Implementing AOS-CX

Switching

LAB GUIDE
Version: 24.31

Switching Series
© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice.
The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accom-
panying such products and services. Nothing herein should be construed as constituting an additional warranty.

Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.

Open Source Code

This product includes code licensed under the GNU General Public License, the GNU Lesser General Public License, and/or certain other
open source licenses. A complete machine-readable copy of the source code corresponding to such code is available upon request. This
offer is valid to anyone in receipt of this information and shall expire three years following the date of the final distribution of this
product version by Hewlett Packard Enterprise Company. To obtain such source code, send a check or money order in the amount of US
$10.00 to:

Hewlett Packard Enterprise Company

1701 E Mossy Oaks Rd
Spring, TX 77389
USA

Notices
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and
services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be con-
strued as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions
contained herein.

Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or copying. Consistent with
FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items
are licensed to the U.S. Government under vendor's standard commercial license.

Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard Enterprise has no control over
and is not responsible for information outside the Hewlett Packard Enterprise website.

Acknowledgments
All third-party marks are property of their respective owners.
Contents

Contents

Contents 3
Lab 1: Base configuration - initial lab setup 9
Task 1-1: Factory reset of devices (optional) 9
Task 1-2: Configure the OOBM interface on Access-1 11
Task 1-3: Configure the OOBM for Access-2, Core-1, and Core-2 13
Lab 2: Configuring HPE Aruba Networking Virtual Switching
eXtension (VSX) 17
Task 2-1: Verify the lab starting configuration 18
Task 2-2: Preparing for VSX 19
Task 2-3: VSX basic setup 22
Task 2-4: VSX configuration synchronization 30
Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG) 37
Task 2-6: VSX Layer 3 active gateway 50
Task 2-7: VSX failover test (optional) 58
Task 2-8: VSX split-brain handling 67
Task 2-9: Finalize the configuration for the upcoming labs 74
Lab 3: Layer 2 optimization and protection features 81
Overview 81
Task 3-1: Verify the lab starting configuration 82
Task 3-2: Examine the LAG load sharing process 82
Task 3-3: Using the LACP fallback feature 91
Task 3-4: Configure an MSTP solution 99
Task 3-5: Understanding edge ports and their operation with spanning tree 105
Task 3-6: Implement BPDU guard 107
Task 3-7: Implement root guard 112
Task 3-8: Implement loop protection 117
Task 3-9: Implement PVLANs (optional) 123

Contents 3
 Lab 4.1: OSPF single area—basic OSPF configuration 135
Overview 135
Task 4.1-1: Verify lab starting configuration 136
Task 4.1-2: Basic OSPF setup for the core (area 0) 136
Task 4.1-3: OSPF address advertisements and control 147
Task 4.1-4: OSPF peering using a VSX LAG 152
Lab 4.2: OSPF and multiple areas 157
Overview 157
Task 4.2-1: Assign Access-1 to OSPF area 1 158
Task 4.2-2: Assign Access-2 to OSPF Area 2 167
Task 4.2-3: Route summarization 174
Task 4.2-4: Verify route propagation impact with summarization 181
Task 4.2-5: ABR route filtering 184
Lab 4.3: Managing OSPF external routes 187
Overview 187
Task 4.3-1: Configure the link to Router-A 188
Task 4.3-2: Redistribute static routes into OSPF 189
Task 4.3-3: Control route redistribution and metric types 195
Task 4.3-4: Filter routes with stub and totally stub areas 200
Task 4.3-5: Filter routes with an NSSA 208
Task 4.3-6: Save configuration checkpoints for the upcoming labs 214
Lab 5: Basic BGP peering 217
Overview 217
Task 5-1: Prepare the lab setup 218
Task 5-2: Core-1 eBGP peering to ISP1 218
Task 5-3: Core-1 and Core-2 iBGP peering 225
Task 5-4: Core-2 eBGP peering to ISP2 230
Task 5-5: Announce routes to eBGP peers 236
Lab 6: Additional Layer 3 features 241
Overview 241
Task 6-1: Prepare the lab starting configuration 242

4 Contents
 Contents
Task 6-2: Add a new routing VRF 243
Task 6-3: OSPF routing inside a VRF 255
Task 6-4: Implementing DHCP snooping 259
Task 6-5: Implementing Dynamic ARP Inspection 267
Lab 7: IGMP and IGMP snooping 273
Overview 273
Task 7-1: Prepare the lab starting configuration 274
Task 7-2: Set up the multicast sender and receiver 277
Task 7-3: Enable IGMP querier and snooping 280
Task 7-4: Verify the IGMP snooping operation 285
Task 7-5: Verify IGMP snooping fast leave (optional) 291
Lab 8: Multicast routing with PIM sparse mode 295
Overview 295
Task 8-1: Prepare and review the lab setup 295
Task 8-2: Configure PIM sparse mode 298
Task 8-3: Verify multicast forwarding 303
Lab 9: Access control lists 309
Overview 309
Task 9-1: Verify the lab starting configuration 310
Task 9-2: Port ACLs 310
Task 9-3: Using object groups 316
Task 9-4: Resource usage 319
Lab 10: 802.1X authentication and user roles on AOS-CX 323
Task 10-1: Verify the lab starting configuration 324
Task 10-2: RADIUS server setup 324
Task 10-3: Basic 802.1X authentication with a single user 333
Task 10-4: Change of authorization verification 343
Task 10-5: Basic 802.1X authentication with a single user 349
Task 10-6: Unknown role assignment 358

Contents 5
 Lab 11: MAC-based authentication and user roles 361
Task 11-1: MAC authentication with a single device on a port 362
Task 11-2: Verify access with two devices connected on same port 366
Task 11-3: Aruba user role-based access 373
Task 11-4: OPTIONAL—client-mode versus device-mode port
authentication 377
Task 11-5: Authentication priority order with combined MAC-auth and
802.1X 380
Task 11-6: Verify 802.1X authentication precedence over MAC-auth 387
Task 11-7: OPTIONAL—device profiles with LLDP 391
Task 11-8: Save checkpoint configuration 398
Lab 12.1: Integration with HPE Aruba Networking ClearPass Policy
Manager Platform downloadable user roles 399
Task 12.1-1: CPPM REST API communication 400
Task 12.1-2: CPPM user role definitions 406
Task 12.1-3: Testing 802.1X DUR with employee and contractor 408
Task 12.1-4: OPTIONAL—ClearPass DUR configuration and
troubleshooting 415
Lab 12.2: Integration with HPE Aruba Networking MC—user-based
tunneling with the MC firewall 423
Task 12.2-1: Prepare the lab devices 424
Task 12.2-2: HPE Aruba Networking MC integration 426
Task 12.2-3: User role configuration on the switch and the MC 432
Task 12.2-4: Test MC integration 434
Task 12.2-5: OPTIONAL—MAC authentication role example for IoT 442
Lab 13: Quality of Service 451
Overview 451
Task 13-1: Prepare the lab start configuration 452
Task 13-2: Port classification – trust configuration 454
Task 13-3: LLDP device profile for QoS trust 463
Task 13-4: QoS classification 467
Task 13-5: Queue configuration 477
Task 13-6: LLDP-MED and voice VLAN configuration 483

6 Contents
 Contents
Lab 14: REST API 487
Task 14-1: Enable access to REST API on the AOS-CX switch 489
Task 14-2: REST reference interface 491
Lab 15: HPE Aruba Networking Network Analytics Engine (NAE) 497
Task 15-1: Test the environment 497
Task 15-2: Review the built-in NAE script and agent 499
Task 15-3: Add a new NAE script and agent 510
Task 15-4: OPTIONAL – Connectivity check 516
Task 15-5: Review the NAE agent in the switch configuration file 522
Lab 16: Troubleshooting 525
Task 16-1: Prepare the lab starting configuration 526
Task 16-2: Support ticket troubleshoot 530

Contents 7
[This page intentionally left blank]

8
Lab 1: Base configuration - initial lab setup

Lab 1: Base configuration - initial lab setup

Lab diagram

Overview
In this lab activity, all switches will be factory reset and the Out-of-Band Management (OOBM) will be
configured. At the end of the configuration, a configuration checkpoint will be made.

Objectives
n Configure the OOBM network.
n Prepare a basic configuration checkpoint.

Task 1-1: Factory reset of devices (optional)

This task is optional and can be done if required. Check with your instructor. If you skip this task, you
can move to the next task (Task 2).

Lab 1: Base configuration - initial lab setup 9

Objectives
n Perform a factory reset.
n Remove all checkpoints.
Note that in case the AOS-CX is completely in factory default, the switch will prompt to you change the
administrator password at the first login.
This will also happen after the erase all zeroize procedure. This procedure will not only clear the
startup configuration, but it will also clear any other custom files, such as configuration checkpoints.

Steps
1. Open a console connection to Access-1 (6300A). Log in using admin and no password.

The initial hostname may be different from the output below; this depends on the
remote lab setup.

6300 login: admin

Password:

Last login: 2019-12-08 05:26:49 from the console

User "admin" has logged in 2 times in the past 30 days
6300 #

In case the switch prompts you to change the password at this point, it is already at
factory default, so there is no need to perform the erase all zeroize procedure in
the next step. Move on to the next switch; the password will be set in the next task.

2. Clear all configuration files and snapshots.

6300# erase all zeroize
This will securely erase all customer data and reset the switch
to factory defaults. This will initiate a reboot and render the
switch unavailable until the zeroization is complete.
This should take several minutes to one hour to complete.
Continue (y/n)? y
The system is going down for zeroization.
P52-6300A-Table12#

3. Open a console connection to the Access-2 (6300B ). Log in using admin and no password.
4. Clear all configuration files and snapshots (skip this step if the switch prompts you to change the
admin password).
6300# erase all zeroize
This will securely erase all customer data and reset the switch
to factory defaults. This will initiate a reboot and render the
switch unavailable until the zeroization is complete.
This should take several minutes to one hour to complete.

10 Task 1-1: Factory reset of devices (optional)

 Continue (y/n)? y
The system is going down for zeroization.
P52-6300B-Table12#

5. Open a console to the Core-1 (8325A ) and repeat the factory reset process.

If the switch shows a new password prompt, the switch is already at factory default,
so you can move on to the next step.

Lab 1: Base configuration - initial lab

6. Open a console to Core-2 (8325B ) and repeat the factory reset process.

If the switch shows a new password prompt, the switch is already at factory default,

setup
so you can move on to the next step.

Task 1-2: Configure the OOBM interface on Access-1

Objectives
n Configure an initial password.
n Make a checkpoint of the factory default configuration.
n Disable all interfaces to prevent remote lab network loops.
n Configure the OOBM management IP address.
n Make the base configuration checkpoint.

Steps
1. Switch to the console connection of Access-1.
2. Log in using admin and no password.
3. Since the switch is at factory default, the software will show a prompt to change the admin pass-
word. Set the admin password to aruba123.
6300 login: admin
Password:

Please configure the 'admin' user account password.

Enter new password: *****
Confirm new password: *****
6300#

If you entered a different password, the password can be changed with these com-
mands:
6300# configure terminal
6300(config)# user admin password plaintext aruba123

Task 1-2: Configure the OOBM interface on Access-1 11

 6300(config)# end

4. Create a checkpoint named icx-factory-default. This checkpoint is not used in the future labs,
but it will allow you to switch back to the factory default state without the erase all zeroize
command and reboot.
6300# copy running-config checkpoint icx-factory-default

5. Enter configuration mode and configure the hostname and OOBM IP address (10.251.1.4).
6300# configure terminal
6300(config)# hostname ICX-Access-1
ICX-Access-1(config)# interface mgmt
ICX-Access-1(config-if-mgmt)# ip static 10.251.1.4/24
ICX-Access-1(config-if-mgmt)# default-gateway 10.251.1.254
ICX-Access-1(config-if-mgmt)# exit

6. Disable all switch ports. Since the remote lab contains several redundant links between all the
switches, all interfaces are disabled initially. You will enable the interfaces as needed in later labs.
ICX-Access-1(config)# interface 1/1/1-1/1/28
ICX-Access-1(config-if-<1/1/1-1/1/28>)# shutdown
ICX-Access-1(config-if-<1/1/1-1/1/28>)# exit
ICX-Access-1(config)# end

7. Verify access on the OOBM network with a ping to the PC1 (10.251.1.91).
ICX-Access-1# ping 10.251.1.91 vrf mgmt
PING 10.251.1.91 (10.251.1.91) 100(128) bytes of data.
108 bytes from 10.251.1.91: icmp_seq=1 ttl=62 time=1.14 ms
108 bytes from 10.251.1.91: icmp_seq=2 ttl=62 time=0.875 ms
108 bytes from 10.251.1.91: icmp_seq=3 ttl=62 time=0.930 ms
108 bytes from 10.251.1.91: icmp_seq=4 ttl=62 time=1.04 ms
108 bytes from 10.251.1.91: icmp_seq=5 ttl=62 time=1.09 ms

--- 10.251.1.91 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4057ms
rtt min/avg/max/mdev = 0.875/1.017/1.147/0.108 ms

If the ping was not successful, review your settings.

8. You have now completed the base configuration and verified connectivity. This configuration will
be saved as the base configuration checkpoint for future labs. List current checkpoints. Only the
icx-factory-default checkpoint should be in the list after the zeroize factory reset.

There may be an automatic snapshot if five minutes have passed since your last con-
figuration change. This is the checkpoint post-configuration feature that is enabled
by default.

ICX-Access-1# show checkpoint

12 Task 1-2: Configure the OOBM interface on Access-1

 icx-factory-default

9. Make a checkpoint of the current configuration named icx-lab01-base.

ICX-Access-1# copy running-config checkpoint icx-lab01-base
Configuration changes will take time to process, please be patient.
ICX-Access-1#

10. Verify the checkpoint is now in the list (another checkpoint may have been created by the sys-

Lab 1: Base configuration - initial lab

tem already, which can be ignored).
ICX-Access-1# show checkpoint
CPC20191215142246
icx-lab01-base
icx-factory-default

setup
ICX-Access-1#

11. Verify the contents of the checkpoint.

ICX-Access-1# show checkpoint icx-lab01-base
Checkpoint configuration:
!
<output omitted>

If you made a mistake, you can remove the checkpoint with the erase checkpoint
<NAME> command.

If you need to see the configuration changes between two checkpoints or between a
checkpoint and the running configuration, the checkpoint diff command can be
used. Examples:
ICX-Access-2# checkpoint diff icx-factory-default icx-lab01-base
ICX-Access-2# checkpoint diff icx-lab01-base running-configuration

Sometimes it is handy to copy and paste text directly from the lab guide. If you are
unable to paste directly into your device or PC, pressing Ctrl-Alt-Shift will open a
clipboard in your web browser. Paste the contents into this clipboard, press Ctrl-Alt-
Shift to close the clipboard, and then paste the contents into the device or PC in the
remote lab.

Task 1-3: Configure the OOBM for Access-2, Core-1, and Core-2
Objectives
n Apply the initial configuration to the Access-2, Core-1, and Core-2 switches.

Task 1-3: Configure the OOBM for Access-2, Core-1, and Core-2 13
Steps
Access-2 base configuration
1. Switch to the console connection of Access-2.
2. Log in with admin and no password.
3. Configure the admin password as aruba123.
Please configure the 'admin' user account password.
Enter new password: *********
Confirm new password: *********

4. Enter these configuration commands:

6300# copy running-config checkpoint icx-factory-default
Configuration changes will take time to process, please be patient.
6300# configure terminal
6300(config)# hostname ICX-Access-2
ICX-Access-2(config)# interface mgmt
ICX-Access-2(config-if-mgmt)# ip static 10.251.1.5/24
ICX-Access-2(config-if-mgmt)# default-gateway 10.251.1.254
ICX-Access-2(config-if-mgmt)# exit
ICX-Access-2(config)# interface 1/1/1-1/1/28
ICX-Access-2(config-if-<1/1/1-1/1/28>)# shutdown
ICX-Access-2(config-if-<1/1/1-1/1/28>)# exit
ICX-Access-2(config)# end

5. Verify access to PC1 on the management network.

ICX-Access-2# ping 10.251.1.91 vrf mgmt
PING 10.251.1.91 (10.251.1.91) 100(128) bytes of data.
108 bytes from 10.251.1.91: icmp_seq=1 ttl=62 time=1.27 ms
108 bytes from 10.251.1.91: icmp_seq=2 ttl=62 time=1.20 ms
108 bytes from 10.251.1.91: icmp_seq=3 ttl=62 time=1.18 ms
108 bytes from 10.251.1.91: icmp_seq=4 ttl=62 time=1.05 ms
108 bytes from 10.251.1.91: icmp_seq=5 ttl=62 time=1.14 ms

--- 10.251.1.91 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 1.057/1.173/1.278/0.072 ms

6. Save the configuration checkpoint named icx-lab01-base.

ICX-Access-2# copy running-config checkpoint icx-lab01-base
Configuration changes will take time to process, please be patient.

Core-1 base configuration

1. Switch to the console connection of the 8325A (Core-1).
2. Log in with admin and no password.
3. Configure the admin password as aruba123.
Please configure the 'admin' user account password.

14 Task 1-3: Configure the OOBM for Access-2, Core-1, and Core-2
 Enter new password: *********
Confirm new password: *********

4. Enter the following configuration commands:

The system interface-group 1 speed 10g command instructs the switch to handle
the port speed for this group of ports. By default, CX 8325 Series (JL624A and
JL625A) have ports configured for 25 Gbps. In this lab, we are using 1 Gbps and 10

Lab 1: Base configuration - initial lab

Gbps. So, port groups need to be configured to work with 1 Gbps and 10 Gbps.
On the CX 8xxx Series platforms:
n All ports are L3 routed ports and shut down by default.

setup
n The HTTPS server is disabled on the in-band network (VRF default) by
default.
n The REST API access is read-only by default.
The following command instructions below will enable HTTPS on the default VRF
(the default global routing table) and allow read-write access to the REST API.

8325# copy running-config checkpoint icx-factory-default

Configuration changes will take time to process, please be patient.
8325# configure terminal
8325(config)# hostname ICX-Core-1
ICX-Core-1(config)# interface mgmt
ICX-Core-1(config-if-mgmt)# ip static 10.251.1.2/24
ICX-Core-1(config-if-mgmt)# default-gateway 10.251.1.254
ICX-Core-1(config-if-mgmt)# exit
ICX-Core-1(config)# https-server rest access-mode read-write
ICX-Core-1(config)# https-server vrf default
ICX-Core-1(config)# system interface-group 1 speed 10g
Changing the group speed will disable all member interfaces that
do not match the new speed.

Continue (y/n)? y
ICX-Core-2(config)# end

Notice that group 1 contains ports from 1/1/1 to 1/1/12. The choice between 1/10
Gbps and 25 Gbps is done by a port group, meaning that you are not allowed to mix
1 Gbps and 10 Gbps ports with 25 Gbps ports in the same port group
simultaneously. CX 8325 Series switches have four port groups. To view the port
group information of an AOS-CX switch, use the show system interface-group com-
mand. Sample output:
ICX-Core-1(config)# show system interface-group
------------------------------------------------
Group Speed Member Ports Mismatched Ports

Task 1-3: Configure the OOBM for Access-2, Core-1, and Core-2 15
 ------------------------------------------------
1 10g 1/1/1-1/1/12
2 25g 1/1/13-1/1/24
3 25g 1/1/25-1/1/36
4 25g 1/1/37-1/1/48

5. Test access to PC1 on the management network.

ICX-Core-1# ping 10.251.1.91 vrf mgmt

6. Save a configuration checkpoint named icx-lab01-base.

ICX-Core-1# copy running-config checkpoint icx-lab01-base
Configuration changes will take time to process, please be patient.

Core-2 base configuration

1. Switch to the console connection of the 8325B (Core-2).
2. Log in with admin and no password.
3. Configure the admin password as aruba123.
Please configure the 'admin' user account password.
Enter new password: *********
Confirm new password: *********

4. Enter these configuration commands:

8325# copy running-config checkpoint icx-factory-default
Configuration changes will take time to process, please be patient.
8325# configure terminal
8325(config)# hostname ICX-Core-2
ICX-Core-2(config)# interface mgmt
ICX-Core-2(config-if-mgmt)# ip static 10.251.1.3/24
ICX-Core-2(config-if-mgmt)# default-gateway 10.251.1.254
ICX-Core-2(config-if-mgmt)# exit
ICX-Core-2(config)# https-server rest access-mode read-write
ICX-Core-2(config)# https-server vrf default
ICX-Core-2(config)# system interface-group 1 speed 10g
Changing the group speed will disable all member interfaces that
do not match the new speed.

Continue (y/n)? y
ICX-Core-2(config)# end

5. Test access to PC1 on the management network.

ICX-Core-2# ping 10.251.1.91 vrf mgmt

6. Save a configuration checkpoint named icx-lab01-base.

ICX-Core-2# copy running-config checkpoint icx-lab01-base
Configuration changes will take time to process, please be patient.

You have completed Lab 1!

16 Task 1-3: Configure the OOBM for Access-2, Core-1, and Core-2
Lab 2: Configuring HPE Aruba Networking Virtual
Switching eXtension (VSX)

Lab 2: Configuring HPE Aruba Networking Virtual Switching eXtension (VSX)

Lab diagram

Overview
In this lab activity, VSX will be configured between the two core switches in the lab setup. VSX has sim-
ilar benefits as HPE Aruba Networking Virtual Switching Framework (VSF). However, VSX also offers
better high availability—required in core and data center environments—than a virtual switching tech-
nology like VSF. VSX binds two AOS-CX switches, of the same model type, to operate as one device for
Layer 2 for certain processes and operations.

Objectives
n Configure VSX.
n Understand the VSX configuration synchronization feature.
n Configure VSX to peer devices using VSX LAG.
n Understand and configure VSX active gateway (first hop redundancy).
n Configure a DHCP relay.
n Configure and understand split-system protection.

Lab 2: Configuring HPE Aruba Networking Virtual Switching eXtension (VSX) 17

 The checkpoint of this lab activity will be used as the base configuration for many other lab
activities. Make sure to verify your steps, and pay attention to which device you are work-
ing on when performing the tasks in this lab.

Task 2-1: Verify the lab starting configuration

Objectives
n Load the Lab01-base configuration checkpoint.

Steps
1. Open a console connection to Access-1. Log in using admin/aruba123.
ICX-Access-1# copy checkpoint icx-lab01-base running-config
Configuration changes will take time to process, please be patient.
ICX-Access-1#

2. Open a console connection to Access-2. Log in using admin/aruba123.

ICX-Access-2# copy checkpoint icx-lab01-base running-config
Configuration changes will take time to process, please be patient.
ICX-Access-2#

3. Open a console connection to Core-1. Log in using admin/aruba123.

ICX-Core-1# copy checkpoint icx-lab01-base running-config
Configuration changes will take time to process, please be patient.
ICX-Core-1#

4. Open a console connection to Core-2. Log in using admin/aruba123.

ICX-Core-2# copy checkpoint icx-lab01-base running-config
Configuration changes will take time to process, please be patient.
ICX-Core-2#

18 Task 2-1: Verify the lab starting configuration

Task 2-2: Preparing for VSX
Lab diagram

Objectives
n Configure the keepalive link.
n Configure a link aggregation that will be used as the Inter-Switch Link (ISL).

Steps
1. Open a terminal session to Core-1 and enter configuration mode. Create a VRF called KA.

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
ICX-Core-1# configure terminal
ICX-Core-1(config)# vrf KA
ICX-Core-1(config-vrf)# exit

2. Repeat this configuration on Core-2.

ICX-Core-2# configure terminal
ICX-Core-2(config)# vrf KA
ICX-Core-2(config-vrf)# exit

3. Access Core-1. Associate interface 1/1/45 to the VRF KA. Assign an IP address of
192.168.0.0/31 to the interface. Enable the interface.
ICX-Core-1(config)# interface 1/1/45
ICX-Core-1(config-if)# vrf attach KA
ICX-Core-1(config-if)# ip address 192.168.0.0/31
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# exit

A /31 subnet mask can be used on AOS-CX devices on point-to-point connections

that only have two host addresses. Thanks to the /31 support, there is no waste of
the subnet's network and broadcast addresses, like in a /30 subnet.

4. Repeat this on Core-2, but assign an IP address of 192.168.0.1/31.

ICX-Core-2(config)# interface 1/1/45
ICX-Core-2(config-if)# vrf attach KA
ICX-Core-2(config-if)# ip address 192.168.0.1/31
ICX-Core-2(config-if)# no shutdown
ICX-Core-2(config-if)# exit

Task 2-2: Preparing for VSX 19

 5. Verify that Core-2 can ping Core-1's IP address in the VRF KA.
ICX-Core-2(config)# ping 192.168.0.0 vrf KA
PING 192.168.0.0 (192.168.0.0) 100(128) bytes of data.
108 bytes from 192.168.0.0: icmp_seq=1 ttl=64 time=11.3 ms
108 bytes from 192.168.0.0: icmp_seq=2 ttl=64 time=0.171 ms
108 bytes from 192.168.0.0: icmp_seq=3 ttl=64 time=0.173 ms
108 bytes from 192.168.0.0: icmp_seq=4 ttl=64 time=0.171 ms
108 bytes from 192.168.0.0: icmp_seq=5 ttl=64 time=0.173 ms

--- 192.168.0.0 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4050ms
rtt min/avg/max/mdev = 0.171/2.401/11.317/4.458 ms

6. On Core-1, assign an IP address of 10.1.1.2/24 to the VLAN 1 interface.

ICX-Core-1(config)# interface vlan 1
ICX-Core-1(config-if)# ip address 10.1.1.2/24
ICX-Core-1(config-if)# exit

7. On Core-2, assign an IP address of 10.1.1.3/24 to the VLAN 1 interface.

ICX-Core-2(config)# interface vlan 1
ICX-Core-2(config-if)# ip address 10.1.1.3/24
ICX-Core-2(config-if)# exit

8. On both Core-1 and Core-2, create LAG 256, enable it, disable IP routing, allow all VLANs for this
trunk, and set the LACP mode to active.
ICX-Core-1(config)# interface lag 256
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# no routing
ICX-Core-1(config-if)# vlan trunk allowed all
ICX-Core-1(config-if)# lacp mode active
ICX-Core-1(config-if)# exit

ICX-Core-21(config)# interface lag 256

ICX-Core-2(config-if)# no shutdown
ICX-Core-2(config-if)# no routing
ICX-Core-2(config-if)# vlan trunk allowed all
ICX-Core-2(config-if)# lacp mode active
ICX-Core-2(config-if)# exit

9. On both Core-1 and Core-2, assign interfaces 1/1/46 and 1/1/47 to your new LAG and enable
them.
ICX-Core-1(config)# interface 1/1/46-1/1/47
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# lag 256
ICX-Core-1(config-if)# exit

ICX-Core-2(config)# interface 1/1/46-1/1/47

20 Task 2-2: Preparing for VSX

 ICX-Core-2(config-if)# no shutdown
ICX-Core-2(config-if)# lag 256
ICX-Core-2(config-if)# exit

10. From Core-1, verify that the ISL LAG is operational.

ICX-Core-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
Partner details of all interfaces:
---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256

11. From Core-1, verify that it can ping Core-2's IP address in VLAN 1 (10.1.1.3). This should be suc-
cessful.
ICX-Core-1(config)# ping 10.1.1.3
PING 10.1.1.3 (10.1.1.3) 100(128) bytes of data.
108 bytes from 10.1.1.3: icmp_seq=1 ttl=64 time=23.5 ms
108 bytes from 10.1.1.3: icmp_seq=2 ttl=64 time=0.175 ms
108 bytes from 10.1.1.3: icmp_seq=3 ttl=64 time=0.174 ms
108 bytes from 10.1.1.3: icmp_seq=4 ttl=64 time=0.181 ms
108 bytes from 10.1.1.3: icmp_seq=5 ttl=64 time=0.175 ms

--- 10.1.1.3 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4051ms
rtt min/avg/max/mdev = 0.174/4.850/23.549/9.349 ms

Task 2-2: Preparing for VSX 21

Task 2-3: VSX basic setup
Lab diagram

Objectives
n Prepare a link aggregation that will be used as the ISL.
n Set up the ISL link.
n Reference the keepalive link.
n Configure the VSX roles.
n Verify the status of the VSX cluster.

Steps
Core-1
1. Open a terminal session to Core-1 and enter configuration mode. Take note of the current ver-
sion.
ICX-Core-1(config)# show version
-----------------------------------------------------------------------------
ArubaOS-CX
(c) Copyright 2017-2024 Hewlett Packard Enterprise Development LP
-----------------------------------------------------------------------------
Version : GL.10.13.1000
Build Date : 2024-01-29 21:07:10 UTC
Build ID : ArubaOS-CX:GL.10.13.1000:7720573f9b1b:202401292047
Build SHA : 7720573f9b1b321e9916f3bd11b5fcf426fd5238
Hot Patches :
Active Image : primary

Service OS Version : GL.01.14.0001

BIOS Version : GL-01-0013

2. Review the LAG 256 connection to Core-2. This LAG was defined in the previous task. Some best
practice guidelines:
n Use the last LAG number supported by the switch—in this case, number 256.
n Allow all the VLANs on the ISL.

22 Task 2-3: VSX basic setup

 n Enable LACP and use the standard LACP timers (30 seconds).
ICX-Core-1# show running-config interface lag256
interface lag 256
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
exit

3. Enable support for jumbo frames (MTU size of 9198) on the ISL ports. This will be required when
using Dynamic Segmentation later in the course.
ICX-Core-1(config)# interface 1/1/46-1/1/47
ICX-Core-1(config-if-<1/1/46-1/1/47>)# mtu 9198
ICX-Core-1(config-if-<1/1/46-1/1/47>)# exit

4. Review the physical ports of LAG 256 and verify jumbo frame support is enabled.
ICX-Core-1(config)# show run int 1/1/46
interface 1/1/46
no shutdown

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
mtu 9198
lag 256
exit

ICX-Core-1(config)# show run int 1/1/47

interface 1/1/47
no shutdown
mtu 9198
lag 256
exit

Core-2
5. Open a console to Core-2 and enter configuration mode. Check the version; make sure this is the
same version as Core-1. Contact your instructor if it is different.
ICX-Core-2(config)# show version
-----------------------------------------------------------------------------
ArubaOS-CX
(c) Copyright 2017-2024 Hewlett Packard Enterprise Development LP
-----------------------------------------------------------------------------
Version : GL.10.13.1000
Build Date : 2024-01-29 21:07:10 UTC
Build ID : ArubaOS-CX:GL.10.13.1000:7720573f9b1b:202401292047
Build SHA : 7720573f9b1b321e9916f3bd11b5fcf426fd5238
Hot Patches :
Active Image : primary

Service OS Version : GL.01.14.0001

BIOS Version : GL-01-0013

Task 2-3: VSX basic setup 23

 6. Enable jumbo frame support on ISL ports 1/1/46 and 1/1/47.
ICX-Core-2(config)# interface 1/1/46-1/1/47
ICX-Core-2(config-if-<1/1/46-1/1/47>)# mtu 9198
ICX-Core-2(config-if-<1/1/46-1/1/47>)# exit

Core-1: review status

7. On Core-1, review the status of the LAG between the Core-1 and Core-2 switches.
ICX-Core-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
------------------------------------------------------------------------------
1/1/46 lag256 47 1 ALFNCD 90:20:c2:bc:17:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD 90:20:c2:bc:17:00 65534 256 up

Partner details of all interfaces:

------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
------------------------------------------------------------------------------
1/1/46 lag256 47 1 ALFNCD 90:20:c2:bc:97:00 65534 256
1/1/47 lag256 48 1 ALFNCD 90:20:c2:bc:97:00 65534 256

Review the VSX keepalive link

The keepalive link is used to handle a split-brain scenario. A split-brain scenario means that all the links
between the VSX members are down, while both switches are still up.
VSX will make an IP connectivity check with its peer if the keepalive link is defined. Since this IP check
has nothing to do with the rest of the IP network, it is recommended to put this IP link in a dedicated
VRF, with its own IP routing table.

The split-brain scenario will be tested in a later task in this lab.

Core-1
1. On Core-1, verify the connectivity to Core-2 for this VRF. This VRF and IP have been defined in
the NetEdit lab activity.
ICX-Core-1(config)# ping 192.168.0.1 vrf KA

24 Task 2-3: VSX basic setup

 PING 192.168.0.1 (192.168.0.1) 100(128) bytes of data.
108 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.202 ms
108 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.171 ms
108 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.175 ms
108 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.157 ms
108 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.226 ms

--- 192.168.0.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4099ms
rtt min/avg/max/mdev = 0.157/0.186/0.226/0.026 ms

Configure the VSX roles

Some best practice guidelines:
n On the VSX primary switch, set the system-mac manually. This will ensure that in case this switch
needs to be replaced due to hardware failure, the new switch can be configured with the same
system-mac as the original switch. By default, the hardware system MAC is used, which would
result in a different system MAC address after a hardware change.
n Use the default values for the ISL link timers.

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
n Make sure the role is meaningful based on the hostname. For example, assign the primary role on
Core-1 and the secondary role on Core-2.
n Enable the VSX global sync. This will keep many parts of the switch configuration automatically
synchronized between the switches.
Core-1
1. On Core-1, configure the following for VSX, using a system MAC address of 02:01:00:00:01:00,
referencing LAG 256 for the ISL link, defining the role as primary, and enabling vsx-global syn-
chronization.
ICX-Core-1(config)# vsx
ICX-Core-1(config-vsx)# system-mac 02:01:00:00:01:00
ICX-Core-1(config-vsx)# inter-switch-link lag 256
ICX-Core-1(config-vsx)# role primary
ICX-Core-1(config-vsx)# vsx-sync vsx-global
ICX-Core-1(config-vsx)# exit

Core-2
2. On Core-2, configure the following, defining the role as secondary:
ICX-Core-2(config)# vsx
ICX-Core-2(config-vsx)# inter-switch-link lag 256
ICX-Core-2(config-vsx)# role secondary
ICX-Core-2(config-vsx)# exit

Task 2-3: VSX basic setup 25

 Core-1
3. On Core-1, now review the VSX status. You might have to wait a minute for the synchronization
to complete.
ICX-Core-1(config)# show vsx status
VSX Operational State
---------------------
ISL channel : In-Sync
ISL mgmt channel : operational
Config Sync Status : in-sync
NAE : peer_reachable
HTTPS Server : peer_reachable

Attribute Local Peer

------------ -------- --------
ISL link lag256 lag256
ISL version 2 2
System MAC 02:01:00:00:01:00 02:01:00:00:01:00
Platform 8325 8325
Software Version GL.10.13.1000 GL.10.13.1000
Device Role primary secondary

In the previous output, the switch software version may be different from your actual
lab environment. However, both switches must have the same version.

4. Compare the running configurations between Core-1 and Core-2.

Core-1
ICX-Core-1(config)# show running-config | begin 5 vsx
vsx
system-mac 02:01:00:00:01:00
inter-switch-link lag 256
role primary
vsx-sync vsx-global
ICX-Core-1(config)#

Core-2
ICX-Core-2(config)# show running-config | begin 5 vsx
vsx
system-mac 02:01:00:00:01:00
inter-switch-link lag 256
role secondary
vsx-sync vsx-global
ICX-Core-2(config)#

Notice that Core-2 has received the vsx-sync command automatically, as well as the system-mac
command.

26 Task 2-3: VSX basic setup

 Core-1
5. On Core-1, review the VSX section of the running configuration.
ICX-Core-1(config)# show running-config vsx
vsx
system-mac 02:01:00:00:01:00
inter-switch-link lag 256
role primary
vsx-sync vsx-global
interface lag 256
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
interface 1/1/46
no shutdown
lag 256
interface 1/1/47
no shutdown

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
lag 256

Notice in the previous output that the interface that is used for the ISL will auto-
matically set the native VLAN to the native tagged state. This means that there is
no untagged traffic passing on the ISL. One of the benefits of having the native
VLAN tagged is that any 802.1p CoS value would be preserved on the ISL.

6. Review the running configuration on Core-2.

ICX-Core-2(config)# show running-config vsx
vsx
system-mac 02:01:00:00:01:00
inter-switch-link lag 256
role secondary
interface lag 256
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
interface 1/1/47
no shutdown
lag 256
interface 1/1/46
no shutdown
lag 256

7. Next, review the configuration that is synchronized between the two core switches.

Task 2-3: VSX basic setup 27

 Core-1
ICX-Core-1(config)# show running-config vsx-sync
Current vsx-sync configuration:
!
!Version ArubaOS-CX GL.10.13.1000
!export-password: default
vsx
system-mac 02:01:00:00:01:00
vsx-sync vsx-global

Core-2
ICX-Core-2(config)# show running-config vsx-sync
Current vsx-sync configuration:
!
!Version ArubaOS-CX GL.10.13.1000
!export-password: default
vsx
system-mac 02:01:00:00:01:00
vsx-sync vsx-global

Reference the keepalive link

Reference the keepalive link in the VSX context. This is the detection of split brain, in case all the links
of the ISL are down. The split brain will be tested in a later task.
Core-1
1. Configure the keepalive link, making sure to check the source and destination IP.
ICX-Core-1(config)# vsx
ICX-Core-1(config-vsx)# keepalive peer 192.168.0.1 source 192.168.0.0 vrf KA
ICX-Core-1(config-vsx)# exit

Core-2
2. Set the keepalive link, making sure to invert the source and destination IP.
ICX-Core-2(config)# vsx
ICX-Core-2(config-vsx)# keepalive peer 192.168.0.0 source 192.168.0.1 vrf KA
ICX-Core-2(config-vsx)# exit

Verify the VSX status on Core-1

3. On Core-1, verify the VSX status.
ICX-Core-1(config)# show vsx brief
ISL State : In-Sync
Device State : Peer-Established
Keepalive State : Keepalive-Init
Device Role : primary
Number of Multi-chassis LAG interfaces : 0

ICX-Core-1(config)# show vsx brief

28 Task 2-3: VSX basic setup

 ISL State : In-Sync
Device State : Peer-Established
Keepalive State : Keepalive-Established
Device Role : Primary
Number of Multi-chassis LAG interfaces : 0

The previous output was taken right after enabling the keepalive link, showing the
Keepalive State as Keepalive-Init. A few seconds later, the state will transition to
Keepalive-Established, so you may see that state already in your output.

Core-2
4. Review the same output on the console of Core-2.
ICX-Core-2(config)# show vsx brief
ISL State : In-Sync
Device State : Peer-Established
Keepalive State : Keepalive-Established
Device Role : secondary
Number of Multi-chassis LAG interfaces : 0

Lab 2: Configuring HPE Aruba

ICX-Core-2(config)#

Networking Virtual Switching

Core-1
When an administrator is connected to Core-1, they may need to review some command output
on the VSX peer device (that is, Core-2). Instead of having to connect to the peer device, many
commands support the vsx-peer parameter option and can be executed from the VSX primary
switch.
This indicates to the CLI that the command should be executed on the peer device, so the output
of the command comes effectively from the peer device, but there is no need to log into the peer
device.
5. On Core-1, run the same command, but add the vsx-peer option. Compare this output with the
previous output that was shown on the console of the Core-2 device. The command output
should be the same.
ICX-Core-1(config)# show vsx brief vsx-peer
ISL State : In-Sync
Device State : Peer-Established
Keepalive State : Keepalive-Established
Device Role : Secondary
Number of Multi-chassis LAG interfaces : 0

6. On Core-1, test this feature again with the show lldp neighbor 1/1/46 command. When the com-
mand is executed using vsx-peer, the output will come from Core-2, so Core-1 will be listed as an
LLDP peer.
ICX-Core-1(config)# show lldp neighbor-info 1/1/46
ICX-Core-1(config)# show lldp neighbor-info 1/1/46 vsx-peer

Task 2-3: VSX basic setup 29

 7. On Core-1, verify that the keepalive link is properly connected.
ICX-Core-1(config)# show vsx status keepalive
Keepalive State : Keepalive-Established
Last Established : Mon Apr 23 16:15:34 2024
Last Failed : Mon Apr 23 16:13:27 2024
Peer System Id : 02:01:00:00:01:00
Peer Device Role : secondary

Keepalive Counters
Keepalive Packets Tx : 385
Keepalive Packets Rx : 255
Keepalive Timeouts : 0
Keepalive Packets Dropped : 0

8. On Core-1, execute the same command for the VSX peer (Core-2). Note the peer device role and
the counters in the two command outputs are those from Core-2's perspective.
ICX-Core-1(config)# show vsx status keepalive vsx-peer
Keepalive State : Keepalive-Established
Last Established : Mon Apr 23 16:16:16 2024
Last Failed :
Peer System Id : 02:01:00:00:01:00
Peer Device Role : primary

Keepalive Counters
Keepalive Packets Tx : 360
Keepalive Packets Rx : 360
Keepalive Timeouts : 0
Keepalive Packets Dropped : 0

Task 2-4: VSX configuration synchronization

Lab diagram

Objectives
n Review default configuration synchronization behavior on both VSX switches.
n Enable configuration synchronization.
n Verify VSX operation.
n Review an out-of-sync status.

30 Task 2-4: VSX configuration synchronization

Steps
Review the default configuration synchronization behavior on both VSX switches
In these steps, the current status of the configuration synchronization will be reviewed. Only a limited
set of configurations (vsx-global sync) are synchronized between the VSX peers at this point. This
introduces potential configuration risks, since an administrator should remember to define a VLAN
(and most other settings) on both VSX peers. In the next steps, you will explore the default behavior.
Afterwards, the VSX configuration synchronization feature will be used to automatically synchronize
the configuration between the VSX peers. Note that in a production environment that uses HPE Aruba
Networking Central for network management, HPE Aruba Networking Central can push the con-
figurations to both switches or push the configuration to the VSX primary, who, in turn, synchronizes it
to the secondary.
In the configuration, there are:
n Global configuration settings: Examples are global ACLs, time configurations, and so forth.
Synchronization of these settings can be enabled under the VSX global context.

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
n Context configuration settings: An example is VLANs.
Synchronization of these settings must be enabled per context.
The lab will introduce a global and a context configuration change.
Core-1
1. On Core-1, verify that the config-sync process is active.
ICX-Core-1(config)# show vsx status config-sync
Admin state : Enabled
Operational State : Operational
Error State : None
Recommended remediation : N/A
Current time : Mon Apr 23 16:28:42 2024
Last sync time : Sun Apr 22 21:21:10 2024
ICX-Core-1(config)#

Global configuration change

As an example, a new admin user called demo will be created on Core-1. Since there is no con-
figuration synchronization at this point, the user will not exist on Core-2.
The admin users are part of the aaa vsx-sync feature that will be enabled in the next section.
2. On Core-1, define a new admin user called demo with a password of demo.
ICX-Core-1(config)# user demo group administrators password plaintext demo

3. Review the running configuration.

ICX-Core-1(config)# show running-config | include user

Task 2-4: VSX configuration synchronization 31

 user admin group administrators password ciphertext
AQBapV8rLxVdvc31eF2hwggG6NdJ/p/bqXrRlSsdibXBcJ5SYgAAAI9vpWqHUNb5frqUOqkMdrazRAVY0tN
dl36lkRQVKggG5ldaN9iEzCWFKQz1b7fMpNMt8xX0nal2et4T8N1aXuXnvJFKH+X1BPs7BSiKboKXGiEW4/
sy/Sv6EGz5yshSNuoB
user demo group administrators password ciphertext
AQBapazfG0p4r497EJ3fcdfaSHIeRNhPeHHvMVYX9r8YpjulYgAAAHGn29l4MqabnQyJ0tQpanbi+eao6jz
b/tfgRDXefU5s+4U5qDInY5fTjoGUNSxQjTHNeUpgWQ9cbCCXxirTU9eKfbWbU3jS45B9GGwlM5nySfAopi
FDLebNg+S3yEW8o2fy

4. Review the running configuration of the vsx-peer (Core-2). Note that the user demo should not
exist on Core-2.
ICX-Core-1(config)# show running-config vsx-peer | include user
user admin group administrators password ciphertext
ICX-Core-1(config)#

This was an example of a global configuration change where synchronization was not enabled
(which it is not by default).
Context configuration change
Next, you will define a new VLAN on Core-1 and verify the configuration status on Core-2.
Core-1
5. On Core-1, define VLAN 11.
ICX-Core-1(config)# vlan 11
ICX-Core-1(config-vlan-11)# exit

6. Verify the VLAN list.

ICX-Core-1(config)# show vlan

---------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
---------------------------------------------------------------------------------
1 DEFAULT_VLAN_1 up ok default lag256
11 VLAN11 up ok static lag256

7. Next, verify the VLAN list on the VSX peer, Core-2.

ICX-Core-1(config)# show vlan vsx-peer

---------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
---------------------------------------------------------------------------------
1 DEFAULT_VLAN_1 up ok default lag256

This demonstrates that each switch has a local configuration, and, by default, a configuration
change on Core-1 is not automatically pushed to Core-2.

32 Task 2-4: VSX configuration synchronization

 Enable global configuration synchronization for other features
The administrator must opt in for the global features that should be synchronized by the VSX
members.
8. On Core-1, review the current VSX configuration.
ICX-Core-1(config)# show running-config vsx-sync
Current vsx-sync configuration:
!
!Version ArubaOS-CX GL.10.13.1000
!export-password: default
vsx
system-mac 02:01:00:00:01:00
vsx-sync vsx-global

9. Next, enable some of the VSX sync features. For this lab exercise, the aaa option is required,
since that includes the admin users.
ICX-Core-1(config)# vsx
ICX-Core-1(config-vsx)# vsx-sync aaa bfd-global bgp dhcp-relay mclag-interfaces
ICX-Core-1(config-vsx)# vsx-sync ospf qos-global route-map

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
ICX-Core-1(config-vsx)# exit

Verify synchronization operation for the global features

10. Review the updated output of the vsx-sync command.
ICX-Core-1(config)# show run vsx-sync
Current vsx-sync configuration:
!
!Version ArubaOS-CX GL.10.13.1000
!export-password: default
user admin group administrators password ciphertext
AQBapXRaY6Hk0KGjVzqZjewoYg94PjoFJCPdL8qqusr+/7b/YgAAADi/osVJXNfAMvTortdokcXfSSG1/9R
zFDtehOzaNeea8iMUWOtNNv1SVTufQwLeVHXnk2Crpat4r29ENMWQJ76/Z1cngFVibQV4M7bELYq8+GJCgZ
fKHoTgjlNOKjqCb5EO
user demo group administrators password ciphertext
AQBapWf0qG1No/HM5fQb3+D0teB4f9bvCrhVtqExP0xflB1wYgAAAGmR1x0axs0A5LVMSvTMmJAllPr494i
lg4ZcSzOCZGXVRDvfXlIgo9+kVA9rAWc42ONmXLElQ4+0wF3vGiW1Tj1I8ht4VUrCF4iKIhf+BVc+wQl/lc
AcgN+qdHDQZ006CFvb
!
!
!
vsx
system-mac 02:01:00:00:01:00
vsx-sync aaa bfd-global bgp dhcp-relay mclag-interfaces ospf qos-global route-
map vsx-global

11. Run the command again with the vsx-peer option. The configuration of the local Core-1 and
remote Core-2 should be the same now, so the user demo exists in both switch configurations.
ICX-Core-1(config)# show running-config vsx-sync vsx-peer

Task 2-4: VSX configuration synchronization 33

 Current vsx-sync configuration:
!
!Version ArubaOS-CX GL.10.13.1000
!export-password: default
user admin group administrators password ciphertext
user demo group administrators password ciphertext
!
!
!
vsx
system-mac 02:01:00:00:01:00
vsx-sync aaa bfd-global bgp dhcp-relay mclag-interfaces ospf qos-global route-
map vsx-global

12. Cleanup: On Core-1, remove the demo user account.

ICX-Core-1(config)# no user demo
User demo's home directory and active sessions will be deleted.
Do you want to continue (y/n)? y

ICX-Core-1(config)#

13. Verify the configuration change on Core-1 and Core-2. Notice that there is no longer a user
demo on either switch.
ICX-Core-1(config)# show run vsx-sync
Current vsx-sync configuration:
!
!Version ArubaOS-CX GL.10.13.1000
!export-password: default
user admin group administrators password ciphertext
AQBapRmG3aISxIdvh4rq1JlVT9a6zgXnkKfjmK/UNQDF+2lCYgAAAP1kVtbRXI7tkaxSRFI1+ss4nz3wnAb
Knyw2j9VXFxCwJD2sHCDoNAHdC1rjj0svX0M/54jZgIBlB
16P7eEBnmD9HKpMLCVmVjVqdDvantLNESEPFUq6HPJmG0n9zby8Nqed
!
!
!
!
!
vsx
system-mac 02:01:00:00:01:00
vsx-sync aaa bfd-global bgp dhcp-relay mclag-interfaces ospf qos-global route-
map vsx-global

ICX-Core-1(config)# show run vsx-sync vsx-peer

Current vsx-sync configuration:
!
!Version ArubaOS-CX GL.10.13.1000
!export-password: default
user admin group administrators password ciphertext

34 Task 2-4: VSX configuration synchronization

 AQBapRmG3aISxIdvh4rq1JlVT9a6zgXnkKfjmK/UNQDF+2lCYgAAAP1kVtbRXI7tkaxSRFI1+ss4nz3wnAb
Knyw2j9VXFxCwJD2sHCDoNAHdC1rjj0svX0M/54jZgIBlB
16P7eEBnmD9HKpMLCVmVjVqdDvantLNESEPFUq6HPJmG0n9zby8Nqed
!
!
!
!
!
vsx
system-mac 02:01:00:00:01:00
vsx-sync aaa bfd-global bgp dhcp-relay mclag-interfaces ospf qos-global route-
map vsx-global

This demonstrates the global feature synchronization.

Synchronization for context features
For a context feature, such as a VLAN, synchronization must be enabled within the specific con-
figuration context.
14. On Core-1, enter the VLAN 11 context and enable the vsx-sync option for this VLAN.

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
ICX-Core-1(config)# vlan 11
ICX-Core-1(config-vlan-11)# vsx-sync
ICX-Core-1(config-vlan-11)# exit

15. Review the VLAN list of the VSX peer device.

ICX-Core-1(config)# show vlan vsx-peer

---------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
---------------------------------------------------------------------------------
1 DEFAULT_VLAN_1 up ok default lag256
11 VLAN11 up ok static lag256

16. On Core-1, create VLAN 12 and VLAN 13; these will be used in later labs.
ICX-Core-1(config)# vlan 12,13
ICX-Core-1(config-vlan-<12,13>)# vsx-sync
ICX-Core-1(config-vlan-<12,13>)# exit

17. Verify the VLANs exist on the VSX peer.

ICX-Core-1(config)# show vlan vsx-peer

---------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-------------------------------------------------------------------------------
1 DEFAULT_VLAN_1 up ok default lag256
11 VLAN11 up ok static lag256
12 VLAN12 up ok static lag256
13 VLAN13 up ok static lag256

Task 2-4: VSX configuration synchronization 35

Review the synchronization process rules
At this point, the lab has demonstrated that the VSX configuration synchronization feature can help
the administrator to perform an action only once on the primary switch, and the synchronization will
push the configuration change to the secondary switch.
There are some rules for the synchronization process:
n For any feature that IS ENABLED for synchronization:
l Configuration changes MUST be made on the primary switch.
l If any change is made on the secondary switch, the change will be overwritten by the VSX
sync with the primary switch configuration. Therefore, the secondary switch SHOULD NOT
be used for those configuration changes.
n For any feature that IS NOT ENABLED for synchronization:
l Changes can be made on either switch and will only exist in the local configuration of each
switch.
n Synchronization status changes:
l When synchronization is turned off for a feature, each switch maintains the current con-
figuration for that feature in the local configuration. Disabling the configuration sync will
not remove that configuration on the secondary node.
l When both switches have local configuration changes for a feature, and the feature is
enabled for synchronization, the version of the primary switch will be leading. The sec-
ondary switch will lose any local configuration changes related to this feature.
l If the sync process is out of sync, due to an ISL failure or a member reboot, the system will
automatically update all the settings for the enabled features the first time they come back
online. Since this is a complete feature sync, any new, modified, or removed configurations
are automatically synchronized as well. Any changes applied locally on the secondary node
would be lost at this point.

36 Task 2-4: VSX configuration synchronization

Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG)
Lab diagram

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
Objectives
n Setup a VSX LAG with configuration synchronization.
n Configure peer switches (Access-1 and Access-2).
n Verify connectivity.
n Configure a VSX LAG to the HPE Aruba Networking Mobility Controller (gateway).
This task will cover the redundant Layer 2 connectivity to a VSX system. Since both VSX members have
their own management and control planes, the default behavior would use each system's own unique
MAC address for Layer 2 protocols.
Since VSX wants to present itself as a single Layer 2 device to the peer devices, the VSX LAG feature
can be used so both VSX members will present themselves with the same MAC address for Layer 2 pro-
tocols such as LACP and STP.
A VSX member can still have a local LAG, using only local ports, but this is uncommon. Any LAG that
spans ports of both members of the VSX system, the administrator must define this LAG as a VSX LAG
(formerly referred to as a multi-chassis or MC LAG).
In this task, two VSX LAGs will be defined: one from the VSX cluster to Access-1 and one to Access-2.

Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG) 37

Steps
Core-1: VSX LAG to Access-1
1. Open a console connection to Core-1. Enter configuration mode and define a new LAG of the
multi-chassis type. This is the VSX LAG.
ICX-Core-1(config)# interface lag 1 multi-chassis

By default, a VSX LAG is:

n Shut down
n LACP-enabled
n Switched port (a VSX LAG cannot be a routed port)

LACP is the recommended method to connect with the peer switches. When it is not
possible to use LACP with the peer device, a static (no protocol) VSX LAG can be cre-
ated using the interface lag <id> multi-chassis static command.
In some scenarios, the peer device may not always support LACP. This may happen
with servers during the boot process (when the server administrator wants to use a
PXE boot for the initial server provisioning). This may also occur when the peer
switch must be deployed with Zero-Touch Provisioning (ZTP), since the peer switch
does not have an LACP configuration at factory default.
For these use cases, it is possible to configure AOS-CX with the LACP fallback fea-
ture. With this feature enabled, the switch will keep one interface in a forwarding
state when no LACP packets are received from the peer device. In the default LACP
mode, both interfaces are blocked, so the peer device is not able to reach the net-
work.

2. Review this default state by reviewing the current configuration for the current context.
ICX-Core-1(config-lag-if)# show running-config current-context
interface lag 1 multi-chassis
no routing
vlan access 1
lacp mode active
ICX-Core-1(config-lag-if)#

3. Make the VSX LAG a VLAN trunk and permit VLANs 1 and 11–13.
ICX-Core-1(config-lag-if)# vlan trunk allowed 1,11-13

In this command, 11-13 is a range, so VLAN 12 will be included as well.

4. Set a description on the LAG.

ICX-Core-1(config-lag-if)# description access1

38 Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG)

 5. Enable the port.
ICX-Core-1(config-lag-if)# no shutdown

6. Review the configuration changes.

ICX-Core-1(config-lag-if)# show running-config current-context
interface lag 1 multi-chassis
description access1
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed 1,11-13
lacp mode active
ICX-Core-1(config-lag-if)# exit

Core-2: VSX LAG to Access-1

7. Open a console connection to Core-2. Define a new VSX LAG with LAG ID 1 of multi-chassis type.
ICX-Core-2(config)# interface lag 1 multi-chassis

8. Review the current configuration.

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
ICX-Core-2(config-lag-if)# show run current-context
interface lag 1 multi-chassis
description access1
no routing
vlan trunk native 1
vlan trunk allowed 1,11-13
lacp mode active
ICX-Core-2(config-lag-if)#
n Question: Why is the VSX LAG already a VLAN trunk and why are the VLANs allowed?
n Answer: Due to the global vsx config-sync mclag-interfaces.
9. Even though the VLAN configuration has been synchronized, the interface must still be enabled
per member. Enable the interface.
ICX-Core-2(config-lag-if)# no shutdown

10. Review the configuration.

ICX-Core-2(config-lag-if)# show running-config current-context
interface lag 1 multi-chassis
description access1
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed 1,11-13
lacp mode active
ICX-Core-2(config-lag-if)# exit

Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG) 39

 Core-1: Assign the local physical port to the VSX LAG
11. On Core-1, assign interface 1/1/1 to LAG 1. This is the LAG that was created in the previous
steps.
n Description: access1
n MTU: 9100
n LAG: 1
n Status: enabled (no shutdown)
ICX-Core-1(config)# interface 1/1/1
ICX-Core-1(config-if)# description access1
ICX-Core-1(config-if)# lag 1
ICX-Core-1(config-if)# mtu 9100
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# exit

Core-2
12. On Core-2, repeat the commands of the previous step for the same interface, interface 1/1/1.
ICX-Core-2(config)# interface 1/1/1
ICX-Core-2(config-if)# description access1
ICX-Core-2(config-if)# lag 1
ICX-Core-2(config-if)# mtu 9100
ICX-Core-2(config-if)# no shutdown
ICX-Core-2(config-if)# exit

Configure the VSX LAG to Access-2 on both core switches

In these steps, the VSX LAG to Access-2 will be defined on both core switches.
13. The following are the manual steps for both Core-1 and Core-2 to create LAG 2, which connects
to Access-2.
ICX-Core-1(config)# interface lag 2 multi-chassis
ICX-Core-1(config-lag-if)# description access2
ICX-Core-1(config-lag-if)# no shutdown
ICX-Core-1(config-lag-if)# no routing
ICX-Core-1(config-lag-if)# vlan trunk native 1
ICX-Core-1(config-lag-if)# vlan trunk allowed 1,11-13
ICX-Core-1(config-lag-if)# lacp mode active
ICX-Core-1(config-lag-if)# exit
ICX-Core-1(config)# interface 1/1/2
ICX-Core-1(config-if)# description access2
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# mtu 9100
ICX-Core-1(config-if)# lag 2
ICX-Core-1(config-if)# exit

ICX-Core-2(config)# interface lag 2 multi-chassis

40 Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG)

 ICX-Core-2(config-lag-if)# no shutdown
ICX-Core-2(config-lag-if)# exit
ICX-Core-2(config)# interface 1/1/2
ICX-Core-2(config-if)# description access2
ICX-Core-2(config-if)# no shutdown
ICX-Core-2(config-if)# mtu 9100
ICX-Core-2(config-if)# lag 2
ICX-Core-2(config-if)# exit

Create the corresponding LAG on Access-1 and Access-2

Both Access-1 and Access-2 need to get the uplink LAG defined. Both access switches will be
using the same LAG ID as the upstream LAG to connect to the core switches. This makes it easy
to identify the LAG when troubleshooting issues. In these labs, LAG ID 255 will be used for the
uplink LAG on the access switches.
Access-1
14. Access Access-1's console (admin/aruba123). Create VLANs 11–13.
ICX-Access-1(config)# vlan 11-13
ICX-Access-1(config-vlan-<11-13>)# exit

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
15. Create LAG 255.
ICX-Access-1(config)# interface lag 255
ICX-Access-1(config-lag-if)# description core
ICX-Access-1(config-lag-if)# no routing
ICX-Access-1(config-lag-if)# vlan trunk allowed all
ICX-Access-1(config-lag-if)# no shut
ICX-Access-1(config-lag-if)# lacp mode active
ICX-Access-1(config-lag-if)# exit

16. Assign interfaces 1/1/25 and 1/1/26 to the LAG and define an MTU of 9100 bytes.
ICX-Access-1(config)# interface 1/1/25,1/1/26
ICX-Access-1(config-if-<1/1/25,1/1/26>)# lag 255
ICX-Access-1(config-if-<1/1/25,1/1/26>)# mtu 9100
ICX-Access-1(config-if-<1/1/25,1/1/26>)# no shutdown
ICX-Access-1(config-if-<1/1/25,1/1/26>)# exit

17. Verify the status of the LAG.

ICX-Access-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State

Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG) 41

 ---------------------------------------------------------------------------------
1/1/25 lag255 26 1 ALFNCD 10:4f:58:f6:e3:80 65534 255 up
1/1/26 lag255 27 1 ALFNCD 10:4f:58:f6:e3:80 65534 255 up

Partner details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/25 lag255 1 1 ALFNCD 02:01:00:00:01:00 65534 1
1/1/26 lag255 1001 1 ALFNCD 02:01:00:00:01:00 65534 1
n Question: What is the Forwarding State of the ports in LAG 255?
n Answer: Both ports 1/1/25 and 1/1/26 should have the state up.
n Question: Under Partner details, what is the Partner System-ID?
n Answer: This is the LACP system ID, which is based on the switch system ID. This was con-
figured statically to 02:01:00:00:01:00.
n Question: Is the Partner System-ID the same for ports 1/1/25 and 1/1/26?
n Answer: Yes. VSX ensures that both members of the VSX are communicating with the
same System-ID to peer devices, so they appear as one device.
Access-2
18. Repeat this process for Access-2 (admin/aruba123).
ICX-Access-2(config)# vlan 11-13
ICX-Access-2(config-vlan-<11-13>)# exit

ICX-Access-2(config)# interface lag 255

ICX-Access-2(config-lag-if)# description core
ICX-Access-2(config-lag-if)# no routing
ICX-Access-2(config-lag-if)# vlan trunk allowed all
ICX-Access-2(config-lag-if)# no shutdown
ICX-Access-2(config-lag-if)# lacp mode active
ICX-Access-2(config-lag-if)# exit

ICX-Access-2(config)# interface 1/1/25,1/1/26

ICX-Access-2(config-if-<1/1/25,1/1/26>)# lag 255
ICX-Access-2(config-if-<1/1/25,1/1/26>)# mtu 9100
ICX-Access-2(config-if-<1/1/25,1/1/26>)# no shutdown
ICX-Access-2(config-if-<1/1/25,1/1/26>)# exit

19. Verify the status of the LAG on Access-2.

ICX-Access-2(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync

42 Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG)

 C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/25 lag255 26 1 ALFNCD 10:4f:58:fc:b2:40 65534 255 up
1/1/26 lag255 27 1 ALFNCD 10:4f:58:fc:b2:40 65534 255 up

Partner details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/25 lag255 2 1 ALFNCD 02:01:00:00:01:00 65534 2
1/1/26 lag255 1002 1 ALFNCD 02:01:00:00:01:00 65534 2

Core-1

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
20. On Core-1, review the LAG status.
ICX-Core-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 ALFNCD 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/46 lag256 47 1 ALFNCD 90:20:c2:bc:17:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD 90:20:c2:bc:17:00 65534 256 up

Partner details of all interfaces:

------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
------------------------------------------------------------------------------
1/1/1 lag1(mc) 26 1 ALFNCD 88:3a:30:98:30:c0 65534 256
1/1/2 lag2(mc) 26 1 ALFNCD 88:3a:30:97:b6:00 65534 256
1/1/46 lag256 47 1 ALFNCD 90:20:c2:bc:97:00 65534 256
1/1/47 lag256 48 1 ALFNCD 90:20:c2:bc:97:00 65534 256

Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG) 43

 ICX-Core-1(config)#
n Question: Why is the actor System-ID for interfaces 1/1/1 and 1/1/46 different?
n Answer: Interface 1/1/1 is part of a VSX LAG, so it uses the VSX system MAC. Interface
1/1/46 is part of a local LAG, so it can use the base system MAC instead of the VSX-con-
figured system MAC.
21. On Core-1, review the LAG status with the peer VSX status.
ICX-Core-1(config)# show lacp interfaces multi-chassis

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

------------------------------------------------------------------------------
Intf Aggregate Port Port State System-ID System Aggr
name id Priority Priority Key
------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 ALFNCD 02:01:00:00:01:00 65534 1
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:01:00 65534 2

Partner details of all interfaces:

------------------------------------------------------------------------------
Intf Aggregate Partner Port State System-ID System Aggr
name Port-id Priority Priority Key
------------------------------------------------------------------------------
1/1/1 lag1(mc) 26 1 ALFNCD 88:3a:30:98:30:c0 65534 256
1/1/2 lag2(mc) 26 1 ALFNCD 88:3a:30:97:b6:00 65534 256

Remote Actor details of all interfaces:

------------------------------------------------------------------------------
Intf Aggregate Port Port State System-ID System Aggr
name id Priority Priority Key
------------------------------------------------------------------------------
1/1/1 lag1(mc) 1001 1 ALFNCD 02:01:00:00:01:00 65534 1
1/1/2 lag2(mc) 1002 1 ALFNCD 02:01:00:00:01:00 65534 2

Remote Partner details of all interfaces:

------------------------------------------------------------------------------
Intf Aggregate Partner Port State System-ID System Aggr
name Port-id Priority Priority Key
------------------------------------------------------------------------------
1/1/1 lag1(mc) 27 1 ALFNCD 88:3a:30:98:30:c0 65534 256
1/1/2 lag2(mc) 27 1 ALFNCD 88:3a:30:97:b6:00 65534 256

44 Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG)

 ICX-Core-1(config)#

You have now established uplink LAGs to the VSX cluster. From the access switches' per-
spectives, Core-1 and Core-2 look like a single switch (02:01:00:00:01:00).
Access-1
22. View the LLDP neighbor information on Access-1.
ICX-Access-1(config)# show lldp neighbor-info

LLDP Neighbor Information

=========================

Total Neighbor Entries : 3

Total Neighbor Entries Deleted : 4
Total Neighbor Entries Dropped : 0
Total Neighbor Entries Aged-Out : 4

LOCAL-PORT CHASSIS-ID PORT-ID PORT-DESC TTL SYS-

NAME
--------------------------------------------------------------------------------------------
-------

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
1/1/25 b8:d4:e7:40:6d:00 1/1/1 access1 120 ICX-
Core-1
1/1/26 b8:d4:e7:40:8e:00 1/1/1 access1 120 ICX-
Core-2
mgmt 00:23:89:bb:73:4a GigabitEthernet2/0/23 T13-6300-A-OOBM 120 P54-
OOBM-Fanout

n Question: What are the MAC addresses and system names that Access-1 is seeing from
the VSX cluster?
n Answer: Access-1 is seeing the true system MAC address and hostnames of each VSX
switch.
n Question: Why is the Chassis-ID different from the LACP System-ID?
n Answer: The VSX core consists of two independent control planes, with their own IP and
MAC addressing. They only share a common System-ID for Layer 2 protocols such as
LACP to make their partners believe they are a single system. LLDP is a discovery protocol
and does not require the use of a common System-ID, so each VSX switch uses its own sys-
tem MAC address and hostname for LLDP.

Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG) 45

 VSX LAG to the HPE Aruba Networking Mobility Controller (gateway)
Diagram

The mobility controller has been pre-configured in the lab with a LAG on its ports (0/0/1 and
0/0/2) to the core switches.
As an exercise, try configuring the VSX LAG (on Core-1 and Core-2) to the mobility controller on
your own.
Use these settings for the VSX LAG:
n Use LAG ID 5.
n Use interface 1/1/5 on both Core-1 and Core-2 for the VSX LAG.

46 Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG)

 n Define an MTU of 9100 bytes (to support GRE tunnels in the Dynamic Segmentation lab).
n Define a VLAN trunk, allowing all VLANs.
In case you are unsure, here are the configurations:
ICX-Core-1(config)# interface lag 5 multi-chassis
ICX-Core-1(config-lag-if)# vlan trunk allowed all
ICX-Core-1(config-lag-if)# no shutdown
ICX-Core-1(config-lag-if)# lacp mode active
ICX-Core-1(config-lag-if)# exit
ICX-Core-1(config)#
ICX-Core-1(config)# interface 1/1/5
ICX-Core-1(config-if)# mtu 9100
ICX-Core-1(config-if)# lag 5
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# exit

ICX-Core-2(config)# interface lag 5 multi-chassis

ICX-Core-2(config-lag-if)# no shutdown
ICX-Core-2(config-lag-if)# exit

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
ICX-Core-2(config)#
ICX-Core-2(config)# interface 1/1/5
ICX-Core-2(config-if)# mtu 9100
ICX-Core-2(config-if)# lag 5
ICX-Core-2(config-if)# no shutdown
ICX-Core-2(config-if)# exit

23. Verify connectivity, that the LACP state is up for 1/1/5, and check that VLANs are allowed on
Core-1 and its VSX peer.
ICX-Core-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 ALFNCD 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 5 1 ALFNCD 02:01:00:00:01:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up

Partner details of all interfaces:

Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG) 47

 ----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
----------------------------------------------------------------------------------
1/1/1 lag1(mc) 26 1 ALFNCD 10:4f:58:f6:e3:80 65534 255
1/1/2 lag2(mc) 26 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc) 2 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256

ICX-Core-1(config)# show lacp interfaces vsx-peer

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 1001 1 ALFNCD 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 1002 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 1005 1 ALFNCD 02:01:00:00:01:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up

Partner details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 27 1 ALFNCD 10:4f:58:f6:e3:80 65534 255
1/1/2 lag2(mc) 27 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc) 3 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256

24. Optional: Log in to the CLI of the mobility controller/gateway (admin/aruba123). Examine port
channel 1's status (the LAG). (This was pre-configured for you at the start-of-class lab state for
this course.)
(icx-T13-mc1) *[mynode] # show interface port-channel 1

Port-Channel 1 is administratively up, Link is up, Line protocol is up

Hardware is Port-Channel, address is 20:4C:03:B1:D4:2A (bia 20:4C:03:B1:D4:2A)
Description: Link Aggregate (LACP)
Spanning Tree is disabled
Switchport priority: 0

48 Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG)

 MTU: 1500 bytes
Member port(s):
GE 0/0/1, Admin is up, Link is up, Line protocol is up
GE 0/0/2, Admin is up, Link is up, Line protocol is up
Speed :2 Gbps
Interface index: 8194
Last clearing of "show interface" counters 17 day 5 hr 25 min 18 sec
link status last changed 0 day 0 hr 5 min 39 sec
0 packets input, 110541 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input error bytes, 0 CRC, 0 frame
0 multicast, 0 unicast
56 packets output, 13191 bytes
0 output errors bytes, 0 deferred
0 collisions, 0 late collisions, 0 throttles
Port-Channel 1 is TRUSTED

Statistics for member port: GE 0/0/1

0 packets input, 69577 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input error bytes, 0 CRC, 0 frame

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
0 multicast, 0 unicast
32 packets output, 7065 bytes
0 output errors bytes, 0 deferred
0 collisions, 0 late collisions, 0 throttles
Statistics for member port: GE 0/0/2
0 packets input, 40964 bytes
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input error bytes, 0 CRC, 0 frame
0 multicast, 0 unicast
24 packets output, 6126 bytes
0 output errors bytes, 0 deferred
0 collisions, 0 late collisions, 0 throttles
n Question: What is the MTU on the gateway interfaces?
n Answer: The MTU is 1500 bytes. In a production network, you want this to match what is
on the VSX cluster switches, which is 9100 bytes. For this lab, you can leave it as it is.

Task 2-5: VSX Layer 2—VSX link aggregation (VSX LAG) 49

Task 2-6: VSX Layer 3 active gateway
Lab diagram

Objectives
n Understand the active gateway principle.
n Configure an active gateway.
n Verify the active gateway configuration.
n Verify the active gateway operation on a client.
n Set up an active gateway in VLAN 1 to the Mobility Controller.
n Configure an IP helper on the VSX core.
Understand the active gateway principle
In a VSX system, an active gateway provides redundant default gateway functionality for the end hosts.
The default gateway of the end host is automatically handled by both of the VSX systems.
This functionality is similar to VRRP, but VRRP only operates in an active/standby mode, using a
keepalive between the active and the standby system to detect the state. To keep the ARP entry of the
default gateway valid in case of a VRRP failover, VRRP uses a common MAC address between the
VRRP hosts. In the case of VRRP, this is based on the VRRP VRID value.
The active gateway feature also uses a virtual MAC address to ensure the ARP entry on the end hosts
is stable (the same in case of a switchover). However, the virtual MAC is set by the administrator in the
VSX setup; it is not controlled by some other ID, as in VRRP. The virtual MAC can be reused over mul-

50 Task 2-6: VSX Layer 3 active gateway

tiple VLANs, since the MAC address is only used within the VLAN and only needs to be unique in each
VLAN. In the VSX setup, the virtual MAC and active gateway IP addresses are programmed in the hard-
ware tables of both VSX switches, which results in an active/active setup.
Since the peer switches are typically connected with a VSX LAG, the peer switch load distribution
decides if traffic is sent to VSX member 1 or member 2. Whichever switch receives the traffic first will
be the switch that handles the traffic and forwards it onward. Therefore, it does not matter whether
VSX member 1 or member 2 receives the traffic first, since either of them can route the traffic else-
where.
In case of a link failure, the peer switch will switch the traffic over to the other link in the VSX LAG, so
the other VSX member will route all the traffic until its mate repairs its link in the VSX LAG.
Each VSX member still has a local IP address, besides the active gateway IP address, in the VLAN. The
same active gateway IP address and active gateway MAC address must be configured on both VSX
members, however.

Steps
Configuration

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
For each VLAN connected to end hosts, the administrator must set an active gateway IP and virtual
MAC addresses on both VSX members.
This will be the IP address that must be used by the end hosts as the default gateway IP address.
Core-1: VLAN 11
1. Open a console connection to Core-1 and enter configuration mode.
2. Enter the interface VLAN 11 context and configure the local switch IP address (10.1.11.2 for
Core-1). Enable L3 counters; this will provide IP statistics on the interface.
ICX-Core-1(config)# interface vlan 11
ICX-Core-1(config-if-vlan)# ip address 10.1.11.2/24
ICX-Core-1(config-if-vlan)# l3-counters

3. Enable the vsx-sync feature for this L3 VLAN interface.

ICX-Core-1(config-if-vlan)# vsx-sync active-gateways policies

Active gateway and access policies configurations applied to the interface VLAN will
be synced between the VSX pair. AOS-CX policies will be explained later in the lab.

4. Configure the active gateway IP (10.1.11.1) and virtual MAC address (02:02:00:00:01:00). This
IP address is what end hosts need to have defined as the default gateway address for the VLAN.
ICX-Core-1(config-if-vlan)# active-gateway ip 10.1.11.1 mac 02:02:00:00:01:00
ICX-Core-1(config-if-vlan)# exit

5. Verify the configuration for interface VLAN 1. Output example:

Task 2-6: VSX Layer 3 active gateway 51

 ICX-Core-1(config)# show interface vlan11

Interface vlan11 is up
Admin state is up
Description:
Hardware: Ethernet, MAC Address: b8:d4:e7:40:6d:00
IPv4 address 10.1.11.2/24
active-gateway L3 source mac b8:d4:e7:40:6d:00
active-gateway ip mac 02:02:00:00:01:00
active-gateway ip 10.1.11.1
L3 Counters: Rx Enabled, Tx Enabled

Statistic RX TX Total
---------------- -------------------- -------------------- --------------------
L3 Packets 0 0 0
L3 Bytes 0 0 0

Core-2: VLAN 11
6. Open a console connection to Core-2 and enter configuration mode.
7. Enter the interface VLAN 11 context, configure the Core-2 switch IP address, and enable L3
counters.
ICX-Core-2(config)# interface vlan 11
ICX-Core-2(config-if-vlan)# ip address 10.1.11.3/24
ICX-Core-2(config-if-vlan)# l3-counters

8. Review the current configuration of the VLAN 11 interface. Verify that vsx-sync has completed
the active gateway configuration synchronization on Core-2.
ICX-Core-2(config-if-vlan)# show run current-context
interface vlan11
vsx-sync active-gateways policies
ip address 10.1.11.3/24
active-gateway ip mac 02:02:00:00:12:00
active-gateway ip 10.1.11.1
l3-counters

9. Verify the operational status. Output example:

ICX-Core-2(config-if-vlan)# exit
ICX-Core-2(config)# show interface vlan11

Interface vlan11 is up
Admin state is up
Description:
Hardware: Ethernet, MAC Address: b8:d4:e7:40:8e:00
IPv4 address 10.1.11.3/24
active-gateway L3 source mac b8:d4:e7:40:8e:00
active-gateway ip mac 02:02:00:00:01:00
active-gateway ip 10.1.11.1
L3 Counters: Rx Enabled, Tx Enabled

52 Task 2-6: VSX Layer 3 active gateway

 Statistic RX TX Total
---------------- -------------------- -------------------- --------------------
L3 Packets 0 0 0
L3 Bytes 0 0 0

VLAN 12 active gateway configuration: Core-1

10. Configure VLAN 12 on Core-1, assigning an IP address of 10.1.12.2.
ICX-Core-1(config)# interface vlan 12
ICX-Core-1(config-if-vlan)# ip address 10.1.12.2/24
ICX-Core-1(config-if-vlan)# l3-counters
ICX-Core-1(config-if-vlan)# vsx-sync active-gateways policies
ICX-Core-1(config-if-vlan)# active-gateway ip 10.1.12.1 mac 02:02:00:00:01:00
ICX-Core-1(config-if-vlan)# exit

VLAN 12 active gateway configuration: Core-2

11. Configure VLAN 12 on Core-2, assigning an IP address of 10.1.12.3.
ICX-Core-2(config)# interface vlan 12
ICX-Core-2(config-if-vlan)# ip address 10.1.12.3/24
ICX-Core-2(config-if-vlan)# l3-counters

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
ICX-Core-2(config-if-vlan)# exit

VLAN 1 active gateway: Core-1

Set up VLAN 1's active gateway. This will be used for communication to the Mobility Controller
and ensure the mobility controller has a redundant default gateway.
12. On Core-1, configure the VLAN 1 active gateway.
ICX-Core-1(config)# interface vlan1
ICX-Core-1(config-if-vlan)# vsx-sync active-gateways policies
ICX-Core-1(config-if-vlan)# active-gateway ip mac 02:02:00:00:01:00
ICX-Core-1(config-if-vlan)# active-gateway ip 10.1.1.1
ICX-Core-1(config-if-vlan)# exit

Core-2 has been configured with an IP address already. Adding vsx-sync to the com-
mand will ensure the active gateway configuration is set on Core-2 as well.

13. View the configuration of Core-2 from Core-1.

ICX-Core-1(config)# show run interface vlan1 vsx-peer
interface vlan 1
vsx-sync active-gateways policies
ip address 10.1.1.3/24
active-gateway ip mac 02:02:00:00:01:00
active-gateway ip 10.1.1.1
exit

Task 2-6: VSX Layer 3 active gateway 53

 Configure DHCP relay on the VSX core
In this lab environment, DHCP scopes have been configured on the mobility controller (gateway).
On the VSX core, the DHCP relay, also known as "IP helper," will be configured to point to the
gateway as the DHCP server when receiving DHCP client requests in VLANs 11 and 12.
Core-1
14. On Core-1, apply the ip helper-address command to VLAN 11. The MC (gateway) has IP
address 10.1.1.6.
ICX-Core-1(config)# interface vlan11
ICX-Core-1(config-if-vlan)# ip helper-address 10.1.1.6
ICX-Core-1(config-if-vlan)# exit

15. Repeat the configuration for VLAN 12.

ICX-Core-1(config)# interface vlan12
ICX-Core-1(config-if-vlan)# ip helper-address 10.1.1.6
ICX-Core-1(config-if-vlan)# exit

16. Verify the IP helper configuration was synchronized to Core-2.

ICX-Core-1(config)# show running-config interface vlan11 vsx-peer
interface vlan11
vsx-sync active-gateways policies
ip address 10.1.11.3/24
active-gateway ip mac 02:02:00:00:12:00
active-gateway ip 10.1.11.1
l3-counters
ip helper-address 10.1.1.6
exit

Verify the active gateway operation on the client PC

Access-1
17. Open a terminal connection to Access-1 and enter the configuration context.
18. Assign interface 1/1/3 (connected to the client PC3) to VLAN 11.
ICX-Access-1(config)# vlan 11
ICX-Access-1(config-vlan-11)# exit
ICX-Access-1(config)# interface 1/1/3
ICX-Access-1(config-if)# vlan access 11
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# exit

19. Open a desktop connection to PC3 (connected to Access-1 port 1/1/3). Enable the LAB NIC –
6300-A Port 1 interface (if it is not already enabled).

54 Task 2-6: VSX Layer 3 active gateway

 20. On the client PC3, renew your IP address. Open a command prompt (cmd.exe) with administrator
privileges, then release and renew the IP address, entering the ipconfig /release command fol-
lowed by ipconfig /renew.

TIP: You may also choose to disable and enable the Lab NIC interface in the Network
Connections list.
Select Start > Settings > Network & Internet > Ethernet > Change adapter
options.
Right-click Lab NIC and select Disable.

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
Wait a few moments, then right-click Lab NIC and select Enable.

In the rest of the course labs, this procedure is referred to as "bounce the Lab NIC"
(disable and enable it). The IP address can be shown by right-clicking Lab NIC and
selecting Status > Details.

21. Verify that PC3 received an IP address by executing ipconfig /all from the command prompt
(cmd.exe).
n Question: What are the IP address and MAC address of the Lab NIC?
n Answer: The IP address should begin with 10.1.11 and probably start at 50 for a host
address in the DHCP pool.

Task 2-6: VSX Layer 3 active gateway 55

 22. From the Access-1 console, examine the MAC address table for VLAN 11. The MAC address of
the client should now be listed on interface 1/1/3.
n Question: Can you explain the three MAC addresses that have been learned on LAG 255?
n Answer: They are for both core switches, the system MAC address, and the active gate-
way MAC.
ICX-Access-1(config)# show mac-address-table vlan 11
MAC age-time : 300 seconds
Number of MAC addresses : 4

MAC Address VLAN Type Port

--------------------------------------------------------------
90:20:c2:bc:97:00 11 dynamic lag255
90:20:c2:bc:17:00 11 dynamic lag255
00:50:56:b1:7a:37 11 dynamic 1/1/3
02:02:00:00:12:00 11 dynamic lag255

23. On the client PC3, verify the system has received an IP address from the VLAN 11 IP range
(10.1.11.0/24). In a command prompt (cmd.exe), enter ipconfig.
C:\Users\student> ipconfig

Windows IP Configuration

Ethernet adapter Do NOT Touch!:

<output omitted>

Ethernet adapter Lab NIC:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.11.51
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.11.1

Ethernet adapter OOBM:

<output omitted>

24. Verify the IP path with a traceroute to the MC (10.1.1.6).

C:\Users\student> tracert -d 10.1.1.6

Tracing route to 10.12.1.6 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 10.1.11.2

2 <1 ms <1 ms <1 ms 10.1.1.6

Trace complete.

56 Task 2-6: VSX Layer 3 active gateway

 C:\Users\student>
n Question: The client PC default gateway is 10.1.11.1. Why does the traceroute show
10.1.11.2 or 10.1.11.3?
n Answer: The core switch that receives the request (either Core-1 or Core-2) will respond
with its local interface IP address.
25. Optional step: Verify the ARP entry on PC3. In a command prompt (cmd.exe), enter arp -a. The
IP address of the default gateway (10.1.11.1) should be listed with the active gateway MAC
address. This confirms that the configured VSX active gateway MAC is learned by the client's sys-
tems.
<output omitted>
Interface: 10.12.11.51 --- 0x10
internet Address Physical Address Type
10.1.11.1 02-02-00-00-12-00 dynamic
10.1.11.2 90-20-c2-bc-17-00 dynamic
10.1.11.3 90-20-c2-bc-97-00 dynamic
10.1.11.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static

Lab 2: Configuring HPE Aruba

224.0.0.251 01-00-5e-00-00-fb static

Networking Virtual Switching

224.0.0.252 01-00-5e-00-00-fc static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static
<output omitted>

Verify DHCP relay for PC4—the client connected to Access-2

Access-2
26. Open a terminal connection to Access-2 and enter the configuration context.
27. Assign interface 1/1/4 (connected to the client PC4) to VLAN 12.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# vlan access 12
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit

28. On PC4 (connected to Access-2 port 1/1/4), renew your IP address. Open a command prompt
(cmd.exe) with administrator privileges, then release and renew the IP address, entering the
ipconfig /release and ipconfig /renew commands or by bouncing the Lab NIC network con-
nection (disable/enable).
C:\Users\student> ipconfig

<output omitted>

Ethernet adapter Lab NIC - 6300-B Port 4:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.12.51

Task 2-6: VSX Layer 3 active gateway 57

 Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.12.1

If PC4 did not get an IP address in the 10.1.12.0/24 range, review your IP helper and VLAN
configuration.

Task 2-7: VSX failover test (optional)

This task is optional and can be done if time permits. Check with your instructor. If you skip this task,
you can proceed to the next task.

Lab diagram

Objectives
n Verify L3 inter-VLAN traffic failover in a link falure.
n Manage link failure of a single ISL port, without causing a split-brain.

58 Task 2-7: VSX failover test (optional)

 Steps
Verify L3 inter-VLAN traffic failover in a link failure
In this section, a ping will be done from PC3 (connected to Access-1 1/1/3: VLAN 11) to the MC (gate-
way) (connected to VLAN 1).
While the ping is running, Access-1 uplinks will be disabled and re-enabled, one by one.
The result should be that the ping has only a minor interruption.
1. Open a session to PC3. Open a command prompt and start a continuous ping to the MC
(10.1.1.6).
C:\Users\student> ping 10.1.1.6 -t

Pinging 10.1.1.6 with 32 bytes of data:

Reply from 10.1.1.6: bytes=32 time<1ms TTL=63
Reply from 10.1.1.6: bytes=32 time<1ms TTL=63
...

2. Open a terminal connection to Access-1, clear the interface statistics, and then check the inter-

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
face statistics for the uplink LAG.
The ping from PC3 sends an echo request, and the MC will send an echo reply back. This is why
the output will show both RX and TX statistics. The distribution of traffic depends on the hashing
algorithm.
ICX-Access-1# clear interface statistics

ICX-Access-1# show interface lag255 statistics

Output example for the statistics:

------------------------------------------------------------------------------------------------------------------
Interface RX Bytes RX Packets TX Bytes TX Packets RX Broadcast RX Multicast TX Broadcast TX Multicast
------------------------------------------------------------------------------------------------------------------
1/1/25 - lag255 2279 17 2811 20 3 1 0 7
1/1/26 - lag255 1755 18 1148 14 3 1 0 0
lag255 4034 35 3959 34 6 2 0 7

3. On Access-1, enter configuration mode and disable uplink 1.

ICX-Access-1(config)# interface 1/1/25
ICX-Access-1(config-if)# shutdown

4. On PC3, check that the ping operation is still successful. It is normal to either have no packet loss
or one missed ping, since the ping is only performed once per second.
5. On Access-1, enable uplink 1, verifying the LACP state is operational again.
ICX-Access-1(config-if)# no shutdown

An example of a link that has not yet completed the LACP negotiation state (this output would
only be seen a few seconds after enabling the interface) is as follows.

Task 2-7: VSX failover test (optional) 59

 ICX-Access-1(config-if)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
------------------------------------------------------------------------------
1/1/25 lag255 26 1 ALFO 88:3a:30:97:b6:00 65534 256 lacp-block
1/1/26 lag255 27 1 ALFNCD 88:3a:30:97:b6:00 65534 256 up

Partner details of all interfaces:

------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
------------------------------------------------------------------------------
1/1/25 lag255 2 1 ALFO 02:01:00:00:01:00 65534 2
1/1/26 lag255 1002 1 ALFNCD 02:01:00:00:01:00 65534 2

An example of an operational link is as follows:

ICX-Access-1(config-if)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
------------------------------------------------------------------------------
1/1/25 lag255 26 1 ALFNCD 88:3a:30:97:b6:00 65534 256 up
1/1/26 lag255 27 1 ALFNCD 88:3a:30:97:b6:00 65534 256 up

Partner details of all interfaces:

------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
------------------------------------------------------------------------------

60 Task 2-7: VSX failover test (optional)

 1/1/25 lag255 2 1 ALFNCD 02:01:00:00:12:00 65534 2
1/1/26 lag255 1002 1 ALFNCD 02:01:00:00:12:00 65534 2
ICX-Access-1(config-if)#

6. On Access-1, disable uplink 2.

ICX-Access-1(config)# interface 1/1/26
ICX-Access-1(config-if)# shutdown

7. On PC3, check that the ping operation is still successful. It is normal to either have no packet loss
or one missed ping, since the ping is only performed once per second.
8. On Access-1, enable uplink 2, verifying it is operational again (check for the up state in the LACP
output).
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# exit
ICX-Access-1(config-if)# show lacp interfaces

You may need to wait a few seconds and repeat the show lacp interfaces command
to see the up state.

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
You may leave the continuous ping active on PC3; it will be used in the next activity.

This has demonstrated a link failure and traffic failover.

Task 2-7: VSX failover test (optional) 61

Link failure of a single ISL port
Lab Diagram

In this section, traffic will be forced over the ISL LAG and an ISL member port failure will be tested.
The traffic will be forced over the ISL link by:
n On Access-1, disabling uplink 2 so Access-1 will send all traffic to Core-1.
n On Core-1, disabling port 1/1/5 so the MC will be forced to send all traffic to Core-2.
This way, the traffic will no longer use the local path on each core switch, but it must take the ISL path
to reach the destination.
Once this has been done, one of the ISL member ports will be disabled to verify the ISL LAG failover. Do
not shutdown the entire ISL at this point; that will result in a split-brain scenario, which will be tested in
the following task.
Prepare the setup
1. On Access-1, disable the uplink to Core-2.
ICX-Access-1(config)# interface 1/1/26

62 Task 2-7: VSX failover test (optional)

 ICX-Access-1(config-if)# shutdown

2. On Core-1, disable the local link to the MC.

ICX-Core-1(config)# interface 1/1/5
ICX-Core-1(config-if)# shutdown
ICX-Core-1(config-if)# exit

3. On PC3, verify that the ping to the MC is still working fine.

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
Test the ISL LAG failover
Now the ISL LAG failover can be tested.
1. On Core-1, disable ISL member port 1 (1/1/46).
ICX-Core-1(config)# interface 1/1/46
ICX-Core-1(config-if)# shutdown

2. On PC3, verify that the ping is still operating fine.

3. On Core-1, enable ISL member port 1 (1/1/46) and wait a few seconds. Next, verify that LAG
256 is up again.
ICX-Core-1(config-if)# no shutdown

ICX-Core-1(config-if)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
----------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 ALFNCD 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:01:00 65534 2 up

Task 2-7: VSX failover test (optional) 63

 1/1/5 lag5(mc) down
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up

Partner details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
----------------------------------------------------------------------------------
1/1/1 lag1(mc) 26 1 ALFNCD 10:4f:58:f6:e3:80 65534 255
1/1/2 lag2(mc) 26 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc)
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256

4. Next, disable ISL member port 2 (1/1/47).

ICX-Core-1(config-if)# interface 1/1/47
ICX-Core-1(config-if)# shutdown

5. On PC3, verify that the ping is still operating fine.

6. On Core-1, enable ISL member port 2 again and verify the status.
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# exit
ICX-Core-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
----------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 ALFNCD 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) down
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up

Partner details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key

64 Task 2-7: VSX failover test (optional)

 ----------------------------------------------------------------------------------
1/1/1 lag1(mc) 26 1 ALFNCD 10:4f:58:f6:e3:80 65534 255
1/1/2 lag2(mc) 26 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc)
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256

7. On PC3, verify that the ping is still operating fine.

This has demonstrated the ISL LAG member port failover.
Restore the uplink connections on Access-1 and Core-1
1. On Access-1, restore the uplink to Core-2 (1/1/26); the session is probably still in the interface
1/1/26 context. Verify that the LAG is operational.
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# exit

ICX-Access-1(config)# show lacp interfaces

State abbreviations :

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
----------------------------------------------------------------------------------
1/1/25 lag255 26 1 ALFNCD 10:4f:58:f6:e3:80 65534 255 up
1/1/26 lag255 27 1 ALFNCD 10:4f:58:f6:e3:80 65534 255 up

Partner details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
----------------------------------------------------------------------------------
1/1/25 lag255 1 1 ALFNCD 02:01:00:00:01:00 65534 1
1/1/26 lag255 1001 1 ALFNCD 02:01:00:00:01:00 65534 1

2. On Core-1, restore the link to the MC (port 1/1/5).

ICX-Core-1(config)# int 1/1/5
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# exit

3. On Core-1, the LACP states for all LAGs are up.

Task 2-7: VSX failover test (optional) 65

 ICX-Core-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 ALFNCD 02:01:00:00:12:00 65534 1 up
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:12:00 65534 2 up
1/1/5 lag5(mc) 5 1 ALFNCD 02:01:00:00:12:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD 90:20:c2:bc:17:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD 90:20:c2:bc:17:00 65534 256 up

This concludes the ISL LAG failover test and the optional task. Continue with the remainder of this lab.

66 Task 2-7: VSX failover test (optional)

 Task 2-8: VSX split-brain handling
Lab diagram

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
Objectives
n In a split-brain scenario, review the results, output, and logs.
n Recover from a split-brain scenario.
n Verify the link-up delay timer is functioning.
Handling a split-brain scenario
Primary ISL protection
The ISL between the VSX members should be primarily protected against link failures by using a LAG
of multiple member ports. This way, when a single port between the VSX members fails, it will have no
impact on the VSX functionality. Only the link capacity between the VSX members will be reduced.
Split-brain problem
However, in case all the members ports of the ISL link are down, there will be no VSX state and con-
figuration replication between the VSX members. So, the primary VSX member may have different
MAC/ARP entries compared to the secondary VSX member, and they will not be able to share the STP
state information between them.

Task 2-8: VSX split-brain handling 67

Solution
This scenario would lead to unpredictable results, so the solution will be to have the secondary node
disable its VSX LAG interfaces and any other interfaces that have VLANs enabled on them associated
with the VSX LAG interfaces. The result will be that only the primary node will still be on the network,
so the network will operate in a predictable way again.
The secondary node must have a means to detect that the primary node is still active. In case the
primary node suffers a complete power failure, the ISL link will also be down, but the secondary is sup-
posed to take over complete control. In this case, we want to have the secondary active on the network.
Only when the primary and the secondary nodes are online at the same time but not seeing each other
on the ISL link—but the keepalive is functioning—do we want to have the secondary disable (shut
down) its appropriate interfaces.
How: using keepalives
This can be achieved by configuring a keepalive between the primary and the secondary nodes. When
the ISL is down and the secondary still gets a response over the keepalive, the secondary knows both
are still online, and it will disable the VSX LAG interfaces.
In case the ISL goes down and the keepalive does not respond, the secondary knows the primary is no
longer online, so it will keep its VSX LAG interfaces up.

Steps
The keepalive has been configured as part of the basic VSX configuration task; in these steps, the con-
figuration is reviewed.
1. Open a console connection to Core-1. The keepalive is an IP connection between the Core-1 and
Core-2 switches. To make sure this connection is never in conflict or impacted by the normal rout-
ing table, a dedicated VRF is typically used.
2. Review routed port 1/1/45, a dedicated link that was used for the VSX keepalive.
Core-1
ICX-Core-1# show running-config interface 1/1/45
interface 1/1/45
no shutdown
vrf attach KA
ip address 192.168.0.0/31
exit

3. Review the VSX running configuration.

ICX-Core-1# show running-config vsx
vsx
system-mac 02:01:00:00:01:00
inter-switch-link lag 256
role primary

68 Task 2-8: VSX split-brain handling

 keepalive peer 192.168.0.1 source 192.168.0.0 vrf KA
interface lag 256
description ISL link
no shutdown
no routing
vlan trunk native 1 tag
vlan trunk allowed all
lacp mode active

<output omitted..>

4. Review the VSX keepalive configuration.

ICX-Core-1# show vsx configuration keepalive
Keepalive Interface : 1/1/45
Keepalive VRF : KA
Source IP Address : 192.168.0.0
Peer IP Address : 192.168.0.1
UDP Port : 7678
Hello Interval : 1 Seconds
Dead Interval : 3 Seconds

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
5. Verify the keepalive operational status (Keepalive-Established) and the peer role (on Core-1,
the peer should be secondary).
ICX-Core-1# show vsx status keepalive
Keepalive State : Keepalive-Established
Last Established : Mon Apr 23 19:15:09 2024
Last Failed : Mon Apr 23 17:56:15 2024
Peer System Id : 02:01:00:00:01:00
Peer Device Role : secondary

Keepalive Counters
Keepalive Packets Tx : 352151
Keepalive Packets Rx : 352020
Keepalive Timeouts : 0
Keepalive Packets Dropped : 0

Core-2
6. Open a console connection to Core-2, reviewing the VSX keepalive with the same commands.
show running-config interface 1/1/45
show running-config vsx
show vsx configuration keepalive
show vsx status keepalive

Task 2-8: VSX split-brain handling 69

Force a split brain
Core-1
1. On Core-1, enter configuration mode and disable LAG 256 (the LAG used for the VSX ISL).
ICX-Core-1(config)# interface lag 256
ICX-Core-1(config-lag-if)# shutdown
ICX-Core-1(config-lag-if)# exit

2. On Core-1, review the VSX status.

ICX-Core-1(config)# show vsx status
VSX Operational State
---------------------
ISL channel : Out-Of-Sync
ISL mgmt channel : inter_switch_link_down
Config Sync Status : out-of-sync
NAE : peer_unreachable
HTTPS Server : peer_unreachable

Attribute Local Peer

------------ -------- --------
ISL link lag256
ISL version 2
System MAC 02:01:00:00:01:00 02:01:00:00:01:00
Platform 8325
Software Version GL.10.13.1000
Device Role primary

3. Review the keepalive status.

ICX-Core-1(config)# show vsx status keepalive
Keepalive State : Keepalive-Established
Last Established : Fri Dec 27 18:07:37 2024
Last Failed : Mon Apr 23 17:56:15 2024
Peer System Id : 02:01:00:00:01:00
Peer Device Role :

Keepalive Counters
Keepalive Packets Tx : 352501
Keepalive Packets Rx : 352370
Keepalive Timeouts : 0
Keepalive Packets Dropped : 0
n Question: Why are there no packets dropped at this point?
n Answer: Only the ISL is down at this point. The keepalive operates just fine, so no
keepalive packets are dropped.

70 Task 2-8: VSX split-brain handling

 4. On Core-1, notice that the vsx-peer commands are no longer available, since these commands
use the ISL link.
ICX-Core-1(config)# show vsx status keepalive vsx-peer
VSX Peer not reachable
ICX-Core-1(config)#

Core-2—split-system detected
Diagram

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
5. On Core-2, verify that the keepalive has detected that the primary (Core-1) is still responding
(established).
ICX-Core-2# show vsx status keepalive
Keepalive State : Keepalive-Established
Last Established : Fri Dec 27 18:08:18 2024
Last Failed : Mon Apr 23 17:56:56 2024
Peer System Id : 02:01:00:00:01:00
Peer Device Role :

Keepalive Counters
Keepalive Packets Tx : 352481
Keepalive Packets Rx : 352482
Keepalive Timeouts : 0
Keepalive Packets Dropped : 0

6. Check the log buffer (-r reverse, -n number of lines) and look for lines containing vsx. This will
show an entry that the ISL link is down, but the keepalive has been established. This indicates
the split-system scenario.

Task 2-8: VSX split-brain handling 71

 ICX-Core-2# show logging -r -n 30 | include vsx
2024-04-04T08:35:36.312254+00:00 ICX-Core-2 hpe-vsxd[2167]: Event|7014|LOG_
INFO|AMM|1/1|VSX 2 state local down, remote down
2024-04-04T08:35:36.306706+00:00 ICX-Core-2 hpe-vsxd[2167]: Event|7014|LOG_
INFO|AMM|1/1|VSX 5 state local down, remote down
2024-04-04T08:35:36.257432+00:00 ICX-Core-2 hpe-vsxd[2167]: Event|7020|LOG_
INFO|AMM|1/1|ISL out-of-sync and keepalive is in established2024-04-
04T08:35:36.254765+00:00 ICX-Core-2 hpe-vsxkad[8376]: Event|7006|LOG_
INFO|AMM|1/1|VSX Keepalive succeeded
2024-04-04T08:35:35.594193+00:00 ICX-Core-2 vsx-syncd[8800]: Event|7602|LOG_
INFO|AMM|-|Configuration sync update : VSX Inter-Switch-Link is down.
2024-04-04T08:35:35.575153+00:00 ICX-Core-2 hpe-vsxd[2167]: Event|7011|LOG_
INFO|AMM|1/1|VSX 5 state local up, remote down
2024-04-04T08:35:35.570479+00:00 ICX-Core-2 hpe-vsxd[2167]: Event|7011|LOG_
INFO|AMM|1/1|VSX 2 state local up, remote down
2024-04-04T08:35:35.566540+00:00 ICX-Core-2 hpe-vsxd[2167]: Event|7014|LOG_
INFO|AMM|1/1|VSX 1 state local down, remote down
2024-04-04T08:35:35.559596+00:00 ICX-Core-2 hpe-vsxd[2167]: Event|7004|LOG_
ERR|AMM|1/1|VSX ISL port lag256 is Out-Of-Sync with the peer: link is down
2024-04-04T08:35:35.559336+00:00 ICX-Core-2 hpe-vsxd[2167]: Event|7015|LOG_
INFO|AMM|1/1|VSX ISL sliding window parameters are reset.
2024-04-04T08:35:35.559097+00:00 ICX-Core-2 hpe-vsxd[2167]: Event|7001|LOG_
INFO|AMM|1/1|VSX ISL port lag256 is down
ICX-Core-2#

Due to this condition, Core-2 has disabled its local VSX LAG interfaces.
ICX-Core-2# show interface brief
---------------------------------------------------------------------------------
Port Native Mode Type Enabled Status Reason
Speed
VLAN
(Mb/s)
---------------------------------------------------------------------------------
1/1/1 1 trunk SFP+DAC1 yes down Disabled by VSX --
1/1/2 1 trunk SFP+DAC1 yes down Disabled by VSX --
1/1/3 -- routed -- no down No XCVR installed --
1/1/4 -- routed SFP-BT no down Administratively down --
1/1/5 1 trunk SFP-BT yes down Disabled by VSX --
1/1/6 -- routed -- no down No XCVR installed --
<output omitted>

vlan1 -- -- yes down Disabled by VSX --

vlan11 -- -- yes down Disabled by VSX --
vlan12 -- -- yes down Disabled by VSX --
<output omitted>

And the VSX state will show as Split-System-Secondary.

72 Task 2-8: VSX split-brain handling

 ICX-Core-2# show vsx brief
ISL State : Out-Of-Sync
Device State : Split-System-Secondary
Keepalive State : Keepalive-Established
Device Role : secondary
Number of Multi-chassis LAG interfaces : 3

Split-brain recovery: linkup delay

When the ISL gets restored, the secondary node will automatically re-enable the disabled interfaces
after it has completed the VSX hardware table synchronization.
To provide enough time to synchronize all the tables and allow the secondary node time to learn routes
from possible OSPF or BGP peers, VSX has a default linkup delay timer of 180 seconds (three minutes).
Verify this default behavior in the next steps.
Core-1
1. On Core-1, re-enable LAG 256 .
ICX-Core-1(config)# interface lag 256

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
ICX-Core-1(config-lag-if)# no shut
ICX-Core-1(config-lag-if)# exit

2. On Core-2, review the VSX and interface status.

ICX-Core-2# show vsx brief
ISL State : In-Sync
Device State : Sync-Secondary-Linkup-Delay
Keepalive State : Keepalive-Established
Device Role : secondary
Number of Multi-chassis LAG interfaces : 3

ICX-Core-2# show interface brief

---------------------------------------------------------------------------------
Port Native Mode Type Enabled Status Reason
Speed
VLAN
(Mb/s)
---------------------------------------------------------------------------------
1/1/1 1 trunk SFP+DAC1 yes down Disabled by VSX --
1/1/2 1 trunk SFP+DAC1 yes down Disabled by VSX --
1/1/3 -- routed -- no down No XCVR installed --
<output omitted>

It may take up to three minutes before the VSX LAG interfaces are re-enabled. Wait for the inter-
faces to come up before continuing with the lab.

Task 2-8: VSX split-brain handling 73

 When the two switches have completed the synchronization of the forwarding tables
before the timer expires, the interfaces will be re-enabled. This is why it will not actu-
ally take three minutes in the lab, but typically less than a minute.
It is possible for the administrator to manually set the linkup delay timer. This may be
useful for very large deployments, when many table entries need to be synchronized
between the primary and secondary nodes. Consult the Virtual Switching Extension
(VSX) Guide for more information.

Task 2-9: Finalize the configuration for the upcoming labs

Lab diagram

Objectives
In this task, you will complete the IP configuration to reach the ClearPass server. This will be required in
future labs. The ClearPass server is reachable via the Router-A device that is connected to the Core-1
port 1/1/7. In this task, port 1/1/7 will be enabled, an IP address will be assigned, and a static route will
be set for the ClearPass IP subnet. Core-2 will be configured with a static route to the ClearPass server
via Core-1.
You will also configure DNS resolution and NTP on all four switches.
The last step will be to save a new checkpoint, so you can revert to this configuration from later labs.

74 Task 2-9: Finalize the configuration for the upcoming labs

 Steps
Router-A
1. Access Router-A's console. Log in with the following credentials:
a. Username: admin
b. Password: aruba123
2. Verify connectivity to the ClearPass and NTP servers.
ICX-RouterA# ping 10.254.1.23
PING 10.254.1.23 (10.254.1.23) 100(128) bytes of data.
108 bytes from 10.254.1.23: icmp_seq=1 ttl=64 time=1.30 ms
108 bytes from 10.254.1.23: icmp_seq=2 ttl=64 time=2.20 ms
108 bytes from 10.254.1.23: icmp_seq=3 ttl=64 time=1.79 ms
108 bytes from 10.254.1.23: icmp_seq=4 ttl=64 time=2.08 ms
108 bytes from 10.254.1.23: icmp_seq=5 ttl=64 time=1.89 ms

--- 10.254.1.23 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4005ms

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
rtt min/avg/max/mdev = 1.296/1.851/2.200/0.311 ms

ICX-RouterA# ping 10.254.1.21

PING 10.254.1.21 (10.254.1.21) 100(128) bytes of data.
108 bytes from 10.254.1.21: icmp_seq=1 ttl=128 time=1.39 ms
108 bytes from 10.254.1.21: icmp_seq=2 ttl=128 time=2.57 ms
108 bytes from 10.254.1.21: icmp_seq=3 ttl=128 time=2.08 ms
108 bytes from 10.254.1.21: icmp_seq=4 ttl=128 time=1.99 ms
108 bytes from 10.254.1.21: icmp_seq=5 ttl=128 time=2.12 ms

--- 10.254.1.21 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 1.390/2.028/2.567/0.376 ms

Core-1
3. Access the console on Core-1 and enter configuration mode.
4. Define the uplink connection to Router-A and configure a static route to reach the 10.254.1.0/24
subnet.
ICX-Core-1(config)# interface 1/1/7
ICX-Core-1(config-if)# ip address 10.255.101.2/24
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# exit
ICX-Core-1(config-)# ip route 10.254.1.0/24 10.255.101.11

5. Verify Core-1 can reach Router-A.

Task 2-9: Finalize the configuration for the upcoming labs 75

 ICX-Core-1(config)# ping 10.255.101.11
PING 10.255.101.11 (10.255.101.11) 100(128) bytes of data.
108 bytes from 10.255.101.11: icmp_seq=1 ttl=64 time=1.35 ms
108 bytes from 10.255.101.11: icmp_seq=2 ttl=64 time=2.02 ms
108 bytes from 10.255.101.11: icmp_seq=3 ttl=64 time=2.03 ms
108 bytes from 10.255.101.11: icmp_seq=4 ttl=64 time=2.06 ms
108 bytes from 10.255.101.11: icmp_seq=5 ttl=64 time=2.19 ms

--- 10.255.101.11 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 1.350/1.927/2.190/0.295 ms

6. Verify access to the ClearPass server (10.254.1.23) from VLAN 1.

ICX-Core-1(config)# ping 10.254.1.23 source vlan1
PING 10.254.1.23 (10.254.1.23) from 10.1.1.2 : 100(128) bytes of data.
108 bytes from 10.254.1.23: icmp_seq=1 ttl=61 time=4.72 ms
108 bytes from 10.254.1.23: icmp_seq=2 ttl=61 time=3.10 ms

If this ping is not successful, use the lab diagram to access Router-A's console. Enter
the boot system command, then y to reboot Router-A. Routers A, B, and C are virtual
machines running CX-OVA and may need a reboot at the beginning of this lab. Feel
free to contact your instructor with any questions.

Core-2
7. Access the console on Core-2 and enter configuration mode.
8. Configure a static route for the CPPM subnet to next-hop Core-1.
ICX-Core-2(config)# ip route 10.254.1.0/24 10.1.1.2

9. Verify connectivity to the ClearPass host, sourcing the ping from VLAN 1.
ICX-Core-2(config)# ping 10.254.1.23 source vlan1
PING 10.254.1.23 (10.254.1.23) from 10.1.1.3 : 100(128) bytes of data.
108 bytes from 10.254.1.23: icmp_seq=1 ttl=60 time=3.67 ms
108 bytes from 10.254.1.23: icmp_seq=2 ttl=60 time=3.26 ms
<output omitted>
ICX-Core-2(config)# end

Access-1
10. Access Access-1's console and enter configuration mode.
11. Define an IP address of 10.1.1.4/24 for VLAN 1.
ICX-Access-1(config)# interface vlan1
ICX-Access-1(config-if-vlan)# ip address 10.1.1.4/24
ICX-Access-1(config-if-vlan)# exit

12. Define a static route for 10.254.1.0/24, pointing to Core-1's IP address in VLAN 1.

76 Task 2-9: Finalize the configuration for the upcoming labs

 ICX-Access-1(config)# ip route 10.254.1.0/24 10.1.1.2

13. Verify connectivity to the ClearPass server.

ICX-Access-1(config)# ping 10.254.1.23
PING 10.254.1.23 (10.254.1.23) 100(128) bytes of data.
108 bytes from 10.254.1.23: icmp_seq=1 ttl=62 time=2.57 ms
108 bytes from 10.254.1.23: icmp_seq=2 ttl=62 time=2.44 ms
108 bytes from 10.254.1.23: icmp_seq=3 ttl=62 time=2.33 ms
108 bytes from 10.254.1.23: icmp_seq=4 ttl=62 time=2.15 ms
108 bytes from 10.254.1.23: icmp_seq=5 ttl=62 time=2.46 ms

--- 10.254.1.23 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 2.154/2.390/2.569/0.139 ms

Access-2
14. Access Access-2's console and enter configuration mode.
15. Define an IP address of 10.1.1.5/24 for VLAN 1.
ICX-Access-2(config)# interface vlan1

Lab 2: Configuring HPE Aruba

Networking Virtual Switching
ICX-Access-2(config-if-vlan)# ip address 10.1.1.5/24
ICX-Access-2(config-if-vlan)# exit

16. Define a static route for 10.254.1.0/24, pointing to Core-1's IP address in VLAN 1.
ICX-Access-2(config)# ip route 10.254.1.0/24 10.1.1.2

17. Verify connectivity to the ClearPass server.

ICX-Access-2(config)# ping 10.254.1.23
PING 10.254.1.23 (10.254.1.23) 100(128) bytes of data.
108 bytes from 10.254.1.23: icmp_seq=1 ttl=62 time=2.41 ms
108 bytes from 10.254.1.23: icmp_seq=2 ttl=62 time=2.44 ms
108 bytes from 10.254.1.23: icmp_seq=3 ttl=62 time=2.37 ms
108 bytes from 10.254.1.23: icmp_seq=4 ttl=62 time=2.69 ms
108 bytes from 10.254.1.23: icmp_seq=5 ttl=62 time=2.62 ms

--- 10.254.1.23 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 2.371/2.507/2.694/0.126 ms

All four switches

18. Add this configuration to all four switches. This will apply the correct time zone for the remote
lab, and it will increase the admin session timeout to 12 hours (not recommended in a production
environment).
ICX-switch1-4(config)# clock timezone us/eastern
ICX-switch1-4(config)# cli-session
ICX-switch1-4(config-cli-session)# timeout 43200
ICX-switch1-4(config-cli-session)# exit

Task 2-9: Finalize the configuration for the upcoming labs 77

 19. Define a DNS server (10.254.1.21) on all four switches.
ICX-switch1-4(config)# ip dns server-address 10.254.1.21

20. On all four switches, define 10.254.1.21 as an NTP server with iburst mode. Set the VRF to
default. Source NTP requests from VLAN 1, then globally enable NTP.
ICX-switch1-4(config)# ntp server 10.254.1.21 iburst
ICX-switch1-4(config)# ntp vrf default
ICX-switch1-4(config)# ip source-interface ntp interface vlan1
ICX-switch1-4(config)# ntp enable

21. On Core-1, verify your NTP configuration and receipt of NTP packets on all four switches.
ICX-switch1-4(config)# show ntp server
------------------------------------------------------
NTP SERVER KEYID MINPOLL MAXPOLL OPTION VER
------------------------------------------------------
10.254.1.21 -- 6 10 iburst 4
<output omitted>

ICX-switch1-4(config)# show ntp association

----------------------------------------------------------------------
ID NAME REMOTE REF-ID ST LAST POLL REACH
----------------------------------------------------------------------
1 10.254.1.21 10.254.1.21 LOCAL(0) 4 12 64 1
----------------------------------------------------------------------

Note that it may take a while for the time synchronization to drift to the time on the NTP server.
Save configuration checkpoints for the upcoming labs
You have now completed the VSX configuration lab.

This configuration will be the base configuration of several later labs, so a checkpoint
MUST be created to complete the rest of the course lab activities. This is critical, so do not
skip this step!

1. On Core-1, save the current configuration as a checkpoint.

ICX-Core-1(config)# end
ICX-Core-1# copy run checkpoint icx-lab02-vsx
Configuration changes will take time to process, please be patient.

2. Repeat this on Core-2.

ICX-Core-2(config)# end
ICX-Core-2# copy run checkpoint icx-lab02-vsx
Configuration changes will take time to process, please be patient.

3. Repeat this on Access-1.

78 Task 2-9: Finalize the configuration for the upcoming labs

 ICX-Access-1(config)# end
ICX-Access-1# copy run checkpoint icx-lab02-vsx

4. Repeat this on Access-2.

ICX-Access-2(config)# end
ICX-Access-2# copy run checkpoint icx-lab02-vsx

5. On all four switches, verify that the checkpoint exists in the checkpoint list.
ICX-switch1-4# show checkpoint list | include vsx
icx-lab02-vsx

You have completed Lab 2!

Lab 2: Configuring HPE Aruba

Networking Virtual Switching

Task 2-9: Finalize the configuration for the upcoming labs 79

[This page intentionally left blank]

80 Task 2-9: Finalize the configuration for the upcoming labs

Lab 3: Layer 2 optimization and protection
features

Lab 3: Layer 2 optimization and protection features

Lab diagram

Overview
This lab focuses on understanding and implementing Layer 2 (L2) optimization and protection features
that you learned about in Module 3—including STP and protections for STP, like edge ports, BPDU
guard, root guard, loop protection, and private VLANs—give you a better understanding of the load
sharing algorithm used by LAGs and how to tune it.

Objectives
n Describe the LAG load sharing algorithm.
n Configure a load sharing MSTP solution.
n Explain edge ports and their operation with STP.
n Implement BPDU guard.
n Implement root guard.
n Implement loop protection.
n Implement private VLANs (PVLANs).

Lab 3: Layer 2 optimization and protection features 81

Task 3-1: Verify the lab starting configuration
This lab requires that you load the Lab 2 VSX checkpoint as the starting configuration for the sub-
sequent tasks.

Objectives
n Load the Lab02 VSX configuration checkpoint.

Steps
1. Open a console connection to the Access-1. Log in using admin/aruba123.
ICX-Access-1# copy checkpoint icx-lab02-vsx running-config
Configuration changes will take time to process, please be patient.
ICX-Access-1#

2. Open a console connection to the Access-2. Log in using admin/aruba123.

ICX-Access-2# copy checkpoint icx-lab02-vsx running-config
Configuration changes will take time to process, please be patient.
ICX-Access-2#

3. Open a console connection to the Core-1. Log in using admin/aruba123.

ICX-Core-1# copy checkpoint icx-lab02-vsx running-config
Configuration changes will take time to process, please be patient.
ICX-Core-1#

4. Open a console connection to the Core-2. Log in using admin/aruba123.

ICX-Core-2# copy checkpoint icx-lab02-vsx running-config
Configuration changes will take time to process, please be patient.
ICX-Core-2#

Task 3-2: Examine the LAG load sharing process

In this task, you will learn about LAG features, including the load sharing algorithm used for dis-
tributing traffic across the interface members and LACP fallback, which is used with ZTP scenarios.
This lab will focus on the VSX LAG from the two core switches to the Access-1 switch.

82 Task 3-1: Verify the lab starting configuration

Lab diagram

Objectives
n Tune the LAG hash algorithm.
n Understand and use the LACP fallback feature.

Steps
Access-1
1. Open a terminal session to Access-1. Examine the LAG 255 interface connected to the VSX

Lab 3: Layer 2 optimization and

cluster of the core switches.
ICX-Access-1(config)# show lag 255

protection features
System-ID : 10:4f:58:f6:e3:80
System-priority : 65534

Aggregate lag255 is up
Admin state is up
Description : core
Type : normal
Lacp Fallback : Disabled
MAC Address : 10:4f:58:f6:e3:80
Aggregated-interfaces : 1/1/25 1/1/26
Aggregation-key : 255
Aggregate mode : active
Hash : l3-src-dst
LACP rate : slow

Task 3-2: Examine the LAG load sharing process 83

 Speed : 20000 Mb/s
Mode : trunk
n Question: What is the LACP mode?
n Answer: The mode is LACP active. HPE recommends that LAGs are configured using
LACP (not static) and at least one side, if not both, are configured in active mode.
n Question: What is the default load sharing algorithm used?
n Answer: The algorithm uses a hash of the source and destination IP addresses to deter-
mine which physical interface to use in the LAG.
2. On Access-1, enter the LAG 255 interface context that connects to the two core switches. Exam-
ine the hash options.
ICX-Access-1(config)# interface lag 255
ICX-Access-1(config-vrf)# hash ?
l2-src-dst Base the hash on l2-src-dst (Default:l3-src-dst)
l3-src-dst Base the hash on l3-src-dst (Default)
l4-src-dst Base the hash on l4-src-dst (Default:l3-src-dst)
ICX-Access-1(config-vrf)# exit
n Question: What are the hashing options?
n Answer: Layer 2 source and destination MAC addresses, Layer 3 source and destination IP
addresses, and source and destination TCP and UDP ports (L4).
A good practice is to periodically examine LAGs to see if traffic is evenly distributed. If it is not,
then you should experiment with changing the LAG load sharing algorithm. For example, you
might have a server that handles both DHCP and DNS server functions. The problem with the
default algorithm is that it does not look at the two services running on the destination, but only
the destination IP address. If you see an imbalance of traffic on the LAG, you should experiment
with changing the hash algorithm. In this example, since DHCP and DNS are TCP/UDP services,
the l4-src-dst option might provide a better load sharing solution. Remember that when tuning
it, you should examine the load sharing algorithm for both directions of traffic (both sides of the
LAG).
3. Examine the statistics for LAG 255. Notice the transmit (TX Bytes) byte difference between the
two interfaces (25 and 26). Interface 1/1/25 is handling about two-thirds of the traffic on the
LAG.
ICX-Access-1(config)# show interface lag255 statistics
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
Interface RX Bytes RX Packets RX Drops TX Bytes TX Packets TX Drops RX Broadcast RX Multicast TX Broadcast TX Multicast
RX Pause TX Pause
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
1/1/25 - lag255 11690126 88128 0 32782183 250369 11 32493 3 3888 6271
208914 0
1/1/26 - lag255 7356077 49562 0 16089068 113931 46 15304 3 3806 1978
111232 0
lag255 19046203 137690 0 48871251 364300 57 47797 6 7694 8249
320146 0

84 Task 3-2: Examine the LAG load sharing process

 4. Clear the interface statistics on LAG 255.
ICX-Access-1(config)# clear interface lag255 statistics

5. Send 100 pings from Access-1's VLAN 1 interface to the active gateway IP address with a size of
1000 bytes.
ICX-Access-1(config)# ping 10.1.1.1 source vlan1 repetitions 100 datagram-size 1000
PING 10.1.1.1 (10.1.1.1) 100(128) bytes of data.
PING 10.1.1.1 (10.1.1.1) from 10.1.1.4 : 1000(1028) bytes of data.
1008 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=0.212 ms
1008 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=0.184 ms
<output omitted>

--- 10.1.1.1 ping statistics ---

100 packets transmitted, 100 received, 0% packet loss, time 101380ms

6. Re-examine the LAG 255 statistics.

ICX-Access-1(config)# show interface lag255 statistics
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
Interface RX Bytes RX Packets RX Drops TX Bytes TX Packets TX Drops RX Broadcast RX Multicast TX Broadcast TX Multicast
RX Pause TX Pause
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
1/1/25 - lag255 4428 48 0 5584 56 0 7 8 0 8
0 0
1/1/26 - lag255 106412 114 0 114008 173 0 6 8 1 72
0 0
lag255 110840 162 0 119592 229 0 13 16 1 80
0 0

n Question: Which interface did they traverse?

n Answer: Interface 1/1/26. This is evident by examining the TX Packets column.
7. Clear the interface statistics again.

Lab 3: Layer 2 optimization and

ICX-Access-1(config)# clear interface lag255 statistics

8. Redo the same ping, except ping Core-1's VLAN IP address.

protection features
ICX-Access-1(config)# ping 10.1.1.2 source vlan1 repetitions 100 datagram-size 1000
PING 10.1.1.2 (10.1.1.2) from 10.1.1.4 : 1000(1028) bytes of data.
1008 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=0.196 ms
1008 bytes from 10.1.1.2: icmp_seq=2 ttl=64 time=0.191 ms
<output omitted>

--- 10.1.1.2 ping statistics ---

100 packets transmitted, 100 received, 0% packet loss, time 101360ms
rtt min/avg/max/mdev = 0.166/0.206/0.447/0.043 ms

9. Re-examine the LAG statistics.

ICX-Access-1(config)# show interface lag255 statistics
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
Interface RX Bytes RX Packets RX Drops TX Bytes TX Packets TX Drops RX Broadcast RX Multicast TX Broadcast TX Multicast
RX Pause TX Pause
---------------------------------------------------------------------------------------------------------------------------------------

Task 3-2: Examine the LAG load sharing process 85

 --------------------
1/1/25 - lag255 110190 138 0 4790 48 0 6 8 0 8
0 0
1/1/26 - lag255 1684 12 0 115180 168 0 4 8 1 64
0 0
lag255 111874 150 0 119970 216 0 10 16 1 72
0 0

n Question: Which interface did they traverse?

n Answer: Interface 1/1/26. This is evident by examining the TX Packets column.
10. Redo this process by having Access-1 ping Core-2's VLAN 1 IP address.
ICX-Access-1(config)# clear interface lag255 statistics

ICX-Access-1(config)# ping 10.1.1.3 source vlan1 repetitions 100 datagram-size 1000

PING 10.1.1.3 (10.1.1.3) from 10.1.1.4 : 1000(1028) bytes of data.
1008 bytes from 10.1.1.3: icmp_seq=1 ttl=64 time=16.3 ms
1008 bytes from 10.1.1.3: icmp_seq=2 ttl=64 time=0.175 ms
<output omitted>

--- 10.1.1.3 ping statistics ---

100 packets transmitted, 100 received, 0% packet loss, time 101348ms
rtt min/avg/max/mdev = 0.175/0.366/16.254/1.597 ms

ICX-Access-1(config)# show interface lag255 statistics

---------------------------------------------------------------------------------------------------------------------------------------
--------------------
Interface RX Bytes RX Packets RX Drops TX Bytes TX Packets TX Drops RX Broadcast RX Multicast TX Broadcast TX Multicast
RX Pause TX Pause
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
1/1/25 - lag255 3835 38 0 108552 137 0 9 8 0 8
0 0
1/1/26 - lag255 106480 115 0 9417 74 0 6 8 2 71
0 0
lag255 110315 153 0 117969 211 0 15 16 2 79
0 0

n Question: Which interface did they traverse?

n Answer: Interface 1/1/25. This is evident by examining the TX Packets column.
As you can see from the previous process, as a human, you cannot really predict what link will
actually be used in the LAG—by default, it is a hash of the source and destination IP addresses.
11. Access the LAG 255 context and change the load sharing algorithm to use TCP and UDP ports.
ICX-Access-1(config)# interface lag 255
ICX-Access-1(config-lag-if)# hash l4-src-dst
ICX-Access-1(config-lag-if)# exit

12. Verify the change.

ICX-Access-1(config)# show lag 255
System-ID : 10:4f:58:f6:e3:80
System-priority : 65534

Aggregate lag255 is up
Admin state is up
Description : core
Type : normal
Lacp Fallback : Disabled

86 Task 3-2: Examine the LAG load sharing process

 MAC Address : 10:4f:58:f6:e3:80
Aggregated-interfaces : 1/1/25 1/1/26
Aggregation-key : 255
Aggregate mode : active
Hash : l4-src-dst
LACP rate : slow
Speed : 20000 Mb/s
Mode : trunk

Access-1, Core-1, and Core-2

13. Enable SSH in the default VRF on Access-1, Core-1, and Core-2.
ICX-Access-1(config)# ssh server vrf default

ICX-Core-1(config)# ssh server vrf default

ICX-Core-2(config)# ssh server vrf default

Access-1
14. Reaccess Access-1. Clear the LAG statistics.
ICX-Access-1(config)# clear interface lag255 statistics

15. Access Core-1 and SSH to the IP address of Access-1 in VLAN 1 and log in (admin/aruba123).
ICX-Access-1# ssh admin@10.1.1.2 vrf default
The authenticity of host '10.1.1.1 (10.1.1.1)' can't be established.
ED25519 key fingerprint is SHA256:GUABszgT9d5rwJ+Tjg54B7CC0et3N136Jpi8ryMM4CM.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.1.1.1' (ED25519) to the list of known hosts.

Lab 3: Layer 2 optimization and

protection features
(C) Copyright 2017-2024 Hewlett Packard Enterprise Development LP

RESTRICTED RIGHTS LEGEND

Confidential computer software. Valid license from Hewlett Packard Enterprise
Development LP required for possession, use, or copying. License found at
https://www.arubanetworks.com/assets/legal/EULA.pdf and
https://www.hpe.com/software/SWLicensing.
By using the software, you acknowledge that you have read and understand
the license, represent you are authorized to accept this license, and agree
to be bound by its terms. If you do not agree to these terms, do not use the
software. Consistent with FAR 12.211 and 12.212, Commercial Computer Software,
Computer Software Documentation, and Technical Data for Commercial Items are
licensed to the U.S. Government under vendor's standard commercial license.

We'd like to keep you up to date about:

* Software feature updates

Task 3-2: Examine the LAG load sharing process 87

 * New product announcements
* Special events
Please register your products now at: https://asp.arubanetworks.com

admin@10.1.1.1's password: aruba123

Last login: 2024-05-07 15:34:56 from the console
User "admin" has logged in 9 times in the past 30 days
ICX-Core-1#
n Question: Which switch were you connected to?
n Answer: In the previous example, it was Core-1.
16. Execute the show running-config command about a dozen times. Then log out.
ICX-Core-1# show running-config
<output omitted>
ICX-Core-1# show running-config
<output omitted>
...
...
...
ICX-Core-1# exit
Connection to 10.1.1.1 closed.
Access-1#

17. Examine the LAG statistics.

ICX-Access-1# show interface lag255 statistics
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
Interface RX Bytes RX Packets RX Drops TX Bytes TX Packets TX Drops RX Broadcast RX Multicast TX Broadcast TX Multicast
RX Pause TX Pause
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
1/1/25 - lag255 233396 1762 0 140990 1803 0 27 37 1 37
0 0
1/1/26 - lag255 8663 62 0 45777 378 0 19 37 4 309
0 0
lag255 242059 1824 0 186767 2181 0 46 74 5 346
0 0

n Question: Which interface did the output of the SSH session traverse?
n Answer: Interface 1/1/25. Most of the output of the show run command was received (RX
Packets) on this interface.
Notice that the hash you configured only affects Access-1 and not what Core-1 or Core-2 will do.
Core-1 and Core-2
18. Mirror the hash algorithm configuration on Core-1 and Core-2's LAG 1.
ICX-Core-1(config)# interface lag 1
ICX-Core-1(config-lag-if)# hash l4-src-dst
ICX-Core-1(config-lag-if)# exit

88 Task 3-2: Examine the LAG load sharing process

 ICX-Core-2(config)# interface lag 1
ICX-Core-2(config-lag-if)# hash l4-src-dst
ICX-Core-2(config-lag-if)# exit

Access-1
19. Return to Access-1's console. Clear the LAG statistics.
ICX-Access-1(config)# clear interface lag255 statistics

20. Access Core-1 and SSH to the IP address of Access-1 in VLAN 1 and log in (admin/aruba123).
ICX-Access-1# ssh admin@10.1.1.3 vrf default
The authenticity of host '10.1.1.1 (10.1.1.1)' can't be established.
ED25519 key fingerprint is SHA256:GUABszgT9d5rwJ+Tjg54B7CC0et3N136Jpi8ryMM4CM.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.1.1.1' (ED25519) to the list of known hosts.

(C) Copyright 2017-2024 Hewlett Packard Enterprise Development LP

RESTRICTED RIGHTS LEGEND

Confidential computer software. Valid license from Hewlett Packard Enterprise
Development LP required for possession, use, or copying. License found at
https://www.arubanetworks.com/assets/legal/EULA.pdf and
https://www.hpe.com/software/SWLicensing.
By using the software, you acknowledge that you have read and understand
the license, represent you are authorized to accept this license, and agree
to be bound by its terms. If you do not agree to these terms, do not use the
software. Consistent with FAR 12.211 and 12.212, Commercial Computer Software,
Computer Software Documentation, and Technical Data for Commercial Items are
licensed to the U.S. Government under vendor's standard commercial license.

Lab 3: Layer 2 optimization and

We'd like to keep you up to date about:
* Software feature updates

protection features
* New product announcements
* Special events
Please register your products now at: https://asp.arubanetworks.com

admin@10.1.1.1's password: aruba123

Last login: 2024-05-07 15:34:56 from the console
User "admin" has logged in 9 times in the past 30 days
ICX-Core-1#

If you see a message "WARNING: REMOTE HOST IDENTIFICATON HAS CHANGED!"

perform the following and reconnect via SSH to 10.1.1.1.
ICX-Access-1(config)# ssh admin@10.1.1.1 vrf default
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Task 3-2: Examine the LAG load sharing process 89

 @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle
attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:0OW4xdHyMIlhL4GONbUCvEYVkZHTw6ma9KeGlx8IPJw.
Please contact your system administrator.
The offending key can be removed using the below command:
ssh known-host remove 10.1.1.1
Host key for 10.1.1.1 has changed and you have requested strict
checking.
Host key verification failed.
ICX-Access-1(config)# ssh known-host remove 10.1.1.1

n Question: To which switch were you connected?

n Answer: In the previous example, it was Core-1.
21. Execute the show running-config command about a dozen times. Then log out.
ICX-Core-1# show running-config
<output omitted>
ICX-Core-1# show running-config
<output omitted>
...
...
...
ICX-Core-1# exit
Connection to 10.1.1.1 closed.
Access-1#

22. Examine the LAG statistics.

ICX-Access-1(config)# show interface lag255 statistics
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
Interface RX Bytes RX Packets RX Drops TX Bytes TX Packets TX Drops RX Broadcast RX Multicast TX Broadcast TX Multicast
RX Pause TX Pause
---------------------------------------------------------------------------------------------------------------------------------------
--------------------
1/1/25 - lag255 201689 1491 0 115497 1512 0 14 16 1 16
0 0
1/1/26 - lag255 5681 34 0 22392 178 0 10 16 2 138
0 0
lag255 207370 1525 0 137889 1690 0 24 32 3 154
0 0

n Question: Which interface did the output of the SSH session traverse?
n Answer: Interface 1/1/25. Most of the output of the show run command was received (RX
Packets) on this interface.

90 Task 3-2: Examine the LAG load sharing process

 n Question: Is this a different interface compared to when the algorithm was l3-src-dst on
the VSX LAG on the two core switches?
n Answer: No (at least for this example). Based on this information, you should always verify
that when you change the hash algorithm (which should match on the devices on the two
sides of the LAG), the change has the desired effect. You should, obviously, not rely on one
test but examine the results of the LAG (on both sides) over a period of time.
23. Optionally, you can repeat this process by clearing the statistics and from Access-1, SSH into the
VLAN 1 IP addresses of the two core switches (10.1.1.2 and 10.1.1.3), and examine the results.

Task 3-3: Using the LACP fallback feature

The LACP fallback feature is necessary on AOS-CX aggregation and core switches, or both, on down-
links to devices that perform ZTP. By default, AOS-CX switches, when using LACP, expect to receive
LACP messages from the partner switch. In the following diagram, if Core-1 and Core-2 are configured
for LACP (active) and Access-1 is at its factory-default state, then Core-1 and Core-2 will not receive
responses to their LACP messages. What happens next is vendor-specific because the LACP standard
does not have a defined recommendation as to what to do. In the case of AOS-CX switches, they will
leave both interfaces in an LACP-blocked state. The problem with this is that Access-1 is then denied
access on the uplinks and, therefore, ZTP will fail.
The LACP fallback feature solves this problem by allowing a port on the LAG to remain active, thus
allowing ZTP to function, if required.
In this lab, you will explore this process and implement the LACP fallback feature to solve this problem.

Lab 3: Layer 2 optimization and

protection features

Task 3-3: Using the LACP fallback feature 91

Lab diagram

Objectives
n Explain the default behavior of LACP on AOS-CX switches.
n Implement LACP fallback on aggregation or core switches.

Steps
Core-1
1. Verify that the LAG, using LACP to Access-1, is operational.
ICX-Core-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 ALFNCD 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 5 1 ALFNCD 02:01:00:00:01:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up

92 Task 3-3: Using the LACP fallback feature

 1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up

Partner details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 26 1 ALFNCD 10:4f:58:f6:e3:80 65534 255
1/1/2 lag2(mc) 26 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc) 2 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256

ICX-Core-1(config)# show lacp interfaces vsx-peer

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 1001 1 ALFNCD 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 1002 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 1005 1 ALFNCD 02:01:00:00:01:00 65534 5 up

Lab 3: Layer 2 optimization and

1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up

protection features
Partner details of all interfaces:
---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 27 1 ALFNCD 10:4f:58:f6:e3:80 65534 255
1/1/2 lag2(mc) 27 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc) 3 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256

Access-1
2. Access Access-1's console. Disable LACP on LAG 255.

Task 3-3: Using the LACP fallback feature 93

 ICX-Access-1(config)# interface lag 255
ICX-Access-1(config-lag-if)# no lacp mode active
ICX-Access-1(config-lag-if)# exit

3. Try pinging the active gateway IP address of VLAN 1.

ICX-Access-1(config)# ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 100(128) bytes of data.
From 10.1.1.4 icmp_seq=1 Destination Host Unreachable
From 10.1.1.4 icmp_seq=2 Destination Host Unreachable
From 10.1.1.4 icmp_seq=3 Destination Host Unreachable

--- 10.1.1.1 ping statistics ---

5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4061ms
n Question: What was the result?
n Answer: The ping failed.
Core-1
4. Access Core-1's console. What is the status of interface 1/1/1 on both core switches?
ICX-Core-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 ALFOE 02:01:00:00:01:00 65534 1 lacp-block
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 5 1 ALFNCD 02:01:00:00:01:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up

Partner details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 0 0 PLFOEX 00:00:00:00:00:00 0 0
1/1/2 lag2(mc) 26 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc) 2 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2

94 Task 3-3: Using the LACP fallback feature

 1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256

ICX-Core-1(config)# show lacp interfaces vsx-peer

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 1001 1 ALFOE 02:01:00:00:01:00 65534 1 lacp-block
1/1/2 lag2(mc) 1002 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 1005 1 ALFNCD 02:01:00:00:01:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up

Partner details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 0 0 PLFOEX 00:00:00:00:00:00 0 0
1/1/2 lag2(mc) 27 1 ALFNCD 10:4f:58:fc:b2:40 65534 255

Lab 3: Layer 2 optimization and

1/1/5 lag5(mc) 3 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256

protection features
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256
n Question: Based on the LACP state (the flags), what is the issue?
n Answer: The O indicates out of sync; one possible reason for this is that the LACP neigh-
bor is not responding to LACP messages.
Core-1
5. Let us fix this issue. On Core-1, enable the LACP fallback feature on LAG 1. Note the warning
that is displayed.
ICX-Core-1(config)# interface lag 1
ICX-Core-1(config-lag-if)# lacp fallback
Warning: Enabling LACP fallback may result in a network loop.
ICX-Core-1(config-lag-if)#

6. Verify that the configuration was synched to Core-2.

Task 3-3: Using the LACP fallback feature 95

 ICX-Core-1(config-lag-if)# show run interface lag1 vsx-peer
interface lag 1 multi-chassis
description access1
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed 1,11-13
lacp mode active
hash l4-src-dst
lacp fallback
exit

7. Re-examine the LACP state on the two core switches.

ICX-Core-1(config-lag-if)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 IE 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 5 1 ALFNCD 02:01:00:00:01:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up

Partner details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 0 0 IE 00:00:00:00:00:00 0 0
1/1/2 lag2(mc) 26 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc) 2 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256

ICX-Core-1(config-lag-if)# show lacp interfaces vsx-peer

State abbreviations :

96 Task 3-3: Using the LACP fallback feature

 A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 1001 1 IE 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 1002 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 1005 1 ALFNCD 02:01:00:00:01:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up

Partner details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/1 lag1(mc) 0 0 IE 00:00:00:00:00:00 0 0
1/1/2 lag2(mc) 27 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc) 3 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256
n Question: Why are both interfaces enabled?
n Answer: This is a VSX LAG. With a LAG between two devices, an AOS-CX switch would
only allow one port (by default, the first one) to remain enabled. However, this is a VSX

Lab 3: Layer 2 optimization and

LAG, and thus the first port on each member will remain enabled. That is why you saw the

protection features
warning message when enabling the fallback feature—you might be inadvertently creating
an L2 loop in your network when using this feature.
Access-1
8. Ping the active gateway IP address for VLAN 1.
ICX-Access-1(config)# ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 100(128) bytes of data.
From 10.1.1.4 icmp_seq=1 Destination Host Unreachable
From 10.1.1.4 icmp_seq=2 Destination Host Unreachable
From 10.1.1.4 icmp_seq=3 Destination Host Unreachable

9. Examine the interface status of 1/1/25 and 1/1/26 on Access-1. As you can see, an L2 loop prob-
ably exists in this situation since both sides are up.
ICX-Access-1(config)# show interface brief
-----------------------------------------------------------------------------------

Task 3-3: Using the LACP fallback feature 97

 ---------------------
Port Native Mode Type Enabled Status Reason
Speed Description
VLAN
(Mb/s)
-----------------------------------------------------------------------------------
---------------------
<output omitted>
1/1/25 1 trunk 10G-DAC1 yes up
10000 --
1/1/26 1 trunk 10G-DAC1 yes up
10000 --
<output omitted>

10. Remove the LAG 255 configuration on Access-1.

ICX-Access-1(config)# no interface lag 255

11. Retest the ping.

ICX-Access-1(config)# ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 100(128) bytes of data.
108 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=13.4 ms
108 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=0.191 ms
108 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=0.199 ms
108 bytes from 10.1.1.1: icmp_seq=4 ttl=64 time=0.184 ms
108 bytes from 10.1.1.1: icmp_seq=5 ttl=64 time=0.204 ms

--- 10.1.1.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4077ms
rtt min/avg/max/mdev = 0.184/0.194/0.204/0.007 ms

12. Rebuild the LAG on Access-1, enabling LACP. Assign interfaces 1/1/25 and 1/1/26 to it.
ICX-Access-1(config)# interface lag 255
ICX-Access-1(config-lag-if)# description core
ICX-Access-1(config-lag-if)# no routing
ICX-Access-1(config-lag-if)# vlan trunk allowed all
ICX-Access-1(config-lag-if)# no shut
ICX-Access-1(config-lag-if)# lacp mode active
ICX-Access-1(config-lag-if)# exit

ICX-Access-1(config)# interface 1/1/25,1/1/26

ICX-Access-1(config-if-<1/1/25,1/1/26>)# lag 255
ICX-Access-1(config-if-<1/1/25,1/1/26>)# mtu 9100
ICX-Access-1(config-if-<1/1/25,1/1/26>)# no shutdown
ICX-Access-1(config-if-<1/1/25,1/1/26>)# exit

13. Verify that the LAG is operational.

ICX-Access-1(config)# show lacp interfaces

State abbreviations :

98 Task 3-3: Using the LACP fallback feature

 A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
---------------------------------------------------------------------------------
1/1/25 lag255 26 1 ALFNCD 10:4f:58:f6:e3:80 65534 255 up
1/1/26 lag255 27 1 ALFNCD 10:4f:58:f6:e3:80 65534 255 up

Partner details of all interfaces:

---------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
---------------------------------------------------------------------------------
1/1/25 lag255 1 1 ALFNCD 02:01:00:00:01:00 65534 1
1/1/26 lag255 1001 1 ALFNCD 02:01:00:00:01:00 65534 1

Task 3-4: Configure an MSTP solution

The configuration of MSTP was covered in the AOS-CX Switching Fundamentals course. In this task,
you will configure a simple MSTP solution that will be used in the upcoming tasks.

Lab 3: Layer 2 optimization and

protection features

Task 3-4: Configure an MSTP solution 99

Lab diagram

Objectives
n Implement MSTP on all four switches.
n Verify the operation of MSTP.

Steps
Core-1, Core-2, Access-1, and Access-2
1. On all four switches, define a matching MSTP configuration. For this lab, all VLANs will belong to
the default instance.
ICX-Core-1(config)# spanning-tree
ICX-Core-1(config)# spanning-tree mode mstp
ICX-Core-1(config)# spanning-tree config-name icx
ICX-Core-1(config)# spanning-tree config-revision 1

ICX-Core-2(config)# spanning-tree
ICX-Core-2(config)# spanning-tree mode mstp
ICX-Core-2(config)# spanning-tree config-name icx
ICX-Core-2(config)# spanning-tree config-revision 1

ICX-Access-1(config)# spanning-tree
ICX-Access-1(config)# spanning-tree mode mstp
ICX-Access-1(config)# spanning-tree config-name icx
ICX-Access-1(config)# spanning-tree config-revision 1

100 Task 3-4: Configure an MSTP solution

 ICX-Access-2(config)# spanning-tree
ICX-Access-2(config)# spanning-tree mode mstp
ICX-Access-2(config)# spanning-tree config-name icx
ICX-Access-2(config)# spanning-tree config-revision 1

Core-1
2. Define Core-1 as the primary root bridge.
ICX-Core-1(config)# spanning-tree priority 1

Core-2
3. Define Core-2 as the secondary root bridge.
ICX-Core-2(config)# spanning-tree priority 2

Access-1
4. Enable port 1/1/27 on Access-1.
ICX-Access-1(config)# interface 1/1/27
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# exit

Access-2
5. Enable port 1/1/27 on Access-2.
ICX-Access-2(config)# interface 1/1/27
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit

6. Verify that the interface is enabled and that Access-1 is reachable.

Lab 3: Layer 2 optimization and

ICX-Access-2(config)# show interface brief
--------------------------------------------------------------------------------------------------
Port Native Mode Type Enabled Status Reason Speed Description

protection features
VLAN (Mb/s)
--------------------------------------------------------------------------------------------------
<output omitted>
1/1/26 1 trunk 10G-DAC1 yes up 10000 --
1/1/27 1 access 10G-DAC1 yes up 10000 --
1/1/28 1 access 10G-DAC1 no down Administratively down -- --
<output omitted>

ICX-Access-2(config)# show lldp neighbor-info

LLDP Neighbor Information

=========================

Total Neighbor Entries : 4

Total Neighbor Entries Deleted : 9
Total Neighbor Entries Dropped : 0
Total Neighbor Entries Aged-Out : 9

LOCAL-PORT CHASSIS-ID PORT-ID PORT-DESC TTL SYS-NAME

Task 3-4: Configure an MSTP solution 101

 -----------------------------------------------------------------------------------------------------------
1/1/25 b8:d4:e7:40:6d:00 1/1/2 access2 120 ICX-Core-1
1/1/26 b8:d4:e7:40:8e:00 1/1/2 access2 120 ICX-Core-2
1/1/27 10:4f:58:f6:e3:80 1/1/27 1/1/27 120 ICX-Access-1
mgmt 00:23:89:bb:73:4a GigabitEthernet3/0/7 T13-6300-B-OOBM 120 P54-OOBM-Fanout

Core-1, Core-2, Access-1, and Access-2

7. Since you have now introduced an L2 loop into your network, verify the MSTP port state of the
four switches to see how MSTP has avoided the loop situation.
ICX-Core-1(config)# show spanning-tree mst
#### MST0
Vlans mapped: 1-4040
Bridge Address:02:01:00:00:01:00 priority:4096
Root
Regional Root
Operational Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in seconds):20 txHoldCount(in
pps): 6
Configured Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in seconds):20 Max-Hops:20
Root Address:02:01:00:00:01:00 Priority:4096
Port:0 Path cost:0
Regional Root Address:02:01:00:00:01:00 Priority:4096
Internal cost:0 Rem Hops:20

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
-------------- -------------- ---------- ---------- ---------- ---------- ---------- ---------- -------- -------
lag1 Designated Forwarding 2000 64 P2P 428 8 8 4
lag2 Designated Forwarding 2000 64 P2P 429 6 10 2
lag5 Designated Forwarding 20000 64 P2P 424 0 0 0
lag256 Designated Forwarding 1 64 P2P 432 379 14 2

Topology change flag : True

Number of topology changes : 17
Last topology change occurred : 222 seconds ago

Notice that all enabled ports on Core-1 (the root) are in a designated/forwarding state.
ICX-Core-2(config)# show spanning-tree mst
#### MST0
Vlans mapped: 1-4040
Bridge Address:02:01:00:00:01:00 priority:8192
Root
Regional Root
Operational Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in seconds):20 txHoldCount(in
pps): 6
Configured Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in seconds):20 Max-Hops:20
Root Address:02:01:00:00:01:00 Priority:4096
Port:lag256 Path cost:0
Regional Root Address:02:01:00:00:01:00 Priority:4096
Internal cost:1 Rem Hops:19

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
-------------- -------------- ---------- ---------- ---------- ---------- ---------- ---------- -------- -------
lag1 Designated Forwarding 2000 64 P2P 0 0 0 0
lag2 Designated Forwarding 2000 64 P2P 0 0 0 0
lag5 Designated Forwarding 20000 64 P2P 0 0 0 0
lag256 Root Forwarding 1 64 P2P 185 343 2 10

Topology change flag : True

Number of topology changes : 17
Last topology change occurred : 243 seconds ago

102 Task 3-4: Configure an MSTP solution

 Notice that LAG 256 on Core-2 is a root port.
ICX-Access-1(config)# show spanning-tree mst
#### MST0
Vlans mapped: 1-4094
Bridge Address:10:4f:58:f6:e3:80 priority:32768
Operational Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in seconds):20 txHoldCount(in
pps): 6
Configured Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in seconds):20 Max-Hops:20
Root Address:02:01:00:00:01:00 Priority:4096
Port:lag255 Path cost:0
Regional Root Address:02:01:00:00:01:00 Priority:4096
Internal cost:2000 Rem Hops:19

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
-------------- -------------- ---------- ---------- ---------- ---------- ---------- ---------- -------- -------
1/1/1 Disabled Down 20000 128 P2P 69150 0 0 0
1/1/2 Disabled Down 20000 128 P2P 0 0 0 0
1/1/3 Designated Forwarding 20000 128 P2P 158046 0 0 0
1/1/4 Disabled Down 20000 128 P2P 0 0 0 0
1/1/5 Disabled Down 20000 128 P2P 0 0 0 0
1/1/6 Disabled Down 20000 128 P2P 0 0 0 0
1/1/7 Disabled Down 20000 128 P2P 0 0 0 0
1/1/8 Disabled Down 20000 128 P2P 0 0 0 0
1/1/9 Disabled Down 20000 128 P2P 0 0 0 0
1/1/10 Disabled Down 20000 128 P2P 0 0 0 0
1/1/11 Disabled Down 20000 128 P2P 0 0 0 0
1/1/12 Disabled Down 20000 128 P2P 0 0 0 0
1/1/13 Disabled Down 20000 128 P2P 0 0 0 0
1/1/14 Disabled Down 20000 128 P2P 0 0 0 0
1/1/15 Disabled Down 20000 128 P2P 0 0 0 0
1/1/16 Disabled Down 20000 128 P2P 0 0 0 0
1/1/17 Disabled Down 20000 128 P2P 0 0 0 0
1/1/18 Disabled Down 20000 128 P2P 0 0 0 0
1/1/19 Disabled Down 20000 128 P2P 0 0 0 0
1/1/20 Disabled Down 20000 128 P2P 0 0 0 0
1/1/21 Disabled Down 20000 128 P2P 3 69152 2 2
1/1/22 Disabled Down 20000 128 P2P 3 69151 0 2
1/1/23 Disabled Down 20000 128 P2P 0 0 0 0

Lab 3: Layer 2 optimization and

1/1/24 Disabled Down 20000 128 P2P 0 0 0 0
1/1/27 Designated Forwarding 2000 128 P2P 69289 3 4 0
1/1/28 Disabled Down 20000 128 P2P 69155 2 3 0

protection features
lag255 Root Forwarding 2000 64 P2P 510 548 6 8

Notice that the root port on Access-1 is LAG 255, that port 1/1/27 is in a designated/forwarding
state, and that LAG 255 is a root port.
ICX-Access-2(config)# show spanning-tree mst
#### MST0
Vlans mapped: 1-4094
Bridge Address:10:4f:58:fc:b2:40 priority:32768
Operational Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in seconds):20 txHoldCount(in
pps): 6
Configured Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in seconds):20 Max-Hops:20
Root Address:02:01:00:00:01:00 Priority:4096
Port:lag255 Path cost:0
Regional Root Address:02:01:00:00:01:00 Priority:4096
Internal cost:2000 Rem Hops:19

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
-------------- -------------- ---------- ---------- ---------- ---------- ---------- ---------- -------- -------
1/1/1 Disabled Down 20000 128 P2P 0 0 0 0

Task 3-4: Configure an MSTP solution 103

 1/1/2 Disabled Down 20000 128 P2P 0 0 0 0
1/1/3 Disabled Down 20000 128 P2P 0 0 0 0
1/1/4 Designated Forwarding 20000 128 P2P 741241 0 0 0
1/1/5 Disabled Down 20000 128 P2P 0 0 0 0
1/1/6 Disabled Down 20000 128 P2P 0 0 0 0
1/1/7 Disabled Down 20000 128 P2P 0 0 0 0
1/1/8 Disabled Down 20000 128 P2P 0 0 0 0
1/1/9 Disabled Down 20000 128 P2P 0 0 0 0
1/1/10 Disabled Down 20000 128 P2P 0 0 0 0
1/1/11 Disabled Down 20000 128 P2P 0 0 0 0
1/1/12 Disabled Down 20000 128 P2P 0 0 0 0
1/1/13 Disabled Down 20000 128 P2P 0 0 0 0
1/1/14 Disabled Down 20000 128 P2P 0 0 0 0
1/1/15 Disabled Down 20000 128 P2P 0 0 0 0
1/1/16 Disabled Down 20000 128 P2P 0 0 0 0
1/1/17 Disabled Down 20000 128 P2P 0 0 0 0
1/1/18 Disabled Down 20000 128 P2P 0 0 0 0
1/1/19 Disabled Down 20000 128 P2P 0 0 0 0
1/1/20 Disabled Down 20000 128 P2P 0 0 0 0
1/1/21 Disabled Down 20000 128 P2P 10 653294 8 190
1/1/22 Disabled Down 20000 128 P2P 13 653323 3 175
1/1/23 Disabled Down 20000 128 P2P 0 0 0 0
1/1/24 Disabled Down 20000 128 P2P 0 0 0 0
1/1/27 Alternate Blocking 2000 128 P2P 26 652327 2 189
1/1/28 Disabled Down 20000 128 P2P 25 652172 2 189
lag255 Root Forwarding 2000 64 P2P 558 256180 4 21

Topology change flag : True

Number of topology changes : 13
Last topology change occurred : 684 seconds ago

Notice that the root port on Access-1 is LAG 255, that port 1/1/27 is in a designated/blocking
state, and that LAG 255 is a root port.
Now that you have a working MSTP configuration, you can proceed with the next tasks.

104 Task 3-4: Configure an MSTP solution

 Task 3-5: Understanding edge ports and their operation with spanning
tree
Lab diagram

Objectives
n Explain the difference between an admin-network port and admin-edge port.

Steps
Access-2

Lab 3: Layer 2 optimization and

1. Examine the STP port status of interface 1/1/4.

protection features
ICX-Access-2(config)# show spanning-tree mst 0 interface 1/1/4
Port 1/1/4
Port Type : admin-network Loop Guard : disable
Link Type : P2P BPDU Filter : disable
Boundary : internal BPDU Guard : disable
Root Guard : disable RPVST Filter : disable
RPVST Guard : disable

Instance Role State Cost Priority Vlans mapped

-------------- -------------- ------------ ---------- ---------- ----------
0 Designated Forwarding 20000 128 1-4094
n Question: What is the default STP port type for interface 1/1/4?
n Answer: admin-network.

Task 3-5: Understanding edge ports and their operation with spanning tree 105
 n Question: Are any STP protection methods enabled by default?
n Answer: No.
2. Examine the STP port status of interface 1/1/27.
ICX-Access-2(config)# show spanning-tree mst 0 interface 1/1/27
Port 1/1/27
Port Type : admin-network Loop Guard : disable
Link Type : P2P BPDU Filter : disable
Boundary : internal BPDU Guard : disable
Root Guard : disable RPVST Filter : disable
RPVST Guard : disable

Instance Role State Cost Priority Vlans mapped

-------------- -------------- ------------ ---------- ---------- ----------
0 Alternate Blocking 2000 128 1-4094
n Question: What is the default STP port type for interface 1/1/27?
n Answer: admin-network.
3. On interface 1/1/27, disable it, re-enable it, and immediately look at the STP state for the inter-
face.
ICX-Access-2(config)# interface 1/1/27
ICX-Access-2(config-if)# shutdown
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# show spanning-tree mst 0 interface 1/1/27
Port 1/1/27
Port Type : admin-network Loop Guard : disable
Link Type : P2P BPDU Filter : disable
Boundary : internal BPDU Guard : disable
Root Guard : disable RPVST Filter : disable
RPVST Guard : disable

Instance Role State Cost Priority Vlans mapped

-------------- -------------- ------------ ---------- ---------- ----------
0 Designated Blocking 2000 128 1-4094

4. Wait 10 seconds and re-examine the STP port state.

ICX-Access-2(config-if)# show spanning-tree mst 0 interface 1/1/27
Port 1/1/27
Port Type : admin-network Loop Guard : disable
Link Type : P2P BPDU Filter : disable
Boundary : internal BPDU Guard : disable
Root Guard : disable RPVST Filter : disable
RPVST Guard : disable

Instance Role State Cost Priority Vlans mapped

106 Task 3-5: Understanding edge ports and their operation with spanning tree
 -------------- -------------- ------------ ---------- ---------- ----------
0 Alternate Blocking 2000 128 1-4094

In the case of admin-network, the port looks for BPDUs for the first three seconds after the link is
up. If no BPDUs are received, the port becomes an edge port and immediately forwards frames. If
BPDUs are detected, the port becomes a non-edge port and participates in normal STP oper-
ation.
5. The admin-edge option does not wait for the receipt of any BPDUs. The port immediately
transitions to the forwarding state on startup. Change the STP port state to admin-edge. Shut
down the port, re-enable the port, and immediately examine the STP port state.
ICX-Access-2(config)# interface 1/1/27
ICX-Access-2(config-if)# spanning-tree port-type admin-edge
ICX-Access-2(config-if)# shutdown
ICX-Access-2(config-if)# no shutdown

ICX-Access-2(config-if)# show spanning-tree mst 0 interface 1/1/27

Port 1/1/27
Port Type : admin-edge Loop Guard : disable
Link Type : P2P BPDU Filter : disable
Boundary : internal BPDU Guard : disable
Root Guard : disable RPVST Filter : disable
RPVST Guard : disable

Instance Role State Cost Priority Vlans mapped

-------------- -------------- ------------ ---------- ---------- ----------
0 Alternate Blocking 2000 128 1-4094
n Question: Why is the port showing as an alternate/blocking port instead of initially des-
ignated/forwarding?

Lab 3: Layer 2 optimization and

n Answer: BPDUs are sent every two seconds. Therefore, as soon as you bring the interface

protection features
back up, unless you are quick enough, the BPDUs are exchanged and the correct port
states are determined.
6. Change the port state back to admin-network.
ICX-Access-2(config)# interface 1/1/27
ICX-Access-2(config-if)# spanning-tree port-type admin-network
ICX-Access-2(config-if)# exit

Task 3-6: Implement BPDU guard

AOS-CX switches offer BPDU protection to help protect against rogue switches being attached to edge
ports on your access switches. This feature operates at the port level and is best implemented on edge
ports, which should not be receiving BPDUs.

Task 3-6: Implement BPDU guard 107

By default, all four switches have STP enabled. For this task, you will implement this feature on LAG
255 on Access-1 and verify the results. Since both core switches have STP enabled on the downlink
LAG 1 interface, Access-1 should see this as a violation and take action.

Lab diagram

Objectives
n Implement BPDU guard.
n Verify BPDU guard operation.

Steps
Access-1
1. Open a console connection to Access-1. Enable a timeout of 30 seconds for BPDU guard.
ICX-Access-1(config)# spanning-tree bpdu-guard timeout 30
n Question: Upon a violation, what will happen after the 30 seconds expires?
n Answer: The port will automatically be re-enabled. However, if another violation occurs,
the port is logically disabled.
2. Enable the BPDU guard feature on the LAG 255 interface.
ICX-Access-1(config)# interface lag 255
ICX-Access-1(config-if)# spanning-tree bpdu-guard

3. Verify the configuration.

ICX-Access-1(config-lag-if)# show spanning-tree interface lag255

108 Task 3-6: Implement BPDU guard

 Port : lag255
Admin State : up
BPDU Guard : enabled
BPDU Filter : disabled
RPVST Guard : disabled
RPVST Filter : disabled
Loop Guard : disabled
Root Guard : disabled
TCN Guard : disabled
Admin Edge Port : admin-network
Link Type : Point to Point
BPDU Tx Count : 537
BPDU Rx Count : 2294
TCN Tx Count : 22
TCN Rx Count : 16

4. Examine the STP messages (hpe-mstpd process) and look for the one related to the BPDU guard
violation.
ICX-Access-1(config-lag-if)# show events -r -d hpe-mstpd
---------------------------------------------------
Event logs from current boot
---------------------------------------------------
2024-05-08T15:31:54.534013-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2011|LOG_
INFO|CDTR|1|Topology Change received on port 1/1/27 for CIST from source:
10:4f:58:fc:b2:4e
2024-05-08T15:31:52.853356-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2011|LOG_
INFO|CDTR|1|Topology Change received on port 1/1/27 for CIST from source:
10:4f:58:fc:b2:4e
2024-05-08T15:31:52.839517-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2006|LOG_
INFO|CDTR|1|CST - Root changed from 32768: 10:4f:58:f6:e3:80 to 4096:
02:01:00:00:01:00

Lab 3: Layer 2 optimization and

2024-05-08T15:31:52.812796-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2006|LOG_

protection features
INFO|CDTR|1|CST - Root changed from 4096: 02:01:00:00:01:00 to 32768:
10:4f:58:f6:e3:80
2024-05-08T15:31:52.786311-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2007|LOG_
WARN|CDTR|1|Port lag255 disabled - BPDU received on protected port

5. Examine the STP port inconsistencies and notice the port violation.
CX-Access-1(config-lag-if)# show spanning-tree inconsistent-ports
Instance ID Blocked Port Reason
------------ -------------- ------------
0 lag255 BPDU Guard

6. Wait at least 30 seconds and re-examine the STP events. In the following output, you can see
three violations, which means that between the first and second list of events, more than 60
seconds expired.
ICX-Access-1(config-lag-if)# show events -r -d hpe-mstpd
---------------------------------------------------

Task 3-6: Implement BPDU guard 109

 Event logs from current boot
---------------------------------------------------
2024-05-08T15:33:00.805865-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2007|LOG_
WARN|CDTR|1|Port lag255 disabled - BPDU received on protected port
2024-05-08T15:33:00.790689-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2012|LOG_
INFO|CDTR|1|CIST - Topology Change generated on port lag255 going in to forwarding
2024-05-08T15:32:26.803361-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2007|LOG_
WARN|CDTR|1|Port lag255 disabled - BPDU received on protected port
2024-05-08T15:32:26.788809-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2012|LOG_
INFO|CDTR|1|CIST - Topology Change generated on port lag255 going in to forwarding
2024-05-08T15:31:54.534013-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2011|LOG_
INFO|CDTR|1|Topology Change received on port 1/1/27 for CIST from source:
10:4f:58:fc:b2:4e
2024-05-08T15:31:52.853356-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2011|LOG_
INFO|CDTR|1|Topology Change received on port 1/1/27 for CIST from source:
10:4f:58:fc:b2:4e
2024-05-08T15:31:52.839517-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2006|LOG_
INFO|CDTR|1|CST - Root changed from 32768: 10:4f:58:f6:e3:80 to 4096:
02:01:00:00:01:00
2024-05-08T15:31:52.812796-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2006|LOG_
INFO|CDTR|1|CST - Root changed from 4096: 02:01:00:00:01:00 to 32768:
10:4f:58:f6:e3:80
2024-05-08T15:31:52.786311-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2007|LOG_
WARN|CDTR|1|Port lag255 disabled - BPDU received on protected port
2024-05-08T15:23:18.734752-04:00 ICX-Access-1 hpe-mstpd[3126]: Event|2012|LOG_
INFO|CDTR|1|CIST - Topology Change generated on port 1/1/28 going in to forwarding

As you can see, the port was re-enabled (Topology Change generated on port lag255 going
in to forwarding) and then disabled (Port lag255 disabled - BPDU received on protected
port) because of a recurring violation.

7. Disable BPDU guard on the LAG and verify your configuration.

ICX-Access-1(config-lag-if)# no spanning-tree bpdu-guard
ICX-Access-1(config-lag-if)# show spanning-tree interface lag255

Port : lag255
Admin State : up
BPDU Guard : disabled
BPDU Filter : disabled
RPVST Guard : disabled
RPVST Filter : disabled
Loop Guard : disabled
Root Guard : disabled
TCN Guard : disabled
Admin Edge Port : admin-network
Link Type : Point to Point
BPDU Tx Count : 539
BPDU Rx Count : 2294

110 Task 3-6: Implement BPDU guard

 TCN Tx Count : 22
TCN Rx Count : 16

8. Verify the STP topology on Access-1. The LAG 255 interface should be a root port and in a for-
warding state.
ICX-Access-1(config-lag-if)# show spanning-tree mst
#### MST0
Vlans mapped: 1-4094
Bridge Address:10:4f:58:f6:e3:80 priority:32768
Operational Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in
seconds):20 txHoldCount(in pps): 6
Configured Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in
seconds):20 Max-Hops:20
Root Address:02:01:00:00:01:00 Priority:4096
Port:lag255 Path cost:0
Regional Root Address:02:01:00:00:01:00 Priority:4096
Internal cost:2000 Rem Hops:19

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
--------- ------------ ---------- ------- --------- ------ -------- -------- ------- ------
1/1/1 Disabled Down 20000 128 P2P 69150 0 0 0
1/1/2 Disabled Down 20000 128 P2P 0 0 0 0
1/1/3 Designated Forwarding 20000 128 P2P 160028 0 0 0
1/1/4 Disabled Down 20000 128 P2P 0 0 0 0
1/1/5 Disabled Down 20000 128 P2P 0 0 0 0
1/1/6 Disabled Down 20000 128 P2P 0 0 0 0
1/1/7 Disabled Down 20000 128 P2P 0 0 0 0
1/1/8 Disabled Down 20000 128 P2P 0 0 0 0
1/1/9 Disabled Down 20000 128 P2P 0 0 0 0
1/1/10 Disabled Down 20000 128 P2P 0 0 0 0
1/1/11 Disabled Down 20000 128 P2P 0 0 0 0
1/1/12 Disabled Down 20000 128 P2P 0 0 0 0

Lab 3: Layer 2 optimization and

1/1/13 Disabled Down 20000 128 P2P 0 0 0 0
1/1/14 Disabled Down 20000 128 P2P 0 0 0 0

protection features
1/1/15 Disabled Down 20000 128 P2P 0 0 0 0
1/1/16 Disabled Down 20000 128 P2P 0 0 0 0
1/1/17 Disabled Down 20000 128 P2P 0 0 0 0
1/1/18 Disabled Down 20000 128 P2P 0 0 0 0
1/1/19 Disabled Down 20000 128 P2P 0 0 0 0
1/1/20 Disabled Down 20000 128 P2P 0 0 0 0
1/1/21 Disabled Down 20000 128 P2P 3 69152 2 2
1/1/22 Disabled Down 20000 128 P2P 3 69151 0 2
1/1/23 Disabled Down 20000 128 P2P 0 0 0 0
1/1/24 Disabled Down 20000 128 P2P 0 0 0 0
1/1/27 Designated Forwarding 2000 128 P2P 71055 226 22 4
1/1/28 Disabled Down 20000 128 P2P 69172 3 5 0
lag255 Root Forwarding 2000 64 P2P 544 2321 24 18

Topology change flag : True

Number of topology changes : 31
Last topology change occurred : 53 seconds ago

Task 3-6: Implement BPDU guard 111

Task 3-7: Implement root guard
Root guard is a feature implemented at the aggregation/core layer of your network on the downlinks of
these switches. Root guard looks for BPDU violations where, if an incoming bridge ID (BID) has a lower
number (referred to as a "superior" BID) than the aggregation/core switches, a violation occurs and the
offending port is logically disabled.
In this task, you will enable this on LAG 1 and LAG 2 of the VSX core switches to cause the access
switches to create root guard violations.

Lab diagram

Objectives
n Implement root guard.
n Verify root guard operation.

Steps
Core-1
1. Open a console connection to Core-1 and enter configuration mode.
2. On Core-1, enable VSX group sync for STP.
ICX-Core-1(config)# vsx
ICX-Core-1(config-vsx)# vsx-sync stp-global
ICX-Core-1(config-vsx)# exit

112 Task 3-7: Implement root guard

 3. Review the STP status locally and on the VSX peer. Both Core-1 and Core-2's STP state shows
they are the root ("This bridge is the root") with the same system MAC that you configured in
LAB 2 for the system MAC address for VSX.
ICX-Core-1(config)# show spanning-tree
Spanning tree status : Enabled Protocol: MSTP

MST0
Root ID Priority : 4096
MAC-Address: 02:01:00:00:01:00
This bridge is the root
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Bridge ID Priority : 4096

MAC-Address: 02:01:00:00:01:00
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
--------- ------------ ---------- ------- --------- ------ -------- -------- ------- ------
lag1 Designated Forwarding 2000 64 P2P 4766 32 22 22
lag2 Designated Forwarding 2000 64 P2P 4959 16 30 12
lag5 Designated Forwarding 20000 64 P2P 4946 0 0 0
lag256 Designated Forwarding 1 64 P2P 4964 421 38 4

Number of topology changes : 47

Last topology change occurred : 84 seconds ago

ICX-Core-1(config)# show spanning-tree vsx-peer

Spanning tree status : Enabled Protocol: MSTP

Lab 3: Layer 2 optimization and

MST0

protection features
Root ID Priority : 4096
MAC-Address: 02:01:00:00:01:00
This bridge is the root
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Bridge ID Priority : 4096

MAC-Address: 02:01:00:00:01:00
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
--------- ------------ ---------- ------- --------- ------ -------- -------- ------- ------
lag1 Designated Forwarding 2000 64 P2P 0 0 0 0
lag2 Designated Forwarding 2000 64 P2P 0 0 0 0
lag5 Designated Forwarding 20000 64 P2P 0 0 0 0
lag256 Designated Forwarding 1 64 P2P 235 4870 4 34

Task 3-7: Implement root guard 113

 Number of topology changes : 47
Last topology change occurred : 96 seconds ago

4. Configure Core-1 with STP root guard on the VSX LAG interfaces towards Access-1 and
Access-2. This will effectively protect the current root bridge and shut down the interface when a
superior BPDU is received on these interfaces.
ICX-Core-1(config)# interface lag 1,2
ICX-Core-1(config-lag-if-<1,2>)# spanning-tree root-guard
ICX-Core-1(config-lag-if-<1,2>)# exit

5. Verify the configuration was pushed to Core-2.

ICX-Core-1(config)# show running-config interface lag1 vsx-peer
interface lag 1 multi-chassis
description access1
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed 1,11-13
lacp mode active
hash l4-src-dst
lacp fallback
spanning-tree root-guard
exit

Access-1
6. Configure Access-1 with a priority multiplier of 0.
ICX-Access-1(config)# spanning-tree priority 0

Core-1
7. On Core-1, verify the local STP status and on the VSX peer. Core-1 and Core-2 are still STP roots,
and the state of LAG 2 is Root-Inc with the role Alternate.
ICX-Core-1(config)# show spanning-tree
Spanning tree status : Enabled Protocol: MSTP

MST0
Root ID Priority : 4096
MAC-Address: 02:01:00:00:01:00
This bridge is the root
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Bridge ID Priority : 4096

MAC-Address: 02:01:00:00:01:00
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx

114 Task 3-7: Implement root guard

 --------- ------------ ---------- ------- --------- ------ -------- -------- ------- ------
lag1 Alternate Root-Inc 2000 64 P2P 4938 82 22 24
lag2 Alternate Root-Inc 2000 64 P2P 5131 66 30 14
lag5 Designated Forwarding 20000 64 P2P 5166 0 0 0
lag256 Designated Forwarding 1 64 P2P 5184 641 38 4

Number of topology changes : 47

Last topology change occurred : 521 seconds ago

ICX-Core-1(config)# show spanning-tree vsx-peer

Spanning tree status : Enabled Protocol: MSTP

MST0
Root ID Priority : 4096
MAC-Address: 02:01:00:00:01:00
This bridge is the root
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Bridge ID Priority : 4096

MAC-Address: 02:01:00:00:01:00
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
--------- ------------ ---------- ------- --------- ------ -------- -------- ------- ------
lag1 Alternate Root-Inc 2000 64 P2P 0 0 0 0
lag2 Alternate Root-Inc 2000 64 P2P 0 0 0 0
lag5 Designated Forwarding 20000 64 P2P 0 0 0 0
lag256 Designated Forwarding 1 64 P2P 460 5095 4 34

Number of topology changes : 47

Lab 3: Layer 2 optimization and

Last topology change occurred : 546 seconds ago

protection features
n Question: Why is LAG 2 in a blocked state?
n Answer: Remember that interface 1/1/27 between the two access switches is enabled,
and thus the core switches will see Access-1 via both LAG interfaces.
8. View the port consistencies of the two LAGs on Core-1 and Core-2. Notice that both LAGs are
blocked by the root guard feature.
ICX-Core-1(config)# show spanning-tree inconsistent-ports
Instance ID Blocked Port Reason
------------ -------------- ------------
0 lag1 Root Guard
0 lag2 Root Guard

ICX-Core-1(config)# show spanning-tree inconsistent-ports vsx-peer

Instance ID Blocked Port Reason

Task 3-7: Implement root guard 115

 ------------ -------------- ------------
0 lag1 Root Guard
0 lag2 Root Guard

Access-1
9. On Access-1, change the priority multiplier back to the default value (8).
ICX-Access-1(config)# spanning-tree priority 8

Core-1
10. Verify that the inconsistencies no longer exist and the two LAGs are operational.
ICX-Core-1(config)# show spanning-tree inconsistent-ports
Instance ID Blocked Port Reason
------------ -------------- ------------

ICX-Core-1(config)# show spanning-tree inconsistent-ports vsx-peer

Instance ID Blocked Port Reason
------------ -------------- ------------

ICX-Core-1(config)# show spanning-tree

Spanning tree status : Enabled Protocol: MSTP

MST0
Root ID Priority : 4096
MAC-Address: 02:01:00:00:01:00
This bridge is the root
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Bridge ID Priority : 4096

MAC-Address: 02:01:00:00:01:00
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
--------- ------------ ---------- ------- --------- ------ -------- -------- ------- ------
lag1 Designated Forwarding 2000 64 P2P 4974 276 24 26
lag2 Designated Forwarding 2000 64 P2P 5167 259 32 14
lag5 Designated Forwarding 20000 64 P2P 5391 0 0 0
lag256 Designated Forwarding 1 64 P2P 5410 866 40 4

ICX-Core-1(config)# show spanning-tree vsx-peer

Spanning tree status : Enabled Protocol: MSTP

MST0
Root ID Priority : 4096
MAC-Address: 02:01:00:00:01:00

116 Task 3-7: Implement root guard

 This bridge is the root
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Bridge ID Priority : 4096

MAC-Address: 02:01:00:00:01:00
Hello time(in seconds):2 Max Age(in seconds):20
Forward Delay(in seconds):15

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
--------- ------------ ---------- ------- --------- ------ -------- -------- ------- ------
lag1 Designated Forwarding 2000 64 P2P 0 0 0 0
lag2 Designated Forwarding 2000 64 P2P 0 0 0 0
lag5 Designated Forwarding 20000 64 P2P 0 0 0 0
lag256 Designated Forwarding 1 64 P2P 680 5316 4 36

Number of topology changes : 50

Last topology change occurred : 81 seconds ago

Task 3-8: Implement loop protection

Loop protection is used at the access layer to detect Layer 2 loops to edge devices—for example, if a
VoIP hardware appliance phone, which has two Ethernet ports, had both ports plugged into the same
switch.
In this lab, you will use Access-2 to test this feature, based on the diagram below.

Lab 3: Layer 2 optimization and

protection features

Task 3-8: Implement loop protection 117

Lab diagram

Objectives
n Implement loop protection.
n Verify the implementation of loop protection.

Steps
Access-1
1. Access Access-1's console. Enable interface 1/1/28.
ICX-Access-1(config)# interface 1/1/28
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# exit

2. Set a loop protection timer of 30 seconds.

ICX-Access-1(config)# loop-protect re-enable-timer 30

3. Enable loop protection on interfaces 1/1/27 and 1/1/28. Disable BPDUs on the two interfaces as
well (otherwise, STP will break up the loop, and you want loop protection to deal with the loop).
ICX-Access-1(config)# interface 1/1/27-1/1/28
ICX-Access-1(config-if-<1/1/27-1/1/28>)# loop-protect
ICX-Access-1(config-if-<1/1/27-1/1/28>)# spanning-tree bpdu-filter
[1/1/27] This filter command allows the port to go into a continuous
forwarding mode and spanning tree will not interfere, even if
the port would cause a loop to form in the network topology.
If you suddenly experience high traffic load, shutdown the
port and remove the applicable filter configuration under

118 Task 3-8: Implement loop protection

 interface context using the following CLI command(s):
no spanning-tree bpdu-filter
no spanning-tree rpvst-filter
[1/1/28] This filter command allows the port to go into a continuous
forwarding mode and spanning tree will not interfere, even if
the port would cause a loop to form in the network topology.
If you suddenly experience high traffic load, shutdown the
port and remove the applicable filter configuration under
interface context using the following CLI command(s):
no spanning-tree bpdu-filter
no spanning-tree rpvst-filter
ICX-Access-1(config-if-<1/1/27-1/1/28>)# exit

4. Verify that loop protection was enabled on the interfaces.

ICX-Access-1(config)# show loop-protect

Status and Counters - Loop Protection Information

Transmit Interval : 5 (sec)

Port Re-enable Timer : 30 (sec)
Loop Detected Trap : Disabled

Interface 1/1/27
Loop-protect enabled : Yes
Action on loop detection : TX disable
Loop detected count : 0
Loop detected : No
Interface status : up

Interface 1/1/28
Loop-protect enabled : Yes

Lab 3: Layer 2 optimization and

Action on loop detection : TX disable
Loop detected count : 0

protection features
Loop detected : No
Interface status : down

Access-2
5. Access Access-2's console. Enable interface 1/1/28.
ICX-Access-2(config)# interface 1/1/28
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit

6. Disable the LAG 2 interface.

ICX-Access-2(config)# interface lag 2
ICX-Access-2(config-lag-if)# shutdown
ICX-Access-2(config-lag-if)# exit

7. Disable STP globally.

Task 3-8: Implement loop protection 119

 ICX-Access-2(config)# no spanning-tree

Access-1
8. On Access-1, verify that loop protection dealt with the loop issue.
ICX-Access-1(config)# show loop-protect

Status and Counters - Loop Protection Information

Transmit Interval : 5 (sec)

Port Re-enable Timer : 30 (sec)
Loop Detected Trap : Disabled

Interface 1/1/27
Loop-protect enabled : Yes
Action on loop detection : TX disable
Loop detected count : 1
Loop detected : Yes
Detected on VLAN : 1
Detected at : 2024-05-08T17:40:20
Interface status : down

Interface 1/1/28
Loop-protect enabled : Yes
Action on loop detection : TX disable
Loop detected count : 1
Loop detected : Yes
Detected on VLAN : 1
Detected at : 2024-05-08T17:40:20
Interface status : down

Because you defined a timer of 30 seconds, after the violation occurs and 30 seconds has
expired, the interfaces would be re-enabled. However, if the loop condition still exists, the inter-
faces would, logically, be disabled again.
Access-1 and Access-2
9. Disable interfaces 1/1/27 and 1/1/28.
ICX-Access-1(config)# interface 1/1/27-1/1/28
ICX-Access-1(config-if-<1/1/27-1/1/28>)# shutdown
ICX-Access-1(config-if-<1/1/27-1/1/28>)# exit

ICX-Access-2(config)# interface 1/1/27-1/1/28

ICX-Access-2(config-if-<1/1/27-1/1/28>)# shutdown
ICX-Access-2(config-if-<1/1/27-1/1/28>)# exit

Access-2
10. Re-enable STP.

120 Task 3-8: Implement loop protection

 ICX-Access-2(config)# spanning-tree
ICX-Access-2(config)# show spanning-tree mst-config
MST configuration information
MST config ID : icx
MST config revision : 1
MST config digest : AC36177F50283CD4B83821D8AB26DE62
Number of instances : 0

Instance ID Member VLANs

--------------- ----------------------------------
0 1-4094

11. Re-enable the LAG 2 interface.

ICX-Access-2(config)# interface lag 2
ICX-Access-2(config-lag-if)# no shutdown
ICX-Access-2(config-lag-if)# exit

Access-1 and Access-2

12. Verify the operation of MSTP.
ICX-Access-1(config)# show spanning-tree mst 0
#### MST0
Vlans mapped: 1-4094
Bridge Address:10:4f:58:f6:e3:80 priority:32768
Operational Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in
seconds):20 txHoldCount(in pps): 6
Configured Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in
seconds):20 Max-Hops:20
Root Address:02:01:00:00:01:00 Priority:4096
Port:lag255 Path cost:0
Regional Root Address:02:01:00:00:01:00 Priority:4096
Internal cost:2000 Rem Hops:19

Lab 3: Layer 2 optimization and

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx

protection features
--------- ------------ ---------- ------- --------- ------ -------- -------- ------- ------
1/1/1 Disabled Down 20000 128 P2P 69150 0 0 0
1/1/2 Disabled Down 20000 128 P2P 0 0 0 0
1/1/3 Designated Forwarding 20000 128 P2P 163858 0 0 0
1/1/4 Disabled Down 20000 128 P2P 0 0 0 0
1/1/5 Disabled Down 20000 128 P2P 0 0 0 0
1/1/6 Disabled Down 20000 128 P2P 0 0 0 0
1/1/7 Disabled Down 20000 128 P2P 0 0 0 0
1/1/8 Disabled Down 20000 128 P2P 0 0 0 0
1/1/9 Disabled Down 20000 128 P2P 0 0 0 0
1/1/10 Disabled Down 20000 128 P2P 0 0 0 0
1/1/11 Disabled Down 20000 128 P2P 0 0 0 0
1/1/12 Disabled Down 20000 128 P2P 0 0 0 0
1/1/13 Disabled Down 20000 128 P2P 0 0 0 0
1/1/14 Disabled Down 20000 128 P2P 0 0 0 0
1/1/15 Disabled Down 20000 128 P2P 0 0 0 0
1/1/16 Disabled Down 20000 128 P2P 0 0 0 0

Task 3-8: Implement loop protection 121

 1/1/17 Disabled Down 20000 128 P2P 0 0 0 0
1/1/18 Disabled Down 20000 128 P2P 0 0 0 0
1/1/19 Disabled Down 20000 128 P2P 0 0 0 0
1/1/20 Disabled Down 20000 128 P2P 0 0 0 0
1/1/21 Disabled Down 20000 128 P2P 3 69152 2 2
1/1/22 Disabled Down 20000 128 P2P 3 69151 0 2
1/1/23 Disabled Down 20000 128 P2P 0 0 0 0
1/1/24 Disabled Down 20000 128 P2P 0 0 0 0
1/1/27 Disabled Down 20000 128 P2P 74501 409 30 6
1/1/28 Disabled Down 20000 128 P2P 69231 183 7 0
lag255 Root Forwarding 2000 64 P2P 790 5912 30 24

Topology change flag : True

Number of topology changes : 39
Last topology change occurred : 896 seconds ago

ICX-Access-2(config)# show spanning-tree mst 0

#### MST0
Vlans mapped: 1-4094
Bridge Address:10:4f:58:fc:b2:40 priority:32768
Operational Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in
seconds):20 txHoldCount(in pps): 6
Configured Hello time(in seconds): 2 Forward delay(in seconds):15 Max-age(in
seconds):20 Max-Hops:20
Root Address:02:01:00:00:01:00 Priority:4096
Port:lag255 Path cost:0
Regional Root Address:02:01:00:00:01:00 Priority:4096
Internal cost:2000 Rem Hops:19

Port Role State Cost Priority Type BPDU-Tx BPDU-Rx TCN-Tx TCN-Rx
--------- ------------ ---------- ------- --------- ------ -------- -------- ------- ------
1/1/1 Disabled Down 20000 128 P2P 0 0 0 0
1/1/2 Disabled Down 20000 128 P2P 0 0 0 0
1/1/3 Disabled Down 20000 128 P2P 0 0 0 0
1/1/4 Designated Forwarding 20000 128 P2P 79 0 0 0
1/1/5 Disabled Down 20000 128 P2P 0 0 0 0
1/1/6 Disabled Down 20000 128 P2P 0 0 0 0
1/1/7 Disabled Down 20000 128 P2P 0 0 0 0
1/1/8 Disabled Down 20000 128 P2P 0 0 0 0
1/1/9 Disabled Down 20000 128 P2P 0 0 0 0
1/1/10 Disabled Down 20000 128 P2P 0 0 0 0
1/1/11 Disabled Down 20000 128 P2P 0 0 0 0
1/1/12 Disabled Down 20000 128 P2P 0 0 0 0
1/1/13 Disabled Down 20000 128 P2P 0 0 0 0
1/1/14 Disabled Down 20000 128 P2P 0 0 0 0
1/1/15 Disabled Down 20000 128 P2P 0 0 0 0
1/1/16 Disabled Down 20000 128 P2P 0 0 0 0
1/1/17 Disabled Down 20000 128 P2P 0 0 0 0
1/1/18 Disabled Down 20000 128 P2P 0 0 0 0
1/1/19 Disabled Down 20000 128 P2P 0 0 0 0

122 Task 3-8: Implement loop protection

 1/1/20 Disabled Down 20000 128 P2P 0 0 0 0
1/1/21 Disabled Down 20000 128 P2P 0 0 0 0
1/1/22 Disabled Down 20000 128 P2P 0 0 0 0
1/1/23 Disabled Down 20000 128 P2P 0 0 0 0
1/1/24 Disabled Down 20000 128 P2P 0 0 0 0
1/1/27 Disabled Down 20000 128 P2P 0 2 0 0
1/1/28 Disabled Down 20000 128 P2P 0 2 0 0
lag255 Root Forwarding 2000 64 P2P 3 78 2 0

Topology change flag : True

Number of topology changes : 1
Last topology change occurred : 154 seconds ago

Task 3-9: Implement PVLANs (optional)

This task is optional. If you have enough time, then please do this task. If you skip this task and want to
come back later and do it, then you only need to load the icx-lab02-vsx checkpoint on both core and
access switches—you do not need to complete the previous tasks of this lab to do this particular task.
With a PVLAN, you can partition a VLAN by grouping multiple sets of ports that need Layer 2 traffic
isolation. This requires the creation of a primary VLAN and subordinate (or secondary) VLANs. In this
task, you will configure PVLANs on the access and core switches. VLAN 11 will be used to test the isol-
ated VLAN function, while VLAN 12 will be used to test the community VLAN function. You will test
the operation of both individually, by using PC3 and PC4.

Lab 3: Layer 2 optimization and

protection features

Task 3-9: Implement PVLANs (optional) 123

Lab diagram

Objectives
n Implement PVLANs.
n Explore the use of isolated, promiscuous, and community ports.

Steps
All four switches
1. Verify the VLAN configuration on all four switches. VLANs 1 and 11–13 should exist on all three
switches.
ICX-Core-1(config)# show vlan

-------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-------------------------------------------------------------------------------
1 DEFAULT_VLAN_1 up ok default lag1-lag2,lag5,lag256
11 VLAN11 up ok static lag1-lag2,lag5,lag256
12 VLAN12 up ok static lag1-lag2,lag5,lag256
13 VLAN13 up ok static lag1-lag2,lag5,lag256

ICX-Core-2(config)# show vlan

-------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-------------------------------------------------------------------------------

124 Task 3-9: Implement PVLANs (optional)

 1 DEFAULT_VLAN_1 up ok default lag1-lag2,lag5,lag256
11 VLAN11 up ok static lag1-lag2,lag5,lag256
12 VLAN12 up ok static lag1-lag2,lag5,lag256
13 VLAN13 up ok static lag1-lag2,lag5,lag256

ICX-Access-1(config)# show vlan

-------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-------------------------------------------------------------------------------
1 DEFAULT_VLAN_1 up ok default 1/1/1-1/1/2,1/1/4-1/1/24,
1/1/27-1/1/28,lag255
11 VLAN11 up ok static 1/1/3,lag255
12 VLAN12 up ok static lag255
13 VLAN13 up ok static lag255

ICX-Access-2(config)# show vlan

-------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-------------------------------------------------------------------------------
1 DEFAULT_VLAN_1 up ok default 1/1/1-1/1/3,1/1/5-1/1/24,
1/1/27-1/1/28,lag255
11 VLAN11 up ok static lag255
12 VLAN12 up ok static 1/1/4,lag255
13 VLAN13 up ok static lag255

Core-1 and Core-2

2. On the VSX primary, define VLAN 11 as a primary VLAN.

Lab 3: Layer 2 optimization and

ICX-Core-1(config)# vlan 11

protection features
ICX-Core-1(config-vlan-11)# private-vlan primary
ICX-Core-1(config-vlan-11)# vsx-sync
ICX-Core-1(config-vlan-11)# exit

3. On the VSX primary, create VLAN 111 and define it as an isolated VLAN for the primary VLAN
11. Synchronize this to the VSX peer.
ICX-Core-1(config)# vlan 111
ICX-Core-1(config-vlan-111)# private-vlan isolated primary-vlan 11
ICX-Core-1(config-vlan-111)# vsx-sync
ICX-Core-1(config-vlan-111)# exit

4. On the VSX primary, define VLAN 12 as a primary VLAN.

ICX-Core-1(config)# vlan 12
ICX-Core-1(config-vlan-12)# private-vlan primary
ICX-Core-1(config-vlan-12)# vsx-sync
ICX-Core-1(config-vlan-12)# exit

Task 3-9: Implement PVLANs (optional) 125

 5. On the VSX primary, create VLAN 112 and define it as a community VLAN for the primary VLAN
12. Synchronize this to the VSX peer.
ICX-Core-1(config)# vlan 112
ICX-Core-1(config-vlan-112)# private-vlan community primary-vlan 12
ICX-Core-1(config-vlan-112)# vsx-sync
ICX-Core-1(config-vlan-112)# exit

6. Verify your VLAN configuration.

ICX-Core-1(config)# show private-vlan type
--------------------
VLAN Type
--------------------
11 primary
12 primary
111 isolated
112 community

ICX-Core-1(config)# show private-vlan type vsx-peer

--------------------
VLAN Type
--------------------
11 primary
12 primary
111 isolated
112 community

7. Allow the secondary VLANs on the LAG 1 and LAG 2 interfaces.

ICX-Core-1(config)# interface lag 1,2
ICX-Core-1(config-lag-if-<1,2>)# vlan trunk allowed 11,12,111,112
ICX-Core-1(config-lag-if-<1,2>)# exit

You do not need to add this configuration to the Core-2 switch since the VSX sync is
enabled or the LAG interfaces in the VSX cluster.

Access-1 and Access-2

8. Repeat this configuration on Access-1 and Access-2.
ICX-Access-1(config)# vlan 11
ICX-Access-1(config-vlan-11)# private-vlan primary
ICX-Access-1(config-vlan-11)# exit
ICX-Access-1(config)# vlan 12
ICX-Access-1(config-vlan-12)# private-vlan primary
ICX-Access-1(config-vlan-12)# exit
ICX-Access-1(config)# vlan 111
ICX-Access-1(config-vlan-111)# private-vlan isolated primary-vlan 11
ICX-Access-1(config-vlan-111)# exit

126 Task 3-9: Implement PVLANs (optional)

 ICX-Access-1(config)# vlan 112
ICX-Access-1(config-vlan-112)# private-vlan community primary-vlan 12
ICX-Access-1(config-vlan-112)# exit

ICX-Access-1(config)# show private-vlan type

--------------------
VLAN Type
--------------------
11 primary
12 primary
111 isolated
112 community

ICX-Access-2(config)# vlan 11
ICX-Access-2(config-vlan-11)# private-vlan primary
ICX-Access-2(config-vlan-11)# exit
ICX-Access-2(config)# vlan 12
ICX-Access-2(config-vlan-12)# private-vlan primary
ICX-Access-2(config-vlan-12)# exit
ICX-Access-2(config)# vlan 111
ICX-Access-2(config-vlan-111)# private-vlan isolated primary-vlan 11
ICX-Access-2(config-vlan-111)# exit
ICX-Access-2(config)# vlan 112
ICX-Access-2(config-vlan-112)# private-vlan community primary-vlan 12
ICX-Access-2(config-vlan-112)# exit

ICX-Access-2(config)# show private-vlan type

--------------------
VLAN Type
--------------------

Lab 3: Layer 2 optimization and

11 primary
12 primary

protection features
111 isolated
112 community

Test the isolated VLAN

In this part of the task, you will test your isolated VLAN (11 and 111) configuration.
Access-1
1. Assign interface 1/1/3 to the isolated VLAN (111) and verify VLAN 111's assignment.
ICX-Access-1(config)# interface 1/1/3
ICX-Access-1(config-if)# no vlan access 11
ICX-Access-1(config-if)# private-vlan port-type secondary
ICX-Access-1(config-if)# vlan access 111
ICX-Access-1(config-if)# exit

Task 3-9: Implement PVLANs (optional) 127

 ICX-Access-1(config)# show vlan 111

-------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-------------------------------------------------------------------------------
111 VLAN111 up ok static 1/1/3,lag255

Access-2
2. Assign interface 1/1/4 to the isolated VLAN (111) and verify VLAN 111's assignment.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# no vlan access 12
ICX-Access-2(config-if)# private-vlan port-type secondary
ICX-Access-2(config-if)# vlan access 111

ICX-Access-2(config-if)# show vlan 111

-------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-------------------------------------------------------------------------------
111 VLAN111 up ok static 1/1/4,lag255

PC3
3. Reacquire an IP address on PC3. Verify that PC3 requires an IP address in the primary VLAN 11.
C:\Users\student> ipconfig /release

Windows IP Configuration

Ethernet adapter Do NOT Touch!:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 172.16.54.63
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter OOBM:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.251.13.90
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.251.13.254

Ethernet adapter Lab NIC - 6300-A Port 3:

128 Task 3-9: Implement PVLANs (optional)

 Connection-specific DNS Suffix . :
Default Gateway . . . . . . . . . :

C:\Users\student> ipconfig /renew

Windows IP Configuration

Ethernet adapter Do NOT Touch!:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 172.16.54.63
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter OOBM:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.251.13.90
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.251.13.254

Ethernet adapter Lab NIC - 6300-A Port 3:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.11.51
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.11.1

PC4

Lab 3: Layer 2 optimization and

4. Reacquire an IP address on PC4. Since LAG 255 on Access-2 is a promiscuous port, by default,

protection features
DHCP should work. Verify that PC3 received an IP address.
C:\Users\student> ipconfig /release

Windows IP Configuration

Ethernet adapter Do NOT Touch!:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 172.16.54.83
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter Lab NIC - 6300-B Port 4:

Task 3-9: Implement PVLANs (optional) 129

 Connection-specific DNS Suffix . :
Default Gateway . . . . . . . . . :

C:\Users\student> ipconfig /renew

Windows IP Configuration

Ethernet adapter Do NOT Touch!:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 172.16.54.83
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter Lab NIC - 6300-B Port 4:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.11.53
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.11.1

5. Test if PC4 can ping PC3.

C:\Users\student> ping 10.1.11.xx

Pinging 10.1.11.51 with 32 bytes of data:

Reply from 10.1.11.53: Destination host unreachable.
Reply from 10.1.11.53: Destination host unreachable.
Reply from 10.1.11.53: Destination host unreachable.
Reply from 10.1.11.53: Destination host unreachable.

Ping statistics for 10.1.11.51:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
n Question: What happens when you perform the ping?
n Answer: It fails because PC3 and PC4 are in an isolated VLAN, and therefore, com-
munication between the isolated ports is denied.
6. Test if PC4 can ping the default gateway IP address (this should be successful).
C:\Users\student> ping 10.1.11.1

Pinging 10.1.11.1 with 32 bytes of data:

Reply from 10.1.11.1: bytes=32 time<1ms TTL=64
Reply from 10.1.11.1: bytes=32 time<1ms TTL=64
Reply from 10.1.11.1: bytes=32 time<1ms TTL=64
Reply from 10.1.11.1: bytes=32 time<1ms TTL=64

130 Task 3-9: Implement PVLANs (optional)

 Ping statistics for 10.1.11.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Test the community VLAN

In this part of the task, you will test your community VLAN (12 and 112) configuration.
Access-1
1. Access Access-1's console. Assign interface 1/1/3 to the community VLAN (112). Verify the
VLAN interface associations.
ICX-Access-1(config)# interface 1/1/3
ICX-Access-1(config-if)# no vlan access 111
ICX-Access-1(config-if)# vlan access 112
ICX-Access-1(config-if)# exit

ICX-Access-1(config)# show vlan 112

-------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-------------------------------------------------------------------------------
112 VLAN112 up ok static 1/1/3,lag255

Access-2
2. Access Access-2's console. Assign interface 1/1/4 to the community VLAN (112). Verify the
VLAN interface associations.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# no vlan access 111
ICX-Access-2(config-if)# vlan access 112

Lab 3: Layer 2 optimization and

ICX-Access-2(config-if)# exit

protection features
ICX-Access-2(config)# show vlan 112

-------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-------------------------------------------------------------------------------
112 VLAN112 up ok static 1/1/4,lag255

PC3
3. Reacquire an IP address on PC3. Verify that PC3 requires an IP address in the primary VLAN 12.
C:\Users\student> ipconfig /release

C:\Users\student> ipconfig /renew

Task 3-9: Implement PVLANs (optional) 131

 Windows IP Configuration

Ethernet adapter Do NOT Touch!:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 172.16.54.63
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter OOBM:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.251.13.90
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.251.13.254

Ethernet adapter Lab NIC - 6300-A Port 3:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.12.52
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.12.1

PC4
4. Reacquire an IP address on PC4. Verify that PC4 requires an IP address in the primary VLAN 12.
C:\Users\student> ipconfig /release
C:\Users\student> ipconfig /renew

Windows IP Configuration

Ethernet adapter Do NOT Touch!:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 172.16.54.83
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter Lab NIC - 6300-B Port 4:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.12.51
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.12.1

5. Test if PC4 can ping PC3.

C:\Users\student> ping 10.1.12.52

132 Task 3-9: Implement PVLANs (optional)

 Pinging 10.1.12.52 with 32 bytes of data:
Reply from 10.1.12.52: bytes=32 time=1ms TTL=128
Reply from 10.1.12.52: bytes=32 time=1ms TTL=128
Reply from 10.1.12.52: bytes=32 time<1ms TTL=128
Reply from 10.1.12.52: bytes=32 time<1ms TTL=128

Ping statistics for 10.1.12.52:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
n Question: What happens when you perform the ping?
n

n Answer: It succeeds because PC3 and PC4 are in the same PVLAN community (112).
6. Test if PC4 can ping the default gateway IP address (this should be successful).
C:\Users\student> ping 10.1.12.1

Pinging 10.1.12.1 with 32 bytes of data:

Reply from 10.1.12.1: bytes=32 time<1ms TTL=64
Reply from 10.1.12.1: bytes=32 time<1ms TTL=64
Reply from 10.1.12.1: bytes=32 time<1ms TTL=64
Reply from 10.1.12.1: bytes=32 time<1ms TTL=64

Ping statistics for 10.1.12.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

This lab does not require you to save checkpoints on the switches. This lab is not

Lab 3: Layer 2 optimization and

used in any later labs. Lab 4 will have you begin by loading the LAB 02 VSX check-

protection features
point configuration.

You have completed Lab 3!

Task 3-9: Implement PVLANs (optional) 133

[This page intentionally left blank]

134 Task 3-9: Implement PVLANs (optional)

Lab 4.1: OSPF single area—basic OSPF
configuration

Lab 4.1: OSPF single area—basic OSPF configuration

Lab diagram

Overview
In this lab activity, OSPF will be configured using a single backbone area (0.0.0.0) on the devices in the
lab. What you will be doing in this lab is a review of what is in the Campus Access Fundamentals course.
In upcoming lab activities, additional areas will be introduced.

Objectives
n Use loopback interfaces.
n Configure single area OSPF on AOS-CX switches.
n Review OSPF passive interfaces.

Lab 4.1: OSPF single area—basic OSPF configuration 135

Task 4.1-1: Verify lab starting configuration
Objectives
n If you have just completed Lab 2 Configuring HPE Aruba Networking Virtual Switching
eXtension (VSX), you can skip this task and move to the next task.
n If you have completed any other lab and are performing this lab again, complete the following
steps to get the base configuration on the devices.

Steps
1. Open a console connection to Access-1. Log in using admin/aruba123.
ICX-Access-1# copy checkpoint icx-lab02-vsx running-config
Configuration changes will take time to process, please be patient.
ICX-Access-1#

2. Open a console connection to Access-2. Log in using admin/aruba123.

ICX-Access-2# copy checkpoint icx-lab02-vsx running-config
Configuration changes will take time to process, please be patient.
ICX-Access-2#

3. Open a console connection to Core-1. Log in using admin/aruba123.

ICX-Core-1# copy checkpoint icx-lab02-vsx running-config
Configuration changes will take time to process, please be patient.
ICX-Core-1#

4. Open a console connection to Core-2. Log in using admin/aruba123.

ICX-Core-2# copy checkpoint icx-lab02-vsx running-config
Configuration changes will take time to process, please be patient.
ICX-Core-2#

Task 4.1-2: Basic OSPF setup for the core (area 0)

In this task, you will set up a basic OSPF configuration for area 0, as shown in the following diagram.

136 Task 4.1-1: Verify lab starting configuration

 Lab Diagram

Objectives
n Use loopback interfaces.
n Define the OSPF single area configuration.
n Set up OSPF in a VSX cluster.
n Implement OSPF point-to-point connections.
n Implement OSPF passive interfaces.

Steps
Core-1
1. Open a terminal connection to Core-1 and enter configuration mode.
2. Define a new IP loopback interface and assign the IP address.
ICX-Core-1(config)# interface loopback 0
ICX-Core-1(config-loopback-if)# ip address 10.1.0.2/32
ICX-Core-1(config-loopback-if)# exit

3. Start a new OSPF process with process ID 1. Assign the same IP address of the loopback inter-
face as the router ID to ensure stability for OSPF.
n The process ID is locally significant.
n By default, the process is linked to the default VRF.
ICX-Core-1(config)# router ospf 1
Lab 4.1: OSPF single area—basic

ICX-Core-1(config-ospf-1)# router-id 10.1.0.2

OSPF configuration

4. Review the current OSPF status.

ICX-Core-1(config-ospf-1)# show ip ospf
VRF : default Process : 1
----------------------------------------------------

Task 4.1-2: Basic OSPF setup for the core (area 0) 137
 RouterID : 10.1.0.2 OSPFv2 : Enabled

BFD : Disabled SPF Start Interval : 200 ms

SPF Hold Interval : 1000 ms SPF Max Wait Interval : 5000 ms
LSA Start Time : 5000 ms LSA Hold Time : 0 ms
LSA Max Wait Time : 0 ms LSA Arrival : 1000 ms
External LSAs : 0 Checksum Sum : 0

ECMP : 4 Reference Bandwidth : 100000 Mbps

Area Border : false AS Border : false
GR Status : Enabled GR Interval : 120 sec
GR State : inactive GR Exit Status : none

GR Helper : Enabled GR Strict LSA Check : Enabled

GR Ignore Lost I/F : Disabled

Summary address:

Area Total Active

------------------------------
Normal 0 0
Stub 0 0
NSSA 0 0

5. Define area 0.
ICX-Core-1(config-ospf-1)# area 0

6. Review the current OSPF LSDB. Since no interfaces have been enabled for OSPF, the database
will not yet contain any LSA information.
ICX-Core-1(config-ospf-1)# show ip ospf lsdb
No OSPF LSAs found on VRF default.
ICX-Core-1(config-ospf-1)# exit

7. Assign the loopback interface to the OSPF process.

ICX-Core-1(config)# interface loopback 0
ICX-Core-1(config-loopback-if)# ip ospf 1 area 0
ICX-Core-1(config-loopback-if)# exit

The ip ospf command allows fine control over which interface is assigned to which
OSPF process and in which area.

8. Review the LSDB again.

ICX-Core-1(config)# show ip ospf lsdb
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
==========================================================

Router Link State Advertisements (Area 0.0.0.0)

138 Task 4.1-2: Basic OSPF setup for the core (area 0)
 ------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 5 0x80000002 0x000058a3 1
n Question: What type of LSA has been added into the LSDB?
n Answer: A type 1 LSA, known as a "router" LSA, has been added.
n Question: How many links (IP subnets) are announced by this LSA?
n Answer: Currently, only the loopback interface is announced in the LSA, so one link.
Dedicated routed link between Core-1 and Core-2
It is best practice to have a dedicated routed subnet between the VSX members. Dedicated
means that there are no other devices in this subnet. This subnet will be used as the transit net-
work (between the two core routers) for any routes that would exist on only one of the VSX mem-
bers.
While technically any existing subnet could be used for this, a cleaner design would have a ded-
icated subnet for this purpose—a subnet that cannot be impacted by any other end-point
devices.
Core-1
9. On Core-1, create VLAN 2 and its SVI interface. It will be used as the transit network. Since only
Core-1 and Core-2 will be using this subnet, a /31 mask is used for IP addressing.

It is best practice to use a /31 subnet for point-to-point links when both sides sup-
port the /31 mask.

ICX-Core-1(config)# vlan 2
ICX-Core-1(config-vlan-2)# vsx-sync
ICX-Core-1(config-vlan-2)# exit
ICX-Core-1(config)# interface vlan 2
ICX-Core-1(config-if-vlan)# ip address 10.1.2.2/31

Core-2
10. Open a terminal connection to Core-2 and enter configuration mode.
11. Define the VLAN 2 interface.
Lab 4.1: OSPF single area—basic

ICX-Core-2(config)# interface vlan 2

ICX-Core-2(config-if-vlan)# ip address 10.1.2.3/31
OSPF configuration

12. Verify connectivity to Core-1 with a ping.

ICX-Core-2(config-if-vlan)# ping 10.1.2.2
PING 10.1.2.2 (10.1.2.2) 100(128) bytes of data.
108 bytes from 10.1.2.2: icmp_seq=1 ttl=64 time=14.1 ms

Task 4.1-2: Basic OSPF setup for the core (area 0) 139
 108 bytes from 10.1.2.2: icmp_seq=2 ttl=64 time=0.231 ms
<output omitted>
ICX-Core-2(config-if-vlan)# exit

Core-1
13. Enable OSPF on interface VLAN 2 for OSPF process 1 area 0.
ICX-Core-1(config-if-vlan)# ip ospf 1 area 0

It is best practice to use the lowest possible cost for this link. By default, the cost is
calculated based on the interface bandwidth, using 100 Gbps as the reference. This
results in a cost of 100 by default for the VLAN interfaces.
For the VSX transit link, the lowest possible cost will be set, which is a cost of 1.

14. On Core-1, apply this cost to interface VLAN 2.

ICX-Core-1(config-if-vlan)# ip ospf cost 1
ICX-Core-1(config)# exit

15. Review the LSDB again.

ICX-Core-1(config)# show ip ospf lsdb
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
==========================================================

Router Link State Advertisements (Area 0.0.0.0)

------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 455 0x80000002 0x000058a3 2
10.1.12.3 10.1.12.3 457 0x80000002 0x00000fee 1

Network Link State Advertisements (Area 0.0.0.0)

-------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.2.3 10.1.12.3 462 0x80000001 0x00009376
n Question: How many links are active for the router LSA 10.1.0.2?
n Answer: There are two links now: loopback and VLAN2.
n Question: Who has the router ID of 10.1.12.3, and how was this selected?
n Answer: Core-2 has router ID 10.1.12.3. The default behavior is that if there are no loop-
backs, the highest active IP address is selected.

140 Task 4.1-2: Basic OSPF setup for the core (area 0)
 n Question: How was OSPF configured on Core-2?
n Answer: It was configured by VSX synchronization from Lab 2.
ICX-Core-1(config)# show run vsx
vsx
system-mac 02:01:00:00:01:00
inter-switch-link lag 256
role primary
keepalive peer 192.168.0.1 source 192.168.0.0 vrf KA
vsx-sync aaa bfd-global bgp dhcp-relay mclag-interfaces ospf qos-global route-
map vsx-global
interface lag 256
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
interface 1/1/47
no shutdown
lag 256
interface 1/1/46
no shutdown
lag 256
interface lag 1 multi-chassis
description access1
no shutdown
no routing
vlan trunk native 1

Core-2
16. Configure Core-2 for OSPF. First, review the current OSPF configuration.
ICX-Core-2(config)# show running-config ospf
router ospf 1
area 0.0.0.0
interface vlan2
ip ospf 1 area 0.0.0.0
ip ospf cost 1
n Question: Why is there already an OSPF configuration on Core-2?
n Answer: VSX sync is enabled for OSPF, so many OSPF configurations are automatically
synchronized to Core-2.
Lab 4.1: OSPF single area—basic

17. Configure the loopback and set the OSPF router ID.
OSPF configuration

n IP loopback 0: 10.1.0.3/32
n OSPF process 1

Task 4.1-2: Basic OSPF setup for the core (area 0) 141
 n Router ID 10.1.0.3/32
n Define area 0
ICX-Core-2(config)# interface loopback 0
ICX-Core-2(config-loopback-if)# ip address 10.1.0.3/32
ICX-Core-2(config-loopback-if)# exit

ICX-Core-2(config)# router ospf 1

ICX-Core-2(config-ospf-1)# router-id 10.1.0.3
OSPFv2 protocol will be reset.
Do you want to continue (y/n)? y
ICX-Core-2(config-ospf-1)# exit

Changing the OSPF router ID requires the OSPF process to restart. Make sure to con-
firm the restart by answering y.

18. On Core-2, check the current configuration of the loopback 0 interface.

ICX-Core-2(config)# show run interface loopback 0
n Question: Is OSPF enabled on the interface? If so, why?
n Answer: Yes, OSPF is enabled. VSX OSPF configuration synchronization took care of this.
Core-1
19. On Core-1, review the OSPF LSDB.
ICX-Core-1(config)# show ip ospf lsdb
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Router Link State Advertisements (Area 0.0.0.0)

------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 601 0x80000005 0x00000c55 2
10.1.0.3 10.1.0.3 602 0x80000002 0x0000263a 2

Network Link State Advertisements (Area 0.0.0.0)

-------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.2.2 10.1.0.2 606 0x80000001 0x0000688f
n Question: What are the two LSA types in this LSDB?
n Answer: Router (type 1) and Network (type 2).

142 Task 4.1-2: Basic OSPF setup for the core (area 0)
 n Question: What does the network LSA represent?
n Answer: A network LSA is representing a multi-access network between two or more
OSPF routers. Since the VLAN 2 Ethernet interface is a broadcast type interface, OSPF will
start the DR/BDR election process by default and the DR will generate the network LSA.
20. Review the current OSPF neighbor list.
ICX-Core-1(config)# show ip ospf neighbors
OSPF Process ID 1 VRF default
==============================

Total Number of Neighbors: 1

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.3 1 FULL/BDR 10.1.2.3 vlan2
n Question: What does DR/BDR stand for?
n Answer: Designated Router and Backup Designated Router are elected on a multi-access
network, such as an Ethernet broadcast network. This is the default operation of OSPF.
OSPF point-to-point connections
A network-type broadcast means that more than two devices could come online in the subnet;
therefore, OSPF prepares itself and elects the DR/BDR for the subnet. This election takes some
time during the link setup phase.
When the design ensures that only two OSPF routers will ever be online in a subnet that is trans-
ported on a broadcast network, the administrator can change the OSPF network type to point-to-
point (p2p).
For this reason, even when the physical network is still broadcast—such as an Ethernet VLAN—
this configuration will instruct OSPF to assume that only one peer is available in this subnet. This
will effectively skip the DR/BDR election process and will also eliminate the type 2 network LSA
from the LSDB.
It is best practice to set the OSPF network type to point-to-point for p2p links.
Core-1
21. On Core-1, change the VLAN 2 interface OSPF network type to point-to-point.
ICX-Core-1(config)# interface vlan 2
Lab 4.1: OSPF single area—basic

ICX-Core-1(config-if-vlan)# ip ospf network point-to-point

ICX-Core-1(config-if-vlan)# exit
OSPF configuration

22. Review the configuration changes that were pushed to Core-2 by VSX sync.
ICX-Core-1(config)# show run interface vlan2 vsx-peer
interface vlan2
ip address 10.1.2.3/31

Task 4.1-2: Basic OSPF setup for the core (area 0) 143
 ip ospf 1 area 0.0.0.0
ip ospf cost 1
ip ospf network point-to-point
exit

23. On Core-1, review the OSPF LSDB. The network LSA that was previously present for the broad-
cast transit network has now been removed.
ICX-Core-1(config)# show ip ospf lsdb
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Router Link State Advertisements (Area 0.0.0.0)

------------------------------------------------

LSID ADV Router Age Seq# Checksum

---------------------------------------------------------------
10.1.0.2 10.1.0.2 130 0x80000004 0x00007163
10.1.0.3 10.1.0.3 131 0x80000004 0x0000874a

Route verification
24. Verify there is an OSPF route in the routing table for the peer core switch loopback interface
using the show ip route ospf command.

The show ip route command has many filtering options. In real world environments
with many routes, these filter options can help the administrator to reduce the out-
put of the command.

ICX-Core-1(config)# show ip route ospf

Displaying ipv4 routes selected for forwarding

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

VRF: default

Prefix Nexthop Interface VRF(egress) Origin/ Distance/ Age

Type Metric
-------------------------------------------------------------------------------------------
10.1.0.3/32 10.1.2.3 vlan2 - O [110/1] 00h:01m:18s

Total Route Count : 1

144 Task 4.1-2: Basic OSPF setup for the core (area 0)
 25. Verify connectivity between the loopback interfaces with a ping from the local loopback IP
address to the peer switch loopback IP address.
ICX-Core-1(config)# ping 10.1.0.3 source loopback0
PING 10.1.0.3 (10.1.0.3) from 10.1.0.2 : 100(128) bytes of data.
108 bytes from 10.1.0.3: icmp_seq=1 ttl=64 time=0.179 ms
108 bytes from 10.1.0.3: icmp_seq=2 ttl=64 time=0.174 ms
108 bytes from 10.1.0.3: icmp_seq=3 ttl=64 time=0.186 ms
108 bytes from 10.1.0.3: icmp_seq=4 ttl=64 time=0.205 ms
108 bytes from 10.1.0.3: icmp_seq=5 ttl=64 time=0.248 ms

--- 10.1.0.3 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4086ms
rtt min/avg/max/mdev = 0.174/0.198/0.248/0.029 ms
n Question: Why is the loopback IP address configured as the source IP for this test?
n Answer: By default, a router will use the IP address of the outbound interface as the
source IP. In this case, that would have been the VLAN 2 interface. If the administrator
wants to test if the remote router has an entry in the routing table for the local loopback,
the loopback can be set as the source IP.
26. Review the OSPF neighbors.
ICX-Core-1(config)# show ip ospf neighbors
OSPF Process ID 1 VRF default
==============================

Total Number of Neighbors: 1

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.3 n/a FULL 10.1.2.3 vlan2

Review the detailed OSPF neighbor state

ICX-Core-1(config)# show ip ospf neighbors 10.1.0.3
VRF : default Process : 1
---------------------------------------------------------

Router-Id : 10.1.0.3 Area Id : 0.0.0.0

Interface : vlan2 Address : 10.1.2.3
State : FULL Neighbor Priority : n/a
Dead Timer Due : 00:00:35 Options : 0x42
Lab 4.1: OSPF single area—basic

Time Since Last State Change : 00h:04m:06s

27. Review the OSPF interfaces, noting the state of each interface.
OSPF configuration

ICX-Core-1(config)# show ip ospf interface

Codes: DR - Designated router BDR - Backup Designated router

Interface loopback0 is up, line protocol is up

Task 4.1-2: Basic OSPF setup for the core (area 0) 145
 -----------------------------------------------

VRF : default Process : 1

IP Address : 10.1.0.2/32 Area : 0.0.0.0

Status : Up Network Type : Loopback

Hello Interval : 10 sec Dead Interval : 40 sec

Transit Delay : 1 sec Retransmit Interval : 5 sec
BFD : Disabled Link Speed : NA
Cost Configured : NA Cost Calculated : NA
State/Type : Loopback Router Priority : 1
DR : No BDR : No
Link LSAs : 0 Checksum Sum : 0
Authentication : No Passive : No

Codes: DR - Designated router BDR - Backup Designated router

Interface vlan2 is up, line protocol is up

-------------------------------------------

VRF : default Process : 1

IP Address : 10.1.2.2/31 Area : 0.0.0.0

Status : Up Network Type : Point-to-point

Hello Interval : 10 sec Dead Interval : 40 sec

Transit Delay : 1 sec Retransmit Interval : 5 sec
BFD : Disabled Link Speed : 1000 Mbps
Cost Configured : 1 Cost Calculated : 1
State/Type : Point-to-point Router Priority : n/a
DR : No BDR : No
Link LSAs : 0 Checksum Sum : 0
Authentication : No Passive : No

146 Task 4.1-2: Basic OSPF setup for the core (area 0)
Task 4.1-3: OSPF address advertisements and control
Lab Diagram

Objectives
n Enable end-host subnet advertisement into OSPF.
n Configure a passive interface.
n Use the passive interface default.
n Review the administrative distance of OSPF.

Steps
Core-1
1. On Core-1, enable the user VLAN 11 for OSPF in area 0.
ICX-Core-1(config)# interface vlan11
ICX-Core-1(config-if-vlan)# ip ospf 1 area 0
ICX-Core-1(config-if-vlan)# exit

2. Review the running configuration of interface VLAN 11 on both the local device and the VSX
peer (Core-2).
ICX-Core-1(config)# show running interface vlan11
interface vlan 11
vsx-sync active-gateways policies
ip address 10.1.11.2/24
active-gateway ip mac 02:02:00:00:01:00
Lab 4.1: OSPF single area—basic

active-gateway ip 10.1.11.1
l3-counters
OSPF configuration

ip ospf 1 area 0.0.0.0

ip helper-address 10.1.1.6
exit

Task 4.1-3: OSPF address advertisements and control 147

 interface vlan 11
vsx-sync active-gateways policies
ip address 10.1.11.3/24
active-gateway ip mac 02:02:00:00:01:00
active-gateway ip 10.1.11.1
l3-counters
ip ospf 1 area 0.0.0.0
ip helper-address 10.1.1.6
exit

For the VSX OSPF synchronization to work properly, the administrator should use
the same physical uplink interface. For instance, if Core-1 has a routed uplink port
1/1/45, Core-2 should also use interface 1/1/45 as the routed uplink.

3. Review the OSPF neighbors.

ICX-Core-1(config)# show ip ospf neighbors
OSPF Process ID 1 VRF default
==============================

Total Number of Neighbors: 3

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.3 1 FULL/DR 10.1.11.3 vlan11
10.1.0.3 n/a FULL 10.1.2.3 vlan2
n Question: Why did OSPF establish a neighbor relationship over the user VLAN?
n Answer: When an interface is enabled for OSPF, it automatically starts sending hello pack-
ets.
n Question: Is it desired to have OSPF communication over user subnets?
n Answer: Typically, OSPF communication is not enabled on user subnets to protect the
OSPF protocol against malicious neighbors that may be connected to the user subnets.
Passive interfaces
Passive interfaces provide a method to have an interface enabled for OSPF; therefore, the subnet
will be included in the router LSA announcement. But at the same time, the OSPF protocol will be
disabled on this interface, so no OSPF hello packets will be transmitted or received by this inter-
face. Thus, OSPF adjacencies will not occur for passive interfaces.
4. Configure the VLAN 11 interface as a passive/silent interface.
ICX-Core-1(config)# interface vlan 11
ICX-Core-1(config-if-vlan)# ip ospf passive
ICX-Core-1(config-if-vlan)# exit

5. Verify that only the VLAN 2 transit link is now used for the OSPF peering.

148 Task 4.1-3: OSPF address advertisements and control

 ICX-Core-1(config)# show ip ospf neighbors
OSPF Process ID 1 VRF default
==============================

Total Number of Neighbors: 1

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.3 n/a FULL 10.1.2.3 vlan2

Passive interfaces default

If a network has many user subnets, it may be more convenient to set new OSPF interfaces to
passive by default. This means that only the OSPF uplink interfaces must be configured as non-
passive.
The other advantage is that there is no security risk when adding a new user VLAN, since it will
automatically have OSPF disabled.
In the lab setup, VLANs 1, 11, and 12 can have endpoints connected to them, so they can benefit
from the passive default feature. The VLAN 2 interface is a dedicated routed link; therefore, the
passive feature should be turned off for this interface.
6. On Core-1, enter the OSPF configuration context.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# passive-interface default
ICX-Core-1(config-ospf-1)# exit

IMPORTANT: This change will impact the current OSPF adjacencies, so it should be
made during a maintenance window in a production network.

7. Enable the VLAN 2 interface again using no ip ospf passive.

ICX-Core-1(config)# interface vlan 2
ICX-Core-1(config-if-vlan)# no ip ospf passive
ICX-Core-1(config-if-vlan)# exit

8. Add VLAN interfaces 1 and 12 as OSPF-enabled interfaces.

ICX-Core-1(config)# interface vlan 1,12
ICX-Core-1(config-if-vlan-<1,12>)# ip ospf 1 area 0.0.0.0
ICX-Core-1(config-if-vlan-<1,12>)# exit

9. Verify that the new interfaces, VLAN 1 and 12, are now enabled for OSPF.
Lab 4.1: OSPF single area—basic

ICX-Core-1(config)# show ip ospf interface brief

OSPF configuration

OSPF Process ID 1 VRF default

==============================

Total Number of Interfaces: 5

Task 4.1-3: OSPF address advertisements and control 149

 Flags: P - Passive A - Active

Interface Area IP Address/Mask Cost State Status Flags

---------------------------------------------------------------------------------
loopback0 0.0.0.0 10.1.0.2/32 0 Loopback Up P
vlan1 0.0.0.0 10.1.1.2/24 100 DR-other Up P
vlan11 0.0.0.0 10.1.11.2/24 100 DR-other Up P
vlan12 0.0.0.0 10.1.12.2/24 100 DR-other Up P
vlan2 0.0.0.0 10.1.2.2/31 1 Point-to-point Up A
n Question: What does the A indicate for the Flags?
n Answer: It indicates that the interface is non-passive and will attempt to form adjacencies
with other OSPF routers.
The only OSPF adjacency was formed over VLAN 2.
ICX-Core-1(config)# show ip ospf neighbors
OSPF Process ID 1 VRF default
==============================

Total Number of Neighbors: 1

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.3 n/a FULL 10.1.2.3 vlan2

10. Review VLAN 11's interface statistics to confirm that no OSPF packets have been transmitted.
ICX-Core-1(config)# show ip ospf statistics interface vlan11 | include Tx
Tx Hello Packets : 0 Rx Hello Packets : 0
Tx Hello Bytes : 0 Rx Hello Bytes : 0
Tx DD Packets : 0 Rx DD Packets : 0
Tx DD Bytes : 0 Rx DD Bytes : 0
Tx LS Request Packets : 0 Rx LS Request Packets : 0
Tx LS Request Bytes : 0 Rx LS Request Bytes : 0
Tx LS Update Packets : 0 Rx LS Update Packets : 0
Tx LS Update Bytes : 0 Rx LS Update Bytes : 0
Tx LS Ack Packets : 0 Rx LS Ack Packets : 0
Tx LS Ack Bytes : 0 Rx LS Ack Bytes : 0

Review administrative distance

11. First, review the routes learned and calculated by OSPF through the LSDB. These routes will be
presented by OSPF to the IP routing table. Notice that routes that are local on Core-1 have been
learned as i (intra-area) routes based on the router LSA of Core-1.
ICX-Core-1(config)# show ip ospf routes
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table

150 Task 4.1-3: OSPF address advertisements and control

 ---------------------------------------------

Total Number of Routes : 5

10.1.0.3/32 (i) area: 0.0.0.0

via 10.1.2.3 interface vlan2, cost 1 distance 110
10.1.1.0/24 (i) area: 0.0.0.0
directly attached to interface vlan1, cost 100 distance 110
10.1.2.2/31 (i) area: 0.0.0.0
directly attached to interface vlan2, cost 1 distance 110
10.1.11.0/24 (i) area: 0.0.0.0
directly attached to interface vlan11, cost 100 distance 110
10.1.12.0/24 (i) area: 0.0.0.0
directly attached to interface vlan12, cost 100 distance 110
n Question: What is the distance applied to route 10.1.1.0/24?
n Answer: OSPF routes get an administrative distance of 110 by default.
12. Now review the IP routing table.
ICX-Core-1(config)# show ip route

Displaying ipv4 routes selected for forwarding

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

VRF: default

Prefix Nexthop Interface

RF(egress) Origin/ Distance/ Age
Type Metric
--------------------------------------------------------------------------------------
0.0.0.0/0 10.255.101.11 1/1/7 - S [1/0] 02d:03h:11m
10.1.0.2/32 - loopback0 - L [0/0] -
10.1.0.3/32 10.1.2.3 vlan2 - O [110/1] 00h:05m:15s
10.1.1.0/24 - vlan1 - C [0/0] -
10.1.1.2/32 - vlan1 - L [0/0] -
10.1.2.2/31 - vlan2 - C [0/0] -
10.1.2.2/32 - vlan2 - L [0/0] -
10.1.11.0/24 - vlan11 - C [0/0] -
10.1.11.2/32 - vlan11 - L [0/0] -
Lab 4.1: OSPF single area—basic

10.1.12.0/24 - vlan12 - C [0/0] -

10.1.12.2/32 - vlan12 - L [0/0] -
OSPF configuration

10.254.1.0/24 10.255.101.11 1/1/7 - S [1/0] 02d:21h:19m

10.255.101.0/24 - 1/1/7 - C [0/0] -
10.255.101.2/32 - 1/1/7 - L [0/0] -

Task 4.1-3: OSPF address advertisements and control 151

 n Question: The output shows that the 10.1.1.0/24 route was not learned by OSPF. What is
the source of the 10.1.1.0/24 route?
n Answer: The source is connected; this indicates an IP subnet that is locally connected on
the router.
n Question: Why was this route selected by the routing table over the OSPF route?
n Answer: The administrative distance of directly connected routes is 0. Therefore, these
routes will always have precedence, by default, over any other type of route: static or
dynamic. OSPF has a default distance of 110.

Task 4.1-4: OSPF peering using a VSX LAG

Lab Diagram

Objectives
n Configure a VSX LAG with OSPF to neighboring routers.
n Understand and configure the VSX active forwarding feature.

Steps
In this task, you will:
n Define a new routed VLAN between access switches and the VSX core.
n Enable OSPF between Access-1 and the VSX core.

The link between Access-2 and the VSX core will be configured in the following lab.

152 Task 4.1-4: OSPF peering using a VSX LAG

Routed VLAN between Access-1 and core VSX
Core-1
1. On Core-1, define VLAN 101 (to Access-1) and 102 (to Access-2).
ICX-Core-1(config)# vlan 101
ICX-Core-1(config-vlan-101)# vsx-sync
ICX-Core-1(config-vlan-101)# exit

ICX-Core-1(config)# vlan 102

ICX-Core-1(config-vlan-102)# vsx-sync
ICX-Core-1(config-vlan-102)# exit

ICX-Core-1(config)# interface lag 1

ICX-Core-1(config-lag-if)# vlan access 101
ICX-Core-1(config-lag-if)# exit

ICX-Core-1(config)# interface lag 2

ICX-Core-1(config-lag-if)# vlan access 102
ICX-Core-1(config-lag-if)# exit

2. For VLAN 101, configure the IP address and enable OSPF on it.
ICX-Core-1(config)# interface vlan 101
ICX-Core-1(config-if-vlan)# description L3-access-1
ICX-Core-1(config-if-vlan)# ip address 10.1.101.2/24
ICX-Core-1(config-if-vlan)# ip ospf 1 area 0
ICX-Core-1(config-if-vlan)# exit

3. VLAN 102 is only prepared with an IP address at this point. It is not enabled for OSPF at this
time, since this will be done in the next lab (4.2).
ICX-Core-1(config)# interface vlan 102
ICX-Core-1(config-if-vlan)# description L3-Access-2
ICX-Core-1(config-if-vlan)# ip address 10.1.102.2/24
ICX-Core-1(config-if-vlan)# exit

Core-2
4. On Core-2, define VLAN 101 and 102 IP addressing (L2 VLAN and OSFP are automatically
enabled via vsx-sync).
Lab 4.1: OSPF single area—basic

ICX-Core-2(config)# interface vlan 101

ICX-Core-2(config-if-vlan)# ip address 10.1.101.3/24
OSPF configuration

ICX-Core-2(config-if-vlan)# description L3-access-1

ICX-Core-2(config-if-vlan)# exit

Task 4.1-4: OSPF peering using a VSX LAG 153

 ICX-Core-2(config)# interface vlan 102
ICX-Core-2(config-if-vlan)# ip address 10.1.102.3/24
ICX-Core-2(config-if-vlan)# description L3-access-2
ICX-Core-2(config-if-vlan)# exit

Access-1
On Access-1, define the VLAN 101 uplink interface.
5. Access a terminal session on Access-1 and enter configuration mode.
6. Add VLAN 101; define the IP interface.

In the VSX lab activity, LAG 255 was set to allow all VLANs. This is why there is no
step that follows to allow VLAN 101 on the VLAN trunk, since they are automatically
permitted with the existing configuration.

ICX-Access-1(config)# vlan 101

ICX-Access-1(config-vlan-101)# exit
ICX-Access-1(config)# interface vlan 101
ICX-Access-1(config-if-vlan)# description L3-core
ICX-Access-1(config-if-vlan)# ip address 10.1.101.4/24
ICX-Access-1(config-if-vlan)# exit

7. Verify the ping works between Access-1 and Core-1/Core-2.

ICX-Access-1(config)# ping 10.1.101.2
PING 10.1.101.2 (10.1.101.2) 100(128) bytes of data.
108 bytes from 10.1.101.2: icmp_seq=1 ttl=64 time=16.7 ms
<output omitted>

ICX-Access-1(config)# ping 10.1.101.3

PING 10.1.101.3 (10.1.101.3) 100(128) bytes of data.
108 bytes from 10.1.101.3: icmp_seq=1 ttl=64 time=15.4 ms
<output omitted>

8. Configure OSPF on Access-1.

n OSPF router ID, area 0
n Loopback interface with IP 10.1.0.4/32 and enabled for OSPF
n Enable VLAN 101 for OSPF
ICX-Access-1(config)# router ospf 1
ICX-Access-1(config-ospf-1)# router-id 10.1.0.4
ICX-Access-1(config-ospf-1)# enable
ICX-Access-1(config-ospf-1)# area 0
ICX-Access-1(config-ospf-1)# exit

154 Task 4.1-4: OSPF peering using a VSX LAG

 ICX-Access-1(config)# interface loopback 0
ICX-Access-1(config-loopback-if)# ip address 10.1.0.4/32
ICX-Access-1(config-loopback-if)# ip ospf 1 area 0
ICX-Access-1(config-loopback-if)# exit

ICX-Access-1(config)# interface vlan 101

ICX-Access-1(config-if-vlan)# ip ospf 1 area 0
ICX-Access-1(config-if-vlan)# exit

9. Verify OSPF neighbors, where the expectation would be to see Core-1 and Core-2 in the FULL
state.
ICX-Access-1(config)# show ip ospf neighbors
No OSPF neighbor found on VRF default.
n Question: What could be wrong with the configuration?
n Answer: Try to troubleshoot this using these commands on Access-1 and Core-1:
show ip ospf neighbors
show ip ospf interface
show ip ospf statistics interface vlan101

Output example for the statistics:

ICX-Access-1(config-ospf-1)# show ip ospf statistics interface vlan101
OSPF Process ID 1 VRF default, interface vlan101 statistics (cleared 0h4m6s ago)
================================================================================

Tx Hello Packets : 25 Rx Hello Packets : 0

Tx Hello Bytes : 1600 Rx Hello Bytes : 0
Tx DD Packets : 0 Rx DD Packets : 0
Tx DD Bytes : 0 Rx DD Bytes : 0
Tx LS Request Packets : 0 Rx LS Request Packets : 0
Tx LS Request Bytes : 0 Rx LS Request Bytes : 0
Tx LS Update Packets : 0 Rx LS Update Packets : 0
Tx LS Update Bytes : 0 Rx LS Update Bytes : 0
Tx LS Ack Packets : 0 Rx LS Ack Packets : 0
Tx LS Ack Bytes : 0 Rx LS Ack Bytes : 0
<output omitted>

The troubleshooting commands should have shown that there are no receive (Rx) statistics for
the OSPF interface VLAN 101. This is because a passive-interface default was configured on the
VSX core switches, so any new interfaces enabled for OSPF on the VSX core are passive by
Lab 4.1: OSPF single area—basic

default.
OSPF configuration

Core-1
10. On Core-1, enable the new routed VLAN interface for OSPF.

Task 4.1-4: OSPF peering using a VSX LAG 155

 ICX-Core-1(config)# interface vlan 101
ICX-Core-1(config-if-vlan)# no ip ospf passive
ICX-Core-1(config-if-vlan)# exit

Access-1
11. On Access-1, check the OSPF neighbors again.
ICX-Access-1(config)# show ip ospf neighbors
OSPF Process ID 1 VRF default
==============================

Total Number of Neighbors: 2

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.2 1 FULL/DR 10.1.101.2 vlan101
10.1.0.3 1 FULL/BDR 10.1.101.3 vlan101

The role (DR/BDR/DROther) may be different in your output, but the state should be
FULL.

All four switches: Core-1, Core-2, Access-1, and Access-2

12. Save the configurations on all devices using the write memory command.
You have completed Lab 4.1!

156 Task 4.1-4: OSPF peering using a VSX LAG

Lab 4.2: OSPF and multiple areas

Lab 4.2: OSPF and multiple areas

Lab diagram

Overview
This lab activity will introduce multiple areas for OSPF. The lab will demonstrate the benefits of using
multiple areas, such as route aggregation and route filtering.

Objectives
n Configure an OSPF Area Border Router (ABR).
n Demonstrate how routes from one area are announced into other areas.
n Explain the need for the backbone area.
n Apply route aggregation and route filtering at the ABR.

Lab 4.2: OSPF and multiple areas 157

Task 4.2-1: Assign Access-1 to OSPF area 1
Lab diagram

Objectives
n Set up an ABR link between Core-1 and Access-1.
n Verify LSA changes.
n Set up ABR link between Core-2 and Access-1.

Steps
On Core-1, define area 1 and assign interface VLAN 101 to area 1. On Access-1, remove area 0 and
define area 1. Assign interface VLAN 101 to area 1. Verify the OSPF adjacency and OSPF operations.
Verify the area 1 setup between Access-1 and Core-2, and verify OSPF operations.
Core-1
1. Open a terminal connection to Core-1 and enter configuration mode.
2. Under the OSPF context, define a new area with an ID of 1.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# area 1
ICX-Core-1(config-ospf-1)# exit

3. Under the VLAN 101 context, assign area 1 for this interface.
ICX-Core-1(config)# interface vlan 101
ICX-Core-1(config-if-vlan)# ip ospf 1 area 1

4. Verify the current configuration of this interface.

ICX-Core-1(config-if-vlan)# show running current
interface vlan101
description L3-ccess1

158 Task 4.2-1: Assign Access-1 to OSPF area 1

 Lab 4.2: OSPF and multiple areas
ip address 10.1.101.2/24
ip ospf 1 area 0.0.0.1
no ip ospf passive
ICX-Core-1(config-if-vlan)# exit

Verify the LSDB changes on Core-1

In each area database, Core-1 has inserted a router LSA that contains the links for that area. You
will see, in the area 1 database, where there will be a router LSA with one link (the VLAN 101
interface). Due to the VSX synchronization, Core-2 has also inserted a router LSA into this area
1.
5. Review the LSDB for area 1.

It may take a minute for the LSDB to update and display the correct information.

ICX-Core-1(config)# show ip ospf lsdb area 1

OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Router Link State Advertisements (area 0.0.0.1)

------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 18 0x80000002 0x0000744d 1
10.1.0.3 10.1.0.3 19 0x80000002 0x0000724c 1

Network Link State Advertisements (area 0.0.0.1)

-------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.101.3 10.1.0.3 24 0x80000001 0x00000c85

Inter-area Summary Link State Advertisements (area 0.0.0.1)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.0.2 10.1.0.2 63 0x80000001 0x00007daf
10.1.0.2 10.1.0.3 63 0x80000001 0x000081a9
10.1.0.3 10.1.0.2 63 0x80000001 0x00007dad
10.1.0.3 10.1.0.3 63 0x80000001 0x00006dbd
10.1.1.0 10.1.0.2 63 0x80000001 0x00007257
10.1.1.0 10.1.0.3 63 0x80000001 0x00006c5c
10.1.2.2 10.1.0.2 63 0x80000001 0x00006bbf
10.1.2.2 10.1.0.3 63 0x80000001 0x000065c4

Task 4.2-1: Assign Access-1 to OSPF area 1 159

 10.1.11.0 10.1.0.2 63 0x80000001 0x000004bb
10.1.11.0 10.1.0.3 63 0x80000001 0x0000fdc0
10.1.12.0 10.1.0.2 63 0x80000001 0x0000f8c5
10.1.12.0 10.1.0.3 63 0x80000001 0x0000f2ca
n Question: How many links are there in the router LSA for Core-1 inside area 1 (10.1.0.2)?
n Answer: The router LSA inside area 1 only contains the VLAN 101 interface; therefore,
only one link will be present in the router LSA at this point.
The ABR is now responsible for converting the routes that were learned through the router (type
1) and network (type 2) LSAs between the areas. This means that the VLAN 2, 11, and 12 IP pre-
fixes that are known via the router LSA in area 0 have been converted into a summary LSA (type
3) in area 1.
6. In the same output, verify that the IP prefixes of area 0 are known as inter-area summary (type
3) LSAs in area 1.

Summary does not indicate route summarization. It only indicates that this LSA is not
used for the topology calculation of this area. Only router and network LSAs are used
to build the topology of an area.

ICX-Core-1(config-ospf-1)# show ip ospf lsdb area 1

OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Router Link State Advertisements (area 0.0.0.1)

------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 18 0x80000002 0x0000744d 1
10.1.0.3 10.1.0.3 19 0x80000002 0x0000724c 1

Network Link State Advertisements (area 0.0.0.1)

-------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.101.3 10.1.0.3 24 0x80000001 0x00000c85

Inter-area Summary Link State Advertisements (area 0.0.0.1)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.0.2 10.1.0.2 63 0x80000001 0x00007daf
10.1.0.2 10.1.0.3 63 0x80000001 0x000081a9

160 Task 4.2-1: Assign Access-1 to OSPF area 1

 Lab 4.2: OSPF and multiple areas
10.1.0.3 10.1.0.2 63 0x80000001 0x00007dad
10.1.0.3 10.1.0.3 63 0x80000001 0x00006dbd
10.1.1.0 10.1.0.2 63 0x80000001 0x00007257
10.1.1.0 10.1.0.3 63 0x80000001 0x00006c5c
10.1.2.2 10.1.0.2 63 0x80000001 0x00006bbf
10.1.2.2 10.1.0.3 63 0x80000001 0x000065c4
10.1.11.0 10.1.0.2 63 0x80000001 0x000004bb
10.1.11.0 10.1.0.3 63 0x80000001 0x0000fdc0
10.1.12.0 10.1.0.2 63 0x80000001 0x0000f8c5
10.1.12.0 10.1.0.3 63 0x80000001 0x0000f2ca

7. Review the LSDB for area 0.

ICX-Core-1(config)# show ip ospf lsdb area 0
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Router Link State Advertisements (area 0.0.0.0)

------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 421 0x80000014 0x0000369c 6
10.1.0.3 10.1.0.3 422 0x80000010 0x0000785b 6
10.1.0.4 10.1.0.4 1069 0x80000003 0x0000eca3 2

Network Link State Advertisements (area 0.0.0.0)

-------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.101.4 10.1.0.4 1069 0x80000002 0x0000a1ce

Inter-area Summary Link State Advertisements (area 0.0.0.0)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.101.0 10.1.0.2 416 0x80000002 0x00002044
10.1.101.0 10.1.0.3 417 0x80000002 0x00001a49

You may still notice the Access-1 (10.1.0.4) router LSA in the area 0 LSDB, even
though the link to Access-1 was already assigned to area 1. This is because that
router LSA still needs to age out from the LSDB, so it will disappear automatically
after 3600 seconds.

Task 4.2-1: Assign Access-1 to OSPF area 1 161

 n Question: The interface VLAN 101 IP subnet is now active in area 1. Is it known as a "sum-
mary" LSA in area 0?
n Answer: Yes, the 10.1.101.0 is listed as a summary LSA. Area border routers can be easily
found in the LSDB since they are advertising the summary LSAs. ADV Router indicates the
advertising router ID.
n Question: Which routers are currently ABR?
n Answer: Both 10.1.0.2 and 10.1.0.3 are currently advertising a summary LSA.
n Question: The configuration was only performed on Core-1. How is it possible that Core-2
(10.1.0.3) is also advertising the 10.1.101.0 summary LSA?
n Answer: Due to the VSX configuration synchronization, area 1 was also defined on Core-2,
and the interface VLAN 101 was also moved into area 1. Therefore, without manually con-
figuring anything on Core-2, it obtained its configuration from Core-1 and then became an
ABR as well.
Access-1
On Access-1, remove area 0, define area 1, and assign interface VLAN 101 to area 1.
8. On Access-1, enter configuration mode.
9. Remove area 0 and define area 1.
ICX-Access-1(config)# router ospf 1
ICX-Access-1(config-ospf-1)# no area 0
ICX-Access-1(config-ospf-1)# area 1
ICX-Access-1(config-ospf-1)# exit

10. Assign interface VLAN 101 to area 1.

ICX-Access-1(config)# interface vlan 101
ICX-Access-1(config-if-vlan)# ip ospf 1 area 1
ICX-Access-1(config-if-vlan)# exit

On Access-1, you will now define some local IP subnets. These subnets simulate client subnets
and will be used to test routing. The Access-1 router will be the only host in these test subnets.
The test subnets for area 1 are assigned in the 10.1.128–191 block, so it will be possible to sum-
marize these in a later task in the lab.
11. Define the test VLANs. Enable them as a VLAN trunk on the port to the client PC. This is only
done to ensure the VLAN is up.

If a VLAN does not contain any port in the up state, the Layer 3 IP interface remains
down as well, and thus OSPF will not advertise its network. As a workaround to bring
these VLANs up, these two VLANs are defined on the port to the PC, which is oper-
ationally up.

162 Task 4.2-1: Assign Access-1 to OSPF area 1

 Lab 4.2: OSPF and multiple areas
ICX-Access-1(config)# vlan 128,129
ICX-Access-1(config-vlan-<128,129>)# exit

ICX-Access-1(config)# interface 1/1/3

ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# vlan trunk allowed 128,129
ICX-Access-1(config-if)# exit

12. Define the test subnets.

ICX-Access-1(config)# interface vlan 128
ICX-Access-1(config-if-vlan)# ip address 10.1.128.1/24
ICX-Access-1(config-if-vlan)# ip ospf 1 area 1
ICX-Access-1(config-if-vlan)# exit

ICX-Access-1(config)# interface vlan 129

ICX-Access-1(config-if-vlan)# ip address 10.1.129.1/24
ICX-Access-1(config-if-vlan)# ip ospf 1 area 1
ICX-Access-1(config-if-vlan)# exit

13. On Access-1, restart OSPF. This ensures that anything related to OSPF on Core-1 and Core-2 will
be updated correctly.
ICX-Access-1(config)# router ospf 1
ICX-Access-1(config-ospf-1)# disable
ICX-Access-1(config-ospf-1)# enable
ICX-Access-1(config-ospf-1)# exit

14. On Access-1, review the LSDB for area 1, noting the link count for the Router LSA of Access-1.
ICX-Access-1(config)# show ip ospf lsdb area 1
OSPF Router with ID (10.1.0.4) (Process ID 1 VRF default)
===========================================================

Router Link State Advertisements (area 0.0.0.1)

------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 757 0x80000002 0x0000744d 1
10.1.0.3 10.1.0.3 132 0x80000003 0x0000704d 1
10.1.0.4 10.1.0.4 11 0x80000005 0x00004b57 3

Network Link State Advertisements (area 0.0.0.1)

-------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.101.4 10.1.0.4 132 0x80000002 0x0000adc4

Task 4.2-1: Assign Access-1 to OSPF area 1 163

 Inter-area Summary Link State Advertisements (area 0.0.0.1)
------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.0.2 10.1.0.2 802 0x80000001 0x00007daf
10.1.0.2 10.1.0.3 802 0x80000001 0x000081a9
10.1.0.3 10.1.0.2 802 0x80000001 0x00007dad
10.1.0.3 10.1.0.3 802 0x80000001 0x00006dbd
10.1.1.0 10.1.0.2 802 0x80000001 0x00007257
10.1.1.0 10.1.0.3 802 0x80000001 0x00006c5c
10.1.2.2 10.1.0.2 802 0x80000001 0x00006bbf
10.1.2.2 10.1.0.3 802 0x80000001 0x000065c4
10.1.11.0 10.1.0.2 802 0x80000001 0x000004bb
10.1.11.0 10.1.0.3 802 0x80000001 0x0000fdc0
10.1.12.0 10.1.0.2 802 0x80000001 0x0000f8c5
10.1.12.0 10.1.0.3 802 0x80000001 0x0000f2ca

Core-1
15. On Core-1, verify that the same information is known in the area 1 LSDB. Core-1 should also
know about the three links of the Access-1 router in the area 1 database.

Remember that an OSPF area LSDB contains the same information on all routers of
that area.

ICX-Core-1(config)# show ip ospf lsdb area 1

OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Router Link State Advertisements (area 0.0.0.1)

------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 808 0x80000002 0x0000744d 1
10.1.0.3 10.1.0.3 184 0x80000003 0x0000704d 1
10.1.0.4 10.1.0.4 24 0x80000007 0x00004759 3

Network Link State Advertisements (area 0.0.0.1)

-------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.101.4 10.1.0.4 184 0x80000002 0x0000adc4

Inter-area Summary Link State Advertisements (area 0.0.0.1)

164 Task 4.2-1: Assign Access-1 to OSPF area 1

 Lab 4.2: OSPF and multiple areas
------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
<output omitted>

16. The Core-1 area border has converted the routes of this Router LSA from area 1 to summary
routes into area 0. Verify this by reviewing the area 0 database.
ICX-Core-1(config)# show ip ospf lsdb area 0
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Router Link State Advertisements (area 0.0.0.0)

------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 596 0x80000005 0x00000332 6
10.1.0.3 10.1.0.3 151 0x8000000d 0x00006bbd 6

Inter-area Summary Link State Advertisements (area 0.0.0.0)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.101.0 10.1.0.2 641 0x80000002 0x00002044
10.1.101.0 10.1.0.3 150 0x80000003 0x0000184a
10.1.128.0 10.1.0.2 339 0x80000001 0x0000e302
10.1.128.0 10.1.0.3 340 0x80000001 0x0000dd07
10.1.129.0 10.1.0.2 329 0x80000001 0x0000d80c
10.1.129.0 10.1.0.3 329 0x80000001 0x0000d211

The Core-2 ABR has performed the same action, which is why the 10.1.128.0 and
10.1.129.0 summary LSAs are listed two times.

17. On Core-1, review learned OSPF routes and notice the OSPF route code.
ICX-Core-1(config)# show ip ospf routes
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table

---------------------------------------------

Total Number of Routes : 8

10.1.0.3/32 (i) area: 0.0.0.0

via 10.1.2.3 interface vlan2, cost 1 distance 110

Task 4.2-1: Assign Access-1 to OSPF area 1 165

 10.1.1.0/24 (i) area: 0.0.0.0
directly attached to interface vlan1, cost 100 distance 110
10.1.2.2/31 (i) area: 0.0.0.0
directly attached to interface vlan2, cost 1 distance 110
10.1.11.0/24 (i) area: 0.0.0.0
directly attached to interface vlan11, cost 100 distance 110
10.1.12.0/24 (i) area: 0.0.0.0
directly attached to interface vlan12, cost 100 distance 110
10.1.101.0/24 (i) area: 0.0.0.1
directly attached to interface vlan101, cost 100 distance 110
10.1.128.0/24 (i) area: 0.0.0.1
via 10.1.101.4 interface vlan101, cost 200 distance 110
10.1.129.0/24 (i) area: 0.0.0.1
via 10.1.101.4 interface vlan101, cost 200 distance 110
n Question: Why are all OSPF routes on Core-1 listed as intra-area routes (i)?
n Answer: In the current state of the lab, Core-1 has direct access to both area 0 and area 1,
so from the Core-1 perspective, all learned routes are intra-area routes.
18. On Core-1, review the IP routing table. The 10.1.128.0/24 and 10.1.129.0/24 subnets should be
visible.
ICX-Core-1(config)# show ip route ospf

Displaying ipv4 routes selected for forwarding

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

VRF: default

Prefix Nexthop Interface VRF(egress) Origin/ Distance/ Age

Type Metric
---------------------------------------------------------------------------------------
10.1.0.3/32 10.1.2.3 vlan2 - O [110/1] 00h:04m:35s
10.1.128.0/24 10.1.101.4 vlan101 - O [110/200] 00h:04m:35s
10.1.129.0/24 10.1.101.4 vlan101 - O [110/200] 00h:04m:35s

This concludes the introduction of OSPF area 1 in the lab. Proceed to the next task.

166 Task 4.2-1: Assign Access-1 to OSPF area 1

 Lab 4.2: OSPF and multiple areas
Task 4.2-2: Assign Access-2 to OSPF Area 2
Lab diagram

Objectives
n Configure Access-2 in its own area: Area 2.
n Review LSA propagation once Area 2 has been defined.
n Configure the ABR link.
n Verify how the LSA changes when traversing through Area 2, to Area 0, then to Area 1.

Steps
Core-1
1. On Core-1, define Area 2, assigning interface VLAN 102 to Area 2.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# area 2
ICX-Core-1(config-ospf-1)# exit

ICX-Core-1(config)# interface vlan 102

ICX-Core-1(config-if-vlan)# ip ospf 1 area 2
ICX-Core-1(config-if-vlan)# no ip ospf passive
ICX-Core-1(config-if-vlan)# exit

Access-2
2. Open a terminal connection to Access-2 and enter configuration mode.
3. On Access-2, enable OSPF with the Access-2 router ID and define Area 2.
ICX-Access-2(config)# router ospf 1
ICX-Access-2(config-ospf-1)# router-id 10.1.0.5

Task 4.2-2: Assign Access-2 to OSPF Area 2 167

 ICX-Access-2(config-ospf-1)# area 2
ICX-Access-2(config-ospf-1)# exit

4. On Access-2, define VLAN 102 and verify the switch can reach both core switches.

In the VSX lab activity, LAG 255 was set to allow all VLANs. This is why there is no
step to allow VLAN 102 on the VLAN trunk.

ICX-Access-2(config)# vlan 102

ICX-Access-2(config-vlan-102)# exit

5. Enable the IP address and verify connectivity to Core-1 and Core-2.

ICX-Access-2(config)# interface vlan 102
ICX-Access-2(config-vlan)# ip address 10.1.102.5/24
ICX-Access-2(config-vlan)# ip ospf 1 area 2
ICX-Access-2(config-vlan)# exit

ICX-Access-2(config)# ping 10.1.102.2

PING 10.1.102.2 (10.1.102.2) 100(128) bytes of data.
108 bytes from 10.1.102.2: icmp_seq=1 ttl=64 time=16.7 ms
108 bytes from 10.1.102.2: icmp_seq=2 ttl=64 time=0.173 ms
<output omitted>

ICX-Access-2(config)# ping 10.1.102.3

PING 10.1.102.3 (10.1.102.3) 100(128) bytes of data.
108 bytes from 10.1.102.3: icmp_seq=1 ttl=64 time=0.182 ms
108 bytes from 10.1.102.3: icmp_seq=2 ttl=64 time=0.175 ms
<output omitted>

6. Configure the loopback interface.

ICX-Access-2(config)# interface loopback 0
ICX-Access-2(config-loopback-if)# ip address 10.1.0.5/32
ICX-Access-2(config-loopback-if)# ip ospf 1 area 2
ICX-Access-2(config-loopback-if)# exit

7. Configure some local test subnets.

ICX-Access-2(config)# vlan 192,193
ICX-Access-2(config-vlan-<192,193>)# exit

ICX-Access-2(config)# interface 1/1/4

ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# vlan trunk allowed 192,193
ICX-Access-2(config-if)# exit

ICX-Access-2(config)# interface vlan 192

168 Task 4.2-2: Assign Access-2 to OSPF Area 2

 Lab 4.2: OSPF and multiple areas
ICX-Access-2(config-if-vlan)# ip address 10.1.192.1/24
ICX-Access-2(config-if-vlan)# ip ospf 1 area 2
ICX-Access-2(config-if-vlan)# exit

ICX-Access-2(config)# interface vlan 193

ICX-Access-2(config-if-vlan)# ip address 10.1.193.1/24
ICX-Access-2(config-if-vlan)# ip ospf 1 area 2
ICX-Access-2(config-if-vlan)# exit

8. On Access-2, restart OSPF. This ensures that anything related to OSPF on Core-1 and Core-2 will
be updated correctly.
ICX-Access-2(config)# router ospf 1
ICX-Access-2(config-ospf-1)# disable
ICX-Access-2(config-ospf-1)# enable
ICX-Access-2(config-ospf-1)# exit

9. Verify the OSPF adjacencies have been established with Core-1 and Core-2.
ICX-Access-2(config)# show ip ospf neighbors
OSPF Process ID 1 VRF default
==============================

Total Number of Neighbors: 2

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.2 1 FULL/BDR 10.1.102.2 vlan102

10.1.0.3 1 FULL/DR 10.1.102.3 vlan102

Verify route propagation and LSA changes from Area 2 to Area 0 to Area 1
In the next steps, the route propagation between the areas will be reviewed. For this example,
route 10.1.192.0/24 will be used. This is the test subnet that was defined on Access-2 in Area 2.
In previous steps, the show ip ospf lsdb command was used to review the LSAs in the LSDB. In
the next steps, the show ip ospf routes command will be used. This command shows the actual
routes that have been calculated by OSPF for both intra-area (router and network LSA) and
inter-area LSAs (summary LSA).
Access-2
10. On Access-2, verify the 10.1.192.0/24 route is known as an intra-area route.

The lowercase "i" is used for intra-area, while the uppercase "I" is used for inter-area.

ICX-Access-2(config)# show ip ospf routes

Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

Task 4.2-2: Assign Access-2 to OSPF Area 2 169

 OSPF Process ID 1 VRF default, Routing Table
---------------------------------------------

Total Number of Routes : 19

10.1.0.2/32 (I)
via 10.1.102.2 interface vlan102, cost 100 distance 110
10.1.0.3/32 (I)
via 10.1.102.3 interface vlan102, cost 100 distance 110
10.1.1.0/24 (I)
via 10.1.102.2 interface vlan102, cost 200 distance 110
10.1.1.0/24 (I)
via 10.1.102.3 interface vlan102, cost 200 distance 110
10.1.2.2/31 (I)
via 10.1.102.2 interface vlan102, cost 101 distance 110
10.1.2.2/31 (I)
via 10.1.102.3 interface vlan102, cost 101 distance 110
10.1.11.0/24 (I)
via 10.1.102.2 interface vlan102, cost 200 distance 110
10.1.11.0/24 (I)
via 10.1.102.3 interface vlan102, cost 200 distance 110
10.1.12.0/24 (I)
via 10.1.102.2 interface vlan102, cost 200 distance 110
10.1.12.0/24 (I)
via 10.1.102.3 interface vlan102, cost 200 distance 110
10.1.101.0/24 (I)
via 10.1.102.2 interface vlan102, cost 200 distance 110
10.1.101.0/24 (I)
via 10.1.102.3 interface vlan102, cost 200 distance 110
10.1.102.0/24 (i) area: 0.0.0.2
directly attached to interface vlan102, cost 100 distance 110
10.1.128.0/24 (I)
via 10.1.102.2 interface vlan102, cost 300 distance 110
10.1.128.0/24 (I)
via 10.1.102.3 interface vlan102, cost 300 distance 110
10.1.129.0/24 (I)
via 10.1.102.2 interface vlan102, cost 300 distance 110
10.1.129.0/24 (I)
via 10.1.102.3 interface vlan102, cost 300 distance 110
10.1.192.0/24 (i) area: 0.0.0.2
directly attached to interface vlan192, cost 100 distance 110
10.1.193.0/24 (i) area: 0.0.0.2
directly attached to interface vlan193, cost 100 distance 110

Core-1
11. On Core-1, review the OSPF routing table and look for the 10.1.192.0/24 subnet.
ICX-Core-1(config)# show ip ospf routes
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

170 Task 4.2-2: Assign Access-2 to OSPF Area 2

 Lab 4.2: OSPF and multiple areas
OSPF Process ID 1 VRF default, Routing Table
---------------------------------------------

Total Number of Routes : 12

10.1.0.3/32 (i) area: 0.0.0.0

via 10.1.2.3 interface vlan2, cost 1 distance 110
10.1.0.5/32 (i) area: 0.0.0.2
via 10.1.102.5 interface vlan102, cost 100 distance 110
10.1.1.0/24 (i) area: 0.0.0.0
directly attached to interface vlan1, cost 100 distance 110
10.1.2.2/31 (i) area: 0.0.0.0
directly attached to interface vlan2, cost 1 distance 110
10.1.11.0/24 (i) area: 0.0.0.0
directly attached to interface vlan11, cost 100 distance 110
10.1.12.0/24 (i) area: 0.0.0.0
directly attached to interface vlan12, cost 100 distance 110
10.1.101.0/24 (i) area: 0.0.0.1
directly attached to interface vlan101, cost 100 distance 110
10.1.102.0/24 (i) area: 0.0.0.2
directly attached to interface vlan102, cost 100 distance 110
10.1.128.0/24 (i) area: 0.0.0.1
via 10.1.101.4 interface vlan101, cost 200 distance 110
10.1.129.0/24 (i) area: 0.0.0.1
via 10.1.101.4 interface vlan101, cost 200 distance 110
10.1.192.0/24 (i) area: 0.0.0.2
via 10.1.102.5 interface vlan102, cost 200 distance 110
10.1.193.0/24 (i) area: 0.0.0.2
via 10.1.102.5 interface vlan102, cost 200 distance 110
n Question: Why is the route listed as an intra-area route?
n Answer: Core-1 has both Area 2 and Area 0 databases locally. Both Area 2 and Area 0 are
offering this route to the OSPF routing table. But an intra-area route takes precedence
over an inter-area route, so the intra-area route is listed here.
12. Also review the summary LSAs in the Area 0 LSDB.
ICX-Core-1(config)# show ip ospf lsdb summary area 0
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Inter-area Summary Link State Advertisements (area 0.0.0.0)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.0.5 10.1.0.2 454 0x80000001 0x00004b7a
10.1.0.5 10.1.0.3 455 0x80000001 0x0000457f
10.1.101.0 10.1.0.2 404 0x80000003 0x00001e45
10.1.101.0 10.1.0.3 405 0x80000003 0x0000184a
10.1.102.0 10.1.0.2 743 0x80000002 0x0000154e

Task 4.2-2: Assign Access-2 to OSPF Area 2 171

 10.1.102.0 10.1.0.3 740 0x80000002 0x00000f53
10.1.128.0 10.1.0.2 1437 0x80000001 0x0000e302
10.1.128.0 10.1.0.3 1439 0x80000001 0x0000dd07
10.1.129.0 10.1.0.2 1418 0x80000001 0x0000d80c
10.1.129.0 10.1.0.3 1419 0x80000001 0x0000d211
10.1.192.0 10.1.0.2 414 0x80000001 0x00002184
10.1.192.0 10.1.0.3 415 0x80000001 0x00001b89
10.1.193.0 10.1.0.2 398 0x80000001 0x0000168e
10.1.193.0 10.1.0.3 399 0x80000001 0x00001093
n Question: Which routers are advertising the summary LSA for the 10.1.192.0/24 subnet?
n Answer: As ABRs, both Core-1 and Core-2 are advertising this summary LSA.
13. On Core-1, review the Area 1 LSDB, looking for the 10.1.192.0 summary LSA. An ABR will con-
vert router and network LSAs from non-backbone areas (not Area 0.0.0.0) into summary LSAs in
the backbone area. These summary LSAs will be copied as summary LSAs into any other areas
that exist on the ABR.
ICX-Core-1(config)# show ip ospf lsdb summary area 1
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Inter-area Summary Link State Advertisements (area 0.0.0.1)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.0.2 10.1.0.2 459 0x80000002 0x00007bb0
10.1.0.2 10.1.0.3 460 0x80000002 0x00007faa
10.1.0.3 10.1.0.2 459 0x80000002 0x00007bae
10.1.0.3 10.1.0.3 460 0x80000002 0x00006bbe
10.1.0.5 10.1.0.2 504 0x80000001 0x00004b7a
10.1.0.5 10.1.0.3 505 0x80000001 0x0000457f
10.1.1.0 10.1.0.2 459 0x80000002 0x00007058
10.1.1.0 10.1.0.3 460 0x80000002 0x00006a5d
10.1.2.2 10.1.0.2 459 0x80000002 0x000069c0
10.1.2.2 10.1.0.3 460 0x80000002 0x000063c5
10.1.11.0 10.1.0.2 459 0x80000002 0x000002bc
10.1.11.0 10.1.0.3 460 0x80000002 0x0000fbc1
10.1.12.0 10.1.0.2 459 0x80000002 0x0000f6c6
10.1.12.0 10.1.0.3 460 0x80000002 0x0000f0cb
10.1.102.0 10.1.0.2 793 0x80000002 0x0000154e
10.1.102.0 10.1.0.3 789 0x80000003 0x00000d54
10.1.192.0 10.1.0.2 464 0x80000001 0x00002184
10.1.192.0 10.1.0.3 465 0x80000001 0x00001b89
10.1.193.0 10.1.0.2 448 0x80000001 0x0000168e
10.1.193.0 10.1.0.3 449 0x80000001 0x00001093
n Question: Which routers are advertising the summary LSA?
n Answer: Again, as ABRs, both Core-1 and Core-2 are advertising this summary LSA.

172 Task 4.2-2: Assign Access-2 to OSPF Area 2

 Lab 4.2: OSPF and multiple areas
Access-1
14. On Access-1, review the OSPF LSDB and the routing table.
ICX-Access-1(config)# show ip ospf lsdb summary area 1
OSPF Router with ID (10.1.0.4) (Process ID 1 VRF default)
===========================================================

Inter-area Summary Link State Advertisements (area 0.0.0.1)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.0.2 10.1.0.2 536 0x80000002 0x00007bb0
10.1.0.2 10.1.0.3 535 0x80000002 0x00007faa
10.1.0.3 10.1.0.2 536 0x80000002 0x00007bae
10.1.0.3 10.1.0.3 535 0x80000002 0x00006bbe
10.1.0.5 10.1.0.2 580 0x80000001 0x00004b7a
10.1.0.5 10.1.0.3 580 0x80000001 0x0000457f
10.1.1.0 10.1.0.2 536 0x80000002 0x00007058
10.1.1.0 10.1.0.3 535 0x80000002 0x00006a5d
10.1.2.2 10.1.0.2 536 0x80000002 0x000069c0
10.1.2.2 10.1.0.3 535 0x80000002 0x000063c5
10.1.11.0 10.1.0.2 536 0x80000002 0x000002bc
10.1.11.0 10.1.0.3 535 0x80000002 0x0000fbc1
10.1.12.0 10.1.0.2 536 0x80000002 0x0000f6c6
10.1.12.0 10.1.0.3 535 0x80000002 0x0000f0cb
10.1.102.0 10.1.0.2 870 0x80000002 0x0000154e
10.1.102.0 10.1.0.3 864 0x80000003 0x00000d54
10.1.192.0 10.1.0.2 540 0x80000001 0x00002184
10.1.192.0 10.1.0.3 540 0x80000001 0x00001b89
10.1.193.0 10.1.0.2 524 0x80000001 0x0000168e
10.1.193.0 10.1.0.3 524 0x80000001 0x00001093

15. Review the OSPF routes. The route to 10.1.192.0/24 should be listed as an inter-area route.
ICX-Access-1(config)# show ip ospf routes 10.1.192.0/24
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table for prefixes 10.1.192.0/24

-------------------------------------------------------------------------

Total Number of Routes : 2

10.1.192.0/24 (I)
via 10.1.101.2 interface vlan101, cost 300 distance 110
10.1.192.0/24 (I)
via 10.1.101.3 interface vlan101, cost 300 distance 110

Task 4.2-2: Assign Access-2 to OSPF Area 2 173

 This demonstrates that a route on a router LSA in Area 2 is converted into a summary LSA by
the ABR into the backbone area (0.0.0.0). An ABR will copy any summary LSA from the backbone
area into any other area LSDB.

An ABR will only exchange information between an area and the backbone (0.0.0.0)
area LSDB databases. It will never exchange information directly between two non-
backbone areas—for example, between Area 1 and Area 2 LSDBs directly.

Task 4.2-3: Route summarization

Lab diagram

Objectives
n Implement route summarization between the areas.

Steps
To complete this task, you will:
n Summarize routes injected by Area 1 into Area 0 on Core-1.
n Verify the summarization in Area 2; verify the LSA type and cost.
n Summarize Area 2 test subnets.
Summarize the Area 1 test subnets
In Area 1, the test subnets 10.1.128.0/24 and 10.1.129.0/24 can be summarized into a 10.1.128.0/18
prefix on an Area 1 ABR.

174 Task 4.2-3: Route summarization

 Lab 4.2: OSPF and multiple areas
Core-1
1. On Core-1, configure the summarization rule in the OSPF Area 1 context.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# area 1 range 10.1.128.0/18 type inter-area
ICX-Core-1(config-ospf-1)# exit

2. Verify that this was synchronized to Core-2.

IMPORTANT: The route aggregation must be performed on every ABR that is con-
nected to this area to be effective. An ABR that does not have the aggregation route
will still be announcing the more specific routes into the area.
As a result, all traffic to these subnets will go via the most specific match, meaning
the ABR that does not have the aggregate route configured.
In this lab environment, the VSX configuration synchronization is also synchronizing
the OSPF commands, where the area range command is automatically set on the
Core-2 ABR.

ICX-Core-1(config)# show run ospf vsx-peer

router ospf 1
router-id 10.1.0.3
passive-interface default
area 0.0.0.0
area 0.0.0.1
area 0.0.0.1 range 10.1.128.0/18 type inter-area
area 0.0.0.2
interface loopback 0
ip ospf 1 area 0.0.0.0
interface vlan1
ip ospf 1 area 0.0.0.0
interface vlan2
ip ospf 1 area 0.0.0.0
no ip ospf passive
ip ospf cost 1
ip ospf network point-to-point
interface vlan11
ip ospf 1 area 0.0.0.0
interface vlan12
ip ospf 1 area 0.0.0.0
interface vlan101
ip ospf 1 area 0.0.0.1
no ip ospf passive
interface vlan102
ip ospf 1 area 0.0.0.2
no ip ospf passive

Task 4.2-3: Route summarization 175

 3. Review how this affects the Area 0 LSDB on Core-1. Previously, these subnets were known as
unique summary LSAs; now, only the summarized route is listed.
ICX-Core-1(config)# show ip ospf lsdb summary area 0
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Inter-area Summary Link State Advertisements (area 0.0.0.0)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.0.5 10.1.0.2 962 0x80000001 0x00004b7a
10.1.0.5 10.1.0.3 963 0x80000001 0x0000457f
10.1.101.0 10.1.0.2 912 0x80000003 0x00001e45
10.1.101.0 10.1.0.3 913 0x80000003 0x0000184a
10.1.102.0 10.1.0.2 1251 0x80000002 0x0000154e
10.1.102.0 10.1.0.3 1248 0x80000002 0x00000f53
10.1.128.0 10.1.0.2 162 0x80000002 0x0000a57e
10.1.128.0 10.1.0.3 161 0x80000002 0x00009f83
10.1.192.0 10.1.0.2 922 0x80000001 0x00002184
10.1.192.0 10.1.0.3 923 0x80000001 0x00001b89
10.1.193.0 10.1.0.2 906 0x80000001 0x0000168e
10.1.193.0 10.1.0.3 907 0x80000001 0x00001093

4. And since Area 0 only contains the summarized entry, the Area 2 LSDB will also reflect this.
Review summary LSAs in the LSDB for Area 2.
ICX-Core-1(config)# show ip ospf lsdb summary area 2
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

Inter-area Summary Link State Advertisements (area 0.0.0.2)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.0.2 10.1.0.2 1322 0x80000001 0x00007daf
10.1.0.2 10.1.0.3 1319 0x80000001 0x000081a9
10.1.0.3 10.1.0.2 1322 0x80000001 0x00007dad
10.1.0.3 10.1.0.3 1319 0x80000001 0x00006dbd
10.1.1.0 10.1.0.2 1322 0x80000001 0x00007257
10.1.1.0 10.1.0.3 1319 0x80000001 0x00006c5c
10.1.2.2 10.1.0.2 1322 0x80000001 0x00006bbf
10.1.2.2 10.1.0.3 1319 0x80000001 0x000065c4
10.1.11.0 10.1.0.2 1322 0x80000001 0x000004bb
10.1.11.0 10.1.0.3 1319 0x80000001 0x0000fdc0
10.1.12.0 10.1.0.2 1322 0x80000001 0x0000f8c5
10.1.12.0 10.1.0.3 1319 0x80000001 0x0000f2ca
10.1.101.0 10.1.0.2 1322 0x80000001 0x00002243

176 Task 4.2-3: Route summarization

 Lab 4.2: OSPF and multiple areas
10.1.101.0 10.1.0.3 1319 0x80000001 0x00001c48
10.1.128.0 10.1.0.2 233 0x80000002 0x0000a57e
10.1.128.0 10.1.0.3 229 0x80000003 0x00009d84

Access-2
5. Access-2 is an OSPF router that only belongs to Area 2. Review the LSDB. Since all the databases
for an area must be the same on all the routers of an area, this Area 2 LSDB will also contain the
summarized summary LSA.
ICX-Access-2(config)# show ip ospf lsdb summary area 2
OSPF Router with ID (10.1.0.5) (Process ID 1 VRF default)
===========================================================

Inter-area Summary Link State Advertisements (area 0.0.0.2)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.0.2 10.1.0.2 1368 0x80000001 0x00007daf
10.1.0.2 10.1.0.3 1365 0x80000001 0x000081a9
10.1.0.3 10.1.0.2 1368 0x80000001 0x00007dad
10.1.0.3 10.1.0.3 1365 0x80000001 0x00006dbd
10.1.1.0 10.1.0.2 1368 0x80000001 0x00007257
10.1.1.0 10.1.0.3 1365 0x80000001 0x00006c5c
10.1.2.2 10.1.0.2 1368 0x80000001 0x00006bbf
10.1.2.2 10.1.0.3 1365 0x80000001 0x000065c4
10.1.11.0 10.1.0.2 1368 0x80000001 0x000004bb
10.1.11.0 10.1.0.3 1365 0x80000001 0x0000fdc0
10.1.12.0 10.1.0.2 1368 0x80000001 0x0000f8c5
10.1.12.0 10.1.0.3 1365 0x80000001 0x0000f2ca
10.1.101.0 10.1.0.2 1368 0x80000001 0x00002243
10.1.101.0 10.1.0.3 1365 0x80000001 0x00001c48
10.1.128.0 10.1.0.2 281 0x80000002 0x0000a57e
10.1.128.0 10.1.0.3 275 0x80000003 0x00009d84

6. Verify the OSPF routing table. It should only contain the summarized entry 10.1.128.0/18, so
the 10.1.128.0/24 and 10.1.129.0/24 subnets should not appear anymore.
ICX-Access-2(config)# show ip ospf routes
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table

---------------------------------------------

Total Number of Routes : 17

10.1.0.2/32 (I)
via 10.1.102.2 interface vlan102, cost 100 distance 110

Task 4.2-3: Route summarization 177

 10.1.0.3/32 (I)
via 10.1.102.3 interface vlan102, cost 100 distance 110
10.1.1.0/24 (I)
via 10.1.102.2 interface vlan102, cost 200 distance 110
10.1.1.0/24 (I)
via 10.1.102.3 interface vlan102, cost 200 distance 110
10.1.2.2/31 (I)
via 10.1.102.2 interface vlan102, cost 101 distance 110
10.1.2.2/31 (I)
via 10.1.102.3 interface vlan102, cost 101 distance 110
10.1.11.0/24 (I)
via 10.1.102.2 interface vlan102, cost 200 distance 110
10.1.11.0/24 (I)
via 10.1.102.3 interface vlan102, cost 200 distance 110
10.1.12.0/24 (I)
via 10.1.102.2 interface vlan102, cost 200 distance 110
10.1.12.0/24 (I)
via 10.1.102.3 interface vlan102, cost 200 distance 110
10.1.101.0/24 (I)
via 10.1.102.2 interface vlan102, cost 200 distance 110
10.1.101.0/24 (I)
via 10.1.102.3 interface vlan102, cost 200 distance 110
10.1.102.0/24 (i) area: 0.0.0.2
directly attached to interface vlan102, cost 100 distance 110
10.1.128.0/18 (I)
via 10.1.102.2 interface vlan102, cost 300 distance 110
10.1.128.0/18 (I)
via 10.1.102.3 interface vlan102, cost 300 distance 110
10.1.192.0/24 (i) area: 0.0.0.2
directly attached to interface vlan192, cost 100 distance 110
10.1.193.0/24 (i) area: 0.0.0.2
directly attached to interface vlan193, cost 100 distance 110

Reject route for the summarized route

When an ABR is announcing a summary route to other routers, it introduces the risk that remote
systems may send traffic to a subnet that is simply not online or available. In this example, Core-
1 and Core-2 ABRs are announcing the 10.1.128.0/18 summarized route to Area 2. This means
that devices connected to Access-2 could try to send traffic to, for example, the 10.1.130.0/24
subnet, since this traffic also falls under the 10.1.128.0/18 route.
To prevent this, the ABR router that has the summarized route configured will automatically get
a reject route in its routing table for the summarized route. In this example, the 10.1.128.0/18
route is rejected. While this may seem like it would block all the traffic, the ABR still has the more
specific routes for 10.1.128.0/24 and 10.1.129.0/24 in its routing table, so these routes take pre-
cedence over the summarized route.

178 Task 4.2-3: Route summarization

 Lab 4.2: OSPF and multiple areas
Core-1
7. On Core-1, review the IP routing table. Verify that the summarized route is listed as a "reject"
route, while the more specific routes still exist as normal routes.
ICX-Core-1(config)# show ip route ospf

Displaying ipv4 routes selected for forwarding

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

VRF: default

Prefix Nexthop Interface VRF(egress)

Origin/ Distance/ Age
Type Metric
--------------------------------------------------------------------------------------
10.1.0.3/32 10.1.2.3 vlan2 - O [110/1] 00h:25m:15s
10.1.0.5/32 10.1.102.5 vlan102 - O [110/100] 00h:11m:50s
10.1.128.0/24 10.1.101.4 vlan101 - O [110/200] 00h:25m:15s
10.1.129.0/24 10.1.101.4 vlan101 - O [110/200] 00h:25m:15s
10.1.192.0/24 10.1.102.5 vlan102 - O [110/200] 00h:11m:50s
10.1.193.0/24 10.1.102.5 vlan102 - O [110/200] 00h:11m:50s

Total Route Count : 6

8. Therefore, if any traffic were to arrive for the non-existing 10.1.130.0/24 subnet, it would be
rejected since it only matches the reject route.
ICX-Core-1(config)# show ip route 10.1.130.0

VRF: default

Prefix : 10.1.128.0/18 VRF(egress) : -

Nexthop : - Interface : reject
Origin : static Type : -
Distance : 110 Metric : 0
Age : 00h:08m:02s Tag : 0
Encap Type : - Encap Details : -

While this reject route is listed as a static route, it will not be visible in the running
configuration. OSFP summarized route entries are automatically added to the oper-
ational routing table as a static route with the reject option.

Task 4.2-3: Route summarization 179

 Summarize Area 2 test subnets
Lab diagram

9. Now, attempt to summarize the Area 2 test subnets 10.1.192.0/24 and 10.1.193.0/24 into a
10.1.192.0/18 summary route. Try to apply the commands yourself. If you are not sure, the com-
mands can be found in the next steps.
Access-1
10. Verify on Access-1 (Area 1) that only the summary route is listed (and not the specific routes for
Area 2).
ICX-Access-1(config)# show ip route 10.1.192.0

VRF: default

Prefix : 10.1.192.0/18 VRF(egress) : -

Nexthop : 10.1.101.3 Interface : vlan101
Origin : ospf Type : ospf_inter_area
Distance : 110 Metric : 300
Age : 00h:01m:29s Tag : 0
Encap Type : - Encap Details : -

Prefix : 10.1.192.0/18 VRF(egress) : -

Nexthop : 10.1.101.2 Interface : vlan101
Origin : ospf Type : ospf_inter_area
Distance : 110 Metric : 300
Age : 00h:01m:29s Tag : 0
Encap Type : - Encap Details : -

Solution
11. On Core-1:

180 Task 4.2-3: Route summarization

 Lab 4.2: OSPF and multiple areas
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# area 2 range 10.1.192.0/18 type inter-area
ICX-Core-1(config-ospf-1)# exit

Task 4.2-4: Verify route propagation impact with summarization

Using route summarization reduces the routing table size, but it also minimizes the impact of routing
updates. In the case where a summarized route is added or removed, the change will only be seen up to
the point where the summarization takes place. In a large OSPF network, this has significant advan-
tages and ensures better network stability due to fewer routing updates.

Objectives
n Verify an OSPF LSA update propagates over the entire autonomous system (AS) by default.
n Verify LSA propagation can be controlled using summarization.

Steps
Default LSA propagation
In the lab setup, the loopback 0 interface of Access-2 will be disabled. Since this interface has IP
address 10.1.0.5/32, and this does not match the summarization rule, the LSA change will propagate
across the entire AS.
These are the high-level steps:
n Check the OSPF SPF count on Access-1.
n On Access-2, disable the loopback interface to simulate a route change.
n On Access-1, examine the SPF count again; it should have increased since the LSA is propagated
across the entire AS.
Access-1
1. On Access-1, review the OSPF SPF count and routing table.

In each lab, the number of calculations may be different; the following output is just
an example.

ICX-Access-1(config)# show ip ospf

VRF : default Process : 1
----------------------------------------------------

RouterID : 10.1.0.4 OSPFv2 : Enabled

BFD : Disabled SPF Start Interval : 200 ms
SPF Hold Interval : 1000 ms SPF Max Wait Interval : 5000 ms
LSA Start Time : 5000 ms LSA Hold Time : 0 ms
LSA Max Wait Time : 0 ms LSA Arrival : 1000 ms
External LSAs : 0 Checksum Sum : 0

Task 4.2-4: Verify route propagation impact with summarization 181

 ECMP : 4 Reference Bandwidth : 100000 Mbps
Area Border : false AS Border : false
GR Status : Enabled GR Interval : 120 sec
GR State : inactive GR Exit Status : none
GR Helper : Enabled GR Strict LSA Check : Enabled
GR Ignore Lost I/F : Disabled
Summary address:

Area Total Active

------------------------------
Normal 1 1
Stub 0 0
NSSA 0 0

area : 0.0.0.1
----------------
area Type : Normal Status : Active
Total Interfaces : 3 Active Interfaces : 3
Passive Interfaces : 0 Loopback Interfaces : 0
SPF Calculation Count : 39
area ranges :
Number of LSAs : 22 Checksum Sum : 737320

2. On Access-1, check the OSPF database summary.

ICX-Access-1(config)# show ip ospf lsdb database-summary
OSPF Router with ID (10.1.0.4) (Process ID 1 VRF default)
===========================================================

Area 0.0.0.1 database summary

------------------------------

LSA Type Count

---------------------------
Router 3
Network 1
Inter-area Summary 18
ASBR Summary 0
NSSA External 0
Subtotal 22

Process 1 database summary

---------------------------

LSA Type Count

---------------------------
Router 3
Network 1
Inter-area Summary 18
ASBR Summary 0
NSSA External 0
AS External 0

182 Task 4.2-4: Verify route propagation impact with summarization

 Lab 4.2: OSPF and multiple areas
Total 22

Access-2
3. On Access-2, disable the loopback 0 interface for OSPF.
ICX-Access-2(config)# interface loopback 0
ICX-Access-2(config-loopback-if)# ip ospf shutdown

Access-1
4. On Access-1, review the SPF count and the LSDB database summary.
ICX-Access-1(config)# show ip ospf | include SPF
RouterID : 10.1.0.4 OSPFv2 : Enabled
BFD : Disabled SPF Start Interval : 200 ms
SPF Hold Interval : 1000 ms SPF Max Wait Interval : 5000 ms
SPF Calculation Count : 41

ICX-Access-1(config)# show ip ospf lsdb database-summary

OSPF Router with ID (10.1.0.4) (Process ID 1 VRF default)
===========================================================

Area 0.0.0.1 database summary

------------------------------

LSA Type Count

---------------------------
Router 3
Network 1
Inter-area Summary 16
ASBR Summary 0
NSSA External 0
Subtotal 20

<output omitted>

Access-2
5. On Access-2, enable the loopback 0 interface for OSPF again.
ICX-Access-2(config-loopback-if)# no ip ospf shutdown
ICX-Access-2(config-loopback-if)# exit
ICX-Access-2(config)#

This demonstrates that LSA updates are propagated over the entire AS by default.
Verify that LSA propagation can be controlled using summarization
Now, an interface that was summarized will be disabled. This should have no impact on the LSDB
and the SPF count in the other areas. For this example, on Access-2, the interface VLAN 192 will
be disabled. Again, verify the SPF count on Access-1 first, then make the change on Access-2,
and verify the count again on Access-1.

Task 4.2-4: Verify route propagation impact with summarization 183

 Access-1
6. On Access-1, review the current SPF count.
ICX-Access-1(config)# show ip ospf | include SPF
RouterID : 10.1.0.4 OSPFv2 : Enabled
BFD : Disabled SPF Start Interval : 200 ms
SPF Hold Interval : 1000 ms SPF Max Wait Interval : 5000 ms
SPF Calculation Count : 42

Access-2
7. On Access-2, disable the VLAN 192 interface. This interface was summarized using the
10.1.192.0/18 range command.
ICX-Access-2(config)# interface vlan 192
ICX-Access-2(config-if-vlan)# shutdown

Access-1
8. On Access-1, verify the SPF count has not increased.
ICX-Access-1(config)# show ip ospf | include SPF
RouterID : 10.1.0.4 OSPFv2 : Enabled
BFD : Disabled SPF Start Interval : 200 ms
SPF Hold Interval : 1000 ms SPF Max Wait Interval : 5000 ms
SPF Calculation Count : 42

This demonstrates the advantage of route summarization between OSPF areas.

Access-2
9. On Access-2, enable the VLAN 192 interface again.
ICX-Access-2(config)# interface vlan 192
ICX-Access-2(config-if-vlan)# no shutdown
ICX-Access-2(config-if-vlan)# exit

Task 4.2-5: ABR route filtering

On the ABR, the network administrator can also filter routes. This feature is useful in case some routes
only need to be known within the local area, but they should not be advertised to the rest of the
autonomous system.
To demonstrate route filtering, a new IP interface will be enabled on Access-2 and will be assigned to
Area 2. This route will be visible to the Core-1 and Core-2 routers, since they also belong to Area 2.
Therefore, the route can be used by all the routers that belong to this area. However, the administrator
does not want this route to be visible in the other areas, so a route filter will be used.

184 Task 4.2-5: ABR route filtering

 Lab 4.2: OSPF and multiple areas
Lab diagram

Objectives
n Explain ABR route filtering.
n Configure ABR route filtering.

Steps
Here is a brief summary of what you will be doing in this task:
n Introduce a new subnet on Access-2 and assign it to Area 2.
n On the ABR, filter the route in the OSPF Area 2 LSDB.
n Verify the result on Access-1, a route in Area 1.
Access-2
1. On Access-2, introduce a new route by adding a secondary IP address on the VLAN 192 inter-
face.
ICX-Access-2(config)# interface vlan 192
ICX-Access-2(config-if-vlan)# ip address 10.1.99.1/24 secondary

Access-1
2. On Access-1, verify the route is visible in the routing table, since no filtering has been applied
yet.
ICX-Access-1(config)# show ip route 10.1.99.0

Task 4.2-5: ABR route filtering 185

 VRF: default

Prefix : 10.1.99.0/24 VRF(egress) : -

Nexthop : 10.1.101.3 Interface : vlan101
Origin : ospf Type : ospf_inter_area
Distance : 110 Metric : 300
Age : 00h:00m:13s Tag : 0
Encap Type : - Encap Details : -

Prefix : 10.1.99.0/24 VRF(egress) : -

Nexthop : 10.1.101.2 Interface : vlan101
Origin : ospf Type : ospf_inter_area
Distance : 110 Metric : 300
Age : 00h:00m:13s Tag : 0
Encap Type : - Encap Details : -

Core-1
3. On Core-1, review that the 10.1.99.0 summary LSA exists in the Area 0 database.
ICX-Core-1(config)# show ip ospf lsdb summary area 0 | include 99.0
10.1.99.0 10.1.0.2 10 0x80000001 0x0000382f
10.1.99.0 10.1.0.3 9 0x80000001 0x00003234

4. Apply the filter for Area 2 so the 10.1.99.0/24 subnet is not announced anymore.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# area 2 range 10.1.99.0/24 type inter-area no-advertise
ICX-Core-1(config-ospf-1)# exit

5. Verify that the 10.1.99.0/24 summary route is no longer listed in the Area 0 database.
ICX-Core-1(config)# show ip ospf lsdb summary area 0 | include 99.0
ICX-Core-1(config)#

6. As a result, it will also be removed from the Area 1 database.

ICX-Core-1(config)# show ip ospf lsdb summary area 1 | include 99.0
ICX-Core-1(config)#

Access-1
7. Verify the result on Access-1.
ICX-Access-1(config)# show ip route 10.1.99.0

No ipv4 routes configured

All four switches: Core-1, Core-2, Access-1, and Access-2

8. Save the configurations on all devices using the write memory command.
You have completed Lab 4.2!

186 Task 4.2-5: ABR route filtering

Lab 4.3: Managing OSPF external routes

Lab 4.3: Managing OSPF external routes

Lab diagram

Overview
This lab activity will demonstrate how OSPF can be used to distribute routes to external networks to
other OSPF routers in the OSPF AS. The router that is performing this redistribution is referred to as
the Autonomous System Boundary Router (ASBR). This will be demonstrated using Core-1 in the back-
bone and Access-2 in Area 2.
Once the external routes have been exchanged, the lab will show how a route map can be used to con-
trol the cost and the list of routes that can be redistributed.
The last section of the lab will show how area types can be used to optimize which external and OSPF
routes will be announced into an area.

Objectives
n Learn how to configure an ASBR to redistribute routes.
n Configure a route map to control external cost types, such as metric type 1 and type 2.

Lab 4.3: Managing OSPF external routes 187

 n Understand the difference between stub, stub no-summary, and not-so-stubby area (NSSA)
types.

Task 4.3-1: Configure the link to Router-A

Objectives
In this task, the routed connection between Core-1 and Router-A will be verified. On Core-1, a static
route will be configured to this Router-A, so Core-1 (and only Core-1) can reach the external network
at this point.

Steps
Verify the routed connection from Core-1 (interface 1/1/7) to Router-A.
Core-1
1. On Core-1, enter configuration mode.
2. Review the configuration of interface 1/1/7. This was configured during the VSX lab activity.

The IP scheme for the upstream routers is local for each table, so there is no "x" mark-
ing in these IP addresses.

ICX-Core-1(config)# interface 1/1/7

ICX-Core-1(config-if)# show running-config current-context
interface 1/1/7
no shutdown
ip address 10.255.101.2/24
exit
ICX-Core-1(config-if)# exit

3. Verify connectivity to the Router-A IP.

ICX-Core-1(config)# ping 10.255.101.11
PING 10.255.101.11 (10.255.101.11) 100(128) bytes of data.
108 bytes from 10.255.101.11: icmp_seq=1 ttl=64 time=1.75 ms
<output omitted>

4. Define a static route to the remote subnet (loopback on Router-A). This represents a business
partner network outside of this organization's OSPF AS.
ICX-Core-1(config)# ip route 198.18.11.0/24 10.255.101.11

5. Test with a ping to 198.18.11.1; this IP is hosted by Router-A using a loopback interface.
ICX-Core-1(config)# ping 198.18.11.1
PING 198.18.11.1 (198.18.11.1) 100(128) bytes of data.
108 bytes from 198.18.11.1: icmp_seq=1 ttl=64 time=2.20 ms
<output omitted>

6. Review the IP routing table on Core-1.

188 Task 4.3-1: Configure the link to Router-A

 ICX-Core-1(config)# show ip route static

Displaying ipv4 routes selected for forwarding

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

Lab 4.3: Managing OSPF external

VRF: default

Prefix Nexthop Interface VRF(egress)

Origin/ Distance/ Age

routes
Type Metric
----------------------------------------------------------------------------------------
10.1.128.0/18 - reject - S [110/0] 18h:41m:38s
10.1.192.0/18 - reject - S [110/0] 18h:30m:24s
10.254.1.0/24 10.255.101.11 1/1/7 - S [1/0] 03d:17h:55m
198.18.11.0/24 10.255.101.11 1/1/7 - S [1/0] 00h:02m:43s

Total Route Count : 4

At this point, Core-1 can reach the external network, but the rest of the OSPF AS cannot reach
this 198.18.11.0/24 network. This will be solved with route redistribution in the next task.

Task 4.3-2: Redistribute static routes into OSPF

Lab diagram

Objectives
In this task, the static route that was installed on the Core-1 router will now be distributed to the other
routers using OSPF route redistribution. The router that is inserting external routes into OSPF is known
as the ASBR. The ASBR can be a router in the backbone area or a router in another area. Other area

Task 4.3-2: Redistribute static routes into OSPF 189

types are covered in a later task in this lab.
In order to allow other OSPF routers to make a distinction between the routes of the OSPF autonomous
system and routes that are injected (imported/redistributed) into the AS (external routes), OSPF uses a
different LSA type from the intra-area (router/type 1 and network/type 2) and the inter-area (sum-
mary/type 3). All the routes that are injected by the ASBR are inserted as type 5 LSAs in the LSDB. For
example, if a complete AS has two routers that are injecting 100 routes each, the LSDB will contain 200
type 5 LSAs (2 x 100 routes).

Steps
n Redistribute static routes into OSPF.
n Verify the OSPF LSA type 5 in the backbone and other areas.
Core-1
1. Open a terminal session to Core-1 and enter configuration mode.
2. Review the current OSPF database summary. There are currently no external routes in the data-
base (the bottom of the output).
ICX-Core-1(config)# show ip ospf lsdb database-summary

<output omitted>

Process 1 database summary

---------------------------

LSA Type Count

---------------------------
Router 8
Network 2
Inter-area Summary 44
ASBR Summary 0
NSSA External 0
AS External 0
Total 54

3. Enter the OSPF router context and enable route redistribution of the static routes. This will
instruct the OSPF process to look into the local routing table for routes that match the redis-
tribution condition; in this case, the condition is static routes.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# redistribute static
ICX-Core-1(config-ospf-1)# exit

4. Verify in the LSDB that a new record was created for this external route.
ICX-Core-1(config)# show ip ospf lsdb database-summary

<output omitted>

190 Task 4.3-2: Redistribute static routes into OSPF

 Process 1 database summary
---------------------------

LSA Type Count

---------------------------
Router 8
Network 2
Inter-area Summary 44
ASBR Summary 0

Lab 4.3: Managing OSPF external

NSSA External 0
AS External 4
Total 58

routes
ICX-Core-1(config)# show ip ospf lsdb external
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

AS External Link State Advertisements

--------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.254.1.0 10.1.0.2 129 0x80000001 0x00009502
10.254.1.0 10.1.0.3 129 0x80000001 0x00008f07
198.18.11.0 10.1.0.2 129 0x80000001 0x0000ac11

The 10.254.1.0/24 static route was added during the VSX lab on both Core-1 and
Core-2. It provides access to the ClearPass server subnet. Due to the VSX OSPF sync,
Core-2 is now also redistributing its static route to the 10.254.1.0/24 subnet. These
routes can be ignored in this lab.

Core-2
5. Now, check the LSDB on Core-2 and Access-2. Access-2 is connected via Core-2 to Core-1.
Review that the external route has arrived in the LSDB.
ICX-Core-2(config)# show ip ospf lsdb external
OSPF Router with ID (10.1.0.3) (Process ID 1 VRF default)
===========================================================

AS External Link State Advertisements

--------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.254.1.0 10.1.0.2 176 0x80000001 0x00009502
10.254.1.0 10.1.0.3 174 0x80000001 0x00008f07
198.18.11.0 10.1.0.2 176 0x80000001 0x0000ac11

Task 4.3-2: Redistribute static routes into OSPF 191

 Access-2
ICX-Access-2(config)# show ip ospf lsdb external
OSPF Router with ID (10.1.0.5) (Process ID 1 VRF default)
===========================================================

AS External Link State Advertisements

--------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.254.1.0 10.1.0.2 200 0x80000001 0x00009502
10.254.1.0 10.1.0.3 199 0x80000001 0x00008f07
198.18.11.0 10.1.0.2 200 0x80000001 0x0000ac11

6. From Core-1, this route is a static route in the routing table. However, now review the IP routing
table on Access-2.
ICX-Access-2(config)# show ip route 198.18.11.0/24
VRF: default

Prefix : 198.18.11.0/24 VRF(egress) : -

Nexthop : 10.1.102.2 Interface : vlan102
Origin : ospf Type : ospf_type2_ext
Distance : 110 Metric : 25
Age : 00h:05m:03s Tag : 0
Encap Type : - Encap Details : -
n Question: Which router is the next-hop IP of this route?
n Answer: Next-hop IP 10.1.102.2 is the Core-1 router. It was calculated by OSPF to be the
shortest path to the ASBR that is announcing this route (Core-1).
Access-1
7. On Access-1, attempt to ping the remote host 198.18.11.1 to validate that all the routers on the
path to the ASBR know how to route this traffic.
ICX-Access-1(config)# ping 198.18.11.1
PING 198.18.11.1 (198.18.11.1) 100(128) bytes of data.
108 bytes from 198.18.11.1: icmp_seq=1 ttl=63 time=2.52 ms
<output omitted>

An IP always needs bidirectional communication paths. On Router-A, a static route

for 10.0.0.0/8 already exists in the configuration to handle the return traffic.

This demonstrates how OSPF can be used to distribute routes in the OSPF AS that were not ori-
ginated by the OSPF routers themselves.

192 Task 4.3-2: Redistribute static routes into OSPF

 Diagram: Access-2—external routes

Lab 4.3: Managing OSPF external

routes
ASBRs do not have to be in the backbone area. A router in a normal area can also redistribute
routes into the OSPF AS. In the next steps, Access-2 will be configured to inject an external
route. For testing purposes, Access-2 will be configured with a local static route that will be redis-
tributed into OSPF.
To provide a test IP in this subnet, a local loopback interface will be used. Since this test loop-
back interface is not enabled for OSPF, it will not be known as a native OSPF route. Only the
static route will be known to OSPF due to the redistribution.
Access-2
8. On Access-2 (OSPF area 2), define a new static route. A normal static route would be configured
to a real next-hop IP address. Since this is a test subnet and there is no real next hop router, the
next hop will be set to blackhole. This means that all traffic arriving for this subnet will be
dropped. In order to perform a test ping, a loopback address will be made in this test subnet.
ICX-Access-2(config)# ip route 198.18.14.0/24 nullroute

Older AOS-CX versions of code used the blackhole parameter instead of nullroute.
The current version of AOS-CX code has deprecated the blackhole parameter.

9. Define a new loopback interface; this can be used to test access to the 198.18.14.0/24 subnet.
ICX-Access-2(config)# interface loopback 198
ICX-Access-2(config-loopback-if)# ip address 198.18.14.1/32
ICX-Access-2(config-loopback-if)# exit

10. Redistribute the static route into OSPF.

ICX-Access-2(config)# router ospf 1
ICX-Access-2(config-ospf-1)# redistribute static

Task 4.3-2: Redistribute static routes into OSPF 193

 ICX-Access-2(config-ospf-1)# exit

Core-1
11. Verify in the backbone area that the external route is available.
ICX-Core-1(config)# show ip ospf routes 198.18.14.0/24
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table for prefixes 198.18.14.0/24

-------------------------------------------------------------------------

Total Number of Routes : 1

198.18.14.0/24 (E2)
via 10.1.102.5 interface vlan102, cost 25 distance 110

Access-1
Verify in OSPF area 1 that the new external route is available.
12. On Access-1, check the IP routing table for the 198.18.14.0 subnet.
ICX-Access-1(config)# show ip ospf routes 198.18.14.0/24
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table for prefixes 198.18.14.0/24

-------------------------------------------------------------------------

Total Number of Routes : 2

198.18.14.0/24 (E2)
via 10.1.101.2 interface vlan101, cost 25 distance 110
198.18.14.0/24 (E2)
via 10.1.101.3 interface vlan101, cost 25 distance 110
n Question: Why are there two paths available for this route?
n Answer: OSPF calculates the best path to reach the ASBR. In this case, there are two equal
cost paths to reach the ASBR (Access-2), so both paths are entered in the routing table.
13. Perform a traceroute to the test IP in the 198.18.14.0/24 subnet. The path should use either
Core-1 or Core-2 to reach the Access-2 router.
ICX-Access-1# traceroute 198.18.14.1
traceroute to 198.18.14.1 (198.18.14.1), 1 hops min, 30 hops max, 3 sec. timeout, 3
probes
1 10.1.101.2 0.202ms 0.099ms 0.504ms
2 198.18.14.1 0.188ms 0.101ms 0.099ms
ICX-Access-1#

194 Task 4.3-2: Redistribute static routes into OSPF

 Task 4.3-3: Control route redistribution and metric types
Introduction to metric types
OSPF has two metric types to describe the cost for external routes (LSA type 5 messages): external
type 1 (E1) and external type 2 (E2), where the latter is the default.

External type 2 (E2)

Lab 4.3: Managing OSPF external

In the case of an E2 route, the external route is entered into the OSPF LSDB with a static cost. This
static cost is not adjusted as the route is propagated by the OSPF routers. Therefore, a router that is
several hops away would still see the route with the same cost that was initially set by the redis-

routes
tributing ASBR. This is convenient to force the entire network to use a specific ASBR to reach a specific
external network, instead of the closest ASBR. This applies to scenarios where the traffic to the
external network must pass through a firewall (the customer wants to avoid an asynchronous routing
scenario that could cause problems for the traffic).

External type 1 (E1)

When there is no need for a fixed ASBR to the external network, OSPF can be configured to use the
path to the closest ASBR. This can be achieved by configuring the external route with a metric type
(E1). In this case, the OSPF path cost to reach the ASBR is added to the initial cost of the external
route.

Route maps
The configuration of the route metric types is done through a route policy (route map). Route policies
can also be used to filter routes that should not be redistributed.

Task 4.3-3: Control route redistribution and metric types 195

Lab diagram

Objectives
n Review the default cost and metric type of OSPF external routes.
n Add a static route on Core-1 that should not be redistributed using OSPF.
n Define a route policy on Core-1 to set the OSPF metric type 2 (E2) and set the initial cost to 100.

Steps
Core-1
1. On Core-1, add a dummy static route. In the current configuration, every static route will be redis-
tributed by OSPF. This route will be filtered by the route policy in the upcoming step.
ICX-Core-1(config)# ip route 198.18.12.0/24 nullroute

2. Verify this static route is redistributed in the current configuration.

ICX-Core-1(config-ospf-1)# show ip ospf lsdb external
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

AS External Link State Advertisements

--------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.254.1.0 10.1.0.2 213 0x80000003 0x00009104
10.254.1.0 10.1.0.3 213 0x80000003 0x00008b09
198.18.11.0 10.1.0.2 213 0x80000003 0x0000a813
198.18.12.0 10.1.0.2 7 0x80000001 0x0000a11b
198.18.14.0 10.1.0.5 387 0x80000002 0x0000773f

196 Task 4.3-3: Control route redistribution and metric types

 Access-2
3. Review the default cost and metric type. On Access-2, review the OSPF routing table, looking for
routes 198.18.11.0/24 and 198.18.12.0/24. Note the (E2) marking:
ICX-Access-2# show ip ospf routes 198.18.11.0/24
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

Lab 4.3: Managing OSPF external

OSPF Process ID 1 VRF default, Routing Table for prefixes 198.18.11.0/24
-------------------------------------------------------------------------

Total Number of Routes : 1

routes
198.18.11.0/24 (E2)
via 10.1.102.2 interface vlan102, cost 25 distance 110

ICX-Access-2# show ip ospf routes 198.18.12.0/24

Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table for prefixes 198.18.12.0/24

-------------------------------------------------------------------------

Total Number of Routes : 1

198.18.12.0/24 (E2)
via 10.1.102.2 interface vlan102, cost 25 distance 110
n Question: What is the default cost for the external route?
n Answer: The default cost is 25.

Task 4.3-3: Control route redistribution and metric types 197

 Define a route map to control redistribution

Now, a route map will be created on Core-1 to change the external route to metric type E1 for
the 198.18.11.0/24 prefix. This route map will be configured to also prevent route
198.18.12.0/24 from being redistributed.

Core-1—define a prefix list

First a prefix list must be defined; this defines which routes need to be controlled by the policy.
4. On Core-1, define a prefix list that matches the external route to Router-A. Any name can be
used; try to use a descriptive name. A prefix list can contain many prefixes, and the administrator
can control whether the entry should be matched (permit) or ignored (deny). This is why the
order sequence (seq) is important if permit/deny combinations would be used. In this example,
only one entry is used.
ICX-Core-1(config)# ip prefix-list routerAext seq 10 permit 198.18.11.0/24

Core-1—define a route map

5. Next, define a route map that references the prefix list and sets the metric type to external
type-1. Only routes that are permitted in the route policy are passing the route map. There is an
implicit deny at the end of the route map.
Since 198.18.12.0.24 does not match the prefix list and does not match any other rule in the
route map, it will not pass the route map.
ICX-Core-1(config)# route-map ospf_from_static permit seq 10
ICX-Core-1(config-route-map-ospf_from_static-10)# match ip address prefix-list
routerAext
ICX-Core-1(config-route-map-ospf_from_static-10)# set metric-type external type-1

6. Review the configuration.

ICX-Core-1(config-route-map-ospf_from_static-10)# show run current-config

198 Task 4.3-3: Control route redistribution and metric types

 route-map ospf_from_static permit seq 10
match ip address prefix-list routerAext
set metric-type external type-1
!

7. Exit the route map context.

ICX-Core-1(config-route-map-ospf_from_static-10)# exit

Activate the route map for redistributed routes

Lab 4.3: Managing OSPF external

8. Activate the route policy on the OSPF redistribution for static routes.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# redistribute static route-map ospf_from_static

routes
ICX-Core-1(config-ospf-1)# exit

Access-2
9. Verify the result on the Access-2 router. The 198.18.11.0/24 route should now be listed as E1,
and the cost will reflect the path to reach Core-1 (100) plus the initial cost (25 by default, if not
specified during the redistribution or in the respective route map entry).
ICX-Access-2# show ip ospf routes 198.18.11.0/24
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table for prefixes 198.18.11.0/24

-------------------------------------------------------------------------

Total Number of Routes : 1

198.18.11.0/24 (E1)
via 10.1.102.2 interface vlan102, cost 125 distance 110

10. The route to 198.18.12.0/24 should have been removed as well since it does not match the route
policy.
ICX-Access-2# show ip ospf routes 198.18.12.0/24
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table for prefixes 198.18.12.0/24

-------------------------------------------------------------------------

Total Number of Routes : 0

Core-1
11. Return to Core-1 and modify the route policy so the initial cost is now 1000.
ICX-Core-1(config)# route-map ospf_from_static permit seq 10
ICX-Core-1(config-route-map-ospf_from_static-10)# set metric 1000
ICX-Core-1(config-route-map-ospf_from_static-10)# exit

Task 4.3-3: Control route redistribution and metric types 199

 Access-2
12. Verify the result on Access-2. The cost should now be 1100, the 1000 initial cost plus cost 100
to reach Core-1.
ICX-Access-2(config)# show ip ospf routes 198.18.11.0/24
Codes: i - Intra-area route, I - Inter-area route
E1 - External type-1, E2 - External type-2

OSPF Process ID 1 VRF default, Routing Table for prefixes 198.18.11.0/24

-------------------------------------------------------------------------

Total Number of Routes : 1

198.18.11.0/24 (E1)
via 10.1.102.2 interface vlan102, cost 1100 distance 110

This demonstrates how a route policy can be used to control external routes.

Task 4.3-4: Filter routes with stub and totally stub areas
In this task, the stub and totally stubby (sometimes referred to as a "no-summary" stub) area types will
be configured.

Introduction to area types

Stub
When an area does not have an ASBR inside the area, this means that all the traffic destined to external
networks will need to go through the ABR systems. The logic here is: why distribute all those external
routes into the area, if the traffic has to go through the ABR routers anyway?
It would be convenient to aggregate all those external routes using the default route (0.0.0.0/0) that is
operating as the ultimate aggregation route. This is exactly what the stub area feature provides:
n The ABR will not announce the external type 5 routes from the backbone into the stub area.
n The ABR will announce a default route (0.0.0.0/0) into the area.
n Routers inside the stub area will see the 0.0.0.0/0 route, but they will not see the external routes
anymore.
n Routers inside the stub area will still see all the OSPF intra-area and inter-area (OSPF LSA type 3
summary).

The stub area feature must be configured on every router in the area, including the ABRs.

200 Task 4.3-4: Filter routes with stub and totally stub areas
 Stub no-summary
Besides the stub area feature, an administrator can configure the area to be a stub no-summary area.
Since the routers inside the stub area already have the default route 0.0.0.0/0, this default route could
also be used to aggregate all the OSPF inter-area routes (OSPF LSA type 3 summary routes). This
results in the name stub no-summary. This feature is also known as a "totally stubby area".

The extra no-summary parameter is only configured on the ABR systems.

Lab 4.3: Managing OSPF external

Objectives

routes
n Configure and verify a stub area.
n Configure and verify a totally stubby area.

Steps
Diagram: make area 1 an OSPF stub area

Access-1
Review that Access-1 in area 1 sees all the external routes.
1. On Access-1, check the IP routing table. Notice that there is no default route needed at this
point, since all external routes are actually known to the router. Therefore, there is no 0.0.0.0/0
entry at this moment.
ICX-Access-1# show ip route 0.0.0.0

No ipv4 routes configured

Task 4.3-4: Filter routes with stub and totally stub areas 201
 Core-1
2. Make area 1 a stub area. This will summarize all the external routes into the default route
0.0.0.0/0. This action (injecting the default route) is done at the ABR and should be done on each
ABR. In this lab setup, Core-1 and Core-2 are part of a VSX setup, so making area 1 a stub area
on Core-1 will automatically be synchronized to Core-2 due to the VSX OSPF synchronization.
3. Open Core-1 and make area 1 a stub under the OSPF context.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# area 1 stub

4. Verify, using the vsx-peer command, that Core-2 also has area 1 set as stub.
ICX-Core-1(config-ospf-1)# show run ospf vsx-peer
router ospf 1
router-id 10.1.0.3
passive-interface default
redistribute static route-map ospf_from_static
area 0.0.0.0
area 0.0.0.1 stub
area 0.0.0.1 range 10.1.128.0/18 type inter-area
area 0.0.0.2
area 0.0.0.2 range 10.1.99.0/24 type inter-area no-advertise
area 0.0.0.2 range 10.1.192.0/18 type inter-area
interface loopback 0
ip ospf 1 area 0.0.0.0
interface vlan1
ip ospf 1 area 0.0.0.0

<output omitted>

ICX-Core-1(config-ospf-1)# exit

Access-1
5. On the Access-1 router (router inside area 1), examine the IP routing table for OSPF routes.
ICX-Access-1# show ip route ospf

No ipv4 routes configured

n Question: Are there any OSPF routes in the routing table?
n Answer: No, there are no more OSPF routes.
n Question: Why did the OSPF routes disappear?
n Answer: The OSPF stub area option must be enabled on all routers in that area. The stub
option is checked using the OSPF hello packets; a mismatch will prevent an OSPF neighbor
adjacency.

202 Task 4.3-4: Filter routes with stub and totally stub areas
 6. Check the OSPF interface statistics. There should be dropped hello packets due to Options mis-
match.
ICX-Access-1# show ip ospf statistics interface vlan101

<output omitted>

Reason Packets Dropped

----------------------------------------------

Lab 4.3: Managing OSPF external

Invalid type 0
Invalid length 0
Invalid checksum 0
Invalid version 0

routes
Bad or unknown source 8
Area mismatch 0
Self-originated 0
Duplicate router ID 0
Interface standby 0
Total Hello packets dropped 62
Network Mask mismatch 0
Hello interval mismatch 0
Dead interval mismatch 0
Options mismatch 62
MTU mismatch 0
<output omitted>

7. View the OSPF neighbor table. Core-1 and Core-2 should no longer be listed as neighbors.
ICX-Access-1(config)# show ip ospf neighbors
No OSPF neighbor found on VRF default.

8. On Access-1, change the area 1 type to stub.

ICX-Access-1(config)# router ospf 1
ICX-Access-1(config-ospf-1)# area 1 stub
ICX-Access-1(config-ospf-1)# exit

9. Wait until the OSPF adjacencies re-form.

ICX-Access-1(config)# show ip ospf neighbors
VRF : default Process : 1
===================================================

Total Number of Neighbors : 2

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.2 1 FULL/BDR 10.1.101.2 vlan101

10.1.0.3 1 FULL/DR 10.1.101.3 vlan101

10. Review the routing table. The external routes should have been replaced with a default route by
the ABR.

Task 4.3-4: Filter routes with stub and totally stub areas 203
 It may take a few moments for the OSPF adjacencies to re-establish. Within about 30
seconds, the OSPF routes should appear.

ICX-Access-1(config)# show ip route 0.0.0.0

VRF: default

Prefix : 0.0.0.0/0 VRF(egress) : -

Nexthop : 10.1.101.2 Interface : vlan101
Origin : ospf Type : ospf_inter_area
Distance : 110 Metric : 101
Age : 00h:00m:43s Tag : 0
Encap Type : - Encap Details : -

Prefix : 0.0.0.0/0 VRF(egress) : -

Nexthop : 10.1.101.3 Interface : vlan101
Origin : ospf Type : ospf_inter_area
Distance : 110 Metric : 101
Age : 00h:00m:43s Tag : 0
Encap Type : - Encap Details : -
n Question: What is the cost of the default route?
n Answer: The cost is 101. This is based on 100 to reach Core-1/Core-2; the metric for the
default route is 1, by default.
n Question: What type of LSA are the ABRs injecting into area 1?
n Answer: LSA type 3 (summary).
11. On Access-1, check which route it would take for the traffic to 198.18.11.0. Since the specific
route to 198.18.11.0 is no longer available, the default route is used.
ICX-Access-1(config)# show ip route 198.18.11.0

VRF: default

Prefix : 0.0.0.0/0 VRF(egress) : -

Nexthop : 10.1.101.2 Interface : vlan101
Origin : ospf Type : ospf_inter_area
Distance : 110 Metric : 101
Age : 00h:00m:43s Tag : 0
Encap Type : - Encap Details : -

Prefix : 0.0.0.0/0 VRF(egress) : -

Nexthop : 10.1.101.3 Interface : vlan101
Origin : ospf Type : ospf_inter_area
Distance : 110 Metric : 101
Age : 00h:00m:43s Tag : 0
Encap Type : - Encap Details : -

204 Task 4.3-4: Filter routes with stub and totally stub areas
 Core-1
12. On Core-1, review the routing table, looking for the default route 0.0.0.0/0.
ICX-Core-1(config)# show ip route 0.0.0.0

No ipv4 routes configured

n Question: Is there a default route on Core-1?

Lab 4.3: Managing OSPF external

n Answer: No. The ABR will announce the default route into the stub area, but it does not
need the default route itself, since it knows all the external routes.
This demonstrates how the stub area feature of OSPF can automatically summarize all external

routes
routes with the default route.

Diagram: Make area 1 a stub no-summary area (totally stubby area)

The stub feature in area 1 is summarizing all the external routes for this area into the default
route, while it still sees all the detailed OSPF inter-area routes. It is also possible to summarize all
the OSPF inter-area routes into this default route, so all the OSPF summary LSAs (type 3) will be
removed as well. Since the OSPF summary LSA is suppressed by this action, this feature is known
as "stub no-summary".
Access-1
13. First, verify on Access-1 that the OSPF inter-area routes are still visible. Review the IP routing
table, looking for OSPF routes.
ICX-Access-1(config)# show ip route ospf

Displaying ipv4 routes selected for forwarding

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN

Task 4.3-4: Filter routes with stub and totally stub areas 205
 IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2
Flags: F - FIB-optimized route

VRF: default

Prefix Nexthop Interface VRF(egress)

Origin/ Distance/ Age
Type Metric
---------------------------------------------------------------------------------
0.0.0.0/0 10.1.101.2 vlan101 - O/IA [110/101] 00h:10m:12s
10.1.101.3 vlan101 - [110/101] 00h:10m:12s
10.1.0.2/32 10.1.101.2 vlan101 - O/IA [110/100] 00h:10m:12s
10.1.0.3/32 10.1.101.3 vlan101 - O/IA [110/100] 00h:10m:12s
10.1.0.5/32 10.1.101.2 vlan101 - O/IA [110/200] 00h:10m:12s
10.1.101.3 vlan101 - [110/200] 00h:10m:12s
10.1.2.2/31 10.1.101.2 vlan101 - O/IA [110/101] 00h:10m:12s
10.1.101.3 vlan101 - [110/101] 00h:10m:12s
10.1.11.0/24 10.1.101.2 vlan101 - O/IA [110/200] 00h:10m:13s
10.1.101.3 vlan101 - [110/200] 00h:10m:13s
10.1.12.0/24 10.1.101.2 vlan101 - O/IA [110/200] 00h:10m:13s
10.1.101.3 vlan101 - [110/200] 00h:10m:13s
10.1.102.0/24 10.1.101.2 vlan101 - O/IA [110/200] 00h:10m:13s
10.1.101.3 vlan101 - [110/200] 00h:10m:13s
10.1.192.0/18 10.1.101.2 vlan101 - O/IA [110/300] 00h:10m:13s
10.1.101.3 vlan101 - [110/300] 00h:10m:13s

Core-1
14. Now make the area a stub no-summary area. This must only be done on the ABR, since that is
the router that will filter the routes. On Core-1, change area 1 to no-summary. This change
should be made on every ABR, but due to the VSX synchronization, this is automatically pushed
to Core-2.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# area 1 stub no-summary
ICX-Core-1(config-ospf-1)# exit

Access-1
15. On Access-1, verify the impact on the routing table. All OSPF external and inter-area routes have
been replaced with the default route.
ICX-Access-1(config)# show ip route ospf

Displaying ipv4 routes selected for forwarding

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2
Flags: F - FIB-optimized route

206 Task 4.3-4: Filter routes with stub and totally stub areas
 VRF: default

Prefix Nexthop Interface VRF(egress)

Origin/ Distance/ Age
Type Metric
---------------------------------------------------------------------------------
0.0.0.0/0 10.1.101.2 vlan101 - O/IA [110/101] 00h:00m:22s
10.1.101.3 vlan101 - [110/101] 00h:00m:22s

Lab 4.3: Managing OSPF external

16. Examine the LSDB for external and summary routes.
ICX-Access-1(config)# show ip ospf lsdb external
No OSPF LSAs found on VRF default.

routes
ICX-Access-1(config)# show ip ospf lsdb summary
OSPF Router with ID (10.1.0.4) (Process ID 1 VRF default)
==========================================================

Inter-area Summary Link State Advertisements (Area 0.0.0.1)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
0.0.0.0 10.1.0.2 135 0x80000001 0x0000252c
0.0.0.0 10.1.0.3 134 0x80000001 0x00001f31
n Question: Are there any external routes (LSA type 5)?
n Answer: No.
n Question: Are there any summary routes (LSA type 3)?
n Answer: Yes, but just the two default routes from the core switches.
17. Verify that Access-1 can still reach the external network to Router-A and Access-2.
ICX-Access-1(config)# ping 198.18.11.1
PING 198.18.11.1 (198.18.11.1) 100(128) bytes of data.
108 bytes from 198.18.11.1: icmp_seq=1 ttl=63 time=2.39 ms
<...output omitted...>

ICX-Access-1(config)# ping 198.18.14.1

PING 198.18.14.1 (198.18.14.1) 100(128) bytes of data.
108 bytes from 198.18.14.1: icmp_seq=1 ttl=63 time=0.183 ms
<...output omitted...>

18. Verify Access-1 can still reach the loopback IP on Access-2 (an inter-area route).
ICX-Access-1(config)# ping 10.1.0.5
PING 10.1.0.5 (10.1.0.5) 100(128) bytes of data.
108 bytes from 10.1.0.5: icmp_seq=1 ttl=63 time=0.180 ms
<output omitted>

Task 4.3-4: Filter routes with stub and totally stub areas 207
 This demonstrates how Access-1's routing table can benefit from the summarization (smaller
OSPF LSDB and IP routing tables) while Access-1 still maintains full connectivity to the rest of
the network.

Task 4.3-5: Filter routes with an NSSA

While a stub area benefits from the route summarization that is performed by the ABR, it is also limited
now, since it cannot announce any external networks by itself anymore. When the administrator
attempts to redistribute a route on a router in a stub area, OSPF will simply not process the request.
In these steps, Access-1 will make a connection to an external network, and the rest of the OSPF AS
needs access to this external network as well. At the same time, Access-1 should still be optimized, so it
does not get all the external routes from the backbone area.

Lab diagram

Objectives
n Configure and verify an NSSA area.

Steps
Verify the problem
Access-1
1. On Access-1, introduce a new external network. Since there is no real external network in this lab,
it will be simulated using a nullroute static route and a local loopback interface. This is similar to
the setup on Access-2.
ICX-Access-1(config)# ip route 198.18.13.0/24 nullroute
ICX-Access-1(config)# interface loopback 198
ICX-Access-1(config-loopback-if)# ip address 198.18.13.1/32
ICX-Access-1(config-loopback-if)# exit

208 Task 4.3-5: Filter routes with an NSSA

 2. Now, attempt to redistribute the static route into OSPF.
ICX-Access-1(config)# router ospf 1
ICX-Access-1(config-ospf-1)# redistribute static
ICX-Access-1(config-ospf-1)# exit

3. Check the local OSPF LSDB, looking for external routes.

ICX-Access-1(config)# show ip ospf lsdb
OSPF Router with ID (10.1.0.4) (Process ID 1 VRF default)

Lab 4.3: Managing OSPF external

===========================================================

Router Link State Advertisements (Area 0.0.0.1)

------------------------------------------------

routes
LSID ADV Router Age Seq# Checksum Link Count
-------------------------------------------------------------------------------
10.1.0.2 10.1.0.2 166 0x80000006 0x00008a35 1
10.1.0.3 10.1.0.3 2 0x80000009 0x00008237 1
10.1.0.4 10.1.0.4 1 0x8000000d 0x00005943 3

Network Link State Advertisements (Area 0.0.0.1)

-------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.1.101.3 10.1.0.3 2 0x80000002 0x0000cba8

Inter-area Summary Link State Advertisements (Area 0.0.0.1)

------------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
0.0.0.0 10.1.0.2 1506 0x80000003 0x0000c87b
0.0.0.0 10.1.0.3 1506 0x80000003 0x0000c280
n Question: Are there any external LSAs in the OSPF LSDB?
n Answer: No. Since this is a stub area, OSPF does not actually perform the redistribution.
This means that Core-1 and Core-2 would never be able to learn about the new
198.18.13.0/24 route.
4. A filtered view of just the external LSAs in the LSDB shows the same result.
ICX-Access-1(config)# show ip ospf lsdb external
No OSPF LSAs found on VRF default.

ICX-Access-1(config)#

Task 4.3-5: Filter routes with an NSSA 209

 Solution: NSSA
The solution for this scenario is to convert the area into an NSSA area type. This will allow
external routes to be exchanged via the OSPF LSDB as LSA type 7 entries (since LSA type 5 is
not allowed by a stub area). The ABR will convert the type 7 LSAs into the regular type 5 LSAs in
the backbone. Any other areas in the OSPF autonomous system are not aware that this NSSA
configuration was used, since they only see the external routes as LSA type 5.
5. On Access-1, convert the area type to nssa.
ICX-Access-1(config)# router ospf 1
ICX-Access-1(config-ospf-1)# area 1 nssa
ICX-Access-1(config-ospf-1)# exit

6. Review the OSPF LSDB. There should be an NSSA external LSA.

ICX-Access-1(config)# show ip ospf lsdb
OSPF Router with ID (10.1.0.4) (Process ID 1 VRF default)
===========================================================

Router Link State Advertisements (Area 0.0.0.1)

------------------------------------------------

LSID ADV Router Age Seq# Checksum Link Count

-------------------------------------------------------------------------------
10.1.0.4 10.1.0.4 30 0x80000001 0x0000928d 3

NSSA External Link State Advertisements (Area 0.0.0.1)

-------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.254.1.0 10.1.0.4 21 0x80000001 0x000044df
198.18.13.0 10.1.0.4 30 0x80000001 0x000071c0
n Question: Why are all the other LSAs gone from the LSDB?
n Answer: The NSSA area type is also included in the OSPF hello. Since Core-1 and Core-2
still have the stub area type, Access-1 no longer has an OSPF adjacency with them. This
can be verified using the show ip ospf neighbors command.

Remember that Access-1 also has a static route for 10.254.1.0/24 that you con-
figured during Lab 2 on VSX; for this lab, you can ignore this route. However, in a pro-
duction network, you should use an IP prefix list and remote map and only inject the
routes that are necessary.

7. Notice that the NSSA external (LSA type 7) and regular external (LSA type 5) are shown sep-
arately in the LSDB.
ICX-Access-1(config)# show ip ospf lsdb external
No OSPF LSAs found on VRF default.

210 Task 4.3-5: Filter routes with an NSSA

 ICX-Access-1(config)# show ip ospf lsdb nssa-external
OSPF Router with ID (10.1.0.4) (Process ID 1 VRF default)
===========================================================

NSSA External Link State Advertisements (Area 0.0.0.1)

-------------------------------------------------------

Lab 4.3: Managing OSPF external

LSID ADV Router Age Seq# Checksum
--------------------------------------------------------------
10.254.1.0 10.1.0.4 225 0x80000001 0x000044df
198.18.13.0 10.1.0.4 10 0x80000001 0x000071c0

routes
Core-1
8. On Core-1, change area 1 to an NSSA area type. VSX will synchronize this to Core-2 auto-
matically.
ICX-Core-1(config)# router ospf 1
ICX-Core-1(config-ospf-1)# area 1 nssa
ICX-Core-1(config-ospf-1)# exit

9. Wait a few moments for the OSPF adjacencies to re-establish.

ICX-Core-1(config)# show ip ospf neighbors
VRF : default Process : 1
===================================================

Total Number of Neighbors : 5

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.3 n/a FULL 10.1.2.3 vlan2

10.1.0.3 1 FULL/BDR 10.1.101.3 vlan101

10.1.0.4 1 FULL/DR 10.1.101.4 vlan101

10.1.0.3 1 FULL/DR 10.1.102.3 vlan102

10.1.0.5 1 FULL/DROther 10.1.102.5 vlan102

10. Verify that NSSA external LSAs are now appearing in the LSDB of area 1.
ICX-T12-Core-1(config)# show ip ospf lsdb nssa-external area 1
OSPF Router with ID (10.1.0.2) (Process ID 1 VRF default)
===========================================================

NSSA External Link State Advertisements (Area 0.0.0.1)

-------------------------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------

Task 4.3-5: Filter routes with an NSSA 211

 0.0.0.0 10.1.0.2 93 0x80000001 0x00002891
0.0.0.0 10.1.0.3 89 0x80000001 0x00002296
10.254.1.0 10.1.0.4 374 0x80000001 0x000044df
198.18.11.0 10.1.0.2 93 0x80000001 0x00006407
198.18.13.0 10.1.0.4 221 0x80000001 0x000071c0

Access-2
11. Verify the routes in another area, like area 2. Now switch to Access-2 and verify the routing
table. The route to 198.18.13.0 should now be available.
ICX-Access-2(config)# show ip route 198.18.13.0

VRF: default

Prefix : 198.18.13.0/24 VRF(egress) : -

Nexthop : 10.1.102.2 Interface : vlan102
Origin : ospf Type : ospf_type2_ext
Distance : 110 Metric : 25
Age : 00h:01m:41s Tag : 0
Encap Type : - Encap Details : -

Prefix : 198.18.13.0/24 VRF(egress) : -

Nexthop : 10.1.102.3 Interface : vlan102
Origin : ospf Type : ospf_type2_ext
Distance : 110 Metric : 25
Age : 00h:01m:41s Tag : 0
Encap Type : - Encap Details : -

This demonstrates how Area 1 still benefits from the route summarization of the stub area fea-
ture, while at the same time it can announce a route to an external network.
12. Review the OSPF LSDB of area 2, looking for the external and nssa-external entries in the
LSDB.
ICX-Access-2# show ip ospf lsdb nssa-external
No OSPF LSAs found on VRF default.

ICX-T12-Access-2# show ip ospf lsdb external

OSPF Router with ID (10.1.0.5) (Process ID 1 VRF default)
===========================================================

AS External Link State Advertisements

--------------------------------------

LSID ADV Router Age Seq# Checksum

--------------------------------------------------------------
10.254.1.0 10.1.0.3 209 0x80000001 0x0000c06c
10.254.1.0 10.1.0.5 1769 0x80000003 0x0000d7c5
198.18.11.0 10.1.0.2 1373 0x80000007 0x0000560f
198.18.13.0 10.1.0.3 193 0x80000001 0x0000ed4d
198.18.14.0 10.1.0.5 29 0x80000006 0x00006f43

212 Task 4.3-5: Filter routes with an NSSA

 n Question: Why is the entry for the 198.18.13.0/24 network not shown as an NSSA
external route?
n Answer: NSSA-external only has meaning inside the NSSA area. When the ABR receives
these NSSA (LSA type 7) entries, it converts them into regular external routes (LSA type
5) in the backbone area, so the backbone area and any other areas are not aware of this.

Core 1: Revert area 1 to a normal area

Lab 4.3: Managing OSPF external

13. Area 1 will now be reverted to a normal area. On Core-1 and Core-2, remove the NSSA type for
area 1.
ICX-Core-1(config)# router ospf 1

routes
ICX-Core-1(config-ospf-1)# no area 1 nssa
ICX-Core-1(config-ospf-1)# exit

Access-1
14. On Access-1, repeat this step.
ICX-Access-1(config)# router ospf 1
ICX-Access-1(config-ospf-1)# no area 1 nssa

15. Remove the static route redistribution from OSPF.

ICX-Access-1(config-ospf-1)# no redistribute static
ICX-Access-1(config-ospf-1)# exit

16. On Access-1, verify OSPF adjacency is back to both core switches.

ICX-Access-1(config)# show ip ospf neighbors
OSPF Process ID 1 VRF default
==============================

Total Number of Neighbors: 2

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.0.2 1 FULL/BDR 10.1.101.2 vlan101

10.1.0.3 1 FULL/DROther 10.1.101.3 vlan101

It may take a few moments for the OSPF adjacencies to re-establish. Repeat the com-
mand until the FULL state is shown.

17. Verify that external routes are available again; check, for example, the OSPF route to the
198.18.11.0/24 network.
ICX-Access-1(config)# show ip route 198.18.11.0

VRF: default

Prefix : 198.18.11.0/24 VRF(egress) : -

Task 4.3-5: Filter routes with an NSSA 213

 Nexthop : 10.1.101.2 Interface : vlan101
Origin : ospf Type : ospf_type1_ext
Distance : 110 Metric : 1100
Age : 00h:01m:55s Tag : 0
Encap Type : - Encap Details : -

Access-2
18. On Access-2, remove the static route redistribution from OSPF.
ICX-Access-2(config)# router ospf 1
ICX-Access-2(config-ospf-1)# no redistribute static
ICX-Access-2(config-ospf-1)# exit

This concludes the NSSA task.

Task 4.3-6: Save configuration checkpoints for the upcoming labs

You have now completed the OSPF configuration lab. In this task, you will save your configurations as
checkpoints.

IMPORTANT: This configuration will be the base configuration used in some later labs, so a
checkpoint MUST be created to complete the rest of the course lab activities. This is crit-
ical, so do not skip this step!

1. On Core-1, save the current configuration as a checkpoint.

ICX-Core-1(config)# end
ICX-Core-1# copy run checkpoint icx-lab043-ospf
Copying configuration: [Success]
ICX-Core-1(config)#

2. Repeat this on Core-2.

ICX-Core-2(config)# end
ICX-Core-2# copy run checkpoint icx-lab043-ospf
Copying configuration: [Success]
ICX-Core-2(config)#

3. Repeat this on Access-1.

ICX-Access-1(config)# end
ICX-Access-1# copy run checkpoint icx-lab043-ospf
Copying configuration: [Success]
ICX-Access-1(config)#

4. Repeat this on Access-2.

ICX-Access-2(config)# end
ICX-Access-2# copy run checkpoint icx-lab043-ospf
Copying configuration: [Success]
ICX-Access-2(config)#

214 Task 4.3-6: Save configuration checkpoints for the upcoming labs
 Verify the checkpoint creation
5. On all four switches, verify that the checkpoint exists in the checkpoint list.
ICX-switch1-4# show checkpoint | include ospf
icx-lab043-ospf latest User 2024-05-10T17:42:35Z FL.10.13.1000

You have completed Lab 4.3!

Lab 4.3: Managing OSPF external

routes

Task 4.3-6: Save configuration checkpoints for the upcoming labs 215
[This page intentionally left blank]

216 Task 4.3-6: Save configuration checkpoints for the upcoming labs
Lab 5: Basic BGP peering

Lab 5: Basic BGP peering

Lab diagram

Overview
In this lab activity, basic BGP peering will be demonstrated. As you can see in the previous diagram,
there are four autonomous systems. Router-B and Router-C have the correct configuration on them for
BGP. On Router-A, you will have to load a pre-configured BGP checkpoint to load its BGP configuration.
Each of these three BGP routers represents their own AS.
The four physical switches represent AS 64500. The two core switches will be configured to use iBGP
between each other. They will use eBGP to communicate with two different ISPs, one connected to each
core switch. Once the BGP peering has been established, a route advertisement will be configured. The
core switches will also be configured with a route policy so they do not become a transit AS for traffic
between the service providers.

Objectives
n Set up eBGP and iBGP peering.
n Advertise routes using BGP.
n Configure a route policy to control BGP routing updates.

Lab 5: Basic BGP peering 217

Task 5-1: Prepare the lab setup
This lab requires the completion of the OSPF lab activities (single area, multiarea, and external routes).

Steps
Access-1
1. Open a console connection to Access-1. Log in using admin/aruba123.
ICX-Access-1# copy checkpoint icx-lab043-ospf running-config
Configuration changes will take time to process, please be patient.
ICX-Access-1#

Access-2
2. Open a console connection to Access-2. Log in using admin/aruba123.
ICX-Access-2# copy checkpoint icx-lab043-ospf running-config
Configuration changes will take time to process, please be patient.
ICX-Access-2#

Core-1
3. Open a console connection to Core-1. Log in using admin/aruba123.
ICX-Core-1# copy checkpoint icx-lab043-ospf running-config
Configuration changes will take time to process, please be patient.
ICX-Core-1#

Core-2
4. Open a console connection to Core-2. Log in using admin/aruba123.
ICX-Core-2# copy checkpoint icx-lab043-ospf running-config
Configuration changes will take time to process, please be patient.
ICX-Core-2#

Task 5-2: Core-1 eBGP peering to ISP1

Objectives
In this task, Core-1 will be configured to establish an eBGP peering with ISP Router-A. Since Router-A is
running as a VM, there is no direct physical link between Core-1 and Router-A, so it can take more time
to detect that the peer is unreachable. Shutting the interfaces down between Router-A and Core-1 or
Router-B and Core-2 will not cause the BGP session to fail immediately—BGP's keepalive timer is used
by default. This will be sped up by implementing Bidirectional Forward Detection (BFD), which imple-
ments a simple keepalive protocol with the support for sub-second convergence, if necessary.

Steps
Core-1
1. Open a terminal connection to Core-1 and enter configuration mode.

218 Task 5-1: Prepare the lab setup

 2. In the OSPF lab, a routed link was established to Router-A. Verify that Core-1 can reach Router-
A.
ICX-Core-1(config)# ping 10.255.101.11
PING 10.255.101.11 (10.255.101.11) 100(128) bytes of data.
108 bytes from 10.255.101.11: icmp_seq=1 ttl=64 time=1.49 ms
108 bytes from 10.255.101.11: icmp_seq=2 ttl=64 time=1.79 ms
<output omitted>

3. Enable BGP for AS 64500.

ICX-Core-1(config)# router bgp 64500

4. Define Router-A as a BGP neighbor.

ICX-Core-1(config-bgp)# neighbor 10.255.101.11 remote-as 64511

5. Enter the IPv4 address family and enable the peer Router-A for IPv4.
ICX-Core-1(config-bgp)# address-family ipv4 unicast
ICX-Core-1(config-bgp-ipv4-uc)# neighbor 10.255.101.11 activate
ICX-Core-1(config-bgp-ipv4-uc)# exit
ICX-Core-1(config-bgp)# exit

6. Verify the status of the BGP session; it should be established. The state may be Idle initially.

Lab 5: Basic BGP peering

Wait for the state to change to Established.
ICX-Core-1(config)# show bgp all summary
VRF : default
BGP Summary
-----------
Local AS : 64500 BGP Router Identifier : 10.1.0.2
Peers : 1 Log Neighbor Changes : No
Cfg. Hold Time : 180 Cfg. Keep Alive : 60

Address-family : IPv4 Unicast

-----------------------------
Neighbor Remote-AS MsgRcvd MsgSent Up/Down Time State AdminStatus
10.255.101.11 64511 10 12 00h:03m:30s Established Up

Address-family : IPv6 Unicast

-----------------------------

Address-family : L2VPN EVPN

n Question: What are the default keepalive and hold-down times for BGP sessions?
n Answer: By default, they are 60 and 180 seconds, respectively.

Verify the impact of the default BGP keepalive interval (default of 60 seconds)
7. On Core-1, disable the interface that connects to Router-A.
ICX-Core-1(config)# interface 1/1/7
ICX-Core-1(config-if)# shutdown
ICX-Core-1(config-if)# exit

Task 5-2: Core-1 eBGP peering to ISP1 219

 8. Review the status of the BGP neighbor using the show bgp all summary command.
9. Wait about 30 seconds and review the status again. It should still be Established, even when the
link is down for a period of 180 seconds.
ICX-Core-1(config)# show bgp all summary

10. Wait until the status transitions to Idle.

ICX-Core-1(config)# show bgp all summary
VRF : default
BGP Summary
-----------
Local AS : 64500 BGP Router Identifier : 10.1.0.2
Peers : 1 Log Neighbor Changes : No
Cfg. Hold Time : 180 Cfg. Keep Alive : 60

Address-family : IPv4 Unicast

-----------------------------
Neighbor Remote-AS MsgRcvd MsgSent Up/Down Time State AdminStatus
10.255.101.11 64511 12 18 00h:01m:06s Idle Up

Address-family : IPv6 Unicast

-----------------------------

Address-family : L2VPN EVPN

-----------------------------

This demonstrates that, by default, it can take several minutes before BGP detects that a peer is
not reachable on a non-direct connection link. In the next section, a BFD solution will be con-
figured to speed up BGP convergence.
11. Enable the interface to Router-A again.
ICX-Core-1(config)# interface 1/1/7
ICX-Core-1(config-if)# no shutdown
ICX-Core-1(config-if)# exit

12. Wait for the state to change to Established.

ICX-Core-1(config)# show bgp all summary
VRF : default
BGP Summary
-----------
Local AS : 64500 BGP Router Identifier : 10.1.0.2
Peers : 1 Log Neighbor Changes : No
Cfg. Hold Time : 180 Cfg. Keep Alive : 60

Address-family : IPv4 Unicast

-----------------------------
Neighbor Remote-AS MsgRcvd MsgSent Up/Down Time State AdminStatus
10.255.101.11 64511 10 12 00h:03m:30s Established Up

Address-family : IPv6 Unicast

220 Task 5-2: Core-1 eBGP peering to ISP1

 -----------------------------

Address-family : L2VPN EVPN

Use BFD for a faster peer keepalive detection solution

13. On Core-1, enter the BGP context and enable BFD for the Router-A neighbor. On Router-A, this
command (neighbor <IP-ADDRESS> fall-over bfd) should also be enabled. In the lab setup, this
has been done already.
ICX-Core-1(config)# router bgp 64500
ICX-Core-1(config-bgp)# neighbor 10.255.101.11 fall-over bfd
ICX-Core-1(config-bgp)# exit

14. Verify the current BFD sessions.

ICX-Core-1(config)# show bfd

Admin status: disabled

Statistics:
Total number of control packets transmitted: 0
Total number of control packets received: 0
Total number of control packets dropped: 0

Lab 5: Basic BGP peering

Session Interface VRF Source Destination IP Echo State Protocol
------- --------- --------- ------------- ---------------------- ----------- --------
1 1/1/7 default 10.255.101.2 10.255.101.11 enabled admin_down bgp
ICX-Core-1(config)#

ICX-Core-1(config)# show bfd session 1

BFD session information - Session 1

VRF: default
Min Tx interval (msec): 3000
Min Rx interval (msec): 3000
Min echo Rx interval (msec): 500
Detect multiplier: 5
Application: bgp
Local discriminator: 13211
Remote discriminator: 366
Echo: enabled
Local diagnostic: administratively_down
Remote diagnostic: no_diagnostic
State flaps: 0
Interface Source IP Destination IP State Pkt Rx Pkt Tx Pkt drop
--------- --------------------------------------- -------------------------------
1/1/7 10.255.101.2 10.255.101.11 admin_down 27 26 0
ICX-Core-1(config)#

n Question: Has a BFD session been established to Router-A, and what would be the
reason?

Task 5-2: Core-1 eBGP peering to ISP1 221

 n Answer: No BFD session is active at the moment, since the BFD process is not enabled at
the global level (admin_down). BFD must be enabled globally as well as for the particular
protocol, like BGP.
15. Enable BFD globally on Core-1.
ICX-Core-1(config)# bfd

Router-A
16. Access Router-A and globally enable BFD.
ICX-RouterA(config)# bfd

Core-1
17. Access Core-1. Review the state of BFD. The state will transition from admin_down > down >
init > up.
ICX-Core-1(config)# show bfd session 1

BFD session information - Session 1

VRF: default
Min Tx interval (msec): 3000
Min Rx interval (msec): 3000
Min echo Rx interval (msec): 500
Detect multiplier: 5
Application: bgp
Local discriminator: 13211
Remote discriminator: 366
Echo: enabled
Local diagnostic: no_diagnostic
Remote diagnostic: no_diagnostic
State flaps: 0
Interface Source IP Destination IP State Pkt Rx Pkt Tx Pkt drop
--------- --------------------------------------- -------------------------------
1/1/7 10.255.101.2 10.255.101.11 up 0 0 0

n Question: What is the default echo Rx interval?

n Answer: 500 milliseconds (half a second).
n Question: What is the default hold-down interval?
n Answer: 5 (detect multiplier) x 500 ms (echo Rx interval) = 2.5 seconds.

Verify the BFD operation

18. Now, repeat the test by bringing down the interface to Router-A.
ICX-Core-1(config)# interface 1/1/7
ICX-Core-1(config-if)# shutdown
ICX-Core-1(config-if)# exit

19. Check the BGP neighbor state. Within a few seconds, the state should transition to Idle.

222 Task 5-2: Core-1 eBGP peering to ISP1

 ICX-Core-1(config)# show bgp all summary
VRF : default
BGP Summary
-----------
Local AS : 64500 BGP Router Identifier : 10.1.0.2
Peers : 1 Log Neighbor Changes : No
Cfg. Hold Time : 180 Cfg. Keep Alive : 60

Address-family : IPv4 Unicast

-----------------------------
Neighbor Remote-AS MsgRcvd MsgSent Up/Down Time State AdminStatus
10.255.101.11 64511 30 32 00h:00m:00s Idle Up

Address-family : IPv6 Unicast

-----------------------------

Address-family : L2VPN EVPN

-----------------------------

20. Enable the interface to Router-A again.

ICX-Core-1(config)# interface 1/1/7
ICX-Core-1(config-if)# no shutdown

Lab 5: Basic BGP peering

ICX-Core-1(config-if)# exit

21. Wait for the BGP state to change to Established.

ICX-Core-1(config)# show bgp all summary
VRF : default
BGP Summary
-----------
Local AS : 64500 BGP Router Identifier : 10.1.0.2
Peers : 1 Log Neighbor Changes : No
Cfg. Hold Time : 180 Cfg. Keep Alive : 60

Address-family : IPv4 Unicast

-----------------------------
Neighbor Remote-AS MsgRcvd MsgSent Up/Down Time State AdminStatus
10.255.101.11 64511 10 12 00h:03m:30s Established Up

Address-family : IPv6 Unicast

-----------------------------

Address-family : L2VPN EVPN

This demonstrates how BFD can help with a faster detection of the peer reachability.

For eBGP peers, the switch can also monitor if the link used to reach a directly adja-
cent peer goes down and then reset the BGP session immediately.
This can be enabled under the router bgp context using the bgp fast-external-
fallover command.

Task 5-2: Core-1 eBGP peering to ISP1 223

 router bgp <as>
bgp fast-external-fallover

Verify received routes via BGP

22. Now, review the routes that have been received via BGP on Core-1.
ICX-Core-1(config)# show bgp all paths
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed, a additional-paths
VRF : default
Local Router-ID 10.1.0.2

Address-family : IPv4 Unicast

-----------------------------
Network Next Hop PathID Path
*>e 192.0.2.0/24 10.255.101.11 64511 i
*>e 198.19.101.0/24 10.255.101.11 64511 64513 i
*>e 198.19.102.0/24 10.255.101.11 64511 64512 64513 i
*>e 198.51.100.0/24 10.255.101.11 64511 64512 i
Total number of entries 4

Address-family : IPv6 Unicast

-----------------------------
Network Next Hop PathID Path
Total number of entries 0

Address-family : L2VPN EVPN

-----------------------------
Network Nexthop Path
---------------------------------------------------------------------------
Total number of entries 0

n Question: Route 192.0.2.0/24 has AS path 64511. What does this mean?
n Answer: Since the neighbor 10.255.101.11 belongs to AS 64511, this means that route
192.0.2.0/24 is originated by this neighbor AS.
n Question: Which AS originates the route 198.19.102.0/24?
n Answer: The last AS in the AS path indicates the originating AS, so this route is originated
by AS 64513; it traverses AS 64512 and then AS 64511.
n Question: Both 198.19.101.0/24 and 198.19.102.0/24 originate from AS 64513. Why are
they using a different path (different AS path)?
n Answer: BGP allows the administrator to control the routing paths. In this case, appar-
ently, some route policy was defined on Routers A, B, or C so that 198.19.101.0/24 and
198.19.102.0/24 are taking a different path to reach their destination. You only see the
result of that policy here.

224 Task 5-2: Core-1 eBGP peering to ISP1

Task 5-3: Core-1 and Core-2 iBGP peering
Objectives
In this task, iBGP peering will be configured between the Core-1 and the Core-2 devices. The VSX syn-
chronization for BGP will be reviewed and disabled, so each core switch can have its own BGP con-
figuration. With the iBGP peering in place between the two core switches, the BGP routes and the next-
hop will be analyzed. This will result in the configuration of the next-hop self for the iBGP peers.

Steps
Set up iBGP peering between Core-1 and Core-2
Core-1
1. On Core-1, add a new neighbor for Core-2. Use the same AS, so BGP knows this is iBGP.
ICX-Core-1(config)# router bgp 64500
ICX-Core-1(config-bgp)# neighbor 10.1.0.3 remote-as 64500

2. For iBGP, the peering is typically configured between the loopback IP addresses of the routers
instead of the outgoing interface IP address. Configure the loopback IP address as the source IP

Lab 5: Basic BGP peering

for this neighbor.
ICX-Core-1(config-bgp)# neighbor 10.1.0.3 update-source loopback 0

3. Enable the neighbor for IPv4 unicast.

ICX-Core-1(config-bgp)# address-family ipv4 unicast
ICX-Core-1(config-bgp-ipv4-uc)# neighbor 10.1.0.3 activate
ICX-Core-1(config-bgp-ipv4-uc)# exit
ICX-Core-1(config-bgp)# exit

Core-2
4. Switch to Core-2, enter the configuration mode if needed, review the current configuration, and
look for the BGP section.
ICX-Core-2(config)# show run bgp
router bgp 64500
neighbor 10.1.0.3 remote-as 64500
neighbor 10.255.101.11 remote-as 64511
neighbor 10.255.101.11 fall-over bfd
address-family ipv4 unicast
neighbor 10.1.0.3 activate
neighbor 10.255.101.11 activate
exit-address-family
!

Task 5-3: Core-1 and Core-2 iBGP peering 225

 n Question: Why is there already a BGP configuration on Core-2?
n Answer: Since Core-1 and Core-2 are in a VSX cluster and all the VSX synchronization fea-
tures had been turned on, the BGP commands are automatically replicated.
This is very useful in case the VSX cluster is in a datacenter and needs to have the same neigh-
bor peering commands on both core switches. In this lab environment, the BGP configuration of
both Core-1 and Core-2 will be unique, so the VSX synchronization will be disabled.

In case only minor differences are needed, it is possible to exclude the neighbor con-
figuration synchronization at the neighbor level in the BGP configuration. An
example would be:
example(config)# router bgp 64500
example(config-bgp)# neighbor 10.1.1.1 vsx-sync-exclude

You do not need to apply this command in the lab because the entire BGP syn-
chronization will be disabled.

Core-1
5. On Core-1, disable the VSX synchronization of the BGP feature.
ICX-Core-1(config)# vsx
ICX-Core-1(config-vsx)# no vsx-sync bgp
ICX-Core-1(config-vsx)# exit

Core-2
6. On Core-2, verify the BGP configuration.
ICX-Core-2(config)# show run bgp
router bgp 64500
neighbor 10.1.0.3 remote-as 64500
neighbor 10.255.101.11 remote-as 64511
neighbor 10.255.101.11 fall-over bfd
address-family ipv4 unicast
neighbor 10.1.0.3 activate
neighbor 10.255.101.11 activate
exit-address-family
n Question: Is the BGP configuration still in the running configuration?
n Answer: Yes, it is still there. Only the VSX synchronization was stopped. Now the admin-
istrator can make local changes to Core-2.
7. To clean up, remove the BGP configuration.
ICX-Core-2(config)# no router bgp 64500
This will delete all BGP configurations on this device.
Continue (y/n)? y

226 Task 5-3: Core-1 and Core-2 iBGP peering

 8. Now try to set up the BGP router by yourself: add Core-1 as an iBGP neighbor, use the loopback
IP as the source IP, and verify the peering.
The commands are only listed here in case you want to verify your commands.
ICX-Core-2(config)# router bgp 64500
ICX-Core-2(config-bgp)# neighbor 10.1.0.2 remote-as 64500
ICX-Core-2(config-bgp)# neighbor 10.1.0.2 update-source loopback 0
ICX-Core-2(config-bgp)# address-family ipv4 unicast
ICX-Core-2(config-bgp-ipv4-uc)# neighbor 10.1.0.2 activate
ICX-Core-2(config-bgp-ipv4-uc)# exit-address-family
ICX-Core-2(config-bgp)#

9. The result should be an Established iBGP session.

ICX-Core-2(config-bgp)# show bgp all summary
VRF : default
BGP Summary
-----------
Local AS : 64500 BGP Router Identifier : 10.1.0.3
Peers : 1 Log Neighbor Changes : No
Cfg. Hold Time : 180 Cfg. Keep Alive : 60

Lab 5: Basic BGP peering

Address-family : IPv4 Unicast
-----------------------------
Neighbor Remote-AS MsgRcvd MsgSent Up/Down Time State AdminStatus
10.1.0.2 64500 7 3 00h:00m:37s Established Up

Address-family : IPv6 Unicast

-----------------------------

Address-family : L2VPN EVPN

-----------------------------

Core-2: Verify received BGP routes

10. Now, review the received BGP routes on Core-2.
ICX-Core-2(config-bgp)# show bgp all path
tatus codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed, a additional-paths
VRF : default
Local Router-ID 10.1.0.3

Address-family : IPv4 Unicast

-----------------------------
Network Next Hop PathID Path
* i 192.0.2.0/24 10.255.101.11 64511 i
* i 198.19.101.0/24 10.255.101.11 64511 64513 i
* i 198.19.102.0/24 10.255.101.11 64511 64512 64513 i
* i 198.51.100.0/24 10.255.101.11 64511 64512 i

Task 5-3: Core-1 and Core-2 iBGP peering 227

 Total number of entries 4

Address-family : IPv6 Unicast

-----------------------------
Network Next Hop PathID Path
Total number of entries 0

Address-family : L2VPN EVPN

-----------------------------
Network Nexthop Path
---------------------------------------------------------------------------------
Total number of entries 0
n Question: Do you notice a difference in the flags compared to the output on Core-1?
n Answer: There is no best route on Core-2, so the ">" flag is missing at the beginning of
each route entry. In the following steps, this will be investigated.
11. Review the IP routing table on Core-2. Is there a route to the 198.19.101.0/24 network?
ICX-Core-2(config-bgp)# show ip route 198.19.101.0

No ipv4 routes configured

n Question: What would be the reason that this route that is visible in the BGP routing table
is not inserted into the IP routing table?
n Answer: BGP always checks if the next-hop IP address of a route is reachable. In this case,
Core-1 announces the external next-hop IP address of 10.255.101.11. This IP address is
not reachable for Core-2; therefore, it cannot inject these routes into the IP routing table.
12. Determine if the 10.255.101.11 route is in Core-2's routing table.
ICX-Core-2(config-bgp)# show ip route 10.255.101.11

No ipv4 routes configured

Solution: iBGP next-hop-self

The behavior seen in the previous section occurs because, by default, iBGP keeps the next hop of
the eBGP peer. In many cases, this is not desired, so the internal iBGP IP should be used as the
next hop for the announced IP routes. This will now be configured on both Core-1 and on Core-2
on the neighbor definitions to each other.
Core-1
13. Open Core-1, enter the IPv4 address-family under the BGP router context, and enable the next-
hop-self parameter for the Core-2 neighbor.
ICX-Core-1(config)# router bgp 64500
ICX-Core-1(config-bgp)# address-family ipv4 unicast
ICX-Core-1(config-bgp-ipv4-uc)# neighbor 10.1.0.3 next-hop-self
ICX-Core-1(config-bgp-ipv4-uc)# exit

228 Task 5-3: Core-1 and Core-2 iBGP peering

 14. Review the configuration.
ICX-Core-1(config-bgp)# show running-config current-context
router bgp 64500
neighbor 10.1.0.3 remote-as 64500
neighbor 10.1.0.3 update-source loopback 0
neighbor 10.255.101.11 remote-as 64511
neighbor 10.255.101.11 fall-over bfd
address-family ipv4 unicast
neighbor 10.1.0.3 activate
neighbor 10.1.0.3 next-hop-self
neighbor 10.255.101.11 activate
exit-address-family

Core-2
15. On Core-2, repeat this for the neighbor Core-1.
ICX-Core-2(config-bgp)# address-family ipv4 unicast
ICX-Core-2(config-bgp-ipv4-uc)# neighbor 10.1.0.2 next-hop-self
ICX-Core-2(config-bgp-ipv4-uc)# exit
ICX-Core-2(config-bgp)# exit

Lab 5: Basic BGP peering

16. On Core-2, review the BGP routing table, checking the next-hop IP for the routes.
ICX-Core-2(config-bgp)# show bgp all path
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed
VRF : default
Local Router-ID 10.1.0.3

Address-family : IPv4 Unicast

-----------------------------
Network Next Hop PathID Path
* i 192.0.2.0/24 10.255.101.11 64511 i
* i 198.19.101.0/24 10.255.101.11 64511 64513 i
* i 198.19.102.0/24 10.255.101.11 64511 64512 64513 i
* i 198.51.100.0/24 10.255.101.11 64511 64512 i
Total number of entries 4
<output omitted>
n Question: Did the next hop change for the routes?
n Answer: No. This change is only effective for the next update, so the session must be
refreshed for these changes to be visible.
17. On Core-2, clear the BGP session with Core-1.
ICX-Core-2(config)# clear bgp 10.1.0.2

18. Review the BGP routing table; the next hop should now be the loopback IP of Core-1. Also notice
that the > best flag is now shown again for the routes.

Task 5-3: Core-1 and Core-2 iBGP peering 229

 ICX-Core-2(config)# show bgp all path
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed
VRF : default
Local Router-ID 10.1.0.3

Address-family : IPv4 Unicast

-----------------------------
Network Next Hop PathID Path
*>i 192.0.2.0/24 10.1.0.2 64511 i
*>i 198.19.101.0/24 10.1.0.2 64511 64513 i
*>i 198.19.102.0/24 10.1.0.2 64511 64512 64513 i
*>i 198.51.100.0/24 10.1.0.2 64511 64512 i
Total number of entries 4
<output omitted>

19. Review the IP routing table. Are the routes visible now?
ICX-Core-2(config)# show ip route 198.19.101.0

VRF: default

Prefix : 198.19.101.0/24 VRF(egress) : -

Nexthop : 10.1.2.2 Interface : vlan2
Origin : bgp Type : bgp_int
Distance : 200 Metric : 0
Age : 00h:02m:04s Tag : 0
Encap Type : - Encap Details : -

This demonstrates the need for next-hop-self between iBGP peers.

Do not attempt to ping the remote hosts. Core-1 and Core-2 are receiving the routes
from the ISP, but they are not announcing any routes themselves, so there is no
return path to make a connection possible (at least at this point in the lab). You will
fix this later in the lab.

Task 5-4: Core-2 eBGP peering to ISP2

Objectives
In this task, Core-2 will be configured with an eBGP peering session to Router-B (another ISP). Once the
peering is established, the routes will be reviewed. This will also reveal that the customer now has
become a transit AS, so traffic between Router-A and Router-B could be using the path via the cus-
tomer network. A solution using a route map will be configured to prevent this transit AS behavior.

230 Task 5-4: Core-2 eBGP peering to ISP2

Steps
Core-2
1. On Core-2, configure the routed uplink to Router-B.
ICX-Core-2(config)# interface 1/1/7
ICX-Core-2(config-if)# ip address 10.255.102.3/24
ICX-Core-2(config-if)# no shutdown
ICX-Core-2(config-if)# exit

2. Verify Core-2 can reach Router-B on the new link.

ICX-Core-2(config)# ping 10.255.102.12
PING 10.255.102.12 (10.255.102.12) 100(128) bytes of data.
108 bytes from 10.255.102.12: icmp_seq=1 ttl=64 time=1.43 ms
108 bytes from 10.255.102.12: icmp_seq=2 ttl=64 time=1.23 ms
<output omitted>

If Router-B is not reachable, check the interface configuration again. If the con-
figuration is correct, contact your instructor.

Lab 5: Basic BGP peering

3. On Core-2, attempt to configure Router-B (10.255.102.12) as a BGP neighbor for AS 64512 by
yourself. Only use the commands below in case you want to verify your commands.
ICX-Core-2(config)# bfd
ICX-Core-2(config)# router bgp 64500
ICX-Core-2(config-bgp)# neighbor 10.255.102.12 remote-as 64512
ICX-Core-2(config-bgp)# neighbor 10.255.102.12 fall-over bfd
ICX-Core-2(config-bgp)# address-family ipv4 unicast
ICX-Core-2(config-bgp-ipv4-uc)# neighbor 10.255.102.12 activate
ICX-Core-2(config-bgp-ipv4-uc)# exit

Core-2: Verify the received routes from the eBGP peer

4. On Core-2, verify the status of the eBGP peering. The state with 10.255.102.12 should be Estab-
lished.
ICX-Core-2(config-bgp)# show bgp all summary
VRF : default
BGP Summary
-----------
Local AS : 64500 BGP Router Identifier : 10.1.0.3
Peers : 2 Log Neighbor Changes : No
Cfg. Hold Time : 180 Cfg. Keep Alive : 60

Address-family : IPv4 Unicast

-----------------------------
Neighbor Remote-AS MsgRcvd MsgSent Up/Down Time State AdminStatus
10.1.0.2 64500 30 27 00h:19m:53s Established Up

Task 5-4: Core-2 eBGP peering to ISP2 231

 10.255.102.12 64512 16 18 00h:00m:30s Established Up
<output omitted>

5. Review that routes have been received from this eBGP peer.
ICX-Core-2(config-bgp)# show bgp all paths
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed, a additional-paths
VRF : default
Local Router-ID 10.1.0.3

Address-family : IPv4 Unicast

-----------------------------
Network Next Hop PathID Path
*>i 192.0.2.0/24 10.1.0.2 64511 i
* e 192.0.2.0/24 10.255.102.12 64512 64511 i
*>i 198.19.101.0/24 10.1.0.2 64511 64513 i
* e 198.19.101.0/24 10.255.102.12 64512 64511 64513 i
*>e 198.19.102.0/24 10.255.102.12 64512 64513 i
*>e 198.51.100.0/24 10.255.102.12 64512 i
Total number of entries 6
<output omitted>

Transit AS problem: Verify the routes that are advertised to the eBGP peer
By default, BGP will advertise all routes that it has received from other BGP peers. The risk for a
customer with BGP peering to two different ISPs is that it becomes a transit AS between these
ISPs. It is best practice to apply a route filter to the eBGP peers to ensure that only locally ori-
ginated routes can be announced to them.
Core-2
6. First, review that Core-2 is indeed advertising routes to Router-B. On Core-2, no configuration
has been performed to announce routes to the eBGP system. Check if any routes are being
advertised to the eBGP peer.
ICX-Core-2(config-bgp)# show bgp ipv4 unicast neighbors 10.255.102.12 advertised-
routes
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

VRF : default
Local Router-ID 10.1.0.3

Network Nexthop Metric LocPrf Weight Path

*>e 192.0.2.0/24 10.255.102.3 0 0 0 64500 64511 i
*>e 198.19.101.0/24 10.255.102.3 0 0 0 64500 64511 64513 i
Total number of entries 2

232 Task 5-4: Core-2 eBGP peering to ISP2

 This shows that the two routes that were received by Router-A (via Core-1) are being advertised
by Core-2 to Router-B.
Core-1
7. On Core-1, the issue can also be verified. It is currently advertising routes that it received via
Core-2 from Router-B.
ICX-Core-1(config-bgp)# show bgp ipv4 unicast neighbors 10.255.101.11 advertised-
routes
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

VRF : default
Local Router-ID 10.1.0.2

Network Nexthop Metric LocPrf Weight Path

*>e 198.19.102.0/24 10.255.101.2 0 0 0 64500 64512 64513 i
*>e 198.51.100.0/24 10.255.101.2 0 0 0 64500 64512 i
Total number of entries 2

Lab 5: Basic BGP peering

Solution: Route policy for locally originated networks
In the next section, a route policy will be created to ensure that only routes that have originated
in the local AS can be advertised to the eBGP peers. This will be achieved by checking the AS
path attribute. All the routes that originate inside this AS will have an empty AS path attribute,
while any route that was received via an external AS (eBGP) will have at least the value of that
external AS in the AS path.
To match on the AS path of a route, a regular expression can be used. See
https://www.regex101.com for regular expression examples.
These regex values are used:
n ^: indicates 'must begin with'
n $: indicates 'must end with'
Combined, they result in "^$", which represents an empty or null string (in other words, an AS
path that contains no AS numbers).
Since the outbound route filter will be used by both Core-1 and Core-2, the configuration will be
performed on Core-1, so the route map will by synchronized by VSX (route-map is a separate
synchronization feature of VSX).
8. On Core-1, define a new AS path list that only allows an "empty" AS path value.
ICX-Core-1(config)# ip aspath-list bgp-local permit ^$

Task 5-4: Core-2 eBGP peering to ISP2 233

 In the remote lab console web interface, it may be required to enter the up caret (^)
and press the Space key to see the character.

9. Define a new route map to select routes matching the new AS path list.
ICX-Core-1(config)# route-map bgp-ebgp-out permit
ICX-Core-1(config-route-map-bgp-ebgp-out-10)# match aspath bgp-local
ICX-Core-1(config-route-map-bgp-ebgp-out-10)# exit
ICX-Core-1(config)#

Note that the outbound policy must be defined on each core switch separately.
Core-1
10. On Core-1, apply the policy to the neighbor definition to Router-A.
ICX-Core-1(config)# router bgp 64500
ICX-Core-1(config-bgp)# address-family ipv4 unicast
ICX-Core-1(config-bgp-ipv4-uc)# neighbor 10.255.101.11 route-map bgp-ebgp-out out
ICX-Core-1(config-bgp-ipv4-uc)# exit

Core-2
11. On Core-2, the AS path list and the route map were synchronized by VSX. Verify that the route
map exists in the configuration.
ICX-Core-2(config-bgp)# show run | include aspath
ip aspath-list bgp-local seq 10 permit ^$
match aspath-list bgp-local

ICX-Core-2(config-bgp)# show route-map

Route-map: bgp-ebgp-out
Seq 10, permit,
Match :
aspath-list : bgp-local
Set :

Route-map: ospf_from_static
Seq 10, permit,
Match :
ip prefix-list : routerAext
Set :
metric : 1000
metric-type : external_type1

12. On Core-2, apply the policy to the neighbor definition to Router B. The switch should still be in
the router bgp 64500 context.
ICX-Core-2(config)# router bgp 64500
ICX-Core-2(config-bgp)# address-family ipv4 unicast

234 Task 5-4: Core-2 eBGP peering to ISP2

 ICX-Core-2(config-bgp-ipv4-uc)# neighbor 10.255.102.12 route-map bgp-ebgp-out out
ICX-Core-2(config-bgp-ipv4-uc)# exit

The update in the policy will be effective after the BGP sessions are restarted.
Core-1
13. Reset the eBGP session on Core-1.
ICX-Core-1(config-bgp)# clear bgp 10.255.101.11

Core-2
14. Reset the eBGP session on Core-2. Alternatively, you could use the clear bgp all * soft in
command.
ICX-Core-2(config-bgp)# clear bgp 10.255.102.12

Core-1
15. Wait a few moments so the eBGP session can be re-established. Now the route policy should be
effective. On Core-1, check the outbound routes.
ICX-Core-1(config-bgp)# show bgp ipv4 unicast neighbors 10.255.101.11 advertised-
routes

Lab 5: Basic BGP peering

Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

VRF : default
Local Router-ID 10.1.0.2

Network Nexthop Metric LocPrf Weight Path

Total number of entries 0

ICX-Core-1(config-bgp)# exit

Core-2
16. Verify this on Core-2 as well.
ICX-Core-2(config-bgp)# show bgp ipv4 unicast neighbors 10.255.102.12 advertised-
routes

Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,

i internal, e external S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

VRF : default
Local Router-ID 10.1.0.3

Network Nexthop Metric LocPrf Weight Path

Total number of entries 0

Task 5-4: Core-2 eBGP peering to ISP2 235

 ICX-Core-2(config-bgp)# exit

This demonstrates how a route policy can prevent the customer from becoming a transit AS for
other BGP autonomous systems.

Task 5-5: Announce routes to eBGP peers

Objectives
In this task, the customer would like to advertise its local, public subnet to the two ISPs. First, a public
subnet will be defined on the Core-1 and Core-2 switches. Next, Core-1 will be configured to announce
this subnet using eBGP to Router-A (ISP 64511), and the advertisement will be verified that it was
received on Router-C.
The last step will be to repeat this configuration on Core-2, where the route will also be advertised to
Router-B (ISP 64512).

Steps
Define the subnet on Core-1 and Core-2 for external use
The Core-1 and Core-2 BGP AS 64500 will be hosting the 100.100.1.0/24 network. Each core switch
will be configured with a loopback interface in this subnet for testing purposes. This loopback will be
included in the OSPF topology so Core-1 and Core-2 can reach each other's 100.100.1.0/24 interface
and also forward data to the peer switch.
Core-1
1. On Core-1, define the new loopback with the public test IP.
ICX-Core-1(config)# interface loopback 101
ICX-Core-1(config-loopback-if)# ip address 100.100.1.2/32
ICX-Core-1(config-loopback-if)# ip ospf 1 area 0
ICX-Core-1(config-loopback-if)# exit
ICX-Core-1(config)#

Core-2
2. On Core-2, define the new loopback IP as well.
ICX-Core-2(config)# interface loopback 101
ICX-Core-2(config-loopback-if)# ip address 100.100.1.3/32
ICX-Core-2(config-loopback-if)# ip ospf 1 area 0
ICX-Core-2(config-loopback-if)# exit

3. On Core-2, verify the new loopback IP on Core-1 can be reached via OSPF, while using the local
loopback as source IP.
ICX-Core-2(config)# ping 100.100.1.2 source 100.100.1.3
PING 100.100.1.2 (100.100.1.2) from 100.100.1.3 : 100(128) bytes of data.
108 bytes from 100.100.1.2: icmp_seq=1 ttl=64 time=0.197 ms

236 Task 5-5: Announce routes to eBGP peers

 108 bytes from 100.100.1.2: icmp_seq=2 ttl=64 time=0.169 ms
<output omitted>

Core-1 eBGP: Announce local subnet to Router-A

4. In these steps, Core-1 will announce the 100.100.1.0/24 prefix to Router-A. On Core-1, enter the
BGP router context.
ICX-Core-1(config)# router bgp 64500
ICX-Core-1(config-bgp)# address-family ipv4 unicast

5. Use the network command to inject the 100.100.1.0/24 route into the IPv4 BGP table.
ICX-Core-1(config-bgp-ipv4-uc)# network 100.100.1.0/24
ICX-Core-1(config-bgp-ipv4-uc)# exit
ICX-Core-1(config-bgp)# exit

6. Verify if the new network is part of the IPv4 unicast routing table.
ICX-Core-1(config)# show bgp ipv4 unicast paths
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed
VRF : default
Local Router-ID 10.1.0.2

Lab 5: Basic BGP peering

Network Next Hop PathID Path
*>e 192.0.2.0/24 10.255.101.11 64511 i
*>e 198.19.101.0/24 10.255.101.11 64511 64513 i
*>i 198.19.102.0/24 10.1.0.3 64512 64513 i
* e 198.19.102.0/24 10.255.101.11 64511 64512 64513 i
*>i 198.51.100.0/24 10.1.0.3 64512 i
* e 198.51.100.0/24 10.255.101.11 64511 64512 i

Total number of entries 6

n Question: Is the new route visible?
n Answer: No, the new route is not injected yet. BGP requires the route to exist in the local
routing table before it can be announced to BGP peers.
Since the local routing table only contains the /32 loopback routes, but not the /24 route, BGP
rejects the route. To solve this, a dummy static route can be created. This should only be done in
case more specific subnets are still available in the routing table, such as the /32 subnets in this
lab.
7. Verify that the 100.100.1.0/24 route is not in the IP routing table. Remember that the loopback
network used a /32 mask, not a /24 mask, and BGP requires an exact match with the network
statement.
ICX-Core-1(config)# show ip route 100.100.1.0

No ipv4 routes configured

8. Define the dummy static route.

Task 5-5: Announce routes to eBGP peers 237

 ICX-Core-1(config)# ip route 100.100.1.0/24 nullroute

9. Next, verify the route appears in the local BGP routing table.
ICX-Core-1(config)# show bgp ipv4 unicast paths
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed
VRF : default
Local Router-ID 10.1.0.2

Network Next Hop PathID Path

*> 100.100.1.0/24 0.0.0.0 i
*>e 192.0.2.0/24 10.255.101.11 64511 i
*>e 198.19.101.0/24 10.255.101.11 64511 64513 i
*>i 198.19.102.0/24 10.1.0.3 64512 64513 i
* e 198.19.102.0/24 10.255.101.11 64511 64512 64513 i
*>i 198.51.100.0/24 10.1.0.3 64512 i
* e 198.51.100.0/24 10.255.101.11 64511 64512 i

Total number of entries 7

10. Verify the route passes the outbound route map to Router-A.
ICX-Core-1(config)# show bgp ipv4 unicast neighbors 10.255.101.11 advertised-routes
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

VRF : default
Local Router-ID 10.1.0.2

Network Nexthop Metric LocPrf Weight Path

*>e 100.100.1.0/24 10.255.101.2 0 0 0 64500 i
Total number of entries 1

11. Verify connectivity using this IP to Router-C (this router is connected behind Router-A and
Router-B). If this router can be reached using a ping, it means Router-C knows about the
100.100.1.0/24 subnet as well. Router-C has several loopback test IP addresses; one of them is
198.19.101.50.
ICX-Core-1(config)# ping 198.19.101.50 source 100.100.1.2
PING 198.19.101.50 (198.19.101.50) from 100.100.1.2 : 100(128) bytes of data.
108 bytes from 198.19.101.50: icmp_seq=1 ttl=62 time=3.82 ms
108 bytes from 198.19.101.50: icmp_seq=2 ttl=62 time=3.55 ms
<output omitted>

Core-2
12. On Core-2, verify Router-C (198.19.101.50) can be reached when using the local public IP as the
source IP (100.100.1.3). The reply confirms that all the hosts on the 100.100.1.0/24 subnet can
be reached from the ISPs using a path via Core-1.
ICX-Core-2(config)# ping 198.19.101.50 source 100.100.1.3
PING 198.19.101.50 (198.19.101.50) from 100.100.1.3 : 100(128) bytes of data.

238 Task 5-5: Announce routes to eBGP peers

 108 bytes from 198.19.101.50: icmp_seq=1 ttl=62 time=3.67 ms
108 bytes from 198.19.101.50: icmp_seq=2 ttl=62 time=3.82 ms
<output omitted>

13. Now repeat the configuration of the route advertisement on Core-2.

ICX-Core-2(config)# ip route 100.100.1.0/24 nullroute
ICX-Core-2(config)# router bgp 64500
ICX-Core-2(config-bgp)# address-family ipv4 unicast
ICX-Core-2(config-bgp-ipv4-uc)# network 100.100.1.0/24
ICX-Core-2(config-bgp-ipv4-uc)# exit
ICX-Core-2(config-bgp)# exit

Router-C: Perform route validation

14. Open a connection to Router-C (admin/aruba123).
15. On Router-C, verify that there are now two paths for the 100.100.1.0/24 subnet.
ICX-RouterC-bgp# show bgp ipv4 unicast
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, e external S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

Lab 5: Basic BGP peering

VRF : default
Local Router-ID 203.0.113.50

Network Nexthop Metric LocPrf Weight Path

*>e 100.100.1.0/24 10.255.104.11 0 100 0 64511 64500 i
* e 100.100.1.0/24 10.255.105.12 0 100 0 64512 64500 i
*>e 192.0.2.0/24 10.255.104.11 0 100 0 64511 i
* e 192.0.2.0/24 10.255.105.12 0 100 0 64512 64511 i
*> 198.19.101.0/24 0.0.0.0 0 100 0 i
*> 198.19.102.0/24 0.0.0.0 0 100 0 i
* e 198.51.100.0/24 10.255.104.11 0 100 0 64511 64512 i
*>e 198.51.100.0/24 10.255.105.12 0 100 0 64512 i
*> 203.0.113.0/24 0.0.0.0 0 100 0 i
Total number of entries 9
n Question: What is the AS path for each of the routes?
n Answer: There should be one entry with AS path 64511 64500 and another entry with
64512 64500.
n Question: Why is only one route selected as the best path (">")?
n Answer: BGP default path selection will only select one best path when the AS path length
is the same for multiple paths.
16. Review the IP routing table for the 100.100.1.0/24 route. Notice that the next hop is in line with
the BGP routing table shown in the previous step.
ICX-RouterC-bgp# show ip route 100.100.1.0

VRF: default

Task 5-5: Announce routes to eBGP peers 239

 Prefix : 100.100.1.0/24 VRF(egress) : -
Nexthop : 10.255.104.11 Interface : 1/1/1
Origin : bgp Type : bgp_ext
Distance : 20 Metric : 0
Age : 00h:04m:49s Tag : 0
Encap Type : - Encap Details : -

It is not necessary to create a checkpoint for the BGP configuration since this will not
be used in later labs.

You have completed Lab 5!

240 Task 5-5: Announce routes to eBGP peers

Lab 6: Additional Layer 3 features

Lab 6: Additional Layer 3 features

Lab diagram

Overview
In this lab activity, you will begin by exploring the VRF feature. A new routing table will be defined on
the VSX core switches: for example, customer blue. After defining a new routing context, the lab will
show how L3 interfaces can be attached to a VRF; this will be done with loopback and VLAN interfaces.
The lab will then show how a static route can be defined within the VRF context, how user subnets in
the VRF can be configured, and how a DHCP helper can be enabled. The last section will show how a
routing protocol, such as OSPF, can be enabled and bound to a VRF context.
The last two tasks will have you explore two security features in AOS-CX: DHCP snooping and ARP pro-
tection.

Objectives
n Create a new VRF.
n Associate L3 interfaces to a VRF.
n Define static routing for a VRF.
n Configure OSPF for a VRF context.

Lab 6: Additional Layer 3 features 241

 n Implement DHCP snooping.
n Implement ARP protection.

Task 6-1: Prepare the lab starting configuration

This lab is built on the base VSX topology. Make sure to complete these steps to get the base VSX
checkpoint configuration on the devices.

Steps (required)
1. Open a console connection to the Access-1. Log in using admin and the password aruba123.
ICX-Access-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-1#

2. Open a console connection to the Access-2. Log in using admin and the password aruba123.
ICX-Access-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-2#

3. Open a console connection to the Core-1. Log in using admin and the password aruba123.
ICX-Core-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-1#

4. Open a console connection to the Core-2. Log in using admin and the password aruba123.
ICX-Core-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-2#

242 Task 6-1: Prepare the lab starting configuration

Task 6-2: Add a new routing VRF
Lab diagram

Objectives
In this task, a new VRF (blue) will be defined for a customer. Next, L3 IP interfaces, such as loopback
and VLAN interfaces, will be attached to this VRF. On the VSX core, a routed VLAN with a VSX active
gateway will be defined to the upstream MC that will be operating as the upstream firewall in this
setup. With this routed connection in place, a static route example will be configured.
The next step will be to define a user subnet in the customer VRF (VLAN 23) and verify the PC has
access to the customer resources.

Lab 6: Additional Layer 3 features

Steps
Review existing VRFs
Core-1
1. Open a terminal connection to Core-1 and enter configuration mode.
2. Use the show vrf command to review the currently defined VRFs on the system.
n Question: What are the names of the VRFs shown in this output?
n Answer: default and KA (the keepalive VRF for VSX you created in Lab 2).
n Question: Which VRF is not shown in this output?
n Answer: The VRF mgmt is a default, built-in VRF for the management interface.
3. Review the VRF mgmt and the mgmt interface.
ICX-Core-1(config)# show vrf mgmt
VRF Configuration:

Task 6-2: Add a new routing VRF 243

 ------------------
VRF Name : mgmt
use "show interface mgmt" for mgmt interfaces

ICX-Core-1(config)# show interface mgmt

Address Mode : static
Admin State : up
Mac Address : 90:20:c2:bc:17:01
IPv4 address/subnet-mask : 10.251.1.2/24
Default gateway IPv4 : 10.251.1.254
IPv6 address/prefix :
IPv6 link local address/prefix: fe80::9220:c2ff:febc:1701/64
Default gateway IPv6 :
Primary Nameserver :
Secondary Nameserver :
Tertiary Nameserver :

Create new VRF

4. Define a new VRF named blue.
ICX-Core-1(config)# vrf blue
ICX-Core-1(config-vrf)# exit

5. Define a new loopback interface with ID 20 and assign it an IP address of 10.1.20.2/32.

ICX-Core-1(config)# interface loopback 20
ICX-Core-1(config-loopback-if)# ip address 10.1.20.2/32

6. Use the show vrf command to review the interfaces and the VRF assignment.
ICX-Core-1(config-loopback-if)# show vrf
VRF Configuration:
------------------
VRF Name : default
Interfaces Status
-----------------------------
1/1/3 down
<output omitted>
1/1/56 down
loopback20 up
vlan11 up
vlan12 up

VRF Name : KA
Interfaces Status
-----------------------------
1/1/45 up

VRF Name : blue

Interfaces Status

244 Task 6-2: Add a new routing VRF

 n Question: To which VRF is an L3 IP interface attached by default?
n Answer: The VRF named default, which uses the switch's global routing table.
7. Review the current configuration on the loopback 20 interface.
ICX-Core-1(config-loopback-if)# show run interface loopback 20
interface loopback 20
ip address 10.1.20.2/32
exit

8. Attach the loopback 20 interface to the VRF blue. This will automatically remove the interface
from the default routing table.
ICX-Core-1(config-loopback-if)# vrf attach blue

9. Review the current configuration on the loopback 20 interface again.

ICX-Core-1(config-loopback-if)# show run interface loopback 20
interface loopback 20
vrf attach blue
exit
n Question: What happens to the existing IP configuration when an interface is moved to a
different VRF?
n Answer: The existing L3 IP configuration is removed. This is how the switch prevents the
IP configuration of one customer from accidently being inserted into another customer or
security environment.
10. Assign the IP address again to the loopback 20 interface (use the up arrow to get the previous
commands).
ICX-Core-1(config-loopback-if)# ip address 10.1.20.2/32
ICX-Core-1(config-loopback-if)# exit

Lab 6: Additional Layer 3 features

Review the global routing table versus the VRF blue routing table
11. Review the global routing table using the show ip route command.
ICX-Core-1(config)# show ip route

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

VRF: default

Prefix Nexthop Interface VRF(egress)

Origin/ Distance/ Age
Type Metric
---------------------------------------------------------------------------------
10.1.1.0/24 - vlan1 - C [0/0] -

Task 6-2: Add a new routing VRF 245

 10.1.1.2/32 - vlan1 - L [0/0] -
10.1.11.0/24 - vlan11 - C [0/0] -
10.1.11.2/32 - vlan11 - L [0/0] -
10.1.12.0/24 - vlan12 - C [0/0] -
10.1.12.2/32 - vlan12 - L [0/0] -
10.254.1.0/24 10.255.101.11 1/1/7 - S [1/0]
01d:00h:41m
10.255.101.0/24 - 1/1/7 - C [0/0] -
10.255.101.2/32 - 1/1/7 - L [0/0] -

Total Route Count : 9

n Question: Is the 10.1.20.2/32 route available in the global routing table?
n Answer: No, a VRF provides complete L3 routing isolation from other VRFs.
12. Review the VRF blue routing table using the show ip route vrf blue command. Notice that
none of the routes of the default routing table are available here.
ICX-Core-1(config)# show ip route vrf blue

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

VRF: blue

Prefix Nexthop Interface VRF(egress)

Origin/ Distance/ Age
Type Metric
---------------------------------------------------------------------------------
10.1.20.2/32 - loopback20 - L [0/0] -

Configure a VLAN in the VRF blue

In the next steps, a VLAN will be defined to make a routed connection to an upstream firewall. In
this lab environment, the gateway (MC) has the role of the upstream firewall. It will also operate
as the DHCP server for hosts in the VRF blue.

Define a new VLAN for the upstream routed connection to the gateway (MC)
The VSX core already has a VSX LAG (LAG 5) to the gateway, so only an extra VLAN and VLAN
interface is required for this communication. This will be the routed connection between the VSX
core and the gateway. VLAN 23 will be used for this purpose.
Core-1
13. Define VLAN 23 and use the vsx-sync command to have it created on Core-2 as well.

246 Task 6-2: Add a new routing VRF

 ICX-Core-1(config)# vlan 23
ICX-Core-1(config-vlan-23)# vsx-sync
ICX-Core-1(config-vlan-23)# exit

14. Configure the L3 interface and configure the IP settings for the new VLAN.
ICX-Core-1(config)# interface vlan23
ICX-Core-1(config-if-vlan)# vsx-sync active-gateways
ICX-Core-1(config-if-vlan)# vrf attach blue
ICX-Core-1(config-if-vlan)# ip address 10.1.23.2/24
ICX-Core-1(config-if-vlan)# active-gateway ip mac 02:02:00:00:01:00
ICX-Core-1(config-if-vlan)# active-gateway ip 10.1.23.1
ICX-Core-1(config-if-vlan)# exit

Configure Core-2 to support the VRF blue

The previous steps were only executed on Core-1. In the next steps, Core-2 will be configured to
support the VRF blue as well.
Core-2
15. Open a terminal connection to Core-2 and enter configuration mode.
16. Define the VRF blue and the loopback 20 interface.
ICX-Core-2(config)# vrf blue
ICX-Core-2(config-vrf)# exit
ICX-Core-2(config)# interface loopback 20
ICX-Core-2(config-loopback-if)# vrf attach blue
ICX-Core-2(config-loopback-if)# ip address 10.1.20.3/32
ICX-Core-2(config-loopback-if)# exit

17. Define the VLAN 23 SVI interface and verify the VSX active gateway configuration was syn-
chronized.

Lab 6: Additional Layer 3 features

ICX-Core-2(config)# interface vlan23
ICX-Core-2(config-if-vlan)# vrf attach blue
ICX-Core-2(config-if-vlan)# ip address 10.1.23.3/24
ICX-Core-2(config-if-vlan)# show run current
interface vlan23
vsx-sync active-gateways
vrf attach blue
ip address 10.1.23.3/24
active-gateway ip mac 02:02:00:00:01:00
active-gateway ip 10.1.23.1
ICX-Core-2(config-if-vlan)# exit

Core-1
18. On Core-1, verify the connectivity to the upstream gateway in VLAN 23 with a ping from within
the VRF blue context.

Task 6-2: Add a new routing VRF 247

 ICX-Core-1(config)# ping 10.1.23.6 vrf blue
PING 10.1.23.6 (10.1.23.6) 100(128) bytes of data.
108 bytes from 10.1.23.6: icmp_seq=1 ttl=64 time=7.71 ms
108 bytes from 10.1.23.6: icmp_seq=2 ttl=64 time=0.335 ms
<output omitted>

19. Review the ARP table on Core-1.

ICX-Core-1(config)# show arp
n Question: Do you see an ARP entry for the 10.1.23.6 IP address? Why?
n Answer: ARP is also processed per VRF since a VRF may have overlapping IP addresses
with another VRF, so isolation is required.
20. Review the ARP table of the VRF blue. Verify that the 10.1.23.6 address is listed in this ARP
table.
ICX-Core-1(config)# show arp vrf blue
IPv4 Address MAC Port Physical Port State VRF

---------------------------------------------------------------------------------
10.1.23.6 20:4c:03:5f:a0:c2 vlan23 lag5 reachable blue

Total Number Of ARP Entries Listed- 1.

---------------------------------------------------------------------------------
ICX-Core-1(config)#

248 Task 6-2: Add a new routing VRF

 Diagram: Configure a static route in a VRF context

A VRF is just like a regular routing table, so it can be configured with static routes and dynamic
routing protocols. In the next steps, a static route will be added and verified in the blue VRF. The
VSX core currently has a direct link to the gateway in VLAN 23. On the gateway, there is an addi-
tional IP subnet 10.1.24.0/24, where the gateway has an IP address of 10.1.24.6. Currently, the
VSX core switches cannot reach the 10.1.24.0/24 subnet (no routing to it in the blue VRF). By
adding a static route to this subnet on the core switches, they will be able to reach 10.1.24.6 in

Lab 6: Additional Layer 3 features

the blue VRF.
Core-1
21. On Core-1, review the current routing table of the VRF blue.
ICX-Core-1(config)# show ip route vrf blue

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

VRF: blue

Prefix Nexthop Interface VRF(egress)

Origin/ Distance/ Age
Type Metric
---------------------------------------------------------------------------------
10.1.20.2/32 - loopback20 - L [0/0] -

Task 6-2: Add a new routing VRF 249

 10.1.23.0/24 - vlan23 - C [0/0] -
10.1.23.2/32 - vlan23 - L [0/0] -

Total Route Count : 3

22. Add a static route for the 10.1.24.0/24 subnet to the gateway's IP address for the blue VRF.
ICX-Core-1(config)# ip route 10.1.24.0/24 10.1.23.6 vrf blue

23. Verify the routing table again.

ICX-Core-1(config)# show ip route vrf blue

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

VRF: blue

Prefix Nexthop Interface VRF(egress)

Origin/ Distance/ Age
Type Metric
---------------------------------------------------------------------------------
10.1.20.2/32 - loopback20 - L [0/0] -
10.1.23.0/24 - vlan23 - C [0/0] -
10.1.23.2/32 - vlan23 - L [0/0] -
10.1.24.0/24 10.1.23.6 vlan23 - S [1/0] 00h:00m:07s
Total Route Count : 3

Core-2
24. On Core-2, add the static route as well.
ICX-Core-2(config)# ip route 10.1.24.0/24 10.1.23.6 vrf blue

It is also possible to enable the vsx-sync static-routes command under the VSX
context on Core-1 (the VSX primary). In this situation, the VSX synchronization
would create the static route on Core-2.

25. Verify that the routing table in the VRF blue now lists a route to the 10.1.24.0 subnet.
ICX-Core-2(config)# show ip route 10.1.24.0 vrf blue

VRF: blue

Prefix : 10.1.24.0/24 VRF(egress) : -

Nexthop : 10.1.23.6 Interface : vlan23
Origin : static Type : -
Distance : 1 Metric : 0
Age : 00h:00m:34s Tag : 0
Encap Type : - Encap Details : -

250 Task 6-2: Add a new routing VRF

 Test the static route
The gateway has been pre-configured in the lab with an IP address of 10.1.24.6. Attempting to
ping this IP address should succeed from both Core-1 and Core-2.
Core-1
26. Verify the ping to 10.1.24.6 on Core-1.
ICX-Core-1(config)# ping 10.1.24.6 vrf blue
PING 10.1.24.6 (10.1.24.6) 100(128) bytes of data.
108 bytes from 10.1.24.6: icmp_seq=1 ttl=64 time=0.468 ms
108 bytes from 10.1.24.6: icmp_seq=2 ttl=64 time=0.373 ms
<output omitted>

Core-2
27. Verify the ping to 10.1.24.6 on Core-2.
ICX-Core-2(config)# ping 10.1.24.6 vrf blue
PING 10.1.24.6 (10.1.24.6) 100(128) bytes of data.
108 bytes from 10.1.24.6: icmp_seq=1 ttl=64 time=0.468 ms
108 bytes from 10.1.24.6: icmp_seq=2 ttl=64 time=0.373 ms

This demonstrates how a static route can be defined within a VRF context to implement routing.

Diagram: Configure user subnet in the VRF blue

Lab 6: Additional Layer 3 features

In these steps, a new user VLAN will be defined in the VRF blue for PC3 connected to Access-1.
The VSX core will be the default gateway for this subnet in the blue VRF; therefore, the active
gateway and DHCP relay features will be configured. The new user VLAN is VLAN 21.
Core-1
28. On Core-1, create the new VLAN.

Task 6-2: Add a new routing VRF 251

 ICX-Core-1(config)# vlan 21
ICX-Core-1(config-vlan-21)# vsx-sync
ICX-Core-1(config-vlan-21)# exit

29. Define the IP configuration for SVI 21.

ICX-Core-1(config)# interface vlan21
ICX-Core-1(config-if-vlan)# vrf attach blue
ICX-Core-1(config-if-vlan)# ip address 10.1.21.2/24
ICX-Core-1(config-if-vlan)# vsx-sync active-gateways
ICX-Core-1(config-if-vlan)# active-gateway ip mac 02:02:00:00:01:00
ICX-Core-1(config-if-vlan)# active-gateway ip 10.1.21.1

30. Configure a DHCP relay on the VLAN, using the gateway as the DHCP server.
ICX-Core-1(config-if-vlan)# ip helper-address 10.1.23.6
ICX-Core-1(config-if-vlan)# exit

31. Allow VLAN 21 on LAG 1 connected to Access-1 and verify the configuration.
ICX-Core-1(config)# interface lag 1
ICX-Core-1(config-lag-if)# vlan trunk allowed 21
ICX-Core-1(config-lag-if)# show run current
interface lag 1 multi-chassis
no shutdown
description Access-1
no routing
vlan trunk native 1
vlan trunk allowed 1,11-13,21
lacp mode active
ICX-Core-1(config-lag-if)# exit
ICX-Core-1(config)#

Core-2
On Core-2, several settings have already been synchronized by VSX:
n L2 VLAN
n L2 LAG allowed VLAN list
n L3 VLAN active gateway settings
n L3 IP helper
The only remaining configuration steps are:
n Define the L3 interface
n Attach it to VRF
n Assign the interface an IP address
32. Define the L3 interface, attach it to the VRF blue, and set the IP address.

252 Task 6-2: Add a new routing VRF

 ICX-Core-2(config)# interface vlan 21
ICX-Core-2(config-if-vlan)# vrf attach blue
ICX-Core-2(config-if-vlan)# ip address 10.1.21.3/24

33. Verify the VSX active gateway settings have been synchronized correctly.
ICX-Core-2(config-if-vlan)# show running-config current-context
interface vlan21
vsx-sync active-gateways
vrf attach blue
ip address 10.1.21.3/24
active-gateway ip mac 02:02:00:00:01:00 active-gateway ip 10.1.21.1 ip
helper-address 10.1.23.6
ICX-Core-2(config-if-vlan)# exit

34. Verify VLAN 21 exists and is allowed on LAG 1 (to Access-1).

ICX-Core-2(config)# show vlan 21

---------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
---------------------------------------------------------------------------------
21 VLAN21 up ok static lag1,lag5,lag256

Access-1
35. Open a terminal connection on Access-1 and enter configuration mode.
36. Define VLAN 21 and verify it is allowed on the uplink.
ICX-TxAccess-1(config)# vlan 21
ICX-TxAccess-1(config-vlan-21)# exit
ICX-TxAccess-1(config)# show vlan 21

Lab 6: Additional Layer 3 features

---------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
---------------------------------------------------------------------------------
21 VLAN21 up ok static lag255

37. Assign the port connected to PC3 (1/1/3) as an access port in VLAN 21.
ICX-TxAccess-1(config)# int 1/1/3
ICX-TxAccess-1(config-if)# vlan access 21
ICX-TxAccess-1(config-if)# exit

38. On PC3, connected to Access-1 port 1/1/3, reset (disable/enable) the Lab NIC interface, and
verify the IP address received IP addressing information. This should be in the 10.1.21.0/24
range.
C:\Users\student> ipconfig

Windows IP Configuration

Task 6-2: Add a new routing VRF 253

 Ethernet adapter Do NOT Touch!:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 172.16.54.63
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter OOBM:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.251.13.90
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.251.13.254

Ethernet adapter Lab NIC - 6300-A Port 3:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.21.51
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.21.1

39. On PC3, ping and traceroute to 10.1.24.6 (the MC) to test the routing and the static route.
C:\Users\student> ping 10.1.24.6

Pinging 10.1.24.6 with 32 bytes of data:

Reply from 10.1.24.6: bytes=32 time<1ms TTL=63
Reply from 10.1.24.6: bytes=32 time<1ms TTL=63
<output omitted>

C:\Users\student> tracert -d 10.1.24.6

Tracing route to 10.1.24.6 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 10.1.21.3 2 <1 ms <1 ms <1 ms 10.1.24.6

Trace complete.

The PC3 traffic can be hashed to either Core-1 or Core-2, so the first response in the
traceroute could come from either Core-1 (10.1.21.2) or Core-2 (10.1.21.3).

40. Close the command prompt using the exit command.

This demonstrates how customer devices and subnets can be configured in an isolated routing context.

254 Task 6-2: Add a new routing VRF

Task 6-3: OSPF routing inside a VRF
Lab diagram

Objectives
In this task, OSPF routing will be configured inside the blue VRF. The only main difference will be to
bind the OSPF process to the VRF. The other steps, such as the configuration of the router ID, areas,
and interfaces, are the same as configuring OSPF for the default routing table (default VRF).

Lab 6: Additional Layer 3 features

Steps
Core-1
1. On Core-1, define a new OSPF process for VRF blue. Typically, the OSPF process ID used would
be 1 for OSPF in the default routing table; therefore, an OSPF process ID of 2 is used for the blue
VRF.

Without the vrf blue command option, the OSPF process would operate in the
default routing table.

ICX-Core-1(config)# router ospf 2 vrf blue

2. Configure the loopback IP that was defined in the VRF blue as the router ID.
ICX-Core-1(config-ospf-2)# router-id 10.1.20.2

3. Define OSPF area 0 in this new process.

Task 6-3: OSPF routing inside a VRF 255

 ICX-Core-1(config-ospf-2)# area 0
ICX-Core-1(config-ospf-2)# exit

4. Enable OSPF on the loopback 20 and upstream routed VLAN 23 interfaces. Notice that the ip
ospf command requires the OSPF process number. Typically, that would be 1 for the OSPF pro-
cess that is running in the global routing table. In this example, OSPF process ID 2 was bound to
the blue VRF. This is how the administrator can control which OSPF process the interface is asso-
ciated with.

This is different from the VRF attach command, since a single routing table (VRF)
may contain multiple OSPF processes!

ICX-Core-1(config)# interface loopback 20

ICX-Core-1(config-loopback-if)# ip ospf 2 area 0
ICX-Core-1(config-loopback-if)# exit

ICX-Core-1(config)# interface vlan 23

ICX-Core-1(config-if-vlan)# ip ospf 2 area 0
ICX-Core-1(config-if-vlan)# exit

Core-1: Verify the OSPF operation

5. Review the OSPF settings.
ICX-Core-1(config)# show ip ospf
OSPF Process is not running on VRF default.
n Question: Why is there no information shown about OSPF?
n Answer: The default show ip ospf command will look for an OSPF process that is bound
to the default VRF, but there is no OSPF in the default routing context.
6. Repeat the command, but use the vrf parameter option; now, the expected OSPF status should
be displayed.
ICX-Core-1(config)# show ip ospf vrf blue
VRF : blue Process : 2
----------------------------------------------------

RouterID : 10.1.20.2 OSPFv2 : Enabled

BFD : Disabled SPF Start Interval : 200 ms
SPF Hold Interval : 1000 ms SPF Max Wait Interval : 5000 ms
LSA Start Time : 5000 ms LSA Hold Time : 0 ms
LSA Max Wait Time : 0 ms LSA Arrival : 1000 ms
External LSAs : 0 Checksum Sum : 0
ECMP : 4 Reference Bandwidth : 100000 Mbps
Area Border : false AS Border : false
GR Status : Enabled GR Interval : 120 sec
GR State : inactive GR Exit Status : none

256 Task 6-3: OSPF routing inside a VRF

 GR Helper : Enabled GR Strict LSA Check : Enabled
GR Ignore Lost I/F : Disabled
Summary address:

Area Total Active

------------------------------
Normal 1 1
Stub 0 0
NSSA 0 0

Area : 0.0.0.0
----------------
Area Type : Normal Status : Active
Total Interfaces : 2 Active Interfaces : 2
Passive Interfaces : 0 Loopback Interfaces : 1
SPF Calculation Count : 6
Area ranges :
Number of LSAs : 3 Checksum Sum : 93633

Core-2
7. On Core-2, VSX synchronization should have completed most of the configuration. Review the
OSPF configuration.
ICX-Core-2(config)# show run ospf
router ospf 2 vrf blue
area 0.0.0.0
interface loopback 20
ip ospf 2 area 0.0.0.0
interface vlan23
ip ospf 2 area 0.0.0.0

Lab 6: Additional Layer 3 features

The only missing configuration command is the router-id command, but an active IP
address would be selected by default.

8. Review the OSPF status and notice the router ID 10.1.20.3 was automatically selected.
ICX-Core-2(config)# show ip ospf vrf blue
VRF : blue Process : 2
----------------------------------------------------

RouterID : 10.1.20.3 OSPFv2 : Enabled

BFD : Disabled SPF Start Interval : 200 ms
SPF Hold Interval : 1000 ms SPF Max Wait Interval : 5000 ms
LSA Start Time : 5000 ms LSA Hold Time : 0 ms
LSA Max Wait Time : 0 ms LSA Arrival : 1000 ms
External LSAs : 0 Checksum Sum : 0
ECMP : 4 Reference Bandwidth : 100000 Mbps
Area Border : false AS Border : false

Task 6-3: OSPF routing inside a VRF 257

 GR Status : Enabled GR Interval : 120 sec
GR State : inactive GR Exit Status : none
GR Helper : Enabled GR Strict LSA Check : Enabled
GR Ignore Lost I/F : Disabled
Summary address:

Area Total Active

------------------------------
Normal 1 1
Stub 0 0
NSSA 0 0

Area : 0.0.0.0
----------------
Area Type : Normal Status : Active
Total Interfaces : 2 Active Interfaces : 2
Passive Interfaces : 0 Loopback Interfaces : 1
SPF Calculation Count : 5
Area ranges :
Number of LSAs : 3 Checksum Sum : 93633

9. Review the OSPF neighbors: this should be Core-1.

ICX-Core-2(config)# show ip ospf neighbors vrf blue
OSPF Process ID 2 VRF blue
===========================

Total Number of Neighbors: 1

Neighbor ID Priority State Nbr Address Interface

-------------------------------------------------------------------------
10.1.20.2 1 FULL/BDR 10.1.23.2 vlan23

10. Review the IP routing table of the VRF blue. This should show an OSPF route to the loopback IP
of the Core-1 switch.
ICX-Core-2(config)# show ip route vrf blue

Displaying ipv4 routes selected for forwarding

Origin Codes: C - connected, S - static, L - local

R - RIP, B - BGP, O - OSPF, D - DHCP
Type Codes: E - External BGP, I - Internal BGP, V - VPN, EV - EVPN
IA - OSPF internal area, E1 - OSPF external type 1
E2 - OSPF external type 2

VRF: blue

Prefix Nexthop Interface VRF(egress) Origin/ Distance/ Age

Type Metric

258 Task 6-3: OSPF routing inside a VRF

 ---------------------------------------------------------------------------------
10.1.20.2/32 10.1.23.2 vlan23 - O [110/100] 00h:02m:57s
10.1.20.3/32 - loopback20 - L [0/0] -
10.1.21.0/24 - vlan21 - C [0/0] -
10.1.21.3/32 - vlan21 - L [0/0] -
10.1.23.0/24 - vlan23 - C [0/0] -
10.1.23.3/32 - vlan23 - L [0/0] -
10.1.24.0/24 10.1.23.6 vlan23 - S [1/0] 00h:20m:50s

11. Attempt to ping this remote loopback IP, using the Core-2 loopback IP as the source. This should
succeed, since Core-1 should also have a route to the Core-2 loopback IP.
ICX-Core-2(config)# ping 10.1.20.2 source 10.1.20.3 vrf blue
PING 10.1.20.2 (10.1.20.2) from 10.1.20.3 : 100(128) bytes of data.
108 bytes from 10.1.20.2: icmp_seq=1 ttl=64 time=0.233 ms
108 bytes from 10.1.20.2: icmp_seq=2 ttl=64 time=0.195 ms
<output omitted>

This demonstrates how OSPF can be configured to operate within a VRF context.

Task 6-4: Implementing DHCP snooping

In this task, you will implement the DHCP snooping feature. You will use the blue VRF that you created
previously in this lab to implement this security feature. You will implement this for VLAN 21. PC3 will
be used as the user device, and the gateway will be the DHCP server.

Lab 6: Additional Layer 3 features

Task 6-4: Implementing DHCP snooping 259

Lab diagram

Objectives
n Implement DHCP snooping.
n Define an authorized DHCP server.
n Verify DHCP snooping.

Steps
Access-1
1. Review the DHCP snooping configuration for the blue VRF.
ICX-Access-1(config)# show dhcpv4-snooping

DHCPv4-Snooping Information

DHCPv4-Snooping : No Verify MAC Address : Yes

Allow Overwrite Binding : No Enabled VLANs :
IP Binding Disabled VLANs :
Static Attributes : No
Client Event Logs : No
Trust VxLAN Tunnels : Yes

Option 82 Configurations

Untrusted Policy : drop Insertion : Yes

260 Task 6-4: Implementing DHCP snooping

 Option 82 Remote-id : mac

External Storage Information

Volume Name : --
File Name : --
Inactive Since : --
Error : --

Flash Storage Information

File Write Delay : --

Active Storage : --

Authorized Server Configurations

VRF Authorized Servers

------------ ------------------

Port Information

Max Static Dynamic

Port Trust Bindings Bindings Bindings
-------- ----- -------- -------- --------

2. Enable DHCP snooping globally and for VLAN 21.

ICX-Access-1(config)# dhcpv4-snooping
ICX-Access-1(config)# vlan 21
ICX-Access-1(config-vlan-21)# dhcpv4-snooping
ICX-Access-1(config-vlan-21)# exit

3. Verify your configuration.

Lab 6: Additional Layer 3 features

ICX-Access-1(config)# show dhcpv4-snooping

DHCPv4-Snooping Information

DHCPv4-Snooping : Yes Verify MAC Address : Yes

Allow Overwrite Binding : No Enabled VLANs : 21
IP Binding Disabled VLANs :
Static Attributes : No
Client Event Logs : No
Trust VxLAN Tunnels : Yes

Option 82 Configurations

Untrusted Policy : drop Insertion : Yes

Option 82 Remote-id : mac

External Storage Information

Volume Name : --

Task 6-4: Implementing DHCP snooping 261

 File Name : --
Inactive Since : --
Error : --

Flash Storage Information

File Write Delay : --

Active Storage : --

Authorized Server Configurations

VRF Authorized Servers

------------ ------------------

Port Information

Max Static Dynamic

Port Trust Bindings Bindings Bindings
-------- ----- -------- -------- --------

PC3
4. On PC3, try to renew your IPv4 address from the DHCP server (ipconfig /renew).

Please wait for the command to complete its action. It may take up to a minute.

C:\Users\student> ipconfig /renew

Windows IP Configuration

An error occurred while renewing interface Lab NIC - 6300-A Port 3 : unable to
contact your DHCP server. Request has timed out.

C:\Users\student>
n Question: Why did the DHCP request fail?
n Answer: It failed because all interfaces are untrusted by default, including LAG 255 on the
Access-1 switch, which is its uplink.
Access-1
5. View the DHCP snooping statistics.
ICX-Access-1(config)# show dhcpv4-snooping statistics

Packet-Type Action Reason Count

----------- ------- ----------------------------- ---------
server forward from trusted port 0
client forward to trusted port 0
server drop received on untrusted port 0
server drop unauthorized server 0

262 Task 6-4: Implementing DHCP snooping

 client drop destination on untrusted port 4
client drop untrusted option 82 field 0
client drop bad DHCP release request 0
client drop failed verify MAC check 0
client drop failed on max-binding limit 0

6. Define the uplink LAG (255) as a trusted port for DHCP snooping.
ICX-Access-1(config)# interface lag 255
ICX-Access-1(config-lag-if)# dhcpv4-snooping trust
ICX-Access-1(config-lag-if)# exit

PC3
7. On PC3, attempt to renew its IP address again (ipconfig /release and ipconfig /renew). This
should now be successful.
C:\Users\student> ipconfig /release

C:\Users\student> ipconfig /renew

Windows IP Configuration

Ethernet adapter Do NOT Touch!:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 172.16.54.63
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter OOBM:

Lab 6: Additional Layer 3 features

Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 10.251.13.90
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.251.13.254

Ethernet adapter Lab NIC - 6300-A Port 3:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.21.51
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.21.1

Access-1
8. Review the statistics on Access-1.
ICX-Access-1(config)# show dhcpv4-snooping statistics

Packet-Type Action Reason Count

Task 6-4: Implementing DHCP snooping 263

 ----------- ------- ----------------------------- ---------
server forward from trusted port 2
client forward to trusted port 7
server drop received on untrusted port 0
server drop unauthorized server 0
client drop destination on untrusted port 4
client drop untrusted option 82 field 0
client drop bad DHCP release request 0
client drop failed verify MAC check 0
client drop failed on max-binding limit 0

9. View the DHCP snooping operation. Notice that there is one dynamic binding for interface 1/1/3.
ICX-Access-1(config)# show dhcpv4-snooping

DHCPv4-Snooping Information

DHCPv4-Snooping : Yes Verify MAC Address : Yes

Allow Overwrite Binding : No Enabled VLANs : 21
IP Binding Disabled VLANs :
Static Attributes : No
Client Event Logs : No
Trust VxLAN Tunnels : Yes

Option 82 Configurations

Untrusted Policy : drop Insertion : Yes

Option 82 Remote-id : mac

External Storage Information

Volume Name : --
File Name : --
Inactive Since : --
Error : --

Flash Storage Information

File Write Delay : --

Active Storage : --

Authorized Server Configurations

VRF Authorized Servers

------------ ------------------

Port Information

Max Static Dynamic

Port Trust Bindings Bindings Bindings

264 Task 6-4: Implementing DHCP snooping

 -------- ----- -------- -------- --------
1/1/3 No 8192 0 1
lag255 Yes 0 0 0

10. Examine the DHCP snooping binding table. Notice the entry for PC3.
ICX-Access-1(config)# show dhcpv4-snooping binding

MacAddress IP VLAN Interface Time-Left

----------------- --------------- ---- --------- -------------------
00:50:56:b1:2c:b8 10.1.21.51 21 1/1/3 42955

11. Optionally, you can configure DHCPv4 snooping authorized servers to validate when the switch
is receiving DHCP server replies not only to trusted ports but from authorized DHCP server
source IP addresses. On Access-1, configure a DHCPv4 snooping authorized server IP address to
an incorrect one (for example, 10.1.23.99).
ICX-Access-1(config)# dhcpv4-snooping authorized-server 10.1.23.99

12. Verify your DHCP snooping configuration.

ICX-Access-1(config)# show dhcpv4-snooping

DHCPv4-Snooping Information

DHCPv4-Snooping : Yes Verify MAC Address : Yes

Allow Overwrite Binding : No Enabled VLANs : 21
IP Binding Disabled VLANs :
Static Attributes : No
Client Event Logs : No
Trust VxLAN Tunnels : Yes

Option 82 Configurations

Lab 6: Additional Layer 3 features

Untrusted Policy : drop Insertion : Yes
Option 82 Remote-id : mac

External Storage Information

Volume Name : --
File Name : --
Inactive Since : --
Error : --

Flash Storage Information

File Write Delay : --

Active Storage : --

Authorized Server Configurations

VRF Authorized Servers

------------ ------------------

Task 6-4: Implementing DHCP snooping 265

 default 10.1.23.99

Port Information

Max Static Dynamic

Port Trust Bindings Bindings Bindings
-------- ----- -------- -------- --------
1/1/3 No 8192 0 1
lag255 Yes 0 0 0
n Question: Notice that authorized server is listed for the default VRF. Is this an issue?
n Answer: No, because the routing separation is occurring on the VSX core switches at
Layer 3 and Access-1 is operating at Layer 2.
PC3
13. On PC3, attempt to renew its IP address. This should fail.

Please wait for the command to complete its action. It may take up to a minute.

C:\Users\student> ipconfig /renew

Windows IP Configuration

An error occurred while renewing interface Lab NIC - 6300-A Port 3 : unable to
contact your DHCP server. Request has timed out.

Access-1
14. Remove the incorrect DHCP authorized server entry and put in the correct one (10.23.1.6).
ICX-Access-1(config)# no dhcpv4-snooping authorized-server 10.1.23.99
ICX-Access-1(config)# dhcpv4-snooping authorized-server 10.1.23.6

15. Verify your DHCP snooping operation.

CX-Access-1(config)# show dhcpv4-snooping
<output omitted>
Authorized Server Configurations

VRF Authorized Servers

------------ ------------------
default 10.1.23.6
<output omitted>

PC3
16. On PC3, attempt to release and renew its IP address. This should now be successful.
C:\Users\student> ipconfig /release

C:\Users\student> ipconfig /renew

266 Task 6-4: Implementing DHCP snooping

 Windows IP Configuration

Ethernet adapter Do NOT Touch!:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 172.16.54.63
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter OOBM:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.251.13.90
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.251.13.254

Ethernet adapter Lab NIC - 6300-A Port 3:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.21.51
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.21.1

This completes the task on the DHCP snooping feature.

Task 6-5: Implementing Dynamic ARP Inspection

To prevent ARP poisoning attacks and Man-in-the-Middle (MITM) attacks, where a rogue device spoofs
an invalid default gateway MAC address, you can configure the AOS-CX switches to perform Dynamic
ARP Inspection (DAI), commonly called ARP protection. This feature is enabled by default.

Lab 6: Additional Layer 3 features

With DAI, you can either statically define the ARP entries, define a port as a trusted port, or have the
switch learn them from the bindings it sees when DHCP snooping is implemented. Typically, uplinks—
like LAG 255 on Access-2—would be defined as trusted DAI ports and DHCP snooping would be used
on the untrusted (edge) ports.
You will implement DAI in VLAN 21 and test it in this task.

Task 6-5: Implementing Dynamic ARP Inspection 267

Lab diagram

Objectives
n Implement DAI.
n Verify the operation of DAI.

Steps
PC1
1. Verify that PC1 has an IP address in VLAN 21.
C:\Users\student> ipconfig

Windows IP Configuration
<output omitted>

Ethernet adapter Lab NIC - 6300-A Port 3:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.21.51

268 Task 6-5: Implementing Dynamic ARP Inspection

 Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.21.1

2. Verify that PC1 can ping its default gateway in VLAN 21.
C:\Users\student> ping 10.1.21.1

Pinging 10.1.21.1 with 32 bytes of data:

Reply from 10.1.21.1: bytes=32 time<1ms TTL=64
Reply from 10.1.21.1: bytes=32 time<1ms TTL=64
<output omitted>

3. View the ARP entry for the VLAN 21 default gateway IP address (Core-1/Core-2).
C:\Users\student> arp -a 10.1.21.1

Interface: 10.1.21.51 --- 0xb

Internet Address Physical Address Type
10.1.21.1 02-02-00-00-01-00 dynamic

Access-1
4. On Access-1, view the DHCP snooping bindings.
ICX-Access-1(config)# show dhcpv4-snooping binding

MacAddress IP VLAN Interface Time-Left

----------------- --------------- ---- --------- -------------------
00:50:56:b1:2c:b8 10.1.21.51 21 1/1/3 4247

5. Enable ARP inspection for VLAN 21.

ICX-Access-1(config)# vlan 21
ICX-Access-1(config-vlan-21)# arp inspection
ICX-Access-1(config-vlan-21)# exit

Lab 6: Additional Layer 3 features

PC3
6. Delete all the ARP entries on PC3. You will need to open a new command prompt and run it as
Administrator.
C:\WINDOWS\system32> arp -d *

7. On PC3, try to ping the default gateway. The ping should fail.
C:\WINDOWS\system32> ping 10.1.21.1

Pinging 10.1.21.1 with 32 bytes of data:

Reply from 10.251.13.254: Destination host unreachable.
Reply from 10.251.13.254: Destination host unreachable.
<output omitted>
n Question: Why did the ping operation fail?
n Answer: By default, when DAI is enabled for a VLAN, all interfaces are untrusted, including
uplinks. Therefore, the ARP replay from the VSX core is being dropped.

Task 6-5: Implementing Dynamic ARP Inspection 269

 Access-1
8. View the DAI interface configurations.
ICX-Access-1(config)# show arp inspect interface

-----------------------------------------------------------------
Interface Trust-State
-----------------------------------------------------------------
1/1/1 Untrusted
1/1/2 Untrusted
1/1/3 Untrusted
<output omitted>
lag255 Untrusted
-----------------------------------------------------------------

9. On Access-1, examine the DAI statistics for VLAN 21.

ICX-Access-1(config)# show arp inspection statistics vlan 21

-----------------------------------------------------------------
VLAN Name Forwarded Dropped
-----------------------------------------------------------------
21 VLAN21 9 23
-----------------------------------------------------------------

10. Define LAG 255 as a trusted DAI interface.

ICX-Access-1(config)# interface lag 255
ICX-Access-1(config-lag-if)# arp inspection trust
ICX-Access-1(config-lag-if)# exit

PC3
11. On PC3, confirm it can ping the default gateway and has a record, now, in its local ARP table.
C:\WINDOWS\system32>ping 10.1.21.1

Pinging 10.1.21.1 with 32 bytes of data:

Reply from 10.1.21.1: bytes=32 time<1ms TTL=64
Reply from 10.1.21.1: bytes=32 time<1ms TTL=64
<output omitted>

12. View the ARP entry for the VLAN 21 default gateway IP address (Core-1/Core-2).
C:\Users\student> arp -a 10.1.21.1

Interface: 10.1.21.51 --- 0xb

Internet Address Physical Address Type
10.1.21.1 02-02-00-00-01-00 dynamic

270 Task 6-5: Implementing Dynamic ARP Inspection

 Access-1
13. With ARP inspection enabled and no records in the DHCPv4 snooping binding database, ARP
inspection will fail to inspect ARP packets and will drop them. On Access-1, disable DHCPv4
snooping on VLAN 21 and review the binding table. The table should be empty.
ICX-Access-1(config)# vlan 21
ICX-Access-1(config-vlan-21)# no dhcpv4-snooping
ICX-Access-1(config-vlan-21)# exit
ICX-Access-1(config)# show dhcpv4-snooping binding

MacAddress IP VLAN Interface Time-Left

----------------- --------------- ---- --------- -------------------

PC3
14. On PC3, clear the local ARP table and try to ping the default gateway again. The ping will fail
because the switch will drop ARP packets from PC3.
C:\WINDOWS\system32> arp -d *

C:\WINDOWS\system32> ping 10.1.21.1

Pinging 10.1.21.1 with 32 bytes of data:

Reply from 10.1.21.51: Destination host unreachable.
Reply from 10.251.13.254: Destination host unreachable.
Reply from 10.251.13.254: Destination host unreachable.
<output omitted>

Access-1
15. Re-enable DHCP snooping for VLAN 21.

Lab 6: Additional Layer 3 features

ICX-Access-1(config)# vlan 21
ICX-Access-1(config-vlan-21)# dhcpv4-snooping
ICX-Access-1(config-vlan-21)# exit

PC3
16. Renew your IP address on PC3 and make sure it can ping the default gateway IP address in
VLAN 21.
C:\WINDOWS\system32> ipconfig /release
<output omitted>

C:\WINDOWS\system32> ipconfig /renew

<output omitted>

C:\WINDOWS\system32> ping 10.1.21.1

Task 6-5: Implementing Dynamic ARP Inspection 271

 Pinging 10.1.21.1 with 32 bytes of data:
Reply from 10.1.21.1: bytes=32 time<1ms TTL=64
Reply from 10.1.21.1: bytes=32 time<1ms TTL=64
<output omitted>

This completes the task on DAI.

The configuration of this lab is not needed in any upcoming labs. Therefore, no checkpoints
need to be created on the switches.

You have completed Lab 6!

272 Task 6-5: Implementing Dynamic ARP Inspection

Lab 7: IGMP and IGMP snooping

Lab 7: IGMP and IGMP snooping

Lab diagram

Overview
In this lab activity, an IGMP querier and IGMP snooping will be configured and demonstrated. The VSX
core will be configured to perform the IGMP querier function, since the core has the IP interface in the
user VLAN. The access switches will be configured with IGMP snooping. This will ensure that the
multicast traffic is only delivered to the ports with active subscribers. PC3, connected to Access-1, will
be transmitting a multicast stream, while PC4, connected to Access-2, will be configured to register and
listen for the multicast stream.

Objectives
n Configure an IGMP querier on the VSX system.
n Configure IGMP snooping on the access switches.
n Understand the need for IGMP configuration.
n Verify the IGMP operation.

Lab 7: IGMP and IGMP snooping 273

Task 7-1: Prepare the lab starting configuration
Objectives
n This lab is built on the base VSX topology created at the end of Lab 2.
n Make sure to complete these steps to get the base VSX checkpoint configuration on the devices.

Steps (required)
1. Open a console connection to the Access-1. Log in using admin/aruba123.
ICX-Access-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-1#

2. Open a console connection to the Access-2. Log in using admin/aruba123.

ICX-Access-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-2#

3. Open a console connection to the Core-1. Log in using admin/aruba123.

ICX-Core-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-1#

4. Open a console connection to the Core-2. Log in using admin/ aruba123.

ICX-Core-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-2#

Access-1
5. On Access-1, enter configuration mode. Assign port 1/1/3 (connected to PC3) as an access port
to VLAN 11 and enable the port.
ICX-Access-1(config)# interface 1/1/3
ICX-Access-1(config-if)# vlan access 11
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# exit

PC3
6. Open a connection to PC3 and reset the Lab NIC (disable/enable).

274 Task 7-1: Prepare the lab starting configuration

 7. Verify that PC3 has an IP address from VLAN 11 (10.1.11.0/24).
C:\WINDOWS\system32> ipconfig

Windows IP Configuration
<output omitted>

Ethernet adapter Lab NIC - 6300-A Port 3:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.11.51
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.11.1

Access-2
8. On Access-2, enter configuration mode, assign port 1/1/4 (connected to PC4) as the access port
to VLAN 11, and enable the port.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# vlan access 11
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit
Lab 7: IGMP and IGMP snooping

PC4
9. Open a connection to PC4 and reset the Lab NIC (disable/enable).

Task 7-1: Prepare the lab starting configuration 275

 10. Verify that PC4 has an IP address from VLAN 11 (10.1.11.0/24).
C:\Users\student> ipconfig

<output omitted>

Ethernet adapter Lab NIC - 6300-B Port 4:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.11.53
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.11.1

11. Verify that PC4 can ping PC3's IP address in VLAN 11. Replace xx with the actual IP address of
PC3 in VLAN 11.
C:\Users\student> ping 10.1.11.xx

Pinging 10.1.11.xx with 32 bytes of data:

Reply from 10.1.11.xx: bytes=32 time=1ms TTL=128
Reply from 10.1.11.xx: bytes=32 time<1ms TTL=128
Reply from 10.1.11.xx: bytes=32 time<1ms TTL=128
Reply from 10.1.11.xx: bytes=32 time<1ms TTL=128

Ping statistics for 10.1.11.51:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

276 Task 7-1: Prepare the lab starting configuration

 Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

Task 7-2: Set up the multicast sender and receiver

Objectives
In this task, the default behavior of the switches will be demonstrated for intra-VLAN IP multicast
traffic (within the VLAN). Lab 8 will cover multicast routing. PC3 (connected to Access-1 1/1/3) will be
transmitting test multicast traffic. On PC4 (connected to Access-2 1/1/4), Wireshark will be used to
verify that the traffic is flooded to all ports in the VLAN, even without any IGMP joins occurring.

Steps
PC3
1. Open PC3 (connected to Access-1).
2. Start the UDP Multicast test tool from the desktop.

3. Under the Sender section (top half of the screen), configure:

n Local Interface Address: Enter your local Lab NIC IP address (in the 10.1.11.0/24 subnet).
Do not confuse this with the Local Multicast Interface Address field.

You may also drag and drop your 10.1.11.y IP from the Local interfaces list to the
Local Interface field. See the following screenshot.
Lab 7: IGMP and IGMP snooping

n Destination (multicast) Address: 239.1.1.1

n Click Start Sender to start.

Task 7-2: Set up the multicast sender and receiver 277

 You may need to scroll down to the bottom or expand the application window in
order to see the Start Sender button.

4. The message to the right of the button should now say Sender has started.

On PC3, locally verify the transmission of the multicast stream

5. On PC3, open Wireshark.
6. Select the Lab NIC and start the capture (click the Wireshark icon).

278 Task 7-2: Set up the multicast sender and receiver

 7. After about five seconds, stop the capture (click the red square icon in the toolbar).
8. Verify that packets are transmitted to the 239.1.1.1 multicast IP address.

Lab 7: IGMP and IGMP snooping

PC4
9. Open PC4 (connected to Access-2), start Wireshark, and perform a packet capture on the Lab
NIC for about five seconds. Then, stop/pause the capture.

Task 7-2: Set up the multicast sender and receiver 279

 10. Verify that the multicast traffic is received on the Lab NIC. If there are too many other traffic
types, apply this display filter to limit the display to IP multicast traffic:
n ip.addr == 224.0.0.0/4

This demonstrates that multicast traffic is flooded, by default.

11. On PC3, stop the multicast transmission so you can start the next task without multicast traffic.

Task 7-3: Enable IGMP querier and snooping

Objectives
In this task, the network switches will be configured with IP IGMP snooping. IP IGMP snooping will look
for IP IGMP JOINs that are sent by the multicast listener devices. To operate correctly, there should be
an IP IGMP querier in the VLAN. This function will be configured on the VSX core switches in VLAN 11.

280 Task 7-3: Enable IGMP querier and snooping

Steps
Core-1: IGMP querier and snooping
1. Open a terminal connection to Core-1 and enter configuration mode.
2. Review the default IP IGMP querier state.
ICX-Core-1(config)# show ip igmp interface vlan11

IGMP is not enabled

3. Enable the querier function for VLAN 11 and VLAN 12.

ICX-Core-1(config)# interface vlan11
ICX-Core-1(config-if-vlan)# ip igmp enable
ICX-Core-1(config-if-vlan)# exit

The ip igmp querier role is default on the Layer 3 VLAN SVI interface, so you are
only required to enable IGMP on the VLAN interface.

4. Repeat this for VLAN 12. (VLAN 12 will be used in the multicast routing lab.)
ICX-Core-1(config)# interface vlan12
ICX-Core-1(config-if-vlan)# ip igmp enable
ICX-Core-1(config-if-vlan)# exit

5. Verify that the IP IGMP querier is now in the Initial Wait state.
ICX-Core-1(config)# show ip igmp interface vlan11

IGMP Configured Version : 3

IGMP Operating Version : 3
Querier State : Initial Wait
Querier IP :
Querier Uptime :
Querier Expiration Time :
IGMP Snoop Enabled on VLAN : False
n Question: Based on this output, what is the default IGMP snooping status on the VLAN?
n Answer: By default, IGMP snooping is disabled on the VLAN. Therefore, the IGMP querier
and snooping functions are enabled separately. The IGMP querier is enabled on the L3
VLAN Interface (interface vlan x), while IGMP snooping is configured on the L2 VLAN con-
text (vlan x).
Lab 7: IGMP and IGMP snooping

6. Enable IGMP snooping on VLAN 11 and VLAN 12.

ICX-Core-1(config)# vlan 11,12
ICX-Core-1(config-vlan-<11,12>)# ip igmp snooping enable
ICX-Core-1(config-vlan-<11,12>)# exit

7. Verify the updated state.

ICX-Core-1(config)# show ip igmp interface vlan11

Task 7-3: Enable IGMP querier and snooping 281

 IGMP Configured Version : 3
IGMP Operating Version : 3
Querier State : Initial Wait
Querier IP :
Querier Uptime :
Querier Expiration Time :
IGMP Snoop Enabled on VLAN : True
<output omitted>

The multicast group 239.255.255.250 may be observed at this point. This depends
on the Windows client that may or may not have used this address already at this
point in the lab—you can ignore this address, if seen at the bottom of the display.

Core-2: IGMP querier and snooping

8. Open a terminal connection to Core-2 and enter configuration mode.
9. Enable the querier function for VLAN 11 and VLAN 12.
ICX-Core-2(config)# interface vlan11
ICX-Core-2(config-if-vlan)# ip igmp enable
ICX-Core-2(config-if-vlan)# exit

ICX-Core-2(config)# interface vlan12

ICX-Core-2(config-if-vlan)# ip igmp enable
ICX-Core-2(config-if-vlan)# exit

10. Enable IGMP snooping on the Layer 2 VLANs 11 and 12.

ICX-Core-2(config)# vlan 11,12
ICX-Core-2(config-vlan-<11,12>)# ip igmp snooping enable
ICX-Core-2(config-vlan-<11,12>)# exit

11. Review the status of IGMP.

ICX-Core-2(config)# show ip igmp interface vlan 11

IGMP Configured Version : 3

IGMP Operating Version : 3
Querier State : Initial Wait
Querier IP :
Querier Uptime :
Querier Expiration Time :
IGMP Snoop Enabled on VLAN : True
<output omitted>

Depending on your lab pace, the switches may already have transitioned from Initial
Wait to Querier or Non-Querier at this point.

282 Task 7-3: Enable IGMP querier and snooping

 Enable IP IGMP snooping on Access-1 and Access-2
Access-1
12. Open a terminal connection to Access-1 and enter configuration mode.
13. Enable IGMP snooping for VLAN 11 and VLAN 12.
ICX-Access-1(config)# vlan 11,12
ICX-Access-1(config-vlan-<11,12>)# ip igmp snooping enable
ICX-Access-1(config-vlan-<11,12>)# exit

14. Verify the configuration status of IGMP snooping.

ICX-Access-1(config)# show ip igmp snooping vlan 11
IGMP Snooping Protocol Info

Total VLANs with IGMP enabled : 2

Current count of multicast groups joined : 0

IGMP Drop Unknown Multicast : Global

VLAN ID : 11
VLAN Name : VLAN11
IGMP Configured Version : 3
IGMP Operating Version : 3
Querier Address :
Querier Port :
Querier UpTime :
Querier Expiration Time :

Access-2
15. Open a terminal connection to Access-2 and enter configuration mode.
16. Enable IGMP snooping for VLAN 11 and VLAN 12.
ICX-Access-2(config)# vlan 11,12
ICX-Access-2(config-vlan-<11,12>)# ip igmp snooping enable
ICX-Access-2(config-vlan-<11,12>)# exit

Core-1
17. On Core-1, verify the state until Initial Wait has changed to Querier. It may take a few minutes
before Core-1 transitions to the IP querier state. Make sure to wait in the lab until this has
occurred.
ICX-Core-1(config)# show ip igmp interface vlan11
Lab 7: IGMP and IGMP snooping

IGMP Configured Version : 3

IGMP Operating Version : 3
Querier State : Querier
Querier IP [this switch] : 10.1.11.2
Querier Uptime : 7m 17s
Querier Expiration Time : 0m 5s
IGMP Snoop Enabled on VLAN : True

Task 7-3: Enable IGMP querier and snooping 283

 Active Group Address Vers Mode Uptime Expires
---------------------- ---- ---- --------- ---------
239.255.255.250 3 EXC 0m 21s 4m 4s

You might have to disable and re-enable the L3 interface VLAN 11 and VLAN 12
interfaces with one or both core switches to force the IGMP querier election process.

You might need to periodically re-execute the previous command until the correct
state is displayed. You can ignore the 239.255.255.250 address, if it is displayed at
the bottom of the output.

Core-2
18. Repeat this on Core-2 and verify it has transitioned to Non-Querier.
ICX-Core-2(config)# show ip igmp interface vlan 11

IGMP Configured Version : 3

IGMP Operating Version : 3
Querier State : Non-Querier
Querier IP : 10.1.11.2
Querier Uptime : 9m 17s
Querier Expiration Time : 2m 20s
IGMP Snoop Enabled on VLAN : True

Active Group Address Vers Mode Uptime Expires

---------------------- ---- ---- --------- ---------
239.255.255.250 3 EXC 2m 34s 2m 49s

Now that the core switch is sending out regular queries for IGMP membership, the access
switches' IGMP snooping should be able to detect the querier port.
Access-1
19. On Access-1, verify that the upstream IGMP querier was detected on LAG 255 (this is the LAG to
the VSX core).
ICX-Access-1(config)# show ip igmp snooping vlan 11
IGMP Snooping Protocol Info

Total VLANs with IGMP enabled : 2

Current count of multicast groups joined : 1

IGMP Drop Unknown Multicast : Global

VLAN ID : 11
VLAN Name : VLAN11
IGMP Configured Version : 3
IGMP Operating Version : 3
Querier Address : 10.1.11.2

284 Task 7-3: Enable IGMP querier and snooping

 Querier Port : lag255
Querier UpTime :5m 33s
Querier Expiration Time :2m 54s
<output omitted>

Access-2
20. Repeat this verification on Access-2.
ICX-Access-2(config)# show ip igmp snooping vlan 11
IGMP Snooping Protocol Info

Total VLANs with IGMP enabled : 2

Current count of multicast groups joined : 1

IGMP Drop Unknown Multicast : Global

VLAN ID : 11
VLAN Name : VLAN11
IGMP Configured Version : 3
IGMP Operating Version : 3
Querier Address : 10.1.11.2
Querier Port : lag255
Querier UpTime :6m 40s
Querier Expiration Time :3m 53s
<output omitted>

Task 7-4: Verify the IGMP snooping operation

Objectives
In this task, the multicast test traffic will be used again, but this time, the multicast traffic should be
filtered due to the IGMP snooping configuration. Once the lab has demonstrated that the traffic was
filtered, the client device (PC4) will send an IGMP JOIN, using the multicast test application, and the
multicast stream from PC3 should be forwarded to the port (1/1/4 on Access-2). Any other ports that
have not sent an IGMP JOIN should not receive the multicast stream for the test group.

Steps
Verify that multicast traffic is no longer flooded
PC3
1. Open PC3 (connected to Access-1) and start the multicast test traffic again by clicking the Start
Sender button.
Lab 7: IGMP and IGMP snooping

2. You may, optionally, restart the Wireshark packet capture for a few seconds to confirm traffic is
being generated.

Task 7-4: Verify the IGMP snooping operation 285

 PC4
3. Open PC4 (connected to Access-2) and start the Wireshark packet capture for a few seconds,
and then stop it again.
4. Confirm that no multicast test traffic was received for the 239.1.1.1 stream.

Some IGMP traffic may be observed since the core IGMP querier will send regular
membership queries and PC3/PC4 will respond with membership reports.

PC4: Verify that multicast traffic is still delivered when requested

5. On PC4, connected to Access-2, start the Wireshark capture again.
6. Start the UDP Multicast Test tool from the desktop.
7. Configure the Receiver section (bottom half of the screen).
n Local Multicast Interface Address: Enter the PC4 Lab NIC IP address

The local address should be listed in the Local Interfaces list. You may also drag and
drop from this list into the field.
Do not confuse this with the Local Interface Address field.

n Multicast address: 239.1.1.1

n Click the Start Receiver button at the bottom of the window.

You may need to scroll down or resize the window to see the Start Receiver button.

286 Task 7-4: Verify the IGMP snooping operation

 8. In the UDP Multicast Test application, the Received section should now show the incoming test
message.

Lab 7: IGMP and IGMP snooping

Task 7-4: Verify the IGMP snooping operation 287

 9. Stop the Wireshark trace and scroll back to the start of the trace.

TIP: It may be easier to apply display filter ip.addr == 224.0.0.0/4 (not /24!) to see
only the multicast traffic.

The trace should show that at the moment the multicast test client application starts the
receiver, the IGMP JOIN is sent by the PC. Following the JOIN message, the actual multicast
traffic will now be received by this switch port.

Verify the IGMP snooping status on the switches

Access-2
10. On Access-2, review all the IGMP snooping groups.
ICX-Access-2(config)# show ip igmp snooping groups

IGMP Group Address Information

VLAN ID Group Address Expires UpTime Last Reporter Type

------- --------------- --------- --------- -------------- ------
11 239.1.1.1 3m 34s 48m 32s 10.1.11.53 Filter
11 239.255.255.250 3m 36s 1h 16m 10.1.11.53 Filter

11. Next, review the IGMP group tables for VLAN 11.
ICX-Access-2(config)# show ip igmp snooping vlan 11
IGMP Snooping Protocol Info

Total VLANs with IGMP enabled : 2

288 Task 7-4: Verify the IGMP snooping operation

 Current count of multicast groups joined : 2

IGMP Drop Unknown Multicast : Global

VLAN ID : 11
VLAN Name : VLAN11
IGMP Configured Version : 3
IGMP Operating Version : 3
Querier Address : 10.1.11.2
Querier Port : lag256
Querier UpTime :23m 15s
Querier Expiration Time :4m 6s

Active Group Address Tracking Vers Mode Uptime Expires

--------------------- ---------- ---- ---- --------- ----------
239.1.1.1 Filter 3 EXC 5m 46s 4m 16s
239.255.255.250 Filter 3 EXC 23m 11s 4m 18s

12. Review the details of group 239.1.1.1 in this VLAN. This will show which port received the
multicast request.
ICX-Access-2(config)# show ip igmp snooping vlan 11 group 239.1.1.1

IGMP ports and group information for group 239.12.1.1

VLAN ID : 11
VLAN Name : VLAN11

Group Address : 239.1.1.1

Last Reporter : 10.1.11.53
Group Type : Filter

V1 V2 Sources Sources
Port Vers Mode Uptime Expires Timer Timer Forwarded Blocked
--------- ---- ---- --------- --------- --------- --------- --------- --------
1/1/4 3 EXC 5m 58s 4m 4s 0 0

Core-1 and Core-2

13. On Core-1 and Core-2, review the IGMP group table 239.1.1.1. Both systems should show a
joined client on LAG 2. This is the LAG to the Access-2 switch where the receiver is connected
(the Last Reporter IP address listed as follows, which is PC4).
ICX-Core-1(config)# show ip igmp snooping vlan 11 group 239.1.1.1

IGMP ports and group information for group 239.1.1.1

Lab 7: IGMP and IGMP snooping

VLAN ID : 11
VLAN Name : VLAN11

Group Address : 239.1.1.1

Last Reporter : 10.1.11.53
Group Type : Filter

Task 7-4: Verify the IGMP snooping operation 289

 V1 V2 Sources Sources
Port Vers Mode Uptime Expires Timer Timer Forwarded Blocked
--------- ---- ---- --------- --------- --------- --------- --------- --------
lag2 3 EXC 8m 21s 3m 51s 0 0

ICX-Core-2(config)# show ip igmp snooping vlan 11 group 239.1.1.1

IGMP ports and group information for group 239.12.1.1

VLAN ID : 11
VLAN Name : VLAN11

Group Address : 239.1.1.1

Last Reporter : 10.1.11.53
Group Type : Filter

V1 V2 Sources Sources
Port Vers Mode Uptime Expires Timer Timer Forwarded Blocked
--------- ---- ---- --------- --------- --------- --------- --------- --------
lag2 3 EXC 8m 52s 3m 19s 0 0

Access-1
14. On Access-1, review the IGMP group membership tables for VLAN 11.
ICX-Access-1(config)# show ip igmp snooping vlan 11
IGMP Snooping Protocol Info

Total VLANs with IGMP enabled : 2

Current count of multicast groups joined : 1

IGMP Drop Unknown Multicast : Global

VLAN ID : 11
VLAN Name : VLAN11
IGMP Configured Version : 3
IGMP Operating Version : 3
Querier Address : 10.1.11.2
Querier Port : lag255
Querier UpTime :28m 17s
Querier Expiration Time :3m 50s

Active Group Address Tracking Vers Mode Uptime Expires

--------------------- ---------- ---- ---- --------- ----------
239.255.255.250 Filter 3 EXC 28m 14s 3m 28s
n Question: Why is the 239.1.1.1 group address not listed here?
n Answer: Multicast traffic is always forwarded to the IGMP querier port, so there is no need
to filter the traffic on this port.
n Question: Why is PC3, connected to interface 1/1/3, not listed?

290 Task 7-4: Verify the IGMP snooping operation

 n Answer: IGMP snooping is looking at the querier port as well as the ports where IGMP
report, JOIN, and/or LEAVE messages are seen, and PC3 is not joining or leaving a
multicast group—PC3 is the sender of the traffic.
This demonstrates the filtering and forwarding of the multicast traffic.

Task 7-5: Verify IGMP snooping fast leave (optional)

This task is optional and can be done if time permits. Check with your instructor. If you skip
this task, this would then be the end of the lab.

Objectives
In this task, the IGMP fast-leave feature will be verified. When a client signals that it no longer needs
the multicast stream using an IGMP leave message, the IGMP querier will check if there are any other
receivers active in the VLAN for that particular multicast group (stream). If no other receivers respond,
the multicast can be filtered immediately. This will be demonstrated using PC4 (connected to Access-
2).

Steps
PC4
1. Open the connection to PC4 (connected to Access-2).
2. Start a new Wireshark packet capture for the Lab NIC and leave it running. You should observe
the incoming multicast to 239.1.1.1.

3. On PC4, in the UDP Multicast Test application, stop the receiver. Lab 7: IGMP and IGMP snooping

Task 7-5: Verify IGMP snooping fast leave (optional) 291

 4. Return to the Wireshark session and stop the packet capture after about five seconds.

The trace should demonstrate that the client is sending an IGMP leave group message to the
224.0.0.22 address (the IGMPv3 multicast address).
Next, the current IGMP querier will check if any other memberships are still active. Since no other
clients respond, the snooping will also terminate the multicast forwarding, so after one to two
additional seconds, there should be no more multicast traffic for the 239.1.1.1 destination.

292 Task 7-5: Verify IGMP snooping fast leave (optional)

 5. On all the switches, verify that 239.1.1.1 is no longer listed. Note that you still might see the
239.255.255.250 multicast stream—you can ignore this Windows stream.
show ip igmp snooping groups

6. You can easily repeat the tests by restarting the multicast receiver client.
This demonstrates the fast-leave operation.
You have completed Lab 7!

Lab 7: IGMP and IGMP snooping

Task 7-5: Verify IGMP snooping fast leave (optional) 293

[This page intentionally left blank]

294 Task 7-5: Verify IGMP snooping fast leave (optional)

Lab 8: Multicast routing with PIM sparse mode

Lab 8: Multicast routing with PIM sparse mode

Lab diagram

Overview
In this lab activity, multicast routing will be configured using PIM Sparse Mode (PIM-SM) on the VSX
core. Multicast routing also requires an IGMP querier, which you completed in the previous lab activity
(Lab 7 IGMP and IGMP snooping). In this lab, the end result will be that a multicast that is transmitted
by PC3 in VLAN 11 can be received by PC4 in VLAN 12, which requires multicast routing.

Objectives
n Understand multicast routing.
n Activate PIM-SM globally and at the interface-level configuration.
n Verify the multicast routing table.

Task 8-1: Prepare and review the lab setup

Objectives
This lab requires the completion of the Lab 7 IGMP and IGMP snooping lab activity.
PC3 should be in VLAN 11 from this lab. In this task, PC4 will be moved to VLAN 12.

Lab 8: Multicast routing with PIM sparse mode 295

Steps
Access-2
1. Access the terminal of Access-2 and enter configuration mode.
2. Assign PC4's port to VLAN 12.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# vlan access 12
ICX-Access-2(config-if)# exit

PC4
3. Open PC4 (connected to Access-2); renew the IP address by bouncing (disable/enable) the Lab
NIC port.
4. PC4 should now have an IP address from the VLAN 12 range.
C:\Users\student> ipconfig

<output omitted>

Ethernet adapter Lab NIC - 6300-B Port 4:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.12.51
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.12.1

5. Verify that PC4 (in VLAN 12) can ping PC3 (in VLAN 11). Replace xx with the actual IP address
of PC3.
C:\Users\student> ping 10.1.11.xx

Pinging 10.1.11.xx with 32 bytes of data:

Reply from 10.1.11.xx: bytes=32 time<1ms TTL=127
Reply from 10.1.11.xx: bytes=32 time<1ms TTL=127
<output omitted>

Verify the IP IGMP querier on the core switches

PIM multicast routing relies on IGMP join packets from the client devices to learn which mul-
ticasts are requested by the clients. Therefore, the IGMP querier function must be enabled and
functional on the receiving client interfaces before PIM routing can operate.
Core-1
6. On Core-1, verify the IP IGMP querier status for VLAN 11 and 12 Layer 3 interfaces. Note that if
you see an active group address of 239.255.255.250, you can ignore this.
ICX-Core-1(config)#show ip igmp interface vlan11

IGMP Configured Version : 3

296 Task 8-1: Prepare and review the lab setup

 Lab 8: Multicast routing with PIM
sparse mode
IGMP Operating Version : 3
Querier State : Querier
Querier IP [this switch] : 10.1.11.2
Querier Uptime : 3h 38m
<output omitted>

ICX-Core-1(config)#show ip igmp interface vlan12

IGMP Configured Version : 3

IGMP Operating Version : 3
Querier State : Querier
Querier IP [this switch] : 10.1.12.2
Querier Uptime : 5m 24s
Querier Expiration Time : 1m 58s
<output omitted>

Core-2
7. Repeat the verification on Core-2.

This can also be done via Core-1 by appending vsx-peer to the commands from
Core-1.

ICX-Core-2(config)#show ip igmp interface vlan11

IGMP Configured Version : 3

IGMP Operating Version : 3
Querier State : Non-Querier
Querier IP : 10.1.11.2
Querier Uptime : 26m 30s
Querier Expiration Time : 2m 57s
<output omitted>

ICX-Core-2(config)#show ip igmp interface vlan12

IGMP Configured Version : 3

IGMP Operating Version : 3
Querier State : Non-Querier
Querier IP : 10.1.12.2
Querier Uptime : 5m 27s
Querier Expiration Time : 3m 32s
<output omitted>

Task 8-1: Prepare and review the lab setup 297

Task 8-2: Configure PIM sparse mode
Objectives
In this task, the PIM sparse mode (PIM-SM) Candidate Bootstrap Router (C-BSR) is configured. Once
the BSR has been elected, the Candidate Rendezvous Points (C-RP) will be elected and distributed by
the BSR. On the RP, the administrator can specify that the RP should be the handling point for a spe-
cific range of multicast addresses.

Steps
Core-1: PIM-SM configuration
1. Open a terminal to Core-1 and enter configuration mode.
2. Access the router pim context.
ICX-Core-1(config)# router pim

3. For multicast on a VSX cluster, the best practice is to configure PIM Dual-DR under the PIM
router command. With the active-active command, the proxy DR will also learn the multicast
routes, which will allow a fast recovery time if the actual DR fails.
ICX-Core-1(config-pim)# active-active

In a VSX cluster, the VSX member with the highest IP address will be the forwarder of
the multicast traffic. In this lab setup, Core-2 will become the forwarder. Do not con-
figure PIM-interface-level designated router (DR) priority when active-active is
enabled, since the active-active feature will overrule the manually configured inter-
face priority.

4. Attempt to enable the C-BSR function using the VLAN 1 interface as the source address.

In a typical deployment, a loopback interface would be used for this function. This lab
uses the VLAN 1 IP interface since it is already configured. If a loopback interface is
used, make sure it is routable in the network.

ICX-Core-1(config-pim)#bsr-candidate source-ip-interface vlan1

PIM SM should be configured on one or more interface.
n Question: Why did the switch return an error?
n Answer: While the VLAN 1 IP interface exists, the PIM protocol must first be enabled on
the interface before it can be used in the PIM election process.
5. Enable PIM on the VLAN 1 interface.
ICX-Core-1(config-pim)# exit
ICX-Core-1(config)# interface vlan1
ICX-Core-1(config-if-vlan)# ip pim-sparse enable

298 Task 8-2: Configure PIM sparse mode

 Lab 8: Multicast routing with PIM
sparse mode
ICX-Core-1(config-if-vlan)# exit

6. Try to enable the C-BSR function again using the loopback interface, and enable the PIM routing
protocol.
ICX-Core-1(config)# router pim
ICX-Core-1(config-pim)#bsr-candidate source-ip-interface vlan1
ICX-Core-1(config-pim)# enable

7. Assign the Core-1 BSR priority 250.

ICX-Core-1(config-pim)#bsr-candidate priority 250
ICX-Core-1(config-pim)# exit

8. Review the local BSR candidate information.

ICX-Core-1(config)#show ip pim bsr local

Status and Counters - PIM-SM Local Candidate-BSR Information

VRF : default
C-BSR Admin Status : This system is a Candidate-BSR
C-BSR Address : 10.1.1.2
C-BSR Priority : 250
C-BSR Hash Mask Length : 30
C-BSR Message Interval : 60
C-BSR Source IP Interface : vlan1

9. Enable PIM SM on Layer 3 interfaces VLAN 11 and VLAN 12.

ICX-Core-1(config)# interface vlan11
ICX-Core-1(config-if-vlan)# ip pim-sparse enable
ICX-Core-1(config-if-vlan)# exit

ICX-Core-1(config)# interface vlan12

ICX-Core-1(config-if-vlan)# ip pim-sparse enable
ICX-Core-1(config-if-vlan)# exit

Core-2: PIM-SM configuration

10. On Core-2, configure PIM-SM on the interfaces and make it C-BSR.
ICX-Core-2(config)# interface vlan1
ICX-Core-2(config-if-vlan)# ip pim-sparse enable
ICX-Core-2(config-if-vlan)# exit

ICX-Core-2(config)# interface vlan11

ICX-Core-2(config-if-vlan)# ip pim-sparse enable
ICX-Core-2(config-if-vlan)# exit

ICX-Core-2(config)# interface vlan12

ICX-Core-2(config-if-vlan)# ip pim-sparse enable

Task 8-2: Configure PIM sparse mode 299

 ICX-Core-2(config-if-vlan)# exit

ICX-Core-2(config)# router pim

ICX-Core-2(config-pim)# active-active
ICX-Core-2(config-pim)#bsr-candidate source-ip-interface vlan1
ICX-Core-2(config-pim)# enable
ICX-Core-2(config-pim)# exit

Verify the BSR election

Core-1
11. On Core-1, review the elected BSR information.
ICX-Core-1(config)#show ip pim bsr elected

Status and Counters - PIM-SM Elected Bootstrap Router Information

VRF : default
E-BSR Address : 10.1.1.2
E-BSR Priority : 250
E-BSR Hash Mask Length : 30
E-BSR Up Time : 1 mins 57 secs
Next Bootstrap Message : 13 secs

It may take up to two minutes before Core-2 shows 10.1.1.2 as the E-BSR address.

Core-2
12. On Core-2, review the elected BSR information.
ICX-Core-2(config)#show ip pim bsr elected

Status and Counters - PIM-SM Elected Bootstrap Router Information

VRF : default
E-BSR Address : 10.1.1.2
E-BSR Priority : 250
E-BSR Hash Mask Length : 30
E-BSR Up Time : 2 mins 40 secs
Next Bootstrap Message : 1 mins 40 secs

It may take up to two minutes for the E-BSR to show Core-1's IP address.

300 Task 8-2: Configure PIM sparse mode

 Lab 8: Multicast routing with PIM
sparse mode
PIM-SM RP
Core-1
13. On Core-1, review the default RP candidate information and active RP sets. This shows that there
is no default RP on the system.
ICX-Core-1(config)#show ip pim rp-candidate

ICX-Core-1(config)#show ip pim rp-set

14. Make Core-1 a candidate RP.

ICX-Core-1(config)# router pim
ICX-Core-1(config-pim)#rp-candidate source-ip-interface vlan1

Core-2
15. Make Core-2 a candidate RP.
ICX-Core-2(config)# router pim
ICX-Core-2(config-pim)#rp-candidate source-ip-interface vlan1

Core-1: Verify the RP set

16. On Core-1, review the RP set.
ICX-Core-1(config-pim)# show ip pim rp-set

VRF: default

Status and Counters - PIM-SM Learned RP-Set Information

Group Address Group Mask RP Address Hold Time Expire Time
--------------- --------------- --------------- --------- -----------
224.0.0.0 240.0.0.0 10.1.1.3 150 149
224.0.0.0 240.0.0.0 10.1.1.2 150 149

It may take a minute or so for the Core-2 RP (10.1.1.3) to appear in the list. You do
not need to wait for this entry but can proceed with the lab.

RP for multicast group

By default, an RP will be the RP for all possible multicast entries (224.0.0.0/4). In a large network
with multiple sites or regions, the administrator may want to have a regional RP for the local
multicast traffic. In this case, the administrator should use structural IP addressing for the
multicast applications.
In this lab, your table will be considered a separate region, so the local RPs will be configured to
be the preferred RPs for the local multicast ranges (239.1.0.0/16).

Task 8-2: Configure PIM sparse mode 301

 Core-1
17. On Core-1, configure the 239.1.0.0/16 group-prefix for the RP.
ICX-Core-1(config-pim)#rp-candidate group-prefix 239.1.0.0/16
ICX-Core-1(config-pim)# exit

Core-2
18. Repeat this on Core-2.
ICX-Core-2(config-pim)#rp-candidate group-prefix 239.1.0.0/16
ICX-Core-2(config-pim)# exit

19. On Core-2, review the resulting local candidate RP information.

ICX-Core-2(config)#show ip pim rp-candidate
Status and Counters- PIM-SM Candidate-RP Information

VRF : default
C-RP Admin Status : This system is a Candidate-RP
C-RP Address : 10.1.1.3
C-RP Hold Time : 150
C-RP Advertise Period : 60
C-RP Priority : 192
C-RP Source IP Interface : vlan1

Group Address Group Mask

--------------- ---------------
224.0.0.0 240.0.0.0
Group Address Group Mask
--------------- ---------------
239.12.0.0 255.255.0.0

Verify RP set and group prefixes

20. Verify that both Core-1 (10.1.12.2) and Core-2 (10.1.12.3) are now listed in the RP set for the
239.1.0.0/16 group prefix.
ICX-Core-1(config-pim)# show ip pim rp-set

VRF: default

Status and Counters - PIM Learned RP-Set Information

Group Address Group Mask RP Address Hold Time Expire Time Priority
--------------- ------------ --------------- --------- ----------- --------
224.0.0.0 240.0.0.0 10.1.1.3 150 149 192
224.0.0.0 240.0.0.0 10.1.1.2 150 149 192
239.1.0.0 255.255.0.0 10.1.1.2 150 149 192
239.1.0.0 255.255.0.0 10.1.1.3 150 149 192

ICX-Core-2(config)#show ip pim rp-set

302 Task 8-2: Configure PIM sparse mode

 Lab 8: Multicast routing with PIM
sparse mode
VRF: default

Group Address Group Mask RP Address Hold Time Expire Time Priority
--------------- ------------ --------------- --------- ----------- --------
224.0.0.0 240.0.0.0 10.1.1.3 150 146 192
224.0.0.0 240.0.0.0 10.1.1.2 150 146 192
239.1.0.0 255.255.0.0 10.1.1.2 150 146 192
239.1.0.0 255.255.0.0 10.1.1.3 150 146 192

It may take up to a minute before the updated RP set is seen for 10.1.1.2 and
10.1.1.3.

Task 8-3: Verify multicast forwarding

Objectives
In this task, the multicast routing will be tested between the hosts in VLAN 11 and VLAN 12.
n PC3 (connected to Access-1) belongs to VLAN 11 and will be transmitting the multicast test
traffic (sending).
n PC4 (connected to Access-2) belongs to VLAN 12 and will request the test multicast traffic
(receiving).
Once the multicast traffic arrives, the status of the multicast group information will be reviewed on the
core switches.

Steps
PC3: Test multicast transmitter and registration
1. On PC3 (connected to Access-1), configure the UDP Multicast Test tool as Sender. (The tool can
be found on the desktop).
n Local Interface Address: 10.1.11.y (Your PC as shown in the Local Interfaces list)
n Destination multicast address: 239.1.1.1

2. Click the Start Sender button at the bottom of the window to make the Multicast Sender active.
It will now start to send traffic to the 239.1.1.1 destination address, using the local interface
10.1.11.y.

Task 8-3: Verify multicast forwarding 303

 You may need to scroll down to see the Start Sender button.

Core-1
3. On Core-1, review the brief output of the current multicast routing table. The 239.1.1.1 multicast
should have been learned by the data plane on VLAN 11. This also shows the source address of
the transmitter (10.1.11.y).
ICX-Core-1(config)# show ip mroute brief
---------------------------------------------------------------------------------
VRF : default Total number of entries : 1
---------------------------------------------------------------------------------
Group Address Source Address Neighbor Interface Uptime State
(HH:MM:SS)
------------- --------------- -------- ---------- ----------- -------
239.1.1.1 10.1.11.y vlan11 00:06:09 bridge
---------------------------------------------------------------------------------

4. Review the details of the 239.1.1.1 route. This will show that the multicast was registered with
the PIM-SM protocol.
ICX-Core-1(config)# show ip mroute 239.1.1.1

IP Multicast Route Entries

VRF : default

Group Address : 239.1.1.1

Source Address : 10.1.11.y
Neighbor : 10.1.11.3
Incoming interface : vlan11
Multicast Routing Protocol : PIM-SM
Unicast Routing Protocol : connected
Metric : 0
Metric Pref : 0
n Question: What is the Incoming interface?
n Answer: The multicast traffic is received by the core switch on the VLAN 11 interface.
n Question: Are there any outgoing interfaces listed?

304 Task 8-3: Verify multicast forwarding

 Lab 8: Multicast routing with PIM
sparse mode
n Answer: Since there are no registered subscribers, there are no outgoing interfaces at this
moment.
Test the multicast routing forwarding
PC4
5. On PC4 (connected to Access-2), start a Wireshark trace on the Lab NIC.
6. Next, enable the UDP Multicast Test tool as Receiver (lower section).
n Local Multicast Interface address: 10.1.12.y
Make sure this is the updated VLAN 12 IP address. You can click the Refresh button to
see the updated Local Interfaces.
n Multicast Address: 239.1.1.1

7. Scroll down and click the Start Receiver button. Verify that the test messages are received in
the tool.

8. Return to Wireshark and stop the trace. Scroll to the top of the trace. The test tool has sent the
IGMP join request. The core switch has received the IGMP join and has initiated the multicast
routing forwarding process.

Task 8-3: Verify multicast forwarding 305

 Core-1
9. On Core-1, review that the PC4 host in VLAN 12 has joined the multicast stream.
ICX-Core-1(config)# show ip igmp group 239.1.1.1

IGMP group information for group 239.1.1.1

Interface Name : vlan12

VRF Name : default

Group Address : 239.12.1.1

Last Reporter : 10.1.12.y

V1 V2 Sources Sources
Vers Mode Uptime Expires Timer Timer Forwarded Blocked
---- ---- --------- --------- --------- --------- --------- --------
3 EXC 4m 13s 3m 7s

10. On Core-1, review the multicast routing table. Notice the downstream interface; this was initiated
based on the IGMP join. The proxy DR is used by VSX to synchronize the active multicast routes
between the two VSX nodes.
ICX-Core-1(config)# show ip mroute 239.1.1.1

IP Multicast Route Entries

VRF : default

Group Address : 239.1.1.1

Source Address : 10.1.11.y
Neighbor :
Incoming interface : vlan11
Multicast Routing Protocol : PIM-SM
Unicast Routing Protocol : connected
Metric : 0
Metric Pref : 0
Uptime (HH:MM:SS) : 00:15:13
Downstream Interface
Interface State VSX Role
----------- ---------- --------
vlan12 forwarding Proxy DR

306 Task 8-3: Verify multicast forwarding

 Lab 8: Multicast routing with PIM
sparse mode
Group Address : 239.1.1.1
Source Address : 10.1.11.y
Neighbor :
Incoming interface : vlan12
Multicast Routing Protocol : PIM-SM
Unicast Routing Protocol : connected
Metric : 0
Metric Pref : 0
Uptime (HH:MM:SS) : 00:02:09

11. Check Core-2 as well. In this example, notice that Core-2 is the PIM DR for VLAN 12.
ICX-Core-1(config)# show ip mroute 239.1.1.1 vsx-peer

IP Multicast Route Entries

VRF : default

Group Address : 239.1.1.1

Source Address : 10.1.11.51
Neighbor :
Incoming interface : vlan11
Multicast Routing Protocol : PIM-SM
Unicast Routing Protocol : connected
Metric : 0
Metric Pref : 0
Uptime (HH:MM:SS) : 00:18:02
Downstream Interface
Interface State VSX Role
----------- ---------- --------
vlan12 forwarding DR

You have completed Lab 8!

Task 8-3: Verify multicast forwarding 307

[This page intentionally left blank]

308 Task 8-3: Verify multicast forwarding

Lab 9: Access control lists

Lab 9: Access control lists

Lab diagram

Overview
In this lab activity, Access Control Lists (ACLs) are configured and tested on the switch. First, an ACL is
defined and then access list rules are reviewed. Next, the ACL is applied to a switch port and tested.
Then, the object group feature will be demonstrated. This allows the grouping of multiple IP addresses
or ports in a logical group, so the ACL rules can be simplified. The last part of the lab will review the
resource utilization of the ACLs in the hardware tables.

Objectives
n Create an ACL.
n Understand the ACL rules.
n Remove an ACL rule and re-sequence the rules.
n Activate an ACL on a switch.
n Use object groups for IP addresses and ports.
n Review the hardware resource utilization.

Lab 9: Access control lists 309

Task 9-1: Verify the lab starting configuration
Objectives
n If you have just completed Lab 2 Configuring HPE Aruba Networking Virtual Switching
eXtension (VSX), you can skip this task and move to the next task.
n If you have completed any other lab and are performing this lab again, complete these steps to
get the base configuration on the devices.

Steps (required)
1. Open a console connection to the Access-1. Log in using admin/aruba123.
ICX-Access-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-1#

2. Open a console connection to the Access-2. Log in using admin/aruba123.

ICX-Access-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-2#

3. Open a console connection to the Core-1. Log in using admin/aruba123.

ICX-Core-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-1#

4. Open a console connection to the Core-2. Log in using admin/aruba123.

ICX-Core-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-2#

Task 9-2: Port ACLs

Objectives
n Configure an ACL.
n Understand the ACL syntax and rules.
n Apply an ACL to an interface.

Steps
Access-2
1. Open a terminal connection to Access-2 and enter configuration mode.
2. Move interface 1/1/4 back to VLAN 11 and enable it.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# vlan access 11

310 Task 9-1: Verify the lab starting configuration

 ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit

PC4
3. On PC4, disable and re-enable the LAB NIC. Make sure it receives an IP address in VLAN 11.

Lab 9: Access control lists

C:\Users\student> ipconfig

<output omitted>

Ethernet adapter Lab NIC - 6300-B Port 4:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.11.53
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.11.1

Access 2: Create an ACL

4. On Access-2, define a new ACL named pc.
ICX-Access-2(config)# access-list ip pc
ICX-Access-2(config-acl-ip)#

5. Allow DHCP client traffic.

ICX-Access-2(config-acl-ip)# permit udp any eq 68 any eq 67

6. Allow traffic to the local subnet. The wildcard mask is not using inverse bits but a normal subnet
mask logic, so a binary 1 is used to match and a binary 0 is used to ignore the corresponding bit
in the IP address.
In this example, any destination IP address that has 10 in the first byte and 11 in the third byte
will match the rule (255). The value in the second or fourth byte will be ignored (0). Enable the
log and count functions as well.
ICX-Access-2(config-acl-ip)# permit any any 10.0.11.0/255.0.255.0 log count

7. No further lines will be added. Any traffic that is not matching the ACL entries will be handled by
the implicit deny rule; therefore, it will be dropped.

Task 9-2: Port ACLs 311

 Since the implicit deny rule is invisible, you cannot see any logs or hit counts (in older
versions of AOS-CX software) for matches on this statement. Therefore, if you want
traffic to be dropped and either logged or counted, or both (older software), you will
need to create a specific deny statement in your ACL with the corresponding para-
meters. In the current version of code, AOS-CX switches will display the hit counts,
but not the logs, for matches on the implicit deny statement.

8. Review the ACL. Notice that each line now has a line number, so the order of the lines is
important. The line numbers can be used to remove an individual line or to insert a new line
between two existing lines.
ICX-Access-2(config-acl-ip)# show running-config current-context
access-list ip pc
10 permit udp any eq dhcp-client any eq dhcp-server
20 permit any any 10.0.11.0/255.0.255.0 log count
n Question: What happened to the port numbers you configured?
n Answer: AOS-CX has predefined names/aliases for common port numbers. In the previous
example, the alias dhcp-client represents port 68 and dhcp-server port 67. You can use
either method for defining a port, assuming an alias exists for the specified port.
9. Add a new line to match destination 10.0.12.0/255.0.255.0.
ICX-Access-2(config-acl-ip)# permit ip any 10.0.12.0/255.0.255.0 log count

10. Next, verify the configuration again. This shows that entering the same source/destination infor-
mation does not overwrite the existing line, but simply adds a line to the access list.
ICX-Access-2(config-acl-ip)# show running-config current-context
access-list ip pc
10 permit udp any eq dhcp-client any eq dhcp-server
20 permit any any 10.0.11.0/255.0.255.0 log count
30 permit any any 10.0.12.0/255.0.255.0 log count

11. Next, remove line 20 and review the configuration.

ICX-Access-2(config-acl-ip)# no 20
ICX-Access-2(config-acl-ip)# show running-config current-context
access-list ip pc
10 permit udp any eq dhcp-client any eq dhcp-server
30 permit any any 10.0.12.0/255.0.255.0 log count

12. The switch supports resequencing the line numbers. This must be done from the global con-
figuration. There is a start number and an increment number.
ICX-Access-2(config-acl-ip)# exit
ICX-Access-2(config)# access-list ip pc resequence 1000 100

13. Review the ACL configuration with the updated line numbers.
ICX-Access-2(config)# show access-list configuration commands
access-list ip pc

312 Task 9-2: Port ACLs

 1000 permit udp any eq dhcp-client any eq dhcp-server
1100 permit any any 10.0.12.0/255.0.255.0 log count

Access-2: Apply the ACL

14. Enter the interface 1/1/4 context and apply the ACL inbound to the port.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# apply access-list ip pc in
ICX-Access-2(config-if)# exit

Lab 9: Access control lists

15. Review the ACL configuration, noticing how the access-list and interface commands are com-
bined in the output.
ICX-Access-2(config)# show access-list configuration commands
access-list ip pc
1000 permit udp any eq dhcp-client any eq dhcp-server
1100 permit any any 10.0.12.0/255.0.255.0 log count
interface 1/1/4
apply access-list ip pc in

ACL applications

IMPORTANT: The next steps are for reference only: no actual configuration should
be performed.
Do not perform the following steps!

n Reference only: ACLs can be applied on switched (non-routed) ports in the inbound and
outbound direction.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# show run current-context
interface 1/1/4
no shutdown
apply access-list ip pc in
no routing
vlan access 11
exit
ICX-Access-2(config-if)# apply access-list ip pc ?
in Inbound (ingress) traffic
out Outbound (egress) traffic
n Reference only: ACLs can also be applied to routed ports (example only, no actual con-
figuration required).
ICX-Access-2(config)# interface 1/1/2
ICX-Access-2(config-if)# show run cur
interface 1/1/2
shutdown
no routing
vlan access 1
exit

Task 9-2: Port ACLs 313

 ICX-Access-2(config-if)# routing
ICX-Access-2(config-if)# show run cur
interface 1/1/2
shutdown
routing
exit
ICX-Access-2(config-if)# apply access-list ip pc ?
in Inbound (ingress) traffic
out Outbound (egress) traffic
n Reference only: ACLs can also be applied to a switched VLAN (example only).
ICX-Access-2(config)# vlan 2
ICX-Access-2(config-vlan-2)# apply access-list ip pc ?
in Inbound (ingress) traffic
out Outbound (egress) traffic
ICX-Access-2(config-vlan-2)# interface vlan 2
ICX-Access-2(config-if-vlan)# apply ?
access-list Access control list (ACL)
policy Classifier policy

You will actually perform the next steps.

PC4: Test the ACL
16. On PC4, which is connected to Access-2 port 1/1/4, open a command prompt with administrator
privileges (cmd.exe) and attempt to release and renew the IP address. This should succeed,
since this is allowed.
C:\Users\student> ipconfig /release
C:\Users\student> ipconfig /renew

<output omitted>

Ethernet adapter Lab NIC - 6300-B Port 4:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.11.53
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.11.1

17. Attempt to ping 10.1.12.1. This should succeed since this is allowed in the ACL.
C:\Users\student> ping 10.1.12.1

Pinging 10.1.12.1 with 32 bytes of data:

Reply from 10.1.12.1: bytes=32 time<1ms TTL=64
Reply from 10.1.12.1: bytes=32 time<1ms TTL=64
<output omitted>

18. Attempt to ping to 10.1.11.1. This should fail, due to the ACL implicit deny. Therefore, when
traffic does not match the ACL, it will be rejected.
C:\Users\student> ping 10.1.11.1

314 Task 9-2: Port ACLs

 Pinging 10.12.11.1 with 32 bytes of data:
Request timed out.
<output omitted>

19. On Access-2, review the ACL hit counts. In the output example, four packets have matched the
permit rule, and there were 43 matches on the implicit deny statement. You can use the access-
list log-timer 30 command to speed up the log creation from every 300 seconds to 30
seconds.

Lab 9: Access control lists

ICX-Access-2(config)# show access-list hitcounts ip pc
Statistics for ACL pc (ipv4):
interface 1/1/4 (in):
Matched Packets Configuration
- 1000 permit udp any eq dhcp-client any eq dhcp-server
4 1100 permit any any 10.0.12.0/255.0.255.0 log count
43 implicit deny any any any count

20. Next, review the log file on the switch using the show logging -r -n 10 command. This shows
the log in reverse order, with 10 as the number of lines to display.
The log should show a match for the ping to 10.1.12.1 (event 10001).
ICX-Access-2(config)# show logging -r -n 10
---------------------------------------------------
Event logs from current boot
---------------------------------------------------
2024-05-12T15:19:40.086455-04:00 ICX-Access-2 ops-switchd[947]: Event|10001|LOG_
INFO|CDTR|1|List pc, seq# 1100 permitted icmp 10.1.11.53 -> 10.1.12.1 type 8 code
0, on vlan 11,
port 1/1/4, direction in
2024-05-12T15:13:51.662073-04:00 ICX-Access-2 ntp-mgrd[4054]: Event|1105|LOG_
INFO|||NTP primary server connection established to 10.254.1.21
2024-05-12T15:11:50.425990-04:00 ICX-Access-2 ntp-mgrd[4054]: Event|1106|LOG_
INFO|||NTP primary server connection lost to 10.254.1.21
2024-05-12T14:51:19.222162-04:00 ICX-Access-2 hpe-mgmdd[3421]: Event|2610|LOG_
INFO|CDTR|1|Received IGMPv2 query from 10.1.12.2 when the device is configured for
IGMPv3.
2024-05-12T14:37:27.378878-04:00 ICX-Access-2 ntp-mgrd[4054]: Event|1105|LOG_
INFO|||NTP primary server connection established to 10.254.1.21
2024-05-12T13:16:51.719282-04:00 ICX-Access-2 hpe-restd[928]: Event|14604|LOG_
INFO|AMM|-|Unable to fetch Aruba Central location from via VRF .
2024-05-12T13:16:51.719072-04:00 ICX-Access-2 hpe-restd[928]: Event|14604|LOG_
INFO|AMM|-|Unable to fetch Aruba Central location from via VRF .
2024-05-12T13:16:01.658843-04:00 ICX-Access-2 hpe-restd[928]: Event|14603|LOG_
INFO|AMM|-|Aruba Central location successfully fetched from via VRF
2024-05-12T13:16:01.658715-04:00 ICX-Access-2 hpe-restd[928]: Event|14603|LOG_
INFO|AMM|-|Aruba Central location successfully fetched from via VRF
2024-05-12T13:01:53.930215-04:00 ICX-Access-2 hpe-mgmdd[3421]: Event|2618|LOG_
INFO|CDTR|1|IGMP snooping is operational on VLAN 12.

Task 9-2: Port ACLs 315

 21. To see the last packets that matched an ACL with the log option, use the event ID to filter the
log output.
ICX-Access-2(config)# show logging -r -n 100 | i 10001
2024-05-12T15:19:40.086455-04:00 ICX-Access-2 ops-switchd[947]: Event|10001|LOG_
INFO|CDTR|1|List pc, seq# 1100 permitted icmp 10.1.11.53 -> 10.1.12.1 type 8 code
0, on vlan 11,
port 1/1/4, direction in

Task 9-3: Using object groups

Objectives
In this task, object groups for ACLs will be introduced. Object groups group objects that would oth-
erwise be used directly in ACLs. For example, suppose a customer has two web servers and they want
to allow TCP port 80 and 443 (http/https) access to these two web server IP addresses.
With a traditional ACL, four configuration entries would be required:
n Allow traffic to IP1 TCP port 80.
n Allow traffic to IP2 TCP port 80.
n Allow traffic to IP1 TCP port 443.
n Allow traffic to IP2 TCP port 443.
With object groups, the customer can first assign both IP addresses to an object group (for example,
web-servers) and then use this group in a configuration:
n Allow traffic to web-servers on TCP port 80.
n Allow traffic to web-servers on TCP port 443.
The administrator can also combine ports into an object group, so both 80 and 443 can be combined
into a group (for example, web-ports). The result would be:
n Allow traffic to web-servers on web-ports.
Whenever new ports or new IP addresses must be added, changed, or removed, only the respective
object groups need to be updated. The ACL entries remain the same with their references to the object
groups.

Steps
Define group for core switches' IP
Access-2
1. Open the terminal connection to Access-2 and enter configuration mode.
2. Define a new object group named core-switch.
ICX-Access-2(config)# object-group ip address core-switch

316 Task 9-3: Using object groups

 3. Examine the possible object types.
ICX-Access-2(config-addrgroup-ip)# ?
<1-4294967295> Object Group sequence number
A.B.C.D Specify IP host address
A.B.C.D/M Specify IP network address with prefix length
A.B.C.D/W.X.Y.Z Specify IP network address with network mask
end End current mode and change to enable mode.
exit Exit current mode and change to previous mode
list Print command list

Lab 9: Access control lists

no Negate a command or set its defaults
show Show running system information
n Question: What types of addresses can be added to the object group?
n Answer: A single IP address, a network address with a prefix mask, and a network address
with a network mask.
4. Add the two IP addresses of the two VSX core switches in VLAN 12.
ICX-Access-2(config-addrgroup-ip)# 10.1.12.2
ICX-Access-2(config-addrgroup-ip)# 10.1.12.3

Do not add 10.1.12.1: this address will be used in a validation test, and therefore, it
should not belong to the object group.

5. Review the object group, noticing the line numbers that are automatically generated.
ICX-Access-2(config-addrgroup-ip)# show run current
object-group ip address core-switch
10 10.1.12.2
20 10.1.12.3
ICX-Access-2(config-addrgroup-ip)# exit

6. For reference only: Just like the regular ACL, entries in the object group can be re-sequenced.
This step is for reference only: no actual re-sequencing is needed.
ICX-Access-2(config)# object-group ip address core-switch ?
resequence Re-number entries
reset Reset configuration
<cr>

Access-2: Define group for ports 80 and 443

7. Define a new object group named switch-ports.
ICX-Access-2(config)# object-group port switch-ports

8. Review the object group options.

ICX-Access-2(config-portgroup)# ?
<1-4294967295> Object Group sequence number
end End current mode and change to enable mode.
eq Layer 4 port equal to
exit Exit current mode and change to previous mode

Task 9-3: Using object groups 317

 gt Layer 4 port greater than
list Print command list
lt Layer 4 port less than
no Negate a command or set its defaults
range Layer 4 port range
show Show running system information

9. Add ports 80 and 443 to the object group.

ICX-Access-2(config-portgroup)# eq 80
ICX-Access-2(config-portgroup)# eq 443

10. Review the current configuration.

ICX-Access-2(config-portgroup)# show run current
object-group port switch-ports
10 eq http
20 eq https
ICX-Access-2(config-portgroup)# exit

Access-2: Combine the object groups into an ACL entry

11. Enter the ACL pc context and review the current settings.
ICX-Access-2(config)# access-list ip pc
ICX-Access-2(config-acl-ip)# show run current
access-list ip pc
1000 permit udp any eq dhcp-client any eq dhcp-server
1100 permit any any 10.0.12.0/255.0.255.0 log count

12. Overwrite the current line 1100 with the new line based on the object groups.
ICX-Access-2(config-acl-ip)# 1100 permit tcp any core-switch group switch-ports

13. Verify the new configuration.

ICX-Access-2(config-acl-ip)# show run current
access-list ip pc
1000 permit udp any eq dhcp-client any eq dhcp-server
1100 permit tcp any core-switch group switch-ports
ICX-Access-2(config-acl-ip)# exit

PC4: Verify the operation

14. Using PC4, connected to Access-2, open a web browser and navigate to https://10.1.12.2. You
are connecting to the web service of Core-1. This should succeed (you might see a warning page
about a certificate issue; Core-1's certificate is self-signed). There is no need to log in.
15. Open a new tab in the web browser. Navigate to https://10.1.12.3 (this is Core-2). This should
succeed.
16. Open a new tab in the web browser. Attempt to navigate to https://10.1.12.1. This should fail.
17. You can close the web browser.

318 Task 9-3: Using object groups

Task 9-4: Resource usage
Objectives
ACLs and traffic classifiers consume resources in the switch TCAM tables. When large ACLs or many
ACLs are configured, the administrator can review the current resource utilization of the TCAMs. In this
task, the resources will be reviewed, and the impact of object groups will be examined.

Steps

Lab 9: Access control lists

n Review the current resource usage.
n Adjust the object groups to increase the TCAM use.
n Verify the updated resource usage.
Review the current resource usage
Access-2
1. On Access-2, review the current usage. Notice that you can see the resource usage for each inter-
face, as well as the total resources consumed, at the bottom of the display. In the following
example, no egress TCAM entries are used because there is not an outbound ACL applied on the
switch.
ICX-Access-2(config)# show resources

Resource Usage:

Mod Description
Resource Used Reserved Free
------------------------------------------------------------------------------
1/1 Ingress IP Port ACL Lookup
Ingress TCAM Entries 13 2048
Total
Ingress TCAM Entries 13 2048 18432
Egress TCAM Entries 0 0 8192
Ingress Lookups 1 8
Ingress Flex Lookups 0 1
Egress Lookups 0 4
Ingress Policers 0 2047
Egress Policers 0 2047
ICX-Access-2(config)#

For reference only: This is the output of an example of Core-1's configuration (model 8325)
resources. (Obviously, you have not configured an ACL on Core-1, so your output at this point
would be different.)
ICX-Core-1(config)# show resources

Resource Usage:

Task 9-4: Resource usage 319

 Mod Description
Resource Width Used Reserved Free
-------------------------------------------------------------------------
1/1 Ingress Control Plane Policing
Ingress TCAM Entries 3 231 2304
Egress Control Plane Policing
Egress TCAM Entries 2 84 512
Total
Ingress TCAM Entries 231 2304 6912
Egress TCAM Entries 84 512 1536
Policers 0 6144
Ingress L4 Port Ranges 0 32

Resource data is updated every 10 seconds.

ICX-Core-1(config)#

Access-2
2. Enter the object group IP address of the default gateway address for VLAN 12.
ICX-Access-2(config)# object-group ip address core-switch
ICX-Access-2(config-addrgroup-ip)# 10.1.12.1

3. Wait about 10 seconds, and then review the resources.

ICX-Access-2(config-addrgroup-ip)# show resources

Resource Usage:

Mod Description
Resource Used Free
-------------------------------------------------------------------------
1/1 Ingress IP Port ACL Lookup
Ingress TCAM Entries 15 2048
Total
Ingress TCAM Entries 15 2048 18432
Egress TCAM Entries 0 0 8192
Ingress Lookups 1 8
Ingress Flex Lookups 0 1
Egress Lookups 0 4
Ingress Policers 0 2047
Egress Policers 0 2047

4. Next, add two more IP addresses to the group.

ICX-Access-2(config-addrgroup-ip)# 10.1.12.4
ICX-Access-2(config-addrgroup-ip)# 10.1.12.5
ICX-Access-2(config-addrgroup-ip)# exit

5. Wait about 10 seconds, and then review the resources.

ICX-Access-2(config)# show resources

Resource Usage:

320 Task 9-4: Resource usage

 Mod Description
Resource Used Free
-------------------------------------------------------------------------
1/1 Ingress IP Port ACL Lookup
Ingress TCAM Entries 19 2048
Total
Ingress TCAM Entries 19 2048 18432
Egress TCAM Entries 0 0 8192
Ingress Lookups 1 8
Ingress Flex Lookups 0 1

Lab 9: Access control lists

Egress Lookups 0 4
Ingress Policers 0 2047
Egress Policers 0 2047

6. Enter the port object-group and add a port and port range to the group.
ICX-Access-2(config)# object-group port switch-ports
ICX-Access-2(config-portgroup)# eq 22
ICX-Access-2(config-portgroup)# range 1024 2048
ICX-Access-2(config-portgroup)# exit

7. Wait about 10 seconds, and then review the resources.

ICX-Access-2(config)# show resources

Resource Usage:

Mod Description
Resource Used Free
-------------------------------------------------------------------------
1/1 Ingress IP Port ACL Lookup
Ingress TCAM Entries 34 2048
Total
Ingress TCAM Entries 34 2048 18432
Egress TCAM Entries 0 0 8192
Ingress Lookups 1 8
Ingress Flex Lookups 0 1
Egress Lookups 0 4
Ingress Policers 0 2047
Egress Policers 0 2047

This shows that the object groups are very convenient for the administrator, but internally, they
are extracted so they still consume the same hardware resources as if individual lines would have
been created in the ACLs (object groups were not referenced in ACL entries).
You have completed Lab 9!

Task 9-4: Resource usage 321

[This page intentionally left blank]

322 Task 9-4: Resource usage

Lab 10: 802.1X authentication and user roles on
AOS-CX

Lab 10: 802.1X authentication and user roles on AOS-CX

Lab diagram

Overview
In this lab activity, 802.1X will be configured on an access switch. This will require the configuration of
a RADIUS server and will include RADIUS change of authorization (CoA) support.
For the first 802.1X authentication part of the lab, the RADIUS server will provide standard IETF Attrib-
ute Value Pairs (AVP) to assign the user to a VLAN.
Next, the lab will introduce Aruba User-Roles; therefore, the access instructions will be stored in the
switch configuration and the RADIUS server will use the Aruba Vendor-Specific Attribute (VSA) called
Aruba-User-Role.

Lab 10: 802.1X authentication and user roles on AOS-CX 323

Objectives
n Configure a RADIUS server, authentication groups, and dynamic authorization (CoA).
n Configure RADIUS tracking.
n Configure 802.1X on a switch port.
n Configure user roles with policies and classes.

Task 10-1: Verify the lab starting configuration

Objectives
n If you have just completed Lab 02 -VSX, you can skip this task and move to the next task.
n If you have completed any other lab and are performing this lab again, complete these steps to
get the base configuration on the devices.
Steps (required)
1. Open a console connection to the Access-1. Log in using admin/aruba123.
ICX-Access-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-1#

2. Open a console connection to the Access-2. Log in using admin/aruba123.

ICX-Access-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-2#

3. Open a console connection to the Core-1. Log in using admin/aruba123.

ICX-Core-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-1#

4. Open a console connection to the Core-2. Log in using admin/aruba123.

ICX-Core-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-2#

Task 10-2: RADIUS server setup

Objectives
In this task, the Access-1 switch will be configured to use the ClearPass RADIUS server. In campus net-
works, the RADIUS server would typically be reachable over the in-band network.
n How AOS-CX supports the use of server groups will be explained.
n RADIUS accounting and interim accounting will be enabled.

324 Task 10-1: Verify the lab starting configuration

 n CoA (RF-C3576 support) will be enabled and verified.
n RADIUS server tracking will be enabled to verify that the RADIUS server is operational.

Steps
Access-1
1. Open a session to Access-1 and enter configuration mode.

In a later lab, the ClearPass Downloadable User Roles will be configured. Since this
feature will require an HTTPS connection between the switch and the ClearPass host,
this HTTPS connection will be validated by the switch. Therefore, the CPPM HTTPS
certification subject name must match with the DNS name.
To prepare for this later activity, the RADIUS server will be defined based on the host-
name and not based on an IP address. If the customer has an entry for the ClearPass
host in the DNS system, that can be used as well.
In this lab setup, the hostname will be locally defined on the switch, similar to the

Lab 10: 802.1X authentication and

"hosts" file on many operating systems.

user roles on AOS-CX

2. Define a new hostname for cppm.arubatraining.com.
ICX-Access-1(config)# ip dns host cppm.arubatraining.com 10.254.1.23

3. Verify that the new entry works with a test ping.

ICX-Access-1(config)# ping cppm.arubatraining.com
PING cppm.arubatraining.com (10.254.1.23) 100(128) bytes of data.
108 bytes from 10.254.1.23: icmp_seq=1 ttl=62 time=2.68 ms
108 bytes from 10.254.1.23: icmp_seq=2 ttl=62 time=2.08 ms
108 bytes from 10.254.1.23: icmp_seq=3 ttl=62 time=2.21 ms
108 bytes from 10.254.1.23: icmp_seq=4 ttl=62 time=2.40 ms
108 bytes from 10.254.1.23: icmp_seq=5 ttl=62 time=2.19 ms

--- cppm.arubatraining.com ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 2.082/2.313/2.683/0.210 ms

4. Define a new RADIUS host for the ClearPass server.

Make sure to verify the key when entering the command.

ICX-Access-1(config)# radius-server host cppm.arubatraining.com key plaintext

aruba123

5. Define a new server group, and add the previously defined CPPM host.

Task 10-2: RADIUS server setup 325

 ICX-Access-1(config)# aaa group server radius cppm
ICX-Access-1(config-sg)# server cppm.arubatraining.com
ICX-Access-1(config-sg)# exit

6. Enable RADIUS accounting to this server group, enable interim accounting, and set the interim
accounting to five minutes. This will ensure that the switch updates the RADIUS server about the
connected devices every five minutes and will ensure that ClearPass has a view over the cur-
rently connected devices in the network.
ICX-Access-1(config)# aaa accounting port-access start-stop interim 5 group cppm

7. Enable the CoA processing on the switch. This is also known as RFC 3576 support or dynamic
authorization. This allows the RADIUS server (ClearPass) to send a message to the switch to
request an update in the authorization or a re-authentication. Basically, ClearPass can have a
"triggered" re-authentication based on authentication events.
ICX-Access-1(config)# radius dyn-authorization client cppm.arubatraining.com
secret-key plaintext aruba123 replay-protection disable
ICX-Access-1(config)# radius dyn-authorization enable

Replay Protection disable indicates that the timestamp of the CoA packet will not be
inspected by the switch. In a real deployment, replay protection should be enabled.
The default allowed time difference between the RADIUS host and the switch is 300
seconds. Since in the lab, the time of the switch and CPPM may not be in sync, replay
protection is disabled.

Since ClearPass will send a RADIUS CoA message to the switch, it is important that
the switch is configured to accept these RADIUS messages. Typically, it is the switch
that sends the RADIUS request packets to the RADIUS server, and the RADIUS server
responds to these request packets.
In case of the CoA, it is the RADIUS server that initiates the packet. Thus, it is con-
sidered to be the CoA client, while the switch receives the CoA packet, so it is con-
sidered to be the CoA server.

8. Enable RADIUS tracking credentials. RADIUS tracking is a feature that allows the switch to send
test requests on a regular basis, so it can detect if the RADIUS server is still responding. For this
feature, dedicated credentials and ClearPass service can be configured, so it does not interfere
with any regular production credentials or ClearPass services. The tracking test is performed
every five minutes by default; this can also be changed if needed.
ICX-Access-1(config)# radius-server tracking user-name icx-radius-track password
plaintext aruba123

9. The tracking must be enabled per radius-server host.

ICX-Access-1(config)# radius-server host cppm.arubatraining.com tracking enable

326 Task 10-2: RADIUS server setup

 10. On interface 1/1/1, put interface 1/1/1 in VLAN 11 and enable it.
ICX-Access-1(config)# interface 1/1/1
ICX-Access-1(config-if)# vlan access 11
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# exit

PC1
11. On PC1, disable and re-enable the LAB NIC. Make sure it receives an IP address in VLAN 11.

Lab 10: 802.1X authentication and

user roles on AOS-CX
C:\Users\student>ipconfig
<output omitted>

Ethernet adapter Lab NIC - 6300-A Port 1:

Connection-specific DNS Suffix . :

IPv4 Address. . . . . . . . . . . : 10.1.11.54
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.11.1

If the Lab NIC card's IP address is from a subnet other than 10.1.11.0/24, check if it is
configured to use DHCP for IP addressing. If not, please change the NIC card to use
DHCP.

12. Open a web browser connection to the ClearPass host (https://10.254.1.23/tips).

Remote labs, ClearPass servers are using self-signed certificates, so a warning mes-
sage could be displayed. Click Advanced, add an exception, and confirm the security
exception.

Task 10-2: RADIUS server setup 327

 13. Login with these credentials:
n Username: icx-admin1
n Password: aruba123
14. Navigate to Monitoring > Live Monitoring > Access Tracker. Select Edit to change the
columns.

15. Add the NAS IP Address and the Host MAC Address columns to the View and arrange them in
a logical order (see image for an example) and click save.

In some remote lab environments, these column settings may have been applied pre-
viously. If the NAS IP Address and Host MAC Address columns have been configured
already, move to the next step.

328 Task 10-2: RADIUS server setup

 16. Optional step: Add Enforcement Profiles as the last column at the end and click Save.

Lab 10: 802.1X authentication and

user roles on AOS-CX
There should be an "ACCEPT" message displayed for your Access-1 switch (10.1.1.4).
17. Click your switch’s entry in ClearPass and review the Input and Output-tabs.

Task 10-2: RADIUS server setup 329

330 Task 10-2: RADIUS server setup
 Lab 10: 802.1X authentication and
user roles on AOS-CX
You may navigate between the access tracker tabs by clicking the tabs at the top of
the popup screen.

18. On the Access-1 switch, check the RADIUS tracking status.

ICX-Access-1(config)# show radius-server detail
******* Global RADIUS Configuration *******

Shared-Secret: None
Timeout: 5

Task 10-2: RADIUS server setup 331

 Auth-Type: pap
Retries: 1
Initial TLS Connection Timeout: 30
TLS Timeout: 5
Tracking Time Interval (seconds): 300
Tracking Retries: 1
Tracking User-name: icx-radius-track
Tracking Password: AQBapQigcgGUUVgijVS4PZfzCh60bJRm3oCYmRJ5yptBrq/VCAAAAOBgmFAxlMU6
Status-Server Time Interval (seconds): 300
Number of Servers: 1
AAA Server Status Trap: Disabled

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

Server-Name : cppm.arubatraining.com
Auth-Port : 1812
Accounting-Port : 1813
VRF : default
TLS Enabled : No
Shared-Secret :
AQBape3Xwfby5RSI9s19du+71MHbiz8xNsFqkjBlk/zX2owYCAAAAHNgsNDp+pSj
Timeout : 5
Retries : 1
Auth-Type : pap
Server-Group:Priority : cppm:1
ClearPass-Username :
ClearPass-Password : None
Tracking : enabled
Tracking-Mode : any
Reachability-Status : reachable, Since Thu Jul 11 16:41:42 EDT 2024
Tracking-Last-Attempted : Thu Jul 11 16:41:41 EDT 2024
Next-Tracking-Request : 298 seconds

19. Review the RADIUS server statistics.

ICX-Access-1(config)# show radius-server statistics authentication
Server Name : cppm.arubatraining.com
Auth-Port : 1812
Accounting-Port : 1813
VRF : default
TLS Enabled : No

Authentication Statistics
-------------------------
Round Trip Time : 0
Pending Requests : 0
Timeouts : 8
Bad Authenticators : 0
Packets Dropped : 0
Access Requests : 10
Access challenge : 0

332 Task 10-2: RADIUS server setup

 Access Accepts : 2
Access Rejects : 0
Access Response Malformed : 0
Access Retransmits : 4
Tracking Requests : 6
Tracking Responses : 6
Unknown Response Code : 0

In case the switch does not receive a RADIUS response from the RADIUS server, the
switch will consider it "unreachable" and it will use another RADIUS server, if defined.
The switch does not need a RADIUS Accept packet for the tracking to be successful.
Any RADIUS response, both Accept and Reject, results in the tracking feature to
mark the RADIUS server as reachable.

Task 10-3: Basic 802.1X authentication with a single user

Objectives

Lab 10: 802.1X authentication and

In this task, PC3 (connected to Access-1) will perform 802.1X authentication.

user roles on AOS-CX

This lab's purpose is to demonstrate the basic 802.1X authentication process and some of the RADIUS
attributes that a RADIUS server can return to an AOS-CX switch to control client sessions. This task will
not use the role-based configuration yet; that will be done in an upcoming task.
The switch's hostname will be changed so that ClearPass can process this authentication request dif-
ferently from the upcoming authentication with the user roles. The switch's hostname is included in the
RADIUS request to the RADIUS server as the "NAS Identifier". A service on the ClearPass server has
been pre-configured to look for the string "AVP" in the "NAS Identifier".
For this task, the ClearPass server will need to return some standard RADIUS Attribute Value Pairs
(AVP); therefore, the hostname should also contain the string "AVP" to match this service.

Task 10-3: Basic 802.1X authentication with a single user 333

Lab diagram

Steps
Define group for core switches IP
Access-1
1. Change the hostname of the Access-1 switch to: ICX-T1-Access1-avp.
ICX-Access-1(config)# hostname ICX-T1-Access1-avp
ICX-T1-Access1-avp(config)#

334 Task 10-3: Basic 802.1X authentication with a single user

 The hostname is used as the NAS-identifier in the access request to ClearPass.
ClearPass has been pre-configured to look for the value "avp" in the NAS-identifier to
return standard IETF AVPs with VLAN instructions. This lab depends on these
instructions.

2. Enable 802.1X authentication on the switch, and ensure it is using the previously defined
RADIUS server group.
ICX-T1-Access1-avp(config)# aaa authentication port-access dot1x authenticator
radius server-group cppm
ICX-T1-Access1-avp(config)# aaa authentication port-access dot1x authenticator
enable

3. Assign port 1/1/3 to VLAN 1. In this lab, it is simply used as the base landing VLAN in case the
RADIUS server does not assign a VLAN. There is no DHCP server or other resources in this VLAN
in this example.
ICX-T1-Access1-avp(config)# interface 1/1/3
ICX-T1-Access1-avp(config-if)# vlan access 1

Lab 10: 802.1X authentication and

4. Enter the 802.1X authenticator context and enable 802.1X on the port.

user roles on AOS-CX

ICX-T1-Access1-avp(config-if)# aaa authentication port-access dot1x authenticator
ICX-T1-Access1-avp(config-if-dot1x-auth)# enable
ICX-T1-Access1-avp(config-if-dot1x-auth)# exit
ICX-T1-Access1-avp(config-if)# exit

PC3
5. On PC3 (connected to the Access-1 port 1/1/3), ensure that the Windows service "Wired
AutoConfig" is started. This service is not started by default. Open a command prompt with
administrator rights and enter net start dot3svc.
C:\WINDOWS\system32>net start dot3svc
The Wired AutoConfig service is starting.
The Wired AutoConfig service was started successfully.

6. Open Network Connections (Select Start > Settings > Network & Internet > Ethernet >
Change adapter options).

Task 10-3: Basic 802.1X authentication with a single user 335

 7. Under Network Connections, open the Properties of the Lab NIC. Click the Authentication tab
and select Enable IEEE 802.1X authentication.

If the Authentication tab is not available, the 'Wired AutoConfig' service has not been
started on the client PC. Check the previous steps to ensure the service is started.

8. Open Settings for the PEAP method and uncheck Verify the server's identity by validating
the certificate.

The labs are using self-signed certificates for simplicity. Therefore, to avoid any trust
problems, we are disabling certificate validation.
In a real-world environment, it is considered a best-practice, and it is strongly recom-
mended to use trusted certificates and "verify the server's identity by validating the
certificate check box marked.

336 Task 10-3: Basic 802.1X authentication with a single user

 9. Click Configure next to the "EAP-MSCHAP v2" method. Make sure the option "Automatically use
my Windows logon name and password (and domain if any)" is unchecked. Click OK to close the
window.

Lab 10: 802.1X authentication and

user roles on AOS-CX
10. Click OK to close the Protected EAP Properties.
11. Click Additional Settings, check Specify authentication mode, and select User authentication.
12. Click Save credentials to enter the credentials.
a. Username: icx-avp1
b. Password: aruba123

Task 10-3: Basic 802.1X authentication with a single user 337

 13. Click OK to save the credentials. Then, click OK to close Advanced settings, and click OK to close
the Lab NIC Properties.
14. Using PC1, check Access Tracker in ClearPass.

15. Open your authentication entry (make sure to check it has your NAS IP), click Input, and review
the attributes that were sent by the switch in the access request.

338 Task 10-3: Basic 802.1X authentication with a single user

 16. Next, review the Output tab. This shows that ClearPass is returning the IETF VLAN attributes

Lab 10: 802.1X authentication and

and a session timeout of 180 seconds to the switch.

user roles on AOS-CX

The value of 180 seconds was used in the lab environment to demonstrate the re-
authentication. In a real deployment, this value would be controlled by the customer
security policy; this may be several hours.

17. On Access-1, check the authenticated clients. Take note of the MAC address of the authenticated
client.

Task 10-3: Basic 802.1X authentication with a single user 339

 ICX-T1-Access1-avp(config)# show aaa authentication port-access dot1x authenticator
interface all client-status

Client 00:50:56:b1:2c:b8, icx-avp1, 1/1/3

=========================================

Authentication Details
----------------------
Status : Authenticated
Type : Pass-Through
EAP-Method : PEAP
Auth Failure reason :
Time Since Last State Change : 62s

Authentication Statistics
-------------------------
Authentication : 1
Authentication Timeout : 0
EAP-Start While Authenticating : 0
EAP-Logoff While Authenticating : 0
Successful Authentication : 1
Failed Authentication : 0
Re-Authentication : 0
Successful Re-Authentication : 0
Failed Re-Authentication : 0
EAP-Start When Authenticated : 0
EAP-Logoff When Authenticated : 0
Re-Auths When Authenticated : 0
Cached Re-Authentication : 0

ICX-T1-Access1-avp(config)#

18. Review the MAC-address table. The client MAC address should have been assigned to VLAN 11
by port-access-security. Remember that the default VLAN of interface 1/1/3 has been set to
VLAN 1.
ICX-T1-Access1-avp(config)# show mac-address-table
MAC age-time : 300 seconds
Number of MAC addresses : 13

MAC Address VLAN Type Port

--------------------------------------------------------------
b8:d4:e7:40:8e:00 1 dynamic lag255
02:02:00:00:01:00 1 dynamic lag255
10:4f:58:fc:b2:40 1 dynamic lag255
20:4c:03:b1:d4:2a 1 dynamic lag255
b8:d4:e7:40:6d:00 1 dynamic lag255
00:50:56:b1:2c:b8 11 port-access-security 1/1/3
b8:d4:e7:40:8e:00 11 dynamic lag255

340 Task 10-3: Basic 802.1X authentication with a single user

 b8:d4:e7:40:6d:00 11 dynamic lag255
00:50:56:b1:fd:6a 11 dynamic 1/1/1
02:02:00:00:01:00 11 dynamic lag255
b8:d4:e7:40:8e:00 12 dynamic lag255
02:02:00:00:01:00 12 dynamic lag255
b8:d4:e7:40:6d:00 12 dynamic lag255

19. Review the switch log for entries of the port-accessd process. After a few minutes (180
seconds), the user will be re-authenticated based on the RADIUS session timeout. These are the
options used:
-r show log in reverse order

-n 4 last four lines of the log

-d filter on daemon (process)

ICX-T1-Access1-avp(config)# show logging -r -n 4 -d port-accessd
---------------------------------------------------
Event logs from current boot
---------------------------------------------------

Lab 10: 802.1X authentication and

2024-07-12T13:28:46.051150-04:00 ICX-T1-Access1-avp port-accessd[4587]:
Event|10534|LOG_INFO|CDTR|1|Interface 1/1/3 is unblocked by port-access.

user roles on AOS-CX

2024-07-12T13:28:45.869537-04:00 ICX-T1-Access1-avp port-accessd[4587]:
Event|10533|LOG_INFO|CDTR|1|Interface 1/1/3 is blocked by port-access.
2024-07-12T13:25:45.945588-04:00 ICX-T1-Access1-avp port-accessd[4587]:
Event|10534|LOG_INFO|CDTR|1|Interface 1/1/3 is unblocked by port-access.
2024-07-12T13:25:45.746357-04:00 ICX-T1-Access1-avp port-accessd[4587]:
Event|10533|LOG_INFO|CDTR|1|Interface 1/1/3 is blocked by port-access.

20. Review the client accounting information. Notice that the session time will never exceed 180
seconds due to the re-authentication interval.
ICX-T1-Access1-avp(config)# show aaa accounting port-access interface all client-
status

Port Access Client Status Details

Client 00:50:56:b1:2c:b8, icx-avp1

============================
Session Details
---------------
Port : 1/1/3
Session Time : 175s

Accounting Details
----------------------
Accounting Session ID : 172080532651
Input Packets : 35
Input Octets : 3878
Output Packets : 145

Task 10-3: Basic 802.1X authentication with a single user 341

 Output Octets : 19475
Input Gigaword : 0
Output Gigaword : 0

AOS-CX internal user roles

AOS-CX will always apply the authorization settings as a role internally. This is a significant
change compared with the AOS-S-Switch devices, where the switch was either in "radius" mode
or "user-role" mode. With those switches, it was not possible to have some devices authenticated
and authorized with RADIUS attributes while other devices were using a user role.
In AOS-CX, this is solved by converting RADIUS authorization attributes into a temporary user
role of type "radius". Therefore, this role can co-exist with any locally defined roles or ClearPass
downloadable user roles.
21. On the Access-1 switch, review the port-access roles, note the type of the role. This shows which
RADIUS attributes were returned and converted into this temporary user role.
ICX-T1-Access1-avp(config)# show port-access role

Role Information:
Attributes overridden by RADIUS are prefixed by '*'.

Name : RADIUS_2063809959
Type : radius
----------------------------------------------
Session Timeout : 180 secs
Access VLAN : 11

22. Next, review the authenticated users on the interfaces. Notice the difference with the previous
client-status command:
ICX-T1-Access1-avp(config)# show aaa authentication port-access interface all
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-avp1

==================================
Session Details
---------------
Port : 1/1/3
Session Time : 107s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------

342 Task 10-3: Basic 802.1X authentication with a single user

 Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 107s ago

Authorization Details
----------------------
Status : Applied

To show 802.1X authenticated clients:

show aaa authentication port-access dot1x authenticator interface all
client-status

To show the role authorization:

show aaa authentication port-access interface all client-status

Task 10-4: Change of authorization verification

Objectives

Lab 10: 802.1X authentication and

Verify that a disconnect message from the ClearPass RADIUS host is processed correctly by the switch.

user roles on AOS-CX

This allows the ClearPass server to dynamically trigger re-authentication on the access device when
the access security policy or the access conditions change.

Task 10-4: Change of authorization verification 343

Lab diagram

Steps
Define group for core switches, IP
Access-1
1. First, review the current online time of the 802.1X authenticated user. When the CoA disconnect
message is sent in the next steps, you should see that this timer will be reset since the CoA will
trigger a new authentication.
ICX-T1-Access1-avp(config)# show aaa authentication port-access interface all
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-avp1

==================================
Session Details
---------------
Port : 1/1/3

344 Task 10-4: Change of authorization verification

 Session Time : 141s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 141s ago

Authorization Details
----------------------
Status : Applied

2. On PC1, navigate to ClearPass, then navigate to Monitoring > Live Monitoring > Access
Tracker.
3. Open the latest authentication event from your own access switch (use the NAS IP to find your
own authentication session).

Lab 10: 802.1X authentication and

4. On the Summary page, click Change Status to get access to the CoA options.

user roles on AOS-CX

5. Click Submit to test the CoA.

Task 10-4: Change of authorization verification 345

 6. After a few seconds, a "successful" message should be displayed.

If the CoA is not successful, you should check the dynamic authorization con-
figuration on the switch. This was done in Task 2.

7. In the Access Tracker list, a new authentication entry should show up a few seconds later.

346 Task 10-4: Change of authorization verification

 8. On the Access-1 switch, review the "online time" for the authenticated user. The timer should
have been reset.

Lab 10: 802.1X authentication and

ICX-T1-Access1-avp(config)# show aaa authentication port-access interface all
client-status

user roles on AOS-CX

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-avp1

==================================
Session Details
---------------
Port : 1/1/3
Session Time : 98s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 98s ago

Authorization Details
----------------------
Status : Applied

9. Review the "dynamic authorization" statistics.

Task 10-4: Change of authorization verification 347

 ICX-T1-Access1-avp(config)# show radius dyn-authorization
Status and Counters - RADIUS Dynamic Authorization Information

RADIUS Dynamic Authorization : Enabled

RADIUS Dynamic Authorization UDP Port : 3799
Invalid Client Addresses in CoA Requests : 0
Invalid Client Addresses in Disconnect Requests: 0

Dynamic Authorization Client Information

=========================================

IP Address : cppm.arubatraining.com
VRF : default
TLS Enabled : No
Replay Protection : Disabled
Time Window : 300
rfc5176-enforcement-mode : strict
Disconnect Requests : 1
Disconnect ACKs : 1
Disconnect NAKs : 0
CoA Requests : 0
CoA ACKs : 0
CoA NAKs : 0
Shared-Secret :
AQBapQ4rJhVI+hBRTebvvLEVATMhjtFfj0Pd8s36SS/CPa33CAAAAJQbRDn917lm

The actual statistics may be different in your setup.

10. Review the details for the CPPM client.

ICX-T1-Access1-avp(config)# show radius dyn-authorization client
cppm.arubatraining.com
Status and Counters - RADIUS Dynamic Authorization Client Information

VRF Name : default

Authorization Client : cppm.arubatraining.com
TLS Enabled : No
Unknown Packets : 0
Message-Type Disconnect CoA
---------------------------------------------------------------
Total Requests 1 0
Authorize Only Requests 0 0
Malformed Requests 0 0
Bad Authenticator Requests 0 0
Dropped Requests 0 0
Total ACK Responses 1 0
Total NAK Responses 0 0

348 Task 10-4: Change of authorization verification

 Session Not Found Responses 0 0
User Sessions Modified 1 0

Task 10-5: Basic 802.1X authentication with a single user

Objectives
In this task, you will explore how Aruba User Roles will simplify how settings can be assigned to an
authenticated user or device. On the switch, user roles will be defined for an employee and contractor;
each role will have different network access.
The ClearPass server will return this role to the switch when the users complete successful authen-
tication. In order for ClearPass to return the correct Aruba VSA, "Aruba-User-Role," you will change the
hostname of the switch, so a different policy will be applied by the ClearPass server for this task.
To define the roles, you will first define classes and policies. These can control access to the network.
n The employee role will be assigned to VLAN 11, with an unrestricted ACL.
n The contractor role will be assigned to the same VLAN 11, but with a restricted ACL.

Lab 10: 802.1X authentication and

user roles on AOS-CX

Task 10-5: Basic 802.1X authentication with a single user 349

Lab diagram

Steps
Define traffic classes
Each user role will be configured with unique access restrictions to the network. To control network
access, the administrator first needs to describe the traffic classes.
These are global objects that can be used in multiple policies.
Access-1
1. Open a terminal session to Access-1 and enter configuration mode. Define a new class for any
traffic
ICX-T1-Access1-avp(config)# class ip any
ICX-T1-Access1-avp(config-class-ip)# match any any any
ICX-T1-Access1-avp(config-class-ip)# exit

2. Define a new class for servers. This is for lab purposes only, the IP addresses of the core switches
are used to simulate servers.
ICX-T1-Access1-avp(config)# class ip servers
ICX-T1-Access1-avp(config-class-ip)# match any any 10.1.1.2/255.255.255.255
ICX-T1-Access1-avp(config-class-ip)# match any any 10.1.1.3/255.255.255.255

350 Task 10-5: Basic 802.1X authentication with a single user

 Notice how the system automatically adds line numbers for each entered line.
ICX-T1-Access1-avp(config-class-ip)# show running-config current-context
class ip servers
10 match any any 10.0.1.2
20 match any any 10.0.1.3

3. The sequencing makes it easy to remove a single line, or to insert a line between two existing
lines. Remove the second line again and verify one server is listed.
ICX-T1-Access1-avp(config-class-ip)# no 20
ICX-T1-Access1-avp(config-class-ip)# show running-config current-context
class ip servers
10 match any any 10.0.1.2
ICX-T1-Access1-avp(config-class-ip)# exit

Define policy for employees and contractors

These are not the actual roles yet. A policy assigns an action to a traffic class.
4. Define the employee policy. Employees are granted full access to the network.
ICX-T1-Access1-avp(config)# port-access policy employee

Lab 10: 802.1X authentication and

ICX-T1-Access1-avp(config-pa-policy)# class ip any

user roles on AOS-CX

5. By default, when a class is added to a policy, it gets an "permit" action, but many more actions are
possible, such as QoS actions. Review the available actions using the "?" option, but no action
must be configured in this step (due to the default "permit").
ICX-T1-Access1-avp(config-pa-policy)# class ip any action ?
cir Specify the committed information rate
drop Drop all traffic
dscp Specify a Differentiated Services Code Point value
ip-precedence Specify the IP precedence
local-priority Specify a local priority value
pcp Specify the Priority Code Point (PCP) value
redirect Specify a redirect destination
reflect Allow traffic destined to a client only for flows initiated
by client
<cr>
ICX-T1-Access1-avp(config-pa-policy)# exit

6. Define the contractor policy. Contractors will not be allowed access to the "servers" class, so this
action is set to drop. Any other traffic is permitted.
ICX-T1-Access1-avp(config)# port-access policy contractor
ICX-T1-Access1-avp(config-pa-policy)# class ip servers action drop
ICX-T1-Access1-avp(config-pa-policy)# class ip any

7. Review the current context configuration.

ICX-T1-Access1-avp(config-pa-policy)# show running-config current-context
port-access policy contractor

Task 10-5: Basic 802.1X authentication with a single user 351

 10 class ip servers action drop
20 class ip any

8. The policy also allows the administrator to add a comment to each line.
ICX-T1-Access1-avp(config-pa-policy)# 10 comment No server access for Contractors
ICX-T1-Access1-avp(config-pa-policy)# show running-config current-context
port-access policy contractor
10 class ip servers action drop
10 comment No server access for Contractors
20 class ip any
ICX-T1-Access1-avp(config-pa-policy)# exit

9. Review the policy that was just created for the contractor.
ICX-T1-Access1-avp(config)# show port-access policy contractor

Access Policy Details:

======================

Policy Name : contractor

Policy Type : Local
Policy Status : Applied
Base Policy : N/A
ACL Names : N/A

SEQUENCE CLASS TYPE ACTION

----------- ---------------------------- ---- ----------------------------------
10 servers ipv4 drop
20 any ipv4 permit

Define the employee and contractor user roles

10. Define the employee user role. In this step, the previously defined access policy will be bound to
the role. The role also contains the L2 VLAN assignment.
ICX-T1-Access1-avp(config)# port-access role employee
ICX-T1-Access1-avp(config-pa-role)# associate policy employee
ICX-T1-Access1-avp(config-pa-role)# vlan access 11
ICX-T1-Access1-avp(config-pa-role)# exit

11. Define the contractor user role.

ICX-T1-Access1-avp(config)# port-access role contractor
ICX-T1-Access1-avp(config-pa-role)# associate policy contractor
ICX-T1-Access1-avp(config-pa-role)# vlan access 11
ICX-T1-Access1-avp(config-pa-role)# exit

12. Review the defined objects. Notice that these roles are local roles, while in the previous section,
the radius role was automatically defined based on the RADIUS attributes. In a later lab, role
definitions will be downloaded from ClearPass; these are not local roles, but will be clearpass
roles.

352 Task 10-5: Basic 802.1X authentication with a single user

 ICX-T1-Access1-avp(config)# show port-access role

Role Information:
Attributes overridden by RADIUS are prefixed by '*'.

Name : RADIUS_2063809959
Type : radius
----------------------------------------------
Session Timeout : 180 secs
Access VLAN : 11

Name : contractor
Type : local
----------------------------------------------
Access VLAN : 11
Policy : contractor

Name : employee
Type : local

Lab 10: 802.1X authentication and

----------------------------------------------
Access VLAN : 11

user roles on AOS-CX

Policy : employee

Test access for user-role employee

13. Change hostname string from avp to vsa for the remainder of this lab.
ICX-T1-Access1-avp(config)# hostname ICX-T1-Access1-vsa
ICX-T1-Access1-vsa(config)#

The hostname is used as the NAS-identifier. ClearPass has been pre-configured to

look for the value "vsa" in the NAS-identifier to return the Aruba-User-Role VSA
attributes that are needed for this lab.

14. On PC3 (connected to Access-1 port 1/1/3), change the 802.1X authentication credentials to:
a. Username: icx-employee
b. Password: aruba123

Task 10-5: Basic 802.1X authentication with a single user 353

 15. On the ClearPass system, navigate to Access Tracker. Open your most recent authentication
entry (it should have a username of "icx-employee").

16. Check the Output tab of the entry and expand the RADIUS Response section. Notice that AOS-
CX is now also using the Aruba RADIUS dictionary, so to push a user role, the Aruba-User-Role
attribute is used, just like the Aruba Mobility Controller (MC).

354 Task 10-5: Basic 802.1X authentication with a single user

 Lab 10: 802.1X authentication and
The AOS-S switch platform was using the "HPE" RADIUS dictionary, so customers
migrating to AOS-CX should update the RADIUS policy to reflect this change.

user roles on AOS-CX

17. On the switch, review the authenticated 802.1X users.
ICX-T1-Access1-vsa(config)# show aaa authentication port-access dot1x authenticator
interface all client-status

Client 00:50:56:b1:2c:b8, icx-employee, 1/1/3

=========================================

Authentication Details
----------------------
Status : Authenticated
Type : Pass-Through
EAP-Method : PEAP
Auth Failure reason :
Time Since Last State Change : 442s

Authentication Statistics
-------------------------
Authentication : 1
Authentication Timeout : 0
EAP-Start While Authenticating : 0
EAP-Logoff While Authenticating : 0
Successful Authentication : 1
Failed Authentication : 0
Re-Authentication : 1
Successful Re-Authentication : 1

Task 10-5: Basic 802.1X authentication with a single user 355

 Failed Re-Authentication : 0
EAP-Start When Authenticated : 1
EAP-Logoff When Authenticated : 0
Re-Auths When Authenticated : 0
Cached Re-Authentication : 0

18. Review the user role authorization; the user should have been assigned the employee role based
on the RADIUS Aruba-User-Role assignment by ClearPass.
ICX-T1-Access1-vsa(config)# show aaa authentication port-access interface all
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-employee

======================================
Session Details
---------------
Port : 1/1/3
Session Time : 1s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 1s ago

Authorization Details
----------------------
Role : employee
Status : Applied

19. On PC3, verify that the employee role can access the "server" host (10.254.1.21). The ping
should be successful.
Optional steps: Test access for user-role contractor
You may test the contractor access. Check with your instructor.
20. On PC3 (connected to Access-1 1/1/3), change the 802.1X credentials to:
a. Username: icx-contractor
b. Password: aruba123

356 Task 10-5: Basic 802.1X authentication with a single user

 21. On PC1, check that ClearPass has been configured to return the Aruba-User-Role "contractor"
for this user. Check the Output tab’s RADIUS Response for the Access Tracker record.

22. On the switch, review the authentication result.

ICX-T1-Access1-vsa(config)# show aaa authentication port-access dot1x authenticator
interface all client-status

Client 00:50:56:b1:2c:b8, icx-contractor, 1/1/3

=========================================

Lab 10: 802.1X authentication and

Authentication Details

user roles on AOS-CX

----------------------
Status : Authenticated
Type : Pass-Through
EAP-Method : PEAP
Auth Failure reason :
Time Since Last State Change : 536s

Authentication Statistics
-------------------------
Authentication : 1
Authentication Timeout : 0
EAP-Start While Authenticating : 0
EAP-Logoff While Authenticating : 0
Successful Authentication : 1
Failed Authentication : 0
Re-Authentication : 1
Successful Re-Authentication : 1
Failed Re-Authentication : 0
EAP-Start When Authenticated : 1
EAP-Logoff When Authenticated : 0
Re-Auths When Authenticated : 0
Cached Re-Authentication : 0

23. Review the role authorization.

ICX-T1-Access1-vsa(config)# show aaa authentication port-access interface all
client-status

Task 10-5: Basic 802.1X authentication with a single user 357

 Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-contractor

========================================
Session Details
---------------
Port : 1/1/3
Session Time : 54s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 54s ago

Authorization Details
----------------------
Role : contractor
Status : Applied

24. On PC3, verify the contractor role cannot access the "server: host (10.1.1.2 and 101.1.3). The
ping should not be successful.

Task 10-6: Unknown role assignment

Objectives
Test the result of a configuration inconsistency between the RADIUS host and the switch configuration.
From PC3, you will log in with user icx-badrole and verify the switch status.

Steps
Define group for core switches, IP
PC3
1. On PC3, log in with a user that has an incorrect role assignment.
2. On the PC3, change the 802.1X authentication credentials to:
a. Username: icx-badrole
b. Password: aruba123

358 Task 10-6: Unknown role assignment

 3. Enable 802.1X authentication on the switch and ensure it is using the previously defined RADIUS
server group.
ICX-T1-Access1-vsa(config)# show aaa authentication port-access dot1x authenticator
interface all client-status

Client 00:50:56:b1:2c:b8, icx-badrole, 1/1/3

=========================================

Authentication Details
----------------------
Status : Authenticated
Type : Pass-Through
EAP-Method : PEAP
Auth Failure reason :
Time Since Last State Change : 12s

Authentication Statistics
-------------------------
Authentication : 1

Lab 10: 802.1X authentication and

Authentication Timeout : 0

user roles on AOS-CX

EAP-Start While Authenticating : 0
EAP-Logoff While Authenticating : 0
Successful Authentication : 1
Failed Authentication : 0
Re-Authentication : 1
Successful Re-Authentication : 1
Failed Re-Authentication : 0
EAP-Start When Authenticated : 1
EAP-Logoff When Authenticated : 0
Re-Auths When Authenticated : 0
Cached Re-Authentication : 0

4. Review the role assignment.

ICX-T1-Access1-vsa(config)# show aaa authentication port-access interface all
client-status
Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-badrole

=====================================
Session Details
---------------
Port : 1/1/3
Session Time : 772s
IPv4 Address :
IPv6 Address :
Device Type :

Task 10-6: Unknown role assignment 359

 Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 106s ago
dot1x - Authenticated, 772s ago

Authorization Details
----------------------
Role :
Status : Invalid

5. Disable port 1/1/3 so that it does not interfere with the next lab.
ICX-T1-Access1-vsa(config)# interface 1/1/3
ICX-T1-Access1-vsa(config-if)# shutdown
ICX-T1-Access1-vsa(config-if)# exit

You have completed Lab 10!

360 Task 10-6: Unknown role assignment

Lab 11: MAC-based authentication and user roles

Lab 11: MAC-based authentication and user roles

Lab diagram

Overview
In this lab activity, the MAC authentication feature will be configured. While MAC authentication is not
a secure authentication method, it will be required in most networks, since there will typically be some
devices that cannot perform 802.1X authentication.
By using MAC authentication, some control can be applied to these devices.

Lab 11: MAC-based authentication and user roles 361

Just like with the 802.1X authentication, it is possible to use user roles to combine authentication set-
tings into a logical object group. The lab will also explore the interaction of 802.1X and MAC authen-
tication on the same switch port, and the difference between client-based and device-based
authentication will be demonstrated.
The last part of the lab will show how LLDP device profiles can be used to push the correct con-
figuration to a switch port when, for instance, an Aruba AP is connected. While this is technically not
MAC authentication, the device profile feature is also based on information received by a peer device
via LLDP.

Objectives
n Configure MAC authentication and review single and multiple users on a port.
n Configure user roles with MAC authentication.
n Review the interaction between 802.1X and MAC authentication on the same port.
n Understand client-mode and device-mode authentication.
n Understand the LLDP device profile feature.

Task 11-1: MAC authentication with a single device on a port

Objectives
Set up MAC authentication on the port connected to Access-2. This will allow you to use Access-2 as a
"connected device," and by using the PC that is connected to Access-2, it will be possible to verify the
operation with multiple clients on the same physical port.

362 Task 11-1: MAC authentication with a single device on a port

 Lab diagram

Steps
Disconnect the Access-2 switch from the VSX core
1. Open a terminal session to Access-2. This switch will act as an endpoint during the authen-

Lab 11: MAC-based authentication

tication labs.
2. On Access-2, disable the uplink ports to the VSX Core-1 and Core-2.

and user roles

ICX-Access-2# configure terminal
ICX-Access-2(config)# interface 1/1/25-1/1/26
ICX-Access-2(config-if-<1/1/25-1/1/26>)# shutdown
ICX-Access-2(config-if-<1/1/25-1/1/26>)# exit

3. On Access-2, enable the port 1/1/27 that connects to Access-1. This port is still at its default con-
figuration state: it is an access port in VLAN 1.
ICX-Access-2(config)# interface 1/1/27
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit

Enable MAC authentication on Access-1

Access-1
4. Open a terminal session to Access-1 and enter configuration mode.

Task 11-1: MAC authentication with a single device on a port 363

 5. Change the hostname to include avp.
ICX-T1-Access1-vsa(config)# hostname ICX-T1-Access1-avp
ICX-T1-Access1-avp(config)#

6. Enable MAC authentication on the switch and ensure it is using the previously defined RADIUS
server group.
ICX-T1-Access1-avp(config)# aaa authentication port-access mac-auth radius server-
group cppm
ICX-T1-Access1-avp(config)# aaa authentication port-access mac-auth enable

7. Assign port 1/1/27 to VLAN 1. In this lab, it is simply used as the base landing VLAN in case the
RADIUS server does not assign a VLAN. There are no DHCP server or other resources in this
VLAN in this example.
ICX-T1-Access1-avp(config)# interface 1/1/27
ICX-T1-Access1-avp(config-if)# vlan access 1

8. Enter the mac-auth context and enable MAC-auth on the port.

ICX-T1-Access1-avp(config-if)# aaa authentication port-access mac-auth
ICX-T1-Access1-avp(config-if-macauth)# enable
ICX-T1-Access1-avp(config-if-macauth)# exit

9. Enable the port.

ICX-T1-Access1-avp(config-if)# no shutdown
ICX-T1-Access1-avp(config-if)# exit

10. Verify that the MAC address of the Access-2 switch is now authenticated. The ClearPass system
has been configured to assign the MAC OUI range of the switch to VLAN 11.

It make take a few moments for Access-2 to generate some traffic; repeat the fol-
lowing command until the authentication shows up. This should occur within about
30 seconds.

ICX-T1-Access1-avp(config)# show aaa authentication port-access mac-auth interface

1/1/27 client-status

Port Access Client Status Details

Client 10:4f:58:fc:b2:40, 104f58fcb240, 1/1/27

=========================================

Authentication Details
----------------------
Status : Authenticated
Auth-Method : chap
Auth Failure reason :
Time Since Last State Change : 105s

364 Task 11-1: MAC authentication with a single device on a port

 Authentication Statistics
-------------------------
Authentication : 1
Authentication Timeout : 0
Successful Authentication : 1
Failed Authentication : 0
Re-Authentication : 0
Successful Re-Authentication : 0
Failed Re-Authentication : 0
Re-Auths When Authenticated : 0
Cached Re-Authentication : 0

11. Confirm the MAC address on the port is now dynamically learned on VLAN 11 by reviewing the
mac-address-table.
ICX-T1-Access1-avp(config)# show mac-address-table
MAC age-time : 300 seconds
Number of MAC addresses : 11

MAC Address VLAN Type Port

--------------------------------------------------------------
02:02:00:00:01:00 1 dynamic lag255
b8:d4:e7:40:6d:00 1 dynamic lag255
b8:d4:e7:40:8e:00 1 dynamic lag255
10:4f:58:fc:b2:40 11 port-access-security 1/1/27
b8:d4:e7:40:8e:00 11 dynamic lag255
00:50:56:b1:fd:6a 11 dynamic 1/1/1
02:02:00:00:01:00 11 dynamic lag255
b8:d4:e7:40:6d:00 11 dynamic lag255
b8:d4:e7:40:8e:00 12 dynamic lag255
02:02:00:00:01:00 12 dynamic lag255

Lab 11: MAC-based authentication

b8:d4:e7:40:6d:00 12 dynamic lag255

12. For this initial MAC authentication lab, ClearPass returns standard RADIUS IETF VLAN assign-

and user roles

ment attributes. These are dynamically assigned into a role on the switch. Review the author-
ization of this MAC address:
ICX-T1-Access1-avp(config)# show aaa authentication port-access interface 1/1/27
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 10:4f:58:fc:b2:40, 104f58fcb240

======================================
Session Details
---------------
Port : 1/1/27
Session Time : 245s

Task 11-1: MAC authentication with a single device on a port 365

 IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Not attempted, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 245s ago

Authorization Details
----------------------
Status : Applied

13. Review the role details to discover the assigned RADIUS attributes.
ICX-T1-Access1-avp(config)# show port-access role radius

Role Information:
Attributes overridden by RADIUS are prefixed by '*'.

Name : RADIUS_1453543606
Type : radius
----------------------------------------------
Access VLAN : 11

Task 11-2: Verify access with two devices connected on same port
Objectives
This task is optional and can be done if time permits. Check with your instructor. If you skip this task,
you can move to the next task.
In this task, the PC that is connected to Access-2 will be authenticated as well. This will result in two
untagged devices that are authenticated on the same physical port, but they are still assigned to dif-
ferent VLANs. This is also known as MAC-Based VLAN (MBV), since the switch assigns the traffic to the
correct VLAN based on the authenticated client MAC address.
Initially, two clients (PC4 and Access-2) will be connected to the same port 1/1/27 on Access-1. Only
one of these two clients will be able to come online, since there is a default client limit of one. Next, this
client limit will be increased so both clients can come online at the same time.

366 Task 11-2: Verify access with two devices connected on same port
 Lab diagram

Steps
Access-2
1. On the Access-2 switch, enable port 1/1/4 and assign it to VLAN 1. This is the port that connects

Lab 11: MAC-based authentication

to PC4.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# vlan access 1

and user roles

ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit

PC4
2. Using the remote lab dashboard, connect to PC4.
3. Open Network Connections and look for the Lab NIC.

Make sure you select the Lab NIC and not the DO NOT TOUCH interface.

4. Bounce the Lab NIC interface (disable/enable). This will trigger the DHCP client to send out a
request.
Access-2

Task 11-2: Verify access with two devices connected on same port 367
 5. Verify on Access-2 that a MAC address is learned on port 1/1/4. The MAC will probably start
with 00:50:56, which is the range used by VMware to generate MAC addresses for the VMs.
ICX-Access-2(config)# show mac-address-table
MAC age-time : 300 seconds
Number of MAC addresses : 5

MAC Address VLAN Type Port

--------------------------------------------------------------
b8:d4:e7:40:8e:00 1 dynamic 1/1/27
b8:d4:e7:40:6d:00 1 dynamic 1/1/27
02:02:00:00:01:00 1 dynamic 1/1/27
00:50:56:b1:f3:31 1 dynamic 1/1/4
00:50:56:b1:fd:6a 1 dynamic 1/1/27

Access-1
6. Review the active clients on port 1/1/27.
ICX-T1-Access1-avp(config)# show aaa authentication port-access interface 1/1/27
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 10:4f:58:fc:b2:40, 104f58fcb240

======================================
Session Details
---------------
Port : 1/1/27
Session Time : 1848s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Not attempted, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 1848s ago

Authorization Details
----------------------
Status : Applied

a. Question: How many authenticated clients are there on the interface?

______________________________________________________________________________________________
___________________________

368 Task 11-2: Verify access with two devices connected on same port
 b. Answer: Only one client is authenticated, even though two clients (the Access-2 switch
and the client PC4) are connected to the port.
7. Review the MAC-address table on Access-1, using the detail option word. Look for the Denied
column. This reveals that the MAC-address of the client has been seen on the port but is not
allowed to become active.

In the following output, it can be either the PC4 or the Access-2 MAC address that is
"denied" on port 1/1/27. This depends on which MAC address was authenticated on
the port; the other MAC address will be denied.
This is because the switch applies a default client limit of one client on each switch
port.

ICX-T1-Access1-avp(config)# show mac-address-table detail

MAC age-time : 300 seconds
Number of MAC addresses : 11

MAC Address VLAN Type Port Age Denied never_ageout

------------------------------------------------------------------------
88:3a:30:97:b6:00 1 port-access-security 1/1/27 300 true false
00:50:56:b1:f3:31 1 port-access-security 1/1/27 300 true false
...
88:3a:30:97:b6:00 12 port-access-security 1/1/27 300 false false
...

8. Now, increase the client limit to ensure multiple clients; can be authenticated on the same switch
port.
9. On Access-1, enter the interface 1/1/27 context and increase the client limit to three. Reset the

Lab 11: MAC-based authentication

interface to trigger the Access-2 switch to send some packets.
ICX-T1-Access1-avp(config)# interface 1/1/27
ICX-T1-Access1-avp(config-if)# aaa authentication port-access client-limit 3

and user roles

ICX-T1-Access1-avp(config-if)# shutdown
ICX-T1-Access1-avp(config-if)# no shutdown

10. On PC4, disable and enable the Lab NIC again.

11. On Access-1, there should now be two clients authenticated on the same port.
ICX-T1-Access1-avp(config-if)# show aaa authentication port-access interface 1/1/27
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:f3:31, 005056b1f331

======================================

Task 11-2: Verify access with two devices connected on same port 369
 Session Details
---------------
Port : 1/1/27
Session Time : 9s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Not attempted, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 9s ago

Authorization Details
----------------------
Status : Applied

Client 10:4f:58:fc:b2:40, 104f58fcb240

======================================
Session Details
---------------
Port : 1/1/27
Session Time : 62s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Not attempted, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 62s ago
Authorization Details
----------------------
Status : Applied

ICX-T1-Access1-avp(config-if)#

In case Access-2 is not listed as a client, bounce the VLAN 1 Layer 3 interface to trig-
ger some DHCP traffic.
ICX-Access-2(config)# interface vlan 1
ICX-Access-2(config-if)# shutdown
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config)# exit

370 Task 11-2: Verify access with two devices connected on same port
 12. Review the RADIUS attributes that were pushed to the client PC MAC-auth by checking the
radius roles.
ICX-T1-Access1-avp(config-if)# show port-access role radius

Role Information:
Attributes overridden by RADIUS are prefixed by '*'.

Name : RADIUS_1453543606
Type : radius
----------------------------------------------
Access VLAN : 11

Name : RADIUS_1576327855
Type : radius
----------------------------------------------
Access VLAN : 12

13. Review the updated MAC address table on port 1/1/27. Notice how both MAC addresses of
Access-2 and PC4 are now active, but each has been assigned to its own VLAN, based on the
instructions of the RADIUS server.
ICX-T1-Access1-avp(config-if)# show mac-address-table interface 1/1/27
MAC age-time : 300 seconds
Number of MAC addresses : 1

MAC Address VLAN Type Interface

-------------------------------------------------------------------
10:4f:58:fc:b2:40 11 port-access-security 1/1/27
00:50:56:b1:f3:31 12 port-access-security 1/1/27

Lab 11: MAC-based authentication

This demonstrates that multiple untagged devices can be concurrently active on the
same physical port, each with their own network access security settings applied to
them.

and user roles

14. Review the authentication and attributes on the ClearPass system. On the ClearPass Access
tracker, use Access Tracker to verify that two authentications were processed.

Task 11-2: Verify access with two devices connected on same port 371
 15. Open the MAC-auth entry for MAC 005056 (the PC4 VM) and click Input to review the attrib-
utes that are used for MAC authentication.

16. Check the Output tab and click RADIUS Response to see the VLAN that was returned to the
switch. Close Request Details.

17. Open the second MAC authentication entry (for the Access-2 switch) and review the Output set-
tings.

372 Task 11-2: Verify access with two devices connected on same port
Task 11-3: Aruba user role-based access
Objectives
Similar to the 802.1X authentication, MAC authentication also supports the use of user roles that are
defined on the switch. User roles on the switch have the advantage of grouping all the relevant access
settings (VLAN, ACL, QoS, POE priority) into a single logical object. This simplifies the RADIUS server
configuration, since the RADIUS server only needs to assign the role to the switch, while the switch
knows the configuration of that role.
In this lab, the Access-1 switch will be assigned the dev-switch role, while the PC connected to the

Lab 11: MAC-based authentication

Access-2 switch will be assigned the employee role.
In the previous lab (Configuring 802.1X), the employee role was already defined, so those steps are not

and user roles

included here. This task will define the new user role for the Access-2 switch and show that the role can
also be used to control both tagged and untagged access for the user role.

Task 11-3: Aruba user role-based access 373

Lab diagram

Steps
Access-1
1. Open a terminal connection to Access-1 and enter configuration mode.
2. If you did not complete the previous optional task, increase the client limit on port 1/1/27. Other-
wise, move to the next step.
ICX-T1-Access1-avp(config)# interface 1/1/27
ICX-T1-Access1-avp(config-if)# aaa authentication port-access client-limit 3
ICX-T1-Access1-avp(config-if)# exit

You can verify the current interface configuration using show running interface
1/1/27 command and check if the client limit was applied.

3. Define a new port-access user role named "dev-switch." Provide the role a VLAN trunk with
native VLAN 11, and allowed VLANs 11, 12, and 13.
ICX-T1-Access1-avp(config)# port-access role dev-switch
ICX-T1-Access1-avp(config-pa-role)# vlan trunk native 11
ICX-T1-Access1-avp(config-pa-role)# vlan trunk allowed 11,12,13
ICX-T1-Access1-avp(config-pa-role)# exit

374 Task 11-3: Aruba user role-based access

 4. On Access-1, change the hostname, replacing the "avp" the hostname with "vsa."
ICX-T1-Access1-avp(config)# hostname ICX-T1-Access1-vsa
ICX-T1-Access1-vsa(config)#

The hostname is used as the NAS-identifier. ClearPass has been pre-configured to

look for the value "vsa" in the NAS-identifier to return the Aruba-User-Role VSA
attributes that are needed for this lab.

5. On Access-1 switch, disable and enable port 1/1/27.

ICX-T1-Access1-vsa(config)# interface 1/1/27
ICX-T1-Access1-vsa(config-if)# shutdown
ICX-T1-Access1-vsa(config-if)# no shutdown
ICX-T1-Access1-vsa(config-if)# exit

You may need to generate some traffic to trigger the MAC-auth on the clients, that is, the
Access-2 switch and the PC connected to it.
Access-2
6. On Access-2, disable and enable the VLAN 1 IP interface; this will send out a DHCP request.
ICX-Access-2(config)# interface vlan 1
ICX-Access-2(config-if-vlan)# shutdown
ICX-Access-2(config-if-vlan)# no shutdown
ICX-Access-2(config-if-vlan)# exit

PC4
7. On PC4, connected to Access-2, disable and enable the Lab NIC.

This is important: since PC4 may be assigned to a different VLAN, it needs to renew

Lab 11: MAC-based authentication

its IP address.

and user roles

Access-1
8. On Access-1 switch, review the authenticated clients and the role that was assigned to the cli-
ents.
ICX-T1-Access1-vsa(config)# show aaa authentication port-access interface 1/1/27
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 10:4f:58:fc:b2:40, 104f58fcb240

======================================
Session Details
---------------

Task 11-3: Aruba user role-based access 375

 Port : 1/1/27
Session Time : 458s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Not attempted, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 458s ago

Authorization Details
----------------------
Role : dev-switch
Status : Applied

Client 00:50:56:b1:f3:31, 005056b1f331

======================================
Session Details
---------------
Port : 1/1/27
Session Time : 81s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated Auth Precedence : dot1x - Not
attempted, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 81s ago

Authorization Details
----------------------
Role : employee
Status : Applied

9. Review the VLAN port status of port 1/1/27.

ICX-T1-Access1-vsa(config)# show vlan port 1/1/27

-------------------------------------------------------------------------------
VLAN Name Mode Mapping
-------------------------------------------------------------------------------
11 VLAN11 native-untagged port-access,mbv
12 VLAN12 trunk port-access
13 VLAN13 trunk port-access

376 Task 11-3: Aruba user role-based access

 Overridden VLAN list: 1

Question: What is the listed method for the tagged VLAN — for example, VLAN 12— assign-
ment mapping?
Answer: VLAN 12 is assigned by the port-access module, while a manual VLAN trunk would be
listed as mapped by the 'port' configuration, as can be seen for VLAN 1.

Task 11-4: OPTIONAL—client-mode versus device-mode port

authentication
Objectives
In the previous task, it was demonstrated that multiple devices can be connected to the same switch
port, and each device can be assigned its own network access policy by using Aruba user roles.
However, sometimes it may not be desired to authenticate each device on the port, for example, if the
connected device itself is responsible for performing authentication.
This would apply, for example, to Aruba Instant APs (IAPs) that are connected to a switch port. With an
AP, the wireless traffic will be forwarded by the AP as either tagged or untagged traffic to the switch
port. This is also referred to as "local breakout at the AP" or "bridging at the AP level." The result is that
the switch port will actually see all the MAC addresses that are connected to the IAP device.
The IAP itself is responsible for handling the authentication, so it would perform 802.1X authentication
with the wireless clients. But then, the traffic is forwarded as regular traffic on the switch port, so the
switch would also attempt to perform authentication of this client. Since the 802.1X traffic of the client
is terminated at the IAP, the switch would attempt to perform MAC authentication for the client MAC
address.

Lab 11: MAC-based authentication

This is unnecessary and confusing, since ClearPass would see the same MAC address as 802.1X authen-
ticated on the IAP and MAC-authenticated on the switch port.

and user roles

For this scenario, the switch can be set to "port-based" authentication, that is, device mode. When a spe-
cific device (such as an IAP or an access switch in a meeting room) is connected to the switch port, the
switch will open the port for all traffic, so it will not perform MAC authentication for the other MAC
addresses seen off of the port anymore.
In this task, you will change the user role of the Access-2 switch "dev-switch" to become a role that
operates as "Device-mode." When the switch completes its authentication, any device connected to the
switch will automatically be allowed access to the network as well. In this lab, Access-2 is not actually
performing any authentication itself for PC4, but it simply demonstrates the concept of "device-mode"
authentication.

Task 11-4: OPTIONAL—client-mode versus device-mode port authentication 377

Steps
Access-2
1. Open Access-2 and disable the port to the PC. This is done to ensure that the Access-2 switch’s
MAC address will be guaranteed to be the first seen MAC address on the port.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# shutdown

Access-1: Change the role

2. On Access-1, modify the user role for dev-switch.
ICX-T1-Access1-vsa(config)# port-access role dev-switch
ICX-T1-Access1-vsa(config-pa-role)# auth-mode device-mode
ICX-T1-Access1-vsa(config-pa-role)# exit

3. Reset port 1/1/27.

ICX-T1-Access1-vsa(config)# interface 1/1/27
ICX-T1-Access1-vsa(config-if)# shutdown
ICX-T1-Access1-vsa(config-if)# no shutdown
ICX-T1-Access1-vsa(config-if)# exit

4. Verify the connected switch has authenticated.

ICX-T1-Access1-vsa(config)# show aaa authentication port-access interface 1/1/27
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 10:4f:58:fc:b2:40, 104f58fcb240

======================================
Session Details
---------------
Port : 1/1/27
Session Time : 44s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Not attempted, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 44s ago

Authorization Details
----------------------

378 Task 11-4: OPTIONAL—client-mode versus device-mode port authentication

 Role : dev-switch
Status : Applied

Access-2
On Access-2, enable the PC port to verify it passes network access without authentication.
5. Enable port 1/1/4 of the PC again.
ICX-Access-2(config-if)# no shutdown

PC4
6. On the PC4, disable and enable the Lab NICinterface.
Access-1
7. On Access-1, verify the MAC address table shows two MAC addresses on interface 1/1/27, and
the Denied status is "false." This means these MAC addresses have access to the network.
ICX-T1-Access1-vsa(config)# show mac-address-table detail
MAC age-time : 300 seconds
Number of MAC addresses : 13

MAC Address VLAN Type Port Age Denied never_

ageout
--------------------------------------------------------------------------------------------
-
10:4f:58:fc:b2:40 1 port-access-security 1/1/27 300 true false
b8:d4:e7:40:8e:00 1 dynamic lag255 300 false false
02:02:00:00:01:00 1 dynamic lag255 300 false false
b8:d4:e7:40:6d:00 1 dynamic lag255 300 false false
10:4f:58:fc:b2:40 11 port-access-security 1/1/27 300 false false
00:50:56:b1:f3:31 11 port-access-security 1/1/27 300 false false
b8:d4:e7:40:8e:00 11 dynamic lag255 300 false false

Lab 11: MAC-based authentication

<...output omitted...>

PC1

and user roles

8. Navigate to ClearPass’s Access Tracker from PC1.

Question: How many authentication events are there for the last test?

Task 11-4: OPTIONAL—client-mode versus device-mode port authentication 379

 Answer: Only one authentication was done by the switch. The role that was assigned contains
the auth-mode: device-mode: device option, so no other authentications are needed on this port.
Revert configuration
Access-1
9. On Access-1, change the dev-switch role back to client-based and disable the port.
ICX-T1-Access1-vsa(config)# port-access role dev-switch
ICX-T1-Access1-vsa(config-pa-role)# auth-mode client-mode
ICX-T1-Access1-vsa(config-pa-role)# exit
ICX-T1-Access1-vsa(config)# interface 1/1/27
ICX-T1-Access1-vsa(config-if)# shutdown
ICX-T1-Access1-vsa(config-if)# exit

Access-2
10. On Access-2, disable port 1/1/4 to PC4.
ICX-Access-2(config-if)# shutdown
ICX-Access-2(config-if)# exit

Task 11-5: Authentication priority order with combined MAC-auth and

802.1X
Objectives
This task will show how a port that combines 802.1X and MAC authentication will handle the combined
authentication of a device.
For each MAC address that connects to the switch, only one authentication method can be active to
control the network access. When a MAC address comes online, the switch will either apply the role that
was received for the MAC authentication or the role that was received for the 802.1X authentication,
but never both at the same time.
Since 802.1X is a more secure authentication method than MAC-auth, the switch will, by default, give
the 802.1X role precedence over the MAC-auth role.
In a real-world deployment, the administrator should realize that a PC with an 802.1X configuration will
only start the 802.1X process when it has booted. During the boot process, the PC may already send
some frames that may trigger MAC authentication on the switch port. A few seconds later, the 802.1X
process would also succeed, and the 802.1X role would overrule the MAC-auth role.
In this task, this behavior will be observed by enabling MAC-auth on port 1/1/3 of Access-1. The PC
that performs 802.1X will first be authenticated using MAC-auth. Then, the 802.1X supplicant will be
enabled, so the 802.1X role will overrule the MAC-auth role.

380 Task 11-5: Authentication priority order with combined MAC-auth and 802.1X
Lab diagram

Steps
Disable the 802.1X supplicant on PC3 (connected to port 1/1/3 on Access-1)
1. Open a session to PC3.

Lab 11: MAC-based authentication

2. Get the properties for the Lab NIC > Authentication and uncheck the Enable IEEE 802.1X
authentication checkbox. Confirm the message that saved credentials will be deleted, if promp-

and user roles

ted.

Task 11-5: Authentication priority order with combined MAC-auth and 802.1X 381
 Enable MAC-auth on Access-1
3. On Access-1, configure port 1/1/3 for MAC-auth.
ICX-T1-Access1-vsa(config)# interface 1/1/3
ICX-T1-Access1-vsa(config-if)# aaa authentication port-access mac-auth enable

4. Reset the port.

ICX-T1-Access1-vsa(config-if)# shutdown
ICX-T1-Access1-vsa(config-if)# no shutdown
ICX-T1-Access1-vsa(config-if)# exit

5. On PC3, disable and enable the Lab NIC.

6. On Access-1, follow the client authentication status.
ICX-T1-Access1-vsa(config-if)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8
========================
Session Details
---------------
Port : 1/1/3
Session Time : 5s
IPv4 Address :
IPv6 Address :
Device Type :

382 Task 11-5: Authentication priority order with combined MAC-auth and 802.1X
 Authentication Details
----------------------
Status : Authenticating
Auth Precedence : dot1x - Authenticating, mac-auth - Not attempted
Auth History :

Authorization Details
----------------------
Role :
Status :

With the default timers, it may take several minutes before the 802.1X times out and
performs the MAC-auth. During testing, about three minutes were observed.

Eventually, the switch will consider that 802.1X has failed and it will perform MAC-auth.

The following output is for reference only: you do not need to wait for this timeout in
the lab. You can move to the next step.

ICX-T1-Access1-vsa(config-if)# show aaa authentication port-access interface 1/1/3

client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, 005056b12cb8

======================================

Lab 11: MAC-based authentication

Session Details
---------------
Port : 1/1/3

and user roles

Session Time : 257s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Unauthenticated, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 93s ago
dot1x - Unauthenticated, Supplicant-Timeout, 93s ago

Authorization Details
----------------------

Task 11-5: Authentication priority order with combined MAC-auth and 802.1X 383
 Role : employee
Status : Applied

Adjust the timers to achieve faster MAC-authentication

7. Configure updated timers for the 802.1X authenticator on port 1/1/3.
ICX-T1-Access1-vsa(config-if)# aaa authentication port-access dot1x authenticator
ICX-T1-Access1-vsa(config-if-dot1x-auth)# eapol-timeout 30
ICX-T1-Access1-vsa(config-if-dot1x-auth)# max-eapol-requests 1
ICX-T1-Access1-vsa(config-if-dot1x-auth)# max-retries 1
ICX-T1-Access1-vsa(config-if-dot1x-auth)# exit

These are the validated timers when the labs were developed. Adjust these timers
based on the requirements of the deployment.

8. Review the resulting port configuration.

ICX-T1-Access1-vsa(config-if)# show running-config current-context
interface 1/1/3
no shutdown
no routing
vlan access 1
aaa authentication port-access dot1x authenticator
eapol-timeout 30
max-eapol-requests 1
max-retries 1
enable
aaa authentication port-access mac-auth
enable
exit

9. Disable and enable the port.

ICX-T1-Access1-vsa(config-if)# shutdown
ICX-T1-Access1-vsa(config-if)# no shutdown

10. Verify the authentication status. It may help to disable/enable the Lab NIC on the client PC3 to
generate some client traffic.
11. On Access-1, repeat the show aaa authentication port-access interface 1/1/3 client-
status command to follow the state transitions.

If you use the repeat command on the switch, the repeat loop can be stopped using
the Ctrl-c key combination.

ICX-T1-Access1-vsa(config-if)# show aaa authentication port-access interface 1/1/3

client-status

Port Access Client Status Details

384 Task 11-5: Authentication priority order with combined MAC-auth and 802.1X
 RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, 005056b12cb8

======================================
Session Details
---------------
Port : 1/1/3
Session Time : 63s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Unauthenticated
Auth Precedence : dot1x - Unauthenticated, mac-auth - Unauthenticated
Auth History : mac-auth - Authenticated, 1s ago
dot1x - Unauthenticated, Supplicant-Timeout, 1s ago

Authorization Details
----------------------
Role :
Status :
ICX-T1-Access1-vsa(config-if)# repeat delay 5

Once the first frame from the client was received:

ICX-T1-Access1-vsa(config-if)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

Lab 11: MAC-based authentication

Client 00:50:56:b1:7a:37
============================
Session Details

and user roles

---------------
Port : 1/1/3
Session Time : 1s

Authentication Details
----------------------
Status : Authenticating
Auth Precedence : dot1x - Initialized, mac-auth - Not attempted

While the 802.1X is retrying:

ICX-T1-Access1-vsa(config-if)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

Task 11-5: Authentication priority order with combined MAC-auth and 802.1X 385
 Client 00:50:56:b1:7a:37
============================
Session Details
---------------
Port : 1/1/3
Session Time : 3s

Authentication Details
----------------------
Status : Authenticating
Auth Precedence : dot1x - Authenticating, mac-auth - Not attempted

Once the 802.1X authentication is considered "failed," it will take about 60 seconds with the con-
figured timers for MAC-auth to be performed.
ICX-Tx-Access1-vsa(config-if)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

Client 00:50:56:b1:7a:37, 005056b17a37

============================
Session Details
---------------
Port : 1/1/3
Session Time : 63s

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Unauthenticated, mac-auth - Authenticated

Authorization Details
----------------------
Role : employee
Status : Applied

12. If you used the repeat command, enter Ctrl-c to stop the output.
This ensures that any device that is not 802.1X-capable, such as IoT devices, will still be able to
access the network using MAC-auth.
Notice that the current role of the device is "employee": this was assigned by the MAC-auth
authentication process.

386 Task 11-5: Authentication priority order with combined MAC-auth and 802.1X
Task 11-6: Verify 802.1X authentication precedence over MAC-auth
In the next steps, the 802.1X default precedence over MAC-auth will be demonstrated. This means that
in case both MAC-auth and 802.1X succeed, the 802.1X authentication method will control the final
access for the client device.
Diagram

Lab 11: MAC-based authentication

1. On PC3, enable 802.1X again, making sure to enter the credentials again.

and user roles

a. Username: icx-contractor
b. Password: aruba123

Task 11-6: Verify 802.1X authentication precedence over MAC-auth 387

 2. On Access-1, disable and re-enable interface 1/1/3 to trigger a new user authentication.
ICX-T1-Access1-vsa(config-if)# shutdown
ICX-T1-Access1-vsa(config-if)# no shutdown

3. Check the authenticated client status.

ICX-T1-Access1-vsa(config-if)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-contractor

========================================
Session Details
---------------
Port : 1/1/3
Session Time : 5s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 5s ago

Authorization Details
----------------------
Role : contractor
Status : Applied

388 Task 11-6: Verify 802.1X authentication precedence over MAC-auth

 Question: What is the role that was applied to the client?
Answer: The role is "contractor." This is based on the 802.1X authentication, since 802.1X
authentication has precedence over a successful MAC authentication.
Optional step: Verify combination of failed 802.1X and successful MAC-auth
These steps are optional and can be done if time permits. Check with your instructor. In the next
steps, you will see that in case a device fails 802.1X authentication, it can still succeed with MAC-
auth and get controlled network access based on MAC-auth.
Diagram

Lab 11: MAC-based authentication

and user roles
4. On PC3, update the 802.1X credentials on the Lab NIC to incorrect credentials:
a. Username: icx-contractor
b. Password: bad
5. On Access-1, verify the result.
ICX-T1-Access1-vsa(config-if)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Task 11-6: Verify 802.1X authentication precedence over MAC-auth 389

 Client 00:50:56:b1:2c:b8, 005056b12cb8
======================================
Session Details
---------------
Port : 1/1/3
Session Time : 523s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Held, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 2s ago
dot1x - Unauthenticated, Server-Reject, 2s ago
dot1x - Authenticated, 523s ago

Authorization Details
----------------------
Role : employee
Status : Applied

6. Wait a few seconds and repeat the command until the 802.1X authentication has failed.
ICX-T1-Access1-vsa(config-if)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, 005056b12cb8

======================================
Session Details
---------------
Port : 1/1/3
Session Time : 624s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Unauthenticated, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 103s ago
dot1x - Unauthenticated, Server-Reject, 103s ago
dot1x - Authenticated, 624s ago

390 Task 11-6: Verify 802.1X authentication precedence over MAC-auth

 Authorization Details
----------------------
Role : employee
Status : Applied

Task 11-7: OPTIONAL—device profiles with LLDP

This task is optional and can be done if time permits. Check with your instructor. If you skip this task,
you can move to the next task.

Objectives
In this task, the AOS-CX device profiles will be demonstrated. This is not a security feature but a con-
venience feature, similar to MAC-auth.
In this case, instead of using the client MAC address for authentication, like MAC-auth, it is possible to
configure a switch port based on the incoming LLDP or CDP messages. Since many network devices
support LLDP or CDP, this means that the switch port of those devices can be easily provisioned based
on the received LLDP communication from these network devices.
LLDP is more difficult to spoof compared to a client MAC address, but it should still be understood that
there is no actual authentication happening; with a more advanced toolset, the LLDP messages can still
be spoofed. This is why the HPE Aruba Networking Device Profiles feature is considered a "con-
venience" feature.
Some examples for real-world deployment:
n Aruba AP is connected to any switch port. The switch assigns a device profile with the correct
VLAN untagged and tagged states.
n Any vendor AP that supports LLDP or CDP is connected to any switch port. The switch assigns a

Lab 11: MAC-based authentication

device profile with the correct VLAN untagged and tagged states.
n Any vendor media device, such as a conference room controller, that supports LLDP or CDP can

and user roles

now automatically be assigned to the correct VLAN.
All of these examples are handled by the switch itself; they do not require a RADIUS server or other
authentication infrastructure. While it is possible to have the same results with 802.1X or MAC-auth,
not every customer may be willing to setup the RADIUS infrastructure. In that case, device profiles can
assist to simplify the life of the network administrator.
In this task, the Access-2 switch will be used as the "test LLDP" device that is connected to Access-1.
Based on the Access-2 LLDP communication, the switch port on Access-1 will be automatically con-
figured with the correct settings based on the device profile that will be prepared.

Task 11-7: OPTIONAL—device profiles with LLDP 391

Lab diagram

Steps
Collect information of the peer LLDP device
Access-1
1. Open a terminal session on Access-1 and enter configuration mode.
2. Change the hostname, replacing the "vsa" the hostname with "lldp."
ICX-T1-Access1-vsa(config)# hostname ICX-T1-Access1-lldp
ICX-T1-Access1-lldp(config)#

The hostname is used as the NAS-identifier. ClearPass has been pre-configured to

look for the value "lldp" in the NAS-identifier; in this case, it will return an Access-
Reject for the MAC authentication. This is required for this lab, since the local device
profile will be used to assign the user role instead of the RADIUS server.

3. Enable port 1/1/27; this is the port connected to Access-2.

ICX-T1-Access1-lldp(config)# interface 1/1/27
ICX-T1-Access1-lldp(config-if)# no shutdown
ICX-T1-Access1-lldp(config-if)# exit

392 Task 11-7: OPTIONAL—device profiles with LLDP

 4. Review the current LLDP neighbors.
ICX-T1-Access1-lldp(config)# show lldp neighbor-info

LLDP Neighbor Information

=========================

Total Neighbor Entries : 3

Total Neighbor Entries Deleted : 0
Total Neighbor Entries Dropped : 0
Total Neighbor Entries Aged-Out : 0

LOCAL-PORT CHASSIS-ID PORT-ID PORT-DESC TTL

SYS-NAME
--------------------------------------------------------------------------------------------
---------------
1/1/25 b8:d4:e7:40:6d:00 1/1/1 access1 120
ICX-Core-1
1/1/26 b8:d4:e7:40:8e:00 1/1/1 access1 120
ICX-Core-2
mgmt 00:23:89:bb:73:4a GigabitEthernet2/0/23 T13-6300-A-OOBM 120
P54-OOBM-Fanout

Question: Is the Access-2 switch listed as an LLDP neighbor?

Answer: No. On ports with port-access authentication enabled, LLDP packets are disabled by
default. LLDP would start to operate once a device has been successfully authenticated.
5. Enable LLDP packets on the port-access protected interface. Review the port-access options;
next, enable LLDP BPDUs.
ICX-T1-Access1-lldp(config)# interface 1/1/27
ICX-T1-Access1-lldp(config-if)# aaa authentication port-access allow-?
allow-cdp-auth Allow or block authentication on CDP BPDU. (Default:

Lab 11: MAC-based authentication

allow)
allow-cdp-bpdu Allow or block CDP BPDU. (Default: block)

and user roles

allow-cdp-proxy-logoff Enables or disables CDP TLV processing (Default:
Disabled)
allow-lldp-auth Allow or block authentication on LLDP BPDU. (Default:
allow)
allow-lldp-bpdu Allow or block LLDP BPDU. (Default: block)
ICX-T1-Access1-lldp(config-if)# aaa authentication port-access allow-lldp-bpdu
ICX-T1-Access1-lldp(config-if)# exit

6. Wait up to 30 seconds, then review the LLDP neighbors. On port 1/1/27, there should be an
LLDP neighbor now.
ICX-T1-Access1-lldp(config)# show lldp neighbor-info

LLDP Neighbor Information

=========================

Total Neighbor Entries : 4

Task 11-7: OPTIONAL—device profiles with LLDP 393

 Total Neighbor Entries Deleted : 0
Total Neighbor Entries Dropped : 0
Total Neighbor Entries Aged-Out : 0

LOCAL-PORT CHASSIS-ID PORT-ID PORT-DESC TTL

SYS-NAME
--------------------------------------------------------------------------------------------
---------------
1/1/25 b8:d4:e7:40:6d:00 1/1/1 access1 120
ICX-Core-1
1/1/26 b8:d4:e7:40:8e:00 1/1/1 access1 120
ICX-Core-2
1/1/27 10:4f:58:fc:b2:40 1/1/27 1/1/27 120
ICX-Access-2
mgmt 00:23:89:bb:73:4a GigabitEthernet2/0/23 T13-6300-A-OOBM 120
P54-OOBM-Fanout

7. Review the details for the neighbor on interface 1/1/27. The device profile can be applied to the
chassis-name and the chassis-description information.

It is also possible to assign the device profile based on a vendor-specific LLDP TLV,
but that feature is less frequently implemented. The HPE Aruba Networking APs,
AOS-S switch, and AOS-CX switches do report a specific vendor OUI, so it is possible
to apply the vendor OUI filter for those devices.
In this lab, the assignment will be done based on the LLDP system description. The
Access-2 switch is a specific switch model, and the AOS-CX switches report their
model code (Jxxxx) in the LLDP system description.
Take note of the Jxxxx code in the system description in this lab guide: it is JL668A
or JL660A (Pod 11).

The lab assumes that the core switches are using a different model number than the
access switches. If your lab is using the same model number, it is possible to use the
system name (access) instead of the model number.

ICX-T1-Access1-lldp(config)# show lldp neighbor-info 1/1/27

Port : 1/1/27
Neighbor Entries : 1
Neighbor Entries Deleted : 0
Neighbor Entries Dropped : 0
Neighbor Entries Aged-Out : 0
Neighbor System-Name : ICX-Access-2
Neighbor System-Description : Aruba JL668A FL.10.13.1000
Neighbor Chassis-ID : 10:4f:58:fc:b2:40
Neighbor Management-Address : 10.1.1.5
Chassis Capabilities Available : Bridge, Router

394 Task 11-7: OPTIONAL—device profiles with LLDP

 Chassis Capabilities Enabled : Bridge, Router
Neighbor Port-ID : 1/1/27
Neighbor Port-Desc : 1/1/27
Neighbor Port VLAN ID : 1
Neighbor Port VLAN Name : DEFAULT_VLAN_1
Neighbor Port MFS : 1500
Link aggregation supported : Yes
Link aggregation enabled : No
Aggregation port ID : 0
TTL : 120

Neighbor Mac-Phy details

Neighbor Auto-neg Supported : true
Neighbor Auto-Neg Enabled : false
Neighbor Auto-Neg Advertised : Other
Neighbor MAU type : 10 GIGBASEER

Neighbor EEE information : DOT3

Neighbor TX Wake time : 0 us
Neighbor RX Wake time : 0 us
Neighbor Fallback time : 0 us
Neighbor TX Echo time : 0 us
Neighbor RX Echo time : 0 us

8. Define a new role that will be used in this task. The device profile feature also uses the same
port-access roles that are used by the 802.1X and MAC-auth modules. For the purpose of this
lab, a dedicated role will be defined.

For this lab demo, device-mode authentication is enabled. This means that the port
will be "open" for any MAC-address after this device profile has been applied. This

Lab 11: MAC-based authentication

would apply to HPE Aruba Networking Instant APs, for example, since the AP will be
performing the wireless user authentication.

and user roles

ICX-T1-Access1-lldp(config)# port-access role demo-lldp-switch
ICX-T1-Access1-lldp(config-pa-role)# auth-mode device-mode
ICX-T1-Access1-lldp(config-pa-role)# vlan trunk native 11
ICX-T1-Access1-lldp(config-pa-role)# vlan trunk allowed 11,12
ICX-T1-Access1-lldp(config-pa-role)# exit

Define an LLDP group to match the peer LLDP device

With an LLDP group, the administrator can assign LLDP devices based on the reported system
description, system name, or a vendor OUI TLV in the LLDP frame.
In this lab, the assignment will be done based on the LLDP system description. The Access-2
switch is a specific switch model, and the AOS-CX switches report their model code (Jxxxx) in the
LLDP system description.

Task 11-7: OPTIONAL—device profiles with LLDP 395

 9. Define a new LLDP group profile. This LLDP group will match on the LLDP system description of
the neighbor LLDP switch.
ICX-T1-Access1-lldp(config)# port-access lldp-group demo-switch

10. Review the selection criteria of the match command.

ICX-T1-Access1-lldp(config-lldp-group)# match ?
sys-desc Configure LLDP system description.
sysname Configure LLDP system name.
vendor-oui Configure LLDP vendor OUI.
<cr>

11. Define a new match criteria based on the LLDP neighbor system description.
ICX-T1-Access1-lldp(config-lldp-group)# match sys-desc JL668A

All students should verify the model number of Access-1 and Access-2. For example,
in Pod 13, they are model JL668A.

12. Review the current configuration of the LLDP group and exit the group context.
ICX-T1-Access1-lldp(config-lldp-group)# show running-config current-context
port-access lldp-group demo-switch
seq 10 match sys-desc JL668A
ICX-T1-Access1-lldp(config-lldp-group)# exit

Define a device profile to bind the LLDP group to a user role

13. Define a new port-access device profile.
ICX-T1-Access1-lldp(config)# port-access device-profile dev-aoscx-switch

14. Bind the LLDP group and the user role to this device profile and enable it.
ICX-T1-Access1-lldp(config-device-profile)# associate role demo-lldp-switch
ICX-T1-Access1-lldp(config-device-profile)# associate lldp-group demo-switch
ICX-T1-Access1-lldp(config-device-profile)# enable
ICX-T1-Access1-lldp(config-device-profile)# exit

15. Review the current device profile configuration.

ICX-T1-Access1-lldp(config)# show port-access device-profile

Profile Name : dev-aoscx-switch

LLDP Groups : demo-switch
CDP Groups :
MAC Groups :
Role : demo-lldp-switch
State : Enabled

16. Reset the port connected to Access-2.

ICX-T1-Access1-lldp(config)# interface 1/1/27
ICX-T1-Access1-lldp(config-if)# shutdown

396 Task 11-7: OPTIONAL—device profiles with LLDP

 ICX-T1-Access1-lldp(config-if)# no shutdown
ICX-T1-Access1-lldp(config-if)# exit

17. Review the device-profile status for all interfaces.

ICX-T1-Access1-lldp(config)# show port-access device-profile interface all
Port 1/1/27, Neighbor-Mac 10:4f:58:fc:b2:40
Profile Name: : dev-aoscx-switch
LLDP Group: : demo-switch
CDP Group: :
MAC Group: :
Role: : demo-lldp-switch
State: : applied
Failure Reason: :

18. Review that no other successful authentication device is online on this port.
ICX-T1-Access1-lldp(config)# show aaa authentication port-access interface 1/1/27
client-status
No aaa clients found.

19. Review that the port VLAN status is now active based on the VLAN settings of the device profile
user role.
ICX-T1-Access1-lldp(config)# show vlan port 1/1/27

-------------------------------------------------------------------------------
VLAN Name Mode Mapping
-------------------------------------------------------------------------------
11 VLAN11 native-untagged port-access
12 VLAN12 trunk port-access

Overridden VLAN list: 1

Lab 11: MAC-based authentication

This method can be used to auto-provision the port and VLAN settings for many
LLDP device types.

and user roles

20. Disable the device profile feature.
ICX-T1-Access1-lldp(config)# port-access device-profile dev-aoscx-switch
ICX-T1-Access1-lldp(config-device-profile)# disable
ICX-T1-Access1-lldp(config-device-profile)# exit

21. Verify that the VLAN configuration of port 1/1/27 has been reverted.
ICX-T1-Access1-lldp(config)# show vlan port 1/1/27

-------------------------------------------------------------------------------
VLAN Name Mode Mapping
-------------------------------------------------------------------------------
1 DEFAULT_VLAN_1 access port

22. Remove the allow-lldp-bpdu feature on port 1/1/27.

Task 11-7: OPTIONAL—device profiles with LLDP 397

 ICX-T1-Access1-lldp(config)# interface 1/1/27
ICX-T1-Access1-lldp(config-if)# no aaa authentication port-access allow-lldp-bpdu
ICX-T1-Access1-lldp(config-if)# exit

Task 11-8: Save checkpoint configuration

Objectives
This task is required; upcoming lab activities are based on this configuration.

Steps
Access-1
1. On Access-1, change the hostname back to the default lab hostname.
ICX-T1-Access1-lldp(config)# hostname ICX-T1-Access1

2. Save checkpoint icx-lab11-mac.

ICX-T1-Access1(config)# copy running-config checkpoint icx-lab11-mac
Copying configuration: [Success]

Access-2
3. Save checkpoint icx-lab11-mac.
ICX-Access-2(config)# copy running-config checkpoint icx-lab11-mac
Copying configuration: [Success]

You have completed Lab 11!

398 Task 11-8: Save checkpoint configuration

Lab 12.1: Integration with HPE Aruba Networking
ClearPass Policy Manager Platform downloadable
user roles

Lab 12.1: Integration with HPE Aruba Networking ClearPass Policy Manager Platform downloadable
user roles

Lab diagram

Overview
This lab requires the completion of the 802.1X (Lab 10) and MAC authentication (Lab 11) lab activ-
ities.
This lab activity will demonstrate how ClearPass downloadable user roles can be used to simplify the
deployment of the authentication user roles to the switches. The roles are only defined on the
ClearPass host, and they will be downloaded on the fly, as needed, by the access switches.
This means that the administrator still needs to understand the concept of roles. However, it is no
longer necessary to check that all the switches have the latest configuration/policy version of all these

Lab 12.1: Integration with HPE Aruba Networking ClearPass Policy Manager Platform downloadable user roles 399
user roles in their configuration, since this will be done automatically for the administrator. This will
also reduce the operational configuration file of the access switches, since these roles are not saved in
the configuration file.
The switch will download the definition from ClearPass as part of the authentication process using the
REST API. Therefore, credentials must be configured on the switch to access the ClearPass host to
download the role configuration.

Objectives
n Define secure HTTPS access between the switch and ClearPass by importing the Trust Anchor
(TA) certificate.
n Define the credentials to access the ClearPass REST API.
n Verify the operation of the downloadable user roles.

Task 12.1-1: CPPM REST API communication

Objectives
n Review the requirements on the switch to validate the CPPM certificate: check NTP and the name
resolution for the certificate subject name.
n Verify CPPM has been configured with a read-only admin user account.
On the Access-1 switch, install the CPPM CA certificate as a "trust anchor." This will enable the switch
to validate the CPPM server certificate. This procedure can be done using the CLI or using NetEdit.
On the Access-1 switch, configure the (read-only) admin account that the switch should use to access
the CPPM REST API when downloading user roles.

The AOS-CX switch should be able to verify the validity of the ClearPass server certificate.
This requires a valid time to be set on the switch, and the switch should have a valid cer-
tificate chain (trust anchor) to validate the certificate on the ClearPass server.

Steps
1. On PC3 (connected to Access-1 port 1/1/3), change the 802.1X authentication credentials to:
n Username: icx-employee
n Password: aruba123

400 Task 12.1-1: CPPM REST API communication

 2. Open a terminal session on Access-1 and enter configuration mode.
3. Verify the time.
ICX-T1-Access1(config)# show clock
Mon Jul 15 18:06:15 EDT 2024
System is configured for timezone : US/Eastern

The switch time should be accurate and in sync with the American Eastern Standard
time zone.

4. Verify the NTP status.

ICX-T1-Access1(config)# show ntp status
NTP Status Information

NTP : Enabled
NTP DHCP : Enabled
NTP Authentication : Disabled
NTP Server Connections : Using the default VRF
Aruba Networking ClearPass Policy
Lab 12.1: Integration with HPE

System time : Mon Jul 15 18:08:20 EDT 2024

NTP uptime : 4 days, 1 hours, 44 minutes, 42 seconds

NTP Synchronization Information

NTP Server : 10.254.1.21 at stratum 4

Task 12.1-1: CPPM REST API communication 401

 Poll interval : 1024 seconds
Time accuracy : Within -0.009121 seconds
Reference time : Mon, Jul 15 2024 18:02:35.493 as per US/Eastern

Trust Anchor (TA) installation

5. Review the default TA configuration. There should be no root CAs installed by default.
ICX-T1-Access1(config)# show crypto pki ta-profile

TA Profile Name TA Certificate Revocation Check

-------------------------------- -------------------- ----------------

6. Define a new TA profile "cppm."

ICX-T1-Access1(config)# crypto pki ta-profile cppm

7. Run the import command.

ICX-T1-Access1(config-ta-cppm)# ta-certificate import
Paste the certificate in PEM format below, then hit enter and ctrl-D:

8. On PC1, open the ICX-Files folder on the desktop.

9. Open the cert file lab 12.1 - clearpass - root - ca.txt and copy the contents.

402 Task 12.1-1: CPPM REST API communication

 10. Paste the certificate to the Access-1 console.

If you are unable to paste the content to Access-1, pressing Ctrl-Alt-Shift will open a
clipboard. Paste the content into the clipboard, press Ctrl-Alt-Shift to close the clip-
Aruba Networking ClearPass Policy

board, and then paste the contents into Access-1.

Lab 12.1: Integration with HPE

ICX-T1-Access1(config-ta-cert)#-----BEGIN CERTIFICATE-----
ICX-T1-Access1(config-ta-cert)#
ICX-T1-Access1(config-ta-cert)#MIIEGTCCAwGgAwIBAgIBEjANBgkqhkiG9w0BAQ0FADCBkzELMAkGA1UEBhMCVVMx
ICX-T1-Access1(config-ta-cert)#EzARBgNVBAgMCkNhbGlmb3JuaWExEjAQBgNVBAcMCVN1bm55dmFsZTEYMBYGA1UE
ICX-T1-Access1(config-ta-cert)#CgwPQXJ1YmEgRWR1Y2F0aW9uMQwwCgYDVQQLDANFZHUxEDAOBgNVBAMMB0FDU1Ag
ICX-T1-Access1(config-ta-cert)#Q0ExITAfBgkqhkiG9w0BCQEWEmFjc3AtY2FAYWNzcC5sb2NhbDAeFw0yMDAxMjcx
ICX-T1-Access1(config-ta-cert)#ODE5NDRaFw0zMDAxMjcxODQ5NDRaMIGTMQswCQYDVQQGEwJVUzETMBEGA1UECAwK

Task 12.1-1: CPPM REST API communication 403

 ICX-T1-Access1(config-ta-cert)#Q2FsaWZvcm5pYTESMBAGA1UEBwwJU3Vubnl2YWxlMRgwFgYDVQQKDA9BcnViYSBF
ICX-T1-Access1(config-ta-cert)#ZHVjYXRpb24xDDAKBgNVBAsMA0VkdTEQMA4GA1UEAwwHQUNTUCBDQTEhMB8GCSqG
ICX-T1-Access1(config-ta-cert)#SIb3DQEJARYSYWNzcC1jYUBhY3NwLmxvY2FsMIIBIjANBgkqhkiG9w0BAQEFAAOC
ICX-T1-Access1(config-ta-cert)#AQ8AMIIBCgKCAQEAwwpyOsCEii0f8eSNjHI6WcEQ+EOKHYMoNROGWy2YmhFqcAEf
ICX-T1-Access1(config-ta-cert)#V0Df9Mto0tPIJGth3CmQcZELBz+8WpSdaJvllqj9QbNJZNklT44al5Sbv59pOyUM
ICX-T1-Access1(config-ta-cert)#XsnJj+KwUmLWL/SUvxM8R81pAK36wRAyAeNr+plVj1RpIxUl2xHsQv8qMTypShkw
ICX-T1-Access1(config-ta-cert)#YfEs+mCl/VKZ8iWtoupRX+iuWUhBXj39+8gM7c+8sSiImWYmkLlqQfXzxN9TQ4hj
ICX-T1-Access1(config-ta-cert)#Xc6Hk4ovxUri2YzO1ZXtx5zJYKz/AqlZ1gfUdBKyNFZwRPRt4F0mLKMsQnyG19Cg
ICX-T1-Access1(config-ta-cert)#j10sC1vzysqjfXk7KbrJU+XE0z4meiNxWmemmQIDAQABo3YwdDAdBgNVHQ4EFgQU
ICX-T1-Access1(config-ta-cert)#XYYnMTUJlJxEmOqT8QoA1pYb8KEwDwYDVR0PAQH/BAUDAweGADAPBgNVHRMBAf8E
ICX-T1-Access1(config-ta-cert)#BTADAQH/MDEGA1UdJQQqMCgGCCsGAQUFBwMJBggrBgEFBQcDAgYIKwYBBQUHAwEG
ICX-T1-Access1(config-ta-cert)#CCsGAQUFBwMDMA0GCSqGSIb3DQEBDQUAA4IBAQAjLKEREPA/QGVdP5xi1tcMe7LI
ICX-T1-Access1(config-ta-cert)#jaG987qoFmCwi9ocDhfMMggNnOny9m0uW4GNsHeBSPIcTgN+JYjjBuN4+V5Iz74Z
ICX-T1-Access1(config-ta-cert)#LUqHP2YwZFqwIWtNr3agBEievCj0AQNSdFNwKU7BS6B0BaT2RBWyy6x5U7ljBKAl
ICX-T1-Access1(config-ta-cert)#OQH5xzcNyRpetbTIdf0q5Aa0kC7QmbYYGxBamwbzS5luU+akQy2HD9vr2bi+X5Aq
ICX-T1-Access1(config-ta-cert)#jVBKTUkTPuFPQhQroXp2VI3ldIPJYaWz1Gk5NTAQkv/9bImdr5f4NfJrMI/kubjy
ICX-T1-Access1(config-ta-cert)#bdXTI+LyPtiLpkbF2dDCN8GBKovNQFvhlXtGT4b/umOzSS2AzHcVj/SldVw6
ICX-T1-Access1(config-ta-cert)#-----END CERTIFICATE-----

11. When the paste is complete, press the CTRL-D key combination. This will instruct the switch to
parse the pasted cert and show the subject name. Now confirm that this cert is okay.
ICX-T1-Access1(config-ta-cert)# crtl + d
The certificate you are importing has the following attributes:
Subject: C = US, ST = California, L = Sunnyvale, O = Aruba Education, OU = Edu, CN
= ACSP CA, emailAddress = acsp-ca@acsp.local
Issuer: C = US, ST = California, L = Sunnyvale, O = Aruba Education, OU = Edu, CN
= ACSP CA, emailAddress = acsp-ca@acsp.local
Serial Number: 0x12
TA certificate import is allowed only once for a TA profile
Do you want to accept this certificate (y/n)? y

12. Exit the context and verify that the TA profile is installed.
ICX-T1-Access1(config-ta-cppm)# exit
ICX-T1-Access1(config)# show crypto pki ta-profile

TA Profile Name TA Certificate Revocation Check

-------------------------------- -------------------- ----------------
cppm Installed, valid disabled

CPPM REST API read-only user account

A read-only administrator has been defined on ClearPass. In the next steps, you will verify that
this administrator has been defined.
13. Using the PC1 management station, open a connection to ClearPass on https://10.254.1.23/tips.
a. Username: icx-admin1
b. Password: aruba123
14. Navigate to Administration > Users and Privileges > Admin Users.
15. Verify that an admin account has been created named "duradmin" (downloadable user role
admin), with read-only privileges.

404 Task 12.1-1: CPPM REST API communication

 In this lab environment, a read-only administrator is used. ClearPass also provides a
more restrictive admin privilege Aruba User Role Download that can be assigned to
the download account. This role can only access ClearPass using the REST API, and it
can only read the enforcement profiles.

Define the ClearPass credentials to access the REST API

16. On the Access-1 switch, define the REST API credentials on the ClearPass RADIUS server object
with the name "cppm.arubatraining.com."
ICX-T1-Access1(config)# radius-server host cppm.arubatraining.com clearpass-
username duradmin clearpass-password plaintext aruba123

17. Verify the running configuration for RADIUS server lines; there should be only one RADIUS
server.
ICX-T1-Access1(config)# show running-config | include radius-server
radius-server tracking user-name icx-radius-track password ciphertext
AQBapQigcgGUUVgijVS4PZfzCh60bJRm3oCYmRJ5yptBrq/VCAAAAOBgmFAxlMU6
radius-server host cppm.arubatraining.com key ciphertext
AQBape3Xwfby5RSI9s19du+71MHbiz8xNsFqkjBlk/zX2owYCAAAAHNgsNDp+pSj tracking enable
clearpass-
username duradmin clearpass-password ciphertext
AQBapcTCqknqxO39UgIyhenwnbEIk9IQEX0NLZKEiHtnGzS8CAAAAKOYejX8PiFn

18. You can also review the RADIUS list in a different format.
Aruba Networking ClearPass Policy

ICX-T1-Access1(config)# show radius-server detail

Lab 12.1: Integration with HPE

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

Shared-Secret: None
Timeout: 5
Auth-Type: pap
Retries: 1
Initial TLS Connection Timeout: 30

Task 12.1-1: CPPM REST API communication 405

 TLS Timeout: 5
Tracking Time Interval (seconds): 300
Tracking Retries: 1
Tracking User-name: icx-radius-track
Tracking Password: AQBapQigcgGUUVgijVS4PZfzCh60bJRm3oCYmRJ5yptBrq/VCAAAAOBgmFAxlMU6
Status-Server Time Interval (seconds): 300
Number of Servers: 1
AAA Server Status Trap: Disabled

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

Server-Name : cppm.arubatraining.com
Auth-Port : 1812
Accounting-Port : 1813
VRF : default
TLS Enabled : No
Shared-Secret :
AQBape3Xwfby5RSI9s19du+71MHbiz8xNsFqkjBlk/zX2owYCAAAAHNgsNDp+pSj
Timeout : 5
Retries : 1
Auth-Type : pap
Server-Group:Priority : cppm:1
ClearPass-Username : duradmin
ClearPass-Password :
AQBapcTCqknqxO39UgIyhenwnbEIk9IQEX0NLZKEiHtnGzS8CAAAAKOYejX8PiFn
Tracking : enabled
Tracking-Mode : any
Reachability-Status : reachable, Since Mon Jul 15 18:36:20 EDT 2024
Tracking-Last-Attempted : Mon Jul 15 18:41:20 EDT 2024
Next-Tracking-Request : 290 seconds

Task 12.1-2: CPPM user role definitions

Objectives
There are no configuration steps in this task. You will review the user role configuration that has been
prepared on the ClearPass Policy Manager.
Downloadable user roles have been pre-defined for:
n Employees
n Contractors

Steps
Access-2
1. Use PC1 to open a session to the ClearPass server.
2. Navigate to Configuration > Enforcement > Profiles.

406 Task 12.1-2: CPPM user role definitions

 3. Enter dur in the Name filter and select Go.

4. Open icx-aruba-dur-employee. The RADIUS VSA attribute used here is Aruba-CPPM-Role. The
data contains the CLI commands that define the complete user role.

In the enforcement profile, the user-role name is not important; in the example, "dur"
is used. When the profile is downloaded by the switch, the switch will put the
provided configuration under a role name that will be based on the Enforcement
Policy name, which is "icx-aruba-dur-employee" in this example.

Aruba Networking ClearPass Policy

Lab 12.1: Integration with HPE

5. Click Cancel to close the Employee profile.

6. Click the icx-aruba-dur-contractor profile to see the configuration.

Task 12.1-2: CPPM user role definitions 407

 The port-access role name is again "dur," but as stated before, this name will not be
used in the operational status in the switch, since every downloadable role will have
its unique name based on the ClearPass enforcement profile name. For this example,
it would be "icx-aruba-dur-contractor."

7. Click Cancel to close the Contractor profile.

Task 12.1-3: Testing 802.1X DUR with employee and contractor

Objectives
In this task, the downloadable user role will be tested using the 802.1X client PC (PC3). Once the user
has authenticated, ClearPass will return the name of the downloadable user role, and the switch will
dynamically collect the details of the role using a REST API connection over HTTPS to ClearPass.
In the lab setup, ClearPass must be made aware that it needs to return the Aruba-CPPM-role, so the
hostname on the switch must be updated to include "dur" (this is based on the services that were pre-
defined on the Lab CPPM server).

Steps
Testing employee access
1. Open a terminal session to Access-1 and enter configuration mode.
2. Change the hostname to include the string "dur." This will ensure the correct ClearPass policy
rules are used for the downloadable user roles.

408 Task 12.1-3: Testing 802.1X DUR with employee and contractor
 ICX-T1-Access1(config)# hostname ICX-T1-Access1-dur
ICX-T1-Access1-dur(config)#

The hostname is used as the NAS-identifier in the access request to ClearPass.

ClearPass has been pre-configured to look for the value "dur" in the NAS-identifier to
return the downloadable user roles that are needed for this lab.

3. Review the current configuration of port 1/1/3. This port should have 802.1X enabled (MAC
authentication can also be enabled, but it will not be tested on this port).
ICX-T1-Access1-dur(config)# show run interface 1/1/3
interface 1/1/3
no shutdown
no routing
vlan access 1
aaa authentication port-access dot1x authenticator
eapol-timeout 30
max-eapol-requests 1
max-retries 1
enable
aaa authentication port-access mac-auth
enable
exit

4. On PC3, connected to Access-1 port 1/1/3, enable 802.1X on the Lab NIC, and configure the
employee credentials (refer to the 802.1X lab for instructions on how to do this):
n Username: icx-employee
n Password: aruba123

Troubleshooting steps in case the authentication fails:

a. Verify the TA cert import.
b. Verify the hostname.
c. Verify the user credentials.
d. Verify the switch log (show logging -r -n 20) for any errors.

5. Review the authenticated users on port 1/1/3.

ICX-T1-Access1-dur(config)# show aaa authentication port-access interface 1/1/3
Aruba Networking ClearPass Policy
Lab 12.1: Integration with HPE

client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-employee

Task 12.1-3: Testing 802.1X DUR with employee and contractor 409
 ======================================
Session Details
---------------
Port : 1/1/3
Session Time : 13845s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 62s ago
dot1x - Unauthenticated, Server-Reject, 164s ago

Authorization Details
----------------------
Role : icx_aruba_dur_employee-3044-7
Status : Applied

6. Next, review the current roles on the switch. Notice how the local, radius, and clearpass (DUR)
roles all coexist on the same switch.
ICX-T1-Access1-dur(config)# show port-access role

Role Information:
Attributes overridden by RADIUS are prefixed by '*'.

Name : contractor
Type : local
----------------------------------------------
Access VLAN : 11
Policy : contractor

Name : demo-lldp-switch
Type : local
----------------------------------------------
Authentication Mode : device-mode
Native VLAN : 11
Allowed Trunk VLANs : 11-12

Name : dev-switch
Type : local
----------------------------------------------
Authentication Mode : client-mode
Native VLAN : 11
Allowed Trunk VLANs : 11-13

410 Task 12.1-3: Testing 802.1X DUR with employee and contractor
 Name : employee
Type : local
----------------------------------------------
Access VLAN : 11
Policy : employee

Name : icx_aruba_dur_employee-3044-7
Type : clearpass
Status: Completed
----------------------------------------------
Access VLAN : 11
Policy : employee_icx_aruba_dur_employee-3044-7

7. Next, review just the ClearPass downloaded roles.

ICX-T1-Access1-dur(config)# show port-access role clearpass

Role Information:

Name : icx_aruba_dur_employee-3044-7
Type : clearpass
Status: Completed
----------------------------------------------
Access VLAN : 11
Policy : employee_icx_aruba_dur_employee-3044-7

Question: What is the VLAN assigned to this role? _______________________________________________

________________________________
Answer: VLAN access 11
8. Next, review the port-access policies. Between the locally defined policies, there should also be
one downloaded policy.
ICX-T1-Access1-dur(config)# show port-access policy

Access Policy Details:

======================

<output omitted>

Policy Name : employee_icx_aruba_dur_employee-3044-7

Policy Type : Downloaded
Policy Status : Applied
Aruba Networking ClearPass Policy

Base Policy : N/A

Lab 12.1: Integration with HPE

ACL Names : N/A

SEQUENCE CLASS TYPE ACTION

----------- ---------------------------- ---- ----------------------------------
10 any_icx_aruba_dur_employe... ipv4 permit

Question: What is the name of the traffic class in this policy?

Task 12.1-3: Testing 802.1X DUR with employee and contractor 411
 Answer: The IP class name begins with "any_icx_aruba_dur_employee."
9. Next, review the IP classes in the system.
ICX-T1-Access1-dur(config)# show class ip

User Configured ipv4 classes:

=============================

Type Name
Additional Class Parameters
Sequence Comment
Action L3 Protocol
Source IP Address Source L4 Port(s)
Destination IP Address Destination L4 Port(s)
Additional Entry Parameters
-------------------------------------------------------------------------------
IPv4 any
10
match any
any
any
-------------------------------------------------------------------------------
IPv4 any_icx_aruba_dur_employee-3044-7
10
match any
any
any
-------------------------------------------------------------------------------
IPv4 servers
10
match any
any
10.0.1.2

This demonstrates that the downloaded user roles and their member objects are added to the
operational configuration of the switch.
10. Review the running configuration and look for any user roles, policies, or classes with "dur" in the
name.
ICX-T1-Access1-dur(config)# show running-config | include dur
hostname ICX-T1-Access1-dur
radius-server host cppm.arubatraining.com key ciphertext
AQBape3Xwfby5RSI9s19du+71MHbiz8xNsFqkjBlk/zX2owYCAAAAHNgsNDp+pSj tracking enable
clearpass-
username duradmin clearpass-password ciphertext
AQBapcTCqknqxO39UgIyhenwnbEIk9IQEX0NLZKEiHtnGzS8CAAAAKOYejX8PiFn

Question: Are there any user roles in the configuration?

412 Task 12.1-3: Testing 802.1X DUR with employee and contractor
 Answer: No, the ClearPass downloadable user roles are always downloaded on the fly and are
not stored in the switch’s configuration. This demonstrates that the downloaded user roles and
their member objects are added to the switch's operational configuration, but they are not added
to the switch's running or startup configurations.
Verify the contractor DUR
11. On PC3, change the 802.1X credentials to the contractor account:
a. Username: icx-contractor
b. Password: aruba123
12. On the switch, review the authenticated clients on port 1/1/3.
ICX-T1-Access1-dur(config)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-contractor

========================================
Session Details
---------------
Port : 1/1/3
Session Time : 53s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 18s ago
dot1x - Authenticated, 53s ago

Authorization Details
----------------------
Role : icx_aruba_dur_contractor-3042-8
Status : Applied
Aruba Networking ClearPass Policy

13. Review the downloaded roles.

Lab 12.1: Integration with HPE

ICX-T1-Access1-dur(config)# show port-access role clearpass

Role Information:

Name : icx_aruba_dur_contractor-3042-8
Type : clearpass

Task 12.1-3: Testing 802.1X DUR with employee and contractor 413
 Status: Completed
----------------------------------------------
Access VLAN : 11
Policy : contractor_icx_aruba_dur_contractor-3042-
8

Question: Is the employee DUR still available in the role list?

Answer: No. When the last online user with a downloadable user role goes offline, the role is no
longer maintained in the switch memory.
14. Review the policy list.
ICX-T1-Access1-dur(config)# show port-access policy

Access Policy Details:

======================

Policy Name : contractor

Policy Type : Local
Policy Status : Applied
Base Policy : N/A
ACL Names : N/A

SEQUENCE CLASS TYPE ACTION

----------- ---------------------------- ---- ----------------------------------
10 servers ipv4 drop
20 any ipv4 permit

Policy Name : contractor_icx_aruba_dur_contractor-3042-8

Policy Type : Downloaded
Policy Status : Applied
Base Policy : N/A
ACL Names : N/A

SEQUENCE CLASS TYPE ACTION

----------- ---------------------------- ---- ----------------------------------
10 servers_icx_aruba_dur_con... ipv4 drop
20 any_icx_aruba_dur_contrac... ipv4 permit

Policy Name : employee

Policy Type : Local
Policy Status : Applied
Base Policy : N/A
ACL Names : N/A

SEQUENCE CLASS TYPE ACTION

----------- ---------------------------- ---- ----------------------------------
10 any ipv4 permit

414 Task 12.1-3: Testing 802.1X DUR with employee and contractor
 This demonstrates how the complete user-role definition can be downloaded on the fly from the
Policy Manager server.

Task 12.1-4: OPTIONAL—ClearPass DUR configuration and

troubleshooting
This task is optional and can be done if time permits. Check with your instructor.

Objectives
When defining the user role on ClearPass, the administrator should note that:
n The downloadable user role is fully "self-contained." In the role, it can have its own classes,
policies, and captive profile objects.
n The downloadable user role cannot use any classes, policies or captive portal profiles that are loc-
ally defined in the switch. This means that any referenced object in a DUR must be defined within
the ClearPass enforcement profile.
n ClearPass will automatically generate a name for the downloadable user role, which is based on:
l The name of the "Enforcement Profile."
l The ClearPass internal enforcement object ID (3xxx).
l The version number of the "Enforcement Profile". Every time the enforcement profile is
saved on the ClearPass server, the version number will increment with 1.
n In the object names within the downloadable user role, any <space> or hyphen (-) is auto-
matically replaced with an underscore (_).
n It is not allowed to have "comment" lines in the downloadable user role.
n For classes and policies, it is not required to include line numbers. In that case, the line order will
be used.
n It is important to order the objects correctly in the ClearPass Enforcement Profile:
l Classes should be defined before the policy.
l Policy and Captive Portal profiles should be defined before the actual user role.
n The downloadable user role can refer to a "ubt" zone. This is covered in the mobility controller
lab activity.
n The downloadable user role cannot be used to create a ubt zone. That must be done in the
Aruba Networking ClearPass Policy

switch configuration.
Lab 12.1: Integration with HPE

Config version information

Task 12.1-4: OPTIONAL—ClearPass DUR configuration and troubleshooting 415

Every time the enforcement profile is saved in ClearPass, the internal enforcement profile version num-
ber is increased. At the next authentication, ClearPass will return the new version number in the DUR
name to the switch. This ensures both the previous and current versiona of the same enforcement pro-
file can be online at the same time on the switch.
Migration to the new version occurs based on the reauthentication configuration, allowing for a smooth
transition of any ClearPass changes to the actual authenticated devices. When all the devices that were
online on the previous version of the DUR have reauthenticated, the old version of the DUR will auto-
matically disappear from the switch.

Steps
Detailed operation of downloadable user roles
1. Using PC1, open a session to ClearPass and navigate to Configuration > Enforcement > Pro-
files. Open the "icx-aruba-dur-contractor" profile.

Question: What is the name of the enforcement profile? __________________________________________

__________________________
Answer: In this lab, the enforcement profile name is "icx-aruba-dur-contractor."
Question: Why is this name relevant to the switch? _______________________________________________
_________________________
Answer: The name of the downloadable user role on the switch will be based on the enforcement
profile name. Using a meaningful enforcement profile name helps when troubleshooting on the
switch.

416 Task 12.1-4: OPTIONAL—ClearPass DUR configuration and troubleshooting

 2. Navigate to Monitoring > Live Monitoring > Access Tracker and open the latest authen-
tication for user icx-contractor. Check the Output tab.

This seems to suggest that the contents of the DUR are sent to the switch as part of the RADIUS
Access-Accept.
3. On Access-1, review the name of the role on port 1/1/3.
ICX-T1-Access1-dur(config)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-contractor

========================================
Session Details
---------------
Port : 1/1/3
Session Time : 568s
IPv4 Address :
IPv6 Address :
Device Type :
Aruba Networking ClearPass Policy
Lab 12.1: Integration with HPE

Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 568s ago

Task 12.1-4: OPTIONAL—ClearPass DUR configuration and troubleshooting 417

 Authorization Details
----------------------
Role : icx_aruba_dur_contractor-3042-8
Status : Applied

The output demonstrates that the name of the ClearPass enforcement profile is automatically
part of the name of the DUR.
Questions: What other elements exist in the DUR name?
Answer: In this example, the numbers 3042 and 8.
3042: Every enforcement profile in ClearPass has an internal object number; the range starts at
3000. This is the unique identifier of the enforcement profile, while the name makes it easy to
recognize it.
8: This is the version number. Every time an enforcement profile is saved, the version number is
incremented with 1.
The complete DUR consists of:
n Enforcement Profile name
n Enforcement Profile internal object number
n Enforcement Profile version number
When ClearPass receives an authentication request that has an Aruba-CPPM-Role in the result, it
will not send the detailed commands in the RADIUS request, but only a reference name to the cur-
rent enforcement profile.
Example of a RADIUS trace of the Access-Accept sent by ClearPass:

Next, the switch will access the REST API of ClearPass over HTTPS (this required the TA profile
installation) and download the contents of this enforcement profile.

418 Task 12.1-4: OPTIONAL—ClearPass DUR configuration and troubleshooting

 The contents are then installed as a "clearpass role" in the port-access module.
Any names of referenced objects (classes, policies, or captive portal names) are automatically
appended with this generated enforcement-profile DUR name.
This ensures no conflicts can occur between roles or even locally defined roles.
This is an example of the CLI configuration of the contractor role:
class ip any
10 match any any any

class ip servers
10 match any any 10.255.0.200

port-access policy contractor

10 class ip servers action drop
20 class ip any

port-access role dur

associate policy contractor
vlan access 11

4. On the switch, there is also a local "contractor" role, which is also referring to a "servers" class.
Thanks to the appended names, there is no conflict. Review the IP classes on Access-1. Notice
that there are two server classes:
n servers locally defined on the switch during the 802.1X lab activity
n servers_icx_aruba_... part of the downloadable user role
ICX-T1-Access1-dur(config)# show class ip

User Configured ipv4 classes:

=============================

Type Name
Additional Class Parameters
Sequence Comment
Action L3 Protocol
Source IP Address Source L4 Port(s)
Destination IP Address Destination L4 Port(s)
Additional Entry Parameters
-------------------------------------------------------------------------------
IPv4 any
Aruba Networking ClearPass Policy
Lab 12.1: Integration with HPE

10
match any
any
any
-------------------------------------------------------------------------------
IPv4 any_icx_aruba_dur_contractor-3042-8
10

Task 12.1-4: OPTIONAL—ClearPass DUR configuration and troubleshooting 419

 match any
any
any
<output omitted>

This demonstrates that objects in DUR roles will not interfere with each other or with locally
defined roles or objects.

Example of invalid DUR configuration on ClearPass

In the next steps, a DUR that contains an error will be returned to the switch to demonstrate to
the effect in the switch.
A "badrole" DUR has been prepared on the ClearPass system. It will be returned when the "icx-
badrole" user account connects to the network using 802.1X on PC3 (connected to Access-1).
5. On PC3, connected to Access-1, changing the 802.1X credentials to:
n Username: icx-badrole
n Password: aruba123
6. After the authentication completes, check the authentication status on Access-1 switch port
1/1/3.
ICX-T1-Access1-dur(config)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-badrole

=====================================
Session Details
---------------
Port : 1/1/3
Session Time : 277s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 8s ago
dot1x - Authenticated, 277s ago

Authorization Details
----------------------

420 Task 12.1-4: OPTIONAL—ClearPass DUR configuration and troubleshooting

 Role : icx_aruba_dur_badrole-3046-5
Status : Download Failed

Question: What is the status of the role?

Answer: The status is reported as "Download Failed," which indicates some error with the role
processing.
7. Use PC1 to open ClearPass Access Tracker, check the "icx-badrole authentication entry" and
open the Output tab to see the details of the role.

Question: What is wrong with this role example?

Answer: The order of the objects is incorrect. The policy references the "cam-server" class before
it is defined.

Lab cleanup
8. Revert the Access-1 switch hostname to the base hostname.
ICX-T1-Access1-dur(config)# hostname ICX-T1-Access1
ICX-T1-Access1(config)#
Aruba Networking ClearPass Policy
Lab 12.1: Integration with HPE

Task 12.1-4: OPTIONAL—ClearPass DUR configuration and troubleshooting 421

[This page intentionally left blank]

422 Task 12.1-4: OPTIONAL—ClearPass DUR configuration and troubleshooting

Lab 12.2: Integration with HPE Aruba Networking
MC—user-based tunneling with the MC firewall

Lab 12.2: Integration with HPE Aruba Networking MC—user-based tunneling with the MC firewall

Lab diagram

Overview
If you just completed Lab 12.1, the switch configurations are valid and you can start with this lab activ-
ity. This lab activity requires at least the completion of Lab 11 MAC-based authentication and user
roles.
In this lab activity, the AOS-CX switch will be integrated with the mobility controller (MC). The con-
troller licensing and firewall user roles will be reviewed.
On the switch, the connection to the controller will be defined using a gateway zone.
Next, the switch user roles will be updated. The user role will now point to the MC as the "gateway
zone," and a firewall user-role instruction will be included. Once the user has authenticated, the user
and session information will be reviewed on the MC.

Lab 12.2: Integration with HPE Aruba Networking MC—user-based tunneling with the MC firewall 423
Objectives
n Define a connection to the MC for the User-Based Tunneling (UBT).
n Define user roles that use the UBT feature.
n Verify the state and operation of the tunnels on the switch.
n Verify the state and operation of the tunnels on the MC.

Task 12.2-1: Prepare the lab devices

Objectives
This lab requires the completion of the "Integration with CPPM" lab activity. In this task, the MC licenses
and firewall visibility are verified and adjusted as needed.

Steps
1. Open a terminal connection to the MC:
n Username:admin
n Password:aruba123
2. Review that Access Point (AP) and Policy Enforcement Firewall (PEF) licenses have been
installed.
User: admin
Password:
(icx-T13-mc1) [mynode] # show license

License Table
-------------
Key Installed Expires
(Grace period expiry) Flags Service Type
--- --------- ---------
------------------- ----- ------------
nWrEBufn-F4ZwcIi7-x35TArzw-rtsGx0Fx-+xihtiw9-YOg6DlZy-Ifdepg 2020-05-28 10:38:03 Never
E Next Generation Policy Enfor
cement Firewall Module: 16
mMoMyUT5-WP0e7hyT-MwdL/85X-mhpALGVJ-GSUSP29C-pGUz64Q+-+pszjg 2020-05-28 10:37:52 Never
E Access Points: 16

License Entries: 2

Flags: A - auto-generated; E - enabled; S - Subscription; R - reboot/activation key required

to activate; D - Not enabled on license client

Note: Time under 'Installed' for Subscription licenses is the license generation time.
(icx-T13-mc1) [mynode] #

424 Task 12.2-1: Prepare the lab devices

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
3. Verify the PEF license feature has been enabled. This command must be executed at the /mm
context level. In the lab setup, it is expected that this feature has been enabled.
(icx-T13-mc1) [mynode] #cd /mm
(icx-T13-mc1) [mm] #show license-pool-profile-root

License root(/) pool profile

----------------------------
Parameter Value
--------- -----
enable PEFNG feature Enabled
enable RFP feature Disabled
enable ACR feature Disabled
enable WebCC feature Disabled

4. Optional step in case the PEF license feature was not enabled:
(ICX-Tx-MC) [mm] # configure terminal
Enter Configuration commands, one per line. End with CNTL/Z

(ICX-Tx-MC) [mm] (config) # license-pool-profile-root

(ICX-Tx-MC) [mm] (License root(/) pool profile) # pefng-licenses-enable
Please ensure to add licenses before enabling feature bit.

(ICX-Tx-MC) ^[mm] (License root(/) pool profile) # write mem

Saving Configuration...

Configuration Saved.
(ICX-Tx-MC) [mm] (License root(/) pool profile) # exit
(ICX-Tx-MC) [mm] (config) # end

5. Enable the Deep Packet Inspection (DPI) and the application visibility.
(ICX-Tx-MC) [mm] # configure terminal
(ICX-Tx-MC) [mm] (config) # firewall
(ICX-Tx-MC) ^[mm] (config-submode)# dpi
Warning: Application visibility/control is enabled, this change would take effect
after reloading the controller(s) in "/mm"

(ICX-Tx-MC) ^ [mm] (config-submode)# exit

(ICX-Tx-MC) ^ [mm] (config) # firewall-visibility
(ICX-Tx-MC) ^ [mm] (config) # end
(ICX-Tx-MC) ^ [mm] # write memory

Saving Configuration...

Task 12.2-1: Prepare the lab devices 425

 Your mobility controller may have been enabled for deep packet inspection already.
In this case, the controller will log the following message when entering the dpi com-
mand:
Application visibility/control is already enabled in one or more
controllers in "/mm." Changes would take effect after reloading
controllers in "/mm."

You can move on to the next step.

6. Reload the MC to activate the DPI engine.

(ICX-Tx-MC) [mm] #reload
Do you really want to restart the system(y/n): y

It takes about seven to eight minutes for the controller in the lab to reboot.

Task 12.2-2: HPE Aruba Networking MC integration

Objectives
In this task, the MC will be configured with the transit VLAN for the user tunnel. In an earlier version of
UBT, the final VLAN that the wired user would be assigned to on the MC had to exist on the switch as
well.
To simplify the VLAN administration, the current version only needs a single VLAN to transport wired
users via the GRE tunnel to the MC. Once the wired user traffic arrives at the MC, the MC will map the
traffic to the final VLAN, so the MC will do a VLAN rewrite of the transit VLAN to the final user VLAN.
The switch will be configured with the IP address of the MC as the tunneled-node server. In the switch
configuration, this is defined as a "user-based-tunnel" (ubt) zone.

426 Task 12.2-2: HPE Aruba Networking MC integration

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
Diagram

Steps
1. Open a terminal connection to the MC and enter configuration mode.
2. At the /mm level, define VLAN 4000, which is used as the transport VLAN between the switch
and the controller.

This is the transport VLAN inside the IP GRE tunnel between the switch and the MC,
so this VLAN does not need to exist on the intermediate network between the switch
and the MC.

User: admin
Password:
(icx-T13-mc1) ^[mynode] # cd /mm
(icx-T13-mc1) ^[mm] # configure terminal
Enter Configuration commands, one per line. End with CNTL/Z

(icx-T13-mc1) ^[mm] (config) # vlan 4000

(icx-T13-mc1) ^[mm] (config-submode)# end
(icx-T13-mc1) ^[mm] # write memory

Task 12.2-2: HPE Aruba Networking MC integration 427

 Saving Configuration...

Configuration Saved.

It is not strictly required to define the transport VLAN on the MC, if all authenticated
devices are assigned controller firewall user roles that include a VLAN instruction
(this is the method used in this lab activity).
However, if a device is assigned to a firewall user role without VLAN instruction, then
the device would still be in the assigned transport VLAN.
In this case, the transport VLAN should be defined on the MC, and it should be
allowed on the MC uplink VLAN trunk ports to the upstream switch.

Access-1 UBT zone configuration

Define the gateway zone and set the MC IP.
Access-1
3. On Access-1, verify connectivity to the MC with a ping to 10.1.1.6 (gateway IP).
ICX-T1-Access1(config)# ping 10.1.1.6
PING 10.1.1.6 (10.1.1.6) 100(128) bytes of data.
108 bytes from 10.1.1.6: icmp_seq=1 ttl=64 time=27.5 ms
108 bytes from 10.1.1.6: icmp_seq=2 ttl=64 time=0.783 ms
108 bytes from 10.1.1.6: icmp_seq=3 ttl=64 time=0.514 ms
108 bytes from 10.1.1.6: icmp_seq=4 ttl=64 time=0.491 ms
108 bytes from 10.1.1.6: icmp_seq=5 ttl=64 time=1.47 ms

--- 10.1.1.6 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4061ms
rtt min/avg/max/mdev = 0.491/6.157/27.531/10.692 ms

4. Set the IP source interface for UBT packets to this VLAN 1 interface.
ICX-T1-Access1(config)# ip source-interface ubt interface vlan1

5. Define the UBT zone for the MC. In the current release, only one UBT zone is supported. Make
sure to enable the zone.
n Zone name: mc
n Controller IP: 10.1.1.6
ICX-T1-Access1(config)# ubt zone mc vrf default
ICX-T1-Access1(config-ubt-mc)# primary-controller ip 10.1.1.6
ICX-T1-Access1(config-ubt-mc)# enable
ICX-T1-Access1(config-ubt-mc)# exit

6. Verify the UBT zone configuration.

ICX-T1-Access1(config)# show ubt

428 Task 12.2-2: HPE Aruba Networking MC integration

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
Zone Name : mc
UBT Mode : local-vlan
Primary Controller : 10.1.1.6
Backup Controller : ---/---
SAC HeartBeat Interval : 1
UAC KeepAlive Interval : 60
VLAN Identifier : ---/---
VRF Name : default
Wake-on-LAN Enabled-VLANs: -NA-
Admin State : Enabled
PAPI Security Key : Disabled
Operational State : down

Question: What could be a reason for the operational status to be down even though the admin
state shows as up?
Answer: The switch has not yet been configured to use a transport VLAN for the user-tunneled
traffic.
7. Define VLAN 4000 as the UBT transport VLAN.
ICX-T1-Access1(config)# vlan 4000
ICX-T1-Access1(config-vlan-4000)# exit
ICX-T1-Access1(config)# ubt-client-vlan 4000

8. Review the UBT status.

ICX-T1-Access1(config)# show ubt

Zone Name : mc
UBT Mode : local-vlan
Primary Controller : 10.1.1.6
Backup Controller : ---/---
SAC HeartBeat Interval : 1
UAC KeepAlive Interval : 60
VLAN Identifier : 4000
VRF Name : default
Wake-on-LAN Enabled-VLANs: -NA-
Admin State : Enabled
PAPI Security Key : Disabled
Operational State : up

9. On Access-1, verify that the switch has registered with the MC.
ICX-T1-Access1(config)# show ubt state

=====================================================================
Zone mc:
=====================================================================

Local Conductor Server (LCS) State:

Task 12.2-2: HPE Aruba Networking MC integration 429

 LCS Type IP Address State Role
---------------------------------------------------------------------
Primary : 10.1.1.6 ready_for_bootstrap operational_primary

Switch Anchor Controller (SAC) State:

IP Address MAC Address State

-----------------------------------------------------------------
Active : 10.1.1.6 20:4c:03:b1:d4:2a registered

Verify state on MC (gateway)

10. Verify that the switch is listed as a tunneled node.
(icx-T13-mc1) [mm] # show tunneled-node-mgr tunneled-nodes

Tunneled Node Table Entries

---------------------------

Flags: A - Active Switch Anchor Controller(A-SAC),

S - Standby Switch Anchor Controller(S-SAC),
U - Active User Anchor Controller(A-UAC),
X - Standby User Anchor Controller(S-UAC),
C - Convert BC & MC into Unicast,

Name Tunneled Node Mac IP Address Age(d:h:m) Key Tunnel Index SAC IP
Address S-SAC IP Address A-Users S-Users Flags
---- ----------------- ---------- ---------- --- ------------ -------------
- ---------------- ------- ------- -----
ICX-T1-Access1 10:4f:58:f6:e3:80 10.1.1.4 00:00:26 deed tunnel 9 10.1.1.6
0.0.0.0 0 0 AC

11. On the MC, verify the license usage. The output shows that the switch consumes a license on the
controller like an AP.

Only the first columns are displayed on this output example.

(icx-T13-mc1) [mm] # show license-usage

License Clients License Usage for pool /

----------------------------------------
Hostname IP Address Mac addr AP PEF RF Protect
-------- ---------- -------- ---- ---- -----------
icx-T13-mc1 10.1.1.6 20:4c:03:b1:d4:2a 1 1 0

TOTAL 1 1 0

Total no. of clients: 1

12. Review the current datapath tunnels.

430 Task 12.2-2: HPE Aruba Networking MC integration

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
(icx-T13-mc1) [mm] # show datapath tunnel

+----+-------+-----------------------------------------------------+
|SUM/| | | |
|CPU | Addr | Description Value |
+----+-------+-----------------------------------------------------+
| | | |
| G | [000] | Current Entries 9 |
| G | [002] | High Water Mark 9 |
| G | [003] | Maximum Entries 4096 |
| G | [004] | Total Entries 9 |
| G | [007] | Max link length 8 |
+----+-------+-----------------------------------------------------+

Datapath Tunnel Table Entries

-----------------------------

Flags: E - Ether encap, I - Wi-Fi encap, R - Wired tunnel, F - IP fragment OK

W - WEP, K - TKIP, A - AESCCM, G - AESGCM, M - no mcast src filtering
S - Single encrypt, U - Untagged, X - Tunneled node, 1(cert-id) - 802.1X
Term-PEAP
2(cert-id) - 802.1X Term-TLS, T - Trusted, L - No looping, d - Drop
Bcast/Unknown Mcast,
D - Decrypt tunnel, a - Reduce ARP packets in the air, e - EAPOL only
C - Prohibit new calls, P - Permanent, m - Convert multicast, B - Bgw peer
uplink tunnel
n - Convert RAs to unicast(VLAN Pooling/L3 Mobility enabled), s - Split
tunnel
V - enforce user vlan(open clients only), z - Datazone
H - Standby (HA-Lite), u - Cluster UAC tunnel, b - Active AAC tunnel, t -
Cluster s-AAC tunnel
c - IP Compression, g - PAN GlobalProtect Tunnel, w - Tunneled Node
Heartbeat
B - Cluster A-SAC Mcast, G - Cluster S-SAC Mcast, l - Tunneled Node user
tunnel
f - Static GRE Tunnels, k- keepalive enabled, Y - Convert BC/MC to Unicast

# Source Destination Prt Type MTU VLAN Acls

BSSID Decaps Encaps Heartbeats Flags
EncapKBytes DecapKBytes
------ -------------- -------------- --- ---- ---- ---- ---------------------
-- ----------------- ---------- ---------- ---------- ----------
----- ------------- -----------
9 10.1.1.6 10.1.1.4 47 deed 1500 0 0 0 0 0 0
10:4f:58:f6:e3:80 1995 0 1995 TESw

Question: Why is there already a tunnel if there are no clients active? Check the "w" flag.

Task 12.2-2: HPE Aruba Networking MC integration 431

 Answer: This is the keepalive check GRE tunnel. Thanks to this tunnel, all the other tunnels will
not have to perform their own keepalive checks. This concept is similar to the HPE Aruba Net-
working AP GRE data tunnels and keepalive tunnel.

Task 12.2-3: User role configuration on the switch and the MC

Objectives
In this task, the "employee" user role on the switch will be configured to forward the traffic of the
authenticated user to the MC.
First, you will disable Access-1 switch ports 1/1/3 and 1/1/27 so no devices are authenticated.
The hostname will be updated to match the correct ClearPass policies.
On the MC, a new firewall user role will be defined. In this lab, the role will have "full access" to the net-
work, but this will still demonstrate that the client traffic visibility is in the firewall.
Diagram

Steps
Access-1: Disable ports 1/1/3 and 1/1/27, remove VLAN 11
1. Open a terminal session to Access-1 and enter configuration mode.
2. Change the hostname. Add "vsa" at the end.

432 Task 12.2-3: User role configuration on the switch and the MC
 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
ICX-T1-Access1(config)# hostname ICX-T1-Access1-vsa
ICX-T1-Access1-vsa(config)#

The hostname is used as the NAS-identifier in the access request to ClearPass.

ClearPass has been pre-configured to look for the value "vsa" in the NAS-identifier to
return the Aruba VSA Aruba-User-Role attributes that are needed for this lab.

3. Disable the two ports that currently may have active client authentications. These are the ports
connected to PC3 (802.1X on 1/1/3) and PC4 (MAC-auth via Access-2 on 1/1/27).
ICX-T1-Access1-vsa(config)# interface 1/1/3,1/1/27
ICX-T1-Access1-vsa(config-if-<1/1/3,1/1/27>)# shutdown
ICX-T1-Access1-vsa(config-if-<1/1/3,1/1/27>)# exit

4. Remove VLAN 11. The clients will be transported via VLAN 4000 to the MC, and the MC will
assign them to VLAN 11, so the VLAN 11 does not need to exist on the access switch.
ICX-T1-Access1-vsa(config)# no vlan 11

MC: Define an employee role

5. Open a terminal session on the MC and enter configuration mode.
6. Define VLAN 11 at the /mm level.
(icx-T13-mc1) [mynode] # cd /mm
(icx-T13-mc1) [mm] # configure terminal
Enter Configuration commands, one per line. End with CNTL/Z

(icx-T13-mc1) [mm] (config) # vlan 11

(icx-T13-mc1) ^[mm] (config-submode)# exit

7. Define a new user role that will be used for employees. This role has full access to the network.
By sending the traffic through the MC firewall, all traffic can still be inspected and traffic analysis
is available.

The user roles on the mobility controller are different from the user roles on the
switches, since they support firewall features. They could have the same name as on
the switch, but in this lab setup, the name is kept different to make it easier to dif-
ferentiate the different roles.

(icx-T13-mc1) ^[mm] (config) # user-role mc-employee

(icx-T13-mc1) ^[mm] (config-submode)# access-list session allowall
(icx-T13-mc1) ^[mm] (config-submode)# vlan 11
(icx-T13-mc1) ^[mm] (config-submode)# exit
(icx-T13-mc1) ^[mm] (config) # write memory

Saving Configuration...

Configuration Saved.

Task 12.2-3: User role configuration on the switch and the MC 433
 Access-1 : Update employee to redirect traffic to MC using secondary role
8. On the Access-1 switch, update the employee role so traffic is sent to the gateway-zone "mc"
with the secondary role "mc-employee."
ICX-T1-Access1-vsa(config)# port-access role employee
ICX-T1-Access1-vsa(config-pa-role)# gateway-zone zone mc gateway-role mc-employee
ICX-T1-Access1-vsa(config-pa-role)# exit

Task 12.2-4: Test MC integration

Objectives
In this task, the integration will be tested using PC3 (connected to Access-1 port 1/1/3) with 802.1X
authentication.

Steps
1. On Access-1, enable the port 1/1/3.
ICX-T1-Access1-vsa(config)# interface 1/1/3
ICX-T1-Access1-vsa(config-if)# no shutdown
ICX-T1-Access1-vsa(config-if)# exit

2. On PC3, connected to Access-1 port 1/1/3, configure the 802.1X authentication with these cre-
dentials:
n Username: icx-employee
n Password: aruba123
Verification of the status on the switch
3. Verify that the user authentication and role are successfully applied.
ICX-T1-Access1-vsa(config)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, icx-employee

======================================
Session Details
---------------
Port : 1/1/3
Session Time : 32s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details

434 Task 12.2-4: Test MC integration

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
----------------------
Status : dot1x Authenticated
Auth Precedence : dot1x - Authenticated, mac-auth - Not attempted
Auth History : dot1x - Authenticated, 9s ago
dot1x - Authenticated, 32s ago

Authorization Details
----------------------
Role : employee
Status : Applied

4. Review all the UBT users. This shows the MAC address and secondary role (mc-employee) that
will be send to the MC via the PAPI protocol.
ICX-T1-Access1-vsa(config)# show ubt users all

=====================================================================
Displaying All UBT Users for Zone: mc
=====================================================================
Downloaded user roles are preceded by *
Port Mac-Address Tunnel Status Gateway-Role
Failure Reason
-----------------------------------------------------------------------------------
-----------
1/1/3 00:50:56:b1:2c:b8 activated mc-employee ---
/---

5. Review the UBT state.

ICX-T1-Access1-vsa(config)# show ubt state

=====================================================================
Zone mc:
=====================================================================

Local Conductor Server (LCS) State:

LCS Type IP Address State Role

---------------------------------------------------------------------
Primary : 10.1.1.6 ready_for_bootstrap operational_primary

Switch Anchor Controller (SAC) State:

IP Address MAC Address State

-----------------------------------------------------------------
Active : 10.1.1.6 20:4c:03:b1:d4:2a registered

User Anchor Controller(UAC): 10.1.1.6

User Port State Bucket ID Gre Key VLAN

Task 12.2-4: Test MC integration 435

 ----------------------------------------------------------------------------------
00:50:56:b1:2c:b8 1/1/3 registered 37 3 4000

The bucket map is used in an AOS cluster to distribute clients over the cluster con-
trollers. Each client MAC address is hashed and mapped to a bucket ID based on this
hash.

Question: What is the GRE key for this user?

Answer: 3, which is based on the switch port ID.
Verification steps on the MC
6. Review the user-tunnel table. This shows the active (GRE) tunnels and the number of users that
are active on the tunnel.
(icx-T13-mc1) [mm] (config) # show tunneled-node-mgr user-tunnel-table

Tunnel Info Table Entries

-------------------------

u - Untagged VLAN

Tunnel Id Tunneled Node BCMC TO UCast Key MTU Curr Users VLANs
--------- ------------- ------------- ---- ---- ---------- -----
tunnel 10 10.1.1.4 1 3 1500 1 11

Question: What is the key ID?

Answer: The key ID is 3, which is the same GRE key ID that was observed on the switch, based
on the switch port ID.
7. The tunneled-user output shows the active tunneled users.
(icx-T13-mc1) [mm] (config) # show tunneled-node-mgr tunneled-users

Tunneled User Table Entries

---------------------------

Flags: U - User Anchor Controller(UAC),

S - Standby User Anchor Controller(S-UAC),
T - Tagged VLAN,
A - Authenticated on Tunneled Node,
C - Convert BC & MC into Unicast,

User Tunneled User Mac Tunneled Node Mac Vlan UAC IP Address Key Tunnel
Index Flags
---- ----------------- ----------------- ---- -------------- --- ---------
--- -----
icx-employee 00:50:56:b1:2c:b8 10:4f:58:f6:e3:80 4000(11) 10.1.1.6 3 tunnel 10
UAC

436 Task 12.2-4: Test MC integration

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
Question: What is the meaning of the value 4000(11) in the VLAN column?
Answer: The first VLAN, VLAN 4000, is the transport VLAN (inside the GRE tunnel), while the
second VLAN is the actual user VLAN on the MC wired uplink port to the core switch.
8. Review the active datapath tunnels.
(icx-T13-mc1) [mm] (config) #show datapath tunnel

+----+-------+-----------------------------------------------------+
|SUM/| | | |
|CPU | Addr | Description Value |
+----+-------+-----------------------------------------------------+
| | [001] | Tunnel FIB Egress Not Unicast 23 |
| | [004] | Tunnel FIB stale 1 |
+----+-------+-----------------------------------------------------+
| | | |
| G | [000] | Current Entries 10 |
| G | [002] | High Water Mark 10 |
| G | [003] | Maximum Entries 4096 |
| G | [004] | Total Entries 10 |
| G | [007] | Max link length 8 |
| G | [008] | Current Tunnel FIB 1 |
| G | [009] | Tunnel FIB recompute 1 |
+----+-------+-----------------------------------------------------+

Datapath Tunnel Table Entries

-----------------------------

Flags: E - Ether encap, I - Wi-Fi encap, R - Wired tunnel, F - IP fragment OK

W - WEP, K - TKIP, A - AESCCM, G - AESGCM, M - no mcast src filtering
S - Single encrypt, U - Untagged, X - Tunneled node, 1(cert-id) - 802.1X Term-PEAP
2(cert-id) - 802.1X Term-TLS, T - Trusted, L - No looping, d - Drop Bcast/Unknown
Mcast,
D - Decrypt tunnel, a - Reduce ARP packets in the air, e - EAPOL only
C - Prohibit new calls, P - Permanent, m - Convert multicast, B - Bgw peer uplink
tunnel
n - Convert RAs to unicast(VLAN Pooling/L3 Mobility enabled), s - Split tunnel
V - enforce user vlan(open clients only), z - Datazone
H - Standby (HA-Lite), u - Cluster UAC tunnel, b - Active AAC tunnel, t - Cluster s-
AAC tunnel
c - IP Compression, g - PAN GlobalProtect Tunnel, w - Tunneled Node Heartbeat
B - Cluster A-SAC Mcast, G - Cluster S-SAC Mcast, l - Tunneled Node user tunnel
f - Static GRE Tunnels, k- keepalive enabled, Y - Convert BC/MC to Unicast

# Source Destination Prt Type MTU VLAN Acls

BSSID Decaps Encaps Heartbeats Flags
EncapKBytes DecapKBytes
------ -------------- -------------- --- ---- ---- ---- ----------------------- -----
------------ ---------- ---------- ---------- ----------
----- ------------- -----------
9 10.1.1.6 10.1.1.4 47 deed 1500 0 0 0 0 0 0

Task 12.2-4: Test MC integration 437

 10:4f:58:f6:e3:80 11047 0 11047 TESw
10 10.1.1.6 10.1.1.4 47 3 1500 0 0 0 0 0 0
10:4f:58:f6:e3:80 97 24 0 EUPRlY

Question: How many tunnels are active now?_____________________________________________________

______________________
Answer: There are two GRE (Protocol 47) tunnels now:
n One keep-alive tunnel, type "deed"
n One user data tunnel, type "3" (this was based on the switch port ID)
9. Finally, review the regular user table on the MC. This is the user table that would show both wire-
less and wired (tunneled-node) clients.
(icx-T13-mc1) [mynode] # show user
This operation can take a while depending on number of users. Please be patient ....

Users
-----
IP MAC Name Role Age(d:h:m) Auth
VPN link AP name Roaming Essid/Bssid/Phy
Profile Forward mode Type Host Name User Type
---------- ------------ ------ ---- ---------- ----
-------- ------- ------- ---------------
------- ------------ ---- --------- ---------
10.1.11.51 00:50:56:b1:2c:b8 icx-employee mc-employee 00:00:05 Tunneled-User-802.1X
10.1.1.4 Tunneled tunnel 10/10:4f:58:f6:e3:8
0/1/1/3 default-tunneled-user tunnel TUNNELED USER

User Entries: 1/1

Curr/Cum Alloc:1/3 Free:0/2 Dyn:1 AllocErr:0 FreeErr:0

Application visibility on the MC

Since the wired traffic is now passing through the MC, the network administrator now has vis-
ibility in those traffic streams. In the next steps, some traffic will be generated with the wired cli-
ent PC3, and the resulting analysis will be shown on the MC.
10. On PC3, connected to Access-1 port 1/1/3, open a browser, and navigate to 10.1.1.1 (the VSX
core switch). Log in using admin/aruba123.
11. Using the same PC3, open a new browser tab and navigate to 10.1.1.6 (the MC). Log in using
admin/aruba123.

438 Task 12.2-4: Test MC integration

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
12. Navigate to the Dashboard > Traffic Analysis screen and review the active hosts.

13. Select the icx-employee host.

14. Review the details of the traffic sent by this device.

Task 12.2-4: Test MC integration 439

 15. In the top bar, click the wired link under "Clients". The administrator can clearly see the dif-
ference between the wireless and wired clients here.

16. On the MC, more information about the clients can be shown by enabling additional columns.

This example shows the output with the MAC address, OS, Authentication, and Port enabled:

440 Task 12.2-4: Test MC integration

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
Detailed firewall sessions for the wired client MC
17. Switch to the MC terminal. Review the firewall sessions for the client by using the client IP
address as a filter. Replace <client-ip> with the previously noted client IP.
In the output, the TCP sessions to the core switch (10.1.1.1 with TCP 443) and the MC (10.1.1.6
with TCP 4343) should be listed.
(icx-T13-mc1) [mm] # show user ip 10.1.11.xx
This operation can take a while depending on number of users. Please be patient ....

Datapath Session Table Entries

------------------------------

Flags: F - fast age, S - src NAT, N - dest NAT

D - deny, R - redirect, Y - no syn
H - high prio, P - set prio, T - set ToS
C - client, M - mirror, V - VOIP
Q - Real-Time Quality analysis
u - Upstream Real-Time Quality analysis
I - Deep inspect, U - Locally destined
E - Media Deep Inspect, G - media signal
r - Route Nexthop, h - High Value
A - Application Firewall Inspect
J - SDWAN Default Probe stats used as fallback
B - Permanent, O - Openflow
L - Log, o - Openflow config revision mismatched

Source IP or MAC Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge
Packets Bytes Flags CPU ID
----------------- --------------- ---- ----- ----- -------- ---- --- --- ----------- ---- --
-------- ---------- --------------- -------
10.1.1.6 10.1.11.51 6 4343 2876 0/0 0 0 1 tunnel 10 a 12
3270 2
10.1.11.51 10.1.1.1 1 1051 2048 0/0 0 0 1 tunnel 10 14 1
60 FCI 2
10.1.11.51 10.254.1.23 6 2851 443 0/0 0 0 1 tunnel 10 15 8

Task 12.2-4: Test MC integration 441

 1417 FC 2
10.1.11.51 10.1.1.6 6 2867 4343 1/4101 0 0 1 tunnel 10 a 20
11232 C 2

10.1.11.51 10.1.1.1 1 1069 2048 0/0 0 0 0 tunnel 10 1 1

60 FCI 2
10.1.1.1 10.1.11.51 1 1059 0 0/0 0 0 1 tunnel 10 b 1
60 FI 2
10.1.1.1 10.1.11.51 1 1053 0 0/0 0 0 1 tunnel 10 12 1
60 FI 2
10.1.1.6 10.1.11.51 6 4343 2865 0/0 0 0 1 tunnel 10 a 18
7952 2

10.1.11.51 10.254.1.23 6 2859 443 0/0 0 0 1 tunnel 10 15 8

1417 FC 2
10.1.11.51 10.1.1.6 6 2875 4343 1/4101 0 0 1 tunnel 10 a 12
1640 FC 2
10.1.11.51 10.1.1.1 1 1061 2048 0/0 0 0 1 tunnel 10 9 1
60 FCI 2
10.1.1.1 10.1.11.51 1 1067 0 0/0 0 0 0 tunnel 10 3 1
60 FI 2
<...output omitted...>

This demonstrates how the MC can be used to get deep visibility into the traffic of the wired
devices.

Task 12.2-5: OPTIONAL—MAC authentication role example for IoT

This task is optional and can be done if time permits. Check with your instructor. If you skip this task,
you can move to the next task.

Objectives
In this task, an IoT use case example will be shown. This assumes that a customer wants to assign mul-
tiple types of IoT devices to the same VLAN. Since these IoT devices may come from different vendors,
the customer is concerned about the security between these IoT devices and would like to apply micro-
segmentation. This means that all the traffic, even the intra-VLAN traffic, needs to be firewalled and
controlled.
In this lab setup, PC3 and Access-2 will be assigned to the MC in the same VLAN. Initially, they will be
able to reach each other.
After the MC firewall user role is updated, the intra-VLAN traffic will be blocked by the firewall.
To simulate IoT devices, this activity will use MAC-auth.

442 Task 12.2-5: OPTIONAL—MAC authentication role example for IoT

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
Diagram

Steps
1. On PC3, connected to Access-1 port 1/1/3, disable 802.1X on the Lab NIC interface.

2. On PC3, disable and enable the Lab NIC interface.

Access-1
3. On Access-1, bounce the switch port 1/1/3 to restart the authentication process. Since the PC
does not have 802.1X configured, MAC-auth will be performed after about one minute. There is
no need to wait for the MAC-auth at this moment.

Task 12.2-5: OPTIONAL—MAC authentication role example for IoT 443

 ICX-T1-Access1-vsa(config)# interface 1/1/3
ICX-T1-Access1-vsa(config-if)# shutdown
ICX-T1-Access1-vsa(config-if)# no shutdown
ICX-T1-Access1-vsa(config-if)# exit

Prepare connection for Access-2

On Access-1, port 1/1/27 connects to Access-2. You will update the dev-switch user role and
assign it also to the mc-employee user role on the MC.
4. Remove the previous role (this ensures no previous settings are maintained), define the role
again, and redirect the traffic to the MC.
ICX-T1-Access1-vsa(config)# no port-access role dev-switch
ICX-T1-Access1-vsa(config)# port-access role dev-switch
ICX-T1-Access1-vsa(config-pa-role)# gateway-zone zone mc gateway-role mc-employee
ICX-T1-Access1-vsa(config-pa-role)# exit

5. Enable port 1/1/27 to Access-2 again.

ICX-T1-Access1-vsa(config)# interface 1/1/27
ICX-T1-Access1-vsa(config-if)# no shutdown
ICX-T1-Access1-vsa(config-if)# exit

Access-2
6. Access Access-2's terminal and enter configuration mode.
7. Disable the port to PC4 to prevent unnecessary authentications.
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# shutdown
ICX-Access-2(config-if)# exit

8. Remove the static IP address configuration from interface VLAN 1.

ICX-Access-2(config)# interface vlan 1
ICX-Access-2(config-if-vlan)# no ip address 10.1.1.5/24
ICX-Access-2(config-if-vlan)# exit

9. Bounce the uplink port 1/1/27 to trigger VLAN 1 to request a DHCP address.
ICX-Access-2(config)# interface 1/1/27
ICX-Access-2(config-if)# shutdown
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit

10. After about 30 seconds, Access-2 should have received a DHCP address on its VLAN 1 interface.
The assigned IP address may be different in your setup. Verify VLAN 1 IP address.
ICX-Access-2(config)# show ip interface brief
Interface IP Address Interface Status
link/admin
1/1/2 No Address down/down

vlan1 10.1.11.55/24 up/up

444 Task 12.2-5: OPTIONAL—MAC authentication role example for IoT

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
vlan2 No Address down/up

11. Ping to the core switch to generate some traffic.

ICX-Access-2(config)# ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 100(128) bytes of data.
108 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=8.88 ms
108 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=0.427 ms
108 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=0.629 ms
108 bytes from 10.1.1.1: icmp_seq=4 ttl=64 time=0.393 ms
108 bytes from 10.1.1.1: icmp_seq=5 ttl=64 time=0.331 ms

--- 10.1.1.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4069ms
rtt min/avg/max/mdev = 0.331/2.132/8.884/3.377 ms

Verify MAC-auth
Access-1
12. Verify the authentication status of port 1/1/27 (to Access-2). The ClearPass RADIUS server
returns the Aruba VSA dev-switch user role for the MAC authentication for the switch.
ICX-T1-Access1-vsa(config)# show aaa authentication port-access interface 1/1/27
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 10:4f:58:fc:b2:40, 104f58fcb240

======================================
Session Details
---------------
Port : 1/1/27
Session Time : 189s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Not attempted, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 189s ago

Authorization Details
----------------------
Role : dev-switch
Status : Applied

Task 12.2-5: OPTIONAL—MAC authentication role example for IoT 445

 13. About one minute should have passed by now. Verify the authentication status of port 1/1/3
(PC3); it should have received the employee role.
ICX-T1-Access1-vsa(config)# show aaa authentication port-access interface 1/1/3
client-status

Port Access Client Status Details

RADIUS overridden user roles are suffixed with '*'

Client 00:50:56:b1:2c:b8, 005056b12cb8

======================================
Session Details
---------------
Port : 1/1/3
Session Time : 350s
IPv4 Address :
IPv6 Address :
Device Type :

Authentication Details
----------------------
Status : mac-auth Authenticated
Auth Precedence : dot1x - Unauthenticated, mac-auth - Authenticated
Auth History : mac-auth - Authenticated, 289s ago
dot1x - Unauthenticated, Supplicant-Timeout, 289s ago

Authorization Details
----------------------
Role : employee
Status : Applied

Both user roles have been configured to redirect traffic to the MC using the same
"mc-employee" gateway role, so they are using the same firewall policy.

MC
14. On the MC, review the active users and their IP addresses.

Although both clients are using MAC-auth at this moment, the MC may still report
the original 802.1X client as "Tunneled-User-802.1X" at this point.

(icx-T13-mc1) [mm] # show user

This operation can take a while depending on number of users. Please be patient ....

Users
-----
IP MAC Name Role Age(d:h:m) Auth VPN

446 Task 12.2-5: OPTIONAL—MAC authentication role example for IoT

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
link AP name Roaming Essid/Bssid/Phy
Profile Forward mode Type Host Name User Type
---------- ------------ ------ ---- ---------- ---- ---
----- ------- ------- ---------------
------- ------------ ---- --------- ---------
10.1.11.55 10:4f:58:fc:b2:40 104f58fcb240 mc-employee 00:00:00 Tunneled-User-MAC
10.1.1.4 Tunneled tunnel 11/10:4f:58:f6:e3:80/1
/1/27 default-tunneled-user tunnel TUNNELED USER
10.1.11.51 00:50:56:b1:2c:b8 005056b12cb8 mc-employee 00:00:00 Tunneled-User-MAC
10.1.1.4 Tunneled tunnel 10/10:4f:58:f6:e3:80/1
/1/3 default-tunneled-user tunnel Win 10 TUNNELED USER

User Entries: 2/2

Curr/Cum Alloc:2/10 Free:1/8 Dyn:3 AllocErr:0 FreeErr:0

15. On PC3, attempt to ping to this IP. This should succeed, since the mc-employee firewall role has
an "allowall" policy.
Microsoft Windows [Version 10.0.17134.441]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Users\student>ping 10.1.11.55

Pinging 10.1.11.55 with 32 bytes of data:

Reply from 10.1.11.55: bytes=32 time=1ms TTL=64
Reply from 10.1.11.55: bytes=32 time<1ms TTL=64
Reply from 10.1.11.55: bytes=32 time<1ms TTL=64
Reply from 10.1.11.55: bytes=32 time<1ms TTL=64

Ping statistics for 10.1.11.55:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

Disable intra-VLAN traffic in the firewall role

16. On the MC, define a new session policy that denies ICMP traffic to the local VLAN 11.
(icx-T13-mc1) [mm] # configure terminal
Enter Configuration commands, one per line. End with CNTL/Z

(icx-T13-mc1) [mm] (config) # ip access-list session no-iot-intravlan

(icx-T13-mc1) ^[mm] (config-submode)# user network 10.1.11.0 255.255.255.0 icmp
echo deny
(icx-T13-mc1) ^[mm] (config-submode)# exit

17. Review the current mc-employee role. The "allowall" access-list is currently in position 3.
(icx-T13-mc1) ^[mm] (config) #show rights mc-employee

<Output omitted>

access-list List

Task 12.2-5: OPTIONAL—MAC authentication role example for IoT 447

 ----------------
Position Name Type Location
-------- ---- ---- --------
1 global-sacl session
2 apprf-mc-employee-sacl session
3 allowall session

<Output omitted>

18. Add the "no-iot-intravlan" access-list to the firewall mc-employee role.

Make sure to use position 3 in the command; it will insert the access-list before the
"allowall".

(icx-T13-mc1) ^[mm] (config) # user-role mc-employee

(icx-T13-mc1) ^[mm] (config-submode)# access-list session no-iot-intravlan position
3
(icx-T13-mc1) ^[mm] (config-submode)# exit

19. Save the configuration to make it effective.

(icx-T13-mc1) ^[mm] (config) # write memory

Saving Configuration...

Configuration Saved.

20. Review the updated mc-employee role. The "no-iot-intravlan" access-list is now in position 3.
(icx-T13-mc1) [mm] (config) # show rights mc-employee

<Output omitted>

access-list List
----------------
Position Name Type Location
-------- ---- ---- --------
1 global-sacl session
2 apprf-mc-employee-sacl session
3 no-iot-intravlan session
4 allowall session

<Output omitted>

21. On the client PC3, the ping will no longer be possible to Access-2.
C:\Users\student>ping 10.1.11.55

Pinging 10.1.11.55 with 32 bytes of data:

Request timed out.
Request timed out.

448 Task 12.2-5: OPTIONAL—MAC authentication role example for IoT

 Aruba Networking MC—user-based
Lab 12.2: Integration with HPE
Request timed out.
Request timed out.

Ping statistics for 10.1.11.55:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

This demonstrates how the HPE Aruba Networking Dynamic Segmentation solution can offer
complete network control, even for intra-VLAN traffic.
You have completed Lab 12!

Task 12.2-5: OPTIONAL—MAC authentication role example for IoT 449

[This page intentionally left blank]

450 Task 12.2-5: OPTIONAL—MAC authentication role example for IoT

Lab 13: Quality of Service

Lab 13: Quality of Service

Lab diagram

Overview
In this lab activity, the QoS trust and policy configuration will be explained. The first part of the lab will
cover the port and global trust options. Next, the LLDP device profile-based trust will be demonstrated.
The second part of the lab will explain how classifiers, policies, and actions can be used to mark and pri-
oritize specific traffic.

Lab 13: Quality of Service 451

The lab will also show options for the queue configuration and how to configure an LLDP-MED voice
VLAN.

Objectives
n Configure and understand QoS trust modes on the switch.
n Understand device profiles.
n Configure QoS classifiers.
n Understand queue configuration options.
n Apply a voice VLAN configuration for LLDP-MED.

Task 13-1: Prepare the lab start configuration

This lab is built on the base VSX topology.
Make sure to complete these steps to get the base VSX checkpoint configuration on the devices.

Objectives
n Adjust topology for QoS.
n Force traffic from PC4 and Access-2 over Access-1.
Steps (required)
1. Open a console connection to Access-1. Log in using admin/aruba123.
ICX-Access-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-1#

2. Open a console connection to Access-2. Log in using admin/aruba123.

ICX-Access-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-2#

3. Open a console connection to Core-1. Log in using admin/aruba123.

ICX-Core-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-1#

4. Open a console connection to Core-2. Log in using admin/aruba123.

ICX-Core-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-2#

452 Task 13-1: Prepare the lab start configuration

 Adjust topology for the QoS lab
Access-1
5. On Access-1, enter configuration mode.
6. Enable the peer link to Access-2, configure it as the VLAN trunk using VLAN 11 as the native
(untagged) VLAN ID, and allow VLANs 11 and 12.
n VLAN 11 can be used to simulate PC/data traffic.

Lab 13: Quality of Service

n VLAN 12 is used to simulate voice traffic (tagged).
ICX-Access-1(config)# interface 1/1/27
ICX-Access-1(config-if)# vlan trunk native 11
ICX-Access-1(config-if)# vlan trunk allowed 11,12
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# exit

Access-2
7. Open a terminal to Access-2 and enter configuration mode.
8. Disable the uplinks to VSX Core-1 and Core-2.
ICX-Access-2(config)# interface 1/1/25,1/1/26
ICX-Access-2(config-if-<1/1/25,1/1/26>)# shutdown
ICX-Access-2(config-if-<1/1/25,1/1/26>)# exit

9. Enable the peer link to Access-1 and configure it as the VLAN trunk. Define an IP address on the
voice VLAN 12.
ICX-Access-2(config)# interface 1/1/27
ICX-Access-2(config-if)# vlan trunk native 11
ICX-Access-2(config-if)# vlan trunk allowed 11,12
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit

10. Define IP address 10.1.12.100 on VLAN 12 and set the default route.
ICX-Access-2(config)# interface vlan 12
ICX-Access-2(config-if-vlan)# ip address 10.1.12.100/24
ICX-Access-2(config-if-vlan)# exit
ICX-Access-2(config)# ip route 0.0.0.0/0 10.1.12.1

11. Verify the IP address and default route with a ping to a VLAN 11 IP address.
ICX-Access-2(config)# ping 10.1.12.1
PING 10.1.12.1 (10.1.12.1) 100(128) bytes of data.
108 bytes from 10.1.12.1: icmp_seq=1 ttl=64 time=0.197 ms
108 bytes from 10.1.12.1: icmp_seq=2 ttl=64 time=0.387 ms
108 bytes from 10.1.12.1: icmp_seq=3 ttl=64 time=0.206 ms
108 bytes from 10.1.12.1: icmp_seq=4 ttl=64 time=0.202 ms
108 bytes from 10.1.12.1: icmp_seq=5 ttl=64 time=0.213 ms

Task 13-1: Prepare the lab start configuration 453

 --- 10.1.12.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4097ms
rtt min/avg/max/mdev = 0.197/0.241/0.387/0.073 ms

12. Enable the port to PC4 connected on Access-2. Make it a member of VLAN 11 so that PC4 sim-
ulates a PC connected to a phone (simulated by Access-2) (untagged VLAN 11 PC traffic passing
Access-2 to Access-1).
ICX-Access-2(config)# interface 1/1/4
ICX-Access-2(config-if)# vlan access 11
ICX-Access-2(config-if)# no shutdown
ICX-Access-2(config-if)# exit

13. On PC4, bounce the Lab NIC to refresh the IP address.

14. Confirm that PC3 and PC4 can ping each other.

Task 13-2: Port classification – trust configuration

Access-2 is used as a test device to send DSCP marked traffic. Access-1 is where the QoS configuration
is applied to deal with the incoming marks.

Objectives
n Review the default QoS trust mode on Access-1.
n Adjust the default global trust mode and verify the result.

454 Task 13-2: Port classification – trust configuration

 Diagram

Lab 13: Quality of Service

Steps
Send normal and marked packets from Access-2 to PC3 and verify these using Wireshark.
1. On Access-1, enter configuration mode and clear the interface statistics on ports 1/1/3 (PC) and
LAG 256 (uplink to the VSX core).
ICX-Access-1(config)# clear interface statistics

Task 13-2: Port classification – trust configuration 455

 The lab is using this generic clear interface statistics command for simplicity. A
more selective clear is available per interface. For example, do clear interface
1/1/3 statistics.

Core-1
2. On Core-1, enter the configuration mode and clear the interface statistics.
ICX-Core-1(config)# clear interface statistics

Core-2
3. Repeat this on Core-2.
ICX-Core-2(config)# clear interface statistics

Access-1
4. Review the current queue statistics on port 1/1/3; this is the port connected to PC3. Most queues
should have statistics that are close to 0.
ICX-Access-1(config)# show interface 1/1/3 queues
Interface 1/1/3 is up
Admin state is up
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 0 0 0
Q2 0 0 0
Q3 0 0 0
Q4 0 0 0
Q5 0 0 0
Q6 0 0 0
Q7 615 5 0

If the statistics are not close to 0, you should repeat the clear interface
statistics command and verify the queue counters again.

Clearing the queue statistics makes it easier to troubleshoot and understand what
traffic is sent via which queue. Feel free to repeat the clear statistics command in
case tests need to be repeated.
The switch will automatically send L2 control protocols via Q7; normal user frames
will be sent on Q1 by default.

5. Open a connection to PC3 (connected to Access-1 port 1/1/3).

6. Check and take note of the IP address (it should have an IP address in VLAN 11); you will need
this IP address in the next steps on Access-2.

456 Task 13-2: Port classification – trust configuration

 Lab 13: Quality of Service
7. Start Wireshark. The Wireshark icon is available on the PC3 desktop.

8. Double-click the Lab NIC interface to start a new trace.

9. Click in the Apply a display filter field.

Task 13-2: Port classification – trust configuration 457

 10. Type icmp and press Enter.

Access-2
11. On Access-2, perform a ping to PC3 on Access-1. Access-2 has an IP address in VLAN 12, so this
ping will be routed via the core VSX. The ping should be successful. Replace xx with the current
IP address from PC3.
ICX-Access-2(config)# ping 10.1.11.xx datagram-size 14000 repetitions 10

Any ping is fine for this lab. In the above ping, using 10 requests of size 14,000 gen-
erates about 100 outbound packets (due to fragmentation), so it is easy to recognize
these test packets in the statistics.
If your pings fail to PC3, disable all three Windows Defender firewalls on PC3.

12. On PC3 (connected to Access-1), stop the Wireshark capture.

13. Click the packet with the Access-2 source IP (10.1.12.100) and open the Internet Protocol and
Differentiated Services Codepoint sections. Check the DSCP value. Since no configuration was
done, this should be Default (0) at this point.

458 Task 13-2: Port classification – trust configuration

 Lab 13: Quality of Service
Access-1
14. On Access-1, review the interface 1/1/3 statistics; this traffic should have been sent out using
the "normal" queue. There should be about 100 packets in queue 1 at this moment.
ICX-Access-1(config)# show interface 1/1/3 queues
Interface 1/1/3 is up
Admin state is up
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 146743 128 0
Q2 0 0 0
Q3 0 0 0
Q4 0 0 0
Q5 0 0 0
Q6 0 0 0
Q7 58341 463 0

The PC may be generating some other traffic, so the statistics will typically have
some variation.

Task 13-2: Port classification – trust configuration 459

 Marked voice traffic
Diagram

15. On PC3 (connected to Access-1), start the Wireshark trace. Click Continue without Saving to
start the trace.

460 Task 13-2: Port classification – trust configuration

 Lab 13: Quality of Service
Access-2
16. Now use Access-2 to send traffic from VLAN 12 marked with voice DSCP (46).

On an AOS-CX switch, the administrator can enter the TOS value that should be used
for the outgoing ICMP packets.
The binary value for DSCP 46 is 101110.
The IP TOS field has two extra bits at the end, so the complete value is 10111000.
Converted into decimals, this results in value 184.

ICX-Access-2(config)# ping 10.1.11.xx datagram-size 17000 repetitions 8 tos 184

17. On the receiving PC, verify the received marked traffic. In Wireshark, stop the trace and verify the
incoming DSCP value of the ICMP request (make sure to select a request, not the reply).

18. On Access-1, review statistics on the queues. It should still be normal traffic, even when marked
with the DSCP value for voice.

Task 13-2: Port classification – trust configuration 461

 ICX-Access-1(config)# show interface 1/1/3 queues
Interface 1/1/3 is up
Admin state is up
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 428406 339 0
Q2 0 0 0
Q3 0 0 0
Q4 0 0 0
Q5 0 0 0
Q6 0 0 0
Q7 92121 730 0

Enable global DSCP trust

In the next steps, the QoS trust mode on the switches will be set to globally trust the incoming
DSCP value. This will ensure that the switch will inspect every incoming packet for a DSCP value
and apply it to the correct local mapping based on the DSCP map.
19. On Access-1, enable the global DSCP trust option.
ICX-Access-1(config)# qos trust dscp

20. Clear the port counters on Access-1.

ICX-Access-1(config)# clear interface statistics

21. On Access-2, repeat the ping (use the up arrow to get the previous command).
ICX-Access-2(config)# ping 10.1.11.xx datagram-size 17000 repetitions 8 tos 184

22. Once the ping has completed, review the queue statistics on the Access-1 switch.
ICX-Access-1(config)# show interface 1/1/3 queues
Interface 1/1/3 is up
Admin state is up
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 913 8 0
Q2 0 0 0
Q3 0 0 0
Q4 0 0 0
Q5 140096 96 0
Q6 0 0 0
Q7 9711 77 0

The DSCP marking of the traffic did not change, but now the switch is using this mark
in the incoming packet to assign it to the correct local priority, which is assigned to
queue 5.

462 Task 13-2: Port classification – trust configuration

 Trust end-to-end
The core VSX also needs to trust DSCP to ensure packets are assigned to the correct queue. It is
a best practice to enable the global QoS trust DSCP for VSX on Core-1 and Core-2 and review
the traffic assignment.
Core-1
23. Enable the global trust on Core-1.
ICX-Core-1(config)# qos trust dscp

Lab 13: Quality of Service

Core-2
24. Repeat this step on Core-2.
ICX-Core-2(config)# qos trust dscp

Access-2
25. On Access-2, repeat the ping (use the up arrow to get the previous command).
Core-1
26. Review the LAG 1 (LAG to Access-1) queue statistics. You should see that some traffic was sent
into queue 5.
ICX-Core-1(config)# show interface lag1 queues
Aggregate-name lag1
Aggregated-interfaces :
1/1/1
Speed 10000 Mb/s
Tx Bytes Tx Packets Tx Drops Tx Byte Depth Recent Peak Depth
Q0 0 0 0 0 0
Q1 626742 1146 0 1792 0
Q2 0 0 0 0 0
Q3 0 0 0 0 0
Q4 0 0 0 0 0
Q5 140096 96 0 1792 1792
Q6 0 0 0 1024 0
Q7 27818 157 0 512 0

In case there are no traffic statistics in queue 5, check the command for the peer VSX system,
since the link aggregation on Access-1 may have sent the traffic to Core-2. Use the show
interface lag1 queues vsx-peer command.

Task 13-3: LLDP device profile for QoS trust

Objectives
Some customers may prefer to control the DSCP and queue assignment using classifiers and policies, so
they may not want to enable the global QoS trust DSCP on the access switches.

Task 13-3: LLDP device profile for QoS trust 463

However, an HPE controlled AP (this is an AP connected to a Mobility Controller [MC]) can use this
DSCP mark as well. It will send wireless traffic over an IP GRE tunnel to the MC and, based on the con-
figuration, the wireless QoS may be copied into the IP DSCP mark. This ensures a high-priority wireless
packet can also be recognized as a high-priority packet on the path between the AP and the MC. In this
case, the switch should trust the DSCP mark if the traffic comes from a port with an HPE Aruba Net-
working AP connected.
AOS-CX switches support this scenario using LLDP-based device profiles. The LLDP device trust allows
the administrator to leave the global trust level at :none," since the switch will automatically set the
port trust to DSCP when a matching LLDP device is discovered on a switch port.
Diagram

Steps
Configure a device profile with LLDP trust settings.

464 Task 13-3: LLDP device profile for QoS trust

 Use the Access-2 switch to simulate an LLDP device profile to test the device profile.
1. On Access-1, remove the global trust DSCP.
ICX-Access-1(config)# qos trust none

2. Clear statistics and verify incoming marked DSCP traffic is not trusted anymore. A ping test from
Access-2 should arrive in the normal queue (queue 1) again.
ICX-Access-1(config)# clear interface statistics

Lab 13: Quality of Service

Access-2
3. Repeat the test ping on Access-2. Replace xx with the current PC4 IP address.
ICX-Access-2(config)# ping 10.1.11.xx datagram-size 17000 repetitions 8 tos 184

Access-1
4. Verify on Access-1 that the traffic is handled in the normal queue again.
ICX-Access-1(config)# show interface 1/1/27 queues
Interface 1/1/27 is up
Admin state is up
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 143671 139 0
Q2 0 0 0
Q3 0 0 0
Q4 0 0 0
Q5 0 0 0
Q6 0 0 0
Q7 11518 91 0

5. Review the default port trust mode.

ICX-Access-1(config)# show interface 1/1/27

Interface 1/1/27 is up
Admin state is up
Link state: up for 17 hours (since Wed Jul 17 17:57:10 EDT 2024)
Link transitions: 21
Description:
Persona:
Hardware: Ethernet, MAC Address: 10:4f:58:f6:e3:8e
MTU 1500
Type 10G-DAC1 / 10G SFP+ 1m DAC
Full-duplex
qos trust none
Speed 10000 Mb/s
Auto-negotiation is off
Flow-control: off

<Output omitted>

Task 13-3: LLDP device profile for QoS trust 465

 Configure the device profile
6. On Access-1, configure the LLDP device profile role with DSCP trust.
ICX-Access-1(config)# port-access role demo-lldp-switch
ICX-Access-1(config-pa-role)# trust-mode dscp
ICX-Access-1(config-pa-role)# exit

7. Configure the LLDP device profile with an LLDP group for AOS-CX switches. In a real deploy-
ment, this would be an HPE Aruba Networking AP, but the Access-2 switch is used to simulate
the behavior.

You should verify the model number of Access-1 and Access-2 using the show lldp
neighbor-info 1/1/27 command from each switch. For example, in Pod 13, it is
model JL668A.

ICX-Access-1(config)# port-access lldp-group demo-switch

ICX-Access-1(config-lldp-group)# match sys-desc JL668A
ICX-Access-1(config-lldp-group)# exit
ICX-Access-1(config)# port-access device-profile dev-aoscx-switch
ICX-Access-1(config-device-profile)# associate role demo-lldp-switch
ICX-Access-1(config-device-profile)# associate lldp-group demo-switch
ICX-Access-1(config-device-profile)# enable
ICX-Access-1(config-device-profile)# exit

8. Verify the LLDP profile has been applied to port 1/1/27.

ICX-Access-1(config)# show port-access device-profile interface all
Port 1/1/27, Neighbor-Mac 10:4f:58:fc:b2:40
Profile Name: : dev-aoscx-switch
LLDP Group: : demo-switch
CDP Group: :
MAC Group: :
Role: : demo-lldp-switch
State: : applied
Failure Reason: :

9. Verify the changed port QoS trust mode.

ICX-Access-1(config)# show interface 1/1/27

Interface 1/1/27 is up
Admin state is up
Link state: up for 19 hours (since Wed Jul 17 17:57:10 EDT 2024)
Link transitions: 21
Description:
Persona:
Hardware: Ethernet, MAC Address: 10:4f:58:f6:e3:8e
MTU 1500
Type 10G-DAC1 / 10G SFP+ 1m DAC
Full-duplex

466 Task 13-3: LLDP device profile for QoS trust

 qos trust dscp
Speed 10000 Mb/s
<Output omitted>

Access-2
10. Repeat the test ping on Access-2.
ICX-Access-2(config)# ping 10.1.11.51 datagram-size 17000 repetitions 8 tos 184

Access-1

Lab 13: Quality of Service

11. Check the queue statistics of interface LAG 255 on Access-1; the traffic should now appear in
queue 5 again.
ICX-Access-1(config)# show interface lag255 queues
Aggregate-name lag255
Aggregated-interfaces :
1/1/25 1/1/26
Speed 20000 Mb/s
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 663153 3070 0
Q2 0 0 0
Q3 0 0 0
Q4 0 0 0
Q5 140782 103 0
Q6 138576 1243 0
Q7 664434 4892 0

This demonstrates how the AOS-CX switch can dynamically enable QoS DSCP trust based on the
LLDP neighbor, such as an HPE Aruba Networking AP.
12. Lab cleanup: Disable the LLDP profile.
ICX-Access-1(config)# port-access device-profile dev-apscx-switch
ICX-Access-1(config-device-profile)# disable
ICX-Access-1(config-device-profile)# exit

Task 13-4: QoS classification

Objectives
In this task, the classifier-based QoS will be demonstrated. The purpose of the classifier is to provide
the administrator a mechanism to re-mark and classify traffic in case the endpoint cannot perform the
marking by itself, or the endpoint is not trusted to perform the marking.
In this task, traffic from the voice VLAN 12 will be changed for these two scenarios:
n Voice to voice: Traffic coming from the simulated voice VLAN 12 to the other VLAN 12 hosts will
be marked as DSCP 46, so even when an unmarked ping is done, the traffic will be marked with
value 46.

Task 13-4: QoS classification 467

 n Voice to other: Traffic coming from the simulated voice VLAN 12 to any other destination will be
marked as DSCP AF41. This is just an example mark to demonstrate the feature.
Diagram

Steps
To use the classifier-based QoS, the administrator should complete these steps:
n Define the classes.
n Assign the classes into a policy and set actions.
n Bind the policy to an interface or VLAN.

468 Task 13-4: QoS classification

 Define the classes
Access-1
1. On Access-1, define a new class for the voice-to-voice traffic; set the count option as well to get
class statistics on matched traffic. The "VLAN" keyword applies to the given VLAN ID as an addi-
tional condition.
Wildcard mask

Lab 13: Quality of Service

In the IP class definition, wildcard masks are supported. On some platforms, wildcard masks are
inversed bits. For AOS-CX, the wildcard mask is using the same logic as a normal subnet mask, so
a 1 bit to match, 0 bit to ignore the value.
Therefore, 10.0.12.0/0.255.0.255 means traffic:
n matching 10 in the first byte
n with any value in the second byte
n matching 12 in the third byte
n with any value in the fourth byte
ICX-Access-1(config)# class ip voice-dst-voice
ICX-Access-1(config-class-ip)# 10 match any any 10.0.12.0/255.0.255.0 vlan 12 count
ICX-Access-1(config-class-ip)# exit

2. Define a new class for the voice-to-any traffic with the count option.
ICX-Access-1(config)# class ip voice-dst-any
ICX-Access-1(config-class-ip)# 10 match any any any vlan 12 count
ICX-Access-1(config-class-ip)# exit

Define the policy and assign actions to the classes

Now, combine the traffic classes into a policy with actions.
For the voice-to-voice traffic, a re-mark action of DSCP value 46 (EF) will be set.
For the voice-to-any traffic, a re-mark action of DSCP value 34 (AF41) will be set.
3. Define the policy.
ICX-Tx-Access1(config)# policy access
ICX-Tx-Access1(config-policy)# 10 class ip voice-dst-voice action dscp EF
ICX-Tx-Access1(config-policy)# 20 class ip voice-dst-any action dscp AF41
ICX-Tx-Access1(config-policy)# exit

Apply the policy

A policy can be applied at various levels (global/VLAN/interface). In this lab, the policy will be
applied at the interface level.
4. On port 1/1/27 connected to Access-2, apply the QoS policy on the inbound traffic.

Task 13-4: QoS classification 469

 ICX-Access-1(config)# interface 1/1/27
ICX-Access-1(config-if)# apply policy access in
ICX-Access-1(config-if)# exit

5. Review the applied policy on port 1/1/27.

ICX-Access-1(config)# show policy interface 1/1/27
Direction
Name
Additional Policy Parameters
Sequence Comment
Class Type
action
-------------------------------------------------------------------------------
Inbound
access
10
voice-dst-voice ipv4
dscp EF

20
voice-dst-any ipv4
dscp AF41

-------------------------------------------------------------------------------

Verify marking and queuing for voice to data scenario

In the next steps, the result of the configuration will be verified.
6. Prepare the test:
a. On PC3, connected to Access-1 and start a Wireshark trace.
b. On Access-1, clear the interface statistics (run the command twice).
ICX-Access-1(config)# clear interface statistics

PC3
7. On PC3, restart the packet capture. When prompted click Continue without Saving.

470 Task 13-4: QoS classification

 Lab 13: Quality of Service
Access-2
8. On Access-2, run the ping to this PC (voice to any) without marking the traffic (so, no tos in the
command). The unmarked traffic should be re-marked by the policy.
ICX-Access-2(config)# ping 10.1.11.xx datagram-size 17000 repetitions 8

Access-1
9. On Access-1, verify that the traffic has matched the policy by checking the hit counts of the
policy. The number 100 in this output example is the number of packets that have matched the
class in the policy.
ICX-Access-1(config)# show policy hitcounts access
Statistics for Policy access:

Interface 1/1/27 (in):

Matched Packets Configuration
10 class ip voice-dst-voice action dscp EF
0 10 match any any 10.0.12.0/255.0.255.0 vlan 12 count
20 class ip voice-dst-any action dscp AF41
539 10 match any any any vlan 12 count

10. On PC3, stop the Wireshark trace and check the inbound DSCP value (source 10.1.12.100). This
should be AF41.

Task 13-4: QoS classification 471

 11. Now, verify the traffic was handled by the correct queue on Access-1.
ICX-Access-1(config)# show interface 1/1/3 queues
Interface 1/1/3 is up
Admin state is up
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 282343 221 0
Q2 0 0 0
Q3 0 0 0
Q4 0 0 0
Q5 0 0 0
Q6 0 0 0
Q7 47721 379 0

Question: Why is the traffic sent out in the "normal" queue (Q1), instead of Q4 (the expected
queue for AF41 traffic)?
Answer: Check the global QoS trust option.
12. Review the global trust option.
ICX-Access-1(config)# show qos trust
qos trust none

13. Adjust the global trust to DSCP.

ICX-Access-1(config)# qos trust dscp
ICX-Access-1(config)# show qos trust
qos trust dscp

14. Repeat the ping test from Access-2 to the PC.

15. On Access-1, the traffic should now be visible in Q4.
ICX-Access-1(config)# show interface 1/1/3 queues
Interface 1/1/3 is up

472 Task 13-4: QoS classification

 Admin state is up
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 282887 229 0
Q2 0 0 0
Q3 0 0 0
Q4 140096 96 0
Q5 0 0 0
Q6 0 0 0
Q7 63726 506 0

Lab 13: Quality of Service

This concludes the first part of the validation.
Verify marking and queuing for voice-to-voice scenario
In the next section, traffic from voice to voice will be verified.
This will be tested with a basic ping to the default gateway in the voice VLAN (10.1.12.1).
Access-1
16. Prepare the test: On Access-1, clear the interface statistics.
ICX-Access-1(config)# clear interface statistics

Access-2
17. On Access-2, ping the voice default gateway (10.1.12.1) without marking the traffic.
ICX-Access-2(config)# ping 10.1.12.1 datagram-size 17000 repetitions 8

Access-1
18. On Access-1, verify the traffic matched by checking the hitcounts of the policy.
ICX-Access-1(config)# show policy hitcounts access
Statistics for Policy access:

Interface 1/1/27 (in):

Matched Packets Configuration
10 class ip voice-dst-voice action dscp EF
96 10 match any any 10.0.12.0/255.0.255.0 vlan 12 count
20 class ip voice-dst-any action dscp AF41
1016 10 match any any any vlan 12 count

19. Now, verify that the traffic was assigned to the correct queue on the uplink interface.
ICX-Access-1(config)# show interface lag255 queues
Aggregate-name lag255
Aggregated-interfaces :
1/1/25 1/1/26
Speed 20000 Mb/s
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 145543 159 0
Q2 0 0 0

Task 13-4: QoS classification 473

 Q3 0 0 0
Q4 0 0 0
Q5 0 0 0
Q6 3920 35 0
Q7 15240 113 0

Question: Why would the traffic be assigned to the normal queue?

Answer: In the previous section, the QoS global trust was enabled; however, that does not seem
to affect the current setup.
This is because any traffic that matches a policy will not be trusted, so it is not automatically
assigned to a queue based on the trust map.
In the previous section, the trust did work, since the traffic was first sent to the VSX core (to be
routed between the voice and data VLAN). So when the traffic was sent back from the core to
the Access-1 switch, the global qos trust dscp ensured that the incoming DSCP mark was used
to assign the packet to the correct queue.
In the current example, the incoming traffic on 1/1/27 matches a policy. The policy re-marks the
DSCP, but the policy did not apply a local priority to the traffic. Therefore, although the DSCP re-
mark was done, the packet was still considered "normal" inside the switch.
In the next section, the policy will be adjusted to apply both the DSCP mark and the local priority.

This also applied to the previous section. If the uplink LAG 255 statistics would have
been checked, it would have shown that the traffic was sent in the normal queue,
even with qos trust dscp enabled.

To summarize:
Any match on an entry in a policy overrules the trust, so the administrator should assign a local
priority as well.

474 Task 13-4: QoS classification

 Adjust the policy to mark and local policy
Diagram

Lab 13: Quality of Service

20. Enter the policy context and review the current configuration.
ICX-Access-1(config)# policy access
ICX-Access-1(config-policy)# show running-config current-context
policy access
10 class ip voice-dst-voice action dscp EF
20 class ip voice-dst-any action dscp AF41

Task 13-4: QoS classification 475

 21. Update the policy to include the local-priority action. Make sure to use the line numbers (10 and
20) in the commands. Otherwise, additional configuration lines would be added and the traffic
would still match the original first line.
ICX-Access-1(config-policy)# 10 class ip voice-dst-voice action local-priority 5
action dscp EF
ICX-Access-1(config-policy)# 20 class ip voice-dst-any action local-priority 4
action dscp AF41

22. Review the updated configuration. Make sure there are only two rules in the policy.
ICX-Access-1(config-policy)# show running-config current-context
policy access
10 class ip voice-dst-voice action local-priority 5 action dscp EF
20 class ip voice-dst-any action local-priority 4 action dscp AF41
ICX-Access-1(config-policy)# exit

If you added additional lines, these can be remove using no plus the line number.
Example:
ICX-Access-1(config-policy)# no 30

The DSCP and CoS to local priority (LP) could be managed either by using policies or
the DSCP-to-LP or CoS-to-LP maps. As a best practice, those maps should be con-
sistent throughout the entire network to ensure the proper treatment and pri-
oritization of traffic.

23. On Access-1, check the LAG 255 queue statistics.

ICX-Access-1(config)# show interface lag255 queues
Aggregate-name lag255
Aggregated-interfaces :
1/1/25 1/1/26
Speed 20000 Mb/s
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 170025 425 1
Q2 0 0 0
Q3 0 0 0
Q4 6224 66 0
Q5 98 1 0
Q6 16472 148 0
Q7 88603 652 0

24. Configure the switch to repeat the command.

ICX-Access-1(config)# repeat

The output will now automatically repeat every two seconds.

Access-2

476 Task 13-4: QoS classification

 25. On Access-2, repeat the verification test with a ping without a mark to the default gateway.
ICX-Access-2(config)# ping 10.1.12.1 datagram-size 17000 repetitions 8

Access-1
26. Press Ctrl-c to stop the repeat.
27. On Access-1, check the LAG 255 queue statistics. Traffic should pass over Q5 now.
***************************************
Iteration : 10 Command : show interface lag255 queues

Lab 13: Quality of Service

***************************************
Aggregate-name lag255
Aggregated-interfaces :
1/1/25 1/1/26
Speed 20000 Mb/s
Tx Bytes Tx Packets Tx Drops
Q0 0 0 0
Q1 171557 444 1
Q2 0 0 0
Q3 0 0 0
Q4 10008 105 0
Q5 140194 97 0
Q6 17792 160 0
Q7 100167 737 0

This demonstrates the use of classifiers, policies, and actions.

Task 13-5: Queue configuration

Objectives
In this task, the queue configuration and priority mappings will be reviewed.
The priority mapping tables allow the administrator to customize the trust maps:
n DSCP-to-local-priority mapping
n COS-to-local-priority mapping
With the queue configuration, the administrator can control to which queue each of the local-priority
values will be mapped.
With a schedule profile, the administrator can control the relative bandwidth of each of the queues and
the type of scheduling, such as strict priority or DWRR.

Task 13-5: Queue configuration 477

Steps
Review default DSCP to local-priority mapping
Access-1
1. On Access-1, review the default QoS DSCP map. Notice how each DSCP code point is mapped to
a local priority on the switch. This local priority will be used to assign the packet to a queue. This
map is used for any incoming traffic on ports with qos trust dscp (based on interface, global or
dynamic, with LLDP or port access).
ICX-Access-1(config)# show qos dscp-map
DSCP code_point local_priority cos color name
-------- ---------- -------------- --- ------- ----
000000 0 1 green CS0
000001 1 1 green
000010 2 1 green
000011 3 1 green
000100 4 1 green
000101 5 1 green
000110 6 1 green
000111 7 1 green
001000 8 0 green CS1
001001 9 0 green
001010 10 0 green AF11
001011 11 0 green
001100 12 0 yellow AF12
001101 13 0 green
001110 14 0 red AF13
001111 15 0 green
010000 16 2 green CS2
010001 17 2 green
010010 18 2 green AF21
010011 19 2 green
010100 20 2 yellow AF22
010101 21 2 green
010110 22 2 red AF23
010111 23 2 green
011000 24 3 green CS3
011001 25 3 green
011010 26 3 green AF31
011011 27 3 green
011100 28 3 yellow AF32
011101 29 3 green
011110 30 3 red AF33
011111 31 3 green
100000 32 4 green CS4
100001 33 4 green
100010 34 4 green AF41

478 Task 13-5: Queue configuration

 100011 35 4 green
100100 36 4 yellow AF42
100101 37 4 green
100110 38 4 red AF43
100111 39 4 green
101000 40 5 green CS5
101001 41 5 green
101010 42 5 green
101011 43 5 green
101100 44 5 green

Lab 13: Quality of Service

101101 45 5 green
101110 46 5 green EF
101111 47 5 green
110000 48 6 green CS6
110001 49 6 green
110010 50 6 green
110011 51 6 green
110100 52 6 green
110101 53 6 green
110110 54 6 green
110111 55 6 green
111000 56 7 green CS7
111001 57 7 green
111010 58 7 green
111011 59 7 green
111100 60 7 green
111101 61 7 green
111110 62 7 green
111111 63 7 green

Question: What is the local priority that would be assigned to traffic marked with DSCP 46 (EF),
typically used for voice?
Answer: DSCP 46 will be mapped to local-priority 5.
Question: What is the local priority that would be assigned to traffic without a DSCP mark (0)?
Answer: DSCP CS0 will be mapped to local-priority 1.

The DSCP map also shows the drop precedence level option as a color code
(green/yellow). However, this is beyond the scope of this course.

2. Review the default CoS to local-priority map. This map would be used for ports that have the qos
trust cos command applied. Most deployments will opt for the DSCP trust instead.
ICX-Access-1(config)# show qos cos-map
code_point local_priority color name
---------- -------------- ------- ----
0 1 green Best_Effort
1 0 green Background

Task 13-5: Queue configuration 479

 2 2 green Excellent_Effort
3 3 green Critical_Applications
4 4 green Video
5 5 green Voice
6 6 green Internetwork_Control
7 7 green Network_Control

Question: What is the local priority that would be assigned to traffic without the CoS mark (0)?
Answer: CoS 0 will be mapped to local-priority 1.
Review the queue configuration
3. Review the available queue profiles. Only one queue profile can be applied on the switch; this is a
switch global option.
ICX-Access-1(config)# show qos queue-profile
profile_status profile_name
-------------- ------------
applied factory-default

4. Check the details of this queue profile.

ICX-Access-1(config)# show qos queue-profile factory-default
queue_num local_priorities name
--------- ---------------- ----
0 0 Scavenger_and_backup_data
1 1
2 2
3 3
4 4
5 5
6 6
7 7

Question: To which queue will default traffic (local-priority 1) be assigned?

Answer: Default (best effort) traffic is assigned to queue 1 based on this table. This is consistent
with the queue statistics that were observed in previous tasks.
Review the scheduling profile
In the next steps, the scheduling of the queues will be reviewed.
The scheduling profile controls how each queue will be able to send out traffic, relative to other
traffic in the queues.
5. Review the current scheduling profiles.
ICX-Access-1(config)# show qos schedule-profile
profile_status profile_name
-------------- ------------
applied factory-default
complete strict

480 Task 13-5: Queue configuration

 6. Check the details of the "factory-default" profile.
ICX-Access-1(config)# show qos schedule-profile factory-default
Queue Maximum Bandwidth
Number Algorithm Percent Weight Bandwidth Units
------- -------------- -------- ------- ---------- ----------
0 dwrr 1
1 dwrr 1
2 dwrr 1
3 dwrr 1

Lab 13: Quality of Service

4 dwrr 1
5 dwrr 1
6 dwrr 1
7 dwrr 1

Question: What does the weight indicate?

Answer: The weight is used to measure the "weight" of the queue when multiple queues need to
deliver traffic.
For example, when there is only traffic waiting in queue 1 and queue 5, the total weight at that
moment is 1+1. So, both queue 1 and queue 5 would have 1 out of 2, so up to 50% each.
In case only queue 1 has traffic waiting, the total weight at that moment is 1. So, queue 1 would
have 1 out of 1, so up to 100% of the bandwidth.
The result is that each queue has an equal share of the potential bandwidth when required.
In case the administrator wants to ensure that a queue needs more (or less) than this equal
share, the weight can be adjusted.
Example of queue profile adjustment
In this example, the schedule profile will be adjusted, so in case of traffic in various queues, these
will be the minimum share values of the bandwidth.
To make the calculation easy, use a total of 100 for all the queues; this is not a requirement, how-
ever.
Each individual queue weight can have a value between 1–1023.

Queue Weight

0 1
1 39
2 10
3 10
4 10
5 10

Task 13-5: Queue configuration 481

 Queue Weight

6 10
7 10

This means:
If there is guest traffic (assuming this is assigned to queue 0) with weight 1, and normal traffic
with weight 39, the guest would get 1 out of 40 (39+1), so 2.5%.
7. Define the new profile and assign each queue a value.
ICX-Access-1(config)# qos schedule-profile icx
ICX-Access-1(config-schedule)# dwrr queue 0 weight 1
ICX-Access-1(config-schedule)# dwrr queue 1 weight 39
ICX-Access-1(config-schedule)# dwrr queue 2 weight 10
ICX-Access-1(config-schedule)# dwrr queue 3 weight 10
ICX-Access-1(config-schedule)# dwrr queue 4 weight 10
ICX-Access-1(config-schedule)# dwrr queue 5 weight 10
ICX-Access-1(config-schedule)# dwrr queue 6 weight 10
ICX-Access-1(config-schedule)# dwrr queue 7 weight 10

8. Review the configuration.

ICX-Access-1(config-schedule)# show running-config current-context
qos schedule-profile icx
dwrr queue 0 weight 1
dwrr queue 1 weight 39
dwrr queue 2 weight 10
dwrr queue 3 weight 10
dwrr queue 4 weight 10
dwrr queue 5 weight 10
dwrr queue 6 weight 10
dwrr queue 7 weight 10
ICX-Access-1(config-schedule)# exit

9. Apply the new schedule profile to queue 1/1/27.

ICX-Access-1(config)# interface 1/1/27
ICX-Access-1(config-if)# apply qos schedule-profile icx
ICX-Access-1(config-if)# exit

10. Review the schedule profile list.

ICX-Access-1(config)# show qos schedule-profile
profile_status profile_name
-------------- ------------
applied factory-default
applied icx
complete strict

482 Task 13-5: Queue configuration

Task 13-6: LLDP-MED and voice VLAN configuration
Objectives
When phones are connected to a switch that supports LLDP-MED, the switch should be configured with
the correct voice VLAN. This will ensure that the switch announces this voice VLAN ID using LLDP-
MED to the phone, so the phone will automatically send its own traffic with the voice VLAN tag.
The switch can also be configured to control which LLDP TLV (type/length/value) information is sent

Lab 13: Quality of Service

out. This may be required for security purposes, so the access ports cannot see the firmware version of
the device.

Steps
Configure a voice VLAN
Access-1
1. On Access-1, configure VLAN 12 as the voice VLAN.
ICX-Access-1(config)# vlan 12
ICX-Access-1(config-vlan-12)# voice
ICX-Access-1(config-vlan-12)# exit

2. Review the active voice VLAN.

ICX-Access-1(config)# show vlan voice

------------------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces

------------------------------------------------------------------------------------------
12 VLAN12 up ok static 1/1/27,lag255

No further configuration is required. The LLDP-MED TLVs are automatically enabled on all inter-
faces. When an LLDP-MED capable device comes online, the switch will announce VLAN ID 12 as
the voice VLAN.
Review the advertised TLV information
3. Review the advertised TLVs.
ICX-Access-1(config)# show lldp tlv

TLVs Advertised
===============

Management Address
Port Description
Port VLAN-ID
System Capabilities
System Description

Task 13-6: LLDP-MED and voice VLAN configuration 483

 System Name
OUI
Port VLAN-Name
Dot1 Link Aggregation

Access-2
4. On Access-2, review the details of the LLDP neighbor on port 1/1/27 (Access-1).

You should verify the model number of Access-1 and Access-2. For example, in Pod
13 they are model JL668A.

ICX-Access-2(config)# show lldp neighbor-info 1/1/27

Port : 1/1/27
Neighbor Entries : 1
Neighbor Entries Deleted : 0
Neighbor Entries Dropped : 0
Neighbor Entries Aged-Out : 0
Neighbor System-Name : ICX-Access-1
Neighbor System-Description : Aruba JL668A FL.10.13.1000
Neighbor Chassis-ID : 10:4f:58:f6:e3:80
Neighbor Management-Address : 10.251.1.4
Chassis Capabilities Available : Bridge, Router
Chassis Capabilities Enabled : Bridge, Router
Neighbor Port-ID : 1/1/27
Neighbor Port-Desc : 1/1/27
Neighbor Port VLAN ID : 11
Neighbor Port VLAN Name : VLAN11,VLAN12
Neighbor Port MFS : 1500
Link aggregation supported : Yes
Link aggregation enabled : No
Aggregation port ID : 0
TTL : 120

Neighbor Mac-Phy details

Neighbor Auto-neg Supported : true
Neighbor Auto-Neg Enabled : false
Neighbor Auto-Neg Advertised : Other
Neighbor MAU type : 10 GIGBASEER

Neighbor EEE information : DOT3

Neighbor TX Wake time : 0 us
Neighbor RX Wake time : 0 us
Neighbor Fallback time : 0 us
Neighbor TX Echo time : 0 us
Neighbor RX Echo time : 0 us

Question: What is the firmware version of the peer switch?

484 Task 13-6: LLDP-MED and voice VLAN configuration

 Answer: Based on the output, the version is FL.10.13.1000.
Question: What is the management IP address?
Answer: Based on the output, the management IP is 10.251.1.4.
Access-1
5. On Access-1, change the LLDP configuration so the description and management IP are no
longer advertised.
ICX-Access-1(config)# no lldp select-tlv system-description

Lab 13: Quality of Service

ICX-Access-1(config)# no lldp select-tlv management-address

Access-2
6. Wait up to 30 seconds, then check the LLDP neighbors again on Access-2.
ICX-Access-2(config)# show lldp neighbor-info 1/1/27

Port : 1/1/27
Neighbor Entries : 1
Neighbor Entries Deleted : 0
Neighbor Entries Dropped : 0
Neighbor Entries Aged-Out : 0
Neighbor System-Name : ICX-Access-1
Neighbor System-Description :
Neighbor Chassis-ID : 10:4f:58:f6:e3:80
Neighbor Management-Address :
Chassis Capabilities Available : Bridge, Router
Chassis Capabilities Enabled : Bridge, Router
Neighbor Port-ID : 1/1/27
Neighbor Port-Desc : 1/1/27
Neighbor Port VLAN ID : 11
Neighbor Port VLAN Name : VLAN11,VLAN12
Neighbor Port MFS : 1500
Link aggregation supported : Yes
Link aggregation enabled : No
Aggregation port ID : 0
TTL : 120

Neighbor Mac-Phy details

Neighbor Auto-neg Supported : true
Neighbor Auto-Neg Enabled : false
Neighbor Auto-Neg Advertised : Other
Neighbor MAU type : 10 GIGBASEER

Neighbor EEE information : DOT3

Neighbor TX Wake time : 0 us
Neighbor RX Wake time : 0 us
Neighbor Fallback time : 0 us

Task 13-6: LLDP-MED and voice VLAN configuration 485

 Neighbor TX Echo time : 0 us
Neighbor RX Echo time : 0 us

You have completed Lab 13!

486 Task 13-6: LLDP-MED and voice VLAN configuration

Lab 14: REST API

Lab 14: REST API

In this lab, you will learn more about REST APIs and the REST API reference interface of AOS-CX
switches.

Objectives
In this lab, you will perform the following tasks:
n Perform the necessary configuration to use the RESP API.
n Use the REST reference interface to test different API functions.

Lab diagram
In this lab, you will focus on Access-1, which will be used for our tests.

Introduction to the REST API

The REST API can be accessed by using any REST client interface that supports HTTPS requests and
supports obtaining and passing a session cookie.
Examples of client interfaces to access the AOS-CX REST API include the following:

Lab 14: REST API 487

 n Scripts and programs that support HTTPS requests
l The most powerful way to access the AOS-CX REST API is to use a programming language
that supports HTTPS requests, such as Python, to write programs that automate network
management tasks.
n The curl command-line interface
l There are several tools available for accessing RESTful web service APIs, one of which is
curl. The curl project created the curl tool to be a command-line application for trans-
ferring data using URL syntax.
l You can use curl commands either interactively or within a script to make REST requests.
Using curl commands can be a way to execute GET requests without writing a script. Using
curl commands can also be a way to test REST requests that you are considering incor-
porating into an application.
l For details on installing the curl application, see https://curl.haxx.se/download.html.
l The curl application has many options described in detail in the curl manual (run curl --
manual) and at https://curl.haxx.se/docs/manpage.html.
n Browser-based interfaces such as Postman or the AOS-CX REST API Reference
l The AOS-CX REST API Reference is a web interface based on Swagger 2.0. The AOS-CX
REST API Reference does the following:
o Documents the switch resources, parameters, and JSON models for each HTTPS
method the resource supports. Because the AOS-CX REST API Reference is browser-
based, it can share the session cookie with a web UI session active in another
browser tab.
l The AOS-CX REST API Reference is not intended to be a configuration tool or required for
day-to-day operations.
l The AOS-CX REST API Reference is one way to execute GET requests without writing a
script. You can use the AOS-CX REST API Reference during script coding to help you con-
struct the URIs—with their query parameters—that you use in a script or curl command.
l For more information about Swagger, see https://swagger.io/.
l Postman
o Remember, developers can use any program and scripting language they want in a
REST client. The client needs to send valid REST requests to the interface.
o One choice for the tool is Postman, which you can obtain at
https://www.getpostman.com.

488
 o Postman is an open-source program for creating and scripting REST requests. It lets
you use a more intuitive interface to generate REST requests, rather than, for
example, curl, which is a command line utility.
l Python and Ansible are two popular scripting language tools developers often use to auto-
mate IT configurations. You will work with Python in the next lab.

Task 14-1: Enable access to REST API on the AOS-CX switch

Objectives
In this task, you will set up Access-1 with the required configuration for using the REST API.

Steps
Prepare the environment
1. Open a console connection to Access-1. Log in using admin/aruba123.
ICX-Access-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-1#

2. Open a console connection to Access-2. Log in using admin/aruba123.

Lab 14: REST API

ICX-Access-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Access-2#

3. Open a console connection to Core-1. Log in using admin/aruba123.

ICX-Core-1# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-1#

4. Open a console connection to Core-2. Log in using admin/aruba123.

ICX-Core-2# copy checkpoint icx-lab02-vsx running-config
Copying configuration: [Success]
ICX-Core-2#

Enable access to REST API

5. Using the remote lab dashboard, connect to the Access-1 console.
6. Enable the HTTPS server for the default VRF.
ICX-Access-1(config)# https-server vrf default

Note the HTTPS server was enabled already. In production environments, remember
to activate the HTTPS server at the desired VRF.

Task 14-1: Enable access to REST API on the AOS-CX switch 489
 7. Although you have set up the admin account with the password, you will create another admin
account named "restapi." The reason for creating this account is to be able to differentiate when
you review accounting logs.
ICX-Access-1(config)# user restapi group administrators password
Enter password: Aruba123
Confirm password: Aruba123

8. Set the REST API access mode to read-write.

ICX-Access-1(config)# https-server rest access-mode read-write

By default, the REST API is set to read-only mode, meaning only GET calls are avail-
able. Enabling the read/write mode on the REST API allows POST, PUT, and DELETE
operations to be called on all configurable elements in the switch database.
The REST API in read/write mode is intended for advanced users who understand
the switch database's system schema and data relationships.

CAUTION: Because the REST API is in read/write mode, it can access every con-
figurable element in the database. It is powerful, so you must use it with extreme cau-
tion. No semantic validation is performed on the data you write to the database; any
input you make will be written in the database.

9. Verify the REST API access configuration.

ICX-Access-1(config)# show https-server

HTTPS Server Configuration

----------------------------
VRF : default, mgmt

REST Access Mode : read-write

Max sessions per user : 6

Session idle timeout : 20

Session absolute timeout : 480

10. Enable port 1/1/1 and configure it as an access port for VLAN 11.
ICX-Access-1(config)# interface 1/1/1
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# vlan access 11
ICX-Access-1(config-if)# exit

11. Configure a default route.

ICX-Access-1(config)# ip route 0.0.0.0/0 10.1.1.1

490 Task 14-1: Enable access to REST API on the AOS-CX switch
 Task 14-2: REST reference interface
Objectives
In this task, you will learn to use the AOS-CX REST reference interface, which is based on the Swagger
interface. The Swagger UI is a web-based graphical representation of the API. It sits live on the switch,
and you can interact with the AOS-CX switch via this interface.

Steps
1. Using the remote lab dashboard, connect to PC1.
2. Open a browser (Google Chrome or Firefox), and navigate to Access-1 (https://10.1.1.4).
3. Accept the unknown certificate and continue to open the page. The switch web UI login page
should be displayed.
4. Log in using the following credentials:
n Username: admin
n Password: aruba123

Lab 14: REST API

5. To access the REST reference interface (Swagger), click the system menu (gear icon) in the top
right corner.

Task 14-2: REST reference interface 491

 6. Select v10.13 API.

Notice that the previous versions of the REST APIs are available for compatibility.

7. Before placing REST API calls, it is necessary to authenticate the session and obtain a session
cookie. To do so, scroll down to the Login section and expand it.

8. Select POST under Login. The Login post section will be expanded. Click Try it out.
9. Scroll down, enter the following credentials, and click Execute.
n Username: restapi
n Password: Aruba123

492 Task 14-2: REST reference interface

 Scroll down under the Responses section. You should see the curl code used for this request, the
URL used for this request, and a response code, which should be 200 (success).

The response codes inform if the switch accepted the request or if an error has

Lab 14: REST API

happened. Check the possible response codes and their meaning in the switch Swag-
ger interface.

10. Scroll down and check some of the possible responses for this request.

Task 14-2: REST reference interface 493

 11. Now that you are logged in to the REST API, you can look at other data on the switch. Scroll up
and expand the Firmware option.

12. Click GET /firmware.

13. Click Try it out.

14. Click Execute.

494 Task 14-2: REST reference interface

 15. Scroll down to the Responses section.
Notice the response code was 200 (success). Under Response body, you should see the firmware
version running in your switch.

Lab 14: REST API

You will now repeat the same action (GET) under VLAN to see a list of VLANs in the switch.
16. Scroll down and expand the VLAN section. Click GET /system/vlans, then click Try it out.

17. Scroll down and click Execute.

Task 14-2: REST reference interface 495

 18. Scroll down to the Responses section. You should have received a response code 200 (success).
Under Response body, you can see the VLAN configured on Access-1.

Lab debrief
In this lab, you learned how to use the REST reference interface of AOS-CX switches. Remember that
even though you have used the GET method—which is similar to a show command—during the lab,
methods such as POST, PUT, PATCH, and DELETE will actively modify the switch configuration.
The Swagger interface aims to give network administrators knowledge of the available APIs and a ref-
erence code and URI that can be used to integrate switches with other platforms.

496 Task 14-2: REST reference interface

Lab 15: HPE Aruba Networking Network Analytics
Engine (NAE)

Lab 15: HPE Aruba Networking Network Analytics Engine (NAE)

In this lab, you will configure NAE on switch Access-1 to monitor the device's hardware and con-
figuration changes. When the switch configuration is changed, the switch will automatically send a
backup of the config file using TFTP.

Objectives
In this lab, you will perform the following tasks:
n Upload and install a new NAE script.
n Configure NAE agents using the installed scripts to monitor switch hardware and configuration.

Lab diagram
In this lab, you will focus on Access-1, which will be used for our tests.

Task 15-1: Test the environment

Objectives
In this task, you will verify the required configuration for NAE to work properly and test your access to
the switch web UI.

Lab 15: HPE Aruba Networking Network Analytics Engine (NAE) 497
Steps
1. Using the remote lab dashboard, connect to the Access-1 console.
Once logged in, you will verify the switch time settings are configured for NAE to work properly.
2. Verify that the switch has the NTP server configuration:
ICX-Access-1(config)# show running-config | include ntp
ntp server 10.254.1.21 iburst
ntp server pool.ntp.org minpoll 4 maxpoll 4 iburst
ntp enable
ip source-interface ntp interface vlan1

3. Verify the NTP status.

ICX-Access-1(config)# show ntp status
NTP Status Information

NTP : Enabled
NTP DHCP : Enabled
NTP Authentication : Disabled
NTP Server Connections : Using the default VRF

System time : Fri Jul 19 09:25:45 EDT 2024

NTP uptime : 1 days, 15 hours, 30 minutes, 26 seconds

NTP Synchronization Information

NTP Server : 10.254.1.21 at stratum 4

Poll interval : 1024 seconds
Time accuracy : Within 0.002185 seconds
Reference time : Fri, Jul 19 2024 9:18:51.486 as per US/Eastern
ICX-Access-1(config)#

4. Verify the switch time. It should be in sync with USA Eastern Time.
ICX-Access-1(config)# show clock
Fri Jul 19 09:24:53 EDT 2024
System is configured for timezone : US/Eastern

5. Compare the switch time with the PC1 time; they should match.

The NAE UI displays data based on the browser time. NAE relies on accurate time.
Time drift might cause unexpected query results and chart rendering errors.

6. Using the remote lab dashboard, connect to PC1.

7. Open a browser (Google Chrome or Firefox), and navigate to Access-1 (https://10.1.1.4).

498 Task 15-1: Test the environment

 8. Accept the unknown certificate and continue to open the page. The switch web UI login page
should be displayed.

9. Log in using the following credentials:

n Username: admin
n Password: aruba123
You will be placed at the switch Overview page.

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking

Task 15-2: Review the built-in NAE script and agent

Objectives
In this task, you will:

Task 15-2: Review the built-in NAE script and agent 499
 n Get experience implementing an NAE script and agent.
n Review the built-in System Monitor NAE agent.
n Understand the meaning of parameters for an agent.
n Review the alerts and alert actions generated by an agent.

Steps
1. Open a session to PC1.
2. On PC1, open a web browser to the Access-1 IP (https://10.1.1.4).
3. Log into the web interface with admin/aruba123 credentials.
The Overview page will be displayed.

a. Navigate to the Analytics page by selecting Analytics in the left navigation pane. This will
display the Agents and the Scripts panes.

500 Task 15-2: Review the built-in NAE script and agent
 Scripts are the actual code that can be executed by NAE, while an agent is an instance of
the script. A script that is installed on the switch does not do anything by itself. An agent
must be created based on the script to start the actual monitoring.
One script may be instantiated multiple times, which would depend on the script:
n Some scripts may monitor all interfaces of the switch, so only one instance (agent)
would make sense
n Another script may only monitor one interface, where the interface that needs to be
monitored would need to be entered by the administrator. This interface name
would be a parameter on an agent. When the administrator wants to monitor two
interfaces, two agents would be created based on this script—one agent with inter-
face 1, the other agent with interface 2.
4. Click the Scripts link.

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking

5. There is one built-in script, called the "system_resource_monitor." This is system-created and
therefore cannot be deleted.

Task 15-2: Review the built-in NAE script and agent 501
 Example of script details
6. Click the name of the script (system_resource_monitor) to see the details of the script. A script
on the switch can also be downloaded to an administrator PC from this screen. The download is
optional; it is not required in this lab activity.

The window layout may appear different, based on your local computer’s screen res-
olution.

The development of the scripts themselves is beyond the scope of this training.
Please check the Configuring Network Automation Solutions course or consult the
product documentation to learn more about the scripts and the syntax.

7. Navigate back to Analytics to see the Dashboard screen.

502 Task 15-2: Review the built-in NAE script and agent
 8. Click the Agents link to open the Agents window.

9. This will list the default agent that is running on the switch. The agents are the actual running
instances of a script. In this case, there is a default agent that will be monitoring the system
resources. This happens out of the box.

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking
10. Click the name of the agent (system_resource_monitor) to see its details.
11. The default screen will show:
n The agent details (script that is used for this agent)
n The status
n The parameters that have been set for this agent
n The graph, if applicable
n The alerts, if applicable

Task 15-2: Review the built-in NAE script and agent 503
 Graph management
12. The switch has a local database that can store historical data for the agent. In the graph, the
administrator can check the history of the agent. Click the 1h, 1d, and Live links to explore the
differences.

Your actual graph will be different; the images in the lab guide were made on a sys-
tem that has been running for some time.

13. The admin can also apply a custom zoom by selecting a time range with the mouse (click and
drag).

504 Task 15-2: Review the built-in NAE script and agent
 14. The administrator can choose to disable certain lines on the graph by clicking them at the bot-
tom.

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking
Alerts
Agents can monitor various options in the system. When the agent is configured to compare a
value with some threshold, the agent can generate an alert when the threshold is exceeded.
The moment an alert is generated, the agent can simply display the alert, send out a syslog mes-
sage, or run some CLI commands and capture the output. These actions are defined in the script.
Change agent parameters
To see an example of an alert, the default parameters that control the threshold of the built-in
system monitor will be changed to extremely low values, which will trigger an alert.
15. In the Agent Details pane, click the pencil icon to edit the agent settings.

Task 15-2: Review the built-in NAE script and agent 505
 Under these settings, it is possible to enable or disable the agent. It is also possible to review or
update the agent parameters.
16. Update these parameters for the Average CPU / Memory utilization, expressed as a percentage:
n medium_term_high_threshold: 2
n medium_term_normal_threshold: 1

By setting the high_threshold for the average CPU/Memory to an extremely low num-
ber, the NAE system monitor agent will go into an Alert state.

17. Click SAVE to save the settings. Click CLOSE to close the pop-up window.

506 Task 15-2: Review the built-in NAE script and agent
 18. In about 60 seconds, a minor alert should be generated. The alert will be displayed at the top of
the screen in the top right corner, in the agent details' Status pane to the right of the Agent
Details pane, and in the graph bar (make sure Live is selected in the graph), displayed as an
orange line with an orange triangle. (Note that the color of the alert in the graph corresponds to
the alert level; in this example, since the alert is categorized as minor, the color is orange.)

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking
19. Open the details of the alert. This can be done either by clicking on the triangle in the graph or
by clicking on the alert in the alert list, and then clicking DETAILS.

Task 15-2: Review the built-in NAE script and agent 507
 20. In Alert Details, the administrator can see detailed information about the monitor that has
triggered the alert; in this case, either high memory or high CPU utilization will be indicated. In
this script, an alert will also capture CLI information from the switch, where this output is saved
as part of the alert. This is very convenient, since it allows the administrator to see additional
information about the state of the switch at that point in time.

21. Click the various Output links to see the details; this example shows the "show copp-policy
statistics" output (click Back to return to the Alert Details window).

508 Task 15-2: Review the built-in NAE script and agent
 22. Close the CLI details and the alert.
23. Click the pencil icon for Agent Details again, and assign high custom values so the alert can be
cleared again. Then click SAVE and CLOSE to confirm.
n medium_term_high_threshold: 91
n medium_term_normal_threshold: 81

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking

Task 15-2: Review the built-in NAE script and agent 509
 It may take a few minutes for the alert to clear again (where the status returns to a
normal state). There is no need to wait for this.

Task 15-3: Add a new NAE script and agent

Objectives
In this task, a new script and agent will be added to Access-1 to monitor link state changes on the
switch.

Steps
Install the new script
1. Using PC1, in the switch web UI, navigate to Analytics > Scripts.
2. Click the UPLOAD link to install a new script.

510 Task 15-3: Add a new NAE script and agent

 3. Click BROWSE, open the ICX-Files folder on the desktop, open the nae sub-folder, and select the
interface_link_state_monitor.1.0.py script, then click NEXT.

4. Review the script manifest data and click UPLOAD.

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking
5. Click CLOSE for the confirmation; the script will be shown in the list.

Create an agent based on the new script

6. Navigate to Analytics > Agents and define a new agent by clicking CREATE.

Task 15-3: Add a new NAE script and agent 511

 7. Select interface_link_state_monitor from the list and enter Agent Name iface-link-state-mon
then click CREATE.

8. Click CLOSE in the confirmation window.

9. Navigate to Analytics to see the new agent in the dashboard.

10. Select the name of the agent to see the details.

512 Task 15-3: Add a new NAE script and agent

 This script does not have any parameters; it simply monitors all the interface
transitions from up to down.

Test the link state agent

11. On Access-1, disable interface 1/1/3 and save the configuration.
ICX-Access-1(config)# interface 1/1/3
ICX-Access-1(config-if)# shutdown
ICX-Access-1(config-if)# write memory
Copying configuration: [Success]

12. Return to the switch Analytics Dashboard. The triangle will indicate the moment the alert was

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking
detected. The diamond will indicate that a new configuration was saved.

Task 15-3: Add a new NAE script and agent 513

 13. Click the red triangle in the graph to see the alert details. Review the captured CLI details by
clicking the Output hyperlinks.

Example of CLI details:

514 Task 15-3: Add a new NAE script and agent

 14. Click CLOSE to close the CLI output.
15. Click the purple diamond icon in the graph to see the details of the configuration change. This
can make it easy for an administrator to correlate an alert to a configuration change.

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking

Restore the interface

16. On Access-1, enable interface 1/1/3 and save the configuration.
ICX-Access-1(config-if)# interface 1/1/3
ICX-Access-1(config-if)# no shutdown
ICX-Access-1(config-if)# exit

Task 15-3: Add a new NAE script and agent 515

 ICX-Access-1(config)# write memory
Copying configuration: [Success]

17. Verify that the agent state is back to normal in the Analytics Dashboard. The Status pane should
show a green icon and display "Normal." In the Alerts section, you should see an event listed that
the link is now up ("Link Came UP"). In the graph, you should see a green arrow indicating the
interface status change. Also, the graph will display a bright blue line indicating that the status is
up (examine the graph key for the interfaces at the bottom of the graph).

18. In the Agent Details pane, select the pencil icon to edit the agent. Move the slider to the off state
to disable the agent. Click SAVE to save the settings; click CLOSE for the confirmation.

Task 15-4: OPTIONAL – Connectivity check

This task is optional and can be done if time permits. Check with your instructor. If you skip this task,
you can move to the next task.

516 Task 15-4: OPTIONAL – Connectivity check

Objectives
In this task, a connectivity check script will be installed and configured. This script relies on the IP-SLA
(Service Level Agreement) test feature set of the switch. An IP-SLA object in the switch is a "test client"
that can perform and repeat network tests, such as sending ICMP echo requests or HTTP get requests,
and keep track of the results.
In this task, an IP-SLA test will be created that will verify ICMP connectivity with the peer switch Core-
1. With the IP-SLA in place, the NAE script will now keep track of the IP-SLA object and will be able to
alert and monitor the results of the IP-SLA object.

Steps
Add IP-SLA on Access-1
1. On the Access-1 terminal, enter configuration mode.
2. Configure a new IP-SLA to send an ICMP echo to the IP of Core-1 every five seconds. Then start
the test.
ICX-Access-1(config)# ip-sla ping-core-1
ICX-Access-1(config-ip-sla-ping-core-1)# vrf default
ICX-Access-1(config-ip-sla-ping-core-1)# icmp-echo 10.255.101.2 probe-interval 5
ICX-Access-1(config-ip-sla-ping-core-1)# start-test
ICX-Access-1(config-ip-sla-ping-core-1)# exit

3. Wait about 10 seconds, then check the results of the IP-SLA test. The latest probe results should
show that one packet was received; this is the ICMP response from Core-1.
ICX-Access-1(config)# show ip-sla all
SLA Name : ping-core-1
Status : running
SLA Type : icmp-echo

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking
VRF : default
Source IP :
Source Interface :
Domain Name Server :
Payload Size : 0
TOS : 0
Probe Interval(seconds) : 5

IP-SLA session status

IP-SLA Name : ping-core-1
IP-SLA Type : icmp-echo
Destination Host Name/IP Address : 10.255.101.2
Source IP Address/IFName :
Status : running

IP-SLA Session Cumulative Counters

Total Probes Transmitted : 15

Task 15-4: OPTIONAL – Connectivity check 517

 Probes Timed-out : 0
Bind Error : 0
Destination Address Unreachable : 0
DNS Resolution Failures : 0
Reception Error : 0
Transmission Error : 0

IP-SLA Latest Probe Results

Last Probe Time : 2024 Jul 19 11:56:02
Packets Sent : 1
Packets Received : 1
Packet Loss in Test : 0.0000%

Minimum RTT(ms) : 0
Maximum RTT(ms) : 0
Average RTT(ms) : 0
DNS RTT(ms) :

------------------------------------------------------------------------------

This IP-SLA is now ready to be tracked by NAE.

Add script and agent for the connectivity reachability test
First, add a new script that can monitor IP-SLA objects.
4. On PC1, use a web browser to connect to Access-1. Navigate to Analytics > Scripts.
5. Upload the script "reachability.1.1.py":
a. Click UPLOAD in the top right corner.
b. Click BROWSE. Find and select the "reachability.1.1.py" script in the ICX-Files\nae folder.
c. Click NEXT. Examine the script information, including the name, which is "connectivity_
monitor." Notice that the author is "Aruba Networks."
d. Click UPLOAD.
e. Finally, click CLOSE to complete the upload.
f. Verify that you see the "connectivity_monitor" script.

6. Navigate to the Analytics > Agents window.

7. Click CREATE to create a new agent. Enter the following information:

518 Task 15-4: OPTIONAL – Connectivity check

 n Script: connectivity_monitor
n Agent Name: connectivity-ping-core-1
For the parameters, enter the following:
n Connectivity Check Rate: leave at the default (1 min)
n IP-SLA Session Name: ping-core-1

The IP-SLA session name must match with the IP-SLA object name that was created
in the previous step, which is "ping-core-1" in this lab guide.

8. Click CREATE to submit the new agent settings, and click CLOSE for the confirmation.
9. Once the agent has been created, select the agent to see the details. It should appear as Normal
(green).

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking

Task 15-4: OPTIONAL – Connectivity check 519

 10. Open a terminal to Core-1, and remove the IP address on interface VLAN 1. This will not cause a
"link down," as the first "link status" script would be able to detect. However, the ping will no
longer work, so this connectivity script should detect it.
ICX-Core-1(config)# interface 1/1/7
ICX-Core-1(config-if)# no ip address 10.255.101.2/24

11. Switch to the web UI of Access-1. Access Analytics in the left navigation pane. After one to two
minutes, the connectivity-ping-core-1 agent under the Agents pane should show a minor alarm
and then a critical alarm. Click connectivity-ping-core-1 to access the Agent Details screen.

12. In the Alerts window, select the most recent alert for the IP-SLA event and then click DETAILS.
Check the CLI output by clicking the Output hyperlink. The output should be familiar from when
you executed the show command previously after configuring and verifying SLA from the CLI.
NAE captures the IP-SLA state at the time of the alert.

520 Task 15-4: OPTIONAL – Connectivity check

 13. Click CLOSE.
Recover the alert
14. Reassign the IP address on Core-1.
ICX-Core-1(config-if)# ip address 10.255.101.2/24

15. Reaccess the Analytics Dashboard in the web UI. After about one minute, the alert should be
cleared. Notice that the Status pane will show a green icon and "Normal." The graph will indicate
a green arrow for when the condition was recovered.

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking

Task 15-4: OPTIONAL – Connectivity check 521

Task 15-5: Review the NAE agent in the switch configuration file
Objectives
In this task, the NAE script and agent settings will be reviewed in the switch configuration.

Steps
Review the running configuration
NAE script and agent information is stored in the switch’s configuration file. This ensures that a
backup/restore of the switch configuration will also maintain the configured monitoring solution.
1. On the Access-1 terminal, enter configuration mode and review the installed scripts.

The listed scripts may be different in your output based on the completion of the pre-
vious, optional task. This can be ignored.

ICX-Access-1(config)# show nae-script

---------------------------------------------------------------
Script Name Version Origin Status
---------------------------------------------------------------
connectivity_monitor 1.1 user VALIDATED
interface_link_state_monitor 1.0 user VALIDATED
system_resource_monitor 1.5 system VALIDATED

2. Review the NAE agents.

The listed agents may be different in your output based on the completion of the pre-
vious, optional task. This can be ignored.

ICX-Access-1(config)# show nae-agent

---------------------------------------------------------------------------------------------------------------------------------------
----------
Agent Name Script Name Version Origin Disabled Status Time Series Count Alerts Count
Rules Error
---------------------------------------------------------------------------------------------------------------------------------------
----------
connectivity-ping-core-1 connectivity_monitor 1.1 user false NORMAL 12 8 0
NONE
iface-link-state-mon interface_link_state_monitor 1.0 user true UNKNOWN 70 2 32
NONE
system_resource_monitor.default system_resource_monitor 1.5 system false NORMAL 10 4 6
NONE

3. Review the running configuration for lines that include the string "nae." The script and the agent
parameters are Base64 encoded in the configuration file.
ICX-Access-1(config)# show running-config | include nae
nae-script connectivity_monitor false ...
nae-script interface_link_state_monitor false ...
nae-agent connectivity_monitor connectivity-ping-core-1 false ipsla_session_
name:cGluZy1jb3JlLTE=

522 Task 15-5: Review the NAE agent in the switch configuration file
 nae-agent interface_link_state_monitor iface-link-state-mon true
nae-agent system_resource_monitor system_resource_monitor.default false medium_
term_high_threshold:OTE= medium_term_normal_threshold:ODE=

Review the switch NAE capacities

4. The switch can handle several scripts and agents. To review the currently active number of
scripts and agents versus the platform limits, use the show capacities-status nae command.
ICX-Access-1(config)# show capacities-status nae

System Capacities Status: Filter NAE

Capacities Status Name Value Maximum
------------------------------------------------------------------------------------
Number of configured NAE agents currently active in the system 3 10
Number of configured NAE monitors currently active in the system 8 130
Number of configured NAE scripts currently active in the system 3 10
Number of configured NAE watches currently active in the system 0 20

Network Analytics Engine (NAE)

Lab 15: HPE Aruba Networking

Task 15-5: Review the NAE agent in the switch configuration file 523
[This page intentionally left blank]

524 Task 15-5: Review the NAE agent in the switch configuration file
Lab 16: Troubleshooting

Lab 16: Troubleshooting

In this lab, you will learn how to use a structured approach for troubleshooting, which allows for more
assertive diagnostics and better response time.

Objectives
In this lab, you will perform the following tasks:
n Use a structured troubleshooting methodology.
n Apply the troubleshooting methodology to identify and fix a trouble ticket.

This lab emphasizes a structured troubleshooting methodology over specific tools, com-
mands, and management tools.

Lab 16: Troubleshooting 525

Lab diagram

Task 16-1: Prepare the lab starting configuration

Objectives
n This lab is built on the base VSX topology created at the end of Lab 2.
n Configuration files with an intentional bad configuration were provided for you to troubleshoot.

Steps (required)
1. Using the remote lab dashboard, connect to PC1.
2. Open the ICX-Files folder located on the PC1 desktop and navigate to the Troubleshooting lab
folder.

526 Task 16-1: Prepare the lab starting configuration

 Four configuration files should be available.

3. Using WordPad, open the access-1.cfg file and copy the file content.

Lab 16: Troubleshooting

Task 16-1: Prepare the lab starting configuration 527

 4. Using the remote lab dashboard, open a console connection to Access-1 and log in using
admin/aruba123.
5. Enter the configuration context.
ICX-Accsss-1# configure terminal
ICX-Accsss-1(config)#

6. Paste the configuration you copied from PC1 (right-clicking the CLI screen will automatically
paste the clipboard content).
7. Repeat steps 4 to 6 to copy and paste the new configuration files to Access-2, Core-1, and Core-
2.
PC3
8. Open a connection to PC3 and reset the Lab NIC (disable/enable).

528 Task 16-1: Prepare the lab starting configuration

 PC4
9. Open a connection to PC4 and reset the Lab NIC (disable/enable).

Lab 16: Troubleshooting

Task 16-1: Prepare the lab starting configuration 529

Task 16-2: Support ticket troubleshoot
Objectives
In this task, you will use a troubleshooting methodology to identify the issue in a support case, analyze
the issue's impact, generate a hypothesis, validate the hypothesis, implement the solution, and verify
that the issue has been resolved.
You have deployed a network refresh, replacing old switches with brand-new AOS-CX switches. Two
8325s were deployed as core switches in a VSX pair, and 6300s were deployed as access switches. A
collapsed core topology was chosen, with routing (L3) being done by the core layer.
The next morning, several users complained that they had lost access to the network. It is not clear if
the issue is impacting the entire network or a group of users.
After the first-level support team received several calls with the same complaint, the case was
escalated to you as the senior network engineer to investigate and troubleshoot.
Network topology

Sample support ticket

User: John Doe
Priority: Urgent

530 Task 16-2: Support ticket troubleshoot

 Day: Monday
Time: 8:05 a.m.
Description: John Doe, a contingent employee, reported that once he logged on to his computer, he
noticed that he had no network access.

Steps
1- Identify
In this step, you focus on identifying the issue and narrowing it down as close as possible to the
affected devices, isolating the problem. You will start determining if the issue affects all users or a spe-
cific group.
PC3
1. Using the remote lab dashboard, connect to PC3.
2. Open a web browser and try to navigate to the ISS server (10.254.1.21). Navigation should be
successful.

This validates that PC3 has access to the data center servers.
3. Open a command prompt and verify the IP address assigned to PC3.
Lab 16: Troubleshooting

Task 16-2: Support ticket troubleshoot 531

 4. Ping the Router-A (10.255.101.11) interface to check reachability to the edge router. The ping
should succeed.

5. Using the remote lab dashboard, connect to PC4.

6. Open a web browser and try to navigate to the ISS server (10.254.1.21). Navigation should be
unsuccessful.

532 Task 16-2: Support ticket troubleshoot

 As per the test, PC4 has no access to the data center server.
7. Open a command prompt and test PC4 reachability to Router-A (10.255.101.11). The ping
should fail.

8. Test a ping to the ClearPass server (10.254.1.23). The ping should fail.

You now know that PC4 is not able to reach the servers or Router-A.
9. Verify PC4 IP addressing.
Lab 16: Troubleshooting

Task 16-2: Support ticket troubleshoot 533

 Notice that PC4 has no IP address on interface Lab NIC.

2- Analyze
In this step, you will focus on analyzing the problem, affected devices, switch configurations, logs,
and change history.
You now know that not all users were affected by the issue. It is time to analyze the problem and
the data, trying to narrow down the scope and possible causes.
10. Using the remote lab dashboard, connect to PC4.
11. As you noticed in the previous step, PC4 does not have an IP address on the Lab NIC card. Issue
an ipconfig /renew command to try to obtain an IP address.

It may take up to a minute for the command to fail.

12. As you have noticed, the PC is failing to obtain an IP address. It could be a connectivity problem.
Connect to the Access-2 console and check interface 1/1/4 status.
ICX-Access-2(config)# show interface 1/1/4 brief
--------------------------------------------------------------------------------------------------------
Port Native Mode Type Enabled Status Reason Speed Description
VLAN (Mb/s)
--------------------------------------------------------------------------------------------------------
1/1/4 12 access 1GbT yes up 1000 --

Notice that the interface is enabled and active (UP). Also, notice that it is assigned to VLAN 12.
13. Verify VLAN 12 assignments on Access-2.

534 Task 16-2: Support ticket troubleshoot

 ICX-Access-2(config)# show vlan 12

-----------------------------------------------------------------------------------------
VLAN Name Status Reason Type Interfaces
-----------------------------------------------------------------------------------------
12 VLAN12 up ok static 1/1/4,lag255

Notice that VLAN 12 is assigned to port 1/1/4 (connected to PC4) and LAG 255 (connected to
core switches).
14. Verify LAG 255 status.
ICX-Access-2(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
----------------------------------------------------------------------------------
1/1/25 lag255 26 1 ALFNCD 10:4f:58:fc:b2:40 65534 255 up
1/1/26 lag255 27 1 ALFNCD 10:4f:58:fc:b2:40 65534 255 up

Partner details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
----------------------------------------------------------------------------------
1/1/25 lag255 2 1 ALFNCD 02:01:00:00:01:00 65534 2
1/1/26 lag255 1002 1 ALFNCD 02:01:00:00:01:00 65534 2

Notice that the flags indicates that the link aggregation is working properly.
15. Using the remote lab dashboard, connect to Core-1.
16. Verify VLAN 12 on Core-1.
ICX-Core-1(config)# show vlan 12

-----------------------------------------------------------------------------------
Lab 16: Troubleshooting

-----
VLAN Name Status Reason Type Interfaces

-----------------------------------------------------------------------------------
-----
12 VLAN12 up ok static lag1-lag2,lag5,lag256

Task 16-2: Support ticket troubleshoot 535

 Notice that VLAN 12 is mapped to LAG 1 (connected to Access-1), LAG 2 (connected to Access-
2), LAG 5 (connected to the gateway), and LAG 256 (between Core-1 and Core-2).
17. Verify the LAGs on Core-1.
ICX-Core-1(config)# show lacp interfaces

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State
----------------------------------------------------------------------------------
1/1/1 lag1(mc) 1 1 ALFNCD 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 2 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 5 1 ALFNCD 02:01:00:00:01:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256 up

Partner details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
----------------------------------------------------------------------------------
1/1/1 lag1(mc) 26 1 ALFNCD 14:ab:ec:cd:8a:80 65534 255
1/1/2 lag2(mc) 26 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc) 2 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256

18. Verify LAG 2 status on Core-2 by using the vsx-peer option on Core-1.
ICX-Core-1(config)# show lacp interfaces vsx-peer

State abbreviations :
A - Active P - Passive F - Aggregable I - Individual
S - Short-timeout L - Long-timeout N - InSync O - OutofSync
C - Collecting D - Distributing
X - State m/c expired E - Default neighbor state

Actor details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr Forwarding
Name Id Pri Pri Key State

536 Task 16-2: Support ticket troubleshoot

 ----------------------------------------------------------------------------------
1/1/1 lag1(mc) 1001 1 ALFNCD 02:01:00:00:01:00 65534 1 up
1/1/2 lag2(mc) 1002 1 ALFNCD 02:01:00:00:01:00 65534 2 up
1/1/5 lag5(mc) 1005 1 ALFNCD 02:01:00:00:01:00 65534 5 up
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:8e:00 65534 256 up

Partner details of all interfaces:

----------------------------------------------------------------------------------
Intf Aggr Port Port State System-ID System Aggr
Name Id Pri Pri Key
----------------------------------------------------------------------------------
1/1/1 lag1(mc) 27 1 ALFNCD 14:ab:ec:cd:8a:80 65534 255
1/1/2 lag2(mc) 27 1 ALFNCD 10:4f:58:fc:b2:40 65534 255
1/1/5 lag5(mc) 3 255 ASFNCD 20:4c:03:b1:d4:2a 32768 2
1/1/46 lag256 47 1 ALFNCD b8:d4:e7:40:6d:00 65534 256
1/1/47 lag256 48 1 ALFNCD b8:d4:e7:40:6d:00 65534 256

19. Since the VLAN configuration looks appropriate and the LAGs and physical links are ok, check
the VLAN 12 configuration.
ICX-Core-1(config)# show running-config interface vlan 12
interface vlan 12
vsx-sync active-gateways policies
ip address 10.1.12.2/24
active-gateway ip mac 02:02:00:00:01:00
active-gateway ip 10.1.12.1
l3-counters
ip helper-address 10.1.1.7
exit

20. Verify interface VLAN 11 configuration, as you have noticed that PC3, which is connected to
VLAN 11, is working properly.
ICX-Core-1(config)# show running-config interface vlan 11
interface vlan 11
vsx-sync active-gateways policies
ip address 10.1.11.2/24
active-gateway ip mac 02:02:00:00:01:00
active-gateway ip 10.1.11.1
l3-counters
ip helper-address 10.1.1.6
exit
Lab 16: Troubleshooting

3- Hypothesis
In this step, you formulate a hypothesis based on the data gathered during the first and second
steps.

Task 16-2: Support ticket troubleshoot 537

 21. Notice that the IP helper IP address is different between VLAN 11 and VLAN 12. This might be
the problem.
22. As you were not informed of a new DHCP server in the network, it could indicate a configuration
error during the configuration of the new switches.
4- Validate
In this step, you will validate your hypothesis by testing it and observing the results.
In the previous step, you identified that the IP helper address is different between VLAN 11 and
VLAN 12. There are several ways to test your hypothesis; you will start by ensuring PC4 has con-
nectivity to VLAN 12 and the data center by using a static IP address.
23. Connect to PC4 and manually assign the following IP address:
n IP address: 10.1.12.100
n Subnet mask: 255.255.255.0
n Default gateway: 10.1.12.1
n Preferred DNS server: 10.254.1.21

24. Open a command prompt and test a ping to the AD server (10.254.1.21). The ping should suc-
ceed.

538 Task 16-2: Support ticket troubleshoot

 5- Implement
In this step, you will implement the solution based on the validation phase's positive test.
You now know that it is not a connectivity problem or a bad VLAN configuration. This indicates
that the wrong IP helper address could be causing the problem.
25. To test your hypothesis, you will change the IP helper address on Core-1 and Core-2 to the
DHCP server IP address assigned to VLAN 11.
26. Connect to the Core-1 console and navigate to interface VLAN 12.
27. Change the IP helper address 10.1.1.6.
ICX-Core-1(config)# interface vlan 12
ICX-Core-1(config-if-vlan)# ip helper-address 10.1.1.6
ICX-Core-1(config-if-vlan)# no ip helper-address 10.1.1.7
ICX-Core-1(config-if-vlan)# exit

28. Clear the DHCP-relay statistics.

ICX-Core-1(config)# clear dhcp-relay statistics

6- Verify
In this step, you will verify whether the applied solution has solved the issue.
29. Connect to PC4 and configure it to use DHCP for the Lab NIC.

Lab 16: Troubleshooting

Task 16-2: Support ticket troubleshoot 539

 30. Open a command prompt and verify that PC4 has received a dynamic IP address.

31. Ping the ClearPass (10.254.1.23) server to test connectivity to the data center. The ping should
succeed.

540 Task 16-2: Support ticket troubleshoot

 32. Connect to the Core-1 console and check the DHCP statistics.
ICX-Core-1(config)# show dhcp-relay

DHCP Relay Agent : enabled

DHCP Smart Relay : disabled
DHCP Request Hop Count Increment : enabled
L2VPN Clients : enabled
Option 82 : disabled
Source-Interface : disabled
Response Validation : disabled
Option 82 Handle Policy : replace
Remote ID : mac

DHCP Relay Statistics:

Valid Requests Dropped Requests Valid Responses Dropped Responses

-------------- ---------------- --------------- -----------------
2 0 2 0

DHCP Relay Option 82 Statistics:

Valid Requests Dropped Requests Valid Responses Dropped Responses

-------------- ---------------- --------------- -----------------
0 0 0 0

You have verified that PC4 is now able to receive an IP address using DHCP, and it is able to
access the data center.
You have completed Lab 16!
Lab 16: Troubleshooting

Task 16-2: Support ticket troubleshoot 541

Implementing AOS-CX Switching
LAB GUIDE
Version: 24.31
Copyright 2024