Hi Thanks for the response 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? 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 On Tue, Feb 2, 2021 at 4:43 PM Chriztoffer Hansen <ch@ntrv.dk> wrote:
Hi,
On Tue, 2 Feb 2021 at 09:37, Délsio Cabá wrote:
We have a installed 2 BIRD RR (10.200.2.125 and 10.200.2.124) just installed to use as reflectors on our network
We noticed the client is adding 2 entries to the routing table.
Is this normal?
Taking into consideration we do full global BGP is will be too much memory wasted:
RR-CLIENT#show ip bgp 0.0.0.0 BGP routing table entry for 0.0.0.0/0, version 0 Paths: (2 available, no best path) Not advertised to any peer Refresh Epoch 1 xxxx 10.200.0.252 (inaccessible) from 10.200.2.125 (10.200.2.125) Origin IGP, metric 0, localpref 350, valid, internal Community: 2470515592 Originator: 10.200.0.252, Cluster list: 10.200.2.125 rx pathid: 0, tx pathid: 0 Refresh Epoch 1 xxxx 10.200.0.252 (inaccessible) from 10.200.2.124 (10.200.2.124) Origin IGP, metric 0, localpref 350, valid, internal Community: 2470515592 Originator: 10.200.0.252, Cluster list: 10.200.2.124 rx pathid: 0, tx pathid: 0
Yes. This is completely normal for IBGP RR clients. (Regardless if you are using BIRD or not) Your RR client receives one best-route from each RR (or RR cluster). Your RR client will install both routes in it's RIB. And the "best" route (decided locally by RR client configured logic) is installed in the FIB.
You will want to have multiple routes for the same destination in your local RR client RIB. Should one of the RR's go offline. Being taken down for maint, etc. (= RR not available). Your RR client will then "fall-back" to the next best route it stores in it's RIB and install that in the FIB. Instead of the "now" gone best route. (In short, quicker failover to another route to the destination, and has high potential lessening the time traffic is potentially blackholed during a route convergence)
-- Cheers, Chriztoffer