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.
iBGP Multipath Load Sharing Reference
When there are multiple border BGP routers having reachability information heard over eBGP, if no local
policy is applied, the border routers will choose their eBGP paths as best. They advertise that bestpath inside
the ISP network. For a core router, there can be multiple paths to the same destination, but it will select only
one path as best and use that path for forwarding. iBGP multipath load sharing adds the ability to enable load
sharing among multiple equi-distant paths. Configuring multiple iBGP best paths enables a router to evenly
share the traffic destined for a particular site. The iBGP Multipath Load Sharing feature functions similarly
in a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) with a service provider backbone.
For multiple paths to the same destination to be considered as multipaths, the following criteria must be met:
•
All attributes must be the same. The attributes include weight, local preference, autonomous system
path (entire attribute and not just length), origin code, Multi Exit Discriminator (MED), and Interior
Gateway Protocol (iGP) distance.
•
The next hop router for each multipath must be different.
Even if the criteria are met and multiple paths are considered multipaths, the BGP speaking router designates
one of the multipaths as the best path and advertises this best path to its neighbors.
BGP Configuration Guide for Cisco NCS 5500 Series Routers, IOS XR Release 6.2.x
141
Implementing BGP
Information about Implementing BGP
To Next Page
Loading...
Need help?
General
