Duplicated routes received from Route Reflectors
Dear 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 2.125 config: https://pastebin.com/jUh0ZQ6h 2.124 config: https://pastebin.com/5dhx94db
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
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
On Tue, 2 Feb 2021 at 18:55, Délsio Cabá <delsio@gmail.com> 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
participants (2)
-
Chriztoffer Hansen -
Délsio Cabá