configuring STP between 3com and cisco

paulnigel · ‎12-19-2006

Hi forum,

I am not sure I understand correctly or not.

For 3com, it run a single STP instance for all vlans(up to 16 for my case i supposed(the rest broadcast), 3300 3com switch)). Some of my 3com is used as the distribution switches at certain rack, but they are connected to Cisco switches at the core.

If my cisco is running pvst, for those port connected to 3com that carry multiple vlans, what the cisco will see at the port, and how 3com view cisco at the port too?

How do I make them work together?

Thank you,

py

ovt · ‎12-20-2006

If they're 802.1q-connected 3com and cisco STPs will see each other via Native vlan (vlan 1 by default) using standard 802.1d STP MAC 0180.C200.0000. This means that common topology is built for VLAN 1 (vlan 1 in PVST+ region) and entire 3com network. Also, cisco switches will send BPDUs for other vlans using cisco MAC 0100.0CCC.CCCD. As 3coms do not undestand this they will flood multicast frames to all their ports and a cisco switch on the other side of the network (if any) will receive those frames and build per-VLAN topology.

HTH

paulnigel · ‎12-20-2006

Hi ovt,

I hope I understand correctly.

1) Cisco vlan 1 will merge with 3com VLANs.

2) when cisco send BPDU for other vlans, 3com will flood to all ports on itself? or flood to the entire network(including cisco) where itself is also a member? Or it will flood to cisco Vlan 1 and any other multicast will be dropped at cisco side?

When I show span root on the cisco, i get something like this:

VLAN0001 32768 000b.ac0b.3c40 4 2 20 15 Gi0/14

VLAN0002 32768 000b.ac87.e500 25 2 20 15 Po10

VLAN0003 32768 000b.ac87.9280 25 2 20 15 Po10

VLAN0005 32773 0014.694c.1900 0 2 20 15

VLAN0006 32774 0014.694c.1900 0 2 20 15

VLAN0010 32778 0014.694c.1900 0 2 20 15

VLAN0011 32779 0014.694c.1900 0 2 20 15

VLAN0020 32788 0014.694c.1900 0 2 20 15

the VLAN1 is actually having a 3com switch as STP root, I haven't track that down. therefore when there is something wrong with that switch, Can I say i will get constant reconvergence on the whole network, the instability? besides, for any vlan that is beyond 16, 3com will block it?

Thank you,

py

ovt · ‎12-21-2006

Ok,

1) No, STP will merge, not VLANs.

2) See the link below with better explaination.

1. What kind of problems do you have in your network? Instability or STP loops? If you have instability only this means that you CAN trunk-connect 802.1d 3coms with cisco PVST+ switches. Do you have physical loops between 3coms and ciscos? Such as two 802.1Q uplinks from a single 3com to two cisco switches? If yes, this again means that you CAN trunk-connect them without any problems. If you suspect there is a loop - verify CPU utilization and look at the number of broadcasts with the "show int counters" command. If you see that there is no loop -- disregard all other opinions that 802.1d and PVST+ switches cannot be trunk-connected.

2. The following explains well how PVST+ works and why you should NOT use access links between 802.1d and PVST+ switches:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00801d11a0.shtml

3. If 3coms do have redundant uplinks to catalysts they will block one uplink for ALL VLANs (!) unless the 3com switch is the root for the VLAN 1. (Single STP means "if block - block for all VLANs". Roots never block their ports.) So, when choosing the root switch consider two things: stability and load-balancing requirements. "Cisco LAN switching" book by Clark and Hamilton has good explaination of load balancing when 802.1d and PVST+ switches are mixed together.

HTH

rseiler · ‎12-20-2006

I would highly NOT recommend trunking between the 3Com switch and the Cisco switch. You WILL create a spanning-tree loop because the Cisco switch will assume the 3Com switch is honoring STP per-vlan (which it is not). You will create a loop for each vlan other than vlan 1 for every vlan that is active on the trunk and passing traffic.

Note that this is not an issue if you are connecting one 3Com switch to one Cisco switch because there is no loop. In most enterprise designs this is not the case.

This is also a problem with all HP, Nortel, and Extreme switches and most cheap switches from Dlink, Netgear, etc.

One option is to NOT trunk between the 3Com and Cisco switches. Connect the switches together with a single access port in a single vlan on each switch. The port *MUST* be in vlan 1 on the 3Com switch, it can be in any vlan on the Cisco switch. This would allow 12 or 24 users on the 3Com swtich to be in a Cisco vlan without an STP issue...

Good luck!

paulnigel · ‎12-20-2006

Thank you rseiler,

I just joined my company. It happens that we have lots of instability issue in the network. The problem could be like what you have said, due to the STP between 3com and cisco.

But my situation is a bit difficult, because most edge racks are 3com equipments and they are trunked to cisco at the core, some rack carry up to 4 or 5 vlans, I have managed to get a few cisco switches in as the distribtion switch with 3com as plain switch, and those racks are fine, but to get the 50+ racks all with cisco will take time.

and it seems that some of the STP vlan has 3com as root switch too. In the meanwhile, how do I ensure I have less problem, less ups and downs in the network if I have to stick with my current setup?

Thank you,

paul

Francois Tallet · ‎12-21-2006

The pvst switch does not assume that its neighbor is necessarily running PVST. PVST+ is designed to that it can interoperate with third party bridges that don't understand Cisco's PVST. The solution chosen was to send PVST BPDUs to a destination mac that is unknown to third party bridges, as explained in the first post.

This solution as its pros and cons. In theory, this is plug and play. PVST BPDUs are tunneled through the third party bridges (the whole network of third party bridges look like a big hub to the PVST+ switches). As a result, except for vlan 1, that is running IEEE stp with the 3rd party bridges, all the vlans can only block on the Cisco switches. This introduces some limitation on the design. Convergence might be longer in case of failure in the 3rd party bridge network. Link recovery in the 3rd party bridge network can introduce transient loops. All this is common to all solution implying tunneling of bpdus.

A simple solution is to run MST on the cisco bridges (with no configuration at all, it's equivalent to RSTP). You will not be able to do load balancing on a per-vlan basis, but the behavior of the whole network will be simpler to manage.

Regards,

Francois