In Part 1 of this blog series, we covered the step-by-step procedure for installing EVE-NG (eve-ng.net) on Google Cloud Platform (GCP). In this blog post, we are going to look at how to spin up a very simple topology, consisting of an Arista vEOS and Juniper vMX router. In Part 3, we will investigate how we can connect our EVE-NG topology to external VMs that reside in our GCP environment.
Downloading The Arista vEOS Image
Kudos to Arista for making vEOS-lab freely available to download and use … customer adoption is accelerated when you make things open, accessible and less prohibitive. You can create a free account here, and use it to access the Software Download page, where you can download both vEOS (virtualized EOS) and cEOS (containerized EOS) images. In this blog post, we are going to try out version 4.24.0F of vEOS. As highlighted in the screenshot below, we need to download a couple of files:
The first file (“Aboot-veos-serial-8.0.0.iso”) enables the sending of console output during bootup time to the serial port. The second file (“vEOS64-lab-4.24.0F.vmdk”) is the actual vEOS image for a 64-bit system.
Note: If you are unsure whether your system is 32-bit or 64-bit, you can run the “uname -m” command. If the output shows “x86_64” then you are running 64-bit. If it shows something like “i386” or “i686” then you are running 32-bit.
Once you have obtained the above two files, you need to upload them to your home directory on your EVE-NG machine, as shown in the screenshot below. Note: also shown below is a Juniper vMX image file (“vmx-bundle-18.4R3.3.tgz”), which was obtained separately.
Staging The Image Files On EVE-NG
Before we can create topologies in EVE-NG using our virtual router image files, we need to first stage them properly on the EVE-NG server. Note that EVE-NG is fairly prescriptive about this, in terms of the format and location of the image files as well as the naming conventions of both the image files and the folders where the images are housed. There is an EVE-NG webpage on QEMU Image Naming which lists the naming conventions for all supported vendors. Sifting through this long list, Table 1 below summarizes the pertinent info for both Arista vEOS and Juniper vMX (note that for Juniper we need to consider both the Control Plane (vMX-vCP) and Forwarding Plane (vMX-vFP).
NOTE: EVE-NG requires that all image folders be located in directory /opt/unetlab/addons/qemu/. The image folder name must begin using the convention outlined in the first column of Table 1 above. After the “-“, the folder name should include the name and version of the image.
Let’s apply these conventions to correctly stage our Arista vEOS and Juniper vMX images.
Staging Arista vEOS Image Files
Let’s begin with staging the Arista vEOS image files. First, note that the 64-bit Arista vEOS image file is in VMDK format, which is meant for use with VMware or VirtualBox. We need to convert this VMDK image into “QCOW2” format that is compatible with KVM. To do this, we can use the “qemu-img convert” utility to convert between the two formats. Note that according to Table 1 above, the QCOW2 file needs to be named as “hda.qcow2“, so we use the following command to convert the image:
/opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 vEOS64-lab-4.24.0F.vmdk hda.qcow2
Also, according the to Table 1 above, the “Aboot-veos-serial-8.0.0.iso” file needs to be renamed to “cdrom.iso“, using the following command:
sudo cp Aboot-veos-serial-8.0.0.iso cdrom.iso
At this point, our home directory looks as shown in the screenshot below, where we now have the new “hda.qcow2” and “cdrom.iso” image files alongside the original uploaded files.
Next, we create the image folder under “/opt/unetlab/addons/qemu/” according the naming convention outlined above. For our Arista vEOS 4.24.0F image, we will name the folder “veos-4.24.0F” using the following command:
sudo mkdir -p /opt/unetlab/addons/qemu/veos-4.24.0F
We can now move our renamed image files to this newly created image folder:
sudo mv hda.qcow2 /opt/unetlab/addons/qemu/veos-4.24.0F/
sudo mv cdrom.iso /opt/unetlab/addons/qemu/veos-4.24.0F/
Finally, run the following command to fix permissions:
sudo /opt/unetlab/wrappers/unl_wrapper -a fixpermissions
Staging Juniper vMX Image Files
Now let’s stage the Juniper vMX image files. Note that the vMX consists of two separate components or VMs: one for the virtual forwarding plane (VFP) and one for the virtual control plane (VCP). The VFP runs the virtual Trio forwarding plane software and the VCP runs Junos OS. Despite running separately, the VCP and VFP logically function together as a single device.
The first thing we need to do is to unzip the vMX image archive in your home directory, as shown below:
tar -xvf vmx-bundle-18.4R3.3.tgz
Next, “cd” to the “vmx/images” directory and list the contents; you should see an output similar to the screenshot below:
There are four files highlighted in the screenshot above which need to be renamed in order to comply with the EVE-NG naming conventions outlined in Table 1 above. The table below summarizes the changes that need to be made. Note that the first 3 entries are VCP-specific image files, while the last entry is a VFP-specific image file.
|vMX Component||Original Filename||New Filename|
In addition, as per Table 1 above, the VCP-specific files need to go in one particular directory (whose name starts with “vmxvcp-“), and the VFP-specific files need to go in a different directory (whose name starts with “vmxvfp-“). Both of these image directories need to reside under “/opt/unetlab/addons/qemu/”, similar to the Arista vEOS image folder.
Let’s first create these directories. We will name our VCP directory “vmxvcp-18.4R3.3-VCP” and our VFP directory as “vmxvfp-18.4R3.3-VFP”, using the commands shown below.
sudo mkdir /opt/unetlab/addons/qemu/vmxvcp-18.4R3.3-VCP
sudo mkdir /opt/unetlab/addons/qemu/vmxvfp-18.4R3.3-VFP
The screenshot below shows the newly created directories under “/opt/unetlab/addons/qemu/”.
With the directories created, let’s now rename our four VCP/VFP image files and move them to their appropriate folders under “/opt/unetlab/addons/qemu/”. The commands to do this are shown below:
sudo cp junos-vmx-x86-64-18.4R3.3.qcow2 /opt/unetlab/addons/qemu/vmxvcp-18.4R3.3-VCP/virtioa.qcow2
sudo cp vmxhdd.img /opt/unetlab/addons/qemu/vmxvcp-18.4R3.3-VCP/virtiob.qcow2
sudo cp metadata-usb-re.img /opt/unetlab/addons/qemu/vmxvcp-18.4R3.3-VCP/virtioc.qcow2
sudo cp vFPC-20191212.img /opt/unetlab/addons/qemu/vmxvfp-18.4R3.3-VFP/virtioa.qcow2
And that’s it for staging! At this point, your “/opt/unetlabs/addons/qemu/” directory should look like this:
Spinning Up A Topology Using The EVE-NG GUI
Now that the staging of the image files on the EVE-NG server is complete, we are ready to spin up our simple dual-vendor topology using the EVE-NG GUI. Point your browser to https://<your_eve-ng_ip_address>, and you should see the following login screen, shown below. Login to the app using your credentials.
From the main “File manager” landing page, click on the “Add new lab” icon as shown in the screenshot below.
The “Add New Lab” popup window appears, as shown below. Fill in the various fields for Name, Version, Author, Description and Summary, and click on “Save” to continue.
The user is then taken directly to the Topology Designer for the lab just created. The Topology Designer is the Visio-like canvas where you can drag and drop newly instantiated virtual routers, link them together to create network topologies and launch them.
Launching The Arista vEOS
Let’s get started with spinning up a new Arista vEOS device. To do this, right-click anywhere in the canvas, and in the “Add a new object” context-menu that appears, select “Node”, as shown in the screenshot below.
In the “Add A New Node” popup window that appears (shown below), select “Arista vEOS” from the “Template” field dropdown menu.
The contents of the “Add A New Node” popup window changes according to the selected Template. The contents of this provisioning wizard can be largely left intact, unless you wish to modify certain parameters, such as the router name, or the number of CPUs, the amount of memory to allocate, or the number of Ethernet ports to assign. Click on “Save” to continue.
You will see the Arista vEOS router icon displayed in the main Topology Designer canvas window. The icon will be shown as grey in colour because it has not been started yet. To start the router, right-click on it and select “Start” in the context-menu that appears, as shown in the screenshot below.
To view the console logs as the router boots up, click once on the router icon, and a popup window will appear, which will provide terminal server console access to the device. This is shown in the screenshot below. The router will have finished booting up once the “login:” prompt appears (use “admin” as the default username, without any password).
Launching the Juniper vMX
As mentioned above, the Juniper vMX is different from the Arista vEOS, in that there are two components to consider: the Virtual Control Plane (VCP) and the Virtual Forwarding Plane (VFP). In similar fashion to what was done above for Arista vEOS, add a node for “Juniper vMX VCP” and another node for “Juniper vMX VFP” onto the Topology Designer canvas. What is key here is to establish a communication link between the VCP and VFP via an internal bridge. As shown in the screenshot below, draw a line between the VCP and VFP, and a new “Add Connection Between vMX-VCP and vMX-VFP” popup window will automatically appear. Important: for both the VCP and VFP, select “em1/int” as the Interface.
Finally, to start the vMX, select both the VCP and VFP, right-click on the selected group, and in the context-menu that appears, select “Start Selected”. This is shown in the screenshot below.
To view the console logs as the router boots up, click once on the icon for the vMX-VCP, and a popup window will appear, which will provide terminal server console access to the device. This is shown in the screenshot below. The router will have finished booting up once the “login:” prompt appears (use “root” as the default username, without any password).
Note: with the Juniper vMX, all CLI configurations are performed on the VCP, and all porting and connections are done on the VFP. The exception is the management interface “fxp0” or “em0”, which must be connected on the VCP.
Now that we are able to instantiate Arista vEOS and Juniper vMX routers individually, we can then stitch multiple such nodes together to create a larger network topology, as desired, such as the simple setup shown in the screenshot below.
In the next blog post, Part 3, we will explore how we can connect our EVE-NG topology to external VMs that reside in our GCP environment.