HPE 5820X & 5800 Switch Series
MPLS
Configuration Guide
Part number: 5998-7393R
Software version: Release 1810
Document version: 6W100-20160129
© Copyright 2016 Hewlett Packard Enterprise Development LP
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard
Enterprise products and services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett
Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.
Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or
copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software
Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s
standard commercial license.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard
Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise
website.
Acknowledgments
Intel®, Itanium®, Pentium®, Intel Inside®, and the Intel Inside logo are trademarks of Intel Corporation in the
United States and other countries.
Microsoft® and Windows® are trademarks of the Microsoft group of companies.
Adobe® and Acrobat® are trademarks of Adobe Systems Incorporated.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.
Contents
Configuring MCE ····························································································· 1
Overview ···························································································································································· 1
MPLS L3VPN ············································································································································· 1
MPLS L3VPN concepts······························································································································ 2
Multi-VPN-instance CE ······························································································································ 4
Using MCE in tunneling applications·········································································································· 5
Configuring routing on an MCE ·························································································································· 6
Route exchange between an MCE and a VPN site ··················································································· 6
Route exchange between an MCE and a PE····························································································· 7
Configuring VPN instances ································································································································ 8
Creating a VPN instance ···························································································································· 8
Associating a VPN instance with an interface ···························································································· 8
Configuring route attributes of a VPN instance ·························································································· 9
Configuring routing on an MCE ························································································································ 10
Configuring routing between an MCE and a VPN site ············································································· 10
Configuring routing between an MCE and a PE ······················································································ 15
Resetting BGP connections ····························································································································· 18
Displaying and maintaining MCE ····················································································································· 19
Configuration examples ··································································································································· 20
Using OSPF to advertise VPN routes to the PE ······················································································ 20
Using BGP to advertise VPN routes to the PE························································································· 25
Using tunnels to advertise VPN routes ···································································································· 28
Configuring IPv6 MCE ·················································································· 35
Overview ·························································································································································· 35
Configuring VPN instances ······························································································································ 35
Creating a VPN instance ·························································································································· 35
Associating a VPN instance with an interface ·························································································· 35
Configuring route related attributes for a VPN instance ··········································································· 36
Configuring routing on an IPv6 MCE ··············································································································· 37
Configuring routing between IPv6 MCE and VPN site ············································································· 37
Configuring routing between IPv6 MCE and PE ······················································································ 41
Resetting IPv6 BGP connections ····················································································································· 44
Displaying and maintaining IPv6 MCE ············································································································· 44
IPv6 MCE configuration example ····················································································································· 45
Configuring basic MPLS ··············································································· 51
Hardware compatibility ····································································································································· 51
MPLS overview ················································································································································ 51
Basic concepts ········································································································································· 51
MPLS network structure ··························································································································· 53
LSP establishment and label distribution ································································································· 53
MPLS forwarding······································································································································ 55
LDP ·························································································································································· 57
Protocols ·················································································································································· 59
MPLS configuration task list ····························································································································· 59
Enabling the MPLS function ····························································································································· 60
Configuring a static LSP ·································································································································· 60
Establishing dynamic LSPs through LDP ········································································································ 61
Configuring MPLS LDP capability ············································································································ 61
Configuring local LDP session parameters ······························································································ 62
Configuring remote LDP session parameters ·························································································· 63
Configuring PHP ······································································································································ 63
Configuring the policy for triggering LSP establishment ·········································································· 64
Configuring the label distribution control mode ························································································ 65
Configuring LDP loop detection ··············································································································· 65
Configuring LDP MD5 authentication ······································································································· 66
i
Configuring LDP label filtering·················································································································· 66
Configuring DSCP for outgoing LDP packets ·························································································· 68
Maintaining LDP sessions ································································································································ 68
Configuring BFD for MPLS LDP··············································································································· 68
Resetting LDP sessions ··························································································································· 69
Managing and optimizing MPLS forwarding ···································································································· 69
Configuring a TTL processing mode for an LSR ······················································································ 69
Sending back ICMP TTL exceeded messages for MPLS TTL expired packets ······································ 70
Configuring LDP GR ································································································································ 71
Configuring LDP NSR ······························································································································ 73
Configuring MPLS statistics collection ············································································································· 73
Inspecting LSPs ··············································································································································· 74
Configuring MPLS LSP ping ···················································································································· 74
Configuring MPLS LSP tracert ················································································································· 74
Configuring BFD for LSPs ························································································································ 75
Configuring periodic LSP tracert ·············································································································· 76
Enabling MPLS trap ········································································································································· 76
Displaying and maintaining MPLS ··················································································································· 77
Displaying MPLS operation ······················································································································ 77
Displaying MPLS LDP operation ·············································································································· 78
Clearing MPLS statistics ·························································································································· 79
MPLS configuration examples ························································································································· 79
Configuring static LSPs ···························································································································· 79
Configuring LDP to establish LSPs dynamically ······················································································ 82
Configuring BFD for LSPs ························································································································ 86
Configuring MPLS TE ··················································································· 88
Hardware compatibility ····································································································································· 88
MPLS TE overview ·········································································································································· 88
Basic concepts ········································································································································· 89
MPLS TE implementation ························································································································ 89
CR-LSP ···················································································································································· 90
RSVP-TE·················································································································································· 91
Traffic forwarding ····································································································································· 94
Bidirectional MPLS TE tunnel ·················································································································· 96
CR-LSP backup ······································································································································· 96
FRR ·························································································································································· 96
PS for an MPLS TE tunnel ······················································································································· 97
Protocols and standards ·························································································································· 99
MPLS TE configuration task list ······················································································································· 99
Configuring basic MPLS TE ····························································································································· 99
Creating an MPLS TE tunnel over a static CR-LSP ······················································································· 100
Configuring an MPLS TE tunnel with a dynamic signaling protocol ······························································· 101
Configuration prerequisites ···················································································································· 102
Configuration procedure························································································································· 102
Configuring RSVP-TE advanced features ····································································································· 105
Configuring RSVP reservation style ······································································································· 105
Configuring RSVP state timers ·············································································································· 106
Configuring the RSVP refresh mechanism ···························································································· 106
Configuring the RSVP hello extension ··································································································· 107
Configuring RSVP-TE resource reservation confirmation ······································································ 107
Configuring RSVP authentication··········································································································· 108
Configuring DSCP for outgoing RSVP packets······················································································ 108
Configuring RSVP-TE GR ······················································································································ 108
Tuning CR-LSP setup ···································································································································· 109
Configuring route pinning ······················································································································· 109
Configuring administrative group and affinity attribute ··········································································· 109
Configuring CR-LSP reoptimization ······································································································· 110
Tuning MPLS TE tunnel setup ······················································································································· 110
Configuring loop detection ····················································································································· 110
Configuring route and label recording ···································································································· 111
Configuring tunnel setup retry ················································································································ 111
ii
Assigning priorities to a tunnel ··············································································································· 111
Configuring traffic forwarding ························································································································· 112
Forwarding traffic along MPLS TE tunnels using static routes······························································· 112
Forwarding traffic along MPLS TE tunnels through automatic route advertisement ······························ 112
Configuring traffic forwarding tuning parameters ··························································································· 114
Configuring the failed link timer ·············································································································· 114
Specifying the link metric type for tunnel path calculation······································································ 114
Configuring the traffic flow type of a tunnel ···························································································· 115
Creating a bidirectional MPLS TE tunnel ······································································································· 115
Configuring CR-LSP backup ·························································································································· 116
Configuring FRR ············································································································································ 117
Enabling FRR on the ingress node of a protected LSP ········································································· 117
Configuring a bypass tunnel on its PLR ································································································· 118
Configuring node protection ··················································································································· 118
Configuring the FRR polling timer ·········································································································· 119
Inspecting an MPLS TE tunnel ······················································································································ 119
Configuring MPLS LSP ping ·················································································································· 119
Configuring MPLS LSP tracert ··············································································································· 120
Configuring BFD for an MPLS TE tunnel ······························································································· 120
Configuring periodic LSP tracert for an MPLS TE tunnel ······································································· 121
Configuring DM ······································································································································ 122
Configuring protection switching ···················································································································· 123
Displaying and maintaining MPLS TE ············································································································ 123
Configuring MPLS TE examples ···················································································································· 125
MPLS TE using static CR-LSP configuration example ·········································································· 125
MPLS TE using RSVP-TE configuration example ················································································· 130
RSVP-TE GR configuration example ····································································································· 136
MPLS RSVP-TE and BFD cooperation configuration example······························································ 138
Bidirectional MPLS TE tunnel configuration example ············································································ 140
CR-LSP backup configuration example ································································································· 147
FRR configuration example···················································································································· 150
MPLS TE in MPLS L3VPN configuration example················································································· 159
Troubleshooting MPLS TE ····························································································································· 166
No TE LSA generated ···························································································································· 166
Configuring VPLS ······················································································· 168
Hardware compatibility ··································································································································· 168
VPLS overview ··············································································································································· 168
Basic VPLS concepts ····························································································································· 168
PW establishment ·································································································································· 169
MAC address learning and flooding ······································································································· 170
VPLS loop avoidance ····························································································································· 171
VPLS packet encapsulation ··················································································································· 171
H-VPLS implementation ························································································································· 172
Hub-spoke VPLS implementation ·········································································································· 174
VPLS configuration task list ··························································································································· 174
Enabling L2VPN and MPLS L2VPN ·············································································································· 175
Configuring static VPLS ································································································································· 175
Configuring a static VPLS instance ········································································································ 175
Configuring LDP VPLS ·································································································································· 176
Configuring an LDP VPLS instance ······································································································· 177
Configuring BGP VPLS ·································································································································· 178
Configuring the BGP extension ·············································································································· 178
Configuring a BGP VPLS instance········································································································· 178
Resetting VPLS BGP connections ········································································································· 179
Binding a service instance to a VPLS instance ······························································································ 179
Configuring traffic policing for VPLS ·············································································································· 180
Configuring traffic policing for a PW ······································································································· 180
Configuring traffic policing for an AC······································································································ 180
Enabling VPLS statistics ································································································································ 181
Enabling traffic statistics for a PW·········································································································· 181
Enabling traffic statistics for an AC ········································································································ 181
iii
Configuring MAC address learning ················································································································ 182
Configuring VPLS instance attributes ············································································································ 182
Inspecting PWs ·············································································································································· 183
Displaying and maintaining VPLS ·················································································································· 183
VPLS configuration examples ························································································································ 184
Binding service instances to VPLS instances ························································································ 185
Configuring hub-spoke VPLS ················································································································· 189
Configuring PW redundancy for H-VPLS access ··················································································· 192
Configuring BFD for the primary link in an H-VPLS network·································································· 197
Troubleshooting VPLS ··································································································································· 201
Configuring MPLS L2VPN ·········································································· 203
Hardware compatibility ··································································································································· 203
MPLS L2VPN overview ·································································································································· 203
Basic concepts of MPLS L2VPN ············································································································ 203
MPLS L2VPN network models ··············································································································· 204
Remote connection operation ················································································································ 204
Implementation of MPLS L2VPN ··········································································································· 206
VC encapsulations types························································································································ 211
MPLS L2VPN configuration task list ·············································································································· 211
Configuring basic MPLS L2VPN ···················································································································· 212
Configuring a PE-CE interface ······················································································································· 212
Configuring Ethernet encapsulation ······································································································· 212
Configuring VLAN encapsulation ··········································································································· 212
Configuring a remote CCC connection ·········································································································· 213
Configuring SVC MPLS L2VPN ····················································································································· 213
Configuring a static VC on a Layer 3 interface (approach 1) ································································· 214
Configuring a static VC on a Layer 3 interface (approach 2) ································································· 214
Configuring a static VC for a service instance ······················································································· 214
Configuring Martini MPLS L2VPN ·················································································································· 216
Configuring the remote peer ·················································································································· 216
Creating a Martini VC on a Layer 3 interface ························································································· 217
Creating a Martini VC for a service instance ·························································································· 217
Inspecting VCs ······································································································································· 218
Configuring Kompella MPLS L2VPN ············································································································· 219
Configuring BGP L2VPN capability ········································································································ 219
Creating and configuring an MPLS L2VPN ···························································································· 219
Creating a CE connection ······················································································································ 220
Configuring traffic policing for an AC ············································································································· 221
Enabling traffic statistics for an AC ················································································································ 222
Displaying and maintaining MPLS L2VPN ····································································································· 223
MPLS L2VPN configuration examples ··········································································································· 224
Example for configuring a remote CCC connection ··············································································· 224
Example for configuring SVC MPLS L2VPN ·························································································· 227
Example for configuring Martini MPLS L2VPN ······················································································ 231
Example for configuring Kompella MPLS L2VPN ·················································································· 234
Example for configuring a VC for a service instance ············································································· 237
Troubleshooting MPLS L2VPN ······················································································································ 241
Configuring MPLS L3VPN ·········································································· 242
Hardware compatibility ··································································································································· 242
MPLS L3VPN overview ·································································································································· 242
MPLS L3VPN concepts·························································································································· 243
MPLS L3VPN packet forwarding············································································································ 245
MPLS L3VPN networking schemes ······································································································· 246
MPLS L3VPN routing information advertisement··················································································· 249
Inter-AS VPN·········································································································································· 250
Carrier's carrier ······································································································································ 253
Nested VPN ··········································································································································· 255
HoVPN ··················································································································································· 256
OSPF VPN extension····························································································································· 258
BGP AS number substitution and SoO ·································································································· 261
iv
MPLS L3VPN configuration task list ·············································································································· 261
Configuring basic MPLS L3VPN ···················································································································· 262
Configuring VPN instances ···················································································································· 262
Configuring routing between PE and CE ······························································································· 266
Configuring routing between PEs··········································································································· 271
Configuring routing features for BGP VPNv4 subaddress family ··························································· 272
Configuring inter-AS VPN ······························································································································ 275
Configuring inter-AS option A················································································································· 275
Configuring inter-AS option B················································································································· 275
Configuring inter-AS option C ················································································································ 276
Configuring nested VPN ································································································································ 278
Configuration restrictions and guidelines ······························································································· 278
Configuration procedure························································································································· 278
Configuring HoVPN ········································································································································ 279
Configuring an OSPF sham link ····················································································································· 280
Configuring a loopback interface············································································································ 280
Redistributing the loopback interface route and OSPF routes into BGP················································ 280
Creating a sham link ······························································································································ 281
Configuring BGP AS number substitution and SoO ······················································································· 281
Resetting BGP connections ··························································································································· 282
Displaying and maintaining MPLS L3VPN ····································································································· 283
MPLS L3VPN configuration examples ··········································································································· 285
Configuring MPLS L3VPNs using EBGP between PE and CE ······························································ 285
Configuring MPLS L3VPNs using IBGP between PE and CE ······························································· 292
Configuring a hub-spoke network ·········································································································· 300
Configuring inter-AS option A················································································································· 308
Configuring inter-AS option B················································································································· 312
Configuring inter-AS option C ················································································································ 317
Configuring carrier's carrier ···················································································································· 323
Configuring nested VPN························································································································· 330
Configuring HoVPN ································································································································ 339
Configuring OSPF sham links ················································································································ 346
Configuring BGP AS number substitution ······························································································ 351
Configuring BGP AS number substitution and SoO ··············································································· 354
Configuring IPv6 MPLS L3VPN ·································································· 358
Hardware compatibility ··································································································································· 358
Overview ························································································································································ 358
IPv6 MPLS L3VPN packet forwarding ··································································································· 359
IPv6 MPLS L3VPN routing information advertisement ·········································································· 359
IPv6 MPLS L3VPN network schemes and functions ············································································· 360
IPv6 MPLS L3VPN configuration task list ······································································································ 360
Configuring basic IPv6 MPLS L3VPN ············································································································ 360
Configuring VPN instances ···················································································································· 361
Configuring route related attributes for a VPN instance ········································································· 361
Configuring routing between PE and CE ······························································································· 364
Configuring routing between PEs··········································································································· 367
Configuring routing features for the BGP-VPNv6 subaddress family····················································· 368
Configuring inter-AS IPv6 VPN ······················································································································ 369
Configuring inter-AS IPv6 VPN option A ································································································ 370
Configuring inter-AS IPv6 VPN option C ································································································ 370
Resetting IPv6 BGP connections ··················································································································· 371
Displaying and maintaining IPv6 MPLS L3VPN ····························································································· 371
IPv6 MPLS L3VPN configuration examples ··································································································· 372
Configuring IPv6 MPLS L3VPNs············································································································ 372
Configuring inter-AS IPv6 VPN option A ································································································ 380
Configuring inter-AS IPv6 VPN option C ································································································ 384
Configuring carrier's carrier ···················································································································· 391
Document conventions and icons ······························································· 399
Conventions ··················································································································································· 399
Network topology icons ·································································································································· 400
v
Support and other resources ······································································ 401
Accessing Hewlett Packard Enterprise Support ···························································································· 401
Accessing updates ········································································································································· 401
Websites ················································································································································ 402
Customer self repair ······························································································································· 402
Remote support······································································································································ 402
Documentation feedback ······················································································································· 402
Index ··········································································································· 403
vi
Configuring MCE
This chapter covers only MCE-related configuration. For information about routing protocols, see
Layer 3—IP Services Configuration Guide.
The term "router" in this chapter refers to both routers and Layer 3 switches.
The term "interface" in this chapter collectively refers to Layer 3 interfaces, including VLAN
interfaces, Layer 3 Ethernet interfaces, and Layer 3 aggregate interfaces. You can set an Ethernet
port as a Layer 3 interface by using the port link-mode route command (see Layer 2—LAN
Switching Configuration Guide).
Overview
This section describes the basic MPLS L3VPN information that is important to understand the
Multi-VPN-Instance CE (MCE) feature, and the MCE specific information.
MPLS L3VPN
MPLS L3VPN is a type of PE-based L3VPN technology for service provider VPN solutions. It uses
BGP to advertise VPN routes, and it 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.
The MPLS L3VPN model consists of the following types of devices:
•
CE—A CE resides on a customer network and has one or more interfaces directly connected to
service provider networks. A CE can be a router, a switch, or a host. It can neither "sense" the
existence of any VPN nor does it need to support MPLS.
•
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.
•
P—A P device is a core device on a service provider network. It is not directly connected with
any CE. It has only basic MPLS forwarding capability.
1
Figure 1 Network diagram for MPLS L3VPN model
CEs and PEs mark the boundary between the service providers and the customers.
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 for a CE, it uses BGP to exchange VPN routing
information with other PEs. A PE maintains routing information about VPNs that are directly
connected, rather than for all VPN routing information on the provider network.
A P router maintains only routes to PEs and does not deal with 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, and P routers function as the transit LSRs.
MPLS L3VPN concepts
This section describes concepts for MPLS L3VPN.
Site
Sites are often mentioned in the VPN. A site has the following features:
•
A site is a group of IP systems with IP connectivity that does not rely on any service-provider
network to implement.
•
The classification of a site depends on the topology relationship of the devices, rather than the
geographical positions, although the devices at a site are, in most cases, adjacent to each other
geographically.
•
The devices at a site can belong to multiple VPNs.
•
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. This kind of a set is
called a VPN.
Address space overlapping
Each VPN independently manages the addresses it uses. The assembly of such addresses for a
VPN is called an address space.
2
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, the address space overlaps.
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 the independence and security of VPN data, each VPN instance on a PE maintains a routing
table and an LFIB. VPN instance information contains the following items: the LFIB, the IP routing
table, the interfaces bound to the VPN instance, and the administration information for the VPN
instance. The administration information for the VPN instance includes the RD, route filtering policy,
and member interface list.
VPN-IPv4 address
Traditional BGP cannot process overlapping VPN routes. For example, if both VPN 1 and VPN 2 use
the subnet 10.110.10.0/24 and each advertises a route to the subnet, BGP selects only one of them,
resulting in the 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 has 12 bytes. The first eight bytes represent the RD, followed by a four-byte
IPv4 address prefix.
Figure 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 if the assigned RDs are unique. 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.
Configure a distinct RD for each VPN instance on a PE, so that routes to the same CE use the same
RD. The VPN-IPv4 address with RD 0 is 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 an AS number plus an arbitrary number or an IP address plus an arbitrary number.
An RD can be in one of the following formats distinguished by the Type field:
•
If 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.
•
If 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.
•
If the value of the Type field is 2, the Administrator subfield occupies four bytes, the Assigned
number subfield occupies two bytes, and the RD format is 32-bit AS number:16-bit user-defined
number, where the minimum value of the AS number is 65536. For example, 65536:1.
3
To guarantee the global uniqueness of an RD, do not set the Administrator subfield to any private AS
number or private IP address.
Route target attributes
MPLS L3VPN uses the BGP extended community attributes called "route target attributes" to control
the advertisement of VPN routing information.
A VPN instance on a PE supports the following types of route target attributes:
•
Export target attribute—A local PE sets this type of route target attribute for VPN-IPv4 routes
learned from directly connected sites before advertising them to other PEs.
•
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, route target attributes define which sites can receive VPN-IPv4 routes and from
which sites a PE can receive routes.
Similar to RDs, route target attributes can be of the following formats:
•
16-bit AS number:32-bit user-defined number. For example, 100:1.
•
32-bit IPv4 address:16-bit user-defined number. For example, 172.1.1.1:1.
•
32-bit AS number:16-bit user-defined number, where the minimum value of the AS number is
65536. For example, 65536:1.
Multi-VPN-instance CE
BGP/MPLS VPN transmits private network data through MPLS tunnels over the public network.
However, the traditional MPLS L3VPN architecture requires that each VPN instance exclusively use
a CE to connect with a PE, as shown in Figure 1.
For better services and higher security, a private network is usually divided into multiple VPNs to
isolate services. To meet these requirements, you can configure a CE for each VPN, which increases
users' device expenses and maintenance costs. Or, you can configure multiple VPNs to use the
same CE and the same routing table, which sacrifices data security.
By using the MCE function, you can have both lower cost and higher security in multi-VPN networks.
You can use MCE to bind each VPN to a VLAN interface on the CE, and create and maintain a
separate routing table for each VPN. This separates the forwarding paths of packets of different
VPNs and, in conjunction with the PE, can correctly advertise the routes of each VPN to the peer PE,
ensuring the normal transmission of VPN packets over the public network.
This section uses Figure 3 to describe how an MCE maintains the routing entries of multiple VPNs
and how an MCE exchanges VPN routes with PEs.
4
Figure 3 Network diagram for the MCE function
VPN 1
Site 1
VPN 2
Site 1
P
PE1
VLAN-int2
CE
VLAN-int7
PE2
VLAN-int8
VLAN-int3
MCE
P
CE
VPN 2
Site 2
PE
Site 2
VPN 1
On the left-side network, there are two VPN sites, both of which are connected to the MPLS
backbone through the MCE device. VPN 1 and VPN 2 on the left-side network must establish a
tunnel with both VPN 1 and VPN 2 on the right-side network.
The MCE creates one routing table for VPN 1 and one for VPN 2. VLAN-interface 2 is bound to VPN
1, and VLAN-interface 3 is bound to VPN 2. Upon receiving a route, the MCE determines the source
of the route according to the number of the receiving interface, and adds it to the corresponding
routing table.
You must also bind PE 1 interfaces that are connected to the MCE to the VPNs in the same way as
on the MCE. The MCE connects to PE 1 through a trunk link, which permits packets of VLAN 2 and
VLAN 3 to pass through with VLAN tags. Based on the VLAN tag of an incoming packet, PE 1 can
determine its VPN and output tunnel.
Using MCE in tunneling applications
In addition to MPLS L3VPN, you can also use tunneling technologies to implement other types of
VPNs. The MCE function provided by the switch can be applied in VPN applications based on
tunneling.
Figure 4 Network diagram for using MCE in a tunneling application (1)
By establishing multiple tunnels between two MCE devices and binding the tunnel interfaces to VPN
instances, you can make the routing information and data of the VPN instances delivered to the peer
devices through the bound tunnel interfaces. According to the tunnel interfaces receiving the routes,
an MCE device determines the VPN instances that the routes belong to and advertises the routes to
5
the corresponding sites. As shown in Figure 4, you can bind Tunnel 1 to VPN 1 to make the MCE
devices deliver the routing information and data of VPN 1 through the tunnel.
You can also use an MCE in a tunneling application as shown in Figure 5 to connect multiple remote
CEs through tunnels. In this scenario, the CE devices only need to receive and advertise routes as
usual, while the MCE advertises and receives VPN routing information based on the bindings
between tunnel interfaces and VPNs.
Figure 5 Network diagram for using MCE in a tunneling application (2)
CE
VPN 1
Site1
MCE
VPN 1
Site2
IP network
Tunn
el 2
VPN 2
Site1
CE
VPN 2
Site2
MCE devices in a tunneling application can exchange VPN routing information with their peer MCE
devices or CE devices directly, just as MCE devices in an MPLS L3VPN application do with the
corresponding PEs. For more information, see "Route exchange between an MCE and a PE."
GRE tunnel, IPv4 over IPv4 tunnel, and IPv4 over IPv6 tunnel support MCE. For more information
about tunnel types, see Layer 3—IP Services Configuration Guide.
Configuring routing on an MCE
Interface-to-VPN-instance binding enables MCEs and PEs to determine the sources of received
packets and then forward the packets according to the routing information concerning the
corresponding VPNs. MCE routing configuration includes:
•
MCE-VPN site routing configuration
•
MCE-PE routing configuration
Route exchange between an MCE and a VPN site
An MCE can adopt the following routing protocols to exchange VPN routes with a site:
•
Static route
•
RIP
•
OSPF
•
IS-IS
•
IBGP
•
EBGP
This section briefly introduces the cooperation of routing protocols and MCE. For information about
the routing protocols, see Layer 3—IP Routing Configuration Guide.
Static routes
An MCE can communicate with a site through static routes. As static routes configured for traditional
CEs take effect globally, address overlapping between multiple VPNs remains a problem until the
6
emergence of MCE. MCE allows static-route-to-VPN-instance binding, which isolates the static
routes of different VPNs.
RIP
The switch can bind RIP processes to VPN instances. With these bindings on the MCE, private
network routes of different VPNs can be exchanged between MCE and sites through different RIP
processes, isolating and securing VPN routes.
OSPF
The switch can bind OSPF processes to VPN instances and isolate the routes of different VPNs.
For an OSPF process bound to a VPN instance, the router ID of the public network configured in
system view is invalid. You must specify the router ID when creating an OSPF process.
An OSPF process can be bound to only one VPN instance. A VPN instance can use multiple OSPF
processes for private network route transmission. To make sure routes can be advertised correctly,
configure the same domain ID for all OSPF processes bound to the same VPN instance.
Routes redistributed from OSPF to BGP on the MCE have their OSPF attributes removed. To enable
BGP to distinguish routes redistributed from different OSPF domains, you must enable the
redistributed routes to carry the OSPF domain ID by configuring the domain-id command in OSPF
view. The domain ID is added to BGP VPN routes as an extended community attribute.
In cases where a VPN has multiple MCE devices attached to it and when an MCE device advertises
the routes learned from BGP within the VPN, the routes may be learned by other MCE devices,
generating route loops. To prevent route loops, configure route tags for different VPN instances on
each MCE. Hewlett Packard Enterprise recommends that you assign the same route tag to the same
VPN on all MCEs.
IS-IS
Similar to those in OSPF, IS-IS processes can be bound to VPN instances for private network routes
to be exchanged between MCE and sites. An IS-IS process can be bound to only one VPN instance.
IBGP
To use IBGP to exchange private routes between an MCE and a site, configure IBGP peers for VPN
instances on the MCE and redistribute IGP routing information from corresponding VPNs. If the MCE
is connected with multiple sites in the same VPN, you can configure the MCE as a route reflector (RR)
and configure the egress routers of the sites as clients, making the MCE reflect routing information
between the sites. This eliminates the necessity for BGP connections between sites, reducing the
number of BGP connections and simplifying network configuration.
EBGP
To use EBGP for exchanging routing information between an MCE and VPN sites, you must
configure a BGP peer for each VPN instance on the MCE, and redistribute the IGP routes of each
VPN instance on the VPN sites. You also can configure filtering policies to filter the received routes
and the routes to be advertised.
Route exchange between an MCE and a PE
Routing information entries are bound to specific VPN instances on an MCE device, and packets of
each VPN instance are forwarded between MCE and PE according to interface. As a result, VPN
routing information can be transmitted by performing relatively simple configurations between MCE
and PE, such as importing the VPN routing entries on MCE devices to the routing table of the routing
protocol running between MCE and PEs.
The following routing protocols can be used between MCE and PE devices for routing formation
exchange:
•
Static route
•
RIP
7
•
OSPF
•
IS-IS
•
IBGP
•
EBGP
For information about routing protocol configuration and route import, see Layer 3—IP Routing
Configuration Guide.
Configuring VPN instances
You must configure VPN instances in all MCE networking schemes.
VPN instances isolate not only VPN routes from public network routes, but also routes of a VPN from
those of another VPN. This feature allows VPN instances to be used in networking scenarios
besides MCE.
Creating a VPN instance
A VPN instance is associated with a site. It is a collection of the VPN membership and routing rules of
its associated site. A VPN instance does not necessarily correspond to one VPN.
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 other parameters for the instance but a description.
You can configure a description for a VPN instance to record its related information, such as its
relationship with a certain VPN.
To create and configure a VPN instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a VPN instance and
enter VPN instance view.
ip vpn-instance
vpn-instance-name
N/A
3.
Configure an RD for the VPN
instance.
route-distinguisher
route-distinguisher
For easy management, set the
same RD for the same VPN
instance on the MCE and the PE.
4.
Configure a description for
the VPN instance.
description text
Optional.
Associating a VPN instance with an interface
After you create and configure a VPN instance, you must associate the VPN instance with the
interfaces connected to the VPN sites.
In an MPLS L3VPN application, you must also associate the VPN instances with the interfaces
connected to the PE.
In a tunneling application, you must associate the VPN instances with the tunnel interfaces
connecting the peer MCE device or CE device.
You can add a management Ethernet interface on the switch to a VPN, so the IP address of the
interface only participates in the route calculation of the specified VPN.
To associate a VPN instance with an interface:
8
Step
Command
Remarks
5.
Enter system view.
system-view
N/A
6.
Enter interface view.
interface interface-type
interface-number
N/A
By default, no VPN instance is
associated with any interface.
7.
Associate the interface with
a VPN instance.
ip binding vpn-instance
vpn-instance-name
Associating the interface with a
VPN instance clears the IP
address of the interface.
Therefore, you must reconfigure
the IP address of the interface
after executing this command.
Configuring route attributes of a VPN instance
The control process of VPN route advertisement is as follows:
•
When a VPN route learned from a site is redistributed into BGP, BGP associates the route with
a route target extended community attribute list, which is usually the export target attribute of
the VPN instance associated with the site.
•
The VPN instance determines which routes it can accept and redistribute according to the
import-extcommunity in the route target.
•
The VPN instance determines how to change the route targets attributes for routes to be
advertised according to the export-extcommunity in the route target.
IMPORTANT:
• The route target attribute can be advertised to the PE along with the routing information only
when BGP runs between the MCE and PE. In other cases, this attribute does not take effect.
• Before associating a routing policy with a VPN instance, you must first create the routing policy.
Otherwise, the default routing policy is used.
To configure route related attributes of a VPN instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VPN instance view.
ip vpn-instance
vpn-instance-name
N/A
3.
Enter IPv4 VPN view.
ipv4-family
Optional.
4.
Associate the current VPN
instance with one or more
route targets.
vpn-target vpn-target&<1-8>
[ both | export-extcommunity |
import-extcommunity ]
A single vpn-target command
can configure up to eight route
targets. You can configure up to
64 route targets for a VPN
instance.
Optional.
5.
Configure the maximum
number of routes for the
VPN instance.
Not configured by default.
routing-table limit number
{ warn-threshold | simply-alert }
9
Setting the maximum number of
routes for a VPN instance to
support is for preventing too many
routes from being redistributed
into the PE.
Step
Command
Remarks
Optional.
6.
Apply an import routing
policy to the current VPN
instance.
import route-policy route-policy
By default, all routes permitted by
the import target attribute can be
redistributed into the VPN
instance.
Optional.
7.
Apply an export routing
policy to the current VPN
instance.
export route-policy route-policy
By default, all VPN instance
routes permitted by the export
target attribute can be
redistributed.
NOTE:
You can configure route related attributes for IPv4 VPNs in both VPN instance view and IPv4 VPN
view. Those configured in IPv4 VPN view take precedence.
Configuring routing on an MCE
MCE implements service isolation by using route isolation. MCE routing configuration includes:
•
Routing configuration between an MCE and a VPN site
•
Routing configuration between an MCE and a PE
On the PE in an MCE network environment, disable routing loop detection to avoid route loss during
route calculation and disable route redistribution between routing protocols to save system
resources.
Before you configure routing on an MCE, complete the following tasks:
•
On the MCE, configure VPN instances, and bind the VPN instances to the interfaces that are
connected to the VPN sites and to the PE.
•
Configure the link layer and network layer protocols on related interfaces to ensure IP
connectivity.
Configuring routing between an MCE and a VPN site
This section shows how to configure static routing, RIP, OSPF, IS-IS, EBGP, or IBGP between an
MCE and a VPN site.
Configuring static routing between an MCE and a VPN site
An MCE can reach a VPN site through a static route. Static routing on a traditional CE is globally
effective and thus does not support address overlapping among VPNs. An MCE supports binding a
static route to a VPN instance, so that the static routes of different VPN instances can be isolated
from each other.
To configure static routing between an MCE and a VPN site:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
10
Step
Command
•
2.
3.
Remarks
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 ]
ip route-static vpn-instance
s-vpn-instance-name&<1-6> 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 ]
Configure a static
route for a VPN
instance.
•
Configure the default
precedence for static
routes.
ip route-static default-preference
default-preference-value
Use either command.
Perform this
configuration on the
MCE. On a VPN site,
configure a normal static
route.
Optional.
The default setting is 60.
Configuring RIP between an MCE and a VPN site
A RIP process belongs to the public network or a single VPN instance. If you create a RIP process
without binding it to a VPN instance, the process belongs to the public network. By configuring RIP
process-to-VPN instance bindings on an IPv6 MCE, you allow routes of different VPNs to be
exchanged between the MCE and the sites through different RIP processes, ensuring the separation
and security of VPN routes.
For more information about RIP, see Layer 3—IP Routing Configuration Guide.
To configure RIP between MCE and VPN site:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RIP process for a
VPN instance and enter RIP
view.
rip [ process-id ] vpn-instance
vpn-instance-name
Perform this configuration on the
MCE. On a VPN site, create a
normal RIP process.
3.
Enable RIP on the interface
attached to the specified
network.
network network-address
By default, RIP is disabled on an
interface.
4.
Redistribute remote site
routes advertised by the PE.
import-route protocol
[ process-id ] [ allow-ibgp ] [ cost
cost | route-policy
route-policy-name | tag tag ] *
By default, no route is
redistributed into RIP.
5.
Configure the default cost
value for the redistributed
routes.
default cost value
Optional.
0 by default.
Configuring OSPF between an MCE and a VPN site
An OSPF process belongs to the public network or a single VPN instance. If you create an OSPF
process without binding it to a VPN instance, the process belongs to the public network.
By configuring OSPF process-to-VPN instance bindings on a MCE, you allow routes of different
VPNs to be exchanged between the MCE and the sites through different OSPF processes, ensuring
the separation and security of VPN routes.
For more information about OSPF, see Layer 3—IP Routing Configuration Guide.
11
To configure OSPF between an MCE and a VPN site:
Step
1.
2.
Enter system view.
Create an OSPF process for
a VPN instance and enter
OSPF view.
Command
Remarks
system-view
N/A
ospf [ process-id | router-id
router-id | vpn-instance
vpn-instance-name ] *
Perform this configuration on the
MCE. On a VPN site, create a
normal OSPF process.
An OSPF process can belong to
only one VPN instance, but one
VPN instance can use multiple
OSPF processes to advertise the
VPN routes.
Optional.
By default, the domain ID is 0.
Configure the OSPF domain
ID.
domain-id domain-id
[ secondary ]
4.
Redistribute remote site
routes advertised by the PE.
import-route protocol
[ process-id | allow-ibgp ] [ cost
cost | type type | tag tag |
route-policy route-policy-name ]
*
By default, no route of any other
routing protocol is redistributed
into OSPF.
5.
Create an OSPF area and
enter OSPF area view.
area area-id
By default, no OSPF area is
created.
6.
Enable OSPF on the
interface attached to the
specified network in the
area.
network ip-address
wildcard-mask
By default, an interface neither
belongs to any area nor runs
OSPF.
3.
Perform this configuration on the
MCE. On a VPN site, perform the
common OSPF configuration.
An OSPF process that is bound with a VPN instance does not use the public network router ID
configured in system view. Therefore, you must configure a router ID when starting the OSPF
process. All OSPF processes for the same VPN must be configured with the same OSPF domain ID
to ensure correct route advertisement.
Configuring IS-IS between an MCE and a VPN site
An IS-IS process belongs to the public network or a single VPN instance. If you create an IS-IS
process without binding it to a VPN instance, the process belongs to the public network.
By configuring IS-IS process-to-VPN instance bindings on a MCE, you allow routes of different VPNs
to be exchanged between the MCE and the sites through different IS-IS processes, ensuring the
separation and security of VPN routes.
For more information about IS-IS, see Layer 3—IP Routing Configuration Guide.
To configure IS-IS between an MCE and a VPN site:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IS-IS process for a
VPN instance and enter
IS-IS view.
isis [ process-id ] vpn-instance
vpn-instance-name
Perform this configuration on the
MCE. On a VPN site, configure a
normal IS-IS process.
3.
Configure a network entity
title.
network-entity net
Not configured by default.
12
Step
Command
Remarks
Optional.
Redistribute remote site
routes advertised by the PE.
import-route { isis [ process-id ] |
ospf [ process-id ] | rip
[ process-id ] | bgp [ allow-ibgp ] |
direct | static } [ cost cost |
cost-type { external | internal } |
[ level-1 | level-1-2 | level-2 ] |
route-policy route-policy-name |
tag tag ] *
5.
Return to system view.
quit
N/A
6.
Enter interface view.
interface interface-type
interface-number
N/A
7.
Enable the IS-IS process on
the interface.
isis enable [ process-id ]
Disabled by default.
4.
By default, IS-IS does not
redistribute routes of any other
routing protocol.
If you do not specify the route
level in the command, the
command redistributes routes to
the level-2 routing table by
default.
Configuring EBGP between an MCE and a VPN site
To use EBGP for exchanging routing information between an MCE and VPN sites, configure a BGP
peer for each VPN instance on the MCE, and redistribute the IGP routes of each VPN instance on
the VPN sites.
If EBGP is used for route exchange, you also can configure filtering policies to filter the received
routes and the routes to be advertised.
1.
Configure the MCE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter BGP-VPN instance
view.
ipv4-family vpn-instance
vpn-instance-name
N/A
4.
Configure an EBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
5.
Allow the local AS number to
appear in the AS_PATH
attribute of a received route,
and set the maximum
number of times that such
case is allowed to appear.
peer { group-name | ip-address }
allow-as-loop [ number ]
Optional.
6.
Redistribute remote site
routes advertised by the PE.
import-route protocol
[ process-id | all-processes ]
[ med med-value | route-policy
route-policy-name ] *
By default, no route redistribution
is configured.
7.
Configure a filtering policy to
filter the 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 ]
Configure a filtering policy to
filter the received routes.
filter-policy { acl-number |
ip-prefix ip-prefix-name } import
8.
13
Optional.
By default, BGP does not filter the
routes to be advertised.
Optional.
By default, BGP does not filter the
received routes.
BGP checks routing loops by examining AS numbers. If EBGP is used, the MCE advertises routing
information carrying the local AS number to the site and then receives routing updates from the site.
The routing updates carry the AS number of the MCE, so the MCE discards the updates to avoid
routing loops. To enable the MCE to receive these routes, configure the MCE to allow routing loops.
Routes redistributed from OSPF to BGP on the MCE have their OSPF attributes removed. To enable
BGP to distinguish routes redistributed from different OSPF domains, you must enable the
redistributed routes to carry the OSPF domain ID by configuring the domain-id command in OSPF
view. The domain ID is added to BGP VPN routes as an extended community attribute.
BGP runs in a BGP VPN instance in the same way as it runs in a normal network. For more
information about BGP, see Layer 3—IP Routing Configuration Guide.
2.
Configure a VPN site:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure the MCE as the
EBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
4.
Redistribute the IGP routes
of the VPN.
import-route protocol
[ process-id ] [ med med-value |
route-policy route-policy-name ]
*
Optional.
A VPN site must advertise the
VPN network addresses it can
reach to the connected MCE.
Configuring IBGP between an MCE and a VPN site
If IBGP is used for exchanging routing information between an MCE and VPN sites, configure a BGP
peer for each VPN instance, and redistribute the IGP routes of each VPN instance on the VPN sites.
1.
Configure the MCE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter BGP-VPN instance
view.
ipv4-family vpn-instance
vpn-instance-name
N/A
4.
Configure an IBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
5.
Configure the system to be
the RR and specify the peer
as the client of the RR.
peer { group-name | ip-address }
reflect-client
6.
Redistribute remote site
routes advertised by the PE.
import-route protocol
[ process-id | all-processes ]
[ med med-value | route-policy
route-policy-name ] *
7.
Configure a filtering policy to
filter the 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 ]
Configure a filtering policy to
filter the received routes.
filter-policy { acl-number |
ip-prefix ip-prefix-name } import
8.
14
Optional.
By default, no RR or RR client is
configured.
By default, no route redistribution
is configured.
Optional.
By default, BGP does not filter the
routes to be advertised.
Optional.
By default, BGP does not filter the
received routes.
NOTE:
After you configure a VPN site as an IBGP peer of the MCE, the MCE does not advertise the BGP
routes learned from the VPN site to other IBGP peers, including VPNv4 peers. An MCE advertises
routes learned from a VPN site to other IBGP peers only when you configure the VPN site as a client
of the RR (the MCE).
2.
Configure a VPN site:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure the MCE as the
IBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
4.
Redistribute the IGP routes
of the VPN.
import-route protocol
[ process-id ] [ med med-value |
route-policy route-policy-name ]
*
Optional.
A VPN site must advertise the
VPN network addresses it can
reach to the connected MCE.
Configuring routing between an MCE and a PE
MCE-PE routing configuration includes these tasks:
•
Bind the MCE-PE interfaces to VPN instances
•
Perform route configurations
•
Redistribute VPN routes into the routing protocol running between the MCE and the PE.
Configuring static routing between an MCE and a PE
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
•
2.
3.
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 ]
ip route-static vpn-instance
s-vpn-instance-name&<1-6> 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 ]
Configure a static
route for a VPN
instance.
•
Configure the default
precedence for static
routes.
ip route-static default-preference
default-preference-value
Configuring RIP between an MCE and a PE
15
Use either command.
Optional.
60 by default.
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RIP process for a
VPN instance and enter RIP
view.
rip [ process-id ] vpn-instance
vpn-instance-name
N/A
Enable RIP on the interface
attached to the specified
network.
network network-address
By default, RIP is disabled
on an interface.
4.
Redistribute the VPN routes.
import-route protocol [ process-id ]
[ allow-ibgp ] [ cost cost |
route-policy route-policy-name | tag
tag ] *
By default, no route of any
other routing protocol is
redistributed into RIP.
5.
Configure the default cost
value for the redistributed
routes.
default cost value
3.
Optional.
0 by default.
Configuring OSPF between an MCE and a PE
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an OSPF
process for a VPN
instance and enter
OSPF view.
ospf [ process-id | router-id router-id |
vpn-instance vpn-instance-name ] *
N/A
Disabled by default.
Disable routing loop detection
for a VPN OSPF process on
the MCE. Otherwise, the MCE
cannot receive OSPF routes
from the PE.
3.
Disable routing loop
detection.
vpn-instance-capability simple
4.
Configure the OSPF
domain ID.
domain-id domain-id [ secondary ]
5.
Redistribute the VPN
routes.
import-route protocol [ process-id |
allow-ibgp ] [ cost cost | type type | tag
tag | route-policy route-policy-name ] *
By default, no route of any
other routing protocol is
redistributed into OSPF.
6.
Configure a filtering
policy to filter the
advertised routes.
filter-policy { acl-number | ip-prefix
ip-prefix-name } export [ protocol
[ process-id ] ]
Optional.
Optional.
By default, the domain ID is 0.
By default, advertised routes
are not filtered.
Optional.
7.
8.
9.
Configure the default
parameters for
redistributed routes
(cost, route number,
tag, and type).
default { cost cost | limit limit | tag tag |
type type } *
Create an OSPF area
and enter OSPF area
view.
area area-id
By default, no OSPF area is
created.
Enable OSPF on the
interface attached to
the specified network in
the area.
network ip-address wildcard-mask
By default, an interface neither
belongs to any area nor runs
OSPF.
16
The default cost is 1, the
default maximum number of
routes redistributed per time is
1000, the default tag is 1, and
default type of redistributed
routes is Type-2.
Configuring IS-IS between an MCE and a PE
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IS-IS
process for a VPN
instance and enter
IS-IS view.
isis [ process-id ] vpn-instance
vpn-instance-name
N/A
Configure a network
entity title.
network-entity net
By default, no network entity title
is configured.
3.
Optional.
Redistribute the VPN
routes.
import-route { isis [ process-id ] | ospf
[ process-id ] | rip [ process-id ] | bgp
[ allow-ibgp ] | direct | static } [ cost
cost | cost-type { external | internal } |
[ level-1 | level-1-2 | level-2 ] |
route-policy route-policy-name | tag
tag ] *
Configure a filtering
policy to filter the
advertised routes.
filter-policy { acl-number | ip-prefix
ip-prefix-name | route-policy
route-policy-name } export [ isis
process-id | ospf process-id | rip
process-id | bgp | direct | static ]
6.
Return to system view.
quit
N/A
7.
Enter interface view.
interface interface-type
interface-number
N/A
8.
Enable the IS-IS
process on the
interface.
isis enable [ process-id ]
Disabled by default.
4.
5.
By default, IS-IS does not
redistribute routes of any other
routing protocol.
If you do not specify the route
level in the command, the
command redistributes routes to
the level-2 routing table by
default.
Optional.
By default, IS-IS does not filter
advertised routes.
Configuring EBGP between an MCE and a PE
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter BGP-VPN
instance view.
ipv4-family vpn-instance
vpn-instance-name
N/A
4.
Configure the PE as the
EBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
5.
Redistribute the VPN
routes of the VPN site.
import-route protocol [ process-id |
all-processes ] [ med med-value |
route-policy route-policy-name ] *
By default, no route
redistribution is configured.
6.
Configure a filtering
policy to filter the 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 ]
7.
Configure a filtering
policy to filter the
received routes.
filter-policy { acl-number | ip-prefix
ip-prefix-name } import
17
Optional.
By default, BGP does not
filter the routes to be
advertised.
Optional.
By default, BGP does not
filter the received routes.
NOTE:
BGP runs within a VPN in the same way as it runs within a public network. For more information
about BGP, see Layer 3—IP Routing Configuration Guide.
Configuring IBGP between an MCE and a PE
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter BGP-VPN
instance view.
ipv4-family vpn-instance
vpn-instance-name
N/A
4.
Configure the PE as the
IBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
5.
Redistribute the VPN
routes of the VPN site.
import-route protocol [ process-id |
all-processes ] [ med med-value |
route-policy route-policy-name ] *
By default, no route
redistribution is configured.
6.
Configure the egress
router of the site as a
client of the route
reflector.
peer { group-name | ip-address }
reflect-client
Optional.
By default, no route reflector
or client is configured.
Optional.
7.
Enable route reflection
between clients.
Enabled by default.
reflect between-clients
If the clients are fully meshed,
you do not need to enable
route reflection.
Optional.
8.
9.
By default, each RR in a
cluster uses its own router ID
as the cluster ID.
Specify a cluster ID for
the route reflector.
reflector cluster-id cluster-id
If more than one RR exists in
a cluster, use this command
to configure the same cluster
ID for all RRs in the cluster to
avoid routing loops.
Configure a filtering
policy to filter the 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.
10. Configure a filtering
policy to filter the
received routes.
filter-policy { acl-number | ip-prefix
ip-prefix-name } import
By default, BGP does not
filter the routes to be
advertised.
Optional.
By default, BGP does not
filter the received routes.
Resetting BGP connections
If the BGP configuration changes, you can refresh or reset BGP connections to make new
configurations take effect. Refreshing BGP connections refers to updating BGP routing information
without breaking BGP neighbor relationships. A refreshing operation requires that BGP peers have
route refreshment capability (supporting Route-Refresh messages).
To refresh or reset BGP connections, execute the following commands in user view:
18
Task
Command
Refresh the BGP connections in a
specific VPN instance.
refresh bgp vpn-instance vpn-instance-name { ip-address | all |
external | group group-name } { export | import }
Reset BGP connections of a VPN
instance.
reset bgp vpn-instance vpn-instance-name { as-number |
ip-address | all | external | group group-name }
Displaying and maintaining MCE
Task
Command
Remarks
Display information about the
routing table associated with a
VPN instance.
display ip routing-table vpn-instance
vpn-instance-name [ verbose ] [ | { begin
| exclude | include } regular-expression ]
Available in any view.
Display information about a
specific VPN instance or all VPN
instances.
display ip vpn-instance
[ instance-name vpn-instance-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about the FIB
of a VPN instance.
display fib vpn-instance
vpn-instance-name [ acl acl-number |
ip-prefix ip-prefix-name ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about the FIB
of a VPN instance that matches
the specified destination IP
address.
display fib vpn-instance
vpn-instance-name ip-address [ mask |
mask-length ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about a
specific peer group or all BGP
VPNv4 peer groups.
display bgp vpnv4 vpn-instance
vpn-instance-name group [ group-name ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display information about BGP
VPNv4 routes injected into a
specific VPN instance or all VPN
instances.
display bgp vpnv4 vpn-instance
vpn-instance-name network [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display BGP VPNv4 AS path
information.
display bgp vpnv4 vpn-instance
vpn-instance-name paths
[ as-regular-expression | { | { begin |
exclude | include } regular-expression } ]
Available in any view.
Display information about BGP
VPNv4 peers.
display bgp vpnv4 vpn-instance
vpn-instance-name peer [ group-name
log-info | ip-address { log-info |
verbose } | verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
19
Task
Command
Remarks
Display the BGP VPNv4 routing
information for a specific 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-advertise |
no-export | no-export-subconfed ] *
[ whole-match ] | community-list
{ basic-community-list-number
[ whole-match ] |
adv-community-list-number }&<1-16> |
dampened | dampening parameter |
different-origin-as | flap-info
[ network-address [ { mask | mask-length }
[ longer-match ] ] | as-path-acl
as-path-acl-number ] | peer ip-address
{ advertised-routes | received-routes } |
statistic ] [ | { begin | exclude | include }
regular-expression | [ flap-info ]
regular-expression
as-regular-expression ]
Available in any view.
Clear the route flap dampening
information for a VPN instance.
reset bgp vpn-instance
vpn-instance-name dampening
[ network-address [ mask | mask-length ]
Available in user view.
reset bgp vpn-instance
vpn-instance-name ip-address flap-info
Clear route flap history
information about a BGP peer of a
VPN instance.
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, see Layer 3—IP Routing Command
Reference.
Configuration examples
Using OSPF to advertise VPN routes to the PE
Network requirements
As shown in Figure 6, the MCE is connected to VPN 1 through VLAN-interface 10 and to VPN 2
through VLAN-interface 20. RIP runs in VPN 2.
Configure the MCE to separate routes from different VPNs and advertise the VPN routes to PE 1
through OSPF.
20
Figure 6 Network diagram
Configuration procedure
Assume that the system name of the MCE device is MCE, the system names of the edge devices of
VPN 1 and VPN 2 are VR1 and VR2, respectively, and the system name of PE 1 is PE1.
1.
Configure the VPN instances on the MCE and PE 1:
# On the MCE, configure VPN instances vpn1 and vpn2, and specify an RD and route targets
for each VPN instance.
<MCE> system-view
[MCE] ip vpn-instance vpn1
[MCE-vpn-instance-vpn1] route-distinguisher 10:1
[MCE-vpn-instance-vpn1] vpn-target 10:1
[MCE-vpn-instance-vpn1] quit
[MCE] ip vpn-instance vpn2
[MCE-vpn-instance-vpn2] route-distinguisher 20:1
[MCE-vpn-instance-vpn2] vpn-target 20:1
[MCE-vpn-instance-vpn2] quit
# Create VLAN 10, add port GigabitEthernet 1/0/1 to VLAN 10, and create VLAN-interface 10.
[MCE] vlan 10
[MCE-vlan10] port gigabitethernet 1/0/1
[MCE-vlan10] quit
[MCE] interface vlan-interface 10
# Bind VLAN-interface 10 to VPN instance vpn1, and configure an IP address for
VLAN-interface 10.
[MCE-Vlan-interface10] ip binding vpn-instance vpn1
[MCE-Vlan-interface10] ip address 10.214.10.3 24
21
# Configure VLAN 20, add port GigabitEthernet 1/0/2 to VLAN 20, bind VLAN-interface 20 to
VPN instance vpn2, and specify an IP address for VLAN-interface 20.
[MCE-Vlan-interface10] quit
[MCE] vlan 20
[MCE-vlan20] port gigabitethernet 1/0/2
[MCE-vlan20] quit
[MCE] interface vlan-interface 20
[MCE-Vlan-interface20] ip binding vpn-instance vpn2
[MCE-Vlan-interface20] ip address 10.214.20.3 24
[MCE-Vlan-interface20] quit
# On PE 1, configure VPN instances vpn1 and vpn2, and specify an RD and route targets for
each VPN instance.
<PE1> system-view
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 30:1
[PE1-vpn-instance-vpn1] vpn-target 10:1
[PE1-vpn-instance-vpn1] quit
[PE1] ip vpn-instance vpn2
[PE1-vpn-instance-vpn2] route-distinguisher 40:1
[PE1-vpn-instance-vpn2] vpn-target 20:1
[PE1-vpn-instance-vpn2] quit
2.
Configure routing between the MCE and VPN sites:
The MCE is connected to VPN 1 directly, and no routing protocol is enabled in VPN 1.
Therefore, you can configure static routes.
# On VR 1, assign IP address 10.214.10.2/24 to the interface connected to MCE and
192.168.0.1/24 to the interface connected to VPN 1. Add ports to VLANs correctly. (Details not
shown.)
# On VR 1, configure a default route with the next hop as 10.214.10.3.
<VR1> system-view
[VR1] ip route-static 0.0.0.0 0.0.0.0 10.214.10.3
# On the MCE, configure a static route to 192.168.0.0/24, specify the next hop as 10.214.10.2,
and bind the static route to VPN instance vpn1.
[MCE] ip route-static vpn-instance vpn1 192.168.0.0 24 10.214.10.2
# On the MCE, display the routing information maintained for VPN instance vpn1.
[MCE] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 5
Routes : 5
Destination/Mask
Proto
Cost
NextHop
Interface
10.214.10.0/24
Direct 0
Pre
0
10.214.10.3
Vlan10
10.214.10.3/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
192.168.0.0/24
Static 60
0
10.214.10.2
Vlan10
The output shows that the MCE has a static route for VPN instance vpn1.
# Run RIP in VPN 2. Create RIP process 20 and bind it to VPN instance vpn2 on the MCE, so
that the MCE can learn the routes of VPN 2 and add them to the routing table of the VPN
instance vpn2.
[MCE] rip 20 vpn-instance vpn2
# Advertise subnet 10.214.20.0.
22
[MCE-rip-20] network 10.214.20.0
[MCE-rip-20] quit
# On VR 2, assign IP address 10.214.20.2/24 to the interface connected to MCE and
192.168.10.1/24 to the interface connected to VPN 2. (Details not shown.)
# Configure RIP, and advertise subnets 192.168.10.0 and 10.214.20.0.
<VR2> system-view
[VR2] rip 20
[VR2-rip-20] network 192.168.10.0
[VR2-rip-20] network 10.214.20.0
# On the MCE, display the routing information maintained for VPN instance vpn2.
[MCE] display ip routing-table vpn-instance vpn2
Routing Tables: vpn2
Destinations : 5
Destination/Mask
Proto
10.214.20.0/24
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
10.214.20.3
Vlan20
10.214.20.3/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
192.168.10.0/24
RIP
1
10.214.20.2
Vlan20
100
The output shows that the MCE has learned the private routes of VPN 2. The MCE maintains
the routes of VPN 1 and those of VPN2 in two different routing tables. In this way, routes from
different VPNs are separated.
3.
Configure routing between the MCE and PE 1:
# The MCE uses port GigabitEthernet 1/0/3 to connect to the PE's port GigabitEthernet 1/0/1.
Configure the two ports as trunk ports, and configure them to permit packets carrying VLAN
tags 30 and 40 to pass.
[MCE] interface gigabitethernet 1/0/3
[MCE-GigabitEthernet1/0/3] port link-type trunk
[MCE-GigabitEthernet1/0/3] port trunk permit vlan 30 40
[MCE-GigabitEthernet1/0/3] quit
# Configure port GigabitEthernet1/0/1 on the PE.
[PE1] interface gigabitethernet 1/0/1
[PE1-GigabitEthernet1/0/1] port link-type trunk
[PE1-GigabitEthernet1/0/1] port trunk permit vlan 30 40
[PE1-GigabitEthernet1/0/1] quit
# On the MCE, create VLAN 30 and VLAN-interface 30, bind the VLAN interface to VPN
instance vpn1, and configure an IP address for the VLAN interface.
[MCE] vlan 30
[MCE-vlan30] quit
[MCE] interface vlan-interface 30
[MCE-Vlan-interface30] ip binding vpn-instance vpn1
[MCE-Vlan-interface30] ip address 30.1.1.1 24
[MCE-Vlan-interface30] quit
# On the MCE, create VLAN 40 and VLAN-interface 40, bind the VLAN interface to VPN
instance vpn2, and configure an IP address for the VLAN interface.
[MCE] vlan 40
[MCE-vlan40] quit
23
[MCE] interface vlan-interface 40
[MCE-Vlan-interface40] ip binding vpn-instance vpn2
[MCE-Vlan-interface40] ip address 40.1.1.1 24
[MCE-Vlan-interface40] quit
# On PE 1, create VLAN 30 and VLAN-interface 30, bind the VLAN interface to VPN instance
vpn1, and configure an IP address for the VLAN interface.
[PE1] vlan 30
[PE1-vlan30] quit
[PE1] interface vlan-interface 30
[PE1-Vlan-interface30] ip binding vpn-instance vpn1
[PE1-Vlan-interface30] ip address 30.1.1.2 24
[PE1-Vlan-interface30] quit
# On PE 1, create VLAN 40 and VLAN-interface 40, bind the VLAN interface to VPN instance
vpn2, and configure an IP address for the VLAN interface.
[PE1] vlan 40
[PE1-vlan40] quit
[PE1] interface vlan-interface 40
[PE1-Vlan-interface40] ip binding vpn-instance vpn2
[PE1-Vlan-interface40] ip address 40.1.1.2 24
[PE1-Vlan-interface40] quit
# Configure the IP address of the interface Loopback0 as 101.101.10.1 for the MCE and as
100.100.10.1 for PE 1. Specify the loopback interface address as the router ID for the MCE and
PE 1. (Details not shown.)
# Enable OSPF process 10 on the MCE, bind the process to VPN instance vpn1, and set the
domain ID to 10.
[MCE] ospf 10 router-id 101.101.10.1 vpn-instance vpn1
[MCE-ospf-10] vpn-instance-capability simple
[MCE-ospf-10] domain-id 10
# On the MCE, advertise subnet 30.1.1.0 in area 0, and redistribute the static route of VPN 1.
[MCE-ospf-10] area 0
[MCE-ospf-10-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[MCE-ospf-10-area-0.0.0.0] quit
[MCE-ospf-10] import-route static
# On PE 1, start OSPF process 10, bind the process to VPN instance vpn1, set the domain ID
to 10, and advertise subnet 30.1.1.0 in area 0.
[PE1] ospf 10 router-id 100.100.10.1 vpn-instance vpn1
[PE1-ospf-10] domain-id 10
[PE1-ospf-10] area 0
[PE1-ospf-10-area-0.0.0.0] network 30.1.1.0 0.0.0.255
[PE1-ospf-10-area-0.0.0.0] quit
[PE1-ospf-10] quit
# On PE 1, display the routing table of VPN1.
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 5
Routes : 5
Destination/Mask
Proto
Cost
NextHop
Interface
30.1.1.0/24
Direct 0
Pre
0
30.1.1.2
Vlan30
30.1.1.2/32
Direct 0
0
127.0.0.1
InLoop0
127.0.0.0/8
Direct 0
0
127.0.0.1
InLoop0
24
127.0.0.1/32
Direct 0
0
127.0.0.1
InLoop0
192.168.0.0/24
O_ASE
1
30.1.1.1
Vlan30
150
The output shows that the static route of VPN 1 has been redistributed to the OSPF routing
table of PE 1.
Perform similar procedures to configure OSPF process 20 between MCE and PE 1, and
redistribute VPN 2's routing information from RIP into the OSPF routing table of MCE. The
following output shows that PE 1 has learned the private route of VPN 2 through OSPF.
<PE1> display ip routing-table vpn-instance vpn2
Routing Tables: vpn2
Destinations : 5
Destination/Mask
Proto
40.1.1.0/24
40.1.1.2/32
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
40.1.1.2
Vlan40
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
192.168.10.0/24
O_ASE
1
40.1.1.1
Vlan40
150
Now, the routing information for the two VPNs has been redistributed into the routing tables on
PE 1.
Using BGP to advertise VPN routes to the PE
Network requirements
As shown in Figure 7, use an Ethernet switch as the MCE device. Advertise the VPN routes in site 1
and site 2 to PE 1, so that a VPN's sites across the MPLS backbone network can communicate with
each other correctly.
Use OSPF in both site 1 and site 2. Use EBGP between the MCE and PE 1.
25
Figure 7 Network diagram
Configuration procedure
1.
Configure VPN instances:
Create VPN instances on the MCE and PE 1, and bind the VPN instances to VLAN interfaces.
For the configuration procedure, see "Using OSPF to advertise VPN routes to the PE."
2.
Configure routing between the MCE and VPN sites:
# Start an OSPF process on the devices in the two VPNs and advertise the subnets. (Details
not shown.)
# Configure OSPF on the MCE, and bind OSPF process 10 to VPN instance vpn1 to learn the
routes of VPN 1.
<MCE> system-view
[MCE] ospf router-id 10.214.10.3 10 vpn-instance vpn1
[MCE-ospf-10] area 0
[MCE-ospf-10-area-0.0.0.0] network 10.214.10.0 0.0.0.255
# Display the routing table of VPN 1 on the MCE.
[MCE-ospf-10-area-0.0.0.0] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 5
Destination/Mask
Proto
10.214.10.0/24
10.214.10.3/32
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
10.214.10.3
Vlan10
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
26
192.168.0.0/24
OSPF
10
1
10.214.10.2
Vlan10
The output shows that the MCE has learned the private route of VPN 1 through OSPF process
10.
# On MCE, bind OSPF process 20 to VPN instance vpn2 to learn the routes of VPN 2. The
configuration procedure is similar to that for OSPF process 10.
The following output shows that the MCE has learned the private route of VPN 2 through OSPF:
[MCE] display ip routing-table vpn-instance vpn2
Routing Tables: vpn2
Destinations : 5
3.
Destination/Mask
Proto
10.214.20.0/24
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
10.214.20.3
Vlan20
10.214.20.3/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
192.168.0.0/24
OSPF
1
10.214.20.2
Vlan20
10
Configure routing between the MCE and PE 1:
# Configure the connecting ports between the MCE and PE 1 as trunk ports. The configuration
procedure is similar to that described in "Using OSPF to advertise VPN routes to the PE."
(Details not shown.)
# Start BGP process 100 on the MCE, and enter the IPv4 address family view of VPN instance
vpn1.
[MCE] bgp 100
[MCE-bgp] ipv4-family vpn-instance vpn1
# Specify PE 1 as the EBGP peer of the MCE, and redistribute the routing information for OSPF
process 10. (The IP address of PE 1's interface bound with VPN instance vpn1 is 10.100.10.3,
and the BGP process is 200.)
[MCE-bgp-vpn1] peer 30.1.1.2 as-number 200
[MCE-BGP-vpn1] import-route ospf 10
# On PE 1, configure BGP process 200 and specify the MCE as its EBGP peer.
<PE1> system-view
[PE1] bgp 200
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] peer 30.1.1.1 as-number 100
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# On PE 1, display the routing information for VPN instance vpn1.
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 5
Destination/Mask
Proto
30.1.1.0/24
30.1.1.2/32
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
30.1.1.2
Vlan30
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
192.168.0.0/24
BGP
2
30.1.1.1
Vlan30
255
27
# Perform similar configuration on the MCE and PE 1 for VPN 2. Redistribute the OSPF routes
of VPN instance vpn2 into the EBGP routing table. (Details not shown.)
The following output shows that PE 1 has learned the private route of VPN 2 through BGP:
[PE1] display ip routing-table vpn-instance vpn2
Routing Tables: vpn2
Destinations : 5
Destination/Mask
Proto
40.1.1.0/24
40.1.1.2/32
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
40.1.1.2
Vlan40
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
192.168.10.0/24
BGP
2
40.1.1.1
Vlan40
255
Now, the MCE has redistributed the OSPF routes of the two VPN instances into the EBGP
routing tables of PE 1.
Using tunnels to advertise VPN routes
Network requirements
As shown in Figure 8, MCE 1 and MCE 2 communicate with each other through GRE tunnels, and
both are connected to sites of VPN 1 and VPN 2. The sites of VPN 1 use routing protocol OSPF and
reside in the backbone area, that is, area 0. The two sites of VPN 2 use RIP and OSPF, respectively,
and the OSPF area 0 is used.
Configure MCE 1 and MCE 2 to correctly advertise routing information for the two VPNs.
Figure 8 Network diagram
Configuration considerations
As shown in Figure 8, because a GRE tunnel is configured for each VPN to transmit data and routing
information for the VPN, you can create a VPN instance for each VPN and bind the VPN instances to
specific interfaces (the tunnel interfaces and interfaces connected to the VPN sites). In this way the
current network is simplified into two separate topologies, as shown in Figure 9 and Figure 10. Thus,
MCEs advertise routes of different VPNs through different paths.
For VPN 1, advertise interface addresses on the two MCEs in area 0, making the entire VPN a single
OSPF domain. For VPN 2, advertise interface addresses for RIP and OSPF calculations, and in
addition, redistribute OSPF routes to RIP and RIP routes to OSPF on MCE 1.
28
Figure 9 Network topology of VPN 1 with the MCEs
Figure 10 Network topology of VPN 2 with the MCEs
Configuration procedure
1.
Configure MCE 1:
# Create VLAN 100 and VLAN 101, configure GigabitEthernet 1/0/15 as a trunk port, and add it
to the two VLANs.
<MCE1> system-view
[MCE1] vlan 100 to 101
[MCE1] interface GigabitEthernet 1/0/15
[MCE1-GigabitEthernet1/0/15] port link-type trunk
[MCE1-GigabitEthernet1/0/15] port trunk permit vlan 100 101
[MCE1-GigabitEthernet1/0/15] quit
# Create VLAN interfaces, and configure IP addresses for them.
[MCE1] interface vlan-interface 100
[MCE1-Vlan-interface100] ip address 192.168.1.1 255.255.255.0
[MCE1-Vlan-interface100] quit
[MCE1] interface vlan-interface 101
[MCE1-Vlan-interface101] ip address 192.168.2.1 255.255.255.0
[MCE1-Vlan-interface101] quit
# Create tunnel interface Tunnel0.
[MCE1] interface tunnel 0
# Configure an IP address for the tunnel interface Tunnel0.
[MCE1-Tunnel0] ip address 10.1.1.1 255.255.255.0
# Specify the tunnel protocol as GRE.
[MCE1-Tunnel0] tunnel-protocol gre
# Specify the source address of the tunnel.
[MCE1-Tunnel0] source vlan-interface 100
# Specify the destination address of the tunnel.
[MCE1-Tunnel0] destination 172.16.1.1
[MCE1-Tunnel0] quit
29
# Create loopback group 1 and specify the service type as tunnel.
[MCE1] service-loopback group 1 type tunnel
# Add any unused port (GigabitEthernet 1/0/3 in this example) to loopback group 1.
[MCE1] interface GigabitEthernet 1/0/3
[MCE1-GigabitEthernet1/0/3] undo stp enable
[MCE1-GigabitEthernet1/0/3] port service-loopback group 1
# Reference the loopback group on the tunnel interface.
[MCE1-GigabitEthernet1/0/3] quit
[MCE1] interface tunnel 0
[MCE1-Tunnel0] service-loopback-group 1
[MCE1-Tunnel0] quit
# Create the tunnel interface Tunnel1.
[MCE1] interface tunnel 1
# Configure an IP address for the tunnel interface Tunnel1.
[MCE1-Tunnel1] ip address 10.1.2.1 255.255.255.0
# Specify the tunnel protocol as GRE.
[MCE1-Tunnel1] tunnel-protocol gre
# Specify the source address of the tunnel.
[MCE1-Tunnel1] source vlan-interface 101
# Specify the destination address of the tunnel.
[MCE1-Tunnel1] destination 172.16.2.1
# Reference loopback group 1 on the tunnel interface.
[MCE1-Tunnel1] service-loopback-group 1
[MCE1-Tunnel1] quit
2.
Configure MCE 2:
# Create VLAN 100 and VLAN 101, configure GigabitEthernet 1/0/25 as a trunk port, and add it
to the two VLANs.
<MCE2> system-view
[MCE2] vlan 100 to 101
[MCE2] interface GigabitEthernet 1/0/25
[MCE2-GigabitEthernet1/0/25] port link-type trunk
[MCE2-GigabitEthernet1/0/25] port trunk permit vlan 100 101
[MCE2-GigabitEthernet1/0/25] quit
# Create VLAN interfaces, and configure IP addresses for them.
[MCE2] interface vlan-interface 100
[MCE2-Vlan-interface100] ip address 172.16.1.1 255.255.255.0
[MCE2-Vlan-interface100] quit
[MCE2] interface vlan-interface 101
[MCE2-Vlan-interface101] ip address 172.16.2.1 255.255.255.0
[MCE2-Vlan-interface101] quit
# Create the tunnel interface Tunnel0.
[MCE2] interface tunnel 0
# Configure an IP address for the Tunnel0 interface.
[MCE2-Tunnel0] ip address 10.1.1.2 255.255.255.0
# Specify the tunnel protocol as GRE.
[MCE2-Tunnel0] tunnel-protocol gre
# Specify the source address of the tunnel.
30
[MCE2-Tunnel0] source vlan-interface 100
# Specify the destination address of the tunnel.
[MCE2-Tunnel0] destination 192.168.1.1
[MCE2-Tunnel0] quit
# Create loopback group 1 and specify its service type as tunnel.
[MCE2] service-loopback group 1 type tunnel
# Add any unused port (GigabitEthernet 1/0/3 in this example) to loopback group 1.
[MCE2] interface GigabitEthernet 1/0/3
[MCE2-GigabitEthernet1/0/3] undo stp enable
[MCE2-GigabitEthernet1/0/3] port service-loopback group 1
# Reference loopback group 1 on the tunnel interface.
[MCE2-GigabitEthernet1/0/3] quit
[MCE2] interface tunnel 0
[MCE2-Tunnel0] service-loopback-group 1
[MCE2-Tunnel0] quit
# Create the tunnel interface Tunnel1.
[MCE2] interface tunnel 1
# Configure an IP address for the Tunnel 1 interface.
[MCE2-Tunnel1] ip address 10.1.2.2 255.255.255.0
# Specify the tunnel protocol as GRE.
[MCE2-Tunnel1] tunnel-protocol gre
# Specify the source address of the tunnel.
[MCE2-Tunnel1] source vlan-interface 101
# Specify the destination address of the tunnel.
[MCE2-Tunnel1] destination 192.168.2.1
# Reference loopback group 1 on the tunnel interface.
[MCE2-Tunnel1] service-loopback-group 1
3.
Configure VPN instances on MCE 1:
# Create VPN instance vpn1 for VPN 1, and configure an RD for it.
<MCE1> system-view
[MCE1] ip vpn-instance vpn1
[MCE1-vpn-instance-vpn1] route-distinguisher 1:2
[MCE1-vpn-instance-vpn1] vpn-target 1:2
[MCE1-vpn-instance-vpn1] quit
# Create VPN instance vpn2 for VPN 2, and configure an RD for it.
[MCE1] ip vpn-instance vpn2
[MCE1-vpn-instance-vpn2] route-distinguisher 1:3
[MCE1-vpn-instance-vpn2] vpn-target 1:3
[MCE1-vpn-instance-vpn2] quit
# Bind VLAN-interface 10 and Tunnel0 to VPN instance vpn1, and configure IP addresses for
the VLAN interface and tunnel interface.
[MCE1] vlan 10
[MCE1-vlan10] port gigabitethernet 1/0/10
[MCE1-vlan10] quit
[MCE1] interface vlan-interface 10
[MCE1-Vlan-interface10] ip binding vpn-instance vpn1
[MCE1-Vlan-interface10] ip address 10.214.10.1 24
31
[MCE1-Vlan-interface10] quit
[MCE1] interface tunnel 0
[MCE1-Tunnel0] ip binding vpn-instance vpn1
[MCE1-Tunnel0] ip address 10.1.1.1 24
# Bind VLAN-interface 11 and Tunnel1 to VPN instance vpn2, and configure IP addresses for
the VLAN interface and tunnel interface.
[MCE1] vlan 11
[MCE1-vlan11] port gigabitethernet 1/0/11
[MCE1-vlan11] quit
[MCE1] interface vlan-interface 11
[MCE1-Vlan-interface11] ip binding vpn-instance vpn2
[MCE1-Vlan-interface11] ip address 10.214.20.1 24
[MCE1-Vlan-interface11] quit
[MCE1] interface tunnel 1
[MCE1-Tunnel1] ip binding vpn-instance vpn2
[MCE1-Tunnel1] ip address 10.1.2.1 24
[MCE1-Tunnel1] quit
4.
Configure VPN instances on MCE 2:
# Create VPN instance vpn1 for VPN 1, and configure the same RD as that configured on MCE
1 for the VPN instance.
<MCE2> system-view
[MCE2] ip vpn-instance vpn1
[MCE2-vpn-instance-vpn1] route-distinguisher 1:2
[MCE2-vpn-instance-vpn1] vpn-target 1:2
[MCE2-vpn-instance-vpn1] quit
# Create VPN instance vpn2 for VPN 2, and configure the same RD as that configured on MCE
1 for the VPN instance.
[MCE2] ip vpn-instance vpn2
[MCE2-vpn-instance-vpn2] route-distinguisher 1:3
[MCE2-vpn-instance-vpn2] vpn-target 1:3
[MCE2-vpn-instance-vpn2] quit
# Bind VLAN-interface 20 and Tunnel 0 to VPN instance vpn1, and configure IP addresses for
the VLAN interface and tunnel interface.
[MCE2] vlan 20
[MCE2-vlan20] port gigabitethernet 1/0/20
[MCE2-vlan20] quit
[MCE2] interface vlan-interface 20
[MCE2-Vlan-interface20] ip binding vpn-instance vpn1
[MCE2-Vlan-interface20] ip address 10.214.30.1 24
[MCE2-Vlan-interface20] quit
[MCE2] interface tunnel 0
[MCE2-Tunnel0] ip binding vpn-instance vpn1
[MCE2-Tunnel0] ip address 10.1.1.2 24
# Bind VLAN-interface 21 and Tunnel 1 to VPN instance vpn2, and configure IP addresses for
the VLAN interface and tunnel interface.
[MCE2] vlan 21
[MCE2-vlan21] port gigabitethernet 1/0/21
[MCE2-vlan21] quit
[MCE2] interface vlan-interface 21
32
[MCE2-Vlan-interface21] ip binding vpn-instance vpn2
[MCE2-Vlan-interface21] ip address 10.214.40.1 24
[MCE2-Vlan-interface21] quit
[MCE2] interface tunnel 1
[MCE2-Tunnel1] ip binding vpn-instance vpn2
[MCE2-Tunnel1] ip address 10.1.2.2 24
[MCE2-Tunnel1] quit
5.
Advertise routes of VPN 1:
# On MCE 1, configure OSPF process 1 for VPN instance vpn1, and configure OSPF to
support MCE. Be sure to configure the same OSPF area as that configured at site 1 of VPN 1,
area 0 in this example.
[MCE1] ospf 1 vpn-instance vpn1 router-id 192.168.1.1
[MCE1-ospf-1] vpn-instance-capability simple
[MCE1-ospf-1] area 0
[MCE1-ospf-1-area-0.0.0.0]
# Advertise the addresses of interfaces VLAN-interface 10 and Tunnel 0 on MCE 1.
[MCE1-ospf-1-area-0.0.0.0] network 10.214.10.1 0.0.0.255
[MCE1-ospf-1-area-0.0.0.0] network 10.1.1.1 0.0.0.255
# On MCE 2, configure OSPF process 1 for VPN instance vpn1, and configure OSPF to
support MCE.
[MCE2] ospf 1 vpn-instance vpn1 router-id 172.16.1.1
[MCE2-ospf-1] vpn-instance-capability simple
[MCE2-ospf-1] area 0
[MCE2-ospf-1-area-0.0.0.0]
# Advertise addresses of interfaces VLAN-interface 20 and Tunnel 0 on MCE 2.
[MCE2-ospf-1-area-0.0.0.0] network 10.214.30.1 0.0.0.255
[MCE2-ospf-1-area-0.0.0.0] network 10.1.1.2 0.0.0.255
6.
Advertise routes of VPN 2:
# On MCE 1, configure OSPF process 2 for VPN instance vpn2, and configure OSPF to
support MCE. Be sure to configure the same OSPF area as that configured at site 2 of VPN 2,
area 0 in this example.
[MCE1] ospf 2 vpn-instance vpn2 router-id 192.168.2.1
[MCE1-ospf-2] vpn-instance-capability simple
[MCE1-ospf-2] area 0
[MCE1-ospf-2-area-0.0.0.0]
# Advertise the address of tunnel interface Tunnel 1.
[MCE1-ospf-2-area-0.0.0.0] network 10.1.2.1 0.0.0.255
# Configure RIP process 1 for VPN instance vpn2.
[MCE1] rip 1 vpn-instance vpn2
[MCE1-rip-1]
# Advertise the IP address of VLAN-interface 11.
[MCE1-rip-1] network 10.214.20.1
# Redistribute routes learned by OSPF process 2 to RIP process 1.
[MCE1-rip-1] import-route ospf 2
[MCE1-rip-1] quit
# Redistribute routes learned by RIP process 1 to OSPF process 2.
[MCE1] ospf 2
[MCE1-ospf-2] import-route rip 1
33
# On MCE 2, configure OSPF process 2 for VPN instance vpn2, and configure OSPF to
support MCE. Be sure to configure the same OSPF area as that configured at site 2 of VPN 2,
area 0 in this example.
[MCE2] ospf 2 vpn-instance vpn2 router-id 172.16.2.1
[MCE2-ospf-2] vpn-instance-capability simple
[MCE2-ospf-2] area 0
[MCE2-ospf-2-area-0.0.0.0]
# Advertise the addresses of interfaces VLAN-interface 21 and Tunnel 1 on MCE 2.
[MCE2-ospf-2-area-0.0.0.0] network 10.214.40.1 0.0.0.255
[MCE2-ospf-2-area-0.0.0.0] network 10.1.2.2 0.0.0.255
34
Configuring IPv6 MCE
This chapter describes how to configure the IPv6 MCE function.
Overview
In an IPv6 MPLS L3VPN, an IPv6 MCE advertises IPv6 routing information between the VPN site
and the connected PE and forwards IPv6 packets. An IPv6 MCE operates in the same way as an
IPv4 MCE. For more information, see "Configuring MCE."
Configuring VPN instances
By configuring VPN instances, you isolate not only VPN routes from public network routes, but also
routes of a VPN from those of another VPN.
Creating a VPN instance
A VPN instance is associated with a site. It is a collection of the VPN membership and routing rules of
its associated site. A VPN instance does not necessarily correspond to one VPN.
A VPN instance takes effect only after you configure an RD for it.
You can configure a description for a VPN instance to record its related information, such as its
relationship with a certain VPN.
To create and configure a VPN instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a VPN instance and
enter VPN instance view.
ip vpn-instance vpn-instance-name
N/A
3.
Configure an RD for the VPN
instance.
route-distinguisher
route-distinguisher
N/A
4.
Configure a description for the
VPN instance.
description text
Optional.
Associating a VPN instance with an interface
After you create and configure a VPN instance, you must associate the VPN instance with the
interfaces connected to the VPN sites and PE.
To associate a VPN instance with an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
35
Step
Command
Remarks
By default, no VPN instance is
associated with an interface.
3.
Associate a VPN instance
with the interface.
ip binding vpn-instance
vpn-instance-name
Associating an interface with a
VPN instance clears the IPv6
address of the interface.
Therefore, you must reconfigure
the IPv6 address of the interface
after executing this command.
Configuring route related attributes for a VPN instance
The control process of VPN route advertisement is as follows:
•
When a VPN route learned from a VPN site gets redistributed into BGP, BGP associates it with
a route target extended community attribute list, which is usually the export target attribute of
the VPN instance associated with the site.
•
The VPN instance determines which routes it can accept and redistribute according to the
import-extcommunity in the route target.
•
The VPN instance determines how to change the route targets attributes for routes to be
advertised according to the export-extcommunity in the route target.
IMPORTANT:
Create a routing policy before associating it with a VPN instance. Otherwise, the device cannot filter
the routes to be received and advertised.
To configure route related attributes for a VPN instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VPN instance view.
ip vpn-instance
vpn-instance-name
N/A
3.
Enter IPv6 VPN view.
ipv6-family
Optional.
Configure route targets.
vpn-target vpn-target&<1-8>
[ both | export-extcommunity |
import-extcommunity ]
A single vpn-target command
can configure up to eight route
targets. You can configure up to
64 route targets for a VPN
instance.
4.
Optional.
5.
Set the maximum number of
routes supported.
6.
Apply an import routing
policy.
import route-policy route-policy
7.
Apply an export routing
policy.
export route-policy route-policy
routing-table limit number
{ warn-threshold | simply-alert }
Setting the maximum number of
routes for a VPN instance to
support is for preventing too many
routes from being redistributed
into the PE.
Optional.
By default, all routes matching the
import target attribute are
accepted.
Optional.
36
By default, routes to be advertised
are not filtered.
NOTE:
• Route related attributes configured in VPN instance view are applicable to both IPv4 VPNs and
IPv6 VPNs.
• You can configure route related attributes for IPv6 VPNs in both VPN instance view and IPv6
VPN view. Those configured in IPv6 VPN view take precedence.
Configuring routing on an IPv6 MCE
An IPv6 MCE implements service isolation through route isolation. IPv6 MCE routing configuration
includes:
•
IPv6 MCE-VPN site routing configuration
•
IPv6 MCE-PE routing configuration
On the PE in an IPv6 MCE network environment, disable routing loop detection to avoid route loss
during route calculation and disable route redistribution between routing protocols to save system
resources.
Before you configure routing on an IPv6 MCE, complete the following tasks:
•
On the IPv6 MCE, configure VPN instances, and bind the VPN instances to the interfaces
connected to the VPN sites and those connected to the PE.
•
Configure the link layer and network layer protocols on related interfaces to ensure IP
connectivity.
Configuring routing between IPv6 MCE and VPN site
You can configure IPv6 static routing, RIPng, OSPFv3, IPv6 IS-IS, or EBGP between the MCE and a
VPN site.
Configuring static routing between IPv6 MCE and VPN site
An IPv6 MCE can reach a VPN site through an IPv6 static route. IPv6 static routing on a traditional
CE is globally effective and thus does not support address overlapping among VPNs. An IPv6 MCE
supports binding an IPv6 static route to an IPv6 VPN instance, so that the IPv6 static routes of
different IPv6 VPN instances can be isolated from each other.
To configure IPv6 static routing between IPv6 MCE and VPN site:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
37
Step
Command
•
2.
Configure an IPv6 static
route for an IPv6 VPN
instance.
•
Remarks
ipv6 route-static ipv6-address
prefix-length { interface-type
interface-number [ next-hop-address ] |
next-hop-address | vpn-instance
d-vpn-instance-name nexthop-address }
[ preference preference-value ] [ tag
tag-value ] [ description
description-text ]
ipv6 route-static vpn-instance
s-vpn-instance-name&<1-6>
ipv6-address prefix-length
{ interface-type interface-number
[ next-hop-address ] | nexthop-address
[ public ] | vpn-instance
d-vpn-instance-name nexthop-address }
[ preference preference-value ] [ tag
tag-value ] [ description
description-text ]
Use either command.
Perform this
configuration on the
IPv6 MCE. On a VPN
site, configure normal
IPv6 static routes.
Configuring RIPng between IPv6 MCE and VPN site
A RIPng process belongs to the public network or a single IPv6 VPN instance. If you create a RIPng
process without binding it to an IPv6 VPN instance, the process belongs to the public network. By
configuring RIPng process-to-IPv6 VPN instance bindings on an IPv6 MCE, you allow routes of
different VPNs to be exchanged between the IPv6 MCE and the sites through different RIPng
processes, ensuring the separation and security of IPv6 VPN routes.
For more information about RIPng, see Layer 3—IP Routing Configuration Guide.
To configure RIPng between IPv6 MCE and VPN site:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RIPng process for a
VPN instance and enter
RIPng view.
ripng [ process-id ] vpn-instance
vpn-instance-name
Perform this configuration on the
IPv6 MCE. On a VPN site,
configure normal RIPng.
3.
Redistribute remote site
routes advertised by the PE.
import-route protocol
[ process-id ] [ allow-ibgp ] [ cost
cost | route-policy
route-policy-name ] *
By default, no route of any other
routing protocol is redistributed
into RIPng.
4.
Configure the default cost
value for the redistributed
routes.
default cost value
5.
Return to system view.
quit
N/A
6.
Enter interface view.
interface interface-type
interface-number
N/A
7.
Enable RIPng on the
interface.
ripng process-id enable
Disabled by default.
Optional.
0 by default.
Configuring OSPFv3 between IPv6 MCE and VPN site
An OSPFv3 process belongs to the public network or a single IPv6 VPN instance. If you create an
OSPFv3 process without binding it to an IPv6 VPN instance, the process belongs to the public
network.
38
By configuring OSPFv3 process-to-IPv6 VPN instance bindings on an IPv6 MCE, you allow routes of
different IPv6 VPNs to be exchanged between the IPv6 MCE and the sites through different OSPFv3
processes, ensuring the separation and security of IPv6 VPN routes.
For more information about OSPFv3, see Layer 3—IP Routing Configuration Guide.
To configure OSPFv3 between IPv6 MCE and VPN site:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an OSPFv3 process
for a VPN instance and enter
OSPFv3 view.
ospfv3 [ process-id ]
vpn-instance vpn-instance-name
Perform this configuration on the
IPv6 MCE. On a VPN site,
configure normal OSPFv3.
3.
Set the router ID.
router-id router-id
N/A
4.
Redistribute remote site
routes advertised by the PE..
import-route protocol
[ process-id | allow-ibgp ] [ cost
value | route-policy
route-policy-name | type type ] *
By default, no route of any other
routing protocol is redistributed
into OSPFv3.
5.
Return to system view.
quit
N/A
6.
Enter interface view.
interface interface-type
interface-number
N/A
7.
Enable OSPFv3 on the
interface.
ospfv3 process-id area area-id
[ instance instance-id ]
By default, OSPFv3 is disabled on
an interface.
NOTE:
Deleting a VPN instance also deletes all related OSPFv3 processes.
Configuring IPv6 IS-IS between IPv6 MCE and VPN site
An IPv6 IS-IS process belongs to the public network or a single IPv6 VPN instance. If you create an
IPv6 IS-IS process without binding it to an IPv6 VPN instance, the process belongs to the public
network.
By configuring IPv6 IS-IS process-to-IPv6 VPN instance bindings on an IPv6 MCE, you allow routes
of different IPv6 VPNs to be exchanged between the IPv6 MCE and the sites through different IPv6
IS-IS processes, ensuring the separation and security of IPv6 VPN routes.
For more information about IPv6 IS-IS, see Layer 3—IP Routing Configuration Guide.
To configure IPv6 IS-IS between IPv6 MCE and VPN site:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IPv6 IS-IS
process for a VPN instance
and enter IS-IS view.
isis [ process-id ] vpn-instance
vpn-instance-name
Perform this configuration on the
IPv6 MCE. On a VPN site,
configure normal IPv6 IS-IS.
3.
Configure a network entity
title for the IS-IS process.
network-entity net
Not configured by default.
4.
Enable the IPv6 capacity for
the IPv6 IS-IS process.
ipv6 enable
Disabled by default.
39
Step
Command
Remarks
Optional.
By default, no routes from any
other routing protocol are
redistributed to IPv6 IS-IS.
Redistribute remote site
routes advertised by the PE.
ipv6 import-route protocol
[ process-id ] [ allow-ibgp ] [ cost
cost | [ level-1 | level-1-2 |
level-2 ] | route-policy
route-policy-name | tag tag ] *
6.
Return to system view.
quit
N/A
7.
Enter interface view.
interface interface-type
interface-number
N/A
8.
Enable the IPv6 IS-IS
process on the interface.
isis ipv6 enable [ process-id ]
Disabled by default.
5.
If you do not specify the route
level in the command,
redistributed routes are added to
the level-2 routing table by
default.
Configuring EBGP between IPv6 MCE and VPN site
To use EBGP for exchanging routing information between an IPv6 MCE and IPv6 VPN sites, you
must configure a BGP peer for each IPv6 VPN instance on the IPv6 MCE, and redistribute the IGP
routes of each VPN instance on the IPv6 VPN sites.
If EBGP is used for route exchange, you also can configure filtering policies to filter the received
routes and the routes to be advertised.
1.
Configure the IPv6 MCE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter IPv6 BGP-VPN
instance view.
ipv6-family vpn-instance
vpn-instance-name
N/A
4.
Specify an IPv6 BGP peer in
an AS.
peer ipv6-address as-number
as-number
N/A
5.
Redistribute remote site
routes advertised by the PE.
import-route protocol
[ process-id [ med med-value |
route-policy route-policy-name ]
*]
By default, No route redistribution
is configured.
6.
Configure a filtering policy to
filter the routes to be
advertised.
filter-policy { acl6-number |
ipv6-prefix ip-prefix-name }
export [ direct | isisv6 process-id
| ripng process-id | static ]
Optional.
7.
Configure a filtering policy to
filter the received routes.
filter-policy { acl6-number |
ipv6-prefix ip-prefix-name }
import
Optional.
By default, the IPv6 MCE does
not filter the routes to be
advertised.
By default, the IPv6 MCE does
not filter the received routes.
NOTE:
After you configure an IPv6 BGP VPN instance, the IPv6 BGP route exchange for the IPv6 VPN
instance is the same as the normal IPv6 BGP VPN route exchange. For more information about
IPv6 BGP, see Layer 3—IP Routing Configuration Guide.
2.
Configure a VPN site:
40
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter IPv6 address family
view.
ipv6-family
N/A
4.
Configure the IPv6 MCE as
the EBGP peer.
peer ipv6-address as-number
as-number
N/A
Optional.
5.
Redistribute the IGP routes
of the VPN.
import-route protocol
[ process-id [ med med-value |
route-policy route-policy-name ]
*]
By default, no route redistribution
is configured.
A VPN site must advertise the
IPv6 VPN network addresses it
can reach to the connected IPv6
MCE.
Configuring routing between IPv6 MCE and PE
IPv6 MCE-PE routing configuration includes these tasks:
•
Bind the IPv6 MCE-PE interfaces to IPv6 VPN instances
•
Perform routing configurations
•
Redistribute IPv6 VPN routes into the routing protocol running between the IPv6 MCE and the
PE.
Configuring IPv6 static routing between IPv6 MCE and PE
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
•
2.
Configure IPv6
static routes for an
IPv6 VPN instance.
•
ipv6 route-static ipv6-address prefix-length
{ interface-type interface-number
[ next-hop-address ] | next-hop-address |
vpn-instance d-vpn-instance-name
nexthop-address } [ preference preference-value ]
[ tag tag-value ] [ description description-text ]
ipv6 route-static vpn-instance
s-vpn-instance-name&<1-6> ipv6-address
prefix-length { interface-type interface-number
[ next-hop-address ] | nexthop-address [ public ] |
vpn-instance d-vpn-instance-name
nexthop-address } [ preference preference-value ]
[ tag tag-value ] [ description description-text ]
User either
command.
Configuring RIPng between IPv6 MCE and PE
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RIPng process
for an IPv6 VPN instance
and enter RIPng view.
ripng [ process-id ] vpn-instance
vpn-instance-name
N/A
41
Step
Command
Remarks
By default, no route of any
other routing protocol is
redistributed into RIPng.
3.
Redistribute the VPN
routes.
import-route protocol [ process-id ]
[ allow-ibgp ] [ cost cost | route-policy
route-policy-name ] *
4.
Configure the default cost
value for the redistributed
routes.
default cost value
5.
Return to system view.
quit
N/A
6.
Enter interface view.
interface interface-type interface-number
N/A
7.
Enable the RIPng
process on the interface.
ripng process-id enable
Disabled by default.
Optional.
0 by default.
Configuring OSPFv3 between IPv6 MCE and PE
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an OSPFv3
process for an IPv6 VPN
instance and enter
OSPFv3 view.
ospfv3 [ process-id ] vpn-instance
vpn-instance-name
N/A
3.
Set the router ID.
router-id router-id
N/A
4.
Redistribute the VPN
routes.
import-route protocol [ process-id |
allow-ibgp ] [ cost value |
route-policy route-policy-name | type
type ] *
By default, no route of any other
routing protocol is redistributed
into OSPFv3.
5.
Configure a filtering
policy to filter the
redistributed routes.
filter-policy { acl6-number |
ipv6-prefix ipv6-prefix-name } export
[ bgp4+ | direct | isisv6 process-id |
ospfv3 process-id | ripng process-id |
static ]
6.
Return to system view.
quit
N/A
7.
Enter interface view.
interface interface-type
interface-number
N/A
8.
Enable the OSPFv3
process on the interface.
ospfv3 process-id area area-id
[ instance instance-id ]
Disabled by default.
Optional.
By default, redistributed routes
are not filtered.
Configuring IPv6 IS-IS between IPv6 MCE and PE
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IS-IS
process for an IPv6
VPN instance and
enter IS-IS view.
isis [ process-id ] vpn-instance
vpn-instance-name
N/A
3.
Configure a network
entity title.
network-entity net
Not configured by default.
4.
Enable the IPv6
capacity for the IS-IS
process.
ipv6 enable
Disabled by default.
42
Step
Command
Remarks
Optional.
By default, IS-IS does not
redistribute routes of any other
routing protocol.
Redistribute the VPN
routes.
ipv6 import-route protocol
[ process-id ] [ allow-ibgp ] [ cost cost |
[ level-1 | level-1-2 | level-2 ] |
route-policy route-policy-name | tag
tag ] *
Configure a filtering
policy to filter the
advertised routes.
ipv6 filter-policy { acl6-number |
ipv6-prefix ipv6-prefix-name |
route-policy route-policy-name }
export [ protocol [ process-id ] ]
Optional.
7.
Return to system view.
quit
N/A
8.
Enter interface view.
interface interface-type
interface-number
N/A
9.
Enable IPv6 for the
IS-IS process on the
interface.
isis ipv6 enable [ process-id ]
Disabled by default.
5.
6.
If you do not specify the route
level in the command, the
command will redistribute routes
to the level-2 routing table by
default.
By default, IPv6 IS-IS does not
filter advertised routes.
Configuring EBGP between IPv6 MCE and PE
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter IPv6 BGP-VPN
instance view.
ipv6-family vpn-instance
vpn-instance-name
N/A
4.
Configure the PE as the
EBGP peer.
peer ipv6-address as-number as-number
N/A
5.
Redistribute the VPN
routes.
import-route protocol [ process-id [ med
med-value | route-policy
route-policy-name ] * ]
By default, no route
redistribution is configured.
6.
Configure a filtering
policy to filter the routes
to be advertised.
filter-policy { acl6-number | ipv6-prefix
ip-prefix-name } export [ direct | isisv6
process-id | ripng process-id | static ]
7.
Configure a filtering
policy to filter the
received routes.
filter-policy { acl6-number | ipv6-prefix
ip-prefix-name } import
Optional.
By default, BGP does not
filter the routes to be
advertised.
Optional.
By default, BGP does not
filter the received routes.
NOTE:
IPv6 BGP runs within a VPN in the same way as it runs within a public network. For more
information about IPv6 BGP, see Layer 3—IP Routing Configuration Guide.
43
Resetting IPv6 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 hard reset or soft reset BGP connections:
Task
Command
Remarks
Soft reset the IPv6 BGP
connections in a VPN instance.
refresh bgp ipv6 vpn-instance
vpn-instance-name
{ ipv6-address | all | external }
{ export | import }
Available in user view.
Hard reset the IPv6 BGP
connections of a VPN instance.
reset bgp ipv6 vpn-instance
vpn-instance-name { as-number |
ipv6-address | all | external }
Available in user view.
Displaying and maintaining IPv6 MCE
Task
Command
Remarks
Display information about a
specific or all VPN instances.
display ip vpn-instance
[ instance-name vpn-instance-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about the
IPv6 FIB of a VPN instance.
display ipv6 fib vpn-instance
vpn-instance-name [ acl6 acl6-number |
ipv6-prefix ipv6-prefix-name ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display a VPN instance's FIB
entries that match the specified
destination IPv6 address.
display ipv6 fib vpn-instance
vpn-instance-name ipv6-address
[ prefix-length ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about IPv6
BGP peers established between
the PE and CE in a VPN instance.
display bgp vpnv6 vpn-instance
vpn-instance-name peer [ ipv6-address
verbose | verbose ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display BGP VPNv6 routing
information for a VPN instance.
display bgp vpnv6 vpn-instance
vpn-instance-name routing-table
[ network-address prefix-length
[ longer-prefixes ] | peer ipv6-address
{ advertised-routes | received-routes } ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
For commands that display information about a routing table, see Layer 3—IP Routing Command
Reference.
44
IPv6 MCE configuration example
Network requirements
As shown in Figure 11, the IPv6 MCE device is connected to VPN 1 through VLAN-interface 10 and
to VPN 2 through VLAN-interface 20. RIPng is used in VPN 2.
Configure the IPv6 MCE to separate routes from different VPNs and advertise VPN routes to PE 1
through OSPFv3.
Figure 11 Network diagram
VPN 2
Site 1
PE 2
CE
PE 1
GE1/0/1
Vlan-int30: 30::2/64
Vlan-int40: 40::2/64
VPN 1
2012:1::/64 Vlan-int11
2012:1::2/64
VR 1
Vlan-int10
2001:1::2/64
GE1/0/1
Vlan-int10
2001:1::1/64
MCE
GE1/0/3
Vlan-int30: 30::1/64
Vlan-int40: 40::1/64
GE1/0/2
Vlan-int20
2002:1::1/64
PE 3
CE
VPN 1
Site 2
Vlan-int20
2002:1::2/64
VR 2
Vlan-int21
2012::2/64
VPN 2
2012::/64
Configuration procedure
Assume that the system name of the IPv6 MCE device is MCE, the system names of the edge
devices of VPN 1 and VPN 2 are VR1 and VR2, respectively, and the system name of PE 1 is PE1.
1.
Configure the VPN instances on the MCE and PE 1:
# On the MCE, configure VPN instances vpn1 and vpn2, and specify a RD and route targets for
each VPN instance.
<MCE> system-view
[MCE] ip vpn-instance vpn1
[MCE-vpn-instance-vpn1] route-distinguisher 10:1
[MCE-vpn-instance-vpn1] vpn-target 10:1
[MCE-vpn-instance-vpn1] quit
[MCE] ip vpn-instance vpn2
[MCE-vpn-instance-vpn2] route-distinguisher 20:1
45
[MCE-vpn-instance-vpn2] vpn-target 20:1
[MCE-vpn-instance-vpn2] quit
# Create VLAN 10, add port GigabitEthernet 1/0/1 to VLAN 10, and create VLAN-interface 10.
[MCE] vlan 10
[MCE-vlan10] port gigabitethernet 1/0/1
[MCE-vlan10] quit
# Bind VLAN-interface 10 to VPN instance vpn1, and configure an IPv6 address for the VLAN
interface.
[MCE] interface vlan-interface 10
[MCE-Vlan-interface10] ip binding vpn-instance vpn1
[MCE-Vlan-interface10] ipv6 address 2001:1::1 64
[MCE-Vlan-interface10] quit
# Configure VLAN 20, add port GigabitEthernet 1/0/2 to VLAN 20, bind VLAN-interface 20 to
VPN instance vpn2, and assign an IPv6 address to VLAN-interface 20.
[MCE] vlan 20
[MCE-vlan20] port gigabitethernet 1/0/2
[MCE-vlan20] quit
[MCE] interface vlan-interface 20
[MCE-Vlan-interface20] ip binding vpn-instance vpn2
[MCE-Vlan-interface20] ipv6 address 2002:1::1 64
[MCE-Vlan-interface20] quit
# On PE 1, configure VPN instances vpn1 and vpn2, and specify an RD and route targets for
each VPN instance.
<PE1> system-view
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 30:1
[PE1-vpn-instance-vpn1] vpn-target 10:1
[PE1-vpn-instance-vpn1] quit
[PE1] ip vpn-instance vpn2
[PE1-vpn-instance-vpn2] route-distinguisher 40:1
[PE1-vpn-instance-vpn2] vpn-target 20:1
[PE1-vpn-instance-vpn2] quit
2.
Configure routing between the MCE and VPN sites:
The MCE is connected to VPN 1 directly, and no routing protocol is enabled in VPN 1.
Therefore, you can configure IPv6 static routes.
# On VR 1, assign IP address 2001:1::2/64 to the interface connected to the MCE and
2012:1::2/64 to the interface connected to VPN 1. Add ports to VLANs. (Details not shown.)
# On VR 1, configure a default route, specifying the next hop as 2001:1::1.
<VR1> system-view
[VR1] ipv6 route-static :: 0 2001:1::1
# On the MCE, configure an IPv6 static route to 2012:1::/64, specify the next hop as 2001:1::2,
and bind the static route to VPN instance vpn1.
[MCE] ipv6 route-static vpn-instance vpn1 2012:1:: 64 vpn-instance vpn1 2001:1::2
# Run RIPng in VPN 2. Configure RIPng process 20 for VPN instance vpn2 on the MCE, so that
the MCE can learn the routes of VPN 2 and add them to the routing table of VPN instance vpn2.
# Configure RIPng process 20, and bind it to VPN instance vpn2.
[MCE] ripng 20 vpn-instance vpn2
# Advertise subnet 2002:1::/64 through RIPng.
46
[MCE] interface vlan-interface 20
[MCE-Vlan-interface20] ripng 20 enable
[MCE-Vlan-interface20] quit
# On VR 2, assign IPv6 address 2002:1::2/64 to the interface connected to the MCE and
2012::2/64 to the interface connected to VPN 2. (Details not shown.)
# Configure RIPng, and advertise subnets 2012::/64 and 2002:1::/64.
<VR2> system-view
[VR2] ripng 20
[VR2-ripng-20] quit
[VR2] interface vlan-interface 20
[VR2-Vlan-interface20] ripng 20 enable
[VR2-Vlan-interface20] quit
[VR2] interface vlan-interface 21
[VR2-Vlan-interface21] ripng 20 enable
[VR2-Vlan-interface21] quit
# On MCE, display the routing tables of VPN instances vpn1 and vpn2.
[MCE] display ipv6 routing-table vpn-instance vpn1
Routing Table : vpn1
Destinations : 5
Routes : 5
Destination: ::1/128
Protocol
: Direct
NextHop
: ::1
Preference: 0
Interface
: InLoop0
Cost
: 0
Destination: 2001:1::/64
Protocol
: Direct
NextHop
: 2001:1::1
Preference: 0
Interface
: Vlan10
Cost
: 0
Destination: 2001:1::1/128
Protocol
: Direct
NextHop
: ::1
Preference: 0
Interface
: InLoop0
Cost
: 0
Destination: 2012:1::/64
Protocol
: Static
NextHop
: 2001:1::2
Preference: 60
Interface
: Vlan10
Cost
: 0
Destination: FE80::/10
Protocol
: Direct
NextHop
: ::
Preference: 0
Interface
: NULL0
Cost
: 0
Destination: ::1/128
Protocol
: Direct
NextHop
: ::1
Preference: 0
Interface
: InLoop0
Cost
[MCE] display ipv6 routing-table vpn-instance vpn2
Routing Table : vpn2
Destinations : 5
Routes : 5
47
: 0
Destination: 2002:1::/64
Protocol
NextHop
: 2002:1::1
Preference: 0
: Direct
Interface
: Vlan20
Cost
: 0
Destination: 2002:1::1/128
Protocol
: Direct
NextHop
: ::1
Preference: 0
Interface
: InLoop0
Cost
: 0
Destination: 2012::/64
Protocol
: RIPng
NextHop
: FE80::20F:E2FF:FE3E:9CA2
Preference: 100
Interface
: Vlan20
Cost
: 1
Destination: FE80::/10
Protocol
: Direct
NextHop
: ::
Preference: 0
Interface
: NULL0
Cost
: 0
The output shows that the MCE has learned the private route of VPN 2. The MCE maintains the
routes of VPN 1 and VPN 2 in two different routing tables. In this way, routes from different
VPNs are separated.
3.
Configure routing between the MCE and PE 1:
# On the MCE, configure the port connected to PE 1 as a trunk port, and configure it to permit
packets of VLAN 30 and VLAN 40 to pass with VLAN tags.
[MCE] interface gigabitethernet 1/0/3
[MCE-GigabitEthernet1/0/3] port link-type trunk
[MCE-GigabitEthernet1/0/3] port trunk permit vlan 30 40
[MCE-GigabitEthernet1/0/3] quit
# On PE 1, configure the port connected to MCE as a trunk port, and configure it to permit
packets of VLAN 30 and VLAN 40 to pass with VLAN tags.
[PE1] interface gigabitethernet 1/0/1
[PE1-GigabitEthernet1/0/1] port link-type trunk
[PE1-GigabitEthernet1/0/1] port trunk permit vlan 30 40
[PE1-GigabitEthernet1/0/1] quit
# On the MCE, create VLAN 30 and VLAN-interface 30, bind VLAN-interface 30 to VPN
instance vpn1 and configure an IPv6 address for the VLAN-interface 30.
[MCE] vlan 30
[MCE-vlan30] quit
[MCE] interface vlan-interface 30
[MCE-Vlan-interface30] ip binding vpn-instance vpn1
[MCE-Vlan-interface30] ipv6 address 30::1 64
[MCE-Vlan-interface30] quit
# On the MCE, create VLAN 40 and VLAN-interface 40, bind VLAN-interface 40 to VPN
instance vpn2 and configure an IPv6 address for the VLAN-interface 40.
[MCE] vlan 40
[MCE-vlan40] quit
[MCE] interface vlan-interface 40
[MCE-Vlan-interface40] ip binding vpn-instance vpn2
[MCE-Vlan-interface40] ipv6 address 40::1 64
[MCE-Vlan-interface40] quit
# On PE 1, create VLAN 30 and VLAN-interface 30, bind VLAN-interface 30 to VPN instance
vpn1 and configure an IPv6 address for the VLAN-interface 30.
[PE1] vlan 30
48
[PE1-vlan30] quit
[PE1] interface vlan-interface 30
[PE1-Vlan-interface30] ip binding vpn-instance vpn1
[PE1-Vlan-interface30] ipv6 address 30::2 64
[PE1-Vlan-interface30] quit
# On PE 1, create VLAN 40 and VLAN-interface 40, bind VLAN-interface 40 to VPN instance
vpn2 and configure an IPv6 address for the VLAN-interface 40.
[PE1] vlan 40
[PE1-vlan40] quit
[PE1] interface vlan-interface 40
[PE1-Vlan-interface40] ip binding vpn-instance vpn2
[PE1-Vlan-interface40] ipv6 address 40::2 64
[PE1-Vlan-interface40] quit
# Configure the IP address of the interface Loopback0 as 101.101.10.1 for the MCE and as
100.100.10.1 for PE 1. Specify the loopback interface address as the router ID for the MCE and
PE 1. (Details not shown.)
# Enable OSPFv3 process 10 on the MCE, bind the process to VPN instance vpn1, and
redistribute the IPv6 static route of VPN 1.
[MCE] ospfv3 10 vpn-instance vpn1
[MCE-ospf-10] router-id 101.101.10.1
[MCE-ospf-10] import-route static
[MCE-ospf-10] quit
# Enable OSPFv3 on VLAN-interface 30.
[MCE] interface vlan-interface 30
[MCE-Vlan-interface30] ospfv3 10 area 0.0.0.0
[MCE-Vlan-interface30] quit
# On PE 1, enable OSPFv3 process 10 and bind the process to VPN instance vpn1.
[PE1] ospfv3 10 vpn-instance vpn1
[PE1-ospf-10] router-id 100.100.10.1
[PE1-ospf-10] quit
# Enable OSPFv3 on VLAN-interface 30.
[PE1] interface vlan-interface 30
[PE1-Vlan-interface30] ospfv3 10 area 0.0.0.0
[PE1-Vlan-interface30] quit
# On PE 1, display the routing table of VPN 1.
[PE1] display ipv6 routing-table vpn-instance vpn1
Routing Table : vpn1
Destinations : 5
Routes : 5
Destination: ::1/128
Protocol
NextHop
: ::1
Preference: 0
Interface
: InLoop0
Cost
: 0
Destination: 30::/64
Protocol
: Direct
NextHop
: 30::2
Preference: 0
Interface
: Vlan30
Cost
: 0
Protocol
: Direct
Destination: 30::2/128
49
: Direct
NextHop
: ::1
Preference: 0
Interface
: InLoop0
Cost
: 0
Destination: 2012:1::/64
Protocol
: OSPFv3
NextHop
: FE80::202:FF:FE02:2
Preference: 150
Interface
: Vlan30
Cost
: 1
Destination: FE80::/10
Protocol
: Direct
NextHop
: ::
Preference: 0
Interface
: NULL0
Cost
: 0
The output shows that PE 1 has learned the private route of VPN 1 through OSPFv3.
Take similar procedures to configure OSPFv3 process 20 between the MCE and PE 1 and
redistribute VPN 2's routes from RIPng process 20 into the OSPFv3 routing table of the MCE.
The following output shows that PE 1 has learned the private route of VPN 2 through OSPFv3.
[PE1] display ipv6 routing-table vpn-instance vpn2
Routing Table : vpn2
Destinations : 5
Routes : 5
Destination: ::1/128
Protocol
: Direct
NextHop
: ::1
Preference: 0
Interface
: InLoop0
Cost
: 0
Destination: 40::/64
Protocol
: Direct
NextHop
: 40::2
Preference: 0
Interface
: Vlan40
Cost
: 0
Destination: 40::2/128
Protocol
: Direct
NextHop
: ::1
Preference: 0
Interface
: InLoop0
Cost
: 0
Destination: 2012::/64
Protocol
: OSPFv3
NextHop
: FE80::200:FF:FE0F:5
Preference: 150
Interface
: Vlan40
Cost
: 1
Destination: FE80::/10
Protocol
: Direct
NextHop
: ::
Preference: 0
Interface
: NULL0
Cost
: 0
Now, the routing information for the two VPNs has been added into the routing tables on PE 1.
50
Configuring basic MPLS
The term "interface" in this chapter collectively refers to Layer 3 Ethernet interfaces, Layer 3
aggregate interfaces, and VLAN interfaces. You can set an Ethernet port as a Layer 3 interface by
using the port link-mode route command (see Layer 2—LAN Switching Configuration Guide).
This chapter describes how to configure basic MPLS.
Hardware compatibility
The HPE 5820X Switch Series does not support MPLS.
MPLS overview
Multiprotocol Label Switching (MPLS) enables connection-oriented label switching on
connectionless IP networks. It integrates both the flexibility of IP routing and the level of simplicity of
Layer 2 switching.
MPLS has the following advantages:
•
MPLS forwards packets according to short- and fixed-length labels, instead of Layer 3 header
analysis and complicated routing table lookup, enabling highly-efficient and fast data forwarding
on backbone networks.
•
MPLS resides between the link layer and the network layer. It can operate over various link
layer protocols (for example, PPP, ATM, frame relay, and Ethernet), provide
connection-oriented services for various network layer protocols (for example, IPv4, IPv6, and
IPX), and operate with mainstream network technologies.
•
MPLS is connection-oriented and supports label stack. It can be used to implement various
functions, such as VPN, traffic engineering, and QoS.
Basic concepts
This section describes the basic concepts of MPLS.
FEC
MPLS groups packets with the same characteristics (such as packets with the same destination or
service class) into a class called a "forwarding equivalence class (FEC)." Packets of the same FEC
are handled in the same way on an MPLS network. The device supports classifying FECs according
to the network layer destination addresses.
Label
A label is a short, fixed length identifier for identifying a single FEC. A label is locally significant and
must be locally unique.
Figure 12 Format of a label
0
19
Label
Layer 2 header
Label
Exp
Layer 3 header
S
Layer 3 data
51
31
22 23
TTL
A label is encapsulated between the Layer 2 header and Layer 3 header of a packet. A label is four
bytes in length and consists of the following fields:
•
Label—20 bits in length. Label value for identifying a FEC.
•
Exp—Three bits in length. Reserved field, usually used for CoS.
•
S—One bit in length. MPLS supports multiple levels of labels. This field indicates whether a
label is at the bottom of the label stack. A value of 1 indicates that the label is at the bottom of
the label stack.
•
TTL—Eight bits in length. Like the homonymous IP header field, it is used to prevent loops.
NOTE:
The Exp field marks the CoS of the MPLS packet. It affects the scheduling priority of the packet. For
more information about packet scheduling, see ACL and QoS Configuration Guide.
LSR
A label switching router (LSR) is a fundamental component on an MPLS network. LSRs support label
distribution and label swapping.
LER
A label edge router (LER) is an LSR that resides at the edge of an MPLS network and is connected to
another network.
LSP
A label switched path (LSP) is the path along which packets of a FEC travel through an MPLS
network.
An LSP is a unidirectional path from the ingress of an MPLS network to the egress. On an LSP, two
neighboring LSRs are called the "upstream LSR" and "downstream LSR," respectively. In Figure 13,
LSR B is the downstream LSR of LSR A, and LSR A is the upstream LSR of LSR B.
Figure 13 Diagram of an LSP
LFIB
Labeled packets are forwarded according to the label forwarding information base (LFIB).
Control plane and forwarding plane
An MPLS node consists of two planes, control plane and forwarding plane.
•
The control plane assigns labels, selects routes, creates the LFIB, and establishes and
removes LSPs.
•
The forwarding plane forwards packets according to the LFIB.
52
MPLS network structure
Figure 14 Diagram of the MPLS network structure
LSRs in the same routing or administrative domain form an MPLS domain.
An MPLS domain consists of the following types of LSRs:
•
Ingress LSRs receive and label packets coming into the MPLS domain.
•
Transit LSRs forward packets along LSPs to their egress LERs according to the labels.
•
Egress LSRs remove labels from packets and forward the packets to their destination networks.
LSP establishment and label distribution
This section describes how MPLS sets up LSPs and distribute labels.
LSP establishment
Establishing LSPs is to bind FECs to labels on each LSR involved and notify its adjacent LSRs of the
bindings, so as to establish the LFIB on each LSR. LSPs can be manually established through
configuration, or dynamically established through label distribution protocols.
•
Establishing a static LSP through manual configuration:
Static LSPs do not dynamically change in response to network topology changes, and are
suitable for small-scale, stable, and simple networks. To establish a static LSP, assign a label to
the FEC on each LSR along the packet forwarding path.
•
Establishing an LSP through a label distribution protocol:
Label distribution protocols are MPLS signaling protocols. They can classify FECs, distribute
labels, and establish and maintain LSPs. Label distribution protocols include protocols
designed specifically for label distribution, such as the Label Distribution Protocol (LDP), and
protocols extended to support label distribution, such as BGP and RSVP-TE.
This document discusses LDP only. For more information about LDP, see "LDP."
In this document, the term "label distribution protocols" refers to all protocols for label distribution.
The term "LDP" refers to the RFC 5036 LDP.
A dynamic LSP is established in the following procedure:
A downstream LSR classifies FECs according to destination addresses. It assigns a label to a FEC,
and distributes the FEC-label binding to its upstream LSR, which then establishes an LFIB entry for
the FEC according to the binding information. After all LSRs along the packet forwarding path
establish a LFIB entry for the FEC, an LSP is established for packets of this FEC.
53
Figure 15 Process of dynamic LSP establishment
Ingress
LSR A
LSR B
LSR E
LSR F
Egress
LSR D
LSR C
LSR G
LSR H
Label mapping
LSP
If equal-cost routes exist on the LSRs, MPLS establishes equal-cost LSPs based on these routes,
and shares loads among the equal-cost LSPs.
Label distribution and management
An LSR informs its upstream LSRs of labels assigned to FECs through label advertisement. The
label advertisement modes include downstream unsolicited (DU) and downstream on demand (DoD).
The label distribution control modes include independent and ordered.
Label management specifies the mode for processing a received label binding that is not useful at
the moment. The processing mode, called "label retention mode," can be either liberal or
conservative.
Figure 16 Label advertisement modes
1) Unsolicitedly distributes a label
mapping for a FEC to the
upstream.
2) Unsolicitedly distributes a label
mapping for the FEC to the
upstream.
DU mode
Ingress
Transit
Egress
1) Sends a label request for a
FEC to the downstream.
2) Sends a label request for the
FEC to the downstream.
DoD mode
4) Distributes a label mapping for
the FEC to the upstream upon
receiving the request.
3) Distributes a label mapping for
the FEC to the upstream upon
receiving the request.
As shown in Figure 16, the label advertisement modes include the DU mode and the DoD mode.
•
In DU mode, an LSR assigns a label to a FEC and then distributes the FEC-label binding to its
upstream LSR without solicitation. The switch supports only the DU mode.
•
In DoD mode, an LSR assigns a label to a FEC and distributes the FEC-label binding to its
upstream LSR only when it receives a label request from the upstream LSR.
To establish an LSP, an upstream LSR and its downstream LSR must use the same label
advertisement mode.
54
Label distribution control modes include the independent mode and the ordered mode.
•
In independent mode, an LSR can distribute label bindings upstream at any time. This means
that an LSR may have distributed a label binding for a FEC to its upstream LSR before it
receives a binding for that FEC from its downstream LSR. As shown in Figure 17, in
independent label distribution control mode, if the label advertisement mode is DU, an LSR
assigns labels to its upstream even if it has not obtained labels from its downstream. If the label
advertisement mode is DoD, the LSR distributes a label to its upstream as long as it receives a
label request from the upstream.
Figure 17 Independent label distribution control mode
•
In ordered mode, an LSR distributes its label binding for a FEC upstream only when it receives
a label binding for the FEC from its downstream or it is the egress of the FEC. In Figure 16, label
distribution control is in ordered mode. If the label advertisement mode is DU, an LSR
distributes a label upstream only when it receives a label binding for the FEC from its
downstream. If the label advertisement mode is DoD, after an LSR (Transit in this example)
receives a label request from its upstream (Ingress), the LSR (Transit) sends a label request to
its downstream (Egress). Then, after the LSR (Transit) receives the label binding from its
downstream (Egress), it distributes a label binding to the upstream (Ingress).
Label retention modes include the liberal mode and the conservative mode.
•
In liberal mode, an LSR keeps any received label binding regardless of whether the binding is
from the next hop for the FEC or not. This mode allows for quicker adaptation to route changes
but wastes label resources because LSRs keep extra labels. The switch supports only the
liberal mode.
•
In conservative mode, an LSR keeps only label bindings that are from the next hops for the
FECs. This allows LSRs to maintain fewer labels but makes LSRs slower in adapting to route
changes.
MPLS forwarding
This section describes the MPLS forwarding information.
LFIB
An LFIB has the following table entries:
•
Next Hop Label Forwarding Entry (NHLFE)—Describes the label operation to be performed.
It is used to forward MPLS packets.
55
•
FEC to NHLFE (FTN) map—FTN maps each FEC to a set of NHLFEs at the ingress LSR. The
FTN map is used for forwarding unlabeled packets that need MPLS forwarding. When an LSR
receives an unlabeled packet, it looks for the corresponding FIB entry. If the Token value of the
FIB entry is not Invalid, the packet must be forwarded through MPLS. The LSR then looks for
the corresponding NHLFE entry according to the Token value to determine the label operation
to be performed.
•
Incoming Label Map (ILM)—ILM maps each incoming label to a set of NHLFEs. It is used to
forward labeled packets. When an LSR receives a labeled packet, it looks for the corresponding
ILM entry. If the Token value of the ILM entry is not null, the LSR looks for the corresponding
NHLFE entry to determine the label operation to be performed.
FTN and ILM are associated with NHLFE through Token.
MPLS data forwarding
Figure 18 MPLS forwarding process diagram
In an MPLS domain, a packet is forwarded in the following procedure:
1.
Router B (the ingress LSR) receives a packet carrying no label. It determines the FEC of the
packet according to the destination address, and searches the FIB table for the Token value.
Because the Token value is not Invalid, Router B looks for the corresponding NHLFE entry that
contains the Token value. According to the NHLFE entry, Router B pushes label 40 to the
packet, and forwards the labeled packet to the next hop LSR (Router C) through the outgoing
interface (GigabitEthernet 1/0/2).
2.
Upon receiving the labeled packet, Router C looks for the ILM entry that contains the label 40 to
get the Token value. Because the Token value is not empty, Router C looks for the NHLFE
entry containing the Token value. According to the NHLFE entry, Router C swaps the original
label with label 50, and then forwards the labeled packet to the next hop LSR (Router D)
through the outgoing interface (GigabitEthernet 1/0/2).
3.
Upon receiving the labeled packet, Router D (the egress) looks for the ILM entry according to
the label (50) to get the Token value. Because the Token is empty, Router D removes the label
from the packet. If the ILM entry records the outgoing interface, Router D forwards the packet
through the outgoing interface. If no outgoing interface is recorded, router D forwards the
packet according to the IP header of the packet.
56
PHP
In an MPLS network, when an egress node receives a labeled packet, it looks up the LFIB, pops the
label of the packet, and then performs the next level label forwarding or performs IP forwarding. The
egress node needs to do two forwarding table lookups to forward a packet: looking up the LFIB twice
or looking up the LFIB and the FIB once each.
The penultimate hop popping (PHP) feature can pop the label at the penultimate node to relieve the
egress of the label operation burden.
PHP is configured on the egress node. The label assigned by a PHP-capable egress node to the
penultimate hop can be one of the two listed:
•
IPv4 explicit null label 0—The egress assigns an IPv4 explicit null label to a FEC and
advertises the FEC-label binding to the upstream LSR. When forwarding an MPLS packet, the
upstream LSR replaces the label at the stack top with the explicit null label and then sends the
packet to the egress. When the egress receives the packet, which carries a label of 0, it does
not look up for the LFIB entry but pops the label stack directly and performs IPv4 forwarding.
•
Implicit null label 3—This label never appears in the label stack. An LSR directly performs a
pop operation to the labeled packets that match the implicit null label rather than substituting the
implicit null label for the original label at the stack top. After that, the LSR forwards the packet to
the downstream egress LSR. The egress directly performs the next level forwarding upon
receiving the packet.
Queue scheduling for MPLS
Queue scheduling uses a resource scheduling policy to determine the packet forwarding sequence
when network congestion occurs.
To implement priority mapping and queue scheduling for packets:
•
In an MPLS network, you must configure the trusted packet priority type as 802.1p or DSCP for
the interfaces that forward the packets on MPLS-enabled devices. For more information about
priority mapping and queue scheduling, see ACL and QoS Configuration Guide.
•
In an MPLS L2VPN, VPLS, or MPLS L3VPN environment, you must also configure the trusted
packet priority type as 802.1p or DSCP for the interfaces that forward the packets on CE
devices. For more information about CE devices, see "Configuring MPLS L3VPN."
LDP
LDP establishes LSPs dynamically. Using LDP, LSRs can map network layer routing information to
data link layer switching paths.
Basic concepts of LDP
•
LDP session—LDP sessions are established between LSRs based on TCP connections and
used to exchange messages for label binding, label releasing, and error notification.
•
LDP peer—Two LSRs using LDP to exchange FEC-label bindings are LDP peers.
LDP message type
LDP uses the following messages:
•
Discovery messages—Declare and maintain the presence of LSRs.
•
Session messages—Establish, maintain, and terminate sessions between LDP peers.
•
Advertisement messages—Create, alter, and remove FEC-label bindings.
•
Notification messages—Provide advisory information and notify errors.
LDP session, advertisement, and notification messages use TCP for reliability. Discovery messages
use UDP for efficiency.
57
LDP operation
LDP goes through the following phases in operation:
1.
Discovery
Each LSR sends hello messages periodically to notify neighboring LSRs of its presence. In this
way, LSRs can automatically discover their LDP peers. LDP provides the following discovery
mechanisms:
{
{
Basic discovery mechanism—Discovers directly connected LSRs and establishes link
hello adjacencies with them. An LSR periodically sends LDP link Hello messages to
multicast address 224.0.0.2 that identifies all routers on the subnet to advertise its
presence.
Extended discovery mechanism—Discovers indirectly connected LDP peers and
establishes targeted hello adjacencies. An LSR periodically sends LDP Hello messages to
a given IP address so that the LSR with the IP address can discover the LDP peer.
If two LSRs each have the same transport address (the source IP address used to establish a
TCP connection to the peer) for the basic and extended discovery mechanisms, the LSRs can
establish both a link hello adjacency and a targeted hello adjacency with each other, and the
two adjacencies are associated with the same session. This method is suited for two LDP peers
that have both a direct link (only one hop) and an indirect link (more than one hop) in between.
It can protect the LDP session between the two peers and avoid LDP convergence upon failure
of one link. When the direct link fails, the link hello adjacency is deleted. In this case, if the
indirect link operates correctly, the targeted hello adjacency remains. Therefore, the LDP
session is not deleted, and the FEC-label bindings based on this session are not deleted either.
When the direct link recovers, the LDP peers do not need to re-establish the LDP session or
re-learn the FEC-label bindings.
If two LSRs each have different transport addresses for the basic and extended discovery
mechanisms, only one type of hello adjacency (either link or targeted) can exist between them.
2.
Session establishment and maintenance
After an LSR finds a LDP peer, the LSRs go through the following steps to establish a session:
a. Establish a TCP connection between them.
b. Initialize negotiation of session parameters such as the LDP version, label advertisement
mode, and Keepalive interval.
After establishing a session between them, the two LDP peers send Hello and Keepalive
messages to maintain the session.
3.
LSP establishment and maintenance
LDP sends label requests and label binding messages between LDP peers to establish LSPs.
For the LSP establishment process, see "LSP establishment and label distribution."
4.
Session termination
An LSR terminates its LDP session with an LDP peer when:
{
All Hello adjacencies deleted between the two peers
LDP peers periodically send Hello messages to indicate that they intend to keep the Hello
adjacency. If an LSR does not receive any Hello message from a peer before the Hello timer
expires, it deletes the Hello adjacency with this peer. An LDP session has one or more Hello
adjacencies. When the last Hello adjacency for the session is deleted, the LSR sends a
Notification message to terminate the LDP session.
{
Loss of session connectivity
An LSR determines the integrity of an LDP session according to the LDP PDU (which
carries one or more LDP messages) transmitted on the session. Before the Keepalive timer
times out, if two LDP peers have no information to exchange, they can send Keepalive
messages to each other to maintain the LDP session. If an LSR does not receive any LDP
PDU from its peer during a Keepalive interval, it closes the TCP connection and terminates
the LDP session.
58
{
Receiving a shutdown message from the peer
An LSR can also send a Shutdown message to its LDP peer to terminate the LDP session.
When receiving the Shutdown message from an LDP peer, an LSR terminates the session
with the LDP peer.
Protocols
•
RFC 3031, Multiprotocol Label Switching Architecture
•
RFC 3032, MPLS Label Stack Encoding
•
RFC 5036, LDP Specification
MPLS configuration task list
Task
Remarks
Enabling the MPLS function
Required.
Configuring a static LSP
Required.
Establishing dynamic LSPs
through LDP
Maintaining LDP sessions
Configuring MPLS LDP capability
Required.
Configuring local LDP session
parameters
Optional.
Configuring remote LDP session
parameters
Optional.
Configuring PHP
Optional.
Configuring the policy for triggering
LSP establishment
Optional.
Configuring the label distribution
control mode
Optional.
Configuring LDP loop detection
Optional.
Configuring LDP MD5
authentication
Optional.
Configuring LDP label filtering
Optional.
Configuring DSCP for outgoing LDP
packets
Optional.
Configuring BFD for MPLS LDP
Optional.
Resetting LDP sessions
Optional.
Configuring a TTL processing mode
for an LSR
Optional.
Sending back ICMP TTL exceeded
messages for MPLS TTL expired
packets
Optional.
Configuring LDP GR
Optional.
Configuring LDP NSR
Optional.
Configuring MPLS statistics collection
Optional.
Inspecting LSPs
Optional.
Configuring MPLS LSP ping
59
Use either the static
or dynamic LSP
configuration
method.
Task
Remarks
Configuring MPLS LSP tracert
Optional.
Configuring BFD for LSPs
Optional.
Configuring periodic LSP tracert
Optional.
Enabling MPLS trap
Optional.
Enabling the MPLS function
In an MPLS domain, you must enable MPLS on all routers before you can configure other MPLS
features.
Before you enable MPLS, complete the following tasks:
•
Configure link layer protocols to ensure the connectivity at the link layer.
•
Assign IP addresses to interfaces so that all neighboring nodes can reach each other at the
network layer.
•
Configure static routes or an IGP protocol for the LSRs to communicate with each other.
To enable MPLS:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
By default, no MPLS LSR ID is
configured.
An MPLS LSR ID is in the format
of an IP address and must be
unique within an MPLS domain.
Hewlett Packard Enterprise
recommends using the IP
address of a loopback interface
on an LSR as the MPLS LSR ID.
2.
Configure the MPLS LSR ID.
mpls lsr-id lsr-id
3.
Enable MPLS globally and
enter MPLS view.
mpls
By default, global MPLS is
disabled.
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
6.
Enable MPLS for the
interface.
mpls
By default, MPLS is disabled on
interfaces.
Configuring a static LSP
The principle of establishing a static LSP is that the outgoing label of an upstream LSR is the
incoming label of its downstream LSR.
Before you configure a static LSP, complete the following tasks:
•
Determine the ingress LSR, transit LSRs, and egress LSR for the static LSP.
•
Enable MPLS on all these LSRs.
•
Make sure the ingress LSR has a route to the FEC destination. This is not required on the
transit LSRs and egress LSR.
60
When you configure a static LSP, follow these configuration restrictions and guidelines:
•
The outgoing label of an upstream LSR is the incoming label of its downstream LSR.
•
When you configure a static LSP on the ingress LSR, the next hop specified must be consistent
with the next hop of the optimal route in the routing table. If you configure a static IP route for the
LSP, be sure to specify the same next hop for the static route and the static LSP. For information
about configuring a static IP route, see Layer 3—IP Routing Configuration Guide.
•
For an ingress or transit LSR, do not specify the public address of an interface on the LSR as
the next hop address.
To configure a static LSP:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
•
•
2.
Configure a static LSP.
•
On the ingress node:
static-lsp ingress lsp-name
destination dest-addr { mask |
mask-length } nexthop next-hop-addr
out-label out-label
On a transit node:
static-lsp transit lsp-name
incoming-interface interface-type
interface-number in-label in-label
nexthop next-hop-addr out-label
out-label
On the egress node:
static-lsp egress lsp-name
incoming-interface interface-type
interface-number in-label in-label
Follow the configuration
guidelines to set correct
parameters for the ingress,
transit, and egress nodes.
Establishing dynamic LSPs through LDP
Perform the tasks in this section so the switch can use LDP to set up dynamic LSPs.
Configuring MPLS LDP capability
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable LDP capability globally and
enter MPLS LDP view.
mpls ldp
Not enabled by default.
61
Step
Command
Remarks
Optional.
By default, the LDP LSR ID is the
same as the MPLS LSR ID.
You need to perform this task only
in a multi-VPN context to make
sure different LDP instances have
different LDP LSR IDs if their
address spaces overlap.
Otherwise, TCP connections
cannot be established.
3.
Configure the LDP LSR ID.
lsr-id lsr-id
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
6.
Enable LDP capability for the
interface.
mpls ldp
Not enabled by default.
NOTE:
Disabling LDP on an interface terminates all LDP sessions on the interface. As a result, all LSPs
using the sessions are deleted.
Configuring local LDP session parameters
LDP sessions established between local LDP peers are local LDP sessions. To establish a local LDP
session:
•
Determine the LDP transport addresses of the two peers and make sure the LDP transport
addresses are reachable to each other. This step is to establish the TCP connection.
•
If many LDP sessions exist between the two LSRs or the CPU is occupied often, adjust timers
to ensure the stability of the LDP sessions.
To configure local LDP session parameters:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Set the link Hello timer.
mpls ldp timer hello-hold value
4.
Set the link Keepalive timer.
mpls ldp timer keepalive-hold
value
Optional.
15 seconds by default.
Optional.
45 seconds by default.
Optional.
5.
Configure the LDP transport
address.
mpls ldp transport-address
{ ip-address | interface }
62
The default takes the value of the
MPLS LSR ID.
The specified IP address must be
the IP address of an interface on
the switch for setting up LDP
sessions.
Configuring remote LDP session parameters
LDP sessions established between remote LDP peers are remote LDP sessions. Remote LDP
sessions are mainly used in Martini MPLS L2VPN, and Martini VPLS. For more information about
remote session applications, see "Configuring MPLS L2VPN" and "Configuring VPLS."
To establish a remote LDP session, perform the following operations:
•
Determine the LDP transport addresses of the two peers and make sure the LDP transport
addresses are reachable to each other. Do this to establish the TCP connection.
•
If many LDP sessions exist between the two LSRs or the CPU is occupied often, adjust timers
to ensure the stability of the LDP sessions.
To configure remote LDP session parameters:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a remote peer entity
and enter MPLS LDP remote
peer view.
mpls ldp remote-peer
remote-peer-name
N/A
Configure the remote peer IP
address.
remote-ip ip-address
The remote peer IP address must
be different from all existing
remote peer IP addresses.
3.
Optional.
Configure LDP to advertise
prefix-based labels through
a remote session.
prefix-label advertise
5.
Set the targeted Hello timer.
mpls ldp timer hello-hold value
6.
Set the targeted Keepalive
timer.
mpls ldp timer keepalive-hold
value
4.
By default, LDP does not
advertise prefix-based labels
through a remote session, and
remote sessions are used only to
transfer messages for L2VPNs.
For more information about
remote session applications, see
the Martini MPLS L2VPN
configuration in "Configuring
MPLS L2VPN."
Optional.
The default value is 45 seconds.
Optional.
The default value is 45 seconds.
Optional.
7.
Configure the LDP transport
address.
mpls ldp transport-address
ip-address
The default takes the value of the
MPLS LSR ID.
The specified IP address must be
the IP address of an interface on
the device for setting up LDP
sessions.
Configuring PHP
Follow these guidelines when you configure PHP:
•
When specifying the type of label for an egress to distribute to a penultimate hop, check
whether the penultimate hop supports PHP. If the penultimate hop supports PHP, you can
configure the egress to distribute an explicit null or implicit null label to the penultimate hop. If
the penultimate hop does not support PHP, you must configure the egress to distribute a normal
label.
63
•
The device supports PHP when it operates as a penultimate hop.
•
For LDP sessions that already exist before the label advertise command is configured, you
must reset the LDP sessions by using the reset mpls ldp command for the PHP configuration
to take effect.
To configure PHP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Specify the type of the label
to be distributed by the
egress to the penultimate
hop.
label advertise { explicit-null |
implicit-null | non-null }
Optional.
By default, an egress distributes
to the penultimate hop an implicit
null label.
Configuring the policy for triggering LSP establishment
You can configure an LSP triggering policy on an LSR, so only routes matching the policy can trigger
establishment of LSPs, reducing the number of LSPs to be established on the LSR and avoiding
instability of the LSR caused by excessive LSPs.
An LSR supports the following types of LSP triggering policies:
•
Allowing all routing entries to trigger establishment of LSPs.
•
Filtering routing entries by an IP prefix list, so static and IGP routes denied by the IP prefix list do
not trigger LSP establishment. To use this policy, first create the IP prefix list. For information
about IP prefix list configuration, see Layer 3—IP Routing Configuration Guide.
To configure the policy for triggering LSP establishment:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
Optional.
By default, only host routes with
32-bit masks can trigger
establishment of LSPs.
3.
Configure the LSP
establishment triggering
policy.
lsp-trigger [ vpn-instance
vpn-instance-name ] { all |
ip-prefix prefix-name }
If the vpn-instance
vpn-instance-name option is
specified, the command
configures an LSP establishment
triggering policy for the specified
VPN. Otherwise, the command
configures an LSP establishment
triggering policy for the public
network routes.
NOTE:
For an LSP to be established, an exactly matching routing entry must exist on the LSR. For
example, on an LSR, to establish an LSP to a loopback address with a 32-bit mask, there must be
an exactly matching host routing entry on the LSR.
64
Configuring the label distribution control mode
With the label re-advertisement function enabled, an LSR periodically looks for FECs not assigned
with labels, assigns labels to them if any, and advertises the label-FEC bindings. You can set the
label re-advertisement interval as needed.
To configure the LDP label distribution control mode:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS LDP view.
mpls ldp
N/A
Optional.
The default mode is ordered.
3.
Specify the label distribution
control mode.
4.
Enable label
re-advertisement for DU
mode.
du-readvertise
Set the interval for label
re-advertisement in DU
mode.
du-readvertise timer value
5.
label-distribution { independent
| ordered }
For LDP sessions existing before
the command is configured, you
must reset the LDP sessions for
the specified label distribution
control mode to take effect.
Optional.
By default, label re-advertisement
for DU mode is enabled.
Optional.
The default interval is 30 seconds.
Configuring LDP loop detection
LSPs established in an MPLS domain may be looping. The LDP loop detection mechanism can
detect looping LSPs and prevent LDP messages from looping forever.
LDP loop detection can be in either of the following modes:
•
Maximum hop count
A label request message or label mapping message carries information about its hop count,
which increments by 1 for each hop. When this value reaches the specified limit, LDP considers
that a loop is present and terminates the establishment of the LSP.
•
Path vector
A label request message or label mapping message carries path information in the form of path
vector list. When such a message reaches an LSR, the LSR examines the path vector list of the
message for its MPLS LSR ID. If its MPLS LSR ID is not in the list, the LSR adds its LSR ID to
the path vector list. If it is in the list, the LSR considers that a loop has occurred and terminates
the establishment of the LSP.
The path vector mode also limits the number of hops of an LSP. An LSR also terminates the
establishment of an LSP when the hop count of the path, or the length of the path vector,
reaches the upper limit.
Configuration guidelines
•
The loop detection modes configured on two LDP peers must be the same for setting up an
LDP session.
•
To implement loop detection in an MPLS domain, you must enable loop detection on every LSR
in the MPLS domain.
•
Configure loop detection before enabling LDP capability on any interface.
65
•
All loop detection configurations take effect for only the LSPs established after the
configurations. Changing the loop detection settings does not affect existing LSPs. You can
execute the reset mpls ldp command in user view, so the loop detection settings also take
effect for existing LSPs.
•
LDP loop detection can result in LSP update, which generates redundant information and
consume many system resources. Hewlett Packard Enterprise recommends configuring the
routing protocol's loop detection mechanism.
Configuration procedure
To configure LDP loop detection:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS LDP view.
mpls ldp
N/A
3.
Enable loop detection.
loop-detect
By default, loop detection is
disabled.
4.
Set the maximum hop count.
hops-count hop-number
5.
Set the maximum path
vector length.
path-vectors pv-number
Optional.
The default value is 32.
Optional.
The default value is 32.
Configuring LDP MD5 authentication
LDP sessions are established based on TCP connections. To improve the security of LDP sessions,
you can configure MD5 authentication for the underlying TCP connections, so that the TCP
connections can be established only if the peers have the same authentication password.
IMPORTANT:
To establish an LDP session successfully between two LDP peers, make sure their LDP MD5
authentication settings are the same.
To configure LDP MD5 authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS LDP view.
mpls ldp
N/A
3.
Enable LDP MD5
authentication and set the
password.
md5-password { cipher | plain }
peer-lsr-id password
By default, LDP MD5
authentication is disabled.
Configuring LDP label filtering
The LDP label filtering feature provides two mechanisms, label acceptance control for controlling
which labels are accepted and label advertisement control for controlling which labels are advertised.
In complicated MPLS network environments, you can use LDP label filtering to control which LSPs
are to be established dynamically and prevent devices from accepting and advertising excessive
label bindings.
66
Label acceptance control
Label acceptance control is for filtering received label bindings. An upstream LSR filters the label
bindings received from the specified downstream LSR and accepts only those permitted by the
specified prefix list. As shown in Figure 19, upstream device LSR A filters the label bindings received
from downstream device LSR B. Only if the destination address of an FEC matches the specified
prefix list, does LSR A accept the label binding of the FEC from LSR B. LSR A does not filter label
bindings received from downstream device LSR C.
Figure 19 Network diagram of label acceptance control
Label advertisement control
Label advertisement control is for filtering label bindings to be advertised. A downstream LSR
advertises only the label bindings of the specified FECs to the specified upstream LSR. As shown
in Figure 20, downstream device LSR A advertises to upstream device LSR B only label bindings
with FEC destinations permitted by prefix list B, and advertises to upstream device LSR C only label
bindings with FEC destinations permitted by prefix list C.
b i Ad
nd ve
by ing rtis
pr s p e l
ef e ab
ix rm e
lis i t t l
t C ed
Figure 20 Network diagram of label advertisement control
Configuration prerequisites
Before you configure LDP label filtering policies, create an IP prefix list. For information about IP
prefix list configuration, see Layer 3—IP Routing Configuration Guide.
67
Configuration procedure
For two neighboring LSRs, configuring a label acceptance control policy on the upstream LSR and
configuring a label advertisement control policy on the downstream LSR have the same effect. To
reduce network traffic, Hewlett Packard Enterprise recommends configuring only label
advertisement control policies.
To configure LDP label filtering policies:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS LDP view.
mpls ldp
N/A
3.
Configure a label acceptance
control policy.
accept-label peer peer-id ip-prefix
ip-prefix-name
4.
Configure a label
advertisement control policy.
advertise-label ip-prefix ip-prefix-name
[ peer peer-ip-prefix-name ]
Optional.
Not configured by
default.
Not configured by
default.
Configuring DSCP for outgoing LDP packets
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS LDP view.
mpls ldp
N/A
3.
Configure a DSCP value for
outgoing LDP packets.
dscp dscp-value
By default, the DSCP value for
outgoing LDP packets is 48.
Maintaining LDP sessions
This section describes how to detect communication failures between remote LDP peers and reset
LDP sessions.
Configuring BFD for MPLS LDP
Use bidirectional forwarding detection (BFD) to help MPLS promptly detect a neighbor failure or link
failure between two remote LDP peers. BFD can help MPLS LDP detect communication failures only
between remote LDP peers. For configuration examples, see "Configuring VPLS." For more
information about BFD, see High Availability Configuration Guide.
To configure BFD for MPLS LDP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS LDP remote
peer view.
mpls ldp remote-peer
remote-peer-name
N/A
3.
Enable BFD for MPLS
LDP.
remote-ip bfd
68
By default, BFD is disabled for
MPLS LDP.
One LSP can have only one
BFD session.
Resetting LDP sessions
If you change LDP session parameters when some LDP sessions are up, the LDP sessions cannot
function correctly. In this case, reset LDP sessions so the LDP peers will renegotiate parameters and
establish new sessions.
To reset LDP sessions, perform the following task in user view:
Task
Command
Reset LDP sessions.
reset mpls ldp [ all | [ vpn-instance vpn-instance-name ] [ fec
mask | peer peer-id ] ]
Managing and optimizing MPLS forwarding
Perform the tasks in this section to manage and optimize MPLS forwarding for higher performance.
Configuring a TTL processing mode for an LSR
An LSR can process the TTL field in the either of the following ways:
•
Enable TTL propagation—When an LSR labels a packet, it copies the TTL value of the
original packet (the IP TTL value of an IP packet or the TTL value in the top label of a labeled
packet) to the TTL field of the newly added label. When an LSR pops the stack-top label, it
copies the TTL value of the stack-top label to the TTL field of the original packet. In this mode,
the TTL value of a packet is decreased hop by hop when forwarded along the LSP. The tracert
result reflects the real path along which the packet has traveled.
Figure 21 TTL processing when TTL propagation is enabled
•
Disable TTL propagation—When an LSR labels a packet, it does not copy the TTL value of
the original IP packet to the TTL field of the label, and the label's TTL is set to 255. When an
LSR pops the stack-top label, it does not copy the label's TTL to the original packet, and if the
LSR is the egress LSR, it decreases the TTL value of the original packet by 1. Other LSRs do
not change the TTL value of the original packet. In this mode, the tracert result does not show
the hops within the MPLS backbone, as if the ingress and egress were connected directly.
69
Figure 22 TTL processing when TTL propagation is disabled
Configuration guidelines
Hewlett Packard Enterprise recommends configuring the same TTL processing mode on all LSRs
along an LSP.
To enable IP TTL propagation for a VPN, you must enable it on all PE devices in the VPN, so that you
can get the same traceroute result (hop count) from those PEs. For more information about PEs, see
"Configuring MPLS L3VPN."
Configuration procedure
To configure TTL propagation of MPLS:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Enable MPLS TTL
propagation.
ttl propagate { public | vpn }
Optional.
Enabled only for public network
packets by default.
Sending back ICMP TTL exceeded messages for MPLS TTL
expired packets
After you enable an LSR to send back ICMP TTL exceeded messages for MPLS TTL expired
packets, when the LSR receives an MPLS packet that carries a label with TTL being 1, it generates
an ICMP TTL exceeded message, and send the message to the packet sender in one of the
following ways:
•
If the LSR has a route to the packet sender, it sends the ICMP TTL exceeded message to the
packet sender directly through the IP route.
•
If the LSR has no route to the packet sender, it forwards the ICMP TTL exceeded message
along the LSP to the egress, which sends the message to the packet sender.
Usually, for an MPLS packet carrying only one level of label, the first method is used. For an MPLS
packet carrying a multi-level label stack, the second method is used. However, because autonomous
system boundary routers (ASBRs), superstratum PEs or service provider-end PEs (SPEs) in
Hierarchy of VPN (HoVPN) applications, and carrier backbone PEs in nested VPNs may receive
MPLS VPN packets that carry only one level of labels but these devices have no IP routes to the
packet senders, the first method is not applicable. In this case, you can configure the undo ttl
expiration pop command on these devices so the devices use the second method.
For more information about HoVPN and nested VPN, see "Configuring MPLS L3VPN."
70
To configure the device to send back an ICMP TTL exceeded message for a received MPLS TTL
expired packet:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Enable the device to send
back an ICMP TTL exceeded
message when it receives an
MPLS TTL expired packet.
ttl expiration enable
Optional.
Enabled by default.
Optional.
Use either method as required.
4.
Configure the device to use
IP routes or LSPs to send
back the ICMP TTL
exceeded messages for
TTL-expired MPLS packets
that have only one level of
label.
•
•
(Method 1) Use IP routes:
ttl expiration pop
(Method 2) Use LSPs:
undo ttl expiration pop
By default, an ICMP TTL
exceeded message is sent back
along an IP route when the TTL of
an MPLS packet with a one-level
label stack expires.
This configuration does not take
effect when the MPLS packets
carry multiple levels of labels.
ICMP TTL exceeded messages
for such MPLS packets always
travel along the LSPs.
Configuring LDP GR
MPLS has two separate planes: the forwarding plane and the control plane. Using this feature, LDP
Graceful Restart (GR) preserves the LFIB information when the signaling protocol or control plane
fails, so that LSRs can still forward packets according to LFIB, ensuring continuous data
transmission.
A device that participates in a GR process can be a GR restarter or a GR helper.
•
GR restarter—Router that gracefully restarts due to a manually configured command or a fault.
It must be GR-capable.
•
GR helper—Neighbor of the GR restarter. A GR helper maintains the neighbor relationship with
the GR restarter and helps the GR restarter restore its LFIB information. A GR helper must be
GR-capable.
71
Figure 23 LDP GR
GR helper
GR restarter
GR helper
GR helper
LDP session with GR capability
Two LDP peers perform GR negotiation when establishing an LDP session. The LDP session
established is GR capable only when both peers support LDP GR.
LDP GR operates in the following procedure:
1.
Whenever restarting, the GR restarter preserves all MPLS forwarding entries, marks them as
stale, and starts the MPLS forwarding state holding timer for them.
2.
After a GR helper detects that the LDP session with the GR restarter is down, it marks the
FEC-label bindings learned from the session as stale and keeps these FEC-label bindings for a
period of time defined by the fault tolerant (FT) reconnect time argument. The FT reconnect
time is the smaller one between the reconnect time advertised from the peer GR restarter and
the neighbor liveness time configured locally.
3.
During the FT reconnect time, if the LDP session fails to be re-established, the GR helper
deletes the FEC-label bindings marked stale.
4.
If the session is re-established successfully, during the LDP recovery time, the GR helper and
the GR restarter uses the new LDP session to exchange the label mapping information, update
the LFIB, and delete the stale marks of the corresponding forwarding entries. The LDP recovery
time is the smaller one between the recovery time configured locally and that configured on the
peer GR restarter.
5.
After the recovery time elapses, the GR helper deletes the FEC-label bindings that are still
marked stale.
6.
When the MPLS forwarding state holding timer expires, the GR restarter deletes the label
forwarding entries that are still marked stale.
Configuration prerequisites
Configure MPLS LDP capability on each device acting as the GR restarter or a GR helper. (The
switch can act as a GR restarter or a GR helper as needed in the LDP GR process.)
Configuration procedure
The LDP GR feature and the LDP NSR feature are mutually exclusive. Do not configure both
features on the device.
To configure LDP GR:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
72
Step
Command
Remarks
2.
Enter MPLS LDP view.
mpls ldp
N/A
3.
Enable MPLS LDP GR.
graceful-restart
Disabled by default.
4.
Set the FT reconnect time.
graceful-restart timer
reconnect timer
Optional.
5.
Set the LDP neighbor
liveness time.
graceful-restart timer
neighbor-liveness timer
Optional.
Set the LDP recovery time.
graceful-restart timer recovery
timer
Optional.
6.
300 seconds by default.
120 seconds by default.
300 seconds by default.
Gracefully restarting MPLS LDP
To test whether the MPLS LDP GR configuration has taken effect, you can perform graceful restart of
MPLS LDP. During the LDP restart process, you can see whether the packet forwarding path is
changed and whether packet forwarding is interrupted.
The graceful-restart mpls ldp command is intended only for testing the MPLS LDP GR function. It
does not perform active/standby switchover.
To restart MPLS LDP gracefully:
Task
Command
Remarks
Restart MPLS LDP gracefully.
graceful-restart mpls ldp
Available in user view.
Configuring LDP NSR
Nonstop routing (NSR) is a mechanism for keeping on data transmission during a master/slave
switchover. NSR for LDP can back up the LDP session information and LSP information from the IRF
master device to the IRF slave device. Therefore, when a master/slave switchover occurs, the slave
device can immediately pick up the LDP service, implementing nonstop data transmission.
The LDP GR function can also implement nonstop data forwarding, but it requires that the GR
restarter and all its neighbors support LDP GR. With the LDP NSR function, the neighboring devices
do not need to support LDP NSR, and they are not aware of any switchover event on the
NSR-enabled device.
The LDP GR feature and the LDP NSR feature are mutually exclusive. Do not configure both
features on the device.
To configure LDP NSR:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS LDP view.
mpls ldp
N/A
3.
Enable the NSR function.
non-stop-routing
Disabled by default.
Configuring MPLS statistics collection
To use display commands to display LSP statistics, first set the statistics reading interval, as follows:
73
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Set LSP statistics reading
interval.
statistics interval interval-time
The default interval is 0 seconds.
The system does not read LSP
statistics.
Inspecting LSPs
In MPLS, the MPLS control plane is responsible for establishing LSPs. However, when an LSP fails
to forward data, the control plane cannot detect the LSP failure or cannot do so in time. This makes
network maintenance difficult. To find LSP failures in time and locate the failed node, the device
provides the following mechanisms:
•
MPLS LSP ping
•
MPLS LSP tracert
•
BFD for LSPs
•
Periodic LSP tracert
Configuring MPLS LSP ping
MPLS LSP ping is for testing the connectivity of an LSP. At the ingress, it adds the label for the FEC
to be inspected into an MPLS echo request, which then is forwarded along the LSP to the egress.
The egress processes the request packet and returns an MPLS echo reply to the ingress. An MPLS
echo reply carrying a success notification indicates that the LSP is normal, and an MPLS echo reply
carrying an error code indicates that the LSP has failed.
To test the connectivity of an LSP, perform the following task in any view:
Task
Command
Use MPLS LSP ping to test MPLS LSP connectivity.
ping lsp [ -a source-ip | -c count | -exp exp-value |
-h ttl-value | -m wait-time | -r reply-mode | -s
packet-size | -t time-out | -v ] * ipv4 dest-addr
mask-length [ destination-ip-addr-header ]
Configuring MPLS LSP tracert
MPLS LSP tracert is for locating LSP errors. It consecutively sends the MPLS echo requests along
the LSP to be inspected, with the TTL increasing from 1 to a specific value. Then, each hop along the
LSP returns an MPLS echo reply to the ingress due to TTL timeout. So, the ingress can collect
information about each hop along the LSP, so as to locate the failed node. You can also use MPLS
LSP tracert to collect the important information about each hop along the LSP, such as the label
allocated.
Configuration prerequisites
•
Enable sending ICMP TTL exceeded messages on the intermediate devices between the
source device and the destination device.
•
Enable sending ICMP destination unreachable messages on the destination device.
•
To display MPLS information during the tracert operation, enable support for ICMP extensions
on the source device and the intermediate devices.
74
For more information about ICMP time exceeded messages, ICMP destination unreachable
messages, and ICMP extensions for MPLS, see Layer 3—IP Services Configuration Guide.
Configuration procedure
To locate errors of an LSP, perform the following task in any view:
Task
Command
Perform MPLS LSP tracert to locate errors along an
MPLS LSP.
tracert lsp [ -a source-ip | -exp exp-value | -h
ttl-value | -r reply-mode |-t time-out ] * ipv4
dest-addr mask-length [ destination-ip-addr-header ]
Configuring BFD for LSPs
You can configure BFD to detect the connectivity of an LSP. After the configuration, a BFD session is
established between the ingress and egress of the LSP, and the ingress adds the label for the FEC
into a BFD control packet, forwards the BFD control packet along the LSP to the egress, and
determines the status of the LSP according to the reply received. Upon detecting an LSP failure,
BFD triggers a traffic switchover.
A BFD session for LSP connectivity detection can be static or dynamic.
•
Static—If you specify the local and remote discriminator values by using the discriminator
keyword when configuring the bfd enable command, the BFD session is established with the
specified discriminator values. Such a BFD session is used to detect the connectivity of a pair of
LSPs in opposite directions (one from local to remote, and the other from remote to local)
between two devices.
•
Dynamic—If you do not specify the local and remote discriminator values when configuring the
bfd enable command, the MPLS LSP ping is run automatically to negotiate the discriminator
values and then the BFD session is established based on the negotiated discriminator values.
Such a BFD session is used for connectivity detection of an LSP from the local device to the
remote device.
Configuration prerequisites
•
The BFD session parameters configured on the loopback interface whose IP address is
configured as the MPLS LSR ID are used, and the BFD packets use the MPLS LSR ID as the
source address. Before enabling BFD for an LSP, you must configure an IP address for the
loopback interface and configure the IP address as the MPLS LSR ID. You can also configure
BFD session parameters for the loopback interface as needed. For more information about
BFD, see High Availability Configuration Guide.
•
To establish a static BFD session, make sure there is already an LSP from the local device to
the remote device and an LSP from the remote device to the local device.
Configuration guidelines
•
You cannot establish both a static BFD session and a dynamic BFD session for the same LSP.
•
After you establish a static BFD session, you cannot modify the discriminator values of the BFD
session.
•
In a BFD session for detecting LSP connectivity, the ingress node always operates in active
mode and the egress node always operates in passive mode. The bfd session init-mode
command does not take effect on the ingress and egress nodes of such a BFD session. Even if
you configure the two nodes to both operate in passive mode, the BFD session can still be
successfully established.
•
BFD for MPLS LDP is for detecting the IP connectivity between two remote LDP peers. BFD for
LSP is for detecting the connectivity of LSPs.
75
Configuration procedure
To configure BFD for LSPs:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable LSP verification and
enter the MPLS LSPV view.
mpls lspv
Not enabled by default.
3.
Configure BFD to detect the
LSP connectivity.
bfd enable destination-address
mask-length [ nexthop
nexthop-address [ discriminator
local local-id remote remote-id ] ]
Not configured by default.
Configuring periodic LSP tracert
The periodic LSP tracert function is for locating faults of an LSP periodically. It detects the
consistency of the forwarding plane and control plane and records detection results into logs. You
can check the logs to know whether an LSP has failed.
If you configure BFD as well as periodic tracert for an LSP, once the periodic LSP tracert function
detects an LSP fault or inconsistency of the forwarding plane and control plane, the BFD session for
the LSP is deleted and a new BFD session is established according to the control plane.
Configuration prerequisites
•
Enable sending ICMP TTL exceeded messages on the intermediate devices between the
source device and the destination device.
•
Enable sending ICMP destination unreachable messages on the destination device.
•
To display MPLS information during the tracert operation, enable support for ICMP extensions
on the source device and the intermediate devices.
For more information about ICMP time exceeded messages, ICMP destination unreachable
messages, and ICMP extensions for MPLS, see Layer 3—IP Services Configuration Guide.
Configuration procedure
To configure the periodic LSP tracert function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable LSP verification and
enter the MPLS LSPV view.
mpls lspv
Not enabled by default.
3.
Configure periodic tracert for
an LSP to the specified FEC
destination.
periodic-tracert destination-address
mask-length [ -a source-ip | -exp
exp-value | -h ttl-value | -m wait-time |
-t time-out | -u retry-attempt ] *
Not configured by default.
Enabling MPLS trap
With the MPLS trap function enabled, trap packets of the notifications level are generated to report
critical MPLS events. Such trap packets are sent to the information center of the device. Whether
and where the packets are output depend on the configurations of the information center. For
information on how to configure the information center, see Network Management and Monitoring
Configuration Guide.
76
To enable the MPLS trap function:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
By default, the MPLS trap is
disabled.
2.
Enable the MPLS trap.
snmp-agent trap enable mpls
For more information about the
command, see the snmp-agent
trap enable command in Network
Management and Monitoring
Command Reference.
Displaying and maintaining MPLS
Use the commands in this section to verify MPLS configuration and maintain MPLS statistics.
Displaying MPLS operation
Task
Command
Remarks
Display information about one or
all MPLS-enabled interfaces.
display mpls interface [ interface-type
interface-number ] [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about ILM
entries.
display mpls ilm [ label ] [ verbose ] [ slot
slot-number ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display information about
specified MPLS labels or all
labels.
display mpls label { label-value1 [ to
label-value2 ] | all } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about LSPs.
display mpls lsp [ incoming-interface
interface-type interface-number ]
[ outgoing-interface interface-type
interface-number ] [ in-label in-label-value ]
[ out-label out-label-value ] [ asbr |
[ vpn-instance vpn-instance-name ]
[ protocol { bgp | bgp-ipv6 | crldp | ldp |
rsvp-te | static | static-cr } ] ] [ egress |
ingress | transit ] [ { exclude | include }
dest-addr mask-length ] [ verbose ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display LSP statistics.
display mpls lsp statistics [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display BFD detection
information for an LSP.
display mpls lsp bfd [ ipv4
destination-address mask-length ] [ | { begin
| exclude | include } regular-expression ]
Available in any view.
Display information about NHLFE
entries.
display mpls nhlfe [ token ] [ verbose ]
[ slot slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display usage information for the
NHLFE entries.
display mpls nhlfe reflist token [ slot
slot-number ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
77
Task
Command
Remarks
Display information about static
LSPs.
display mpls static-lsp [ lsp-name
lsp-name ] [ { exclude | include } dest-addr
mask-length ] [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display LSP-related route
information.
display mpls route-state [ vpn-instance
vpn-instance-name ] [ dest-addr
mask-length ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display MPLS statistics for all
LSPs or the LSP with a specific
index or name.
display mpls statistics lsp { index | all |
name lsp-name } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display MPLS statistics for one or
all interfaces.
display mpls statistics interface
{ interface-type interface-number | all } [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display MPLS statistics for all
LSPs or the LSP with a specific
incoming label.
display mpls statistics lsp [ in-label
in-label ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Displaying MPLS LDP operation
Task
Command
Remarks
Display information about LDP.
display mpls ldp [ all [ verbose ] [ |
{ begin | exclude | include }
regular-expression ] ]
Available in any view.
Display label advertisement
information for the specified FEC.
display mpls ldp fec [ vpn-instance
vpn-instance-name ] dest-addr
mask-length [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about
LDP-enabled interfaces.
display mpls ldp interface [ all
[ verbose ] | [ vpn-instance
vpn-instance-name ] [ interface-type
interface-number | verbose ] ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about LDP
peers.
display mpls ldp peer [ all [ verbose ] |
[ vpn-instance vpn-instance-name ]
[ peer-id | verbose ] ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about remote
LDP peers.
display mpls ldp remote-peer
[ remote-name remote-peer-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about LDP
sessions between LDP peers.
display mpls ldp session [ all [ verbose ]
| [ vpn-instance vpn-instance-name ]
[ peer-id | verbose ] ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display statistics about all LSP
sessions.
display mpls ldp session all statistics [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
78
Task
Command
Remarks
Display information about LSPs
established by LDP.
display mpls ldp lsp [ all | [ vpn-instance
vpn-instance-name ] [ dest-addr
mask-length ] ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
NOTE:
The vpn-instance vpn-instance-name option is used to specify information about an LDP instance.
For information about LDP instances, see "Configuring MPLS L3VPN."
Clearing MPLS statistics
Task
Command
Remarks
Clear MPLS statistics for one or
all MPLS interfaces.
reset mpls statistics interface
{ interface-type interface-number | all }
Available in user view.
Clear MPLS statistics for all LSPs
or the LSP with a specific index or
name.
reset mpls statistics lsp { index | all |
name lsp-name }
Available in user view.
MPLS configuration examples
This section provides examples of MPLS configuration.
Configuring static LSPs
Network requirements
Switch A, Switch B, and Switch C support MPLS.
Establish static LSPs between Switch A and Switch C so that subnets 11.1.1.0/24 and 21.1.1.0/24
can access each other over MPLS. Test the connectivity of the static LSPs.
Figure 24 Network diagram
Loop0
2.2.2.9/32
Loop0
1.1.1.9/32
Loop0
3.3.3.9/32
Vlan-int2
10.1.1.1/24
Vlan-int4
11.1.1.1/24
Vlan-int3
20.1.1.2/24
Switch A
Vlan-int5
21.1.1.1/24
Vlan-int3
20.1.1.1/24
Vlan-int2
10.1.1.2/24
Switch B
11.1.1.0/24
Switch C
21.1.1.0/24
Configuration considerations
•
On an LSP, the out label of an upstream LSR must be identical with the in label of its
downstream LSR.
•
Configure an LSP for each direction on the forwarding path.
79
•
Configure a static route to the destination address of the LSP on each ingress node. Such a
route is not required on the transit and egress nodes. You do not need to configure any routing
protocol on the switches.
Configuration procedure
1.
Configure IP addresses for the interfaces, according to Figure 24. (Details not shown.)
2.
Configure a static route to the FEC destination address on each ingress node:
# Configure a static route to network 21.1.1.0/24 on Switch A.
<SwitchA> system-view
[SwitchA] ip route-static 21.1.1.0 24 10.1.1.2
# Configure a static route to network 11.1.1.0/24 on Switch C.
<SwitchC> system-view
[SwitchC] ip route-static 11.1.1.0 255.255.255.0 20.1.1.1
3.
Enable MPLS:
# Configure MPLS on Switch A.
[SwitchA] mpls lsr-id 1.1.1.9
[SwitchA] mpls
[SwitchA-mpls] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] mpls
[SwitchA-Vlan-interface2] quit
# Configure MPLS on Switch B.
[SwitchB] mpls lsr-id 2.2.2.9
[SwitchB] mpls
[SwitchB-mpls] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] mpls
[SwitchB-Vlan-interface2] quit
[SwitchB] interface vlan-interface 3
[SwitchB-Vlan-interface3] mpls
[SwitchB-Vlan-interface3] quit
# Configure MPLS on Switch C.
[SwitchC] mpls lsr-id 3.3.3.9
[SwitchC] mpls
[SwitchC-mpls] quit
[SwitchC] interface vlan-interface 3
[SwitchC-Vlan-interface3] mpls
[SwitchC-Vlan-interface3] quit
4.
Create a static LSP from Switch A to Switch C:
# Configure the LSP ingress, Switch A.
[SwitchA] static-lsp ingress AtoC destination 21.1.1.0 24 nexthop 10.1.1.2 out-label
30
# Configure the LSP transit node, Switch B.
[SwitchB] static-lsp transit AtoC incoming-interface vlan-interface 2 in-label 30
nexthop 20.1.1.2 out-label 50
# Configure the LSP egress, Switch C.
[SwitchC] static-lsp egress AtoC incoming-interface vlan-interface 3 in-label 50
5.
Create a static LSP from Switch C to Switch A:
80
# Configure the LSP ingress, Switch C.
[SwitchC] static-lsp ingress CtoA destination 11.1.1.0 24 nexthop 20.1.1.1 out-label
40
# Configure the LSP transit node, Switch B.
[SwitchB] static-lsp transit CtoA incoming-interface vlan-interface 3 in-label 40
nexthop 10.1.1.1 out-label 70
# Configure the LSP egress, Switch A.
[SwitchA] static-lsp egress CtoA incoming-interface vlan-interface 2 in-label 70
6.
Verify the configuration:
# Execute the display mpls static-lsp command on each switch to display static LSP
information. Take Switch A as an example:
[SwitchA] display mpls static-lsp
total statics-lsp : 2
Name
FEC
AtoC
21.1.1.0/24
CtoA
-/-
I/O Label
NULL/30
70/NULL
I/O If
-/Vlan2
Vlan2/-
State
Up
Up
# On Switch A, test the connectivity of the LSP from Switch A to Switch C.
[SwitchA] ping lsp -a 11.1.1.1 ipv4 21.1.1.0 24
LSP Ping FEC: IPV4 PREFIX 21.1.1.0/24 : 100
data bytes, press CTRL_C to break
Reply from 20.1.1.2: bytes=100 Sequence=1 time = 2 ms
Reply from 20.1.1.2: bytes=100 Sequence=2 time = 2 ms
Reply from 20.1.1.2: bytes=100 Sequence=3 time = 1 ms
Reply from 20.1.1.2: bytes=100 Sequence=4 time = 2 ms
Reply from 20.1.1.2: bytes=100 Sequence=5 time = 2 ms
--- FEC: IPV4 PREFIX 21.1.1.0/24 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 ms
# On Switch C, test the connectivity of the LSP from Switch C to Switch A.
[SwitchC] ping lsp -a 21.1.1.1 ipv4 11.1.1.0 24
LSP Ping FEC: IPV4 PREFIX 11.1.1.0/24 : 100
data bytes, press CTRL_C to break
Reply from 10.1.1.1: bytes=100 Sequence=1 time = 3 ms
Reply from 10.1.1.1: bytes=100 Sequence=2 time = 2 ms
Reply from 10.1.1.1: bytes=100 Sequence=3 time = 2 ms
Reply from 10.1.1.1: bytes=100 Sequence=4 time = 2 ms
Reply from 10.1.1.1: bytes=100 Sequence=5 time = 2 ms
--- FEC: IPV4 PREFIX 11.1.1.0/24 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 2/2/3 ms
81
Configuring LDP to establish LSPs dynamically
Network requirements
Switch A, Switch B, and Switch C support MPLS.
Configure LDP to establish LSPs between Switch A and Switch C so that subnets 11.1.1.0/24 and
21.1.1.0/24 can reach each other over MPLS. Test the connectivity of the LSPs.
Figure 25 Network diagram
Loop0
2.2.2.9/32
Loop0
1.1.1.9/32
Loop0
3.3.3.9/32
Vlan-int2
10.1.1.1/24
Vlan-int4
11.1.1.1/24
Vlan-int3
20.1.1.2/24
Switch A
Vlan-int5
21.1.1.1/24
Vlan-int3
20.1.1.1/24
Vlan-int2
10.1.1.2/24
Switch B
Switch C
11.1.1.0/24
21.1.1.0/24
Configuration considerations
•
Enable LDP on the LSRs. LDP dynamically distributes labels and establishes LSPs and thus
there is no need to manually configure labels for LSPs.
•
LDP uses routing information for label distribution. You must configure a routing protocol to
learn routing information. OSPF is used in this example.
Configuration procedure
1.
Configure IP addresses for the interfaces, according to Figure 25. (Details not shown.)
2.
Configure OSPF to ensure IP connectivity between the switches:
# Configure OSPF on Switch A.
<Sysname> system-view
[Sysname] sysname SwitchA
[SwitchA] ospf
[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[SwitchA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] network 11.1.1.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
# Configure OSPF on Switch B.
<Sysname> system-view
[Sysname] sysname SwitchB
[SwitchB] ospf
[SwitchB-ospf-1] area 0
[SwitchB-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0
[SwitchB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchB-ospf-1] quit
82
# Configure OSPF on Switch C.
<Sysname> system-view
[Sysname] sysname SwitchC
[SwitchC] ospf
[SwitchC-ospf-1] area 0
[SwitchC-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0
[SwitchC-ospf-1-area-0.0.0.0] network 20.1.1.0 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.0] network 21.1.1.0 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.0] quit
[SwitchC-ospf-1] quit
# Execute the display ip routing-table command on each switch. You will see that each switch
has learned the routes to other switches. Take Switch A as an example:
[SwitchA] display ip routing-table
Routing Tables: Public
Destinations : 11
3.
Destination/Mask
Proto
1.1.1.9/32
Routes : 11
Pre
Cost
NextHop
Interface
Direct 0
0
127.0.0.1
InLoop0
2.2.2.9/32
OSPF
10
1
10.1.1.2
Vlan2
3.3.3.9/32
OSPF
10
2
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
11.1.1.0/24
Direct 0
0
11.1.1.1
Vlan4
11.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
20.1.1.0/24
OSPF
10
2
10.1.1.2
Vlan2
21.1.1.0/24
OSPF
10
3
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
Enable MPLS and MPLS LDP:
# Configure MPLS and MPLS LDP on Switch A.
[SwitchA] mpls lsr-id 1.1.1.9
[SwitchA] mpls
[SwitchA-mpls] quit
[SwitchA] mpls ldp
[SwitchA-mpls-ldp] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] mpls
[SwitchA-Vlan-interface2] mpls ldp
[SwitchA-Vlan-interface2] quit
# Configure MPLS and MPLS LDP on Switch B.
[SwitchB] mpls lsr-id 2.2.2.9
[SwitchB] mpls
[SwitchB-mpls] quit
[SwitchB] mpls ldp
[SwitchB-mpls-ldp] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] mpls
83
[SwitchB-Vlan-interface2] mpls ldp
[SwitchB-Vlan-interface2] quit
[SwitchB] interface vlan-interface 3
[SwitchB-Vlan-interface3] mpls
[SwitchB-Vlan-interface3] mpls ldp
[SwitchB-Vlan-interface3] quit
# Configure MPLS and MPLS LDP on Switch C.
[SwitchC] mpls lsr-id 3.3.3.9
[SwitchC] mpls
[SwitchC-mpls] quit
[SwitchC] mpls ldp
[SwitchC-mpls-ldp] quit
[SwitchC] interface vlan-interface 3
[SwitchC-Vlan-interface3] mpls
[SwitchC-Vlan-interface3] mpls ldp
[SwitchC-Vlan-interface3] quit
After the configuration is complete, two local LDP sessions are established, one between
Switch A and Switch B and the other between Switch B and Switch C.
# Execute the display mpls ldp session command on each switch to display the LDP session
information, and execute the display mpls ldp peer command to display the LDP peer
information. Take Switch A as an example:
[SwitchA] display mpls ldp session
LDP Session(s) in Public Network
Total number of sessions: 1
---------------------------------------------------------------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
[SwitchA] display mpls ldp peer
LDP Peer Information in Public network
Total number of peers: 1
----------------------------------------------------------------Peer-ID
Transport-Address
Discovery-Source
---------------------------------------------------------------2.2.2.9:0
2.2.2.9
Vlan-interface2
----------------------------------------------------------------
4.
Allow all static routes and IGP routes to trigger LDP to establish LSPs:
# Configure the LSP establishment triggering policy on Switch A.
[SwitchA] mpls
[SwitchA-mpls] lsp-trigger all
[SwitchA-mpls] return
# Configure the LSP establishment triggering policy on Switch B.
[SwitchB] mpls
[SwitchB-mpls] lsp-trigger all
[SwitchB-mpls] quit
# Configure the LSP establishment triggering policy on Switch C.
84
[SwitchC] mpls
[SwitchC-mpls] lsp-trigger all
[SwitchC-mpls] quit
5.
Verify the configuration:
# Execute the display mpls ldp lsp command on each switch to display the LDP LSP
information. Take Switch A as an example:
<SwitchA> 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
-------/InLoop0
2
2.2.2.9/32
NULL/3
10.1.1.2
-------/Vlan2
3
3.3.3.9/32
NULL/1024
10.1.1.2
-------/Vlan2
4
11.1.1.0/24
3/NULL
0.0.0.0
-------/Vlan4
5
20.1.1.0/24
NULL/3
10.1.1.2
-------/Vlan2
6
21.1.1.0/24
NULL/1027
10.1.1.2
-------/Vlan2
------------------------------------------------------------------A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
# On Switch A, test the connectivity of the LDP LSP from Switch A to Switch C.
[SwitchA] ping lsp ipv4 21.1.1.0 24
LSP Ping FEC: IPV4 PREFIX 21.1.1.0/24 : 100
data bytes, press CTRL_C to break
Reply from 20.1.1.2: bytes=100 Sequence=1 time = 3 ms
Reply from 20.1.1.2: bytes=100 Sequence=2 time = 2 ms
Reply from 20.1.1.2: bytes=100 Sequence=3 time = 1 ms
Reply from 20.1.1.2: bytes=100 Sequence=4 time = 1 ms
Reply from 20.1.1.2: bytes=100 Sequence=5 time = 3 ms
--- FEC: IPV4 PREFIX 21.1.1.0/24 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/2/3 ms
# On Switch C, test the connectivity of the LDP LSP from Switch C to Switch A.
[SwitchC] ping lsp ipv4 11.1.1.0 24
LSP Ping FEC: IPV4 PREFIX 11.1.1.0/24 : 100
data bytes, press CTRL_C to break
Reply from 10.1.1.1: bytes=100 Sequence=1 time = 2 ms
Reply from 10.1.1.1: bytes=100 Sequence=2 time = 2 ms
Reply from 10.1.1.1: bytes=100 Sequence=3 time = 2 ms
Reply from 10.1.1.1: bytes=100 Sequence=4 time = 3 ms
Reply from 10.1.1.1: bytes=100 Sequence=5 time = 2 ms
--- FEC: IPV4 PREFIX 11.1.1.0/24 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 2/2/3 ms
85
Configuring BFD for LSPs
Network requirements
As shown in Figure 25, use LDP to establish an LSP from 11.1.1.0/24 to 21.1.1.0/24, and an LSP
from 21.1.1.0/24 to 11.1.1.0/24. Configure BFD for the LSPs to detect LSP failures.
Configuration procedure
1.
Configure LDP sessions (see "Configuring LDP to establish LSPs dynamically.")
2.
Enable BFD for LSPs:
# Configure Switch A.
<SwitchA> system-view
[SwitchA] mpls lspv
[SwitchA -mpls-lspv] bfd enable 21.1.1.0 24
[SwitchA -mpls-lspv] quit
# Configure Switch C.
<SwitchC> system-view
[SwitchC] mpls lspv
[SwitchC-mpls-lspv] bfd enable 11.1.1.0 24
[SwitchC-mpls-lspv] quit
3.
Verify the configuration:
Execute the display mpls lsp bfd command on Switch A and Switch C to display information
about the sessions established for the LSPs. Take Switch A as an example:
[SwitchA] display mpls lsp bfd
MPLS BFD Session(s) Information
----------------------------------------------------------------------------FEC
: 11.1.1.0/24
Type
Local Discr
: 130
Remote Discr : 130
Tunnel ID
: ---
NextHop
: ---
Source IP
: 3.3.3.9
: LSP
Session State : Up
: LSP
Session Role
: Passive
FEC
: 21.1.1.0/24
Type
Local Discr
: 129
Remote Discr : 129
Tunnel ID
: 0x6040000
NextHop
: 10.1.1.2
Source IP
: 1.1.1.9
Session State : Up
Session Role
: Active
Total Session Num: 2
The output shows that two BFD sessions have been established between Switch A and Switch
C: one for testing the connectivity of the LSP Switch A-Switch B-Switch C, and the other for
testing the connectivity of the LSP Switch C-Switch B-Switch A.
Use the following command to display detailed information about BFD sessions:
[SwitchA] display bfd session verbose
Total session number: 2
Up session number: 2
IPv4 session working under Ctrl mode:
86
Init mode: Active
Local Discr: 129
Remote Discr: 129
Source IP: 1.1.1.9
Destination IP: 127.0.0.1
Session State: Up
Interface: LoopBack0
Min Trans Inter: 400ms
Act Trans Inter: 400ms
Min Recv Inter: 400ms
Act Detect Inter: 2000ms
Running Up for: 00:15:52
Auth mode: None
Connect Type: Indirect
Board Num: 6
Protocol: MFW/LSPV
Diag Info: No Diagnostic
Local Discr: 130
Remote Discr: 130
Source IP: 1.1.1.9
Destination IP: 3.3.3.9
Session State: Up
Interface: LoopBack0
Min Trans Inter: 400ms
Act Trans Inter: 400ms
Min Recv Inter: 400ms
Act Detect Inter: 2000ms
Running Up for: 00:15:44
Auth mode: None
Connect Type: Indirect
Board Num: 7
Protocol: MFW/LSPV
Diag Info: No Diagnostic
87
Configuring MPLS TE
This chapter describes how to configure MPLS TE.
Hardware compatibility
The HPE 5820X Switch Series does not support MPLS TE.
MPLS TE overview
Network congestion is one of the major problems that can degrade your network backbone
performance. It may occur either when network resources are inadequate or when load distribution is
unbalanced. Traffic engineering (TE) is intended to avoid the latter situation where partial congestion
may occur because of inefficient resource allocation.
TE can make the best utilization of network resources and avoid non-even load distribution by
real-time monitoring traffic and traffic load on each network elements to dynamically tune traffic
management attributes, routing parameters and resources constraints.
The performance objectives of TE can be classified as either traffic-oriented or resource-oriented.
•
Traffic-oriented performance objectives enhance QoS of traffic streams, such as minimization
of packet loss, minimization of delay, maximization of throughput and enforcement of SLA.
•
Resource-oriented performance objectives optimize resources utilization. Bandwidth is a
crucial resource on networks. Efficiently managing it is a major task of TE.
To implement TE, you can use IGPs or MPLS.
Because IGPs are topology-driven and consider only network connectivity, they fail to present some
dynamic factors such as bandwidth and traffic characteristics.
This IGP disadvantage can be repaired by using an overlay model, such as IP over ATM or IP over
FR. An overlay model provides a virtual topology on top of the physical network topology for a more
scalable network design. It also provides better traffic and resources control support for
implementing a variety of traffic engineering policies.
Despite all the benefits, overlay models are not suitable for implementing traffic engineering in
large-sized backbones because of their inadequacy in extensibility. In this sense, MPLS TE is a
better traffic engineering solution for its extensibility and ease of implementation.
MPLS is better than IGPs in implementing traffic engineering for the following reasons:
•
MPLS supports explicit LSP routing.
•
LSP routing is easy to manage and maintain compared to traditional packet-by-packet IP
forwarding.
•
MPLS TE uses less system resources compared with other traffic engineering
implementations.
MPLS TE combines the MPLS technology and traffic engineering. It delivers the following benefits:
•
Reserve resources by establishing LSP tunnels to specific destinations, allowing traffic to
bypass congested nodes to achieve appropriate load distribution.
•
When network resources are insufficient, MPLS TE allows bandwidth-hungry LSPs or critical
user traffic to occupy the bandwidth for lower priority LSP tunnels.
•
In case an LSP tunnel fails or congestion occurs on a network node, MPLS TE can provide
route backup and Fast Reroute (FRR).
88
With MPLS TE, a network administrator can eliminate network congestion by creating some LSPs
and congestion bypass nodes. Special offline tools are also available for the traffic analysis
performed when the number of LSPs is large.
Basic concepts
•
LSP tunnel
On an LSP, after packets are labeled at the ingress node, the packets are forwarded based on
label. The traffic is transparent to the transits nodes on the LSP. In this sense, an LSP can be
regarded as a tunnel.
•
MPLS TE tunnel
Rerouting and transmission over multiple paths may involve multiple LSP tunnels. A set of such
LSP tunnels is called a traffic engineered tunnel (TE tunnel).
MPLS TE implementation
MPLS TE accomplishes the following functions:
•
Static Constraint-based Routed LSP (CR-LSP) processing—Creates and removes static
CR-LSPs. The bandwidth of a static CR-LSP must be configured manually.
•
Dynamic CR-LSP processing—Handles three types of CR-LSPs: basic CR-LSPs, backup
CR-LSPs and fast rerouted CR-LSPs.
Static CR-LSP processing is simple. Dynamic CR-LSP processing is more complex and involves
four phrases: advertising TE attributes, calculating paths, establishing paths, and forwarding
packets.
Advertising TE attributes
MPLS TE must be aware of dynamic TE attributes of each link on the network, which is achieved by
extending link state-based IGPs such as OSPF and IS-IS.
OSPF and IS-IS extensions add to link states such TE attributes as link bandwidth, color, among
which maximum reservable link bandwidth and non-reserved bandwidth with a particular priority are
most important.
Each node collects the TE attributes of all links on all routers within the local area or at the same level
to build up a TE database (TEDB).
Calculating paths
Link state-based routing protocols use SPF to calculate the shortest path to each network node.
In MPLS TE, the CSPF algorithm is used to calculate the shortest, TE compliant path to a node. It is
derived from SPF and makes calculations based on the following conditions:
•
Constraints on the LSP to be set up with respect to bandwidth, color, setup/holding priority,
explicit path and other constraints. They are configured at the LSP ingress.
•
TEDB
CSPF first prunes TE attribute incompliant links from the TEDB and then performs SPF calculation to
identify the shortest path to an LSP egress.
Establishing paths
Two signaling protocols, CR-LDP and RSVP-TE, can be used to set up LSP tunnels. Both can carry
constraints such as LSP bandwidth, some explicit route information, and color and deliver the same
function.
They are different in that CR-LDP establishes LSPs using TCP, and RSVP-TE uses raw IP.
89
RSVP is a well-established technology in terms of its architecture, protocol procedures and support
to services. CR-LDP is an emerging technology with better scalability.
The switch supports only RSVP-TE.
Forwarding packets
Packets are forwarded over established tunnels.
CR-LSP
Unlike ordinary LSPs established based on routing information, CR-LSPs are established based on
criteria such as bandwidth, selected path, and QoS parameters, in addition to routing information.
The mechanism for setting up and managing constraints is called "Constraint-based Routing (CR)."
CR-LSP uses the following concepts:
•
Strict and loose explicit routes
•
Traffic characteristics
•
Preemption
•
Route pinning
•
Administrative group and affinity attribute
•
Reoptimization
Strict and loose explicit routes
An LSP is called a strict explicit route if all LSRs along the LSP are specified.
An LSP is called a loose explicit route if the downstream LSR selection conditions rather than LSRs
are defined.
Traffic characteristics
Traffic is described in terms of peak rate, committed rate, and service granularity.
The peak and committed rates describe the bandwidth constraints of a path while the service
granularity specifies a constraint on the delay variation that the CR-LDP MPLS domain may
introduce to a path's traffic.
Preemption
During establishment of a CR-LSP, if a path with sufficient resources cannot be found, the CR-LSP
can be established by preempting the resources of a lower-priority CR-LSP. This is called path
preemption.
Two priorities, setup priority and holding priority, are assigned to CR-LSPs for making preemption
decision. Both setup and holding priorities range from 0 to 7, with a lower numerical number
indicating a higher priority.
For a new path to preempt an existing path, the setup priority of the new path must be greater than
the holding priority of the existing path. To initiate a preemption, the Resv message of RSVP-TE is
sent.
To avoid flapping caused by improper preemptions between CR-LSPs, the setup priority of a
CR-LSP must not be set higher than its holding priority.
Route pinning
Route pinning prevents an established CR-LSP from changing upon route changes.
If a network does not run IGP TE extension, the network administrator is unable to identify from
which part of the network the required bandwidth can be obtained when setting up a CR-LSP. In this
case, loose explicit route (ER-hop) with required resources is used. The established CR-LSP,
however, may change when the route changes, for example, when a better next hop becomes
90
available. If this is undesirable, the network administrator can set up the CR-LSP using route
underpinning to make it a permanent path.
Administrative group and affinity attribute
The affinity attribute of an MPLS TE tunnel identifies the properties of the links that the tunnel can
use. Together with the link administrative group, it decides which links the MPLS TE tunnel can use.
Reoptimization
Traffic engineering is a process of allocating or reallocating network resources. You can configure it
to meet desired QoS.
Typically, service providers use some mechanism to optimize CR-LSPs for best use of network
resources. They can do this manually but CR-LSP measurement and tuning are required.
Alternatively, they can use MPLS TE where CR-LSPs are dynamically optimized.
Dynamic CR-LSP optimization involves periodic calculation of paths that traffic trunks traverse. If a
better route is found for an existing CR-LSP, a new CR-LSP is established to replace the old one, and
services are switched to the new CR-LSP.
RSVP-TE
Two QoS models are available: IntServ and DiffServ.
Resource Reservation Protocol (RSVP) is designed for IntServ. It reserves resources on each node
along a path. RSVP operates at the transport layer but does not participate in data transmission. It is
an Internet control protocol similar to ICMP.
Features of RSVP:
•
Unidirectional
•
Receiver oriented. The receiver initiates resource reservation requests and is responsible for
maintaining the reservation information.
•
Using soft state mechanism to maintain resource reservation information.
Extended RSVP can support MPLS label distribution and allow resource reservation information to
be transmitted with label bindings. This extended RSVP is called "RSVP-TE," which is operating as a
signaling protocol for LSP tunnel setup in MPLS TE.
Basic concepts
•
Soft state
Soft state is a mechanism used in RSVP-TE to periodically refresh the resource reservation
state on a node. The resource reservation state includes the path state and the reservation
state. The path state is generated and refreshed by the Path message. The reservation state is
generated and refreshed by the Resv message. A state is to be removed if no refresh
messages are received for it in certain interval.
•
Resource reservation style
Each LSP set up using RSVP-TE is assigned a resource reservation style. During an RSVP
session, the receiver decides which reservation style to use for this session and which LSPs to
use.
The following reservation styles are available:
{
{
Fixed-filter (FF) style—Resources are reserved for individual senders and cannot be
shared among senders on the same session.
Shared-explicit (SE) style—Resources are reserved for senders on the same session and
shared among them.
91
NOTE:
SE is only used for make-before-break because multiple LSPs cannot be present on the same
session.
Make-before-break
Make-before-break is a mechanism to change MPLS TE tunnel attributes with minimum data loss
and without extra bandwidth.
Figure 26 Diagram for make-before-break
Figure 26 presents a scenario where a path Router A → Router B → Router C → Router D is
established with 30 Mbps reserved bandwidth between Router A and Router D. The remaining
bandwidth is then 30 Mbps.
If 40 Mbps path bandwidth is requested, the remaining bandwidth of the Router A → Router B →
Router C → Router D path is inadequate. You cannot address the problem by selecting another path,
Router A → Router E → Router C → Router D, because the bandwidth of the Router C → Router D
link is inadequate.
To address the problem, you can use the make-before-break mechanism. It allows the new path to
share the bandwidth of the original path at the Router C → Router D link. Upon creation of the new
path, traffic is switched to the new path and the previous path is torn down. This helps avoid traffic
interruption effectively.
RSVP-TE messages
RSVP-TE uses RSVP messages with extensions. The RSVP messages are as follows:
•
Path messages—Transmitted along the path of data transmission downstream by each RSVP
sender to save path state information on each node along the path.
Resv messages—Sent by each receiver upstream towards senders to request resource
reservation and to create and maintain reservation state on each node along the reverse of data
transmission path.
•
PathTear messages—Sent downstream to remove the path state and related reservation state
on each node along the path.
•
ResvTear messages—Sent upstream to remove the reservation state on each node along the
path.
•
PathErr messages—Sent upstream to report Path message processing errors to senders.
They do not affect the state of the nodes along the path.
•
ResvErr messages—Sent downstream to notify the downstream nodes that an error occurs
during Resv message processing or reservation error occurs as the result of preemption.
•
ResvConf messages—Sent to receivers to confirm Resv messages.
•
Hello messages—Sent between any two directly connected RSVP neighbors to set up and
maintain the neighbor relationship that has local significance on the link.
The TE extension to RSVP adds new objects to the Path message and the Resv message. These
objects carry not only label bindings but also routing constraints, supporting CR-LSP and FRR.
92
•
New objects added to the Path message include LABEL_REQUEST, EXPLICIT_ROUTE,
RECORD_ROUTE, and SESSION_ATTRIBUTE.
•
New objects added to the Resv message include LABEL and RECORD_ROUTE
The LABEL_REQUEST object in the Path message requests the label bindings for an LSP. It is also
saved in the path state block. The node receiving LABEL_REQUEST advertises the label binding
using the LABEL object in the Resv message to the upstream node, accomplishing label
advertisement and transmission.
Setting up an LSP tunnel
Figure 27 Setting up an LSP tunnel
The following is a simplified procedure for setting up an LSP tunnel with RSVP:
1.
The ingress LSR sends a Path message that carries the label request information, and then
forwards the message along the path calculated by CSPF hop-by-hop towards the egress LSR.
2.
After receiving the Path message, the egress generates a Resv message carrying the
reservation information and label and then forwards the message towards the ingress along the
reverse direction of the path along which the Path message travels. The LSRs that the Resv
message traverses along the path reserve resources as required.
3.
When the ingress LSR receives the Resv message, LSP is established.
As resources are reserved on the LSRs along the path for the LSP established by using RSVP-TE,
services transmitted on the LSP are guaranteed.
RSVP refresh mechanism
RSVP maintains path and reservation state by periodically retransmitting two types of
messages—Path and Resv. These periodically retransmitted Path and Resv messages are called
refresh messages. They are sent along the path that the last Path or Resv message travels to
synchronize the state between RSVP neighbors and to recover lost RSVP messages.
When many RSVP sessions are present, periodically sent refresh messages become a network
burden. In addition, for some delay sensitive applications, the refreshing delay they must wait for
recovering lost RSVP messages may be unbearable. Because tuning refresh intervals is not
adequate to address the two problems, the refreshing mechanism was extended in RFC 2961 RSVP
Refresh Overhead Reduction Extensions to address the problems.
•
Message_ID extension
RSVP itself uses Raw IP to send messages. The Message_ID extension mechanism defined in
RFC 2961 adds objects that can be carried in RSVP messages. Of them, the Message_ID
object and the Message_ID_ACK object are used to acknowledge RSVP messages, improving
transmission reliability.
On an interface enabled with the Message_ID mechanism, you can configure RSVP message
retransmission. If a node sends a message carrying the Message_ID object, and the
ACK_Desired flag in the object is set, the node expects a response that carries the
Message_ID_ACK object during the initial retransmission interval (Rf). If the node does not
receive the response within the Rf interval, it resends the message and sets the retransmission
interval to (1+Delta) × Rf. The node repeats such retransmissions until it receives the
corresponding response within the retransmission time or the number of retransmission
attempts reaches the limit.
•
Summary refresh extension
93
Send summary refreshes (Srefreshes) rather than retransmit standard Path or Resv messages
to refresh related RSVP state. This reduces refresh traffic and allows nodes to make faster
processing.
To use summary refresh, you must use the Message_ID extension. Only states advertised
using MESSAGE_ID included Path and Resv messages can be refreshed using summary
refreshes.
PSB, RSB and BSB timeouts
To create an LSP tunnel, the sender sends a Path message with a LABEL_REQUEST object. After
receiving this Path message, the receiver assigns a label for the path and puts the label binding in
the LABEL object in the returned Resv message.
The LABEL_REQUEST object is stored in the path state block (PSB) on the upstream nodes, while
the LABEL object is stored in the reservation state block (RSB) on the downstream nodes. The state
stored in the PSB or RSB object times out and is removed after the number of consecutive
non-refreshing times exceeds the PSB or RSB timeout keep-multiplier.
Sometimes, although a reservation request does not pass admission control on some node, you may
want to store the resource reservation state for it while allowing other requests to use the resources
reserved for the request. In this case, the node transits to the blockade state and a blockade state
block (BSB) is created on each downstream node. When the number of non-refreshing times
exceeds the blockade multiplier, the blockade state is removed.
RSVP-TE GR
RSVP-TE GR preserves the soft state and label forwarding information when the signaling protocol
or control plane fails, so that LSRs can still forward packets according to forwarding entries, ensuring
continuous data transmission.
A device that participates in an RSVP-TE GR process plays either of the following roles:
•
GR restarter—Router that gracefully restarts due to a manually configured command or a fault.
It must be GR-capable.
•
GR helper—Neighbor of the GR restarter. A GR helper maintains the neighbor relationship with
the GR restarter and helps the GR restarter restore its LFIB information. A GR helper must be
GR-capable.
The RSVP-TE GR function depends on the extended hello capability of RSVP-TE. A GR-capable
device advertises its GR capability and relevant time parameters to its neighbors by extended RSVP
hello packets. If a device and all its neighbors have the RSVP GR capability and have exchanged
GR parameters, each of them can function as the GR helper of another device, allowing data to be
forwarded without interruption when the GR restarter is rebooting.
A GR helper considers that a GR restarter is rebooting when it receives no Hello packets from the
restarter in a specific period of time. When a GR restarter is rebooting, the GR helpers retain soft
state information about the GR restarter and keep sending Hello packets periodically to the GR
restarter until the restart timer expires.
If a GR helper and the GR restarter reestablish a Hello session before the restart timer expires, the
recovery timer is started and signaling packet exchanging is triggered to restore the original soft
state. Otherwise, all RSVP soft state information and forwarding entries relevant to the neighbor are
removed. If the recovery timer expires, soft state information and forwarding entries that are not
restored during the GR restarting process are removed.
The switch, if configured with RSVP-TE GR, can act as both a GR restarter and a GR helper.
Traffic forwarding
For traffic to travel along an LSP tunnel, you must perform the configuration after creating the MPLS
TE tunnel. Otherwise, traffic is IP routed.
94
Even when an MPLS TE tunnel is available, traffic is IP routed if you do not configure it to travel the
tunnel. For traffic to be routed along an MPLS TE tunnel, you can use static routing, policy-based
routing, or automatic route advertisement.
Static routing
Static routing is the easiest way to route traffic along an MPLS TE tunnel. You only need to manually
create a route that reaches the destination through the tunnel interface.
For more information about static routing, see Layer 3—IP Routing Configuration Guide.
Policy-based routing
You can also use policy-based routing to route traffic over an MPLS TE tunnel. In this approach,
create a policy that specifies the MPLS TE tunnel interface as the output interface for traffic that
matches certain criteria defined in the referenced ACL.
This policy should be applied to the incoming interface.
For more information about policy-based routing, see Layer 3—IP Routing Configuration Guide.
Automatic route advertisement
You can use automatic route advertisement to advertise MPLS TE tunnel interface routes to IGPs,
allowing traffic to be routed down MPLS TE tunnels.
Two approaches are available to automatic route advertisement—IGP shortcut and forwarding
adjacency.
OSPF and IS-IS support both approaches where TE tunnels are considered point-to-point links and
TE tunnel interfaces can be set as outgoing interfaces.
IGP shortcut, also known as autoroute announce, considers a TE tunnel as a logical interface
directly connected to the destination when computing IGP routes on the ingress of the TE tunnel.
IGP shortcut and forwarding adjacency are different in that in the forwarding adjacency approach,
routes with TE tunnel interfaces as outgoing interfaces are advertised to neighboring devices but not
in the IGP shortcut approach. Therefore, TE tunnels are visible to other devices in the forwarding
adjacency approach but not in the IGP shortcut approach.
Figure 28 IGP shortcut and forwarding adjacency
A TE tunnel is present between Router D and Router C. With IGP shortcut enabled, the ingress node
Router D can use this tunnel when calculating IGP routes. This tunnel, however, is invisible to Router
A. Router A cannot use this tunnel to reach Router C. With forwarding adjacency enabled, Router A
can know the presence of the TE tunnel and forward traffic to Router C to Router D though this
tunnel.
95
The configuration of IGP shortcut and forwarding adjacency is broken down into tunnel configuration
and IGP configuration. When making tunnel configuration on a TE tunnel interface, consider the
following:
•
The tunnel destination address must be in the same area where the tunnel interface is located.
•
The tunnel destination address must be reachable through intra-area routing.
Bidirectional MPLS TE tunnel
MPLS Transport Profile uses bidirectional MPLS TE tunnels to implement 1:1 and 1+1 protection
switching and support in-band detection tools and signaling protocols such as OAM and PSC.
A bidirectional MPLS TE tunnel contains two CR-LSPs in opposite directions. It can be established in
co-routed mode or associated mode:
•
Co-routed mode uses the extended RSVP-TE protocol to establish a bidirectional MPLS TE
tunnel. RSVP-TE uses a Path message to advertise labels assigned by the upstream LSR to
the downstream LSR and a Resv message to advertise labels assigned by the downstream
LSR to the upstream LSR. The path message establishes a CR-LSP in one direction. The Resv
message establishes a CR-LSP in the other direction. The CR-LSPs of a bidirectional MPLS TE
tunnel use the same path.
•
In associated mode, you establish a bidirectional MPLS TE tunnel by binding two unidirectional
CR-LSPs in opposite directions. The two CR-LSPs can be established in different modes and
use different paths. For example, one CR-LSP is established statically and the other CR-LSP is
established dynamically by RSVP-TE.
CR-LSP backup
CR-LSP backup provides end-to-end path protection for the entire LSP without time limitation. This is
different from FRR, which provides quick but temporary per-link or per-node protection on an LSP.
In the same TE tunnel, the LSP used to back up a primary LSP is called a secondary LSP. When the
ingress of a TE tunnel detects that the primary LSP is unavailable, it switches traffic to the secondary
LSP and after the primary LSP becomes available, switches traffic back. This is how LSP path
protection is achieved.
The following approaches are available for CR-LSP backup:
•
Hot backup where a secondary CR-LSP is created immediately after a primary CR-LSP is
created. MPLS TE switches traffic to the secondary CR-LSP after the primary CR-LSP fails.
•
Standard backup where a secondary CR-LSP is created to take over after the primary CR-LSP
fails.
FRR
FRR provides a quick per-link or per-node protection on an LSP.
In this approach, once a link or node fails on a path, FRR comes up to reroute the path to a new link
or node to bypass the failed link or node. This can happen in as fast as 50 milliseconds, thereby
minimizing data loss.
Once a link or node on an LSP configured with FRR fails, traffic is switched to the protection link and
the ingress node of the LSP starts attempting to set up a new LSP.
The following are basic concepts of FRR:
•
Protected LSP—A primary LSP to be protected.
•
Bypass LSP—An LSP used to protect primary LSPs.
96
•
Point of local repair (PLR)—The ingress node of a bypass LSP. It must be located on a
protected LSP but must not be the egress node.
•
Merge point (MP)—The egress node of the bypass LSP. It must be located on a protected LSP
but must not be the ingress node.
Protection
FRR provides link protection and node protection for an LSP.
•
Link protection—The PLR and the MP are connected through a direct link and the primary
LSP traverses this link. When the link fails, traffic is switched to the bypass LSP. As shown
in Figure 29, the primary LSP is Router A → Router B → Router C → Router D, and the bypass
LSP is Router B → Router F → Router C.
Figure 29 FRR link protection
•
Node protection—The PLR and the MP are connected through a device and the primary LSP
traverses this device. When the device fails, traffic is switched to the bypass LSP. As shown
in Figure 30, the primary LSP is Router A → Router B → Router C → Router D → Router E, and
the bypass LSP is Router B → Router F→ Router D. Router C is the protected device.
Figure 30 FRR node protection
Deploying FRR
When configuring the bypass LSP, make sure the protected link or node is not on the bypass LSP.
As bypass LSPs are pre-established, FRR requires extra bandwidth. When network bandwidth is
insufficient, use FRR for crucial interfaces or links only.
PS for an MPLS TE tunnel
Protection switching (PS) refers to establishing one or more protection tunnels (backup tunnels) for a
primary tunnel. A primary tunnel and its protection tunnels form a protection group. When the primary
tunnel fails, data is switched to a protection tunnel immediately, greatly improving the reliability of the
network. When the primary tunnel recovers, data can be switched back to the primary tunnel.
97
Protection switching modes
The device supports the following protection switching modes:
•
1:1 protection switching—Two tunnels, one primary and one backup, exist between the
ingress node and the egress node. Typically, user data travels along the primary tunnel. If the
ingress node detects a fault on the primary tunnel by using a probing mechanism (such as BFD),
it switches data to the backup tunnel. 1:1 protection switching is applicable to both
unidirectional and bidirectional tunnels.
•
1+1 protection switching—Two tunnels, one primary and one backup, exist between the
ingress node and the egress node. Typically, user data travels along both the primary and
backup tunnels, and the egress node decides from which tunnel it receives data. If the ingress
node detects a fault on one of the tunnels by using a probing mechanism (such as BFD), it
forwards data only along the other tunnel to the egress node. 1+1 protection switching is
applicable only to bidirectional tunnels.
NOTE:
Once you configure 1+1 PS protection for two tunnels, the two tunnels can transmit only MPLS
L2VPN traffic. They cannot transmit VPLS traffic, even if you switch the PS mode from 1+1 to 1:1.
Protection switching triggering modes
Protection switching may be command triggered or signal triggered.
•
•
Command switching refers to a PS triggered by an externally configured switching command,
which can define the following switching actions (in descending order of priority):
{
clear—Clears all configured switching actions.
{
lock (lockout of protection)—Always uses the primary LSP to transfer data.
{
force (forced switch)—Forces data to travel on the backup LSP.
{
manual (manual switch)—Switches data from the primary LSP to the backup LSP.
Signal switching (Signal Fail) refers to a PS automatically triggered by a signal fail declaration.
For example, BFD can trigger a signal fail switching when it detects a failed MPLS-TE tunnel.
The following shows the externally configured switching actions and the signal fail switching actions,
in the descending order of priority:
•
Clear
•
Lockout of protection
•
Signal fail of the backup LSP
•
Forced switch
•
Signal fail of the primary LSP
•
Signal clear
•
Manual switch
In practice, a manually configured switching action takes effect only when its priority is higher than
that of the current switching action. To change a switching action to a lower-priority switching action,
first execute the mpls te protect-switch clear command and then configure the low-priority
switching action.
Path switching modes
The primary and backup tunnels in a protection group support the following path switching modes:
•
Unidirectional path switching—Only the ingress node performs path switching. The ingress
node does not notify the egress node to perform path switching.
•
Bidirectional path switching—When the ingress or egress node performs path switching, it
also notifies the other node to perform path switching. Only a protection group comprised of
bidirectional tunnels supports bidirectional path switching.
98
Protocols and standards
•
RFC 2702, Requirements for Traffic Engineering Over MPLS
•
RFC 3212, Constraint-Based LSP Setup using LDP
•
RFC 2205, Resource ReSerVation Protocol
•
RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels
•
RFC 2961, RSVP Refresh Overhead Reduction Extensions
•
RFC 3564, Requirements for Support of Differentiated Service-aware MPLS Traffic
Engineering
•
ITU-T Recommendation Y.1720, Protection switching for MPLS networks
MPLS TE configuration task list
Task
Remarks
Configuring basic MPLS TE
Required.
Configuring an
MPLS TE
tunnel
Creating an MPLS TE tunnel over a static CR-LSP
Required.
Configuring an MPLS TE tunnel with a dynamic signaling protocol
Use either method.
Configuring RSVP-TE advanced features
Optional.
Tuning CR-LSP setup
Optional.
Tuning MPLS TE tunnel setup
Optional.
Forwarding traffic along MPLS TE
tunnels using static routes
Configuring traffic forwarding
Forwarding traffic along MPLS TE
tunnels through automatic route
advertisement
Required.
Use either method.
Configuring traffic forwarding tuning parameters
Optional.
Creating a bidirectional MPLS TE tunnel
Optional.
Configuring CR-LSP backup
Optional.
Configuring FRR
Optional.
Inspecting an MPLS TE tunnel
Optional.
Configuring protection switching
Optional.
Configuring basic MPLS TE
Perform this task to perform the basic MPLS TE settings required for all MPLS TE features.
Before you configure the basic MPLS TE, complete the following tasks:
•
Configure static routing or IGPs to make sure all LSRs are reachable.
•
Configure basic MPLS.
For information about basic MPLS configurations, see "Configuring basic MPLS."
To configure basic MPLS TE:
99
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Enable global MPLS TE.
mpls te
Disabled by default.
4.
Return to system view.
quit
N/A
5.
Enter the interface view of an
MPLS TE link.
interface interface-type
interface-number
N/A
6.
Enable interface MPLS TE.
mpls te
Disabled by default.
7.
Return to system view.
quit
N/A
8.
Create a tunnel interface and
enter its view.
interface tunnel tunnel-number
N/A
9.
Assign an IP address to the
tunnel interface.
ip address ip-address netmask
Optional.
10. Set the tunnel protocol to
MPLS TE.
tunnel-protocol mpls te
N/A
11. Configure the destination
address of the tunnel.
destination ip-address
N/A
12. Configure the tunnel ID of
the tunnel.
mpls te tunnel-id tunnel-id
N/A
13. Submit the current tunnel
configuration.
mpls te commit
N/A
For more information about tunnel interfaces, see Layer 3—IP Services Configuration Guide.
Creating an MPLS TE tunnel over a static CR-LSP
Creating MPLS TE tunnels over static CR-LSPs does not involve configuration of tunnel constraints
or the issue of IGP TE extension or CSPF. Create a static CR-LSP and a TE tunnel using static
signaling and then associate them.
Despite its ease of configuration, the application of MPLS TE tunnels over static CR-LSPs is
restricted because they cannot dynamically adapt to network changes.
Static CR-LSPs are special static LSPs. They share the same constraints and use the same label
space.
Before you perform the configuration, complete the following tasks:
•
Configure static routing or an IGP protocol to make sure all LSRs can reach each other.
•
Configure basic MPLS.
•
Configure basic MPLS TE.
Follow these guidelines when you create an MPLS TE tunnel over a static CR-LSP:
•
The tunnel-name argument in the static-cr-lsp ingress command specifies the name of the
MPLS TE tunnel interface that uses the static CR-LSP. It must be the same as the tunnel
interface name, including the letter case. For example, assume that you have created a tunnel
interface by using the command interface tunnel 2. The tunnel interface name is Tunnel2. The
tunnel-name in the static-cr-lsp ingress command must be in the form of Tunnel2—not
tunnel2 or TUNNEL2. Otherwise, the tunnel cannot be established on the ingress node. This
restriction however does not apply to transit or egress nodes.
100
•
Do not configure the next hop address as a local public address when configuring the static
CR-LSP on the ingress or a transit node.
To create an MPLS TE tunnel over a static CR-LSP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter the interface view of an
MPLS TE tunnel.
interface tunnel tunnel-number
N/A
3.
Configure the tunnel to use
static CR-LSP.
mpls te signal-protocol static
N/A
4.
Submit the current tunnel
configuration.
mpls te commit
N/A
5.
Return to system view.
quit
N/A
•
•
6.
Create a static CR-LSP.
•
On the ingress node:
static-cr-lsp ingress
tunnel-name destination
dest-addr nexthop
next-hop-addr out-label
out-label-value
On a transit node:
static-cr-lsp transit tunnel-name
incoming-interface
interface-type interface-number
in-label in-label-value nexthop
next-hop-addr out-label
out-label-value
On the egress node:
static-cr-lsp egress
tunnel-name incoming-interface
interface-type interface-number
in-label in-label-value
Follow the guidelines to
correctly configure the
ingress, transit, and egress
node.
Configuring an MPLS TE tunnel with a dynamic
signaling protocol
Dynamic signaling protocol can adapt the path of a TE tunnel to network changes and implement
redundancy, FRR, and other advanced features.
The following describes how to create an MPLS TE tunnel with a dynamic signaling protocol:
•
Configure MPLS TE properties for links and advertise them through IGP TE extension to form a
TEDB.
•
Configure tunnel constraints.
•
Use the CSPF algorithm to calculate a preferred path based on the TEDB and tunnel
constraints.
•
Establish the path by using the signaling protocol RSVP-TE.
To form a TEDB, configure the IGP TE extension for the nodes on the network to send TE LSAs. If
the IGP TE extension is not configured, the CR-LSP is created based on IGP routing rather than
computed by CSPF.
101
Configuration prerequisites
Before you perform the configuration, complete the following tasks:
•
Configure static routing or an IGP protocol to make sure all LSRs can reach each other.
•
Configure basic MPLS.
•
Configure basic MPLS TE.
Configuration procedure
Task
Remarks
Configuring CSPF
Optional.
Configuring OSPF TE
Required when CSPF is configured.
Configuring IS-IS TE
Choose one depending on the IGP protocol used.
Configuring an MPLS TE explicit path
Optional.
Configuring MPLS TE tunnel constraints
Optional.
Establishing an MPLS TE tunnel with RSVP-TE
Optional.
Configuring CSPF
With CSPF enabled, a node uses CSPF to calculate the shortest path that satisfies TE requirements.
To configure CSPF:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Enable CSPF on the switch.
mpls te cspf
Disabled by default.
Configuring OSPF TE
Configure OSPF TE if the routing protocol is OSPF and a dynamic signaling protocol is used for
MPLS TE tunnel setup.
The OSPF TE extension uses Opaque Type 10 LSAs to carry TE attributes of links. Before
configuring OSPF TE, enable the opaque capability of OSPF. In addition, for TE LSAs to be
generated, at least one neighbor must be in full state. For more information about OSPF opaque
LSAs, see Layer 3—IP Routing Configuration Guide.
MPLS TE cannot reserve resources and distribute labels on OSPF virtual links. MPLS TE cannot
establish an LSP tunnel through an OSPF virtual link. Make sure no virtual links exist in the OSPF
routing domain when configuring OSPF TE.
To configure OSPF TE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter OSPF view.
ospf [ process-id ]
N/A
102
Step
Command
Remarks
3.
Enable the opaque LSA
capability.
opaque-capability enable
Disabled by default.
4.
Enter OSPF area view.
area area-id
N/A
5.
Enable MPLS TE in the
OSPF area.
mpls-te enable
Disabled by default.
6.
Return to OSPF view.
quit
N/A
Configuring IS-IS TE
Configure IS-IS TE if the routing protocol is IS-IS and a dynamic signaling protocol is used for MPLS
TE tunnel setup. If both OSPF TE and IS-IS TE are available, OSPF TE takes priority.
The IS-IS TE extension uses the sub-TLV of IS reachability TLV (type 22) to carry TE attributes.
Before configuring IS-IS TE, configure the IS-IS wide metric style, which can be wide, compatible, or
wide-compatible.
According to RFC 3784, the length of the IS reachability TLV (type 22) may reach the maximum of
255 bytes. For an IS-IS LSP to carry this type of TLV and to be flooded correctly on all IS-IS enabled
interfaces, the MTU of any of the interfaces cannot be less than 284 bytes (including 27 bytes of LSP
header and two bytes of TLV header). If an LSP must also carry the authentication information, the
minimum MTU needs to be recalculated according to the packet structure. Because of these reasons,
when TE is configured, set the MTU of each IS-IS enabled interface to be equal to or greater than
512 bytes to guarantee that IS-IS LSPs can be flooded on the network.
For more information about IS-IS, see Layer 3—IP Routing Configuration Guide.
IMPORTANT:
IS-IS TE does not support secondary IP address advertisement. With IS-IS TE enabled on an
interface configured with multiple IP addresses, IS-IS TE advertises only the primary IP address of
the interface through the sub-TLV of IS reachability TLV (type 22). Hewlett Packard Enterprise
recommends that you avoid enabling IS-IS TE on an interface configured with secondary IP
addresses.
To configure IS-IS TE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter IS-IS view.
isis [ process-id ]
N/A
3.
Configure the wide metric
attribute of IS-IS.
cost-style { narrow | wide |
wide-compatible | { compatible |
narrow-compatible }
[ relax-spf-limit ] }
By default, IS-IS uses narrow
metric style.
4.
Enable IS-IS TE.
traffic-eng [ level-1 | level-2 |
level-1-2 ]
Disabled by default.
Configuring an MPLS TE explicit path
An explicit path is a set of nodes. The relationship between any two neighboring nodes on an explicit
path can be either strict or loose.
•
Strict—The two nodes are directly connected.
•
Loose—The two nodes have devices in between.
103
When inserting nodes to an explicit path or modifying nodes on it, you can configure the include
keyword to have the established LSP traverse the specified nodes or the exclude keyword to have
the established LSP bypass the specified nodes.
When establishing an MPLS TE tunnel between areas or ASs, use a loose explicit route, specify the
ABR or ASBR as the next hop of the route, and make sure the tunnel's ingress node and the ABR or
ASBR can reach each other.
To configure an MPLS TE explicit path:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an explicit path for
MPLS TE tunneling and
enter its view.
explicit-path path-name
[ disable | enable ]
N/A
Optional.
3.
4.
Add a node to the explicit
path.
Specify a next hop IP
address on the explicit path.
add hop ip-address1 [ include
[ loose | strict ] | exclude ] { after
| before } ip-address2
next hop ip-address [ include
[ loose | strict ] | exclude ]
By default, the include keyword
and the strict keyword apply. The
explicit path traverses the
specified node and the next node
is a strict node.
The next hop is a strict node by
default.
Repeat this step to define a
sequential set of the hops that the
explicit path traverses.
Optional.
By default, the include keyword
and the strict keyword apply. The
explicit path traverses the
specified node and the next node
is a strict node.
5.
Modify the IP address of
current node on the explicit
path.
modify hop ip-address1
ip-address2 [ [ include [ loose |
strict ] | exclude ]
6.
Remove a node from the
explicit path.
delete hop ip-address
Optional.
7.
Display information about
the specified or all nodes on
the explicit path.
list hop [ ip-address ]
Optional.
Configuring MPLS TE tunnel constraints
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Specify a path for the tunnel
to use and set the
preference of the path.
mpls te path { dynamic |
explicit-path path-name }
preference value
Optional.
Submit current tunnel
configuration.
mpls te commit
N/A
4.
By default, a tunnel uses the
dynamically calculated path.
Establishing an MPLS TE tunnel with RSVP-TE
To use RSVP-TE to set up an MPLS TE tunnel, enable both MPLS TE and RSVP-TE on the
interfaces for the tunnel to use on each node along the tunnel.
104
To establish an MPLS TE tunnel with RSVP-TE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Enable RSVP-TE for the
switch.
mpls rsvp-te
Disabled by default.
4.
Return to system view.
quit
N/A
5.
Enter interface view of MPLS
TE link.
interface interface-type
interface-number
N/A
6.
Enable RSVP-TE on the
interface.
mpls rsvp-te
Disabled by default.
7.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
8.
Set the signaling protocol for
setting up the MPLS TE
tunnel to RSVP-TE.
mpls te signal-protocol rsvp-te
Submit current tunnel
configuration.
mpls te commit
9.
Optional.
RSVP-TE applies by default.
N/A
Configuring RSVP-TE advanced features
RSVP-TE adds new objects in Path and Resv messages to support CR-LSP setup. RSVP-TE
provides many configurable options with respect to reliability, network resources, and other
advanced features of MPLS TE.
Before performing the configuration tasks in this section, be aware of each configuration objective
and its impact on your network.
Before you configure RSVP-TE advanced features, complete the following tasks:
•
Configure basic MPLS.
•
Configure basic MPLS TE.
•
Establish an MPLS TE tunnel with RSVP-TE.
Configuring RSVP reservation style
Each LSP set up using RSVP-TE is assigned a resource reservation style. During an RSVP session,
the receiver decides which reservation style to use for this session and thus which LSPs to use.
Two reservation styles are available:
•
FF style—Resources are reserved for individual senders and cannot be shared among
senders on the same session.
•
SE style—Resources are reserved for senders on the same session and shared among them.
In current MPLS TE applications, the SE style is mainly used for make-before-break. The FF style is
rarely used.
To configure RSVP reservation style:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
105
Step
Command
Remarks
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
3.
Configure the resources
reservation style for the
tunnel.
mpls te resv-style { ff | se }
The default resource reservation
style is SE.
Submit current tunnel
configuration.
mpls te commit
N/A
4.
Optional.
Configuring RSVP state timers
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Configure the
path/reservation state
refresh interval of the node.
mpls rsvp-te timer refresh
timevalue
Configure the keep multiplier
for PSB and RSB.
mpls rsvp-te keep-multiplier
number
Configure the blockade
timeout multiplier.
mpls rsvp-te
blockade-multiplier number
4.
5.
Optional.
The default path/reservation state
refresh interval is 30 seconds.
Optional.
The default is 3.
Optional.
The default blockade timeout
multiplier is 4.
Configuring the RSVP refresh mechanism
To enhance reliability of RSVP message transmission, the Message_ID extension mechanism is
used to acknowledge RSVP messages. The Message_ID extension mechanism is also referred to
as the reliability mechanism throughout this document.
After you enable RSVP message acknowledgement on an interface, you can enable retransmission.
To use summary refresh (Srefresh), you must use the Message_ID extension. Only states advertised
using MESSAGE_ID included Path and Resv messages can be refreshed using summary refreshes.
To configure RSVP refreshing mechanism:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view of MPLS TE
link.
interface interface-type
interface-number
N/A
3.
Enable the reliability mechanism
of RSVP-TE.
mpls rsvp-te reliability
Enable retransmission.
mpls rsvp-te timer retransmission
{ increment-value [ increment-value ] |
retransmit-value [ retrans-timer-value ] }
*
4.
106
Optional.
Disabled by default.
Optional.
Disabled by default.
Step
5.
Enable summary refresh.
Command
Remarks
Optional.
mpls rsvp-te srefresh
Disabled by default.
Configuring the RSVP hello extension
RSVP hello extension tests the reachability of RSVP neighboring nodes. It is defined in RFC 3209.
To configure the RSVP hello extension:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Enable global RSVP hello
extension.
mpls rsvp-te hello
Disabled by default.
4.
Configure the maximum
number of consecutive
hellos that must be lost
before the link is considered
failed..
mpls rsvp-te hello-lost times
5.
Configure the hello interval.
mpls rsvp-te timer hello
timevalue
Optional.
6.
Return to system view.
quit
N/A
7.
Enter interface view of MPLS
TE link.
interface interface-type
interface-number
N/A
8.
Enable interface RSVP hello
extension.
mpls rsvp-te hello
Disabled by default.
Optional.
By default, the link is considered
failed if three consecutive hellos
are lost.
The default is 3 seconds.
Configuring RSVP-TE resource reservation confirmation
Reservation confirmation is initiated by the receiver, which sends the Resv message with an object
requesting reservation confirmation.
Receiving the ResvConf message does not mean resource reservation is established. It only
indicates that resources are reserved on the farthest upstream node where the Resv message
arrived and the resources can be preempted.
To configure RSVP-TE resource reservation confirmation:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Enable resource reservation
confirmation.
mpls rsvp-te resvconfirm
Disabled by default.
107
Configuring RSVP authentication
RSVP adopts hop-by-hop authentication to prevent fake resource reservation requests from
occupying network resources.
The interfaces at the two ends of a link must share the same authentication key to exchange RSVP
messages.
To configure RSVP authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view of MPLS
TE link.
interface interface-type
interface-number
N/A
3.
Enable RSVP
authentication.
Disabled by default.
mpls rsvp-te authentication
{ cipher | plain } auth-key
Do not configure both FRR and
RSVP authentication on the same
interface.
Configuring DSCP for outgoing RSVP packets
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Configure a DSCP value for
outgoing RSVP packets.
mpls rsvp-te dscp dscp-value
By default, the DSCP value for
outgoing RSVP packets is 48.
Configuring RSVP-TE GR
The RSVP-TE GR function depends on the extended hello capability of RSVP-TE. Enable the
extended hello capability of RSVP-TE before configuring RSVP-TE GR.
To configure RSVP-TE GR on each device to act as the GR restarter or a GR helper:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Enable global RSVP hello
extension.
mpls rsvp-te hello
Disabled by default.
4.
Enable MPLS RSVP-TE GR.
mpls rsvp-te graceful-restart
Disabled by default.
5.
Set the RSVP-TE GR restart
timer.
mpls rsvp-te timer
graceful-restart restart
restart-time
Optional.
Set the RSVP-TE GR
recovery timer.
mpls rsvp-te timer
graceful-restart recovery
recovery-time
Optional.
Enter interface view of MPLS
TE link.
interface interface-type
interface-number
N/A
6.
7.
108
120 seconds by default.
300 seconds by default.
Step
8.
Enable RSVP hello
extension for the interface.
Command
Remarks
mpls rsvp-te hello
Disabled by default.
Tuning CR-LSP setup
A CR-LSP is established through the signaling protocol based on the path calculated by CSPF using
TEDB and constraints. MPLS TE can affect CSPF calculation in many ways to determine the path
that a CR-LSP can traverse.
The configuration tasks described in this section are about CSPF of MPLS TE. You must use them in
conjunction with CSPF and RSVP-TE. Before performing them, be aware of each configuration
objective and its impact on your system.
Configuring route pinning
You cannot use route pinning together with reoptimization.
To configure route pinning:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Enable route pinning.
mpls te route-pinning
Disabled by default.
4.
Submit current tunnel
configuration.
mpls te commit
N/A
Configuring administrative group and affinity attribute
The affinity attribute of an MPLS TE tunnel identifies the properties of the links that the tunnel can
use. Together with the link administrative group, it decides which links the MPLS TE tunnel can use.
This is done by ANDing the 32-bit affinity attribute with the 32-bit link administrative group attribute.
When doing that, a 32-bit mask is used. The affinity bits corresponding to the 1s in the mask are "do
care" bits which must be considered while those corresponding to the 0s in the mask are "don't care"
bits.
For a link to be used by a TE tunnel, at least one considered affinity bit and its corresponding
administrative group bit must be set to 1.
Suppose the affinity of an MPLS TE tunnel is 0xFFFFFFFF and the mask is 0x0000FFFF. For a link
to be used by the tunnel, the leftmost 16 bits of its administrative group attribute can be 0s or 1s, but
at least one of the rest bits must be 1.
The affinity of an MPLS TE tunnel is configured at the first node on the tunnel and then signaled to
the rest nodes through RSVP-TE.
The associations between administrative groups and affinities may vary by vendor. To ensure the
successful establishment of a tunnel between two devices from different vendors, correctly configure
their respective administrative groups and affinities.
To configure the administrative group and affinity attribute:
109
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view of MPLS
TE link.
interface interface-type
interface-number
N/A
3.
Assign the link to a link
administrative group.
mpls te link administrative
group value
Optional.
4.
Return to system view.
quit
N/A
5.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
6.
Configure the affinity
attribute of the MPLS TE
tunnel.
mpls te affinity property
properties [ mask mask-value ]
The default affinity attribute is
0x00000000, and the default
mask is 0x00000000.
7.
Submit current tunnel
configuration.
mpls te commit
N/A
The default is 0x00000000.
Optional.
Configuring CR-LSP reoptimization
Dynamic CR-LSP optimization involves the periodic calculation of paths that traffic trunks traverse. If
a better route is found for an existing CR-LSP, a new CR-LSP is established to replace the old one,
and services are switched to the new CR-LSP.
To configure CR-LSP reoptimization:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel interface view.
interface tunnel tunnel-number
N/A
3.
Enable reoptimization for the MPLS
TE tunnel.
mpls te reoptimization
[ frequency seconds ]
Disabled by default.
4.
Submit current tunnel configuration.
mpls te commit
N/A
5.
Return to user view.
return
N/A
6.
Perform reoptimization on all MPLS
TE tunnels with reoptimization
enabled.
mpls te reoptimization
Optional.
Tuning MPLS TE tunnel setup
This section only covers the configuration tasks for tuning MPLS TE tunnel setup.
You must use the configurations described in this section together with a dynamic signaling protocol
(such as RSVP-TE). Before performing the configuration tasks, be aware of each configuration
objective and its impact on your system.
Configuring loop detection
110
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel interface
view.
interface tunnel tunnel-number
N/A
3.
Enable the system to perform loop
detection when setting up a tunnel.
mpls te loop-detection
Disabled by default.
4.
Submit current tunnel
configuration.
mpls te commit
N/A
Configuring route and label recording
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Enable the system to record
routes or labels when setting
up the tunnel.
4.
Submit current tunnel
configuration.
•
•
Record routes:
mpls te record-route
Record routes and labels:
mpls te record-route label
mpls te commit
Use either command.
Both route recording and label
recording are disabled by default.
N/A
Configuring tunnel setup retry
You can configure the system to attempt setting up a tunnel multiple times until it is established
successfully or until the number of attempts reaches the upper limit.
To configure tunnel setup retry:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Configure maximum number
of tunnel setup retries.
mpls te retry times
Configure the tunnel setup
retry interval.
mpls te timer retry seconds
Submit current tunnel
configuration.
mpls te commit
4.
5.
Optional.
The default is 10.
Optional.
The default is 2 seconds.
N/A
Assigning priorities to a tunnel
Two priorities, setup priority and holding priority, are assigned to paths for MPLS TE to make
preemption decision. For a new path to preempt an existing path, the setup priority of the new path
must be greater than the holding priority of the existing path.
111
To avoid flapping caused by improper preemptions between CR-LSPs, the setup priority of a
CR-LSP must not be set higher than its holding priority.
To assign priorities to a tunnel:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Assign priorities to the
tunnel.
mpls te priority setup-priority
[ hold-priority ]
4.
Submit current tunnel
configuration.
mpls te commit
Optional.
The default setup and holding
priorities are 7.
N/A
Configuring traffic forwarding
This section describes how to forward traffic through MPLS TE tunnels.
Before you configure traffic forwarding, complete the following tasks:
•
Configure basic MPLS.
•
Configure basic MPLS TE.
•
Configure MPLS TE tunnels.
Forwarding traffic along MPLS TE tunnels using static routes
Step
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
Create a static route for
forwarding traffic along an
MPLS TE tunnel.
ip route-static dest-address
{ mask | mask-length }
interface-type interface-number
[ gateway-address ] |
vpn-instance
d-vpn-instance-name
gateway-address } [ preference
preference-value ] [ tag
tag-value ] [ description
description-text ]
The interface-type argument in
the ip route-static command
must be tunnel. In addition, the
preference value must be set.
For more information about static
routing, see Layer 3—IP Routing
Configuration Guide.
Forwarding traffic along MPLS TE tunnels through automatic
route advertisement
Two approaches, IGP shortcut and forwarding adjacency, are available to automatically advertise
MPLS TE tunnel interface routes to IGPs, allowing traffic to be routed down MPLS TE tunnels.
You can assign a metric, either absolute or relative, to TE tunnels for the purpose of path calculation
in either approach. If it is absolute, the switch directly uses the metric for path calculation. If it is
relative, the switch adds the cost of the corresponding IGP path to the metric before using it for path
calculation.
112
Enable OSPF or IS-IS on the tunnel interface of the MPLS TE tunnel before configuring automatic
route advertisement.
To use automatic route advertisement, specify the destination address of the TE tunnel as the LSR
ID of the peer and advertise the tunnel interface address to IGPs, such as OSPF and ISIS.
1.
Configure an IGP shortcut:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Configure the IGP to take the
MPLS TE tunnels in up state
into account when
performing enhanced SPF
calculation.
mpls te igp shortcut [ isis |
ospf ]
4.
Assign a metric to the MPLS
TE tunnel.
mpls te igp metric { absolute |
relative } value
The metrics of TE tunnels equal
the metrics of their corresponding
IGP routes by default.
5.
Submit current tunnel
configuration.
mpls te commit
N/A
6.
Return to system view.
quit
N/A
7.
Enter OSPF view.
ospf [ process-id ]
N/A
8.
Enable the IGP shortcut
function.
enable traffic-adjustment
Disabled by default.
MPLS TE tunnels are not
considered in the enhanced SPF
calculation of IGP.
If no IGP type is specified, the
configuration applies to both
OSPF and ISIS by default.
Optional.
2.
Configure a forwarding adjacency:
Create a bi-directional MPLS TE tunnel and enable forwarding adjacency at both ends of the tunnel
to make forwarding adjacency take effect.
To configure a forwarding adjacency:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Enable IGP to advertise the
route of the MPLS TE tunnel
to IGP neighbors.
mpls te igp advertise
[ hold-time value ]
Routes of MPLS TE tunnels are
not advertised to IGP neighbors
by default.
4.
Assign a metric to the MPLS
TE tunnel.
mpls te igp metric { absolute |
relative } value
The metrics of TE tunnels equal
the metrics of their corresponding
IGP routes by default.
5.
Submit current tunnel
configuration.
mpls te commit
N/A
6.
Return to system view.
quit
N/A
7.
Enter OSPF view.
ospf [ process-id ]
N/A
8.
Enable forwarding
adjacency.
enable traffic-adjustment
advertise
Disabled by default.
Optional.
113
Configuring traffic forwarding tuning parameters
In MPLS TE, you can configure traffic forwarding tuning parameters, such as the failed link timer and
flooding thresholds, to change paths that IP or MPLS traffic traverses or to define type of traffic that
may travel down a TE tunnel.
You must use the configurations described in this section in conjunction with CSPF and a dynamic
signaling protocol, such as RSVP-TE.
Configuring the failed link timer
A CSPF failed link timer starts once a link goes down. If IGP removes or modifies the link before the
timer expires, CSPF updates information about the link in TEDB and stops the timer. If IGP does not
remove or modify the link before the timer expires, the state of the link in TEDB changes to up.
To configure failed link timer:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Configure the CSPF failed
link timer.
mpls te cspf timer failed-link
timer-interval
Optional.
The default is 10 seconds.
Specifying the link metric type for tunnel path calculation
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Specify the metric type to
use when no metric type is
explicitly configured for a
tunnel.
mpls te path metric-type { igp |
te }
4.
Return to system view.
quit
N/A
5.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
6.
Specify the metric type to
use for path calculation of
the current tunnel.
mpls te path metric-type { igp |
te }
If you do not specify a metric type
in MPLS TE tunnel interface view,
the one specified in MPLS view
takes effect.
7.
Submit current tunnel
configuration.
mpls te commit
Optional.
8.
Return to system view.
quit
N/A
9.
Enter interface view of MPLS
TE link.
interface interface-type
interface-number
N/A
Optional.
TE metrics of links are used by
default.
Optional.
114
Step
Command
Remarks
Optional.
10. Assign a TE metric to the
link.
mpls te metric value
If no TE metric is assigned to the
link, IGP metric is used as the TE
metric by default.
Configuring the traffic flow type of a tunnel
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Configure the traffic flow type
of the TE tunnel.
mpls te vpn-binding { acl
acl-number | vpn-instance
vpn-instance-name }
Optional.
4.
Submit current tunnel
configuration.
mpls te commit
N/A
Traffic flow types of TE tunnels
are not restricted by default.
Creating a bidirectional MPLS TE tunnel
Before you create a bidirectional MPLS TE tunnel, complete the following tasks:
•
Configure basic MPLS.
•
Configure basic MPLS TE.
•
To set up a bidirectional MPLS TE tunnel in co-routed mode, you must specify the signaling
protocol as RSVP-TE, and use the mpls te resv-style command to configure the resources
reservation style as FF for the tunnel.
•
To set up a bidirectional MPLS TE tunnel in associated mode and use RSVP-TE to set up one
CR-LSP of the tunnel, you must use the mpls te resv-style command to configure the
resources reservation style as FF for the CR-LSP.
•
Disable the PHP function on both ends of the tunnel to assign non-null labels to the penultimate
hop.
To create a bidirectional MPLS TE tunnel, create an MPLS TE tunnel interface on both ends of the
tunnel and enable the bidirectional tunnel function on the tunnel interfaces:
•
For a co-routed bidirectional tunnel, configure one end of the tunnel as the active end and the
other end as the passive end, and specify the reverse CR-LSP at the passive end.
•
For an associated bidirectional tunnel, specify a reverse CR-LSP at both ends of the tunnel.
To configure the active end of a co-routed bidirectional MPLS TE tunnel:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
115
Step
3.
4.
Command
Remarks
Configure a co-routed
bidirectional MPLS TE
tunnel and specify the local
end as the active end of the
tunnel.
mpls te bidirectional co-routed
active
By default, no bidirectional tunnel
is configured, and tunnels
established on the tunnel
interface are unidirectional MPLS
TE tunnels.
Submit current tunnel
configuration.
mpls te commit
N/A
To configure the passive end of a co-routed bidirectional MPLS TE tunnel:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Configure a co-routed
bidirectional MPLS TE
tunnel and specify the local
end as the passive end of
the tunnel.
mpls te bidirectional co-routed
passive reverse-lsp lsr-id
ingress-lsr-id tunnel-id tunnel-id
By default, no bidirectional tunnel
is configured, and tunnels
established on the tunnel
interface are unidirectional MPLS
TE tunnels.
Submit current tunnel
configuration.
mpls te commit
N/A
4.
To configure an associated bidirectional MPLS TE tunnel:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Configure an associated
bidirectional MPLS TE
tunnel.
mpls te bidirectional
associated reverse-lsp lsr-id
ingress-lsr-id tunnel-id tunnel-id
By default, no bidirectional tunnel
is configured, and tunnels
established on the tunnel
interface are unidirectional MPLS
TE tunnels.
4.
Submit current tunnel
configuration.
mpls te commit
N/A
Configuring CR-LSP backup
CR-LSP backup provides end-to-end path protection to protect the entire LSP.
Configure CR-LSP backup mode at the ingress node of a tunnel. The system automatically selects
the primary LSP and backup LSP. You do not need to configure them.
Before you configure CR-LSP backup, complete the following tasks:
•
Configure basic MPLS.
•
Configure basic MPLS TE.
•
Configure MPLS TE tunnels.
To configure CR-LSP backup:
116
Step
Command
Remarks
1.
Enter system view of the
ingress node.
system-view
N/A
2.
Enter MPLS TE tunnel
interface view.
interface tunnel tunnel-number
N/A
3.
Enable the specified backup
mode for the current tunnel.
mpls te backup { hot-standby |
ordinary }
Disabled by default.
4.
Submit current tunnel
configuration.
mpls te commit
N/A
Configuring FRR
As mentioned previously, FRR provides quick but temporary per-link or per-node local protection on
an LSP.
Bypass tunnels are pre-established and require extra bandwidth. Use bypass tunnels to protect only
crucial interfaces or links.
You can define which type of LSPs can use bypass LSPs, whether a bypass LSP provides bandwidth
protection, and the sum of protected bandwidth.
The bandwidth of a bypass LSP is to protect the protected LSPs. To guarantee that a protected LSP
can always be bound to the bypass LSP successfully, make sure the bandwidth assigned to the
bypass LSP is not less than the total bandwidth needed by all protected LSPs.
Typically, a bypass tunnel only forwards data traffic when a protected tunnel fails. To allow a bypass
tunnel to also forward data traffic when the protected tunnels are normal, make sure the bypass
tunnel has adequate bandwidth.
You cannot use a bypass tunnel for services like VPN.
Before you configure FRR, complete the following tasks:
•
Configure IGP, making sure all LSRs can reach each other.
•
Configure basic MPLS.
•
Configure basic MPLS TE.
•
Establish an MPLS TE tunnel with RSVP-TE.
•
Set up primary LSPs.
Enabling FRR on the ingress node of a protected LSP
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter tunnel interface view of
the protected LSP.
interface tunnel tunnel-number
N/A
Disabled by default.
3.
Enable FRR.
mpls te fast-reroute
4.
Submit current tunnel
configuration.
mpls te commit
117
Do not configure both FRR and
RSVP authentication on the same
interface.
N/A
Configuring a bypass tunnel on its PLR
After a tunnel is specified to protect an interface, its corresponding LSP becomes a bypass LSP. The
setup of a bypass LSP must be manually performed on the PLR. The configuration of a bypass LSP
is similar to that of a common LSP, but a bypass LSP cannot act as an LSP to be protected by
another LSP at the same time.
When specifying a bypass tunnel for an interface, make sure:
•
The bypass tunnel is up.
•
The protected interface is not the outgoing interface of the bypass tunnel.
Up to three bypass tunnels can be specified for a protected interface. The best-fit algorithm
determines which of them is used in case a failure occurs.
Your device has a restriction on links that use the same bypass tunnel so their total bandwidth does
not exceeds a specific value.
To configure a bypass tunnel on its PLR:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view of the
bypass tunnel.
interface tunnel
tunnel-number
N/A
3.
Specify the destination
address of the bypass
tunnel.
destination ip-address
4.
Submit current tunnel
configuration.
mpls te commit
N/A
5.
Return to system view.
quit
N/A
6.
Enter interface view of the
outgoing interface of the
protected LSP.
interface interface-type
interface-number
N/A
Bind the bypass tunnel to the
protected interface.
mpls te fast-reroute
bypass-tunnel tunnel
tunnel-number
N/A
7.
For node protection, this is the LSR
ID of the next hop router of PLR.
For link protection, this is the LSR ID
of the next hop device of PLR.
Configuring node protection
To use FRR for node protection, perform the tasks in this section on the PLR and the protected node.
If you only need to protect links, skip this section.
To configure node protection:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Enable RSVP hello extension on
current node.
mpls rsvp-te hello
Disabled by default.
4.
Return to system view.
quit
N/A
118
Step
5.
6.
Command
Remarks
Enter the view of the interface directly
connected to the protected node or
PLR.
interface interface-type
interface-number
N/A
Enable RSVP hello extension on the
interface.
mpls rsvp-te hello
Disabled by default.
NOTE:
RSVP hello extension is configured to detect node failures caused by problems such as signaling
error other than failures caused by link failures.
Configuring the FRR polling timer
The protection provided by FRR is temporary. Once a protected LSP becomes available again or a
new LSP is established, traffic is switched to the protected or new LSP. After this switchover, the PLR
polls available bypass tunnels for the best one at the regular interval specified by the FRR polling
timer:
To configure the FRR polling timer:
Step
Command
Remarks
1.
Enter system view of the
PLR node.
system-view
N/A
2.
Enter MPLS view.
mpls
N/A
3.
Configure the FRR polling
timer.
mpls te timer fast-reroute
[ seconds ]
Optional.
The FRR polling timer is 300
seconds by default.
Inspecting an MPLS TE tunnel
When an MPLS TE tunnel fails or affects data forwarding due to performance degradation, the
control plane cannot detect the fault or cannot do so in time. This brings difficulty to network
maintenance. To detect MPLS TE tunnel failures in time and locate the failed node, the device
provides the following mechanisms:
•
MPLS LSP ping
•
MPLS LSP tracert
•
BFD for an MPLS TE tunnel
•
Periodic tracert of an MPLS TE tunnel
•
Delay Measurement (DM)
Configuring MPLS LSP ping
Use MPLS LSP ping to test the connectivity of an MPLS TE tunnel. At the ingress, it adds the label of
the tunnel into an MPLS echo request, and sends it along the MPLS TE tunnel to the egress. The
ingress determines whether the MPLS TE tunnel is normal according to whether it can receive a
reply from the egress.
To test the connectivity of an MPLS TE tunnel, perform the following task in any view:
119
Task
Command
Use MPLS LSP ping to test the connectivity of an
MPLS TE tunnel.
ping lsp [ -a source-ip | -c count | -exp exp-value | -h
ttl-value | -m wait-time | -r reply-mode | -s packet-size |
-t time-out | -v ] * te interface-type interface-number
Configuring MPLS LSP tracert
Use MPLS LSP tracert to locate errors of an MPLS TE tunnel. It sends MPLS echo requests to the
nodes along the MPLS TE tunnel to be inspected, with the TTL increasing from 1 to a specific value.
Each node along the MPLS TE tunnel returns an MPLS echo reply to the ingress due to TTL timeout.
Thus, the ingress can collect information about each hop along the MPLS TE tunnel, so as to locate
the failed node. You can also use MPLS LSP tracert to collect information about each hop along the
MPLS TE tunnel, such as the label allocated.
To locate errors of an MPLS TE tunnel, perform the following task in any view:
Task
Command
Use MPLS LSP tracert to locate errors of an MPLS
TE tunnel.
tracert lsp [ -a source-ip | -exp exp-value | -h
ttl-value | -r reply-mode |-t time-out ] * te
interface-type interface-number
Configuring BFD for an MPLS TE tunnel
You can configure BFD for an MPLS TE tunnel to implement fast detection of the connectivity of the
tunnel. After you configure BFD for an MPLS TE tunnel, a BFD session is established between the
ingress and egress of the tunnel, and the ingress adds the label for the tunnel into a BFD control
packet, forward the BFD control packet along the tunnel, and determine the status of the tunnel
according to the BFD control packet received from the egress. Upon detecting an MPLS TE tunnel
failure, BFD triggers protection switching to switch traffic to another tunnel.
A BFD session for MPLS TE tunnel detection can be static or dynamic.
•
Static—If you specify the local and remote discriminator values by using the discriminator
keyword when configuring the mpls te bfd enable command, the BFD session is established
with the specified discriminator values. Such a BFD session can detect the connectivity of a pair
of MPLS TE tunnels in opposite directions (one from local to remote, and the other from remote
to local) between two devices.
•
Dynamic—If you do not specify the local and remote discriminator values when configuring the
mpls te bfd enable command, the MPLS LSP ping is run automatically to negotiate the
discriminator values and then the BFD session is established based on the negotiated
discriminator values. Such a BFD session can detect the connectivity of a unidirectional (from
the local device to the remote device) MPLS TE tunnel between two devices.
After you enable BFD and configure the mpls te failure-action teardown command for an MPLS
TE tunnel, once an RSVP-TE tunnel failure occurs, BFD can detect the failure, and if RSVP does not
re-establish the tunnel within a specific period of time, MPLS TE removes the failed RSVP-TE tunnel
and then re-establishes it.
Configuration guidelines
•
You cannot establish both a static BFD session and a dynamic BFD session for the same MPLS
TE tunnel.
•
After establishing a static BFD session for an MPLS TE tunnel, you cannot modify the
discriminator values of the BFD session.
120
•
If you enable both FRR and BFD for an MPLS TE tunnel, to make sure the BFD session is not
down during an FRR switching, give the BFD detection interval a greater value than the FRR
detection interval.
•
In a BFD session for detecting an MPLS TE tunnel's connectivity, the ingress node always
operates in active mode and the egress node always operates in passive mode. The bfd
session init-mode command does not take effect on the ingress and egress nodes of such a
BFD session. Even if you configure the two nodes to both operate in passive mode, the BFD
session can still be successfully established.
Configuration prerequisites
•
The source address of the BFD session is the MPLS LSR ID. Before configuring BFD to inspect
an MPLS TE tunnel, make sure there is a route on the peer device to the MPLS LSR ID. You
can also configure the BFD session parameters on the tunnel interface as needed. For more
information about BFD, see High Availability Configuration Guide.
•
To establish a static BFD session to inspect an MPLS TE tunnel, make sure there is already an
LSP from the local device to the remote device and an LSP from the remote device to the local
device.
Configuring BFD for an MPLS TE tunnel
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
By default, LSP verification is
disabled.
2.
Enable LSP verification and
enter MPLS LSPV view.
mpls lspv
For more information about the
mpls lspv command, see MPLS
Command Reference.
3.
Return to system view.
quit
N/A
4.
Enter the tunnel interface
view of an MPLS TE tunnel.
interface tunnel tunnel-number
N/A
5.
Configure BFD to test the
connectivity of the MPLS TE
tunnel.
mpls te bfd enable
[ discriminator local local-id
remote remote-id ]
By default, BFD is not configured
to test the connectivity of MPLS
TE tunnels.
6.
Configure MPLS TE to tear
down a failed RSVP TE
tunnel and reestablish it.
mpls te failure-action teardown
Optional.
Not configured by default.
Configuring periodic LSP tracert for an MPLS TE tunnel
The periodic LSP tracert function for an MPLS TE tunnel is for locating faults of the MPLS TE tunnel
periodically. It detects the consistency of the forwarding and control plane and records detection
results into logs. You can examine the logs to see whether an MPLS TE tunnel has failed.
If you configure BFD as well as periodical tracert for an MPLS TE tunnel, once the periodical LSP
tracert function detects a fault or inconsistency of the forwarding plane and control plane of the
MPLS TE tunnel, the BFD session for the tunnel is deleted and a new BFD session is established
according to the control plane.
After you configure periodic LSP tracert and the mpls te failure-action teardown command for an
MPLS TE tunnel, once an RSVP-TE tunnel failure occurs, the periodic LSP tracert function can
detect the failure, and if RSVP does not re-establish the RSVP-TE tunnel within a specific period of
time, MPLS TE removes the failed RSVP-TE tunnel and then re-establishes it.
To configure periodic LSP tracert for an MPLS TE tunnel:
121
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
By default, LSP verification is
disabled.
2.
Enable LSP verification and
enter MPLS LSPV view.
mpls lspv
For more information about the
mpls lspv command, see MPLS
Command Reference.
3.
Return to system view.
quit
N/A
4.
Enter the tunnel interface
view of an MPLS TE tunnel.
interface tunnel tunnel-number
N/A
5.
Enable periodic LSP tracert
for the MPLS TE tunnel.
mpls te periodic-tracert [ -a
source-ip | -exp exp-value | -h
ttl-value | -m wait-time | -t
time-out | -u retry-attempt ] *
By default, periodic LSP tracert is
disabled for MPLS TE tunnels.
6.
Configure MPLS TE to tear
down a failed RSVP TE
tunnel and reestablish it.
mpls te failure-action teardown
Optional.
Not configured by default.
Configuring DM
DM measures one-way or round-trip delay time for a bidirectional tunnel by using four timestamps in
DM messages. The timestamps record the time when the DM query message is transmitted from the
ingress, the time when the DM query message is received at the egress, the time when the DM
response message is transmitted from the egress, and the time when the DM response message is
received at the ingress, which hereinafter are referred as T1, T2, T3, and T4, respectively.
To measure the round-trip delay time:
1.
When the ingress sends a DM query to the egress through the forward CR-LSP, the ingress fills
the timestamp T1 in the query message and leaves other timestamps (T2, T3, and T4) empty.
2.
When the egress receives the query, it adds T2 and T3 into the response message and sends
the response message to the ingress through the backward CR-LSP.
3.
When the ingress receives the response message, it adds T4 into the message and then
compares T4 with T1 to compute the round-trip delay time.
To measure the one-way delay, the egress compares T2 with T1 to compute the delay time.
IMPORTANT:
To use DM to measure the one-way (in forward or backward direction) delay, modify the clocks or
configure the Network Time Protocol (NTP) to ensure clock consistency on the ingress and egress
nodes. Otherwise, the measurement result is incorrect. For round-trip delay measurement, clock
synchronization is not needed.
To configure the DM function:
Task
Command
Remarks
Measure the delay time for an
MPLS TE tunnel.
moam dm [ -c count | -m interval | -exp
value ] * te interface-type
interface-number
Available in any view.
122
Configuring protection switching
Before you configure protection switching, complete following tasks:
•
Configure basic MPLS.
•
Enable MPLS TE and create an MPLS TE tunnel.
•
Configure BFD for the MPLS TE tunnel.
Before you configure a protection tunnel, prepare the following data:
•
Interface number of the primary tunnel in the protection group
•
ID of the protection tunnel in the protection group
To configure protection switching:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter tunnel interface view.
interface tunnel tunnel-number
N/A
3.
Configure a protection tunnel
for the primary tunnel.
mpls te protection tunnel
tunnel-id [ holdoff holdoff-time |
mode { non-revertive | revertive
[ wtr wtr-time ] } | one-plus-one ]
*
N/A
4.
Enable the bidirectional path
switching mode.
mpls te protection
switch-mode bidirectional
5.
Configure an external
protection switching action.
mpls te protect-switch { clear |
force | lock | manual }
6.
Commit the current
configuration of the tunnel.
mpls te commit
Optional.
By default, the unidirectional path
switching mode is used.
Optional.
By default, no switching action is
configured.
N/A
Displaying and maintaining MPLS TE
Task
Command
Remarks
Display information about explicit
paths.
display explicit-path [ path-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about static
CR-LSPs.
display mpls static-cr-lsp [ lsp-name
lsp-name ] [ egress | ingress | transit ]
[ { include | exclude } ip-address
prefix-length ] [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display RSVP-TE configuration.
display mpls rsvp-te [ interface
[ interface-type interface-number ] [ | { begin
| exclude | include } regular-expression ] ]
Available in any view.
Display the RSVP-TE tunnel
information.
display mpls rsvp-te established
[ interface interface-type interface-number ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
123
Task
Command
Remarks
Display RSVP-TE neighbors.
display mpls rsvp-te peer [ interface
interface-type interface-number ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about RSVP
requests.
display mpls rsvp-te request [ interface
interface-type interface-number ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about RSVP
resource reservation.
display mpls rsvp-te reservation
[ interface interface-type interface-number ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display information about
RSVP-TE PSB.
display mpls rsvp-te psb-content
ingress-lsr-id lspid tunnel-id egress-lsr-id [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about
RSVP-TE RSB.
display mpls rsvp-te rsb-content
ingress-lsr-id Ispid tunnel-id egress-lsr-id
nexthop-address [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about RSVP
sender messages.
display mpls rsvp-te sender [ interface
interface-type interface-number ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display statistics about RSVP-TE.
display mpls rsvp-te statistics { global |
interface [ interface-type
interface-number ] } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display criteria-compliant
information about CSPF-based
TEDB.
display mpls te cspf tedb { all | area
area-id | interface ip-address | network-lsa
| node [ mpls-lsr-id ] } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about the
CR-LSPs carried on the specified
or all links.
display mpls te link-administration
admission-control [ interface
interface-type interface-number ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about MPLS
TE tunnels.
display mpls te tunnel [ destination
dest-addr ] [ lsp-id lsr-id lsp-id ] [ lsr-role
{ all | egress | ingress | remote | transit } ]
[ name name ] [ { incoming-interface |
outgoing-interface | interface }
interface-type interface-number ] [ verbose ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display the path attributes of
MPLS TE tunnels on this node.
display mpls te tunnel path [ lsp-id lsr-id
lsp-id | tunnel-name tunnel-name ] [ |
{ begin | exclude | include }
regular-expression ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display statistics about MPLS TE
tunnels.
display mpls te tunnel statistics [ | { begin
| exclude | include } regular-expression ]
Available in any view.
Display information about MPLS
TE tunnel interfaces.
display mpls te tunnel-interface tunnel
number [ | { begin | exclude | include }
regular-expression ]
Available in any view.
124
Task
Command
Remarks
Display information about the
specified or all OSPF processes
about traffic tuning.
display ospf [ process-id ]
traffic-adjustment [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about OSPF
TE.
display ospf [ process-id ] mpls-te [ area
area-id ] [ self-originated ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display the latest TE information
advertised by IS-IS TE.
display isis traffic-eng advertisements
[ [ level-1 | level-1-2 | level-2 ] | [ lsp-id
lsp-id | local ] ] * [ process-id | vpn-instance
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about TE links
for IS-IS.
display isis traffic-eng link [ [ level-1 |
level-1-2 | level-2 ] | verbose ] * [ process-id
| vpn-instance vpn-instance-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about TE
networks for IS-IS.
display isis traffic-eng network [ level-1 |
level-1-2 | level-2 ] [ process-id |
vpn-instance vpn-instance-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display statistics about TE for
IS-IS.
display isis traffic-eng statistics
[ process-id | vpn-instance
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about tunnels.
display tunnel-info { tunnel-id | all |
statistics } [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display the BFD information for
an MPLS TE tunnel.
display mpls lsp bfd [ te tunnel
tunnel-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about the
specified tunnels and their
protection tunnels.
display mpls te protection tunnel
{ tunnel-id | all } [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Clear the statistics about
RSVP-TE.
reset mpls rsvp-te statistics { global |
interface [ interface-type interface-number ]
Available in user view.
Configuring MPLS TE examples
This section provides examples of configuring MPLS TE.
MPLS TE using static CR-LSP configuration example
Network requirements
Switch A, Switch B, and Switch C run IS-IS.
Establish a TE tunnel using a static CR-LSP between Switch A and Switch C.
125
Figure 31 Network diagram
Configuration procedure
1.
Configure IP addresses and masks for the interfaces according to Figure 31. (Details not
shown.)
2.
Enable IS-IS to advertise routes destined for LSR IDs:
# Configure Switch A.
<SwitchA> system-view
[SwitchA] isis 1
[SwitchA-isis-1] network-entity 00.0005.0000.0000.0001.00
[SwitchA-isis-1] quit
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] isis enable 1
[SwitchA-Vlan-interface1] quit
[SwitchA] interface loopback 0
[SwitchA-LoopBack0] isis enable 1
[SwitchA-LoopBack0] quit
# Configure Switch B.
<SwitchB> system-view
[SwitchB] isis 1
[SwitchB-isis-1] network-entity 00.0005.0000.0000.0002.00
[SwitchB-isis-1] quit
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] isis enable 1
[SwitchB-Vlan-interface1] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] isis enable 1
[SwitchB-Vlan-interface2] quit
[SwitchB] interface loopback 0
[SwitchB-LoopBack0] isis enable 1
[SwitchB-LoopBack0] quit
# Configure Switch C.
<SwitchC> system-view
[SwitchC] isis 1
126
[SwitchC-isis-1] network-entity 00.0005.0000.0000.0003.00
[SwitchC-isis-1] quit
[SwitchC] interface vlan-interface 2
[SwitchC-Vlan-interface2] isis enable 1
[SwitchC-Vlan-interface2] quit
[SwitchC] interface loopback 0
[SwitchC-LoopBack0] isis enable 1
[SwitchC-LoopBack0] quit
Execute the display ip routing-table command on each switch. The output shows that all
nodes have learned the host routes of other nodes with LSR IDs as destinations. Take Switch A
for example:
[SwitchA] display ip routing-table
Routing Tables: Public
Destinations : 8
Destination/Mask
3.
Proto
Routes : 8
Cost
NextHop
Interface
1.1.1.1/32
Direct 0
Pre
0
127.0.0.1
InLoop0
2.1.1.0/24
Direct 0
0
2.1.1.1
Vlan1
2.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
2.2.2.2/32
ISIS
15
10
2.1.1.2
Vlan1
3.2.1.0/24
ISIS
15
20
2.1.1.2
Vlan1
3.3.3.3/32
ISIS
15
20
2.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
Configure basic MPLS TE:
# Configure Switch A.
[SwitchA] mpls lsr-id 1.1.1.1
[SwitchA] mpls
[SwitchA-mpls] mpls te
[SwitchA-mpls] quit
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] mpls
[SwitchA-Vlan-interface1] mpls te
[SwitchA-Vlan-interface1] quit
# Configure Switch B.
[SwitchB] mpls lsr-id 2.2.2.2
[SwitchB] mpls
[SwitchB-mpls] mpls te
[SwitchB-mpls] quit
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] mpls
[SwitchB-Vlan-interface1] mpls te
[SwitchB-Vlan-interface1] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] mpls
[SwitchB-Vlan-interface2] mpls te
[SwitchB-Vlan-interface2] quit
# Configure Switch C.
[SwitchC] mpls lsr-id 3.3.3.3
127
[SwitchC] mpls
[SwitchC-mpls] mpls te
[SwitchC-mpls] quit
[SwitchC] interface vlan-interface 2
[SwitchC-Vlan-interface2] mpls
[SwitchC-Vlan-interface2] mpls te
[SwitchC-Vlan-interface2] quit
4.
Configure an MPLS TE tunnel:
# Configure an MPLS TE tunnel on Switch A.
[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] ip address 6.1.1.1 255.255.255.0
[SwitchA-Tunnel0] tunnel-protocol mpls te
[SwitchA-Tunnel0] destination 3.3.3.3
[SwitchA-Tunnel0] mpls te tunnel-id 10
[SwitchA-Tunnel0] mpls te signal-protocol static
[SwitchA-Tunnel0] mpls te commit
[SwitchA-Tunnel0] quit
5.
Create a static CR-LSP:
# Configure Switch A as the ingress node of the static CR-LSP.
[SwitchA] static-cr-lsp ingress Tunnel0 destination 3.3.3.3 nexthop 2.1.1.2 out-label
20
# Configure Switch B as the transit node of the static CR-LSP.
[SwitchB] static-cr-lsp transit tunnel0 incoming-interface Vlan-interface1 in-label
20 nexthop 3.2.1.2 out-label 30
# Configure Switch C as the egress node of the static CR-LSP.
[SwitchC] static-cr-lsp egress tunnel0 incoming-interface Vlan-interface2 in-label
30
6.
Verify the configuration:
# Execute the display interface tunnel command on Switch A. The output shows that the
tunnel interface is up.
[SwitchA] display interface tunnel
Tunnel0 current state: UP
Line protocol current state: UP
Description: Tunnel0 Interface
The Maximum Transmit Unit is 64000
Internet Address is 6.1.1.1/24 Primary
Encapsulation is TUNNEL, service-loopback-group ID not set
Tunnel source unknown, destination 3.3.3.3
Tunnel protocol/transport CR_LSP
Output queue : (Urgent queuing : Size/Length/Discards)
0/100/0
Output queue : (Protocol queuing : Size/Length/Discards)
Output queue : (FIFO queuing : Size/Length/Discards)
Last 300 seconds input:
0 packets input,
0 bytes/sec, 0 packets/sec
0 bytes
0 input error
0 packets output,
0/75/0
0 bytes/sec, 0 packets/sec
Last 300 seconds output:
0 bytes
0 output error
128
0/500/0
# Execute the display mpls te tunnel command on each switch to display information about
the MPLS TE tunnel.
[SwitchA] display mpls te tunnel
LSP-Id
Destination
In/Out-If
Name
1.1.1.1:1
3.3.3.3
-/Vlan1
Tunnel0
[SwitchB] display mpls te tunnel
LSP-Id
-
Destination
-
In/Out-If
Name
Vlan1/Vlan2
Tunnel0
[SwitchC] display mpls te tunnel
LSP-Id
Destination
In/Out-If
Name
-
-
Vlan2/-
Tunnel0
# Execute the display mpls lsp command or the display mpls static-cr-lsp command on
each switch to display information about the static CR-LSP.
[SwitchA] display mpls lsp
------------------------------------------------------------------LSP Information: STATIC CRLSP
------------------------------------------------------------------FEC
In/Out Label
In/Out IF
3.3.3.3/32
NULL/20
-/Vlan1
Vrf Name
[SwitchB] display mpls lsp
-----------------------------------------------------------------LSP Information: STATIC CRLSP
-----------------------------------------------------------------FEC
In/Out Label
In/Out IF
Vrf Name
-/-
20/30
Vlan1/Vlan2
[SwitchC] display mpls lsp
-----------------------------------------------------------------LSP Information: STATIC CRLSP
-----------------------------------------------------------------FEC
In/Out Label
In/Out IF
-/-
30/NULL
Vlan1/-
Vrf Name
[SwitchA] display mpls static-cr-lsp
total statics-cr-lsp : 1
Name
FEC
I/O Label
I/O If
State
Tunnel0
3.3.3.3/32
NULL/20
-/Vlan1
Up
[SwitchB] display mpls static-cr-lsp
total statics-cr-lsp : 1
Name
FEC
I/O Label
I/O If
State
Tunnel0
-/-
20/30
Vlan1/Vlan2
Up
[SwitchC] display mpls static-cr-lsp
total statics-cr-lsp : 1
Name
FEC
I/O Label
I/O If
State
Tunnel0
-/-
30/NULL
Vlan2/-
Up
On an MPLS TE tunnel configured using a static CR-LSP, traffic is forwarded directly based on
label at the transit nodes and egress node. Therefore, it is normal that the FEC field in the
sample output is empty on Switch B and Switch C.
7.
Create a static route to direct traffic to the MPLS TE tunnel.
[SwitchA] ip route-static 3.2.1.2 24 tunnel 0 preference 1
129
# Execute the display ip routing-table command on Switch A. The output shows a static route
entry with interface Tunnel 0 as the outgoing interface.
MPLS TE using RSVP-TE configuration example
Network requirements
Switch A, Switch B, Switch C, and Switch D are running IS-IS and all of them are Level-2 devices.
Use RSVP-TE to create a TE tunnel with 2000 kbps of bandwidth from Switch A to Switch D, making
sure the maximum bandwidth of each link that the tunnel traverses is 10000 kbps and the maximum
reservable bandwidth is 5000 kbps.
Figure 32 Network diagram
Device
Interface
IP address
Device
Interface
IP address
Switch A
Loop0
1.1.1.9/32
Switch D
Loop0
4.4.4.9/32
Vlan-int1
10.1.1.1/24
Vlan-int3
30.1.1.2/24
Switch B
Loop0
2.2.2.9/32
Switch C
Loop0
3.3.3.9/32
Vlan-int1
10.1.1.2/24
Vlan-int3
30.1.1.1/24
Vlan-int2
20.1.1.1/24
Vlan-int2
20.1.1.2/24
Configuration procedure
1.
Configure IP addresses and masks for the interfaces according to Figure 32. (Details not
shown.)
2.
Enable IS-IS to advertise routes destined for LSR IDs:
# Configure Switch A.
<SwitchA> system-view
[SwitchA] isis 1
[SwitchA-isis-1] network-entity 00.0005.0000.0000.0001.00
[SwitchA-isis-1] quit
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] isis enable 1
[SwitchA-Vlan-interface1] isis circuit-level level-2
[SwitchA-Vlan-interface1] quit
[SwitchA] interface loopback 0
[SwitchA-LoopBack0] isis enable 1
[SwitchA-LoopBack0] isis circuit-level level-2
[SwitchA-LoopBack0] quit
# Configure Switch B.
130
<SwitchB> system-view
[SwitchB] isis 1
[SwitchB-isis-1] network-entity 00.0005.0000.0000.0002.00
[SwitchB-isis-1] quit
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] isis enable 1
[SwitchB-Vlan-interface1] isis circuit-level level-2
[SwitchB-Vlan-interface1] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] isis enable 1
[SwitchB-Vlan-interface2] isis circuit-level level-2
[SwitchB-Vlan-interface2] quit
[SwitchB] interface loopback 0
[SwitchB-LoopBack0] isis enable 1
[SwitchB-LoopBack0] isis circuit-level level-2
[SwitchB-LoopBack0] quit
# Configure Switch C.
<SwitchC> system-view
[SwitchC] isis 1
[SwitchC-isis-1] network-entity 00.0005.0000.0000.0003.00
[SwitchC-isis-1] quit
[SwitchC] interface vlan-interface 3
[SwitchC-Vlan-interface3] isis enable 1
[SwitchC-Vlan-interface3] isis circuit-level level-2
[SwitchC-Vlan-interface3] quit
[SwitchC] interface vlan-interface 2
[SwitchC-Vlan-interface2] isis enable 1
[SwitchC-Vlan-interface2] isis circuit-level level-2
[SwitchC-Vlan-interface2] quit
[SwitchC] interface loopback 0
[SwitchC-LoopBack0] isis enable 1
[SwitchC-LoopBack0] isis circuit-level level-2
[SwitchC-LoopBack0] quit
# Configure Switch D.
<SwitchD> system-view
[SwitchD] isis 1
[SwitchD-isis-1] network-entity 00.0005.0000.0000.0004.00
[SwitchD-isis-1] quit
[SwitchD] interface vlan-interface 3
[SwitchD-Vlan-interface3] isis enable 1
[SwitchD-Vlan-interface3] isis circuit-level level-2
[SwitchD-Vlan-interface3] quit
[SwitchD] interface loopback 0
[SwitchD-LoopBack0] isis enable 1
[SwitchD-LoopBack0] isis circuit-level level-2
[SwitchD-LoopBack0] quit
131
# Execute the display ip routing-table command on each switch. The output shows that all
nodes have learned the host routes of other nodes with LSR IDs as destinations. Take Switch A
for example:
[SwitchA] display ip routing-table
Routing Tables: Public
Destinations : 10
Destination/Mask
3.
Proto
Pre
Routes : 10
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
Vlan1
3.3.3.9/32
ISIS
15
20
10.1.1.2
Vlan1
4.4.4.9/32
ISIS
15
30
10.1.1.2
Vlan1
10.1.1.0/24
Direct 0
0
10.1.1.1
Vlan1
10.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
20.1.1.0/24
ISIS
15
20
10.1.1.2
Vlan1
30.1.1.0/24
ISIS
15
30
10.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
Configure basic MPLS TE, and enable RSVP-TE and CSPF:
# Configure Switch A.
[SwitchA] mpls lsr-id 1.1.1.9
[SwitchA] mpls
[SwitchA-mpls] mpls te
[SwitchA-mpls] mpls rsvp-te
[SwitchA-mpls] mpls te cspf
[SwitchA-mpls] quit
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] mpls
[SwitchA-Vlan-interface1] mpls te
[SwitchA-Vlan-interface1] mpls rsvp-te
[SwitchA-Vlan-interface1] quit
# Configure Switch B.
[SwitchB] mpls lsr-id 2.2.2.9
[SwitchB] mpls
[SwitchB-mpls] mpls te
[SwitchB-mpls] mpls rsvp-te
[SwitchB-mpls] mpls te cspf
[SwitchB-mpls] quit
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] mpls
[SwitchB-Vlan-interface1] mpls te
[SwitchB-Vlan-interface1] mpls rsvp-te
[SwitchB-Vlan-interface1] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] mpls
[SwitchB-Vlan-interface2] mpls te
[SwitchB-Vlan-interface2] mpls rsvp-te
[SwitchB-Vlan-interface2] quit
# Configure Switch C.
132
[SwitchC] mpls lsr-id 3.3.3.9
[SwitchC] mpls
[SwitchC-mpls] mpls te
[SwitchC-mpls] mpls rsvp-te
[SwitchC-mpls] mpls te cspf
[SwitchC-mpls] quit
[SwitchC] interface vlan-interface 3
[SwitchC-Vlan-interface3] mpls
[SwitchC-Vlan-interface3] mpls te
[SwitchC-Vlan-interface3] mpls rsvp-te
[SwitchC-Vlan-interface3] quit
[SwitchC] interface vlan-interface 2
[SwitchC-Vlan-interface2] mpls
[SwitchC-Vlan-interface2] mpls te
[SwitchC-Vlan-interface2] mpls rsvp-te
[SwitchC-Vlan-interface2] quit
# Configure Switch D.
[SwitchD] mpls lsr-id 4.4.4.9
[SwitchD] mpls
[SwitchD-mpls] mpls te
[SwitchD-mpls] mpls rsvp-te
[SwitchD-mpls] mpls te cspf
[SwitchD-mpls] quit
[SwitchD] interface vlan-interface 3
[SwitchD-Vlan-interface3] mpls
[SwitchD-Vlan-interface3] mpls te
[SwitchD-Vlan-interface3] mpls rsvp-te
[SwitchD-Vlan-interface3] quit
4.
Configure IS-IS TE:
# Configure Switch A.
[SwitchA] isis 1
[SwitchA-isis-1] cost-style wide
[SwitchA-isis-1] traffic-eng level-2
[SwitchA-isis-1] quit
# Configure Switch B.
[SwitchB] isis 1
[SwitchB-isis-1] cost-style wide
[SwitchB-isis-1] traffic-eng level-2
[SwitchB-isis-1] quit
# Configure Switch C.
[SwitchC] isis 1
[SwitchC-isis-1] cost-style wide
[SwitchC-isis-1] traffic-eng level-2
[SwitchC-isis-1] quit
# Configure Switch D.
[SwitchD] isis 1
[SwitchD-isis-1] cost-style wide
[SwitchD-isis-1] traffic-eng level-2
133
[SwitchD-isis-1] quit
5.
Configure MPLS TE attributes of links:
# Configure maximum link bandwidth and maximum reservable bandwidth on Switch A.
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] mpls te max-link-bandwidth 10000
[SwitchA-Vlan-interface1] mpls te max-reservable-bandwidth 5000
[SwitchA-Vlan-interface1] quit
# Configure maximum link bandwidth and maximum reservable bandwidth on Switch B.
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] mpls te max-link-bandwidth 10000
[SwitchB-Vlan-interface1] mpls te max-reservable-bandwidth 5000
[SwitchB-Vlan-interface1] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] mpls te max-link-bandwidth 10000
[SwitchB-Vlan-interface2] mpls te max-reservable-bandwidth 5000
[SwitchB-Vlan-interface2] quit
# Configure maximum link bandwidth and maximum reservable bandwidth on Switch C.
[SwitchC] interface vlan-interface 3
[SwitchC-Vlan-interface3] mpls te max-link-bandwidth 10000
[SwitchC-Vlan-interface3] mpls te max-reservable-bandwidth 5000
[SwitchC-Vlan-interface3] quit
[SwitchC] interface vlan-interface 2
[SwitchC-Vlan-interface2] mpls te max-link-bandwidth 10000
[SwitchC-Vlan-interface2] mpls te max-reservable-bandwidth 5000
[SwitchC-Vlan-interface2] quit
# Configure maximum link bandwidth and maximum reservable bandwidth on Switch D.
[SwitchD] interface vlan-interface 3
[SwitchD-Vlan-interface3] mpls te max-link-bandwidth 10000
[SwitchD-Vlan-interface3] mpls te max-reservable-bandwidth 5000
[SwitchD-Vlan-interface3] quit
6.
Create an MPLS TE tunnel:
# Create an MPLS TE tunnel on Switch A.
[SwitchA] interface tunnel 1
[SwitchA-Tunnel1] ip address 7.1.1.1 255.255.255.0
[SwitchA-Tunnel1] tunnel-protocol mpls te
[SwitchA-Tunnel1] destination 4.4.4.9
[SwitchA-Tunnel1] mpls te tunnel-id 10
[SwitchA-Tunnel1] mpls te signal-protocol rsvp-te
[SwitchA-Tunnel1] mpls te bandwidth 2000
[SwitchA-Tunnel1] mpls te commit
[SwitchA-Tunnel1] quit
7.
Verify the configuration:
# Execute the display interface tunnel command on Switch A. The output shows that the
tunnel interface is up.
[SwitchA] display interface tunnel
Tunnel1 current state: UP
Line protocol current state: UP
Description: Tunnel1 Interface
134
The Maximum Transmit Unit is 64000
Internet Address is 7.1.1.1/24 Primary
Encapsulation is TUNNEL, service-loopback-group ID not set
Tunnel source unknown, destination 4.4.4.9
Tunnel protocol/transport CR_LSP
Output queue : (Urgent queuing : Size/Length/Discards)
0/100/0
Output queue : (Protocol queuing : Size/Length/Discards)
Output queue : (FIFO queuing : Size/Length/Discards)
Last 300 seconds input:
0 bytes/sec, 0 packets/sec
Last 300 seconds output:
0 packets input,
0/500/0
0/75/0
0 bytes/sec, 0 packets/sec
0 bytes
0 input error
0 packets output,
0 bytes
0 output error
# Execute the display mpls te tunnel-interface command on Switch A to display information
about the MPLS TE tunnel.
[SwitchA] display mpls te tunnel-interface
Tunnel Name
:
Tunnel1
Tunnel Desc
:
Tunnel1 Interface
Tunnel State Desc :
CR-LSP is Up
Tunnel Attributes :
LSP ID
:
1.1.1.9:3
Session ID
:
10
Admin State
:
UP
Oper State
Ingress LSR ID
:
1.1.1.9
Egress LSR ID:
4.4.4.9
Signaling Prot
:
RSVP
Resv Style
:
SE
Class Type
:
CT0
Tunnel BW
:
2000 kbps
Reserved BW
:
2000 kbps
Setup Priority
:
7
Affinity Prop/Mask
:
0x0/0x0
Explicit Path Name
:
-
:
UP
Hold Priority:
7
Tie-Breaking Policy :
None
Metric Type
:
None
Record Route
:
Disabled
Record Label :
Disabled
FRR Flag
:
Disabled
BackUpBW Flag:
Not Supported
BackUpBW Type
:
-
BackUpBW
-
Route Pinning
:
Disabled
Retry Limit
:
10
Retry Interval:
Reopt
:
Disabled
Reopt Freq
Back Up Type
:
None
Back Up LSPID
:
-
Auto BW
:
Min BW
:
Current Collected BW:
-
Interfaces Protected:
-
VPN Bind Type
:
NONE
VPN Bind Value
:
-
Car Policy
:
Disabled
Tunnel Group
:
Primary
:
10 sec
:
-
Disabled
Auto BW Freq :
-
-
Max BW
-
135
:
Primary Tunnel
:
-
Backup Tunnel
:
-
Group Status
:
-
# Execute the display mpls te cspf tedb all command on Switch A to display information
about links in TEDB.
[SwitchA] display mpls te cspf tedb all
Maximum Node Supported: 128
Maximum Link Supported: 256
Current Total Node Number: 4
8.
Current Total Link Number: 6
Id
MPLS LSR-Id
IGP
Process-Id
Area
Link-Count
1
3.3.3.9
ISIS
1
Level-2
2
2
2.2.2.9
ISIS
1
Level-2
2
3
4.4.4.9
ISIS
1
Level-2
1
4
1.1.1.9
ISIS
1
Level-2
1
Create a static route to direct traffic to the MPLS TE tunnel.
[SwitchA] ip route-static 30.1.1.2 24 tunnel 1 preference 1
# Execute the display ip routing-table command on Switch A. The output shows a static route
entry with interface Tunnel1 as the outgoing interface.
RSVP-TE GR configuration example
Network requirements
Switch A, Switch B and Switch C are running IS-IS. All of them are Level-2 devices and support
RSVP hello extension.
Use RSVP-TE to create a TE tunnel from Switch A to Switch C.
Switch A, Switch B, and Switch C are RSVP-TE neighbors. Configure the RSVP-TE GR on the
routers, so each of them can provide GR helper support when another is GR restarting.
Figure 33 Network diagram
Configuration procedure
1.
Configure IP addresses and masks for the interfaces according to Figure 33. (Details not
shown.)
2.
Enable IS-IS to advertise routes destined for LSR IDs. (Details not shown.)
3.
Configure basic MPLS TE, and enable RSVP-TE and RSVP hello extension:
# Configure Switch A.
<SwitchA> system-view
[SwitchA] mpls lsr-id 1.1.1.9
[SwitchA] mpls
[SwitchA-mpls] mpls te
[SwitchA-mpls] mpls rsvp-te
[SwitchA-mpls] mpls rsvp-te hello
[SwitchA-mpls] interface vlan-interface 1
136
[SwitchA-Vlan-interface1] mpls
[SwitchA-Vlan-interface1] mpls te
[SwitchA-Vlan-interface1] mpls rsvp-te
[SwitchA-Vlan-interface1] mpls rsvp-te hello
[SwitchA-Vlan-interface1] quit
# Configure Switch B.
<SwitchB> system-view
[SwitchB] mpls lsr-id 2.2.2.9
[SwitchB] mpls
[SwitchB-mpls] mpls te
[SwitchB-mpls] mpls rsvp-te
[SwitchB-mpls] mpls rsvp-te hello
[SwitchB-mpls] interface vlan-interface 1
[SwitchB-Vlan-interface1] mpls
[SwitchB-Vlan-interface1] mpls te
[SwitchB-Vlan-interface1] mpls rsvp-te
[SwitchB-Vlan-interface1] mpls rsvp-te hello
[SwitchB-Vlan-interface1] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] mpls
[SwitchB-Vlan-interface2] mpls te
[SwitchB-Vlan-interface2] mpls rsvp-te
[SwitchB-Vlan-interface2] mpls rsvp-te hello
[SwitchB-Vlan-interface2] quit
# Configure Switch C.
<SwitchC> system-view
[SwitchC] mpls lsr-id 3.3.3.9
[SwitchC] mpls
[SwitchC-mpls] mpls te
[SwitchC-mpls] mpls rsvp-te
[SwitchC-mpls] mpls rsvp-te hello
[SwitchC-mpls] quit
[SwitchC] interface vlan-interface 2
[SwitchC-Vlan-interface2] mpls
[SwitchC-Vlan-interface2] mpls te
[SwitchC-Vlan-interface2] mpls rsvp-te
[SwitchC-Vlan-interface2] mpls rsvp-te hello
[SwitchC-Vlan-interface2] quit
4.
Configure IS-IS TE. (Details not shown.)
5.
Configure the MPLS TE tunnel. (Details not shown.)
6.
Configure RSVP-TE GR:
# Configure Switch A.
<SwitchA> system-view
[SwitchA] mpls
[SwitchA-mpls] mpls rsvp-te graceful-restart
# Configure Switch B.
<SwitchB> system-view
[SwitchB] mpls
137
[SwitchB-mpls] mpls rsvp-te graceful-restart
# Configure Switch C.
<SwitchC> system-view
[SwitchC] mpls
[SwitchC-mpls] mpls rsvp-te graceful-restart
7.
Verify the configuration:
A tunnel is created between Switch A and Switch C. Execute the following command. The
output shows that the neighbor's GR state is Ready.
<SwitchA> display mpls rsvp-te peer
Interface Vlan-interface1
Neighbor Addr: 10.1.1.2
SrcInstance: 880
NbrSrcInstance: 5017
PSB Count: 0
RSB Count: 1
Hello Type Sent: REQ
Neighbor Hello Extension: ENABLE
SRefresh Enable: NO
Graceful Restart State: Ready
Restart Time: 120 Sec
Recovery Time: 300 Sec
MPLS RSVP-TE and BFD cooperation configuration
example
Network requirements
Run OSPF on Switch A and Switch B to ensure IP connectivity.
Enable MPLS RSVP-TE BFD on the VLAN interfaces connecting the two switches. If the link
between Switch A and Switch B fails, BFD can detect the failure quickly and inform MPLS RSVP-TE
of the failure.
Figure 34 Network diagram
Configuration procedure
1.
Configure basic MPLS RSVP-TE settings:
# Configure Switch A.
<SwitchA> system-view
[SwitchA] mpls lsr-id 1.1.1.1
[SwitchA] mpls
[SwitchA-mpls] mpls te
[SwitchA-mpls] mpls rsvp-te
[SwitchA-mpls] quit
[SwitchA] interface vlan-interface 12
[SwitchA-Vlan-interface12] mpls
[SwitchA-Vlan-interface12] mpls te
138
[SwitchA-Vlan-interface12] mpls rsvp-te
[SwitchA-Vlan-interface12] mpls rsvp-te bfd enable
[SwitchA-Vlan-interface12] quit
# Configure Switch B.
<SwitchB> system-view
[SwitchB] mpls lsr-id 2.2.2.2
[SwitchB] mpls
[SwitchB-mpls] mpls te
[SwitchB-mpls] mpls rsvp-te
[SwitchB-mpls] quit
[SwitchB] interface vlan-interface 12
[SwitchB-Vlan-interface12] mpls
[SwitchB-Vlan-interface12] mpls te
[SwitchB-Vlan-interface12] mpls rsvp-te
[SwitchB-Vlan-interface12] mpls rsvp-te bfd enable
[SwitchB-Vlan-interface12] quit
2.
Configure OSPF:
# Configure Switch A.
[SwitchA] ospf
[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.0] network 12.12.12.1 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] network 1.1.1.1 0.0.0.0
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
# Configure Switch B.
[SwitchB] ospf
[SwitchB-ospf-1] area 0
[SwitchB-ospf-1-area-0.0.0.0] network 12.12.12.2 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchB-ospf-1] quit
3.
Configure IP addresses for the interfaces:
# Configure Switch A.
[SwitchA] interface vlan-interface 12
[SwitchA-Vlan-interface12] ip address 12.12.12.1 24
[SwitchA-Vlan-interface12] quit
# Configure Switch B.
[SwitchB] interface vlan-interface 12
[SwitchB-Vlan-interface12] ip address 12.12.12.2 24
4.
Configure the MPLS TE tunnel:
# Configure an RSVP-TE tunnel between Switch A and Switch B.
[SwitchA] interface tunnel 1
[SwitchA-Tunnel1] ip address 10.10.10.1 24
[SwitchA-Tunnel1] tunnel-protocol mpls te
[SwitchA-Tunnel1] destination 2.2.2.2
[SwitchA-Tunnel1] mpls te tunnel-id 10
[SwitchA-Tunnel1] mpls te signal-protocol rsvp-te
139
[SwitchA-Tunnel1] mpls te commit
[SwitchA-Tunnel1] return
5.
Verify the configuration:
On Switch A, display detailed information about the BFD session between Switch A and Switch
B.
<SwitchA> display bfd session verbose
Total Session Num: 1
Init Mode: Active
Session Working Under Ctrl Mode:
Local Discr: 21
Remote Discr: 20
Source IP: 12.12.12.1
Destination IP: 12.12.12.2
Session State: Up
Interface: Vlan-interface12
Min Trans Inter: 400ms
Act Trans Inter: 400ms
Min Recv Inter: 400ms
Act Detect Inter: 2000ms
Running Up for: 00:00:01
Auth mode: None
Connect Type: Direct
Board Num: 6
Protocol: RSVP
Diag Info: No Diagnostic
Bidirectional MPLS TE tunnel configuration example
Network requirements
Switch A, Switch B, Switch C, and Switch D all run IS-IS and they are all level-2 switches.
Use RSVP-TE to establish a bidirectional MPLS TE tunnel between Switch A to Switch D.
Figure 35 Network diagram
Device
Interface
IP address
Device
Interface
IP address
Switch A
Loop0
1.1.1.9/32
Switch D
Loop0
4.4.4.9/32
Vlan-int1
10.1.1.1/24
Vlan-int3
30.1.1.2/24
Switch B
Loop0
2.2.2.9/32
Switch C
Loop0
3.3.3.9/32
Vlan-int1
10.1.1.2/24
Vlan-int3
30.1.1.1/24
Vlan-int2
20.1.1.1/24
Vlan-int2
20.1.1.2/24
Configuration procedure
1.
Configure IP addresses and masks for the interfaces according to Figure 35.
140
2.
Configure IS-IS on each switch to advertise routes destined for LSR IDs.
For more information, see "MPLS TE using RSVP-TE configuration example."
3.
Configure basic MPLS TE, and enable RSVP-TE and CSPF:
# Configure Switch A.
<SwitchA> system-view
[SwitchA] mpls lsr-id 1.1.1.9
[SwitchA] mpls
[SwitchA-mpls] label advertise non-null
[SwitchA-mpls] mpls te
[SwitchA-mpls] mpls rsvp-te
[SwitchA-mpls] mpls te cspf
[SwitchA-mpls] quit
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] mpls
[SwitchA-Vlan-interface1] mpls te
[SwitchA-Vlan-interface1] mpls rsvp-te
[SwitchA-Vlan-interface1] quit
# Configure Switch B.
<SwitchB> system-view
[SwitchB] mpls lsr-id 2.2.2.9
[SwitchB] mpls
[SwitchB-mpls] mpls te
[SwitchB-mpls] mpls rsvp-te
[SwitchB-mpls] mpls te cspf
[SwitchB-mpls] quit
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] mpls
[SwitchB-Vlan-interface1] mpls te
[SwitchB-Vlan-interface1] mpls rsvp-te
[SwitchB-Vlan-interface1] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] mpls
[SwitchB-Vlan-interface2] mpls te
[SwitchB-Vlan-interface2] mpls rsvp-te
[SwitchB-Vlan-interface1] quit
# Configure Switch C.
<SwitchC> system-view
[SwitchC] mpls lsr-id 3.3.3.9
[SwitchC] mpls
[SwitchC-mpls] mpls te
[SwitchC-mpls] mpls rsvp-te
[SwitchC-mpls] mpls te cspf
[SwitchC-mpls] quit
[SwitchC] interface vlan-interface 3
[SwitchC-Vlan-interface3] mpls
[SwitchC-Vlan-interface3] mpls te
[SwitchC-Vlan-interface3] mpls rsvp-te
[SwitchC-Vlan-interface3] quit
141
[SwitchC] interface vlan-interface 2
[SwitchC-Vlan-interface2] mpls
[SwitchC-Vlan-interface2] mpls te
[SwitchC-Vlan-interface2] mpls rsvp-te
[SwitchC-Vlan-interface2] quit
# Configure Switch D.
<SwitchD> system-view
[SwitchD] mpls lsr-id 4.4.4.9
[SwitchD] mpls
[SwitchD-mpls] label advertise non-null
[SwitchD-mpls] mpls te
[SwitchD-mpls] mpls rsvp-te
[SwitchD-mpls] mpls te cspf
[SwitchD-mpls] quit
[SwitchD] interface vlan-interface 3
[SwitchD-Vlan-interface3] mpls
[SwitchD-Vlan-interface3] mpls te
[SwitchD-Vlan-interface3] mpls rsvp-te
[SwitchD-Vlan-interface3] quit
4.
Configure IS-IS TE:
# Configure Switch A.
[SwitchA] isis 1
[SwitchA-isis-1] cost-style wide
[SwitchA-isis-1] traffic-eng level-2
[SwitchA-isis-1] quit
# Configure Switch B.
[SwitchB] isis 1
[SwitchB-isis-1] cost-style wide
[SwitchB-isis-1] traffic-eng level-2
[SwitchB-isis-1] quit
# Configure Switch C.
[SwitchC] isis 1
[SwitchC-isis-1] cost-style wide
[SwitchC-isis-1] traffic-eng level-2
[SwitchC-isis-1] quit
# Configure Switch D.
[SwitchD] isis 1
[SwitchD-isis-1] cost-style wide
[SwitchD-isis-1] traffic-eng level-2
[SwitchD-isis-1] quit
5.
Configure a co-routed bidirectional MPLS TE tunnel:
# Configure Switch A as the active end of the co-routed bidirectional MPLS TE tunnel.
[SwitchA] interface tunnel 1
[SwitchA-Tunnel1] ip address 7.1.1.1 255.255.255.0
[SwitchA-Tunnel1] tunnel-protocol mpls te
[SwitchA-Tunnel1] destination 4.4.4.9
[SwitchA-Tunnel1] mpls te tunnel-id 1
[SwitchA-Tunnel1] mpls te signal-protocol rsvp-te
142
[SwitchA-Tunnel1] mpls te resv-style ff
[SwitchA-Tunnel1] mpls te bidirectional co-routed active
[SwitchA-Tunnel1] mpls te commit
[SwitchA-Tunnel1] quit
# Configure Switch A as the passive end of the co-routed bidirectional MPLS TE tunnel.
[SwitchD] interface tunnel 4
[SwitchD-Tunnel4] ip address 8.1.1.1 255.255.255.0
[SwitchD-Tunnel4] tunnel-protocol mpls te
[SwitchD-Tunnel4] destination 1.1.1.9
[SwitchD-Tunnel4] mpls te tunnel-id 4
[SwitchD-Tunnel4] mpls te signal-protocol rsvp-te
[SwitchD-Tunnel4] mpls te resv-style ff
[SwitchD-Tunnel4] mpls te bidirectional co-routed passive reverse-lsp lsr-id 1.1.1.9
tunnel-id 1
[SwitchD-Tunnel4] mpls te commit
[SwitchD-Tunnel4] quit
6.
Verify the configuration:
# Execute the display interface tunnel command on Switch A. The output shows that a tunnel
in up state has been established.
[SwitchA] display interface tunnel
Tunnel1 current state: UP
Line protocol current state: UP
Description: Tunnel1 Interface
The Maximum Transmit Unit is 64000
Internet Address is 7.1.1.1/24 Primary
Encapsulation is TUNNEL, service-loopback-group ID not set
Tunnel source unknown, destination 4.4.4.9
Tunnel bandwidth 64 (kbps)
Tunnel protocol/transport CR_LSP
Output queue : (Urgent queuing : Size/Length/Discards)
0/100/0
Output queue : (Protocol queuing : Size/Length/Discards)
Output queue : (FIFO queuing : Size/Length/Discards)
Last 300 seconds input:
0 bytes/sec, 0 packets/sec
Last 300 seconds output:
0 packets input,
0/500/0
0/75/0
0 bytes/sec, 0 packets/sec
0 bytes
0 input error
0 packets output,
0 bytes
0 output error
# Execute the display mpls te tunnel-interface command on Switch A to display detailed
information about the tunnel.
[SwitchA] display mpls te tunnel-interface
Tunnel Name
:
Tunnel1
Tunnel Desc
:
Tunnel1 Interface
Tunnel State Desc :
CR-LSP is Up
Tunnel Attributes :
LSP ID
:
1.1.1.9:3
Session ID
:
1
Admin State
:
UP
Oper State
Ingress LSR ID
:
1.1.1.9
Egress LSR ID:
143
:
UP
4.4.4.9
Signaling Prot
:
RSVP
Tunnel mode
:
Co-routed, active
Class Type
:
CT0
Reserved BW
:
0 kbps
Setup Priority
:
7
Affinity Prop/Mask
:
0x0/0x0
Explicit Path Name
:
-
Resv Style
:
FF
Tunnel BW
:
0 kbps
Hold Priority:
7
Tie-Breaking Policy :
None
Metric Type
:
None
Record Route
:
Disabled
Record Label :
Disabled
FRR Flag
:
Disabled
BackUpBW Flag:
Not Supported
BackUpBW Type
:
-
BackUpBW
-
Route Pinning
:
Disabled
Retry Limit
:
10
Retry Interval:
Reopt
:
Disabled
Reopt Freq
Back Up Type
:
None
Back Up LSPID
:
-
Auto BW
:
Min BW
:
10 sec
:
-
Disabled
Auto BW Freq :
-
Max BW
-
:
-
Current Collected BW:
-
Interfaces Protected:
-
VPN Bind Type
:
NONE
VPN Bind Value
:
-
Car Policy
:
Disabled
Tunnel Group
:
Primary
Primary Tunnel
:
-
Backup Tunnel
:
-
Group Status
:
-
Oam Status
:
-
:
# Execute the display mpls lsp verbose command on Switch A to display detailed information
about the two LSPs of the bidirectional tunnel.
[SwitchA] display mpls lsp verbose
------------------------------------------------------------------------LSP Information: RSVP LSP
------------------------------------------------------------------------No.
:
1
IngressLsrID
:
1.1.1.9
LocalLspID
:
3
Tunnel-Interface
:
Fec
:
*1.1.1.9/32
Nexthop
:
-------
In-Label
:
1310
Out-Label
:
NULL
In-Interface
:
Vlan-interface1
Out-Interface
:
----------
LspIndex
:
3077
Tunnel ID
:
0x0
LsrType
:
Egress
Bypass In Use
:
Not Exists
144
BypassTunnel
:
Tunnel Index[---]
No.
:
2
IngressLsrID
:
1.1.1.9
LocalLspID
:
3
Tunnel-Interface
:
Tunnel1
Fec
:
4.4.4.9/32
Nexthop
:
10.1.1.2
In-Label
:
NULL
Out-Label
:
1029
In-Interface
:
----------
Out-Interface
:
Vlan-interface1
LspIndex
:
3078
Tunnel ID
:
0xd2004
LsrType
:
Ingress
Bypass In Use
:
Not Exists
BypassTunnel
:
Tunnel Index[---]
# Execute the display interface tunnel command on Switch D. The output shows that a tunnel
in up state has been established.
[SwitchD] display interface tunnel
Tunnel4 current state: UP
Line protocol current state: UP
Description: Tunnel4 Interface
The Maximum Transmit Unit is 64000
Internet Address is 8.1.1.1/24 Primary
Encapsulation is TUNNEL, service-loopback-group ID not set
Tunnel source unknown, destination 1.1.1.9
Tunnel bandwidth 64 (kbps)
Tunnel protocol/transport CR_LSP
Output queue : (Urgent queuing : Size/Length/Discards)
0/100/0
Output queue : (Protocol queuing : Size/Length/Discards)
Output queue : (FIFO queuing : Size/Length/Discards)
Last 300 seconds input:
0/75/0
0 bytes/sec, 0 packets/sec
Last 300 seconds output:
0 packets input,
0/500/0
0 bytes/sec, 0 packets/sec
0 bytes
0 input error
0 packets output,
0 bytes
0 output error
# Execute the display mpls te tunnel-interface command on Switch D to display detailed
information about the tunnel.
[SwitchD] display mpls te tunnel-interface
Tunnel Name
:
Tunnel4
Tunnel Desc
:
Tunnel4 Interface
Tunnel State Desc :
CR-LSP is Up
Tunnel Attributes :
LSP ID
:
4.4.4.9:3
Session ID
:
4
Admin State
:
UP
Oper State
Ingress LSR ID
:
4.4.4.9
Egress LSR ID:
145
:
UP
1.1.1.9
Signaling Prot
:
RSVP
Tunnel mode
:
Co-routed, passive
Class Type
:
CT0
Reserved BW
:
0 kbps
Setup Priority
:
7
Affinity Prop/Mask
:
0x0/0x0
Explicit Path Name
:
-
Resv Style
:
FF
Tunnel BW
:
0 kbps
Hold Priority:
7
Tie-Breaking Policy :
None
Metric Type
:
None
Record Route
:
Disabled
Record Label :
Disabled
FRR Flag
:
Disabled
BackUpBW Flag:
Not Supported
BackUpBW Type
:
-
BackUpBW
-
Route Pinning
:
Disabled
Retry Limit
:
10
Retry Interval:
Reopt
:
Disabled
Reopt Freq
Back Up Type
:
None
Back Up LSPID
:
-
Auto BW
:
Min BW
:
10 sec
:
-
Disabled
Auto BW Freq :
-
Max BW
-
:
-
Current Collected BW:
-
Interfaces Protected:
-
VPN Bind Type
:
NONE
VPN Bind Value
:
-
Car Policy
:
Disabled
Tunnel Group
:
Primary
Primary Tunnel
:
-
Backup Tunnel
:
-
Group Status
:
-
Oam Status
:
-
:
# Execute the display mpls lsp verbose command on Switch D to display detailed information
about the two LSPs of the bidirectional tunnel.
[SwitchD] display mpls lsp verbose
------------------------------------------------------------------------LSP Information: RSVP LSP
------------------------------------------------------------------------No.
:
1
IngressLsrID
:
1.1.1.9
LocalLspID
:
3
Tunnel-Interface
:
Fec
:
*1.1.1.9/32
Nexthop
:
30.1.1.1
In-Label
:
NULL
Out-Label
:
1028
In-Interface
:
----------
Out-Interface
:
Vlan-interface3
LspIndex
:
3077
Tunnel ID
:
0x18004
LsrType
:
Ingress
Bypass In Use
:
Not Exists
146
BypassTunnel
:
Tunnel Index[---]
No.
:
2
IngressLsrID
:
1.1.1.9
LocalLspID
:
3
Tunnel-Interface
:
Tunnel1
Fec
:
4.4.4.9/32
Nexthop
:
-------
In-Label
:
1025
Out-Label
:
NULL
In-Interface
:
Vlan-interface3
Out-Interface
:
----------
LspIndex
:
3078
Tunnel ID
:
0x0
LsrType
:
Egress
Bypass In Use
:
Not Exists
BypassTunnel
:
Tunnel Index[---]
CR-LSP backup configuration example
Network requirements
Set up an MPLS TE tunnel from Switch A to Switch C. Use CR-LSP hot backup for it.
Figure 36 Network diagram
Device
Interface
IP address
Device
Interface
IP address
Switch A
Loop0
1.1.1.9/32
Switch D
Loop0
4.4.4.9/32
Vlan-int1
10.1.1.1/24
Vlan-int4
30.1.1.2/24
Vlan-int4
30.1.1.1/24
Vlan-int3
40.1.1.1/24
Loop0
2.2.2.9/32
Loop0
3.3.3.9/32
Vlan-int1
10.1.1.2/24
Vlan-int2
20.1.1.2/24
Vlan-int2
20.1.1.1/24
Vlan-int3
40.1.1.2/24
Switch B
Switch C
147
Configuration procedure
1.
Configure IP addresses and masks for the interfaces according to Figure 36. (Details not
shown.)
2.
Configure the IGP protocol:
# Enable IS-IS on each switch to advertise routes destined for LSR IDs. (Details not shown.)
# Execute the display ip routing-table command on each switch. The output shows that all
nodes have learned the host routes of other nodes with LSR IDs as destinations.
3.
Configure basic MPLS TE, and enable RSVP-TE and CSPF:
# Configure Switch A.
<SwitchA> system-view
[SwitchA] mpls lsr-id 1.1.1.9
[SwitchA] mpls
[SwitchA-mpls] mpls te
[SwitchA-mpls] mpls rsvp-te
[SwitchA-mpls] mpls te cspf
[SwitchA-mpls] quit
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] mpls
[SwitchA-Vlan-interface1] mpls te
[SwitchA-Vlan-interface1] mpls rsvp-te
[SwitchA-Vlan-interface1] quit
[SwitchA] interface vlan-interface 4
[SwitchA-Vlan-interface4] mpls
[SwitchA-Vlan-interface4] mpls te
[SwitchA-Vlan-interface4] mpls rsvp-te
[SwitchA-Vlan-interface4] quit
# Follow the same steps to configure Switch B, Switch C, and Switch D. (Details not shown.)
4.
Create an MPLS TE tunnel on Switch A:
# Configure the MPLS TE tunnel carried on the primary LSP.
[SwitchA] interface tunnel 1
[SwitchA-Tunnel1] ip address 9.1.1.1 24
[SwitchA-Tunnel1] tunnel-protocol mpls te
[SwitchA-Tunnel1] destination 3.3.3.9
[SwitchA-Tunnel1] mpls te tunnel-id 10
[SwitchA-Tunnel1] mpls te record-route
# Enable hot LSP backup.
[SwitchA-Tunnel1] mpls te backup hot-standby
[SwitchA-Tunnel1] mpls te commit
[SwitchA-Tunnel1] quit
Execute the display interface tunnel command on Switch A. The output shows that Tunnel1 is
up.
[SwitchA] display interface tunnel
Tunnel1 current state: UP
Line protocol current state: UP
Description: Tunnel1 Interface
The Maximum Transmit Unit is 64000
Internet Address is 9.1.1.1/24 Primary
Encapsulation is TUNNEL, service-loopback-group ID not set
148
Tunnel source unknown, destination 3.3.3.9
Tunnel protocol/transport CR_LSP
Output queue : (Urgent queuing : Size/Length/Discards)
0/100/0
Output queue : (Protocol queuing : Size/Length/Discards)
Output queue : (FIFO queuing : Size/Length/Discards)
Last 300 seconds input:
0/75/0
0 bytes/sec, 0 packets/sec
Last 300 seconds output:
0 packets input,
0/500/0
0 bytes/sec, 0 packets/sec
0 bytes
0 input error
0 packets output,
0 bytes
0 output error
5.
Verify the configuration:
# Execute the display mpls te tunnel command on Switch A. The output shows that two
tunnels are present with the outgoing interface being VLAN-interface 1 and VLAN-interface 4,
respectively. This indicates that a backup CR-LSP was created upon creation of the primary
CR-LSP.
[SwitchA] display mpls te tunnel
LSP-Id
Destination
In/Out-If
Name
1.1.1.9:6
3.3.3.9
-/Vlan1
Tunnel1
1.1.1.9:2054
3.3.3.9
-/Vlan4
Tunnel1
# Execute the display mpls te tunnel path command on Switch A to identify the paths that the
two tunnels traverse:
[SwitchA] display mpls te tunnel path
Tunnel Interface Name : Tunnel1
Lsp ID : 1.1.1.9 :6
Hop Information
Hop 0
10.1.1.1
Hop 1
10.1.1.2
Hop 2
2.2.2.9
Hop 3
20.1.1.1
Hop 4
20.1.1.2
Hop 5
3.3.3.9
Tunnel Interface Name : Tunnel1
Lsp ID : 1.1.1.9 :2054
Hop Information
Hop 0
30.1.1.1
Hop 1
30.1.1.2
Hop 2
4.4.4.9
Hop 3
40.1.1.1
Hop 4
40.1.1.2
Hop 5
3.3.3.9
# Execute the tracert command to draw the picture of the path that a packet must travel to reach
the tunnel destination.
[SwitchA] tracert –a 1.1.1.9 3.3.3.9
traceroute to
3.3.3.9(3.3.3.9) 30 hops max,40 bytes packet
1 10.1.1.2 25 ms 30.1.1.2 25 ms 10.1.1.2 25 ms
2 40.1.1.2 45 ms 20.1.1.2 29 ms 40.1.1.2 54 ms
The output shows that the current LSP traverses Switch B but not Switch D.
149
# Shut down VLAN-interface 2 on Switch B. Execute the tracert command on Switch A to draw
the path to the tunnel destination.
[SwitchA] tracert –a 1.1.1.9 3.3.3.9
traceroute to
3.3.3.9(3.3.3.9) 30 hops max,40 bytes packet
1 30.1.1.2 28 ms
27 ms
23 ms
2 40.1.1.2 50 ms
50 ms
49 ms
The output shows that the LSP is re-routed to traverse Switch D.
# Execute the display mpls te tunnel command on Switch A. The output shows that only the
tunnel traversing Switch D is present.
[SwitchA] display mpls te tunnel
LSP-Id
Destination
In/Out-If
Name
1.1.1.9:2054
3.3.3.9
-/Vlan4
Tunnel1
Configuring ordinary CR-LSP backup is almost the same as configuring hot CR-LSP backup
except that you replace the mpls te backup hot-standby command with the mpls te backup
ordinary command. Unlike in hot CR-LSP backup where a secondary tunnel is created
immediately upon creation of a primary tunnel, in ordinary CR-LSP backup, a secondary
CR-LSP is created only after the primary LSP goes down.
6.
Create a static route to direct traffic to the MPLS TE tunnel:
[SwitchA] ip route-static 20.1.1.2 24 tunnel 1 preference 1
# Execute the display ip routing-table command on Switch A. The output shows a static route
entry with Tunnel1 as the outgoing interface.
FRR configuration example
Network requirements
On a primary LSP Switch A—Switch B—Switch C—Switch D, use FRR to protect the link Switch
B—Switch C.
Create a bypass LSP that traverses the path Switch B—Switch E—Switch C. Switch B is the PLR
and Switch C is the MP.
Explicitly route the primary TE tunnel and the bypass TE tunnel with the signaling protocol being
RSVP-TE.
Figure 37 Network diagram
Device
Interface
IP address
Device
Interface
IP address
Switch A
Loop0
1.1.1.1/32
Switch E
Loop0
5.5.5.5/32
Vlan-int1
2.1.1.1/24
Vlan-int4
3.2.1.2/24
150
Switch B
Switch D
Loop0
2.2.2.2/32
Vlan-int1
2.1.1.2/24
Vlan-int5
3.3.1.1/24
Loop0
3.3.3.3/32
Vlan-int2
Vlan-int4
3.1.1.1/24
Vlan-int3
4.1.1.1/24
3.2.1.1/24
Vlan-int2
3.1.1.2/24
Loop0
4.4.4.4/32
Vlan-int5
3.3.1.2/24
Vlan-int3
4.1.1.2/24
Switch C
Configuration procedure
1.
Configure IP addresses and masks for the interfaces according to Figure 37. (Details not
shown.)
2.
Configure the IGP protocol.
# Enable IS-IS on each switch to advertise routes destined for LSR IDs. (Details not shown.)
# Execute the display ip routing-table command on each switch. The output shows that all
nodes have learned the host routes of other nodes with LSR IDs as destinations. Take Switch A
for example:
<SwitchA> display ip routing-table
Routing Tables: Public
Destinations : 13
Destination/Mask
3.
Proto
Pre
Routes : 13
Cost
NextHop
Interface
1.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
2.1.1.0/24
Direct 0
0
2.1.1.1
Vlan1
2.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
2.2.2.2/32
ISIS
15
10
2.1.1.2
Vlan1
3.1.1.0/24
ISIS
15
20
2.1.1.2
Vlan1
3.2.1.0/24
ISIS
15
20
2.1.1.2
Vlan1
3.3.1.0/24
ISIS
15
30
2.1.1.2
Vlan1
3.3.3.3/32
ISIS
15
20
2.1.1.2
Vlan1
4.1.1.0/24
ISIS
15
30
2.1.1.2
Vlan1
4.4.4.4/32
ISIS
15
30
2.1.1.2
Vlan1
5.5.5.5/32
ISIS
15
20
2.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
Configure basic MPLS TE, and enable RSVP-TE and CSPF:
# Configure Switch A.
[SwitchA] mpls lsr-id 1.1.1.1
[SwitchA] mpls
[SwitchA-mpls] mpls te
[SwitchA-mpls] mpls rsvp-te
[SwitchA-mpls] mpls te cspf
[SwitchA-mpls] quit
[SwitchA] interface vlan-interface 1
[SwitchA-Vlan-interface1] mpls
[SwitchA-Vlan-interface1] mpls te
[SwitchA-Vlan-interface1] mpls rsvp-te
[SwitchA-Vlan-interface1] quit
# Configure Switch B.
[SwitchB] mpls lsr-id 2.2.2.2
[SwitchB] mpls
151
[SwitchB-mpls] mpls te
[SwitchB-mpls] mpls rsvp-te
[SwitchB-mpls] mpls te cspf
[SwitchB-mpls] quit
[SwitchB] interface vlan-interface 1
[SwitchB-Vlan-interface1] mpls
[SwitchB-Vlan-interface1] mpls te
[SwitchB-Vlan-interface1] mpls rsvp-te
[SwitchB-Vlan-interface1] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] mpls
[SwitchB-Vlan-interface2] mpls te
[SwitchB-Vlan-interface2] mpls rsvp-te
[SwitchB-Vlan-interface2] quit
[SwitchB] interface vlan-interface 4
[SwitchB-Vlan-interface4] mpls
[SwitchB-Vlan-interface4] mpls te
[SwitchB-Vlan-interface4] mpls rsvp-te
[SwitchB-Vlan-interface4] quit
# Follow the same steps to configure Switch C, Switch D, and Switch E. (Details not shown.)
4.
Create an MPLS TE tunnel on Switch A, the ingress node of the primary LSP:
# Create an explicit path for the primary LSP.
[SwitchA] explicit-path pri-path
[SwitchA-explicit-path-pri-path] next hop 2.1.1.2
[SwitchA-explicit-path-pri-path] next hop 3.1.1.2
[SwitchA-explicit-path-pri-path] next hop 4.1.1.2
[SwitchA-explicit-path-pri-path] next hop 4.4.4.4
[SwitchA-explicit-path-pri-path] quit
# Configure the MPLS TE tunnel carried on the primary LSP.
[SwitchA] interface tunnel 4
[SwitchA-Tunnel4] ip address 10.1.1.1 255.255.255.0
[SwitchA-Tunnel4] tunnel-protocol mpls te
[SwitchA-Tunnel4] destination 4.4.4.4
[SwitchA-Tunnel4] mpls te tunnel-id 10
[SwitchA-Tunnel4] mpls te path explicit-path pri-path preference 1
# Enable FRR.
[SwitchA-Tunnel4] mpls te fast-reroute
[SwitchA-Tunnel4] mpls te commit
[SwitchA-Tunnel4] quit
Execute the display interface tunnel command on Switch A. The output shows that Tunnel4 is
up.
[SwitchA] display interface tunnel
Tunnel4 current state: UP
Line protocol current state: UP
Description: Tunnel4 Interface
The Maximum Transmit Unit is 64000
Internet Address is 10.1.1.1/24 Primary
Encapsulation is TUNNEL, service-loopback-group ID not set
152
Tunnel source unknown, destination 4.4.4.4
Tunnel protocol/transport CR_LSP
Output queue : (Urgent queuing : Size/Length/Discards)
0/100/0
Output queue : (Protocol queuing : Size/Length/Discards)
Output queue : (FIFO queuing : Size/Length/Discards)
Last 300 seconds input:
0/75/0
0 bytes/sec, 0 packets/sec
Last 300 seconds output:
0 packets input,
0/500/0
0 bytes/sec, 0 packets/sec
0 bytes
0 input error
0 packets output,
0 bytes
0 output error
Execute the display mpls te tunnel-interface command on Switch A to verify the configuration
of the tunnel interface.
[SwitchA] display mpls te tunnel-interface
Tunnel Name
:
Tunnel4
Tunnel Desc
:
Tunnel4 Interface
Tunnel State Desc
:
CR-LSP is Up
Tunnel Attributes
:
LSP ID
:
1.1.1.1:1
Session ID
:
10
Admin State
:
UP
Oper State
Ingress LSR ID
:
1.1.1.1
Egress LSR ID:
4.4.4.4
Signaling Prot
:
RSVP
Resv Style
:
SE
Class Type
:
CT0
Tunnel BW
:
0 kbps
Reserved BW
:
0 kbps
Setup Priority
:
7
Affinity Prop/Mask
:
0/0
Explicit Path Name
:
pri-path
:
Hold Priority:
UP
7
Tie-Breaking Policy :
None
Metric Type
:
None
Record Route
:
Enabled
Record Label :
Enabled
FRR Flag
:
Enabled
BackUpBW Flag:
Not Supported
BackUpBW Type
:
-
BackUpBW
-
Route Pinning
:
Disabled
Retry Limit
:
10
Retry Interval:
Reopt
:
Disabled
Reopt Freq
Back Up Type
:
None
Back Up LSPID
:
-
Auto BW
:
Min BW
:
10 sec
:
-
Disabled
Auto BW Freq :
-
Max BW
-
:
-
Current Collected BW:
-
Interfaces Protected:
-
VPN Bind Type
:
NONE
VPN Bind Value
:
-
Car Policy
:
Disabled
Tunnel Group
:
Primary
Primary Tunnel
:
-
Backup Tunnel
:
-
Group Status
:
-
153
:
5.
Configure a bypass tunnel on Switch B (the PLR):
# Create an explicit path for the bypass LSP.
[SwitchB] explicit-path by-path
[SwitchB-explicit-path-by-path] next hop 3.2.1.2
[SwitchB-explicit-path-by-path] next hop 3.3.1.2
[SwitchB-explicit-path-by-path] next hop 3.3.3.3
[SwitchB-explicit-path-by-path] quit
# Create the bypass tunnel.
[SwitchB] interface tunnel 5
[SwitchB-Tunnel5] ip address 11.1.1.1 255.255.255.0
[SwitchB-Tunnel5] tunnel-protocol mpls te
[SwitchB-Tunnel5] destination 3.3.3.3
[SwitchB-Tunnel5] mpls te tunnel-id 15
[SwitchB-Tunnel5] mpls te path explicit-path by-path preference 1
# Configure the bandwidth that the bypass tunnel protects.
[SwitchB-Tunnel5] mpls te backup bandwidth 10000
[SwitchB-Tunnel5] mpls te commit
[SwitchB-Tunnel5] quit
# Bind the bypass tunnel to the protected interface.
[SwitchB] interface Vlan-interface 2
[SwitchB-Vlan-interface2] mpls te fast-reroute bypass-tunnel tunnel 5
[SwitchB-Vlan-interface2] quit
Execute the display interface tunnel command on Switch B. The output shows that Tunnel5 is
up.
Execute the display mpls lsp command on each switch. The output shows that two LSPs are
traversing Switch B and Switch C.
[SwitchA] display mpls lsp
-----------------------------------------------------------------LSP Information: RSVP LSP
-----------------------------------------------------------------FEC
In/Out Label
In/Out IF
4.4.4.4/32
NULL/1024
-/Vlan1
Vrf Name
[SwitchB] display mpls lsp
-----------------------------------------------------------------LSP Information: RSVP LSP
-----------------------------------------------------------------FEC
In/Out Label
In/Out IF
4.4.4.4/32
1024/1024
Vlan1/Vlan2
3.3.3.3/32
NULL/1024
-/Vla4
Vrf Name
[SwitchC] display mpls lsp
-----------------------------------------------------------------LSP Information: RSVP LSP
-----------------------------------------------------------------FEC
In/Out Label
In/Out IF
4.4.4.4/32
1024/3
Vlan2/Vlan3
3.3.3.3/32
3/NULL
Vlan5/-
Vrf Name
[SwitchD] display mpls lsp
------------------------------------------------------------------
154
LSP Information: RSVP LSP
-----------------------------------------------------------------FEC
In/Out Label
In/Out IF
4.4.4.4/32
3/NULL
Vlan3/-
Vrf Name
[SwitchE] display mpls lsp
-----------------------------------------------------------------LSP Information: RSVP LSP
-----------------------------------------------------------------FEC
In/Out Label
In/Out IF
3.3.3.3/32
1024/3
Vlan4/Vlan5
Vrf Name
Execute the display mpls te tunnel command on each switch. The output shows that two
MPLS TE tunnels are traversing Switch B and Switch C.
[SwitchA] display mpls te tunnel
LSP-Id
Destination
In/Out-If
Name
1.1.1.1:1
4.4.4.4
-/Vlan1
Tunnel4
[SwitchB] display mpls te tunnel
LSP-Id
Destination
In/Out-If
Name
1.1.1.1:1
4.4.4.4
Vlan1/Vlan2
Tunnel4
2.2.2.2:1
3.3.3.3
-/Vlan4
Tunnel5
[SwitchC] display mpls te tunnel
LSP-Id
Destination
In/Out-If
Name
1.1.1.1:1
4.4.4.4
Vlan2/Vlan3
Tunnel4
2.2.2.2:1
3.3.3.3
Vlan5/-
Tunnel5
[SwitchD] display mpls te tunnel
LSP-Id
Destination
In/Out-If
Name
1.1.1.1:1
4.4.4.4
Vlan3/-
Tunnel4
[SwitchE] display mpls te tunnel
LSP-Id
Destination
In/Out-If
Name
2.2.2.2:1
3.3.3.3
Vlan4/Vlan5
Tunnel5
Execute the display mpls lsp verbose command on Switch B. The output shows that the
bypass tunnel is bound with the protected interface VLAN-interface 2 and is currently unused.
[SwitchB] display mpls lsp verbose
------------------------------------------------------------------LSP Information: RSVP LSP
------------------------------------------------------------------No
:
1
IngressLsrID
:
1.1.1.1
LocalLspID
:
1
Tunnel-Interface
:
Tunnel4
Fec
:
4.4.4.4/32
Nexthop
:
3.1.1.2
In-Label
:
1024
Out-Label
:
1024
In-Interface
:
Vlan-interface1
Out-Interface
:
Vlan-interface2
LspIndex
:
4097
Tunnel ID
:
0x22001
LsrType
:
Transit
Bypass In Use
:
Not Used
155
6.
BypassTunnel
:
Tunnel Index[Tunnel5], InnerLabel[1024]
Mpls-Mtu
:
1500
No
:
2
IngressLsrID
:
2.2.2.2
LocalLspID
:
1
Tunnel-Interface
:
Tunnel5
Fec
:
3.3.3.3/32
Nexthop
:
3.2.1.2
In-Label
:
NULL
Out-Label
:
1024
In-Interface
:
----------
Out-Interface
:
Vlan-interface4
LspIndex
:
4098
Tunnel ID
:
0x22002
LsrType
:
Ingress
Bypass In Use
:
Not Exists
BypassTunnel
:
Tunnel Index[---]
Mpls-Mtu
:
1500
Verify the FRR function:
# Shut down the protected outgoing interface on PLR.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] shutdown
%Sep 7 08:53:34 2004 SwitchB IFNET/5/UPDOWN:Line protocol on the interface
Vlan-interface2 turns into DOWN state
Execute the display interface tunnel 4 command on Switch A to identify the state of the
primary LSP. The output shows that the tunnel interface is still up.
Execute the display mpls te tunnel-interface command on Switch A to display the
configuration of the tunnel interface.
[SwitchA] display mpls te tunnel-interface
Tunnel Name
: Tunnel4
Tunnel Desc
: Tunnel4 Interface
Tunnel State Desc
: Modifying CR-LSP is setting up
Tunnel Attributes
:
LSP ID
:
1.1.1.1:1
Session ID
:
10
Admin State
:
UP
Oper State
Ingress LSR ID
:
1.1.1.1
Egress LSR ID:
4.4.4.4
Signaling Prot
:
RSVP
Resv Style
:
SE
Class Type
:
CT0
Tunnel BW
:
0 kbps
Reserved BW
:
0 kbps
Setup Priority
:
7
Affinity Prop/Mask
:
0x0/0x0
Explicit Path Name
:
pri-path
:
Hold Priority:
UP
7
Tie-Breaking Policy :
None
Metric Type
:
None
Record Route
:
Enabled
Record Label :
Enabled
FRR Flag
:
Enabled
BackUpBW Flag:
Not Supported
BackUpBW Type
:
-
BackUpBW
-
156
:
Route Pinning
:
Disabled
Retry Limit
:
10
Retry Interval:
Reopt
:
Disabled
Reopt Freq
Back Up Type
:
None
Back Up LSPID
:
-
Auto BW
:
Disabled
Auto BW Freq :
-
Min BW
Max BW
-
:
-
Current Collected BW:
-
Interfaces Protected:
-
VPN Bind Type
:
NONE
VPN Bind Value
:
-
Car Policy
:
Disabled
Tunnel Group
:
Primary
Primary Tunnel
:
-
Backup Tunnel
:
-
Group Status
:
-
Tunnel Name
:
Tunnel4
Tunnel Desc
:
Tunnel4 Interface
Tunnel State Desc
:
Modifying CR-LSP is setting up
Tunnel Attributes
:
:
10 sec
-
:
LSP ID
:
1.1.1.1:1025
Session ID
:
10
Admin State
:
Ingress LSR ID
:
1.1.1.1
Egress LSR ID:
4.4.4.4
Signaling Prot
:
RSVP
Resv Style
:
SE
Class Type
:
CT0
Tunnel BW
:
0 kbps
Reserved BW
:
0 kbps
Setup Priority
:
7
Affinity Prop/Mask
:
0x0/0x0
Explicit Path Name
:
pri-path
Oper State
:
Hold Priority:
Modified
7
Tie-Breaking Policy :
None
Metric Type
:
None
Record Route
:
Enabled
Record Label :
Enabled
FRR Flag
:
Enabled
BackUpBW Flag:
Not Supported
BackUpBW Type
:
-
BackUpBW
-
Route Pinning
:
Disabled
Retry Limit
:
10
Retry Interval:
Reopt
:
Disabled
Reopt Freq
Back Up Type
:
None
Back Up LSPID
:
-
Auto BW
:
Min BW
:
10 sec
:
-
Disabled
Auto BW Freq :
-
Max BW
-
:
-
Current Collected BW:
-
Interfaces Protected:
-
VPN Bind Type
:
NONE
VPN Bind Value
:
-
Car Policy
:
Disabled
157
:
Tunnel Group
:
Primary
Primary Tunnel
:
-
Backup Tunnel
:
-
Group Status
:
-
If you execute the display mpls te tunnel-interface command immediately after an FRR
protection switch, you are likely to see two CR-LSPs in up state are present. This is normal
because the make-before-break mechanism of FRR introduces a delay before removing the old
LSP after a new LSP is created.
# Execute the display mpls lsp verbose command on Switch B. The output shows that the
bypass tunnel is in use.
[SwitchB] display mpls lsp verbose
-----------------------------------------------------------------LSP Information: RSVP LSP
-----------------------------------------------------------------No
:
1
IngressLsrID
:
1.1.1.1
LocalLspID
:
1
Tunnel-Interface
:
Tunnel4
Fec
:
4.4.4.4/32
Nexthop
:
3.1.1.2
In-Label
:
1024
Out-Label
:
1024
In-Interface
:
Vlan-interface1
Out-Interface
:
Vlan-interface2
LspIndex
:
4097
Tunnel ID
:
0x22001
LsrType
:
Transit
Bypass In Use
:
In Use
BypassTunnel
:
Tunnel Index[Tunnel5], InnerLabel[1024]
Mpls-Mtu
:
1500
No
:
2
IngressLsrID
:
2.2.2.2
LocalLspID
:
1
Tunnel-Interface
:
Tunnel5
Fec
:
3.3.3.3/32
Nexthop
:
3.2.1.2
In-Label
:
NULL
Out-Label
:
1024
In-Interface
:
----------
Out-Interface
:
Vlan-interface4
LspIndex
:
4098
Tunnel ID
:
0x22002
LsrType
:
Ingress
Bypass In Use
:
Not Exists
BypassTunnel
:
Tunnel Index[---]
Mpls-Mtu
:
1500
# Set the FRR polling timer to five seconds on PLR.
[SwitchB] mpls
158
[SwitchB-mpls] mpls te timer fast-reroute 5
[SwitchB-mpls] quit
# Bring the protected outgoing interface up on PLR.
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] undo shutdown
%Sep 7 09:01:31 2004 SwitchB IFNET/5/UPDOWN:Line protocol on the interface
Vlan-interface2 turns into UP state
# Execute the display interface tunnel 4 command on Switch A to identify the state of the
primary LSP. The output shows that the tunnel interface is up.
About 5 seconds later, execute the display mpls lsp verbose command on Switch B. The
output shows that Tunnel5 is still bound with interface VLAN-interface 2 and is unused.
7.
Create a static route to direct traffic to the MPLS TE tunnel.
[SwitchA] ip route-static 4.1.1.2 24 tunnel 4 preference 1
# Execute the display ip routing-table command on Switch A. The output shows a static route
entry with Tunnel4 as the outgoing interface.
MPLS TE in MPLS L3VPN configuration example
Network requirements
CE 1 and CE 2 belong to VPN 1. They are connected to the MPLS backbone through PE 1 and PE 2.
The IGP protocol running on the MPLS backbone is OSPF.
Set up an MPLS TE tunnel to forward traffic of VPN 1 from PE 1 to PE 2.
To allow the MPLS L3VPN traffic to travel the TE tunnel, configure a tunneling policy to use a
CR-LSP as the VPN tunnel when creating the VPN.
Figure 38 Network diagram
Configuration procedure
1.
Configure OSPF, making sure PE 1 and PE 2 can learn LSR-ID routes from each other:
# Configure PE 1.
<PE1> system-view
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 2.2.2.2 255.255.255.255
[PE1-LoopBack0] quit
[PE1] interface vlan-interface 2
[PE1-Vlan-interface2] ip address 10.0.0.1 255.255.255.0
159
[PE1-Vlan-interface2] quit
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 10.0.0.0 0.0.0.255
[PE1-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Configure PE 2.
<PE2> system-view
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 3.3.3.3 255.255.255.255
[PE2-LoopBack0] quit
[PE2] interface vlan-interface 2
[PE2-Vlan-interface2] ip address 10.0.0.2 255.255.255.0
[PE2-Vlan-interface2] quit
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1-area-0.0.0.0] network 10.0.0.0 0.0.0.255
[PE2-ospf-1-area-0.0.0.0] network 3.3.3.3 0.0.0.0
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
After you complete the configuration, the PEs are able to establish the OSPF neighbor
relationship. Execute the display ospf peer verbose command. The output shows that the
neighbor relationship state is FULL. Execute the display ip routing-table command. The
output shows that the PEs have learned the routes to the loopback interfaces of each other.
Take PE 1 for example:
[PE1] display ospf peer verbose
OSPF Process 1 with Router ID 2.2.2.2
Neighbors
Area 0.0.0.0 interface 10.0.0.1(Vlan-interface2)'s neighbors
Router ID: 3.3.3.3
State: Full
DR: None
Address: 10.0.0.2
Mode:Nbr is
Master
GR State: Normal
Priority: 1
BDR: None
Dead timer due in 30
sec
Neighbor is up for 00:01:00
Authentication Sequence: [ 0 ]
[PE1] display ip routing-table
Routing Tables: Public
Destinations : 7
Destination/Mask
2.
Proto
Pre
Routes : 7
Cost
NextHop
Interface
2.2.2.2/32
Direct 0
0
127.0.0.1
InLoop0
3.3.3.3/32
OSPF
1563
10.0.0.2
Vlan2
10
10.0.0.0/24
Direct 0
0
10.0.0.1
Vlan2
10.0.0.1/32
Direct 0
0
127.0.0.1
InLoop0
10.0.0.2/32
Direct 0
0
10.0.0.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
Configure basic MPLS TE, and enable RSVP-TE and CSPF:
# Configure PE 1.
160
[PE1] mpls lsr-id 2.2.2.2
[PE1] mpls
[PE1-mpls] lsp-trigger all
[PE1-mpls] mpls te
[PE1-mpls] mpls rsvp-te
[PE1-mpls] mpls te cspf
[PE1-mpls] quit
[PE1] interface vlan-interface 2
[PE1-Vlan-interface2] mpls
[PE1-Vlan-interface2] mpls te
[PE1-Vlan-interface2] mpls rsvp-te
[PE1-Vlan-interface2] quit
# Configure PE2.
[PE2] mpls lsr-id 3.3.3.3
[PE2] mpls
[PE2-mpls] lsp-trigger all
[PE2-mpls] mpls te
[PE2-mpls] mpls rsvp-te
[PE2-mpls] mpls te cspf
[PE2-mpls] quit
[PE2] interface vlan-interface 2
[PE2-Vlan-interface2] mpls
[PE2-Vlan-interface2] mpls te
[PE2-Vlan-interface2] mpls rsvp-te
[PE2-Vlan-interface2] quit
3.
Enable OSPF TE:
# Configure PE 1.
[PE1] ospf
[PE1-ospf-1] opaque-capability enable
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] mpls-te enable
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Configure PE 2.
[PE2] ospf
[PE2-ospf-1] opaque-capability enable
[PE2-ospf-1] area 0
[PE2-ospf-1-area-0.0.0.0] mpls-te enable
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
4.
Configure an MPLS TE tunnel:
# Create a TE tunnel with PE 1 as the ingress node and PE 2 as the egress node. The signaling
protocol is RSVP-TE.
[PE1] interface tunnel 1
[PE1-Tunnel1] ip address 12.1.1.1 255.255.255.0
[PE1-Tunnel1] tunnel-protocol mpls te
[PE1-Tunnel1] destination 3.3.3.3
[PE1-Tunnel1] mpls te tunnel-id 10
161
[PE1-Tunnel1] mpls te signal-protocol rsvp-te
[PE1-Tunnel1] mpls te commit
[PE1-Tunnel1] quit
Execute the display interface tunnel command on PE 1. The output shows that the tunnel
interface is up.
5.
Configure the VPN instance on each PE, and bind it to the interface connected to the CE:
# Configure on CE 1.
<CE1> system-view
[CE1] interface vlan-interface 1
[CE1-Vlan-interface1] ip address 192.168.1.2 255.255.255.0
[CE1-Vlan-interface1] quit
# Configure the VPN instance on PE 1, and use CR-LSP for VPN setup. Bind the VPN instance
to the interface connected to CE 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] tnl-policy policy1
[PE1-vpn-instance-vpn1] quit
[PE1] tunnel-policy policy1
[PE1-tunnel-policy-policy1] tunnel select-seq cr-lsp load-balance-number 1
[PE1-tunnel-policy-policy1] quit
[PE1] interface vlan-interface 1
[PE1-Vlan-interface1] ip binding vpn-instance vpn1
[PE1-Vlan-interface1] ip address 192.168.1.1 255.255.255.0
[PE1-Vlan-interface1] quit
# Configure on CE 2.
<CE2> system-view
[CE2] interface vlan-interface 3
[CE2-Vlan-interface3] ip address 192.168.2.2 255.255.255.0
[CE2-Vlan-interface3] quit
# Configure the VPN instance on PE 2, and bind it to the interface connected to CE 2.
[PE2] ip vpn-instance vpn1
[PE2-vpn-instance-vpn1] route-distinguisher 100:2
[PE2-vpn-instance-vpn1] vpn-target 100:1 both
[PE2-vpn-instance-vpn1] quit
[PE2] interface vlan-interface 3
[PE2-Vlan-interface3] ip binding vpn-instance vpn1
[PE2-Vlan-interface3] ip address 192.168.2.1 255.255.255.0
[PE2-Vlan-interface3] quit
Execute the display ip vpn-instance command on the PEs to display the configuration of the
VPN instance. Take PE 1 for example:
[PE1] display ip vpn-instance instance-name vpn1
VPN-Instance Name and ID : vpn1, 1
Create time : 2006/09/27 15:10:29
Up time : 0 days, 00 hours, 03 minutes and 09 seconds
Route Distinguisher : 100:1
Export VPN Targets :
100:1
Import VPN Targets :
100:1
162
Tunnel Policy : policy1
Interfaces : Vlan-interface1
Ping connected CEs on PEs to test connectivity. For example, ping CE 1 on PE 1:
[PE1] ping -vpn-instance vpn1 192.168.1.2
PING 192.168.1.2: 56
data bytes, press CTRL_C to break
Reply from 192.168.1.2: bytes=56 Sequence=1 ttl=255 time=47 ms
Reply from 192.168.1.2: bytes=56 Sequence=2 ttl=255 time=26 ms
Reply from 192.168.1.2: bytes=56 Sequence=3 ttl=255 time=26 ms
Reply from 192.168.1.2: bytes=56 Sequence=4 ttl=255 time=26 ms
Reply from 192.168.1.2: bytes=56 Sequence=5 ttl=255 time=26 ms
--- 192.168.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 26/30/47 ms
The output shows that PE 1 can reach CE 1.
6.
Configure BGP:
# Configure CE 1.
[CE1] bgp 65001
[CE1-bgp] peer 192.168.1.1 as-number 100
[CE1-bgp] quit
# Configure PE 1 to establish the EBGP peer relationship with CE 1, and the IBGP peer
relationship with PE 2.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] peer 192.168.1.2 as-number 65001
[PE1-bgp-vpn1] import-route direct
[PE1-bgp-vpn1] quit
[PE1-bgp] peer 3.3.3.3 as-number 100
[PE1-bgp] peer 3.3.3.3 connect-interface loopback 0
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 3.3.3.3 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
# Configure CE 2.
[CE2] bgp 65002
[CE2-bgp] peer 192.168.2.1 as-number 100
[CE2-bgp] quit
# Configure PE 2 to establish the EBGP peer relationship with CE 2 and the IBGP relationship
with PE 1.
[PE2] bgp 100
[PE2-bgp] ipv4-family vpn-instance vpn1
[PE2-bgp-vpn1] peer 192.168.2.2 as-number 65002
[PE2-bgp-vpn1] import-route direct
[PE2-bgp-vpn1] quit
[PE2-bgp] peer 2.2.2.2 as-number 100
[PE2-bgp] peer 2.2.2.2 connect-interface loopback 0
[PE2-bgp] ipv4-family vpnv4
163
[PE2-bgp-af-vpnv4] peer 2.2.2.2 enable
[PE2-bgp-af-vpnv4] quit
[PE2-bgp] quit
# Execute the display bgp peer command and the display bgp vpn-instance peer command
on PEs. The output shows that the BGP peer relationships have been formed between PEs and
between PEs and CEs and have reached Established state. Take PE 1 for example:
[PE1-bgp] display bgp peer
BGP local router ID : 2.2.2.2
Local AS number : 100
Total number of peers : 1
Peer
V
AS
3.3.3.3
4
100
Peers in established state : 1
MsgRcvd
MsgSent
OutQ
3
3
0
Up/Down
State
PrefRcv
00:00:11
Established
0
[PE1-bgp] display bgp vpn-instance vpn1 peer
BGP local router ID : 2.2.2.2
Local AS number : 100
Total number of peers : 1
Peer
V AS
Peers in established state : 1
MsgRcvd
192.168.1.2 4 65001
MsgSent
4
OutQ
5
0
Up/Down
State
00:02:13 Established
PrefRcv
0
# Ping CE 2 from CE 1 and ping CE 1 from CE 2 to test connectivity.
[CE1] ping 192.168.2.2
PING 192.168.2.2: 56
data bytes, press CTRL_C to break
Reply from 192.168.2.2: bytes=56 Sequence=1 ttl=253 time=61 ms
Reply from 192.168.2.2: bytes=56 Sequence=2 ttl=253 time=54 ms
Reply from 192.168.2.2: bytes=56 Sequence=3 ttl=253 time=53 ms
Reply from 192.168.2.2: bytes=56 Sequence=4 ttl=253 time=57 ms
Reply from 192.168.2.2: bytes=56 Sequence=5 ttl=253 time=36 ms
--- 192.168.2.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 36/52/61 ms
[CE2] ping 192.168.1.2
PING 192.168.1.2: 56
data bytes, press CTRL_C to break
Reply from 192.168.1.2: bytes=56 Sequence=1 ttl=253 time=38 ms
Reply from 192.168.1.2: bytes=56 Sequence=2 ttl=253 time=61 ms
Reply from 192.168.1.2: bytes=56 Sequence=3 ttl=253 time=74 ms
Reply from 192.168.1.2: bytes=56 Sequence=4 ttl=253 time=36 ms
Reply from 192.168.1.2: bytes=56 Sequence=5 ttl=253 time=35 ms
--- 192.168.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 35/48/74 ms
The output shows that CE 1 and CE 2 can reach each other.
7.
Verify the configuration:
# Execute the display mpls lsp verbose command on PE 1. The output shows that the LSP
with LspIndex 2050 has been established by using RSVP-TE. It is the MPLS TE tunnel.
[PE1] display mpls lsp verbose
164
-----------------------------------------------------------------LSP Information: RSVP LSP
-----------------------------------------------------------------No
:
1
IngressLsrID
:
2.2.2.2
LocalLspID
:
1
Tunnel-Interface
:
Tunnel1
Fec
:
3.3.3.3/32
Nexthop
:
10.0.0.2
In-Label
:
NULL
Out-Label
:
1024
In-Interface
:
----------
Out-Interface
:
Vlan-interface2
LspIndex
:
2050
Tunnel ID
:
0x22004
LsrType
:
Ingress
Bypass In Use
:
Not Exists
BypassTunnel
:
Tunnel Index[---]
Mpls-Mtu
:
1500
-----------------------------------------------------------------LSP Information: BGP
LSP
-----------------------------------------------------------------No
:
2
VrfIndex
:
vpn1
Fec
:
192.168.1.0/24
Nexthop
:
192.168.1.1
In-Label
:
1024
Out-Label
:
NULL
In-Interface
:
----------
Out-Interface
:
----------
LspIndex
:
8193
Tunnel ID
:
0x0
LsrType
:
Egress
Outgoing Tunnel ID
:
0x0
Label Operation
:
POP
-----------------------------------------------------------------LSP Information: LDP LSP
-----------------------------------------------------------------No
:
VrfIndex
:
3
Fec
:
2.2.2.2/32
Nexthop
:
127.0.0.1
In-Label
:
3
Out-Label
:
NULL
In-Interface
:
Vlan-interface2
Out-Interface
:
----------
LspIndex
:
10241
Tunnel ID
:
0x0
165
LsrType
:
Egress
Outgoing Tunnel ID
:
0x0
Label Operation
:
POP
No
:
4
VrfIndex
:
Fec
:
3.3.3.3/32
Nexthop
:
10.0.0.2
In-Label
:
NULL
Out-Label
:
3
In-Interface
:
----------
Out-Interface
:
Vlan-interface2
LspIndex
:
10242
Tunnel ID
0x22000
LsrType
:
Ingress
Outgoing Tunnel ID
:
0x0
Label Operation
:
PUSH
# Execute the display interface tunnel command on PE 1. The output shows that traffic is
forwarded along the CR-LSP of the TE tunnel.
[PE1] display interface tunnel 1
Tunnel1 current state: UP
Line protocol current state: UP
Description: Tunnel1 Interface
The Maximum Transmit Unit is 1500
Internet Address is 12.1.1.1/24 Primary
Encapsulation is TUNNEL, service-loopback-group ID not set
Tunnel source unknown, destination 3.3.3.3
Tunnel protocol/transport CR_LSP
Output queue : (Urgent queuing : Size/Length/Discards)
0/100/0
Output queue : (Protocol queuing : Size/Length/Discards)
Output queue : (FIFO queuing : Size/Length/Discards)
Last 300 seconds input:
Last 300 seconds output:
34 packets input,
0/500/0
0/75/0
5 bytes/sec, 0 packets/sec
5 bytes/sec, 0 packets/sec
2856 bytes
0 input error
34 packets output,
2856 bytes
0 output error
Troubleshooting MPLS TE
This section describes how to troubleshoot MPLS TE.
No TE LSA generated
Symptom
OSPF TE is configured but no TE LSAs can be generated to describe MPLS TE attributes.
166
Analysis
For TE LSAs to be generated, at least one OSPF neighbor must reach the FULL state.
Solution
1.
Execute the display current-configuration command to verify that MPLS TE is configured on
involved interfaces.
2.
Execute the debugging ospf mpls-te command to observe whether OSPF can receive the TE
LINK establishment message.
3.
Execute the display ospf peer command to verify that OSPF neighbors are established
correctly.
167
Configuring VPLS
This chapter describes how to configure VPLS.
Hardware compatibility
The HPE 5820X Switch Series does not support VPLS.
VPLS overview
Virtual Private LAN Service (VPLS), also called "Transparent LAN Service (TLS)" or "virtual private
switched network service," can deliver a point-to-multipoint L2VPN service over public networks.
With VPLS, geographically-dispersed sites can interconnect and communicate over MAN or WAN as
if they were on the same LAN.
VPLS provides Layer 2 VPN services. However, it supports multipoint services rather than the
point-to-point services the traditional VPN supports. With VPLS, service providers can create a
series of virtual switches for customers on the PEs, allowing customers to build their LANs across
the MAN or WAN.
Basic VPLS concepts
•
CE—Customer edge device. A CE is directly connected to the PE.
•
PE—Provider edge device. A PE connects one or more CEs to the service provider network. It
maps and forwards packets between private networks and public network tunnels. A PE can be
a UPE or NPE.
•
UPE—User facing provider edge device. A UPE functions as the user access convergence
device.
•
NPE—Network provider edge device. An NPE functions as the network core PE, resides at the
edge of a VPLS network core domain, and provides transparent VPLS transport services
between core networks.
•
VSI—Virtual switch instances (hereinafter referred to as "VPLS instances") maps actual access
links to virtual links.
•
PW—A pseudowire is a bidirectional virtual connection between VSIs. A PW consists of two
unidirectional MPLS LSPs in opposite directions. A PW is also referred as a virtual circuit (VC).
•
Service instance—A service instance is created on a port to identify and process specific
packets passing through the port. A PE uses service instances to match traffic received from a
CE, so as to forward traffic with different characteristics over different PWs. A service instance
supports multiple packet matching rules.
•
AC—An attachment circuit connects a CE to a PE. It can use physical interfaces or virtual
interfaces. Usually, all user packets on an AC, including Layer 2 and Layer 3 protocol messages,
must be forwarded to the peer site without being changed. In VPLS, a PE uses service
instances to differentiate different VPN traffic transmitted on the AC. Therefore, an AC on a port
corresponds to all service instances on the port.
•
QinQ—802.1Q in 802.1Q. It is a tunneling protocol based on 802.1Q. It offers a
point-to-multipoint L2VPN service mechanism. With QinQ, the private network VLAN tags of
packets are encapsulated into the public network VLAN tags, allowing packets to be transmitted
with two layers of tags across the service provider network. This provides a simpler Layer 2
VPN tunneling service.
168
•
Forwarders—A forwarder functions as the VPLS forwarding table. Once a PE receives a
packet from an AC, the forwarder selects a PW for forwarding the packet.
•
Tunnel—A tunnel, usually an MPLS tunnel, is a direct channel between a local PE and the peer
PE for transparent data transmission in-between. It is used to carry PWs. A tunnel can carry
multiple PWs.
•
Encapsulation—Packets transmitted over a PW use the standard PW encapsulation formats
and technologies: Ethernet and VLAN.
•
PW signaling—The PW signaling protocol is the fundament of VPLS. It is used for creating and
maintaining PWs and automatically discovering VSI peer PEs. Two PW signaling protocols are
available: LDP and BGP.
Figure 39 VPLS network diagram
Site 1
Tunnel
VPN 1
PW
AC
CE 1
Site 2
MPLS backbone
Forwarder
VPN 2
CE 2
P
CE 3
VPN 1
PE 1
CE 4
PE 2
PWSignaling
VPN 2
Site 3
PW establishment
VPLS uses PWs to transfer data over the public network. A PW is established based on an MPLS
tunnel (including LSP and CR-LSP) or a GRE tunnel.
To create a PW:
1.
Establish an MPLS tunnel or a GRE tunnel between the local and peer PEs.
2.
Identify the address of the peer PE. For PEs in the same VSI, you can manually specify the peer
PE address or you can use a signaling protocol (such as BGP) to automatically discover the
peer PE.
3.
On each PE, assign a multiplex distinguishing flag (VC label) for the PW and advertise the
assigned VC label to the peer PE to establish a unidirectional LSP. The two unidirectional LSPs
between the PEs form a bidirectional PW.
VPLS includes the following types:
•
Static VPLS—Uses manually configured VC labels for a PW.
•
LDP VPLS—Uses LDP to distribute VC labels for a PW. This mode is also referred to as Martini
mode.
•
BGP VPLS—Uses multiprotocol BGP to distribute VC labels for a PW. This mode is also
referred to as Kompella mode.
For more information about the Martini mode and Kompella mode, see "Configuring MPLS L2VPN."
169
MAC address learning and flooding
VPLS provides reachability by MAC address learning. Each PE maintains a MAC address table.
•
Source MAC address learning
MAC address learning includes the following parts:
{
Remote MAC address learning associated with PWs
A PW consists of two unidirectional VC LSPs. A PW is up only when both of the VC LSPs
are up. When the inbound VC LSP learns a new MAC address, the PW must map the MAC
address to the outbound VC LSP.
{
Local MAC address learning of interfaces directly connected to users
This refers to learning source MAC addresses from Layer 2 packets originated by CEs. This
occurs on the corresponding VSI interfaces.
Figure 40 shows the procedure of MAC address learning and flooding on PEs.
Figure 40 MAC learning and flooding on PEs
•
MAC address reclaim
Dynamic address learning must support refreshing and relearning. The VPLS draft defines a
dynamic address learning method that uses the address reclaim message, which carries MAC
TLV. Upon receiving such a message, a device removes MAC addresses or relearns them
according to the specified parameters in the TLV. If NULL is specified, the device removes all
MAC addresses of the VSI, except for those learned from the PW that received the address
reclaim message.
The address reclaim message is very useful when the network topology changes and you must
remove the learned MAC addresses quickly. There are two types of address reclaim messages:
those with MAC address lists and those without MAC address lists.
After a backup link becomes active and a message with the instruction of relearning MAC
entries arrives, a PE updates the corresponding MAC entries in the FIB table of the VPLS
instance and sends the message to other PEs that are directly connected through LDP
sessions. If the message contains a null MAC address TLV list, these PEs remove all MAC
addresses from the specified VSI, except for those learned from the PW that sent the message.
170
•
MAC address aging
Remote MAC addresses learned by a PE that are related to VC labels but no longer in use must
be aged out by an aging mechanism. The aging mechanism used here is the aging timer
corresponding to the MAC address. When receiving a packet whose source MAC address has
an aging timer started, the PE resets the aging timer.
VPLS loop avoidance
To avoid loops in a VPLS network, full mesh and split horizon forwarding are used instead of STP at
the private network side.
•
Full mesh—PEs are logically fully meshed (as are the PWs). Each PE must create for each
VPLS forwarding instance a tree to all other PEs of the instance.
•
Split horizon forwarding—Each PE must support horizontal split to avoid loops. A PE cannot
forward packets through PWs of the same VSI, because all PEs of a VSI are directly connected.
Packets from PWs on the public network side cannot be forwarded to other PWs. They can only
be forwarded to the private network side.
VPLS packet encapsulation
This section describes VPLS packet encapsulation.
Packet encapsulation on an AC
The packet encapsulation type of an AC depends on the user VSI access mode, which can be VLAN
or Ethernet.
•
VLAN access—The Ethernet header of a packet sent by a CE to a PE or sent by a PE to a CE
includes a VLAN tag that is added in the header as a service delimiter for the service provider
network to identify the user. The tag is called a "P-Tag."
•
Ethernet access—The Ethernet header of a packet upstream from the CE or downstream from
the PE does not contain any service delimiter. If a header contains a VLAN tag, it is the internal
VLAN tag of the user and means nothing to the PE. This kind of internal VLAN tag of the user is
called a "U-Tag."
You can specify the VSI access mode to be used.
Packet encapsulation on a PW
The packet encapsulation type of a PW, also called the "PW transport mode," can be either Ethernet
or VLAN.
•
In Ethernet mode, P-Tag is not transferred on the PW. For a packet from a CE, if it contains the
service delimiter, the PE removes the service delimiter and adds a PW label and a tunnel label
into the packet before forwarding the packet. Otherwise, the PE adds a PW label and a tunnel
label into the packet and then forwards the packet. For a packet to be sent downstream,
whether the PE adds the service delimiter into the packet depends on your configuration.
However, rewriting and removing the existing tags are not allowed.
•
In VLAN mode, packets transmitted over the PW must carry a P-Tag. For a packet from a CE, if
it contains the service delimiter, the PE keeps the P-Tag unchanged or changes the P-Tag to the
VLAN tag expected by the peer PE or to a null tag (the tag value is 0), and then adds a PW label
and a tunnel label into the packet before sending the packet out. If the packet contains no
service delimiter, the PE adds the VLAN tag expected by the peer PE or a null tag, and then a
PW label and a tunnel label into the packet before sending the packet out. For a packet to be
sent downstream, the PE rewrites, removes, or retains the service delimiter depending on your
configuration.
According to the protocol, the packet encapsulation type of a PW is VLAN by default.
171
H-VPLS implementation
Hierarchy of VPLS (H-VPLS) can extend the VPLS access range of a service provider and reduce
costs.
Advantages of H-VPLS access
•
H-VPLS has lower requirements on the multi-tenant unit switch (MTU-s). It has distinct
hierarchies which fulfill definite tasks.
•
H-VPLS reduces the logical complexity of the fully meshed network consisting of PEs and the
configuration complexity.
H-VPLS with LSP access
Figure 41 H-VPLS with LSP access
As shown in Figure 41, UPE functions as the MTU-s and establishes only a virtual link U-PW with
NPE 1. It does not establish virtual links with any other peers.
Data forwarding in H-VPLS with LSP access is as follows:
1.
Upon receiving a packet from a CE, UPE tags the packet with the MPLS label for the U-PW,
namely, "the multiplex distinguishing flag," and then sends the packet to NPE 1.
2.
When receiving the packet, NPE 1 determines which VSI the packet belongs to by the label and,
based on the destination MAC address of the packet, tags the packet with the multiplex
distinguishing flag for the N-PW, and forwards the packet.
3.
Upon receiving the packet from the N-PW, NPE 1 tags the packet with the multiplex
distinguishing flag for the U-PW and sends the packet to UPE, which forwards the packet to the
CE.
For packets to be exchanged between CE 1 and CE 2, UPE can forward them directly without NPE 1
because it holds the bridging function by itself. For the first packet with an unknown destination MAC
address or a broadcast packet, UPE broadcasts the packet to CE 2 through the bridging function and,
at the same time, forwards it through U-PW to NPE 1, which replicates the packet and sends a copy
to each peer CE.
172
H-VPLS with QinQ access
Figure 42 H-VPLS with QinQ access
As shown in Figure 42, MTU is a standard bridging device and QinQ is enabled on its interfaces
connected to CEs.
Data forwarding in H-VPLS with QinQ access is as follows:
1.
Upon receiving a packet from a CE, MTU labels the packet with a VLAN tag as the multiplex
distinguishing flag, and transparently sends the packet to PE 1 through the QinQ tunnel.
2.
When receiving the packet, PE 1 determines which VSI the packet belongs to by the VLAN tag
and, based on the destination MAC address of the packet, tags the packet with the multiplex
distinguishing flag (MPLS label) for the PW. Then, it forwards the packet.
3.
Upon receiving the packet from the PW, PE 1 determines to which VSI the packet belongs by
the multiplex distinguishing flag (MPLS label) and, based on the destination MAC address of
the packet, labels the packet with the VLAN tag. Then, it forwards the packet through the QinQ
tunnel to MTU, which in turn forwards the packet to the CE.
For packets to be exchanged between CE 1 and CE 2, MTU can forward them directly without PE 1
because it holds the bridging function by itself. For the first data packet with an unknown destination
MAC address or a broadcast packet, MTU broadcasts the packet to CE 2 through the bridging
function and, at the same time, forwards it through the QinQ tunnel to PE 1, which replicates the
packet and sends a copy to each peer CE.
PW redundancy
The network design with a single PW between a UPE and an NPE has a distinct drawback: once the
PW experiences a failure, all VPNs connected to the aggregate device lose connectivity. The
H-VPLS with LSP access provides redundant links for PW backup. Typically, the primary PW link is
used. When the primary link fails, the backup link takes over the VPN services.
Figure 43 PW redundancy for H-VPLS with LSP access
CE 1
NPE 1
N-PW
NPE 3
U-PW
UPE
CE 3
N-PW
CE 2
N-PW
U-PW
(Backup link)
NPE 2
The H-VPLS with LSP access activates the backup link when:
•
The tunnel over which the primary PW is established is deleted, causing the PW to go down.
173
•
BFD detects a primary link failure.
•
The LDP session between the peers of the primary PW goes down, and the PW is deleted as a
result.
Hub-spoke VPLS implementation
In hub-spoke networking, one of the VPLS networking modes, there is one hub site and multiple
spoke sites. The spoke sites (the spoke-CEs) are not permitted to communicate with each other
directly. Data transmission between them depends on the hub site (the hub-CE). The PE connecting
the hub site is called the "hub-PE." PEs connecting the spoke sites are called "spoke-PEs."
In hub-spoke networking, all traffic between spoke sites must go through the hub site, facilitating
centralized management of traffic.
Figure 44 Hub-spoke networking
Figure 44 shows a typical hub-spoke networking application. As the MAC address learning in a
hub-spoke network is the same as that in a common network, the following describes only the data
forwarding procedure:
1.
Upon receiving a packet from Spoke-CE 1, Spoke-PE 1 inserts an MPLS label into the packet
according to the VSI to which Spoke-CE 1 belongs and then forwards the packet to Hub-PE.
2.
Receiving the packet from the PW, Hub-PE determines by the MPLS label the VSI that the
packet is for and forwards the packet to Hub-CE directly.
3.
Hub-CE has Layer 2 forwarding function. It processes the packet and then forwards the packet
back to Hub-PE.
4.
Receiving the packet from the AC, Hub-PE determines by the VLAN tag the VSI that the packet
is for, inserts an MPLS label to which the PW corresponds based on the destination MAC
address, and forwards the packet to Spoke-PE 2.
5.
When Spoke-PE 2 receives the packet from the PW, it determines by the MPLS label the VSI
that the packet is for, and then forwards the packet to Spoke-CE 2.
VPLS configuration task list
174
Task
Remarks
Enabling L2VPN and MPLS L2VPN
Required.
Configuring static VPLS
Configure one type of VPLS as
needed.
Configuring LDP VPLS
Configuring BGP VPLS
Binding a service instance to a VPLS instance
Required.
Configuring traffic policing for VPLS
Optional.
Enabling VPLS statistics
Optional.
Configuring MAC address learning
Optional.
Configuring VPLS instance attributes
Optional.
Inspecting PWs
Optional.
Enabling L2VPN and MPLS L2VPN
Enable L2VPN and MPLS L2VPN before you perform VPLS-related configurations.
To enable L2VPN and MPLS L2VPN:
Step
Command
1.
Enter system view.
system-view
2.
Enable L2VPN and enter L2VPN view.
l2vpn
3.
Enable MPLS L2VPN.
mpls l2vpn
For more information about the l2vpn command and the mpls l2vpn command, see MPLS
Command Reference.
Configuring static VPLS
Before you configure static VPLS, complete the following tasks:
•
Configure an IGP on the MPLS backbone devices (PEs and P devices) to ensure IP
connectivity. For configuration information, see Layer 3—IP Routing Configuration Guide.
•
Configure basic MPLS on the MPLS backbone devices (PEs and P devices) to establish LSP
tunnels over the backbone network. For configuration information, see "Configuring basic
MPLS."
Configuring a static VPLS instance
To create a static VPLS instance, perform the following configurations:
1.
Specify a globally unique name for the VPLS instance and set the peer discovery mechanism to
manual configuration.
2.
Specify the PW signaling protocol as static.
3.
Use the peer command to configure a VPLS peer PE for the instance, including the following
parameters:
{
IP address of the peer PE.
175
{
{
ID of the PW to the peer PE, which must be consistent with that specified on the peer PE.
Type of the peer PE. Use the upe keyword to specify a UPE peer, which is an MTU-s device
in the H-VPLS model, or use the backup-peer keyword to configure two NPE peers (one
primary, one backup).
You can configure only one pair of primary and backup NPEs. The remote NPEs must be
fully meshed, but it is not necessary for the UPE to connect to all the NPEs.
{
4.
PW class template to be referenced. A PW class template defines the PW transport mode
and tunneling policy for the PW.
Specify the local and remote VC labels.
To configure a static VPLS instance:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Create a PW class template
and enter its view.
pw-class pw-class-name
3.
Configure the PW transport
mode.
trans-mode { ethernet | vlan }
Optional.
By default, no PW class template
is created.
Optional.
VLAN by default.
Optional.
4.
Specify a tunneling policy.
pw-tunnel-policy policy-name
By default, the tunneling policy
specified through the tnl-policy
command in VSI view is used.
For information about how to
configure a tunneling policy, see
"Configuring MPLS L3VPN."
5.
Return to system view.
quit
N/A
6.
Create a static VPLS
instance and enter VSI view.
vsi vsi-name static [ hub-spoke ]
By default, no VPLS instance
exists on the device.
7.
Specify the PW signaling
protocol as static and enter
VSI-static view.
pwsignal static
N/A
8.
Create a peer PE for the
VPLS instance and enter
L2VPN peer view.
peer ip-address [ { hub | spoke } |
pw-class class-name | [ pw-id
pw-id ] [ upe | backup-peer
ip-address [ backup-pw-id
pw-id ] ] ] *
If you do not specify the VPLS
instance ID by using the vsi-id
command, you must specify the
PW ID by using the pw-id
keyword in this command.
9.
Configure VC labels for the
primary VC.
static label local local-vc remote
remote-vc
By default, no VC labels are
configured for the primary VC.
Optional.
10. Configure VC labels for the
backup VC.
static backup-label local
local-vc remote remote-vc
11. Return to VSI-static view.
quit
N/A
12. Enable the PW switchback
function
and
set
the
switchover delay time.
dual-npe revertive [ wtr-time
wtr-time ]
Optional.
Configuring LDP VPLS
Before you configure LDP VPLS, complete the following tasks:
176
By default, no VC labels are
configured for the backup VC.
Disabled by default.
•
Configure an IGP on the MPLS backbone devices (PEs and P devices) to ensure IP
connectivity. For configuration information, see Layer 3—IP Routing Configuration Guide.
•
Configure basic MPLS on the MPLS backbone devices (PEs and P devices) to establish LSP
tunnels over the backbone network. For configuration information, see "Configuring basic
MPLS."
•
Configure LDP remote peers on PEs to establish remote LDP sessions. For configuration
information, see "Configuring basic MPLS."
Configuring an LDP VPLS instance
When creating an LDP VPLS instance, perform the following configurations:
1.
Specify a globally unique name for the VPLS instance and set the peer discovery mechanism to
manual configuration.
2.
Configure LDP as the PW signaling protocol.
3.
Specify the ID of the VPLS instance.
4.
Use the peer command to configure a VPLS peer PE for the instance, including the following
parameters:
{
IP address of the peer PE.
{
ID of the PW to the peer PE, which must be consistent with that specified on the peer PE.
{
Type of the peer PE. Use the upe keyword to specify a UPE peer, which is an MTU-s device
in the H-VPLS model; or use the backup-peer keyword to configure two NPE peers (one
primary one backup).
You can configure only one pair of primary and backup NPEs. The remote NPEs must be
fully meshed, but it is not necessary for the UPE to connect to all NPEs.
{
PW class to be referenced. A PW class defines the PW transport mode and tunneling policy
for the PW.
To configure an LDP VPLS instance:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Create a PW class and enter
its view.
pw-class pw-class-name
3.
Configure the PW transport
mode.
trans-mode { ethernet | vlan }
Optional.
By default, no PW class is
created.
Optional.
VLAN by default.
Optional.
4.
Specify a tunneling policy.
pw-tunnel-policy policy-name
By default, the tunneling policy
specified through the tnl-policy
command in VSI view is used.
For information about how to
configure a tunneling policy, see
"Configuring MPLS L3VPN."
5.
Return to system view.
quit
N/A
6.
Create an LDP VPLS
instance and enter VSI view.
vsi vsi-name static [ hub-spoke ]
N/A
7.
Specify LDP as the PW
signaling protocol and enter
VSI LDP view.
pwsignal ldp
N/A
177
Step
Command
Remarks
8.
Specify an ID for the VPLS
instance.
vsi-id vsi-id
N/A
9.
Create a peer PE for the
VPLS instance and enter
L2VPN peer view.
peer ip-address [ { hub | spoke } |
pw-class class-name | [ pw-id
pw-id ] [ upe | backup-peer
ip-address [ backup-pw-id
pw-id ] ] ] *
N/A
10. Return to VSI LDP view.
quit
N/A
11. Enable the PW switchover
function
and
set
the
switchover delay time.
dual-npe revertive [ wtr-time
wtr-time ]
Optional.
By default, PW switchover is
disabled.
Configuring BGP VPLS
Before you configure BGP VPLS, complete the following tasks:
•
Configure an IGP on the MPLS backbone devices (PEs and P devices) to guarantee the IP
connectivity of the MPLS backbone. For configuration information, see Layer 3—IP Routing
Configuration Guide.
•
Configure basic MPLS on the MPLS backbone devices (PEs and P devices) to establish LSP
tunnels on the backbone network. For configuration information, see "Configuring basic MPLS."
Configuring the BGP extension
Before configuring BGP VPLS, configure BGP parameters on the PEs. For configuration details, see
Layer 3—IP Routing Configuration Guide.
To configure BGP extension:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter BGP-VPLS address
family view.
vpls-family
For more configurations in
BGP-VPLS address family view,
see "Configuring MPLS L3VPN."
4.
Activate a peer.
peer peer-address enable
By default, no peer is activated.
Configuring a BGP VPLS instance
To create a BGP VPLS instance, specify a globally unique name for the VPLS instance, set the peer
discovery mechanism to automatic configuration, and configure BGP as the PW signaling protocol.
To configure a BGP VPLS instance:
Step
Command
1.
Enter system view.
system-view
2.
Create a BGP VPLS instance and enter VSI
view.
vsi vsi-name auto
178
Step
Command
3.
Specify BGP as the PW signaling protocol and
enter VSI-BGP view.
pwsignal bgp
4.
Configure an RD for the VPLS instance.
route-distinguisher route-distinguisher
5.
Configure VPN targets for the VPLS instance.
vpn-target vpn-target&<1-16> [ both |
import-extcommunity | export-extcommunity ]
6.
Create a site for the VPLS instance.
site site-id [ range site-range ] [ default-offset { 0 |
1}]
Resetting VPLS BGP connections
When the BGP routing policy or protocol is changed, reset BGP connections in a VPLS to make the
new configurations take effect to the VPLS connections.
To reset VPLS BGP connections, perform the following task in user view:
Task
Command
Reset a specific VPLS BGP connection or all VPLS
BGP connections.
reset bgp vpls { as-number | ip-address | all |
external | internal }
Binding a service instance to a VPLS instance
To bind a service instance to a VPLS instance, create the service instance on a Layer 2 Ethernet
interface or Layer 2 aggregate interface, configure a packet matching rule for the service instance,
and then bind the service instance to the VPLS instance. After these configurations, packets that
arrive at the interface and match the packet matching rule are forwarded by the bound VPLS
instance.
A service instance supports multiple types of packet matching rules (such as matching all packets
received on the port, packets carrying the specified VLAN tags, all tagged packets, and all packets
with no VLAN tags), providing a more flexible VPLS instance access control. Use this method when
users connected to a VLAN interface belong to different VPNs.
You can further specify the access mode as hub or spoke only when the VPLS instance is enabled
with the hub-spoke capability (the hub-spoke keyword included in the vsi static command. The
default is spoke.
To bind a service instance to a VPLS instance:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
•
2.
3.
Enter the view of the Layer 2
Ethernet interface or Layer 2
aggregate
interface
connected to a CE.
Create a service instance
and enter its view.
•
Enter Layer 2 Ethernet interface
view:
interface interface-type
interface-number
Enter Layer 2 aggregate interface
view:
interface bridge-aggregation
interface-number
service-instance service-instance-id
179
N/A
By default, no service
instance is created.
Step
Command
Remarks
4.
Configure a packet matching
rule for the service instance.
encapsulation { s-vid vlan-id
[ only-tagged ] | port-based | tagged |
untagged }
By default, no packet
matching rule is configured
for a service instance.
5.
Associate
the
service
instance with a VPLS
instance.
xconnect vsi vsi-name [ access-mode
{ ethernet | vlan } | { hub | spoke } ] *
By default, a service
instance is not associated
with any VPLS instance.
Configuring traffic policing for VPLS
Traffic policing controls packet transmission to avoid network congestion. Before you configure traffic
policing for VPLS, use the qos car command in system view to configure a global CAR action. For
more information about traffic policing and CAR, see ACL and QoS Configuration Guide.
Configuring traffic policing for a PW
Only static VPLS and LDP VPLS support traffic policing.
A global CAR action limits the traffic transmit rate to avoid network congestions. After you apply a
global CAR action in L2VPN peer view, the device polices traffic transmitted on the PW to the
specified peer PE according to the applied global CAR action.
To configure traffic policing for a PW:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VSI view.
vsi vsi-name
N/A
3.
Enter VSI-LDP view.
pwsignal ldp
N/A
4.
Enter L2VPN peer view.
peer ip-address
N/A
5.
Apply a global CAR action to
the inbound traffic of the PW.
qos car inbound name
car-name
By default, no global CAR is
applied to a PW.
Configuring traffic policing for an AC
After you bind a VPLS instance to a service instance, you can perform this configuration task to apply
a global CAR action to the service instance for traffic policing on the AC.
After you apply a global CAR action to a service instance, the device polices inbound traffic matching
the service instance according to the applied global CAR action.
To configure traffic policing for an AC:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
180
Step
Command
•
Remarks
Enter the view of the Layer 2
Ethernet interface or Layer 2
aggregate interface connected to
the CE.
•
Enter Layer 2 Ethernet
interface view:
interface interface-type
interface-number
Enter Layer 2 aggregate
interface view:
interface
bridge-aggregation
interface-number
N/A
3.
Enter service instance view.
service-instance instance-id
N/A
4.
Apply a global CAR action to the
inbound traffic on the AC.
car inbound name car-name
By default, no global CAR is
applied to an AC.
2.
Enabling VPLS statistics
Enabling traffic statistics for a PW
Only LDP VPLS supports the VPLS statistics function.
After you enable VPLS statistics in L2VPN peer view, the device collects statistics for traffic on the
PW to the specified peer PE. If you also set the statistics reading interval by using the statistics
interval command, you can use the display mpls statistics pw command to display statistics. For
more information about the statistics interval command, see MPLS Command Reference.
To enable traffic statistics for a PW:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VSI view.
vsi vsi-name
N/A
3.
Enter VSI-LDP view.
pwsignal ldp
N/A
4.
Enter L2VPN peer view.
peer ip-address
N/A
5.
Enable traffic statistics for the PW to the
specified peer.
statistics enable
Disabled by default.
Enabling traffic statistics for an AC
After you bind a service instance to a VPLS instance, you can perform this configuration task to
enable inbound or outbound traffic statistics for the AC.
You can use the display mpls l2vpn fib ac vpls command to display AC traffic statistics.
To configure traffic statistics for an AC by using a service instance:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
181
Step
Command
•
2.
Enter the view of the Layer 2
Ethernet interface or Layer 2
aggregate interface connected
to the CE.
•
Remarks
Enter Layer 2 Ethernet interface
view:
interface interface-type
interface-number
Enter Layer 2 aggregate interface
view:
interface bridge-aggregation
interface-number
N/A
3.
Enter service instance view.
service-instance instance-id
N/A
4.
Enable inbound or outbound
traffic statistics for the AC.
statistics { inbound | outbound }
By default, traffic statistics
for an AC is disabled.
Configuring MAC address learning
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VSI view.
vsi vsi-name
N/A
3.
Enable or disable MAC
address learning for the
VPLS instance.
mac-learning { enable | disable }
Set the maximum number of
MAC addresses that the
device can learn for the
VPLS instance.
mac-table limit
mac-limit-number
Enable the MAC address
move function, so when the
incoming
interfaces
of
packets change, the device
changes the interfaces in the
corresponding MAC address
entries accordingly.
mac-move enable
4.
5.
Optional.
Enabled by default.
Optional.
32768 by default.
Optional.
Enabled by default.
Configuring VPLS instance attributes
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VSI view.
vsi vsi-name
N/A
3.
Specify the encapsulation
type of the VPLS instance.
Optional.
encapsulation { bgp-vpls |
ethernet | vlan }
182
vlan by default, which
corresponds to the VSI PW
encapsulation type of tagged.
Step
Command
Remarks
Optional.
The default MTU is 1500 bytes.
4.
Set the MTU of the VPLS
instance.
mtu mtu
5.
Configure the description of
the VPLS instance.
description text
6.
Shut down the VPLS service
of the VPLS instance.
shutdown
The MTU configured for a VPLS
instance applies only to link
negotiation messages. It is not
used for data packets.
Optional.
By default, no description is
configured.
Optional.
By default, the VPLS service of a
VPLS instance is enabled.
Optional.
7.
Specify a tunneling policy for
the VPLS instance.
tnl-policy tunnel-policy-name
By default, no tunneling policy is
specified for a VPLS instance
and a VPLS instance uses the
default tunneling policy. The
default tunneling policy selects
only one tunnel in this order: LSP
tunnel, CR-LSP tunnel.
For information about how to
configure a tunneling policy, see
"Configuring MPLS L3VPN."
Inspecting PWs
On a VPLS network, you can use the MPLS LSP ping function to test PW connectivity and get
necessary information for troubleshooting PW failures.
On the local PE, the MPLS LSP ping function adds the label of the PW to be tested into MPLS Echo
Request messages so that the messages travel along the PW. The local PE determines whether the
PW is valid and reachable according to the replies received from the peer PE.
To test the connectivity of a PW:
Task
Command
Use MPLS LSP ping to test the
connectivity of a PW.
ping lsp [ -a source-ip | -c count |
-exp exp-value | -h ttl-value | -m
wait-time | -r reply-mode | -s
packet-size | -t time-out | -v ] * pw
ip-address pw-id pw-id
Displaying and maintaining VPLS
183
Remarks
Available in any view.
MPLS LSP ping can be used to
inspect only an LDP PW.
Task
Command
Remarks
Display VPLS information in the
BGP routing table.
display bgp vpls { all | group
[ group-name ] | peer [ [ ip-address ]
verbose ] | route-distinguisher
route-distinguisher [ site-id site-id
[ label-offset label-offset ] ] } [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display MAC address table
information for one or all VPLS
instances.
display mac-address vsi [ vsi-name ]
[ blackhole | dynamic | static ] [ count ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about VPLS
connections.
display vpls connection [ bgp | ldp | static
| vsi vsi-name ] [ block | down | up ]
[ verbose ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display AC entry information for
one or all VPLS instances.
display mpls l2vpn fib ac vpls [ vsi
vsi-name | interface interface-type
interface-number [ service-instance
service-instanceid ] ] [ slot slot-number ]
[ verbose ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display PW entry information for
one or all VPLS instances.
display mpls l2vpn fib pw vpls [ vsi
vsi-name [ link link-id ] ] [ slot slot-number ]
[ verbose ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display information about service
instances on a specific interface.
display service-instance interface
interface-type interface-number
[ service-instance instance-id ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display the PW statistics of one or
all VPLS instances.
display mpls statistics pw [ vsi vsi-name
[ link link-id ] ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about one or
all VPLS instances.
display vsi [ vsi-name ] [ verbose ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about remote
VPLS connections.
display vsi remote { bgp | ldp } [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about one or
all PW classes.
display pw-class [ pw-class-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Clear the MAC address table of
one or all VPLS instances.
reset mac-address vsi [ vsi-name ]
Available in user view.
Clear PW statistics for one or all
VPLS instances.
reset mpls statistics pw [ vsi vsi-name
[ link link-id ] ]
Available in user view.
Clear AC statistics for VPLS
instances.
reset service-instance statistics
[ interface interface-type interface-number
[ service-instance instance-id [ inbound |
outbound ] ] ]
Available in user view.
VPLS configuration examples
The following sections provide VPLS configuration examples.
184
Binding service instances to VPLS instances
Network requirements
CE 1 and CE 2 are connected to PE 1 and PE 2 through VLANs.
On PE 1 and PE 2, perform the following configuration:
•
Configure VPLS instance aaa to use LDP (Martini mode) and VPLS instance bbb to use BGP
(Kompella mode), and configure the AS number as 100.
•
Configure service instance 1000 to match packets that are received on GigabitEthernet 1/0/1
and carry the VLAN tag of 100. Bind service instance 1000 to VPLS instance aaa.
•
Configure service instance 2000 to match packets that are received on GigabitEthernet 1/0/1
and carry VLAN tag of 200. Bind service instance 2000 to VPLS instance bbb.
Figure 45 Network diagram
Loop 0
1.1 .1. 9/ 24
Loop 0
2.2 .2. 9/ 24
Vlan-int 2
23. 1.1 .1/ 24
GE1/0/1
Vlan -int 2
23 .1 .1. 2/ 24
PE 1
Loop
3 .3. 3. 9/ 24
Vlan-int 3
26. 2.2 .2/ 24
Vlan -int 3
26. 2. 2. 1/24
P
PE 2
GE1/0/1
CE 1
CE 2
Configuration procedure
1.
Configure PE 1:
<Sysname> system-view
[Sysname] sysname PE1
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 1.1.1.9 32
[PE1-LoopBack0] quit
# Configure the LSR ID and enable MPLS globally.
[PE1] mpls lsr-id 1.1.1.9
[PE1] mpls
[PE1-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE1] l2vpn
[PE1-l2vpn] mpls l2vpn
[PE1-l2vpn] quit
# Enable LDP globally.
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure PE 1 to establish an LDP remote session with PE 2.
[PE1] mpls ldp remote-peer 1
[PE1-mpls-ldp-remote-1] remote-ip 3.3.3.9
[PE1-mpls-ldp-remote-1] quit
# Configure the interface connected to the P device and enable LDP on the interface.
185
[PE1] interface vlan-interface 2
[PE1-Vlan-interface2] ip address 23.1.1.1 24
[PE1-Vlan-interface2] mpls
[PE1-Vlan-interface2] mpls ldp
[PE1-Vlan-interface2] quit
# Configure OSPF.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 23.1.1.1 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 BGP extensions.
[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] vpls-family
[PE1-bgp-af-vpls] peer 3.3.3.9 enable
[PE1-bgp-af-vpls] quit
[PE1-bgp] quit
# Configure the basic attributes of VPLS instance aaa, which uses LDP.
[PE1] vsi aaa static
[PE1-vsi-aaa] pwsignal ldp
[PE1-vsi-aaa-ldp] vsi-id 500
[PE1-vsi-aaa-ldp] peer 3.3.3.9
[PE1-vsi-aaa-ldp] quit
[PE1-vsi-aaa] quit
# Configure the basic attributes of VPLS instance bbb, which uses BGP.
[PE1] vsi bbb auto
[PE1-vsi-bbb] pwsignal bgp
[PE1-vsi-bbb-bgp] route-distinguisher 100:1
[PE1-vsi-bbb-bgp] vpn-target 111:1
[PE1-vsi-bbb-bgp] site 1
[PE1-vsi-bbb-bgp] quit
[PE1-vsi-bbb] quit
# On the interface connecting CE 1, create service instance 1000 and bind it to VPLS instance
aaa, and create service instance 2000 and bind it to VPLS instance bbb.
[PE1] interface gigabitethernet 1/0/1
[PE1-GigabitEthernet1/0/1] service-instance 1000
[PE1-GigabitEthernet1/0/1-srv1000] encapsulation s-vid 100
[PE1-GigabitEthernet1/0/1-srv1000] xconnect vsi aaa
[PE1-GigabitEthernet1/0/1-srv1000] quit
[PE1-GigabitEthernet1/0/1] service-instance 2000
[PE1-GigabitEthernet1/0/1-srv2000] encapsulation s-vid 200
[PE1-GigabitEthernet1/0/1-srv2000] xconnect vsi bbb
[PE1-GigabitEthernet1/0/1-srv2000] quit
[PE1-GigabitEthernet1/0/1] quit
2.
Configure the P device:
186
<Sysname> system-view
[Sysname] sysname P
[P] interface loopback 0
[P-LoopBack0] ip address 2.2.2.9 32
[P-LoopBack0] quit
# Configure the LSR ID and enable MPLS globally.
[P] mpls lsr-id 2.2.2.9
[P] mpls
[P-mpls] quit
# Enable LDP globally.
[P] mpls ldp
[P-mpls-ldp] quit
# Configure the interface connected to PE 1 and enable LDP on the interface.
[P] interface vlan-interface 2
[P-Vlan-interface2] ip address 23.1.1.2 24
[P-Vlan-interface2] mpls
[P-Vlan-interface2] mpls ldp
[P-Vlan-interface2] quit
# Configure the interface connected to PE 2 and enable LDP on the interface.
[P] interface vlan-interface 3
[P-Vlan-interface3] ip address 26.2.2.2 24
[P-Vlan-interface3] mpls
[P-Vlan-interface3] mpls ldp
[P-Vlan-interface3] quit
# Configure OSPF.
[P] ospf
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 23.1.1.2 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 26.2.2.2 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
3.
Configure PE 2:
<Sysname> system-view
[Sysname] sysname PE2
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 3.3.3.9 32
[PE2-LoopBack0] quit
# Configure the LSR-ID and enable MPLS globally.
[PE2] mpls lsr-id 3.3.3.9
[PE2] mpls
[PE2-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE2] l2vpn
[PE2-l2vpn] mpls l2vpn
[PE2-l2vpn] quit
# Enable LDP globally.
[PE2] mpls ldp
187
[PE2-mpls-ldp] quit
# Configure PE 2 to establish a remote LDP peer PE 1.
[PE2] mpls ldp remote-peer 2
[PE2-mpls-ldp-remote-2] remote-ip 1.1.1.9
[PE2-mpls-ldp-remote-2] quit
# Configure the interface connected to the P device and enable LDP on the interface.
[PE2] interface vlan-interface 3
[PE2-Vlan-interface3] ip address 26.2.2.1 24
[PE2-Vlan-interface3] mpls
[PE2-Vlan-interface3] mpls ldp
[PE2-Vlan-interface3] quit
# Configure OSPF.
[PE2] ospf
[PE2-ospf-1] area 0
[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] network 26.2.2.0 0.0.0.255
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
# Configure BGP extensions.
[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] vpls-family
[PE2-bgp-af-vpls] peer 1.1.1.9 enable
[PE2-bgp-af-vpls] quit
[PE2-bgp] quit
# Configure VPLS instance aaa that uses LDP signaling.
[PE2] vsi aaa static
[PE2-vsi-aaa] pwsignal ldp
[PE2-vsi-aaa-ldp] vsi-id 500
[PE2-vsi-aaa-ldp] peer 1.1.1.9
[PE2-vsi-aaa-ldp] quit
[PE2-vsi-aaa] quit
# Configure VPLS instance bbb that uses BGP signaling.
[PE2] vsi bbb auto
[PE2-vsi-bbb] pwsignal bgp
[PE2-vsi-bbb-bgp] route-distinguisher 100:1
[PE2-vsi-bbb-bgp] vpn-target 111:1
[PE2-vsi-bbb-bgp] site 2
[PE2-vsi-bbb-bgp] quit
[PE2-vsi-bbb] quit
# On the interface connecting CE 2, create service instance 1000 and bind it to VPLS instance
aaa, and create service instance 2000 and bind it to VPLS instance bbb.
[PE2] interface gigabitethernet 1/0/1
[PE2-GigabitEthernet1/0/1] service-instance 1000
[PE2-GigabitEthernet1/0/1-srv1000] encapsulation s-vid 100
[PE2-GigabitEthernet1/0/1-srv1000] xconnect vsi aaa
[PE2-GigabitEthernet1/0/1-srv1000] quit
188
[PE2-GigabitEthernet1/0/1] service-instance 2000
[PE2-GigabitEthernet1/0/1-srv2000] encapsulation s-vid 200
[PE2-GigabitEthernet1/0/1-srv2000] xconnect vsi bbb
[PE2-GigabitEthernet1/0/1-srv2000] quit
[PE2-GigabitEthernet1/0/1] quit
4.
Verify the configuration:
# Execute the display vpls connection command on the PEs. The output shows that a PW
connection in up state has been established. Take PE 2 as an example:
[PE2] display vpls connection vsi aaa verbose
VSI Name: aaa
Signaling: ldp
**Remote Vsi ID
: 500
VC State
: up
Encapsulation
: vlan
Group ID
: 0
Remote MTU
: 1500
Peer Ip Address : 1.1.1.9
PW Type
: label
Local VC Label
: 89766
Remote VC Label : 81922
Link ID
: 1
Tunnel Policy
: --
Tunnel ID
: 0x4600068
Configuring hub-spoke VPLS
Network requirements
Create a PW between Spoke-PE 1 and Hub-PE and another PW between Spoke-PE 2 and Hub-PE.
Create VPLS instance aaa and configure it to support hub-spoke networking.
Configure service instance 1000 to match packets that are received on GigabitEthernet 1/0/1 and
carry the VLAN tag of 100. Bind service instance 1000 to VPLS instance aaa.
Figure 46 Network diagram
Hub-CE
Vlan-int100
Hub-PE
Vlan-int20
20.1.1.1/24
Vlan-int10
10.1.1.2/24
Vlan-int10
10.1.1.1/24
Loop0
3.3.3.9/32
Vlan-int20
20.1.1.2/24
Spoke-PE 1
Spoke-PE 2
Vlan-int100
Vlan-int100
Loop0
1.1.1.9/32
Loop0
2.2.2.9/32
Spoke-CE 1
Spoke-CE 2
189
Configuration procedure
1.
Configure an IGP (such as OSPF) on the MPLS backbone. (Details not shown.)
2.
Configure Spoke-PE 1:
# Configure basic MPLS.
<Sysname> system-view
[Sysname] sysname Spoke-PE1
[Spoke-PE1] interface loopback 0
[Spoke-PE1-LoopBack0] ip address 1.1.1.9 32
[Spoke-PE1-LoopBack0] quit
[Spoke-PE1] mpls lsr-id 1.1.1.9
[Spoke-PE1] mpls
[Spoke-PE1–mpls] quit
[Spoke-PE1] mpls ldp
[Spoke-PE1-mpls-ldp] quit
# Configure basic MPLS on the interface connected to Hub-PE.
[Spoke-PE1] interface vlan-interface 10
[Spoke-PE1-Vlan-interface10] ip address 10.1.1.1 24
[Spoke-PE1-Vlan-interface10] mpls
[Spoke-PE1-Vlan-interface10] mpls ldp
[Spoke-PE1-Vlan-interface10] quit
# Configure the remote LDP peer Hub-PE.
[Spoke-PE1] mpls ldp remote-peer 1
[Spoke-PE1-mpls-remote-1] remote-ip 3.3.3.9
[Spoke-PE1-mpls-remote-1] quit
# Enable L2VPN and MPLS L2VPN.
[Spoke-PE1] l2vpn
[Spoke-PE1-l2vpn] mpls l2vpn
[Spoke-PE1-l2vpn] quit
# Configure LDP VPLS instance aaa that supports the hub-spoke model, and configure the
peer as the hub.
[Spoke-PE1] vsi aaa static hub-spoke
[Spoke-PE1-vsi-aaa] pwsignal ldp
[Spoke-PE1-vsi-aaa-ldp] vsi-id 500
[Spoke-PE1-vsi-aaa-ldp] peer 3.3.3.9 hub
[Spoke-PE1-vsi-aaa-ldp] quit
[Spoke-PE1-vsi-aaa] quit
# On interface GigabitEthernet 1/0/1, create service instance 1000 and bind it to VPLS instance
aaa, and specify the attached CE as a spoke-CE.
[Spoke-PE1] interface GigabitEthernet 1/0/1
[Spoke-PE1-GigabitEthernet1/0/1] service-instance 1000
[Spoke-PE1-GigabitEthernet1/0/1-srv1000] encapsulation s-vid 100
[Spoke-PE1-GigabitEthernet1/0/1-srv1000] xconnect vsi aaa spoke
[Spoke-PE1-GigabitEthernet1/0/1-srv1000] quit
3.
Configure Spoke-PE 2:
# Configure basic MPLS.
<Sysname> system-view
[Sysname] sysname Spoke-PE2
[Spoke-PE2] interface loopback 0
190
[Spoke-PE2-LoopBack0] ip address 2.2.2.9 32
[Spoke-PE2-LoopBack0] quit
[Spoke-PE2] mpls lsr-id 2.2.2.9
[Spoke-PE2] mpls
[Spoke-PE2–mpls] quit
[Spoke-PE2] mpls ldp
[Spoke-PE2–mpls-ldp] quit
# Configure basic MPLS on the interface connected to Hub-PE.
[Spoke-PE2] interface vlan-interface 20
[Spoke-PE2-Vlan-interface20] ip address 20.1.1.1 24
[Spoke-PE2-Vlan-interface20] mpls
[Spoke-PE2-Vlan-interface20] mpls ldp
[Spoke-PE2-Vlan-interface20] quit
# Configure the remote LDP peer Hub-PE.
[Spoke-PE2] mpls ldp remote-peer 2
[Spoke-PE2-mpls-remote-2] remote-ip 3.3.3.9
[Spoke-PE2-mpls-remote-2] quit
# Enable L2VPN and MPLS L2VPN.
[Spoke-PE2] l2vpn
[Spoke-PE2-l2vpn] mpls l2vpn
[Spoke-PE2-l2vpn] quit
# Configure the LDP VPLS instance aaa that supports the hub-spoke model, and configure the
peer as the hub.
[Spoke-PE2] vsi aaa static hub-spoke
[Spoke-PE2-vsi-aaa] pwsignal ldp
[Spoke-PE2-vsi-aaa-ldp] vsi-id 500
[Spoke-PE2-vsi-aaa-ldp] peer 3.3.3.9 hub
[Spoke-PE2-vsi-aaa-ldp] quit
[Spoke-PE2-vsi-aaa] quit
# On interface GigabitEthernet 1/0/1, create service instance 1000 and bind it to VPLS instance
aaa, and specify the attached CE as a spoke-CE.
[Spoke-PE2] interface GigabitEthernet 1/0/1
[Spoke-PE2-GigabitEthernet1/0/1] service-instance 1000
[Spoke-PE2-GigabitEthernet1/0/1-srv1000] encapsulation s-vid 100
[Spoke-PE2-GigabitEthernet1/0/1-srv1000] xconnect vsi aaa spoke
[Spoke-PE2-GigabitEthernet1/0/1-srv1000] quit
4.
Configure Hub-PE:
# Configure basic MPLS.
<Sysname> system-view
[Sysname] sysname Hub-PE
[Hub-PE] interface loopback 0
[Hub-PE-LoopBack0] ip address 3.3.3.9 32
[Hub-PE-LoopBack0] quit
[Hub-PE] mpls lsr-id 3.3.3.9
[Hub-PE] mpls
[Hub-PE–mpls] quit
[Hub-PE] mpls ldp
[Hub-PE–mpls-ldp] quit
191
# Configure basic MPLS on the interface connected to Spoke-PE 1.
[Hub-PE] interface vlan-interface 10
[Hub-PE-Vlan-interface10] ip address 10.1.1.2 24
[Hub-PE-Vlan-interface10] mpls
[Hub-PE-Vlan-interface10] mpls ldp
[Hub-PE-Vlan-interface10] quit
# Configure basic MPLS on the interface connected to Spoke-PE 2.
[Hub-PE] interface vlan-interface 20
[Hub-PE-Vlan-interface20] ip address 20.1.1.2 24
[Hub-PE-Vlan-interface20] mpls
[Hub-PE-Vlan-interface20] mpls ldp
[Hub-PE-Vlan-interface20] quit
# Configure the remote LDP sessions.
[Hub-PE] mpls ldp remote-peer 1
[Hub-PE-mpls-remote-1] remote-ip 1.1.1.9
[Hub-PE-mpls-remote-1] quit
[Hub-PE] mpls ldp remote-peer 2
[Hub-PE-mpls-remote-2] remote-ip 2.2.2.9
[Hub-PE-mpls-remote-2] quit
# Enable L2VPN and MPLS L2VPN.
[Hub-PE] l2vpn
[Hub-PE-l2vpn] mpls l2vpn
[Hub-PE-l2vpn] quit
# Configure the LDP VPLS instance aaa that supports the hub-spoke model, and configure the
peers as spokes.
[Hub-PE] vsi aaa static hub-spoke
[Hub-PE-vsi-aaa] pwsignal ldp
[Hub-PE-vsi-aaa-ldp] vsi-id 500
[Hub-PE-vsi-aaa-ldp] peer 1.1.1.9 spoke
[Hub-PE-vsi-aaa-ldp] peer 2.2.2.9 spoke
[Hub-PE-vsi-aaa-ldp] quit
[Hub-PE-vsi-aaa] quit
# On interface GigabitEthernet 1/0/1, create service instance 1000 and bind it to VPLS instance
aaa, and specify the attached CE as the hub-CE.
[Hub-PE] interface GigabitEthernet 1/0/1
[Hub-PE-GigabitEthernet1/0/1] service-instance 1000
[Hub-PE-GigabitEthernet1/0/1-srv1000] encapsulation s-vid 100
[Hub-PE-GigabitEthernet1/0/1-srv1000] xconnect vsi aaa hub
[Hub-PE-GigabitEthernet1/0/1-srv1000] quit
5.
Verify the configuration:
# Use the display vpls connection command on the PEs. The output shows that a PW
connection in up state has been established between the PEs.
Configuring PW redundancy for H-VPLS access
Network requirements
As shown in Figure 47, CE 1 and CE 2 are connected to UPE through VLANs.
UPE establishes a PW connection (U-PW) with NPE 1 and NPE 2, with the NPE 2 link as the backup.
192
Establish fully meshed PWs among NPE 1, NPE 2, and NPE 3.
Create a VPLS instance and configure it to support H-VPLS networking.
Figure 47 Network diagram
Loop0
2.2.2.2/32
NPE 1
Vlan-int12
12.1.1.2/24
CE 1
Vlan-int17
17.1.1.1/24
Vlan-int12
12.1.1.1/24
GE1/0/1
VLAN 11
Vlan-int15
15.1.1.1/24
Vlan-int15
15.1.1.2/24
Loop0
4.4.4.4/32
GE1/0/1
VLAN 10
UPE
GE1/0/2
VLAN 10
Vlan-int16
16.1.1.2/24
Vlan-int13
13.1.1.1/24
NPE 3
CE 3
Vlan-int17
17.1.1.2/24
Vlan-int16
16.1.1.1/24
Vlan-int13
13.1.1.2/24
CE 2
NPE 2
Loop0
3.3.3.3/32
Configuration procedure
1.
Configure the IGP protocol on the MPLS backbone. (Details not shown.)
2.
Configure UPE:
# Configure basic MPLS.
<Sysname> system-view
[Sysname] sysname UPE
[UPE] interface loopback 0
[UPE-LoopBack0] ip address 1.1.1.1 32
[UPE-LoopBack0] quit
[UPE] mpls lsr-id 1.1.1.1
[UPE] mpls
[UPE-mpls] quit
[UPE] mpls ldp
[UPE-mpls-ldp] quit
# Configure an IP address for the interface connected to NPE 1, and enable MPLS and MPLS
LDP.
[UPE] interface vlan-interface 12
[UPE-Vlan-interface12] ip address 12.1.1.1 24
[UPE-Vlan-interface12] mpls
[UPE-Vlan-interface12] mpls ldp
[UPE-Vlan-interface12] quit
# Configure an IP address for the interface connected to NPE 2, and enable MPLS and MPLS
LDP.
[UPE] interface vlan-interface 13
[UPE-Vlan-interface13] ip address 13.1.1.1 255.255.255.0
[UPE-Vlan-interface13] mpls
193
[UPE-Vlan-interface13] mpls ldp
[UPE-Vlan-interface13] quit
# Configure the remote LDP peer NPE 1.
[UPE] mpls ldp remote-peer 1
[UPE-mpls-remote-1] remote-ip 2.2.2.2
[UPE-mpls-remote-1] quit
# Configure the remote LDP peer NPE 2.
[UPE] mpls ldp remote-peer 2
[UPE-mpls-remote-1] remote-ip 3.3.3.3
[UPE-mpls-remote-1] quit
# Enable L2VPN and MPLS L2VPN.
[UPE] l2vpn
[UPE-l2vpn] mpls l2vpn
[UPE-l2vpn] quit
# Configure the basic attributes of VPLS instance aaa, which uses LDP.
[UPE] vsi aaa static
[UPE-vsi-aaa] pwsignal ldp
[UPE-vsi-aaa-ldp] vsi-id 500
[UPE-vsi-aaa-ldp] peer 2.2.2.2 backup-peer 3.3.3.3
[UPE-vsi-aaa-ldp] dual-npe revertive wtr-time 1
[UPE-vsi-aaa-ldp] quit
[UPE-vsi-aaa] quit
# On the interface connected to CE 1, create a service instance and bind the VSI.
[UPE] interface gigabitethernet 1/0/1
[UPE-GigabitEthernet1/0/1] service-instance 1000
[UPE-GigabitEthernet1/0/1-srv1000] encapsulation s-vid 10
[UPE-GigabitEthernet1/0/1-srv1000] xconnect vsi aaa
[UPE-GigabitEthernet1/0/1-srv1000] quit
# On the interface connected to CE 2, create a service instance and bind the VSI.
[UPE] interface gigabitethernet 1/0/2
[UPE-GigabitEthernet1/0/2] service-instance 1000
[UPE-GigabitEthernet1/0/2-srv1000] encapsulation s-vid 11
[UPE-GigabitEthernet1/0/2-srv1000] xconnect vsi aaa
[UPE-GigabitEthernet1/0/2-srv1000] quit
3.
Configure NPE 1:
# Configure basic MPLS.
<Sysname> system-view
[Sysname] sysname NPE1
[NPE1] interface loopback 0
[NPE1-LoopBack0] ip address 2.2.2.2 32
[NPE1-LoopBack0] quit
[NPE1] mpls lsr-id 2.2.2.2
[NPE1] mpls
[NPE1–mpls] quit
[NPE1] mpls ldp
[NPE1–mpls-ldp] quit
# Configure an IP address for the interface connected to UPE, and enable MPLS and MPLS
LDP.
194
[NPE1] interface vlan-interface 12
[NPE1-Vlan-interface12] ip address 12.1.1.2 24
[NPE1-Vlan-interface12] mpls
[NPE1-Vlan-interface12] mpls ldp
[NPE1-Vlan-interface12] quit
# Configure an IP address for the interface connected to NPE 2, and enable MPLS and MPLS
LDP.
[NPE1] interface vlan-interface 17
[NPE1-Vlan-interface17] ip address 17.1.1.1 24
[NPE1-Vlan-interface17] mpls
[NPE1-Vlan-interface17] mpls ldp
[NPE1-Vlan-interface17] quit
# Configure an IP address for the interface connected to NPE 3, and enable MPLS and MPLS
LDP.
[NPE1] interface vlan-interface 15
[NPE1-Vlan-interface15] ip address 15.1.1.1 24
[NPE1-Vlan-interface15] mpls
[NPE1-Vlan-interface15] mpls ldp
[NPE1-Vlan-interface15] quit
# Configure the remote LDP peer UPE.
[NPE1] mpls ldp remote-peer 2
[NPE1-mpls-remote-2] remote-ip 1.1.1.1
[NPE1-mpls-remote-2] quit
# Configure the remote LDP peer NPE 2.
[NPE1] mpls ldp remote-peer 3
[NPE1-mpls-remote-3] remote-ip 3.3.3.3
[NPE1-mpls-remote-3] quit
# Configure the remote LDP peer NPE 3.
[NPE1] mpls ldp remote-peer 4
[NPE1-mpls-remote-4] remote-ip 4.4.4.4
[NPE1-mpls-remote-4] quit
# Enable L2VPN and MPLS L2VPN.
[NPE1] l2vpn
[NPE1-l2vpn] mpls l2vpn
[NPE1-l2vpn] quit
# Configure the basic attributes of VPLS instance aaa, which uses LDP.
[NPE1] vsi aaa static
[NPE1-vsi-aaa] pwsignal ldp
[NPE1-vsi-aaa-ldp] vsi-id 500
[NPE1-vsi-aaa-ldp] peer 1.1.1.1 upe
[NPE1-vsi-aaa-ldp] peer 3.3.3.3
[NPE1-vsi-aaa-ldp] peer 4.4.4.4
[NPE1-vsi-aaa-ldp] quit
[NPE1-vsi-aaa] quit
The configuration procedure on NPE 2 is similar to that on NPE 1. (Details not shown.)
4.
Configure NPE 3:
# Configure basic MPLS.
<Sysname> system-view
195
[Sysname] sysname NPE3
[NPE3] interface loopback 0
[NPE3-LoopBack0] ip address 4.4.4.4 32
[NPE3-LoopBack0] quit
[NPE3] mpls lsr-id 4.4.4.4
[NPE3] mpls
[NPE3–mpls] quit
[NPE3] mpls ldp
[NPE3–mpls-ldp] quit
# Configure an IP address for the interface connected to NPE 1, and enable MPLS and MPLS
LDP.
[NPE3] interface vlan-interface 15
[NPE3-Vlan-interface15] ip address 15.1.1.2 24
[NPE3-Vlan-interface15] mpls
[NPE3-Vlan-interface15] mpls ldp
[NPE3-Vlan-interface15] quit
# Configure an IP address for the interface connected to NPE 2, and enable MPLS and MPLS
LDP.
[NPE3] interface vlan-interface 16
[NPE3-Vlan-interface16] ip address 16.1.1.2 255.255.255.0
[NPE3-Vlan-interface16] mpls
[NPE3-Vlan-interface16] mpls ldp
[NPE3-Vlan-interface16] quit
# Configure the remote LDP session.
[NPE3] mpls ldp remote-peer 1
[NPE3-mpls-remote-1] remote-ip 2.2.2.2
[NPE3-mpls-remote-1] quit
[NPE3] mpls ldp remote-peer 2
[NPE3-mpls-remote-2] remote-ip 3.3.3.3
[NPE3-mpls-remote-2] quit
# Enable L2VPN and MPLS L2VPN.
[NPE3] l2vpn
[NPE3-l2vpn] mpls l2vpn
[NPE3-l2vpn] quit
# Configure the basic attributes of VPLS instance aaa, which uses LDP.
[NPE3] vsi aaa static
[NPE3-vsi-aaa] pwsignal ldp
[NPE3-vsi-aaa-ldp] vsi-id 500
[NPE3-vsi-aaa-ldp] peer 2.2.2.2
[NPE3-vsi-aaa-ldp] peer 3.3.3.3
[NPE3-vsi-aaa-ldp] quit
[NPE3-vsi-aaa] quit
# Create service instance on GigabitEthernet 1/0/1, the interface connecting CE 3, and bind the
VPLS instance.
[NPE3] interface gigabitethernet 1/0/1
[NPE3-GigabitEthernet1/0/1] service-instance 1000
[NPE3-GigabitEthernet1/0/1-srv1000] encapsulation s-vid 10
[NPE3-GigabitEthernet1/0/1-srv1000] xconnect vsi aaa
196
[NPE3-GigabitEthernet1/0/1-srv1000] quit
# Execute the display vpls connection command on the PEs. The output shows that a PW
connection in up state has been established.
Configuring BFD for the primary link in an H-VPLS network
Network requirements
In the H-VPLS network, Switch A is the UPE, Switch B is the primary NPE and Switch C is the
backup NPE.
Enable MPLS on the connecting interfaces of the switches. Enable OSPF on the switches to ensure
IP connectivity.
Configure BFD for the link between Switch A and Switch B and the link between Switch A and Switch
C, so that when either link is down, BFD can detect the link failure and inform the MPLS LDP protocol
for fast PW switchover.
Figure 48 Network diagram
Configuration procedure
1.
Configure basic MPLS:
# Configure Switch A.
<SwitchA> system-view
[SwitchA] mpls lsr-id 1.1.1.9
[SwitchA] mpls
[SwitchA-mpls] quit
[SwitchA] mpls ldp
[SwitchA-mpls-ldp] quit
[SwitchA] mpls ldp remote-peer switchb
[SwitchA-mpls-ldp-remote-switchb] remote-ip 2.2.2.9
[SwitchA-mpls-ldp-remote-switchb] remote-ip bfd
[SwitchA-mpls-ldp-remote-switchb] quit
[SwitchA] mpls ldp remote-peer switchc
[SwitchA-mpls-ldp-remote-switchc] remote-ip 3.3.3.9
[SwitchA-mpls-ldp-remote-switchc] remote-ip bfd
[SwitchA-mpls-ldp-remote-switchc] quit
[SwitchA] vlan 12
197
[SwitchA-vlan12] port gigabitethernet 1/0/2
[SwitchA-vlan12] quit
[SwitchA] vlan 13
[SwitchA-vlan13] port gigabitethernet 1/0/1
[SwitchA-vlan13] quit
[SwitchA] interface vlan-interface 12
[SwitchA-Vlan-interface12] mpls
[SwitchA-Vlan-interface12] mpls ldp
[SwitchA-Vlan-interface12] quit
[SwitchA] interface vlan-interface 13
[SwitchA-Vlan-interface13] mpls
[SwitchA-Vlan-interface13] mpls ldp
[SwitchA-Vlan-interface13] quit
# Configure Switch B.
<SwitchB> system-view
[SwitchB] mpls lsr-id 2.2.2.9
[SwitchB] mpls
[SwitchB-mpls] quit
[SwitchB] mpls ldp
[SwitchB-mpls-ldp] quit
[SwitchB] mpls ldp remote-peer switcha
[SwitchB-mpls-ldp-remote-switcha] remote-ip 1.1.1.9
[SwitchB-mpls-ldp-remote-switcha] remote-ip bfd
[SwitchB-mpls-ldp-remote-switcha] quit
[SwitchB] vlan 12
[SwitchB-vlan12] port gigabitethernet 1/0/1
[SwitchB-vlan12] quit
[SwitchB] interface vlan-interface 12
[SwitchB-Vlan-interface12] mpls
[SwitchB-Vlan-interface12] mpls ldp
[SwitchB-Vlan-interface12] quit
# Configure Switch C.
<SwitchC> system-view
[SwitchC] mpls lsr-id 3.3.3.9
[SwitchC] mpls
[SwitchC-mpls] quit
[SwitchC] mpls ldp
[SwitchC-mpls-ldp] quit
[SwitchC] mpls ldp remote-peer switcha
[SwitchC-mpls-ldp-remote-switcha] remote-ip 1.1.1.9
[SwitchC-mpls-ldp-remote-switcha] remote-ip bfd
[SwitchC-mpls-ldp-remote-switcha] quit
[SwitchC] vlan 13
[SwitchC-vlan13] port gigabitethernet 1/0/1
[SwitchC-vlan13] quit
[SwitchC] interface vlan-interface 13
[SwitchC-Vlan-interface13] mpls
[SwitchC-Vlan-interface13] mpls ldp
198
[SwitchC-Vlan-interface13] quit
2.
Configure related interfaces on the switches:
# Configure Switch A.
[SwitchA] interface vlan-interface 12
[SwitchA-Vlan-interface12] ip address 12.1.1.1 24
[SwitchA-Vlan-interface12] quit
[SwitchA] interface vlan-interface 13
[SwitchA-Vlan-interface13] ip address 13.1.1.1 24
[SwitchA-Vlan-interface13] quit
[SwitchA] interface loopback 0
[SwitchA-LoopBack0] ip address 1.1.1.9 32
[SwitchA-LoopBack0] quit
# Configure Switch B.
[SwitchB] interface vlan-interface 12
[SwitchB-Vlan-interface12] ip address 12.1.1.2 24
[SwitchB-Vlan-interface12] quit
[SwitchB] interface loopback 0
[SwitchB-LoopBack0] ip address 2.2.2.9 32
[SwitchB-LoopBack0] quit
# Configure Switch C.
[SwitchC] interface vlan-interface 13
[SwitchC-Vlan-interface13] ip address 13.1.1.3 24
[SwitchC-Vlan-interface13] quit
[SwitchC] interface loopback 0
[SwitchC-LoopBack0] ip address 3.3.3.9 32
[SwitchC-LoopBack0] quit
3.
Configure basic OSPF functions:
# Configure Switch A.
[SwitchA] ospf
[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.0] network 12.1.1.1 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] network 13.1.1.1 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
# Configure Switch B.
[SwitchB] ospf
[SwitchB-ospf-1] area 0
[SwitchB-ospf-1-area-0.0.0.0] network 12.1.1.2 0.0.0.255
[SwitchB-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0
[SwitchB-ospf-1-area-0.0.0.0] quit
[SwitchB-ospf-1] quit
# Configure Switch C.
[SwitchC] ospf
[SwitchC-ospf-1] area 0
[SwitchC-ospf-1-area-0.0.0.0] network 13.1.1.3 0.0.0.255
[SwitchC-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0
[SwitchC-ospf-1-area-0.0.0.0] quit
199
[SwitchC-ospf-1] quit
4.
Configure a VPLS instance for each switch:
# Configure Switch A.
[SwitchA] l2vpn
[SwitchA-l2vpn] mpls l2vpn
[SwitchA-l2vpn] quit
[SwitchA] vsi vpna static
[SwitchA-vsi-vpna] pwsignal ldp
[SwitchA-vsi-vpna-ldp] vsi-id 100
[SwitchA-vsi-vpna-ldp] peer 2.2.2.9 backup-peer 3.3.3.9
[SwitchA-vsi-vpna-ldp] quit
[SwitchA-vsi-vpna] quit
[SwitchA] vlan 100
[SwitchA-vlan100] port gigabitethernet 1/0/1
[SwitchA-vlan100] quit
[SwitchA] interface vlan-interface 100
[SwitchA-Vlan-interface100] l2 binding vsi vpna
[SwitchA-Vlan-interface100] return
# Configure Switch B.
[SwitchB] l2vpn
[SwitchB-l2vpn] mpls l2vpn
[SwitchB-l2vpn] quit
[SwitchB] vsi vpna static
[SwitchB-vsi-vpna] pwsignal ldp
[SwitchB-vsi-vpna-ldp] vsi-id 100
[SwitchB-vsi-vpna-ldp] peer 1.1.1.9 upe
[SwitchB-vsi-vpna-ldp] quit
[SwitchB-vsi-vpna] quit
# Configure Switch C.
[SwitchC] l2vpn
[SwitchC-l2vpn] mpls l2vpn
[SwitchC-l2vpn] quit
[SwitchC] vsi vpna static
[SwitchC-vsi-vpna] pwsignal ldp
[SwitchC-vsi-vpna-ldp] vsi-id 100
[SwitchC-vsi-vpna-ldp] peer 1.1.1.9 upe
[SwitchC-vsi-vpna-ldp] quit
[SwitchC-vsi-vpna] quit
5.
Verify the configuration:
# Use the display bfd session verbose command to display information about the BFD
sessions from Switch A to its neighbors.
<SwitchA> display bfd session verbose
Total Session Num: 2
Init Mode: Active
Session Working Under Ctrl Mode:
Local Discr: 21
Remote Discr: 20
200
Source IP: 1.1.1.9
Destination IP: 2.2.2.9
Session State: Up
Interface: LoopBack0
Min Trans Inter: 400ms
Act Trans Inter: 400ms
Min Recv Inter: 400ms
Act Detect Inter: 2000ms
Running Up for: 00:00:01
Auth mode: None
Connect Type: Indirect
Board Num: 6
Protocol: MFW/LDP
Diag Info: No Diagnostic
Local Discr: 4
Remote Discr: 0
Source IP: 1.1.1.9
Destination IP: 3.3.3.9
Session State: Up
Interface: LoopBack0
Min Trans Inter: 400ms
Act Trans Inter: 1000ms
Min Recv Inter: 400ms
Act Detect Inter: 3000ms
Running Up for: 00:00:01
Auth mode: None
Connect Type: Indirect
Board Num: 6
Protocol: MFW/LDP
Diag Info: No Diagnostic
# Execute the display vpls connection vsi vpna command on Switch A.
<SwitchA> display vpls connection vsi vpna
Total 2 connection(s),
connection(s): 1 up, 1 block, 0 down
VSI Name: vpna
Signaling: ldp
VsiID
VsiType
PeerAddr
InLabel OutLabel LinkID
VCState
100
vlan
2.2.2.9
134312
138882
1
up
100
vlan
3.3.3.9
134216
140476
2
block
The output shows that the link between Switch A and Switch B is up.
# Disconnect the link between Switch A and Switch B. Then, execute the display vpls
connection vsi vpna command.
<SwitchA> display vpls connection vsi vpna
Total 1 connection(s),
connection(s): 1 up, 0 block, 0 down
VSI Name: vpna
Signaling: ldp
VsiID
VsiType
PeerAddr
InLabel OutLabel LinkID
VCState
100
vlan
3.3.3.9
134216
up
The output shows that the link to 3.3.3.9 is up.
Troubleshooting VPLS
Symptom
The VPLS PW is not up.
Analysis
•
The public network LSP tunnel is not established.
201
140476
2
•
The extended session is not operating correctly.
•
A private network interface is not bound to the corresponding VPLS instance or the private
network interface is not up.
Solution
•
Check the routing tables of the PEs to see whether a route is available between the two PEs.
Verify that each device can ping the loopback interface of the peer and whether the LDP
session operates correctly.
•
Verify that no extended session configuration command is missing at either side.
•
Display the private interface status by using the display interface command. Make sure the
private interface is up.
•
Display the current configuration by using the display current-configuration command. Make
sure the two peers have the same PW ID and transport mode.
202
Configuring MPLS L2VPN
This chapter describes how to configure MPLS L2VPN.
Hardware compatibility
The HPE 5820X Switch Series does not support MPLS L2VPN.
MPLS L2VPN overview
MPLS L2VPN is an MPLS-based Layer 2 VPN technology. It uses MPLS to establish Layer 2
connections between network nodes.
Using MPLS L2VPN, carriers can transparently transport Layer 2 data of different data link layer
protocols (including ATM, FR, VLAN, Ethernet, and PPP) over a single MPLS or IP backbone.
For the perspective of users, the MPLS or IP backbone network is a Layer 2 switched network. For
example, when two Ethernet networks are connected through MPLS L2VPN over an MPLS or IP
backbone, Ethernet users cannot sense the existence of the MPLS or IP backbone. They feel like
they are connected directly through an Ethernet.
MPLS L2VPN can provide both point-to-point connections and point-to-multipoint connections. This
chapter describes only the MPLS L2VPN technologies that provide point-to-point connections. For
information about the MPLS L2VPN technologies that provide point-to-multipoint connections, see
"Configuring VPLS."
MPLS L2VPN has the following advantages:
•
High scalability—MPLS L2VPN establishes only Layer 2 connections. It does not maintain the
routing information for users. This greatly reduces the load of provider edge (PE) devices and
even the load of the whole service provider network, enabling carriers to support more VPNs
and to service more users.
•
Guaranteed reliability and VPN routing security—MPLS L2VPN neither tries to obtain nor
processes the routing information for users, guaranteeing the security of user VPN routing
information.
•
Support for multiple network layer protocols—Such as IP, IPX, and SNA.
Basic concepts of MPLS L2VPN
•
Customer edge device—A CE device is a customer network device directly connected to the
service provider network. It can be a network device (such as a router or a switch) or a host. It
cannot "sense" the existence of any VPN, neither does it need to support MPLS.
•
Provider edge device—A PE device is a service provider network device connected to one or
more CEs. It provides VPN access by mapping and forwarding packets from user networks to
public network tunnels and from public network tunnels to user networks.
On an MPLS network, all VPN processing occurs on PEs.
•
Attachment circuit—An AC is a link between a CE and a PE.
•
Virtual circuit—A VC is a pseudowire (PW). It is a virtual bidirectional connection that connects
the ACs on two PEs. An MPLS VC contains a pair of LSPs in opposite directions.
•
Tunnel—A tunnel (or public tunnel) is a connection that carries a VC across the MPLS or IP
backbone. It can be an LSP tunnel, MPLS TE tunnel, or a GRE tunnel.
203
•
Provider device—P devices do not directly connect to CEs. They only need to forward user
packets between PEs.
MPLS L2VPN network models
MPLS L2VPN network models include remote connection model and local connection model.
Remote connection model
As shown in Figure 49, this model connects two Layer 2 customer networks over an MPLS or IP
backbone.
Figure 49 Remote connection
Local connection model
As shown in Figure 50, this model connects two Layer 2 customer networks to the same PE. The
customer networks exchange packets with each other through the PE. The PE functions like a Layer
2 switch.
Figure 50 Local connection
NOTE:
The switch does not support the local connection model.
Remote connection operation
Remote connection establishment
To set up a remote MPLS L2VPN connection between two CEs over a backbone network:
1.
Set up a public tunnel to forward user packets from the local PE to the remote PE.
The public tunnel can be an LSP, MPLS TE, or GRE tunnel. For more information about LSP
and MPLS TE tunnels, see "Configuring basic MPLS" and "Configuring MPLS TE." For more
information about GRE tunnels, see Layer 3—IP Services Configuration Guide.
204
If multiple public tunnels exist between two PEs, you can configure a tunneling policy to control
tunnel selection. For more information about tunneling policy, see "Configuring MPLS L3VPN."
2.
Set up a VC to identify customer networks.
To set up a VC, the two PEs assign VC labels to each other to set up a pair of unidirectional
LSPs in opposite directions. By VC setup mode, MPLS L2VPN can be implemented in Circuit
Cross Connect (CCC) mode, Static Virtual Circuit (SVC) mode, Martini mode, or Kompella
mode. For more information, see "Implementation of MPLS L2VPN."
3.
Set up ACs and bind the ACs to the VC, so the PEs can forward user packets from ACs through
the VC:
a. Set up an AC: Configure the link layer protocol on a PE and the connected CE to set up a
link layer connection (such as a PPP connection) between the PE and the CE.
b. Bind the AC to the VC: For most link layer protocols, you bind the AC to the VC by binding
the PE's Layer 3 interface connected to the CE to the VC. For Ethernet links, you can bind
the Layer 3 interface to the VC or bind a service instance to the VC. After the binding, the PE
forwards packets received from the AC to the bound VC, and forwards packets received
from the bound VC to the AC.
Packet forwarding process
MPLS L2VPN implements transparent transmission of Layer 2 user packets over an MPLS or IP
backbone by encapsulating user packets with a VC label and a tunnel tag .
•
The tunnel tag is used to transfer packets from one PE to another. If the public tunnel is an LSP
tunnel or an MPLS TE tunnel, the tunnel tag is an MPLS label. If the public tunnel is a GRE
tunnel, the tunnel tag is the GRE header and the transport protocol packet header.
•
The VC label identifies a Layer 2 connection to a CE. When receiving a packet from the
backbone, a PE forwards the packet to a CE identified by the VC label.
Figure 51 Packet forwarding process
P
T
V
L2PDU
T
V
L2PDU
PE 1
PE 2
L2PDU
L2PDU
CE 2
CE 1
L2 PDU: Layer 2 protocol data unit.
T represents a tunnel tag. V represents a VC label.
As shown in Figure 51, MPLS L2VPN forwards packets in the following steps:
1.
After PE 1 receives a Layer 2 packet from CE 1, it adds a VC label to the packet according to
the VC bound to the AC, searches for the public tunnel, adds a tunnel tag to the packet, and
then forwards the packet to the P device.
2.
The P device forwards the packet to PE 2 according to the tunnel tag.
3.
After PE 2 receives the packet from the public tunnel, it identifies the VC to which the packet
belongs according to the VC label of the packet, deletes the tunnel tag and the VC label from
the packet, and then forwards the resulting packet to CE 2 through the AC bound to the VC.
205
This packet forwarding process is not applicable to the CCC mode of MPLS L2VPN. For more
information about the CCC mode of MPLS L2VPN, see "CCC MPLS L2VPN."
Implementation of MPLS L2VPN
This section describes how to set up a remote MPLS L2VPN connection in different modes.
CCC MPLS L2VPN
The CCC mode sets up a CCC connection by establishing two static LSPs in opposite directions and
binding the static LSPs to ACs. A VC established in CCC mode is called a CCC connection.
Figure 52 CCC MPLS L2VPN network diagram
After you complete the configurations as shown in Figure 52, a static LSP from PE 1 to PE 2 and a
static LSP from PE 2 to PE 1 are established. Bind the two LSPs to Interface A on PE 1 and to
Interface B on PE 2. A CCC connection is successfully established.
The following describes how a packet is forwarded from CE 1 to CE 2:
1.
After PE 1 receives a packet from CE 1 on Interface A, it adds label 300 (corresponding to the
static LSP from PE 1 to PE 2) into the packet.
2.
After the P device receives the packet, it looks up the label forwarding table, and swaps label
300 with label 310.
3.
After receiving the packet, PE 2 deletes the label from the packet, and then forwards the packet
out of the bound Interface B to CE 2.
Unlike other MPLS L2VPN modes, CCC employs only one level of label to transfer user packets. A
static LSP forwards only packets from the AC bound to the static LSP. Therefore, CCC uses LSPs
exclusively. LSPs used by a CCC connection transfers only CCC connection data. They cannot be
used by other connections or MPLS L3VPN.
SVC MPLS L2VPN
SVC implements MPLS L2VPN by static configuration. It uses two levels of labels to transfer user
packets. The inner label is statically configured on PEs. No signaling protocol is used.
Martini MPLS L2VPN
Martini MPLS L2VPN employs two levels of labels to transfer user packets, and uses LDP as the
signaling protocol to distribute inner labels.
To exchange VC labels between PEs, Martini extended LDP by adding the VC FEC. The VC FEC
contains the following information:
•
VC type—Encapsulation type of the VC. For more information, see "VC encapsulations types."
•
VC ID—Identifier of a VC on a PE.
206
The VC type and the VC ID uniquely identify a VC. On a PE, the VC ID uniquely identifies a VC
among the VCs of the same type.
As shown in Figure 53, the PEs send a VC FEC and VC label mapping to each other. After the VC
labels are distributed, a VC is set up between the PEs.
Figure 53 Label distribution in Martini mode
Kompella MPLS L2VPN
Kompella MPLS L2VPN employs two levels of labels to transfer user packets, and uses BGP as the
signaling protocol to distribute the inner VC label.
Different from other MPLS L2VPN modes, Kompella introduces the concept of VPN. It allows CEs in
the same VPN to establish a connection. CEs in different VPNs cannot establish a connection.
Kompella MPLS L2VPN has the following basic concepts:
•
CE ID—Kompella numbers CEs inside a VPN. A CE ID uniquely identifies a CE in a VPN. CEs
in different VPNs can have the same CE ID.
•
Route distinguisher—To distinguish CEs with the same CE ID in different VPNs, Kompella
adds an RD before a CE ID. An RD and a CE ID uniquely identify a CE.
•
Route target—Kompella uses the BGP route target attribute (also called "VPN target" attribute)
to identify VPNs to make sure CEs in the same VPN can establish a connection and CEs in
different VPNs cannot.
A PE supports the following types of route target attributes:
•
Export target attribute—When a PE sends L2VPN information (such as CE ID and RD) to the
peer PE through a BGP update message, it sets the route target attribute carried in the update
message to export target.
•
Import target attribute—When a PE receives an update message from the peer PE, it checks
the route target attribute in the update message. If the route target value matches an import
target on the PE, the PE accepts the L2VPN information in the update message.
In a word, route target attributes define which PEs can receive L2VPN information, and from which
PEs that a PE can receive L2VPN information.
Different from Martini mode, the Kompella mode does not distribute the VC label assigned by the
local PE directly to the peer PE through the signaling protocol. Instead, it uses label blocks to assign
labels to multiple connections at time. A PE advertises label blocks to all PEs in the same VPN. Each
PE calculates the VC labels according to the label blocks from other PEs.
A label block includes the following parameters:
•
Label Base—Initial label value of the label block. A PE automatically selects the LB value that
cannot be manually modified.
•
Label Range—Number of labels that the label block contains. LB and LR determine the labels
contained in the label block. For example, if the LB is 1000 and LR is 5, the label block contains
labels 1000 through 1004.
207
•
Label-block Offset—Offset of the label block. When CEs increase in a VPN and the existing
label block size is not enough, you do not need to withdraw the label block on the PEs. Instead,
you can assign a new label block in addition to the existing label block to enlarge the label range.
A PE uses LO to identify a label block among all label blocks, and to determine from which label
block it assigns labels. The LO value of a label block is the sum of LRs of all previously assigned
label blocks. For example, if the LR and LO of the first label block is 10 and 0, the LO of the
second label block is 10. If the LR of the second label block is 20, the LO of the third label block
is 30.
The following describes a label block in the format of LB/LO/LR. For example, a label block whose
LB, LO, and LR are 1000, 10, and 5 is represented as 1000/10/5.
With label blocks, you can reserve some labels for the VPN for future use. This wastes some label
resources in a short term, but can reduce the VPN deployment and configuration workload in the
case of expansion.
Assume that an enterprise VPN contains 10 CEs and the number of CEs may increase to 20 in future.
In this case, set the LR to 20. When you add a CE to the VPN, you only need to modify the
configurations of the PE to which the new CE is connected. No change is required for the other PEs,
which simplifies VPN expansion.
Figure 54 VC label calculation
CE 2
Label block 1: 1000/0/5
Label block 2: 1055/5/10
Label block for CE 2: 2000/0/15
Label block for CE 12: 3000/0/15
P Label block allocated
Label block allocated
PE 1
VPN 1
CE 1
VPN 1
PE 2
VC labels calculated
VC connected CE 1 and CE 2:
local VC label: 1002
remote VC label: 2001
VC connected CE 1 and CE 12:
local VC label: 1062
remote VC label: 3001
VC connected CE 1 and CE 2:
local VC label: 2001
remote VC label: 1002
VC connected CE 1 and CE 12:
local VC label: 3001
remote VC label: 1062
VPN 1
CE 12
As shown in Figure 54, PEs calculates VC labels for a VC as follows (take the VC between CE 1 and
CE 12 as an example):
•
PE 1 calculates the VC label it assigns to the VC:
PE 1 compares the ID (12) of the peer CE (CE 12) with the label blocks assigned by PE 1. If a
label block satisfies LO<=CE ID<LO+LR, PE 1 assigns a label from the label block. In this
example, label block 2 (1055/5/10) satisfies LO<=CE ID<LO+LR (5<=12<5+10). PE 1 assigns
a label to the VC from label block 2. The assigned label value = LB+CE ID-LO, namely 1062
(1055+12-5).
•
PE 1 calculates the VC label that PE 2 assigns to the VC:
PE 1 compares the ID (1) of the local CE (CE 1) with the label blocks assigned by PE 2. A label
block that satisfies LO<=CE ID<LO+LR is used by PE 2 to assign a label value to the VC. In this
example, label block (3000/0/15) satisfies LO<=CE ID<LO+LR (0<=1<0+15). PE 2 assigns a
label value to the VC from the label block. The assigned label value = LB+CE ID-LO, namely
3001 (3000+1-0).
•
PE 2 performs the same calculations and gets the same results: the VC label that PE 2 assigns
to the VC is 3001 and that PE 1 assigns to the VC is 1062.
A PE adds the VC label assigned by the peer PE into a Layer 2 packet from a local CE. For example,
when PE 1 forwards packets from CE 1 to CE 2, it adds VC label 3001.
208
Figure 55 Label distribution in Kompella mode
As shown in Figure 55, CE 1 and CE 2 belong to VPN 1. CE 3 and CE 4 belong to VPN 2. Configure
route targets for the two VPNs to make sure CEs in the same VPN can set up a VC and CEs in
different VPNs cannot.
A VC is set up as follows (take the VC between CE 1 and CE 2 as an example):
1.
PE 1 sends the RD, CE ID, route target (export target configured for VPN 1 on PE 1), and the
label block for CE 1 to PE 2 in a BGP update message.
2.
When PE 2 receives the update message, it compares the route target in the message against
the import targets locally configured for VPNs. If a match is found, PE 2 learns the L2VPN
information in the update message for the matching VPN. Otherwise, it does not learn the
L2VPN information.
In this example, the route target value carried in the update message for CE 1 is 100:1, which
matches the import target of VPN 1 on PE 2. Therefore, PE 2 adds the CE 1 L2VPN information
only to VPN 1 but not to other VPNs.
3.
PE 2 sends a BGP update message for CE 2 to PE 1. PE 1 processes the update message as
PE 2 does.
4.
PE 1 and PE 2 calculate the local and remote VC labels for the VC according to the learned
L2VPN information.
The VC is successfully set up after both PE 1 and PE 2 calculate the VC labels.
Table 1 compares the implementation modes of MPLS L2VPN.
209
Table 1 Comparing MPLS L2VPN implementation modes
Mode
CCC
VC label
encapsulation and
distribution
VC label
encapsulation: one
level of label
VC label distribution:
static configuration
SVC
VC label
encapsulation: two
levels of labels
VC label distribution:
static configuration
Martini
VC label
encapsulation: two
levels of labels
VC label distribution:
LDP
Advantages and disadvantages
Advantages:
•
Requires no signaling protocol and occupies
fewer network resources.
•
Network devices only need to support
MPLS.
•
Better QoS for service traffic as LSPs are
exclusive to CCC connections.
Disadvantages:
•
Configuration and maintenance are
complicated. You must configure two static
LSPs in opposite directions for each CCC
connection on each P device.
•
Cannot automatically adapt to network
changes.
Advantage: Requires no signaling protocol and
occupies few network resources.
Disadvantage:
•
Cannot automatically adapt to network
changes.
•
Supports only remote connections.
Advantages:
•
On a carrier network, only PEs need to save
a few VC label to LSP mappings. The P
devices do not need to save any Layer 2
VPN information.
•
To add a new VC, you only need to configure
the PEs of the VC, without interrupting
network operation.
Application
scenario
Small-scale
network with a
simple
topology
where all the
network
devices
support
MPLS.
Small-scale
network with a
simple
topology.
Sparse Layer
2 connections,
such as a star
topology.
Disadvantage: Supports only remote
connections.
Kompella
VC label
encapsulation: two
levels of labels
VC label distribution:
BGP
Advantages:
•
Introduces the concept of VPN to prevent
CEs in different VPNs from communicating
with each other.
•
Uses label blocks to assign additional labels
to user VPNs for future use, greatly reducing
the VPN deployment and configuration
workload in the case of expansion.
•
To add a CE to the network, you only need to
configure the PE to which the CE is
connected. The configuration workload is
small and does not interrupt network
operation.
Disadvantage: The implementation is relatively
complicated.
210
Full-mesh
network.
VC encapsulations types
Before adding a VC label to a Layer 2 packet, a PE encapsulates the Layer 2 packet according to the
AC link type. VC encapsulation types and AC link types are closely related. The following VC
encapsulation types are available for an Ethernet link:
•
Ethernet—P-Tag is not transferred on a VC. If a packet from a CE contains a P-tag, the PE
removes the P-tag before encapsulating the packet. If the packet contains no P-tag, the PE
directly encapsulates the packet. If the user access mode is VLAN, the PE adds a P-tag into a
packet sent to a CE. If the user access mode is Ethernet, the PE does not add a P-tag but
directly forwards the packet to the CE. Rewriting and removing existing tags are not allowed.
•
VLAN—Packets transmitted over a VC must carry a P-Tag.
{
{
If the peer PE does not require the ingress to rewrite the P-tag:
The PE keeps the P-Tag unchanged for a packet from a CE and then encapsulates the
packet. If the packet contains no P-tag, the PE adds a null label (the label value is 0) into the
packet, and then encapsulates the packet.
If the peer PE requires the ingress to rewrite the P-tag:
The PE changes the P-Tag to the VLAN tag (the tag may be a null tag) expected by the peer
PE, and then encapsulates the packet. If the packet contains no P-tag, the PE adds a VLAN
tag expected by the peer PE (the tag value may be 0) and then encapsulates the packet.
For a packet sent to a CE, if the user access mode is VLAN, the PE rewrites or retains the
original P-tag in the packet and then forwards the packet to the CE. If the user access mode is
Ethernet, the PE removes the P-tag and then forwards the packet to the CE.
MPLS L2VPN configuration task list
To set up a remote VC between two PEs, complete the following tasks:
•
Configure an IGP on PEs and P devices to ensure IP connectivity in the backbone.
•
Configure MPLS, GRE, or MPLS TE to set up public tunnels across the backbone network.
•
Configure a tunneling policy on PEs to select the public tunnels that carry the VC.
•
Configure MPLS L2VPN, set up the VC, and bind the AC to the VC.
NOTE:
The MPLS L2VPN is transparent to a user network. You do not need to perform MPLS
L2VPN-specific configurations on CEs.
To configure MPLS L2VPN:
Task
Remarks
Required.
Perform this task to enable MPLS L2VPN. You can
perform other MPLS L2VPN configurations only after
you enable MPLS L2VPN.
Configuring basic MPLS L2VPN
Required.
Configuring a PE-CE interface
Perform this task to set up an AC between a PE and
a CE.
Configuring a remote CCC connection
Configuring SVC MPLS L2VPN
Use one of the approaches according to the MPLS
L2VPN implementation method.
Configuring Martini MPLS L2VPN
Perform this task to set up a VC, and bind the VC to
an AC.
Configuring Kompella MPLS L2VPN
211
Task
Remarks
Configuring traffic policing for an AC
Optional.
Enabling traffic statistics for an AC
Optional.
Configuring basic MPLS L2VPN
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure the LSR ID.
mpls lsr-id lsr-id
N/A
3.
Configure basic MPLS and
enter MPLS view.
mpls
N/A
4.
Return to system view.
quit
N/A
5.
Enable L2VPN and enter
L2VPN view.
l2vpn
Disabled by default.
6.
Enable MPLS L2VPN.
mpls l2vpn
Disabled by default.
Configuring a PE-CE interface
A PE-CE interface refers to a PE's interface connected to a CE.
As shown in Table 2, a PE-CE interface of a PE can use various types of encapsulations.
Table 2 Encapsulation types on a PE-CE interface of a PE
Encapsulation type
Configuration
Ethernet
Configuring Ethernet encapsulation
VLAN
Configuring VLAN encapsulation
Configuring Ethernet encapsulation
When you configure Martini MPLS L2VPN for a service instance, you can specify the encapsulation
type for the PE-CE interface. When you configure MPLS L2VPN other than the Martini mode, you
can only use the default encapsulation type on the PE-CE interface.
By default, a Layer 3 Ethernet interface uses Ethernet encapsulation. For configuration information
about Layer 3 Ethernet interfaces, see Layer 2—LAN Switching Configuration Guide.
Configuring VLAN encapsulation
When you configure Martini MPLS L2VPN for a service instance, you can specify the encapsulation
type for the PE-CE interface. When you configure MPLS L2VPN other than the Martini mode, you
can only use the default encapsulation type on the PE-CE interface.
By default, a VLAN interface uses VLAN encapsulation (the VLAN interface and the CE must reside
in the same VLAN). For configuration information about VLAN interface, see Layer 2—LAN
Switching Configuration Guide.
212
Configuring a remote CCC connection
To configure a remote CCC connection, perform the following configuration on the PE and P devices:
•
On a PE, you do not need to create static LSPs (with the static-lsp command) for a remote
CCC connection. Instead, you only need to configure the incoming and outgoing labels by using
the ccc interface in-label out-label command on each PE of the remote CCC connection.
•
On each P device between the PEs, you must use the static-lsp command to create two static
LSPs in opposite directions to dedicatedly transmit data of the CCC connection.
Follow these guidelines to configure a remote CCC connection:
•
The label range for CCC is 16 to 1023, which is the label range for static LSPs.
•
In CCC mode, if the PE-CE interface of a PE is a VLAN interface, all packets sent from the PE
to the CE carry a VLAN tag. You must configure the PE-CE interface of the CE to permit the
packets that carry that VLAN tag.
To configure a PE:
Step
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
Create a remote
CCC connection.
ccc ccc-connection-name interface
interface-type interface-number
in-label in-label-value out-label
out-label-value nexthop ip-address
The interface interface-type
interface-number option specifies a
PE-CE interface of the PE. By
specifying the interface, you bind the
AC link on the interface to the remote
CCC connection to be created.
To configure a P device:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Configure a transit static
LSP.
static-lsp transit lsp-name
incoming-interface interface-type
interface-number in-label in-label nexthop
next-hop-addr out-label out-label
For more information
about this command,
see MPLS Command
Reference.
Configuring SVC MPLS L2VPN
SVC MPLS L2VPN does not use any signaling protocol to transfer L2VPN information. It uses
tunnels to transport data between PEs.
SVC supports these tunnel types: LDP LSP and CR-LSP. By default, LDP LSP tunnels are used.
You can configure a static VC in the following methods:
•
Configure a static VC on a Layer 3 interface (Layer 3 Ethernet interface or VLAN interface).
•
Configure a static VC for a service instance.
After you configure an SVC on a Layer 3 interface, packets arriving at this interface are forwarded
over the VC. If the Layer 3 interface is a VLAN interface, all packets carrying the tag of the VLAN are
forwarded over the VC, no matter which Layer 2 Ethernet interfaces that the packets arrive at. The
device chooses a VC for a received packet according to only the VLAN tag carried in the packet. It
cannot differentiate the users and services on different Layer 2 Ethernet interfaces. Hewlett Packard
Enterprise recommends that you configure SVC on a VLAN interface when all users connected to
the VLAN interface have their packets forwarded over the same VC.
213
After you configure an SVC for a service instance applied on a Layer 2 Ethernet interface or Layer 2
aggregate interface, the interface uses the service instance to match incoming packets. Packets
matching the service instance are forwarded over the VC. A service instance can match all packets
received on the interface, packets carrying the specified VLAN tags, all tagged packets, or packets
with no VLAN tags. Hewlett Packard Enterprise recommends that you configure static VCs in this
way when the users connected to the same VLAN interface must use different VCs to forward
packets.
Configuring a static VC on a Layer 3 interface (approach 1)
To configure a static VC on a Layer 3 interface of a PE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter the view of the
interface connecting the
CE.
interface interface-type
interface-number
N/A
3.
Create a static VC
connection.
mpls static-l2vc destination
destination-router-id
transmit-vpn-label transmit-label-value
receive-vpn-label receive-label-value
[ ethernet | vlan } | tunnel-policy
tunnel-policy-name ] *
The label range for SVC is 16 to
1023, which is the label range
for static LSPs.
The transmit-vpn-label and
receive-vpn-label configured
on the local PE must be the
same as the receive-vpn-label
and transmit-vpn-label
configured on the peer PE.
Configuring a static VC on a Layer 3 interface (approach 2)
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter the view of the
interface connecting
the CE.
interface interface-type
interface-number
N/A
Create a static VC
and enter
static-L2VC view.
mpls static-l2vc destination vcid
[ { ethernet | vlan } | [ tunnel-policy
tunnel-policy-name ] ] *
By default, no static VCs are created.
Configure the VC
labels for the VC.
static label local local-vc remote
remote-vc
By default, no VC labels are
configured for the VC.
3.
4.
Configuring a static VC for a service instance
To perform this task, complete the following operations on a PE:
•
Create a service instance on a Layer 2 Ethernet interface or Layer 2 aggregate interface.
•
Configure a packet matching rule for the service instance.
•
Create a static VC or the service instance.
After you perform these operations, packets arriving at the interface and matching the packet
matching rule are forwarded over the VC.
214
To create multiple VCs with the same attributes (such as VC encapsulation type and VC tunneling
policy), you do not need to configure the attributes one by one for each VC. Instead, you can create
a PW class, configure VC attributes in the PW class, and then reference the PW class in each VC.
To create a static VC for a service instance:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Create a PW class and
enter PW class view.
pw-class pw-class-name
3.
Specify the VC
encapsulation type.
trans-mode { ethernet | vlan }
Optional.
By default, no PW class is
created.
Optional.
By default, the VC
encapsulation type is VLAN.
Optional.
4.
Specify the tunneling
policy.
pw-tunnel-policy policy-name
5.
Return to system view.
quit
•
6.
7.
8.
Enter the view of the Layer
2 Ethernet interface or
Layer 2 aggregate interface
connected to a CE.
•
If you do not specify a
tunneling policy, the default
tunneling policy is used. The
default tunneling policy selects
only one tunnel in this order:
LSP tunnel, GRE tunnel,
CR-LSP tunnel. For
information about how to
configure a tunneling policy,
see "Configuring MPLS
L3VPN."
N/A
Enter Layer 2 Ethernet interface
view:
interface interface-type
interface-number
Enter Layer 2 aggregate interface
view:
interface bridge-aggregation
interface-number
N/A
Create a service instance
and enter service instance
view.
service-instance instance-id
By default, no service instance
is created.
Configure a packet
matching rule for the
service instance.
encapsulation { s-vid vlan-id
[ only-tagged ] | port-based | tagged
| untagged }
By default, no packet matching
rule is configured for the
service instance.
This command is available for
service instances with an ID in
the range of 1 to 4094.
9.
Create a static VC and
enter static-xpeer view.
10. Configure the VC labels for
the VC.
xconnect static-peer
peer-ip-address pw-id pw-id
[ access-mode { ethernet | vlan } |
mtu mtu-value | pw-class
class-name ] *
static label local local-vc remote
remote-vc
215
After this command is
executed, the VLAN ID,
access mode, and MTU
configured for the service
instance cannot be changed.
To modify these parameters,
you must use the undo
xconnect static-peer
command to delete the VCs
first.
By default, no VC labels are
configured for the VC.
Step
Command
Remarks
11. Display information about
one or all service instances
configured on the interface.
display service-instance interface
interface-type interface-number
[ service-instance instance-id ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
For more information about commands service-instance, encapsulation, and display
service-instance interface, see MPLS Command Reference.
Configuring Martini MPLS L2VPN
To configure Martini MPLS L2VPN, complete the following tasks:
1.
Configure the remote peer.
In Martini MPLS L2VPN implementation, VC labels must be exchanged between PEs. Because
two PEs may not be connected to each other directly, you must establish a remote session
between the two PEs, so that VC FECs and VC labels can be transferred through the session.
2.
Create a Martini VC, in one of the following ways:
{
Configure a Martini VC on a Layer 3 interface.
In this way, packets arriving at this interface are forwarded over the created VC. If the Layer
3 interface is a VLAN interface, all packets carrying the tag of the VLAN are forwarded over
the VC, no matter which Layer 2 Ethernet interfaces that the packets arrive at. The device
chooses a VC for a received packet according to only the VLAN tag carried in the packet. It
cannot differentiate the users and services on different Layer 2 Ethernet interfaces. Create
a VC on a VLAN interface when all users connected to the VLAN interface have their
packets forwarded over the same VC.
{
Configure a Martini VC for a service instance.
After you configure a Martini VC for a service instance applied on a Layer 2 Ethernet
interface or Layer 2 aggregate interface, the interface uses the service instance to match
incoming packets. Packets matching the service instance are forwarded over the VC. A
service instance can match all packets received on the interface, packets carrying the
specified VLAN tags, all tagged packets, or packets with no VLAN tags. Configure Martini
VCs in this way when the users connected to the same VLAN interface must use different
VCs to forward packets. For more information about service instances, see "Configuring
VPLS."
NOTE:
Service instances can be created only on Layer 2 Ethernet interfaces or Layer 2 aggregate
interfaces.
Configuring the remote peer
Step
Command
1.
Enter system view.
system-view
2.
Configure an MPLS LDP remote peer and enter
its view.
mpls ldp remote-peer remote-peer-name
3.
Specify the IP address of the remote peer.
remote-ip ip-address
For remote peer configuration information, see "Configuring basic MPLS."
216
Creating a Martini VC on a Layer 3 interface
IMPORTANT:
A Martini VC has two main parameters: IP address of the peer PE, and VC ID. The combination of
the VC ID and the encapsulation type must be unique on a PE. Changing the encapsulation type
may result in VC ID conflicts.
To create a Martini VC on a Layer 3 interface of a PE:
Step
Command
1.
Enter system view.
system-view
2.
Enter the view of the interface connecting the
CE.
interface interface-type interface-number
3.
Create a Martini VC.
mpls l2vc destination vcid [ ethernet | vlan } |
[ tunnel-policy tunnel-policy-name ] ] *
Creating a Martini VC for a service instance
To complete this task, perform the following configurations on a PE:
•
Create a service instance on a Layer 2 Ethernet interface or Layer 2 aggregate interface.
•
Configure a packet matching rule for the service instance.
•
Create a Martini VC for the service instance.
After you perform these configurations, packets arriving at the interface and matching the packet
matching rule are forwarded over the created VC.
To create multiple VCs with the same attributes (such as VC encapsulation type and VC tunneling
policy), you do not need to configure the attributes one by one for each VC. Instead, you can create
a PW class, configure VC attributes in the PW class, and then reference the PW class in each VC.
To create a Martini VC for a service instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a PW class and enter
PW class view.
pw-class pw-class-name
3.
Specify the VC
encapsulation type.
trans-mode { ethernet | vlan }
Optional.
By default, no PW class is
created.
Optional.
VLAN by default.
Optional.
4.
Specify the tunneling policy.
pw-tunnel-policy policy-name
If you do not specify a tunneling
policy, the default tunneling policy
is used. The default tunneling
policy selects only one tunnel in
this order: LSP tunnel, CR-LSP
tunnel.
For information about how to
configure a tunneling policy, see
"Configuring MPLS L3VPN."
5.
Return to system view.
N/A
quit
217
Step
Command
•
6.
7.
8.
9.
Enter Layer 2 Ethernet
interface view:
interface interface-type
interface-number
Enter Layer 2 aggregate
interface view:
interface
bridge-aggregation
interface-number
Remarks
Enter the view of the Layer 2
Ethernet interface or Layer 2
aggregate interface
connected to a CE.
•
Create a service instance
and enter service instance
view.
service-instance instance-id
By default, no service instance is
created.
Configure a packet matching
rule for the service instance.
encapsulation { s-vid { vlan-id |
vlan-list } [ only-tagged ] |
port-based | tagged | untagged }
By default, no packet matching
rule is configured for the service
instance.
xconnect peer peer-ip-address
pw-id pw-id [ access-mode
{ ethernet | vlan } | mtu mtu-value
| [ pw-class class-name ] ] *
After this command is executed,
the VLAN ID, access mode, and
MTU configured for the service
instance cannot be changed. To
modify these parameters, you
must use the undo xconnect
peer command to delete the VC
first.
Create a Martini VC for the
service instance.
N/A
The xconnect peer command is
available for service instances
with an ID in the range of 1 to
4094.
10. Display information about
one or all service instances
configured on the interface.
display service-instance
interface interface-type
interface-number
[ service-instance instance-id ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
NOTE:
MPLS L2VPN does not support load sharing among tunnels.
Inspecting VCs
On a MPLS L2VPN network, you can use the MPLS LSP ping function to test the connectivity of VCs
and get necessary information for troubleshooting VC failures.
On the local PE, the MPLS LSP ping function adds the label of the VC to be tested into MPLS Echo
Request messages so the messages travel along the VC. The local PE determines whether the VC
is valid and reachable according to the replies received from the peer PE.
To test the VC connectivity, perform the following task in any view:
Task
Command
Remarks
Use MPLS LSP ping to test the
VC connectivity.
ping lsp [ -a source-ip | -c count |
-exp exp-value | -h ttl-value | -m
wait-time | -r reply-mode | -s
packet-size | -t time-out | -v ] * pw
ip-address pw-id pw-id
MPLS LSP ping can be used to
test the connectivity of only a
Martini VC.
218
Configuring Kompella MPLS L2VPN
To configure a Kompella MPLS L2VPN, perform the following configurations on PEs:
•
Configure BGP L2VPN capability. (Not needed for a local connection.)
•
Create and configure MPLS L2VPN.
•
Create a CE connection.
Configuring BGP L2VPN capability
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Establish the peer
relationship with the peer
PE.
peer { group-name | ip-address }
as-number as-number
N/A
4.
Specify the interface for the
TCP connection.
peer { group-name | ip-address }
connect-interface interface-type
interface-number
N/A
5.
Enter BGP L2VPN address
family view.
l2vpn-family
For more information about the
configuration in BGP-L2VPN
address family, see "Configuring
MPLS L3VPN."
6.
Enable the filtering by the
route target extended
community attributes for the
received routing information.
policy vpn-target
Enable the specified peer or
peers to exchange BGP
routing information for the
BGP-L2VPN address family.
peer { group-name | ip-address }
enable
7.
Optional.
Enabled by default.
N/A
Creating and configuring an MPLS L2VPN
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
2.
Create an MPLS L2VPN and
enter MPLS L2VPN view.
mpls l2vpn vpn-name
[ encapsulation { ethernet | vlan } ]
You must create an L2VPN
name on the PE for each
VPN where a directly
connected CE resides, and
specify an encapsulation
type matching that of the AC
link.
3.
Configure an RD for the
MPLS L2VPN.
route-distinguisher
route-distinguisher
Once configured, an RD
cannot be changed, unless
you delete the L2VPN and
then re-create it.
219
Step
4.
5.
Associate the MPLS L2VPN
with one or more route
targets.
Set the Layer 2 MTU for the
MPLS L2VPN.
Command
Remarks
vpn-target vpn-target&<1-16> [ both |
export-extcommunity |
import-extcommunity ]
N/A
mtu mtu
The mtu command affects
only parameter negotiations,
if any. It does not affect data
forwarding. Hewlett Packard
Enterprise recommends not
using this command.
Creating a CE connection
Configuration parameters and guidelines
•
id ce-id: Specifies the CE ID of a local CE connected to the PE.
•
range ce-range: Specifies the CE range—the maximum number of CEs to which the specified
CE can connect.
You can configure a CE range greater than what is required based on your estimate of future
VPN expansion. This can reduce configuration workload required when CEs are added into the
VPN in future.
•
default-offset default-offset: Specifies the initial CE ID, 0 or 1. 0 indicates CEs in the VPN are
numbered from 0. 1 indicates CEs in the VPN are numbered from 1.
This parameter and the CE range together determine the label blocks that the PE assigns to
CEs:
{
{
When you first execute the ce command and specify the CE range as ce-range1, the PE
assigns the first label block. The LR of the label block equals ce-range1. If the default-offset
is 0, the LO of the label block is 0. Otherwise, the LO is 1.
When you execute the ce command for the second time and specify the CE range as
ce-range2 (greater than ce-range1), the PE assigns the second label block. The LR of the
second label block = ce-range2–ce-range1. If the default-offset is 0, the LO of the label
block is ce-range1. Otherwise, the LO is ce-range1+1.
The subsequent label blocks are calculated in the same way. For example, if you execute the
following commands on the PE in order, the PE assigns three label blocks. They are LB1/0/10,
LB2/10/12, and LB3/22/14, where LB1, LB2, and LB3 are label values automatically selected
by the PE.
ce ce1 id 1 range 10 default-offset 0
ce ce1 id 1 range 22
ce ce1 id 1 range 36
•
ce-offset ce-id: Specifies the ID of the peer CE that establishes a local or remote connection
with the local CE.
If you execute the connection command without specifying the ce-offset ce-id option:
{
{
When you first execute the connection command, the PE creates a connection between
the local CE and the peer CE with an ID of default-offset. If the default-offset equals the local
CE ID, the PE creates a connection for the local CE and the peer CE with an ID of
default-offset+1.
When you execute the connection command for the second time, the PE creates a
connection between the local CE and the peer CE with an ID of "previous connection CE
ID+1." If the "previous connection CE ID+1" equals the local CE ID, the PE creates a
connection for the local CE and the peer CE with an ID of "previous connection CE ID+2."
220
When you plan a VPN, Hewlett Packard Enterprise recommends that you set CE IDs in
incremental sequence and then configure connections in the sequence of CE IDs so you can
omit the ce-offset keyword (use the default setting) for most connections.
•
To modify the CE range by executing the ce command, you can only change the CE range to a
bigger value than that of the current CE range. For example, if the current CE range is 10, you
can change it to 20, but you cannot change it to 5. Changing the CE range to a bigger value
does not interrupt current services. To change the CE range to a smaller value, you must delete
the current CE, re-create the CE, and specify a smaller CE range for it.
Configuration procedure
To create a CE connection:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter MPLS L2VPN view.
mpls l2vpn vpn-name
N/A
3.
Create a CE, specify the CE
name, CE ID, CE range, and
the CE ID initial offset and
enter MPLS L2VPN CE view.
ce ce-name [ id ce-id [ range
ce-range ] [ default-offset
default-offset ] ]
N/A
4.
Create a Kompella
connection.
connection [ ce-offset ce-id ]
interface interface-type
interface-number [ tunnel-policy
tunnel-policy-name ]
The ce-offset ce-id option
determines whether the
connection is a local
connection or a remote
connection. If the specified
CE is connected to the same
PE as the local CE, the
connection is a local
connection. Otherwise, the
connection is a remote
connection.
The interface interface-type
interface-number option
specifies a PE-CE interface of
the PE. By specifying the
interface, you bind the AC link
on the interface to the
Kompella connection.
Resetting L2VPN BGP sessions
To apply new configuration that affects BGP routing selection, perform the following task in any view:
Task
Command
Reset L2VPN BGP sessions.
reset bgp l2vpn { as-number | ip-address | all |
external | internal }
Configuring traffic policing for an AC
Traffic policing controls packet transmission to avoid network congestion. An AC originally refers to a
physical link between a PE and a CE to transfer data between the user network and the public
network. In MPLS L2VPN, a PE uses service instances to differentiate different VPN traffic
transmitted on the AC. Therefore, an AC on a port corresponds to all service instances on the port.
Before you configure traffic policing for an AC, use the qos car command in system view to configure
a global CAR action. For more information about CAR, see ACL and QoS Configuration Guide.
221
After you apply an inbound or outbound global CAR action in service instance view, the device
polices the inbound or outbound traffic matching the service instance according to the applied global
CAR action.
To apply a global CAR action for a service instance:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
•
2.
Enter the view of the Layer 2
Ethernet interface or Layer 2
aggregate interface
connected to a CE.
3.
Enter service instance view.
4.
Apply a global CAR action to
the inbound or outbound
traffic on the AC.
•
Enter Layer 2 Ethernet interface
view:
interface interface-type
interface-number
Enter Layer 2 aggregate
interface view:
interface bridge-aggregation
interface-number
service-instance instance-id
car { inbound | outbound } name
car-name
N/A
N/A
By default, no global CAR is
applied to an AC.
For more information about the
car command, see MPLS
Command Reference.
Enabling traffic statistics for an AC
After you create a VC for a service instance, you can perform this task to enable statistics for inbound
or outbound traffic of the AC.
To enable traffic statistics for an AC by using a service instance:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
•
2.
3.
Enter the view of the Layer 2
Ethernet interface or Layer 2
aggregate interface
connected to a CE.
•
Enter Layer 2 Ethernet
interface view:
interface interface-type
interface-number
Enter Layer 2 aggregate
interface view:
interface
bridge-aggregation
interface-number
N/A
Enter service instance view.
service-instance instance-id
N/A
By default, traffic statistics for an
AC is disabled.
4.
Enable inbound or outbound
traffic statistics for the AC.
statistics { inbound |
outbound }
222
For more information about the
statistics command, see MPLS
Command Reference.
You can view the AC statistics by
using the display mpls l2vpn fib
ac vpws command. For more
information, see MPLS Command
Reference.
Displaying and maintaining MPLS L2VPN
Task
Command
Remarks
Display information about CCC
connections.
display ccc [ ccc-name ccc-name | type
{ local | remote } ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about
specified L2VPN VC interfaces.
display l2vpn ccc-interface vc-type { all |
bgp-vc | ccc | ldp-vc | static-vc } [ up |
down ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display information about static
VCs.
display mpls static-l2vc [ interface
interface-type interface-number
[ service-instance instance-id ] ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about Martini
VCs.
display mpls l2vc [ interface interface-type
interface-number [ service-instance
instance-id ] | remote-info ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about
Kompella VCs.
display mpls l2vpn connection
[ vpn-name vpn-name [ remote-ce ce-id |
down | up | verbose ] | summary |
interface interface-type interface-number ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display information about L2VPN
in the BGP routing table.
display bgp l2vpn { all | group
[ group-name ] | peer [ [ ip-address ]
verbose ] | route-distinguisher rd [ ce-id
ce-id [ label-offset label-offset ] ] } [ | { begin
| exclude | include } regular-expression ]
Available in any view.
Display L2VPN information on a
PE.
display mpls l2vpn
[ export-route-target-list |
import-route-target-list | vpn-name
vpn-name [ local-ce | remote-ce ] ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display MPLS L2VPN AC
information.
display mpls l2vpn fib ac vpws [ interface
interface-type interface-number
[ service-instance service-instanceid ] ]
[ slot slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display MPLS L2VPN PW
information.
display mpls l2vpn fib pw vpws
[ interface interface-type interface-number
[ service-instance service-instanceid ] ]
[ slot slot-number ] [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about one or
all PW classes.
display pw-class [ pw-class-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Clear traffic statistics for service
instances.
reset service-instance statistics
[ interface interface-type interface-number
[ service-instance instance-id [ inbound |
outbound ] ] ]
Available in user view.
223
MPLS L2VPN configuration examples
This section provides examples for configuring MPLS L2VPN.
Example for configuring a remote CCC connection
Network requirements
The CEs are connected to the PEs through VLAN interfaces.
Create a remote CCC connection, so CE 1 and CE 2 can exchange Layer 2 packets across the
backbone network.
Figure 56 Network diagram
Device
Interface
IP address
Device
Interface
IP address
CE 1
Vlan-int10
100.1.1.1/24
CE 2
Vlan-int10
100.1.1.2/24
PE 1
Loop0
10.0.0.1/32
P
Loop0
10.0.0.2/32
Vlan-int30
10.1.1.1/24
Vlan-int20
10.2.2.2/24
Loop0
10.0.0.3/32
Vlan-int30
10.1.1.2/24
Vlan-int20
10.2.2.1/24
PE 2
Configuration considerations
The following steps are required:
1.
Create remote CCC connections on the PEs. No static LSP is required on the PEs.
2.
Configure two static LSPs on the P device for packets to be transferred in both directions.
Configuration procedure
1.
Configure CE 1:
# Configure an IP address for the interface connected to PE 1.
<Sysname> system-view
[Sysname] sysname CE1
[CE1] interface vlan-interface 10
[CE1-Vlan-interface10] ip address 100.1.1.1 24
2.
Configure PE 1:
# Configure the LSR ID and enable MPLS globally.
<Sysname> system-view
[Sysname] sysname PE1
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 10.0.0.1 32
224
[PE1-LoopBack0] quit
[PE1] mpls lsr-id 10.0.0.1
[PE1] mpls
[PE1-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE1] l2vpn
[PE1-l2vpn] mpls l2vpn
[PE1-l2vpn] quit
# Configure interface VLAN-interface 10.
[PE2] interface vlan-interface 10
[PE2-Vlan-interface10] quit
# Configure interface VLAN-interface 30 and enable MPLS.
[PE1] interface vlan-interface 30
[PE1-Vlan-interface30] ip address 10.1.1.1 24
[PE1-Vlan-interface30] mpls
[PE1-Vlan-interface30] quit
# Create a remote connection from CE 1 to CE 2, using the interface connected to CE 1 as the
incoming interface and that connecting the P device as the outgoing interface, setting the
incoming label to 100 and the outgoing label to 200.
[PE1] ccc ce1-ce2 interface vlan-interface 10 in-label 100 out-label 200 nexthop
10.1.1.2
3.
Configure the P device:
# Configure the LSR ID and enable MPLS globally.
<Sysname> system-view
[Sysname] sysname P
[P] interface loopback 0
[P-LoopBack0] ip address 10.0.0.2 32
[P-LoopBack0] quit
[P] mpls lsr-id 10.0.0.2
[P] mpls
[P-mpls] quit
# Configure interface VLAN-interface 30 and enable MPLS.
[P] interface vlan-interface 30
[P-Vlan-interface30] ip address 10.1.1.2 24
[P-Vlan-interface30] mpls
[P-Vlan-interface30] quit
# Configure interface VLAN-interface 20 and enable MPLS.
[P] interface vlan-interface 20
[P-Vlan-interface20] ip address 10.2.2.2 24
[P-Vlan-interface20] mpls
[P-Vlan-interface20] quit
# Create a static LSP for forwarding packets from PE 1 to PE 2.
[P] static-lsp transit pe1_pe2 incoming-interface vlan-interface 30 in-label 200
nexthop 10.2.2.1 out-label 201
# Create a static LSP for forwarding packets from PE 2 to PE 1.
[P] static-lsp transit pe2_pe1 incoming-interface vlan-interface 20 in-label 101
nexthop 10.1.1.1 out-label 100
4.
Configure PE 2:
225
# Configure the LSR ID and enable MPLS globally.
<Sysname> system-view
[Sysname] sysname PE2
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 10.0.0.3 32
[PE2-LoopBack0] quit
[PE2] mpls lsr-id 10.0.0.3
[PE2] mpls
[PE2-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE2] l2vpn
[PE2-l2vpn] mpls l2vpn
[PE2-l2vpn] quit
# Configure interface VLAN-interface 10.
[PE2] interface vlan-interface 10
[PE2-Vlan-interface10] quit
# Configure interface VLAN-interface 20 and enable MPLS.
[PE2] interface vlan-interface 20
[PE2-Vlan-interface20] ip address 10.2.2.1 24
[PE2-Vlan-interface20] mpls
[PE2-Vlan-interface20] quit
# Create a remote connection from CE 2 to CE 1, using the interface connected to CE 2 as the
incoming interface and that connecting the P device as the outgoing interface, setting the
incoming label to 201 and the outgoing label to 101.
[PE2] ccc ce2-ce1 interface vlan-interface 10 in-label 201 out-label 101 nexthop
10.2.2.2
5.
Configure CE 2:
# Configure an IP address for the interface connected to PE 2.
<Sysname> system-view
[Sysname] sysname CE2
[CE2] interface vlan-interface 10
[CE2-Vlan-interface10] ip address 100.1.1.2 24
6.
Verify the configuration:
# Display CCC connection information on PE 1. The output shows that a remote CCC
connection has been established.
[PE1] display ccc
Total
ccc vc
: 1
Local
ccc vc
: 0,
0 up
Remote ccc vc
: 1,
1 up
***Name
: ce1-ce2
Type
: remote
State
: up
Intf
: Vlan-interface10 (up)
In-label
: 100
Out-label
: 200
Nexthop
: 10.1.1.2
# Ping CE 2 from CE 1. The output shows that CE 1 and CE 2 can ping each other.
[CE1] ping 100.1.1.2
226
PING 100.1.1.2: 56
data bytes, press CTRL_C to break
Reply from 100.1.1.2: bytes=56 Sequence=1 ttl=255 time=180 ms
Reply from 100.1.1.2: bytes=56 Sequence=2 ttl=255 time=60 ms
Reply from 100.1.1.2: bytes=56 Sequence=3 ttl=255 time=10 ms
Reply from 100.1.1.2: bytes=56 Sequence=4 ttl=255 time=70 ms
Reply from 100.1.1.2: bytes=56 Sequence=5 ttl=255 time=60 ms
--- 100.1.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 10/76/180 ms
Example for configuring SVC MPLS L2VPN
Network requirements
CEs are connected to PEs through VLAN interfaces.
Establish an SVC between CE 1 and CE 2, so CE 1 and CE 2 can exchange Layer 2 packets across
the backbone.
Figure 57 Network diagram
PE 1
P
PE 2
Loop0
Loop0
Loop0
Vlan-int30
Vlan-int20
Vlan-int20
Vlan-int10
Vlan-int30
Vlan-int10
SVC
Vlan-int10
Vlan-int10
CE 2
CE 1
Device
Interface
IP address
CE 1
Vlan-int10
100.1.1.1/24
CE 2
Vlan-int10
100.1.1.2/24
PE 1
Loop0
192.2.2.2/32
P
Loop0
192.4.4.4/32
Vlan-int20
10.1.1.1/24
Vlan-int30
10.2.2.2/24
Loop0
192.3.3.3/32
Vlan-int20
10.1.1.2/24
Vlan-int30
10.2.2.1/24
PE 2
Device
Interface
IP address
Configuration considerations
The following steps are required:
1.
Configure basic MPLS settings on the PEs and P device:
Configure the LSR ID, enable MPLS and LDP, and run IGP (OSPF in this example) between PE
1, the P device, and PE 2 to establish LSPs.
2.
Configure SVC MPLS L2VPN:
Enable MPLS L2VPN on PE 1 and PE 2 and create a static VC and specify the VC labels.
Configuration procedure
1.
Configure CE 1:
227
# Configure an IP address for the interface connected to PE 1.
<Sysname> system-view
[Sysname] sysname CE1
[CE1] interface vlan-interface 10
[CE1-Vlan-interface10] ip address 100.1.1.1 24
2.
Configure PE 1:
# Configure the LSR ID and enable MPLS globally.
<Sysname> system-view
[Sysname] sysname PE1
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 192.2.2.2 32
[PE1-LoopBack0] quit
[PE1] mpls lsr-id 192.2.2.2
[PE1] mpls
[PE1-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE1] l2vpn
[PE1-l2vpn] mpls l2vpn
[PE1-l2vpn] quit
# Enable LDP globally.
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure the interface connected with the P device, and enable LDP on the interface.
[PE1] interface vlan-interface 20
[PE1-Vlan-interface20] ip address 10.1.1.1 24
[PE1-Vlan-interface20] mpls
[PE1-Vlan-interface20] mpls ldp
[PE1-Vlan-interface20] quit
# Configure OSPF on PE 1 for establishing LSPs.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 10.1.1.1 0.0.0.255
[PE1-ospf-1-area-0.0.0.0] network 192.2.2.2 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Create a static VC on the interface connected to CE 1. The interface requires no IP address.
[PE1] interface vlan-interface 10
[PE1-Vlan-interface10] mpls static-l2vc destination 192.3.3.3 transmit-vpn-label 100
receive-vpn-label 200
[PE1-Vlan-interface10] quit
3.
Configure the P device:
# Configure the LSR ID and enable MPLS globally.
<Sysname> system-view
[Sysname] sysname P
[P] interface loopback 0
[P-LoopBack0] ip address 192.4.4.4 32
[P-LoopBack0] quit
[P] mpls lsr-id 192.4.4.4
228
[P] mpls
[P-mpls] quit
# Enable LDP globally.
[P] mpls ldp
[P-mpls-ldp] quit
# Configure the interface connected with PE 1, and enable LDP on the interface.
[P] interface vlan-interface 20
[P-Vlan-interface20] ip address 10.1.1.2 24
[P-Vlan-interface20] mpls
[P-Vlan-interface20] mpls ldp
[P-Vlan-interface20] quit
# Configure the interface connected with PE 2, and enable LDP on the interface.
[P] interface vlan-interface 30
[P-Vlan-interface30] ip address 10.2.2.2 24
[P-Vlan-interface30] mpls
[P-Vlan-interface30] mpls ldp
[P-Vlan-interface30] quit
# Configure OSPF on the P device for establishing LSPs.
[P] ospf
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 10.1.1.2 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 10.2.2.2 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 192.4.4.4 0.0.0.0
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] quit
4.
Configure PE 2:
# Configure the LSR ID and enable MPLS globally.
<Sysname> system-view
[Sysname] sysname PE2
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 192.3.3.3 32
[PE2-LoopBack0] quit
[PE2] mpls lsr-id 192.3.3.3
[PE2] mpls
[PE2-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE2] l2vpn
[PE2-l2vpn] mpls l2vpn
[PE2-l2vpn] quit
# Enable LDP globally.
[PE2] mpls ldp
[PE2-mpls-ldp] quit
# Configure the interface connected with the P device, and enable LDP on the interface.
[PE2] interface vlan-interface 30
[PE2-Vlan-interface30] ip address 10.2.2.1 24
[PE2-Vlan-interface30] mpls
[PE2-Vlan-interface30] mpls ldp
229
[PE2-Vlan-interface30] quit
# Configure OSPF on PE 2 for establishing LSPs.
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1-area-0.0.0.0] network 10.2.2.1 0.0.0.255
[PE2-ospf-1-area-0.0.0.0] network 192.3.3.3 0.0.0.0
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
# Create a static VC on the interface connected to CE 2. The interface requires no IP address.
[PE2] interface vlan-interface 10
[PE2-Vlan-interface10] mpls static-l2vc destination 192.2.2.2 transmit-vpn-label 200
receive-vpn-label 100
[PE2-Vlan-interface10] quit
5.
Configure CE 2:
# Configure an IP address for the interface connected to PE 2.
<Sysname> system-view
[Sysname] sysname CE2
[CE2] interface vlan-interface 10
[CE2-Vlan-interface10] ip address 100.1.1.2 24
6.
Verify the configuration:
# Display static VC information on PE 1. The output shows that a VC has been established.
[PE1] display mpls static-l2vc
Total connections:
1,
1 up,
0 down
ce-intf
state destination
tr-label
rcv-label tnl-policy
Vlan10
up
100
200
192.3.3.3
-
# Display static VC information on PE 2. The output shows that a VC has been established.
[PE2] display mpls static-l2vc
Total connections:
1,
1 up,
0 down
ce-intf
state destination
tr-label
rcv-label tnl-policy
Vlan20
up
200
100
192.2.2.2
-
# Ping CE 2 from CE 1. The output shows that CE 1 and CE 2 can ping each other.
[CE1] ping 100.1.1.2
PING 100.1.1.2: 56
data bytes, press CTRL_C to break
Reply from 100.1.1.2: bytes=56 Sequence=1 ttl=255 time=150 ms
Reply from 100.1.1.2: bytes=56 Sequence=2 ttl=255 time=130 ms
Reply from 100.1.1.2: bytes=56 Sequence=3 ttl=255 time=130 ms
Reply from 100.1.1.2: bytes=56 Sequence=4 ttl=255 time=140 ms
Reply from 100.1.1.2: bytes=56 Sequence=5 ttl=255 time=80 ms
--- 100.1.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 80/126/150 ms
230
Example for configuring Martini MPLS L2VPN
Network requirements
CEs are connected to PEs through VLAN interfaces.
Establish a Martini VC, so CE 1 and CE 2 can exchange Layer 2 packets across the backbone.
Figure 58 Network diagram
PE 1
P
PE 2
Loop0
Loop0
Loop0
Vlan-int30
Vlan-int20
Vlan-int20
Vlan-int10
Vlan-int30
Vlan-int10
Maitini
Vlan-int10
Vlan-int10
CE 2
CE 1
Device
Interface
IP address
Device
Interface
IP address
CE 1
Vlan-int10
100.1.1.1/24
CE 2
Vlan-int10
100.1.1.2/24
PE 1
Loop0
192.2.2.2/32
P
Loop0
192.4.4.4/32
Vlan-int20
10.1.1.1/24
Vlan-int20
10.1.1.2/24
Loop0
192.3.3.3/32
Vlan-int30
10.2.2.2/24
Vlan-int30
10.2.2.1/24
PE 2
Configuration procedure
1.
Configure CE 1:
# Configure an IP address for the interface connected to PE 1.
<Sysname> system-view
[Sysname] sysname CE1
[CE1] interface vlan-interface 10
[CE1-Vlan-interface10] ip address 100.1.1.1 24
2.
Configure PE 1:
# Configure the LSR ID and enable MPLS globally.
<Sysname> system-view
[Sysname] sysname PE1
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 192.2.2.2 32
[PE1-LoopBack0] quit
[PE1] mpls lsr-id 192.2.2.2
[PE1] mpls
[PE1-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE1] l2vpn
[PE1-l2vpn] mpls l2vpn
[PE1-l2vpn] quit
# Enable LDP globally.
231
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Establish a remote session between PE 1 and PE 2.
[PE1] mpls ldp remote-peer 1
[PE1-mpls-ldp-remote-1] remote-ip 192.3.3.3
[PE1-mpls-ldp-remote-1] quit
# Configure the interface connected with the P device, and enable LDP on the interface.
[PE1] interface vlan-interface 20
[PE1-Vlan-interface20] ip address 10.1.1.1 24
[PE1-Vlan-interface20] mpls
[PE1-Vlan-interface20] mpls ldp
[PE1-Vlan-interface20] quit
# Configure OSPF on PE 1 for establishing LSPs.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 10.1.1.1 0.0.0.255
[PE1-ospf-1-area-0.0.0.0] network 192.2.2.2 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# Create a Martini VC on the interface connected to CE 1. The interface requires no IP address.
[PE1] interface vlan-interface 10
[PE1-Vlan-interface10] mpls l2vc 192.3.3.3 101
[PE1-Vlan-interface10] quit
3.
Configure the P device:
# Configure the LSR ID and enable MPLS globally.
<Sysname> system-view
[Sysname] sysname P
[P] interface loopback 0
[P-LoopBack0] ip address 192.4.4.4 32
[P-LoopBack0] quit
[P] mpls lsr-id 192.4.4.4
[P] mpls
[P-mpls] quit
# Enable LDP globally.
[P] mpls ldp
[P-mpls-ldp] quit
# Configure the interface connected with PE 1, and enable LDP on the interface.
[P] interface vlan-interface 20
[P-Vlan-interface20] ip address 10.1.1.2 24
[P-Vlan-interface20] mpls
[P-Vlan-interface20] mpls ldp
[P-Vlan-interface20] quit
# Configure the interface connected with PE 2, and enable LDP on the interface.
[P] interface vlan-interface 30
[P-Vlan-interface30] ip address 10.2.2.2 24
[P-Vlan-interface30] mpls
[P-Vlan-interface30] mpls ldp
232
[P-Vlan-interface30] quit
# Configure OSPF on the P device for establishing LSPs.
[P] ospf
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 10.1.1.2 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 10.2.2.2 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 192.4.4.4 0.0.0.0
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] quit
4.
Configure PE 2:
# Configure the LSR ID and enable MPLS globally.
<Sysname> system-view
[Sysname] sysname PE2
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 192.3.3.3 32
[PE2-LoopBack0] quit
[PE2] mpls lsr-id 192.3.3.3
[PE2] mpls
[PE2-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE2] l2vpn
[PE2-l2vpn] mpls l2vpn
[PE2-l2vpn] quit
# Enable LDP globally.
[PE2] mpls ldp
[PE2-mpls-ldp] quit
# Configure an LDP remote session between PE 2 and PE 1.
[PE2] mpls ldp remote-peer 2
[PE2-mpls-ldp-remote-2] remote-ip 192.2.2.2
[PE2-mpls-ldp-remote-2] quit
# Configure the interface connected with the P device, and enable LDP on the interface.
[PE2] interface vlan-interface 30
[PE2-Vlan-interface30] ip address 10.2.2.1 24
[PE2-Vlan-interface30] mpls
[PE2-Vlan-interface30] mpls ldp
[PE2-Vlan-interface30] quit
# Configure OSPF on PE 2 for establishing LSPs.
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1-area-0.0.0.0] network 192.3.3.3 0.0.0.0
[PE2-ospf-1-area-0.0.0.0] network 10.2.2.0 0.0.0.255
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
# Create a L2VPN connection on the interface connected to CE 2. The interface requires no IP
address.
[PE2] interface vlan-interface 10
[PE2-Vlan-interface10] mpls l2vc 192.2.2.2 101
[PE2-Vlan-interface10] quit
233
5.
Configure CE 2:
# Configure an IP address for the interface connected to PE 2.
<Sysname> system-view
[Sysname] sysname CE2
[CE2] interface vlan-interface 10
[CE2-Vlan-interface10] ip address 100.1.1.2 24
6.
Verify the configuration:
# Display VC information on PE 1. The output shows that a VC has been established.
[PE1] display mpls l2vc
Total ldp vc : 1
1 up
0 down
0 blocked
Transport
Client
Service
VC
Local
Remote
VC ID
Intf
ID
State
VC Label
VC Label
101
Vlan10
--
up
8193
8192
# Display VC information on PE 2. The output shows that a VC has been established.
[PE2] display mpls l2vc
Total ldp vc : 1
1 up
0 down
0 blocked
Transport
Client
Service
VC
Local
Remote
VC ID
Intf
ID
State
VC Label
VC Label
101
Vlan10
--
up
8192
8193
# Ping CE 2 from CE 1. The output shows that CE 1 and CE 2 can ping each other.
[CE1] ping 100.1.1.2
PING 100.1.1.2: 56
data bytes, press CTRL_C to break
Reply from 100.1.1.2: bytes=56 Sequence=1 ttl=255 time=30 ms
Reply from 100.1.1.2: bytes=56 Sequence=2 ttl=255 time=60 ms
Reply from 100.1.1.2: bytes=56 Sequence=3 ttl=255 time=50 ms
Reply from 100.1.1.2: bytes=56 Sequence=4 ttl=255 time=40 ms
Reply from 100.1.1.2: bytes=56 Sequence=5 ttl=255 time=70 ms
--- 100.1.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 30/50/70 ms
Example for configuring Kompella MPLS L2VPN
Network requirements
CEs are connected to PEs through VLAN interfaces.
Establish a Kompella VC, so CE 1 and CE 2 can exchange Layer 2 packets across the backbone.
234
Figure 59 Network diagram
P
PE 1
Loop0
PE 2
Loop0
Vlan-int30
Vlan-int20
Vlan-int20
Vlan-int10
Loop0
Vlan-int30
Vlan-int10
Kompella
Vlan-int10
Vlan-int10
CE 2
CE 1
Device
Interface
IP address
CE 1
Vlan-int10
100.1.1.1/24
PE 1
Loop0
2.2.2.2/32
Vlan-int20
PE 2
Device
Interface
IP address
CE 2
Vlan-int10
100.1.1.2/24
P
Loop0
3.3.3.3/32
10.1.1.1/24
Vlan-int20
10.1.1.2/24
Loop0
4.4.4.4/32
Vlan-int30
10.2.2.2/24
Vlan-int30
10.2.2.1/24
Configuration procedure
1.
Configure an IGP on the MPLS backbone.
This example uses OSPF. (Details not shown.)
After OSPF configuration is complete, execute the display ip routing-table command on each
LSR. You should see that the LSR has learned the routes to the LSR IDs of the other LSRs.
Execute the display ospf peer command. You should see that OSPF adjacencies have been
established and reached Full state.
2.
Configure basic MPLS and LDP to establish LDP LSPs. (Details not shown.)
After configuration, execute the display mpls ldp session and display mpls ldp peer
commands to display the LDP sessions and peer relationship established, or the display mpls
lsp command to display the LSPs established.
3.
Configure BGP L2VPN capability:
# Configure PE 1.
<Sysname> system-view
[Sysname] sysname PE1
[PE1] l2vpn
[PE1-l2vpn] mpls l2vpn
[PE1-l2vpn] quit
[PE1] bgp 100
[PE1-bgp] peer 4.4.4.4 as-number 100
[PE1-bgp] peer 4.4.4.4 connect-interface loopback 0
[PE1-bgp] l2vpn-family
[PE1-bgp-af-l2vpn] policy vpn-target
[PE1-bgp-af-l2vpn] peer 4.4.4.4 enable
[PE1-bgp-af-l2vpn] quit
[PE1-bgp] quit
# Configure PE 2.
<Sysname> system-view
[Sysname] sysname PE2
235
[PE2] l2vpn
[PE2-l2vpn] mpls l2vpn
[PE2-l2vpn] quit
[PE2] bgp 100
[PE2-bgp] peer 2.2.2.2 as-number 100
[PE2-bgp] peer 2.2.2.2 connect-interface loopback 0
[PE2-bgp] l2vpn-family
[PE2-bgp-af-l2vpn] policy vpn-target
[PE2-bgp-af-l2vpn] peer 2.2.2.2 enable
[PE2-bgp-af-l2vpn] quit
[PE2-bgp] quit
After completing the configurations, execute the display bgp l2vpn peer command on PE 1
and PE 2 to display the peer relationship established between the PEs. The peer state should
be Established. Take PE 1 as an example:
[PE1] display bgp l2vpn peer
BGP local router ID : 2.2.2.2
Local AS number : 100
Total number of peers : 1
4.
Peer
V
AS
4.4.4.4
4
100
Peers in established state : 1
MsgRcvd
MsgSent
2
OutQ PrefRcv Up/Down
5
0
0
State
00:01:07 Established
Configure the L2VPN and the CE connection:
# Configure PE 1. The configurations of the VLAN interfaces are similar to those for Martini
MPLS L2VPN and are omitted.
[PE1] mpls l2vpn vpn1 encapsulation vlan
[PE1-mpls-l2vpn-vpn1] route-distinguisher 100:1
[PE1-mpls-l2vpn-vpn1] vpn-target 1:1
[PE1-mpls-l2vpn-vpn1] ce ce1 id 1 range 10
[PE1-mpls-l2vpn-ce-vpn1-ce1] connection ce-offset 2 interface vlan-interface 10
[PE1-mpls-l2vpn-ce-vpn1-ce1] quit
[PE1-mpls-l2vpn-vpn1] quit
# Configure PE 2.
[PE2] mpls l2vpn vpn1 encapsulation vlan
[PE2-mpls-l2vpn-vpn1] route-distinguisher 100:1
[PE2-mpls-l2vpn-vpn1] vpn-target 1:1
[PE2-mpls-l2vpn-vpn1] ce ce2 id 2 range 10
[PE2-mpls-l2vpn-ce-vpn1-ce2] connection ce-offset 1 interface vlan-interface 10
[PE2-mpls-l2vpn-ce-vpn1-ce2] quit
[PE2-mpls-l2vpn-vpn1] quit
5.
Verify the configuration:
# Execute the display mpls l2vpn connection command on the PEs. The output shows that a
VC in up state has been established between the PEs. Take PE 1 as an example:
Display the MPLS L2VPN connection information on PE 1.
[PE1] display mpls l2vpn connection
1 total connections,
connections: 1 up, 0 down, 0 local, 1 remote, 0 unknown
VPN name: vpn1,
1 total connections,
connections: 1 up, 0 down, 0 local, 1 remote, 0 unknown
236
CE name: ce1, id: 1,
Rid type status peer-id
route-distinguisher
intf
2
100:1
Vlan10
rmt
up
4.4.4.4
# Ping CE 2 from CE 1. The output shows that CE 1 and CE 2 can ping each other.
[CE1] ping 100.1.1.2
PING 100.1.1.2: 56
data bytes, press CTRL_C to break
Reply from 100.1.1.2: bytes=56 Sequence=1 ttl=255 time=90 ms
Reply from 100.1.1.2: bytes=56 Sequence=2 ttl=255 time=77 ms
Reply from 100.1.1.2: bytes=56 Sequence=3 ttl=255 time=34 ms
Reply from 100.1.1.2: bytes=56 Sequence=4 ttl=255 time=46 ms
Reply from 100.1.1.2: bytes=56 Sequence=5 ttl=255 time=94 ms
--- 100.1.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 34/68/94 ms
Example for configuring a VC for a service instance
Network requirements
CE 1 and CE 2 are connected to PE 1 and PE 2 through VLAN interfaces.
On PE 1 and PE 2, create a VC for CE 1 and CE 2 in service instance view, so CE 1 and CE 2 can
exchange Layer 2 packets across the backbone.
Figure 60 Network diagram
PE 1
P
PE 2
Loop0
Loop0
Loop0
Vlan-int26
Vlan-int23
Vlan-int23
Eth1/1
Vlan-int26
Eth1/1
Maitini
Vlan-int10
Vlan-int10
CE 2
CE 1
Device
Interface
IP address
CE 1
Vlan-int10
100.1.1.1/24
CE 2
Vlan-int10
100.1.1.2/24
PE 1
Loop0
192.2.2.2/32
P
Loop0
192.4.4.4/32
Vlan-int23
23.1.1.1/24
Vlan-int23
23.1.1.2/24
Loop0
192.3.3.3/32
Vlan-int26
26.2.2.2/24
Vlan-int26
26.2.2.1/24
PE 2
Device
Interface
Configuration procedure
1.
Configure CE 1:
# Configure an IP address for the interface connected to PE 1.
<Sysname> system-view
[Sysname] sysname CE1
237
IP address
[CE1] interface vlan-interface 10
[CE1-Vlan-interface10] ip address 100.1.1.1 24
2.
Configure PE 1:
<Sysname> system-view
[Sysname] sysname PE1
[PE1] interface loopback 0
[PE1-LoopBack0] ip address 192.2.2.2 32
[PE1-LoopBack0] quit
# Configure the LSR ID and enable MPLS globally.
[PE1] mpls lsr-id 192.2.2.2
[PE1] mpls
[PE1-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE1] l2vpn
[PE1-l2vpn] mpls l2vpn
[PE1-l2vpn] quit
# Enable LDP globally.
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure PE 1 to establish an LDP remote session with PE 2.
[PE1] mpls ldp remote-peer 1
[PE1-mpls-ldp-remote-1] remote-ip 192.3.3.3
[PE1-mpls-ldp-remote-1] quit
# Configure the interface connected to the P device and enable LDP on the interface.
[PE1] interface vlan-interface 23
[PE1-Vlan-interface23] ip address 23.1.1.1 24
[PE1-Vlan-interface23] mpls
[PE1-Vlan-interface23] mpls ldp
[PE1-Vlan-interface23] quit
# Configure OSPF.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 23.1.1.1 0.0.0.255
[PE1-ospf-1-area-0.0.0.0] network 192.2.2.2 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
# On the interface connected to CE 1, create a service instance and then create a VC.
[PE1] interface gigabitethernet 1/0/1
[PE1-GigabitEthernet1/0/1] port access vlan 10
[PE1-GigabitEthernet1/0/1] service-instance 1000
[PE1-GigabitEthernet1/0/1-srv1000] encapsulation s-vid 10
[PE1-GigabitEthernet1/0/1-srv1000] xconnect peer 192.3.3.3 pw-id 1000
[PE1-GigabitEthernet1/0/1-srv1000] quit
[PE1-GigabitEthernet1/0/1] quit
3.
Configure the P device:
<Sysname> system-view
[Sysname] sysname P
238
[P] interface loopback 0
[P-LoopBack0] ip address 192.4.4.4 32
[P-LoopBack0] quit
# Configure the MPLS LSR ID and enable MPLS globally.
[P] mpls lsr-id 192.4.4.4
[P] mpls
[P-mpls] quit
# Enable LDP globally.
[P] mpls ldp
[P-mpls-ldp] quit
# Configure the interface connected with PE 1 and enable LDP on the interface.
[P] interface vlan-interface 23
[P-Vlan-interface23] ip address 23.1.1.2 24
[P-Vlan-interface23] mpls
[P-Vlan-interface23] mpls ldp
[P-Vlan-interface23] quit
# Configure the interface connected with PE 2 and enable LDP on the interface.
[P] interface vlan-interface 26
[P-Vlan-interface26] ip address 26.2.2.2 24
[P-Vlan-interface26] mpls
[P-Vlan-interface26] mpls ldp
[P-Vlan-interface26] quit
# Configure OSPF.
[P] ospf
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 23.1.1.2 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 26.2.2.2 0.0.0.255
[P-ospf-1-area-0.0.0.0] network 192.4.4.4 0.0.0.0
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] quit
4.
Configure PE 2:
<Sysname> system-view
[Sysname] sysname PE2
[PE2] interface loopback 0
[PE2-LoopBack0] ip address 192.3.3.3 32
[PE2-LoopBack0] quit
# Configure the MPLS LSR ID and enable MPLS globally.
[PE2] mpls lsr-id 192.3.3.3
[PE2] mpls
[PE2-mpls] quit
# Enable L2VPN and MPLS L2VPN.
[PE2] l2vpn
[PE2-l2vpn] mpls l2vpn
[PE2-l2vpn] quit
# Enable LDP globally.
[PE2] mpls ldp
[PE2-mpls-ldp] quit
239
# Configure PE 2 to establish a remote LDP connection with PE 1.
[PE2] mpls ldp remote-peer 2
[PE2-mpls-ldp-remote-2] remote-ip 192.2.2.2
[PE2-mpls-ldp-remote-2] quit
# Configure the interface connected to the P device and enable LDP on the interface.
[PE2] interface vlan-interface 26
[PE2-Vlan-interface26] ip address 26.2.2.1 24
[PE2-Vlan-interface26] mpls
[PE2-Vlan-interface26] mpls ldp
[PE2-Vlan-interface26] quit
# Configure OSPF.
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1-area-0.0.0.0] network 192.3.3.3 0.0.0.0
[PE2-ospf-1-area-0.0.0.0] network 26.2.2.0 0.0.0.255
[PE2-ospf-1-area-0.0.0.0] quit
[PE2-ospf-1] quit
# On the interface connected to CE 2, create a service instance and create a VC.
[PE2] interface gigabitethernet 1/0/1
[PE2-GigabitEthernet1/0/1] port access vlan 10
[PE2-GigabitEthernet1/0/1] service-instance 1000
[PE2-GigabitEthernet1/0/1-srv1000] encapsulation s-vid 10
[PE2-GigabitEthernet1/0/1-srv1000] xconnect peer 192.2.2.2 pw-id 1000
[PE2-GigabitEthernet1/0/1-srv1000] quit
[PE2-GigabitEthernet1/0/1] quit
5.
Configure CE 2:
# Configure an IP address for the interface connected to PE 2.
<Sysname> system-view
[Sysname] sysname CE2
[CE2] interface vlan-interface 10
[CE2-Vlan-interface10] ip address 100.1.1.2 24
6.
Verify the configuration:
# Display VC information on PE 1. The output shows that a VC has been established.
[PE1] display mpls l2vc
Total ldp vc : 1
1 up
0 down
0 blocked
Transport
Client
Service
VC
Local
Remote
VC ID
Intf
ID
State
VC Label
VC Label
1000
GE1/0/1
1000
up
8193
8192
# Display VC information on PE 2. The output shows that a VC has been established.
[PE2] display mpls l2vc
Total ldp vc : 1
1 up
0 down
0 blocked
Transport
Client
Service
VC
Local
Remote
VC ID
Intf
ID
State
VC Label
VC Label
1000
GE1/0/1
1000
up
8192
8193
# Ping CE 2 from CE 1. The output shows that CE 1 and CE 2 can ping each other.
[CE1] ping 100.1.1.2
240
PING 100.1.1.2: 56
data bytes, press CTRL_C to break
Reply from 100.1.1.2: bytes=56 Sequence=1 ttl=255 time=90 ms
Reply from 100.1.1.2: bytes=56 Sequence=2 ttl=255 time=77 ms
Reply from 100.1.1.2: bytes=56 Sequence=3 ttl=255 time=34 ms
Reply from 100.1.1.2: bytes=56 Sequence=4 ttl=255 time=46 ms
Reply from 100.1.1.2: bytes=56 Sequence=5 ttl=255 time=94 ms
--- 100.1.1.2 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 34/68/94 ms
Troubleshooting MPLS L2VPN
This section describes troubleshooting techniques for MPLS L2VPN.
Symptom
After the L2VPN configuration, the peer PEs cannot ping each other. The display mpls l2vc
command output shows that the VC is down and the remote VC label is invalid (displayed as --).
Analysis
The reason the VC is down might be that the PEs are configured with different encapsulation types.
Solution
•
Verify that the local PE and the peer PE are configured with the same encapsulation type.
•
Verify that the PEs are correctly configured with the remote peers.
241
Configuring MPLS L3VPN
This chapter describes only MPLS L3VPN related information. For information about basic MPLS
configuration, see "Configuring basic MPLS." For information about BGP, see Layer 3—IP Routing
Configuration Guide.
The term "router" in this document represents both routers and Layer 3 switches.
Hardware compatibility
The HPE 5820X Switch Series does not support MPLS L3VPN.
MPLS L3VPN overview
MPLS L3VPN is a PE-based L3VPN technology. It uses BGP to advertise VPN routes and uses
MPLS to forward VPN packets over service provider backbones.
MPLS L3VPN provides flexible networking modes, excellent scalability, and convenient support for
MPLS QoS and MPLS TE.
MPLS L3VPN has the following types of devices:
•
Customer edge device—A CE resides on a customer network and has one or more interfaces
directly connected to service provider networks. It can be a router, a switch, or a host. It can
neither "sense" the presence of any VPN nor does it need to support MPLS.
•
Provider edge device—A PE resides at the edge of a service provider network and connects
one or more CEs. On an MPLS network, all VPN services are processed on the PEs.
•
Provider device—A P device is a core device on a service provider network. It is not directly
connected to any CE. It has only basic MPLS forwarding capability.
Figure 61 Network diagram for MPLS L3VPN model
VPN 1
Site 1
VPN 2
Site 3
P
P
CE
CE
PE
PE
CE
P
P
PE
Site 2
VPN 2
CE
Site 4
VPN 1
CEs and PEs mark the boundary between the service providers and the customers.
242
After a CE establishes an 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 can use BGP, an IGP, or static routing
to exchange routing information.
After a PE learns VPN routing information from a CE, it uses BGP to exchange VPN routing
information to other PEs. A PE maintains routing information for only directly connected VPNs, rather
than all VPNs on the provider network.
A P router maintains only routes to PEs and does not deal with 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, and P routers function as the transit LSRs.
MPLS L3VPN concepts
This section describes concepts for MPLS L3VPN.
Site
A site has the following features:
•
A site is a group of IP systems with IP connectivity that does not rely on any service provider
network.
•
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, in most cases, adjacent to each other
geographically.
•
The devices at a site can belong to multiple VPNs, which means a site can belong to multiple
VPNs.
•
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 its address space.
The address spaces of VPNs may overlap. For example, if both VPN 1 and VPN 2 use the addresses
on subnet 10.110.10.0/24, address space overlapping occurs.
VPN instance
In MPLS VPN, routes of different VPNs are identified by VPN instances.
A PE creates and maintains a separate VPN instance for each 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 VPNs.
For independence and security of VPN data, each VPN instance on a PE maintains a routing table
and a LFIB. VPN instance information includes the LFIB, the IP routing table, the interfaces bound to
the VPN instance, and administration information for the VPN instance. The administration
information for a 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 the subnet 10.110.10.0/24 and each advertise a route to the subnet, BGP
selects only one of them, resulting in the loss of the other route.
To solve this problem, PEs use MP-BGP in VPN-IPv4 address family mode to advertise VPN routes.
243
A VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD, followed by a
four-byte IPv4 address prefix.
Figure 62 VPN-IPv4 address structure
Route Distinguisher (8 bytes)
2 bytes
Type
6 bytes
Administrator subfield
4 bytes
Assigned number subfield
IPv4 address prefix
Upon receiving an IPv4 route from a CE, a PE changes the route to a VPN route by adding an RD
and then advertises the VPN route to the peer PE. The RD ensures the uniqueness of the VPN route.
Each service provider can independently assign unique RDs. A PE can advertise routes for VPNs
even if the VPNs are from different service providers and are using the same IPv4 address space.
Configure a distinct RD for each VPN instance on a PE, so that routes to the same CE use the same
RD. The VPN-IPv4 address with an RD of 0 equals 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 AS number, in which case it is the combination of the AS number and a
discretionary number. It can also 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 one of the following formats distinguished by the Type field:
•
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.
•
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.
•
When the value of the Type field is 2, the Administrator subfield occupies four bytes, the
Assigned number subfield occupies two bytes, and the RD format is 32-bit AS number:16-bit
user-defined number, where the minimum value of the AS number is 65536. For example,
65536:1.
To guarantee global uniqueness for an RD, do not set the Administrator subfield to any private AS
number or private IP address.
BGP extended community attributes
MPLS L3VPN uses VPN route target attributes to control the advertisement of VPN routing
information.
A VPN instance on a PE supports the following types of route target attributes:
•
Export target attribute—A PE sets the export target attribute for VPN-IPv4 routes learned
from directly connected sites before advertising them to other PEs.
•
Import target attribute—A PE checks the export target attribute of VPN-IPv4 routes
advertised from 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, route target attributes define which sites can receive VPN-IPv4 routes, and from
which sites that a PE can receive routes.
Like RDs, route target attributes can be of the following formats:
•
16-bit AS number:32-bit user-defined number. For example, 100:1.
•
32-bit IPv4 address:16-bit user-defined number. For example, 172.1.1.1:1.
244
•
32-bit AS number:16-bit user-defined number, where the minimum value of the AS number is
65536. For example, 65536:1.
The Site of Origin (SoO) attribute specifies the site where the route update is originated. It prevents
the receiving router from advertising the route update back to the originating site. If the AS-path
attribute is lost, the router can use the SoO attribute to avoid routing loops.
The SoO attribute has the following formats:
•
16-bit AS number:32-bit user-defined number. For example, 100:1.
•
32-bit IPv4 address:16-bit user-defined number. For example, 172.1.1.1:1.
•
32-bit AS number:16-bit user-defined number, where the minimum value of the AS number is
65536. For example, 65536:1.
NOTE:
A route update can contain one SoO attribute at most.
MP-BGP
Multiprotocol 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 redistribution 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 route 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 an import routing policy, an export routing policy,
or both 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 for the VPN instance.
By default, only one tunnel is selected (no load balancing) in this order: LSP tunnel, CR-LSP tunnel.
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 the following
layers of labels:
•
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.
•
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 CEs belong to the same VPN and are connected to the same PE, each CE only needs to know
how to reach the other CE.
245
Figure 63 VPN packet forwarding
Site 1
CE 1
CE 2
P
2.1.1.1/24
P
PE 2
PE 1
Layer1
1.1.1.2
Site 2
Layer2
Layer2
1.1.1.2
1.1.1.2
1.1.1.2/24
1.1.1.2
A VPN packet is forwarded in the following way:
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. 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, route target attributes are used to control the advertisement and reception of VPN
routes between sites. They function 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 basic VPN networking scheme, you must assign a route target to each VPN for identifying
the export target attribute and import target attribute of the VPN. Moreover, this route target cannot
be used by any other VPNs.
246
Figure 64 Network diagram for basic VPN networking scheme
In Figure 64, for example, the route 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, you can use the hub and spoke networking scheme to
implement the monitoring and filtering of user communications.
This networking scheme requires two route targets: one for the hub and the other for the spoke.
The route target setting rules for VPN instances of all sites on PEs are as follows:
•
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.
•
On the hub PE (that is, the PE connected to the hub site), specify two 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.
247
Figure 65 Network diagram for hub and spoke networking scheme
VPN 1
Site 1
VPN 1:
Import: Hub
Export: Spoke
VPN 1-out:
Export: Hub
Spoke-CE
Hub-PE
Hub-CE
Spoke-PE
Site 3
Spoke-PE
VPN 1-in:
Import: Spoke
Spoke-CE
Site 2
VPN 1
VPN 1
VPN 1:
Import: Hub
Export: Spoke
In Figure 65, 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:
•
The hub PE can receive all VPN-IPv4 routes advertised by spoke PEs.
•
All spoke PEs can receive the VPN-IPv4 routes advertised by the hub PE.
•
The hub PE advertises the routes learned from a spoke PE to the other spoke PEs. The spoke
sites can communicate with each other through the hub site.
•
The import target attribute of any spoke PE is distinct from the export route 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
Use the extranet networking scheme 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 must access a shared site, the export target attribute and
the import target attribute of the VPN must be contained in the import target attribute and the export
target attribute of the VPN instance of the shared site.
248
Figure 66 Network diagram for extranet networking scheme
VPN 1
Site 1
VPN 1:
Import:100:1
Export:100:1
CE
PE 1
VPN 1
PE 3
CE
Site 3
PE 2
CE
Site 2
VPN 2
VPN 2:
Import:200:1
Export:200:1
VPN 1:
Import:100:1,200:1
Export:100:1,200:1
In Figure 66, VPN 1 and VPN 2 can access Site 3 of VPN 1.
•
PE 3 can receive the VPN-IPv4 routes advertised by PE 1 and PE 2.
•
PE 1 and PE 2 can receive the VPN-IPv4 routes advertised by PE 3.
•
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.
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 are not 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 for the VPNs directly connected to it,
rather than that of all VPNs. Therefore, MPLS L3VPN has excellent scalability.
The VPN routing information for a local CE is advertised in the following 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,
EBGP route, or IBGP route. No matter which routing protocol is used, the CE always advertises
standard IPv4 routes to the PE.
249
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 route targets
for these standard IPv4 routes to create VPN-IPv4 routes, save them to the routing table of the VPN
instance that is created for the CE, and then trigger MPLS to assign VPN labels for them.
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, EBGP routes, and IBGP 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.
Inter-AS VPN
In some networking scenarios, multiple sites of a VPN are connected to multiple ISPs in different
ASs, or to multiple ASs of an ISP. Such an application is called inter-AS VPN.
RFC 2547bis presents the following inter-AS VPN solutions:
•
VRF-to-VRF—ASBRs manage VPN routes between them through VLAN interfaces. This
solution is also called inter-AS option A.
•
EBGP redistribution of labeled VPN-IPv4 routes—ASBRs advertise labeled VPN-IPv4
routes to each other through MP-EBGP. This solution is also called inter-AS option B.
•
Multihop EBGP redistribution of labeled VPN-IPv4 routes—PEs advertise labeled
VPN-IPv4 routes to each other through MP-EBGP. This solution is also called inter-AS option C.
Inter-AS option A
In this 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 interfaces. 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-AS has a pair of interfaces to exchange VPN routing information.
250
Figure 67 Network diagram for inter-AS option A
Inter-AS option A 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 must manage all 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 interface for each VPN also calls for higher
performance of the PEs.
Inter-AS 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 68, 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.
For more information about RR, see Layer 3—IP Routing Configuration Guide.
The ASBRs must perform the special processing on the labeled VPN-IPv4 routes, which is also
called ASBR extension method.
251
Figure 68 Network diagram for inter-AS option B
G
M
PIB
P
G
IB
PM
PIB
G
P
P
G
IB
PM
P
M
In terms of scalability, inter-AS option B is better than option A.
When adopting the MP-EBGP method, note the following:
•
ASBRs perform no route target filtering on VPN-IPv4 routes that they receive from each other.
Therefore, the ISPs in different ASs that exchange VPN-IPv4 routes must agree on the route
exchange.
•
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-AS option C
The Inter-AS option A and option B solutions can satisfy the needs for inter-AS 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 problem is to make PEs directly exchange VPN-IPv4 routes without the
participation of ASBRs:
•
Two ASBRs advertise labeled IPv4 routes to PEs in their respective ASs through MP-IBGP.
•
The ASBRs neither maintain VPN-IPv4 routes nor advertise VPN-IPv4 routes to each other.
•
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.
•
Between PEs of different ASs, Multi-hop EBGP connections are established to exchange
VPN-IPv4 routes.
252
Figure 69 Network diagram for inter-AS option C
VPN 1
VPN 1
Multi-hop MP-EBGP
CE 1
CE 3
PE 3
G
P
P
IB
G
AS 200
P
M
P-
G
IB
IB
P-
G
M
PE 2
P-
IB
P-
AS 100
MPLS backbone
M
M
MPLS backbone
ASBR 2
ASBR 1
(PE)
(PE) EBGP
P
PE 1
PE 4
Multi-hop MP-EBGP
VPN LSP
LSP
CE 2
CE 4
VPN 2
VPN 2
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-AS
VPNv4 connection to advertise VPN-IPv4 routes.
Figure 70 Network diagram for inter-AS option C using RRs
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 redistribute the routes of the customer network
connected to a Level 2 carrier. It only redistributes the routes for delivering packets between different
sites of the Level 2 carrier. Routes of the customer networks connected to a Level 2 carrier are
exchanged through the BGP session established between the routers of the Level 2 carrier. This can
greatly reduce the number of routes maintained by the Level 1 carrier network.
253
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:
•
If the PE and the CE are in a same AS, you must configure IGP and LDP between them.
•
If the PE and the CE are not in the same AS, you must configure MP-EBGP to label the routes
exchanged between them.
In either case, you must 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 71, PE 3 and PE 4 exchange VPN routes of the Level 2 carrier
through IBGP sessions.
Figure 71 Scenario where the Level 2 carrier is an ISP
PE 1
PE 2
MP-IBGP
Level 1 carrier
CE 2
CE 1
IGP/LDP/Labeled BGP
Level 2 carrier
PE 3
IGP
IGP
Level 2 carrier
IBGP
PE 4
When the Level 2 carrier is an MPLS L3VPN service provider, its PEs must run IGP and LDP to
communicate with CEs. As shown in Figure 72, PE 3 and PE 4 exchange VPN routes of the Level 2
carrier through MP-IBGP sessions.
Figure 72 Scenario where the Level 2 carrier is an MPLS L3VPN service provider
254
NOTE:
If equal cost routes exist between the Level 1 carrier and the Level 2 carrier, Hewlett Packard
Enterprise recommends establishing equal cost LSPs between them.
Nested VPN
In an MPLS L3VPN network, generally a service provider runs an MPLS L3VPN backbone and
provides VPN services through PEs. Different sites of a VPN customer are connected to the PEs
through CEs to implement communication. In this scenario, a customer's networks are ordinary IP
networks and cannot be further divided into sub-VPNs.
However, in actual applications, customer networks can be dramatically different in form and
complexity, and a customer 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 of the following:
•
The number of VPNs that PEs must support increases sharply.
•
Any modification of an internal VPN must be done through the service provider.
The nested VPN technology offers a better solution. It exchanges VPNv4 routes between PEs and
CEs of the ISP MPLS L3VPN and allows a customer to manage its own internal VPNs. Figure 73
depicts a nested VPN network. On the service provider's MPLS VPN network, there is a customer
VPN named VPN A. The customer VPN contains two sub-VPNs, VPN A-1 and VPN A-2. The service
provider PEs treat the customer's network as a common VPN user and do not join any sub-VPNs.
The customer'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 customer network.
Figure 73 Network diagram for nested VPN
Propagation of routing information
In a nested VPN network, routing information is propagated in the following way:
1.
A provider PE and its CEs exchange VPNv4 routes, which carry information about users'
internal VPNs.
255
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 for the user is maintained on the provider PE.
3.
The provider PE advertises VPNv4 routes carrying 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 73). If a CE is connected to
a provider PE through an IPv4 connection, 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 benefits:
•
Support for VPN aggregation. It can aggregate a customer's internal VPNs into one VPN on the
service provider's MPLS VPN network.
•
Support for both symmetric networking and asymmetric networking. Sites of the same VPN can
have the same number or different numbers of internal VPNs.
•
Support for multiple levels of nesting of internal VPNs.
Nested VPN is flexible and easy to implement and can reduce the cost because a customer only
needs to pay for one MPLS VPN to have multiple internal VPNs connected. Nested VPN provides
diversified VPN networking methods for a customer, and allows for multi-level hierarchical access
control over the internal VPNs.
HoVPN
In MPLS L3VPN solutions, PEs are the key devices, which provide the following functions:
•
User access. This means that the PEs must have a large amount of interfaces.
•
VPN route managing and advertising, and user packet processing. This requires that a PE must
have a large-capacity memory and high forwarding capability.
Most of the current network schemes use the typical hierarchical architecture. For example, the MAN
architecture contains typically three layers, namely, the core layer, distribution layer, and access
layer. From the core layer to the access layer, the performance requirements on the devices
decrease while the network expands.
MPLS L3VPN, on the contrary, is a plane model where performance requirements are the same for
all PEs. If a certain PE has limited performance or scalability, the performance or scalability of the
whole network is influenced.
Due to the difference, you are faced with the scalability problem when deploying PEs at any of the
three layers. Therefore, the plane model is not applicable to the large-scale VPN deployment.
To solve the scalability problem of the plane model, MPLS L3VPN must transition to the hierarchical
model.
In MPLS L3VPN, hierarchy of VPN (HoVPN) was proposed to meet that requirement. With HoVPN,
the PE functions can be distributed among multiple PEs, which take different roles for the same
functions and form a hierarchical architecture.
As in the typical hierarchical network model, HoVPN has different requirements on the devices at
different layers of the hierarchy.
256
Implementation of HoVPN
Figure 74 Basic architecture of HoVPN
As shown in Figure 74, devices directly connected to CEs are called underlayer PEs or user-end PEs
(UPEs), whereas devices that are connected to UPEs and are in the internal network are called
superstratum PEs or service provider-end PEs (SPEs).
The hierarchical PE consists of multiple UPEs and SPEs, which function together as a traditional PE.
With the HoVPN solution, PE functions are implemented hierarchically. Hence, the solution is also
called hierarchy of PE (HoPE).
UPEs and SPEs play the following different roles:
•
A UPE allows user access. It maintains the routes of the VPN sites that are directly connected
with it, It does not maintain the routes of the remote sites in the VPN, or only maintains their
summary routes. A UPE assigns inner labels to the routes of its directly connected sites, and
advertises the labels to the SPE along with VPN routes through MP-BGP.
•
An SPE manages and advertises VPN routes. It maintains all routes of the VPNs connected
through UPEs, including the routes of both the local and remote sites. An SPE advertises routes
along with labels to UPEs, including the default routes of VPN instances or summary routes and
the routes permitted by the routing policy. By using routing policies, you can control which
nodes in a VPN can communicate with each other.
Different roles mean different requirements:
•
An SPE is required to have large-capacity routing table, high forwarding performance, and
fewer interface resources.
•
A UPE is required to have small-capacity routing table, low forwarding performance, but higher
access capability.
HoVPN makes full use of both the high performance of SPEs and the high access capability of
UPEs.
The concepts of SPE and UPE are relative. In the hierarchical PE architecture, a PE may be the SPE
of its underlayer PEs and a UPE of its SPE at the same time.
The HoPE and common PEs can coexist in an MPLS network.
SPE-UPE
The MP-BGP running between SPE and UPE can be either MP-IBGP or MP-EBGP. Which one to
use depends on whether the UPE and SPE belong to a same AS.
257
With MP-IBGP, to advertise routes between IBGP peers, the SPE acts as the RR and advertises
routes from IBGP peer UPE to IBGP peer SPE. However, it does not act as the RR of the other PEs.
Recursion and extension of HoVPN
HoVPN supports HoPE recursion:
•
A HoPE can act as a UPE to form a new HoPE with an SPE.
•
A HoPE can act as an SPE to form a new HoPE with multiple UPEs.
•
HoVPN supports multi-level recursion.
With recursion of HoPEs, a VPN, in theory, can be extended infinitely.
Figure 75 Recursion of HoPEs
Figure 75 shows a three-level HoPE. The PE in the middle is called the middle-level PE (MPE).
MP-BGP runs between SPE and MPE, and between MPE and UPE.
The term "MPE" does not really exist in a HoVPN model. It is used here just for the convenience of
description.
MP-BGP advertises all VPN routes of the UPEs to the SPEs, and advertises the default routes of the
VPN instance of the SPEs or the VPN routes permitted by the routing policies to the UPEs.
The SPE maintains the VPN routes of all sites in the HoVPN. Each UPE maintains only VPN routes
of its directly connected sites. An MPE has fewer routes than the SPE but has more routes than a
UPE.
OSPF VPN extension
This section focuses on the OSPF VPN extension. For more information about OSPF, see Layer
3—IP Routing Configuration Guide.
OSPF for VPNs on a PE
OSPF is a prevalent IGP protocol. It often runs between PE and CE to simplify CE configuration and
management because the CEs only need to support OSPF. In addition, if the customers require
MPLS L3VPN services through conventional OSPF backbone, using OSPF between PE and CE can
simplify the transition.
For OSPF to run between CE and PE, the PE must support multiple OSPF processes. Each OSPF
process must correspond to a VPN instance and have its own interface and routing table.
Details of OSPF configuration between PE and CE are describe here:
•
Configuration of OSPF areas between PE and CE
258
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). The area 0 of each VPN site must be connected to the MPLS VPN backbone
because OSPF requires that the backbone area be contiguous.
If a VPN site contains an OSPF area 0, the connected PE must be connected to the backbone
area of the VPN site through area 0. You can configure a logical connection by using a virtual
link.
•
BGP/OSPF interaction
PEs advertise VPN routes to each other through BGP and to CEs through OSPF.
Conventional OSPF considers two sites 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 more OSPF traffic and network management problems.
The extended OSPF protocol supports multiple instances to address the previous problems.
OSPF sites are considered directly connected, and PEs can exchange OSPF routing
information as they are using dedicated lines. This improves network management and makes
OSPF applications more effective.
As shown in Figure 76, PE 1 and PE 2 are connected through the MPLS backbone. CE 11, CE
21, and CE 22 belong to VPN 1. Assume that CE 11, CE 21, and CE 22 belong to the same
OSPF domain. PEs advertise VPN 1 routes in the following procedure:
a. PE 1 redistributes OSPF routes from CE 11 into BGP.
b. PE 1 advertises the VPN routes to PE 2 through BGP.
c. PE 2 redistributes the BGP VPN routes into OSPF and advertises them to CE 21 and CE
22.
Figure 76 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-AS routes).
To solve the problem, the 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.
Each OSPF domain must have a configurable domain ID. Hewlett Packard Enterprise
recommends that you configure the same domain ID or adopt the default ID for all OSPF
processes of the same VPN, so the system can know that all VPN routes with the same domain
ID are from the same VPN.
259
•
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 learned from MPLS/BGP to the VPN site through LSAs, the
LSAs can 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 learned 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 77, 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 77 Network diagram for sham link
To resolve 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 must configure it manually. In addition, the local VPN
instance must have a route to the destination of the sham link.
When configuring an OSPF sham link, redistribute OSPF VPN routes to BGP, but do not redistribute
BGP routes to OSPF to avoid routing loops.
260
BGP AS number substitution and SoO
Because 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 is 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 previous principle.
Figure 78 Application of BGP AS number substitution and SoO
CE 3
PE 1
EBGP_Update: 10.1.0.0/16
AS_PATH: 800
CE 1
AS 100
MPLS backbone
PE 2
VPNv4_Update: 10.1.0.0/16
RD: 100:1
AS_PATH: 800
AS 800
Site 1
AS 800
Site 2
EBGP_Update: 10.1.0.0/16
AS_PATH: 100, 100
CE 2
As show in Figure 78, both Site and Site 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 correctly receive the routing information from CE 1.
However, the AS number substitution function also introduces a routing loop in Site 2 because route
updates originated from CE 3 can be advertised back to Site 2 through PE 2 and CE 2. To remove
the routing loop, you can configure a routing policy on PE 2 to add the SoO attribute to route updates
received from CE 2 and CE 3 so that PE 2 does not advertise route updates from CE 3 to CE 2.
MPLS L3VPN configuration task list
Task
Remarks
Configuring basic MPLS L3VPN
By configuring basic MPLS L3VPN, you can
construct simple VPN networks over an MPLS
backbone.
Configuring inter-AS VPN
Configuring nested VPN
Configuring HoVPN
Configuring an OSPF sham link
Configuring BGP AS number substitution and SoO
261
To deploy special MPLS L3VPN networks, such as
inter-AS VPN, nested VPN, you must also perform
some specific configurations in addition to the basic
MPLS L3VPN configuration. For more information,
see the related sections.
Configuring basic MPLS L3VPN
The key task in MPLS L3VPN configuration is to manage the advertisement of VPN routes on the
MPLS backbone, including PE-CE route exchange and PE-PE route exchange.
To configure basic MPLS L3VPN:
Task
Configuring VPN instances
Remarks
Creating a VPN instance
Required.
Associating a VPN instance with
an interface
Required.
Configuring route related attributes
for a VPN instance
Optional.
Configuring a tunneling policy for a
VPN instance
Optional.
Configuring an LDP instance
Optional.
Configuring routing between PE and CE
Required.
Configuring routing between PEs
Required.
Configuring routing features for BGP VPNv4 subaddress family
Optional.
Before you configure basic MPLS L3VPN, complete the following tasks:
•
Configure an IGP for the MPLS backbone (on the PEs and Ps) to achieve IP connectivity.
•
Configure basic MPLS for the MPLS backbone.
•
Configure MPLS LDP for the MPLS backbone so that LDP LSPs can be established.
Configuring VPN instances
VPN instances isolate not only VPN routes from public network routes, but also routes among VPNs.
This feature allows VPN instances to be used in network scenarios besides MPLS L3VPNs.
All VPN instance configurations are performed on PEs or MCEs.
Creating a VPN instance
A VPN instance is associated with a site. It is a collection of the VPN membership and routing rules of
its associated site. A VPN instance does not necessarily correspond to one VPN.
To create and configure a VPN instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a VPN instance and
enter VPN instance view.
ip vpn-instance
vpn-instance-name
N/A
3.
Configure an RD for the VPN
instance.
route-distinguisher
route-distinguisher
A VPN instance takes effect only
after you configure an RD for it.
Optional.
4.
Configure a description for
the VPN instance.
description text
262
The description should contain
the VPN instance's related
information, such as its
relationship with a certain VPN.
Associating a VPN instance with an interface
After creating and configuring a VPN instance, you must associate the VPN instance with the
interface connected to the CE. Any LDP-capable interface can be associated with a VPN instance.
For information about LDP-capable interfaces, see "Configuring basic MPLS."
To associate a VPN instance with an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
By default, no VPN instance is
associated with an interface.
3.
Associate a VPN instance
with the interface.
ip binding vpn-instance
vpn-instance-name
Associating the interface with a
VPN instance clears the IP
address of the interface.
Therefore, you must reconfigure
the IP address of the interface
after executing this command.
Configuring route related attributes for a VPN instance
The device processes VPN route advertisement as follows:
•
When a VPN route learned from a site gets redistributed into BGP, BGP associates it with a
route target extended community attribute list, which is usually the export target attribute of the
VPN instance associated with the site.
•
The VPN instance determines which routes it can accept and redistribute according to the
import-extcommunity in the route target.
•
The VPN instance determines how to change the route targets attributes for routes to be
advertised according to the export-extcommunity in the route target.
To configure route related attributes for a VPN instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VPN instance view.
ip vpn-instance
vpn-instance-name
N/A
3.
Enter IPv4 VPN view.
ipv4-family
Optional.
Configure route targets.
vpn-target vpn-target&<1-8>
[ both | export-extcommunity |
import-extcommunity ]
A single vpn-target command
can configure up to eight route
targets. You can configure up to
64 route targets for a VPN
instance.
4.
Optional.
5.
Set the maximum number of
routes allowed.
routing-table limit number
{ warn-threshold | simply-alert }
263
Setting the maximum number of
routes for a VPN instance is for
preventing too many routes from
being redistributed into the PE.
Step
Command
Remarks
Optional.
6.
Apply an import routing
policy.
import route-policy route-policy
By default, all routes matching the
import target attribute are
accepted.
Make sure the routing policy
already exists. Otherwise, the
switch does not filter received
routes.
Optional.
7.
Apply an export routing
policy.
By default, routes to be advertised
are not filtered.
export route-policy route-policy
Make sure the routing policy
already exists. Otherwise, the
switch does not filter routes to be
advertised.
NOTE:
• Route related attributes configured in VPN instance view are applicable to both IPv4 VPNs and
IPv6 VPNs.
• You can configure route related attributes for IPv4 VPNs in both VPN instance view and IPv4
VPN view. Those configured in IPv4 VPN view take precedence.
Configuring a tunneling policy for a VPN instance
When multiple tunnels exist in an MPLS L3VPN network, you can configure a tunneling policy to
specify the type and number of tunnels to be used by using the tunnel select-seq command or the
preferred-path command.
With the tunnel select-seq command, you can specify the tunnel selection preference order and the
number of tunnels for load balancing.
With the preferred-path command, you can configure preferred tunnels that each correspond to a
tunnel interface.
After a tunneling policy is applied on a PE, the PE selects tunnels in this order:
•
The PE matches the peer PE address against the destination addresses of preferred tunnels,
starting from the tunnel with the smallest number. If no match is found, the local PE selects
tunnels as configured by the tunnel select-seq command or the default tunneling policy if the
tunnel select-seq command is not configured. The default tunneling policy selects only one
tunnel (no load balancing) in this order: LSP tunnel, CR-LSP tunnel.
•
If a matching tunnel is found and the tunnel is available, the local PE stops matching other
tunnels and forwards the traffic to the specified tunnel interface.
•
If the matching tunnel is unavailable (for example, the tunnel is down or the tunnel's ACL does
not permit the traffic) and is not specified with the disable-fallback keyword, the local PE
continues to match other tunnels. If the tunnel is specified with the disable-fallback keyword,
the local PE stops matching and tunnel selection fails.
IMPORTANT:
Create a tunneling policy before applying it to a VPN instance. Otherwise, the default tunneling
policy is used. The default tunneling policy selects only one tunnel (no load balancing) in this order:
LSP tunnel, CR-LSP tunnel.
To configure a tunneling policy for a VPN instance:
264
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a tunneling
policy and enter
tunneling policy view.
tunnel-policy
tunnel-policy-name
N/A
Optional.
By default, no preferred tunnel is
configured.
3.
Configure a preferred
tunnel and specify a
tunnel interface for it.
preferred-path number
interface tunnel tunnel-number
[ disable-fallback ]
In a tunneling policy, you can configure
up to 64 preferred tunnels.
The tunnel interfaces specified for the
preferred tunnels can have the same
destination address and the tunnel
encapsulation type must be MPLS TE.
Optional.
By default, only one tunnel is selected (no
load balancing) in this order: LSP tunnel,
CR-LSP tunnel.
NOTE:
•
A tunnel type closer to the
select-seq keyword has a higher
priority. For example, with the tunnel
select-seq lsp cr-lsp
load-balance-number 1 command
configured, VPN uses a CR-LSP
tunnel only when no LSP exists.
After an LSP is created, the VPN
uses the LSP tunnel instead.
•
If you specify more than one tunnel
type and the number of tunnels of a
type is less than the specified
number of tunnels for load
balancing, tunnels of different types
may be used.
Specify the tunnel
selection preference
order and the number
of tunnels for load
balancing.
tunnel select-seq { cr-lsp | lsp }
* load-balance-number number
5.
Return to system
view.
quit
N/A
6.
Enter VPN instance
view.
ip vpn-instance
vpn-instance-name
N/A
7.
Enter IPv4 VPN view.
ipv4-family
Optional.
8.
Apply the tunnel
policy to the VPN
instance.
tnl-policy tunnel-policy-name
By default, only one tunnel is selected (no
load balancing) in this order: LSP tunnel,
CR-LSP tunnel.
4.
NOTE:
• A tunneling policy configured in VPN instance view is applicable to both IPv4 VPNs and IPv6
VPNs.
• You can configure a tunneling policy for IPv4 VPNs in both VPN instance view and IPv4 VPN
view. A tunneling policy configured in IPv4 VPN view takes precedence.
Configuring an LDP instance
A LDP instance refers to an LDP-capable VPN instance. LDP instances are for carrier's carrier
network applications.
265
This task is to configure the LDP capability for an existing VPN instance, create an LDP instance for
the VPN instance, and configure LDP parameters for the LDP instance.
To configure an LDP instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable LDP for a VPN instance,
create an LDP instance, and enter
MPLS LDP VPN instance view.
mpls ldp vpn-instance
vpn-instance-name
Disabled by default.
Configure LDP parameters except
LDP GR for the instance.
For configuration information, see
"Configuring basic MPLS."
Optional.
3.
Except for the command for LDP GR, all commands available in MPLS LDP view can be configured
in MPLS LDP VPN instance view. For more information about MPLS LDP, see "Configuring basic
MPLS."
Configurations in MPLS LDP VPN instance view affect only the LDP-enabled interface bound to the
VPN instance. Configurations in MPLS LDP view do not affect interfaces bound to VPN instances.
When configuring the transport address of an LDP instance, use the IP address of the interface
bound to the VPN instance.
By default, LDP adjacencies on a private network are established by using the addresses of the
LDP-enabled interfaces, and those on the public network are established by using the LDP LSR ID.
Configuring routing between PE and CE
You can configure static routing, RIP, OSPF, IS-IS, EBGP, or IBGP between PE and CE.
Before you configure routing between PE and CE, complete the following tasks:
•
Assign an IP address to the CE-PE interface of the CE.
•
Assign an IP address to the PE-CE interface of the PE.
Configuring static routing between PE and CE
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
266
Step
Command
•
2.
Configure a static
route for a VPN
instance.
•
Remarks
Approach 1:
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 ]
Approach 2:
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 ]
Use either command as
needed.
Perform this configuration on
PEs. On CEs, configure
normal static routes.
For more information about
static routing, see Layer
3—IP Routing Configuration
Guide.
Configuring RIP between PE and CE
A RIP process belongs to the public network or a single VPN instance. If you create a RIP process
without binding it to a VPN instance, the process belongs to the public network.
For more information about RIP, see Layer 3—IP Routing Configuration Guide.
To configure RIP between PE and CE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RIP process for a
VPN instance and enter RIP
view.
rip [ process-id ] vpn-instance
vpn-instance-name
Perform this configuration on
PEs. On CEs, create a normal
RIP process.
3.
Enable RIP on the interface
attached to the specified
network.
network network-address
By default, RIP is disabled on an
interface.
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 must 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 the public network or a single VPN instance. If you create an OSPF
process without binding it to a VPN instance, the process belongs to the public network.
To configure PE-CE route exchange through OSPF:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an OSPF process for
a VPN instance and enter
the OSPF view.
ospf [ process-id | router-id
router-id | vpn-instance
vpn-instance-name ] *
Perform the configurations on
PEs. On CEs, create a normal
OSPF process.
267
Step
3.
Configure the OSPF domain
ID.
Command
Remarks
domain-id domain-id
[ secondary ]
Optional.
0 by default.
Optional.
4.
Configure the type codes of
OSPF extended community
attributes.
ext-community-type
{ domain-id type-code1 |
router-id type-code2 |
route-type type-code3 }
The defaults are as follows:
•
0x0005 for Domain ID.
•
0x0107 for Router ID.
•
0x0306 for Route Type.
Perform this configuration on
PEs.
5.
Create an OSPF area and
enter area view.
area area-id
By default, no OSPF area is
created.
6.
Enable OSPF on the
interface attached to the
specified network in the
area.
network ip-address
wildcard-mask
By default, an interface neither
belongs to any area nor runs
OSPF.
NOTE:
Deleting a VPN instance also deletes all the associated OSPF processes.
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, but 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 redistributed into BGP, the OSPF domain ID is included in the BGP VPN route and
delivered as a BGP extended community attribute.
For more information about OSPF, see Layer 3—IP Routing Configuration Guide.
Configuring IS-IS between PE and CE
An IS-IS process belongs to the public network or a single VPN instance. If you create an IS-IS
process without binding it to a VPN instance, the process belongs to the public network.
For more information about IS-IS, see Layer 3—IP Routing Configuration Guide.
To configure PE-CE route exchange through IS-IS:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IS-IS process for a
VPN instance and enter
IS-IS view.
isis [ process-id ] vpn-instance
vpn-instance-name
N/A
3.
Configure a network entity
title for the IS-IS process.
network-entity net
Not configured by default.
4.
Return to system view.
quit
N/A
5.
Enter interface view.
interface interface-type
interface-number
N/A
6.
Enable the IS-IS process on
the interface.
isis enable [ process-id ]
Disabled by default.
268
Configuring EBGP between PE and CE
1.
Configure the PE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable BGP and enter BGP
view.
bgp as-number
N/A
3.
Enter BGP VPN instance
view.
ipv4-family vpn-instance
vpn-instance-name
N/A
4.
Configure the CE as the
VPN EBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
5.
Specify the source interface
for establishing TCP
connections to the peer.
peer { group-name | ip-address }
connect-interface interface-type
interface-number
By default, BGP uses the
outgoing interface of the optimal
route to the peer as the source
interface.
6.
Redistribute the routes of the
local CEs.
import-route protocol
[ process-id ] [ med med-value |
route-policy route-policy-name ]
*
A PE must redistribute the routes
of the local CEs into its VPN
routing table so it can advertise
them to the peer PE.
7.
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 ]
8.
Configure BGP to filter
received routes.
filter-policy { acl-number |
ip-prefix ip-prefix-name } import
Optional.
By default, BGP does not filter
routes to be advertised.
Optional.
By default, BGP does not filter
received routes.
Optional.
Required for the hub and spoke
network.
9.
2.
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 ]
BGP detects routing loops by AS
number. In the hub and spoke
network scheme, 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,
you must configure this command
to allow routing loops.
Configure the CE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
269
Step
Command
Remarks
For information about BGP peer
and peer group configuration, see
Layer 3—IP Routing
Configuration Guide. This chapter
does not differentiate between
peer and peer group.
3.
Configure the PE as the
EBGP peer.
peer { group-name | ip-address }
as-number as-number
4.
Configure the route
redistribution and
advertisement behavior.
import-route protocol
[ process-id ] [ med med-value |
route-policy route-policy-name ]
*
Optional.
A CE must advertise its routes to
the connected PE so the PE can
advertise them to the peer CE.
NOTE:
• Exchange of BGP routes for a VPN instance is the same as that of ordinary BGP routes.
• The BGP configuration task in BGP-VPN instance view is the same as that in BGP view. For
more information, see Layer 3—IP Routing Configuration Guide.
Configuring IBGP between PE and CE
Use IBGP between PE and CE devices in only common MPLS L3VPN network. In networks such as
Extranet, inter-AS VPN, carrier's carrier, nested VPN, and HoVPN, you cannot use IBGP between
PE and CE devices.
1.
Configure the PE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter BGP VPN instance
view.
ipv4-family vpn-instance
vpn-instance-name
N/A
4.
Configure the CE as the
VPN IBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
5.
Specify the source interface
for establishing TCP
connections to the peer.
peer { group-name | ip-address }
connect-interface interface-type
interface-number
By default, BGP uses the
outgoing interface of the optimal
route to the peer as the source
interface.
Optional.
By default, no RR or RR client is
configured.
6.
Configure the system to be
the RR and specify the CE
as the client of the RR.
peer { group-name | ip-address }
reflect-client
By default, a PE does not
advertise routes learned from
IBGP peer CEs to IBGP peers,
including VPNv4 IBGP peers. The
PE advertises routes learned from
an IBGP peer CE to other IBGP
peers only when you configure
the IBGP peer CE as a client of
the RR.
Optional.
7.
Enable route reflection
between clients.
Enabled by default.
reflect between-clients
270
If the clients are fully meshed, you
do not need to enable route
reflection.
Step
Command
Remarks
Optional.
8.
9.
Configure the cluster ID for
the RR.
reflector cluster-id { cluster-id |
ip-address }
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 ]
10. Configure BGP to filter
received routes.
filter-policy { acl-number |
ip-prefix ip-prefix-name } import
By default, each RR in a cluster
uses its own router ID as the
cluster ID.
If more than one RR exists in a
cluster, use this command to
configure the same cluster ID for
all RRs in the cluster to avoid
routing loops.
Optional.
By default, BGP does not filter
routes to be advertised.
Optional.
By default, BGP does not filter
received routes.
You can execute the reflect between-clients command and the reflector cluster-id command in
multiple views, such as BGP-VPN instance view and BGP-VPNv4 subaddress family view. The two
commands take effect for only the RR in the view where they are executed. For RRs in other views,
they do not take effect.
Configuring an RR does not change the next hop of a route. To change the next hop of a route,
configure an inbound policy on the receiving side of the route.
2.
Configure the CE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
For information about BGP peer
and BGP peer group
configuration, see Layer 3—IP
Routing Configuration Guide. This
chapter does not differentiate
between peer and peer group.
3.
Configure the PE as the
IBGP peer.
peer { group-name | ip-address }
as-number as-number
4.
Configure the route
redistribution and
advertisement behavior.
import-route protocol
[ process-id ] [ med med-value |
route-policy route-policy-name ]
*
Optional.
A CE must advertise its routes to
the connected PE so the PE can
advertise them to the peer CE.
NOTE:
• Exchange of BGP routes of a VPN instance is the same as that of ordinary BGP routes.
• The BGP configuration task in BGP VPN instance view is the same as that in BGP view. For
more information, see Layer 3—IP Routing Configuration Guide.
Configuring routing between PEs
271
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure the remote PE as
the peer.
peer { group-name | ip-address }
as-number as-number
N/A
4.
Specify the source interface
for route updates.
peer { group-name | ip-address }
connect-interface interface-type
interface-number
By default, BGP uses the source
interface of the optimal route
update packet.
5.
Enter BGP-VPNv4
subaddress family view.
ipv4-family vpnv4
N/A
6.
Enable the exchange of
BGP-VPNv4 routing
information with the
specified peer.
peer { group-name | ip-address }
enable
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 and only takes effect for the BGP routes
in the address family view where the command is executed.
To configure common routing features for all types of subaddress families:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure the remote PE as
the peer.
peer ip-address as-number
as-number
N/A
4.
Specify the interface for TCP
connection.
peer ip-address
connect-interface interface-type
interface-number
N/A
5.
Enter address family view.
•
•
•
6.
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 ]
ipv4-family vpnv4
l2vpn-family
vpls-family
272
Use one of the commands as
needed.
For information about
BGP-L2VPN address family and
VPLS address family, see MPLS
Command Reference.
Optional.
Step
7.
8.
Command
Remarks
Enable a peer or peer group
for an address family and
enable the exchange of BGP
routing information for the
address family.
peer { group-name | ip-address }
enable
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.
Optional.
9.
Configure the system to use
the local address as the next
hop of a route to be
advertised to a specific peer
or peer group.
By default, the system uses the
local address as the next hop of a
route to be advertised to an EBGP
peer.
peer { group-name | ip-address }
next-hop-local
10. 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
11. Enable the Outbound Route
Filtering (ORF) capability for
a BGP peer or peer group.
peer { group-name | ip-address }
capability-advertise orf
ip-prefix { both | receive | send }
12. Enable route target filtering
for received VPNv4 routes.
policy vpn-target
13. Enable route reflection
between clients.
reflect between-clients
14. Specify the cluster ID of the
RR.
reflector cluster-id { cluster-id |
ip-address }
NOTE:
In the inter-AS option C solution,
configure the peer { group-name |
ip-address } next-hop-invariable
command on the RR for multi-hop
EBGP neighbors and reflector
clients to make sure the next hop
of a VPN route is not changed.
Optional.
By default, no RR or RR client is
configured.
Optional.
By default, the ORF capability is
disabled on a BGP peer or peer
group.
Optional.
Enabled by default.
Optional.
Enabled by default.
Optional.
Router ID of an RR in the cluster
by default.
Optional.
By default, an RR does not filter
the reflected routes.
15. Create an RR reflection
policy.
rr-filter
extended-community-list-number
With an RR reflection policy, only
IBGP routes whose Extended
Communities attribute matches
the specified one are reflected.
By configuring different RR
reflection policies on different
RRs, you can implement load
balancing among the RRs.
Configuring specific routing features for BGP-VPNv4 subaddress family
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
273
Step
Command
Remarks
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure the remote PE as
the peer.
peer ip-address as-number
as-number
N/A
4.
Specify the interface for TCP
connection.
peer ip-address
connect-interface interface-type
interface-number
N/A
5.
Enter BGP-VPNv4
subaddress family view.
ipv4-family vpnv4
N/A
6.
Set the default value of the
local preference.
default local-preference value
7.
Set the default value for the
system MED.
default med med-value
8.
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 ]
9.
Filter received routes.
filter-policy { acl-number |
ip-prefix ip-prefix-name } import
10. Advertise community
attributes to a peer or peer
group.
peer { group-name | ip-address }
advertise-community
By default, no community
attributes are advertised to any
peer or peer group.
11. 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.
12. Advertise a default VPN
route to a peer or peer
group.
peer { group-name | ip-address }
default-route-advertise
vpn-instance vpn-instance-name
13. Apply a filtering policy to a
peer or peer group.
peer { group-name | ip-address }
filter-policy acl-number { export
| import }
14. 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.
100 by default.
Optional.
By default, the default value of the
system MED is 0.
Optional.
By default, BGP does not filter
routes to be advertised.
Optional.
By default, BGP does not filter
received routes.
Optional.
By default, no AS filtering list is
applied to a peer or peer group.
Optional.
By default, no default VPN route
is advertised to a peer or peer
group.
Optional.
By default, no filtering policy is
applied to a peer or peer group.
Optional.
By default, no route filtering policy
based on IP prefix list is applied to
a peer or peer group.
Optional.
15. 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
By default, a device uses its
address as the next hop when
advertising a route to its EBGP
peer.
16. Specify the preference value
for the routes received from
the peer/peer group.
peer { group-name | ip-address }
preferred-value value
Optional.
274
0 by default.
Step
Command
17. Make BGP updates to be
sent carry no private AS
numbers.
peer { group-name | ip-address }
public-as-only
18. Apply a routing policy to a
peer or peer group.
peer { group-name | ip-address }
route-policy route-policy-name
{ export | import }
Remarks
Optional.
By default, a BGP update carries
private AS numbers.
Optional.
By default, no routing policy is
applied to a peer or peer group.
For information about BGP routing, see Layer 3—IP Routing Configuration Guide.
Configuring inter-AS VPN
If the MPLS backbone on which the VPN routes rely spans multiple ASs, you must configure inter-AS
VPN.
Three inter-AS VPN solutions are available. You can choose them as required.
Before you configure an inter-AS VPN, complete the following tasks:
•
Configure an IGP for the MPLS backbones in each AS to implement IP connectivity of the
backbones in the AS
•
Configure basic MPLS for the MPLS backbones of each AS
•
Configure MPLS LDP for the MPLS backbones so that LDP LSPs can be established
•
Configure 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-AS VPN solution selected.
Configuring inter-AS option A
Inter-AS option A applies to scenarios where the number of VPNs and that of VPN routes on the PEs
are relatively small. It is easy to implement.
To configure inter-AS option A, complete the following tasks:
•
Configure basic MPLS L3VPN on each AS.
•
Configure each ASBR-PE, taking the peer ASBR-PE as its CE.
In other words, configure VPN instances on PEs and ASBR PEs, respectively. The VPN instances
on PEs are used to allow CEs to access the network, and those on ASBR PEs are used to access
the peer ASBR PEs. For more information, see "Configuring basic MPLS L3VPN."
In the inter-AS option A solution, for the same VPN, the route targets configured on the PEs must
match those configured on the ASBR-PEs in the same AS to make sure VPN routes sent by the PEs
(or ASBR-PEs) can be received by the ASBR-PEs (or PEs). Route targets configured on the PEs in
different ASs do not have such requirements.
Configuring inter-AS option B
For inter-AS option B, the following configuration methods are available:
•
Do not change the next hop on an ASBR. With this method, you still must configure MPLS LDP
between ASBRs.
•
Change the next hop on an ASBR. With this method, MPLS LDP is not required between
ASBRs.
275
The device supports only the second method. Therefore, MP-EBGP routes get their next hops
changed by default before being redistributed to MP-IBGP. However, normal EBGP routes to be
advertised to IBGP do not have their next hops changed by default. To change the next hop to a local
address, use the peer { ip-address | group-name } next-hop-local command. For more information
about the command, see Layer 3—IP Routing Configuration Guide.
To configure inter-AS option B on ASBR PEs:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view for the
interface connecting to the
remote ASBR-PE.
interface interface-type
interface-number
N/A
3.
Configure the IP address of
the interface.
ip address ip-address { mask |
mask-length }
N/A
4.
Return to system view.
quit
N/A
5.
Enter BGP view.
bgp as-number
N/A
6.
Enter BGP-VPNv4
subaddress family view.
ipv4-family vpnv4
N/A
7.
Disable route target based
filtering of VPNv4 routes.
By default, a PE filters received
VPNv4 routes by route targets.
undo policy vpn-target
The routes surviving the filtering
are added to the routing table,
and the others are discarded.
In the inter-AS option B solution, the ASBR PEs must 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 route target-based filtering.
In the inter-AS option B solution, for the same VPN, the route targets for the VPN instances on the
PEs in different ASs must match.
Configuring inter-AS option C
To configure inter-AS option C, perform proper configurations on PEs and ASBR PEs, and configure
routing policies on the ASBR PEs.
Configuring the PEs
You must establish an 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.
To configure a PE for inter-AS option C:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure the ASBR PE in
the same AS as the IBGP
peer.
peer { group-name | ip-address }
as-number as-number
N/A
Enable the PE to exchange
labeled IPv4 routes with the
ASBR PE in the same AS.
peer { group-name | ip-address }
label-route-capability
By default, the device does not
advertise labeled routes to the
IPv4 peer or peer group.
4.
276
Step
Command
Remarks
5.
Configure the PE of another
AS as the EBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
6.
Enter BGP-VPNv4
subaddress family view.
ipv4-family vpnv4
N/A
7.
Enable the PE to exchange
BGP VPNv4 routing
information with the EBGP
peer.
peer { group-name | ip-address }
enable
N/A
Optional.
8.
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
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-AS option C solution, an inter-AS 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.
To configure an ASBR PE for inter-AS option C:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure each PE in the
same AS as the IBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
4.
Enable the ASBR PE to
exchange labeled IPv4
routes with the PEs in the
same AS.
peer { group-name | ip-address }
label-route-capability
By default, the device does not
advertise labeled routes to the
IPv4 peer or 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
By default, a BGP speaker does
not use its address as the next
hop when advertising a route to its
IBGP peer or peer group.
6.
Configure the remote ASBR
PE as the EBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
7.
Enable the ASBR PE to
exchange labeled IPv4
routes with the peer ASBR
PE.
peer { group-name | ip-address }
label-route-capability
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
By default, no routing policy is
applied to a peer or peer group.
5.
8.
277
Configuring the routing policy
After you configure and apply a routing policy on an ASBR PE, it does the following:
•
Assigns MPLS labels to the routes received from the PEs in the same AS before advertising
them to the peer ASBR PE.
•
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 other routes are still common IPv4 routes.
For information about routing policy configuration, see Layer 3—IP Routing Configuration Guide.
To configure a routing policy for inter-AS option C on an ASBR PE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter routing policy view.
route-policy policy-name permit
node seq-number
N/A
3.
Configure the device to
match IPv4 routes with
labels.
if-match mpls-label
N/A
Configure the device to
assign labels to IPv4 routes.
apply mpls-label
By default, an IPv4 route does not
carry any label.
4.
Configuring nested VPN
For a network with many VPNs, if you want to implement layered management of 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.
Before you configure nested VPN, configure basic MPLS L3VPN settings. For configuration
information, see "Configuring basic MPLS L3VPN."
Configuration restrictions and guidelines
•
The address ranges for sub-VPNs of a VPN cannot overlap.
•
Do not give nested VPN peers addresses that public network peers use.
•
Before specifying a nested VPN peer or peer group, configure the corresponding CE peer or
peer group in BGP VPN instance view.
•
If a CE of a sub-VPN is directly connected to a service provider's PE, policy routing must be
configured on the PE to allow mutual access between the sub-VPN and the VPN on the
backbone.
Configuration procedure
To configure nested VPN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
278
Step
Command
Remarks
3.
Enter BGP VPN instance
view.
ipv4-family vpn-instance
vpn-instance-name
N/A
4.
Configure a CE peer or peer
group.
peer { group-name |
peer-address } as-number
number
N/A
5.
Return to BGP view.
quit
N/A
6.
Enter BGP-VPNv4
subaddress family view.
ipv4-family vpnv4
N/A
7.
Enable nested VPN.
nesting-vpn
Disabled by default.
8.
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
By default, only IPv4 routes and
no BGP-VPNv4 routes can be
exchanged between nested VPN
peers/peer groups.
9.
Add a peer to the nested
VPN peer group.
peer peer-address vpn-instance
vpn-instance-name group
group-name
Optional.
10. 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, a peer is not in any
nested VPN peer group.
By default, no routing policy is
applied to routes received from a
nested VPN peer or peer group.
NOTE:
Nested VPN does not support multi-hop EBGP. A service provider PE and its peer must use the
addresses of the directly connected interfaces to establish a neighbor relationship.
Configuring HoVPN
For hierarchical VPNs, you can adopt HoVPN to reduce the performance requirements for PEs.
Before you configure HoVPN, complete basic MPLS L3VPN settings on UPE and SPE.
Do not connect an SPE to a CE directly. If an SPE must be directly connected to a CE, the VPN
instance on the SPE and that on the UPE must be configured with different RDs.
To configure HoVPN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter BGP-VPNv4
subaddress family view.
ipv4-family vpnv4
N/A
4.
Enable the exchange of
BGP-VPNv4 routing
information with a peer or
peer group.
peer { group-name | ip-address }
enable
N/A
Specify the BGP peer or
peer group as a UPE.
peer { group-name | ip-address }
upe
The default route of a VPN
instance can be advertised to only
a BGP peer or peer group that is
UPE.
5.
279
Step
6.
Advertise routes to the UPE.
Command
Remarks
•
Use either approach. Do not
configure both the peer
default-route-advertise
vpn-instance command and the
peer upe route-policy
command.
•
(Approach 1) Advertise a
default VPN route:
peer { group-name |
ip-address }
default-route-advertise
vpn-instance
vpn-instance-name
(Approach 2) Advertise
routes permitted by a routing
policy:
peer { group-name |
ip-address } upe
route-policy
route-policy-name export
By default, BGP does not
advertise routes to a VPNv4 peer.
With the peer
default-route-advertise
vpn-instance command
configured, the SPE always
advertises a default route using
the local address as the next hop
address to the UPE, regardless of
whether the default route is
present in the local routing table
or not.
Configuring an OSPF sham link
The sham link is considered an OSPF intra-area route. It is used to make sure 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.
Before you configure an OSPF sham link, complete the following tasks:
•
Configure basic MPLS L3VPN (OSPF is used between PEs and CEs).
•
Configure OSPF in the LAN where CEs reside.
Configuring a loopback interface
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a loopback interface
and enter loopback interface
view.
interface loopback
interface-number
N/A
3.
Bind the loopback interface
to a VPN instance.
ip binding vpn-instance
vpn-instance-name
By default, an interface is
associated with no VPN instance.
4.
Configure the address of the
loopback interface.
ip address ip-address { mask |
mask-length }
N/A
Redistributing the loopback interface route and OSPF routes
into BGP
280
Step
Command
1.
Enter system view.
system-view
2.
Enter BGP view.
bgp as-number
3.
Enter BGP VPN instance view.
ipv4-family vpn-instance vpn-instance-name
4.
Redistribute direct routes into BGP (to
redistribute the loopback interface route into
BGP).
import-route direct [ med med-value |
route-policy route-policy-name ] *
5.
Redistribute OSPF VPN routes.
import-route ospf [ { process-id | all-processes }
[ allow-direct | med med-value | route-policy
route-policy-name ] * ]
Creating a sham link
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter OSPF view.
ospf [ process-id | router-id
router-id | vpn-instance
vpn-instance-name ] *
N/A
3.
Configure the external route
tag for imported VPN routes.
route-tag tag-value
N/A
4.
Enter OSPF area view.
area area-id
N/A
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 ]*
By default, no sham link is
configured.
5.
If you start OSPF but do not configure the router ID, the system automatically elects one. However,
the same election rules produce the same router ID. Therefore, Hewlett Packard Enterprise
recommends that you configure the router ID when starting an OSPF process. For the election rules,
see Layer 3—IP Routing Configuration Guide.
If you configure multiple OSPF VPN instances but do not configure the route tag, the system
automatically creates one based on the AS number configured. If you do not configure BGP, the tag
is 0. However, the same calculation rule produces the same tag, and hence the same tag is created
for multiple OSPF VPN instances on the same PE or PEs with the same AS number. Therefore,
Hewlett Packard Enterprise recommends configuring different tags for different OSPF VPN
instances.
Configuring BGP AS number substitution and
SoO
When CEs at different sites have the same AS number, configure the BGP AS number substitution
function to avoid route loss.
281
With the BGP AS number substitution function, when a PE advertises a route to the specified CE, if
an AS number identical to that of the CE exists in the AS_PATH of the route, it is replaced with that of
the PE before the route is advertised.
If the PE connects to multiple CEs in the same site, use a routing policy to add the SoO attribute to
the routes received from the CEs.
Before you configure BGP AS number substitution and SoO, complete the following tasks:
•
Configure basic MPLS L3VPN.
•
Make sure CEs at different sites have the same AS number.
To configure BGP AS number substitution and SoO:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Create a routing policy and
enter routing policy view.
route-policy route-policy-name
permit node node-number
3.
Specify an SoO attribute
value.
apply extcommunity soo
site-of-origin additive
Optional.
4.
Return to system view.
quit
N/A
5.
Enter BGP view.
bgp as-number
N/A
6.
Enter BGP VPN instance
view.
ipv4-family vpn-instance
vpn-instance-name
N/A
7.
Enable the BGP AS number
substitution function.
peer { ip-address | group-name }
substitute-as
Disabled by default.
8.
Apply the routing policy to
routes received from the
specified peer.
peer { ip-address | group-name }
route-policy route-policy-name
import
Optional.
No routing policy is created by
default.
Not specified by default.
Optional.
Not applied by default.
For more information about the route-policy, apply extcommunity, peer substitute-as and peer
route-policy commands, see Layer 3—IP Routing Command Reference.
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).
Soft reset of BGP connections refers to updating BGP routing information without breaking BGP
neighbor relationships. Hard reset of BGP connections refers to updating BGP routing information by
breaking and then reestablishing BGP neighbor relationships.
To hard reset or soft reset BGP connections:
Task
Command
Remarks
Soft reset BGP connections of a
VPN instance.
refresh bgp vpn-instance
vpn-instance-name { ip-address | all |
external | group group-name } { export |
import }
Available in user view.
Soft reset BGP VPNv4
connections.
refresh bgp vpnv4 { ip-address | all |
external | group group-name | internal }
{ export | import }
282
Available in
user view.
Task
Command
Remarks
Hard 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.
Hard 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
Task
Command
Remarks
Display information about the
routing table associated with a
VPN instance.
display ip routing-table vpn-instance
vpn-instance-name [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about a
specific or all VPN instances.
display ip vpn-instance [ instance-name
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about the FIB
of a VPN instance.
display fib vpn-instance
vpn-instance-name [ acl acl-number |
ip-prefix ip-prefix-name ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about the FIB
of a VPN instance that matches
the specified destination IP
address.
display fib vpn-instance
vpn-instance-name ip-address [ mask |
mask-length ] [ | { begin | exclude |
include } regular-expression ]
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 [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about a
specific or all BGP VPNv4 peer
group.
display bgp vpnv4 { all | vpn-instance
vpn-instance-name } group [ group-name ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display information about BGP
VPNv4 routes redistributed into a
specific or all VPN instances.
display bgp vpnv4 { all | vpn-instance
vpn-instance-name } network [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display BGP VPNv4 AS path
information.
display bgp vpnv4 { all | vpn-instance
vpn-instance-name } paths
[ as-regular-expression | { | { begin |
exclude | include } regular-expression } ]
Available in any view.
display bgp vpnv4 all peer [ ip-address
verbose | verbose ] [ | { begin | exclude |
include } regular-expression ]
Display information about BGP
VPNv4 peers.
display bgp vpnv4 vpn-instance
vpn-instance-name peer [ group-name
log-info | ip-address { log-info | verbose } |
verbose ] [ | { begin | exclude | include }
regular-expression ]
283
Available in any view.
Task
Command
Remarks
Display the IP prefix information
for the ORF packets received
from the specified BGP peer.
display bgp vpnv4 { all | vpn-instance
vpn-instance-name } peer ip-address
received ip-prefix [ | { begin | exclude |
include } regular-expression ]
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-advertise |
no-export | no-export-subconfed ] *
[ whole-match ] | community-list
{ { basic-community-list-number |
comm-list-name } [ whole-match ] |
adv-community-list-number } |
different-origin-as | peer ip-address
{ advertised-routes | received-routes }
[ statistic ] | statistic ] [ | { begin | exclude
| include } regular-expression ] |
regular-expression
as-regular-expression ]
Available in any view.
Display BGP VPNv4 routing
information for a specific RD.
display bgp vpnv4 route-distinguisher
route-distinguisher routing-table
[ [ network-address [ mask | mask-length ] |
as-path-acl as-path-acl-number | cidr |
community [ aa:nn ]&<1-13>
[ no-advertise | no-export |
no-export-subconfed ] * [ whole-match ] |
community-list
{ { basic-community-list-number |
comm-list-name } [ whole-match ] |
adv-community-list-number } |
different-origin-as ] [ | { begin | exclude |
include } regular-expression ] |
regular-expression
as-regular-expression ]
Available in any view.
Display BGP VPNv4 routing
information for a specific 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-advertise |
no-export | no-export-subconfed ] *
[ whole-match ] | community-list
{ { basic-community-list-number |
comm-list-name } [ whole-match ] |
adv-community-list-number } | dampened |
dampening parameter |
different-origin-as | flap-info
[ network-address [ { mask | mask-length }
[ longer-match ] ] | as-path-acl
as-path-acl-number ] | peer ip-address
{ advertised-routes | received-routes } |
statistic ] [ | { begin | exclude | include }
regular-expression ] | [ flap-info ]
regular-expression
as-regular-expression ]
Available in any view.
Display information about OSPF
sham links.
display ospf [ process-id ] sham-link
[ area area-id ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
284
Task
Command
Remarks
Display information about a
specific or all tunnel policies.
display tunnel-policy { all | policy-name
tunnel-policy-name } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about the
specified LDP instance.
display mpls ldp vpn-instance
vpn-instance-name [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Clear the route flap dampening
information for a VPN instance.
reset bgp vpn-instance
vpn-instance-name dampening
[ network-address [ mask | mask-length ]
Available in user view.
reset bgp vpn-instance
vpn-instance-name ip-address flap-info
Clear route flap history
information about a BGP peer of a
VPN instance.
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, see Layer 3—IP Routing Command
Reference.
MPLS L3VPN configuration examples
This section provides examples on how to configure MPLS L3VPN.
Configuring MPLS L3VPNs using EBGP between PE and CE
Network requirements
CE 1 and CE 3 belong to VPN 1. CE 2 and CE 4 belong to VPN 2.
VPN 1 uses route target attribute 111:1. VPN 2 uses route target attribute 222:2. Users of different
VPNs cannot access each other.
EBGP is used to exchange VPN routing information between CE and PE.
PEs use OSPF to communicate with each other and use MP-IBGP to exchange VPN routing
information.
285
Figure 79 Network diagram
Device
Interface
IP address
Device
Interface
IP address
CE 1
Vlan-int11
10.1.1.1/24
P
Loop0
2.2.2.9/32
PE 1
Loop0
1.1.1.9/32
Vlan-int12
172.2.1.1/24
Vlan-int11
10.1.1.2/24
Vlan-int13
172.1.1.2/24
Vlan-int13
172.1.1.1/24
Loop0
3.3.3.9/32
PE 2
Vlan-int12
10.2.1.2/24
Vlan-int12
172.2.1.2/24
CE 2
Vlan-int12
10.2.1.1/24
Vlan-int11
10.3.1.2/24
CE 3
Vlan-int11
10.3.1.1/24
Vlan-int13
10.4.1.2/24
CE 4
Vlan-int13
10.4.1.1/24
Configuration procedure
1.
Configure an IGP on the MPLS backbone to ensure IP connectivity within the backbone:
# 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 13
[PE1-Vlan-interface13] ip address 172.1.1.1 24
[PE1-Vlan-interface13] 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
286
[P-LoopBack0] quit
[P] interface vlan-interface 13
[P-Vlan-interface13] ip address 172.1.1.2 24
[P-Vlan-interface13] quit
[P] interface vlan-interface 12
[P-Vlan-interface12] ip address 172.2.1.1 24
[P-Vlan-interface12] 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 12
[PE2-Vlan-interface12] ip address 172.2.1.2 24
[PE2-Vlan-interface12] 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
# On PE 1, verify that the PEs have learned the routes to the loopback interfaces of each other.
[PE1] display ip routing-table
Routing Tables: Public
Destinations : 8
Destination/Mask
Proto
1.1.1.9/32
2.2.2.9/32
Pre
Routes : 8
Cost
NextHop
Interface
Direct 0
0
127.0.0.1
InLoop0
OSPF
10
1
172.1.1.2
Vlan13
3.3.3.9/32
OSPF
10
2
172.1.1.2
Vlan13
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
Vlan13
172.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
172.2.1.0/24
OSPF
1
172.1.1.2
Vlan13
10
# On PE 1, verify that OSPF adjacencies in Full state have been established between PE 1, P,
and PE 2.
[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-interface13)'s neighbors
Router ID: 172.1.1.2
Address: 172.1.1.2
287
GR State: Normal
State: Full
Mode:Nbr is
DR: 172.1.1.1
Master
BDR: 172.1.1.2
Dead timer due in 38
Priority: 1
MTU: 0
sec
Neighbor is up for 00:02:44
Authentication Sequence: [ 0 ]
Neighbor state change count: 5
2.
Configure basic MPLS 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 13
[PE1-Vlan-interface13] mpls
[PE1-Vlan-interface13] mpls ldp
[PE1-Vlan-interface13] 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 13
[P-Vlan-interface13] mpls
[P-Vlan-interface13] mpls ldp
[P-Vlan-interface13] quit
[P] interface vlan-interface 12
[P-Vlan-interface12] mpls
[P-Vlan-interface12] mpls ldp
[P-Vlan-interface12] 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 12
[PE2-Vlan-interface12] mpls
[PE2-Vlan-interface12] mpls ldp
[PE2-Vlan-interface12] quit
# On PE 1, verify that LDP sessions in Operational state have been established between PE 1,
P, and PE 2.
[PE1] display mpls ldp session
LDP Session(s) in Public Network
Total number of sessions: 1
---------------------------------------------------------------Peer-ID
Status
LAM
288
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
# On PE 1, verify that the LSPs have been established by LDP.
[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
-------/InLoop0
2
2.2.2.9/32
NULL/3
172.1.1.2
-------/Vlan-interface13
3
3.3.3.9/32
NULL/1024
172.1.1.2
-------/Vlan-interface13
-----------------------------------------------------------------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:
# 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 11
[PE1-Vlan-interface11] ip binding vpn-instance vpn1
[PE1-Vlan-interface11] ip address 10.1.1.2 24
[PE1-Vlan-interface11] quit
[PE1] interface vlan-interface 12
[PE1-Vlan-interface12] ip binding vpn-instance vpn2
[PE1-Vlan-interface12] ip address 10.2.1.2 24
[PE1-Vlan-interface12] 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 11
[PE2-Vlan-interface11] ip binding vpn-instance vpn1
[PE2-Vlan-interface11] ip address 10.3.1.2 24
[PE2-Vlan-interface11] quit
[PE2] interface vlan-interface 13
289
[PE2-Vlan-interface13] ip binding vpn-instance vpn2
[PE2-Vlan-interface13] ip address 10.4.1.2 24
[PE2-Vlan-interface13] quit
# Configure IP addresses for the CEs according to Figure 79. (Details not shown.)
# Execute the display ip vpn-instance command on the PEs to display the configuration of the
VPN instance, for example, on PE 1.
[PE1] display ip vpn-instance
Total VPN-Instances configured : 2
VPN-Instance Name
RD
Create time
vpn1
100:1
2009/01/22 13:02:21
vpn2
100:2
2009/01/22 13:02:40
# Use the ping command on the PEs to verify that the PEs can ping their attached CEs, for
example, on PE 1.
[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 relationships between PEs and CEs to allow VPN routes to be
redistributed:
# 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
# Configure the other three CEs in the same way that CE 1 is configured. (Details not shown.)
# 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
# Configure PE 2 in the same way that PE 1 is configured. (Details not shown.)
290
# Execute the display bgp vpnv4 vpn-instance peer command on the PEs. This example
uses PE 1 to verify that a BGP peer relationship in Established state has been established
between a PE and a CE.
[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
5.
Peer
AS
MsgRcvd
10.1.1.1
65410
Peers in established state : 1
MsgSent
11
OutQ
9
PrefRcv
0
Up/Down
1
State
00:06:37
Established
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
# Execute the display bgp peer command on the PEs. This example uses PE 1 to verify that a
BGP peer relationship in Established state has been established between the PEs.
[PE1] display bgp peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
6.
Peer
AS
3.3.3.9
100
MsgRcvd
Peers in established state : 1
MsgSent
2
OutQ
6
PrefRcv
0
0
Up/Down
State
00:00:12 Established
Verify the configuration:
# Execute the display ip routing-table vpn-instance command on the PEs. This example
uses PE 1 to verify that the PEs have the routes to the CEs.
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 5
Destination/Mask
Proto
10.1.1.0/24
10.1.1.2/32
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
10.1.1.2
Vlan11
Direct 0
0
127.0.0.1
InLoop0
10.3.1.0/24
BGP
0
3.3.3.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
255
[PE1] display ip routing-table vpn-instance vpn2
291
Routing Tables: vpn2
Destinations : 5
Routes : 5
Destination/Mask
Proto
Cost
NextHop
Interface
10.2.1.0/24
Direct 0
Pre
0
10.2.1.2
Vlan12
10.2.1.2/32
Direct 0
0
127.0.0.1
InLoop0
10.4.1.0/24
BGP
0
3.3.3.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
255
# Verify that CEs of the same VPN can ping each other. Those of different VPNs cannot ping
each other. For example, CE 1 can ping CE 3 (10.3.1.1) but cannot ping 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
Configuring MPLS L3VPNs using IBGP between PE and CE
Network requirements
CE 1 and CE 3 belong to VPN 1. CE 2 and CE 4 belong to VPN 2.
VPN 1 uses route target attribute 111:1. VPN 2 uses route target attribute 222:2. Users of different
VPNs cannot access each other.
IBGP is used to exchange VPN routing information between CE and PE.
PEs use OSPF to communicate with each other and use MP-IBGP to exchange VPN routing
information.
292
Figure 80 Network diagram
Device
Interface
IP address
Device
Interface
IP address
PE 1
Loop0
1.1.1.9/32
PE 2
Loop0
3.3.3.9/32
CE 1
CE 2
CE 3
Vlan-int11
10.1.1.2/24
Vlan-int12
172.2.1.2/24
Vlan-int13
172.1.1.1/24
Vlan-int11
10.3.1.2/24
Vlan-int12
10.2.1.2/24
Vlan-int13
10.4.1.2/24
Loop0
4.4.4.9/32
Loop0
2.2.2.9/32
Vlan-int11
10.1.1.1/24
P
Vlan-int12
172.2.1.1/24
Loop0
5.5.5.9/32
Vlan-int13
172.1.1.2/24
Vlan-int12
10.2.1.1/24
Loop0
6.6.6.9/32
Vlan-int11
10.3.1.1/24
CE 4
Loop0
7.7.7.9/32
Vlan-int13
10.4.1.1/24
Configuration procedure
1.
Configure an IGP on the MPLS backbone to ensure IP connectivity within the backbone:
# 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 13
[PE1-Vlan-interface13] ip address 172.1.1.1 24
[PE1-Vlan-interface13] 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 switch.
293
<P> system-view
[P] interface loopback 0
[P-LoopBack0] ip address 2.2.2.9 32
[P-LoopBack0] quit
[P] interface vlan-interface 13
[P-Vlan-interface13] ip address 172.1.1.2 24
[P-Vlan-interface13] quit
[P] interface vlan-interface 12
[P-Vlan-interface12] ip address 172.2.1.1 24
[P-Vlan-interface12] 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 12
[PE2-Vlan-interface12] ip address 172.2.1.2 24
[PE2-Vlan-interface12] 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
# On PE 1, verify that the PEs have learned the routes to the loopback interfaces of each other.
[PE1] display ip routing-table
Routing Tables: Public
Destinations : 8
Pre
Routes : 8
Destination/Mask
Proto
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
Vlan13
3.3.3.9/32
OSPF
10
2
172.1.1.2
Vlan13
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
Vlan13
172.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
172.2.1.0/24
OSPF
1
172.1.1.2
Vlan13
10
# On PE 1, verify that OSPF adjacencies in Full state have been established between PE 1, P,
and PE 2.
[PE1] display ospf peer verbose
OSPF Process 1 with Router ID 1.1.1.9
294
Neighbors
Area 0.0.0.0 interface 172.1.1.1(Vlan-interface13)'s neighbors
Router ID: 172.1.1.2
State: Full
Address: 172.1.1.2
Mode:Nbr is
DR: 172.1.1.1
Master
BDR: 172.1.1.2
Dead timer due in 38
GR State: Normal
Priority: 1
MTU: 0
sec
Neighbor is up for 00:02:44
Authentication Sequence: [ 0 ]
Neighbor state change count: 5
2.
Configure basic MPLS 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 13
[PE1-Vlan-interface13] mpls
[PE1-Vlan-interface13] mpls ldp
[PE1-Vlan-interface13] quit
# Configure the P switch.
[P] mpls lsr-id 2.2.2.9
[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
[P] interface vlan-interface 13
[P-Vlan-interface13] mpls
[P-Vlan-interface13] mpls ldp
[P-Vlan-interface13] quit
[P] interface vlan-interface 12
[P-Vlan-interface12] mpls
[P-Vlan-interface12] mpls ldp
[P-Vlan-interface12] 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 12
[PE2-Vlan-interface12] mpls
[PE2-Vlan-interface12] mpls ldp
[PE2-Vlan-interface12] quit
# On PE 1, verify that LDP sessions in Operational state have been established between PE 1,
P, and PE 2.
[PE1] display mpls ldp session
LDP Session(s) in Public Network
295
Total number of sessions: 1
---------------------------------------------------------------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
# On PE 1, verify that the LSPs have been established by LDP.
[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
-------/InLoop0
2
2.2.2.9/32
NULL/3
172.1.1.2
-------/Vlan-interface13
3
3.3.3.9/32
NULL/1024
172.1.1.2
-------/Vlan-interface13
-----------------------------------------------------------------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:
# 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 11
[PE1-Vlan-interface11] ip binding vpn-instance vpn1
[PE1-Vlan-interface11] ip address 10.1.1.2 24
[PE1-Vlan-interface11] quit
[PE1] interface vlan-interface 12
[PE1-Vlan-interface12] ip binding vpn-instance vpn2
[PE1-Vlan-interface12] ip address 10.2.1.2 24
[PE1-Vlan-interface12] 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 11
[PE2-Vlan-interface11] ip binding vpn-instance vpn1
296
[PE2-Vlan-interface11] ip address 10.3.1.2 24
[PE2-Vlan-interface11] quit
[PE2] interface vlan-interface 13
[PE2-Vlan-interface13] ip binding vpn-instance vpn2
[PE2-Vlan-interface13] ip address 10.4.1.2 24
[PE2-Vlan-interface13] quit
# Configure IP addresses for the CEs according to in Figure 80. (Details not shown.)
# Execute the display ip vpn-instance command on the PEs to display the configuration of the
VPN instance, for example, on PE 1.
[PE1] display ip vpn-instance
Total VPN-Instances configured : 2
VPN-Instance Name
RD
Create time
vpn1
100:1
2009/01/22 13:02:21
vpn2
100:2
2009/01/22 13:02:40
# Use the ping command on the PEs to verify that the PEs can ping their attached CEs, for
example, on PE 1.
[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 IBGP peer relationships between PEs and CEs to redistribute VPN routes, and
configure routing policies to change the next hop of the routes:
# On CE 1, configure PE 1 as the IBGP peer, and configure a routing policy for the routes
received from PE 1, changing the next hop address of the routes to the IP address of PE 1.
<CE1> system-view
[CE1] route-policy ce-ibgp permit node 0
[CE1-route-policy] apply ip-address next-hop 10.1.1.2
[CE1-route-policy] quit
[CE1] bgp 100
[CE1-bgp] peer 10.1.1.2 as-number 100
[CE1-bgp] peer 10.1.1.2 route-policy ce-ibgp import
[CE1-bgp] import-route direct
[CE1-bgp] quit
# Configure the other three CEs (CE 2 through CE 4) in the same way that CE 1 is configured.
(Details not shown.)
# On PE 1, configure the CE 1 and CE 2 as the IBGP peers, and configure PE 1 as the route
reflector.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] peer 10.1.1.1 as-number 100
297
[PE1-bgp-vpn1] peer 10.1.1.1 reflect-client
[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 100
[PE1-bgp-vpn2] peer 10.2.1.1 reflect-client
[PE1-bgp-vpn2] import-route direct
[PE1-bgp-vpn2] quit
[PE1-bgp] quit
# Configure PE 2 in the same way that PE 1 is configured. (Details not shown.)
# Execute the display bgp vpnv4 vpn-instance peer command on the PEs. This example
uses PE 1 to verify that a BGP peer relationship in Established state has been established
between a PE and a CE.
[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
Peer
10.1.1.1
5.
Peers in established state : 1
AS
MsgRcvd
100
26
MsgSent OutQ PrefRcv Up/Down
21
0
State
2 00:11:08 Established
Configure an MP-IBGP peer relationship between PEs:
# On PE 1, configure PE 2 as the MP-IBGP peer, and configure a routing policy for the routes
received from PE 2, changing the next hop address of the routes as the loopback interface
address of PE 2.
[PE1] route-policy pe-ibgp permit node 0
[PE1-route-policy] apply ip-address next-hop 3.3.3.9
[PE1-route-policy] quit
[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] peer 3.3.3.9 route-policy pe-ibgp import
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
# On PE 2, configure PE 1 as the MP-IBGP peer, and configure a routing policy for the routes
received from PE 1, changing the next hop address of the routes as the loopback interface
address of PE 1.
[PE2] route-policy pe-ibgp permit node 0
[PE2-route-policy] apply ip-address next-hop 1.1.1.9
[PE2-route-policy] quit
[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] peer 1.1.1.9 route-policy pe-ibgp import
298
[PE2-bgp-af-vpnv4] quit
[PE2-bgp] quit
# Execute the display bgp peer command on the PEs. This example uses PE 1 to verify that a
BGP peer relationship in Established state has been established between the PEs.
[PE1] display bgp peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peer
3.3.3.9
6.
Peers in established state : 1
AS
MsgRcvd
100
4
MsgSent OutQ PrefRcv Up/Down
8
0
State
0 00:00:09 Established
Verify the configuration:
# Execute the display ip routing-table vpn-instance command on the PEs. This example
uses PE 1 to verify that the PEs have the routes to the CEs.
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 7
Routes : 7
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
4.4.4.9/32
BGP
255
0
10.1.1.1
Vlan11
6.6.6.9/32
BGP
255
0
3.3.3.9
NULL0
10.1.1.0/24
Direct 0
0
10.1.1.2
Vlan11
10.1.1.2/32
Direct 0
0
127.0.0.1
InLoop0
10.3.1.0/24
BGP
0
3.3.3.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
255
[PE1] display ip routing-table vpn-instance vpn2
Routing Tables: vpn2
Destinations : 5
Routes : 5
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
5.5.5.9/32
BGP
255
0
10.2.1.1
Vlan12
7.7.7.9/32
BGP
255
0
3.3.3.9
NULL0
10.2.1.0/24
Direct 0
0
10.2.1.2
Vlan12
10.2.1.2/32
Direct 0
0
127.0.0.1
InLoop0
10.4.1.0/24
BGP
0
3.3.3.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
255
# Verify that CEs of the same VPN can ping each other. Those of different VPNs cannot ping
each other. For example, CE 1 can ping CE 3 (6.6.6.9), but cannot ping CE 4 (7.7.7.9).
[CE1] ping 6.6.6.9
PING 6.6.6.9: 56
data bytes, press CTRL_C to break
Reply from 6.6.6.9: bytes=56 Sequence=1 ttl=253 time=72 ms
Reply from 6.6.6.9: bytes=56 Sequence=2 ttl=253 time=34 ms
Reply from 6.6.6.9: bytes=56 Sequence=3 ttl=253 time=50 ms
Reply from 6.6.6.9: bytes=56 Sequence=4 ttl=253 time=50 ms
Reply from 6.6.6.9: bytes=56 Sequence=5 ttl=253 time=34 ms
--- 6.6.6.9 ping statistics ---
299
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 34/48/72 ms
[CE1] ping 7.7.7.9
PING 7.7.7.9: 56
data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 7.7.7.9 ping statistics --5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
Configuring a hub-spoke network
Network requirements
The spoke-CEs are not permitted to communicate with each other directly. Data transmission
between them depends on the hub-CE.
Configure EBGP to exchange VPN routing information between spoke-CE and spoke-PE, and
between hub-CE and hub-PE.
Configure OSPF between spoke-PE and hub-PE to ensure IP connectivity between PEs, and
configure MP-IBGP to exchange VPN routing information.
Figure 81 Network diagram
Device
Interface
IP address
Device
Interface
IP address
Spoke-CE 1
Vlan-int2
10.1.1.1/24
Hub-CE
Vlan-int6
10.3.1.1/24
Spoke-PE 1
Loop0
1.1.1.9/32
Vlan-int7
10.4.1.1/24
Vlan-int2
10.1.1.2/24
Loop0
2.2.2.9/32
Hub-PE
300
Vlan-int4
172.1.1.1/24
Vlan-int4
172.1.1.2/24
Spoke-CE 2
Vlan-int3
10.2.1.1/24
Vlan-int5
172.2.1.2/24
Spoke-PE 2
Loop0
3.3.3.9/32
Vlan-int6
10.3.1.2/24
Vlan-int3
10.2.1.2/24
Vlan-int7
10.4.1.2/24
Vlan-int5
172.2.1.1/24
Configuration procedure
1.
Configure an IGP in the MPLS backbone to ensure IP connectivity between spoke-PE and
hub-PE:
# Configure Spoke-PE 1.
<Spoke-PE1> system-view
[Spoke-PE1] interface loopback 0
[Spoke-PE1-LoopBack0] ip address 1.1.1.9 32
[Spoke-PE1-LoopBack0] quit
[Spoke-PE1] interface vlan-interface 4
[Spoke-PE1-Vlan-interface4] ip address 172.1.1.1 24
[Spoke-PE1-Vlan-interface4] quit
[Spoke-PE1] ospf
[Spoke-PE1-ospf-1] area 0
[Spoke-PE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[Spoke-PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[Spoke-PE1-ospf-1-area-0.0.0.0] quit
[Spoke-PE1-ospf-1] quit
# Configure Spoke-PE 2.
<Spoke-PE2> system-view
[Spoke-PE2] interface loopback 0
[Spoke-PE2-LoopBack0] ip address 3.3.3.9 32
[Spoke-PE2-LoopBack0] quit
[Spoke-PE2] interface vlan-interface 5
[Spoke-PE2-Vlan-interface5] ip address 172.2.1.1 24
[Spoke-PE2-Vlan-interface5] quit
[Spoke-PE2] ospf
[Spoke-PE2-ospf-1] area 0
[Spoke-PE2-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255
[Spoke-PE2-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0
[Spoke-PE2-ospf-1-area-0.0.0.0] quit
[Spoke-PE2-ospf-1] quit
# Configure the Hub-PE.
<Hub-PE> system-view
[Hub-PE] interface loopback 0
[Hub-PE-LoopBack0] ip address 2.2.2.9 32
[Hub-PE-LoopBack0] quit
[Hub-PE] interface vlan-interface 4
[Hub-PE-Vlan-interface4] ip address 172.1.1.2 24
[Hub-PE-Vlan-interface4] quit
[Hub-PE] interface vlan-interface 5
[Hub-PE-Vlan-interface5] ip address 172.2.1.2 24
[Hub-PE-Vlan-interface5] quit
301
[Hub-PE] ospf
[Hub-PE-ospf-1] area 0
[Hub-PE-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[Hub-PE-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255
[Hub-PE-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0
[Hub-PE-ospf-1-area-0.0.0.0] quit
[Hub-PE-ospf-1] quit
# On Spoke-PE 1, verify that the PEs have learned the routes to the loopback interfaces of each
other.
[Spoke-PE1] display ip routing-table
Routing Tables: Public
Destinations : 10
Destination/Mask
Proto
1.1.1.9/32
2.2.2.9/32
Routes : 10
Pre
Cost
NextHop
Interface
Direct 0
0
127.0.0.1
InLoop0
OSPF
10
1
172.1.1.2
Vlan4
3.3.3.9/32
OSPF
10
2
172.1.1.2
Vlan4
10.1.1.0/24
Direct 0
0
10.1.1.2
Vlan2
10.1.1.2/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
172.1.1.0/24
Direct 0
0
172.1.1.1
Vlan4
172.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
172.2.1.0/24
OSPF
1
172.1.1.2
Vlan4
10
# On Spoke-PE 1, verify that OSPF adjacencies in Full state have been established between
Spoke-PE 1, Hub-PE, and Spoke-PE 2.
[Spoke-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-interface4)'s neighbors
Router ID: 2.2.2.9
State: Full
Address: 172.1.1.2
Mode:Nbr is
DR: 172.1.1.1
Master
BDR: 172.1.1.2
Dead timer due in 38
GR State: Normal
Priority: 1
MTU: 0
sec
Neighbor is up for 00:02:44
Authentication Sequence: [ 0 ]
Neighbor state change count: 5
2.
Configure basic MPLS and MPLS LDP in the MPLS backbone to establish LDP LSPs:
# Configure Spoke-PE 1.
[Spoke-PE1] mpls lsr-id 1.1.1.9
[Spoke-PE1] mpls
[Spoke-PE1-mpls] quit
[Spoke-PE1] mpls ldp
[Spoke-PE1-mpls-ldp] quit
[Spoke-PE1] interface vlan-interface 4
[Spoke-PE1-Vlan-interface4] mpls
[Spoke-PE1-Vlan-interface4] mpls ldp
302
[Spoke-PE1-Vlan-interface4] quit
# Configure Spoke-PE 2.
[Spoke-PE2] mpls lsr-id 3.3.3.9
[Spoke-PE2] mpls
[Spoke-PE2-mpls] quit
[Spoke-PE2] mpls ldp
[Spoke-PE2-mpls-ldp] quit
[Spoke-PE2] interface vlan-interface 5
[Spoke-PE2-Vlan-interface5] mpls
[Spoke-PE2-Vlan-interface5] mpls ldp
[Spoke-PE2-Vlan-interface5] quit
# Configure the Hub-PE.
[Hub-PE] mpls lsr-id 2.2.2.9
[Hub-PE] mpls
[Hub-PE-mpls] quit
[Hub-PE] mpls ldp
[Hub-PE-mpls-ldp] quit
[Hub-PE] interface vlan-interface 4
[Hub-PE-Vlan-interface4] mpls
[Hub-PE-Vlan-interface4] mpls ldp
[Hub-PE-Vlan-interface4] quit
[Hub-PE] interface vlan-interface 5
[Hub-PE-Vlan-interface5] mpls
[Hub-PE-Vlan-interface5] mpls ldp
[Hub-PE-Vlan-interface5] quit
# On Spoke-PE 1, verify that LDP sessions in Operational state have been established
between Spoke-PE 1 and Hub-PE, and Spoke-PE 2.
[Spoke-PE1] display mpls ldp session
LDP Session(s) in Public Network
Total number of sessions: 1
---------------------------------------------------------------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
# On Spoke-PE 1, verify that the LSPs have been established by LDP.
[Spoke-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
-------/InLoop0
2
2.2.2.9/32
NULL/3
172.1.1.2
-------/Vlan-interface4
3
3.3.3.9/32
NULL/1024
172.1.1.2
-------/Vlan-interface4
-----------------------------------------------------------------A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
303
3.
Configure VPN instances on the spoke-PEs and the hub-PE to allow CEs to access the PEs:
# Configure Spoke-PE 1.
[Spoke-PE1] ip vpn-instance vpn1
[Spoke-PE1-vpn-instance-vpn1] route-distinguisher 100:1
[Spoke-PE1-vpn-instance-vpn1] vpn-target 111:1 import-extcommunity
[Spoke-PE1-vpn-instance-vpn1] vpn-target 222:2 export-extcommunity
[Spoke-PE1-vpn-instance-vpn1] quit
[Spoke-PE1] interface vlan-interface 2
[Spoke-PE1-Vlan-interface2] ip binding vpn-instance vpn1
[Spoke-PE1-Vlan-interface2] ip address 10.1.1.2 24
[Spoke-PE1-Vlan-interface2] quit
# Configure the Spoke-PE 2.
[Spoke-PE2] ip vpn-instance vpn1
[Spoke-PE2-vpn-instance-vpn1] route-distinguisher 100:2
[Spoke-PE2-vpn-instance-vpn1] vpn-target 111:1 import-extcommunity
[Spoke-PE2-vpn-instance-vpn1] vpn-target 222:2 export-extcommunity
[Spoke-PE2-vpn-instance-vpn1] quit
[Spoke-PE2] interface vlan-interface 3
[Spoke-PE2-Vlan-interface3] ip binding vpn-instance vpn1
[Spoke-PE2-Vlan-interface3] ip address 10.2.1.2 24
[Spoke-PE2-Vlan-interface3] quit
# Configure the Hub-PE.
[Hub-PE] ip vpn-instance vpn1-in
[Hub-PE-vpn-instance-vpn1-in] route-distinguisher 100:3
[Hub-PE-vpn-instance-vpn1-in] vpn-target 222:2 import-extcommunity
[Hub-PE-vpn-instance-vpn1-in] quit
[Hub-PE] ip vpn-instance vpn1-out
[Hub-PE-vpn-instance-vpn1-out] route-distinguisher 100:4
[Hub-PE-vpn-instance-vpn1-out] vpn-target 111:1 export-extcommunity
[Hub-PE-vpn-instance-vpn1-out] quit
[Hub-PE] interface vlan-interface 6
[Hub-PE-Vlan-interface6] ip binding vpn-instance vpn1-in
[Hub-PE-Vlan-interface6] ip address 10.3.1.2 24
[Hub-PE-Vlan-interface6] quit
[Hub-PE] interface vlan-interface 7
[Hub-PE-Vlan-interface7] ip binding vpn-instance vpn1-out
[Hub-PE-Vlan-interface7] ip address 10.4.1.2 24
[Hub-PE-Vlan-interface7] quit
# Configure IP addresses for the CEs according to Figure 81. (Details not shown.)
# Execute the display ip vpn-instance command on the PEs to display the configuration of the
VPN instance, for example, on Spoke-PE 1.
[Spoke-PE1] display ip vpn-instance
Total VPN-Instances configured : 1
VPN-Instance Name
RD
Create time
vpn1
100:1
2009/04/08 10:55:07
# Use the ping command on the PEs to verify that the PEs can ping their attached CEs, for
example, on Spoke-PE 1.
304
[Spoke-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 relationships between PEs and CEs:
# Configure Spoke-CE 1.
<Spoke-CE1> system-view
[Spoke-CE1] bgp 65410
[Spoke-CE1-bgp] peer 10.1.1.2 as-number 100
[Spoke-CE1-bgp] import-route direct
[Spoke-CE1-bgp] quit
# Configure Spoke-CE 2.
<Spoke-CE2> system-view
[Spoke-CE2] bgp 65420
[Spoke-CE2-bgp] peer 10.2.1.2 as-number 100
[Spoke-CE2-bgp] import-route direct
[Spoke-CE2-bgp] quit
# Configure the Hub-CE.
<Hub-CE> system-view
[Hub-CE] bgp 65430
[Hub-CE-bgp] peer 10.3.1.2 as-number 100
[Hub-CE-bgp] peer 10.4.1.2 as-number 100
[Hub-CE-bgp] import-route direct
[Hub-CE-bgp] quit
# Configure Spoke-PE 1.
[Spoke-PE1] bgp 100
[Spoke-PE1-bgp] ipv4-family vpn-instance vpn1
[Spoke-PE1-bgp-vpn1] peer 10.1.1.1 as-number 65410
[Spoke-PE1-bgp-vpn1] import-route direct
[Spoke-PE1-bgp-vpn1] quit
[Spoke-PE1-bgp] quit
# Configure Spoke-PE 2.
[Spoke-PE2] bgp 100
[Spoke-PE2-bgp] ipv4-family vpn-instance vpn1
[Spoke-PE2-bgp-vpn1] peer 10.2.1.1 as-number 65420
[Spoke-PE2-bgp-vpn1] import-route direct
[Spoke-PE2-bgp-vpn1] quit
[Spoke-PE2-bgp] quit
# Configure the Hub-PE.
[Hub-PE] bgp 100
305
[Hub-PE-bgp] ipv4-family vpn-instance vpn1-in
[Hub-PE-bgp-vpn1-in] peer 10.3.1.1 as-number 65430
[Hub-PE-bgp-vpn1-in] import-route direct
[Hub-PE-bgp-vpn1-in] quit
[Hub-PE-bgp] ipv4-family vpn-instance vpn1-out
[Hub-PE-bgp-vpn1-out] peer 10.4.1.1 as-number 65430
[Hub-PE-bgp-vpn1-out] peer 10.4.1.1 allow-as-loop
[Hub-PE-bgp-vpn1-out] import-route direct
[Hub-PE-bgp-vpn1-out] quit
[Hub-PE-bgp] quit
# Execute the display bgp vpnv4 vpn-instance peer command on the PEs. This example
uses Spoke-PE 1 to verify that a BGP peer relationship in Established state has been
established between a PE and a CE.
[Spoke-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
Peer
10.1.1.1
5.
Peers in established state : 1
AS
MsgRcvd
65410
6
MsgSent OutQ PrefRcv Up/Down
7
0
2 00:03:16 Established
Configure an MP-IBGP peer relationship between a spoke-PE and the hub-PE:
# Configure Spoke-PE 1.
[Spoke-PE1] bgp 100
[Spoke-PE1-bgp] peer 2.2.2.9 as-number 100
[Spoke-PE1-bgp] peer 2.2.2.9 connect-interface loopback 0
[Spoke-PE1-bgp] ipv4-family vpnv4
[Spoke-PE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[Spoke-PE1-bgp-af-vpnv4] quit
[Spoke-PE1-bgp] quit
# Configure Spoke-PE 2.
[Spoke-PE2] bgp 100
[Spoke-PE2-bgp] peer 2.2.2.9 as-number 100
[Spoke-PE2-bgp] peer 2.2.2.9 connect-interface loopback 0
[Spoke-PE2-bgp] ipv4-family vpnv4
[Spoke-PE2-bgp-af-vpnv4] peer 2.2.2.9 enable
[Spoke-PE2-bgp-af-vpnv4] quit
[Spoke-PE2-bgp] quit
# Configure the Hub-PE.
[Hub-PE] bgp 100
[Hub-PE-bgp] peer 1.1.1.9 as-number 100
[Hub-PE-bgp] peer 1.1.1.9 connect-interface loopback 0
[Hub-PE-bgp] peer 3.3.3.9 as-number 100
[Hub-PE-bgp] peer 3.3.3.9 connect-interface loopback 0
[Hub-PE-bgp] ipv4-family vpnv4
[Hub-PE-bgp-af-vpnv4] peer 1.1.1.9 enable
[Hub-PE-bgp-af-vpnv4] peer 3.3.3.9 enable
306
State
[Hub-PE-bgp-af-vpnv4] quit
[Hub-PE-bgp] quit
# Execute the display bgp peer command on the PEs. This example uses Spoke-PE 1 to verify
that a BGP peer relationship in Established state has been established between the PEs.
[Spoke-PE1] display bgp peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peer
2.2.2.9
6.
Peers in established state : 1
AS
MsgRcvd
100
6
MsgSent OutQ PrefRcv Up/Down
5
0
State
0 00:00:32 Established
Verify the configuration:
# Execute the display ip routing-table vpn-instance command on the PEs to display the
routes to the CEs. This example uses Spoke-PE 1 to verify that the next hop of the route from a
Spoke-PE to its connected Spoke-CE is Hub-PE.
[Spoke-PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 8
Routes : 8
Destination/Mask
Proto
Pre
Cost
NextHop
Interface
10.0.0.0/24
BGP
255
0
2.2.2.9
NULL0
10.1.1.0/24
Direct 0
0
10.1.1.2
Vlan2
10.1.1.2/32
Direct 0
0
127.0.0.1
InLoop0
10.2.1.0/24
BGP
255
0
2.2.2.9
NULL0
10.3.1.0/24
BGP
255
0
2.2.2.9
NULL0
10.4.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
# Verify that Spoke-CE 1 and Spoke-CE 2 can ping each other. The TTL value indicates that
traffic from Spoke-CE 1 to Spoke-CE 2 passes six hops (255-250+1) and is forwarded through
the Hub-CE. This example uses Spoke-CE 1 to verify their connectivity.
[Spoke-CE1] ping 10.2.1.1
PING 10.2.1.1: 56
data bytes, press CTRL_C to break
Reply from 10.2.1.1: bytes=56 Sequence=1 ttl=250 time=3 ms
Reply from 10.2.1.1: bytes=56 Sequence=2 ttl=250 time=3 ms
Reply from 10.2.1.1: bytes=56 Sequence=3 ttl=250 time=2 ms
Reply from 10.2.1.1: bytes=56 Sequence=4 ttl=250 time=2 ms
Reply from 10.2.1.1: bytes=56 Sequence=5 ttl=250 time=2 ms
--- 10.2.1.1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 2/2/3 ms
307
Configuring inter-AS option A
Network requirements
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.
Inter-AS MPLS L3VPN is implemented using option A, where the VRF-to-VRF method is used to
manage VPN routes.
The MPLS backbone in each AS runs OSPF.
Figure 82 Network diagram
MPLS backbone
Loop0
MPLS backbone
Loop0
AS 100
AS 200
Vlan-int12
Vlan-int11
Loop0
Vlan-int12
Vlan-int11
ASBR-PE 2
ASBR-PE 1
Vlan-int11
Loop0
Vlan-int11
PE 2
PE 1
Vlan-int12
Vlan-int12
Vlan-int12
Vlan-int12
CE 1
CE 2
AS 65001
AS 65002
Device
Interface
IP address
Device
Interface
IP address
CE 1
Vlan-int12
10.1.1.1/24
CE 2
Vlan-int12
10.2.1.1/24
PE 1
Loop0
1.1.1.9/32
PE 2
Loop0
4.4.4.9/32
Vlan-int12
10.1.1.2/24
Vlan-int12
10.2.1.2/24
Vlan-int11
172.1.1.2/24
Vlan-int11
162.1.1.2/24
ASBR-PE 1
Loop0
2.2.2.9/32
Loop0
3.3.3.9/32
Vlan-int11
172.1.1.1/24
ASBR-PE 2
Vlan-int11
162.1.1.1/24
Vlan-int12
192.1.1.1/24
Vlan-int12
192.1.1.2/24
Configuration procedure
1.
Configure an IGP on the MPLS backbone to ensure IP connectivity in the backbone.
This example uses OSPF. (Details not shown.)
The 32-bit loopback interface address used as the LSR ID must be advertised by OSPF.
# Execute the display ospf peer command to verify that each ASBR PE has established an
OSPF adjacency in Full state with the PE in the same AS, and that PEs and ASBR PEs in the
same AS have learned the routes to the loopback interfaces of each other. Verify that each
ASBR PE and the PE in the same AS can ping each other. (Details not shown.)
2.
Configure basic MPLS and MPLS LDP on the MPLS backbone to establish LDP LSPs:
# Configure basic MPLS on PE 1, and enable MPLS LDP on the interface connected to ASBR
PE 1.
<PE1> system-view
308
[PE1] mpls lsr-id 1.1.1.9
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1] interface vlan-interface 11
[PE1-Vlan-interface11] mpls
[PE1-Vlan-interface11] mpls ldp
[PE1-Vlan-interface11] quit
# Configure basic MPLS 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 11
[ASBR-PE1-Vlan-interface11] mpls
[ASBR-PE1-Vlan-interface11] mpls ldp
[ASBR-PE1-Vlan-interface11] quit
# Configure basic MPLS 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 11
[ASBR-PE2-Vlan-interface11] mpls
[ASBR-PE2-Vlan-interface11] mpls ldp
[ASBR-PE2-Vlan-interface11] quit
# Configure basic MPLS 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 11
[PE2-Vlan-interface11] mpls
[PE2-Vlan-interface11] mpls ldp
[PE2-Vlan-interface11] quit
# Execute the display mpls ldp session command on the devices to verify that the session status
is Operational, and that each PE and the ASBR PE in the same AS have established a neighbor
relationship. (Details not shown.)
3.
Configure VPN instances on PEs:
309
For the same VPN, the route targets for the VPN instance on the PE must match those for the
VPN instance on the ASBR-PE in the same AS. This is not required for PEs in different ASs.
# Configure CE 1.
<CE1> system-view
[CE1] interface vlan-interface 12
[CE1-Vlan-interface12] ip address 10.1.1.1 24
[CE1-Vlan-interface12] 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 12
[PE1-Vlan-interface12] ip binding vpn-instance vpn1
[PE1-Vlan-interface12] ip address 10.1.1.2 24
[PE1-Vlan-interface12] quit
# Configure CE 2.
<CE2> system-view
[CE2] interface vlan-interface 12
[CE2-Vlan-interface12] ip address 10.2.1.1 24
[CE2-Vlan-interface12] 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 12
[PE2-Vlan-interface12] ip binding vpn-instance vpn1
[PE2-Vlan-interface12] ip address 10.2.1.2 24
[PE2-Vlan-interface12] quit
# On ASBR PE 1, create a VPN instance, and bind the instance to the interface connected to
ASBR PE 2. 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 12
[ASBR-PE1-Vlan-interface12] ip binding vpn-instance vpn1
[ASBR-PE1-Vlan-interface12] ip address 192.1.1.1 24
[ASBR-PE1-Vlan-interface12] quit
# On ASBR PE 2, create a VPN instance, and bind the instance to the interface connected to
ASBR PE 1. 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 12
[ASBR-PE2-Vlan-interface12] ip binding vpn-instance vpn1
310
[ASBR-PE2-Vlan-interface12] ip address 192.1.1.2 24
[ASBR-PE2-Vlan-interface12] quit
# Execute the display ip vpn-instance command to display VPN instance configurations. Verify
that the PEs can ping the CEs, and the ASBR PEs can ping each other. (Details not shown.)
4.
Establish EBGP peer relationships between PEs and CEs to allow VPN routes to be
redistributed:
# 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 an MP-IBGP peer relationship between each PE and the ASBR-PE in the same AS
and an 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
311
[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 the configuration:
# Verify that the CEs can learn the interface routes from each other and can ping each other.
Configuring inter-AS option B
Network requirements
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. PEs in the same AS run IS-IS.
PE 1 and ASBR-PE 1 exchange labeled IPv4 routes by MP-IBGP. PE 2 and ASBR-PE 2 exchange
labeled IPv4 routes by MP-IBGP. ASBR-PE 1 and ASBR-PE 2 exchange labeled IPv4 routes by
MP-EBGP.
ASBRs do not perform route target filtering of received VPN-IPv4 routes.
312
Figure 83 Network diagram
MPLS backbone
Loop0
MPLS backbone
Loop0
AS 100
AS 600
Vlan-int12
Vlan-int11
Loop0
Vlan-int12
Vlan-int11
ASBR-PE 2
ASBR-PE 1
Vlan-int11
Loop0
Vlan-int11
PE 2
PE 1
Vlan-int12
Vlan-int12
Site 1
Site 2
CE 1
CE 2
AS 65001
AS 65002
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-int12
30.0.0.1/8
Vlan-int12
20.0.0.1/8
ASBR-PE 1
Vlan-int11
1.1.1.2/8
Loop0
3.3.3.9/32
Vlan-int11
9.1.1.2/8
Loop0
4.4.4.9/32
Vlan-int11
1.1.1.1/8
Vlan-int11
9.1.1.1/8
Vlan-int12
11.0.0.2/8
Vlan-int12
11.0.0.1/8
ASBR-PE 2
Configuration procedure
1.
Configure PE 1:
# Run IS-IS on PE 1.
<PE1> system-view
[PE1] isis 1
[PE1-isis-1] network-entity 10.1111.1111.1111.1111.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 11, and start IS-IS and enable MPLS and LDP on the
interface.
[PE1] interface vlan-interface 11
[PE1-Vlan-interface11] ip address 1.1.1.2 255.0.0.0
[PE1-Vlan-interface11] isis enable 1
[PE1-Vlan-interface11] mpls
[PE1-Vlan-interface11] mpls ldp
[PE1-Vlan-interface11] quit
313
# 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 route target attributes.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 11:11
[PE1-vpn-instance-vpn1] vpn-target 3:3 import-extcommunity
[PE1-vpn-instance-vpn1] vpn-target 3:3 export-extcommunity
[PE1-vpn-instance-vpn1] quit
# Bind the interface connected to CE 1 to the created VPN instance.
[PE1] interface vlan-interface 12
[PE1-Vlan-interface12] ip binding vpn-instance vpn1
[PE1-Vlan-interface12] ip address 30.0.0.1 8
[PE1-Vlan-interface12] 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
# Redistribute 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.2222.2222.2222.2222.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 11, and start IS-IS and enable MPLS and LDP on the
interface.
[ASBR-PE1] interface vlan-interface 11
[ASBR-PE1-Vlan-interface11] ip address 1.1.1.1 255.0.0.0
[ASBR-PE1-Vlan-interface11] isis enable 1
[ASBR-PE1-Vlan-interface11] mpls
314
[ASBR-PE1-Vlan-interface11] mpls ldp
[ASBR-PE1-Vlan-interface11] quit
# Configure interface VLAN-interface 12 and enable MPLS on it.
[ASBR-PE1] interface vlan-interface 12
[ASBR-PE1-Vlan-interface12] ip address 11.0.0.2 255.0.0.0
[ASBR-PE1-Vlan-interface12] mpls
[ASBR-PE1-Vlan-interface12] 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
# Disable route target based filtering of received VPNv4 routes.
[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.3333.3333.3333.3333.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 11, and start IS-IS and enable MPLS and LDP on the
interface.
[ASBR-PE2] interface vlan-interface 11
[ASBR-PE2-Vlan-interface11] ip address 9.1.1.1 255.0.0.0
[ASBR-PE2-Vlan-interface11] isis enable 1
[ASBR-PE2-Vlan-interface11] mpls
[ASBR-PE2-Vlan-interface11] mpls ldp
[ASBR-PE2-Vlan-interface11] quit
# Configure interface VLAN-interface 12 and enable MPLS on it.
[ASBR-PE2] interface vlan-interface 12
[ASBR-PE2-Vlan-interface12] ip address 11.0.0.1 255.0.0.0
315
[ASBR-PE2-Vlan-interface12] mpls
[ASBR-PE2-Vlan-interface12] 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 5.5.5.9 as-number 600
[ASBR-PE2-bgp] peer 5.5.5.9 connect-interface loopback 0
# Disable route target based filtering of received VPNv4 routes.
[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.4444.4444.4444.4444.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 11, and start IS-IS and enable MPLS and LDP on the
interface.
[PE2] interface vlan-interface 11
[PE2-Vlan-interface11] ip address 9.1.1.2 255.0.0.0
[PE2-Vlan-interface11] isis enable 1
[PE2-Vlan-interface11] mpls
[PE2-Vlan-interface11] mpls ldp
[PE2-Vlan-interface11] 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 route target attributes.
[PE2] ip vpn-instance vpn1
316
[PE2-vpn-instance-vpn1] route-distinguisher 12:12
[PE2-vpn-instance-vpn1] vpn-target 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 12
[PE2-Vlan-interface12] ip binding vpn-instance vpn1
[PE2-Vlan-interface12] ip address 20.0.0.1 8
[PE2-Vlan-interface12] 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
# Redistribute 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 the configuration:
# Verify that PE 1 and PE 2 can ping each other.
[PE2] ping –vpn-instance vpn1 30.0.0.1
[PE1] ping –vpn-instance vpn1 20.0.0.1
Configuring inter-AS option C
Network requirements
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. PEs in the same AS run IS-IS.
PE 1 and ASBR-PE 1 exchange labeled IPv4 routes by MP-IBGP. PE 2 and ASBR-PE 2 exchange
labeled IPv4 routes by MP-IBGP. PE 1 and PE 2 are MP-EBGP peers.
ASBR-PE 1 and ASBR-PE 2 use their respective routing policies and label the routes received from
each other.
ASBR-PE 1 and ASBR-PE 2 use MP-EBGP to exchange labeled IPv4 routes.
317
Figure 84 Network diagram
Device
Interface
IP address
Device
Interface
IP address
PE 1
Loop0
2.2.2.9/32
PE 2
Loop0
5.5.5.9/32
ASBR-PE 1
Loop1
30.0.0.1/32
Loop1
20.0.0.1/32
Vlan-int11
1.1.1.2/8
Vlan-int11
9.1.1.2/8
Loop0
3.3.3.9/32
Loop0
4.4.4.9/32
Vlan-int11
1.1.1.1/8
Vlan-int11
9.1.1.1/8
Vlan-int12
11.0.0.2/8
Vlan-int12
11.0.0.1/8
ASBR-PE 2
Configuration procedure
1.
Configure PE 1:
# Run IS-IS on PE 1.
<PE1> system-view
[PE1] isis 1
[PE1-isis-1] network-entity 10.1111.1111.1111.1111.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 11, and start IS-IS and enable MPLS and LDP on the
interface.
[PE1] interface vlan-interface 11
[PE1-Vlan-interface11] ip address 1.1.1.2 255.0.0.0
[PE1-Vlan-interface11] isis enable 1
[PE1-Vlan-interface11] mpls
[PE1-Vlan-interface11] mpls ldp
[PE1-Vlan-interface11] 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
318
[PE1-LoopBack0] quit
# Create VPN instance vpn1 and configure the RD and route target attributes.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] route-distinguisher 11:11
[PE1-vpn-instance-vpn1] vpn-target 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
# Redistribute 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.2222.2222.2222.2222.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 11, and start IS-IS and enable MPLS and LDP on the
interface.
[ASBR-PE1] interface vlan-interface 11
319
[ASBR-PE1-Vlan-interface11] ip address 1.1.1.1 255.0.0.0
[ASBR-PE1-Vlan-interface11] isis enable 1
[ASBR-PE1-Vlan-interface11] mpls
[ASBR-PE1-Vlan-interface11] mpls ldp
[ASBR-PE1-Vlan-interface11] quit
# Configure interface VLAN-interface 12 and enable MPLS on it.
[ASBR-PE1] interface vlan-interface 12
[ASBR-PE1-Vlan-interface12] ip address 11.0.0.2 255.0.0.0
[ASBR-PE1-Vlan-interface12] mpls
[ASBR-PE1-Vlan-interface12] 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 redistribute routes from IS-IS process 1.
[ASBR-PE1] bgp 100
[ASBR-PE1-bgp] import-route isis 1
# Use routing policy policy2 to filter routes advertised to 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
# Use routing policy policy1 to filter routes advertised to 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.3333.3333.3333.3333.00
[ASBR-PE2-isis-1] quit
# Configure LSR ID, enable MPLS and LDP.
[ASBR-PE2] mpls lsr-id 4.4.4.9
320
[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 11, and start IS-IS and enable MPLS and LDP on the
interface.
[ASBR-PE2] interface vlan-interface 11
[ASBR-PE2-Vlan-interface11] ip address 9.1.1.1 255.0.0.0
[ASBR-PE2-Vlan-interface11] isis enable 1
[ASBR-PE2-Vlan-interface11] mpls
[ASBR-PE2-Vlan-interface11] mpls ldp
[ASBR-PE2-Vlan-interface11] 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 12 and enable MPLS on it.
[ASBR-PE2] interface vlan-interface 12
[ASBR-PE2-Vlan-interface12] ip address 11.0.0.1 255.0.0.0
[ASBR-PE2-Vlan-interface12] mpls
[ASBR-PE2-Vlan-interface12] 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 redistribute routes from 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 0
[ASBR-PE2-bgp] peer 5.5.5.9 label-route-capability
# Use routing policy policy2 to filter routes advertised to IBGP peer 5.5.5.9.
[ASBR-PE2-bgp] peer 5.5.5.9 route-policy policy2 export
# Use routing policy policy1 to filter routes advertised to 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
321
[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.4444.4444.4444.4444.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 11, and start IS-IS and enable MPLS and LDP on the
interface.
[PE2] interface vlan-interface 11
[PE2-Vlan-interface11] ip address 9.1.1.2 255.0.0.0
[PE2-Vlan-interface11] isis enable 1
[PE2-Vlan-interface11] mpls
[PE2-Vlan-interface11] mpls ldp
[PE2-Vlan-interface11] 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 route target attributes.
[PE2] ip vpn-instance vpn1
[PE2-vpn-instance-vpn1] route-distinguisher 11:11
[PE2-vpn-instance-vpn1] vpn-target 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 0
[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 0
322
[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
# Redistribute 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
5.
Verify the configuration:
# Verify that PE 1 and PE 2 can ping each other.
[PE2] ping –vpn-instance vpn1 30.0.0.1
[PE1] ping –vpn-instance vpn1 20.0.0.1
Configuring carrier's carrier
Network requirements
Configure carrier's carrier for the scenario shown in Figure 85. In this scenario:
•
PE 1 and PE 2 are the provider carrier's PE switches. They provide VPN services for the
customer carrier.
•
CE 1 and CE 2 are the customer carrier's switches. They are connected to the provider carrier's
backbone as CE switches.
•
PE 3 and PE 4 are the customer carrier's PE switches. They provide MPLS L3VPN services for
the end customers.
•
CE 3 and CE 4 are customers of the customer carrier.
The key to carrier's carrier deployment is to configure exchange of two kinds of routes:
•
Exchange of the customer carrier's internal routes on the provider carrier's backbone.
•
Exchange of the end customers' VPN routes between PE 3 and PE 4, the PEs of the customer
carrier. In this process, an MP-IBGP peer relationship must be established between PE 3 and
PE 4.
323
Figure 85 Network diagram
Loop0
Provider carrier
Loop0
Vlan-int12
PE 1
PE 2
Vlan-int12
Vlan-int11
Vlan-int11
AS 100
Loop0
AS 100
Customer carrier
Customer carrier
Vlan-int11
Vlan-int12
Vlan-int11
CE 1
Vlan-int12
Vlan-int12
CE 2
Vlan-int12
PE 3 Vlan-int11
Vlan-int11
Loop0
Loop0
MP-IBGP
Vlan-int11
PE 4
Vlan-int11
CE 4
AS 65420
CE 3
AS 65410
Device
Interface
IP address
Device
Interface
IP address
CE 3
Vlan-int11
100.1.1.1/24
CE 4
Vlan-int11
120.1.1.1/24
PE 3
Loop0
1.1.1.9/32
PE 4
Loop0
6.6.6.9/32
Vlan-int11
100.1.1.2/24
Vlan-int11
120.1.1.2/24
Vlan-int12
10.1.1.1/24
Vlan-int12
20.1.1.2/24
Loop0
2.2.2.9/32
Loop0
5.5.5.9/32
Vlan-int12
10.1.1.2/24
Vlan-int11
21.1.1.2/24
CE 1
PE 1
Vlan-int11
11.1.1.1/24
Loop0
3.3.3.9/32
Vlan-int11
Vlan-int12
CE 2
Vlan-int12
20.1.1.1/24
Loop0
4.4.4.9/32
11.1.1.2/24
Vlan-int12
30.1.1.2/24
30.1.1.1/24
Vlan-int11
21.1.1.1/24
PE 2
Configuration procedure
1.
Configure MPLS L3VPN on the provider carrier backbone: start IS-IS as the IGP, enable LDP
between PE 1 and PE 2, and establish an 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
324
[PE1-LoopBack0] quit
[PE1] interface vlan-interface 12
[PE1-Vlan-interface12] ip address 30.1.1.1 24
[PE1-Vlan-interface12] isis enable 1
[PE1-Vlan-interface12] mpls
[PE1-Vlan-interface12] 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
# Configure PE 2 in the same way that PE 1 is configured. (Details not shown.)
# On PE 1, verify that the LDP session has been established.
[PE1] display mpls ldp session
LDP Session(s) in Public Network
Total number of sessions: 1
---------------------------------------------------------------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
# On PE 1, verify that the BGP peer relationship in Established state has been established.
[PE1] display bgp peer
BGP local router ID : 3.3.3.9
Local AS number : 100
Total number of peers : 1
Peer
4.4.4.9
Peers in established state : 1
AS
MsgRcvd
MsgSent
OutQ
PrefRcv
100
162
145
0
0
Up/Down
State
02:12:47 Established
# On PE 1, verify that the IS-IS neighbor relationship has been set up.
[PE1] display isis peer
Peer information for ISIS(1)
---------------------------System Id
Interface
0000.0000.0005 Vlan-interface2
2.
Circuit Id
State HoldTime
Type
PRI
001
Up
L1L2
--
29s
Configure the customer carrier network: start IS-IS as the IGP and enable 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
325
[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 12
[PE3-Vlan-interface12] ip address 10.1.1.1 24
[PE3-Vlan-interface12] isis enable 2
[PE3-Vlan-interface12] mpls
[PE3-Vlan-interface12] mpls ldp
[PE3-Vlan-interface12] mpls ldp transport-address interface
[PE3-Vlan-interface12] 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 12
[CE1-Vlan-interface12] ip address 10.1.1.2 24
[CE1-Vlan-interface12] isis enable 2
[CE1-Vlan-interface12] mpls
[CE1-Vlan-interface12] mpls ldp
[CE1-Vlan-interface12] mpls ldp transport-address interface
[CE1-Vlan-interface12] quit
PE 3 and CE 1 can establish an LDP session and IS-IS neighbor relationship between them.
# Configure PE 4 and CE 2 in the same way that PE 3 and CE 1 are configured. (Details not
shown.)
3.
Perform configuration to allow CEs of the customer carrier to access PEs of the provider carrier,
and redistribute IS-IS routes to BGP and BGP routes to IS-IS on the PEs:
# 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
326
[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 allow-ibgp
[PE1-isis-2] quit
[PE1] interface vlan-interface 11
[PE1-Vlan-interface11] ip binding vpn-instance vpn1
[PE1-Vlan-interface11] ip address 11.1.1.2 24
[PE1-Vlan-interface11] isis enable 2
[PE1-Vlan-interface11] mpls
[PE1-Vlan-interface11] mpls ldp
[PE1-Vlan-interface11] mpls ldp transport-address interface
[PE1-Vlan-interface11] 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 11
[CE1-Vlan-interface11] ip address 11.1.1.1 24
[CE1-Vlan-interface11] isis enable 2
[CE1-Vlan-interface11] mpls
[CE1-Vlan-interface11] mpls ldp
[CE1-Vlan-interface11] mpls ldp transport-address interface
[CE1-Vlan-interface11] quit
PE 1 and CE 1 can establish the LDP session and IS-IS neighbor relationship between them.
# Configure PE 2 and CE 2 in the same way that PE 1 and CE 1 are configured. (Details not
shown.)
4.
Perform configuration to connect the CEs of the end customers to the PEs of the customer
carrier:
# Configure CE 3.
<CE3> system-view
[CE3] interface vlan-interface 11
[CE3-Vlan-interface11] ip address 100.1.1.1 24
[CE3-Vlan-interface11] 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 11
327
[PE3-Vlan-interface11] ip binding vpn-instance vpn1
[PE3-Vlan-interface11] ip address 100.1.1.2 24
[PE3-Vlan-interface11] 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
# Configure PE 4 and CE 4 in the same way that PE 3 and CE 3 are configured. (Details not
shown.)
5.
Configure MP-IBGP peer relationship between the PEs of the customer carrier to exchange the
end customers' VPN routes:
# 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
# Configure PE 4 in the same way that PE 3 is configured. (Details not shown.)
6.
Verify the configuration:
# Verify that the public network routing table contains only routes of the provider carrier network
on PEs, for example, on PE 1.
[PE1] display ip routing-table
Routing Tables: Public
Destinations : 7
Routes : 7
Destination/Mask
Proto
Cost
NextHop
Interface
3.3.3.9/32
Direct 0
Pre
0
127.0.0.1
InLoop0
4.4.4.9/32
ISIS
10
30.1.1.2
Vlan12
30.1.1.0/24
Direct 0
0
30.1.1.1
Vlan12
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
Vlan12
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
15
# Verify that the VPN routing tables contain the internal routes of the customer carrier network,
but do not contain the VPN routes that the customer carrier maintains on PEs, for example, on
PE 1.
[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
Vlan11
2.2.2.9/32
ISIS
15
10
11.1.1.1
Vlan11
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
Vlan11
11.1.1.0/24
Direct 0
0
11.1.1.1
Vlan11
328
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
Vlan11
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
# Verify that the public network routing table contains the internal routes of the customer carrier
network, but does not contain the VPN routes that the customer carrier maintains on CEs, for
example, on CE 1.
[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
Vlan12
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
Vlan11
6.6.6.9/32
ISIS
15
74
11.1.1.2
Vlan11
10.1.1.0/24
Direct 0
0
10.1.1.2
Vlan12
10.1.1.1/32
Direct 0
0
10.1.1.1
Vlan12
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
Vlan11
20.1.1.0/24
ISIS
15
74
11.1.1.2
Vlan11
21.1.1.0/24
ISIS
15
74
11.1.1.2
Vlan11
21.1.1.2/32
ISIS
15
74
11.1.1.2
Vlan11
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
# Verify that the public network routing table contains the internal routes of the customer carrier
network on PEs, for example, on PE 3.
[PE3] display ip routing-table
Routing Tables: Public
Destinations : 11
Destination/Mask
Proto
1.1.1.9/32
2.2.2.9/32
Routes : 11
Pre
Cost
NextHop
Interface
Direct 0
0
127.0.0.1
InLoop0
ISIS
15
10
10.1.1.2
Vlan12
5.5.5.9/32
ISIS
15
84
10.1.1.2
Vlan12
6.6.6.9/32
ISIS
15
84
10.1.1.2
Vlan12
10.1.1.0/24
Direct 0
0
10.1.1.1
Vlan12
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
Vlan12
11.1.1.0/24
ISIS
15
20
10.1.1.2
Vlan12
20.1.1.0/24
ISIS
15
84
10.1.1.2
Vlan12
21.1.1.0/24
ISIS
15
84
10.1.1.2
Vlan12
21.1.1.2/32
ISIS
15
84
10.1.1.2
Vlan12
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
# Verify that the VPN routing tables contain the routes of the remote VPN customers on PEs, for
example, on PE 3.
[PE3] display ip routing-table vpn-instance vpn1
329
Routing Tables: vpn1
Destinations : 3
Routes : 3
Destination/Mask
Proto
Cost
NextHop
Interface
100.1.1.0/24
Direct 0
Pre
0
100.1.1.2
Vlan11
100.1.1.2/32
Direct 0
0
127.0.0.1
InLoop0
120.1.1.0/24
BGP
0
6.6.6.9
NULL0
255
# Verify that PE 3 and PE 4 can 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
# Verify that CE 3 and CE 4 can 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
Configuring nested VPN
Network requirements
The service provider provides nested VPN services for users, as shown in Figure 86.
•
PE 1 and PE 2 are PE devices on the service provider backbone. Both of them support the
nested VPN function.
•
CE 1 and CE 2 are connected to the service provider backbone. Both of them support VPNv4
routes.
•
PE 3 and PE 4 are PE devices of the customer VPN. Both of them support MPLS L3VPN.
•
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:
330
•
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.
•
To implement exchange of sub-VPN routes between customer PEs and service provider PEs,
MP-EBGP peers must be established between service provider PEs and customer CEs.
p0
Lo
Lo
o
0
op
op
Lo
Lo
op
0
Figure 86 Network diagram
0
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-int12
10.1.1.2/24
Vlan-int11
21.1.1.2/24
Vlan-int11
11.1.1.1/24
Vlan-int12
20.1.1.1/24
Vlan-int11
100.1.1.1/24
CE 4
Vlan-int11
120.1.1.1/24
CE 5
Vlan-int13
110.1.1.1/24
CE 6
Vlan-int13
130.1.1.1/24
PE 1
Loop0
3.3.3.9/32
PE 2
Loop0
4.4.4.9/32
Vlan-int11
11.1.1.2/24
Vlan-int11
21.1.1.1/24
Vlan-int12
30.1.1.1/24
Vlan-int12
30.1.1.2/24
Loop0
1.1.1.9/32
Loop0
6.6.6.9/32
Vlan-int11
100.1.1.2/24
Vlan-int11
120.1.1.2/24
Vlan-int12
10.1.1.1/24
Vlan-int12
20.1.1.2/24
Vlan-int13
110.1.1.2/24
Vlan-int13
130.1.1.2/24
CE 3
PE 3
PE 4
Configuration procedure
1.
Configure MPLS L3VPN on the service provider backbone. Use IS-IS as the IGP protocol,
enable LDP, and establish 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
331
[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 12
[PE1-Vlan-interface12] ip address 30.1.1.1 24
[PE1-Vlan-interface12] isis enable 1
[PE1-Vlan-interface12] mpls
[PE1-Vlan-interface12] mpls ldp
[PE1-Vlan-interface12] 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
# Configure PE 2 in the same way that PE 1 is configured. (Details not shown.)
# On PE 1, verify that the LDP session has been established.
[PE1] display mpls ldp session
LDP Session(s) in Public Network
Total number of sessions: 1
---------------------------------------------------------------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
# On PE 1, verify that the BGP peer relationship in Established state has been established.
[PE1] display bgp peer
BGP local router ID : 3.3.3.9
Local AS number : 100
Total number of peers : 1
Peer
AS
4.4.4.9
100
MsgRcvd
Peers in established state : 1
MsgSent
162
145
OutQ
PrefRcv
0
Up/Down
0
State
02:12:47 Established
# On PE 1, verify that the IS-IS neighbor relationship has been established.
[PE1] display isis peer
Peer information for ISIS(1)
---------------------------System Id
Interface
0000.0000.0005 Vlan-interface12
Circuit Id
001
332
State HoldTime
Up
29s
Type
L1L2
PRI
--
2.
Configure the customer VPN. Use IS-IS as the IGP protocol, and enable 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] interface vlan-interface 12
[PE3-Vlan-interface12] ip address 10.1.1.1 24
[PE3-Vlan-interface12] isis enable 2
[PE3-Vlan-interface12] mpls
[PE3-Vlan-interface12] mpls ldp
[PE3-Vlan-interface12] 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 12
[CE1-Vlan-interface12] ip address 10.1.1.2 24
[CE1-Vlan-interface12] isis enable 2
[CE1-Vlan-interface12] mpls
[CE1-Vlan-interface12] mpls ldp
[CE1-Vlan-interface12] quit
LDP and IS-IS neighbor relationship can be established between PE 3 and CE 1.
333
# Configure PE 4 and CE 2 in the same way that PE 3 and CE 1 are configured. (Details not
shown.)
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-interface 11
[PE1-Vlan-interface11] ip binding vpn-instance vpn1
[PE1-Vlan-interface11] ip address 11.1.1.2 24
[PE1-Vlan-interface11] mpls
[PE1-Vlan-interface11] 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 11
[CE1-Vlan-interface11] ip address 11.1.1.1 24
[CE1-Vlan-interface11] mpls
[CE1-Vlan-interface11] quit
[CE1] bgp 200
[CE1-bgp] peer 11.1.1.2 as-number 100
[CE1-bgp] import isis 2
[CE1-bgp] quit
# Configure PE 2 and CE 2 in the same way that PE 1 and CE 1 are configured. (Details not
shown.)
4.
Connect sub-VPN CEs to the customer VPN PEs:
# Configure CE 3.
<CE3> system-view
[CE3] interface vlan-interface11
[CE3-Vlan-interface11] ip address 100.1.1.1 24
[CE3-Vlan-interface11] quit
[CE3] bgp 65410
[CE3-bgp] peer 100.1.1.2 as-number 200
[CE3-bgp] import-route direct
[CE3-bgp] quit
# Configure CE 5.
<CE5> system-view
[CE5] interface vlan-interface 13
[CE5-Vlan-interface13] ip address 110.1.1.1 24
[CE5-Vlan-interface13] quit
[CE5] bgp 65411
[CE5-bgp] peer 110.1.1.2 as-number 200
[CE5-bgp] import-route direct
[CE5-bgp] quit
334
# 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 11
[PE3-Vlan-interface11] ip binding vpn-instance SUB_VPN1
[PE3-Vlan-interface11] ip address 100.1.1.2 24
[PE3-Vlan-interface11] 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 13
[PE3-Vlan-interface13] ip binding vpn-instance SUB_VPN2
[PE3-Vlan-interface13] ip address 110.1.1.2 24
[PE3-Vlan-interface13] 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
# Configure PE 4, CE 4, and CE 6 in the same way that PE 3, CE 3, and CE 5 are configured.
(Details not shown.)
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
# 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
# Disable route target based filtering of received VPNv4 routes.
[CE1-bgp-af-vpnv4] undo policy vpn-target
[CE1-bgp-af-vpnv4] quit
335
[CE1-bgp] quit
# Configure PE 2 and CE 2 in the same way that PE 1 and CE 1 are configured. (Details not
shown.)
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
# 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
# Configure PE 4 and CE 2 in the same way that PE 3 and CE 1 are configured. (Details not
shown.)
7.
Verify the configurations:
# Verify that the public routing table contains only routes on the service provider network on
PEs, for example, on PE 1.
[PE1] display ip routing-table
Routing Tables: Public
Destinations : 7
Destination/Mask
Proto
3.3.3.9/32
4.4.4.9/32
30.1.1.0/24
30.1.1.1/32
Routes : 7
Pre
Cost
NextHop
Interface
Direct 0
0
127.0.0.1
InLoop0
ISIS
10
30.1.1.2
Vlan12
Direct 0
0
30.1.1.1
Vlan12
Direct 0
0
127.0.0.1
InLoop0
30.1.1.2/32
Direct 0
0
30.1.1.2
Vlan12
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
15
# Verify that the VPN routing tables contain sub-VPN routes on PEs, for example, on PE 1.
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 9
Routes : 9
336
Destination/Mask
Proto
11.1.1.0/24
11.1.1.1/32
Pre
Cost
NextHop
Interface
Direct 0
0
11.1.1.1
Vlan11
Direct 0
0
127.0.0.1
InLoop0
11.1.1.2/32
Direct 0
0
11.1.1.2
Vlan11
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
0
4.4.4.9
NULL0
255
# Verify that the VPNv4 routing tables on the customer VPN contain internal sub-VPN routes on
CEs, for example, on CE 1.
[CE1] display bgp vpnv4 all routing-table
BGP Local router ID is 11.11.11.11
Status codes: * - valid, ^ - VPN best, > - 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
100.1.1.0/24
1.1.1.9
1024/1024
MED
LocPrf
MED
LocPrf
MED
LocPrf
MED
LocPrf
MED
LocPrf
Route Distinguisher: 101:1
*^
Network
NextHop
In/Out Label
100.1.1.0/24
1.1.1.9
1024/1024
Route Distinguisher: 101:1
Network
NextHop
In/Out Label
* > 110.1.1.0/24
1.1.1.9
1025/1025
Route Distinguisher: 200:1
Network
* >
120.1.1.0/24
NextHop
In/Out Label
11.1.1.2
1026/1027
Route Distinguisher: 201:1
Network
NextHop
In/Out Label
337
* > 130.1.1.0/24
11.1.1.2
1027/1028
# Verify that the VPN routing tables contain routes sent by the provider PE to user sub-VPN on
PEs, for example, on PE 3.
[PE3] display ip routing-table vpn-instance SUB_VPN1
Routing Tables: SUB_VPN1
Destinations : 5
Destination/Mask
Proto
100.1.1.0/24
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
100.1.1.2
Vlan11
100.1.1.2/32
Direct 0
0
127.0.0.1
InLoop0
120.1.1.0/24
BGP
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
255
# Verify that the routing tables contain routes of remote sub-VPNs on CEs, for example, on CE
3.
[CE3] display ip routing-table
Routing Tables: Public
Destinations : 5
Destination/Mask
Proto
100.1.1.0/24
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
100.1.1.1
Vlan11
100.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
120.1.1.0/24
BGP
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
255
# Verify that the routing tables contain routes of remote sub-VPNs on CEs, for example, on CE
5.
[CE5] display ip routing-table
Routing Tables: Public
Destinations : 5
Destination/Mask
Proto
110.1.1.0/24
Routes : 5
Pre
Cost
NextHop
Interface
Direct 0
0
110.1.1.1
Vlan11
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
0
110.1.1.2
Vlan11
255
# Verify that CE 3 and CE 4 can 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
338
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
# Verify that CE 5 and CE 6 can ping each other.
[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
# Verify that CE 3 and CE 6 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
Configuring HoVPN
Network requirements
There are two levels of networks, the backbone and the MPLS VPN networks, as shown in Figure
87.
•
SPEs act as PEs to allow MPLS VPNs to access the backbone.
•
UPEs act as PEs of the MPLS VPNs to allow end users to access the VPNs.
•
Performance requirements for the UPEs are lower than those for the SPEs.
339
•
SPEs advertise routes permitted by the routing policies to UPEs, permitting CE 1 and CE 3 in
VPN 1 to communicate with each other and forbidding CE 2 and CE 4 in VPN 2 to communicate
with each other.
Figure 87 Network diagram
Device
Interface
IP address
Device
Interface
IP address
CE 1
Vlan-int12
10.2.1.1/24
CE 3
Vlan-int12
10.1.1.1/24
CE 2
Vlan-int13
10.4.1.1/24
CE 4
Vlan-int13
10.3.1.1/24
UPE 1
Loop0
1.1.1.9/32
UPE 2
Loop0
4.4.4.9/32
SPE 1
Vlan-int11
172.1.1.1/24
Vlan-int11
172.2.1.1/24
Vlan-int12
10.2.1.2/24
Vlan-int12
10.1.1.2/24
Vlan-int13
10.4.1.2/24
Vlan-int13
10.3.1.2/24
Loop0
2.2.2.9/32
Loop0
3.3.3.9/32
Vlan-int11
172.1.1.2/24
SPE 2
Vlan-int11
172.2.1.2/24
Vlan-int12
180.1.1.1/24
Vlan-int12
180.1.1.2/24
Configuration procedure
1.
Configure UPE 1:
# Configure basic MPLS and MPLS LDP to establish LDP LSPs.
<UPE1> system-view
[UPE1] interface loopback 0
[UPE1-LoopBack0] ip address 1.1.1.9 32
[UPE1-LoopBack0] quit
[UPE1] mpls lsr-id 1.1.1.9
[UPE1] mpls
[UPE1-mpls] quit
[UPE1] mpls ldp
[UPE1-mpls-ldp] quit
[UPE1] interface vlan-interface 11
[UPE1-Vlan-interface11] ip address 172.1.1.1 24
[UPE1-Vlan-interface11] mpls
[UPE1-Vlan-interface11] mpls ldp
[UPE1-Vlan-interface11] quit
# Configure the IGP protocol, OSPF, for example.
340
[UPE1] ospf
[UPE1-ospf-1] area 0
[UPE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[UPE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[UPE1-ospf-1-area-0.0.0.0] quit
[UPE1-ospf-1] quit
# Configure VPN instances vpn1 and vpn2, allowing CE 1 and CE 2 to access UPE 1.
[UPE1] ip vpn-instance vpn1
[UPE1-vpn-instance-vpn1] route-distinguisher 100:1
[UPE1-vpn-instance-vpn1] vpn-target 100:1 both
[UPE1-vpn-instance-vpn1] quit
[UPE1] ip vpn-instance vpn2
[UPE1-vpn-instance-vpn2] route-distinguisher 100:2
[UPE1-vpn-instance-vpn2] vpn-target 100:2 both
[UPE1-vpn-instance-vpn2] quit
[UPE1] interface vlan-interface 12
[UPE1-Vlan-interface12] ip binding vpn-instance vpn1
[UPE1-Vlan-interface12] ip address 10.2.1.2 24
[UPE1-Vlan-interface12] quit
[UPE1] interface vlan-interface 13
[UPE1-Vlan-interface13] ip binding vpn-instance vpn2
[UPE1-Vlan-interface13] ip address 10.4.1.2 24
[UPE1-Vlan-interface13] quit
# Configure UPE 1 to establish MP-IBGP peer relationship with SPE 1 and to inject VPN routes.
[UPE1] bgp 100
[UPE1-bgp] peer 2.2.2.9 as-number 100
[UPE1-bgp] peer 2.2.2.9 connect-interface loopback 0
[UPE1-bgp] ipv4-family vpnv4
[UPE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[UPE1-bgp-af-vpnv4] quit
[UPE1-bgp] ipv4-family vpn-instance vpn1
[UPE1-bgp-vpn1] peer 10.2.1.1 as-number 65410
[UPE1-bgp-vpn1] import-route direct
[UPE1-bgp-vpn1] quit
[UPE1-bgp] ipv4-family vpn-instance vpn2
[UPE1-bgp-vpn1] peer 10.4.1.1 as-number 65420
[UPE1-bgp-vpn1] import-route direct
[UPE1-bgp-vpn1] quit
[UPE1-bgp] quit
2.
Configure CE 1.
<CE1> system-view
[CE1] interface vlan-interface 12
[CE1-Vlan-interface12] ip address 10.2.1.1 255.255.255.0
[CE1-Vlan-interface12] quit
[CE1] bgp 65410
[CE1-bgp] peer 10.2.1.2 as-number 100
[CE1-bgp] import-route direct
[CE1] quit
341
3.
Configure CE 2.
<CE2> system-view
[CE2] interface vlan-interface 13
[CE2-Vlan-interface13] ip address 10.4.1.1 255.255.255.0
[CE2-Vlan-interface13] quit
[CE2] bgp 65420
[CE2-bgp] peer 10.4.1.2 as-number 100
[CE2-bgp] import-route direct
[CE2] quit
4.
Configure UPE 2:
# Configure basic MPLS and MPLS LDP to establish LDP LSPs.
<UPE2> system-view
[UPE2] interface loopback 0
[UPE2-Loopback0] ip address 4.4.4.9 32
[UPE2-Loopback0] quit
[UPE2] mpls lsr-id 4.4.4.9
[UPE2] mpls
[UPE2-mpls] quit
[UPE2] mpls ldp
[UPE2-mpls-ldp] quit
[UPE2] interface vlan-interface 11
[UPE2-Vlan-interface11] ip address 172.2.1.1 24
[UPE2-Vlan-interface11] mpls
[UPE2-Vlan-interface11] mpls ldp
[UPE2-Vlan-interface11] quit
# Configure the IGP protocol, OSPF, for example.
[UPE2] ospf
[UPE2-ospf-1] area 0
[UPE2-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255
[UPE2-ospf-1-area-0.0.0.0] network 4.4.4.9 0.0.0.0
[UPE2-ospf-1-area-0.0.0.0] quit
[UPE2-ospf-1] quit
# Configure VPN instances vpn1 and vpn2, allowing CE 3 and CE 4 to access UPE 2.
[UPE2] ip vpn-instance vpn1
[UPE2-vpn-instance-vpn1] route-distinguisher 300:1
[UPE2-vpn-instance-vpn1] vpn-target 100:1 both
[UPE2-vpn-instance-vpn1] quit
[UPE2] ip vpn-instance vpn2
[UPE2-vpn-instance-vpn2] route-distinguisher 400:2
[UPE2-vpn-instance-vpn2] vpn-target 100:2 both
[UPE2-vpn-instance-vpn2] quit
[UPE2] interface vlan-interface 12
[UPE2-Vlan-interface12] ip binding vpn-instance vpn1
[UPE2-Vlan-interface12] ip address 10.1.1.2 24
[UPE2-Vlan-interface12] quit
[UPE2] interface vlan-interface 13
[UPE2-Vlan-interface13] ip binding vpn-instance vpn2
[UPE2-Vlan-interface13] ip address 10.3.1.2 24
342
[UPE2-Vlan-interface13] quit
# Configure UPE 2 to establish MP-IBGP peer relationship with SPE 2 and to inject VPN routes.
[UPE2] bgp 100
[UPE2-bgp] peer 3.3.3.9 as-number 100
[UPE2-bgp] peer 3.3.3.9 connect-interface loopback 0
[UPE2-bgp] ipv4-family vpnv4
[UPE2-bgp-af-vpnv4] peer 3.3.3.9 enable
[UPE2-bgp-af-vpnv4] quit
[UPE2-bgp] ipv4-family vpn-instance vpn1
[UPE2-bgp-vpn1] peer 10.1.1.1 as-number 65430
[UPE2-bgp-vpn1] import-route direct
[UPE2-bgp-vpn1] quit
[UPE2-bgp] ipv4-family vpn-instance vpn2
[UPE2-bgp-vpn1] peer 10.3.1.1 as-number 65440
[UPE2-bgp-vpn1] import-route direct
[UPE2-bgp-vpn1] quit
[UPE2-bgp] quit
5.
Configure CE 3.
<CE3> system-view
[CE3] interface vlan-interface 12
[CE3-Vlan-interface12] ip address 10.1.1.1 255.255.255.0
[CE3-Vlan-interface12] quit
[CE3] bgp 65430
[CE3-bgp] peer 10.1.1.2 as-number 100
[CE3-bgp] import-route direct
[CE3] quit
6.
Configure CE 4.
<CE4> system-view
[CE4] interface vlan-interface 13
[CE4-Vlan-interface13] ip address 10.3.1.1 255.255.255.0
[CE4-Vlan-interface13] quit
[CE4] bgp 65440
[CE4-bgp] peer 10.3.1.2 as-number 100
[CE4-bgp] import-route direct
[CE4] quit
7.
Configure SPE 1:
# Configure basic MPLS and MPLS LDP to establish LDP LSPs.
<SPE1> system-view
[SPE1] interface loopback 0
[SPE1-LoopBack0] ip address 2.2.2.9 32
[SPE1-LoopBack0] quit
[SPE1] mpls lsr-id 2.2.2.9
[SPE1] mpls
[SPE1-mpls] quit
[SPE1] mpls ldp
[SPE1-mpls-ldp] quit
[SPE1] interface vlan-interface 11
[SPE1-Vlan-interface11] ip address 172.1.1.2 24
343
[SPE1-Vlan-interface11] mpls
[SPE1-Vlan-interface11] mpls ldp
[SPE1-Vlan-interface11] quit
[SPE1] interface vlan-interface 12
[SPE1-Vlan-interface12] ip address 180.1.1.1 24
[SPE1-Vlan-interface12] mpls
[SPE1-Vlan-interface12] mpls ldp
[SPE1-Vlan-interface12] quit
# Configure the IGP protocol, OSPF, for example.
[SPE1] ospf
[SPE1-ospf-1] area 0
[SPE1-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0
[SPE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[SPE1-ospf-1-area-0.0.0.0] network 180.1.1.0 0.0.0.255
[SPE1-ospf-1-area-0.0.0.0] quit
[SPE1-ospf-1] quit
# Configure VPN instances vpn1 and vpn2.
[SPE1] ip vpn-instance vpn1
[SPE1-vpn-instance-vpn1] route-distinguisher 500:1
[SPE1-vpn-instance-vpn1 ] vpn-target 100:1 both
[SPE1-vpn-instance-vpn1] quit
[SPE1] ip vpn-instance vpn2
[SPE1-vpn-instance-vpn2] route-distinguisher 700:1
[SPE1-vpn-instance-vpn2] vpn-target 100:2 both
[SPE1-vpn-instance-vpn2] quit
# Configure SPE 1 to establish MP-IBGP peer relationship with UPE 1 and to inject VPN routes,
and specify UPE 1.
[SPE1] bgp 100
[SPE1-bgp] peer 1.1.1.9 as-number 100
[SPE1-bgp] peer 1.1.1.9 connect-interface loopback 0
[SPE1-bgp] peer 1.1.1.9 next-hop-local
[SPE1-bgp] peer 3.3.3.9 as-number 100
[SPE1-bgp] peer 3.3.3.9 connect-interface loopback 0
[SPE1-bgp] ipv4-family vpnv4
[SPE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[SPE1-bgp-af-vpnv4] peer 1.1.1.9 enable
[SPE1-bgp-af-vpnv4] peer 1.1.1.9 upe
[SPE1-bgp-af-vpnv4] quit
[SPE1-bgp]ipv4-family vpn-instance vpn1
[SPE1-bgp-vpn1] quit
[SPE1-bgp]ipv4-family vpn-instance vpn2
[SPE1-bgp-vpn2] quit
[SPE1-bgp] quit
# Configure SPE 1 to advertise to UPE 1 the routes permitted by a routing policy, that is, the
routes of CE 3.
[SPE1] ip ip-prefix hope index 10 permit 10.1.1.1 24
[SPE1] route-policy hope permit node 0
[SPE1-route-policy] if-match ip-prefix hope
344
[SPE1-route-policy] quit
[SPE1] bgp 100
[SPE1-bgp] ipv4-family vpnv4
[SPE1-bgp-af-vpnv4] peer 1.1.1.9 upe route-policy hope export
8.
Configure SPE 2:
# Configure basic MPLS and MPLS LDP to establish LDP LSPs.
<SPE2> system-view
[SPE2] interface loopback 0
[SPE2-LoopBack0] ip address 3.3.3.9 32
[SPE2-LoopBack0] quit
[SPE2] mpls lsr-id 3.3.3.9
[SPE2] mpls
[SPE2-mpls] quit
[SPE2] mpls ldp
[SPE2-mpls-ldp] quit
[SPE2] interface vlan-interface 12
[SPE2-Vlan-interface12] ip address 180.1.1.2 24
[SPE2-Vlan-interface12] mpls
[SPE2-Vlan-interface12] mpls ldp
[SPE2-Vlan-interface12] quit
[SPE2] interface vlan-interface 11
[SPE2-Vlan-interface11] ip address 172.2.1.2 24
[SPE2-Vlan-interface11] mpls
[SPE2-Vlan-interface11] mpls ldp
[SPE2-Vlan-interface11] quit
# Configure the IGP protocol, OSPF, for example.
[SPE2] ospf
[SPE2-ospf-1] area 0
[SPE2-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0
[SPE2-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255
[SPE2-ospf-1-area-0.0.0.0] network 180.1.1.0 0.0.0.255
[SPE2-ospf-1-area-0.0.0.0] quit
[SPE2-ospf-1] quit
# Configure VPN instances vpn1 and vpn2.
[SPE2] ip vpn-instance vpn1
[SPE2-vpn-instance-vpn1] route-distinguisher 600:1
[SPE2-vpn-instance-vpn1 ] vpn-target 100:1 both
[SPE2-vpn-instance-vpn1] quit
[SPE2] ip vpn-instance vpn2
[SPE2-vpn-instance-vpn2] route-distinguisher 800:1
[SPE2-vpn-instance-vpn2] vpn-target 100:2 both
[SPE2-vpn-instance-vpn2] quit
# Configure SPE 2 to establish MP-IBGP peer relationship with UPE 2 and to inject VPN routes,
and specify UPE 2.
[SPE2] bgp 100
[SPE2-bgp] peer 4.4.4.9 as-number 100
[SPE2-bgp] peer 4.4.4.9 connect-interface loopback 0
[SPE2-bgp] peer 4.4.4.9 next-hop-local
345
[SPE2-bgp] peer 2.2.2.9 as-number 100
[SPE2-bgp] peer 2.2.2.9 connect-interface loopback 0
[SPE2-bgp] ipv4-family vpnv4
[SPE2-bgp-af-vpnv4] peer 2.2.2.9 enable
[SPE2-bgp-af-vpnv4] peer 4.4.4.9 enable
[SPE2-bgp-af-vpnv4] peer 4.4.4.9 upe
[SPE2-bgp-af-vpnv4] quit
[SPE2-bgp]ipv4-family vpn-instance vpn1
[SPE2-bgp-vpn1] quit
[SPE2-bgp]ipv4-family vpn-instance vpn2
[SPE2-bgp-vpn2] quit
[SPE2-bgp] quit
# Configure SPE 2 to advertise to UPE 2 the routes permitted by a routing policy, that is, the
routes of CE 1.
[SPE2] ip ip-prefix hope index 10 permit
10.2.1.1 24
[SPE2] route-policy hope permit node 0
[SPE2-route-policy] if-match ip-prefix hope
[SPE2-route-policy] quit
[SPE2] bgp 100
[SPE2-bgp] ipv4-family vpnv4
[SPE2-bgp-af-vpnv4] peer 4.4.4.9 upe route-policy hope export
Configuring OSPF sham links
Network requirements
As shown in Figure 88:
•
CE 1 and CE 2 belong to VPN 1 and are connected to PE 1 and PE 2, respectively.
•
CE 1 and CE 2 are in the same OSPF area.
•
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.
Figure 88 Network diagram
Device
Interface
IP address
Device
Interface
IP address
CE 1
Vlan-int11
100.1.1.1/24
CE 2
Vlan-int11
120.1.1.1/24
346
PE 1
Switch A
Vlan-int13
20.1.1.1/24
Loop0
1.1.1.9/32
PE 2
Vlan-int12
30.1.1.2/24
Loop0
2.2.2.9/32
Loop1
3.3.3.3/32
Loop1
5.5.5.5/32
Vlan-int11
100.1.1.2/24
Vlan-int11
120.1.1.2/24
Vlan-int12
10.1.1.1/24
Vlan-int12
10.1.1.2/24
Vlan-int11
20.1.1.2/24
Vlan-int12
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 subnet addresses of
the interfaces as shown in Figure 88. (Details not shown.)
# Execute the display ip routing-table command to verify that CE 1 and CE 2 can learn the
OSPF route to the VLAN interface 1 of each other.
<CE1> display ip routing-table
Routing Tables: Public
Destinations : 9
2.
Destination/Mask
Proto
20.1.1.0/24
20.1.1.1/32
Pre
Routes : 9
Cost
NextHop
Interface
Direct 0
0
20.1.1.1
Vlan13
Direct 0
0
127.0.0.1
InLoop0
20.1.1.2/32
Direct 0
0
20.1.1.2
Vlan13
30.1.1.0/24
OSPF
3124
20.1.1.2
Vlan13
100.1.1.0/24
Direct 0
0
100.1.1.1
Vlan11
100.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
120.1.1.0/24
OSPF
3125
20.1.1.2
Vlan13
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
10
10
Configure MPLS L3VPN on the backbone:
# Configure basic MPLS 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 12
[PE1-Vlan-interface12] ip address 10.1.1.1 24
[PE1-Vlan-interface12] mpls
[PE1-Vlan-interface12] mpls ldp
[PE1-Vlan-interface12] 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
347
[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 basic MPLS 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 12
[PE2-Vlan-interface12] ip address 10.1.1.2 24
[PE2-Vlan-interface12] mpls
[PE2-Vlan-interface12] mpls ldp
[PE2-Vlan-interface12] 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 11
348
[PE1-Vlan-interface11] ip binding vpn-instance vpn1
[PE1-Vlan-interface11] ip address 100.1.1.2 24
[PE1-Vlan-interface11] 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] import-route direct
[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 11
[PE2-Vlan-interface11] ip binding vpn-instance vpn1
[PE2-Vlan-interface11] ip address 120.1.1.2 24
[PE2-Vlan-interface11] 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] import-route direct
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
# Execute the display ip routing-table vpn-instance command on the PEs. This example
uses PE 1 to verify that the path to the peer CE is along the OSPF route across the customer
networks, instead of the BGP route across the backbone.
[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
Vlan11
30.1.1.0/24
OSPF
10
3125
100.1.1.1
Vlan11
100.1.1.0/24
Direct 0
0
100.1.1.2
Vlan11
100.1.1.2/32
Direct 0
0
127.0.0.1
InLoop0
120.1.1.0/24
OSPF
3126
100.1.1.1
Vlan11
10
349
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
# Execute the display ip routing-table vpn-instance command again on the PEs. This
example uses PE 1 to verify 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.
[PE1] display ip routing-table vpn-instance vpn1
Routing Tables: vpn1
Destinations : 6
Pre
Routes : 6
Destination/Mask
Proto
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
Vlan11
100.1.1.0/24
Direct 0
0
100.1.1.2
Vlan11
100.1.1.2/32
Direct 0
0
127.0.0.1
InLoop0
120.1.1.0/24
BGP
0
2.2.2.9
NULL0
255
# Execute the display ip routing-table command on the CEs. This example uses CE 1 to
verify 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 11 connected to the PE. This means that
VPN traffic to the peer is forwarded over the backbone.
[CE1] display ip routing-table
Routing Tables: Public
Destinations : 9
Destination/Mask
Proto
20.1.1.0/24
20.1.1.1/32
Pre
Routes : 9
Cost
NextHop
Interface
Direct 0
0
20.1.1.1
Vlan13
Direct 0
0
127.0.0.1
InLoop0
20.1.1.2/32
Direct 0
0
20.1.1.2
Vlan13
30.1.1.0/24
OSPF
1574
100.1.1.2
Vlan11
100.1.1.0/24
Direct 0
0
100.1.1.1
Vlan11
100.1.1.1/32
Direct 0
0
127.0.0.1
InLoop0
120.1.1.0/24
OSPF
12
100.1.1.2
Vlan11
10
10
350
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 ospf sham-link command on the PEs to verify that a sham link has been
established, for example, on PE 1.
[PE1] display ospf sham-link
OSPF Process 100 with Router ID 100.1.1.2
Sham Link:
Area
NeighborId
Source-IP
Destination-IP
State Cost
0.0.0.1
120.1.1.2
3.3.3.3
5.5.5.5
P-2-P 10
# Execute the display ospf sham-link area command. The output shows that the peer state 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
Neighbor ID: 120.1.1.2
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
Configuring BGP AS number substitution
Network requirements
As shown in Figure 89, CE 1 and CE 2 belong to VPN 1 and are connected to PE 1 and PE 2,
respectively. CE 1 and CE 2 use the same AS number, AS 600.
Figure 89 Network diagram
Device
Interface
IP address
Device
Interface
IP address
CE 1
Vlan-int11
10.1.1.1/24
P
Loop0
2.2.2.9/32
Vlan-int12
100.1.1.1/24
Vlan-int11
30.1.1.1/24
Loop0
1.1.1.9/32
Vlan-int12
20.1.1.2/24
PE 1
351
CE 2
Vlan-int11
10.1.1.2/24
Loop0
3.3.3.9/32
Vlan-int12
20.1.1.1/24
PE 2
Vlan-int11
30.1.1.2/24
Vlan-int12
10.2.1.1/24
Vlan-int12
10.2.1.2/24
Vlan-int13
200.1.1.1/24
Configuration procedure
1.
Configuring basic MPLS L3VPN:
{
Configure OSPF on the MPLS backbone to allow the PEs and P device to learn the routes
of the loopback interfaces from each other.
{
Configure basic MPLS and MPLS LDP on the MPLS backbone to establish LDP LSPs.
{
Establish MP-IBGP peer relationship between the PEs to advertise VPN IPv4 routes.
{
Configure the VPN instance of VPN 1 on PE 2 to allow CE 2 to access the network.
{
Configure the VPN instance of VPN 1 on PE 1 to allow CE 1 to access the network.
{
Configure BGP between PE 1 and CE 1, and between PE 2 and CE 2 to inject routes of CEs
into PEs.
# Execute the display ip routing-table command on CE 2. The output shows that CE 2 has
learned the route to network 10.1.1.0/24, where the interface used by CE 1 to access PE 1
resides. However, it has not learned the route to the VPN (100.1.1.0/24) behind 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
Vlan11
10.1.1.1/32
BGP
255
0
10.2.1.2
Vlan11
10.2.1.0/24
Direct 0
0
10.2.1.1
Vlan11
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
Vlan11
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
# Execute the display ip routing-table command on CE 1 to verify that CE 1 has not learned
the route to the VPN behind CE 2. (Details not shown.)
# Execute the display ip routing-table vpn-instance command on the PEs. The output shows
the route to the VPN behind the peer CE. Take 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
Vlan11
10.2.1.1/32
Direct 0
0
10.2.1.1
Vlan11
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
Vlan11
# Enable BGP update packet debugging on PE 2. The output shows that PE 2 advertises the
route to 100.1.1.1/32, and the AS_PATH is 100 600.
352
<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,
# Execute the display bgp routing-table peer received-routes command on CE 2. The
output shows that CE 2 has not received 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, ^ - VPN best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
2.
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?
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
The output shows 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, ^ - VPN best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
*>
Network
NextHop
10.1.1.0/24
10.2.1.2
MED
LocPrf
PrefVal Path/Ogn
0
353
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
Vlan12
10.1.1.1/32
BGP
255
0
10.2.1.2
Vlan12
10.2.1.0/24
Direct 0
0
10.2.1.1
Vlan12
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
Vlan12
100.1.1.1/32
BGP
0
10.2.1.2
Vlan12
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
255
After you also configure BGP AS substitution on PE 1, the VLAN interfaces of CE 1 and CE 2
can 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
Configuring BGP AS number substitution and SoO
Network requirements
CE 1, CE 2, and CE 3 belong to VPN 1 and connect to PE1, PE 2, and PE 3, respectively. CE 1 and
CE 2 reside in the same site. CE1, CE2, and CE 3 all use AS number 600.
To avoid route loss, configure BGP AS number substitution on PEs. To avoid routing loops, configure
a routing policy on PE1 and PE2 to add the SoO attribute to routes received from CE 1 and CE 2.
354
Figure 90 Network diagram
CE 1
Loop0
Vlan-int2
MPLS backbone
AS 100
Vlan-int2
Loop0
Vlan-int3
PE 1
VPN 1
AS 600
Vlan-int4
Loop0
Loop0
Vlan-int3
Vlan-int6
Vlan-int6
PE 2
Vlan-int4
Loop0
Vlan-int5
PE 3
P
Vlan-int5
Vlan-int7
Vlan-int7
CE 3
Loop0
Vlan-int2
CE 2
VPN 1
AS 600
Vlan-int2
Device
CE 1
Interface
IP address
Device
CE 3
Loop0
100.1.1.1/32
Vlan-int2
10.1.1.1/24
CE 2
Vlan-int2
10.2.1.1/24
PE 1
Loop0
1.1.1.9/32
Vlan-int2
10.1.1.2/24
Vlan-int3
30.1.1.1/24
Vlan-int4
20.1.1.1/24
Loop0
PE 3
PE 2
Interface
IP address
Loop0
200.1.1.1/32
Vlan-int7
10.3.1.1/24
Loop0
2.2.2.9/32
Vlan-int2
10.2.1.2/24
Vlan-int4
20.1.1.2/24
Vlan-int5
40.1.1.1/24
Loop0
3.3.3.9/32
4.4.4.9/32
Vlan-int3
30.1.1.2/24
Vlan-int6
50.1.1.2/24
Vlan-int5
40.1.1.2/24
Vlan-int7
10.3.1.2/24
Vlan-int6
50.1.1.1/24
P
Configuration procedure
1.
Configure basic MPLS L3VPN:
{
{
Configure basic MPLS and MPLS LDP on the MPLS backbone to establish LDP LSPs.
{
Establish MP-IBGP peer relationships between the PEs to advertise VPN IPv4 routes.
{
Configure VPN 1 on PE 1 to allow CE 1 to access the network.
{
Configure VPN 1 on PE 2 to allow CE 2 to access the network.
{
Configure VPN 1 on PE 3 to allow CE 3 to access the network.
{
2.
Configure OSPF on the MPLS backbone to allow the PEs and P device to learn the routes
of the loopback interfaces from each other.
Configure BGP between PE 1 and CE 1, between PE 2 and CE 2, and between PE 3 and
CE 3 to inject routes of CEs into PEs.
Configure BGP AS number substitution:
# Configure BGP AS number substitution on PE 1, PE2, and PE3 as described in "Configuring
BGP AS number substitution."
# Display routing information on CE 2. The output shows that CE 2 has learned the route
100.1.1.1/32 to CE 1. A routing loop has occurred because CE1 and CE 2 reside in the same
site.
<CE2> display bgp routing-table peer 10.2.1.2 received-routes
355
Total Number of Routes: 8
BGP Local router ID is 10.2.1.1
Status codes: * - valid, ^ - VPN best, > - best, d - damped,
h - history,
i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
3.
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?
*
10.3.1.0/24
10.2.1.2
0
100?
*
10.3.1.1/32
10.2.1.2
0
100?
*>
100.1.1.1/32
10.2.1.2
0
100 100?
*>
200.1.1.1/32
10.2.1.2
0
100 100?
Configure the SoO attribute:
# On PE 1, configure a routing policy named soo to add the specified SoO attribute.
<PE1> system-view
[PE1] route-policy soo permit node 10
[PE1-route-policy] apply extcommunity soo 1:100 additive
[PE1-route-policy] quit
# On PE 1, apply the routing policy soo to routes received from CE 1.
[PE1] bgp 100
[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] peer 10.1.1.1 route-policy soo import
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
# On PE 2, configure a routing policy named soo to add the specified SoO attribute.
<PE2> system-view
[PE2] route-policy soo permit node 10
[PE2-route-policy] apply extcommunity soo 1:100 additive
[PE2-route-policy] quit
# On PE 2, apply the routing policy soo to routes received from CE 2.
[PE2] bgp 100
[PE2-bgp] ipv4-family vpn-instance vpn1
[PE2-bgp-vpn1] peer 10.2.1.1 route-policy soo import
[PE2-bgp-vpn1] quit
[PE2-bgp] quit
# PE 2 does not advertise routes received from CE 1 to CE 2 because the same SoO attribute
has been configured. Display the routing table of CE 2. The output shows that the route
100.1.1.1/32 has been removed.
<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
Vlan2
10.1.1.1/32
BGP
255
0
10.2.1.2
Vlan2
10.2.1.0/24
Direct 0
0
10.2.1.1
Vlan2
10.2.1.1/32
Direct 0
0
127.0.0.1
InLoop0
356
10.3.1.0/24
BGP
255
0
10.2.1.2
Vlan2
10.3.1.1/32
BGP
255
0
10.2.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
200.1.1.1/32
BGP
0
10.2.1.2
Vlan2
255
357
Configuring IPv6 MPLS L3VPN
This chapter describes how to configure IPv6 MPLS L3VPN.
Hardware compatibility
The HPE 5820X Switch Series does not support IPv6 MPLS L3VPN.
Overview
MPLS L3VPN applies to the IPv4 environment. It uses BGP to advertise IPv4 VPN routes and uses
MPLS to forward IPv4 VPN packets on the service provider backbone.
IPv6 MPLS L3VPN functions similarly. It uses BGP to advertise IPv6 VPN routes and uses MPLS to
forward IPv6 VPN packets on the service provider backbone.
Figure 91 shows the typical IPv6 MPLS L3VPN model. The service provider backbone in the IPv6
MPLS L3VPN model is an IPv4 network. IPv6 runs inside the VPNs and between CEs and PEs.
Therefore, PEs must support both IPv4 and IPv6. The PE-CE interfaces of a PE run IPv6 and the
PE-P interface of a PE runs IPv4.
Figure 91 Network diagram for the IPv6 MPLS L3VPN model
VPN 1
IPv6 Site 1
VPN 2
IPv6 Site 3
IPv4 network
P
P
CE
CE
PE
PE
CE
P
P
PE
IPv6 Site 2
VPN 2
CE
IPv6 Site 4
VPN 1
358
IPv6 MPLS L3VPN packet forwarding
Figure 92 IPv6 MPLS L3VPN packet forwarding diagram
As shown in Figure 92, the IPv6 MPLS L3VPN packet forwarding procedure is as follows:
1.
The PC at Site 1 sends an IPv6 packet destined for 2001:2::1, the PC at Site 2. CE 1 transmits
the packet to PE 1.
2.
Based on the inbound interface and destination address of the packet, PE 1 searches the
routing table of the VPN instance. 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. The outer label is removed
from the packet at the penultimate hop.
4.
According to the inner label and destination address of the packet, PE 2 searches the routing
table of the VPN instance to determine the outbound interface and then forwards the packet out
the interface to CE 2.
5.
CE 2 forwards the packet to the destination by IPv6 forwarding.
IPv6 MPLS L3VPN routing information advertisement
A route become available from the local CE to the remote CE after it is advertised from the local CE
to the ingress PE, from the ingress PE to the egress PE, and then from the egress PE to the remote
peer CE.
Routing information exchange from the local CE to the ingress PE
After establishing an adjacency with the directly connected PE, a CE advertises its IPv6 VPN routes
to the PE.
The routes between a CE and a PE can be IPv6 static routes, RIPng routes, OSPFv3 routes, IPv6
IS-IS routes, or EBGP routes. No matter which routing protocol is used, the CE always advertises
standard IPv6 routes to the PE.
Routing information exchange from the ingress PE to the egress PE
After learning the IPv6 VPN routes from the CE, the ingress PE adds RDs and route targets for these
standard IPv6 routes to create VPN-IPv6 routes, saves them to the routing table of the VPN instance
created for the CE, and then triggers MPLS to assign VPN labels for them.
Then, the ingress PE advertises the VPN-IPv6 routes to the egress PE through MP-BGP.
Finally, the egress PE compares the export target attributes of the VPN-IPv6 routes with the import
target attributes that it maintains for the VPN instance and, if they are the same, adds the routes to
the routing table of the VPN instance.
The PEs use an IGP to ensure the connectivity between them.
359
Routing information exchange from the egress PE to the remote CE
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.
IPv6 MPLS L3VPN network schemes and functions
IPv6 MPLS L3VPN supports the following network schemes and functions:
•
Basic VPN
•
Inter-AS VPN option A
•
Inter-AS VPN option C
•
Carrier's carrier
IPv6 MPLS L3VPN configuration task list
Task
Remarks
Configuring basic IPv6 MPLS L3VPN
By configuring basic IPv6 MPLS L3VPN, you can
construct simple IPv6 VPN networks over an MPLS
backbone.
To deploy special IPv6 MPLS L3VPN networks,
such as inter-AS VPN, you must also perform some
specific configurations in addition to the basic IPv6
MPLS L3VPN configuration. For more information,
see the related sections.
Configuring inter-AS IPv6 VPN
Configuring basic IPv6 MPLS L3VPN
The key task in IPv6 MPLS L3VPN configuration is to manage the advertisement of IPv6 VPN routes
on the MPLS backbone, including PE-CE route exchange and PE-PE route exchange.
Complete the following tasks to configure basic IPv6 MPLS L3VPN:
Task
Configuring VPN instances
Remarks
Creating a VPN instance
Required.
Associating a VPN instance with an interface
Required.
Configuring route related attributes for a VPN
instance
Optional.
Configuring a tunneling policy for a VPN instance
Optional.
Configuring an LDP instance
Optional.
Configuring routing between PE and CE
Required.
Configuring routing between PEs
Required.
Configuring routing features for the BGP-VPNv6 subaddress family
Optional.
Before configuring basic IPv6 MPLS L3VPN, complete the following tasks:
•
Configure an IGP on the PEs and Ps to ensure IP connectivity within the MPLS backbone.
•
Configure basic MPLS for the MPLS backbone.
360
•
Configure MPLS LDP on PEs and Ps to establish LDP LSPs.
Configuring VPN instances
By configuring VPN instances on a PE, you isolate not only VPN routes from public network routes,
but also routes of a VPN from those of another VPN. This feature allows VPN instances to be used in
network scenarios besides MPLS L3VPNs.
All VPN instance configurations are performed on PEs or MCEs.
Creating a VPN instance
A VPN instance is associated with a site. It is a collection of the VPN membership and routing rules of
its associated site. A VPN instance does not necessarily correspond to one VPN.
To create and configure a VPN instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a VPN instance and
enter VPN instance view.
ip vpn-instance
vpn-instance-name
N/A
3.
Configure an RD for the VPN
instance.
route-distinguisher
route-distinguisher
A VPN instance takes effect only
after you configure an RD for it.
Optional.
4.
Configure a description for
the VPN instance.
description text
The description should contain
the VPN instance's related
information, such as its
relationship with a certain VPN.
Associating a VPN instance with an interface
After creating and configuring a VPN instance, you must associate the VPN instance with the
interface for connecting the CE. Any LDP-capable interface can be associated with a VPN instance.
For information about LDP-capable interfaces, see "Configuring basic MPLS."
To associate a VPN instance with an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
By default, no VPN instance is
associated with an interface.
3.
Associate a VPN instance
with the interface.
ip binding vpn-instance
vpn-instance-name
Associating the interface with a
VPN instance clears the IPv6
address of the interface.
Therefore, you must reconfigure
the IPv6 address of the interface
after executing this command.
Configuring route related attributes for a VPN instance
The control process of VPN route advertisement is as follows:
361
•
When a VPN route learned from a CE gets redistributed into BGP, BGP associates it with a
route target extended community attribute list, which is usually the export target attribute of the
VPN instance associated with the CE.
•
The VPN instance determines which routes it can accept and redistribute according to the
import-extcommunity in the route target.
•
The VPN instance determines how to change the route targets attributes for routes to be
advertised according to the export-extcommunity in the route target.
To configure route related attributes for a VPN instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VPN instance view.
ip vpn-instance
vpn-instance-name
N/A
3.
Enter IPv6 VPN view.
ipv6-family
Optional.
Configure route targets.
vpn-target vpn-target&<1-8>
[ both | export-extcommunity |
import-extcommunity ]
A single vpn-target command
can configure up to eight route
targets. You can configure up to
64 route targets for a VPN
instance.
4.
Optional.
5.
Set the maximum number of
routes supported.
routing-table limit number
{ warn-threshold | simply-alert }
Setting the maximum number of
routes for a VPN instance to
support is for preventing too many
routes from being redistributed
into the PE.
Optional.
6.
Apply an import routing
policy.
import route-policy route-policy
By default, all routes matching the
import target attribute are
accepted.
Make sure the routing policy
already exists. Otherwise, the
switch does not filter received
routes.
Optional.
7.
Apply an export routing
policy.
By default, routes to be advertised
are not filtered.
export route-policy route-policy
Make sure the routing policy
already exists. Otherwise, the
switch does not filter routes to be
advertised.
NOTE:
• Route related attributes configured in VPN instance view are applicable to both IPv4 VPNs and
IPv6 VPNs.
• You can configure route related attributes for IPv6 VPNs in both VPN instance view and IPv6
VPN view. Those configured in IPv6 VPN view take precedence.
Configuring a tunneling policy for a VPN instance
When multiple tunnels exist in an MPLS L3VPN network, you can configure a tunneling policy to
specify the type and number of tunnels to be used by using the tunnel select-seq command or the
preferred-path command.
362
With the tunnel select-seq command, you can specify the tunnel selection preference order and the
number of tunnels for load balancing.
With the preferred-path command, you can configure preferred tunnels that each correspond to a
tunnel interface.
After a tunneling policy is applied on a PE, the PE selects tunnels in this order:
•
The PE matches the peer PE address against the destination addresses of preferred tunnels,
starting from the tunnel with the smallest number. If no match is found, the local PE selects
tunnels as configured by the tunnel select-seq command or the default tunneling policy if the
tunnel select-seq command is not configured. The default tunneling policy selects only one
tunnel (no load balancing) in this order: LSP tunnel, CR-LSP tunnel.
•
If a matching tunnel is found and the tunnel is available, the local PE stops matching other
tunnels and forwards the traffic to the specified tunnel interface.
•
If the matching tunnel is unavailable (for example, the tunnel is down or the tunnel's ACL does
not permit the traffic) and is not specified with the disable-fallback keyword, the local PE
continues to match other tunnels. If the tunnel is specified with the disable-fallback keyword,
the local PE stops matching and tunnel selection fails.
IMPORTANT:
Create a tunneling policy before applying it to a VPN instance. Otherwise, the default tunneling
policy is used. The default tunneling policy selects only one tunnel in this order: LSP tunnel, CR-LSP
tunnel.
To configure a tunneling policy for a VPN instance:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a tunneling
policy and enter
tunneling policy view.
tunnel-policy
tunnel-policy-name
N/A
Optional.
By default, no preferred tunnel is
configured.
3.
Configure a preferred
tunnel and specify a
tunnel interface for it.
preferred-path number
interface tunnel
tunnel-number
[ disable-fallback ]
363
NOTE:
•
In a tunneling policy, you can
configure up to 64 preferred tunnels.
•
The tunnel interfaces specified for
the preferred tunnels can have the
same destination address and the
tunnel encapsulation type must be
MPLS TE.
Step
Command
Remarks
Optional.
By default, only one tunnel is selected (no
load balancing) in this order: LSP tunnel,
CR-LSP tunnel.
NOTE:
•
A tunnel type closer to the
select-seq keyword has a higher
priority. For example, with the tunnel
select-seq lsp cr-lsp
load-balance-number 1 command
configured, VPN uses a CR-LSP
tunnel only when no LSP exists.
After an LSP is created, the VPN
uses the LSP tunnel instead.
•
If you specify more than one tunnel
type and the number of tunnels of a
type is less than the specified
number of tunnels for load
balancing, tunnels of different types
may be used.
Specify the tunnel
selection preference
order and the number of
tunnels for load
balancing.
tunnel select-seq { cr-lsp |
lsp } * load-balance-number
number
5.
Return to system view.
quit
N/A
6.
Enter VPN instance
view.
ip vpn-instance
vpn-instance-name
N/A
7.
Enter IPv6 VPN view.
ipv6-family
Optional.
8.
Apply the tunneling
policy to the VPN
instance.
tnl-policy tunnel-policy-name
By default, only one tunnel is selected (no
load balancing) in this order: LSP tunnel,
CR-LSP tunnel.
4.
NOTE:
• A tunneling policy configured in VPN instance view is applicable to both IPv4 VPNs and IPv6
VPNs.
• You can configure a tunneling policy for IPv6 VPNs in both VPN instance view and IPv6 VPN
view. A tunneling policy configured in IPv6 VPN view takes precedence.
Configuring an LDP instance
LDP instances are for carrier's carrier network applications.
This task is to enable LDP for an existing VPN instance, create an LDP instance for the VPN instance,
and configure LDP parameters for the LDP instance.
For LDP instance configuration information, see "Configuring MPLS L3VPN."
Configuring routing between PE and CE
You can configure IPv6 static routing, RIPng, OSPFv3, IPv6 IS-IS, or EBGP between PE and CE.
Before configuring routing between PE and CE, complete the following tasks:
•
Assign an IPv6 address to the CE-PE interface of the CE
•
Assign an IPv6 address to the PE-CE interface of the PE
Configuring IPv6 static routing between PE and CE
364
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
•
2.
Configure an IPv6 static
route for a VPN
instance.
•
ipv6 route-static ipv6-address prefix-length
{ interface-type interface-number
[ next-hop-address ] | next-hop-address |
vpn-instance d-vpn-instance-name
nexthop-address } [ preference
preference-value ] [ tag tag-value ]
[ description description-text ]
ipv6 route-static vpn-instance
s-vpn-instance-name&<1-6> ipv6-address
prefix-length { interface-type interface-number
[ next-hop-address ] | nexthop-address
[ public ] | vpn-instance
d-vpn-instance-name nexthop-address }
[ preference preference-value ] [ tag
tag-value ] [ description description-text ]
Use either command
as needed.
Perform this
configuration on PEs.
On CEs, configure
normal IPv6 static
routes.
For information about
IPv6 static routing,
see Layer 3—IP
Routing
Configuration Guide.
Configuring RIPng between PE and CE
A RIPng process belongs to the public network or a single VPN instance. If you create a RIPng
process without binding it to a VPN instance, the process belongs to the public network.
For more information about RIPng, see Layer 3—IP Routing Configuration Guide.
To configure RIPng between PE and CE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RIPng process for a
VPN instance and enter
RIPng view.
ripng [ process-id ] vpn-instance
vpn-instance-name
Perform this configuration on
PEs. On CEs, create a normal
RIPng process.
3.
Return to system view.
quit
N/A
4.
Enter interface view.
interface interface-type
interface-number
N/A
5.
Enable RIPng on the
interface.
ripng process-id enable
By default, RIPng is disabled on
an interface.
Configuring OSPFv3 between PE and CE
An OSPFv3 process belongs to the public network or a single VPN instance. If you create an OSPF
process without binding it to a VPN instance, the process belongs to the public network.
For more information about OSPFv3, see Layer 3—IP Routing Configuration Guide.
To configure OSPFv3 between PE and CE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an OSPFv3 process
for a VPN instance and enter
the OSPFv3 view.
ospfv3 [ process-id ]
vpn-instance vpn-instance-name
Perform this configuration on
PEs. On CEs, create a normal
OSPF process.
3.
Set the router ID.
router-id router-id
N/A
4.
Return to system view.
quit
N/A
365
Step
Command
Remarks
N/A
5.
Enter interface view.
interface interface-type
interface-number
6.
Enable OSPFv3 on the
interface.
ospfv3 process-id area area-id
[ instance instance-id ]
By default, OSPFv3 is disabled on
an interface.
Perform this configuration on
PEs.
Configuring IPv6 IS-IS between PE and CE
An IPv6 IS-IS process belongs to the public network or a single VPN instance. If you create an IPv6
IS-IS process without binding it to a VPN instance, the process belongs to the public network.
For more information about IPv6 IS-IS, see Layer 3—IP Routing Configuration Guide.
To configure IPv6 IS-IS between PE and CE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IPv6 IS-IS
process for a VPN instance
and enter IS-IS view.
isis [ process-id ] vpn-instance
vpn-instance-name
Perform this configuration on
PEs. On CEs, create a normal
IPv6 IS-IS process.
3.
Configure a network entity
title for the IS-IS process.
network-entity net
Not configured by default.
4.
Enable the IPv6 capacity for
the IS-IS process.
ipv6 enable
Disabled by default.
5.
Return to system view.
quit
N/A
6.
Enter interface view.
interface interface-type
interface-number
N/A
7.
Enable the IPv6 capacity for
the IS-IS process on the
interface.
isis ipv6 enable [ process-id ]
Disabled by default.
Configuring EBGP between PE and CE
1.
Configure the PE:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable BGP and enter BGP
view.
bgp as-number
N/A
3.
Enter IPv6 BGP-VPN
instance view.
ipv6-family vpn-instance
vpn-instance-name
N/A
4.
Configure the CE as the
VPN EBGP peer.
peer ipv6-address as-number
as-number
N/A
5.
Specify the source interface
for establishing TCP
connections to the peer.
peer ipv6-address
connect-interface interface-type
interface-number
By default, BGP uses the
outgoing interface of the optimal
route to the peer as the source
interface.
6.
Redistribute the routes of the
local CEs.
import-route protocol
[ process-id ] [ med med-value |
route-policy route-policy-name ]
*
A PE must redistribute the routes
of the local CEs into its VPN
routing table so that it can
advertise them to the peer PE.
366
Step
Command
Remarks
Configure a filtering policy to
filter the routes to be
advertised.
filter-policy { acl6-number |
ipv6-prefix ipv6-prefix-name }
export [ direct | isisv6 process-id
| ripng process-id | static ]
Optional.
8.
Configure a filtering policy to
filter received routes.
filter-policy { acl6-number |
ipv6-prefix ipv6-prefix-name }
import
Optional.
9.
Advertise the COMMUNITY
attribute to the peer.
peer ipv6-address
advertise-community
By default, BGP does not
advertise the COMMUNITY
attribute to any peers.
Command
Remarks
7.
2.
By default, BGP does not filter
routes to be advertised.
By default, the PE does not filter
received routes.
Configure the CE:
Step
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Enter IPv6 BGP subaddress
family view.
ipv6-family
N/A
4.
Configure the PE as the
EBGP peer.
peer ipv6-address as-number
as-number
N/A
5.
Configure route
redistribution and
advertisement.
import-route protocol
[ process-id ] [ med med-value |
route-policy route-policy-name ]
*
Optional.
A CE must advertise its VPN
routes to the connected PE so
that the PE can advertise them to
the peer CE.
NOTE:
• After an IPv6 BGP-VPN instance is configured, exchange of BGP routes for the VPN instance is
the same as exchange of ordinary BGP routes.
• The configuration commands available in IPv6 BGP-VPN instance view are the same as those in
IPv6 BGP subaddress family view. For more configuration commands in the two views, see
Layer 3—IP Routing Configuration Guide.
Configuring routing between PEs
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure the remote PE as
the peer.
peer ip-address as-number
as-number
N/A
4.
Specify the source interface
for route update packets.
peer { group-name | ip-address }
connect-interface interface-type
interface-number
By default, BGP uses the
outbound interface of the best
route to the BGP peer.
5.
Enter BGP-VPNv6
subaddress family view.
ipv6-family vpnv6
N/A
367
Step
6.
Enable the exchange of
BGP-VPNv6 routing
information with the
specified peer.
Command
Remarks
peer ip-address enable
By default, BGP peers exchange
only IPv4 routing information.
Configuring routing features for the BGP-VPNv6 subaddress
family
A variety of routing features for the BGP-VPNv6 subaddress family are the same as those for BGP
IPv6 unicast routing. You can select any of the features as required.
To configure routing features for the BGP-VPNv6 subaddress family:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure the remote PE as
the peer.
peer ip-address as-number
as-number
N/A
4.
Specify the interface for TCP
connections.
peer ip-address
connect-interface interface-type
interface-number
N/A
5.
Enter BGP-VPNv6
subaddress family view.
ipv6-family vpnv6
N/A
6.
Set the default value of the
local preference.
default local-preference value
7.
Set the default value for the
system MED.
default med med-value
By default, the default value of the
system MED is 0.
8.
Configure a filtering policy to
filter routes to be advertised.
filter-policy { acl6-number |
ipv6-prefix ipv6-prefix-name }
export [ direct | isisv6 process-id
| ripng process-id | static ]
Optional.
9.
Configure a filtering policy to
filter received routes.
filter-policy { acl6-number |
ipv6-prefix ipv6-prefix-name }
import
Optional.
Optional.
100 by default.
Optional.
By default, the PE does not filter
routes to be advertised.
By default, the PE does not filter
received routes.
Optional.
10. Advertise the COMMUNITY
attribute to the peer.
peer ip-address
advertise-community
11. Apply a filtering policy for the
peer.
peer ip-address filter-policy
acl6-number { export | import }
12. Apply an IPv6-prefix list for
the peer to filter
received/advertised routes.
peer ip-address ipv6-prefix
prefix-name { export | import }
13. Specify the preference value
for the routes received from
the peer.
peer ip-address preferred-value
value
368
By default, BGP does not
advertise the COMMUNITY
attribute to any peers.
Optional.
By default, no filtering policy is
applied for a peer.
Optional.
By default, no IPv6 prefix list is
applied for a peer.
Optional.
0 by default.
Step
Command
Remarks
14. Configure BGP updates to
the peer to not carry private
AS numbers.
peer ip-address public-as-only
By default, a BGP update carries
private AS numbers.
15. Apply a routing policy for the
peer.
peer ip-address route-policy
route-policy-name { export |
import }
Optional.
16. Enable route target filtering
for received BGP-VPNv6
subaddress family routes.
policy vpn-target
17. Configure the local PE as the
route reflector and specify
the peer as the client.
peer ip-address reflect-client
18. Enable route reflection
between clients.
reflect between-clients
Optional.
By default, no routing policy is
applied for a peer.
Optional.
Enabled by default.
Optional.
No route reflector or client is
configured by default.
Optional.
Enabled by default.
Optional.
19. Configure a cluster ID for the
route reflector.
reflector cluster-id { cluster-id |
ip-address }
By default, each RR in a cluster
uses its own router ID as the
cluster ID.
If more than one RR exists in a
cluster, use this command to
configure the same cluster ID for
all RRs in the cluster to avoid rout
loops.
Optional.
By default, an RR does not filter
the reflected routes.
20. Create an RR reflection
policy.
rr-filter
extended-community-list-number
With an RR reflection policy, only
IBGP routes whose Extended
Communities attribute matches
the specified one are reflected.
By configuring different RR
reflection policies on different
RRs, you can implement load
balancing among the RRs.
For more information about IPv6 BGP routing features, see Layer 3—IP Routing Configuration
Guide.
Configuring inter-AS IPv6 VPN
If the MPLS backbone that carries the IPv6 VPN routes spans multiple ASs, you must configure
inter-AS IPv6 VPN.
There are three inter-AS VPN solutions (for more information, see "Configuring MPLS L3VPN").
Currently, IPv6 MPLS L3VPN supports only inter-AS VPN option A and option C.
Before configuring inter-AS IPv6 VPN, complete these tasks:
•
Configuring an IGP for the MPLS backbone in each AS to ensure IP connectivity
•
Configuring basic MPLS for the MPLS backbone of each AS
•
Configuring MPLS LDP for the MPLS backbones so that LDP LSPs can be established
369
The following sections describe inter-AS IPv6 VPN option A and option C. Select one according to
your network scenario.
Configuring inter-AS IPv6 VPN option A
Inter-AS IPv6 VPN option A applies to scenarios where the number of VPNs and that of VPN routes
on the PEs are relatively small. It is easy to implement.
To configure inter-AS IPv6 option A:
•
Perform basic IPv6 Configuring MPLS L3VPN on each AS.
•
Configure each ASBR, taking the peer ASBR PE as its CE.
In other words, configure VPN instances on both PEs and ASBR PEs. The VPN instances on PEs
allow CEs to access the network, and those on ASBR PEs are for access of the peer ASBR PEs.
For configuration information, see "Configuring MPLS L3VPN."
In the inter-AS IPv6 VPN option A solution, for the same IPv6 VPN, the route targets configured on
the PEs must match those configured on the ASBR-PEs in the same AS to ensure that VPN routes
sent by the PEs (or ASBR-PEs) can be received by the ASBR-PEs (or PEs). Route targets
configured on the PEs in different ASs do not have such requirements.
Configuring inter-AS IPv6 VPN option C
To configure inter-AS IPv6 option C, perform proper configurations on PEs and ASBR PEs, and
configure routing policies on the ASBR PEs.
Configuring the PEs
Establish ordinary IBGP peer relationships between PEs and ASBR PEs in an AS and MP-EBGP
peer relationships between PEs in different ASs.
The PEs and ASBR PEs in an AS must be able to exchange labeled routes.
To configure a PE for inter-AS IPv6 VPN option C:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter BGP view.
bgp as-number
N/A
3.
Configure the ASBR PE in
the same AS as the IBGP
peer.
peer { group-name | ip-address }
as-number as-number
N/A
4.
Enable the PE to exchange
labeled routes with the
ASBR PE in the same AS.
peer { group-name | ip-address }
label-route-capability
By default, the PE does not
advertise labeled routes to the
IPv4 peer/peer group.
5.
Configure the PE of another
AS as the EBGP peer.
peer { group-name | ip-address }
as-number as-number
N/A
6.
Enter BGP-VPNv6
subaddress family view.
ipv6-family vpnv6
N/A
7.
Enable the PE to exchange
BGP VPNv6 routing
information with the EBGP
peer.
peer ip-address enable
N/A
370
Configuring the ASBR PEs
In the inter-AS IPv6 VPN option C solution, an inter-AS LSP is required, and the routes advertised
between the relevant PEs and ASBRs must carry MPLS label information. The configuration is the
same as that in the Inter-AS IPv4 VPN option C solution. For more information, see "Configuring
MPLS L3VPN."
Configuring the routing policy
After you configure and apply a routing policy on an ASBR PE, it does the following:
•
Assigns MPLS labels to routes received from the PEs in the same AS before advertising them
to the peer ASBR PE.
•
Assigns new MPLS labels to the labeled routes to be advertised to the PEs in the same AS.
The configuration is the same as that in the Inter-AS IPv4 VPN option C solution. For more
information, see "Configuring MPLS L3VPN."
Resetting IPv6 BGP connections
When BGP configuration changes, use the soft reset function or reset BGP connections to make the
changes take effect. Soft reset requires that BGP peers have the route refreshment capability, which
means supporting Route-Refresh messages.
Soft reset of BGP connections refers to updating BGP routing information without breaking BGP
neighbor relationships. Hard reset of BGP connections refers to updating BGP routing information by
breaking and then reestablishing BGP neighbor relationships.
To hard reset or soft reset BGP connections:
Task
Command
Remarks
Soft reset the IPv6 BGP
connections of a VPN instance.
refresh bgp ipv6 vpn-instance
vpn-instance-name { ipv6-address | all |
external } { export | import }
Available in user view.
Soft reset the BGP VPNv6
connections.
refresh bgp vpnv6 { ip-address | all |
external | internal } { export | import }
Available in user view.
Hard reset the IPv6 BGP
connections of a VPN instance.
reset bgp ipv6 vpn-instance
vpn-instance-name { as-number |
ipv6-address | all | external }
Available in user view.
Hard reset BGP VPNv6
connections.
reset bgp vpnv6 { as-number | ip-address |
all | external | internal }
Available in user view.
Displaying and maintaining IPv6 MPLS L3VPN
Task
Command
Remarks
Display information about the
IPv6 routing table associated with
a VPN instance.
display ipv6 routing-table vpn-instance
vpn-instance-name [ verbose ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about a
specific or all VPN instances.
display ip vpn-instance [ instance-name
vpn-instance-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any v