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
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:
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
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
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:
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