reflector would be configured with other route reflectors as nonclient peers (thus, all route reflectors are fully
meshed). The clients are configured to maintain iBGP sessions with only the route reflector in their cluster.
Usually, a cluster of clients has a single route reflector. In that case, the cluster is identified by the router ID
of the route reflector. To increase redundancy and avoid a single point of failure, a cluster might have more
than one route reflector. In this case, all route reflectors in the cluster must be configured with the cluster ID
so that a route reflector can recognize updates from route reflectors in the same cluster. All route reflectors
serving a cluster should be fully meshed and all of them should have identical sets of client and nonclient
peers.
By default, the clients of a route reflector are not required to be fully meshed and the routes from a client are
reflected to other clients. However, if the clients are fully meshed, the route reflector need not reflect routes
to clients.
As the iBGP learned routes are reflected, routing information may loop. The route reflector model has the
following mechanisms to avoid routing loops:
•
Originator ID is an optional, nontransitive BGP attribute. It is a 4-byte attributed created by a route
reflector. The attribute carries the router ID of the originator of the route in the local autonomous system.
Therefore, if a misconfiguration causes routing information to come back to the originator, the information
is ignored.
•
Cluster-list is an optional, nontransitive BGP attribute. It is a sequence of cluster IDs that the route has
passed. When a route reflector reflects a route from its clients to nonclient peers, and vice versa, it
appends the local cluster ID to the cluster-list. If the cluster-list is empty, a new cluster-list is created.
Using this attribute, a route reflector can identify if routing information is looped back to the same cluster
due to misconfiguration. If the local cluster ID is found in the cluster-list, the advertisement is ignored.
RPL - if prefix is-best-path/is-best-multipath
Border Gateway Protocol (BGP) routers receive multiple paths to the same destination. As a standard, by
default the BGP best path algorithm decides the best path to install in IP routing table. This is used for traffic
forwarding.
BGP assigns the first valid path as the current best path. It then compares the best path with the next path in
the list. This process continues, until BGP reaches the end of the list of valid paths. This contains all rules
used to determine the best path. When there are multiple paths for a given address prefix, BGP:
•
Selects one of the paths as the best path as per the best-path selection rules.
•
Installs the best path in its forwarding table. Each BGP speaker advertises only the best-path to its peers.
The advertisement rule of sending only the best path does not convey the full routing state of a destination,
present on a BGP speaker to its peers.
Note
After the BGP speaker receives a path from one of its peers; the path is used by the peer for forwarding packets.
All other peers receive the same path from this peer. This leads to a consistent routing in a BGP network. To
improve the link bandwidth utilization, most BGP implementations choose additional paths satisfy certain
conditions, as multi-path, and install them in the forwarding table. Incoming packets for such are load-balanced
across the best-path and the multi-path(s). You can install the paths in the forwarding table that are not
advertised to the peers. The RR route reflector finds out the best-path and multi-path. This way the route
Cisco ASR 9000 Series Aggregation Services Router Routing Configuration Guide, Release 5.3.x
51
Implementing BGP
RPL - if prefix is-best-path/is-best-multipath
To Next Page
Loading...
Need help?
General
