Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Route Target Filtering

This topic describes configuring static, BGP, and Proxy BGP route target filtering and provides examples on configuring route target filtering for VPNs.

Configuring Static Route Target Filtering for VPNs

The BGP VPN route target extended community (RFC 4360, BGP Extended Communities Attribute) is used to determine VPN membership. Static route target filtering helps to prevent resources from being consumed in portions of the network where the VPN routes are not needed due to the lack of member PE routers (RFC 4684, Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)). Routers can originate routes into the RT-Constrain protocol to indicate their interest in receiving VPN routes containing route targets that match the RT-Constrain NLRI.

To configure static route target filtering for VPNs:

  • Configure the route-target-filter statement at the [edit routing-options rib bgp.rtarget.0 static] hierarchy level.

    The following example illustrates how you could configure the route-target-filter statement:

  • You can display route target filtering information using the show bgp group rtf detail command.

Reducing Network Resource Use with Static Route Target Filtering for VPNs

The BGP VPN route target extended community (RFC 4360, BGP Extended Communities Attribute) is used to determine VPN membership. Static route target filtering helps to prevent resources from being consumed in portions of the network where the VPN routes are not needed due to the lack of member PE routers (RFC 4684, Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)). Routers can originate routes into the RT-Constrain protocol to indicate their interest in receiving VPN routes containing route targets that match the RT-Constrain NLRI.

Normally, for the RT-Constrain feature to function properly, it must be broadly deployed throughout a network. If this is not the case, the feature is less useful, because the RT-Constrain BGP speaker facing a non-RT-Constrain speaker must advertise a default RT-Constrain route to the other RT-Constrain speakers on behalf of the peer that does not support the feature. This effectively removes the resource saving benefits of the feature in portions of the network where it is not supported since a default RT-Constrain route causes the PE router and all intervening PE routers to need to receive all VPN routes.

The static RT-Constrain feature enables you to partially deploy the RT-Constrain feature in a network. The feature is enabled at a boundary in the network where RT-Constrain is configured. However, some BGP VPN peers do not support RT-Constrain, typically PE routers. The route targets of those PE routers must be statically configured on the router. These route targets are disseminated using the RT-Constrain protocol.

The proxy RT-Constrain feature permits BGP VPN peers that do not support the protocol to have their route-targets discovered and disseminated automatically. However, this feature can only support symmetric route-targets. For example, the import and export route-targets for a VRF routing instance are identical. However, for a hub-and-spoke VPN, the import and export route-targets are not identical. In this scenario, the import and export route-target may be statically configured to be disseminated in the RT-Constrain protocol.

Configuring BGP Route Target Filtering for VPNs

BGP route target filtering allows you to distribute VPN routes to only the routers that need them. In VPN networks without BGP route target filtering configured, BGP distributes all VPN routes to all VPN peer routers.

For more information about BGP route target filtering, see RFC 4684, Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs).

The following sections provide an overview of BGP route target filtering and how to configure it for VPNs:

BGP Route Target Filtering Overview

PE routers, unless they are configured as route reflectors or are running an EBGP session, discard any VPN routes that do not include a route target extended community as specified in the local VRF import policies. This is the default behavior of the Junos OS.

However, unless it is explicitly configured not to store VPN routes, any router configured either as a route reflector or border router for a VPN address family must store all of the VPN routes that exist in the service provider’s network. Also, though PE routers can automatically discard routes that do not include a route target extended community, route updates continue to be generated and received.

By reducing the number of routers receiving VPN routes and route updates, BGP route target filtering helps to limit the amount of overhead associated with running a VPN. BGP route target filtering is most effective at reducing VPN-related administrative traffic in networks where there are many route reflectors or AS border routers that do not participate in the VPNs directly (not acting as PE routers for the CE devices).

BGP route target filtering uses standard UPDATE messages to distributes route target extended communities between routers. The use of UPDATE messages allows BGP to use its standard loop detection mechanisms, path selection, policy support, and database exchange implementation.

Configuring BGP Route Target Filtering for VPNs

BGP route target filtering is enabled through the exchange of the route-target address family, stored in the bgp.rtarget.0 routing table. Based on the route-target address family, the route target NLRI (address family indicator [AFI]=1, subsequent AFI [SAFI]=132) is negotiated with its peers.

On a system that has locally configured VRF instances, BGP automatically generates local routes corresponding to targets referenced in the vrf-import policies.

To configure BGP route target filtering, include the family route-target statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

The advertise-default, external-paths, and prefix-limit statements affect the BGP route target filtering configuration as follows:

  • The advertise-default statement causes the router to advertise the default route target route (0:0:0/0) and suppress all routes that are more specific. This can be used by a route reflector on BGP groups consisting of neighbors that act as PE routers only. PE routers often need to advertise all routes to the route reflector.

    Suppressing all route target advertisements other than the default route reduces the amount of information exchanged between the route reflector and the PE routers. The Junos OS further helps to reduce route target advertisement overhead by not maintaining dependency information unless a nondefault route is received.

  • The external-paths statement (which has a default value of 1) causes the router to advertise the VPN routes that reference a given route target. The number you specify determines the number of external peer routers (currently advertising that route target) that receive the VPN routes.

  • The prefix-limit statement limits the number of prefixes that can be received from a peer router.

The route-target, advertise-default, and external-path statements affect the RIB-OUT state and must be consistent between peer routers that share the same BGP group. The prefix-limit statement affects the receive side only and can have different settings between different peer routers in a BGP group.

Example: BGP Route Target Filtering for VPNs

BGP route target filtering is enabled by configuring the family route-target statement at the appropriate BGP hierarchy level. This statement enables the exchange of a new route-target address family, which is stored in the bgp.rtarget.0 routing table.

The following configuration illustrates how you could configure BGP route target filtering for a BGP group titled to_vpn04:

The following configuration illustrates how you could configure a couple of local VPN routing and forwarding (VRF) routing instances to take advantage of the functionality provided by BGP route target filtering. Based on this configuration, BGP would automatically generate local routes corresponding to the route targets referenced in the VRF import policies (note the targets defined by the vrf-target statements).

Issue the show route table bgp.rtarget.0 show command to verify the BGP route target filtering configuration:

The show command display format for route target prefixes is:

The first number represents the autonomous system (AS) of the router that sent this advertisement. The remainder of the display follows the Junos show command convention for extended communities.

The output from the show route table bgp-rtarget.0 command displays the locally generated and remotely generated routes.

The first two entries correspond to the route targets configured for the two local VRF routing instances (vpn1 and vpn2):

  • 200:200:101/96—Community 200:101 in the vpn1 routing instance

  • 200:200:102/96—Community 200:102 in the vpn2 routing instance

The last two entries are prefixes received from a BGP peer:

  • 200:200:103/96—Tells the local router that routes tagged with this community (200:103) should be advertised to peer 10.255.14.174 through t3-0/0/0.0

  • 200:200:104/96—Tells the local router that routes tagged with this community (200:104) should be advertised to peer 10.255.14.174 through t3-0/0/0.0

Example: Configuring BGP Route Target Filtering for VPNs

BGP route target filtering reduces the number of routers that receive VPN routes and route updates, helping to limit the amount of overhead associated with running a VPN. BGP route target filtering is most effective at reducing VPN-related administrative traffic in networks where there are many route reflectors or AS border routers that do not participate in the VPNs directly (do not act as PE routers for the CE devices).

Figure 1 illustrates the topology for a network configured with BGP route target filtering for a group of VPNs.

Figure 1: BGP Route Target Filtering Enabled for a Group of VPNsBGP Route Target Filtering Enabled for a Group of VPNs

The following sections describe how to configure BGP route target filtering for a group of VPNs:

Configure BGP Route Target Filtering on Router PE1

This section describes how to enable BGP route target filtering on Router PE1 for this example.

Configure the routing options on router PE1 as follows:

Configure the BGP protocol on Router PE1 as follows:

Configure the vpn1 routing instance as follows:

Configure the vpn2 routing instance on Router PE1 as follows:

Once you have implemented this configuration, you should see the following when you issue a show route table bgp.rtarget.0 command:

Configure BGP Route Target Filtering on Router PE2

This section describes how to enable BGP route target filtering on Router PE2 for this example.

Configure the routing options on Router PE2 as follows:

Configure the BGP protocol on Router PE2 as follows:

Configure the vpn1 routing instance on Router PE2 as follows:

Configure the vpn2 routing instance on Router PE2 as follows:

Configure the vpn3 routing instance on Router PE2 as follows:

Once you have configured router PE2 in this manner, you should see the following when you issue the show route table bgp.rtarget.0 command:

Configure BGP Route Target Filtering on the Route Reflector

This section illustrates how to enable BGP route target filtering on the route reflector for this example.

Configure the routing options on the route reflector as follows:

Configure the BGP protocol on the route reflector as follows:

Once you have configured the route reflector in this manner, you should see the following when you issue the show route table bgp.rtarget.0 command:

Configure BGP Route Target Filtering on Router PE3

The following section describes how to enable BGP route target filtering on Router PE3 for this example.

Configure the routing options on Router PE3 as follows:

Configure the BGP protocol on Router PE3 as follows:

Configure the vpn1 routing instance on Router PE3 as follows:

Configure the vpn3 routing instance on Router PE3 as follows:

Configure the vpn4 routing instance on Router PE3 as follows:

Once you have configured Router PE3 in this manner, you should see the following when you issue the show route table bgp.rtarget.0 command:

Example: Configuring an Export Policy for BGP Route Target Filtering for VPNs

This example shows how to configure an export routing policy for BGP route target filtering (also known as route target constrain, or RTC).

Requirements

This example uses the following hardware and software components:

  • Four Juniper Networks devices that support BGP route target filtering.

  • Junos OS Release 12.2 or later on one or more devices configured for proxy BGP route filtering. In this example, you explicitly configure proxy BGP route filtering on the route reflectors.

Before configuring an export policy for BGP route target filtering, make sure that you are familiar with and understand the following concepts:

Overview

BGP route target filtering allows you to reduce network resource consumption by distributing route target membership (RT membership) advertisements throughout the network. BGP uses the RT membership information to send VPN routes only to the devices that need them in the network. Similar to other types of BGP reachability, you can apply a routing policy to route target filtering routes to influence the network. When route target filtering is configured, restricting the flow of route target filtering routes also restricts the VPN routes that might be attracted by this RT membership. Configuring this policy involves:

  • Creating a filter that defines the list of route target prefixes.

  • Creating a policy to select a subset of the route target filters to use for BGP route target filtering.

To define the list of route target prefixes:

  • You configure the rtf-prefix-list statement at the [edit policy-options] hierarchy level to specify the name of the route target prefix list and one or more route target prefixes to use. This configuration allows you to specify the incoming route target filtering routes that the device will use and then distribute them throughout the network.

To configure the routing policy and apply the route target prefix list to that policy, you can specify the following policy options:

  • family route-target—(Optional) The route-target family match condition specifies matching BGP route target filtering routes. You define this criteria in the from statement. This example shows how to create an export policy using the family route-target match condition.

    Note:

    Juniper uses the inet.3 table to resolve the next hop address when family route-target is configured.

  • protocol route-target—(Optional) The route-target protocol match condition defines the criteria that an incoming route must match. You define this criteria in the from statement. This statement is primarily useful for restricting the policy to locally generated route target filtering routes.

    Note:

    When you use the show route table bgp.rtarget.0 command to view proxy BGP route target filtering routes, you will see the BGP protocol for received routes and the route target protocol routes for local route target filtering routes.

  • rtf-prefix-list name—The rtf-prefix-list statement applies the list of route target prefixes that you already configured to the policy. You define this criteria in the from statement.

Topology Diagram

Figure 2 shows the topology used in this example.

Figure 2: BGP Route Target Filtering Export Policy TopologyBGP Route Target Filtering Export Policy Topology

In this example, BGP route target filtering is configured on the route reflectors (Device RR1 and Device RR2) and provider edge (PE) Device PE2. The other PE, Device PE1, does not support BGP route target filtering. Proxy BGP route target filtering is also configured on the peering sessions between the route reflectors and Device PE1 to minimize the number of VPN route updates processed by Device PE1. Device PE2 has four VPNs configured (vpn1, vpn2, vpn3, and vpn4), and Device PE1 has two VPNs configured (vpn1 and vpn2). In the sample topology, all devices participate in autonomous system (AS) 203, OSPF is the configured interior gateway protocol (IGP), and LDP is the signaling protocol used by the VPNs. In this example, we use static routes in the VPN routing and forwarding (VRF) instances to generate VPN routes. This is done in place of using a PE to customer edge (CE) protocol such as OSPF or BGP.

In this example, you further control the routes being advertised from Device PE2 to Device PE1 by configuring an export policy on Device PE2 to prevent vpn3 routes from being advertised to Device RR1. You create a policy that specifies the family route-target match condition, defines the list of route target prefixes, and applies the list of route target prefixes by defining the rtf-prefix-list criteria.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device PE1

Device RR1

Device RR2

Device PE2

Configuring Device PE1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device PE1:

  1. Configure the interfaces.

  2. Configure the route distinguisher and the AS number.

  3. Configure LDP as the signaling protocol used by the VPN.

  4. Configure BGP.

  5. Configure OSPF.

  6. Configure the VPN routing instances.

  7. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device RR1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device RR1:

  1. Configure the interfaces.

  2. Configure the route distinguisher and the AS number.

  3. Configure LDP as the signaling protocol used by the VPN.

  4. Configure BGP.

  5. Configure BGP route target filtering on the peering session with Device PE2.

  6. Configure proxy BGP route target filtering on the peering session with Device PE1.

  7. Configure OSPF.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device RR2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device RR2:

  1. Configure the interfaces.

  2. Configure the route distinguisher and the AS number.

  3. Configure LDP as the signaling protocol used by the VPN.

  4. Configure BGP.

  5. Configure BGP route target filtering on the peering session with Device PE2.

  6. Configure proxy BGP route target filtering on the peering session with Device PE1.

  7. Configure OSPF.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device PE2:

  1. Configure the interfaces.

  2. Configure the route distinguisher and the AS number.

  3. Configure LDP as the signaling protocol used by the VPN.

  4. Configure BGP.

  5. Configure OSPF.

  6. Configure the VPN routing instances.

  7. Configure and apply the export routing policy.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, show routing-options, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying the Route Target Filtering Routes in the bgp.rtarget.0 Routing Table for Device RR1

Purpose

Verify that the route prefix for vpn3 is not in Device RR1’s bgp.rtarget.0 table. Since an export policy on Device PE2 was applied to prevent the advertisement of vpn3 routes to Device RR1, Device RR1 should not receive those advertisements.

Action

From operational mode, enter the show route advertising-protocol bgp 10.255.165.220 table bgp.rtarget.0 command.

Meaning

The bgp.rtartget.0 table does not display 203:203:103/96, which is the route prefix for vpn3. That means the export policy was applied correctly.

Verifying the Route Target Filtering Routes in the bgp.rtarget.0 Routing Table for Device RR2

Purpose

Verify that the route prefix for vpn3 is in Device RR2’s bgp.rtarget.0 table. Since an export policy was not applied on Device PE2 to prevent the advertisement of vpn3 routes to Device RR2, Device RR2 should receive advertisements from all of the VPNs.

Action

From operational mode, enter the show route advertising-protocol bgp 10.255.165.28 table bgp.rtarget.0 command.

Meaning

The bgp.rtartget.0 table displays the route prefixes for all of the VPNs.

Example: Configuring Layer 3 VPN Protocol Family Qualifiers for Route Filters

This example shows how to control the scope of BGP import policies by configuring a family qualifier for the BGP import policy. The family qualifier specifies routes of type inet, inet6, inet-vpn, or inet6-vpn.

Requirements

This example uses Junos OS Release 10.0 or later.

Before you begin:

Overview

Family qualifiers cause a route filter to match only one specific family. When you configure an IPv4 route filter without a family qualifier, as shown here, the route filter matches inet and inet-vpn routes.

Likewise, when you configure an IPv6 route filter without a family qualifier, as shown here, the route filter matches inet6 and inet6-vpn routes.

Consider the case in which a BGP session has been configured for both family inet routes and family inet-vpn routes, and an import policy has been configured for this BGP session. This means that both family inet and family inet-vpn routes, when received, share the same import policy. The policy term might look as follows:

This route-filter logic matches an inet route of 0.0.0.0 and an inet-vpn route whose IPv4 address portion is 0.0.0.0. The 8-byte route distinguisher portion of the inet-vpn route is not considered in the route-filter matching. This is a change in Junos OS behavior that was introduced in Junos OS Release 10.0.

If you do not want your policy to match both types of routes, add a family qualifier to your policy. To have the route-filter match only inet routes, add the family inet policy qualifier. To have the route-filter match only inet-vpn routes, add the family inet-vpn policy qualifier.

The family qualifier is evaluated before the route-filter is evaluated. Thus, the route-filter is not evaluated if the family match fails. The same logic applies to family inet6 and family inet6-vpn. The route-filter used in the inet6 example must use an IPv6 address. There is a potential efficiency gain in using a family qualifier because the family qualifier is tested before most other qualifiers, quickly eliminating routes from undesired families.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

inet Example

Inet-vpn Example

inet6 Example

Inet6-vpn Example

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure a flow map:

  1. Configure the family qualifier.

  2. Configure the route filter.

  3. Configure the policy actions.

  4. Apply the policy.

Results

From configuration mode, confirm your configuration by issuing the show protocols and show policy-options command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Repeat the procedure for every protocol family for which you need a specific route-filter policy.

Verification

To verify the configuration, run the following commands:

  • show route advertising-protocol bgp neighbor detail

  • show route instance instance-name detail

Understanding Proxy BGP Route Target Filtering for VPNs

BGP route target filtering (also known as route target constrain, or RTC) allows you to distribute VPN routes to only the devices that need them. In VPN networks without BGP route target filtering configured, BGP distributes all VPN routes to all VPN peer devices, which can strain network resources. The route target filtering feature was introduced to reduce the number of devices receiving VPN routes and VPN routing updates, thereby limiting the amount of overhead associated with running a VPN. The Junos OS implementation for BGP route target filtering is based on RFC 4684, Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs).

What if you have a network environment where route target filtering is not widely deployed, or what if some devices do not support route target filtering? For example, you might have a BGP speaker with route target filtering enabled that is peered with a BGP speaker that does not support or have route target filtering configured. In this case, the BGP speaker with route target filtering configured must advertise default route target membership (RT membership) on behalf of its peer. The route target filtering resource savings are unrealized because the device supporting the filtering must now send all VPN routes to the device that does not support the filter. Proxy BGP route target filtering (or Proxy RTC) permits the generation of RT membership for devices that do not support route target filtering. This eases the deployment of route target filtering in networks where it is incompletely deployed or not fully supported.

Proxy BGP route target filtering allows you to distribute proxy RT membership advertisements created from the received BGP VPN routes to other devices in the network that need them. These are known as proxy advertisements because the device creates the RT membership on behalf of its peers without the route target filtering functionality. Proxy BGP route target filtering uses BGP route target extended communities that are exported to a specific BGP speaker to generate the route targets. Generated proxy RTC routes are stored in the bgp.rtarget.0 routing table.

You can also configure a policy to control which VPN routes are used to generate the proxy RTC routes. This can help control which RT membership is generated by the proxying device. In addition, you can configure a policy to reduce the memory overhead associated with proxy RTC. Proxy RTC only uses additional memory on a per-VPN route basis when it is permitted by a policy to be used for generating RT membership.

Example: Configuring Proxy BGP Route Target Filtering for VPNs

This example shows how to configure proxy BGP route target filtering (also known as proxy route target constrain, or proxy RTC).

Requirements

This example uses the following hardware and software components:

  • Four Juniper Networks devices that can be a combination of M Series, MX Series, or T Series routers.

  • Junos OS Release 12.2 or later on one or more devices configured for proxy BGP route filtering. In this example, you explicitly configure proxy BGP route filtering on the route reflectors.

Before configuring proxy BGP route target filtering, make sure that you are familiar with and understand the following concepts:

Overview

Route target filtering decreases the number of devices in a network that receive VPN routes that are not needed. Proxy BGP route target filtering allows networks to take advantage of route target filtering in locations where the feature is not currently supported. By configuring this feature, you can realize many of the same network resource savings that are available to you if your network fully supported BGP route target filtering.

To configure proxy BGP route target filtering, you include the family route-target proxy-generate statement on the devices that will distribute proxy route target membership (RT membership) advertisements for the devices that do not support BGP route target filtering. The proxy BGP route target filtering routes are then stored in the bgp.rtarget.0 routing table.

Proxy BGP route target filtering is intended to create RT membership advertisements for devices that do not support the BGP route target filtering feature. If the proxy-generate statement is present, but the route target family is negotiated with the BGP peer, the proxy-generate functionality is disabled. This allows simplified configuration of BGP peer groups where a portion of the peers in the group support route target filtering but others do not. In such an example case, the family route-target proxy-generate statement might be part of the BGP peer group configuration.

Note:

When deploying proxy BGP route target filtering in your network, the advertise-default statement for BGP route target filtering causes the device to advertise the default route target route (0:0:0/0) and suppress all routes that are more specific. If you have proxy BGP route target filtering configured on one device and one or more peers have the advertise-default statement configured as part of their BGP route target filtering configuration, the advertise-default configuration is ignored.

Topology Diagram

Figure 3 shows the topology used in this example.

Figure 3: Proxy BGP Route Target Filtering TopologyProxy BGP Route Target Filtering Topology

In this example, BGP route target filtering is configured on the route reflectors (Device RR1 and Device RR2) and the provider edge (PE) Device PE2, but the other PE, Device PE1, does not support the BGP route target filtering functionality. Device PE2 has four VPNs configured (vpn1, vpn2, vpn3, and vpn4). Device PE1 has two VPNs configured (vpn1 and vpn2), so this device is only interested in receiving route updates for vpn1 and vpn2. Currently, this is impossible because both route reflectors (Device RR1 and Device RR2) learn and share information about all of the incoming VPN routes (vpn1 through vpn4) with Device PE1. In the sample topology, all devices participate in autonomous system (AS) 203, OSPF is the configured interior gateway protocol (IGP), and LDP is the signaling protocol used by the VPNs. In this example, we use static routes in the VPN routing and forwarding (VRF) instances to generate VPN routes. This is done in place of using a PE to customer edge (CE) protocol such as OSPF or BGP.

To minimize the number of VPN route updates being processed by Device PE1, you include the family route-target proxy-generate statement to configure proxy BGP route target filtering on each route reflector. Each route reflector has a peering session with Device PE1 and supports route target filtering to the core. However, Device PE1 does not support route target filtering, so the network resource savings are unrealized by Device PE1 since it receives all of the VPN updates. By configuring proxy BGP route target filtering on the peering sessions facing Device PE1, you limit the number of VPN updates processed by Device PE1, and the route reflectors generate the proxy BGP route target routes for Device PE1 throughout the network.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device PE1

Device RR1

Device RR2

Device PE2

Configuring Device PE1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device PE1:

  1. Configure the interfaces.

  2. Configure the route distinguisher and the AS number.

  3. Configure LDP as the signaling protocol used by the VPN.

  4. Configure BGP.

  5. Configure OSPF.

  6. Configure the VPN routing instances.

  7. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device RR1

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device RR1:

  1. Configure the interfaces.

  2. Configure the route distinguisher and the AS number.

  3. Configure LDP as the signaling protocol used by the VPN.

  4. Configure BGP.

  5. Configure BGP route target filtering on the peering session with Device PE2.

  6. Configure proxy BGP route target filtering on the peering session with Device PE1.

  7. Configure OSPF.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device RR2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device RR2:

  1. Configure the interfaces.

  2. Configure the route distinguisher and the AS number.

  3. Configure LDP as the signaling protocol used by the VPN.

  4. Configure BGP.

  5. Configure BGP route target filtering on the peering session with Device PE2.

  6. Configure proxy BGP route target filtering on the peering session with Device PE1.

  7. Configure OSPF.

  8. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring Device PE2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure Device PE2:

  1. Configure the interfaces.

  2. Configure the route distinguisher and the AS number.

  3. Configure LDP as the signaling protocol used by the VPN.

  4. Configure BGP.

  5. Configure OSPF.

  6. Configure the VPN routing instances.

  7. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show routing-options, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying the Proxy BGP Route Target Routes

Purpose

Verify that the proxy BGP route target routes are displayed in the bgp.rtarget.0 table on Device RR1.

Action

From operational mode, enter the show route table bgp.rtartget.0 command to display the proxy BGP route targets.

Meaning

Device RR1 is generating the proxy BGP route target routes on behalf of its peer Device PE1. The proxy BGP route target routes are identified with the protocol and preference [RTarget/5] and the route target type of Proxy.