Why router is selecting longer AS path over a short path?

[Lost & Found]

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

[Harold Ritter]

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,