Skip navigation
Cisco Learning Home > Certifications > Routing & Switching (CCNP) > Discussions

_Communities

This Question is Not Answered 1 Correct Answer available (4 pts) 2 Helpful Answers available (2 pts)
13966 Views 22 Replies Latest reply: Jan 2, 2012 5:39 AM by Flanger RSS 1 2 Previous Next

Currently Being Moderated

BGP metrics and Administrative Distance

Jan 19, 2011 12:07 PM

Harris 104 posts since
Mar 17, 2009

Hello,

 

I see that eBGP and iBGP are considered two different routing protocols since a different Administrative Distance is used for eBGP and iBGP routes (20 and 200). I also know that a router to select the best route between two routes that match a network destination, first it looks for the route with the longest prefix, then for the route with the smaller AD and finally for the route with the smaller metric. This means that if we have one eBGP route and one iBGP route for the same destination, with the same mask, the eBGP route will always be chosen, regardless of the BGP metrics (e.g. AS path, Weight. local preference, e.t.c.) of the two routes?

 

Cheers,

Harris

  • Brian 2,971 posts since
    Aug 17, 2009
    Currently Being Moderated
    1. Jan 19, 2011 12:37 PM (in response to Harris)
    Re: BGP metrics and Administrative Distance

    Aloha Harris,

     

    AD is the first criterion to determin which routing protocol to use when you learn the route information for a destination from two different routing protocols.  The routing protocol with the lower AD is added to the routing table.

     

    The router then chooses the longest prefix match amoung the routes to the same destination.  Then, if more than one route with same prefix, selects the one with the lower metric.

     

    HTH

  • Keith Barker - CCIE RS/Security, CISSP 5,351 posts since
    Jul 3, 2009
    Currently Being Moderated
    2. Jan 19, 2011 2:15 PM (in response to Harris)
    Re: BGP metrics and Administrative Distance

    OSPF and RIP contest.png

     

    If R1 and R3 both advertised the exact same network of 55.0.0.0/8, R2 would only put 1 in the routing table, because they come from different routing protocols, with different ADs.

     

    It's decision would be based on the route to 55.0.0.0/8 based on the routing protocol that has the lowest AD, which would be OSPF in this example.

     

    The route to 55.0.0.0/8 using R1 as the next hop would never make it into the routing table of R2.

     

    Once a packet needs to be forwarded, the router's check their routing tables for the longest match, and then forward based on that information.

     

    Best wishes,

     

    Keith

  • Addy 105 posts since
    Oct 21, 2009
    Currently Being Moderated
    3. Jan 20, 2011 7:10 AM (in response to Brian)
    Re: BGP metrics and Administrative Distance

    Hi Brian,

     

    Isn't longest prefix match the first criterion for route selection?

    I thought that a /26 route advertised by RIP(AD:120) would be preferred over a /24 route advertised by OSPF(AD:110) despite OSPF having the lower AD of the two. At least the BSCI book by Diane Teare seems to sugget so (If I remember correctly).

  • Addy 105 posts since
    Oct 21, 2009
    Currently Being Moderated
    4. Jan 20, 2011 7:26 AM (in response to Brian)
    Re: BGP metrics and Administrative Distance

    Oops, I submit that I was wrong, or partially wrong...or whatever!

    I just remembered that routes to the same destination network but with different prefix length are considered different destinations. So technically, they won't be the same destination. If the routes are indeed to the same destination, they'd have equal prefix lengths also in which case lower AD will be chosen.

    I hope I'm correct this time.
    Apologies for the previous post.

  • Brian 2,971 posts since
    Aug 17, 2009
    Currently Being Moderated
    5. Jan 20, 2011 11:40 AM (in response to Addy)
    Re: BGP metrics and Administrative Distance

    Aloha Addy,

     

    The AD is really not part of the roting process, it occurs before the routing process.  When a router learns of a route to a destination from two sources say EIGRP and RIP, the router will install only one into the routing table.  The one which gets installed is the route with the lower AD.  Since EIGRP AD = 90 and RIP AD = 120, the EIGRP route gets installed in the routing table.

     

    The routimg process occurs once these routes have been added to the routing table.  When a packet comes in the router matches longest prefix to the destination.  I was in "error" in my previous post as I stated, "The router then chooses the longest prefix match amoung the routes to the same destination."    I included the word "same" here and that is incorrect.  Remove the word "same".

     

    Should read as, ""The router then chooses the longest prefix match amoung the routes to the destination."

     

    Once the longest match is made, if there two or more entries for the same prefix to the destination, the one with the lowest metric wins.

     

    Sorry, if I confused you with my first post.

     

    HTH

  • Brian 2,971 posts since
    Aug 17, 2009
    Currently Being Moderated
    7. Jan 20, 2011 3:53 PM (in response to Harris)
    Re: BGP metrics and Administrative Distance

    No AD is occirs before the actuall routing process as it is what determines which "routes" will be added to the routing table.

     

    HTH

  • Brian 2,971 posts since
    Aug 17, 2009
    Currently Being Moderated
    8. Jan 20, 2011 9:54 PM (in response to Harris)
    Re: BGP metrics and Administrative Distance

    In response to post #6.

     

    Question:

     

    "If we have two routes for the exact same destination with the same prefix, the first route learned from eBGP (AD 20) and the second route learned from iBGP (AD 200), then the eBGP route will be used (because of the smaller AD) even if the BGP metrics (e.g. AS Path)  of the iBGP route are better?"

     

    The eBGP route is preferred, but not because of AD.  BGP rules state, that the NEXT_HOP PA must be valid for a route to be considered the BEST path.  In the case above, by default, when sending to an eBGP peer the NEXT_HOP PA is changed to an IP address on the advertising eBGP router.  When sending to an iBGP peer, the default action is to NOT change the NEX_HOP PA.  Basically leaving the NEX_HOP PA unchanged.  Because of these default behaviors the iBGP route is unreachable and therefore not a valid route to be considered BEST.  Result the eBGP route is BEST.

     

    If you were to change the NEX_HOP PA for the iBGP to be "next-hop-self" then the iBGP route will be preferred providing the AS_PATH was lower.

     

    There is actually a very good example of this in the CCIE R&S OCG, 4th Edition, by Wendel Odom.  The example can be found in Chapter 10, beginning on page 393.

     

    The actual BGP decision process is pretty lengthy butcan be reduced to a four-step process as follows:

     

    1. choose the shortest AS_PATH.

     

    2. If AS_PATH is the same, prefer an eBGP learned route over an iBGP learned route.

     

    3. If the best path has not been chosen, choose the IGP route with the lowest metric to the NEXT_HOP for the route.

     

    4. If the IGP metrics tie, choose the iBGP learned route with the lowest BGP RID amoung advertising routers.

     

    Reference:  CCIE R&S OCG, 4th Edition, by Wendell Odom, et al.

     

    HTH

  • kddwivedi 3 posts since
    Sep 8, 2009
    Currently Being Moderated
    9. Jan 23, 2011 10:42 PM (in response to Harris)
    Re: BGP metrics and Administrative Distance

    Dear Harris,

     

    If a route is learned from iBGP, the prefix should be present in the same AS. It, therefore, cannot be learnt from eBGP.

     

    Similarly, if a route is learned from eBGP, the destination is in another AS and cannot be learnt via iBGP.

  • Brian 2,971 posts since
    Aug 17, 2009
    Currently Being Moderated
    10. Jan 24, 2011 3:43 AM (in response to kddwivedi)
    Re: BGP metrics and Administrative Distance

    Aloha kiddwivedi,

     

    In response to your post #9, your statements are incorrect.  I suggest you give the CCIE R&S OCG a read.  In particular Chapter 10.  In addition, take a look at the attached PDF.  R1 will learn a route to the 10.1.56.0/24 subnet through its eBGP peer with R3 and through its iBGP peer with R2.  As I explained in my previous post, the iBGP route is invalid due to the default behavior of the NEXT_HOP path attribute.  However, you can change this default behavior using the next-hop-self command.

     

    HTH

    Attachments:
  • daniel.rodrig 11 posts since
    Jan 25, 2010
    Currently Being Moderated
    11. Jan 24, 2011 8:24 AM (in response to Harris)
    Re: BGP metrics and Administrative Distance

    Hi,

     

    kddwivedi, you can actually have the same prefix learned from a eBGP peer and iBGP, it’s just a matter of doing the redistribution/advertisement on the correct place to have that scenario.

     

    If the same prefix is learned from an external AS and at the same time from and iBGP neighbor, the router is going to chose the path learned from the eBGP neighbor (external AS).

     

     

    So, answering your question. IF you happened to have an eBGP neighbor relationship with a device that is advertising the same prefix as a same AS neighbor, the device will put as a BGP best route the one learned from the eBGP.

     

    Daniel,

    http://blog.initialdraft.com/

  • kddwivedi 3 posts since
    Sep 8, 2009
    Currently Being Moderated
    12. Jan 24, 2011 4:36 AM (in response to Harris)
    Re: BGP metrics and Administrative Distance

    Hi Brian & Daniel,

     

    May be my post was too brief and did not follow the language of a book. But, what I meant is as below -

     

    Suppose a destination route is present in a different AS, then irrespective of it being learnt from its iBGP or eBGP peer, it will always be an eBGP destination with an AD of 20. (I hope this answers Harris's question).

     

    And if it is present in the same AS where the router in question is located, it will be a design flaw if it is learnt as an eBGP destination. It should be learnt through IGP running in that AS.

     

    If an eBGP destination is learnt from an eBGP neighbor and also from an iBGP neighbor, using BGP attributes, the route learnt from iBGP may be preferred over that learnt from eBGP. However, it will always be installed as eBGP destination with AD of 20.

  • Brian 2,971 posts since
    Aug 17, 2009
    Currently Being Moderated
    13. Jan 24, 2011 5:29 AM (in response to kddwivedi)
    Re: BGP metrics and Administrative Distance

    I think you are getting confused.  try reading the chapter I suggested.  As this explains the scenario you are referring to in regards to learning a route via eBGP and iBGP.   The AD has nothing to do with the selection in scenario.

     

    HTH

  • Brian 2,971 posts since
    Aug 17, 2009
    Currently Being Moderated
    14. Jan 24, 2011 7:09 AM (in response to Brian)
    Re: BGP metrics and Administrative Distance

    All,

     

    Here are the router outputs for the PDF I attached in post #10.   The outputs display the results of what I was talking about in Post #8 in regard to the NEXT_HOP path attribute.

     

    The first set of outputs is with R1 and R2 forming an iBGP peer with the default NEXT_HOP path attribute behavior.  pay particular attention to the highlighted areas in RED.

     

    RT2#sh ip bgp 10.1.3.0
    BGP routing table entry for 10.1.3.0/24, version 36
    Paths: (2 available, best #1, table Default-IP-Routing-Table)
    Flag: 0x4840
      Advertised to update-groups:
         2
      100
        10.1.24.4 from 10.1.24.4 (10.1.4.4)
          Origin IGP, metric 460800, localpref 100, valid, external, best
      100
        10.1.13.3 (inaccessible) from 10.1.12.1 (10.1.1.1)
          Origin IGP, metric 0, localpref 100, valid, internal
    RT2#sh ip bgp 10.1.35.0
    BGP routing table entry for 10.1.35.0/24, version 35
    Paths: (2 available, best #2, table Default-IP-Routing-Table)
    Flag: 0x4840
      Advertised to update-groups:
         2
      100
        10.1.13.3 (inaccessible) from 10.1.12.1 (10.1.1.1)
          Origin IGP, metric 0, localpref 100, valid, internal
      100
        10.1.24.4 from 10.1.24.4 (10.1.4.4)
          Origin IGP, metric 332800, localpref 100, valid, external, best
    RT2#sh ip rou
    Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
           E1 - OSPF external type 1, E2 - OSPF external type 2
           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
           ia - IS-IS inter area, * - candidate default, U - per-user static route
           o - ODR, P - periodic downloaded static route

    Gateway of last resort is not set

         10.0.0.0/24 is subnetted, 11 subnets
    C       10.1.12.0 is directly connected, FastEthernet0/0
    B       10.1.3.0 [20/460800] via 10.1.24.4, 00:01:31
    C       10.1.2.0 is directly connected, Loopback0
    O       10.1.1.0 [110/11] via 10.1.12.1, 01:59:36, FastEthernet0/0
    B       10.1.6.0 [20/409600] via 10.1.24.4, 00:16:03
    B       10.1.5.0 [20/435200] via 10.1.24.4, 00:01:31
    B       10.1.4.0 [20/0] via 10.1.24.4, 00:16:03
    C       10.1.24.0 is directly connected, Serial0/0
    B       10.1.46.0 [20/0] via 10.1.24.4, 00:16:03
    B       10.1.35.0 [20/332800] via 10.1.24.4, 00:01:31
    B       10.1.56.0 [20/307200] via 10.1.24.4, 00:15:33
    RT2#

     

    Notice the route for 10.1.3.0 goes through the eBGP peer R4.  The path from R2 is R4-R6-R5-R3.  Looking at the diagram this is not the shortest path to this destination.  Also, IP address 10.1.13.3 shows as "inaccessible" due to the NEXT_HOP path attribute being unchanged when R1 sends the update to R2.  The NLRI to reach this IP address is invalid and the path is not selected as the best path.  Therefore, the route is not added to the IP routing table.

     

    Likewise, the route for 10.1.35.0 goes through the eBGP peer R4.  The path from R2 is R4-R6-R5.  Looking at the diagram this is not the shortest path to this destination.  Again, the IP address 10.1.13.3 shows as "inaccessible" due to the NEXT_HOP path attribute being unchanged when R1 sends the update to R2.  The NLRI to reach this IP address is invalid and the path is not selected as the best path.  Therefore, the route is not added to the IP routing table.

     

    ++++++++++++++++++++

     

    Now, when I change the NEX_HOP path attribute on R1 for the iBGP peer with R2 using the "next-hop-self" command.  The next-hop changed from 10.1.13.3 (R3) to 10.1.12.1 (R1) and the NLRI information is now valid.  This is verifed in the following outputs in the highlighted areas in BLUE.

     

    RT2#sh ip bgp 10.1.3.0
    BGP routing table entry for 10.1.3.0/24, version 33
    Paths: (2 available, best #2, table Default-IP-Routing-Table)
    Flag: 0x4840
      Advertised to update-groups:
         1
      100
        10.1.24.4 from 10.1.24.4 (10.1.4.4)
          Origin IGP, metric 460800, localpref 100, valid, external
      100
        10.1.12.1 from 10.1.12.1 (10.1.1.1)
          Origin IGP, metric 0, localpref 100, valid, internal, best
    RT2#sh ip bgp 10.1.35.0
    BGP routing table entry for 10.1.35.0/24, version 38
    Paths: (2 available, best #1, table Default-IP-Routing-Table)
    Flag: 0x4840
      Advertised to update-groups:
         1
      100
        10.1.12.1 from 10.1.12.1 (10.1.1.1)
          Origin IGP, metric 0, localpref 100, valid, internal, best
      100
        10.1.24.4 from 10.1.24.4 (10.1.4.4)
          Origin IGP, metric 332800, localpref 100, valid, external
    RT2#sh ip rou
    Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
           E1 - OSPF external type 1, E2 - OSPF external type 2
           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
           ia - IS-IS inter area, * - candidate default, U - per-user static route
           o - ODR, P - periodic downloaded static route

    Gateway of last resort is not set

         10.0.0.0/24 is subnetted, 11 subnets
    C       10.1.12.0 is directly connected, FastEthernet0/0
    B       10.1.3.0 [200/0] via 10.1.12.1, 00:00:51
    C       10.1.2.0 is directly connected, Loopback0
    O       10.1.1.0 [110/11] via 10.1.12.1, 02:22:37, FastEthernet0/0
    B       10.1.6.0 [20/409600] via 10.1.24.4, 00:39:04
    B       10.1.5.0 [200/409600] via 10.1.12.1, 00:00:51
    B       10.1.4.0 [20/0] via 10.1.24.4, 00:39:04
    C       10.1.24.0 is directly connected, Serial0/0
    B       10.1.46.0 [20/0] via 10.1.24.4, 00:39:04
    B       10.1.35.0 [200/0] via 10.1.12.1, 00:00:51
    B       10.1.56.0 [20/307200] via 10.1.24.4, 00:38:33
    RT2#

     

    ++++++++++++++++++++

     

    As you can see the comparing of ADs (20 vs 200) between the eBGP route and iBGP route had nothing to do with which path was selected as the best path and added to the IP routing table.  In this case, it had to do with the metric.  R3 advertised a metric of zero for both routes, while R4 advertised a metric of 460800 and 332800 respectively.  As a result the path for these to subnets is now through the iBGP peer.  The path from R2 is now R1 - R3.

     

    RT3#sh ip bgp neighbors 10.1.13.1 advertised-routes
    BGP table version is 77, local router ID is 10.1.3.3
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale
    Origin codes: i - IGP, e - EGP, ? - incomplete

       Network          Next Hop            Metric LocPrf Weight Path
    *> 10.1.3.0/24      0.0.0.0                  0         32768 i
    *> 10.1.4.0/24      10.1.35.5           460800         32768 i
    *> 10.1.5.0/24      10.1.35.5           409600         32768 i
    *> 10.1.6.0/24      10.1.35.5           435200         32768 i
    *> 10.1.35.0/24     0.0.0.0                  0         32768 i
    *> 10.1.46.0/24     10.1.35.5           332800         32768 i
    *> 10.1.56.0/24     10.1.35.5           307200         32768 i

    Total number of prefixes 7
    RT3#

     

    +++++

     

    RT4#sh ip bgp nei 10.1.24.2 advertised-routes
    BGP table version is 69, local router ID is 10.1.4.4
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale
    Origin codes: i - IGP, e - EGP, ? - incomplete

       Network          Next Hop            Metric LocPrf Weight Path
    *> 10.1.3.0/24      10.1.46.6           460800         32768 i
    *> 10.1.4.0/24      0.0.0.0                  0         32768 i
    *> 10.1.5.0/24      10.1.46.6           435200         32768 i
    *> 10.1.6.0/24      10.1.46.6           409600         32768 i
    *> 10.1.35.0/24     10.1.46.6           332800         32768 i
    *> 10.1.46.0/24     0.0.0.0                  0         32768 i
    *> 10.1.56.0/24     10.1.46.6           307200         32768 i

    Total number of prefixes 7
    RT4#

     

    The example in the CCIE R&S OCG, had a third AS and therefore the AS_PATH was the deciding factor.

     

    HTH

    Attachments:

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)