Jon,

We are taking full bgp routes from our ISPs, is there any specific information you need from the sh ip bgp so I can eliminate some output.

Bob

Sorry, yes i just wanted to see the output from a "sh ip bgp" for those specific routes. If you notice the IGP metrics are different between the routes but that still doesn't explain why it is choosing 10.1.1.2.

Jon

Jon,

I made a mistake about the router ID. Router with IP Address 10.1.1.1 has a router iD of 66.28.22.29 and router with an IP Address of 10.1.1.2 has a router ID of 10.1.1.2. So since 10.1.1.2 is lower than 66.28.22.29, that's why it would be using 10.1.1.2 as the next hop.

Bob

Hi Jon,

this is something I'd really like to clarify:

It the metric shown below the IGP metric or the MED value (which would not be compared as prefixes are coming from different ASes)?

core-pri#sh ip bgp 8.3.26.0/23
BGP routing table entry for 8.3.26.0/23, version 245129772
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  65535 3356 26769
    10.1.1.2 (metric 101) from 10.1.1.2 (10.1.1.2)
      Origin IGP, metric 21381, localpref 100, valid, internal, best
  174 3549 26769
    10.1.1.1 (metric 101) from 10.1.1.1 (66.28.22.29)
      Origin IGP, metric 6010, localpref 100, valid, internal

And the BGP path selection algorithm step 8 is

"Prefer the path with the lowest IGP metric to the BGP next hop."

But the IGP metric to the next hop is not shown by this output, is it?

Or is it that (metric 101)? I don't see this (metric) in the output on my BGP routers!

Your original asking for "sh ip bgp" output might show some more details - the weight, e.g.

IMHO, "sh ip bgp 8.3.26.0/23 lon" would bring the desired output format.

Thanks,

Milan

Message was edited by: milan.kulik

Hi Milan

Yes i'm not 100% sure myself and would like to clarify. I assumed it was the IGP metric but it could be the MED as you say and because they are from different AS they wouldn't normally be compared. That is exactly why i asked for the "sh ip bgp" output.

I need to do a bit of testing i guess but i think i may have made an error.

Jon

Hi Jon,

that 10.1.1.1 (metric 101) from 10.1.1.1 (66.28.22.29)

is even more confusing me - I don't see it in output from my BGP routers :-(

Milan

milan.kulik wrote:
Hi Jon,
that 10.1.1.1 (metric 101) from 10.1.1.1 (66.28.22.29)
is even more confusing me - I don't see it in output from my BGP routers :-(
Milan

Milan

Yes i know, i can't see it in the output either in my test setup. I also had a quick scan of docs for outputs and still can't find an example of that.

Jon

Below is the sh ip bgp 8.3.26.0/23 longer-prefixes:

core-pri#sh ip bgp 8.3.26.0/23 longer-prefixes
BGP table version is 246313347, local router ID is 130.64.254.1
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
*>i8.3.26.0/23      10.1.1.2             21381    100      0 65535 3356 26769 i
* i                 10.1.1.1              6010    100      0 174 3549 26769 i

The IGP metric to 10.1.1.2 and 10.1.1.1 are the same, both IP are being learned by OSPF:

O       10.1.1.1/32 [110/101] via 130.64.4.9, 00:14:59, Vlan420
O       10.1.1.2/32 [110/101] via 130.64.4.33, 00:14:59, Vlan450

Bob

Hi,

so 101 is metric to the next hop (what IOS version are you running? My IOS is not showing that.)

21381 and 6010  is MED - not compared

And the router ID seems to be the real tie-breaker.

BR,

Milan

Milan,

From the output below:

10.1.1.1 (metric 101) from 10.1.1.1 (66.28.22.29)

The 10.1.1.1 is the BGP neighbor, the metric (101) is the IGP metric to that neighbor and the 66.28.22.29 is the router ID.

Bob

Bob

Thanks for that. Looks like i made a mistake.  It as, Milan suggested, the MED that is shown as the metric.

Apologies for the misleading information.

Jon

The router I'm executing the commands on is a 6509 with  IOS 122-18.SXF14.

10.1.1.2 (metric 101) from 10.1.1.2 (10.1.1.2)
      Origin IGP, metric 21381, localpref 100, valid, internal, best

I think the metric (101) is the IGP metric to the next hop. The metric 21381 is the BGP metric, but since I'm not using always compare med and then upstream ASs are different, that is being ignored for path selection.

Bob

Hello Bob,

if we look at your original post we see that second path has inside the round clauses ( ) a public ip address that is higher then 10.1.1.2

My understanding is that the second iBGP neighbor is using that public ip address as its BGP router-id.

So the lowest BGP router-id wins and it is 10.1.1.2.

if you can access the 10.1.1.1  iBGP peer and you issue a sh ip bgp summary you should be able to verify if the BGP router-id is actually the public ip address rather then the supposed private 10.1.1.1.

10.1.1.1 is the BGP next-hop and it is the IP source of the iBGP session but it doesn't look like to  be the current router-id.

About the other notes

(metric 101)

IGP metric to next-hop

origin IGP means i as origin code (last char in AS path)

Origin IGP, metric 21381, localpref 100, valid, internal, best

the second is the BGP MED / metric, internal means that comes from an iBGP session and appears on the left in first chars in sh ip bgp

Hope to help

Giuseppe