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

[Peter Rathlev]

On Tue, 2011-11-22 at 21:49 +0200, Martin T wrote:
> However, are there some other possibilities for L2 loop? I mean other
> than filtering out BPDU's in "Customer-SW"?

Filtering BPDUs will generate a loop, that's correct. If there's any
chance the customer would do this to you, I really think you should find
another solution. :-)

> Customer-SW#sh int Fa0/23 | i bits
>   5 minute input rate 0 bits/sec, 0 packets/sec
>   5 minute output rate 77321000 bits/sec, 142110 packets/sec
> Customer-SW#sh int Fa0/24 | i bits
>   5 minute input rate 77322000 bits/sec, 142111 packets/sec
>   5 minute output rate 0 bits/sec, 0 packets/sec
> Customer-SW#
> 
> Why there is a flood only in one direction? I created this flood by
> configuring 192.168.1.1/24 IP address to "R1" interface Fa0/0.300 and
> executing "ping 192.168.1.2" which sent out the broadcast ARP frames.

Um... did you have 142 kpps of broadcast traffic? That does indeed seem
like a loop. Do the "Received <X> broadcasts" and "<Y> packets input"
match up, meaning it really is broadcast?

Unidirectional traffic like that can also be because of unicast flooding
caused by an asymmetric L2 forwarding topology.

What's the purpose of the redundancy? Is it on purpose that there's no
L3 redundancy? And why is the STP interconnect needed? It seems like a
setup that is next to impossible to actually secure. :-)

-- 
Peter