Project

General

Profile

Actions
Copy link

Bug #15675

open

IPv4 Prefixes with IPv6 Next Hops only show one of two Next Hops for Equal Cost Multipath

Added by Kris Phillips 5 months ago. Updated 24 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Routing
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Release Notes:
Default
Affected Plus Version:
24.03
Affected Architecture:
All

Description

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. 

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

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.

Actions
Copy link

Also available in: Atom PDF