Basic trunking problem

Unanswered Question
Apr 21st, 2009

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?

-Jeff

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
davy.timmermans Tue, 04/21/2009 - 12:42

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?

jedavis Tue, 04/21/2009 - 12:54

Hi Davy,

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.

-Jeff

davy.timmermans Tue, 04/21/2009 - 13:13

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

no shut

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

jedavis Tue, 04/21/2009 - 13:29

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.

davy.timmermans Tue, 04/21/2009 - 13:37

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

edit:

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.

davy.timmermans Tue, 04/21/2009 - 13:54

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)

Actions

This Discussion