BGP - next hop self command.

[s4sandyad]

Hi,

I am learning bgp...need your help...

Connectivity is like as follows:

Router A (ebgp)  Router B (ibgp) Router C (ibgp) Router D

when loopback subnet of Router A is received at Router C, defalult with next hop address of outgoing interface of router A.

after configuring next hop self command on router B to C, on Router C then show next hop add outgoing interface of router B. k no prob.

but same subnet isn't received on router D because of ibgp split horizon rule; used route-reflector client on router C. then router D received subnet of Router A; but shows next hop address outgoing interface of router B. even though i used next hop self on router C towards D.; router D didn't show next hop add of router C. Why ??

Its ok i used IGP i.e. EIGRP in between router B, C & D. it works.

=> why next hop self doesn't work in this scenario ?? & is it the reaseon we need to use IGP into IBGP AS ??

--Sandy.

[milan.kulik]

Hi,

you can read

"When you use nexthop-self on RRs, the clause only affects the next hop of eBGP learned routes because the next hop of reflected routes should not be changed. "

here:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#routereflectors

But I believe you could use an outbound route-map to set ip next-hop as described here:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg-int-features.html#GUID-A753218A-E17A-4B02-ADE9-7B7CB248E82F

Best regards,

Milan

[Jose Jara]

Hi,

I agree with Milan, you can use a route-map applied in the outbound direction to rewrite the next-hop.

Another option is to use the "next-hop-self all" (note the keyword all), that will update the next hop of both iBGP and eBGP learned prefixes:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html#wp4972925610

The use case for this (next-hop-self all) is I see is in a DMVPN Network, but not for an ISP - MPLS/VPN Provider.

Regarding BGP and the need of IGP, think that different protocols have different purposes. The IGP, specially used in large-scale deployments, is used to build the topology and provide reachability to internal prefixes. The IGPs used in large-scale designs, IS-IS/OSPF, are good here because as they are link-state protocols and have a complete view of the network and will detect fast a change and run SPF for a new topology if needed. Furthermore, they have extensions to use MPLS/Traffic Engineering.

Once the topology is build and the routers have reachability to internal prefixes, then you can run iBGP (typically between loopbacks) to provide reachability to external prefixes. BGP is very good to transport a good amount of prefixes, as it is based in TCP. If the IGPs could handle the amount of prefixes can handle BGP, then you would not need iBGP, you would redistribute (which is another option) them to the IGP and we will only have external BGP. However, in order to provide reachability and build and scalable network, you need BGP plus an IGP.

The reason of having the need of an iBGP full mesh is to prevent black-holes in the network. Think that routers A-B-C, A is running iBGP with C, which are edge routers receiving prefixes from other ASN´s. As B is not running BGP, when it receives a packet destined to an external network it will drop that packet as it has no information in the RIB.

There was also an old rule called synchronization that prevented the problem of advertising a black hole to another AS. The rule was that if the prefix is not in the IGP, BGP will not advertise that prefix. So, redistribution solved in the old days the problem of black holes and the rule of sync the problem of advertising them to other ASNs. As the networks got bigger and bigger, there was no point to redistribute the external prefixes to the IGP, so iBGP full-mesh/RRs were deployed and the sync rule disabled.

Hope this helps,

Jose.

[Peter Paluch]

Hi Jose,

First of all - this is a very nice and insightful answer. I like it very much! Rated as deserved.

Just a couple of very minor remarks. Regarding the existence BGP and IGP, you have said very correctly that they are different in their purpose and that is why we need them both. I would like to point out that BGP is designed so that in many places, it simply assumes that there is already a full visibility to each and every network in an autonomous system. For example, with iBGP sessions, you need to specify neighbors that are possibly several hops away. Without a pre-existing IGP already running, the neighbors would simply be unreachable. Also, when a router receives a route via an iBGP session, the value of the next hop is very often going to be an address several hops away, again necessitating the existence of an IGP besides BGP. Simply put, running a network with only BGP and advertising all routes in it, both external and internal, would end up in chicken-and-egg scenarios.

You wrote: "If the IGPs could handle the amount of prefixes can handle BGP, then you would not need iBGP, you would redistribute (which is another option) them to the IGP and we will only have external BGP." This is very true if we simply wanted our autonomous system to act as a multihomed autonomous system, knowing about external networks reachable over several paths. However, if you wanted to run your autonomous system as a transit AS, providing transit communication capability to neighboring ASes, it would not be sufficient to redistribute from BGP to IGP and vice versa on boundary routers, as in this redistribution, you would lose all BGP attributes of the redistributed routes. Therefore, even if IGPs could handle the punishment of handling over 500K external routes, you would still need to run iBGP sessions at least between your boundary routers in order for BGP to keep the attributes of advertised networks.

Regarding the (in)ability of IGPs to handle as many routes as BGP, it is not just a matter of TCP - in fact, I would not personally attribute BGP's scalability to the use of TCP. Rather, it is about the overall design of the protocol. BGP was designed from ground up to advertise information in a very compact, efficient form, and to allow processing of this information in a relatively straightforward way.

I am looking forward to see you posting more!

Best regards,
Peter

[Jose Jara]

Hi Peter,

thanks for your reply!

I totally agree with you. Regarding the redistribution and losing the attributes, there is a functionality in IOS to maintain some via table-map but it is very limited and definitely restricted to enterprise environment. It would be cumbersome and almost impossible to do it in SP world.

The ability of BGP to handle so many prefixes and scale much better than IGP´s, it is a matter of the whole protocol, not just TCP. I simplified too much!

Best Regards,

Jose.

[Aaron Harrison]

That's normal - the next-hop-self sets the next hop for routes originated by the iBGP peer. A route reflector 'reflects' routes, rather than readvertising them.

The assumption would be that you have full connectivity between the iBGP peers, just as you would have if you didn't have a route reflector... i.e. D can route to interfaces on B, as it would if it had a 'normal' iBGP peer relationship.

Aaron

[Jon Marshall]

Aaron

the next-hop-self sets the next hop for routes originated by the iBGP peer

It's probably the way you worded it but an IBGP router cannot set the next hop whether it is a router reflector or not.

Just didn't want to confuse the OP :-)

Sandy, yes this is why you need an IGP.

The alternative to using route reflectors is to have a full mesh of peerings between your IBGP routers however even here you may need an IGP.

If every IBGP router had a direct connection to every other IBGP router then you do not need an IGP. So in the example you are using C and D would need to be connected to B as well as to each other.

This obviously does not scale at all.

You can still have a full mesh even without direct connections but then you need an IGP so that the IBGP peers know to reach each other.

Even this does not scale particularly well in a lot of instances.

Finally you can use BGP confederations but you may want to look into those later as you are just starting to learn BGP.

Jon