Brezular's Blog

This article provides step-by-step guide for setting Cisco ASAv Virtual Appliance on VMware - Workstation, Player or Fusion. Thanks go to the original author of the idea of copying deployed ASAv files from vSphere datastore to a local host.

Prerequisites:

a) VMware vSphere 5.x with the following components

• ESXi Server
• vCenter Server
• vSphere Web Client or vSphere Client for Windows or Linux

b) VMware Workstation or VMware Player or VMware Fusion
c) Cisco ASAv Virtual Appliance - asav922.ova

1. Deploy ASAv with vSphere Client

a) File-> Deploy OVF Template-> select path to ovf template
b) Select configuration (1. vCPU standalone) and Thin Provision.
c) Configure Network Cards.
d) Power on ASAv virtual machine.

When OVF XMML parsing is finished, ASAv reboots. After boot, installation is finished and you can power off a virtual machine.

2. Copy ASAv files from Datastore to Local Host

Click on Inventory and select the option Datastores and Datastore Clusters. Browse Data store and navigate to ASAv directory.

Picture 1 - ASAv Files in Datastore

Download all the files from directory to a local host with installed VMware Workstation.

3. Convert Virtual Disks

The following files were copied to a local host directory.

Picture 2 - Size of Virtual Disks Before Conversion

When we check the content of the file ASAv922.vmdk, we can see that virtual disk type is vmfs.

Picture 3 - Virtual Disk Type - vmfs

Although vmfs format can be directly used by VMware Workstation we will convert it to monolithicSparse type in order to reduce its size. To do this we will use offline disk manipulation utility - vmware-vdiskmanager that is included in VMware Workstation.

Use the commands bellow to convert virtual disks to single growable virtual disks.

$ vmware-vdiskmanager -r ASAv922.vmdk -t 0 ../ASAv922.vmdk
$ vmware-vdiskmanager -r ASAv922_1.vmdk -t 0 ../ASAv922_1.vmdk

Replace old virtual disk with the new ones and delete flat vmdk files that are not needed anymore.

$ mv ../ASAv922* .
$ rm *flat*

4. Import Configuration File

Start VMware Workstation and navigate to the Files -> Open. Select path to vmx file. VMware Workstation should be able to import settings successfully. Once you power on the virtual machine, click an option I copied it.

Picture 4 - Dialog Menu

End.

Links
http://sanbarrow.com/vmdk/disktypes.html

MikroTik RouterOS is the stand-alone operating system of MikroTik RouterBOARD hardware. It can also be installed on a PC and will turn it into a router with all the necessary features - routing, firewall, bandwidth, management, wireless access point, backhaul link, hotspot, gateway, VPN server and more.

The tutorial explains how to install RouterOS on Qemu virtual disk and configure GNS3 software to run such a router. Later, We will use GNS3 to a create simple testing topology with one RoutersOS router connected to emulated Cisco 3725 router.

You can download Mikrotik RouterOS x86 installed on Qemu and VirtualBox images in the Download section here.

Software Prerequisites

GNS3 with Qemu or VirtualBox support (the last GNS3 version with Qemu/VirtualBox support is 0.8.7, the current GNS3 version 1.0.7 Alpha has not implemented support for Qemu and VirtualBox hypervisor yet
Qemu or VirtualBox
RouterOS ISO image - mikrotik-6.15.iso

Virtual Machine Prerequisites

i386 compatible architecture
minimum 32MB of RAM (maximum supported 2GB)
minimum Hard Disk space 64MB
Network cards supported by linux v3.3.5 kernel (PCI, PCI-X)

RouterOS x86 Installation

1. Download RouterOS for x86 Architecture

$ wget http://download2.mikrotik.com/routeros/6.15/mikrotik-6.15.iso

2. Create Qemu Virtual Disk and Start Virtual Machine

$ /usr/local/bin/qemu-img create -f qcow2 routeros-6.15.img 200M
$ /usr/local/bin/qemu-system-i386 -m 512 -enable-kvm -boot d -cdrom mikrotik-6.15.iso routeros-6.15.img

3. Install RouterOS

Use spacebar to select packages that are needed. Then press I to install RouterOS.

Picture 1 - RouterOS Installation

Once RouterOS is installed, you have 24 hours to enter a license key to activate RouterOS Qemu image. The timer stops if router is shutdowned. For this reason, we let GNS3 automatically create the copy of base Qemu image everytime is a new RouterOS instance placed on the GNS3 desktop. These independent copy of the base image can be run for total 24 hours time period.

4. Start RouterOS Qemu Disk

After the disk is formatted and packages copied, start RouterOS instance with the command:

$ /usr/local/bin/qemu-system-i386 -m 512 -enable-kvm -boot c routeros-6.15.img -nographic -serial telnet::4444,server,nowait

You should be able to login to RouterOS with the telnet command:

$ telnet 127.0.0.1 4444

Username is admin without password set.

5. Connect Qemu image to GNS3

I assume that GNS3 is correctly installed and configured.

a) Start GNS3 and create a new GNS3 project

Picture 2 - Creating GNS3 New Project

b) Configure Qemu guest settings

Navigate to Edit -> Preferences -> Qemu -> Qemu Guest and configure parameters as it is shown on the picture below.

Picture 3 - Qemu Guest Settings

RouterOS Configuration

1. Testing Topology

The topology consists of one RouterOS that connects two Microcore Qemu instances. As we want to test switching and VLANs, both Microcore instances are connected to RouterOS switvchport that are separated by VLANs - VLAN10 and VLAN20.

RouterOS's interface Ethernet1 si connected to Cisco 3725 router emulated by Dynamips. The port will be configured as a trunk port on RouterOS side and as a routed port with two sub-interfaces on Cisco's side.

Picture 4 - Testing Topology

2. Create Bridges for VLAN10 and VLAN20 and Assign Access Ports to Bridges

First, check available Ethernet interfaces.They are six Ethernet interfaces presented in RouterOS console in total.

Picture 5 - Router Ethernet Interfaces

We are going to create bridges br10 and br20 and assign interface Ethernet2 to the bridge br10 and Ethernet3 to br20.

[admin@MikroTik] > /interface bridge add name=br10
[admin@MikroTik] > /interface bridge add name=br20
[admin@MikroTik] > /interface bridge port add interface=ether2 bridge=br10
[admin@MikroTik] > /interface bridge port add interface=ether3 bridge=br20

3. Configure Trunk Port to allow VLAN 10 and VLAN 20 and create Switched Virtual Interfaces - SVI10 and SVI20

[admin@MikroTik] > /interface vlan add vlan-id=10 name=SVI10 interface=ether1 disabled=no
[admin@MikroTik] > /interface vlan add vlan-id=20 name=SVI20 interface=ether1 disabled=no

Note: the term SVI is used in a Cisco world, feel free to change it if you want.

4. Add SVI Ports to Bridges

[admin@MikroTik] > /interface bridge port add interface=SVI10 bridge=br10 disabled=no
[admin@MikroTik] > /interface bridge port add interface=SVI20 bridge=br20 disabled=no

Picture 6 - Bridge Ports Configuration

5. Assign IP address to SVI Ports

This configuration ensures that intervlan routing betwwen VLAN 10 and VLAN20 can be done by RouterOS.

[admin@MikroTik] > /ip address add interface=SVI10 address=192.168.10.254/24 disabled=no
[admin@MikroTik] > /ip address add interface=SVI20 address=192.168.20.254/24 disabled=no

At this point you should be able to make successful ping between PC1 and PC2.

6. Set password and hostname

[admin@MikroTik] > /password new-password=admin
[admin@MikroTik] > /system identity set name=RouterOS-I

7. Static routing configuration

[admin@RouterOS-I] > /ip route add dst-address=10.10.10.10/32 gateway=192.168.10.253

Picture 7 - Routing Table

End hosts PC1 and PC2 Configuration

End hosts are represent by Microcore Linux 3.8.2 installed on Qemu virtual disks. Ethernet interfaces configuration is stored in the file /opt/bootlocal.sh that is started during the boot of Microcore. To save configuration changes, the script /usr/bin/filetool.sh must be called with parameter -b.

PC1
tc@box:~$ sudo su
root@tc:# echo "ifconfig eth0 192.168.10.1 netmask 255.255.255.0 up" >> /opt/bootlocal.sh
root@tc:# echo "hostname PC2" >> /opt/bootlocal.sh
root@tc:# echo "route add default gw 192.168.10.254" >> /opt/bootlocal.sh

root@tc:~# /opt/bootlocal.sh
root@PC1:~# /usr/bin/filetool.sh -b

PC2
tc@box:~$ sudo su
root@tc:# echo "ifconfig eth0 192.168.20.1 netmask 255.255.255.0 up" >> /opt/bootlocal.sh
root@tc:# echo "hostname PC2" >> /opt/bootlocal.sh
root@tc:# echo "route add default gw 192.168.20.254" >> /opt/bootlocal.sh

root@tc:~# /opt/bootlocal.sh
root@PC2:~# /usr/bin/filetool.sh -b

Cisco 3725 Configuration

1. Router-on-the-stick Configuration

3725#conf t
3725(config)#interface fastEthernet 0/0
3725(config-if)#no shut
3725(config-if)#exit

3725(config)#interface FastEthernet 0/0.10
3725(config-subif)#encapsulation dot1Q 10
3725(config-subif)#ip address 192.168.10.253 255.255.255.0
3725(config-subif)#no shutdown

3725(config-subif)#int fa0/0.20
3725(config-subif)#encapsulation dot1Q 20
3725(config-subif)#ip address 192.168.20.253 255.255.255.0
3725(config-subif)#no shutdown

2. Loopback configuration

725(config)#interface loopback 0
3725(config-if)#ip address 10.10.10.10 255.255.255.255
3725(config-if)#no shutdown

Testing Connectivity

1. Check if RouterOS does Packet Switching Between VLAN10 and VLAN20 Subnets

Issue the command ping on PC1 to test connectivity between PC1 and PC2.

Picture 8 - RouterOS InterVlan Routing

2. Check if VLAN Tagged Traffic is Transferred via Trunk Port

Ping from PC1 to Cisco 3725 router's IP address 192.168.10.253

Picture 9 - Ping from PC1 to Cisco 3725

Picture 10 - Captured Traffic on Cisco 3725 Interface FastEthernet0/0

End.

RouterOS Basic Commands
http://rbmikrotik.blogspot.sk/2011/07/mikrotik-router-os-basic-commands.html

RouterOS x86 Features
http://wiki.mikrotik.com/wiki/Manual:RouterOS_features
http://download2.mikrotik.com/what_is_routeros.pdf

RouterOs Switching
http://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features
http://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_Interface_Setup

RouterOS VLANs
http://wiki.mikrotik.com/wiki/Vlans_on_Mikrotik_environment

MikroTik RouterOS is the stand-alone operating system of MikroTik RouterBOARD hardware. It can also be installed on a PC and will turn it into a router with all the necessary features – routing, firewall, bandwidth, management, wireless access point, backhaul link, hotspot, gateway, VPN server and more.

RouterOS x86 installed on Qemu and VirtualBox disks is not licensed, you have 24 hours in total to run these images.

1. RouterOS x86 6.15

Qemu
https://drive.google.com/file/d/0B6L2h6R5UKMhQUcxMFl2a1pZZGs/edit?usp=sharing
http://sourceforge.net/projects/gns-3/files/Qemu%20Appliances/routeros-6.15-qemu.zip/download
http://www.4shared.com/zip/HG7nubJlba/routeros-615-qemu.html

VirtualBox
https://drive.google.com/file/d/0B6L2h6R5UKMhODYyNm0tWnFjXzA/edit?usp=sharingv
http://sourceforge.net/projects/gns-3/files/VirtualBox%20Appliances/routeros-6.15-vbox.zip/download
http://www.4shared.com/zip/qPN2tmD7ba/routeros-615-vbox.html

VyOS is a community fork of Vyatta, a Linux-based network operating system that provides software-based network routing, firewall, and VPN functionality. The VyOS project was started in late 2013 as a community fork of the GPL portions of Vyatta Core 6.6R1 with the goal of maintaining a free and open source network operating system in response to the decision to discontinue the community edition of Vyatta.

VyOS runs on both physical and virtual platforms. It supports paravirtual drivers and integration packages for virtual platforms. It is completely free and open source.

The aim of the tutorial is to show VyOS installation on Qemu virtual machine and get it working on GNS3.

VyOS Qemu and VirtualBox virtual disks can be downloaded here.

I created a Bash script deploy_vyos for automatic deployment of VyOS to Qemu image. The script downloads stable VyOS ISO image from the Internet, creates Qemu disk and starts Qemu virtual machine with attached ISO image. Then is starts Expect script install_vyos that automatically configure all required configuration options without user intervention.

deploy_vyos
install_vyos

Just copy both scripts to the same directory, assign run privileges to both scripts with the command below and run the deploy_vyos script.

$ chmod +x deploy_vyos
$ chmod +x install_vyos

Software and Hardware Prerequisites

Host OS - any 64 bit Linux OS
Hypervisor - Qemu emulator and virtualizer compiled with x86_64 support
KVM
GNS3 1.0 beta3 and later - the first new GNS3 version that has built-in support for Qemu hypervisor
VyOS Installation ISO image
CPU with hardware virtualization support (AMD-V or VT-X extensions)
RAM minimum - 512 MB
Storage - 2 GB

1. Download VyOS x64 Installation ISO

$ wget http://0.uk.mirrors.vyos.net/iso/release/1.1.0/vyos-1.1.0-amd64.iso

2. Create Qemu Virtual Disk

$ /usr/local/bin/qemu-img create -f qcow2 vyos-1.1.0-amd64.img 1G

3. Start Qemu Disk with Attached VyOS ISO

$ /usr/local/bin/qemu-system-x86_64 -boot d -cdrom ./vyos-1.1.0-amd64.iso -hda vyos-1.1.0-amd64.img -enable-kvm -m 1G -serial telnet:localhost:3355,server,nowait

Connect to VyOS console with the telnet command:

$ telnet localhost 3355

4. VyOS Installation

Login as user vyos with the password vyos. Issue the command install system to install a new system to hard drive and follow installation instructions. When installation is finished, do not reboot the system as we are going to adapt VyOS to support GNS3. To make changes in VyOS that is installed on the /dev/sda1 disk we first have to mount it the disk.

vyos@vyos:~$sudo su
root@vyos:/home/vyos#mount -t ext4 /dev/sda1 /tmp

Now our VyOS installation is mounted to the /tmp directory.

5. Stop Generating New Name for Ethernet Interfaces with Changed MAC Address

Qemuwrapper, the script that controls Qemu inside GNS3 always starts Qemu virtual machines with randomly generated MAC addresses for Ethernet interfaces. VyOS with underlying Debian Linux is programmed to remember MAC address of existing Ethernet interfaces. During the boot when VyOS detects that a particular interface has a new MAC address assigned (generated by qemuwrapper), VyOS assigns a new name to this interface. Thanks to this, name of Ethernet interfaces are changed everytime is VyOS rebooted.

This is not a desirable behavior so we are going to configure VyOS to keep an original name of interface even if the interface MAC address had been changed.

First, rename the file vyatta_net_name to vyatta_net_name_backup.

vyos@vyos:~$ sudo su
root@vyatta:/home/vyatta#mv /tmp/lib/udev/vyatta_net_name /tmp/lib/udev/vyatta_net_name.bak
root@vyatta:/home/vyatta#mv /tmp/lib64/udev/vyatta_net_name /tmp/lib64/udev/vyatta_net_name.bak

Then, issue the following commands to add MAC addresses starting with the hex numbers 00 to the list of Ethernet interfaces with the names that will never be changed.

root@vyatta:/home/vyatta#sed -i 's/2367abef/00/g' /tmp/lib/udev/rules.d/75-persistent-net-generator.rules
root@vyatta:/home/vyatta#sed -i 's/2367abef/00/g' /tmp/lib64/udev/rules.d/75-persistent-net-generator.rules

The commands change the line ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}="" to ENV{MATCHADDR}=="?[00]:*", ENV{MATCHADDR}="" for both files:

/lib/udev/rules.d/75-persistent-net-generator.rules
/lib64/udev/rules.d/75-persistent-net-generator.rules

6. Change Boot Order

They are several boot options available in Grub menu window when VyOS is booted after its installation. Depending how VyOS was installed, the default option is configured by VyOS itself. For instance if we issued a command install system from a Qemu window, an option KVM console would be chosen as the default option. In our case, installation was done from the telnet window (serial console) so the option Serial console is chosen as the default boot option.

Picture 1 - VyOS Grub Menu Window

As we want to integrate VyOS Qemu virtual machine with GNS3 and use a serial console to connect VyOS instances running inside GNS3, we will do such as configuration which ensures that an option Serial console is always selected regardless of the type of installation.

root@vyatta:/home/vyatta#sed -i 's/set default=0/set default=1/g' /tmp/boot/grub/grub.cfg

The command replaces the default option 0 (KVM console) with the default option 1 (Serial console).

VyOS Integration to GNS3 Project

7. Configure GNS3 to Run VyOS Virtual Machine

Start GNS3 and create a new project. Navigate to Edit -> Preferences -> Qemu VMs. Configure VyOS Qemu settings as following.

Picture 2 - Qemu VyOS Settings

Click Advanced Qemu VM Settings tab and configure following parameters.

Picture 3 - Advanced Qemu VyOS Settings

VyOS User Guide:
http://vyos.net/wiki/User_Guide

End.

The tutorial discuss the use of GNS3 software to run Cisco Virtual IOS (vIOS). Cisco vIOS is shipped and supported as a part of the Cisco's One Platform Kit (onePK) that is distributed in form of virtual machine. It might be downloaded with Cisco.com account. Currently, it is not required to have Cisco account associated with service contracts, Bill-to IDs, or product serial numbers in order to download onePK.

Software Prerequisites

Host OS - any 64 bit Linux OS
Qemu emulator and virtualizer compiled with x86_64 support
KVM
GNS3 0.8.7 - the last version that has Qemu support included
Cisco all-in-one-VM-1.2.1-194.ova virtual machine

Minimum Hardware Requirements

CPU with hardware virtualization support (AMD-V or VT-X virtualization extensions)
Storage - 10 GB
RAM - 2000 MB
RAM vIOS - 384 MB

Script for Extracting vIOS from All-In-One VM

Here is a Linux bash script that helps you to extract vIOS vios-adventerprisek9-m.vmdk from all-in-one VM file. Download all-in-one.ova file from here and assign executable privileges to the script.

$ chmod +x extract_vios.txt

Then you can run the script as it is shown below. The only user input is selecting path to all-in-one VM file and entering a root password needed for temporary mount of raw image.

$ ./extract_vios

Script Requirements

VirtualBox or Qemu installed
+21GB free hard disk space to convert vmdk to raw format
Root password to mount raw image

Configuration Steps for Extracting vIOS from All-In-One VM

1. Download the onePK All-In-One Virtual Machine

https://developer.cisco.com/site/networking/one/onepk/sdk-and-docs/all-in-one-vm/

2. Extract Files from Virtual Machine

$ tar xvf all-in-one-VM-1.2.1-194.ova

Picture 1 - Content of OVA Tarball

The virtual disk all-in-one-VM-1.2.1-194-disk1.vmdk contains vIOS image that we are going to extract from the disk.

3. Extract vIOS from Virtual Disk

We can directly extract the vios image out of all-in-one-VM-1.2.1-194-disk1.img file.

a) Convert vmdk to raw disk

Use qemu-img utility to convert vmdk disk type to raw disk.

$ /usr/local/bin/qemu-img convert -O raw all-in-one-VM-1.2.1-194-disk1.vmdk all-in-one-VM-1.2.1-194-disk1.img

b) Check the available partitions inside the virtual disk

$ fdisk -l all-in-one-VM-1.2.1-194-disk1.img

Picture 2 - Available Partitions

c) Determine where the partition with vIOS image starts inside the virtual disk

The first partition flagged with boot option contains vIOS image. The partition starts at the sector 2048. The sector size is 512 bytes. When we multiple the starting sector number and the sector size we calculate the offset where the partition starts ( 512 x 2048 = 1048576 ).

$ echo '2048 * 512' | bc
1048576

d) Mount the partition and extract vIOS image from partition

Thanks the computed offset we can mount the partition and extract vIOS image from partition.

$ mkdir mount-point
$ sudo mount -o loop,ro,offset=1048576 all-in-one-VM-1.2.1-194-disk1.img mount-point/
$ tar xvf ./mount-point/usr/share/vmcloud/data/images/vios-adventerprisek9-m.ova -C /home/brezular/

The expected result is the file vios-adventerprisek9-m.vmdk located in a directory /home/brezular/.

4. Configure GNS3 to Run vIOS Disk

Start GNS3 and create a new project. Navigate to Edit -> Preferences -> Qemu -> General Settings. Configure Qemu general parameters and click test button.

Picture 3 - Qemu General Settings

Go ahead and configure GNS3 Guest settings. Navigate to Edit -> Preferences -> Qemu -> Qemu Guest. Configure vIOS parameters according to the picture below.

Picture 4 - Qemu vIOS Guest Settings

Picture 5 - Show Version Command

According to the show version command, vIOS distributed with onePK virtual machine is only demo version.

5. Testing Connectivity

The topology consists from the two routers running vIOS that are connected via GigabitEthernet0/0 interfaces.

Picture 6 - Testing Topology

Configure vIOS routers as following.

Router>en
Router#conf t
Router(config)#hostname vOS-I
vIOS-I(config)#interface GigabitEthernet 0/0
vIOS-I(config-if)#ip address 172.16.1.1 255.255.255.0
vIOS-I(config-if)#no shutdown
vIOS-I(config-if)#do wr

Router>en
Router#conf t
Router(config)#hostname vIOS-II
vIOS-II(config)#interface GIgabitEthernet 0/0
vIOS-II(config-if)#ip address 172.16.1.2 255.255.255.0
vIOS-II(config-if)#no shutdown
vIOS-I(config-if)#do wr

Successful ping issued on the vIOS-I router proves that connectivity is established between virtual IOS instances.

Picture 7 - Ping Between vIOS Instances

End.

Firefly Perimeter is a virtual security appliance that provides security and networking services at the perimeter in virtualized private or public cloud environments. It runs as a virtual machine (VM) on a standard x86 server and delivers similar security and networking features available on branch SRX Series devices.

However not all the features that are supported by SRX hardware devices are supported. Here is the list of features supported by current firefly 12.1x46-d10 release.

Firefly Perimeter Hardware Specifications

Memory 2 GB
Disk space 2 GB
vCPUs 2
vNICs Up to 10
Virtual Network Interface Card type (NIC) E1000

Thanks to Juniper’s software evaluation program we can download the Firefly Perimeter security solution for free and test it out for 60 days. In this tutorial we are going to connect Firefly Perimeter to GNS3 and create a simple lab to test connectivity between two vSRX instances. Even GNS3 has built-in support for VirtualBox, only Qemu / KVM will be used as hypervisor as I wasn't successful with running Firefly vSRX virtual on VirtualBox.

Firefly Perimeter virtual machines can be download here. You have to use your Juniper account to proceed the download but a valid service contract is not required to to download Firefly Perimeter virtual machine.

Picture 1 - Juniper Login Window

Notice that they are both JVA and OVA files available for download. We will download the OVA file archive that contains vmdk vSRX image and other files required for running vSRX on VMware appliance.

Picture 2 - Firefly Perimeter Download Page

Part 1 Running Firefly Perimeter as Qemu Appliance

This part discuss how to convert Firefly Perimeter installed on VMware image to qcow2 disk format that is recognized by Qemu and explains GNS3 Qemu settings configuration. As the current GNS3 1.0 beta2 does not have Qemu support included yet we will use the most latest GNS3 0.8.7 version with Qemu support.

1.1. Extract vmdk Virtual Disk from OVA File

$ tar xvf junos-vsrx-12.1X46-D10.2-domestic.ova

Picture 3 - Extracting OVA File

Starting at version 0.12, Qemu-kvm has native support for VMware virtual machines disks. When we have a closer look at the virtual disk we will find that the disk type is streamOptimized read only disk.

Picture 4 - StreamOptimized Virtual Machine Disk

As you can see, Qemu refuses to open streamOptimized virtual disks complaining that VMDK version 3 must be read only.

Picture 5 - Qemu fails to open StreamOptimized Virtual Machine Disk

A workaround consists of the conversion from streamOptimized vmdk disk to the copy and write qcow2 virtual machine disk type tha is recognized by Qemu.

$ qemu-img convert -O qcow2 junos-vsrx-12.1X46-D10.2-domestic-disk1.vmdk junos-vsrx-12.1X46-D10.2-domestic.img

Picture 6 - Converting from VMDK to QCOW2 Virtual Machine Disk

Part 1.2 GNS3 Qemu General and Guest Settings Configuration for Firefly Permiter

Start GNS3 0.8.7 and create a new project. Navigate to Edit -> Preferences -> Qemu -> Qemu General Settings. Configure Qemu general parameters and click test button.

Picture 7 - GNS3 General Qemu Settings

Go ahead and configure GNS3 Guest settings. Navigate to Edit -> Preferences -> Qemu -> Qemu Guest. Configure vSRX parameters according to the picture below.

Picture 8 - Qemu Guest Settings

Note Do not omit Qemu option -smp 2. According to my test, it is required to configuretwo CPUs for VM otherwise all Gigabit Ethernet interfaces are not recognized.

Part 2 Running Firefly Perimeter as VirtualBox Appliance

In this part we are going to convert Firefly Perimeter installed on VMware virtual machine disk (VMDK) to the native Virtualbox disk format - Virtual Disk Image (VDI). Then we will create a VirtualBox Firefly Perimeter VM and attach a virtual disk with installed Firefly Perimeter to this machine. At the end, we will configure GNS3 VirtualBox General Settings and VirtualBox VMs Settings to support our newly created Firefly Perimeter Vm.

Note As the new GNS3 1.0 version supports VirtualBox we will use it.

2.1. Extract Vmdk Virtual Disk from OVA File

$ tar xvf junos-vsrx-12.1X46-D10.2-domestic.ova

Convert VMware VMDK disk to VirtualBox disk VDI.

$ vboxmanage clonehd -format VDI junos-vsrx-12.1X46-D10.2-domestic-disk1.vmdk junos-vsrx-12.1X46-D10.2-domestic.vdi

Start VirtualBox Manager with the command below.

$ sudo virtualbox

Navigate to Machine-> New and select Type and Version as it is shown on the picture below.

Picture 9 - Creating New VirtualBox VM

Assign at least 1024 MB RAM to our VM. Continue to the Hard Drive window and select path to VDI disk.

Picture 10 - Selecting Hard Drive for VM

Left click on Firefly Perimeter VM and press Ctrl-S to open VM settings window. Navigate to System-> Processor and increase number of CPU to 2. This is need otherwise Junos fails to recognize Gigabit Ethernet interfaces.

Picture 11 - Increasing Number of CPU to 2

Note For each Firefly Perimeter network device inside GNS3 project, VirtualBox VM must be created first. For this reason we consider the Firefly Perimeter VM we have just created as the base image and we will used for cloning any other Firefly Perimeter VMs. Left click on Firefly Perimeter VM and press Ctrl-O.

Picture 12 - Cloning Firefly Perimeter Base VM

Select the Full Clone option a continue with pressing Clone button.

2.2 GNS3 VirtualBox General and Guest Settings Configuration for Firefly Permiter

Start GNS3 1.x and create a new project. If you run GNS3 on Linux, navigate to Edit -> Preferences -> VirtualBox -> General Settings. Configure path to VirtualBox wrapper.

Picture 13 - VirtualBox General Settings

Switch to VirtualBox VMs menu. Click on Refresh VM List button an select our virtual machine from the list. Change the default NIC type from Automatic to Paravirtualized (virtio-net) type otherwise connection will not be working.

Picture 14 - VirtualBox VMs Preferences

3. Testing Connectivity between Firefly Perimeter vSRX Instances

We are going to connect two instances of Firefly Perimeter vSRX routers via Gigabit Ethernet interfaces em0. The interface em0 represents an interface GigabiEthernet 0/0/0 in vSRX cli. We will assign IP address to the interfaces and issue the ping command on the vSRX-I router pinging the IP address 192.168.1.2 of the second router.

Picture 15 - Testing Topology

Start the routers and login as root without the blank password. Type the command cli to enter vSRX CLI. Check the available GigabitEthernet interfaces with the command:

root> show interfaces ge-0/0/* terse

Picture 16 - Firefly Perimeter Gigabit Ethernet Interfaces

They are seven GigabitEthernet interfaces presented in CLI output. Now assign particular IP address to the interface ge-0/0/0 on both routers.

vSRX-I Configuration

root@%
root@% cli
root> configure
[edit]
root# set system host-name vSRX-I
root# set system root-authentication plain-text-password
root# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24
root# set security zones security-zone untrust interfaces ge-0/0/0 host-inbound-traffic system-services ping
root# commit
root@vSRX-I> exit

vSRX-II Configuration

root@%
root@% cli
root> configure
[edit]
root# set system host-name vSRX-II
root# set system root-authentication plain-text-password
root# set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24
root# set security zones security-zone untrust interfaces ge-0/0/0 host-inbound-traffic system-services ping
root# commit
root@vSRX-II> exit

To test connectivity between router, ping IP address 192.168.1.2 from the router vSRX-I.

Picture 17 - Successful Ping Between Routers

End.

Links
http://www.junosworkbook.com/

HP VSR is a Comware 7 router software application for a server which provides the same functionality as a physical router. Installed on either VMware or KVM virtual machine it offers routing, Firewall, IPSec, and MPLS VPN security services.

The tutorial gives you some ideas how to install HP VSR1000 (Virtual Service Router) running Comware 7 OS on Qemu disk and connects Qemu appliance to GNS3.

They are HP VSR1001, VSR1004 and VSR1008 models available for download. Differences between models are explained here. As the VSR1001 model has the lowest RAM requirements comparing to other models and we do not have to concern the forwarding performance, VSR 1001 demo ISO image is our choice. The demo is full featured, performance limited and requiring no license and with no expiration date.

HP VSR1001 Minimum Hardware Requirements

CPU: 2.0 GHz
Memory: 1 GB
Disk space: 8 GB
Network interfaces: 2 virtual NICs, E1000 and VirtIO virtual NICs are recommended, maximum 16 NICs supported

1. Download HP VSR1001 Virtual Services Router

Navigate to the Download page here

Picture 1 - HP VSR1001 Virtual Services Router Download Page

Click on the button >> on he right, beside the padlock icon. Either sign in with your HP Passport account or create a new account. After registration navigate back to the Download software page. Once you are signed in, you are allowed to download the HP VSR1001 archive file. Click Download button and accept License Agreement.

Picture 2 - Unlocked Download HP VSR1001 Virtual Services Router

2. Install HP VSR 1001 on Qemu Disk

2.1. Unzip Archive

$ unzip -e VSR1000_7.10.R0202.zip

2.2. Create Qemu Disk

$ /usr/local/bin/qemu-img create -f qcow2 vsr1000-hp.img 8G

2.3. Start Qemu Disk with Attached ISO image

$ /usr/local/bin/qemu-system-x86_64 -enable-kvm vsr1000-hp.img -cdrom VSR1000_HP-CMW710-R0202-X64.iso -m 2G

Press button 1 - Fresh Install. Type yes to continue VSR1000 installation. Once installation process finishes, type yes to reboot and close Qemu window.

Picture 3 - HP VSR Install Menu

3. Configure GNS3

Start GNS3 0.8.7 and create a new project.

Picture 4 - New GNS3 Project

Navigate to Edit -> Preferences -> Qemu -> General Settings. Configure path to Qemu binaries and qemuwrapper. Once you finished, click the Test Settings button.

Picture 5 - Qemu General Settings

Navigate to Edit -> Preferences -> Qemu -> Qemu Guest and configure HP VSR 1001 virtual machine settings according to the picture below.

Picture 6 - Qemu Guest Settings

Drag and drop Qemu device to GNS3 dektop. Power on the Qemu appliance. Press Ctrl-D to break automatic configuration.

4. Configure HP VSR Routers and Test Connectivity Between Routers

Picture 7 - GNS3 Topology

4.1. Configure HP VSR routers

To be able to log in using GNS3 console we have to configure following commands on both routers.

<HP>system-view
[HP]user-interface aux 0
[HP-line-aux0]authentication-mode none
[HP-line-aux0]user-role network-admin
[HP-line-aux0]quit

Now we are allowed to log in to VSR appliance aux port. Right click on the router icon and select option Console. Configure the hostname and assign IP address for the interface GigabitEthernet 1/0.

VSR-I
[HP]sysname vsr-I
[vsr-I]interface GigabitEthernet 1/0
[vsr-I-GigabitEthernet1/0]ip address 192.168.1.1 24
[vsr-I-GigabitEthernet1/0]quit
[vsr-I]save

VSR-II
[HP]sysname vsr-II
[vsr-II]interface GigabitEthernet 1/0
[vsr-II-GigabitEthernet1/0]ip address 192.168.1.2 24
[vsr-II-GigabitEthernet1/0]quit
[vsr-II]save

4.2. Test Connectivity between Routers

To test connectivity between routers, ping IP address 192.168.1.2 from VSR-I router.

Picture 8 - Successful Ping

Monitor features in Cisco devices are able to show data flows but Cisco IOS lacks the option to export data on the fly. I wrote tiny GNU/Linux shell script to solve this restriction.

That is something like ASA capture (https://supportforums.cisco.com/document/69281/asa-using-packet-capture-troubleshoot-asa-firewall-configuration-and-scenarios) via HTTP/HTTPS.

I tested script on:

Router(config)#uname -a
IOSv Router IOS 15.4 Cisco IOS Software, vios Software (vios-ADVENTERPRISEK9-M), Experimental Version 15.4(20131213:232637) [lucylee-ca_pi23 137]
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Mon 16-Dec-13 19:50 by lucylee Unknown Unknown IOS

1. Create user and add privilege level 15 (root)

username user secret userpass
username user privilege 15

2. Start HTTP server, authentication style and optional (set max connection to 16 (default 5))

For security reasons you should set HTTP/HTTPS authorization with ACL and instead of HTTP use HTTPS server.

ip http server
ip http authentication local
ip http max-connections 16

3. Configure Monitor settings

Below I created a circular buffer called MY_BUFFER. Linear buffer is limited that means, if buffer is full IOS will stop capture. In circular buffer "old" data will be rewritten when buffer is full.

monitor capture buffer MY_BUFFER size 1024 max-size 9500 circular

Next step is to create a capture point. I created the capture point MY_CAPTURE and pointing it to the interface GigabitEthernet 0/1.

monitor capture point ip cef MY_CAPTURE Gig 0/1 both

Capturing process needs connect (association) capture point to buffer.

monitor capture point associate MY_CAPTURE MY_BUFFER

After this step we can start the capturing process.

monitor capture point start MY_CAPTURE

For more information about monitor features see Cisco's documentation.

4. HTTP modification

You can download contents from the buffer in two different ways. The first method is Direct URI, the second method is Server Side Includes (SSIs). Using the SSIs method is explained in more details below.

4.1 HTTP modification - Server Side Includes (SSIs)

This way uses the Server Side Includes technology.

I created a file "test.shtml" with the following content:

You can upload that file to router via "traditional way" - TFTP/SCP/... style or you can use IOS.sh.

IOS.sh way:

Turn on shell.

shell processing full

Create file with following content:

<printf "" > test.shtml

Check the content of file. In my case files are stored in flash memory.

cat test.shtml

You can get result from HTTP server with URI like this: "http://ip_add_of_router/path/to/file.shtml"

4.2 HTTP modification - Direct URI

In this method you use direct URI to download content from buffer but you must remove HTML tags at header. I decided not to publish this variation of the script. I want you to do it by your own in order to learn something new.

Tiny challenge for you, write script, which download contents from buffer and these contents save as file in pcap format.

HINT:

level/15/exec/show/monitor/capture/buffer/MY_BUFFER/dump/CR

5. GNU/Linux Script - Server Side Includes (SSIs)

IP address of the router is "192.168.20.3", a path to the file is "flash/test.shtml"

brezular.com-on-the-fly-capture-wireshark-screenshot

Telnet communication between 192.168.100.1 and 192.168.100.2

6. Notes

You can change download speed in wget with option "--limit-rate=amount"

Please read carefully documentation of monitor features.

Richard CHOMJAK

Here are mu notes about installation GNS3 version on Fedora Linux. It shows the basic steps required to successfully install and configure GNS3 for VirtualBox, Qemu, IOU, and Dynamips support. Configuration of individual VirtualBox, Qemu, IOU and IOS images is not discussed.

1. GNS3 GUI and Server Installation and Configuration

1.1 Install Dependencies

$ sudo yum install python3 python3-setuptools.noarch python3-PyQt4 python3-devel gcc

1.2 Download and Extract GNS3 GUI and Server

$ git clone https://github.com/GNS3/gns3-gui.git
$ git clone https://github.com/GNS3/gns3-server.git

$ cd gns3-gui/
$ sudo python3 setup.py install
$ cd ..

$ cd gns3-server/
$ sudo python3 setup.py install

1.3 Configure GNS3 Server Settings

Navigate to Edit-> Preferences-> GNS3 server-> Local server and change path to gns3server.

2. IOU Installation and Configuration

IOU stands for IOS on Unix. IOU images are IOS images that are compiled for x86 / Sparc CPU architecture.

2.1 Install Dependencies

$ sudo yum install gcc gcc-c++ git

2.2 Create Symbolic Link and Prevent IOU to Call Home

$ cd /usr/lib
$ sudo ln -s ./libcrypto.so.10 libcrypto.so.4
$ su -c "echo '127.0.0.127 xml.cisco.com' >> /etc/hosts"

2.3 Generate IOU License

To run IOU on Linux, a license file named iourc must be created with a valid license number tied with the hostname. The format of the file is following.

[license]
localhost = aaaaaaaaaaaaaaaa;

The length of the license key is 16 hex number and the hostname is localhost. If it is needed, the hostname can be changed in /etc/hostname.

2.4 Install IOUYAP

Iouyap bridges IOU to tap, UDP and Ethernet interfaces.

$ sudo yum install bison flex
$ git clone https://github.com/GNS3/iouyap.git
$ cd iouyap

$ git clone https://github.com/ndevilla/iniparser.git
$ cd iniparser
$ make
$ sudo cp libiniparser.so.0 libiniparser.a /usr/lib
$ sudo cp src/iniparser.h src/dictionary.h /usr/local/include

$ cd ..
$ make
$ sudo cp iouyap /usr/local/bin

2.5 Configure IOU Settings

Navigate to Edit-> Preferences-> IOS on Unix-> General Settings and select path to licence file iourc.
Navigate to Edit-> Preferences-> IOS on Unix-> General Settings and set path to iouyap.

3. VirtualBox Installation and Configuration

3.1 Vboxwrapper Installation

VirtualBox wrapper is needed for control VirtualBox on Linux.

$ sudo yum install python python-setuptools.noarch

$ git clone https://github.com/GNS3/vboxwrapper.git
$ cd vboxwrapper
$ sudo python setup.py install

Navigate to Edit-> Preferences-> VirtualBox-> General Settings and set path to Virtual box wrapper.

3.2 VirtualBox Installation

VirtualBox installation on Fedora is explained here:

4. Qemu Installation and Configuration

To successfully compile Qemu on Fedora, following Dependencies must be installed.

$ sudo yum group install 'C Development Tools and Libraries'

Qemu installation on Fedora Linux is explained here.

5. Dynamips Installation and Configuration

Dynamips installation on Fedora can be found here.

To configure path to Dynamips binary, navigate to Edit-> Preferences-> Dynamips-> General Settings and configure an option path to Dynamips.

End.

EOS (Extensible Operating System) is Linux-based network operating system developed by Arista Networks that runs on all Arista switches. Virtual EOS (vEOS) is single image and can be run in a virtual machine. The article describes how to set up vEOS virtual machine and connects it to GNS3 in order to test EOS functionality.

Host Requirements
Linux x86-64
Qemu or VirtualBox installed

Virtual Machine Requirements
1024 MB RAM
IDE CD-ROM drive with mounted Aboot-veos-serial-2.0.8.iso
2GB flash IDE disk - vEOS-4.14.2F.vmdk
NICs e1000 type

1. Download Bootloader and Virtual EOS

Clik the link to create a new account. The guest account (when no corporate email is used for registration e.g. gmail.com) is sufficient to download vEOS software. Click the link and login with the credentials you entered during the registration. You have to accept License Agreement in order to download vEOS software.

Download the bootloader and a virtual disk:

Aboot-veos-serial-2.0.8.iso
vEOS-4.14.2F.vmdk

2. Arista Switch First Boot on Qemu

Use Qemu to boot Arista switch virtual machine for the first time.

$ /usr/local/bin/qemu-system-x86_64 -m 1024 -enable-kvm -cdrom ./Aboot-veos-serial-2.0.8.iso -boot d vEOS-4.14.2F.vmdk -serial telnet::3355,server,nowait

Connect to the serial port of the image with the command below and check the boot proccess:

$ telnet localhost 3355

During the first boot, the file vEOS.swi (about 209MB) is being copied as .boot-image.swi to flash. The process may take several minutes to complete. When the switch boots up, login with the username admin with no password set. Switch to the enable mode and shutdown the switch with the command:

localhost>enable
localhost#sudo bash shutdown -h now

3. GNS3 Qemu Settings Configuration

Navigate to Edit-> Preferences-> Qemu VMs. Configure VMs settings according the picture below.

Picture 1 - GNS3 Qemu vEOS Settings

Switch to Advanced Qemu VMs Settings tab and configure following settings.

-boot d -cdrom Aboot-veos-serial-2.0.8.iso -enable-kvm -nographic

Replace the path to ISO with your own path.

Picture 2 - GNS3 Qemu vEOS Advanced Settings

4. Creating VirtualBox vEOS Virtual Machine

To run Arista switch on VirtualBox, you must create VirtualBox virtual machine. Start VirtualBox with the command:

$ sudo virtualbox

Create a new machine with Ctrl-n. Choose Linux Fedora (64 bit) and assign 1024 MB to a virtual machine. Select an option Do not add a virtual hard drive. Edit settings of the virtual machine with Ctrl-s and navigate to Storage menu. Remove SATA controler and click cdrom symbol. Select path to the file Aboot-veos-serial-2.0.8.iso. Click on Controller IDE and add hard disk. Select and option Choose existing disk and select path to the file vEOS-4.14.2F.vmdk.

Comapring to Arista first boot on Qemu, the first boot on VirtualBox takes only few seconds.

Picture 3 - Arista Vbox VM Storage Configuration

Start GNS3 and press Ctrl-Shift-P. Navigate to VirtualBox VMs and click refresh button. Configure settings according to the picture below.

Picture 4 - GNS3 VirtualBox VMs Preferences Configuration

5. Arista Switches Configuration

We are going to build a network topology that helps us to test configuration of VLANs, trunks and inter VLAN routing on Arista switches.The topology consists of two Arista switches and four computers, all these are emulated by Qemu. Switches are connected via 802.1q trunk with only traffic from VLAN20 allowed on trunk port. Computers are running Linux Core and they are connected to Arista switchports with configured either VLAN10 or VLAN30 on switchports. IP routing must be enabled on both switches in order to forward traffic between VLANs. Thanks to enabled OSPF routing protocol, the switch Arista1 receives info about the network 192.168.30.0/24 connected to the switch Arista2 and the switch Arista2 receives info about the network 192.168.10.0/24 that is connected to the switch Arista1.

Picture 5 - Network Topology

Arista1
localhost>enable
localhost#conf t
localhost(config)#hostname Arista1
Arista1(config)#enable secret arista
Arista1(config)#username admin secret arista

Arista1(config)#vlan 10
Arista1(config-vlan-10)#vlan 20
Arista1(config-vlan-10)#exit

Arista1(config)#interface ethernet 1
Arista1(config-if-Et1)#switchport mode access
Arista1(config-if-Et1)#switchport access vlan 10
Arista1(config-if-Et1)#no shutdown

Arista1(config-if-Et1)#interface ethernet 2
Arista1(config-if-Et2)#switchport mode access
Arista1(config-if-Et2)#switchport access vlan 10
Arista1(config-if-Et2)#no shutdown

Arista1(config-if-Et2)#interface ethernet 3
Arista1(config-if-Et3)#switchport mode trunk
Arista1(config-if-Et3)#switchport trunk allowed vlan 20
Arista1(config-if-Et3)#no shutdown

Arista1(config)#interface vlan 10
Arista1(config-if-Vl10)#ip address 192.168.1.254 255.255.255.0
Arista1(config-if-Vl10)#no shutdown

Arista1(config)#interface vlan 20
Arista1(config-if-Vl20)#ip address 192.168.20.1 255.255.255.252
Arista1(config-if-Vl20)#no shutdown

Arista1(config-if-Vl20)#ip routing
Arista1(config-if-Vl20)#router ospf 10
Arista1(config-router-ospf)#network 192.168.10.0/24 area 0
Arista1(config-router-ospf)#network 192.168.20.0/30 area 0

Arista1(config-router-ospf)#write mem

PC1
tc@box:~$ sudo su
root@box:~# ifconfig eth0 192.168.10.1 netmask 255.255.255.0 up
root@box:~# route add default gw 192.168.10.254
root@box:# hostname PC1

root@PC1:~# echo "ifconfig eth0 192.168.10.1 netmask 255.255.255.0 up" >> /opt/bootlocal.sh
root@PC1:~# echo "route add default gw 192.168.10.254" >> /opt/bootlocal.sh
root@PC1:~# echo "hostname PC1" >> /opt/bootlocal.sh
root@PC1:~# /usr/bin/filetool.sh -b

PC2
tc@box:~$ sudo su
root@box:~# ifconfig eth0 192.168.10.2 netmask 255.255.255.0 up
root@box:~# route add default gw 192.168.10.254
root@box:~# hostname PC2

root@PC2:~# echo "ifconfig eth0 192.168.10.2 netmask 255.255.255.0 up" >> /opt/bootlocal.sh
root@PC2:~# echo "route add default gw 192.168.10.254" >> /opt/bootlocal.sh
root@PC2:~# echo "hostname PC2" >> /opt/bootlocal.sh
root@PC2:~# /usr/bin/filetool.sh -b

Arista2
localhost>enable
localhost#conf t
localhost(config)#hostname Arista2
Arista2(config)#enable secret arista
Arista2(config)#username admin secret arista

Arista2(config)#vlan 20
Arista2(config-vlan-20)#vlan 30
Arista2(config-vlan-30)#interface ethernet 1
Arista2(config-if-Et1)#switchport mode access
Arista2(config-if-Et1)#switchport access vlan 30
Arista2(config-if-Et1)#no shutdown
Arista2(config-if-Et1)#interface ethernet 2
Arista2(config-if-Et2)#switchport mode access
Arista2(config-if-Et2)#switchport access vlan 30
Arista2(config-if-Et2)#no shutdown

Arista1(config)#interface vlan 30
Arista1(config-if-Vl30)#ip address 192.168.30.254 255.255.255.0
Arista1(config-if-Vl30)#no shutdown

Arista1(config-if-Vl30)#interface vlan 20
Arista1(config-if-Vl20)#ip address 192.168.20.2 255.255.255.252
Arista1(config-if-Vl20)#no shutdown

Arista1(config-if-Vl20)#ip routing
Arista2(config)#router ospf 10
Arista2(config-router-ospf)#network 192.168.20.0/30 area 0
Arista2(config-router-ospf)#network 192.168.30.0/24 area 0

Arista1(config-router-ospf)#write mem

PC3
tc@box:~$ sudo su
root@box:~# ifconfig eth0 192.168.30.1 netmask 255.255.255.0 up
root@box:~# route add default gw 192.168.30.254
root@box:~# hostname PC3

root@PC3:~# echo "ifconfig eth0 192.168.30.1 netmask 255.255.255.0 up" >> /opt/bootlocal.sh
root@PC3:~# echo "route add default gw 192.168.30.254" >> /opt/bootlocal.sh
root@PC3:~# echo "hostname PC3" >> /opt/bootlocal.sh
root@PC3:~# /usr/bin/filetool.sh -b

PC4
tc@box:~$ sudo su
root@box:~# ifconfig eth0 192.168.30.2 netmask 255.255.255.0 up
root@box:~# route add default gw 192.168.30.254
root@box:~# hostname PC4

root@PC4:~# echo "ifconfig eth0 192.168.30.2 netmask 255.255.255.0 up" >> /opt/bootlocal.sh
root@PC4:~# echo "route add default gw 192.168.30.254" >> /opt/bootlocal.sh
root@PC4:~# echo "hostname PC4" >> /opt/bootlocal.sh
root@PC4:~# /usr/bin/filetool.sh -b

6. Testing Arista Switches

Issue the command show ip route on the switch Arista1 to check if the OSPF routes are presented in its routing table.

Picture 6 - Available Routes in Routing Table of Arista1 Switch

If the switch Arista 1 learned path to the network 192.168.30.0/24, you can test the connectivity between PC1 and PC3 with traceroute command.

Picture 7 - Testing Connectivity Between PC1 and PC3

Reference:
http://blog.scottlowe.org/2014/08/11/running-arista-veos-on-kvm/

End.

ExtremeXOS is a network operating system used in Extreme Networks network switches. Virtualized version of ExtremeXOS - EXOS virtual machine vmdk image can be used to build virtual lab without need to use hardware switches. Although ExtremeXOS virtual machine can be downloaded for free only certain features are known to work. For this reason software should not be used for testing any actual networking setups or performance tests.

The tutorial consist of two parts. The part one explains how to configure Qemu emulator to run ExtremeXOS virtual machine. In part two, ExtremeXOS VM is connected to virtual lab run by GNS3 software. In this lab, features such as VLANs, 802.1q trunks and OSPF routing protocol are tested between multilayer switches from different vendors - Cisco, Arista and Extreme Networks.

Host Software and Hardware Requirements

Linux x86-64,
Qemu emulator version 2.1.2 (qemu-system-x86_64, qemu-system-i386 ) or later,
GNS3 version 1.1 or later,
RAM - at least 4 GB,
CPU with hardware virtualization support (VT-x or AMD-V)

Virtual Machines Software and Hardware Requirements

ExtremeXOS VM 15.3.2, exosvm.vmdk,
RAM 256 MB ,CPU x86-64
Qemu additional parameters: -nographic -enable-kvm
Vios_l2-ADVENTERPRISEK9-M), Version 15.0, vIOS-L2.vmdk,
RAM 512MB, CPU x86-64
Qemu additional parameters: -enable-kvm -nographic
Arista 4.14.2F, image vEOS-4.14.2F.vmdk
RAM 1024 MB, x86-64 CPU
Qemu additional parameters: -boot d -cdrom Aboot-veos-serial-2.0.8.iso -enable-kvm -nographic
Linux Core 3.0.21-tinycore, linux-core-4.7.7.img
RAM 128 MB, CPU i386
Qemu additional parameters: -nographic -enable-kvm

To download ExtremeXOS 15.3.2 virtual machine, you must register first. Create your account here and you will get your free registration code. When you finish registration process, navigate to download page.

Click on Download Free button and enter the mail address you used during the registration. Login with your username (email address) and password.

1. ExtremeXOS Virtual Machine on GNS3

1. Extract ZIP archive

$ unzip extremexosvm1532.zip
$ cd XOS_VM_Lab
$ unzip EXOS_VM_15_3_2.zip

2. Run XOS Virtual Machine using Qemu

Use Qemu to run virtual machine vmdk image.

$ /usr/local/bin/qemu-system-x86_64 -serial telnet::3366,server,nowait -m 512MB -enable-kvm exosvm.vmdk

Note: If you use Windows OS, omit the parameter -enable-kvm otherwise the virtual machine fails to start.

Once the machine starts, select an option Primary EXOS Image on (hd0,1) using serial console.

Picture 1 - ExtremeXOS Virtual Machine Grub Menu

Connect to virtual machine serial port with the telnet command.

$ telnet localhost 3366

Once the machine boots it sits on the login prompt. Username is admin without password set. After the first successful login you will be asked to answer several configuration questions.

Picture 2 - Boot with the Empty Configuration

3. Connect XIOS Virtual Machine to GNS3

Navigate to Edit-> Preferences-> Qemu VMs -> and create New machine according to settings below. After you finish Qemu VM configuration, you can change parameters clicking on Edit button. For instance, you can change number of NICs or configure additional Qemu parameters (-nographic, -enable-kvm) etc.

Picture 3 - Qemu Advanced Settings Tab

2. GNS3 Lab Configuration

The lab consist of three multilayer switches from different vendors. Cisco switch is represented by Virtual IOS L2 image, Arista switch is running Arista virtual EOS and extreme switch is running ExtremeXOS. Switches are connected by their ports that are configured as 802.1q trunks. Only tagged frames from VLAN ID 50, 51 and 52 are allowed on particular trunk ports. Clients connected to the switch ports are simulated by Linux Core.

Picture 4 - Lab Topology

Arista-I

localhost>en
localhost#conf t

Hostname
localhost(config)#hostname Arista-I

VLANs
Arista-I(config)#vlan 52
Arista-I(config-vlan-52)#vlan 20
Arista-I(config-vlan-20)#vlan 51
Arista-I(config-vlan-51)#exit

Password for Access to Privileged User Mode
Arista-I(config)#enable secret arista

Allow SSH Access to CLI
Arista-I(config)#username admin secret arista

Trunk Ports and Access Port
Arista-I(config)#interface ethernet 4
Arista-I(config-if-Et4)#switchport mode trunk
Arista-I(config-if-Et4)#switchport trunk allowed vlan 52

Arista-I(config-if-Et4)#interface ethernet 1
Arista-I(config-if-Et1)#switchport mode trunk
Arista-I(config-if-Et1)#switchport trunk allowed vlan 51

Arista-I(config-if-Et1)#interface ethernet 2
Arista-I(config-if-Et2)#switchport mode access
Arista-I(config-if-Et2)#switchport access vlan 20

VLAN Interfaces
Arista-I(config-if-Et2)#interface vlan 52
Arista-I(config-if-Vl52)#ip address 10.10.52.2 255.255.255.252
Arista-I(config-if-Vl52)#no shutdown

Arista-I(config-if-Vl52)#interface vlan 51
Arista-I(config-if-Vl51)#ip address 10.10.51.1 255.255.255.252
Arista-I(config-if-Vl51)#no shutdown

Arista-I(config-if-Vl51)#interface vlan 20
Arista-I(config-if-Vl20)#ip address 192.168.20.1 255.255.255.0
Arista-I(config-if-Vl20)#no shutdown
Arista-I(config-if-Vl20)#exit

IPv4 Routing
Arista-I(config)#ip routing

OSPF Protocol
Arista-I(config)#router ospf 1
Arista-I(config-router-ospf)#network 10.10.51.0 0.0.0.3 area 0
Arista-I(config-router-ospf)#network 10.10.52.0 0.0.0.3 area 0
Arista-I(config-router-ospf)#network 192.168.20.0 0.0.0.255 area 0
Arista-I(config-router-ospf)#passive-interface ethernet 2

Save Configuration
Arista-I(config)#do write mem

Linux Core-II

tc@box:~$ sudo su
root@box:~# echo "ip addr add 192.168.20.100/24 dev eth0" >> /opt/bootlocal.sh
root@box:~#echo "ip route add default via 192.168.20.1" >> /opt/bootlocal.sh
root@box:~# echo "hostname Core-II" >> /opt/bootlocal.sh

Apply Changes
root@box:~# /opt/bootlocal.sh

Make Configuration Persistent After Boot
root@Core-II:~# /usr/bin/filetool.sh -b

vIOS-I

Hostname
vIOS-L2-01>en
vIOS-L2-01#conf t
vIOS-L2-01(config)#hostname vIOS-L2-I

VLANs
vIOS-L2-I(config)#vlan 51
vIOS-L2-I(config-vlan)#vlan 30
vIOS-L2-I(config-vlan)#vlan 50
vIOS-L2-I(config-vlan)#exit

Password for Access to Privileged User Mode
vIOS-L2-I(config)#enable secret cisco

SSH server on Switch
vIOS-L2-I(config)#username admin secret cisco
vIOS-L2-I(config)#ip ssh version 2
vIOS-L2-I(config)#ip domain-name cisco
vIOS-L2-I(config)#crypto key generate rsa

Access to VTY ports
vIOS-L2-I(config)#line vty 0 15
vIOS-L2-I(config-line)#login local
vIOS-L2-I(config-line)#exit

Access to console port
vIOS-L2-I(config)#line console 0
vIOS-L2-I(config-line)#login local

Trunk Ports and Access port
vIOS-L2-I(config)#interface GigabitEthernet 0/1
vIOS-L2-I(config-if)#switchport trunk encapsulation dot1q
vIOS-L2-I(config-if)#switchport mode trunk
vIOS-L2-I(config-if)#switchport trunk allowed vlan 51

vIOS-L2-I(config)#interface gigabitEthernet 0/2
vIOS-L2-I(config-if)#switchport trunk encapsulation dot1q
vIOS-L2-I(config-if)#switchport mode trunk
vIOS-L2-I(config-if)#switchport trunk allowed vlan 50

vIOS-L2-I(config)#interface gigabitEthernet 0/0
vIOS-L2-I(config-if)#switchport mode access
vIOS-L2-I(config-if)#switchport access vlan 30

VLAN Interfaces
vIOS-L2-I(config)#interface vlan 51
vIOS-L2-I(config-if)#ip address 10.10.51.2 255.255.255.252
vIOS-L2-I(config-if)#no shutdown

vIOS-L2-I(config)#interface vlan 50
vIOS-L2-I(config-if)#ip address 10.10.50.2 255.255.255.252
vIOS-L2-I(config-if)#no shutdown

IOS-L2-I(config-if)#interface vlan 30
vIOS-L2-I(config-if)#ip address 192.168.30.1 255.255.255.0

IPv4 Routing
vIOS-L2-I(config-if)#ip routing

OSPF Protocol
vIOS-L2-I(config)#router ospf 1
vIOS-L2-I(config-router)#network 10.10.50.0 0.0.0.3 area 0
vIOS-L2-I(config-router)#network 10.10.51.0 0.0.0.3 area 0
vIOS-L2-I(config-router)#network 192.168.30.0 0.0.0.255 area 0
vIOS-L2-I(config-router)#passive-interface GigabitEthernet 0/0

Save Configuration
vIOS-L2-I(config)#do write

Core-III

tc@box:~$ sudo su
root@box:~# echo "ip addr add 192.168.30.100/24 dev eth0" >> /opt/bootlocal.sh
root@box:~# echo "ip route add default via 192.168.30.1" >> /opt/bootlocal.sh
root@box:~# echo "hostname Core-III" >> /opt/bootlocal.sh

Apply Changes
root@box:~# /opt/bootlocal.sh

Persistent Configuration after Boot
root@Core-III:~# /usr/bin/filetool.sh -b

EXOS-I

Change password for user admin
Summit-PC.1 # configure account "admin" password

Hostname
Summit-PC.2 # configure snmp sysName EXOS-I

SSH
To configure ssh, we must first download and install the separate Extreme Networks SSH software module (ssh.xmod). It is not shown in this tutorial.

VLANs
EXOS-I.3 # create vlan data52 tag 52
EXOS-I.4 # create vlan data50 tag 50
EXOS-I.5 # create vlan data10 tag 10

Trunk Ports and Access pPort
EXOS-I.6 # configure vlan data50 add ports 2 tagged
EXOS-I.7 # configure vlan data52 add ports 4 tagged
EXOS-I.8 # configure vlan "Default" delete ports 1
EXOS-I.9 # configure vlan "data10" add ports 1 untagged

VLAN Interfaces
EXOS-I.10 # configure vlan data50 ipaddress 10.10.50.1/30
EXOS-I.11 # configure vlan data52 ipaddress 10.10.52.1/30
EXOS-I.12 # configure vlan data10 ipaddress 192.168.10.1/24

IPv4 Routing
EXOS-I.13 # enable ipforwarding

OSPF Protocol
EXOS-I.2 # configure ospf add vlan data50 area 0
EXOS-I.3 # configure ospf add vlan data52 area 0
EXOS-I.9 # configure ospf add vlan "data10" area 0 passive
EXOS-I.4 # enable ospf

Save configuration
Summit-PC.2 # save

Core-I

tc@box:~$ sudo su
root@box:~# echo "ip addr add 192.168.10.100/24 dev eth0" >> /opt/bootlocal.sh
root@box:~# echo "ip route add default via 192.168.10.1" >> /opt/bootlocal.sh
root@box:~# echo "hostname Core-I" >> /opt/bootlocal.sh

Apply Changes
root@box:~# /opt/bootlocal.sh

Persistent Configuration after Boot
root@Core-I:~# /usr/bin/filetool.sh -b

Used Links
http://www.curtis-lamasters.com/cisco-vs-extreme-networks-switching-commands/
http://support.dce.felk.cvut.cz/mediawiki/index.php/Extreme_Networks_XOS_Commands#Basic_setup
http://mantikore.wordpress.com/2008/10/08/basic-command-of-extreme-switch/
http://netengu.blogspot.sk/2011/06/cisco-hp-and-extreme-networks-equvilent.html

End.

The Alcatel-Lucent virtualized Simulator (vSim) is a virtualization-ready version of SR OS called SR OS-VM. This new operating system is designed to run in a virtual machine (VM) on a generic Intel x86 server. In control and management plane aspects, the vSim is functionally and operationally equivalent to an Alcatel-Lucent hardware-based SR OS router.The vSim is intended to be used as a laboratory tool to fully simulate the control and management plane of an SR OS node. The vSim is not intended to be used in a production network environment and the forwarding plane is limited to 250 pps per interface. Furthermore, without a license file it will run for 1 hour before reloading.

Host Software and Hardware Requirements

Linux x86-64
Qemu emulator version 2.1.2 (qemu-system-x86_64 or i386)
GNS3 version 1.2 or later
RAM - at least 4 GB
CPU with hardware virtualization support (VT-x or AMD-V)

Virtual Machines Software and Hardware Requirements

TiMOS-B-12.0.R6 ALCATEL SR 7750, TiMOS-SR-12.0.R6-vm.zip
RAM 2048 MB, CPU x86-32
Qemu additional parameters: -nographic -enable-kvm

1. Installation Steps

Extract image from the zip file.

$ unzip TiMOS-SR-12.0.R6-vm.zip
$ cd vm/7xxx-i386/

Now a virtual disk sros-vm.qcow2 is extracted. To start Qemu virtual machine use the command:

$ /usr/local/bin/qemu-system-x86_64 -m 2048MB -enable-kvm sros-vm.qcow2 -serial telnet:localhost:3366,server,nowait -smp 2

Telnet to a serial port of virtual machine with the command:

$ telnet localhost 3366

Check cards that are presented presented in a system with the command:

A:vRR# show card state

Picture 1 - Card iom3-xp-b is Detected but not Provisioned

Card IOM3-XP-B is equipped in slot 1 of chasis but it is not provisioned. Thus we mustto provision it for the slot 1.

*A:vRR# configure card 1 card-type "iom3-xp-b"

Picture 2 - Card iom3-xp-b Provisioned in Slot 1

Card iom3-xp-b accepts up to two Media Dependent Adapters (MDAs). There is a one unprovisioned module m5-1gb-sfp-b equipped in port one of card iom3-xp-b that provides five Ethernet interfaces. We have to specify slot and mda type and save configuration.

*A:vRR# configure card 1 mda 1 mda-type "m5-1gb-sfp-b"
*A:vRR# admin save

Now we can connect vSIM virtual machine to connect to GNS3.

2. Connecting vSIM to GNS3

We are going to create a simple topology in order to check network connectivity between vSIM ports and Core Linux hosts.

Picture 3 - Port Connectivity Testing Topology

They are six Linux Core hosts connected to the ports of virtual service router. A table mapping vSIM ports and how they are presented in TiMOS configuration is following:

Timos ----- vSIM ports
bof ----------- eth0
1/1/1 --------- eth1
1/1/2 --------- eth2
1/1/3 --------- eth3
1/1/4 --------- eth4
1/1/5 --------- eth5

2.1 Configure GNS3 Qemu VMs Preferences

Navigate to Edit -> Preferences -> QEMU VMs and configure VM parameters according to the picture below.

Picture 4 - GNS3 Qemu VM Configuration

2.2 IP Address Configuration for Control Proccessor Module (CPM) Management Ethernet Interface

The interface eth0 is connected to CPM management interface. Use BOF command-line interface (CLI) to configure IP address for CPM interface.

*A:vRR# bof address 10.10.10.1/24

Save bof configuration.
*A:vRR# bof save

2.3 Linux Core Configuration - PC0

tc@box:~$ sudo su
root@box:~# echo "ifconfig eth0 10.10.10.2 netmask 255.255.255.0" >> /opt/bootlocal.sh
root@box:~# echo "route add default gw 10.10.10.1" >> /opt/bootlocal.sh
root@box:~# /opt/bootlocal.sh
root@box:~# /usr/bin/filetool.sh -b

2.4 IP Address Configuration for Port 1/1/1

*A:vRR# configure port 1/1/1 no shutdown
*A:vRR# configure router interface "PC1" address 192.168.1.1/24
*A:vRR# configure router interface "PC1" port 1/1/1

Note: The interface Ethernet 1 is represented by the port 1/1/1 in TiMOS configuration.

2.5 Linux Core Configuration - PC1

tc@box:~$ sudo su
root@box:~# echo "ifconfig eth0 192.168.1.2 netmask 255.255.255.0" >> /opt/bootlocal.sh
root@box:~# echo "route add default gw 192.168.1.1" >> /opt/bootlocal.sh
root@box:~# /opt/bootlocal.sh
root@box:~# /usr/bin/filetool.sh -b

2.6 IP Address Configuration for Port 1/1/2

*A:vRR# configure port 1/1/2 no shutdown
*A:vRR# configure router interface "PC2" address 192.168.2.1/24
*A:vRR# configure router interface "PC2" port 1/1/2

2.7 Linux Core Configuration - PC2

tc@box:~$ sudo su
root@box:~# echo "ifconfig eth0 192.168.2.2 netmask 255.255.255.0" >> /opt/bootlocal.sh
root@box:~# echo "route add default gw 192.168.2.1" >> /opt/bootlocal.sh
root@box:~# /opt/bootlocal.sh
root@box:~# /usr/bin/filetool.sh -b

2.8. IP Address Configuration for Port 1/1/3

*A:vRR# configure port 1/1/3 no shutdown
*A:vRR# configure router interface "PC3" address 192.168.3.1/24
*A:vRR# configure router interface "PC3" port 1/1/3

2.9 Linux Core Configuration - PC3

tc@box:~$ sudo su
root@box:~# echo "ifconfig eth0 192.168.3.2 netmask 255.255.255.0" >> /opt/bootlocal.sh
root@box:~# echo "route add default gw 192.168.3.1" >> /opt/bootlocal.sh
root@box:~# /opt/bootlocal.sh
root@box:~# /usr/bin/filetool.sh -b

2.10 IP Address Configuration for Port 1/1/4

*A:vRR# configure port 1/1/4 no shutdown
*A:vRR# configure router interface "PC4" address 192.168.4.1/24
*A:vRR# configure router interface "PC4" port 1/1/4

2.11 Linux Core Configuration - PC4

tc@box:~$ sudo su
root@box:~# echo "ifconfig eth0 192.168.4.2 netmask 255.255.255.0" >> /opt/bootlocal.sh
root@box:~# echo "route add default gw 192.168.4.1" >> /opt/bootlocal.sh
root@box:~# /opt/bootlocal.sh
root@box:~# /usr/bin/filetool.sh -b

2.12 IP Address Configuration for Port 1/1/5

*A:vRR# configure port 1/1/5 no shutdown
*A:vRR# configure router interface "PC5" address 192.168.5.1/24
*A:vRR# configure router interface "PC5" port 1/1/5

2.13 Linux Core Configuration - PC5

tc@box:~$ sudo su
root@box:~# echo "ifconfig eth0 192.168.5.2 netmask 255.255.255.0" >> /opt/bootlocal.sh
root@box:~# echo "route add default gw 192.168.5.1" >> /opt/bootlocal.sh
root@box:~# /opt/bootlocal.sh
root@box:~# /usr/bin/filetool.sh -b

2.14 Additional Configuration

Hostname
A:vRR# configure system name Timos-I

Admin Password
*A:Timos-I#password

Save Configuration
*A:Timos-I# admin save

2.15 Testing Connectivity between vSIM Ports

Login to PC1 and ping IP address of PC2, PC3, PC4 and PC5. As the hosts have default gateway configured, ping should be successful.

Picture 5 - Testing Connectivity Between vSIM Ports

3. Testing OSPF MD5 Authentication Between Cisco CSR1000v and Alcatel-Lucent vSIM

In this lab we will focus on configuration and testing authentication in OSPF routing protocol running on Cisco CSR1000v router and Alcatel-Lucent virtual simulator.

Installation and configuration of Cisco Cloud Service Router CSR1000v in GNS3 is explained here.

Picture 6 - OSPF Authentication Testing Topology

Note: A Link labeled as eth0 and connected to the first available port on CSR1000v is presented as interface GigabitEthernet 1 in CSR1000v configuration. Similarly, a link labeled as eth1 and connected to the second available port on Alcatel-Lucent vSIM is presented as port 1/1/1 in TiMOS CLI.

3.1 OSPF Configuration on CSR1000v

Password is set to lab123 and it must match between two OSPF neighbors.

Router>enable
Router#conf t

Router(config)#interface gigabitEthernet 1
Router(config-if)#ip address 192.168.1.1 255.255.255.0
Router(config-if)#ip ospf network point-to-point
Router(config-if)#ip ospf authentication message-digest
Router(config-if)#ip ospf message-digest-key 1 md5 lab123
Router(config-if)#no shutdown
Router(config-if)#exit

Router(config)#hostname CSR1000v-I
CSR1000v-I(config)#ip routing

SR1000v-I(config)#interface loopback 0
CSR1000v-I(config-if)#ip address 10.10.10.1 255.255.255.252
CSR1000v-I(config-if)#no shutdown

CSR1000v-I(config)#router ospf 1
CSR1000v-I(config-router)#router-id 1.1.1.1
CSR1000v-I(config-router)#network 10.10.10.2 0.0.0.0 area 0
CSR1000v-I(config-router)#network 192.168.1.0 0.0.0.3 area 0

Note: If you want to enable MD5 authentication for all interfaces in area 0, add the command:

CSR1000v-I(config-router)#area 0 authentication message-digest

3.2 OSPF Configuration Alcatel-Lucent Virtual Simulator

*A:vRR#configure system name Timos-I
*A:Timos-I# configure port 1/1/1 no shutdown
*A:Timos-I# configure router interface toCSR address 192.168.1.2/30
*A:Timos-I# configure router interface "toCSR" port 1/1/1
*A:Timos-I# configure router interface lo0 address 10.10.10.2/30
*A:Timos-I# configure router interface "lo0" loopback

*A:Timos-I# configure router ospf router-id 2.2.2.2
*A:Timos-I# configure router ospf area 0.0.0.0 interface "toCSR" interface-type point-to-point
*A:Timos-I# configure router ospf area 0.0.0.0 interface "lo0"

A:Timos-I# configure router ospf area 0.0.0.0 interface "toCSR" authentication-type message-digest
*A:Timos-I# configure router ospf area 0.0.0.0 interface "toCSR" message-digest-key 1 md5 "lab123"

Note: vSIM has the maximum transmission unit (MTU) set to 8936 Bytes for Ethernet interfaces by default. The default MTU value for CSR 1000v Ethernet interfaces is 1500 Bytes. In order to establish OSPF neigborship between two routers, MTU must match on both sides of link. For this reason we must configure MTU 1500 Bytes for vSIM port 1/1/1.

However as it is shown from the debug command enabled on Cisco, CSR 1000v continues complaining about smaller size of MTU. The MTU received in OSPF packets from the neighbor vSIM router is 1486 Bytes. It causes that routers are not fully adjacent and they stay in EXCHANGE neighbor state.

CSR1000v-I#debug ip ospf adj
*Dec 16 19:17:24.428: OSPF-1 ADJ Gi1: Rcv DBD from 2.2.2.2 seq 0x1E opt 0x42 flag 0x7 len 32 mtu 1486 state EXCHANGE
*Dec 16 19:17:24.428: OSPF-1 ADJ Gi1: Nbr 2.2.2.2 has smaller interface MTU

Changing MTU parameter to 1514 Bytes for Ethernet port 1/1/1 on vSIM helps to solve the issue.

*A:Timos-I# configure port 1/1/1 ethernet mtu 1514

3.3 OSPF MD5 Authentication Trobleshooting

We are going to check if routers are fully adjacent and if OSPF routes are presented in both routers's routing tables.

3.3.1 Checking OSPF on CSR1000v

CSR1000v-I#show ip ospf neighbor

Picture 7 - Full OSPF Neigborship Established

CSR1000v-I#show ip route

Picture 8 - Routing Table of Cisco CSR1000v

3.3.2 Checking OSPF on Alcatel-Lucent vSIM

A:Timos-I# show router ospf

Picture9 - OSPF Neighbor 1.1.1.1 presented in TiMOS CLI

A:Timos-I# show router route-table

Picture 10 - Routing Table of Alcatel-Lucent vSIM

End.

References:
http://echorequest.info/
http://labelswitched.blogspot.sk/2013/02/understanding-alcatel-lucent-ipv4.html
http://labelswitched.blogspot.sk/2013/02/ospf-configuration-comparison.html

Recently I have read a question on GNS3 forum asking whether Qemu supports more than 8 network adapters. According to Google search, maximum number of adapters for Qemu virtual machines can be configured with a parameter #define MAX_NICS 8 in a file ./include/net/net.h under Qemu source tree. After you set desirable value you must compile and install Qemu from source.

However I have noticed that changing the integer value in the line #define MAX_NICS has no effect on the maximum number of NIC allowed for Qemu VMs. I notice that I can start Core Linux Qemu machine with 18 network adapters even Qemu 2.2.0 was compiled with parameter #define MAX_NICS set to 1.

Now we know that Qemu itself does not limit the maximum network adapters to 8. We will go ahead and investigate GNS3. Navigate to Edit -> Preferences -> QEMU VMs and click on existing Qemu VM. Click on Edit button for this VM and navigate to Network tab. Increase the number of Adapters to 9.

The GNS3 1.2.1 allows to add maximum 8 NICs for a particular Qemu virtual machine. To avoid this limitation we have edit GNS3 source files and recompile GNS3 GUI and server. Here are the the steps for Linux.

1. Download and extract GNS3 1.2.1 Linux Sources

$ wget http://54dbd800be60307ab3fb-af183b57d94afbc9487771ea4c2db268.r84.cf5.rackcdn.com/GNS3-1.2.1.source.zip
$ unzip GNS3-1.2.1.source.zip

2. Install GNS3 GUI

$ cd gns3-server-1.2.1
$ unzip gns3-gui-1.2.1.zip
$ cd gns3-gui-1.2.1/

Edit a file qemu_vm_configuration_page_ui.py a change an integer number in a line self.uiAdaptersSpinBox.setMaximum(8) to value that represents the number of required network adapters.

$ vi gns3/modules/qemu/ui/qemu_vm_configuration_page_ui.py

self.uiAdaptersSpinBox.setMaximum(18)

Now GNs3 should allow to configure 18 NIC for each Qemu VM. But first we have to recompile GNS3 GUI.

$ sudo python3 setup.py install

Picture 1 - GNS3 QEMU VM Network Adapters Configuration

3. Install GNS3 Server

$ cd ../
$ unzip gns3-server-1.2.1.zip
$ cd gns3-server-1.2.1/

Edit a file schemas.py and change a parameter "maximum": 8, in these three parts of the file:

$ vi gns3server/modules/qemu/schemas.py

"adapters": {
"description": "number of adapters",
"type": "integer",
"minimum": 0,
"maximum": 18,
},

"port": {
"description": "Port number",
"type": "integer",
"minimum": 0,
"maximum": 18
},

Note: The number 18 in the line "maximum":18 should match the value that we configured in a file qemu_vm_configuration_page_ui.py.

Now we can recompile GNS3 server with the command:

$ sudo python3 setup.py install

4. Test Connectivity Between Core Linux Qemu Instances

I have created a simple GNS3 topology that consists of two Linux Core hosts emulated by Qemu. Each Core host is occupied with 18 Ethernet Interfaces (Eth0 - Eth17). Hosts are connected via their interface ETh17.

Picture 2 - Topology for Testing Connectivity Between Linux Core Hosts

Core-I
tc@box:~$ sudo su
root@box:~# echo "ifconfig eth17 192.168.1.1 netmask 255.255.255.0" >> /opt/bootlocal.sh
root@box:~# /opt/bootlocal.sh
root@box:~# /usr/bin/filetool.sh -b

Core-II
tc@box:~$ sudo su
root@box:~# echo "ifconfig eth17 192.168.1.2 netmask 255.255.255.0" >> /opt/bootlocal.sh
root@box:~# /opt/bootlocal.sh
root@box:~# /usr/bin/filetool.sh -b

We should be able to ping Linux Core-II IP address 192.168.1.2 from the host Core-I.

Picture 3 - Testing Connectivity Between Linux Core Hosts

End.

The tutorial explains how to set up pfSense VirtualBox appliance in order to use it as a personal firewall on Linux. It shows Linux network configuration to support this scenario and provides an installation script that automatically builds a VirtualBox virtual machine ready for pfSense installation. It also describes pfSense installation and shows minimal web configuration needed for successful connection to the Internet.

pfSense Live CD ISO disk can be downloaded from here.

1. Linux Network Configuration

We are going to install pfSsense from live CD ISO image on a VirtualBox virtual machine. To do so we must reconfigure an existing network interface, create a new one and configure new static default routes. A network topology consists of Linux Fedora with installed VirtualBox virtualizer. is shown below.

Picture 1 - Network Topology

A wireless network card is installed in Linux and presented as an interface wlp3s0. The interface wlp3s0 is the interface that connects Pfsense virtual machine to the outside world. This interface will be bridged with a first network adapter (em0) of the Pfsense virtual machine. Bridging host adapter wlp3s0 with the guest adapter em0 (WAN interface of Pfsense) will be done using vboxmanage utility and shown later in the tutorial.

As the Pfsense appliance is responsible for connecting to WAN network, we should remove an IP address from the interface wlp3s0 and delete a default route pointing traffic to networks via this interface. A root account is required to do the changes.

# ifconfig wlp3s0 0.0.0.0
# route del default dev wlp3s0

Now we need a virtual tap interface that will be bridged to the second network adapter em1 of the Pfsense virtual machine. Network interface em1 represents the LAN interface of the pfSense firewall. In order to create a virtual interface a package tunctl must be installed.

# tunctl -t tap0

The next step consists of IP address configuration for the interface tap0 and configuration of a default route that routes all traffic to LAN interface - em1 of Pfsense appliance.

# ifconfig tap0 192.168.1.2 netmask 255.255.255.0
# route add default gw 192.168.1.1

Now we can replace our DNS configuration with Pfsense DNS server.

# echo "nameserver 192.168.1.1" > /etc/resolv.conf

As a last step we are going to disable iptables to avoid undesirable traffic filtering.

# service iptables stop

Every time a Pfsense appliance is started we must issue type these commands. To automate a process you can write a script that will do this job for you. I will share my own script, you just need to replace the name of the interfaces and a username 'brezular' according to your needs. A root account is needed to start a script and to let the script configure network settings. The script also starts a Pfsense VirtualBox appliance in headless mode.

You can download the script here . Download it and assign executable privileges to the script.

$ chmod +x ./start_pfsense

2. Building VirtualBox Virtual Machine for PfSsense Installation

You can either create a virtual machine using VirtualBox GUI or use my second script that automatically builds a virtual machine and starts Pfsense installation. The script creates a virtual machine with two network adapters and bridge them with the particular host interfaces that you must enter as a script arguments. It is a virtual tap interface tap0 that will be bridged to em1 (LAN) interface of the Pfsense virtual machine and the interface wlp3s0 (in my case) bridged to em0 (WAN) interface of the Pfsense appliance.

$ chmod +x ./set_pfsense

Then start the script with the required arguments but change network interfaces according to your real adapters.

$ ./set_pfsense -m 1024 -f ./pfSense-LiveCD-2.1.5-RELEASE-i386.iso -l tap0 -n Pfsense -w wlp3s0

Picture 2 - Script Usage

Once a script finishes creating a virtual machine, Pfsense installation is started.

Picture 3 - Pfsense Virtual Machine Ready for Installation

3. PfSense Installation on VirtualBox

PfSense installation is explained here in detail. Just press key I (install) once you are prompted and select an option Quick/Easy Install. Once installation is finished, you will be asked for doing reboot. Power of the virtual machine (Right Ctrl-q) and deattach Live CD ISO disk from cdrom with using the command:

$ vboxmanage storageattach Pfsense --storagectl IDE --port 0 --device 1 --type dvddrive --medium none

Note: Change the virtual machine name pfSense according to the name of your VM.

Now you can start a virtual machine to finish an installation process with the command below.

$ vboxmanage startvm Pfsense

During the boot proccess you can notice a list of detected interfaces.

Picture 4 - List of Detected Interfaces

Type 'n' once you are asked to set up VLANs. Then you will be asked to enter the WAN interface name. It is an interface em0 and it was bridged with the interface wlp3s0. Installation continues with entering a name of pfSense LAN interface. It is an interface em1 and it was bridged with the interface tap0.

Hit enter when you are prompted to enter the name of Optional 1 interface name. At the end of install you should be able to see the following interfaces assignment.

Picture 5 - Interfaces Assignment

Hit the key 'y' to finish pfSense installation.

4. Minimal Pfsense Configuration

We will make a minimal Pfsense configuration that allows us to connect our Linux box to WAN network and to the Internet. For this purpose we are going to use a web browser to connect to the LAN interface of Pfsense - IP address 192.168.1.1. Username is admin and password pfsense.

Once you are logged in, configuration wizard is started. The wizard may be stopped by clicking the logo image at the top of the screen. Just do it.

4.1 Assign IP Address to WAN Interface

According to a network diagram, WAN interface should be configured with the IP address 172.17.100.5/16. Navigate to Interfaces-> WAN and select an option IPv4 Configuration Type - Static IPv4. Type the IP address 172.17.100.5/16 for WAN interface.

Picture 6 - WAN Interface Configuration

As the WAN interface has IP address assigned from the space reserved for private networks RFC 1918 (10/8, 172.16/12, 192.168/16) we should uncheck the box Block private networks. Then click Save and Apply Changes button.

Picture 7 - WAN Interface Configuration

4.2 Create a Static Default Route to WAN and Internet

Navigate to System-> Routing. Add a new IPv4 gateway by clicking on + button. Type a name of the Gateway, IP address (172.17.100.1) and check a switch Default Gateway. Click Save and Apply Changes button.

Picture 8 - Default Gateway Configuration

Note: In my case, a default gateway address is the IP address configured on the LAN interfaces of my Belkin SoHO router - 172.17.100.1/16. You have to enter your own default router IP address.

At this point we should be able to ping both - the IP address of our default router and public IP addresses located in the Internet. Lets try to ping Google IP address 8.8.8.8 from the Pfsense WAN interface. Navigate to Diagnostic-> Ping and make a test.

Picture 9 -Pinging Google Public IP Address

Now configure DNS server to let Pfsense us names if needed. Navigate to System-> General Setup and configure an option DNS Server. I want to use DNS server configured on my home Belkin router so I will configure IP addres 172.17.100.1.

4.3 Configure Network Address Translation - NAT

We want to hide our LAN network 192.168.1.0/24 behind the IP address 172.17.100.5/24 so NAT must be put in the place. Navigate to Firewall-> NAT and select an Outbound NAT tab. Click + button and type a source network 192.168.1.0/24 for a Source option. Leave the other settings default. Then click on Save button and you will return to the Outbound tab. Check the box Manual Outbound NAT rule generation (AON - Advanced Outbound NAT) and click Save and Apply Changes button.

Picture 10 - NAT Configuration

4.4. Disable User Admin and Create New Admin Account

Navigate to System-> User Manager and edit settings for user admin. Change a default password for this user and check the box Disabled. Then click Save button.

Now create a new user with admin privileges. Click on + button and type a name and a password for a new user. Assign admin privileges to your new account in the Group Memberships panel. Again, click the Save button.

Picture 11 - User Configuration

4.5 Secure Remote Access via CLI

In order to to start Pfsense appliance automatically we put the command 'runuser -l brezular -c 'vboxheadless -startvm Pfsense' in a startup script scriptstart_pfsense.txt. The script starts the Pfsense virtual machine in a headless mode. The headless mode allows to start a virtual machine from the command line so the VirtualBox GUI is not needed for this job. A graphical popup window with the Pfsense console will not appear and the output is transferred to VirtualBox Remote Display Protocol (VRDP) server. The server is listening on a port 3389 and anyone having connectivity to a Linux host can connect to Pfsense console using remote desktop client. To do so, we can use the command:

$ rdesktop-vrdp 192.168.1.2

Picture 12 - Pfsense Console

If we do not need access to pfSense console we can start the virtual machine in headless mode with disabled vrde server - option --vrde off. If it is your case, replace the actual command in start_pfsense.txt script with the command:

runuser -l brezular -c 'vboxheadless -startvm Pfsense --vrde off'

In order to keep the shell access to your pfSense appliance even after you disabled VRDE server, you should enable SSH server. Navigate to System-> Advanced and check the box button Enable Secure shell.

If you insist on using console, an access should be protected with a password. Navigate to System-> Advanced-> Admin Access and check the box Password protect the console menu. Next time you connect to console via remote desktop you will be asked to enter your credentials to log in.

5. Conclusion

We have just finished pfSense installation on VirtualBox machine and from now we can use it as a personal firewall on Linux. Adapt a first script I shared with you and use it to setup a network connection and for starting your pfSense VirtualBox appliance.

The article discuss how to run Cisco Adaptive Security Virtual Appliance (ASAv) on KVM hypervisor as your personal firewall. Since ASAv version 9.3.2-200, Cisco supports deploying ASAv using Kernel-based Virtual Machine (KVM). Thanks for the support of KVM hypervisor, ASAv can be deployed in a very easy manner on Linux and no mysterious hacks are needed anymore.

Unfortunately until a valid license file is installed, ASAv throughput is limited to 100 Kbps. So far I have not found a way how to bypass this limitation as Cisco does not provide any evaluation licence as they offer for their CSR100v IOS-XE router. I also found out that ASAv keeps rebooting when Qemu is started without enabled KVM option. It limits deployment of ASAv Qemu images on Linux/FreeBSD as KVM is available for these operation systems only. Windows users should download and install ASAv edition for VMware hypervisor.

Software Requirements
• Linux x86_64 with installed Qemu and KVM
• Cisco ASAv Virtual Appliance - asav932-200.qcow2 or later (you need a service contract to be able to download it)

HardwareRequirements
• CPU with VT-X or AMD-V hardware virtualization support
• 2GB RAM dedicated for ASAv virtual machine

1. ASAv Installation

Installation does not requires any special skills and takes only one reboot. Start the ASAv virtual machine installation with the command.

$ /usr/local/bin/qemu-system-x86_64 -m 2048M -boot c -hda ./asav932-200.qcow2 -enable-kvm

Copy a file coredump.cfg to disk0, if you want ASAv to redirect output to a serial port.

ciscoasa>enable
ciscoasa# copy disk0:/coredumpinfo/coredump.cfg disk0:/use_ttyS0

Now you can shutdown your ASAv virtual machine and run it with a serial port redirected to internal Qemu telnet server. Just start your ASAv appliance with an option -serial telnet:0.0.0.0:3333,server,nowait -display none and and issue the telnet command.

$ telnet localhost 3333

2. Running ASAv As Your Personal Firewall

In this part we are going to reconfigure our existing network infrastructure in order to connect ASAv virtual machine as a personal firewall. As we have already mentioned a throughput is limited to 100 kbps until you load a licence file to ASAv. For this reason it is sufficient to experiment with unlicensed ASAv appliance in your home lab but such as deployment is useless in your production network.

Picture 1 - Network Topology

There is a network diagram on the picture that shows connection between network interfaces of ASAv virtual machine and Linux host interfaces. In fact three virtual host interfaces have to be created on Linux - tap0, tap1 and tap2 before the ASAv appliance is started. You do not need to worry about actual commands as I will later share a script that take responsibility for changes in your network configuration.

Below is a list of ASAv network interfaces and their IP addresses assignment. The interfaces are connected with particular tap interfaces by Qemu itself thus no user action is required.

ASAV Interfaces IP Address Assignment
• GigabitEthernet0/0 (management) - 192.168.1.1/24
• GigabitEthernet0/1 (inside) - 192.168.2.1/24
• GigabitEthernet0/2 (outside) - 172.17.100.5/16

Linux Tap Interfaces Map Connection
• Interface tap0 - 192.168.1.2/24 is bridged with ASA Management interface
• Interface tap1 - 192.168.2.2/24 is bridged with ASA inside interface
• Interface tap1 - 172.17.100.5/16 is bridged with ASA outside interface

An outside ASAv interface is connected with an interface tap2 and bridged with a host network interface p3p1. Bridging is done by brctl command that comes with a bridge-utils package installed on Fedora Linux. Again, a script will take responsibility for creating a virtual bridge interface and bridging interfaces tap2 and p3p1 together.

In case of my home network, an interface p31p is connected with a straight Ethernet cable to the LAN interface of my SOHO router with an IP address 172.17.100.1/16. In fact, the router acts as a default gateway for all network hosts in my home network. No route to the network 182.168.1.0/24 is needed on that router as a NAT service is configured on the outside interface of ASAv appliance. NAT translates an IP addresses from the subnet 192.168.1.0/24 that is configured on the inside ASAv interface to a dynamic IP address assigned from DHCP server for the outside ASAv interface. The server is running on the SOHO router and it offers an IP address from a DHCP pool 172.17.0.0/16.

A start-up script start_asa.txt must be started with the root privileges. You only need to make changes according to your configuration and assign executable privileges to the script.

$ chmod +x start_asa.txt

3. ASAv Configuration

Telnet to ASAv Appliance with the command below and configure ASAv as following:

$ telnet localhost 3333

Hostname
ciscoasa> enable
ciscoasa# conf t
ciscoasa(config)# hostname ASAv

Creating Local User
ASAv(config)# username admin password cisco privilege 0

Securing Access to Console
ASAv(config)# aaa authentication serial console LOCAL

Securing Access to Privileged User Mode
ASAv(config)# enable password cisco

Securing SSH Access to VTY
ASAv(config)# aaa authentication ssh console LOCAL
ASAv(config)# ssh 192.168.1.2 255.255.255.255 management
ASAv(config)# ssh version 2

Management Interface
ASAv(config)# interface Management 0/0
ASAv(config-if)# management-only
ASAv(config-if)# nameif management
ASAv(config-if)# ip address 192.168.1.1 255.255.255.0
ASAv(config-if)# no shutdown
ASAv(config-if)# exit

LAN (Inside) Interface
ASAv(config)# interface GigabitEthernet 0/0
ASAv(config-if)# nameif inside
ASAv(config-if)# security-level 100
ASAv(config-if)# ip address 192.168.2.1 255.255.255.0
ASAv(config-if)# no shutdown
ASAv(config-if)# exit

WAN (Outside) Interface
ASAv(config-if)# interface gigabitEthernet 0/1
ASAv(config-if)# nameif outside
ASAv(config-if)# security-level 0
ASAv(config-if)# no shutdown
ASAv(config-if)# exit

Default Route and DNS Server
ASAv(config)# route outside 0.0.0.0 0.0.0.0 172.17.100.1
ASAv(config)# dns domain-lookup outside
ASAv(config)# dns name-server 8.8.8.8

NAT (PAT Overload)
ASAv(config)# object network my_inside_network
ASAv(config-network-object)# subnet 192.168.2.0 255.255.255.0
ASAv(config-network-object)# nat (inside,outside) dynamic interface
ASAv(config-network-object)# exit

Allowing ICMP Inspection
ASAv(config)# policy-map global_policy
ASAv(config-pmap)# class inspection_default
ASAv(config-pmap-c)# inspect icmp

References
https://maroskukan.wordpress.com/2015/01/20/up-and-running-with-asav/
https://community.gns3.com/thread/5359
https://www.youtube.com/watch?v=5WNxPJqQ-yk
https://www.fir3net.com/Firewalls/Cisco/how-to-configure-nat-of-asa-83.html

Cisco Encapsulated Remote SPAN (ERSPAN) feature allows to monitor traffic on one or more ports and send the monitored traffic to one or more destination ports. Traffic is encapsulated into GRE tunnel and routed via network to ERSPAN destination. Any device that supports ERSPAN can be used as ERSPAN destination. It might be another Cisco device or Linux with installed software that can decapsulate GRE traffic.

The goal of this article is to show methods and tools for decapsulation of ERSPAN traffic. For this purpose I have built simple lab that consists of a Cisco CSR 1000v router and two Linux boxes. Core Linux represents a network host and generates network traffic (ICMP) that is going to be monitored. It is connected to the port GigabitEthernet1 of the Cisco router. The router is configured to monitor traffic on the port Gi1 and it sends traffic encapsulated in GRE tunneling protocol to IP address 10.230.10.1. It is the IP address of the ERSPAN destination configured on Linux Security Union. Security Onion is a unique Linux distro for intrusion detection, network security monitoring, and log management based on Ubuntu however any other Linux distro can be used.

Picture 1 - ERSPAN Lab Topology

Below is an example of ERSPAN configuration on the CSR 1000v router. This is the source ERSPAN type and with configured rspan_id 1. The interface Gi1 is being monitored and the GRE traffic is sent to ERSPAN destination address IP 10.230.10.1.

CSR1000v# show running-config | b monitor
monitor session 1 type erspan-source
description ERSPAN to 10.230.10.1
source interface Gi1
destination
erspan-id 1
mtu 1464
ip address 10.230.10.1
origin ip address 10.230.10.2

1. Capturing ERSPAN Traffic with Wireshark

We are going to capture and analyze ERSPAN traffic with Wireshark packet sniffer. First configure IP address 10.230.10.1 on interface eth1 of the Linux Security Onion.

janosik@onion:~$ sudo su
root@onion# ip address add 10.230.10.1/24 dev eth1

Now use Wireshark to capture GRE traffic on Security Onion on its interface eth1 and ping the router IP address 192.168.1.2 from the Linux Core host (IP 192.168.1.1). If the source ERSPAN is properly configured on router, packets from the subnet 192.168.1.0/24 should appear in Wireshark output.

A closer look at the picture below reveals that the original packet ICMP packet (MAC header, IPv4 header and ICMP header) is now encapsulated as following.

MAC header + IPv4 header (10.230.10.2, 10.230.10.1) + GRE header (Protocol type ERSPAN) + ERPAN header + (original packet)

Picture 2 - Encapsulated GRE Traffic Captured on Interface Eth1

An original ICMP packet is encapsulated into GRE tunnel and the new outer MAC and IPv4 + GRE + ERSPAN headers are added to original packets. It allows encapsulated traffic to be forwarded through network to ERSPAN destination. However if we want software application such as IPS/IDS to analyze encapsulated packets, the outer L2 and L3 headers must be striped from packet. This can be done with tools such as RCDCAP which dissects packets from GRE tunnel.

2. Configuring GRE tunnel on ERSPAN Destination Device

If for some reason we do not want to install special software that dissects packets from GRE tunnel we can configure GRE tunnel on ERSPAN destination (Linux Security Onion) and let IDS to listen on a tunneled interface. Thanks to this configuration the outer MAC and IPv4 headers are stripped and do no appear in Wireshark output.

a) Load gre module to kernel

janosik@onion:~$ sudo su
root@onion# modprobe ip_gre

b) Choose receiving interface and assign IPv4 to it

root@onion# ip addr add 10.230.10.1/24 dev eth1

Set the MTU of the network interface that receives GRE packets larger than 1500 e.g. to 1900. Otherwise we are going to miss some bytes in larger packets.

root@onion# ip link set dev eth1 mtu 1900

c) Create virtual tunnel interface and associate it with IP previously configured on eth1 interface

root@onion# ip tunnel add mon0 mode gre local 10.230.10.1 ttl 8

d) Add IP address to interface mon0 which is not used for anything

root@onion# ip addr add 1.1.1.1/30 dev mon0

e) Change the state of mon0 device to up

root@onion# ip link set mon0 up

Again, generate some traffic in the subnet 192.168.1.0/24 and configure Wireshark to listen on interface mon0. Notice that the outer MAC and Ipv4 header are now stripped from the ICMP packet.

Picture 3 - Decapsulated Traffic Captured on Interface Eth1

3. Using RCDCAP for Decapsulating ERSPAN Traffic

RCDCAP is wrapper program that dissects the traffic and creates a virtual interface where the traffic is already decapsulated. I've compiled it from the source and created the Ubuntu package RCDCap-0.7.99-Linux for Ubuntu 15.04. Be aware that additional packages are needed to get it working.

janosik@onion:~$ sudo su
root@onion# apt-get install libboost-regex1.55.0

Use apt-get to install the packages below. If they are not available in a repository download them from here and install manually with dpkg -i command.

libboost-program-options1.48.0_1.48.0-3_amd64.deb
libboost-thread1.48.0_1.48.0-3_amd64.deb
libboost-system1.48.0_1.48.0-3_amd64.deb

root@onion# dpkg -i libboost-program-options1.48.0_1.48.0-3_amd64.deb libboost-thread1.48.0_1.48.0-3_amd64.deb libboost-system1.48.0_1.48.0-3_amd64.deb

Now we can install RCDCAP with the command.

root@onion# dpkg -i RCDCap-0.7.99-Linux.deb

Once RCDCAP is installed configure interface eth1 to prepare for capturing.

janosik@onion:~$ sudo su
root@onion# ip addr add dev eth1 10.230.10.1/24
root@onion# ip link set dev eth1 mtu 1900
root@onion# ip link set dev eth1 up

Start RCDCAP with the command below and let Wireshark to listen on interface mon1.

root@onion# rcdcap -i eth1 --erspan --tap-persist --tap-device mon1 --expression "host 10.230.10.1"

We can see that RCDCAP have dissected monitored traffic from GRE and only original MAC + IPv4 + ICMP headers and pyaload are presented in Wireshark output.

Picture 4 - Decapsulated Traffic Captured on Interface Mon1

End.

Reference:
http://packetpushers.net/erspan-new-favorite-packet-capturing-trick/
http://networkengineering.stackexchange.com/questions/3274/remote-sniffing-with-erspan-to-the-desktop

Have you ever been in that situation that you needed to apply the same configuration quickly on multiple Cisco routers? If yes, you probably wrote a script that connected to routers and sent appropriate IOS commands. One problem that you certainly had to solved was forcing your script to enter login credentials such as username and password. Moreover if you secured an access to privileged user mode with an enable secret command on your routers you had to tell the script how to enter that password as well.

All the issues I have mentioned above can be easily solved with Expect scripting language. Expect sends commands via telnet or ssh session as the human would. However encapsulating IOS commands to syntax recognized by Expect language every time you need to change routers' configuration seems to be not very comfortable. That is why public key authentication for Cisco routers can be handy.

Public key authentication allows you to log in to your routers using RSA key instead of a password. But firstly key-pair - public and private key must be generated and a public key copied into a config file of the router. Then you can connect to the router with your private key. A private key is the key that should be kept in secret and it is recommended to secure it with a password.

On Linux, ssh-keygen command can be used to generate RSA key-pair. The command below generates 4096 bit RSA key-pair without any user interaction and with a null password. Add the command in to your script if you want to automatize the process of generating your key-pair.

$ ssh-keygen -b 4096 -t rsa -f my_cisco_rsa -t rsa -N ''

Explanation:
-b number of bits in the key to create
-t type of the key
-f filename of the key file
-N password

Now we should have our RSA key-pair gecreated and we can start copying a content of the file my_cisco_rsa.pub that contains a public key into Cisco router configuration. But instead of copying an entire 4096 bits public key, Cisco offers an option to insert only a hash of your public key. This is definitely an advantage as copying a short hash string is less laborious than copying a whole public key. Anyway Cisco stores only a hash of the public key in its configuration even if you entered the entire public key.

So how can we find a hash of our public key? On Linux, enter the ssh-keygen command that we have used for generating the key-pair.

$ ssh-keygen -f my_cisco_rsa.pub -l
4096 5b:27:ba:1d:46:4c:32:1a:e5:b8:32:f9:4e:9e:bb:ae brezular@k55vm (RSA)

Obviously, our RSA public key is 4096 bits long and the hash of the key is: 5b:27:ba:1d:46:4c:32:1a:e5:b8:32:f9:4e:9e:bb:ae.

Add the hash to a router configuration as following.

cisco(config)#ip ssh pubkey-chain
cisco(conf-ssh-pubkey)#username admin
cisco(conf-ssh-pubkey-user)#key-hash ssh-rsa 5B27BA1D464C321AE5B832F94E9EBBAE

Assuming that your router contains configuration for ssh access to vty lines, you can now connect to the router using your private RSA key.

$ ssh -i my_cisco_rsa admin@ip_or_your_router

So far so good but you would probably like to automatize the process of deploying your public key on a remote Cisco router. Writing a script that can do this job for us is very likely a good idea, specially when you have many routers. In that case adding a key hash manually in to each router would be slow and not very efficient.

For this purpose I have written Bash script addkey.sh and Expect script addkey.tcl that works together and take care of deploying of your pub key on remote Cisco routers. The Bash script loops over IP addresses of your routers stored in a text file and send IP address as an argument to the Expect script together with login credentials. The Expect script establishes connection to a router using SSH and add a hash of your pub key into to a config file of the router . It also creates a new privilege user with privilege level 15. We will use this user to jump directly to a privileged user mode after the login to a router.

Parameters of the script are displayed below. You have to enter all the script parameters except of the last -h parameter.

Picture 1 - Bash Script Parameters

Testing Script on Cisco Routers

I have created a lab topology in GNS3 that consists of three routers running BGP protocol. The routers are Cisco 7206VXR emulated by Dynamips an running IOS C7200-ADVENTERPRISEK9-M, version 15.2(4)S2.

Picture 2 - GNS3 Lab Topology

In order to achieve a full bi-directional connectivity between lab routers and my Linux box I have done following.

Linux
I have created a tap interface tap0 and bridged it to the physical Ethernet interface p3p1 that connects my computer to my LAN home network. I have assigned an IP address 172.16.100.6/16 from the LAN subnet to a bridge interface br0 and created a static route pointing packets to the subnet 10.10.10.0/28 via IP address 172.16.100.200. This IP address is configured on interface fa3/0 of the router R3. Here are the appropriate commands of the iproute2 utility that I have used.

GNS3
I have created a cloud (server symbol in a topology) and added the interface tap0 interface to the cloud configuration. Now we can run our script with the command.

$ ./addkey.sh -f iplist -g addkey.tcl -i my_cisco_rsa.pub -u student -p ucebna -s ucebna -x admin -z cisco

Explanation:
-f path to file that contains list of the IP addresses of routers
-g path to Expect script
-i path to file that contains private RSA key
-u name of unprivileged (level 0) user that script is going to use to connect to router
-p password for unprivileged (level 0) user
-s password for access to enable mode of router
-x name of privileged user (level 15) who is going to be created by script
-z password for privileged (level 15) user

At this point we should have our routers configured for public key authentication. To test if it is working we are going to send several Cisco IOS command to the router R1. We will place the commands in to a text file commands-r1.txt and redirect a content of the file to the router over ssh session. The commands configure banner, public Google DNS server and BGP protocol authentication with the BGP peer R2 on the router R1.

$ ssh -i my_cisco_rsa admin@10.10.10.10 < commands-r1.txt

And we will do the same for a router R2 but with a file commands-r2.txt instead.

$ ssh -i my_cisco_rsa admin@10.10.10.6 < commands-r2.txt

As we can see all the configuration changes have been successfully added to R1 and R2 configuration.

End.

Reference
https://damn.technology/public-key-authentication-on-cisco-ios

Recently, I have been asked to find a way how to clone Linux machines running in a remote virtual lab. The machines have single disks, they all are accessible over SSH and configured with the same login credentials. The goal is to make identical copies of their disks, download the disks and rebuild machines locally in the virtual lab.

On Linux based systems, utility 'dd' is very often used to make identical copy of a disk. I have used this command together with 'ssh' and 'gzip' commands to copy and compress remote disks and send them on the fly to a local disk over SSH connection. For instance, the command below issued on a local machine copies a disk /dev/sda of a remote Linux machine with IP address 10.10.10.11 to a local disk:

$ ssh student@10.10.10.11 "/bin/dd if=/dev/sda | gzip -c" | dd of=disk.raw.gz

Explanation:
/dev/sda - disk located on remote machine
disk.raw.gz - gzip compressed copy of disk /dev/sda on local machine
gzip -c - send compressed file to stdout

I wrote a BASH script backup-images-1.0.sh that automates process of cloning disks of remote Linux machines. The script reads IP addresses from a file and uses credentials you provide as command-line arguments for SSH connection (options -u and -p). The utility 'sshpass' is used to enter password during establishing SSH connection. The benefit of using sshpass command is that a password can be provided as a command-line argument and it is obfuscated as string 'zzzz' in the output of 'ps' command. On the other hand password is still stored in a file ~/.bash_history or can be read in the output of 'history' command. For this reason I recommend to delete history with the commands history -c && history -w in the same terminal where you run the script.

Picture 1 - Bash Script Syntax

A user used for SSH connection must have assigned root privileges to be able read and copy an entire disk with dd command. For instance, if user 'student' is used for ssh connection, student must be added to /etc/sudoers file. Although a root account can be used for SSH connection as well, usually root login is not permitted in a ssh server configuration.

In case of a SSH user has no sufficient privileges to copy the disk with dd command or root login is not permitted on SSH server you can use an option -r that I added to the script. This option allows you to specify a password of the user root on remote machine as the command-line argument of the script. The root password is used by Expect code that is put inside the BASH script. Expect takes care of adding the dd command to /etc/sudoers for user specified with -u option. In fact, Expect is called only when you start the BASH script with option -r otherwise the script relies on an assumption that user specified with -u option has sufficient privileges to copy the entire remote disk.

Below is an example of line that Expect inserts in to /etc/sudoers on remote machine.

student ALL=(ALL) NOPASSWD: /bin/dd if=/dev/sda

Thank to the line, user student can run the command 'sudo /bin/dd if=/dev/sda' without being prompted for the password. Once copying of disks is finished, Expect code is run again. This time Expects replaces a file /etc/sudoers with its original version so the dd command is not available in /etc/sudoers anymore.

A script uses gzip utility to compress the raw copies of remote disks while they are sent over SSH tunnel to a local computer. Once the downloading of raw copies is finished, the script decompress gzip disks back to raw format. Finally, the script starts 'qemu-img' utility to convert copies of raw disks to virtual machine disk format specified by the option -c. This disk format type must be supported by qemu-img, such as qcow2, vmdk,vdi etc.

Testing

1. Cloning Disks of Linux Core Installed on VirtualBox Machines

I have installed three Core Linux on VirtualBox virtual machines and bridged their network interfaces together with a host Ethernet card. Then I have started the script on the host with the following command syntax:

$ ./backup-images-1.0.sh -c vmdk -d /dev/sda -f iplist -u root -p root -t 1

-c disks are converted to vmdk format
-d name of disks that are copied
-f path to a file that contains IP addresses of Linux machines that are copied
-u name of user used for ssh connection
-p password of user used for ssh connection to Linux machines
-t time interval - 1s for displaying logs to standard output

Here is the log file from the operation. At the end all three disks are stored on a local machine and we are able to create new machines VirtualBox machines with attached vmdk copies of the disks.

Picture 2 - Cloned Linux Core Disks

2. Cloning Physical Disk with Installed Kubuntu Linux

In a previous part we tested copying of the disks of VirtualBox guests with installed Linux Core. But instead of cloning disks of virtual machines we can instruct the script to copy physical disks of hardware machines with installed Linux OS. Disk copies of physical disks can be subsequently attached to a virtual machines in case of hardware machines virtualization is required.

For purpose of testing, I installed Kubuntu 14.04 on HP laptop. The motherboard of the laptop is occupied with UEFI firmware and hard disk contains EFI partition. Again we run BASH script with the same parameters:

$ ./backup-images-1.0.sh -c vmdk -d /dev/sda -f iplist -u root -p root -t 5

The physical disk inside the laptop is 180GB so copying takes some time. To test if cloning is successful we are going to attach a final vmdk copy of the disk /dev/sda to a VirtualBox machine. As UEFI is used instead of BIOS, it is important to enable EFI in virtual machine settings.

Picture 3 - Enabling EFI in VirtualBox Machine Settings

We have not discusses how to boot installed Kubuntu Linux. When a virtual machine is started and VirtualBox UEFI firmware cannot find bootloader it keeps sitting in UEFI interactive shell. That is why we must tell UEFI where to find a bootloader.

Select 'fs0:' device and move to the directory where the grubx64.efi loader is located. In my case it is in a path FS0:\EFI\ubuntu\. Type the command grubx64.efi and hit Enter.

Picture 4 - Locating Grub EFI Bootloader

To instruct Virtualbox to find bootloader grubx64.efi automatically during the boot of VM we need to create a startup.nsh file. This file contains path to bootloader. Start the shell then follow the example below.

Shell> FS0:
edit startup.nsh
\EFI\ubuntu\grubx64.efi
<ctrl-s>
<enter>
<ctrl-q>

Note: If you cannot boot from the disk you should check installed Kubuntu Linux with 'fsck' utility. Start your virtual machine and when the Grub menu appears, choose an option Advanced option for Ubuntu-> Recovery mode. Select an option Resume - resume normal boot. If there is a problem with your file system, fsck utility is going to check your disk.

Picture 5 - Boot Menu Options

The picture below shows Kubuntu Linux virtual machine after boot. The vmdk disk that is attached to this virtual machine is a copy of the physical disk /dev/sda downloaded from HP laptop.

Picture 6 - Kubuntu Virtual Machine

Reference
how-to-dd-a-remote-disk-using-ssh-on-local-machine-and-save-to-a-local-disk

The Core Linux is a small modular Linux distribution that provides only a command line interface and tools that allows you to build your own application extensions. Thanks to these extensions you can easily turn your Core installation to a custom appliance such as network host, router, switch, server. Moreover choosing the Core Linux as an operating system for your appliance significantly reduces the size of the appliance.

Two weeks ago I started to build a network host that can handle network traffic. I installed the latest 64 bit Linux Core 6.3 on VMware virtual disk and loaded Core with extensions that can generate traffic, measure bandwidth, route, forward and filter traffic. A list of the extensions, their purpose and configuration changes is mentioned here.

I share my own network host VMware disk in Linux Core download section. You can create a new virtual machine (VirtualBox, VMware Workstation/Player, Qemu) with the disk attached and use it in your GNS3 labs in order to simulate network host. The disk contains the following tcz extensions:

bash - 4.3.39(1) with patches up to 39
bash-completion - 2.1
d-itg - 2.8.1-r1023
hping3 - 3.0.0-alpha-1
iperf3 - 3.1b3
iproute2 - 3.14.0
iptables - 1.4.21
ipv6-3.16.6-tinycore64 - 3.16.6
libpcap - 1.7.4
mtr - 0.86
ncat - 6.40
netfilter-3.16.6-tinycore64
nmap - 6.40
openssh - 6.0p1
openssl-1.0.0
tcpdump - 4.7.4

Note:
If you want to use application which is not on the list, install appropriate extension with the command:

$ tce-load -wi your_extension.tcz

If the extension is not available in Tinycore public repository (HTTP/1.1 404) you have to create it by yourself. Once you have it ready, copy the files extension.tcz, extension.tcz.md5.txt and extension.tcz.dep to the directory /mnt/sda1/tce/optional/. You also need to update the list of after boot loaded extension - file /mnt/sda1/tce/onboot.lst. If you want to know more about a file architecture check this picture.

Two weeks ago I finished creating a network host based on Linux Core 6.3 installed on WMware x86-64 virtual machine. I loaded Core Linux with several network extensions that allows host to generate, measure, route network traffic and scan networks. I also wrote a short article that contains a list of loaded extension.

Then I went further with the project and my goal was to build L3 switch and router based on Core Linux 6.3 loaded with Open vSwitch, Quagga, Bird and Keepalived extension. Those are the right extensions that turn a network host to routing and switching appliance. Furthermore routing daemons Quagga and Bird and multilayer switch Open vSwitch are used in many large production networks so it is certainly worth to be familiar with them.

The R&S appliance I built can be used for learning networking on Linux, routing and switching. The appliance is available for download in Download section. Please be aware that it is only vmdk disk not the whole virtual machine. For this reason you have to create a virtual machine in your favorite virtualizer (Qemu, VirtualBox, VMware Player/Workstation) and then attach the disk to the virtual machine. As some users have troubles to do these steps I share a quick hint for VMware Workstation 10:

CTRL-N -> Custom (advanced) installation -> Hw compatibility - Workstation 10.0-> I will install OS later-> Other Linux 3.x kernel 64-bit-> I/O Controller Types - LSI Logic-> Virtual Disk Type - SCSI-> Use an existing virtual disk.

The virtual VMware appliance contains the following extensions:

openvswitch - 2.4.90
quagga - 0.99.24.1
bird - 1.5.0
keepalived - 1.2.19
bash - 4.3.39(1) with patches up to 39
bash-completion - 2.1
d-itg - 2.8.1-r1023
hping3 - 3.0.0-alpha-1
iperf3 - 3.1b3
iproute2 - 3.14.0
iptables - 1.4.21
ipv6-3.16.6-tinycore64 - 3.16.6
libpcap - 1.7.4
mtr - 0.86
ncat - 6.40
netfilter-3.16.6-tinycore64
nmap - 6.40
openssh - 6.0p1
openssl-1.0.0
tcpdump - 4.7.4

Note: If the application is needed and it is not on the list, it can be installed with the command:

$ tce-load -wi your_extension.tcz

In case the extension is not available in Tinycore public repository (HTTP/1.1 404) you have to built it by yourself.

For those who are interested in installation steps the whole process of extension installation is described in this article.

Here I share one of my lab based on my Linux Core L3 switch and router appliance for your inspiration.

End.