TS Lab 10 ticket 5

Hi,

On the SG, it says that

"SW2 is a RR client, and therefore does not have the complete routing information. In order for SW2 to obtain all eBGP prefixes, it has to be peered with the edge eBGP explicitly"


R6 is the RR
SW2, SW4, SW1, and SW3 are the RR client and edge eBGP routers

I thought the RR will advertised the all of the routes received from all of its eBGP edge to all of its client.


I never heard this RR "limitation" before.

Qs:
1. Is this correct?
2. Where can I find a cisco doco on this?

thx
dsu

Comments

  • peetypeety ✭✭✭







    "SW2 is a RR client, and therefore does not have the complete routing information. In order for SW2 to obtain all eBGP prefixes, it has to be peered with the edge eBGP explicitly"



    R6 is the RR

    SW2, SW4, SW1, and SW3 are the RR client and edge eBGP routers



    I thought the RR will advertised the all of the routes received from all of its eBGP edge to all of its client.



    I never heard this RR "limitation" before.


    Qs:
    1. Is this correct?

    2. Where can I find a cisco doco on this?


    This is correct.  BGP-speaking routers perform a best-path calculation to decide what routes to place into their BGP RIB and onwards into the IP RIB.  As such, they can only propagate those paths that win the best-path calculation.  If the edge BGP router has some paths that aren't good enough to be considered best path on the RR, they aren't passed to the other clients.

    Check Internet Routing Architectures, Second Edition, page 264 and on.

    Had this been fully meshed, each router would get the list of best paths from every edge.  With RRs, each router only gets the RR's view of the world; non-best-paths are not carried along.  As such, the RRCs have every route, but only one IBGP path to use (plus an EBGP path, if they have a local EBGP connection), so the only way to have 2 or more paths to choose amongst on a particular RRC is to have 1 or more EBGP connections on said router.

    (In the bigger picture, the fix is to use RRs in a hybrid manner to consolidate inter-POP routing decisions: put one or two RRs in each POP, fully mesh the RRs, then within each POP do a full BGP mesh, and enable 'no bgp client-to-client reflection' on the RRs.  As such, the RR will only reflect inter-POP routes to intra-POP clients, and the intra-POP neighbors will individually share their paths with intra-POP neighbors. I'm a big fan of this, as long as the routers can all handle the full table; without consistent full-table, the filtering gets challenging.)

  • Thanks peety,

    I missed out that info but I guess I missed out the fundamental understanding that every BGP client will only choose 1 best path and adv it to its peer.

    After some reading, "bgp additional-path" will do the trick but I'll lab this later.

    Your solution,  do you have reference for it? knowing additional ways to accomplish the same thing would be just like what BGP created for.


    thx
    dsu



    On 11/05/2013, at 4:06 AM, peety <[email protected]> wrote:

    imageDavid Sudjiman:






    "SW2 is a RR client, and therefore does not have the complete routing information. In order for SW2 to obtain all eBGP prefixes, it has to be peered with the edge eBGP explicitly"



    R6 is the RR

    SW2, SW4, SW1, and SW3 are the RR client and edge eBGP routers



    I thought the RR will advertised the all of the routes received from all of its eBGP edge to all of its client.



    I never heard this RR "limitation" before.


    Qs:
    1. Is this correct?

    2. Where can I find a cisco doco on this?


    This is correct.  BGP-speaking routers perform a best-path calculation to decide what routes to place into their BGP RIB and onwards into the IP RIB.  As such, they can only propagate those paths that win the best-path calculation.  If the edge BGP router has some paths that aren't good enough to be considered best path on the RR, they aren't passed to the other clients.

    Check Internet Routing Architectures, Second Edition, page 264 and on.

    Had this been fully meshed, each router would get the list of best paths from every edge.  With RRs, each router only gets the RR's view of the world; non-best-paths are not carried along.  As such, the RRCs have every route, but only one IBGP path to use (plus an EBGP path, if they have a local EBGP connection), so the only way to have 2 or more paths to choose amongst on a particular RRC is to have 1 or more EBGP connections on said router.

    (In the bigger picture, the fix is to use RRs in a hybrid manner to consolidate inter-POP routing decisions: put one or two RRs in each POP, fully mesh the RRs, then within each POP do a full BGP mesh, and enable 'no bgp client-to-client reflection' on the RRs.  As such, the RR will only reflect inter-POP routes to intra-POP clients, and the intra-POP neighbors will individually share their paths with intra-POP neighbors. I'm a big fan of this, as long as the routers can all handle the full table; without consistent full-table, the filtering gets challenging.)




    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • peetypeety ✭✭✭


    I missed out that info but I guess I missed out the fundamental understanding that every BGP client will only choose 1 best path and adv it to its peer.



    You might want to review the path selection algorithm.  It's used to pick ONE winner.  If you then look at the multipath specifics, those are used to add additional next-hops to the FIB, but they don't actually give the BGP RIB more paths.  At a higher level, BGP version 4 simply doesn't allow one router to advertise multiple paths for a prefix - new paths are considered to overwrite the old ones.


    After some reading, "bgp additional-path" will do the trick but I'll lab this later.

    It might, but if the SG says to add a direct neighbor, wouldn't that be best since it's in the SG?


    Your solution,  do you have reference for it? knowing additional ways to accomplish the same thing would be just like what BGP created for.

    I think I somehow pulled it from Danny McPherson's work on MED Oscillation, contained in RFC 3345.  See section 3.2.5 for my recommendation above: http://tools.ietf.org/html/rfc3345

Sign In or Register to comment.