RRs

An RR is a BGP speaker that reflects routes from other BGP speakers. RRs were invented when networks grew larger. Internal BGP requires that all BGP speakers are in a full mesh with each other. This is fine for a low number of BGP speakers, but it gives the operator of the network problems when the network becomes larger than a certain size. When you have a network with n internal BGP speakers, each BGP speaker has n-1 peers, and n*(n-1)/2 BGP sessions exist in total. RRs and BGP confederations were invented to alleviate this problem. RRs peer with the BGP speakers in a cluster, but the BGP speakers in the cluster do not need to peer with each other any more if they peer with the RRs. The RRs just forward or reflect all the BGP routes they receive. If you want to use RRs with MPLS VPN, the RRs should reflect vpnv4 prefixes, which carry labels. RRs only change the label if they become the next hop for the routes, which they usually do not. RRs that do become the next hop for the iBGP route are in the forwarding path. This means that they have to forward the traffic for those routes. This could result in a huge amount of traffic flowing through a few RRs, which is definitely not a good idea. The RRs should not be burdened with forwarding traffic. Furthermore, the route of the traffic through the RRs from ingress PE to egress PE is usually not the most optimal route, because the RRs can be anywhere in the network. RRs should not forward traffic, but just reflect BGP routes.

RRs differ in another way from the other BGP speakers (the PE routers) in the MPLS VPN network. They do not reject vnpv4 routes when the RT is not configured for acceptance on the RRs. A PE router that receives a vpnv4 route for which any of the RTs is not imported into a VRF rejects the route. Example 7-16 shows a route that is rejected because the RT 2:2 is not configured to be imported by a VRF on the PE.

Example 7-16 Rejected vnpv4 Route sydney#debug ip bgp vpnv4 unicast updates in

BGP updates debugging is on (inbound) for address family: VPNv4 Unicast sydney#

BGP(2): 10.200.254.2 rcvd UPDATE w/ attr: nexthop 10.200.254.2, origin ?, localpref 100, metric

0, extended community RT:2:2

BGP(2): 10.200.254.2 rcvd 2:2:10.140.1.1/32 -- DENIED due to: extended community not supported;

The PE router has this default behavior to save memory. Why does it need to store the vpnv4 routes in the BGP table if no VRF is attached to this PE router that imports the route? RRs do not exhibit this behavior because they do not know which RTs the PEs permit or deny. RRs accept and store all BGP routes. To ease the burden, you can implement RR groups to split the load of reflecting vpnv4 routes among several RRs or groups of RRs. Each RR or group of RRs then reflects a subset of all the vpnv4 routes.

NOTE It is a good idea to have at least two RRs for a subset of the vpnv4 prefixes for redundancy reasons.

RR Group

It is unnecessary for one RR or a group of RRs to have all the vpnv4 routes in the BGP table. You can subdivide the vpnv4 routes into groups and allow several RRs or several groups of RRs to carry one of those subsets of routes. Divide and conquer. This increases the scalability of your network. The command needed to implement RR group on the RRs is bgp rr-group {extcom-list-number} under the address family vpnv4. You must specify an extended community list for the RR group. This extended community list specifies the RTs that you want this RR to permit or deny. Figure 7-12 shows an example of the usage of an RR group. Two RRs are available, with RR group configured for a different set of vpnv4 routes. One RR filters out the vpnv4 updates with the even RTs; the other RR filters out the vpnv4 updates with the odd RTs.

Figure 7-12 Example of an MPLS VPN Network with RR Groups

RR1 Is RR for Odd VRFs RR2 Is RR for Even VRFs

RR1 Is RR for Odd VRFs RR2 Is RR for Even VRFs

Example 7-17 shows the use of RR groups. An extended community list 1 is created on RR1 permitting the RT 1:1 and denying the RT 1:2 from the RR clients. On the second RR, you swap the permitted and denied RTs.

Example 7-17 Example of RR Groups

RR1(config-router)#address-family vpnv4 RR1(config-router-af)#bgp rr-group ? <1-500> Extended-Community list number router bgp 1 neighbor 10.200.254.2 neighbor 10.200.254.2 neighbor 10.200.254.5 neighbor 10.200.254.5 no auto-summary !

address-family vpnv4 neighbor 10.200.254.2 neighbor 10.200.254.2 neighbor 10.200.254.2 neighbor 10.200.254.5 neighbor 10.200.254.5 neighbor 10.200.254.5 bgp rr-group 1 exit-address-family remote-as 1

update-source Loopback0 remote-as 1

update-source Loopback0

activate route - reflector-client send-community extended activate route - reflector-client send-community extended

Example 7-17 Example of RR Groups (Continued)

ip extcommunity-list

1

permit rt

1:1

ip extcommunity-list

1

deny rt 1

2

ip extcommunity-list

1

permit rt

1:3

ip extcommunity-list

!

1

deny rt 1

4

Micro Expression Master

Micro Expression Master

If You Could Read Everyone Life A Book You Can Have Better Career, Great Relationships And Become Successful. This Book Is One Of The Most Valuable Resources In The World When It Comes To Reading the smallest and tiniest body Language and know what people are thinking about.

Get My Free Ebook


Post a comment