Sunday, 5 July 2015

A Little More VIRL


So I have spent a bit of time this week playing around with VIRL. I have trialed 3 instances:

  • local on my 8GB laptop in VMware
  • at work on an ESX, assigned 32GB
  • at home on my ESX - currently assigned 8GB but working on improving this
I think my takeaway points are:

Don't use VIRL for the NX-OS image!
I was pretty excited to do some NX-OS topologies but I found out pretty quickly that some of the technologies I wanted to play around with aren't support. Below shows the problems I had in trying to establish vPC.
After googling I realised that Layer 2 functionality is not supported in NX-OSv and there is no timeline for the features to be released. I don't think this is made very clear when VIRL is acquired.
Click here for a comprehensive list of what is available on NX-OS.

After this disappointment, I went back to switching and routing and was pretty happy with what I could do again. I tried out some various routing scenarios with multiple IGPs and VLANs. It worked very nicely with 32GB of memory.

I then tried to push it a little more to the limits, so I grew my network to something along the line of a service provider network. At this point I ran out of memory again. :( So I used the option of disabling some of the router from the configuration. See below the option to highlight nodes and click a box to exclude them from the simulation:

After I did this, the simulation launched without problem, with the two routers excluded. I thought this was pretty good, considering how many CSR routers I put into the network. You can see below on the right the routers that didn't launch are represented with an [ABSENT] tag next to them.


I guess at this point I'm still just feeling my way around, but would I buy it again? Considering how much I've spent on hardware, and with the current $50 off special making VIRL very cost effective comparatively. So yes, I despite some limitations, I think VIRL is a very good investment for anyone wanting to practice and trial network configurations.

Previous VIRL Post

Wednesday, 1 July 2015

DMVPN Part 2

Go to DMVPN Part 1

4. DMVPN Routing Configuration

So each router doesn't know about the other routers attached networks (in this case its the loopback addresses). The routing can be completed using either static routes.

Because  "ip nhrp map multicast" command was used on the spoke routers they can only broadcast hellos to the hub router, so OSPF becomes a hub and spoke configuration. This means the hub router must become the DR and using the OSPF broadcast network type must be used.

It should look like this:

Pretty cool.

My First-Run VIRL Review

I have been so slack in blogging lately, the truth is I've been a bit slack in my CCIE study. Though I have been sidetracked in learning a heap about Cisco UCS - but that was for work.

Anyway, I have embarked on a new adventure - which is VIRL. This stands for Virtual Internet Routing Lab. I love my hardware lab, but I just had to try this virtualisation method. Installing it was pretty easy, it downloads as an OVF which you deploy as either standalone on a PC/Mac or onto an ESX. I used VMware Player and installed it on my laptop.

Here's what it looks like:

This was great and all you have to do is click on the VMMaestro icon to fire up the software that allows you to place virtual routers and do all sorts of network configurations. However, I ran into this error a lot:


It generally happens when stopping a simulation and restarting it or another simulation. I'm not 100% sure, but it feels like it takes a bit of time to release the memory once a simulation is stopped. This simulation above was 6 IOSv routers - I didn't even bother trying to run CSR1000vs which apparently use up 3GB of memory.



So my first bit of advice is... don't run VIRL on a PC with only 8GB. Although 8GB is the minimum requirement, you may get frustrated quickly.

I've since moved my installation to an ESX server, assigning the VM 32GB... and this is seamless. I've been running through the tutorials and am really enjoying the features that are available that you wouldn't get from using the VMs directly in KVM or whatever... or from using hardware. These features are things like the AutoNetkit which allows you to very quickly deploy configurations across a large network. So you can setup your test environment much faster than if you were setting it up on hardware or standalone VMs. I'll show you a screenshot here of auto configuring EIGRP on a bunch of routers - but this is directly from the tutorial mentioned above.


And secondly, the views allow you to troubleshoot so quickly what is going on in the network. You can click on various different configs to highlight what you expect to see.

Below is the eBGP neighbour relationships highlighted... but you can see the options on the left.



I am going move my installation one more time to my home ESX so that I can use it in the evenings. It has 16GB which I'm hoping is sufficient. But watch this space for some more VIRL fun. =)

Thursday, 18 June 2015

DMVPN Part 1

So I briefly covered some points about DMVPN here from a night when I did a lab and wanted to remember some of it. I thought for my own sake I'd step back and really examine DMVPN. So back to the textbook.

DMVPN stands for "Dynamic Multipoint VPN". It is a way of creating dynamic VPNs for an organisation. This should remove the overhead of configuring individual VPNs. DMVPNs are ALWAYS setup in a hub & spoke configuration.

I've gone through the steps in the book using my home lab:

1. Basic Configuration of IP Addresses

Pretty easy... my routers are all connected to my switch and have 192.168.123.0/24 range IP addresses on their fast ethernet interfaces.

2. GRE Multipoint Tunnel configuration on all routers (for spoke-to-spoke connectivity).

This can be broken down further into two steps. Setup NHRP and setup mGRE - both of these are done under the tunnel interface.

An example of this is:

This is done on each router, however you don't have to do the nhrp map command to the hub router on the spoke routers. These are the commands underlined in red. They are not required on the hub router.
The authentication command is optional.
This can be verified using the following command:

The coolest thing about this is that we have two tunnels from the hub router to the spoke routers, but if the spoke routers decide to communicate, they will dynamically build a tunnel between them. Imagine in a DMVPN network, this is pretty useful.


Could do this all day!! It's so cool. However, the default operation of DMVPN is to send traffic as clear text. :O

3. Configure IPsec to Encrypt mGRE Tunnels

Apply IPsec to the configuration involves:
  1. Setting up the crypto isakmp policy
  2. Setting a key with the ip address 0.0.0.0 (because of the dynamic IP setting)
  3. Setting up a transform set
  4. Setting up an IPsec profile
  5. Applying the profile to the tunnel interface

Wednesday, 17 June 2015

OSPF Basics

Taking advantage of my serial ports, doing some OSPF.

There are two ways to setup OSPF:

  1. Under the interface using "ip ospf <process-id> area <area-id>"
  2. Under the routing process using the network command
If both are configured, the interface command supersedes the setting under the routing process. So for example if an interface is configured both ways with different areas, the area given under the interface will be the one used.

OSPF Cost = Reference/Bandwidth

New rack!

This post has nothing to do with my CCIE journey... but a bit about my home lab. I'm changing jobs this week after 6 years and the guys at work (knowing my CCIE lab and study) decided to buy me a rack as a farewell gift. *sob*

At first I thought assembling it was some sort of punishment for leaving:


Tossed up mounting it on the wall (it has a wall mount), putting it on wheels (it has wheels too!) but opted to keep it on my buffet just so I have fast easy access to re-cable and power the routers and switches as often as I want to.


Here is the back. I still haven't put on the side panels, the back or the front.


And here is the front:


I think technically the rack costs more than the equipment in it. I'm not sure I'll include its price in my CCIE lab setup since I didn't pay for it. :)

Monday, 15 June 2015

Serial, serial... :(

Having problems with my serial ports at the moment, I think one of the network modules I received last week has a hardware fault. I've tried unbelievable number of combinations, but whether its the DCE, DTE and in multiple different routers, whenever I bring up the port it takes a few seconds and then it throws a "Level 2 Watch Dog Timeout" error and reboots the router.

See exhibit A below :(
I guess you win some and lose some. $55 wasted.