Well - my ASCII diagram may have failed to come through cleanly. If so - the topology was pretty basic.. Sending PE <-> Pair of left side tier 2 RRs <-> Pair of left side tier 1 RRs <-> Pair of right side tier 1 RRs <-> Pair of right side tier 2 RRs <-> Receiving PE Hope that helps if the diagram didn't come across cleanly. Thanks - Jon On Wed, Dec 10, 2025 at 5:56 PM Jon Langemak <jon@interubernet.com> wrote:
Hi folks,
I was doing some testing with BIRD in a hierarchical route reflector configuration. Something that looks like this...
+--------+ +--------+ +--------+ +--------+ | Left | | Left | | Right | | Right | | Tier 2 | | Tier 1 | | Tier 1 | | Tier 2 | | RR | | RR | | RR | | RR | +-----------+ | | | | | | | | | | +--------+ +--------+ +--------+ +--------+ +------------+ | | | | | Sending | | Receiving | | PE Router | | PE Router | | | | | +-----------+ +--------+ +--------+ +--------+ +--------+ +------------+ | Left | | Left | | Right | | Right | | Tier 2 | | Tier 1 | | Tier 1 | | Tier 2 | | RR | | RR | | RR | | RR | | | | | | | | | +--------+ +--------+ +--------+ +--------+
Basically we have two PEs that are connected to local tier 2 RRs which then connect to the tier 1 RRs to form a mesh. I couldn't get the lines to not look a mess on the diagram but the peering looks as follows...
* PE routers peer to both local tier 2 RRs (left or right side) * Tier 2 RRs peer to both tier 1 RRs (within left or right) * Tier 1 RRs peer to both tier 1 RRs (between left and right)
The only peering exception in terms of a full mesh peering is that RRs of the same type do not peer together in the same area (left or right). In terms of the diagram that means that vertical peering between nodes does not exist.
What I'm seeing is that in a peering configuration with BGP add-path BIRD is sending all of the paths it is aware of to all of its peers. For instance...
* A prefix originated from the PE on the left side of the diagram shows up as one path in each left side tier 2 RR it is peered with (1 path in each left side tier 2 RR) * The left side tier 2 RRs both peer to each left side tier 1 RRs so they each send a path to each of the left side tier 1 RRs (2 paths in each left side tier 1 RR) * The left side tier 1 RRs both peer to each of the right side tier 1 RRs so they send both paths they are aware of to each right side tier 1 RR (4 paths in each right side tier 1 RR) * The right side tier 1 RRs both peer to each of the right side tier 2 RRs so they send their 4 paths to each right side tier 2 RR (8 paths in each right side tier 2 RR) * The right side (receiving) PE ends up getting 8 paths from each right side tier 2 RR meaning it has a total of 16 paths for one prefix.
Put more simply - a single path originating in the left side ends up getting multiplied by a factor of two at each route reflector "layer". From my basic understanding of the code I believe this happens because BIRD considers paths unique on a per neighbor basis. Because of this - identical paths learned from unique neighbors can get assigned unique path IDs and therefore be propagated through the topology. From my understanding of RFC 7911 - this sort of topology was not discussed so there is no defined means for how to handle add-path and the deduplication of these paths in this kind of hierarchical route reflector setup. However I believe that in some other BGP implementations you can configure the route reflectors to only send paths with unique next-hops which would effectively deduplicate the paths in this kind of topology.
I was curious if other folks had run into this before and if there has been any talk about possible solutions for BIRD to work with add-path in a hierarchical route reflector model without the path multiplication occurring.
Thanks! - Jon