We have completed the upgrade of IEOC! All posts, comments and user profiles have been migrated. For security reasons, we have reset all passwords. To set a new password please Click Here. Further updates soon to follow.

BGP Best Path Selection vs IP Route

Happy new Year Experts !

wonder any one has a better understanding for relationship between the best path result obtained in sh ip bgp vs sh ip route?[8-|]

Refer to below output

R1#sh ip bgp
BGP table version is 245925, local router ID is 10.192.7.151
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf  Weight      Path
*> 10.0.0.0         10.192.5.102                        400          0               65206 i
*                        10.192.5.101                        400          0               65206 i                   
* i                      10.192.7.152                 0      400         0                65206 i

R1#sh ip ro | i 10.0.0.0
     10.0.0.0/8 is variably subnetted, 1298 subnets, 14 masks
B       10.0.0.0/8 [20/0] via 10.192.5.101, 2w2d

 

Question : from the sh ip bgp output indicate that the best valid path to reach 10.0.0.0 is via next hop 10.192.5.102

                likewise from the sh ip ro output , it show that the route to reach 10.0.0.0/8 is via next hop of 10.192.5.101

 

anyone can shed some light , as i expecting both result of sh ip bgp and sh ip ro should be the same next hop ip address?

but in reality i getting different ip 10.192.5.102 & 10.192.5.101

thanks alot !!!

Mr.BL[8-|]

 

Comments

  • well, but it is close, close enough does not count?   .102 & .101 [:D]

    there is 2nd line in bgp with 10.192.5.101, 2 entries but 1st the best , so  what does show ip bgp 10.0.0.0/8 show ?

  • I also would like to see the more descriptive output.

    show ip bgp 10.0.0.0

    show ip route 10.0.0.0

     

    Thanks

  • hi Martini, thx for looking into this, ya it does not count as basically 101 and 102 are different bgp router neighbor

    R1#sh ip bgp 10.0.0.0
    BGP routing table entry for 10.0.0.0/8, version 245731
    Paths: (5 available, best #1, table Default-IP-Routing-Table)
    Multipath: eBGP iBGP
      Advertised to update-groups:
         1                            2
      65206
        10.192.5.102 from 10.192.5.102 (10.192.7.102)
          Origin IGP, localpref 400, valid, external, multipath, best
      65206, (received-only)
        10.192.5.102 from 10.192.5.102 (10.192.7.102)
          Origin IGP, metric 1, localpref 100, valid, external
      65206
        10.192.5.101 from 10.192.5.101 (10.192.7.101)
          Origin IGP, localpref 400, valid, external, multipath
      65206, (received-only)
        10.192.5.101 from 10.192.5.101 (10.192.7.101)
          Origin IGP, metric 1, localpref 100, valid, external
      65206, (received & used)
        10.192.7.152 (metric 2) from 10.192.7.152 (10.192.7.152)
          Origin IGP, metric 0, localpref 400, valid, internal

  • well well, [8-|] , my piping | include command make me overlook another route in the ip routing table,...revisted below is the result ...my apology

    R1#sh ip route bgp | b 10.0.0.0

     10.0.0.0/8 is variably subnetted, 1296 subnets, 14 masks

    B       10.0.0.0/8 [20/0] via 10.192.5.101, 2w3d
                            [20/0] via 10.192.5.102, 2w3d

    so BGP injected both route into routing table ...now it started to make some sense : )

  • (received & used) versus received-only --- i think is due to bgp multipath feature.

    in sh run | s r bgp do u ahve command    maximum -path x

  • yes , it is multipath with following command line in the router bgp section config:

     maximum-paths 4
     maximum-paths ibgp  4

  • well, another puzzle, if this is a multipath, it should show a *m identifier in the sh ip bgp  : )

     

     

  • peetypeety ✭✭

    (received & used) versus received-only --- i think is due to bgp multipath feature.

    Nope, it's due to soft-reconfiguration inbound being enabled. If enabled for a particular neighbor, the learned routes could have three different possible outcomes:

    (received & used) - means the prefix was not altered by the inbound filtering mechanisms (if any), and is being used in the same form as it was learned.

    (received) - means this is how the prefix was learned, prior to any inbound filtering/manipulation mechanisms being applied.

    [nothing in parenthesis] - means this is how the prefix exists in the BGP RIB, after all inbound filtering/manipulation is applied.

    Note that soft-reconfig in is configured on a per-neighbor basis. A neighbor without this feature enabled would simply show the prefixes after filtering.

Sign In or Register to comment.