05-13-2021 02:16 AM
We have a hub and spoke router but connection should work only when primary connection at the site fails however I run to a issue that from hub we are fording the traffic via the tunnel instead via the private connection.
As checked between working and non-working it seem that router is selecting a longer AS path?
Working: R1#sh ip bgp 10.96.32.0 BGP routing table entry for 10.96.32.0/20, version 3654434 Paths: (3 available, best #2, table default) Multipath: eBGP iBGP Advertised to update-groups: 205 Refresh Epoch 1 887 887 887 887 172.24.194.41 from 172.24.194.41 (172.27.199.158) Origin IGP, metric 3072, localpref 100, valid, external, af-export(1) Community: 23:1101 23:1300 65000:65004 rx pathid: 0, tx pathid: 0 Refresh Epoch 1 4809 887, (received & used) 10.118.1.7 (metric 131072) from 10.118.1.1 (10.118.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best <-- Correct Originator: 10.118.1.7, Cluster list: 10.118.1.1 rx pathid: 0, tx pathid: 0x0 Refresh Epoch 1 4809 887, (received & used) 10.118.1.7 (metric 131072) from 10.118.1.2 (10.118.1.2) Origin IGP, metric 0, localpref 100, valid, internal Originator: 10.118.1.7, Cluster list: 10.118.1.2 rx pathid: 0, tx pathid: 0 Not working: R1#sh ip bgp 10.125.138.0 BGP routing table entry for 10.125.138.0/24, version 3655165 Paths: (3 available, best #1, table default) Multipath: eBGP iBGP Advertised to update-groups: 186 188 205 Refresh Epoch 1 887 887 887 887 172.24.194.41 from 172.24.194.41 (172.27.199.158) Origin IGP, metric 3072, localpref 100, valid, external, af-export(1), best Community: 23:1101 23:1300 65000:65004 rx pathid: 0, tx pathid: 0x0 Refresh Epoch 1 4809 887, (received-only) 10.118.1.7 (metric 131072) from 10.118.1.1 (10.118.1.1) Origin IGP, metric 0, localpref 100, valid, internal Originator: 10.118.1.7, Cluster list: 10.118.1.1 rx pathid: 0, tx pathid: 0 Refresh Epoch 1 4809 887, (received-only) 10.118.1.7 (metric 131072) from 10.118.1.2 (10.118.1.2) Origin IGP, metric 0, localpref 100, valid, internal Originator: 10.118.1.7, Cluster list: 10.118.1.2 rx pathid: 0, tx pathid: 0
Tried bouncing the connection to 172.24.194.41 but still the same. any inputs?
R1#sh ip route 10.96.32.0
Routing entry for 10.96.32.0/20
Known via "bgp 23", distance 200, metric 0
Tag 4809, type internal
Last update from 10.118.1.7 2d08h ago
Routing Descriptor Blocks:
* 10.118.1.7, from 10.118.1.1, 2d08h ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 4809
MPLS label: none
R1#sh ip route 10.125.138.0
Routing entry for 10.125.138.0/24
Known via "bgp 23", distance 20, metric 3072
Tag 887, type external
Redistributing via nhrp
Last update from 172.24.194.41 00:54:57 ago
Routing Descriptor Blocks:
* 172.24.194.41, from 172.24.194.41, 00:54:57 ago
Route metric is 3072, traffic share count is 1
AS Hops 4
Route tag 887
MPLS label: none
05-13-2021 06:56 AM - edited 05-13-2021 09:52 AM
Hi @Lost & Found ,
Just as a note, "received-only" means that "soft-reconfiguration inbound" is configured and therefore the prefix will be kept locally even if it has been filtered out (not being used for best path calculation). "received & used" also means that "soft-reconfiguration inbound" is configured, but in this case the prefix is not filtered out (used for best path calculation).
For prefix 10.125.138.0/24, the only path available is the external one with the longer AS Path, hence it is being selected. The other two paths (internal) are showed as received-only, which means that they are received from the route reflectors, but not being used as they are filtered out by the ingress policy.
Please check your ingress filtering policy for the sessions with the route reflectors.
Regards,
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide