cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3755
Views
0
Helpful
6
Replies

Native vlan mismatch between cisco and non-cisco switches

rramlal
Level 1
Level 1

Hi All,

I recently did a changeout of core infrastructure. It was originally a 3com and was replaced with a nexus cluster. The rest of the environment is still 3com, the access layer that is. During the implementation we discovered that the customer had merged two vlans via native vlan mismatch under the existing 3com infrastructure for communication from the access clients to the production servers. The production servers and clients are on the same subnet but prod is vlan 100 and access clients are vlan 1.

Initially when we migrated all access switches to the nexus cluster there was no communication until the same configs from the previous 3com core were replicated on the nexus core that is the native vlan was set to 100. On the access switches end their native vlan was default on vlan 1. So this configuration is working fine however when i try to simulate this exact config on two cisco swiches i am getting the error msgs of native vlan mismatch and the ports are blocked by STP. I turned off cdp and same result, msg stating that the bpdus received had a mismatch on the native vlan.

Can anyone advise why this is working for the nexus/3com environment? The nexus is set to rapid-pvst mode while the 3com is set to rstp mode. Do you think a difference in stp modes can cause this environment to work the way it is?

Any ideas would help?

6 Replies 6

Aninda Chatterjee
Cisco Employee
Cisco Employee

Hello,

Spanning-tree's mechanism of detecting native VLAN mismatches does not use CDP; you saw this behavior in action when you turned off CDP and still saw the interfaces blocked (from a spanning-tree perspective) for the mismatched VLAN pair.

Spanning-tree, instead, uses the VLAN information in the SSTP BPDUs that it sends out to detect such mismatches. This makes for an interesting scenario in your situation, since I believe that the RSTP mode of 3com does not understand SSTP BPDUs. These BPDUs are Cisco proprietary and are not understood by most third party switches unless they are running in some sort of compatibility mode.

Since the SSTP BPDUs are simply flooded out and not processed, there is no way to detect the mismatch. I'll have to test this to be a 100% sure, but I believe this is what might be happening.

Regards,

Aninda

Hello,

recently we had an interesting disscusion about the way Cisco switches detect native VLAN mismatches:

https://supportforums.cisco.com/message/4001087

I neither have experience in the STP behavior of 3com switches, but normally  a non-Cisco switch doesn't recognize the proprietary BPDUs for what they are, but because the group-bit of the destination MAC-address is set, treat them as multicast.

So if there's no blocking port in the 3com part, they will be "forwarded" to the other Cisco switch(es). The port roles are not really predictable but somewhere on a non-root bridge the loop will be cut (port which is neither root port nor designated). That means, from the Cisco perspective you could have two different ST topologies: One for the VLAN 1 (IEEE destination address) and another one for the other instances (destination address 01-00-0C-CC-CC-CD). In contrast, the 3com Switche only know the topology of the VLAN 1 instance of the Cisco part.

Hope that helps

Rolf

One more note:

A couple of years ago we had a similar scenario with HP Procurve and Catalyst switches.

We used MSTP and had some very undesired effects whenever a RSTP+ switch was added.

One solution we finally found was to suppress the 01-00-0C-CC-CC-CD as multicast destination address on the HPs.

Maybe you can configure something similar on your 3coms, if needed for some reason.

Best regards

Rolf

Hi Rolf,

Thanks for joining in! Yes, that was a very interesting discussion that we had.

And you're right; from the 3com perspective, it is only going to understand the IEEE BPDU and use that to build it's spanning-tree for VLAN 1. The other BPDUs (SSTP BPDUs) will simply be flooded across and if there are any Cisco switches behind the 3com switch, they would receive and process the BPDU. So for VLANs 2 and above, the 3com switch behaves like a transparent bridge, more so like a hub.

One solution we finally found was to suppress the 01-00-0C-CC-CC-CD as multicast destination address on the HPs.

That's an interesting solution. Just to be clear, by suppress you mean that you configured the HP switches to drop the 0100.0CCC.CCCD (SSTP) BPDUs? Did this really bring about a stable environment? Consider the following topology:

SW1 (Cisco)-------- SW2 (HP)------------SW3 (Cisco)

SW1 and SW3 and Cisco switches running PVST+ and SW2 is a HP switch, stuck right in the middle of the other two. Let's take VLAN 2 as an example. SW1 has a priority of 4096 while SW3 has a priority of 32768 for this VLAN. VLAN 1 builds itself fine with even SW2 understanding and participating in that VLANs spanning-tree.

However, if we were to suppress (drop, as I have assumed it to be) BPDUs with destination mac address of 0100.0CCC.CCCD on SW2, this would mean that VLAN 2s BPDUs (SSTP BPDUs generated by SW1) never reach SW3. In that event, SW3 would elect itself as the root bridge for VLAN 2 and now you'd have two root bridges for the same VLAN. Doesn't seem like a very ideal situation to have yourself in.

Again, I'm just jumping to conclusions. Perhaps you could explain your topology a bit more and how you utilized this suppression of SSTP BPDUs please?

Regards,

Aninda

Hello Aninda,

of course your're absolutely right and I definitely should have added an advice to be cautious when doing something like that.

Our scenario was a little bit different because the HPs were the core switches and the Catalysts (among others) were the access-switches. The problem we wanted to solve was, that whenever a new Catalyst switch was added, which was not pre-configured for MSTP for some reason (auto-install or lack of staff's knowledge), it started sending SSTP BPDUs and the HP core flooded them to the other access-switches. All the Catalysts then resulted in spanning-tree inconsistency state for 2 minutes because they were running in MST-mode but received PVST+ BPDUs.

I think this is a very special scenario and normally there is no need for dropping the SSTP BPDUs unless they don't cause any problems. As you described, in multi-vendor environments they can be a last resort in cutting bridging loops or at least produce a more desired topology.

The original post doesn't say this explicitly, but I assume that the Nexus cluster is the spanning-tree root and hence we have blocking ports somewhere on the 3coms (which also should block the SSTP BPDUs), so we should have a stable and predictable topology.

Best regards

Rolf

Our scenario was a little bit different because the HPs were the core switches and the Catalysts (among others) were the access-switches. The problem we wanted to solve was, that whenever a new Catalyst switch was added, which was not pre-configured for MSTP for some reason (auto-install or lack of staff's knowledge), it started sending SSTP BPDUs and the HP core flooded them to the other access-switches.

That is quite a pickle to be in Thanks for sharing the scenario with me.

Regards,

Aninda

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: