VTP: VLANs That Never Reach the Other Switch
The trunk is up, the VLANs exist on one switch, and the other has never heard of them. Fix the domain, then find out why that alone is not enough, live, right below.
Symptom
One switch has the VLANs, the other has never heard of them, and the trunk between them is perfectly healthy. Fix the domain, then work out why that alone changes nothing.
Your mission
Prove the cause, then fix it
Format
Guided CLI investigation
Investigate before you configure.
Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.
Observe the symptom and link state.
Diagnose by comparing the protocol evidence.
Verify the expected device state and confirm the original symptom is resolved.
Console access: SW1 · SW2
This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.
Need a hint?
Reveal the root cause when you're ready.
Try the investigation first, then use this as your escape hatch, not a dead end.
Lab debrief
Turn the session into a repeatable troubleshooting pattern.
Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.
The problem
VLANs 10 and 20 were created on SW1, a VTP server. SW2 is also a VTP server, the 802.1Q trunk between them is up and forwarding, and SW2's VLAN database still contains nothing but the defaults.
What you'll practice
- Compare VTP status between two switches and spot the field that must match
- Understand that a mismatched domain causes advertisements to be discarded unread
- Read the configuration revision and understand what raises it
- Learn that joining the correct domain does not retroactively pull the database
- Trigger a synchronisation by changing the database on the server
The topology
Two VTP servers joined by a single 802.1Q trunk, with the user VLANs defined on one of them only.
Commands to run yourself
The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.
show vtp statusshow vlan briefshow interfaces trunkTopology diagram
Frequently asked
Why does a VTP domain mismatch fail silently?
The domain name is checked before anything else in the advertisement. If it does not match, the frame is discarded without the revision number or the VLAN list ever being examined, so there is no error, no log entry on the receiving switch, and no clue in the VLAN database. The only place the mismatch shows is show vtp status on both switches, side by side.
I fixed the domain and the VLANs still have not appeared. Is something else wrong?
No, and this is the part worth remembering. A VTP server advertises when its database changes, not when a new switch starts listening. Joining the domain only means future advertisements will be accepted. Until something changes on the server, or the next periodic advertisement happens to arrive, the newly joined switch sits at its own revision with its own VLAN list. Creating or deleting a VLAN on the server sends the database immediately.
Is it safe to add a switch to an existing VTP domain?
Only if you check its configuration revision first. A switch joining with a higher revision number than the servers already in the domain will have its database accepted as the newer one, which can delete VLANs across the whole domain. Resetting the revision, by switching the device to transparent mode and back or by changing its domain name, is the standard precaution before plugging in a switch that has been used elsewhere.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.