From: Jeremy O'Dette (jeremyodette@hotmail.com)
Date: Thu Dec 22 2005 - 16:10:57 GMT-3
Just wanted to start this off with the reminder that the concept of a
'native vlan' only applies to dot1q trunks... ISL explicitly tags all frames
that go through an ISL trunk so you never have to worry about native vlans
on ISL trunks. In 802.1q it is possible for a frame to not get tagged when
it goes across the trunk. If a switch receives an untagged frame on a port
that is operating as an 802.1q (dot1q) trunk it will assume the the frame
should be forwarded to the native vlan.
Here is a useful link that goes over frame format
http://www.cisco.com/en/US/tech/tk389/tk390/technologies_tech_note09186a0080094665.shtml
>1. Management Interface is set to VLAN 254?
Yes - although its more accurate to say "you have a switch virtual interface
(SVI) for vlan 254 which could be used for management"... you could also
have other SVIs as needed.
>2. Native VLAN to TRK-SW2 is set to whatever is '1' (Default VLAN is listed
>in SH VLAN command as 1)
If you don't explicitly set the native vlan on a dot1q trunk it will default
to vlan as the native vlan. This means that vlan 1 frames will be sent
untagged across the trunk, frames from all other vlans will be tagged with
the vlan ID.
>3. Why would anybody change the NATIVE VLAN to something else other than
>Default VLAN?
There are a lot of good reasons to remove VLAN 1 from your network to
increase security. There is some more information here:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml
>4. If they change to something else which VLAN's are the most likely
>candidates? Is it management VLAN created?
That entirely depends on how your network is designed... it is important to
make sure that your native vlan settings match on both sides of a trunk
link. If they don't the ports will often go errdisable.
>5. Is it necessary to include the VLAN 254(MGMT VLAN) in the trunk allowed
>VLAN list?
Yes... if you want traffic from that vlan to be able to cross that trunk.
Jeremy O'Dette
CCIE #14973
jeremyodette@hotmail.com
>From: "Capt.Spock" <capt.spock@gmail.com>
>Reply-To: "Capt.Spock" <capt.spock@gmail.com>
>To: Group Study <ccielab@groupstudy.com>
>Subject: Clearing some DUST abt NATIVE VLAN.....
>Date: Thu, 22 Dec 2005 11:52:30 -0500
>
>Trying to understand NATIVE VLAN. Appreciate your inputs. Thanks for TIM
>clearing up some dust abt NATIVE VLAN.
>
>I have a trunk to another switch...
>
>interface GigabitEthernet0/22
> description Trunk To TRK-SW2 22x
> switchport trunk encapsulation dot1q
> switchport trunk allowed vlan
>21,22,48-50,100,103,106,149,169,202,223,247,252
> switchport mode trunk
>!
>
>interface Vlan1
> no ip address
> no ip route-cache
> shutdown
>!
>interface Vlan254
> ip address 10.11.254.161 255.255.255.0
> no ip route-cache
>
>Does the above config mean that ...
>
>1. Management Interface is set to VLAN 254?
>
>2. Native VLAN to TRK-SW2 is set to whatever is '1' (Default VLAN is listed
>in SH VLAN command as 1)
>
>3. Why would anybody change the NATIVE VLAN to something else other than
>Default VLAN?
>
>4. If they change to something else which VLAN's are the most likely
>candidates? Is it management VLAN created?
>
>5. Is it necessary to include the VLAN 254(MGMT VLAN) in the trunk allowed
>VLAN list?
>
>
> interface GigabitEthernet0/22
> description Trunk To TRK-SW2 22x
> switchport trunk encapsulation dot1q
> switchport trunk allowed vlan
>21,22,48-50,100,103,106,149,169,202,223,247,252
> switchport mode trunk
> switchport trunk native vlan 254
>!
>
>Thanks!
>
>
>
>
>
>On 12/22/05, Tim <ccie2be@nyc.rr.com> wrote:
> >
> > OK, this doesn't have much to do with AP's but I'll take a crack at it.
> >
> >
> >
> > See comments in-line
> >
> >
> >
> > Tim
> >
> >
> > ------------------------------
> >
> > *From:* Capt.Spock [mailto:capt.spock@gmail.com]
> > *Sent:* Thursday, December 22, 2005 10:37 AM
> > *To:* Tim
> > *Subject:* Re: Way OT: Aironet AP's -- Functionally more repeater or
>more
> > bridge?
> >
> >
> >
> > Tim, How is it going? I read number of your posts in groupstudy and they
> > were very informative. I need some help in nailing NATIVE VLAN concept
>for
> > ever.
> >
> >
> >
> > As far as I know NATIVE vlan is mainly for dot1q encapsulation trunk. If
>a
> > switch finds a pakcet without a VLAN info then it will tag it to the
> > specified NATIVE VLAN and send it to the other side. This traffic may
> > include system traffic like CDP traffic or whatever traffic that is
>SYSTEM
> > generated.
> >
> >
> >
> > AM I right till now?
> >
> >
> >
> > Yes, the native vlan is ONLY for 802.1q trunks. ISL trunks have no
> > concept of native vlans. Keep in mind that the concept of native has
> > meaning ONLY in the context of trunks. If there are no trunks, then
>there
> > are no native vlans.
> >
> >
> >
> > Now, let's get back to the definition of a native vlan in the context of
> > trunks. A frame crossing an 802.1q trunk can be tagged or not tagged.
> > This is different than ISL where every frame is tagged. So, are you
>ready?
> > Are you sitting down? Brace yourself because I'm about to reveal the
>true
> > and complete secret of native vlans. So, here ya go.
> >
> >
> >
> > If a frame comes across a trunk and it does NOT have a tag telling the
> > receiving switch which vlan this frame belongs in, then (can I have a
>drum
> > roll, please) this frame is in the NATIVE VLAN. PERIOD. END OF STORY.
> >
> >
> >
> > But wait, you say, "which vlan is the native vlan?"
> >
> >
> >
> > Easy, it's any vlan you want it to be when you specify the native vlan.
> > And, if you don't explicitly specify a native vlan, then, by default,
>it's
> > vlan 1.
> >
> >
> >
> > How does this NATIVE VLAN relate to the MGMT VLAN? Many of the switches
>I
> > saw have a VLAN other than 1 being used as MGMT VLAN. like
> >
> >
> >
> > int VLAN 100
> >
> > IP address
> >
> >
> >
> > Ah, the management vlan. This is a rather nebulous term. Vendors and
> > marketing folk tend to obscure the meaning of this to the point where it
> > almost has no meaning. But, here's one way to think about the
>management
> > vlan: This vlan is created to carry only management traffic such as
>snmp,
> > syslog, SSH, IDS alerts, ntp, etc. No user traffic should ever transit
>the
> > management vlan. Use this vlan as an out-of-band means of connecting to
> > your network equipment.
> >
> >
> >
> > This VLAN 100 is being mentioned as NATIVE VLAN in any of the trunks
>that
> > are being created. Is this DEFACTO standard?
> >
> >
> >
> > No, there is no DEFACTO standard for the native vlan but also keep in
>mind
> > that whatever native vlan you specify on one side of the trunk you must
>also
> > specify on the other side of the trunk.
> >
> >
> >
> > Am I lost at this point? No more than I was at one point earlier in my
> > life.
> >
> >
> >
> > Where does DEFAULT VLAN come in to picture?
> >
> >
> >
> > This is the vlan that becomes the native vlan if you don't specify a
> > different native vlan. It's also the vlan used for certain types of
>switch
> > traffic such as VTP ( I believe but I'm not 100% sure about).
> >
> >
> >
> >
> >
> > Thanks for your help!
> >
> >
> >
> > You're welcomed, Tim
> >
> >
> >
> > Now, what's the story with the AP's?
> >
> >
> >
> >
> >
> > On 12/22/05, *Tim* <ccie2be@nyc.rr.com> wrote:
> >
> > Hi guys,
> >
> >
> >
> > I'm starting to refresh myself on this WLAN technology and I was
> > wondering.
> >
> >
> >
> > Would an AP be considered more a repeater or more a bridge?
> >
> >
> >
> > Or, does it depend on the topology?
> >
> >
> >
> >
> >
> > For example, suppose this were our 802.11 topology (and assume no ad-hoc
> > peering between pc1 and pc2)
> >
> >
> >
> >
> >
> >
> >
> > pc 1 pc 2
> >
> >
> >
> >
> >
> > AP
> >
> > |
> >
> > |-----------------------------------------------------------|
> >
> > |
> >
> > server
> >
> >
> >
> >
> >
> > When pc 1 is talking to pc 2 via the AP, is the AP acting like a
>repeater?
> >
> >
> >
> > And, when pc 1 is talking to the server via the AP, is the AP acting
>like
> > a
> > bridge (switch) and thus building a mac address table?
> >
> >
> >
> > I've been reviewing lots of WLAN material but nothing seems to discuss
> > this
> > issue.
> >
> >
> >
> > If these are really dumb questions, please accept my apologies and try
>to
> > set me straight.
> >
> >
> >
> > Thanks, Tim
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:52 GMT-3