The VLAN mismatch is a deceptively quiet fault in mixed-vendor networks. Cisco and Arista trunks may pass some traffic while dropping specific VLANs. The link remains up, counters stay clean, and CDP and LLDP still resolve neighbors correctly. The symptom can resemble congestion, routing trouble, or a QoS issue. A disciplined check of the per-VLAN state separates those explanations from the actual trunk configuration problem.
After working through this diagnosis across mixed-vendor networks, we use a consistent sequence. Here it is.
How Partial VLAN Faults Stay Hidden
A basic trunk mismatch is easy to spot: the port becomes err-disabled or falls back to access mode, traffic stops, and the cause is apparent. Because it creates a hard failure, this form is usually found quickly.
The difficult case is partial disagreement. Most VLANs in the allowed list match, while one or two do not. Those VLANs are dropped silently, but correctly configured traffic continues. The port remains up, both devices report an established trunk, and STP remains stable for the working VLANs. Only a per-VLAN allowed-list check exposes the fault.
Cisco and Arista differ in several small but important trunk behaviors and status displays. DTP negotiation defaults are not the same, and per-VLAN pruning does not map identically to the allowed list. A VLAN added independently during a change window can therefore diverge through a one-character typo or differently expanded range, remaining unnoticed until that VLAN carries traffic.
Selecting the Suspect Trunk
First identify the trunk worth inspecting. Affected traffic points toward a VLAN or VLAN range. Confirm the VLAN assignments of the impacted endpoints, then trace their path toward the distribution or core layer.
With a candidate VLAN identified, list the trunks along its path that could carry it. A Cisco-to-Arista boundary deserves priority because it is the most likely mismatch point. Begin there.
On Cisco, inspect show interfaces trunk, especially the "VLANs allowed and active in management domain" line for the interface. This is the effective list after DTP and VTP pruning. Compare it with the configured allowed list. A difference means DTP or VTP is modifying the intended policy and needs separate investigation.
On Arista, show interfaces trunk is similar, though formatted differently. Focus on "Vlans in spanning tree forwarding state and not pruned" and the per-VLAN STP state, not only the allowed list. A VLAN can be allowed yet "not in STP" when it exists locally but is not active globally. That points to a missing VLAN definition on Arista, not a trunk error.
Match the Effective VLAN Sets
Now compare the effective forwarding lists for the VLANs showing loss. The task is simple in principle, but large ranges make manual comparison error-prone.
Capture the allowed-and-active lists from both devices as text and compare them. Since Cisco and Arista format the output differently, first convert each list to sorted, one-VLAN-per-line text. Any VLAN appearing on only one side is a mismatch candidate. Compare those candidates with the VLANs used by the affected traffic.
Confirm a suspected mismatch before changing anything. Retrieve both interface configurations and check whether the missing VLAN appears in the configured allowed list on the side where it is absent operationally. If not, the configuration is wrong. If present, investigate the gap between configuration and state, including VTP pruning, mismatched STP settings, or a VLAN missing from the switch's global database.
Cisco VTP State and VLAN Availability
When Cisco switches operate as VTP clients, the VTP domain determines the effective VLAN set, not local interface configuration alone. This frequently creates partial mismatches with an Arista switch that does not participate in VTP.
On a Cisco VTP client, a VLAN added to the domain may not reach the switch if synchronization failed. It can still appear in the trunk's allowed list while remaining absent from the operational database. Check show vtp status and show vlan brief. If the VLAN is missing from show vlan brief, it is not operational there, regardless of the trunk configuration.
Arista uses VTP transparent mode by default: it forwards VTP frames without joining domain synchronization. Its VLAN definitions are local. Thus, when a VLAN appears in both trunk configurations but is active only on Arista, the Cisco VTP client may not have received the definition.
Apply the Change, Then Prove It
Once the offending VLAN is known, match the remedy to the cause. Add it to the missing trunk's allowed list for a simple omission. For a VTP issue, check the domain state and force synchronization if appropriate, or add the VLAN locally on the VTP client when VTP is not working in that environment.
Afterward, check both configuration and operational state. show interfaces trunk should place the VLAN in the "active and not pruned" category on each end. Then send test traffic from an endpoint in that VLAN and confirm it crosses the trunk without loss.
Intermittent symptoms can make validation difficult. If the loss was too rare to reproduce before the change, monitor through an equivalent observation window afterward. Compare interface error counters and per-VLAN traffic totals before and after. Those baselines are more dependable than waiting for the original symptom. This method confirms the trunk path, but it cannot explain loss caused elsewhere in the network.
Keep Trunk State Aligned
Partial mismatches usually enter during change windows when VLAN additions reach devices one at a time. The exposure lasts from the first device change until the second device is updated.
For time-sensitive production traffic, coordinate both changes as closely as possible. If a brief mismatch is acceptable, add a post-change check that compares per-VLAN operational state on every modified trunk. It can be scripted through the respective APIs on Cisco and Arista, comparing current output with a known-good state. That catches multi-week bugs in the same session. This reduces detection time, but does not replace validation of endpoint and application behavior.