0% found this document useful (0 votes)
42 views21 pages

IACA Lab 12.01

Uploaded by

James Zapata
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
42 views21 pages

IACA Lab 12.01

Uploaded by

James Zapata
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

Lab 12.

01 Service Survivability

Lab 12.01 Service Survivability


Check PreLab Module at the beginning of this Lab guide to
validate the proper start of class state of your table and learn
how to use and validate setup script to start with this Lab.
Overview
In this lab you will explore service survivability.

In the first task you will review how the tunneled WLAN can survive when the internet connection is
unavailable.

After verifying the AP to gateway tunnel, you will block access to the internet and reboot all devices.
This will demonstrate how the AP stores survivability information to establish tunnels to the gateways.

In the second task, you will review how the switches can be configured with cached re-authentication
and a critical role. In case access to the RADIUS server is lost, these features can ensure that clients
can stay connected to the network or connect to the network using a minimal service level.

Objectives
After completing this lab, you will be able to:
• Understand AP to gateway tunnel setup without an Internet connection.
• Understand switch cached reauthentication.
• Understand the switch critical role.

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
440
Lab 12.01 Service Survivability

Task 1: Tunnel WLAN Central Survivability


The tunnels between APs and gateways are orchestrated by the overlay tunnel orchestrator service
in Aruba Central. When Aruba Central is not reachable, the APs and GWs cannot reach the OTO
service.

For the tunnels that are provisioned by the OTO service, backup tunnel information and IPsec keys
are stored in the existing GW and AP systems. This can be used when Aruba Central could be
unreachable for the devices due to an Internet link failure, for example.

Note that this only works for existing tunnel WLANs on existing gateways and APs. New APs or new
tunnel WLAN configurations will work after the devices have established contact with Central’s OTO
service.

Objectives
• Review AP to gateway tunnel status.
• Verify AP to gateway tunnel setup without internet connection.

Steps

Verify Cluster and AP Operation


In the next steps you will review and verify that the gateway cluster is online, the APs are
successfully connected to the cluster, and the APs are providing WLAN services.

First, verify the gateways are online in the group cluster.


1. In Aruba Central, navigate to Context: Global> Navigation: Devices > Top
Gateways.
2. Click Clusters.
3. Verify there are 4 AP tunnels (AP1 to GW1/GW2 and AP2 to GW1/GW2).

NOTE: If the cluster would be missing a gateway, verify:


- Both GW1 and GW2 are assigned to the group campus-gw-main
- The group campus-gw-main gateway configuration is set to auto-group cluster.
- The group campus-gw-main gateway configuration auto_gwcluster is set to
automatic.

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
441
Lab 12.01 Service Survivability

Verify that the APs have all WLANs enabled.


4. In Aruba Central, navigate to Context: Groups / campus-wifi-ui > Navigation:
Devices> Top: Access Points > Config (gear icon).
5. Click Access Points.

6. Verify the WLANs column shows All SSIDs selected for both ap1 and ap2.
NOTE: If one of the APs does not have this option, use the pencil button to edit
the AP configuration and enable the WLANs.

Disable Internet Access


In the next steps, you will configure the rtr-core1 with an ACL to block access to the Internet. This
will simulate a cloud connection failure.
7. Use the MGMT PC to open an SSH connection to rtr-core1.
8. Create a new IP access-list that blocks the device access to Aruba Central.
• Your management subnets (10.1.1.0, 10.1.3.0 and 10.1.4.0) are all in the 10.1.0.0/21
block
• Allow access to your internal network (devices should still be able to reach ClearPass).
• Block any other access for 10.1.0.0/21.
• Allow all other traffic.

access-list ip no-inet
10 permit any 10.1.0.0/21 10.0.0.0/8
20 deny any 10.1.0.0/21 any
30 permit any any any
exit

rtr-core1(config)# access-list ip no-inet


rtr-core1(config-acl-ip)# 10 permit any 10.1.0.0/21 10.0.0.0/8
rtr-core1(config-acl-ip)# 20 deny any 10.1.0.0/21 any
rtr-core1(config-acl-ip)# 30 permit any any any
rtr-core1(config-acl-ip)# exit

NOTE: The hostname of the rtr-core1 may be slightly different in your lab
environment; it may include the pod and/or table number or the course title
(IACA). This can be ignored.

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
442
Lab 12.01 Service Survivability

9. Apply the IP ACL outbound on the port 1/1/9.


interface 1/1/9
apply access-list ip no-inet out
exit

rtr-core1(config)# interface 1/1/9


rtr-core1(config-if)# apply access-list ip no-inet out
rtr-core1(config-if)# exit

Reboot the Gateways and APs


To demonstrate that the survivability also works when the devices are rebooted while the cloud
connection is down, you will now reboot the gateways and the APs.
10. Use the MGMT PC to open an SSH connection to gw1 (10.1.3.21).
11. Attempt to ping pqm.arubanetworks.com.
ping pqm.arubanetworks.com

(gw1) *# ping pqm.arubanetworks.com

! - Success . - Failure D - Duplicate Response


Press 'q' to abort.
Sending 5, 92-byte ICMP Echos to 52.207.118.149, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

12. After about 1 minute, check the Aruba Central control-channel. It should show as
DOWN. Repeat the command until the connection status shows down.
show aruba-central details

(gw1) *#show aruba-central details

Aruba Central
-------------
Parameter Value
--------- -----
Aruba Central IP/URL device-uswest4.central.arubanetworks.com
Connection Status DOWN
Time of last disconnect Wed Dec 28 06:47:51 2022
SmartAmon MON Bootstrap Status Init
Number of times WS connected 2
Time of last connect Wed Dec 28 06:47:51 2022

13. Reboot the GW1 and confirm the reload.


reload

(gw1) *# reload
Do you really want to restart the system(y/n): y

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
443
Lab 12.01 Service Survivability

System will now restart!

14. Open an SSH connection to GW2.


15. Verify you cannot access the internet.
ping pqm.arubanetworks.com

(gw2) # ping pqm.arubanetworks.com

! - Success . - Failure D - Duplicate Response


Press 'q' to abort.
Sending 5, 92-byte ICMP Echos to 3.232.163.149, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

16. Reboot the GW2 and confirm the reload.


reload

Let’s reboot the APs now.


17. Use the lab dashboard to reboot the AP1 and AP2.

NOTE: If there is no power option in the lab dashboard, you can login on the console
of the AP using admin / Aruba123! and use the reload command.

ap1# reload
Do you really want to reset the system(y/n): y
Reloading

Post Reboot Verification


The APs will be the first to complete the reboot.
18. Use the lab dashboard to connect to the console of either ap1 or ap2 using admin /
Aruba123!
19. Review the AP Tunnel Agent (ATA) tunnel configuration. This shows that the AP is
still aware of the required tunnels and tunnel endpoints, even without the cloud
connection.
show ata current-cfg

ap1# show ata current-cfg

Current Central is Down


Microbranch AP is Disabled
Microbranch System IP is 0.0.0.0/::
[Current Configuration For cluster(auto_gwcluster_125_0)]
<Tunnel list>

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
444
Lab 12.01 Service Survivability

-----pub_ip=10.1.3.22, local_ip=10.1.3.22, vlan=1,3,31-32,34-35, mcast=0,


Tun_Type=GRE, peer_device_type=Gateway
key_exp=0, dstNatt=0, HBT_interval=3, HBT_Threshold=10
-----pub_ip=10.1.3.21, local_ip=10.1.3.21, vlan=1,3,31-32,34-35, mcast=0,
Tun_Type=GRE, peer_device_type=Gateway
key_exp=0, dstNatt=0, HBT_interval=3, HBT_Threshold=10
<SSID list for primary>
-----ssid=p28t13-psk, type=0
-----ssid=p28t13-employee, type=0
-----ssid=p28t13-guest-cppm, type=0

20. Review the active tunnel status.


show ata endpoint

ap1# show ata endpoint

ATA Endpoint Status


-------------------
UUID IP ADDR STATE TUN DEV TUN SPI(OUT/IN) LINK TAG VALID TIME(s) TUNNEL TYPE
GRE VLANs HBT(Jiff/Missed/Sent/Rcv) INNER IP UP TIME(s)
---- ------- ----- ------- --------------- -------- ------------- -----------
--------- ------------------------- -------- ----------
Total Endpoints Count: 0

• Question: Are the any tunnels currently active?

• Answer: No, the AP will first attempt to connect to Aruba Central.

21. Review the AP BSS-table.


show ap bss-table

ap1# show ap bss-table

Aruba AP BSS Table


------------------
bss ess port ip phy type ch/EIRP/max-EIRP
cur-cl ap name in-t(s) tot-t flags mu-mimo
--- --- ---- -- --- ---- ---------------- ---
--- ------- ------- ----- ----- -------
f4:2e:7f:7b:15:f0 p28t13-employee ?/? 0.0.0.0 a-VHT ap 100E/15.0/25.5 0
ap1 0 2m:5s W3r 1
f4:2e:7f:7b:15:e0 p28t13-employee ?/? 0.0.0.0 g-HT ap 11/7.0/23.0 0
ap1 0 2m:4s W3r 0

Channel followed by "*" indicates channel selected due to unsupported configured


channel.
"Spectrum" followed by "^" indicates Local Spectrum Override in effect.

Num APs:2
Num Associations:0

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
445
Lab 12.01 Service Survivability

Flags: K = 802.11K Enabled; W = 802.11W Enabled; r = 802.11r Enabled; 3 = WPA3


BSS; O = Enhanced-open BSS with transition mode; o = Enhanced-open transition mode
open BSS; M = WPA3-SAE mixed mode BSS; E = Enhanced-open BSS without transition mode;
m = Agile Multiband (MBO) BSS; c = MBO Cellular Data Capable BSS; I = Imminent VAP
Down; T = Individual TWT Enabled; t = Broadcast TWT Enabled; d = Deferred Delete
Pending; a = Airslice policy; A = Airslice app monitoring; D = VLAN Discovered;

• Question: What do you observe?

• Answer: The p#tx-employee SSID is enabled on the AP, the other WLANs are not
active.

• Question: What is the difference between the p#tx-employee WLAN and the other
WLANs?

• Answer: The p#tx-employee is a mixed mode WLAN. The other WLANs are tunnel
mode WLANs.
o By default, a mixed mode WLAN will remain active when the tunnel to the gateways
is down.
o By default, a tunnel WLAN will be disabled when the tunnel is down for more than 30
seconds.

22. The AP will keep trying to reach Aruba Central for several minutes. After about 6
minutes, the AP will start using the survivability information and connect to the
gateways. Repeat this command every minute until you see the survived tunnels.
show ata endpoint

Example output after the reboot. No tunnels have been established.


ap1# show ata endpoint

ATA Endpoint Status


-------------------
UUID IP ADDR STATE TUN DEV TUN SPI(OUT/IN) LINK TAG VALID TIME(s) TUNNEL TYPE
GRE VLANs HBT(Jiff/Missed/Sent/Rcv) INNER IP UP TIME(s)
---- ------- ----- ------- --------------- -------- ------------- -----------
--------- ------------------------- -------- ----------
Total Endpoints Count: 0

Example after 6 minutes, with the tunnels established in a survived state.


ap1# show ata endpoint

ATA Endpoint Status


-------------------
UUID IP ADDR STATE TUN DEV TUN
SPI(OUT/IN) LINK TAG VALID TIME(s) TUNNEL TYPE GRE VLANs
HBT(Jiff/Missed/Sent/Rcv) INNER IP UP TIME(s)
---- ------- ----- ------- --------
------- -------- ------------- ----------- --------- -------------------
------ -------- ----------

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
446
Lab 12.01 Service Survivability

9cdaa2df-2f0e-421f-be71-66794accd1af 10.1.3.22 SM_STATE_SURVIVED tun0


c1284200/11450700 inet 6725 GRE 1,3,31-32,34-35
944/0/484/473 10.1.4.50 2022-12-28 12:09:42
a4a37eba-4742-4a84-ae17-297722b21f40 10.1.3.21 SM_STATE_SURVIVED tun1
ba9d9600/b97dcc00 inet 6725 GRE 1,3,31-32,34-35
944/0/484/473 10.1.4.50 2022-12-28 12:09:42
Total Endpoints Count: 2

23. Open an SSH connection to GW1 and review the IPsec tunnels.
show crypto ipsec sa

(gw1) *# show crypto ipsec sa

IPSEC SA (V2) Active Session Information


-----------------------------------
Initiator IP Responder IP
SPI(IN/OUT) Flags Start Time Tunnel Type Inner IP
------------ ------------ -
--------------- ------ --------------- ------------ ----------
10.1.4.51 10.1.3.21
a2192400/805ed900 UT2 Dec 28 07:10:14 10.1.4.51
10.1.4.50 10.1.3.21
ba9d9600/b97dcc00 UT2 Dec 28 07:09:42 10.1.4.50
10.1.3.22 10.1.3.21
4b66b400/c5ff3000 T2 Dec 28 06:55:28 N/A -

Flags: T = Tunnel Mode; E = Transport Mode; U = UDP Encap


L = L2TP Tunnel; N = Nortel Client; C = Client; 2 = IKEv2
l = uplink load-balance; t = Tunnel Service; P = Reverse-Pinning Enabled

Total IPSEC SAs: 3

• Question: What are the IPsec connections in the list?

• Answer: 3 in total. 2 IPsec connections to the APs. They were initiated by the APs
based on their survivability information. There is 1 IPsec connection to the GW2 for the
cluster function. This connection was never orchestrated by the OTO and was always
using the certificate-based authentication.

24. Review the ISAKMP SA list.


show crypto isakmp sa

(gw1) *# show crypto isakmp sa

ISAKMP SA Active Session Information


------------------------------------
Initiator IP Responder IP Flags
Start Time Private IP Peer ID
------------ ------------ -----
---------- ---------- -------------

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
447
Lab 12.01 Service Survivability

10.1.3.22 10.1.3.21 r-v2-


c Dec 28 06:55:28 -
CN=CNJJKLB09H::20:4c:03:b1:d5:02 L=SW
10.1.4.50 10.1.3.21 r-v2-
c-C Dec 28 07:09:42 10.1.4.50
CN=CNJ2K2R0YR::20:4c:03:8c:27:42
10.1.4.51 10.1.3.21 r-v2-
c-C Dec 28 07:10:14 10.1.4.51
CN=CNHSK2R4KP::20:4c:03:5b:27:e2

Flags: i = Initiator; r = Responder


m = Main Mode; a = Agressive Mode; v2 = IKEv2
p = Pre-shared key; c = Certificate/RSA Signature; e = ECDSA Signature
x = XAuth Enabled; y = Mode-Config Enabled; E = EAP Enabled
3 = 3rd party AP; C = Campus AP; R = Microbranch AP; Ru = Custom Certificate
RAP; I = IAP
V = VIA; S = VIA over TCP; l = uplink load-balance; P = Reverse-Pinning
Enabled

Total ISAKMP SAs: 3

• Question: How many of these ISAKMP sessions did you have when the OTO service
was available?

• Answer: Only 1: the IPsec connection between the gateway cluster members. The IPsec
keys for the AP to Gateways connections were setup by the OTO.

• Question: What type of IPsec authentication is used between the AP and the GW?

• Answer: The flag c indicates a certificate-based authentication. The AP is using its


factory TPM certificate to authenticate to the GW. The GW only needs to have a list of
authorized AP MAC addresses to validate the AP certificate subject name.

25. On the AP console, review the BSS table.


show ap bss-table

ap1# show ap bss-table

Aruba AP BSS Table


------------------
bss ess port ip phy type
ch/EIRP/max-EIRP cur-cl ap name in-t(s) tot-t flags mu-mimo
--- --- ---- -- --- ---- ----
------------ ------ ------- ------- ----- ----- -------
f4:2e:7f:7b:15:f0 p28t13-employee ?/? 0.0.0.0 a-VHT ap
100E/15.0/25.5 0 20:4c:03:8c:27:42 0 18m:26s W3r 1
f4:2e:7f:7b:15:f1 p28t13-psk ?/? 10.1.4.50 a-VHT ap
100E/15.0/25.5 0 20:4c:03:8c:27:42 0 12m:46s r 1
f4:2e:7f:7b:15:f2 p28t13-guest-cppm ?/? 10.1.4.50 a-VHT ap
100E/15.0/25.5 0 20:4c:03:8c:27:42 0 12m:46s o 1
f4:2e:7f:7b:15:f3 _owetm_p28t13-guest-c311025731 ?/? 10.1.4.50 a-VHT ap
100E/15.0/25.5 0 20:4c:03:8c:27:42 0 12m:45s WO 1

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
448
Lab 12.01 Service Survivability

f4:2e:7f:7b:15:e0 p28t13-employee ?/? 0.0.0.0 g-HT ap


11/7.0/23.0 0 20:4c:03:8c:27:42 0 18m:26s W3r 0
f4:2e:7f:7b:15:e1 p28t13-psk ?/? 10.1.4.50 g-HT ap
11/7.0/23.0 0 20:4c:03:8c:27:42 0 12m:46s r 0
f4:2e:7f:7b:15:e2 p28t13-guest-cppm ?/? 10.1.4.50 g-HT ap
11/7.0/23.0 0 20:4c:03:8c:27:42 0 12m:45s o 0
f4:2e:7f:7b:15:e3 _owetm_p28t13-guest-c311025731 ?/? 10.1.4.50 g-HT ap
11/7.0/23.0 0 20:4c:03:8c:27:42 0 12m:45s WO 0

Channel followed by "*" indicates channel selected due to unsupported configured


channel.
"Spectrum" followed by "^" indicates Local Spectrum Override in effect.

Num APs:8
Num Associations:0

Flags: K = 802.11K Enabled; W = 802.11W Enabled; r = 802.11r Enabled; 3 = WPA3


BSS; O = Enhanced-open BSS with transition mode; o = Enhanced-open transition mode
open BSS; M = WPA3-SAE mixed mode BSS; E = Enhanced-open BSS without transition mode;
m = Agile Multiband (MBO) BSS; c = MBO Cellular Data Capable BSS; I = Imminent VAP
Down; T = Individual TWT Enabled; t = Broadcast TWT Enabled; d = Deferred Delete
Pending; a = Airslice policy; A = Airslice app monitoring; D = VLAN Discovered;

• Question: Do you have any active WLANs?

• Answer: Yes, the AP is broadcasting all the configured WLANs now, including the tunnel
WLANs.

Verify Connectivity Using a Wireless Client


26. Open a connection to PC1.
27. Open Network & Internet Settings.

28. Click Change Adapter Options.


29. Disable the Lab NIC.
30. Enable the WLAN NIC.
31. Make a connection to your p#tx-employee WLAN using the employee certificate
(EAP-TLS). Confirm the certificate message.

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
449
Lab 12.01 Service Survivability

32. Verify that you are successfully connected.

This concludes the WLAN cloud survivability activity.

Restore the Internet Connection


33. On rtr-core1, remove the ACL from port 1/1/9.
interface 1/1/9
no apply access-list ip no-inet out
exit

rtr-core1(config)# interface 1/1/9


rtr-core1(config-if)# no apply access-list ip no-inet out
rtr-core1(config-if)# exit

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
450
Lab 12.01 Service Survivability

Task 2: Wired Cached Re-Authentication and Critical Role


In this task you will enable cached re-authentication and the critical role on the edge switch.

Both are features that can assist when the RADIUS server is not reachable anymore.

When the RADIUS server is not reachable:


• With cached re-authentication, clients that are already authenticated and that need to perform
reauthentication, can be reauthenticated based on the existing connection. The administrator
can set the cache period.
• With the critical role, new clients, or existing clients that are outside of the cached re-
authentication period, can be allowed access to the network based on a dedicated role, known
as the critical role. By default, the network will be closed when the RADIUS server is
unreachable, with this option, the network can be open when the RADIUS server is
unreachable. This can be useful, for example, in industrial or medical environments.

Objectives
• Understand switch cached reauthentication.
• Understand switch critical role.
• Verify the operation of cached reauthentication and critical role.

Steps

Cached Re-Authentication
1. Use thee eMGMT PC to open an SSH connection to sw-edge2.
2. Disable Aruba Central support to allow local configuration changes.
aruba-central
disable
exit

sw-edge2(config)# aruba-central
sw-edge2(config-aruba-central)# disable
sw-edge2(config-aruba-central)# exit

NOTE: While you could make the configuration changes without disabling Aruba
Central, you should be aware that the configuration of Aruba Central will
overwrite the local configuration when the switch reboots or the Aruba Central
connection is reconnected. Since you just blocked and then unblocked Internet
access in the previous task, your initial configuration in this task could be lost
when the switch restores the connection to Aruba Central.

3. On sw-edge2, configure port 1/1/4 with cached re-authentication.


interface 1/1/4
aaa authentication port-access dot1x authenticator

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
451
Lab 12.01 Service Survivability

cached-reauth
cached-reauth-period 120
aaa authentication port-access mac-auth
cached-reauth
cached-reauth-period 120
exit
exit

sw-edge2(config)# interface 1/1/4


sw-edge2(config-if)# aaa authentication port-access dot1x authenticator
sw-edge2(config-if-dot1x-auth)# cached-reauth
sw-edge2(config-if-dot1x-auth)# cached-reauth-period 120
sw-edge2(config-if-dot1x-auth)#aaa authentication port-access mac-auth
sw-edge2(config-if-macauth)# cached-reauth
sw-edge2(config-if-macauth)# cached-reauth-period 120
sw-edge2(config-if-macauth)# exit
sw-edge2(config-if)# exit

NOTE: The cached re-authentication period starts after the first failed RADIUS
authentication. Within the cache period, any number of re-authentications can
be performed. Once the cache period expires, the next client re-authentication
will fail.

NOTE: In production environments, the cached period can be set much higher,
for example, up to 86,400 seconds (24 hours). This provides time to restore the
link or RADIUS service while the existing systems will remain connected. The
lab uses a short timer to show what happens when the cache expires.

4. For testing purposes, configure the contractor role with a re-authentication period of
60 seconds. First remove the role, this ensures the role does not have any settings
from previous lab activities.
no port-access role contractor

port-access role contractor


vlan access 21
reauth-period 60
exit

sw-edge2(config)# no port-access role contractor


sw-edge2(config)# port-access role contractor
sw-edge2(config-pa-role)# vlan access 21
sw-edge2(config-pa-role)# reauth-period 60
sw-edge2(config-pa-role)# exit

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
452
Lab 12.01 Service Survivability

NOTE: In production environments, the reauthentication time will depend on


your security policy. It will typically be several hours. The lab uses a short timer
to speed up the demonstration process.

Critical Role
5. Configure a new role named critical-role-pc. Assign VLAN 21.
port-access role critical-role-pc
vlan access 21
reauth-period 60
exit

sw-edge2(config)# port-access role critical-role-pc


sw-edge2(config-pa-role)# vlan access 21
sw-edge2(config-pa-role)# reauth-period 60
sw-edge2(config-pa-role)# exit

NOTE: You can use any name for this role name; this is just a lab example.

6. On port 1/1/4, configured the critical role. Each port can have its own critical role
configured.
interface 1/1/4
aaa authentication port-access critical-role critical-role-pc
exit

sw-edge2(config)# interface 1/1/4


sw-edge2(config-if)# aaa authentication port-access critical-role critical-role-pc
sw-edge2(config-if)# exit

RADIUS Tracking
In case the RADIUS server is unreachable, the cache re-authentication and critical roles will be
used to provide continuous or limited services for the clients.

When the RADIUS server is reachable again, the switch will not immediately be aware of this. By
using RADIUS tracking, the switch will perform tracking (by sending test authentication requests) to
the RADIUS server. This allows the switch to detect that the RADIUS server is reachable again and
clients can be re-authenticated.

7. Configured RADIUS tracking to be performed every minute (60 seconds). The


tracking must be enabled per RADIUS server. The mode dead-only indicates that the
tracking will only start when the RADIUS server was found unreachable during a
normal authentication event.
radius-server tracking interval 60
radius-server tracking user-name radius-track password plaintext Aruba123!

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
453
Lab 12.01 Service Survivability

radius-server host cppm.aruba-training.com tracking enable tracking-mode dead-only

NOTE: The configured tracking user does not have to exist on the RADIUS
server. Any RADIUS reply (accept or reject) will be considered by the switch as
a reachable RADIUS server. If you are concerned about the number of failed
authentications in the RADIUS log, you can configure a dedicated RADIUS
service to handle the RADIUS tracking requests.

sw-edge2(config)# radius-server tracking interval 60


sw-edge2(config)# radius-server tracking user-name radius-track password plaintext
Aruba123!
sw-edge2(config)# radius-server host cppm.aruba-training.com tracking enable
tracking-mode dead-only

8. Verify the current RADIUS server status.


show radius-server detail

sw-edge2(config)# show radius-server detail


******* Global RADIUS Configuration *******

Shared-Secret: None
Timeout: 5
Auth-Type: pap
Retries: 1
TLS Timeout: 5
Tracking Time Interval (seconds): 60
Tracking Retries: 1
Tracking User-name: radius-track
Tracking Password:
AQBapenDkJR2yAvSlHReiujyK8CvCB8fZZW27nKBejxBznV2CQAAAOmIWOPdfKBWsw==
Number of Servers: 1
AAA Server Status Trap: Disabled

****** RADIUS Server Information ******


Server-Name : cppm.aruba-training.com
Auth-Port : 1812
Accounting-Port : 1813
VRF : default
TLS Enabled : No
Shared-Secret :
AQBapTjm3+3uP95qPMMZpf1TiDVJvWcfeLM9kDVHcMSsavmoCQAAAI93dwaxRjUaVw==
Timeout : 5
Retries : 1
Auth-Type : pap
Server-Group : pa
Group-Priority : 1
ClearPass-Username :
ClearPass-Password : None
Tracking : enabled
Tracking-Mode : dead-only
Reachability-Status : reachable, Since Wed Dec 28 12:53:57 UTC 2022

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
454
Lab 12.01 Service Survivability

Tracking-Last-Attempted : Wed Dec 28 12:53:53 UTC 2022


Next-Tracking-Request : 53 seconds

Verify the Operation When the RADIUS Server is Unreachable


9. On PC4, verify the WLAN NIC is disabled and the LAB NIC (wired) is authenticated
with 802.1X using the contractor certificate.
10. Open Network & Internet Settings.

11. Click Change Adapter Options.


12. Right-click the Lab NIC and click Properties.
13. Click Authentication.
NOTE: If the Authentication tab is not visible, make sure the Windows service
Wired AutoConfig is running.

14. Set Network authentication method to Microsoft: Smart Card or other


certificate.
15. Click Settings.
16. Uncheck the option Verify the server’s identity.
NOTE: In a production environment it is recommended to have this option
enabled.

17. Click OK.


18. Click Additional Settings.
19. Set Specify authentication mode to Computer authentication.
20. Click OK to close the Additional settings.
21. Click OK to close the NIC properties, the PC4 will now attempt to authenticate.

Verify the client authentication.


22. On sw-edge2, verify PC4 is authenticated as contractor on port 1/1/4.
show port-access clients interface 1/1/4

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
455
Lab 12.01 Service Survivability

sw-edge2(config)# show port-access clients interface 1/1/4

Port Access Clients

Status Codes: d device-mode, c client-mode, m multi-domain

-------------------------------------------------------------------------------------
-------------------
Port MAC-Address Onboarding Status Role
Device Type
Method
-------------------------------------------------------------------------------------
-------------------
c 1/1/4 00:50:56:b1:b9:0d dot1x Success contractor
c 1/1/4 ec:b1:d7:1b:07:00 In-Progress

23. Use MGMT PC to connect to ClearPass using admin / Aruba123!


https://10.254.1.23/tips

24. Navigate to Monitoring > Live Monitoring > Access Tracker.


25. Check the Access Tracker list. Every minute you should see an authentication event
for the PC4 contractor user. This is based on the reauthentication timer that was set
in the user role contractor.
NOTE: Just wait a minute watching this screen. The access tracker will auto-
refresh every 10 seconds by default.

26. On sw-edge2, review the port access client details on interface 1/1/4.
show port-access clients interface 1/1/4 detail

...
Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 47s ago
mac-auth - Attempted, 47s ago
dot1x - Authenticated, 108s ago
mac-auth - Attempted, 108s ago
dot1x - Authenticated, 169s ago
...

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
456
Lab 12.01 Service Survivability

NOTE: The output may contain 2 MAC addresses. Make sure to look for the
host/contractor (PC4) Authentication details section in the output.

• Question: What is the current authentication status?

• Answer: dot1x authenticated.

• Question: What is the interval for the 802.1X events in the Auth History?

• Answer: 60 seconds (1 min).

Configure a RADIUS Block ACL on rtr-core1


In the next steps you will activate an ACL on the rtr-core1 that blocks traffic to 10.254.1.23, the IP
address of the ClearPass RADIUS server in the lab.
27. Use the MGMT PC to open an SSH connection to rtr-core1.
28. On rtr-core1, create a new ACL that blocks access from the device management
subnets to 10.254.1.23. Permit all other traffic.
access-list ip no-radius
10 deny any 10.1.0.0/21 10.254.1.23
20 permit any any any
exit

rtr-core1(config)# access-list ip no-radius


rtr-core1(config-acl-ip)# 10 deny any 10.1.0.0/21 10.254.1.23
rtr-core1(config-acl-ip)# 20 permit any any any
rtr-core1(config-acl-ip)# exit

29. Activate the ACL on the port 1/1/9 in the outbound direction.
interface 1/1/9
apply access-list ip no-radius out
exit

rtr-core1(config)# interface 1/1/9


rtr-core1(config-if)# apply access-list ip no-radius out
rtr-core1(config-if)# exit

Monitor Status on sw-edge2


After a maximum of one minute, PC4 will be re-authenticated. This attempt will fail.

This failed attempt will start the cached reauthentication timer and initiate the RADIUS tracking
function.

30. Review the port access interface 1/1/4 authentication details. You can filter on the
text Auth to get a filtered output.

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
457
Lab 12.01 Service Survivability

show port-access clients interface 1/1/4 detail | include Auth

NOTE: The filtered output may include duplicate lines due to the 2 MAC
addresses on the port. You only need to focus on the dot1x lines for the PC4.

These are some states you may observe.

Every 60 seconds, the client will be re-authenticated, during this re-authentication you may see:
Auth Precedence : dot1x - Re-Authenticating, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 64s ago

When the server cannot be reached, the cached re-authentication timer starts, and the client will be
re-authenticated based on the cache:
Auth Precedence : dot1x - Cached-Re-Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 72s ago

Finally, when the cache expires, the status will be:


Status : Authentication Failed, Server-Timeout
Auth Precedence : dot1x - Unauthenticated, mac-auth - Not attempted
Auth History : dot1x - Unauthenticated, Server-Timeout, 46s ago
dot1x - Authenticated, 274s ago

NOTE: You may also notice a status of Authentication Failed, Supplicant-


Timeout. This is the Windows supplicant that goes into a quiet mode when
authentication could not complete for several times. The Windows systems in
the lab have been configured with a short quiet timer of 1 minute, therefore this
state should disappear after 1 minute.

31. Review the port-access clients again. The PC is now assigned the critical role.
show port-access clients interface 1/1/4

sw-edge2(config)# show port-access clients interface 1/1/4

Port Access Clients

Status Codes: d device-mode, c client-mode, m multi-domain

-------------------------------------------------------------------------------------
-------------------
Port MAC-Address Onboarding Status Role
Device Type
Method
-------------------------------------------------------------------------------------
-------------------
c 1/1/4 00:50:56:b1:b9:0d Success critical-role-pc, Critical
c 1/1/4 ec:b1:d7:1b:07:00 In-Progress

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
458
Lab 12.01 Service Survivability

...

32. Review the RADIUS tracking status


show radius-server detail

sw-edge2(config)# show radius-server detail

...
Tracking : enabled
Tracking-Mode : dead-only
Reachability-Status : unreachable, Since Wed Dec 28 13:36:20 UTC 2022
Tracking-Last-Attempted : Wed Dec 28 13:38:35 UTC 2022
Next-Tracking-Request : 49 seconds

Restore the RADIUS Connection


Now you can restore the connection to the RADIUS server.
33. On rtr-core1, remove the ACL from the port 1/1/9.
no apply access-list ip no-radius out

rtr-core1(config-if)# no apply access-list ip no-radius out

34. Within about 1- 2 minutes, the RADIUS tracking will detect that the RADIUS server is
reachable again. The client will be authenticated against the RADIUS server. Repeat
this command every minute until you see PC4 is authenticated as contractor again.
show port-access clients interface 1/1/4

sw-edge2(config)# show port-access clients interface 1/1/4

Port Access Clients

Status Codes: d device-mode, c client-mode, m multi-domain

-------------------------------------------------------------------------------------
-------------------
Port MAC-Address Onboarding Status Role
Device Type
Method
-------------------------------------------------------------------------------------
-------------------
c 1/1/4 00:50:56:b1:b9:0d dot1x Success contractor
c 1/1/4 ec:b1:d7:1b:07:00 Fail

35. Use the MGMT PC to review the latest ClearPass Access Tracker authentication
events.

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
459
Lab 12.01 Service Survivability

• Question: Why is there a radius-track authentication request?

• Answer: This is default username for the RADIUS tracking feature performed by the
switch.

• Question: You configured the RADIUS track with an interval of 60 seconds. Why is the
RADIUS track only shown once in the list?

• Answer: You are looking at the RADIUS server logs now. After the ACL blocked access
to the RADIUS server, the switch started to track the RADIUS server. These requests
were generated every 60 seconds, but they never reached the RADIUS server due to the
ACL.

After the ACL was removed, the next tracking request will mark the RADIUS server as
reachable again. Therefore, no more tracking requests need to be sent, since the
tracking is configured as dead-only.

You have completed this Lab!

Rev 23.11 | © Copyright 2022 Hewlett Packard Enterprise Development LP | Confidential – For Training Purposes Only
460

You might also like