I just found a bunch of cool AirWave video how-to's on YouTube thanks to @nullinterface asking a question about Aruba's manageability.
http://bit.ly/gnaEiV
There are 12 videos in all - covering the following topics:
AirWave Integrate Seamlessly
AirWave Scale To Your Enviroment
AirWave Run Or Schedule Trend Reports
AirWave Pass Compliance Audits
AirWave Administrator Role Based Permissions
AirWave Detect Rogue Access Points
AirWave Enforce Device Configurations
AirWave Locate Every Wireless User
AirWave Monitor Devices In Realtime
AirWave Wireless Overview
Overview of Airwave 7
Wi-Fi Site Planning with VisualRF Plan 6.4
Wednesday, January 19, 2011
Monday, January 10, 2011
test aaa group
Maybe everyone else knows about this command - I'd forgotten about it and had to dig it out of an email thread this morning. I'm running through testing a bridge link setup where the root AP is the radius server for authenticating the non-root AP.
This command test aaa group allows you to do a sanity check on your root AP configuration so you don't spend all day troubleshooting the non-root AP configuration if that isn't the problem.
Now at least I know my problem *is* with my non-root AP configuration.
You'll also want to turn on 'debug radius' on the root AP so you can see all the RADIUS messages pertaining to the bridge link authentication attempts.
Keep in mind - 99.9% of the information I put on this site is for me so I can find it easier later! :-)
This command test aaa group allows you to do a sanity check on your root AP configuration so you don't spend all day troubleshooting the non-root AP configuration if that isn't the problem.
ROOT#test aaa group rad_eap admin admin new
Trying to authenticate with Servergroup rad_eap
User successfully authenticated
Now at least I know my problem *is* with my non-root AP configuration.
You'll also want to turn on 'debug radius' on the root AP so you can see all the RADIUS messages pertaining to the bridge link authentication attempts.
Keep in mind - 99.9% of the information I put on this site is for me so I can find it easier later! :-)
Monday, January 3, 2011
mls qos trust what?
I'm working through the IPexperts Lab2 for the CCIE Wireless - trying to reverse engineer the solutions to the questions and understand the subjects where I'm lacking. Namely QoS.
I was digging around trying to find the reason why the solution for section 2.8 bullet point number two was to use the command 'mls qos trust ip-precedence' for all the connections between the core switches. The bullet point asks you to ensure that the layer 3 QoS markings are trusted between the switches, and that you trust the 3 most significant bits of the DiffServ field in the IP packet.
I found this explanation for the difference between 'mls qos trust dscp' and 'mls qos trust ip-precedence'. DSCP is the most significant 6 bits of 8-bit service-type field, where IP-Precedence refers to the most significant 3 bits of 8-bit service-type field.
This picture shows this breakdown in a little better detail.
I was digging around trying to find the reason why the solution for section 2.8 bullet point number two was to use the command 'mls qos trust ip-precedence' for all the connections between the core switches. The bullet point asks you to ensure that the layer 3 QoS markings are trusted between the switches, and that you trust the 3 most significant bits of the DiffServ field in the IP packet.
I found this explanation for the difference between 'mls qos trust dscp' and 'mls qos trust ip-precedence'. DSCP is the most significant 6 bits of 8-bit service-type field, where IP-Precedence refers to the most significant 3 bits of 8-bit service-type field.
This picture shows this breakdown in a little better detail.
