I have 2 4006's in the same vtp domain and I have configured about 8 vlans on both. When I do a 'show vtp domain' command I can see that on both switches the Config Rrevision # is still set @ ZERO (0). Both are set to server mode. <----- is that the problem (Should I have one as client) Right now those 2 are the only ones in that particular VTP domain. The fact that the config revision # in not increasing concerns me because if I introduce a smaller switch with a higher revision number that switch may become the the vtp root? Can anyone help me out with this one????
Re: 4006 config revision # increments on vtp domain
Is your trunk link(s) ISL or dot1q?
Having 2+ VTP servers isn't a bad thing/not a problem (it's common). Whenever you make a vlan change (add/delete a vlan) on a VTP server, the switch issues VTP messages so that other switches can update their vlan configs. With a fresh config the revision number is 0. It increments until it hits a huge number (2 billion or something) then it counter wraps back to 0. You can reset the revision number with the "set vtp domain xxxx" command.
Add a vlan and see if the number increments. Use the commands "show vtp stat" and "show vtp domain".
If it doesn't increase, make a vlan change and put a sniffer on the trunk link to see the VTP packets, look at the sniffer output to see if the revision number is there (it should be, along with the time of the change, and other info).
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...