June 9, 2015 at 13:13Configuring VPLS Multihoming on Juniper Routers
- Tutorial
VPLS technology has long established itself as a way of combining geographically dispersed objects into a single L2 network. This solution scales well compared to the classic L2 network and eliminates the problems of L2 loops in the network core. However, often there is a need to organize backup channels from the subscriber to the VPLS cloud. In such a situation, there is a risk of hinging in the PE-CE section. There are several approaches to solving this problem. Here is some of them:
In this article, I would like to consider the first two approaches.
Transport Setup
BGP-Based VPLS Multihoming
Bundle of VPLS and STP
Conclusions
Materials used in writing the article
The main goal of this article is to present the working configuration of a fairly comprehensive solution. When writing, I did not set myself the goal of going deep into theory and explaining the intricacies of the work of various protocols that will be discussed. It is understood that the reader is well acquainted with the operation of MPLS, BGP, and Spanning-tree protocols.
Below is the topology that I will use in this article.
The provider's network consists of PE and P routers (Juniper MX), all of which are located in OSPF Area 0 and BGP AS 65412. The subscriber network consists of three switches (Cisco Catalyst), each of which has a Vlan 10 and RPVST version of the Spanning tree protocol (VSTP in Juniper terminology).
Before you begin configuring VPLS, you need to raise the MPLS transport. In this example, RSVP is used for LSP signaling. For brevity, I present the configurations of only two routers, the rest are easy to configure by analogy.
The flexible-vlan-tagging and flexible-ethernet-sevices parameters allow you to configure not only VPLS, but also other services on the physical interface using different logical units. If you plan to use the interface only under VPLS, then you should specify encapsulation ethernet-vpls or vlan-vpls. More details here .
Check that MPLS is up and running:
Now you can go directly to the VPLS service settings.
First of all, I would like to consider the "classical", from the point of view of Juniper, implementation of VPLS using BGP signaling ( RFC 4761 ). From the point of view of the control plane, this is not much different from the usual L3VPN - Route Distinguisher and Route Target are also used here, and l2vpn is specified as the address family.
First you need to configure the BGP protocol itself. Since iBGP requires full connectivity within the network for correct operation, I used P1 and P2 as a route-reflector to simplify the configuration.
PE routers:
P1
P2
Here it is worth noting the routing-options block . When a route-reflector receives a route from its client, before announcing it to other clients, it checks the availability of next-hop in the inet table. 3. Since during the initial configuration of MPLS on P-routers, I did not create LSPs before PE-routers, this table is empty and, accordingly, the check does not work. Routes received from RR clients are marked as hidden and are not announced further. Of course, you can create LSPs from RR to each PE, but this is time-consuming, moreover, these LSPs will never be used to transfer traffic. Creating a static route to the lo0 network is much easier and more elegant.
At the moment, BGP connectivity should work between all PE routers, but so far they have nothing to announce. You can proceed to configure VPLS.
PE1
PE2
Everything is quite simple here: create a routing-instance with the vpls type, assign RD and RT, point the interfaces towards CE and a unique site-identifier.
We check:
VPLS connections have risen. You can check the connectivity of CE1 and CE2:
As you can see from the topology, the CE3 switch is connected simultaneously with two PE routers. Here, to avoid the occurrence of L2-loops, it is necessary to use the Multihoming mechanism . Consider the settings for PE3 and PE4.
PE3
PE4
Unlike previous configurations PE1 and PE2, two parameters are added here:
In this case, the same site-identifier is indicated on both PEs. Thus, PE3 and PE4 announce the same l2vpn route, which differs only in the site-preference parameter. The route with the highest site-preference, i.e. the route from PE3 wins and all l2vpn traffic from PE1 and PE2 starts going through PE3. The ge-0/0/0 interface on PE4 does not allow traffic.
It should be noted that on PE4 all VPLS connections are in the LN state - local site not designated. This means that PE4 is not involved in the transmission of VPLS traffic.
If the PE3-CE3 link crashes or PE3 is disconnected from the rest of the network, the router stops announcing the l2vpn route, PE4 starts passing traffic on the ge-0/0/0 interface, and PE1 and PE2 begin to route traffic towards PE4. The channel switching rate in this case depends on the BGP convergence rate.
Now for the fun part. Consider a topology in which CE1 and CE2 are interconnected.
When using BGP-Based Multihoming in such a topology, everything will be fine until the CE1-CE2 link breaks. PE routers do not know about the topology change and, in the case when, for example, PE1 is the main router, traffic to CE2 will continue to go through PE1 and will be discarded.
In order for topology changes in the CE segment to be transferred to the VPLS segment, you must configure the interaction between STP and VPLS.
Below is a bit of a high-level theory of how this should work.
Let's consider a regular situation when all links work.
Suppose the CE1-CE2 link is broken.
In the STP domain:
In the VPLS domain:
When restoring the CE1-CE2 link, the TCN is sent again and the script repeats, with the difference that the PE2-CE2 link is blocked.
Now let's move on to setting up. I note right away that I was able to recreate this behavior only using the LDP protocol for VPLS signaling ( RFC 4762 ), although it is not written anywhere in the official documentation (correct if I am mistaken).
Unlike regular switches, in order to configure STP on MX series routers, you need to create a routing-instance with the layer2-control type.
PE1 and PE3
PE2 and PE4
Checking the operation of STP
STP works as it should - the port towards CE2 is blocked by root protect.
Unlike BGP, when configuring VPLS with LDP signaling, you must manually specify the IP addresses of all PE routers participating in VPLS.
PE1
The key parameter here is mac-flush . Without it, routers will not reset the MAC address table when the topology changes.
On PE2, PE3, PE4, the settings are absolutely identical except for the neighbor strings.
Checking the operation of LDP
LDP connections have risen, look what with VPLS
Here, too, everything is in order. On PE2, the connections are in standby state.
We check that CE3 can ping CE2. Traffic should go through PE3, PE1 and CE1.
We look at the table of MAC addresses on PE3
Here 50: 00: 00: 08: 80: 0a is the Vlan10 interface MAC address on CE2, lsi.1049088 is PW from PE3 to PE1.
Now break the CE1-CE2 link and see what has changed
The PE2 interface towards CE2 has transitioned to the Forwarding state as it should.
Again we ping PE2
We look at the MAC table on PE3
As you can see, MAC CE2 is now on the lsi.1049089 interface, and this is PW before PE2.
As you can see from the article, VPLS Multihoming is not the most trivial task with its pitfalls. Both approaches described by me to the solution of this problem have their advantages and disadvantages and are applicable only in certain situations. The general disadvantage of VPLS Multihoming is the inability to use two uplinks simultaneously. If such functionality is necessary, you should look towards EVPN technology, which is gradually replacing VPLS.
- BGP-Based VPLS Multihoming
- Bundle of VPLS and STP
- MC-LAG
In this article, I would like to consider the first two approaches.
Content
Transport Setup
- Basic setup of PE routers
- Basic P-Router Setup
- Basic configuration of CE switches
BGP-Based VPLS Multihoming
- Configure BGP
- Configure VPLS
- Multihoming Setting
Bundle of VPLS and STP
- Configure STP
- Configure VPLS on LDP
Conclusions
Materials used in writing the article
Disclaimer
The main goal of this article is to present the working configuration of a fairly comprehensive solution. When writing, I did not set myself the goal of going deep into theory and explaining the intricacies of the work of various protocols that will be discussed. It is understood that the reader is well acquainted with the operation of MPLS, BGP, and Spanning-tree protocols.
Transport Setup
Below is the topology that I will use in this article.
The provider's network consists of PE and P routers (Juniper MX), all of which are located in OSPF Area 0 and BGP AS 65412. The subscriber network consists of three switches (Cisco Catalyst), each of which has a Vlan 10 and RPVST version of the Spanning tree protocol (VSTP in Juniper terminology).
Before you begin configuring VPLS, you need to raise the MPLS transport. In this example, RSVP is used for LSP signaling. For brevity, I present the configurations of only two routers, the rest are easy to configure by analogy.
Basic configuration of PE routers using PE1 as an example
PE1 base config
system {
host-name PE1;
}
interfaces {
ge-0/0/0 {
encapsulation flexible-ethernet-services;
flexible-vlan-tagging;
unit 10 {
encapsulation vlan-vpls;
vlan-id 10;
}
}
ge-0/0/1 {
mtu 2000;
unit 0 {
family inet {
address 10.0.11.1/30;
}
family mpls;
}
}
ge-0/0/2 {
mtu 2000;
unit 0 {
family inet {
address 10.0.12.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.1/32;
}
}
}
}
routing-options {
router-id 10.0.0.1;
autonomous-system 65412;
}
protocols {
rsvp {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
mpls {
label-switched-path PE1-PE2 {
to 10.0.0.2;
no-cspf;
}
label-switched-path PE1-PE3 {
to 10.0.0.3;
no-cspf;
}
label-switched-path PE1-PE4 {
to 10.0.0.4;
no-cspf;
}
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
ospf {
area 0.0.0.0 {
interface ge-0/0/1.0 {
interface-type p2p;
}
interface ge-0/0/2.0 {
interface-type p2p;
}
interface lo0.0;
}
}
}
The flexible-vlan-tagging and flexible-ethernet-sevices parameters allow you to configure not only VPLS, but also other services on the physical interface using different logical units. If you plan to use the interface only under VPLS, then you should specify encapsulation ethernet-vpls or vlan-vpls. More details here .
Basic setup of P-routers on the example of P1
P1 base config
system {
host-name P1;
}
interfaces {
ge-0/0/0 {
mtu 2000;
unit 0 {
family inet {
address 10.0.11.2/30;
}
family mpls;
}
}
ge-0/0/1 {
mtu 2000;
unit 0 {
family inet {
address 10.0.13.2/30;
}
family mpls;
}
}
ge-0/0/2 {
mtu 2000;
unit 0 {
family inet {
address 10.0.21.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.11/32;
}
}
}
}
routing-options {
router-id 10.0.0.11;
autonomous-system 65412;
}
protocols {
rsvp {
interface lo0.0;
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
mpls {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0 {
interface-type p2p;
}
interface ge-0/0/1.0 {
interface-type p2p;
}
interface ge-0/0/2.0 {
interface-type p2p;
}
interface lo0.0;
}
}
}
Check that MPLS is up and running:
lab@PE1> traceroute mpls rsvp PE1-PE2
Probe options: retries 3, exp 7
ttl Label Protocol Address Previous Hop Probe Status
1 10.0.12.2 (null) Egress
Path 1 via ge-0/0/2.0 destination 127.0.0.64
lab@PE1> traceroute mpls rsvp PE1-PE3
Probe options: retries 3, exp 7
ttl Label Protocol Address Previous Hop Probe Status
1 299888 RSVP-TE 10.0.11.2 (null) Success
2 3 RSVP-TE 10.0.13.1 10.0.11.2 Egress
Path 1 via ge-0/0/1.0 destination 127.0.0.64
lab@PE1> traceroute mpls rsvp PE1-PE4
Probe options: retries 3, exp 7
ttl Label Protocol Address Previous Hop Probe Status
1 299936 RSVP-TE 10.0.11.2 (null) Success
2 299792 RSVP-TE 10.0.13.1 10.0.11.2 Success
3 3 RSVP-TE 10.0.34.2 10.0.13.1 Egress
Path 1 via ge-0/0/1.0 destination 127.0.0.64
Basic configuration of CE switches
CE1 base config
hostname CE1
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
vlan 10
!
interface GigabitEthernet0/0
switchport trunk allowed vlan 10
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface Vlan10
ip address 192.168.10.1 255.255.255.0
no shutdown
!
CE2 base config
hostname CE2
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
vlan 10
!
interface GigabitEthernet0/0
switchport trunk allowed vlan 10
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface Vlan10
ip address 192.168.10.2 255.255.255.0
no shutdown
!
CE3 base config
hostname CE3
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
vlan 10
!
interface GigabitEthernet0/0
switchport trunk allowed vlan 10
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/1
switchport trunk allowed vlan 10
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface Vlan10
ip address 192.168.10.3 255.255.255.0
no shutdown
!
Now you can go directly to the VPLS service settings.
BGP-Based VPLS Multihoming
First of all, I would like to consider the "classical", from the point of view of Juniper, implementation of VPLS using BGP signaling ( RFC 4761 ). From the point of view of the control plane, this is not much different from the usual L3VPN - Route Distinguisher and Route Target are also used here, and l2vpn is specified as the address family.
First you need to configure the BGP protocol itself. Since iBGP requires full connectivity within the network for correct operation, I used P1 and P2 as a route-reflector to simplify the configuration.
Configure BGP
PE routers:
PE BGP config
where X is the number of the corresponding PE
protocols {
bgp {
group IBGP {
type internal;
local-address 10.0.0.X;
family l2vpn {
signaling;
}
neighbor 10.0.0.11;
neighbor 10.0.0.22;
}
}
}
where X is the number of the corresponding PE
P1
P1 BGP config
routing-options {
rib inet.3 {
static {
route 10.0.0.0/24 discard;
}
}
}
protocols {
bgp {
group IBGP {
type internal;
local-address 10.0.0.11;
family l2vpn {
signaling;
}
cluster 10.0.0.0;
neighbor 10.0.0.1;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
}
}
}
P2
P2 BGP config
routing-options {
rib inet.3 {
static {
route 10.0.0.0/24 discard;
}
}
}
protocols {
bgp {
group IBGP {
type internal;
local-address 10.0.0.22;
family l2vpn {
signaling;
}
cluster 10.0.0.0;
neighbor 10.0.0.1;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
}
}
}
Here it is worth noting the routing-options block . When a route-reflector receives a route from its client, before announcing it to other clients, it checks the availability of next-hop in the inet table. 3. Since during the initial configuration of MPLS on P-routers, I did not create LSPs before PE-routers, this table is empty and, accordingly, the check does not work. Routes received from RR clients are marked as hidden and are not announced further. Of course, you can create LSPs from RR to each PE, but this is time-consuming, moreover, these LSPs will never be used to transfer traffic. Creating a static route to the lo0 network is much easier and more elegant.
At the moment, BGP connectivity should work between all PE routers, but so far they have nothing to announce. You can proceed to configure VPLS.
Configure VPLS
PE1
PE1 BGP VPLS config
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
route-distinguisher 10.0.0.1:1;
vrf-target target:65412:10;
protocols {
vpls {
no-tunnel-services;
site CE1 {
site-identifier 1;
interface ge-0/0/0.10;
}
}
}
}
}
PE2
PE2 BGP VPLS config
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
route-distinguisher 10.0.0.2:1;
vrf-target target:65412:10;
protocols {
vpls {
no-tunnel-services;
site CE2 {
site-identifier 2;
interface ge-0/0/0.10;
}
}
}
}
}
Everything is quite simple here: create a routing-instance with the vpls type, assign RD and RT, point the interfaces towards CE and a unique site-identifier.
We check:
lab@PE1> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up May 30 17:29:28 2015 1
Remote PE: 10.0.0.2, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262145
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 1 remote site 2
lab@PE2> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE2 (2)
connection-site Type St Time last up # Up trans
1 rmt Up May 30 17:29:30 2015 1
Remote PE: 10.0.0.1, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262146
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 2 remote site 1
VPLS connections have risen. You can check the connectivity of CE1 and CE2:
CE1>ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 10/119/207 ms
Multihoming Setting
As you can see from the topology, the CE3 switch is connected simultaneously with two PE routers. Here, to avoid the occurrence of L2-loops, it is necessary to use the Multihoming mechanism . Consider the settings for PE3 and PE4.
PE3
PE3 VPLS config
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
route-distinguisher 10.0.0.3:1;
vrf-target target:65412:10;
protocols {
vpls {
no-tunnel-services;
site CE3 {
site-identifier 3;
multi-homing;
site-preference primary;
interface ge-0/0/0.10;
}
}
}
}
}
PE4
PE4 VPLS config
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
route-distinguisher 10.0.0.4:1;
vrf-target target:65412:10;
protocols {
vpls {
no-tunnel-services;
site CE3 {
site-identifier 3;
multi-homing;
site-preference backup;
interface ge-0/0/0.10;
}
}
}
}
}
Unlike previous configurations PE1 and PE2, two parameters are added here:
- multi-homing - indicates to the router that it is connected to a multihomed site;
- site-preference - a value from 1 (primary) to 65535 (backup), announced by another PE as a BGP community.
In this case, the same site-identifier is indicated on both PEs. Thus, PE3 and PE4 announce the same l2vpn route, which differs only in the site-preference parameter. The route with the highest site-preference, i.e. the route from PE3 wins and all l2vpn traffic from PE1 and PE2 starts going through PE3. The ge-0/0/0 interface on PE4 does not allow traffic.
lab@PE1> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up May 30 17:29:28 2015 1
Remote PE: 10.0.0.2, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262145
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 1 remote site 2
3 rmt Up May 30 20:16:41 2015 1
Remote PE: 10.0.0.3, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262145
Local interface: lsi.1048579, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 1 remote site 3
lab@PE2> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE2 (2)
connection-site Type St Time last up # Up trans
1 rmt Up May 30 17:29:30 2015 1
Remote PE: 10.0.0.1, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262146
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 2 remote site 1
3 rmt Up May 30 20:16:42 2015 1
Remote PE: 10.0.0.3, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262146
Local interface: lsi.1048578, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 2 remote site 3
lab@PE3> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE3 (3)
connection-site Type St Time last up # Up trans
1 rmt Up May 30 20:16:35 2015 1
Remote PE: 10.0.0.1, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262147
Local interface: lsi.1048833, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 3 remote site 1
2 rmt Up May 30 20:16:35 2015 1
Remote PE: 10.0.0.2, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262147
Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 3 remote site 2
3 rmt RN
lab@PE4> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE3 (3)
connection-site Type St Time last up # Up trans
1 rmt LN
2 rmt LN
3 rmt LN
It should be noted that on PE4 all VPLS connections are in the LN state - local site not designated. This means that PE4 is not involved in the transmission of VPLS traffic.
If the PE3-CE3 link crashes or PE3 is disconnected from the rest of the network, the router stops announcing the l2vpn route, PE4 starts passing traffic on the ge-0/0/0 interface, and PE1 and PE2 begin to route traffic towards PE4. The channel switching rate in this case depends on the BGP convergence rate.
Bundle of VPLS and STP
Now for the fun part. Consider a topology in which CE1 and CE2 are interconnected.
When using BGP-Based Multihoming in such a topology, everything will be fine until the CE1-CE2 link breaks. PE routers do not know about the topology change and, in the case when, for example, PE1 is the main router, traffic to CE2 will continue to go through PE1 and will be discarded.
In order for topology changes in the CE segment to be transferred to the VPLS segment, you must configure the interaction between STP and VPLS.
Below is a bit of a high-level theory of how this should work.
Let's consider a regular situation when all links work.
- PE1 and PE2 participate in both STP and VPLS domains
- The STP domain is local to CE1, CE2, PE1, PE2 and does not apply to PE3, PE4 and CE3
- STP on PE1 and PE2 is configured so that PE1 is the root bridge and PE2 is the backup root
- On ports PE1 and PE2 looking towards CE, root protect is configured. Thus, when BPDU from PE1 arrives on port PE2, this port is blocked
- On PE1 and PE2, PWs (pseudowires) are raised to each other and to PE3 and PE4 (fully connected), while PE2 signals its PWs as standby (shown by dashed lines), because the port towards CE2 is in a blocked state
Suppose the CE1-CE2 link is broken.
In the STP domain:
- CE1 and CE2 send Topology Change Notification
- CE1 and CE2 reset MAC tables
- PE2 becomes the root bridge in its segment
- PE1 remains root bridge
- PE2 unlocks the port towards CE2, as stops receiving BPDUs from PE1
In the VPLS domain:
- PE2 puts its PW in the Up state, because the port towards CE2 is no longer blocked
- PWs on PE1 remain Up as before
- PE2 sends a signal to PE3 and PE4 to reset the MAC addresses received from PE1
- PE3 and PE4 begin to use both PE1 and PE2 to transfer traffic to CE1 and CE2
When restoring the CE1-CE2 link, the TCN is sent again and the script repeats, with the difference that the PE2-CE2 link is blocked.
Now let's move on to setting up. I note right away that I was able to recreate this behavior only using the LDP protocol for VPLS signaling ( RFC 4762 ), although it is not written anywhere in the official documentation (correct if I am mistaken).
Configure STP
Unlike regular switches, in order to configure STP on MX series routers, you need to create a routing-instance with the layer2-control type.
PE1 and PE3
PE1 & PE3 STP config
routing-instances {
STP {
instance-type layer2-control;
protocols {
vstp {
interface ge-0/0/0 {
mode point-to-point;
no-root-port;
}
vlan 10 {
bridge-priority 24k;
}
}
}
}
}
PE2 and PE4
PE2 & PE4 STP config
routing-instances {
STP {
instance-type layer2-control;
protocols {
vstp {
interface ge-0/0/0 {
mode point-to-point;
no-root-port;
}
vlan 10 {
bridge-priority 28k;
}
}
}
}
}
Checking the operation of STP
lab@PE1> show spanning-tree interface ge-0/0/0 routing-instance STP
Spanning tree interface parameters for VLAN 10
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/0 128:1 128:1 24586.00058671c3d0 20000 FWD DESG
lab@PE2> show spanning-tree interface ge-0/0/0 routing-instance STP
Spanning tree interface parameters for VLAN 10
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/0 128:1 128:1 32778.500000080000 20000 BLK ALT (Root-Prev)
STP works as it should - the port towards CE2 is blocked by root protect.
Configure VPLS on LDP
Unlike BGP, when configuring VPLS with LDP signaling, you must manually specify the IP addresses of all PE routers participating in VPLS.
PE1
PE1 LDP VPLS config
protocols {
ldp {
interface lo0.0;
}
}
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
protocols {
vpls {
no-tunnel-services;
vpls-id 1;
mac-flush;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
}
}
}
}The key parameter here is mac-flush . Without it, routers will not reset the MAC address table when the topology changes.
On PE2, PE3, PE4, the settings are absolutely identical except for the neighbor strings.
Checking the operation of LDP
lab@PE1> show ldp neighbor
Address Interface Label space ID Hold time
10.0.0.2 lo0.0 10.0.0.2:0 33
10.0.0.3 lo0.0 10.0.0.3:0 44
10.0.0.4 lo0.0 10.0.0.4:0 41
LDP connections have risen, look what with VPLS
lab@PE1> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
VPLS-id: 1
Neighbor Type St Time last up # Up trans
10.0.0.2(vpls-id 1) rmt Up May 30 23:50:32 2015 1
Remote PE: 10.0.0.2, Negotiated control-word: No
Incoming label: 262401, Outgoing label: 262401
Negotiated PW status TLV: No
Local interface: lsi.1048580, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls VPLS neighbor 10.0.0.2 vpls-id 1
Flow Label Transmit: No, Flow Label Receive: No
10.0.0.3(vpls-id 1) rmt Up May 30 23:51:49 2015 1
Remote PE: 10.0.0.3, Negotiated control-word: No
Incoming label: 262402, Outgoing label: 262401
Negotiated PW status TLV: No
Local interface: lsi.1048581, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls VPLS neighbor 10.0.0.3 vpls-id 1
Flow Label Transmit: No, Flow Label Receive: No
10.0.0.4(vpls-id 1) rmt Up May 30 23:52:00 2015 1
Remote PE: 10.0.0.4, Negotiated control-word: No
Incoming label: 262403, Outgoing label: 262401
Negotiated PW status TLV: No
Local interface: lsi.1048582, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls VPLS neighbor 10.0.0.4 vpls-id 1
Flow Label Transmit: No, Flow Label Receive: No
lab@PE2> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
VPLS-id: 1
Neighbor Type St Time last up # Up trans
10.0.0.1(vpls-id 1) rmt ST
10.0.0.3(vpls-id 1) rmt ST
10.0.0.4(vpls-id 1) rmt ST
Here, too, everything is in order. On PE2, the connections are in standby state.
We check that CE3 can ping CE2. Traffic should go through PE3, PE1 and CE1.
CE3>ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/18 ms
We look at the table of MAC addresses on PE3
lab@PE3> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : VPLS
Bridging domain : __VPLS__, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID
50:00:00:08:80:0a D lsi.1049088
50:00:00:09:80:0a D ge-0/0/0.10
Here 50: 00: 00: 08: 80: 0a is the Vlan10 interface MAC address on CE2, lsi.1049088 is PW from PE3 to PE1.
Now break the CE1-CE2 link and see what has changed
lab@PE1> show spanning-tree interface ge-0/0/0 routing-instance STP
Spanning tree interface parameters for VLAN 10
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/0 128:1 128:1 24586.00058671c3d0 20000 FWD DESG
lab@PE2> show spanning-tree interface ge-0/0/0 routing-instance STP
Spanning tree interface parameters for VLAN 10
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/0 128:1 128:1 28682.0005867142d0 20000 FWD DESG
The PE2 interface towards CE2 has transitioned to the Forwarding state as it should.
Again we ping PE2
CE3>ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/13/19 ms
We look at the MAC table on PE3
lab@PE3> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : VPLS
Bridging domain : __VPLS__, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID
50:00:00:08:80:0a D lsi.1049089
50:00:00:09:80:0a D ge-0/0/0.10
As you can see, MAC CE2 is now on the lsi.1049089 interface, and this is PW before PE2.
conclusions
As you can see from the article, VPLS Multihoming is not the most trivial task with its pitfalls. Both approaches described by me to the solution of this problem have their advantages and disadvantages and are applicable only in certain situations. The general disadvantage of VPLS Multihoming is the inability to use two uplinks simultaneously. If such functionality is necessary, you should look towards EVPN technology, which is gradually replacing VPLS.
