highest router-id

[Balajee Muggalla]

Hi,

   When I enabled "bgp bestpath compare-routerid", bgp is choosing the path with highest router-id as the next-hop. I remember reading bgp should choose the path with the lowest router-id incase of a tie-break. Is there any change in the bgp recently? When I disabled this command, it is taking the path whichever is reanred first.

Thanks,

Balajee

[Peter Paluch]

Hello Balajee,

Are you sure that with this command enabled, the router with the highest BGP RID wins? According to the documentation at

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/command/bgp-a1.html#GUID-08F4146C-81FF-4D93-9D8F-6399AD35EFD5

it should be the router with the lowest RID. I believe this is what also RFC 4271 mandates.

You are correct that when this command is disabled, the path learned first is preferred. This is for a good reason: protocols like BGP prefer stability, trading it for slightly intedeterminate behavior. There is really no point in updating the routing table just because a BGP peer announced a route that is precisely identical to one already known, just this BGP peer's RID happens to be lower. Nevertheless, the bgp bestpath compare-routerid should make sure that BGP behaves perfectly deterministically, without being dependent on the (possibly random) order of learning routes from peers.

Best regards,

Peter

[Balajee Muggalla]

Hi Peter,

     Thanks for the reply. Yes, I am seeing it is choosing the path with highest router-id. Please see the o/p below.

R4#show ip bgp 192.168.50.0

BGP routing table entry for 192.168.50.0/24, version 120

BGP Bestpath: compare-routerid

Paths: (3 available, best #1, table default)

  Advertised to update-groups:

     3        

  Refresh Epoch 1

  50

    6.6.6.6 from 6.6.6.6 (6.6.6.6)

      Origin incomplete, metric 0, localpref 100, valid, external, best

      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 1

  30

    3.3.3.3 from 3.3.3.3 (112.1.1.1)

      Origin incomplete, metric 10, localpref 100, valid, external

      rx pathid: 0, tx pathid: 0

  Refresh Epoch 2

  100 50

    4.4.4.4 from 4.4.4.4 (4.4.4.4)

      Origin incomplete, localpref 100, valid, external

      rx pathid: 0, tx pathid: 0

R4#

Thanks,

Balajee

[Raju Sekharan]

Hi Balajee,

The Metric of your 1st route is 0. MED is compared before the Router-ID. So the one with lower MED is preferred

The metric of your last route is not mentioned here. 

[Balajee Muggalla]

Hi Raj,

    They are from two different ASes. So, metric wont be compared in this case.

Thanks,

Balajee

[Raju Sekharan · Accepted solution]

Hi Balajee,

True. I missed that point

The 1st route has router-id 6.6.6.6and 2nd has 112.1.1.1

It has selected the 1st one. Is it not correct? or am I missing anything else

3rd one has a longer AS PAth. So that is anyway not the best

[Balajee Muggalla]

Oh...my bad. You are correct. I was assuming 3.3.3.3 as router-id, did not pay attention to 112.1.1.1. So, everything is working fine. Thanks for pointing out and sorry for the confusion.

[Raju Sekharan]

You are welcome

*** rate if the post helps ***

[Richard Burts]

Balajee

When you use the command bgp bestpath compare-routerid then you are changing the default behavior of BGP and instructing IOS to use router ID in a way that is different from the default behavior. When you disable the command then IOS goes back to its default behavior. And in BGP the default for IOS is to choose the path that was learned first. So there is not really any change in BGP, other than that Cisco gives us a configuration option where we can change the behavior.

HTH

Rick

[Peter Paluch]

Hi Rick,

When you use the command bgp bestpath compare-routerid then you are  changing the default behavior of BGP and instructing IOS to use router  ID in a way that is different from the default behavior.

Umm... What do you understand by "default"? The RFC 4271 appears to mandate that routes learned from BGP speaker with the lowest RID are preferred:

      f) Remove from consideration all routes other than the route that
         was advertised by the BGP speaker with the lowest BGP
         Identifier value.

RFC 4271, Section 9.1.2.2.

The Cisco's implementation seems to differ here, according to the document

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

Step 10 of this document seems to confirm this. I guess what's default in Cisco implementation is not necessarily default by RFC

Best regards,

Peter