Configuring VPLS Multihoming on Juniper Routers
VPLS technology has long established itself as a way to combine geographically separated objects into a single L2 network. This solution is well scaled compared to the classic L2 network and allows you to get rid of L2-loop problems in the network core. However, it often becomes necessary to organize backup channels from the subscriber to the VPLS-cloud. In such a situation there is a danger of looping in the PE-CE section. To solve this problem, there are several approaches. Here are some of them:
In this article I would like to consider the first two approaches.
Transport setting
BGP-Based VPLS Multihoming
A bunch of VPLS and STP
findings
The materials used in writing the article
The main purpose of this article is to present a working configuration of a fairly comprehensive solution. When writing, I did not set myself the goal to go deep into the theory and explain the subtleties of the work of those or other 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 network of the provider consists of PE and P routers (Juniper MX), all of them are in OSPF Area 0 and BGP AS 65412. The subscriber network is three switches (Cisco Catalyst), each of which has Vlan 10 and RPVST-version Spanning-tree protocol (VSTP in Juniper terminology).
Before you begin setting up VPLS, you must raise the MPLS transport. For LSP signaling, this example uses the RSVP protocol. 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 the interface is to be used only under VPLS, then encapsulation ethernet-vpls or vlan-vpls should be specified. Read more 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 “classic”, from Juniper's point of view, 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 - here also Route Distinguisher and Route Target are used, 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, I used P1 and P2 as the route reflector to simplify the configuration.
PE routers:
P1
P2
It is worth noting the routing-options block. When route-reflector receives a route from its client, before announcing it to other clients, it checks the availability of the next-hop in the inet.3 table. Since during the initial configuration of MPLS on P-routers, I did not create LSP to PE-routers, this table is empty and, accordingly, the test does not work. Routes received from RR clients are marked as hidden and are not announced further. Of course, you can create LSPs from RRs to each PE, but this is laborious, and these LSPs will never be used to transmit traffic. It is much easier and more elegant to create a static route to the lo0 network
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
It's all quite simple: create a routing-instance with the type of vpls, assign RD and RT, specify the interfaces in the direction of CE and the unique site-identifier.
Checking:
VPLS connections have risen. You can check the connectivity of CE1 and CE2:
As can be seen 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 of PE3 and PE4.
PE3
PE4
Unlike previous configurations of PE1 and PE2, two parameters are added here:
At the same time, the same site-identifier is specified 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 to go 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 suggests that PE4 does not participate in the transmission of VPLS traffic.
When the PE3-CE3 link drops or PE3 loses connectivity with the rest of the network, the router stops announcing the l2vpn route, PE4 starts to pass traffic on the interface ge-0/0/0, and PE1 and PE2 begin to route traffic towards PE4. The channel switching speed in this case depends on the BGP convergence rate.
Now to the fun part. Consider the 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 is broken. PE routers do not learn about the topology change and, in the case where, for example, PE1 is the main router, traffic to CE2 will continue to go through PE1 and will be dropped.
In order for the topology changes in the CE segment to be transmitted to the VPLS segment, you must configure the interaction of STP and VPLS.
Below is a bit of high-level theory of how this should work.
Consider a regular situation when all the links work.
Suppose the link CE1-CE2 is broken.
In the STP domain:
In the VPLS domain:
When the CE1-CE2 link is restored, the TCN is sent again and the script repeats, with the difference that the PE2-CE2 link is blocked.
We now turn to the setting. I note right away that I was able to recreate this behavior only using the LDP protocol for VPLS signaling ( RFC 4762 ), although this is not written anywhere in the official documentation (correct if I am mistaken).
Unlike conventional switches, to set up STP on MX series routers, you need to create routing-instance type layer2-control.
PE1 and PE3
PE2 and PE4
We check the work of STP
STP works as it should - the port towards CE2 is blocked by root protect.
Unlike BGP, when configuring VPLS with LDP alarm, you must manually specify the IP addresses of all PE routers participating in the 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 lines of neighbor.
Check LDP operation
LDP connections have risen, look what with VPLS
Here, too, everything is in order. On a PE2 connection in standby state.
We check that CE3 can ping CE2. Traffic must go through PE3, PE1 and CE1.
We look at the table of MAC addresses on PE3
Here 50: 00: 00: 08: 80: 0a - the MAC address of the Vlan10 interface on CE2, lsi.1049088 - PW from PE3 to PE1.
Now break the link of CE1-CE2 and see what has changed
The PE2 interface in the direction of CE2 moved to the Forwarding state as it should.
Pinging PE2 again
We look the MAC table on PE3
As you can see, MAC CE2 is now on the lsi.1049089 interface, and this is PW to PE2.
As can be seen from the article, the organization of 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 impossibility of simultaneously using two uplinks. If such functionality is necessary, you should look towards the EVPN technology, which is gradually replacing VPLS.
- BGP-Based VPLS Multihoming
- A bunch of VPLS and STP
- MC-LAG
In this article I would like to consider the first two approaches.
Content
Transport setting
BGP-Based VPLS Multihoming
A bunch of VPLS and STP
findings
The materials used in writing the article
Disclaimer
The main purpose of this article is to present a working configuration of a fairly comprehensive solution. When writing, I did not set myself the goal to go deep into the theory and explain the subtleties of the work of those or other 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 setting
Below is the topology that I will use in this article.
')
The network of the provider consists of PE and P routers (Juniper MX), all of them are in OSPF Area 0 and BGP AS 65412. The subscriber network is three switches (Cisco Catalyst), each of which has Vlan 10 and RPVST-version Spanning-tree protocol (VSTP in Juniper terminology).
Before you begin setting up VPLS, you must raise the MPLS transport. For LSP signaling, this example uses the RSVP protocol. For brevity, I present the configurations of only two routers, the rest are easy to configure by analogy.
Basic configuration of PE routers using the example of PE1
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 the interface is to be used only under VPLS, then encapsulation ethernet-vpls or vlan-vpls should be specified. Read more here .
Basic P-router configuration using 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 CE switch configuration
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 “classic”, from Juniper's point of view, 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 - here also Route Distinguisher and Route Target are used, 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, I used P1 and P2 as the route reflector to simplify the configuration.
BGP Setup
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; } } } It is worth noting the routing-options block. When route-reflector receives a route from its client, before announcing it to other clients, it checks the availability of the next-hop in the inet.3 table. Since during the initial configuration of MPLS on P-routers, I did not create LSP to PE-routers, this table is empty and, accordingly, the test does not work. Routes received from RR clients are marked as hidden and are not announced further. Of course, you can create LSPs from RRs to each PE, but this is laborious, and these LSPs will never be used to transmit traffic. It is much easier and more elegant to create a static route to the lo0 network
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.
VPLS Setup
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; } } } } } It's all quite simple: create a routing-instance with the type of vpls, assign RD and RT, specify the interfaces in the direction of CE and the unique site-identifier.
Checking:
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 can be seen 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 of 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 of 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 the BGP community.
At the same time, the same site-identifier is specified 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 to go 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 suggests that PE4 does not participate in the transmission of VPLS traffic.
When the PE3-CE3 link drops or PE3 loses connectivity with the rest of the network, the router stops announcing the l2vpn route, PE4 starts to pass traffic on the interface ge-0/0/0, and PE1 and PE2 begin to route traffic towards PE4. The channel switching speed in this case depends on the BGP convergence rate.
A bunch of VPLS and STP
Now to the fun part. Consider the 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 is broken. PE routers do not learn about the topology change and, in the case where, for example, PE1 is the main router, traffic to CE2 will continue to go through PE1 and will be dropped.
In order for the topology changes in the CE segment to be transmitted to the VPLS segment, you must configure the interaction of STP and VPLS.
Below is a bit of high-level theory of how this should work.
Consider a regular situation when all the links work.
- PE1 and PE2 are involved in both STP and VPLS domains.
- 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 the PE1 and PE2 ports facing the CE, root protect is configured. Thus, when a BPDU from PE1 arrives at port PE2, this port is blocked
- On PE1 and PE2, PW (pseudowires) are raised up to each other and up to PE3 and PE4 (full connectivity), while PE2 signals its PW as standby (shown in dotted lines) because the port towards CE2 is in a locked state
Suppose the link CE1-CE2 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 in the direction of CE2, because stops receiving BPDU from PE1
In the VPLS domain:
- PE2 puts its PW in the Up state, because the port in the direction of CE2 is no longer blocked
- PW on PE1 remain Up Up as before
- PE2 sends a signal to PE3 and PE4 to reset the MAC addresses received from PE1
- PE3 and PE4 are beginning to use PE1 and PE2 to transmit traffic to CE1 and CE2.
When the CE1-CE2 link is restored, the TCN is sent again and the script repeats, with the difference that the PE2-CE2 link is blocked.
We now turn to the setting. I note right away that I was able to recreate this behavior only using the LDP protocol for VPLS signaling ( RFC 4762 ), although this is not written anywhere in the official documentation (correct if I am mistaken).
STP Setup
Unlike conventional switches, to set up STP on MX series routers, you need to create routing-instance type layer2-control.
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; } } } } } We check the work 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 alarm, you must manually specify the IP addresses of all PE routers participating in the 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 lines of neighbor.
Check LDP operation
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 a PE2 connection in standby state.
We check that CE3 can ping CE2. Traffic must 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 - the MAC address of the Vlan10 interface on CE2, lsi.1049088 - PW from PE3 to PE1.
Now break the link of CE1-CE2 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 in the direction of CE2 moved to the Forwarding state as it should.
Pinging PE2 again
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 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 to PE2.
findings
As can be seen from the article, the organization of 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 impossibility of simultaneously using two uplinks. If such functionality is necessary, you should look towards the EVPN technology, which is gradually replacing VPLS.
The materials used in writing the article
Source: https://habr.com/ru/post/259645/
All Articles