Clearing some DUST abt NATIVE VLAN.....

From: Capt.Spock (capt.spock@gmail.com)
Date: Thu Dec 22 2005 - 13:52:30 GMT-3


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



This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:52 GMT-3