non-Vlan1 interface down/down and no VTP info going thru

cnorton · ‎04-14-2007

Here is the situation:

One switch is configured as the VTp server witn interface VLAN 1 shutdown.

Other Vlans are configured on that switch, and one of the created Vlan is the new management Vlan (let's say vlan200).

Trunking is enable on the Gig interfaces (by the way this is a 3550 with 12.1 and I am not sure which one is the Native vlan on the trunk).

A VTP domain name has been configured and no vtp password

the vlans were not created using the vlan database config mode

Here is the problem:

When another switch is added to the network, the switch does not bring up its vlan interface (the one configured for vlan200, since vlan1 is admin down).

Here is what was done in chronological order to fix the issue but I need to understand why it worked. . . I have an idea but I want to be sure:

1. new switch comes online . . .

2. configured the VTP mode to client

3. configured the VTP domain name (no password set)

4. create an interface for Vlan 200 with an ip address that does not conflict with other any ip addresses on the vlan, and do a "no shut"

5. configured the Gig port for 802.1q encapsulation and trunking mode (the gig interface shows that it is up/up)

6. do a show vtp stat to ensure that the switch is learning the vlan . . . to no avail

7. checked the interface vlan 200 and it show down/down

8. delete the originally created vlan 200 interface

9. move the switch to vtp server mode

10. re-create the interface vlan 200 . . . which now shows up/up

11. check the vtp stats to make sure the switch has learned about the other vlans . . . which it has.

12. move the switch back to client mode

13. Done!

I am thinking this is due to vlan 1 (or native vlan) being disabled and 802.1q not passing VTP information. I have not had a chance yet to check if both ends of the trunk had Vlan 1 or 200 set as the native Vlan or if there was a mismatch, but so far that is my best guess. The only problem with this is that if there was a mismatch, shouldn't the trunk be in a down status as opposed to up/up?

What do you guys think?

Thanks for the help

glen.grant · ‎04-15-2007

The native vlans on each end must match for the trunk to work correctly . If you forced the trunk on , switchport port mode trunk its possible you had a physical link but the trunk was not working correctly thus it would not learn the vlans, this can happen if you choose to force the trunk link on instead of letting it negotiate the link (switchbport mode trunk). Before adding your new switch did you look at the server with the "show vlan" command ? Not the "show int vlan" command . All your vlans should show up and active if configured correctly.

3550

conf t

vlan 200

exit

interface vlan 200

no shut

ip address xxx.xxx.xxx.xxx

uplink to new switch

interface x/x (match both sides)

switchport trunk encapsulation dot1q

switchport trunk native vlan XX (this must match on both sides)

switchport trunk mode dynamic desirable

milan.kulik · ‎04-16-2007

Hi,

you are mixing L2 and L3 here.

VTP is a purely L2 feature.

So forget "int VLAN x", it has no impact on VTP functionality.

I think your problem was probably caused by a native VLAN mismatch.

Remember that VTP packets are always carried on VLAN 1.

So if VLAN1 is the native VLAN on the VTP server trunk side VTP frames are sent untagged to the trunk.

But if another VLANx is configured as native VLAN on the opposite trunk side, VLANx is receiving the VTP frames!

As no VTP frames are received in VLAN1 on the opposite trunk side, no VTP info is transferred through the trunk.

So you need a living trunk (either negotiated on non-negotiated) with the same native VLAN on both sides to make VTP working correctly.

(To be 100% precise: it might even work with a native VLAN mismatch, but VLAN1 must not be native on both sides in that case.)

See http://www.cisco.com/warp/public/473/21.pdf

for details.

Best regards,

Milan Kulik