How to signal a VPLS multihoming change to a L2 CE device

Question

We have the following setup:

Two MX routers connect to the same L2 site. Loop protection / redundancy is done via VPLS multihoming. On the other end are two switches (EX4200 for example).

When the blue link fails the two switches and the rest of the L2 infrastructure have to know that traffic must now go through the yellow link (and consequently trough the EX switch on the right).

The problem is, the yellow mac-table only gets filled when there is traffic arriving from the VPLS through the yellow link. If no traffic is received from a certain MAC address, traffic for that address will still be sent over the blue link and noone knows that that link is now broken (except perhaps the EX switch on the left if the link fails physically).

I can't find a good solution to fix this problem.

A few approaches:

1. You can somewhat lessen the impact by not making the blue/yellow link portfast so that spanning-tree can send a topology change when the interface goes down/up. When the interface does not go down physically you're out of luck. On the other hand the spanning-tree solution will bite you when the port comes up again. VPLS will take the site online but the port needs to go trough the STP learning stages before it forwards traffic.

2. You could stack the two switches. This will fix the problem for the rest of the L2 infrastructure as they always send to the same switch (stack). Still the stack needs to know when to switch to the other uplink interface with the active VPLS instance.

3. When doing planned maintenance (and if you have a stack), you can deactivate the primary link manually to switch over to the secondary link. Then you can lower the site-preference for the deactivated link on the router so that the now active site becomes the new primary. Same thing when switching back. Not ideal and does not work for unforeseen outages.

Any input on how to solve this is appreciated. (Waiting for EVPN/TRILL does not count. ;))

Answer 1

1. Disable Portfast on the PE facing ports (On CE)
2. Enable RSTP across the CE network
3. Favor "Blue link" w/ interface cost

Working this out in my head I believe it should react as follows:

When blue link dies the CE will stop sending/receiving BPDUs from the blue interface. Default RSTP hello timer is 2 seconds. It waits for three missed hellos before calling that link "dead". Once three hellos (6 seconds) have been missed it will then re-establish the STP tree and age the MAC addresses.

This is basically option 1 you've stated above except the way I've read the comments and your original post it sounds like you want the PE to participate in STP. I'm suggesting allowing the customer to build its own tree between all CEs.

Your network should fail over smoothly, and the client network would follow suit a few seconds later.

This feels too simple to be the answer...but that's what I can see based on your write up.

Answer 2

What kind of convergence budget are you looking for?

If you'd ditch the idea of using VPLS loop-prevention and run unique siteID, you could go back to STP. You'd experience loss of link via BPDU even in absence of hardware liveliness failure.

Then you could tune your convergence budget by TCN/forward-time (MAC timeout, after TCN has been seen) or by bigger hammer 'mac aging-time'.
Flip side is, you'll have more unknown unicast in the network, which you can workaround by making sure ARP timeout is less or equal to TCN/forward-time

I know probably not the answer you're looking for, but if there is some silver bullet here, I'm missing it. I don't think trill or EVPN draft would help you either in this scenario, if your VPLS or EVPN would be end-to-end right to the host port, then it would fix this right up. But just replacing VPLS to EVPN at the core and keeping disconnected LAN in either side, would provide same problem.

Answer 3

Sticking to the options you provide, I personally would follow #1 on your list, but I would not use common ST. I would rather use RST (or MST if you need to load balance VLANs across links) as it allows for must fast/smoother transition when a link comes up or goes down.

This addresses both the concerns you have for this approach:

1. "Interface doesn't go down physically" - each device running RST generates BPDUs (rather than just relaying) and they are used as keep alives. Failure to receive BPDUs will result in aging out the information.
2. "Need to go through STP learning stages before forwarding traffic" - RST is able to actively confirm that a port can safely transition to forwarding state without waiting for timers.

I would also consider doing #2 in addition as this just simplifies the management of the devices.

Answer 4

Perhaps an event script could be made on the "failing" MX to take the link down? If there is some kind of lit transport, then that may not work.

In most applications I've worked on like this, we've had bi-directional traffic, such that the remove MACs that should move eventually come in via the backup port, and the old FIB entry is evicted, and the new port installed.

If your L2 site served by those EXes only ever sends traffic, then the only thing I could think to do would be to decrease the mac-table-aging-time to an acceptable amount.