Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Some service providers have a large number of routing updates being sent from RRs to PEs, which can require extensive use of resources. A PE does not need routing updates for VRFs that are not on the PE; therefore, the PE determines that many routing updates it receives are "unwanted." The PE filters out the unwanted updates.

The figure below illustrates a scenario in which unwanted routing updates arrive at two PEs.

As shown in the figure above, a PE receives unwanted routes in the following manner:

1. PE-3 advertises VRF Blue and VRF Red routes to RR-1. PE-4 advertises VRF Red and VRF Green routes to RR-1.

2. RR-1 has all of the routes for all of the VRFs (Blue, Red, and Green).

3. During a route refresh or VRF provisioning, RR-1 advertises all of the VRF routes to both PE-3 and PE-4.

4. Routes for VRF Green are unwanted at PE-3. Routes for VRF Blue are unwanted at PE-4.

Now consider the scenario where there are two RRs with another set of PEs. There are unwanted routing updates from RRs to PEs and unwanted routing updates between RRs. The figure below illustrates a scenario in which unwanted routes arrive at an RR.

As shown in the figure above, RR-1 and RR-2 receive unwanted routing updates in the following manner:

1. PE-3 and PE-4 advertise VRF Blue, VRF Red, and VRF Green VPN routes to RR-1.

2. RR-1 sends all of its VPN routes to RR-2.

3. VRF Red routes are unwanted on RR-2 because PE-1 and PE-2 do not have VRF Red.

4. Similarly, VRF Purple routes are unwanted on RR-1 because PE-3 and PE-4 do not have VRF Purple.

Hence, a large number of unwanted routes might be advertised among RRs and PEs. The BGP: RT Constrained Route Distribution feature addresses this problem by filtering unwanted routing updates.

Before the BGP: RT Constrained Route Distribution feature, the PE would filter the updates. With this feature, the burden is moved to the RR to filter the updates.

In MPLS L3VPNs, PE routers use BGP and route target (RT) extended communities to control the distribution of VPN routes to and from VRFs in order to separate the VPNs. PEs and Autonomous System Boundary Routers (ASBRs) commonly receive and then filter out the unwanted VPN routes.

However, receiving and filtering unwanted VPN routes is a waste of resources. The sender generates and transmits a VPN routing update and the receiver filters out the unwanted routes. Preventing the generation of VPN route updates would save resources.

Route Target Constrain (RTC) is a mechanism that prevents the propagation of VPN Network Layer Reachability Information (NLRI) from the RR to a PE that is not interested in the VPN. The feature provides considerable savings in CPU cycles and transient memory usage. RT constraint limits the number of VPN routes and describes VPN membership.

The BGP: RT Constrained Route Distribution feature introduces the BGP RT-Constrain Subsequent Address Family Identifier (SAFI). The command to enter that address family is the address-family rtfilter unicast command.

In order to filter out the unwanted routes described in the "Problem that BGP RT Constrained Route Distribution Solves" section on page 2, the PEs and RRs must be configured with the BGP: RT Constrained Route Distribution feature.

The feature allows the PE to propagate RT membership and use the RT membership to limit the VPN routing information maintained at the PE and RR. The PE uses an MP-BGP UPDATE message to propagate the membership information. The RR restricts advertisement of VPN routes based on the RT membership information it received.

This feature causes two exchanges to happen:

• The PE sends RT Constraint (RTC) Network Layer Reachability Information (NLRI) to the RR.

• The RR installs an outbound route filter.

The figure below illustrates the exchange of the RTC NLRI and the outbound route filter.

As shown in the figure above, the following exchange occurs between the PE and the RR:

1. PE-3 sends RTC NLRI (RT 1, RT 2) to RR-1.

2. PE-4 sends RTC NLRI (RT 2, RT 3) to RR-1.

3. RR-1 translates the NLRI into an outbound route filter and installs this filter (Permit RT 1, RT 2) for PE-3.

4. RR-1 translates the NLRI into an outbound route filter and installs this filter (Permit RT 2, RT 3) for PE-4.

The format of the RT Constraint NLRI is a prefix that is always 12 bytes long, consisting of the following:

• 4-byte origin autonomous system

• 8-byte RT extended community value

The following are examples of RT Constraint prefixes:

• 65000:2:100:1

  • Origin autonomous system number is 65000
  • BGP Extended Community Type Code is 2
  • Route target is 100:1
• 65001:256:192.0.0.1:100

  • Origin ASN is 65001
  • BGP Extended Community Type Code is 256
  • Route target is 192.0.0.1:100
• 1.10:512:1.10:2

  • Origin ASN is 4-byte, unique 1.10
  • BGP Extended Community Type Code is 512
  • Route target is 1.10:2

To determine what the BGP Extended Community Type Code means, refer to RFC 4360, BGP Extended Communities Attribute. In the first example shown, a 2 translates in hexadecimal to 0x002. In RFC 4360, 0x002 indicates that the value that follows the type code will be a two-octet AS specific route target.

This section shows the RT Constrained Route Distribution process. In this example has two CE routers in AS 100 that are connected to PE1. PE1 communicates with PE2, which is also connected to CE routers. Between the two PEs is a route reflector (RR). PE1 and PE2 belong to AS 65000.

The general process for the feature is as follows:

1. The user configures PE1 to activate its BGP peers under the address-family rtfilter unicast command.

2. The user configures PE1 in AS 65000 with route-target import 100:1 , for example.

3. PE1 translates that command to an RT prefix of 65000:2:100:1. The 65000 is the service provider’s AS number; the 2 is the BGP Extended Communities Type Code; and the 100:1 is the CE’s RT (AS number and another number).

4. PE1 advertises the RT Constrain (RTC) prefix of 65000:2:100:1 to its iBGP peer RR.

5. The RR installs RTC 65000:2:100:1 into the RTC RIB. Each VRF has its own RIB.

6. The RR also installs RTC 65000:2:100:1 into its outbound filter for the neighbor PE1.

7. A filter in the RR either permits or denies the RT. (The AS number is ignored because iBGP is operating in a single AS and does not need to track the AS number.)

8. The RR looks in its outbound filter and sees that it permits outbound VPN packets for RT 100:1 to PE1. So, the RR sends VPN update packet only with RT 100:1 to PE1 and denies VPN updates with any other RT.

The default RT filter has a value of zero and length of zero. The default RT filter is used:

• By a peer to indicate that the peer wants all of the VPN routes sent to it, regardless of the RT value.

• By the RR to request that the PE advertise all of its VPN routes to the RR.

The default RT filter is created by configuring the neighbor default-originate command under the address-family rtfilter unicast command. On the RR it comes as default along with the configuration of route-reflector-client under the address-family rtfilter.

To connect the MPLS VPN customers to the VPN, perform the following tasks: