Enterasys Networks X-PeditionTM manual Confederations

Overview

It is typical for a client cluster to have one route reflector and be identified by the reflector’s router ID. If you want greater redundancy and wish to avoid a single point of failure, you can add more than one reflector to a cluster. This is accomplished by configuring all cluster route reflectors with the 4-byte cluster ID so that a reflector can recognize updates from other reflectors within that cluster. All reflectors serving a cluster should be fully meshed and share identical client and non- client peer groups.

For clusters with multiple route reflectors, specify the cluster ID with the bgp cluster-idcommand

A route reflector’s clients, by default, need not be fully meshed so a client’s routes are reflected to others. But if clients are fully meshed, the route reflector need not reflect routes to clients and you can disable client-to-client route reflection with the no bgp client-to-client reflection command.

To avoid routing data loops, which may arise from reflected IBGP learned routes, the XSR supports the following options:

•Originator-ID, a 4-byte attribute created by a route reflector. This automatically generated attribute holds the router ID of the route’s originator in the local AS. If a misconfiguration causes routing data to bounce back to the originator, the data is dropped.

•Cluster-listis an optional BGP attribute configured with the bgp cluster-idcommand. It is a series of cluster IDs the route has passed. When a route reflector reflects a route from its clients to non-client peers, it appends the local cluster ID to the cluster-list, and if empty, it creates a new ID. With this attribute, a reflector can determine if routing data is mistakenly looped back to the same cluster. If the local cluster ID is found in the cluster-list, the advertisement is dropped.

•Set clauses employed in outbound route maps change attributes and risk routing loops. The XSR avoids this by ignoring these set clauses for routes reflected to IBGP peers.

Confederations

Confederations are another alternative to the fully meshed requirement within an AS, as shown in Figure 6-12. This is accomplished by dividing an AS with a host of BGP speakers into smaller domains or confederations and the peers in different AS’s swapping routing data as if they were EBGP peers. By subdividing a larger AS, the number of intra-domain BGP connections are greatly reduced but the network still appears as a single AS to its external EBGP peers.

Confederations require a confederation identifier (an AS number) for what will appear as a single AS to exterior networks; it is set with the bgp confederation identifier command. Neighbors from other AS’s within the confederation are marked as special EBGP peers with the bgp confederation peers <AS#> command.

For an example, refer to “Configuring BGP Confederations” on page 6-24.Alternatively, you can also downsize the IBGP mesh with route reflectors, described on page 6-19.

6-20 Configuring the Border Gateway Protocol