 Feedback
|
Table Of Contents
Inter-AS Hybrid for MPLS VPN over IP Tunnels
Prerequisites for Inter-AS Hybrid for MPLS VPN over IP Tunnels
Restrictions for Inter-AS Hybrid for MPLS VPN over IP Tunnels
Information About Inter-AS Hybrid for MPLS VPN over IP Tunnels
BGP Distribution of VPN Routing Information
Advertising Tunnel Type and Tunnel Capabilities Between PE Routers—BGP
Configuring the PE Routers and Managing Address Space
Interautonomous System VPN—Back-to-Back VRF
MPLS VPN—Interautonomous System Support
Exchanging VPN Routing Information
MPLS VPN—Interautonomous System Configuration
Inter-AS Hybrid for MPLS VPN over IP Tunnels
Configuring Inter-AS Hybrid for MPLS VPN over IP Tunnels
Configuring EBGP Routing for the Exchange of VPNv4 Routes on Each Peer ASBR
Configuring VRFs on the MPLS VPNs over IP Tunnels ASBR
Verifying Inter-AS Hybrid over MPLS VPNs over IP Tunnels
Displaying VPN-IPv4 LFIB Entries
Configuration Example for Inter-AS Hybrid for MPLS VPN over IP Tunnels
PE1 Router Configuration Example—MPLS VPNs over IP Tunnels Service Provider
ASBR1 Router Configuration Example—MPLS VPNs over IP Tunnels Service Provider
ASBR2 Router Configuration Example—MPLS VPN Service Provider
PE2 Router Configuration Example—MPLS VPN Service Provider
Related Documents for MPLS VPN Interautonomous Systems
Related Documents for MPLS VPNS over IP Tunnels
Inter-AS Hybrid for MPLS VPN over IP Tunnels
Part Number OL-10922-01 (Rev B0), June 26, 2006The Inter-AS Hybrid for MPLS VPN over IP Tunnels feature allows a Multiprotocol Label Switching Virtual Private Network (MPLS VPN) to span autonomous systems (ASs) and VPN service providers when one of the VPN autonomous systems runs Layer 2 Tunneling Protocol version 3 (L2TPv3) in an MPLS VPN over IP Tunnels network. This feature allows the MPLS VPN over IP Tunnels network to present a standard MPLS VPN Inter-AS interface to a BGP peer in an adjacent MPLS AS. The Inter-AS Hybrid implementation combines elements of the existing MPLS/IP VPN and MPLS VPN Inter-AS features described in:
•
Interautonomous System VPN—Back-to-Back VRF
•
Feature History for the Inter-AS Hybrid for MPLS VPN over IP Tunnels
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
•
•
•
•
Prerequisites for Inter-AS Hybrid for MPLS VPN over IP Tunnels
•
•
4-port OC-3 POS ISE
8-port OC-3 POS ISE
16-port OC-3 POS ISE
4-port OC-12 POS ISE
1-port OC-48 POS ISE
4-port Channelized OC-12 POS ISE
1-port Channelized OC-48 POS ISE
4-port Gigabit Ethernet ISE
•
Engine 5 shared port adapters (SPAs):
1-port Channelized STM-1c/OC-3c to DS0
8-port Channelized T1/E1
1-port 10-Gigabit Ethernet
2-port Gigabit Ethernet
5-port Gigabit Ethernet
10-port Gigabit Ethernet
8-port Fast Ethernet
8-port 10/100 Ethernet
4-port OC3/STM4 POS
8-port OC3/STM4 POS
2-port OC12/STM4 POS
4-port OC12/STM4 POS
8-port OC12/STM4 POS
2-port OC48/STM16 POS/RPR
1-port OC192/STM64 POS/RPR
1-port OC192/STM64 POS/RPR
Engine 5 SPA Interface Processors (SIPs):
12000-SIP-600 (10G Engine 5 SPA Interface Processor
2.5G multiservice engine SPA Interface Processor
5G multiservice engine SPA Interface Processor
10G multiservice engine SPA Interface Processor
Restrictions for Inter-AS Hybrid for MPLS VPN over IP Tunnels
•
•
Information About Inter-AS Hybrid for MPLS VPN over IP Tunnels
To configure the Inter-AS Hybrid for MPLS VPN over IP Tunnels feature, you should understand the following concepts:
•
•
•
•
MPLS Virtual Private Networks
The IP Virtual Private Network (VPN) feature for Multiprotocol Label Switching (MPLS) allows a Cisco IOS network to deploy scalable IPv4 Layer 3 VPN backbone services. An IP VPN is the foundation companies use for deploying or administering services, including applications and data hosting network commerce and telephony services, to business customers.
Figure 1 shows an example of a VPN with a service provider (P) backbone network, service provider edge routers (PE), and customer edge routers (CE).
Figure 1 VPNs with a Service Provider Backbone
A VPN contains customer devices attached to the CE routers. These customer devices use VPNs to exchange information between devices. Only the PE routers are aware of the VPNs.
Each VPN is associated with one or more VPN routing/forwarding instances (VRFs). A VRF defines the VPN membership of a customer site attached to a PE router. A VRF consists of an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information included in the routing table.
A 1-to-1 relationship does not necessarily exist between customer sites and VPNs. A given site can be a member of multiple VPNs. However, a site can only associate with only one VRF. A customer site's VRF contains all of the routes available to the site from the VPNs of which it is a member.
Packet forwarding information is stored in the IP routing table and the CEF table for each VRF. A separate set of routing and CEF tables is maintained for each VRF. These tables prevent information from being forwarded outside a VPN, and also prevent packets that are outside a VPN from being forwarded to a router within the VPN.
VPN Route Target Communities
The distribution of VPN routing information is controlled through the use of VPN route target communities, implemented by Border Gateway Protocol (BGP) extended communities. Distribution of VPN routing information works as follows:
1.
2.
BGP Distribution of VPN Routing Information
A service provider edge (PE) router can learn an IP prefix from a customer edge (CE) router by static configuration, through a BGP session with the CE router, or through the routing information protocol (RIP) exchange with the CE router. The IP prefix is a member of the IPv4 address family. After it learns the IP prefix, the PE converts it into a VPN-IPv4 prefix by combining it with an 8-byte route distinguisher (RD). The generated prefix is a member of the VPN-IPv4 address family. It serves to uniquely identify the customer address, even if the customer site is using globally nonunique (unregistered private) IP addresses.
The route distinguisher used to generate the VPN-IPv4 prefix is specified by a configuration command associated with the VRF on the PE router.
BGP distributes reachability information for VPN-IPv4 prefixes for each VPN. BGP communication takes place at two levels: within IP domains, known as an autonomous systems (interior BGP or IBGP) and between autonomous systems (external BGP or EBGP). PE-PE or PE-RR (route reflector) sessions are IBGP sessions, and PE-CE sessions are EBGP sessions.
BGP propagates reachability information for VPN-IPv4 prefixes among PE routers by means of the BGP multiprotocol extensions (refer to RFC 2283, Multiprotocol Extensions for BGP-4) which define support for address families other than IPv4. It does this in a way that ensures that the routes for a given VPN are learned only by other members of that VPN, enabling members of the VPN to communicate with each other.
MPLS Forwarding
Based on routing information stored in the VRF IP routing table and VRF CEF table, packets are forwarded to their destination using MPLS.
A PE router binds a label to each customer prefix learned from a CE router and includes the label in the network reachability information for the prefix that it advertises to other PE routers. When a PE router forwards a packet received from a CE router across the provider network, it labels the packet with the label learned from the destination PE router. When the destination PE router receives the labeled packet, it removes the label and uses it to direct the packet to the correct CE router. Label forwarding across the provider backbone is based on either dynamic label switching or traffic engineered paths. A customer data packet carries two levels of labels when traversing the backbone:
1.
2.
MPLS VPNs over IP Tunnels
The MPLS VPNs over IP Tunnels feature introduces the capability to deploy Layer 3 Virtual Private Network (VPN) services, as proposed in RFC 2547, BGP/MPLS VPNs, over an IP core network using L2TPv3 multipoint tunneling instead of Multiprotocol Label Switching (MPLS). This feature allows L2TPv3 tunnels to be configured as multipoint tunnels to transport IP VPN services across the core IP network. Because multipoint tunnels support multiple endpoints, only one tunnel must be configured on each Provider Edge (PE) router. This feature also introduces a simple packet validation mechanism to enforce VPN integrity.
VPN services are traditionally deployed over IP core networks by configuring MPLS or through L2TPv3 tunnels using point-to-point links. The MPLS VPN over IP Tunnels feature allows you to deploy Layer 3 VPN services by configuring multipoint L2TPv3 tunnels over an existing IP core network. This feature is configured only on PE routers and requires no configuration on the core routers.
The L2TPv3 multipoint tunnel network allows Layer 3 VPN services to be carried through the core without the configuration of MPLS. L2TPv3 multipoint tunnelling supports multiple tunnel endpoints, which creates a full mesh topology that requires only one tunnel to be configured on each PE router. This feature provides the capability for VPN traffic to be carried from enterprise networks across cooperating service provider core networks to remote sites.
Note
Advertising Tunnel Type and Tunnel Capabilities Between PE Routers—BGP
Border Gateway Protocol (BGP) is used to advertise the tunnel endpoints and the subaddress family identifier (SAFI) specific attributes (which contains the tunnel type, and tunnel capabilities). This feature introduces the tunnel SAFI and the BGP SAFI-Specific Attribute (SSA) attribute.
The tunnel SAFI:
•
•
The BGP SSA:
•
•
These attributes allow BGP to distribute tunnel encapsulation information between PE routers. Virtual Private Network IP Version 4 (VPNv4) traffic is routed through these tunnels. The next hop, advertised in BGP VPNv4 updates, determines which tunnel to use for routing tunnel traffic.
Configuring the PE Routers and Managing Address Space
One multipoint L2TPv3 tunnel is configured on each PE router. To create the VPN, you configure a unique Virtual Routing and Forwarding (VRF) instance. The tunnel that transports the VPN traffic across the core network resides in its own address space. A special purpose VRF called a Resolve in VRF (RiV) is created to manage the tunnel address space. You also configure the address space under the RiV that is associated with the tunnel and a static route in the RiV to route outgoing traffic through the tunnel.
Packet Validation Mechanism
The MPLS VPNs over IP Tunnels feature provides a simple mechanism to validate received packets from appropriate peers. The multipoint L2TPv3 tunnel header is automatically configured with a 64-bit cookie and L2TPv3 session ID.
This packet validation mechanism:
•
•
Interautonomous System VPN—Back-to-Back VRF
The Interautonomous System VPN—Back-to-Back VRF feature allows separate autonomous systems from different service providers to communicate in an MPLS or IP VPN. This VPN configuration does not require MPLS at the border between autonomous systems.
Figure 2 shows a sample Interautonomous System VPN—Back-to-Back VRF configuration. No signaling is sent between the autonomous system boundary routers (ASBRs). One VPN interface and one VPN Routing and Forwarding (VRF) table are configured on each ASBR for each customer VPN whose routes need to be passed between ASs. The ASBRs are interconnected through multiple logical connections. You can use eBGP to distribute unlabeled IPv4 addresses to a peer ASBR.
Figure 2 Inter-AS Service-Providers Using Back-to-Back VRFs in a VPN
In an Interautonomous System VPN—Back-to-Back VRF configuration, information is transmitted between autonomous systems as follows:
1.
2.
In Figure 2, VPN service providers exchange routes across a back-to-back VRF connection. Each VRF instance:
•
•
The PE-ASBR routers in each autonomous system serve as gateways that are used to exchange IPv4 routes. The link between peer PE-ASBRs supports the following PE-CE protocols: external Border Gateway Protocol (eBGP), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Routing Information Protocol (RIPv2), and static routing. VPN routes are sent in IPv4 format.
Note
For the Interautonomous System VPN-Back-to-Back VRF feature, when you configure VPN routing and forwarding (VRF) instances and sessions on a PE-ASBR router in a service provider (autonomous system) network, you must:
•
•
•
MPLS VPN—Interautonomous System Support
The MPLS VPN—Interautonomous System Support feature provides seamless integration of autonomous systems and service providers. Separate autonomous systems from different service providers can communicate by exchanging IPv4 Network Layer Reachability Information (NLRI) in the form of VPN-IPv4 addresses. The autonomous systems' border edge routers use Exterior Border Gateway Protocol (EBGP) to exchange that information. Then, an Interior Gateway Protocol (IGP) distributes the network layer information for VPN-IPv4 prefixes throughout each VPN and each autonomous system. Routing information uses the following protocols:
•
–
–
•
An MPLS VPN with interautonomous system support allows a service provider to provide to customers scalable Layer 3 VPN services, such as web hosting, application hosting, interactive learning, electronic commerce, and telephony service. A VPN service provider supplies a secure, IP-based network that shares resources on one or more physical networks.
The primary function of an EBGP is to exchange network reachability information between autonomous systems, including information about the list of autonomous system routes. The autonomous systems use EGBP border edge routers to distribute the routes, which include label switching information. Each border edge router rewrites the next-hop and MPLS labels.
Figure 3 shows how the MPLS VPN-Interautonomous System Support feature is used to set up an MPLS VPN consisting of two separate autonomous systems. Each autonomous system operates under different administrative control and runs a different IGP. Service providers exchange routing information through EBGP border edge routers (ASBR1 and ASBR2).
Figure 3 Inter-AS Service Providers Using EBGP in an MPLS VPN
An MPLS VPN-Interautonomous System Support configuration uses the following process to transmit information:
1.
2.
3.
–
–
4.
–
–
Exchanging VPN Routing Information
Autonomous systems exchange VPN routing information (routes and labels) to establish connections. To control connections between autonomous systems, the PE routers and EBGP border edge routers maintain a label forwarding information base (LFIB). The LFIB manages the labels and routes that the PE routers and EBGP border edge routers receive during the exchange of VPN information.
Figure 4 illustrates the exchange of VPN route and label information between autonomous systems.
Figure 4 Exchanging Routes and Labels Between Autonomous Systems in an Inter-AS VPN Network
The autonomous systems use the following guidelines to exchange VPN routing information:
•
–
–
–
•
•
Packet Forwarding
Figure 5 illustrates how packets are forwarded between autonomous systems in an interprovider network using the following packet forwarding method.
Figure 5 Forwarding Packets Between Autonomous Systems in an Inter-AS VPN Network
Packets are forwarded to their destination by means of MPLS. Packets use the routing information stored in the LFIB of each PE router and EBGP border edge router.
The service provider VPN backbone uses dynamic label switching to forward labels.
Each autonomous system uses standard multilevel labeling to forward packets between the edges of the autonomous system routers (for example, from CE4 to PE2). Between autonomous systems, only one level of labeling is used, corresponding to the advertised route.
A data packet carries two levels of labels when traversing the Inter-AS VPN backbone:
•
•
MPLS VPN—Interautonomous System Configuration
For the MPLS VPN-Interautonomous System feature, it is not necessary to:
•
•
•
Inter-AS Hybrid for MPLS VPN over IP Tunnels
Starting in Cisco IOS Release 12.0(31)S, you can configure a "hybrid" version of the MPLS VPN—Interautonomous System Support feature on supported ISE interfaces configured for MPLS VPNs over IP Tunnels in a Cisco 12000 series router. The router must be deployed as an ASBR router in a service-provider core network.
The Inter-AS Hybrid for MPLS VPNs over IP Tunnels feature:
•
•
Figure 6 MPLS VPNs over IP Tunnels and MPLS Service Providers in an Inter-AS MPLS VPN
Figure 6 shows how the Inter-AS Hybrid for MPLS VPNs over IP Tunnels feature is used in a VPN interprovider network to interconnect an autonomous system configured for MPLS VPNs over IP Tunnels with another MPLS-based autonomous system.
In the Inter-AS Hybrid for MPLS VPNs over IP Tunnels implementation:
•
•
Note
The Inter-AS Hybrid for MPLS VPNs over IP Tunnels configuration uses the following process to transmit information:
1.
2.
Note
The MPLS VPN-Interautonomous System implementation does not require customer-specific VFR tables. Only one ASBR interface is used to exchange VPNv4 prefixes with the peer ASBR. For more information, refer to MPLS VPN—Interautonomous Systems Support.3.
4.
5.
6.
This process is transparent to the peer ASBR in the MPLS-based autonomous system.
Note
Figure 7 illustrates the exchange of VPN route and label information in a VPN interprovider network between an autonomous system configured for MPLS VPNs over IP Tunnels and an MPLS-based autonomous system. In this example, a customer in VPN A transmits information through CE1 to a another customer site in VPN A through CE4.
Figure 7 Exchanging Routes and Labels Between MPLS and MPLS VPNs over IP Tunnels Autonomous Systems in an Inter-AS Hybrid Configuration
In an Inter-AS Hybrid for MPLS VPNs over IP Tunnels configuration, the autonomous systems exchange VPN routing information (routes and labels) to establish connections in the same way as in an MPLS VPN—Interautonomous System Support configuration, as described in Exchanging VPN Routing Information.
Figure 8 illustrates how packets are forwarded between autonomous systems in an Inter-AS Hybrid for MPLS VPNs over IP Tunnels configuration, using the same packet forwarding method described in Packet Forwarding for an MPLS VPN—Interautonomous System Support configuration. In this example, a customer in VPN A transmits information through CE4 and is received at another customer site in VPN A through CE1.
Figure 8 Forwarding Packets Between MPLS and MPLS VPNs over IP Tunnels Autonomous Systems in an Inter-AS Hybrid Configuration
A data packet carries two levels of labels when traversing the Inter-AS VPN backbone:
•
•
Configuring Inter-AS Hybrid for MPLS VPN over IP Tunnels
This section contains the following procedures:
•
•
•
Preconfiguration Procedures
Before you configure EBGP routing in an MPLS VPN between a VPN autonomous system that runs L2TPv3 in an MPLS VPNs over IP Tunnels configuration and an adjacent MPLS VPN, ensure that:
•
•
•
The configuration tasks described in this section are based on these configuration tasks.
Perform (as appropriate to the existing network configuration) the following tasks as described in the Cisco IOS Switching Services Configuration Guide (the "Configuring Multiprotocol Label Switching chapter).
•
•
•
•
Configuring EBGP Routing for the Exchange of VPNv4 Routes on Each Peer ASBR
Note
To configure the peer ASBR router in an interautonomous service-provider network configured for MPLS VPNs over IP Tunnels to exchange VPN routes using EBGP with an adjacent MPLS-based autonomous system, use the following commands starting in EXEC mode.
Note
Configuring VRFs on the MPLS VPNs over IP Tunnels ASBR
Note
To define VPN routing instances on the peer ASBR router in each autonomous system, use the following commands beginning in global configuration mode:
Verifying Inter-AS Hybrid over MPLS VPNs over IP Tunnels
Perform the tasks in this section to verify the Inter-AS Hybrid over MPLS VPNs over IP Tunnels configuration on each peer ASBR.
Verifying VPN Operation
To verify VPN operation, use the following commands in privileged EXEC mode:
Displaying VPN-IPv4 LFIB Entries
To display the VPN-IPv4 label forwarding information base (LFIB) entries at the border edge routers in the autonomous systems, use the following commands starting in EXEC mode:
The following example shows the appearance of VPN-IPv4 LFIB entries when you use the show tag-switching forwarding-table privileged EXEC command:
Router# show tag-switching forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hoptag tag or VC or Tunnel Id switched interface33 33 10.120.4.0/24 0 Hs0/0 point2point35 27 100:12:10.200.0.1/32 \0 Hs0/0 point2pointIn this example, the Prefix field appears as a VPN-IPv4 route distinguisher (RD), plus the prefix. If the value is longer than the Prefix column (as illustrated in the last line of the example), the output automatically wraps onto the next line in the forwarding table to preserve column alignment.
Configuration Example for Inter-AS Hybrid for MPLS VPN over IP Tunnels
This section describes a configuration example for Inter-AS Hybrid for MPLS VPNs over IP Tunnels, and consists of the following steps:
•
•
•
•
Note
The sample configuration shown in Figure 9 is for two autonomous-system MPLS VPN service providers: an MPLS VPNs over IP Tunnels-based network and an MPLS-based network.
Figure 9 Configuring Inter-AS for MPLS VPNs over IP Tunnels in an MPLS VPN Network
In this interautonomous-system network, the MPLS VPNs over IP Tunnels-based service provider runs IS-IS as its IGP. The MPLS-based service provider runs OSPF as its IGP. Two VPNs (VPN 1 and VPN 2) interconnect over the two service-provider networks.
Each service-provider network is configured to rewrite route target values. (The route distinguisher (rd) values cannot be rewritten.) Route targets are carried as extended community attributes in BGP VPNv4 updates. Route target extended community attributes are used to identify a set of sites and VPN routing/forwarding instances (VRFs) that can receive routes with a configured route target. Each ASBR performs route target replacement at the autonomous system border when peer ASBRs exchange VPNv4 prefixes. For more information, refer to MPLS VPN—Route Target Rewrite.
Note
Prerequisites
In the MPLS VPNS over IP Tunnels-based network, the following prerequisites exist:
•
•
Note
It is not necessary to configure the ISE line cards in the ASBR in the MPLS-based autonomous system (ASBR2) in feature mode.
PE1 Router Configuration Example—MPLS VPNs over IP Tunnels Service Provider
The following example shows a sample configuration for the PE1 router in the MPLS VPNs over IP Tunnels-based autonomous system shown in Figure 9 and specifies the following:
•
•
•
•
•
hw-module slot 2 np mode featureip vrf RIVrd 0:0ip vrf vpn1rd 200:1route-target export 200:1route-target import 200:1ip vrf vpn2rd 200:2route-target export 200:2route-target import 200:2interface Loopback0ip address 10.127.13.1 255.255.255.255no ip directed-broadcastinterface Loopback1ip vrf forwarding vpn1ip address 10.127.44.1 255.255.255.255no ip directed-broadcastinterface Loopback2ip vrf forwarding vpn2ip address 10.127.45.1 255.255.255.255no ip directed-broadcastinterface Tunnel0ip vrf forwarding RIVip address 192.168.13.1 255.255.255.255no ip redirectsno ip directed-broadcasttunnel source Loopback0tunnel mode l3vpn l2tpv3 multipointinterface POS2/0ip vrf forwarding vpn1ip address 192.168.144.1 255.255.255.252no ip directed-broadcastcrc 32clock source internalpos ais-shutpos scramble-atminterface POS2/1ip vrf forwarding vpn2ip address 192.168.144.1 255.255.255.252no ip directed-broadcastcrc 32clock source internalpos scramble-atminterface POS 3/0ip address 192.168.79.2 255.255.255.0no ip directed-broadcastip router isis P1encapsulation pppcrc 32clock source internalpos ais-shutpos scramble-atmrouter ospf 100 vrf vpn1router-id 192.168.44.1domain-id 192.168.0.0log-adjacency-changesredistribute bgp 200 metric 1000 subnetsnetwork 192.168.144.1 0.0.0.3 area 0router ospf 101 vrf vpn2router-id 192.168.45.1log-adjacency-changesredistribute bgp 200 metric 1000 subnetsnetwork 192.168.144.1 0.0.0.3 area 0router isis P1net 47.0023.0001.0000.0001.0002.0001.1921.6813.0001.00is-type level-1metric-style widepassive-interface Loopback0router bgp 200bgp router-id 192.168.13.1no bgp fast-external-falloverbgp maxas-limit 70no bgp default route-target filterbgp log-neighbor-changesbgp deterministic-medtimers bgp 45 135neighbor partner1 peer-groupneighbor partner1 remote-as 200neighbor partner1 update-source Loopback0neighbor partner1 version 4neighbor 192.168.112.1 peer-group partner1neighbor 192.168.112.2 peer-group partner1address-family ipv4redistribute connectedredistribute static route-map static-mbgpneighbor partner1 activateneighbor partner1 send-community extendedneighbor 192.168.112.1 peer-group partner1neighbor 192.168.112.2 peer-group partner1default-metric 1no auto-summaryno synchronizationexit-address-familyaddress-family ipv4 tunnelneighbor partner1 activateneighbor partner1 send-community extendedneighbor 192.168.112.1 peer-group partner1neighbor 192.168.112.2 peer-group partner1exit-address-familyaddress-family vpnv4neighbor partner1 activateneighbor partner1 send-community extendedneighbor partner1 next-hop-selfneighbor partner1 route-map RIV-nexthop inneighbor 192.168.112.1 peer-group partner1neighbor 192.168.112.1 route-map RIV-nexthop inneighbor 192.168.112.2 peer-group partner1neighbor 192.168.112.2 route-map RIV-nexthop inexit-address-familyaddress-family ipv4 vrf vpn2redistribute connectedredistribute staticredistribute ospf 101 vrf vpn2 match internal external 1 external 2no auto-summaryno synchronizationexit-address-familyaddress-family ipv4 vrf vpn1redistribute connectedredistribute staticredistribute ospf 100 vrf vpn1 match internal external 1 external 2no auto-summaryno synchronizationexit-address-familyaddress-family ipv4 vrf RIVno auto-summaryno synchronizationexit-address-familyip classlessip route vrf RIV 0.0.0.0 0.0.0.0 Tunnel0ip bgp-community new-formatroute-map RIV-nexthop permit 10set ip next-hop in-vrf RIVASBR1 Router Configuration Example—MPLS VPNs over IP Tunnels Service Provider
The following example shows a sample configuration for the ASBR1 router in the MPLS VPNs over IP Tunnels-based autonomous system shown in Figure 9 and specifies the following:
•
•
•
•
•
•
hw-module slot 1 np mode featureip subnet-zeroip vrf RIVrd 0:0ip vrf vpn1rd 200:1route-target export 200:1route-target import 200:1ip vrf vpn2rd 200:2route-target export 200:2route-target import 200:2interface Loopback0ip address 10.127.112.1 255.255.255.255no ip directed-broadcastno ip route-cacheinterface Tunnel0ip vrf forwarding RIVip address 10.127.112.1 255.255.255.255no ip redirectsno ip directed-broadcasttunnel source Loopback0tunnel mode l3vpn l2tpv3 multipointinterface GigabitEthernet1/0ip address 192.168.10.161 255.255.255.252no ip directed-broadcastmpls bgp forwardingtag-switching ipinterface POS2/0ip address 192.168.10.88 255.255.255.252no ip directed-broadcastip router isis P1crc 32clock source internalpos ais-shutpos scramble-atmclns router isis P1router isis P1net 47.0023.0001.0000.0001.0002.0001.1921.6811.0012.00is-type level-1metric-style widepassive-interface Loopback0router bgp 200bgp router-id 192.168.112.1no bgp fast-external-falloverbgp maxas-limit 70bgp log-neighbor-changesbgp deterministic-medbgp graceful-restart restart-time 120bgp graceful-restart stalepath-time 360bgp graceful-restarttimers bgp 45 135neighbor partner1 peer-groupneighbor partner1 remote-as 200neighbor partner1 update-source Loopback0neighbor partner1 version 4neighbor 10.161.1.6 remote-as 100neighbor 10.161.1.6 update-source GigabitEthernet1/0neighbor 192.168.13.1 peer-group partner1neighbor 192.168.112.2 peer-group partner1address-family ipv4redistribute staticneighbor partner1 activateneighbor partner1 send-community extendedneighbor partner1 next-hop-selfneighbor 10.161.1.6 activateneighbor 10.161.1.6 send-community bothneighbor 10.161.1.6 send-labelneighbor 192.168.13.1 peer-group partner1neighbor 192.168.112.2 peer-group partner1default-metric 1no auto-summaryno synchronizationexit-address-familyaddress-family ipv4 tunnelneighbor partner1 activateneighbor partner1 send-community extendedneighbor 192.168.13.1 peer-group partner1exit-address-familyaddress-family vpnv4neighbor partner1 activateneighbor partner1 send-community extendedneighbor partner1 next-hop-selfneighbor partner1 route-map RIV-nexthop inneighbor 10.161.1.6 activateneighbor 10.161.1.6 send-community bothneighbor 10.161.1.6 prefix-list filter-in inneighbor 10.161.1.6 route-map rtwrite inneighbor 192.168.13.1 peer-group partner1neighbor 192.168.13.1 route-map RIV-nexthop inexit-address-familyaddress-family ipv4 vrf vpn2no auto-summaryno synchronizationexit-address-familyaddress-family ipv4 vrf vpn1no auto-summaryno synchronizationexit-address-familyaddress-family ipv4 vrf RIVno auto-summaryno synchronizationexit-address-familyip classlessip route vrf RIV 0.0.0.0 0.0.0.0 Tunnel0ip extcommunity-list 1 permit rt 100:1ip extcommunity-list 2 permit rt 100:2ip bgp-community new-formatip as-path access-list 1 deny _6451[2-9]_ip as-path access-list 1 deny _645[2-9][0-9]_ip as-path access-list 1 deny _64[6-9][0-9][0-9]_ip as-path access-list 1 deny _65[0-9][0-9][0-9]_ip as-path access-list 1 deny \(*\)ip as-path access-list 1 permit .*ip prefix-list filter-in seq 20 deny 10.0.0.0/8 le 32ip prefix-list filter-in seq 30 deny 127.0.0.0/8 le 32ip prefix-list filter-in seq 40 deny 128.0.0.0/16 le 32ip prefix-list filter-in seq 50 deny 169.254.0.0/16 le 32ip prefix-list filter-in seq 60 deny 172.16.0.0/12 le 32ip prefix-list filter-in seq 70 deny 191.255.0.0/16 le 32ip prefix-list filter-in seq 80 deny 192.0.2.0/24 le 32ip prefix-list filter-in seq 90 deny 192.168.0.0/16 le 32ip prefix-list filter-in seq 100 deny 223.255.255.0/24 le 32ip prefix-list filter-in seq 110 deny 224.0.0.0/3 le 32ip prefix-list filter-in seq 120 deny 14.0.50.0/24ip prefix-list filter-in seq 125 deny 13.0.4.0/30ip prefix-list filter-in seq 130 permit 0.0.0.0/0 ge 8no logging traproute-map RIV-nexthop permit 10set ip next-hop in-vrf RIVroute-map rtwrite permit 10match extcommunity 1set extcommunity rt 200:1route-map rtwrite permit 20match extcommunity 2set extcommunity rt 200:2ASBR2 Router Configuration Example—MPLS VPN Service Provider
The following example shows a sample configuration for the ASBR2 router in the MPLS-based autonomous system shown in Figure 9 and specifies the following:
•
•
•
•
•
interface Loopback0ip address 10.127.168.229 255.255.255.255no ip directed-broadcastinterface POS3/0ip address 192.168.10.170 255.255.255.252no ip directed-broadcastmpls label protocol ldptag-switching ipcrc 32clock source internalpos scramble-atminterface GigabitEthernet5/0ip address 192.168.10.161 255.255.255.252no ip directed-broadcastmpls bgp forwardingtag-switching ipno negotiation autorouter ospf 100log-adjacency-changesnetwork 10.170.1.0 0.0.0.3 area 0network 192.168.229.1 0.0.0.0 area 0router bgp 100no bgp default route-target filterbgp log-neighbor-changesbgp graceful-restart restart-time 120bgp graceful-restart stalepath-time 360bgp graceful-restartneighbor 10.161.1.5 remote-as 200neighbor 10.161.1.5 update-source GigabitEthernet5/0neighbor 192.168.82.1 remote-as 100neighbor 192.168.82.1 update-source Loopback0address-family ipv4neighbor 10.161.1.5 activateneighbor 10.161.1.5 send-community bothneighbor 10.161.1.5 send-labelneighbor 192.168.82.1 activateneighbor 192.168.82.1 next-hop-selfno auto-summaryno synchronizationexit-address-familyaddress-family vpnv4neighbor 10.161.1.5 activateneighbor 10.161.1.5 send-community bothneighbor 10.161.1.5 route-map rtwrite inneighbor 192.168.82.1 activateneighbor 192.168.82.1 send-community bothneighbor 192.168.82.1 next-hop-selfexit-address-familyip classlessip extcommunity-list 1 permit rt 200:1ip extcommunity-list 2 permit rt 200:2route-map rtwrite permit 10match extcommunity 1set extcommunity rt 100:1route-map rtwrite permit 20match extcommunity 2set extcommunity rt 100:2PE2 Router Configuration Example—MPLS VPN Service Provider
The following example shows a sample configuration for the PE2 router in the MPLS-based autonomous system shown in Figure 9 and specifies the following:
•
•
•
•
•
ip vrf vpn1rd 100:1route-target export 100:1route-target import 100:1ip vrf vpn2rd 100:2route-target export 100:2route-target import 100:2interface Loopback0ip address 10.127.168.82 255.255.255.255no ip directed-broadcastinterface GigabitEthernet5/0ip vrf forwarding vpn2ip address 192.168.0.11.180 255.255.255.252no ip directed-broadcastno negotiation autointerface POS7/0ip address 192.168.10.170 255.255.255.252no ip directed-broadcastmpls label protocol ldptag-switching ipcrc 32clock source internalpos scramble-atminterface POS7/1ip vrf forwarding vpn1ip address 192.168.10.180 255.255.255.252no ip directed-broadcastcrc 32clock source internalpos scramble-atmrouter ospf 101 vrf vpn1log-adjacency-changesredistribute bgp 100 metric 1000 subnetsnetwork 10.180.1.0 0.0.0.3 area 0router ospf 102 vrf vpn2log-adjacency-changesredistribute bgp 100 metric 1000 subnetsnetwork 10.180.1.0 0.0.0.3 area 0router ospf 100log-adjacency-changesnetwork 10.170.1.0 0.0.0.3 area 0network 192.168.82.1 0.0.0.0 area 0router bgp 100bgp log-neighbor-changesneighbor 192.168.229.1 remote-as 100neighbor 192.168.229.1 update-source Loopback0address-family ipv4neighbor 192.168.229.1 activateno auto-summaryno synchronizationexit-address-familyaddress-family vpnv4neighbor 192.168.229.1 activateneighbor 192.168.229.1 send-community bothexit-address-familyaddress-family ipv4 vrf vpn2redistribute connectedredistribute ospf 102 vrf vpn2 match internal external 1 external 2no auto-summaryno synchronizationexit-address-familyaddress-family ipv4 vrf vpn1redistribute connectedredistribute ospf 101 vrf vpn1 match internal external 1 external 2no auto-summaryno synchronizationexit-address-familyAdditional References
The following sections provide references related to the Inter-AS Hybrid for MPLS VPNs over IP Tunnels feature.
Related Documents for MPLS VPN Interautonomous Systems
MPLS VPN interautonomous systems: configuration tasks and commands
Virtual Private Network (VPN) configuration tasks
MPLS Virtual Private Networks (VPNs)
An explanation of how Border Gateway Protocol (BGP) works and how you can use it to participate in routing with other networks that run BGP
Border Gateway Protocol (BGP) configuration tasks
"Configuring BGP" chapter in the Cisco IOS IP Configuration Guide, Release 12.2
An explanation of the purpose of the Border Gateway Protocol and the BGP route selection process, and how to use BGP attributes in route selection
"Border Gateway Protocol" chapter in the Internetworking Technology Overview
Multiprotocol Label Switching (MPLS) configuration tasks
"Configuring Multiprotocol Label Switching" chapter in the Cisco IOS Switching Services Configuration Guide, Release 12.3
Commands to configure and monitor BGP
"BGP Commands" chapter in the Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols, Release 12.2
Related Documents for MPLS VPNS over IP Tunnels
MPLS VPNs over IP Tunnels: configuration tasks and commands
CEF switching
Cisco IOS Switching Services Configuration Guide, Release 12.3
QoS—Tunnel Marking
VPN configuration
Cisco IOS Dial Technologies Configuration Guide, Release 12.3 and Cisco IOS Switching Services Configuration Guide, Release 12.3
VPN Routing and Forwarding (VRF) instances
Cisco IOS Switching Services Configuration Guide, Release 12.3
Standards
MIBs
No new or modified MIBs are supported by this feature.
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator at:
RFCs
Technical Assistance
Command Reference
There are no new Cisco IOS commands introduced with this feature.
All commands used with this feature are described in the following Cisco IOS documentation:
•
•
•
•
Copyright © 2006 Cisco Systems, Inc. All rights reserved.
