Spanning Tree with other switch vendors (is VLAN 1 required)

[cco@leferguson.com]

We have new-ish Cisco switches (3650, 3560CX), with a variety of VLAN's on a LAN with no loops. We are running spanning tree just in case, with the default Cisco setup (PVRST).  Works fine, blocks if we force a loop, etc.

We have some other switches, notably Netgear 4100-26G, and a few Adtran 1335 PoE. 

On the Ciscos, we have followed what we believe is recommended and not used VLAN 1 for anything.  When we trunk between switches we have the native VLAN defined as a non-existent VLAN as well so all traffic that can be propagated must come in tagged.

My vague understanding of how PVRST and 802.1w interact is that the VLAN 1 is used for interoperability.

How does that work if the ciscos, in between individual Netgears (or islands of Netgears) does not have VLAN 1 defined? 

More specifically, to make it work properly must we define VLAN 1 just for this purpose, and trunk it? 

What appears to be happening is that these 3rd party switches are forming little islands of STP, each with their own root.  So I think that not having VLAN 1 trunked through is indeed isolating STP on the non-cisco gear.

If I do need VLAN 1 defined, how does that interact with the standing security recommendation not to use VLAN 1?   If it's only used between switches as a trunk are there any security concerns? 

Thanks in advance, 

Linwood

[omz]

Which spanning-tree protocol Netgear run? Is it not possible to just run RSTP on all the devices? To possibly eliminate the interoperability issue between PVST and ?

[cco@leferguson.com]

The Netgears have 802.1w as a default, and list the old 802.1d as an option along with 802.1s which I think is MST.

The only option on the 3650 (just looked) is mst, pvst and rapid-pvst, so it's not obvious I can run a non-per-vlan rstp. 

I also did an experiment.  I have one 3650, with two netgears hanging off of it, and each Netgear had a Adtran off of it.  I checked the root of the netgears, and each was, separately, its own root, so they were not seeing each other across the Cisco at all.

I changed the netgear to its normal default of native VLAN 1, added it to the Cisco and both allow lists, and I got a topology change with the Cisco now root for the Netgear (the single one I changed).  SO indeed it does seem to require VLAN 1 to participate.

It looks like if I trunked VLAN 1 everywhere, I would get VLAN 1's SPT shared among the netgears as the only tree, and as the VLAN 1 tree on the ciscos, so at least if I am thinking of this right it ought to work in a way, but it's not clear correctly, as the ciscos would think it was only for VLAN 1, the others would block/forward for all together.

Does this mean I need to switch the Netgears to MST and set up separate configurations for each trunked VLAN? 

[omz]

So Netgear run 802.1w which is RSTP. Most vendors do. And on Cisco switches I guess rapid-pvst is RSTP.

As an experiment what happens if you configured rapid-pvst on Cisco with 802.1w on Netgear?

[cco@leferguson.com]

---

@omz wrote:

As an experiment what happens if you configured rapid-pvst on Cisco with 802.1w on Netgear?

---

I'm not in a position to test that.  At the moment all but one Cisco and one Netgear are in production in a 24x7 facility.  I'm reasonably comfortable changing the netgear as it's clear they are not working (i.e. they are little islands of STP trees), but the Ciscos are tied together across a county and indeed to other agencies. I am about 99% sure changing the mode would have no effect, but it's a bit risky.

I was going to set this up in GNS3 and experiment, but I'm not sure I can get a reasonable 802.1w to add to the mix.

But... see my response a bit further down. I'm not clear how that moves toward the underlying issue.

[omz]

https://supportforums.cisco.com/t5/lan-switching-and-routing/native-vlan-1-with-stp/td-p/944774

[cco@leferguson.com]

---

@omz wrote:
https://supportforums.cisco.com/t5/lan-switching-and-routing/native-vlan-1-with-stp/td-p/944774

---

Thank you.  That is certainly on point, though it vacalates a bit in terms of native and what kind of presence VLAN 1 requires to be there, it is consistent with what I observed -- if I added VLAN 1 firmly into the trunked link from the Cisco to the Netgear, then the Netgears did a topology change to honor the lower priority on the Cisco -- before it clearly never saw the Cisco at all (relative to STP). 

Where it doesn't help though is what the best way to have them work and play together is. The Ciscos, if I understand, are going to do per-vlan in all their modes (well, I don't want to fall back to the slow 802.1d).  The Netgear, with VLAN 1 present, will interoperate on the VLAN 1 STP tree with the Ciscos, but they are doing so for all VLAN's, and it's not obvious that works.  It's not obvious it fails either, at least to me.

In particular in terms of implementation, to make these inter-operate properly:

- Do I need to include VLAN 1 in all Cisco to Netgear trunks -- I think yes? 

- Do I need to include VLAN 1 in Cisco to Cisco trunks (since it has a separate "tree" for VLAN 1, to allow this tree to connect to different Netgear islands)?  I think yes? 

- Do I need to include VLAN 1 in all Netgear to Netgear links -- I'm assuming not, that it sees the BPDU's in both cases? 

Or are there other considerations? 

My concern is if one day two "islands" of disconnected trees get connected, that they may not detect the loop (e.g. a loop where one path leads through ciscos, and one path leads through only netgears). And/or such a loop not on VLAN 1, will Cisco's per-vlan trees not properly inter-operate with Netgears single one.

And at least hardware wise at the moment I'm a bit limited in what I can experiment with. I can't, for example, just create a loop and see what happens.  Im going to fire up GNS3 and see if their L2 switch simulation is a straight IEEE implementation, or is Cisco.  Maybe I can experiment there.

[cco@leferguson.com]

I have been experimenting and can offer some observations, these are with a Cisco 3650 running Version 16.3.6, RELEASE SOFTWARE (fc3), and two Netgears M4100-26G running 10.0.2.26, plus I found an Adtran 1335 running 17.09.01.00.E. The topology is:

3650 - Netgear 1 - Netgear 2
3650 - Netgear 1 - Adtran

There are no loops. The Netgear 2 has nothing connected except the one trunk cable between 1 and 2.

Here are things I found:

- For the Cisco and Netgear to see each other, VLAN 1 must be in the VLAN Allowed list of the trunk that connects them on the Cisco side. It does not need to be the native VLAN. Interestingly it does not need to be in the Allowed or Native list on the Netgear. But if removed from the Cisco interface allowed list, the Cisco and Netgear each declare themselves (internally) as the root.

- For the Netgear connected to the Netgear, there is no need to have VLAN 1 in the allowed list, nor be native.

- For the two netgears, I had several instances of the trunk port between the two blocking even though the second netgear has ONLY that one single port connected, there is zero possibility of a loop. This happened only when the native vlan between the two netgears was 1. if the native vlan was anything else (real or dummy) it would not block. I have no explanation for this, nor did Netgear when I called them. I think it's a firmware bug. It is not consistent however, and I believe it arises with some specific set of steps, as I have twice now gotten it both blocking, and not blocking, with identical configurations (but probably reached by a different set of steps). This issue did not change if I removed VLAN 1 from the Cisco.

I did not experiment significantly with the Adtrans other than that they worked, never blocked, and would take or give up root properly based on priority. The Netgears also would take or give up root relative to the Adtran and, if VLAN 1 was trunked, the Cisco.

So I think my specific answer for how to manage this is just include 1 in the trunk allow list (native or not), and don't worry about the Netgears, as they will process the BPDU's regardless. Now I am worried why that Netgear to Netgear port blocked, but that's (almost certainly) a separate question, and almost certainly a bug since there's only one cable leading to it.

I'm still not sure what is happening, however, if there's are two Ciscos separated by a group of Netgears.  At the moment I don't have that (well, I do but the other Cisco's are outside of our management and not sure how configured, if STP is active, etc.) 

I gather from what I've read the vlan specific BPDU's pass through the netgears unchanged, so essentially the netgears (or other non-per-VLAN) look like a loop free hub. Is that correct? So I don't have to worry that the per-VLAN tree structure of the Cisco's for some specific vlan might be different (e.g. different root, different blocks if thare a blocks) than the non-per-VLAN structure of the Netgears?

[cco@leferguson.com]

OK, so it doesn't work.  Or at least not what I expected.

Here's what I did extending this out.

Cisco 3560 <-> Netgear C <-> Cisco 3650 <-> Netgear A <-> Netgear B

The netgear A and B are the ones I worked with before, that worked OK, recognized the CIsco 3650 as the root (it has priority 0 on all VLAN's). 

So I trunked VLAN 1 to Netgear C, and the Netgear properly saw the Cisco as root, and continued forwarding.

Then I trunked VLAN 1 to the Cisco 3560.  It shows itself as root of VLAN 1, and shows the port to the Netgear C as forwarding.  The Netgear shows the Cisco 3650 as root, and shows the port toward the 3650 as Root, and the port toward the Cisco 3560 as Forwarding.

So I have two roots for VLAN 1.

Is that how these are supposed to interact?   The Cisco will build, even for VLAN 1, it's own island with its own root? 

[cco@leferguson.com]

OK, I figured this out.  Apparently the VLAN 1 allowed is required on the Netgears as well, for VLAN 1 to go through the netgear to the other Cisco.  When I added it to the trunk on both sides, the topology changed and the proper root was shown on both.

Now before I did that, I checked, and the other non-1 VLAN were working properly, only 1 was wrong, so the non-1 BPDUs are going through the netgear as expected.

So I'm now thinking the answer is I need to trunk 1 to every non-Cisco switch, and every cisco switch that is adjacent to non-cisco.  Maybe to every Cisco in the middle also, I don't have that setu at present.

[Joseph W. Doherty]

Often other vendor STP implementations are "common" (i.e. one STP instance for all VLANs) while Cisco's is per-VLAN. (This is different from the non-rapid vs. rapid STP standards.) Often only MST is a shared standard.

Other vendor documentation might suggest how they can STP interoperate with Cisco equipment.

[cco@leferguson.com]

---

@Joseph W. Doherty wrote:
Other vendor documentation might suggest how they can STP interoperate with Cisco equipment.

---

I found one for Allied Telesyn, which actually had some good info, but have not found anything terribly useful for Netgear.