Downloads |
 Feedback
|
Table Of Contents
Prerequisites for MPLS VPN - Route Target Rewrite
Restrictions for MPLS VPN - Route Target Rewrite
Information About MPLS VPN - Route Target Rewrite
Route Target Replacement Policy
Route Maps and Route Target Replacement
How to Configure MPLS VPN - Route Target Rewrite
Configuring a Route Target Replacement Policy
Applying the Route Target Replacement Policy
Associating Route Maps with Specific BGP Neighbors
Refreshing BGP Session to Apply Route Target Replacement Policy
Verifying the Route Target Replacement Policy
Troubleshooting Your Route Target Replacement Policy
Configuration Examples for MPLS VPN - Route Target Rewrite
Configuring Route Target Replacement Policies: Examples
Applying Route Target Replacement Policies: Examples
Associating Route Maps with Specific BGP Neighbor Example
Refreshing the BGP Session to Apply the Route Target Replacement Policy Example
Verifying the Route Target Replacement Policy Example
Troubleshooting the Route Target Replacement Policy Example
MPLS VPN—Route Target Rewrite
First Published: August 26, 2003Last Updated: May 31, 2007The MPLS VPN—Route Target Rewrite feature allows the replacement of route targets on incoming and outgoing Border Gateway Protocol (BGP) updates. Typically, Autonomous System Border Routers (ASBRs) perform the replacement of route targets at autonomous system boundaries. Route Reflectors (RRs) and provider edge (PE) routers can also perform route target replacement.
The main advantage of the MPLS VPN - Route Target Rewrite feature is that it keeps the administration of routing policy local to the autonomous system.
History for the MPLS VPN - Route Target Rewrite Feature
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for MPLS VPN - Route Target Rewrite
•
•
•
•
Prerequisites for MPLS VPN - Route Target Rewrite
The MPLS VPN - Route Target Rewrite feature requires the following:
•
•
•
Restrictions for MPLS VPN - Route Target Rewrite
You can apply multiple replacement rules using the route-map continue clause. The MPLS VPN - Route Target Rewrite feature does not support the continue clause on outbound route maps.
Information About MPLS VPN - Route Target Rewrite
To configure the MPLS VPN - Route Target Rewrite feature, you need to understand the following concepts:
•
•
Route Target Replacement Policy
Routing policies for a peer include all configurations that may impact inbound or outbound routing table updates. The MPLS VPN - Route Target Rewrite feature can influence routing table updates by allowing the replacement of route targets on inbound and outbound BGP updates. Route targets are carried as extended community attributes in BGP Virtual Private Network IP Version 4 (VPNv4) updates. Route target extended community attributes are used to identify a set of sites and VPN routing and forwarding (VRF) instances that can receive routes with a configured route target.
In general, ASBRs perform route target replacement at autonomous system borders when the ASBRs exchange VPNv4 prefixes. You can also configure the MPLS VPN - Route Target Rewrite feature on PE routers and RR routers.
Figure 1 shows an example of route target replacement on ASBRs in an MPLS VPN Inter-autonomous system topology. This example includes the following configurations:
•
•
•
•
Figure 1 Route Target Replacement on ASBRs in an MPLS VPN Inter-AS Topology
Figure 2 shows an example of route target replacement on route reflectors in an MPLS VPN Inter-autonomous system topology. This example includes the following configurations:
•
•
•
•
•
•
•
•
Figure 2 Route Target Rewrite on Route Reflectors in an MPLS VPN Inter-autonomous system Topology
Route Maps and Route Target Replacement
The MPLS VPN - Route Target Rewrite feature extends the BGP inbound/outbound route map functionality to enable route target replacement. The set extcomm-list delete command entered in route-map configuration mode allows the deletion of a route target extended community attribute based on an extended community list.
How to Configure MPLS VPN - Route Target Rewrite
This section contains the following procedures to configure MPLS VPN - Route Target Rewrite:
•
•
•
•
Configuring a Route Target Replacement Policy
Perform this task to configure an RT replacement policy for your internetwork.
If you configure a PE to rewrite RT x to RT y and the PE has a VRF that imports RT x, you need to configure the VRF to import RT y in addition to RT x.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Troubleshooting Tips
Use the show route-map map-name command to verify that the match and set entries are correct.
Applying the Route Target Replacement Policy
Perform the following tasks to apply the route target replacement policy to your internetwork:
•
•
Associating Route Maps with Specific BGP Neighbors
Perform this task to associate route maps with specific BGP neighbors.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPS
Refreshing BGP Session to Apply Route Target Replacement Policy
Perform this task to refresh the BGP session to apply the RT replacement policy.
After you have defined two routers to be BGP neighbors, the routers form a BGP connection and exchange routing information. If you subsequently change a routing policy, you must reset BGP connections for the configuration change to take effect. After configuring the RT replacement policy and applying it to the target routers in your system, you must refresh the BGP session to put the policy into operation.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Troubleshooting Tips
To determine whether a BGP router supports the route refresh capability, use the show ip bgp neighbors command. If a router supports the route refresh capability, the following message is displayed:
Received route refresh capability from peer.You can issue the debug ip bgp updates command on the router where you entered the clear ip bgp command to verify that the updates are occurring.
Note
Verifying the Route Target Replacement Policy
Perform this task to verify the operation of your RT replacement policy.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Troubleshooting Your Route Target Replacement Policy
Perform this task to troubleshoot your RT replacement policy.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuration Examples for MPLS VPN - Route Target Rewrite
This section contains the following configuration examples for the MPLS VPN - Route Target Rewrite feature:
•
•
•
•
Configuring Route Target Replacement Policies: Examples
This example shows the RT replacement configuration of an ASBR (ASBR1) that exchanges VPNv4 prefixes with another ASBR (ASBR2). The route map extmap is configured to replace RTs on inbound updates. Any incoming update with RT 100:3 is replaced with RT 200:3. Any other prefixes with an RT whose autonomous system number is 100 is rewritten to RT 200:4.
!ip extcommunity-list 1 permit rt 100:3ip extcommunity-list 101 permit RT:100:*!route-map extmap permit 10match extcommunity 1set extcomm-list 1 deleteset extcommunity rt 200:3 additive!route-map regexp permit 10match extcommunity 101set extcomm-list 101 deleteset extcommunity rt 200:4 additive!route-map regexp permit 20This example shows the use of the route-map configuration continue command when you need to apply more than one replacement rule on an update. In this example, an incoming update with RT 100:3 is replaced with RT 200:3. Without the continue 20 command, route-map evaluation would stop when a match on sequence 10 is made. With the continue 20 command, route-map evaluation continues into sequence 20 even if a match occurs in sequence 10. If the incoming update has an RT 100:4, the router replaces it with RT 200:4.
!ip extcommunity-list 1 permit rt 100:3ip extcommunity-list 2 permit rt 100:4!route-map extmap permit 10match extcommunity 1set extcomm-list 1 deleteset extcommunity rt 200:3 additivecontinue 20!route-map extmap permit 20match extcommunity 2set extcomm-list 2 deleteset extcommunity rt 200:4 additive!route-map extmap permit 30
Note
Applying Route Target Replacement Policies: Examples
This section contains the following examples:
•
•
Associating Route Maps with Specific BGP Neighbor Example
This example shows the association of route map extmap with a BGP neighbor. The BGP inbound route map is configured to replace RTs on incoming updates.
router bgp 100...neighbor 172.16.0.2 remote-as 100...!address family vpnv4neighbor 172.16.0.2 activateneighbor 172.16.0.2 send-community extendedneighbor 172.16.0.2 route-map extmap inThis example shows the association of the same route map with the outbound BGP neighbor. The route map is configured to replace RTs on outgoing updates.
router bgp 100...neighbor 172.16.0.2 remote-as 100...!address family vpnv4neighbor 172.16.0.2 activateneighbor 172.16.0.2 send-community extendedneighbor 172.16.0.2 route-map extmap outRefreshing the BGP Session to Apply the Route Target Replacement Policy Example
The following example shows the clear ip bgp command used to initiate a dynamic reconfiguration in the BGP peer 172.16.0.2. This command requires that the peer supports the route refresh capability.
Router# clear ip bgp 172.16.0.2 vpnv4 unicast inVerifying the Route Target Replacement Policy Example
The following examples verify route target replacement on ABSR1 and ABSR2.
Verify route target replacement on ABSR1:
Router# show ip bgp vpnv4 all 172.16.17.17BGP routing table entry for 100:1:172.16.17.17/32, version 6Paths: (1 available, best #1, no table)Advertised to update-groups:1300172.16.11.11 (metric 589) from 172.16.11.11 (172.16.11.11)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:200:1Verify route target replacement on ABSR2:
Router# show ip bgp vpnv4 all 172.16.17.17BGP routing table entry for 100:1:172.16.17.17/32, version 6Paths: (1 available, best #1, no table)Advertised to update-groups:1100 300192.168.1.1 from 192.168.1.1 (172.16.13.13)Origin incomplete, localpref 100, valid, external, bestExtended Community: RT:100:1The following examples verify route target replacement on PE1 and PE2.
Verify route target on PE1:
Router# show ip bgp vpnv4 all 172.16.17.17BGP routing table entry for 100:1:172.16.17.17/32, version 13Paths: (1 available, best #1, table vpn1)Advertised to update-groups:1300192.168.2.1 (via vpn1) from 192.168.2.1 (172.16.19.19)Origin incomplete, metric 0, localpref 100, valid, external, bestExtended Community: RT:200:1Verify route target on PE2:
Router# show ip bgp vpnv4 all 172.16.17.17BGP routing table entry for 100:1:172.16.17.17/32, version 13Paths: (1 available, best #1, table vpn1)Advertised to update-groups:3100 300192.168.1.1 (metric 20) from 172.16.16.16 (172.16.16.16)Origin incomplete, localpref 100, valid, internal, bestExtended Community: RT:100:1Troubleshooting the Route Target Replacement Policy Example
Note
This example shows the BGP update information on ASBR1:
Router# debug ip bgp updates 172.16.16.16BGP(2): no valid path for 100:1:172.16.20.20/32BGP(2): no valid path for 100:1:10.0.0.0/8%BGP-5-ADJCHANGE: neighbor 172.16.16.16 Down User resetBGP(2): nettable_walker 100:1:172.16.20.20/32 no RIBBGP(2): nettable_walker 100:1:192.168.3.0/8 no RIBBGP(2): 172.16.11.11 computing updates, afi 2, neighbor version 13,table version 15, starting at 0.0.0.0BGP(2): 172.16.11.11 send unreachable 100:1:172.16.20.20/32BGP(2): 172.16.11.11 send UPDATE 100:1:172.16.20.20/32 -- unreachableBGP(2): 172.16.11.11 send UPDATE 100:1:192.168.3.0/8 -- unreachableBGP(2): 1 updates (average = 58, maximum = 58)BGP(2): 172.16.11.11 updates replicated for neighbors: 172.16.11.11BGP(2): 172.16.11.11 update run completed, afi 2, ran for 0ms,neighbor version 15, start version 15, throttled to 15BGP: Import walker start version 13, end version 15BGP: ... start import cfg version = 30%BGP-5-ADJCHANGE: neighbor 172.16.16.16 UpBGP(2): 172.16.16.16 computing updates, afi 2, neighbor version 0,table version 15, starting at 0.0.0.0BGP(2): 172.16.16.16 send UPDATE (format) 100:1:172.16.0.0/16,next 172.16.11.11, metric 0, path 300, extended community RT:2:2RT:7777:222222222 RT:20000:111 RT:65535:999999999BGP(2): 172.16.16.16 send UPDATE (prepend, chgflags: 0x0)100:1:172.16.19.19/32, next 172.16.11.11, metric 0, path 300,extended community RT:2:2 RT:7777:222222222 RT:20000:111RT:65535:999999999BGP(2): 172.16.16.16 send UPDATE (format) 100:1:192.168.2.0/8,next 172.16.11.11, metric 0, path , extended communityRT:2:2 RT:7777:222222222 RT:20000:111 RT:65535:999999999BGP(2): 2 updates (average = 111, maximum = 121)BGP(2): 172.16.16.16 updates replicated for neighbors: 172.16.16.16BGP(2): 172.16.16.16 update run completed, afi 2, ran for 0ms,neighbor version 15, start version 15, throttled to 15BGP(2): 172.16.16.16 rcvd UPDATE w/ attr: nexthop 172.16.15.15,origin ?, path 200, extended community RT:100:1BGP(2): 172.16.16.16 rcvd 100:1:192.168.3.0/8BGP(2): 172.16.16.16 rcvd UPDATE w/ attr: nexthop 172.16.15.15,origin ?, path 200 400, extended community RT:100:1BGP(2): 172.16.16.16 rcvd 100:1:172.16.0.0/16BGP(2): 172.16.16.16 rcvd 100:1:172.16.20.20/32BGP(2): nettable_walker 100:1:172.16.20.20/32 no RIBBGP(2): nettable_walker 100:1:192.168.3.0/8 no RIBBGP: Import walker start version 15, end version 17BGP: ... start import cfg version = 30BGP(2): 172.16.11.11 computing updates, afi 2,neighbor version 15, table version 17,starting at 0.0.0.0BGP(2): 172.16.11.11 NEXT_HOP part 1 net 100:1:172.16.20.20/32,next 172.16.15.15BGP(2): 172.16.11.11 send UPDATE (format) 100:1:172.16.20.20/32,next 172.16.15.15,metric 0, path 200 400, extended communityRT:1:1 RT:10000:111 RT:33333:888888888RT:65535:999999999BGP(2): 172.16.11.11 NEXT_HOP part 1 net 100:1:10.0.0.0/8,next 172.16.15.15BGP(2): 172.16.11.11 send UPDATE (format) 100:1:192.168.3.0/8,next 172.16.15.15, metric 0, path 200, extended communityRT:1:1 RT:10000:111 RT:33333:888888888 RT:65535:999999999BGP(2): 2 updates (average = 118, maximum = 121)BGP(2): 172.16.11.11 updates replicated for neighbors: 172.16.11.11BGP(2): 172.16.11.11 update run completed, afi 2, ran for 0ms,neighbor version 17, start version 17, throttled to 17This example shows VPN address information from the BGP table and verifies that RT extended community attributes are replaced correctly:
Router# show ip bgp vpnv4 all 172.16.17.17BGP routing table entry for 100:1:172.16.17.17/32, version 6Paths: (1 available, best #1, no table)Advertised to update-groups:1100 300192.168.1.1 from 192.168.1.1 (172.16.13.13)Origin incomplete, localpref 100, valid, external, bestExtended Community: RT:100:1Additional References
The following sections provide references related to the MPLS VPN - Route Target Rewrite feature.
Related Documents
MPLS VPN interautonomous systems configuration tasks
VPN configuration tasks
BGP configuration tasks
Cisco IOS IP Routing Protocols Configuration Guide, Release 12.4
MPLS configuration tasks
Cisco IOS Multiprotocol Label Switching Configuration Guide, Release 12.4
Commands to configure and monitor BGP
•
•
•
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
Command Reference
This section documents only commands that are new or modified.
set extcomm-list delete
To allow the deletion of extended community attributes based on an extended community list, use the set extcomm-list delete command in route-map configuration mode. To negate a previous set extcomm-list detect command, use the no form of this command.
set extcomm-list extended-community-list-number delete
no set extcomm-list extended-community-list-number delete
Syntax Description
Command Modes
Route-map configuration
Command History
Usage Guidelines
This command removes extended community attributes of an inbound or outbound Border Gateway Protocol (BGP) update using a route map to filter and determine the extended community attribute to be deleted and replaced. Depending upon whether the route map is applied to the inbound or outbound update for a neighbor, each extended community that passes the route map permit clause and matches the given extended community list will be removed and replaced from the extended community attribute being received from or sent to the BGP neighbor.
Examples
The following example shows how to replace a route target 100:3 on an incoming update with a route target of 100:4 using an inbound route map extmap:
...Router(config-af)# neighbor 10.10.10.10 route-map extmap in...Router(config)# ip extcommunity-list 1 permit rt 100:3Router(config)# route-map extmap permit 10Router(config-route-map)# match extcommunity 1Router(config-route-map)# set extcomm-list 1 deleteRouter(config-route-map)# set extcommunity rt 100:4 additiveThe following example shows how to configure more than one replacement rule using the route-map configuration continue command. Prefixes with RT 100:2 are rewritten to RT 200:3 and prefixes with RT 100:4 are rewritten to RT 200:4. With the continue command, route-map evaluation proceeds even if a match is found in a previous sequence.
Router(config)# ip extcommunity-list 1 permit rt 100:3Router(config)# ip extcommunity-list 2 permit rt 100:4Router(config)# route-map extmap permit 10Router(config-route-map)# match extcommunity 1Router(config-route-map)# set extcomm-list 1 deleteRouter(config-route-map)# set extcommunity rt 200:3 additiveRouter(config-route-map)# continue 20Router(config)# route-map extmap permit 20Router(config-route-map)# match extcommunity 2Router(config-route-map)# set extcomm-list 2 deleteRouter(config-route-map)# set extcommunity rt 200:4 additiveRouter(config-route-map)# exitRouter(config)# route-map extmap permit 30Related Commands
Glossary
autonomous system—A collection of networks that share the same routing protocol and that are under the same system administration.
ASBR—autonomous system border router. A router that connects and exchanges information between two or more autonomous systems.
BGP—Border Gateway Protocol. The exterior border gateway protocol used to exchange routing information between routers in separate autonomous systems. BGP uses Transmission Control Protocol (TCP). Because TCP is a reliable protocol, BGP does not experience problems with dropped or fragmented data packets.
CE router—customer edge router. The customer router that connects to the provider edge (PE) router.
EBGP—External Border Gateway Protocol. A BGP session between routers in different autonomous systems. When a pair of routers in different autonomous systems are more than one IP hop away from each other, an EBGP session between those two routers is called multihop EBGP.
IBGP—Internal Border Gateway Protocol. A BGP session between routers within the same autonomous system.
IGP—Interior Gateway Protocol. Internet protocol used to exchange routing information within an autonomous system. Examples of common Internet IGPs include Internal Gateway Routing Protocol (IGRP), Open Shortest Path First (OSPF), and Routing Information Protocol (RIP).
LDP—Label Distribution Protocol. A standard protocol between MPLS-enabled routers to negotiate the labels (addresses) used to forward packets. The Cisco proprietary version of this protocol is the Tag Distribution Protocol (TDP).
LER—label edge router. The edge router that performs label imposition and disposition.
LSR—label switch router. The role of an LSR is to forward packets in an MPLS network by looking only at the fixed-length label.
MPLS—Multiprotocol Label Switching. A switching method that forwards IP traffic using a label. This label instructs the routers and the switches in the network where to forward the packets based on preestablished IP routing information.
NLRI—Network Layer Reachability Information. BGP sends routing update messages containing NLRI, which describes the route. In this context, an NLRI is a prefix. A BGP update message carries one or more NLRI prefixes and the attributes of a route for the NLRI prefixes. The route attributes include a BGP next-hop gateway address, community values, and other information.
P router—provider router. The core router in the service provider network that connects to provider edge (PE) routers. In a packet-switched star topology, a router that is part of the backbone and that serves as the single pipe through which all traffic from peripheral networks must pass on its way to other peripheral networks.
PE router—provider edge router. The label edge router (LER) in the service provider network that connects to the customer edge (CE) router.
RD—route distinguisher. An 8-byte value that is concatenated with an IPv4 prefix to create a unique VPN IPv4 (VPNv4) prefix.
RR—route reflector. A router that advertises, or reflects, IBGP learned routes to other IBGP peers without requiring a full network mesh.
RT—route target. Extended community attribute used to identify the VRF routing table into which a prefix is to be imported.
VPN—Virtual Private Network. A group of sites that, as a result of a set of administrative policies, can communicate with each other over a shared backbone.
VPNv4 prefix—IPv4 prefix preceded by an 8-byte route distinguisher. The VPN addresses are made unique by adding a route distinguisher to the front of the address.
VRF—VPN routing and forwarding instance. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table. In general, a VRF includes the routing information that defines a customer VPN site that is attached to a provider edge (PE) router.
Note
CCVP, the Cisco Logo, and the Cisco Square Bridge logo are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networking Academy, Network Registrar, Packet, PIX, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0704R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2003-2007 Cisco Systems, Inc. All rights reserved.
