VPLS MAC Protection
Load vpls.ldp.basic.complete.cfg. You may need to replace with flash:blank.cfg first.
VPLS is already pre-configured in the core.
Configure MAC address resource protection by setting the limit for the BD to 100 MAC addresses. Set the MAC aging timer for half the default value. The router should disable flooding of unknown MACs for all BDs when the MAC limit has been reached.
Answer
Explanation
The SP should set a limit to the MAC addresses in a BD to protect itself from resource exhaustion. Each MAC address the customer adds to the VPLS domain takes up resources on the SP core routers.
By default, when the limit is reached, the router will stop learning additional MAC addresses but will flood unknown unicast traffic so that there is no outage. However, this would result in a waste of bandwidth, so we set the global action to disable unknown unicast flooding when the limit is reached. Because this is set globally, this will apply to all BDs. We can set MAC address maximums on an individual BD basis.
The MAC aging time can be set on a per-BD basis as well. We set half the default value which is 300 seconds, or 5 minutes.
Not shown in this lab is that MAC address learning can be completely disabled on a BD. This turns the BD into hub behaviour, in which traffic is flooded out all other ports besides the port it arrived on.
Verification
Verify the MAC aging time and max MAC address limit. All MACs should never have an aging time higher than 150 seconds.
To test that unknown unicast flooding is disabled once the limit is reached, we can set the max address limit down to 2 on one PE. This should prevent the attached CE from being reachable via unicast from one other CE.
We see the following log message on R1:
On CE3 see see that the EIGRP neighborship with R1 has a very high SRTT and RTO value. We also see that we cannot ping CE1.
The EIGRP neighborship stays up because multicast traffic is allowed to flood as normal. However, unicast traffic cannot work. Traffic from CE3 destined for CE1 has CE1’s unicast MAC as the destination which can be forwarded to CE1. But the return reply from CE1 has CE3’s MAC as the destination which is not learned. R1 does not flood this.
Remove the global MAC limit action and verify that unicast traffic works again.
Even though R1 can still only hold 2 MACs in the CAM table, unicast traffic still works because the default unknown unicast flooding action is taking place.
Last updated
