Wireless Access

Hey all, 

I only noticed this when my SSID with RADIUS auth stopped working (seemingly without reason). I then tried to run diagnostics to the AAA server (radius server) and the request timed out. I then realized that I couldn't ping the server that radius was on.

From the radius server I could ping the aruba controller without issue (both are on the same vlan). 

From a machine outside of that vlan, I can ping radius server and aruba controller no problem. Would this narrow down the issue to being some sort of config issue on the controller itself? 

Any insight would be appreciated. (Highly)

Is the controller connected with a port-channel?

Could you check if the RADIUS server, for some reason, is in the user-table? Via CLI: "show user-table | include <IP>"

As an extension to those two good tips...

Do a "show arp" in the controller CLI when you have just tried to ping the server from it. What does the mac look like? Does it look as you'd expect? Based on the server?

I've seen this in the past due to some, let's call it "interesting" Microsoft load balancing server mechanisms.

After pinging the Radius server, show arp shows the proper MAC for that server.

That's strange.

Ok. So, the controller can ping anything else in the same VLAN I assume? Like default gateways etc?

I think we need to see the port configuration that applies to the controller. I.e. the configuration of the controller port that attaches to the VLAN we're discussing.

Can you post this please?

Controller is configured on VLAN 1, VLAN 1 is configured on port 0, and 1.

Port 0 Config: (Reserved for just controller VLAN)

Port Trusted: Yes

Port Speed: Auto

Port Duplex: auto

Port Monitoring: *Not Configured*

Port Mode: Access

VLAN ID: 1

Trusted: Yes

Spanning Tree Point-To-Point: Yes

LACP Mode: Active.

Port 1: (Vlan1 included)

Port 1: (Multiple Vlans)

Port mode: Trunk
(All other settings same)

If I have understood what you're saying correctly...

1. You have ports 0 & 1 connected from the controller to the switch.

2. Port 0 connects like an "access" port on vlan 1 (i.e. untagged).

3. Port 1 connects like a "trunk" port (i.e. other tagged vlans), AND you've left vlan 1 untagged on this port also.

4. The controller IP is on VLAN 1.

If this is all true, it probably explains why you're seeing the issue you describe. I would have expected in this scenario one of the two ports to block via STP. Can you check the STP status on your controller and switch to which it attaches?

Regardless, your setup isn't ideal. I suspect your traffic is lost due to switch-controller interaction in terms of the STP, source-mac learning or something similar.

I would recommend you either need to:

1. Use a port-channel/ether-channel between the controller and switch, using multiple ports carry the same set of VLAN traffic (including VLAN 1).

2. Take VLAN 1 off the trunk port (i.e. port 1) with a VLAN allowed list. Note that you should check your STP status first!

For a simple test to prove my theory (assuming vlan 1 untagged is allowed on your controller port 1, and the switch port to which it attaches), just unplug your controller port 0. It should work fine like that.

UPDATE: STP is not enabled on either port. 

With this being said, would option 2 still be a viable solution? (According to your theory)

I'd recommend you do my final suggestion first to prove the point. I.e. uplug port 0. You'll get breif service impact. If that works, you can reattach and do option 2 moving forward, but I don't see huge value in it as a design model. Option 1 is preffered.

Thanks for the response.

The controller is connected with port, not a port-channel.

The Radius server IP does not show up when I run: show user-table | include <IP of Radius Server>

JD