[c-nsp] Question about setting up VTP

[Andre Beck]

On Sun, May 01, 2005 at 06:54:23PM -0400, Paul Stewart wrote:
> Why not bring them both up on transparent mode and then convert one to master,
> and then the other?  Would that not work around this for Jeff?

No, as soon as the second one is turned into a VTP Server, one of them
will lose the election and get overwritten by the other. The winner will
be the one with the higher revision number. If indeed both have a VLAN
database that doesn't match the other one's, without rebuilding the final
database on one of them and forcing that one to become the winner, you
will lose definitions. To force the winner you will need to bump the
revision number up high, which is easily done by creating each VLAN
on its own, applying the changes inbetween. Or just create and delete
a dummy VLAN some times repeatedly. Making the other switch VTP Client
can help preventing unwanted overwrites in the wrong direction, but
finally the revision number is the one item to fix - a Client with the
same or higher revision than the Server will not overwrite and, as soon
as propagated to Server, will kill the other box. I don't know about
Cat5ks but on the platforms I had do deal with VTP on, a well meant
"delete flash:vlan.dat" sometimes was the only thing to get clean start
conditions.

> Or, does the same rule apply in transparent mode?

No, VTP Transparent means the switch will behave as if it never heard
of the protocol called VTP, and thus, as VTP is a multicast, just
flood it. The problem is that it still has a VLAN database with a
revision bump and as soon as converted to Server, it could wreak
havoc to an existing VTP domain. Just assume it once was a Server
or Client and became converted to Transparent. Afterwards, VLANs were
created and removed on it as well as on others. When converting back
to Master, the one with the highest number of changes applied in the
highest granularity will end up as the winner as it happens to have
the highest revision number.

If you don't need VTP (as for instance you are following Ciscos current
design proposals of not spanning any VLAN to more than one access switch
at all) setting them all to VTP Transparent is the way to go. In a large
network based on campus spanning VLANs, though, the advantages of VTP
(helping you to have a synchronized VLAN database everywhere, if enabled
also having automatic pruning of VLANs from trunks) have to be traded
against the dangers. From a risk assessment standpoint, such designs
already involve and rely on STP - given that, VTP is not really that
much of an added risk anymore.

-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-