Troubleshooting Native VLAN Mismatch and Missing VLAN Issues in Cisco-Meraki Hybrid Networks


4 views

When examining this Cisco-Meraki hybrid network setup, several configuration irregularities stand out that could lead to potential network issues:

// Problematic Interface Configuration Example
interface GigabitEthernet1/0/24
 description Uplink
 switchport access vlan 100  // Conflict with trunk native vlan
 switchport trunk native vlan 2

The current implementation shows inconsistent port channel configurations across different ESXi host connections. For Cisco switches, physical interfaces in a port channel should inherit their configuration from the port-channel interface itself:

// Correct Port Channel Configuration
interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100,101,172,192
 switchport mode trunk
 switchport nonegotiate
 spanning-tree portfast trunk

interface GigabitEthernet1/0/1
 channel-group 1 mode active  // Preferred over 'on' for dynamic negotiation

The critical issue between the Catalyst 3750x and Meraki MS42 lies in their native VLAN configuration:

  • Catalyst: Native VLAN 2 (VLAN 100 as access)
  • Meraki: Native VLAN 1 (all VLANs allowed)

To properly fix this, we should standardize the native VLAN configuration:

// Corrected Uplink Configuration (Catalyst Side)
interface GigabitEthernet1/0/24
 description Uplink-to-Meraki
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 100  // Matching operational VLAN
 switchport trunk allowed vlan 100,101,172,192
 switchport mode trunk
 no switchport access vlan  // Remove conflicting access mode

The current setup allows VLAN 100 traffic to pass despite the apparent configuration issues because:

  1. The access vlan 100 configuration on the Catalyst uplink port creates an implicit trunk for VLAN 100
  2. The Meraki's "allow all VLANs" setting permits the tagged traffic
  3. VLAN 1 becomes the fallback for untagged traffic

For production environments, we should implement this cleaner approach:

// Recommended Meraki Switch Configuration
  - Native VLAN: 100 (matching Catalyst)
  - Allowed VLANs: 100,101,172,192 (explicitly defined)
  - Remove VLAN 2 unless specifically required

When modifying this configuration, consider these operational aspects:

  • Schedule changes during maintenance windows as VLAN reconfiguration may cause brief outages
  • Verify VMware vSwitch configurations match the new network settings
  • Update documentation to reflect the standardized VLAN approach

The final configuration should eliminate the current hybrid access/trunk mode and establish consistent VLAN tagging throughout the network path.


Examining this hybrid Cisco-Meraki setup reveals several configuration anomalies that could impact network performance and security. The most notable issues appear in the Port-Channel configurations and uplink settings between the Catalyst 3750x and Meraki MS42.

// Problematic configuration example
interface Port-channel1
 switchport access vlan 100  // This is ineffective
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100,101,172,192
 switchport mode trunk       // Overrides access mode
 switchport nonegotiate
 spanning-tree portfast trunk

The simultaneous presence of switchport access and switchport mode trunk commands creates confusion. In Cisco IOS, the last configured mode takes precedence, making the access mode configuration irrelevant.

The uplink configuration shows a critical mismatch:

// Catalyst side
interface GigabitEthernet1/0/24
 switchport access vlan 100
 switchport trunk native vlan 2  // Native VLAN 2 configured

// Meraki side
Trunk port using native VLAN 1; allowed VLANs: all

Despite this mismatch, VLAN 100 traffic somehow traverses the network. This occurs because:

  1. The Catalyst port is in access mode (despite the native VLAN setting)
  2. The Meraki accepts all VLANs, including tagged VLAN 100 frames
  3. Native VLAN mismatch only affects untagged traffic

For proper VLAN handling:

// Correct Port-Channel configuration
interface Port-channel1
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 100  // Consistent native VLAN
 switchport trunk allowed vlan 100,101,172,192
 switchport mode trunk
 switchport nonegotiate
 spanning-tree portfast trunk

// Correct Uplink configuration
interface GigabitEthernet1/0/24
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 100  // Match native VLAN
 switchport trunk allowed vlan 100,101,172,192
 switchport mode trunk

When working with Cisco Port-Channels:

  • Configure VLAN settings at the Port-Channel level
  • Member ports should only have channel-group configuration
  • Avoid mixing access/trunk modes in member ports

For a cleaner implementation:

  1. Standardize on VLAN 100 as the native VLAN throughout
  2. Remove VLAN 2 unless specifically required
  3. Ensure consistent VLAN tagging across all devices
  4. Document VLAN purposes clearly (100=network, 101=vMotion, etc.)

The current setup works by coincidence rather than design. Implementing these changes will create a more predictable and maintainable network infrastructure.