BGP Peering

Route advertisements will differ depending on whether the advertisement is occurring over iBGP or EBGP. Some of the important differences have to do with next hops and iBGP full mesh.

Below are three routers running BGP. R8 and R10 are running iBGP in ASN 810.1, while R8 and R5 are running EBGP, R5 being in ASN 100. R8 and R10 have OSPF for internal loopback connectivity. R5 is advertising it’s loopback network 192.168.10.0/24 down to R8, and R10 is advertising a loopback network of 192.168.1.0/24.

R5:

R10:

When R5 tries pinging R10’s advertised loopback, it will not succeed, even though R5 has a valid route via BGP in it’s routing table.

Looking on R10, a ‘show ip bgp’ displays zero ‘>’ next to R5’s route, which means that it was not actually added to the routing table.

Drilling into this even further, BGP shows that the next hop (10.8.8.2, R5) is not accessible in R10’s routing table.

What this displays is how iBGP will advertise to its neighbors. The EBGP peer will advertise 1 hop further into its autonomous system but will not change the next hop. This can be troublesome for iBGP neighbors who do not have route information for the transit to another AS.

A solution to resolve this issue is by doing BGP ‘Next Hop Self’. On R8 the config for this is under the router bgp AS.

The command is after specifying which neighbor this should be applied on. This alone will not change the advertisement. A route refresh needs to occur.

A ‘* out’ will refresh the bgp table without taking the adjacency down.

Now on R10 we’ll see the route added to the routing table and the next hop advertised as R8’s internal Loopback address that R10 is peering with.

Below is an image with another BGP neighbor in the mix, R1. R1 is going to be in AS 100 and an iBGP peer with R5.

R1 and R5 have reachability via OSPF and they’re both peering over their Loopback0 IP addresses.

R1 L0 – 100.100.100.1/24
R5 L0 – 192.168.10.1/24

After the peers are up here’s what a ‘show ip bgp’ looks like on R1:

All looks good except for prefix 192.168.1.0, which is a subnet back on R10 in AS 810.1. The reason for this is the next hop again, 10.8.8.1, is not reachable from R1. A fix for this is to perform next hop self again when setting up peering from R5 to R1, or we can simply inject that route into the OSPF domain for underlying reachability, which is the other option – add the routing into the BGP IGP.

On R5 we can see that 10.8.8.0 is a directly connected network, and all we need to do is add that interface into OSPF, or redistribute connected.

On R5 the 10.8.8.0 subnet is on GigabitEthernet0/3, and below is a route-map matching on that interface.

The route-map will then get added into the OSPF process with redistribution. This will allow only what’s in the route-map to get redistributed.

Now on R1 the 10.8.8.0 network is visible via OSPF, and the BGP table shows R10’s loopback subnet has made it to the RIB.

• Main Takeway:
  • By default when eBGP advertises a route to a remote AS, the next hop for the remote AS will be the originating advertising router.
    • If this route gets advertised further into iBGP, the route next hop will not change, it will remain the IP of the remote AS router.
      • Fixes for this are advertising transit path into an IGP, or setting the inbound router as next-hop self – ie. next hop self to iBGP peer.