LAB GUIDE

NetEdit 2.1 - Part 2 – Multi-

Editor
IMPORTANT! THIS GUIDE ASSUMES THAT THE AOS-CX OVA HAS BEEN INSTALLED AND WORKS IN GNS3
OR EVE-NG. PLEASE REFER TO GNS3/EVE-NG INITIAL SETUP LABS IF REQUIRED.
https://www.eve-ng.net/index.php/documentation/howtos/howto-add-aruba-cx-switch/

TABLE OF CONTENTS
Lab Objective ................................................................................................................................................. 2
Lab Overview ................................................................................................................................................. 2
Lab Network Layout ....................................................................................................................................... 2
Lab Task 1. Changing Configurations using the Multi-Editor ......................................................................... 2
Lab Task 2. Creating and Using Change Validation Tests ............................................................................ 8

1
Lab Objective
This is the first of a NetEdit lab series. At the end of the lab series, you will be able to operate an Aruba AOS-CX Network using
Aruba NetEdit 2.1.

Lab Overview
In this second lab of the NetEdit Series, you will Configure the CX switches using the Multi-Editor Tool.

This lab requires is the continuation of Lab 1 and assumes that:

• you have completed Lab 1

• the configuration of the switches is still active
• NetEdit is in the same state as it was at the end of Lab 1

Lab Network Layout

Figure 1. Lab topology and addresses

Lab Task 1. Changing Configurations using the Multi-Editor

Part 1 – Enable ports and assign them an IP address
Access Switches

• Go to the Devices page and select both access switches. Then use the ACTION menu to select . This action
will take you to the Multi-Editor.
• On the left panel you will find the list of devices being edited. In the central panel, you will find the editor. And on the right
panel you will find the Insights.
• In the editor panel, scroll the configuration until you find the command: vlan 1
• Add two more VLANs at the end of the list to obtain (do not add spaces after the comma)
vlan 1,10,20

2
• When you hit enter, an empty line will be created. Create the LAG 1 interface
• Note: You will create a LAG with a single port as in this environment there is a single cable between each access switch
and the core. However, using a LAG has 2 advantages: first, it follows best practices; and second, it will allow you to monitor
the LAG state using the network analytics engine (NAE).
interface lag 1
• This command creates a configuration context in which all of the configurations for that LAG must be entered.
Note: The editor moves any new context to its right position in the command sequence

• Enable the LAG. These context specific commands must be indented using 4 spaces or 1 tab) under the interface
command.
interface lag 1
no shutdown
• Here you will see your new conformance test in action. As soon as you entered the no shutdown command, the interface
line received a yellow underline and a yellow warning sign on the left.

• Move your mouse over the line and a popup will tell you that ‘description’ must exist.
• Add a description to the interface:
interface lag 1
no shutdown
description UPLINK-1
• Notice that the warning disappeared.

• Complete the LAG configuration, including: routed mode, LACP active mode, and IP address
interface lag 1
lacp mode active
no shutdown
description UPLINK-1
routing
ip address 10.0.1.2/30
At this point, you have two devices with the same IP address in their uplink! To resolve the conflict, right-click on the IP
address and change the address of the second switch (ACC1B) to 10.0.1.6/30.

3
 Notice that the IP address was replaced with a generic value. If you position your mouse over this generic IP address, you
will see both values.

• Scroll down to locate interface 1/1/8 (existing link to COR1A). Assign it to LAG 1.

interface 1/1/8
description LAG1PORT1
no shutdown
mtu 2048
lag 1

Reviewing the changes

At the top of the editor panel find these 3 options and click on VIEWS. In the popup,
select DIFF.

The DIFF view, as its name implies, shows the running configuration in the left panel, and the candidate configuration on the
right panel.

• Scroll down to lines 121-125 and compare the “before and after” of the interface 1/1/8.
Validating the configuration

• Click on the VALIDATE icon.

• Look at the bottom-right corner. A pop-up box will show the result of the validation.
Note: For this operation NetEdit uses the REST interface of each switch to send the correspoding configuration to each one
of them with a validation request. Each switch creates a copy of the relevant parts of its configuration and state database
(CSDB) and runs the configuration command by command to test the validity. Notice that the running configuration of the
switch is not modified during this process.

• If the configuration is valid, you will be able to proceed to deploy it (changing the running configuration). For that purpose,
click on the RETURN TO PLAN icon. The Configuration Plan page will open and will allow you to deploy the new
configuration.
• But before applying it, observe the following:

o Device Validation (the process you just run) shows “Passed” for both switches.
o Conformance shows “Passed”
Important: a failed Device Validation will disable the DEPLOY button, but a failed Conformance will not.

4
• Change Validation shows “Not Run”
• Now, click DEPLOY and observe the state of the Change Validation. It will first change to ”Started” and then to “Refreshed”.
At this point the available buttons have changed:

• The EDIT button is now VIEW (it will take you back to the editor, but it will be in read only mode)
• The DEPLOY is now disabled (grey)
• There are two new buttons:
o ROLLBACK: allows you to return the switches to their previous configuration, and to return to the Editor in read-
write mode
o COMMIT: save the new configuration and closes the change plan. If you need to make other configuration
changes, you have to start a new plan (select the switches and choose the Edit Config action)
Change Validation

• But before deciding if you want to rollback or commit, you must validate the changes. Click on the Change Validation option
and the results page will pop up. It displays a list of “show” commands the run on each device.
• Look for a green > sign and click on it to expand and display the command’s output.
Note: The change validation process uses SSH to connect to each switch and run each CLI command (it is the only process
in NetEdit that uses SSH). NetEdit populates the left panel running the CLI commands before deploying the new
configuration, and the right panel running them again after the configuration deployment.

Showing the “before” and “after” results side-by-side enables you to analyze the impact of the configuration change on the
device and network state.

• Scroll the whole list to identify the output of the different show commands and analyze every option on that popup window.
In particular, expand the show interface brief command output and scroll down to find: 1/1/8 – Waiting for Link, and lag 1 –
down (this is correct, as the other end of the links on COR1A have not been configured yet).
Note: You will learn how to create your own change validation scripts later in this lab.

• Close the change validation window and COMMIT the configuration.

Core Switch

Return to the Device list, select the COR1A switch and in the ACTION menu select Edit Config.

5
• In the editor make the following configuration changes
• Create both LAG interfaces to ACC1A and ACC1B

interface lag 1
lacp mode active
no shutdown
routing
description DOWNLINK1A
ip address 10.0.1.1/30
interface lag 2
lacp mode active
no shutdown
routing
description DOWNLINK1B
ip address 10.0.1.5/30

• Assign interfaces 1/1/2 and 1/1/2 to LAG 1 and LAG 2 respectively

interface 1/1/1
no shutdown
description LAG1-PORT1
mtu 2048
lag 1
interface 1/1/2
no shutdown
description LAG2-PORT1
mtu 2048
lag 2

• VALIDATE the changes

• RETURN TO PLAN and DEPLOY
• Review the change validation results and verify that interfaces 1/1/1, 1/1/2, lag1, and lag2 are up

Note: If any of the lags show as blocked, go to the top right and REFRESH to allow for more time to converge

• Click OK
• Finally COMMIT the changes.
• To verify that the connections are up, return to the Network page
Note: if the links do not show up in the topology, wait a few minutes.

• Rearrange the switches to show the topology.

6
NetEdit Network Page Tools
Create an Access Switch Group (do not confuse with the Access Switch query)

• Select both access switches, right-click and select group. Create a group called ACCESS.

• Notice that the group box includes the group name, and a summary of the NAE agent status (Green N circle).
Note: NAE agents will be installed in the Lab Activity 7.

• Move the group box around to understand how it can be used to improve the topology graph.
Modify the properties displayed by toggling options on the left panel

Notice that all property groups on the left panel are enabled by default.

• On the left panel, toggle-off the Device properties group –

• Notice that the green N (NAE status) is now a gray question mark

• Toggle the Device properties group on

7
• Select the Core switch.

• Take a few minutes to scroll the right panel and observe the different level of information offered.
• In the Health Summary box, expand the Bridging properties

• Note: The Consistency Check verifies VLAN configuration consistencies on all links. For example, on a layer 2 link
configured as a VLAN trunk, it will check that the same VLANs are “allowed” at both ends of the link. As in this lab you are
using L3 links, no VLANs are assigned to these links.
• Expand the Properties, General Hardware, Interfaces boxes and scroll down to learn what information is provided

Lab Task 2. Creating and Using Change Validation Tests

Note: It is recommended to have a specific change validation test before editing the configuration of one or more switches.

Create the OSPF change validation test

• Go to the Settings page , Validation option and Change Validation tab .

• Start by exploring the change validation features

Notes:

• A change validation test is created as a Command Mapping

• A Command Mapping assigns one or more Command Scripts to a group of devices: all, or a subset selected by a Query,
or a list of Resources
• A Command Script is a sequence of CLI commands that can be run on a device via SSH
• A Resource is a network device that
o Does not run AOS-CX
o Supports SSH
o Examples: servers, mobility gateway, AP, router, etc.
o In this case, the scripts must be written using the resource’s specific CLI commands
Create a new script.

• Scroll down to the Command Scripts option, expand it and use the icon to open a command script form and enter the
script
Name: OSPF

Description: OSPF State Validation

Commands:
show ip ospf 1
show ip ospf interface brief
show ip ospf neighbor

• Click ADD to confirm

Add the OSPF command script to the built-in Routing State command mapping

8
• Open the Routing State command mapping
• Select OSPF and click OK

Configure OSPF routing

• Return to the Devices page

• Select all three switches and in the ACTION menu select EDIT CONFIG
Note:
• When multiple devices are being edited simultaneously, the Multi-Editor shows configuration differences by
highlighting the parameter or command using a blue background

• Highlighted parameter: the value is different on each device

• Highlighted command: the line exists on one or more of the devices but not all
• Add the OSPF ROUTER configuration

• As the router-id must be different across all devices, right-click on it to open the parameter form and assign:

9
 ACC1A: 10.254.1.2
ACC1B: 10.254.1.3
COR1A: 10.254.1.1

• Configure the loopback interfaces

• Right-click on the IP address to open the parameter form and assign the right value to each switch
ACC1A: 10.254.1.2/32
ACC1B: 10.254.1.3/32
COR1A: 10.254.1.1/32

Note: to enable OSPF on the interface, you will proceed in two steps: first, you will deselect the core switch and configure the
uplinks of the access switches, then you will select just the core switch and configure the downlinks.

• In the left panel, deselect the core switch

• Go to the interface 1/1/8 (uplink) and add the OSPF commands:

ip ospf 1 area 0
ip ospf network point-to-point
no ip ospf passive

10
• Select the Core switch (only)

• Configure OSPF on both downlinks (1/1/1 and 1/1/2)

ip ospf 1 area 0
ip ospf network point-to-point
no ip ospf passive

Validate the configuration, and deploy.

• At the top of the editor panel find these 3 options and click on VALIDATE
• If the validation is successful, RETURN TO PLAN and DEPLOY
• Open Change Validation
• Analyze the outputs of the commands included in the OSPF script
show ip ospf 1
show ip ospf interface brief
show ip ospf neighbor
• Focus on the COR1A neighbors list and verify that both access switches have been discovered

Note: in the screen capture shown above, notice that the state of the neighbors is INIT. In the case of routing protocols like
OSPF, reaching the FULL state takes longer than the time it takes NetEdit to run the second part of the change validation

11
 process.

• Use the refresh button at the top right to repeat the validation and allow for the routing processes to synchronize

• Go back to outputs and verify that the state is now FULL

• Close the validation window (OK)

• COMMIT the changes

Important: Keep the lab as it is at this point for the NetEdit 2.1 Part 3

12
 Document type
Headline text

www.arubanetworks.com
3333 Scott Blvd. Santa Clara, CA 95054
1.844.472.2782 | T: 1.408.227.4500 | FAX: 1.408.227.4550 | info@arubanetworks.com
13