On Tue, 2 Feb 2021 at 18:55, Délsio Cabá <[email protected]> wrote: > I understand your point. I have added a third RR Server to check, and > it's adding a entry to the FIB. So if I have even 10 RR, it will add > 10 entries on the FIB?
Correct 👍 One route entry in the RR client RIB per cluster-id your RR client has a direct IBGP peering with amongst your RR's. 2 cluster id's → 2 RIB entries. 5 cluster id's → 5 RIB entries. > Why the cluster list is different? > > RR-CLIENT#show ip bgp x.x.x.x > BGP routing table entry for x.x.x.x/29, version 1028 > Paths: (3 available, best #1, table default) > Not advertised to any peer > Refresh Epoch 2 > Local > 10.10.10.6 (metric 5) from 10.200.2.126 (10.200.2.126) > Origin IGP, metric 0, localpref 400, valid, internal, best > Originator: 10.10.10.6, Cluster list: 10.200.2.126 > rx pathid: 0, tx pathid: 0x0 > Refresh Epoch 1 > Local > 10.10.10.6 (metric 5) from 10.200.2.124 (10.200.2.124) > Origin IGP, metric 0, localpref 100, valid, internal > Community: 2470510602 > Originator: 10.10.10.6, Cluster list: 10.200.2.124 > rx pathid: 0, tx pathid: 0 > Refresh Epoch 1 > Local > 10.10.10.6 (metric 5) from 10.200.2.125 (10.200.2.125) > Origin IGP, metric 0, localpref 400, valid, internal > Community: 2470510602 > Originator: 10.10.10.6, Cluster list: 10.200.2.125, 0.0.0.1, > 10.200.2.126 > rx pathid: 0, tx pathid: 0 The 3rd entry in your output below the cluster id denotes the RR learned the route from a peering via another RR cluster (RR). E.g. RR client → RR (cluster id 10.200.2.126) → RR (cluster id 0.0.0.1) → RR (cluster id 10.200.2.125) → (another) RR client I presume you have a full-mesh in your test topology between your RR's? I am no "super" expert on the matter: So i highly encourage you to (also) read at least a handful of blog posts/articles/videos online. E.g. https://duckduckgo.com/?q=BGP+route+reflector+cluster → search results. -- Cheers, Chriztoffer
