H3C S12500-X User manual

H3C S12500-X Switch Series
MCE
Configuration Guide
Hangzhou H3C Technologies Co., Ltd.
http://www.h3c.com
Software version: Release 1109
Document version: 6W100-20141210

Copyright © 2014, Hangzhou H3C Technologies Co., Ltd. and its licensors
All rights reserved
No part of this manual may be reproduced or transmitted in any form or by any means without prior
written consent of Hangzhou H3C Technologies Co., Ltd.
Trademarks
H3C, , H3CS, H3CIE, H3CNE, Aolynk, , H3Care, , IRF, NetPilot, Netflow,
SecEngine, SecPath, SecCenter, SecBlade, Comware, ITCMM and HUASAN are trademarks of
Hangzhou H3C Technologies Co., Ltd.
All other trademarks that may be mentioned in this manual are the property of their respective owners
Notice
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.

Preface
The H3C S12500-X documentation set includes 11 configuration guides. These guides describe the
software features for the H3C S12500-X Switch Series running Release 1109, and guide you through the
software configuration procedures. These guides also provide configuration examples to help you apply
software features to different network scenarios.
The MCE Configuration Guide describes MCE fundamentals and the configuration on the switch that
acts as an MCE.
This preface includes:
•Audience
•Conventions
•Obtaining documentation
•Technical support
•Documentation feedback
Audience
This documentation is intended for:
•Network planners
•Field technical support and servicing engineers
•Network administrators working with the S12500-X series
Conventions
This section describes the conventions used in this documentation set.
Command conventions
Convention Descri
p
tion
Boldface Bold text represents commands and keywords that you enter literally as shown.
Italic Italic text represents arguments that you replace with actual values.
[ ] Square brackets enclose syntax choices (keywords or arguments) that are optional.
{ x | y | ... }
Braces enclose a set of required syntax choices separated by vertical bars, from which
you select one.
[ x | y | ... ]
Square brackets enclose a set of optional syntax choices separated by vertical bars, from
which you select one or none.
{ x | y | ... } *
Asterisk marked braces enclose a set of required syntax choices separated by vertical
bars, from which you select at least one.
[ x | y | ... ] *
Asterisk marked square brackets enclose optional syntax choices separated by vertical
bars, from which you select one choice, multiple choices, or none.

Convention Descri
p
tion
&<1-n> The argument or keyword and argument combination before the ampersand (&) sign can
be entered 1 to n times.
# A line that starts with a pound (#) sign is comments.
GUI conventions
Convention Descri
p
tion
Boldface Window names, button names, field names, and menu items are in Boldface. For
example, the New User window appears; click OK.
> Multi-level menus are separated by angle brackets. For example, File > Create > Folder.
Symbols
Convention Descri
p
tion
WARNING An alert that calls attention to important information that if not understood or followed can
result in personal injury.
CAUTION An alert that calls attention to important information that if not understood or followed can
result in data loss, data corruption, or damage to hardware or software.
IMPORTANT An alert that calls attention to essential information.
NOTE An alert that contains additional or supplementary information.
TIP An alert that provides helpful information.
Network topology icons
Represents a generic network device, such as a router, switch, or firewall.
Represents a routing-capable device, such as a router or Layer 3 switch.
Represents a generic switch, such as a Layer 2 or Layer 3 switch, or a router that supports
Layer 2 forwarding and other Layer 2 features.
Represents an access controller, a unified wired-WLAN module, or the access controller
engine on a unified wired-WLAN switch.
Represents an access point.
Represents a mesh access point.
Represents omnidirectional signals.
Represents directional signals.




Represents a security product, such as a firewall, UTM, multiservice security gateway, or
load-balancing device.
Represents a security card, such as a firewall, load-balancing, NetStream, SSL VPN, IPS,
or ACG card.
Port numbering in examples
The port numbers in this document are for illustration only and might be unavailable on your device.
Obtaining documentation
Access the most up-to-date H3C product documentation on the World Wide Web
at http://www.h3c.com.
Click the links on the top navigation bar to obtain different categories of product documentation:
[Technical Support & Documents > Technical Documents]—Provides hardware installation, software
upgrading, and software feature configuration and maintenance documentation.
[Products & Solutions]—Provides information about products and technologies, as well as
solutions. [Technical Support & Documents > Software Download]—Provides the documentation
released with the software version.
Technical support
servic[email protected]
http://www.h3c.com
Documentation feedback
You can e-mail your comments about product documentation to [e-mail].
We appreciate your comments.


i
Contents
Configuring MCE ························································································································································· 1
MPLS L3VPN overview ·····················································································································································1
Basic MPLS L3VPN architecture······························································································································1
MPLS L3VPN concepts ·············································································································································2
MCE overview ···································································································································································3
MCE configuration task list ··············································································································································4
Configuring VPN instances ··············································································································································5
Creating a VPN instance·········································································································································5
Associating a VPN instance with an interface ······································································································5
Configuring route related attributes for a VPN instance······················································································6
Configuring routing on an MCE······································································································································7
Configuring routing between an MCE and a VPN site························································································7
Configuring routing between an MCE and a PE ······························································································· 13
Displaying and maintaining MCE································································································································ 17
MCE configuration examples ······································································································································· 18
Configuring the MCE that uses OSPF to advertise VPN routes to the PE························································ 18
Configuring the MCE that uses EBGP to advertise VPN routes to the PE························································ 23
Index ···········································································································································································28

1
Configuring MCE
This chapter describes MCE configuration. For information about the related routing protocols, see Layer
3
— IP Routing Configuration Guide.
Unless otherwise specified, the term "interface" in this document collectively refers to VLAN interfaces
and Layer 3 Ethernet 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).
MPLS L3VPN overview
MPLS L3VPN is a L3VPN technology used to interconnect geographically dispersed VPN sites. MPLS
L3VPN uses BGP to advertise VPN routes and uses MPLS to forward VPN packets over a service provider
backbone.
MPLS L3VPN provides flexible networking modes, excellent scalability, and convenient support for MPLS
QoS and MPLS TE.
Basic MPLS L3VPN architecture
Figure 1 Basic MPLS L3VPN architecture
A basic MPLS L3VPN architecture has the following types of devices:
•Customer edge device—A CE device resides on a customer network and has one or more interfaces
directly connected to a service provider network. It does not support VPN or MPLS.
•Provider edge device—A PE device resides at the edge of a service provider network and connects
to one or more CEs. All MPLS VPN services are processed on PEs.
VPN 1
CE
Site 1
VPN 2
CE
CE
CE
Site 3
VPN 2
PE
VPN 1
Site 2
Site 4
PE
PE
PP
PP

2
•Provider device—A P device is a core device on a service provider network. It is not directly
connected to any CE. A P device has only basic MPLS forwarding capability and does not handle
VPN routing information.
MPLS L3VPN concepts
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 that a site can belong to multiple
VPNs.
•A site is connected to a provider network through one or more CEs. A site can contain multiple 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.
VPN instance
VPN instances, also called virtual routing and forwarding (VRF) instances, implement route isolation,
data independence, and data security for VPNs.
A VPN instance has the following components:
•A separate Label Forwarding Information Base (LFIB).
•An IP routing table.
•Interfaces bound to the VPN instance.
•VPN instance administration information, including route distinguishers (RDs), route targets (RTs),
and route filtering policies.
To associate a site with a VPN instance, bind the VPN instance to the PE's interface connected to the site.
A site can be associated with only one VPN instance, and different sites can associate with the same
VPN instance. A VPN instance contains the VPN membership and routing rules of associated sites.
Address space overlapping
Each VPN independently manages its address space.
The address spaces of VPNs might 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-IPv4 address
BGP cannot process overlapping VPN address spaces. For example, if both VPN 1 and VPN 2 use the
subnet 10.110.10.0/24 and each advertise a route destined for the subnet, BGP selects only one of them,
resulting in the loss of the other route.
Multiprotocol BGP (MP-BGP) can solve this problem by advertising VPN-IPv4 prefixes.

3
Figure 2 VPN-IPv4 address structure
As shown in Figure 2, a VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD,
followed by a four-byte IPv4 prefix. The RD and the IPv4 prefix form a unique VPN-IPv4 prefix.
An RD can be in one of the following formats:
•When the Type field is 0, the Administrator subfield occupies two bytes, the Assigned number
subfield occupies four bytes, and the RD format is 16 - b i t A S n u m b e r :32-bit user-defined number. For
example, 100:1.
•When 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.
Fo r e xa m p l e , 172.1.1.1:1.
•When 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.
Route target attribute
MPLS L3VPN uses route target community 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 received from
other PEs. If the export target attribute matches the import target attribute of a VPN instance, the PE
adds the routes to the routing table of the VPN instance.
Route target attributes define which sites can receive VPN-IPv4 routes, and from which sites a PE can
receive routes.
Like RDs, route target attributes can be one of the following formats:
•16 - b i t A S n u m b e r :32-bit user-defined number. For example, 100:1.
•32-bit IPv4 address:16-bit user-defined number. F or e xa m p l e , 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.
MCE overview
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 use an exclusive CE to connect
to a PE, as shown in Figure 1.
A private network is typically divided into multiple VPNs to isolate services. To meet these requirements,
you can configure a CE for each VPN, which increases device expense and maintenance costs. Or, you
Type
2 bytes 4 bytes
IPv4 address prefix
6 bytes
Route Distinguisher (8 bytes)
Assigned number subfieldAdministrator subfield

4
can configure multiple VPNs to use the same CE and the same routing table, which sacrifices data
security.
You can use the Multi-VPN Instance CE (MCE) function in multi-VPN networks. MCE allows you to bind
each VPN to a VLAN interface. The MCE creates and maintains 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.
Figure 3 Network diagram for the MCE function
As shown in Figure 3, the MCE device creates a routing table for each VPN. VLAN interface 2 binds to
VPN 1 and VLAN-interface 3 binds to VPN 2. When receiving a route, the MCE device determines the
source of the routing information according to the number of the receiving interface, and then adds it to
the corresponding routing table. The MCE connects to PE 1 through a trunk link that permits packets
tagged with VLAN 2 or VLAN 3. PE 1 determines the VPN that a received packet belongs to according
to the VLAN tag of the packet, and sends the packet through the corresponding tunnel.
You can configure static routes, RIP, OSPF, IS-IS, EBGP, or IBGP between an MCE and a VPN site and
between an MCE and a PE.
NOTE:
To implement dynamic IP assi
g
nment for DHCP clients in private networks, you can confi
g
ure DHCP server
or DHCP relay agent on the MCE. When the MCE functions as the DHCP server, the IP addresses assi
g
ned
to different private networks cannot overlap.
MCE configuration task list
Tasks at a
g
lance
Configuring VPN instances:
1. (Required.) Creating a VPN instance

5
Tasks at a
g
lance
2. (Required.)
A
ssociating a VPN instance with an interface
3. (Optional.) Configuring route related attributes for a VPN instance
Configuring routing on an MCE:
•(Required.) Configuring routing between an MCE and a VPN site
•(Required.) Configuring routing between an MCE and a PE
Configuring VPN instances
VPN instances isolate VPN routes from public network routes and routes among VPNs. You must
configure VPN instances for an MCE networking scheme.
Creating a VPN instance
A VPN instance is a collection of the VPN membership and routing rules of its associated site. A VPN
instance might not correspond to one VPN.
To create and configure a VPN instance:
Ste
p
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
By default, no VPN instance is
created.
3. Configure an RD for the VPN
instance.
route-distinguisher
route-distinguisher
By default, no RD is specified for a
VPN instance.
4. (Optional.) Configure a
description for the VPN
instance.
description text By default, no description is
configured for a VPN instance.
5. (Optional.) Configure a VPN
ID for the VPN instance. vpn-id vpn-id By default, no VPN ID is configured
for a VPN instance.
Associating a VPN instance with an interface
After creating and configuring a VPN instance, associate the VPN instance with the MCE's interface
connected to the site and the interface connected to the PE.
To associate a VPN instance with an interface:
Ste
p
Command Remarks
1. Enter system view. system-view N/A
2. Enter interface view. interface interface-type
interface-number N/A

6
Ste
p
Command Remarks
3. Associate a VPN instance
with the interface.
ip binding vpn-instance
vpn-instance-name
By default, no VPN instance is
associated with an interface.
The ip binding vpn-instance
command deletes the IP address of
the current interface. You must
re-configure an IP address for the
interface after configuring the
command.
Configuring route related attributes for a VPN instance
VPN routes are controlled and advertised on a PE by using the following process:
1. 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 typically the export target attribute of the VPN
instance associated with the site.
2. The VPN instance determines which routes it can accept and redistribute according to the
import-extcommunity in the route target.
3. The VPN instance determines how to change the route target attributes for routes to be advertised
according to the export-extcommunity in the route target.
To configure route related attributes for a VPN instance:
Ste
p
Command Remarks
1. Enter system view. system-view N/A
2. Enter VPN instance view
or IPv4 VPN view.
•Enter VPN instance view:
ip vpn-instance vpn-instance-name
•Enter IPv4 VPN view:
a. ip vpn-instance
vpn-instance-name
b. address-family ipv4
An IPv4 VPN prefers the
configurations in IPv4 VPN view
over the configurations in VPN
instance view.
3. Configure route targets.
vpn-target vpn-target&<1-8> [ both |
export-extcommunity |
import-extcommunity ]
By default, no route targets are
configured.
4. Set the maximum
number of active routes
allowed.
routing-table limit number
{ warn-threshold | simply-alert }
By default, the maximum number of
active routes in the VPN instance is
not limited.
Setting the maximum number of
active routes for a VPN instance
can prevent the PE from learning
too many routes.

7
Ste
p
Command Remarks
5. Apply an import routing
policy. import route-policy route-policy
By default, all routes matching the
import target attribute are
accepted.
The specified routing policy must
have been created.
For information about routing
policies, see Layer 3—IP Routing
Configuration Guide.
6. Apply an export routing
policy. export route-policy route-policy
By default, routes to be advertised
are not filtered.
The specified routing policy must
have been created.
For information about routing
policies, see Layer 3—IP Routing
Configuration Guide.
Configuring routing on an MCE
MCE implements service isolation through route isolation. MCE routing configuration includes the
following:
•MCE-VPN site routing configuration.
•MCE-PE routing configuration.
On the PE, 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:
•Configure VPN instances, and bind the VPN instances with the interfaces connected to the VPN
sites and 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
You can 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 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 a static route to a VPN site:
Ste
p
Command Remarks
1. Enter system view. system-view N/A

8
Ste
p
Command Remarks
2. Configure a static route
for a VPN instance.
ip route-static vpn-instance s-vpn-instance-name
dest-address { mask-length | mask } { interface-type
interface-number [ next-hop-address ] |
next-hop-address [ public ] [ track track-entry-number ]
| vpn-instance d-vpn-instance-name next-hop-address
[ track track-entry-number ] } [ permanent ]
[ preference preference-value ] [ tag tag-value ]
[ description description-text ]
By default, no static
route is configured.
Perform this
configuration on the
MCE. On the VPN
site, configure a
common static route.
3. (Optional.) Configure
the default preference
for static routes.
ip route-static default-preference
default-preference-value
The default preference
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. Binding RIP processes to VPN
instances can isolate routes of different VPNs. For more information about RIP, see Layer 3—IP Routing
Configuration Guide.
To configure RIP between an MCE and a VPN site:
Ste
p
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
common 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 into RIP.
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. (Optional.) Configure the
default cost value for the
redistributed routes.
default cost value The default cost is 0.
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.
Binding OSPF processes to VPN instances can isolate routes of different VPNs. For more information
about OSPF, see Layer 3—IP Routing Configuration Guide.
To configure OSPF between an MCE and a VPN site:
Ste
p
Command Remarks
1. Enter system view. system-view N/A

9
Ste
p
Command Remarks
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 ] *
Perform this configuration on the
MCE. On a VPN site, create a
common OSPF process.
An OSPF process bound to a VPN
instance does not use the public
network router ID configured in
system view. Therefore, configure
a router ID for the OSPF process.
An OSPF process can belong to
only one VPN instance, but one
VPN instance can use multiple
OSPF processes to advertise VPN
routes.
3. (Optional.) Configure the
OSPF domain ID. domain-id domain-id [ secondary ]
The default domain ID is 0.
Perform this configuration on the
MCE.
All OSPF processes of the same
VPN instance must be configured
with the same OSPF domain ID to
ensure correct route advertisement.
4. (Optional.) 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.
5. (Optional.) Configure the
external route tag for
imported VPN routes.
route-tag tag-value
By default, no route tag is
configured.
In some networks, a VPN might be
connected to multiple MCEs.
When one MCE advertises the
routes learned from BGP to the
VPN, the other MCEs might learn
the routes, resulting in routing
loops. To avoid such routing loops,
you can configure route tags for
VPN instances on an MCE. H3C
recommends that you configure the
same route tag for the same VPN
on the MCEs.
6. Redistribute remote site routes
advertised by the PE into
OSPF.
import-route protocol [ process-id
|all-processes | allow-ibgp ] [ cost
cost | route-policy
route-policy-name | tag tag | type
type ] *
By default, no routes are
redistributed into OSPF.
7. (Optional.) Configure OSPF
to redistribute the default
route.
default-route-advertise summary
cost cost
By default, OSPF does not
redistribute the default route.
This command redistributes the
default route in a Type-3 LSA. The
MCE advertises the default route to
the site.

10
Ste
p
Command Remarks
8. Create an OSPF area and
enter OSPF area view. area area-id By default, no OSPF area is
created.
9. 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.
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.
Binding IS-IS processes to VPN instances can isolate routes of different VPNs. For more information about
IS-IS, see Layer 3—IP Routing Configuration Guide.
To configure IS-IS between an MCE and a VPN site:
Ste
p
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
common IS-IS process.
3. Configure a network entity
title. network-entity net By default, no NET is configured.
4. Redistribute remote site routes
advertised by the PE into IS-IS.
import-route protocol [ process-id
| all-processes |allow-ibgp ] [ cost
cost | cost-type { external |
internal } | [ level-1 | level-1-2 |
level-2 ] | route-policy
route-policy-name | tag tag ] *
By default, IS-IS does not
redistribute routes from 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.
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 ] IS-IS is disabled by default.
Configuring EBGP between an MCE and a VPN site
To run EBGP between an MCE and a VPN site, 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 site.
You can configure filtering policies to filter received routes and advertised routes.
1. Configure the MCE:
Routes redistributed from OSPF to BGP 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.
To configure the MCE:

11
Ste
p
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. ip vpn-instance vpn-instance-name N/A
4. Configure an EBGP
peer.
peer { group-name |ip-address }
as-number as-number
By default, no BGP peer is
configured.
5. Enter BGP-VPN IPv4
unicast address family
view.
address-family ipv4 [unicast ]N/A
6. Enable BGP to exchange
IPv4 unicast routes with
the peer.
peer { group-name |ip-address }
enable
By default, BGP does not
exchange IPv4 unicast routes
with any peer.
7. Allow the local AS
number to appear in the
AS_PATH attribute of
routes received from the
peer, and set the
maximum number of
repetitions.
peer { group-name |ip-address }
allow-as-loop [ number ]
By default, BGP discards
incoming route updates that
contain the local AS number.
BGP detects routing loops by
examining AS numbers. The
routing information the MCE
advertises to a site carries the
local AS number. Therefore,
the route updates that the MCE
receives from the site also
include the local AS number.
This causes the MCE to be
unable to receive the route
updates. In this case, you must
configure this command to
allow routing loops.
8. Redistribute remote site
routes advertised by the
PE into BGP.
import-route protocol [ { process-id |
all-processes } [ med med-value |
route-policy route-policy-name ] * ]
By default, no routes are
redistributed into BGP.
9. (Optional.) Configure
filtering of advertised
routes.
filter-policy { acl-number | prefix-list
prefix-list-name } export [ protocol
process-id ]
By default, BGP does not filter
advertised routes.
10. (Optional.) Configure
filtering of received
routes.
filter-policy { acl-number | prefix-list
prefix-list-name } import
By default, BGP does not filter
received routes.
2. Configure a VPN site:
Ste
p
Command Remarks
1. Enter system view. system-view N/A
2. Enter BGP view. bgp as-number N/A
3. Configure the MCE as an
EBGP peer.
peer { group-name |
ip-address } as-number
as-number
N/A

12
Ste
p
Command Remarks
4. Enter BGP-VPN IPv4
unicast address family
view.
address-family ipv4 [unicast ]
N/A
5. Enable BGP to exchange
IPv4 unicast routes with
the peer.
peer { group-name |
ip-address } enable
By default, BGP does not exchange
IPv4 unicast routes with any peer.
6. Redistribute the IGP routes
of the VPN into BGP.
import-route protocol
[ { process-id | all-processes }
[ med med-value | route-policy
route-policy-name ] * ]
By default, no routes are
redistributed into BGP.
A VPN site must advertise the VPN
network addresses it can reach to the
connected MCE.
Configuring IBGP between MCE and VPN site
To run IBGP between an MCE and a VPN site, 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 site.
1. Configure the MCE:
Ste
p
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.
ip vpn-instance
vpn-instance-name N/A
4. Configure an IBGP peer.
peer { group-name |
ip-address } as-number
as-number
N/A
5. Enter BGP-VPN IPv4
unicast address family
view.
address-family ipv4 [unicast ]
N/A
6. Enable BGP to exchange
IPv4 unicast routes with
the peer.
peer { group-name |
ip-address } enable
By default, BGP does not exchange
IPv4 unicast routes with any peer.
7. (Optional.) Configure the
system to be the RR, and
specify the peer as the
client of the RR.
peer { group-name |
ip-address } reflect-client
By default, no RR or RR client is
configured.
After you configure a VPN site as an
IBGP peer, the MCE does not
advertise the BGP routes learned
from the VPN site to other IBGP
peers, including VPNv4 peers. The
MCE advertises routes learned from
a VPN site only when you configure
the VPN site as a client of the RR (the
MCE).
8. Redistribute remote site
routes advertised by the
PE into BGP.
import-route protocol
[ process-id | all-processes ]
[ med med-value | route-policy
route-policy-name ] *
By default, no routes are
redistributed into BGP.

13
Ste
p
Command Remarks
9. (Optional.) Configure
filtering of advertised
routes.
filter-policy { acl-number |
prefix-list prefix-list-name }
export [ protocol process-id ]
By default, BGP does not filter
advertised routes.
10. (Optional.) Configure
filtering of received routes.
filter-policy { acl-number |
prefix-list prefix-list-name }
import
By default, BGP does not filter
received routes.
2. Configure a VPN site:
Ste
p
Command Remarks
1. Enter system view. system-view N/A
2. Enter BGP view. bgp as-number N/A
3. Configure the MCE as an
IBGP peer.
peer { group-name |
ip-address } as-number
as-number
N/A
4. Enter BGP-VPN IPv4
unicast address family
view.
address-family ipv4 [unicast ]
N/A
5. Enable BGP to exchange
IPv4 unicast routes with
the peer.
peer { group-name |
ip-address } enable
By default, BGP does not exchange
IPv4 unicast routes with any peer.
6. Redistribute the IGP routes
of the VPN into BGP.
import-route protocol
[ { process-id | all-processes }
[ med med-value | route-policy
route-policy-name ] * ]
By default, no routes are
redistributed into BGP.
A VPN site must advertise VPN
network addresses to the connected
MCE.
Configuring routing between an MCE and a PE
MCE-PE routing configuration includes the following tasks:
•Binding the MCE-PE interfaces to VPN instances.
•Performing route configurations.
•Redistributing VPN routes into the routing protocol running between the MCE and the PE.
Perform the following configurations on the MCE. For more information about configuring the PE, see the
documentation for the PE.
Configuring static routing between an MCE and a PE
Ste
p
Command Remarks
1. Enter system view. system-view N/A

14
Ste
p
Command Remarks
2. Configure a static route
for a VPN instance.
ip route-static vpn-instance s-vpn-instance-name
dest-address { mask-length | mask } { interface-type
interface-number [ next-hop-address ] |
next-hop-address [ public ] [ track
track-entry-number ] | vpn-instance
d-vpn-instance-name next-hop-address [ track
track-entry-number ] } [ permanent ] [ preference
preference-value ] [ tag tag-value ] [ description
description-text ]
By default, no static
route is configured.
3. (Optional.) Configure
the default preference for
static routes.
ip route-static default-preference
default-preference-value
The default preference is
60.
Configuring RIP between an MCE and a PE
Ste
p
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
3. 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 |
all-processes | allow-ibgp ] [ cost cost |
route-policy route-policy-name | tag tag ] *
By default, no routes are
redistributed into RIP.
5. (Optional.) Configure
the default cost for
redistributed routes.
default cost value The default cost is 0.
Configuring OSPF between an MCE and a PE
Ste
p
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
3. Disable routing loop
detection. vpn-instance-capability simple
By default, routing loop detection
is enabled.
You must disable routing loop
detection for a VPN OSPF process
on the MCE. Otherwise, the MCE
cannot receive OSPF routes from
the PE.
4. (Optional.) Configure the
OSPF domain ID. domain-id domain-id [ secondary ]
The default domain ID is 0.