Actual purpose of native vlan in real network

Hi,
Somebody please explain me what is the actual purpose native vlan in real scenarios.I have ready many documents related native vlan and I know it will never tag the vlans.But I want to know in which situation configure native vlan in our real network.
thanks in advance..
Regards
Prajith

The native VLAN is simply tagged to all traffic on a trunk link that does not already have an 802.1q tag. Some people use this for security purposes setting the native VLAN to a VLAN that is shutdown/disabled so untagged traffic essentially gets dropped. Another application of where I've seen native VLANs used is on access point trunk ports where the management VLAN is set to native so the AP gets an IP address from it.

Similar Messages

Changing native vlan on running network

I want to change the native vlan on running network. a network include 30 switches . there is loop free topology .
unfortunately native vlan is vlan 1 and also management network .
in my test environment :
if I go to a switch and change native vlan from 1 to 100 the stp will Block the link for vlan 1 and i lose my access to the switch and then i should go to other side and change the native vlan to 100.
i just want to know the best practice for this situation.
Thanks !

Correct. As soon as you change it to 100, you will lose access to the devices since vlan 1 is used for management. To shorten the down time, you can create vlan 100 and all the SVIs on all switches ahead of time and than change it form 1 to 100 in a maintenance window.
HTH

Various questions on uplink profiles, CoS, native VLAN, downlink trunking

I will be using vPC End Host Mode with MAC-pinning. I see I can further configure MAC-Pinning. Is this required or will it automatically forward packets by just turning it on? Is it also best not to enable failover for the vnics in this configuration? See this text from the Cisco 1000V deployment Guide:
Fabric Fail-Over Mode
Within the Cisco UCS M71KR-E, M71KR-Q and M81KR adapter types, the Cisco Unified Computing System can
enable a fabric failover capability in which loss of connectivity on a path in use will cause remapping of traffic
through a redundant path within the Cisco Unified Computing System. It is recommended to allow the Cisco Nexus
1000V redundancy mechanism to provide the redundancy and not to enable fabric fail-over when creating the
network interfaces within the UCS Service Profiles. Figure 3 shows the dialog box. Make sure the Enable Failover
checkbox is not checked."
What is the 1000V redundancy?? I didn't know it has redundancy. Is it the MAC-Pinning set up in the 1000V? Is it Network State Tracking?
The 1000V has redundancy and we can even pin VLANs to whatever vNIC we want. See Cisco's Best Practices for Nexus 1000V and UCS.
Nexus1000V management VLAN. Can I use the same VLAN for this and for ESX-management and for Switch management? E.g VLan 3 for everything.
According to the below text (1000V Deployment Guide), I can have them all in the same vlan:
There are no best practices that specify whether the VSM
and the VMware ESX management interface should be on the same VLAN. If the management VLAN for
network devices is a different VLAN than that used for server management, the VSM management
interface should be on the management VLAN used for the network devices. Otherwise, the VSM and the
VMware ESX management interfaces should share the same VLAN.
I will also be using CoS and Qos to prioritize the traffic. The CoS can either be set in the 1000V (Host control Full) or per virtual adapter (Host control none) in UCS. Since I don't know how to configure CoS on the 1000V, I wonder if I can just set it in UCS (per adapter) as before when using the 1000V, ie. we have 2 choices.
Yes, you can still manage CoS using QoS on the vnics when using 1000V:
The recommended action in the Cisco Nexus 1000V Series is to assign a class of service (CoS) of 6 to the VMware service console and VMkernel flows and to honor these QoS markings on the data center switch to which the Cisco UCS 6100 Series Fabric Interconnect connects. Marking of QoS values can be performed on the Cisco Nexus 1000V Series Switch in all cases, or it can be performed on a per-VIF basis on the Cisco UCS M81KR or P81E within the Cisco Unified Computing System with or without the Cisco Nexus 1000V Series Switch.
Something else: Native VLANs
Is it important to have the same native VLAN on the UCS and the Cisco switch? And not to use the default native VLAN 1? I read somewhere that the native VLAN is used for communication between the switches and CDP amongst others. I know the native VLAN is for all untagged traffic. I see many people set the ESXi management VLAN as native also, and in the above article the native VLAN (default 1) is setup. Why? I have been advised to leave out the native VLAN.
Example:Will I be able to access a VM set with VLAN 0 (native) if the native VLAN is the same in UCS and the Cisco switch (Eg. VLAN 2)? Can I just configure a access port with the same VLAN ID as the native VLAN, i.e 2 and connect to it with a PC using the same IP network address?
And is it important to trunk this native VLAN? I see in a Netapp Flexpod config they state this: "This configuration also leverages the native VLAN on the trunk ports to discard untagged packets, by setting the native VLAN on the port channel, but not including this VLAN in the allowed VLANs on the port channel". But I don't understand it...
What about the downlinks from the FI to the chassis. Do you configure this as a port channel also in UCS? Or is this not possible with the setup described here with 1000V and MAC-pinning.
No, port channel should not be configured when MAC-pinning is configured.
[Robert] The VSM doesn't participate in STP so it will never send BPDU's. However, since VMs can act like bridges & routers these days, we advise to add two commands to your upstream VEM uplinks - PortFast and BPDUFilter. PortFast so the interface is FWD faster (since there's no STP on the VSM anyway) and BPDUFilter to ignore any received BPDU's from VMs. I prefer to ignore them then using BPDU Gaurd - which will shutdown the interface if BPDU's are received.
-Are you thinking of the upstream switch here (Nexus, Catalyst) or the N1kV uplink profile config?
Edit: 26 July 14:23. Found answers to many of my many questions...

Answers inline.
Atle Dale wrote:
Something else: Native VLANsIs it important to have the same native VLAN on the UCS and the Cisco switch? And not to use the default native VLAN 1? I read somewhere that the native VLAN is used for communication between the switches and CDP amongst others. I know the native VLAN is for all untagged traffic. I see many people set the ESXi management VLAN as native also, and in the above article the native VLAN (default 1) is setup. Why? I have been advised to leave out the native VLAN.[Robert] The native VLAN is assigned per hop. This means between the 1000v Uplinks port profile and your UCS vNIC definition, the native VLAN should be the same. If you're not using a native VLAN, the "default" VLAN will be used for control traffic communication. The native VLAN and default VLAN are not necessarily the same. Native refers to VLAN traffic without an 802.1q header and can be assigned or not. A default VLAN is mandatory. This happens to start as VLAN 1 in UCS but can be changed. The default VLAN will be used for control traffic communication. If you look at any switch (including the 1000v or Fabric Interconnects) and do a "show int trunk" from the NXOS CLI, you'll see there's always one VLAN allowed on every interface (by default VLAN 1) - This is your default VLAN.Example:Will I be able to access a VM set with VLAN 0 (native) if the native VLAN is the same in UCS and the Cisco switch (Eg. VLAN 2)? Can I just configure a access port with the same VLAN ID as the native VLAN, i.e 2 and connect to it with a PC using the same IP network address?[Robert] There's no VLAN 0. An access port doesn't use a native VLAN - as its assigned to only to a single VLAN. A trunk on the other hand carries multiple VLANs and can have a native vlan assigned. Remember your native vlan usage must be matched between each hop. Most network admins setup the native vlan to be the same throughout their network for simplicity. In your example, you wouldn't set your VM's port profile to be in VLAN 0 (doens't exist), but rather VLAN 2 as an access port. If VLAN 2 also happens to be your Native VLAN northbound of UCS, then you would configured VLAN 2 as the Native VLAN on your UCS ethernet uplinks. On switch northbound of the UCS Interconnects you'll want to ensure on the receiving trunk interface VLAN 2 is set as the native vlan also. Summary:1000v - VM vEthernet port profile set as access port VLAN 21000v - Ethernet Uplink Port profile set as trunk with Native VLAN 2UCS - vNIC in Service Profile allowing all required VLANs, and VLAN 2 set as NativeUCS - Uplink Interface(s) or Port Channel set as trunk with VLAN 2 as Native VLANUpstream Switch from UCS - Set as trunk interface with Native VLAN 2From this example, your VM will be reachable on VLAN 2 from any device - assuming you have L3/routing configured correctly also.And is it important to trunk this native VLAN? I see in a Netapp Flexpod config they state this: "This configuration also leverages the native VLAN on the trunk ports to discard untagged packets, by setting the native VLAN on the port channel, but not including this VLAN in the allowed VLANs on the port channel". But I don't understand it...[Robert] This statement recommends "not" to use a native VLAN. This is a practice by some people. Rather than using a native VLAN throughout their network, they tag everything. This doesn't change the operation or reachability of any VLAN or device - it's simply a design descision. The reason some people opt not to use a native VLAN is that almost all switches use VLAN 1 as the native by default. So if you're using the native VLAN 1 for management access to all your devices, and someone connects in (without your knowing) another switch and simply plug into it - they'd land on the same VLAN as your management devices and potentially do harm.What about the downlinks from the FI to the chassis. Do you configure this as a port channel also in UCS? Or is this not possible with the setup descrived here with 1000V and MAC-pinning.[Robert] On the first generation hardware (6100 FI and 2104 IOM) port channeling is not possible. With the latest HW (6200 and 2200) you can create port channels with all the IOM - FI server links. This is not configurable. You either tell the system to use Port Channel or Individual Links. The major bonus of using a Port Channel is losing a link doesn't impact any pinned interfaces - as it would with individual server interfaces. To fix a failed link when configured as "Individual" you must re-ack the Chassis to re-pinn the virtual interfaces to the remaining server uplinks. In regards to 1000v uplinks - the only supported port channeling method is "Mac Pinning". This is because you can't port channel physical interfaces going to separate Fabrics (one to A and one to B). Mac Pinning gets around this by using pinning so all uplinks can be utilized at the same time.--[Robert] The VSM doesn't participate in STP so it will never send BPDU's. However, since VMs can act like bridges & routers these days, we advise to add two commands to your upstream VEM uplinks - PortFast and BPDUFilter. PortFast so the interface is FWD faster (since there's no STP on the VSM anyway) and BPDUFilter to ignore any received BPDU's from VMs. I prefer to ignore them then using BPDU Gaurd - which will shutdown the interface if BPDU's are received.-Are you thinking of the upstream switch here (Nexus, Catalyst) or the N1kV uplink profile config?[Robert] The two STP commands would be used only when the VEM (ESX host) is directly connected to an upstream switch. For UCS these two commands to NOT apply.

VLAN trunking, native vlan and management vlan

Hello all,
In our situation, we have 3 separate vlans: 100 for management vlan and 101 for data and 102 for voice.
We have an uplink which is trunked using .1Q. Our access ports has the data vlan as the native. Based on our design, what should be the native vlan for this uplink trunk? Should it be the management vlan or the data vlan? Thanks for your help.

To answer this question you must remember what the native vlan is. Native is where untagged packets are sent, i.e. packets without a dot1Q tag. It is there mainly for compatibility. On an access port it has no function while normal traffic is not tagged and sent to the vlan that is configured for the port. Traffic for the voice vlan is an exception to this general rule.
Native vlan setting only plays a role on trunk links where most of the traffic carries a tag. As explained, it is then used as the vlan for untagged traffic.
When you do not consider this a security breach, you may configure the data-vlan as native. Use another vlan (why not vlan1?) in the case where you want to isolate this traffic.
I find it good design practice to use the same native vlan throughout the network. This keeps things clear and it's better for anyone who is not completely obsessed with security. The latter kind of people can always find a reason to mess things up, both for themselves and for others;-)
Regards,
Leo

UCS Native VLAN Question

All,
I have a problem that I just cannot wrap my mind around. We have UCS setup in a lab with 2 interconnects connected to 2 nexus 5510 switches. The nexus switches are uplinked to the network via a 4900m switch. All trunks are setup and tested as functional. All routing is setup and confirmed. I have an issue in UCS that is baffling me. In the lab I have kept the native VLAN at vlan1. I have setup test vlans 2-10 on all the switches and interconnects. I have created a service profile that contains 1 nic and placed it in VLAN 7. I have installed Windows 2008 on a blade using this service profile. In the OS I have statically IP'ed the NIC for the scheme used in VLAN 7. From the OS I cannot ping another device that is in vlan 7. I also cannot ping a host on another vlan. If I place a check on VLAN 1 as the native vlan I still cannot ping anything. If I place the check for native vlan to vlan 7 I can ping hosts within the same vlan as well as outside the vlan. So, why do I need to place vlan 7 as the native vlan when all my trunks are set up as vlan 1 being the native vlan?
Thanks for any help,
Ken

Ken,
When allowing certain VLANs on your Service Profile vNICs you need to set the native VLAN. This is because the way you have it configured currently you're only "allowing VLAN 15", but you're not tagging it. This would work fine for ESX or Linux where you can assign the dot1q tag at the host. With Windows unless you have specific drivers doing the tagging for you, you'll need to do this at the vNIC level within UCS.
Two ways to see this in action. When creating a service profile in the "Basic" method - not "Expert", you will select a single VLAN for your interfaces. This will treat the interfaces pretty much like an "Access Port". Conversely when you use the "Expert mode you're enable the vNIC as a trunk, in which you will "allow" all the VLANs you'd like access to. Sounds like this is the method you have performed.
For a Windows OS, set the VLAN as Native for the VLAN you want it to access and you'll be sweet. Unchecking that "Native VLAN" option box is allowing the traffic to traverse out of UCS on the Native VLAN of your network - VLAN 1, which is why it's MAC appears on the other fabric under VLAN1
Regards,
Robert

Native Vlan Effect on the Overall Network Performance

Dear Experts,
I would like to know that did Native Vlan affect the overall Network performance and make the whole network slow and can be cause for all Network devices to be failure or disconnect. I am facing this issue for the network that after apply Vlan dot1q tag native" in global Config the user disconnect from the network and also the devices.
Kindly assist on this issue with the practical scenario and result oriented conclusion.
Further I have following Devices in the Network Catalyst 4500, Nexus 5548, FIC 6248, UCS 5018 and Catalyst 3750.
The issue is this the VLAN 50 which is for UCS is not able to access from the LAN network even we added the VLAN 50 on all the Switches and it propogated to whole network so we make Vlan 50 as Native and added "switchport trunk native vlan 50 on trunks ports from Nexux 5548 to Fabric Interconnect and to Core Switch 4500. After added vlan 50 as native vlan we can access the UCS from LAN.
But after adding native vlan 50 on all trunks the Network Administrator complaining that network is slow and few servers are disconnecting.
here for the information that server vlan is 1.
Waiting for the answer.
Thanks,
JH
Thanks,
JH

Hello.
1. Could you please draw interconnectivity diagram of all the devices?
2. Could you chose any LAN device (on the same switch as UCS) and post here running config of the device that interconnects them?

What is AP H-REAP Native Vlan used for?

We have a few APs - CAP3502 and LAP1242s for the most part - whose H-REAP "Native Vlan" doesn't match the switchport's native vlan. It appears that the switchport native vlan is what gets used for the AP for DHCP (it gets an AP IP address from that network). If so, does anyone know what the purpose of specifying the native vlan on the H-REAP config is? I can think of no useful purpose, but if there is one I'd appreciate anyone who could say.
Thanks.
BTW this is on a 5508 controller running 7.0.240.0 code.

Thanks Scott - further info: the Vlan Mappings are filled in with the appropriate Vlans, which are separate from the AP native vlan. In this case vlans 202, 203, 204 and 206 are assigned to various SSIDs and the Native Vlan for the AP is set to 201. The switchport is set to trunk all vlans and has native vlan 221, and it is from vlan 221 that the AP get's its own IP.
So on the one hand, if specifying the 'native' vlan were to avoid cases where the wrong vlan was native on the switch (and so, to tell the AP which vlan to use for itself and control traffic), I would expect the AP to have a vlan201 address.
If on the other hand this is merely a 'documentary' setting to say what the 'native vlan' *should* be, then I would expect the AP to have a vlan221 IP, which it does.
Just trying to find out if this setting does anything more than document.

Why Native VLAN exists on a Trunk?

Basically, A Native VLAN carries untagged traffic on a trunk line.
A trunk line allows mutiple VLAN traffic ( tagged traffic). So Why Native VLAN exists on a trunk.
Why Native VLAN was created?
I'm pretty confused up with VLANs.

Hi,
The second question - why PC Network adapters support VLAN tags - is actually easier to answer :)
First of all, with regards to VLANs and frame tagging, there is actually nothing special to support on a network adapter! The VLAN tag itself is in fact stored in the payload of a tagged frame. Even to the most dumb network adapter, a tagged frame looks like any other - Destination MAC, Source MAC, EtherType (set to 0x8100), Payload (holding the rest of the VLAN tag, the original EtherType and the original Payload), and the FCS. Supporting VLANs and frame tags is possible on a purely software level. The fact that network adapters often do have hardware support for VLANs is related to performance reasons: With hardware VLAN support, the tagging, de-tagging, filtering and/or sorting frames based on the VLAN tag value is faster and it allows offloading these operations from the computer's CPU to the network card. However, even if the network adapter did not have any kind of VLAN support, the VLANs could still be implemented purely in the card's software driver.
Ordinarily, you would not see a common PC send and receive tagged frames. However, there are situations in which even a PC would send or receive a tagged frame. One of reasons is the presence of the Class-of-Service (CoS) bits in a VLAN tag. You surely know that basic Ethernet frame format does not include any kind of priority marking. There is no field in an Ethernet header that would allow you to indicate that this or that frame requires a preferential treatment. VLAN tags, on the other hand, have a 3-bit CoS field that allows you to indicate the priority of the tagged frame. Should a PC need to send a frame that needs to be explicitly marked as more important than others, it can be done by inserting a VLAN tag into this frame and setting the CoS field to a non-zero value (with 3 bits, the maximum CoS value is 7).
Another reason for a computer to send and receive tagged frames would be when the computer itself would be intentionally placed into multiple VLANs. For example, the router-on-a-stick performing inter-VLAN routing is not a concept just for dedicated hardware routers. For example, any computer running Linux can be used in place of a Cisco router to perform inter-VLAN routing. Just like on a Cisco router, you would configure the Linux with subinterfaces for each VLAN it should be able to route from and to, assign IP addresses, and voila - you have a cheap and powerful inter-VLAN router. Yet another reason for receiving and sending tagged frames on a computer would be virtualization: You could have a server that runs multiple virtual operating systems in VirtualBox, VMWare, Xen or some other virtualization solution, and you want each of these virtual PCs to have a "separate" network card so that they can not talk to each other when they communicate with the outside world. You would do this again by creating subinterfaces on the physical machine, and bridging the individual virtual PCs with unique subinterfaces so that each virtual PC gets its own subinterface onto which it is bridged. As a result, the communication of individual virtual PCs would be tagged on the physical link depending on what virtual machine was speaking.
So, while not exactly a typical situation for an ordinary office PC, it is nonetheless quite normal to see a computer being connected to a trunk port. This, however, is always done with the prior knowledge that the computer will indeed need to talk to several VLANs simultaneously and directly. Otherwise there's no need for that.
Regarding the native VLAN on trunks - well, this is a neverending debate. I wish the native VLAN was never invented but well, it's here so we have to fight with it. Often, it is explained as "the VLAN that will save you if you happen to connect a normal PC to a trunk", and you have asked quite correctly - why on Earth would I want to connect a normal PC to a trunk, if not for reasons stated above? And you would be perfectly right - you wouldn't. The reason for native VLANs is different. If you try to study the IEEE 802.1Q standard you will learn that it does not recognize the terms access port and trunk port. It has no distinction for these port types. Instead, 802.1Q considers each port to be possibly associated with multiple VLANs at once. One of these VLANs is called the Primary VLAN, its number (ID) is called the Primary VLAN ID (PVID), and this VLAN is considered to be the one that is always associated with the port and thus does not need to use tags. Any other VLAN that is in addition associated with the port obviously has to use tags to be distinguishable. From this viewpoint, a port that is associated just with its PVID would be what Cisco calls an access port, and a port that is associated with VLAN IDs other than just its PVID would be what Cisco calls a trunk port, with the PVID being the trunk's native VLAN ID.
So in the way IEEE defines VLANs and their usage, PVID (= native VLAN ID) is a property of each port, so any implementation that claims compatibility with 802.1Q has to implement the PVID. Cisco decided to have a twist on the understanding of VLANs, and came up with access ports (i.e. ports associated just with their PVID and no other VLAN ID) and trunk ports (i.e. ports associated with many VLAN IDs including PVID), and so each trunk port must have its PVID - and that is what we call native VLAN and why we need to at least support it - although we do not need to make use of the native VLAN on trunks.
Quite convoluted.
Best regards,
Peter

Voice Vlan and Native Vlan

Dear all,
I am now reading some information regarding the setup of Voip Phone. It mentioned that the Phone is actually a 3-ports switch:
Port 1: Connect to upstream switch
Port 2: Transfer Phone traffic
Port 3: Connect to a PC
Actually, what should i configure on the upstream switch port? Should it be a trunk port containing both the voice traffic vlan and pc data vlan?
Or something else?
Also, there is a term called 'Voice Vlan', is there any different between 'Voice vlan' and ordinary Vlan ?
Is there any special usage of 'Native' Vlan in implementing Voip?
Thanks.
Br,
aslnet

Thanks.
How about if the PC data should be tagged as another vlan (e.g., Vlan 10)? Then I should change the native vlan to vlan 10?
But from my understanding, Native Vlan should be the same in the whole network, then I need to change the whole network native vlan? If there are different vlans should be assigned to different PCs that behind different VoIP-phone, then how to do it?
From my guessing, is it i can assign individual native vlan (vlan10) on that port (connect to voip-phone), and then keep the switch's uplink port as original native vlan (vlan1).
Therefore, PC data traffic would be untagged when entering from voip to the switch, and then tagged as vlan10 when leaving the switch to other uplink switch, right?
Thanks.

VLAN DOT1Q, SWITCHPORT TRUNK NATIVE VLAN, and VLAN1

Hi All,
L2 security documents suggest to avoid using vlan1 and tagging all frames with vlan IDs using the global configuration of vlan dot1q. Other Cisco non-security documents suggest using the switchport trunk native vlan # which removes any vlan tagging. It seems to me that the global vlan dot1q command and the interface switchport trunk native vlan # are contradictory; therefore, both should not be used. Furthermore, my understanding is to avoid using vlan 1 to tighten L2 security. When vlan 1 is removed from all trunked uplinks, user access ports are other than vlan 1, and no spanning-tree vlan 1 operations exists, what is the native vlan 1 actually used for?. The output of show interface gi0/1 trunk shows the native vlan as 1.
Thanks,
HC

Hi HC,
the command "switchport trunk native vlan" is used to define the native (untagged vlan) on a dot1q link. The default is 1, but you can change it to anyting you like. But it does only change the native vlan, all the others vlan on the trunk are of course tagged (and it only applies to dot1q, as ISL "taggs/encapsulates" all the vlans). The command "vlan dot1q tag native" is mostly used in dot1qindot1q tunnels, where you tunnel a dot1q trunk within a dot1q trunk. Thats something mostly service Providers offer to there customers. There it is important that there is no untagged traffic, as that would not work with dot1qindot1q. This command tagges the native vlan traffic, and drops all traffic which is not tagged.
Whatfor is the native VLAN? Switches send control PDU such as STP,CDP or VTP over the native VLAN.
If you don't happen to be a service Provider for L2 metropolitan Ethernet, you wan't need the "vlan dot1q tag native" command. For my part I'm trying not to use vlan 1 everywhere in my campus, because it gives a huge spanningtree topology and if you ever get a switch to blow a heavy load of traffic into it, you have your whole campus network degradet. I try to keep Vlan's a small as possible and to have as much L3 separaton as possible, that's good for the stability!
Simon

Default/native vlan- voip data question- cisco sf300

hi everybody,
I have to set up voip and data vlans on cisco sf 300-24P. I will set up phones over LLDP and
on the same port (on switch) I will have untagged vlan 10 for data, so PC will be connected
through IP phones on network.
So what confuses me that on SF 300 under VLAN mgmt--> Default VLAN settings you got
options to change default VLAN id (which is of course VLAN1) which will be active after reboot.
How come that you can change default vlan? Isnt that default vlan is always vlan 1 and you can
change native vlan to be something else- let say vlan 10 which will be untagged vlan for data?
So what is best practise- should I just leave default vlan 1 and use it for data also or I sholud
change it to let say VLAN 10 to be native and use it for data.
And what will be with default VLAN 1 if I change it with above mentioned procedure?
Thx!

Hi,
Best Practice is to leave Vlan 1 for management purposes only. Create yourself a DATA and VOICE vlan. Usually Management vlan does not have DHCP enabled and have to static assigned pc within your management vlan for access. I would say that it really depends on how the rest of your network is configured depending on configuration of switch now. Unless this is a clean install.
Hope this helps,
Jasbryan

Routed port configured as native vlan

I have attached a diagram with this discussion. First please have a look at it.
The thing is; I had seen on design recently. There was more than 20 sub interfaces with IP address assigned in a router which was connected to
a switch. The port was obviously a trunk port as it was supposed to make a flow for more than 20 vlans. The confusion part for me is: there
was IP address in the actual physical interface too. I didn't understand why its there in the first place.
Would somebody share me the scoop??
Thank You in advance.

Hi Ganesh.,
To be frank I dont see any reason to have the ip address on the main interface. It is just like having native vlan concept.
Please find below testing:
Example:
I have router connecting to the Switch.
Router---F0/1--------------------F0/1---Switch
Router f0/1- ip address 50.0.0.1 /24---
f0/.1---ip address 10.0.0.2/24
f0/.2--ip address 20.0.0.2/24
f0/.3- ip address 30.0.0.3/24
Switch
F0/1--Switch port mode trunk----switch trunk encap dot1q --Switch trunk native vlan 50.>>> configuring native vlan as 50.
vlan 10--ip address 10.0.0.1/24
vlan 20---ip address 20.0.0.1/24
vlan 30 -ip address 30.0.0.1/24
vlan 50--ip address 50.0.0.2/24
Now you will have reachability to all the network. Were in Vlan 50 is your native vlan now.
HTH
Regards
Inayath.

Why dot1Q doesn't tag native vlan?

Why dot1Q doesn't tag native vlan?
Is there any reason? Or Is there any advantage with this ?
Regards,
Chandu

Chandu
The native vlan is there to support connectivity to switches that do not support vlan tagging so that if the switch on the other end of the link cannot interpret frames with vlan tags added it can still process the non tagged native vlan packets.
Nowadays most, if not all, switches do understand vlan tagging so it is very rare you need it for it's original purpose and you can in fact on a lot of Cisco switches actually tell the switch to tag the native vlan as well.
Jon

The difference between IEEE802.1Q Native VLAN sub-interface and Physical interface?

Hello
I think the following topologies are supported for Cisco Routers
And the Physical interface also can be using as Native VLAN interface right?
Topology 1.
R1 Gi0.1 ------ IEEE802.1Q Tunneling L2SW ------ Gi0 R2
R1 - configuration
interface GigabitEthernet0.1
encapsulation dot1Q 1 native
ip address 10.0.0.1 255.255.255.0
Topology 2.
R1 Gi0 ------ IEEE802.1Q Tunneling L2SW ------ Gi0 R2
interface GigabitEthernet0
ip address 10.0.0.1 255.255.255.0
And is it ok to use the physical interface and sub-interface with dynamic routing such as EIGRP or OSPF etc?
R1 Gi 0 ---- Point to Multipoint EIGRP or OSPF ---- Gi0 R2 / R3
Gi 0.20--- Point to Point EIGRP or OSPF --- Gi0.10 R4 (same VLAN-ID)
R1 - configuration
interface GigabitEthernet0
ip address 10.0.0.1 255.255.255.0
interface GigabitEthernet8.20
encapsulation dot1Q 20
ip address 20.0.0.1 255.255.255.0
Any information is very appreciated. but if there is any CCO document please let me know.
Thank you very much and regards,
Masanobu Hiyoshi

Hello,
The diagram is helpful.
If I am getting you correctly, you have three routers interconnected by a switch, and you want them to operate in a hub-and-spoke fashion even though the switch is capable of allowing direct communication between any of these routers.
Your first scenario is concerned with all three routers being in the same VLAN, and by using neighbor commands, you force these routers to establish targeted EIGRP adjacencies R1-R2 and R1-R3, with R1 being the hub.
Your second scenario is concerned with creating one VLAN per spoke, having subinterfaces for each spoke VLAN created on R1 as the router, and putting each spoke just in its own VLAN.
Your scenarios are not really concerned with the concept of native VLAN or the way it is configured, to be honest. Whether you use a native VLAN in either of your scenarios, or whether you configure the native VLAN on a subinterface or on the physical interface makes no difference. There is simply no difference to using or not using a native VLAN in any of your scenarios, and there is no difference to the native VLAN configuration being placed on a physical interface or a subinterface. It's as plain as that. Both your scenarios will work.
My personal opinion, though, is that forcing routers on a broadcast multi-access segment such as Ethernet to operate in a hub-and-spoke fashion is somewhat artificial. Why would you want to do this? Both scenarios have drawbacks: in the first scenario, you need to add a neighbor statement for each spoke to the hub, limiting the scalability. In the second scenario, you waste VLANs and IP subnets if there are many spokes. The primary question is, though: why would you want an Ethernet segment to operate as a hub-and-spoke network? Sure, these things are done but they are motivated by specific needs so I would like to know if you have any.
Even if you needed your network to operate in a hub-and-spoke mode, there are more efficient means of achieving that: Cisco switches support so-called protected ports that are prevented from talking to each other. By configuring the switch ports to spokes as protected, you will prevent the spokes from seeing each other. You would not need, then, to configure static neighbors in EIGRP, or to waste VLANs for individual spokes. What you would need to do would be deactivating the split horizon on R1's interface, and using the ip next-hop-self eigrp command on R1 to tweak the next hop information to point to R1 so that the spokes do not attempt to route packets to each other directly but rather route them over R1.
I do not believe I have seen any special CCO documents regarding the use of physical interfaces or subinterfaces for native VLAN or for your scenarios.
Best regards,
Peter

QoS / Native VLAN Issue - Please HELP! :)

I've purchased 10 Cisco Aironet 2600 AP’s (AIR-SAP2602I-E-K9 standalone rather than controller based).
I’ve configured the WAP’s (or the first WAP I’m going to configure and then pull the configuration from and push to the others) with 2 SSID’s. One providing access to our DATA VLAN (1000 – which I’ve set as native on the WAP) and one providing access to guest VLAN (1234). I’ve configured the connecting DELL switchport as a trunk and set the native VLAN to 1000 (DATA) and allowed trunk traffic for VLAN’s 1000 and 1234. Everything works fine, when connecting to the DATA SSID you get a DATA IP and when you connect to the GUEST SSID you lease a GUEST IP.
The problem starts when I create a QoS policy on the WAP (for Lync traffic DSCP 40 / CS5) and try to attach it to my VLAN’s. It won’t let me attach the policy to VLAN 1000 as it’s the native VLAN. If I change VLAN 1000 on the WAP to NOT be the native VLAN I can attach the policies however wireless clients can no longer attach to either SSID properly as they fail to lease an IP address and instead get a 169.x.x.x address.
I'm sure I'm missing something basic here so please forgive my ignorance.
This is driving me insane!
Thanks to anyone that provides assistance. Running config below and example of the error...
User Access Verification
Username: admin
Password:
LATHQWAP01#show run
Building configuration...
Current configuration : 3621 bytes
! Last configuration change at 02:37:59 UTC Mon Mar 1 1993 by admin
version 15.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
hostname LATHQWAP01
logging rate-limit console 9
aaa new-model
aaa authentication login default local
aaa authorization exec default local
aaa session-id common
no ip routing
dot11 syslog
dot11 vlan-name Data vlan 1000
dot11 vlan-name Guest vlan 1234
dot11 ssid LatitudeCorp
   vlan 1000
   authentication open
   authentication key-management wpa version 2
   wpa-psk ascii
dot11 ssid LatitudeGuest
   vlan 1234
   authentication open
   authentication key-management wpa version 2
   guest-mode
   wpa-psk ascii
crypto pki token default removal timeout 0
username admin privilege 15 password!
class-map match-all _class_Lync0
match ip dscp cs5
policy-map Lync
class _class_Lync0
set cos 6
bridge irb
interface Dot11Radio0
no ip address
no ip route-cache
encryption vlan 1234 mode ciphers aes-ccm
encryption vlan 1000 mode ciphers aes-ccm
ssid LatitudeCorp
ssid LatitudeGuest
antenna gain 0
stbc
station-role root
interface Dot11Radio0.1000
encapsulation dot1Q 1000 native
no ip route-cache
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 spanning-disabled
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
interface Dot11Radio0.1234
encapsulation dot1Q 1234
no ip route-cache
bridge-group 255
bridge-group 255 subscriber-loop-control
bridge-group 255 spanning-disabled
bridge-group 255 block-unknown-source
no bridge-group 255 source-learning
no bridge-group 255 unicast-flooding
service-policy input Lync
service-policy output Lync
interface Dot11Radio1
no ip address
no ip route-cache
encryption vlan 1234 mode ciphers aes-ccm
encryption vlan 1000 mode ciphers aes-ccm
ssid LatitudeCorp
ssid LatitudeGuest
antenna gain 0
no dfs band block
stbc
channel dfs
station-role root
interface Dot11Radio1.1000
encapsulation dot1Q 1000 native
no ip route-cache
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 spanning-disabled
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
interface Dot11Radio1.1234
encapsulation dot1Q 1234
no ip route-cache
bridge-group 255
bridge-group 255 subscriber-loop-control
bridge-group 255 spanning-disabled
bridge-group 255 block-unknown-source
no bridge-group 255 source-learning
no bridge-group 255 unicast-flooding
service-policy input Lync
service-policy output Lync
interface GigabitEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
interface GigabitEthernet0.1000
encapsulation dot1Q 1000 native
no ip route-cache
bridge-group 1
bridge-group 1 spanning-disabled
no bridge-group 1 source-learning
interface GigabitEthernet0.1234
encapsulation dot1Q 1234
no ip route-cache
bridge-group 255
bridge-group 255 spanning-disabled
no bridge-group 255 source-learning
service-policy input Lync
service-policy output Lync
interface BVI1
ip address 10.10.1.190 255.255.254.0
no ip route-cache
ip default-gateway 10.10.1.202
ip http server
ip http authentication aaa
no ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
bridge 1 route ip
line con 0
line vty 0 4
transport input all
end
LATHQWAP01#conf
Configuring from terminal, memory, or network [terminal]? t
Enter configuration commands, one per line. End with CNTL/Z.
LATHQWAP01(config)#int dot11radio1.1000
LATHQWAP01(config-subif)#ser
LATHQWAP01(config-subif)#service-policy in
LATHQWAP01(config-subif)#service-policy input Lync
set cos is not supported on native vlan interface
LATHQWAP01(config-subif)#

Hey Scott,
Thank you (again) for your assistance.
So I' ve done as instructed and reconfigured the WAP. I've added an additional VLAN (1200 our VOIP VLAN) and made this the native VLAN - so 1000 and 1234 are now tagged. I've configure the BVI interface with a VOIP IP address for management and can connect quite happily. I've configured the connecting Dell switchport as a trunk and to allow trunk vlans 1000 (my DATA SSID), 1200(native) and 1234 (MY GUEST SSID). I'm now back to the issue where when a wireless client attempts to connect to either of my SSID's (Guest or DATA) they are not getting a IP address / cannot connect.
Any ideas guys? Forgive my ignorance - this is a learning curve and one i'm enjoying.
LATHQWAP01#show run
Building configuration...
Current configuration : 4426 bytes
! Last configuration change at 20:33:19 UTC Mon Mar 1 1993 by Cisco
version 15.3
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
hostname LATHQWAP01
logging rate-limit console 9
enable secret 5
no aaa new-model
no ip source-route
no ip cef
dot11 syslog
dot11 vlan-name DATA vlan 1000
dot11 vlan-name GUEST vlan 1234
dot11 vlan-name VOICE vlan 1200
dot11 ssid LatitudeCorp
   vlan 1000
   authentication open
   authentication key-management wpa version 2
   mobility network-id 1000
   wpa-psk ascii
dot11 ssid LatitudeGuest
   vlan 1234
   authentication open
   authentication key-management wpa version 2
   mbssid guest-mode
   mobility network-id 1234
   wpa-psk ascii
   no ids mfp client
dot11 phone
username CISCO password
class-map match-all _class_Lync0
match ip dscp cs5
policy-map Lync
class _class_Lync0
set cos 6
bridge irb
interface Dot11Radio0
no ip address
encryption vlan 1000 mode ciphers aes-ccm
encryption vlan 1234 mode ciphers aes-ccm
ssid LatitudeCorp
ssid LatitudeGuest
antenna gain 0
stbc
mbssid
station-role root
interface Dot11Radio0.1000
encapsulation dot1Q 1000
bridge-group 255
bridge-group 255 subscriber-loop-control
bridge-group 255 spanning-disabled
bridge-group 255 block-unknown-source
no bridge-group 255 source-learning
no bridge-group 255 unicast-flooding
service-policy input Lync
service-policy output Lync
interface Dot11Radio0.1200
encapsulation dot1Q 1200 native
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 spanning-disabled
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
interface Dot11Radio0.1234
encapsulation dot1Q 1234
bridge-group 254
bridge-group 254 subscriber-loop-control
bridge-group 254 spanning-disabled
bridge-group 254 block-unknown-source
no bridge-group 254 source-learning
no bridge-group 254 unicast-flooding
service-policy input Lync
service-policy output Lync
interface Dot11Radio1
no ip address
encryption vlan 1000 mode ciphers aes-ccm
encryption vlan 1234 mode ciphers aes-ccm
ssid LatitudeCorp
ssid LatitudeGuest
antenna gain 0
peakdetect
no dfs band block
stbc
mbssid
channel dfs
station-role root
interface Dot11Radio1.1000
encapsulation dot1Q 1000
bridge-group 255
bridge-group 255 subscriber-loop-control
bridge-group 255 spanning-disabled
bridge-group 255 block-unknown-source
no bridge-group 255 source-learning
no bridge-group 255 unicast-flooding
service-policy input Lync
service-policy output Lync
interface Dot11Radio1.1200
encapsulation dot1Q 1200 native
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 spanning-disabled
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
interface Dot11Radio1.1234
encapsulation dot1Q 1234
bridge-group 254
bridge-group 254 subscriber-loop-control
bridge-group 254 spanning-disabled
bridge-group 254 block-unknown-source
no bridge-group 254 source-learning
no bridge-group 254 unicast-flooding
service-policy input Lync
service-policy output Lync
interface GigabitEthernet0
no ip address
duplex full
speed auto
interface GigabitEthernet0.1000
encapsulation dot1Q 1000
bridge-group 255
bridge-group 255 spanning-disabled
no bridge-group 255 source-learning
service-policy input Lync
service-policy output Lync
interface GigabitEthernet0.1200
encapsulation dot1Q 1200 native
bridge-group 1
bridge-group 1 spanning-disabled
no bridge-group 1 source-learning
interface GigabitEthernet0.1234
encapsulation dot1Q 1234
bridge-group 254
bridge-group 254 spanning-disabled
no bridge-group 254 source-learning
service-policy input Lync
service-policy output Lync
interface BVI1
mac-address 881d.fc46.c865
ip address 10.10. 255.255.254.0
ip default-gateway 10.10.
ip forward-protocol nd
ip http server
no ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
bridge 1 route ip
line con 0
line vty 0 4
login local
transport input all
sntp server ntp2c.mcc.ac.uk
sntp broadcast client
end
LATHQWAP01#

Actual purpose of native vlan in real network

Similar Messages

Maybe you are looking for