LFNE GNS3 Appliances

This post will be a very short one, more like a note :)

Based on the LFNE Docker images (explained here https://ipnet.xyz/2023/11/lfne-linux-for-network-engineers) I’ve created the GNS3 Appliances for easy import into GNS3.

The GNS3 Appliances can be downloaded here https://github.com/yotis1982/lfne and imported into GNS3.

Have fun!

INE’s CCIE R&S v5 topology for EVE-NG using CSR1000v

In my previous blog post I’ve adapted the INE’s CCIE Routing and Switching topology to be used with EVE-NG using IOSv (or vIOS) L3 images for routers and L2 images for switches.

Following the promise in that blog post, I’ve adapted the same topology using Cisco CSR1000v images for routers and IOSv L2 images for switches. There isn’t much to say about this topology since mostly is matching the original INE’s one for routers (including the configuration files) and the major difference is the utilization of virtual switches.

Since we’re using virtual switches, the configuration files for switches are still different. I’ve adapted these ones to match the interface names of IOSv-L2:

Real Switches – vIOS-L2

Fa0/1  - Gi0/0 - SW1 only connection to bridge

Fa0/19 - Gi0/2
Fa0/20 - Gi0/3
Fa0/21 - Gi1/0
Fa0/22 - Gi1/1
Fa0/23 - Gi1/2
Fa0/24 - Gi1/3

For convenience, the switches topology looks like this in EVE-NG:

CCIE R&S V5 Switches

For routers, the interfaces stays the same since we’re using CSR1000v images.

Here is how the network topology looks like. No surprise here, just added for convenience:

INE CCIE R&S v5 topology with csr1000v

If you don’t have the CSR1000v image added to your installation of EVE-NG, please download it (Cisco.com is a good starting point) and add it following these How-to:
HowTo add Cisco Cloud Service Router (CSR1000V NG) Denali and Everest
or
HowTo add Cisco Cloud Service Router (CSR1000V) – for pre Denali or Everest images.

If you’re curious I’m using csr1000v-universalk9.03.12.03.S.154-2.S3-std image when testing for this lab.

Before sharing the download links, a word of advice.

It may be that CSR1000v images are more stable and support all features when compared with IOSv-L3, however this comes with a cost in term of resources. Each node has by default 3GB RAM assigned and I wouldn’t recommend trying to decrease it.

Once the nodes boot up, the actual used RAM will be less, but still you need more resources to use CSR1000v.
My recommendation for 10 routers using CSR1000v images would be at least 16GB RAM assigned to the EVE-NG virtual machine. The same if you’re using EVE-NG on a bare metal machine.

Last but not least, somebody asked me when I’m going to provide the same topology with 20 routers.
No need. You can extend the default topology with as many devices as you want. The modified configuration files for labs with 20 routers are already modified and present in the archive you download. Just add the missing R11 until R20 devices.

If you encounter errors that are critical, please let me know and I’ll try to correct them.

Download files:
EVE-NG-INE-CCIEv5-Topology-CSR1000v.zip
INE-CCIEv5-RS-Initial-Configuration-for-EVE-NG-CSR1000v.zip

Happy labbing and let me know if you find these materials useful!

INE’s CCIE R&S v5 topology for EVE-NG

The last days I was working on adapting INE‘s lab topology, most specific the CCIE Routing and Switching v5 one, to be used in EVE-NG.

In my opinion, INE offers some of the best training materials for Cisco and Juniper certifications. Along certification training you can find in their All Access Pass Subscription valuable learning materials for Network Automation, Security and Traffic Analysis (like Wireshark).
By the way I’m not affiliated with nor this post is the result of some sponsorship from INE. I just wanted to have the possibility to use their materials on using the entire topology, including the Switches, in EVE-NG.

I’ve picked Cisco‘s vIOS L3 and L2 images to support the topology in EVE-NG. You can argue that vIOS is a bit unstable and lacks some features, that CSR1000v images are better when combined with real Cisco switches and so on. Yes yes, all these are quite right, but I’m not here to debate about the best way to create a topology, rather a simple and sustainable one which works even for low end devices with less resources (CPU, RAM). Is no secret that vIOS will use less resources than CSR1000v images.

It brings me great happiness to let you know that I’ve succeeded in adapting not only the topology (not that hard honestly), but also the initial configuration files. The challenge lies in the fact that vIOS L2 images are build to support Ethernet ports in group of four, resulting in a slight different naming convention.

If you’ll check INE’s CCIE R&S v5 topology, the Cisco switches are using the Port from 19 to 24 to interconnect. On switch SW1, Port 1 is used to bridge the switching part to the routing one. You cannot replicate this exact port configuration scheme using vIOS L2 images.

I was forced to come with an alternative scheme, to map the original interface to the virtual ones and to adapt the configuration files.

This is what I came with:

INE CCIE R&S v5 switches

The interface mapping is as follows:

Real Switches – vIOS-L2

Fa0/1  - Gi0/0 - SW1 only connection to bridge

Fa0/19 - Gi0/2
Fa0/20 - Gi0/3
Fa0/21 - Gi1/0
Fa0/22 - Gi1/1
Fa0/23 - Gi1/2
Fa0/24 - Gi1/3

For the Routers is easy, since the interfaces are almost the same:

CSR1000v – vIOS-L3

Gi1 - Gi0/1

Here is how the network topology looks like:
INE CCIR R&S v5 Topology

We have 10 Routers using vIOS-L3 and 4 Switches using vIOS-L2. The connections between routers and switches are facilitated by the Net bridge.
10 routers should be sufficient for most of the labs. However if you need more, just add nodes and connect them to the Net bridge using the Gi0/1 interface.

As said previously, the configuration files have been adapted to match the interfaces listed above. I’ve tried my best not to have any errors, I also did some testing, everything looks to be fine. Most probably you’ll notice some errors at the copy / paste, but these are just cosmetic and related mostly to some proprietary CSR1000v commands or management interface which is not needed in EVE-NG. If you encounter errors that are critical, please let me know and I’ll try to correct them.

If somebody from INE’s team reads this post (that would be something :)) and consider inappropriate to share the modified initial configuration files, please let me know and I’ll take them down. They are derived from the public available ones on the CCIE R&S v5 Topology Diagrams & Initial Configurations page and do not contain any workbook information or somehow else related to INE’s training materials.

Download files:
INE-CCIEv5-RS-Topology-for-EVE-NG.zip
INE-CCIEv5-RS-Initial-Configuration-for-EVE-NG.zip

Happy labbing and let me know if you find these materials useful!

GNS3 1.2.1 installation on Ubuntu 14.04

As mentioned in an earlier post GNS3 is moving ahead fast. Currently at version 1.2.1 the GNS3 is looking great. Compared with the version 1.0 Beta 1 which I had installed, the 1.2.1 is not only more stable, but it has the Menu more clean and compact. For example now there is only one Preferences menu where you can adjust all your settings.

During the installation of 1.0 Beta 1 I made some notes in Evernote and it prove to be very useful as the installation was pretty messy. With 1.2.1 I did the same thing, but the installation was very smooth. Still, I said that if I made those notes maybe I should share them for those interested in a quick installation. A more complete guide can be found on GNS3 Community.

1. Download GNS3 1.2.1

Head over to http://www.gns3.com/, create and account and download the bundle archive for Linux.

If you for some reason you don’t want to create an account, you may download each package individually from https://github.com/GNS3

The following lines will assume that you have the bundle archive.

2. Install Ubuntu 14.04 dependencies

$ sudo apt-get install libpcap-dev uuid-dev libelf-dev cmake
$ sudo apt-get install python3-setuptools python3-pyqt4 python3-ws4py python3-netifaces python3-zmq python3-tornado
$ sudo apt-get install unzip 

3. Unzip the bundle archive

$ unzip GNS3-1.2.1.source.zip

You should see 5 packages in GNS3-1.2.1 folder:
dynamips-0.2.14.zip
gns3-server-1.2.1.zip
gns3-gui-1.2.1.zip
iouyap-0.95.zip
vpcs-0.6.zip

4. Install Dynamips

$ unzip dynamips-0.2.14.zip
$ cd dynamips-0.2.14
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install

To check if the correct version is install:

$ dynamips | grep version

You should see in the output 0.2.14

5. Install GNS3 Server

$ unzip gns3-server-1.2.1.zip
$ cd gns3-server-1.2.1
$ sudo python3 setup.py install

To check if the GNS3 Server is installed correctly:

$ gns3server

If you see some output other than an error, than you’re fine.

6. Install GNS3 GUI

$ unzip gns3-gui-1.2.1.zip
$ cd gns3-gui-1.2.1
$ sudo python3 setup.py install

To test if the installation is working:

$ gns3

You should see a graphical interface of GNS3 launched.

At this moment you have a working GNS3 environment if you want only want to test Cisco hardware emulators. I strongly recommend to continue and install also the rest of the components. Who knows when you’ll need them

7. Install IOUyap (Optional, if you will use IOU images)

$ unzip iouyap-0.95.zip
$ cd iouyap-0.95.zip
$ make
$ sudo make install

To test the installation:

$ iouyap -h

If you encounter an error, please check the [Update 1] section at the bottom of this article.

8. Install VPCS (Optional, if you want to use VirtualPC)

$ unzip vpcs-0.6.zip
$ cd vpcs-0.6/src
$ ./mk.sh 64
$ cp vpcs /usr/bin/

For the third line, the 64 represent 64bit, as my Ubuntu 14.04 is build on 64bit.
The values can be:
– 32 or i386 for 32bit OS
– 64 or amd64 for 64bit OS

Please be sure to use the correct one for your OS.

To test the VPCS:

$ vpcs

You should see a Virtual PC being launched. Leave the console with letter q.

9. Install VirtualBox (Optional, if you want to launch VMs)

Download the correct version for your system from https://www.virtualbox.org/wiki/Linux_Downloads. The following lines will assume an Ubuntu 14.04 64bit OS.

$ apt-get install dkms
$ dpkg -i virtualbox-4.3_4.3.20-96996~Ubuntu~raring_amd64.deb

You can also use the instructions at https://www.virtualbox.org/wiki/Linux_Downloads and go for an APT installation.The choice is yours.

10. Install Qemu (Optional, if you want to use qemu images)

$ sudo apt-get install qemu

11. Install IOU (Optional, if you want to use IOU images)

I’m not a legal matter expert, and the usage of IOU is sort of grey area. Because of this, I’m not going to cover this chapter.

You’re ready to go. Start the GNS3 GUI:

$ gns3

Some things to check before going live:

  • check in the menu Edit > Preferences to set your desired Paths (in General sections) and to check the paths for the binaries (dynamips, vpcs, iou, virtualbox…)
  • add the IOS, virtualbox vm, iou images
  • in case of Cisco hardware emulators don’t forget to find the IdlePC value (when you add the IOS image or later with the start of your first router with a certain image) otherwise your CPUs will cry.

If something does not work as described or you need help please let me know in Comments.

[Update 1]

If you get the following error during installation of iouyap:

GNS3-1.2.2.source/iouyap-0.95 $ make
gcc -g -DDEBUG -Wall -c -o iouyap.o iouyap.c
iouyap.c:40:23: fatal error: iniparser.h: No such file or directory
#include
^
compilation terminated.
make: *** [iouyap.o] Error 1

Try to install the iniparser as follows:

sudo apt-get install flex bison

then

cd /tmp
curl -L https://github.com/ndevilla/iniparser/archive/master.tar.gz | tar -xz
cd iniparser*
make

and finally iouyap

cd /tmp
curl -L https://github.com/GNS3/iouyap/archive/master.tar.gz | tar -xz
cd iouyap*
bison -ydv netmap_parse.y
flex netmap_scan.l
gcc -Wall *.c -I /tmp/iniparser*/src -L /tmp/iniparser* -o iouyap -liniparser -lpthread
strip --strip-unneeded iouyap
sudo mv iouyap /usr/local/bin

Thanks to mweisel @ forum.gns3.net for this update!

Cisco BGP soft-reconfiguration and received-routes relation

A while ago I received the following question:

“Why I’m not seeing the prefixes received from the BGP peer when using the show ip bgp neighbors x.x.x.x received-routes while the soft-reconfiguration inbound is not enabled?”

I must admit that I had to stop and think for a second before giving my response.

Simple BGP

For the above diagram I have a simple BGP configuration:

router bgp 65301
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 192.168.0.2 remote-as 65302
 neighbor 192.168.0.2 timers 5 15
 !
 address-family ipv4
  network 1.1.1.1 mask 255.255.255.255
  network 2.2.2.2 mask 255.255.255.255
  network 3.3.3.3 mask 255.255.255.255
  neighbor 192.168.0.2 activate
 exit-address-family
router bgp 65302
 bgp log-neighbor-changes
 neighbor 192.168.0.1 remote-as 65301
 neighbor 192.168.0.1 timers 5 15

Focus is on the secondary router. I’m trying to see what prefixes I receive from my BGP neighbor, so I rapidly hit the following command:

R2#sh ip bgp neighbors 192.168.0.1 received-routes
% Inbound soft reconfiguration not enabled on 192.168.0.1

OK, that’s not good. Am I missing the command? Let’s see:

R2#sh ip bgp neighbors 192.168.0.1 ?
  advertised-routes  Display the routes advertised to a BGP neighbor
  dampened-routes    Display the dampened routes received from neighbor (eBGP
                     peers only)
  flap-statistics    Display flap statistics of the routes learned from
                     neighbor (eBGP peers only)
  paths              Display AS paths learned from neighbor
  policy             Display neighbor polices per address-family
  received           Display information received from a BGP neighbor
  received-routes    Display the received routes from neighbor
  routes             Display routes learned from neighbor
  |                  Output modifiers

-> received-routes – Display the received routes from neighbor

OK, I know the soft-reconfiguration inbound is not enabled, but what has this to do with the fact that the command is not showing me what routes I receive from BGP neighbor?

Let’s recall what “soft-reconfiguration inbound” command actually does.

BGP soft-reconfiguration inbound
*Cisco BGP-4 Command and Configuration Handbook

According to the above explanation, if you have an inbound policy (like a route-map) applied to a BGP neighbor and you change that policy, you need to clear the BGP session before it take effect. This is the procedure without having “soft-reconfiguration inbound” configured. I remember it like this and most of the network engineers out there remember this behavior associated with the “soft-reconfiguration inbound” command.

Still, I just want to see what routes I received from BGP neighbor and according with “sh ip bgp neighbors 192.168.0.1 received-routes” description is the right command . I have no inbound policy on R2 for R1 BGP neighbor.

A less remembered fact about the “soft-reconfiguration inbound” command is that when added, the router begins to store updates from the specified neighbor. These updates are unmodified by any existing inbound policies so that the router can correctly apply the new policies when soft reconfiguration is triggered.

Where are these updates stored?

In the BGP Adj-RIB-in (Adjacent Routing Information Base, Incoming) table. So, what the “received-routes” command does actually is looking in the BGP Adj-RIB-in table for the received routes from the BGP neighbor. I consider that the “received-routes” command has an ambiguous explanation leading to confusion.

When “soft-reconfiguration inbound” is not present, the BGP router does not store anything in Adj-RIB-in. Rather it process the update and discard the Adj-RIB-in table, but not before adding the information in the Loc-RIB (Local Routing Information Base) table. Knowing these facts of course the BGP router returns an error when trying to check the received prefixes using the “received-routes” command.

To check actually what’s received from BGP peer and stored in the Loc-RIB (after being processed by inbound policies) use only the “routes” parameter in the command:

R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *>  3.3.3.3/32       192.168.0.1              0             0 65301 i

Total number of prefixes 3

-> routes – Display routes learned from neighbor

The output is what exists in the Loc-RIB table, after processed by the inbound policy.

Let me show you an example of the above explanation.

I’ll apply the “soft-reconfiguration inbound” first:

R2(config-router)#neighbor 192.168.0.1 soft-reconfiguration inbound

Now I’ll check again the received routes:

R2#sh ip bgp neighbors 192.168.0.1 received-routes  | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *>  3.3.3.3/32       192.168.0.1              0             0 65301 i

Total number of prefixes 3

OK, so I have three prefixes, reflected in the Adj-RIB-in table.
Checking next the Loc-RIB tables (so the routes installed after being processed by inbound policies):

R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *>  3.3.3.3/32       192.168.0.1              0             0 65301 i

Total number of prefixes 3

The Adj-RIB-in and Loc-RIB tables are identical.

Now, I’ll apply an inbound policy that will filter the 3.3.3.3 prefix.

R2(config)#ip prefix-list LIST permit 3.3.3.3/32
R2(config)#route-map INBOUND deny 10
R2(config-route-map)#match ip address prefix-list LIST
R2(config-route-map)#route-map INBOUND permit 1000
R2(config-route-map)#router bgp 65302
R2(config-router)#neighbor 192.168.0.1 route-map INBOUND in

OK, we have the “soft-reconfiguration inbound” in place, so the inbound policies should be applied automatically denying the 3.3.3.3 prefix.

R2#sh ip bgp neighbors 192.168.0.1 received-routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *   3.3.3.3/32       192.168.0.1              0             0 65301 i

The above output is what we receive from BGP peer. Notice that the 3.3.3.3 prefix is still there, in the Adj-RIB-in table, as the inbound policies are not applied yet. The only visible change is the missing > sign (best).

R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i

Now we can see that the inbound policy is working fine as the 3.3.3.3 prefix is not installed in the Loc-RIB table. This is also the explanation why the > (best) sign was missing from the 3.3.3.3 prefix in Adj-RIB-in.

I hope you understood the logic behind the confusion which these commands “received-routes” and “routes” and their explanation in IOS is creates.

Please let me know in Comments if you have any questions.