Bug #15675
Updated by Marcos M 4 months ago
When configuring FRR to utilize ECMP with IPv6 next hops in BGP for IPv4 prefixes, only one of the next hops will be present in FRR. When utilizing IPv4 next hops, both will show up as expected for IPv4 prefixes. When testing IPv6 next hops with IPv6 prefixes, this also works fine. Below is a sanitized output from a customer firewall. <pre> netstat -Wrn4 | grep [Destination IPv4 Address Here] [IPv4 Address Here] [IPv6 Next Hop #2] UGH1 124 1500 lagg0.10 show bgp ipv4 [Destination IPv4 Address Here] BGP routing table entry for [Destination IPv4 Address Here]/32, version 61 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: 10.25.5.57 10.25.6.65 Local [IPv6 Next Hop #1] (metric 1) from [IPv6 Next Hop #1] (172.16.16.121) Origin IGP, localpref 100, valid, internal, multipath Last update: Tue Jul 23 14:54:49 2024 Local [IPv6 Next Hop #2] (metric 1) from [IPv6 Next Hop #2] (172.16.16.110) Origin IGP, localpref 100, valid, internal, multipath, best (Router ID) Last update: Tue Jul 23 14:17:15 2024 </pre> As shown above, both IPv6 next hops are present in FRR, but they are not present in pfSense. As such, this doesn't appear to be an FRR bug, but a pfSense routing bug. Tested on 24.03.