BGP Confederations - inner workings

I feel as if I have a pretty good understanding of what a confederation is and where it might be appliacble.  However, I don't understand the in-depth workings of BGP in relation to confederations.  What is the router actually doing?  What do the "bgp confederation indentifier" and "bgp confederation peers" actual do from a router perspective? Is it a completely seperate code-path in the handling of confederations or is there just additional fields and behaviors within a confederation?

 

Regards,

Micah

 

Comments

  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">





    Hi Micah,



    The point is to distinguish between true EBGP peers, and iBGP peers
    that are part of our global AS but in confederation.  In other words,
    the router knows that any neighbors you are peering with that have ASNs
    in the "confederation peers" command are really not in a different
    public AS, but just in a different subAS.  Likewise the
    "confederation-id" tells the router what it's public AS number is. 
    This affects how the AS-Path attribute is built and what the next-hop
    processing rules are.





    HTH,



    Brian McGahan, CCIE #8593 (R&S/SP/Security)

    [email protected]

     

    Internetwork Expert, Inc.

    http://www.INE.com

    Toll Free: 877-224-8987 x 705

    Outside US: 775-826-4344 x 705

    Online Community: http://www.IEOC.com

    CCIE Blog: http://blog.INE.com





    micah wrote:

    I feel as if I have a pretty good understanding of what a
    confederation is and where it might be appliacble.  However, I don't
    understand the in-depth workings of BGP in relation to confederations. 
    What is the router actually doing?  What do the "bgp confederation
    indentifier" and "bgp confederation peers" actual do from a router
    perspective? Is it a completely seperate code-path in the handling of
    confederations or is there just additional fields and behaviors within
    a confederation?

     

    Regards,

    Micah

     





    --

    View this message online at: http://ieoc.com/forums/p/8158/37399.aspx#37399









  • Hi Brian,

     

    Thanks for the reply.  It's a good start :-)

    Let me see if I can better articulate what I'm actually interested in from a technology perspective.

    1) From an eBGP perspective there is really no way to tell that the peer is or is not in a confederation.  True? I would suspect so since confederations are designed to scale large iBGPs ISP environement, correct?

    2) From an iBGP sub-AS perspective, you still need to fully mesh the peers in the same sub-as correct? If not, you could in theory use route-reflectors.

    3) When a sub-AS communicates with another sub-AS is this treated as an eBGP peering but with the additional field of confed-id?  The updates look like they come from the actual configured AS number "router bgp XXX" and not the confederation-id AS.  Correct? 

     

    Thanks again,

    Micah

     

     

  • 1. Correct. Because the AS is replaced with the confederation ID which
    would have global significance, but no other meaning to anyone else.

    2. Correct as well. The maximum number of peers in a single sub-as
    without full-mesh or RR would be 2 (just like "normal" AS design)

    3. Correct. Because the "confederation-peers" command tells us who to
    trust. The line is still somewhat blurred. Even though it's
    TECHNICALLY an ebgp peering, some things don't change (such as next-hop
    is preserved which may make for some difficulties).

    HTH,




    *Scott Morris*, CCIE/x4/ (R&S/ISP-Dial/Security/Service Provider) #4713,

    JNCIE-M #153, JNCIS-ER, CISSP, et al.

    JNCI-M, JNCI-ER

    [email protected]


    Internetwork Expert, Inc.

    http://www.InternetworkExpert.com

    Toll Free: 877-224-8987

    Outside US: 775-826-4344


    Knowledge is power.

    Power corrupts.

    Study hard and be Eeeeviiiil......



    micah wrote:
    >
    > Hi Brian,
    >
    >
    >
    > Thanks for the reply. It's a good start :-)
    >
    > Let me see if I can better articulate what I'm actually interested in
    > from a technology perspective.
    >
    > 1) From an eBGP perspective there is really no way to tell that the
    > peer is or is not in a confederation. True? I would suspect so since
    > confederations are designed to scale large iBGPs ISP environement,
    > correct?
    >
    > 2) From an iBGP sub-AS perspective, you still need to fully mesh the
    > peers in the same sub-as correct? If not, you could in theory use
    > route-reflectors.
    >
    > 3) When a sub-AS communicates with another sub-AS is this treated as
    > an eBGP peering but with the additional field of confed-id? The
    > updates look like they come from the actual configured AS number
    > "router bgp XXX" and not the confederation-id AS. Correct?
    >
    >
    >
    > Thanks again,
    >
    > Micah
    >
    >
    >
    >
    >
    >
    >
    >
    > 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
  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">





    Hi Micah,



        Yes for 1 & 2, and the key behavioral difference is #3.  The
    BGP process internally knows the difference between a "true EBGP peer"
    and a "confederation EBGP peer".  With a true EBGP peer, advertisements
    sent to them are prepended with the public AS number as defined by the
    confed-ID as part of the AS_PATH attribute, and have the next-hop
    modified to the local update source.  With a confederation EBGP peer,
    advertisements sent to them are prepended with the Sub-AS number as
    part of the AS_CONFED_SET, which is a combination of the normal AS_PATH
    and the Sub ASNs of the other members of the confederation that the
    prefix passed through.  Additionally, when updates are sent to the
    confederation EBGP peers, the next-hop value is not updated.



        For the most detail on the behind the scenes implementation of this
    visit RFC 5065, Autonomous System Confederations for BGP, at
    http://www.rfc-editor.org/rfc/rfc5065.txt.



    Also if you haven't already read through Routing TCP/IP Volume 2 and
    Internet Routing Architectures, those are great texts on how BGP works
    on Cisco IOS.





    HTH,





    Brian McGahan, CCIE #8593 (R&S/SP/Security)

    [email protected]

     

    Internetwork Expert, Inc.

    http://www.INE.com

    Toll Free: 877-224-8987 x 705

    Outside US: 775-826-4344 x 705

    Online Community: http://www.IEOC.com

    CCIE Blog: http://blog.INE.com





    micah wrote:

    Hi Brian,

     

    Thanks for the reply.  It's a good start :-)

    Let me see if I can better articulate what I'm actually interested
    in from a technology perspective.

    1) From an eBGP perspective there is really no way to tell that
    the peer is or is not in a confederation.  True? I would suspect so
    since confederations are designed to scale large iBGPs ISP
    environement, correct?

    2) From an iBGP sub-AS perspective, you still need to fully mesh
    the peers in the same sub-as correct? If not, you could in theory use
    route-reflectors.

    3) When a sub-AS communicates with another sub-AS is this treated
    as an eBGP peering but with the additional field of confed-id?  The
    updates look like they come from the actual configured AS number
    "router bgp XXX" and not the confederation-id AS.  Correct? 

     

    Thanks again,

    Micah

     

     





    --

    View this message online at: http://ieoc.com/forums/p/8158/37421.aspx#37421







  • Brian / Scott,

     

    Thank you both for the replies.  I think I have it nailed down now.  Thanks for clarifying the behavior.  It was that special confed eBGP case that screwed me up I believe.  I'll also read the RFC 3 or 4 times to see if I can pickup the nuances.

    One last question on the topic.  Are there versions of IOS where "next-hop-self" across a confederation eBGP peering doesn't have any affect?

    Thanks again,
    Micah

     

Sign In or Register to comment.