Wireless Access

Hello,

I experienced the problem when I specified VLAN mobility, the client picks wrong DHCP scope.

Controller Aruba 3400  OS 5.0.4.6

Configuration

VLAN200 is configured in the 3400 controller only. VLAN200 does not have Interface.

VLAN200 has DHCP server enabled.

VirtualAP  V200 has Tunnel mode , WEP authentication and belongs to VLAN200. VLAN Mobility is enabled.

In 3400 controller, Inter-VLAN routing is enabled. so that VLAN200 can route to VLAN1.

VLAN1 is configured in the 3400 controller and has Interface 1/0. This Interface 1/0 is connected to

core switch.

In the Core switch, VLAN1 and VLAN250 is defined. VLAN1 and VLAN250 is routable in L3. (L3 switch)

There is DHCP scope for VLAN1 and VLAN250.

Remote AP is connected under VLAN250.

The problem is - when I connect Virtual AP V200, ip should be supplied by Aruba 3400 DHCP server,

but sometimes ip is supplied from VLAN1.

When I disabled VLAN Mobility option, this behavior does not occur again.

Thinking of how VLAN Mobility works, Aruba 3400 ask around other switches if MAC address is already in the mac-address-table and if it does, Aruba 3400 tries to find which VLAN it used to belong. Actually, this pc used to belong VLAN1 a week ago and IP address which was wrongly assigned seems to be the same IP address when the pc was in VLAN1.

In past, I experienced a scanner which never belonged to VLAN1, picked up VLAN1 DHCP scope IP address.

Reading the concept how VLAN Mobility works, my understanding is - VLAN Mobility should work if all AP connects to the same controller? In this case, two APs are connected under same VLAN250, and Tunnel mode VirtualAP V200 let the device being connected to VLAN200 within the controller. I believed that everything works fine within VLAN200 in the same Aruba 3400 controller, since it is Tunnel Mode! (Not a bridge Mode)

Remote AP1 - VLAN250 - Core Switch - VLAN1 - [Aruba 3400 VLAN1 - VLAN200]

Remote AP2 - VLAN250 - Core Switch - VLAN1 - [Aruba 3400 VLAN1 - VLAN200]

Does someone know why this behavior happens? I guess - as long as wrong mac-address-table exists in core switch, this behavior can happen. Therefore to make VLAN Mobility work ( to pick up right DHCP scope), we should shorten mac-address-table lifetime?

Or is there any misconfiguration that VLAN Mobility should not work?

I captured wireshark trace on the pc and found that DHCP server which is commonly used for all VLAN, sent DHCP Offer to this pc. At the matter of fact, this pc used to join in VLAN1, therefore DHCP server remembers the mac address and IP address which was assigned last time.

I assume - if we set VLAN Mobility on, Aruba controller tries to forward DHCP Request packet from controller-inside VLANs through VLAN1 which is connected to the other VLANs. Does anyone know if this behavior is working as expected?

Sorry for self replies ..

I set Debugging log level for DHCP and compared two cases.

If VLAN Mobility is enabled, DHCP Discover from a client (MAC XX:XX:XX:75:92:84) is shown from Datapath vlan1. But actually a client (MAC XX:XX:XX:75:92:84) tries to authenticate through inside-controller VLAN200.

May 16 16:52:45 dhcpdwrap[1435]: <202541> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x40 opcode 0x5a ingress 0x1089 vlan 1 egress 0x1 src mac XX:XX:XX:75:92:84
May 16 16:52:45 dhcpdwrap[1435]: <202534> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1: DISCOVER XX:XX:XX:75:92:84
May 16 16:52:45 dhcpdwrap[1435]: <202523> <DBUG> |dhcpdwrap| |dhcp| dhcprelay: dev=eth1, length=300, from_port=68, op=1, giaddr=0.0.0.0
May 16 16:52:45 dhcpdwrap[1435]: <202532> <DBUG> |dhcpdwrap| |dhcp| got 0 relay servers
May 16 16:52:45 dhcpdwrap[1435]: <202541> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x42 opcode 0x5a ingress 0x1040 vlan 1 egress 0x1 src mac XX:XX:XX:4e:1b:bc
May 16 16:52:45 dhcpdwrap[1435]: <202546> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1: OFFER XX:XX:XX:75:92:84 clientIP=172.200.1.74
May 16 16:52:45 dhcpdwrap[1435]: <202541> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x40 opcode 0x5a ingress 0x1089 vlan 1 egress 0x1 src mac XX:XX:XX:75:92:84
May 16 16:52:45 dhcpdwrap[1435]: <202536> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1: REQUEST XX:XX:XX:75:92:84 reqIP=172.200.1.74
May 16 16:52:45 dhcpdwrap[1435]: <202523> <DBUG> |dhcpdwrap| |dhcp| dhcprelay: dev=eth1, length=327, from_port=68, op=1, giaddr=0.0.0.0
May 16 16:52:45 dhcpdwrap[1435]: <202532> <DBUG> |dhcpdwrap| |dhcp| got 0 relay servers
May 16 16:52:45 dhcpdwrap[1435]: <202541> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x42 opcode 0x5a ingress 0x1040 vlan 1 egress 0x1 src mac XX:XX:XX:4e:1b:bc
May 16 16:52:45 dhcpdwrap[1435]: <202544> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1: ACK XX:XX:XX:75:92:84 clientIP=172.200.1.74

If the VLAN Mobility is disabled, DHCP Discover from a client (MAC XX:XX:XX:75:92:84) is shown from Datapath vlan200 which is correct.

May 16 16:59:59 dhcpdwrap[1435]: <202541> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x40 opcode 0x5a ingress 0x1089 vlan 200 egress 0xbb src mac XX:XX:XX:75:92:84
May 16 16:59:59 dhcpdwrap[1435]: <202534> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan200: DISCOVER XX:XX:XX:75:92:84
May 16 16:59:59 dhcpdwrap[1435]: <202523> <DBUG> |dhcpdwrap| |dhcp| dhcprelay: dev=eth1, length=300, from_port=68, op=1, giaddr=0.0.0.0
May 16 16:59:59 dhcpdwrap[1435]: <202532> <DBUG> |dhcpdwrap| |dhcp| got 0 relay servers
May 16 17:00:00 dhcpdwrap[1435]: <202541> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x42 opcode 0x5a ingress 0x0 vlan 200 egress 0x1089 src mac XX:XX:XX:6d:a6:98
May 16 17:00:00 dhcpdwrap[1435]: <202546> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan200: OFFER XX:XX:XX:75:92:84 clientIP=172.200.187.254
May 16 17:00:00 dhcpdwrap[1435]: <202541> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x40 opcode 0x5a ingress 0x1089 vlan 200 egress 0xbb src mac XX:XX:XX:75:92:84
May 16 17:00:00 dhcpdwrap[1435]: <202536> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan200: REQUEST XX:XX:XX:75:92:84 reqIP=172.200.187.254
May 16 17:00:00 dhcpdwrap[1435]: <202523> <DBUG> |dhcpdwrap| |dhcp| dhcprelay: dev=eth1, length=327, from_port=68, op=1, giaddr=0.0.0.0
May 16 17:00:00 dhcpdwrap[1435]: <202532> <DBUG> |dhcpdwrap| |dhcp| got 0 relay servers
May 16 17:00:00 dhcpdwrap[1435]: <202541> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x42 opcode 0x5a ingress 0x0 vlan 200 egress 0x1089 src mac XX:XX:XX:6d:a6:98
May 16 17:00:00 dhcpdwrap[1435]: <202544> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan200: ACK XX:XX:XX:75:92:84 clientIP=172.200.187.254

Therefore, I think this behavior is caused by VLAN Mobility setting.

What I need to implement is L2 roaming. I do not need "VLAN Mobility" since VLAN is always same - VLAN200.

But if I choose VLAN Mobility, this behavior occur.

To fix this behavior, purge DHCP cache may work.

Is there any setting not to forward DHCP Discover from VLAN1 to outside, or not to forward controller-inside VLAN200 to VLAN1?

My understanding is that VLAN-VLAN routing works only for layer3 (IP level) and should not relay any broadcast-type packets unless DHCP Relay is specified...

Vlan mobility is not relevant to your situation or in a single-controller environment.  It seems that you have Vlan 200 bridged and both the internal DHCP server on the controller and external DHCP server both answer to the client, is your problem.  You need to turn one off.

Clients receive ip addresses from the VLAN in the virtual AP.  If you put more than one VLAN in the virtual AP, clients will be load-balanced into both VLANs.

What are you trying to do?

Hi cjoseph,

What I am trying to do is - expect L2 roaming when the device moves from one AP to another.

In virtual ap configuration, just checking IP mobility makes L3 roaming,

and checking VLAN mobility makes L2 roaming.

I defined Tunnel mode WEP-authentication for handy scanner. VLAN200 is defined for this. Internal DHCP is defined for VLAN200 in Aruba3400 controller.

VLAN200 does not have interface in Aruba 3400.

Aruba 3400 has VLAN1, and this VLAN1 interface connects to DHCP server  and core switch (L3 switch, Cisco)

Core switch has VLAN1 and VLAN250 defined. All APs are connected under VLAN250.

I expect handy scanner to work as L2 roaming when moving one AP to another. In this case, VLAN200 is always used for roaming and roaming should be taken place within the controller. Therefore, VLAN mobility, such as moving scanner device from VLAN200 to VLAN1, is not nesessary here (I just want to implement L2 roaming ;)

Hi cjoseph,

One more thing. AP-105 is working as a RAP(Remote Access Point), not a Campus AP.

I am thinking if we can create a policy to block DHCP request (UDP 68) from VLAN200 towards VLAN1, we can stop this behavior.

By default, devices should be able to roam from one AP to another, when the Virtual AP mode is tunneled.  you should not have to do anything special for this to happen.

The controller just has to have an interface in VLAN 200.  You do not need two DHCP servers...?

Hi cjoseph,

I thought that there are choices - L3 roaming by choosing IP mobility, and L2 roaming by choosing VLAN mobiliy.

By default, if we choose IP mobility only, the roaming mode is L3 mobility I think.

To make L2 mobility happen, I have to choose VLAN mobility option - that is what I thought.

Today I will face 3200 with 5.0.4.6.and see if VLAN mobility option simply relay broadcast domain from origin VLAN to another .... I thought Aruba's design of VLAN mobility is not just simple ..

Here is what you do:

1.  Configure a controller with a Vlan for your users

2.  Assign that VLAN to  a port on the controller

3.  Configure a WLAN with the WLAN/LAN Wizard to put users on that VLAN

4.  Users on that WLAN can roam seamlessly to every access point that you deploy in that AP group.

5.  No need to change any mobility settings

The mobility settings on the controller are for multiple controller deployments.  They do not come into play here...

Hi cjoseph,

Today I created lab environment with two 3200s (OS 5.0.4.6) and tried to recreate the problem.

I created VLAN1 with Gi1/0 and connect to VLAN1 switch. DHCP server with scope VLAN1 is connected to VLAN1.

I created VLAN200, VirtualAP VLAN200 tunnel mode and DHCP server for VLAN200 within Aruba 3200 controller.

I set wireshark on monitor port of Catalyst 2960 and monitored Fa0/1 which is connected to Aruba 3200 Gi 1/0.

Result: DHCP Discover which was oridinally sent from laptop on VLAN200 was relayed to VLAN1, and DHCP server in
VLAN1 sent DHCP offer.

I have figured out why this behavior happened.

DHCP server determines the DHCP scope by Relay Agent IP address in DHCP Discover. In Wireshark trace, Relay Agent IP
address is 0.0.0.0, therefore DHCP server thought that DHCP Discover was sent from pc in VLAN1.

I think Aruba 3200 should respect Relay Agent IP address when VLAN Mobility option is set to enable.

Your solution - only one DHCP server in VLAN1 supplies DHCP scope for VLAN200 in Aruba 3200, does not work if "VLAN Mobility" option is enabled.

On the other hand, I set VLAN Mobility disable and check how roaming works.

When AP to AP roaming occur, I could observe following in wireshark trace.

19:17:45.928914 from 00:24:6c:XX;XX:XX to XX;XX:XX:75:92:84(Laptop's MAC) EAPOL Key
19:17:45.930011 from XX;XX:XX:75:92:84 to 00:24:6c:XX;XX:XX EAPOL Key
19:17:45.942686 from 00:24:6c:XX;XX:XX to XX;XX:XX:75:92:84 EAPOL Key
19:17:45.943000 from XX;XX:XX:75:92:84 to 00:24:6c:XX;XX:XX EAPOL Key
19:17:45.944030 from XX;XX:XX:75:92:84 to broadcast         who has 172.200.0.1(Gefault GW)? Tell 172.200.0.85
19:17:48.482681 from 00:1e:4a:XX:XX:XX to XX;XX:XX:75:92:84 172.200.0.1 is at 00:1e:4a:XX:XX:XX
19:17:48.482686 from 172.200.0.85      to 172.200.0.1       ICMP Echo(ping) request
19:17:48.486529 from 172.200.0.1       to 172.200.0.85      ICMP Echo(ping) reply
19:17:48.486653 from 172.200.0.85      to 172.200.0.1       ICMP Echo(ping) request
19:17:48.490468 from 172.200.0.1       to 172.200.0.85      ICMP Echo(ping) reply
 
This behavior looks like L3 mobility, and it takes 3 seconds for roaming to be completed.

Our customer needs non-disruptive roaming - this is why I am trying to implement L2 roaming.
In Aruba document,L2 roaming provides milliseconds disruptive time.

But - if I enable VLAN Mobility option, DHCP system does not work and VLAN Mobility spreads broadcast type of traffics
towards whole network. This behavior is not good.

Do you know how to implement L2 roaming only? (Not VLAN mobolity)
or do you know how to cut DHCP Discover broadcast from Aruba controller to VLAN1?

Hi cjoseph,

This morning, I captured wireshark trace when pc roams from one AP to another using VLAN Mobility option.

Result is - I can observe ARP between pc 172.20.0.85 (IP was assigned from VLAN1) and 172.200.0.1(Default gateway),

but absolutely no disruption. This is what out customer is looking for.

Therefore, the problem here is - why VLAN Mobility option forwards DHCP Discovery without "Relay Router IP" specified.

If it does, correct IP should be assigned by DHCP.(Or if there is no scope in DHCP in VLAN1, the DHCP discvery is simply ignored)

I am going to open the case with Aruba and ask them what is the expected behavior for VLAN Mobility option.

Hi cjoseph,

I opened the case and the conclusion is:

- In this scenario that only one VLAN200 with Tunnel mode, we do not need to choose VLAN Mobility for roaming.

We just need to select "Mobile IP" option for L3 roaming.

I think there are two problems:

P1) VLAN Mobility option forwards broadcasts from one VLAN to another, but they did not correctly handle "Relay Agent IP Address" in DHCP Discover packet, therefore wrong DHCP scope may be assigned to the wireless device.

Here is a good explanation - from Microsoft Technet:

http://technet.microsoft.com/en-us/library/cc940466.aspx

DHCPDiscover

The DHCP client sends the DHCPDiscover, containing the MAC address of the DHCP client, to the limited broadcast IP address (255.255.255.255) and the MAC-level broadcast address. The DHCP Relay Agent receives and processes the DHCPDiscover.

As established in RFC 1542, the DHCP Relay Agent can forward the packet to an IP broadcast, multicast, or unicast address. In practice, DHCP Relay Agents forward DHCPDiscover messages to unicast IP addresses which correspond to DHCP servers. Before forwarding the original DHCPDiscover message, the DHCP Relay Agent makes the following changes:

• If needed, updates the Relay IP Address field (also known as the Gateway IP Address field) in the DHCP header. When the DHCP client sends the DHCPDiscover message, the Relay IP Address field is set to 0.0.0.0. If the Relay IP Address is 0.0.0.0, the DHCP Relay Agent records the IP address of the interface on which the DHCPDiscover message was received. If the Relay IP Address is not 0.0.0.0, the DHCP Relay Agent does not modify it. The Relay IP Address field records the first router interface encountered by the DHCPDiscover message.

According to my test, ArubaOS 5.0.4.6 with 3200/3400 controller did not change "Relay Agent IP" field to the Interface IP Address (VLAN200 = 172.200.187.2) Therefore, ArubaOS 5.0.4.6 does not fully complies with RFC1542. If they already creates the fix in 6.0 or 6.1 code, they should create a fix for 5.0 code.

P2) VLAN Mobility and L2 roaming should be provided as independent functionalities.

Some user like me would like to implement L2 roaming only to expect fast roaming behavior.

According to my test, L2 roaming provided with VLAN Mobility showed faster roaming behavior than L3 roaming.

L3 roaming needed 3 seconds to switch from one AP to another, but L2 roaming I did not see any disruntion in Wireshark trace. (Wireshark trace provides .000000 under seconds and I did not see any noticable disruption in the event of AP to AP roaming. )

I want Aruba to provide L2 roaming under same VLAN option.

There is a option "Drop Broadcast and Multicast" but I am afraid if this "Drop Broadcast and Multicast" option stops ARP and DHCP working ...

Cjoseph, do you know what happens if "Drop Broadcast and Multicast" is selected? Any broadcast-dependent protocol such as ARP or DHCP would not work?

Also, which forum post should I use for "Future development request"?