native vlan question

Discussion in 'Cisco' started by aaabbb16@hotmail.com, Apr 15, 2008.

  1. Guest

    A lot of people ask native vlan question.
    I think using "vlan dot1q tag native" should eliminate this question.
    at least for sw---sw connection. (all tagged just like isl)
    I may not fully understand what's purpose why cisco make "native
    vlan".
    Some article say because of backward compatible with 802.3.
    Can anyone give an example?

    TIA,
    st
     
    , Apr 15, 2008
    #1
    1. Advertising

  2. Trendkill Guest

    On Apr 15, 3:51 am, wrote:
    > A lot of people ask native vlan question.
    > I think using "vlan dot1q tag native" should eliminate this question.
    > at least for sw---sw connection. (all tagged just like isl)
    > I may not fully understand what's purpose why cisco make "native
    > vlan".
    > Some article say because of backward compatible with 802.3.
    > Can anyone give an example?
    >
    > TIA,
    > st


    Here are some good posts on this topic. Probably better than one of
    us typing up several paragraphs. The second article explains native
    vlan / vlan 1, and management interface concerns.

    http://www.velocityreviews.com/forums/t30335-native-vlan.html
    http://www.velocityreviews.com/forums/t40938-native-and-management-vlan-quotvlan-1quot.html
     
    Trendkill, Apr 15, 2008
    #2
    1. Advertising

  3. Guest

    On 4ÔÂ15ÈÕ, ÉÏÎç4ʱ13·Ö, Trendkill <> wrote:
    > On Apr 15, 3:51 am, wrote:
    >
    > > A lot of people ask native vlan question.
    > > I think using "vlan dot1q tag native" should eliminate this question.
    > > at least for sw---sw connection. (all tagged just like isl)
    > > I may not fully understand what's purpose why cisco make "native
    > > vlan".
    > > Some article say because of backward compatible with 802.3.
    > > Can anyone give an example?

    >
    > > TIA,
    > > st

    >
    > Here are some good posts on this topic. Probably better than one of
    > us typing up several paragraphs. The second article explains native
    > vlan / vlan 1, and management interface concerns.
    >
    > http://www.velocityreviews.com/foru...ws.com/forums/t40938-native-and-management-vl...


    Still confuse something.
     
    , Apr 15, 2008
    #3
  4. sp3gcf

    Joined:
    Nov 1, 2007
    Messages:
    7
    Cisco's proprietary ISL doesn't support Natvie Vlan, an IEEE's 802.1Q does support Native Vlan and was intorduced years later..

    -Tom
     
    sp3gcf, Apr 15, 2008
    #4
  5. stephen Guest

    <> wrote in message
    news:...
    > A lot of people ask native vlan question.
    > I think using "vlan dot1q tag native" should eliminate this question.
    > at least for sw---sw connection. (all tagged just like isl)
    > I may not fully understand what's purpose why cisco make "native
    > vlan".


    cisco didnt invent this - it is part of 802.1Q.

    > Some article say because of backward compatible with 802.3.


    i suggest you try to find the standard and read around that,
    maybe start at www.ieee.org

    AFAIR some of the standards docs are without charge for Ethernet.

    > Can anyone give an example?


    there are 2 Qs to think about.

    1. set a port to be tagged
    - what do you do with a packet that arrives with no tag?

    the 2 common answers are to throw it away, or to put it into some sort of
    "default VLAN" - that is what untagged means for incoming packets.

    not putting a tag on outbound packets form that VLAN on that port allows 2
    way comms.

    this sounds silly - but it is what often needs to happen when you hook up an
    unconfigured device to set it up.

    2. what happens when you want to split up 2 streams of packets on a port?

    sometimes you have a device that will add its own stream of packets to a set
    it gets from elsewhere
    - the classic case is an IP phone where there is a plug on the phone to
    connect a PC.
    - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    doesnt have the horsepower to wrap a tag around every packet.
    - but you want the phone traffic kept separate from PC (security, QoS and
    so on).

    So - pass the PC packet thru untagged, and tag the phone traffic.
    At the switch the PC "stuff" is untagged and goes into the native VLAN,
    phone traffic is tagged and goes into a different VLAN.
    >
    > TIA,
    > st
    >

    --
    Regards

    - replace xyz with ntl
     
    stephen, Apr 15, 2008
    #5
  6. Guest

    On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    > <> wrote in message
    >
    > news:...
    >
    > > A lot of people ask native vlan question.
    > > I think using "vlan dot1q tag native" should eliminate this question.
    > > at least for sw---sw connection. (all tagged just like isl)
    > > I may not fully understand what's purpose why cisco make "native
    > > vlan".

    >
    > cisco didnt invent this - it is part of 802.1Q.
    >
    > > Some article say because of backward compatible with 802.3.

    >
    > i suggest you try to find the standard and read around that,
    > maybe start atwww.ieee.org
    >
    > AFAIR some of the standards docs are without charge for Ethernet.
    >
    > > Can anyone give an example?

    >
    > there are 2 Qs to think about.
    >
    > 1. set a port to be tagged
    > - what do you do with a packet that arrives with no tag?
    >
    > the 2 common answers are to throw it away, or to put it into some sort of
    > "default VLAN" - that is what untagged means for incoming packets.
    >
    > not putting a tag on outbound packets form that VLAN on that port allows 2
    > way comms.
    >
    > this sounds silly - but it is what often needs to happen when you hook up an
    > unconfigured device to set it up.
    >
    > 2. what happens when you want to split up 2 streams of packets on a port?
    >
    > sometimes you have a device that will add its own stream of packets to a set
    > it gets from elsewhere
    > - the classic case is an IP phone where there is a plug on the phone to
    > connect a PC.
    > - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    > doesnt have the horsepower to wrap a tag around every packet.
    > - but you want the phone traffic kept separate from PC (security, QoS and
    > so on).
    >
    > So - pass the PC packet thru untagged, and tag the phone traffic.
    > At the switch the PC "stuff" is untagged and goes into the native VLAN,
    > phone traffic is tagged and goes into a different VLAN.
    >
    > > TIA,
    > > st

    >
    > --
    > Regards
    >
    > - replace xyz with ntl


    Thanks,
    For "Some article say because of backward compatible with 802.3"
    they may think far end is Hub or switch/bridge which does not support
    802.3,
    right?
    One more question, when a access port receive a untag frame, does it
    add
    a 802.1q tag or some other tag to make sure it can go same vlan inside
    of
    this switch?
     
    , Apr 16, 2008
    #6
  7. Guest

    On 16 Apr, 05:31, wrote:
    > On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    >
    >
    >
    >
    >
    > > <> wrote in message

    >
    > >news:...

    >
    > > > A lot of people ask native vlan question.
    > > > I think using "vlan dot1q tag native" should eliminate this question.
    > > > at least for sw---sw connection. (all tagged just like isl)
    > > > I may not fully understand what's purpose why cisco make "native
    > > > vlan".

    >
    > > cisco didnt invent this - it is part of 802.1Q.

    >
    > > > Some article say because of backward compatible with 802.3.

    >
    > > i suggest you try to find the standard and read around that,
    > > maybe start atwww.ieee.org

    >
    > > AFAIR some of the standards docs are without charge for Ethernet.

    >
    > > > Can anyone give an example?

    >
    > > there are 2 Qs to think about.

    >
    > > 1. set a port to be tagged
    > > - what do you do with a packet that arrives with no tag?

    >
    > > the 2 common answers are to throw it away, or to put it into some sort of
    > > "default VLAN" - that is what untagged means for incoming packets.

    >
    > > not putting a tag on outbound packets form that VLAN on that port allows 2
    > > way comms.

    >
    > > this sounds silly - but it is what often needs to happen when you hook up an
    > > unconfigured device to set it up.

    >
    > > 2. what happens when you want to split up 2 streams of packets on a port?

    >
    > > sometimes you have a device that will add its own stream of packets to a set
    > > it gets from elsewhere
    > > - the classic case is an IP phone where there is a plug on the phone to
    > > connect a PC.
    > > - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    > > doesnt have the horsepower to wrap a tag around every packet.
    > > - but you want the phone traffic kept separate from PC (security, QoS and
    > > so on).

    >
    > > So - pass the PC packet thru untagged, and tag the phone traffic.
    > > At the switch the PC "stuff" is untagged and goes into the native VLAN,
    > > phone traffic is tagged and goes into a different VLAN.

    >
    > > > TIA,
    > > > st

    >
    > > --
    > > Regards

    >
    > > - replace xyz with ntl

    >
    > Thanks,
    > For "Some article say because of backward compatible with 802.3"
    > they may think far end is Hub or switch/bridge which does not support
    > 802.3,
    > right?
    > One more question, when a access port receive a untag frame, does it
    > add
    > a 802.1q tag or some other tag to make sure it can go same vlan inside
    > of
    > this switch?-


    I have read something somewhere that stated that the Tags are
    stripped off when frames enter the switch however clearly equivalent
    information is carried 'with' the frame 'through' the switch.

    So as far as we the Users are concerned I think that
    you would have a good way of thinking about it if
    you assumed that such a tag was used.
     
    , Apr 16, 2008
    #7
  8. News Reader Guest

    wrote:
    > On 16 Apr, 05:31, wrote:
    >> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    >>
    >>
    >>
    >>
    >>
    >>> <> wrote in message
    >>> news:...
    >>>> A lot of people ask native vlan question.
    >>>> I think using "vlan dot1q tag native" should eliminate this question.
    >>>> at least for sw---sw connection. (all tagged just like isl)
    >>>> I may not fully understand what's purpose why cisco make "native
    >>>> vlan".
    >>> cisco didnt invent this - it is part of 802.1Q.
    >>>> Some article say because of backward compatible with 802.3.
    >>> i suggest you try to find the standard and read around that,
    >>> maybe start atwww.ieee.org
    >>> AFAIR some of the standards docs are without charge for Ethernet.
    >>>> Can anyone give an example?
    >>> there are 2 Qs to think about.
    >>> 1. set a port to be tagged
    >>> - what do you do with a packet that arrives with no tag?
    >>> the 2 common answers are to throw it away, or to put it into some sort of
    >>> "default VLAN" - that is what untagged means for incoming packets.
    >>> not putting a tag on outbound packets form that VLAN on that port allows 2
    >>> way comms.
    >>> this sounds silly - but it is what often needs to happen when you hook up an
    >>> unconfigured device to set it up.
    >>> 2. what happens when you want to split up 2 streams of packets on a port?
    >>> sometimes you have a device that will add its own stream of packets to a set
    >>> it gets from elsewhere
    >>> - the classic case is an IP phone where there is a plug on the phone to
    >>> connect a PC.
    >>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    >>> doesnt have the horsepower to wrap a tag around every packet.
    >>> - but you want the phone traffic kept separate from PC (security, QoS and
    >>> so on).
    >>> So - pass the PC packet thru untagged, and tag the phone traffic.
    >>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    >>> phone traffic is tagged and goes into a different VLAN.
    >>>> TIA,
    >>>> st
    >>> --
    >>> Regards
    >>> - replace xyz with ntl

    >> Thanks,
    >> For "Some article say because of backward compatible with 802.3"
    >> they may think far end is Hub or switch/bridge which does not support
    >> 802.3,
    >> right?
    >> One more question, when a access port receive a untag frame, does it
    >> add
    >> a 802.1q tag or some other tag to make sure it can go same vlan inside
    >> of
    >> this switch?-

    >
    > I have read something somewhere that stated that the Tags are
    > stripped off when frames enter the switch however clearly equivalent
    > information is carried 'with' the frame 'through' the switch.
    >
    > So as far as we the Users are concerned I think that
    > you would have a good way of thinking about it if
    > you assumed that such a tag was used.
    >
    >


    When you configure a port-based VLAN on a switch, you are telling the
    switch which ports are to be grouped into a common broadcast domain
    (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    it knows which ports it is permitted to forward too based on the
    separation of broadcast domains (VLANs). Of course, if the switch has
    learned the port that the destination host resides on, it will only
    forward it out that port within the appropriate VLAN (assuming a unicast
    packet). Broadcast packets may be flooded to all ports within a VLAN.

    Best Regards,
    News Reader
     
    News Reader, Apr 16, 2008
    #8
  9. Guest

    On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    > wrote:
    > > On 16 Apr, 05:31, wrote:
    > >> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:

    >
    > >>> <> wrote in message
    > >>>news:....
    > >>>> A lot of people ask native vlan question.
    > >>>> I think using "vlan dot1q tag native" should eliminate this question.
    > >>>> at least for sw---sw connection. (all tagged just like isl)
    > >>>> I may not fully understand what's purpose why cisco make "native
    > >>>> vlan".
    > >>> cisco didnt invent this - it is part of 802.1Q.
    > >>>> Some article say because of backward compatible with 802.3.
    > >>> i suggest you try to find the standard and read around that,
    > >>> maybe start atwww.ieee.org
    > >>> AFAIR some of the standards docs are without charge for Ethernet.
    > >>>> Can anyone give an example?
    > >>> there are 2 Qs to think about.
    > >>> 1. set a port to be tagged
    > >>> - what do you do with a packet that arrives with no tag?
    > >>> the 2 common answers are to throw it away, or to put it into some sort of
    > >>> "default VLAN" - that is what untagged means for incoming packets.
    > >>> not putting a tag on outbound packets form that VLAN on that port allows 2
    > >>> way comms.
    > >>> this sounds silly - but it is what often needs to happen when you hook up an
    > >>> unconfigured device to set it up.
    > >>> 2. what happens when you want to split up 2 streams of packets on a port?
    > >>> sometimes you have a device that will add its own stream of packets to a set
    > >>> it gets from elsewhere
    > >>> - the classic case is an IP phone where there is a plug on the phone to
    > >>> connect a PC.
    > >>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    > >>> doesnt have the horsepower to wrap a tag around every packet.
    > >>> - but you want the phone traffic kept separate from PC (security, QoS and
    > >>> so on).
    > >>> So - pass the PC packet thru untagged, and tag the phone traffic.
    > >>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    > >>> phone traffic is tagged and goes into a different VLAN.
    > >>>> TIA,
    > >>>> st
    > >>> --
    > >>> Regards
    > >>> - replace xyz with ntl
    > >> Thanks,
    > >> For "Some article say because of backward compatible with 802.3"
    > >> they may think far end is Hub or switch/bridge which does not support
    > >> 802.3,
    > >> right?
    > >> One more question, when a access port receive a untag frame, does it
    > >> add
    > >> a 802.1q tag or some other tag to make sure it can go same vlan inside
    > >> of
    > >> this switch?-

    >
    > > I have read something somewhere that stated that the Tags are
    > > stripped off when frames enter the switch however clearly equivalent
    > > information is carried 'with' the frame 'through' the switch.

    >
    > > So as far as we the Users are concerned I think that
    > > you would have a good way of thinking about it if
    > > you assumed that such a tag was used.

    >
    > When you configure a port-based VLAN on a switch, you are telling the
    > switch which ports are to be grouped into a common broadcast domain
    > (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    > it knows which ports it is permitted to forward too based on the
    > separation of broadcast domains (VLANs). Of course, if the switch has
    > learned the port that the destination host resides on, it will only
    > forward it out that port within the appropriate VLAN (assuming a unicast
    > packet). Broadcast packets may be flooded to all ports within a VLAN.
    >
    > Best Regards,
    > News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >
    > - ÏÔʾÒýÓõÄÎÄ×Ö -


    let me clear the second question up:
    when a access port receive a untag frame from a
    host, does it add a 802.1q tag or some other tag to make sure it can
    go same vlan inside of switch?
     
    , Apr 16, 2008
    #9
  10. News Reader Guest

    wrote:
    > On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    >> wrote:
    >>> On 16 Apr, 05:31, wrote:
    >>>> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    >>>>> <> wrote in message
    >>>>> news:...
    >>>>>> A lot of people ask native vlan question.
    >>>>>> I think using "vlan dot1q tag native" should eliminate this question.
    >>>>>> at least for sw---sw connection. (all tagged just like isl)
    >>>>>> I may not fully understand what's purpose why cisco make "native
    >>>>>> vlan".
    >>>>> cisco didnt invent this - it is part of 802.1Q.
    >>>>>> Some article say because of backward compatible with 802.3.
    >>>>> i suggest you try to find the standard and read around that,
    >>>>> maybe start atwww.ieee.org
    >>>>> AFAIR some of the standards docs are without charge for Ethernet.
    >>>>>> Can anyone give an example?
    >>>>> there are 2 Qs to think about.
    >>>>> 1. set a port to be tagged
    >>>>> - what do you do with a packet that arrives with no tag?
    >>>>> the 2 common answers are to throw it away, or to put it into some sort of
    >>>>> "default VLAN" - that is what untagged means for incoming packets.
    >>>>> not putting a tag on outbound packets form that VLAN on that port allows 2
    >>>>> way comms.
    >>>>> this sounds silly - but it is what often needs to happen when you hook up an
    >>>>> unconfigured device to set it up.
    >>>>> 2. what happens when you want to split up 2 streams of packets on a port?
    >>>>> sometimes you have a device that will add its own stream of packets to a set
    >>>>> it gets from elsewhere
    >>>>> - the classic case is an IP phone where there is a plug on the phone to
    >>>>> connect a PC.
    >>>>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    >>>>> doesnt have the horsepower to wrap a tag around every packet.
    >>>>> - but you want the phone traffic kept separate from PC (security, QoS and
    >>>>> so on).
    >>>>> So - pass the PC packet thru untagged, and tag the phone traffic.
    >>>>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    >>>>> phone traffic is tagged and goes into a different VLAN.
    >>>>>> TIA,
    >>>>>> st
    >>>>> --
    >>>>> Regards
    >>>>> - replace xyz with ntl
    >>>> Thanks,
    >>>> For "Some article say because of backward compatible with 802.3"
    >>>> they may think far end is Hub or switch/bridge which does not support
    >>>> 802.3,
    >>>> right?
    >>>> One more question, when a access port receive a untag frame, does it
    >>>> add
    >>>> a 802.1q tag or some other tag to make sure it can go same vlan inside
    >>>> of
    >>>> this switch?-
    >>> I have read something somewhere that stated that the Tags are
    >>> stripped off when frames enter the switch however clearly equivalent
    >>> information is carried 'with' the frame 'through' the switch.
    >>> So as far as we the Users are concerned I think that
    >>> you would have a good way of thinking about it if
    >>> you assumed that such a tag was used.

    >> When you configure a port-based VLAN on a switch, you are telling the
    >> switch which ports are to be grouped into a common broadcast domain
    >> (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    >> it knows which ports it is permitted to forward too based on the
    >> separation of broadcast domains (VLANs). Of course, if the switch has
    >> learned the port that the destination host resides on, it will only
    >> forward it out that port within the appropriate VLAN (assuming a unicast
    >> packet). Broadcast packets may be flooded to all ports within a VLAN.
    >>
    >> Best Regards,
    >> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>
    >> - ÏÔʾÒýÓõÄÎÄ×Ö -

    >
    > let me clear the second question up:
    > when a access port receive a untag frame from a
    > host, does it add a 802.1q tag or some other tag to make sure it can
    > go same vlan inside of switch?
    >
    >


    I would "assume" that an untagged frame (the norm) sent by a host, and
    received on a switch port that is assigned a non-native VLAN ID, would
    get tagged at the ingress port; would remain so on its journey through
    the switch, and get stripped on the egress port if the port was
    configured for "access mode".

    However, I would think that a programmer could (if desired) use some
    other construct for segregating frames within the switch, and tag frames
    as necessary as they egress onto a trunk port.

    I think your answer is likely implementation dependent, and up to the
    whims of the programmer.

    Why get hung up on such an esoteric matter, when there are so many
    practical issues to deal with?

    Best Regards,
    News Reader
     
    News Reader, Apr 16, 2008
    #10
  11. Guest

    On 4ÔÂ16ÈÕ, ÉÏÎç8ʱ05·Ö, News Reader <> wrote:
    > wrote:
    > > On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    > >> wrote:
    > >>> On 16 Apr, 05:31, wrote:
    > >>>> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    > >>>>> <> wrote in message
    > >>>>>news:...
    > >>>>>> A lot of people ask native vlan question.
    > >>>>>> I think using "vlan dot1q tag native" should eliminate this question.
    > >>>>>> at least for sw---sw connection. (all tagged just like isl)
    > >>>>>> I may not fully understand what's purpose why cisco make "native
    > >>>>>> vlan".
    > >>>>> cisco didnt invent this - it is part of 802.1Q.
    > >>>>>> Some article say because of backward compatible with 802.3.
    > >>>>> i suggest you try to find the standard and read around that,
    > >>>>> maybe start atwww.ieee.org
    > >>>>> AFAIR some of the standards docs are without charge for Ethernet.
    > >>>>>> Can anyone give an example?
    > >>>>> there are 2 Qs to think about.
    > >>>>> 1. set a port to be tagged
    > >>>>> - what do you do with a packet that arrives with no tag?
    > >>>>> the 2 common answers are to throw it away, or to put it into some sort of
    > >>>>> "default VLAN" - that is what untagged means for incoming packets.
    > >>>>> not putting a tag on outbound packets form that VLAN on that port allows 2
    > >>>>> way comms.
    > >>>>> this sounds silly - but it is what often needs to happen when you hook up an
    > >>>>> unconfigured device to set it up.
    > >>>>> 2. what happens when you want to split up 2 streams of packets on a port?
    > >>>>> sometimes you have a device that will add its own stream of packets to a set
    > >>>>> it gets from elsewhere
    > >>>>> - the classic case is an IP phone where there is a plug on the phone to
    > >>>>> connect a PC.
    > >>>>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    > >>>>> doesnt have the horsepower to wrap a tag around every packet.
    > >>>>> - but you want the phone traffic kept separate from PC (security, QoS and
    > >>>>> so on).
    > >>>>> So - pass the PC packet thru untagged, and tag the phone traffic.
    > >>>>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    > >>>>> phone traffic is tagged and goes into a different VLAN.
    > >>>>>> TIA,
    > >>>>>> st
    > >>>>> --
    > >>>>> Regards
    > >>>>> - replace xyz with ntl
    > >>>> Thanks,
    > >>>> For "Some article say because of backward compatible with 802.3"
    > >>>> they may think far end is Hub or switch/bridge which does not support
    > >>>> 802.3,
    > >>>> right?
    > >>>> One more question, when a access port receive a untag frame, does it
    > >>>> add
    > >>>> a 802.1q tag or some other tag to make sure it can go same vlan inside
    > >>>> of
    > >>>> this switch?-
    > >>> I have read something somewhere that stated that the Tags are
    > >>> stripped off when frames enter the switch however clearly equivalent
    > >>> information is carried 'with' the frame 'through' the switch.
    > >>> So as far as we the Users are concerned I think that
    > >>> you would have a good way of thinking about it if
    > >>> you assumed that such a tag was used.
    > >> When you configure a port-based VLAN on a switch, you are telling the
    > >> switch which ports are to be grouped into a common broadcast domain
    > >> (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    > >> it knows which ports it is permitted to forward too based on the
    > >> separation of broadcast domains (VLANs). Of course, if the switch has
    > >> learned the port that the destination host resides on, it will only
    > >> forward it out that port within the appropriate VLAN (assuming a unicast
    > >> packet). Broadcast packets may be flooded to all ports within a VLAN.

    >
    > >> Best Regards,
    > >> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -

    >
    > >> - ÏÔʾÒýÓõÄÎÄ×Ö -

    >
    > > let me clear the second question up:
    > > when a access port receive a untag frame from a
    > > host, does it add a 802.1q tag or some other tag to make sure it can
    > > go same vlan inside of switch?

    >
    > I would "assume" that an untagged frame (the norm) sent by a host, and
    > received on a switch port that is assigned a non-native VLAN ID, would
    > get tagged at the ingress port; would remain so on its journey through
    > the switch, and get stripped on the egress port if the port was
    > configured for "access mode".
    >
    > However, I would think that a programmer could (if desired) use some
    > other construct for segregating frames within the switch, and tag frames
    > as necessary as they egress onto a trunk port.
    >
    > I think your answer is likely implementation dependent, and up to the
    > whims of the programmer.
    >
    > Why get hung up on such an esoteric matter, when there are so many
    > practical issues to deal with?
    >
    > Best Regards,
    > News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >
    > - ÏÔʾÒýÓõÄÎÄ×Ö -


    Thanks, To raise this question is that I try to have a good understand
    mechanism of switch. Still have some questions here:

    1. Based on what you explain it. For "a non-native VLAN ID" which you
    mentioned, this ID may be or may be not 802.1q tag, it depends on
    vender how to implement it. I think it is 802.1q tag,since port
    can also
    add 802.1p if it need it (3 bit for CoS). make sense? (maybe
    venders
    have diff. way to do it.)

    2. Let's go back practical issues, from a switch config point of view,
    the
    native vlan we have is because of trunk port. only trunk port can
    assign
    native Vlan. true? if other port is assign to as same as native
    Vlan ID,
    then we say it is native vlan port. right? (assume all we talked
    here
    is access port)

    3. We know for a trunk (assume two switch connected)should assgin same
    native vlan ID on both side. otherwise some vlan can not talk for
    some
    case or may have loop. The most of switch default native vlan is
    vlan 1.
    What is purpose to assgin it to other than vlan 1 when config trunk
    port?

    4. Some article also say one benifit of native vlan is if this trunk
    failed, the
    native vlan (untagged message) can still work. What is trunk
    failed
    definition over here? What falure cause tagged frame cannot go
    through
    only untagged frame can.

    5. Is it valid that a switch trunk port to connect to a host NIC?
    (assume NIC
    is not 802.1q aware) if it is ok, it means that that server can
    only
    send/receive native vlan frame (untagged). right? what is purpose?
    it is just because of backward compatible?

    6. I remember (intel and broadcom) support 802.1q aware sever NIC.
    For somecase, say a small company that no need hosts talk bewteen
    vlans, only allow all vlans hosts talk to a server. then we can
    config a
    trunk port on switch and connect to that server. We dont need any
    routing protocol. Is that right? anyone use this way? (i know it
    has diff
    solution such as Pvlan)

    TIA,
    st
     
    , Apr 16, 2008
    #11
  12. News Reader Guest

    wrote:
    > On 4ÔÂ16ÈÕ, ÉÏÎç8ʱ05·Ö, News Reader <> wrote:
    >> wrote:
    >>> On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    >>>> wrote:
    >>>>> On 16 Apr, 05:31, wrote:
    >>>>>> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    >>>>>>> <> wrote in message
    >>>>>>> news:...
    >>>>>>>> A lot of people ask native vlan question.
    >>>>>>>> I think using "vlan dot1q tag native" should eliminate this question.
    >>>>>>>> at least for sw---sw connection. (all tagged just like isl)
    >>>>>>>> I may not fully understand what's purpose why cisco make "native
    >>>>>>>> vlan".
    >>>>>>> cisco didnt invent this - it is part of 802.1Q.
    >>>>>>>> Some article say because of backward compatible with 802.3.
    >>>>>>> i suggest you try to find the standard and read around that,
    >>>>>>> maybe start atwww.ieee.org
    >>>>>>> AFAIR some of the standards docs are without charge for Ethernet.
    >>>>>>>> Can anyone give an example?
    >>>>>>> there are 2 Qs to think about.
    >>>>>>> 1. set a port to be tagged
    >>>>>>> - what do you do with a packet that arrives with no tag?
    >>>>>>> the 2 common answers are to throw it away, or to put it into some sort of
    >>>>>>> "default VLAN" - that is what untagged means for incoming packets.
    >>>>>>> not putting a tag on outbound packets form that VLAN on that port allows 2
    >>>>>>> way comms.
    >>>>>>> this sounds silly - but it is what often needs to happen when you hook up an
    >>>>>>> unconfigured device to set it up.
    >>>>>>> 2. what happens when you want to split up 2 streams of packets on a port?
    >>>>>>> sometimes you have a device that will add its own stream of packets to a set
    >>>>>>> it gets from elsewhere
    >>>>>>> - the classic case is an IP phone where there is a plug on the phone to
    >>>>>>> connect a PC.
    >>>>>>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    >>>>>>> doesnt have the horsepower to wrap a tag around every packet.
    >>>>>>> - but you want the phone traffic kept separate from PC (security, QoS and
    >>>>>>> so on).
    >>>>>>> So - pass the PC packet thru untagged, and tag the phone traffic.
    >>>>>>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    >>>>>>> phone traffic is tagged and goes into a different VLAN.
    >>>>>>>> TIA,
    >>>>>>>> st
    >>>>>>> --
    >>>>>>> Regards
    >>>>>>> - replace xyz with ntl
    >>>>>> Thanks,
    >>>>>> For "Some article say because of backward compatible with 802.3"
    >>>>>> they may think far end is Hub or switch/bridge which does not support
    >>>>>> 802.3,
    >>>>>> right?
    >>>>>> One more question, when a access port receive a untag frame, does it
    >>>>>> add
    >>>>>> a 802.1q tag or some other tag to make sure it can go same vlan inside
    >>>>>> of
    >>>>>> this switch?-
    >>>>> I have read something somewhere that stated that the Tags are
    >>>>> stripped off when frames enter the switch however clearly equivalent
    >>>>> information is carried 'with' the frame 'through' the switch.
    >>>>> So as far as we the Users are concerned I think that
    >>>>> you would have a good way of thinking about it if
    >>>>> you assumed that such a tag was used.
    >>>> When you configure a port-based VLAN on a switch, you are telling the
    >>>> switch which ports are to be grouped into a common broadcast domain
    >>>> (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    >>>> it knows which ports it is permitted to forward too based on the
    >>>> separation of broadcast domains (VLANs). Of course, if the switch has
    >>>> learned the port that the destination host resides on, it will only
    >>>> forward it out that port within the appropriate VLAN (assuming a unicast
    >>>> packet). Broadcast packets may be flooded to all ports within a VLAN.
    >>>> Best Regards,
    >>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    >>> let me clear the second question up:
    >>> when a access port receive a untag frame from a
    >>> host, does it add a 802.1q tag or some other tag to make sure it can
    >>> go same vlan inside of switch?

    >> I would "assume" that an untagged frame (the norm) sent by a host, and
    >> received on a switch port that is assigned a non-native VLAN ID, would
    >> get tagged at the ingress port; would remain so on its journey through
    >> the switch, and get stripped on the egress port if the port was
    >> configured for "access mode".
    >>
    >> However, I would think that a programmer could (if desired) use some
    >> other construct for segregating frames within the switch, and tag frames
    >> as necessary as they egress onto a trunk port.
    >>
    >> I think your answer is likely implementation dependent, and up to the
    >> whims of the programmer.
    >>
    >> Why get hung up on such an esoteric matter, when there are so many
    >> practical issues to deal with?
    >>
    >> Best Regards,
    >> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>
    >> - ÏÔʾÒýÓõÄÎÄ×Ö -

    >
    > Thanks, To raise this question is that I try to have a good understand
    > mechanism of switch. Still have some questions here:
    >
    > 1. Based on what you explain it. For "a non-native VLAN ID" which you
    > mentioned, this ID may be or may be not 802.1q tag, it depends on
    > vender how to implement it. I think it is 802.1q tag,since port
    > can also
    > add 802.1p if it need it (3 bit for CoS). make sense? (maybe
    > venders
    > have diff. way to do it.)


    Although I offered an opinion, I don't really care what mechanism the
    programmer uses to segregate VLAN traffic as it passes through the
    switch, as long as separate broadcast domains are honored. I care about
    implementing functionality.

    >
    > 2. Let's go back practical issues, from a switch config point of view,
    > the
    > native vlan we have is because of trunk port. only trunk port can
    > assign
    > native Vlan. true? if other port is assign to as same as native
    > Vlan ID,


    The "switchport access" command on our switches permit us to assign a
    VLAN only, no reference to "native". The "switchport trunk" command
    permits defining a VLAN as 802.1Q native.

    > then we say it is native vlan port. right? (assume all we talked
    > here
    > is access port)
    >
    > 3. We know for a trunk (assume two switch connected)should assgin same
    > native vlan ID on both side. otherwise some vlan can not talk for
    > some


    The two switches should agree to tag or not to tag a given VLAN. There
    is no requirement to use a native VLAN though. More on this below.

    > case or may have loop. The most of switch default native vlan is
    > vlan 1.
    > What is purpose to assgin it to other than vlan 1 when config trunk
    > port?


    Personal preferences most likely.

    >
    > 4. Some article also say one benifit of native vlan is if this trunk
    > failed, the
    > native vlan (untagged message) can still work. What is trunk
    > failed
    > definition over here? What falure cause tagged frame cannot go
    > through
    > only untagged frame can.


    Perhaps, if you used a native VLAN as an administrative VLAN (device
    administration), it might give you some immunity from some configuration
    errors, but I'm not aware of any such failure mode.

    >
    > 5. Is it valid that a switch trunk port to connect to a host NIC?
    > (assume NIC
    > is not 802.1q aware) if it is ok, it means that that server can
    > only
    > send/receive native vlan frame (untagged). right? what is purpose?
    > it is just because of backward compatible?


    If a server/host NIC was NOT 802.1Q aware you wouldn't connect it to a
    trunk port on the switch, you'd connect it to an access port.

    >
    > 6. I remember (intel and broadcom) support 802.1q aware sever NIC.
    > For somecase, say a small company that no need hosts talk bewteen
    > vlans, only allow all vlans hosts talk to a server. then we can
    > config a
    > trunk port on switch and connect to that server. We dont need any
    > routing protocol. Is that right? anyone use this way? (i know it


    If a server NIC was 802.1Q aware, you could connect it to a trunk port
    on the switch, enabling hosts from different VLANs to access the server.
    Without a routing function, hosts in different VLANs would be isolated
    from each other.

    > has diff
    > solution such as Pvlan)
    >
    > TIA,
    > st


    There is generally no need to use a native VLAN on a trunk. In fact it
    is preferable from a security standpoint that you not use native VLANs
    due to VLAN Hopping exploitation. We assign a specific VLAN (not VLAN1)
    as the native, and then refrain from assigning any ports to the VLAN.
    The trunk is then configured to permit specific VLANs only (excluding
    the native, and excluding VLAN1). All traffic on our trunks are non-native.

    We assign all unused (shutdown) ports to a specific VLAN (again, not
    VLAN1). The default VLAN1 is not used at all.

    Best Regards,
    News Reader
     
    News Reader, Apr 16, 2008
    #12
  13. stephen Guest

    <> wrote in message
    news:...
    On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    > <> wrote in message
    >
    > news:...
    >
    > > A lot of people ask native vlan question.
    > > I think using "vlan dot1q tag native" should eliminate this question.
    > > at least for sw---sw connection. (all tagged just like isl)
    > > I may not fully understand what's purpose why cisco make "native
    > > vlan".

    >
    > cisco didnt invent this - it is part of 802.1Q.
    >
    > > Some article say because of backward compatible with 802.3.

    >
    > i suggest you try to find the standard and read around that,
    > maybe start atwww.ieee.org
    >
    > AFAIR some of the standards docs are without charge for Ethernet.
    >
    > > Can anyone give an example?

    >
    > there are 2 Qs to think about.
    >
    > 1. set a port to be tagged
    > - what do you do with a packet that arrives with no tag?
    >
    > the 2 common answers are to throw it away, or to put it into some sort of
    > "default VLAN" - that is what untagged means for incoming packets.
    >
    > not putting a tag on outbound packets form that VLAN on that port allows 2
    > way comms.
    >
    > this sounds silly - but it is what often needs to happen when you hook up

    an
    > unconfigured device to set it up.
    >
    > 2. what happens when you want to split up 2 streams of packets on a port?
    >
    > sometimes you have a device that will add its own stream of packets to a

    set
    > it gets from elsewhere
    > - the classic case is an IP phone where there is a plug on the phone to
    > connect a PC.
    > - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    > doesnt have the horsepower to wrap a tag around every packet.
    > - but you want the phone traffic kept separate from PC (security, QoS and
    > so on).
    >
    > So - pass the PC packet thru untagged, and tag the phone traffic.
    > At the switch the PC "stuff" is untagged and goes into the native VLAN,
    > phone traffic is tagged and goes into a different VLAN.
    >
    > > TIA,
    > > st

    >
    > --
    > Regards
    >
    > - replace xyz with ntl


    Thanks,
    For "Some article say because of backward compatible with 802.3"
    they may think far end is Hub or switch/bridge which does not support
    802.3,
    right?

    SPH - possibly, depends on where you found this.

    One more question, when a access port receive a untag frame, does it
    add
    a 802.1q tag or some other tag to make sure it can go same vlan inside
    of
    this switch?

    SH - the standard doesnt care.

    802.x is all about what happens on network links between devices - what a
    manufacturer chooses to do inside the box is private / implementation
    dependent.

    Now - on a cisco switch it any untagged frame is either thrown away or
    associated with a VLAN (the VLAN is configured against the port, or you
    inherit the default VLAN 1). Once "in" a VLAN it stays there through the
    box, and may actually get wrapped in a tag once it goes onto a link to the
    outside world.
    --
    Regards

    - replace xyz with ntl
     
    stephen, Apr 16, 2008
    #13
  14. Guest

    On 4ÔÂ16ÈÕ, ÏÂÎç1ʱ57·Ö, News Reader <> wrote:
    > wrote:
    > > On 4ÔÂ16ÈÕ, ÉÏÎç8ʱ05·Ö, News Reader <> wrote:
    > >> wrote:
    > >>> On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    > >>>> wrote:
    > >>>>> On 16 Apr, 05:31, wrote:
    > >>>>>> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    > >>>>>>> <> wrote in message
    > >>>>>>>news:...
    > >>>>>>>> A lot of people ask native vlan question.
    > >>>>>>>> I think using "vlan dot1q tag native" should eliminate this question.
    > >>>>>>>> at least for sw---sw connection. (all tagged just like isl)
    > >>>>>>>> I may not fully understand what's purpose why cisco make "native
    > >>>>>>>> vlan".
    > >>>>>>> cisco didnt invent this - it is part of 802.1Q.
    > >>>>>>>> Some article say because of backward compatible with 802.3.
    > >>>>>>> i suggest you try to find the standard and read around that,
    > >>>>>>> maybe start atwww.ieee.org
    > >>>>>>> AFAIR some of the standards docs are without charge for Ethernet.
    > >>>>>>>> Can anyone give an example?
    > >>>>>>> there are 2 Qs to think about.
    > >>>>>>> 1. set a port to be tagged
    > >>>>>>> - what do you do with a packet that arrives with no tag?
    > >>>>>>> the 2 common answers are to throw it away, or to put it into some sort of
    > >>>>>>> "default VLAN" - that is what untagged means for incoming packets.
    > >>>>>>> not putting a tag on outbound packets form that VLAN on that port allows 2
    > >>>>>>> way comms.
    > >>>>>>> this sounds silly - but it is what often needs to happen when you hook up an
    > >>>>>>> unconfigured device to set it up.
    > >>>>>>> 2. what happens when you want to split up 2 streams of packets on a port?
    > >>>>>>> sometimes you have a device that will add its own stream of packets to a set
    > >>>>>>> it gets from elsewhere
    > >>>>>>> - the classic case is an IP phone where there is a plug on the phone to
    > >>>>>>> connect a PC.
    > >>>>>>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    > >>>>>>> doesnt have the horsepower to wrap a tag around every packet.
    > >>>>>>> - but you want the phone traffic kept separate from PC (security, QoS and
    > >>>>>>> so on).
    > >>>>>>> So - pass the PC packet thru untagged, and tag the phone traffic.
    > >>>>>>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    > >>>>>>> phone traffic is tagged and goes into a different VLAN.
    > >>>>>>>> TIA,
    > >>>>>>>> st
    > >>>>>>> --
    > >>>>>>> Regards
    > >>>>>>> - replace xyz with ntl
    > >>>>>> Thanks,
    > >>>>>> For "Some article say because of backward compatible with 802.3"
    > >>>>>> they may think far end is Hub or switch/bridge which does not support
    > >>>>>> 802.3,
    > >>>>>> right?
    > >>>>>> One more question, when a access port receive a untag frame, does it
    > >>>>>> add
    > >>>>>> a 802.1q tag or some other tag to make sure it can go same vlan inside
    > >>>>>> of
    > >>>>>> this switch?-
    > >>>>> I have read something somewhere that stated that the Tags are
    > >>>>> stripped off when frames enter the switch however clearly equivalent
    > >>>>> information is carried 'with' the frame 'through' the switch.
    > >>>>> So as far as we the Users are concerned I think that
    > >>>>> you would have a good way of thinking about it if
    > >>>>> you assumed that such a tag was used.
    > >>>> When you configure a port-based VLAN on a switch, you are telling the
    > >>>> switch which ports are to be grouped into a common broadcast domain
    > >>>> (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    > >>>> it knows which ports it is permitted to forward too based on the
    > >>>> separation of broadcast domains (VLANs). Of course, if the switch has
    > >>>> learned the port that the destination host resides on, it will only
    > >>>> forward it out that port within the appropriate VLAN (assuming a unicast
    > >>>> packet). Broadcast packets may be flooded to all ports within a VLAN.
    > >>>> Best Regards,
    > >>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    > >>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    > >>> let me clear the second question up:
    > >>> when a access port receive a untag frame from a
    > >>> host, does it add a 802.1q tag or some other tag to make sure it can
    > >>> go same vlan inside of switch?
    > >> I would "assume" that an untagged frame (the norm) sent by a host, and
    > >> received on a switch port that is assigned a non-native VLAN ID, would
    > >> get tagged at the ingress port; would remain so on its journey through
    > >> the switch, and get stripped on the egress port if the port was
    > >> configured for "access mode".

    >
    > >> However, I would think that a programmer could (if desired) use some
    > >> other construct for segregating frames within the switch, and tag frames
    > >> as necessary as they egress onto a trunk port.

    >
    > >> I think your answer is likely implementation dependent, and up to the
    > >> whims of the programmer.

    >
    > >> Why get hung up on such an esoteric matter, when there are so many
    > >> practical issues to deal with?

    >
    > >> Best Regards,
    > >> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -

    >
    > >> - ÏÔʾÒýÓõÄÎÄ×Ö -

    >
    > > Thanks, To raise this question is that I try to have a good understand
    > > mechanism of switch. Still have some questions here:

    >
    > > 1. Based on what you explain it. For "a non-native VLAN ID" which you
    > > mentioned, this ID may be or may be not 802.1q tag, it depends on
    > > vender how to implement it. I think it is 802.1q tag,since port
    > > can also
    > > add 802.1p if it need it (3 bit for CoS). make sense? (maybe
    > > venders
    > > have diff. way to do it.)

    >
    > Although I offered an opinion, I don't really care what mechanism the
    > programmer uses to segregate VLAN traffic as it passes through the
    > switch, as long as separate broadcast domains are honored. I care about
    > implementing functionality.
    >
    >
    >
    > > 2. Let's go back practical issues, from a switch config point of view,
    > > the
    > > native vlan we have is because of trunk port. only trunk port can
    > > assign
    > > native Vlan. true? if other port is assign to as same as native
    > > Vlan ID,

    >
    > The "switchport access" command on our switches permit us to assign a
    > VLAN only, no reference to "native". The "switchport trunk" command
    > permits defining a VLAN as 802.1Q native.
    >
    > > then we say it is native vlan port. right? (assume all we talked
    > > here
    > > is access port)

    >
    > > 3. We know for a trunk (assume two switch connected)should assgin same
    > > native vlan ID on both side. otherwise some vlan can not talk for
    > > some

    >
    > The two switches should agree to tag or not to tag a given VLAN. There
    > is no requirement to use a native VLAN though. More on this below.
    >
    > > case or may have loop. The most of switch default native vlan is
    > > vlan 1.
    > > What is purpose to assgin it to other than vlan 1 when config trunk
    > > port?

    >
    > Personal preferences most likely.
    >
    >
    >
    > > 4. Some article also say one benifit of native vlan is if this trunk
    > > failed, the
    > > native vlan (untagged message) can still work. What is trunk
    > > failed
    > > definition over here? What falure cause tagged frame cannot go
    > > through
    > > only untagged frame can.

    >
    > Perhaps, if you used a native VLAN as an administrative VLAN (device
    > administration), it might give you some immunity from some configuration
    > errors, but I'm not aware of any such failure mode.
    >
    >
    >
    > > 5. Is it valid that a switch trunk port to connect to a host NIC?
    > > (assume NIC
    > > is not 802.1q aware) if it is ok, it means that that server can
    > > only
    > > send/receive native vlan frame (untagged). right? what is purpose?
    > > it is just because of backward compatible?

    >
    > If a server/host NIC was NOT 802.1Q aware you wouldn't connect it to a
    > trunk port on the switch, you'd connect it to an access port.
    >
    >
    >
    > > 6. I remember (intel and broadcom) support 802.1q aware sever NIC.
    > > For somecase, say a small company that no need hosts talk bewteen
    > > vlans, only allow all vlans hosts talk to a server. then we can
    > > config a
    > > trunk port on switch and connect to that server. We dont need any
    > > routing protocol. Is that right? anyone use this way? (i know it

    >
    > If a server NIC was 802.1Q aware, you could connect it to a trunk port
    > on the switch, enabling hosts from different VLANs to access the server.
    > Without a routing function, hosts in different VLANs would be isolated
    > from each other.
    >
    > > has diff
    > > solution such as Pvlan)

    >
    > > TIA,
    > > st

    >
    > There is generally no need to use a native VLAN on a trunk. In fact it
    > is preferable from a security standpoint that you not use native VLANs
    > due to VLAN Hopping exploitation. We assign a specific VLAN (not VLAN1)
    > as the native, and then refrain from assigning any ports to the VLAN.
    > The trunk is then configured to permit specific VLANs only (excluding
    > the native, and excluding VLAN1). All traffic on our trunks are non-native..
    >
    > We assign all unused (shutdown) ports to a specific VLAN (again, not
    > VLAN1). The default VLAN1 is not used at all.
    >
    > Best Regards,
    > News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >
    > - ÏÔʾÒýÓõÄÎÄ×Ö -


    Very good feedback!
    How about management vlan?
    So you use Vlan1 for managment only or use others?
     
    , Apr 16, 2008
    #14
  15. News Reader Guest

    wrote:
    > On 4ÔÂ16ÈÕ, ÏÂÎç1ʱ57·Ö, News Reader <> wrote:
    >> wrote:
    >>> On 4ÔÂ16ÈÕ, ÉÏÎç8ʱ05·Ö, News Reader <> wrote:
    >>>> wrote:
    >>>>> On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    >>>>>> wrote:
    >>>>>>> On 16 Apr, 05:31, wrote:
    >>>>>>>> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    >>>>>>>>> <> wrote in message
    >>>>>>>>> news:...
    >>>>>>>>>> A lot of people ask native vlan question.
    >>>>>>>>>> I think using "vlan dot1q tag native" should eliminate this question.
    >>>>>>>>>> at least for sw---sw connection. (all tagged just like isl)
    >>>>>>>>>> I may not fully understand what's purpose why cisco make "native
    >>>>>>>>>> vlan".
    >>>>>>>>> cisco didnt invent this - it is part of 802.1Q.
    >>>>>>>>>> Some article say because of backward compatible with 802.3.
    >>>>>>>>> i suggest you try to find the standard and read around that,
    >>>>>>>>> maybe start atwww.ieee.org
    >>>>>>>>> AFAIR some of the standards docs are without charge for Ethernet.
    >>>>>>>>>> Can anyone give an example?
    >>>>>>>>> there are 2 Qs to think about.
    >>>>>>>>> 1. set a port to be tagged
    >>>>>>>>> - what do you do with a packet that arrives with no tag?
    >>>>>>>>> the 2 common answers are to throw it away, or to put it into some sort of
    >>>>>>>>> "default VLAN" - that is what untagged means for incoming packets.
    >>>>>>>>> not putting a tag on outbound packets form that VLAN on that port allows 2
    >>>>>>>>> way comms.
    >>>>>>>>> this sounds silly - but it is what often needs to happen when you hook up an
    >>>>>>>>> unconfigured device to set it up.
    >>>>>>>>> 2. what happens when you want to split up 2 streams of packets on a port?
    >>>>>>>>> sometimes you have a device that will add its own stream of packets to a set
    >>>>>>>>> it gets from elsewhere
    >>>>>>>>> - the classic case is an IP phone where there is a plug on the phone to
    >>>>>>>>> connect a PC.
    >>>>>>>>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    >>>>>>>>> doesnt have the horsepower to wrap a tag around every packet.
    >>>>>>>>> - but you want the phone traffic kept separate from PC (security, QoS and
    >>>>>>>>> so on).
    >>>>>>>>> So - pass the PC packet thru untagged, and tag the phone traffic.
    >>>>>>>>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    >>>>>>>>> phone traffic is tagged and goes into a different VLAN.
    >>>>>>>>>> TIA,
    >>>>>>>>>> st
    >>>>>>>>> --
    >>>>>>>>> Regards
    >>>>>>>>> - replace xyz with ntl
    >>>>>>>> Thanks,
    >>>>>>>> For "Some article say because of backward compatible with 802.3"
    >>>>>>>> they may think far end is Hub or switch/bridge which does not support
    >>>>>>>> 802.3,
    >>>>>>>> right?
    >>>>>>>> One more question, when a access port receive a untag frame, does it
    >>>>>>>> add
    >>>>>>>> a 802.1q tag or some other tag to make sure it can go same vlan inside
    >>>>>>>> of
    >>>>>>>> this switch?-
    >>>>>>> I have read something somewhere that stated that the Tags are
    >>>>>>> stripped off when frames enter the switch however clearly equivalent
    >>>>>>> information is carried 'with' the frame 'through' the switch.
    >>>>>>> So as far as we the Users are concerned I think that
    >>>>>>> you would have a good way of thinking about it if
    >>>>>>> you assumed that such a tag was used.
    >>>>>> When you configure a port-based VLAN on a switch, you are telling the
    >>>>>> switch which ports are to be grouped into a common broadcast domain
    >>>>>> (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    >>>>>> it knows which ports it is permitted to forward too based on the
    >>>>>> separation of broadcast domains (VLANs). Of course, if the switch has
    >>>>>> learned the port that the destination host resides on, it will only
    >>>>>> forward it out that port within the appropriate VLAN (assuming a unicast
    >>>>>> packet). Broadcast packets may be flooded to all ports within a VLAN.
    >>>>>> Best Regards,
    >>>>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>>>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    >>>>> let me clear the second question up:
    >>>>> when a access port receive a untag frame from a
    >>>>> host, does it add a 802.1q tag or some other tag to make sure it can
    >>>>> go same vlan inside of switch?
    >>>> I would "assume" that an untagged frame (the norm) sent by a host, and
    >>>> received on a switch port that is assigned a non-native VLAN ID, would
    >>>> get tagged at the ingress port; would remain so on its journey through
    >>>> the switch, and get stripped on the egress port if the port was
    >>>> configured for "access mode".
    >>>> However, I would think that a programmer could (if desired) use some
    >>>> other construct for segregating frames within the switch, and tag frames
    >>>> as necessary as they egress onto a trunk port.
    >>>> I think your answer is likely implementation dependent, and up to the
    >>>> whims of the programmer.
    >>>> Why get hung up on such an esoteric matter, when there are so many
    >>>> practical issues to deal with?
    >>>> Best Regards,
    >>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    >>> Thanks, To raise this question is that I try to have a good understand
    >>> mechanism of switch. Still have some questions here:
    >>> 1. Based on what you explain it. For "a non-native VLAN ID" which you
    >>> mentioned, this ID may be or may be not 802.1q tag, it depends on
    >>> vender how to implement it. I think it is 802.1q tag,since port
    >>> can also
    >>> add 802.1p if it need it (3 bit for CoS). make sense? (maybe
    >>> venders
    >>> have diff. way to do it.)

    >> Although I offered an opinion, I don't really care what mechanism the
    >> programmer uses to segregate VLAN traffic as it passes through the
    >> switch, as long as separate broadcast domains are honored. I care about
    >> implementing functionality.
    >>
    >>
    >>
    >>> 2. Let's go back practical issues, from a switch config point of view,
    >>> the
    >>> native vlan we have is because of trunk port. only trunk port can
    >>> assign
    >>> native Vlan. true? if other port is assign to as same as native
    >>> Vlan ID,

    >> The "switchport access" command on our switches permit us to assign a
    >> VLAN only, no reference to "native". The "switchport trunk" command
    >> permits defining a VLAN as 802.1Q native.
    >>
    >>> then we say it is native vlan port. right? (assume all we talked
    >>> here
    >>> is access port)
    >>> 3. We know for a trunk (assume two switch connected)should assgin same
    >>> native vlan ID on both side. otherwise some vlan can not talk for
    >>> some

    >> The two switches should agree to tag or not to tag a given VLAN. There
    >> is no requirement to use a native VLAN though. More on this below.
    >>
    >>> case or may have loop. The most of switch default native vlan is
    >>> vlan 1.
    >>> What is purpose to assgin it to other than vlan 1 when config trunk
    >>> port?

    >> Personal preferences most likely.
    >>
    >>
    >>
    >>> 4. Some article also say one benifit of native vlan is if this trunk
    >>> failed, the
    >>> native vlan (untagged message) can still work. What is trunk
    >>> failed
    >>> definition over here? What falure cause tagged frame cannot go
    >>> through
    >>> only untagged frame can.

    >> Perhaps, if you used a native VLAN as an administrative VLAN (device
    >> administration), it might give you some immunity from some configuration
    >> errors, but I'm not aware of any such failure mode.
    >>
    >>
    >>
    >>> 5. Is it valid that a switch trunk port to connect to a host NIC?
    >>> (assume NIC
    >>> is not 802.1q aware) if it is ok, it means that that server can
    >>> only
    >>> send/receive native vlan frame (untagged). right? what is purpose?
    >>> it is just because of backward compatible?

    >> If a server/host NIC was NOT 802.1Q aware you wouldn't connect it to a
    >> trunk port on the switch, you'd connect it to an access port.
    >>
    >>
    >>
    >>> 6. I remember (intel and broadcom) support 802.1q aware sever NIC.
    >>> For somecase, say a small company that no need hosts talk bewteen
    >>> vlans, only allow all vlans hosts talk to a server. then we can
    >>> config a
    >>> trunk port on switch and connect to that server. We dont need any
    >>> routing protocol. Is that right? anyone use this way? (i know it

    >> If a server NIC was 802.1Q aware, you could connect it to a trunk port
    >> on the switch, enabling hosts from different VLANs to access the server.
    >> Without a routing function, hosts in different VLANs would be isolated
    >> from each other.
    >>
    >>> has diff
    >>> solution such as Pvlan)
    >>> TIA,
    >>> st

    >> There is generally no need to use a native VLAN on a trunk. In fact it
    >> is preferable from a security standpoint that you not use native VLANs
    >> due to VLAN Hopping exploitation. We assign a specific VLAN (not VLAN1)
    >> as the native, and then refrain from assigning any ports to the VLAN.
    >> The trunk is then configured to permit specific VLANs only (excluding
    >> the native, and excluding VLAN1). All traffic on our trunks are non-native.
    >>
    >> We assign all unused (shutdown) ports to a specific VLAN (again, not
    >> VLAN1). The default VLAN1 is not used at all.
    >>
    >> Best Regards,
    >> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>
    >> - ÏÔʾÒýÓõÄÎÄ×Ö -

    >
    > Very good feedback!
    > How about management vlan?
    > So you use Vlan1 for managment only or use others?


    The last sentence of my post - "The default VLAN1 is not used at all."
    ;>)

    We use a specific VLAN for management purposes. No user traffic is
    permitted into the administrative VLAN.

    One issue with VLAN1 is inheritance (for lack of a better word). If you
    were to delete a VLAN (intentionally, or otherwise) that had ports
    assigned to it, where would they go? They would end up in the default
    VLAN; VLAN1. If you were using VLANs to enforce security policy, would
    you want ports that were supposed to be isolated, to be grouped into a
    common VLAN, even for a short period of time, until you remedied the
    situation? No.

    Best Regards,
    News Reader
     
    News Reader, Apr 16, 2008
    #15
  16. Guest

    On 4ÔÂ16ÈÕ, ÏÂÎç3ʱ07·Ö, News Reader <> wrote:
    > wrote:
    > > On 4ÔÂ16ÈÕ, ÏÂÎç1ʱ57·Ö, News Reader <> wrote:
    > >> wrote:
    > >>> On 4ÔÂ16ÈÕ, ÉÏÎç8ʱ05·Ö, News Reader <> wrote:
    > >>>> wrote:
    > >>>>> On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    > >>>>>> wrote:
    > >>>>>>> On 16 Apr, 05:31, wrote:
    > >>>>>>>> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    > >>>>>>>>> <> wrote in message
    > >>>>>>>>>news:...
    > >>>>>>>>>> A lot of people ask native vlan question.
    > >>>>>>>>>> I think using "vlan dot1q tag native" should eliminate this question.
    > >>>>>>>>>> at least for sw---sw connection. (all tagged just like isl)
    > >>>>>>>>>> I may not fully understand what's purpose why cisco make "native
    > >>>>>>>>>> vlan".
    > >>>>>>>>> cisco didnt invent this - it is part of 802.1Q.
    > >>>>>>>>>> Some article say because of backward compatible with 802.3.
    > >>>>>>>>> i suggest you try to find the standard and read around that,
    > >>>>>>>>> maybe start atwww.ieee.org
    > >>>>>>>>> AFAIR some of the standards docs are without charge for Ethernet..
    > >>>>>>>>>> Can anyone give an example?
    > >>>>>>>>> there are 2 Qs to think about.
    > >>>>>>>>> 1. set a port to be tagged
    > >>>>>>>>> - what do you do with a packet that arrives with no tag?
    > >>>>>>>>> the 2 common answers are to throw it away, or to put it into some sort of
    > >>>>>>>>> "default VLAN" - that is what untagged means for incoming packets.
    > >>>>>>>>> not putting a tag on outbound packets form that VLAN on that port allows 2
    > >>>>>>>>> way comms.
    > >>>>>>>>> this sounds silly - but it is what often needs to happen when you hook up an
    > >>>>>>>>> unconfigured device to set it up.
    > >>>>>>>>> 2. what happens when you want to split up 2 streams of packets on a port?
    > >>>>>>>>> sometimes you have a device that will add its own stream of packets to a set
    > >>>>>>>>> it gets from elsewhere
    > >>>>>>>>> - the classic case is an IP phone where there is a plug on the phone to
    > >>>>>>>>> connect a PC.
    > >>>>>>>>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    > >>>>>>>>> doesnt have the horsepower to wrap a tag around every packet.
    > >>>>>>>>> - but you want the phone traffic kept separate from PC (security, QoS and
    > >>>>>>>>> so on).
    > >>>>>>>>> So - pass the PC packet thru untagged, and tag the phone traffic..
    > >>>>>>>>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    > >>>>>>>>> phone traffic is tagged and goes into a different VLAN.
    > >>>>>>>>>> TIA,
    > >>>>>>>>>> st
    > >>>>>>>>> --
    > >>>>>>>>> Regards
    > >>>>>>>>> - replace xyz with ntl
    > >>>>>>>> Thanks,
    > >>>>>>>> For "Some article say because of backward compatible with 802.3"
    > >>>>>>>> they may think far end is Hub or switch/bridge which does not support
    > >>>>>>>> 802.3,
    > >>>>>>>> right?
    > >>>>>>>> One more question, when a access port receive a untag frame, does it
    > >>>>>>>> add
    > >>>>>>>> a 802.1q tag or some other tag to make sure it can go same vlan inside
    > >>>>>>>> of
    > >>>>>>>> this switch?-
    > >>>>>>> I have read something somewhere that stated that the Tags are
    > >>>>>>> stripped off when frames enter the switch however clearly equivalent
    > >>>>>>> information is carried 'with' the frame 'through' the switch.
    > >>>>>>> So as far as we the Users are concerned I think that
    > >>>>>>> you would have a good way of thinking about it if
    > >>>>>>> you assumed that such a tag was used.
    > >>>>>> When you configure a port-based VLAN on a switch, you are telling the
    > >>>>>> switch which ports are to be grouped into a common broadcast domain
    > >>>>>> (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    > >>>>>> it knows which ports it is permitted to forward too based on the
    > >>>>>> separation of broadcast domains (VLANs). Of course, if the switch has
    > >>>>>> learned the port that the destination host resides on, it will only
    > >>>>>> forward it out that port within the appropriate VLAN (assuming a unicast
    > >>>>>> packet). Broadcast packets may be flooded to all ports within a VLAN.
    > >>>>>> Best Regards,
    > >>>>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    > >>>>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    > >>>>> let me clear the second question up:
    > >>>>> when a access port receive a untag frame from a
    > >>>>> host, does it add a 802.1q tag or some other tag to make sure it can
    > >>>>> go same vlan inside of switch?
    > >>>> I would "assume" that an untagged frame (the norm) sent by a host, and
    > >>>> received on a switch port that is assigned a non-native VLAN ID, would
    > >>>> get tagged at the ingress port; would remain so on its journey through
    > >>>> the switch, and get stripped on the egress port if the port was
    > >>>> configured for "access mode".
    > >>>> However, I would think that a programmer could (if desired) use some
    > >>>> other construct for segregating frames within the switch, and tag frames
    > >>>> as necessary as they egress onto a trunk port.
    > >>>> I think your answer is likely implementation dependent, and up to the
    > >>>> whims of the programmer.
    > >>>> Why get hung up on such an esoteric matter, when there are so many
    > >>>> practical issues to deal with?
    > >>>> Best Regards,
    > >>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    > >>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    > >>> Thanks, To raise this question is that I try to have a good understand
    > >>> mechanism of switch. Still have some questions here:
    > >>> 1. Based on what you explain it. For "a non-native VLAN ID" which you
    > >>> mentioned, this ID may be or may be not 802.1q tag, it depends on
    > >>> vender how to implement it. I think it is 802.1q tag,since port
    > >>> can also
    > >>> add 802.1p if it need it (3 bit for CoS). make sense? (maybe
    > >>> venders
    > >>> have diff. way to do it.)
    > >> Although I offered an opinion, I don't really care what mechanism the
    > >> programmer uses to segregate VLAN traffic as it passes through the
    > >> switch, as long as separate broadcast domains are honored. I care about
    > >> implementing functionality.

    >
    > >>> 2. Let's go back practical issues, from a switch config point of view,
    > >>> the
    > >>> native vlan we have is because of trunk port. only trunk port can
    > >>> assign
    > >>> native Vlan. true? if other port is assign to as same as native
    > >>> Vlan ID,
    > >> The "switchport access" command on our switches permit us to assign a
    > >> VLAN only, no reference to "native". The "switchport trunk" command
    > >> permits defining a VLAN as 802.1Q native.

    >
    > >>> then we say it is native vlan port. right? (assume all we talked
    > >>> here
    > >>> is access port)
    > >>> 3. We know for a trunk (assume two switch connected)should assgin same
    > >>> native vlan ID on both side. otherwise some vlan can not talk for
    > >>> some
    > >> The two switches should agree to tag or not to tag a given VLAN. There
    > >> is no requirement to use a native VLAN though. More on this below.

    >
    > >>> case or may have loop. The most of switch default native vlan is
    > >>> vlan 1.
    > >>> What is purpose to assgin it to other than vlan 1 when config trunk
    > >>> port?
    > >> Personal preferences most likely.

    >
    > >>> 4. Some article also say one benifit of native vlan is if this trunk
    > >>> failed, the
    > >>> native vlan (untagged message) can still work. What is trunk
    > >>> failed
    > >>> definition over here? What falure cause tagged frame cannot go
    > >>> through
    > >>> only untagged frame can.
    > >> Perhaps, if you used a native VLAN as an administrative VLAN (device
    > >> administration), it might give you some immunity from some configuration
    > >> errors, but I'm not aware of any such failure mode.

    >
    > >>> 5. Is it valid that a switch trunk port to connect to a host NIC?
    > >>> (assume NIC
    > >>> is not 802.1q aware) if it is ok, it means that that server can
    > >>> only
    > >>> send/receive native vlan frame (untagged). right? what is purpose?
    > >>> it is just because of backward compatible?
    > >> If a server/host NIC was NOT 802.1Q aware you wouldn't connect it to a
    > >> trunk port on the switch, you'd connect it to an access port.

    >
    > >>> 6. I remember (intel and broadcom) support 802.1q aware sever NIC.
    > >>> For somecase, say a small company that no need hosts talk bewteen
    > >>> vlans, only allow all vlans hosts talk to a server. then we can
    > >>> config a
    > >>> trunk port on switch and connect to that server. We dont need any
    > >>> routing protocol. Is that right? anyone use this way? (i know it
    > >> If a server NIC was 802.1Q aware, you could connect it to a trunk port
    > >> on the switch, enabling hosts from different VLANs to access the server..
    > >> Without a routing function, hosts in different VLANs would be isolated
    > >> from each other.

    >
    > >>> has diff
    > >>> solution such as Pvlan)
    > >>> TIA,
    > >>> st
    > >> There is generally no need to use a native VLAN on a trunk. In fact it
    > >> is preferable from a security standpoint that you not use native VLANs
    > >> due to VLAN Hopping exploitation. We assign a specific VLAN (not VLAN1)
    > >> as the native, and then refrain from assigning any ports to the VLAN.
    > >> The trunk is then configured to permit specific VLANs only (excluding
    > >> the native, and excluding VLAN1). All traffic on our trunks are non-native.

    >
    > >> We assign all unused (shutdown) ports to a specific VLAN (again, not
    > >> VLAN1). The default VLAN1 is not used at all.

    >
    > >> Best Regards,
    > >> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -

    >
    > >> - ÏÔʾÒýÓõÄÎÄ×Ö -

    >
    > > Very good feedback!
    > > How about management vlan?
    > > So you use Vlan1 for managment only or use others?

    >
    > The last sentence of my post - "The default VLAN1 is not used at all."
    > ;>)
    >
    > We use a specific VLAN for management purposes. No user traffic is
    > permitted into the administrative VLAN.
    >
    > One issue with VLAN1 is inheritance (for lack of a better word). If you
    > were to delete a VLAN (intentionally, or otherwise) that had ports
    > assigned to it, where would they go? They would end up in the default
    > VLAN; VLAN1. If you were using VLANs to enforce security policy, would
    > you want ports that were supposed to be ...
    >
    > ÔĶÁ¸ü¶à >>- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >
    > - ÏÔʾÒýÓõÄÎÄ×Ö -


    Still have a couple of things not sure,
    1. if no vlan1 go through trunk port,
    how about some L2 protocol such as VTP,CDP,PAgP etc.
    cisco say those protocols must be run vlan1 only.

    2. Also no vlan1 go to trunk, does it impect spanning tree protocol.
    or you don't care them. (maybe stp is okay, use rstp or mstp
    I am not sure about it)

    3. Any special config to enable a management vlan which can do
    snmp and telnet to switch to do configuration on cisco
    switch?.
    What i know some vender assign one or two dedicate port
    for this purpose.

    TIA,
    st
     
    , Apr 17, 2008
    #16
  17. Guest

    On 4ÔÂ16ÈÕ, ÏÂÎç4ʱ03·Ö, wrote:
    > On 4ÔÂ16ÈÕ, ÏÂÎç3ʱ07·Ö, News Reader <> wrote:
    >
    >
    >
    > > wrote:
    > > > On 4ÔÂ16ÈÕ, ÏÂÎç1ʱ57·Ö, News Reader <> wrote:
    > > >> wrote:
    > > >>> On 4ÔÂ16ÈÕ, ÉÏÎç8ʱ05·Ö, News Reader <> wrote:
    > > >>>> wrote:
    > > >>>>> On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    > > >>>>>> wrote:
    > > >>>>>>> On 16 Apr, 05:31, wrote:
    > > >>>>>>>> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    > > >>>>>>>>> <> wrote in message
    > > >>>>>>>>>news:...
    > > >>>>>>>>>> A lot of people ask native vlan question.
    > > >>>>>>>>>> I think using "vlan dot1q tag native" should eliminate this question.
    > > >>>>>>>>>> at least for sw---sw connection. (all tagged just like isl)
    > > >>>>>>>>>> I may not fully understand what's purpose why cisco make "native
    > > >>>>>>>>>> vlan".
    > > >>>>>>>>> cisco didnt invent this - it is part of 802.1Q.
    > > >>>>>>>>>> Some article say because of backward compatible with 802.3.
    > > >>>>>>>>> i suggest you try to find the standard and read around that,
    > > >>>>>>>>> maybe start atwww.ieee.org
    > > >>>>>>>>> AFAIR some of the standards docs are without charge for Ethernet.
    > > >>>>>>>>>> Can anyone give an example?
    > > >>>>>>>>> there are 2 Qs to think about.
    > > >>>>>>>>> 1. set a port to be tagged
    > > >>>>>>>>> - what do you do with a packet that arrives with no tag?
    > > >>>>>>>>> the 2 common answers are to throw it away, or to put it into some sort of
    > > >>>>>>>>> "default VLAN" - that is what untagged means for incoming packets.
    > > >>>>>>>>> not putting a tag on outbound packets form that VLAN on that port allows 2
    > > >>>>>>>>> way comms.
    > > >>>>>>>>> this sounds silly - but it is what often needs to happen when you hook up an
    > > >>>>>>>>> unconfigured device to set it up.
    > > >>>>>>>>> 2. what happens when you want to split up 2 streams of packets on a port?
    > > >>>>>>>>> sometimes you have a device that will add its own stream of packets to a set
    > > >>>>>>>>> it gets from elsewhere
    > > >>>>>>>>> - the classic case is an IP phone where there is a plug on the phone to
    > > >>>>>>>>> connect a PC.
    > > >>>>>>>>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    > > >>>>>>>>> doesnt have the horsepower to wrap a tag around every packet.
    > > >>>>>>>>> - but you want the phone traffic kept separate from PC (security, QoS and
    > > >>>>>>>>> so on).
    > > >>>>>>>>> So - pass the PC packet thru untagged, and tag the phone traffic.
    > > >>>>>>>>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    > > >>>>>>>>> phone traffic is tagged and goes into a different VLAN.
    > > >>>>>>>>>> TIA,
    > > >>>>>>>>>> st
    > > >>>>>>>>> --
    > > >>>>>>>>> Regards
    > > >>>>>>>>> - replace xyz with ntl
    > > >>>>>>>> Thanks,
    > > >>>>>>>> For "Some article say because of backward compatible with 802.3"
    > > >>>>>>>> they may think far end is Hub or switch/bridge which does not support
    > > >>>>>>>> 802.3,
    > > >>>>>>>> right?
    > > >>>>>>>> One more question, when a access port receive a untag frame, does it
    > > >>>>>>>> add
    > > >>>>>>>> a 802.1q tag or some other tag to make sure it can go same vlan inside
    > > >>>>>>>> of
    > > >>>>>>>> this switch?-
    > > >>>>>>> I have read something somewhere that stated that the Tags are
    > > >>>>>>> stripped off when frames enter the switch however clearly equivalent
    > > >>>>>>> information is carried 'with' the frame 'through' the switch.
    > > >>>>>>> So as far as we the Users are concerned I think that
    > > >>>>>>> you would have a good way of thinking about it if
    > > >>>>>>> you assumed that such a tag was used.
    > > >>>>>> When you configure a port-based VLAN on a switch, you are telling the
    > > >>>>>> switch which ports are to be grouped into a common broadcast domain
    > > >>>>>> (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    > > >>>>>> it knows which ports it is permitted to forward too based on the
    > > >>>>>> separation of broadcast domains (VLANs). Of course, if the switch has
    > > >>>>>> learned the port that the destination host resides on, it will only
    > > >>>>>> forward it out that port within the appropriate VLAN (assuming a unicast
    > > >>>>>> packet). Broadcast packets may be flooded to all ports within a VLAN.
    > > >>>>>> Best Regards,
    > > >>>>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    > > >>>>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    > > >>>>> let me clear the second question up:
    > > >>>>> when a access port receive a untag frame from a
    > > >>>>> host, does it add a 802.1q tag or some other tag to make sure it can
    > > >>>>> go same vlan inside of switch?
    > > >>>> I would "assume" that an untagged frame (the norm) sent by a host, and
    > > >>>> received on a switch port that is assigned a non-native VLAN ID, would
    > > >>>> get tagged at the ingress port; would remain so on its journey through
    > > >>>> the switch, and get stripped on the egress port if the port was
    > > >>>> configured for "access mode".
    > > >>>> However, I would think that a programmer could (if desired) use some
    > > >>>> other construct for segregating frames within the switch, and tag frames
    > > >>>> as necessary as they egress onto a trunk port.
    > > >>>> I think your answer is likely implementation dependent, and up to the
    > > >>>> whims of the programmer.
    > > >>>> Why get hung up on such an esoteric matter, when there are so many
    > > >>>> practical issues to deal with?
    > > >>>> Best Regards,
    > > >>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    > > >>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    > > >>> Thanks, To raise this question is that I try to have a good understand
    > > >>> mechanism of switch. Still have some questions here:
    > > >>> 1. Based on what you explain it. For "a non-native VLAN ID" which you
    > > >>> mentioned, this ID may be or may be not 802.1q tag, it depends on
    > > >>> vender how to implement it. I think it is 802.1q tag,since port
    > > >>> can also
    > > >>> add 802.1p if it need it (3 bit for CoS). make sense? (maybe
    > > >>> venders
    > > >>> have diff. way to do it.)
    > > >> Although I offered an opinion, I don't really care what mechanism the
    > > >> programmer uses to segregate VLAN traffic as it passes through the
    > > >> switch, as long as separate broadcast domains are honored. I care about
    > > >> implementing functionality.

    >
    > > >>> 2. Let's go back practical issues, from a switch config point of view,
    > > >>> the
    > > >>> native vlan we have is because of trunk port. only trunk port can
    > > >>> assign
    > > >>> native Vlan. true? if other port is assign to as same as native
    > > >>> Vlan ID,
    > > >> The "switchport access" command on our switches permit us to assign a
    > > >> VLAN only, no reference to "native". The "switchport trunk" command
    > > >> permits defining a VLAN as 802.1Q native.

    >
    > > >>> then we say it is native vlan port. right? (assume all we talked
    > > >>> here
    > > >>> is access port)
    > > >>> 3. We know for a trunk (assume two switch connected)should assgin same
    > > >>> native vlan ID on both side. otherwise some vlan can not talk for
    > > >>> some
    > > >> The two switches should agree to tag or not to tag a given VLAN. There
    > > >> is no requirement to use a native VLAN though. More on this below.

    >
    > > >>> case or may have loop. The most of switch default native vlan is
    > > >>> vlan 1.
    > > >>> What is purpose to assgin it to other than vlan 1 when config trunk
    > > >>> port?
    > > >> Personal preferences most likely.

    >
    > > >>> 4. Some article also say one benifit of native vlan is if this trunk
    > > >>> failed, the
    > > >>> native vlan (untagged message) can still work. What is trunk
    > > >>> failed
    > > >>> definition over here? What falure cause tagged frame cannot go
    > > >>> through
    > > >>> only untagged frame can.
    > > >> Perhaps, if you used a native VLAN as an administrative VLAN (device
    > > >> administration), it might give you some immunity from some configuration
    > > >> errors, but I'm not aware of any such failure mode.

    >
    > > >>> 5. Is it valid that a switch trunk port to connect to a host NIC?
    > > >>> (assume NIC
    > > >>> is not 802.1q aware) if it is ok, it means that that server can
    > > >>> only
    > > >>> send/receive native vlan frame (untagged). right? what is purpose?
    > > >>> it is just because of backward compatible?
    > > >> If a server/host NIC was NOT 802.1Q aware you wouldn't connect it to a
    > > >> trunk port on the switch, you'd connect it to an access port.

    >
    > > >>> 6. I remember (intel and broadcom) support 802.1q aware sever NIC.
    > > >>> For somecase, say a small company that no need hosts talk bewteen
    > > >>> vlans, only allow all vlans hosts talk to a server. then we can
    > > >>> config a
    > > >>> trunk port on switch and connect to that server. We dont need any
    > > >>> routing protocol. Is that right? anyone use this way? (i know it
    > > >> If a server NIC was 802.1Q aware, you could connect it to a trunk port
    > > >> on the switch, enabling hosts from different VLANs to access the server.
    > > >> Without a routing function, hosts in different VLANs would be isolated
    > > >> from each other.

    >
    > > >>> has diff
    > > >>> solution such as Pvlan)
    > > >>> TIA,
    > > >>> st
    > > >> There is generally no need to use a native VLAN on a trunk. In fact it
    > > >> is preferable from a security standpoint that you not use native VLANs
    > > >> due to VLAN Hopping exploitation. We assign a specific VLAN (not VLAN1)
    > > >> as the native, and then refrain from assigning any ports to the VLAN.
    > > >> The trunk is then configured to permit specific VLANs only (excluding
    > > >> the native, and excluding VLAN1). All traffic on our trunks are non-native.

    >
    > > >> We assign all unused (shutdown) ports to a specific VLAN (again, not
    > > >> VLAN1). The default VLAN1 is not used at all.

    >
    > > >> Best Regards,
    > > >> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -

    >
    > > >> - ÏÔʾÒýÓõÄÎÄ×Ö -

    >
    > > > Very good feedback!
    > > > How about management vlan?
    > > > So you use Vlan1 for managment only or use others?

    >
    > > The last sentence of my post - "The default VLAN1 is not used at all."
    > > ;>)

    >
    > > We use a specific VLAN for management

    >
    > ...
    >
    > ÔĶÁ¸ü¶à >>- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >
    > - ÏÔʾÒýÓõÄÎÄ×Ö -


    Still have a couple of questions to discuss with you.

    1.Does it need any special config to make a management vlan
    on cisco switch? or any vlan can do? I know some vender assign
    one or two dedicate physical port to do it.

    2. If no vlan1 go through trunk prot, how about some L2 protocol
    such as VTP,CDP and PAgP etc., how do they work between
    switches if they need it?

    3. If no vlan1 go through trunk port, how spanning tree protocl?
    any impact?
    all above assume switch to switch trunk connection (use 802.1q.)

    TIA,
    st
     
    , Apr 17, 2008
    #17
  18. wrote:

    >
    >Still have a couple of things not sure,
    >1. if no vlan1 go through trunk port,
    > how about some L2 protocol such as VTP,CDP,PAgP etc.
    > cisco say those protocols must be run vlan1 only.
    >
    >2. Also no vlan1 go to trunk, does it impect spanning tree protocol.
    > or you don't care them. (maybe stp is okay, use rstp or mstp
    > I am not sure about it)
    >
    >3. Any special config to enable a management vlan which can do
    > snmp and telnet to switch to do configuration on cisco
    > switch?.
    > What i know some vender assign one or two dedicate port
    > for this purpose.
    >
    >TIA,


    When answering or replying to a post WHY don't up cut down the size
    (number of lines) in the message. It makes reading and replying a lot
    easer...
     
    gene martinez, Apr 17, 2008
    #18
  19. News Reader Guest

    wrote:
    > On 4ÔÂ16ÈÕ, ÏÂÎç4ʱ03·Ö, wrote:
    >> On 4ÔÂ16ÈÕ, ÏÂÎç3ʱ07·Ö, News Reader <> wrote:
    >>
    >>
    >>
    >>> wrote:
    >>>> On 4ÔÂ16ÈÕ, ÏÂÎç1ʱ57·Ö, News Reader <> wrote:
    >>>>> wrote:
    >>>>>> On 4ÔÂ16ÈÕ, ÉÏÎç8ʱ05·Ö, News Reader <> wrote:
    >>>>>>> wrote:
    >>>>>>>> On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    >>>>>>>>> wrote:
    >>>>>>>>>> On 16 Apr, 05:31, wrote:
    >>>>>>>>>>> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    >>>>>>>>>>>> <> wrote in message
    >>>>>>>>>>>> news:...
    >>>>>>>>>>>>> A lot of people ask native vlan question.
    >>>>>>>>>>>>> I think using "vlan dot1q tag native" should eliminate this question.
    >>>>>>>>>>>>> at least for sw---sw connection. (all tagged just like isl)
    >>>>>>>>>>>>> I may not fully understand what's purpose why cisco make "native
    >>>>>>>>>>>>> vlan".
    >>>>>>>>>>>> cisco didnt invent this - it is part of 802.1Q.
    >>>>>>>>>>>>> Some article say because of backward compatible with 802.3.
    >>>>>>>>>>>> i suggest you try to find the standard and read around that,
    >>>>>>>>>>>> maybe start atwww.ieee.org
    >>>>>>>>>>>> AFAIR some of the standards docs are without charge for Ethernet.
    >>>>>>>>>>>>> Can anyone give an example?
    >>>>>>>>>>>> there are 2 Qs to think about.
    >>>>>>>>>>>> 1. set a port to be tagged
    >>>>>>>>>>>> - what do you do with a packet that arrives with no tag?
    >>>>>>>>>>>> the 2 common answers are to throw it away, or to put it into some sort of
    >>>>>>>>>>>> "default VLAN" - that is what untagged means for incoming packets.
    >>>>>>>>>>>> not putting a tag on outbound packets form that VLAN on that port allows 2
    >>>>>>>>>>>> way comms.
    >>>>>>>>>>>> this sounds silly - but it is what often needs to happen when you hook up an
    >>>>>>>>>>>> unconfigured device to set it up.
    >>>>>>>>>>>> 2. what happens when you want to split up 2 streams of packets on a port?
    >>>>>>>>>>>> sometimes you have a device that will add its own stream of packets to a set
    >>>>>>>>>>>> it gets from elsewhere
    >>>>>>>>>>>> - the classic case is an IP phone where there is a plug on the phone to
    >>>>>>>>>>>> connect a PC.
    >>>>>>>>>>>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    >>>>>>>>>>>> doesnt have the horsepower to wrap a tag around every packet.
    >>>>>>>>>>>> - but you want the phone traffic kept separate from PC (security, QoS and
    >>>>>>>>>>>> so on).
    >>>>>>>>>>>> So - pass the PC packet thru untagged, and tag the phone traffic.
    >>>>>>>>>>>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    >>>>>>>>>>>> phone traffic is tagged and goes into a different VLAN.
    >>>>>>>>>>>>> TIA,
    >>>>>>>>>>>>> st
    >>>>>>>>>>>> --
    >>>>>>>>>>>> Regards
    >>>>>>>>>>>> - replace xyz with ntl
    >>>>>>>>>>> Thanks,
    >>>>>>>>>>> For "Some article say because of backward compatible with 802.3"
    >>>>>>>>>>> they may think far end is Hub or switch/bridge which does not support
    >>>>>>>>>>> 802.3,
    >>>>>>>>>>> right?
    >>>>>>>>>>> One more question, when a access port receive a untag frame, does it
    >>>>>>>>>>> add
    >>>>>>>>>>> a 802.1q tag or some other tag to make sure it can go same vlan inside
    >>>>>>>>>>> of
    >>>>>>>>>>> this switch?-
    >>>>>>>>>> I have read something somewhere that stated that the Tags are
    >>>>>>>>>> stripped off when frames enter the switch however clearly equivalent
    >>>>>>>>>> information is carried 'with' the frame 'through' the switch.
    >>>>>>>>>> So as far as we the Users are concerned I think that
    >>>>>>>>>> you would have a good way of thinking about it if
    >>>>>>>>>> you assumed that such a tag was used.
    >>>>>>>>> When you configure a port-based VLAN on a switch, you are telling the
    >>>>>>>>> switch which ports are to be grouped into a common broadcast domain
    >>>>>>>>> (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    >>>>>>>>> it knows which ports it is permitted to forward too based on the
    >>>>>>>>> separation of broadcast domains (VLANs). Of course, if the switch has
    >>>>>>>>> learned the port that the destination host resides on, it will only
    >>>>>>>>> forward it out that port within the appropriate VLAN (assuming a unicast
    >>>>>>>>> packet). Broadcast packets may be flooded to all ports within a VLAN.
    >>>>>>>>> Best Regards,
    >>>>>>>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>>>>>>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    >>>>>>>> let me clear the second question up:
    >>>>>>>> when a access port receive a untag frame from a
    >>>>>>>> host, does it add a 802.1q tag or some other tag to make sure it can
    >>>>>>>> go same vlan inside of switch?
    >>>>>>> I would "assume" that an untagged frame (the norm) sent by a host, and
    >>>>>>> received on a switch port that is assigned a non-native VLAN ID, would
    >>>>>>> get tagged at the ingress port; would remain so on its journey through
    >>>>>>> the switch, and get stripped on the egress port if the port was
    >>>>>>> configured for "access mode".
    >>>>>>> However, I would think that a programmer could (if desired) use some
    >>>>>>> other construct for segregating frames within the switch, and tag frames
    >>>>>>> as necessary as they egress onto a trunk port.
    >>>>>>> I think your answer is likely implementation dependent, and up to the
    >>>>>>> whims of the programmer.
    >>>>>>> Why get hung up on such an esoteric matter, when there are so many
    >>>>>>> practical issues to deal with?
    >>>>>>> Best Regards,
    >>>>>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>>>>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    >>>>>> Thanks, To raise this question is that I try to have a good understand
    >>>>>> mechanism of switch. Still have some questions here:
    >>>>>> 1. Based on what you explain it. For "a non-native VLAN ID" which you
    >>>>>> mentioned, this ID may be or may be not 802.1q tag, it depends on
    >>>>>> vender how to implement it. I think it is 802.1q tag,since port
    >>>>>> can also
    >>>>>> add 802.1p if it need it (3 bit for CoS). make sense? (maybe
    >>>>>> venders
    >>>>>> have diff. way to do it.)
    >>>>> Although I offered an opinion, I don't really care what mechanism the
    >>>>> programmer uses to segregate VLAN traffic as it passes through the
    >>>>> switch, as long as separate broadcast domains are honored. I care about
    >>>>> implementing functionality.
    >>>>>> 2. Let's go back practical issues, from a switch config point of view,
    >>>>>> the
    >>>>>> native vlan we have is because of trunk port. only trunk port can
    >>>>>> assign
    >>>>>> native Vlan. true? if other port is assign to as same as native
    >>>>>> Vlan ID,
    >>>>> The "switchport access" command on our switches permit us to assign a
    >>>>> VLAN only, no reference to "native". The "switchport trunk" command
    >>>>> permits defining a VLAN as 802.1Q native.
    >>>>>> then we say it is native vlan port. right? (assume all we talked
    >>>>>> here
    >>>>>> is access port)
    >>>>>> 3. We know for a trunk (assume two switch connected)should assgin same
    >>>>>> native vlan ID on both side. otherwise some vlan can not talk for
    >>>>>> some
    >>>>> The two switches should agree to tag or not to tag a given VLAN. There
    >>>>> is no requirement to use a native VLAN though. More on this below.
    >>>>>> case or may have loop. The most of switch default native vlan is
    >>>>>> vlan 1.
    >>>>>> What is purpose to assgin it to other than vlan 1 when config trunk
    >>>>>> port?
    >>>>> Personal preferences most likely.
    >>>>>> 4. Some article also say one benifit of native vlan is if this trunk
    >>>>>> failed, the
    >>>>>> native vlan (untagged message) can still work. What is trunk
    >>>>>> failed
    >>>>>> definition over here? What falure cause tagged frame cannot go
    >>>>>> through
    >>>>>> only untagged frame can.
    >>>>> Perhaps, if you used a native VLAN as an administrative VLAN (device
    >>>>> administration), it might give you some immunity from some configuration
    >>>>> errors, but I'm not aware of any such failure mode.
    >>>>>> 5. Is it valid that a switch trunk port to connect to a host NIC?
    >>>>>> (assume NIC
    >>>>>> is not 802.1q aware) if it is ok, it means that that server can
    >>>>>> only
    >>>>>> send/receive native vlan frame (untagged). right? what is purpose?
    >>>>>> it is just because of backward compatible?
    >>>>> If a server/host NIC was NOT 802.1Q aware you wouldn't connect it to a
    >>>>> trunk port on the switch, you'd connect it to an access port.
    >>>>>> 6. I remember (intel and broadcom) support 802.1q aware sever NIC.
    >>>>>> For somecase, say a small company that no need hosts talk bewteen
    >>>>>> vlans, only allow all vlans hosts talk to a server. then we can
    >>>>>> config a
    >>>>>> trunk port on switch and connect to that server. We dont need any
    >>>>>> routing protocol. Is that right? anyone use this way? (i know it
    >>>>> If a server NIC was 802.1Q aware, you could connect it to a trunk port
    >>>>> on the switch, enabling hosts from different VLANs to access the server.
    >>>>> Without a routing function, hosts in different VLANs would be isolated
    >>>>> from each other.
    >>>>>> has diff
    >>>>>> solution such as Pvlan)
    >>>>>> TIA,
    >>>>>> st
    >>>>> There is generally no need to use a native VLAN on a trunk. In fact it
    >>>>> is preferable from a security standpoint that you not use native VLANs
    >>>>> due to VLAN Hopping exploitation. We assign a specific VLAN (not VLAN1)
    >>>>> as the native, and then refrain from assigning any ports to the VLAN.
    >>>>> The trunk is then configured to permit specific VLANs only (excluding
    >>>>> the native, and excluding VLAN1). All traffic on our trunks are non-native.
    >>>>> We assign all unused (shutdown) ports to a specific VLAN (again, not
    >>>>> VLAN1). The default VLAN1 is not used at all.
    >>>>> Best Regards,
    >>>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    >>>> Very good feedback!
    >>>> How about management vlan?
    >>>> So you use Vlan1 for managment only or use others?
    >>> The last sentence of my post - "The default VLAN1 is not used at all."
    >>> ;>)
    >>> We use a specific VLAN for management

    >> ...
    >>
    >> ÔĶÁ¸ü¶à >>- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >>
    >> - ÏÔʾÒýÓõÄÎÄ×Ö -

    >
    > Still have a couple of questions to discuss with you.
    >
    > 1.Does it need any special config to make a management vlan
    > on cisco switch? or any vlan can do? I know some vender assign
    > one or two dedicate physical port to do it.


    The VLAN interface is a logical interface used for administration. If we
    wanted to use VLAN20 for administrative purposes we'd create a VLAN
    interface with the result being:

    interface Vlan1
    description Not to be used, for security reasons.
    no ip address
    shutdown
    !
    interface Vlan20
    description Management VLAN
    ip address 192.168.20.6 255.255.255.0


    >
    > 2. If no vlan1 go through trunk prot, how about some L2 protocol
    > such as VTP,CDP and PAgP etc., how do they work between
    > switches if they need it?


    Thank you for asking that question. It reminds me that I need to think
    beyond the environment (bubble) in which I work. The environment in
    which I work is not large enough to force us to use VTP, DTP, CDP etc.
    Each has it's own security implications, and we choose not to use these
    protocols.

    I did do some investigation though, so I can offer the following:

    I temporarily enable switchport negotiation on a trunk and observed that
    three DTP packets were immediately placed on the trunk with VLAN ID = 1.
    Thereafter, all DTP packets were sent with the native VLAN ID (not 1 in
    our case). This is despite the fact that neither of these VLANs are
    defined as permissible by the "switchport trunk allowed vlan x-y"
    command configured on the trunk.

    When I enabled CDP on the trunk interface the resulting packets used
    VLAN ID = 1.

    I don't have a network tap on the trunk port and am forced to use a SPAN
    port on the switch. If I set the encapsulation mode of the SPAN
    destination port to 802.1q, all packets are seen with 802.1q headers,
    even those that would not have a header (native) when placed on the
    wire. Therefore, I can not say conclusively whether the VLAN1 packets
    were sent with or without a header (I suspect they would be).

    >
    > 3. If no vlan1 go through trunk port, how spanning tree protocl?
    > any impact?


    There are different spanning tree modes. We're using PVST (per VLAN
    Spanning Tree).

    spanning-tree mode pvst

    STP packets are sent in each of the VLANs on the trunk.

    > all above assume switch to switch trunk connection (use 802.1q.)
    >
    > TIA,
    > st
    >


    Best Regards,
    News Reader
     
    News Reader, Apr 17, 2008
    #19
  20. Guest

    On 4ÔÂ16ÈÕ, ÏÂÎç5ʱ59·Ö, News Reader <> wrote:
    > wrote:
    > > On 4ÔÂ16ÈÕ, ÏÂÎç4ʱ03·Ö, wrote:
    > >> On 4ÔÂ16ÈÕ, ÏÂÎç3ʱ07·Ö, News Reader <> wrote:

    >
    > >>> wrote:
    > >>>> On 4ÔÂ16ÈÕ, ÏÂÎç1ʱ57·Ö, News Reader <> wrote:
    > >>>>> wrote:
    > >>>>>> On 4ÔÂ16ÈÕ, ÉÏÎç8ʱ05·Ö, News Reader <> wrote:
    > >>>>>>> wrote:
    > >>>>>>>> On 4ÔÂ16ÈÕ, ÉÏÎç6ʱ54·Ö, News Reader <> wrote:
    > >>>>>>>>> wrote:
    > >>>>>>>>>> On 16 Apr, 05:31, wrote:
    > >>>>>>>>>>> On 4ÔÂ15ÈÕ, ÏÂÎç1ʱ13·Ö, "stephen" <> wrote:
    > >>>>>>>>>>>> <> wrote in message
    > >>>>>>>>>>>>news:...
    > >>>>>>>>>>>>> A lot of people ask native vlan question.
    > >>>>>>>>>>>>> I think using "vlan dot1q tag native" should eliminate this question.
    > >>>>>>>>>>>>> at least for sw---sw connection. (all tagged just like isl)
    > >>>>>>>>>>>>> I may not fully understand what's purpose why cisco make "native
    > >>>>>>>>>>>>> vlan".
    > >>>>>>>>>>>> cisco didnt invent this - it is part of 802.1Q.
    > >>>>>>>>>>>>> Some article say because of backward compatible with 802.3.
    > >>>>>>>>>>>> i suggest you try to find the standard and read around that,
    > >>>>>>>>>>>> maybe start atwww.ieee.org
    > >>>>>>>>>>>> AFAIR some of the standards docs are without charge for Ethernet.
    > >>>>>>>>>>>>> Can anyone give an example?
    > >>>>>>>>>>>> there are 2 Qs to think about.
    > >>>>>>>>>>>> 1. set a port to be tagged
    > >>>>>>>>>>>> - what do you do with a packet that arrives with no tag?
    > >>>>>>>>>>>> the 2 common answers are to throw it away, or to put it into some sort of
    > >>>>>>>>>>>> "default VLAN" - that is what untagged means for incoming packets.
    > >>>>>>>>>>>> not putting a tag on outbound packets form that VLAN on that port allows 2
    > >>>>>>>>>>>> way comms.
    > >>>>>>>>>>>> this sounds silly - but it is what often needs to happen when you hook up an
    > >>>>>>>>>>>> unconfigured device to set it up.
    > >>>>>>>>>>>> 2. what happens when you want to split up 2 streams of packets on a port?
    > >>>>>>>>>>>> sometimes you have a device that will add its own stream of packets to a set
    > >>>>>>>>>>>> it gets from elsewhere
    > >>>>>>>>>>>> - the classic case is an IP phone where there is a plug on the phone to
    > >>>>>>>>>>>> connect a PC.
    > >>>>>>>>>>>> - Pcs dont normally send tagged frames, and the 3 port bridge in the phone
    > >>>>>>>>>>>> doesnt have the horsepower to wrap a tag around every packet.
    > >>>>>>>>>>>> - but you want the phone traffic kept separate from PC (security, QoS and
    > >>>>>>>>>>>> so on).
    > >>>>>>>>>>>> So - pass the PC packet thru untagged, and tag the phone traffic.
    > >>>>>>>>>>>> At the switch the PC "stuff" is untagged and goes into the native VLAN,
    > >>>>>>>>>>>> phone traffic is tagged and goes into a different VLAN.
    > >>>>>>>>>>>>> TIA,
    > >>>>>>>>>>>>> st
    > >>>>>>>>>>>> --
    > >>>>>>>>>>>> Regards
    > >>>>>>>>>>>> - replace xyz with ntl
    > >>>>>>>>>>> Thanks,
    > >>>>>>>>>>> For "Some article say because of backward compatible with 802.3"
    > >>>>>>>>>>> they may think far end is Hub or switch/bridge which does not support
    > >>>>>>>>>>> 802.3,
    > >>>>>>>>>>> right?
    > >>>>>>>>>>> One more question, when a access port receive a untag frame, does it
    > >>>>>>>>>>> add
    > >>>>>>>>>>> a 802.1q tag or some other tag to make sure it can go same vlan inside
    > >>>>>>>>>>> of
    > >>>>>>>>>>> this switch?-
    > >>>>>>>>>> I have read something somewhere that stated that the Tags are
    > >>>>>>>>>> stripped off when frames enter the switch however clearly equivalent
    > >>>>>>>>>> information is carried 'with' the frame 'through' the switch.
    > >>>>>>>>>> So as far as we the Users are concerned I think that
    > >>>>>>>>>> you would have a good way of thinking about it if
    > >>>>>>>>>> you assumed that such a tag was used.
    > >>>>>>>>> When you configure a port-based VLAN on a switch, you are telling the
    > >>>>>>>>> switch which ports are to be grouped into a common broadcast domain
    > >>>>>>>>> (VLAN). Therefore when a switch receives a tagged frame on a trunk port,
    > >>>>>>>>> it knows which ports it is permitted to forward too based on the
    > >>>>>>>>> separation of broadcast domains (VLANs). Of course, if the switch has
    > >>>>>>>>> learned the port that the destination host resides on, it will only
    > >>>>>>>>> forward it out that port within the appropriate VLAN (assuming a unicast
    > >>>>>>>>> packet). Broadcast packets may be flooded to all ports within a VLAN.
    > >>>>>>>>> Best Regards,
    > >>>>>>>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    > >>>>>>>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    > >>>>>>>> let me clear the second question up:
    > >>>>>>>> when a access port receive a untag frame from a
    > >>>>>>>> host, does it add a 802.1q tag or some other tag to make sure it can
    > >>>>>>>> go same vlan inside of switch?
    > >>>>>>> I would "assume" that an untagged frame (the norm) sent by a host, and
    > >>>>>>> received on a switch port that is assigned a non-native VLAN ID, would
    > >>>>>>> get tagged at the ingress port; would remain so on its journey through
    > >>>>>>> the switch, and get stripped on the egress port if the port was
    > >>>>>>> configured for "access mode".
    > >>>>>>> However, I would think that a programmer could (if desired) use some
    > >>>>>>> other construct for segregating frames within the switch, and tag frames
    > >>>>>>> as necessary as they egress onto a trunk port.
    > >>>>>>> I think your answer is likely implementation dependent, and up to the
    > >>>>>>> whims of the programmer.
    > >>>>>>> Why get hung up on such an esoteric matter, when there are so many
    > >>>>>>> practical issues to deal with?
    > >>>>>>> Best Regards,
    > >>>>>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    > >>>>>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    > >>>>>> Thanks, To raise this question is that I try to have a good understand
    > >>>>>> mechanism of switch. Still have some questions here:
    > >>>>>> 1. Based on what you explain it. For "a non-native VLAN ID" which you
    > >>>>>> mentioned, this ID may be or may be not 802.1q tag, it depends on
    > >>>>>> vender how to implement it. I think it is 802.1q tag,since port
    > >>>>>> can also
    > >>>>>> add 802.1p if it need it (3 bit for CoS). make sense? (maybe
    > >>>>>> venders
    > >>>>>> have diff. way to do it.)
    > >>>>> Although I offered an opinion, I don't really care what mechanism the
    > >>>>> programmer uses to segregate VLAN traffic as it passes through the
    > >>>>> switch, as long as separate broadcast domains are honored. I care about
    > >>>>> implementing functionality.
    > >>>>>> 2. Let's go back practical issues, from a switch config point of view,
    > >>>>>> the
    > >>>>>> native vlan we have is because of trunk port. only trunk port can
    > >>>>>> assign
    > >>>>>> native Vlan. true? if other port is assign to as same as native
    > >>>>>> Vlan ID,
    > >>>>> The "switchport access" command on our switches permit us to assign a
    > >>>>> VLAN only, no reference to "native". The "switchport trunk" command
    > >>>>> permits defining a VLAN as 802.1Q native.
    > >>>>>> then we say it is native vlan port. right? (assume all we talked
    > >>>>>> here
    > >>>>>> is access port)
    > >>>>>> 3. We know for a trunk (assume two switch connected)should assgin same
    > >>>>>> native vlan ID on both side. otherwise some vlan can not talk for
    > >>>>>> some
    > >>>>> The two switches should agree to tag or not to tag a given VLAN. There
    > >>>>> is no requirement to use a native VLAN though. More on this below.
    > >>>>>> case or may have loop. The most of switch default native vlan is
    > >>>>>> vlan 1.
    > >>>>>> What is purpose to assgin it to other than vlan 1 when config trunk
    > >>>>>> port?
    > >>>>> Personal preferences most likely.
    > >>>>>> 4. Some article also say one benifit of native vlan is if this trunk
    > >>>>>> failed, the
    > >>>>>> native vlan (untagged message) can still work. What is trunk
    > >>>>>> failed
    > >>>>>> definition over here? What falure cause tagged frame cannot go
    > >>>>>> through
    > >>>>>> only untagged frame can.
    > >>>>> Perhaps, if you used a native VLAN as an administrative VLAN (device
    > >>>>> administration), it might give you some immunity from some configuration
    > >>>>> errors, but I'm not aware of any such failure mode.
    > >>>>>> 5. Is it valid that a switch trunk port to connect to a host NIC?
    > >>>>>> (assume NIC
    > >>>>>> is not 802.1q aware) if it is ok, it means that that server can
    > >>>>>> only
    > >>>>>> send/receive native vlan frame (untagged). right? what is purpose?
    > >>>>>> it is just because of backward compatible?
    > >>>>> If a server/host NIC was NOT 802.1Q aware you wouldn't connect it to a
    > >>>>> trunk port on the switch, you'd connect it to an access port.
    > >>>>>> 6. I remember (intel and broadcom) support 802.1q aware sever NIC.
    > >>>>>> For somecase, say a small company that no need hosts talk bewteen
    > >>>>>> vlans, only allow all vlans hosts talk to a server. then we can
    > >>>>>> config a
    > >>>>>> trunk port on switch and connect to that server. We dont need any
    > >>>>>> routing protocol. Is that right? anyone use this way? (i know it
    > >>>>> If a server NIC was 802.1Q aware, you could connect it to a trunk port
    > >>>>> on the switch, enabling hosts from different VLANs to access the server.
    > >>>>> Without a routing function, hosts in different VLANs would be isolated
    > >>>>> from each other.
    > >>>>>> has diff
    > >>>>>> solution such as Pvlan)
    > >>>>>> TIA,
    > >>>>>> st
    > >>>>> There is generally no need to use a native VLAN on a trunk. In fact it
    > >>>>> is preferable from a security standpoint that you not use native VLANs
    > >>>>> due to VLAN Hopping exploitation. We assign a specific VLAN (not VLAN1)
    > >>>>> as the native, and then refrain from assigning any ports to the VLAN..
    > >>>>> The trunk is then configured to permit specific VLANs only (excluding
    > >>>>> the native, and excluding VLAN1). All traffic on our trunks are non-native.
    > >>>>> We assign all unused (shutdown) ports to a specific VLAN (again, not
    > >>>>> VLAN1). The default VLAN1 is not used at all.
    > >>>>> Best Regards,
    > >>>>> News Reader- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    > >>>>> - ÏÔʾÒýÓõÄÎÄ×Ö -
    > >>>> Very good feedback!
    > >>>> How about management vlan?
    > >>>> So you use Vlan1 for managment only or use others?
    > >>> The last sentence of my post - "The default VLAN1 is not used at all."
    > >>> ;>)
    > >>> We use a specific VLAN for management
    > >> ...

    >
    > >> ÔĶÁ¸ü¶à >>- Òþ²Ø±»ÒýÓÃÎÄ×Ö -

    >
    > >> - ÏÔʾÒýÓõÄÎÄ×Ö -

    >
    > > Still have a couple of questions to discuss with you.

    >
    > > 1.Does it need any special config to make a management vlan
    > > on cisco switch? or any vlan can do? I know some vender assign
    > > one or two dedicate physical port to do it.

    >
    > The VLAN interface is a logical interface used for administration. If we
    > wanted to use VLAN20 for administrative purposes we'd create a VLAN
    > interface with the result being:
    >
    > interface Vlan1
    > description Not to be used, for security reasons.
    > no ip address
    > shutdown
    > !
    > interface Vlan20
    > description Management VLAN
    > ip address 192.168.20.6 255.255.255.0
    >
    >
    >
    > > 2. If no vlan1 go through trunk prot, how about some L2 protocol
    > > such as VTP,CDP and PAgP etc., how do they work between
    > > switches if they need it?

    >
    > Thank you for asking that question. It reminds me that I need to think
    > beyond the environment (bubble) in which I work. The environment in
    > which I work is not large enough to force us to use VTP, DTP, CDP etc.
    > Each has it's own security implications, and we choose not to use these
    > protocols.
    >
    > I did do some investigation though, so I can offer the following:
    >
    > I temporarily enable switchport negotiation on a trunk and observed that
    > three DTP packets were immediately placed on the trunk with VLAN ID = 1.
    > Thereafter, all DTP packets were sent with the native VLAN ID (not 1 in
    > our case). This is despite the fact that neither of these VLANs are
    > defined as permissible by the "switchport trunk allowed vlan x-y"
    > command configured on the trunk.
    >
    > When I enabled CDP on the trunk interface the resulting packets used
    > VLAN ID = 1.
    >
    > I don't have a network tap on the trunk port and am forced to use a SPAN
    > port on the switch. If I set the encapsulation mode of the SPAN
    > destination port to 802.1q, all packets are seen with 802.1q headers,
    > even those that would not have a header (native) when placed on the
    > wire. Therefore, I can not say conclusively whether the VLAN1 packets
    > were sent with or without a header (I suspect they would be).
    >
    >
    >
    > > 3. If no vlan1 go through trunk port, how spanning tree protocl?
    > > any impact?

    >
    > There are different spanning tree modes. We're using PVST (per VLAN
    > Spanning Tree).
    >
    > spanning-tree mode pvst
    >
    > STP packets are sent in each of the VLANs on the trunk.
    >
    > > all above assume switch to switch trunk connection (use 802.1q.)

    >
    > > TIA,
    > > st

    >
    > Best Regards,
    > News Reader

    "interface Vlan20
    description Management VLAN
    ip address 192.168.20.6 255.255.255.0"

    Looks your management vlan has not special config.
    Does any Vlan assign ip addr. to be a management vlan?
    I think every vlan wants to routing must be assign a ip addr.
     
    , Apr 17, 2008
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. PS2 gamer
    Replies:
    1
    Views:
    1,082
    Ivan Ostres
    May 28, 2004
  2. avraham shir-el
    Replies:
    4
    Views:
    8,619
    avraham shir-el
    Jul 20, 2004
  3. Andy
    Replies:
    1
    Views:
    12,094
    Walter Roberson
    Sep 21, 2005
  4. Replies:
    4
    Views:
    1,047
  5. paul1537
    Replies:
    0
    Views:
    1,786
    paul1537
    May 15, 2008
Loading...

Share This Page