Wireless Access

Hi!

 

I´m doing a fresh installation of ArubaOS 8.3.0.0

I´ve setup a MM and a MC in vmware eviroment. 

A couple of vlans and one trunk port per device.

 

The problem is if I connect clients to a SSID with a vlan set, either by clearpass or just static for that SSID, the client doesn´t recieve a ip adress. I can set dhcp on my MC on the same vlan and the MC will recieve an address from dhcp-server. So communication between MC and the rest of the network seems to work fine on that vlan.

 

I have tried setting a static adress on my client. If I do this the client can ping the MC but not reach anything beyond the MC. So the MC can ping stuff on this vlan no matter what but the client can never go any futher than connection with the MC.

 

Very strange. 

 

This is the MCs interface:

 

interface gigabitethernet 0/0/0
description "GE0/0/0"
trusted
trusted vlan 1-4094
no poe
switchport mode trunk
no spanning-tree

 

Some logs when connecting a client:

Jun 11 11:26:52 dhcpdwrap[5686]: <202532> <5686> <DBUG> |dhcpdwrap| |dhcp| got 0 relay servers
Jun 11 11:26:52 dhcpdwrap[5686]: <202534> <5686> <DBUG> |dhcpdwrap| |dhcp| Datapath vlan194: DISCOVER 30:07:4d:08:01:37 Transaction ID:0x707b7620 Options 3d:0130074d080137 39:05dc 3c:616e64726f69642d646863702d382e302e30 0c:44616e69656c732d47616c6178792d5338 37:0103060f1a1c333a3b2b
Jun 11 11:26:52 dhcpdwrap[5686]: <202541> <5686> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datapath, Flags 0x100040, Opcode 0x5a, Vlan 194, Ingress tunnel 21, Egress vlan 194, SMAC 30:07:4d:08:01:37
Jun 11 11:26:52 dhcpdwrap[5686]: <202541> <5686> <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datapath, Flags 0x42, Opcode 0x5a, Vlan 194, Ingress 0/0/0, Egress vlan 194, SMAC 30:07:4d:08:01:37

Is there a DHCP server on VLAN 194? It does not appear that the VMC is aware of an IP helpers (no DHCP relays defined on the VMC), so the DHCP server either needs to be on the same VLAN, or the default gateway needs to relay the DHCP Discovers.

 

First of all, do you really need 8.3.0.0? Only reason is support for newer AP’s like 345,303,318. Otherwise stick to 8.2.1.0.

Which role does the client get? Is the FW policy correct?

I will doublecheck the firewall settings but I did apply allow all to that role.

EDIT: I've now doublechecked and the user only has the defaults + allow all ie.

global-sacl  (0 rules)

apprf-userrolename (0 rules)

allowall (2 rules)

 

Do you know if i can downgrade from 8.3 or do I have to do a new install ?

 

Regarding dhcp the gateway is a firewall, not the controller and the controller does recieve dhcp lease on the same vlan so that is not the issue.

---

@Gonz wrote:

I will doublecheck the firewall settings but I did apply allow all to that role.

 

Do you know if i can downgrade from 8.3 or do I have to do a new install ?

 

Regarding dhcp the gateway is a firewall, not the controller and the controller does recieve dhcp lease on the same vlan so that is not the issue.

---

Can you verify on the firewall if it is receiving the client's DHCP discover?

 

 

What version was the controller running before going to 8.3?

I've doublechecked and the role is only getting the defaults + allowall.

ie.

global-sacl (0 rules)

apprf-userrolename (0 rules)

allowall (2 rules)

 

Well no the firewall wont communicate with the client even if i set a static ip as described above. But it will communicate with the controller on the same vlan.

 

It's a new installation so I started with 8.3.0 , can I still go down to 8.2 ?

Did you trust the vlan’s on the trunk port?

yup:

 

interface gigabitethernet 0/0/0
description "GE0/0/0"
trusted
trusted vlan 1-4094
no poe
switchport mode trunk
no spanning-tree

Hi Daniel,

Are the Vlan’s on that port? Missing some config?

Well, no thats the only port for that controller and if I set a ip-adress on the clients VLAN I can verify L2 connectivity no problem.

If I set a static ip adress on the client in the client vlan it can ping the controller but not beyond.

The controller can ping the client and it's defualt gw on the outside network no problem.

So the client seems to get stuck "on the other side" of the controller and cant access anything beyond, eventough the controller can communicate successfully on the very same VLAN.

Please send me the complete port config.

It still looks like a trust or fw issue

I am missing the following on the port

Switchport trunk permit vlan x,y,z.

Is your controller ip on vlan 1?

X,y,z being your vlan’s

What is the port config of the switch where the controller is connected to?

It's allowed vlan all in the controller and it's setup with a virtual vmware switch "all vlans". But since I can set a ip on the controller itself it and that works fine the vlan tagging itself seems to work.

 

Maybe it's some weird vmware setting ? I'm not very vmware savvy.

Hi,

 

So in the MC config you have on the interface also the command:

 

switchport trunk allowed vlan x,y,z?

 

 

Yes, switchport trunk allow vlan all

This sounds like the same issue I had with a new install of 8.3 on a vSphere cluster.  We finally determined that it will not work correctly unless the vSwitch or dvSwitch is set to load balance by IP hash. None of the other methods work.  You meed to have full LACP (not passive) LAG trunks anywhere there are multiple interfaces between the VM and the core.  So, our host with 2 vNICs needed full LACP LAG trunks to VirtualConnect and VirtualConnect needed full LACP LAG trunks to our core.

Hi!

 

Just installed 2 new Virtual Controllers with 8.2.1 insead. Same issue now... Your issue with vswitch settings does sound similar.

Did you follow the vmware install part of the VMC's for 100%?

 

Are you using vrrp between the VMC's?

It sounds exactly the same.  With ours, the client could not get a DHCP address.  If you set one manually, you could ping whichever controller it was associated to, but not the other one in the cluster and not the gateway.

 

We have an HPE Synergy server cluster and the firmware version it was on did not support full LACP and "load balance based on IP hash" for the vSwitch.  We had to upgrade the server cluster firmware and setup LACP everywhere so we could turn on the IP hash load balancing setup in vSphere.

 

In our testing, it would also work fine if we assigned it to a vSwitch with only one vNIC.  If we added a "standby" adapter to the vSwitch, we would start seeing the same behavior.

 

Support said it had to do with the VMC seeing the packets coming back in from the LAN and so it would start dropping the packets intended for the wireless client since it thinks that MAC is on the LAN versus on the wireless tunnel to the AP.

Checked with TAC and they more or less confirmed this. 

Thanks for the input, will mark your last post as answer when/if we get around to implementing this.