13.4.10 Confederations

(1) Concept of confederation and flow of routing information

A confederation is formed by dividing the AS into multiple member ASs. The BGP speakers in a member AS must be fully meshed as internal peers, and are handled as normal internal peers. Member ASs can be in peering relationships with one another, in the same way as with external peers. BGP speakers in different member ASs do not need to be fully meshed peers. In this way, deploying a confederation reduces the number of peers in an AS. In the Switch, the member ASs of a confederation in a peering relationship with one another are known as member AS peers.

The following figure shows the flow of routing information when the routers are configured in a confederation.

Routers 1, 2, and 3 constitute a member AS of the confederation. Routers 4, 5, and 6 constitute another member AS. Routing information from Router 8 is distributed by Router 2 to the other BGP speakers (Routers 1 and 3) in its member AS. Route information reported from Router 2 to Router 1 is distributed to Router 4 in the other member AS, and from there to the other BGP speakers (Routers 5 and 6) in that member AS. In this way, the routing information is distributed to all BGP speakers in the AS.

(2) Routing in a Confederation Configuration

When routers are configured in a confederation, the route selection process differs somewhat from a non-confederation topology because of the addition of another peer type (member AS peer). In the usual type of configuration, a route learned by an external peer is preferred over a route learned by an internal peer. With a confederation, however, a route learned by an external peer is preferred over a route learned by a member AS peer, which is preferred over a route learned by an internal peer.

Route selection conditions in a confederation are listed in order of priority as follows:

1. Selects the route with the greatest weight.

2. Selects the route with the largest LOCAL_PREF attribute value.

3. Selects the route whose AS_PATH attribute has the smallest number of ASs.#1

   The AS_SET path type of the AS_PATH attribute is counted as one AS. The AS_CONFED_SEQUENCE and AS_CONFED_SET path types of the AS_PATH attribute are not included in the path length.

4. Selects by the ORIGIN attribute value, preferring IGP, EGP, and Incomplete, in that order.

5. Selects the route with the smallest MED attribute value.#2

   Route selection by MED attribute value applies only to redundant routes learned from the same neighboring AS. If bgp always-compare-med of the configuration command is set, duplicate routes learned from different neighboring AS are also enabled.

6. Selects a route learned by an external peer, a route learned by a member AS peer, or a route learned by an internal peer, in that order.

7. Selects the route with the closest next hop (the lowest metric for IGP route used when resolving the next hop).

8. Selects the route whose peer has the smallest BGP identifier (router ID). For a route having the ORIGINATOR_ID attribute, however, the ORIGINATOR_ID attribute values are compared instead of the peers' BGP identifiers.#3

   If the routes received from an external peer have different peer BGP identifiers (router IDs), the route selected at the previous step is used, and route selection based on peer BGP identifier and learning source peer address is skipped. When the configuration command bgp bestpath compare-routerid is set, routes can be selected using the peer BGP identifier (router ID) even when the peer BGP identifier (router ID) differs between routes received from external peers.

9. Selects the route with the smallest CLUSTER_LIST attribute length.#4

   When a route does not have the CLUSTER_LIST attribute, it is compared assuming a CLUSTER_LIST attribute length of 0.

10. Selects the route whose learning source peer has the smallest address.#3

    If the routes received from an external peer have different peer BGP identifiers (router IDs), the route selected at the previous step is used, and route selection based on peer BGP identifier and learning source peer address is skipped. When the configuration command bgp bestpath compare-routerid is set, routes can be selected using the peer BGP identifier (router ID) even when the peer BGP identifier (router ID) differs between routes received from external peers.

(3) Working with BGP Properties in a Confederation Configuration

When routers are configured in a confederation, BGP attributes are handled in much the same way as in a non-confederation topology. However, there are some differences in the way the AS_PATH and COMMUNITIES attributes operate. BGP attributes in member AS peers are handled in the same way as in internal peers.

(4) AS_PATH Attribute Handling in Confederation Configurations

When routing information is reported to a member AS peer in a confederation, the AS number of the local member AS is appended to the AS_CONFED_SEQUENCE path type of the AS_PATH attribute. When routing information is sent to another AS (external peer), the AS_CONFED_SEQUENCE path type is removed from the AS_PATH attribute and the local AS number is appended to the AS_SEQUENCE path type. In all other respects, the AS_PATH attribute is handled in the same way as in usual configurations.

The following figure shows how the AS_PATH attribute is handled.

In this figure, the routing information ASPATH: (AS_SEQUENCE) 100 is reported by AS100 to Router 1. Router 1 distributes the route to Router 2 (also a member AS of this confederation), appending its own member AS number (65001) to the AS_CONFED_SEQUENCE path type in the AS_PATH attribute. Router 2 receives the routing information as ASPATH: (AS_CONFED_SEQUENCE) 65001, (AS_SEQUENCE) 100. When distributing this routing information to AS300, Router 2 removes the AS_CONFED_SEQUENCE path type and appends its own AS number (200) to the AS_SEQUENCE path type.

(5) Working with COMMUNITIES Properties in a Confederation Configuration

In a confederation, the well-known communities defined in RFC 1997 are handled as follows. Other communities are handled in the usual manner.

The well-known communities defined in RFC1997 are listed under Wellnon Communities defined in the Tables 13-12 RFC1997. The advertised range of route information with COMMUNITIES attribute is shown in "Advertised range of route information with 13-27 COMMUNITIES attribute".