Confederations - Enterasys Security Router X-PeditionTM User Manual

Enterasys security router user's guide
Table of Contents

Advertisement

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
command
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
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-list is an optional BGP attribute configured with the
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
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
from other AS's within the confederation are marked as special EBGP peers with the
confederation peers <AS#>
For an example, refer to
also downsize the IBGP mesh with route reflectors, described on
6-20 Configuring the Border Gateway Protocol
6-12. This is accomplished by dividing an AS with a host of BGP speakers into smaller
"Configuring BGP Confederations"
no bgp client-to-client reflection
bgp confederation identifier
command.
bgp cluster-id
bgp cluster-id
command. It is
command. Neighbors
on page 6-24. Alternatively, you can
page
6-19.
bgp

Advertisement

Table of Contents
loading

This manual is also suitable for:

X-pedition xsr

Table of Contents