Peter,
yes, I had 142kpps of broadcast traffic. For example interface
statistics from "C3550-24-B":
GigabitEthernet0/2:
2934166139 packets input, 934612896 bytes, 0 no buffer
Received 2934166135 broadcasts (0 multicast)
FastEthernet0/24:
2477728 packets input, 169336954 bytes, 0 no buffer
Received 2460055 broadcasts (0 multicast)
Isn't the L2 broadcast(FF:FF:FF:FF:FF:FF) most frequent type of frames
in L2 flood?
Could you explain this thought:
"Unidirectional traffic like that can also be because of unicast
flooding caused by an asymmetric L2 forwarding topology."
I would say it's secure enough if storm-control is applied on border
ports and customer doesn't filter BPDU's..
Keegan,
thank you for answer! As both ports facing the customer are copper
ports, the unidirectional links shouldn't be a problem because link
pulses should be able to detect link integrity. Aren't there any
configuration possibilities other than "spanning-tree bpdufilter
enable" to filter BPDU's and create a L2 loop?
regards,
martin
2011/11/23 Keegan Holley <[email protected]>:
>
> 2011/11/21 Martin T <[email protected]>
>>
>> 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? 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
>
> That is a risk, but control plane protection is a must for a router in an
> environment like that so hopefully you're protected against it. You could
> also write the config for them or a config guide to keep them from messing
> things up. Is the environment multi-tennant? If not the only risk is one
> customer blowing up their own environment. If not you or the ISP should
> install some protections to contain bridging loops.
>>
>> 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
>
> You should never connect to a customer network without some protection.
> Root-guard or setting your priority to extend sys-id +1 or something. You
> should also manipulate the spanning-tree priorities so that the same links
> block in every vlan.
>>
>> 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?
>
> Unidirectional-links, bad-asics/switchports, cables plugged into the wrong
> ports, bad copper/fiber patch panels. There are several things that could
> cause a bridging loop. Layer-2 networks aren't to be feared it just needs
> to be done right like everything else. You can probably find some docs on
> ISP best practices on google to fill in anything that doesn't come up in
> this thread.
>>
>>
>> regards,
>> martin
>> _______________________________________________
>> cisco-nsp mailing list [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
