02-07-2014 05:37 AM
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)
02-07-2014 11:54 AM
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>"
ACMX#255 | ACMP | ACCP | AWMP
02-08-2014 02:06 AM
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.
02-10-2014 09:50 AM
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>
02-10-2014 10:00 AM
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?
02-10-2014 10:28 AM
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
Spanning Tree Point-To-Point: Yes
LACP Mode: Active.
Port 1: (Vlan1 included)
Port 1: (Multiple Vlans)
Port mode: Trunk
(All other settings same)
02-10-2014 11:52 PM - edited 02-10-2014 11:53 PM
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.
02-12-2014 01:21 AM
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.