[c-nsp] Loop Prevention in VPLS

[adamv0025 at netconsultings.com]

Hi Nick,

> From: Nick Hilliard [mailto:nick at foobar.org]
> Sent: Tuesday, October 18, 2016 10:54 PM
> 
> adamv0025 at netconsultings.com wrote:
> > If you make sure there's always just one active path from each
> > broadcast domain and have your MAC filters, then you have nothing to
> worry about.
> 
> this is not generally possible when the customer moans about wanting
> provider edge resiliency, or wanting full visibility of all macs on each
side, with
> no restrictions; even if you have per-port mac counting, a port flap
followed
> by a customer-side l2 loop can still cause a lot of
> damage: don't forget how long it takes between the time that a port
receives
> a mac address and the time that the port ACL is programmed in hardware, by
> which time the entire FDB of your entire broadcast domain could be
polluted.
> Not sure how long that operation takes on modern boxes these days, but
> I've seen it take up to 250ms on some older kit.
> 

"One active path" doesn't mean no edge resiliency or backup path. (It's just
a port/VLAN/flow has an active forwarder only in one of the PEs at any given
time)
And as you know the core has its own methods to address loops. 

I think it's providers responsibility to protect customers from shooting
themselves in a foot. After all we know better, so we should have all the
controls in place. 


I actually haven't tested a case with sending say 100K MACs per sec to see
if I can brute force the TCAM to learn more than what the per port/BD limit
is set to due to HW programing delay.  
But I don't think the HW programing delay plays a role in this particular
case. 
Maybe you are referring to another case and I misunderstood you. 


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::