Ok, I think I am losing my mind here. I have a remote site that has some old 3500XL switches in the distribution and access layer. Distribution is 3508GXL with 1 link to the core and 6 to access switches. We needed to use the free port on the 3508G to trunk 6 vlans to one additional 3548XL. Ok, pretty straight forward right? Except that we can't get it to work. The native vlan (vlan 1) seems to forward, but none of the other vlans do. There is nothing funky about this config. ISL was used on the other trunks so we set this one up the same way. The only configuration statement on the Gig trunk on either side was "switchport mode trunk". I jerked it around a little when it didn't work just to see if I could figure out why. Changed it to a dot1q trunk, no joy. Added "switchport trunk pruning vlan none" just for grins, no luck.
A "show spanning" on both ends of the trunk shows that all Vlans are forwarding. BPDUs are being received by the 3548 on all Vlans. VTP domains are the same and the access switch receives VTP updates - pruning is disabled. "show mac-add vlan 50" on the 3548XL shows only the mac of adjacent switch, presumably the source mac of the BPDU's. I would expect to see macs for all the multicast traffic on that Vlan (mac aging is 14400).
What am I missing?
according to the output the trunk is active for vlan 1,3,50,60,100,150
which test did you do in order to conclude that only the native vlan passes over the trunk?
Well, a couple of things. First, we are able to ping other devices on the network when we connect to the native vlan. That is pretty conclusive. However, since the switch is on another continent and I have no one there to perform that type of test right now I am also just looking at the dynamic MAC addresses learned on the individual Vlans. The native Vlan has a few hundred, the other Vlans just one each. There is currently nothing connected to the 3548XL.
the trunking problem occurs between
3508XL g0/4 and 3548XL Gi0/1 (remote)?
You can try to change the management vlan to another vlan and then try to ping it.
For avoiding loss of connection
>int vlan 1
>no ip add
you can upload a config to running config via tftp
int vlan 1
>int vlan 30
ip add x.x.x.x /y
and then try to access the switch from a pc connected to vlan 30
Before you start, issue the command:
reload in 15
If you've no more access to the switch in the new vlan, now problem because the switch will reboot in 15 minutes due to this command. > Previous config
Yes, you are correct on the switches and ports.
I did change the native Vlan from 1 to 50 on both ends. I was able to maintain connectivity, but I still don't see any MAC addresses being learned on Vlan 50 on the 3548.
It has been a while since I worked with the XL switches, but it seems to me that it was kind of a pain to change the management Vlan remotely. I know I can create a second Vlan interface, but it will stay shutdown until a "cluster management-vlan n" is issued. At that point I believe that Vlan 1 will be shut down and the other one will come active. I seem to remember though that I had to make multiple changes, each of which would cause me to lose connectivity. So what I did is copy a group of statements to flash and then did a "copy flash:cfg.tmp run" and hoped for the best.
Sigh. I guess I'll try and make it happen.
So you can ping over the trunk via another vlan than the native vlan
And if you configure a port somewhere in the network to vlan 50, connect your pc and ping the other switch(3548). Does it record your MAC address
that's why I mentioned to do first
reload in x
When you copied your file to running-config and lost the connection, the switch would boot up with the startup configuration, which is not modified.
else you can try to change the native vlan and keep the same vlans as management vlan.
I would use the reload in x command before and cancel (reload cancel) the command if the connection remains
(if supported by the software off course)