Cisco CCIE EI Lab User's Guide

Our CCIE Enterprise Infrastructure Lab is based on the Lab Topology

recommended by ine.com (Inter Network Expert).
To implement this Lab we use a Dell R620 or Dell R630 Server with a
minimum RAM size of 128GB RAM and a SSD Drive of at least 1TB
The main Operating System in the Server is VMware ESXi, which is a
Hypervisor Software that allows the deployment of multiple Virtual
Machines (VM’s)

1. Virtual Lab Topology

INE’s Lab Topology at least 20 Virtual Routers that can be implemented
either as independent VM’s (directly under ESXi) or through a Network
Emulator Software like GNS3, CML-2 or EVE-NG.
The Topology also needs 4 x Physical Layer-3 Switches that must be
connected to the Server. The following Diagram shows this Topology:

Cisco EI Lab User's Guide Property of Ciscoland.net

The requirements to implement a CCIE EI Lab are of course provided by
Cisco and they can be found at this URL:
https://learningnetwork.cisco.com/s/article/ccie-enterprise-infrastructure-
equipment-and-software-list
These are the requirements listed there:

Main Virtual Machines

- Cisco CSR1000v with IOS XE SD-WAN ver 16.12
- Cisco IOSv with IOS Software ver 15.8
- Cisco IOSv-L2 with IOS Software ver 15.2
- Cisco SD-WAN (vManage, vBond, vSmart, vEdge) Software ver 18.4

Supporting Virtual Machines

- Cisco ISE (Identity Services Engine) ver 2.6
- Ubuntu (Server or Desktop) ver 18.04.5
- Windows Virtual Machine
Physical Equipment
- Cisco Catalyst 9300 Series Switches Release 16.12

Our Lab includes all of the Virtual Machines in this list, but of course it
doesn’t include the Physical Equipment (Switches).
However, the Physical Switches are not needed for all Lab Exercises. They
are mainly needed for the SD-Access-related Labs that include SD-Access
Programmability and SD-Access FiaB (Fabric in a Box)
But the less complex Switching-related Lab Exercises can simply use
Virtual Devices like the Cisco IOSv-L2. We’ll expand this discussion in the
next section: 2. Connection between Physical Switches & Server
Cisco’s Website also includes the following requirement:
- Cisco DNA Center Release 1.3.1
But this requirement can’t be met with a Home Lab, because Cisco hasn’t
still released an Official Virtual version of the DNA Center (DNAC)
However, Cisco does offer a way to get at least some “exposure” to the
DNAC User Interface.
That will be explained in Appendix B (Cisco DNA Center Sandbox Site)
In addition to the VM’s mentioned above, our Lab includes an EVE-NG
VM, which is perhaps the most important component of this Lab:
EVE-NG Server (Community Edition) ver 2.0.3-112

Cisco EI Lab User's Guide Property of Ciscoland.net

EVE-NG Community Edition is a Free Product. Although there is a paid
version (called EVE-NG Pro), the Free Community Edition is enough for
CCIE Enterprise Infrastructure Labs.
This VM will allow you to do most Lab Exercises, from the most basic ones
to the more complex, SD-WAN related Labs.
In fact the EVE-NG VM includes all the Network Nodes needed to emulate
a Viptela SD-WAN Network that gives this Lab full SD-WAN functionality
INE actually doesn’t use EVE-NG to do their EI Lab Exercises. Instead,
they use CML-2 (formally VIRL), that is a Licensed product from Cisco.
For that reason our Lab also includes a CML-2 VM:
CML-2 Server (Cisco Modeling Labs) ver 2.1.2
We install this VM, but NO License is included. However, if you decide to
go the CML-2 route, you’ll simply have to buy and install the License.
However, you won’t really need to buy a CML-2 License because EVE-NG
is 100% equivalent to CML-2 and some Users actually consider EVE-NG
better than CML-2. And it doesn’t hurt the fact that it is Free.
EVE-NG actually uses the same IOS Images than CML-2 (.qcow2 Files).
In fact, our EVE-NG VM is already pre-loaded with the following Virtual
Devices:

Routers
- Cisco IOSv Router ver 15.9.3
- Cisco XRv Router ver 6.3.1
- Cisco XRv-9K Router ver 7.2.1
- Cisco CSR1000v SD-WAN Router w/ IOS XE ver Amsterdam 17.3.2

Other Devices
- Cisco IOSv-L2 Layer-2 Switch ver 15.2
- Cisco NX-OSv9K Nexus Switch ver 9.2.4
- Cisco ASAv Firewall ver 9.14.1

EVE-NG is also an excellent tool (perhaps the best tool) to emulate a

Viptela SD-WAN Network. Our EVE-NG VM provides full SD-WAN
functionality. To do that, it includes the following types of Nodes:

SD-WAN Controllers
- vBond versions 18.4.4, 19.2.31 and 20.3.2
- vSmart versions 18.4.4, 19.2.31 and 20.3.2
- vManage versions 18.4.4, 19.2.31 and 20.3.2

Cisco EI Lab User's Guide Property of Ciscoland.net

WAN Edge Nodes
- vEdge versions 18.4.4, 19.2.31 and 20.3.2
- CSR1000v with IOS XE version UCM-K9 16.12.5
- CSR1000v with IOS XE version Amsterdam 17.3.2

As we may recall, the list of requirements for CCIE EI Lab includes the
following:
- Cisco CSR1000v with IOS XE SD-WAN ver 16.12
Using these Routers as WAN Edge Nodes is perhaps the main purpose of
this requirement. However, they can also be used for other purposes.
In fact, our Lab includes CSR1000v SD-WAN capable Routers (IOS XE
ver 17.3.2) not only as part of the EVE-NG VM, but also as an alternative
to CML-2 and EVE-NG.
We deploy 20 x CSR1000v Routers as independent/native VM’s directly on
top of ESXi. Being built directly on ESXi allows them run much faster
than when they run on a Network Simulator like CML-2 and EVE-NG.
When INE started to offer Labs based on Virtual devices, they were initially
based on CSR1000v Routers. But when Cisco VIRL was released, they
migrated from native CSR1000v Routers to VIRL and now to CML-2.
But again, using natively deployed CSR1000v Routers is still a valid
option, although they so present some challenges.
For instance, while the Virtual Routers in EVE-NG and CML-2 have 4 or
more Gigabit Ethernet interfaces, CSR1000v Routers have only 3. This
challenge can be overcome by creating Sub-interfaces, for which of course
there is no limit on the number of them.
However, this would force us to modify the Lab’s Initial Configuration files,
since the interface names will be very different. But it could be done.
The main advantage of taking this approach is first of all speed and the fact
that there is no Licensing requirement, at least not for a Lab environment
where the Routers won’t be using a lot of Bandwidth.
We’ll discuss this issue a little bit more in Appendix A.
All of the VM’s are interconnected with an internal Virtual Switch, which
also allows communication to the external world, because it’s “mapped” to
one of the 4 Gigabit Ports in the Dell Server.
As we’ll see in the next section, this relationship between the Virtual Switch
and one of the physical Gigabit Ports is what allows the interconnection
between the Server and the Physical Switches that are needed for this Lab.

Cisco EI Lab User's Guide Property of Ciscoland.net

2. Connection between Physical Switches & Server
As mentioned in the previous section, the Lab Topology needs 4 x Physical
Layer-3 Switches that must be connected to the Server, so that they
become part of the Lab’s Network. In this section we explain how to make
this connection.
Let’s start by explaining some key terms. The Dell Server has 4 Gigabit
Ports which we’ll call Gb0, Gb1, Gb2, Gb3
In ESXi language these Ports are called vmnic0, vmnic1, vmnic2 & vmnic3
But the bottom line is that vmnic0 refers to the Server's First physical
Gigabit Port, vmnic2 refers to the Second Gigabit Port and so on.
The following image shows a rear view of an R620/R630 Server. If you
look closer you’ll see that the Gigabit Ports actually are labeled: Gb1, Gb2,
Gb3 & Gb4. But to avoid any confusion we’ll stick to the previous names.
That is, Gb0, Gb1, Gb2, Gb3

One of these Ports must be designated the Management Port. The default
Management Port is Gb0. That could be changed, but we keep the default.
The Management Port is of course connected to the Management Network
which we configure with IP Subnet 192.168.15.0/24 (255.255.255.0)
An ESXi Sever always includes a Virtual Switch called vSwitch0, which is
a Virtual Device (everything in ESXi is of course Virtual) that by default
has 3 main components (or Ports if we use VMware Language) which are
in a way equivalent to the 3 first Layers in the OSI model:
- vSwitch (Physical Layer for a Virtual Switch with 120 Virtual Ports)
- VM Network (Data-Link Layer Controller)
- Management Network (Layer-3 or IP Network Controller)

The following image shows these 3 components:

Cisco EI Lab User's Guide Property of Ciscoland.net

As you may see, the VM Network and Management Network Ports have a
VLAN-ID associated to them. This VLAN-ID could be either a specific
VLAN number or it could be 4095, which means that it allows all VLAN’s.
Therefore, if we assign VLAN 4095 to these Ports, effectively we would be
turning them into Trunk Ports!
We could add more Ports to Virtual Switch vSwitch0 and these extra Ports
would also have a VLAN-ID (0 - 4095). That is, these extra Ports would be
either Trunk Ports (VLAN-ID 4095) or would allow a specific VLAN.
As we can in the previous image, in addition to Ports, a Virtual Switch also
has Network Adapters assigned to it. And by Network Adapters we
basically refer to the Physical Gigabit Ports in the Dell Server.
A Virtual Switch can have either zero, one or more Physical Gigabit Ports
assigned to it.
Assigning zero Gigabit Ports means that the Virtual Switch would have no
communication with the External World. It would be just an Internal Switch

Cisco EI Lab User's Guide Property of Ciscoland.net

Assigning one Gigabit Port means that the Virtual Switch will be able to
communicate with the External World through that specific Physical Port.
Assigning more than one Gigabit Port means that we are connecting the
Server to a Port-Channel.
In our case Virtual Switch vSwitch0 is assigned to vmnic0 which as we
know, refers to the Server's First physical Gigabit Port in the Server.
The following image shows this:

As mentioned before, the Management Network is setup with IP Subnet

192.168.15.0/24
Gb0 (vmnic0) is the Management Port to which we assign IP Address
192.168.15.1. This is the IP Address that, as we’ll will see in the next
section, should be used to login to the Server.
Although this IP Address could be changed, we’ll see that we based our
entire configuration on this specific IP. Therefore, if this IP is changed,
most other Lab’s settings would have to be changed as well.
Therefore, we recommend keeping this IP Address. This implies that you
will need to change the IP Subnet of the Network where you plan to
connect the Server.

Cisco EI Lab User's Guide Property of Ciscoland.net

The changes needed on the Network where this Server will be installed are
explained in this document: VMware ESXi Server Setup.PDF.
As previously mentioned, Cisco recommends the following Switching
Platform: Catalyst 9300 Series Switches Release 16.12
But the 9300 Series are still very expensive! Their price tag is in the
thousands. However, there are some less expensive alternatives that could
be effectively used for this Lab.
One of them is the 9200 Series, which have a price tag slightly lower, but
still in the thousands.
The next models to consider are the Catalyst 3850 Series or even his little
brother, the 3650, which provides basically the same functions.
The following image provides a comparison between 9300’s and 3850’s

Source:
https://www.router-switch.com/faq/cisco-catalyst-9300-switch-vs-3850-switch.html
As you may see, the 9300’s and 3850’s have similar capabilities, while
lower level Platforms lack many of the functions provided by them.
Although not shown here, the Catalyst 3650 is quite similar to the 3850.

Cisco EI Lab User's Guide Property of Ciscoland.net

The most important of these capabilities, at least of those related to the EI
Lab Exam, is SD-Access (SDA) Programmability. This capability comes
standard in the 9300 Platform, but it’s optional in the 3850/3650 Platform.
However, in order to do any SDA-related activities we would need a DNA
Center. But since there no DNAC in this Lab, there is really no reason to
use 9300 Switches and therefore using 3850/3650’s should be good enough.
But regardless of the Physical Platform used, to connect the Server to the
Physical Switches we use the 2nd Gigabit Port (Gb1)
Since the Physical Switches need to be connected to the Virtual Devices in
the Server, we need to create a new Virtual Switch that would make this
connection possible. So we have created Virtual Switch vSwitch1 for this
purpose. The following image illustrates this:

As we may see here, vSwitch1 is the “bridge” that connects the Physical
Switches with the Virtual Routers and all other VM’s.
Of course vSwitch1 has to be assigned to Gb1 (vmnic1) and that’s why Gb1
is the Port that must be used to connect the Physical Switches to the Server.

Cisco EI Lab User's Guide Property of Ciscoland.net

The following image is a screenshot from the ESXi Management Console
that shows how vmnic1; that is, Gb1, is assigned to vSwitch1:

A single link between the Server and one of the Physical Switches is enough
because vSwitch1 is configured as a Trunk, so that it allows all VLANs.
According to the previous Diagram, Switch SW1 should be connected to the
Server through its first Gigabit Port (G0/1 or whatever the Port name is).
Therefore, that Switch Port should also be configured as a Trunk.
Since SW1 is connected to all other Physical Switches (also through Trunks
that allow all VLAN’s) then all 4 Physical Switches will effectively have
full communication with all Virtual Devices.
We actually create 3 Virtual Switches in the Server, vSwitch1, vSwitch2
and vSwitch3.
Virtual Switch vSwitch2 is assigned to vmnic2 (Gb2) and Virtual Switch
vSwitch3 is assigned to vmnic3 (Gb3).
While this is done just as a backup plan for vSwitch1, they could also be
used to connect devices to the Lab. However, in this Topology these Virtual
Switches are not being unused.

Cisco EI Lab User's Guide Property of Ciscoland.net

3. ESXi Server Configuration and Management
In this section is about the ESXi Server configuration steps needed to make
it work in this Lab and to allow its Management either locally or remotely.
Let’s start with local Management, for which the Server needs a Monitor
(Dumb Terminal) that must be connected to the Server’s VGA Port.
Most Servers actually has two VGA Ports; one on the back and one on the
front. But there are some Servers that use the entire front section to host
Hard Drives. In other words, they have no Ports on the front; no VGA Ports,
no USB Port, nothing; just Drive Slots.
If that’s the case, you’ll have to use the VGA Port on the back where you’ll
also find USB Ports to connect the Keyboard.
The Server’s Monitor is only used for some very basic administration tasks
that are seldom needed (mostly needed during the initial installation).
However, you do need to login through this Monitor at least to shut down
the Server. And to login you’ll need to use these Access Credentials:
Login Name: root
Password: esxiadmin

You may later configure the Integrated Dell Remote Access Controller,
(simply known as the iDRAC Controller) to allow Remote Management.
That way you can shutdown the Server without being right beside.
By the way, there is a short but very good YouTube Video that explains
how to setup the iDRAC Controller:
Dell PowerEdge R620 iDRAC Setup
https://www.youtube.com/watch?v=n1O9DrAoCAk

And the following URL provides additional iDRAC Tutorials:

iDRAC Tutorials`
https://techexpert.tips/dell-idrac/reboot-idrac-server/

Cisco EI Lab User's Guide Property of Ciscoland.net

But iDRAC and Remote Server Access is not the main topic of this section.
Here we’ll be focusing on Local Server Management; that is, on the Server
login options.
We already explained how to login through the Server’s Monitor. But this
only allows you to manage mainly Hardware-related issues; not the ESXi
Software itself.
To actually manage the ESXi Server Software we need to use a separate
Computer, which we call Client PC.
On the Client PC you can use either the vSphere Client for Windows or a
Web Browser.
The differences, advantages and disadvantages of each alternative are
discussed in this Document: VMware ESXi Server Setup.PDF (included
in your Lab Disk or Flash Drive). So please refer to this PDF for details.
If using the Web Interface you’ll need to enter the Server’s IP Address
(192.168.15.1) on the Web Browser, hit Enter and you’ll see the following:

The Access Credentials to login through this Interface (or through the
vSphere Client) are the same Credentials used on the Server’s Monitor:
User Name: root
Password: esxiadmin

Cisco EI Lab User's Guide Property of Ciscoland.net

If using the vSphere Client, you’ll see the following:

The next step after we login should be to power up the VM’s that we want
to use. These are the Lab’s VM’s as seen from the vSphere Client:

Cisco EI Lab User's Guide Property of Ciscoland.net

The next image shows all the VM’s as seen through the Web Interface:

So for instance, if you plan to use the EVE-NG VM, of course you’ll need
to power up only that VM.
However, EVE-NG needs the Default Gateway VM, that in this Lab takes
the name CSR-DG (a CSR1000v Router). Therefore, the CSR-DG VM
would also have to be powered up.
This will be explained in Appendix E (Sample SD-WAN Network),

Cisco EI Lab User's Guide Property of Ciscoland.net

But for now we can say that the Default Gateway is needed mainly by the
Sample SD-WAN Network that is already built-in the EVE-NG VM.
However, it can be used for many other purposes, since it provides an easy
way to connect EVE-NG Devices to the Internet.
Appendix A covers in more detail the purpose and functions of each of
these VM. So please check out that section.
Another important topic that must be mentioned with regards to the ESXi
Server is the configuration of the Virtual Switches.
As explained before, the Server is configured with 4 Virtual Switches, the
Standard one (vSwitch0) and 3 Custom Virtual Switches (vSwitch1,
vSwitch2, vSwitch3)
All of them, but specially vSwitch0 and vSwitch1, need a couple of special
settings for this Lab to operate: Allowed VLAN's and Promiscuous Mode.
Multiple VLAN’s are used in most Lab Exercises and Virtual Switches
should support that by allowing the transmission of Frames with multiple
VLAN’s ID’s. The next image shows how this is done.

Cisco EI Lab User's Guide Property of Ciscoland.net

The previous image shows the default settings of vSwitch0. As you may see
its DLC Controller (VM Network) is set to VLAN 0 (none) by default.
Therefore, we need to change that to allow all VLAN’s and this is done by
setting the VLAN ID field to 4095. This would have the effect of making
Gb0 (the NIC assigned to vSwitch0) a Trunk Port. Please see next image:

We also need to configure all Virtual Switches, and therefore the NIC’s
assigned to them, in Promiscuous Mode (PM).
As you may know, a Network Interface in Promiscuous Mode allows all
Frames through it. This lets the Interface to accept Frames intended for
other Network Devices.
And that’s exactly what is needed in our case, because the Server will be
receiving Frames intended for multiple Virtual Machines; not for itself.
If this is not done, the Server would simply discard those Frames and they
will never reach the actual destination.
To configure a Virtual Switch in Promiscuous Mode we first need to go to
its vSwitch component (or sudo Physical Layer) which by default is set to
Reject PM, click on the Security Tab, and change PM to Accept. The next
image shows that:

Cisco EI Lab User's Guide Property of Ciscoland.net

In addition to this, we also need to move back to the DLC Controller (or VM
Network), again click on the Security Tab. As you may see in the next
image, all options are disabled by default:

Cisco EI Lab User's Guide Property of Ciscoland.net

So we need to click on the proper Check Box to accept Promiscuous Mode:

Now the Virtual Switches are finally properly configured for this Lab and
we are almost done with this section.
There are still a couple of settings that the Server needs like setting the
Security Profile and the creation of Virtual Console Ports to allow
Reverse Telnet Access to some Virtual Appliances. But that will be
explained in some of the Appendices.

Cisco EI Lab User's Guide Property of Ciscoland.net

Appendix A: Lab Components: Purpose and Functions
Our CCIE EI Lab includes the following Virtual Machines:

1. EVE-NG Server (Comm. Edition) ver 2.0.3-112

2. Cisco ISE Server (Identity Services Engine) ver 2.6
3. Ubuntu Server and Ubuntu Desktop ver 20.04.2
4. CML-2 Server (Cisco Modeling Labs) ver 2.1.2
5. Windows 2012 Server (180-day Trial version)
6. CSR1000v Virtual Routers (21 Routers total)
Here we’ll try to explain their purpose and also how to use them effectively
in this Lab.

1. EVE-NG Server (Community Edition)

EVE-NG stands for Emulated Virtual Environment-Next Generation. This
VM is perhaps the most important component of this Lab.
There are 2 versions of EVE-NG; the Free version called Community
Edition, and the Paid version called EVE-NG Pro.
We use the Community Edition ver 2.0.3-112 which is enough for a CCIE
Enterprise Infrastructure Lab.
The EVE-NG VM is configured with 4 Network Interfaces. The next
image shows that:

As you may see, Network Adapter 1 is connected to the VM Network.

Therefore, this NIC will have an IP in IP Subnet 192.168.15.0/24
Although this VM could get an IP Address via DHCP, we assigned a Fixed
IP Address to it: 192.168.15.5

Cisco EI Lab User's Guide Property of Ciscoland.net

Once the VM is powered up we can use any Web Browser to access the
EVE Work Area using the following URL and the Access Credentials:
URL: http://192.168.15.5/#/login
Username: admin
Password: eve

Please notice that this is not a Secure URL. It’s a standard HTTP that
starts with http://. It won’t work if you try the Secure version (https://)
We can also access EVE-NG’s Console either through the ESXi Console
Tab or via SSH. These are the Credentials to login to EVE’s Console :
Username: root
Password: cisco
Although advanced users can use the Console to do some very complex
settings, most users only use it to power down the VM, which is done with
this Command: sudo shutdown now
Obviously we won’t explain how to use EVE-NG. However, we do need to
ask you to check out Appendix F: EVE-NG Windows Client Side Software.
This short Appendix talks about a little piece of Software that must be
installed in the Client PC to help you manage the different Virtual Devices
in an EVE-NG Topology.

Cisco EI Lab User's Guide Property of Ciscoland.net

And if you are totally new to EVE-NG and need some jump start, then
YouTube will be your best friend! There are dozens of good EVE-NG
tutorials in YouTube, so you should look there for help.
In case you wonder about the differences between the Pro version and the
Comm. Edition, perhaps the most important one is Node Limit per Lab:
- Community Ed. version: 63
- Pro (Licensed) version: 1024
Obviously the Pro version would be needed to emulate very large Networks.
A complete comparison between these 2 versions can be seen at this URL:
https://www.eve-ng.net/index.php/features-compare/
But Network size is not the only difference between versions. For a more
complete comparison between versions, please check out this Video:
Run Docker Containers in EVE-NG - Why You NEED EVE-NG Pro
https://www.youtube.com/watch?v=n_tDPWPlhJw
By the way, although the topic of Docker Containers is well beyond the
scope of this Document and perhaps beyond the scope of the CCIE EI Lab
itself, is not completely out of the Network Engineering world.
Docker Containers do have a place in the job of a Cisco Network Engineer
these days because many Cisco Products use this Technology. In fact,
Docker Containers are very much related to an important section of the
CCIE EI Lab Exam Blueprint:
Chapter 5: Infrastructure Automation and Programmability (15%)
In addition, the Cisco IOS-XE, IOS-XR, and NX-OS Software relies on
this technology. Cisco Press even published an entire Book on this topic:
Containers in Cisco IOS-XE, IOS-XR, and NX-OS
ciscopress.com/store/containers-in-cisco-ios-xe-ios-xr-and-nx-os-orchestration-9780135783016
The Cisco DNA Center (DNAC), which we’ll cover in Appendix B, also
uses the Containers Technology as a way to expand its capabilities by letting
DNAC Administrators to import Docker Images, which in most cases are
Custom Applications typically written in Python.
But let’s stay on track and keep talking about the EVE-NG VM that is
included in this Lab. This EVE-NG VM includes a built-in sample SD-
WAN Network that is fully configured and ready o use. A complete
description of this sample SD-WAN Network is provided in Appendix E.
So we’ll refer you to that section for further details.
We setup this sample Network to provide you with a Guide that will help
you to create your own SD-WAN Network and to test the functionality of
the SD-WAN components (vManage, vSmart, vBond and vEdges)

Cisco EI Lab User's Guide Property of Ciscoland.net

2. Cisco ISE (Identity Services Engine)
An ISE Server is a security policy management platform that provides
secure access to network resources.
Since its main purpose is to provide security management, it may seem that
this Technology would be more appropriate for a CCIE Security track, rather
than for the CCIE EI track.
But although ISE is in fact a very important topic in the CCIE Security Lab
Exam, the CCIE EI Lab also includes it because ISE also plays a role in
SDA Technology (Software Defined Access), which is a very important part
of the CCIE EI Lab Exam.
The last part of this section deals with ISE’s role within SDA. But for now
let’s concentrate on the characteristics of the ISE VM included in this Lab.
The ISE VM is configured with 6 Network Interfaces. The following image
shows that:

As you may see, Network Adapter 1 is connected to the VM Network.

Therefore, this NIC will have an IP in IP Subnet 192.168.15.0/24

Cisco EI Lab User's Guide Property of Ciscoland.net

Although this VM could get an IP Address via DHCP, we assigned a Fixed
IP Address to it: 192.168.15.20
Once the VM is powered up we can use any Web Browser to access ISE’s
GUI Interface. These are the Access Credentials for it:
URL: https://192.168.15.20/admin/
Username: admin
Password: default1A
The previous image also shows Serial Port 1, which takes the following
value: telnet://192.168.15.1:2101
This Serial Port is actually a Virtual Console Port that allows Out-of-Band
Mgmt. of this VM.
To be more specific, this Virtual Port allows a Reverse-Telnet connection to
the VM, which is how Out-of-Band Mgmt. is usually done.
To do Reverse-Telnet we use the ESXi Server’s IP Address (192.168.15.1)
and TPC Port 2101. Together they form URL: telnet://192.168.15.1:2101
We simply have to configure our Telnet Software (whatever that is) with this
URL and a Reverse Telnet connection will be established. This connection
method doesn’t need any Access Credentials because it’s equivalent to using
a Physical Consol Port.
We explain the Reverse-Telnet connection method in detail in Appendix C:
Security Profile Configuration. So please check it out.
In addition to the Web Interface and to the Reverse-Telnet access methods,
ISE can also be accessed through the ESXi Console Tab.
This is unlike the CSR1000v Routers, which allow only one access method
at a time; either access through a Reverse-Telnet connection or through the
ESXi Consol Tab, but not both at the same time.
Finally, we can also access the ISE VM via SSH. The Credentials to access
ISE via an SSH connection or through the ESXi Consol Tab, are the same as
the GUI’s Credentials:
Username: admin
Password: default1A
An ISE VM always needs to have access to a DNS Server and to an NTP
Server. So when ISE is configured, we must setup the proper FQDN (Fully
Qualified Domain Name) of these Services or their IP Addresses.
For DNS we use VM Network’s DNS Server. That is, 192.168.15.254
For NTP we use Google's NTP Servers. This is a short list of these Servers:

Cisco EI Lab User's Guide Property of Ciscoland.net

- time1.google.com ==> IP Address 216.239.35.0
- time2.google.com ==> IP Address 216.239.35.4
- time3.google.com ==> IP Address 216.239.35.8
Finally, please keep in mind that the ISE VM has a Demo License that lasts
for only 90 days.
After these 90 Days the VM will stop working. However, you can simply
remove the VM and re-install it. The Flash Drive includes an .OVA file for
the re-installation.
The full Configuration Procedure for this VM is provided in this Document:
- Virtual ISE Configuration Procedure.TXT
So please check it out for more details.

Cisco EI Lab User's Guide Property of Ciscoland.net

Now let’s go back to a very important topic that we started to discuss at the
beginning of this Document; that is, ISE’s role within SDA (SD Access).
The previous image illustrates this.
As this image shows, ISE plays a small but very important role with SDA,
which is one of the most important sections of the CCIE EI Lab Exam
Blueprint:
2. Software Defined Infrastructure (25%)
2.1.b Cisco SD Access Deployment
2.1.b.i Cisco DNA Center Device Discovery and Device Management
2.1.c Segmentation
2.1.ci Macro-level segmentation using VNs (Virtual Networks)
2.1.cii Micro-level segmentation using SGTs (Cisco ISE)
We can see that ISE works directly with the DNA Center (which as we said,
is covered in more detail in Appendix B) and it plays an important role in
Segmentation (especially in micro- Segmentation).
By the way, the following Link provides a very good reference to the topic
of SD-Access Segmentation:
SD-Access Segmentation Design Guide
https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Campus/CVD-
Software-Defined-Access-Segmentation-Design-Guide-2018MAY.pdf
Now, let’s go back a little bit to SDA. Obviously, SDA is such an extensive
Technology, that we can’t even pretend to cover it here. However, just for
the sake of completeness, we would like to include some key facts.
SDA is a large umbrella Technology that includes DNA, SD-WAN and
others. Although it is very difficult to put everything into context, we can
say that these are the key foundational components of the SDA:
- Controller-Based Architecture (in other words, DNAC-based)
- Network Fabric (Collection of Interconnected Network Nodes)
- Programmable Infrastructure (Eqp. that allows Full Lifecycle Mgmt.)
The most important of these components is by far the Cisco DNA Center
(DNAC). It’s so central that even Cisco is sometimes a bit confused about it
While most Cisco documents describe the DNAC as part of the SD-Access
Technology, other documents describe SD-Access just as a solution within
Cisco DNA.
But as we saw before, the CCIE EI Lab Exam Blueprint actually settles this
discussion since it includes the DNA Center within the SDA section. So it
should be clear that DNAC is part of SDA and not the other way around.

Cisco EI Lab User's Guide Property of Ciscoland.net

As mentioned before, DNAC works directly with ISE. Moreover, ISE and
DNAC must be fully integrated for them operate correctly. The integration
process of these SDA components can be quite complex.
The following Links provide a very good description of this process:

DNAC and ISE Integration

https://curiouswaves.blog/2018/09/05/dnac-and-ise-integration/
Software Defined Access with Cisco ISE and DNA Center
ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/5eU6DfQV/LTRSEC-1571-LG.pdf
Cisco DNA Center & ISE Mgmt. Infrastructure Deployment Guide
cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-dnac-ise-deploy-guide.html
Troubleshooting DNA SD-Access from API and Maglev
https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2018/pdf/BRKARC-2016.pdf
These documents should give you a good idea about the multiple steps that
must be taken to integrate these Platforms.
So far we have only given you some basic information about the purpose of
an ISE VM in a CCIE EI Lab.
But since there is no DNA Center in this Lab, the ISE VM can’ really be
used for the purpose intended in the CCIE EI Lab Exam Blueprint.
However, the ISE VM could still be used for other purposes such as Device
Access Control.
Device Administration of a Network Device is generally achieved with
TACACS+ Protocol.
But if the Network Device doesn't support TACACS+ or if ISE doesn't
have a Device Administration License, we could use an RADIUS Server
(an External Device).
The CCIE EI Lab Exam Blueprint still includes an Infrastructure Security &
Services section and AAA functions are still part of it. So although it is not
a major part, you could still take advantage of the ISE VM by using it as a
Device Access Control Server.
For more information about this topic, please check out the following URLs:

Configure External RADIUS Servers on ISE

cisco.com/c/en/us/support/docs/security/identity-services-engine/213239-
configure-external-radius-servers-on-ise.html

Use RADIUS for Device Administration with ISE

cisco.com/c/en/us/support/docs/security/identity-services-engine/215525-
use-radius-for-device-administration-wit.html

Cisco EI Lab User's Guide Property of Ciscoland.net

Switch Configuration Required to Support Cisco ISE Functions
cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_sw_cnfg.html
The Ubuntu Server could be used to implement a RADIUS Server. So now
let’s move one to the Ubuntu section.

3. Ubuntu Server and Ubuntu Desktop ver 20.04.2

Our CCIE Enterprise Infrastructure Lab includes 2 Ubuntu VM's:
- Ubuntu Desktop 20.04.2 LTS
- Ubuntu Server 20.04.2 LTS
The Ubuntu version can be verified using this command:
- lsb_release -a
Ubuntu Desktop comes by default with a Graphical User Interface (GUI),
but Ubuntu Server doesn’t. Ubuntu Server only has a CLI Interface by
default. However, Ubuntu Server does provide the option to install a GUI
Interface. So we went ahead and installed a Desktop-style GUI on it.
When you power up the Ubuntu Server you will see a screen that looks like
an Ubuntu Desktop VM. However, please keep in mind that they are two
different types of Ubuntu Machines, each with different capabilities
Both are configured with 2 Ethernet Interfaces.
In each VM, one of the Ethernet Interfaces is connected to vSwitch0 (that
is, to the VM Network), so that they can get an IP Address via DHCP.
Remote Access to an Ubuntu Server via SSH is disabled by default.
However, we enabled Remote Access via SSH.
Without this, the only way to access the Ubuntu Server would be through the
ESXi Console Tab. But using the ESXi Console can be very frustrating,
even if you use the GUI.
The main problem with ESXi Console is the fact that you can’t copy &
paste! Therefore, it is much better to access the Server externally (that is,
external to the ESXi Console), so that we don’t face these limitations.
And that’s exactly what an SSH session provides; a CLI Window totally
independent from the ESXi environment.

Ubuntu Desktop Access Credentials:

- Username: Ciscoland
- Password: c1sco123

Cisco EI Lab User's Guide Property of Ciscoland.net

Please notice that although the Username "Ciscoland" has been created on
the Ubuntu Desktop, to login you’ll only need the Password.

Ubuntu Server Access Credentials (same as Ubuntu Desktop):

- Username: Ciscoland
- Password: c1sco123
Same deal with the Ubuntu Server. That is, to login you’ll only need the
Password.
However, if you want to access it via SSH, of course you will need to use a
different Username and Password combination:
- Username: ubuntu
- Password: c1sco123
By the way, to login to the Server via SSH, first you need to get the DHCP
IP Address. You need to open a Terminal Windows and then enter this
Command:
- ifconfig -a
The Username ubuntu has been given root Privileges. So you can run any
privileged command under this Username, although of course you’ll have to
run them as sudo.
However, Username root has also been enabled on the Ubuntu Server!
By default the root User is disabled in Ubuntu. But it can be enabled using
this command:
- sudo passwd root
The Password for the root Username is the same as the one used so far:
- Username: root
- Password: c1sco123

4. CML-2 Server (Cisco Modeling Labs)

As it was mentioned in previous sections, INE actually doesn’t use EVE-
NG to do their EI Lab Exercises.
Instead, they use CML-2 (formally VIRL), that is a Licensed product from
Cisco. For that reason our Lab also includes a CML-2 VM:
CML-2 Server (Cisco Modeling Labs) ver 2.1.2
We install this VM, but NO License is included. However, if you decide to
go the CML-2 route, you’ll simply have to buy and install the License.

Cisco EI Lab User's Guide Property of Ciscoland.net

Since it’s a Licensed product, CML-2 comes already loaded with multiple
IOS Images and therefore it can be used right after it is installed.
That’s not the case with EVE-NG, which doesn’t include any IOS Images by
default. Instead, all IOS Images have to be loaded into EVE-NG to enable
its use. However, our EVE-NG VM is already loaded with multiple Images.
Cisco offers 2 versions of CML: Personal and Personal Plus versions:
www.cisco.com/c/en/us/products/cloud-systems-management/modeling-labs/index.html
The difference between versions is the Max. Number of Nodes allowed.
- Personal version: 20 Nodes
- Personal Plus version: 40 Nodes
Like all Cisco Products, Cisco doesn’t sell the Software. Instead, they only
sell a 1-Year License or as they call it, 1-Year Subscription.
The price for the Personal version is $199 for a 1-Year subscription.
The price for the Personal Plus version is $349 for a 1-Year subscription.
Our CCIE EI Lab includes a Personal CML-2 VM, but again, no License
has been activated on it. But a License can be activated at any time.
The CML-2 VM is configured with a single Network Interface. The next
image shows that:

Cisco EI Lab User's Guide Property of Ciscoland.net

As you may see, Network Adapter 1 is connected to the VM Network.
Therefore, this NIC will have an IP in IP Subnet 192.168.15.0/24
Although this VM could get an IP Address via DHCP, we assigned a Fixed
IP Address to it: 192.168.15.4
Once the VM is powered up we can use any Web Browser to access CML’s
GUI Interface. These are the Access Credentials for the Web Interface are:
URL: https://192.168.15.4
Username: admin
Password: c1sco123
We can also access CML’s Console either through the ESXi Console Tab
or via SSH. We can use the same GUI’s Credentials to access the Console:
Username: admin
Password: default1A
You can also access CML’s ESXi Console Tab using these Credentials:
Username: sysadmin
Password: c1sco123
However, unlike the other VM’s that we have covered so far, CML doesn’t
allow SSH access to it.
You can use the ESXi Console Tab to run some Linux-like commands, but
this Console doesn’t have root-level access, so it is very limited.
Perhaps the main purpose of CML’s Console is just to power down the VM,
which is done with the typical shutdown command (in sudo mode):
- sudo shutdown now
CML can only be shut down from the Console (not from the Web Interface.
Since the CML Console has very limited functionality and since we don’t
have access to it via SSH, it would appear as if CML is simply not open to
any Customization, System Upgrades or something like that.
However, CML does offer a way to do some Administration Tasks like the
one mentioned above. It does so through a special GUI Interface that can
be reached using this URL:
https://192.168.15.4:9090/
CML is based on the CentOS version of Linux and this GUI basically gives
you access to the CentOS Linux Cockpit, that is used for Advanced Admin
Tasks. The Access Credentials for this GUI are the same as the Console Tab:
Username: sysadmin
Password: c1sco123

Cisco EI Lab User's Guide Property of Ciscoland.net

The following image shows a screen shot from this GUI:

5. Windows 2012 Server (180-day Trial version)

Our CCIE EI Lab also includes a Windows 2012 Server. The main purpose
of this VM is to run Windows-based Applications like Wireshark Network
Packet Analyzer or any other Windows App.
As you know, Wireshark is used to capture, decode and analyze the Frames
& Packets in the Network. Using a tool like this is extremely important for
any Network Engineering Project.
The Access Credentials for this VM are the same as the Console Tab:
CISCOLAND\Administrator
Password: W1n@dm1n
Like in the case of Ubuntu, you’ll only need the Password to login. This is
only a Temporary Password that will expire after first login.

Cisco EI Lab User's Guide Property of Ciscoland.net

So please be prepared to enter a new Password when you login for the first
time. The Windows-2012 VM is configured with 3 Network Interfaces.
The following image shows that:

As you may see, Network Adapter 1 is connected to the VM Network.

Therefore, this NIC will have an IP in IP Subnet 192.168.15.0/24, which is
obtained via DHCP.
Network Adapter 2 is connected to the vSwitch1. Therefore, this NIC
could be used to capture Frames that travel through this Virtual Switch.
Network Adapter 3 is connected to the vSwitch2. Since vSwitch2 is not
used in this Lab, this NIC is being basically unused.
This Windows 2012 Server comes with a 180-day Trial version. When the
Trial Period is over, you can simply remove this VM and re-install it.
For that purpose we have already uploaded the proper ISO file, so that you
can easily redeploy this VM.

Cisco EI Lab User's Guide Property of Ciscoland.net

Appendix B: Cisco DNA Center Sandbox Site
Cisco DNA stands for Digital Network Architecture. And the combined
term DNA-Center is usually referred to as DNAC.
Although it would be almost impossible to describe DNAC in very words, a
good try would be saying that DNAC is a Management and Automation
Technology.
Of course is much more than that. So here we won’t try to describe/define
this complex Technology. Instead we would refer you to this URL for a
good definition and description of it:
Cisco DNA Center FAQ
https://www.cisco.com/c/en/us/products/collateral/cloud-systems-
management/dna-center/nb-06-dna-center-faq-cte-en.html
The focus of this section is to explain why this Lab doesn’t include a DNAC
VM, even though is part of the CCIE EI Lab requirements.
There are several reasons we are unable to include it. The first one is that
Cisco hasn’t still released an Official Virtual version of the DNA Center
(DNAC) and hasn’t even said if they ever will.
Another reason is that the DNAC Software demands a lot of processing
power and therefore we would need an extremely powerful Server to run
this Software if a Virtual version was ever released.
Let’s discuss a little bit about the alternatives offered by Cisco for their
DNA Center Technology.
Cisco only provides a Physical Appliance for their DNA Center. That is,
they sell the Hardware (very powerful Servers by the way) with the DNAC
Software already installed in it. They actually offer 3 versions of it:

DN2-HW-APL Cisco DNA Center (GEN 2) 44 Core Server

DN2-HW-APL-L Cisco DNA Center (GEN 2) 56 Core Server
DN2-HW-APL-XL Cisco DNA Center (GEN 2) 112 Core Server
The list price of these devices is really exorbitant!

DN2-HW-APL $91,756.40
DN2-HW-APL-L $152,619.27
DN2-HW-APL-XL $293,785.66
Although most Cisco Authorized Resellers offer significant discounts over
these very high list prices, their final prices are still extremely high for most
Organizations and of course no person preparing for the CCIE EI Lab Exam
would be able to afford this.

Cisco EI Lab User's Guide Property of Ciscoland.net

But Cisco does offer an alternative way to get at least some “exposure” to
the DNAC User Interface.
We are referring to the Cisco DNA Center Sandbox site that not only does it
show the actual User Interface, but it also lets you navigate through it and
thus explore some of its capabilities.
This is the URL for the Cisco DNA Center Sandbox site:

https://sandboxdnac.cisco.com

You can use these Access Credentials to login:

devnetuser
Cisco123!
Once you login you’ll see a Link to the DNAC’s YouTube Channel:
https://www.youtube.com/playlist?list=PLGJ69loi36wLySI1qIlbNqPsw8beIDkFP

Cisco EI Lab User's Guide Property of Ciscoland.net

This Channel has many DNAC-related Videos that should give you a very
good understand of this Software works.
You may also check out these additional Videos:

Overview of Cisco DNA Center (Kevin Wallace’s YouTube Channel)

https://www.youtube.com/watch?v=hzsmoY2xdjQ

Intro to Cisco DNA Center (Data Knox’s YouTube Channel)

https://www.youtube.com/watch?v=Jjo1_lsClHo
The following image shows part of the DNAC’s Management Dashboard:

The following URL provides some help to navigate the DNAC Dashboard:
Cisco DNA Assurance User Guide - Managing Dashboards
https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-
automation-and-management/dna-center-assurance/1-3-3-
0/b_cisco_dna_assurance_1_3_3_0_ug/b_cisco_dna_assurance_1_3_2_0_ch
apter_01110.html

Cisco EI Lab User's Guide Property of Ciscoland.net

Appendix C: Security Profile Configuration
In order to manage a Virtual Appliance like Virtual Routers or any Security
Appliance, we have two options:
- Through the Console Tab (using the vSphere Client or the Web Interface)
- Through a Reverse Telnet Session (using a Virtual Console Port)
But these options are actually mutually exclusive. That is, if we choose to
use the Console Tab, then we won’t be able to use Reverse Telnet.
As explained in other sections, the Console Tab is very limited. Its main
problem is that we can't copy & paste on the Console Tab, which makes it
virtually unusable! Therefore, we must use the Reverse Telnet method;
that is, use the Virtual Console Ports configured in the Virtual Appliance.
Reverse Telnet is a specialized application of Telnet, where the Server side
of a TCP connection sends and receives data to a Custom TCP Port, rather
than to the Standard Port 23 used in normal Telnet operation.
This is basically done to do Out-of-Band Management of Network Devices.
To do Reverse Telnet we need an IP Address and a TCP Port. In this case
we use the Server’s IP Address (192.168.15.1), which acts as the Telnet
Server, and a Port Number in this range: 2000 - 2199.
The Virtual Ports are configured with this URI: telnet://192.168.15.1:2XXX
For all CSR1000v Routers we use this Port range: 2000 to 2020.
We assign Port 2000 to the Default Gateway (CSR-DG). So its Virtual
Console Port should be setup with this URI: telnet://192.168.15.1:2000
Routers R01-R20 use Ports 2001 – 2020. Therefore, they should be setup
with URI’s: telnet://192.168.15.1:2001, telnet://192.168.15.1:2002,etc.
If for any reason you need to include some additional Routers, the extra
Routers should use Ports > 2020
We also configure a Virtual Console Port for the ISE Server. We assign
TCP Port 2101 to it. Therefore, the ISE Server should be setup with URI’s:
telnet://192.168.15.1:2101
The following Documents explain Virtual Serial Port setup process:
- How to Create a Virtual Console Port on Virtual Appliances.PDF
- How to Configure mRemoteNG - Telnet Session Software.PDF

Cisco EI Lab User's Guide Property of Ciscoland.net

As their name indicates, they explain how to create a Virtual Serial Port on
each Virtual Appliance and how to configure the mRemoteNG Software to
establish Reverse Telnet connections.
But creating Virtual Serial Ports on the Virtual Appliance is not enough to
allow the Reverse Telnet method.
As it has been explained elsewhere, in order to allow the use of Virtual
Console Ports a Server needs to have a VMware ESXi Enterprise License.
A Standard ESXi License lacks several features, including the ability to
create and use Virtual Console Ports.
However, we have already taken care of this because our Servers do have a
Permanent ESXi Enterprise License installed in them.
Yet, this is not enough either. We still need to change some Settings on the
Server. We need the Server’s Security Profile to allow traffic through
TCP Ports 23 and 1024 – 65535, which are not open to traffic by default!
The following image shows the Security Profile Settings of an already
configured Server, which is found under the Configuration Tab in the
vSphere Client's. As you may see, it’s located under the Software section
(right under the Hardware section)

We have highlighted the relevant section:

Cisco EI Lab User's Guide Property of Ciscoland.net

Once again, this is not the default configuration. To open TCP Ports 23,
1024-65535 we need to do the following:
In the vSphere Client please click on Configuration Tab  Security
Profile  then on the Firewall Properties option. You should get a pop-up
Window with like this:

We'll have to scroll down until we find the VM serial port connected over
network option, which by default will be unchecked. So please check this
option and click OK.
Now we are finally ready to do Reverse Telnet!

Cisco EI Lab User's Guide Property of Ciscoland.net

Appendix D: CSR1000v Licenses
There are 4 types of Licenses available for the CSR1000v Routers:
- Base (or IPBase) License
- Security (SEC) License
- Application Experience (APP) License
- Full Featured (AX) License
By default the CSR1000v Routers are configured in Lab Edition Mode (No
License). The Data Rate in Lab Mode is limited to 2.5Mbps
But although they are rate-limited, they are still fully functional. That is,
while in Lab Mode, they are capable of performing ALL the functions of
a Router with a Full Featured (AX) License.
All features are available, but again the Data Rate is limited to 2.5Mbps.
However, this Data Rate should still be enough to do all Lab tasks, which
typically only require reachability testing. In other words, they only need
to transmit ICMP (ping) packages, which of course don't use a lot of BW.
If you wish you could obtain a Demo License for the CSR1000v Routers
that would increase the Data Rate to 2.5 Gbps for a 60-day period. But
this is not really necessary.
Just in case we provide some instructions how to get and apply a Demo
License to the Routers. Please refer to this Document for details:
How to Obtain and Install CSR1000v License.PDF

Cisco EI Lab User's Guide Property of Ciscoland.net

Appendix E: Sample SD-WAN Network
The EVE-NG VM includes a built-in sample SD-WAN Network fully
configured and ready o use.
This sample Network is provided to you as a practical guide that hopefully
will help you build your own SD-WAN Network.
There are several ways to implement the SD-WAN Technology, but the
Cisco SD-WAN solution in particular is a Cloud-Delivered Wide Area
Network (WAN) Overlay Architecture that applies the principles of SDN
(Software-Defined Networking) into the WAN.
Cisco's Architecture is composed of four Planes: Management, Control,
Orchestration and Data. The following image illustrates this:

To implement an SD-WAN Network Cisco uses these main components:

vManage, vSmart, vBond and vEdges.
As mentioned previously, several versions of these components are pre-
loaded in the EVE-NG VM:

Cisco EI Lab User's Guide Property of Ciscoland.net

SD-WAN Controllers
- vBond versions 18.4.4, 19.2.31 and 20.3.2
- vSmart versions 18.4.4, 19.2.31 and 20.3.2
- vManage versions 18.4.4, 19.2.31 and 20.3.2

So when you start a new EVE-NG Project and try to add a new Node, you
should see the following options:

vEdges can be implemented with either the Viptela vEdge Software

(shown the Menu) or with SD-WAN-enabled CSR1000v Routers, for
which we include 2 versions:
WAN Edge Nodes
- vEdge versions 18.4.4, 19.2.31 and 20.3.2
- CSR1000v with IOS XE version UCM-K9 16.12.5
- CSR1000v with IOS XE version Amsterdam 17.3.2
The following image shows the Topology of the sample SD-WAN Network
included in the EVE-NG VM:

Cisco EI Lab User's Guide Property of Ciscoland.net

Cisco EI Lab User's Guide Property of Ciscoland.net
Lab’s Configuration Files
We provide all the Configuration Files for all the elements in this sample
Network. The following image shows the exact location in the Lab Disk (or
Flash Drive) of these files:

All Configuration Files include comments that make them almost self-
explanatory. Therefore, we are not going to explain the configuration. So
please read all the comments if you wish to understand it.
However, we do need to explain a few things about this sample Network.
Let’s start with the SD-WAN Controllers: vManage, vSmart, and vBond
As the Diagram shows, the Controllers are connected to the OOB-Switch
(Out-of-Band Switch) which in turn is connected to vSwitch0; that is, to the
Management Network.
As you know, the Management Network uses IP Subnet 192.168.15.0/24.
Therefore, the Controllers could get an IP Address via DHCP. However, we
prefer to assign Fixed IP Addresses to them:
- vManage ==> 192.168.15.51
- vBond ==> 192.168.15.52
- vSmart ==> 192.168.15.53

Cisco EI Lab User's Guide Property of Ciscoland.net

The Management Network is connected to the Internet (ISP) Router which
is the Default Gateway for the Management Network and as you also know,
in this Lab is configured with IP Address 192.168.15.254
Therefore, all Controllers should have a Default Route pointing to this
Default Gateway, which is configured with the following command:
- ip route 0.0.0.0/0 192.168.15.254
Yes, the configuration syntax is a bit different than traditional Cisco devices.
With this Default Route in place the Controllers have access to the Internet,
but the most important effect of this connection, is the fact that it gives us
access to the Controllers from the Client PC’s Desktop.
To access vManage’s Web Interface you need to use the following URL:
https://192.168.15.51:8443/
As you may see, instead of using the standard Port 80, this Web Interface
used Port 8443. The following image shows vManage’s Web Interface
Login page:

The Access Credentials for this Web Interface are:

Username: admin
Password: admin

Cisco EI Lab User's Guide Property of Ciscoland.net

These are actually the same Access Credentials used to login to vManage’s
CLI; that is, vManage’s Console Port.
Please keep in mind that vManage and all Controllers take a long time to
get fully loaded and ready to operate. So you won't be able to login and/or
access the Web Interface until they are actually ready, which could take at
least 20 minutes after they are powered up.
The following image provides a partial view of vManage’s Dashboard:

As you may see, the Dashboard provides a view of the entire SD-WAN
Network, as it shows the connections to the other Controllers (vSmart and
vBond) and to all three vEdges.
Of course we are going to explain how to navigate this Dashboard, but you
can find a good explanation at this URL:
https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-
xe-gs-book/vmanage-dashboard.html
The following YouTube Video also provides a good Tutorial:
Cisco SDWAN: vManage GUI Deep Dive
https://www.youtube.com/watch?v=SQshStgp72I

Cisco EI Lab User's Guide Property of Ciscoland.net

SD-WAN Controllers have 2 Interfaces:
- In-Band Management Interface: VPN ID 0
- Out-of-Band Management Interface: VPN ID 512
As you know the OOB-Switch is connected to vSwitch0 which is part of
our do Out-of-Band Management Network. So through this Switch we have
Out-of-Band access to the Controllers over VPN 0, which of course has to
be configured using IP Subnet 192.168.15.0/24.
But in addition to this connection, the Diagram also shows a link between
WAN-Switch and vSwitch1, which is labeled as In-Band Network:

We use this label because in this case vSwitch1 is giving us access to the
Controller’s In-Band Management Interface, which is configure using IP
Subnet 10.1.1.0/24
To be more specific, these are the IP Addresses assigned to the Controller’s
In-Band Management Interfaces:
- vManage ==> 10.1.1.1
- vBond ==> 10.1.1.2
- vSmart ==> 10.1.1.3
Normally we would not have access to the In-Band Mgmt. Interface, nor
should we. Actually, that’s the job of the OOB Management Interface.
However, since this is a Lab, it would be nice to also have access to the In-
Band Mgmt. Interface from our Desktop.

Cisco EI Lab User's Guide Property of Ciscoland.net

To do that this Lab includes a second Default Gateway. Not the Internet
Default Gateway, which is our Internet Router (192.168.15.254), but a
Default Gateway for the In-Band Mgmt. Network whose only purpose is to
give us access to this network from the Client PC’s Desktop.
This Default Gateway is implemented with a CSR1000v Router deployed
under the name CSR-DG.
CSR-DG was introduced in section 3 (ESXi Server Configuration & Mgmt)
and as it was mentioned there, this VM should be powered up when EVE-
NG is powered up. Now you know why.
The following image shows CSR-DG’s Settings:

As this image shows, Network Adapter 1 (NIC1) is connected to the VM

Network. Therefore, NIC1 has an IP Address in IP Subnet 192.168.15.0/24
Network Adapter 2 (NIC2) is instead connected to the vSwitch1.
Therefore, the connection between WAN-Switch and vSwitch1 is actually a
connection between WAN-Switch and this special 2nd Default Gateway.
And since this Default Gateway is also connected to the VM Network, any
device connected to this Network would have also have access to the WAN-
Switch, which is basically an In-Band Mgmt. Switch.
Since NIC1 is connected to the VM Network, it could get an IP Address via
DHCP. And this case we let the Default Gateway to get its IP via DHCP.
These are the configuration commands for Default Gateway’s NIC1:

Cisco EI Lab User's Guide Property of Ciscoland.net

interface GigabitEthernet 1
description Connection to Lab's Internet Router (vSwitch0)
no shut
ip add dhcp
NIC2 can't get an IP Address via DHCP, so we have to assign an explicit
one. But we don't do it directly on the main Interface. Instead, we create a
Sub-Interface and configure IP Address 172.1.0.1 on it:
interface GigabitEthernet2.1
encapsulation dot1Q 1 native
ip address 172.1.0.1 255.255.255.0

We create a Sub-Interface because as you know NIC2 is the Interface that

provides a connection to the Physical Switches. And since these Switches
will send traffic marked with different VLAN ID’s, we need to allow the
separation of traffic circulating through NIC2.
Since we are using IP Address 172.1.0.1 on the Default Gateway, the other
side of this link of course should be configured with an IP Address in the
same Subnet.
In fact, these are the configuration commands for WAN-Switch’s Interface
connected to vSwitch1, which in this case is Interface g0/0
interface g0/0
description Connection to Default Gateway (DG)
no switchport
ip address 172.1.0.2 255.255.255.0
no shut
As mentioned before the Lab Disk (or Flash Drive) has all the Configuration
Files for all the elements in this sample Network. So please check it out.
As you may see there, the Default Gateway also needs some Static Routes
to make this sample Network work as intended.
First of all, it needs a Default Route (0.0.0.0 0.0.0.0) that points to the
Lab's Internet Router (192.168.15.254), so that it can reach the Internet:
ip route 0.0.0.0 0.0.0.0 192.168.15.254

It also needs a Route to the Controllers In-Band Network: 10.1.1.0/24.

This Route should point to the WAN Switch (172.1.0.2):
ip route 10.1.1.0 255.255.255.0 172.1.0.2

The Sample Network Diagram also shows one more connection between the
SD-WAN Network and the external world. The following image shows that:

Cisco EI Lab User's Guide Property of Ciscoland.net

As the image shows, there is also a connection from the SD-WAN’s
Internet Router to the Lab’s Internet Router; that is, to vSwitch0
To verify that the Internet Cloud is actually vSwitch0, please click on the
Internet Cloud object and select the Edit option. You’ll see the following:

Cisco EI Lab User's Guide Property of Ciscoland.net

Here the Object Type is Cloud0, which is EVE-NG’s term for vSwitch0
By the way, there is great YouTube Video that explains the terms used by
EVE-NG to refer to the Network Interfaces that are part of this VM:
Connect EVE-NG to External VMs with Numbered Clouds
https://www.youtube.com/watch?v=OINW16cJp4w

So if the Internet Cloud is actually vSwitch0, it means that the connection

between the SD-WAN’s Internet Router and vSwitch0 should be configured
the same way as the connection between the Default Gateway & vSwitch0;
that is, letting the proper Interface get an IP address via DHCP.
Now the question is: Which Interface in the SD-WAN’s Internet Router
should be configured with DHCP (with command ip address dhcp) ?
As the Network Diagram shows, the SD-WAN’s Internet Router has five
Interfaces (it actually has 6, but we use only 5 of them):

- GigabitEthernet0/0 ==> Connection to WAN-Switch

ip address 200.200.100.1 255.255.255.252

- GigabitEthernet0/1 ==> Connection to Site-101-vEdge1

ip address 200.200.100.5 255.255.255.252

- GigabitEthernet0/2 ==> Connection to Site-102-vEdge2

ip address 200.200.100.9 255.255.255.252

- GigabitEthernet0/3 ==> Connection to Site-103-vEdge3

ip address 200.200.100.13 255.255.255.252

- GigabitEthernet0/4 ==> Connection to the Internet Router

ip address dhcp
These are the configuration commands in SD-WAN’s Internet Router:
interface GigabitEthernet0/4
description Connection to the Internet through Lab's ISP Router
ip address dhcp
The SD-WAN’s Internet Router also needs Static Routes similar to those
configured in the Default Gateway. That is, a Default Route to the Lab's
Internet Router (192.168.15.254), so that it can reach the Internet:
ip route 0.0.0.0 0.0.0.0 192.168.15.254
It also needs a Static Route to the Controllers In-Band Network 10.1.1.0/24
This Route should point to the WAN Switch (200.200.100.1):
ip route 10.1.1.0 255.255.255.0 200.200.100.1

Cisco EI Lab User's Guide Property of Ciscoland.net

Static Routes in Internet/ISP Router
Finally, the Lab’s Internet Router also needs some Static Routes!
This is quite obvious, because we have added Static Routes to CSR-DG
(Default Gateway) and to SD-WAN’s Internet Router.
As you know, those Routes point only in one direction, but we also need
Routes in the opposite direction. Otherwise, the Packets won’t know the
return Route.
Let's review what we've done so far. Both, Routers CSR-DG & SD-WAN’s
Internet Router were configured with a Default Route:
ip route 0.0.0.0 0.0.0.0 192.168.15.254

And we also added a Static Route to the Controllers In-Band Network

(10.1.1.0/24)
CSR-DG (Default Gateway)
ip route 10.1.1.0 255.255.255.0 172.1.0.2

SD-WAN’s Internet Router

ip route 10.1.1.0 255.255.255.0 200.200.100.1

As you may see, there is traffic from 3 different Subnets that are being re-
directed to the Lab’s Internet Router (192.168.15.254):
- 10.1.1.0/24
- 172.1.0.0/24
- 200.200.100.0/24
Therefore, we need to tell this Router how to send traffic from these
Subnets back to their proper origin.
If the Lab’s Internet Router was also a Cisco Router, we could solve this
problem very easily by simply running RIP, EIRGP or OSPF, so that all
Routers learn all Routes.
But the Lab’s Internet Router is most likely a Linksys or similar product in
which it would be very difficult to run any Dynamic Routing Protocol.
The solution is this case then would be to create Static Routes using the
Router's GUI.
But to create a Static Route we need to know the Gateway's IP Address.
We know that CSR-DG is the Gateway to reach the first two Subnets
(10.1.1.0/24 & 172.1.0.0/24)
And we also know that SD-WAN’s Internet Router is the Gateway to reach
Subnet 200.200.100.0/24

Cisco EI Lab User's Guide Property of Ciscoland.net

But we don't know the exact IP Address that should be used. However
that's easy to find out.
We simply need to run the command sh ip int brief in these Routers and
we'll get the DHCP-assigned IP Addresses that should be used to create the
Static Routes.
Of course these IP Addresses will be different in each case. The following
image shows these Static Routes as they were created in a Linksys Router:

To test these Static Routes, we simply try to ping any IP Address in these
Subnets.
If everything is done correctly all of the IP Addresses used in the SD-WAN
Network should be reachable (pingable) from the Client PC’s Desktop!

Cisco EI Lab User's Guide Property of Ciscoland.net

Appendix F: EVE-NG Windows Client Side Software
One of the main advantages of EVE-NG is the fact that it uses a Web
Browser to connect to the respective Server process. That is, it doesn’t
require any special Client-Side Software like GNS3 or VIRL do.
However, this claim is not 100% accurate because EVE-NG actually does
need a little piece of Client Side Software.
Although the interaction with the Server process is in fact done with a Web
Browser, once we start creating Projects, we’ll need some additional Tools
to interact with the Virtual Devices.
For instance, if you want to configure a Network device like a Switch or a
Router will need some kind of Telnet Software Tools to access them.
Other Network Nodes may need a different Tool. For instance, to access a
Linux Sever we may want to use some SSH Software. Or if our Topology
includes some Windows PC’s, we may need to use a VNC Tool (Virtual
Network Computing) to access them,
So we need to setup our Client PC with the proper (preferred) Tools to
access the different type of Nodes in our Network.
If our Client PC is a Windows computer, we’ll need to install the following
piece of Software:
- EVE-NG-Win-Client-Pack-2.0.exe
If instead we are using a Mac as a Client PC, we’ll need to install the
following Package:
- EVE-ClientPackV2.dmg
Both Software Packages can be downloaded from this URL:
https://www.eve-ng.net/index.php/download/
But of course we include them as part of the Lab Materials. They can be
found in Folder: EVE-NG Installation Software/EVE-NG-Client-Pack
For a more detailed explanation please check out the following YouTube
Videos:
EVE-NG Console Options Explained: HTML5 Console, HTML5 Desktop, Native Console
https://www.youtube.com/watch?v=00K2EUeFOq4

Installing EVE-NG Client Tools: Integrate SecureCRT, UltraVNC, and PuTTy

https://www.youtube.com/watch?v=r1EHttibcXo

Cisco EI Lab User's Guide Property of Ciscoland.net