BGP Confederation Configuration:

Reduces full mesh iBGP requirement by splitting AS into smaller Sub-ASes

--Inside Sub-AS full mesh or RR requirement remains

--Between Sub-AS acts like EBGP

Devices outside the confederation do not know about the internal structure

--Aub-AS numbers asre stripped from advertisements to True EBGP peers

Typically uses ASNs in private range (64512 – 65535)

------------------------

Essentially BGP Confederations are when we take the entire AS and split it into smaller more manageable ASes.

This is similar to Clusters in route reflection but based on the normal loop prevention mechanisms of EBGP –

The loop prevention is based on the AS PATH.

All configuration inside the SUB-AS will still need a full mesh of peering’s or route reflection. The change in confederation is going to be for any updates between the SUB-ASes, in what is now known as the confederation EBGP peers.

The Sub AS numbers will be stripped form advertisements for routers outside the AS or not part of the configuration.

BGP Confederation Configuration:

Enable the BGP process

# router bgp (SUB-AS)

Specify the main AS number

#bgp confederation-id (main-AS)

Specify other sub-ASes the you peer with

#bgp confederation-peers (sub-as1 sub-as-2, etc)

--not all Sub-ASes, just those directly peered with.

Note: in order to tell the difference between a true EBGP peer and a confederation EBGP peer. Any routers on the edge of the SUB-AS,

Will need to specify which of its neighbors are confederation peers and which are true EBGP peers.

For this we would use the #bgp confederation-peers (sub-as1 sub-as-2, etc)

Command – it only needs to be configured on the SUB-AS edge and only for the SUB as systems were directly peering with.

We will need to use the Private range for the Internal SUB-ASes and they cannot overlap. When Sub-ASes exchange information, they will use the SUB-AS number prepended to the end of the routes.

One thing to note about Confederation ebgp peers – Since theses technically count as EBGP peering, the TTL will be sent to 1 be default.

 Note – if you require full mesh – you can configure route reflectors inside your SUB-ASes.

Once all peering are up – we would verify peering. We should also expect to see – inside the SUB-ASes ONLY – the Sub-as. If peering with other ebgp neighbor we would not want to see the Sub-as in the path.

If we are traversing though sub-ases we would see the sub-as prepended and in parentheses ex: (65000) (65146) 100 200, etc.

Note: there are special configurations related only to the confederation designs and also to the community attributes – specific to confederations.

These are:

# bgp bestpath med confed – which means, between our confederation peers we could compare the MED to figure out which path to choose.

We could also create a route-map the set the community attribute.

For example – set community the is the local-as (also sometimes know as # no export sub-confed). This means that prefixes in the local AS will not go out of the sub-as …

We can also set the command “no-export”, this will essential send the prefix to our sub-as EBGP peers but not our true EBGP peer.

This just depends where we want the prefix to be confined to – the local-as or the entire sub-as