Enterprise products and services are set forth in the express warranty statements acco mpanying such
products and services. Nothing herein should be construe d as constituting an additional warranty. Hewlett
Packard Enterprise shall not be liable for technical or editorial errors or omissions co ntained herein.
Confidential computer software. V alid 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 T e chnical 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 In corporated.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.
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
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
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
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
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 the FRR polling timer ·········································································································· 119
Inspecting an MPLS TE tunnel ······················································································································ 119
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 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
Configuring PW redundancy for H-VPLS access ··················································································· 192
Configuring BFD for the primary link in an H-VPLS network ·································································· 197
Troubleshooting VPLS ··································································································································· 201
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
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 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
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 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
Remote support ······································································································································ 402
Index ··········································································································· 403
vi
Configuring MCE
This chapter covers only MCE-related configuration. For information about routing protocols, see
Layer 3—IP Services Configuration Gui de.
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 num ber: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 se
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
and how an MCE exchanges VPN routes with PEs.
rvices and higher security, a private network is usually divided into multiple VPNs to
how an MCE maintains the routing entries of multiple VPNs
4
Figure 3 Network diagram for the MCE function
VPN 1
Site 1
VPN 2
Site 2
VLAN-int2
VLAN-int3
MCE
P
PE1
VLAN-int7
VLAN-int8
P
PE
VPN 2
Site 1
CE
PE2
CE
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 th
rough 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)
VPN 1
VPN 1
Site1
MCE
IP network
T
u
n
n
e
CE
l
2
Site2
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
RIP
OSPF
emergence of MCE. MCE allows static-route-to-VPN-instance binding, which isolates the static
routes of different VPNs.
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.
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.
2. Create a VPN instance and
enter VPN instance view.
3. Configure an RD for the VPN
instance.
4. Configure a description for
the VPN instance.
system-view
ip vpn-instance
vpn-instance-name
route-distinguisher
route-distinguisher
description
text
N/A
N/A
For easy management, set the
same RD for the same VPN
instance on the MCE and the PE.
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.
7. Associate the interface with
a VPN instance.
interface
interface-number
ip binding vpn-instance
vpn-instance-name
interface-type
N/A
By default, no VPN instance is
associated with any interface.
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.
2. Enter VPN instance view.
3. Enter IPv4 VPN view.
4. Associate the current VPN
instance with one or more
route targets.
5. Configure the maximum
number of routes for the
VPN instance.
system-view
ip vpn-instance
vpn-instance-name
ipv4-family
vpn-target
both
[
import-extcommunity
routing-table limit
{ warn-threshold |
export-extcommunity
|
vpn-target&<1-8>
number
simply-alert
N/A
N/A
Optional.
A single
can configure up to eight route
|
targets. You can configure up to
]
64 route targets for a VPN
instance.
Optional.
Not configured by default.
Setting the maximum number of
routes for a VPN instance to
}
support is for preventing too many
routes from being redistributed
into the PE.
vpn-target
command
9
Step Command Remarks
6. Apply an import routing
policy to the current VPN
instance.
7. Apply an export routing
policy to the current VPN
instance.
NOTE:
import route-policy
export route-policy
route-policy
route-policy
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
Optional.
By default, all routes permitted by
the import target attribute can be
redistributed into the VPN
instance.
Optional.
By default, all VPN instance
routes permitted by the export
target attribute can be
redistributed.
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:
Perform this
configuration on the
MCE. On a VPN site,
configure a normal static
route.
3. Configure the default
precedence for static
routes.
ip route-static default-preference
default-preference-value
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.
2. Create a RIP process for a
VPN instance and enter RIP
view.
3. Enable RIP on the interface
attached to the specified
network.
4. Redistribute remote site
routes advertised by the PE.
5. Configure the default cost
value for the redistributed
routes.
system-view
rip
[ process-id ]
vpn-instance-name
network
import-route
[
process-id
cost
route-policy-name |
default cost
network-address
] [
| route-policy
value
vpn-instance
tag
tag ] *
protocol
allow-ibgp
] [
cost
Optional.
The default setting is 60.
N/A
Perform this configuration on the
MCE. On a VPN site, create a
normal RIP process.
By default, RIP is disabled on an
interface.
By default, no route is
redistributed into RIP.
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 Command Remarks
1. Enter system view.
2. Create an OSPF process for
a VPN instance and enter
OSPF view.
3. Configure the OSPF domain
ID.
system-view
ospf
[ process-id |
router-id |
vpn-instance-name ] *
domain-id
secondary
[
vpn-instance
domain-id
]
router-id
N/A
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.
Perform this configuration on the
MCE. On a VPN site, perform the
common OSPF configuration.
4. Redistribute remote site
routes advertised by the PE.
5. Create an OSPF area and
enter OSPF area view.
6. Enable OSPF on the
interface attached to the
specified network in the
area.
import-route
[ process-id |
cost |
route-policy
*
area
area-id
network
wildcard-mask
protocol
allow-ibgp
type
type |
route-policy-name ]
ip-address
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.
tag
tag |
] [
cost
By default, no route of any other
routing protocol is redistributed
into OSPF.
By default, no OSPF area is
created.
By default, an interface neither
belongs to any area nor runs
OSPF.
To configure IS-IS between an MCE and a VPN site:
Step Command Remarks
1. Enter system view.
2. Create an IS-IS process for a
VPN instance and enter
IS-IS view.
3. Configure a network entity
title.
system-view
isis
[ process-id ]
vpn-instance-name
network-entity
vpn-instance
net
12
N/A
Perform this configuration on the
MCE. On a VPN site, configure a
normal IS-IS process.
Not configured by default.
Step Command Remarks
Optional.
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.
N/A
4. Redistribute remote site
routes advertised by the PE.
5. Return to system view.
import-route
ospf
[ process-id ] |
[ process-id ] |
direct
cost-type
[
route-policy
tag
quit
|
level-1
tag ] *
static
external
{
level-1-2
|
isis
{
[ process-id ] |
rip
bgp
allow-ibgp
[
cost
} [
cost |
internal
|
level-2
|
route-policy-name |
] |
6. Enter interface view.
7. Enable the IS-IS process on
the interface.
interface
interface-number
isis enable
interface-type
[ process-id ]
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.
2. Enter BGP view.
3. Enter BGP-VPN instance
view.
4. Configure an EBGP peer.
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.
system-view
bgp
as-number N/A
ipv4-family vpn-instance
vpn-instance-name
peer
{ group-name | ip-address }
as-number
peer
allow-as-loop
as-number
{ group-name | ip-address }
[ number ]
N/A
Disabled by default.
N/A
N/A
N/A
Optional.
6. Redistribute remote site
routes advertised by the PE.
7. Configure a filtering policy to
filter the routes to be
advertised.
8. Configure a filtering policy to
filter the received routes.
import-route
[ process-id |
med
[
route-policy-name ] *
filter-policy
ip-prefix
direct | isis
[
process-id |
static
filter-policy
ip-prefix
protocol
all-processes
med-value
ip-prefix-name }
]
| route-policy
{ acl-number |
process-id |
rip
process-id |
{ acl-number |
ip-prefix-name }
13
]
export
ospf
import
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.
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.
3. Configure the MCE as the
EBGP peer.
4. Redistribute the IGP routes
of the VPN.
bgp
as-number N/A
peer
{ group-name | ip-address }
as-number
import-route
[ process-id ] [
route-policy
*
as-number
protocol
med
route-policy-name ]
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.
2. Enter BGP view.
3. Enter BGP-VPN instance
view.
4. Configure an IBGP peer.
system-view
bgp
as-number N/A
ipv4-family vpn-instance
vpn-instance-name
peer
{ group-name | ip-address }
as-number
as-number
med-value |
N/A
Optional.
A VPN site must advertise the
VPN network addresses it can
reach to the connected MCE.
N/A
N/A
N/A
5. Configure the system to be
the RR and specify the peer
as the client of the RR.
6. Redistribute remote site
routes advertised by the PE.
7. Configure a filtering policy to
filter the routes to be
advertised.
8. Configure a filtering policy to
filter the received routes.
peer
{ group-name | ip-address }
reflect-client
import-route
[ process-id |
med
[
route-policy-name ] *
filter-policy
ip-prefix
direct | isis
[
process-id |
static
filter-policy
ip-prefix
protocol
all-processes
med-value
ip-prefix-name }
]
| route-policy
{ acl-number |
process-id |
rip
process-id |
{ acl-number |
ip-prefix-name }
14
]
export
ospf
import
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.
t
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 clien
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.
3. Configure the MCE as the
IBGP peer.
4. Redistribute the IGP routes
of the VPN.
bgp
as-number N/A
peer
{ group-name | ip-address }
as-number
import-route
[ process-id ] [
route-policy
*
as-number
protocol
med
med-value |
route-policy-name ]
N/A
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
Disable routing loop detection
for a VPN OSPF process on
the MCE. Otherwise, the MCE
cannot receive OSPF routes
from the PE.
Optional.
By default, the domain ID is 0.
5. Redistribute the VPN
routes.
6. Configure a filtering
policy to filter the
advertised routes.
7. Configure the default
parameters for
redistributed routes
(cost, route number,
tag, and type).
8. Create an OSPF area
and enter OSPF area
view.
9. Enable OSPF on the
interface attached to
the specified network in
the area.
import-route
allow-ibgp
route-policy
tag |
filter-policy
protocol [ process-id |
] [
{ acl-number |
ip-prefix-name }
[ process-id ] ]
default { cost
type
area
area-id
network
type } *
ip-address wildcard-mask
cost
cost |
type
route-policy-name ] *
ip-prefix
export [
cost |
limit
protocol
limit |
16
type |
tag
tag
tag |
By default, no route of any
other routing protocol is
redistributed into OSPF.
Optional.
By default, advertised routes
are not filtered.
Optional.
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.
By default, no OSPF area is
created.
By default, an interface neither
belongs to any area nor runs
OSPF.
Configuring IS-IS between an MCE and a PE
Step Command Remarks
1. Enter system view.
2. Create an IS-IS
process for a VPN
instance and enter
IS-IS view.
3. Configure a network
entity title.
4. Redistribute the VPN
routes.
system-view
isis
[ process-id ]
vpn-instance-name
network-entity
import-route
[ process-id ] |
allow-ibgp
[
cost |
level-1
[
route-policy
] |
cost-type
level-1-2
|
route-policy-name |
tag ] *
vpn-instance
net
isis
{
[ process-id ] |
rip
[ process-id ]|
direct
|
external
{
level-2
|
static
|
] |
ospf
bgp
cost
} [
internal
tag
N/A
N/A
By default, no network entity title
is configured.
Optional.
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.
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:
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.
3. Enter BGP-VPN
instance view.
4. Configure the PE as the
IBGP peer.
5. Redistribute the VPN
routes of the VPN site.
6. Configure the egress
router of the site as a
client of the route
reflector.
7. Enable route reflection
between clients.
8. Specify a cluster ID for
the route reflector.
bgp
as-number N/A
ipv4-family vpn-instance
vpn-instance-name
peer
{ group-name | ip-address }
as-number
import-route
all-processes
route-policy
peer
reflect-client
reflect between-clients
reflector cluster-id
as-number
protocol [ process-id |
med
] [
route-policy-name ] *
{ group-name | ip-address }
med-value
cluster-id
|
N/A
N/A
By default, no route
redistribution is configured.
Optional.
By default, no route reflector
or client is configured.
Optional.
Enabled by default.
If the clients are fully meshed,
you do not need to enable
route reflection.
Optional.
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.
9. Configure a filtering
policy to filter the routes
to be advertised.
10. Configure a filtering
policy to filter the
received routes.
filter-policy
ip-prefix-name }
process-id |
process-id |
filter-policy
ip-prefix-name }
{ acl-number |
export
ospf
process-id |
static
]
{ acl-number |
import
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
ip-prefix
direct | isis
[
rip
ip-prefix
Optional.
By default, BGP does not
filter the routes to be
advertised.
Optional.
By default, BGP does not
filter the received routes.
Task Command
Refresh the BGP connections in a
specific VPN instance.
refresh bgp vpn-instance
external | group
group-name } {
vpn-instance-name { ip-address |
export
import
|
}
all
|
Reset BGP connections of a VPN
instance.
reset bgp vpn-instance
all
ip-address |
external
|
vpn-instance-name { as-number |
group
|
Displaying and maintaining MCE
Task Command Remarks
Display information about the
routing table associated with a
VPN instance.
Display information about a
specific VPN instance or all VPN
instances.
Display information about the FIB
of a VPN instance.
Display information about the FIB
of a VPN instance that matches
the specified destination IP
address.
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.
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 Pre Cost NextHop Interface
10.214.10.0/24 Direct 0 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
Loading...
+ 379 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.