- Table of Contents
- Related Documents
-
Title | Size | Download |
---|---|---|
04-MPLS L3VPN Configuration | 1.22 MB |
Table of Contents
MPLS L3VPN Routing Information Advertisement
MPLS L3VPN Configuration Task List
Associating a VPN Instance with an Interface
Configuring Route Related Attributes of a VPN Instance
Configuring a Tunneling Policy of a VPN Instance
Configuring Route Advertisement between PE and CE
Configuring Route Advertisement Between PEs
Configuring Routing Features for BGP VPNv4 Subaddress Family
Configuring Inter-Provider VPN
Configuring Inter-Provider VPN Option A
Configuring Inter-Provider VPN Option B
Configuring Inter-Provider VPN Option C
Configuring a Loopback Interface
Advertising Routes of a Loopback Interface
Configuring BGP AS Number Substitution
Displaying and Maintaining MPLS L3VPN
Displaying and Maintaining MPLS L3VPN
MPLS L3VPN Configuration Examples
Example for Configuring MPLS L3VPNs
Example for Configuring Inter-Provider VPN Option A
Example for Configuring Inter-Provider VPN Option B
Example for Configuring Inter-Provider VPN Option C
Example for Configuring Carrier’s Carrier
Example for Configuring Nested VPN
Example for Configuring OSPF Sham Links
Example for Configuring BGP AS Number Substitution
When configuring MPLS L3VPN, go to these sections for information you are interested in:
l MPLS L3VPN Configuration Task List
l Displaying and Maintaining MPLS L3VPN
l MPLS L3VPN Configuration Examples
l The term router in this document refers to a router in a generic sense or a Layer 3 switch.
l This chapter covers only introduction to and configuration of MPLS L3VPN. For information about MPLS basics, BGP, and VPN, refer to the relevant manuals or volumes.
l At present, to support MPLS or MPLS-based functions, S7500E series Ethernet switches must use the LSQ1SRP1CB engine or use no other LPUs but the EA series.
MPLS L3VPN Overview
This section covers these topics:
l MPLS L3VPN Packet Forwarding
l MPLS L3VPN Networking Schemes
l MPLS L3VPN Routing Information Advertisement
Introduction to MPLS L3VPN
MPLS L3VPN is a kind of PE-based L3VPN technology for service provider VPN solutions. It uses BGP to advertise VPN routes and uses MPLS to forward VPN packets on service provider backbones.
MPLS L3VPN provides flexible networking modes, excellent scalability, and convenient support for MPLS QoS and MPLS TE. Hence, it is widely used.
The MPLS L3VPN model consists of three kinds of devices:
l Customer edge device (CE): A CE resides on a customer network and has one or more interfaces directly connected with service provider networks. It can be a router, a switch, or a host. It neither can "sense" the existence of any VPN nor needs to support MPLS.
l Provider edge router (PE): A PE resides on a service provider network and connects one or more CEs to the network. On an MPLS network, all VPN processing occurs on the PEs.
l Provider (P) router: A P router is a backbone router on a service provider network. It is not directly connected with any CE. It only needs to be equipped with basic MPLS forwarding capability.
Figure 1-1 shows the MPLS L3VPN model.
Figure 1-1 Network diagram for MPLS L3VPN model
CEs and PEs mark the boundary between the service providers and the customers.
A CE is usually a router. After a CE establishes adjacency with a directly connected PE, it advertises its VPN routes to the PE and learns remote VPN routes from the PE. A CE and a PE use BGP/IGP to exchange routing information. You can also configure static routes between them.
After a PE learns the VPN routing information of a CE, it uses BGP to exchange VPN routing information with other PEs. A PE maintains routing information about only VPNs that are directly connected, rather than all VPN routing information on the provider network.
A P router maintains only routes to PEs. It does not need to know anything about VPN routing information.
When VPN traffic travels over the MPLS backbone, the ingress PE functions as the ingress LSR, the egress PE functions as the egress LSR, while P routers function as the transit LSRs.
MPLS L3VPN Concepts
Site
Site is often mentioned in the VPN. Its meanings are described as follows:
l A site is a group of IP systems with IP connectivity that does not rely on any service provider network to implement.
l The classification of a site depends on the topology relationship of the devices, rather than the geographical positions, though the devices at a site are adjacent to each other geographically in most cases.
l The devices at a site can belong to multiple VPNs.
l A site is connected to a provider network through one or more CEs. A site can contain many CEs, but a CE can belong to only one site.
Sites connected to the same provider network can be classified into different sets by policies. Only the sites in the same set can access each other through the provider network. Such a set is called a VPN.
Address space overlapping
Each VPN independently manages the addresses that it uses. The assembly of such addresses for a VPN is called an address space.
The address spaces of VPNs may overlap. For example, if both VPN 1 and VPN 2 use the addresses on network segment 10.110.10.0/24, address space overlapping occurs.
VPN instance
In MPLS VPN, routes of different VPNs are identified by VPN instance.
A PE creates and maintains a separate VPN instance for each VPN at a directly connected site. Each VPN instance contains the VPN membership and routing rules of the corresponding site. If a user at a site belongs to multiple VPNs at the same time, the VPN instance of the site contains information about all the VPNs.
For independency and security of VPN data, each VPN instance on a PE maintains a relatively independent routing table and a separate label forwarding information base (LFIB). VPN instance information contains these items: the LFIB, IP routing table, interfaces bound to the VPN instance, and administration information of the VPN instance. The administration information of the VPN instance includes the route distinguisher (RD), route filtering policy, and member interface list.
VPN-IPv4 address
Traditional BGP cannot process VPN routes which have overlapping address spaces. If, for example, both VPN 1 and VPN 2 use addresses on the segment 10.110.10.0/24 and each advertise a route to the segment, BGP selects only one of them, which results in loss of the other route.
PEs use MP-BGP to advertise VPN routes, and use VPN-IPv4 address family to solve the problem with traditional BGP.
A VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD, followed by a 4-byte IPv4 address prefix, as shown in Figure 1-2.
Figure 1-2 VPN-IPv4 address structure
When a PE receives an ordinary IPv4 route from a CE, it must advertise the VPN route to the peer PE. The uniqueness of a VPN route is implemented by adding an RD to the route.
A service provider can independently assign RDs provided the assigned RDs are unique. Thus, a PE can advertise different routes to VPNs even if the VPNs are from different service providers and are using the same IPv4 address space.
You are recommended to configure a distinct RD for each VPN instance on a PE, guaranteeing that routes to the same CE use the same RD. The VPN-IPv4 address with an RD of 0 is in fact a globally unique IPv4 address.
By prefixing a distinct RD to a specific IPv4 address prefix, you get a globally unique VPN IPv4 address prefix.
An RD can be related to an autonomous system (AS) number, in which case it is the combination of the AS number and a discretionary number; or be related to an IP address, in which case it is the combination of the IP address and a discretionary number.
An RD can be in either of the following two formats distinguished by the Type field:
l When the value of the Type field is 0, the Administrator subfield occupies two bytes, the Assigned number subfield occupies four bytes, and the RD format is: 16-bit AS number:32-bit user-defined number. For example, 100:1.
l When the value of the Type field is 1, the Administrator subfield occupies four bytes, the Assigned number subfield occupies two bytes, and the RD format is: 32-bit IPv4 address:16-bit user-defined number. For example, 172.1.1.1:1.
For the global uniqueness of an RD, you are not recommended to set the Administrator subfield to any private AS number or private IP address.
VPN target attributes
MPLS L3VPN uses the BGP extended community attributes called VPN target attributes, or route target attributes, to control the advertisement of VPN routing information.
A VPN instance on a PE supports two types of VPN target attributes:
l Export target attribute: A local PE sets this type of VPN target attribute for VPN-IPv4 routes learnt from directly connected sites before advertising them to other PEs.
l Import target attribute: A PE checks the export target attribute of VPN-IPv4 routes advertised by other PEs. If the export target attribute matches the import target attribute of the VPN instance, the PE adds the routes to the VPN routing table.
In other words, VPN target attributes define which sites can receive VPN-IPv4 routes, and from which sites that a PE can receive routes.
Like RDs, VPN target attributes can be of two types of formats:
l 16-bit AS number:32-bit user-defined number. For example, 100:1.
l 32-bit IPv4 address:16-bit user-defined number. For example, 172.1.1.1:1.
MP-BGP
Multiprotocol extensions for BGP-4 (MP-BGP) advertises VPN composition information and routes between PEs. It is backward compatible and supports both traditional IPv4 address family and other address families, such as VPN-IPv4 address family.
Using MP-BGP can guarantee that private routes of a VPN are advertised only in the VPN and implement communications between MPLS VPN members.
Routing policy
In addition to the import and export extended communities for controlling VPN route advertisement, you can also configure import and export routing policies to control the injection and advertisement of VPN routes more precisely.
An import routing policy can further filter the routes that can be advertised to a VPN instance by using the VPN target attribute of import target attribute. It can reject the routes selected by the communities in the import target attribute. An export routing policy can reject the routes selected by the communities in the export target attribute.
After a VPN instance is created, you can configure import and/or export routing policies as needed.
Tunneling policy
A tunneling policy is used to select the tunnel for the packets of a specific VPN instance to use.
After a VPN instance is created, you can optionally configure a tunneling policy. By default, LSPs are used as tunnels and no load balancing occurs (in other words, the number of tunnels for load balancing is 1). In addition, a tunneling policy takes effect only within the local AS.
MPLS L3VPN Packet Forwarding
For basic MPLS L3VPN applications in a single AS, VPN packets are forwarded with two layers of labels:
l Layer 1 labels: Outer labels, used for label switching inside the backbone. They indicate LSPs from the local PEs to the remote PEs. Based on layer 1 labels, VPN packets can be label switched along the LSPs to the remote PEs.
l Layer 2 labels: Inner labels, used for forwarding packets from the remote PEs to the CEs. An inner label indicates to which site, or more precisely, to which CE the packet should be sent. A PE finds the interface for forwarding a packet according to the inner label.
If two sites (CEs) belong to the same VPN and are connected to the same PE, each of them only needs to know how to reach the remote CE.
The following takes Figure 1-3 as an example to illustrate the VPN packet forwarding procedure.
Figure 1-3 VPN packet forwarding
1) Site 1 sends an IP packet with the destination address of 1.1.1.2. CE 1 transmits the packet to PE 1.
2) PE 1 searches VPN instance entries based on the inbound interface and destination address of the packet. Once finding a matching entry, PE 1 labels the packet with both inner and outer labels and forwards the packet out.
3) The MPLS backbone transmits the packet to PE 2 by outer label. Note that the outer label is removed from the packet at the penultimate hop.
4) PE 2 searches VPN instance entries according to the inner label and destination address of the packet to determine the outbound interface and then forwards the packet out the interface to CE 2.
5) CE 2 transmits the packet to the destination by IP forwarding.
MPLS L3VPN Networking Schemes
In MPLS L3VPNs, VPN target attributes are used to control the advertisement and reception of VPN routes between sites. They work independently and can be configured with multiple values to support flexible VPN access control and implement multiple types of VPN networking schemes.
Basic VPN networking scheme
In the simplest case, all users in a VPN form a closed user group. They can forward traffic to each other but cannot communicate with any user outside the VPN.
For this networking scheme, the basic VPN networking scheme, you need to assign a VPN target to each VPN for identifying the export target attribute and import target attribute of the VPN. Moreover, this VPN target cannot be used by any other VPNs.
Figure 1-4 Network diagram for basic VPN networking scheme
In Figure 1-4, for example, the VPN target for VPN 1 is 100:1 on the PEs, while that for VPN 2 is 200:1. The two VPN 1 sites can communicate with each other, and the two VPN 2 sites can communicate with each other. However, the VPN 1 sites cannot communicate with the VPN 2 sites.
Hub and spoke networking scheme
For a VPN where a central access control device is required and all users must communicate with each other through the access control device, the hub and spoke networking scheme can be used to implement the monitoring and filtering of user communications.
This networking scheme requires two VPN targets: one for the "hub" and the other for the "spoke".
The VPN target setting rules for VPN instances of all sites on PEs are as follows:
l On spoke PEs (that is, the PEs connected with spoke sites), set the export target attribute to Spoke and the import target attribute to Hub.
l On the hub PE (that is, the PE connected to the hub site), specify two interfaces or sub-interfaces, one for receiving routes from spoke PEs, and the other for advertising routes to spoke PEs. Set the import target attribute of the VPN instance for the former to Spoke, and the export target attribute of the VPN instance for the latter to Hub.
Figure 1-5 Network diagram for hub and spoke networking scheme
In Figure 1-5, the spoke sites communicate with each other through the hub site. The arrows in the figure indicate the advertising path of routes from Site 2 to Site 1:
l The hub PE can receive all the VPN-IPv4 routes advertised by spoke PEs.
l All spoke PEs can receive the VPN-IPv4 routes advertised by the hub PE.
l The hub PE advertises the routes learnt from a spoke PE to the other spoke PEs. Thus, the spoke sites can communicate with each other through the hub site.
l The import target attribute of any spoke PE is distinct from the export VPN targets of the other spoke PEs. Therefore, any two spoke PEs can neither directly advertise VPN-IPv4 routes to each other nor directly access each other.
Extranet networking scheme
The extranet networking scheme can be used when some resources in a VPN are to be accessed by users that are not in the VPN.
In this kind of networking scheme, if a VPN needs to access a shared site, the export target attribute and the import target attribute of the VPN must be contained respectively in the import target attribute and the export target attribute of the VPN instance of the shared site.
Figure 1-6 Network diagram for extranet networking scheme
In Figure 1-6, VPN 1 and VPN 2 can access Site 3 of VPN 1.
l PE 3 can receive the VPN-IPv4 routes advertised by PE 1 and PE 2.
l PE 1 and PE 2 can receive the VPN-IPv4 routes advertised by PE 3.
l Based on the above, Site 1 and Site 3 of VPN 1 can communicate with each other, and Site 2 of VPN 2 and Site 3 of VPN 1 can communicate with each other.
l PE 3 advertises neither the VPN-IPv4 routes received from PE 1 to PE 2, nor the VPN-IPv4 routes received from PE 2 to PE 1 (that is, routes learned from an IBGP neighbor will not be advertised to any other IBGP neighbor). Therefore, Site 1 of VPN 1 and Site 2 of VPN 2 cannot communicate with each other.
MPLS L3VPN Routing Information Advertisement
In basic MPLS L3VPN networking, the advertisement of VPN routing information involves CEs and PEs. A P router maintains only the routes of the backbone and does not need to know any VPN routing information. A PE maintains only the routing information of the VPNs directly connected to it, rather than that of all VPNs. Therefore, MPLS L3VPN has excellent scalability.
The VPN routing information of a local CE is advertised in three phases:
1) Advertised from the local CE to the ingress PE.
2) Advertised from the ingress PE to the egress PE.
3) Advertised from the egress PE to the remote CE.
Then, a route is available between the local CE and the remote CE, and the VPN routing information can be advertised on the backbone.
The following describes these phases in detail.
Routing information exchange from the local CE to the ingress PE
After establishing an adjacency with the directly connected PE, a CE advertises its VPN routing information to the PE.
The route between the CE and the PE can be a static route, RIP route, OSPF route, IS-IS route, or BGP route. No matter which routing protocol is used, the CE always advertises standard IPv4 routes to the PE.
Routing information exchange from the ingress PE to the egress PE
After learning the VPN routing information from the CE, the ingress PE adds RDs and VPN targets for these standard IPv4 routes to form VPN-IPv4 routes, and maintains them for the VPN instance created for the CE.
Then, the ingress PE advertises the VPN-IPv4 routes to the egress PE through MP-BGP.
Finally, the egress PE compares the export target attribute of the VPN-IPv4 routes with the import target attribute that it maintains for the VPN instance and determines whether to add the routes to the routing table of the VPN instance.
PEs use IGP to ensure the connectivity between them.
Routing information exchange from the egress PE to the remote CE
A remote CE can learn VPN routes from the egress PE in a number of ways. The routes can be static routes, RIP routes, OSPF routes, IS-IS routes, or EBGP routes. The exchange of routing information between the egress PE and the remote CE is the same as that between the local CE and the ingress PE.
Multi-AS VPN
In some networking scenarios, multiple sites of a VPN may be connected to multiple ISPs in different ASs, or to multiple ASs of an ISP. Such an application is called multi-AS VPN.
RFC 2547bis presents three inter-provider VPN solutions:
l VRF-to-VRF: ASBRs manage VPN routes between them through subinterfaces. This solution is also called inter-provider VPN option A.
l EBGP advertisement of labeled VPN-IPv4 routes: ASBRs advertise labeled VPN-IPv4 routes to each other through MP-EBGP. This solution is also called inter-provider VPN option B.
l Multi-hop EBGP advertisement of labeled VPN-IPv4 routes: PEs advertise labeled VPN-IPv4 routes to each other through MP-EBGP. This solution is also called inter-provider VPN option C.
The following describes these three solutions.
Inter-provider VPN option A
In this kind of solution, PEs of two ASs are directly connected and each PE is also the ASBR of its AS.
The PEs acting as ASBRs are connected through multiple subinterfaces. Each of them treats the other as a CE of its own and advertises IPv4 routes through conventional EBGP. Within an AS, packets are forwarded using two-level label forwarding as VPN packets. Between ASBRs, conventional IP forwarding is used.
Ideally, each inter-provider VPN has a pair of subinterfaces to exchange VPN routing information.
Figure 1-7 Network diagram for inter-provider VPN option A
This kind of solution is easy to carry out because no special configuration is required on the PEs acting as the ASBRs.
However, it has limited scalability because the PEs acting as the ASBRs have to manage all the VPN routes and create VPN instances on a per-VPN basis. This leads to excessive VPN-IPv4 routes on the PEs. Moreover, the requirement to create a separate subinterface for each VPN also calls for higher performance of the PEs.
Inter-provider VPN option B
In this kind of solution, two ASBRs use MP-EBGP to exchange labeled VPN-IPv4 routes that they have obtained from the PEs in their respective ASs.
As shown in Figure 1-8, the routes are advertised through the following steps:
1) PEs in AS 100 advertise labeled VPN-IPv4 routes to the ASBR PE of AS 100 or the route reflector (RR) for the ASBR PE through MP-IBGP.
2) The ASBR PE advertises labeled VPN-IPv4 routes to the ASBR PE of AS 200 through MP-EBGP.
3) The ASBR PE of AS 200 advertises labeled VPN-IPv4 routes to PEs in AS 200 or to the RR for the PEs through MP-IBGP.
The ASBRs must perform the special processing on the labeled VPN-IPv4 routes, which is also called ASBR extension method.
Figure 1-8 Network diagram for inter-provider VPN option B
In terms of scalability, inter-provider VPN option B is better than option A.
When adopting MP-EBGP method, note that:
l ASBRs perform no VPN target filtering on VPN-IPv4 routes that they receive from each other. Therefore, the ISPs in different ASs that exchange VPN-IPv4 routes need to agree on the route exchange.
l VPN-IPv4 routes are exchanged only between VPN peers. A VPN user can exchange VPN-IPv4 routes neither with the public network nor with MP-EBGP peers with whom it has not reached agreement on the route exchange.
Inter-provider VPN option C
The above two kinds of solutions can satisfy the needs for inter-provider VPNs. However, they require that the ASBRs maintain and advertise VPN-IPv4 routes. When every AS needs to exchange a great amount of VPN routes, the ASBRs may become bottlenecks hindering network extension.
One way to solve the above problem is to make PEs directly exchange VPN-IPv4 routes without the participation of ASBRs:
l Two ASBRs advertise labeled IPv4 routes to PEs in their respective ASs through MP-IBGP.
l The ASBRs neither maintain VPN-IPv4 routes nor advertise VPN-IPv4 routes to each other.
l An ASBR maintains labeled IPv4 routes of the PEs in the AS and advertises them to the peers in the other ASs. The ASBR of another AS also advertises labeled IPv4 routes. Thus, an LSP is established between the ingress PE and egress PE.
l Between PEs of different ASs, Multi-hop EBGP connections are established to exchange VPN-IPv4 routes.
Figure 1-9 Network diagram for inter-provider VPN option C
To improve the scalability, you can specify an RR in each AS, making it maintain all VPN-IPv4 routes and exchange VPN-IPv4 routes with PEs in the AS. The RRs in two ASs establish an inter-provider VPNv4 connection to advertise VPN-IPv4 routes, as shown in Figure 1-10.
Figure 1-10 Network diagram for inter-provider VPN option C using RRs
Carrier’s Carrier
Introduction to carrier's carrier
It is possible that a customer of the MPLS L3VPN service provider is also a service provider. In this case, the MPLS L3VPN service provider is called the provider carrier or the Level 1 carrier, while the customer is called the customer carrier or the Level 2 carrier. This networking model is referred to as carrier’s carrier. In this model, the Level 2 service provider serves as a CE of the Level 1 service provider.
For good scalability, the Level 1 carrier does not inject the external routes of a Level 2 carrier; it only injects routes for switching packets from different sites of the Level 2 carrier. The external routes maintained by a Level 2 carrier are exchanged through BGP sessions established between related routes of the Level 2 carrier. This can greatly reduce the number of routes maintained by the Level 1 carrier network.
Implementation of carrier’s carrier
Compared with the common MPLS L3VPN, the carrier’s carrier is different because of the way in which a CE of a Level 1 carrier, that is, a Level 2 carrier, accesses a PE of the Level 1 carrier:
l If the PE and the CE are in a same AS, you need to configure IGP and LDP between them.
l If the PE and the CE are not in the same AS, you need to configure MP-EBGP to label the routes exchanged between them.
In either case, you need to enable MPLS on the CE of the Level 1 carrier. Moreover, the CE holds the VPN routes of the Level 2 carrier, but it does not advertise the routes to the PE of the Level 1 carrier; it only exchanges the routes with other PEs of the Level 2 carrier.
A Level 2 carrier can be an ordinary ISP or an MPLS L3VPN service provider.
When the Level 2 carrier is an ordinary ISP, its PEs run IGP to communicate with the CEs, rather than MPLS. As shown in Figure 1-11, PE 3 and PE 4 exchange VPN routes of the Level 2 carrier through IBGP sessions.
Figure 1-11 Scenario where the Level 2 carrier is an ISP
When the Level 2 carrier is an MPLS L3VPN service provider, its PEs need to run IGP and LDP to communicate with CEs. As shown in Figure 1-12, PE 3 and PE 4 exchange VPN routes of the Level 2 carrier through MP-IBGP sessions.
Figure 1-12 Scenario where the Level 2 carrier is an MPLS L3VPN service provider
If there are equal cost routes between the Level 1 carrier and the Level 2 carrier, you are recommended to establish equal cost LSPs between them accordingly.
Nested VPN
Background
In an MPLS L3VPN network, generally a service provider runs an MPLS L3VPN backbone and provides VPN services through PEs. VPN users are connected through CEs to PEs to access the MPLS L3VPN network. In this way, users in the same VPN at different sites can communicate with each other. In this scenario, user networks are ordinary IP networks and cannot be further divided into sub-VPNs.
However, in actual applications, VPN user networks can be dramatically different in form and complexity, and a VPN user network may need to use VPNs to further group its users. The traditional solution to this request is to implement internal VPN configuration on the service provider’s PEs. This solution is easy to deploy, but it increases the network operation cost and brings issues on management and security because:
l The number of VPNs that PEs must support will increase sharply.
l Any modification of an internal VPN must be done through the service provider.
The nested VPN technology offers a better solution. Its essence is to exchange VPNv4 routes between PEs and CEs of an ordinary MPLS L3VPN, and to allow VPN users to manage their own internal VPNs. Figure 1-13 depicts a nested VPN network. On the service provider’s MPLS VPN network, there is a user VPN named VPN A. The user VPN contains two sub-VPNs, VPN A-1 and VPN A-2. The service provider PEs treate the user network as a common VPN user and will not join any sub-VPNs. The VPN user’s CE devices (CE 1, CE 2, CE 7 and CE 8) exchange VPNv4 routes that carry the sub-VPN routing information with the service provider PEs, implementing the propagation of the sub-VPN routing information throughout the user network.
Figure 1-13 Network diagram for nested VPN
Propagation of routing information
In a nested VPN network, routing information is propagated in the following process:
1) A provider PE and its CEs exchange VPNv4 routes, which carry information about users’ internal VPNs.
2) After receiving a VPNv4 route, a provider PE keeps the user’s internal VPN information, and appends the user’s MPLS VPN attributes on the service provider network. That is, it replaces the RD of the VPNv4 route with the RD of the user’s MPLS VPN on the service provider network and adds the export route-target (ERT) attribute of the user’s MPLS VPN on the service provider network to the extended community attribute list of the route. The internal VPN information of the user is maintained on the provider PE.
3) The provider PE advertises VPNv4 routes which carry the comprehensive VPN information to the other PEs of the service provider.
4) After another provider PE receives the VPNv4 routes, it matches the VPNv4 routes based on its local VPNs. Each local VPN accepts routes of its own and advertises them to its connected sub-VPN CEs (such as CE 3 and CE 4, or CE 5 and CE 6 in Figure 1-13). If a CE is connected to a provider PE through an IPv4 netowrk, the PE advertises IPv4 routes to the CE; If a CE is connected to a provider PE through a VPNv4 connection (a user MPLS VPN network), the PE advertises VPNv4 routes to the CE.
Benefits
The nested VPN technology features the following main benefits:
l Support for VPN aggregation. It can aggregate a user’s internal VPNs into one VPN on the service provider’s MPLS VPN network.
l Support for both symmetric networking and asymmetric networking. It allows sites of the same VPN to have the same number or different numbers of internal VPNs.
l Support for multiple levels of nesting of user internal VPNs.
The nested VPN technology simplifies the complexity for a user to access a VPN, reduces the access cost, supports diversified VPN networking methods, and implements control over the access to internal VPNs and control over mutual access among multiple levels of VPNs.
OSPF VPN Extension
This section focuses on the OSPF VPN extension. For more information about OSPF, refer to the OSPF Configuration in the IP Routing Volume.
OSPF multi-instance on PE
OSPF is a prevalent IGP protocol. In many cases, VPN clients are connected through BGP peers, and the clients often run OSPF. Running OSPF between PEs and CEs can simplify the configuration and management of the CEs, because the CEs only need to support OSPF. In addition, if the customers require MPLS L3VPN services through conventional OSPF backbone, using OSPF between PEs and CEs can simplify the transition.
For OSPF to run between CEs and PEs, the PEs must support multiple OSPF instances. Each OSPF instance must correspond to a VPN instance and have its own interface and routing table.
The following describes details of OSPF configuration between PEs and CEs.
1) Configuration of OSPF areas between PEs and CEs
The OSPF area between a PE and a CE can be either a non-backbone area or a backbone area.
In the OSPF VPN extension application, the MPLS VPN backbone is considered the backbone area (area 0). Since OSPF requires that the backbone area must be contiguous, the area 0 of each VPN site must be connected with the MPLS VPN backbone.
That is, if a VPN site contains an OSPF area 0, the PE connected with the CE must be connected with the area 0 in this VPN site through an area 0 (the virtual link can be used for logical connection).
2) BGP/OSPF interaction
With OSPF running between PEs and CEs, PEs advertise VPN routes to each other through BGP and to CEs through OSPF.
With conventional OSPF, two sites are considered to be in different ASs even if they belong to the same VPN. Therefore, the routes that one site learns are advertised to the other as external routes. This results in higher OSPF traffic and network management problems that should have been avoided otherwise.
Currently, OSPF supports multiple instances and therefore can address the above problems. Properly configured, OSPF sites are considered directly connected, and PEs can exchange OSPF routing information as they are using dedicated lines. This improves the network management and makes OSPF applications more effective.
As shown in Figure 1-14, PE 1 and PE 2 are connected through the MPLS backbone, while CE 11, CE 21, and CE 22 belong to VPN 1. Assumes that all the routers in the figure belong to the same AS, that is, CE 11, CE 21, and CE 22 belong to the same OSPF domain. The advertisement procedure of VPN 1 routes is as follows:
l At first, PE 1 redistributes OSPF routes from CE 11 into BGP.
l Then, PE 1 advertises the VPN routes to PE 2 through BGP.
l Finally, PE 2 redistributes the BGP VPN routes into OSPF and advertises them to CE 21 and CE 22.
Figure 1-14 Application of OSPF in VPN
With the standard BGP/OSPF interaction, PE 2 advertises the BGP VPN routes to CE 21 and CE 22 through Type 5 LSAs (ASE LSAs). However, CE 11, CE 21, and CE 22 belong to the same OSPF domain, and the route advertisement between them should use Type 3 LSAs (inter-provider routes).
To solve the above problems, PE uses an extended BGP/OSPF interaction process called BGP/OSPF interoperability to advertise routes from one site to another, differentiating the routes from real AS-External routes. The process requires that extended BGP community attributes carry the information for identifying the OSPF attributes.
It is required that each OSPF domain has a configurable domain ID. It is recommended to configure for all OSPF instances in the network related to each VPN instance the same domain ID, or adopt the default ID. Thus, the system can know that all VPN routes with the same domain ID are from the same VPN instance.
3) Routing loop detection
If OSPF runs between CEs and PEs and a VPN site is connected to multiple PEs, when a PE advertises the BGP VPN routes learnt from MPLS/BGP to the VPN site through LSAs, the LSAs may be received by another PE, resulting in a routing loop.
To avoid routing loops, when creating Type 3 LSAs, the PE always sets the flag bit DN for BGP VPN routes learnt from MPLS/BGP, regardless of whether the PE and the CEs are connected through the OSPF backbone. When performing route calculation, the OSPF process of the PE ignores the Type 3 LSAs whose DN bit is set.
If the PE needs to advertise to a CE the routes from other OSPF domains, it must indicate that it is the ASBR, and advertise the routes using Type 5 LSAs.
Sham link
Generally, BGP peers carry routing information on the MPLS VPN backbone through the BGP extended community attributes. The OSPF that runs on the remote PE can use the information to create Type 3 summary LSAs to be transmitted to the CEs. As shown in Figure 1-15, both site 1 and site 2 belong to VPN 1 and OSPF area1. They are connected to different PEs, PE 1 and PE 2. There is an intra-area OSPF link called backdoor link between them. In this case, the route connecting the two sites through PEs is an inter-area route. It is not preferred by OSPF because its preference is lower than that of the intra-area route across the backdoor link.
Figure 1-15 Network diagram for sham link
To solve the problem, you can establish a sham link between the two PEs so that the routes between them over the MPLS VPN backbone become an intra-area route.
The sham link acts as an intra-area point-to-point link and is advertised through the Type 1 LSA. You can select a route between the sham link and backdoor link by adjusting the metric.
The sham link is considered the link between the two VPN instances with one endpoint address in each VPN instance. The endpoint address is a loopback interface address with a 32-bit mask in the VPN address space on the PE. Different sham links of the same OSPF process can share an endpoint address, but that of different OSPF processes cannot.
BGP advertises the endpoint addresses of sham links as VPN-IPv4 addresses. A route across the sham link cannot be redistributed into BGP as a VPN-IPv4 route.
A sham link can be configured in any area. You need to configure it manually. In addition, the local VPN instance must have a route to the destination of the sham link.
BGP AS Number Substitution
Since BGP detects routing loops by AS number, if EBGP runs between PEs and CEs, you must assign different AS numbers to geographically different sites to ensure correct transmission of the routing information.
The BGP AS number substitution function allows physically dispersed CEs to use the same AS number. The function is a BGP outbound policy and functions on routes to be advertised.
With the BGP AS number substitution function, when a PE advertises a route to a CE of the specified peer, if an AS number identical to that of the CE exist in the AS_PATH of the route, it will be replaced with that of the PE.
After you enable the BGP AS number substitution function, the PE re-advertises all routing information to the connected CEs in the peer group, performing BGP AS number substitution based on the above principle.
Figure 1-16 Application of BGP AS number substitution
In Figure 1-16, both CE 1 and CE 2 use the AS number of 800. AS number substitution is enabled on PE 2 for CE 2. Before advertising updates received from CE 1 to CE 2, PE 2 finds that an AS number in the AS_PATH is the same as that of CE 2 and hence substitutes its own AS number 100 for the AS number. In this way, CE 2 can normally receive the routing information from CE 1.
AS number substitution also applies to a PE connecting multiple CEs through different interfaces, such as PE 2 in Figure 1-16, which connects CE 2 and CE 3.
For a multi-homed CE, that is, a CE connected with multiple PEs, the BGP AS number substitution function must be used in combination with the site-of-origin (SOO) function. Otherwise, routing loops may appear.
MPLS L3VPN Configuration Task List
Complete the following tasks to configure MPLS L3VPN:
Task |
Remarks |
Required |
|
Required |
|
Optional Configure it as needed |
|
Optional Configure it as needed |
|
Optional Configure it as needed |
|
Optional Configure it as needed |
Configuring VPN Instances
VPN instances are used to isolate VPN routes from public network routes. Configuring VPN instances is required in all MPLS L3VPN networking schemes.
In addition, routes of a VPN instance are isolated from those of another. This feature allows VPN instances to be used in networking schemes other than MPLS L3VPNs.
All VPN instance configurations are on PEs.
Creating a VPN Instance
A VPN instance is associated with a site, rather than a VPN. It is a collection of the VPN membership and routing rules of its associated site.
A VPN instance takes effect only after you configure an RD for it. Before configuring an RD for a VPN instance, you can configure no parameters for the instance other than a description.
A VPN instance description is a piece of descriptive information about the VPN instance. You can use it to keep information such as the relationship of the VPN instance with a VPN.
Follow these steps to create and configure a VPN instance:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Create a VPN instance and enter VPN instance view |
ip vpn-instance vpn-instance-name |
Required |
Configure an RD for the VPN instance |
route-distinguisher route-distinguisher |
Required |
Configure a description for the VPN instance |
description text |
Optional |
Associating a VPN Instance with an Interface
After creating and configuring a VPN instance, you associate the VPN instance with the interface for connecting CEs. Any interface supporting MPLS LDP capability can be associated with a VPN instance. For interfaces supporting MPLS LDP capability, refer to MPLS Basics Configuration in the MPLS Volume.
Follow these steps to associate a VPN instance with an interface:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter interface view |
interface interface-type interface-number |
— |
Associate the current interface with the VPN instance |
ip binding vpn-instance vpn-instance-name |
Required No VPN instance is associated with an interface by default. |
When configured on an interface, the ip binding vpn-instance command clears the IP address of the interface. Therefore, you must re-configure the IP address of the interface after configuring the command.
Configuring Route Related Attributes of a VPN Instance
The control process of VPN route advertisement is as follows:
l When a VPN route learned from a CE gets redistributed into BGP, BGP associates it with a VPN target extended community attribute list, which is usually the export target attribute of the VPN instance associated with the CE.
l The VPN instance determines which routes it can accept and redistribute according to the import-extcommunity in the VPN target.
l The VPN instance determines how to change the VPN targets attributes for routes to be redistributed according to the export-extcommunity in the VPN target.
Follow these steps to configure route related attributes of a VPN instance
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter VPN instance view |
ip vpn-instance vpn-instance-name |
Required |
Associate the current VPN instance with one or more VPN targets |
vpn-target vpn-target&<1-8> [ both | export-extcommunity | import-extcommunity ] |
Required |
Configure the maximum number of routes for the VPN instance |
routing-table limit number { warn-threshold | simply-alert } |
Optional |
Apply an import routing policy to the current VPN instance |
import route-policy route-policy |
Optional By default, all routes permitted by the import target attribute can be redistributed into the VPN instance. |
Apply an export routing policy to the current VPN instance |
export route-policy route-policy |
Optional By default, all VPN instance routes permitted by the export target attribute can be redistributed. |
l A single vpn-target command can configure up to eight VPN targets. You can configure up to 20 VPN targets for a VPN instance.
l You can define the maximum number of routes for a VPN instance to support, preventing too many routes from being redistributed into the PE.
l Before associating a routing policy with a VPN instance, you must create the routing policy at first. Otherwise, the default routing policy is used.
Configuring a Tunneling Policy of a VPN Instance
Configuring a tunneling policy
Follow these steps to configure a tunneling policy:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Create a tunneling policy and enter tunneling policy view |
tunnel-policy tunnel-policy-name |
Required |
Specify the priorities of tunnels and the number of tunnels for load balancing |
tunnel select-seq { cr-lsp | lsp } * load-balance-number number |
Required By default, the LSP tunnel is used and the number of tunnels for load balancing is 1. |
CR-LSP tunneling is not supported by S7500E Series Ethernet Switches..
Associating a tunneling policy with the VPN instance
Follow these steps to associate a tunneling policy with the VPN instance:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter VPN instance view |
ip vpn-instance vpn-instance-name |
Required |
Associate a tunneling policy with the VPN instance |
tnl-policy tunnel-policy-name |
Required By default, the LSP tunnel is used and the number of tunnels for load balancing is 1. |
Create the tunneling policy before associating it with the VPN instance. Otherwise, the default policy will be used.
Configuring Basic MPLS L3VPN
This section describes how to configure a simple MPLS L3VPN, where only one carrier is involved, the MPLS backbone is not inter-provider, and none of the PEs or CEs functions as a PE and a CE at the same time.
Some special MPLS L3VPN networking scenarios such as inter-provider VPN require additional configurations. For more information, refer to the related sections in this chapter.
In configuring MPLS L3VPN, the key task is to manage the advertisement of VPN routes on the MPLS backbone and includes the management of route advertisement between PEs and CEs and that between PEs.
As for the route exchange between a PE and a CE, you can configure static routes, multiple RIP instances, multiple OSPF instances, multiple IS-IS instances, or BGP according to the networking situations. MP-IBGP is adopted between PEs.
Configuration Prerequisites
Before configuring basic MPLS L3VPN, complete these tasks:
l Configure IGP for the MPLS backbone (PEs and Ps) to achieve IP connectivity
l Configure MPLS basic capability for the MPLS backbone (PEs and Ps)
l Configure MPLS LDP for the MPLS backbone (PEs and Ps) so that LDP LSPs can be established
l On CEs, configure the IP addresses of the interfaces for accessing the PEs
Configuring a VPN Instance
Follow these steps to configure a VPN instance:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Create a VPN instance and enter VPN instance view |
ip vpn-instance vpn-instance-name |
Required No VPN instance exists by default. |
Configure an RD for the VPN instance |
route-distinguisher route-distinguisher |
Required |
Associate the current VPN instance with one or more VPN targets |
vpn-target vpn-target&<1-8> [ both | export-extcommunity | import-extcommunity ] |
Required |
Return to system view |
quit |
— |
Enter interface view |
interface interface-type interface-number |
— |
Associate the current interface with the VPN instance |
ip binding vpn-instance vpn-instance-name |
Required By default, an interface is associated with no VPN instance. |
Configuring Route Advertisement between PE and CE
Route advertisement between PE and CE can depend on static routes, RIP, OSPF, IS-IS, or EBGP. You may choose one as needed.
Configuring static routes between PEs and CEs
Follow these steps to configure static routes between PEs and CEs:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Configure static routes for a specified VPN instance |
ip route-static dest-address { mask | mask-length } { gateway-address | interface-type interface-number [ gateway-address ] | vpn-instance d-vpn-instance-name gateway-address } [ preference preference-value ] [ tag tag-value ] [ description description-text ] |
Required |
ip route-static vpn-instance s-vpn-instance-name&<1-5> dest-address { mask | mask-length } { gateway-address [ public ] | interface-type interface-number [ gateway-address ] | vpn-instance d-vpn-instance-name gateway-address } [ preference preference-value ] [ tag tag-value ] [ description description-text ] |
l Perform this configuration on the PEs. The configuration method on the CEs is the same for configuring ordinary static routes.
l For information about static route, refer to Static Routing Configuration in the IP Routing Volume.
Configuring RIP between PE and CE
A RIP process belongs to only one VPN instance. If you run a RIP process without binding it to a VPN instance, the process is considered a public network process.
Follow these steps to configure RIP between PE and CE:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Create a RIP instance between PE and CE and enter RIP view |
rip [ process-id ] vpn-instance vpn-instance-name |
Required |
l Perform this configuration on the PEs. Only conventional RIP is required on CEs.
l After configuring a RIP instance, you must start RIP by using the same method for starting a common RIP process.
l For description and detailed configuration about RIP, refer to RIP Configuration in the IP Routing Volume.
Configuring OSPF between PE and CE
An OSPF process that is bound to a VPN instance does not use the public network router ID configured in system view. Therefore, you need to specify the router ID when starting a process or to configure the IP address for at least one interface of the VPN instance.
An OSPF process belongs to only one VPN instance. If you run an OSPF process without binding it to a VPN instance, the process is considered a public network process.
Follow these steps to configure OSPF between PE and CE:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Create an OSPF instance between PE and CE and enter the OSPF view |
ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] |
Required |
Configure the OSPF domain ID |
domain-id domain-id [ secondary ] |
Optional 0 by default |
Configure the type codes of OSPF extended community attributes |
ext-community-type { domain-id type-code1 | router-id type-code2 | route-type type-code3 } |
Optional The defaults are as follows: 0x0005 for Domain ID, 0x0107 for Router ID, and 0x0306 for Route Type. Configure this command on a PE. |
After a VPN instance is deleted, all related OSPF processes are deleted at the same time.
An OSPF process can be configured with only one domain ID. Domain IDs of different OSPF processes are independent of each other.
All OSPF processes of a VPN must be configured with the same domain ID for routes to be correctly advertised, while OSPF processes on PEs in different VPNs can be configured with domain IDs as desired.
The domain ID of an OSPF process is included in the routes generated by the process. When an OSPF route is injected into BGP, the OSPF domain ID is included in the BGP VPN route and delivered as a BGP extended community attribute.
l After configuring an OSPF instance, you must start OSPF by using the same method for starting a common OSPF process.
l For description and detailed configuration about OSPF, refer to OSPF Configuration in the IP Routing Volume.
Configuring IS-IS between PE and CE
An IS-IS process belongs to only one VPN instance. If you run a IS-IS process without binding it to a VPN instance, the process is considered a public network process.
Follow these steps to configure IS-IS between PE and CE:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Create an IS-IS instance between PE and CE and enter IS-IS view |
isis [ process-id ] vpn-instance vpn-instance-name |
Required |
l After configuring an IS-IS instance, you must start IS-IS by using the same method for starting a common IS-IS process.
l For description and detailed configuration about IS-IS, refer to IS-IS Configuration in the IP Routing Volume.
Configuring EBGP Between PE and CE
1) On a PE
Follow these steps to configure EBGP between PE and CE on a PE:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
— |
Enter BGP VPN instance view |
ipv4-family vpn-instance vpn-instance-name |
Required |
Configure the CE as the VPN peer |
peer { group-name | ip-address } as-number as-number |
Required |
Inject the routes of the local CEs |
import-route protocol [ process-id ] [ med med-value | route-policy route-policy-name ] * |
Required A PE needs to inject the routes of the local CEs into its VPN routing table so that it can advertise them to the peer PE. |
Configure BGP to filter routes to be advertised |
filter-policy { acl-number | ip-prefix ip-prefix-name } export [ direct | isis process-id | ospf process-id | rip process-id | static ] |
Optional By default, BGP does not filter routes to be advertised. |
Configure BGP to filter received routes |
filter-policy { acl-number | ip-prefix ip-prefix-name } import |
Optional By default, BGP does not filter received routes. |
Allow the local AS number to appear in the AS_PATH attribute of a received route and set the maximum number of repetitions |
peer { group-name | ip-address } allow-as-loop [ number ] |
Optional For the hub and spoke networking scheme |
Normally, BGP detects routing loops by AS number. In the hub and spoke networking scheme, however, with EBGP running between PE and CE, the routing information the PE advertises to a CE carries the number of the AS where the PE resides. Therefore, the route updates that the PE receives from the CE also include the number of the AS where the PE resides. This causes the PE unable to receive the route updates. In this case, routing loops must be allowed.
2) On a CE
Follow these steps to configure EBGP between PE and CE on a CE:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
— |
Configure the PE as the peer |
peer { group-name | ip-address } as-number as-number |
Required |
Configure the route advertisement behavior |
import-route protocol [ process-id ] [ med med-value | route-policy route-policy-name ] * |
Optional A CE needs to advertise its routes to the connected PE so that the PE can advertise them to the peer CE. |
l Exchange of BGP routes for a VPN instance is the same as that of ordinary BGP routes.
l The configuration task in BGP instance view is the same as that in BGP view. For detailed information, refer to BGP Configuration and BGP Commands in the IP Routing Volume.
l For information about BGP peer and peer group configuration, refer to BGP Configuration and BGP Commands in the IP Routing Volume. This chapter does not differentiate between peer and peer group.
Configuring Route Advertisement Between PEs
Follow these steps to configure route advertisement between PEs:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
Required |
Configure the remote PE as the peer |
peer { group-name | ip-address } as-number as-number |
Required |
Specify the source interface for route updates |
peer { group-name | ip-address } connect-interface interface-type interface-number |
Required By default, BGP uses the source interface of the optimal route update packet. |
Enter BGP-VPNv4 subaddress family view |
ipv4-family vpnv4 [ unicast ] |
Required |
Enable the exchange of BGP-VPNv4 routing information with the specified peer |
peer { group-name | ip-address } enable |
Required By default, BGP peers exchange IPv4 routing information only. |
Configuring Routing Features for BGP VPNv4 Subaddress Family
With BGP VPNv4 subaddress family, there are a variety of routing features that are the same as those for BGP IPv4 unicast routing. You can select any of the features as required.
Configuring common routing features for all types of subaddress families
For VPN applications, BGP address families include BGP VPN-IPv4 address family, BGP-L2VPN address family, and VPLS address family. Every command in the following table has the same function on BGP routes for each type of the address families.
Follow these steps to configure common routing features for all types of subaddress families:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
Required |
Configure the remote PE as the peer |
peer ip-address as-number as-number |
Required |
Specify the interface for TCP connection |
peer ip-address connect-interface interface-type interface-number |
Required |
Enter address family view |
ipv4-family vpnv4 |
Required Use one of the commands as needed. |
l2vpn-family |
||
Allow the local AS number to appear in the AS_PATH attribute of a received route and set the maximum number of repetitions |
peer { group-name | ip-address } allow-as-loop [ number ] |
Optional |
Enable a peer or peer group for an address family and enable the exchange of BGP routing information of the address family |
peer { group-name | ip-address } enable |
Required By default, only IPv4 routing information is exchanged between BGP peers. |
Add a peer into an existing peer group |
peer ip-address group group-name |
Optional |
Configure the system to use the local address as the next hop of a route to be advertised to a specified peer or peer group |
peer { group-name | ip-address } next-hop-local |
Optional By default, the system uses the local address as the next hop of a route to be advertised to an EBGP peer. Note that in the inter-provider VPN option C solution, you need to configure the peer { group-name | ip-address } next-hop-invariable command on the RR for multi-hop EBGP neighbors and reflector clients to ensure that the next hop of a VPN route will not be changed. |
Configure the system to be the RR and set a peer or peer group as the client of the RR |
peer { group-name | ip-address } reflect-client |
Optional By default, no RR or RR client is configured. |
Enable VPN target filtering for received VPNv4 routes |
policy vpn-target |
Optional Enabled by default |
Enable route reflection between clients |
reflect between-clients |
Optional Enabled by default |
Specify the cluster ID of the RR |
reflector cluster-id { cluster-id | ip-address } |
Optional Router ID of an RR in the cluster by default |
Create an RR reflection policy |
rr-filter extended-community-list-number |
Optional |
For information about BGP-L2VPN address family, refer to MPLS L2VPN Commands in the MPLS Volume.
Configuring specific routing features for BGP-VPNv4 subaddress family
Follow these steps to configure specific routing features for BGP-VPNv4 subaddress family:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
— |
Configure the remote PE as the peer |
peer ip-address as-number as-number |
Required |
Specify the interface for TCP connection |
peer ip-address connect-interface interface-type interface-number |
Required |
Enter BGP-VPNv4 subaddress family view |
ipv4-family vpnv4 |
— |
Set the default value of the local preference |
default local-preference value |
Optional 100 by default |
Set the default system metric |
default med med-value |
Optional 0 by default |
Configure BGP to filter all or certain types of routes to be advertised |
filter-policy { acl-number | ip-prefix ip-prefix-name } export [ direct | isis process-id | ospf process-id | rip process-id | static ] |
Optional By default, BGP does not filter routes to be advertised. |
Configure BGP to filter received routes |
filter-policy { acl-number | ip-prefix ip-prefix-name } import |
Optional By default, BGP does not filter received routes. |
Configure the system to advertise community attributes to a peer or peer group |
peer { group-name | ip-address } advertise-community |
Optional By default, no community attributes are advertised to any peer or peer group. |
Specify to filter routes received from or to be advertised to a peer or peer group based on an AS_PATH list |
peer { group-name | ip-address } as-path-acl aspath-filter-number { import | export } |
Optional By default, no AS filtering list is applied to a peer or peer group. |
Specify to advertise all default routes of a VPN instance to a peer or peer group |
peer { group-name | ip-address } default-route-advertise vpn-instance vpn-instance-name |
Optional By default, no default route is advertised to a peer or peer group. |
Apply a filtering policy to a peer or peer group |
peer { group-name | ip-address } filter-policy acl-number { export | import } |
Optional By default, no filtering policy is applied to a peer or peer group. |
Apply a route filtering policy based on IP prefix list to a peer or peer group |
peer { group-name | ip-address } ip-prefix prefix-name { export | import } |
Optional By default, no route filtering policy based on IP prefix list is applied to a peer or peer group. |
Specify not to change the next hop of a route when advertising it to an EBGP peer |
peer { group-name | ip-address } next-hop-invariable |
Optional By default, a device uses its address as the next hop when advertising a route to its EBGP peer. |
Specify the preferred value for the routes received from the peer/peer group |
peer { group-name | ip-address } preferred-value value |
Optional 0 by default |
Make BGP updates to be sent carry no private AS numbers |
peer { group-name | ip-address } public-as-only |
Optional By default, a BGP update carries private AS numbers. |
Apply a routing policy to a peer or peer group |
peer { group-name | ip-address } route-policy route-policy-name { export | import } |
Optional By default, no routing policy is applied to a peer or peer group. |
For information about BGP routing, refer to BGP Configuration in the IP Routing Volume.
Configuring Inter-Provider VPN
If the MPLS backbone on which the VPN routes rely spans multiple ASs, you need to configure inter-provider VPN.
There are three inter-provider VPN solutions. You can choose them as required.
Configuration Prerequisites
Before configuring inter-provider VPN, complete these tasks:
l Configuring IGP for the MPLS backbones in each AS to implement IP connectivity of the backbones in the AS
l Configuring basic MPLS capabilities for the MPLS backbones of each AS
l Configuring MPLS LDP for the MPLS backbones so that LDP LSPs can be established
l Configuring basic MPLS L3VPN for each AS
When configuring basic MPLS L3VPN for each AS, specific configurations may be required on PEs or ASBR-PEs. This depends on the inter-provider VPN solution selected.
Configuring Inter-Provider VPN Option A
Inter-provider VPN option A applies to scenarios where the number of VPNs and that of VPN routes on the PEs are relatively small. It is simple to implement.
To configure inter-provider VPN option A, you only need to:
l Configure basic MPLS L3VPN on each AS.
l Configure each ASBR, taking the peer ASBR PE as its CE.
In other words, configure VPN instances for PEs and ASBR PEs respectively. The VPN instance for PE is used to allow CEs to access the network, while that for ASBR-PE is used to access its peer ASBR-PE.
Refer to Configuring Basic MPLS L3VPN.
In the inter-provider VPN option A solution, for the same VPN, the VPN targets for the VPN instances of the PEs must match those for the VPN instances of the ASBR-PEs in the same AS. It is not required for PEs in different ASs.
Configuring Inter-Provider VPN Option B
Follow these steps to configure inter-provider VPN option B on ASBR PEs:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter interface view for the interface connecting to the remote ASBR-PE |
interface interface-type interface-number |
— |
Configure the IP address of the interface |
ip address ip-address { mask | mask-length } |
Required |
Return to system view |
quit |
— |
Enter BGP view |
bgp as-number |
— |
Enter BGP-VPNv4 subaddress family view |
ipv4-family vpnv4 [ unicast ] |
— |
Disable VPN target filtering for VPNv4 routes |
undo policy vpn-target |
Required By default, PE performs VPN target filtering of the received VPNv4 routes. The routes surviving the filtering will be added to the routing table, and the others are discarded. |
In the inter-provider VPN option B solution, the ASBR PEs need to maintain all VPNv4 routing information and advertise the information to peer ASBR PEs. In this case, the ASBR PEs must receive all VPNv4 routing information without performing VPN target filtering.
In the inter-provider VPN option B solution, for the same VPN, the VPN targets for the VPN instances of the PEs must match those for the VPN instances of the ASBR-PEs in the same AS. This is true for PEs in different ASs.
For inter-provider VPN option B, two configuration methods are available:
l Do not change the next hop on an ASBR. With this method, you still need to configure MPLS LDP between ASBRs.
l Change the next hop on an ASBR. With this method, MPLS LDP is not required between ASBRs.
Currently, only the second method is supported. Therefore, MP-EBGP routes will get their next hops changed by default before being redistributed to MP-IBGP. On conventional BGP, however, EBGP routes to be advertised to IBGP do not have their next hops changed by default. If the next hops need to be changed to the local addresses, you can configure the peer { ip-address | group-name } next-hop-local command. For information about the command, refer to BGP Configuration in the IP Routing Volume.
Configuring Inter-Provider VPN Option C
Configuring the PEs
You need to establish ordinary IBGP peer relationship between PEs and ASBR PEs in an AS and MP-EBGP peer relationship between PEs of different ASs.
The PEs and ASBR PEs in an AS must be able to exchange labeled IPv4 routes.
Follow these steps to configure a PE for inter-provider VPN option C:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
— |
Configure the ASBR PE in the same AS as the IBGP peer |
peer { group-name | ip-address } as-number as-number |
Required |
Enable the PE to exchange labeled IPv4 routes with the ASBR PE in the same AS |
peer { group-name | ip-address } label-route-capability |
Required By default, the device does not advertise labeled routes to the IPv4 peer/peer group. |
Configure the PE of another AS as the EBGP peer |
peer { group-name | ip-address } as-number as-number |
Required |
Enter BGP-VPNv4 subaddress family view |
ipv4-family vpnv4 [ unicast ] |
— |
Enable the PE to exchange BGP VPNv4 routing information with the peer |
peer { group-name | ip-address } enable |
Required |
Configure the PE not to change the next hop of a route when advertising it to the EBGP peer |
peer { group-name | ip-address } next-hop-invariable |
Optional Required only when RRs are used to advertise VPNv4 routes, where the next hop of a route advertised between RRs cannot be changed. |
Configuring the ASBR PEs
In the inter-provider VPN option C solution, an inter-provider VPN LSP is required, and the routes advertised between the relevant PEs and ASBRs must carry MPLS label information.
An ASBR-PE establishes common IBGP peer relationship with PEs in the same AS, and common EBGP peer relationship with the peer ASBR PE. All of them exchange labeled IPv4 routes.
The public routes carrying MPLS labels are advertised through MP-BGP. According to RFC 3107 “Carrying Label Information in BGP-4”, the label mapping information for a particular route is piggybacked in the same BGP update message that is used to distribute the route itself. This capability is implemented through BGP extended attributes and requires that the BGP peers can handle labeled IPv4 routes.
Follow these steps to configure an ASBR PE for inter-provider VPN option C:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
— |
Configure each PE in the same AS as the IBGP peer |
peer { group-name | ip-address } as-number as-number |
Required |
Enable the ASBR PE to exchange labeled IPv4 routes with the PEs in the same AS |
peer { group-name | ip-address } label-route-capability |
Required By default, the device does not advertise labeled routes to the IPv4 peer/peer group. |
Configure the ASBR PE to change the next hop to itself when advertising routes to PEs in the same AS |
peer { group-name | ip-address } next-hop-local |
Required By default, a BGP speaker does not use its address as the next hop when advertising a route to its IBGP peer/peer group. |
Configure the remote ASBR PE as the EBGP peer |
peer { group-name | ip-address } as-number as-number |
Required |
Enable the ASBR PE to exchange labeled IPv4 routes with the peer ASBR PE |
peer { group-name | ip-address } label-route-capability |
Required By default, the device does not advertise labeled routes to the IPv4 peer. |
Apply a routing policy to the routes advertised by peer ASBR PE |
peer { group-name | ip-address } route-policy route-policy-name export |
Required By default, no routing policy is applied to a peer or peer group. |
Configuring the routing policy
After you configure and apply a routing policy on an ASBR PE, it:
l Assigns MPLS labels to the routes received from the PEs in the same AS before advertising them to the peer ASBR PE.
l Assigns new MPLS labels to the labeled IPv4 routes to be advertised to the PEs in the same AS.
Which IPv4 routes are to be assigned with MPLS labels depends on the routing policy. Only routes that satisfy the criteria are assigned with labels. All the other routes are still common IPv4 routes.
Follow these steps to configure a routing policy for inter-provider VPN option C on an ASBR PE:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter routing policy view |
route-policy policy-name permit node seq-number |
Required |
Configure the device to match IPv4 routes with labels |
if-match mpls-label |
Required |
Configure the device to assign labels to IPv4 routes |
apply mpls-label |
Required By default, an IPv4 route does not carry any label. |
For information about routing policy configuration, refer to Routing Policy Configuration in the IP Routing Volume.
Configuring Nested VPN
For a network with many VPNs, if you want to classify different levels of management privilidges by VPNs and to conceal the deployment of internal VPNs, nested VPN is a good solution. By using nested VPN, you can implement layered management of internal VPNs easily with a low cost and simple management operation.
Configuration Prerequisites
Before configuring nested VPN, configure the basic MPLS L3VPN capability. Refer to Configuring Basic MPLS L3VPN.
Configuring Nested VPN
Follow these steps to configure nested VPN:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
— |
Enter BGP VPN instance view |
ipv4-family vpn-instance vpn-instance-name |
— |
Configure a CE peer or peer group |
peer { group-name | peer-address } as-number number |
Required |
Return to BGP view |
quit |
— |
Enter BGP-VPNv4 subaddress family view |
ipv4-family vpnv4 |
— |
Enable nested VPN |
nesting-vpn |
Required Disabled by default. |
Activate a nested VPN peer or peer group, and enable the BGP-VPNv4 route exchange capability |
peer { group-name | peer-address } vpn-instance vpn-instance-name enable |
Required By default, only IPv4 routes and no BGP-VPNv4 routes can be exchanged between nested VPN peers/peer groups. |
Add a peer to the nested VPN peer group |
peer peer-address vpn-instance vpn-instance-name group group-name |
Optional By default, a peer is not in any nested VPN peer group. |
Specify to apply a routing policy to routes received from a nested VPN peer or peer group |
peer { group-name | peer-address } vpn-instance vpn-instance-name route-policy route-policy-name import |
Optional By default, no routing policy is applied to routes received from a nested VPN peer or peer group. |
l The address ranges for sub-VPNs of a user VPN cannot overlap.
l It is not recommended to give nested VPN peers addresses that public network peers use.
l Before specifying a nested VPN peer or peer group, be sure to configure the corresponding CE peer or peer group in BGP VPN instance view.
l At present, nested VPN does not support multi-hop EBGP networking. Therefore, a service provider PE and its peer must use the addresses of the directly connected interfaces to establish neighbor relationship.
Configuring OSPF Sham Link
The sham link is considered an OSPF intra-area route. It is used to ensure that the VPN traffic is transmitted over the backbone instead of the backdoor link between two CEs.
The source and destination addresses of the sham link must be loopback interface addresses with 32-bit masks. Besides, the loopback interfaces must be bound to the VPN instances and be advertised through BGP.
Configuration Prerequisites
Before configuring OSPF sham link, be sure to complete these tasks:
l Configuring basic MPLS L3VPN (OSPF is used between PE and CE)
l Configuring OSPF in the LAN where CEs reside
Configuring a Loopback Interface
Follow these steps to configure a loopback interface:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Create a loopback interface and enter loopback interface view |
interface loopback interface-number |
Required |
Bind the loopback interface to VPN instance |
ip binding vpn-instance vpn-instance-name |
Required By default, an interface is associated with no VPN instance. |
Configure the address of the loopback interface |
ip address ip-address { mask | mask-length } |
Required |
Advertising Routes of a Loopback Interface
Follow these steps to advertise routes of a loopback interface:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
Required |
Enter BGP VPN instance view |
ipv4-family vpn-instance vpn-instance-name |
Required |
Inject direct routes, that is, loopback host routes |
import-route direct |
Required |
Creating a Sham Link
Follow these steps to create a sham link:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter OSPF view |
ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] * |
— |
Configure the route tag |
route-tag tag-value |
Required |
Enter OSPF area view |
area area-id |
Required |
Configure a sham link |
sham-link source-ip-address destination-ip-address [ cost cost | dead dead-interval | hello hello-interval | retransmit retrans-interval | trans-delay delay | simple [ cipher | plain ] password | { md5 | hmac-md5 } key-id [ cipher | plain ] password ]* |
Required By default, no sham link is configured. |
l If you start OSPF but do not configure the router ID, the system will automatically elect one. However, the same election rules produce the same router ID. Therefore, you are recommended to configure the router ID when starting an OSPF process. For the election rules, refer to OSPF Configuration in the IP Routing Volume.
l If you configure multiple OSPF VPN instances but do not configure the route tag, the system will automatically create one based on the AS number configured. If you do not configure BGP, the tag will be 0. However, the same calculation rule produces the same tag, and hence the same tag will be created for multiple OSPF VPN instances on the same PE or PEs with the same AS number. Therefore, you are recommended to configure different tags for different OSPF VPN instance.
Configuring BGP AS Number Substitution
Configuration Prerequisites
Before configuring BGP AS number substitution, complete these tasks:
l Configuring basic MPLS L3VPN
l Configuring CEs at different sites to have the same AS number
Configuration Procedure
When CEs at different sites have the same AS number, you need to configure the BGP AS number substitution function to avoid route loss.
With the BGP AS number substitution function, when a PE advertises a route to a CE of the specified peer, if an AS number identical to that of the CE exist in the AS_PATH of the route, it will be replaced with that of the PE before the route is advertised.
Follow these steps to configure the BGP AS number substitution function:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
— |
Enter BGP view |
bgp as-number |
Required |
Enter BGP VPN instance view |
ipv4-family vpn-instance vpn-instance-name |
Required |
Enable the BGP AS number substitution function |
peer { ip-address | group-name } substitute-as |
Required Disabled by default |
For information about the peer { ip-address | group-name } substitute-as command, refer to BGP Commands in the IP Routing Volume.
Displaying and Maintaining MPLS L3VPN
Resetting BGP Connections
When BGP configuration changes, you can use the soft reset function or reset BGP connections to make new configurations take effect. Soft reset requires that BGP peers have route refreshment capability (supporting Route-Refresh messages).
To do… |
Use the command… |
Remarks |
Perform a soft reset of the BGP connections in a specified VPN instance |
refresh bgp vpn-instance vpn-instance-name { ip-address | all | external | group group-name } { export | import } |
Available in user view |
Perform a soft reset of the BGP VPNv4 connections |
refresh bgp vpnv4 { ip-address | all | external | group group-name | internal } { export | import } |
Available in user view |
Reset BGP connections of a VPN instance |
reset bgp vpn-instance vpn-instance-name { as-number | ip-address | all | external | group group-name } |
Available in user view |
Reset BGP VPNv4 connections |
reset bgp vpnv4 { as-number | ip-address | all | external | internal | group group-name } |
Available in user view |
Displaying and Maintaining MPLS L3VPN
To do… |
Use the command… |
Remarks |
Display information about the routing table associated with a VPN instance |
display ip routing-table vpn-instance vpn-instance-name [ verbose ] |
Available in any view |
Display information about a specified or all VPN instances |
display ip vpn-instance [ instance-name vpn-instance-name ] |
Available in any view |
Display information about the FIB of a VPN instance |
display fib vpn-instance vpn-instance-name [ include string ] |
Available in any view |
Display statistics about the FIB of all VPN instances |
display fib statistics vpn-instance |
Available in any view |
Display information about labeled routes in the BGP routing table |
display bgp vpnv4 { all | vpn-instance vpn-instance-name } routing-table label |
Available in any view |
Display information about a specified or all BGP VPNv4 peer group |
display bgp vpnv4 { all | vpn-instance vpn-instance-name } group [ group-name ] |
Available in any view |
Display information about BGP VPNv4 routes injected into a specified or all VPN instances |
display bgp vpnv4 { all | vpn-instance vpn-instance-name } network |
Available in any view |
Display BGP VPNv4 AS path information |
display bgp vpnv4 { all | vpn-instance vpn-instance-name } paths [ as-regular-expression ] |
Available in any view |
Display information about BGP VPNv4 peers |
display bgp vpnv4 { all | vpn-instance vpn-instance-name } peer [ group-name log-info | ip-address { log-info | verbose } | verbose ] |
Available in any view |
Display all BGP VPNv4 routing information |
display bgp vpnv4 all routing-table [ network-address [ { mask | mask-length } [ longer-prefixes ] ] | as-path-acl as-path-acl-number | cidr | community [ aa:nn ]&<1-13> [ no-export-subconfed | no-advertise | no-export ] * [ whole-match ] | community-list { basic-community-list-number [ whole-match ] | adv-community-list-number }&<1-16> | different-origin-as | peer ip-address { advertised-routes | received-routes } [ statistic ] | regular-expression as-regular-expression | statistic ] |
Available in any view |
Display the BGP VPNv4 routing information of a specified RD |
display bgp vpnv4 route-distinguisher route-distinguisher routing-table [ network-address [ { mask | mask-length } [ longer-prefixes ] ] | as-path-acl as-path-acl-number | cidr | community [ aa:nn ]&<1-13> [ no-export-subconfed | no-advertise | no-export ]* [ whole-match ] | community-list { basic-community-list-number [ whole-match ] | adv-community-list-number }&<1-16> | different-origin-as | regular-expression as-regular-expression ] |
Available in any view |
Display the BGP VPNv4 routing information of a specified VPN instance |
display bgp vpnv4 vpn-instance vpn-instance-name routing-table [ network-address [ { mask | mask-length } [ longer-prefixes ] ] | as-path-acl as-path-acl-number | cidr | community [ aa:nn ]&<1-13>[ no-export-subconfed | no-advertise | no-export ]* [ whole-match ] | community-list { basic-community-list-number [ whole-match ] | adv-community-list-number }&<1-16> | dampened | dampening parameter | different-origin-as | flap-info [ as-path-acl as-path-acl-number | network-address [ mask [ longer-match ] | mask-length [ longer-match ] ] | regular-expression as-regular-expression ] | peer ip-address { advertised-routes | received-routes } | regular-expression as-regular-expression | statistic ] |
Available in any view |
Display information about OSPF sham links |
display ospf [ process-id ] sham-link [ area area-id ] |
Available in any view |
Display information about a specified or all tunnel policies |
display tunnel-policy { all | policy-name tunnel-policy-name } |
Available in any view |
Clear the route flap dampening information of a VPN instance |
reset bgp vpn-instance vpn-instance-name dampening [ network-address [ mask | mask-length ] |
Available in user view |
Clear route flap history information about a BGP peer of a VPN instance |
reset bgp vpn-instance vpn-instance-name ip-address flap-info reset bgp vpn-instance vpn-instance-name flap-info [ ip-address [ mask | mask-length ] | as-path-acl as-path-acl-number | regexp as-path-regexp ] |
Available in user view |
For commands to display information about a routing table, refer to IP Routing Table Commands in the IP Routing Volume.
MPLS L3VPN Configuration Examples
Example for Configuring MPLS L3VPNs
Network requirements
l CE 1 and CE 3 belong to VPN 1, while CE 2 and CE 4 belong to VPN 2.
l VPN 1 uses VPN target attributes 111:1, while VPN 2 uses VPN target attributes 222:2. Users of different VPNs cannot access each other.
l PEs and the P device support MPLS.
Network diagram
Figure 1-17 Configure MPLS L3VPNs
Interface |
IP address |
Device |
Interface |
IP address |
|
CE 1 |
Vlan-int1 |
10.1.1.1/24 |
P |
Loop0 |
2.2.2.9/32 |
PE 1 |
Loop0 |
1.1.1.9/32 |
|
Vlan-int1 |
172.2.1.1/24 |
|
Vlan-int1 |
10.1.1.2/24 |
|
Vlan-int3 |
172.1.1.2/24 |
|
Vlan-int3 |
172.1.1.1/24 |
PE 2 |
Loop0 |
3.3.3.9/32 |
|
Vlan-int2 |
10.2.1.2/24 |
|
Vlan-int1 |
172.2.1.2/24 |
CE 2 |
Vlan-int1 |
10.2.1.1/24 |
|
Vlan-int2 |
10.3.1.2/24 |
CE 3 |
Vlan-int1 |
10.3.1.1/24 |
|
Vlan-int3 |
10.4.1.2/24 |
CE 4 |
Vlan-int1 |
10.4.1.1/24 |
|
|
|
Configuration procedure
1) Configure IGP on the MPLS backbone, enabling the PEs and the P device to communicate
# Configure PE 1.
<PE1> system-view
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 1.1.1.9 32
[PE1-LoopBack0] quit
[PE1] interface vlan-interface 3
[PE1-Vlan-interface3] ip address 172.1.1.1 24
[PE1-Vlan-interface3] quit
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Configure the P device.
<P> system-view
[P] interface loopback 0
[P-LoopBack0] ip address 2.2.2.9 32
[P-LoopBack0] quit
[P] interface vlan-interface 3
[P-Vlan-interface3] ip address 172.1.1.2 24
[P-Vlan-interface3] quit
[P] interface vlan-interface 1
[P-Vlan-interface1] ip address 172.2.1.1 24
[P-Vlan-interface1] quit
[P] ospf
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] quit
# Configure PE 2.
<PE2> system-view
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 3.3.3.9 32
[PE2-LoopBack0] quit
[PE2] interface vlan-interface 1
[PE2-Vlan-interface1] ip address 172.2.1.2 24
[PE2-Vlan-interface1] quit
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255
[PE2-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
After you complete the above configurations, OSPF adjacency should be established between PE 1, P, and PE 2. Issuing the display ospf peer command, you can see that the adjacency status is Full. Issuing the display ip routing-table command, you can see that the PEs have learned the loopback route of each other. The following takes PE 1 as an example:
[PE1] display ip routing-table
Routing Tables: Public
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0
2.2.2.9/32 OSPF 10 1 172.1.1.2 Vlan3
3.3.3.9/32 OSPF 10 2 172.1.1.2 Vlan3
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.1.1.0/24 Direct 0 0 172.1.1.1 Vlan3
172.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
172.1.1.2/32 Direct 0 0 172.1.1.2 Vlan3
172.2.1.0/24 OSPF 10 1 172.1.1.2 Vlan3
[PE1] display ospf peer verbose
OSPF Process 1 with Router ID 1.1.1.9
Neighbors
Area 0.0.0.0 interface 172.1.1.1(Vlan-interface3)'s neighbors
Router ID: 172.1.1.2 Address: 172.1.1.2 GR State: Normal
State: Full Mode:Nbr is Master Priority: 1
DR: None BDR: None MTU: 1500
Dead timer due in 38 sec
Neighbor is up for 00:02:44
Authentication Sequence: [ 0 ]
Neighbor state change count: 5
2) Configure MPLS basic capability and MPLS LDP on the MPLS backbone to establish LDP LSPs
# Configure PE 1.
[PE1] mpls lsr-id 1.1.1.9
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] interface vlan-interface 3
[PE1-Vlan-interface3] mpls
[PE1-Vlan-interface3] mpls ldp
[PE1-Vlan-interface3] quit
# Configure the P device.
[P] mpls lsr-id 2.2.2.9
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
[P] interface vlan-interface 3
[P-Vlan-interface3] mpls
[P-Vlan-interface3] mpls ldp
[P-Vlan-interface3] quit
[P] interface vlan-interface 1
[P-Vlan-interface1] mpls
[P-Vlan0interface1] mpls ldp
[P-Vlan-interface1] quit
# Configure PE 2.
[PE2] mpls lsr-id 3.3.3.9
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2] interface vlan-interface 1
[PE2-Vlan-interface1] mpls
[PE2-Vlan-interface1] mpls ldp
[PE2-Vlan-interface1] quit
After you complete the above configurations, LDP sessions should be established between PE 1, P, and PE 2. Issuing the display mpls ldp session command, you can see that the Session State field has a value of Operational. Issuing the display mpls ldp lsp command, you can see that the LSPs established by LDP. The following takes PE 1 as an example:
[PE1] display mpls ldp session
LDP Session(s) in Public Network
----------------------------------------------------------------
Peer-ID Status LAM SsnRole FT MD5 KA-Sent/Rcv
---------------------------------------------------------------
2.2.2.9:0 Operational DU Passive Off Off 5/5
---------------------------------------------------------------
LAM : Label Advertisement Mode FT : Fault Tolerance
[PE1] display mpls ldp lsp
LDP LSP Information
------------------------------------------------------------------
SN DestAddress/Mask In/OutLabel Next-Hop In/Out-Interface
------------------------------------------------------------------
1 1.1.1.9/32 3/NULL 127.0.0.1 Vlan-interface3/InLoop0
2 2.2.2.9/32 NULL/3 172.1.1.2 -------/Vlan-interface3
3 3.3.3.9/32 NULL/1024 172.1.1.2 -------/Vlan-interface3
------------------------------------------------------------------
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
3) Configure VPN instances on PEs to allow CEs to access
# Configure PE 1.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 100:1
[PE1-vpn-instance-vpn1] vpn-target 111:1
[PE1-vpn-instance-vpn1] quit
[PE1] ip vpn-instance vpn2
[PE1-vpn-instance-vpn2] route-distinguisher 100:2
[PE1-vpn-instance-vpn2] vpn-target 222:2
[PE1-vpn-instance-vpn2] quit
[PE1] interface vlan-interface 1
[PE1-Vlan-interface1] ip binding vpn-instance vpn1
[PE1-Vlan-interface1] ip address 10.1.1.2 24
[PE1-Vlan-interface1] quit
[PE1] interface vlan-interface 2
[PE1-Vlan-interface2] ip binding vpn-instance vpn2
[PE1-Vlan-interface2] ip address 10.2.1.2 24
[PE1-Vlan-interface2] quit
# Configure PE 2.
[PE2] ip vpn-instance vpn1
[PE2-vpn-instance-vpn1] route-distinguisher 200:1
[PE2-vpn-instance-vpn1] vpn-target 111:1
[PE2-vpn-instance-vpn1] quit
[PE2] ip vpn-instance vpn2
[PE2-vpn-instance-vpn2] route-distinguisher 200:2
[PE2-vpn-instance-vpn2] vpn-target 222:2
[PE2-vpn-instance-vpn2] quit
[PE2] interface vlan-interface 2
[PE2-Vlan-interface2] ip binding vpn-instance vpn1
[PE2-Vlan-interface2] ip address 10.3.1.2 24
[PE2-Vlan-interface2] quit
[PE2] interface vlan-interface 3
[PE2-Vlan-interface3] ip binding vpn-instance vpn2
[PE2-Vlan-interface3] ip address 10.4.1.2 24
[PE2-Vlan-interface3] quit
# Configure IP addresses for the CEs as required in Figure 1-17. The detailed configuration steps are omitted.
After completing the above configurations, you can issue the display ip vpn-instance command on the PEs to view the configuration of the VPN instance. The PEs should be capable of pinging their respective CEs. The following takes PE 1 and CE 1 as an example:
[PE1] display ip vpn-instance
Total VPN-Instances configured : 2
VPN-Instance Name RD Create Time
vpn1 100:1 2006/08/13 09:32:45
vpn2 100:2 2006/08/13 09:42:59
[PE1] ping -vpn-instance vpn1 10.1.1.1
PING 10.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 10.1.1.1: bytes=56 Sequence=1 ttl=255 time=56 ms
Reply from 10.1.1.1: bytes=56 Sequence=2 ttl=255 time=4 ms
Reply from 10.1.1.1: bytes=56 Sequence=3 ttl=255 time=4 ms
Reply from 10.1.1.1: bytes=56 Sequence=4 ttl=255 time=52 ms
Reply from 10.1.1.1: bytes=56 Sequence=5 ttl=255 time=3 ms
--- 10.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 3/23/56 ms
4) Establish EBGP peer relationship between PEs and CEs to allow VPN routes to be injected
# Configure CE 1.
<CE1> system-view
[CE1] bgp 65410
[CE1-bgp] peer 10.1.1.2 as-number 100
[CE1-bgp] import-route direct
[CE1-bgp] quit
The configurations for the other three CEs are similar to the above. The detailed configuration steps are omitted.
# Configure PE 1.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] peer 10.1.1.1 as-number 65410
[PE1-bgp-vpn1] import-route direct
[PE1-bgp-vpn1] quit
[PE1-bgp] ipv4-family vpn-instance vpn2
[PE1-bgp-vpn2] peer 10.2.1.1 as-number 65420
[PE1-bgp-vpn2] import-route direct
[PE1-bgp-vpn2] quit
[PE1-bgp] quit
The configurations for PE 2 are similar to those for PE 1. The detailed configuration steps are omitted.
After completing the above configuration, if you issue the display bgp vpnv4 vpn-instance peer command on the PEs, you should see that BGP peer relationship has been established between PE and CE, and has reached the state of Established. The following takes PE 1 and CE 1 as an example:
[PE1] display bgp vpnv4 vpn-instance vpn1 peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
10.1.1.1 4 65410 11 9 0 1 00:06:37 Established
5) Configure MP-IBGP peers between PEs
# Configure PE 1.
[PE1] bgp 100
[PE1-bgp] peer 3.3.3.9 as-number 100
[PE1-bgp] peer 3.3.3.9 connect-interface loopback 0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
# Configure PE 2.
[PE2] bgp 100
[PE2-bgp] peer 1.1.1.9 as-number 100
[PE2-bgp] peer 1.1.1.9 connect-interface loopback 0
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpnv4] peer 1.1.1.9 enable
[PE2-bgp-af-vpnv4] quit
[PE2-bgp] quit
After completing the above configuration, if you issue the display bgp peer command or the display bgp vpnv4 all peer command on the PEs, you should see that BGP peer relationship has been established between the PEs, and has reached the state of Established.
[PE1] display bgp peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
3.3.3.9 4 100 2 6 0 0 00:00:12 Established
6) Verify your configurations
Issuing the display ip routing-table vpn-instance command on the PEs, you should see the routes to the CEs. The following takes PE 1 as an example:
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 3 Routes : 3
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 Direct 0 0 10.1.1.2 Vlan1
10.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
10.3.1.0/24 BGP 255 0 3.3.3.9 NULL0
[PE1] display ip routing-table vpn-instance vpn2
Routing Tables: vpn2
Destinations : 3 Routes : 3
Destination/Mask Proto Pre Cost NextHop Interface
10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan2
10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0
10.4.1.0/24 BGP 255 0 3.3.3.9 NULL0
CEs of the same VPN should be capable of pinging each other, whereas those of different VPNs should not. For example, CE 1 should be capable of pinging CE 3 (10.3.1.1), but should not be capable of pinging CE 4 (10.4.1.1):
[CE1] ping 10.3.1.1
PING 10.3.1.1: 56 data bytes, press CTRL_C to break
Reply from 10.3.1.1: bytes=56 Sequence=1 ttl=253 time=72 ms
Reply from 10.3.1.1: bytes=56 Sequence=2 ttl=253 time=34 ms
Reply from 10.3.1.1: bytes=56 Sequence=3 ttl=253 time=50 ms
Reply from 10.3.1.1: bytes=56 Sequence=4 ttl=253 time=50 ms
Reply from 10.3.1.1: bytes=56 Sequence=5 ttl=253 time=34 ms
--- 10.3.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 34/48/72 ms
[CE1] ping 10.4.1.1
PING 10.4.1.1: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 10.4.1.1 ping statistics ---
5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
Example for Configuring Inter-Provider VPN Option A
Network requirements
l CE 1 and CE 2 belong to the same VPN. CE 1 accesses the network through PE 1 in AS 100 and CE 2 accesses the network through PE 2 in AS 200.
l Inter-provider MPLS L3VPN is implemented using option A. That is, the VRF-to-VRF method is used to manage VPN routes.
l The MPLS backbone in each AS runs OSPF.
Network diagram
Figure 1-18 Configure inter-provider VPN option A
Device |
Interface |
IP address |
Device |
Interface |
IP address |
CE 1 |
Vlan-int1 |
10.1.1.1/24 |
CE 2 |
Vlan-int1 |
10.2.1.1/24 |
PE 1 |
Loop0 |
1.1.1.9/32 |
PE 2 |
Loop0 |
4.4.4.9/32 |
|
Vlan-int1 |
10.1.1.2/24 |
|
Vlan-int1 |
10.2.1.2/24 |
|
Vlan-int2 |
172.1.1.2/24 |
|
Vlan-int2 |
162.1.1.2/24 |
ASBR-PE 1 |
Loop0 |
2.2.2.9/32 |
ASBR-PE 2 |
Loop0 |
3.3.3.9/32 |
|
Vlan-int1 |
172.1.1.1/24 |
|
Vlan-int1 |
162.1.1.1/24 |
|
Vlan-int2 |
192.1.1.1/24 |
|
Vlan-int2 |
192.1.1.2/24 |
Configuration procedure
1) Configure IGP on the MPLS backbone, implementing the connectivity in the backbone
This example uses OSPF. The detailed configuration steps are omitted.
The 32-bit loopback interface address used as the LSR ID needs to be advertised by OSPF.
After you complete the above configurations, each ASBR PE and the PE in the same AS should be able to establish OSPF adjacencies. Issuing the display ospf peer command, you can see that the adjacencies reach the state of Full, and that PEs can learn the loopback addresses of each other.
Each ASBR PE and the PE in the same AS should be able to ping each other.
2) Configure MPLS basic capability and MPLS LDP on the MPLS backbone to establish LDP LSPs
# Configure MPLS basic capability on PE 1 and enable MPLS LDP on the interface connected to ASBR PE 1.
<PE1> system-view
[PE1] mpls lsr-id 1.1.1.9
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] interface vlan-interface 1
[PE1-Vlan-interface1] mpls
[PE1-Vlan-interface1] mpls ldp
[PE1-Vlan-interface1] quit
# Configure MPLS basic capability on ASBR PE 1 and enable MPLS LDP on the interface connected to PE 1.
<ASBR-PE1> system-view
[ASBR-PE1] mpls lsr-id 2.2.2.9
[ASBR-PE1] mpls
[ASBR-PE1-mpls] quit
[ASBR-PE1] mpls ldp
[ASBR-PE1-mpls-ldp] quit
[ASBR-PE1] interface vlan-interface 1
[ASBR-PE1-Vlan-interface1] mpls
[ASBR-PE1-Vlan-interface1] mpls ldp
[ASBR-PE1-Vlan-interface1] quit
# Configure MPLS basic capability on ASBR PE 2 and enable MPLS LDP on the interface connected to PE 2.
<ASBR-PE2> system-view
[ASBR-PE2] mpls lsr-id 3.3.3.9
[ASBR-PE2] mpls
[ASBR-PE2-mpls] quit
[ASBR-PE2] mpls ldp
[ASBR-PE2-mpls-ldp] quit
[ASBR-PE2] interface vlan-interface 1
[ASBR-PE2-Vlan-interface1] mpls
[ASBR-PE2-Vlan-interface1] mpls ldp
[ASBR-PE2-Vlan-interface1] quit
# Configure MPLS basic capability on PE 2 and enable MPLS LDP on the interface connected to ASBR PE 2.
<PE2> system-view
[PE2] mpls lsr-id 4.4.4.9
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2] interface vlan-interface 2
[PE2-Vlan-interface2] mpls
[PE2-Vlan-interface2] mpls ldp
[PE2-Vlan-interface2] quit
After you complete the above configurations, each PE and the ASBR PE in the same AS should be able to establish neighbor relationship. Issuing the display mpls ldp session command on the devices, you can see that the Session State field has a value of Operational in the output information.
3) Configure VPN instances on PEs to allow CEs to access
The VPN targets for the VPN instances of the PEs must match those for the VPN instances of the ASBR-PEs in the same AS. It is not required for PEs in different ASs.
# Configure CE 1.
<CE1> system-view
[CE1] interface vlan-interface 1
[CE1-Vlan-interface1] ip address 10.1.1.1 24
[CE1-Vlan-interface1] quit
# Configure PE 1.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 100:1
[PE1-vpn-instance-vpn1] vpn-target 100:1 both
[PE1-vpn-instance-vpn1] quit
[PE1] interface vlan-interface 1
[PE1-Vlan-interface1] ip binding vpn-instance vpn1
[PE1-Vlan-interface1] ip address 10.1.1.2 24
[PE1-Vlan-interface1] quit
# Configure CE 2.
<CE2> system-view
[CE2] interface vlan-interface 1
[CE2-Vlan-interface1] ip address 10.2.1.1 24
[CE2-Vlan-interface1] quit
# Configure PE 2.
[PE2] ip vpn-instance vpn1
[PE2-vpn-instance] route-distinguisher 200:2
[PE2-vpn-instance] vpn-target 100:1 both
[PE2-vpn-instance] quit
[PE2] interface vlan-interface 1
[PE2-Vlan-interface1] ip binding vpn-instance vpn1
[PE2-Vlan-interface1] ip address 10.2.1.2 24
[PE2-Vlan-interface1] quit
# Configure ASBR PE 1, creating a VPN instance and binding the instance to the interface connected with ASBR PE 2. Note that ASBR PE 1 considers ASBR PE 2 its CE.
[ASBR-PE1] ip vpn-instance vpn1
[ASBR-PE1-vpn-instance-vpn1] route-distinguisher 100:1
[ASBR-PE1-vpn-instance-vpn1] vpn-target 100:1 both
[ASBR-PE1-vpn-instance-vpn1] quit
[ASBR-PE1] interface vlan-interface 2
[ASBR-PE1-Vlan-interface2] ip binding vpn-instance vpn1
[ASBR-PE1-Vlan-interface2] ip address 192.1.1.1 24
[ASBR-PE1-Vlan-interface2] quit
# Configure ASBR PE 2, creating a VPN instance and binding the instance to the interface connected with ASBR PE 1. Note that ASBR PE 2 considers ASBR PE 1 its CE.
[ASBR-PE2] ip vpn-instance vpn1
[ASBR-PE2-vpn-vpn-vpn1] route-distinguisher 200:1
[ASBR-PE2-vpn-vpn-vpn1] vpn-target 100:1 both
[ASBR-PE2-vpn-vpn-vpn1] quit
[ASBR-PE2] interface vlan-interface 2
[ASBR-PE2-Vlan-interface2] ip binding vpn-instance vpn1
[ASBR-PE2-Vlan-interface2] ip address 192.1.1.2 24
[ASBR-PE2-Vlan-interface2] quit
After completing the above configurations, you should see the VPN instance configurations by issuing the display ip vpn-instance command.
The PEs should be able to ping the CEs and the ASBR PEs should be able to ping each other.
4) Establish EBGP peer relationship between PEs and CEs to allow VPN routes to be injected
# Configure CE 1.
[CE1] bgp 65001
[CE1-bgp] peer 10.1.1.2 as-number 100
[CE1-bgp] import-route direct
[CE1-bgp] quit
# Configure PE 1.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] peer 10.1.1.1 as-number 65001
[PE1-bgp-vpn1] import-route direct
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure CE 2.
[CE2] bgp 65002
[CE2-bgp] peer 10.2.1.2 as-number 200
[CE2-bgp] import-route direct
[CE2-bgp] quit
# Configure PE 2.
[PE2] bgp 200
[PE2-bgp] ipv4-family vpn-instance vpn1
[PE2-bgp-vpn1] peer 10.2.1.1 as-number 65002
[PE2-bgp-vpn1] import-route direct
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
5) Establish IBGP peer relationship between each PE and the ASBR PE in the same AS and EBGP peer relationship between the ASBR PEs
# Configure PE 1.
[PE1] bgp 100
[PE1-bgp] peer 2.2.2.9 as-number 100
[PE1-bgp] peer 2.2.2.9 connect-interface loopback 0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[PE1-bgp-af-vpnv4] peer 2.2.2.9 next-hop-local
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
# Configure ASBR PE 1.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] ipv4-family vpn-instance vpn1
[ASBR-PE1-bgp-vpn1] peer 192.1.1.2 as-number 200
[ASBR-PE1-bgp-vpn1] quit
[ASBR-PE1-bgp] peer 1.1.1.9 as-number 100
[ASBR-PE1-bgp] peer 1.1.1.9 connect-interface loopback 0
[ASBR-PE1-bgp] ipv4-family vpnv4
[ASBR-PE1-bgp-af-vpnv4] peer 1.1.1.9 enable
[ASBR-PE1-bgp-af-vpnv4] peer 1.1.1.9 next-hop-local
[ASBR-PE1-bgp-af-vpnv4] quit
[ASBR-PE1-bgp] quit
# Configure ASBR PE 2.
[ASBR-PE2] bgp 200
[ASBR-PE2-bgp] ipv4-family vpn-instance vpn1
[ASBR-PE2-bgp-vpn1] peer 192.1.1.1 as-number 100
[ASBR-PE2-bgp-vpn1] quit
[ASBR-PE2-bgp] peer 4.4.4.9 as-number 200
[ASBR-PE2-bgp] peer 4.4.4.9 connect-interface loopback 0
[ASBR-PE2-bgp] ipv4-family vpnv4
[ASBR-PE2-bgp-af-vpnv4] peer 4.4.4.9 enable
[ASBR-PE2-bgp-af-vpnv4] peer 4.4.4.9 next-hop-local
[ASBR-PE2-bgp-af-vpnv4] quit
[ASBR-PE2-bgp] quit
# Configure PE 2.
[PE2] bgp 200
[PE2-bgp] peer 3.3.3.9 as-number 200
[PE2-bgp] peer 3.3.3.9 connect-interface loopback 0
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpnv4] peer 3.3.3.9 enable
[PE2-bgp-af-vpnv4] peer 3.3.3.9 next-hop-local
[PE2-bgp-af-vpnv4] quit
[PE2-bgp] quit
6) Verify your configurations
After you complete the above configurations, the CEs should be able to learn the interface routes from each other and ping each other.
Example for Configuring Inter-Provider VPN Option B
Network requirements
l Site 1 and Site 2 belong to the same VPN. CE 1 of Site 1 accesses the network through PE 1 in AS 100 and CE 2 of Site 2 accesses the network through PE 2 in AS 600.
l PEs in the same AS runs IS-IS between them.
l PE 1 and ASBR-PE 1 exchange labeled IPv4 routes by MP-IBGP.
l PE 2 and ASBR-PE 2 exchange labeled IPv4 routes by MP-IBGP.
l ASBR-PE 1 and ASBR-PE 2 exchange labeled IPv4 routes by MP-EBGP.
l ASBRs do not perform VPN target filtering of received VPN-IPv4 routes.
Network diagram
Figure 1-19 Configure inter-provider VPN option B
Device |
Interface |
IP address |
Device |
Interface |
IP address |
PE 1 |
Loop0 |
2.2.2.9/32 |
PE 2 |
Loop0 |
5.5.5.9/32 |
|
Vlan-int1 |
30.0.0.1/8 |
|
Vlan-int1 |
20.0.0.1/8 |
|
Vlan-int2 |
1.1.1.2/8 |
|
Vlan-int2 |
9.1.1.2/8 |
ASBR-PE 1 |
Loop0 |
3.3.3.9/32 |
ASBR-PE 2 |
Loop0 |
4.4.4.9/32 |
|
Vlan-int1 |
1.1.1.1/8 |
|
Vlan-int1 |
9.1.1.1/8 |
|
Vlan-int2 |
11.0.0.2/8 |
|
Vlan-int2 |
11.0.0.1/8 |
Configuration procedure
1) Configure PE 1
# Run IS-IS on PE 1.
<PE1> system-view
[PE1] isis 1
[PE1-isis-1] network-entity 10.111.111.111.111.00
[PE1-isis-1] quit
# Configure LSR ID, enable MPLS and LDP.
[PE1] mpls lsr-id 2.2.2.9
[PE1] mpls
[PE1-mpls] label advertise non-null
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure interface VLAN-interface 2, start IS-IS and enable MPLS and LDP on the interface.
[PE1] interface vlan-interface 2
[PE1-Vlan-interface2] ip address 1.1.1.2 255.0.0.0
[PE1-Vlan-interface2] isis enable 1
[PE1-Vlan-interface2] mpls
[PE1-Vlan-interface2] mpls ldp
[PE1-Vlan-interface2] quit
# Configure interface Loopback 0 and start IS-IS on it.
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 2.2.2.9 32
[PE1-LoopBack0] isis enable 1
[PE1-LoopBack0] quit
# Create VPN instance vpn1 and configure the RD and VPN target attributes.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 11:11
[PE1-vpn-instance-vpn1] vpn-target 1:1 2:2 3:3 import-extcommunity
[PE1-vpn-instance-vpn1] vpn-target 3:3 export-extcommunity
[PE1-vpn-instance-vpn1] quit
# Bind the interface connected with CE 1 to the created VPN instance.
[PE1] interface vlan-interface 1
[PE1-Vlan-interface1] ip binding vpn-instance vpn1
[PE1-Vlan-interface1] ip address 30.0.0.1 8
[PE1-Vlan-interface1] quit
# Start BGP on PE 1.
[PE1] bgp 100
# Configure IBGP peer 3.3.3.9 as a VPNv4 peer.
[PE1-bgp] peer 3.3.3.9 as-number 100
[PE1-bgp] peer 3.3.3.9 connect-interface loopback 0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[PE1-bgp-af-vpnv4] quit
# Specify to inject direct routes to the VPN routing table of vpn1.
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] import-route direct
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
2) Configure ASBR-PE 1
# Start IS-IS on ASBR-PE 1.
<ASBR-PE1> system-view
[ASBR-PE1] isis 1
[ASBR-PE1-isis-1] network-entity 10.222.222.222.222.00
[ASBR-PE1-isis-1] quit
# Configure LSR ID, enable MPLS and LDP.
[ASBR-PE1] mpls lsr-id 3.3.3.9
[ASBR-PE1] mpls
[ASBR-PE1-mpls] label advertise non-null
[ASBR-PE1-mpls] quit
[ASBR-PE1] mpls ldp
[ASBR-PE1-mpls-ldp] quit
# Configure interface VLAN-interface 1, start IS-IS and enable MPLS and LDP on the interface.
[ASBR-PE1] interface vlan-interface 1
[ASBR-PE1-Vlan-interface1] ip address 1.1.1.1 255.0.0.0
[ASBR-PE1-Vlan-interface1] isis enable 1
[ASBR-PE1-Vlan-interface1] mpls
[ASBR-PE1-Vlan-interface1] mpls ldp
[ASBR-PE1-Vlan-interface1] quit
# Configure interface VLAN-interface 2 and enable MPLS on it.
[ASBR-PE1] interface vlan-interface 2
[ASBR-PE1-Vlan-interface2] ip address 11.0.0.2 255.0.0.0
[ASBR-PE1-Vlan-interface2] mpls
[ASBR-PE1-Vlan-interface2] quit
# Configure interface Loopback 0 and start IS-IS on it.
[ASBR-PE1] interface loopback 0
[ASBR-PE1-LoopBack0] ip address 3.3.3.9 32
[ASBR-PE1-LoopBack0] isis enable 1
[ASBR-PE1-LoopBack0] quit
# Start BGP on ASBR-PE 1.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] peer 2.2.2.9 as-number 100
[ASBR-PE1-bgp] peer 2.2.2.9 connect-interface loopback 0
[ASBR-PE1-bgp] peer 11.0.0.1 as-number 600
[ASBR-PE1-bgp] peer 11.0.0.1 connect-interface vlan-interface 2
# Specify not to filter the received VPNv4 routes using the import target attribute.
[ASBR-PE1-bgp] ipv4-family vpnv4
[ASBR-PE1-bgp-af-vpnv4] undo policy vpn-target
# Configure both IBGP peer 2.2.2.0 and EBGP peer 11.0.0.1 as VPNv4 peers.
[ASBR-PE1-bgp-af-vpnv4] peer 11.0.0.1 enable
[ASBR-PE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[ASBR-PE1-bgp-af-vpnv4] quit
3) Configure ASBR-PE 2
# Start IS-IS on ASBR-PE 2.
<ASBR-PE2> system-view
[ASBR-PE2] isis 1
[ASBR-PE2-isis-1] network-entity 10.222.222.222.222.00
[ASBR-PE2-isis-1] quit
# Configure LSR ID, enable MPLS and LDP.
[ASBR-PE2] mpls lsr-id 4.4.4.9
[ASBR-PE2] mpls
[ASBR-PE2-mpls] label advertise non-null
[ASBR-PE2-mpls] quit
[ASBR-PE2] mpls ldp
[ASBR-PE2-mpls-ldp] quit
# Configure interface VLAN-interface 1, start IS-IS and enable MPLS and LDP on the interface.
[ASBR-PE2] interface vlan-interface 1
[ASBR-PE2-Vlan-interface1] ip address 9.1.1.1 255.0.0.0
[ASBR-PE2-Vlan-interface1] isis enable 1
[ASBR-PE2-Vlan-interface1] mpls
[ASBR-PE2-Vlan-interface1] mpls ldp
[ASBR-PE2-Vlan-interface1] quit
# Configure interface VLAN-interface 2 and enable MPLS on it.
[ASBR-PE2] interface vlan-interface 2
[ASBR-PE2-Vlan-interface2] ip address 11.0.0.1 255.0.0.0
[ASBR-PE2-Vlan-interface2] mpls
[ASBR-PE2-Vlan-interface2] quit
# Configure interface Loopback 0 and start IS-IS on it.
[ASBR-PE2] interface loopback 0
[ASBR-PE2-LoopBack0] ip address 4.4.4.9 32
[ASBR-PE2-LoopBack0] isis enable 1
[ASBR-PE2-LoopBack0] quit
# Start BGP on ASBR-PE 2.
[ASBR-PE2] bgp 600
[ASBR-PE2-bgp] peer 11.0.0.2 as-number 100
[ASBR-PE2-bgp] peer 11.0.0.2 connect-interface vlan-interface 2
[ASBR-PE2-bgp] peer 5.5.5.9 as-number 600
[ASBR-PE2-bgp] peer 5.5.5.9 connect-interface loopback 0
# Specify not to filter the received VPNv4 routes using the import target attribute.
[ASBR-PE2-bgp] ipv4-family vpnv4
[ASBR-PE2-bgp-af-vpnv4] undo policy vpn-target
# Configure both IBGP peer 5.5.5.9 and EBGP peer 11.0.0.2 as VPNv4 peers.
[ASBR-PE2-bgp-af-vpnv4] peer 11.0.0.2 enable
[ASBR-PE2-bgp-af-vpnv4] peer 5.5.5.9 enable
[ASBR-PE2-bgp-af-vpnv4] quit
[ASBR-PE2-bgp] quit
4) Configure PE 2
# Start IS-IS on PE 2.
<PE2> system-view
[PE2] isis 1
[PE2-isis-1] network-entity 10.111.111.111.111.00
[PE2-isis-1] quit
# Configure LSR ID, enable MPLS and LDP.
[PE2] mpls lsr-id 5.5.5.9
[PE2] mpls
[PE2-mpls] label advertise non-null
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
# Configure interface VLAN-interface 2, start IS-IS and enable MPLS and LDP on the interface.
[PE2] interface vlan-interface 2
[PE2-Vlan-interface2] ip address 9.1.1.2 255.0.0.0
[PE2-Vlan-interface2] isis enable 1
[PE2-Vlan-interface2] mpls
[PE2-Vlan-interface2] mpls ldp
[PE2-Vlan-interface2] quit
# Configure interface Loopback 0 and start IS-IS on it.
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 5.5.5.9 32
[PE2-LoopBack0] isis enable 1
[PE2-LoopBack0] quit
# Create VPN instance vpn1 and configure the RD and VPN target attributes.
[PE2] ip vpn-instance vpn1
[PE2-vpn-instance-vpn1] route-distinguisher 12:12
[PE2-vpn-instance-vpn1] vpn-target 1:1 2:2 3:3 import-extcommunity
[PE2-vpn-instance-vpn1] vpn-target 3:3 export-extcommunity
[PE2-vpn-instance-vpn1] quit
# Bind the interface connected with CE 2 to the created VPN instance.
[PE2] interface vlan-interface 1
[PE2-Vlan-interface1] ip binding vpn-instance vpn1
[PE2-Vlan-interface1] ip address 20.0.0.1 8
[PE2-Vlan-interface1] quit
# Start BGP on PE 2.
[PE2] bgp 600
# Configure IBGP peer 4.4.4.9 as a VPNv4 peer.
[PE2-bgp] peer 4.4.4.9 as-number 600
[PE2-bgp] peer 4.4.4.9 connect-interface loopback 0
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpnv4] peer 4.4.4.9 enable
[PE2-bgp-af-vpnv4] quit
# Specify to inject direct routes to the VPN routing table of vpn1.
[PE2-bgp] ipv4-family vpn-instance vpn1
[PE2-bgp-vpn1] import-route direct
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
5) Verify your configurations
After you complete the above configurations, PE 1 and PE 2 should be able to ping each other.
Example for Configuring Inter-Provider VPN Option C
Network requirements
l Site 1 and Site 2 belong to the same VPN. Site 1 accesses the network through PE 1 in AS 100 and Site 2 accesses the network through PE 2 in AS 600.
l PEs in the same AS runs IS-IS between them.
l PE 1 and ASBR-PE 1 exchange labeled IPv4 routes by MP-IBGP.
l PE 2 and ASBR-PE 2 exchange labeled IPv4 routes by MP-IBGP.
l PE 1 and PE 2 are MP-EBGP peers.
l ASBR-PE 1 and ASBR-PE 2 use their respective routing policies and label the routes received from each other.
l ASBR-PE 1 and ASBR-PE 2 use MP-EBGP to exchange labeled IPv4 routes.
Network diagram
Figure 1-20 Configure inter-provider VPN option C
Device |
Interface |
IP address |
Device |
Interface |
IP address |
PE 1 |
Loop0 |
2.2.2.9/32 |
PE 2 |
Loop0 |
5.5.5.9/32 |
|
Loop1 |
30.0.0.1/32 |
|
Loop1 |
20.0.0.1/32 |
|
Vlan-int1 |
1.1.1.2/8 |
|
Vlan-int1 |
9.1.1.2/8 |
ASBR-PE 1 |
Loop0 |
3.3.3.9/32 |
ASBR-PE 2 |
Loop0 |
4.4.4.9/32 |
|
Vlan-int1 |
1.1.1.1/8 |
|
Vlan-int1 |
9.1.1.1/8 |
|
Vlan-int2 |
11.0.0.2/8 |
|
Vlan-int2 |
11.0.0.1/8 |
Configuration procedure
1) Configure PE 1
# Run IS-IS on PE 1.
<PE1> system-view
[PE1] isis 1
[PE1-isis-1] network-entity 10.111.111.111.111.00
[PE1-isis-1] quit
# Configure LSR ID, enable MPLS and LDP.
[PE1] mpls lsr-id 2.2.2.9
[PE1] mpls
[PE1-mpls] label advertise non-null
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure interface VLAN-interface 1, start IS-IS and enable MPLS and LDP on the interface.
[PE1] interface vlan-interface 1
[PE1-Vlan-interface1] ip address 1.1.1.2 255.0.0.0
[PE1-Vlan-interface1] isis enable 1
[PE1-Vlan-interface1] mpls
[PE1-Vlan-interface1] mpls ldp
[PE1-Vlan-interface1] quit
# Configure interface Loopback 0 and start IS-IS on it.
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 2.2.2.9 32
[PE1-LoopBack0] isis enable 1
[PE1-LoopBack0] quit
# Create VPN instance vpn1 and configure the RD and VPN target attributes.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 11:11
[PE1-vpn-instance-vpn1] vpn-target 1:1 2:2 3:3 import-extcommunity
[PE1-vpn-instance-vpn1] vpn-target 3:3 export-extcommunity
[PE1-vpn-instance-vpn1] quit
# Configure interface Loopback 1 and bind the interface to VPN instance vpn1.
[PE1] interface loopback 1
[PE1-LoopBack1] ip binding vpn-instance vpn1
[PE1-LoopBack1] ip address 30.0.0.1 32
[PE1-LoopBack1] quit
# Start BGP on PE 1.
[PE1] bgp 100
# Configure the capability to advertise labeled routes to IBGP peer 3.3.3.9 and to receive labeled routes from the peer.
[PE1-bgp] peer 3.3.3.9 as-number 100
[PE1-bgp] peer 3.3.3.9 connect-interface loopback 0
[PE1-bgp] peer 3.3.3.9 label-route-capability
# Configure the maximum hop count from PE 1 to EBGP peer 5.5.5.9 as 10.
[PE1-bgp] peer 5.5.5.9 as-number 600
[PE1-bgp] peer 5.5.5.9 connect-interface loopback 0
[PE1-bgp] peer 5.5.5.9 ebgp-max-hop 10
# Configure peer 5.5.5.9 as a VPNv4 peer.
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 5.5.5.9 enable
[PE1-bgp-af-vpnv4] quit
# Specify to inject direct routes to the routing table of vpn1.
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] import-route direct
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
2) Configure ASBR-PE 1
# Start IS-IS on ASBR-PE 1.
<ASBR-PE1> system-view
[ASBR-PE1] isis 1
[ASBR-PE1-isis-1] network-entity 10.222.222.222.222.00
[ASBR-PE1-isis-1] quit
# Configure LSR ID, enable MPLS and LDP.
[ASBR-PE1] mpls lsr-id 3.3.3.9
[ASBR-PE1] mpls
[ASBR-PE1-mpls] label advertise non-null
[ASBR-PE1-mpls] quit
[ASBR-PE1] mpls ldp
[ASBR-PE1-mpls-ldp] quit
# Configure interface VLAN-interface 1, start IS-IS and enable MPLS and LDP on the interface.
[ASBR-PE1] interface vlan-interface 1
[ASBR-PE1-Vlan-interface1] ip address 1.1.1.1 255.0.0.0
[ASBR-PE1-Vlan-interface1] isis enable 1
[ASBR-PE1-Vlan-interface1] mpls
[ASBR-PE1-Vlan-interface1] mpls ldp
[ASBR-PE1-Vlan-interface1] quit
# Configure interface VLAN-interface 2 and enable MPLS on it.
[ASBR-PE1] interface vlan-interface 2
[ASBR-PE1-Vlan-interface2] ip address 11.0.0.2 255.0.0.0
[ASBR-PE1-Vlan-interface2] mpls
[ASBR-PE1-Vlan-interface2] quit
# Configure interface Loopback 0 and start IS-IS on it.
[ASBR-PE1] interface loopback 0
[ASBR-PE1-LoopBack0] ip address 3.3.3.9 32
[ASBR-PE1-LoopBack0] isis enable 1
[ASBR-PE1-LoopBack0] quit
# Create routing policies.
[ASBR-PE1] route-policy policy1 permit node 1
[ASBR-PE1-route-policy1] apply mpls-label
[ASBR-PE1-route-policy1] quit
[ASBR-PE1] route-policy policy2 permit node 1
[ASBR-PE1-route-policy2] if-match mpls-label
[ASBR-PE1-route-policy2] apply mpls-label
[ASBR-PE1-route-policy2] quit
# Start BGP on ASBR-PE 1 and specify to inject routes of IS-IS process 1.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] import-route isis 1
# Specify to use routing policy policy2 to filter routes advertised from IBGP peer 2.2.2.9.
[ASBR-PE1-bgp] peer 2.2.2.9 as-number 100
[ASBR-PE1-bgp] peer 2.2.2.9 route-policy policy2 export
# Configure the capability to advertise labeled routes to IBGP peer 2.2.2.9 and to receive labeled routes from the peer.
[ASBR-PE1-bgp] peer 2.2.2.9 connect-interface loopback 0
[ASBR-PE1-bgp] peer 2.2.2.9 label-route-capability
# Specify to use routing policy policy1 to filter routes advertised from EBGP peer 11.0.0.1.
[ASBR-PE1-bgp] peer 11.0.0.1 as-number 600
[ASBR-PE1-bgp] peer 11.0.0.1 route-policy policy1 export
# Configure the capability to advertise labeled routes to EBGP peer 11.0.0.1 and to receive labeled routes from the peer.
[ASBR-PE1-bgp] peer 11.0.0.1 label-route-capability
[ASBR-PE1-bgp] quit
3) Configure ASBR-PE 2
# Start IS-IS on ASBR-PE 2.
<ASBR-PE2> system-view
[ASBR-PE2] isis 1
[ASBR-PE2-isis-1] network-entity 10.222.222.222.222.00
[ASBR-PE2-isis-1] quit
# Configure LSR ID, enable MPLS and LDP.
[ASBR-PE2] mpls lsr-id 4.4.4.9
[ASBR-PE2] mpls
[ASBR-PE2-mpls] label advertise non-null
[ASBR-PE2-mpls] quit
[ASBR-PE2] mpls ldp
[ASBR-PE2-mpls-ldp] quit
# Configure interface VLAN-interface 1, start IS-IS and enable MPLS and LDP on the interface.
[ASBR-PE2] interface vlan-interface 1
[ASBR-PE2-Vlan-interface1] ip address 9.1.1.1 255.0.0.0
[ASBR-PE2-Vlan-interface1] isis enable 1
[ASBR-PE2-Vlan-interface1] mpls
[ASBR-PE2-Vlan-interface1] mpls ldp
[ASBR-PE2-Vlan-interface1] quit
# Configure interface Loopback 0 and start IS-IS on it.
[ASBR-PE2] interface loopback 0
[ASBR-PE2-LoopBack0] ip address 4.4.4.9 32
[ASBR-PE2-LoopBack0] isis enable 1
[ASBR-PE2-LoopBack0] quit
# Configure interface VLAN-interface 2 and enable MPLS on it.
[ASBR-PE2] interface vlan-interface 2
[ASBR-PE2-Vlan-interface2] ip address 11.0.0.1 255.0.0.0
[ASBR-PE2-Vlan-interface2] mpls
[ASBR-PE2-Vlan-interface2] quit
# Create routing policies.
[ASBR-PE2] route-policy policy1 permit node 1
New Sequence of this List
[ASBR-PE2-route-policy1] apply mpls-label
[ASBR-PE2-route-policy1] quit
[ASBR-PE2] route-policy policy2 permit node 1
[ASBR-PE2-route-policy2] if-match mpls-label
[ASBR-PE2-route-policy2] apply mpls-label
[ASBR-PE2-route-policy2] quit
# Start BGP on ASBR-PE 2 and specify to inject routes of IS-IS process 1.
[ASBR-PE2] bgp 600
[ASBR-PE2-bgp] import-route isis 1
# Configure the capability to advertise labeled routes to IBGP peer 5.5.5.9 and to receive labeled routes from the peer.
[ASBR-PE2-bgp] peer 5.5.5.9 as-number 600
[ASBR-PE2-bgp] peer 5.5.5.9 connect-interface loopback 1
[ASBR-PE2-bgp] peer 5.5.5.9 label-route-capability
# Specify to use routing policy policy2 to filter routes advertised from IBGP peer 5.5.5.9.
[ASBR-PE2-bgp] peer 5.5.5.9 route-policy policy2 export
# Specify to use routing policy policy1 to filter routes advertised from EBGP peer 11.0.0.2.
[ASBR-PE2-bgp] peer 11.0.0.2 as-number 100
[ASBR-PE2-bgp] peer 11.0.0.2 route-policy policy1 export
# Configure the capability to advertise labeled routes to EBGP peer 11.0.0.2 and to receive labeled routes from the peer.
[ASBR-PE2-bgp] peer 11.0.0.2 label-route-capability
[ASBR-PE2-bgp] quit
4) Configure PE 2
# Start IS-IS on PE 2.
<PE2> system-view
[PE2] isis 1
[PE2-isis-1] network-entity 10.111.111.111.111.00
[PE2-isis-1] quit
# Configure LSR ID, enable MPLS and LDP.
[PE2] mpls lsr-id 5.5.5.9
[PE2] mpls
[PE2-mpls] label advertise non-null
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
# Configure interface VLAN-interface 1, start IS-IS and enable MPLS and LDP on the interface.
[PE2] interface vlan-interface 1
[PE2-Vlan-interface1] ip address 9.1.1.2 255.0.0.0
[PE2-Vlan-interface1] isis enable 1
[PE2-Vlan-interface1] mpls
[PE2-Vlan-interface1] mpls ldp
[PE2-Vlan-interface1] quit
# Configure interface Loopback 0 and start IS-IS on it.
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 5.5.5.9 32
[PE2-LoopBack0] isis enable 1
[PE2-LoopBack0] quit
# Create VPN instance vpn1 and configure the RD and VPN target attributes.
[PE2] ip vpn-instance vpn1
[PE2-vpn-instance-vpn1] route-distinguisher 11:11
[PE2-vpn-instance-vpn1] vpn-target 1:1 2:2 3:3 import-extcommunity
[PE2-vpn-instance-vpn1] vpn-target 3:3 export-extcommunity
[PE2-vpn-instance-vpn1] quit
# Configure interface Loopback 1 and bind the interface to VPN instance vpn1.
[PE2] interface loopback 1
[PE2-LoopBack1] ip binding vpn-instance vpn1
[PE2-LoopBack1] ip address 20.0.0.1 32
[PE2-LoopBack1] quit
# Start BGP on PE 2.
[PE2] bgp 600
# Configure the capability to advertise labeled routes to IBGP peer 4.4.4.9 and to receive labeled routes from the peer.
[PE2-bgp] peer 4.4.4.9 as-number 600
[PE2-bgp] peer 4.4.4.9 connect-interface loopback 1
[PE2-bgp] peer 4.4.4.9 label-route-capability
# Configure the maximum hop count from PE 2 to EBGP peer 2.2.2.9 as 10.
[PE2-bgp] peer 2.2.2.9 as-number 100
[PE2-bgp] peer 2.2.2.9 connect-interface loopback 1
[PE2-bgp] peer 2.2.2.9 ebgp-max-hop 10
# Configure peer 2.2.2.9 as a VPNv4 peer.
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpnv4] peer 2.2.2.9 enable
[PE2-bgp-af-vpnv4] quit
# Specify to inject direct routes to the routing table of vpn1.
[PE2-bgp] ipv4-family vpn-instance vpn1
[PE2-bgp-vpn1] import-route direct
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
After you complete the above configurations, PE 1 and PE 2 should be able to ping each other:
[PE2] ping –vpn-instance vpn1 30.0.0.1
[PE1] ping –vpn-instance vpn1 20.0.0.1
Example for Configuring Carrier’s Carrier
Network requirements
The Level 2 carrier provides MPLS L3VPN services to customers.
As shown in Figure 1-21,
l PE 1 and PE 2 are PEs of the Level 1 carrier backbone.
l CE 1 and CE 2 are devices of the Level 2 carrier and work as CE to access the Level 1 carrier backbone.
l PE 3 and PE 4 are devices of the Level 2 carrier and work as PE to provide access service for the customers of the Level 2 carrier.
l CE 3 and CE 4 are customers of the Level 2 carrier.
The key of the carrier’s carrier configuration lies in the exchange process of two kinds of routes:
l The exchange of the internal Level 2 carrier VPN routes on the Level 1 carrier backbone. In this process, the Level 2 carrier accesses the Level 1 carrier backbone as CE.
l The exchange of customer VPN routes of the Level 2 carrier between PEs of the Level 2 carrier. In this process, MP-IBGP peer relationship must be established between the PEs of the Level 2 carrier (that is, between PE 3 and PE 4).
Network diagram
Figure 1-21 Configure carrier’s carrier
Interface |
IP address |
Device |
Interface |
IP address |
|
CE 3 |
Vlan-int1 |
100.1.1.1/24 |
CE 4 |
Vlan-int1 |
120.1.1.1/24 |
PE 3 |
Loop0 |
1.1.1.9/32 |
PE 4 |
Loop0 |
6.6.6.9/32 |
|
Vlan-int1 |
100.1.1.2/24 |
|
Vlan-int1 |
120.1.1.2/24 |
|
Vlan-int2 |
10.1.1.1/24 |
|
Vlan-int2 |
20.1.1.2/24 |
CE 1 |
Loop0 |
2.2.2.9/32 |
CE 2 |
Loop0 |
5.5.5.9/32 |
|
Vlan-int2 |
10.1.1.2/24 |
|
Vlan-int1 |
21.1.1.2/24 |
|
Vlan-int1 |
11.1.1.1/24 |
|
Vlan-int2 |
20.1.1.1/24 |
PE 1 |
Loop0 |
3.3.3.9/32 |
PE 2 |
Loop0 |
4.4.4.9/32 |
|
Vlan-int1 |
11.1.1.2/24 |
|
Vlan-int2 |
30.1.1.2/24 |
|
Vlan-int2 |
30.1.1.1/24 |
|
Vlan-int1 |
21.1.1.1/24 |
Configuration procedure
1) Configure MPLS L3VPN on the Level 1 carrier backbone: start IS-IS as the IGP, enable LDP between PE 1 and PE 2, and establish MP-IBGP peer relationship between the PEs
# Configure PE 1.
<PE1> system-view
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 3.3.3.9 32
[PE1-LoopBack0] quit
[PE1] mpls lsr-id 3.3.3.9
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] isis 1
[PE1-isis-1] network-entity 10.0000.0000.0000.0004.00
[PE1-isis-1] quit
[PE1] interface loopback 0
[PE1-LoopBack0] isis enable 1
[PE1-LoopBack0] quit
[PE1] interface vlan-interface 2
[PE1-Vlan-interface2] ip address 30.1.1.1 24
[PE1-Vlan-interface2] isis enable 1
[PE1-Vlan-interface2] mpls
[PE1-Vlan-interface2] mpls ldp
[PE1-Vlan-interface2] mpls ldp transport-address interface
[PE1-Vlan-interface2] quit
[PE1] bgp 100
[PE1-bgp] peer 4.4.4.9 as-number 100
[PE1-bgp] peer 4.4.4.9 connect-interface loopback 0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 4.4.4.9 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
The configurations for PE 2 are similar to those for PE 1. The detailed configuration steps are omitted.
After completing the above configurations, you should see that the LDP session has been established successfully by issuing the display mpls ldp session command on PE 1 or PE 2. Issuing the display bgp peer command, you should see that the BGP peer relationship has been established and has reached the state of Established. Issuing the display isis peer command, you should see that the IS-IS neighbor relationship has been set up. Take PE 1 as an example:
[PE1] display mpls ldp session
LDP Session(s) in Public Network
----------------------------------------------------------------
Peer-ID Status LAM SsnRole FT MD5 KA-Sent/Rcv
----------------------------------------------------------------
4.4.4.9:0 Operational DU Active Off Off 378/378
----------------------------------------------------------------
LAM : Label Advertisement Mode FT : Fault Tolerance
[PE1] display bgp peer
BGP local router ID : 3.3.3.9
Local AS number : 100
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
4.4.4.9 4 100 162 145 0 0 02:12:47 Established
[PE1] display isis peer
Peer information for ISIS(1)
----------------------------
System Id Interface Circuit Id State HoldTime Type PRI
0000.0000.0005 Vlan-interface2 001 Up 29s L1L2 --
2) Configure the Level 2 carrier network: start IS-IS as the IGP and enable LDP between PE 3 and CE 1, and between PE 4 and CE 2 respectively
# Configure PE 3.
<PE3> system-view
[PE3] interface loopback 0
[PE3-LoopBack0] ip address 1.1.1.9 32
[PE3-LoopBack0] quit
[PE3] mpls lsr-id 1.1.1.9
[PE3] mpls
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
[PE3] isis 2
[PE3-isis-2] network-entity 10.0000.0000.0000.0001.00
[PE3-isis-2] quit
[PE3] interface loopback 0
[PE3-LoopBack0] isis enable 2
[PE3-LoopBack0] quit
[PE3] interface vlan-interface 2
[PE3-Vlan-interface2] ip address 10.1.1.1 24
[PE3-Vlan-interface2] isis enable 2
[PE3-Vlan-interface2] mpls
[PE3-Vlan-interface2] mpls ldp
[PE3-Vlan-interface2] mpls ldp transport-address interface
[PE3-Vlan-interface2] quit
# Configure CE 1.
<CE1> system-view
[CE1] interface loopback 0
[CE1-LoopBack0] ip address 2.2.2.9 32
[CE1-LoopBack0] quit
[CE1] mpls lsr-id 2.2.2.9
[CE1] mpls
[CE1-mpls] quit
[CE1] mpls ldp
[CE1-mpls-ldp] quit
[CE1] isis 2
[CE1-isis-2] network-entity 10.0000.0000.0000.0002.00
[CE1-isis-2] quit
[CE1] interface loopback 0
[CE1-LoopBack0] isis enable 2
[CE1-LoopBack0] quit
[CE1] interface vlan-interface 2
[CE1-Vlan-interface2] ip address 10.1.1.2 24
[CE1-Vlan-interface2] isis enable 2
[CE1-Vlan-interface2] mpls
[CE1-Vlan-interface2] mpls ldp
[CE1-Vlan-interface2] mpls ldp transport-address interface
[CE1-Vlan-interface2] quit
After you complete the above configurations, PE 3 and CE 1 should be able to establish the LDP session and IS-IS neighbor relationship between them.
The configurations for PE 4 and CE 2 are similar to those for PE 3 and CE 1. The detailed configuration steps are omitted.
3) Perform configuration to allow CEs of the Level 2 carrier to access PEs of the Level 1 carrier
# Configure PE 1 and inject IS-IS routes.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 200:1
[PE1-vpn-instance-vpn1] vpn-target 1:1
[PE1-vpn-instance-vpn1] quit
[PE1] mpls ldp vpn-instance vpn1
[PE1-mpls-ldp-vpn-instance-vpn1] quit
[PE1] isis 2 vpn-instance vpn1
[PE1-isis-2] network-entity 10.0000.0000.0000.0003.00
[PE1-isis-2] import-route bgp
[PE1-isis-2] quit
[PE1] interface vlan-interface 1
[PE1-Vlan-interface1] ip binding vpn-instance vpn1
[PE1-Vlan-interface1] ip address 11.1.1.2 24
[PE1-Vlan-interface1] isis enable 2
[PE1-Vlan-interface1] mpls
[PE1-Vlan-interface1] mpls ldp
[PE1-Vlan-interface1] mpls ldp transport-address interface
[PE1-Vlan-interface1] quit
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] import isis 2
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure CE 1.
[CE1] interface vlan-interface 1
[CE1-Vlan-interface1] ip address 11.1.1.1 24
[CE1-Vlan-interface1] isis enable 2
[CE1-Vlan-interface1] mpls
[CE1-Vlan-interface1] mpls ldp
[CE1-Vlan-interface1] mpls ldp transport-address interface
[CE1-Vlan-interface1] quit
After you complete the above configurations, PE 1 and CE 1 should be able to establish the LDP session and IS-IS neighbor relationship between them.
The configurations for PE 2 and CE 2 are similar to those for PE 1 and CE 1. The detailed configuration steps are omitted.
4) Perform configuration to allow the CEs of the Level 2 carrier to access the PEs
# Configure CE 3.
<CE3> system-view
[CE3] interface vlan-interface 1
[CE3-Vlan-interface1] ip address 100.1.1.1 24
[CE3-Vlan-interface1] quit
[CE3] bgp 65410
[CE3-bgp] peer 100.1.1.2 as-number 100
[CE3-bgp] import-route direct
[CE3-bgp] quit
# Configure PE 3.
[PE3] ip vpn-instance vpn1
[PE3-vpn-instance-vpn1] route-distinguisher 100:1
[PE3-vpn-instance-vpn1] vpn-target 1:1
[PE3-vpn-instance-vpn1] quit
[PE3] interface vlan-interface 1
[PE3-Vlan-interface1] ip binding vpn-instance vpn1
[PE3-Vlan-interface1] ip address 100.1.1.2 24
[PE3-Vlan-interface1] quit
[PE3] bgp 100
[PE3-bgp] ipv4-family vpn-instance vpn1
[PE3-bgp-vpn1] peer 100.1.1.1 as-number 65410
[PE3-bgp-vpn1] import-route direct
[PE3-bgp-vpn1] quit
[PE3-bgp] quit
The configurations for PE 4 and CE 4 are similar to those for PE 3 and CE 3. The detailed configuration steps are omitted.
5) Configure MP-IBGP peer relationship between PEs of the Level 2 carrier to exchange the VPN routes of the Level 2 carrier customers
# Configure PE 3.
[PE3] bgp 100
[PE3-bgp] peer 6.6.6.9 as-number 100
[PE3-bgp] peer 6.6.6.9 connect-interface loopback 0
[PE3-bgp] ipv4-family vpnv4
[PE3-bgp-af-vpnv4] peer 6.6.6.9 enable
[PE3-bgp-af-vpnv4] quit
[PE3-bgp] quit
The configurations for PE 4 are similar to those for PE 3. The detailed configuration steps are omitted.
6) Verify your configurations
After completing all the above configurations, you can issue the display ip routing-table command on PE 1 and PE 2. You should see that only routes of the Level 1 carrier network are present in the public network routing table of PE 1 and PE 2. Takes PE 1 as an example:
[PE1] display ip routing-table
Routing Tables: Public
Destinations : 7 Routes : 7
Destination/Mask Proto Pre Cost NextHop Interface
3.3.3.9/32 Direct 0 0 127.0.0.1 InLoop0
4.4.4.9/32 ISIS 15 10 30.1.1.2 Vlan2
30.1.1.0/24 Direct 0 0 30.1.1.1 Vlan2
30.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
30.1.1.2/32 Direct 0 0 30.1.1.2 Vlan2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
Issuing the display ip routing-table vpn-instance command on PE 1 and PE 2, you should see that the internal routes of the Level 2 carrier network are present in the VPN routing tables, but the VPN routes that the Level 2 carrier maintains are not. Takes PE 1 as an example:
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 11 Routes : 11
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.9/32 ISIS 15 20 11.1.1.1 Vlan1
2.2.2.9/32 ISIS 15 10 11.1.1.1 Vlan1
5.5.5.9/32 BGP 255 0 4.4.4.9 NULL0
6.6.6.9/32 BGP 255 0 4.4.4.9 NULL0
10.1.1.0/24 ISIS 15 20 11.1.1.1 Vlan1
11.1.1.0/24 Direct 0 0 11.1.1.1 Vlan1
11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.2/32 Direct 0 0 11.1.1.2 Vlan1
20.1.1.0/24 BGP 255 0 4.4.4.9 NULL0
21.1.1.0/24 BGP 255 0 4.4.4.9 NULL0
21.1.1.2/32 BGP 255 0 4.4.4.9 NULL0
Issuing the display ip routing-table command on CE 1 and CE 2, you should see that the internal routes of the Level 2 carrier network are present in the public network routing tables, but the VPN routes that the Level 2 carrier maintains are not. Takes CE 1 as an example:
[CE1] display ip routing-table
Routing Tables: Public
Destinations : 16 Routes : 16
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.9/32 ISIS 15 10 10.1.1.2 Vlan2
2.2.2.9/32 Direct 0 0 127.0.0.1 InLoop0
5.5.5.9/32 ISIS 15 74 11.1.1.2 Vlan1
6.6.6.9/32 ISIS 15 74 11.1.1.2 Vlan1
10.1.1.0/24 Direct 0 0 10.1.1.2 Vlan2
10.1.1.1/32 Direct 0 0 10.1.1.1 Vlan2
10.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.0/24 Direct 0 0 11.1.1.1 Vlan1
11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.2/32 Direct 0 0 11.1.1.2 Vlan1
20.1.1.0/24 ISIS 15 74 11.1.1.2 Vlan1
21.1.1.0/24 ISIS 15 74 11.1.1.2 Vlan1
21.1.1.2/32 ISIS 15 74 11.1.1.2 Vlan1
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
Issuing the display ip routing-table command on PE 3 and PE 4, you should see that the internal routes of the Level 2 carrier network are present in the public network routing tables. Takes PE 3 as an example:
[PE3] display ip routing-table
Routing Tables: Public
Destinations : 11 Routes : 11
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0
2.2.2.9/32 ISIS 15 10 10.1.1.2 Vlan2
5.5.5.9/32 ISIS 15 84 10.1.1.2 Vlan2
6.6.6.9/32 ISIS 15 84 10.1.1.2 Vlan2
10.1.1.0/24 Direct 0 0 10.1.1.1 Vlan2
10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.1.1.2/32 Direct 0 0 10.1.1.2 Vlan2
11.1.1.0/24 ISIS 15 20 10.1.1.2 Vlan2
20.1.1.0/24 ISIS 15 84 10.1.1.2 Vlan2
21.1.1.0/24 ISIS 15 84 10.1.1.2 Vlan2
21.1.1.2/32 ISIS 15 84 10.1.1.2 Vlan2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
Issuing the display ip routing-table vpn-instance command on PE 3 and PE 4, you should see that the routes of the remote VPN customers are present in the VPN routing tables. Takes PE 3 as an example:
[PE3] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 3 Routes : 3
Destination/Mask Proto Pre Cost NextHop Interface
100.1.1.0/24 Direct 0 0 100.1.1.2 Vlan1
100.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
120.1.1.0/24 BGP 255 0 6.6.6.9 NULL0
PE 3 and PE 4 should be able to ping each other:
[PE3] ping 20.1.1.2
PING 20.1.1.2: 56 data bytes, press CTRL_C to break
Reply from 20.1.1.2: bytes=56 Sequence=1 ttl=252 time=127 ms
Reply from 20.1.1.2: bytes=56 Sequence=2 ttl=252 time=97 ms
Reply from 20.1.1.2: bytes=56 Sequence=3 ttl=252 time=83 ms
Reply from 20.1.1.2: bytes=56 Sequence=4 ttl=252 time=70 ms
Reply from 20.1.1.2: bytes=56 Sequence=5 ttl=252 time=60 ms
--- 20.1.1.2 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 60/87/127 ms
CE 3 and CE 4 should be able to ping each other:
[CE3] ping 120.1.1.1
PING 120.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 120.1.1.1: bytes=56 Sequence=1 ttl=252 time=102 ms
Reply from 120.1.1.1: bytes=56 Sequence=2 ttl=252 time=69 ms
Reply from 120.1.1.1: bytes=56 Sequence=3 ttl=252 time=105 ms
Reply from 120.1.1.1: bytes=56 Sequence=4 ttl=252 time=88 ms
Reply from 120.1.1.1: bytes=56 Sequence=5 ttl=252 time=87 ms
--- 120.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 69/90/105 ms
Example for Configuring Nested VPN
Network requirements
The service provider provides nested VPN services for users, as shown in Figure 1-22, where:
l PE 1 and PE 2 are PE devices on the service provider backbone. Both of them support the nested VPN function.
l CE 1 and CE 2 are connected to the service provider backbone. Both of them support VPNv4 routes.
l PE 3 and PE 4 are PE devices of the customer VPN. Both of them support MPLS L3VPN.
l CE 3 through CE 6 are CE devices of the sub-VPNs for the customer VPN.
The key of nested VPN configuration is to understand the processing of routes of sub-VPNs on the service provider PEs, which is described as follows:
l When receiving a VPNv4 route from a CE (CE 1 or CE 2 in this example), a service provider PE replaces the RD of the VPNv4 route with the RD of the MPLS VPN on the service provider network where the CE resides, adds the export target attribute of the MPLS VPN on the service provider network to the extended community attribute list, and then forwards the VPNv4 route as usual.
l To implement exchange of sub-VPN routes between customer PEs and service provider PEs, MP-EBGP peers should be established between service provider PEs and customer CEs.
Network diagram
Figure 1-22 Configure nested VPN
Device |
Interface |
IP address |
Device |
Interface |
IP address |
CE 1 |
Loop0 |
2.2.2.9/32 |
CE 2 |
Loop0 |
5.5.5.9/32 |
|
Vlan-int2 |
10.1.1.2/24 |
|
Vlan-int1 |
21.1.1.2/24 |
|
Vlan-int1 |
11.1.1.1/24 |
|
Vlan-int2 |
20.1.1.1/24 |
CE 3 |
Vlan-int1 |
100.1.1.1/24 |
CE 4 |
Vlan-int1 |
120.1.1.1/24 |
CE 5 |
Vlan-int3 |
110.1.1.1/24 |
CE 6 |
Vlan-int3 |
130.1.1.1/24 |
PE 1 |
Loop0 |
3.3.3.9/32 |
PE 2 |
Loop0 |
4.4.4.9/32 |
|
Vlan-int1 |
11.1.1.2/24 |
|
Vlan-int1 |
21.1.1.1/24 |
|
Vlan-int2 |
30.1.1.1/24 |
|
Vlan-int2 |
30.1.1.2/24 |
PE 3 |
Loop0 |
1.1.1.9/32 |
PE 4 |
Loop0 |
6.6.6.9/32 |
|
Vlan-int1 |
100.1.1.2/24 |
|
Vlan-int1 |
120.1.1.2/24 |
|
Vlan-int2 |
10.1.1.1/24 |
|
Vlan-int2 |
20.1.1.2/24 |
|
Vlan-int3 |
110.1.1.2/24 |
|
Vlan-int3 |
130.1.1.2/24 |
Configuration procedure
1) Configure MPLS L3VPN on the service provider backbone, using IS-IS as the IGP protocol, and enabling LDP and establishing MP-IBGP peer relationship between PE 1 and PE 2.
# Configure PE 1.
<PE1> system-view
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 3.3.3.9 32
[PE1-LoopBack0] quit
[PE1] mpls lsr-id 3.3.3.9
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] isis 1
[PE1-isis-1] network-entity 10.0000.0000.0000.0004.00
[PE1-isis-1] quit
[PE1] interface loopback 0
[PE1-LoopBack0] isis enable 1
[PE1-LoopBack0] quit
[PE1] interface vlan-interface 2
[PE1-Vlan-interface2] ip address 30.1.1.1 24
[PE1-Vlan-interface2] isis enable 1
[PE1-Vlan-interface2] mpls
[PE1-Vlan-interface2] mpls ldp
[PE1-Vlan-interface2] quit
[PE1] bgp 100
[PE1-bgp] peer 4.4.4.9 as-number 100
[PE1-bgp] peer 4.4.4.9 connect-interface loopback 0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 4.4.4.9 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
Configurations on PE 2 are similar to those on PE 1, and are thus omitted here.
After completing the configurations above, you can execute commands display mpls ldp session, display bgp peer and display isis peer respectively on either PE 1 or PE 2. You should see that the LDP session is established, the BGP peer relationship is established and in the Established state, and the IS-IS neighbor relationship is established and up.
The following takes PE 1 for illustration.
[PE1] display mpls ldp session
LDP Session(s) in Public Network
----------------------------------------------------------------
Peer-ID Status LAM SsnRole FT MD5 KA-Sent/Rcv
----------------------------------------------------------------
4.4.4.9:0 Operational DU Active Off Off 378/378
----------------------------------------------------------------
LAM : Label Advertisement Mode FT : Fault Tolerance
[PE1] display bgp peer
BGP local router ID : 3.3.3.9
Local AS number : 100
Total number of peers : 1 Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
4.4.4.9 4 100 162 145 0 0 02:12:47 Established
[PE1] display isis peer
Peer information for ISIS(1)
----------------------------
System Id Interface Circuit Id State HoldTime Type PRI
0000.0000.0005 Vlan-interface2 001 Up 29s L1L2 --
2) Configure the customer VPN, using IS-IS as the IGP protocol and enabling LDP between PE 3 and CE 1, and between PE 4 and CE 2.
# Configure PE 3.
<PE3> system-view
[PE3] interface loopback 0
[PE3-LoopBack0] ip address 1.1.1.9 32
[PE3-LoopBack0] quit
[PE3] mpls lsr-id 1.1.1.9
[PE3] mpls
[PE3-mpls] quit
[PE3] mpls ldp
[PE3-mpls-ldp] quit
[PE3] isis 2
[PE3-isis-2] network-entity 10.0000.0000.0000.0001.00
[PE3-isis-2] quit
[PE3] interface loopback 0
[PE3-LoopBack0] isis enable 2
[PE3-LoopBack0] quit
[PE3-Vlan-interface2] ip address 10.1.1.1 24
[PE3-Vlan-interface2] isis enable 2
[PE3-Vlan-interface2] mpls
[PE3-Vlan-interface2] mpls ldp
[PE3-Vlan-interface2] quit
# Configure CE 1.
<CE1> system-view
[CE1] interface loopback 0
[CE1-LoopBack0] ip address 2.2.2.9 32
[CE1-LoopBack0] quit
[CE1] mpls lsr-id 2.2.2.9
[CE1] mpls
[CE1-mpls] quit
[CE1] mpls ldp
[CE1-mpls-ldp] quit
[CE1] isis 2
[CE1-isis-2] network-entity 10.0000.0000.0000.0002.00
[CE1-isis-2] quit
[CE1] interface loopback 0
[CE1-LoopBack0] isis enable 2
[CE1-LoopBack0] quit
[CE1] interface vlan-interface 2
[CE1-Vlan-interface2] ip address 10.1.1.2 24
[CE1-Vlan-interface2] isis enable 2
[CE1-Vlan-interface2] mpls
[CE1-Vlan-interface2] mpls ldp
[CE1-Vlan-interface2] quit
After the configurations above, LDP and IS-IS neighbor relationship can be established between PE 3 and CE 1.
Configurations on PE 4 and CE 2 are similar to those on PE 3 and CE 1 respectively, and are thus omitted here.
3) Connect CE 1 and CE 2 to service provider PEs.
# Configure PE 1.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 200:1
[PE1-vpn-instance-vpn1] vpn-target 1:1
[PE1-vpn-instance-vpn1] quit
[PE1] interface vlan-interface1
[PE1-Vlan-interface1] ip binding vpn-instance vpn1
[PE1-Vlan-interface1] ip address 11.1.1.2 24
[PE1-Vlan-interface1] mpls
[PE1-Vlan-interface1] quit
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] peer 11.1.1.1 as-number 200
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure CE 1.
[CE1] interface vlan-interface 1
[CE1-Vlan-interface1] ip address 11.1.1.1 24
[CE1-Vlan-interface1] mpls
[CE1-Vlan-interface1] quit
[CE1] bgp 200
[CE1-bgp] peer 11.1.1.2 as-number 100
[CE1-bgp] import isis 2
[CE1-bgp] quit
Configurations on PE 2 and CE 2 are similar to those on PE 1 and CE 1 respectively, and are thus omitted here.
4) Connect sub-VPN CEs to the customer VPN PEs
# Configure CE 3.
<CE3> system-view
[CE3] interface vlan-interface1
[CE3-Vlan-interface1] ip address 100.1.1.1 24
[CE3-Vlan-interface1] quit
[CE3] bgp 65410
[CE3-bgp] peer 100.1.1.2 as-number 200
[CE3-bgp] import-route direct
[CE3-bgp] quit
# Configure CE5.
<CE5> system-view
[CE5] interface vlan-interface 3
[CE5-Vlan-interface3] ip address 110.1.1.1 24
[CE5-Vlan-interface3] quit
[CE5] bgp 65411
[CE5-bgp] peer 110.1.1.2 as-number 200
[CE5-bgp] import-route direct
[CE5-bgp] quit
# Configure PE 3.
[PE3] ip vpn-instance SUB_VPN1
[PE3-vpn-instance-SUB_VPN1] route-distinguisher 100:1
[PE3-vpn-instance-SUB_VPN1] vpn-target 2:1
[PE3-vpn-instance-SUB_VPN1] quit
[PE3] interface vlan-interface 1
[PE3-Vlan-interface1] ip binding vpn-instance SUB_VPN1
[PE3-Vlan-interface1] ip address 100.1.1.2 24
[PE3-Vlan-interface1] quit
[PE3] ip vpn-instance SUB_VPN2
[PE3-vpn-instance-SUB_VPN2] route-distinguisher 101:1
[PE3-vpn-instance-SUB_VPN2] vpn-target 2:2
[PE3-vpn-instance-SUB_VPN2] quit
[PE3] interface vlan-interface 3
[PE3-Vlan-interface3] ip binding vpn-instance SUB_VPN2
[PE3-Vlan-interface3] ip address 110.1.1.2 24
[PE3-Vlan-interface3] quit
[PE3] bgp 200
[PE3-bgp] ipv4-family vpn-instance SUB_VPN1
[PE3-bgp-SUB_VPN1] peer 100.1.1.1 as-number 65410
[PE3-bgp-SUB_VPN1] import-route direct
[PE3-bgp-SUB_VPN1] quit
[PE3-bgp] ipv4-family vpn-instance SUB_VPN2
[PE3-bgp-SUB_VPN2] peer 100.1.1.1 as-number 65411
[PE3-bgp-SUB_VPN2] import-route direct
[PE3-bgp-SUB_VPN2] quit
[PE3-bgp] quit
Configurations on PE 4, CE 4 and CE6 are similar to those on PE 3, CE 3 and CE5 respectively, and are thus omitted here.
5) Establish MP-EBGP peer relationship between service provider PEs and their CEs to exchange user VPNv4 routes.
# Configure PE 1, enabling nested VPN.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] nesting-vpn
[PE1-bgp-af-vpnv4] peer 11.1.1.1 vpn-instance vpn1 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
# Configure CE 1, enabling VPNv4 capability and establishing VPNv4 neighbor relationship between CE 1 and PE 1.
[CE1] bgp 200
[CE1-bgp] ipv4-family vpnv4
[CE1-bgp-af-vpnv4] peer 11.1.1.2 enable
# Specify to allow the local AS number to appear in the AS-PATH attribute of the routes received.
[CE1-bgp-af-vpnv4] peer 11.1.1.2 allow-as-loop 2
# Specify to receive all VPNv4 routes.
[CE1-bgp-af-vpnv4] undo policy vpn-target
[CE1-bgp-af-vpnv4] quit
[CE1-bgp] quit
Configurations on PE 2 and CE 2 are similar to those on PE 1 and CE 1 respectively, and are thus omitted here.
6) Establish MP-IBGP peer relationship between sub-VPN PEs and CEs of the customer VPN to exchange VPNv4 routes of sub-VPNs.
# Configure PE 3.
[PE3] bgp 200
[PE3-bgp] peer 2.2.2.9 as-number 200
[PE3-bgp] peer 2.2.2.9 connect-interface loopback 0
[PE3-bgp] ipv4-family vpnv4
[PE3-bgp-af-vpnv4] peer 2.2.2.9 enable
# Specify to allow the local AS number to appear in the AS-PATH attribute of the routes received.
[PE3-bgp-af-vpnv4] peer 2.2.2.9 allow-as-loop 2
[PE3-bgp-af-vpnv4] quit
[PE3-bgp] quit
# Configure CE 1.
[CE1] bgp 200
[CE1-bgp] peer 1.1.1.9 as-number 200
[CE1-bgp] peer 1.1.1.9 connect-interface loopback 0
[CE1-bgp] ipv4-family vpnv4
[CE1-bgp-af-vpnv4] peer 1.1.1.9 enable
[CE1-bgp-af-vpnv4] undo policy vpn-target
[CE1-bgp-af-vpnv4] quit
[CE1-bgp] quit
Configurations on PE 4 and CE 2 are similar to those on PE 3 and CE 1 respectively, and are thus omitted here.
7) Verify the configurations.
After completing all the configurations above, execute the display ip routing-table comand on PE 1 and PE 2 to verify that the public routing tables contain only routes on the service provider network. The following takes PE 1 for illustration.
[PE1] display ip routing-table
Routing Tables: Public
Destinations : 7 Routes : 7
Destination/Mask Proto Pre Cost NextHop Interface
3.3.3.9/32 Direct 0 0 127.0.0.1 InLoop0
4.4.4.9/32 ISIS 15 10 30.1.1.2 Vlan2
30.1.1.0/24 Direct 0 0 30.1.1.1 Vlan2
30.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
30.1.1.2/32 Direct 0 0 30.1.1.2 Vlan2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
Execute the display ip routing-table vpn-instance command on PE 1 and PE 2 to verify that the VPN routing tables contain sub-VPN routes. The following takes PE 1 for illustration.
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
11.1.1.0/24 Direct 0 0 11.1.1.1 Vlan1
11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
11.1.1.2/32 Direct 0 0 11.1.1.2 Vlan1
100.1.1.0/24 BGP 255 0 11.1.1.1 NULL0
110.1.1.0/24 BGP 255 0 11.1.1.1 NULL0
120.1.1.0/24 BGP 255 0 4.4.4.9 NULL0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
130.1.1.0/24 BGP 255 0 4.4.4.9 NULL0
Execute the display bgp vpnv4 all routing-table command on CE 1 and CE 2 to verify that the VPNv4 routing tables on the customer VPN contain internal sub-VPN routes. The following takes CE 1 for illustration.
[CE1] display bgp vpnv4 all routing-table
BGP Local router ID is 11.11.11.11
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 4
Route Distinguisher: 100:1
Network NextHop In/Out Label MED LocPrf
*> 100.1.1.0/24 1.1.1.9 1024/1024
Route Distinguisher: 101:1
Network NextHop In/Out Label MED LocPrf
*> 110.1.1.0/24 1.1.1.9 1025/1025
Route Distinguisher: 200:1
Network NextHop In/Out Label MED LocPrf
*> 120.1.1.0/24 11.1.1.2 1026/1027
Route Distinguisher: 201:1
Network NextHop In/Out Label MED LocPrf
*> 130.1.1.0/24 11.1.1.2 1027/1028
Execute the display ip routing-table vpn-instance SUB_VPN1 command on PE 3 and PE 4 to verify that the VPN routing tables contain routes sent by the provider PE to user sub-VPN. The following takes PE 3 for illustration.
[PE3] display ip routing-table vpn-instance SUB_VPN1
Routing Tables: SUB_VPN1
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
100.1.1.0/24 Direct 0 0 100.1.1.2 Vlan1
100.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
120.1.1.0/24 BGP 255 0 2.2.2.9 NULL0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
Execute the display ip routing-table command on CE 3 and CE 4 to verify that the routing tables contain routes of remote sub-VPNs. The following takes CE 3 for illustration.
[CE3] display ip routing-table
Routing Tables: Public
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
100.1.1.0/24 Direct 0 0 100.1.1.1 Vlan1
100.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
120.1.1.0/24 BGP 255 0 100.1.1.2 Vlan1
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
Execute the display ip routing-table command on CE5 and CE6 to verify that the routing tables contain routes of remote sub-VPNs. The following takes CE5 for illustration.
[CE5] display ip routing-table
Routing Tables: Public
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
110.1.1.0/24 Direct 0 0 110.1.1.1 Vlan1
110.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
130.1.1.0/24 BGP 255 0 110.1.1.2 Vlan1
CE 3 and CE 4 can ping each other successfully.
[CE3] ping 120.1.1.1
PING 120.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 120.1.1.1: bytes=56 Sequence=1 ttl=252 time=102 ms
Reply from 120.1.1.1: bytes=56 Sequence=2 ttl=252 time=69 ms
Reply from 120.1.1.1: bytes=56 Sequence=3 ttl=252 time=105 ms
Reply from 120.1.1.1: bytes=56 Sequence=4 ttl=252 time=88 ms
Reply from 120.1.1.1: bytes=56 Sequence=5 ttl=252 time=87 ms
--- 120.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 69/90/105 ms
CE5 and CE6 can ping each other successfully.
[CE5] ping 130.1.1.1
PING 130.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 130.1.1.1: bytes=56 Sequence=1 ttl=252 time=102 ms
Reply from 130.1.1.1: bytes=56 Sequence=2 ttl=252 time=69 ms
Reply from 130.1.1.1: bytes=56 Sequence=3 ttl=252 time=105 ms
Reply from 130.1.1.1: bytes=56 Sequence=4 ttl=252 time=88 ms
Reply from 130.1.1.1: bytes=56 Sequence=5 ttl=252 time=87 ms
--- 130.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 69/90/105 ms
CE 3 and CE6 cannot ping each other.
[CE3] ping 130.1.1.1
PING 130.1.1.1: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 130.1.1.1 ping statistics ---
5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
Example for Configuring OSPF Sham Links
Network requirements
l CE 1 and CE 2 belong to VPN 1 and are respectively connected to PE 1 and PE 2.
l CE 1 and CE 2 are in the same OSPF area.
l VPN traffic between CE 1 and CE 2 is required to be forwarded through the MPLS backbone, instead of any route in the OSPF area.
Network diagram
Figure 1-23 Configure an OSPF sham link
Interface |
IP address |
Device |
Interface |
IP address |
|
CE 1 |
Vlan-int1 |
100.1.1.1/24 |
CE 2 |
Vlan-int1 |
120.1.1.1/24 |
|
Vlan-int2 |
20.1.1.1/24 |
|
Vlan-int2 |
30.1.1.2/24 |
PE 1 |
Loop0 |
1.1.1.9/32 |
PE 2 |
Loop0 |
2.2.2.9/32 |
|
Loop1 |
3.3.3.3/32 |
|
Loop1 |
5.5.5.5/32 |
|
Vlan-int1 |
100.1.1.2/24 |
|
Vlan-int1 |
120.1.1.2/24 |
|
Vlan-int2 |
10.1.1.1/24 |
|
Vlan-int2 |
10.1.1.2/24 |
Switch A |
Vlan-int1 |
20.1.1.2/24 |
|
|
|
|
Vlan-int2 |
30.1.1.1/24 |
|
|
|
Configuration procedure
1) Configure OSPF on the customer networks
Configure conventional OSPF on CE 1, Switch A, and CE 2 to advertise segment addresses of the interfaces as shown in Figure 1-23. The detailed configuration steps are omitted.
After completing the configurations, CE 1 and CE 2 should be able to learn the OSPF route to the VLAN interface 1 of each other. The following takes CE 1 as an example:
<CE1> display ip routing-table
Routing Tables: Public
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
20.1.1.0/24 Direct 0 0 20.1.1.1 Vlan2
20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
20.1.1.2/32 Direct 0 0 20.1.1.2 Vlan2
30.1.1.0/24 OSPF 10 3124 20.1.1.2 Vlan2
100.1.1.0/24 Direct 0 0 100.1.1.1 Vlan1
100.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
120.1.1.0/24 OSPF 10 3125 20.1.1.2 Vlan2
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
2) Configure MPLS L3VPN on the backbone
# Configure MPLS basic capability and MPLS LDP on PE 1 to establish LDP LSPs.
<PE1> system-view
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 1.1.1.9 32
[PE1-LoopBack0] quit
[PE1] mpls lsr-id 1.1.1.9
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] interface vlan-interface 2
[PE1-Vlan-interface2] ip address 10.1.1.1 24
[PE1-Vlan-interface2] mpls
[PE1-Vlan-interface2] mpls ldp
[PE1-Vlan-interface2] quit
# Configure PE 1 to take PE 2 as the MP-IBGP peer.
[PE1] bgp 100
[PE1-bgp] peer 2.2.2.9 as-number 100
[PE1-bgp] peer 2.2.2.9 connect-interface loopback 0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
# Configure OSPF on PE 1.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Configure MPLS basic capability and MPLS LDP on PE 2 to establish LDP LSPs.
<PE2> system-view
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 2.2.2.9 32
[PE2-LoopBack0] quit
[PE2] mpls lsr-id 2.2.2.9
[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
[PE2] interface vlan-interface 2
[PE2-Vlan-interface2] ip address 10.1.1.2 24
[PE2-Vlan-interface2] mpls
[PE2-Vlan-interface2] mpls ldp
[PE2-Vlan-interface2] quit
# Configure PE 2 to take PE 1 as the MP-IBGP peer.
[PE2] bgp 100
[PE2-bgp] peer 1.1.1.9 as-number 100
[PE2-bgp] peer 1.1.1.9 connect-interface loopback 0
[PE2-bgp] ipv4-family vpnv4
[PE2-bgp-af-vpnv4] peer 1.1.1.9 enable
[PE2-bgp-af-vpnv4] quit
[PE2-bgp] quit
# Configure OSPF on PE 2.
[PE2]ospf 1
[PE2-ospf-1]area 0
[PE2-ospf-1-area-0.0.0.0]network 2.2.2.9 0.0.0.0
[PE2-ospf-1-area-0.0.0.0]network 10.1.1.0 0.0.0.255
[PE2-ospf-1-area-0.0.0.0]quit
[PE2-ospf-1]quit
3) Configure PEs to allow CEs to access the network
# Configure PE 1 to allow CE 1 to access the network.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 100:1
[PE1-vpn-instance-vpn1] vpn-target 1:1
[PE1-vpn-instance-vpn1] quit
[PE1] interface vlan-interface 1
[PE1-Vlan-interface1] ip binding vpn-instance vpn1
[PE1-Vlan-interface1] ip address 100.1.1.2 24
[PE1-Vlan-interface1] quit
[PE1] ospf 100 vpn-instance vpn1
[PE1-ospf-100] domain-id 10
[PE1-ospf-100] area 1
[PE1-ospf-100-area-0.0.0.1] network 100.1.1.0 0.0.0.255
[PE1-ospf-100-area-0.0.0.1] quit
[PE1-ospf-100] quit
[PE2] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] import-route ospf 100
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# Configure PE 2 to allow CE 2 to access the network.
[PE2] ip vpn-instance vpn1
[PE2-vpn-instance-vpn1] route-distinguisher 100:2
[PE2-vpn-instance-vpn1] vpn-target 1:1
[PE2-vpn-instance-vpn1] quit
[PE2] interface vlan-interface 1
[PE2-Vlan-interface1] ip binding vpn-instance vpn1
[PE2-Vlan-interface1] ip address 120.1.1.2 24
[PE2-Vlan-interface1] quit
[PE2] ospf 100 vpn-instance vpn1
[PE2-ospf-100] domain-id 10
[PE2-ospf-100] area 1
[PE2-ospf-100-area-0.0.0.1] network 120.1.1.0 0.0.0.255
[PE2-ospf-100-area-0.0.0.1] quit
[PE2-ospf-100] quit
[PE2] bgp 100
[PE2-bgp] ipv4-family vpn-instance vpn1
[PE2-bgp-vpn1] import-route ospf 100
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
After completing the above configurations, if you issue the display ip routing-table vpn-instance command on the PEs, you should see that the path to the peer CE is along the OSPF route across the customer networks, instead of the BGP route across the backbone. Take PE 1 as an example:
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost NextHop Interface
20.1.1.0/24 OSPF 10 1563 100.1.1.1 Vlan1
30.1.1.0/24 OSPF 10 3125 100.1.1.1 Vlan1
100.1.1.0/24 Direct 0 0 100.1.1.2 Vlan1
100.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
120.1.1.0/24 OSPF 10 3126 100.1.1.1 Vlan1
4) Configure a sham link
# Configure PE 1.
[PE1] interface loopback 1
[PE1-LoopBack1] ip binding vpn-instance vpn1
[PE1-LoopBack1] ip address 3.3.3.3 32
[PE1-LoopBack1] quit
[PE1] ospf 100
[PE1-ospf-100] area 1
[PE1-ospf-100-area-0.0.0.1] sham-link 3.3.3.3 5.5.5.5 cost 10
[PE1-ospf-100-area-0.0.0.1] quit
[PE1-ospf-100] quit
# Configure PE 2.
[PE2] interface loopback 1
[PE2-LoopBack1] ip binding vpn-instance vpn1
[PE2-LoopBack1] ip address 5.5.5.5 32
[PE2-LoopBack1] quit
[PE2] ospf 100
[PE2-ospf-100] area 1
[PE2-ospf-100-area-0.0.0.1] sham-link 5.5.5.5 3.3.3.3 cost 10
[PE2-ospf-100-area-0.0.0.1] quit
[PE2-ospf-100] quit
After completing the above configurations, if you issue the display ip routing-table vpn-instance command again on the PEs, you should see that the path to the peer CE is now along the BGP route across the backbone, and that a route to the sham link destination address is present. Take PE 1 as an example:
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 6 Routes : 6
Destination/Mask Proto Pre Cost NextHop Interface
3.3.3.3/32 Direct 0 0 127.0.0.1 InLoop0
5.5.5.5/32 BGP 255 0 2.2.2.9 NULL0
20.1.1.0/24 OSPF 10 1563 100.1.1.1 Vlan1
100.1.1.0/24 Direct 0 0 100.1.1.2 Vlan1
100.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0
120.1.1.0/24 BGP 255 0 2.2.2.9 NULL0
Issuing the display ip routing-table command on the CEs, you should see that the cost of the OSPF route to the peer CE is now 10 (the cost configured for the sham link), and that the next hop is now the VLAN interface 1 connected to the PE. This means that VPN traffic to the peer will be forwarded over the backbone. Takes CE 1 as an example:
[CE1] display ip routing-table
Routing Tables: Public
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
20.1.1.0/24 Direct 0 0 20.1.1.1 Vlan2
20.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
20.1.1.2/32 Direct 0 0 20.1.1.2 Vlan2
30.1.1.0/24 OSPF 10 1574 100.1.1.2 Vlan1
100.1.1.0/24 Direct 0 0 100.1.1.1 Vlan1
100.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
120.1.1.0/24 OSPF 10 12 100.1.1.2 Vlan1
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
Issuing the display ospf sham-link command on the PEs, you should see the established sham link. Takes PE 1 as an example:
[PE1] display ospf sham-link
OSPF Process 100 with Router ID 100.1.1.2
Sham Link:
Area RouterId Source-IP Destination-IP State Cost
0.0.0.1 100.1.1.2 3.3.3.3 5.5.5.5 P-2-P 10
Issuing the display ospf sham-link area command, you should see that the status of the peer is Full:
[PE1] display ospf sham-link area 1
OSPF Process 100 with Router ID 100.1.1.2
Sham-Link: 3.3.3.3 --> 5.5.5.5
Neighbour State: Full
Area: 0.0.0.1
Cost: 10 State: P-2-P, Type: Sham
Timers: Hello 10 , Dead 40 , Retransmit 5 , Transmit Delay 1
Example for Configuring BGP AS Number Substitution
Network requirements
As shown in Figure 1-24, CE 1 and CE 2 belong to VPN 1 and are connected to PE 1 and PE 2 respectively. In addition, they use the same AS number 600.
Network diagram
Figure 1-24 Configure BGP AS number substitution
Interface |
IP address |
Device |
Interface |
IP address |
|
CE 1 |
Vlan-int1 |
10.1.1.1/24 |
P |
Loop0 |
2.2.2.9/32 |
|
Vlan-int2 |
100.1.1.1/24 |
|
Vlan-int1 |
30.1.1.1/24 |
PE 1 |
Loop0 |
1.1.1.9/32 |
|
Vlan-int2 |
20.1.1.2/24 |
|
Vlan-int1 |
10.1.1.2/24 |
PE 2 |
Loop0 |
3.3.3.9/32 |
|
Vlan-int2 |
20.1.1.1/24 |
|
Vlan-int1 |
30.1.1.2/24 |
CE 2 |
Vlan-int1 |
10.2.1.1/24 |
|
Vlan-int2 |
10.2.1.2/24 |
|
Vlan-int2 |
200.1.1.1/24 |
|
|
|
Configuration procedure
1) Configuring basic MPLS L3VPN
l Configure OSPF on the MPLS backbone to allow the PEs and P device to learn the routes of the loopback interfaces from each other.
l Configure MPLS basic capability and MPLS LDP on the MPLS backbone to establish LDP LSPs.
l Establish MP-IBGP peer relationship between the PEs to advertise VPN IPv4 routes.
l Configure the VPN instance of VPN 1 on PE 2 to allow CE 2 to access the network.
l Configure the VPN instance of VPN 1 on PE 1 to allow CE 1 to access the network.
l Configure BGP between PE 1 and CE 1, and between PE 2 and CE 2 to inject routes of CEs into PEs.
After completing the above configurations, if you issue the display ip routing-table command on CE 2, you should see that CE 2 has learned the route to network segment 10.1.1.0/24, where the interface used by CE 1 to access PE 1 resides; but has not learned the route to the VPN (100.1.1.0/24) behind CE 1. You should see the similar situation on CE 1.
<CE2> display ip routing-table
Routing Tables: Public
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 BGP 255 0 10.2.1.2 Vlan1
10.1.1.1/32 BGP 255 0 10.2.1.2 Vlan1
10.2.1.0/24 Direct 0 0 10.2.1.1 Vlan1
10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.2.1.2/32 Direct 0 0 10.2.1.2 Vlan1
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
200.1.1.0/24 Direct 0 0 200.1.1.1 InLoop0
200.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
Issuing the display ip routing-table vpn-instance command on the PEs, you should see the route to the VPN behind the peer CE. Takes PE 2 as an example:
<PE2> display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 7 Routes : 7
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 BGP 255 0 1.1.1.9 NULL0
10.1.1.1/32 BGP 255 0 1.1.1.9 NULL0
10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan1
10.2.1.1/32 Direct 0 0 10.2.1.1 Vlan1
10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0
100.1.1.1/32 BGP 255 0 1.1.1.9 NULL0
200.1.1.1/32 BGP 255 0 10.2.1.1 Vlan1
Enabling BGP update packet debugging on PE 2, you should see that PE 2 advertises the route to 100.1.1.1/32, and the AS_PATH is 100 600.
<PE2> terminal monitor
<PE2> terminal debugging
<PE2> debugging bgp update vpn-instance vpn1 verbose
<PE2> refresh bgp vpn-instance vpn1 all export
*0.4402392 PE2 RM/7/RMDEBUG:
BGP.vpn1: Send UPDATE to 10.2.1.1 for following destinations :
Origin : Incomplete
AS Path : 100 600
Next Hop : 10.2.1.2
100.1.1.1/32,
Issuing the display bgp routing-table peer received-routes command on CE 2, you should see that CE 2 did not receive the route to 100.1.1.1/32.
<CE2> display bgp routing-table peer 10.2.1.2 received-routes
Total Number of Routes: 4
BGP Local router ID is 10.2.1.1
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 10.1.1.0/24 10.2.1.2 0 100?
*> 10.1.1.1/32 10.2.1.2 0 100?
* 10.2.1.0/24 10.2.1.2 0 0 100?
* 10.2.1.1/32 10.2.1.2 0 0 100?
2) Configure BGP AS number substitution
# Configure BGP AS number substitution on PE 2.
<PE2> system-view
[PE2] bgp 100
[PE2-bgp] ipv4-family vpn-instance vpn1
[PE2-bgp-vpn1] peer 10.2.1.1 substitute-as
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
You should see that among the routes advertised by PE 2 to CE 2, the AS_PATH of 100.1.1.1/32 has changed from 100 600 to 100 100:
*0.13498737 PE2 RM/7/RMDEBUG:
BGP.vpn1: Send UPDATE to 10.2.1.1 for following destinations :
Origin : Incomplete
AS Path : 100 100
Next Hop : 10.2.1.2
100.1.1.1/32
Display again the routing information that CE 2 receives and the routing table:
<CE2> display bgp routing-table peer 10.2.1.2 received-routes
Total Number of Routes: 5
BGP Local router ID is 10.2.1.1
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 10.1.1.0/24 10.2.1.2 0 100?
*> 10.1.1.1/32 10.2.1.2 0 100?
* 10.2.1.0/24 10.2.1.2 0 0 100?
* 10.2.1.1/32 10.2.1.2 0 0 100?
*> 100.1.1.1/32 10.2.1.2 0 100 100?
<CE2> display ip routing-table
Routing Tables: Public
Destinations : 9 Routes : 9
Destination/Mask Proto Pre Cost NextHop Interface
10.1.1.0/24 BGP 255 0 10.2.1.2 Vlan1
10.1.1.1/32 BGP 255 0 10.2.1.2 Vlan1
10.2.1.0/24 Direct 0 0 10.2.1.1 Vlan1
10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0
10.2.1.2/32 Direct 0 0 10.2.1.2 Vlan1
100.1.1.1/32 BGP 255 0 10.2.1.2 Vlan1
127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
200.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0
After configuring BGP AS substitution on PE 1 too, the VLAN interfaces of CE 1 and CE 2 should be able to ping each other:
<CE1> ping –a 100.1.1.1 200.1.1.1
PING 200.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 200.1.1.1: bytes=56 Sequence=1 ttl=253 time=109 ms
Reply from 200.1.1.1: bytes=56 Sequence=2 ttl=253 time=67 ms
Reply from 200.1.1.1: bytes=56 Sequence=3 ttl=253 time=66 ms
Reply from 200.1.1.1: bytes=56 Sequence=4 ttl=253 time=85 ms
Reply from 200.1.1.1: bytes=56 Sequence=5 ttl=253 time=70 ms
--- 200.1.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 66/79/109 ms