Trying to access remote switch via VLAN1 (which is shutdown)...

[ChuckHaynes]

We were trying some things to get multiple VLANs to pass through some wireless bridges. In the confusion, we have misconfigured the port and locked ourselves out of the far switch, lol. The local switch has VLAN1 (default), VLAN2 (data), and VLAN3 (voice). None of the VLANs are shutdown and the switch has an interface for both VLAN2 and VLAN3. The remote switch also has VLAN1, VLAN2, and VLAN3 (and it has an interface for VLAN2 and VLAN3). However, VLAN1 is shutdown. The port used to connect it to the local switch has always been using VLAN2. In the midst of some changes, that port got changed to VLAN1 :(  We can no longer access the remote switch at all. It does still show up in cdp neighbors on the local switch (although it says VLAN1 mismatch). Is there anyway we can get back into the remote switch without having someone go on site and perform a power cycle? Thanks.

[John Blakley]

How do these switches connect? Are they directly connected or is there equipment between them? I'm wondering if you'd be able to telnet to the switch sourcing from vlan 2... (You'd have to telnet to vlan 2's svi). You may be able to telnet to vlan2 without sourcing anything...

[ChuckHaynes]

The switches are connected via a set of wireless bridges. The original problem was that the bridges would only pass VLAN2 (and VLAN1), but not VLAN3. That may be a limitation of the bridges themselves. We cannot telnet without sourcing anything, I have tried. Let me try it with sourcing VLAN2 real quick...

[ChuckHaynes]

It doesn't seem to be working. I think the local switch has to be a Layer 3 device, whereas we have ours at Layer 2. I did try to telnet source from the router which is on the other side of the local switch, but that didn't work either.

[John Blakley]

Can you ping anything on vlan 2 across the bridge? If you can, see if you can remote into anything on the other side of the bridge, and then telnet from that device (workstation)...

[ChuckHaynes]

The remote side doesn't have any devices yet :(

So since the remote switch still shows under cdp neighbors, how is that information coming through? Is it still being passed by VLAN1 (even though it's shutdown)? Also, we have VTP domain enabled on these switches - I'm not sure if that could help at all.

[John Blakley]

If you look at "show cdp neighbor detail", it should tell you what vlan it's coming over. It may not be coming over vlan 1.

[ChuckHaynes]

I did check that. That's where it says Native VLAN1 (mismatch).

[John Blakley]

Native vlan 1 mismatch usually indicates that there's a different native vlan on the trunk. Do you have the native configured as 1 on the main side and maybe 2 on the other or vice versa? At this point, I'm not sure you're going to be able to get around it outside of reloading the switch.

[ChuckHaynes]

Some additonal info...

VLAN1 is the Native VLAN on both switches. We were trying to get the Voice VLAN to pass through the wireless bridges, but were having difficulty (for whatever reason, they went with some Plant Networking units instead of Cisco Aironet?!). At first, we tried trunking the ports on both switches, but that didn't work. The port on the local switch looks like this:

interface FastEthernet0/24
 switchport access vlan 2
 switchport mode access
 switchport voice vlan 3
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable

The port on the remote switch looked the same, until the command "no switchport mode access" was issued. After that, we lost access...

[John Blakley]

Okay...I think that makes more sense. When you did "no switchport mode access", it may have switched to trunk (I can't reproduce this in a lab on the version I have). The trunk native vlan would be 1, but your access port on the other side makes the untagged vlan 2. You can make the same change on this side, and you should be able to get back into the switch.

If you do, and the port above is the one connected to the bridge, you should change the port type to trunked and allow 1,2, and 3 over the trunk. That should fix your voice vlan issues as well.

HTH,

John

[ChuckHaynes]

I did a "no switchport mode access" on the local switch. Now when I do a "sh cdp neighbors detail" is says Native VLAN 1 (without saying Mismatch) - however, I still can't ping/telnet the remote switch. I did a "shut" and then a "no shut" on the port just to be sure. Also, now I can't access the two wireless bridges that connect the two switches.

[John Blakley]

Okay. So I can assume the bridge is configured for vlan 2? If that's the case, you probably won't be able to get to the other side without reloading the switch. You can put the port back to an access of vlan 2, but if you want your voice traffic to go over the bridge, and you have the bridge on vlan 2, you can keep the port as a trunk:

Try this:

int fa0/24

switchport mode trunk

switchport trunk native vlan 2

This will change the native vlan to 2. See if you can ping the bridge after doing this.

[ChuckHaynes]

Yes, the bridges are configured for VLAN2. The port now looks like this and I can ping the bridges:

interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 2
 switchport mode trunk
 spanning-tree bpdufilter enable
 spanning-tree bpduguard enable

I will see about contacting someone in that area, and having them go to the location and power cycle the switch.

[ChuckHaynes]

Ok, the remote switch has been power cycled. I have access to it again. I don't think it will allow the exact same config as the local switch (as the the local is a 3560 and the remote is a 2960). It's doesn't like the "switchport trunk encapsulation dot1q" command.

EDIT: Ok, apparently it onlys supports dot1q, therefore you don't need to specify it.