Native vlan tagging and vty access to Autonomous APs

[trevormark]

Hello and thanks for reading!          

I've been experimenting with the 'vlan dot1q tag native' command on a switch and it seems as though tagging the native vlan breaks vty access to my access point.

With the 'vlan dot1q tag native' commnand applied, I lose management connectivity to the AP with 'no vlan dot1q tag native' applied, connectivity is restored. Why is this? Is it safe to say that one can access the AP via vty lines using ONLY untagged packets?

Can anyone shed light on this?

SWITCH

Model: WS-C3560G-24PS

Code: c3560-advipservicesk9-mz.122-46.SE

--Abbreviated CONF

vlan dot1q tag native

!

interface GigabitEthernet0/1

description AIRONET

switchport trunk encapsulation dot1q

switchport trunk native vlan 2

switchport trunk allowed vlan 2,4,8,16

switchport mode trunk

-------------------------

ACCESS POINT

Model: AIR-AP1042N-A-K9 

Code: c1140-k9w7-mx.124-25d.JA1

--Abbreviated CONF

interface Dot11Radio0.2

encapsulation dot1Q 2 native

no ip route-cache

bridge-group 1

bridge-group 1 subscriber-loop-control

bridge-group 1 block-unknown-source

no bridge-group 1 source-learning

no bridge-group 1 unicast-flooding

bridge-group 1 spanning-disabled

!

interface GigabitEthernet0

no ip address

no ip route-cache

duplex auto

speed auto

no keepalive

!

interface GigabitEthernet0.2

encapsulation dot1Q 2 native

no ip route-cache

bridge-group 1

no bridge-group 1 source-learning

bridge-group 1 spanning-disabled

[Andras Dosztal]

This config was copied from one of my operating 1131AG APs:

Switch:

interface FastEthernet0/21
 description AP
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 2
 switchport mode trunk
 spanning-tree portfast
 spanning-tree bpduguard enable

AP:

interface Dot11Radio0.3
 encapsulation dot1Q 3
 no ip route-cache
 no cdp enable
 bridge-group 3
 bridge-group 3 subscriber-loop-control
 bridge-group 3 block-unknown-source
 no bridge-group 3 source-learning
 no bridge-group 3 unicast-flooding
 bridge-group 3 spanning-disabled
!
interface FastEthernet0.2
 description Management
 encapsulation dot1Q 2 native
 no ip route-cache
 bridge-group 1
 no bridge-group 1 source-learning
 bridge-group 1 spanning-disabled
!
interface FastEthernet0.3
 description SSID 
 encapsulation dot1Q 3
 no ip route-cache
 no cdp enable
 bridge-group 3
 no bridge-group 3 source-learning
 bridge-group 3 spanning-disabled
!
interface FastEthernet0
 no ip address
 no ip route-cache
 duplex auto
 speed auto
 bridge-group 1
 no bridge-group 1 source-learning
 bridge-group 1 spanning-disabled
 hold-queue 160 in
!
interface BVI1
 ip address 
 no ip route-cache

[trevormark]

Andras,

Is native vlan tagging enabled on this switch?

Sent from Cisco Technical Support iPhone App

[kcnajaf]

Hi Trevormark,

By default native vlan traffic is untagged vlans on the trunk link as you may be aware. The rule of thumb is that if you are using a specific vlan as native vlan on the trunk then you should ensure that the device connected to the other end of trunk port also has the same vlan configured as native vlan.

So from your configuration wise you have "switchport trunk native vlan 2" on the switch trunk and you have "

encapsulation dot1Q 2 native" on the radio and gig sub interfaces on the AP. This configurations are correct since you have the same native vlan used on the both ends of a trunk link. This means VLAN 2 traffic will not be tagged while passing through the trunk link.

But when you apply "vlan dot1q tag native" on the switch end you are asking the switch to tag the native vlan (in your case this means vlan 2 traffic will be send to AP as tagged). Now you have a mismatch of configuration where in you are tagging vlan 2 at the switch end and the AP end you not tagging vlan 2 and hence AP will reject all tagged vlan2 packets.. This will result in communication failure between these two devices and that is the reason why you lose access to the VTY.

Hope this helps.

Najaf

Please rate when applicable or helpful !!!

[trevormark]

Najaf,

Since 'vlan dot1q tag native' is a global command, how is one supposed to access an AP that drops all tagged traffic on its native vlan?

Sent from Cisco Technical Support iPhone App

[mahmoodmkl]

Hi,

Can you try giving

encapsulation dot1Q 2

Thanks

[Julio Carvajal]

Hello Trevor,

I got to admit.. I am not an Wireless expert ( Not even close to that ) but I had a case yesterday with an ASA a layer 2 switch and an AP and this device for managment purposes was only available using untagged packets but we still need it to send tagged packets for the rest of the user traffic.

That being said.. I would say via console cable lol .... But why dont you send the user traffic tagged and then just use a particular vlan for the AP so you can access it ???

That way is a win win

Hope I could help

[trevormark]

jcarvaja,

'vlan dot1q tag native' is a global command, meaning it is either applied or its not. When it is applied, all vlans are tagged.

Sent from Cisco Technical Support iPhone App

[Julio Carvajal]

Hello Trevor,

I know what that command does, that is why I provided you the solution already,  and as I already said the AP will only accept untagged packets on its vty lines, so again use a trunk link allowing the users vlans and put the AP on the untagged ( native) vlan on that trunk,

As simple as that, I got it working 2 days ago with that..

So nothing to worry. Expected behavior

Regards

[kcnajaf]

Hi Trevormark

Believe me you have asked an interesting question but unforutnatly i dont know the answer for the same :-(

Also i dont have a lab to test this out :-(

Could you try removing the the native commands on the trunk port and access point and check if you are able to ping between them.

It will be interesting to know the result :-)

Regards

Najaf

[Suresh Vinayagam Subramanian]

Hi Trevormark,

"Since 'vlan dot1q tag native' is a global command, how is one supposed to access an AP that drops all tagged traffic on its native vlan?"

I believe , user vlans are in other vlans and your management vlan in vlan 2 which is Native.

You are tagging vlan 2 on switch side as '" vlan dot1q tag native" command will tag all the vlans including native vlan and AP will drop this traffic as AP will expect untagged traffic from vlan 2.

Users traffic is not affected as packet tagged on both side.

Regards,

V.S.Suresh .

[trevormark]

Najaf,

Apparently the APs will ONLY allow untagged traffic on their vty lines. This was confirmed by Scott Fella in another users thread.

By this logic, your suggestion of removing the 'native' option on the trunk as well as the AP, will have no effect since the switch would still be sending tagged traffic.

That said, the options are to disable 'vlan dot1q tag native' or attach the AP to a different switch in the topology that does not have native vlan tagging enabled.

Regards,
Trevor

Sent from Cisco Technical Support iPhone App

[kcnajaf]

Hi Trevormark,

It looks like every day is a school day where i learn some thing new :-)

Thanks for confirming the point that AP's does not allow untagged packets on management interface. If Scott has said that then that would be the fact as I know he is an expert in wireless :-)

So to conclude if we have 'vlan dot1q tag native' enabled globally on a switch then we can not have any AP's (with switch port configured as trunk) connected to any port of this switch accessible through the vty because switch will send tagged packet over the trunk link and AP's does not accept tagged packet on management interface. PLEASE CONFIRM IF MY UNDERSTANDING IS CORRECT HERE...

Scott,

I'm sure that you would be going through this post (as this is related to AP) and hence please confirm my understanding is correct here.....

Thanks in advance.

Regards

Najaf

[trevormark]

Najaf,

I believe you understand it correctly. There is one caveat I see however. For security purposes, enabling native vlan tagging AND configuring a switchport as trunk with an AP attached disables management access entirely (via vty). We could then limit management access to console port (if acceptable). The AP is then quite secure and still functions normally for wireless users.

Regards,
Trevor

Sent from Cisco Technical Support iPhone App

[kcnajaf]

Hi Trevomark,

I labbed this up today.

Interestingly result is that even with the vlan dot1q tag native command enabled globally on the switch i was able to reach the AP's management address which was against as per our theory.

As per the original posted the AP was not reachable after enabling vlan dot1q tag native globally but surprisingly for me, the AP was pinging even when the switch was sending tagged packet to the AP with vlan dot1q tag native command enabled globally

.

I have attached the details of my test bed.

Does any one have any clue for this?

Regards

Najaf