Controllerless Networks

Hi,

I have some issues with VLAN tagging withIAP-105.

I have a network with 3 VLAN:

VLAN 1:          10.10.0.0/16

VLAN 2:          192.168.2.0/24

VLAN 150:      192.168.150.0/24

 

VLAN 1 is the management VLAN in the LAN, while VLAN 150 is the management VLAN for the IAP-105 (I define it in the Uplink Management VLAN parameter for the IAP). The network has a Layer3 switch to implement routing beetwen VLANs.

I create two SSIDs, assigning each a Static VLAN ID in the VLAN screen of WLAN definition. The two SSID are:

WiFi-Test1, with VLAN ID 1

WiFi-Test2, with VLAN ID 2

 

The interface of the switch where I connect the IAP-105 is a trunk with the native VLAN 150 and tagged VLAN 1, 2. The interface in which I connect my laptop is defined Access with VLAN 1.

If a client associates to SSID WiFi-Test1, with an IP in the VLAN 1 network (10.10.0.5), I can't ping it.

If a client associates to SSID WiFi-Test2, with an IP in the VLAN 2 network (192.168.2.5), I can ping it, instead.

I try to substitute VLAN 1 with VLAN 118 (10.118.0.0/16) in the WiFi-Test1 definition, and I create the VLAN 118 in the LAN, defining it tagged in the interface where the IAP is connected: with these changes I can ping a client that is associated to WiFi-Test1, with an IP in the subnet 10.118.0.0/16.

 

I think that the problem with VLAN 1 tagging should be a bug of the IAP. Is true?

There is anyone else who had a similar problem?

 

Thanks,

 

Massimo

 

 

 

If you connect another machine directly to the switch on VLAN1 can you ping it?

Do you mean in an interface in Access mode with VLAN1? Yes, I can ping it!

I am having a similar problem.

 

My IAP config:

I have 2 wlan in IAP, and the management interface of IAP is in a native vlan 90 (mngt)

wlan1 - vlan 1

wlan4 - vlan 4

uplink management - trunk - native vlan 90 - allowed all vlans

 

wired-port-profile default_wired_port_profile
switchport-mode trunk
allowed-vlan all
native-vlan 90
no shutdown

 

wlan ssid-profile WLAN4
index 4
type employee
essid WLAN4
vlan 4

 

wlan ssid-profile WLAN1
index 1
type employee
essid WLAN1
vlan 1

 

In my switch (L3) i configured both interfcaces vlan 1 and 4 (with dhcp), and vlan 90 (no dhcp)

(the IAP has an fixed IPaddress).

 

The uplink to the IAP:

description *** IAP Aruba Test ***
switchport trunk native vlan 90
switchport trunk allowed vlan 1,4,90
switchport mode trunk
no cdp enable
end

 

The clients connecting to the wlan1 (vlan1) cant´t get an IP. It seems that they are falling into the native vlan 90.

Does the IAP tag the vlan 1? I am missing something?

 

Thank you all.

gmoutinho

Hi,

 

By default IAP consider native vlan as 1 and consider the wireless users traffic from vlan 1 as untagged.

To mitigate this situation we neeed to run the below command in CLI of IAP.

Conf t

enet-vlan <native vlan>

commit apply

 

 

This will chnage the default native vlan 1 to the exisitng one.

 

Thanks,
Sreejith

Awesome Sreejith. Got it.

Thanks Sreejith!!!

This finally solves my issue!

Hi Sreejith,

 

Would this be a recommended config? Could there be any issues related to it?

 

Br

Peter

Hi,

 

By running the above config, we are making sure that vlan 1 traffic should be tagged while leave the IAP.

 

Thanks,

Sreejith

I am having VLAN tagging issue as well*****************************************************.

 

Switch trunk is configured as below.

interface FastEthernet2/0/13
 description *** Connection to ARUBA WIRELESS AP ***
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 8
 switchport trunk allowed vlan 8-10
 switchport mode trunk
 switchport nonegotiate
 duplex full
 mls qos trust dscp
 spanning-tree portfast trunk
 spanning-tree guard root

 

VLANS brief *****************************************************.

vlan 8
 name NOR_Management
!
vlan 9
 name Data
!
vlan 10
 name Voice
!
vlan 13
 name HyperV
!
vlan 255
 name Native
!
vlan 1000
 name Unused_Ports

 

 

IAP port configs *****************************************************.

wired-port-profile default_wired_port_profile
 switchport-mode trunk
 allowed-vlan all
 native-vlan 1
 shutdown
 access-rule-name default_wired_port_profile
 speed auto
 duplex full
 no poe
 type employee
 captive-portal disable
 no dot1x

wired-port-profile wired-instant
 switchport-mode access
 allowed-vlan all
 native-vlan 1
 no shutdown
 access-rule-name wired-instant
 speed auto
 duplex auto
 no poe
 type employee
 captive-portal disable
 no dot1x

 

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

The issue is - on Trunk Mode, I cannot connect the IAP... If I change Switch configs to as below the I can connect the IAP - but I need it to be trunk to service WLAN clients.

 

interface FastEthernet2/0/13

Switchport mode access

Switchport access vlan 8

Hi,

 

Please make sure that we don't have mgmt vlan configured on IAP.

 

 

 

Thanks,

Sree

confirmed no management vlan configured...the IAP takes 4minutes plus to boot from a Port configured as <Trunk Mode>... It boots mormally port Access Mode port.

 

Aruba TAC support are currently looking into the issue..

 

Thanks anyway....

Hello,

now 2015-10-07 this issue "no tagging of VLAN 1" seems to be still there.

 

I run untagged VLAN-14 for MGMT and boot - but have to publish tagged VLAN-1 as SSID => without success because "untagged" network is used instead by IAP-205.

 

So - however tagged VLAN-14 is not available in my network and because of this CLI with "enet-vlan 14" if no solution for me. I am running a couple of IAP-"205" with 6.4.2.6-4.1.1.8_50989.

 

Any ideas?

- new FW?

- new CLI for fixing that?

- OR - may I have to change the VLAN concept

 

if vlan 14 exists in your network you should be able to use it tagged, can you explain how it doesn't exist?

VLAN14 untagged supports als MGT Lan "autoconnect" of IAP without pre-configuring it using serial etc.

My question is no how to avoid this reqirement but just when will it be fullfilled by InstantOS.

johannes@goldy,

 

I apologize, but there does not seem to be a way to do this.  When an IAP boots up, it assumes that the untagged VLAN is both the management VLAN and VLAN1, similar to most network devices.

Accepted - but should be BOLD on PAGE1 of any flyer of manual

BR Johannes

How would you want that to be worded?  The controller product functions the same way, in that you need to first put it on an untagged VLAN to manage it, then you would configure a different VLAN for management.

Maybe:

"in default configuration IAP adresses VLAN1 always untagged, so no access to tagged VLAN1 is possible without reconfiguration not to use untagged VLAN access..."

 

Remember: "my stopper was not to be able to publish VLAN1 (tagged) which was different to my untagged (VLAN14)." ...

 ... most other vendors did not have that behave .... 
The solution in my case was not to fix or reconfigure IAP but to move the VLAN1 content to other VLAN11. Therefore no publishing issues occour. VLAN1 is now "emtpy" und my untagged VLAN ist still VLAN14 for MGMT.

 

BR Johannes

BR, standard practice for MOST (there are a handful of exceptions) large enterprise customers and all government customers (US DoD, etc, per STIG and government regulations) are to not use VLAN 1 at all. This thread is the first time in my professional life I have heard of someone wanting to tag VLAN 1 (with the exception of trunking all ports between two switches of course). 

 

Colin is correct, most all device that act as an addressable device will assume VLAN 1 as the untagged unless provisioned differently. That goes to access points and any other devices that require a native VLAN (including most switches that I can think of). I will engage the Instant PLM and TME offline in our meetings this week as to whether they feel this needs to be added to the user guide, but the use case is very rare indeed. 

 

Additionally, the current user guide (4.2) on page 91 calls this out specifically, and explains where to set uplink VLAN if it's different than the default (VLAN 1). 

 

Thanks!

Also, last question (honest question, just needing to understand why it's an issue for your network).

 

If the switch port that the IAP is pluged in to is tagged on all access VLANs and is untagged on VLAN 14 (mgmt), why does it matter that the IAP's untagged VLAN is 1? In a very real sense, every addressable (non-802.1q capable) client plugged in to a switch is technically configured for VLAN 1. Is it just the configuration that shows VLAN 1 untagged (which it doesn't really except on the CLI). Otherwise, no matter what VLAN the addressable device is configured (untagged), it *IS* addressable on VLAN14 by nature of the untagged port on the switch.

I believe this is a bug in the current IAP firmware I suggest you to contact TAC to confirm it. We ran into similiar issue and got the response that currently IAP does not support using a native vlan other than VLAN 1 on a trunk port of the uplink interface.

Hi, apparently this 'bug' still exists...I've send the below question to support, but I probably should have posted it here.

 

Here's the question:

 

I have an issue with a customer who has a 'flat' vlan 1 network.
All clients have a fixed IP in vlan 1.

There was one Instant cluster of about 50 IAP-135 access points, with the following SSID's:
- EMPLOYEES: Radius authentication, client vlan assignment: default vlan, client ip assignment: network assigned (fixed IP's)
- PUBLIC: portal authentication, client ip assignment: Virtual controller assigned (internal dhcp)
- SMARTPHONES: WPA2, client vlan assignment: static vlan 20, client ip assignment: network assigned (external dhcp)

As he wanted different SSID's on different sites I've split the cluster in several small clusters. I've done that by putting the AP's in a seperate native vlan.

This worked fine, for the PUBLIC and SMARTPHONES SSID's, but not for the EMPLOYEES SSID.
As the default (native) vlan wasn't 1 anymore I adjusted the EMPLOYEES SSID to 'client vlan assignment: static vlan 1' (tagged in vlan 1).

But this doesn't seem to work. Somehow it seems impossible to tag VLAN 1 on the SSID / VC.

As I wanted to put the VC controller management IP in VLAN 1 (as all other devices) I've specified this as such in the <system> tab on the VC. After that I completely lost connection with the virtual controller.
The access points of that particular cluster were still accessible via their IP in the native vlan of the cluster.

EX:
cluster 100:
IAP101: 192.168.100.1 / 24
IPA102: 192.168.100.2 / 24
untagged: vlan 100, tagged vlan 1, 20
Virtual Controller: 192.168.100.100 255.255.255.255 -> VC reachable
Virtual Controller: 192.168.1.100 255.255.255.0 vlan 1 ---> after this setting no longer reachable

cluster 200:
IAP101: 192.168.200.1 / 24
IPA102: 192.168.200.2 / 24
untagged: vlan 200, tagged vlan 1, 20

Hi, the VLAN bug still exist. I met it again with IAP-103 with AaubaOS 6.4.0.3-4.1.0.1. It will be fixed in later versions by Aruba??? Massimo

dear,

do the bug steal exist or not . have you contact the Aruba support or not.

 

Hi

 

I'm not sure if it's a 'bug' or by design, but is isn't possible to tag vlan 1.

 

As the customer didn't have a support contract, Aruba support couldn't help me.

 

Br

Peter