i like to use "next hop self" on neighbor config, although route-map + set ip next-hop is good too, and can be used interchangably with next hop self". This comes into play alot with non-directly connected neighbors, i.e. peering with loopbacks, etc.
You and your neighbor will then have "ebgp-multihop 5" or some number of hops after the neighbor 18.104.22.168
I have never used next-hop-unchanged anyone care to jump in ?
next-hop-unchanged is on eBGP VPNv4 sessions for l3vpn inter-AS scenarios. This knob ensures that the BGP NH will be kept to the original PE loopback address. This loopbacj address is normally via mBGP IPv4 + Labels. Without this statement, the BGP NH would be changed to the NH address of the ASBR, which would be undesirable.
Hope this helps,
Andrea, it's a big question - as a clear explanation of these concepts for all scenarios is probably about 20 pages of content.
Briefly, next-hop-self... when you peer to an external BGP neighbor the default behaviour of your router is to accept the next-hop of incoming BGP routes as the address of the external neighbor. But, if the link between you and your external neighbor is not known inside your AS, you can set next-hop-self on your router. This causes your router to set the next-hop for routes learnt from the external neighbor to be your routers BGP ID. So on all routers inside your AS, they see a next-hop of those routes as your BGP speaker rather than the external neighbor you learnt the routes from.
Thank you for your answers, guys,
on RR scenario, I could use "next-hop-self" for eBGP connections, and eventually a route-map for route reflector clients, is it?
And on confederation scenario? What about that?
thanks for your support
You should not have to do anything with next-hop for BGP route-reflectors. Sure, the source of updates from a RR is the address of the RR, but the next-hop of prefixs in the update is still that of the original BGP speaker in the AS.
Peter is correct. This even applies in a situation where the RR itself has eBGP sessions. The RR in this context will exclusively apply the next-hop-self to updates received from the eBGP peers.
Hope this helps,
The interesting (and clarifying) (and slightly off topic) thing is, the RR code only applies to updates from iBGP peers.
So, if you have an iBGP peer configured as a RR-client, any iBGP updates you get from anywhere should be propagated to that client, and any updates from that RR-client should be propagated to all other iBGP clients.
I'm not sure that your comment is right Harold. If there is an eBGP peer on a speaker that also has an RR-client, why would he automatically (exclusively) apply next-hop-self to updates from the eBGP peer?
The BGP next-hop-self command doesn't apply to reflected routes. The only way to change the BGP NH when reflecting routes from one client to another is to use an outbound route-map.
BTW: Changing the BGP NH on reflected routes is not recommended and can lead to serious issues.
Hope this helps,
Ok, so I'm confused as to why you'd think I suggested or asked that?
My point was that I don't know how the presence or not of an eBGP peer on a speaker that also has a RR-client would effect that application of nxt-hp-slf on the eBGP updates - as you suggested a couple of quotes back.
We're spiralling miles away from the original point.
The only thing I suggested is that the only point of configuring the next-hop-self is to change the BGP NH of the eBGP learnt prefixes and that it is has no affect on reflected prefixes.
As for your last comment, I could only say that one thing leads to another ;o)