In some publications it is mentioned that a link local next-hop can’t be used when redistributing routes into BGP because routers receiving the route will not know what to do with the next-hop. That is one of the reason why HSRPv2 got support for global IPv6 addresses. One such scenario is described in this link.
The topology used for this post is the following.
I have just setup enough of the topology to prove that it works with the next-hop, so I won’t be running any pings and so on. The routers R1 and R2 have a static route for the network behind R3 and R4.
ipv6 route 2001:DB8:100::/48 GigabitEthernet0/1 FE80::5:73FF:FEA0:1
When routing towards a link local address, the exit interface must be specified. R1 then runs BGP towards R5, notice that I’m not using next-hop-self.
router bgp 100 bgp router-id 1.1.1.1 bgp log-neighbor-changes neighbor 2001:DB8:1::5 remote-as 100 ! address-family ipv6 redistribute static neighbor 2001:DB8:1::5 activate exit-address-family
If we look in the BGP RIB, we can see that the route is installed with a link local next-hop.
R1#sh bgp ipv6 uni BGP table version is 2, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 2001:DB8:100::/48 FE80::5:73FF:FEA0:1 0 32768 ?
What next-hop do we have at R5 though?
R5#sh bgp ipv6 uni BGP table version is 10, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *>i 2001:DB8:100::/48 2001:DB8:1::1 0 100 0 ?
We see the next-hop of R1 and not the link local address. How did this happen? We aren’t using next-hop-self. If we debug at R1, we will see what happens.
R1#debug ip bgp updates R1#debug ip bgp ipv6 uni
*Aug 30 06:19:15.863: BGP(1): 2001:DB8:1::5 NEXT_HOP part 1 net 2001:DB8:100::/48, next FE80::5:73FF:FEA0:1 *Aug 30 06:19:15.863: BGP(1): Can't advertise 2001:DB8:100::/48 to 2001:DB8:1::5 with NEXT_HOP FE80::5:73FF:FEA0:1 *Aug 30 06:19:15.863: BGP(1): (base) 2001:DB8:1::5 send UPDATE (format) 2001:DB8:100::/48, next 2001:DB8:1::1, metric 0, path Local
We can see that BGP was going to advertise it with the link local next-hop but then realized that this would not work. It then replaced the link local next-hop with a global next-hop.
While it may have been true at some point that routes must point to a global next-hop, this does not hold true in modern code. BGP will automatically advertise its updates with a global next-hop.
Thanks Daniels for this nice article !.
I have one query pls
Is it because of link local address can be used as a next-hop in a single subnet only, R1 advertise it’s global unicast address as a next-hop to it’s peer ?
if yes then why don’t R1 advertise it’s link local address as a next hop when advertising these redistributed route to R5 ?
Is this specific to BGP or IGP will also work like this
Thanks a lot, Daniel. Up to now I used ‘next-hop-self’ by default to overwrite link-local addresses. I didn’t know this useful change in modern code. Thank you very much.
the fact that new ios magically change NH if its link local doesnt change the fact that BGP cant use a link-local NH
people should really think about what they are doing instead of relying of such fragile IOS behavior
so i fail to see how its myth busting…