Print

Print


There are some fun interoperability quirks with Cisco PVST where it will declare the port inconsistent if it receives a PVST BPDU with the wrong VLAN encoded in it (e.g. BPDU says VLAN 10, but tag is something different).  In this case, it's a non-trunk port receiving a PVST BPDU.

If someone originates such a BPDU towards their interface on a MICE cisco switch, then it will place just their port into this inconsistent state.

If their port happens to be on a non-cisco switch that doesn't know what PVST is, it will happily "tunnel" it, usually causing the uplinks on any connected Cisco switches that receive it to go into this inconsistent state.

An ingress MAC ACL on the customer-facing ports of the non-cisco switches to block 0100.0CCC.CCCD should prevent this from happening, while leaving IEEE STP BPDUs alone.   There's no way to change this behavior in Cisco switches AFAIK (aside from running bpdufilter of course).

If it's not this way already, it would be best to run MST for inter-op with the Cisco switches if multiple VLANs will be connected.   Though even when running MST, Cisco switches still run "PVST+ Emulation," so tunneled PVST+ BPDUs will provide the same excitement as before.

Regardless of any amount of STP tweaking on MICE switches, there is still the risk that a dual-connected customer could cause a loop.   Storm-control can help there to at least constrain the amount of broadcast and multicast traffic that ends up looping.

Steven Bertsch
Engineer III
VISI, a TDS® Company
24x7 Support:  612.395.9010
Direct: 612.395.8966
Main:  612.395.9000
Email: [log in to unmask]
Web:  www.visi.com


-----Original Message-----
From: MICE Discuss [mailto:[log in to unmask]] On Behalf Of Steve Howard
Sent: Saturday, May 25, 2013 10:24 AM
To: [log in to unmask]
Subject: Re: [MICE-DISCUSS] [#2175746] MICE reachability

On 05/25/2013 09:42 AM, James Stahr wrote:
> On 5/25/2013 9:13 AM, Jay Hanke wrote:
>> > From the Mankato Networks remote switch I'm able to get to everything
>> except for carriers on the CNS remote switch.
>>
>>    
>
> I can't ping HE (bgp session with them has been down since 00:58:04)
> who is on the remote switch, but I also see weirdness pinging the
> route servers:
>
> r-pop-min-1#ping 206.108.255.1
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
> r-pop-min-1#ping 206.108.255.1 source loop1
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds:
> Packet sent with a source address of 205.173.182.62
> .....
> Success rate is 0 percent (0/5)
> r-pop-min-1#
>
> Do the route servers not use the routes they receive and use a
> provider on the CNS switch for transit?
>
> -James
>
>> On Sat, May 25, 2013 at 6:46 AM, Kelly Cochran (Hurricane Electric
>> Internet Services)<[log in to unmask]>  wrote:
>>   
>>> Are you aware of any partitions on the exchange?  We're only seeing
>>> other people on the CNS switch that we're on.
>>>
>>> -- -H U R R I C A N E - E L E C T R I C-
>>> Kelly Cochran   Sr. Network Engineer
>>> 510-580-4100    http://www.he.net/   AS6939
>>>
>

It looks like something happened last night between the CNS & Main CNS
switches.

The CNS switch showed the following in its log:
May 24 21:31:26.315 CDT: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q
BPDU on non trunk TenGigabitEthernet0/10 VLAN847.
May 24 21:31:26.315 CDT: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking
TenGigabitEthernet0/10 on VLAN0847. Inconsistent port type.
May 24 22:49:51.831 CDT: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking
TenGigabitEthernet0/10 on VLAN0847. Port consistency restored.
May 25 00:57:45.614 CDT: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q
BPDU on non trunk TenGigabitEthernet0/10 VLAN847.
May 25 00:57:45.614 CDT: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking
TenGigabitEthernet0/10 on VLAN0847. Inconsistent port type.

I added a "spanning-tree bpdufilter enable" on the port that points
toward the main CNS switch to solve the problem.

This solved the problem for now.  But, it might be nice if the technical
committee could come up some technical guidelines for spanning-tree that
will work for MICE.

Thanks,
   Steve

########################################################################

To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1


########################################################################

To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1