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 <[email protected]> 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 > >
