[c-nsp] risks of assigning redundant paths on data link layer to end-customer

[Peter Rathlev]

On Tue, 2011-11-22 at 06:55 +0200, Martin T wrote:
> Lets assume there is a following setup:
> 
> http://img844.imageshack.us/img844/9133/stp.png
> 
> ISP manages "R1", "C3550-24-A", "C-355-24-B" and "C2950-24-A".
> "Customer-SW" is fully under customer control. As you can see, there
> are two paths to "Customer-SW". What are the risks with such setups in
> general?

You mention loops, which is probably one of the worst risks. Besides
this there's the fact that a L2 networks spans many more devices. With
L3 interconnect you would only put the two devices closest to the
customer at risk. This might of course adversely affect other things,
but only things connected to these two devices. The L2 network streches
through all the shown devices. Other things than loops can cause
problems, e.g. broadcasts or STP control traffic.


That the root is placed with the customer is IMHO no big problem. They
might have reasons to place it somewhere special, and since only one of
the two paths from the CPE to R1 would be active at any time (because of
STP) it doesn't really matter where the root is from your point of view.


>  I'm able to name two disadvantages:
> 
> 1) in case customer configures (accidentally) "spanning-tree
> bpdufilter enable" on his ports Fa0/23 - 24 there will be L2 loop
> which causes very high PPS and CPU load in ISP devices
> 
> 2) in case customer switch is a STP root(it's easy to become root
> switch by changing priority when "root guard" on ISP side is not
> configured) and customer VLAN is through many ISP switches,
> non-optimal paths for traffic can take place
> 
> Are there some other possibilities for L2 loop? Or anyone seen a
> hub/switch which handles 802.1d/802.1w BPDU's somewhat abnormally and
> might create a L2 loop(under certain circumstances)? Any other
> disadvantages which might arise with setups like this?
> 
> 
> regards,
> martin
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>