VLAN.dat and Management VLAN Access

[Jason.Stinnett_2]

I'm not fully understanding this one but, hopefully one of the Gurus can explain this to us. I had two switches, one that we had on the network prior (swA) and one brand new out of the box (swN). swA we brought back to the shop, formatted NVRAM and threw a new configuration on it for a different building. We installed it and everything worked accordingly.

With swN, we proceeded to put a new configuration on it, a mirror of the configuration on swA, with the exception of name and Management VLAN IP. We installed it in a separate building, users and printers were able to access network resources and such but, we could not access the switch remotely. We reviewed the configuration several times over but nothing was dissimilar except that the vlan.dat file was missing. We copied over the vlan.dat file from swA and immediately we were able to access the switch through the Management VLAN IP remotely.

What is the specific reason that it would require the vlan.dat file to access the switch remotely? It passed all traffic; user, printer vlans, trunked traffic to attached switches, but no remote access.

A partial config:

no service pad

service password-encryption

!

hostname swN

!

boot-start-marker

boot-end-marker

!

ip subnet-zero

no ip source-route

no ip gratuitous-arps

no ip domain-lookup

!

errdisable recovery cause bpduguard

errdisable recovery cause psecure-violation

!

!

vlan internal allocation policy ascending

!

ip tcp synwait-time 10

ip tcp path-mtu-discovery

ip tftp source-interface Vlan10

!

!

interface GigabitEthernet1/0/1

description <== D1 ==>

switchport trunk encapsulation dot1q

switchport trunk native vlan 900

switchport trunk allowed vlan 3-1005,1025-4094

switchport mode trunk

switchport nonegotiate

spanning-tree portfast disable

spanning-tree guard loop

!

interface GigabitEthernet1/0/2

description <== sw48 B ==>

switchport trunk encapsulation dot1q

switchport trunk native vlan 900

switchport trunk allowed vlan 3-1005,1025-4094

switchport mode trunk

switchport nonegotiate

spanning-tree portfast disable

spanning-tree guard loop

!

interface Vlan1

description <== DO NOT USE/SECURITY VIOLATION ==>

shutdown

!

interface Vlan20

description <== MANAGEMENT VLAN ==>

ip address 10.5.1.39 255.255.254.0

no ip redirects

no ip unreachables

no ip proxy-arp

no ip route-cache

no ip mroute-cache

!

interface Vlan98

description <== Ver 5.0 Access Switch 3750-24TS ==>

no ip address

shutdown

!

interface Vlan99

description <== 3750 v3.3 ==>

no ip address

shutdown

!

ip default-gateway 10.5.0.1

ip classless

no ip http server

no ip http secure-server    

[Peter Paluch]

Hello Jason,

I am not quite sure what could have happened. By copying the vlan.dat file to the new switch, you have essentially copied the entire VLAN database and VTP settings to the second switch, thus making its VLAN database synchronized with the first switch and making it equivalent within the VTP protocol to the first switch.

You have noted that the vlan.dat file was not created on the second switch. Assuming that you have configured your trunk links properly, the VTP should have propagated the VLAN database to the second switch - but according to you, it did not. Are you using password protection in your VTP domain? Try running the command show vtp password on your first switch. If there is indeed a password configured then the second switch was not able to actually learn the VLAN database because of missing password. By copying the vlan.dat, you would have transferred all VLAN/VTP settings to the second switch, including the VTP password.

The fact that some of your VLANs were accessible on the second switch can be attributed to the fact that it probably contains access ports configured into a particular access VLAN - and whenever you assign an access port to an access VLAN, it will be created automatically (unless your switch is in VTP Client mode). So despite synchronizing its VTP database with the first switch, your second switch already knew about some of the VLANs you are using, and that is probably the reason why it passed ordinary user traffic. Your management VLAN 20, on the other hand, probably does not contain any access ports and thus was not created when you configured the SVI "interface VLAN 20" for it, thus it was not operational. Only after copying the vlan.dat over to the second switch, you've made its VLAN database complete.

That's my guess...

Best regards,

Peter

[glen.grant]

    If what you have shown is most of what you pasted in then I don't see any layer 2 vlans created which means either the switch is in server mode and the layer 2 info will not show in the config . The layer 2 info will show if the switch is in transparent mode.   If so if no layer 2 vlans were created then the only thing in the vlan.dat file would be vlan 1  so none of the other vlans would be in there .  Creating the layer 3 SVI does not create the layer 2 vlan . Once you copied the vlan.dat file it would have the required vlans and it would work .

[Jason.Stinnett_2]

Appreciate the responses; which are really filling in the blanks for me. Just to note, I didn’t paste the entire config for simplicity. The other ports are used for user and printer vlans. None of which are assigned to the Management Vlan. From Gi 1/1, we have a 6500 used as the internal router and VTP server. The 6500 is remotely managed from another site and in checking with them, yes there is a password set. With that question answered, it brings me to one other. I thought if the VTP domain setting is null, it inherits the VTP and Vlan information from the VTP server?

[Peter Paluch · Accepted solution]

Hi Jason,

I thought if the VTP domain setting is null, it inherits the VTP and Vlan information from the VTP server? 

Yes but only if the switch is in VTP Server or Client mode and the VTP domain is not password protected. If the domain is password protected then, obviously, an erased switch cannot know the password and therefore cannot actively cooperate in any VTP domain operations, including learning the domain name and/or its contents. Moreover, you cannot configure a VTP password if the domain name is null.

To put it shortly, if your VTP domain is not password-protected then an erased switch with its VTP domain name being null will learn both the VTP domain name and its contents. If your VTP domain is protected by a password then you first have to configure both the correct VTP domain name and password. Only then the switch will synchronize its remaining VTP and VLAN settings with the domain.

Best regards,

Peter

[Jason.Stinnett_2]

Okay, I get it now.  Thanks for clarification.