Not sure which switch is indicating the native vlan mismatch, but here's a high level overview of whats going on...
With the 802.1q trunk specification, vlan1 is the native VLAN that carries the tagged VLAN data between switches. Sounds like this has been changed on one end of the trunk link between 2 (or more) switches. If so, reset the trunk to its default (interface level command) or set the native vlan on the other end of the dot1q trunk to match that of the other switch.
When I first ran into the Native VLAN Mismatch problem, I had overlooked one minor but not obvious requirement for setting up the connection.
The ports that are trunking the vlan must be in the same vlan. For instance, if you are trunking vlans between port one on two switches, both ports on each switch must be assigned to the same vlan. I tried to set up a trunk between a port in vlan 1 and a switch with the port in vlan 10. I wanted all the ports on one switch to be in vlan 10. But, I had to assign the port connecting to the other swithch to vlan 1 so that both ends of the trunk were in vlan 1. Problem went away as soon as I corrected the vlan port assignments.
And just to add to the above responses.... you can have two ports adjacent to each other that are not in the same VLAN under the condition that the ports are L3 and not L2 (i.e. no switchport). Basically, this is the same as plugging in two routers.
You'll still get the annoying native VLAN mismatch errors if CDP is active on the adjacent ports. In this scenario it is prudent to turn off CDP on those links (since they're L3 only) and it will stop the messages.
Got it fixed. Thanks for all help. What it end up to be is that I just had to configure the 35xx switch's gigabit ports (trunk ports) to run switchport trunk native vlan 2 ( The vlan we configuded for native). Then everything started to work. Thanks for the tips and advice.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...