Technical Tip: BGP IPv6 routes show IPv6 link-local address as next-hop rather than global unicast address (Expected Behavior)
| Description | This article describes why IPv6 routes received via BGP show an IPv6 link-local address (LLA) as a next-hop, rather than just the global unicast address (GUA). |
| Scope | FortiGate, IPv6. |
| Solution | Consider the following example topology:
In the above topology, the FortiGate and the remote device are establishing BGP connections using both IPv4 and IPv6. The remote peer then advertises its connected IPv6 network (2402:800:6a00:24::100/64) to the local FortiGate over both BGP neighborships.
On the FortiGate, BGP neighbor configurations have been added for both of the remote peer's addresses (2402:800:6a00:27::301 and 10.211.244.82), and BGP has been activated for both IPv4 and IPv6. The remote device is configured similarly, and so two BGP neighborships are established successfully: 
After establishing BGP with the neighbor, the FortiGate shows the following output when checking the routing table and the list of received BGP prefixes:
As shown in the above screenshots, the FortiGate is indeed learning routes for 2402:800:6a00:24::100/64 from both BGP peerings to the remote device. However:
The above is expected behavior. According to RFC 2545 (specifically Section 3), BGP speakers will advertise both the global IPv6 address of the next-hop and also the link-local IPv6 address of the next-hop if (and only if) the BGP speaker shares a common subnet with both the device that owns the global IPv6 address specified in the BGP 'Network Address of Next Hop' field and the device/peer that is being advertised to.
Since the remote peer in this case is the owner of the next-hop and that next-hop address is in the same subnet as the FortiGate, the peer includes both the global and the link-local address in the route advertisement (which is why the FortiGate sees and receives both next-hops). In contrast, IPv4 BGP neighborships do not have this same defined behavior, and so IPv6 routes received via IPv4 only include the global IPv6 address as the next-hop.
If it is preferred to only use the global IPv6 address as the next-hop shown in the routing table, there are several workarounds available:
Option 1: Assign a higher weight to the routes learned via the IPv4 BGP neighbor so that they are preferred over the routes received via IPv6. This can be done by assigning weight values to the entries under config router bgp -> config neighbor (higher is better):
Since the routes received from the IPv4 neighbor are preferred by the higher weight, and since IPv6 routes received via IPv4 BGP only include the global address as the next-hop, the FortiGate will end up installing routes that only have global IPv6 next-hop addresses.
Option 2: Use route-maps on the FortiGate to modify the link-local next-hop address for the received BGP prefixes. To do this, create a prefix list to match the incoming IPv6 prefixes, then use an inbound IPv6 route-map (route-map-in6) to change the link-local next-hop address (set set-ip6-nexthop-local:(
 
   In the above example, the IPv6 link-local next-hop address was replaced with the global address of the remote device (2402:800:6a00:27::301). This solution does work but requires administrators to set a specific next-hop address, which may not be optimal if that address may change.
With that in mind, Change #1099554 was implemented in FortiOS 7.6.3 and later to add support for a more flexible solution. Instead of setting a specific address for set set-ip6-nexthop-local, it is now possible to specify '::' instead, which means 'unspecified'. Prefixes altered in this way via inbound route-map will result in the FortiGate ignoring the link-local next-hop address and only using the global address when installing the route into the route table.
config router route-map edit <name>
With both of the above methods, the outcome is the same: the next-hop address for the IPv6 route will show the global address rather than the link-local address:
Related documents: |
