BGP confederations and lone router

[Sh HH]

Hi,

Assume there is a big AS, say 100, with 2 confederations in it, say 65001 and 65002. The AS also has another router, say router A.

Router A does NOT belong to either confederations but is still a part of the entire AS 100.

What is clear is that between border routers in the confederations, cbgp(confederation bgp) runs, not ibgp.

My question is, if i want to connect the lone router A to confederations, what kind of bgp(ibgp,ebgp or cbgp) should run between the border router in confederation 65001(or 65002) and the lone router A that does not belong to either confederations and why. Are there any constraints/design limitations that disqualify running one kind of bgp between confederation border router and the lone router A.

Thanks

[Giuseppe Larosa]

Hello Sh HH,

the BGP confederations introduce a distinct and additional BGP attribute that represents the confederations AS path.

In this way the main AS path attribute is left unchanged and can be modified adding the true main AS number on true eBGP sessions.

In this way the mini AS numbers of BGP confederations are never exposed outside the confederations.

The BGP configuration to the lone router is that of an eBGP session but the lone router remote-as number is equal to that of the confederation identifier the main AS number, so this  is actually an iBGP session.

The lone router will see an iBGP session both in configuration and in practical effects.

To be noted being the session considered iBGP the lone router may not be able to learn all the routes that are available within the confederations for the iBGP split horizon rule.

I think in real world once the use of BGP confederations is introduced no lone routers are used.

Hope to help

Giuseppe

[cadet alain]

Hi Giuseppe,

I just labbed it in GNS3 and it didn't work. Could you try it too and show me a working config.

I really think that this is not possible and that there can't be any router outside of a subAS in such a case because the confed members will only strip the subAS when doing eBGP. What is your opinion about this?

Regards.

Alain

Don't forget to rate helpful posts.

[Giuseppe Larosa]

Hello Alain,

I have never tried this too. Let consider my reasoning a "just in theory" thought

Best Regards

Giuseppe

[Sh HH]

Thanks for the reply.

I think running either ibgp or ebgp will cause a problem and there is no faultless solution in this case.

If ebgp is enabled on the lone router:

1. A new confederation AS has to be created just for the lone router. The lone router should be included in this new confederation and only then ebgp can be enabled, which would make the lone router a confederation border router. So, this solution requires configuration overhead.

2. Assume the other confederation(65002) was not a confederation but a route reflector cluster. This would really  complicate the situation. Even though I have a RR cluster, as i have to run ebgp, I have to include the RR in a confederation. So having atleast one confederation in the AS would mean there can be no lone routers or RR's in the AS and all these have to be included in a confederation for things to work. So, confederations as a whole would be a limiting concept in bgp because RR's dont have this problem. When RR's connect to lone router, the lone router need not be in any cluster and things will still work.

If ibgp is enabled on the lone router:

1. The local confederation AS numbers must be removed from the AS path when confederation border router advertises the routes to lone router as only confederations have the knowledege of which AS numbers to strip. This can be problematic. If the lone router is connected to another confederation, it will see the AS path from the lone router to be shorter and use it creating loops.

2. There has to be a mesh between confederations in the AS and the lone router(ibgp full mesh requirement), creating configuration overhead.

If there can be no concept of lone routers in confederations, this is constraining. Geographical limits may push an ISP to have a lone router.

Giuseppe,

"the BGP confederations introduce a distinct and additional BGP attribute that represents the confederations AS path."

Can you clarify this please. I thought no new attributes are required for confederations. The local AS numbers are modified in AS_CONFED_* segments, but again these are components of the AS_PATH attribute and not a new one.

[Giuseppe Larosa]

Hello Sh HH,

BGP confederations use a separate AS path attribute. This makes easy the stripping of the mini AS at the ISP border.

From book CCIE practical studies volume II

>> When confederations are in use, one of two new AS_PATH attributes apply. The

AS_CONFED_SET and AS_CONFED_SEQUENCE AS_PATH path segment types are used to

describe the path that a route followed as it passed through confederations. The

AS_CONFED_SET segment type is an unordered list of sub-autonomous systems that a route has

traversed, similar to the AS_SET segment type, and the AS_CONFED_SEQUENCE segment type

contains an ordered list of member ASs that a route travels through. When updates are sent to

external peers, the AS_CONFED_SET and AS_CONFED_SEQUENCE path segment types are

replaced with the confederation ID belonging to the parent AS.

Hope to help

Giuseppe