Can a VTP client overwrite a VTP server's VLAN database? Yes—in VTP versions 1 and 2, a client with a higher configuration revision can cause other participating switches to replace their VLAN database when the domain and configured password match. Client mode prevents local VLAN editing; it does not make a switch harmless to the rest of the domain.[8]
Why client mode is not protection
A VTP server can create, rename and delete VLANs locally, while a VTP client cannot perform those local edits.[6] Both modes exchange VTP information over trunks and synchronize with accepted advertisements; a server is not an authoritative master merely because its mode says Server.[6]
For VTP v1/v2, the revision number tells a receiving switch whether advertised VLAN information is newer than its own.[6] It is a configuration version counter—not a device priority, trust score or proof that a database is correct.
This explains the interview trap: permission to edit locally and ability to distribute an existing database are different things. A switch that already holds an unwanted database can affect the domain even when it is now a client.[8]
VTP modes and the version boundary
| Mode or version | Local VLAN editing | What matters for this question |
|---|---|---|
| VTP v1/v2 server | Allowed | Can accept a newer database; server mode does not protect it from a higher-revision client.[6][8] |
| VTP v1/v2 client | Not allowed | Still exchanges updates; check its revision before connecting it.[8][12] |
| Transparent | Local edits allowed | Does not synchronize its own database through received advertisements; forwarding behavior depends on the version and platform.[6][12] |
| Off, where supported | Local VLAN management | Unlike transparent mode, does not forward VTP advertisements on trunks.[12] |
| VTP v3 primary server | Authorized database changes | Uses a primary/secondary server model rather than the v1/v2 editing model.[12] |
Do not apply the v1/v2 “highest revision wins” explanation unchanged to VTP v3. Version 3 identifies a primary server for database updates, and its advertisements include a primary server ID and additional instance information.[12] On the documented Catalyst platform, primary status is lost after a reload, switchover or domain-parameter change; a domain can still operate without a primary until an administrator needs to make database changes.[12]
My operational recommendation: use a reviewed VTP v3 design on supported equipment if centralized VLAN distribution is required, or deliberately choose local VLAN management rather than relying on accidental defaults.
A simple higher-revision scenario
The following is a fictional VTP v2 example, not output from an executed switch lab. Assume matching domain CAMPUS-LAB, compatible settings, valid authentication and a working trunk. The table lists only user-created VLANs, not reserved/default VLANs.
| Switch before connection | Mode | Revision | User-created VLANs |
|---|---|---|---|
| Distribution switch | Server | 12 | 10, 20, 30 |
| Reused lab switch | Client | 45 | 10, 99 |
Under those assumptions, the client can supply the higher-revision database, replacing the server's existing VLAN information rather than safely merging the two intended designs.[8] For this illustrative database, VLANs 20 and 30 would be absent afterward, while VLAN 99 would be present.
The lesson is not “clients create VLANs remotely.” It is “an already-held database can be accepted as newer.”
Advertisement and update flow
A simplified request-driven VTP v1/v2 exchange looks like this; summary advertisements can also be accompanied directly by subset advertisements.[6]
- A switch receives a summary advertisement containing the domain and revision.[6]
- For an established matching domain, it compares the advertised revision with its local revision.[6]
- When it learns of a higher revision and needs the database contents, it sends an advertisement request.[6]
- The response contains a summary and one or more subset advertisements, which carry VLAN information.[6]
- With valid matching settings, the participating receiver updates its database; being a server does not exempt it from this synchronization.[6][8]
VTP handles VLAN database distribution, not the complete switch configuration; its advertised VLAN fields include identifiers, names, types and states.[12] As a troubleshooting practice, check port assignments, trunk configuration and forwarding separately rather than treating a synchronized database as an end-to-end connectivity test.
What to check before connecting a reused switch
Keep the candidate switch physically isolated from production trunks during preparation. Use a console or a separate management path, collect a backup of the intended production VLAN database, and follow the procedure for the exact platform and release.
These are read-only verification commands used in Cisco's VTP documentation; their available fields vary by release.[8][12]
show vtp status
show vtp counters
show vlan brief
For a supported VTP v3 platform, also examine known devices and primary-server conflicts.[12]
show vtp devices
show vtp devices conflict
Suggested connection checklist:
- Running version: read the version actually running, not only the “version capable” field.[8]
- Mode and domain: confirm the intended participation and exact domain name.[8]
- Authentication: verify matching configured credentials through an approved process; do not paste secrets into tickets or public output.[8]
- Revision for v1/v2: reset the isolated candidate to revision 0 using the supported procedure, then verify the result before connection.[8]
- Database contents: compare the intended VLAN IDs and names, not just the total VLAN count.
- After connection: repeat the checks on both the candidate and a known-good participating switch, then test representative endpoints.
How do you reset the VTP revision safely?
Cisco documents changing the VTP domain name and then restoring the original name as a revision-reset method, with verification through show vtp status.[6][12]
Treat this as a platform-specific preparation procedure for an isolated candidate, not a blanket fix to run across production.
Do not assume that switching to client mode or saving the running configuration proves that the revision is safe. Verify the displayed result before enabling the trunk; Cisco explicitly requires the revision check for v1/v2 clients as well as servers.[8]
Troubleshooting missing VLANs after a switch was added
My suggested triage order is containment, evidence, then controlled recovery:
| Observation | First investigation | Avoid |
|---|---|---|
| VLANs disappear soon after a new trunk comes up | Compare VTP version, domain, revision and VLAN lists with the pre-change records | Making more VLAN changes before identifying the source |
| Candidate does not learn expected VLANs | Check version, domain, authentication, mode and trunk connectivity.[8][12] | Repeatedly changing settings on multiple switches at once |
| Digest-error counter increases | Investigate authentication and database consistency; collect status and counters.[8] | Assuming that every failure is an STP problem |
| VTP v3 rejects a planned database edit | Check primary-server state and any conflicts.[12] | Using a forced takeover as a routine troubleshooting shortcut |
| Database looks correct but endpoints still fail | Verify access-port VLAN, trunk forwarding, STP and the relevant Layer 3 path | Declaring success from revision agreement alone |
For a suspected bad update, use the approved incident procedure to isolate the new participant while preserving management access and evidence. Restore from a known-good VLAN inventory through a controlled recovery plan; do not improvise by increasing revision numbers on several switches.
Common interview pitfalls
- “Only a server can send an update.” Clients also transmit and receive VTP updates on trunks.[12]
- “A higher revision means the better configuration.” The revision is used to determine newer information, not whether it matches the intended design.[6]
- “Server mode always wins over client mode.” That is false for the v1/v2 higher-revision case.[8]
- “Transparent means a VTP firewall.” Transparent mode can forward advertisements without applying them locally; off mode has different forwarding behavior.[12]
- “VTP v2 fixes this risk.” Cisco's revision warning explicitly covers versions 1 and 2.[8]
- “The same rule applies to every VTP version.” Version 3 adds primary-server control and additional advertisement fields.[12]
A concise interview answer
“Yes, in VTP versions 1 and 2, a client with a higher configuration revision can overwrite the VLAN database on servers and other participating switches when domain and authentication settings match.[8] Client mode prevents local VLAN changes but does not prevent the switch from exchanging updates.[12] I would inspect the actual running version, domain, mode and revision, reset a reused v1/v2 switch's revision while isolated, and verify it before connecting a trunk.[8] For VTP v3, I would explain the primary-server model separately.”[12]
Optional isolated lab
Use disposable, isolated virtual or physical switches that support the selected VTP version. Do not bridge the lab to a production or home-management VLAN.
Suggested exercise: create a known-good v2 database on one switch, prepare a different higher-revision database on a second switch while it is a server, change the second switch to client mode, and record its actual revision before connecting the lab trunk. Predict the resulting database, capture status and counters, and compare the observation with your prediction. If the platform resets state during a mode transition, document that instead of assuming the fictional example must occur.
This is a proposed experiment, not a claim that a lab was executed for this article.
Related reading
- MSTP region parameters: name, revision, VLAN mapping and digest
- STP vs RSTP port states and roles
- BPDU Guard vs BPDU Filter vs Root Guard vs Loop Guard
Summary
For the classic v1/v2 interview question, the answer is yes: client mode does not protect the domain from an accepted higher-revision VLAN database.[8] Version 3 requires a separate explanation of primary-server authority.[12]
Preparing for a network engineering interview? Practice the short answer, then explain which checks you would complete before connecting a reused switch—and why the version must come first.
Sources
- [6] https://www.cisco.com/c/en/us/support/docs/lan-switching/vtp/10558-21.html
- [8] https://www.cisco.com/c/en/us/support/docs/lan-switching/vtp/98154-conf-vlan.html
- [12] https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/vlan/b_1715_vlan_9300_cg/configuring_vtp.html
Post a Comment