Category Archives: Labbing with Dynamips

CML, VIRL or GNS3?

Cisco have confused me a little in the way they have brought their simulator to market. First it was VIRL and free, then CML was announced and the name change blamed on marketing. Now we have both. Here is a birds eye view of each for reference. I’ve also included GNS3 as it is worth considering if you’re in the market for an emulation tool.

VIRL

  • Part of the /dev/innovate program at Cisco
  • In Beta at the time of writing
  • Community supported
  • Runs on Linux KVM Hypervisor / OpenStack frontend
    • This can be installed bare metal or run via VMWare Fusion / Workstation / Player etc
  • Local hardware model (laptop / desktop)
  • Supports IOS, IOS-XE, IOS-XR and NX-OS
  • No Layer 2
  • Annual Licence either Academic or Personal ($80 or $200)
  • Capped at 15 nodes

CML

  • Corporate Edition
  • TAC Supported
  • Client / Server Model
  • IOSv only today
  • NXOS support roadmapped
  • Heavy server requirements
    • Min: 4 Core CPU / 16 GB RAM for basic 15 node limit
    • 16 Core CPU / 128 GB RAM for full 50 nodes
  • Server runs Ubuntu image
  • Java Client (oh Cisco, why do you try my patience so?)
  • $13,000 Base Install (15 node limit)
  • 5% discount for 50 nodes, 10% for 100
  • More pricing detail and other useful information here

All-in-One Virtual Machine

  • Free
  • Limited version of VIRL
  • 3 Node Development Environment for the Open Network Environment Platform Kit (onePK)
  • Designed to allow would-be app writers to develop and test their Apps

GNS3

  • Free
  • Community Supported via the GNS3 Jungle
  • Multi-Vendor – Cisco, Juniper, HP, Arista, Citrix and Brocade
  • L2 Supported using Cisco L2IOU Images (native on Linux / Solaris only, VMs on Windows / Mac)
    • Although features relying on L3 Hardware such as  L3 Etherchannel, ISL trunks, DHCP snooping, Private VLAN, SPAN/RSPAN/ERSPAN, Port-security, Voice VLANs, MLS QoS and QinQ won’t work
  • Supports any Cisco platforms available as a virtual machine using VitualBox or Qemu

 

 

Arrival of the Camel (Cisco Modelling Labs)

A horse designed by a committee?

A horse designed by a committee?

My Account Manager kindly sent me this link: www.cisco.com/go/cml this morning. So VIRL CML is almost here. Most of what the site said is positive, Cisco has finally listened to its customers and produced an official modelling tool. Sure, it would be better if it could run standalone on my laptop for study on the move. The client server model should offer rock solid performance provided I have 2GB of RAM and 1GB of storage on my laptop, which I do and most modern machines will too. The server requirements aren’t to be sniffed at – 128GB of RAM! I assume that is for those who have purchased the L-CML-CE-100N= licence (increments of 100 licences on top of the base 10+5). The docs do say to visit the page I linked above to determine your memory requirements although I couldn’t find where to do that.

Since it is used in a virtual environment any hardware-related functionality, including Layer 2 functions such as Spanning Tree Protocol, are not currently supported.

This sentence doesn’t make a lot of sense. I could imagine them saying that UDLD isn’t supported for example, but surely STP is just a software feature that happens to run at layer 2? At any rate, I’d rather a rock solid release which is missing features than a feature and bug rich release. Hopefully switches are coming to a camel near you soon!

Intro to DMVPN

Although this has been well blogged before, as we’ll be rolling DMVPN out where I work I’d like to record the steps I took to configure and verify a working example in GNS3.

Software

The first hurdle I came across is that the image I’d upgraded my virtual Cisco 3725s to (
c3725-adventerprisek9-mz124-25.bin, in order to support EIGRP for IPv6) doesn’t have everything you need for DMVPN. Although it seems to be possible to get things working, the ‘show dmvpn’ command in missing. I rolled back to c3725-adventerprisek9-mz.124-15.T14.bin and all was well.

Lab

Here is a screenshot of my GNS3 topology. Linknets between routers are shown in green, client networks in dark blue. I’ve included a box showing the multipoint GRE tunnel peers in light blue.

Screen Shot 2014-02-24 at 11.33.29

Base Config

I’ve attached full configs to the post. Prior to configuring DMVPN I set up OSPF on all routers. The intention here is to mimic each sites’ Internet connection. I probably should have used BGP or a static route to 0.0.0.0/0 via R5 on each router but at this stage I simply wanted all routers to be aware of all green subnets so that the mGRE tunnel would come up.

interface FastEthernet0/0
 description R1
 ip address 192.168.15.2 255.255.255.252
!
interface FastEthernet0/1
 description R2
 ip address 192.168.25.2 255.255.255.252
!
interface FastEthernet1/0
 description R3
 ip address 192.168.35.2 255.255.255.252
!
interface FastEthernet2/0
 description R4
 ip address 192.168.45.2 255.255.255.252
!
router ospf 100
 router-id 5.5.5.5
 network 0.0.0.0 255.255.255.255 area 0
 default-information originate
!
ip route 0.0.0.0 0.0.0.0 Null0

A sister config was added to each router (without the default-information originate), lighting up the protocol on fa 0/0 only, that is matching the local green subnet. A quick look at the OSPF entires in R1s routing table shows that we’re ready:

R1#show ip route ospf
192.168.45.0/30 is subnetted, 1 subnets
O 192.168.45.0 [110/11] via 192.168.15.2, 01:47:25, FastEthernet0/0
192.168.25.0/30 is subnetted, 1 subnets
O 192.168.25.0 [110/20] via 192.168.15.2, 01:47:25, FastEthernet0/0
192.168.35.0/30 is subnetted, 1 subnets
O 192.168.35.0 [110/11] via 192.168.15.2, 01:47:25, FastEthernet0/0
O*E2 0.0.0.0/0 [110/1] via 192.168.15.2, 01:47:25, FastEthernet0/0

Multipoint GRE Tunnel

I’ve selected 172.16.0.0/24 for my tunnel interfaces. The hub and all spokes will need a logical interface in this subnet to act as the local tunnel ingress/egress. Each router gets a config like this, the example here being R1. Note that there is no tunnel destination on any router.

interface Tunnel0
 ip address 172.16.0.1 255.255.255.0
 tunnel source 192.168.15.1
 tunnel mode gre multipoint

R2 would have a tunnel source of 192.168.25.1 etc.

The multipoint GRE tunnel is treated like a Non Broadcast Multi Access (NBMA) network, much like point-to-multipoint frame-relay.

NHRP

The point of DMVPN is that any spoke should be able to bring up a tunnel to any other spoke on demand. We need a mechanism to define our hub router, and for spoke routers to be able to resolve the physical IP address in use by another spoke, enter Next Hop Resolution Protocol. Hub routers – NHRP clients – query the spoke router or Next Hop Server (NHS) to learn the address of another hub router with which they need to bring up a tunnel. It is notable that although each router in the topology has an interface in 172.16.0.0/24, this network is not known by R5 (my ‘Internet’ router). Instead, NHRP maps interfaces in this subnets to real interfaces in ‘globally routable’ subnets (inverted commas as I’ve used RFC1918 address in this example).

There a four commands needed to configure NHRP, although only two are used on the hub.

The ‘ip nhrp network-id’ must be the same across the DMVPN instance; it is quite possible and sometimes desirable to run multiple concurrent DMVPN overlays. For this lab, one is enough.

The ‘ip nhrp map multicast’ command sets up a mapping so that our NBMA network can process multicast and unknown unicast packets. We then have two options:

R1(config-if)#ip nhrp map multicast ?
  A.B.C.D  IP NBMA address
  dynamic  Dynamically learn destinations from client registrations on hub

On a spoke, we enter the IP NBMA address of our hub so that broadcast and unknown unicast traffic is sent there. We need to do that so that we can run an IGP over our mGRE network later. In my example that would be 192.168.15.1. On our hub we use the dynamic keyword.

Spokes need an additional map entry to link the hub’s tunnel address to its physical address, ‘ip nhrp map 172.16.0.1 192.168.15.1’ in our example.

Finally, for each spoke we need to define its NHS using the ‘ip nhrp nhs 172.16.0.1’ commend

Bringing it all together, to define our hub we add two commands to Tun0 on R1:

interface Tunnel0
 ip nhrp map multicast dynamic
 ip nhrp network-id 1

To define a spoke, we add four commends to Tun0 on R2, R3 and R4:

interface Tunnel0
 ip nhrp map 172.16.0.1 192.168.15.1
 ip nhrp map multicast 192.168.15.1
 ip nhrp network-id 1
 ip nhrp nhs 172.16.0.1

Dynamic MVPN

Like many things, DMVPN relies on a sensible routing table on each router. Here is the logical topology:

DMVPN

 

We need each router to have routes to the other routers’ client networks. EIGRP lends itself well to this. We configure it to match 172.16.0.0/24 on each router, as well as the local client networks. We’ll make the client interfaces passive to stop our routers peering with anything downstream. Finally we’ll need to tweak the defaults on the hub so that:

* split-horizon doesn’t prevent us advertising subnets back out to the other spokes
* we advertise the next hop IP as that of the originating router

Here is R1’s eigrp config, the only change on the other routers is to match their local client networks as they all use the same local physical interfaces in my lab.

router eigrp 1
 passive-interface FastEthernet0/1
 network 10.10.10.0 0.0.0.255
 network 172.16.0.0 0.0.0.255
 no auto-summary

On R1 we also add:

interface Tunnel0
! ip address 172.16.0.1 255.255.255.0
 no ip next-hop-self eigrp 1
 no ip split-horizon eigrp 1

Verification

First, let’s check the routing – each hub and spoke should know about all the other client networks via the mGRE tunnel:

R1#show ip route eigrp 
     20.0.0.0/24 is subnetted, 1 subnets
D       20.20.20.0 [90/297270016] via 172.16.0.2, 02:58:14, Tunnel0
     40.0.0.0/30 is subnetted, 1 subnets
D       40.40.40.252 [90/297270016] via 172.16.0.4, 02:58:16, Tunnel0
     30.0.0.0/24 is subnetted, 1 subnets
D       30.30.30.0 [90/297270016] via 172.16.0.3, 02:58:16, Tunnel0

R4#show ip route eigrp 
     20.0.0.0/24 is subnetted, 1 subnets
D       20.20.20.0 [90/310070016] via 172.16.0.2, 02:58:06, Tunnel0
     10.0.0.0/24 is subnetted, 1 subnets
D       10.10.10.0 [90/297270016] via 172.16.0.1, 02:58:06, Tunnel0
     30.0.0.0/24 is subnetted, 1 subnets
D       30.30.30.0 [90/310070016] via 172.16.0.3, 02:58:06, Tunnel0

On the hub, we should see our three peers:

R1#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
	N - NATed, L - Local, X - No Socket
	# Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:3, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1    192.168.25.1      172.16.0.2    UP    never D    
     1    192.168.35.1      172.16.0.3    UP    never D    
     1    192.168.45.1      172.16.0.4    UP    never D

On each spoke, we’ll just see the hub:

R4#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
	N - NATed, L - Local, X - No Socket
	# Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Spoke, NHRP Peers:1, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1    192.168.15.1      172.16.0.1    UP 02:56:54 S

Now, let’s try and ping 30.30.30.254 (R3’s client interface) from 40.40.40.254 (R4’s client interface):

R4#ping 30.30.30.254 source fa 0/1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 30.30.30.254, timeout is 2 seconds:
Packet sent with a source address of 40.40.40.254 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/34/64 ms

Great, it worked. You can see that the dynamic tunnel has come up:

R4#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
	N - NATed, L - Local, X - No Socket
	# Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Spoke, NHRP Peers:2, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1    192.168.15.1      172.16.0.1    UP 03:00:22 S    
     1    192.168.35.1      172.16.0.3    UP    never D

I’ve uploaded a packet capture taken during the above test (on the R4-R5 link) to cloudshark.

Click on that link and you’ll see the capture filtered to NHRP traffic only. Note that packets 16 and 19 flow via the hub, but 20 and 21 are spoke-to-spoke. If you open up the NHRP Mandatory Part in packet 16 you’ll see that the source and destination protocol addresses are the mGRE tunnel endpoints and the source NBMA address is the physical interface of the router.

Screen Shot 2014-02-24 at 13.17.08

For packet 19 the protocol addresses are reversed (as expected for a reply) but now the source NBMA address is that of R3. Looking at the IP header confirms that this packet came from R1.Screen Shot 2014-02-24 at 13.32.05

In packet 20, NHRP provides R4 with R3’s physical address:

 

Screen Shot 2014-02-24 at 13.35.39

In packet 21, R4 provides R3 with its physical address.Screen Shot 2014-02-24 at 13.36.12

In packets 20 and 21, open the client information entry section to see that NHRP has returned 192.168.35.1, the physical address of R3 and endpoint for our dynamic, spoke-to-spoke tunnel.

Finally, let’s have a look at the pings. The first thing I should point out is that we are tunnelling the traffic, so there are two IP headers. In real life I would drop the IP MTU on each Tu interface to allow for the GRE encapsulation and extra IP header, plus any crypto.

Packet 15’s outer IP headers have source and destination physical addresses of R4 and R1. The inner headers are the local client subnets foreach router. Screen Shot 2014-02-24 at 13.47.35This continues until packet 22 (right after NHRP resolved the true address). From this point, the traffic is direct. Note that in this case, the request went via R1, but the reply came direct as the spoke-to-spoke tunnel had come up.

Screen Shot 2014-02-24 at 13.48.41

 Summary

In this post I’ve described and implemented a simple (crypto-free) DMVPN topology. I may expand on this in future to add encryption.

Update: I’ve covered how to add encryption here.

Site-to-site IPSec VPN through NAT

This post follows on from the first in this series and looks at how to modify the config if there is NAT along the way as well as reviewing a couple of the verification commands.

I’ve attached the full configs here.

Network Diagram

IPSec with NAT

Premise

A branch office with an ADSL connection would like to access corporate and local resources without running a local client on office machines. Split tunnelling is not required, all traffic must be routed back up to the corporate HQ. Only one static IP has been provided by the ADSL ISP.

Config

We’ll need to port forward UDP 500 (IKE) so that our corporate ASA can connect to the branch ASA. On the ADSL router we use the following NAT rules:

ip nat inside source list LAN interface FastEthernet0/0 overload
ip nat inside source static udp 192.168.1.1 500 interface FastEthernet0/0 500

You’ll see I’ve moved the B-End IP of the IPSec tunnel to the ADSL router so the A-End config doesn’t change. All I need to do is renumber the blue linknet to my chosen RFC1918 subnet of 192.168.1.0/24 and give my ASA a new default route matching the ADSL routers interface and all is well.

Testing

One thing which has bitten me in the past is that an IPSec tunnel won’t come up until you send some traffic down it. Since I’m doing this in GNS3 and VPCs, I’ll open up my crypto-map to allow ICMP so that I can bring up the tunnel with some pings.

A-END

access-list OUTSIDE_CRYPTOMAP_10 extended permit icmp any 10.1.0.0 255.255.255.0

B-END

access-list OUTSIDE_CRYPTOMAP_10 extended permit icmp 10.1.0.0 255.255.225.0 any

I also brought up a loopback with ip 8.8.8.8 on R1, to give my host on the otherside of the VPN something to ping. Finally I should say that I’m running OSPF on the two routers either side of the ‘public internet’ cloud, in order that the IPSec Peers have a route to either other.

First I had a look to see if my IPSec SA had come up:

A# show crypto ipsec sa

There are no ipsec sas

Hmm.

VPCS[1]> ping 8.8.8.8
8.8.8.8 icmp_seq=1 timeout
8.8.8.8 icmp_seq=2 ttl=255 time=60.482 ms
8.8.8.8 icmp_seq=3 ttl=255 time=53.498 ms
8.8.8.8 icmp_seq=4 ttl=255 time=55.094 ms
8.8.8.8 icmp_seq=5 ttl=255 time=47.397 ms

IPSec SA Verification

After bringing up the tunnel by pinging 8.8.8.8 from a host behind the B-END ASA, I was able toverify it (apart from the ICMP Echo Replies I got) as follows:

A# show crypto ipsec sa
interface: outside
    Crypto map tag: outside_map, seq num: 10, local addr: 192.0.2.6

      access-list OUTSIDE_CRYPTOMAP_10 extended permit ip any 10.1.0.0 255.255.255.0 
      local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (10.1.0.0/255.255.255.0/0/0)
      current_peer: 192.0.2.129

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 192.0.2.6/500, remote crypto endpt.: 192.0.2.129/500
      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: C7F1AEC5
      current inbound spi : 9DE630E8

    inbound esp sas:
      spi: 0x9DE630E8 (2649108712)
         transform: esp-aes-256 esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 45056, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4055039/28776)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x0000001F
    outbound esp sas:
      spi: 0xC7F1AEC5 (3354504901)
         transform: esp-aes-256 esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 45056, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4193279/28776)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x00000001

A#

Here is how the B-END sees things:

B# show crypto ipsec sa                  
interface: outside
    Crypto map tag: outside_map, seq num: 10, local addr: 192.168.1.1

      access-list OUTSIDE_CRYPTOMAP_10 extended permit ip 10.1.0.0 255.255.255.0 any 
      local ident (addr/mask/prot/port): (10.1.0.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      current_peer: 192.0.2.6

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 192.168.1.1/500, remote crypto endpt.: 192.0.2.6/500
      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: 8E827434
      current inbound spi : 8471E0F8

    inbound esp sas:
      spi: 0x8471E0F8 (2222055672)
         transform: esp-aes-256 esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 4096, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4147198/27959)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x0007FFFF
    outbound esp sas:
      spi: 0x8E827434 (2390914100)
         transform: esp-aes-256 esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, }
         slot: 0, conn_id: 4096, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4285438/27959)
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x00000001

B#

You can also check out the IKEV2 SAs like this:

A# show crypto ikev2 sa

IKEv2 SAs:

Session-id:9, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id                 Local                Remote     Status         Role
 89722291         192.0.2.6/500       192.0.2.129/500      READY    RESPONDER
      Encr: AES-CBC, keysize: 256, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK 
      Life/Active Time: 86400/3606 sec
Child sa: local selector  0.0.0.0/0 - 255.255.255.255/65535
          remote selector 10.1.0.0/0 - 10.1.0.255/65535
          ESP spi in/out: 0xa8d47b04/0xfddbc217

 

B# show crypto ikev2 sa

IKEv2 SAs:

Session-id:9, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id                 Local                Remote     Status         Role
 77759211       192.168.1.1/500         192.0.2.6/500      READY    INITIATOR
      Encr: AES-CBC, keysize: 256, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK 
      Life/Active Time: 86400/3526 sec
Child sa: local selector  10.1.0.0/0 - 10.1.0.255/65535
          remote selector 0.0.0.0/0 - 255.255.255.255/65535
          ESP spi in/out: 0xfddbc217/0xa8d47b04

NAT-T

By default, an ASA will encapsulate both IKEV2 negotiation and the IPSec encrypted packets in UDP 500. If you want to use NAT-T and encapsulate the IPSec packets in UDP 4500 then oort forward UDP 4500 on the NAT router and enable NAT-T on the each ASA:

NATRouter(config)# ip nat inside source static udp 192.168.1.1 4500 interface FastEthernet0/0 4500
ASA(config)# crypto isakmp nat-traversal

ASA 8.4 on Mac OSX 10.8

Like many before me I wanted to emulate an ASA in my GNS3 environment. I am a Mac users and found this to be tricky so will post the steps I took to get it working here. Having done this, I was able to add a couple of ASAs to a topology and fire them up. I should add that they take a while to boot up! You’ll also need to add licences to the ASA, although that isn’t OSX specific.

QEMU

Unlike other versions, the OSX GNS3 package does not come with QEMU bundled. Apparently this will change in the next release but for now, we need to download and install the OSX build. This is pretty easy as the package comes with an install script, but I found I did need to fix the file permissions in /usr/local/bin.

First, download the QEMU built for OSX. Then unpack the tarball (tar zxvf QEMU-0.11.0-GNS3-OSX.tar). Finally, run the script:

./Qinstall
Making Directrories - if directories exist you may see errors, which can safely be ignored.
Please supply elevated credentials.
mkdir: /usr/local/: File exists
mkdir: /usr/local/bin/: File exists
Making /usr/local/bin directory...
Making /usr/local/share directory...
Copying files to their proper locations...
All done. Have fun with your JunOS patched version of QEMU!

I already had /usr/local/bin as it was created when I installed Wireshark. I found that the perms were 600 on /usr/local/bin and needed to adjust these so that my user could run them:

sudo chmod 755 /usr/local/bin

The files which the script placed in that directory were:

qemu
qemu-img
qemu-system-i386

We point our paths to the bottom two as shown:

QEMU Settings

Splitting the ASA binary

In order for QEMU to be able to boot the ASA software, we need to break it into two files:

asa842-vmlinuz
asa842-initrd.gz

Fortunately this is made infinitely simpler with the repack script, available here. I downloaded ASA asa842-k8.bin from the Cisco website. I did try some newer releases but found the script doesn’t accept them. For now I’m happy with 8.4. As I have access to a linux box, I ran the script on there. Version 4 of the script has a few dependancies (mkisofs/syslinux/cdrtools) as it produces an ISO among other things (which I didn’t need personally). I installed them anyway just to be sure the script would run cleanly.

[how@fantastic ~]$ ./repack.v4.sh asa845-smp-k8.bin
Repack script version: 4
which: no mkisofs in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/how/bin)
no syslinux/cdrtools - ISO creation skipped
Version is not supported!

So, I su’d up (thanks Barney) and ran yum install mkisofs. I also switched to asas842-k8.bin:

[root@fantastic ~]# ./repack.v4.sh asa842-k8.bin
Repack script version: 4
no syslinux/cdrtools - ISO creation skipped

Okay, one yum install syslinux later..

[root@fantastic ~]# ./repack.v4.sh asa842-k8.bin
Repack script version: 4
Detected syslinux/cdrtools - ISO will be created

This created the following files:

asa842-vmlinuz
asa842-initrd.gz
asa842-initrd-original
asa.iso

We are interested in the first two and configure the ASA Specific Settings in GNS3 as follows:

ASA GNS3 Settings

Final GNS3 configuration

I read that the Kernel settings are sometimes distributed with the image but I couldn’t find them. I got these from number of sources. If anyone can tell me how to calculate them I’ll be most grateful. The screenshot above shows the config, but for you to cut and paste.

Qemu Options:

-vnc none -vga none -m 1024 -icount auto -hdachs 980,16,32

Kernel:

-append ide_generic.probe_mask=0x01 ide_core.chs=0.0:980,16,32 auto nousb console=ttyS0,9600 bigphysarea=65536

This all done, I tested the settings. Don’t be concerned by the pemu error, it wasn’t ported to OSX apparently and is not needed for ASA emulation anyway.

test_settings

Links

Here are some of the resources I used to get this working:

http://www.brainbump.net/GNS3-How-to-emulate-ASA-8.4-2-under-QEMU
http://blog.ciscoinferno.net/gns3-and-cisco-asa-8-4-part-1
http://www.network-blog.com/ittech/post/2012/02/06/Configure-Cisco-ASA-firewall-version-84-on-GNS3.aspx

Recruitment 2: Advertising a job

In this second post in this series I’ll record my thoughts on recruiting. I work in Data Networking but hopefully some of the principals will apply in other fields.

The job specification

  • Think about the job that needs doing and weigh this against the skills the sort of candidate you are trying to attract could reasonably have. If somebody leaves who built up a bespoke skillset over many years you probably won’t be able to replace them with one person. You may get somebody with a sufficient subset of those skills though.
  • It is vital that the job you advertise is the one you need doing. It sounds obvious but only ask for the skills and experience you need.
  • Research what other organisations are paying for similar roles.

The job advert

If you get this right you’ll attract the right candidates. The job advert should be:

  • Accurate
  • Attractive
  • Clear
  • Concise
  • Visible

On this last point, getting your advert out to the right people is quite an art. You may find your organisation has a policy on this. Don’t be afraid to challenge it if you are having trouble recruiting though, but make your case carefully and bring evidence.

Reviewing Applications

If you are fortunate to get a lot of applications you’ll need to allocate time for the whole panel to review them. There is a huge man-hour cost to this, which is one reason why the specification and advert are some important. Don’t schedule the interviews too close to the deadline and make sure the panel have some help with their day to day duties if you want them to do a good job. I would suggest at least a week between deadline and interviews is needed.

Have a grid with your essential and desirable criteria in columns and a row for each candidate. As you review CVs, try to objectively score the candidates in each area. You’ll soon warm to the candidates who make this easy for you. Reject any candidates who don’t bother to show how they meet your criteria or who don’t meet enough of them.

Preparing for the interviews

Decide if you want a written or practical test, or if you want the candidate to do a presentation. Plan the tests carefully and get colleagues to try them out. I like to make Cisco certified candidates solve some problems on Lab kit via the CLI. If there is an equivalent in your field, consider this. For example you may wish to ask a web developer to look at some code and fix a bug. Don’t make these overly difficult – they should verify the candidate has the skills they claim, not terrify them. They should be challenging enough to expose frauds though.

Thing about the questions you will ask the candidates and make a note of them so that you can ask the same questions to all candidates. Score them on each question and make notes if possible as you’ll forget who said what by the end of the day.

Trust your instincts.

Allow enough time for each test and interview. Allow a good hour for lunch for the panel. Don’t schedule too many interviews for one day. I would suggest three in the morning and two in the afternoon as a maximum, but it will depend on the seniority of the role.

Feedback

When candidates ask for feedback, be very careful. Ask HR for the official policy and where possible refer unsuccessful candidates to them.

Thoughts

Recruitment involves a lot of hard work on both sides. The process can be made easier if there is empathy between candidate and recruiter. Hopefully my ramblings will encourage that.

Network Diagram

Using IPv6 in my Dynamips Lab

In this short post I will describe how I modified my IPv4 numbering scheme for IPv6.

Overview

I picked 2001 as the first quad nibble as I want to use Global addresses in my linknets. I can always use the Link Local addresses if needed. For the second quad nibble I take the two router numbers in ascending order (I leave the rest at zero as it saves a lot of time). I also decided to use /64s for my linknets.  Although this is wasteful I would like the option to use SLAAC. When statically configuring addresses I use the lowest two in the subnet. For example, the link between R1 and R2 would be 2001:12::/64, with R1 taking 2001:12::1 and R2 taking 2001:12::2.

Network Diagram

Network Diagram

Frame relay

The Frame Relay cloud is still available. For subinterfaces connecting v6 addresses via Frame Relay the only change is that I use 2002:XY::/64, where X and Y are the two routers I’m connecting in ascending numerical order.

Summary

That’s it for this mini series on how I use Dynamips when labbing. Hopefully you will find it helpful. I welcome any comments or suggestions.

Network Diagram

Adding Frame Relay to my Dynamips Lab

In this post I will explain how I set up Frame Relay using Dynamips to provide greater flexibility.

Overview

I want to achieve a full mesh of routers on demand but be able to keep the number of interfaces in general use to a minimum. With that in mind I hooked up each router to a frame relay switch via serial 2/1. I configured a full mesh of DLCIs and used the router numbers to donate the circuit and direction.

For example, the DCLI linking R5 to R6 would be 506. The return DCLI from R6 to R5 would be 605. When configuring subinterfaces I name the interface after the DLCI. So in with this example R5 uses serial 2/1.506 to connect to R6 via Frame Relay, R6 uses serial 2/1.605 for the return circuit.

Network Diagram

Network Diagram

So I can now connect any router to any other router with predicable configuration. I’ve kept the first /30 in the /24s I use for each router’s serial linknets, e.g. 192.168.12.0/30 was the linknet for R1/R2. I use the next /30 for the Frame Relay linknet. Although I don’t currently have a physical link between R5 and R6, I’ll still keep 192.168.56.0/30 back for future use. So when I dial up that Frame Relay circuit, I’ll use 192.168.56.4/30.

Summary

Hopefully it is clear that a vast number of topologies are possible with the combination of the physical links and my new Frame Relay cloud. It surprised me how often I’ve been in the middle of a lab and suddenly needed a direct link between R3,4,5 or 6 so this has come in very useful. I stand by my decision to keep the available physical interfaces to a minimum though; I have usually been able to keep the whole topology in my head while configuring the routers for some funky designs because of it. Sometimes less is more.

Network Topology

My Dynamips Lab

In this first post I will describe how I have configured my base lab in dynamips. I intend to use this lab in my future posts and hope that by explaining how the lab works once, I will be able to limit later posts to to discussing the technologies I’m learning about.

My general principals are:

  1. I don’t want to have to think about the topology when learning a new technology.
  2. Nomenclature should be predictable and extensible.
  3. The topology should be large enough to be useful and small enough to be usable on my laptop.

With that in mind I developed the following topology.

Transit networks or ‘linknets’

Network Topology

I’m aware of RFC 3330, specifically that 192.0.2.0/24 is reserved for examples and documentation but I found one /24 too limiting.

Client networks

I use either the 10/8 or 172.16/12 networks to mimic clients, either on Loopbacks or Ethernet ports. In any topology I’ll incorporate the router number in all its clients. If I’m doing something simple, I’ll probably use 172.16.N.0/24 for each client where 0<N<7. Or if I want a few more networks I may take 10 per router, so R1 would get 172.16.1[0-9].0/24. If I’m doing some crazy MPLS VPNs and want a lot of networks, I may use the 10/8 space and denote the router with the second octet and the VC with the third.

Summary

Hopefully you can start to picture some simple network designs using this topology and also see how a methodical approach to nomenclature and interface choice is of benefit. Next time I’ll add some frame relay to give us a few more options.

 Appendix: Dynamips Config

 [[ROUTER R1]]
        f0/0 = S1 1
        s1/2 = R2 s1/1
        s1/3 = R3 s1/1
        s1/4 = R4 s1/1
        s1/5 = R5 s1/1
        s1/6 = R6 s1/1
        s2/1 = F1 1

    [[ROUTER R2]]
        f0/0 = S1 2
        s1/3 = R3 s1/2
        s1/4 = R4 s1/2
        s1/5 = R5 s1/2
        s1/6 = R6 s1/2
        s2/1 = F1 2

    [[ROUTER R3]]
        f0/0 = S1 3
        s2/1 = F1 3

    [[ROUTER R4]]
        f0/0 = S1 4
        s2/1 = F1 4

    [[ROUTER R5]]
        f0/0 = S1 5
        s2/1 = F1 5

    [[ROUTER R6]]
        f0/0 = S1 6
        s2/1 = F1 6

# for route advertisment
    [[ethsw S1]]
        1 = access 1
        2 = access 2
        3 = access 3
        4 = access 4
        5 = access 5
        6 = access 6