ACE 2.1.1 - Lab Guide - HPE Trainers

Arista Configuration Essentials
(ACE)
Version 2.1.1

Lab Guide

Arista Configuration Essentials Lab Guide - 2.1.1
Table of Contents
1 Lab Overview ......................................................................................................... 2
2 Accessing the Lab ................................................................................................... 4
3 CLI & BASH ............................................................................................................. 7
4 Aboot ................................................................................................................... 10
5 Upgrade EOS ........................................................................................................ 18
6 EOS Architecture .................................................................................................. 21
7 Zero Touch Provisioning (ZTP) .............................................................................. 26
8 Multi-Switch CLI ................................................................................................... 32
9 Multi-Chassis LAG (MLAG) .................................................................................... 39
10 BGP Equal Cost Mult-Pathing (ECMP) ................................................................. 49
11 Virtual Extensible LAN (VXLAN) Bridging ............................................................. 57
12 Advanced Event Manager (AEM) ........................................................................ 65
Cli Scheduler .............................................................................................................................................................. 65
Event Handler ............................................................................................................................................................ 67
Event Monitor ............................................................................................................................................................ 70
13 Latency Analyzer (LANZ) ..................................................................................... 72
14 VM Tracer .......................................................................................................... 76
15 Advanced Mirroring ........................................................................................... 83
16 Tap Aggregation ................................................................................................. 92
17 Extensible API (eAPI) ........................................................................................ 109
eAPI Prep (Optional) ............................................................................................................................................. 109
eAPI Lab .................................................................................................................................................................... 111
18 Appendix A: BGP Route Selection Decision Process .......................................... 115
19 Appendix B: Answers to Lab Questions ............................................................. 116
Copywrite 2012-2016 Arista Networks

No duplication without written consent - Prepared for HPE Trainers 1-31-17 Page 1
1 Lab Overview
Lab Rules:
NOTE: Configuration management for the lab is controlled through a mix of ZTP, eAPI,
Python, and Perl, scripting, all of which relies on the following configurations to
function:
• Do not change or remove the Management IP address.

• Do not change or remove the eAPI configuration.
• Do not change or remove the Script or Class users.
• Do not change or remove the login banner.
• Do not change or remove the hostname.
• Do not add a password to the admin user.
• Do not add an enable secret password.
• Please do not log onto other student’s switches unless you’re
helping them and have their permission.

Lab Description:
The lab is constructed such that every pair of switches is connected to the spine switches
in the following fashion:

Each pair is comprised of two switches, starting with the odd-numbered switch. In other
words, the MLAG pairs are as follows:
student-01 + student-02 student-11 + student-12

NOTE: You will need to work with the person who has the other switch in your MLAG
pair.


2 Accessing the Lab

Lab Objectives:
In this activity, you will:

• Establish an SSH connection with the Linux lab management server.
• Establish an SSH connection FROM the Linux Lab management server to your
student lab switch.
• Establish a console connection FROM the Linux Lab management server to your
student lab switch.
See Instructor for the following lab access details:

1. Linux Magement Server
2. Student Username
3. Password
TASK 1: Connect to the Lab Management Linux Server via SSH.
Step 1
Using your favorite SSH client, SSH to the Linux Lab Server (FQDN provided by
instructor)
NOTE: The SSH examples below show direct ssh connection using command-line, but
programs such as Putty, Secure-CRT, etc. all work fine. They may, however, require
more setup. In addition, all examples use “alab.arista.com,” but your lab rack may be
different. Check with your instructor.
Username = stxx (case sensitive, xx represents your student number)

Ask instructor for password
NOTE: Example below is shows direct SSH using command-line.
$ ssh st01@alab.arista.com
st01@alab.arista.com's password:
+---------------------------------------+
| Device: A-Lab Linux Host |
| |
| Purpose: Training Class Lab |
| Owner: Training Department |
| Email: training-team@arista.com |
+---------------------------------------+
+--------------------------------------------------------------------+
|To connect to your switch, type the switch name. |
|To connect to the console of your switch, type console switchname. |
| |

|Examples: |
| |
| student-05 # SSH to student-05 as admin |
| console student-05 # Telnet to the console of student-05 |
+--------------------------------------------------------------------+
Last login: Wed Aug 20 13:34:24 2014 from static-96-245-68-

206.phlapa.fios.verizon.net
st01@ALab-Linux:~$
Step 2
To log out from the Linux Lab Server, simply type “exit”.
st01@ALab-Linux:~$ exit
logout
Connection to alab.arista.com closed.
$
TASK 2: Connect to the your switch via SSH.
Step 1
For SSH access to your switch from the Linux Lab Server, type “student-xx” (xx
represents your student number).
st01@ALab-Linux:~$ student-01
Warning: Permanently added 'student-01,10.0.0.1' (RSA) to the list of
known hosts.
+---------------------------------------+
| Switch: Student-01 |
| |
| Purpose: Training Lab A (alab) |
| Owner: Training Dept. |
+---------------------------------------+
Last login: Fri Aug 22 13:48:46 2014 from 10.0.0.100
Student-01>enable
Student-01#
Step 2
To log out from your switch, simply type “exit”.
Student-01#exit
Connection to student-01 closed.
st01@ALab-Linux:~$
TASK 3: Connect to the your switch via Console.
Step 1
From the Linux Lab Server, type “console student-xx”.

Step 2
If/When you are prompted for a username, type “admin” (no quotes) and press enter.
NOTE: You may have to press enter more than once to get a prompt. Also, there will be a
delay when connecting to the console.
Step 3
Once connected, type “enable” to enter enable mode. To disconnect from the console,
press control -], then type quit.
st01@ALab-Linux:~$ console student-01
Attempting connection to console of student-01...
.----------------------------------------------.
| |
| To disconnect, hit control-], then type quit |
| |
'----------------------------------------------'
Trying 10.255.255.200...
Connected to 10.255.255.200.
Escape character is '^]'.
+---------------------------------------+
| Switch: Student-01 |
| |
| Purpose: Training Lab A (alab) |
| Owner: Training Dept. |
+---------------------------------------+
Student-01 login: admin
Last login: Tue Aug 19 19:57:33 on ttyS0
Student-01>enable
Student-01#
telnet> quit
Connection closed.
st01@ALab-Linux:~$
End of lab

3 CLI & BASH

Lab Objectives:
In this activity you will:

• Execute a number of commands on the CLI.
• Interact with the BASH shell and navigate the Linux file structure.
TASK 1: Get Familiar with the running config.
Step 1
Execute the following CLI commands on your switch to familiarize yourself with the
config.
Show run
Show lldp neighbors
Show interfaces status connected
Show ip route
Step 2
Explore the aliases
Step 3
Feel free to run other various commands you may be familiar with from other platforms.
TASK 2: Enter BASH and get familiar with the file structure.
Step 1
Enter bash on your switch- Type “bash”. To exit bash type “exit”.
Student-05#bash
Arista Networks EOS shell
[admin@Student-05 ~]$
Step 2
Show the interfaces on the switch using the “ifconfig –a” command.

[admin@Student-05 ~]$ ifconfig -a

cpu Link encap:Ethernet HWaddr 00:1C:73:68:D7:F7
UP BROADCAST RUNNING MULTICAST MTU:9216 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
et1 Link encap:Ethernet HWaddr 00:1C:73:68:D7:F7

UP BROADCAST RUNNING MULTICAST MTU:9214 Metric:1
RX bytes:0 (0.0 b) TX bytes:2724658 (2.5 MiB)

UP BROADCAST MULTICAST MTU:9214 Metric:1

UP BROADCAST MULTICAST MTU:9214 Metric:1
<output omitted>
Step 3
Issue the “top” command. Inspect the output including items such as the load average,
% CPU and % MEM for processes, etc. Break out of top by typing “control-c”.
admin@Student-05 ~]$ top
top - 00:58:47 up 11:31, 3 users, load average: 0.04, 0.05, 0.10

Tasks: 204 total, 1 running, 203 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.6%us, 1.7%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 4017112k total, 2101608k used, 1915504k free, 164552k
buffers
Swap: 0k total, 0k used, 0k free, 1328684k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1936 root 20 0 824m 135m 86m S 3.3 3.5 22:33.40
FocalPointV2
1662 root 20 0 434m 145m 84m S 1.0 3.7 6:37.61 Sysdb
1745 root 20 0 388m 46m 15m S 1.0 1.2 6:30.97
AgentMonitor
1661 root 20 0 391m 36m 3448 S 0.7 0.9 2:54.15 ProcMgr-
worker
1244 admin 20 0 416m 73m 26m S 0.3 1.9 0:06.00 Cli

<output omitted>
Step 4
Change to the flash directory. Type ”cd /mnt/flash”.
[admin@Student-05 ~]$ cd /mnt/flash

[admin@Student-05 flash]$
Step 5
From /mnt/flash, show the contents of the boot-config file using the “cat boot-config”.
[admin@Student-05 flash]$ cat boot-config

SWI=flash:/EOS-4.12.5.swi
Questions:
1.) What version of EOS will be used when the switch is booted?
2.) What versions of EOS are currently on flash?
3.) What other config files are stored on flash?
End of lab

4 Aboot
Lab Objectives:
In this lab you will:

• Change the boot-config settings.
• Enter Aboot and get familiar with the Aboot interface.
• Intentionally corrupt the boot-config file via Aboot.
• Perform a full system recovery.
WARNING: If you do a fullrecover on your switch, the switch will default to the base
configuration after ZTP requests a config. You will lose anything you have saved
since the beginning of the lab. You will also default to a very old version of EOS,
which you should then upgrade. This is why Aboot is covered so early in the lab.
NOTE: Reboot time for the switches is about three minutes. ZTP requires two
reboots, so count on about six minutes when triggering a ZTP reload.
TASK 1: Change the boot-config settings.
Step 1
View the boot-config settings using the “show boot-config” command.
Student-05#show boot-config
Software image: flash:/EOS-4.12.5.swi
Console speed: (not set)
Aboot password (encrypted): (not set)
Memory test iterations: (not set)
Step 2
Using the CLI, change the following settings in the boot-config.
secret: Arista
console speed: 9600
Student-05#conf
Student-05(config)#boot secret Arista
Student-05(config)#boot console speed 9600
Student-05(config)#exit
Student-05#
Step 3
View the boot-config settings using the “show boot-config” command.
Student-05#show boot-config
Software image: flash:/EOS-4.12.5.swi

Console speed: 9600

Aboot password (encrypted): $1$bGnX23m9$GFE17Ai2.4ARHNrHRJbKD1
Memory test iterations: (not set)
Questions:
1.) Is it necessary to save the configuration after these commands?
2.) If so, why? If not, why not?
TASK 2: Enter Aboot and get familiar with the interface.
Step 1
Connect to your switch on the console using the terminal server. For help, see section
“Connecting to the Lab.”
St05@ALAB-Linux:~$ console student-05
Step 2
Reboot the switch from the console using the “reload" command.
NOTE: If you are warned that the system configuration has been modified, type “yes” to
save.
Student-05#reload
Proceed with reload? [confirm]
Broadcast message from root@Student-05
(unknown) at 1:15 ...
The system is going down for reboot NOW!

Stopping sshd: [ OK ]
<output omitted>
Step 3
Watch the terminal as the switch boots. When prompted to enter Aboot, do this by
pressing “Control-C” to enter Aboot.
Aboot# reboot
Requesting syst[ 569.546793] Restarting system.
Arista Networks Inc...
Aboot 2.0.9-1287509

Press Control-C now to enter Aboot shell

^CAboot password:
Step 4
Enter the Aboot password you configured in the earler step.
Aboot password:
Welcome to Aboot.
Aboot#
Step 5
Type “help” for a list of commonly used Aboot commands.
Aboot# help
Commonly-used Aboot commands
ls Prints a list of the files in the current working directory

cd Changes the current working directory
cp Copies a file
more Prints the contents of a file one page at a time
vi Edits a text file
boot Boots a SWI
swiinfo Prints information about a SWI
recover Recovers the factory-default configuration
reboot Reboots the switch
netconf Configures a network interface manually (IPv4 or IPv6)
udhcpc Configures a network interface automatically via DHCP (IPv4
only)
wget Transfers a file from an HTTP or FTP server
scp Transfers a file to or from a server running SSH
Run 'command -h' for brief help on a specific command.

See http://busybox.net/ for additional help on many commands.
Aboot#
Step 6
Issue the following commands:
cd /mnt/flash
ls EOS*
NOTE: The contents of the flash on your switch may not match the example exactly.
Aboot# cd /mnt/flash
Aboot# ls EOS*
EOS-4.12.1.swi EOS-4.12.5.swi
Aboot#

Step 7
From the list of EOS .swi files, pick one and use the “swiiinfo” command.
Aboot# swiinfo EOS-4.12.1.swi

Archive: EOS-4.12.1.swi
Length Date Time Name
-------- ---- ---- ----
180 06-01-13 10:56 version
1858 06-01-13 08:52 boot0
1037850 06-01-13 08:52 initrd-i386
2308992 06-01-13 10:56 linux-i386
392081408 06-01-13 10:57 rootfs-i386.sqsh
-------- -------
395430288 5 files
BLESSED=1
BUILD_DATE=20130601T155202Z
BUILD_HOST=local1754-224.sjc.aristanetworks.com
SERIALNUM=688851f9-4aac-4f78-81ca-69a8114f172a
SWI_RELEASE=1275950.EOS4121
SWI_VERSION=4.12.1
Step 8
Get a feel for the Aboot busybox shell by looking at some files. Suggestions for
commands to try:
ls
more startup-config
cat boot-config
NOTE: The contents of the flash on your switch may not match the example exactly.
Aboot# ls
EOS-4.12.1.swi boot-config persist startup-config
EOS-4.12.5.swi debug schedule zerotouch-config
Aboot# more startup-config

! Startup-config last modified at Fri Mar 14 01:11:16 2014 by admin
! device: Student-05 (DCS-7150S-24-CL, EOS-4.12.5)
!
! boot system flash:/EOS-4.12.5.swi
! boot console speed 9600
! boot secret 5 $1$bGnX23m9$GFE17Ai2.4ARHNrHRJbKD1
!
alias conint sh interface | i connected
alias senz show interface counter error | nz
alias shmc show int | awk '/^[A-Z]/ { intf = $1 } /, address is/ {
print intf, $6 }'
alias snz show interface counter | nz
alias spd show port-channel %1 detail all
alias sqnz show interface counter queue | nz
alias srnz show interface counter rate | nz

!
<output omitted>
Aboot# cat boot-config

CONSOLESPEED=9600
PASSWORD=$1$bGnX23m9$GFE17Ai2.4ARHNrHRJbKD1
TASK 3: Update the boot-config file to an invalid Aboot password.
Step 1
Edit the boot-config file using VI.
Aboot# vi boot-config
Step 2
Change the Aboot password. On the line that begins with PASSWORD=, change the
password to something invalid. Save and exit by typing “esc”, “:”, “wq”.
CONSOLESPEED=9600
PASSWORD=#!
~
~
~
~
Aboot#
TASK 4: Attempt to re-enter Aboot.
Step 1
Reboot the switch.
Aboot# reboot
Requesting syst[ 569.546793] Restarting system.
Step 2
When the switch gets to the "Press control-C to enter Aboot" stage, press “control-c” and
enter the password.
Aboot 2.0.9-1287509

^CAboot password:

Step 3
After the password fails three times, you should get the following message:
“Type "fullrecover" and press Enter to revert /mnt/flash to factory default state, or just
press Enter to reboot:”
NOTE: The switch will still boot fine with a bad Aboot password - you just cannot enter
Aboot.
NOTE: If the terminal server injects noise into the line, this may cause the switch to
reboot. If that happens, just hit control-c at the prompt and start again.
^CAboot password:
incorrect password
Aboot password:
incorrect password
Aboot password:
incorrect password
Type "fullrecover" and press Enter to revert /mnt/flash to factory
default
state, or just press Enter to reboot:
TASK 4: Perform a full recovery on the switch.
Step 1
Type “fullrecover”. You should then get this prompt:
Step 2
Type “yes” when you get the prompt “All data on/mnt/flash will be erased…”

default
state, or just press Enter to reboot: fullrecover
All data on /mnt/flash will be erased; type "yes" and press Enter to
proceed,
or just press Enter to cancel: yes
Step 3
Watch the switch reload.


default
state, or just press Enter to reboot: fullrecover
All data on /mnt/flash will be erased; type "yes" and press Enter to
proceed,
or just press Enter to cancel: yes
Erasing /mnt/flash
Writing recovery data to /mnt/flash
EOS-4.11.6.swi
startup-config
boot-config
598554 blocks
[ 294.915490] Restarting system.
<output omitted>
TASK 5: Boot the switch using the default factory EOS version.
Step 1
Re-enter Aboot.
[ 70.125786] Restarting system.

Aboot 2.0.9-1287509

^CWelcome to Aboot.
Aboot#
Step 2
Boot the factory default image.
NOTE: your version may differ than the example. Boot whatever version is on flash after
the fullrecover (there will only be one).
HINT: If you type ‘boot” then type ‘E + tab’ it will tab complete the version on flash.
Aboot# boot /mnt/flash/EOS-4.11.6.swi
NOTE: When the switch boots up, it will be in ZTP mode, let the switch reload one more
time.

Questions:
3.) What EOS version did your switch have after the fullrecover? Ask your partner what
is the version they have after the fullrecover.
4.) Why didn’t you have to enter an Aboot password after the fullrecover?
5.) In this lab, ZTP loads a configuration from the webserver (We'll see this in detail
when we study ZTP). What would be the result if ZTP/DHCP/etc. was not configured?
End of lab

5 Upgrade EOS
Lab Objectives:

• Copy an EOS image to your switch.
• Perform a standard EOS software upgrade.
NOTE: The fullrecover from the previous Task caused your switch to load the factory
default version of code. The system needs to be upgraded to perform the remaining lab
activities.
TASK 1: Copy a new EOS version to the switch.
Step 1
Copy EOS-4.15.5M.swi from the lab management linux server (10.0.0.100) to your
switch.
Student-05#copy http://10.0.0.100/EOS/EOS-4.15.5M.swi flash:

Copy completed successfully.
Student-05#
Step 2
Verify image is in /mnt/flash.
Student-05#dir flash:
Directory of flash:/
-rwx 306459060 Mar 14 01:26 EOS-4.11.6.swi

-rwx 435157769 Nov 11 2013 EOS-4.15.5M.swi
-rwx 26 Mar 14 01:26 boot-config
drwx 4096 Mar 14 01:32 debug
drwx 4096 Mar 14 01:31 persist
drwx 4096 Mar 14 01:36 schedule
-rwx 1368 Mar 14 01:30 startup-config
-rwx 0 Mar 14 01:32 zerotouch-config
1691504640 bytes total (665079808 bytes free)
TASK 2: Complete the EOS Upgrade.
Step 1
Configure the boot config file to point to the new EOS image file.
Student-05(config)#boot system flash: EOS-4.15.5M.swi

Step 2
Verify boot-config settings.
Student-05(config)#show boot-config
Software image: flash:/ EOS-4.15.5M.swi
Console speed: (not set)
Aboot password (encrypted): (not set)
Student-05(config)#
Step 3
Reboot the switch.
NOTE: If you are warned that the system configuration has been modified, type “yes” to
save.
Student-05(config)#reload

Stopping sshd: [ OK ]
Flushing AAA accounting queue: [ OK ]
Restarting system ..
Step 4
Verify system is running on new image.
Student-05#sh ver
Arista DCS-7150S-24-CL-F
Hardware version: 02.00
Serial number: JPE13451306
System MAC address: 001c.7340.4a79
Software image version: 4.15.5M

Architecture: i386
Internal build version: 4.15.5M-1576566.4155M.2
Internal build ID: f2bbcdc2-58a1-4864-83fb-6341568e499b
Uptime: 2 minutes
Total memory: 4017088 kB
Free memory: 1654460 kB
Student-05#
Questions
1.) What other ways could you have verified the new EOS image file was successfully
copied to flash?

2.) How else could you have verified the boot-config settings?
End of lab

6 EOS Architecture
Lab Objectives:
• Interact with switch CLI while in BASH
• Demonstrate the functionality of the native Linux kernel using linux tools and
syntax
• Demonstrate stateful fault repair through killing processes and observing them
come back up
NOTE: Many of the things we're doing in this section should NOT be done on production
switches.
HINT: Many of the commands will require the sudo command.
TASK 1: Perform some more sophisticated tasks within the BASH shell.
Step 1
Enter bash on your switch.
Student-05#bash
Step 2
Using the CLI command, from bash, issue the CLI command “show interface status”.
HINT: “Cli –help” displays a menu of options.
[admin@Student-05 ~]$ Cli -c 'show interfaces status'

Port Name Status Vlan Duplex Speed
Type
Et1 [ ESXi ] connected 1 a-full a-1G
1000BASE-T
Et2 notconnect 1 full 10G Not
Present
Present
<output omitted>
Step 3
Using the “FastCLI” command, from bash, issue the CLI command show interface status.

[admin@Student-05 ~]$ FastCli -c 'show interfaces status'

Type
1000BASE-T
Present
<output omitted>
Step 4
Issue the same command and redirect the output to a file named “show_int_stat.txt”.
[admin@Student-05 ~]$ FastCli -c 'show interfaces status' >

sh_int_stat.txt
Questions
1.) What is the difference between using Cli and FastCli from the bash shell?
Step 5
Verify your file was created.
[admin@Student-05 ~]$ ls
sh_int_stat.txt
Task 2: View the system processes and demonstrate stateful fault repair.
Step 1
Issue the “pstree” command to get a visual representation of the agents running on the
switch. Note the processes running under the ProcMgr process.
admin@Student-05 ~]$ pstree

init-+-EosOomAdjust
|-ProcMgr-master---ProcMgr-worker-+-Aaa---3*[{Aaa}]
| |-EventMon
| |-FastClid-server-+-FastClid-
sessio---Cli---{Cli}
| | `-FastClid-
sessio---Cli-+-bash---pstree
| |
`-{Cli}
| |-Fru
| |-IgmpSnooping
| |-Lag+LacpAgent
Step 2
Using the “ps” command to fine the process IDs for the following processes:
Questions
2.) List the current PIDs for the following processes:
Arp: ________________
Stp: _________________
Lldp: ________________
Sysdb: _____________
[admin@Student-05 ~]$ ps -ef | grep -i arp

root 301 2 0 04:09 ? 00:00:00 [arp_cache-prd]
root 1761 1691 0 04:11 ? 00:00:00 netns --dlopen procmgr
/usr/bin/Arp
root 1776 1772 0 04:11 ? 00:00:14 Arp -d -i -
-dlopen -p -f -l libLoadDynamicLibs.so procmgr libProcMgrSetup.so --
daemonize
admin 2793 2507 0 17:34 pts/5 00:00:00 grep --color=auto -i
arp
[admin@Student-05 ~]$ ps -ef | grep -i stp

/usr/bin/StpTopology
/usr/bin/Stp
root 1782 1779 0 04:11 ? 00:00:13 StpTopology -d -i -
daemonize
root 1786 1781 0 04:11 ? 00:00:33 Stp -d -i -
daemonize
stp
[admin@Student-05 ~]$ ps -ef | grep -i lldp

/usr/bin/Lldp
root 2749 2748 2 17:33 ? 00:00:00 Lldp -d -i -
daemonize
lldp
[admin@Student-05 ~]$ ps -ef | grep -i sysdb

root 1692 1691 3 04:11 ? 00:26:03 Sysdb -d -i -


daemonize
sysdb
Step 3
From bash, kill the process named “Lldp”.
NOTE: Kill the PID that has this in the output “-d -i --dlopen -p -f -l”.

/usr/bin/Lldp
root 2749 2748 0 17:33 ? 00:00:01 Lldp -d -i -
daemonize
lldp
[admin@Student-05 ~]$ sudo kill 2748
Step 4
Find the process number for the “Lldp” process again.

/usr/bin/Lldp
root 3033 3032 65 17:39 ? 00:00:00 Lldp -d -i -
daemonize
lldp
Questions
3.) What is the PID of the LLDP after killing it?
Step 5
Try out some other CLI commands from from the lecture.
Student-05#watch diff show interfaces counters rates
Student-05#show int | awk ‘/^[A-Z]/ { intf = $1 } /, address is/ {

print intf, $6 }’

Student-05#sh int e1-2 count rate | awk '{print; totalin += $3;

totalout += $6}; END {print "total in: ", totalin, " total out: ",
totalout}'
End of lab

7 Zero Touch Provisioning (ZTP)

Lab Objectives:
In this activity you will explore the behavior of Zero Touch Provisioning (ZTP)
including:
• Canceling ZTP
Disabling ZTP
• Enabling ZTP
• Performing ZTP on your lab switch.
Task 1: Force your switch to boot into ZTP mode and cancel ZTP.
Step 1
Step 2
Delete the startup configuration.
Student-05#wr erase
Proceed with erasing startup configuration? [confirm]
Student-05#
Questions
1.) What other ways could you delete the startup-config?
Step 3
Reload the switch. Type “no” when prompted to save the configuration.
Student-05#reload
System configuration has been modified. Save? [yes/no/cancel/diff]:no
<output omitted>

Step 4
When your switch boots, login using the “admin” user (be quick!).
No startup-config was found.
The device is in Zero Touch Provisioning mode and is attempting to

download the startup-config from a remote system. The device will not
be fully functional until either a valid startup-config is downloaded
from a remote system or Zero Touch Provisioning is cancelled.
To cancel Zero Touch Provisioning, login as admin and type

'zerotouch cancel' at the CLI. Alternatively, to disable Zero Touch
Provisioning permanently, type 'zerotouch disable' at the CLI.
Note: The device will reload when these commands are issued.
localhost login: admin
Mar 15 00:31:17 localhost ZeroTouch: %ZTP-5-INIT: No startup-config

found, starting Zero Touch Provisioning
localhost>
<output omitted>
Step 5
Cancel ZTP using the “zerotouch cancel” command.
NOTE: Because ZTP will succeed (i.e. there is a DHCP server configured to reply) you
need to be quick with the zerotouch cancel command!
localhost>enable
localhost#zerotouch cancel
localhost#Mar 15 00:31:25 localhost ZeroTouch: %ZTP-5-INIT: No startup-
config found, starting Zero Touch Provisioning
Mar 15 00:31:31 localhost ZeroTouch: %ZTP-5-CANCEL: Cancelling Zero
Touch Provisioning
Mar 15 00:31:31 localhost ZeroTouch: %ZTP-5-RELOAD: Rebooting the
system
Broadcast message from root@localhost

<output omitted>
Step 6
When the switch boots up, login again using the default “admin” username.
localhost login: admin

localhost>

Questions
2.) What happened when zerotouch was cancelled?
3.) Do you have a startup-config file in flash?
4.) What would happen if you rebooted the switch right now without saving the running-
config?
TASK 3: Disable ZTP.
Step 1
Check the contents of the “zerotouch-config” file before disabling ZTP.
localhost#bash cat /mnt/flash/zerotouch-config
Step 2
Disable ZTP using the “zerotouch disable” command.
localhost#zerotouch disable
Step 3
Check the contents of the “zerotouch-config” file after disabling ZTP.
localhost#bash cat /mnt/flash/zerotouch-config

DISABLE=True
Questions
5.) What does disabling ZTP do? What would happen if you rebooted the switch now?
NOTE: Disabling ZTP normally causes a reboot also, but since the “zerotouch cancel”
command was already used, it did not reboot this time.

Task 4: Re-enable ZTP & perform a ZTP on your switch.
Step 1
Enable ZTP again.
localhost#bash
[admin@localhost ~]$ cd /mnt/flash

[admin@localhost flash]$ rm zerotouch-config
[admin@localhost flash]$ exit
logout
localhost#
Questions:
7.) How else could you re-enable ztp?
Step 2
Reload the switch. Type “no” when prompted to save the configuration.
localhost#reload
<output omitted>
Step 3
Observe your switch performing ZTP.

No startup-config was found.
The device is in Zero Touch Provisioning mode and is attempting to

download the startup-config from a remote system. The device will not
be fully functional until either a valid startup-config is downloaded
from a remote system or Zero Touch Provisioning is cancelled.
To cancel Zero Touch Provisioning, login as admin and type

'zerotouch cancel' at the CLI. Alternatively, to disable Zero Touch
Provisioning permanently, type 'zerotouch disable' at the CLI.
Note: The device will reload when these commands are issued.
localhost login: Mar 15 01:22:24 localhost ProcMgr-worker: %PROCMGR-6-

WORKER_WARMSTART: ProcMgr worker warm start. (PID=1568)
Mar 15 01:22:24 localhost ProcMgr-worker: %PROCMGR-6-PROCESS_STARTED:
'Pmbus' starting with PID=2088 (PPID=1568) -- execing
'/usr/bin/PmbusPowerSupply'
Mar 15 01:22:52 localhost ZeroTouch: %ZTP-5-DHCP_QUERY: Sending DHCP
request on [ Ethernet1, Ethernet21, Ethernet22, Management1 ]
Mar 15 01:22:55 localhost ZeroTouch: %ZTP-5-DHCP_SUCCESS: DHCP response
received on Management1 [ Ip Address: 10.0.0.40/24; Nameserver:
10.0.0.100; Domain: class.com; Boot File: http://10.0.0.100/ZTP/ZTP-
Script ]
Mar 15 01:23:00 localhost ZeroTouch: %ZTP-5-CONFIG_DOWNLOAD: Attempting
to download the startup-config from http://10.0.0.100/ZTP/ZTP-Script
Mar 15 01:23:02 localhost ZeroTouch: %ZTP-5-CONFIG_DOWNLOAD_SUCCESS:
Successfully downloaded config script from http://10.0.0.100/ZTP/ZTP-
Script
Mar 15 01:23:02 localhost ZeroTouch: %ZTP-5-EXEC_SCRIPT: Executing the
downloaded config script
Mar 15 01:23:08 localhost ZeroTouch: %ZTP-5-EXEC_SCRIPT_SUCCESS:
Successfully executed the downloaded config script
Mar 15 01:23:08 localhost ZeroTouch: %ZTP-5-RELOAD: Rebooting the
system
<output omitted>
NOTE: Your switch will reboot once more during the ZTP process. Please do not
interrupt this process.
Step 4
Verify your switch has a config.
Student-05 login: admin

Student-05>en
Student-05#sh run
! Command: show running-config
! device: Student-05 (DCS-7150S-24-CL, EOS-4.12.4)
!
<output omitted>

NOTE: If you do not have a running-config then something went wrong. If you are
having issues, delete the startup-config and zerotouch-config file on flash and reload
again. Also, check the ZTP log messages for errors.
WARNING: You will need the ZTP provided config to complete the remaining labs. If it
didn’t work, consult your lab partner or the instructor.
End of lab

8 Multi-Switch CLI
Lab Objectives:
• Configure and observe Multi-Switch CLI operation.
• Send XMPP to a single switch
• Join XMPP groups and send XMPP messages to all switches in a group
• Use Multi-Switch CLI to gather important information from the network.
TASK 1: Configure Multi-Switch CLI and verify connectivity with XMPP server.
Step 1
Configure your switch with the basic XMPP parameters as follows:
Server: 10.0.0.100
User: student-xx (where xx is your switch number [two digits])
NOTE: usernames in xmpp are all lowercase.
Password: Arista
Domain: class.com
Student-01#conf
Student-01(config)#management xmpp
Student-01(config-mgmt-xmpp)#no shut
Student-01(config-mgmt-xmpp)#server 10.0.0.100
Student-01(config-mgmt-xmpp)#domain class.com
Student-01(config-mgmt-xmpp)#user student-01 password Arista
Student-01(config-mgmt-xmpp)#exit
Student-01(config)#
NOTE: You need to exit XMPP config mode for the changes to take effect
Step 2
Verify connectivity to the XMPP server using the “show xmpp status command”.
Student-01(config)#sh xmpp status

XMPP Server: 10.0.0.100 port 5222
Client username: student-01@class.com
Default domain: class.com
Default privilege level for received commands: 1
Connection status: connected
Student-01(config)#
HINT: If you think everything is configured correctly and you cannot get a connection,
issue a shut command within management xmpp, exit, then issue a no shut command
within management xmpp and exit again. This usually resolves any issues, assuming
correct configuration. See below for exact commands.
management xmpp

shut
exit
management xmpp
no shut
exit
TASK 2: Send a message to a single switch.
Step 1
Using the “show xmpp neighbors” command, verify what other switches are connected to
the XMPP server.
Student-01(config)#sh xmpp neighbors

Neighbor State Time Since Last Change
------------------------------ --------------- ------------------------
-
spine-1@class.com present 0:08:32 ago
spine-2@class.com present 0:08:32 ago
student-02@class.com present 0:08:32 ago
Neighbor Status Message

------------------------------ ----------------------------------------
spine-1@class.com Arista Networks DCS-7150S-52-CL-SSD
spine-2@class.com Arista Networks DCS-7150S-52-CL-SSD
student-02@class.com Arista Networks DCS-7150S-24
student-07@class.com Arista Networks DCS-7150S-24-CL
Student-01(config)#
Step 2
Send a “show version” command to an XMPP neighbor using the “xmpp send student-xx
command show version” (where the xx is the student number of an xmpp neighbor).
Student-01(config)#xmpp send student-02@class.com command show ver

message from user: student-02@class.com
--------------------------------------------------
Arista DCS-7150S-24-F
Hardware version: 01.02
Serial number: JPE13160943
System MAC address: 001c.732a.e5c2
Software image version: 4.13.1F

Architecture: i386
Internal build version: 4.13.1F-1576566.4131F.2
Internal build ID: f2bbcdc2-58a1-4864-83fb-6341568e499b
Uptime: 9 minutes
Total memory: 4017088 kB

Free memory: 1753748 kB
TASK 3: Add your switch to the “odd” OR “even” group.
Step 1a
If your switch number is an odd number, add your switch to the group named “odd”.
Example for odd numbered “switch-01”
Student-01#conf
Student-01(config-mgmt-xmpp)#switch-group odd password Arista
Student-01(config)#
Step 1b
If your switch number is an even number, add your switch to the group named “even”.
Example for even numbered “switch-02”
Student-02#conf
Student-02(config-mgmt-xmpp)#switch-group even password Arista
Student-02(config)#
TASK 3: Send a message to a group.
Step 1
Send the “show version | grep Software” command to the odd OR even group, depending
what group you joined.
Example for odd numbered “switch-01”
Student-01#xmpp send odd@conference.class.com command show version |

grep Software
--------------------------------------------------

--------------------------------------------------

--------------------------------------------------

Student-01#

Student-02#xmpp send even@conference.class.com command show version |

grep Software
--------------------------------------------------

--------------------------------------------------

--------------------------------------------------
Student-02#
TASK 4: Add your switch to the “all” group. Both odd and even switches should
join this group.
Student-01#conf
Student-01(config-mgmt-xmpp)#switch-group all password Arista
Student-01(config)#
TASK 5: Use XMPP to discover some useful information within the network
Step 1
Construct an xmpp message to the all group to determine if there are errors on any
student switch uplinks.
Student-01#xmpp send all@conference.class.com command show int e21-22 |

grep errors
message from user: spine-1@class.com
--------------------------------------------------
0 input errors, 0 CRC, 0 alignment, 0 symbol, 0 input discards

0 output errors, 0 collisions

--------------------------------------------------




--------------------------------------------------


--------------------------------------------------

<output omitted>
Questions
1.) Were any errors found on the uplinks?
Step 2
Construct an xmpp message to the all group to determine what switch has the IP address
10.0.0.102.
Example
Student-01#xmpp send all@conference.class.com command show run | grep

10.0.0.102
--------------------------------------------------

--------------------------------------------------
ip address 10.0.0.102/24

--------------------------------------------------

--------------------------------------------------
<output omitted>

Questions
2.) Which switch has the IP address?
Step 3
Construct an xmpp message to the all group to determine which other student switches
recently connected to the xmpp server.
Example:
Student-01#xmpp send all@conference.class.com command show log | grep

%XMPP-6-CLIENT_CONNECTED
--------------------------------------------------

--------------------------------------------------

--------------------------------------------------
Aug 25 16:03:05 Student-01 Xmpp: %XMPP-6-CLIENT_CONNECTED: Connected to

10.0.0.100:5222 with JID student-
05@class.com/37114762981408978803183293
01@class.com/27028258631408978902920180
10.0.0.100:5222 with JID student-01@class.com/9048928811408979073432312

--------------------------------------------------

02@class.com/17523845891408978911333181

--------------------------------------------------
<output omitted>
Questions
3.) Are other switches connected? If so, what is the timestamp on the first switch that
responded?
TASK 6: Initiate an XMPP session with your lab partner’s switch and run a few
commands.
Step1
Use the command “xmpp session student-xx@class.com” where xx is your lab partner’s
student number to initiate an xmpp session to your lab partners switch.
Student-01#xmpp session student-02@class.com

xmpp-student-02#
Step 2
With your XMPP session open on your lab partner’s switch, run a few commands.
NOTE: Feel free to experiment - issue any commands that you'd like so long as they are
non-invasive. Do not mess with other student's switches without their permission.
WARNING: YES - the reload now command will work. NO - you should no do that here.
If you and your partner (mlag peer-link) would like t experiment with this, feel free, so
long as you both agree. Write your configs first!
Step 3
Type “exit” to return to your switch’s CLI.
xmpp-student-02#exit
Student-01#
End of lab

9 Multi-Chassis LAG (MLAG)

Lab Objectives:

• Configure Multi-chassis LAG (MLAG) and observe its operation in steady and
failed states
• Test MLAG failover by reloading the primary MLAG switch
• Understand the roles of primary and secondary in steady and failed states
TASK 1: Configure MLAG.
Diagram:
NOTE: All switches use the same MLAG and port-channel numbers:
1000 - MLAG peer-link
999 - MLAG uplink to Spine 1&2
Step 1
Configure the port channel/trunk for your peerlink.

Student-05(config)#interface ethernet23-24
Student-05(config-if-Et23-24)#channel-group 1000 mode active
Student-05(config-if-Et23-24)#interface port-channel 1000
Student-05(config-if-Po1000)#switchport mode trunk
Student-05(config-if-Po1000)#exit
Student-05(config)#
Step 2
Configure a VLAN and trunk group used for MLAG peer communications.
Student-05(config)#vlan 4094
Student-05(config-vlan-4094)#trunk group mlagpeer
Student-05(config-vlan-4094)#exit
Student-05(config)#
Step 3
Assign the port channel to the trunk group.
Student-05(config)#int po1000
Student-05(config-if-Po1000)#switchport trunk group mlagpeer
Student-05(config)#
Step 4
Disable spanning-tree on the VLAN used for the MLAG peer.
Student-05(config)#no spanning-tree vlan 4094
Step 5
Configure the SVI for peer-to-peer communication according to the chart below.
Switch IP Address
Student-01 10.100.100.1/30
Student-02 10.100.100.2/30
Student-03 10.100.100.5/30
Student-04 10.100.100.6/30
Student-05 10.100.100.9/30
Student-06 10.100.100.10/30
Student-07 10.100.100.13/30
Student-08 10.100.100.14/30
Student-09 10.100.100.17/30
Student-10 10.100.100.18/30
Student-11 10.100.100.21/30
Student-12 10.100.100.22/30
Student-13 10.100.100.25/30
Student-14 10.100.100.26/30
Student-15 10.100.100.29/30

Student-16 10.100.100.30/30
Student-17 10.100.100.33/30
Student-18 10.100.100.34/30
Student-19 10.100.100.37/30
Student-20 10.100.100.38/30
Example for odd numbered “switch-05” (see chart above for your switch’s IP):
Student-05(config)#int vlan 4094

Student-05(config-if-Vl4094)#ip address 10.100.100.9/30
Student-05(config-if-Vl4094)#no autostate
Student-05(config-if-Vl4094)#exit
Student-05(config)#
Example for even numbered “switch-06” (see chart above for your switch’s IP):
Student-06(config)#int vlan 4094

Student-06(config-if-Vl4094)#ip address 10.100.100.10/30
Student-06(config-if-Vl4094)#no autostate
Student-06(config-if-Vl4094)#exit
Student-06(config)#
Step 6
Configure local interface and peer address.
Example for odd numbered “switch-05” (see chart above for your switch’s IP):
Student-05(config)#mlag configuration
Student-05(config-mlag)#local-interface vlan 4094
Student-05(config-mlag)#peer-address 10.100.100.10
Example for even numbered “switch-06” (see chart above for your switch’s IP):
Student-06(config)#mlag configuration
Student-06(config-mlag)#local-interface vlan 4094
Student-06(config-mlag)#peer-address 10.100.100.9
Step 7
Configure the domain-id, peer-link & reload-delay on BOTH switches
Student-05(config-mlag)#domain-id mlagDomain
Student-05(config-mlag)#peer-link port-channel 1000
Student-05(config-mlag)#exit
Student-05(config)#
Student-06(config-mlag)#domain-id mlagDomain
Student-06(config-mlag)#peer-link port-channel 1000
Student-06(config-mlag)#exit
Student-06(config)#

Step 8
Configure the MLAG interface (upstream interface to spine) on BOTH switches
Student-05(config)#int eth21-22
Student-05(config-if-Et21-22)#int po999
Student-05(config-if-Po999)#mlag 999
Student-05(config)#
Student-06(config-if-Et21-22)#int po999
Student-06(config-if-Po999)#mlag 999
Student-06(config)#
TASK 2: Verify MLAG.
Step 1
Execute the following commands to confirm MLAG is operational and the MLAG
interface (upstream interface to spine) is up.
show mlag
show mlag detail
show mlag interfaces
show int po999
Student-05#sh mlag
MLAG Configuration:
domain-id : mlagDomain
local-interface : Vlan4094
peer-address : 10.100.100.10
peer-link : Port-Channel1000
MLAG Status:
state : Active
negotiation status : Connected
peer-link status : Up
local-int status : Up
system-id : 02:1c:73:68:d7:75
MLAG Ports:
Disabled : 0
Configured : 0
Inactive : 0
Active-partial : 0
Active-full : 1
Student-05#

Student-05#sh mlag interfaces
local/remote
mlag desc state local remote
status
---------- ---------- ----------------- ----------- ------------ ------
------
999 active-full Po999 Po999
up/up
Student-05#
Student-05#sh mlag detail

MLAG Configuration:
peer-address : 10.100.100.10
MLAG Status:
state : Active
system-id : 02:1c:73:68:d7:75
MLAG Ports:
Disabled : 0
Configured : 0
Inactive : 0
Active-partial : 0
Active-full : 1
MLAG Detailed Status:

State : secondary
State changes : 2
Last state change time : 0:17:34 ago
Failover : False
Last failover change time : never
Secondary from failover : False
primary-priority : 32767
Peer primary-priority : 32767
Peer MAC address : 00:1c:73:68:d7:75
Reload delay : 300 seconds
Non-MLAG reload delay : 300 seconds
Ports errdisabled : False
Lacp standby : False
Heartbeat interval : 2000 ms
Heartbeat timeout : 30000 ms
Last heartbeat timeout : never
Heartbeat timeouts since reboot : 0
Peer monotonic clock offset : -1531.359462 seconds
Agent should be running : True
P2p mount state changes : 1
Student-05#

Student-05#sh int po999

Port-Channel999 is up, line protocol is up (connected)
Hardware is Port-Channel, address is 001c.7368.d80c
Ethernet MTU 9214 bytes , BW 40000000 kbit
Full-duplex, 40Gb/s
Active members in this channel: 4
... Ethernet21 , Full-duplex, 10Gb/s
... PeerEthernet21 , Full-duplex, 10Gb/s
Fallback mode is: off
Up 4 minutes, 20 seconds
3 link status changes since last clear
Last clearing of "show interface" counters never
5 minutes input rate 135 bps (0.0% with framing overhead), 0
packets/sec
5 minutes output rate 127 bps (0.0% with framing overhead), 0
packets/sec
61 packets input, 9166 bytes
Received 0 broadcasts, 61 multicast
0 input errors, 0 input discards
51 packets output, 8261 bytes
Sent 0 broadcasts, 51 multicast
0 output errors, 0 output discards
Student-05#
NOTE: If MLAG did not come up, work with your lab partner to ensure configs are
correct.
Questions
1.) How many MLAG interfaces are in Active-full?
2.) How many active members are in port-channel999?
3.) Which switch in your pair is the MLAG primary?
4.) What is the default value for the MLAG Reload delay? (Hint see output from show
mlag detail)
5.) What does the MLAG Reload delay setting do?

TASK 3: Test MLAG Failover.
Step 1
Step 2
Verify which switch is the MLAG primary switch.
Student-06#show mlag detail | grep State

State : primary
State changes : 2
Student-06#
Step 3
Reload the MLAG primary switch.
HINT: If you want to see all syslogs generated during the reboot and subsequent MLAG
re-convergence, execute the command “bash sudo tail -f /var/log/messages” on the
secondary switch.
Student-06#reload
If you are performing an upgrade, and the Release Notes for the new
version of EOS indicate that MLAG is not backwards-compatible with the
currently installed version (4.12.4), the upgrade will result in
packet loss.

<output omitted>
Step 4: As the primary switch reboots, check the status of MLAG and MLAG interfaces
on the secondary switch using the following commands:
show mlag
show mlag detail
show int po999

Questions
6.) While the primary is rebooting, what is the status of the MLAG interface(s) on the
secondary switch?
Step 5
After the switch reboots, check the status of MLAG on your switch. Use the following
commands:
show mlag
show mlag detail
show int po999
Student-06#sh mlag
MLAG Configuration:
peer-address : 10.100.100.9
MLAG Status:
state : Active
system-id : 02:1c:73:68:d7:75
MLAG Ports:
Disabled : 0
Configured : 0
Inactive : 0
Active-partial : 0
Active-full : 1
Student-06#
Student-06#sh mlag detail

MLAG Configuration:
peer-address : 10.100.100.9
MLAG Status:
state : Active
system-id : 02:1c:73:68:d7:75

MLAG Ports:
Disabled : 0
Configured : 0
Inactive : 0
Active-partial : 0
Active-full : 1
MLAG Detailed Status:

State : secondary
State changes : 2
Last state change time : 0:08:42 ago
Failover : False
Last failover change time : never
Secondary from failover : True
primary-priority : 32767
Peer primary-priority : 32767
Peer MAC address : 00:1c:73:68:d7:f7
Reload delay : 300 seconds
Non-MLAG reload delay : 300 seconds
Ports errdisabled : False
Lacp standby : False
Heartbeat interval : 2000 ms
Heartbeat timeout : 30000 ms
Last heartbeat timeout : never
Heartbeat timeouts since reboot : 0
Peer monotonic clock offset : 48222.459805 seconds
Agent should be running : True
P2p mount state changes : 1
Student-06#
local/remote
status
--------- ---------- -------------------- ----------- ------------ ----
--------
999 active-partial Po999 Po999
down/up
local/remote
status
---------- ---------- ----------------- ----------- ------------ ------
------
999 active-full Po999 Po999
up/up
Student-06#
Student-06#sh int po999

Port-Channel999 is up, line protocol is up (connected)
Hardware is Port-Channel, address is 001c.7368.d78a
Ethernet MTU 9214 bytes , BW 40000000 kbit

Full-duplex, 40Gb/s
Active members in this channel: 4
Fallback mode is: off
Up 17 minutes, 18 seconds
2 link status changes since last clear
Last clearing of "show interface" counters never
5 minutes input rate 658 bps (0.0% with framing overhead), 1
packets/sec
5 minutes output rate 175 bps (0.0% with framing overhead), 0
packets/sec
1284 packets input, 167652 bytes
Received 0 broadcasts, 1284 multicast
0 input errors, 0 input discards
279 packets output, 45764 bytes
Sent 0 broadcasts, 279 multicast
0 output errors, 0 output discards
Student-06#
Questions
7.) What happened to the MLAG primary/secondary status?
8.) What is the status of the MLAG interfaces on both switches? HINT: use the "show
mlag detail’ and ‘show mlag interfaces’ commands
9.) How long did it take the MLAG interfaces to come up? HINT: to view the status of
the reload-delay, use the ‘show mlag’ command and look at the ‘state’ under ‘MLAG
Status’
End of lab

10 BGP Equal Cost Mult-Pathing (ECMP)

Lab Objectives:
• Establish a BGP session between your switch and the spine switches
• Advertise and accept routes to/from the spine switches
• Configure and confirm BGP multi-path

Diagram:

TASK 1: Complete Prep Work

Step 1
Backup your config so you can reload them later.

sh run > flash:mlag-config.bak

Step 2
De-configure MLAG and erase relevant interface configs.

conf
no mlag configuration
default interface e21-24
int e23-24
shut

TASK 2: Establish IP connectivity to spine switches


Step1
Configure a point-to-point link between your switch and each spine switch
according to the chart below.

Switch Eth21 IP (to spine-1) Eth22 IP (to spine-2)
student-01 10.10.1.2/30 10.10.1.6/30
student-02 10.10.2.2/30 10.10.2.6/30
student-03 10.10.3.2/30 10.10.3.6/30
student-04 10.10.4.2/30 10.10.4.6/30
student-05 10.10.5.2/30 10.10.5.6/30
student-06 10.10.6.2/30 10.10.6.6/30
student-07 10.10.7.2/30 10.10.7.6/30
student-08 10.10.8.2/30 10.10.8.6/30
student-09 10.10.9.2/30 10.10.9.6/30
student-10 10.10.10.2/30 10.10.10.6/30
student-11 10.10.11.2/30 10.10.11.6/30
student-12 10.10.12.2/30 10.10.12.6/30
student-13 10.10.13.2/30 10.10.13.6/30
student-14 10.10.14.2/30 10.10.14.6/30
student-15 10.10.15.2/30 10.10.15.6/30
student-16 10.10.16.2/30 10.10.16.6/30
student-17 10.10.17.2/30 10.10.17.6/30
student-18 10.10.18.2/30 10.10.18.6/30
student-19 10.10.19.2/30 10.10.19.6/30
student-20 10.10.20.2/30 10.10.20.6/30

NOTE: You have to configure “no switchport” before the IP configuration becomes
active on the interfaces.

EXAMPLE (student-01)
Student-01(config)#int e21
Student-01(config-if-Et21)#no switchport
Student-01(config-if-Et21)#ip address 10.10.1.2/30
Student-01(config-if-Et21)#int e22

Step 2
Confirm you can ping the remote IP in both subnets. If you can’t, check “show lldp
neighbors” to make sure you have the correct interface, double check IP config,
etc.

Student-01#ping 10.10.1.1
PING 10.10.1.1 (10.10.1.1) 72(100) bytes of data.
80 bytes from 10.10.1.1: icmp_req=1 ttl=64 time=0.173 ms


--- 10.10.1.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 1ms
rtt min/avg/max/mdev = 0.074/0.114/0.173/0.034 ms, ipg/ewma 0.281/0.141
ms

ms
Student-01#

TASK 3: Establish BGP neighbor adjacencies with spine switches

Step 1
Enable ip routing globally

Student-01(config)#ip routing

Step 2
Configure a BGP session with both spine-1 and spine-2 using the chart below.

Switch Local ASN Neighbor IP Remote ASN
student-01 65001 10.10.1.1, 10.10.1.5 65100
student-02 65002 10.10.2.1, 10.10.2.5 65100
student-03 65003 10.10.3.1, 10.10.3.5 65100
student-04 65004 10.10.4.1, 10.10.4.5 65100
student-05 65005 10.10.5.1, 10.10.5.5 65100
student-06 65006 10.10.6.1, 10.10.6.5 65100
student-07 65007 10.10.7.1, 10.10.7.5 65100
student-08 65008 10.10.8.1, 10.10.8.5 65100
student-09 65009 10.10.9.1, 10.10.9.5 65100
student-10 65010 10.10.10.1, 10.10.10.5 65100
student-11 65011 10.10.11.1, 10.10.11.5 65100
student-12 65012 10.10.12.1, 10.10.12.5 65100
student-13 65013 10.10.13.1, 10.10.13.5 65100
student-14 65014 10.10.14.1, 10.10.14.5 65100

student-15 65015 10.10.15.1, 10.10.15.5 65100

student-16 65016 10.10.16.1, 10.10.16.5 65100
student-17 65017 10.10.17.1, 10.10.17.5 65100
student-18 65018 10.10.18.1, 10.10.18.5 65100
student-19 65019 10.10.19.1, 10.10.19.5 65100
student-20 65020 10.10.20.1, 10.10.20.5 65100

Student-01(config)#router bgp 65001
Student-01(config-router-bgp)#neighbor 10.10.1.1 remote-as 65100
Student-01(config-router-bgp)#neighbor 10.10.1.5 remote-as 65100

Step 3
Confirm you have neighbor adjacency with both spine switches using the “show ip
bgp summary” command. If it’s not working, double check IP config, ASN, etc.

Student-01#sh ip bgp summary
BGP summary information for VRF default
Router identifier 10.10.1.6, local AS number 65001
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State
PfxRcd
10.10.1.1 4 65100 46 46 0 0 00:37:40 Estab
6
10.10.1.5 4 65100 45 47 0 0 00:37:36 Estab
5
Student-01#

Questions

1.) What routes are you receiving from BOTH the spine switches? HINT: use the
“show ip bgp neighbors 10.10.X.X received-routes” command.

Student-01#sh ip bgp neighbors 10.10.1.1 received-routes
BGP routing table information for VRF default
Route status codes: s - suppressed, * - valid, > - active, E - ECMP
head, e - ECMP
S - Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL
Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path

* 0.0.0.0/0 10.10.1.1 0 100 - 65100
?
* 10.1.2.0/24 10.10.1.1 0 100 - 65100

65002 i
* 10.1.5.0/24 10.10.1.1 0 100 - 65100
65005 i
* 10.1.6.0/24 10.10.1.1 0 100 - 65100
65006 i
* 10.1.12.0/24 10.10.1.1 0 100 - 65100
65012 i
* > 192.168.100.1/32 10.10.1.1 0 100 - 65100
i

Student-01#sh ip bgp neighbors 10.10.1.5 received-routes
BGP routing table information for VRF default
Route status codes: s - suppressed, * - valid, > - active, E - ECMP
head, e - ECMP
S - Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL
Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path

* > 0.0.0.0/0 10.10.1.5 0 100 - 65100
?
* > 10.1.2.0/24 10.10.1.5 0 100 - 65100
65002 i
* > 10.1.5.0/24 10.10.1.5 0 100 - 65100
65005 i
* > 10.1.6.0/24 10.10.1.5 0 100 - 65100
65006 i
* > 10.1.12.0/24 10.10.1.5 0 100 - 65100
65012 i
* > 192.168.100.2/32 10.10.1.5 0 100 - 65100
i

2.) Of the default routes (0.0.0.0/0) received from the spine switches, the
active/best route is from which neighbor? Use the “show ip route 0.0.0.0”
command.

Student-01#sh ip route 0.0.0.0
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route
Gateway of last resort:

B E 0.0.0.0/0 [200/0] via 10.10.1.1, Ethernet21
Student-01#



3.) Using the chart “BGP Route Selection Decision Process” in Appendix A, determine
why the active route was chosen.

4.) What option do you need to enable to get your router to activate both default
routes from spine1 and spine2? HINT: Check the table in Appendix A.

TASK 4: Configure BGP Multipath

Student-01(config-router-bgp)#maximum-paths 32 ecmp 32
Student-01(config-router-bgp)#exit
Student-01(config)#

Question

5.) After enabling BGP Multipath, check the routing table again using “show ip
route” Of the default routes received from the spine switches, which are active
now?

Student-01(config)#sh ip route 0.0.0.0
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route
Gateway of last resort:

B E 0.0.0.0/0 [200/0] via 10.10.1.1, Ethernet21
via 10.10.1.5, Ethernet22

TASK 5: Advertise your Loopback to the spine switches

Step 1
Configure an IP address on interface loopback1 according to the chart below.

Switch Loopback1 IP
student-01 10.1.1.1/24
student-02 10.1.2.1/24

student-03 10.1.3.1/24
student-04 10.1.4.1/24
student-05 10.1.5.1/24
student-06 10.1.6.1/24
student-07 10.1.7.1/24
student-08 10.1.8.1/24
student-09 10.1.9.1/24
student-10 10.1.10.1/24
student-11 10.1.11.1/24
student-12 10.1.12.1/24
student-13 10.1.13.1/24
student-14 10.1.14.1/24
student-15 10.1.15.1/24
student-16 10.1.16.1/24
student-17 10.1.17.1/24
student-18 10.1.18.1/24
student-19 10.1.19.1/24
student-20 10.1.20.1/24

Student-01(config)#int lo1
Student-01(config-if-Lo1)#ip address 10.1.1.1/24

Questions

6.) Ping the loopback of spine-1 (192.168.100.1). What is the source IP of this ping?
HINT: Establish another ssh session to your swich, go to the bash shell and type
“tcpdump –i et21” and then re-issue the ping from the original session.

7.) Ping the loopback of spine-1 sourced from your interface loopback 1 IP “ping
192.168.100.1 source 10.1.X.1” Why does it fail?

Step 2
Configure a network statement in BGP to adversise your loopback network. Use the
chart below.

Switch Loopback Network
student-01 10.1.1.0/24
student-02 10.1.2.0/24
student-03 10.1.3.0/24

student-04 10.1.4.0/24
student-05 10.1.5.0/24
student-06 10.1.6.0/24
student-07 10.1.7.0/24
student-08 10.1.8.0/24
student-09 10.1.9.0/24
student-10 10.1.10.0/24
student-11 10.1.11.0/24
student-12 10.1.12.0/24
student-13 10.1.13.0/24
student-14 10.1.14.0/24
student-15 10.1.15.0/24
student-16 10.1.16.0/24
student-17 10.1.17.0/24
student-18 10.1.18.0/24
student-19 10.1.19.0/24
student-20 10.1.20.0/24

Student-01(config-router-bgp)#network 10.1.1.0/24

Step 3
Re-issue the ping “ping 192.168.100.1 source 10.1.1.1”. If it fails,
troubleshoot. Ensure you are advertising your loopback address to the spine
switches using this command: “sh ip bgp neighbors 10.10.1.1
advertised-routes”

End of Lab

11 Virtual Extensible LAN (VXLAN) Bridging

Lab Objectives:
• Configure a VXLAN segment to bridge traffic between the DANZ switches
across the L3 BGP ECMP network
• Establish connectivity to DANZ switches and run test pings
• Inspect VXLAN Cli outputs

NOTE: You will need to work with the person who has the other switch in your switch
pair.

NOTE: In this lab, “end host” devices are emulated by the DANZ-1 and DANZ-2
switches. Every student switch should be connected to both of these switches.

Diagram:

TASK 1: Configure your switches to connect to the DANZ switches


Step 1
Configure an access port in a vlan according to the chart below.

Switch Interface VLAN
student-01 ethernet19 101

Student-01(config-if-Et19)#switchport access vlan 101
! Access VLAN does not exist. Creating vlan 101
Student-01(config-if-Et19)#

Student-02(config-if-Et20)#switchport access vlan 102
! Access VLAN does not exist. Creating vlan 102

Step 2
Shutdown the other port connected to the DANZ switch (the one you did not
configure as an access port in the vlan).

NOTE: On odd numbered switches, shutdown eth20, on even numbered switches,
shutdown eth19


Student-01(config-if-Et20)#shutdown
Student-01(config-if-Et20)#exit
Student-01(config)#

Student-02(config-if-Et19)#shutdown
Student-02(config)#

TASK 2: Confirm connectivity between your switches and the DANZ switches

Step 1
Confirm eth19 is up on the odd numbered switch and and eth20 is up on the even
numbered switch.

Student-01(config)#sh int e19 | grep proto
Ethernet19 is up, line protocol is up (connected)

Student-02(config)#sh int e20 | grep proto
Ethernet20 is up, line protocol is up (connected)

Step 2
Confirm correct connectivity via “show lldp neighbors”

NOTE: At this point, your odd numbered switch is single-connected to DANZ-1 and
your even numbered switch is single-connected to DANZ-2. This is to avoid
loops/spanning tree blocking.

Your LLDP neighbors should look like the following:

EXAMPLE: (student-01)
Student-01(config)#sh lldp neighbors | grep -A 5 Port
Port Neighbor Device ID Neighbor Port ID TTL
Et19 DANZ-1 Ethernet1 120
Et21 Spine-1 Ethernet1 120
Ma1 ALab-Core Ethernet1 120

Student-02(config)#sh lldp neighbors | grep -A 5 Port
Port Neighbor Device ID Neighbor Port ID TTL
Et20 DANZ-2 Ethernet2 120
Ma1 ALab-Core Ethernet2 120


Step 3
Confirm correct VLAN configuration


Student-01(config)#sh vlan
VLAN Name Status Ports
----- -------------------------------- --------- ----------------------
---------
1 default active Et1
101 VLAN0101 active Et19
Student-01(config)#


Student-02(config)#sh vlan
----- -------------------------------- --------- ----------------------
---------
1 default active Et1
102 VLAN0102 active Et20
Student-02(config)#

TASK 3: Log into DANZ-1 and run a pre-test PING to DANZ-2

Step 1
To log into DANZ-1. Type “danz-1” from the Linux Lab Management Server.

NOTE: You can get back to the Linux Lab Management Server by either exiting your
switch session or establishing a new ssh connection to the Linux Lab Management
Server.

Student-01#exit
Instructor@ALab-Linux:~$ danz-1
Warning: Permanently added 'danz-1,10.0.0.103' (RSA) to the list of
known hosts.
+---------------------------------------+
| Switch: DANZ-1 |
| |
| Purpose: Advanced Class Lab |
| Owner: Gary A. Donahue |
| Email: gad@aristanetworks.com |
+---------------------------------------+
Last login: Tue Aug 26 08:45:34 2014 from 10.0.0.100
DANZ-1>


Step 2
From DANZ-1, ping 172.16.X.2. (X = the ODD student number)

EXAMPLE
DANZ-1>ping 172.16.1.2
From 172.16.1.1 icmp_seq=1 Destination Host Unreachable

5 packets transmitted, 0 received, +5 errors, 100% packet loss, time
4002ms
pipe 3
DANZ-1>

Question

1.) Why does this ping fail?

TASK 4: Configure a VXLAN segment that will bridge the vlans configured on
your switches

Step 1
Configure a VXLAN interface and bridging on your switch according to the chart
below:

Switch Source Int VLAN Remote VTEP IP VNI
student-01 Loopback1 101 10.1.2.1 10000



Student-01(config)#interface Vxlan1
Student-01(config-if-Vx1)#vxlan source-interface Loopback1
Student-01(config-if-Vx1)#vxlan vlan 101 flood vtep 10.1.2.1
Student-01(config-if-Vx1)#vxlan udp-port 4789
Student-01(config-if-Vx1)#vxlan vlan 101 vni 10000
Student-01(config-if-Vx1)#exit
Student-01(config)#

Student-02(config)#interface vxlan1
Student-02(config-if-Vx1)#vxlan source-interface Loopback1
Student-02(config-if-Vx1)#vxlan vlan 102 flood vtep 10.1.1.1
Student-02(config-if-Vx1)#vxlan udp-port 4789
Student-02(config-if-Vx1)#vxlan vlan 102 vni 10000
Student-02(config-if-Vx1)#exit
Student-02(config)#

TASK 5: Log into DANZ-1 and run a re-try PING from DANZ-1

Step 1
To log into DANZ-1. Type “danz-1” from the Linux Lab Management Server.

NOTE: You can get back to the Linux Lab Management Server by either exiting your
switch session or establishing a new ssh connection to the Linux Lab Management
Server.

Student-01#exit
Instructor@ALab-Linux:~$ danz-1
known hosts.
+---------------------------------------+
| Switch: DANZ-1 |
| |
+---------------------------------------+
Last login: Tue Aug 26 08:45:34 2014 from 10.0.0.100
DANZ-1>


Step 2
From DANZ-1, ping 172.16.X.2. (X = the ODD student number)

EXAMPLE
DANZ-1#ping 172.16.1.2

ms
DANZ-1#

Question

2.) Was the ping successful? If so, you have successfully configured VXLAN Bridging.
If not, check your config, ask a neighbor or the instructor for help.

TASK 6: Inspect various “show vxlan” commands

Student-01#sh vxlan vtep
Remote vteps for Vxlan1:
10.1.2.1
Total number of remote vteps: 1
Student-02#sh vxlan vtep
Remote vteps for Vxlan1:
10.1.1.1
Total number of remote vteps: 1

Student-01#sh vxlan address-table
Vxlan Mac Address Table
----------------------------------------------------------------------
Vlan Mac Address Type Prt Vtep Moves Last Move

---- ----------- ---- --- ---- ----- ---------
101 001c.731f.44da DYNAMIC Vx1 10.1.2.1 1 0:02:47
ago

Total Remote Mac Addresses for this criterion: 1

Student-02#sh vxlan address-table
Vxlan Mac Address Table
----------------------------------------------------------------------
Vlan Mac Address Type Prt Vtep Moves Last Move

---- ----------- ---- --- ---- ----- ---------
102 001c.731f.389e DYNAMIC Vx1 10.1.1.1 1 0:05:10
ago
Total Remote Mac Addresses for this criterion: 1

3.) What devices/interfaces are assigned the MAC addresses in the outputs above?

TASK 9: Restore your MLAG config

Student-01#bash

[admin@Student-01 flash]$ cp mlag-config.bak startup-config
[admin@Student-01 flash]$ exit
logout
Student-01#reload
End of Lab


12 Advanced Event Manager (AEM)

Lab Objectives:
• Create a custom CLI Scheduler and observer it’s operation.
• Create a custom Event Handler that executes a BASH script saved on flash and
observe it’s operation.
• Inspect the data provided through Event Monitor.
Cli Scheduler
TASK 1: Observe the default CLI schedule “tech-support”.
Step 1
Execute the “show schedule summary” command.
Student-05#sh schedule summary

Name At time Last Inter\ Max Logfile Location
Status
time val log
(mins) files
------------ ------- ----- ------- ------ -----------------------------
- ------
tech-support now 14:54 60 100 flash:/schedule/tech-support/
Success
Student-05#
Questions
1.) How often does this scheduler execute and store the ‘show-tech’ command?
2.) What is the max number of log files that will be kept on flash?
3.) In what directory are these files stored? (write as much of the path as you can)
TASK 2: Create and observe a scheduled job with the following parameters:
Name: ShowIntStatus
Executes the command “show interface status” every 60 seconds
Saves a max of 30 files

Step 1
Configure the custom CLI scheduler.
Student-05#conf
Student-05(config)#schedule ShowIntStatus interval 1 max-log-files 30
command show interfaces status
Student-05#
Step 2
Verify the scheduler settings with the “show scheduler summary” command.
Student-05#sh schedule summary

Name At time Last Inter\ Max Logfile Location
Status
time val log
(mins) files
------------- ------- ----- ------ ------ -----------------------------
- ------
showintstatus now - 1 30 -
Waiting
tech-support now 15:54 60 100 flash:/schedule/tech-support/
Success
Student-05#
Step 3
Wait 60 seconds and then view the file(s) the scheduler has created.
Step 3a
Enter bash.
Student-05#bash
Step 3b
Navigate to /mnt/flash/schedule.
[admin@Student-05 ~]$ cd /mnt/flash/schedule
Step 3c
Your scheduler created a new directory. Navigate to it and check for files.
[admin@Student-05 schedule]$ cd showintstatus/

[admin@Student-05 showintstatus]$ ls
showintstatus_2014-03-15.1558.log.gz showintstatus_2014-03-
15.1559.log.gz
[admin@Student-05 showintstatus]$

Step 4
Using “zcat,” open the most recent log file.
[admin@Student-05 showintstatus]$ zcat showintstatus_2014-03-

15.1600.log.gz
Type
1000BASE-T
Present
Present
<output omitted>
Event Handler
TASK1: Create an event-handler with the following parameters:
Name: Eth1UpDown
When Eth1 is down, it configures the description to “The link is down”
When Eth1 is up,it configures the description to “The link is up”
Sends a custom syslog message each time the script is run
Step 1
Create the script. Enter bash from the CLI, navigate to /mnt/flash. Type “vi
Eth1UpDown.sh”, type “i” to insert and then type in the script. When finished, type “esc,
: , wq”.
NOTE: Be sure the entire script is correct and the name of your script matches your
config!

Student-05#bash

[admin@Student-05 flash]$ vi Eth1UpDown.sh
#!/bin/bash
if [ "$OPERSTATE" = "linkup" ]; then
FastCli -p 15 -c'
conf t
int e1
description The link is up
send log level notifications message Eth1 is up!
'
elif [ "$OPERSTATE" = "linkdown" ]; then
FastCli -p 15 -c'
conf t
int e1
description The link is down
send log level notifications message Eth1 is down!
'
fi
Step 2
Configure the event handler.
Student-05(config)#conf
Student-05(config)#event-handler Eth1UpDown
Student-05(config-handler-Eth1UpDown)#trigger on-intf Ethernet 1
operstatus
Student-05(config-handler-Eth1UpDown)#action bash
/mnt/flash/Eth1UpDown.sh
Student-05(config-handler-Eth1UpDown)#delay 0
Student-05(config-handler-Eth1UpDown)#exit
Student-05(config)#
TASK 2: Verify the event-handler config and operation.
Step 1
Use the “show event-handler” command to verify configuration.
Student-05#sh event-handler
Event-handler Eth1UpDown
Trigger: on-intf Ethernet1 on operstatus delay 0 seconds
Action: /mnt/flash/Eth1UpDown.sh
Action expected to finish in less than 10 seconds
Last Trigger Activation Time: 5 seconds ago
Total Trigger Activations: 1
Last Action Time: 5 seconds ago
Total Actions: 1
Step 2
Check the description with the “show run interface eth1” command.
Student-05#sh run int e1

interface Ethernet1
Step 3
Shut down eth1.
Student-05#conf
Student-05(config-if-Et1)#shut
Student-05(config)#
Step 4
Observe the description change.
NOTE: Script should be executed and the change should occur within a few seconds.
Student-05(config-if-Et1)#sh run int e1

interface Ethernet1
description The link is down
shutdown
Step 5
Bring eth1 back up.
Student-05#conf
Student-05(config-if-Et1)#no shut
Student-05(config)#
Step 6
Observe the description change.
NOTE: Script should be executed and change should occur within a few seconds.
Student-05(config)#sh run int e1

interface Ethernet1
Student-05(config)#
Step 7
Using the “show log last 5 min” command, verify your custom syslogs were generated.
Student-05#sh log last 5 min

Mar 15 16:17:55 Student-05 Cli: %SYS-5-LOGMSG_NOTICE: Message from
UnknownUser on UnknownTty (UnknownIpAddr): Eth1 is up!
Mar 15 16:18:21 Student-05 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Ethernet1 (The link is up), changed state to down

Mar 15 16:18:21 Student-05 EventMgr: %SYS-6-EVENT_TRIGGERED: Event

handler Eth1UpDown was activated
Mar 15 16:18:24 Student-05 Cli: %SYS-5-CONFIG_E: Enter configuration
mode from console by UnknownUser on UnknownTty (UnknownIpAddr)
UnknownUser on UnknownTty (UnknownIpAddr): Eth1 is down!
Mar 15 16:18:38 Student-05 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Ethernet1 (The link is down), changed state to up
Mar 15 16:18:38 Student-05 EventMgr: %SYS-6-EVENT_TRIGGERED: Event
handler Eth1UpDown was activated
Mar 15 16:18:39 Student-05 Cli: %SYS-5-CONFIG_E: Enter configuration
mode from console by UnknownUser on UnknownTty (UnknownIpAddr)
UnknownUser on UnknownTty (UnknownIpAddr): Eth1 is up!
Event Monitor
TASK 1: Observe event monitor data for ARP, MAC and ROUTE changes on your
switch.
Step 1
Using the “show event-monitor arp” command, view any arp table changes that have
occurred on your switch.
Student-05#show event-monitor arp

2014-03-15 15:19:28|10.100.100.10|Vlan4094|00:1c:73:68:d7:75|0|added|0
2014-03-15 15:19:32|10.0.0.100|Management1|00:30:48:64:2a:b6|0|added|1
2014-03-15 15:49:24|10.0.0.95|Management1|00:1c:73:28:2f:6c|0|added|2
Student-05#
Step 2
Using the “show event-monitor mac” command, view any mac address table changes that
have occurred on your switch.
Student-05#show event-monitor mac

2014-03-15 15:19:27|4094|00:1c:73:68:d7:75|Port-
Channel1000|learnedDynamicMac|added|0
2014-03-15 15:19:27|4094|00:1c:73:68:d7:75|||removed|1
2014-03-15 15:19:28|4094|00:1c:73:68:d7:75|Port-
Channel1000|learnedDynamicMac|added|2
2014-03-15 15:19:31|4094|00:1c:73:68:d7:75|||removed|3
Student-05#
Step 3
Using the “show event-monitor route” command, view any route table changes that have
occurred on your switch
Student-05#show event-monitor route

2014-03-15 15:19:06|127.0.0.0/8|kernel|0|1|added|0
2014-03-15 15:19:06|0.0.0.0/8|kernel|0|1|added|1
2014-03-15 15:19:06|127.0.0.1/32|connected|1|0|added|2
2014-03-15 15:19:14|10.0.0.0/24|connected|1|0|added|3

2014-03-15 15:19:14|10.0.0.255/32|receiveBcast|0|1|added|4
2014-03-15 15:19:14|10.0.0.5/32|receive|0|1|added|5
2014-03-15 15:19:19|10.100.100.8/30|connected|1|0|added|7
2014-03-15 15:19:19|10.100.100.9/32|receive|0|1|added|9
2014-03-15 15:19:28|10.100.100.10/32|attached|0|1|added|11
Student-05#
TASK 2: Force an update to the route table and inspect the event-monitor data.
Step 1
Add the following static route to your switch:
ip route 192.168.0.0/24 10.0.0.100
Student-05#conf
Student-05(config)#ip route 192.168.0.0/24 10.0.0.100
Student-05(config)#
Step 2
Inspect your route change in the event-monitor database.
Student-05#show event-monitor route | grep 192.168

2014-03-15 16:24:52|192.168.0.0/24|staticConfig|0|1|added|12
Student-05#
End of lab

13 Latency Analyzer (LANZ)

Lab Objectives:
• Enable LANZ globally
• Configure the LANZ thresholds to the lowest possible values
• Generate traffic and observe LANZ data
NOTE: The lab is not set up with traffic generators, and generating enough packets to
overwhelm the buffers on these switches is unlikely. As a result, it may be difficult to
show any meaningful output with LANZ in the current lab.
TASK 1: Configure LANZ.
Step 1
Enable LANZ globally.
Student-05#conf
Student-05(config)#queue-monitor length
Student-05#
Step 2
On all interfaces, set the queues to the lowest possible values.
Student-05(config)#int e1-$
! Interfaces Ethernet23, Ethernet24 are members of the MLAG peer link
Port-Channel1000
Student-05(config-if-Et1-24)#queue-monitor length thresholds 2 1
Student-05(config-if-Et1-24)#exit
Student-05(config)#
Questions
1.) What do the numbers “2” and “1” represent in the “queue-monitor length thresholds”
command
TASK 2: Generate traffic that will cause LANZ thresholds to be exceeded.
Step 1
Enter bash
Student-05#bash

Step 2
Ping your lab partners MLAG Peer IP using the example ping. Make sure you use the
correct IP Address.
ping -c 1000 -s 20000 10.100.100.X > /dev/null &
[admin@Student-05 ~]$ ping -c 1000 -s 20000 10.100.100.10 > /dev/null &

[1] 14461
NOTE: This command will send 1,000 20KB packets in the background. You should
repeat this many times to create enough traffic (approx. 10) Make sure you include the
ampersand at the end.
TASK 3: Inspect LANZ data.
Step 1
Exit bash
[admin@Student-05 ~]$ exit

logout
Student-05#
Step 2
Inspect the LANZ data using the “show queue-monitor length” and “show queue-monitor
length tx-latency” commands.
Student-05#show queue-monitor length
Report generated at 2014-03-15 16:33:47

E-End, U-Update, S-Start, TC-Traffic Class
GH-High, GU-Update, GL-Low
Segment size for E, U and S congestion records is 480 bytes
Segment size for GL, GU and GH congestion records is 160 bytes
* Max queue length during period of congestion
+ Period of congestion exceeded counter
-----------------------------------------------------------------------
---------
Type Time Intf Congestion Queue Time
of Max
(TC) duration length Queue
length
(usecs) (segments)
relative to
congestion
start
(usecs)
-----------------------------------------------------------------------
---------
E 0:00:00.15402 ago Et23(1) 27 2* 0

S 0:00:00.15405 ago Et23(1) N/A 2 N/A

E 0:00:00.30997 ago Et23(1) 88 2* 0
S 0:00:00.31005 ago Et23(1) N/A 2 N/A
<output omitted>
Student-05#sh queue-monitor length tx-latency
Report generated at 2014-03-15 16:34:32

Time Intf( TC ) Tx-Latency (usecs)
-----------------------------------------------------------------
0:00:00.06329 ago Et23(1) 1.180
0:00:00.06332 ago Et23(1) 1.180
0:00:00.11926 ago Et23(1) 1.180
0:00:00.11935 ago Et23(1) 1.180
0:00:00.17530 ago Et23(1) 1.180
0:00:00.17533 ago Et23(1) 1.180
<output omitted>
Questions
2.) What interface and traffic class is hitting the LANZ threshold?
3.) During your testing, what is the max number of segments observed? What is this in
bytes?
4.) During your testing, what is the max Tx-Latency induced by buffering?
TASK 4: When you are done and if it’s necessary, clean up the processes.
Step 1
Enter bash
Student-05#bash
Step 2
Kill all the ping processes you started. Your output may differ.

[admin@Student-05 ~]$ killall ping

[1] Terminated ping -s 18000 -c 10000 10.100.100.37
[4]- Terminated ping -s 18000 -c 10000 10.100.100.37
[5]+ Terminated ping -s 18000 -c 10000 10.100.100.37
End of lab

14 VM Tracer
Lab Objectives:
• Configure and verify VM Tracer
• Inspect various outputs from show commands
• Modify the allowed vlan list and observe
NOTE: In the Alab, there are 5 ESXi hosts attached to the student switches on interface
Ethernet 1 in the following way:
ESXi1 vmnic2 – Student-01 e1





Note: Other labs may have fewer student switches, and thus fewer ESXi hosts. For
example Blab had 10 student switches and therefore only three ESXi hosts.
The VMs are configures as shown in the following drawing. Each switch pair is
configured similarly, though the VM names will vary. Note that the VMs may have port
channels configured which may result in VMs being seen on only one switch due to
hashing.

TASK 1: Configure and verify VM Tracer
Step 1
Configure a VM Tracer session with VCenter with the following parameters:
Session Name: Lab

vCenter IP address : 10.0.0.99
Username: root
Password: vmtracer
Student-01#conf
Student-01(config)#vmtracer session Lab
Student-01(config-vmtracer-Lab)#url https://10.0.0.99/sdk
Student-01(config-vmtracer-Lab)#user root
Student-01(config-vmtracer-Lab)#pass vmtracer
Student-01(config)#
Step 2
Verify VM Tracer session is up

Student-01#sho vmtracer session

Session Lab
vCenter URL https://10.0.0.99/sdk
username root
autovlan enabled
allowed-vlans 1-4094
sessionState Connected
Step 3
Configure Ethernet 1 for vmtracer
Student-01(config-if-Po1)#vmtracer vmware-esx
Student-01(config-if-Po1)#switchport mode trunk
Student-01(config)#
TASK 2: Observe information about the VMs on the ESXi host attached to your
switch.
NOTE: Outputs will vary depending on your switch.
NOTE: VM-Tracer can take a minute before VM information is populated.
Step 1
Use the “show vmtracer vm” command to display a list of the virtual machines on the
network
Student-01#sho vmtracer vm
VM Name Esx Host
Interface
----------------- ------------------------------------- -------------
E1-Linux-1 10.0.0.201 Et1
VM Name Logical Switch / VLAN Status VTEP IP

----------------- -------------------------- ---------- ---------------
E1-Linux-1 201 Up/Down --
Student-01#
Step 2
Use the “sh vmtracer vm detail" command to display detailed information about a
specific VM
Student-01#sho vmtracer vm detail
VM Name : E1-Linux-1
Data Center : A-Lab

vCenter instance : https://10.0.0.99/sdk

Host : 10.0.0.201
Status : Up/Down
vNIC : Network adapter 1
vNIC MAC addr : 00:50:56:b3:ae:b1
vNIC Portgroup : PG-1
vNIC VLAN : 201
vSwitch / vDS : vSwitch1
vSwitch MTU : 1500
Logical Switch : --; no active VSM or NSX connection
VNI : --
VTEP IP : --; no active VSM or NSX connection
Transport VLAN : --
Host PNIC : vmnic1
Physical switchport : Et1
Transport Zone : --
Step 3
Use the “show vmtracer interface” to display the hosts and VMs by interface
Student-01#sho vmtracer interface
Ethernet1 : 10.0.0.201/vSwitch1/vmnic1
VM Name VM Adapter Logical Switch / VLAN Status
------------- -------------------- ---------------------- ----------
E1-Linux-1 Network adapter 1 201 Up/Down
VM Name VTEP IP State

------------- -------------------- ------------
E1-Linux-1 -- --
Step 4
Use the “show vmtracer all” to view all the VMware hosts and adaptors connected to all
the switches in your topology
Note: This output will vary depending on how many students have configured VM-
Tracer.
Student-01#sho vmtracer all
Switch : Student-03(10.0.0.3)
VM Name VM Adapter VLAN Status State
E1-Linux-2 Network adapter 1 201 Up/-- --

Step 5
Use the “show vmtracer interface host” to view information about the physical machines
that host the VMs.
Student-01#sho vmtracer interface host
Ethernet1 : 10.0.0.201
Manufacturer: Supermicro
Model: X8STi
CPU type: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
CPUs : 1
CPU Cores: 4
NIC Manufacturer: Intel Corporation
NIC Model: 82571EB Gigabit Ethernet Controller (Copper)
Service Tag: 1234567890

TASK 3: Observe the autovlan feature, re-configure the allowed vlan list and
verify
Step 1
Use the “show vmtracer session” command to verify the autovlan features is enabled
(default) and the range of allowed vlans is 1-4094
Student-01#sho vmtracer session

Session Lab
username root
autovlan enabled
allowed-vlans 1-4094
Step 2
Use the “show vlan” command to verify the autovlan feature. VLANs that were
dynamically created are marked with an asterisk (*).
Student-01#sho vlan
----- --------------------------- --------- --------------------------
1 default active Et1, Et19, Et20, Et21, Et22
Et23, Et24
201* VLAN0201 active
* indicates a Dynamic VLAN
Step 3
Use the “autovlan disable” and “allowed-vlan” commands to prohibit VLAN 201 from
being learned.


Student-01(config-vmtracer-Lab)#allowed-vlan remove 201
Student-01(config-vmtracer-session_1)#exit
Student-01(config)#
Step 4
Use the “show vmtracer session” command to verify. Note that you may need to exit and
re-enter this configuration mode. Note the list of allowed-vlans.
Student-01(config)#sho vmtracer session

Session Lab
username root
autovlan enabled
allowed-vlans 1-200,202-4094
Step 5
Use the “show vlan” command to verify. Note the lack of VLAN 201.
Student-01(config)#sho vlan
----- ----------------------- --------- -------------------------------
Et23, Et24
Step 6
Reverse the VLAN limitation by allowing only VLAN 201.

Student-01(config-vmtracer-Lab)#allowed-vlan none
Student-01(config-vmtracer-Lab)#allowed-vlan 201
Student-01(config-vmtracer-Lab)#exit
Student-01(config)#
Step 5
Use the “show vlan” command to verify. Note the addition of VLAN 201.
Student-01(config)#sho vlan
----- ----------------------- --------- -------------------------------
Et23, Et24
201* VLAN0201 active
* indicates a Dynamic VLAN

End of Lab

15 Advanced Mirroring
Lab Objective:
• Configure a mirror session that sends captured dataplane traffic to the CPU
• Use TCPDUMP to view the capture traffic
Diagram:
TASK 1: Set up Layer 3 interfaces between your switch and the “DANZ” switches.
Step 1
Enable IP routing.
Student-05#conf
Student-05(config)#ip routing
Student-05(config)#
Step 2
Configure ethernet19 and 20 as router L3 interfaces with an IP/mask according to the
table below.

NOTE: All student switches should be connected to DANZ-1 on port ethernet 19 and
DANZ-2 on port 20. Confirm this with “show lldp neighbors” command.
Switch Eth19 (to DANZ-1) Eth20 (to DANZ-2)

Student-01 192.168.1.2/30 192.168.1.6/30
Student-02 192.168.2.2/30 192.168.2.6/30
Student-03 192.168.3.2/30 192.168.3.6/30
Student-04 192.168.4.2/30 192.168.4.6/30
Student-05 192.168.5.2/30 192.168.5.6/30
Student-06 192.168.6.2/30 192.168.6.6/30
Student-07 192.168.7.2/30 192.168.7.6/30
Student-08 192.168.8.2/30 192.168.8.6/30
Student-09 192.168.9.2/30 192.168.9.6/30
Student-10 192.168.10.2/30 192.168.10.6/30
Student-11 192.168.11.2/30 192.168.11.6/30
Student-12 192.168.12.2/30 192.168.12.6/30
Student-13 192.168.13.2/30 192.168.13.6/30
Student-14 192.168.14.2/30 192.168.14.6/30
Student-15 192.168.15.2/30 192.168.15.6/30
Student-16 192.168.16.2/30 192.168.16.6/30
Student-17 192.168.17.2/30 192.168.17.6/30
Student-18 192.168.18.2/30 192.168.18.6/30
Student-19 192.168.19.2/30 192.168.19.6/30
Student-20 192.168.20.2/30 192.168.20.6/30
Example (student-05)
! IP configuration will be ignored while interface Ethernet19 is not a
routed port.
Student-05(config-if-Et19)#int e20
! IP configuration will be ignored while interface Ethernet20 is not a
routed port.
Student-05(config)#
Step 3
Verify you can ping both remote ends of the new subnets.


ms
Student-05#

ms
Student-05#
TASK 2: Use TCPDUMP to sniff pings from DANZ-1 to your switch.
Step 1
Enter bash on your switch.
Student-05#bash
Step 2
Enter the “tcpdump –i et19” command to begin sniffing interface eth19.
[admin@Student-05 ~]$ tcpdump -i et19

tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on et19, link-type EN10MB (Ethernet), capture size 65535
bytes
Step 3
Establish an additional ssh session with the linux management server. For help, see
“LAB0: Accessing the Lab.”
Step 4
From the linux management server, login into DANZ-1 switch.

NOTE: You don’t need the enable password to complete this lab.
st05@ALab-Linux:~$ danz-1
known hosts.
+---------------------------------------+
| Switch: DANZ-1 |
| |
+---------------------------------------+
Last login: Wed Aug 20 10:05:35 2014 from 10.0.0.100
DANZ-1>
Step 5
With your TCPDUMP still running, ping your IP on eth19 from DANZ-1.
Example ping on switch student-05
DANZ-1#ping 192.168.5.2

ms
DANZ-1#
Example tcpdump on switch student-05

decode
bytes
02:48:56.421841 00:1c:73:1f:38:9e (oui Arista Networks) >
00:1c:73:68:d7:f7 (oui Arista Networks), ethertype IPv4 (0x0800),
length 114: 192.168.5.1 > 192.168.5.2: ICMP echo request, id 4956, seq
1, length 80
02:48:56.421895 00:1c:73:68:d7:f7 (oui Arista Networks) >
00:1c:73:1f:38:9e (oui Arista Networks), ethertype IPv4 (0x0800),
length 114: 192.168.5.2 > 192.168.5.1: ICMP echo reply, id 4956, seq 1,
length 80
2, length 80


length 80
3, length 80
length 80
4, length 80
length 80
5, length 80
length 80
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
TASK 3: Use TCPDUMP on eth19 to sniff pings from DANZ-1 to DANZ-2.
Step 1
Enter the “tcpdump –i et19” command to begin sniffing interface eth19.

decode
bytes
Step 2
From DANZ-1, ping 192.168.X.5, where X is your student number. This is the remote
end of the /30 on eth20 and resides on DANZ-2.
Example for student-05

DANZ-1>ping 192.168.5.5

ms
DANZ-1>
Questions
1.) Why didn’t your tcpdump capture the ICMP requests and replies?
2.) What could you configure to capture this traffic?
TASK 4: Configure and a mirror session that sniffs traffic on eth19 and sends
traffic to CPU.
Step 1
Configure a mirror session with the following paramters:
Source interface eth19

Both transmit (tx) and receive (rx) directions
Destination Cpu
Student-05#conf
Student-05(config)#monitor session sniff source eth19 both
Student-05(config)#monitor session sniff destination Cpu
Student-05(config)#
Step 2
Use the “show monitor session” command to determine what interface the CPU is
mirroring to.

Student-05#sh monitor session
Session sniff
------------------------
Source Ports
Both: Et19
Destination Ports:
Cpu : active (mirror1)
Student-05#
TASK 5: Use TCPDUMP on the mirror interface to sniff pings from DANZ-1 to
DANZ-2.
Step 1
Enter the “tcpdump –i mirror X” command where X equals the number shown from the
“show monitor session” command.
[admin@Student-05 ~]$ tcpdump -i mirror1

tcpdump: WARNING: mirror1: no IPv4 address assigned
decode
listening on mirror1, link-type EN10MB (Ethernet), capture size 65535
bytes
Step 2
From DANZ-1, ping 192.168.X.5, where X is your student number. This is the remote
end of the /30 on eth20 and resides on DANZ-2.
DANZ-1>ping 192.168.5.5

ms
DANZ-1>
Example tcpdump on student-05


decode
bytes
1, length 80
length 80
2, length 80
length 80
3, length 80
length 80
4, length 80
length 80
5, length 80
length 80
03:10:38.940835 00:1c:73:68:d8:0a (oui Arista Networks) >
01:80:c2:00:00:0e (oui Unknown), ethertype LLDP (0x88cc), length 195:
LLDP, length 181: Student-05
^C
11 packets captured

Questions
3.) Explain why your tcpdump now captures the ICMP requests and replies.
4.) What is the maximum amount of traffic that the CPU will receive?
End of lab

16 Tap Aggregation
Lab Objectives:
• Configure the switch for tap aggregation mode
• Configure tap ports
• Configure tool ports
• Using aggregation groups, map tap ports to tool ports
• Observe filtering behavior of using the aggregation groups
• Filtering traffic using traditional ACLs
NOTE: You will need to work closely with your lab partner in this lab. Each switch will
have different configs and each partner will perform different tasks during the lab. Both
switches will be configured for Tap Aggregation Mode, but the odd numbered switch will
act as the Tap Aggregator while the even numbered will act as the Tool/Sniffer.
Diagram:
NOTE: The diagram below depicts basic connectivity. The lab builds off this diagram.
TASK 1: Configure, verify and observe Tap Aggregation mode on BOTH ODD and
EVEN numbered switches.
Step 1
Configure tap aggregation mode on both switches in you pair.
Student-05#conf
Student-05(config)#tap aggregation
Student-05(config-tap-agg)#mode exclusive
Student-05(config-tap-agg)#exit
Student-05(config)#
Student-06#conf
Student-06(config-tap-agg)#mode exclusive
Student-06(config)#
Step 2
Disable spanning-tree and igmp.
NOTE: While STP and IGMP snooping have no impact on tap/tool interfaces when left
enabled, the recommendation is to disable these two protocols.
Student-05#conf
Student-05(config)#spanning-tree mode none
Student-05(config)#no ip igmp snooping
Student-05(config)#
Student-06#conf
Student-06(config)#spanning-tree mode none
Student-06(config)#no ip igmp snooping
Student-06(config)#
Step 3
Verify your switch is in tap aggregation mode.
Student-05#sh run section tap

tap aggregation
mode exclusive
Student-05#
Step 4
Using the “show interfaces status” command, observe the interfaces status on your switch
while tap aggregation mode is configured.
Student-05#sh int status

Type
Et1 The link is down errdisabled 1 auto auto
1000BASE-T
Et2 errdisabled 1 full 10G Not
Present


Present
Present
Present
Present
<output omitted>
Questions
1.) In what state are all ports? Explain why.
TASK 2 (FOR ODD NUMBERED SWITCH ONLY): Configure Tap and Tool ports
on the ODD numbered switch.
Diagram:
Step 1
Configure interface Eth19 and Eth20 as a TAP ports.

NOTE: Use the “default interface” command to clear current configs.
Student-05#conf
Student-05(config)#default interface eth19-20
Student-05(config-if-Et19-20)#switchport mode tap
Student-05(config)#
Step 2
Configure interfaces Eth23 and Eth24 as TOOL ports.
NOTE: Use the “default interface” command to clear current configs
Student-05#conf
Student-05(config-if-Et23-24)#switchport mode tool
Student-05(config)#
Step 3
Use the “show interfaces status” command to check the status of your tap and tool ports.
Student-05(config)#sh int status | grep tool

Et23 connected tool full 10G
10GBASE-CR
Et24 connected tool full 10G
10GBASE-CR
Student-05(config)#sh int status | grep tap
Et19 connected tap full 10G
10GBASE-CR
10GBASE-CR
Student-05(config)#
Questions
2.) What happened to the status of the tap and tool ports?
TASK 3 (FOR EVEN NUMBERED SWITCH ONLY): Configure Tap ports on the
EVEN numbered switch.

Diagram:
Step 1
Configure interface Eth23 and Eth24 as a TAP ports.
NOTE: Use the “default interface” command to clear current configs.
Student-06#conf
Student-06(config-if-Et23-24)#switchport mode tap
Student-06(config)#
Step 2
Use the “show interfaces status” command to check the status of your tap and tool ports.
Student-06#sh interface status | grep tap

10GBASE-CR
10GBASE-CR
Student-06#

Questions
3.) What happened to the status of the tap ports?
TASK 4 (FOR ODD NUMBERED SWITCH ONLY): Configure tap aggregation

groups.
Diagram:
Step 1
Configure tap port Eth19 for tap aggregation group “1”.
Student-05#conf
Student-05(config-if-Et19)#switchport tap default group 1
Student-05(config)#
Step 2
Configure tap port Eth20 for tap aggregation group “2”.

Student-05#conf
Student-05(config-if-Et20)#switchport tap default group 2
Student-05(config)#
Step 3
Configure tool port Eth23 for tap aggregation group “1”.
Student-05(config-if-Et23)#switchport tool group set 1
Student-05(config)#
Step 4
Configure tool port Eth24 for both tap aggregation group “1” and group “2”.
Student-05(config-if-Et24)#switchport tool group set 1
Student-05(config-if-Et24)#switchport tool group add 2
Student-05(config)#
Step 5
Use the “show tap aggregation groups” command to verify the tap aggregation group
configuration.
Student-05#
Student-05#show tap aggregation groups
Group Name Tool Members Tap Members
---------------- ------------------ -----------
1 Et23, Et24 Et19
2 Et24 Et20
Student-05#
TASK 5 (FOR EVEN NUMBERED SWITCH ONLY): Configure 2 mirror sessions

with the following parameters.

Diagram:
Session 1:
Name: group_1
Source interface: eth23
Destination: Cpu
Session 2:
Name: group_1_2
Source interface: eth24
Destination: Cpu
Step 1
Configure the monitor session named “group_1” that mirrors traffic on eth23 to the Cpu.
Student-06#conf
Student-06(config)#monitor session group_1 source Ethernet23
Student-06(config)#monitor session group_1 destination Cpu
Step 2
Configure the monitor session named “group_1_2” that mirrors traffic on eth24 to the
Cpu.
Student-06#conf
Student-06(config)#monitor session group_1_2 source Ethernet24
Student-06(config)#monitor session group_1_2 destination Cpu
Student-06(config)#

Step 3
Verify the monitor sessions with the “show monitor sessions” command.
Student-06#sh monitor session
Session group_1
------------------------
Source Ports:
Both: Et23
Destination Ports:
Session group_1_2
------------------------
Source Ports:
Both: Et24
Destination Ports:
TASK 6: (FOR EVEN NUMBERED SWITCH ONLY): Using tcpdump, start

packet captures on both mirror interfaces.
NOTE: You will need to have 2 ssh sessions open to your switch to complete this task.
NOTE: Use the output from the “show monitor sessions” to determine the name of the
mirror interfaces (e.g. mirror2, mirror3).
Step 1
From BASH, enter the “tcpdump –i mirror X” command where X equals one of the
numbers shown from the “show monitor session” command.

decode
bytes

No duplication without written consent - Prepared for HPE Trainers 1-31-17Page 100
Step 2
From BASH, enter the “tcpdump –i mirror” command where X equals the other of the
numbers shown from the “show monitor session” command.

decode
bytes
NOTE: You may need to wait up to 30 seconds to answer the following questions.
Questions
4.) What type of traffic are you capturing?
5.) What device is generating this traffic?
6.) Where (physically) is the original traffic (i.e. what network link?)
TASK 7: Generate traffic from DANZ-1.
Step 1
One student needs to log into DANZ-1
St05@ALAB-Linux:~$ danz-1
known hosts.
+---------------------------------------+
| Switch: DANZ-1 |
| |
+---------------------------------------+
Last login: Sat Mar 15 18:45:42 2014 from 10.0.0.100
DANZ-1>

Step 2
With tcpdump running on BOTH mirror sessions on the EVEN Numbered switch, ping
192.168.X.2 where X = your student number.
Example Ping:
DANZ-1>ping 192.168.5.2

8005ms
pipe 2
DANZ-1>
Example packet capture from mirror session w/ source of eth23 on even numbered
“switch-06”
admin@Student-06 ~]$ tcpdump -i mirror2

decode
bytes
14:54:21.529367 00:1c:73:1f:38:9e (oui Arista Networks) > Broadcast,
ethertype ARP (0x0806), length 60: Request who-has 192.168.5.2 tell
192.168.5.1, length 46
192.168.5.1, length 46
192.168.5.1, length 46
ethertype
<output omitted>
“switch-06”

decode
bytes


192.168.5.1, length 46
192.168.5.1, length 46
192.168.5.1, length 46
ethertype
<output omitted>
Questions
7.) Why do the pings fail?
9.) Do you capture the traffic in both mirror sessions? Why or why not?
TASK 8: (FOR ODD NUMBERED SWITCH ONLY): Configure an egress ACL on

Tool port Eth24

Diagram:
Step 1
Configure an ACL that denies traffic to 192.168.5.0/24.
Student-05(config)#
Student-05(config)#ip access-list Remove_net_192-168-5-0
Student-05(config-acl-Remove_net_192-168-5-0)#deny ip any
192.168.5.0/24 log
Student-05(config-acl-Remove_net_192-168-5-0)#exit
Student-05(config)#
Step 2
Apply the acl on EGRESS on tool port eth24.
HINT: You can tab complete your access-list!!!
Student-05#conf
Student-05(config-if-Et24)#ip access-group Remove_net_192-168-5-0 out
Student-05(config)#
TASK 9: Generate traffic from DANZ-1 again.

Step 1
With TCPDUMP running on BOTH mirror sessions on the EVEN Numbered switch,
issue a ping from DANZ-1 to 192.168.X.2 where X = your student number.
“switch-06”

decode
bytes
192.168.5.1, length 46
192.168.5.1, length 46
192.168.5.1, length 46
<output omitted>
“switch-06”

decode
bytes
^C
0 packets captured
Questions
Step 2
From the ODD numbered switch, use the “sh platform fm6000 acl detail” command to
see your ACL matches/denies.

Student-05#sh platform fm6000 acl detail
=== IP ACLs on switch Alta0 ===
=== ACL Remove_net_192-168-5-0 (Out)

Assigned to ports: Ethernet24
Count: 73
Seq Proto/Mask Src IP Src Mask Src Port Dscp
Frag Flags Dest IP Dest Mask DestPort Action
Hits
10 0x00/0x00 0.0.0.0 /0.0.0.0 0x0000/0x0000
0x00/0x00 00 0x00/0x00 192.168.5.0 /255.255.255.0 0x0000/0x0000
Deny X
Drop 0x00/0x00 0.0.0.0 /0.0.0.0 0x0000/0x0000
0x00/0x00 00 0x00/0x00 0.0.0.0 /0.0.0.0 0x0000/0x0000
Deny X
<output omitted>
TASK 10: Generate traffic from DANZ-2.
Step 1
One student needs to log into DANZ-2.
St05@ALAB-Linux:~$ danz-2
Could not create directory '/home/St05/.ssh'.
known hosts.
+---------------------------------------+
| Switch: DANZ-2 |
| |
+---------------------------------------+
Last login: Mon Mar 31 23:29:21 2014 from 10.0.0.100
DANZ-2>
Step 2
With TCPDUMP running on BOTH mirror sessions on the EVEN Numbered switch,
ping 192.168.X.6 where X = your student number.

DANZ-2>ping 192.168.5.6

8006ms
pipe 2
DANZ-2>
“switch-06”

decode
bytes
^C
0 packets captured
“switch-06”

decode
bytes
15:05:08.816236 00:1c:73:1f:44:da (oui Arista Networks) > Broadcast,
192.168.5.5, length 46
192.168.5.5, length 46
192.168.5.5, length 46
Questions

TASK 11: Disable Tap Aggregation.
Student-05#conf
Student-05(config-tap-agg)#no mode exclusive
Student-05(config)#
End of lab

17 Extensible API (eAPI)

Lab Objectives:
• Optionally configure port forwarding so that you can see the API GUI.
• Write Python scripts designed that:
o Retrieve information about the switch using the EAPI
o Configure the switch using eAPI
eAPI Prep (Optional)
How to connect to the linux lab server with port forwarding from the command
line:
NOTE: If you cannot get port forwarding to work, it's not a huge deal. You'll still be able
to write eAPI scripts on the linux box. The only think the Port-forwarding gets you is the
ability to see the webpage on the switch.
Step 1
Open an SSH session to the linux box with the following command (if you have an SSH-
enabled OS such as OSX):
Step 2
NOTE: The following instructions are for alab.arista.com. Replace “alab” with the rack
you are working on e.g. blab.
Add the following line to your session:

ssh -l stxx alab.arista.com -L localhost:9443:10.0.0.xx:443
NOTE: xx = your switch number, two digits, padded with zeros (01, 05, 15, etc.)
How to connect to the linux lab server with port forwarding from SecureCRT:
Step 1
Create a new session. The protocol is SSH. The hostname is alab.arista.com.
Step 2
Go to “Properties”, then “Port Forwarding”.

Step 3
Click “Add”, configure according to the following IP addresses. Click “OK” when done.
Student-01: 10.0.0.1
Student-02: 10.0.0.2
Student-03: 10.0.0.3
...
Student-15: 10.0.0.15
etc.
NOTE: This example shows a configuration for Student-01. The name can be anything
you'd like.

Step 4
Connect to the linux lab server using this config.
eAPI Lab
TASK 1: Verify eAPI and username Script is configured on your switch
Step 1
Verify your switch has eAPI enabled.

WARNING: If the below config is not present on your switch, add it now. You will need it
to complet this lab.
Student-05#sh run section api

management api http-commands
no shutdown
Student-05#
Step 2
Verify the username “Script” is configured on your switch.
WARNING: If the below config is not present on your switch, please let the instructor
know.
Student-05#sh run | grep user

username Script secret 5 $1$NYfdgjJG$it14zRJf11N8oz1ywOIGK/
username student-05@class.com password 7 0227165218120E
Student-05#
TASK 2: Create a simple python script that retrieves information from your switch.
Step 1
In your home directory on the Linux Lab Server, create the following script.
NOTE: Be sure to replace the “xx” with your switch number.
ALAB-Linux:~$ vi eapi_show.py
#!/usr/bin/python
from jsonrpclib import Server
switch = Server( "https://Script:Arista@10.0.0.xx/command-api" )
response = switch.runCmds( 1, [ "show version" ] )
print response
~
~
~
:wq
Step 2
Give your script execute permissions.
St05@ALAB-Linux:~$ chmod 775 eapi_show.py

Step 3
Run your script and if necessary, debug.
St05@ALAB-Linux:~$ ./eapi_show.py
[{u'memTotal': 4017088, u'internalVersion': u'4.13.1F-1576566.4131F.2',
u'serialNumber': u'JPE13463510', u'systemMacAddress':
u'00:1c:73:68:d7:f7', u'bootupTimestamp': 1394942980.6761389,
u'memFree': 1474556, u'version': u'4.13.1F', u'modelName': u'DCS-7150S-
24-CL-F', u'internalBuildId': u'f2bbcdc2-58a1-4864-83fb-6341568e499b',
u'hardwareRevision': u'02.00', u'architecture': u'i386'}]
St05@ALAB-Linux:~$
Step 4
Add the following lines to your script (feel free to alter this if you'd like):
print "The system MAC addess is: ", response[0][ "systemMacAddress" ]

print "The system version is: ", response[0][ "version" ]
print "The system serial number is:", response[0][ "serialNumber" ]
Step 5
Re-run the script and if necessary, debug.
TASK 4: Create a python script that requires enable mode and configures your
switch.
Step 1
In your home directory on the linux lab server, create the following script.
NOTE: Be sure to replace the “xx” with your switch number.
ALAB-Linux:~$ vi eapi_conf.py
#!/usr/bin/python

response = switch.runCmds( 1, [
"enable" ,
"configure" ,
"interface ethernet 5",
"description [ I *REALLY* Like Pie! ]" ] ,
"json")
print "Done."
:wq

Step 2
Give your script execute permissions.
St05@ALAB-Linux:~$ chmod 775 eapi_conf.py
Step 3
Run your script and if necessary, debug.
St05@ALAB-Linux:~$ ./eapi_conf.py
Done.
Step 4
Verify your script worked by modifying your original script or create a new one that is
designed to run the command “show interface Ethernet 5”.
NOTE: You need to enter enable mode in your script to run this command.
#!/usr/bin/python

response = switch.runCmds( 1, [
"enable" ,
"show interfaces ethernet 5"
] ,
"text")
print response
~
~
:wq
Step 5
Re-run your script to verify the description was changed.
St05@ALAB-Linux:~$ ./eapi_show.py
[{u'output': u''}, {u'output': u'Ethernet5 is down, line protocol is
notpresent (notconnect)\n Hardware is Ethernet, address is
001c.7368.d7fc (bia 001c.7368.d7fc)\n Description: [ I *REALLY* Like
Pie! ]\n Ethernet MTU 9214 bytes , BW 10000000 kbit\n Full-duplex,
10Gb/s, auto negotiation: off, uni-link: unknown\n 0 link status
changes since last clear\n Last clearing of "show interface" counters
never\n 5 minutes input rate 0 bps (0.0% with framing overhead), 0
packets/sec\n 5 minutes output rate 0 bps (0.0% with framing
overhead), 0 packets/sec\n 0 packets input, 0 bytes\n Received
0 broadcasts, 0 multicast\n 0 runts, 0 giants\n 0 input errors,
0 CRC, 0 alignment, 0 symbol, 0 input discards\n 0 PAUSE input\n
0 packets output, 0 bytes\n Sent 0 broadcasts, 0 multicast\n 0
output errors, 0 collisions\n 0 late collision, 0 deferred, 0
output discards\n 0 PAUSE output\n'}
End of lab

18 Appendix A: BGP Route Selection Decision Process

Selection BGP4 RFC
Arista Cisco Juniper
step 4271
Non-standard Highest Weight
1 Highest LOCAL_PREF
Prefer locally /
internally
Non-standard originated routes
over received
ones
2 Shortest AS_PATH
3 Lowest ORIGIN: IGP < EGP < incomplete (e.g. redistributed static)
4 Lowest MED
Prefer locally /
internally
Non-standard originated routes
over received
ones
Smallest IGP
Prefer eBGP Prefer eBGP Prefer eBGP
5 metric to next
over iBGP over iBGP over iBGP
hop
Smallest IGP Smallest IGP Smallest IGP
Prefer eBGP
6 metric to next metric to next metric to next
over iBGP
hop hop hop
Non-standard BGP Multipath option
Non-standard Oldest route
7 Lowest BGP Originator ID, or Router ID if no Originator ID is present
8 (RFC4456
Smallest RR cluster list
standard)
9 Lowest BGP peering address

19 Appendix B: Answers to Lab Questions

CLI and BASH
1.) What version of EOS will be used when the switch is booted?
Answer depends on the switch’s boot config
2.) What versions of EOS are currently on flash?

Answer depends on the flash content of the switch
3.) What other config files are stored on flash?

startup-config
zerotouch-config
Aboot
1.) Is it necessary to save the configuration after these commands?

No.
2.) If so, why? If not, why not?

The boot-config file is independent of the running or startup configs
3.) What EOS version did your switch have after the fullrecover? Ask your partner what
is the version they have after the fullrecover.
Answers will vary
4.) Why didn’t you have to enter an Aboot password after the fullrecover?
The fullrecovery deleted the contents of the flash which included the boot-config file.
5.) In this lab, ZTP loads a configuration from the webserver (We'll see this in detail
when we study ZTP). What would be the result if ZTP/DHCP/etc. was not configured?
The switch would have the default startup configuration
Upgrade EOS
1.) What other ways could you have verified the new EOS image file was successfully
copied to flash?
Go to BASH, cd /mnt/flash and enter the “ls” command
From the CLI enter the command “bash ls /mnt/flash”
2.) How else could you have verified the boot-config settings?
Go to BASH, cd /mnt/flash and enter the “cat boot-config”
From the CLI enter the command “bash cat /mnt/flash/boot-config”

EOS Architecture
1.) What is the difference between using Cli and FastCli from the bash shell?
Cli spawns an new Cli session, FastCli runs as a daemon and executes commands quicker
than Cli and also uses less memory.
2.) List the current PIDs for the following processes:
Arp: Answers will vary
Stp: Answers will vary
Lldp: Answers will vary
Sysdb: Answers will vary
3.) What is the PID of the LLDP after killing it?

Answers will vary. If it was killed properly, the PID should diff from Q1.
Zero Touch Provisioning (ZTP)
1.) What other ways could you delete the startup-config?

Go to BASH, cd /mnt/flash and type “rm startup-config”
From the CLI enter the command “bash rm /mnt/flash/startup-config”
2.) What happened when zerotouch was cancelled?

The switch rebooted.
3.) Do you have a startup-config file in flash?

No.
4.) What would happen if you rebooted the switch right now without saving the running-
config?
The switch would enter ZTP mode again. “zerotouch cancel” only cancels ZTP for 1
reload or there is a startup-config on flash.
5.) What does disabling ZTP do? What would happen if you rebooted the switch now?
Disabling ZTP permanently cancels ZTP even when there is no startup-config file on
flash. The switch would not boot into ZTP mode. The switch would present a default
configuration.
7.) How else could you re-enable ZTP?

Vi the zerotouch-config and remove the line that says “DISABLE=TRUE”.
Multi-Switch CLI

1.) Were any errors found on the uplinks?

Answers may vary, but there shouldn’t be any errors.
2.) Which switch has the IP address?

Spine-2
3.) Are other switches connected? If so, what is the timestamp on the first switch that
responded?
Answers will vary.
Multi-Chassis Lag (MLAG)
1.) How many MLAG interfaces are in Active-full?

One. The uplink portchannel.
2.) How many active members are in port-channel999?

4. The 2 local interfaces and the 2 peer interfaces
3.) Which switch in your pair is the MLAG primary?

Answers will vary. The switch with the lowest System ID will become primary.
4.) What is the default value for the MLAG Reload delay? (Hint see output from show
mlag detail)
300 seconds.
5.) What does the MLAG Reload delay setting do?

The MLAG Reload delay specifies how long a switch will wait to bring up MLAG
interfaces after a reboot.
6.) While the primary is rebooting, what is the status of the MLAG interface(s) on the
secondary switch?
Active-partial. But the portchannel is still up and passing traffic on the remaining link.
7.) What happened to the MLAG primary/secondary status?

The original MLAG secondary should now be primary and the original MLAG primary
should be secondary.
8.) What is the status of the MLAG interfaces on both switches? HINT: use the ‘show
mlag detail’ and ‘show mlag interfaces’ commands
Active-Full. Up/Up.
9.) How long did it take the MLAG interfaces to come up? HINT: to view the status of
the reload-delay, use the ‘show mlag’ command and look at the ‘state’ under ‘MLAG
Status’
300 seconds.

BGP Equal Cost Multi-Pathing (ECMP)
1.) What routes are you receiving from the spine switches? HINT: use the “show ip bgp
neighbors 10.10.X.X received-routes” command.
You should be receiving two default routes (0.0.0.0/0), one from each of the spine
switches.
2.) Of the default routes (0.0.0.0/0) received from the spine switches, the active/best route
is from which neighbor? Use the “show ip route” command.
Your switch should have made active the default route received from spine-1.
3.) Using the chart “BGP Route Selection Decision Process” in Appendix A, determine
why the active route was chosen.
Lowest Router ID.
4.) What option do you need to enable to get your router to activate both default routes
from spine1 and spine2? HINT: Check the table in Appendix A.
BGP Multi-Path Option
5.) After enabling BGP Multipath, check the routing table again using “show ip route” Of
the default routes received from the spine switches, which are active now?
Both default routes should now be active.
6.) Ping the loopback of spine-1 (192.168.100.1). What is the source IP of this ping?
HINT: Establish another ssh session to your swich, go to the bash shell and type
“tcpdump –i et21” and then re-issue the ping from the original session.
The source IP of these packets is the interface IP which connects to the spine.
7.) Ping the loopback of spine-1 sourced from your interface loopback 1 IP “ping
192.168.100.1 source 10.1.X.1” Why does it fail?
It fails because the spine has no route to your loopback.
Vitrual Extensible LAN (VXLAN) Bridging
1.) Why does this ping fail?

Because this segment is not routed in the L3 spine. Nor is VXLAN configured yet.

2.) Was the ping successful?
The ping should be successful because VXLAN encapsulates the traffic and routes it
to the remote vtep.

3.) What devices/interfaces are assigned the MAC addresses in the outputs above?
It is the remote MAC address of the SVI configured on the remote DANZ switch. For
example, if this command was run on student-01, the remote MAC resides on
interface VLAN 102 on DANZ-2.


HINTS:
- Ensure both vteps are advertising their loopbacks. The vteps must be able to
reach each other.
- Switches need to be on code 4.13.1F or later.
- Ensure the switch crosslink is shutdown.
Advanced Event Management (AEM)
1.) How often does this scheduler execute and store the ‘show-tech’ command?
60 minutes.
2.) What is the max number of log files that will be kept on flash?
100.
3.) In what directory are these files stored? (write as much of the path as you can)
/mnt/flash/schedule/tech-support
Latency Analyzer (LANZ)
1.) What do the numbers “2” and “1” represent in the “queue-monitor length thresholds”
command?
The first number (2) represents, in buffer segments (480bytes) the high threshold. The
second number (1) represents, in buffer segments (480bytes) the low threshold.
2.) What interface and traffic class is hitting the LANZ threshold?
Answers may vary. It will be either Eth23 or 24, traffic class 1.
3.) During your testing, what is the max number of segments observed? What is this in
bytes?
Answers will vary. Multiple the number of segments by 480 bytes to derive how much
buffer is in use during the LANZ record. For example, if 88 segments were in use, this
means about 42K of packet was buffered during this event.
4.) During your testing, what is the max Tx-Latency induced by buffering?
Answers will vary.
VM Tracer
No Questions
Advanced Mirroring
1.) Why didn’t your tcpdump capture the ICMP requests and replies?

TCPDUMP will only capture traffic that is processed by the local CPU (i.e. control plane
traffic or any packets destined for the local device). It will NOT capture traffic that is
transiting the device (i.e. data plan traffic).
2.) What could you configure to capture this traffic?

A mirror session with destination of Cpu.
3.) Explain why the tcpdump on the mirror interface captures the ICMP requests and
replies.
Because the monitor session is mirroring all packets (control plane and data plane) traffic
to the Cpu.
4.) What is the maximum amount of traffic that the CPU will receive?
This traffic is shaped at around 100Mbps
Tap Aggregation
1.) In what state are all ports errdisabled? Explain why?

By default, when a switch is configured for Tap Aggregation Mode, all ports are
errdisable. This is because it has ceased to be a normal L2 switch.
2.) What happened to the status of the tap and tool ports?
The ports came up and are showing connected.
3.) What happened to the status of the tap ports?

The ports came up and are showing connected.

LLDP packets.
5.) What device is generating this traffic?

Danz-1
6.) Where (physically) is the original traffic (i.e. what network link?)
The link between the DANZ-1 switch and the ODD Numbered switch (should be Eth19
on the ODD Numbered switch.)
7.) Why do the pings fail?

Because Eth19 on the switch is configured as a TAP port and no longer an L3 port.

ARP and LLDP.
Yes. Because the traffic on Eth19 is identified with agg group tool1 and tool1 is
configured on both tools ports (Eth23 and 24)

No. The ARP packets are only captured on the Eth23 mirror session. This is because the
egress ACL on the ODD Numbered switch is denying packets to 192.168.5.0/24.
No. The ARP packets are only capture on the Eth24 mirror session. This is because the
aggregation group “2” is only applied on ODD Numbered switches Eth24.
Extensible API (EAPI)

No questions

CORPORATE HEADQUARTERS
5453 Great America Parkway,
Santa Clara, CA 95054
Phone: 408-547-5500
Fax: 408-538-8920
General Inquiries
Email: info@arista.com
US & North America Sales: us-sales@arista.com

Latin America Sales: latam-sales@arista.com
Europe, Middle East & Africa Sales: emea-sales@arista.com
Asia-Pacific Sales: apac-sales@arista.com
Japan Sales: japan-sales@arista.com
San Francisco Vancouver

1390 Market Street Suite 350, 3605 Gilmore Way
Suite 800 Burnaby, British Columbia
San Francisco, CA 94102 Canada V5G 4X5
R&D and Sales Office R&D Office
India Ireland
Eastland Citadel 4325 Atlantic Avenue
102, 2nd Floor, Hosur Road Westpark Business Campus
Madiwala Check Post Shannon
Bangalore – 560 095 Co. Clare, Ireland
R&D Office
Singapore
9 Temasek Boulevard
#29-01, Suntec Tower Two
Singapore 038989
Tel: +65 31571367
APAC Administrative Office

ACE 2.1.1 - Lab Guide - HPE Trainers

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ACE 2.1.1 - Lab Guide - HPE Trainers

Uploaded by

Copyright:

Available Formats

Arista Configuration Essentials

Copywrite 2012-2016 Arista Networks

• Do not change or remove the Management IP address.

Copywrite 2012-2016 Arista Networks

student-01 + student-02 student-11 + student-12

Copywrite 2012-2016 Arista Networks

2 Accessing the Lab

In this activity, you will:

See Instructor for the following lab access details:

TASK 1: Connect to the Lab Management Linux Server via SSH.

Username = stxx (case sensitive, xx represents your student number)

NOTE: Example below is shows direct SSH using command-line.

Copywrite 2012-2016 Arista Networks

Last login: Wed Aug 20 13:34:24 2014 from static-96-245-68-

TASK 2: Connect to the your switch via SSH.

TASK 3: Connect to the your switch via Console.

Copywrite 2012-2016 Arista Networks

st01@ALab-Linux:~$ console student-01

Attempting connection to console of student-01...

Copywrite 2012-2016 Arista Networks

3 CLI & BASH

In this activity you will:

TASK 1: Get Familiar with the running config.

Arista Networks EOS shell

Copywrite 2012-2016 Arista Networks

[admin@Student-05 ~]$ ifconfig -a

et1 Link encap:Ethernet HWaddr 00:1C:73:68:D7:F7

et2 Link encap:Ethernet HWaddr 00:1C:73:68:D7:F7

et3 Link encap:Ethernet HWaddr 00:1C:73:68:D7:F7

admin@Student-05 ~]$ top

top - 00:58:47 up 11:31, 3 users, load average: 0.04, 0.05, 0.10

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

Copywrite 2012-2016 Arista Networks

[admin@Student-05 ~]$ cd /mnt/flash

[admin@Student-05 flash]$ cat boot-config

2.) What versions of EOS are currently on flash?

3.) What other config files are stored on flash?

Copywrite 2012-2016 Arista Networks

In this lab you will:

TASK 1: Change the boot-config settings.

Copywrite 2012-2016 Arista Networks

Console speed: 9600

1.) Is it necessary to save the configuration after these commands?

2.) If so, why? If not, why not?

TASK 2: Enter Aboot and get familiar with the interface.

St05@ALAB-Linux:~$ console student-05

The system is going down for reboot NOW!

Copywrite 2012-2016 Arista Networks

Press Control-C now to enter Aboot shell

Commonly-used Aboot commands

ls Prints a list of the files in the current working directory

Run 'command -h' for brief help on a specific command.

Copywrite 2012-2016 Arista Networks

Aboot# swiinfo EOS-4.12.1.swi

Aboot# more startup-config

Copywrite 2012-2016 Arista Networks

Aboot# cat boot-config

TASK 3: Update the boot-config file to an invalid Aboot password.

TASK 4: Attempt to re-enter Aboot.

Press Control-C now to enter Aboot shell

Copywrite 2012-2016 Arista Networks

TASK 4: Perform a full recovery on the switch.

Type "fullrecover" and press Enter to revert /mnt/flash to factory