Native_vlan_mismatch

itdaddy

hello guys,
what if you cannot control the other end and the vlan that is mismatched then what? I dont want this chatter in my logging files. how to remove without affecting my traffic flow? Do you guys know?

shortstop20

Simple, change the native VLAN on your side of the link so it matches.

itdaddy

thanks Okay I did think of that but just wanted to get some ideas since well it is production haahaha thanks man! I will risk it after house easy to role back

Iristheangel

Yeah , there are some potential security issues that could arise by leaving it on different native VLANs not to mention some unpredictable traffic flow (i.e. your native VLAN doesn't have a gateway or is shut down but their native VLAN sends traffic over it and expects to arrive at a destination)

techfiend

Speaking of native VLAN's, is it a big deal to leave the default VLAN as native?

Cisco study guides made it sound like it's a fairly big security issue. My new environment uses the default native VLAN and it would be quite a task to change it.

Iristheangel

VLAN 1 is used for certain control traffic (VTP, CDP, DTP, STP, etC) so you can't really shut it down. Even if you prune it on an trunk, it's still used on that trunk for some management purposes. What you have to worry about with native VLANs is issue with VLAN hopping attacks (double-tagged packets) and potential network instability if you have mismatching native VLANs on each side - seeing your MAC address table start to cycle between two different VLANs is never pretty to see . Technically, you'll get an error thanks to CDP for the Native VLAN mismatch but the trunk is still allowed to form.

Typically, the best practice is to either tag ALL packets with a "vlan dot1q tag native" command if the switches support it or change the native VLAN on all trunk ports to an unused VLAN and for good measure, I like to suspend that unused VLAN as well.

itdaddy

wow great info love talking to CCIEs haha thanks man.!

techfiend

Thanks Katherine! I see tagging native vlan will drop untagged frames which is probably preferable if all frames can be tagged. This place is a 24 hour place and I've been tasked with some pretty big network jobs that I've never performed, I really need to lab it.

Hondabuff

You should always change the native VLAN to something different like 99 or just match it. "Show interfaces trunk" is the command to find it out. If not, change the switch to VTP Transparent and change the VTP domain name and the CDP 4 message will go away. Most production environments don't use CDP either.

Most of my configs look something like this.

VLAN Name Status Ports
----

---

---

---

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/20
Fa0/21, Fa0/22, Fa0/23, Fa0/24
Gig0/1, Gig0/2
10 DATA active
55 VOICE active
99 TRUNK active
1002 fddi-default active
1003 token-ring-default active
1004 fddinet-default active
1005 trnet-default active

Switch(config)#int gigabitEthernet 0/1
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport nonegotiate
Switch(config-if)#switchport trunk native vlan 99
Switch(config-if)#switchport trunk allowed vlan 1,10,55,99

Switch(config)#spanning-tree vlan 1,10,55,99 root primary


Switch#sho interfaces trunk
Port Mode Encapsulation Status Native vlan
Gig0/1 on 802.1q trunking 99


Port Vlans allowed on trunk
Gig0/1 1,10,55,99


Port Vlans allowed and active in management domain
Gig0/1 1,10,55,99


Port Vlans in spanning tree forwarding state and not pruned
Gig0/1 1,10,55,99

Danielh22185

Yes defiantly match it to the other side if possible, you are at bigger risk leaving the potential open for double tagged packets like Iris mentioned. If you don't have access to the other side equipment its leaves me to believe it is some type of 3rd party equipment, which is even riskier if you do manage that equipment because now you have an outside device that could potentially VLAN Hop. You might want to let them know what you had to do to normalize the alarms on your device and if you guys have some agreed configuration standard you might want to look into what may have all of a sudden caused a change or for this to occur. It wouldn't hurt too to make sure your configs are intact as well

I also see this very often at my work. Many times a different group all together will turn-up a new platform of hardware and this is a commonly missed item or they have access to the equipment and make ADHOC changes themselves and I have to go back and correct it.

Iristheangel

Hondabuff wrote: »

Most production environments don't use CDP either.

This would probably be the only thing I would disagree with here. I think ever environment I've ever seen in every customer, client, etc has CDP running and hasn't changed it anywhere except *maybe* on the edge but even then, most of the time they forget to turn it off there.

shortstop20

I couldn't imagine turning off CDP in our campus environment. We have recently given our desktop techs LinkRunner's that can identify the switchport so that we could reduce the number of port change tickets our Network Team(including myself) had to go into the field and resolve ourselves.

I think disabling CDP is more security by obscurity than actual security.

Danielh22185

Agreed. My company contains a network of 50,000+ devices and we use CDP on probably 80% of all the devices. The only areas we don't use CDP is on DMZ environments or on non-cisco devices (LLDP ), which I would say is very common place for most large networks.

stlsmoore

Iristheangel wrote: »

This would probably be the only thing I would disagree with here. I think ever environment I've ever seen in every customer, client, etc has CDP running and hasn't changed it anywhere except *maybe* on the edge but even then, most of the time they forget to turn it off there.

Same here, especially for our Cisco VoIP sites but we do turn it off on our edge ports. We even utilize LLDP for our remote sites with 3rd party VoIP solutions but please don't ask why our Enterprise is a mixed VoIP vendor environment lol.

Iristheangel

Sounds about right, stlsmoore. Best practice is to turn it off on the edge to prevent certain information from being shared but even then, I see most companies forgetting to turn it or LLDP off there.

CDP and LLDP are great for troubleshooting or just the random network that no one decided to document (No documentation you say? That NEVER happens! *eyeroll*). Even if there are security concerns, I would probably fall on the side of keeping it enabled internally and using a TLV list to block certain sensitive information but I haven't come across anyone having an issue with keeping it on.

For anyone unfamiliar with creating and applying TLV lists, it's a fun little configuration: Cisco Discovery Protocol Configuration Guide, Cisco IOS XE Release 3S (Cisco ASR 1000) - Secure Cisco Discovery Protocol [Support] - Cisco

You aren't blocking or disabling CDP but you can block certain information from being passed such as the IOS version, address, etc which you might deem as a security risk being shared. Even with limited CDP information, it could still be useful for troubleshooting

joelsfood

While I see CDP all over, I will have to say that my current main job follows the no cdp on the network rule. Which yeah, makes things all kinds of fun when we have to troubleshoot issues with an undocumented site with no one local who knows what they're doing.

techfiend

I'll put changing native native vlan on the todo list. Will this cause network interruption?

I don't want to complicate the environment for no real reason, which I think the previous guy did by enabling jumbo frames on a gbit network. I can understand it being useful on 10 gbe. It didn't work on most of the LAN links that I've checked and disabled them, it was causing major issues on a few links. I've left it on the SAN links for now but undecided whether I should disable them. With LSO and TOE enabled network wide is there any reason for jumbo frames on a gbit mpio san?

Iristheangel

As far as a network disruptions with changing the native VLAN, it can be disruptive if your old native VLAN or the new one is carrying traffic.


As far as jumbo frames, enabling it network-wide is a little weird but I would make sure there isn't a reason for jumbo frames being enabled (1GB or not). For anyone who owns a copy of Network Warrior, check out Maxim #2 on page 708:

"For me to consider a change, it had to follow on of the three rules. The rules were:
- Simplify
- Standardize
- Stabilize"

I think Gary Donahue was spot on in that section

It's good that you're looking into it. A lot of networkers tend to just leave network as unchanged as possible and will err on the side of not optimizing it just because things "work" but that doesn't mean that there aren't issues lying in wait from not changing it. I say go for a balanced approach of looking for ways of optimizing your network, asking why things are configured a certain way and then taking that extra step of CYA to make sure that the change you make is really going to improve the network or optimize it. Did the previous gentleman leave any documentation? How is this change going to benefit this network in whole? This is definitely something you'll have to answer if you go through a change management process in your company or have to explain it to management.

I could definitely see it being used to optimize the transport for any block-storage being sent over ethernet (iSCSI, FCoE, FCIP etc) and certain applications prefer it as well. Before making any changing in your MTU because you don't see a reason for it, I would check the applications you're using in your network and ensure that there isn't a requirement for jumbo frames or a best practice for that application. Even beyond that, there are some network applications that won't function or work correctly without the MTU being adjusted. One that sticks out is OTV on the Nexus 7Ks. The 7Ks set the DF bit and if the patch can't accommodate that 42-byte additional header, it's going to be dropped. It's a bit of work to do this but it's a lot better than having a potential RGE down the road from making a change without understanding the ramifications.