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.

Similar Messages

Native Vlan and Trunking

Hi Folks,
I am having a doubt with native Vlan in trunk ports.
In a topology of 3 switches. Switch A is connected with switchB and SwitchC on uplinks. Can I configure the different native vlans for 2 different trunk for switch A.
Like I am having 3 vlan,s configured in switch A with VTP domain transparent(1,500,900-Vlans configured). Same configuration is there in B & C too.
So can we use 999 as a native vlan for trunk between A&B and native vlan 1 for trunk configured between A&C.

yes possible, if specific reasons. Already discussed several times on this forum. Pls refer this link:
http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=LAN%2C%20Switching%20and%20Routing&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cbe4e88

Clearing native VLAN from trunks

On a dot1q trunk, all frames are tagged except those on the native VLAN, right? What about PVST BPDUs? Until today, I thought they obeyed the same rule, but now I doubt it.
I did an experiment. Take two switches, a distribution switch and an access switch, and join then with a trunk that passes all VLANs. Make the native VLAN of this trunk, say, 12 - at both ends of course. Make the distribution switch the root of every VLAN. The access switch knows that the distribution switch is the root.
Now clear VLAN 12 from the trunk at the access switch end. As expected, the Spanning Tree for VLAN 12 shuts down beceuse there are no longer any ports supporting it. Most of the VLANs carry on as before. But something interesting happens to VLAN 1 : it is no longer able to receive or process BPDUs on the trunk. Normal VLAN 1 traffic passes fine, but the BPDUs are no longer processed. As a result, the access switch believes it is the root of VLAN 1.
If you have two uplinks into the distribution layer everything falls to pieces. Clear VLAN 12 from both trunks, and the access switch no longer receives VLAN 1 BPDUs from the trunk, so both uplinks go into forwarding. Normal traffic passes OK, so the result is meltdown.
Has anyone else observed this?
So, on a dot1q trunk with a native VLAN not 1, are VLAN 1 BPDUs tagged or not. Are the native VLAN BPDUs tagged or not?
Kevin Dorrell
Luxembourg

Francois,
Thanks for the reply. I am going to raise it with the TAC. I think it does make sense for them to be sent twice. Do you have any document that I could refer to please?
What I do know is that clearing the (unused) native VLAN from my trunks broke the Spanning Tree for VLAN 1, and caused an embarassing meltdown on the LAN. So at the very least, clearing the native VLAN should give a health warning. After all, the repercussions are much greater than portfast, and that has a health warning.
I have seen this behaviour on Cat 4003 running CatOS 8.4(5)GLX, which is almost the latest version, and on Cat29xx running 12.1.
As I see it, there were two possibilities. After I cleared the native VLAN, either the distribution switches stopped sending the VLAN 1 BPDUs, or the access switch stopped receiving them. I tested that by allowing the native VLAN on the distribution-switch side, and clearing it on the access-switch side. VLAN 1 was still broken. Therefore, clearing the native VLAN prevents the VLAN 1 BPDUs from being reveived. Now I must do the converse experiment (in the lab!): clear the native on the distribution-switch side, but allow it on the access-switch side. That will tell me whether the distribution switch is still sending them.
Thanks for your helpful contribution.
Kevin Dorrell
Luxembourg

Native VLAN and Trunks on Bridges

I have a need for different Native VLANs on the radio side and the ethernet side. Can this be done on the non-root 1410 bridge?
The radio native VLAN is to support the management on teh 1410 bridges. I also need to attach a single device from another VLAN on the non-root bridge and I do not want to have to put in a switch just to break out that needed VLAN.

The bridge supports only one SSID. You should assign the SSID to the native VLAN
1.Create subinterfaces on the radio and Ethernet interfaces.
2. Enable 802.1q encapsulation on the subinterfaces and assign one subinterface as the native VLAN.
3. Assign a bridge group to each VLAN.
4. (Optional) Enable WEP on the native VLAN.
5. Assign the bridge's SSID to the native VLAN.
To assign an SSID to a VLAN and how to enable a VLAN on the bridge radio and Ethernet ports
For further information click this link.
http://www.cisco.com/en/US/docs/wireless/bridge/1400/12.3_8_JA/configuration/guide/p38vlan.html

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

Does it need add the native vlan to allowed vlan list ?

If I confiured the port like this "
switchport trunk native vlan 10
switchport trunk allowed vlan 11,12"
does the vlan 10 allowed passing ? or it still need add vlan 10 to the allowed vlan list like "
switchport trunk native vlan 10
switchport trunk allowed vlan 10,11,12"
Thanks

Yes you can remove the native VLAN from the list, and it does prevent the native VLAN from traversing the trunk. That is, if you look at the Spanning Tree for the native VLAN, the trunk will be absent from the list of ports on the VLAN.
The question of untagged frames is a different one. There are some control protocols, particularly link-local ones, that are sent untagged, and these will traverse the trunk regardless. However, they are not considered as part of the native VLAN Spanning Tree as such.
But beware: there is a bug in earlier IOS and in all CatOS switches! If you use a non-1 VLAN as your trunk native VLAN, and you disallow it from the trunks, and there are no other ports carrying that native VLAN, then the Spanning Tree for that VLAN shut down. That is fair enough. But the bug is that the Spanning Tree for VLAN 1 also breaks down, sending your network into meltdown.
Kevin Dorrell
Luxembourg

NAtive VLAN?what is the use of vlan?VLAN in trunk link?

what is the use of native VLAN in trunk links? where should i change native vlan from vlan1 to another?
what is the use of untagged native VLAN frame?

Hi,
On ethernet, you can connect more than one device to a port. So when you configure a port as trunk, it expects a vlan tag to arrive. But some times there are devices which dont have the capability to tag the packet and still they need to connect to network. So they can use native vlan to have connectivity. It is not a usual situation, but it helps on some situation where multiple devices connected on a trunk and not all have ability to send tagged frames. Hope this helps.
Please do remember to rate all useful posts.
Thanks,
Madhu

Native vlan prblm

why the native vlan should be same on both side of the trunk???

A trunk link can carry multiple vlans. So lets say on each switch you have vlans 5,6 & 7. If sw1 sends a frame for vlan 6 to sw2 how does sw2 know which vlan that packet is in ? It knows because sw1 adds a vlan tag to the frame header and sw2 reads this vlan tag and sees that the packet is in vlan 6.
The native vlan is the vlan that is not tagged. So lets say in the above example vlan 5 is the native vlan. When sw1 sends a packet for vlan 5 there is no vlan tag added to the frame. So when sw2 receives the frame there is no vlan tag to read. So it must agree on the native vlan otherwise it wouldn't know which vlan the frame is meant to be in. If sw2 had the native vlan set to 7 for example then it would think the frame it just received was in vlan 7. This would be bad because now you have just "joined" two vlans together.
If you do configure different native vlans on either end of the trunk and you are running CDP then you would get CDP Native vlan mismatch errors in your log.
Note that the native vlan must only agree per trunk link so you could if you wanted have different native vlans per trunk link as long as each trunk link agreed on either end but in practice you generally use the same native vlan across all trunk links.
Finally, by default the native vlan is vlan 1 on all Cisco switches. It is recommended to change this to another vlan. The native vlan should have no ports assigned to it and it does not need an SVI because there is never a need to route native vlan.
Jon

How to get info over snmp on cisco switch whether native vlan on a port is tagged or not?

Hi!
I want to know which oid(s) should I query to know whether native vlan on trunk port on cisco switch is tagged or not?
I am querying the oid .1.3.6.1.4.1.9.9.46.1.6.3.0 (vlanTrunkPortsDot1qTag) on cisco 3560 (E Series) and I am getting global value. Also, this OID is showing as deprecated. So I query .1.3.6.1.4.1.9.9.246.1.6 (cltcDot1qAllTagged) and its subtree, but no value is returned.
Switch Version is
Cisco IOS Software, C3560E Software (C3560E-UNIVERSALK9-M), Version 12.2(50)SE2

Keep in mind that DHCP is a broadcast packet to start. So the AP can only listen in the subnet that it has an IP address for.
Now, for any other subnet you can use the AP for DHCP but you have to have an IP helper address on your L3 pointing back to the AP.
That being said, I wouldn't use the DHCP server on the AP as it is limited. You'd be better off using a Microsoft server or some other device that is designed for DHCP.
HTH,
Steve

The old native vlan question....

Topic came up during troubleshooting a 3524XL sw.
I think my understanding of the native vlan concept is wrong.
I thought on a trunk port (Cisco device) that any packet transversing a trunk link (dot1q trunk that is) has a vlan tag applied on the egress port. As an untagged packet arrives on the port (prior to being sent out over the trunk), its is tagged with the native vlan (if its not assocated with any other vlan), then sent out the (egress) the trunked port.
But lately I have been reading that
"A native vlan is the untagged vlan on an 802.1q trunked switchport. The native vlan and management vlan could be the same, but it is better security practice that they aren't. Basically if a switch receives untagged frames on a trunkport, they are assumed to be part of the vlan that are designated on the switchport as the native vlan. Frames egressing a switchport on the native vlan are not tagged. This is the definition however more recent switch software often will allow you to tag all of the frames, even those in the native vlan. This gives some added security and allows the CoS bits to be carried between switches even on the native vlan. Let me know if you need further clarification."
From : https://learningnetwork.cisco.com/thread/8721
So this tells me that you can have a packet transversing a dot1q link w/o a vlan tag...then when it arrives on the other end its put in the vlan that is on that native vlan question. Is this correct?
If so, and a packet can transverse a trunk link w/o a VLAN tag applied, how does a sw detect (ingress) a native vlan mismatch?
Thanks!

Hi,
It's correct, the native vlan is not tagged by default on the trunk link but some platform can make you tag all traffic though even the native vlan.
The native vlan mismatch is detected through cdp.
Regards.
Alain.
Don't forget to rate helpful posts.

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

Q-in-Q w/o Native VLAN tag question

Let's assume that we have Q-in-Q setup between 2 service provider switches. To run Q-in-Q we want to terminate a trunk into each tunnel port and enable native VLAN tagging to ensure that all customer VLAN's are tagged. In some cases we may have a customer that wants to connect their own equipment into the tunnel port on our switch, so it wouldn't actually be a trunk - it would be an access port. If this occurs then there is no inner VLAN tag, only an outer VLAN tag. Will tunnelling still function properly in this scenario?

actually this is not true... sorry Kishore
Tunneling still works and traffic within the SP core will be singled tagged (with the SP tag only).
However when you do this you need to be extremely careful specially if you use dot1q trunks in the core with native vlan within the customer range. You might end up in unexpected result in this case.
See an exmple of a possible issue you might see in this case:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_58_se/configuration/guide/swtunnel.html#wp1008635
The solution would be to tag native vlan in the SP core or use ISL trunks or use native vlans outside customer range or (logically) use trunk ports on CE device (still paying attention to native vlan though).
Riccardo

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

SG500 auto voice VLAN question about native VLAN

I have been installing SG300 and SG500 switches and using the auto voice vlan feature by simply changing voice vlan to 100 and using vlan 1 for default and data. I normally put the switch in L3 mode and make an access porteach for my IP PBX (vlan 100) and one to connect to existing data network (vlan 1). Then I make a static route in customers default gateway to route back to vlan 100 and everything works nicely for most installs.
On my last install I decided to try to change the default vlan 1 to vlan 10 and go with 10 for data and 100 for voice. The problem I ran into was that the auto generated config on my phone switchports still use vlan 1 as native vlan. I am trying to find a way to still use auto vlan and get the desired native vlan without having to make manual config changes.
Should this be possible?
Thanks in advance.

Hi Brandon, you need to modify the macro from native vlan 1 to vlan 10.
Check out this topic how to modify the macro
https://supportforums.cisco.com/thread/2177613
-Tom
Please mark answered for helpful posts

(Another) Native VLAN tagging question..

I have completed CCNA 3 course and am in 4 right now. I am still confused about VLAN native commands such as
sw tr na vl xxx
When this is on a trunk port, what does it mean?
Thanks....

"So does that mean that before the packet goes onto the trunk link it is put into the native VLAN then when it exits the trunk link (on the other side) it is stripped of the VLAN info? "
No, what your prior quotation decribed is what a switch should do with untagged frames received on a port defined as a VLAN trunk.
The VLAN tags informs the switch what VLAN a frames belongs to when it is received on a VLAN trunk port, but without such a tag, how does the switch know the intended VLAN? It doesn't, from the frame itself. So, we can often configure a trunk port to place any untagged frames into one VLAN of our choice. In theory, once we define what VLAN untagged frames will be considered a member of, tagged frames, for that VLAN could also be accepted. Both should be treated the same by the receiving switch.
As for a switch sending packets out a VLAN trunk, normally you would expect all packets to be VLAN tagged although a switch might support sending one particular VLAN frames without tags to support a device, such as the PC described in your quotation, that doesn't understand how to process, or expect, tagged frames.
If you're wondering how this all comes to be, consider a PC that knows nothing about VLAN tags is connected to an IP phone which does (which connects to the network) and you want to place the two devices on different VLANs. As the PC traffic transits the phone could, in theory, wrap/unwrap the PC traffic with VLANs tags when working with the network switch. However, if the phone fails, you can design the IP phone hardware to keep the link good from PC to the network, but then the IP phone PC VLAN processing would be lost. So for that reason, and the reason, we might want to add/remove an IP phone "in front" of the PC, we want to continue to support untagged frames to/from the PC.
Altough the frames to the PC are untagged, since we can configure what VLAN untagged frame should be considered per port, we can have different PCs (on different ports) in different VLANs on the switch. (This is very similar to port based VLANs, but instead of being limited to one logical VLAN per port, we're limited to one untagged VLAN per port but can have multiple tagged VLANs per port.)

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

Similar Messages

Maybe you are looking for