Closed jharbott closed 6 years ago
Give this branch a try: https://github.com/donaldsharp/frr/tree/bgp_v6_ifindex
Please note I have done absolutely positively no testing on this as of yet.
I just tested the patch received through Cumulus GSS and can confirm that this fixes the issue for us.
cumulus@prod-spine1-zrh1:mgmt-vrf:~$ net show route vrf public 2a06:c00::1ab:3353/128
RIB entry for 2a06:c00::1ab:3353/128 in vrf public
==================================================
Routing entry for 2a06:c00::1ab:3353/128
Known via "bgp", distance 20, metric 0, vrf public
Last update 01:59:12 ago
2a06:c01:1:1902::7a0c:12, via public
FIB entry for 2a06:c00::1ab:3353/128 in vrf public
==================================================
cumulus@prod-spine1-zrh1:mgmt-vrf:~$ net show route vrf public 2a06:c00::1ab:3353/128
RIB entry for 2a06:c00::1ab:3353/128 in vrf public
==================================================
Routing entry for 2a06:c00::1ab:3353/128
Known via "bgp", distance 20, metric 0, vrf public, best
Last update 00:01:00 ago
* 2a06:c01:1:1902::7a0c:12, via vlan1902
FIB entry for 2a06:c00::1ab:3353/128 in vrf public
==================================================
2a06:c00::1ab:3353 via 2a06:c01:1:1902::7a0c:12 dev vlan1902 proto bgp metric 20 pref medium
Thanks a lot for the fix! I hope this will make it into CL 3.6.0.
it will.
When an IPv6 route is received from a neighbor, the interface on which the BGP session is connected is attached to the route. This leads to broken forwarding when the announcement contains a next-hop that is reachable via a different next-hop. A common scenario for this is when the neighbor is a route-server or iBGP route-reflector, as those will mostly annouce routes pointing to other routers than themselves. The output of
show ipv6 route
in that case looks like:Note how the BGP route contains
eth0.8
which is the interface via which the BGP neighbor is connected, while the next-hop would be reachable viaeth0.2
.This issue seems to have been inherited from quagga, see https://bugzilla.quagga.net/show_bug.cgi?id=851 but I verified it with frr 4.0. The patch in that bug does not solve the issue for me when tested against quagga 1.2.4.