We're ready now to move on from the network we've been extending so far and build some new very simple simulations that will help illustrate the mechanisms available to establish connectivity to the Ethernet management interfaces available on each node in a running simulation.

Don't skip the background.

In order to understand and configure the various management access mechanisms you'll first need to understand some details about how VIRL handles projects, users, and networking internally.  Take some time to review the background information provided just below.

Be prepared to record some addresses.

In this excercise you will need to record and reference a number of IP addresses associated with simulations.  Be prepared to use some sort of text application or a pencil and paper to do so.

So far we've been using VM Maestro to connect to the console ports of VIRL nodes.  Console connections are useful for configuring, testing, and troubleshooting, and for many this may be all that is needed.

However, what if you want to:

For any of these requirements you need IP connectivity to the nodes' management interfaces.  VIRL provides three mechanisms for such connectivity - these are:

Each of these methods exposes network connectivity on the 'Flat' network which extends from inside the VIRL host to outside via the host's eth1 network interface.

The Flat network uses by default subnet 172.16.1.0/24 and the VIRL host has an interface on Flat at 172.16.1.254.  The Flat IP subnet, host interface, and host IP address can each be changed during installation to suit site-specific requirements, but this exercise assumes that the defaults remain in use.

These mechanisms - described below - are chosen using the Managment Network dropdown on the Topology tab of the topology's Properties pane:


Private Simulation and Private Project Networking

Whenever either of the Private methods are used a Linux Container (LXC) or - optionally - an Ubuntu jump-host is created for each simulation to provide a bridge (a figurative bridge, not literal networking bridge) between the Flat network and a management network which uses subnet 10.255.0.0/16, and into which each nodes' management interface is then placed.

Management access is then achieved by first accessing the LXC using SSH, and then using Telnet or SSH to access the nodes.  The LXC can also be configured to forward traffic for nodes in the simulation or even host network applications or services directly to manage the nodes in the simulation.

Jump host?

A jump-host is simply a host that has interfaces in two networks, one of which you can reach and the other of which you cannot, except by using the host as a way-point.  VIRL provides two jump-hosts - a lightweight LXC and a heavier full Ubuntu virtual machine which can be modified to provide persistent services and applications if needed.

Projects and Users

Before further explanation of the differences between Private Simulation and Private Project Networking can be offered it's important to understand the distinction between Projects and Users.

A project is a group of users, and every user must be in a project.  By default the user 'guest' is created and used when initially connecting VM Maestro to the VIRL server.  What's perhaps not apparent is that this user 'guest' is already part of a project of the same name.

Using the User Workspace Management interface it's possible to create additional projects, and additional users within a project.  For example, we could create users 'jack' and 'jill' in the 'guest' project and when accessing VIRL from VM Maestro the credentials used would be 'guest-jack' and 'guest-jill', making both the project and the user names apparent.

We could also create new projects called 'dev' and 'ops', and distinct users within each - but we won't for this exercise.

Now that you understand 'projects' and 'users', let's explore the primary differences between the two Private methods - that being the scope of visibility provided by the LXC.

Private Simulation Networking

When using Private Simulation Networking a single discrete 10.255.0.0/16 subnet is created for each simulation and the LXC has connectivity to only those nodes running within that single simulation, as illustrated below.  The dotted line represents the scope of nodes visible to the LXC:



The LXC cannot see and therefore cannot access the nodes in any other simulations, even those running as part of the same project.

Private Project Networking

When using Private Project Networking a single discrete 10.255.0.0/16 subnet is created for the project and the LXC created has connectivity to all nodes running within that project, regardless of which user owns the simulation, as illustrated below.  The dotted line represents the scope of nodes visible to the LXC:



The LXC cannot see and therefore cannot access the nodes in any other project or the nodes that are part of any simulation - even those in the same project - that uses Private Simulation Networking.

Shared Flat Networking

The Shared Flat Networking mechanism differs from the two Private mechanisms in a number of key ways:


Onward to the Lab

OK, now that you understand the differences between the three management access mechanisms let's move on to the lab.

In this exercise you will create four new topologies containing a single router each and using each of the management network mechanisms described above.  You will then access the VIRL host directly so as to gain access to the Flat network and examine the reachabilty that exists between the nodes in the four simulations.

You've got this.

Steps you've done already won't be described in as much detail below. Just take your time and use what you've learned so far.  If you get stuck just go back and review the previous exercises.

  1. Create and launch four new VIRL topologies each containing a single IOSv router and configured as follows:

    Don't forget to generate configurations for each of your topologies, and just so they are more easily recognized in the steps below you may want to name your routers to match the topology to which they belong.


  2. Using the Simulations pane, identify and record the IP address associated with the IOSv node in the 'private' simulation:

    1. Right-click on the node.

    2. Select 'Telnet...'

    3. Look for the address associated with the 'Management' port.

    In this example the management IP address associated with the IOSv node in the 'private' simulation is '10.255.0.1.'


    You can't get there from here.

    Don't bother actually selecting 'to its Management port' because it won't work.  The IP address shown will be on a subnet that exists on the VIRL host and will not be reachable without prior special configuration not covered here.


  3. Identify and record the IP address associated with the LXC created for the 'private' simulation.  In this example the LXC's IP address is '172.16.1.114.'


  4. In the same manner record the IP addresses associated with the IOSv nodes and LXCs in the 'project.1' and 'project.2' simulations.


  5. Record the management IP address for IOSv node in the 'shared' simulation.  In this example the IOSv node's management IP address is '172.16.1.117'

  6. LXCs in 'shared' simulations.

    Observe that the management IP address for the IOSv node in the 'shared' simulation is on the Flat subnet just like the LXCs associated with the 'private' simulations.  Because of this no LXC is needed to gain managment access.  LXCs are still created for 'shared' simulations, but they are used for other purposes such as configuration extraction and can be ignored here.

    Finding 'Flat'.

    We've captured the IP addresses we need in each of the four simulations and now need access to the Flat subnet so we can connect to the various LXCs and IOSv nodes.

    There are a number of ways to get access to the Flat subnet, but the one way that works every time for everyone and will be used here is to login to the VIRL host and use its permanent and direct interface into Flat.

  7. Find the IP address of your VIRL host.  This is most easily accomplished using the 'Credentials Tool' in the bottom right of the VM Maestro Status bar. Select the button that appears as:

    Then find the IP address or host name listed in the roster.  In this example, the IP address of the VIRL host is '10.1.1.138' but your address may differ.


  8. Using an SSH tool appropriate to your platform connect to the VIRL host using the username 'virl' and password 'VIRL'.  For example (your address may differ):

    On a Mac or Linux open a Terminal window and enter:

    ssh virl@10.1.138

    On Windows, download and use 'Putty':


    If you are using Windows you can download the latest version of 'Putty' from putty.org. 

  9. Explore, but be careful.

    While logged in to the VIRL host you are welcome to poke around and explore some basic OpenStack list commands if you happen to know any but be careful not to do anything that might harm your VIRL installation. You've been warned.

  10. Once logged in to the VIRL host, use SSH to connect to the LXC associated with the 'private' simulation using the username 'guest' and password 'guest'.  For example (your address may differ):

    ssh guest@172.16.1.114

  11. While using SSH to connect to the VIRL host or the LXCs you may be prompted to accept the RSA key associated with the target.  It is safe and necessary to accept these keys by entering 'yes'.

  12. Once logged in to the LXC use Telnet and the password 'cisco' to connect to the managment interface of the IOSv node in the 'private' simulation.  For example (your address may differ):

    telnet 10.255.0.1

    You shoud now be connected to the 'private' IOSv node via its management interface.


  13. Logout of the IOSv node and close the Telnet connection, returning the the LXC.

    exit

  14. From the LXC associated with the 'private' simulation attempt to connect to the management intefaces associated with the IOSv routers in the 'project.1' and 'project.2' simulations and observe that connectivity cannot be established, as expected.


  15. Logout of the LXC associated with the 'private' simulation.

    exit

  16. Using SSH, connect to one or both of the LXCs associated with the 'project.1' or 'project.2' simulations.


  17. Using Telnet, confirm that connectivity exists from either of the 'project' LXCs to the IOSv nodes in both of the 'project' simulations.


  18. Using Telnet, confirm that connectivity does not exist from either of the 'project' LXCs to the IOSv node in the 'private' simulation.


  19. Logout of the LXC (or LXCs) associated with the 'project' simulations.


  20. From the VIRL host, use Telnet to connect directly to the IOSv node in the 'shared' simulation.  For example (your address may differ):

    telnet 172.16.1.117


  21. Observe that the IOSv node in the 'shared' simulation is accessible directly via the Flat network without using an LXC.


  22. From the IOSv node in the 'shared' simulation use Ping to confirm connectivity to other devices on Flat such as the LXCs associated with the other 'private' and 'project' simulations.


  23. Logout of the IOSv router associated with the 'shared' simulation.


  24. Logout of the VIRL host.


  25. Return to VM Maestro and use the 'Stop' tool to end all of the running simulations.


Another route to Flat

In some cases such as when using VMware Fusion or Workstation or when using a host with its own IP connectivity to Flat it may be possible to access LXCx and other nodes in the Flat subnet directy without first connecting to the VIRL host.  Give it a try on your machine if you wish.


You should now have a good understanding of a number of important VIRL new concepts, including:

Now let's move on to the next exercise where you'll learn how to use some of the layer-2 features available in VIRL.