[c-nsp] Spanning Tree works great - except when it doesn't

[Nick Cutting]

I came across a curly one like this a few months back - turned out the STP handling of native VLan frames VS a non-created but configured native vlan on the downstream switch port.

 The downstream switchport was also configured for native vlan of 999 - BUT vlan999 was not created in the vlan database so defaulted to expecting STP frames untagged I think - it was something like that.

-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Patrick M. Hausen
Sent: 15 October 2015 12:09
To: daniel.dib at reaper.nu
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Spanning Tree works great - except when it doesn't

Hello,

first, thanks for all the questions. Precisely the kind of help I hoped for.
While I'm really fluent with BGP and OSPF, I do not even know all the features you mention. STP has always "just worked" for us.

OK, now for some more details ...

> Am 15.10.2015 um 12:11 schrieb daniel.dib at reaper.nu:
> 
> What protocol are you running? RPVST+ or MST?

PVST

	spanning-tree mode pvst
	no spanning-tree optimize bpdu transmission
	spanning-tree extend system-id

> What were the port roles when the loop formed?

Sorry - what's a port role?

> Did you have the default bridge priority on the new switch?

Yes, and I can prove it ;-)

VLAN0001
  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)

VLAN0002
  Bridge ID  Priority    32770  (priority 32768 sys-id-ext 2)
...

VLAN1001
  Bridge ID  Priority    33769  (priority 32768 sys-id-ext 1001)

For all VLANs.

>  Is it possible that you had a unidirectional link?

Possible, yes. I will check for that. Simply try to use the other trunk port only.
- outside of business hours.

> Copper or fibre for the trunk ports?

Copper.

> Any other STP features enabled?

None that I know.

> Root Guard? Loop Guard? BPDU filter?

All at the IOS defaults. Whatever they may be. ;-)

OK, what I know: no portfast or uplinkfast on the trunks, portfast only on the FE ports connected to servers.

interface GigabitEthernet0/1
 description Trunk zu Core 1
 switchport trunk native vlan 999
 switchport mode trunk
!
interface GigabitEthernet0/2
 description Trunk zu Core 2
 switchport trunk native vlan 999
 switchport mode trunk

VLAN 999 is a dummy that has no active port or device anywhere, so one cannot accidentally inject traffic into VLAN 1 by connecting a server to a trunk port.

> Did you verify the trunks were fully operational?

Sort of. Trunks were up, VTP up and running, native VLAN identical on both ports on access switch and core - otherwise the trunk would not come up. Are there additional checks I can perform?

> It won't be easy giving more advice until we can see the output from the actual devices.

Of course. I simply did not want to just dump the entire config into my first mail with all the probably irrelevant parts. I really appreciate your guidance, here.

So, what "show xy" shall I use during the ~30 seconds I have when I'm at the data centre with both trunks plugged in - and come back with the output?

> For your second question, there are lots of different options such as stacking, VSS, VPC which can be used for less painful STP implementations. Nothing is perfect though and you need to understand why you choose a certain architecture. Then you also have FabricPath or TRILL to build L2 network not relying on STP.

LACP could work if the "core" switches are VSS ... which currently they are not.

Possibly I read too much Greg Ferro, but I'm actually looking into TRILL and other Layer 2 multipathing protocols. The "problem" is that all products I can find are ten times as expensive as run-off-the-mill Cisco gear. 10k for a 48-port-1G access switch? *phew* ...

If you wonder where I get these figures:
http://pcmicrostore.com/arista-networks-7010t-48x-rj45-100-1000/cat-p/c/p7641704.html

Kind regards,
Patrick
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100
info at punkt.de       http://www.punkt.de
Gf: Jürgen Egeling      AG Mannheim 108285