Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
V800R002C01
01
Date
2011-10-15
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
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.
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 01 (2011-10-15)
Commissioning engineers
Version
HUAWEI NetEngine5000E
Core Router
V800R002C01
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
Indicates a hazard with a high level of risk, which if not
avoided, will result in death or serious injury.
Indicates a hazard with a medium or low level of risk, which
if not avoided, could result in minor or moderate injury.
Issue 01 (2011-10-15)
ii
Symbol
Description
Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
Indicates a tip that may help you solve a problem or save time.
Provides additional information to emphasize or supplement
important points of the main text.
Description
Boldface
Italic
[]
{ x | y | ... }
[ x | y | ... ]
{ x | y | ... }*
[ x | y | ... ]*
&<1-n>
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
iii
Contents
Contents
About This Document.....................................................................................................................ii
1 VPN Tunnel Management Configuration................................................................................1
1.1 VPN Tunnel Management Overview.................................................................................................................2
1.2 VPN Tunnel Management Features Supported by the NE5000E......................................................................2
1.3 Configuring Tunnel Interfaces............................................................................................................................3
1.3.1 Creating a Tunnel Interface.......................................................................................................................4
1.3.2 Configuring a Tunnel Interface.................................................................................................................4
1.3.3 Checking the Configuration.......................................................................................................................5
1.4 Configuring a Tunnel Type Prioritizing Policy for an L3VPN..........................................................................5
1.4.1 Configuring a Tunnel Type Prioritizing Policy.........................................................................................6
1.4.2 Applying a Tunnel Policy to an L3VPN...................................................................................................7
1.4.3 Checking the Configuration.......................................................................................................................7
1.5 Configuring a Tunnel Binding Policy for an L3VPN.........................................................................................9
1.5.1 Configuring a Tunnel Binding Policy.....................................................................................................10
1.5.2 Applying a Tunnel Policy to an L3VPN.................................................................................................11
1.5.3 Checking the Configuration.....................................................................................................................11
1.6 Maintaining a VPN Tunnel...............................................................................................................................13
1.6.1 Monitoring the Running Status of a Tunnel............................................................................................13
1.7 Configuration Examples...................................................................................................................................13
1.7.1 Example for Configuring a Tunnel Policy for an L3VPN.......................................................................13
iv
Contents
Contents
2.12 Configuring Inter-AS VPN Option B (Spanning More Than Two ASs).......................................................89
2.12.1 Configuring MP-IBGP Between a PE and an ASBR in the Same AS..................................................90
2.12.2 Configuring MP-EBGP Between ASBRs in Different ASs..................................................................91
2.12.3 Configuring MP-IBGP Between ASBRs in the Same AS....................................................................92
2.12.4 Controlling the Learning and Advertising of VPN Routes on ASBR...................................................93
2.12.5 Checking the Configuration...................................................................................................................93
2.13 Configuring the Multi-VPN-Instance CE.......................................................................................................94
2.13.1 Configuring OSPF Multi-Instance on the PE........................................................................................95
2.13.2 Configuring the OSPF Multi-Instance on the Multi-Instance CE.........................................................96
2.13.3 Disabling Route Loop Detection on the Multi-VPN-Instance CE........................................................97
2.13.4 Checking the Configuration...................................................................................................................98
2.14 Configuring VPN FRR...................................................................................................................................98
2.15 Configuring FRR for IP Routes on a Private Network.................................................................................100
2.16 Configuring Hybrid FRR for IP and VPNv4 Routes....................................................................................102
2.17 Maintaining BGP/MPLS IP VPN.................................................................................................................105
2.17.1 Monitoring the Running Status of BGP/MPLS IP VPN.....................................................................105
2.17.2 Checking the Network Connectivity and Reachability.......................................................................106
2.17.3 Clearing BGP Statistics of the VPN Instance IPv4 Address Family...................................................106
2.17.4 Resetting BGP Connections................................................................................................................107
2.18 Configuration Examples...............................................................................................................................108
2.18.1 Example for Configuring BGP/MPLS IP VPN...................................................................................108
2.18.2 Example for Configuring BGP AS Number Substitution...................................................................120
2.18.3 Example for Configuring the BGP SoO..............................................................................................126
2.18.4 Example for Configuring CE Dual-Homing with EBGP Running Between a PE and a CE..............136
2.18.5 Example for Configuring Double RRs for the Optimization of the VPN Backbone Layer................149
2.18.6 Example for Configuring an RR for the Optimization of the VPN Access Layer..............................158
2.18.7 Example for Configuring Hub and Spoke...........................................................................................166
2.18.8 Example for Configuring Extranet VPN.............................................................................................175
2.18.9 Example for Configuring Load Balancing Among Tunnels to Which Remote Cross Routes Are Iterated
on a VPN........................................................................................................................................................184
2.18.10 Example for Configuring Inter-AS VPN Option A...........................................................................191
2.18.11 Example for Configuring Inter-AS VPN Option B with Basic Networking.....................................200
2.18.12 Example for Configuring Inter-AS VPN Option B with an RR in an AS.........................................207
2.18.13 Example for Configuring Inter-AS VPN Option B with an ASBR Filtering VPN Routes...............220
2.18.14 Example for Configuring Inter-AS VPN Option B with a P Between ASBRs.................................233
2.18.15 Example for Configuring Inter-AS VPN Option B with ASBRs Functioning as PEs......................241
2.18.16 Example for Configuring Inter-AS VPN Option B with an ASBR Functioning as an RR...............251
2.18.17 Example for Configuring Inter-AS VPN Option B with the VPN Spanning Multiple ASs.............262
2.18.18 Example for Configuring a Multi-VPN-Instance CE........................................................................274
2.18.19 Example for Configuring VPN FRR with FRR Switchover Being Implemented on a PE...............285
2.18.20 Example for Configuring FRR for IP Routes on a Private Network.................................................293
2.18.21 Example for Configuring Hybrid FRR for IP and VPNv4 Routes....................................................300
2.18.22 Example for Configuring BFD for Static VPN Routes.....................................................................310
Issue 01 (2011-10-15)
vi
Contents
vii
Contents
Issue 01 (2011-10-15)
viii
Issue 01 (2011-10-15)
LSP
Label Switched Paths (LSPs) are used as tunnels for VPN data forwarding over the MultiProtocol Label Switch (MPLS) VPN public network. In this mode, only the PE rather than
each device that a VPN packet passes needs to analyze IP packet headers. Thus, the time
to process VPN packets shortens and the delay of packet transmission decreases. In
addition, MPLS labels are supported any link-layer protocol. An LSP is similar to an
Asynchronous Transfer Mode (ATM) virtual circuit (VC) or a Frame Relay (FR) VC in
function and security.
MPLS TE
Generally, carriers are required to provide VPN users with end-to-end Quality of Service
(QoS) for various services, such as the voice service, video service, mission-critical service,
and common online service. MPLS Traffic Engineering (TE) tunnels can optimize network
resources and offer users QoS guaranteed services.
Tunnel interface configuration: You can specify different tunnel types on different tunnel
interfaces. Configurations of tunnels vary with the tunnel type.
Tunnel management: This function notifies the tunnel status to applications that use the
tunnel and provides tunnel query policies for tunnel selection. The commonly used function
is to set tunnel policies.
CR-LSPs are preferred as long as they are Up. If the number of CR-LSPs that are Up is
smaller than three (CR-LSPs are not sufficient or CR-LSPs are sufficient whereas their
status is Down), the CR-LSPs are preferentially selected and the LSPs in the Up state are
also selected.
If there is one LSP tunnel among the selected three tunnels, when a new CR-LSP is set up
or a CR-LSP in the Down state becomes Up, the CR-LSP is selected and the LSP is no
longer used.
If the number of present tunnels for load balancing is smaller than the configured number
and a CR-LSP or an LSP in the Up state is added, the newly added tunnel participates in
load balancing.
The number of present tunnels for load balancing depends on that of the eligible tunnels.
For example, if there are only one CR-LSP and one LSP in the Up state, load balancing is
performed between the two tunnels. The tunnels of other types are not selected even if they
are Up.
Applicable Environment
Tunnels such as MPLS TE tunnels, and IPv6 over IPv4 tunnels all use virtual interfaces, namely,
tunnel interfaces, to forward packets. Before setting up these types of tunnels, you need to create
tunnel interfaces.
Tunnel interfaces can be configured with different encapsulation modes as required, for example,
mpls te, and ipv6-ipv4.
Issue 01 (2011-10-15)
Pre-configuration Tasks
Before configuring a tunnel interface, complete the following tasks:
l
Connecting interfaces correctly and configuring physical parameters for the interfaces to
ensure that the physical layer statuses of these interfaces are Up
Configuring parameters of the link layer protocol and IP addresses for the interfaces to
ensure that the link layer protocol on the interfaces is Up
Configuration Procedures
Figure 1-1 Flowchart for configuring a tunnel interface
Create a tunnel interface
Procedure
Step 1 Run:
system-view
Procedure
l
Issue 01 (2011-10-15)
For detailed TE tunnel interface configuration, refer to Configuring the MPLS TE Tunnel
Interface in the NE5000E Configuration Guide - MPLS.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
For detailed IPv6 over IPv4 tunnel interface configuration, refer to IPv6 over IPv4 Tunnel
Configuration in the NE5000E Configuration Guide - IP Service.
----End
Prerequisite
All configurations of the functions of the tunnel interface are completed.
Procedure
l
Run the display tunnel-info all command to check information about all tunnels.
Run the display tunnel-info tunnel-id command to check details about the specified tunnel.
----End
Example
Run the display tunnel-info command, and you can view the tunnel ID of the specified tunnel
and other configurations.
<HUAWEI> display tunnel-info all
Tunnel ID
Type
Destination
Status
----------------------------------------------------------------------------0x0000000001004c4b81
ldp
2.2.2.2
UP
0x000000000300000001
te
2.2.2.2
UP
Run the display tunnel-info tunnel-id command, and you can view details about the tunnel.
<HUAWEI> display tunnel-info 000000000300000001
Tunnel ID:
0x000000000300000001
Type:
te
Name:
Tunnel2
Destination:
2.2.2.2
Instance ID:
0
Cost:
4294967295
Status:
UP
Applicable Environment
By default, the system selects a tunnel for a VPN based on the default policy. That is, in the
order of LSPs, CR-LSPs, and Local_IfNet, and load balancing is not performed by default. If
load balancing or other types of tunnels are required, you need to configure a tunnel policy and
apply the tunnel policy.
For L3VPNs, a tunnel policy needs to be bound to a VPN instance.
Issue 01 (2011-10-15)
Pre-configuration Tasks
Before configuring a tunnel policy, complete the following tasks:
l
Connecting interfaces correctly and configuring physical parameters for the interfaces to
ensure that the physical layer statuses of these interfaces are Up
Configuring parameters of the link layer protocol and IP addresses for the interfaces to
ensure that the link layer protocol on the interfaces is Up
Configuration Procedures
Figure 1-2 Flowchart for configuring a tunnel type prioritizing policy for an L3VPN
Configure a
tunnel type prioritizing policy
Procedure
Step 1 Run:
system-view
The sequence in which each type of tunnel is selected and the number of tunnels participating
in load balancing are set.
Issue 01 (2011-10-15)
For L3VPNs, if no tunnel policies are configured, LSP is used as the VPN tunnel, and no load
balancing is carried out.
Step 4 Run:
commit
Procedure
Step 1 Run:
system-view
The VPN instance IPv4 address family view or IPv6 address family view is displayed.
Step 4 Run:
tnl-policy policy-name
A tunnel policy is applied to the VPN instance IPv4 address family or IPv6 address family.
Step 5 Run:
commit
Prerequisite
All configurations about a tunnel type prioritizing policy are complete and the tunnel policy is
applied to an L3VPN instance.
Issue 01 (2011-10-15)
Procedure
l
Run the display tunnel-info { all | statistics | tunnel-id } command to check information
about existing tunnels of the system.
Run the display tunnel-policy [ policy-name ] command to check the configuration about
the specified tunnel policy.
----End
Example
Run the display tunnel-info all command, and you can view information and status of existing
tunnels of the system.
<HUAWEI> display tunnel-info all
Tunnel ID
Type
Destination
Status
----------------------------------------------------------------------------0x0000000001004c4b81
ldp
2.2.2.9
UP
0x000000000300000001
te
2.2.2.9
UP
0x000000000300000002
te
2.2.2.9
UP
Run the display tunnel-policy command, and you can view the configuration about the tunnel
policy. For example:
<HUAWEI> display tunnel-policy policy2
Tunnel Policy Name Select-Seq
Load balance No
--------------------------------------------------------------------policy2
CR-LSP LSP
3
Run the display ip vpn-instance verbose command, and you can view the tunnel policy applied
to the specified VPN instance. For example, from the following output, you can view that the
tunnel policy applied to the VPN instance vpnb is policy2.
<HUAWEI> display ip vpn-instance verbose vpnb
VPN-Instance Name and ID : vpnb, 1
Interfaces : GigaEthernet1/0/0
Address family ipv4
Create date : 2009/11/04 17:47:21
Up time : 0 days, 01 hours, 58 minutes and 12 seconds
Route Distinguisher : 11:11
Export VPN Targets : 22:22
Import VPN Targets : 22:22
Label Policy : label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
Tunnel Policy : policy2
Issue 01 (2011-10-15)
Destination: 6.6.6.6/32
Protocol: BGP
Process ID:
Preference: 255
Cost:
NextHop: 2.2.2.2
Neighbour:
State: Active Adv Relied
Age:
Tag: 0
Priority:
Label: 0x15
QoSInfo:
IndirectID: 0xb8
RelayNextHop: 0.0.0.0
Interface:
TunnelID: 0x000000000300000001 Flags:
RelayNextHop: 0.0.0.0
Interface:
TunnelID: 0x0000000001004c4b81 Flags:
0
0
0.0.0.0
00h59m36s
low
0x0
Tunnel1
RD
LDP LSP
RD
Applicable Environment
For VPN service deployment, VPN tunnel binding is required in the following conditions:
l
Pre-configuration Tasks
Before configuring VPN tunnel binding, complete the following tasks:
l
Configuring parameters of the link layer protocol and IP addresses for the interfaces to
ensure that the link layer protocol on the interfaces is Up
Configuring static routes or enabling an IGP to ensure that the routes between nodes are
reachable
Configuration Procedures
Figure 1-3 Flowchart for configuring a tunnel binding policy for an L3VPN
Configure a tunnel binding policy
Related Tasks
1.7.1 Example for Configuring a Tunnel Policy for an L3VPN
Issue 01 (2011-10-15)
Procedure
l
Run:
system-view
Run:
interface tunnel interface-number
Run:
mpls te reserved-for-binding
Run:
commit
Run:
system-view
Run:
tunnel-policy policy-name
Run:
tunnel binding destination dest-ip-address te tunnel interface-number
[ down-switch ]
The destination is bound to the tunnel policy. Then, VPN data from the local device
to the destination address is transmitted over the bound tunnel.
NOTE
l If the tunnel select-seq command is configured in the tunnel policy, you cannot configure
the tunnel binding command for this policy.
l The same destination IP address on a PE can be bound to up to many tunnels to implement
load balancing.
l When the PE has multiple peers, you can configure different tunnel binding commands
for the multiple destination addresses in one tunnel policy.
4.
Run:
commit
10
Context
Do as follows on the PE devices at both ends of a tunnel. For different VPN services on one PE
for the same destination, the same tunnel policy can be used.
Procedure
Step 1 Run:
system-view
The VPN instance IPv4 address family or IPv6 address family view is displayed.
Step 4 Run:
tnl-policy policy-name
A tunnel policy is applied to the VPN instance IPv4 address family or IPv6 address family.
Step 5 Run:
commit
Prerequisite
All configurations about a tunnel binding policy are complete and the tunnel policy is applied
to an L3VPN instance.
Procedure
l
Run the display tunnel-info { all | statistics | tunnel-id } command to check information
about existing tunnels of the system.
Run the display tunnel-policy policy-name command to check the configuration about the
specified tunnel binding policy.
Issue 01 (2011-10-15)
11
----End
Example
Run the display tunnel-info all command, and you can view information and status of existing
tunnels of the system.
<HUAWEI> display tunnel-info all
Tunnel ID
Type
Destination
Status
----------------------------------------------------------------------------0x0000000001004c4b81
ldp
2.2.2.9
UP
0x000000000300000001
te
2.2.2.9
UP
0x000000000300000002
te
2.2.2.9
UP
Run the display tunnel-policy command, and you can view the destination address and tunnel
interface defined in the tunnel binding policy.
<HUAWEI> display tunnel-policy policy2
Tunnel Policy Name Select-Seq
Load balance No
--------------------------------------------------------------------The number of binding:1
Tunnel Policy Name Destination
Tunnel Intf
Down Switch
----------------------------------------------------------------------------policy2
1.1.1.1
Tunnel2
Disable
Run the display ip vpn-instance verbose command, and you can view the tunnel policy applied
to the VPN instance. For example, from the following output, you can view that the tunnel policy
applied to the VPN instance vpna is policy1.
<HUAWEI> display ip vpn-instance verbose
Total VPN-Instances configured : 1
VPN-Instance Name and ID : vpna, 1
Interfaces : GigaEthernet3/0/2
Address family ipv4
Create date : 2009/11/04 17:47:21
Up time : 0 days, 01 hours, 58 minutes and 12 seconds
Route Distinguisher : 11:11
Export VPN Targets : 22:22
Import VPN Targets : 22:22
Label Policy : label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
Tunnel Policy : policy2
Maximum Routes Limit : 100
Issue 01 (2011-10-15)
Process ID: 0
Cost: 0
12
2.2.2.2
Neighbour:
Active Adv Relied
Age:
0
Priority:
0x13
QoSInfo:
0xb9
0.0.0.0
Interface:
0x000000000300000002 Flags:
Context
In routine maintenance, you can run the following commands in any view to know tunnel
running.
Procedure
l
Run the display interface tunnel interface-number command to check information about
a tunnel interface.
Run the display tunnel-info tunnel-id command to check details about a tunnel.
Run the display tunnel-policy policy-namecommand to view the configuration about the
specified tunnel policy.
----End
Issue 01 (2011-10-15)
13
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. In a cluster, an interface is numbered in the format of chassis ID/slot number/
card number/interface number. This requires the chassis ID to be specified along with the slot
number.
Figure 1-4 shows an MPLS L3VPN. CE1 and CE3 belong to vpna; CE2 and CE4 belong to
vpnb. Two MPLS TE tunnels and one LSP are set up between PE1 and PE2. One of the TE
tunnels is 5 Mbit/s, and the other is 10 Mbit/s. CEs in vpna require 10 Mbit/s bandwidth for
communication. Therefore, you need to bind the eligible tunnel to vpna to ensure bandwidth of
vpna. To make full use of tunnel resources, vpnb uses load balancing for tunnels and prefers the
TE tunnel.
Figure 1-4 Networking diagram for configuring a tunnel policy for an L3VPN
Loopback1
3.3.3.3/32
vpna
CE1
Loopback1
1.1.1.1/32
POS1/0/0
10.1.1.1/30
POS1/0/0
10.3.1.1/30
POS2/0/0
10.3.1.2/30
POS2/0/0
10.1.1.2/30
POS2/0/1
10.2.1.2/30
MPLS TE tunnel 1
Loopback1
2.2.2.2/32
PE1
POS1/0/0
100.1.1.2/30
POS1/0/0
100.1.1.1/30
POS1/0/0
10.2.1.1/30
LSP
Loopback1
5.5.5.5/32
vpna
CE3
POS2/0/1
PE2 10.4.1.2/30
POS1/0/0
10.4.1.1/30
CE2
vpnb
Loopback1
4.4.4.4/32
CE4
vpnb
Loopback1
6.6.6.6/32
Configuration Roadmap
The configuration roadmap is as follows:
1.
2.
Configure basic MPLS functions on the router in the backbone network and set up an LSP
and two MPLS TE tunnels between PEs.
3.
Issue 01 (2011-10-15)
14
4.
Configure tunnel policies and apply the policies to different VPN instances.
5.
Configure the Multi-protocol Extensions for Interior Border Gateway Protocol (MP-IBGP)
on PEs to exchange VPN routing information.
Data Preparation
To complete the configuration, you need the following data.
l
Procedure
Step 1 Configure an IGP on the MPLS backbone network so that PEs can communicate.
# Configure PE1.
<HUAWEI> system-view
[~HUAWEI] sysname PE1
[~HUAWEI] commit
[~PE1] interface loopback 1
[~PE1-LoopBack1] ip address 1.1.1.1 32
[~PE1-LoopBack1] quit
[~PE1] interface pos1/0/0
[~PE1-Pos1/0/0] ip address 100.1.1.1 30
[~PE1-Pos1/0/0] undo shutdown
[~PE1-Pos1/0/0] quit
[~PE1] ospf 1
[~PE1-ospf-1] area 0
[~PE1-ospf-1-area-0.0.0.0]network 100.1.1.0 0.0.0.3
[~PE1-ospf-1-area-0.0.0.0] network 1.1.1.1 0.0.0.0
[~PE1-ospf-1-area-0.0.0.0] quit
[~PE1-ospf-1] quit
[~PE1] commit
# Configure PE2.
<HUAWEI> system-view
[~HUAWEI] sysname PE2
[~HUAWEI] commit
[~PE2] interface loopback 1
[~PE2-LoopBack1] ip address 2.2.2.2 32
[~PE2-LoopBack1] quit
[~PE2] interface pos 1/0/0
[~PE2-Pos1/0/0] ip address 100.1.1.2 30
[~PE2-Pos1/0/0] undo shutdown
[~PE2-Pos1/0/0] quit
[~PE2] ospf 1
[~PE2-ospf-1] area 0
[~PE2-ospf-1-area-0.0.0.0] network 100.1.1.0 0.0.0.3
[~PE2-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[~PE2-ospf-1-area-0.0.0.0] commit
[~PE2-ospf-1-area-0.0.0.0] quit
[~PE2-ospf-1] quit
# After the configuration, run the display ip routing-table command on PEs, and you can view
that PEs learn the routes to the Loopback1 interfaces from each other.
# Take the display on PE1 as an example.
[~PE1] display ip routing-table
Route Flags: R - relay, D - download to forwarding
------------------------------------------------------------------------------
Issue 01 (2011-10-15)
15
Interface
LoopBack1
Pos1/0/0
Pos1/0/0
Pos1/0/0
InLoopBack0
InLoopBack0
Step 2 Configure basic MPLS capability on the MPLS backbone network and setup the Label
Distribution Protocol (LDP) LSP between PEs.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos 1/0/0
[~PE1-Pos1/0/0] mpls
[~PE1-Pos1/0/0] mpls ldp
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
# Configure PE2.
[~PE2] mpls lsr-id 2.2.2.2
[~PE2] mpls
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] quit
[~PE2] interface pos 1/0/0
[~PE2-Pos1/0/0] mpls
[~PE2-Pos1/0/0] mpls ldp
[~PE2-Pos1/0/0] commit
[~PE2-Pos1/0/0] quit
After the configuration, run the display tunnel-info all command, you can find that the LSPs
between PE1 and PE2 are set up. Run the display mpls ldp lsp command, you can view the
information about the LSPs.
# Take PE1 as an example.
[~PE1] display tunnel-info all
Tunnel ID
Type
Destination
Status
----------------------------------------------------------------------------0x0000000001004c4b81
ldp
2.2.2.2
UP
<PE1> display mpls ldp lsp
LDP LSP Information
------------------------------------------------------------------------------DestAddress/Mask
In/OutLabel
UpstreamPeer
NextHop
OutInterface
------------------------------------------------------------------------------*1.1.1.1/32
Liberal/16
DS/2.2.2.2
1.1.1.1/32
3/NULL
2.2.2.2
127.0.0.1
Loop1
2.2.2.2/32
NULL/3
100.1.1.2
Pos1/0/0
2.2.2.2/32
16/3
2.2.2.2
100.1.1.2
Pos1/0/0
------------------------------------------------------------------------------TOTAL: 3 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
TOTAL: 0 Frr LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
A '*' before a UpstreamPeer means the session is in GR state
A '*' before a NextHop means the LSP is FRR LSP
16
# Configure the maximum link bandwidth and reservable bandwidth for the TE tunnels.
# Configure PE1.
[~PE1] mpls
[~PE1-mpls] mpls te
[~PE1-mpls] mpls rsvp-te
[~PE1-mpls] mpls te cspf
[~PE1-mpls] quit
[~PE1] interface pos1/0/0
[~PE1-Pos1/0/0] mpls te
[~PE1-Pos1/0/0] mpls rsvp-te
[~PE1-Pos1/0/0] mpls te bandwidth max-reservable-bandwidth 20000
[~PE1-Pos1/0/0] mpls te bandwidth bc0 15000
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
# Configure PE2.
[~PE2] mpls
[~PE2-mpls] mpls te
[~PE2-mpls] mpls rsvp-te
[~PE2-mpls] mpls te cspf
[~PE2-mpls] quit
[~PE2] interface pos1/0/0
[~PE2-Pos1/0/0] mpls te
[~PE2-Pos1/0/0] mpls rsvp-te
[~PE2-Pos1/0/0] mpls te bandwidth max-reservable-bandwidth 20000
[~PE2-Pos1/0/0] mpls te bandwidth bc0 15000
[~PE2-Pos1/0/0] commit
[~PE2-Pos1/0/0] quit
# Enable OSPF on the devices along the TE tunnels to transmit the TE attributes.
# Configure PE1.
[~PE1] ospf 1
[~PE1-ospf-1] opaque-capability enable
[~PE1-ospf-1] area 0
[~PE1-ospf-1-area-0.0.0.0] mpls-te enable
[~PE1-ospf-1-area-0.0.0.0] commit
[~PE1-ospf-1-area-0.0.0.0] quit
[~PE1-ospf-1] quit
# Configure PE2.
[~PE2] ospf 1
[~PE2-ospf-1] opaque-capability enable
[~PE2-ospf-1] area 0
[~PE2-ospf-1-area-0.0.0.0] mpls-te enable
[~PE2-ospf-1-area-0.0.0.0] commit
[~PE2-ospf-1-area-0.0.0.0] quit
[~PE2-ospf-1] quit
# Configure PE2.
[~PE2] interface tunnel 1
[~PE2-Tunnel1] ip address unnumbered interface loopback1
Issue 01 (2011-10-15)
17
tunnel-protocol mpls te
destination 1.1.1.1
mpls te bandwidth ct0 5000
commit
quit
# Set up a 10 Mbit/s MPLS TE tunnel and bind the tunnel to a VPN instance.
# Configure PE1.
[~PE1] interface tunnel 2
[~PE1-Tunnel2] ip address unnumbered interface loopback1
[~PE1-Tunnel2] tunnel-protocol mpls te
[~PE1-Tunnel2] destination 2.2.2.2
[~PE1-Tunnel2] mpls te bandwidth ct0 10000
[~PE1-Tunnel2] mpls te reserved-for-binding
[~PE1-Tunnel2] commit
[~PE1-Tunnel2] quit
# Configure PE2.
[~PE2] interface tunnel 2
[~PE2-Tunnel2] ip address unnumbered interface loopback1
[~PE2-Tunnel2] tunnel-protocol mpls te
[~PE2-Tunnel2] destination 1.1.1.1
[~PE2-Tunnel2] mpls te bandwidth ct0 10000
[~PE2-Tunnel2] mpls te reserved-for-binding
[~PE2-Tunnel2] commit
[~PE2-Tunnel2] quit
# After the configuration, run the display tunnel-info all command on PEs, and you can view
that Tunnel1 and Tunnel2 interfaces are both Up. Take the display on PE1 as an example.
<PE1> display tunnel-info all
Tunnel ID
Type
Destination
Status
----------------------------------------------------------------------------0x0000000001004c4b81
ldp
2.2.2.2
UP
0x000000000300000001
te
2.2.2.2
UP
0x000000000300000002
te
2.2.2.2
UP
Step 4 Configure VPN instances on PEs and configure CEs to access PEs.
# Configure PE1.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] ip vpn-instance vpnb
[~PE1-vpn-instance-vpnb] ipv4-family
[~PE1-vpn-instance-vpnb-af-ipv4] route-distinguisher 100:2
[~PE1-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[~PE1-vpn-instance-vpnb-af-ipv4] quit
[~PE1-vpn-instance-vpnb] quit
[~PE1] interface pos2/0/0
[~PE1-Pos2/0/0] ip binding vpn-instance vpna
[~PE1-Pos2/0/0] ip address 10.1.1.2 30
[~PE1-Pos2/0/0] undo shutdown
[~PE1-Pos2/0/0] quit
[~PE1] interface pos 2/0/1
[~PE1-Pos2/0/1] ip binding vpn-instance vpnb
[~PE1-Pos2/0/1] ip address 10.2.1.2 30
[~PE1-Pos2/0/1] undo shutdown
[~PE1-Pos2/0/1] commit
[~PE1-Pos2/0/1] quit
# Configure PE2.
Issue 01 (2011-10-15)
18
# Assign an IP address to each interface on CEs according to Figure 1-4. The detailed
configuration procedure is not mentioned here.
# After the configuration, run the display ip vpn-instance verbose command on PEs to view
the configurations of VPN instances.
NOTE
If a PE has multiple interfaces bound to the same VPN, when you run the ping command to ping the CE
that is attached to the peer PE, you need to specify the source IP address; that is, you need to specify -a
source-ip-address in the ping -a source-ip-address -vpn-instance vpn-instance-name destinationaddress command. Otherwise, the ping fails.
Step 5 Create tunnel policies on PEs and apply the tunnel policies.
# Configure a tunnel binding policy and apply the policy to vpna.
# Configure PE1.
[~PE1] tunnel-policy policy1
[~PE1-tunnel-policy-policy1] tunnel binding destination 2.2.2.2 te tunnel 2
[~PE1-tunnel-policy-policy1] quit
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] tnl-policy policy1
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] commit
# Configure PE2.
[~PE2] tunnel-policy policy1
[~PE2-tunnel-policy-policy1] tunnel binding destination 1.1.1.1 te tunnel 2
[~PE2-tunnel-policy-policy1] quit
[~PE2] ip vpn-instance vpna
[~PE2-vpn-instance-vpna] ipv4-family
[~PE2-vpn-instance-vpna-af-ipv4] tnl-policy policy1
[~PE2-vpn-instance-vpna-af-ipv4] quit
[~PE2-vpn-instance-vpna] quit
[~PE2] commit
# Configure a tunnel type prioritizing policy and apply the policy to vpnb.
# Configure PE1.
Issue 01 (2011-10-15)
19
# Configure PE2.
[~PE2] tunnel-policy policy2
[~PE2-tunnel-policy-policy2] tunnel select-seq cr-lsp lsp load-balance-number 2
[~PE2-tunnel-policy-policy2] quit
[~PE2] ip vpn-instance vpnb
[~PE2-vpn-instance-vpnb] ipv4-family
[~PE2-vpn-instance-vpnb-af-ipv4] tnl-policy policy2
[~PE2-vpn-instance-vpnb-af-ipv4] quit
[~PE2-vpn-instance-vpnb] quit
[~PE2] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 1.1.1.1 as-number 100
[~PE2-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE2-bgp] ipv4-family vpnv4
[~PE2-bgp-af-vpnv4] peer 1.1.1.1 enable
[~PE2-bgp-af-vpnv4] commit
[~PE2-bgp-af-vpnv4] quit
# After the configuration, run the display bgp peer or display bgp vpnv4 all peer command
on PEs, and you can view that a BGP peer relationship is set up between PEs and the BGP peer
relationship is in the Established state.
Step 7 Set up EBGP peer relationships between PEs and CEs.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[~PE1-bgp-af-vpna] peer 10.1.1.1 as-number 65410
[~PE1-bgp-af-vpna] quit
[~PE1-bgp] ipv4-family vpn-instance vpnb
[~PE1-bgp-af-vpnb] peer 10.2.1.1 as-number 65410
[~PE1-bgp-af-vpnb] commit
[~PE1-bgp-af-vpnb] quit
[~PE1-bgp] quit
# Configure CE1.
[CE1] bgp
[CE1-bgp]
[CE1-bgp]
[CE1-bgp]
[CE1-bgp]
Issue 01 (2011-10-15)
65410
peer 10.1.1.2 as-number 100
import-route direct
commit
quit
20
# Configure CE2.
[CE2] bgp
[CE2-bgp]
[CE2-bgp]
[CE2-bgp]
[CE2-bgp]
65410
peer 10.2.1.2 as-number 100
import-route direct
commit
quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] ipv4-family vpn-instance vpna
[~PE2-bgp-af-vpna] peer 10.3.1.1 as-number 65420
[~PE2-bgp-af-vpna] quit
[~PE2-bgp] ipv4-family vpn-instance vpnb
[~PE2-bgp-af-vpnb] peer 10.4.1.1 as-number 65420
[~PE2-bgp-af-vpnb] commit
[~PE2-bgp-af-vpnb] quit
[~PE2-bgp] quit
# Configure CE3.
[CE3] bgp
[CE3-bgp]
[CE3-bgp]
[CE3-bgp]
[CE3-bgp]
65420
peer 10.3.1.2 as-number 100
import-route direct
commit
quit
# Configure CE4.
[CE4] bgp
[CE4-bgp]
[CE4-bgp]
[CE4-bgp]
[CE4-bgp]
65420
peer 10.4.1.2 as-number 100
import-route direct
commit
quit
3.3.3.3/32
5.5.5.5/32
10.1.1.0/30
10.1.1.2/32
10.3.1.0/30
0.0.0.0
10.1.1.2
0.0.0.0
0.0.0.0
10.1.1.2
MED
LocPrf
PrefVal Path/Ogn
0
0
0
0
0
0
0
?
100 65420?
?
?
100 65420?
# Run the display ip routing-table vpn-instance verbose command on PEs, and you can view
the tunnel used by VPN routing.
# Take the display on PE1 as an example.
[~PE1] display ip routing-table vpn-instance vpna 5.5.5.5 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpna
Summary Count : 1
Issue 01 (2011-10-15)
21
Destination: 5.5.5.5/32
Protocol: BGP
Process ID: 0
Preference: 255
Cost: 0
NextHop: 2.2.2.2
Neighbour: 0.0.0.0
State: Active Adv Relied
Age: 00h00m08s
Tag: 0
Priority: low
Label: 0x13
QoSInfo: 0x0
IndirectID: 0xb9
RelayNextHop: 0.0.0.0
Interface: Tunnel2
TunnelID: 0x000000000300000002 Flags: RD
[~PE1] display ip routing-table vpn-instance vpnb 6.6.6.6 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpnb
Summary Count : 1
Destination: 6.6.6.6/32
Protocol: BGP
Process ID:
Preference: 255
Cost:
NextHop: 2.2.2.2
Neighbour:
State: Active Adv Relied
Age:
Tag: 0
Priority:
Label: 0x15
QoSInfo:
IndirectID: 0xb8
RelayNextHop: 0.0.0.0
Interface:
TunnelID: 0x000000000300000001 Flags:
RelayNextHop: 0.0.0.0
Interface:
TunnelID: 0x0000000001004c4b81 Flags:
0
0
0.0.0.0
00h04m37s
low
0x0
Tunnel1
RD
LDP LSP
RD
# CEs in the same VPN can ping through each other whereas CEs in different VPNs cannot.
----End
Configuration Files
l
Issue 01 (2011-10-15)
22
Issue 01 (2011-10-15)
23
ip vpn-instance vpna
ipv4-family
route-distinguisher 100:3
tnl-policy policy1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
ip vpn-instance vpnb
ipv4-family
route-distinguisher 100:4
tnl-policy policy2
vpn-target 222:2 export-extcommunity
vpn-target 222:2 import-extcommunity
#
mpls lsr-id 2.2.2.2
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 100.1.1.2 255.255.255.252
mpls
mpls te
mpls te bandwidth max-reservable-bandwidth 20000
mpls te bandwidth bc0 15000
mpls rsvp-te
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpna
ip address 10.3.1.2 255.255.255.252
#
interface Pos2/0/1
undo shutdown
link-protocol ppp
ip binding vpn-instance vpnb
ip address 10.4.1.2 255.255.255.252
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
interface Tunnel1
ip address unnumbered interface LoopBack1
tunnel-protocol mpls te
destination 1.1.1.1
mpls te bandwidth ct0 5000
#
interface Tunnel2
ip address unnumbered interface LoopBack1
tunnel-protocol mpls te
destination 1.1.1.1
mpls te bandwidth ct0 10000
mpls te reserved-for-binding
#
bgp 100
peer 1.1.1.1 as-number 100
peer 1.1.1.1 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
Issue 01 (2011-10-15)
24
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance vpna
peer 10.3.1.1 as-number 65420
#
ipv4-family vpn-instance vpnb
peer 10.4.1.1 as-number 65420
#
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 100.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
#
tunnel-policy policy1
tunnel binding destination 1.1.1.1 te Tunnel2
#
tunnel-policy policy2
tunnel select-seq cr-lsp lsp load-balance-number 2
#
return
Issue 01 (2011-10-15)
25
Related Tasks
1.5 Configuring a Tunnel Binding Policy for an L3VPN
Issue 01 (2011-10-15)
26
27
In the scenario where the backbone network spans two ASs, ASBRs need to advertise VPNv4
routes through MP-EBGP.
2.10 Configuring Inter-AS VPN Option B (ASBR Also Functioning as a PE)
In the scenario where the backbone network spans two ASs, ASBRs need to advertise VPNv4
routes through MP-EBGP and ASBRs also need to function as PEs.
2.11 Configuring Inter-AS VPN Option B (ASBR Also Functioning as an RR)
In the scenario where the backbone network spans two ASs, ASBRs need to advertise VPNv4
routes through MP-EBGP. When multiple PEs exist in the ASs, you can configure an ASBR as
an RR to lower configuration complexities.
2.12 Configuring Inter-AS VPN Option B (Spanning More Than Two ASs)
In the scenario where the backbone network spans more than two ASs, ASBRs need to advertise
VPNv4 routes through MP-EBGP.
2.13 Configuring the Multi-VPN-Instance CE
By using OSPF multi-instance on CEs, you can implement service isolation on the LAN.
2.14 Configuring VPN FRR
In the networking of CE dual-homing, you can configure VPN FRR to ensure VPN service
switchover to a secondary link when the primary link between PEs fails.
2.15 Configuring FRR for IP Routes on a Private Network
This section describes how to configure FRR for IP routes on a private network in the networking
where multiple CEs at a VPN site access the same PE. This feature can quickly switch traffic to
a link connected to another CE if the primary route from a PE to a CE becomes unreachable.
2.16 Configuring Hybrid FRR for IP and VPNv4 Routes
This section describes how to configure hybrid FRR in the networking where a CE is dual-homed
to two PEs. If the next hop from a PE to a CE is unreachable, hybrid FRR can send traffic to
another PE over a tunnel, and the traffic will be routed to the CE by using IP forwarding on the
private network. This improves network reliability.
2.17 Maintaining BGP/MPLS IP VPN
Maintaining BGP/MPLS IP VPN involves checking L3VPN traffic, monitoring network
connectivity, resetting BGP connections, and debugging BGP/MPLS IP VPN information.
2.18 Configuration Examples
This section provides several configuration examples of VPN networking. In each configuration
example, the networking requirements, configuration notes, configuration roadmap,
configuration procedures, and configuration files are provided.
Issue 01 (2011-10-15)
28
VPN 1
Site
CE
Service provider's
P backbone
P
CE
VPN 2
Site
PE
PE
PE
VPN 2
Site
CE
CE
VPN 1
Site
BGP/MPLS IP VPN features flexible networking modes, excellent extensibility and convenient
support for Quality of Service (QoS) and MPLS Traffic Engineering (MPLS TE) features. It is
now widely used.
In BGP/MPLS IP VPN, three types of devices are involved:
l
Customer Edge (CE): It is an edge device on the user network. A CE is directly connected
to a Service Provider (SP) network. CEs can be routers, switches, or hosts. Usually, CEs
cannot sense the existence of VPNs and need not support MPLS.
29
Intranet
All users in a VPN form a Closed User Group (CUG) and the users can forward data to
each other. Users in a VPN cannot communicate with users outside the VPN. As shown in
Figure 2-2, Site 1 in VPN1 can communicate with only Site4 and cannot communicate
with Sites 2 and 3.
Figure 2-2 Schematic diagram of an intranet
VPN1
Import: 100:1
Export: 100:1
VPN1
CE
Site1
VPN2
CE
Site2
VPN2
VPN2
Import: 200:1
Export: 200:1
CE
Site3
Backbone
PE
VPN2
Import: 200:1
Export: 200:1
VPN1
PE
VPN1
Import: 100:1
Export: 100:1
CE
Site4
Extranet
A user in a VPN can communicate with sites in another VPN. As shown in Figure 2-3,
Sites 1 and 2 both can communicate with Site3 and Site3 can communicate both Sites 1
and 2. Site1 and Site2, however, cannot communicate.
Figure 2-3 Schematic diagram of an extranet
Site1
CE
VPN1
Import: 100:1
Export: 100:1
VPN1
VPN1
PE1
PE2
Site3
VPN2
CE
Site2
Issue 01 (2011-10-15)
CE
PE3
VPN2
Import: 200:1
Export: 200:1
VPN1
Import: 100:1, 200:1
Export: 100:1, 200:1
30
VPN1
Spoke-PE
Site1
VPN1
Spoke-CE
Hub-PE
VPN1
Hub-CE
Site3
Spoke-CE
Spoke-PE
Site2
Inter-AS VPN
If a VPN backbone network spans multiple ASs, inter-AS VPN must be deployed. There
are two modes for implementing inter-AS VPN: Option A and Option B.
Multi-VPN-Instance CE
Currently, different services on a Local Area Network (LAN) are isolated through the
Virtual LAN (VLAN) function of switches. However, the routing capability of a switch is
weaker than the router. To ensure that the services of the LAN are safely isolated and
improve the routing capability of the LAN, you can configure Multi-VPN-Instance CE to
solve the security problem of the LAN at a low cost.
Reliability
To improve the reliability of a VPN, generally, the following networking models are adopted:
l
The backbone network is an MPLS network, in which the devices on the backbone layer
are fully connected and backed up. The devices on the backbone layer are generally
connected through high-speed interfaces. If the number of PEs is large, use a BGP route
reflector to reflect VPNv4 routes to decrease the number of MP-IBGP connections.
31
VPN Fast ReRoute (VPN FRR): ensures that VPN traffic can be switched to another PEPE link when traffic forwarding between PEs fails. In this way, end-to-end fast convergence
of VPN services is implemented.
VPN Graceful Restart (VPN GR): ensures that VPN traffic is not interrupted when
therouter (PE, P, or CE) bearing the VPN traffic performs master-slave switchover. This
reduces the impact of a single point failure on VPN services. Currently, the NE5000E
supports only the GR helper.
VPN NSR
Non-Stop Routing (NSR) is a technique that prevents a peer from sensing the fault on the
control plane of a router that provides a slave control plane. With NSR, when the control
plane of the router becomes faulty, the peer relationships set up through specific routing
protocols, MPLS, and other protocols that carry services are not interrupted.
During the master/slave switchover, VPN NSR ensures the continuous forwarding at the
forwarding plane and continuous advertisement of VPN routes. In this process, the peer
relationships are not affected, with peers not knowing the switchover on the local router.
This ensures uninterrupted transmission of VPN services.
Applicable Environment
A VPN instance is an important part in the VPN technology. VPN instances are used to isolate
private network routes and public network routes.
VPN instances exist only on PEs for creating private network routing tables and saving VPN
routes sent by local CEs and remote PEs.
Pre-configuration Tasks
Before configuring a VPN instance enabled with the IPv4 address family, complete the following
tasks:
l
Configuring tunnel policies to implement tunnel load balancing for VPN instance IPv4
address family, change the default sequence in which Label Switched Paths (LSPs) or
MPLS TE tunnels are selected, or bind VPN instances to TE tunnels
Issue 01 (2011-10-15)
32
Configuration Procedures
Figure 2-5 Flowchart for configuring a VPN instance enabled with the IPv4 address family
Create a VPN instance
Configure attributes for the VPN instance
IPv4 address family
Limit the route number of the VPN instance IPv4
address family
Apply a tunnel policy to the VPN instance IPv4
address family
Configure MPLS label allocation based on the
VPN instance IPv4 address family
Mandatory
procedure
Optional
procedure
Procedure
Step 1 Run:
system-view
The name of a VPN instance is case sensitive. For example, vpn1 and VPN1 are two different VPN
instances.
The description about the VPN instance is configured. The description is used to record the
purpose of creating the VPN instance and the CEs with which the VPN instance sets up
connections.
Step 4 Run:
commit
33
Context
In addition to the VPN target attribute used to control the import and export of VPN routes, you
can configure a routing policy to control VPN route control accurately.
Procedure
Step 1 Run:
system-view
The IPv4 address family is enabled for the VPN instance and the VPN instance IPv4 address
family view is displayed.
A VPN instance supports the IPv4 address family and IPv6 address family. You can configure
the VPN only after the IPv4 or IPv6 address family is configured on the basis of the type of the
protocol stack used to advertise routes and forward data.
Step 4 Run:
route-distinguisher route-distinguisher
A configured RD cannot be changed or deleted. You need to delete a VPN instance or disable the VPN
instance IPv4 address family before changing or deleting the RD of the VPN instance IPv4 address
family.
Step 5 Run:
vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-extcommunity ]
A VPN target is configured for the VPN instance IPv4 address family.
A VPN target is an extended community attribute of BGP. It controls the import and export of
VPN routes. When a PE exports VPN routes to other PEs, it appends export VPN targets to the
exported routes. When a PE imports VPN routes from other PEs, it decides whether to add the
imported routes to the corresponding VPN instances IPv4 address family according to the import
VPN targets of the local VPN instances and export VPN targets appended to the imported routes.
Issue 01 (2011-10-15)
34
You can configure a maximum of eight VPN targets each time you run the vpn-target command.
Step 6 (Optional) Run:
import route-policy policy-name
A BGP private routing table is created for the VPN instance and the BGP-VPN instance view
is displayed.
VPN targets configured for VPN instance IPv4 address family can be synchronized into a BGP
private routing table only after the ipv4-family vpn-instance command is run. In this way, VPN
targets can be used to filter the routes to be injected to the BGP private routing table. If the ipv4family vpn-instance command is not run, no route can be injected to the BGP private routing
table.
Step 11 Run:
commit
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
35
The maximum number of prefixes of the VPN instance IPv4 address family is set.
To prevent a PE from importing excessive prefixes from CEs, you can set the maximum number
of prefixes supported by a VPN instance IPv4 address family.
If simply-alert is specified, it indicates that when the number of VPN prefixes exceeds the
number, the system generates an alarm and still injects VPN prefixe to the routing table of the
VPN instance IPv4 address family. After the total number of VPN prefixes and the public
network routes reaches the unicast route limit specified in the license file, the subsequent VPN
prefixes are dropped.
Step 5 Run:
commit
Context
By default, the system selects a tunnel for the VPN instance IPv4 address family in the sequence
of LSPs, CR-LSPs, GRE tunnels, and Local_IfNet, and load balancing is not performed. In the
following cases:
l
You need to configure a tunnel policy on the PE and apply the tunnel policy to the VPN instance
IPv4 address family.
Currently, the NE5000E supports two types of tunnel policy:
l
Issue 01 (2011-10-15)
Tunnel type prioritizing policy: is used to change the sequence in which each type of tunnels
are selected or set the number of tunnels participating in load balancing.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
36
Tunnel binding policy: is used to bind a TE tunnel to a destination address so that VPN
services for this destination can be transmitted over this dedicated TE tunnel.
For configurations about tunnel policies, see the chapter "VPN Tunnel Management
Configuration" in this manual.
Procedure
Step 1 Run:
system-view
The IPv4 address family is enabled for the VPN instance and the VPN instance IPv4 address
family view is displayed.
Step 4 Run:
tnl-policy policy-name
Context
By default, the system allocates one label to each route of the VPN instance IPv4 address
family. When a large number of VPN routes exist, the Incoming Label Map (ILM) on a PE needs
to maintain a great deal of information. This poses a requirement for a larger capacity of the PE.
To reduce the entries in the ILM, you can configure the system to allocate a label for each VPN
instance IPv4 address family. Then, all the routes of the VPN instance IPv4 address family use
one label.
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
37
The IPv4 address family is enabled for the VPN instance and the VPN instance IPv4 address
family view is displayed.
Step 4 Run:
apply-label per-instance
MPLS label allocation based on VPN instance IPv4 address family is configured. Then, all the
routes of the VPN instance IPv4 address family use one label.
NOTE
The change of the label allocation mode leads to the re-advertisement of VPN routes. So, use the apply-label
per-instance command with caution.
Step 5 Run:
commit
Prerequisite
All configurations about the VPN instance are complete.
Procedure
l
----End
Example
After a VPN instance is configured, run the display ip vpn-instance command, and you can
view brief information about the configured VPN instance on the local device. For example:
<HUAWEI> display ip vpn-instance
Total VPN-Instances configured : 5
VPN-Instance Name
Address-family
vrf1
ipv4 ipv6
vrf2
vrf3
ipv4 ipv6
vrf4
ipv4
vrf5
ipv6
Issue 01 (2011-10-15)
38
Run the display ip vpn-instance verbose command, and you can view detailed information
about the VPN instance configured on the local device. For example:
<HUAWEI> display ip vpn-instance verbose vpn1
VPN-Instance Name and ID : vpn1, 1
Interfaces : GigabitEthernet1/0/0
Address family ipv4
Create date : 2009/11/19 11:48:13
Up time : 0 days, 00 hours, 41 minutes and 51 seconds
Route Distinguisher : 1:1
Export VPN Targets : 1:2
Import VPN Targets : 1:2
Label policy : label per instance
Import Route Policy : p1
Export Route Policy : p2
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
Tunnel Policy : tnlpolicy1
Description : This is a VPN for company1.
Maximum Routes Limit : 100
Threshold Routes Limit : 80%
Applicable Environment
The basic BGP/MPLS IP VPN supports intranet VPN, extranet VPN, and Hub and Spoke
solutions.
l
Intranet: All users in a VPN form a CUG and users in a VPN cannot communicate with
users outside the VPN.
Hub and Spoke: An access control device is specified in a VPN, and users communicate
with each other through this access control device. For configurations about Hub and Spoke,
see Configuring Hub and Spoke.
Pre-configuration Tasks
Before configuring basic BGP/MPLS IP VPN, complete the following tasks:
l
Configuring basic MPLS functions and MPLS LDP on the MPLS backbone network (PE
and P)
Issue 01 (2011-10-15)
39
Configuration Procedures
Figure 2-6 Flowchart for configuring basic BGP/MPLS IP VPN
Configure a VPN instance
Bind an
interface to a VPN instance
Configure a router ID for
a BGP VPN instance IPv4 address family
Configure
route exchange between PEs
Configure route exchange
between a PE and a CE
Mandatory
procedure
Optional
procedure
Related Tasks
2.18.1 Example for Configuring BGP/MPLS IP VPN
Procedure
Step 1 For detailed procedure for configuring a VPN instance, see 2.3 Configuring a VPN Instance
Enabled with the IPv4 Address Family.
----End
Procedure
Step 1 Run:
system-view
40
Step 3 Run:
ip binding vpn-instance vpn-instance-name
After the ip binding vpn-instance command is run on an interface, the Layer 3 features such as the IP
address and routing protocol configured on the interface are deleted.
Step 4 Run:
ip address ip-address { mask | mask-length }
Context
By default, no router ID is configured for a BGP VPN instance IPv4 address family, and the
BGP router ID is used. This makes different BGP VPN instance IPv4 address families on the
same device have the same router ID. In some cases, different router IDs need to be configured
for different BGP VPN instance IPv4 address families. For example, BGP peer relationships
need to be established between different BGP VPN instance IPv4 address families on the same
PE.
There are two methods of configuring a router ID for a BGP VPN instance IPv4 address family.
You can choose either of the two methods as required.
CAUTION
If a BGP session has been established in a BGP-VPN instance IPv4 address family, changing
or deleting the configured router ID resets the BGP session.
Procedure
l
Configuring router IDs for all BGP VPN instance IPv4 address families
1.
Run:
system-view
Run:
bgp as-number
Issue 01 (2011-10-15)
41
Run:
router-id vpn-instance auto-select
Automatic router ID selection is configured for all BGP VPN instance IPv4 address
families.
NOTE
Rules for automatically selecting a router ID for a BGP VPN instance IPv4 address family are
as follows:
l If the loopback interfaces configured with IP addresses are bound to the VPN instance
enabled with the IPv4 address family, the largest IP address among the IP addresses of the
loopback interfaces is selected as the router ID.
l If no loopback interfaces configured with IP addresses are bound to the VPN instance
enabled with the IPv4 address family, the largest IP address among the IP addresses of
other interfaces bound to the VPN instance is selected as the router ID, regardless of whether
the interface is Up or Down.
Configuring a router ID for a specified BGP VPN instance IPv4 address family
1.
Run:
system-view
Run:
bgp as-number
Run:
ipv4-family vpn-instance vpn-instance-name
Run:
router-id { ipv4-address | auto-select }
A router ID or automatic route ID selection is configured for the current BGP VPN
instance IPv4 address family.
----End
Procedure
Step 1 Run:
system-view
42
Step 3 Run:
peer peer-address as-number as-number
PEs must use the loopback interface addresses with 32-bit masks to establish an MP-IBGP peer relationship
so that routes can be iterated to the tunnel.
Step 5 Run:
ipv4-family vpnv4
Context
PEs and CEs can exchange routes through static routes (including default routes), RIP multiinstance, OSPF multi-instance, IS-IS multi-instance, or BGP.
NOTE
The VPN that can receive the routes of another VPN that are not advertised by the PE and advertise the
routes to the PE is called a transit VPN.
The VPN that receives only the routes of the local VPN and advertised by the PE is called a stub VPN.
Commonly, static routes are used for route exchange between the CE and the PE in a stub VPN.
Issue 01 (2011-10-15)
43
NOTE
For detailed configurations about the IS-IS, OSPF, BGP, static route, and RIP, see the HUAWEI
NetEngine5000E Core Router Configuration Guide - IP Routing.
Procedure
l
Run:
system-view
Run:
isis process-id vpn-instance vpn-instance-name
An IS-IS instance is created on the PE for communications between the PE and the
CE and the IS-IS view is displayed.
An IS-IS process can be bound to only one VPN instance. If you run an IS-IS process
without binding it to a VPN instance, the IS-IS process is considered as a public
network process. The IS-IS process on the public network cannot be bound to a VPN
instance.
3.
Run:
network-entity net
(Optional) Run:
is-level { level-1 | level-1-2 | level-2 }
Run:
import-route bgp [ cost value ] [ cost-type { external | internal } ]
[ level-1 | level-1-2 | level-2 ] [ route-policy policy-name ] [ tag tagvalue ]
Run:
commit
Run:
quit
Run:
interface interface-type interface-number
Issue 01 (2011-10-15)
44
Run:
isis enable [ process-id ]
The IS-IS route is imported into the routing table of the BGP VPN instance IPv4
address family.
14. Run:
commit
After the VPN instance is deleted or disable the IPv4 address family of the VPN instance, all
the IS-IS processes bound to the VPN instance are deleted.
Run:
system-view
Run:
ospf process-id [ router-id router-id ] vpn-instance vpn-instance-name
An OSPF instance is created on the PE for communications between the PE and the
CE and the OSPF view is displayed.
An OSPF process can be bound to only one VPN instance. If you run an OSPF process
without binding it to a VPN instance, the OSPF process is considered as a public
network process. The OSPF process on the public network cannot be bound to a VPN
instance.
The OSPF process that is bound to the VPN instance does not use the public network
router ID configured in the system view. You must specify the router ID when starting
the OSPF process. If no router ID is specified, OSPF selects an IP address from the
IP addresses of the interfaces bound to this VPN instance based on route ID selection
rules and takes the selected IP address as the router ID.
Issue 01 (2011-10-15)
45
3.
(Optional) Run:
domain-id domain-id [ secondary ]
(Optional) Run:
route-tag tag-value
Run:
import-route bgp [ cost value ] [ type { 1 | 2 } ] [ tag value ] [ routepolicy policy-name ]
Run:
area area-id
Run:
network ip-address wildcard-mask
OSPF is run on the network segment where the interface bound to the VPN instance
resides.
A network segment belongs to only one area. That is, you need to specify an area for
each interface that runs OSPF.
Issue 01 (2011-10-15)
46
OSPF can properly run on an interface only when the following conditions are met:
The mask length of the IP address of the interface is equal to or longer than the
mask length specified in the network command.
The primary IP address of the interface is within the network segment specified in
the network command.
For a loopback interface, by default, OSPF advertises its IP address in 32-bit host
route, which is irrelevant to the mask length of the IP address on the interface.
8.
Run:
commit
Run:
quit
The OSPF route is imported into the routing table of the BGP VPN instance IPv4
address family.
14. Run:
commit
After the VPN instance is deleted or disable the IPv4 address family of the VPN instance, all
the OSPF processes bound to the VPN instance are deleted.
Run:
system-view
Run:
bgp as-number
47
3.
Run:
ipv4-family vpn-instance vpn-instance-name
Run:
peer peer-address as-number number
(Optional) Run:
peer { ipv4-address } ebgp-max-hop [ number ]
(Optional) Select either step to import the direct routes destined for the local CE to
the VPN routing table and advertise the routes to the remote PE.
Run the import-route direct [ med med | route-policy policy-name ]* command
to import the direct routes destined for the local CE.
Run the network ip-address mask command to advertise the direct routes destined
for the local CE.
7.
(Optional) Run:
peer { group-name | ipv4-address | ipv6-address } soo site-of-origin
The Site of Origin (SoO) attribute is configured for the specified CE.
When multiple CEs in a VPN site access different PEs, VPN routes sent from CEs to
PEs may return to this VPN site after traveling through the backbone network. This
may cause routing loops in the VPN site.
After the SoO attribute is configured on a PE, the PE adds the SoO attribute to the
route sent from a CE and then advertises the route to other PE peers. Before advertising
the VPN route to the connected CE, the PE peers check the SoO attribute carried in
the VPN route. If the PE peers find that this SoO attribute is the same as the locally
configured SoO attribute, the PE peers do not advertise this VPN route to the connected
CE.
8.
(Optional) Run:
peer ip-address allow-as-loop [ number ]
(Optional) Run:
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
48
In the case of CE multi-homing, the BGP AS number substitution function may lead to route
loops.
10. Run:
commit
Run:
system-view
Run:
bgp as-number
Run:
peer peer-address as-number as-number
(Optional) Run:
peer { ipv4-address | group-name } ebgp-max-hop [ number ]
Run:
import-route { direct | static | rip [ process-id ] | ospf process-id |
isis process-id } [ med med | route-policy policy-name ]*
Run:
commit
Run:
system-view
Issue 01 (2011-10-15)
49
Run:
ip route-static vpn-instance vpn-instance-name dest-ip-address { mask |
mask-length } { interface-type interface-number | vpn-instance vpndestination-name nexthop-address | nexthop-address [ public ] }
[ preference preference ] [ tag tag ] [ description text ]
The static route is configured for the specified VPN instance IPv4 address family.
3.
Run:
bgp as-number
Run:
ipv4-family vpn-instance vpn-instance-name
Run:
import-route static [ med med ] [ route-policy policy-name ]
The static route is imported into the routing table of the BGP VPN instance IPv4
address family.
6.
Run:
commit
Run:
system-view
Run:
rip process-id vpn-instance vpn-instance-name
A RIP instance is created on the PE for communicates between the PE and the CE and
the RIP view is displayed.
A RIP process can be bound to only one VPN instance. If you run a RIP process
without binding it to a VPN instance, the RIP process is considered as a public network
process. The RIP process on the public network cannot be bound to a VPN instance.
3.
Run:
network network-address
RIP is run on the network segment where the interface bound to the VPN instance
resides.
4.
Run:
import-route bgp [ cost value ] [ route-policy policy-name]
50
5.
Run:
commit
Run:
quit
Run:
bgp as-number
Run:
ipv4-family vpn-instance vpn-instance-name
Run:
import-route rip process-id [ med med ] [ route-policy policy-name ]
The RIP route is imported into the routing table of the BGP VPN instance IPv4 address
family.
After the import-route rip command is run in the BGP-VPN instance IPv4 address
family view, the PE imports the VPN routes learnt from the attached CE into BGP,
forms them into VPN-IPv4 routes, and advertises them to the remote PE.
10. Run:
commit
After the VPN instance is deleted or disable the IPv4 address family of the VPN instance, all
the RIP processes bound to the VPN instance are deleted.
Run:
system-view
Run:
bgp as-number
Run:
ipv4-family vpn-instance vpn-instance-name
Run:
peer peer-address as-number number
Issue 01 (2011-10-15)
(Optional) Select either step to import the direct route destined for the local CE to the
VPN routing table and advertise the route to the remote PE.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
51
If Step 5 is not performed, the PE does not advertise the direct route to the remote PE through
MP-BGP.
6.
Run:
commit
Run:
system-view
Run:
bgp as-number
Run:
peer peer-address as-number as-number
Run:
import-route { direct | static | rip [ process-id ] | ospf process-id |
isis process-id } [ med med | route-policy policy-name ]*
Run:
commit
Prerequisite
All configurations about basic BGP/MPLS IP VPN are complete.
Procedure
l
Issue 01 (2011-10-15)
52
Run the ping command on the local CE to ping the remote CE.
----End
Example
Run the display ip routing-table vpn-instance vpn-instance-name command on the PE, and
you can find that the PE has VPN routes to its interconnected CEs.
<HUAWEI> display ip routing-table vpn-instance vpna
Route Flags: R - relied, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: vpna
Destinations : 3
Routes : 3
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24
Direct 0
0
D
10.1.1.2
GigabitEthernet1/0/0
10.1.1.2/32
Direct 0
0
D
127.0.0.1
InLoopBack0
10.3.1.0/24
BGP
255 0
RD
3.3.3.9
Pos3/0/0
Run the ping command on the CE, and you can view that the local CE can ping the remote CE
successfully.
<HUAWEI> ping 10.3.1.1
PING 10.3.1.1: 56 data bytes, press CTRL_C to break
Reply from 10.3.1.1: bytes=56 Sequence=1 ttl=253 time=72
Reply from 10.3.1.1: bytes=56 Sequence=2 ttl=253 time=34
Reply from 10.3.1.1: bytes=56 Sequence=3 ttl=253 time=50
Reply from 10.3.1.1: bytes=56 Sequence=4 ttl=253 time=50
Reply from 10.3.1.1: bytes=56 Sequence=5 ttl=253 time=34
--- 10.3.1.1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 34/48/72 ms
ms
ms
ms
ms
ms
Applicable Environment
If too many PEs reside on the VPN backbone network and these PEs need to establish MP-IBGP
peer relationships to exchange VPN routes, you can configure route reflection to optimize the
VPN backbone network.
A BGP speaker does not advertise the routes learnt from an IBGP peer to other IBGP peers. To
enable a PE to advertise the routes of the VPN that the PE accesses to the BGP VPNv4 peers in
the same AS, the PE must establish IBGP peer relationships with all peers to directly exchange
VPN routing information. That is, MP-IBGP peers must be fully meshed. Suppose there are n
PEs (including ASBRs) in an AS, n (n-1)/2 pairs of MP-IBGP peers need be created. A large
number of IBGP peers consume a great number of network resources. After an RR is configured,
each PE needs to set up an MP-IBGP peer relationship with only the RR, that is, n pairs of MPIBGP peers are required.
Issue 01 (2011-10-15)
53
Pre-configuration Tasks
Before configuring route reflection to optimize the VPN backbone layer, complete the following
tasks:
l
Configuring the routing protocol for the MPLS backbone network to implement IP
interworking between routers on the backbone network
Configuration Procedures
Figure 2-7 Flowchart for configuring route reflection to optimize the VPN backbone layer
Configure a client PE to establish an MPIBGP peer relationship with an RR
Configure route
reflection for BGP VPNv4 routes
Mandatory
procedure
Optional
procedure
Related Tasks
2.18.5 Example for Configuring Double RRs for the Optimization of the VPN Backbone Layer
2.18.6 Example for Configuring an RR for the Optimization of the VPN Access Layer
Context
A PE or P can function as an RR on the backbone network.
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
54
A client PE must use the loopback interface address with a 32-bit mask to establish an MP-IBGP peer
relationship with the RR so that routes can be iterated to the tunnel.
Step 5 Run:
ipv4-family vpnv4
The capability of exchanging VPNv4 routes between the PE and the RR is enabled.
Step 7 Run:
commit
Procedure
l
Configuring the RR to establish an MP-IBGP peer relationship with each of its client
Perform Steps 3 to 6 repeatedly on the RR to establish MP-IBGP peer relationships with
all client PEs.
1.
Run:
system-view
Run:
bgp as-number
Run:
peer peer-ipv4-address as-number as-number
55
4.
Run:
peer peer-ipv4-address connect-interface interface-type interface-number
The interface used to establish a TCP connection is specified. The IP address of the
interface must be the same as the MPLS LSR ID. You are recommended to specify a
loopback interface to establish the TCP connection.
5.
Run:
ipv4-family vpnv4
Run:
peer peer-ipv4-address enable
The capability of exchanging VPNv4 routes between the RR and the client PE is
enabled.
7.
Run:
commit
Context
For detailed configurations about an RR, please refer to the chapter BGP Configuration in the
Configuration Guide - IP Routing.
Procedure
Step 1 Run:
system-view
The local device is configured as an RR and its peer is considered as the client of the RR.
Step 5 (Optional) Run:
undo reflect between-clients
Issue 01 (2011-10-15)
56
Route reflection between clients is disabled if the clients are fully connected.
Step 6 Run:
undo policy vpn-target
Prerequisite
All the configurations about route reflection are complete.
Procedure
l
Run the display bgp vpnv4 all peer [ [ ipv4-address ] verbose ] command on the RR or
client PE to view information about the BGP VPNv4 peer.
Run the display bgp vpnv4 all routing-table peer peer-ipv4-address { advertisedroutes | received-routes } [ statistics ] command on the RR or client PE to view
information about the routes received from the peer or the routes advertised to the peer.
----End
Example
l
Run the display bgp vpnv4 all peer command on the RR or client PE, and you can find
that the status of the MP-IBGP peer relationships between the RR and all client PEs is
"Established."
<HUAWEI> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 3
Peers in established state : 3
Peer
V
AS MsgRcvd MsgSent OutQ Up/Down
State PrefRcv
2.2.2.9
4
100 2
4
0
00:00:31
Established
0
3.3.3.9
4
100 3
5
0
00:01:23
Established
0
Peer of vpn instance :
VPN-Instance vpna, router ID 1.1.1.9:
10.1.1.1
4 65410
79
82
0 01:13:29 Established
0
Issue 01 (2011-10-15)
Run the display bgp vpnv4 all routing-table peer { advertised-routes | receivedroutes } command on the RR or client PE, and you can find that the RR and client PE can
exchange VPNv4 routing information.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
57
Applicable Environment
If it is required that an access control device be specified in the VPN and all the users access the
VPN through this access control device, you can deploy the Hub and Spoke networking so that
all the data exchanged between Spoke sites flow through the Hub site.
As shown in Figure 2-8, Site1 and Site2 in VPN1 communicate with each other through Site3.
In such a scenario, you can deploy a monitoring device at Site 3 to monitor the communication
between Site1 and Site2.
Figure 2-8 Diagram of the Hub-Spoke networking
VPN1
Spoke-PE
Site1
VPN1
Spoke-CE
Hub-PE
Hub-CE
Site3
Spoke-CE
Spoke-PE
Site2
VPN1
Pre-configuration Tasks
Before configuring Hub and Spoke, complete the following tasks:
l
Configuring the basic MPLS capability and establish an LDP LSP between PEs
Issue 01 (2011-10-15)
58
Configuration Procedures
Figure 2-9 Flowchart for configuring Hub and Spoke
Configure a VPN instance
Configure routing
attributes for a VPN instance
Bind an interface
to a VPN instance
Related Tasks
2.18.7 Example for Configuring Hub and Spoke
Context
In the Hub and Spoke networking, the PE connected to a central site (Hub site) is called a HubPE and the PE connected to a non-central site (Spoke site) is called a Spoke-PE.
You need to configure a VPN instance on each Spoke-PE and two VPN instances (VPN-in and
VPN-out) on each Hub-PE.
l
VPN-in is used to receive and maintain the VPNv4 routes advertised by all the Spoke-PEs.
VPN-out is used to maintain the routes of the Hub site and all the Spoke sites and advertise
the routes to all Spoke-PEs.
NOTE
Steps 1 to 7 are performed to configure one VPN instance. Configurations of different VPN instances are
similar. Note that the different VPN instances on the same device must have different names, RDs, and
description.
Procedure
Step 1 Run:
Issue 01 (2011-10-15)
59
system-view
The IPv4 address family is enabled for the VPN instance and the VPN instance IPv4 address
family view is displayed.
Step 5 Run:
route-distinguisher route-distinguisher
MPLS label allocation based on VPN instances IPv4 address family is configured. Then, all the
routes of the VPN instance IPv4 address family use one label.
In general, each route is assigned one label (one label per route).
Step 7 (Optional) Run:
prefix limit number { alert-percent | simply-alert }
The maximum number of prefixes of the VPN instance IPv4 address family is set.
To prevent a PE from importing excessive prefixes, you can set the maximum number of prefixes
supported by the VPN instance IPv4 address family.
Step 8 Run:
commit
60
PE must contain the export VPN targets configured on all the Spoke-PEs. The export VPN target
configured on the Hub-PE must contain the import VPN targets configure on all the Spoke-PEs.
Context
Controlling the advertisement of VPN routes by configuring VPN targets is also a key part of
the Hub and Spoke solution.
Procedure
l
Run:
system-view
Run:
ip vpn-instance vpn-instance-name1
Run:
ipv4-family
Run:
vpn-target vpn-target1 &<1-8> import-extcommunity
The VPN target extended community is configured for the VPN instance IPv4 address
family to receive the VPNv4 routes advertised by all the Spoke-PEs.
The vpn-target1 list here must contain the export VPN targets configured on all the
Spoke-PEs.
5.
(Optional) Run:
import route-policy policy-name
(Optional) Run:
export route-policy policy-name
Run:
commit
Run:
quit
Run:
ip vpn-instance vpn-instance-name2
Issue 01 (2011-10-15)
61
The VPN target extended community is configured for the VPN instance IPv4 address
family to advertise the routes of all the Hub sites and Spoke sites.
The vpn-target2 list here must contain the import VPN targets configured on all the
Spoke-PEs.
12. (Optional) Run:
import route-policy
policy-name
Run:
system-view
Run:
ip vpn-instance vpn-instance-name1
Run:
ipv4-family
Run:
vpn-target vpn-target2 &<1-8> import-extcommunity
The VPN target extended community is configured for the VPN instance IPv4 address
family to receive the VPNv4 routes advertised by the Hub-PE.
vpn-target2 must be in the export VPN target list configured on the Hub-PE.
5.
Run:
vpn-target vpn-target1 &<1-8> export-extcommunity
The VPN target extended community is configured for the VPN instance IPv4 address
family to advertise the routes of the sites the Spoke-PEs access.
vpn-target1 must be in the import VPN target list configured on the Hub-PE.
6.
(Optional) Run:
import route-policy policy-name
(Optional) Run:
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
62
Run:
commit
Context
The configuration on the Hub-PE involves two interfaces or sub-interfaces:
l
One is bound to VPN-out for advertising the routes of all the Hub sites and Spoke sites.
Procedure
Step 1 Run:
system-view
After the ip binding vpn-instance command is run on an interface, the Layer 3 features such as the IP
address and routing protocol configured on the interface are deleted.
Step 4 Run:
ip address ip-address { mask | mask-length }
63
Context
MP-IBGP peer relationships need be established between the Hub-PE and each Spoke-PE.
Spoke-PEs need not exchange routes directly and therefore they need not establish MP-IBGP
peer relationships.
Do as follows on the Hub-PE and all the Spoke-PEs:
Procedure
Step 1 Run:
system-view
PEs must use the loopback interface addresses with 32-bit masks to establish an MP-IBGP peer relationship
so that routes can be iterated to the tunnel. The route to the loopback interface is advertised to the peer PE
through IGP on the MPLS backbone network.
Step 5 Run:
ipv4-family vpnv4 [unicast]
The capability of exchanging BGP VPNv4 routing information with the peer is enabled.
Step 7 Run:
commit
64
Context
The routing protocol run between a Spoke-PE and a Spoke-CE is related to the routing protocol
run between a Hub-PE and a Hub-CE. EBGP, IGP, and the static route (including the default
route) can run between a Hub-PE and a Hub-CE. You can choose any of them as required.
Procedure
l
Configuring a static route (including the default route) between a Hub-PE and a Hub-CE
For detailed configuration procedures, see 2.4.5 Configuring Route Exchange Between
a PE and a CE.
In this mode, EBGP, IGP, or static route (including the default route) can be run between
a Spoke-PE and a Spoke-CE.
If a Hub-CE adopts the default route to access the Hub-PE, to enable the Hub-PE to advertise
the default route to all the Spoke-PEs, you need to run the following commands on the HubPE:
Run the ip route-static vpn-instance vpn-instance-name 0.0.0.0 0.0.0.0 nexthopaddress [ tag tag ] [ description text ] command in the system view.
In this example, vpn-instance-name specifies VPN-out and nexthop-address specifies
the IP address of the Hub-CE interface that is connected with the PE interface bound to
VPN-out.
Run the network 0.0.0.0 0 command in the BGP-VPN instance IPv4 address family
view to advertise the default route to all the Spoke-PEs through MP-BGP.
vpn-instance-name here is also VPN-out.
----End
Issue 01 (2011-10-15)
65
Prerequisite
All configurations of Hub and Spoke are complete.
Procedure
l
Run the display ip routing-table command on the Hub-CE and all the Spoke-CEs to check
routing information.
----End
Example
After the configuration, run the display ip routing-table vpn-instance vpn-instance-name
command, and you can find that the routing table of VPN-in has routes to all the Spoke sites and
the routing table of VPN-out has routes to the Hub site and all the Spoke sites.
Additionally, the Hub-CE and all the Spoke-CEs have routes to the Hub site and all the Spoke
sites.
Applicable Environment
By default, the system selects a tunnel in the order of LSPs, CR-LSPs, and Local_IfNet for VPN
services, and does not perform load balancing. To configure load balancing or select tunnels of
other types, configure a tunnel policy and apply it to the VPN.
At present, the NE5000E supports the following modes of tunnel policies:
l
Tunnel binding: A TE tunnel is bound to a specified destination IP address. This allows the
VPN traffic destined for that destination address to be transmitted over the TE tunnel.
For details on tunnel policy configurations, see VPN Tunnel Management Configuration.
Pre-configuration Tasks
Before configuring a tunnel policy for the backbone network of a BGP/MPLS IP VPN, complete
the following tasks:
l
Issue 01 (2011-10-15)
66
Configuration Procedures
Figure 2-10 Flowchart for configuring a tunnel policy for the backbone network of a BGP/
MPLS IP VPN
Configure a tunnel policy
Related Tasks
2.18.9 Example for Configuring Load Balancing Among Tunnels to Which Remote Cross
Routes Are Iterated on a VPN
Context
In the tunnel policy view, the select-sequence mode and tunnel binding mode are mutually
exclusive. Choose one of the following configurations as needed:
Procedure
l
Run:
system-view
Run:
tunnel-policy policy-name
Run:
tunnel select-seq { lsp | cr-lsp }* load-balance-number load-balance-number
The priority sequence of tunnel types and number of tunnels participating in load
balancing are configured.
A tunnel policy in select-sequence mode defines that tunnels to the same destination
are selected in sequence. If a tunnel listed earlier is Up, it is selected regardless of
Issue 01 (2011-10-15)
67
whether other services have selected it. The tunnels listed later are not selected except
in case of even load balancing or when the preceding tunnels are Down.
4.
Run:
commit
Run:
system-view
Run:
tunnel-policy policy-name
Run:
tunnel binding destination dest-ip-address te { tunnel interface-number }
&<1-6> [ down-switch ]
Run:
commit
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
68
Prerequisite
The configurations of a tunnel policy for the backbone network of a BGP/MPLS IP VPN are
complete.
Procedure
l
----End
Example
Run the display tunnel-policy command. If the configuration of a tunnel policy is displayed, it
means that the configuration succeeds. For example:
<HUAWEI> display tunnel-policy policy1
Tunnel Policy Name
Select-Seq
Load balance No
-----------------------------------------------------policy1
CR-LSP LSP
2
Run the display ip vpn-instance verbose command, and you can view the tunnel policy used
by a VPN instance. In the following command output, the tunnel policy used by the IPv4 address
family of a VPN instance named vpna is policy1.
<HUAWEI> display ip vpn-instance verbose
Total VPN-Instances configured : 1
VPN-Instance Name and ID : vpn1, 1
Interfaces : GigabitEthernet1/0/0
Address family ipv4
Create date : 2006/09/27 15:25:29
Up time : 0 days, 00 hours, 02 minutes and 11 seconds
Route Distinguisher : 100:1
Export VPN Targets : 2:2
Import VPN Targets : 1:1
Label policy : label per route
Tunnel Policy : policy1
Issue 01 (2011-10-15)
69
Applicable Environment
Inter-AS VPN Option A is a typical application of BGP/MPLS IP VPN in an inter-AS scenario.
You need not perform special configurations. In inter-AS VPN Option A, either of the ASBRs
takes the peer ASBR as its CE and advertises IPv4 routes to the peer ASBR through EBGP.
As shown in Figure 2-11, for ASBR 1 in AS 100, ASBR 2 in AS 200 is a CE. Similarly, for
ASBR2, ASBR 1 is a CE.
Figure 2-11 Networking diagram of Inter-AS VPN Option A
VPN1
CE1
VPN1
CE3
BGP/MPLS backbone
AS: 100
PE1
BGP/MPLS backbone
AS: 200
PE3
ASBR1
CE
MP-IBGP
EBGP
MP-IBGP
ASBR2
PE2
PE4
VPN LSP1
CE2
VPN2
IP forwarding
LSP1
CE4
VPN2
Inter-AS VPN Option A is applicable in the scenario where the number of VPNs that a PE
accesses and the number of VPN routes are small. In Inter-AS VPN Option A, ASBRs must
support VPN instances and must be capable of managing VPN routes. In addition, ASBRs must
reserve dedicated interfaces, for example, sub-interfaces, physical interfaces, and bound logical
interfaces, for each inter-AS VPN network. Inter-AS VPN Option A requires high performance
of ASBRs and you need not perform any special configurations on the ASBRs.
Pre-configuration Tasks
Before configuring inter-AS VPN Option A, complete the following tasks:
l
Configuring an IGP for the MPLS backbone network of each AS to ensure IP connectivity
of the backbone network within an AS
Configuring the basic MPLS functions and MPLS LDP on the PE and ASBR
Establishing a tunnel (LSP or MPLS TE tunnel) between the PE and ASBR in the same
AS
Procedure
Step 1 Take the ASBR as a PE and perform 2.4 Configuring Basic BGP/MPLS IP VPN for each AS.
Issue 01 (2011-10-15)
70
NOTE
In inter-AS VPN Option A mode, ensure that the VPN targets of the VPN instances on the ASBR match
those of the VPN instances on the PE in the same AS.? The VPN targets of the VPN instances on the PEs
in different ASs do not need to match each other.
Step 2 On the ASBR, bind the interface connected with the remote ASBR to a VPN instance. For
detailed configuration procedures, see 2.4.2 Binding an Interface to a VPN Instance.
Step 3 Configure the routing protocol run between ASBRs. For detailed configuration procedures, see
2.4.5 Configuring Route Exchange Between a PE and a CE.
----End
Run the display bgp vpnv4 all peer command on the PE or ASBR, and you can view that
the status of the BGP VPNv4 peer relationship between the PE and ASBR in the same AS
is "Established".
Run the display bgp vpnv4 all routing-table command on the PE or ASBR, and you can
view the VPNv4 routes.
Run the display ip routing-table vpn-instance command on the PE or ASBR, and you
can view that the VPN routing table of the PE or ASBR has related VPN routes.
Run the display bgp vpnv4 all routing-table command on the ASBR, and you can view the
VPNv4 routes on the ASBR.
<HUAWEI> display bgp vpnv4 all routing-table
BGP Local router ID is 2.2.2.9
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 2
Route Distinguisher: 100:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 10.1.1.0/24
1.1.1.9
0
100
0
?
*>i 10.1.1.1/32
1.1.1.9
0
100
0
?
VPN-Instance vpn1, router ID 2.2.2.9:
Total Number of Routes:
Network
*>i 10.1.1.0/24
*>i 10.1.1.1/32
*>
10.2.1.0/24
*>
10.2.1.1/32
*>
192.1.1.0
*
*>
192.1.1.1/32
*
*>
192.1.1.2/32
9
NextHop
1.1.1.9
1.1.1.9
192.1.1.2
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
MED
0
0
LocPrf
100
100
0
0
0
0
0
PrefVal Path/Ogn
0
?
0
?
0
200?
0
200?
0
?
0
200?
0
?
0
200?
0
?
Related Tasks
2.18.10 Example for Configuring Inter-AS VPN Option A
Issue 01 (2011-10-15)
71
Applicable Environment
If an ASBR can manage VPN routes but there are not enough interfaces for all inter-AS VPNs,
inter-AS VPN Option B can be used. Inter-AS VPN Option B requires ASBRs to help to maintain
and advertise VPNv4 routes and you need not create VPN instances on the ASBRs. In the basic
networking of inter-AS VPN Option B, an ASBR cannot play other roles, such as the PE or RR,
and an RR is not required in each AS.
On the network shown in Figure 2-12, the interfaces connected between ASBRs do not need to
be bound to the VPN. A single-hop MP-EBGP peer relationship is set up between the ASBRs
to transmit all inter-AS VPN routing information.
Figure 2-12 Schematic diagram for Inter-AS VPN Option B (basic networking)
VPN1
CE1
VPN1
CE3
IP/MPLS Backbone
AS: 100
PE1
ASBR1
IP/MPLS Backbone
AS: 200
PE3
ASBR2
MP-IBGP
MP-EBGP
PE2
MP-IBGP
PE4
CE4
VPN2
CE2
VPN2
Pre-configuration Tasks
Before configuring inter-AS VPN Option B, complete the following tasks:
l
Configuring an IGP for the MPLS backbone network of each AS to ensure IP connectivity
of the backbone network within an AS
Configuring the basic MPLS functions for the MPLS backbone network of each AS and
establishing an LDP LSP or TE tunnel between MP-IBGP peers
2.3 Configuring a VPN Instance Enabled with the IPv4 Address Family on the PE
connected to the CE and 2.4.2 Binding an Interface to a VPN Instance
Issue 01 (2011-10-15)
72
Configuration Procedures
Figure 2-13 Flowchart for configuring inter-AS VPN Option B (basic networking)
Configuring MP-IBGP Between
a PE and an ASBR in the Same AS
Configuring MP-EBGP
Between ASBRs in Different ASs
Related Tasks
2.18.11 Example for Configuring Inter-AS VPN Option B with Basic Networking
Procedure
Step 1 Run:
system-view
The IBGP peer relationship is set up between the PE and ASBR in the same AS.
Step 4 Run:
peer peer-address connect-interface loopback interface-number
The loopback interface is specified as the outbound interface of the BGP session.
Issue 01 (2011-10-15)
73
Step 5 Run:
ipv4-family vpnv4 [ unicast ]
The capability of VPNv4 route exchange between the PE and the ASBR is enabled.
Step 7 Run:
commit
Context
In inter-AS VPN Option B (basic networking), you need not create VPN instances on ASBRs.
The ASBR does not filter the VPNv4 routes received from the PE in the same AS based on VPN
targets. Instead, it advertises the received routes to the peer ASBR through MP-EBGP.
Procedure
Step 1 Run:
system-view
The view of the interface that connects to the peer ASBR is displayed.
Step 3 Run:
ip address ip-address { mask | mask-length }
74
Step 7 Run:
bgp as-number
The capability of exchanging VPNv4 routes with the peer ASBR is enabled.
Step 11 Run:
commit
Context
By default, an ASBR filters the VPN targets of only the received VPNv4 routes. The routes are
imported into the routing table if they pass the filtration; otherwise, they are discarded. Therefore,
if no VPN instance is configured on the ASBR or no VPN target is configured for the VPN
instance, the ASBR discards all the received VPNv4 routes.
You can configure an ASBR to control the importing and exporting of VPN routes through
multiple methods. The two methods are described as follows:
l
Not to filter VPN targets, that is, the ASBR stores all the VPNv4 routes
To filter VPN targets, that is, the ASBR stores partial VPNv4 routes through routing policies
Configure either of the following methods on each ASBR based on the actual situation:
Procedure
l
Run:
system-view
Run:
bgp as-number
Issue 01 (2011-10-15)
75
Run:
ipv4-family vpnv4 [ unicast ]
Run:
undo policy vpn-target
Run:
commit
Run:
system-view
Run:
ip extcommunity-filter extcom-filter-number { deny | permit } rt vpntarget &<1-16>
Run:
route-policy route-policy-name permit node node
Run:
if-match extcommunity-filter extcomm-filter-number &<1-16>
Run:
commit
Run:
quit
Run:
bgp as-number
Run:
ipv4-family vpnv4 [ unicast ]
76
9.
Run:
peer peer-address route-policy policy-name { export | import }
The routing policy is applied to controlling the importing and exporting of VPNv4
routes.
10. Run:
commit
Procedure
Step 1 You can configure a routing protocol between a CE and a PE based on the actual situation. For
detailed configuration procedures, see 2.4.5 Configuring Route Exchange Between a PE and
a CE.
----End
Prerequisite
All the configurations about inter-AS VPN Option B are complete.
Procedure
l
Run the display bgp vpnv4 all peer command on the PE or ASBR to check the status of
all BGP peer relationships.
Run the display bgp vpnv4 all routing-table command on the PE or ASBR to check
information about VPNv4 routes.
----End
Example
Run the display bgp vpnv4 all peer command on the PE or ASBR, and you can view that the
status of the BGP VPNv4 peer relationship between the PE and ASBR in the same AS is
"Established". In addition, the status of the EBGP peer relationship between the directly
connected ASBRs in different ASs is also "Established".
Run the display bgp vpnv4 all routing-table command on the ASBR, and you can view the
VPNv4 routes on the ASBR.
<HUAWEI> display bgp vpnv4 all routing-table
Issue 01 (2011-10-15)
77
Run the display ip routing-table vpn-instance command on the PE, and you can view that the
VPN routing table contains related VPN routes.
<HUAWEI> display ip routing-table vpn-instance vpna
Route Flags: R - relied, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: vpna
Destinations : 3
Routes : 3
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24
Direct 0
0
D
10.1.1.2
GigabitEthernet1/0/0
10.1.1.2/32
Direct 0
0
D
127.0.0.1
InLoopBack0
10.3.1.0/24
BGP
255 0
RD
3.3.3.9
Pos3/0/0
Applicable Environment
If an ASBR can manage VPN routes but there are not enough interfaces for all inter-AS VPNs,
and the ASBR also functions as a PE for CE access, you can configure inter-AS VPN Option B
(ASBR also functioning as a PE). This mode requires ASBRs to help to maintain and advertise
not only the VPNv4 routes of its own VPN instances but also the VPNv4 routes of other VPN
instances.
Pre-configuration Tasks
Before configuring inter-AS VPN Option B (ASBR also functioning as a PE), complete the
following tasks:
l
Configuring an IGP for the MPLS backbone network of each AS to ensure IP connectivity
of the backbone network within an AS
Configuring basic MPLS capabilities for the MPLS backbone network of each AS and
establishing an LDP LSP or TE tunnel between MP-IBGP peers
2.3 Configuring a VPN Instance Enabled with the IPv4 Address Family on the PE
connected to the CE and 2.4.2 Binding an Interface to a VPN Instance
Issue 01 (2011-10-15)
78
Configuration Procedures
Figure 2-14 Flowchart for configuring inter-AS VPN Option B (ASBR functioning as a PE)
Configure MP-IBGP between
a PE and an ASBR in the same AS
Related Tasks
2.18.15 Example for Configuring Inter-AS VPN Option B with ASBRs Functioning as PEs
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
79
The IBGP peer relationship is set up between the PE and ASBR in the same AS.
Step 4 Run:
peer peer-address connect-interface loopback interface-number
The loopback interface is specified as the outbound interface of the BGP session.
Step 5 Run:
ipv4-family vpnv4 [ unicast ]
The capability of VPNv4 route exchange between the PE and the ASBR is enabled.
Step 7 Run:
commit
Context
In inter-AS VPN Option B (basic networking), you need not create VPN instances on ASBRs.
The ASBR does not filter the VPNv4 routes received from the PE in the same AS based on VPN
targets. Instead, it advertises the received routes to the peer ASBR through MP-EBGP.
Procedure
Step 1 Run:
system-view
The view of the interface that connects to the peer ASBR is displayed.
Step 3 Run:
ip address ip-address { mask | mask-length }
Issue 01 (2011-10-15)
80
The capability of exchanging VPNv4 routes with the peer ASBR is enabled.
Step 11 Run:
commit
Context
For configuration details, see 2.9.3 Controlling the Learning and Advertising of VPN Routes
on ASBR.
Procedure
Step 1 Run:
system-view
81
ip vpn-instance vpn-instance-name
The IPv4 address family is enabled for the VPN instance and the VPN instance IPv4 address
family view is displayed.
Step 4 Run:
route-distinguisher route-distinguisher
A VPN target is configured for the VPN instance IPv4 address family.
Step 6 (Optional) Run:
prefix limit number { alert-percent | simply-alert }
The maximum number of prefixes of the VPN instance IPv4 address family is set.
Step 7 (Optional) Run:
import route-policy policy-name
Procedure
Step 1 Configure a routing protocol between a CE and an ASBR based on the actual situation. For
detailed configuration procedures, see 2.4.5 Configuring Route Exchange Between a PE and
a CE.
----End
82
Procedure
Step 1 Configure a routing protocol between a CE and a PE based on the actual situation. For detailed
configuration procedures, see 2.4.5 Configuring Route Exchange Between a PE and a CE.
----End
Prerequisite
All the configurations about inter-AS VPN Option B (ASBR also functioning as a PE) are
complete.
Procedure
l
Run the display bgp vpnv4 all peer command on the PE or ASBR to check the status of
all BGP peer relationships.
Run the display bgp vpnv4 all routing-table command on the PE or ASBR to check
information about VPNv4 routes.
Run the display mpls lsp command to view the LSP and label information on the ASBR.
----End
Example
Run the display bgp vpnv4 all routing-table command on the ASBR, and you can view the
VPNv4 routes on the ASBR.
Run the display bgp vpnv4 all peer command on the PE or ASBR, and you can view that the
status of the BGP VPNv4 peer relationship between the PE and ASBR in the same AS is
"Established". In addition, the status of the EBGP peer relationship between the directly
connected ASBRs in different ASs is also "Established".
Run the display ip routing-table vpn-instance command on the PE or ASBR, and you can view
that the VPN routing table has related VPN routes.
Run the display mpls lsp command, and you can view the LSP and label information on the
ASBR.
83
Applicable Environment
In inter-AS VPN Option B, if multiple PEs exist in an AS, you can configure an ASBR as an
RR to reduce the number of MP-IBGP connections needed between PEs. Configuring an ASBR
as an RR will burden the ASBR. Therefore, it is required that a high-performance device be used
as the ASBR. As shown in Figure 2-15, ASBR1 is configured as an RR so that PE1 and PE2
need not set up an MP-IBGP peer relationship.
Figure 2-15 Networking diagram of inter-AS VPN Option B (ASBR also functioning as an RR)
CE1
PE1
AS100
AS200
ASBR2
CE2
PE3
CE3
PE2
ASBR1
(RR)
Pre-configuration Tasks
Before configuring inter-AS VPN Option B (ASBR also functioning as an RR), complete the
following tasks:
l
Configuring an IGP for the MPLS backbone network of each AS to ensure IP connectivity
of the backbone network within an AS
Configuring the basic MPLS functions for the MPLS backbone network of each AS and
establishing an LDP LSP or TE tunnel between MP-IBGP peers
2.3 Configuring a VPN Instance Enabled with the IPv4 Address Family on the PE
connected to the CE and 2.4.2 Binding an Interface to a VPN Instance
Issue 01 (2011-10-15)
84
Configuration Procedures
Figure 2-16 Flowchart for configuring inter-AS VPN Option B (ASBR also functioning as an
RR)
Configure MP-IBGP between a PE
and an ASBR in the same AS
Configure MP-EBGP
between ASBRs in different ASs
Related Tasks
2.18.16 Example for Configuring Inter-AS VPN Option B with an ASBR Functioning as an RR
Procedure
l
Configuring the ASBR (RR) to establish an MP-IBGP peer relationship with each of its
client PEs
Perform Steps 1 to 6 repeatedly on the ASBR and the PEs to establish MP-IBGP peer
relationships with all client PEs.
1.
Run:
system-view
Run:
bgp as-number
Run:
peer peer-ipv4-address as-number as-number
85
4.
Run:
peer peer-ipv4-address connect-interface interface-type interface-number
The interface used to establish a TCP connection is specified. The IP address of the
interface must be the same as the MPLS LSR ID. It is recommended to specify a
loopback interface to establish the TCP connection.
5.
Run:
ipv4-family vpnv4
Run:
peer peer-ipv4-address enable
The capability of exchanging VPNv4 routes between the ASBR and the client PE is
enabled.
7.
Run:
commit
Procedure
Step 1 Run:
system-view
The view of the interface that connects to the peer ASBR is displayed.
Step 3 Run:
ip address ip-address { mask | mask-length }
86
Step 7 Run:
bgp as-number
The capability of exchanging VPNv4 routes with the peer ASBR is enabled.
Step 11 Run:
commit
Context
For configuration details, see 2.9.3 Controlling the Learning and Advertising of VPN Routes
on ASBR.
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
87
Route reflection between clients is disabled. You need to run this command if the clients are
fully connected.
Step 6 Run:
undo policy vpn-target
Prerequisite
All the configurations about inter-AS VPN Option B (ASBR also functioning as an RR) are
complete.
Procedure
l
Run the display bgp vpnv4 all peer command on the PE or ASBR to check the status of
all BGP peer relationships.
Run the display bgp vpnv4 all routing-table command on the PE or ASBR to check
information about VPNv4 routes.
Run the display mpls lsp command to view the LSP and label information on the ASBR.
----End
Example
Run the display bgp vpnv4 all routing-table command on the ASBR, and you can view the
VPNv4 routes on the ASBR.
Issue 01 (2011-10-15)
88
Run the display bgp vpnv4 all peer command on the PE or ASBR, and you can view that the
status of the BGP VPNv4 peer relationship between the PE and ASBR in the same AS is
"Established". In addition, the status of the EBGP peer relationship between the directly
connected ASBRs in different ASs is also "Established".
Run the display ip routing-table vpn-instance command on the PE, and you can view that the
VPN routes in the VPN routing table.
Run the display mpls lsp command, and you can view the LSP and label information on the
ASBR.
Applicable Environment
If the L3VPN needs to span more than two ASs, you can configure inter-AS VPN Option B
(spanning more than two ASs). As shown in Figure 2-17, the L3VPN needs to span three ASs
to transmit VPN routes.
Figure 2-17 Networking diagram of inter-AS VPN Option B (spanning more than two ASs)
AS200
ASBR4
AS100
ASBR3
ASBR1
PE1
CE1
AS300
PE2
ASBR2
CE2
Pre-configuration Tasks
Before configuring inter-AS VPN Option B (spanning more than two ASs), complete the
following tasks:
l
Configuring an IGP for the MPLS backbone network of each AS to ensure IP connectivity
of the backbone network within an AS
Configuring the basic MPLS functions for the MPLS backbone network of each AS and
establishing an LDP LSP or TE tunnel between MP-IBGP peers
Issue 01 (2011-10-15)
89
2.3 Configuring a VPN Instance Enabled with the IPv4 Address Family on the PE
connected to the CE and 2.4.2 Binding an Interface to a VPN Instance
Configuration Procedures
Figure 2-18 Flowchart for configuring inter-AS VPN Option B (spanning more than two ASs)
Configure MP-IBGP between a PE
and an ASBR in the same AS
Configure MP-EBGP
between ASBRs in different ASs
Configure MP-IBGP
between ASBRs in the same AS
Related Tasks
2.18.17 Example for Configuring Inter-AS VPN Option B with the VPN Spanning Multiple ASs
Procedure
Step 1 Run:
system-view
The IBGP peer relationship is established between the PE and ASBR in the same AS.
Issue 01 (2011-10-15)
90
Step 4 Run:
peer peer-address connect-interface loopback interface-number
The loopback interface is specified as the outbound interface of the BGP session.
Step 5 Run:
ipv4-family vpnv4 [ unicast ]
The capability of VPNv4 route exchange between the PE and the ASBR is enabled.
Step 7 Run:
commit
Procedure
Step 1 Run:
system-view
The view of the interface that connects to the peer ASBR is displayed.
Step 3 Run:
ip address ip-address { mask | mask-length }
91
bgp as-number
The capability of exchanging VPNv4 routes with the peer ASBR is enabled.
Step 11 Run:
commit
Procedure
Step 1 Run:
system-view
The IBGP peer relationship is set up between the ASBRs in the same AS.
Step 4 Run:
peer peer-address connect-interface loopback interface-number
The loopback interface is specified as the outbound interface of the BGP session.
Step 5 Run:
ipv4-family vpnv4 [ unicast ]
Issue 01 (2011-10-15)
92
The capability of VPNv4 route exchange between the ASBRs in the same AS is enabled.
Step 7 Run:
commit
Context
For configuration details, see 2.9.3 Controlling the Learning and Advertising of VPN Routes
on ASBR.
Prerequisite
All the configurations of inter-AS VPN Option B are complete.
Procedure
l
Run the display bgp vpnv4 all peer command on the PE or ASBR to check the status of
all BGP peer relationships.
Run the display bgp vpnv4 all routing-table command on the PE or ASBR to check
information about VPNv4 routes.
Run the display mpls lsp command to view the LSP and label information on the ASBR.
----End
Example
Run the display bgp vpnv4 all routing-table command on the ASBR, and you can view the
VPNv4 routes on the ASBR.
Run the display bgp vpnv4 all peer command on the PE or ASBR, and you can view that the
status of the BGP VPNv4 peer relationship between the PE and ASBR in the same AS is
"Established". In addition, the status of the EBGP peer relationship between the directly
connected ASBRs in different ASs is also "Established".
Run the display ip routing-table vpn-instance command on the PE, and you can view the VPN
routes in the VPN routing table.
Issue 01 (2011-10-15)
93
Run the display mpls lsp command, and you can view the LSP and label information on the
ASBR.
Applicable Environment
In a LAN, if you want to use the CE rather than the VLAN function on the switch to isolate VPN
services, you can configure the multi-VPN-instance CE.
As shown in Figure 2-19, the R&D department and sales department of company X in city A
are in the same LAN and access the VPN backbone network through the same CE. To enable
the R&D department and sales department in city A to communicate with each other, and enable
the R&D department in city A and the R&D department in city C to communicate with each
other but completely isolate the R&D departments from sales departments, you can configure
OSPF multi-instance on both the CE in city A and the PE connecting the CE to the backbone
network. Similar to the OSPF multi-instance on a PE, each OSPF instance on a CE serves as a
virtual CE for each type of service. Multi-VPN-instance implements service isolation with a low
cost and ensures the security of each type of service.
Figure 2-19 Schematic diagram of multi-VPN-instance CE
X company's
R&D department
in city C
CE
R&D department
PE
VPN
backbone
network
OSPF2 VPN2
X company's LAN
in city A
CE
OSPF1 VPN1
PE
PE
CE
Sales department
X company's
sales department
in city B
Pre-configuration Tasks
Before configuring the multi-VPN-instance CE, complete the following tasks:
l
Issue 01 (2011-10-15)
2.3 Configuring a VPN Instance Enabled with the IPv4 Address Family on the multiinstance CE and the PE that the CE accesses (a VPN instance for each service)
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
94
Configuring the link layer protocol and network layer protocol for LAN interfaces and
connecting the LAN with the multi-instance CE (each service using an interface to access
the multi-instance CE)
Binding related VPN instances to the interfaces of the multi-instance CE and PE interfaces
through which the PE accesses the multi-instance and configuring IP addresses for those
interfaces
Configuration Procedures
Figure 2-20 Flowchart for configuring multi-VPN-instance CE
Configure OSPF
Multi-Instance on the PE
Configure the OSPF Multi-Instance on
the Multi-Instance CE
Disable route loop detection
on the Multi-VPN-Instance CE
Mandatory
procedure
Optional
procedure
Related Tasks
2.18.18 Example for Configuring a Multi-VPN-Instance CE
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
95
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
96
The OSPF process ID must be the same as that configured on the PE.
Step 3 Run:
area area-id
If the multi-instance CE does not learn the routes of the LAN through the OSPF multi-instance of the local
process, you also need to run related commands to import the routes of the LAN into the OSPF multiinstance of the local process.
Step 5 Run:
commit
Context
The multi-VPN-instance CE is a scheme for implementing service isolation by isolating routes.
Special configurations are not required but you need to disable route loop detection.
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
97
Prerequisite
All configurations about the multi-VPN-instance CE are complete.
Procedure
l
----End
Example
After the configuration, run the display ip routing-table vpn-instance command on the multiinstance CE, and you can find that the VPN routing table of the CE contains the routes to the
LAN and remote sites for each service.
Applicable Environment
VPN FRR is applicable to services that are very sensitive to packet loss and delay on VPNs. As
shown in Figure 2-21, CE1 is dual-homed to PE2 and PE3. When the link between PE1 and
PE2 fails, VPN traffic need be fast switched to the link between PE1 and PE3.
Figure 2-21 Schematic diagram of VPN FRR
PE2
PE1
MPLS Backbone
AS100
VPN site
AS65400
CE1
PE3
Issue 01 (2011-10-15)
98
Pre-configuration Tasks
Before configuring VPN FRR, complete the following tasks:
l
Procedure
Step 1 Run:
system-view
Example
All VPN FRR configurations are complete, run the display ip routing-table vpn-instance vpninstance-name [ ip-address ] verbose command to check information about the backup nexthop PE, backup tunnel, and backup label.
<HUAWEI> display ip routing-table vpn-instance vpn1 10.1.1.0 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpn1
Summary Count : 1
Destination: 10.3.1.0/24
Protocol: BGP
Process ID: 0
Preference: 255
Cost: 0
NextHop: 2.2.2.2
Neighbour: 2.2.2.2
State: Active Adv GotQ
Age: 00h15m06s
Tag: 0
Priority: low
Label: 15361
QoSInfo: 0x0
IndirectID: 0x13
RelayNextHop: 0.0.0.0
Interface: Pos2/0/0
TunnelID: 0x000000000100000001 Flags: RD
BkNextHop: 3.3.3.3
BkInterface: Unknown
BkLabel: 15362
SecTunnelID: 0x0
BkPETunnelID: 0x000000000100000002 BkPESecTunnelID: 0x0
Issue 01 (2011-10-15)
99
BkIndirectID: 0x15
Related Tasks
2.18.19 Example for Configuring VPN FRR with FRR Switchover Being Implemented on a PE
Applicable Environment
This feature is suitable for IP services that are sensitive to the packet loss and delay on a private
network. With IP FRR configured on the private network, if the route from a PE to a CE is
unavailable, traffic from the PE can be quickly switched to a link connected to another CE. This
reduces the time of IP service interruption.
On the network shown in Figure 2-22, in normal situations, the PE selects Link_A to forward
traffic to vpn1 site and uses Link_B as the backup link. If the PE detects that the route to CE1
is unreachable, it will immediately switch traffic to Link_B and private network routes will be
converged. This can minimize the impact on VPN services.
Figure 2-22 FRR for IP routes on a priviate network
CE1
IP/MPLS
Backbone
PE
vpn1
site
Link_A
RouterA
Link_B
CE2
At present, the NE5000E supports two modes of FRR for IP routes on a private network. The
two modes are different in networking and configuration procedures.
l
IP FRR: applicable to the networking where different PE-CE pairs use different routing
protocols.
BGP Auto FRR for the private network: applicable to the networking where BGP runs
between the PE and CEs.
Pre-configuration Tasks
Before configuring FRR for IP routes on a private network, complete the following tasks:
l
Configuring the PE to learn private network routes with the same prefix from different CEs
attached to it
Issue 01 (2011-10-15)
100
Procedure
l
Configure IP FRR.
1.
Run:
system-view
Run:
ip vpn-instance vpn-instance-name
Run:
ipv4-family
Run:
ip frr
IP FRR is enabled.
5.
Run:
commit
Run:
system-view
Run:
bgp as-number
Run:
ipv4-family vpn-instance vpn-instance-name
Run:
auto-frr
Run:
commit
Example
Run the display ip routing-table vpn-instance vpn-instance-name [ ipv4-address ] verbose
command to check the backup outbound interface and backup next hop of the IP route in the
routing table.
Run the display ip routing-table vpn-instance vpn-instance-name verbose command on the
PE. You can see that the route has a backup outbound interface and a backup next hop.
Issue 01 (2011-10-15)
101
Related Tasks
2.18.20 Example for Configuring FRR for IP Routes on a Private Network
Applicable Environment
Hybrid FRR for IP and VPNv4 routes can quickly switch traffic from a PE to another PE that
serves as the backup next hop if the primary route to a CE is unreachable.
A PE learns VPN routes with the same prefix from a CE and other PEs. In this situation, hybrid
FRR for IP and VPNv4 routes can be configured on the PE. Enabled with hybrid FRR, the PE
generates a primary route and a backup route to the VPN prefix. If the link between the PE and
CE fails, the link traffic can be quickly switched to the backup next hop (a PE).
On the network shown in Figure 2-23, in normal situations, PE1 selects Link_A to forward
traffic to the CE and uses Link_B as the backup link. If PE2 detects that the route to the CE is
unreachable, it will immediately switch traffic to Link_B and private network routes will be
converged. This can minimize the impact on VPN services.
Issue 01 (2011-10-15)
102
PE2
Link_A
PE1
vpn1
site
Link_B
CE
IP/MPLS
Backbone
PE3
At present, the NE5000E supports two modes of hybrid FRR for IP and VPNv4 routes, which
differ in terms of networking and configuration procedures.
l
IP FRR: It is applicable to the networking where a non-BGP routing protocol runs between
the PEs and CE.
BGP Auto FRR for the private network: It is applicable to the networking where BGP runs
between the PEs and CE.
Pre-configuration Tasks
Before configuring hybrid FRR for IP and VPNv4 routes, complete the following tasks:
l
Configuring a PE to learn IP routes with the same prefix from a CE and other VPNv4 peers
Configure IP FRR.
Procedure
1.
Run:
system-view
Run:
ip vpn-instance vpn-instance-name
Run:
ipv4-family
Run:
ip frr
IP FRR is enabled.
5.
Run:
commit
103
1.
Run:
system-view
Run:
bgp as-number
Run:
ipv4-family vpn-instance vpn-instance-name
Run:
auto-frr
Run:
commit
Example
Run the display ip routing-table vpn-instance vpn-instance-name [ ipv4-address ] verbose
command to check the backup outbound interface and backup next hop of the IP route in the
routing table.
Run the display ip routing-table vpn-instance vpn-instance-name verbose command on the
PE. You can find that the route has a backup outbound interface and a backup next hop, and the
hop is on a tunnel such as an LDP LSP.
<HUAWEI> display ip routing-table vpn-instance vpna 22.22.22.22 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpna
Summary Count : 1
Destination: 22.22.22.22/32
Protocol: BGP
Process ID:
Preference: 255
Cost:
NextHop: 192.168.2.2
Neighbour:
State: Active Adv Relied
Age:
Tag: 0
Priority:
Label: NULL
QoSInfo:
IndirectID: 0xa9
RelayNextHop: 192.168.2.2
Interface:
TunnelID: 0x0
Flags:
BkNextHop: 0.0.0.0
BkInterface:
BkLabel: 0x27
SecTunnelID:
BkPETunnelID: 0x0
BkPESecTunnelID:
BkIndirectID: 0xaa
0
0
0.0.0.0
00h00m31s
low
0x0
GigabitEthernet2/0/0
RD
LDP LSP
0x5000098
0x0
Related Tasks
2.18.21 Example for Configuring Hybrid FRR for IP and VPNv4 Routes
Issue 01 (2011-10-15)
104
Context
In routine maintenance, you can run any of the following commands in any view to check the
running status of BGP/MPLS IP VPN.
Procedure
l
Run the display mpls lsp command to check information about LSPs.
Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher | vpninstance vpn-instance-name } routing-table destination-address [ mask | mask-length ]
command to check information about a specific BGP VPNv4 routing entry.
Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher | vpninstance vpn-instance-name } routing-table statistics [ match-options ] command to
check statistics of the BGP VPNv4 routing table.
Run the display bgp vpnv4 { all | route-distinguisher route-distinguisher | vpninstance vpn-instance-name } routing-table [ match-options ] command to check
information about the BGP VPNv4 routing table.
Run the display bgp vpnv4 { all | vpn-instance vpn-instance-name } group [ groupname ] command to check information about the BGP VPNv4 peer groups.
Run the display bgp { all | vpn-instance vpn-instance-name } network command to check
information about the VPNv4 routes imported into the BGP routing table through the
network command.
Run the display bgp { all | vpn-instance vpn-instance-name } paths [ as-regularexpression ] command to check information about the AS path of the BGP VPNv4 route.
Run the display bgp vpn-instance vpn-instance-name peer { group-name | peeraddress } log-info command to check the logs about the BGP peer of the VPN instance
IPv4 address family.
----End
Issue 01 (2011-10-15)
105
Procedure
l
Run the ping [ ip ] [ -a source-ip-address | -c count | -d | -f | -h ttl-value | -i interfacetype interface-number | -m time | -n | -p pattern | -q | -r | -s packetsize | -t timeout | -tos tosvalue | -v | -vpn-instance vpn-instance-name ] * dest-address command to detect the
reachability of the destination.
Run the ping lsp [ -a source-ip | -c count | -exp exp-value | -h ttl-value | -m interval | -r
reply-mode | -s packet-size | -t time-out | -v ] * vpn-instance vpn-name remote remoteaddress mask-length command, and you can check connectivity of the Layer 3 VPN LSP.
----End
Example
After the VPN configuration
l
You can run the ping command on the local CE to check whether the local CE and the
remote CE in the same VPN can communicate with each other. If the ping fails, you can
run the tracert command to locate the faulty node.
You can also run the ping command with the -vpn-instance vpn-instance-name parameter
on the PE to check whether the PE and the CE in the same VPN as the PE can communicate
with each other. If the ping fails, you can run the tracert command with the -vpninstance vpn-instance-nameparameter to locate the faulty node.
If multiple interfaces on the PE are bound to the same VPN, you need to specify the source IP
address, that is, the -a source-ip-address when you ping or tracert the remote CE that accesses
the peer PE. If no source IP address is specified, the PE selects the a lowest IP address from the
IP addresses of the interfaces on the PE bound to this VPN as the source address of the ICMP
messages. If the CE has no route to the selected IPv4 route, the CE discards the returned ICMP
message.
NOTE
By default, as for the MPLS TTL timeout packet with a single label, the router returns the ICMP message
according to the local IP route (that is, the public network route). However, no VPN route exists in the
public network routing table of the ASBR and therefore, the ICMP message is discarded when being sent
to or returned by the ASBR.
Issue 01 (2011-10-15)
106
Context
CAUTION
BGP statistics of the VPN instance IPv4 address family cannot be restored after being cleared.
Therefore, perform the action with caution.
Procedure
l
After confirming that you need to clear the statistics about BGP peer flap in the specified
VPN instance IPv4 address family, run the reset bgp vpn-instance vpn-instance-name
ipv4-family [ peer-address ]flap-info command in the user view.
After confirming that you need to clear the statistics about route dampening information
of the specified VPN instance IPv4 address family, run the reset bgp vpn-instance vpninstance-name ipv4-family dampening [ ip-address [ mask | mask-length ] ] command in
the user view.
----End
Context
CAUTION
VPN services are interrupted after the BGP connection is reset. So, confirm the action before
you use the command.
After BGP configurations are changed, you can validate the new configurations through soft
reset or reset of the BGP connection. Soft reset requires BGP peers to have the route refresh
capability. This means that BGP peers should support Route-Refresh messages.
Procedure
l
Run the refresh bgp vpnv4 { all | peer-address | group group-name | internal |
external } { import | export } command in the user view to trigger the soft reset of the
BGP VPNv4 connection in the inbound or outbound direction so as to validate the
configuration.
Run thereset bgp vpn-instance vpn-instance-name ipv4-family { as-number | peeraddress | group group-name | all | internal | external } command in the user view to reset
Issue 01 (2011-10-15)
107
BGP connections of the VPN instance IPv4 address family so as to validate the
configuration.
l
Run the reset bgp vpnv4 { as-number | peer-address | group group-name | all | internal
| external } command in the user view to reset the BGP VPNv4 connection so as to validate
the configuration.
----End
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-24:
l
The VPN target of vpna is 111:1; the VPN target of vpnb is 222:2.
It is required that users in the same VPN be able to communicate with each other whereas users
in different VPNs be unable to communicate with each other.
Issue 01 (2011-10-15)
108
Loopback1
11.11.11.11/32
vpna
vpna
CE1
CE3
GE1/0/0
10.1.1.1/24
GE1/0/0
10.1.1.2/24
Loopback1
1.1.1.9/32
GE2/0/0
10.2.1.2/24
AS: 65410
AS: 65430
Loopback1
2.2.2.9/32
PE1
POS2/0/0
PE2
172.2.1.1/24
POS1/0/0
172.1.1.2/24
POS3/0/0
172.1.1.1/24
POS3/0/0
172.2.1.2/24
MPLS backbone
GE1/0/0
10.3.1.1/24
GE1/0/0
10.3.1.2/24
Loopback1
3.3.3.9/32
GE2/0/0
10.4.1.2/24
AS: 100
GE1/0/0
10.2.1.1/24
AS: 65420
AS: 65440
CE2
GE1/0/0
10.4.1.1/24
CE4
vpnb
vpnb
Loopback1
22.22.22.22/32
Loopback1
44.44.44.44/32
Configuration Notes
When configuring BGP/MPLS IP VPN, note the following:
l
On the same VPN, the export VPN target list of a site shares VPN targets with the import
VPN target lists of the other sites; the import VPN target list of a site shares VPN targets
with the export VPN target lists of the other sites.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Enable OSPF on the backbone network to ensure that PEs interwork with each other.
2.
Configure basic MPLS functions and MPLS LDP, and set up MPLS LSPs on the backbone
network.
3.
Configure VPN instances enabled with the IPv4 address family on the PEs and bind each
interface that connects a PE to a CE to a VPN instance.
4.
Enable Multi-protocol Extensions for Interior Border Gateway Protocol (MP IBGP) on PEs
to exchange VPN routing information.
Issue 01 (2011-10-15)
109
5.
Data Preparation
To complete the configuration, you need the following data:
l
Procedure
Step 1 Configure an IGP on the MPLS backbone network to achieve connectivity between the PEs and
P. OSPF is adopted as an IGP in this example.
# Configure PE1.
<HUAWEI> system-view
[~HUAWEI] sysname PE1
[~PE1] interface loopback 1
[~PE1-LoopBack1] ip address 1.1.1.9 32
[~PE1-LoopBack1] commit
[~PE1-LoopBack1] quit
[~PE1] interface pos3/0/0
[~PE1-Pos3/0/0] ip address 172.1.1.1 24
[~PE1-Pos3/0/0] commit
[~PE1-Pos3/0/0] quit
[~PE1] ospf
[~PE1-ospf-1] area 0
[~PE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[~PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[~PE1-ospf-1-area-0.0.0.0] commit
[~PE1-ospf-1-area-0.0.0.0] quit
[~PE1-ospf-1] quit
# Configure the P.
<HUAWEI> system-view
[~HUAWEI] sysname P
[~P] interface loopback 1
[~P-LoopBack1] ip address 2.2.2.9 32
[~P-LoopBack1] commit
[~P-LoopBack1] quit
[~P] interface pos 1/0/0
[~P-Pos1/0/0] ip address 172.1.1.2 24
[~P-Pos1/0/0] commit
[~P-Pos1/0/0] quit
[~P] interface pos 2/0/0
[~P-Pos2/0/0] ip address 172.2.1.1 24
[~P-Pos2/0/0] commit
[~P-Pos2/0/0] quit
[~P] ospf
[~P-ospf-1] area 0
[~P-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[~P-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255
[~P-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0
[~P-ospf-1-area-0.0.0.0] commit
[~P-ospf-1-area-0.0.0.0] quit
[~P-ospf-1] quit
# Configure PE2.
<HUAWEI> system-view
[~HUAWEI] sysname PE2
[~PE2] interface loopback 1
Issue 01 (2011-10-15)
110
After the configuration, OSPF neighbor relationships can be set up between PE1, P, and PE2.
Run the display ospf peer command, and you can view that the neighbor status is Full. Run the
display ip routing-table command, and you can view that the PEs have learnt the routes to
Loopback1 of each other.
Take the display on PE1 as an example.
<PE1> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 8
Routes : 8
Destination/Mask Proto Pre Cost
Flags NextHop
Interface
1.1.1.9/32 Direct 0
0
D 127.0.0.1
InLoopBack0
2.2.2.9/32 OSPF
10
2
D 172.1.1.2
Pos3/0/0
3.3.3.9/32 OSPF
10
3
D 172.1.1.2
Pos3/0/0
172.1.1.0/24 Direct 0
0
D 172.1.1.1
Pos3/0/0
172.1.1.1/32 Direct 0
0
D 127.0.0.1
Pos3/0/0
172.1.1.255/32 Direct 0
0
D 127.0.0.1
Pos3/0/0
172.2.1.0/24 OSPF
10
2
D 172.1.1.2
Pos3/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
<PE1> display ospf peer
OSPF Process 1 with Router ID 1.1.1.9
Neighbors
Area 0.0.0.0 interface 172.1.1.1(Pos3/0/0)'s neighbors
Router ID: 172.1.1.2
Address: 172.1.1.2
State: Full Mode:Nbr is Master Priority: 1
DR: None
BDR: None
MTU: 1500
Dead timer due in 38 sec
Retrans timer interval: 0
Neighbor is up for 00:02:44
Authentication Sequence: [ 0 ]
Step 2 Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the MPLS
backbone network.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.9
[~PE1] mpls
[~PE1-mpls] commit
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] commit
[~PE1-mpls-ldp] quit
[~PE1] interface pos 3/0/0
[~PE1-Pos3/0/0] mpls
[~PE1-Pos3/0/0] mpls ldp
[~PE1-Pos3/0/0] commit
[~PE1-Pos3/0/0] quit
# Configure the P.
Issue 01 (2011-10-15)
111
# Configure PE2.
[~PE2] mpls lsr-id 3.3.3.9
[~PE2] mpls
[~PE2-mpls] commit
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] commit
[~PE2-mpls-ldp] quit
[~PE2] interface pos 3/0/0
[~PE2-Pos3/0/0] mpls
[~PE2-Pos3/0/0] mpls ldp
[~PE2-Pos3/0/0] commit
[~PE2-Pos3/0/0] quit
After the configuration, LDP sessions can be set up between PE1 and the P and between the P
and PE2. Run the display mpls ldp session command, and you can view that the Status field
is Operational. Run the display mpls ldp lsp command, and you can check whether LDP LSPs
are set up.
Take the display on PE1 as an example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
------------------------------------------------------------------------Peer-ID
Status
LAM SsnRole SsnAge
KA-Sent/Rcv
------------------------------------------------------------------------2.2.2.9:0
Operational DU
Passive 006:20:55
39551/39552
------------------------------------------------------------------------TOTAL: 1 session(s) Found.
LAM : Label Advertisement Mode
SsnAge Unit : DDD:HH:MM
<PE1> display mpls ldp lsp
LDP LSP Information
-----------------------------------------------------------------SN DestAddress/Mask
In/OutLabel Next-Hop
In/Out-Interface
-----------------------------------------------------------------1
1.1.1.9/32
3/NULL
127.0.0.1
Pos3/0/0/InLoop0
2
2.2.2.9/32
NULL/3
172.1.1.2
-------/Pos3/0/0
3
3.3.3.9/32
NULL/1024
172.1.1.2
-------/Pos3/0/0
-----------------------------------------------------------------TOTAL: 3 Normal LSP(s) Found.
TOTAL: 0 Liberal LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
Step 3 Configure VPN instances enabled with the IPv4 address family on the PEs and connect the CEs
to the PEs through the VPN instances.
# Configure PE1.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
Issue 01 (2011-10-15)
112
# Configure PE2.
[~PE2] ip vpn-instance vpna
[~PE2-vpn-instance-vpna] ipv4-family
[~PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[~PE2-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE2-vpn-instance-vpna-af-ipv4] quit
[~PE2-vpn-instance-vpna] quit
[~PE2] ip vpn-instance vpnb
[~PE2-vpn-instance-vpnb] ipv4-family
[~PE2-vpn-instance-vpnb-af-ipv4] route-distinguisher 200:2
[~PE2-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[~PE2-vpn-instance-vpnb-af-ipv4] quit
[~PE2-vpn-instance-vpnb] quit
[~PE2] interface gigabitethernet 1/0/0
[~PE2-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[~PE2-GigabitEthernet1/0/0] ip address 10.3.1.2 24
[~PE2-GigabitEthernet1/0/0] commit
[~PE2-GigabitEthernet1/0/0] quit
[~PE2] interface gigabitethernet 2/0/0
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpnb
[~PE2-GigabitEthernet2/0/0] ip address 10.4.1.2 24
[~PE2-GigabitEthernet2/0/0] commit
[~PE2-GigabitEthernet2/0/0] quit
# Assign an IP address to each interface on CEs as shown in Figure 2-24. The detailed
configuration procedure is not mentioned here. For details, see "Configuration Files."
After the configuration, run the display ip vpn-instance verbose command on the PEs to view
the configurations of VPN instances. Each PE can successfully ping its connected CE.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, you need to specify a source IP address
by specifying -a source-ip-address in the ping -vpn-instance vpn-instance-name -a source-ip-address
dest-ip-address command to ping the CE connected to the remote PE. Otherwise, the ping operation fails.
Issue 01 (2011-10-15)
113
Step 4 Set up EBGP peer relationships between the PEs and CEs.
# Configure CE1.
[~CE1] interface loopback 1
[~CE1-LoopBack1] ip address 11.11.11.11 32
[~CE1-LoopBack1] quit
[~CE1] bgp 65410
[~CE1-bgp] peer 10.1.1.2 as-number 100
[~CE1-bgp] network 11.11.11.11 32
[~CE1-bgp] quit
[~CE1] commit
NOTE
The configurations of CE2, CE3, and CE4 are similar to the configuration of CE1, and are not mentioned
here. For details, see "Configuration Files."
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[~PE1-bgp-vpna] peer 10.1.1.1 as-number 65410
[~PE1-bgp-vpna] commit
[~PE1-bgp-vpna] quit
[~PE1-bgp] ipv4-family vpn-instance vpnb
[~PE1-bgp-vpnb] peer 10.2.1.1 as-number 65420
[~PE1-bgp-vpnb] commit
[~PE1-bgp-vpnb] quit
NOTE
The procedure for configuring PE2 is similar to the procedure for configuring PE1, and the detailed
configuration is not mentioned here. For details, see "Configuration Files."
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the PEs,
and you can view that BGP peer relationships have been established between the PEs and CEs.
Take the peer relationship between PE1 and CE1 as an example.
<PE1> display bgp vpnv4 vpn-instance vpna peer
BGP local router ID : 1.1.1.9
Issue 01 (2011-10-15)
114
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 1.1.1.9 as-number 100
[~PE2-bgp] peer 1.1.1.9 connect-interface loopback 1
[~PE2-bgp] ipv4-family vpnv4
[~PE2-bgp-af-vpnv4] peer 1.1.1.9 enable
[~PE2-bgp-af-vpnv4] commit
[~PE2-bgp-af-vpnv4] quit
[~PE2-bgp] quit
# After the configuration, run the display bgp peer or display bgp vpnv4 all peer command
on the PEs, and you can view that a BGP peer relationship has been set up between the PEs.
<PE1> display bgp peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V
AS
MsgRcvd MsgSent OutQ Up/Down
State
PrefRcv
3.3.3.9
4
100
2
6
0 00:00:12
Established
0
<PE1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 3
Peers in established state : 3
Peer
V
AS MsgRcvd MsgSent
OutQ Up/Down
State
PrefRcv
3.3.3.9
4
100
12
18
0
00:09:38
Established
0
Peer of vpn instance:
VPN-Instance vpna, router ID 1.1.1.9:
10.1.1.1
4
65410 25
25
00:17:57
Established
00:17:10
Established
Issue 01 (2011-10-15)
115
10.1.1.255/32
Direct 0
0
D
127.0.0.1
GigabitEthernet1/0/0
11.11.11.11/32
BGP
255 0
RD
10.1.1.1
GigabitEthernet1/0/0
33.33.33.33/32
BGP
255 0
RD
3.3.3.9
LDP LSP
<PE1> display ip routing-table vpn-instance vpnb
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: vpnb
Destinations : 3
Routes : 3
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.2.1.0/24
Direct 0
0
D
10.2.1.2
GigabitEthernet2/0/0
10.2.1.2/32
Direct 0
0
D
127.0.0.1
GigabitEthernet2/0/0
10.2.1.255/32
Direct 0
0
D
127.0.0.1
GigabitEthernet2/0/0
22.22.22.22/32
BGP
255 0
RD
10.2.1.1
GigabitEthernet2/0/0
44.44.44.44/32
BGP
255 0
RD
3.3.3.9
LDP LSP
CEs in the same VPN can successfully ping each other whereas CEs in different VPNs cannot.
For example, CE1 can successfully ping CE3 at 10.3.1.1 but cannot successfully ping CE4 at
10.4.1.1.
[~CE1] ping -a 11.11.11.11 33.33.33.33
PING 33.33.33.33: 56 data bytes, press CTRL_C to break
Reply from 33.33.33.33: bytes=56 Sequence=1 ttl=251 time=72
Reply from 33.33.33.33: bytes=56 Sequence=2 ttl=251 time=34
Reply from 33.33.33.33: bytes=56 Sequence=3 ttl=251 time=50
Reply from 33.33.33.33: bytes=56 Sequence=4 ttl=251 time=50
Reply from 33.33.33.33: bytes=56 Sequence=5 ttl=251 time=34
--- 33.33.33.33 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 34/48/72 ms
[~CE1] ping -a 11.11.11.11 44.44.44.44
PING 44.44.44.44: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 44.44.44.44 ping statistics --5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
ms
ms
ms
ms
ms
----End
Configuration Files
l
Issue 01 (2011-10-15)
116
mpls ldp
#
interface GigabitEthernet1/0/0
undo shutdown
ip binding vpn-instance vpna
ip address 10.1.1.2 255.255.255.0
#
interface GigabitEthernet2/0/0
undo shutdown
ip binding vpn-instance vpnb
ip address 10.2.1.2 255.255.255.0
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpna
peer 10.1.1.1 as-number 65410
#
ipv4-family vpn-instance vpnb
peer 10.2.1.1 as-number 65420
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
Issue 01 (2011-10-15)
117
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return
Issue 01 (2011-10-15)
118
#
ospf 1
area 0.0.0.0
network 172.2.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return
Issue 01 (2011-10-15)
119
return
Related Tasks
2.4 Configuring Basic BGP/MPLS IP VPN
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-25, CE1 and CE2 belong to the same VPN. CE1 is connected to PE1;
CE2 is connected to PE2. Both CE1 and CE2 use AS 600. When EBGP runs between a PE and
a CE, the BGP routes sent from the CE to the PE carry the AS_Path attribute. The local PE sends
the BGP routes to the remote PE through MP-IBGP. When the remote PE sends the BGP routes
to its connected CE through EBGP, the CE discards the BGP routes whose AS_Path attribute
carries AS 600.
To address the preceding problem, it is required that AS number substitution be configured on
the PEs. In this manner, when a PE sends VPN routes to a CE through BGP, it substitutes its
own AS number (AS 100 in this example) for the AS numbers in the VPN routes. Then, the CE
can receive the remote VPN routes.
Issue 01 (2011-10-15)
120
Loopback1
1.1.1.9/32
PE1
POS1/0/0
10.1.1.2/24
POS1/0/0
20.1.1.2/24
POS2/0/0
20.1.1.1/24
POS1/0/0
10.1.1.1/24
CE1
Loopback1
3.3.3.9/32
Loopback1
2.2.2.9/32
POS2/0/0
30.1.1.2/24
POS2/0/0
30.1.1.1/24
P
Backbone
AS 100
GE2/0/0
100.1.1.1/24
PE2
POS1/0/0
10.2.1.2/24
POS1/0/0
10.2.1.1/24
CE2
GE2/0/0
200.1.1.1/24
VPN1
AS 600
VPN1
AS 600
Configuration Notes
When configuring BGP AS number substitution, note the following:
l
Configuration Roadmap
The configuration roadmap is as follows:
1.
2.
Data Preparation
To complete the configuration, you need the following data:
l
AS numbers of the CEs (CE1 and CE2 having the same AS number that is different from
the AS number of the backbone network)
Procedure
Step 1 Configure basic BGP/MPLS IP VPN functions.
The configurations include the following:
Issue 01 (2011-10-15)
121
l Configure OSPF on the MPLS backbone network so that the PEs and P can learn the routes
to the loopback interfaces of each other.
l Configure basic MPLS functions and MPLS LDP, and set up LDP LSPs on the MPLS
backbone network.
l Set up MP-IBGP peer relationships between the PEs and advertise VPNv4 routes.
l Configure the VPN instance enabled with the IPv4 address family of VPN1 on PE2 and
connect CE2 to PE2.
l Configure the VPN instance enabled with the IPv4 address family of VPN1 on PE1 and
connect CE1 to PE1.
l Configure EBGP on PE1 and CE1, and PE2 and CE2; import routes of each CE to its
connected PE.
After the configuration, run the display ip routing-table command on CE2, and you can view
that CE2 has learnt the route to the network segment (10.1.1.0/24) where the interface that
connects CE1 to PE1 resides, but there is no route to the VPN (100.1.1.0/24) of CE1. This is the
same on CE1.
<CE2> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 9
Routes : 9
Destination/Mask Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24 BGP
255 0
D
10.2.1.2
Pos1/0/0
10.1.1.1/32 BGP
255 0
D
10.2.1.2
Pos1/0/0
10.2.1.0/24 Direct 0
0
D
10.2.1.1
Pos1/0/0
10.2.1.1/32 Direct 0
0
D
127.0.0.1
InLoopBack0
10.2.1.2/32 Direct 0
0
D
10.2.1.2
Pos1/0/0
127.0.0.0/8 Direct 0
0
D
127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D
127.0.0.1
InLoopBack0
200.1.1.0/24 Direct 0
0
D
200.1.1.1
GigabitEthernet2/0/0
200.1.1.1/32 Direct 0
0
D
127.0.0.1
InLoopBack0
Run the display ip routing-table vpn-instance command on the PEs, and you can view that
the VPN routing table has routes to the VPN of the CEs.
Take the display on PE2 as an example.
<PE2> display ip routing-table vpn-instance vpn1
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: vpn1
Destinations : 8
Routes : 8
Destination/Mask Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24 BGP
255 0
RD
1.1.1.9
Pos2/0/0
10.1.1.1/32 BGP
255 0
RD
1.1.1.9
Pos2/0/0
10.1.1.2/32 BGP
255 0
RD
1.1.1.9
Pos2/0/0
10.2.1.0/24 Direct 0
0
D
10.2.1.2
Pos1/0/0
10.2.1.1/32 Direct 0
0
D
10.2.1.1
Pos1/0/0
10.2.1.2/32 Direct 0
0
D
127.0.0.1
InLoopBack0
100.1.1.0/24 BGP
255 0
RD
1.1.1.9
Pos2/0/0
200.1.1.0/24 BGP
255 0
D
10.2.1.1
Pos1/0/0
Run the display bgp routing-table peer received-routes command on CE2, and you can view
that CE2 receives no route to 100.1.1.0/24.
<CE2> display bgp routing-table peer 10.2.1.2 received-routes
BGP Local router ID is 10.2.1.1
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 4
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
Issue 01 (2011-10-15)
122
10.1.1.0/24
10.1.1.1/32
10.2.1.0/24
10.2.1.1/32
0
0
0
0
0
0
100?
100?
100?
100?
After configuring BGP AS number substitution on PE1, you can find that CE1 and CE2 can
successfully ping each other through GE interfaces.
[~CE1] ping a 100.1.1.1 200.1.1.1
PING 200.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 200.1.1.1: bytes=56 Sequence=1 ttl=253 time=109 ms
Reply from 200.1.1.1: bytes=56 Sequence=2 ttl=253 time=67 ms
Reply from 200.1.1.1: bytes=56 Sequence=3 ttl=253 time=66 ms
Reply from 200.1.1.1: bytes=56 Sequence=4 ttl=253 time=85 ms
Reply from 200.1.1.1: bytes=56 Sequence=5 ttl=253 time=70 ms
--- 200.1.1.1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 66/79/109 ms
----End
Issue 01 (2011-10-15)
123
Configuration Files
l
Issue 01 (2011-10-15)
124
Issue 01 (2011-10-15)
125
undo shutdown
link-protocol ppp
ip address 30.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
ipv4-family vpn-instance vpn1
peer 10.2.1.1 as-number 600
peer 10.2.1.1 substitute-as
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 30.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
126
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
When multiple CEs in a VPN site access different PEs, VPN routes sent from CEs to PEs may
return to this VPN site after traveling through the backbone network. This may cause routing
loops in the VPN site.
As shown in Figure 2-26, CE1 and CE2 belong to Site 1; CE2 and CE3 access PE2; Site 1 and
Site 2 have the same AS number. EBGP runs between PEs and CEs. PE1 sends the routes
received from CE1 to PE2 through MP-IBGP, and then PE2 sends the received routes to CE2
and CE3. CE2, however, has learned these routes through an IGP in the VPN site. This may
cause routing loops in the VPN site.
It is required to configure the BGP SoO attribute so that PE2 checks the SoO attribute carried
in the routes to be sent to CE2. If PE2 finds that this SoO attribute is the same as the locally
configured SoO attribute, PE2 refuses to send these routes to CE2. This avoids routing loops in
the VPN site1. PE2 can still send these routes to CE3.
Figure 2-26 Networking diagram of configuring the BGP SoO
Loopback 1
Loopback 1
POS1/0/1
site1
GE2/0/0
GE2/0/0
0/
GE1/
AS
65410
GE1
/0
CE2
Loopback 1
PE1
/0
GE1
POS1/0/1
0/
GE1/
CE1
AS 100
Loopback 1
PE2
site2
GE1/0/0
0/0
GE2/0/0
Loopback 1
CE3
AS
65410
Device
Interface
IP Address
CE1
Loopback1
11.11.11.11/32
GE 1/0/0
192.168.1.2/30
Issue 01 (2011-10-15)
127
PE1
PE2
CE2
CE3
GE 2/0/0
192.168.4.1/30
Loopback1
1.1.1.1/32
POS 1/0/1
10.1.1.1/30
GE 1/0/0
192.168.1.1/30
Loopback1
2.2.2.2/32
POS 1/0/1
10.1.1.2/30
GE 1/0/0
192.168.2.1/30
GE 2/0/0
192.168.3.1/30
Loopback1
22.22.22.22/32
GE 1/0/0
192.168.2.2/30
GE 2/0/0
192.168.4.2/30
Loopback1
33.33.33.33/32
GE 1/0/0
192.168.3.2/30
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IP address for each interface and an IGP on the backbone network so that PEs
can communicate.
2.
Enable MPLS and MPLS LDP on the backbone network so that LDP LSPs can be
established between PEs.
3.
4.
Configure VPN instances on PEs and bind the interfaces connecting PEs to CEs to the VPN
instances.
5.
Establish EBGP peer relationships between PEs and CEs, enable AS number substitution
on PEs.
6.
Data Preparation
To complete the configuration, you need the following data:
l
Names of the VPN instances created on PE1 and PE2, and RDs, and VPN-targets of the
VPN instance IPv4 address family
Procedure
Step 1 Configure an IP address for each interface and an IGP on the backbone network so that PEs can
learn routes to loopback interfaces of each other.
Issue 01 (2011-10-15)
128
In this example, OSPF is configured as an IGP. For configuration details, see "Configuration
Files."
After the configuration is complete, run the display ip routing-table command on PEs. The
command output shows that the PEs have learned the routes to loopback interfaces of each other.
Take the display on PE1 as an example.
<PE1> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 7
Routes : 7
Destination/Mask
1.1.1.1/32
2.2.2.2/32
10.1.1.0/30
10.1.1.1/32
10.1.1.2/32
127.0.0.0/8
127.0.0.1/32
Proto
Pre
Cost
Direct
OSPF
Direct
Direct
Direct
Direct
Direct
0
10
0
0
0
0
0
0
1562
0
0
0
0
0
Flags NextHop
D
D
D
D
D
D
D
127.0.0.1
10.1.1.2
10.1.1.1
127.0.0.1
10.1.1.2
127.0.0.1
127.0.0.1
Interface
InLoopBack0
Pos1/0/1
Pos1/0/1
InLoopBack0
Pos1/0/1
InLoopBack0
InLoopBack0
Step 2 Enable MPLS and MPLS LDP on the backbone network so that LDP LSPs can be established
between PEs.
You need to enable MPLS and MPLS LDP on the PEs in the system view and interface view.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos1/0/1
[~PE1-Pos1/0/1] mpls
[~PE1-Pos1/0/1] mpls ldp
[~PE1-Pos1/0/1] quit
[~PE1] commit
The configuration of PE2 is similar to the configuration of PE1, and is not mentioned here. For
configuration details, see "Configuration Files."
After the configuration is complete, run the display mpls ldp lsp command on PEs. The
command output shows information about the labels assigned to the routes to loopback interfaces
on the other PEs. Take the display on PE1 as an example.
<PE1> display mpls ldp lsp
LDP LSP Information
------------------------------------------------------------------------------DestAddress/Mask
In/OutLabel
UpstreamPeer
NextHop
OutInterface
------------------------------------------------------------------------------1.1.1.1/32
3/NULL
2.2.2.2
127.0.0.1
InLoop0
*1.1.1.1/32
Liberal
2.2.2.2/32
NULL/3
10.1.1.2
Pos1/0/1
2.2.2.2/32
1024/3
2.2.2.2
10.1.1.2
Pos1/0/1
------------------------------------------------------------------------------TOTAL: 3 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
TOTAL: 0 Frr LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
A '*' before a UpstreamPeer means the session is in GR state
A '*' before a NextHop means the LSP is FRR LSP
Issue 01 (2011-10-15)
129
The configuration of PE2 is similar to the configuration of PE1, and is not mentioned here. For
configuration details, see "Configuration Files."
After the configuration is complete, run the display bgp peer or display bgp vpnv4 all peer
command on PEs. The command output shows that BGP peer relationships have been established
between the PEs. Take the display on PE1 as an example.
<PE1> display bgp peer
BGP local router ID : 10.1.1.1
Local AS number : 100
Total number of peers : 1
Peer
PrefRcv
2.2.2.2
AS
MsgRcvd
MsgSent
100
187
186
OutQ
Up/Down State
0 02:44:06 Established
Step 4 On PEs, create VPN instances, enable IPv4 address families on the VPN instances, and bind the
interfaces connecting the PEs to CEs to the VPN instances.
# Configure PE1.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpna-af-ipv4] vpn-target 100:100
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] interface gigabitethernet1/0/0
[~PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[~PE1-GigabitEthernet1/0/0] ip address 192.168.1.1 30
[~PE1-GigabitEthernet1/0/0] quit
[~PE1] commit
# Configure PE2.
[~PE2] ip vpn-instance vpna
[~PE2-vpn-instance-vpna] ipv4-family
[~PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 100:2
[~PE2-vpn-instance-vpna-af-ipv4] vpn-target 100:100
[~PE2-vpn-instance-vpna-af-ipv4] quit
[~PE2-vpn-instance-vpna] quit
[~PE2] interface gigabitethernet1/0/0
[~PE2-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[~PE2-GigabitEthernet1/0/0] ip address 192.168.2.1 30
[~PE2-GigabitEthernet1/0/0] quit
[~PE2] interface gigabitethernet2/0/0
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[~PE2-GigabitEthernet2/0/0] ip address 192.168.3.1 30
[~PE2-GigabitEthernet2/0/0] quit
[~PE2] commit
Issue 01 (2011-10-15)
130
After the configuration is complete, run the display ip vpn-instance command on PEs to view
the configurations of VPN instances.
Step 5 Establish EBGP peer relationships between PEs and CEs, enable AS number substitution on
PEs, and configure PEs to import routes from CEs.
In this configuration example, the two VPN sites have the same AS number. Therefore, AS
number substitution needs to be enabled on PE1 and PE2.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[~PE1-bgp-vpna] peer 192.168.1.2 as-number 65410
[~PE1-bgp-vpna] peer 192.168.1.2 substitute-as
[~PE1-bgp-vpna] import-route direct
[~PE1-bgp-vpna] quit
[~PE1-bgp] quit
[~PE1] commit
# Configure CE1.
[~CE1] bgp 65410
[~CE1-bgp] peer 192.168.1.1 as-number 100
[~CE1-bgp] network 11.11.11.11 32
[~CE1-bgp] network 192.168.4.0 30
[~CE1-bgp] quit
[~CE1] commit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] ipv4-family vpn-instance vpna
[~PE2-bgp-vpna] peer 192.168.2.2 as-number 65410
[~PE2-bgp-vpna] peer 192.168.3.2 as-number 65410
[~PE2-bgp-vpna] peer 192.168.2.2 substitute-as
[~PE2-bgp-vpna] peer 192.168.3.2 substitute-as
[~PE2-bgp-vpna] import-route direct
[~PE2-bgp-vpna] quit
[~PE2-bgp] quit
[~PE2] commit
# Configure CE2.
[~CE2] bgp 65410
[~CE2-bgp] peer 192.168.2.1 as-number 100
[~CE2-bgp] network 22.22.22.22 32
[~CE2-bgp] network 192.168.4.0 30
[~CE2-bgp] quit
[~CE2] commit
# Configure CE3.
[~CE3] bgp 65410
[~CE3-bgp] peer 192.168.3.1 as-number 100
[~CE3-bgp] network 33.33.33.33 32
[~CE3-bgp] quit
[~CE3] commit
After the configuration is complete, run the display bgp vpnv4 vpn-instance peer command
on PEs. The command output shows that the status of EBGP peer relationships between PEs
and CEs is Established. This indicates that EBGP peer relationships have been established
between PEs and CEs. Take the display on PE1 as an example.
<PE1> display bgp vpnv4 vpn-instance vpna peer
BGP local router ID : 10.1.1.1
Local AS number : 100
Issue 01 (2011-10-15)
131
192.168.1.2
AS
4
MsgRcvd
65410
MsgSent
224
OutQ
231
Up/Down
State
0 03:02:12 Established
Run the display bgp vpnv4 routing-table command on PEs. The command output shows
information about the routes sent from the PEs to CEs. The following takes the routes sent from
PE2 to CE2 as an example.
<PE2> display bgp vpnv4 vpn-instance vpna routing-table peer 192.168.2.2 advertisedroutes
VPN-Instance vpna, router ID 2.2.2.2:
BGP Local router ID is 2.2.2.2
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 7
Network
NextHop
*>i
*>
*>
*>i
*>
*>
*>
11.11.11.11/32
22.22.22.22/32
33.33.33.33/32
192.168.1.0/30
192.168.2.0/30
192.168.3.0/30
192.168.4.0/30
1.1.1.1
192.168.2.2
192.168.3.2
1.1.1.1
0.0.0.0
0.0.0.0
192.168.2.2
MED
LocPrf
0
0
0
0
0
0
0
100
100
PrefVal Path/Ogn
0
0
0
0
0
0
0
65410i
65410i
65410i
?
?
?
65410i
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] ipv4-family vpn-instance vpna
[~PE2-bgp-vpna] peer 192.168.2.2 soo 100:101
[~PE2-bgp-vpna] peer 192.168.3.2 soo 100:102
[~PE2-bgp-vpna] quit
[~PE2-bgp] quit
[~PE2] commit
Issue 01 (2011-10-15)
132
11.11.11.11/32
22.22.22.22/32
33.33.33.33/32
192.168.1.0/30
192.168.2.0/30
192.168.3.0/30
192.168.4.0/30
1.1.1.1
192.168.2.2
192.168.3.2
1.1.1.1
0.0.0.0
0.0.0.0
192.168.2.2
MED
LocPrf
0
0
0
0
0
0
0
100
100
PrefVal Path/Ogn
0
0
0
0
0
0
0
65410i
65410i
65410i
?
?
?
65410i
Run the display bgp vpnv4 routing-table command on PE2. The command output shows
information about the SoO attribute carried in the routes sent from PE2 to CE3.
<PE2> display bgp vpnv4 vpn-instance vpna routing-table 11.11.11.11 32
BGP local router ID : 2.2.2.2
Local AS number : 100
VPN-Instance vpna, router ID 2.2.2.2:
Paths:
1 available, 1 best, 1 select
BGP routing table entry information of 11.11.11.11/32:
Label information (Received/Applied): 1028/NULL
From: 1.1.1.1 (10.1.1.1)
Route Duration: 00h11m12s
Relay Tunnel Out-Interface: Pos1/0/1
Relay token: 0x800001
Original nexthop: 1.1.1.1
Qos information : 0x0
Ext-Community:RT <100 : 100>, SoO <100 : 101>
AS-path 65410, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, b
est, select, active, pre 255
Advertised to such 2 peers:
Update-Group 0 :
192.168.2.2
192.168.3.2
The preceding command output shows that after the BGP SoO attribute is configured, the VPN
routes received from CEs carry the SoO attribute, and PE2 does not send any route to CE2. This
indicates that the configuration of the BGP SoO attribute has taken effect.
----End
Configuration Files
l
Issue 01 (2011-10-15)
133
bgp 65410
peer 192.168.1.1 as-number 100
#
ipv4-family unicast
undo synchronization
network 11.11.11.11 255.255.255.255
network 192.168.4.0 255.255.255.252
peer 192.168.1.1 enable
#
return
Issue 01 (2011-10-15)
134
bgp 100
peer 2.2.2.2 as-number 100
peer 2.2.2.2 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
#
ipv4-family vpn-instance vpna
import-route direct
peer 192.168.1.2 as-number 65410
peer 192.168.1.2 substitute-as
peer 192.168.1.2 soo 100:101
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.3
#
return
Issue 01 (2011-10-15)
135
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance vpna
import-route direct
peer 192.168.2.2 as-number 65410
peer 192.168.2.2 substitute-as
peer 192.168.2.2 soo 100:101
peer 192.168.3.2 as-number 65410
peer 192.168.3.2 substitute-as
peer 192.168.3.2 soo 100:102
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.3
#
return
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
With the development of telecommunications services, all telecommunications services will be
carried on a unified IP network. Important services such as 3G/NGN, IPTV streaming media,
and VIP customer VPN require high reliability of the network. To improve network reliability,
Issue 01 (2011-10-15)
136
in addition to reliability of the network devices, you must consider the link and network reliability
such as fast route convergence, fault detection, fast reroute, and path backup.
At the access layer, CE dual-homing is a common solution to improving network reliability. The
networking where a CE is connected to two PEs that belong to the same VPN is called CE dualhoming. In this case, the CE accesses the backbone network through two links. The two links
can work in either load balancing or master/backup mode.
As shown in Figure 2-27, CE1 resides at site1 of vpn1; CE2 resides at site2 of vpn1. CE1 is
dual-homed to PE1 and PE2; CE2 is dual-homed to PE3 and PE4.
If the data traffic from CE1 to CE2 is heavy whereas the traffic from CE2 to CE1 is light, the
data traffic from CE1 to CE2 can be transmitted in load balancing mode; the data traffic from
CE2 to CE1 can be forwarded by PE4 with PE3 as a backup.
Figure 2-27 Networking diagram of CE dual-homing
VPN backbone
AS 100
Loopback1
Loopback1
POS2/0/0
POS2/0/0
CE1
GE1/0/0
POS1/0/0
PE1
GE1/0/0
GE2/0/0
AS 65410
PE3
P2
POS2/0/0
POS1/0/0
Loopback1
GE2/0/0
POS1/0/0
P1
PE2
Loopback1
GE1/0/0
vpn1 site1
Loopback1
POS2/0/0
POS1/0/0
Loopback1
GE1/0/0
GE2/0/0
PE4
Loopback1
GE2/0/0
vpn1 site2
Loopback1
AS 65420
Device
Interface
IP Address
CE1
Loopback1
11.11.11.11/32
GE 1/0/0
10.1.1.1/30
GE 2/0/0
10.2.1.1/30
Loopback1
1.1.1.1/32
GE 1/0/0
10.1.1.2/30
POS 2/0/0
100.1.1.1/30
Loopback1
2.2.2.2/32
GE 1/0/0
10.2.1.2/30
POS 2/0/0
100.2.1.1/30
Loopback1
5.5.5.5/32
POS 1/0/0
100.1.1.2/30
POS 2/0/0
100.3.1.1/30
Loopback1
6.6.6.6/32
POS 1/0/0
100.2.1.2/30
POS 2/0/0
100.4.1.1/30
Loopback1
3.3.3.3/32
POS 1/0/0
100.3.1.2/30
PE1
PE2
P1
P2
PE3
Issue 01 (2011-10-15)
CE2
137
PE4
CE2
10.3.1.1/30
Loopback1
4.4.4.4/32
POS 1/0/0
100.4.1.2/30
GE 2/0/0
10.4.1.1/30
Loopback1
22.22.22.22/32
GE 1/0/0
10.3.1.2/30
GE 2/0/0
10.4.1.2/30
Configuration Notes
When configuring CE dual-homing with EBGP running between a PE and a CE, note the
following:
l
The CE is dual-homed to two PEs configured with VPN instances of different RDs.
Configuration Roadmap
The configuration roadmap is as follows:
1.
2.
Configure load balancing for the data traffic from CE1 to CE2 in the BGP view of CE1.
3.
Increase the MED value of the BGP-VPN route on PE3 to ensure that the next hop of the
route selected by CE2 to the users that access CE1 is PE4.
Data Preparation
To complete the configuration, you need the following data:
l
Names of the VPN instances, RDs, and VPN targets of the PEs
Procedure
Step 1 Configure an IGP on the MPLS backbone network to interconnect devices on the MPLS
backbone network.
# Assign an IP address to each interface on PE1. Note that the IP address of a loopback interface
contains the 32-bit mask.
<HUAWEI> system-view
[~HUAWEI] sysname PE1
[~PE1] interface loopback 1
[~PE1-LoopBack1] ip address 1.1.1.1 32
[~PE1-LoopBack1] commit
[~PE1-LoopBack1] quit
[~PE1] interface pos2/0/0
[~PE1-Pos2/0/0] ip address 100.1.1.1 30
[~PE1-Pos2/0/0] commit
[~PE1-Pos2/0/0] quit
Issue 01 (2011-10-15)
138
# The configurations of other devices on the backbone network are the same as the configuration
of PE1, and are not mentioned here. For details, see "Configuration Files."
After the configuration, run the display ip routing-table command, and you can view that PE1
and PE3, and PE2 and PE4 have learnt the routes to Loopback1 of each other.
Take the display on PE1 as an example.
<PE1> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 9
Routes : 9
Destination/Mask Proto Pre Cost
Flags NextHop
Interface
1.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
3.3.3.3/32 ISIS
15
20
D 100.1.1.2
Pos2/0/0
5.5.5.5/32 ISIS
15
10
D 100.1.1.2
Pos2/0/0
100.1.1.0/30 Direct 0
0
D 100.1.1.1
Pos2/0/0
100.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
100.1.1.2/32 Direct 0
0
D 100.1.1.2
Pos2/0/0
100.3.1.0/30 ISIS
15
20
D 100.1.1.2
Pos2/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Step 2 Configure basic MPLS functions and MPLS LDP, and set up LDP LSPs on the MPLS backbone
network.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos 2/0/0
[~PE1-Pos2/0/0] mpls
[~PE1-Pos2/0/0] mpls ldp
[~PE1-Pos2/0/0] commit
[~PE1-Pos2/0/0] quit
# The configurations of other devices on the backbone network are the same as the configuration
of PE1, and are not mentioned here. For details, see "Configuration Files."
After the configuration, LDP sessions can be set up between PE1 and the P and between the P
and PE2. Run the display mpls ldp session command, and you can view that the Status field
is dislayed as Operational. Run the display mpls ldp lsp command, and you can check whether
LDP LSPs are set up.
Take the display on PE1 as an example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
-----------------------------------------------------------------------------Peer-ID
Status
LAM SsnRole SsnAge
KA-Sent/Rcv
------------------------------------------------------------------------------
Issue 01 (2011-10-15)
139
5.5.5.5:0
Operational DU
Passive 000:07:02
1688/1688
-----------------------------------------------------------------------------TOTAL: 1 session(s) Found.
LAM : Label Advertisement Mode
SsnAge Unit : DDD:HH:MM
<PE1> display mpls ldp lsp
LDP LSP Information
-----------------------------------------------------------------------------SN
DestAddress/Mask
In/OutLabel
Next-Hop
In/Out-Interface
-----------------------------------------------------------------------------1
1.1.1.1/32
3/NULL
127.0.0.1
Pos2/0/0/InLoop0
2
3.3.3.3/32
NULL/1025
100.1.1.2
-------/Pos2/0/0
3
5.5.5.5/32
NULL/3
100.1.1.2
-------/Pos2/0/0
*4
100.1.1.0/30
Liberal
5
100.3.1.0/30
NULL/3
100.1.1.2
-------/Pos2/0/0
-----------------------------------------------------------------------------TOTAL: 4 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
Step 3 Configure VPN instances enabled with the IPv4 address family on the PEs and connect the CEs
to the PEs through the VPN instances.
# Configure PE1. Configure vpn1 and specify its RD and VPN target. The VPN target configured
on the local PE must be the same as the VPN target of the MP-BGP peer PE so that sites in the
same VPN can communicate with each other.
[~PE1] ip vpn-instance vpn1
[~PE1-vpn-instance-vpn1] ipv4-family
[~PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both
[~PE1-vpn-instance-vpn1-af-ipv4] commit
[~PE1-vpn-instance-vpn1-af-ipv4] quit
[~PE1-vpn-instance-vpn1] quit
# Bind the interface that connects PE1 to a CE to a VPN instance, and assign an IP address to
the interface.
[~PE1] interface gigabitethernet 1/0/0
[~PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpn1
[~PE1-GigabitEthernet1/0/0] ip address 10.1.1.2 30
[~PE1-GigabitEthernet1/0/0] commit
[~PE1-GigabitEthernet1/0/0] quit
# The configurations of PE2, PE3, and PE4 are similar to the configuration of PE1, and are not
mentioned here. For details, see "Configuration Files."
After the configuration, run the display ip vpn-instance verbose command on the PEs to view
the configurations of VPN instances.
Take the display on PE1 as an example.
<PE1> display ip vpn-instance verbose
Total VPN-Instances configured : 1
VPN-Instance Name and ID : vpn1, 1
Interfaces : GigabitEthernet1/0/0
Address family ipv4
Create date : 2008/09/18 14:17:15
Up time : 0 days, 07 hours, 23 minutes and 53 seconds
Route Distinguisher : 100:1
Export VPN Targets : 1:1
Import VPN Targets : 1:1
Label policy : label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
Step 4 Configure EBGP on the PEs and CEs, and import VPN routes.
Issue 01 (2011-10-15)
140
# Assign an IP address to each interface on the CEs as shown in Figure 2-27. The detailed
configuration is not mentioned here. For details, see "Configuration Files."
# On CE1, specify PE1 and PE2 as EBGP peers.
[~CE1] interface loopback 1
[~CE1-LoopBack1] ip address 11.11.11.11 32
[~CE1-LoopBack1] quit
[~CE1] bgp 65410
[~CE1-bgp] peer 10.1.1.2 as-number 100
[~CE1-bgp] peer 10.2.1.2 as-number 100
[~CE1-bgp] network 11.11.11.11 32
[~CE1-bgp] commit
[~CE1-bgp] quit
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the PEs,
and you can view that BGP peer relationships have been established between the PEs and CEs.
Take the peer relationship between PE1 and CE1 as an example.
<PE1> display bgp vpnv4 vpn-instance vpn1 peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V
AS MsgRcvd MsgSent OutQ Up/Down
State PrefRcv
Issue 01 (2011-10-15)
141
408
435
0 06:16:09 Established
Each PE can successfully ping its connected CE. Take the display on PE1 as an example.
<PE1> ping -vpn-instance vpn1 11.11.11.11
PING 11.11.11.11: 56 data bytes, press CTRL_C to break
Reply from 11.11.11.11: bytes=56 Sequence=1 ttl=254
Reply from 11.11.11.11: bytes=56 Sequence=2 ttl=254
Reply from 11.11.11.11: bytes=56 Sequence=3 ttl=254
Reply from 11.11.11.11: bytes=56 Sequence=4 ttl=254
Reply from 11.11.11.11: bytes=56 Sequence=5 ttl=254
--- 11.11.11.11 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 20/42/80 ms
time=80
time=20
time=30
time=50
time=30
ms
ms
ms
ms
ms
# On PE3, specify PE1 as the IBGP peer and establish an IBGP peer relationship between PE3
and PE1 through loopback interfaces.
[~PE3] bgp 100
[~PE3-bgp] peer 1.1.1.1 as-number 100
[~PE3-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE3-bgp] ipv4-family vpnv4
[~PE3-bgp-af-vpnv4] peer 1.1.1.1 enable
[~PE3-bgp-af-vpnv4] commit
[~PE3-bgp-af-vpnv4] quit
# On PE2, specify PE4 as the IBGP peer and establish an IBGP peer relationship between PE2
and PE4 through loopback interfaces.
[~PE2] bgp 100
[~PE2-bgp] peer 4.4.4.4 as-number 100
[~PE2-bgp] peer 4.4.4.4 connect-interface loopback 1
[~PE2-bgp] ipv4-family vpnv4
[~PE2-bgp-af-vpnv4] peer 4.4.4.4 enable
[~PE2-bgp-af-vpnv4] commit
[~PE2-bgp-af-vpnv4] quit
# On PE4, specify PE2 as the IBGP peer and establish an IBGP peer relationship between PE4
and PE2 through loopback interfaces.
[~PE4] bgp 100
[~PE4-bgp] peer 2.2.2.2 as-number 100
[~PE4-bgp] peer 2.2.2.2 connect-interface loopback 1
[~PE4-bgp] ipv4-family vpnv4
[~PE4-bgp-af-vpnv4] peer 2.2.2.2 enable
[~PE4-bgp-af-vpnv4] commit
[~PE4-bgp-af-vpnv4] quit
After the configuration, run the display bgp peer or display bgp vpnv4 all peer command on
the PEs, and you can view that the BGP peer relationships have been established between the
PEs.
<PE1> display bgp peer
Issue 01 (2011-10-15)
142
25
0 00:17:57 Established
Step 6 On CE1, enable load balancing for the traffic from CE1 to CE2.
[~CE1] bgp 65410
[~CE1-bgp] ipv4-family unicast
[~CE1-bgp-af-ipv4] maximum load-balancing 2
[~CE1-bgp-af-ipv4] commit
Step 7 Configure a routing policy. Increase the MED value of the BGP route advertised by PE3 to CE2
and ensure that the traffic from CE2 to CE1 passes through PE4. PE3 functions as a backup.
[~PE3] route-policy policy1 permit node 10
[~PE3-route-policy] apply cost 120
[~PE3-route-policy] commit
[~PE3-route-policy] quit
[~PE3] bgp 100
[~PE3-bgp] ipv4-family vpn-instance vpn1
[~PE3-bgp-vpn1] peer 10.3.1.2 route-policy policy1 export
[~PE3-bgp-vpn1] commit
Display the BGP routing table of CE2. You can view that, for the route to 11.11.11.11/32, the
MED value advertised by PE3 is 120. This value is greater than the MED value advertised by
PE4. Therefore, the MED value advertised by PE4 is chosen. By default, the MED value is 0.
<CE2> display bgp routing-table
BGP Local router ID is 11.11.11.11
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 2
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
11.11.11.11/32
65410?
*
65410?
*>
22.22.22.22/32
10.4.1.1
100
10.3.1.1
120
100
0.0.0.0
Proto
Pre
10.1.1.0/30 Direct 0
Gigabitethernet1/0/0
10.1.1.1/32 Direct 0
Issue 01 (2011-10-15)
Cost
Flags NextHop
10.1.1.1
127.0.0.1
Interface
InLoopBack0
143
10.2.1.0/30 Direct
Gigabitethernet2/0/0
10.2.1.1/32 Direct
11.11.11.11/32 Direct
22.22.22.22/32 BGP
Gigabitethernet1/0/0
BGP
Gigabitethernet2/0/0
127.0.0.0/8
Direct
127.0.0.1/32 Direct
10.2.1.1
0
0
255
0
0
0
D
D
D
127.0.0.1
127.0.0.1
10.1.1.2
255
10.2.1.2
0
0
0
0
D
D
127.0.0.1
127.0.0.1
InLoopBack0
LoopBack1
InLoopBack0
InLoopBack0
Run the display ip routing-table command on CE2, you can view the routes to the users
connected to CE1, and the next hop of the routes is 10.4.1.1. The next hop is the IP address of
the interface that connects PE4 to CE2.
<CE2> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 8
Routes : 8
Destination/Mask
Proto
11.11.11.11/32 BGP
Gigabitethernet2/0/0
22.22.22.22/32 Direct
10.3.1.0/30 Direct
GigabitEthernet1/0/0
10.3.1.2/32 Direct
10.4.1.0/30 Direct
Gigabitethernet2/0/0
10.4.1.2/32 Direct
127.0.0.0/8
Direct
127.0.0.1/32 Direct
Pre
Cost
Flags NextHop
Interface
255
10.4.1.1
0
0
0
0
D
D
127.0.0.1
10.3.1.2
LoopBack1
0
0
0
0
D
D
127.0.0.1
10.4.1.2
InLoopBack0
0
0
0
0
0
0
D
D
D
127.0.0.1
127.0.0.1
127.0.0.1
InLoopBack0
InLoopBack0
InLoopBack0
----End
Configuration Files
l
Issue 01 (2011-10-15)
144
Issue 01 (2011-10-15)
145
network-entity 10.0000.0000.0002.00
#
interface Gigabitethernet1/0/0
undo shutdown
ip binding vpn-instance vpn1
ip address 10.2.1.2 255.255.255.252
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 100.2.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
isis enable 1
#
bgp 100
peer 4.4.4.4 as-number 100
peer 4.4.4.4 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 4.4.4.4 enable
#
ipv4-family vpnv4
policy vpn-target
peer 4.4.4.4 enable
#
ipv4-family vpn-instance vpn1
peer 10.2.1.1 as-number 65410
#
Return
Configuration file of P1
#
sysname P1
#
mpls lsr-id 5.5.5.5
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0005.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 100.1.1.2 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 100.3.1.1 255.255.255.252
isis enable 1
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
isis enable 1
#
Issue 01 (2011-10-15)
146
Return
Configuration file of P2
#
sysname P2
#
mpls lsr-id 6.6.6.6
#
mpls
#
mpls ldp
#
isis 1
network-entity 10.0000.0000.0006.00
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 100.2.1.2 255.255.255.252
mpls
mpls ldp
isis enable 1
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 100.4.1.1 255.255.255.252
mpls
mpls ldp
isis enable 1
#
interface LoopBack1
ip address 6.6.6.6 255.255.255.255
isis enable 1
#
Return
Issue 01 (2011-10-15)
147
isis enable 1
#
bgp 100
peer 1.1.1.1 as-number 100
peer 1.1.1.1 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance vpn1
peer 10.3.1.2 as-number 65420
peer 10.3.1.2 route-policy policy1 export
#
route-policy policy1 permit node 10
apply cost 120
#
Return
Issue 01 (2011-10-15)
148
#
ipv4-family vpn-instance vpn1
peer 10.4.1.2 as-number 65420
#
Return
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
When deploying a VPN, you can configure double route reflectors (RRs) on the VPN to improve
reliability. To achieve this, you need to select two RRs from the Ps in the same AS on the
backbone network and ensure that the two RRs back up each other and reflect routes of the public
network and VPNv4.
Issue 01 (2011-10-15)
149
Figure 2-28 Networking of configuring double RRs for the optimization of the VPN backbone
layer
Loopback1
3.3.3.9/32
Loopback1
2.2.2.9/32
RR1
POS1/0/0
100.1.2.2/24
POS1/0/0
100.1.2.1/24
Loopback1
1.1.1.9/32
PE1
POS2/0/0
POS1/0/0
100.2.3.1/24 100.2.3.2/24
POS3/0/0
100.2.4.1/24
POS2/0/0
100.3.4.1/24
AS100
POS3/0/0
100.1.3.1/24
POS2/0/0
10.1.1.2/24
POS3/0/0
100.1.3.2/24
AS65410
POS1/0/0
100.3.4.2/24
POS3/0/0
100.2.4.2/24
POS2/0/0 PE2
10.2.1.2/24
POS1/0/0
10.2.1.1/24
POS1/0/0
10.1.1.1/24
Loopback1
11.11.11.11/32
RR2
AS65420
CE1
Loopback1
4.4.4.9/32
Loopback1
22.22.22.22/3
2
CE2
As shown in Figure 2-28, PE1, PE2, RR1, and RR2 are within AS100 of the backbone network.
CE1 and CE2 belong to vpna. It is required that RR1 and RR2 be configured as RRs.
Configuration Notes
When configuring double RRs for the optimization of the VPN backbone layer, note the
following:
l
The RRs do not filter the received VPNv4 routes based on VPN targets.
The RRs that back up each other are configured with the same cluster ID.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP, enable MPLS and MPLS LDP, and set up LDP LSPs on the MPLS
backbone network.
2.
Set up MP-IBGP connections between the PEs and RRs. There is no need to set up an MPIBGP connection between PEs.
3.
4.
Configure RR1 and RR2 to back up each other and configure them with the same cluster
ID.
5.
Configure RR1 and RR2 to receive all VPNv4 routing information without filtering the
information based on VPN targets because RR1 and RR2 must save all VPNv4 routing
information and advertise it to PEs.
Issue 01 (2011-10-15)
150
NOTE
On the VPN with double RRs, there must be at least two paths not sharing the same network segment or
node between each RR and PE. Otherwise, the double RRs are inapplicable.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances on PE1 and PE2
Configuration Procedures
1.
The IP addresses of loopback interfaces that are used as LSR IDs need to be advertised.
After the configuration, the devices along the LSP can learn the address of the loopback
interface from each other.
Take the display on PE1 as an example.
<PE1> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 15
Routes : 17
Destination/Mask Proto Pre Cost
Flags NextHop
Interface
1.1.1.9/32 Direct 0
0
D 127.0.0.1
InLoopBack0
2.2.2.9/32 OSPF
10
2
D 100.1.2.2
Pos1/0/0
3.3.3.9/32 OSPF
10
2
D 100.1.3.2
Pos3/0/0
4.4.4.9/32 OSPF
10
3
D 100.1.3.2
Pos3/0/0
OSPF
10
3
D 100.1.2.2
Pos1/0/0
100.1.2.0/24 Direct 0
0
D 100.1.2.1
Pos1/0/0
100.1.2.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
100.1.2.2/32 Direct 0
0
D 100.1.2.2
Pos1/0/0
100.1.3.0/24 Direct 0
0
D 100.1.3.1
Pos3/0/0
100.1.3.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
100.1.3.2/32 Direct 0
0
D 100.1.3.2
Pos3/0/0
100.2.3.0/24 OSPF
10
2
D 100.1.3.2
Pos3/0/0
OSPF
10
2
D 100.1.2.2
Pos1/0/0
100.2.4.0/24 OSPF
10
2
D 100.1.2.2
Pos1/0/0
100.3.4.0/24 OSPF
10
2
D 100.1.3.2
Pos3/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
2.
Issue 01 (2011-10-15)
151
Peer-ID
Status
LAM SsnRole SsnAge
KA-Sent/Rcv
---------------------------------------------------------------------2.2.2.9:0
Operational DU
Passive 000:00:01
8/8
3.3.3.9:0
Operational DU
Passive 000:00:00
4/4
---------------------------------------------------------------------TOTAL: 2 session(s) Found.
LAM : Label Advertisement Mode
SsnAge Unit : DDD:HH:MM
<RR1> display mpls ldp session
LDP Session(s) in Public Network
---------------------------------------------------------------------Peer-ID
Status
LAM SsnRole SsnAge
KA-Sent/Rcv
---------------------------------------------------------------------1.1.1.9:0
Operational DU
Active
000:00:02
11/11
3.3.3.9:0
Operational DU
Passive 000:00:01
8/8
4.4.4.9:0
Operational DU
Passive 000:00:00
4/4
---------------------------------------------------------------------TOTAL: 3 session(s) Found.
LAM : Label Advertisement Mode
SsnAge Unit : DDD:HH:MM
3.
# Configure RR1.
<RR1> system-view
[~RR1] bgp 100
[~RR1-bgp] peer 1.1.1.9 as-number 100
[~RR1-bgp] peer 1.1.1.9 connect-interface loopback 1
[~RR1-bgp] peer 3.3.3.9 as-number 100
[~RR1-bgp] peer 3.3.3.9 connect-interface loopback 1
[~RR1-bgp] peer 4.4.4.9 as-number 100
[~RR1-bgp] peer 4.4.4.9 connect-interface loopback 1
[~RR1-bgp] ipv4-family vpnv4
[~RR1-bgp-af-vpnv4] peer 1.1.1.9 enable
[~RR1-bgp-af-vpnv4] peer 3.3.3.9 enable
[~RR1-bgp-af-vpnv4] peer 4.4.4.9 enable
[~RR1-bgp-af-vpnv4] commit
[~RR1-bgp-af-vpnv4] quit
[~RR1-bgp] quit
# Configure RR2.
<RR2> system-view
[~RR2] bgp 100
[~RR2-bgp] peer 1.1.1.9 as-number 100
[~RR2-bgp] peer 1.1.1.9 connect-interface loopback 1
[~RR2-bgp] peer 2.2.2.9 as-number 100
[~RR2-bgp] peer 2.2.2.9 connect-interface loopback 1
[~RR2-bgp] peer 4.4.4.9 as-number 100
[~RR2-bgp] peer 4.4.4.9 connect-interface loopback 1
[~RR2-bgp] ipv4-family vpnv4
[~RR2-bgp-af-vpnv4] peer 1.1.1.9 enable
[~RR2-bgp-af-vpnv4] peer 2.2.2.9 enable
[~RR2-bgp-af-vpnv4] peer 4.4.4.9 enable
[~RR2-bgp-af-vpnv4] commit
[~RR2-bgp-af-vpnv4] quit
[~RR2-bgp] quit
# Configure PE2.
The configuration of PE2 is similar to the configuration of PE1, and is not mentioned here.
Issue 01 (2011-10-15)
152
After the configuration, run the display bgp vpnv4 all peer command on the PEs, and you
can view that the IBGP peer relationship is established between each PE and RR, and the
EBGP peer relationship is established between each PE and CE.
Take the display on PE1 and RR1 as an example.
<PE1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 3
Peer
V
AS MsgRcvd
2.2.2.9
4
100 2
3.3.3.9
4
100 3
4.
MsgSent
4
5
Set up the EBGP peer relationships between the PEs and CEs and import VPN routes.
For details, see 2.18.1 Example for Configuring BGP/MPLS IP VPN.
5.
Configure a VPN instance enabled with the IPv4 address family on each PE.
For details, see 2.18.1 Example for Configuring BGP/MPLS IP VPN.
6.
# Configure RR2.
[~RR2] bgp 100
[~RR2-bgp] ipv4-family vpnv4
[~RR2-bgp-af-vpnv4] reflector cluster-id 100
[~RR2-bgp-af-vpnv4] peer 1.1.1.9 reflect-client
[~RR2-bgp-af-vpnv4] peer 2.2.2.9 reflect-client
[~RR2-bgp-af-vpnv4] peer 4.4.4.9 reflect-client
[~RR2-bgp-af-vpnv4] undo policy vpn-target
[~RR2-bgp-af-vpnv4] commit
[~RR2-bgp-af-vpnv4] quit
7.
CE1 and CE2 can successfully ping each other. This indicates that the configuration
succeeds.
After the shutdown command is run in the view of POS 3/0/0 on PE1 or POS 3/0/0 on
PE2, CE1 and CE2 can still successfully ping each other. This indicates that the two RRs
are successfully configured.
Issue 01 (2011-10-15)
153
Configuration Files
l
l
Issue 01 (2011-10-15)
154
#
sysname RR1
#
mpls lsr-id 2.2.2.9
#
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 100.1.2.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 100.2.3.1 255.255.255.0
mpls
mpls ldp
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 100.2.4.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface loopback 1
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface loopback 1
peer 4.4.4.9 as-number 100
peer 4.4.4.9 connect-interface loopback 1
#
ipv4-family unicast
undo synchronization
peer 4.4.4.9 enable
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpnv4
reflector cluster-id 100
undo policy vpn-target
peer 1.1.1.9 enable
peer 1.1.1.9 reflect-client
peer 3.3.3.9 enable
peer 3.3.3.9 reflect-client
peer 4.4.4.9 enable
peer 4.4.4.9 reflect-client
#
ospf 1
area 0.0.0.0
network 100.1.2.0 0.0.0.255
network 100.2.3.0 0.0.0.255
network 100.2.4.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return
Issue 01 (2011-10-15)
155
Issue 01 (2011-10-15)
156
Issue 01 (2011-10-15)
157
Related Tasks
2.5 Configuring Route Reflection to Optimize the VPN Backbone Layer
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
Figure 2-29 shows the networking of a BGP/MPLS IP VPN. CE1, CE2, CE3, and CE4 belong
to vpna; CE1, CE2, CE3 and PE1 are in the same AS and all these three CEs are connected to
PE1. It is required that PE1 be configured as an RR to reduce the number of IBGP connections
between CE1, CE2, and CE3 and reflect private routes.
Issue 01 (2011-10-15)
158
Figure 2-29 Networking for configuring an RR for the optimization of the VPN access layer
Loopback1
11.11.11.11/32
CE1
G
10 E1/
.1. 0/0
1.2
/ 24
Loopback1
22.22.22.22/32
Loopback1
1.1.1.1/32
G
10 E1/
.1. 0/0
1
GE1/0/0 .1/2
4
10.2.1.2/24
GE2/0/0
10.2.1.1/24
CE2
CE3
/0
1/0 2/24
E
G .1.
.3
10
/0
3 /0 1 /2 4
E
G .1 .
.3
10
Loopback1
44.44.44.44/32
MPLS Backbone
AS 100
PE2
POS1/0/0
PE1
100.3.1.2/24
POS1/0/0
100.3.1.1/24
GE1/0/0
10.4.1.2/24
GE1/0/0
10.4.1.1/24
CE4
Loopback1
2.2.2.2/32
Loopback1
33.33.33.33/32
Configuration Notes
When configuring an RR for the optimization of the VPN access layer, note the following:
l
The interfaces that connect PE1 to CE1, CE2, and CE3 are bound to the same VPN instance.
An IBGP connection is set up between PE1 and each of CE1, CE2, and CE3, and direct
routes of PE1 are imported to BGP VPN instances IPv4 address family so that routes from
a CE can be iterated to the next hop when being reflected to other CEs.
Configuration Roadmap
The configuration roadmap is as follows:
1.
2.
Set up an IBGP connection between PE1 and each of CE1, CE2, and CE3.
3.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances on PE1 and PE2
Issue 01 (2011-10-15)
159
Configuration Procedures
1.
Configure an IGP on the MPLS backbone network so that the PEs can learn the routes to
the loopback interfaces of each other. The detailed configuration is not mentioned here.
For details, see "Configuration Files."
2.
3.
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 1.1.1.1 as-number 100
[~PE2-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE2-bgp] ipv4-family vpnv4
[~PE2-bgp-af-vpnv4] peer 1.1.1.1 enable
[~PE2-bgp-af-vpnv4] commit
[~PE2-bgp-af-vpnv4] quit
[~PE2-bgp] quit
After the configuration, run the display bgp vpnv4 all peer command on the PEs, and you
can view that MP-IBGP peer relationships have been established between the PEs and CEs.
<PE1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 1
Peer
PrefRcv
2.2.2.2
AS
MsgRcvd
100
1633
MsgSent
1641
OutQ
Up/Down
State
0 27:09:46 Established
4.
Configure a VPN instance enabled with the IPv4 address family on each PE and bind the
PE interfaces that connect to the CEs to the VPN instance.
# Configure PE1, and bind the PE1 interfaces that connect to the CEs to the same VPN
instance.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
Issue 01 (2011-10-15)
160
# Configure PE2.
[~PE2] ip vpn-instance vpna
[~PE2-vpn-instance-vpna] ipv4-family
[~PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[~PE2-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE2-vpn-instance-vpna-af-ipv4] quit
[~PE2-vpn-instance-vpna] quit
[~PE2] interface gigabitethernet 1/0/0
[~PE2-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[~PE2-GigabitEthernet1/0/0] ip address 10.4.1.1 24
[~PE2-GigabitEthernet1/0/0] quit
[~PE2] commit
# After the configuration, run the display ip vpn-instance verbose command on PEs to
view the configurations of VPN instances.
Take the display on PE1 as an example.
<PE1> display ip vpn-instance verbose
Total VPN-Instances configured : 1
VPN-Instance Name and ID : vpna, 1
Interfaces : GigabitEthernet1/0/0,
GigabitEthernet2/0/0,
GigabitEthernet3/0/0
Address family ipv4
Create date : 2009/12/06 15:39:50
Up time : 0 days, 00 hours, 02 minutes and 22 seconds
Route Distinguisher : 100:1
Export VPN Targets : 111:1
Import VPN Targets : 111:1
Label policy : label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
5.
Set up an IBGP peer relationship between PE1 and each of CE1, CE2, and CE3.
# Configure PE1 as an IBGP peer for each of CE1, CE2, and CE3, and import direct routes
to the BGP VPN instance IPv4 address family routing table of PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[~PE1-bgp-vpna] peer 10.1.1.2 as-number 100
[~PE1-bgp-vpna] peer 10.2.1.2 as-number 100
[~PE1-bgp-vpna] peer 10.3.1.2 as-number 100
[~PE1-bgp-vpna] import-route direct
[~PE1-bgp-vpna] commit
[~PE1-bgp-vpna] quit
# Configure CE1.
[~CE1] interface loopback 1
[~CE1-Loopback1] ip address 11.11.11.11 32
[~CE1-Loopback1] quit
Issue 01 (2011-10-15)
161
100
peer 10.1.1.1 as-number 100
network 11.11.11.11 32
commit
# Configure CE2.
[~CE2] interface loopback 1
[~CE2-Loopback1] ip address 22.22.22.22 32
[~CE2-Loopback1] quit
[~CE2] bgp 100
[~CE2-bgp] peer 10.2.1.1 as-number 100
[~CE2-bgp] network 22.22.22.22 32
[~CE2-bgp] commit
# Configure CE3.
[~CE3] interface loopback 1
[~CE3-Loopback1] ip address 33.33.33.33 32
[~CE3-Loopback1] quit
[~CE3] bgp 100
[~CE3-bgp] peer 10.3.1.1 as-number 100
[~CE3-bgp] network 33.33.33.33 32
[~CE3-bgp] commit
After the configuration, run the display bgp vpnv4 vpn-instance peer command on PE1,
and you can view that the IBGP peer relationship is set up between PE1 and each of CE1,
CE2, and CE3.
<PE1> display bgp vpnv4 vpn-instance vpna peer
BGP local router ID : 10.1.1.1
Local AS number : 100
Total number of peers : 3
Peer
PrefRcv
10.1.1.2
0
10.2.1.2
0
10.3.1.2
0
6.
AS
MsgSent
OutQ
Up/Down
State
100
1058
1058
0 17:37:22 Established
100
0 00:01:56 Established
100
0 00:00:32 Established
7.
Proto
10.1.1.0/24 BGP
GigabitEthernet1/0/0
10.1.1.1/32 BGP
GigabitEthernet1/0/0
10.1.1.2/32 BGP
GigabitEthernet1/0/0
Issue 01 (2011-10-15)
Pre
Cost
Flags NextHop
255
RD 10.2.1.1
255
RD 10.1.1.2
255
RD 10.2.1.1
Interface
162
10.2.1.2
10.2.1.1
127.0.0.1
255
RD 10.2.1.1
255
RD 10.1.1.2
255
RD 10.3.1.2
255
RD 10.2.1.1
0
0
0
0
D
D
127.0.0.1
127.0.0.1
127.0.0.1
InLoopBack0
InLoopBack0
Configuration Files
l
Issue 01 (2011-10-15)
163
undo shutdown
ip address 10.3.1.2 255.255.255.0
#
interface LoopBack1
ip address 33.33.33.33 255.255.255.255
#
bgp 100
peer 10.3.1.1 as-number 100
network 33.33.33.33 255.255.255.255
#
ipv4-family unicast
peer 10.3.1.1 enable
#
return
Issue 01 (2011-10-15)
164
policy vpn-target
peer 2.2.2.2 enable
#
ipv4-family vpn-instance vpna
peer 10.1.1.2 as-number 100
peer 10.2.1.2 as-number 100
peer 10.3.1.2 as-number 100
peer 10.1.1.2 reflect-client
peer 10.2.1.2 reflect-client
peer 10.3.1.2 reflect-client
import-route direct
#
return
Issue 01 (2011-10-15)
165
interface LoopBack1
ip address 44.44.44.44 255.255.255.255
#
bgp 65410
peer 10.4.1.1 as-number 100
network 44.44.44.44 255.255.255.255
#
ipv4-family unicast
peer 10.4.1.1 enable
#
return
Related Tasks
2.5 Configuring Route Reflection to Optimize the VPN Backbone Layer
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-30, the communications between the Spoke-CEs is controlled by the HubCE at a central site. That is, the traffic between Spoke-CEs is forwarded through the Hub-CE,
not only through the Hub-PE.
Issue 01 (2011-10-15)
166
GE2/0/0
110.2.1.1/24
GE3/0/0
110.1.1.2/24
GE4/0/0
110.2.1.2/24
Hub-PE
POS2/0/0
11.1.1.2/24
POS1/0/0
10.1.1.2/24
Loopback1
1.1.1.9/32
POS2/0/0
11.1.1.1/24
POS2/0/0
10.1.1.1/24
GE1/0/0
100.1.1.2/24
Spoke-PE1
Loopback1
3.3.3.9/32
Loopback1
2.2.2.9/32
Backbone
Spoke-PE2 GE1/0/0
120.1.1.2/24
AS100
GE1/0/0
100.1.1.1/24
AS: 65410
AS: 65420
Spoke-CE1
Spoke-CE2
Loopback1
11.11.11.11/32
GE1/0/0
120.1.1.1/24
Loopback1
22.22.22.22/32
Configuration Notes
When configuring Hub and Spoke, note the following:
l
The import target and export target configured on a Spoke-PE are different.
Two VPN instances (vpn_in and vpn_out) are created on the Hub-PE. The VPN targets
received by vpn_in are the VPN targets advertised by the two Spoke-PEs; the VPN targets
advertised by vpn_out are the VPN targets received by the two Spoke-PEs and are different
from the VPN targets received by vpn_in.
The Hub-PE is configured to accept the routes whose AS number is repeated once in the
AS_Path attribute.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Issue 01 (2011-10-15)
Establish MP-IBGP peer relationships between the Hub-PE and Spoke-PEs. There is no
need to establish the MP-IBGP peer relationship or exchange VPN route information
between the two Spoke-PEs.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
167
2.
3.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances of the Hub-PE and Spoke-PEs
Procedure
Step 1 Configure an IGP on the MPLS backbone network for the interworking between the Hub-PE
and Spoke-PEs.
In this example, OSPF is used as the IGP protocol. For details, see "Configuration Files."
After the configuration, the OSPF neighbor relationships have been set up between the Hub-PE
and Spoke-PEs. Run the display ospf peer command, and you can view that the neighbor status
is Full. Run the display ip routing-table command, and you can view that the Hub-PE and
Spoke-PEs have learnt the routes to the loopback interface of each other.
Step 2 Configure basic MPLS functions and MPLS LDP, and set up LDP LSPs on the MPLS backbone
network.
For details, see "Configuration Files."
After the configuration, LDP neighbor relationships have been set up between the Hub-PE and
Spoke-PEs. Run the display mpls ldp session command on routers, and you can view that the
Session Status field is displayed as Operational.
Step 3 Configure VPN instances enabled with the IPv4 address family on the PEs and connect the CEs
to PEs.
NOTE
The import target of a VPN on the Hub-PE must contain the export target attributes of all Spoke-PEs.
The export target of another VPN on the Hub-PE must contain the import target attributes of all SpokePEs.
# Configure Spoke-PE1.
<Spoke-PE1> system-view
[~Spoke-PE1] ip vpn-instance vpna
[~Spoke-PE1-vpn-instance-vpna] ipv4-family
[~Spoke-PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~Spoke-PE1-vpn-instance-vpna-af-ipv4] vpn-target 100:1 export-extcommunity
[~Spoke-PE1-vpn-instance-vpna-af-ipv4] vpn-target 200:1 import-extcommunity
[~Spoke-PE1-vpn-instance-vpna-af-ipv4] commit
[~Spoke-PE1-vpn-instance-vpna-af-ipv4] quit
[~Spoke-PE1] interface gigabitethernet 1/0/0
[~Spoke-PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[~Spoke-PE1-GigabitEthernet1/0/0] ip address 100.1.1.2 24
[~Spoke-PE1-GigabitEthernet1/0/0] commit
[~Spoke-PE1-GigabitEthernet1/0/0] quit
# Configure Spoke-PE2.
<Spoke-PE2> system-view
[~Spoke-PE2] ip vpn-instance vpna
[~Spoke-PE2-vpn-instance-vpna] ipv4-family
[~Spoke-PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 100:3
Issue 01 (2011-10-15)
168
# Assign an IP address to each interface on CEs as shown in Figure 2-30. The detailed
configuration procedure is not mentioned here. For details, see "Configuration Files."
After the configuration, run the display ip vpn-instance verbose command on PEs to view the
configurations of VPN instances. Each PE can successfully ping its connected CEs by using the
ping -vpn-instance vpn-name ip-address command.
NOTE
If a PE has multiple interfaces bound to the same VPN instance, you need to specify a source IP address
by specifying -a source-ip-address in the ping -vpn-instance vpn-instance-name -a source-ip-address
dest-ip-address command to ping the CE connected to the remote PE. Otherwise, the ping operation fails.
Step 4 Set up the EBGP peer relationships between the PEs and CEs and import VPN routes.
NOTE
Configure the Hub-PE to allow the AS number to be repeated once in the AS_Path attribute to receive the
routes advertised by the Hub-CE.
You do not need to configure the Spoke-PEs to allow the AS number to be repeated once because the
router does not check the AS-Path attributes in its received routes advertised by the IBGP peer.
# Configure Spoke-CE1.
[~Spoke-CE1] interface loopback 1
[~Spoke-CE1-Loopback1] ip address 11.11.11.11 32
[~Spoke-CE1-Loopback1] quit
[~Spoke-CE1] bgp 65410
[~Spoke-CE1-bgp] peer 100.1.1.2 as-number 100
[~Spoke-CE1-bgp] network 11.11.11.11 32
[~Spoke-CE1-bgp] quit
Issue 01 (2011-10-15)
169
[~Spoke-CE1] commit
# Configure Spoke-PE1.
[~Spoke-PE1] bgp 100
[~Spoke-PE1-bgp] ipv4-family vpn-instance vpna
[~Spoke-PE1-bgp-vpna] peer 100.1.1.1 as-number 65410
[~Spoke-PE1-bgp-vpna] commit
[~Spoke-PE1-bgp-vpna] quit
[~Spoke-PE1-bgp] quit
# Configure Spoke-CE2.
[~Spoke-CE2] interface loopback 1
[~Spoke-CE2-Loopback1] ip address 22.22.22.22 32
[~Spoke-CE2-Loopback1] quit
[~Spoke-CE2] bgp 65420
[~Spoke-CE2-bgp] peer 120.1.1.2 as-number 100
[~Spoke-CE2-bgp] network 22.22.22.22 32
[~Spoke-CE2-bgp] commit
[~Spoke-CE2-bgp] quit
# Configure Spoke-PE2.
[~Spoke-PE2] bgp 100
[~Spoke-PE2-bgp] ipv4-family vpn-instance vpna
[~Spoke-PE2-bgp-vpna] peer 120.1.1.1 as-number 65420
[~Spoke-PE2-bgp-vpna] commit
[~Spoke-PE2-bgp-vpna] quit
[~Spoke-PE2-bgp] quit
After the configuration, run the display bgp vpnv4 all peer command on the PEs. You can find
that BGP peer relationships have been established between PEs and CEs.
Step 5 Set up MP-IBGP peer relationships between the PEs.
# Configure Spoke-PE1.
[~Spoke-PE1] bgp 100
[~Spoke-PE1-bgp] peer 2.2.2.9 as-number 100
[~Spoke-PE1-bgp] peer 2.2.2.9 connect-interface loopback 1
[~Spoke-PE1-bgp] ipv4-family vpnv4
[~Spoke-PE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[~Spoke-PE1-bgp-af-vpnv4] commit
Issue 01 (2011-10-15)
170
[~Spoke-PE1-bgp-af-vpnv4] quit
# Configure Spoke-PE2.
[~Spoke-PE2] bgp 100
[~Spoke-PE2-bgp] peer 2.2.2.9 as-number 100
[~Spoke-PE2-bgp] peer 2.2.2.9 connect-interface loopback 1
[~Spoke-PE2-bgp] ipv4-family vpnv4
[~Spoke-PE2-bgp-af-vpnv4] peer 2.2.2.9 enable
[~Spoke-PE2-bgp-af-vpnv4] commit
[~Spoke-PE2-bgp-af-vpnv4] quit
After the configuration, run the display bgp peer or display bgp vpnv4 all peer command on
the PEs, and you can view that the BGP peer relationships have been established between the
PEs.
Step 6 Verify the configuration.
After the configuration, the Spoke-CEs can successfully ping each other. Run the tracert
command, and you can view that the traffic between the Spoke-CEs is forwarded through the
Hub-CE. You can also deduce the number of forwarding devices between the Spoke-CEs based
on the TTL displayed in the ping command output.
Take the display on Spoke-CE1 as an example.
<Spoke-CE1> ping -a 11.11.11.11.11 22.22.22.22
PING 22.22.22.22: 56 data bytes, press CTRL_C to break
Reply from 22.22.22.22: bytes=56 Sequence=1 ttl=250ime=80 ms
Reply from 22.22.22.22: bytes=56 Sequence=2 ttl=250ime=129 ms
Reply from 22.22.22.22: bytes=56 Sequence=3 ttl=250 time=132 ms
Reply from 22.22.22.22: bytes=56 Sequence=4 ttl=250 time=92 ms
Reply from 22.22.22.22: bytes=56 Sequence=5 ttl=250 time=126 ms
--- 22.22.22.22 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 80/111/132 ms
<Spoke-CE1> tracert -a 11.11.11.11 22.22.22.22
traceroute to 22.22.22.22(22.22.22.22), max hops: 30 ,packet length: 40
1 100.1.1.2 8 ms 2 ms 2 ms
2 110.1.1.2 < AS=100 > 3 ms 2 ms 2 ms
3 110.1.1.1 < AS=100 > 3 ms 2 ms 2 ms
4 110.2.1.2 < AS=65430 > 3 ms 2 ms 2 ms
5 120.1.1.2 < AS=100 > 6 ms 6 ms 6 ms
6 22.22.22.22 < AS=65420 > 6 ms 6 ms 6 ms
Run the display bgp routing-table command on each Spoke-CE, and you can find that there
are repetitive AS numbers in the AS-Path attributes of the BGP routes to the peer Spoke-CE.
Take the display on Spoke-CE1 as an example.
<Spoke-CE1> display bgp routing-table
BGP Local router ID is 11.11.11.11
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Issue 01 (2011-10-15)
171
----End
Configuration Files
l
Issue 01 (2011-10-15)
172
Issue 01 (2011-10-15)
173
#
return
Issue 01 (2011-10-15)
174
#
mpls ldp
#
interface GigabitEthernet3/0/0
undo shutdown
ip binding vpn-instance vpn_in
ip address 110.1.1.2 255.255.255.0
#
interface GigabitEthernet4/0/0
undo shutdown
ip binding vpn-instance vpn_out
ip address 110.2.1.2 255.255.255.0
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 11.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpn_in
peer 110.1.1.1 as-number 65430
#
ipv4-family vpn-instance vpn_out
peer 110.2.1.1 as-number 65430
peer 110.2.1.1 allow-as-loop
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 11.1.1.0 0.0.0.255
#
return
Related Tasks
2.6 Configuring Hub and Spoke
175
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-31, CE1 and CE3 belong to vpna; CE2 belongs to vpnb. By default,
devices in different VPNs cannot communicate with each other. In some scenarios, however,
devices in different VPNs need to communicate with each other. In this case, you can configure
VPN targets for the communication between CE2 and CE3.
Figure 2-31 Networking diagram of extranet VPN
Loopback1
33.33.33.33/32
CE3
AS: 65430
GE1/0/0
110.1.1.1/24
vpna
GE3/0/0
110.1.1.2/24
PE3
POS2/0/0
11.1.1.2/24
POS1/0/0
10.1.1.2/24
Loopback1
1.1.1.9/32
GE1/0/0
100.1.1.2/24
Loopback1
3.3.3.9/32
Loopback1
2.2.2.9/32
POS2/0/0
10.1.1.1/24
PE1
POS2/0/0
11.1.1.1/24
PE2
Backbone
GE1/0/0
120.1.1.2/24
AS100
GE1/0/0
100.1.1.1/24
CE1
vpna
AS: 65410
vpnb
AS: 65420
GE1/0/0
120.1.1.1/24
CE2
Loopback1
11.11.11.11/32
Loopback1
22.22.22.22/32
Configuration Notes
When configuring extranet VPN, note the following:
Issue 01 (2011-10-15)
176
The import VPN target list of PE3 contains the export VPN targets of PE1 and PE2; the
export VPN target list of PE3 contains the import VPN targets of PE1 and PE2.
Configuration Roadmap
The configuration roadmap is as follows:
1.
2.
Configure MPLS and MPLS LSPs on the MPLS backbone network so that PEs can
communicate through the LSPs.
3.
Establish MP-IBGP peer relationships between PE1 and PE3, and between PE2 and PE3.
4.
Create VPN instances on the PEs, ensuring that the import VPN target list of PE3 contains
the export VPN targets of the other PEs and the export VPN target list of PE3 contains the
import VPN targets of the other PEs
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances created on PE1 and PE2
Configuration Procedures
1.
Configure an IGP on the MPLS backbone network so that PEs can learn the routes to the
loopback interface of each other. In this example, OSPF is used as the IGP protocol. For
details, see "Configuration Files."
After the configuration, the OSPF neighbor relationships can be established between the
PEs. Run the display ospf peer command, and you can view that the neighbor relationship
is in the Full state. Run the display ip routing-table command, and you can view that PEs
have learnt the routes to the loopback interface of each other.
2.
# Configure PE2.
[~PE2] mpls lsr-id 3.3.3.9
[~PE2] mpls
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] quit
[~PE2] interface pos 2/0/0
[~PE2-Pos2/0/0] mpls
[~PE2-Pos2/0/0] mpls ldp
[~PE2-Pos2/0/0] commit
[~PE2-Pos2/0/0] quit
Issue 01 (2011-10-15)
177
# Configure PE3.
[~PE3] mpls lsr-id 2.2.2.9
[~PE3] mpls
[~PE3-mpls] quit
[~PE3] mpls ldp
[~PE3-mpls-ldp] quit
[~PE3] interface pos 1/0/0
[~PE3-Pos1/0/0] mpls
[~PE3-Pos1/0/0] mpls ldp
[~PE3-Pos1/0/0] commit
[~PE3-Pos1/0/0] quit
[~PE3] interface pos 2/0/0
[~PE3-Pos2/0/0] mpls
[~PE3-Pos2/0/0] mpls ldp
[~PE3-Pos2/0/0] commit
[~PE3-Pos2/0/0] quit
After the configuration, the LDP sessions can be established between the PEs. Run the
display mpls ldp session command on each device, and you can view that the Status field
is displayed as Operational. Take the display on PE1 as an example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
------------------------------------------------------------------------2.2.2.9:0
Operational DU
Passive 0000:00:01 5/5
3.3.3.9:0
Operational DU
Passive 0000:00:01 5/5
------------------------------------------------------------------------TOTAL: 2 session(s) Found.
3.
Establish MP-IBGP peer relationships between PE1 and PE3, and between PE2 and PE3.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] peer 2.2.2.9 as-number 100
[~PE1-bgp] peer 2.2.2.9 connect-interface loopback 1
[~PE1-bgp] ipv4-family vpnv4
[~PE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[~PE1-bgp-af-vpnv4] commit
[~PE1-bgp-af-vpnv4] quit
[~PE1-bgp] quit
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 2.2.2.9 as-number 100
[~PE2-bgp] peer 2.2.2.9 connect-interface loopback 1
[~PE2-bgp] ipv4-family vpnv4
[~PE2-bgp-af-vpnv4] peer 2.2.2.9 enable
[~PE2-bgp-af-vpnv4] commit
[~PE2-bgp-af-vpnv4] quit
[~PE2-bgp] quit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] peer 1.1.1.9 as-number 100
[~PE3-bgp] peer 3.3.3.9 connect-interface loopback 1
[~PE3-bgp] ipv4-family vpnv4
[~PE3-bgp-af-vpnv4] peer 1.1.1.9 enable
[~PE3-bgp-af-vpnv4] peer 3.3.3.9 enable
[~PE3-bgp-af-vpnv4] commit
[~PE3-bgp-af-vpnv4] quit
[~PE3-bgp] quit
After the configuration, run the display bgp vpnv4 all peer command on the PEs, and you
can view that MP-IBGP peer relationships have been established between PEs and CEs.
Take the display on PE1 as an example.
Issue 01 (2011-10-15)
178
4.
MsgSent
18
00:09:38
Established
Create VPN instances on the PEs, ensuring that the import VPN target list of PE3 contains
the export VPN targets of the other PEs and the export VPN target list of PE3 contains the
import VPN targets of the other PEs
# Configure PE1.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE1-vpn-instance-vpna-af-ipv4] commit
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] interface gigabitethernet 1/0/0
[~PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[~PE1-GigabitEthernet1/0/0] ip address 100.1.1.2 24
[~PE1-GigabitEthernet1/0/0] commit
[~PE1-GigabitEthernet1/0/0] quit
# Configure PE2.
[~PE2] ip vpn-instance vpnb
[~PE2-vpn-instance-vpnb] ipv4-family
[~PE2-vpn-instance-vpnb-af-ipv4] route-distinguisher 100:2
[~PE2-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[~PE2-vpn-instance-vpnb-af-ipv4] commit
[~PE2-vpn-instance-vpnb-af-ipv4] quit
[~PE2-vpn-instance-vpnb] quit
[~PE2] interface gigabitethernet 1/0/0
[~PE2-GigabitEthernet1/0/0] ip binding vpn-instance vpnb
[~PE2-GigabitEthernet1/0/0] ip address 120.1.1.2 24
[~PE2-GigabitEthernet1/0/0] commit
[~PE2-GigabitEthernet1/0/0] quit
# Configure PE3.
[~PE3] ip vpn-instance vpna
[~PE3-vpn-instance-vpna] ipv4-family
[~PE3-vpn-instance-vpna-af-ipv4] route-distinguisher 100:3
[~PE3-vpn-instance-vpna-af-ipv4] vpn-target 111:1 222:2 both
[~PE3-vpn-instance-vpna-af-ipv4] commit
[~PE3-vpn-instance-vpna-af-ipv4] quit
[~PE3-vpn-instance-vpna] quit
[~PE3] interface gigabitethernet 3/0/0
[~PE3-GigabitEthernet3/0/0] ip binding vpn-instance vpna
[~PE3-GigabitEthernet3/0/0] ip address 110.1.1.2 24
[~PE3-GigabitEthernet3/0/0] commit
[~PE3-GigabitEthernet3/0/0] quit
5.
Set up the EBGP peer relationships between the PEs and CEs and import VPN routes.
# Configure CE1.
[~CE1] interface loopback 1
[~CE1-Loopback1] ip address 11.11.11.11 32
[~CE1-Loopback1] quit
[~CE1] bgp 65410
[~CE1-bgp] peer 100.1.1.2 as-number 100
[~CE1-bgp] network 11.11.11.11 32
[~CE1-bgp] commit
The configurations of CE2 and CE3 are similar to the configuration of CE1, and are not
mentioned here. For details, see "Configuration Files."
# Configure PE1.
Issue 01 (2011-10-15)
179
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not
mentioned here. For details, see "Configuration Files."
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the
PEs, and you can view that BGP peer relationships have been established between PEs and
CEs.
Take the peer relationship between PE1 and CE1 as an example.
<PE1> display bgp vpnv4 vpn-instance vpna peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V
AS MsgRcvd MsgSent
OutQ Up/Down
State
PrefRcv
100.1.1.1
4
65410 11
9
0
00:06:37
Established
6.
CE2 can successfully ping CE3 at 33.33.33.33 but cannot successfully ping CE1 at
22.22.22.22.
[~CE1] ping -a 11.11.11.11 33.33.33.33
PING 33.33.33.33: 56 data bytes, press CTRL_C to break
Reply from 33.33.33.33: bytes=56 Sequence=1 ttl=253 time=72
Reply from 33.33.33.33: bytes=56 Sequence=2 ttl=253 time=34
Reply from 33.33.33.33: bytes=56 Sequence=3 ttl=253 time=50
Reply from 33.33.33.33: bytes=56 Sequence=4 ttl=253 time=50
Reply from 33.33.33.33: bytes=56 Sequence=5 ttl=253 time=34
--- 33.33.33.33 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 34/48/72 ms
[~CE1] ping -a 11.11.11.11 22.22.22.22
PING 22.22.22.22: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 22.22.22.22 ping statistics --5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
ms
ms
ms
ms
ms
Configuration Files
l
Issue 01 (2011-10-15)
180
sysname CE1
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 100.1.1.1 255.255.255.0
#
interface Loopback 1
undo shutdown
ip address 11.11.11.11 255.255.255.255
#
bgp 65410
peer 100.1.1.2 as-number 100
network 11.11.11.11 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 100.1.1.2 enable
#
return
Issue 01 (2011-10-15)
181
#
return
Issue 01 (2011-10-15)
182
Issue 01 (2011-10-15)
183
#
return
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
If multiple tunnels such as LDP LSPs and TE tunnels exist between PE peers on the MPLS
backbone network of a BGP/MPLS IP VPN, load balancing among tunnels can be configured
to distribute IPv6 VPN traffic to the tunnels and prevent network congestion.
As shown in Figure 2-32, two links exist between PE1 and PE2 in the basic BGP/MPLS IP VPN
networking: an LDP LSP (PE1-P1-PE2) and a TE tunnel (PE1-P2-PE2). All VPN traffic is
forwarded over the LSP according to the default tunnel policy, which may cause the link of PE1P1-PE2 to be busy and the link of PE1-P2-PE2 to be idle.
To address this problem, load balancing among tunnels can be configured on the MPLS backbone
network to distribute VPN traffic evenly to the two tunnels.
Issue 01 (2011-10-15)
184
Figure 2-32 Networking diagram for configuring load balancing among tunnels to which remote
cross routes are iterated on a VPN
Loopback1
2.2.2.9/32
/0
1/ 0 / 24
S
PO .1.2
.1
20
Loopback1
1.1.1.9/32
PE1
P1
/0
2/0 /24
S
PO .1.1
.1
20
GE3/0/0
PO
PO
10 S1/0
10 S1/0
.1.
.1.
1.2 /0
1 /0
/24
Loopback2 .1/24
11.11.11.11/32
Backbone
AS 100
PO
30 S2/
.1.
0
1.1 /0
Loopback1
/24
Loopback1
22.22.22.22/32
3.3.3.9/32
PO
30 S2
GE1/0/0
.1. /0/
PE2
1.2 0
192.168.1.2/30
/24
P2
192.168.1.1/30
/0
0
1 /0 /2 4
/0/ 4
S
1
1
O
.
2
S
/
P 1 .1
.
P O 1. 1. 2
40
.
0
4
CE2
Loopback1
4.4.4.9/32
Configuration Notes
When configuring load balancing among tunnels to which remote cross routes are iterated on a
VPN, note the following item:
l
The tunnels existing in the system meet the requirements of the configured tunnel policy.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure OSPF on the MPLS backbone network for IP connectivity between devices on
the backbone network.
2.
On the MPLS backbone network, enable MPLS and MPLS LDP to set up an LDP LSP;
enable MPLS TE to set up an MPLS TE tunnel.
3.
4.
Create a tunnel policy on PE1 to distribute traffic to the LDP LSP and TE tunnel between
PE1 and PE2.
5.
Apply the tunnel policy to the VPN instance IPv4 address family on PE1.
Procedure
Step 1 Configure a basic BGP/MPLS IP VPN.
For details on the configuration procedure, see Example for Configuring Basic BGP/MPLS
IP VPN. The main configurations are listed below:
l Configure OSPF on the MPLS backbone network to allow the PEs to learn the route to each
other's loopback interface.
l Configure basic MPLS functions and enable MPLS LDP on PE1, P1, and PE2 to set up an
LDP LSP along the PEs.
Issue 01 (2011-10-15)
185
l Enable MPLS TE on PE1, P2, and PE2 to set up an MPLS TE tunnel along the PEs.
l Establish a VPNv4 peer relationship between the PEs.
l Create a VPN instance that supports the IPv4 address family on each PE and bind the PE
interface connecting to the CE to the VPN instance.
l Enable BGP between the PEs and CE, and import the route of the loopback interface into
BGP on the CE.
After the configuration is complete, run the display ip routing-table vpn-instance command
on PE1. You can find that PE1 has learned the route to the loopback interface on the CE.
<PE1> display ip routing-table vpn-instance vpn1
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpn1
Destinations : 4
Routes : 4
Destination/Mask
Proto
Pre
Cost
Flags NextHop
Interface
11.11.11.11/32 Direct 0
0
D 127.0.0.1
LoopBack2
22.22.22.22/32 BGP
255 0
RD 3.3.3.9
LDP LSP
192.168.1.0/30 BGP
255 0
RD 3.3.3.9
LDP LSP
192.168.1.2/32 BGP
255 0
RD 3.3.3.9
LDP LSP
<PE1> display ip routing-table vpn-instance vpn1 22.22.22.22 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpn1
Summary Count : 1
Destination: 22.22.22.22/32
Protocol: BGP
Process ID:
Preference: 255
Cost:
NextHop: 3.3.3.9
Neighbour:
State: Active Adv Relied
Age:
Tag: 0
Priority:
Label: 0x1f
QoSInfo:
IndirectID: 0xb7
RelayNextHop: 0.0.0.0
Interface:
TunnelID: 0x0000000001004c4b43 Flags:
0
0
0.0.0.0
00h02m28s
low
0x0
LDP LSP
RD
The command output shows that the route to 22.22.22.22/32 is iterated to only one LSP on PE1
because no tunnel policy is applied to the VPN.
Step 2 Apply a tunnel policy to the VPN on PE1.
Configure a tunnel policy in select-sequence mode to make tunnels be selected in the order of
TE tunnels and LSPs and to set the number of tunnels participating in load balancing to 2.
# Configure PE1.
[~PE1] tunnel-policy te-lsp-l2
[~PE1-tunnel-policy-te-lsp-l2] tunnel select-seq cr-lsp lsp load-balance-number 2
[~PE1-tunnel-policy-te-lsp-l2] quit
186
After the configuration is complete, run the display ip routing-table vpn-instance verbose
command on PE1. You can find that the route to the loopback interface on the CE is iterated to
two tunnels.
<PE1> display ip routing-table vpn-instance vpn1 22.22.22.22 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpn1
Summary Count : 1
Destination: 22.22.22.22/32
Protocol: BGP
Process ID:
Preference: 255
Cost:
NextHop: 3.3.3.9
Neighbour:
State: Active Adv Relied
Age:
Tag: 0
Priority:
Label: 0x1f
QoSInfo:
IndirectID: 0xbc
RelayNextHop: 0.0.0.0
Interface:
TunnelID: 0x000000000300000001 Flags:
RelayNextHop: 0.0.0.0
Interface:
TunnelID: 0x0000000001004c4b43 Flags:
0
0
0.0.0.0
00h00m06s
low
0x0
Tunnel1
RD
LDP LSP
RD
Load balancing between tunnels to which remote cross routes are iterated is successfully
deployed on the VPN.
----End
Configuration Files
l
Issue 01 (2011-10-15)
187
#
interface LoopBack2
ip binding vpn-instance vpn1
ip address 11.11.11.11 255.255.255.255
#
interface Tunnel1
ip address unnumbered interface LoopBack1
tunnel-protocol mpls te
destination 3.3.3.9
mpls te tunnel-id 100
#
bgp 100
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
tunnel-policy te-lsp-l2
tunnel select-seq cr-lsp lsp load-balance-number 2
#
return
Configuration file of P1
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 30.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 2.2.2.9 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
Issue 01 (2011-10-15)
188
#
return
Configuration file of P2
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 40.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 4.4.4.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
189
mpls rsvp-te
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 30.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface GigabitEthernet3/0/0
undo shutdown
ip binding vpn-instance vpn1
ip address 192.168.1.1 255.255.255.252
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
ipv4-family vpn-instance vpn1
peer 192.168.1.2 as-number 65410
#
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 3.3.3.9 0.0.0.0
network 30.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
#
return
Related Tasks
2.7 Configuring a Tunnel Policy for the Backbone Network of a BGP/MPLS IP VPN
Issue 01 (2011-10-15)
190
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-33, CE1 and CE2 belong to the same VPN. CE1 is connected to PE1 in
AS 100, and CE2 is connected to PE2 in AS 200.
It is required that inter-AS BGP/MPLS IP VPN be implemented through Option A. That is,
VRF-to-VRF is required to manage VPN routes.
Figure 2-33 Networking diagram of inter-AS VPN Option A
BGP/MPLS Backbone
AS 100
Loopback1
2.2.2.9/32
POS1/0/0
POS2/0/0
172.1.1.1/24
192.1.1.1/24
Loopback1
ASBR1
1.1.1.9/32
POS1/0/0
172.1.1.2/24
PE1
BGP/MPLS Backbone
AS 200
Loopback1
3.3.3.9/32
POS2/0/0
192.1.1.2/24
GE2/0/0
10.1.1.2/24
GE1/0/0
10.1.1.1/24
CE1
AS 65001
Loopback1
11.11.11.11/32
POS1/0/0
162.1.1.1/24
Loopback1
ASBR2
4.4.4.9/32
POS1/0/0
PE2
162.1.1.2/24
GE2/0/0
10.2.1.2/24
GE1/0/0
10.2.1.1/24
CE2
AS 65002
Loopback1
22.22.22.22/32
Configuration Roadmap
The configuration roadmap is as follows:
Issue 01 (2011-10-15)
191
1.
Set up EBGP peer relationships between the PEs and CEs and set up MP-IBGP peer
relationships between the PEs and ASBRs.
2.
Create a VPN instance on each ASBR and bind the VPN instance to the interface that
connects one ASBR to the other, and then set up an EBGP peer relationship between the
ASBRs.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances of the PEs and ASBRs
Procedure
Step 1 On the MPLS backbone networks in AS 100 and AS 200, configure an IGP to interconnect the
PE and ASBR on each network.
In this example, OSPF is used as the IGP protocol. For details, see "Configuration Files."
NOTE
The 32-bit IP address of the loopback interface that functions as the LSR ID needs to be advertised by
using OSPF.
After the configuration, the OSPF neighbor relationship can be established between the ASBR
and PE in the same AS. Run the display ospf peercommand , and you can view that the neighbor
relationship is in the Full state.
The ASBR and PE in the same AS can learn and successfully ping the IP address of the loopback
interface of each other.
Step 2 Configure basic MPLS functions and MPLS LDP, and set up MPLS LDP LSPs on the MPLS
backbone network in AS 100 and AS 200.
# Configure basic MPLS functions on PE1 and enable LDP on the interface that connects PE1
to ASBR1.
<PE1> system-view
[~PE1] mpls lsr-id 1.1.1.9
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos1/0/0
[~PE1-Pos1/0/0] mpls
[~PE1-Pos1/0/0] mpls ldp
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
# Configure basic MPLS functions on ASBR1 and enable LDP on the interface that connects
ASBR1 to PE1.
<ASBR1> system-view
[~ASBR1] mpls lsr-id 2.2.2.9
[~ASBR1] mpls
[~ASBR1-mpls] quit
[~ASBR1] mpls ldp
[~ASBR1-mpls-ldp] quit
[~ASBR1] interface pos1/0/0
[~ASBR1-Pos1/0/0] mpls
[~ASBR1-Pos1/0/0] mpls ldp
Issue 01 (2011-10-15)
192
[~ASBR1-Pos1/0/0] commit
[~ASBR1-Pos1/0/0] quit
# Configure basic MPLS functions on ASBR2 and enable LDP on the interface that connects
ASBR2 to PE2.
<ASBR2> system-view
[~ASBR2] mpls lsr-id 3.3.3.9
[~ASBR2] mpls
[~ASBR2-mpls] quit
[~ASBR2] mpls ldp
[~ASBR2-mpls-ldp] quit
[~ASBR2] interface pos1/0/0
[~ASBR2-Pos1/0/0] mpls
[~ASBR2-Pos1/0/0] mpls ldp
[~ASBR2-Pos1/0/0] commit
[~ASBR2-Pos1/0/0] quit
# Configure basic MPLS functions on PE2 and enable LDP on the interface that connects PE2
to ASBR2.
<PE2> system-view
[~PE2] mpls lsr-id 4.4.4.9
[~PE2] mpls
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] quit
[~PE2] interface pos1/0/0
[~PE2-Pos1/0/0] mpls
[~PE2-Pos1/0/0] mpls ldp
[~PE2-Pos1/0/0] commit
[~PE2-Pos1/0/0] quit
After the configuration, the LDP session is established between the PE and ASBR in the same
AS. Run the display mpls ldp session command on the PEs and ASBRs, and you can view that
the Status field is displayed as Operational.
Take the display on PE1 as an example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
-------------------------------------------------------------------------Peer-ID
Status
LAM SsnRole SsnAge
KA-Sent/Rcv
-------------------------------------------------------------------------2.2.2.9:0
Operational DU
Passive 000:00:02
9/9
-------------------------------------------------------------------------TOTAL: 1 session(s) Found.
LAM : Label Advertisement Mode
SsnAge Unit : DDD:HH:MM
The VPN targets of the VPN instances of the ASBR and PE in an AS must be the same. The VPN targets
of the VPN instances of the ASBR and PE in different ASs can be different.
# Configure CE1.
<CE1> system-view
[~CE1] interface gigabitethernet 1/0/0
[~CE1-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[~CE1-GigabitEthernet1/0/0] quit
[~CE1] interface loopback 1
[~CE1-Loopback1] ip address 11.11.11.11 32
[~CE1-Loopback1] quit
[~CE1] bgp 65001
[~CE1-bgp] peer 10.1.1.2 as-number 100
[~CE1-bgp] network 11.11.11.11 32
[~CE1-bgp] quit
Issue 01 (2011-10-15)
193
[~CE1] commit
The configurations of CE2, PE2, and ASBR2 are similar to the configurations of CE1, PE1, and ASBR1
respectively, and are not mentioned here.
After the configuration, run the display bgp vpnv4 vpn-instance vpn-instancename peer
command on the PEs, and you can view that BGP peer relationships have been established
between PEs and CEs. Run the display bgp vpnv4 all peer command, and you can view that
the BGP peer relationships have been established between each PE and CE, and between each
PE and ASBR.
Take the display on PE1 as an example.
<PE1> display bgp vpnv4 vpn-instance vpn1 peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V AS MsgRcvd MsgSent OutQ Up/Down
State
PrefRcv
10.1.1.1 4 65001
10
10
0 00:07:10 Established
0
<PE1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 2
Peers in established state : 2
Peer
V
AS MsgRcvd MsgSent OutQ Up/Down
State PrefRcv
2.2.2.9
4
100
3
7
0 00:01:36 Established
0
Peer of vpn instance:
Issue 01 (2011-10-15)
194
13
0 00:04:00 Established
# On ASBR2, create a VPN instance and bind it to the interface that connects ASBR2 to ASBR1
(ASBR2 regards ASBR1 as its CE).
[~ASBR2] ip vpn-instance vpn1
[~ASBR2-vpn-instance-vpn1] ipv4-family
[~ASBR2-vpn-instance-vpn1-af-ipv4] route-distinguisher 200:2
[~ASBR2-vpn-instance-vpn1-af-ipv4] vpn-target 2:2 both
[~ASBR2-vpn-instance-vpn1-af-ipv4] commit
[~ASBR2-vpn-instance-vpn1-af-ipv4] quit
[~ASBR2-vpn-instance-vpn1] quit
[~ASBR2] interface pos 2/0/0
[~ASBR2-Pos2/0/0] ip binding vpn-instance vpn1
[~ASBR2-Pos2/0/0] ip address 192.1.1.2 24
[~ASBR2-Pos2/0/0] commit
[~ASBR2-Pos2/0/0] quit
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the ASBRs,
and you can view that BGP peer relationships have been established between the ASBRs.
Step 5 Verify the configuration.
After the configuration, CEs can learn routes from each other, and CE1 and CE2 can ping each
other successfully.
Take the display on CE1 as an example.
<CE1> display ip routing-table
Route Flags: R - relay, D - download for forwarding
------------------------------------------------------------------------------
Issue 01 (2011-10-15)
195
Run the display ip routing-table vpn-instance command on an ASBR, and you can view the
VPN routing table on the ASBR.
<ASBR1> display ip routing-table vpn-instance vpn1
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: vpn1
Destinations : 5
Routes : 5
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
11.11.11.11/32 BGP
255 0
RD 1.1.1.9
Pos1/0/0
22.22.22.22/32 BGP
255 0
D 192.1.1.2
Pos2/0/0
192.1.1.0/24 Direct 0
0
D 192.1.1.1
Pos2/0/0
192.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
192.1.1.2/32 Direct 0
0
D 192.1.1.2
Pos2/0/0
Run the display bgp vpnv4 all routing-table command on an ASBR, and you can view the
VPNv4 routes on the ASBR.
<ASBR1> display bgp vpnv4 all routing-table
Local AS number : 100
BGP Local router ID is 2.2.2.9
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 1
Route Distinguisher: 100:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 11.11.11.11/32
1.1.1.9
0
100
0
?
VPN-Instance vpn1, router ID 2.2.2.9:
Total Number of Routes:
Network
*>i 11.11.11.11/32
*> 22.22.22.22/32
*>
192.1.1.0
*
*>
192.1.1.1/32
*
*>
192.1.1.2/32
7
NextHop
1.1.1.9
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
192.1.1.2
0.0.0.0
MED
0
LocPrf
100
0
0
0
0
0
PrefVal Path/Ogn
0
65001?
0
?
0
?
0
200?
0
?
0
200?
0
?
----End
Configuration Files
l
Issue 01 (2011-10-15)
196
#
sysname CE1
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface Loopback 1
undo shutdown
ip address 11.11.11.11 255.255.255.255
#
bgp 65001
peer 10.1.1.2 as-number 100
network 11.11.11.11 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.1.1.2 enable
#
return
Issue 01 (2011-10-15)
197
Issue 01 (2011-10-15)
198
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 162.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpn1
ip address 192.1.1.2 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 200
peer 4.4.4.9 as-number 200
peer 4.4.4.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 4.4.4.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 4.4.4.9 enable
#
ipv4-family vpn-instance vpn1
peer 192.1.1.1 as-number 100
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
199
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
bgp 200
peer 3.3.3.9 as-number 200
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpn1
peer 10.2.1.1 as-number 65002
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return
Related Tasks
2.8 Configuring Inter-AS VPN Option A
Issue 01 (2011-10-15)
200
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-34, CE1 and CE2 belong to the same VPN. CE1 is connected to PE1 in
AS 100, and CE2 is connected to PE2 in AS 200. It is required that an MP-EBGP peer relationship
be established between the ASBRs to transmit VPNv4 routes, thus implementing inter-AS VPN
Option B.
Figure 2-34 Networking diagram of inter-AS VPN Option B with basic networking
BGP/MPLS Backbone
AS 100
Loopback1
2.2.2.9/32
POS1/0/0
POS2/0/0
172.1.1.1/24
192.1.1.1/24
Loopback1
ASBR1
1.1.1.9/32
BGP/MPLS Backbone
AS 200
Loopback1
3.3.3.9/32
POS2/0/0
192.1.1.2/24
POS1/0/0
172.1.1.2/24
PE1
GE2/0/0
10.1.1.2/24
GE1/0/0
10.1.1.1/24
CE1
AS 65001
Loopback1
11.11.11.11/32
POS1/0/0
162.1.1.1/24
Loopback1
ASBR2
4.4.4.9/32
POS1/0/0
PE2
162.1.1.2/24
GE2/0/0
10.2.1.2/24
GE1/0/0
10.2.1.1/24
CE2
AS 65002
Loopback1
22.22.22.22/32
Configuration Notes
When configuring inter-AS VPN Option B with basic networking, note the following:
l
An MP-EBGP peer relationship is established between ASBR1 and ASBR2, and the
ASBRs do not filter received VPNv4 routes based on VPN targets.
Configuration Roadmap
The configuration roadmap is as follows:
Issue 01 (2011-10-15)
201
1.
Configure an IGP on the MPLS backbone network to implement interworking of the ASBR
and PE in the same AS, and set up an MPLS LDP LSP between the ASBR and PE in the
same AS.
2.
Set up EBGP peer relationships between the PEs and CEs and set up MP-IBGP peer
relationships between the PEs and ASBRs.
3.
4.
Enable MPLS on the interface that connects one ASBR to the other ASBR, set up an MPEBGP peer relationship between the ASBRs, and configure the ASBRs not to filter received
VPNv4 routes based on VPN targets.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances of the PEs
Procedure
Step 1 On the MPLS backbone networks in AS 100 and AS 200, configure an IGP to interconnect the
PE and ASBR on each network.
In this example, OSPF is used as the IGP protocol. For details, see "Configuration Files."
NOTE
The 32-bit IP address of the loopback interface that functions as the LSR ID needs to be advertised by
using OSPF.
After the configuration, the OSPF neighbor relationship can be established between the ASBR
and PE in the same AS. Run the display ospf peer command, and you can view that the neighbor
relationship is in the Full state.
The ASBR and PE in the same AS can learn and successfully ping the IP address of the loopback
interface of each other.
Step 2 Configure basic MPLS functions and MPLS LDP, and set up MPLS LDP LSPs on the MPLS
backbone networks in AS 100 and AS 200.
The detailed configuration is not mentioned here. For details, see 2.18.10 Example for
Configuring Inter-AS VPN Option A.
Step 3 Configure the basic BGP/MPLS IP VPN functions on PE1 and PE2.
NOTE
The VPN targets of the VPN instances of PE1 and PE2 must be the same.
The detailed configuration is not mentioned here. For details, see "Configuration Files."
Step 4 Configure inter-AS VPN Option B.
# On ASBR1, set up an MP-EBGP peer relationship between ASBR1 and ASBR2, and configure
ASBR1 not to filter received VPNv4 routes based on VPN targets.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 192.1.1.2 as-number 200
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 192.1.1.2 enable
Issue 01 (2011-10-15)
202
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here.
Step 5 Verify the configuration.
After the configuration, CEs can learn routes to the loopback interface of each other, and CE1
and CE2 can ping each other successfully.
Take the display on CE1 as an example.
<CE1> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 5
Routes : 5
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24 Direct 0
0
D 10.1.1.1
GigabitEthernet1/0/0
10.1.1.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
22.22.22.22/32 BGP
255 0
D 10.1.1.2
GigabitEthernet1/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
<CE1> ping -a 11.11.11.11 22.22.22.22
PING 22.22.22.22: 56 data bytes, press CTRL_C to break
Reply from 22.22.22.22: bytes=56 Sequence=1 ttl=252 time=120 ms
Reply from 22.22.22.22: bytes=56 Sequence=2 ttl=252 time=73 ms
Reply from 22.22.22.22: bytes=56 Sequence=3 ttl=252 time=111 ms
Reply from 22.22.22.22: bytes=56 Sequence=4 ttl=252 time=86 ms
Reply from 22.22.22.22: bytes=56 Sequence=5 ttl=252 time=110 ms
--- 22.22.22.22 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 73/100/120 ms
Run the display bgp vpnv4 all routing-table command on an ASBR, and you can view the
VPNv4 routes on the ASBR.
Take the display on ASBR1 as an example.
<ASBR1> display bgp vpnv4 all routing-table
Local AS number : 100
BGP Local router ID is 2.2.2.9
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 2
Route Distinguisher: 100:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 11.11.11.11/32
1.1.1.9
0
100
0
?
Route Distinguisher: 200:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
22.22.22.22/32
192.1.1.2
0
200?
----End
Configuration Files
l
Issue 01 (2011-10-15)
203
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface Loopback 1
undo shutdown
ip address 11.11.11.11 255.255.255.255
#
bgp 65001
peer 10.1.1.2 as-number 100
network 11.11.11.11 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.1.1.2 enable
return
l
Issue 01 (2011-10-15)
204
#
sysname ASBR1
#
mpls lsr-id 2.2.2.9
#
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
peer 192.1.1.2 as-number 200
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 192.1.1.2 enable
peer 1.1.1.9 enable
#
ipv4-family vpnv4
undo policy vpn-target
peer 1.1.1.9 enable
peer 192.1.1.2 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
205
#
bgp 200
peer 192.1.1.1 as-number 100
peer 4.4.4.9 as-number 200
peer 4.4.4.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 192.1.1.1 enable
peer 4.4.4.9 enable
#
ipv4-family vpnv4
undo policy vpn-target
peer 4.4.4.9 enable
peer 192.1.1.1 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
206
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return
Related Tasks
2.9 Configuring Inter-AS VPN Option B (Basic Networking)
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-35, CE1, CE2, and CE3 belong to the same VPN; PE1 and PE3 are in the
same AS. It is required that inter-AS VPN Option B be configured and an RR be configured in
AS 100 to reflect VPNv4 routes between PEs and between a PE and an ASBR so as to reduce
MP-IBGP connections in AS 100.
Issue 01 (2011-10-15)
207
Loopback1
Loopback1
POS3/0/0
RR POS1/0/0
POS2/0/0
Loopback1
POS1/0/0
PE1
BGP/MPLS Backbone
AS 200
BGP/MPLS Backbone AS
100
POS1/0/0
Loopback1
Loopback1
POS2/0/0
POS1/0/0
POS2/0/0
ASBR2
ASBR1
POS1/0/0
POS1/0/0
GE1/0/0
GE1/0/0
CE1
CE2
AS 65001
AS 65002
Loopback1
Interface
IP Address
CE1
Loopback1
11.11.11.11/32
GE1/0/0
10.1.1.1/24
Loopback1
1.1.1.1/32
GE 2/0/0
10.1.1.2/24
POS 1/0/0
172.1.1.2/24
Loopback1
4.4.4.4/32
POS 1/0/0
172.1.1.1/24
POS 2/0/0
172.2.1.1/24
POS 3/0/0
172.3.1.1/24
Loopback1
33.33.33.33/32
GE 1/0/0
10.3.1.1/24
CE3
Issue 01 (2011-10-15)
Loopback1
Device
RR
PE2
GE2/0/0
GE2/0/0
PE1
Loopback1
208
Device
Interface
IP Address
PE3
Loopback1
3.3.3.3/32
GE 2/0/0
10.3.1.2/24
POS 1/0/0
172.3.1.2/24
Loopback1
5.5.5.5/32
POS 1/0/0
172.2.1.2/24
POS 2/0/0
192.1.1.1/24
Loopback1
6.6.6.6/32
POS 1/0/0
162.1.1.1/24
POS 2/0/0
192.1.1.2/24
Loopback1
22.22.22.22/32
GE 1/0/0
10.2.1.1/24
Loopback1
2.2.2.2/32
GE 2/0/0
10.2.1.2/24
POS 1/0/0
162.1.1.2/24
ASBR1
ASBR2
CE2
PE2
Configuration Notes
When configuring inter-AS VPN Option B with an RR in a AS, note the following:
l
There is no need to create VPN instances on ASBRs or configure ASBRs to filter VPNv4
routes based on VPN targets.
PE1, PE3, and ASBR1 need to be configured as clients for the RR.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP on the MPLS backbone network to implement interworking of the ASBR
and PE in the same AS, and set up an MPLS LDP LSP between the ASBR and PE in the
same AS.
2.
Set up EBGP peer relationships between the PEs and CEs and set up MP-IBGP peer
relationships between the PEs and ASBRs in the same AS.
3.
4.
Configure VPN instances on the PEs rather than ASBRs or the RR.
5.
Enable MPLS on the interface that connects one ASBR to the other ASBR, set up an MPEBGP peer relationship between the ASBRs, and configure the ASBRs not to filter received
VPNv4 routes based on VPN targets.
Issue 01 (2011-10-15)
209
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances created on PE1 and PE2
Configuration Procedures
1.
On the MPLS backbone networks in AS 100 and AS 200, configure an IGP to interconnect
the devices in the same AS. In this example, OSPF is used as the IGP protocol. For details,
see "Configuration Files."
After the configuration, the OSPF neighbor relationship can be established between the
devices in the same AS. Run the display ospf peer command, and you can view that the
neighbor relationship is in the Full state. Run the display ip routing-table command, and
you can view that PEs have learnt the routes to the loopback interface of each other.
2.
Configure basic MPLS functions and MPLS LDP, and set up MPLS LDP LSPs on the
MPLS backbone networks in AS 100 and AS 200.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos 1/0/0
[~PE1-Pos1/0/0] mpls
[~PE1-Pos1/0/0] mpls ldp
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not
mentioned here. For details, see "Configuration Files."
# Configure the RR.
[~RR] mpls lsr-id 4.4.4.4
[~RR] mpls
[~RR-mpls] quit
[~RR] mpls ldp
[~RR-mpls-ldp] quit
[~RR] interface pos 1/0/0
[~RR-Pos1/0/0] mpls
[~RR-Pos1/0/0] mpls ldp
[~RR-Pos1/0/0] quit
[~RR] interface pos 2/0/0
[~RR-Pos2/0/0] mpls
[~RR-Pos2/0/0] mpls ldp
[~RR-Pos2/0/0] quit
[~RR] interface pos 3/0/0
[~RR-Pos3/0/0] mpls
[~RR-Pos3/0/0] mpls ldp
[~RR-Pos3/0/0] quit
[~RR] commit
# Configure ASBR1.
[~ASBR1] mpls lsr-id 5.5.5.5
[~ASBR1] mpls
[~ASBR1-mpls] quit
[~ASBR1] mpls ldp
[~ASBR1-mpls-ldp] quit
[~ASBR1] interface pos 1/0/0
[~ASBR1-Pos1/0/0] mpls
Issue 01 (2011-10-15)
210
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
After the configuration, LDP sessions can be set up between PEs and the RR and between
ASBRs and the RR. Run the display mpls ldp session command on each device, and you
can view that the Status field is displayed as Operational. Take the display on PE1 as an
example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
------------------------------------------------------------------------4.4.4.4:0
Operational DU
Passive 0000:00:01 5/5
------------------------------------------------------------------------TOTAL: 1 session(s) Found.
3.
Set up MP-IBGP peer relationships between the PEs, ASBRs, and RR in AS 100; set up
an MP-IBGP peer relationship between the PE and ASBR in AS 200.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] peer 4.4.4.4 as-number 100
[~PE1-bgp] peer 4.4.4.4 connect-interface loopback 1
[~PE1-bgp] ipv4-family vpnv4
[~PE1-bgp-af-vpnv4] peer 4.4.4.4 enable
[~PE1-bgp-af-vpnv4] commit
[~PE1-bgp-af-vpnv4] quit
[~PE1-bgp] quit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not
mentioned here. For details, see "Configuration Files."
# Configure ASBR1.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 4.4.4.4 as-number 100
[~ASBR1-bgp] peer 4.4.4.4 connect-interface loopback 1
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 4.4.4.4 enable
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
Set up MP-IBGP peer relationships between the RR and PE1, PE3, and ASBR1.
[~RR] bgp 100
[~RR-bgp] peer 1.1.1.1 as-number 100
[~RR-bgp] peer 1.1.1.1 connect-interface loopback 1
[~RR-bgp] peer 3.3.3.3 as-number 100
[~RR-bgp] peer 3.3.3.3 connect-interface loopback 1
[~RR-bgp] peer 5.5.5.5 as-number 100
[~RR-bgp] peer 5.5.5.5 connect-interface loopback 1
[~RR-bgp] ipv4-family vpnv4
[~RR-bgp-af-vpnv4] peer 1.1.1.1 enable
[~RR-bgp-af-vpnv4] peer 3.3.3.3 enable
[~RR-bgp-af-vpnv4] peer 5.5.5.5 enable
[~RR-bgp-af-vpnv4] commit
[~RR-bgp-af-vpnv4] quit
[~RR-bgp] quit
After the configuration, run the display bgp peer or display bgp vpnv4 all peer command
on the PEs, RR, or ASBRs, and you can view that the BGP peer relationships have been
Issue 01 (2011-10-15)
211
established between the PEs or ASBRs and the RR in AS 100. Take the display on the RR
as an example:
<RR> display bgp
BGP local router
Local AS number
Total number of
Peer
PrefRcv
1.1.1.1
0
3.3.3.3
0
5.5.5.5
0
4.
MsgSent
100
12
18
00:09:38
Established
100
12
18
00:09:38
Established
100
12
18
00:09:38
Established
5.
Configure VPN instances on the PEs and connect the CEs to the PEs through the VPN
instances.
# Configure PE1.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] interface gigabitethernet 2/0/0
[~PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[~PE1-GigabitEthernet2/0/0] ip address 10.1.1.2 24
[~PE1-GigabitEthernet2/0/0] quit
[~PE1] commit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not
mentioned here. For details, see "Configuration Files."
# After the configuration, run the display ip vpn-instance verbose command on PEs to
view the configurations of VPN instances.
<PE1> display ip vpn-instance verbose
Total VPN-Instances configured : 1
VPN-Instance Name and ID : vpna, 1
Interfaces : GigabitEthernet2/0/0
Address family ipv4
Create date : 2009/09/18 11:30:35
Up time : 0 days, 00 hours, 05 minutes and 19 seconds
Route Distinguisher : 100:1
Export VPN Targets : 111:1
Import VPN Targets : 111:1
Label policy: label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
6.
Set up EBGP peer relationships between the PEs and CEs, and import VPN routes to the
loopback interfaces of the CEs.
# Configure CE1.
[~CE1] interface loopback 1
Issue 01 (2011-10-15)
212
The configurations of CE2 and CE3 are similar to the configuration of CE1, and are not
mentioned here. For details, see "Configuration Files."
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[~PE1-bgp-vpna] peer 10.1.1.1 as-number 65001
[~PE1-bgp-vpna] commit
[~PE1-bgp-vpna] quit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not
mentioned here. For details, see "Configuration Files."
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the
PEs, and you can view that BGP peer relationships have been established between the PEs
and CEs.
Take the peer relationship between PE1 and CE1 as an example.
<PE1> display bgp vpnv4 vpn-instance vpna peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V
AS MsgRcvd MsgSent
OutQ Up/Down
State
PrefRcv
10.1.1.1
4
65001 11
9
0
00:06:37
Established
7.
Set up an MP-EBGP peer relationship between the ASBRs, and configure the ASBRs not
to filter received VPNv4 routes based on VPN targets.
# On ASBR1, set up an MP-EBGP peer relationship between ASBR1 and ASBR2, and
configure ASBR1 not to filter received VPNv4 routes based on VPN targets.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 192.1.1.2 as-number 200
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 192.1.1.2 enable
[~ASBR1-bgp-af-vpnv4] undo policy vpn-target
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
8.
Issue 01 (2011-10-15)
213
33.33.33.33/32 BGP
255 0
D 10.1.1.2
GigabitEthernet1/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
<CE1> ping -a 11.11.11.11 22.22.22.22
PING 22.22.22.22: 56 data bytes, press CTRL_C to break
Reply from 22.22.22.22: bytes=56 Sequence=1 ttl=252 time=120 ms
Reply from 22.22.22.22: bytes=56 Sequence=2 ttl=252 time=73 ms
Reply from 22.22.22.22: bytes=56 Sequence=3 ttl=252 time=111 ms
Reply from 22.22.22.22: bytes=56 Sequence=4 ttl=252 time=86 ms
Reply from 22.22.22.22: bytes=56 Sequence=5 ttl=252 time=110 ms
--- 22.22.22.22 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 73/100/120 ms
Run the display bgp vpnv4 all routing-table command on the RR or ASBRs, and you can
view the VPNv4 routes on the RR or ASBRs.
<RR> display bgp vpnv4 all routing-table
Local AS number : 100
BGP Local router ID is 4.4.4.4
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 3
Route Distinguisher: 100:1
Network
NextHop
*>i 11.11.11.11/32
1.1.1.1
Route Distinguisher: 200:2
Network
NextHop
*>i 22.22.22.22/32
5.5.5.5
Route Distinguisher: 100:3
*>i
MED
LocPrf
100
MED
LocPrf
100
Network
NextHop
MED
LocPrf
33.33.33.33/32
3.3.3.3
100
PrefVal Path/Ogn
0
PrefVal Path/Ogn
0
PrefVal Path/Ogn
0
Configuration Files
l
Issue 01 (2011-10-15)
214
Issue 01 (2011-10-15)
215
#
mpls ldp
#
interface GigabitEthernet2/0/0
undo shutdown
ip binding vpn-instance vpna
ip address 10.3.1.2 255.255.255.0
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 172.3.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
peer 4.4.4.4 as-number 100
peer 4.4.4.4 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 4.4.4.4 enable
#
ipv4-family vpnv4
policy vpn-target
peer 4.4.4.4 enable
#
ipv4-family vpn-instance vpna
peer 10.3.1.1 as-number 65003
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 172.3.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
216
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 172.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 100
peer 1.1.1.1 as-number 100
peer 1.1.1.1 connect-interface LoopBack1
peer 3.3.3.3 as-number 100
peer 3.3.3.3 connect-interface LoopBack1
peer 5.5.5.5 as-number 100
peer 5.5.5.5 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
peer 3.3.3.3 enable
peer 5.5.5.5 enable
#
ipv4-family vpnv4
undo policy vpn-target
peer 1.1.1.1 enable
peer 1.1.1.1 reflect-client
peer 3.3.3.3 enable
peer 3.3.3.3 reflect-client
peer 5.5.5.5 enable
peer 5.5.5.5 reflect-client
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
network 172.3.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
217
link-protocol ppp
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 5.5.5.5 255.255.255.255
#
bgp 100
peer 4.4.4.4 as-number 100
peer 4.4.4.4 connect-interface LoopBack1
peer 6.6.6.6 as-number 200
peer 6.6.6.6 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 4.4.4.4 enable
peer 6.6.6.6 enable
#
ipv4-family vpnv4
undo policy vpn-target
peer 4.4.4.4 enable
peer 6.6.6.6 enable
#
ospf 1
area 0.0.0.0
network 5.5.5.5 0.0.0.0
network 172.2.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
218
Issue 01 (2011-10-15)
219
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface Loopback 1
undo shutdown
ip address 22.22.22.22 255.255.255.255
#
bgp 65002
peer 10.2.1.2 as-number 200
network 22.22.22.22 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.2.1.2 enable
#
return
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-36, CE1, CE2, and CE3 belong to the same VPN; PE2 is not in the same
AS where PE1 and PE3 belong. CE2 and CE3 do not need to communicate. It is required that
ASBR1 be configured to filter VPN routes based on RDs so that routes of CE3 cannot be
transmitted to PE2 by ASBR2. This implements inter-AS VPN Option B.
Issue 01 (2011-10-15)
220
Figure 2-36 Networking of inter-AS VPN Option B with an ASBR filtering VPN routes
Loopback1
AS 65003
CE3
GE1/0/0
GE2/0/0
PE3
BGP/MPLS Backbone
AS 200
BGP/MPLS Backbone AS
100
POS1/0/0
Loopback1
Loopback1
POS2/0/0
POS3/0/0
POS1/0/0
Loopback1
Loopback1
POS2/0/0
ASBR1
ASBR2
POS1/0/0
PE1
POS1/0/0
Loopback1
POS1/0/0
GE2/0/0
GE2/0/0
GE1/0/0
GE1/0/0
CE1
CE2
AS 65001
AS 65002
Loopback1
Interface
IP Address
CE1
Loopback1
11.11.11.11/32
GE 1/0/0
10.1.1.1/24
Loopback1
1.1.1.1/32
GE 2/0/0
10.1.1.2/24
POS 1/0/0
172.1.1.2/24
Loopback1
33.33.33.33/32
GE 1/0/0
10.3.1.1/24
Loopback1
3.3.3.3/32
GE 2/0/0
10.3.1.2/24
POS 1/0/0
172.3.1.2/24
Loopback1
5.5.5.5/32
POS 1/0/0
172.1.1.1/24
CE3
PE3
ASBR1
Issue 01 (2011-10-15)
Loopback1
Device
PE1
PE2
221
Device
ASBR2
CE2
PE2
Interface
IP Address
POS 2/0/0
192.1.1.1/24
POS 3/0/0
172.3.1.1/24
Loopback1
6.6.6.6/32
POS 1/0/0
162.1.1.1/24
POS 2/0/0
192.1.1.2/24
Loopback1
22.22.22.22/32
GE 1/0/0
10.2.1.1/24
Loopback1
2.2.2.2/32
GE 2/0/0
10.2.1.2/24
POS 1/0/0
162.1.1.2/24
Configuration Notes
When configuring inter-AS VPN Option B with an ASBR filtering VPN routes, note the
following:
l
There is no need to create VPN instances on the ASBRs. One ASBR needs to filter the
VPNv4 routes advertised to the other ASBR based on RDs.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP on the MPLS backbone network to implement interworking of the ASBR
and PE in the same AS, and set up an MPLS LDP LSP between the ASBR and PE in the
same AS.
2.
Set up EBGP peer relationships between the PEs and CEs and set up MP-IBGP peer
relationships between the PEs and ASBR-PEs.
3.
4.
Enable MPLS on the interface that connects one ASBR to the other ASBR and set up an
MP-EBGP peer relationship between the ASBRs. One ASBR needs to filter the VPNv4
routes advertised to the other ASBR based on RDs.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances of the PEs
Routing policy used by an ASBR to filter VPN routes based on VPN targets
Issue 01 (2011-10-15)
222
Procedure
Step 1 On the MPLS backbone networks in AS 100 and AS 200, configure an IGP to interconnect the
devices in the same AS.
In this example, OSPF is used as the IGP protocol. For details, see "Configuration Files."
After the configuration, the OSPF neighbor relationships can be established between the devices
in the same AS. Run the display ospf peer command, and you can view that the neighbor
relationship is in the Full state. Run the display ip routing-table command, and you can view
that PEs or ASBRs have learnt the routes to the loopback interface of each other.
Step 2 Configure basic MPLS functions and MPLS LDP, and set up LDP LSPs on the MPLS backbone
network of each AS.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos 1/0/0
[~PE1-Pos1/0/0] mpls
[~PE1-Pos1/0/0] mpls ldp
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not mentioned
here. For details, see "Configuration Files."
# Configure ASBR1.
[~ASBR1] mpls lsr-id 5.5.5.5
[~ASBR1] mpls
[~ASBR1-mpls] quit
[~ASBR1] mpls ldp
[~ASBR1-mpls-ldp] quit
[~ASBR1] interface pos 1/0/0
[~ASBR1-Pos1/0/0] mpls
[~ASBR1-Pos1/0/0] mpls ldp
[~ASBR1-Pos1/0/0] commit
[~ASBR1-Pos1/0/0] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
After the configuration, the LDP sessions can be established between the PEs. Run the display
mpls ldp session command on each device, and you can view that the Status field is displayed
as Operational. Take the display on PE1 as an example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
------------------------------------------------------------------------4.4.4.4:0
Operational DU
Passive 0000:00:01 5/5
------------------------------------------------------------------------TOTAL: 1 session(s) Found.
Step 3 Set up MP-IBGP peer relationships between the PEs and ASBR in each AS; set up an MP-IBGP
peer relationship between PE1 and PE3 in AS 100.
# Configure PE1.
Issue 01 (2011-10-15)
223
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not mentioned
here. For details, see "Configuration Files."
# Configure ASBR1.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 1.1.1.1 as-number 100
[~ASBR1-bgp] peer 1.1.1.1 connect-interface loopback 1
[~ASBR1-bgp] peer 3.3.3.3 as-number 100
[~ASBR1-bgp] peer 3.3.3.3 connect-interface loopback 1
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 1.1.1.1 enable
[~ASBR1-bgp-af-vpnv4] peer 3.3.3.3 enable
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
After the configuration, run the display bgp vpnv4 all peer command on the PEs or ASBRs,
and you can view that MP-IBGP peer relationships have been established between the PEs and
ASBRs. Take the display on PE1 as an example.
<PE1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 2
Peer
V
AS MsgRcvd
3.3.3.3
4
100
12
5.5.5.5
4
100
12
MsgSent
18
18
Step 4 Configure VPN instances on the PEs and connect the CEs to the PEs through the VPN instances.
# Configure PE1.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] interface gigabitethernet 2/0/0
[~PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[~PE1-GigabitEthernet2/0/0] ip address 10.1.1.2 24
[~PE1-GigabitEthernet2/0/0] commit
[~PE1-GigabitEthernet2/0/0] quit
# Configure PE2.
[~PE2] ip vpn-instance vpna
[~PE2-vpn-instance-vpna] ipv4-family
[~PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 200:2
[~PE2-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE2-vpn-instance-vpna-af-ipv4] quit
[~PE2-vpn-instance-vpna] quit
Issue 01 (2011-10-15)
224
# Configure PE3.
[~PE3] ip vpn-instance vpna
[~PE3-vpn-instance-vpna] ipv4-family
[~PE3-vpn-instance-vpna-af-ipv4] route-distinguisher 100:3
[~PE3-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE3-vpn-instance-vpna-af-ipv4] quit
[~PE3-vpn-instance-vpna] quit
[~PE3] interface gigabitethernet 2/0/0
[~PE3-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[~PE3-GigabitEthernet2/0/0] ip address 10.3.1.2 24
[~PE3-GigabitEthernet2/0/0] commit
[~PE3-GigabitEthernet2/0/0] quit
# After the configuration, run the display ip vpn-instance verbose command on PEs to view
the configurations of VPN instances.
<PE1> display ip vpn-instance verbose
Total VPN-Instances configured : 1
VPN-Instance Name and ID : vpna, 1
Interfaces : GigabitEthernet2/0/0
Address family ipv4
Create date : 2009/09/18 11:30:35
Up time : 0 days, 00 hours, 05 minutes and 19 seconds
Route Distinguisher : 100:1
Export VPN Targets : 111:1
Import VPN Targets : 111:1
Label policy: label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
Step 5 Set up EBGP peer relationships between the PEs and CEs, and import VPN routes to the loopback
interfaces of the CEs.
# Configure CE1.
[~CE1] interface loopback 1
[~CE1-Loopback1] ip address 11.11.11.11 32
[~CE1-Loopback1] quit
[~CE1] bgp 65001
[~CE1-bgp] peer 10.1.1.2 as-number 100
[~CE1-bgp] network 11.11.11.11 32
[~CE1-bgp] quit
[~CE1] commit
The configurations of CE2 and CE3 are similar to the configuration of CE1, and are not
mentioned here. For details, see "Configuration Files."
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[~PE1-bgp-vpna] peer 10.1.1.1 as-number 65001
[~PE1-bgp-vpna] commit
[~PE1-bgp-vpna] quit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not mentioned
here. For details, see "Configuration Files."
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the PEs,
and you can view that BGP peer relationships have been established between the PEs and CEs.
Issue 01 (2011-10-15)
225
Step 6 Set up an MP-EBGP peer relationship between the ASBRs, and configure the ASBRs to filter
received VPNv4 routes.
# On ASBR1, set up an MP-EBGP peer relationship between ASBR1 and ASBR2, and configure
ASBR1 to filter received VPNv4 routes.
[~ASBR1] ip rd-filter 10 deny 100:3
[~ASBR1] route-policy test permit node 10
[~ASBR1-route-policy] if-match rd-filter 10
[~ASBR1-route-policy] commit
[~ASBR1-route-policy] quit
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 192.1.1.2 as-number 200
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 192.1.1.2 enable
[~ASBR1-bgp-af-vpnv4] peer 192.1.1.2 route-policy test export
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
# On ASBR2, set up an MP-EBGP peer relationship between ASBR2 and ASBR1, and configure
ASBR2 not to filter received VPNv4 routes.
[~ASBR2] bgp 100
[~ASBR2-bgp] peer 192.1.1.1 as-number 100
[~ASBR2-bgp] ipv4-family vpnv4
[~ASBR2-bgp-af-vpnv4] peer 192.1.1.2 enable
[~ASBR2-bgp-af-vpnv4] undo policy vpn-target
[~ASBR2-bgp-af-vpnv4] commit
[~ASBR2-bgp-af-vpnv4] quit
[~ASBR2-bgp] quit
NextHop
*>i 11.11.11.11/32
1.1.1.1
Route Distinguisher: 200:2
*>i
Issue 01 (2011-10-15)
MED
LocPrf
100
Network
NextHop
MED
LocPrf
22.22.22.22/32
6.6.6.6
100
PrefVal Path/Ogn
0
PrefVal Path/Ogn
0
226
*>i
Network
NextHop
MED
LocPrf
33.33.33.33/32
3.3.3.3
100
PrefVal Path/Ogn
0
Run the display bgp vpnv4 all routing-table command on ASBR2, and you can view that there
are no routes sent from PE3.
<ASBR2> display bgp vpnv4 all routing-table
Local AS number : 200
BGP Local router ID is 6.6.6.6
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 2
Route Distinguisher: 100:1
Network
NextHop
*>i 11.11.11.11/32
5.5.5.5
Route Distinguisher: 200:2
*>i
Network
22.22.22.22/24
NextHop
2.2.2.2
MED
LocPrf
MED
0
100
LocPrf
100
PrefVal Path/Ogn
0
PrefVal Path/Ogn
0
?
CE1 and CE3, and CE1 and CE2 can successfully ping each other whereas CE2 and CE3 cannot
successfully ping each other.
<CE1> ping -a 11.11.11.11 33.33.33.33
PING 33.33.33.33: 56 data bytes, press CTRL_C to break
Reply from 33.33.33.33: bytes=56 Sequence=1 ttl=252 time=120 ms
Reply from 33.33.33.33: bytes=56 Sequence=2 ttl=252 time=73 ms
Reply from 33.33.33.33: bytes=56 Sequence=3 ttl=252 time=111 ms
Reply from 33.33.33.33: bytes=56 Sequence=4 ttl=252 time=86 ms
Reply from 33.33.33.33: bytes=56 Sequence=5 ttl=252 time=110 ms
--- 33.33.33.33 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 73/100/120 ms
<CE2> ping -a 22.22.22.22 33.33.33.33
PING 33.33.33.33: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 33.33.33.33 ping statistics --5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
----End
Configuration Files
l
Issue 01 (2011-10-15)
227
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface Loopback1
undo shutdown
ip address 11.11.11.11 255.255.255.255
#
bgp 65001
peer 10.1.1.2 as-number 100
network 11.11.11.11 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.1.1.2 enable
#
return
Issue 01 (2011-10-15)
228
Issue 01 (2011-10-15)
229
interface Loopback1
undo shutdown
ip address 33.33.33.33 255.255.255.255
#
bgp 65003
peer 10.3.1.2 as-number 100
network 33.33.33.33 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.3.1.2 enable
#
return
Issue 01 (2011-10-15)
230
Issue 01 (2011-10-15)
231
mpls
#
mpls ldp
#
interface GigabitEthernet2/0/0
undo shutdown
ip binding vpn-instance vpna
ip address 10.2.1.2 255.255.255.0
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 162.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 200
peer 6.6.6.6 as-number 100
peer 6.6.6.6 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 6.6.6.6 enable
#
ipv4-family vpnv4
policy vpn-target
peer 6.6.6.6 enable
#
ipv4-family vpn-instance vpna
peer 10.2.1.1 as-number 65002
#
ospf 1
area 0.0.0.0
network 162.1.1.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
return
Issue 01 (2011-10-15)
232
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-37, CE1 and CE2 belong to the same VPN. CE1 is connected to PE1 in
AS 100, and CE2 is connected to PE2 in AS 200. The MPLS network between the ASBRs does
not support VPN. That is, there must be a P between the ASBRs. It is required that an LSP be
set up between the ASBRs in different ASs to implement inter-AS VPN Option B.
Figure 2-37 Networking diagram of inter-AS VPN Option B with a P between ASBRs
BGP/MPLS Backbone AS
100
Loopback1
2.2.2.9/32
Loopback1
1.1.1.9/32
PE1
Loopback1
5.5.5.9/32
POS2/0/0
192.1.1.1/24
POS1/0/0
172.1.1.1/24
ASBR1
BGP/MPLS Backbone
AS 200
Loopback1
3.3.3.9/32
POS1/0/0
192.1.1.2/24 P
POS2/0/0
192.2.1.2/24
POS2/0/0
192.2.1.1/24
POS1/0/0
172.1.1.2/24
GE2/0/0
10.1.1.2/24
GE1/0/0
10.1.1.1/24
CE1
AS 65001
Loopback1
11.11.11.11/32
POS1/0/0
162.1.1.1/24
ASBR2
Loopback1
4.4.4.9/32
POS1/0/0
162.1.1.2/24
PE2
GE2/0/0
10.2.1.2/24
GE1/0/0
10.2.1.1/24
CE2
AS 65002
Loopback1
22.22.22.22/32
Configuration Notes
When configuring inter-AS VPN Option B with a P between ASBRs, note the following:
Issue 01 (2011-10-15)
233
There is no need to create VPN instances on ASBRs or configure ASBRs to filter VPNv4
routes based on VPN targets.
An MP-EBGP peer relationship needs to be set up between ASBRs with multiple hops.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP on the MPLS backbone network to implement interworking of the ASBR
and PE in the same AS, and set up an MPLS LDP LSP between the ASBR and PE in the
same AS.
2.
Set up EBGP peer relationships between the PEs and CEs and set up MP-IBGP peer
relationships between the PEs and ASBR-PEs.
3.
4.
Set up an EBGP peer relationship between ASBRs and set up an MPLS LDP LSP.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances of the PEs
Procedure
Step 1 On the MPLS backbone networks in AS 100 and AS 200, configure an IGP to interconnect the
PE and ASBR on each network.
In this example, OSPF is used as the IGP protocol. For details, see "Configuration Files."
NOTE
The 32-bit IP address of the loopback interface that functions as the LSR ID needs to be advertised by
using OSPF.
After the configuration, the OSPF neighbor relationship can be established between the ASBR
and PE in the same AS. Run the display ospf peer command, and you can view that the neighbor
relationship is in the Full state.
The ASBR and PE in the same AS can learn and successfully ping the IP address of the loopback
interface of each other.
Step 2 Configure basic MPLS functions and MPLS LDP and set up LDP LSPs on the MPLS backbone
networks of AS 100 and AS 200.
The detailed configuration is not mentioned here. For details, see 2.18.10 Example for
Configuring Inter-AS VPN Option A.
Step 3 Configure the basic BGP/MPLS IP VPN functions on PE1 and PE2, as described in 2.18.1
Example for Configuring BGP/MPLS IP VPN.
NOTE
The VPN targets of the VPN instances of PE1 and PE2 must be the same.
Issue 01 (2011-10-15)
234
The detailed configuration is not mentioned here. For details, see "Configuration Files."
Step 4 Set up an MPLS LDP LSP and establish an MP-EBGP neighbor relationship between the
ASBRs.
Configure an IGP between the ASBRs. In this example, OSPF is used as the IGP protocol.
# Configure ASBR1.
<ASBR1> system-view
[~ASBR1] interface pos 2/0/0
[~ASBR1-Pos2/0/0] ip address
[~ASBR1-Pos2/0/0] commit
[~ASBR1-Pos2/0/0] quit
[~ASBR1] ospf 2
[~ASBR1-ospf-2] area 0
[~ASBR1-ospf-2-area-0.0.0.0]
[~ASBR1-ospf-2-area-0.0.0.0]
[~ASBR1-ospf-2-area-0.0.0.0]
[~ASBR1-ospf-2] commit
[~ASBR1-ospf-2] quit
[~ASBR1] quit
192.1.1.1 24
NOTE
The process ID of OSPF runs between the ASBRs must be different from that of OSPF runs in each AS.
The configurations of ASBR2 and the P are similar to the configuration of ASBR1, and are not
mentioned here. For details, see "Configuration Files."
Set up an MPLS LDP LSP between the ASBRs.
<ASBR1> system-view
[~ASBR1] mpls lsr-id 2.2.2.9
[~ASBR1] mpls
[~ASBR1-mpls] quit
[~ASBR1] mpls ldp
[~ASBR1-mpls-ldp] quit
[~ASBR1] interface pos2/0/0
[~ASBR1-Pos2/0/0] mpls
[~ASBR1-Pos2/0/0] mpls ldp
[~ASBR1-Pos2/0/0] commit
[~ASBR1-Pos2/0/0] quit
The configurations of ASBR2 and the P are similar to the configuration of ASBR1, and are not
mentioned here. For details, see "Configuration Files."
After the configuration, run the display mpls ldp lsp command on the ASBRs, and you can
view that there is an MPLS LDP LSP between the ASBRs.
<ASBR1>display mpls ldp lsp
LDP LSP Information
-------------------------------------------------------------------------SN
DestAddress/Mask
In/OutLabel
Next-Hop
In/Out-Interface
-------------------------------------------------------------------------*1
2.2.2.9/32
Liberal
2
3.3.3.9/32
NULL/19
192.1.1.1
-------/Pos2/0/0
3
3.3.3.9/32
16/19
192.1.1.1
Pos2/0/0/Pos2/0/0
4
5.5.5.9/32
NULL/3
192.1.1.1
-------/Pos2/0/0
5
5.5.5.9/32
17/3
192.1.1.1
Pos2/0/0/Pos2/0/0
-------------------------------------------------------------------------TOTAL: 4 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
# Set up an MP-EBGP peer relationship between ASBR1 and ASBR2, and configure the ASBRs
not to filter received VPNv4 routes based on VPN targets.
Issue 01 (2011-10-15)
235
Run the display bgp vpnv4 all routing-table command on the ASBRs, and you can view the
VPNv4 routes on the ASBRs.
Take the display on ASBR1 as an example.
<ASBR1> display bgp vpnv4 all routing-table
Local AS number : 100
BGP Local router ID is 2.2.2.9
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 2
Route Distinguisher: 100:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 11.11.11.11/32
1.1.1.9
0
100
0
?
Route Distinguisher: 200:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
22.22.22.22/24
192.1.1.2
0
200?
----End
Configuration Files
l
Issue 01 (2011-10-15)
236
sysname CE1
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface Loopback 1
undo shutdown
ip address 11.11.11.11 255.255.255.255
#
bgp 65001
peer 10.1.1.2 as-number 100
network 11.11.11.11 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.1.1.2 enable
return
Issue 01 (2011-10-15)
237
return
Issue 01 (2011-10-15)
238
link-protocol ppp
ip address 192.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 5.5.5.9 0.0.0.0
network 192.1.1.0 0.0.0.255
network 192.2.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
239
Issue 01 (2011-10-15)
240
interface Loopback 1
undo shutdown
ip address 22.22.22.22 255.255.255.255
#
bgp 65002
peer 10.2.1.2 as-number 200
network 22.22.22.22 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.2.1.2 enable
#
return
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
In inter-AS VPN Option B, the ASBRs function as inter-AS devices to transmit VPNv4 routes
and also function as PEs to manage VPN routes. In this case, inter-AS VPN Option B with
ASBRs functioning as PEs can be deployed. This decreases the number of PEs being deployed
but puts higher requirement on the ASBR performance.
In the networking shown in Figure 2-38, it is required that inter-AS VPN Option B be configured
and ASBRs be configured to function as PEs to interconnect the CEs.
Issue 01 (2011-10-15)
241
Figure 2-38 Networking diagram of inter-AS VPN Option B with ASBRs functioning as PEs
BGP/MPLS Backbone AS
100
Loopback1
2.2.2.9/32
POS1/0/0
172.1.1.1/24
Loopback1
1.1.1.9/32
ASBR1
POS1/0/0
172.1.1.2/24
PE1
GE2/0/0
10.1.1.2/24
GE1/0/0
10.1.1.1/24
CE1
AS 65001
Loopback1
11.11.11.11/32
POS2/0/0
POS2/0/0
192.1.1.1/24 192.1.1.2/24
GE1/0/0
10.3.1.2/24
GE1/0/0
10.3.1.1/24
CE3
AS
65003
Loopback1
33.33.33.33/32
BGP/MPLS Backbone
AS 200
Loopback1
3.3.3.9/32
GE1/0/0
10.4.1.2/24
POS1/0/0
162.1.1.1/24
ASBR2
GE1/0/0
10.4.1.1/24
POS1/0/0
162.1.1.2/24
CE4
AS
65004
Loopback1
44.44.44.44/32
Loopback1
4.4.4.9/32
PE2
GE2/0/0
10.2.1.2/24
GE1/0/0
10.2.1.1/24
CE2
AS 65002
Loopback1
22.22.22.22/32
Configuration Notes
When configuring inter-AS VPN Option B with ASBRs functioning as PEs, note the following:
l
VPN instances need to be created on ASBRs and ASBRs and CEs need to communicate.
ASBRs do not filter the received VPNv4 routes based on VPN targets.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP on the MPLS backbone network to implement interworking of the ASBR
and PE in the same AS, and set up an MPLS LDP LSP between the ASBR and PE in the
same AS.
2.
3.
Create VPN instances on PEs and ASBRs, and set up EBGP peer relationships between
the PEs, ASBRs, and CEs.
4.
Enable MPLS on the interface that connects one ASBR to the other ASBR and set up an
MP-EBGP peer relationship between the ASBRs.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances of the PEs and ASBRs
Issue 01 (2011-10-15)
242
Procedure
Step 1 On the MPLS backbone networks in AS 100 and AS 200, configure an IGP to interconnect the
PE and ASBR on each network.
In this example, OSPF is used as the IGP protocol. For details, see "Configuration Files."
After the configuration, the OSPF neighbor relationship can be established between the ASBR
and PE in the same AS. Run the display ospf peercommand, and you can view that the neighbor
relationship is in the Full state. The ASBR and PE in the same AS can learn and successfully
ping the IP address of the loopback interface of each other.
Step 2 Configure basic MPLS functions and MPLS LDP, and set up MPLS LDP LSPs on the MPLS
backbone networks in AS 100 and AS 200.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.9
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos 1/0/0
[~PE1-Pos1/0/0] mpls
[~PE1-Pos1/0/0] mpls ldp
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
The configuration of PE2 is similar to the configuration of PE1, and is not mentioned here. For
details, see "Configuration Files."
# Configure ASBR1.
[~ASBR1] mpls lsr-id 2.2.2.9
[~ASBR1] mpls
[~ASBR1-mpls] quit
[~ASBR1] mpls ldp
[~ASBR1-mpls-ldp] quit
[~ASBR1] interface pos 1/0/0
[~ASBR1-Pos1/0/0] mpls
[~ASBR1-Pos1/0/0] mpls ldp
[~ASBR1-Pos1/0/0] commit
[~ASBR1-Pos1/0/0] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
After the configuration, the LDP session can be established between the PE and ASBR. Run the
display mpls ldp session command on each device, and you can view that the Status field is
displayed as Operational. Take the display on PE1 as an example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
------------------------------------------------------------------------2.2.2.9:0
Operational DU
Passive 0000:00:01 5/5
------------------------------------------------------------------------TOTAL: 1 session(s) Found.
Step 3 Set up an MP-IBGP peer relationship between the PE and ASBR in the same AS.
# Configure PE1.
Issue 01 (2011-10-15)
243
The configuration of PE2 is similar to the configuration of PE1, and is not mentioned here. For
details, see "Configuration Files."
# Configure ASBR1.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 1.1.1.9 as-number 100
[~ASBR1-bgp] peer 1.1.1.9 connect-interface loopback 1
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 1.1.1.9 enable
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
After the configuration, the MP-IBGP peer relationship can be established between the PE and
ASBR in the same AS. Take the display on PE1 as an example.
After the configuration, run the display bgp vpnv4 all peer command on the PE or ASBR, and
you can view that an MP-IBGP peer relationship has been established between the PE and ASBR
in the same AS. Take the display on PE1 as an example.
<PE1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peer
PrefRcv
2.2.2.2
AS
MsgRcvd
MsgSent
100
54
59
OutQ
Up/Down
State
0 00:45:03 Established
Step 4 Configure VPN instances on the PEs and ASBRs and connect the CEs to the PEs through the
VPN instances.
# Configure PE1.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] interface gigabitethernet 2/0/0
[~PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[~PE1-GigabitEthernet2/0/0] ip address 10.1.1.2 24
[~PE1-GigabitEthernet2/0/0] commit
[~PE1-GigabitEthernet2/0/0] quit
The configurations of PE2, ASBR1, and ASBR2 are similar to the configuration of PE1, and
are not mentioned here. For details, see "Configuration Files."
After the configuration, run the display ip vpn-instance verbose command on the PE or ASBR
to view the configurations of VPN instances. Take the display on PE1 as an example.
Issue 01 (2011-10-15)
244
Step 5 Set up EBGP peer relationships between the PEs, ASBRs, and CEs, and import VPN routes to
the loopback interfaces of the CEs.
# Configure CE1.
[~CE1] interface loopback 1
[~CE1-Loopback1] ip address 11.11.11.11 32
[~CE1-Loopback1] quit
[~CE1] bgp 65001
[~CE1-bgp] peer 10.1.1.2 as-number 100
[~CE1-bgp] network 11.11.11.11 32
[~CE1-bgp] quit
[~CE1] commit
The configurations of CE2, CE3, and CE4 are similar to the configuration of CE1, and are not
mentioned here. For details, see "Configuration Files."
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[~PE1-bgp-vpna] peer 10.1.1.1 as-number 65001
[~PE1-bgp-vpna] commit
[~PE1-bgp-vpna] quit
The configurations of PE2, ASBR1, and ASBR2 are similar to the configuration of PE1, and
are not mentioned here. For details, see "Configuration Files."
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the PEs or
ASBRs, and you can view that BGP peer relationships have been established between the PEs
and CEs. Take the peer relationship between PE1 and CE1 as an example.
<PE1> display bgp vpnv4 vpn-instance vpna peer
BGP local router ID : 10.1.1.2
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V
AS MsgRcvd MsgSent
OutQ Up/Down
State
PrefRcv
10.1.1.1
4
65001 11
9
0
00:06:37
Established 1
Step 6 Set up an MP-EBGP peer relationship between the ASBRs, and configure the ASBRs not to
filter received VPNv4 routes based on VPN targets.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 192.1.1.2 as-number 200
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 192.1.1.2 enable
[~ASBR1-bgp-af-vpnv4] undo policy vpn-target
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
Issue 01 (2011-10-15)
245
NOTE
The ASBR does not filter the received VPNv4 routes based on VPN targets. Instead, it advertises the
received routes to the peer ASBR or the PE in the same AS. The VPN routing table on the ASBR is used
to match the VPN targets. Routes that have matching VPN targets in the VPN routing table on the ASBR
are received.
Run the display bgp vpnv4 all routing-table command on the ASBRs, and you can view the
VPNv4 routes on the ASBRs. Take the display on ASBR1 as an example.
<ASBR1> display bgp vpnv4 all routing-table
Local AS number : 100
BGP Local router ID is 2.2.2.9
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 4
Route Distinguisher: 100:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 11.11.11.11/32
1.1.1.9
100
0
?
Route Distinguisher: 200:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
22.22.22.22/32
3.3.3.9
0
200?
Route Distinguisher: 100:3
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 33.33.33.33/32
0.0.0.0
0
0
?
Route Distinguisher: 200:4
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 44.44.44.44/32
3.3.3.9
0
100
0
200?
----End
Configuration Files
l
Issue 01 (2011-10-15)
246
Issue 01 (2011-10-15)
247
#
mpls lsr-id 2.2.2.9
#
mpls
#
mpls ldp
#
interface GigabitEthernet1/0/0
undo shutdown
ip binding vpn-instance vpna
ip address 10.3.1.2 255.255.255.0
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
peer 192.1.1.2 as-number 200
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 192.1.1.2 enable
peer 1.1.1.9 enable
#
ipv4-family vpnv4
undo policy vpn-target
peer 1.1.1.9 enable
peer 192.1.1.2 enable
#
ipv4-family vpn-instance vpna
peer 10.3.1.1 as-number 65003
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
248
Issue 01 (2011-10-15)
249
Issue 01 (2011-10-15)
250
sysname CE2
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.2.1.1 255.255.255.0
#
interface Loopback1
undo shutdown
ip address 22.22.22.22 255.255.255.255
#
bgp 65002
peer 10.2.1.2 as-number 200
network 22.22.22.22 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.2.1.2 enable
#
return
Related Tasks
2.10 Configuring Inter-AS VPN Option B (ASBR Also Functioning as a PE)
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-39, CE1, CE2, and CE3 belong to the same VPN; PE2 is not in the same
AS where PE1 and PE3 belong. It is required that Inter-AS VPN Option B be adopted to
interconnect CE1, CE2, and CE3. To lower configuration complexities, you can configure
ASBR1 as an RR rather than set up an MP-IBGP peer relationship between PE1 and PE3. Then,
ASBR1 reflects the routes sent from PE1 to PE3 and the routes sent from PE3 to PE1, and then
sends the optimal route to ASBR2 after performing routing.
Issue 01 (2011-10-15)
251
Figure 2-39 Networking diagram of inter-AS VPN Option B with an ASBR functioning as an
RR
Loopback1
CE3
AS 65003
GE1/0/0
GE2/0/0
BGP/MPLS Backbone
AS 100
POS1/0/0
Loopback1
PE3
Loopback1
Loopback1
POS3/0/0
Loopback1
POS2/0/0
POS1/0/0
POS1/0/0
PE1
BGP/MPLS Backbone
AS 200
POS2/0/0
ASBR1
(RR)
ASBR2
POS1/0/0
GE2/0/0
GE1/0/0
CE2
AS 65002
Loopback1
Loopback1
Device
Interface
IP Address
CE1
Loopback1
11.11.11.11/32
GE 1/0/0
10.1.1.1/24
Loopback1
1.1.1.1/32
GE 2/0/0
10.1.1.2/24
POS 1/0/0
172.1.1.2/24
Loopback1
33.33.33.33/32
GE 1/0/0
10.3.1.1/24
Loopback1
3.3.3.3/32
GE 2/0/0
10.3.1.2/24
POS 1/0/0
172.3.1.2/24
Loopback1
5.5.5.5/32
CE3
PE3
ASBR1
Issue 01 (2011-10-15)
PE2
GE2/0/0
GE1/0/0
CE1
AS65001
PE1
POS1/0/0
Loopback1
252
Device
ASBR2
CE2
PE2
Interface
IP Address
POS 1/0/0
172.1.1.1/24
POS 2/0/0
192.1.1.1/24
POS 3/0/0
172.3.1.1/24
Loopback1
6.6.6.6/32
POS 1/0/0
162.1.1.1/24
POS 2/0/0
192.1.1.2/24
Loopback1
22.22.22.22/32
GE 1/0/0
10.2.1.1/24
Loopback1
2.2.2.2/32
GE 2/0/0
10.2.1.2/24
POS 1/0/0
162.1.1.2/24
Configuration Notes
When configuring inter-AS VPN Option B with an ASBR functioning as an RR, note the
following:
l
ASBR1 does not filter the received VPNv4 routes based on VPN targets.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP on the MPLS backbone network to interwork the ASBR and PE in the
same AS, and set up an MPLS LDP LSP between the ASBR and PE in the same AS.
2.
Set up EBGP peer relationships between the PEs and CEs and set up MP-IBGP peer
relationships between the PEs and ASBR-PEs.
3.
4.
5.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances of the PEs
Issue 01 (2011-10-15)
253
Procedure
Step 1 On the MPLS backbone networks in AS 100 and AS 200, configure an IGP to interconnect the
PE and ASBR on each network.
In this example, OSPF is used as the IGP protocol. For details, see "Configuration Files."
After the configuration, the OSPF neighbor relationships can be established between the PEs
and ASBRs. Run the display ospf peer command, and you can view that the neighbor
relationship is in the Full state. Run the display ip routing-table command, and you can view
that PEs or ASBRs have learnt the routes to the loopback interface of each other.
Step 2 Configure basic MPLS functions and MPLS LDP, and set up LDP LSPs on the MPLS backbone
network of each AS.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos 1/0/0
[~PE1-Pos1/0/0] mpls
[~PE1-Pos1/0/0] mpls ldp
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not mentioned
here. For details, see "Configuration Files."
# Configure ASBR1.
[~ASBR1] mpls lsr-id 5.5.5.5
[~ASBR1] mpls
[~ASBR1-mpls] quit
[~ASBR1] mpls ldp
[~ASBR1-mpls-ldp] quit
[~ASBR1] interface pos 1/0/0
[~ASBR1-Pos1/0/0] mpls
[~ASBR1-Pos1/0/0] mpls ldp
[~ASBR1-Pos1/0/0] commit
[~ASBR1-Pos1/0/0] quit
[~ASBR1] interface pos 3/0/0
[~ASBR1-Pos3/0/0] mpls
[~ASBR1-Pos3/0/0] mpls ldp
[~ASBR1-Pos3/0/0] commit
[~ASBR1-Pos3/0/0] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
After the configuration, the LDP sessions can be established between the PE and ASBR. Run
the display mpls ldp session command on each device, and you can view that the Status field
is displayed as Operational. Take the display on PE1 as an example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
------------------------------------------------------------------------5.5.5.5:0
Operational DU
Passive 0000:00:01 5/5
-------------------------------------------------------------------------
Issue 01 (2011-10-15)
254
Step 3 Set up an MP-IBGP peer relationship between the PE and ASBR in the same AS.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] peer 5.5.5.5 as-number 100
[~PE1-bgp] peer 5.5.5.5 connect-interface loopback 1
[~PE1-bgp] ipv4-family vpnv4
[~PE1-bgp-af-vpnv4] peer 5.5.5.5 enable
[~PE1-bgp-af-vpnv4] commit
[~PE1-bgp-af-vpnv4] quit
[~PE1-bgp] quit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not mentioned
here. For details, see "Configuration Files."
# Configure ASBR1.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 1.1.1.1 as-number 100
[~ASBR1-bgp] peer 1.1.1.1 connect-interface loopback 1
[~ASBR1-bgp] peer 3.3.3.3 as-number 100
[~ASBR1-bgp] peer 3.3.3.3 connect-interface loopback 1
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 1.1.1.1 enable
[~ASBR1-bgp-af-vpnv4] peer 3.3.3.3 enable
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here. For details, see "Configuration Files."
After the configuration, run the display bgp vpnv4 all peer command on the PEs or ASBRs,
and you can view that MP-IBGP peer relationships have been established between the PEs and
ASBRs. Take the display on PE1 as an example.
<ASBR1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 2
Peers in established state : 3
Peer
V
AS MsgRcvd MsgSent
OutQ Up/Down
State
PrefRcv
5.5.5.5
4
100
12
18
0
00:09:38
Established
0
Step 4 Configure VPN instances on the PEs and connect the CEs to the PEs.
# Configure PE1.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] interface gigabitethernet 2/0/0
[~PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[~PE1-GigabitEthernet2/0/0] ip address 10.1.1.2 24
[~PE1-GigabitEthernet2/0/0] commit
[~PE1-GigabitEthernet2/0/0] quit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not mentioned
here. For details, see "Configuration Files."
After the configuration, run the display ip vpn-instance verbose command on PEs to view the
configurations of VPN instances.
Issue 01 (2011-10-15)
255
Step 5 Set up EBGP peer relationships between the PEs and CEs, and import VPN routes to the loopback
interfaces of the CEs.
# Configure CE1.
[~CE1] interface loopback 1
[~CE1-Loopback1] ip address 11.11.11.11 32
[~CE1-Loopback1] quit
[~CE1] bgp 65001
[~CE1-bgp] peer 10.1.1.2 as-number 100
[~CE1-bgp] network 11.11.11.11 32
[~CE1-bgp] quit
[~CE1] commit
The configurations of CE2 and CE3 are similar to the configuration of CE1, and are not
mentioned here. For details, see "Configuration Files."
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[~PE1-bgp-vpna] peer 10.1.1.1 as-number 65001
[~PE1-bgp-vpna] commit
[~PE1-bgp-vpna] quit
The configurations of PE2 and PE3 are similar to the configuration of PE1, and are not mentioned
here. For details, see "Configuration Files."
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the PEs,
and you can view that BGP peer relationships have been established between the PEs and CEs.
Take the peer relationship between PE1 and CE1 as an example.
<PE1> display bgp vpnv4 vpn-instance vpna peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V
AS MsgRcvd MsgSent
OutQ Up/Down
State
PrefRcv
10.1.1.1
4
65001 11
9
0
00:06:37
Established 1
Step 6 Set up an MP-EBGP peer relationship between the ASBRs, and configure the ASBRs not to
filter received VPNv4 routes based on VPN targets.
# On ASBR1, set up an MP-EBGP peer relationship between ASBR1 and ASBR2, and configure
ASBR1 to filter received VPNv4 routes.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 192.1.1.2 as-number 200
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 192.1.1.2 enable
[~ASBR1-bgp-af-vpnv4] undo policy vpn-target
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
Issue 01 (2011-10-15)
256
[~ASBR1-bgp] quit
The configuration of ASBR2 is similar to the configuration of ASBR1, and is not mentioned
here.
Step 7 Configure ASBR1 as an RR to reflect the VPNv4 routes from PE1 to PE3, and reflect the VPNv4
routes from PE3 to PE1.
# Configure ASBR1.
[~ASBR1] bgp 100
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 1.1.1.1 reflect-client
[~ASBR1-bgp-af-vpnv4] peer 3.3.3.3 reflect-client
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
NextHop
*>i 11.11.11.11/32
5.5.5.5
Route Distinguisher: 200:2
Network
NextHop
*>i 22.22.22.22/32
2.2.2.2
Route Distinguisher: 100:3
*>i
MED
LocPrf
100
MED
LocPrf
100
Network
NextHop
MED
LocPrf
33.33.33.33/32
5.5.5.5
100
PrefVal Path/Ogn
0
PrefVal Path/Ogn
0
PrefVal Path/Ogn
0
----End
Issue 01 (2011-10-15)
257
Configuration Files
l
Issue 01 (2011-10-15)
258
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 1.1.1.1 0.0.0.0
#
return
Issue 01 (2011-10-15)
259
undo shutdown
ip address 33.33.33.33 255.255.255.255
#
bgp 65003
peer 10.3.1.2 as-number 100
network 33.33.33.33 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.3.1.2 enable
#
return
Issue 01 (2011-10-15)
260
Issue 01 (2011-10-15)
261
Related Tasks
2.11 Configuring Inter-AS VPN Option B (ASBR Also Functioning as an RR)
262
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-40, CE1 and CE2 belong to vpna; the VPN spans AS 100, AS 200, and
AS 300. This networking is similar to the inter-AS VPN Option B with basic networking in that
no VPN instances are required on the ASBRs. One ASBR transmits the received VPNv4 routes
to the peer ASBR. Different from the inter-AS VPN Option B with basic networking, this
networking requires that an MP-IBGP peer relationship be set up between the ASBRs in AS
200.
Figure 2-40 Networking diagram of inter-AS VPN Option B with the VPN spanning multiple
ASs
BGP/MPLS Backbone
AS 200
Loopback1
Loopback1
ASBR2
POS1/0/0
POS2/0/0
POS2/0/0 ASBR1
AS 100
POS1/0/0
Loopback1
PE1
ASBR3
POS1/0/0
Loopback1
POS1/0/0
POS2/0/0
ASBR4 POS2/0/0
POS1/0/0 AS 300
Loopback1
Loopback1
POS1/0/0
GE2/0/0
GE2/0/0
GE1/0/0
GE1/0/0
CE1
AS 65001
CE2
AS 65002
Loopback1
Issue 01 (2011-10-15)
PE2
Loopback1
263
Device
Interface
IP Address
CE1
Loopback1
11.11.11.11/32
GE 1/0/0
10.1.1.1/24
Loopback1
1.1.1.9/32
GE 2/0/0
10.1.1.2/24
POS 1/0/0
172.1.1.2/24
Loopback1
2.2.2.9/32
POS 1/0/0
172.1.1.1/24
POS 2/0/0
192.1.1.1/24
Loopback1
3.3.3.9/32
POS 1/0/0
162.1.1.1/24
POS 2/0/0
192.1.1.2/24
Loopback1
4.4.4.9/32
POS 1/0/0
162.1.1.2/24
POS 2/0/0
192.2.1.1/24
Loopback1
5.5.5.9/32
POS 1/0/0
152.1.1.1/24
POS 2/0/0
192.2.1.2/24
Loopback1
6.6.6.9/32
GE 2/0/0
10.2.1.2/24
POS 1/0/0
152.1.1.2/24
Loopback1
22.22.22.22/32
GE 1/0/0
10.2.1.1/24
PE1
ASBR1
ASBR2
ASBR3
ASBR4
PE2
CE2
Configuration Notes
When configuring inter-AS VPN Option B with the VPN spanning multiple ASs, note the
following:
l
An MP-EBGP peer relationship needs to be set up between the ASBRs in different ASs;
an MP-IBGP peer relationship needs to be set up between the ASBRs or between the PE
and ASBR in the same AS.
ASBRs do not filter the received VPNv4 routes based on VPN targets.
Issue 01 (2011-10-15)
264
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP on each AS to interconnect devices in the same AS; set up an MPLS
LDP LSP between the ASBR and PE or between ASBRs in the same AS.
2.
Set up an MP-EBGP peer relationship between the ASBRs in different ASs; set up an MPIBGP peer relationship between the ASBRs or between the PE and ASBR in the same AS.
3.
Configure VPN instances on the PEs and connect the CEs to the PEs.
4.
Enable MPLS on the interface that connects one ASBR to another ASBR and configure
the ASBRs not to filter VPNv4 routes based on VPN targets.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances of the PEs
Procedure
Step 1 On the MPLS backbone networks in each AS, configure an IGP to interconnect the devices in
the same AS.
In this example, OSPF is used as the IGP protocol. For details, see "Configuration Files."
After the configuration, the OSPF neighbor relationship can be established between the devices
in the same AS. Run the display ospf peer command, and you can view that the neighbor
relationship is in the Full state. the devices in the same AS can learn and successfully ping the
IP address of the loopback interface of each other.
Step 2 Configure basic MPLS functions and MPLS LDP, and set up LDP LSPs on the MPLS backbone
network of each AS.
# Configure PE1.
[~PE1] mpls lsr-id 1.1.1.9
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos 1/0/0
[~PE1-Pos1/0/0] mpls
[~PE1-Pos1/0/0] mpls ldp
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
The configuration of PE2 is similar to the configuration of PE1, and is not mentioned here. For
details, see "Configuration Files."
# Configure ASBR1.
[~ASBR1] mpls lsr-id 2.2.2.9
[~ASBR1] mpls
[~ASBR1-mpls] quit
[~ASBR1] mpls ldp
[~ASBR1-mpls-ldp] quit
[~ASBR1] interface pos 1/0/0
[~ASBR1-Pos1/0/0] mpls
[~ASBR1-Pos1/0/0] mpls ldp
Issue 01 (2011-10-15)
265
[~ASBR1-Pos1/0/0] commit
[~ASBR1-Pos1/0/0] quit
The configurations of ASBR2, ASBR3, and ASBR4 are similar to the configuration of ASBR1,
and are not mentioned here. For details, see "Configuration Files."
After the configuration, the LDP sessions can be established between the PE and ASBR and
between the ASBRs. Run the display mpls ldp session command on each device, and you can
view that the Status field is displayed as Operational. Take the display on PE1 as an example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
------------------------------------------------------------------------2.2.2.9:0
Operational DU
Passive 0000:00:01 5/5
------------------------------------------------------------------------TOTAL: 1 session(s) Found.
Step 3 Set up an MP-IBGP peer relationship between the PE and ASBR and between the ASBRs in the
same AS.
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] peer 2.2.2.9 as-number 100
[~PE1-bgp] peer 2.2.2.9 connect-interface loopback 1
[~PE1-bgp] ipv4-family vpnv4
[~PE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[~PE1-bgp-af-vpnv4] commit
[~PE1-bgp-af-vpnv4] quit
[~PE1-bgp] quit
# Configure ASBR1.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 1.1.1.9 as-number 100
[~ASBR1-bgp] peer 1.1.1.9 connect-interface loopback 1
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 1.1.1.9 enable
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
The configurations of devices in AS 200 and AS 300 are similar to the configurations of devices
in AS 100, and are not mentioned here.
After the configuration, run the display bgp vpnv4 all peer command on the PE or ASBR, and
you can view that an MP-IBGP peer relationship has been established between the PE and ASBR
and between the ASBRs in the same AS. Take the display on PE1 as an example.
<PE1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peer
PrefRcv
2.2.2.9
AS
MsgRcvd
MsgSent
100
18970
19008
OutQ
Up/Down
0 91:51:24
State
Established
Step 4 Configure VPN instances on the PEs and connect the CEs to the PEs.
# Configure PE1.
Issue 01 (2011-10-15)
266
# Configure PE2.
[~PE2] ip vpn-instance vpna
[~PE2-vpn-instance-vpna] ipv4-family
[~PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[~PE2-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE2-vpn-instance-vpna-af-ipv4] quit
[~PE2-vpn-instance-vpna] quit
[~PE2] interface gigabitethernet 2/0/0
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[~PE2-GigabitEthernet2/0/0] ip address 10.2.1.2 24
[~PE2-GigabitEthernet2/0/0] commit
[~PE2-GigabitEthernet2/0/0] quit
After the configuration, run the display ip vpn-instance verbose command on PEs to view the
configurations of VPN instances.
<PE1> display ip vpn-instance verbose
Total VPN-Instances configured : 1
VPN-Instance Name and ID : vpna, 1
Interfaces : GigabitEthernet2/0/0
Address family ipv4
Create date : 2009/09/18 11:30:35
Up time : 0 days, 00 hours, 05 minutes and 19 seconds
Route Distinguisher : 100:1
Export VPN Targets : 111:1
Import VPN Targets : 111:1
Label policy: label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
Step 5 Set up EBGP peer relationships between the PEs and CEs, and import VPN routes to the loopback
interfaces of the CEs to BGP.
# Configure CE1.
[~CE1] interface loopback 1
[~CE1-Loopback1] ip address 11.11.11.11 32
[~CE1-Loopback1] quit
[~CE1] bgp 65001
[~CE1-bgp] peer 10.1.1.2 as-number 100
[~CE1-bgp] quit
[~CE1] commit
The configuration of CE2 is similar to the configuration of CE1, and is not mentioned here. For
details, see "Configuration Files."
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpna
[~PE1-bgp-vpna] peer 10.1.1.1 as-number 65001
[~PE1-bgp-vpna] commit
[~PE1-bgp-vpna] quit
The configuration of PE2 is similar to the configuration of PE1, and is not mentioned here. For
details, see "Configuration Files."
Issue 01 (2011-10-15)
267
After the configuration, run the display bgp vpnv4 vpn-instance peer command on the PEs,
and you can view that BGP peer relationships have been established between the PEs and CEs.
Take the peer relationship between PE1 and CE1 as an example.
<PE1> display bgp vpnv4 vpn-instance vpna peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V
AS MsgRcvd MsgSent
OutQ Up/Down
State
PrefRcv
10.1.1.1
4
65001 11
9
0
00:06:37
Established 1
Step 6 Set up an MP-EBGP peer relationship between the ASBRs in different ASs, and configure the
ASBRs not to filter received VPNv4 routes based on VPN targets.
# On ASBR2, enable MPLS on POS 2/0/0 that connects ASBR2 to ASBR1.
<ASBR2> system-view
[~ASBR2] interface pos 2/0/0
[~ASBR2-Pos2/0/0] ip address 192.1.1.2 24
[~ASBR2-Pos2/0/0] mpls
[~ASBR2-Pos2/0/0] commit
[~ASBR2-Pos2/0/0] quit
# On ASBR1, set up an MP-EBGP peer relationship between ASBR1 and ASBR2, and configure
ASBR1 not to filter received VPNv4 routes based on VPN targets.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 192.1.1.2 as-number 200
[~ASBR1-bgp] ipv4-family vpnv4
[~ASBR1-bgp-af-vpnv4] peer 192.1.1.2 enable
[~ASBR1-bgp-af-vpnv4] undo policy vpn-target
[~ASBR1-bgp-af-vpnv4] commit
[~ASBR1-bgp-af-vpnv4] quit
[~ASBR1-bgp] quit
# On ASBR2, set up an MP-EBGP peer relationship between ASBR2 and ASBR1, and configure
ASBR2 not to filter received VPNv4 routes based on VPN targets.
[~ASBR2] bgp 200
[~ASBR2-bgp] peer 192.1.1.1 as-number 100
[~ASBR2-bgp] ipv4-family vpnv4
[~ASBR2-bgp-af-vpnv4] peer 192.1.1.1 enable
[~ASBR2-bgp-af-vpnv4] undo policy vpn-target
[~ASBR2-bgp-af-vpnv4] commit
[~ASBR2-bgp-af-vpnv4] quit
[~ASBR2-bgp] quit
The configuration of the peer relationship between ASBR3 and ASBR4 is similar to
configuration of the pper relationship between ASBR1 and ASBR2, and is not mentioned here.
After the configuration, run the display bgp vpnv4 all peer command, and you can view that
the MP-EBGP peer relationships between the ASBRs have been established. Take the display
on ASBR1 as an example.
<PE1> display bgp vpnv4 all peer
BGP local router ID : 2.2.2.9
Local AS number : 100
Total number of peers : 2
Peer
PrefRcv
1.1.1.9
3.3.3.9
Issue 01 (2011-10-15)
AS
MsgRcvd
MsgSent
4
4
100
200
17533
12343
17554
34554
OutQ
Up/Down
State
0 127:24:5 Established
0 127:24:5 Established
1
1
268
Run the display bgp vpnv4 all routing-table command on the ASBRs, and you can view the
VPNv4 routes on the ASBRs.
Take the display on ASBR1 as an example.
<ASBR1> display bgp vpnv4 all routing-table
Local AS number : 100
BGP Local router ID is 2.2.2.9
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 2
Route Distinguisher: 100:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>i 11.11.11.11/32
1.1.1.9
0
100
0
?
Route Distinguisher: 200:1
Network
NextHop
MED
LocPrf
PrefVal Path/Ogn
*>
22.22.22.22/32
192.1.1.2
0
200?
----End
Configuration Files
l
Issue 01 (2011-10-15)
269
bgp 65001
peer 10.1.1.2 as-number 100
network 11.11.11.11 255.255.255.255
#
ipv4-family unicast
undo synchronization
peer 10.1.1.2 enable
return
Issue 01 (2011-10-15)
270
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.1.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
peer 192.1.1.2 as-number 200
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 192.1.1.2 enable
peer 1.1.1.9 enable
#
ipv4-family vpnv4
undo policy vpn-target
peer 1.1.1.9 enable
peer 192.1.1.2 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
271
undo synchronization
peer 192.1.1.1 enable
peer 4.4.4.9 enable
#
ipv4-family vpnv4
undo policy vpn-target
peer 4.4.4.9 enable
peer 192.1.1.1 enable
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 162.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
272
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 152.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 5.5.5.9 255.255.255.255
#
bgp 300
peer 192.2.1.1 as-number 200
peer 6.6.6.9 as-number 300
peer 6.6.6.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 192.2.1.1 enable
peer 6.6.6.9 enable
#
ipv4-family vpnv4
undo policy vpn-target
peer 6.6.6.9 enable
peer 192.2.1.1 enable
#
ospf 1
area 0.0.0.0
network 6.6.6.9 0.0.0.0
network 152.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
273
#
bgp 300
peer 5.5.5.9 as-number 300
peer 5.5.5.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 5.5.5.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 5.5.5.9 enable
#
ipv4-family vpn-instance vpna
peer 10.2.1.1 as-number 65002
#
ospf 1
area 0.0.0.0
network 6.6.6.9 0.0.0.0
network 152.1.1.0 0.0.0.255
#
return
Related Tasks
2.12 Configuring Inter-AS VPN Option B (Spanning More Than Two ASs)
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
Issue 01 (2011-10-15)
274
The multi-VPN-instance CE (MCE) isolates different VPN services on a LAN through CEs and
ensures the security of the VPN services.
As shown in Figure 2-41:
l
CE1 and CE2 belong to the same LAN; the MCE, CE3, and CE4 belong to the same VPN.
The MCE is a CE that can be connected to multiple VPNs whose services are isolated
completely.
CE1 and CE3 belong to vpna; CE2 and CE4 belong to vpnb.
It is required that devices in the same VPN be able to communicate whereas devices in different
VPNs be unable to communicate.
Figure 2-41 Networking of a multi-VPN-instance CE
vpna
CE1
POS1/0/0
10.1.1.1/24
Loopback1
11.11.11.11/32
Loopback1
33.33.33.33/32
CE3
POS1/0/0
10.3.1.1/24
Loopback1
2.2.2.9/32
POS1/0/0
POS2/0/0
192.1.1.1/24 192.1.1.2/24
POS3/0/0
10.3.1.2/24
vpna
POS1/0/0
POS3/0/0
POS2/0/0
POS2/0/0 PE1 172.1.1.2/24 PE2 192.2.1.1/24 192.2.1.2/24
10.2.1.2/24
MCE
vpnb
POS4/0/0
10.4.1.2/24
POS1/0/0
10.2.1.1/24
POS1/0/0
10.4.1.1/24
POS1/0/0
10.1.1.2/24
Loopback1
1.1.1.9/32
vpna
CE2
POS3/0/0
172.1.1.1/24
Loopback1
22.22.22.22/32
Loopback1
44.44.44.44/32
vpnb
CE4
vpnb
Configuration Notes
When configuring a multi-VPN-instance CE, note the following:
l
The MCE needs to be configured with different VPN instances and different interfaces are
bound to the VPN instances.
The OSPF multi-instance processes need to be configured on the PEs and MCE to exchange
routes; the MCE needs to be configured not to check routing loops.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Issue 01 (2011-10-15)
Configure OSPF on the PEs to implement interworking between the PEs, and configure
MP-IBGP to exchange VPN routing information.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
275
2.
Set up an EBGP peer relationship between each PE and its connected CE, and import the
VPN routes to the VPN routing table of each PE.
3.
Configure OSPF multi-instance on the MCE and PE2 to exchange VPN routing
information, and run RIP-2 between the MCE and CE3 and between the MCE and CE4 to
exchange VPN routing information.
NOTE
When configuring OSPF multi-instance between the MCE and PE2, you need to do as follows:
l In the OSPF view of PE2, import the BGP route and advertise the private route of PE1 to the MCE.
l In the BGP view of PE2, import the OSPF route and advertise the private route of the MCE to PE1.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances on PE1, PE2, and the MCE (different
VPN instances have different VPN targets)
OSPF process IDs used for OSPF multi-instances (different services have different OSPF
process IDs)
IDs of RIP processes used to import VPN routes of CE3 and CE4 to the MCE (RIP process
IDs must be different for the VPN routes of CE3 and CE4)
Procedure
Step 1 Configure OSPF on the PEs on the backbone network to interconnect the PEs.
The configuration is not mentioned here. For details, see "Configuration Files."
After the configuration, PEs can learn the routes to loopback1 of each other.
Take the display on PE2 as an example.
<PE2> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 7
Routes : 7
Destination/Mask Proto Pre Cost
Flags NextHop
Interface
1.1.1.9/32 OSPF
10
2
D 172.1.1.1
Pos1/0/0
2.2.2.9/32 Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
172.1.1.0/24 Direct 0
0
D 172.1.1.2
Pos1/0/0
172.1.1.1/32 Direct 0
0
D 172.1.1.1
Pos1/0/0
172.1.1.2/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Step 2 Configure basic MPLS functions and MPLS LDP on the PEs, and set up LDP LSPs between the
PEs on the MPLS backbone network.
The configuration is not mentioned here. For details, see "Configuration Files."
After the configuration, run the display mpls ldp session command on the PEs, and you can
view that the MPLS LDP session between the PEs is Operational.
Take the display on PE2 as an example.
<PE2> display mpls ldp session
LDP Session(s) in Public Network
-------------------------------------------------------------------------Peer-ID
Status
LAM SsnRole SsnAge
KA-Sent/Rcv
Issue 01 (2011-10-15)
276
-------------------------------------------------------------------------1.1.1.9:0
Operational DU
Active
000:00:04
17/17
-------------------------------------------------------------------------TOTAL: 1 session(s) Found.
LAM : Label Advertisement Mode
SsnAge Unit : DDD:HH:MM
Step 3 Configure VPN instances on the PEs; connect CE1 and CE2 to PE1 and connect the MCE to
PE2.
# Configure PE1.
<PE1> system-view
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv4-family
[~PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE1-vpn-instance-vpna-af-ipv4] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] ip vpn-instance vpnb
[~PE1-vpn-instance-vpnb] ipv4-family
[~PE1-vpn-instance-vpnb-af-ipv4] route-distinguisher 100:2
[~PE1-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[~PE1-vpn-instance-vpnb-af-ipv4] quit
[~PE1-vpn-instance-vpnb] quit
[~PE1] interface pos1/0/0
[~PE1-Pos1/0/0] ip binding vpn-instance vpna
[~PE1-Pos1/0/0] ip address 10.1.1.2 24
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
[~PE1] interface pos2/0/0
[~PE1-Pos2/0/0] ip binding vpn-instance vpnb
[~PE1-Pos2/0/0] ip address 10.2.1.2 24
[~PE1-Pos2/0/0] commit
[~PE1-Pos2/0/0] quit
# Configure PE2.
<PE2> system-view
[~PE2] ip vpn-instance vpna
[~PE2-vpn-instance-vpna] ipv4-family
[~PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 200:1
[~PE2-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[~PE2-vpn-instance-vpna-af-ipv4] quit
[~PE2-vpn-instance-vpna] quit
[~PE2] ip vpn-instance vpnb
[~PE2-vpn-instance-vpnb] ipv4-family
[~PE2-vpn-instance-vpnb-af-ipv4] route-distinguisher 200:2
[~PE2-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[~PE2-vpn-instance-vpnb-af-ipv4] quit
[~PE2-vpn-instance-vpnb] quit
[~PE2] interface pos2/0/0
[~PE2-Pos2/0/0] ip binding vpn-instance vpna
[~PE2-Pos2/0/0] ip address 192.1.1.1 24
[~PE2-Pos2/0/0] commit
[~PE2-Pos2/0/0] quit
[~PE2]interface pos3/0/0
[~PE2-Pos3/0/0] ip binding vpn-instance vpnb
[~PE2-Pos3/0/0] ip address 192.2.1.1 24
[~PE2-Pos3/0/0] commit
[~PE2-Pos3/0/0] quit
Step 4 Configure VPN instances on the MCE, and connect CE3, CE4, and PE2 to the MCE.
<HUAWEI> system-view
[~HUAWEI] sysname MCE
[~MCE] ip vpn-instance vpna
[~MCE-vpn-instance-vpna] route-distinguisher 100:1
[~MCE-vpn-instance-vpna] vpn-target 111:1 both
[~MCE-vpn-instance-vpna] commit
[~MCE-vpn-instance-vpna] quit
Issue 01 (2011-10-15)
277
Step 5 Create an MP-IBGP peer relationship between the PEs, and create an EBGP peer relationship
between PE1 and CE1, and between PE1 and CE2.
The configuration is not mentioned here. For details, see "Configuration Files."
After the configuration, run the display bgp vpnv4 all peer command on PE1, and you can view
that an IBGP peer relationship has been established between PE1 and PE2, and an EBGP peer
relationship has been established between PE1 and CE1 and between PE1 and CE2.
<PE1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 3
Peer
V
AS MsgRcvd
2.2.2.9
4
100
13
Peer of vpn instance :
MsgSent
10
11
0 00:04:14 Established
12
0 00:04:09 Established
Issue 01 (2011-10-15)
vpna
network 192.1.1.0 0.0.0.255
commit
quit
bgp
vpnb
network 192.2.1.0 0.0.0.255
commit
quit
bgp
278
[~PE2-ospf-200] quit
[~PE2] bgp 100
[~PE2-bgp] ipv4-family vpn-instance vpna
[~PE2-bgp-vpna] import-route ospf 100
[~PE2-bgp-vpna] commit
[~PE2-bgp-vpna] quit
[~PE2-bgp] ipv4-family vpn-instance vpnb
[~PE2-bgp-vpnb] import-route ospf 200
[~PE2-bgp-vpnb] commit
[~PE2-bgp-vpnb] quit
vpna
network 192.1.1.0 0.0.0.255
commit
quit
vpnb
network 192.2.1.0 0.0.0.255
commit
quit
vpn-instance vpna
version 2
network 10.0.0.0
import-route ospf 100
commit
quit
vpn-instance vpnb
version 2
network 10.0.0.0
import-route ospf 200
commit
# Configure CE3.
<HUAWEI> system-view
[~HUAWEI] sysname CE3
[~CE3] rip 100
[~CE3-rip-100] verdion 2
[~CE3-rip-100] network 10.0.0.0
[~CE3-rip-100] network 33.33.33.33
[~CE3-rip-100] commit
# Configure CE4.
<HUAWEI> system-view
[~HUAWEI] sysname CE4
[~CE4] rip 200
[~CE4-rip-200] version 2
[~CE4-rip-200] network 10.0.0.0
[~CE4-rip-200] network 44.44.44.44
[~CE4-rip-200] commit
Step 8 Configure the MCE not to detect routing loops and import RIP routes.
<MCE> system-view
[~MCE] ospf 100 vpn-instance vpna
[~MCE-ospf-100] vpn-instance-capability simple
[~MCE-ospf-100] import-route rip 100
[~MCE-ospf-100] commit
Issue 01 (2011-10-15)
279
quit
vpn-instance vpnb
vpn-instance-capability simple
import-route rip 200
commit
Run the display ip routing-table vpn-instance command on the PEs, and you can view that
the PEs have routes to their peer CEs.
Take vpna on PE1 as an example.
<PE1> display ip routing-table vpn-instance vpna
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: vpna
Destinations : 5
Routes : 5
Destination/Mask Proto Pre Cost
Flags NextHop
Interface
10.1.1.0/24 Direct 0
0
D 10.1.1.2
Pos1/0/0
10.1.1.1/32 Direct 0
0
D 10.1.1.1
Pos1/0/0
10.1.1.2/32 Direct 0
0
D 127.0.0.1
InLoopBack0
33.33.33.33/32 BGP
255 2
RD 2.2.2.9
Pos3/0/0
CE1 and CE3 can successfully ping each other; CE2 and CE4 can successfully ping each other.
Take CE1 as an example.
[~CE1] ping -a 11.11.11.11 33.33.33.33
PING 33.33.33.33: 56 data bytes, press CTRL_C to break
Reply from 33.33.33.33: bytes=56 Sequence=1 ttl=252 time=125
Reply from 33.33.33.33: bytes=56 Sequence=2 ttl=252 time=125
Reply from 33.33.33.33: bytes=56 Sequence=3 ttl=252 time=125
Reply from 33.33.33.33: bytes=56 Sequence=4 ttl=252 time=125
Reply from 33.33.33.33: bytes=56 Sequence=5 ttl=252 time=125
--- 33.33.33.33 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 125/125/125 ms
ms
ms
ms
ms
ms
CE1 cannot successfuly ping CE2 or CE4; CE3 cannot successfully ping CE2 or CE4.
For example, if you ping CE4 from CE1, the display is as follows:
[~CE1] ping -a 11.11.11.11 44.44.44.44
PING 44.44.44.44: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Issue 01 (2011-10-15)
280
----End
Configuration Files
l
Issue 01 (2011-10-15)
281
ipv4-family
route-distinguisher 100:2
vpn-target 222:2 export-extcommunity
vpn-target 222:2 import-extcommunity
#
mpls lsr-id 1.1.1.9
#
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpna
ip address 10.1.1.2 255.255.255.0
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpnb
ip address 10.2.1.2 255.255.255.0
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
peer 2.2.2.9 as-number 100
peer 2.2.2.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
ipv4-family vpn-instance vpna
peer 10.1.1.1 as-number 65410
#
ipv4-family vpn-instance vpnb
peer 10.2.1.1 as-number 65420
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
282
route-distinguisher 200:2
vpn-target 222:2 export-extcommunity
vpn-target 222:2 import-extcommunity
#
mpls lsr-id 2.2.2.9
#
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpna
ip address 192.1.1.1 255.255.255.0
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpnb
ip address 192.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
ipv4-family vpn-instance vpna
import-route ospf 100
#
ipv4-family vpn-instance vpnb
import-route ospf 200
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
ospf 100 vpn-instance vpna
import-route bgp
area 0.0.0.0
network 192.1.1.0 0.0.0.255
#
ospf 200 vpn-instance vpnb
import-route bgp
area 0.0.0.0
network 192.2.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
283
#
ip vpn-instance vpna
ipv4-family
route-distinguisher 100:1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
ip vpn-instance vpnb
ipv4-family
route-distinguisher 200:2
vpn-target 222:2 export-extcommunity
vpn-target 222:2 import-extcommunity
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpna
ip address 192.1.1.2 255.255.255.0
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpnb
ip address 192.2.1.2 255.255.255.0
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpna
ip address 10.3.1.2 255.255.255.0
#
interface Pos4/0/0
undo shutdown
link-protocol ppp
ip binding vpn-instance vpnb
ip address 10.4.1.2 255.255.255.0
#
ospf 100 vpn-instance vpna
import-route rip 100
vpn-instance-capability simple
area 0.0.0.0
network 192.1.1.0 0.0.0.255
#
ospf 200 vpn-instance vpnb
import-route rip 200
vpn-instance-capability simple
area 0.0.0.0
network 192.2.1.0 0.0.0.255
#
rip 100 vpn-instance vpna
version 2
network 10.0.0.0
import-route ospf 100
#
rip 200 vpn-instance vpnb
version 2
network 10.0.0.0
import-route ospf 200
#
return
Issue 01 (2011-10-15)
284
interface Loopback 1
undo shutdown
ip address 33.33.33.33 255.255.255.255
#
rip 100
version 2
network 10.0.0.0
network 33.33.33.33
#
return
Related Tasks
2.13 Configuring the Multi-VPN-Instance CE
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
The networking is shown in Figure 2-42. It is required that a backup next hop be configured on
PE1 with PE3 serving as a backup to PE2. In this manner, when PE2 fails, the traffic can be
quickly switched to PE3.
Issue 01 (2011-10-15)
285
Figure 2-42 Networking diagram of VPN FRR with FRR switchover being implemented on a
PE
Loopback1
2.2.2.2/32
VPN backbone
Loopback1
POS1/0/0
1.1.1.1/32 AS100
100.1.1.2/30
POS2/0/0
100.1.1.1/30
PE1
POS3/0/0
100.2.1.1/30
PE2
GE2/0/0
10.1.1.2/30
GE1/0/0
10.1.1.1/30
Link_A
CE
Link_B
GE2/0/0
10.2.1.1/30
POS1/0/0
100.2.1.2/30
PE3
GE2/0/0
10.2.1.2/30
vpn1 site
AS65410
Loopback1
11.11.11.11/32
Loopback1
3.3.3.3/32
Configuration Notes
When configuring VPN FRR with FRR switchover being implemented on a PE, note the
following:
l
The CE is dual-homed to two PEs configured with VPN instances of different RDs.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure OSPF on the MPLS backbone network on which PE1, PE2, and PE3 reside to
implement interworking of PEs on the backbone network.
2.
Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the
MPLS backbone network.
3.
Configure VPN instances on PE1, PE2, and PE3 and connect the CE to both PE2 and PE3.
4.
Establish MP-EBGP peer relationships between each PE and the CE and import VPN
routes; set up MP-IBGP peer relationships between the PEs.
5.
Data Preparation
To complete the configuration, you need the following data:
l
AS 100 where the PEs reside and AS 65410 where the CE resides
Procedure
Step 1 Assign an IP address to each interface of devices on the VPN backbone network and VPN sites.
The configuration is not mentioned here.
Issue 01 (2011-10-15)
286
Step 2 Configure OSPF on the MPLS backbone network to implement interworking of PEs on the
backbone network. The configuration is not mentioned here.
Step 3 Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the MPLS
backbone network.
# Configure PE1.
<PE1> system-view
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos2/0/0
[~PE1-Pos2/0/0] mpls
[~PE1-Pos2/0/0] mpls ldp
[~PE1-Pos2/0/0] commit
[~PE1-Pos2/0/0] quit
[~PE1] interface pos3/0/0
[~PE1-Pos3/0/0] mpls
[~PE1-Pos3/0/0] mpls ldp
[~PE1-Pos3/0/0] commit
[~PE1-Pos3/0/0] quit
# Configure PE2.
<PE2> system-view
[~PE2] mpls lsr-id 2.2.2.2
[~PE2] mpls
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] quit
[~PE2] interface pos1/0/0
[~PE2-Pos1/0/0] mpls
[~PE2-Pos1/0/0] mpls ldp
[~PE2-Pos1/0/0] commit
[~PE2-Pos1/0/0] quit
# Configure PE3.
<PE3> system-view
[~PE3] mpls lsr-id 3.3.3.3
[~PE3] mpls
[~PE3-mpls] quit
[~PE3] mpls ldp
[~PE3-mpls-ldp] quit
[~PE3] interface pos1/0/0
[~PE3-Pos1/0/0] mpls
[~PE3-Pos1/0/0] mpls ldp
[~PE3-Pos1/0/0] commit
[~PE3-Pos1/0/0] quit
Run the display mpls lsp command on the PEs, and you can view that an LSP is established
between PE1 and PE2 and between PE1 and PE3. Take the display on PE1 as an example.
<PE1> display mpls lsp
---------------------------------------------------------------------LSP Information: LDP LSP
---------------------------------------------------------------------FEC
In/Out Label In/Out IF
Vrf Name
3.3.3.3/32
NULL/3
-/Pos3/0/0
1.1.1.1/32
3/NULL
-/100.1.1.0/30
3/NULL
-/3.3.3.3/32
1024/3
-/Pos3/0/0
100.2.1.0/30
3/NULL
-/2.2.2.2/32
NULL/3
-/Pos2/0/0
2.2.2.2/32
1025/3
-/Pos2/0/0
Issue 01 (2011-10-15)
287
Step 4 Configure VPN instances on the PEs and connect the CE to both PE2 and PE3.
# Configure PE1.
[~PE1] ip vpn-instance vpn1
[~PE1-vpn-instance-vpn1] ipv4-family
[~PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1
[~PE1-vpn-instance-vpn1-af-ipv4] quit
[~PE1-vpn-instance-vpn1] quit
[~PE1] commit
# Configure PE2.
[~PE2] ip vpn-instance vpn1
[~PE2-vpn-instance-vpn1] ipv4-family
[~PE2-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:2
[~PE2-vpn-instance-vpn1-af-ipv4] vpn-target 111:1
[~PE2-vpn-instance-vpn1-af-ipv4] quit
[~PE2-vpn-instance-vpn1] quit
[~PE2] interface gigabitethernet2/0/0
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE2-GigabitEthernet2/0/0] ip address 10.1.1.2 30
[~PE2-GigabitEthernet2/0/0] commit
[~PE2-GigabitEthernet2/0/0] quit
# Configure PE3.
[~PE3] ip vpn-instance vpn1
[~PE3-vpn-instance-vpn1] ipv4-family
[~PE3-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:3
[~PE3-vpn-instance-vpn1-af-ipv4] vpn-target 111:1
[~PE3-vpn-instance-vpn1-af-ipv4] quit
[~PE3-vpn-instance-vpn1] quit
[~PE3] interface gigabitethernet2/0/0
[~PE3-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE3-GigabitEthernet2/0/0] ip address 10.2.1.2 30
[~PE3-GigabitEthernet2/0/0] commit
[~PE3-GigabitEthernet2/0/0] quit
Step 5 Set up MP-EBGP peer relationships between PE2 and the CE and between PE3 and the CE, and
import VPN routes destined to the loopback interface of the CE.
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] ipv4-family vpn-instance vpn1
[~PE2-bgp-vpn1] peer 10.1.1.1 as-number 65410
[~PE2-bgp-vpn1] commit
[~PE2-bgp-vpn1] quit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] ipv4-family vpn-instance vpn1
[~PE3-bgp-vpn1] peer 10.2.1.1 as-number 65410
[~PE3-bgp-vpn1] commit
[~PE3-bgp-vpn1] quit
Issue 01 (2011-10-15)
288
[~CE] commit
# Configure PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance vpn1
[~PE1-bgp-vpn1] commit
[~PE1-bgp-vpn1] quit
After the configuration, run the display bgp vpnv4 vpn-instance peer command on PE2 and
PE3, and you can view that an EBGP peer relationship has been established between PE2 and
the CE and between PE3 and the CE.
Take the display on PE2 as an example.
<PE2> display bgp vpnv4 vpn-instance vpn1 peer
BGP local router ID : 2.2.2.2
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V
AS MsgRcvd MsgSent OutQ Up/Down
State PrefRcv
10.1.1.1
4
65410
46
46
0 00:37:41 Established
5
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 1.1.1.1 as-number 100
[~PE2-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE2-bgp] ipv4-family vpnv4
[~PE2-bgp-af-vpnv4] peer 1.1.1.1 enable
[~PE2-bgp-af-vpnv4] commit
[~PE2-bgp-af-vpnv4] quit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] peer 1.1.1.1 as-number 100
[~PE3-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE3-bgp] ipv4-family vpnv4
[~PE3-bgp-af-vpnv4] peer 1.1.1.1 enable
[~PE3-bgp-af-vpnv4] commit
[~PE3-bgp-af-vpnv4] quit
After the configuration, run the display bgp vpnv4 all peer command on the PEs, and you can
view that the MP-IBGP peer relationships have been established.
Take the display on PE1 as an example.
<PE1> display bgp vpnv4 all peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 2
Peer
V
AS MsgRcvd
2.2.2.2
4
100
20
Issue 01 (2011-10-15)
MsgSent
17
289
24
19
0 00:17:18 Established
# Display the backup next hop, backup tag, and backup tunnel ID.
<PE1> display ip routing-table vpn-instance vpn1 11.11.11.11 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpn1
Summary Count : 1
Destination: 11.11.11.11/32
Protocol: BGP
Process ID: 0
Preference: 255
Cost: 0
NextHop: 2.2.2.2
Neighbour: 2.2.2.2
State: Active Adv Relied
Age: 00h15m06s
Tag: 0
Priority: low
Label: 15361
QoSInfo: 0x0
IndirectID: 0x13
RelayNextHop: 0.0.0.0
Interface: Pos2/0/0
TunnelID: 0x6002002
Flags: RD
BkNextHop: 3.3.3.3
BkInterface:Unknown
BkLabel: 15362
SecTunnelID: 0x0
BkPETunnelID: 0x6002000 BkPESecTunnelID: 0x0
BkIndirectID: 0x15
----End
Configuration Files
l
Issue 01 (2011-10-15)
290
#
bgp 100
peer 2.2.2.2 as-number 100
peer 2.2.2.2 connect-interface LoopBack1
peer 3.3.3.3 as-number 100
peer 3.3.3.3 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpn1
auto-frr
#
ospf 1
area 0.0.0.0
network 100.1.1.0 0.0.0.3
network 100.2.1.0 0.0.0.3
network 1.1.1.1 0.0.0.0
#
return
Issue 01 (2011-10-15)
291
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance vpn1
peer 10.1.1.1 as-number 65410
#
ospf 1
area 0.0.0.0
network 100.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
#
bfd for_ip_frr bind peer-ip 1.1.1.1
discriminator local 20
discriminator remote 10
#
return
Issue 01 (2011-10-15)
292
Related Tasks
2.14 Configuring VPN FRR
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
At a VPN site, different CEs use BGP to access the same PE. The PE has learned multiple IP
VPN routes with the same VPN prefix from the CEs. To enable the system to select a primary
route and a backup route, you can deploy FRR for IP routes on the private network. If this feature
is configured, the PE generates a primary route and a backup route to the same destination on
the private network. After that, IP traffic can be quickly switched to the link of the backup route
when the link of the primary route fails.
As shown in Figure 2-43, an EBGP peer relationship is set up between the PE and each CE.
There are two BGP routes from the PE to Loopback 1 on Router A. The optimal route resides
Issue 01 (2011-10-15)
293
on Link_A; the sub-optimal route resides on Link_B. FRR for IP routes must be deployed on
the PE to allow IPv6 traffic to be quickly switched to Link_B when Link_A fails.
Figure 2-43 Networking diagram for configuring FRR for IP routes on a private network
GE1/0/0
10.1.1.2/24
GE1/0/0
10.1.1.1/24
VPN
backbone
PE
Link_A
Link_B
CE1
GE2/0/0
30.1.1.1/24
GE1/0/0
30.1.1.2/24
RouterA
vpn1
site
Loopback 1
11.11.11.11/32
GE2/0/0
GE2/0/0
20.1.1.1/24 GE1/0/0
40.1.1.2/24
GE2/0/0
20.1.1.2/24 CE2 40.1.1.1/24
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP at the VPN site to advertise the route of Loopback 1 on Router A to CE1
and CE2.
2.
Create a VPN instance named vpna on the PE, and bind GE 1/0/0 and GE 2/0/0 to vpna.
3.
Establish an EBGP peer relationship between the PE and CE1, and between the PE and
CE2. On CE1 and CE2, configure an IGP and BGP to import routes from each other.
4.
Enable IPv6 Auto FRR for the private network on the PE.
Data Preparation
To complete the configuration, you need the following data:
l
VPN instance name (vpna) and attributes of the VPN instance IPv4 address family, for
example, the RD (100:1) and VPN target (100:100), on the PE
MEDs configured for the IGP routes imported into BGP on CE1 and CE2
Procedure
Step 1 Configure IP addresses for the interfaces on the routers at the VPN site.
For details on the configuration procedure, see the following configuration files.
Step 2 Configure an IGP at the VPN site to advertise the route of Loopback 1 on Router A to CE1 and
CE2. In this example, OSPF is configured as an IGP.
# Configure CE1.
[~CE1] ospf 1
[~CE1-ospf] area 0
[~CE1-ospf-1-area-0.0.0.0] network 30.1.1.0 0.0.0.255
Issue 01 (2011-10-15)
294
[~CE1-ospf-1-area-0.0.0.0] quit
[~CE1-ospf] quit
[~CE1] commit
The configurations of CE2 and Router A are similar to the configuration of CE1. For details on
the configuration procedure, see the following configuration files.
After the configuration is complete, run the display ip routing-table command on the CEs, and
you can find that CE1 and CE2 have learned the route to Loopback 1 on Router A. The following
takes the display on CE1 as an example:
<CE1> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : _public_
Destinations : 10
Routes : 10
Destination/Mask
Proto
10.1.1.0/24 Direct
GigabitEthernet1/0/0
10.1.1.1/32 Direct
GigabitEthernet1/0/0
10.1.1.2/32 Direct
GigabitEthernet1/0/0
11.11.11.11/32 OSPF
GigabitEthernet2/0/0
30.1.1.0/24 Direct
GigabitEthernet2/0/0
30.1.1.1/32 Direct
GigabitEthernet2/0/0
30.1.1.255/32 Direct
GigabitEthernet2/0/0
40.1.1.0/24 OSPF
GigabitEthernet2/0/0
127.0.0.0/8
Direct
127.0.0.1/32 Direct
Pre
Cost
Flags NextHop
10.1.1.2
10.1.1.1
127.0.0.1
10
30.1.1.2
30.1.1.1
127.0.0.1
127.0.0.1
10
30.1.1.2
0
0
0
0
D
D
127.0.0.1
127.0.0.1
Interface
InLoopBack0
InLoopBack0
Step 3 Configure a VPN instance on the PE and bind the interfaces connecting the PE to the CEs to the
VPN instance.
# Configure a VPN instance named vpna on the PE, and bind GE 1/0/0 and GE 2/0/0 to the
instance.
<PE> system-view
[~PE] ip vpn-instance vpna
[~PE-vpn-instance-vpna] ipv4-family
[~PE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[~PE-vpn-instance-vpna-af-ipv4] vpn-target 100:100
[~PE-vpn-instance-vpna-af-ipv4] quit
[~PE-vpn-instance-vpna] quit
[~PE] interface gigabitethernet 1/0/0
[~PE-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[~PE-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[~PE-GigabitEthernet1/0/0] quit
[~PE] interface gigabitethernet 2/0/0
[~PE-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[~PE-GigabitEthernet2/0/0] ip address 20.1.1.1 24
[~PE-GigabitEthernet2/0/0] commit
[~PE] quit
Issue 01 (2011-10-15)
295
# Configure CE1.
[~CE1] bgp
[~CE1-bgp]
[~CE1-bgp]
[~CE1-bgp]
65410
peer 10.1.1.1 as-number 100
commit
quit
# Configure CE2.
[~CE2] bgp
[~CE2-bgp]
[~CE2-bgp]
[~CE2-bgp]
65410
peer 20.1.1.1 as-number 100
commit
quit
After the configuration is complete, run the display bgp vpnv4 vpn-instance vpna peer
command on the PE, and you can find that the status of the EBGP peer relationship between the
PE and CEs is Established. It indicates that the EBGP peer relationships have been set up
between the PE and CEs.
<PE> display bgp vpnv4 vpn-instancee vpna peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 2
Peer
PrefRcv
10.1.1.2
1
20.1.1.2
1
AS
MsgRcvd
MsgSent
OutQ
Up/Down
State
65410
21
23
0 00:17:47 Established
65410
51
64
0 00:15:03 Established
Step 5 Configure route exchange between OSPF and BGP on the CEs.
# Configure CE1.
[~CE1] bgp 100
[~CE1-bgp] network 11.11.11.11 32
[~CE1-bgp] quit
[~CE1] ospf 1
[~CE1-ospf-1] import-route bgp
[~CE1-ospf-1] quit
[~CE1] commit
# Configure CE2.
[~CE2] bgp 100
[~CE2-bgp] network 11.11.11.11 32
[~CE2-bgp] quit
[~CE2] ospf 1
[~CE2-ospf-1] import-route bgp
[~CE2-ospf-10] quit
[~CE2] commit
After the configuration is complete, run the display ip routing-table vpn-instance command
on the PE, and you can find the route to Loopback 1 on Router A in the command output.
<PE> display ip routing-table vpn-instance vpna
display ip routing-table vpn-instance vpna
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpna
Destinations : 7
Routes : 7
Issue 01 (2011-10-15)
296
Pre
Cost
10.1.1.0/24 Direct 0
0
GigabitEthernet1/0/0
10.1.1.1/32 Direct 0
0
GigabitEthernet1/0/0
10.1.1.2/32 Direct 0
0
GigabitEthernet1/0/0
11.11.11.11/32 BGP
255 1
GigabitEthernet1/0/0
20.1.1.0/24 Direct 0
0
GigabitEthernet2/0/0
20.1.1.1/32 Direct 0
0
GigabitEthernet2/0/0
20.1.1.255/32 Direct 0
0
Flags NextHop
D
10.1.1.1
127.0.0.1
10.1.1.2
Interface
RD 10.1.1.2
20.1.1.1
127.0.0.1
127.0.0.1
GigabitEthernet2/0/0
Step 6 Enable BGP Auto FRR for the private network on the PE.
# Configure the PE.
[~PE] bgp 100
[~PE-bgp] ipv4-family vpn-instance vpna
[~PE-bgp-vpna] auto-frr
[~PE-bgp-vpna] quit
[~PE-bgp] quit
[~PE] commit
NOTE
The auto-frr command configured in the BGP-VPN instance IPv4 address family view is valid for only the
networking where BGP runs between the PE and CEs.
0
1
0.0.0.0
00h35m31s
low
0x0
GigabitEthernet1/0/0
RD
GigabitEthernet2/0/0
0x0
0x0
Run the display ip routing-table vpn-instance command on the PE. You can find that the next
hop to 11.11.11.11/32 is 20.1.1.2, and the PE does not have a backup next hop or a backup
outbound interface.
Issue 01 (2011-10-15)
297
0
1
0.0.0.0
00h00m04s
low
0x0
GigabitEthernet2/0/0
RD
FRR configured for IP routes on the private network has taken effect.
----End
Configuration Files
l
Issue 01 (2011-10-15)
298
#
ipv4-family unicast
undo synchronization
#
ipv4-family unicast
undo synchronization
network 11.11.11.11 255.255.255.255
peer 10.1.1.1 enable
#
ospf 1
import-route bgp
area 0.0.0.0
network 30.1.1.0 0.0.0.255
#
return
Related Tasks
2.15 Configuring FRR for IP Routes on a Private Network
Issue 01 (2011-10-15)
299
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
A CE at a VPN site is dual-homed to two PEs, and a VPNv4 peer relationship is set up between
the two PEs. To protect one of the PE-CE links, hybrid FRR for IP and VPNv4 routes can be
configured.
If the link fails, hybrid FRR can quickly switch traffic destined for the CE to the backup next
hop (a PE).
As shown in Figure 2-44, a CE is connected to PE2 and PE3; an MPLS public network tunnel
and a VPNv4 peer relationship are set up between PE2 and PE3. OSPF is configured between
PE2 and the CE and EBGP is configured between PE3 and the CE to exchange routing
information. PE3 learns from the CE a route to Loopback 1 on the CE and sends the route to its
VPNv4 peer. PE2 then has two BGP routes to Loopback 1 on the CE. One is learned by using
OSPF, and the other is a VPNv4 route sent from PE3 by using MP-IBGP. PE2 selects the OSPF
route sent from the CE preferably because OSPF takes precedence over BGP. PE3 selects a route
to Loopback 1 on the CE from the routes sent from the CE and PE2 in a similar manner.
The requirements are as follows:
l
PE2 must be configured to make the VPNv4 route sent from PE3 serve as a backup for the
OSPF route sent from the CE.
PE3 must be configured to select the EBGP route sent from the CE preferably and use the
IBGP route sent from PE2 as a backup route.
If the link between a PE and the CE fails, downstream traffic can be switched to the other PE to
reach the CE.
To meet the requirements, enable FRR for IP routes on the private network on PE2 and enable
BGP Auto FRR on PE3 to implement hybrid FRR for IP and VPNv4 routes.
Issue 01 (2011-10-15)
300
Figure 2-44 Networking diagram for configuring hybrid FRR for IP and VPNv4 routes
VPNbackbone
Loopback1
2.2.2.2 /32
PE2
Loopback1
POS1/0/0
1.1.1.1/32 AS100
100.1.1.2/30
POS2/0/0
100.1.1.1/30
POS3/0/0
110.1.1.1/30
PE1
POS3/0/0
110.1.1.2/30
POS3/0/0
100.2.1.1/30
POS1/0/0
100.2.1.2/30
GE2/0/0
192.168.1.1/30
Loopback1
22.22.22.22/32
GE1/0/0
192.168.1.2/30
AS65410
CE
GE2/0/0
192.168.2.2/30
vpn1 site
GE2/0/0
192.168.2.1/30
PE3
Loopback1
3.3.3.3 /32
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure OSPF on the MPLS backbone network for IP connectivity between PE1, PE2,
and PE3.
2.
Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the
MPLS backbone network.
3.
4.
Configure a VPN instance on each PE, and connect the CE to PE2 and PE3.
5.
6.
Enable IP FRR for the VPN instance on PE2, and enable BGP Auto FRR on PE3.
Procedure
Step 1 Configure IP addresses for interfaces on the backbone network of the VPN and interfaces at the
VPN site. Details for configuration procedures are not provided here.
Step 2 Configure OSPF on the MPLS backbone network for IP connectivity between the PEs on the
backbone network. Details for configuration procedures are not provided here.
Step 3 Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the MPLS
backbone network.
# Configure PE1.
<PE1> system-view
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos2/0/0
[~PE1-Pos2/0/0] mpls
[~PE1-Pos2/0/0] mpls ldp
[~PE1-Pos2/0/0] quit
[~PE1] interface pos3/0/0
[~PE1-Pos3/0/0] mpls
[~PE1-Pos3/0/0] mpls ldp
Issue 01 (2011-10-15)
301
[~PE1-Pos3/0/0] quit
[~PE1] commit
# Configure PE2.
<PE2> system-view
[~PE2] mpls lsr-id 2.2.2.2
[~PE2] mpls
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] quit
[~PE2] interface pos1/0/0
[~PE2-Pos1/0/0] mpls
[~PE2-Pos1/0/0] mpls ldp
[~PE2-Pos1/0/0] quit
[~PE2] interface pos3/0/0
[~PE2-Pos3/0/0] mpls
[~PE2-Pos3/0/0] mpls ldp
[~PE2-Pos3/0/0] quit
[~PE2] commit
# Configure PE3.
<PE3> system-view
[~PE3] mpls lsr-id 3.3.3.3
[~PE3] mpls
[~PE3-mpls] quit
[~PE3] mpls ldp
[~PE3-mpls-ldp] quit
[~PE3] interface pos1/0/0
[~PE3-Pos1/0/0] mpls
[~PE3-Pos1/0/0] mpls ldp
[~PE3-Pos1/0/0] quit
[~PE3] interface pos3/0/0
[~PE3-Pos3/0/0] mpls
[~PE3-Pos3/0/0] mpls ldp
[~PE3-Pos3/0/0] quit
[~PE3] commit
Run the display mpls lsp command on the PEs. You can see that LSPs have been set up between
PE1 and PE2, and between PE1 and PE3. The following uses the display on PE1 as an example:
[~PE1] display mpls lsp
---------------------------------------------------------------------LSP Information: LDP LSP
---------------------------------------------------------------------FEC
In/Out Label In/Out IF
Vrf Name
2.2.2.2/32
NULL/3
-/Pos2/0/0
2.2.2.2/32
1024/3
-/Pos2/0/0
3.3.3.3/32
NULL/3
-/Pos3/0/0
3.3.3.3/32
1025/3
-/Pos3/0/0
# Configure PE2.
Issue 01 (2011-10-15)
302
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] peer 1.1.1.1 as-number 100
[~PE3-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE3-bgp] peer 2.2.2.2 as-number 100
[~PE3-bgp] peer 2.2.2.2 connect-interface loopback 1
[~PE3-bgp] ipv4-family vpnv4
[~PE3-bgp-af-vpnv4] peer 1.1.1.1 enable
[~PE3-bgp-af-vpnv4] peer 2.2.2.2 enable
[~PE3-bgp-af-vpnv4] quit
[~PE3-bgp] quit
[~PE3] commit
After the configuration is complete, run the display bgp vpnv4 all peer command on the PEs.
You can find that the status of the MP-IBGP peer relationship between the PEs is
Established. This means that the MP-IBGP peer relationships have been successfully set up.
The following uses the display on PE1 as an example:
[~PE1] display bgp vpnv4 all peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 2
Peer
V
AS MsgRcvd MsgSent
2.2.2.2
4
100
20
17
3.3.3.3
4
100
24
19
Step 5 Configure a VPN instance on each PE, and connect the CE to PE2 and PE3.
# Configure PE1.
[~PE1] ip vpn-instance vpn1
[~PE1-vpn-instance-vpn1] ipv4-family
[~PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-vpn1-af-ipv4] vpn-target 111:1
[~PE1-vpn-instance-vpn1-af-ipv4] quit
[~PE1-vpn-instance-vpn1] quit
[~PE1] commit
# Configure PE2.
[~PE2] ip vpn-instance vpn1
[~PE2-vpn-instance-vpn1] ipv4-family
[~PE2-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:2
[~PE2-vpn-instance-vpn1-af-ipv4] vpn-target 111:1
[~PE2-vpn-instance-vpn1-af-ipv4] quit
[~PE2-vpn-instance-vpn1] quit
[~PE2] interface gigabitethernet2/0/0
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE2-GigabitEthernet2/0/0] ip address 192.168.1.1 30
[~PE2-GigabitEthernet2/0/0] quit
[~PE2] commit
# Configure PE3.
[~PE3] ip vpn-instance vpn1
Issue 01 (2011-10-15)
303
[~PE3-vpn-instance-vpn1] ipv4-family
[~PE3-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:3
[~PE3-vpn-instance-vpn1-af-ipv4] vpn-target 111:1
[~PE3-vpn-instance-vpn1-af-ipv4] quit
[~PE3-vpn-instance-vpn1] quit
[~PE3] interface gigabitethernet2/0/0
[~PE3-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE3-GigabitEthernet2/0/0] ip address 192.168.2.1 30
[~PE3-GigabitEthernet2/0/0] quit
[~PE3] commit
Step 6 Configure an OSPF instance on PE2 and the CE and set up an EBGP peer relationship between
PE3 and the CE.
# Configure PE2.
[~PE2] ospf 2 vpn-instance vpn1
[~PE2-ospf-2] import-route bgp
[~PE2-ospf-2] area 1
[~PE2-ospf-2-area-0.0.0.1] network 192.168.1.0.0 0.0.0.252
[~PE2-ospf-2-area-0.0.0.1] quit
[~PE2-ospf-2] quit
[~PE2] bgp 100
[~PE2-bgp] ipv4-family vpn-instance vpn1
[~PE2-bgp-vpn1] import-route ospf 2
[~PE2-bgp-vpn1] quit
[~PE2-bgp] quit
[~PE2] commit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] ipv4-family vpn-instance vpn1
[~PE3-bgp-vpn1] peer 192.168.2.2 as-number 65410
[~PE3-bgp-vpn1] bestroute as-path-ignore
[~PE3-bgp-vpn1] quit
[~PE3-bgp] quit
[~PE3] commit
After the configuration is complete, run the display ip routing-table vpn-instance vpn1
22.22.22.22 verbose command on PE2, and you can find the route to Loopback 1 on the CE in
the command output.
<PE2> display ip routing-table vpn-instance vpn1 22.22.22.22 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpn1
Summary Count : 2
Destination: 22.22.22.22/32
Protocol: OSPF
Preference: 10
NextHop: 192.168.1.2
State: Active Adv
Issue 01 (2011-10-15)
Process ID:
Cost:
Neighbour:
Age:
2
1
0.0.0.0
00h11m08s
304
0
NULL
0x76
0.0.0.0
0x0
Destination: 22.22.22.22/32
Protocol: BGP
Process ID:
Preference: 255
Cost:
NextHop: 3.3.3.3
Neighbour:
State: Inactive Adv
Age:
Tag: 0
Priority:
Label: 0x23
QoSInfo:
IndirectID: 0xb7
RelayNextHop: 0.0.0.0
Interface:
TunnelID: 0x0000000001004c4c62 Flags:
0
0
0.0.0.0
00h13m25s
low
0x0
LDP LSP
R
The command output shows that PE2 has learned the routes to Loopback 1 on the CE from the
CE by using OSPF and from PE3 by using BGP. Because OSPF takes precedence over BGP,
PE2 selects the OSPF route advertised by PE3 preferably.
Step 7 Enable IP Auto FRR for the VPN instance IPv4 address family on PE2.
# Configure PE2.
[~PE2] ip vpn-instance vpn1
[~PE2-vpn-instance-vpn1] ipv4-family
[~PE2-vpn-instance-vpn1-af-ipv4] ip frr
[~PE2-vpn-instance-vpn1-af-ipv4] quit
[~PE2-vpn-instance-vpn1] quit
[~PE2] commit
Step 8 Enable BGP Auto FRR for the BGP-VPN instance IPv4 address family on PE3.
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] ipv4-family vpn-instance vpn1
[~PE3-bgp-vpn1] auto-frr
[~PE3-bgp-vpn1] quit
[~PE3-bgp] quit
[~PE3] commit
Issue 01 (2011-10-15)
305
Destination: 22.22.22.22/32
Protocol: BGP
Process ID: 0
Preference: 255
Cost: 0
NextHop: 3.3.3.3
Neighbour: 0.0.0.0
State: Inactive Adv
Age: 00h28m57s
Tag: 0
Priority: low
Label: 0x23
QoSInfo: 0x0
IndirectID: 0xb7
RelayNextHop: 0.0.0.0
Interface: LDP LSP
TunnelID: 0x0000000001004c4c62 Flags: R
<PE3> display ip routing-table vpn-instance vpn1 22.22.22.22 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpn1
Summary Count : 1
Destination: 22.22.22.22/32
Protocol: BGP
Process ID:
Preference: 255
Cost:
NextHop: 192.168.2.2
Neighbour:
State: Active Adv Relied
Age:
Tag: 0
Priority:
Label: NULL
QoSInfo:
IndirectID: 0xa9
RelayNextHop: 192.168.2.2
Interface:
TunnelID: 0x0
Flags:
BkNextHop: 0.0.0.0
BkInterface:
BkLabel: 0x27
SecTunnelID:
BkPETunnelID: 0x0
BkPESecTunnelID:
BkIndirectID: 0xaa
0
0
0.0.0.0
00h00m31s
low
0x0
GigabitEthernet2/0/0
RD
LDP LSP
0x5000098
0x0
The command output shows that after IP FRR is enabled, both PE2 and PE3 have the primary
and backup routes to Loopback 1 on the CE, and the backup route is iterated to an LDP LSP.
Run the shutdown command and then the display ip routing-table vpn-instance verbose
command on GE 2/0/0 on PE2. You can find that the next hop to the loopback interface on the
CE is changed to PE3.
<PE2> display ip routing-table vpn-instance vpn1 22.22.22.22 verbose
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Table : vpn1
Summary Count : 1
Destination: 22.22.22.22/32
Protocol: BGP
Process ID: 0
Preference: 255
Cost: 0
NextHop: 3.3.3.3
Neighbour: 0.0.0.0
State: Active Adv Relied
Age: 00h33m16s
Tag: 0
Priority: low
Label: 0x23
QoSInfo: 0x0
IndirectID: 0xb7
RelayNextHop: 0.0.0.0
Interface:LDP LSP
TunnelID: 0x0000000001004c4c62 Flags: RD
Perform the same operation on PE3, and you can view similar information.
Hybrid FRR for IP and VPNv4 routes has taken effect on PE2 and PE3.
----End
Configuration Files
l
Issue 01 (2011-10-15)
306
ip vpn-instance vpn1
ipv4-family
route-distinguisher 100:1
vpn-target 111:1 export-extcommunity
vpn-target 111:1 import-extcommunity
#
mpls lsr-id 1.1.1.1
#
mpls
#
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 100.2.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
interface LoopBack2
ip binding vpn-instance vpn1
ip address 11.11.11.11 255.255.255.255
#
bgp 100
peer 2.2.2.2 as-number 100
peer 2.2.2.2 connect-interface LoopBack1
peer 3.3.3.3 as-number 100
peer 3.3.3.3 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpn1
import-route direct
#
ospf 1
area 0.0.0.0
network 100.1.1.0 0.0.0.3
network 100.2.1.0 0.0.0.3
network 1.1.1.1 0.0.0.0
#
return
Issue 01 (2011-10-15)
307
#
mpls lsr-id 2.2.2.2
#
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface GigabitEthernet2/0/0
undo shutdown
ip binding vpn-instance vpn1
ip address 192.168.1.1 255.255.255.252
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 110.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
peer 1.1.1.1 as-number 100
peer 1.1.1.1 connect-interface LoopBack1
peer 3.3.3.3 as-number 100
peer 3.3.3.3 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpn1
import-route ospf 2
#
ospf 1
area 0.0.0.0
network 100.1.1.0 0.0.0.3
network 110.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
#
ospf 2 vpn-instance vpn1
import-route bgp
area 0.0.0.1
network 192.168.1.0 0.0.0.252
#
return
Issue 01 (2011-10-15)
308
#
mpls lsr-id 3.3.3.3
#
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 100.2.1.2 255.255.255.252
mpls
mpls ldp
#
interface GigabitEthernet2/0/0
undo shutdown
ip binding vpn-instance vpn1
ip address 192.168.2.1 255.255.255.252
#
interface Pos3/0/0
undo shutdown
link-protocol ppp
ip address 110.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
peer 1.1.1.1 as-number 100
peer 1.1.1.1 connect-interface LoopBack1
peer 2.2.2.2 as-number 100
peer 2.2.2.2 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
peer 2.2.2.2 enable
#
ipv4-family vpn-instance vpn1
bestroute as-path-ignore
auto-frr
peer 192.168.2.2 as-number 65410
#
ospf 1
area 0.0.0.0
network 100.2.1.0 0.0.0.3
network 110.1.1.0 0.0.0.3
network 3.3.3.3 0.0.0.0
#
Return
Issue 01 (2011-10-15)
309
interface LoopBack1
ip address 22.22.22.22 255.255.255.255
#
bgp 65410
peer 192.168.2.1 as-number 100
#
ipv4-family unicast
undo synchronization
network 22.22.22.22 255.255.255.255
peer 192.168.2.1 enable
#
ospf 1
area 0.0.0.1
network 22.22.22.22 0.0.0.0
network 192.168.1.0 0.0.0.252
#
return
Related Tasks
2.16 Configuring Hybrid FRR for IP and VPNv4 Routes
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-45, CE1 and CE2 belong to VPN A. Two default routes with the next
hops as PE1 and PE2 respectively are configured on CE1. The two routes carry out load
balancing. The static routes bound to VPN A are configured on PE1 and PE2 separately and are
imported to BGP.
BFD sessions are established between PE1 and CE1, and between PE2 and CE1. It is required
that BFD be configured on PE1 and PE2 to detect static VPN routes. In normal situations, the
traffic from CE1 to the public network can be forwarded through PE1 and PE2 in load balancing
mode. If the link between CE1 and PE1 or PE2 fails, the static route senses the link fault by
tracking BFD session status and CE1 updates the route. Then the traffic is forwarded through
the other link.
Issue 01 (2011-10-15)
310
Configuration Notes
When configuring BFD for static VPN routes, note the following:
l
The CE is dual-homed to two PEs configured with VPN instances of different RDs.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure OSPF between the PEs to implement interworking between the PEs.
2.
3.
Configure VPN instances on the PEs and bind each interface that connects a PE to a CE to
a VPN instance.
4.
5.
Configure two default routes with the next hops as PE1 and PE2 respectively on CE1 to
implement load balancing between PE1 and PE2.
6.
Configure the static route bound to VPN A on PE1 and PE2 and import the static route into
BGP.
7.
8.
Configure static BFD sessions with automatically negotiated discriminators between PE1
and CE1, and between PE2 and CE1.
9.
Data Preparation
To complete the configuration, you need the following data:
Issue 01 (2011-10-15)
311
Names, RDs, and VPN targets of the VPN instances on the PEs
Procedure
Step 1 Configure an IGP on the MPLS backbone network to interconnect the devices on the backbone
network.
# Configure PE1.
<HUAWEI> system-view
[~HUAWEI] sysname PE1
[~PE1] interface loopback 1
[~PE1-LoopBack1] ip address 2.2.2.2 32
[~PE1-LoopBack1] commit
[~PE1-LoopBack1] quit
[~PE1] interface pos 1/0/0
[~PE1-Pos1/0/0] ip address 100.1.1.1 24
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
[~PE1] interface pos 2/0/0
[~PE1-Pos2/0/0] ip address 100.3.1.1 24
[~PE1-Pos2/0/0] commit
[~PE1-Pos2/0/0] quit
[~PE1] ospf
[~PE1-ospf-1] area 0
[~PE1-ospf-1-area-0.0.0.0] network 100.1.1.0 0.0.0.255
[~PE1-ospf-1-area-0.0.0.0] network 100.3.1.0 0.0.0.255
[~PE1-ospf-1-area-0.0.0.0] network 2.2.2.2 0.0.0.0
[~PE1-ospf-1-area-0.0.0.0] commit
[~PE1-ospf-1-area-0.0.0.0] quit
[~PE1-ospf-1] quit
Configure PE2.
<HUAWEI> system-view
[~HUAWEI] sysname PE2
[~PE2] interface loopback 1
[~PE2-LoopBack1] ip address 3.3.3.3 32
[~PE2-LoopBack1] commit
[~PE2-LoopBack1] quit
[~PE2] interface pos 1/0/0
[~PE2-Pos1/0/0] ip address 100.2.1.1 24
[~PE2-Pos1/0/0] commit
[~PE2-Pos1/0/0] quit
[~PE2] interface pos 2/0/0
[~PE2-Pos2/0/0] ip address 100.3.1.2 24
[~PE2-Pos2/0/0] commit
[~PE2-Pos2/0/0] quit
[~PE2] ospf
[~PE2-ospf-1] area 0
[~PE2-ospf-1-area-0.0.0.0] network 100.2.1.0 0.0.0.255
[~PE2-ospf-1-area-0.0.0.0] network 100.3.1.0 0.0.0.255
[~PE2-ospf-1-area-0.0.0.0] network 3.3.3.3 0.0.0.0
[~PE2-ospf-1-area-0.0.0.0] commit
[~PE2-ospf-1-area-0.0.0.0] quit
[~PE2-ospf-1] quit
Configure PE3.
<HUAWEI> system-view
[~HUAWEI] sysname PE3
[~PE3] interface loopback 1
[~PE3-LoopBack1] ip address 4.4.4.4 32
[~PE3-LoopBack1] [~PE3-LoopBack1] quit
[~PE3-LoopBack1] [~PE3-LoopBack1] quit
Issue 01 (2011-10-15)
312
[~PE3-LoopBack1] quit
[~PE3] interface pos 1/0/0
[~PE3-Pos1/0/0] ip address
[~PE3-Pos1/0/0] commit
[~PE3-Pos1/0/0] quit
[~PE3] interface pos 2/0/0
[~PE3-Pos2/0/0] ip address
[~PE3-Pos2/0/0] commit
[~PE3-Pos2/0/0] quit
[~PE3] ospf
[~PE3-ospf-1] area 0
[~PE3-ospf-1-area-0.0.0.0]
[~PE3-ospf-1-area-0.0.0.0]
[~PE3-ospf-1-area-0.0.0.0]
[~PE3-ospf-1-area-0.0.0.0]
[~PE3-ospf-1-area-0.0.0.0]
[~PE3-ospf-1] quit
100.1.1.2 24
100.2.1.2 24
After the configuration, OSPF neighbor relationships can be set up between PE1, PE2, and PE3.
Run the display ip routing-table command, and you can view that the PEs have learnt the routes
to Loopback1 of each other.
Take the display on PE1 as an example.
<PE1> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 12
Routes : 13
Destination/Mask
2.2.2.2/32
3.3.3.3/32
4.4.4.4/32
127.0.0.0/8
127.0.0.1/32
100.3.1.0/24
100.3.1.1/32
100.3.1.2/32
100.1.1.0/24
100.1.1.1/32
100.1.1.2/32
100.2.1.0/24
Proto
Pre
Cost
Direct
OSPF
OSPF
Direct
Direct
Direct
Direct
Direct
Direct
Direct
Direct
OSPF
OSPF
0
10
10
0
0
0
0
0
0
0
0
10
10
0
2
2
0
0
0
0
0
0
0
0
2
2
Flags NextHop
D
D
D
D
D
D
D
D
D
D
D
D
D
127.0.0.1
100.3.1.2
100.1.1.2
127.0.0.1
127.0.0.1
100.3.1.1
127.0.0.1
100.3.1.2
100.1.1.1
127.0.0.1
100.1.1.2
100.1.1.2
100.3.1.2
Interface
InLoopBack0
Pos2/0/0
Pos1/0/0
InLoopBack0
InLoopBack0
Pos2/0/0
InLoopBack0
Pos2/0/0
Pos1/0/0
InLoopBack0
Pos1/0/0
Pos1/0/0
Pos2/0/0
Step 2 Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the MPLS
backbone network.
# Configure PE1.
[~PE1] mpls lsr-id 2.2.2.2
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos 1/0/0
[~PE1-Pos1/0/0] mpls
[~PE1-Pos1/0/0] mpls ldp
[~PE1-Pos1/0/0] commit
[~PE1-Pos1/0/0] quit
[~PE1] interface pos 2/0/0
[~PE1-Pos2/0/0] mpls
[~PE1-Pos2/0/0] mpls ldp
[~PE1-Pos2/0/0] commit
[~PE1-Pos2/0/0] quit
# Configure PE2.
Issue 01 (2011-10-15)
313
Configure PE3.
[~PE3] mpls lsr-id 4.4.4.4
[~PE3] mpls
[~PE3-mpls] quit
[~PE3] mpls ldp
[~PE3-mpls-ldp] quit
[~PE3] interface pos 1/0/0
[~PE3-Pos1/0/0] mpls
[~PE3-Pos1/0/0] mpls ldp
[~PE3-Pos1/0/0] commit
[~PE3-Pos1/0/0] quit
[~PE3] interfacepos 2/0/0
[~PE3-Pos2/0/0] mpls
[~PE3-Pos2/0/0] mpls ldp
[~PE3-Pos2/0/0] commit
[~PE3-Pos2/0/0] quit
After the preceding configuration, LDP sessions can be set up between the PEs. Run the display
mpls ldp session command, and you can view that the Status field is displayed as
Operational.
Take the display on PE1 as an example.
<PE1> display mpls ldp session
LDP Session(s) in Public Network
-----------------------------------------------------------------------------Peer-ID
Status
LAM SsnRole SsnAge
KA-Sent/Rcv
-----------------------------------------------------------------------------3.3.3.3:0
Operational DU
Passive 000:02:22
572/572
4.4.4.4:0
Operational DU
Passive 000:02:21
566/566
-----------------------------------------------------------------------------TOTAL: 2 session(s) Found.
LAM : Label Advertisement Mode
SsnAge Unit : DDD:HH:MM
Step 3 Configure VPN instances on the PEs and connect the CEs to the PEs.
# Configure PE1.
[~PE1] ip vpn-instance VPNA
[~PE1-vpn-instance-VPNA] ipv4-family
[~PE1-vpn-instance-VPNA-af-ipv4] route-distinguisher 100:1
[~PE1-vpn-instance-VPNA-af-ipv4] vpn-target 111:1 both
[~PE1-vpn-instance-VPNA-af-ipv4] quit
[~PE1-vpn-instance-VPNA] quit
[~PE1] interface gigabitethernet 3/0/0
[~PE1-GigabitEthernet3/0/0] ip binding vpn-instance VPNA
[~PE1-GigabitEthernet3/0/0] ip address 10.1.1.2 24
[~PE1-GigabitEthernet3/0/0] commit
[~PE1-GigabitEthernet3/0/0] quit
# Configure PE2.
Issue 01 (2011-10-15)
314
# Configure PE3.
[~PE3] ip vpn-instance VPNA
[~PE3-vpn-instance-VPNA] ipv4-family
[~PE3-vpn-instance-VPNA-af-ipv4] route-distinguisher 100:3
[~PE3-vpn-instance-VPNA-af-ipv4] vpn-target 111:1 both
[~PE3-vpn-instance-VPNA-af-ipv4] quit
[~PE3-vpn-instance-VPNA] quit
[~PE3] interface gigabitethernet 3/0/0
[~PE3-GigabitEthernet3/0/0] ip binding vpn-instance VPNA
[~PE3-GigabitEthernet3/0/0] ip address 10.3.1.1 24
[~PE3-GigabitEthernet3/0/0] commit
[~PE3-GigabitEthernet3/0/0] quit
Configure CE1.
[~CE1] interface gigabitethernet 1/0/0
[~CE1-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[~CE1-GigabitEthernet1/0/0] commit
[~CE1-GigabitEthernet1/0/0] quit
[~CE1] interface gigabitethernet 2/0/0
[~CE1-GigabitEthernet2/0/0] ip address 10.2.1.1 24
[~CE1-GigabitEthernet2/0/0] quit
# Configure CE2.
[~CE2] interface gigabitethernet 1/0/0
[~CE2-GigabitEthernet1/0/0] ip address 10.3.1.2 24
[~CE2-GigabitEthernet1/0/0] commit
[~CE2-GigabitEthernet1/0/0] quit
After the configuration, run the display ip vpn-instance verbose command on PEs to view the
configurations of VPN instances. Each PE can successfully ping its connected CE.
Take PE1 and CE1 as an example:
<PE1> display ip vpn-instance verbose
Total VPN-Instances configured : 1
VPN-Instance Name and ID : VPNA, 1
Interfaces : GigabitEthernet3/0/0
Address family ipv4
Create date : 2008/09/21 12:18:46
Up time : 0 days, 02 hours, 35 minutes and 58 seconds
Route Distinguisher : 100:1
Export VPN Targets : 111:1
Import VPN Targets : 111:1
Label policy : label per route
The diffserv-mode Information is : uniform
The ttl-mode Information is : pipe
[~PE1] ping -vpn-instance VPNA 10.1.1.1
PING 10.1.1.1: 56 data bytes, press CTRL_C to break
Reply from 10.1.1.1: bytes=56 Sequence=1 ttl=255 time=130 ms
Reply from 10.1.1.1: bytes=56 Sequence=2 ttl=255 time=60 ms
Reply from 10.1.1.1: bytes=56 Sequence=3 ttl=255 time=40 ms
Reply from 10.1.1.1: bytes=56 Sequence=4 ttl=255 time=30 ms
Reply from 10.1.1.1: bytes=56 Sequence=5 ttl=255 time=30 ms
Issue 01 (2011-10-15)
315
Step 4 Import the VPN routes between PE1, PE2, and CE1.
Configure two default routes with the next hops being PE1 and PE2 respectively on CE1 to
implement load balancing between PE1 and PE2. Configure the static routes to be bound to the
VPN instance on PE1 and PE2 and import the static routes into BGP.
# Configure CE1.
[~CE1] load-balance packet all
[~CE1] ip route-static 0.0.0.0 0 10.1.1.2
[~CE1] ip route-static 0.0.0.0 0 10.2.1.2
# Configure PE1.
[~PE1] ip route-static vpn-instance VPNA 1.1.1.1 32 10.1.1.1
[~PE1] bgp 100
[~PE1-bgp] ipv4-family vpn-instance VPNA
[~PE1-bgp-VPNA] import-route direct
[~PE1-bgp-VPNA] import-route static
[~PE1-bgp-VPNA] commit
[~PE1-bgp-VPNA] quit
# Configure PE2.
[~PE2] ip route-static vpn-instance VPNA 1.1.1.1 32 10.2.1.1
[~PE2] bgp 100
[~PE2-bgp] ipv4-family vpn-instance VPNA
[~PE2-bgp-VPNA] import-route direct
[~PE2-bgp-VPNA] import-route static
[~PE2-bgp-VPNA] commit
[~PE2-bgp-VPNA] quit
Step 5 Set up an EBGP peer relationship between PE3 and CE2, and import VPN routes to EBGP.
# Configure CE2.
[~CE2] bgp 65410
[~CE2-bgp] peer 10.3.1.1 as-number 100
[~CE2-bgp] import-route direct
[~CE2-bgp] commit
[~CE2] quit
# Configure PE3. Configure the number of routes carrying out load balancing to 2 on PE3.
[~PE3] bgp 100
[~PE3-bgp] ipv4-family vpn-instance VPNA
[~PE3-bgp-VPNA] peer 10.3.1.2 as-number 65410
[~PE3-bgp-VPNA] import-route direct
[~PE3-bgp-VPNA] maximum load-balancing 2
[~PE3-bgp-VPNA] commit
[~PE3-bgp-VPNA] quit
Issue 01 (2011-10-15)
316
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 2.2.2.2 as-number 100
[~PE2-bgp] peer 2.2.2.2 connect-interface loopback 1
[~PE2-bgp] peer 4.4.4.4 as-number 100
[~PE2-bgp] peer 4.4.4.4 connect-interface loopback 1
[~PE2-bgp] ipv4-family vpnv4
[~PE2-bgp-af-vpnv4] peer 2.2.2.2 enable
[~PE2-bgp-af-vpnv4] peer 4.4.4.4 enable
[~PE2-bgp-af-vpnv4] commit
[~PE2-bgp-af-vpnv4] quit
[~PE2-bgp] quit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] peer 2.2.2.2 as-number 100
[~PE3-bgp] peer 2.2.2.2 connect-interface loopback 1
[~PE3-bgp] peer 3.3.3.3 as-number 100
[~PE3-bgp] peer 3.3.3.3 connect-interface loopback 1
[~PE3-bgp] ipv4-family vpnv4
[~PE3-bgp-af-vpnv4] peer 2.2.2.2 enable
[~PE3-bgp-af-vpnv4] peer 3.3.3.3 enable
[~PE3-bgp-af-vpnv4] commit
[~PE3-bgp-af-vpnv4] quit
[~PE3-bgp] quit
After the configuration, run the display bgp peer command on the PEs, and you can view that
the BGP peer relationships have been established between the PEs.
<PE1> display bgp peer
BGP local router ID : 2.2.2.2
Local AS number : 100
Total number of peers : 2
Peer
AS
MsgRcvd
MsgSent
4.4.4.4
3.3.3.3
4
4
100
100
205
197
202
254
OutQ
Up/Down
State PrefRcv
0 03:05:25 Established
0 03:06:54 Established
0
0
# Configure PE2.
[~PE2] bfd
[~PE2-bfd] quit
[~PE2] bfd pe2_to_ce1 bind peer-ip 10.2.1.1 vpn-instance VPNA interface
gigabitethernet 3/0/0 source-ip 10.2.1.2 auto
[~PE2-bfd-session-pe2_to_ce1] commit
[~PE2-bfd-session-pe2_to_ce1] quit
# Configure CE1.
Issue 01 (2011-10-15)
317
[~CE1] bfd
[~CE1-bfd] quit
[~CE1] bfd ce1_to_pe1 bind peer-ip 10.1.1.2 interface gigabitethernet 1/0/0 sourceip 10.1.1.1 auto
[~CE1-bfd-session-ce1_to_pe1] commit
[~CE1-bfd-session-ce1_to_pe1] quit
[~CE1] bfd ce1_to_pe2 bind peer-ip 10.2.1.2 interface gigabitethernet 2/0/0 source
-ip 10.2.1.1 auto
[~CE1-bfd-session-ce1_to_pe2] commit
[~CE1-bfd-session-ce1_to_pe2] quit
After the configuration, run the display bfd session all verbose command on the PEs and CEs,
and you can view that a one-hop static auto-negotiation BFD session is set up, and the session
status is Up. The local and remote IDs of the BFD session are obtained through auto-negotiation.
Take PE1 and CE1 as an example:
# The display on PE1 is as follows:
<PE1> display bfd session all verbose
-------------------------------------------------------------------------------Session MIndex : 16384
(One Hop) State : Up
Name : pe1_to_ce1
-------------------------------------------------------------------------------Local Discriminator
: 8192
Remote Discriminator
: 8192
Session Detect Mode
: Asynchronous Mode Without Echo Function
BFD Bind Type
: Interface(GigabitEthernet3/0/0)
Bind Session Type
: Static_Auto
Bind Peer IP Address
: 10.1.1.1
NextHop Ip Address
: 10.1.1.1
Bind Interface
: GigabitEthernet3/0/0
Bind Source IP Address : 10.1.1.2
Vpn Instance Name
: VPNA
FSM Board Id
: 3
TOS-EXP
: 6
Min Tx Interval (ms)
: 10
Min Rx Interval (ms)
: 10
Actual Tx Interval (ms): Actual Rx Interval (ms): Local Detect Multi
: 3
Detect Interval (ms)
: Echo Passive
: Disable
Acl Number
: Destination Port
: 3784
TTL
: 254
Proc Interface Status : Disable
Process PST
: Disable
WTR Interval (ms)
: Local Demand Mode
: Disable
Active Multi
: 3
Last Local Diagnostic : No Diagnostic
Bind Application
: AUTO
Session TX TmrID
: Session Detect TmrID
: Session Init TmrID
: Session WTR TmrID
: Session Echo Tx TmrID : PDT Index
: FSM-5020000 | RCV-0 | IF-5020000 | TOKEN-0
Session Description
: -------------------------------------------------------------------------------Total UP/DOWN Session Number : 1/0
Issue 01 (2011-10-15)
318
Destination Port
: 3784
TTL
: 255
Proc Interface Status : Disable
Process PST
: Disable
WTR Interval (ms)
: Local Demand Mode
: Disable
Active Multi
: 3
Last Local Diagnostic : No Diagnostic
Bind Application
: AUTO
Session TX TmrID
: Session Detect TmrID
: Session Init TmrID
: Session WTR TmrID
: Session Echo Tx TmrID : PDT Index
: FSM-5020000 | RCV-0 | IF-5020000 | TOKEN-0
Session Description
: --------------------------------------------------------------------------------------------------------------------------------------------------------------Session MIndex : 16384
(One Hop) State : Up
Name : ce1_to_pe2
-------------------------------------------------------------------------------Local Discriminator
: 8193
Remote Discriminator
: 8193
Session Detect Mode
: Asynchronous Mode Without Echo Function
BFD Bind Type
: Interface(GigabitEthernet2/0/0)
Bind Session Type
: Static_Auto
Bind Peer IP Address
: 10.2.1.2
NextHop Ip Address
: 10.2.1.2
Bind Interface
: GigabitEthernet2/0/0
Bind Source IP Address : 10.2.1.1
FSM Board Id
: 3
TOS-EXP
: 6
Min Tx Interval (ms)
: 10
Min Rx Interval (ms)
: 10
Actual Tx Interval (ms): Actual Rx Interval (ms): Local Detect Multi
: 3
Detect Interval (ms)
: Echo Passive
: Disable
Acl Number
: Destination Port
: 3784
TTL
: 255
Proc Interface Status : Disable
Process PST
: Disable
WTR Interval (ms)
: Local Demand Mode
: Disable
Active Multi
: 3
Last Local Diagnostic : No Diagnostic
Bind Application
: AUTO
Session TX TmrID
: Session Detect TmrID
: Session Init TmrID
: Session WTR TmrID
: Session Echo Tx TmrID : PDT Index
: FSM-5020000 | RCV-0 | IF-5020000 | TOKEN-0
Session Description
: -------------------------------------------------------------------------------Total UP/DOWN Session Number : 2/0
# Configure PE2.
[~PE2] ip route-static vpn-instance VPNA 1.1.1.1 255.255.255.255 10.2.1.1 track bfdsession pe2_to_ce1
Issue 01 (2011-10-15)
Proto
Pre
Static 60
Cost
0
Flags NextHop
RD
Interface
10.1.1.1
319
GigabitEthernet3/0/0
10.1.1.0/24 Direct
GigabitEthernet3/0/0
10.1.1.2/32 Direct
10.2.1.0/24 BGP
10.3.1.0/24 BGP
0
255
255
0
0
0
D
RD
RD
10.1.1.2
127.0.0.1
3.3.3.3
4.4.4.4
InLoopBack0
Pos2/0/0
Pos1/0/0
# On CE1, check the gateway through which the packets destined for CE2 pass. You can view
that load balancing is carried out between PE1 and PE2 at the first hop.
<CE1> tracert 10.3.1.2
traceroute to 10.3.1.2(10.3.1.2), max hops: 30 ,packet length: 40
1 10.1.1.2 20 ms 10.2.1.2 1 ms 10.1.1.2 40 ms
2 10.3.1.1 40 ms 30 ms 50 ms
3 10.3.1.2 80 ms 80 ms 60 ms
# Check the routing table on PE3. You can find that there are two routes to PE1 (1.1.1.1), with
the next hops being 3.3.3.3 and 2.2.2.2 respectively. The two routes carry out load balancing.
<PE3> display ip routing-table vpn-instance VPNA
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: VPNA
Destinations : 5
Routes : 6
Destination/Mask
1.1.1.1/32
Proto
Pre
Cost
BGP
BGP
BGP
BGP
Direct
255
255
255
255
0
0
0
0
0
0
RD
RD
RD
RD
D
3.3.3.3
2.2.2.2
2.2.2.2
3.3.3.3
10.3.1.1
Pos2/0/0
Pos1/0/0
Pos1/0/0
Pos2/0/0
127.0.0.1
InLoopBack0
10.1.1.0/24
10.2.1.0/24
10.3.1.0/24
GigabitEthernet3/0/0
10.3.1.1/32 Direct 0
Flags NextHop
Interface
# On CE2, check the traffic destined for CE1, and you can find that load balancing is performed
when the traffic leaves PE3.
[~CE2] tracert 1.1.1.1
traceroute to 1.1.1.1(1.1.1.1), max hops: 30 ,packet length: 40
1 10.3.1.1 9 ms 2 ms 2 ms
2 10.2.1.2 < AS=100 > 6 ms 5 ms 2 ms
3 10.2.1.1 < AS=100 > 6 ms 6 ms 5 ms
# Run the display bfd session all verbose command on PE1, and you can view that the status
of the BFD session is Down.
<PE1> display bfd session all verbose
-------------------------------------------------------------------------------Session MIndex : 16384
(One Hop) State : Down
Name : pe1_to_ce1
-------------------------------------------------------------------------------Local Discriminator
: 8192
Remote Discriminator
: 8192
Session Detect Mode
: Asynchronous Mode Without Echo Function
BFD Bind Type
: Interface(GigabitEthernet3/0/0)
Bind Session Type
: Static_Auto
Bind Peer IP Address
: 10.1.1.1
NextHop Ip Address
: 10.1.1.1
Bind Interface
: GigabitEthernet3/0/0
Bind Source IP Address : 10.1.1.2
FSM Board Id
: 3
TOS-EXP
: 6
Min Tx Interval (ms)
: 10
Min Rx Interval (ms)
: 10
Actual Tx Interval (ms): Actual Rx Interval (ms): Local Detect Multi
: 3
Detect Interval (ms)
: Echo Passive
: Disable
Acl Number
: Destination Port
: 3784
TTL
: 255
Issue 01 (2011-10-15)
320
# Run the display ip routing-table vpn-instance command on PE1 to check the VPN routing
table, and you can view that the next hop of the route destined for CE1 is only PE2.
<PE1> display ip routing-table vpn-instance VPNA
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: VPNA
Destinations : 3
Routes : 3
Destination/Mask
Proto
Pre
1.1.1.1/32 BGP
255 0
10.2.1.0/24 BGP
255
10.3.1.0/24 BGP
255
Cost
Flags NextHop
RD
0
0
3.3.3.3
RD 3.3.3.3
RD 4.4.4.4
Interface
Pos2/0/0
Pos2/0/0
Pos1/0/0
# On CE1, check the gateway through which the packets destined for CE2 pass, and you can
view that load balancing is not carried out between PE1 and PE2 at the first hop, and the traffic
flows only through PE2.
<CE3> tracert 10.3.1.2
traceroute to 10.3.1.2(10.3.1.2), max hops: 30 ,packet length: 40
1 10.2.1.2 50 ms 30 ms 10 ms
2 10.3.1.1 110 ms 70 ms 90 ms
3 10.3.1.2 60 ms 70 ms 80 ms
# Run the display ip routing-table vpn-instance command on PE3 to check the routing table.
You can view that there is only one route to CE1 (1.1.1.1) with the next hop being PE1 (3.3.3.3).
<PE3> display ip routing-table vpn-instance VPNA
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: VPNA
Destinations : 4
Routes : 4
Destination/Mask
Proto
1.1.1.1/32 BGP
10.2.1.0/24 BGP
10.3.1.0/24 Direct
GigabitEthernet3/0/0
10.3.1.1/32 Direct
Pre
Cost
Flags NextHop
255
255
0
0
0
0
RD
RD
D
Interface
3.3.3.3
3.3.3.3
10.3.1.1
Pos2/0/0
Pos2/0/0
127.0.0.1
InLoopBack0
# On CE2, check the traffic destined for CE1, and you can view that the traffic is forwarded
through POS 2/0/0 (10.2.1.2) after the traffic leaves PE3.
[~CE2] tracert 1.1.1.1
traceroute to 1.1.1.1(1.1.1.1), max hops: 30 ,packet length: 40
1 10.3.1.1 9 ms 2 ms 2 ms
2 10.2.1.2 < AS=100 > 6 ms 5 ms 5 ms
3 10.2.1.1 < AS=100 > 6 ms 5 ms 5 ms
Issue 01 (2011-10-15)
321
Use a tester to generate traffic, and the traffic is forwarded through load balancing. After a link
between CE1 and PE1 or a link between CE1 and PE2 fails, you can find that the traffic is
switched in less than 50 ms.
----End
Configuration Files
l
Issue 01 (2011-10-15)
322
import-route static
#
ospf 1
area 0.0.0.0
network 100.1.1.0 0.0.0.255
network 100.3.1.0 0.0.0.255
network 2.2.2.2 0.0.0.0
#
ip route-static vpn-instance VPNA 1.1.1.1 255.255.255.255 10.1.1.1 track bfdsession pe1_to_ce1
#
bfd pe1_to_ce1 bind peer-ip 10.1.1.1 vpn-instance VPNA interface
GigabitEthernet3/0/0 source-ip 10.1.1.2 auto
#
return
Issue 01 (2011-10-15)
323
Issue 01 (2011-10-15)
324
Issue 01 (2011-10-15)
325
326
Issue 01 (2011-10-15)
327
P
CE
CE
IPv6
VPN site
PE
P
IPv6
VPN site
PE
CE
IPv6
VPN site
IPv6 VPN uses Multiprotocol Extensions for BGP-4 (MP-BGP) to advertise VPNv6 routes on
the backbone network, triggers MPLS to allocate labels for IPv6 packet identification, and uses
LSPs and MPLS TE tunnels to transmit VPN services on the backbone network. The working
principle is similar to that of BGP/MPLS IP VPN.
Issue 01 (2011-10-15)
328
Basic Networking
NE5000Es use MP-BGP for VPNv6 route exchange between PEs, and the static route, IS-IS
multi-instance, or BGP4+ for route exchange between PEs and CEs. VPN targets are set on
NE5000Es to control the sending and receiving of VPN routes to achieve multiple VPN
networking topologies.
On an MPLS backbone network, LSPs or MPLS TE tunnels can be used to transmit VPN
services. If VPN services need to be load balanced among different tunnels on a backbone
network, a tunnel policy can be configured.
Inter-AS VPN
Inter-AS VPN is needed when VPN services are transmitted over an MPLS backbone network
that spans multiple ASs. At present, the NE5000E supports inter-AS IPv6 VPN Option A.
Inter-AS IPv6 VPN Option A is applicable to the situation where VPNs and VPN routes
configured on PEs are a few. In inter-AS VPN Option A, Autonomous System Border Routers
(ASBRs) are required to support VPN instances to be capable of managing VPN routes. In
addition, ASBRs must provide dedicated interfaces for inter-AS VPNs. The dedicated interfaces
can be sub-interfaces, physical interfaces, or logical interfaces. Therefore, the requirement for
ASBRs' performance is rather high, but no inter-AS configurations need to be performed on
ASBRs.
Reliability
The following networking model is usually used to improve VPN reliability:
l
A full-mesh MPLS network deployed with hierarchical backup is used as the backbone
network, and devices on the network are connected to each other by using high-speed
interfaces. If there are a great number of PEs, BGP route reflectors (RRs) are configured
to reflect VPNv6 routes, which can reduce MP-IBGP connections.
NE5000Es support load balancing between IPv6 VPN routes or tunnels. This allows VPN
services to be load balanced among different links on the backbone network.
To protect links between PEs, NE5000Es support VPNv6 Fast Reroute (FRR), an end-to-end
fast switching technology, to switch VPN services from a faulty PE to another PE to which a
CE is dual-homed on an IPv6 VPN network.
Different FRR features are provided to protect links between PEs and CEs on different types of
networks.
Issue 01 (2011-10-15)
329
If two CEs at the same site are connected to one PE, VPN IPv6 FRR can be deployed to
quickly switch VPN traffic to the link between the other CE and the PE when a link between
one CE and the PE fails.
If a PE connected to a CE learns routes to the CE from another PE, hybrid FRR can be
deployed to quickly switch VPN traffic to another PE once the link between the PE and
CE fails.
Applicable Environment
IPv6 address family-supporting VPN instances isolate IPv6 VPN routes from public network
routes on PEs, and the routes in an IPv6 address family of different VPN instances from each
other. In an IPv6 address family-supporting VPN instance, routes in an IPv6 address family are
also isolated from routes in an IPv4 address family. In all BGP/MPLS IPv6 VPN networking
solutions, IPv6 address family-supporting VPN instances need to be configured.
Similar to the VPN instance IPv4 address family, the VPN instance IPv6 address family achieves
independence of address space by means of Route Distinguishers (RDs) and controls routes and
IPv6 VPN memberships at the directly-connected site by means of VPN targets.
If VPN targets have been used to control the sending and receiving of IPv6 VPN routes, you can
also apply an import or export routing policy to achieve accurate control. An import routing
policy can filter the routes to be imported into the VPN instance IPv6 address family based on
VPN targets; an export routing policy can filter the IPv6 VPN routes to be advertised to other
PEs.
Pre-configuration Tasks
Before configuring an IPv6 address family-supporting VPN instance, complete the following
tasks:
l
Configuring an import or export routing policy if it needs to be applied to the VPN instance
IPv6 address family
Configuring a tunnel policy if it needs to be applied to the VPN instance IPv6 address
family
Issue 01 (2011-10-15)
330
Configuration Procedures
Figure 3-2 Flowchart for configuring an IPv6 address family-supporting VPN instance
Procedure
Step 1 Run:
system-view
The name of a VPN instance is case-sensitive. For example, vpn1 and VPN1 represent two different VPN
instances.
Issue 01 (2011-10-15)
331
Procedure
Step 1 Run:
system-view
The IPv6 address family is enabled for the VPN instance, and the VPN instance IPv6 address
family view is displayed.
Step 4 Run:
route-distinguisher route-distinguisher
A configured RD cannot be changed or deleted. You need to delete a VPN instance or disable the VPN
instance IPv6 address family before changing or deleting the RD of the VPN instance IPv6 address
family.
Step 5 Run:
vpn-target vpn-target &<1-8> [ both | export-extcommunity | import-extcommunity ]
An IPv6 VPN target extended community is configured for the VPN instance IPv6 address
family.
A VPN target is a BGP extended community attribute. It is used to control the receiving and
advertisement of IPv6 VPN routing information. You can configure a maximum of eight IPv6
VPN targets by using the vpn-target command.
Step 6 (Optional) Run:
prefix limit number { alert-percent | simply-alert }
The maximum number of prefixes of the VPN instance IPv6 address family is configured.
The maximum number of prefixes can be defined for the VPN instance IPv6 address family to
prevent too many prefixes from being imported into the PE.
Issue 01 (2011-10-15)
332
NOTE
If the prefix limit command is run, the system gives a prompt when the number of route prefixes injected
into the routing table of the VPN instance exceeds the limit.
An import routing policy is configured for the VPN instance IPv6 address family.
Step 8 (Optional) Run:
export route-policy policy-name
An export routing policy is configured for the VPN instance IPv6 address family.
Step 9 Run:
commit
Context
By default, the system selects a tunnel in the order of LSPs, CR-LSPs, and Local_IfNet, and
does not perform load balancing.
Do as follows on the PE configured with the VPN instance IPv6 address family:
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
333
Procedure
Step 1 Run:
system-view
MPLS label allocation based on the VPN instance IPv6 address family is configured. All routes
in the VPN instance IPv6 address family are advertised with the same label.
By default, MPLS labels are allocated to routes in the "one label per route" manner. If the number
of routes increases, the number of in-segment entries maintained by the Incoming Label Map
(ILM) increases accordingly, which raises a higher requirement for device capacity.
The NE5000E supports VPN-based MPLS label allocation. One label is allocated to each VPN
instance IPv6 address family. All routes in a VPN instance IPv6 address family are advertised
with the same MPLS label.
Step 5 Run:
commit
Prerequisite
The configurations of the VPN instance IPv6 address family are complete.
Issue 01 (2011-10-15)
334
Procedure
l
Run the display ip vpn-instance command to check VPN instances in the system and
information about the address families supported by the VPN instances.
----End
Example
Run the display ip vpn-instance command. If the preceding configurations are successful, you
can view the name of the created VPN instance and the address family supported by it.
<HUAWEI> display ip vpn-instance
VPN-Instance Name
vpna
vpnb
Address-family
ipv4 ipv6
ipv6
Run the display ip vpn-instance verbose vpn-instance-name command, and you can view
detailed information about the created VPN instance that supports the IPv6 address family,
including the creation time, time during which the instance keeps Up, RD, VPN target, and label
allocation policy.
<HUAWEI> display ip vpn-instance verbose vpna
Total VPN-Instances configured : 1
VPN-Instance Name and ID : vpna, 1
Interfaces : GigabitEthernet1/0/0
Address family ipv6
Create date : 2010/07/20 12:31:47 UTC-08:00
Up time : 0 days, 04 hours, 37 minutes and 05 seconds
Route Distinguisher : 100:1
Export VPN Targets : 22:22
Import VPN Targets : 33:33
Label Policy : label per route
Log Interval : 5
Applicable Environment
On ordinary IPv4 VPNs, IPv4 routing protocols run between PEs, and between PEs and CEs.
In an IPv6 VPN application, however, an IPv6 routing protocol needs to run between PEs and
CEs to provide IPv6 VPN services for users. Static routes, IS-ISv6 multi-instance, or BGP4+
can run between PEs and CEs for route exchange.
In the IPv6 VPN application, an IPv4 routing protocol can still run between PEs. This means
that any PE pair can establish a VPNv6 neighbor relationship by using IPv4 addresses, and
VPNv6 route information can be transmitted over IPv4 tunnels on the backbone network.
Both IPv4 and IPv6 routing protocols can run between a PE-CE pair to provide dual-stack VPN
access services.
Pre-configuration Tasks
Before configuring basic BGP/MPLS IPv6 VPN, complete the following tasks:
Issue 01 (2011-10-15)
335
Configuring an IGP on PEs and Ps on the MPLS backbone network for IP connectivity
Configuring basic MPLS functions on PEs and Ps on the MPLS backbone network
Configuration Procedures
Figure 3-3 Networking for a basic BGP/MPLS IPv6 VPN
Procedure
Step 1 For details on the configuration procedure, see Configuring an IPv6 Address Familysupporting VPN Instance.
----End
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
336
Running the ip binding vpn-instance command on an interface deletes the configured Layer 3 attributes
such as the IPv4 address, IPv6 address, and routing protocol. If these Layer 3 attributes are still required,
you need to configure them again.
An interface cannot be bound to a VPN instance that is not enabled with an address family.
Disabling an address family of a VPN instance will delete the relevant configurations on the interfaces
bound to the VPN instance. Disabling all address families of a VPN instance will unbind the instance from
its bound interfaces.
Step 4 Run:
ipv6 enable
Follow-up Procedure
If an IPv6 address family-enabled VPN instance is bound to a PE interface connecting to a CE,
the interface belongs to the VPN. Packets entering the interface will be forwarded based on the
forwarding information of the VPN instance IPv6 address family.
Procedure
Step 1 Run:
system-view
Issue 01 (2011-10-15)
337
The IP addresses, each with a 32-bit mask, of the loopback interfaces on PEs must be used to establish the
MP-IBGP peer relationship between the PEs. This ensures that the route to the loopback interface can be
iterated to a tunnel. The route to the local loopback interface is advertised to the peer PE by using the IGP
on the MPLS backbone network.
Step 5 Run:
ipv6-family vpnv6
The function that exchanges VPNv6 routing information with the peer is enabled.
Step 7 Run:
commit
Context
Choose one of the following configurations to set a routing protocol between a PE and a CE:
l
Procedure
1.
Issue 01 (2011-10-15)
Run:
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
338
system-view
Run:
bgp as-number
Run:
ipv6-family vpn-instance vpn-instance-name
Run:
peer peer-ipv6-address as-number number
(Optional) Run:
peer { ipv6-address | group-name } ebgp-max-hop [ number ]
(Optional) Run:
peer { group-name | ipv4-address | ipv6-address } soo site-of-origin
(Optional) Run:
peer peer-ipv6-address allow-as-loop [ number ]
(Optional) Run:
peer peer-ipv6-address substitute-as
Issue 01 (2011-10-15)
339
Run:
commit
Run:
system-view
Run:
bgp as-number
(Optional) Run:
router-id ipv4-address
Run:
peer peer-ipv6-address as-number as-number
(Optional) Run:
peer { ipv6-address | group-name } ebgp-max-hop [ number ]
Run:
ipv6-family unicast
Run:
peer peer-ipv6-address enable
The function that exchanges BGP routing information with the BGP IPv6 peer is
enabled.
8.
(Optional) Choose either one of the following configurations if the direct routes or
specific network segment routes of the CE need to be imported into BGP and sent to
the peer PE.
Run:
import-route { direct | static | ripng process-id | ospfv3 process-id
| isis process-id } [ med value | route-policy policy-name ]*
340
The address of the VPN network segment is advertised from the CE to the
connected PE, and is then advertised by the PE to its peer PE. In real world
situations, the type of imported route may be different from that used in this
document.
Run:
network ipv6-address prefix-length
The IPv6 routes of a specified network segment are imported into BGP.
9.
Run:
commit
For details on the configuration of IPv6 static route, see "Static Route Configuration" in the HUAWEI
NetEngine5000E Core Router Configuration Guide - IP Routing.
1.
Run:
system-view
Run:
ipv6 route-static vpn-instance vpn-instance-name dest-ipv6-address masklength { interface-type interface-number [ nexthop-ipv6-address ] | vpninstance vpn-destination-name nexthop-ipv6-address | nexthop-ipv6-address
[ public ] } [ preference value ] [ tag tag ] [ description text ]
A static route is configured for the VPN instance IPv6 address family.
3.
Run:
bgp as-number
Run:
ipv6-family vpn-instance vpn-instance-name
Run:
import-route static [ med value ] [ route-policy policy-name ]
The configured static route is imported into the routing table of the BGP-VPN instance
IPv6 address family.
The configurations of an ordinary IPv6 static route are performed on the CE, and details
for the configuration procedure are not provided here.
l
Run:
commit
Issue 01 (2011-10-15)
341
1.
Run:
system-view
Run:
isis process-id vpn-instance vpn-instance-name
An IS-IS instance is created on the PE and CE, and the IS-IS view is displayed.
An IS-IS multi-instance process belongs to only one VPN instance IPv6 address
family. If an IS-IS process is not bound to a VPN instance when the process is enabled,
it is classified as a public network process.
If only one IS-IS process (which can be a public network process or a multi-instance
process) runs on the router, you do not need to specify process-id in the command.
The default process ID 1 will be used.
NOTE
Deleting an IS-IS multi-instance process will disable IS-IS on all the interfaces that run this
process.
Deleting a VPN instance or disabling the VPN instance IPv6 address family will delete all
associated IS-IS processes.
3.
Run:
network-entity net
(Optional) Run:
is-level { level-1 | level-1-2 | level-2 }
Run:
ipv6 enable
Run:
import-route bgp [ cost value ] [ cost-type { external | internal } ]
[ level-1 | level-1-2 | level-2 ] [ route-policy policy-name ] [ tag tagvalue ]
Run:
quit
Run:
interface interface-type interface-number
Run:
isis ipv6 enable [ process-id ]
Issue 01 (2011-10-15)
342
IS-IS routes are imported into the routing table of the BGP-VPN instance IPv6 address
family.
14. Run:
commit
Do as follows on the PE. Configure common RIPng on the CE. For details on RIPng configurations,
see "RIPng Configuration" in the HUAWEI NetEngine5000E Core Router Configuration Guide IP Routing.
1.
Run:
system-view
Run:
ripng [ process-id ] vpn-instance vpn-instance-name
A RIPng instance is created on the PE and CE, and the RIPng view is displayed.
A RIPng multi-instance process belongs to only one VPN instance. If a RIPng process
is not bound to a VPN instance when the process is enabled, it is classified as a public
network process.
If only one RIPng process (which can be a public network process or a multi-instance
process) runs on the router, you do not need to specify process-id in the command.
The default process ID 1 will be used.
3.
Run:
import-route bgp [ cost cost | route-policy route-policy-name ]*
Run:
quit
Issue 01 (2011-10-15)
343
Run:
interface interface-type interface-number
Run:
ripng process-id enable
The command cannot be used in the interface view if IPv6 is not enabled on the interface.
7.
Run:
quit
Run:
bgp as-number
Run:
ipv6-family vpn-instance vpn-instance-name
RIPng routes are imported into the routing table of the BGP-VPN instance IPv6
address family.
After the import-route ripng command is run in the BGP-VPN instance IPv6 address
family view, the PE imports the IPv6 routes learned from the local CE into BGP, forms
them into VPN IPv6 routes, and advertises the VPN IPv6 routes to the remote PE.
NOTE
Deleting a RIPng multi-instance process will disable RIPng on all the interfaces that run this
process.
Deleting a VPN instance or disabling the VPN instance IPv6 address family will delete all
associated RIPng processes.
11. Run:
commit
Run:
system-view
344
2.
Run:
ospfv3 [ process-id ] [ vpn-instance vpn-instance-name ]
Deleting a VPN instance or disabling the VPN instance IPv6 address family will delete all
associated OSPFv3 processes.
3.
Run:
router-id router-id
Run:
import-route bgp [ cost cost | route-policy route-policy-name | tag tag |
type type ] *
BGP routes are imported into OSPFv3 and then advertised from the PE to the CE.
5.
Run:
quit
Run:
interface interface-type interface-number
Run:
ospfv3 process-id area area-id [ instance instance-id ]
Run:
quit
Run:
bgp as-number
OSPFv3 routes are imported into the routing table of the BGP-VPN instance IPv6
address family.
Issue 01 (2011-10-15)
345
12. Run:
commit
Run:
system-view
Run:
bgp as-number
Run:
ipv6-family vpn-instance vpn-instance-name
Run:
peer peer-ipv6-address as-number number
(Optional) Choose either one of the following configurations if the direct routes of the
CE need to be imported into the VPN routing table and advertised to the remote PE.
Run:
import-route direct [ med med | route-policy route-policy-name ]*
The direct routes of the CE are imported into the VPN routing table.
Run:
network ipv6-address prefix-length
The IPv6 routes of the directly connected network segment are imported into the
IPv6 routing table of the BGP-VPN instance.
NOTE
A PE automatically learns the direct route to its attached CE, and this route takes precedence
over any direct route sent from the CE using IBGP. If this step is not performed, the PE does
not use MP-BGP to send the direct route automatically learned to the remote PE.
6.
Run:
commit
Run:
system-view
Run:
bgp as-number
Run:
peer ipv6-address as-number as-number
Issue 01 (2011-10-15)
346
(Optional) Choose either one of the following configurations if the direct routes or
specific network segment routes of the CE need to be imported into BGP and sent to
the peer PE.
Run:
import-route { direct | static | ripng process-id | ospfv3 process-id
| isis process-id } [ med value | route-policy policy-name ]
The IPv6 routes of a specified network segment are imported into BGP.
5.
Run:
commit
Prerequisite
The basic BGP/MPLS IPv6 VPN configurations are complete.
Procedure
l
Run the display ipv6 routing-table command on the CE to check routing information.
----End
Example
Run the display ipv6 routing-table vpn-instance [ vpn-instance-name ] command on the PE
to check the routing information of a specified VPN instance IPv6 address family. If a VPN
route from the PE to a relevant CE is displayed, it means that the configuration succeeds.
<HUAWEI> display ipv6 routing-table vpn-instance vpna
Routing Table : vpna
Destinations : 4
Routes : 4
Destination
NextHop
Cost
RelayNextHop
Interface
Issue 01 (2011-10-15)
:
:
:
:
:
1::
1::2
0
::
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
347
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
1::2
::1
0
::
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
5::5
1::1
0
1::1
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
255
BGP
0x0
RD
Destination : 6::6
NextHop
: ::FFFF:22.22.22.22
Cost
: 0
RelayNextHop : ::
0x0000000001004c4b42
Interface
: 0x0000000001004c4b42
PrefixLength
Preference
Protocol
TunnelID
: 128
: 255
: BGP
:
Flags
: RD
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
FE80::
::
0
::
NULL0
10
0
Direct
0x0
D
Run the display ipv6 routing-table command on the CE. If all routes from the CE to other CEs
are displayed, it means that the configuration succeeds.
<HUAWEI> display ipv6 routing-table 6::6 128
Routing Table : _public_
Summary Count : 1
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
6::6
1::2
0
1::2
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
255
BGP
0x0
RD
Applicable Environment
The BGP speaker does not advertise routes learned from an IBGP peer to other IBGP peers. To
advertise the routes of an accessed VPN to BGP VPNv6 peers in the same AS, a PE must establish
IBGP connections with all peers for direct exchange of IPv6 VPN routing information. This
means that MP IBGP peers must establish connections between each other. Assume that there
are n PEs (including ASBRs) in an AS. In this situation, n(n - 1)/2 MP-IBGP peer relationships
need to be established. A large number of IBGP peers consume a great amount of network
resources.
Using an RR can solve this problem. In an AS, one device serves as an RR to reflect VPNv6
routes; the other PEs and ASBR PEs serve as clients and are called client PEs. A P, PE, ASBR,
or other type of device can be configured as an RR.
Pre-configuration Tasks
Before configuring route reflection to optimize the VPN backbone layer, complete the following
tasks:
Issue 01 (2011-10-15)
348
Establishing LSPs or MPLS TE tunnels between the RR and all PEs serving as clients
Configuration Procedures
Figure 3-4 Flowchart for configuring route reflection for BGP VPNv6 routes
Procedure
Step 1 Run:
system-view
349
The IP address of the interface must be the same as the MPLS LSR ID of the system. Specifying
a loopback interface to establish the TCP connection is recommended.
Step 5 Run:
ipv6-family vpnv6
The function that exchanges VPNv6 routes with the RR is enabled on the PE.
Step 7 Run:
commit
Context
Choose one of the following schemes to configure the RR to establish MP-IBGP connections
with the client PEs:
Procedure
l
Run:
system-view
Run:
bgp as-number
Run:
group group-name [ internal ]
Run:
peer group-name connect-interface interface-type interface-number
The interface used to establish a TCP connection is specified. The IP address of the
interface must be the same as the MPLS LSR ID of the system. Specifying a loopback
interface to establish the TCP connection is recommended.
Issue 01 (2011-10-15)
350
5.
Run:
ipv6-family vpnv6
Run:
peer group-name enable
The function that exchanges BGP IPv6 VPN routes between the RR and the peer group
is enabled.
7.
Run:
peer ip-address group group-name
Run:
commit
Run:
system-view
Run:
bgp as-number
Run:
peer peer-ipv4-address as-number as-number
Run:
peer peer-ipv4-addressconnect-interface interface-type interface-number
Run:
ipv6-family vpnv6
Run:
peer peer-ipv4-address enable
The function that exchanges BGP IPv6 VPN routes between the RR and the client PE
is enabled.
7.
Run:
commit
351
Procedure
Step 1 Run:
system-view
l To enable route reflection if the RR has established an MP-IBGP connection with each client
PE rather than a peer group, run the following commands repeatedly:
peer peer-ipv4-address reflect-client
Step 5 Run:
undo policy vpn-target
Prerequisite
The configurations of route reflection for BGP VPNv6 routes are complete.
Issue 01 (2011-10-15)
352
Procedure
l
Run the display bgp vpnv6 all peer [ [ ipv4-address ] verbose ] command on the RR or
a client PE to check information about BGP VPNv6 peers.
Run the display bgp vpnv6 all routing-table peer peer-ipv4-address { advertisedroutes | received-routes } [ statistics ] command on the RR or a client PE to check VPNv6
routes received from the peer or advertised to the peer.
Run the display bgp vpnv6 all group [ group-name ] command on the RR to check
information about the VPNv6 peer group.
----End
Example
If the preceding configurations succeed,
You can find that the status of the MP-IBGP connections between the RR and all client PEs is
"Established" after running the display bgp vpnv6 all peer command on the RR or client PEs.
<HUAWEI> display bgp vpnv6 all peer
BGP local router ID : 2.2.2.9
Local AS number : 100
Total number of peers : 2
Peer
PrefRcv
1.1.1.9
3.3.3.9
AS
MsgRcvd
MsgSent
4
4
100
100
1263
1170
1530
1109
OutQ
Up/Down
State
0 19:46:01 Established
0 17:50:26 Established
1
1
You can find that the RR and each client PE can send and receive VPNv6 routing information
between each other after running the display bgp vpnv6 all routing-table peer command on
the RR or client PEs.
If a peer group is configured, you can view information about the group members and find that
the status of the BGP connections between the RR and group members is "Established" after
running the display bgp vpnv6 all group command on the RR.
Applicable Environment
By default, the system selects a tunnel in the order of LSPs, CR-LSPs, and Local_IfNet, and
does not perform load balancing. To configure load balancing or select tunnels of other types,
you need to configure a tunnel policy and apply it to the IPv6 VPN.
At present, the NE5000E supports the following modes of tunnel policies:
l
Issue 01 (2011-10-15)
353
Tunnel binding: A TE tunnel is bound to a specified destination IP address so that the VPN
traffic to that destination address can only be transmitted over the TE tunnel.
For details on tunnel policy configurations, see VPN Tunnel Management Configuration.
Pre-configuration Tasks
Before configuring a tunnel policy for the backbone network of a BGP/MPLS IPv6 VPN,
complete the following tasks:
l
Configuration Procedures
Figure 3-5 Flowchart for configuring a tunnel policy for the backbone network of a BGP/MPLS
IPv6 VPN
Configure a tunnel policy
Apply a tunnel policy to the IPv6 VPN
Mandatory
procedure
Optional
procedure
Context
In the tunnel policy view, the select-sequence mode and tunnel binding mode are mutually
exclusive. Choose one of the following configurations as required:
Procedure
l
Run:
system-view
Run:
tunnel-policy policy-name
Run:
tunnel select-seq { lsp | cr-lsp }* load-balance-number load-balance-number
The priority sequence of tunnel types and number of tunnels participating in load
balancing are configured.
Issue 01 (2011-10-15)
354
Run:
commit
Run:
system-view
Run:
tunnel-policy policy-name
Run:
tunnel binding destination dest-ip-address te { tunnel interface-number }
&<1-6> [ down-switch ]
Run:
commit
Procedure
Step 1 Run:
system-view
355
tnl-policy policy-name
The tunnel policy is applied to the VPN instance IPv6 address family.
Step 5 Run:
commit
Prerequisite
The configurations of a tunnel policy for the backbone network of a BGP/MPLS IPv6 VPN are
complete.
Procedure
l
----End
Example
Run the display tunnel-policy command. If the configuration of a tunnel policy is displayed, it
means that the configuration succeeds. For example:
<HUAWEI> display tunnel-policy policy1
Tunnel Policy Name
Select-Seq
Load balance No
-----------------------------------------------------policy1
LSP
1
Run the display ip vpn-instance verbose command, and you can view the tunnel policy used
by a VPN instance. In the following command output, the tunnel policy used by the IPv6 address
family of a VPN instance named vpna is policy1.
<HUAWEI> display ip vpn-instance verbose
Total VPN-Instances configured : 1
VPN-Instance Name and ID : vpn1, 1
Interfaces : GigabitEthernet1/0/0
Address family ipv6
Create date : 2006/09/27 15:25:29
Up time : 0 days, 00 hours, 02 minutes and 11 seconds
Route Distinguisher : 100:1
Export VPN Targets : 2:2
Import VPN Targets : 1:1
Label policy : label per route
Tunnel Policy : policy1
Issue 01 (2011-10-15)
356
Applicable Environment
If the MPLS backbone network bearing IPv6 VPN routes spans across multiple ASs, the interAS VPN solution is required.
If the number of VPNs that access PEs and the number of IPv6 VPN routes are small, inter-AS
VPN Option A is recommended. In inter-AS VPN Option A, ASBRs are required to support
VPN instances so that they will be capable of managing IPv6 VPN routes. In addition, ASBRs
must provide dedicated interfaces for inter-AS VPNs, which can be sub-interfaces or physical
interfaces. Therefore, the requirement for ASBRs' performance is rather high, but no inter-AS
configurations need to be performed on ASBRs.
Pre-configuration Tasks
Before configuring inter-AS VPN Option A, complete the following tasks:
l
Configuring an IGP for the MPLS backbone network of each AS for IP connectivity of the
backbone network within each AS
Establishing an LSP or MPLS TE tunnel between the PE and the ASBR within each AS
Procedure
Step 1 Configure basic BGP/MPLS IPv6 VPN for each AS. For details, see Configuring Basic BGP/
MPLS IPv6 VPN.
Step 2 Configure ASBRs in different ASs to consider each other as a CE.
Step 3 Enable the IPv6 address family-enabled VPN instance on the PEs and ASBRs. For details on
the configuration procedures, see Configuring the IPv6 Address Family-supporting VPN
Instance.
After the configuration, the PEs can access their attached CEs, and ASBRs in different ASs can
access each other.
NOTE
In inter-AS VPN Option A, on the same IPv6 VPN, the VPN targets of the IPv6 address family-enabled
VPN instances of the ASBR and PE that are in the same AS must be matched. This is not required for the
PEs in different ASs.
----End
Example
Run the following commands to check the previous configuration.
Run the display bgp vpnv6 all peer command on the PE or ASBR to check information about
BGP peer relationships.
Issue 01 (2011-10-15)
357
Run the display bgp vpnv6 all routing-table command on the PE or ASBR to check VPNv6
routing information.
Run the display ipv6 routing-table vpn-instance [ vpn-instance-name ] command on the PE
or ASBR to check the routing table of the VPN instance IPv6 address family.
Applicable Environment
If an ASBR can manage VPN routes but there are not enough interfaces for all inter-AS VPNs,
inter-AS VPN Option B can be used. Inter-AS VPN Option B requires ASBRs to help to maintain
and advertise VPNv6 routes and you need not create VPN instances on the ASBRs.
On the network shown in Figure 3-6, the interfaces connected between ASBRs do not need to
be bound to the VPN. A single-hop MP-EBGP peer relationship is set up between the ASBRs
to transmit all inter-AS VPN routing information.
Figure 3-6 Schematic diagram for Inter-AS IPv6 VPN Option B
VPN1
CE1
VPN1
CE3
IP/MPLS Backbone
AS: 100
PE1
ASBR1
IP/MPLS Backbone
AS: 200
PE3
ASBR2
MP-IBGP
MP-EBGP
PE2
MP-IBGP
PE4
CE4
VPN2
CE2
VPN2
Pre-configuration Tasks
Before configuring inter-AS VPN Option B, complete the following tasks:
l
Configuring an IGP for the MPLS backbone network of each AS to ensure IP connectivity
of the backbone network within an AS
Configuring the basic MPLS functions for the MPLS backbone network of each AS and
establishing an LDP LSP or TE tunnel between MP-IBGP peers
Issue 01 (2011-10-15)
358
Configuration Procedures
Figure 3-7 Flowchart for configuring inter-AS IPv6 VPN Option B
Configuring MP-IBGP Between
a PE and an ASBR in the Same AS
Configuring MP-EBGP
Between ASBRs in Different ASs
Procedure
Step 1 Run:
system-view
The IBGP peer relationship is set up between the PE and ASBR in the same AS.
Step 4 Run:
peer peer-address connect-interface loopback interface-number
The loopback interface is specified as the outbound interface of the BGP session.
Step 5 Run:
ipv6-family vpnv6 [ unicast ]
Issue 01 (2011-10-15)
359
The capability of VPNv6 route exchange between the PE and the ASBR is enabled.
Step 7 Run:
commit
Context
In inter-AS IPv6 VPN Option B, you need not create VPN instances on ASBRs. The ASBR does
not filter the VPNv6 routes received from the PE in the same AS based on VPN targets. Instead,
it advertises the received routes to the peer ASBR through MP-EBGP.
Procedure
Step 1 Run:
system-view
The view of the interface that connects to the peer ASBR is displayed.
Step 3 Run:
ip address ip-address { mask | mask-length }
Issue 01 (2011-10-15)
360
The capability of exchanging VPNv6 routes with the peer ASBR is enabled.
Step 11 Run:
commit
Context
By default, an ASBR filters the VPN targets of only the received VPNv6 routes. The routes are
imported into the routing table if they pass the filtration; otherwise, they are discarded. Therefore,
if no VPN instance is configured on the ASBR or no VPN target is configured for the VPN
instance, the ASBR discards all the received VPNv6 routes.
You can configure an ASBR to control the importing and exporting of VPN routes through
multiple methods. The two methods are described as follows:
l
Not to filter VPN targets, that is, the ASBR stores all the VPNv6 routes
To filter VPN targets, that is, the ASBR stores partial VPNv6 routes through routing policies
Configure either of the following methods on each ASBR based on the actual situation:
Procedure
l
Run:
system-view
Run:
bgp as-number
361
3.
Run:
ipv6-family vpnv6 [ unicast ]
Run:
undo policy vpn-target
Run:
commit
Run:
system-view
Run:
ip extcommunity-filter extcom-filter-number { deny | permit } rt vpntarget &<1-16>
Run:
route-policy route-policy-name permit node node
Run:
if-match extcommunity-filter extcomm-filter-number &<1-16>
Run:
commit
Run:
quit
Run:
bgp as-number
Run:
ipv6-family vpnv6 [ unicast ]
Run:
peer peer-address route-policy policy-name { export | import }
Issue 01 (2011-10-15)
362
The routing policy is applied to controlling the importing and exporting of VPNv6
routes.
10. Run:
commit
Procedure
Step 1 You can configure a routing protocol between a CE and a PE based on the actual situation. For
detailed configuration procedures, see 3.4.4 Configuring Route Exchange Between a PE and
a CE.
----End
Prerequisite
All the configurations about inter-AS VPN Option B are complete.
Procedure
l
Run the display bgp vpnv6 all peer command on the PE or ASBR to check the status of
all BGP peer relationships.
Run the display bgp vpnv6 all routing-table command on the PE or ASBR to check
information about VPNv6 routes.
----End
Example
Run the display bgp vpnv6 all peer command on the PE or ASBR, and you can view that the
status of the BGP VPNv6 peer relationship between the PE and ASBR in the same AS is
"Established". In addition, the status of the EBGP peer relationship between the directly
connected ASBRs in different ASs is also "Established".
<HUAWEI> display bgp vpnv6 all peer
BGP local router ID : 192.1.1.1
Local AS number : 100
Total number of peers : 2
Peer
PrefRcv
Issue 01 (2011-10-15)
AS
MsgRcvd
OutQ
Up/Down
State
363
1.1.1.9
100
39
30
0 00:22:42 Established
192.1.1.2
200
31
24
0 00:18:15 Established
1
1
Run the display bgp vpnv6 all routing-table command on the ASBR, and you can view the
VPNv6 routes on the ASBR.
<HUAWEI> display bgp vpnv6 all routing-table
BGP Local router ID is 192.1.1.1
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 2
Route Distinguisher: 100:1
*>i Network : 2001::
NextHop : ::FFFF:1.1.1.9
MED
: 0
Label
: 17/18
Path/Ogn : ?
Route Distinguisher: 200:2
PrefixLen : 64
LocPrf
: 100
PrefVal
: 0
*>
PrefixLen : 64
LocPrf
:
PrefVal
: 0
Network
NextHop
MED
Label
Path/Ogn
:
:
:
:
:
2002::
::FFFF:192.1.1.2
17/17
200?
Run the display ipv6 routing-table vpn-instance vpn-instance-name command on the PE, and
you can view that the VPN routing table contains related VPN routes.
<HUAWEI> display ipv6 routing-table vpn-instance vpna
Routing Table : vpna
Destinations : 4
Routes : 4
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::
2001::2
0
::
Pos3/1/1
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::2
::1
0
::
Pos3/1/1
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
01004c4b42
Interface
:
:
:
:
2002::
::FFFF:2.2.2.9
0
::
PrefixLength
Preference
Protocol
TunnelID
:
:
:
:
64
255
BGP
0x00000000
: LDP LSP
Flags
: RD
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
Issue 01 (2011-10-15)
FE80::
::
0
::
NULL0
10
0
Direct
0x0
D
364
Applicable Environment
Deploying load balancing among IPv6 VPN routes allows even distribution of VPN traffic to
different links on the backbone network, which improves the link usage.
A PE may receive multiple IPv6 VPN routes with the same prefix from different VPNv6 peers.
Usually, the PE selects an optimal route and delivers it to the Forwarding Information Base (FIB)
to guide data forwarding. If load balancing is configured on the PE, it delivers multiple routes
to the FIB. VPN data then can be distributed to different links on the backbone network in a
packet-by-packet or session-by-session manner.
Pre-configuration Tasks
Before configuring load balancing among IPv6 VPN routes, complete the following tasks:
l
Ensuring that the PE receives IPv6 VPN routes with the same prefix from different VPNv6
peers
Procedure
Step 1 Run:
system-view
Load balancing among BGP routes is configured for the BGP VPN instance IPv6 address family.
Step 5 Run:
commit
365
Example
Run the following commands to check the preceding configurations:
Run the display ipv6 routing-table vpn-instance command on the PE to check detailed
information about IPv6 VPN routes with a specified prefix.
Run the display ipv6 routing-table vpn-instancevpn-instance-name ipv6-address [ prefixlength ] [ longer-match ] [ verbose ] command on the PE. If the IPv6 VPN route with the
specified prefix has more than one next hop, it means that the configuration of load balancing
among IPv6 VPN routes on the backbone network succeeds.
<HUAWEI> display ipv6 routing-table vpn-instance vpna 200:0:1:2::1
Routing Table : vpna
Summary Count : 2
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
200:0:1:2::1
::FFFF:2.2.2.2
0
::FFFF:100.1.1.2
Pos2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
255
BGP
0x800003
RD
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
200:0:1:2::1
::FFFF:3.3.3.3
0
::FFFF:100.2.1.2
Pos3/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
255
BGP
0x800001
RD
Applicable Environment
VPNv6 FRR is applicable to IPv6 services that are sensitive to the packet loss and delay. The
system has higher requirements on the VPN that transmits IPv6 services. If VPNv6 FRR is
enabled, IPv6 VPN services can be quickly switched to another link when a fault occurs on the
VPN. In this manner, IPv6 VPN services are not interrupted.
At present, the NE5000E supports VPNv6 Auto FRR. This function automatically selects the
next hop (a PE) for VPN routes, and there are no fixed backup next hops.
Pre-configuration Tasks
Before configuring VPNv6 FRR, complete the following tasks:
l
Ensuring that the PE receives IPv6 VPN routes with the same prefix from different VPNv6
peers
Procedure
Step 1 Run:
system-view
366
bgp as-number
Result
Run the display ipv6 routing-table vpn-instance vpn-instance-name [ ipv6-address ]
verbose command to check the backup next hop, backup tunnel, and backup label in the routing
table.
Example
Run the display ipv6 routing-table vpn-instance verbose command on the PE where VPNv6
FRR is enabled, and you can view the backup next hop (a PE), backup tunnel, and backup label
of routes. For example, set the primary next hop and backup next hop for the route to 200:0:1:2::1
to 2.2.2.2 and 3.3.3.3 respectively on the PE. The information about the backup next hop, backup
tunnel, and backup label is as follows:
<HUAWEI> display ipv6 routing-table vpn-instance vpna 200:0:1:2::1 128 verbose
Routing Table :vpna
Summary Count : 1
Destination : 200:0:1:2::1
NextHop
: ::FFFF:2.2.2.2
Neighbour
: ::2.2.2.2
Label
: 1030
State
: Active Adv Relied
Entry ID
: 12
Reference Cnt: 2
IndirectID
: 0x4
RelayNextHop : ::FFFF:100.1.1.2
0x0000000001004c4ba2
Interface
: LDP LSP
BkNextHop
: ::FFFF:3.3.3.3
BkLabel
: 1026
BkPETunnelID : 0x800001
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
:
:
:
:
:
:
:
:
:
128
255
0
BGP
0
0x80024904
0
31sec
Flags
: RD
BkInterface :
BkTunnelID
: 0x0
BkIndirectID : 0x6
367
Applicable Environment
This feature is suitable for IP services that are sensitive to the packet loss and delay on a VPN.
With IPv6 FRR configured on the private network, if the route from a PE to a CE is unreachable,
traffic from the PE can be quickly switched to a link connected to another CE. This ensures nonstop forwarding of IP services.
At present, the NE5000E supports two modes of IPv6 FRR for the private network, which differ
in terms of networking and configuration procedures.
l
IPv6 FRR: It is applicable to the networking where different PE-CE pairs use different
routing protocols.
BGP Auto FRR: It is applicable to the networking where BGP runs between the PE and
CEs.
Pre-configuration Tasks
Before configuring FRR for IPv6 routes in a private network, complete the following tasks:
l
Ensuring that the PE learns IPv6 VPN routes with the same prefix from different CEs
attached to it
Procedure
1.
Run:
system-view
Run:
ip vpn-instance vpn-instance-name
Run:
ipv6-family
Run:
ipv6 frr
Run:
commit
Run:
system-view
Run:
bgp as-number
Issue 01 (2011-10-15)
368
Run:
ipv6-family vpn-instance vpn-instance-name
Run:
auto-frr
Run:
commit
Example
Run the display ipv6 routing-table vpn-instance vpn-instance-name [ ipv6-address ]
verbose command to check the backup outbound interface and backup next hop of the IPv6
route in the routing table.
Run the display ipv6 routing-table vpn-instance vpn-instance-name verbose command on the
PE, and you can view that the IPv6 route has a backup outbound interface and a backup next
hop.
<HUAWEI> display ipv6 routing-table vpn-instance vpna 2004::1 verbose
Routing Table : vpna
Summary Count : 1
Destination : 2004::1
NextHop
: 2000::2
Neighbour
: 2000::2
Label
: NULL
State
: Active Adv
Entry ID
: 27
Reference Cnt: 2
IndirectID
: 0x6
RelayNextHop : ::
Interface
: GigabitEthernet1/0/0
BkNextHop
: 2001::2
GigabitEthernet2/0/0
BkLabel
: NULL
BkPETunnelID : 0x0
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
Flags
BkInterface
:
:
:
:
:
:
:
:
:
:
:
128
255
0
BGP
100
0x80004100
0
3sec
0x0
D
BkTunnelID
: 0x0
BkIndirectID : 0x5
Applicable Environment
Hybrid FRR for IPv6 and VPNv6 routes can quickly switch traffic from a PE to another PE that
serves as the backup next hop if the primary route to a CE is unreachable.
A PE learns IPv6 VPN routes with the same prefix from a CE and other PEs. In this situation,
hybrid FRR for IPv6 and VPNv6 routes can be configured on the PE. Enabled with hybrid FRR,
Issue 01 (2011-10-15)
369
the PE generates a primary route and a backup route to the VPN prefix. If the link between the
PE and CE fails, the link traffic can be quickly switched to the backup next hop (a PE).
At present, the NE5000E supports two modes of hybrid FRR for IPv6 and VPNv6 routes, which
differ in terms of networking and configuration procedures.
l
IPv6 FRR: It is applicable to the networking where a non-BGP routing protocol runs
between the PEs and CE.
BGP Auto FRR for the private network: It is applicable to the networking where BGP runs
between the PEs and CE.
Pre-configuration Tasks
Before configuring hybrid FRR for IPv6 and VPNv6 routes, complete the following tasks:
l
Ensuring that a PE learns IPv6 routes with the same prefix from a CE and other VPNv6
peers
Procedure
1.
Run:
system-view
Run:
ip vpn-instance vpn-instance-name
Run:
ipv6-family
Run:
ipv6 frr
Run:
commit
Run:
system-view
Run:
bgp as-number
Run:
ipv6-family vpn-instance vpn-instance-name
Issue 01 (2011-10-15)
370
Run:
auto-frr
Run:
commit
Example
Run the display ipv6 routing-table vpn-instance vpn-instance-name [ ipv6-address ]
verbose command to check the backup outbound interface and backup next hop of the IPv6
route in the routing table.
Run the display ipv6 routing-table vpn-instance vpn-instance-name verbose command on the
PE, and you can view that the IPv6 route has a backup outbound interface and a backup next
hop.
<HUAWEI> display ipv6 routing-table vpn-instance vpn1 200:0:1:2::1 verbose
Routing Table : vpn1
Summary Count : 1
Destination : 200:0:1:2::1
NextHop
: 2001::1
Neighbour
: 2001::1
Label
: NULL
State
: Active Adv Relied
Entry ID
: 14
Reference Cnt: 0
IndirectID
: 0x8a9
RelayNextHop : 2001::1
Interface
: GigabitEthernet2/0/0
BkNextHop
: ::FFFF:3.3.3.3
0x0000000001004c4b42
BkLabel
: 17
BkPETunnelID : 0x1002
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
Flags
BkInterface
:
:
:
:
:
:
:
:
:
:
:
128
60
0
Static
0
0x00000000
0
3sec
0x0
RD
BkTunnelID
: 0x0000000001004c4
BkIndirectID : 0x1000396
Context
In routine maintenance, the following commands can be run in any view to display BGP/MPLS
IPv6 VPN information.
Issue 01 (2011-10-15)
371
Procedure
l
Run the display mpls lsp command to check information about LSPs.
Run the display bgp vpnv6 { all | route-distinguisher route-distinguisher | vpninstance vpn-instance-name } routing-table destination-address [ mask-length ]
command to check entries in the routing table of the BGP-VPN instance IPv6 address
family.
Run the display bgp vpnv6 { all | route-distinguisher route-distinguisher | vpninstance vpn-instance-name } routing-table statistics [ match-options ] command to
check statistics about the routing table of the BGP-VPN instance IPv6 address family.
Run the display bgp vpnv6 { all | route-distinguisher route-distinguisher | vpninstance vpn-instance-name } routing-table [ match-options ] command to check
information about the routing table of the BGP-VPN instance IPv6 address family.
Run the display bgp vpnv6 { all | vpn-instance vpn-instance-name } group [ groupname ] command to check VPNv6 BGP peer group information.
Run the display bgp vpnv6 { all | vpn-instance vpn-instance-name } peer [ [ peeraddress ] verbose ] command to check VPNv6 BGP peer information.
Run the display bgp vpnv6 { all | vpn-instance vpn-instance-name } network command
to check VPNv6 route information advertised by BGP.
Run the display bgp vpnv6 { all | vpn-instance vpn-instance-name } paths [ as-regularexpression ] command to check the AS_Path of the routes in the BGP-VPN instance IPv6
address family.
Run the display bgp vpnv6 vpn-instance vpn-instance-name peer { group-name | ipv6address } log-info command to check log information about the BGP peers in the BGPVPN instance IPv6 address family.
----End
Procedure
l
Run the ping ipv6 [ -a source-ipv6-address | -c echo-number | -m wait-time | -s bytenumber | -t time-out | -tc traffic-class | vpn-instance vpn-instance-name ]* dest-ipv6address [ -i interface-type interface-number ] command to check whether an IPv6 network
is correctly set up to send packets from the transmitting end to the destination address.
Run the tracert ipv6 [ -f first-hop-limit | -m max-hop-limit | -p port-number | -q probes | w wait-time | vpn-instance vpn-instance-name ]* { ipv6-address | host-name } command
to check the gateways through which the IPv6 packets are sent from the transmitting end
to the destination address.
Run the ping [ ip ] [ -a source-ip-address | -c count | -d | -f | -h ttl-value | -i interfacetype interface-number | -m time | -n | -p pattern | -q | -r | -s packetsize |-t timeout | -tos tos-
Issue 01 (2011-10-15)
372
Run thetracert [ -a source-ip-address | -f first-TTL | -m max-TTL | -p port | -q nqueries | vpn-instance vpn-instance-name | -w timeout ]* dest-address command to check the
gateways through which the IPv4 packets are sent from the transmitting end on the IPv4
backbone network to the destination address on the IPv4 backbone network.
----End
Example
After IPv6 VPN configurations are complete, run the ping command with ipv6 vpn-instance
vpn-instance-name on the PE to check whether the PE can communicate with the CE in the same
IPv6 VPN. If the ping fails, run the tracert command with vpn-instance vpn-instance-name to
locate the fault.
If multiple interfaces on a PE are bound to the same VPN instance enabled with an IPv6 address
family, specify the source IP address when you ping the remote CE that accesses the peer PE.
This means that the parameter -a source-ipv6-address needs to be specified in the ping
command. If you do not specify a source IP address, the PE selects the address of its interface
bound to the VPN instance as the source address of the ICMPv6 packet. If the CE does not have
a route to the selected IPv6 address, the ICMPv6 packet sent back from the peer PE will be
discarded.
NOTE
By default, as for the MPLS TTL timeout packet with a single MPLS label, the router returns the ICMPv6
packet based on the local IP route, which is a public network route. No VPN route, however, exists in the
public-network routing table of the ASBR. As a result, the ICMPv6 packet is discarded when it is sent from
the ASBR or returned to the ASBR.
Procedure
l
----End
Issue 01 (2011-10-15)
373
Context
CAUTION
BGP statistics for the VPN instance IPv6 address family cannot be restored after being cleared.
Exercise caution when clearing the statistics.
Procedure
l
Run the reset bgp vpn-instance vpn-instance-name ipv6-family [ ipv6-address ] flapinfo command in the user view to clear statistics about BGP peer flapping for a specified
VPN instance IPv6 address family.
Run the reset bgp vpn-instance vpn-instance-name ipv6-family dampening [ ipv6address mask-length ] command in the user view to clear dampening information of a
specified VPN instance IPv6 address family.
----End
Context
CAUTION
Resetting BGP connections will interrupt VPN services. Exercise caution when performing the
resetting action.
When the BGP configuration changes, you can use soft reset or reset BGP connections to validate
the new BGP configuration. Soft reset requires BGP peers to be able to refresh routes. This
means that BGP peers should support Route-Refresh messages.
Procedure
l
Run the refresh bgp vpnv6 { all | ipv4-address | group group-name | internal |
external } { import | export } command to trigger the soft reset of BGP VPNv6
connections in the inbound or outbound direction.
Run the reset bgp vpn-instance vpn-instance-name ipv6-family { all | as-number | ipv6address | group group-name | external } command to reset the BGP connections of a
specified VPN instance IPv6 address family.
Issue 01 (2011-10-15)
374
Run the reset bgp vpnv6 { as-number | ipv4-address | group group-name | all | internal |
external } command to reset BGP VPNv6 connections.
----End
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number. If the slot number is specified, the chassis ID of the
slot must also be specified.
If users at different sites desire IPv6 data communications between each other across the public
network without having the internal route information known to the public network, BGP/MPLS
IPv6 VPN can be deployed. BGP/MPLS IPv6 VPN also isolates VPNs from each other: It allows
intra-VPN access and prohibits inter-VPN access.
As shown in Figure 3-8, CE1 and CE3 belong to vpna; CE2 and CE4 belong to vpnb. It is
required that BGP/MPLS IPv6 VPN be configured to allow site access within each VPN across
the MPLS backbone network and prohibit site access between vpna and vpnb. In addition, PEs
and CEs are required to use different routing protocols for route exchange. The requirements
are as follows:
l
BGP4+ between PE1 and CE1, and between PE2 and CE4
Issue 01 (2011-10-15)
375
Figure 3-8 Networking diagram for configuring basic BGP/MPLS IPv6 VPN
AS: 65420
AS: 65410
vpna
CE1
vpnb
Loopback1
1999 ::1/64
Loopback1
1998::1/64
CE4
GE1/0/0
2005::1
GE1/0/0
2001::1
GE1/0/0
2001::2
Loopback1
1.1.1.9/32
GE2/0/0
2003::2
Loopback1
2.2.2.9/32
PE1
POS1/0/0
192.168.1.2/24
POS3/0/0
192.168.1.1/24
PE2
POS2/0/0
192.168.2.1/24
POS3/0/0
192.168.2.2/24
MPLSbackbone
GE1/0/0
2005::2
Loopback1
3.3.3.9/32
GE2/0/0
2004::2
AS: 100
GE1/0/0
2004::1
GE1/0/0
2003::1
CE2
Loopback1
1998::1/64
vpnb
Loopback1
1999 ::1/64
AS: 65410
CE3
vpna
AS:65420
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP on the IPv4 backbone network for IP connectivity between the PEs on
the backbone network.
2.
Configure MPLS and MPLS LDP on each PE and the P, and establish an LDP LSP between
the PEs.
3.
Configure MP-IBGP between PE1 and PE2 to exchange IPv6 VPN routing information.
4.
Configure VPN instances that support the IPv6 address family on PE1 and PE2, and bind
the interfaces connecting the PEs to CEs to the VPN instances.
5.
Configure IPv6 routing protocols between PEs and CEs to exchange IPv6 routing
information.
Data Preparation
To complete the configuration, you need the following data:
l
Attributes of the VPN instance IPv6 address family, such as the RD and VPN target
Issue 01 (2011-10-15)
376
Procedure
Step 1 Configure IPv4 or IPv6 addresses for interfaces on each device.
# Configure an IPv6 address for the interface on CE1.
<CE1> system-view
[~CE1] interface gigabitethernet 1/0/0
[~CE1-GigabitEthernet1/0/0] ipv6 enable
[~CE1-GigabitEthernet1/0/0] ipv6 address 2001::1 64
[~CE1-GigabitEthernet1/0/0] quit
[~CE1-GigabitEthernet1/0/0] commit
The configurations of CE2, CE3, CE4, PE1, PE2, and the P are similar to the configuration of
CE1. For details on the configuration procedure, see the following configuration files.
Step 2 Configure an IGP on the IPv4 backbone network for IP connectivity between the PEs. In this
example, IS-IS is configured as an IGP.
# Configure PE1.
[~PE1] isis 1
[~PE1-isis-1] network-entity 10.1111.1111.1111.00
[~PE1-isis-1] quit
[~PE1] interface pos 3/0/0
[~PE1-Pos3/0/0] isis enable 1
[~PE1-Pos3/0/0] quit
[~PE1] interface loopback 1
[~PE1-LoopBack1] isis enable 1
[~PE1-LoopBack1] quit
[~PE1] commit
The configurations of the P and PE2 are similar to the configuration of PE1. For details on the
configuration procedure for the P and PE2, see the following configuration files.
After the configuration is complete, PE1, the P, and PE2 can learn the routes, including routes
to the loopback interfaces, from one another. You can run the display ip routing-table command
to view the routes. The following uses the display on PE1 as an example:
[~PE1] display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 9
Routes : 9
Destination/Mask
1.1.1.9/32
2.2.2.9/32
3.3.3.9/32
127.0.0.0/8
127.0.0.1/32
192.168.1.0/24
192.168.1.1/32
192.168.1.2/32
192.168.2.0/24
Proto
Pre
Cost
Direct
ISIS-L2
ISIS-L2
Direct
Direct
Direct
Direct
Direct
ISIS-L2
0
15
15
0
0
0
0
0
15
0
10
20
0
0
0
0
0
20
Flags NextHop
D
D
D
D
D
D
D
D
D
127.0.0.1
192.168.1.2
192.168.1.2
127.0.0.1
127.0.0.1
192.168.1.1
127.0.0.1
192.168.1.2
192.168.1.2
Interface
InLoopBack0
Pos3/0/0
Pos3/0/0
InLoopBack0
InLoopBack0
Pos3/0/0
InLoopBack0
Pos3/0/0
Pos3/0/0
Step 3 Enable MPLS and MPLS LDP on the devices in the IPv4 backbone network and interfaces on
the devices, and set up an LDP LSP between PE1 and PE2.
# Enable MPLS and MPLS LDP on PE1.
[~PE1] mpls lsr-id 1.1.1.9
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
Issue 01 (2011-10-15)
377
The configurations of the P and PE2 are similar to the configuration of PE1. For details on the
configuration procedure for the P and PE2, see the following configuration files.
After the configuration is complete, PE1 and PE2 can set up LDP LSPs. You can run the display
mpls ldp lsp command to check whether LDP LSPs are set up. The following uses the display
on PE1 as an example:
[~PE1] display mpls ldp lsp
LDP LSP Information
------------------------------------------------------------------------------DestAddress/Mask
In/OutLabel
UpstreamPeer
NextHop
OutInterface
------------------------------------------------------------------------------1.1.1.9/32
3/NULL
2.2.2.9
127.0.0.1
InLoop0
*1.1.1.9/32
Liberal/1024
DS/2.2.2.9
2.2.2.9/32
NULL/3
192.168.1.2
Pos3/0/0
2.2.2.9/32
1024/3
2.2.2.9
192.168.1.2
Pos3/0/0
3.3.3.9/32
NULL/1025
192.168.1.2
Pos3/0/0
3.3.3.9/32
1025/1025
2.2.2.9
192.168.1.2
Pos3/0/0
------------------------------------------------------------------------------TOTAL: 5 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
TOTAL: 0 Frr LSP(s) Found.
A '*' before an LSP means the LSP is not established
A '*' before a Label means the USCB or DSCB is stale
A '*' before a UpstreamPeer means the session is in GR state
A '*' before a DS means the session is in GR state
A '*' before a NextHop means the LSP is FRR LSP
Step 4 On PEs, create VPN instances that support the IPv6 address family and bind the interfaces
connecting the PEs to CEs to the VPN instances.
# Create an IPv6 address family-supporting VPN instance named vpna on PE1.
[~PE1] ip vpn-instance vpna
[~PE1-vpn-instance-vpna] ipv6-family
[~PE1-vpn-instance-vpna-af-ipv6] route-distinguisher 100:1
[~PE1-vpn-instance-vpna-af-ipv6] vpn-target 22:22 export-extcommunity
[~PE1-vpn-instance-vpna-af-ipv6] vpn-target 33:33 import-extcommunity
[~PE1-vpn-instance-vpna-af-ipv6] quit
[~PE1-vpn-instance-vpna] quit
[~PE1] commit
378
The configuration of PE2 is similar to the configuration of PE1. For details on the configuration
procedure for PE2, see the following configuration files.
After the configuration is complete, you can run the display ip vpn-instance verbose command
on each PE to check the configuration of its VPN instance. You can also find that each PE can
successfully ping its connected CE. The following uses the display on PE1 as an example:
[~PE1] display ip vpn-instance verbose
Total VPN-Instances configured : 2
VPN-Instance Name and ID : vpna, 1
Interfaces : GigabitEthernet1/0/0
Address family ipv6
Create date : 2010/07/20 12:31:47 UTC-08:00
Up time : 0 days, 04 hours, 37 minutes and 05 seconds
Route Distinguisher : 100:1
Export VPN Targets : 22:22
Import VPN Targets : 33:33
Label Policy : label per route
Log Interval : 5
VPN-Instance Name and ID : vpnb, 2
Interfaces : GigabitEthernet2/0/0
Address family ipv6
Create date : 2010/07/20 14:41:46 UTC-08:00
Up time : 0 days, 02 hours, 27 minutes and 06 seconds
Route Distinguisher : 100:3
Export VPN Targets : 44:44
Import VPN Targets : 55:55
Label Policy : label per route
Log Interval : 5
[~PE1] ping ipv6 vpn-instance vpna 2001::1
PING 2001::1 : 56 data bytes, press CTRL_C to break
Reply from 2001::1
bytes=56 Sequence=1 hop limit=64 time = 20 ms
Reply from 2001::1
bytes=56 Sequence=2 hop limit=64 time = 30 ms
Reply from 2001::1
bytes=56 Sequence=3 hop limit=64 time = 30 ms
Reply from 2001::1
bytes=56 Sequence=4 hop limit=64 time = 1 ms
Reply from 2001::1
bytes=56 Sequence=5 hop limit=64 time = 1 ms
--- 2001::1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/16/30 ms
Issue 01 (2011-10-15)
379
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 1.1.1.9 as-number 100
[~PE2-bgp] peer 1.1.1.9 connect-interface loopback 1
[~PE2-bgp] ipv6-family vpnv6
[~PE2-bgp-af-vpnv6] peer 1.1.1.9 enable
[~PE2-bgp-af-vpnv6] quit
[~PE2] commit
After the configuration is complete, you can run the display bgp vpnv6 all peer command on
the PEs to check whether the VPNv6 peer relationship is set up. The following uses the display
on PE1 as an example:
[~PE1] display bgp vpnv6 all peer
BGP local router ID : 3.3.3.9
Local AS number : 100
Total number of peers : 1
Peer
PrefRcv
1.1.1.9
V
4
AS
100
MsgSent
OutQ
Up/Down
0 00:01:50
State
Established
The command output shows that the status of the VPNv6 peer relationship is Established. This
means that the VPNv6 peer relationship between PE1 and PE2 is successfully set up.
Step 6 Configure BGP4+ on PE1 and CE1.
# Configure EBGP on PE1.
[~PE1] bgp 100
[~PE1-bgp] ipv6-family vpn-instance vpna
[~PE1-bgp6-vpna] peer 2001::1 as-number 65410
[~PE1-bgp6-vpna] quit
[~PE1-bgp] quit
[~PE1] commit
The configurations of PE2 and CE4 are similar to the configurations of PE1 and CE1. For details
on the configuration procedure for PE2 and CE4, see the following configuration files.
After the configuration is complete, you can run the display bgp vpnv6 vpn-instance vpninstance-name peer command on the PEs to check whether the EBGP peer relationship is set
up.
The following uses the display on PE1 as an example:
[~PE1] display bgp vpnv6 vpn-instance vpna peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Issue 01 (2011-10-15)
380
AS
MsgRcvd
MsgSent
65410
OutQ
Up/Down
State
0 00:00:37 Established
Issue 01 (2011-10-15)
381
time = 170 ms
hop limit=62
time = 140 ms
hop limit=62
time = 150 ms
hop limit=62
time = 140 ms
hop limit=62
time = 170 ms
The address 1999::1/64 also exists on CE4. To determine whether the forwarding path is the
expected one, you only need to run the display ipv6 statistics interface command on PE2 to
check if the number of ICMPv6 packets sent and received on the interface changes.
Run the ping ipv6 -a 1998::1 -c 100 1999::1 command on CE1 to send 100 IPv6 data packets
with the source address to PE2. On PE2, run the display ipv6 statistics interface
gigabitethernet1/0/0 and display ipv6 statistics interface gigabitethernet2/0/0 commands
repeatedly to check the number of ICMPv6 packets sent and received on GE 1/0/0 and GE 2/0/0.
The command outputs show that the number of ICMPv6 packets sent and received on GE 2/0/0
keeps changing. It indicates that IPv6 data is forwarded to CE3 that is in the same VPN. It also
proves that vpna and vpnb are isolated from each other.
----End
Configuration Files
l
Issue 01 (2011-10-15)
382
Issue 01 (2011-10-15)
383
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
isis enable 1
#
return
Issue 01 (2011-10-15)
384
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.9 enable
#
ipv6-family vpn-instance vpna
import-route isis 10
#
ipv6-family vpn-instance vpnb
peer 2005::1 as-number 65420
#
return
Issue 01 (2011-10-15)
385
undo shutdown
ipv6 enable
ipv6 address 2004::1/64
isis ipv6 enable 10
#
interface LoopBack1
ipv6 enable
ipv6 address 1999::1/64
isis ipv6 enable 10
#
return
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
If different IPv6 VPN sites have the same AS number, and EBGP connections are established
between PEs and CEs, you need to enable BGP4+ AS number substitution on the PEs that the
VPN sites access.
Issue 01 (2011-10-15)
386
As shown in Figure 3-9, the AS numbers of CE1 and CE2 are both 65410; EBGP is used to
exchange routes between PE1 and CE1, and between PE2 and CE2.
The AS number 65410 is contained in the AS_Path attribute of the BGP routes learned by PE1
from CE1. PE2 learns BGP routes from PE1 and checks the AS_Path attribute of the routes
before using EBGP to send them to CE2. Finding that the AS number 65410 in the AS_Path
attribute of the routes is the same as the AS number of CE2, PE2 does not send the routes to
CE2. As a result, CE1 and CE2 cannot communicate with each other.
If BGP4+ AS number substitution is configured, PE2 will replace the AS number (65410) in the
AS_Path attribute of VPN routes with its own AS number (100). In this manner, the routes can
pass the AS number check provided by BGP and reach CE2, and then the two VPN sites can
access each other.
Figure 3-9 Networking diagram for configuring BGP4+ AS number substitution
Loopback1
1.1.1.9/32
PE1
POS1/0/0
2001:2/64
CE1
Loopback1
2.2.2.9/32
POS1/0/0
20.1.1.2/24
POS2/0/0
20.1.1.1/24
POS1/0/0
2001::1/64
POS2/0/0
30.1.1.2/24
POS2/0/0
30.1.1.1/24
P
Backbone
AS 100
Loopback1
3.3.3.9/32
PE2
POS1/0/0
2002::2/64
POS1/0/0
2002::1/64
Loopback1
1998::1/64
vpna
AS 65410
CE2
Loopback1
1999::1/64
vpna
AS 65410
Configuration Roadmap
The configuration roadmap is as follows:
1.
2.
3.
Data Preparation
To complete the configuration, you need the following data:
l
Same AS number of CE1 and CE2 (which differs from the AS number of the backbone
network)
Issue 01 (2011-10-15)
387
Procedure
Step 1 Configure basic BGP/MPLS IPv6 VPN.
For details on the configuration procedure, see Example for Configuring Basic BGP/MPLS
IPv6 VPN. The main configurations are listed below:
l Configure OSPF on the MPLS backbone network so that the PEs can learn the route to each
other's loopback interface.
l Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the MPLS
backbone network.
l Establish a VPNv6 peer relationship between the PEs.
l Create a VPN instance that supports the IPv6 address family on each PE and bind the interface
connecting the PE to a CE to the VPN instance.
l Configure BGP on PEs and CEs to exchange routing information.
After the configuration is complete, run the display ipv6 routing-table command on CE2. You
can find that CE2 has learned a route to the network segment 2001::1/64 where the interface that
connects CE1 to PE1 resides, but CE2 does not have a route to 1998::1/64, the loopback interface
of CE1. CE1 is in a similar situation.
<CE2> display ipv6 routing-table
Routing Table : _public_
Destinations : 7
Routes : 7
Issue 01 (2011-10-15)
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
1999::
1999::1
0
::
LoopBack1
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
1999::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::
2002::2
0
::
Pos1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::
2002::1
0
::
Pos1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
: FE80::
: ::
: 0
PrefixLength : 10
Preference
: 0
Protocol
: Direct
388
: 0x0
: D
Run the display ipv6 routing-table vpn-instance command on PE2. You can find that there is
a route to 1998::1/64, the loopback address of the remote CE, in the routing table of the VPN
instance IPv6 address family.
<PE2> display ipv6 routing-table vpn-instance vpna
Routing Table : vpna
Destinations : 6
Routes : 6
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
1998::
::FFFF:1.1.1.9
0
::FFFF:192.168.2.1
Pos2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x800007
RD
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
1999::
2002::1
0
::
Pos1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::
::FFFF:1.1.1.9
0
::FFFF:192.168.2.1
Pos2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x800007
RD
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::
2002::2
0
::
Pos1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::2
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
FE80::
::
0
::
NULL0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
10
0
Direct
0x0
D
Run the display bgp ipv6 routing-table peer received-routes command on CE2. You can find
that CE2 has not received a route with the prefix 1998::1/64.
[~CE2] display bgp ipv6 routing-table peer 2002::2 received-routes
BGP Local router ID is 30.30.30.30
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number
*> Network
NextHop
MED
Label
Path/Ogn
Network
NextHop
MED
Label
Path/Ogn
Issue 01 (2011-10-15)
of Routes: 2
: 2001::
: 2002::2
:
:
: 100 ?
: 2002::
: 2002::2
: 0
:
: 100 ?
PrefixLen : 64
LocPrf
:
PrefVal
: 0
PrefixLen : 64
LocPrf
:
PrefVal
: 0
389
Run the display bgp ipv6 routing-table peer received-routes command on CE2 to check the
routing information received from the EBGP peer. You can find that CE2 has received a route
to 1998::1/64 from PE2, and the value in the Path/Ogn field is 100 100. It indicates that the AS
number has been replaced.
[~CE2] display bgp ipv6 routing-table peer 2002::2 received-routes
BGP Local router ID is 30.30.30.30
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number
*> Network
NextHop
MED
Label
Path/Ogn
*> Network
NextHop
MED
Label
Path/Ogn
Network
NextHop
MED
Label
Path/Ogn
of Routes: 3
: 1998::
: 2002::2
:
:
: 100 100 i
: 2001::
: 2002::2
:
:
: 100 ?
: 2002::
: 2002::2
: 0
:
: 100 ?
PrefixLen : 64
LocPrf
:
PrefVal
: 0
PrefixLen : 64
LocPrf
:
PrefVal
: 0
PrefixLen : 64
LocPrf
:
PrefVal
: 0
After BGP4+ AS number substitution is configured on PE1, the ping (with the source address
specified in the ping command) between CE1 and CE2 succeeds.
[~CE2] ping ipv6 -a 1999::1 1998::1
PING 1998::1 : 56 data bytes, press CTRL_C to
Reply from 1998::1
bytes=56 Sequence=1 hop limit=62 time = 140
Reply from 1998::1
bytes=56 Sequence=2 hop limit=62 time = 140
Reply from 1998::1
bytes=56 Sequence=3 hop limit=62 time = 150
Reply from 1998::1
bytes=56 Sequence=4 hop limit=62 time = 170
Reply from 1998::1
bytes=56 Sequence=5 hop limit=62 time = 140
break
ms
ms
ms
ms
ms
----End
Issue 01 (2011-10-15)
390
Configuration Files
l
Issue 01 (2011-10-15)
391
Issue 01 (2011-10-15)
392
Issue 01 (2011-10-15)
393
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
Load balancing among IPv6 VPN routes can be applied in the following situations:
l
A PE receives multiple VPNv6 routes with the same prefix from different peer PEs.
Different CEs at a site use BGP to access the same PE, and the PE learns multiple IPv6
VPN routes with the same VPN prefix from the CEs.
As shown in Figure 3-10, PE1 sets up a VPNv6 peer relationship with PE2 and PE3 and learns
two routes to the CE from PE2 and PE3. It is required that load balancing among IPv6 VPN
routes be configured on PE1 to load balance the IPv6 VPN traffic destined for CE1 between
PE2 and PE3.
Figure 3-10 Networking diagram for configuring load balancing among IPv6 VPN routes
Loopback1
2.2.2.2/32
VPN backbone
Loopback1
POS1/0/0
1.1.1.1/32 AS100
100.1.1.2/30
POS2/0/0
100.1.1.1/30
Loopback2
1999::1/128
PE1
POS3/0/0
100.2.1.1/30
PE2
GE2/0/0
2001::2/64
Loopback1
200:0:1:2::1/128
GE1/0/0
2001::1/64
Link_A
CE
Link_B
POS1/0/0
100.2.1.2/30
GE2/0/0
2003::2/64
GE2/0/0
2003::1/64
PE3
Loopback1
3.3.3.3/32
Configuration Notes
When configuring load balancing between IPv6 routes, note the following:
l
The RDs configured for the IPv6 VPN instance on PE2 and PE3 must be different.
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure BGP/MPLS IPv6 VPN, and connect the CE to PE2 and PE3.
2.
Configure load balancing among IPv6 VPN routes for the BGP-VPN instance IPv6 address
family on PE1.
Issue 01 (2011-10-15)
394
Procedure
Step 1 Configure IPv4 addresses for interfaces on the backbone network of the VPN and IPv6 addresses
for interfaces at the VPN site. Details for configuration procedures are not provided here.
Step 2 Configure OSPF on the MPLS backbone network for IP connectivity between the PEs on the
backbone network. Details for configuration procedures are not provided here.
Step 3 Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the MPLS
backbone network.
# Configure PE1.
<PE1> system-view
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos2/0/0
[~PE1-Pos2/0/0] mpls
[~PE1-Pos2/0/0] mpls ldp
[~PE1-Pos2/0/0] quit
[~PE1] interface pos3/0/0
[~PE1-Pos3/0/0] mpls
[~PE1-Pos3/0/0] mpls ldp
[~PE1-Pos3/0/0] quit
[~PE1] commit
# Configure PE2.
<PE2> system-view
[~PE2] mpls lsr-id 2.2.2.2
[~PE2] mpls
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] quit
[~PE2] interface pos1/0/0
[~PE2-Pos1/0/0] mpls
[~PE2-Pos1/0/0] mpls ldp
[~PE2-Pos1/0/0] quit
[~PE2] commit
# Configure PE3.
<PE3> system-view
[~PE3] mpls lsr-id 3.3.3.3
[~PE3] mpls
[~PE3-mpls] quit
[~PE3] mpls ldp
[~PE3-mpls-ldp] quit
[~PE3] interface pos1/0/0
[~PE3-Pos1/0/0] mpls
[~PE3-Pos1/0/0] mpls ldp
[~PE3-Pos1/0/0] quit
[~PE3] commit
Run the display mpls lsp command on the PEs. You can view that LSPs are set up between PE1
and PE2, and between PE1 and PE3. The following uses the display on PE1 as an example:
[~PE1] display mpls lsp
------------------------------------------------------------------------------LSP Information: LDP LSP
------------------------------------------------------------------------------FEC
In/Out Label In/Out IF
Vrf Name
1.1.1.1/32
3/NULL
-/2.2.2.2/32
NULL/3
-/Pos2/0/0
2.2.2.2/32
1025/3
-/Pos2/0/0
Issue 01 (2011-10-15)
395
-/Pos3/0/0
-/Pos3/0/0
Step 4 Configure a VPN instance that supports the IPv6 address family on each PE, and connect the
CE to PE2 and PE3.
# Configure PE1.
[~PE1] ip vpn-instance vpn1
[~PE1-vpn-instance-vpn1] ipv6-family
[~PE1-vpn-instance-vpn1-af-ipv6] route-distinguisher 100:1
[~PE1-vpn-instance-vpn1-af-ipv6] vpn-target 111:1
[~PE1-vpn-instance-vpn1-af-ipv6] quit
[~PE1-vpn-instance-vpn1] quit
[~PE1] interface loopback2
[~PE1-Loopback2] ip binding vpn-instance vpn1
[~PE1-Loopback2] ipv6 enable
[~PE1-Loopback2] ipv6 address 1999::128
[~PE1-Loobpack2] quit
[~PE1] commit
# Configure PE2.
[~PE2] ip vpn-instance vpn1
[~PE2-vpn-instance-vpn1] ipv6-family
[~PE2-vpn-instance-vpn1-af-ipv6] route-distinguisher 100:2
[~PE2-vpn-instance-vpn1-af-ipv6] vpn-target 111:1
[~PE2-vpn-instance-vpn1-af-ipv6] quit
[~PE2-vpn-instance-vpn1] quit
[~PE2] interface gigabitethernet2/0/0
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE2-GigabitEthernet2/0/0] ipv6 enable
[~PE2-GigabitEthernet2/0/0] ipv6 address 2001::2 64
[~PE2-GigabitEthernet2/0/0] quit
[~PE2] commit
# Configure PE3.
[~PE3] ip vpn-instance vpn1
[~PE3-vpn-instance-vpn1] ipv6-family
[~PE3-vpn-instance-vpn1-af-ipv6] route-distinguisher 100:3
[~PE3-vpn-instance-vpn1-af-ipv6] vpn-target 111:1
[~PE3-vpn-instance-vpn1-af-ipv6] quit
[~PE3-vpn-instance-vpn1] quit
[~PE3] interface gigabitethernet2/0/0
[~PE3-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE3-GigabitEthernet2/0/0] ipv6 enable
[~PE3-GigabitEthernet2/0/0] ipv6 address 2003::2 64
[~PE3-GigabitEthernet2/0/0] quit
[~PE3] commit
Step 5 Establish an EBGP peer relationship between PE2 and the CE, and between PE3 and the CE.
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] ipv6-family vpn-instance vpn1
[~PE2-bgp6-vpn1] peer 2001::1 as-number 65410
[~PE2-bgp6-vpn1] quit
[~PE2-bgp] quit
[~PE2] commit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] ipv6-family vpn-instance vpn1
[~PE3-bgp6-vpn1] peer 2003::1 as-number 65410
[~PE3-bgp6-vpn1] quit
[~PE3-bgp] quit
Issue 01 (2011-10-15)
396
[~PE3-bgp] commit
After the configuration is complete, run the display bgp vpnv6 all peer command on PE2 and
PE3. You can find that the status of the EBGP peer relationship between the PEs and CE is
Established. This means that the EBGP peer relationships are successfully set up.
The following uses the display on PE2 as an example:
[~PE2] display bgp vpnv6 all peer
BGP local router ID : 2.2.2.2
Local AS number : 100
Total number of peers : 2
Peer
PrefRcv
AS
MsgRcvd
MsgSent
100
27
24
0 00:19:33 Established
10
0 00:08:30 Established
1.1.1.1
OutQ
Up/Down
State
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 1.1.1.1 as-number 100
[~PE2-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE2-bgp] ipv6-family vpnv6
[~PE2-bgp-af-vpnv6] peer 1.1.1.1 enable
[~PE2-bgp-af-vpnv6] quit
[~PE2-bgp] quit
[~PE2-bgp] commit
# Configure PE3.
[~PE3] bgp 100
Issue 01 (2011-10-15)
397
After the configuration is complete, run the display bgp vpnv6 all peer command on the PEs.
You can find that the status of the MP-IBGP peer relationships between PEs is Established.
This means that the MP-IBGP peer relationships are successfully set up.
The following uses the display on PE1 as an example:
<PE1> display bgp vpnv6 all peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 2
Peer
V
AS MsgRcvd
2.2.2.2
4
100
20
3.3.3.3
4
100
24
MsgSent
17
19
:
:
:
:
:
200:0:1:2::1
::FFFF:2.2.2.2
0
::FFFF:100.1.1.2
Pos2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
255
BGP
0x800003
RD
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
200:0:1:2::1
::FFFF:3.3.3.3
0
::FFFF:100.2.1.2
Pos3/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
255
BGP
0x800001
RD
----End
Configuration Files
l
Issue 01 (2011-10-15)
398
Issue 01 (2011-10-15)
399
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 100.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface GigabitEthernet2/0/0
undo shutdown
ipv6 enable
ip binding vpn-instance vpn1
ipv6 address 2001::2/64
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
peer 1.1.1.1 as-number 100
peer 1.1.1.1 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.1 enable
#
ipv6-family vpn-instance vpn1
peer 2001::1 as-number 65410
import-route direct
#
ospf 1
area 0.0.0.0
network 100.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
#
return
Issue 01 (2011-10-15)
400
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
peer 1.1.1.1 as-number 100
peer 1.1.1.1 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.1 enable
#
ipv6-family vpn-instance vpn1
peer 2003::1 as-number 65410
#
ospf 1
area 0.0.0.0
network 100.2.1.0 0.0.0.3
network 3.3.3.3 0.0.0.0
#
return
401
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
If multiple tunnels such as LDP LSPs and TE tunnels exist between peer PEs on the MPLS
backbone network of a BGP/MPLS IPv6 VPN, load balancing among tunnels can be configured
to distribute IPv6 VPN traffic to the tunnels and prevent network congestion.
As shown in Figure 3-11, two links exist between PE1 and PE2 in the basic BGP/MPLS IPv6
VPN networking: an LDP LSP (PE1-P1-PE2) and a TE tunnel (PE1-P2-PE2). All IPv6 VPN
traffic is forwarded over the LSP according to the default tunnel policy, which may cause the
link of PE1-P1-PE2 to be busy and the link of PE1-P2-PE2 to be idle.
To address this problem, load balancing among tunnels can be configured on the MPLS backbone
network to distribute IPv6 VPN traffic evenly to the two tunnels.
Figure 3-11 Networking diagram for configuring load balancing among tunnels to which remote
cross routes are iterated on an IPv6 VPN
Loopback1
2.2.2.9/32
Loopback1
1.1.1.9/32
PE1
PO
30 S2/
.1.
0
1.1 /0
/24
0
/ 0/
S1 2/24
O
P . 1.
.1
20
P1
0
/ 0/
S2 1/24
O
P . 1.
.1
20
PO
PO
10 S1/0
S
.1.
10
1.2 /0
.1. 1/0/0
/24
1.1
Loopback2
/24
1999::1/128
Backbone
AS 100
P2
Loopback1
200:0:1:2::1/128
Loopback1
3.3.3.9/32
PO
30 S2
.1. /0/
1.2 0
/24
PE2
GE1/0/0
2002::2/64
GE3/0/0
0
2002::1/64
/
/0
/0
S1 /24
1/ 0 / 24
S
P O 1 .1 .1
.
PO 1.1.2
40
.
40
CE2
Loopback1
4.4.4.9/32
Configuration Notes
When configuring load balancing among tunnels to which remote cross routes are iterated on
an IPv6 VPN, note the following:
l
Issue 01 (2011-10-15)
The tunnels existing in the system can meet the requirements of the configured tunnel
policy.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
402
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure OSPF on the MPLS backbone network for IP connectivity between devices on
the backbone network.
2.
On the MPLS backbone network, enable MPLS and MPLS LDP to set up an LDP LSP;
enable MPLS TE to set up an MPLS TE tunnel.
3.
Configure an IPv6 address family-enabled VPN instance on the PEs and connect the CE
to PE2.
4.
Create a tunnel policy on PE1 to distribute traffic to the LDP LSP and TE tunnel between
PE1 and PE2.
5.
Apply the tunnel policy to the VPN instance IPv6 address family on PE1.
Procedure
Step 1 Configure basic BGP/MPLS IPv6 VPN.
For details on the configuration procedure, see Example for Configuring Basic BGP/MPLS
IPv6 VPN. The main configurations are listed below:
l Configure OSPF on the MPLS backbone network so that the PEs can learn the route to each
other's loopback interface.
l Configure basic MPLS functions and enable MPLS LDP on PE1, P1, and PE2 to set up an
LDP LSP between the PEs.
l Enable MPLS TE on PE1, P2, and PE2 to set up an MPLS TE tunnel between the PEs.
l Establish a VPNv6 peer relationship between the PEs.
l Create a VPN instance that supports the IPv6 address family on each PE and bind the interface
connecting the PE to the CE to the VPN instance.
l Enable BGP between the PEs and CE, and import the routes to the loopback interface into
BGP on the CE.
After the configuration is complete, run the display ipv6 routing-table vpn-instance command
on PE1. You can find that PE1 has learned the route to the loopback interface on the CE.
<PE1> display ipv6 routing-table vpn-instance vpn1
Routing Table : vpn1
Destinations : 4
Routes : 4
Issue 01 (2011-10-15)
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
200:0:1:2::1
::FFFF:3.3.3.9
0
::
LDP LSP
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
255
BGP
0x800011
RD
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
1999::
1999::1
0
::
LoopBack2
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
28
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
1999::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
: FE80::
PrefixLength : 10
403
: ::
Preference
: 0
: 0
Protocol
: Direct
: ::
TunnelID
: 0x0
: NULL0
Flags
: D
ipv6 routing-table vpn-instance vpn1 200:0:1:2::1 verbose
: vpn1
: 1
Destination : 200:0:1:2::1
NextHop
: ::FFFF:3.3.3.9
Neighbour
: ::3.3.3.9
Label
: 1027
State
: Active Adv Relied
Entry ID
: 21
Reference Cnt: 2
IndirectID
: 0x24
RelayNextHop : ::
0x0000000001004c4ba2
Interface
: LDP LSP
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
:
:
:
:
:
:
:
:
Flags
128
255
0
BGP
0
0x80024904
0
895sec
:
: RD
The command output shows that PE1 iterates the route to 200:0:1:2::1/128 to only one LSP since
no tunnel policy is applied to the VPN instance IPv6 address family, and the outbound interface
is POS 2/0/0.
Step 2 Apply a tunnel policy to the VPN instance IPv6 address family on PE1.
Configure a tunnel policy in select-sequence mode to make tunnels be selected in the order of
TE tunnels and LSPs and to set the number of tunnels participating in load balancing to 2.
# Configure PE1.
[~PE1] tunnel-policy te-lsp-l2
[~PE1-tunnel-policy-te-lsp-l2] tunnel select-seq cr-lsp lsp load-balance-number 2
[~PE1-tunnel-policy-te-lsp-l2] quit
# Apply the tunnel policy to the VPN instance IPv6 address family.
[~PE1] ip vpn-instance vpn1
[~PE1-vpn-instance-vpn1] ipv6-family
[~PE1-vpn-instance-vpn1-af-ipv6] tnl-policy te-lsp-l2
[~PE1-vpn-instance-vpn1-af-ipv6] quit
[~PE1-vpn-instance-vpn1] quit
[~PE1] commit
Issue 01 (2011-10-15)
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
:
:
:
:
:
:
:
:
:
Flags
TunnelID
: RD
:
Flags
: RD
128
255
0
BGP
0
0x80024904
0
895sec
404
Load balancing between tunnels to which remote cross routes are iterated is successfully
deployed on the IPv6 VPN.
----End
Configuration Files
l
Issue 01 (2011-10-15)
405
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
tunnel-policy te-lsp-l2
tunnel select-seq cr-lsp lsp load-balance-number 2
#
return
Configuration file of P1
#
sysname P1
#
mpls lsr-id 2.2.2.9
#
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 30.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 2.2.2.9 0.0.0.0
network 20.1.1.0 0.0.0.255
network 30.1.1.0 0.0.0.255
#
return
Configuration file of P2
#
sysname P2
#
mpls lsr-id 4.4.4.9
#
mpls
mpls te
mpls te cspf
mpls rsvp-te
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
Issue 01 (2011-10-15)
406
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 40.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 4.4.4.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
407
undo synchronization
peer 1.1.1.9 enable
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.9 enable
#
ipv6-family vpn-instance vpn1
peer 2002::2 as-number 65410
#
ospf 1
opaque-capability enable
area 0.0.0.0
mpls-te enable
network 3.3.3.9 0.0.0.0
network 30.1.1.0 0.0.0.255
network 40.1.1.0 0.0.0.255
#
return
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
Inter-AS IPv6 VPN Option A can be deployed if IPv6 VPN services need to be provided to
customers across ASs on a carrier's backbone network.
Issue 01 (2011-10-15)
408
It is easy to configure inter-AS IPv6 VPN Option A. You only need to create an IPv6 address
family-supporting VPN instance on ASBRs and configure the ASBRs to consider each other as
a CE. If services of many VPNs need to be transmitted across ASs, the requirements on ASBR
performance will be high.
As shown in Figure 3-12, CE1 and CE2 belong to the same VPN. CE1 accesses PE1 in AS 100;
CE2 accesses PE2 in AS 200.
It is required that Option A be configured to implement inter-AS IPv6 VPN so that CE1 and
CE2 can access each other.
Figure 3-12 Networking diagram for configuring inter-AS VPN Option A
BGP/MPLS Backbone
AS 100
Loopback1
2.2.2.9/32
POS2/0/0
POS1/0/0
2003::1/64
172.1.1.1/24
Loopback1
ASBR1
1.1.1.9/32
BGP/MPLS Backbone
AS 200
Loopback1
3.3.3.9/32
POS2/0/0
2003::2/64
POS1/0/0
162.1.1.1/24
Loopback1
ASBR2
4.4.4.9/32
POS1/0/0
172.1.1.2/24
PE1
POS1/0/0
162.1.1.2/24
GE2/0/0
2001::2/64
GE2/0/0
2002::2/64
GE1/0/0
2001::1/64
GE1/0/0
2002::1/64
CE1
AS 65001
PE2
CE2
AS 65002
Configuration Roadmap
The configuration roadmap is as follows:
1.
Establish EBGP peer relationships between the PEs and CEs and establish MP-IBGP peer
relationships between the PEs and ASBRs.
2.
Create an IPv6 address family-enabled VPN instance and bind the instance to the interface
connecting to the peer ASBR on each ASBR; establish an EBGP peer relationship between
the ASBRs.
Data Preparation
To complete the configuration, you need the following data:
l
Name of the IPv6 address family-enabled VPN instance configured on each PE and ASBR,
and the RD and VPN target of the instance
Issue 01 (2011-10-15)
409
Procedure
Step 1 Configure an IGP on the MPLS backbone networks of AS 100 and AS 200 for IP connectivity
between the ASBR and the PE within each MPLS backbone network.
In this example, OSPF is configured as an IGP. Details for the configuration procedures are not
provided here.
NOTE
The 32-bit IP address of the loopback interface that functions as the LSR ID needs to be advertised by
using OSPF.
After the configuration is complete, the OSPF neighbor relationship can be established between
the ASBR and the PE in the same AS. Run the display ospf peer command, and you can view
that the neighbor relationship is in the Full state.
The ASBR and PE in the same AS can learn the LSR ID (IP address of Loopback 1) of each
other and ping each other successfully.
Step 2 Configure basic MPLS functions, enable MPLS LDP, and set up MPLS LDP LSPs on the MPLS
backbone networks of AS 100 and AS 200.
# Configure basic MPLS functions on PE1 and enable LDP on the interface connecting PE1 to
ASBR1.
<PE1> system-view
[~PE1] mpls lsr-id 1.1.1.9
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos1/0/0
[~PE1-Pos1/0/0] mpls
[~PE1-Pos1/0/0] mpls ldp
[~PE1-Pos1/0/0] quit
[~PE1] commit
# Configure basic MPLS functions on ASBR1 and enable LDP on the interface connecting
ASBR1 to PE1.
<ASBR1> system-view
[~ASBR1] mpls lsr-id 2.2.2.9
[~ASBR1] mpls
[~ASBR1-mpls] quit
[~ASBR1] mpls ldp
[~ASBR1-mpls-ldp] quit
[~ASBR1] interface pos1/0/0
[~ASBR1-Pos1/0/0] mpls
[~ASBR1-Pos1/0/0] mpls ldp
[~ASBR1-Pos1/0/0] quit
[~ASBR1] commit
# Configure basic MPLS functions on ASBR2 and enable LDP on the interface connecting
ASBR2 to PE2.
<ASBR2> system-view
[~ASBR2] mpls lsr-id 3.3.3.9
[~ASBR2] mpls
[~ASBR2-mpls] quit
[~ASBR2] mpls ldp
[~ASBR2-mpls-ldp] quit
[~ASBR2] interface pos1/0/0
[~ASBR2-Pos1/0/0] mpls
[~ASBR2-Pos1/0/0] mpls ldp
[~ASBR2-Pos1/0/0] quit
Issue 01 (2011-10-15)
410
[~ASBR2] commit
# Configure basic MPLS functions on PE2 and enable LDP on the interface connecting PE2 to
ASBR2.
<PE2> system-view
[~PE2] mpls lsr-id 4.4.4.9
[~PE2] mpls
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] quit
[~PE2] interface pos1/0/0
[~PE2-Pos1/0/0] mpls
[~PE2-Pos1/0/0] mpls ldp
[~PE2-Pos1/0/0] quit
[~PE20] commit
After the configuration is complete, an LDP peer relationship can be set up between the PE and
the ASBR in the same AS. Run the display mpls ldp session command on each device, and you
can view that the session state is displayed as Operational.
The following uses the display on PE1 as an example:
[~PE1] display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
-------------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
-------------------------------------------------------------------------2.2.2.9:0
Operational DU
Passive 0000:00:02 9/9
-------------------------------------------------------------------------TOTAL: 1 session(s) Found.
The VPN targets of the IPv6 address family-enabled VPN instance configured on the ASBR and the PE in
the same AS must be matched. This is not required for the PEs in different ASs.
# Configure CE1.
<CE1> system-view
[~CE1] interface gigabitethernet 1/0/0
[~CE1-GigabitEthernet1/0/0] ipv6 enable
[~CE1-GigabitEthernet1/0/0] ipv6 address 2001::1 64
[~CE1-GigabitEthernet1/0/0] quit
[~CE1] bgp 65001
[~CE1-bgp] router-id 10.10.10.10
[~CE1-bgp] peer 2001::2 as-number 100
[~CE1-bgp] ipv6-family unicast
[~CE1-bgp-af-ipv6] peer 2001::2 enable
[~CE1-bgp-af-ipv6] import-route direct
[~CE1-bgp-af-ipv6] quit
[~CE1-bgp] quit
[~CE1] commit
Issue 01 (2011-10-15)
411
The configurations of CE2, PE2, and ASBR2 are similar to the configurations of CE1, PE1, and ASBR1
respectively, and details are not provided here.
After the configuration is complete, run the display bgp vpnv6 vpn-instance peer command
on the PEs, and you can view that the BGP peer relationships between the PEs and the CEs are
in the Established state. Run the display bgp vpnv6 all peer command on the PE or ASBR,
and you can view that the BGP peer relationship is established between the PEs and the CEs,
and between the PEs and ASBRs.
The following uses the display on PE1 as an example:
[~PE1] display bgp vpnv6 vpn-instance vpn1 peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
V
AS MsgRcvd MsgSent OutQ Up/Down
State PrefRcv
2001::1
4 65001
14
12
0 00:08:36 Established
1
[~PE1] display bgp vpnv6 all peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 2
Peers in established state : 2
Peer
V
AS MsgRcvd MsgSent OutQ Up/Down
State PrefRcv
2.2.2.9
4
100
13
12
0 00:09:10 Established
0
Peer of vpn instance :
VPN-Instance vpn1, router ID 1.1.1.9:
2001::1
4 65001
17
14
0 00:11:09 Established
Issue 01 (2011-10-15)
412
# Create an IPv6 address family-enabled VPN instance on ASBR2 and bind the interface that
connects ASBR2 to ASBR1 (it is considered as a CE by ASBR2) to the VPN instance.
[~ASBR2] ip vpn-instance vpn1
[~ASBR2-vpn-instance-vpn1] ipv6-family
[~ASBR2-vpn-instance-vpn1-af-ipv6] route-distinguisher 200:2
[~ASBR2-vpn-instance-vpn1-af-ipv6] vpn-target 2:2 both
[~ASBR2-vpn-instance-vpn1-af-ipv6] quit
[~ASBR2-vpn-instance-vpn1] quit
[~ASBR2] interface pos 2/0/0
[~ASBR2-Pos2/0/0] ip binding vpn-instance vpn1
[~ASBR2-Pos2/0/0] ipv6 enable
[~ASBR2-Pos2/0/0] ipv6 address 2003::2 64
[~ASBR2-Pos2/0/0] quit
[~ASBR2] commit
After the configuration is complete, run the display bgp vpnv6 vpn-instance peer command,
and you can view that the BGP peer relationship between the ASBRs is in the Established state.
Step 5 Verify the configuration.
After the configuration is complete, the CEs can learn routes of interfaces of each other and
successfully ping each other. The following uses the display on CE1 as an example:
[~CE1] display ipv6 routing-table
Routing Table : _public_
Destinations : 6
Routes : 6
Issue 01 (2011-10-15)
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
:
:
:
:
2001::
2001::1
0
::
PrefixLength
Preference
Protocol
TunnelID
:
:
:
:
64
0
Direct
0x0
413
Interface
: GigabitEthernet1/0/0
Flags
: D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::
2001::2
0
::
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2003::
2001::2
0
::
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x0
D
Destination : FE80::
PrefixLength
NextHop
: ::
Preference
Cost
: 0
Protocol
RelayNextHop : ::
TunnelID
Interface
: NULL0
Flags
[~CE1] ping ipv6 2002::1
PING 2002::1 : 56 data bytes, press CTRL_C to break
Reply from 2002::1
bytes=56 Sequence=1 hop limit=60 time = 94 ms
Reply from 2002::1
bytes=56 Sequence=2 hop limit=60 time = 109 ms
Reply from 2002::1
bytes=56 Sequence=3 hop limit=60 time = 110 ms
Reply from 2002::1
bytes=56 Sequence=4 hop limit=60 time = 94 ms
Reply from 2002::1
bytes=56 Sequence=5 hop limit=60 time = 110 ms
--- 2002::1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 94/103/110 ms
:
:
:
:
:
10
0
Direct
0x0
D
Run the display ipv6 routing-table vpn-instance command on either of ASBRs, and you can
view the routing table of the VPN instance IPv6 address maintained on the ASBR. The following
uses the display on ASBR1 as an example:
<ASBR1> display ipv6 routing-table vpn-instance vpn1
Routing Table : vpn1
Destinations : 5
Routes : 5
Issue 01 (2011-10-15)
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::
::FFFF:1.1.1.9
0
::
NULL0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0xa0010082
RD
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::
2003::2
0
::
Pos2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2003::
2003::1
0
::
Pos2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
414
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2003::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
FE80::
::
0
::
NULL0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
10
0
Direct
0x0
D
Run the display bgp vpnv6 all routing-table command on either of ASBRs, and you can view
the IPv6 VPN routes on the ASBR. The following uses the display on ASBR1 as an example:
<ASBR1> display bgp vpnv6 all routing-table
BGP Local router ID is 2.2.2.9
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 4
Route Distinguisher: 100:1
*>i Network
NextHop
MED
Label
Path/Ogn
:
:
:
:
:
2001::
::FFFF:1.1.1.9
0
105472
?
PrefixLen : 64
LocPrf
: 100
PrefVal
: 0
*>
Network
NextHop
MED
Label
Path/Ogn
Network
NextHop
MED
Label
Path/Ogn
:
:
:
:
:
:
:
:
:
:
2002::
2003::2
NextHop
MED
Label
Path/Ogn
:
:
:
:
2003::2
0
NULL
200 ?
NULL
200 ?
2003::
::
0
NULL
?
PrefixLen : 64
LocPrf
:
PrefVal
: 0
PrefixLen : 64
LocPrf
:
PrefVal
: 0
*
LocPrf
PrefVal
:
: 0
VPN-Instance vpn1 :
Total Number
*>i Network
NextHop
MED
Label
Path/Ogn
*> Network
NextHop
MED
Label
Path/Ogn
*> Network
NextHop
MED
Label
Path/Ogn
*
Issue 01 (2011-10-15)
of Routes: 4
: 2001::
: ::FFFF:1.1.1.9
: 0
: 105472
: ?
: 2002::
: 2003::2
:
: NULL
: 200 ?
: 2003::
: ::
: 0
: NULL
: ?
PrefixLen : 64
LocPrf
: 100
PrefVal
: 0
PrefixLen : 64
LocPrf
:
PrefVal
: 0
PrefixLen : 64
LocPrf
:
PrefVal
: 0
415
:
:
:
:
2003::2
0
NULL
200 ?
LocPrf
PrefVal
:
: 0
----End
Configuration Files
l
Issue 01 (2011-10-15)
416
#
ipv6-family vpnv6
policy vpn-target
peer 2.2.2.9 enable
#
ipv6-family vpn-instance vpn1
peer 2001::1 as-number 65001
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
417
#
return
Issue 01 (2011-10-15)
418
Issue 01 (2011-10-15)
419
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 3-13, CE1 and CE2 belong to the same VPN. CE1 is connected to PE1 in
AS 100, and CE2 is connected to PE2 in AS 200. It is required that an MP-EBGP peer relationship
be established between the ASBRs to transmit VPNv6 routes, thus implementing inter-AS VPN
Option B.
Figure 3-13 Networking diagram of inter-AS IPv6 VPN Option B
BGP/MPLS Backbone
AS 100
Loopback1
2.2.2.9/32
POS1/0/0
172.1.1.1/24
Loopback1
1.1.1.9/32
POS2/0/0
192.1.1.1/24
ASBR1
BGP/MPLS Backbone
AS 200
Loopback1
3.3.3.9/32
POS2/0/0
192.1.1.2/24
POS1/0/0
162.1.1.1/24
Loopback1
ASBR2
4.4.4.9/32
POS1/0/0
172.1.1.2/24
PE1
POS1/0/0
162.1.1.2/24
GE2/0/0
2001::2/64
GE2/0/0
2002::2/64
GE1/0/0
2001::1/64
GE1/0/0
2002::1/64
PE2
CE2
AS 65002
CE1
AS 65001
Configuration Notes
When configuring inter-AS IPv6 VPN Option B, note the following:
l
Issue 01 (2011-10-15)
An MP-EBGP peer relationship is established between ASBR1 and ASBR2, and the
ASBRs do not filter received VPNv6 routes based on VPN targets.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
420
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP on the MPLS backbone network to implement interworking of the ASBR
and PE in the same AS, and set up an MPLS LDP LSP between the ASBR and PE in the
same AS.
2.
Set up EBGP peer relationships between the PEs and CEs and set up MP-IBGP peer
relationships between the PEs and ASBRs.
3.
4.
Enable MPLS on the interface that connects one ASBR to the other ASBR, set up an MPEBGP peer relationship between the ASBRs, and configure the ASBRs not to filter received
VPNv6 routes based on VPN targets.
Data Preparation
To complete the configuration, you need the following data:
l
Names, RDs, and VPN targets of the VPN instances of the PEs
Procedure
Step 1 On the MPLS backbone networks in AS 100 and AS 200, configure an IGP to interconnect the
PE and ASBR on each network.
In this example, OSPF is used as the IGP protocol. For details, see "Configuration Files."
NOTE
The 32-bit IP address of the loopback interface that functions as the LSR ID needs to be advertised by
using OSPF.
After the configuration, the OSPF neighbor relationship can be established between the ASBR
and PE in the same AS. Run the display ospf peer command, and you can view that the neighbor
relationship is in the Full state.
The ASBR and PE in the same AS can learn and successfully ping the IP address of the loopback
interface of each other.
Step 2 Configure basic MPLS functions and MPLS LDP, and set up MPLS LDP LSPs on the MPLS
backbone networks in AS 100 and AS 200.
The detailed configuration is not mentioned here. For details, see 3.14.5 Example for
Configuring Inter-AS IPv6 VPN Option A.
Step 3 Configure the basic BGP/MPLS IPv6 VPN functions on PE1 and PE2.
NOTE
The VPN targets of the VPN instances of PE1 and PE2 must be the same.
The detailed configuration is not mentioned here. For details, see "Configuration Files."
Step 4 Configure inter-AS VPN-Option B mode.
# Configure ASBR1. Enable MPLS on POS2/0/0 connected with ASBR2.
<ASBR1> system-view
Issue 01 (2011-10-15)
421
# Configure ASBR1. Establish MP-EBGP peer with ASBR2 and perform no VPN-Target
filtering on the received VPN-IPv6 routes, and then enable ASBR 1 to allocate labels based on
the next hop.
[~ASBR1] bgp 100
[~ASBR1-bgp] peer 192.1.1.2 as-number 200
[~ASBR1-bgp] ipv6-family vpnv6
[~ASBR1-bgp-af-vpnv6] peer 192.1.1.2 enable
[~ASBR1-bgp-af-vpnv6] undo policy vpn-target
[~ASBR1-bgp-af-vpnv6] quit
[~ASBR1-bgp] quit
[~ASBR1] commit
NOTE
The configurations of ASBR2 are similar to that of ASBR1 and are not mentioned here.
:
:
:
:
:
::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
::FFFF:127.0.0.0
::FFFF:127.0.0.1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
104
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
::FFFF:127.0.0.1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::
2001::1
0
::
Gigabitethernet3/1/1
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::1
::1
0
::
Gigabitethernet3/1/1
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::
2001::2
0
2001::2
Gigabitethernet3/1/1
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x0
RD
Issue 01 (2011-10-15)
422
Destination : FE80::
NextHop
: ::
Cost
: 0
RelayNextHop : ::
Interface
: NULL0
<CE1> ping ipv6 2002::1
PING 2002::1 : 56 data bytes, press CTRL_C to
Reply from 2002::1
bytes=56 Sequence=1 hop limit=62 time = 125
Reply from 2002::1
bytes=56 Sequence=2 hop limit=62 time = 109
Reply from 2002::1
bytes=56 Sequence=3 hop limit=62 time = 109
Reply from 2002::1
bytes=56 Sequence=4 hop limit=62 time = 109
Reply from 2002::1
bytes=56 Sequence=5 hop limit=62 time = 110
--- 2002::1 ping statistics --5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 109/112/125 ms
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
10
0
Direct
0x0
D
break
ms
ms
ms
ms
ms
Run the display bgp vpnv6 all routing-table command on an ASBR, and you can view the
VPNv6 routes on the ASBR.
Take the display on ASBR1 as an example.
<ASBR1> display bgp vpnv6 all routing-table
BGP Local router ID is 192.1.1.1
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total number of routes from all PE: 2
Route Distinguisher: 100:1
*>i Network : 2001::
NextHop : ::FFFF:1.1.1.9
MED
: 0
Label
: 21/23
Path/Ogn : 65410?
Route Distinguisher: 200:2
PrefixLen : 64
LocPrf
: 100
PrefVal
: 0
*>
PrefixLen : 64
LocPrf
:
PrefVal
: 0
Network
NextHop
MED
Label
Path/Ogn
:
:
:
:
:
2002::
::FFFF:192.1.1.2
25/25
200 65411?
----End
Configuration Files
l
Issue 01 (2011-10-15)
423
Issue 01 (2011-10-15)
424
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 192.1.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
peer 192.1.1.2 as-number 200
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 192.1.1.2 enable
peer 1.1.1.9 enable
#
ipv6-family vpnv6
undo policy vpn-target
peer 1.1.1.9 enable
peer 192.1.1.2 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
425
Issue 01 (2011-10-15)
426
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, an interface is numbered in the format of chassis ID/
slot number/card number/interface number. If the slot number is specified, the chassis ID of the
slot must also be specified.
VPNv6 FRR can be deployed in the CE dual-homing networking. If the primary link between
PEs fails, VPNv6 FRR can quickly switch IPv6 VPN traffic to the backup link.
As shown in Figure 3-14, PE1 learns two routes with the same prefix to the CE from PE2 and
PE3. It is required that PE3 be configured as a backup next hop for the IPv6 route on PE1. In
this manner, VPN traffic can be quickly switched to PE3 if PE2 becomes faulty.
Issue 01 (2011-10-15)
427
VPNbackbone
Loopback1
POS1/0/0
1.1.1.1/32 AS100
100.1.1.2/30
POS2/0/0
100.1.1.1/30
Loopback2
1999::1/64
PE1
POS3/0/0
100.2.1.1/30
PE2
Loopback1
200:0:1:2::1/128
GE2/0/0
2001::2/64
GE1/0/0
2001::1/64
Link_A
CE
Link_B
POS1/0/0
100.2.1.2/30
GE2/0/0
2003::2/64
GE2/0/0
2003::1/64
PE3
Loopback1
3.3.3.3 /32
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure OSPF on the MPLS backbone network for IP connectivity between PE1, PE2,
and PE3.
2.
Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the
MPLS backbone network.
3.
Configure a VPN instance that supports the IPv6 address family on PE1, PE2, and PE3,
and connect the CE to PE2 and PE3.
4.
Establish an EBGP peer relationship between the CE and PE2, and between the CE and
PE3, import IPv6 VPN routes, and establish MP-IBGP peer relationships between PEs.
5.
Data Preparation
To complete the configuration, you need the following data:
l
Name of the VPN instance configured on each PE and the other attributes of the VPN
instance IPv6 address family such as the RD and VPN target
Procedure
Step 1 Configure IPv4 addresses for interfaces on the backbone network of the VPN and IPv6 addresses
for interfaces at the VPN site. Details for configuration procedures are not provided here.
Step 2 Configure OSPF on the MPLS backbone network for IP connectivity between the PEs on the
backbone network. Details for configuration procedures are not provided here.
Step 3 Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the MPLS
backbone network.
Issue 01 (2011-10-15)
428
# Configure PE1.
<PE1> system-view
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos2/0/0
[~PE1-Pos2/0/0] mpls
[~PE1-Pos2/0/0] mpls ldp
[~PE1-Pos2/0/0] quit
[~PE1] interface pos3/0/0
[~PE1-Pos3/0/0] mpls
[~PE1-Pos3/0/0] mpls ldp
[~PE1-Pos3/0/0] quit
[~PE1] commit
# Configure PE2.
<PE2> system-view
[~PE2] mpls lsr-id 2.2.2.2
[~PE2] mpls
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] quit
[~PE2] interface pos1/0/0
[~PE2-Pos1/0/0] mpls
[~PE2-Pos1/0/0] mpls ldp
[~PE2-Pos1/0/0] quit
[~PE2] commit
# Configure PE3.
<PE3> system-view
[~PE3] mpls lsr-id 3.3.3.3
[~PE3] mpls
[~PE3-mpls] quit
[~PE3] mpls ldp
[~PE3-mpls-ldp] quit
[~PE3] interface pos1/0/0
[~PE3-Pos1/0/0] mpls
[~PE3-Pos1/0/0] mpls ldp
[~PE3-Pos1/0/0] quit
[~PE3] commit
Run the display mpls lsp command on the PEs. You can view that LSPs are set up between PE1
and PE2, and between PE1 and PE3. The following uses the display on PE1 as an example:
[~PE1] display mpls lsp
------------------------------------------------------------------------------LSP Information: LDP LSP
------------------------------------------------------------------------------FEC
In/Out Label In/Out IF
Vrf Name
1.1.1.1/32
3/NULL
-/3.3.3.3/32
NULL/3
-/Pos3/0/0
3.3.3.3/32
1024/3
-/Pos3/0/0
2.2.2.2/32
NULL/3
-/Pos2/0/0
2.2.2.2/32
1025/3
-/Pos2/0/0
Step 4 Configure a VPN instance that supports the IPv6 address family on each PE, and connect the
CE to PE2 and PE3.
# Configure PE1.
[~PE1] ip vpn-instance vpn1
[~PE1-vpn-instance-vpn1] ipv6-family
[~PE1-vpn-instance-vpn1-af-ipv6] route-distinguisher 100:1
[~PE1-vpn-instance-vpn1-af-ipv6] vpn-target 111:1
Issue 01 (2011-10-15)
429
[~PE1-vpn-instance-vpn1-af-ipv6] quit
[~PE1-vpn-instance-vpn1] quit
[~PE1] interface loopback2
[~PE1-Loopback2] ip binding vpn-instance vpn1
[~PE1-Loopback2] ipv6 enable
[~PE1-Loopback2] ipv6 address 1999::128
[~PE1-Loobpack2] quit
[~PE1] commit
# Configure PE2.
[~PE2] ip vpn-instance vpn1
[~PE2-vpn-instance-vpn1] ipv6-family
[~PE2-vpn-instance-vpn1-af-ipv6] route-distinguisher 100:2
[~PE2-vpn-instance-vpn1-af-ipv6] vpn-target 111:1
[~PE2-vpn-instance-vpn1-af-ipv6] quit
[~PE2-vpn-instance-vpn1] quit
[~PE2] interface gigabitethernet2/0/0
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE2-GigabitEthernet2/0/0] ipv6 enable
[~PE2-GigabitEthernet2/0/0] ipv6 address 2001::2 64
[~PE2-GigabitEthernet2/0/0] quit
[~PE2] commit
# Configure PE3.
[~PE3] ip vpn-instance vpn1
[~PE3-vpn-instance-vpn1] ipv6-family
[~PE3-vpn-instance-vpn1-af-ipv6] route-distinguisher 100:3
[~PE3-vpn-instance-vpn1-af-ipv6] vpn-target 111:1
[~PE3-vpn-instance-vpn1-af-ipv6] quit
[~PE3-vpn-instance-vpn1] quit
[~PE3] interface gigabitethernet2/0/0
[~PE3-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE3-GigabitEthernet2/0/0] ipv6 enable
[~PE3-GigabitEthernet2/0/0] ipv6 address 2003::2 64
[~PE3-GigabitEthernet2/0/0] quit
[~PE3] commit
Step 5 Establish an EBGP peer relationship between PE2 and the CE, and between PE3 and the CE.
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] ipv6-family vpn-instance vpn1
[~PE2-bgp6-vpn1] peer 2001::1 as-number 65410
[~PE2-bgp6-vpn1] quit
[~PE2-bgp] quit
[~PE2] commit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] ipv6-family vpn-instance vpn1
[~PE3-bgp6-vpn1] peer 2003::1 as-number 65410
[~PE3-bgp6-vpn1] quit
[~PE3-bgp] quit
[~PE3] commit
Issue 01 (2011-10-15)
430
[~CE-bgp-af-ipv6] quit
[~CE-bgp] quit
[~CE] commit
After the step, run the display bgp vpnv6 all peer command on PE2 and PE3. You can find that
the status of the EBGP peer relationships between the PEs and CE is Established. This means
that the EBGP peer relationships are successfully set up.
The following uses the display on PE2 as an example:
[~PE2] display bgp vpnv6 all peer
BGP local router ID : 2.2.2.2
Local AS number : 100
Total number of peers : 2
Peer
PrefRcv
AS
MsgRcvd
MsgSent
100
27
24
0 00:19:33 Established
10
0 00:08:30 Established
1.1.1.1
OutQ
Up/Down
State
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 1.1.1.1 as-number 100
[~PE2-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE2-bgp] ipv6-family vpnv6
[~PE2-bgp-af-vpnv6] peer 1.1.1.1 enable
[~PE2-bgp-af-vpnv6] quit
[~PE2-bgp] quit
[~PE2-bgp] commit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] peer 1.1.1.1 as-number 100
[~PE3-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE3-bgp] ipv6-family vpnv6
[~PE3-bgp-af-vpnv6] peer 1.1.1.1 enable
[~PE3-bgp-af-vpnv6] quit
[~PE3-bgp] quit
[~PE3] commit
After the step, run the display bgp vpnv6 all peer command on the PEs. You can find that the
status of the MP-IBGP peer relationship between the PEs is Established. This means that the
MP-IBGP peer relationships are successfully set up.
The following uses the display on PE1 as an example:
Issue 01 (2011-10-15)
431
MsgSent
17
19
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
:
:
:
:
:
:
:
:
:
128
255
0
BGP
0
0x80024904
0
31sec
Flags
BkInterface
BkTunnelID
BkIndirectID
: RD
:
: 0x0
: 0x6
----End
Configuration Files
l
Issue 01 (2011-10-15)
432
Issue 01 (2011-10-15)
433
undo shutdown
ipv6 enable
ip binding vpn-instance vpn1
ipv6 address 2001::2/64
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
bgp 100
peer 1.1.1.1 as-number 100
peer 1.1.1.1 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.1 enable
#
ipv6-family vpn-instance vpn1
peer 2001::1 as-number 65410
import-route direct
#
ospf 1
area 0.0.0.0
network 100.1.1.0 0.0.0.3
network 2.2.2.2 0.0.0.0
#
return
Issue 01 (2011-10-15)
434
#
ipv6-family vpnv6
policy vpn-target
peer 1.1.1.1 enable
#
ipv6-family vpn-instance vpn1
peer 2003::1 as-number 65410
#
ospf 1
area 0.0.0.0
network 100.2.1.0 0.0.0.3
network 3.3.3.3 0.0.0.0
#
Return
Issue 01 (2011-10-15)
435
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
At a VPN site, different CEs use BGP to access the same PE. The PE learns multiple IPv6 VPN
routes with the same VPN prefix from the CEs. To enable the system to select a primary route
and a backup route, you can deploy FRR for IPv6 routes on the private network. If this feature
is configured, the PE generates a primary route and a backup route to the same destination on
the private network. After that, IPv6 traffic can be quickly switched to the link where the backup
route resides in case the link where the primary route resides is faulty.
As shown in Figure 3-15, an EBGP peer relationship is set up between the PE and each CE.
There are two BGP routes from the PE to Loopback 1 on Router A. The optimal route resides
on Link_A; the sub-optimal route resides on Link_B. It is required that IPv6 Auto FRR be
deployed on the PE so that if Link_A fails, IPv6 traffic can be quickly switched to Link_B.
Figure 3-15 Configuring IPv6 Auto FRR for the private network
vpn1
site
CE1
GE1/0/0
2000::1/64
VPN
backbone
GE1/0/0
2000::2/64
PE
GE2/0/0
2001::1/64
GE2/0/0
2002::1/64
Loopback 1
GE1/0/0
2002::2/64 2004::1/128
Link_A
RouterA
Link_B
GE1/0/0
2001::2/64
GE2/0/0
GE2/0/02003::2/64
2003::1/64
CE2
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure an IGP at the VPN site to advertise the routes of Loopback 1 on Router A to
CE1 and CE2.
2.
Create a VPN instance named vpna that supports the IPv6 address family on the PE, and
bind GE 1/0/0 and GE 2/0/0 to vpna.
3.
Establish an EBGP peer relationship between the PE and CE1, and between the PE and
CE2. On CE1 and CE2, configure an IGP and BGP to import routes from each other.
Issue 01 (2011-10-15)
436
4.
Enable IPv6 Auto FRR for the private network on the PE.
Data Preparation
To complete the configuration, you need the following data:
l
VPN instance name (vpna) and attributes of the VPN instance IPv6 address family, for
example, the RD (100:1) and VPN target (100:100), on the PE
MEDs configured for the IGP routes imported into BGP on CE1 and CE2
Procedure
Step 1 Configure IPv6 addresses for the interfaces on the routers at the VPN site.
For details on the configuration procedure, see the following configuration files.
Step 2 Configure an IGP at the VPN site to advertise the route of Loopback 1 on Router A to CE1 and
CE2. In this example, OSPFv3 is configured as an IGP.
# Configure CE1.
[~CE1] ospfv3 1
[~CE1-ospfv3-1] router-id 2.2.2.2
[~CE1-ospfv3-1] quit
[~CE1] interface gigaethernet 2/0/0
[~CE1-GigabitEthernet2/0/0] ospfv3 1 area 0.0.0.0
[~CE1-GigabitEthernet2/0/0] quit
[~CE1] commit
The configurations of CE2 and Router A are similar to the configuration of CE1. For details on
the configuration procedure, see the following configuration files.
After the configuration is complete, run the display ipv6 routing-table command on the CEs,
and you can find that CE1 and CE2 have learned the route of Loopback 1 on Router A. The
following takes the display on CE1 as an example:
<CE1> display ipv6 routing-table
Routing Table : _public_
Destinations : 8
Routes : 8
Issue 01 (2011-10-15)
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2000::
2000::2
0
::
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2000::2
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::
2002::1
0
::
GigabitEthernet2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
437
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2003::
FE80::5451:0:FAC1:1
3124
::
GigabitEthernet2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
10
OSPFv3
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2004::1
FE80::5451:0:FAC1:1
1562
::
GigabitEthernet2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
10
OSPFv3
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
FE80::
::
0
::
NULL0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
10
0
Direct
0x0
D
Step 3 Configure a VPN instance that supports the IPv6 address family on the PE and bind the interfaces
connecting the PE to the CEs to the VPN instance.
# Configure a VPN instance named vpna on the PE, and bind GE 1/0/0 and GE 2/0/0 to the
instance.
<PE> system-view
[~PE] ip vpn-instance vpna
[~PE-vpn-instance-vpna] ipv6-family
[~PE-vpn-instance-vpna-af-ipv6] route-distinguisher 100:1
[~PE-vpn-instance-vpna-af-ipv6] vpn-target 100:100
[~PE-vpn-instance-vpna-af-ipv6] quit
[~PE-vpn-instance-vpna] quit
[~PE] interface gigabitethernet 1/0/0
[~PE-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[~PE-GigabitEthernet1/0/0] ipv6 enable
[~PE-GigabitEthernet1/0/0] ipv6 address 2000::1 64
[~PE-GigabitEthernet1/0/0] quit
[~PE] interface gigabitethernet 2/0/0
[~PE-GigabitEthernet2/0/0] ip binding vpn-instance vpna
[~PE-GigabitEthernet2/0/0] ipv6 enable
[~PE-GigabitEthernet2/0/0] ipv6 address 2001::1 64
[~PE-GigabitEthernet2/0/0] quit
[~PE] commit
# Configure CE1.
[~CE1] bgp 65410
[~CE1-bgp] peer 2000::1 as-number 100
[~CE1-bgp] ipv6-family unicast
[~CE1-bgp-af-ipv6] peer 2000::1 enable
[~CE1-bgp-af-ipv6] quit
[~CE1-bgp] quit
Issue 01 (2011-10-15)
438
[~CE1] commit
The configuration of CE2 is similar to the configuration of CE1. For details on the configuration
of CE2, see the following configuration fils.
After the configuration is complete, run the display bgp vpnv6 vpn-instance vpna peer
command on the PE, and you can find that the status of the EBGP peer relationship between the
PE and CEs is Established. It indicates that the EBGP peer relationships have been set up
between the PE and CEs.
<PE> display bgp vpnv6 vpn-instancee vpna peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 2
Peer
PrefRcv
2000::2
2001::2
AS
MsgRcvd
MsgSent
4
4
65410
65410
35
41
37
43
OutQ
Up/Down
State
0 00:24:31 Established
0 00:24:03 Established
3
3
Step 5 Configure route exchange between OSPFv3 and BGP on the CEs.
Configure OSPFv3 routes on the CEs and import them into BGP. To make the PE select the
route along Link_A as the optimal route, ensure that the MED configured for the OSPFv3 routes
imported into BGP on CE1 is smaller than that configured on CE2.
# Configure CE1.
[~CE1] bgp 100
[~CE1-bgp] ipv6-family unicast
[~CE1-bgp-af-ipv6] import-route ospfv3 1 med 100
[~CE1-bgp-af-ipv6] quit
[~CE1-bgp] quit
[~CE1] commit
# Configure CE2.
[~CE2] bgp 100
[~CE2-bgp] ipv6-family unicast
[~CE2-bgp-af-ipv6] import-route ospfv3 1 med 500
[~CE2-bgp-af-ipv6] quit
[~CE2-bgp] quit
[~CE2] commit
After the configuration is complete, run the display ipv6 routing-table vpn-instance command
on the PE, and you can find the route to Loopback 1 on Router A in the command output.
<PE> display ipv6 routing-table vpn-instance vpna
Routing Table : vpna
Destinations : 8
Routes : 8
Issue 01 (2011-10-15)
439
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2000::
2000::1
0
::
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2000::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::
2001::1
0
::
GigabitEthernet2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::1
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::
2000::2
100
::
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2003::
2001::2
0
::
GigabitEthernet2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2004::1
2000::2
100
::
GigabitEthernet1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
255
BGP
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
FE80::
::
0
::
NULL0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
10
0
Direct
0x0
D
Step 6 Enable IPv6 Auto FRR for the private network on the PE.
# Configure the PE.
[~PE] bgp 100
[~PE-bgp] ipv6-family vpn-instance vpna
[~PE-bgp6-vpna] auto-frr
[~PE-bgp6-vpna] quit
[~PE-bgp] quit
[~PE-bgp] commit
NOTE
The auto-frr command run in the BGP-VPN instance IPv6 address family view is valid only for BGP routes.
Issue 01 (2011-10-15)
440
Summary Count : 1
Destination : 2004::1
NextHop
: 2000::2
Neighbour
: 2000::2
Label
: NULL
State
: Active Adv
Entry ID
: 27
Reference Cnt: 2
IndirectID
: 0x6
RelayNextHop : ::
Interface
: GigabitEthernet1/0/0
BkNextHop
: 2001::2
GigabitEthernet2/0/0
BkLabel
: NULL
BkPETunnelID : 0x0
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
Flags
BkInterface
:
:
:
:
:
:
:
:
:
:
:
128
255
0
BGP
100
0x80004100
0
3sec
0x0
D
BkTunnelID
: 0x0
BkIndirectID : 0x5
Disable IPv6 on GE 2/0/0 on CE1 so that IPv6 routes cannot be transmitted over Link_A.
[~CE1] interface Gigabitethernet2/0/0
[~CE1-GigabitEthernet2/0/0] undo ipv6 enable
[~CE1-GigabitEthernet2/0/0] quit
[~CE1] commit
Run the display ipv6 routing-table vpn-instance command again on the PE. You can find that
the next hop to 2004::1/128 is 2001::2, and the PE does not have a backup next hop or a backup
outbound interface.
<PE> display ipv6 routing-table vpn-instance vpna 2004::1 verbose
Routing Table : vpna
Summary Count : 1
Destination :
NextHop
:
Neighbour
:
Label
:
State
:
Entry ID
:
Reference Cnt:
IndirectID
:
RelayNextHop :
Interface
:
2004::1
2001::2
2001::2
NULL
Active Adv
27
2
0x6
::
GigabitEthernet2/0/0
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
Flags
:
:
:
:
:
:
:
:
:
:
128
255
0
BGP
500
0x80004100
0
3sec
0x0
D
IPv6 Auto FRR configured for routes on the private network has taken effect.
----End
Configuration Files
l
Issue 01 (2011-10-15)
441
ipv6 enable
ipv6 address 2001::1/64
#
bgp 100
#
ipv4-family unicast
undo synchronization
#
ipv6-family vpnv6
policy vpn-target
#
ipv6-family vpn-instancee vpna
auto-frr
peer 2000::2 as-number 65410
peer 2001::2 as-number 65410
#
return
Issue 01 (2011-10-15)
442
3.14.9 Example for Configuring Hybrid FRR for IPv6 and VPNv6
Routes
In a network where a CE is dual-homed to two PEs, hybrid FRR can be configured on PEs to
protect the link between either PE and the CE. If the link between one of the PEs and the CE
fails, traffic destined for the CE can be switched to the other PE to reach the CE.
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
Issue 01 (2011-10-15)
443
A CE at an IPv6 VPN site is dual-homed to two PEs, and a VPNv6 peer relationship is set up
between the two PEs. To protect a link between the CE and one of the PEs, hybrid FRR for IPv6
and VPNv6 routes can be configured.
If the link fails, hybrid FRR can quickly switch traffic destined for the CE to the backup next
hop (a PE).
NOTE
Hybrid FRR for IPv6 and VPNv6 routes is applicable to only the networking where CEs establish BGP
peer relationships with PEs.
As shown in Figure 3-16, a CE is connected to PE2 and PE3; an MPLS public network tunnel
and a VPNv6 peer relationship are set up between PE2 and PE3. PE2 and PE3 use EBGP to
exchange routing information with the CE. PE3 learns from the CE a route to the interface
Loopback 1 on the CE and sends the route to its VPNv6 peer. As a result, PE2 has two BGP
routes to Loopback 1 on the CE: One is sent from the CE by using EBGP, and the other is sent
from PE3 by using MP-IBGP.
It is required that PE2 be configured to preferably select the EBGP route sent from the CE for
data forwarding and use the VPNv6 route sent from PE3 as a backup route. If the link between
PE2 and the CE fails, the link traffic can be switched to PE3 that serves as the backup next hop.
Figure 3-16 Networking diagram for configuring hybrid FRR for IPv6 and VPNv6 routes
VPNbackbone
Loopback1
2.2.2.2 /32
PE2
100.2.1.1/30
Loopback1
200:0:1:2::1/128
GE2/0/0
2001::2/64
Loopback1
POS1/0/0
1.1.1.1/32 AS100
100.1.1.2/30
POS2/0/0
100.1.1.1/30
POS3/0/0
110.1.1.1/30
PE1
POS3/0/0
110.1.1.2/30
POS3/0/0
GE1/0/0
2001::1/64
AS65410
CE
GE2/0/0
2003::2/64
POS1/0/0
100.2.1.2/30
GE2/0/0
2003::1/64
vpn1 site
PE3
Loopback1
3.3.3.3 /32
Configuration Roadmap
The configuration roadmap is as follows:
1.
Configure OSPF on the MPLS backbone network for IP connectivity between PE1, PE2,
and PE3.
2.
Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the
MPLS backbone network.
3.
4.
Configure a VPN instance that supports the IPv6 address family on each PE, and connect
the CE to PE2 and PE3.
5.
Establish an EBGP peer relationship between PE2 and the CE, and between PE3 and the
CE, and import the route of the loopback interface into BGP on the CE.
Issue 01 (2011-10-15)
444
6.
Configure Auto FRR for the BGP VPN instance IPv6 address family on PE2 so that the
VPNv6 route sent from PE3 can serve as a backup route.
Procedure
Step 1 Configure IPv4 addresses for interfaces on the backbone network of the VPN and IPv6 addresses
for interfaces at the VPN site. Details for configuration procedures are not provided here.
Step 2 Configure OSPF on the MPLS backbone network for IP connectivity between the PEs on the
backbone network. Details for configuration procedures are not provided here.
Step 3 Configure basic MPLS functions, enable MPLS LDP, and establish LDP LSPs on the MPLS
backbone network.
# Configure PE1.
<PE1> system-view
[~PE1] mpls lsr-id 1.1.1.1
[~PE1] mpls
[~PE1-mpls] quit
[~PE1] mpls ldp
[~PE1-mpls-ldp] quit
[~PE1] interface pos2/0/0
[~PE1-Pos2/0/0] mpls
[~PE1-Pos2/0/0] mpls ldp
[~PE1-Pos2/0/0] quit
[~PE1] interface pos3/0/0
[~PE1-Pos3/0/0] mpls
[~PE1-Pos3/0/0] mpls ldp
[~PE1-Pos3/0/0] quit
[~PE1] commit
# Configure PE2.
<PE2> system-view
[~PE2] mpls lsr-id 2.2.2.2
[~PE2] mpls
[~PE2-mpls] quit
[~PE2] mpls ldp
[~PE2-mpls-ldp] quit
[~PE2] interface pos1/0/0
[~PE2-Pos1/0/0] mpls
[~PE2-Pos1/0/0] mpls ldp
[~PE2-Pos1/0/0] quit
[~PE2] interface pos3/0/0
[~PE2-Pos3/0/0] mpls
[~PE2-Pos3/0/0] mpls ldp
[~PE2-Pos3/0/0] quit
[~PE2] commit
# Configure PE3.
<PE3> system-view
[~PE3] mpls lsr-id 3.3.3.3
[~PE3] mpls
[~PE3-mpls] quit
[~PE3] mpls ldp
[~PE3-mpls-ldp] quit
[~PE3] interface pos1/0/0
[~PE3-Pos1/0/0] mpls
[~PE3-Pos1/0/0] mpls ldp
[~PE3-Pos1/0/0] quit
[~PE3] interface pos3/0/0
[~PE3-Pos3/0/0] mpls
[~PE3-Pos3/0/0] mpls ldp
[~PE3-Pos3/0/0] quit
[~PE3] commit
Issue 01 (2011-10-15)
445
Run the display mpls lsp command on the PEs. You can view that LSPs are set up between PE1
and PE2, and between PE1 and PE3. The following uses the display on PE1 as an example:
[~PE1] display mpls lsp
---------------------------------------------------------------------LSP Information: LDP LSP
---------------------------------------------------------------------FEC
In/Out Label In/Out IF
Vrf Name
2.2.2.2/32
NULL/3
-/Pos2/0/0
2.2.2.2/32
1024/3
-/Pos2/0/0
3.3.3.3/32
NULL/3
-/Pos3/0/0
3.3.3.3/32
1025/3
-/Pos3/0/0
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] peer 1.1.1.1 as-number 100
[~PE2-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE2-bgp] peer 3.3.3.3 as-number 100
[~PE2-bgp] peer 3.3.3.3 connect-interface loopback 1
[~PE2-bgp] ipv6-family vpnv6
[~PE2-bgp-af-vpnv6] peer 1.1.1.1 enable
[~PE2-bgp-af-vpnv6] peer 3.3.3.3 enable
[~PE2-bgp-af-vpnv6] quit
[~PE2-bgp] quit
[~PE2] commit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] peer 1.1.1.1 as-number 100
[~PE3-bgp] peer 1.1.1.1 connect-interface loopback 1
[~PE3-bgp] peer 2.2.2.2 as-number 100
[~PE3-bgp] peer 2.2.2.2 connect-interface loopback 1
[~PE3-bgp] ipv6-family vpnv6
[~PE3-bgp-af-vpnv6] peer 1.1.1.1 enable
[~PE3-bgp-af-vpnv6] peer 2.2.2.2 enable
[~PE3-bgp-af-vpnv6] quit
[~PE3-bgp] quit
[~PE3] commit
After the step, run the display bgp vpnv6 all peer command on the PEs. You can find that the
status of the MP-IBGP peer relationship between the PEs is Established. This means that the
MP-IBGP peer relationships are successfully set up.
The following uses the display on PE1 as an example:
[~PE1] display bgp vpnv6 all peer
BGP local router ID : 1.1.1.1
Local AS number : 100
Total number of peers : 2
Peer
V
AS MsgRcvd MsgSent
2.2.2.2
4
100
20
17
Issue 01 (2011-10-15)
446
24
19
0 00:17:18 Established
Step 5 Configure a VPN instance that supports the IPv6 address family on each PE, and connect the
CE to PE2 and PE3.
# Configure PE1.
[~PE1] ip vpn-instance vpn1
[~PE1-vpn-instance-vpn1] ipv6-family
[~PE1-vpn-instance-vpn1-af-ipv6] route-distinguisher 100:1
[~PE1-vpn-instance-vpn1-af-ipv6] vpn-target 111:1
[~PE1-vpn-instance-vpn1-af-ipv6] quit
[~PE1-vpn-instance-vpn1] quit
[~PE1] commit
# Configure PE2.
[~PE2] ip vpn-instance vpn1
[~PE2-vpn-instance-vpn1] ipv6-family
[~PE2-vpn-instance-vpn1-af-ipv6] route-distinguisher 100:2
[~PE2-vpn-instance-vpn1-af-ipv6] vpn-target 111:1
[~PE2-vpn-instance-vpn1-af-ipv6] quit
[~PE2-vpn-instance-vpn1] quit
[~PE2] interface gigabitethernet2/0/0
[~PE2-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE2-GigabitEthernet2/0/0] ipv6 enable
[~PE2-GigabitEthernet2/0/0] ipv6 address 2001::2 64
[~PE2-GigabitEthernet2/0/0] quit
[~PE2] commit
# Configure PE3.
[~PE3] ip vpn-instance vpn1
[~PE3-vpn-instance-vpn1] ipv6-family
[~PE3-vpn-instance-vpn1-af-ipv6] route-distinguisher 100:3
[~PE3-vpn-instance-vpn1-af-ipv6] vpn-target 111:1
[~PE3-vpn-instance-vpn1-af-ipv6] quit
[~PE3-vpn-instance-vpn1] quit
[~PE3] interface gigabitethernet2/0/0
[~PE3-GigabitEthernet2/0/0] ip binding vpn-instance vpn1
[~PE3-GigabitEthernet2/0/0] ipv6 enable
[~PE3-GigabitEthernet2/0/0] ipv6 address 2003::2 64
[~PE3-GigabitEthernet2/0/0] quit
[~PE3] commit
Step 6 Establish an EBGP peer relationship between PE2 and the CE, and between PE3 and the CE,
and import the route of the loopback interface into BGP on the CE.
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] ipv6-family vpn-instance vpn1
[~PE2-bgp6-vpn1] peer 2001::1 as-number 65410
[~PE2-bgp6-vpn1] quit
[~PE2-bgp] quit
[~PE2] commit
# Configure PE3.
[~PE3] bgp 100
[~PE3-bgp] ipv6-family vpn-instance vpn1
[~PE3-bgp6-vpn1] peer 2003::1 as-number 65410
[~PE3-bgp6-vpn1] quit
[~PE3-bgp] quit
[~PE3] commit
Issue 01 (2011-10-15)
447
After the configuration is complete, run the display ipv6 routing-table vpn-instance command
on PE2, and you can find the route to Loopback 1 on the CE in the command output.
<PE2> display ipv6 routing-table vpn-instance vpn1 200:0:1:2::1 128
Routing Table : vpn1
Summary Count : 1
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
200:0:1:2::1
2001::1
0
2001::1
GigabitEthernet2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
255
BGP
0x0
RD
Step 7 Configure VPNv6 Auto FRR on PE2, and adjust the precedence of EBGP routes to make PE2
select an EBGP route preferably.
# Configure PE2.
[~PE2] bgp 100
[~PE2-bgp] ipv6-family vpn-instance vpn1
[~PE2-bgp6-vpn1] preference 100 255 255
[~PE2-bgp6-vpn1] auto-frr
[~PE2-bgp6-vpn1] quit
[~PE2-bgp] quit
[~PE2] commit
200:0:1:2::1
2001::1
::
NULL
Active Adv Relied
14
0
0x8a9
2001::1
GigabitEthernet2/0/0
::
17
0x0000000001004c4b44
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
Flags
BkInterface
BkTunnelID
BkIndirectID
:
:
:
:
:
:
:
:
:
:
:
:
:
128
100
0
BGP
0
0x00000000
0
3sec
0x0
RD
LDP LSP
0x0
0xae
Run the shutdown command and then the display ipv6 routing-table vpn-instance verbose
command on GE 2/0/0 on PE2. You can find that the next hop to the loopback interface on the
CE is changed to PE3.
Issue 01 (2011-10-15)
448
PrefixLength
Preference
ProcessID
Protocol
Cost
EntryFlags
Tag
Age
TunnelID
:
:
:
:
:
:
:
:
:
128
255
0
BGP
0
0x00000000
0
9sec
Flags
: RD
Hybrid FRR for IPv6 and VPNv6 routes has taken effect.
----End
Configuration Files
l
Issue 01 (2011-10-15)
449
Issue 01 (2011-10-15)
450
Issue 01 (2011-10-15)
451
Networking Requirements
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
Issue 01 (2011-10-15)
452
On the backbone network of an IPv6 VPN where a lot of VPNv6 peer relationships need to be
set up, a P or PE can be configured as the RR, and therefore other PEs only need to set up a
VPNv6 peer relationship with the RR. This reduces configurations of VPNv6 peer relationships
between PEs as well as the stress on PEs.
NOTE
To enhance the reliability of an RR-deployed network, two RRs can be configured for mutual backup.
As shown in Figure 3-17, PE1, PE2, and RR1 reside in AS 100, the backbone network; CE1
and CE2 belong to vpna. It is required that RR1 be configured as an RR for the IPv6 VPN.
Figure 3-17 Networking diagram for configuring an RR in an IPv6 VPN
AS100
Loopback1
2.2.2.9/32
POS1/0/0
100.1.2.2/24
RR1
POS1/0/0
100.1.2.1/24
Loopback1
1.1.1.9/32
POS2/0/0
100.2.3.1/24
PE1
POS2/0/0
2001::2/64
POS1/0/0
2001::1/64
POS1/0/0
100.2.3.2/24
Loopback1
3.3.3.9/32
PE2
POS2/0/0
2002::2/64
POS1/0/0
2002::1/64
CE1
AS65410
CE2
AS65420
Configuration Roadmap
The configuration roadmap is as follows:
1.
Set up an MP-IBGP connection between each PE and the RR. There is no need to set up
an MP-IBGP peer relationship between the PEs.
2.
3.
Establish LDP LSPs between the PEs and RR on the backbone network.
4.
Configure the RR to receive all VPNv6 routing information without filtering the
information by VPN targets.
Data Preparation
To complete the configuration, you need the following data:
l
Issue 01 (2011-10-15)
453
Name of the VPN instance created on PE1 and PE2, and the RD and VPN target of the
VPN instance IPv6 address family
Routing protocol running between the PEs and CE for route exchange (EBGP in this
configuration example)
Procedure
Step 1 Configure an IP address for each interface. For details on the configuration procedures, see the
following configuration files.
Step 2 Configure an IGP on the MPLS backbone network so that devices on the backbone network can
learn the route to one another's loopback interface.
OSPF is used as the IGP in this example. Details for the configuration procedures are not
provided here.
After the configuration is complete, run the display ip routing-table command on each device
on the backbone network. You can find that the devices have learned the route to one another's
loopback interface.
The following uses the display on PE1 as an example:
<PE1> display ip routing-table
Route Flags: R - relay, D - download for forwarding
-----------------------------------------------------------------------------Routing Tables: _public_
Destinations : 9
Routes : 9
Destination/Mask
Proto Pre Cost
Flags NextHop
Interface
1.1.1.9/32 Direct 0
0
D 127.0.0.1
InLoopBack0
2.2.2.9/32 OSPF
10
1
D 100.1.2.2
Pos1/0/0
3.3.3.9/32 OSPF
10
3
D 100.1.2.2
Pos1/0/0
100.1.2.0/24 Direct 0
0
D 100.1.2.1
Pos1/0/0
100.1.2.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
100.1.2.2/32 Direct 0
0
D 100.1.2.2
Pos1/0/0
100.2.3.0/24 OSPF
10
2
D 100.1.2.2
Pos1/0/0
127.0.0.0/8
Direct 0
0
D 127.0.0.1
InLoopBack0
127.0.0.1/32 Direct 0
0
D 127.0.0.1
InLoopBack0
Step 3 Enable MPLS and MPLS LDP globally and on the interfaces of the PEs and RR1, and set up
LDP LSPs between the PEs and RR1.
Enable MPLS and MPLS LDP globally and on the interfaces of PE1, RR1, and PE2. For details
on the configuration procedures, see the following configuration files.
After the configuration is complete, run the display mpls ldp session command on each PE and
RR1. You can view that the session state is displayed as "Operational", which means that the
LDP peer relationship is successfully set up.
The following uses the display on RR1 as an example:
<RR1> display mpls ldp session
LDP Session(s) in Public Network
Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM)
A '*' before a session means the session is being deleted.
---------------------------------------------------------------------PeerID
Status
LAM SsnRole SsnAge
KASent/Rcv
---------------------------------------------------------------------1.1.1.9:0
Operational DU
Active
0000:00:02 11/11
3.3.3.9:0
Operational DU
Passive 0000:00:01 8/8
---------------------------------------------------------------------TOTAL: 2 session(s) Found.
454
For details on the configuration procedures, see Example for Configuring Basic BGP/MPLS
IPv6 VPN.
Step 5 Establish EBGP peer relationships between the PEs and the CEs to import VPN routes.
For details on the configuration procedures, see Example for Configuring Basic BGP/MPLS
IPv6 VPN.
After the configuration is complete, run the display bgp vpnv6 vpn-instance peer command
on each PE. You can find that the status of EBGP peer relationships between the PEs and the
CEs is Established.
The following uses the display on PE1 as an example:
<PE1> display bgp vpnv6 vpn-instance vpna peer
BGP local router ID : 1.1.1.9
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer
PrefRcv
2001::1
AS
MsgRcvd
MsgSent
65410
1385
1392
OutQ
Up/Down
State
0 17:39:46 Established
# Configure RR1.
<RR1> system-view
[~RR1] bgp 100
[~RR1-bgp] peer 1.1.1.9 as-number 100
[~RR1-bgp] peer 1.1.1.9 connect-interface loopback 1
[~RR1-bgp] peer 3.3.3.9 as-number 100
[~RR1-bgp] peer 3.3.3.9 connect-interface loopback 1
[~RR1-bgp] ipv6-family vpnv6
[~RR1-bgp-af-vpnv6] peer 1.1.1.9 enable
[~RR1-bgp-af-vpnv6] peer 3.3.3.9 enable
[~RR1-bgp-af-vpnv6] quit
[~RR1-bgp] quit
[~RR1] commit
The configuration of PE2 is similar to the configuration of PE1. For details on the configuration
procedure for PE2, see the following configuration files.
After the configuration is complete, run the display bgp vpnv6 all peer command on PEs or
RR1. You can find that the status of the EBGP peer relationships between the PEs and RR1 is
Established.
The following uses the display on RR1 as an example:
<RR1> display bgp vpnv6 all peer
BGP local router ID : 2.2.2.9
Local AS number : 100
Total number of peers : 2
Issue 01 (2011-10-15)
455
Peer
PrefRcv
1.1.1.9
3.3.3.9
AS
MsgRcvd
MsgSent
4
4
100
100
1263
1170
1530
1109
OutQ
Up/Down
State
0 19:46:01 Established
0 17:50:26 Established
1
1
:
:
:
:
:
2001::
2001::2
0
::
Pos2/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2001::2
::1
0
::
InLoopBack0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
128
0
Direct
0x0
D
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
2002::
::FFFF:2.2.2.9
0
::FFFF:100.1.2.2
Pos1/0/0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
64
255
BGP
0xa0010080
RD
Destination
NextHop
Cost
RelayNextHop
Interface
:
:
:
:
:
FE80::
::
0
::
NULL0
PrefixLength
Preference
Protocol
TunnelID
Flags
:
:
:
:
:
10
0
Direct
0x0
D
CE1 and CE2 can successfully ping each other even though no VPNv6 peer relationship is
configured between PE1 and PE2. This indicates that the RR is successfully configured.
----End
Configuration Files
l
Issue 01 (2011-10-15)
456
#
sysname PE1
#
ip vpn-instance vpna
ipv6-family
route-distinguisher 100:1
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
#
mpls lsr-id 1.1.1.9
#
mpls
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 100.1.2.1 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ipv6 enable
ip binding vpn-instance vpna
ipv6 address 2001::2/64
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
peer 2.2.2.9 as-number 100
peer 2.2.2.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 2.2.2.9 enable
#
ipv6-family vpnv6
policy vpn-target
peer 2.2.2.9 enable
#
ipv6-family vpn-instance vpna
peer 2001::1 as-number 65410
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 100.1.2.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
457
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 100.2.3.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
peer 1.1.1.9 as-number 100
peer 1.1.1.9 connect-interface LoopBack1
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv6-family vpnv6
reflector cluster-id 100
undo policy vpn-target
peer 1.1.1.9 enable
peer 1.1.1.9 reflect-client
peer 1.1.1.9 next-hop-local
peer 3.3.3.9 enable
peer 3.3.3.9 reflect-client
peer 3.3.3.9 next-hop-local
#
ospf 1
area 0.0.0.0
network 100.1.2.0 0.0.0.255
network 100.2.3.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return
Issue 01 (2011-10-15)
458
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
peer 2.2.2.9 as-number 100
peer 2.2.2.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 2.2.2.9 enable
#
ipv6-family vpnv6
policy vpn-target
peer 2.2.2.9 enable
#
ipv6-family vpn-instance vpna
peer 2002::1 as-number 65420
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 100.2.3.0 0.0.0.255
#
return
Issue 01 (2011-10-15)
459