So, the situation: we have two switches - a 3Com on one side and a Cisco on the other - connected to each other. It doesn't matter at what distance, over copper or fiber. The ports are configured to work in Access mode (i.e. working with untagged packets).
When you connect a patch cord between the 3Com and the Cisco, the latter shuts down the port (it lights up orange), and writes these messages to the log:
2y28w: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastEthernet0/24 VLAN1.
2y28w: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/24 on VLAN0001. Inconsistent port type.
Of course, the port indicated in the messages will be the one connected to the 3Com in your situation.
This occurs, presumably, due to the different way the 802.1q mechanisms work in Cisco and 3Com, because of which 3Com, even on a port configured as Access, still sends 802.1q requests, which Cisco, in turn, doesn't expect to see on an Access port. Caught off guard, the switch blocks the port and throws a message saying that, apparently, the port on the other side is configured "not at all the way mine is".
This happens in what's called the Spanning Tree mechanism and the STP protocol. This mechanism was invented for L2 and higher devices, to detect and automatically block "rings" or "loops", i.e. situations where looped segments appear in the network. An example of such a segment is below:
Dev.A #1 <--> #4 Dev.B #5 <--> #4 Dev.C #8 <--> #10 Dev.A
As you can see, device A is connected by both ends at once, which means a "loop", and therefore an ambiguity - where to send a packet to reach its destination. This is harmful to the network.
So overall, STP is a useful thing (in my experience - not only from a theoretical point of view). However, in a 3Com-Access + Cisco-Access combination, a "false alarm" occurs.
Solution.
The glitch occurs on VLAN 1, as stated in the Cisco logs. The only solution I found is to disable Spanning Tree on VLAN 1 on the Cisco side (note that 3Com, which also has STP, behaves quite adequately and doesn't block the port). This is done as follows:
Cisco:
$ enable
# config t
(config)# no spanning-tree vlan 1
After this, Cisco unblocks the port and traffic starts flowing unimpeded between these two "brothers in mind".
PS. If successful, don't forget to save the Cisco config:
# copy running-config startup-config
Comments