Odnośniki
- Indeks
- Case of Charles Dexter Ward
- MDM
- 422. Gerard Cindy Wszystko, co najwaśźniejsze
- Cherryh C.J. Gasnć ce sśÂośÂce Kesrith
- Janny Wurts The Cycle of Fire 3 Shadowfane
- 1. Irlandzki romans
- Balogh Mary Magiczne oczarowanie
- Kodeks Karny Skarbowy 2010
- Crowley_A Eight_Lectures_of_Yoga
- hdh_aristoteles_a_politica
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- slowacja.opx.pl
pointed at using the neighbor route-reflector-client command. The same RTD is the RR for its clients RTE
and RTF; RTG is a RR in a third cluster. Note that RTD, RTC and RTG are fully meshed but routers within a
cluster are not. When a route is received by a RR, it will do the following depending on the peer type:
1. Route from a non-client peer: reflect to all the clients within the cluster.
2. Route from a client peer: reflect to all the non-client peers and also to the client peers.
3. Route from an EBGP peer: send the update to all client and non-client peers.
The following is the relative BGP configuration of routers RTC, RTD and RTB:
RTC#
router bgp 100
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-reflector-client
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 4.4.4.4 remote-as 100
neighbor 8.8.8.8 remote-as 200
Cisco - BGP Case Studies
RTB#
router bgp 100
neighbor 3.3.3.3 remote-as 100
neighbor 12.12.12.12 remote-as 300
RTD#
router bgp 100
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
As the IBGP learned routes are reflected, it is possible to have the routing information loop. The Route
Reflector scheme has a few methods to avoid this:
1. Originator-id: this is an optional, non transitive BGP attribute that is four bytes long and is created
by a RR. This attribute will carry the router-id (RID) of the originator of the route in the local AS.
Thus, due to poor configuration, if the routing information comes back to the originator, it will be
ignored.
2. Cluster-list: this will be discussed in the next section.
Multiple RRs within a Cluster
Usually, a cluster of clients will have a single RR. In this case, the cluster will be identified by the router ID
of the RR. In order to increase redundancy and avoid single points of failure, a cluster might have more than
one RR. All RRs in the same cluster need to be configured with a 4 byte cluster-id so that a RR can
Cisco - BGP Case Studies
recognize updates from RRs in the same cluster.
A cluster-list is a sequence of cluster-ids that the route has passed. When a RR reflects a route from its
clients to non-clients outside of the cluster, it will append the local cluster-id to the cluster-list. If this
update has an empty cluster-list the RR will create one. Using this attribute, a RR can identify if the routing
information is looped back to the same cluster due to poor configuration. If the local cluster-id is found in the
cluster-list, the advertisement will be ignored.
In the above diagram, RTD, RTE, RTF and RTH belong to one cluster with both RTD and RTH being RRs
for the same cluster. Note the redundancy in that RTH has a fully meshed peering with all the RRs. In case
RTD goes down, RTH will take its place. The following are the configuration of RTH, RTD, RTF and RTC:
RTH#
router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
neighbor 9.9.9.9 remote-as 300
bgp route-reflector 10 (This is the cluster-id)
RTD#
router bgp 100
neighbor 10.10.10.10 remote-as 100
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 7.7.7.7 remote-as 100
neighbor 3.3.3.3 remote-as 100
neighbor 11.11.11.11 remote-as 400
bgp route-reflector 10 (This is the cluster-id)
RTF#
router bgp 100
neighbor 10.10.10.10 remote-as 100
neighbor 4.4.4.4 remote-as 100
neighbor 13.13.13.13 remote-as 500
RTC#
router bgp 100
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 route-reflector-client
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-reflector-client
neighbor 4.4.4.4 remote-as 100
neighbor 7.7.7.7 remote-as 100
neighbor 10.10.10.10 remote-as 100
neighbor 8.8.8.8 remote-as 200
Cisco - BGP Case Studies
Note that we did not need the cluster command for RTC because only one RR exists in that cluster.
An important thing to note, is that peer-groups were not used in the above configuration. If the clients inside
a cluster do not have direct IBGP peers among one another and they exchange updates through the RR,
peer-goups should not be used. If peer groups were to be configured, then a potential withdrawal to the
source of a route on the RR would be sent to all clients inside the cluster and could cause problems.
The router sub-command bgp client-to-client reflection is enabled by default on the RR. If BGP
client-to-client reflection were turned off on the RR and redundant BGP peering was made between the
clients, then using peer groups would be alright.
RR and Conventional BGP Speakers
It is normal in an AS to have BGP speakers that do not understand the concept of route reflectors. We will
call these routers conventional BGP speakers. The route reflector scheme will allow such conventional BGP
speakers to coexist. These routers could be either members of a client group or a non-client group. This
would allow easy and gradual migration from the current IBGP model to the route reflector model. One could
start creating clusters by configuring a single router as RR and making other RRs and their clients normal
IBGP peers. Then more clusters could be created gradually.
In the above diagram, RTD, RTE and RTF have the concept of route reflection. RTC, RTA and RTB are
what we call conventional routers and cannot be configured as RRs. Normal IBGP mesh could be done
between these routers and RTD. Later on, when we are ready to upgrade, RTC could be made a RR with
clients RTA and RTB. Clients do not have to understand the route reflection scheme; it is only the RRs that
would have to be upgraded.
The following is the configuration of RTD and RTC:
RTD#
router bgp 100
neighbor 6.6.6.6 remote-as 100
neighbor 6.6.6.6 route-reflector-client
neighbor 5.5.5.5 remote-as 100
neighbor 5.5.5.5 route-reflector-client
Cisco - BGP Case Studies
neighbor 3.3.3.3 remote-as 100
neighbor 2.2.2.2 remote-as 100
neighbor 1.1.1.1 remote-as 100
neighbor 13.13.13.13 remote-as 300
RTC#
router bgp 100
neighbor 4.4.4.4 remote-as 100
neighbor 2.2.2.2 remote-as 100
neighbor 1.1.1.1 remote-as 100
neighbor 14.14.14.14 remote-as 400
When we are ready to upgrade RTC and make it a RR, we would remove the IBGP full mesh and have RTA
and RTB become clients of RTC.
Avoiding Looping of Routing Information
We have mentioned so far two attributes that are used to prevent potential information looping:
originator-id and cluster-list. [ Pobierz całość w formacie PDF ]