Aruba Mobility master 8.x node hierarchy – with AAA (Radius/TACACS) config

reference – Aruba OS 8.x user guide

It is absolutely important to understand the node hierarchy and how configurations are pushed from the top down. Misunderstanding how the configurations are inherited will cause major issues if configurations are implemented at the wrong level. Run the “show configuration effective detail” command to see where the config “came from:

The following commands were implemented at the /mm level of the primary mobility master:

aaa authentication-server radius “ISE_10.0.0.35_RA”
host “10.0.0.35”
key “aruba123”
!
aaa authentication-server radius “ISE_10.0.0.36_RA”
host “10.0.0.36”
key “aruba123”
!

aaa authentication-server radius “ISE_10.0.0.35_TA”
host “10.0.0.35”
key “aruba123”
!
aaa authentication-server radius “ISE_10.0.0.36_TA”
host “10.0.0.36”
key “aruba123”
!

Add tacacs/Radius server GROUP

!

aaa server-group “AAA_ISE_SG_RA”
auth-server ISE_10.0.0.35_RA position 1
auth-server ISE_10.0.0.36_RA position 2
!

aaa server-group “AAA_ISE_SG_TA”
auth-server ISE_10.0.0.35_TA position 1
auth-server ISE_10.0.0.36_TA position 2
!

I am attempting to remove ALL of the radius servers from vMM0001 but i received the following message:

Again! it is very important to understand where you are making configuration changes. In order to delete the configs it must be done at the mm level ( in this case):


In this case i want to make sure that both the primary and secondary mobility masters have the same Radius and TACACS servers so i will make the change at the mm level

Currently vMM0002 does not have any AAA servers defined. Once the configuration is applied to vMM0001 it will be synchronized with vMM0002

Configurations will be made on the GUI and I will take a look at the CLI of the primary mobility master before I apply the change.

With master redundancy in place along with database sync, vMM0002 received the AAA configuration:

As outlined earlier, configs are pushed from top down but config from the mm level were NOT pushed down to the managed device level.

The configuration can be pushed from the md level if you want the config to propagate downstream or it can be configured at a lower level example – if the radius servers should only be pushed to a particular set of devices.

Apply AAA config at the /md level – CLI

run show configuration effective detail 7200phywlc0001 to see where the config was inherited from:

the next blog post will document adding the controller to the AAA server 10.0.0.35, defining an authentication policy and creating a “basic” WPA3 802.1X WLAN.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.