Can someone tell me if I have this right?
I have a core switch which has connections to all access switches in the LAN. Everything is on VLAN 1. All ports are non-trunk ports.
I connect a new switch to the core switch. The new switch uplink port to the core is configured as a 1Q trunk. The core port is still a non-trunk port. Will the core switch forward the trunk PBDU to all non-trunks access switches and put them in a block state due to the port types not matching?
Just some notes. If the new switch will only carry VLAN 1, why would you want to connect it to the core via trunk? If the port on the core switch, where the new switch will be connected, is configured in a dynamic desirable mode (which is usually the default for backbone switches), the port becomes a trunk port if the neighboring port is set to trunk, desirable, or auto mode. Also, I believe that BPDUs are used in STP and not in trunking. STP runs on all switches in the network by default while a trunk runs only between the two point-to-point devices.
I didn't fully explain my situation.
I connect the new switch to the core and I do want all the access ports to be on VLAN 1. But then I plan to connect another switch to the new switch via GBIC. The access ports on this second new switch will be in let's say VLAN 50. This is the reason that the new switch link to the core needs to be a trunk.
Would the core forward the BPDU to all other switches seeing it didn't understand the BPDU? Also, BPDU's would be present in my situation due to PVST right?
The core switch is an Alcatel and I don't know it supports any form of dynamic trunking. I tend to think it doesn't.
Let me know if the diagram below is correct:
(2nd NEW SWITCH) <----> (1st NEW SWITCH) <----> (CORE) <----> (OTHER ACCESS SWITCHES)
And the following info:
- Only VLAN 1 in "OTHER ACCESS SWITCHES", "CORE", and "1st NEW SWITCH"
- VLAN 50 on access ports of "2nd NEW SWITCH"
- "CORE" to "1st NEW SWITCH" via trunk
- "CORE" to "OTHER ACCESS SWITCHES" via non-trunk (or access ports)
- "1st NEW SWITCH" to "2nd NEW SWITCH" via trunk
Information about VLAN 50 should not pass through the non-trunk ports.
So I assume you want to create a new VLAN but you do not want this VLAN
to be seen on all other access switches connected to the core, except the
"1st NEW SWITCH". Or I had a wrong interpretation?
What I only wanted to point out is that, in my opinion, you should only create
trunk ports on switches where more than one VLAN exist and needs to pass the VLAN
information to other switches via trunk. I apologize for any confusion I've made.
Yes, your diagram is accurate. The second new switch is going to connect to wireless AP's on VLAN 50 and perhaps more wireless VLANs. So, I would in fact need the link between the core and switch 1 to be a trunk as well as the link between switch 1 and 2 to be a trunk.
This strays a bit from my original question though. And that is, seeing as I brought a new switch up configured with a trunk port and the other end was not a trunk is this what put all other access switches in the VLAN in a block state?
Do you mean after connecting switch 2 to switch 1 and switch 1 to the core switch, all other access switches went to a blocked state? Perhaps there's another path from the access switches going back to the core. But if there's none, you could be looking through another problem here. Just to make sure, I think it would be better if you could try different trunking modes on the new switch (switch 1) connected to the core to enable trunking. If none of the trunking modes work, probably the port on the core switch is configured only as an access port.
all access switches have only one path to the core. i believe everything went to a blocked state at the point where i had switch 1 configured as a trunk and the core switch as an access port. the core is a alcatel switch and as far as i know can not automatically negotiate whether to become a trunk port or not. if the alcatel forwarded the BPDU to all other access switches and they couldn't become a trunk port either i think they all went into a block mode.
i am using 802.1q for trunking because the alcatel will not do isl, nor do i want to use isl.
So I guess you will only have to look on the Alcatel core switch and switch 1 for the cause of the problem. Just keep in mind how the Catalyst switch is configured for trunking and how it deals with trunk negotiations. It will surely help in your problem isolation. The CCO is always available if you want additional troubleshooting resources.
I think this is a vendor incompatibility issue.
There might be two basic problems:
a) 802.1q trunking implementation on Cisco and Alcatel:
Cisco is using native VLAN feature (VLAN1 default) which send frames belonging to the native VLAN untagged on the trunk.
Alcatel might not be using native VLAN, so ALL VLAN frames might be tagged on the Alcatel side. If this is true, you need either force Cisco to tag all VLANs ( set dot1q-all-tagged on CatOS, vlan dot1q tag native in latest IOS) or force Alcatel not to tag frames in VLAN1 (I don't know if this is possible but 3Com is able to do it, e.g.)
It is probably necessary to set trunking mode to nonegotiate.
Cisco is using PVST+ default. I.e., every VLAN has it's separate STP tree. BPDUs are sent for each VLAN (untagged for native VLAN, tagged for other VLANs on a 802.1q trunk port). Cisco is even sending two types of BPDUs: IEEE 802.1d BPDU sent in VLAN1 (called Common Spanning Tree) to muticast address 01-80-c2-00-00-00 and Cisco PVST+ BPDU sent in all VLANs to multicast address 01-00-0c-cc-cc-cd on trunks. See http://www.cisco.com/warp/public/473/103.html#stp for details.
If Alcatel is not using PVST (and probably is not, it is Cisco proprietary), it won't recognize the other VLANs BPDUs and probably forward them as ordinary multicasts to 01-00-0c-cc-cc-cd address.
But if your trunk is not configured correctly both ends (it's acces port on the Alcatel side) all the tagged frames should be discarded by the Alcatel switch and there should be no STP blocking problem. Another situation might be if Alcatel switch doesn't discard the tagged frames and forwards them somehow. If this happens, there might be unpredictable network behaviour.
So the conclusion:
1) configure trunk correctly according native VLAN
2) fix the spanning tree depending on Alcatel approach to multiVLAN spanning tree