Native VLAN

Discussion in 'Cisco' started by Harley D., Nov 19, 2003.

  1. Harley D.

    Harley D. Guest

    Can someone explain what a native VLAN is and how exactly does it work?

    Thanks
    HD
     
    Harley D., Nov 19, 2003
    #1
    1. Advertisements

  2. Harley D.

    phase90 Guest

    Harley,

    In a trunk, which is either ISL or Dot1q, traffic belonging
    to the native vlan does not get a trunk encapsulation. Its frames travel as
    they would on a native ethernet - hence native vlan. Traffic in the
    non-native vlans have the additional trunk encapsulations on them which
    identify which vlan the traffic belongs to.



    Jerry
     
    phase90, Nov 19, 2003
    #2
    1. Advertisements

  3. In effect, it sounds like assigning a native vlan allows the switchport can
    operate both in trunk mode and access mode concurrently. Does anyone have
    an application that takes advantage of this?

    I think one application is with Cisco IP phones which themselves contain a
    3-port mini switch which allows a PC to be plugged into them. When setting
    up the 3550 switchport for the IP phone, the voice and data traffic can be
    kept segregated for separate QoS treatment by configuring a voice vlan that
    is part of an 802.1q trunk (to handle the 802.1q encapsulated voice traffic
    from the phone) and leaving a native vlan for data from the PC. My
    understanding may be a little weak on this, but this is the impression I got
    from reading the 3550 User Reference.

    Robert
     
    Bob by The Bay, Nov 20, 2003
    #3
  4. Harley D.

    Andre Beck Guest

    I wouldn't explain it this way. You also have to consider that "trunk
    port" and "access port" are strictly Cisco nomenclature, they don't exist
    in 802.1pQ and may even have another meaning in the outside world (like
    "trunk" is used by other vendors to name the construct that Cisco names
    a Portchannel/Etherchannel).

    The question is simply: If I have a tagged link, what do I do with frames
    that I receive on that link, but untagged? The (always existing) native
    VLAN names the VID to which these frames are mapped. And if it is this
    way, why should I transmit frames of this VLAN with a tag? So, the native
    VLAN names the VID that, when leaving a port, is sent untagged. There
    is some potential for interoperability problems here (some vendors allow
    *only* tagged frames on trunks, others [like Cisco with the XLs] always
    wanted to transmit some VID untagged), but besides that, it is actually
    a nice idea, because it allows for limited VID translation. The original
    intention is likely that a factory reset switch behaves as expected, what
    you can achieve by defining that initially, Default VLAN == Native VLAN ==
    Untagged. In this setup, having all ports access ports in the default
    VLAN is actually the same as having them all be trunk ports with just
    the default VLAN on the trunks. Allows for easier deployment of additional
    VLANs, automated trunk/access negotiations and so forth.
    The basic application of that is simply the collection of protocols that
    run on a trunk untagged: VTP, CDP...
    I haven't groked voice VLANs completely yet, but they appear to be some-
    thing special, as they have to be explicitely configured. But maybe this
    is just so that the phone has a way to learn the actual VID to use from
    the switch.

    In general, the vast majority (at least that I've seen yet) of imple-
    mentations of tagged links between switches in inter vendor land uses
    the scheme of "default VLAN untagged, all other VLANs tagged". So does
    Cisco (by default), and that's what the "native VLAN" setting of a
    switchport is all about: It sets the "port VLAN ID" as well as the
    "untagged egress VID" as known from other 802.1Q implementations. Indeed
    this is a mixture of "access port" and "trunk port" behavior, but that's
    just because these two are just names, while 802.1Q in practice is a
    little bit more flexible.
     
    Andre Beck, Nov 21, 2003
    #4
  5. Harley D.

    Steinar Haug Guest

    [Andre Beck]

    | In general, the vast majority (at least that I've seen yet) of imple-
    | mentations of tagged links between switches in inter vendor land uses
    | the scheme of "default VLAN untagged, all other VLANs tagged". So does
    | Cisco (by default), and that's what the "native VLAN" setting of a
    | switchport is all about: It sets the "port VLAN ID" as well as the
    | "untagged egress VID" as known from other 802.1Q implementations.

    Fortunately, Cisco lets you do away with the untagged VLAN completely
    with the "vlan dot1q tag native" - not available on the 3500XL series,
    but works nicely on newer switches.

    With "vlan dot1q tag native" all outgoing frames are tagged, and any
    incoming frames without a tag are discarded.

    Steinar Haug, Nethelp consulting,
     
    Steinar Haug, Nov 21, 2003
    #5
  6. Harley D.

    Illusion Guest

    We setup our switches with all ports in the Default VLAN and the uplink
    fiber port in 802.1q trunk mode. The trunk carries untagged default VLAN
    traffic and also tagged traffic for our management VLAN (tag 100). Is this
    the best way to set things up? I often hear people saying that you should
    move all the ports off the default VLAN but I don't understand why?

    Cheers, Dan
     
    Illusion, Nov 24, 2003
    #6
  7. Harley D.

    Blaz Zupan Guest

    You'll know why, when you connect a network of switches administered by someone
    else to one of the ports on your switch. Suddenly, all your VLANs will disappear
    and VLANs from the other switches will appear instead. Of course only if you
    have VTP active and set to "slave" mode. It happened to us and believe me, it
    was painful. VTP runs over VLAN 1. Since then, I turn off VTP on any switch I
    come across. The person at Cisco making this the default should be shot :-(
     
    Blaz Zupan, Nov 24, 2003
    #7
  8. Harley D.

    Illusion Guest

    I think I have VTP set to transparent!

    Cheers, Dan
     
    Illusion, Nov 25, 2003
    #8
  9. Harley D.

    Andre Beck Guest

    Ouch. But that shouldn't happen with a decent VTP domain and password
    unless you almost intend to break it, should it?
    It is actually irrelevant whether your boxes are VTP Client or VTP Server.
    Both will happily overwrite their vlan.dat when someone announces a higher
    revision. There is no way to freeze your VTP domain (except from setting
    all switches to VTP tranmsparent, but that breaks convenience).
    Instead of shooting him, he should be locked into a room until he comes
    out with an implementation in the tradition of "no cdp enable" that
    allows you to do

    int GiX/Y
    switchport mode trunk
    switchport nonegotiate
    switchport trunk allowed-vlan [...]
    no cdp enable
    no vtp enable

    so you can define a decent administrative border of VTP domains. And if he
    is locked there, I'd also like a VID map that allows you to map the VID
    tags of the other domain to your own tags. If it's possible in hardware
    to map DSCPs to 802.1p precedences, it shouldn't be any harder to do a
    table based VID tag rewriting. TCAM is plenty...
     
    Andre Beck, Nov 26, 2003
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.