Native_vlan_mismatch

itdaddyitdaddy Member Posts: 2,089 ■■■■□□□□□□
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?

Comments

  • shortstop20shortstop20 Member Posts: 161 ■■■□□□□□□□
    Simple, change the native VLAN on your side of the link so it matches.
    CCNA Security - 6/11/2018
    CCNP TShoot - 3/7/2018
    CCNP Route - 1/31/2018
    CCNP Switch - 12/10/2015
    CCNA R/S - 1/14/2015
  • itdaddyitdaddy Member Posts: 2,089 ■■■■□□□□□□
    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 ;)
  • IristheangelIristheangel Mod Posts: 4,133 Mod
    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)
    BS, MS, and CCIE #50931
    Blog: www.network-node.com
  • techfiendtechfiend Member Posts: 1,481 ■■■■□□□□□□
    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.
    2018 AWS Solutions Architect - Associate (Apr) 2017 VCAP6-DCV Deploy (Oct) 2016 Storage+ (Jan)
    2015 Start WGU (Feb) Net+ (Feb) Sec+ (Mar) Project+ (Apr) Other WGU (Jun) CCENT (Jul) CCNA (Aug) CCNA Security (Aug) MCP 2012 (Sep) MCSA 2012 (Oct) Linux+ (Nov) Capstone/BS (Nov) VCP6-DCV (Dec) ITILF (Dec)
  • IristheangelIristheangel Mod Posts: 4,133 Mod
    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 icon_sad.gif. 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.
    BS, MS, and CCIE #50931
    Blog: www.network-node.com
  • itdaddyitdaddy Member Posts: 2,089 ■■■■□□□□□□
    wow great info love talking to CCIEs haha thanks man.!
  • techfiendtechfiend Member Posts: 1,481 ■■■■□□□□□□
    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.
    2018 AWS Solutions Architect - Associate (Apr) 2017 VCAP6-DCV Deploy (Oct) 2016 Storage+ (Jan)
    2015 Start WGU (Feb) Net+ (Feb) Sec+ (Mar) Project+ (Apr) Other WGU (Jun) CCENT (Jul) CCNA (Aug) CCNA Security (Aug) MCP 2012 (Sep) MCSA 2012 (Oct) Linux+ (Nov) Capstone/BS (Nov) VCP6-DCV (Dec) ITILF (Dec)
  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    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
    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
  • Danielh22185Danielh22185 Member Posts: 1,195 ■■■■□□□□□□
    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.
    Currently Studying: IE Stuff...kinda...for now...
    My ultimate career goal: To climb to the top of the computer network industry food chain.
    "Winning means you're willing to go longer, work harder, and give more than anyone else." - Vince Lombardi
  • IristheangelIristheangel Mod Posts: 4,133 Mod
    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.
    BS, MS, and CCIE #50931
    Blog: www.network-node.com
  • shortstop20shortstop20 Member Posts: 161 ■■■□□□□□□□
    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.
    CCNA Security - 6/11/2018
    CCNP TShoot - 3/7/2018
    CCNP Route - 1/31/2018
    CCNP Switch - 12/10/2015
    CCNA R/S - 1/14/2015
  • Danielh22185Danielh22185 Member Posts: 1,195 ■■■■□□□□□□
    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.
    Currently Studying: IE Stuff...kinda...for now...
    My ultimate career goal: To climb to the top of the computer network industry food chain.
    "Winning means you're willing to go longer, work harder, and give more than anyone else." - Vince Lombardi
  • stlsmoorestlsmoore Member Posts: 515 ■■■□□□□□□□
    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.
    My Cisco Blog Adventure: http://shawnmoorecisco.blogspot.com/

    Don't Forget to Add me on LinkedIn!
    https://www.linkedin.com/in/shawnrmoore
  • IristheangelIristheangel Mod Posts: 4,133 Mod
    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
    BS, MS, and CCIE #50931
    Blog: www.network-node.com
  • joelsfoodjoelsfood Member Posts: 1,027 ■■■■■■□□□□
    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.
  • techfiendtechfiend Member Posts: 1,481 ■■■■□□□□□□
    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?
    2018 AWS Solutions Architect - Associate (Apr) 2017 VCAP6-DCV Deploy (Oct) 2016 Storage+ (Jan)
    2015 Start WGU (Feb) Net+ (Feb) Sec+ (Mar) Project+ (Apr) Other WGU (Jun) CCENT (Jul) CCNA (Aug) CCNA Security (Aug) MCP 2012 (Sep) MCSA 2012 (Oct) Linux+ (Nov) Capstone/BS (Nov) VCP6-DCV (Dec) ITILF (Dec)
  • IristheangelIristheangel Mod Posts: 4,133 Mod
    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.
    BS, MS, and CCIE #50931
    Blog: www.network-node.com
Sign In or Register to comment.