Ali Abbas

The BGP Next Hop Attribute is useful when passing routes received from an eBGP speaker and advertised to an iBGP speaker within the same Autonomous System.

By default when a route is advertised to an eBGP outside of the AS, the router will make sure that the next hop attribute reflects its IP address… now imagine a route is advertised to an iBGP speaker and sourced into the BGP AS group. What is going to happen is that all iBGP routers will have as next hop the external eBGP router of the external Autonomous System.

To prevent this, we can make sure that a route advertised to an iBGP router reflects the IP address of the router sourcing that route into the AS to the iBGP neighbors and not the IP address of the eBGP neightbor which originally advertised this route.

It is important to keep in mind that BGP always make sure that a “hop/destination” is reachable before advertising – if the hop is not reachable, the route will still be held in the BGP table… in the previous case we discussed, the eBGP neightbor from the external  AS would have been “reachable” to our eBGP router (edge-t1), but not necessary to our iBGP speakers within our AS (depending on your configuration).

To avoid potential routing black-holes, one must then make use of the “next-hope-self” attribute to force the iBGP speaker to set the next hop of the route advertised to its own IP address.

- An example configuration on IOS would look as follow -

edge-t1# conf t
edge-t1(config)# router bgp 65100
edge-t1(config-router)# neightbor 10.210.0.10 remote-as 65100
edge-t1(config-router)# neightbor 10.210.0.10 next-hop-self
edge-t1(config-router)# exit
edge-t1(config)#do wr

* Furthermore, you may also use the “set ip next-hop peer-address” under a route-map and apply that route-map on outgoing routes to the BGP neighbor.

Cheers,

Ali

It is by default that all BGP peers within the same autonomous systems must peer with each other to form a full mesh in order for each peer to be able to advertise routes to its adjacent peer.

“Disclaimer: BGP confederacies will not be tackled in this post”

For example

if routerB learns a new route from routerA, it wouldn’t be able to advertise the learned route to routerC and routerC would only be able to learn the route from routerA. Now imagine if your network isn’t fully meshed? well I am sure you guessed right! depending on your network infrastructure, routing on this advertised subnet from router A will be un-reachable through routerC and you will be having a big problem of convergence.

What if the peers cannot be meshed together?

It is possible when using standard iBGP to “force” a router to “reflect” the routes it learned to another adjacent peer. In simple words, routerB learned the route from routerA, routerB “reflects” that route to routerC.

Route Reflectors

As stated already, route reflectors eliminate the need for a full mesh setup, thus allow scalability but also a route reflector reduce data exchange between peers by only reflecting the best path. When setting up RR, you would be defining what is generally referred as a cluster (RR + client peers), in our example below, the RR is routerB and the client peers are routerA and routerC. This group is then defined as a cluster.

It is also important to understand how RR works.

As we said earlier, RR selects the best path when receiving a route from an iBGP peer; if the route had originated from a non-client iBGP peer (imagine routerD connected to routerA), this route will then be only reflected to all route reflectors clients (routerA and routerC for example), thus any other none-rr-clients needs to be fully meshed.  If the route nevertheless originates from either routerA or routerC, the route would then be reflected to both non-client and rr-client .

Now let’s see how we can set up a simple route reflector…

Configuration using a private ASN

Simple topology: [routerA 192.168.1.1] —– [ routerB 192.168.2.1] —– [ routerC 192.168.3.1]

routerB(config)#router bgp 64514
routerB(config-router)#neighbor 192.168.1.1 remote-as 64514
routerB(config-router)#neighbor 192.168.1.1 route-reflector-client
routerB(config-router)#neighbor 192.168.3.1 remote-as 64514
routerB(config-router)#neighbor 192.168.3.1 route-reflector-client

Now routerB will be advertising routers learned from routerA to routerC and from routerC to routerA.

What more?

I am not going to reiterate what RFC 2796 addresses, thus I suggest a read at http://www.ietf.org/rfc/rfc2796.txt to learn more about RR loop detection and avoidance.