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

Similar Messages

  • WS-C3750X-48T-L and tag native vlan

    Hi guys,
    I have recently bought a new cisco switch : WS-C3750X-48T-L
    Switch Ports Model              SW Version            SW Image                 
    *    1 54    WS-C3750X-48       12.2(55)SE5           C3750E-UNIVERSALK9-M
    with this licence :
    Index 1 Feature: ipservices     
        Period left: 8  weeks 4  days
        License Type: Evaluation
        License State: Active, Not in Use, EULA not accepted
        License Priority: None
        License Count: Non-Counted
    Index 2 Feature: ipbase         
        Period left: 0  minute  0  second  
    Index 3 Feature: lanbase        
        Period left: Life time
        License Type: Permanent
        License State: Active, In Use
        License Priority: Medium
        License Count: Non-Counted
    I want to tag all native vlan traffic from this switch with the command :
    vlan dot1q tag native.
    I can't see this command on the command line interface. How can I reach this option ?
    Have I to pay something ?
    Thanks for your answers.

    Probably is a license limitation: "Each Cisco Catalyst 3750-E/3560-E or 3750-X/3560-X system is loaded with a universal Cisco IOS® Software image. Universal Cisco IOS Software images contain all Cisco IOS Software features. The level of Cisco IOS Software functionality available is determined by the combination of one (or more) licenses installed on the device."
    More info here: http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3560-x-series-switches/white_paper_c11-579326.html
    You have a lan base license active and in use:
    Index 3 Feature: lanbase        
        Period left: Life time
        License Type: Permanent
        License State: Active, In Use
        License Priority: Medium
        License Count: Non-Counted
    You have an ip service test license but is not active:
    ndex 1 Feature: ipservices     
        Period left: 8  weeks 4  days
        License Type: Evaluation
        License State: Active, Not in Use, EULA not accepted
        License Priority: None
        License Count: Non-Counted
    For more informations about how activate a licence use this link:
    https://supportforums.cisco.com/document/69361/licensing-290035003700
    Regards.

  • "vlan dot1q tag native" end-to-end QoS switched network

    Guys,
    Can I use this in my switched network design, (without using 802.1q tunneling as documentation always seems to mention this vlan in a vlan scenario???)
    I have native vlans and I want to act upon the 802.1p CoS field from end-to-end in my switched network. If the packet happens to be in a native vlan, I cannot do this.
    ie
    pc------accessswitch--------distswitch/rtr
    between access and distribution, there is a dot1q trunk, and the native vlan is the vlan what the pc is in
    Choices.
    run this comand vlan dot1q tag native
    dont have a native vlan, ie have vlan 1 (default as native) on the dot1q up to the dist
    or act only upon L3 dscp
    Can anyone help?
    Many thx,
    Ken

    Hi there,
    Many thx for that. This I understand and the question was really, if I wanted to use a dot1p tag in the dot1q header, but the vlan that the PC was on was the same vlan as the native vlan on the dot1q trunk, what is the best option to ensure I can action qos.
    Just trust dscp on the trunks always
    tag the native,
    or just dont run a native vlan
    I hope this makes sense. Sorry if I was a little confusing b4.
    Thx
    Ken

  • 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

  • No native VLAN in 1130 AG AP

    I have switches in my network that doesn't support native VLAN. If no native VLAN is configured in 1130 AP (all vlans tagged), which VLAN is used for IAPP protocol?
    Thanks in advance

    VLAN1 will be used for IAPP Protocol.

  • Native vlan

    can anybody told me in detail
    1) what is tagged traffic
    2) what is untagged traffic
    Kindly explain me in term of native vlan... funda

    Over a dot1q trunk, traffic in VLANs other than Native VLAN is tagged with a 4 byte header which has the following fields
    http://www.cisco.com/warp/public/473/741_4.html#topic2
    Native VLAN does not have this tag. Newer switches/IOS does have an option to tag native VLAN as well. The above page has additional info which you will find useful.
    PS:Rate useful posts

  • 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

  • 3750-x and vlan dot1q tag native command

    Hello,
    I have a 3750-X stack with the following HW & SW revisions:
    Cisco-3750-x-stack>show version
    Cisco IOS Software, C3750E Software (C3750E-UNIVERSALK9NPE-M), Version 15.0(2)SE4, RELEASE SOFTWARE (fc1)
    Technical Support: http://www.cisco.com/techsupport
    sCopyright (c) 1986-2013 by Cisco Systems, Inc.
    Compiled Wed 26-Jun-13 01:47 by prod_rel_team
    ROM: Bootstrap program is C3750E boot loader
    BOOTLDR: C3750E Boot Loader (C3750X-HBOOT-M) Version 12.2(53r)SE2, RELEASE SOFTWARE (fc1)
    Cisco-3750-x-stack uptime is 1 day, 6 hours, 56 minutes
    System returned to ROM by power-on
    System restarted at 20:27:32 UTC Tue Mar 29 2011
    System image file is "flash:/c3750e-universalk9npe-mz.150-2.SE4/c3750e-universalk9npe-mz.150-2.SE4.bin"
    License Level: lanbase
    License Type: Permanent
    Next reload license Level: lanbase
    cisco WS-C3750X-48P (PowerPC405) processor (revision A0) with 262144K bytes of memory.
    Processor board ID FDO1524K1J2
    Last reset from power-on
    2 Virtual Ethernet interfaces
    1 FastEthernet interface
    104 Gigabit Ethernet interfaces
    4 Ten Gigabit Ethernet interfaces
    The password-recovery mechanism is enabled.
    512K bytes of flash-simulated non-volatile configuration memory.
    Base ethernet MAC Address       :
    Motherboard assembly number     : 73-12553-05
    Motherboard serial number       : 
    Model revision number           : A0
    Motherboard revision number     : C0
    Model number                    : WS-C3750X-48P-L
    Daughterboard assembly number   : 800-32727-01
    Daughterboard serial number     : 
    System serial number            : 
    Top Assembly Part Number        : 800-31324-02
    Top Assembly Revision Number    : C0
    Version ID                      : V02
    CLEI Code Number                : 
    Hardware Board Revision Number  : 0x03
    Switch Ports Model              SW Version            SW Image
    *    1 54    WS-C3750X-48P      15.0(2)SE4            C3750E-UNIVERSALK9NPE-M
         2 54    WS-C3750X-48P      15.0(2)SE4            C3750E-UNIVERSALK9NPE-M
    Switch 02
    Switch Uptime                   : 1 day, 6 hours, 56 minutes
    Base ethernet MAC Address       : 
    Motherboard assembly number     : 73-12553-06
    Motherboard serial number       : 
    Model revision number           : A0
    Motherboard revision number     : A0
    Model number                    : WS-C3750X-48P-L
    Daughterboard assembly number   : 800-32727-03
    Daughterboard serial number     : 
    System serial number            : 
    Top assembly part number        : 800-31324-03
    Top assembly revision number    : B0
    Version ID                      : V03
    CLEI Code Number                : 
    License Level                   : lanbase
    License Type                    : Permanent
    Next reboot licensing Level     : lanbase
    Configuration register is 0xF
    I am trying to setup native vlan tagging using the command "vlan dot1q tag native".   I am entering this when I am in privileged exec mode, and then config mode.   When enter vlan ? it does not show dot1q as an option.   Any thoughts on what I might be missing?   What I am trying to achieve is all ingress untagged traffic (from my Meru controller) will be tagged with VLAN tag 101 as it progresses through my network, and any tagged traffic on vlan 101 which is destined for the port where my Meru controller is located will be delivered to the Meru controller untagged.   I can set this up in this manner on a SG300 Cisco switch, and I believe this is what "vlan dot1q tag native" will achieve if I am understanding correctly.
    I welcome suggestions on both why the "vlan dot1q tag native" won't work, and on what I am trying to accomplish.
    Thx
    Bryan

    Hi Aaron,
    Thank you for the quick reply.  
    The Meru controller uses untagged traffic to talk between the controller and the APs.   It also uses tagged traffic to talk between the controller and the VLANs which I have associated with each of the SSIDs.   I am trying to find a way to do what is normally done with an access port, but do that with an LACP group (801.Q trunk).   Where the untagged traffic entering the network from the controller gets tagged as VLAN 101 as it transits the network, and then traffic which is delivered to that 801.Q trunk on VLAN 101 has the tag removed, but all other traffic entering that port will be appropriately tagged, and the tagged traffic along with the tags well egress from that port to the Meru controller.    I have done this before on a Cisco SG300 switch, but not on the 3750-X core in my home.   If I can't make this work I can front end the Meru controller with an SG300 but now I will be introducing another potential point of failure.
    Also, do you have any idea why the "vlan dot1q tag native" would not be accepted by the IOS version on this switch stack?
    Thx
    Bryan

  • Does the dot1q native VLAN need to be defined on the switch?

    I understand the issues with using VLAN 1 as the native VLAN on a dot1q trunk. I follow best practices and change the native VLAN to a VLAN that does not carry any other traffic (switchport trunk native vlan x). I usually go a step further and do not define the VLAN in the switch configuration. This way if traffic bleeds into the native VLAN because it is untagged then it cannot go anywhere.   So if I use VLAN 999 as the native VLAN, I do not create VLAN 999 on the switch.   I’m curious if anyone else does this or if there are any thoughts on whether this is a good or bad practice? 

    If you are tagging your native VLAN but do not have that VLAN in the vlan database - it makes no difference if the VLAN exists or not in my opinion. All the vlans on your trunks would be tagged anyway.
    It seems like a clever idea, but not sure if it provides any benefit.

  • WISM Native Vlan tagged

    Hello , We have 6513 Core Switch and WISM , If I ping from the access points subnet to the WISM IP address there is so many request time out and the number of Access Points registered is going up and down
    In the core switch we are tagging the native Vlan as you can see below
    CORE-SWITCH2#sh run | i tag
    vlan dot1q tag native
    and we don't have the command wism module 9 controller 1 native-vlan X because the native vlan is tagged
    could this be the reason ? that its mandatory that the native VLAN is not tagged for the Cisco WISM configuration
    your reply and feed back is highly appreciated
    many thanks

    Cisco recommends to TAG the management interface. Cisco use to state to configure the managment vlan as native. It makes it easier for QoS as well when all vlans are TAGGED.
    What is key is all your WISMs managment interfaces need to be TAGGED or UNTAGGED. You cant have a mix.
    How are yours set up ?

  • 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

  • Native Vlan and tagging

    Hi!
    I have a particular installation on a customer site.
    The management vlan is the number 1 (which is the native vlan) for the whole network and all the switches tag the native vlan.
    So when I plug my AP on a port of a switch configured in trunk mode, it doesn't work.
    How can I resolve this issue?
    Thanks

    Yes, you can specify the native VLAN, though I am not sure if that will enable tagging of that VLAN or not. You might have to try it yourself to see. See the following link for pictures of the pages in question.
    http://www.cisco.com/en/US/products/ps6087/products_tech_note09186a0080736123.shtml#t12
    Because I think it will require a reboot after enabling HREAP but before setting up VLAN support, you might need to set it as an access port while making the changes.
    1. Do not use VLANs for your H-REAP deployment and set the access point switch ports as Access ports in the VLAN you want your users to be in. The AP will need an IP in the user VLAN, but that is not usually a problem. If you do not need multiple user VLANs from different SSIDs, this will be the easiest option.
    2. Disable native VLAN tagging for the ports with APs with the command I listed above.

  • Native VLAN problem when using dot1q tunnel on ME3600

    We have problems with a VPLS service for a Customer. The edge devices are Cat3560 and ME3600 (where the Customers sites are connected).
    When the edge device are ME3600 we have problems getting the traffic on the Native VLAN from the Customer out in the VPLS cloud.
    No problems using Cat3560
    No problems using ME3600 and tagged VLAN
    Config on ME3600
    interface GigabitEthernet0/2
    description VPLS_CustomerA
    switchport access vlan 888
    switchport trunk allowed vlan none
    switchport mode trunk
    mtu 9800
    storm-control broadcast level 0.10 0.05
    storm-control action trap
    no cdp enable
    spanning-tree bpdufilter enable
    service instance 64 ethernet
      encapsulation untagged , dot1q 1-4094
      bridge-domain 64
    Any ideas?
    /Jorgen

    Can you remove this line from your configuration "
    switchport access vlan 888" since it is an invalid configuration for EVC.
    Reconfigure the port after making the above change. What kind of traffic you are expecting on the native vlan?
    L2 protocol is dsable by default so STP, CDP and other control protocols will not work unless you enable L2PT forward or tunnel.

  • 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

  • Native VLAN tagging work-around?

    Good Day!
    Story here is that I am upgrading my 6500 Metro Ethernet core switch from CatOS to IOS and implementing several security components - one in question is implementing 'vlan dot1q tag native' global command on core switch. Most of my PE switches are 3550 series and are compatible with this configuration. The problem is that I also have several remote legacy 3508G switches that I need to support, and they will not accept this command.
    Is anyone aware of a work-around config for these 3508s? So far have not found any help on CCO...
    Thanks!

    Don't know if you can do this on a Cat6500 running IOS, but here's my idea:
    Set the native VLAN on the 3508G end of the 802.1Q trunk to a VLAN that is not going to be used anywhere for access, and match the native VLAN specification on your 6500's corresponding interface. Then, remove that VLAN from the trunk at both ends.
    The way I read it, on the 6500 the "vlan dot1q tag native" command would tag outgoing traffic on the native VLAN; and would drop all incoming traffic on the native VLAN that wasn't tagged. But none of that will matter, because removing that one VLAN from the allowed VLAN list on the trunk will leave you with only tagged VLAN traffic on the trunk from the 3508G. CDP will see that the native VLAN is set the same at each end (if you use CDP), so it won't flag any mismatches there. You just won't use the native VLAN on the trunk.
    I'm doing something similar with CatOS on a 6509 and 2950G access switches. Setting native VLAN to 1 (the default) on both ends, which makes it untagged; and then removing VLAN 1 from the trunk on both sides, leaving me with only tagged traffic on the trunk.
    Now, VLAN 1 is a special case, you can't remove it completely from the allowed VLAN list on a 2950G. The documentation refers to it as "minimizing" VLAN 1: CDP and VTP traffic will still pass over it, as will a couple of other Cisco-centric things; but no user traffic, and no STP BPDUs. Testing it today, I verified the CDP and VTP traffic work in both directions after I cleared VLAN 1 from the trunk and had only one customer VLAN, tagged, on it.
    In your situation, you can't remove VLAN 1 at all from a 3508G XL trunk. So just pick another VLAN to throw away as the native VLAN that you remove from the trunk, and transmit VLAN1 tagged across it.
    I think DTP uses the native VLAN; so the only drawback to my idea is that you have to manually set the trunk mode rather than letting the switches negotiate it out. (No problem for me, I set them all manually anyway.)
    Hope this helps.

Maybe you are looking for