L2VPN Testing: Unexpected Effects of L2 Loop on Different Setups

[blitzperf]

Hello,

We're relatively new to the world of MPLS and have been working on a testing environment using ASR routers. In this setup, we have two clients, A and B, with an MPLS L2VPN configuration.

In our test, scenario 1, both Client A and B have two sites each, A1 and A2, B1 and B2. We've set up continuous pinging between these sites. We simulated an L2 loop by physically connecting two ports with the same VID (VLAN ID) of 50. As anticipated, both clients experienced intermittent pings. Please refer to the diagram and configuration below:

R1:
l2 vfi ClientA manual
 vpn id 100
 bridge-domain 100
 neighbor 2.2.2.2 encapsulation mpls
!
l2 vfi ClientB manual
 vpn id 101
 bridge-domain 101
 neighbor 2.2.2.2 encapsulation mpls
!
interface GigabitEthernet0
 service instance 100 ethernet
  encapsulation dot1q 50
  rewrite ingress tag pop 1 symmetric
  bridge-domain 100
 !
 service instance 101 ethernet
  encapsulation dot1q 30
  rewrite ingress tag pop 1 symmetric
  bridge-domain 101
 !
!

R2:
l2 vfi ClientA manual
 vpn id 100
 bridge-domain 100
 neighbor 1.1.1.1 encapsulation mpls
!
l2 vfi ClientB manual
 vpn id 101
 bridge-domain 101
 neighbor 1.1.1.1 encapsulation mpls
!
interface GigabitEthernet0
 service instance 100 ethernet
  encapsulation dot1q 51
  rewrite ingress tag pop 1 symmetric
  bridge-domain 100
 !
 service instance 101 ethernet
  encapsulation dot1q 31
  rewrite ingress tag pop 1 symmetric
  bridge-domain 101
 !
!

Scenario 1Now for scenario 2, we modified the connection approach. Client A's A1 is directly connected to R1, while A2 is connected to R2. Similar to before, we simulated an L2 loop using two ports with VID30. Please refer to the diagram and configuration below:

R1:
l2 vfi ClientA manual
 vpn id 100
 bridge-domain 100
 neighbor 2.2.2.2 encapsulation mpls
!
l2 vfi ClientB manual
 vpn id 101
 bridge-domain 101
 neighbor 2.2.2.2 encapsulation mpls
!
!
interface GigabitEthernet0
 service instance 101 ethernet
  encapsulation dot1q 30
  rewrite ingress tag pop 1 symmetric
  bridge-domain 101
 !
!
interface GigabitEthernet1
 service instance 100 ethernet
  encapsulation dot1q 50
  rewrite ingress tag pop 1 symmetric
  bridge-domain 100
 !

R2:
l2 vfi ClientA manual
 vpn id 100
 bridge-domain 100
 neighbor 2.2.2.2 encapsulation mpls
!
l2 vfi ClientB manual
 vpn id 101
 bridge-domain 101
 neighbor 2.2.2.2 encapsulation mpls
!
interface GigabitEthernet0
 service instance 101 ethernet
  encapsulation dot1q 31
  rewrite ingress tag pop 1 symmetric
  bridge-domain 101
 !
!
interface GigabitEthernet1
 service instance 100 ethernet
  encapsulation dot1q 51
  rewrite ingress tag pop 1 symmetric
  bridge-domain 100
 !

Scenario 2

Surprisingly, while the hosts of client B experienced connectivity issues (as expected), we noticed a peculiar effect: the hosts of client A also suffered from increased ping latency and intermittent connectivity.

Our questions:

1. Preventing External L2 Loops: Is there a way to prevent external L2 loops from affecting the network? Our aim is to isolate such loop impacts to the client they occur within.
2. Expected Behavior: Is this type of behavior anticipated even when the links of host A are separated? We assumed that direct links between hosts and routers would insulate them from loop-related issues.
3. Router Configurations: Do we need specific router configurations to mitigate such scenarios and preserve network stability? Does this behavior extend only to L2 switches?

We're keen to learn from your experiences and insights. Your guidance would be immensely appreciated as we delve deeper into MPLS L2VPN configurations.

Thank you for taking the time to read and contribute. Looking forward to your valuable inputs!

Best regards,

Blitz

[Peter Paluch · Accepted solution]

Hello Blitz,

You have a very nicely presented case - although I was a little confused by the

GE0.20

label at R1 and R2 in your diagrams. I suppose it was meant to say only

GE0

right?

Regarding your questions:

1) You as an MPLS Layer2 VPN provider do not have tools to proactively and reliably prevent external loops from happening, as you do not have full control over customers' own networks. You rely on the customers to behave well, and at most, you protect yourself against the most deleterious impacts of a loop if they cause one in their networks.

2) The loop you have created in the second scenario still consumed the bandwidth of the forwarding hardware on R1 and R2, and potentially the capacity of the MPLS cloud connection between R1 and R2. I personally am not surprised that the

A1/A2

pings were affected even if the clients were moved to dedicated interfaces.

3) As I mentioned, you cannot prevent a customer from doing something bad in their network which causes ill traffic patterns to propagate to you. What you can do is look into mechanisms that lessen the impact - storm control, input traffic policing, CoPP to protect the control plane.

Please feel welcome to ask further!

Best regards,
Peter

[blitzperf]

Hi, Peter!

Thank you very much for the well explained answer. This is very much appreciated on our side.

>>although I was a little confused by the

GE0.20

label at R1 and R2 in your diagrams. I suppose it was meant to say only

GE0

right?

It's actually

GE0.20

since we use

port-channels/bundle-ethers

on our current setups.

Just as we thought, since we've never found any resource online or any documentation regarding preventing loops created externally, there is really nothing we can do to prevent any of this happening just as you mentioned.

Best Regards,

Blitz

---

---

---