Showing posts with label unetlab. Show all posts
Showing posts with label unetlab. Show all posts

UNetLab on the go (using a tablet for labbing)

Usually I will be on my laptop or desktop when I am labbing, but I was giving the boys a bath yesterday and wanted to troubleshoot something. I could not just leave them in the bath, so I grabbed my Kindle (HD 10). It's on the WiFi, so I have access to my UNetLab interface, but could not guarantee I would have access to the nodes.

There are some constraints, in that it needs to be of a certain size, a minimum of 922px wide, otherwise you'll see some errors, but holding it horizontally, UNL works very well.


Excuse the colors, I forgot to turn off BlueShade mode.

Using Chrome I could log in, and as I have JuiceSSH I can click on a node, and the SSH client pops up.




This is great, as it means I can VPN to my router, from the Fire, and connect to the nodes. Typing in the JuiceSSH client is fine, it's responsive, and you can launch multiple sessions, its not tabbed though, but maybe something like ServerAuditor would be quicker when switching between sessions, but there is no guarantee that it will integrate seamlessly like JuiceSSH does.

So, if you are looking for a suitable UNL-friendly tablet, the Kindle Fire 10 works very well. I have not found how to get VNC access yet. Not seamless anyway. I could get the link and manually connect, but that's not ideal. Thankfully, most of the nodes will be using telnet instead of VNC, so thats probably about 85% of what I need being covered. Still, the 15% that still need VNC would be nice to get working. I will keep trying and update this page when I find a solution.

The Kindle Fire is a nice bit of kit, I love reading on it, but not study books, I much prefer to have the physical book in my hand for that. It's pretty reasonable as well, it will happily stream stuff to watch, and because it has expandable storage, I can load it up with study videos.

I am sure that there is a wealth of other tablets that can run UNetLab, more importantly, have the integration possibilities to run the SSH and VNC clients as well. Not sure about the iPad, as they are a little bit more sand-boxed, but maybe someone else has got it running.

I'd love to hear from anyone else who is running UNetLab on a tablet, so please comment below with the make/model, and SSH and VNC clients you are using, and I will update the below table!

Click on the price to take you to the Store site.
Model Price Telnet/SSH Client VNC Client
Kindle Fire HD 10 price JuiceSSH Not found yet

CCIE Security lab: Connecting the virtual and physical worlds together

With my new 3750X switch looking like it should be doing as intended, it's time to get it connected to the UNetLab topology.

I must admit, I havn't tried to do this before, so it should be interesting. I did connect pnet0 to a Windows host to grab something before, but this needs to be completely isolated from the rest of the home network, otherwise the Wife will get upset that she can only browse to www.good.com, and not buy shoes.

The basic configuration in UNL is to connect a Pnet interface to a device (like SW3). I am using PNet1 as this is linked to Eth1:


Creating this "3750x" network is just a case of creating a new network, but setting it to be a pnet, instead of a bridge.

As you can see, UNetLab can see two NICs:
root@unl01:~# ifconfig -a | grep ^eth
eth0      Link encap:Ethernet  HWaddr 00:50:56:80:2a:6e
eth1      Link encap:Ethernet  HWaddr 00:50:56:80:a2:db
root@unl01:~#
Inside ESXi things look like this:

We have a vSwitch created, and this includes one of the NICs from the Quad-port NIC card in the ESXi server:
Connecting UNetLab to a physical switch in VMWare

We must accept promiscuous mode, otherwise things won't work properly:

Connecting UNetLab to a physical switch in VMWare

UNL has this network connected.

Connecting UNetLab to a physical switch in VMWare

Unsurprisingly things did not just magically work straight away. So a quick reboot later, and once SW3 is fired up, we can start to see some errors, and these are the kind of errors you want, as it shows everything is working:
%SYS-5-RESTART: System restarted --
Cisco IOS Software, vios_l2 Software (vios_l2-ADVENTERPRISEK9-M), Version 15.2(CML_NIGHTLY_20150414)FLO_DSGS7, EARLY DEPLOYMENT DEVELOPMENT BUILD, synced to  DSGS_PI5_POSTCOLLAPSE_TEAM_TRACK_CLONE
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Wed 15-Apr-15 00:42 by mmen
%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet0/0 (not full duplex), with 3750X GigabitEthernet3/0/1 (full duplex).
SW3>en
SW3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW3(config)#int g0/0
SW3(config-if)#duplex full
Autoneg enabled. Duplex cannot be set

%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet0/0 (not full duplex), with 3750X GigabitEthernet3/0/1 (full duplex).
%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on GigabitEthernet0/0 (not full duplex), with 3750X GigabitEthernet3/0/1 (full duplex).

SW3(config-if)#no neg auto 
SW3(config-if)#duplex full
SW3(config-if)#do sh cdp neigh | b Device
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
SW4              Gig 0/3           170             R S I            Gig 0/3
SW1              Gig 0/1           151             R S I            Gig 0/3
SW2              Gig 0/2           147             R S I            Gig 0/3
3750X            Gig 0/0           130              S I   WS-C3750X Gig 3/0/1

Total cdp entries displayed : 4
SW3(config-if)#
Nice! So, let's add in some VTP, so that the 3750X gets all the VLAN goodness, and then plug in the IP Phone!
SW1(config)#vtp dom 802101
Changing VTP domain name from NULL to 802101
SW1(config)#vtp mo serv
%SW_VLAN-6-VTP_DOMAIN_NAME_CHG: VTP domain name changed to 802101.
Device mode already VTP Server for VLANS.
SW1(config)#vtp ver 2
SW1(config)#vtp pass 802101
Setting device VTP password to 802101
SW1(config)#
The other devices are set up in client mode, using the same settings as above for the domain and password. However, we need to push some data across to the switch, and as I don't want to keep having to find the laptop that I use for console access to the switch, it would make sense to create a VLAN for switch management:
SW1(config)#vlan 11
SW1(config-vlan)#name Switch-MGMT
SW1(config-vlan)#exi
SW1(config)#
This gets to the other switches:
SW2(config)#do sh vlan br

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/0, Gi1/0
4    Management                       active    Gi1/1, Gi1/2, Gi1/3
7    DMZ                              active    
9    Phones                           active    
11   Switch-MGMT                      active    
20   Users-1                          active    
21   Users-2                          active    
55   Failover                         active    
99   Data-Phone                       active    
1002 fddi-default                     act/unsup 
1003 trcrf-default                    act/unsup 
1004 fddinet-default                  act/unsup 
1005 trbrf-default                    act/unsup 
SW2(config)#
But so far, not to the 3750X. It just has the VLANs I manually created for something else.

VTP/DTP is working, and I can see the messages in Wireshark:

Connecting UNetLab to a physical switch in VMWare

I even switched to VTP version 3, and made SW3 the primary server. But the 3750X did not get the VLANs from the virtual environment.

So, where is the issue? Let's expand it out a little, and either rule it down to, or rule out an issue with my VTP configuration, by adding a phone into the mix.

Its a simple config:
int gi 3/0/3
switchport voice vlan 9
switchport mode access
switchport access vlan 21
I switched the 3750X to transparent mode for a moment, so that I could add the VLANs needed. But still there was no joy.

I used the command "sdm prefer vlan", and did a reboot. Once everything came back up again, I could see the VLANs had been added through VTP, however, communicating with devices was a little unwilling.

So I messed around for a bit trying a bit of this and a bit of that, then I decided to ping Andrea a message and ask for help. He was busy, but I got a couple of minutes with him before he had to dash off to another meeting. He told me to try looking for "vmware switch trunk portgroup", which lead me to this document: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004074.

Seems like I was pretty close with my first attempt, but needed to add the following settings:

Connecting UNetLab to a physical switch in VMWare

Connecting UNetLab to a physical switch in VMWare

I even rebooted the switch again... and when it came back up, OSPF formed an adjacency, and the phone has a DHCP address:
SW3(config)#router ospf 1
SW3(config-router)#router-id 33.33.33.33
SW3(config-router)#network 0.0.0.0 0.0.0.0 a 0
SW3(config-router)#
%OSPF-5-ADJCHG: Process 1, Nbr 50.50.50.50 on Vlan4 from LOADING to FULL, Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 50.50.50.50 on Vlan11 from LOADING to FULL, Loading Done
SW3(config-router)#
Rather than posting a blurry photo of the phone's screen, I'll show you the successful DHCP lease for the phone:

Connecting UNetLab to a physical switch in VMWare

So, I do not have a £899 paperweight, I have a working physical switch connected to my IOSv layer-2 switch. It is isolated from my home network, and once the Cisco AP gets delivered I should be able to play around with that.

Just one more bit of proof that its working, here is the DHCP reservation for my MacBook, which was connected to the phone's PC port:

Connecting UNetLab to a physical switch in VMWare


And here is the screenshot from the Mac itself:

Connecting UNetLab to a physical switch in VMWare

Even though it wasn't exactly smooth sailing, I am where I need to be. The UNetLab hosts can talk to the physical hosts, and the floor is opening up for me to have some real fun!



Scheduled certification will resume shortly - back to CCIE.Sec!

OK, so I have been a bit preoccupied recently, I am putting the finishing touches to CCNA and Beyond, which is currently in the hands of the previewers, and took a side step to get the Check Point Certified Security Administrator (CCSA) exam - which I passed today. And as I am in a good mood, it's time to crank up the volume and play music. So here is Ash performing "Burn Baby Burn":


Love that song. And now, here is Red Kite performing "Montreal":


Anyway, it's time to crack on with the CCIE Security. It'sMarch now and I want to sit the exam in December. So I best be getting on with it.

Despite losing the existing topology, I rebuilt most of it using REST calls, but need to finish quite a bit by hand. It's nearly done! I have had to change the LA-FW to ASA (8.4.2) if you are following along at home and need to use the same REST calls.

It's actually proving much harder to re-do all of this than I thought, which is my fault as I did not rename devices, or come up with a proper IP address scheme early on. But, like my lack of backing up, I only have myself to blame.

I will post the topology (as it is at the moment) at the end of this post, and it will have IP addressing and so on and so forth. Lots of people have asked for it, so i't about time I shared it - also it means that this post will be a new starting point, and be all IP'd up (or nearly all).

I will start with the multi-context firewalls first, then do the transparent firewalls, then the MPLS core. If I am luck y then I'll even be able to get the tabbed thing working as it should do...

Multi-context firewalls

The code for the firewalls is below:


hostname LA2
interface GigabitEthernet0/0
 ip address 20.5.5.254 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
ip route 0.0.0.0 0.0.0.0 20.5.5.1
hostname LA3
interface GigabitEthernet0/0
 ip address 20.6.6.254 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
ip route 0.0.0.0 0.0.0.0 20.6.6.1
hostname LA-FW
interface Ethernet0
!
interface Ethernet0.10
 vlan 10
!
interface Ethernet0.20
 vlan 20
!
interface Ethernet0.30
 vlan 30
!
admin-context admin
context admin
  config-url disk0:/admin.cfg
!
context C1
  allocate-interface Ethernet0.20 outsideC1 
  allocate-interface Ethernet2 insideC1 
  config-url disk0:/C1.cfg
!             
context C2
  allocate-interface Ethernet0.30 outsideC2 
  allocate-interface Ethernet3 insideC2 visible 
  config-url disk0:/C2.cfg
!
prompt hostname context
hostname C1
interface outsideC1
 nameif Outside
 security-level 0
 ip address 198.250.20.2 255.255.255.0 
!
interface insideC1
 nameif Inside
 security-level 100
 ip address 20.5.5.1 255.255.255.0 
!
hostname C2
interface outsideC2
 nameif Outside
 security-level 0
 ip address 198.250.30.2 255.255.255.0 
!
interface insideC2
 nameif Inside
 security-level 100
 ip address 20.6.6.1 255.255.255.0 
!
hostname LA-SW
interface GigabitEthernet0/0
 switchport trunk encapsulation dot1q
 switchport mode trunk
 media-type rj45
 negotiation auto
!
interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 media-type rj45
 negotiation auto
Remember to recreate the VLANs! (10,20 and 30)
hostname LA1
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 198.240.5.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/1
 no ip address
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/1.10
 encapsulation dot1Q 10
!
interface GigabitEthernet0/1.20
 encapsulation dot1Q 20
 ip address 198.250.20.1 255.255.255.252
!
interface GigabitEthernet0/1.30
 encapsulation dot1Q 30
 ip address 198.250.30.1 255.255.255.0
!

Make sure that the interfaces are not shut off, and save the work!

Transparent ASA



hostname NY2
interface Loopback0
 ip address 3.3.3.0 255.255.255.255
!
interface Loopback1
 ip address 3.3.3.1 255.255.255.255
!
interface Loopback2
 ip address 3.3.3.2 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 128.2.2.2 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
firewall transparent
hostname NY-FW
interface GigabitEthernet0/0
 nameif Inside
 bridge-group 1
 security-level 100
!
interface GigabitEthernet0/1
 nameif Outside
 bridge-group 1
 security-level 0
!
interface BVI1
 ip address 128.2.2.254 255.255.255.0 
!
ftp mode passive
access-list outside->in extended permit eigrp any any 
access-list outside->in extended permit icmp any any 
access-list outside->in extended permit ip any any 
!
access-group outside->in in interface Inside
access-group outside->in in interface Outside
!
http server enable
http 0.0.0.0 0.0.0.0 Inside
hostname NY1
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 128.2.2.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/1
 ip address 198.240.3.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!

MPLS Core



router ospf 1
router-id 2.2.2.2
network 198.240.3.1 0.0.0.0 a 0
network 2.2.2.2 0.0.0.0 a 0
mpls ldp autoconfig
mpls label protocol ldp
mpls ldp router-id lo0 force
router bgp 1
bgp router-id 2.2.2.2
no bgp def ipv4-unicast 
neigh 4.4.4.4 remote 1
neigh 3.3.3.3 remote 1
neigh 4.4.4.4 update lo0
neigh 3.3.3.3 update lo0
address-family vpnv4 
neigh 4.4.4.4 activate
neigh 3.3.3.3 activ
neigh 4.4.4.4 send-community extended 
neigh 3.3.3.3 send-community extended 
!
ip vrf 802101
rd 1:1
route-target bo 1:1
!
int gi0/0
ip vrf for 802101
ip add 128.2.2.1 255.255.255.0
!
router bgp 1
add ipv4 vrf 802101
hostname ISP
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 198.240.3.254 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/1
 ip address 198.240.5.254 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/2
 ip address 198.240.1.254 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
router-id 1.1.1.1
network 0.0.0.0 0.0.0.0 a 0
mpls ldp autoconfig
mpls label protocol ldp
mpls ldp router-id lo0 force

router ospf 1
router-id 4.4.4.4
network 198.240.5.1 0.0.0.0 a 0
network 4.4.4.4 0.0.0.0 a 0
mpls ldp autoconfig
mpls label protocol ldp
mpls ldp router-id lo0 force
router bgp 1
bgp router-id 4.4.4.4
no bgp def ipv4-unicast 
neigh 2.2.2.2 remote 1
neigh 3.3.3.3 remote 1
neigh 2.2.2.2 update lo0
neigh 3.3.3.3 update lo0
address-family vpnv4 
neigh 2.2.2.2 activate
neigh 3.3.3.3 activ
neigh 2.2.2.2 send-community extended 
neigh 3.3.3.3 send-community extended
!
ip vrf 802101
rd 1:1
route-target bo 1:1
!
int gi0/1.20
ip vrf for 802101
ip add 198.250.20.1 255.255.255.0
int gi 0/1.30 
ip vrf for 802101
ip add 198.250.30.1 255.255.255.0
!
router bgp 1
add ipv4 vrf 802101
hostname LON1
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 198.240.1.1 255.255.255.0
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
router-id 3.3.3.3
network 198.240.1.1 0.0.0.0 a 0
network 3.3.3.3 0.0.0.0 a 0
mpls ldp autoconfig
mpls label protocol ldp
mpls ldp router-id lo0 force
!
router bgp 1
bgp router-id 3.3.3.3
no bgp def ipv4-unicast 
neigh 2.2.2.2 remote 1
neigh 4.4.4.4 remote 1
neigh 2.2.2.2 update lo0
neigh 4.4.4.4 update lo0
address-family vpnv4 
neigh 2.2.2.2 activate
neigh 4.4.4.4 activ
neigh 2.2.2.2 send-community extended 
neigh 4.4.4.4 send-community extended
!
ip vrf 802101
rd 1:1
route-target bo 1:1
!
int gi 0/1
ip vrf for 802101
ip add 163.4.4.1 255.255.255.0
!
router bgp 1
add ipv4 vrf 802101

The last step is to do some redistribution, so that our end points (what we have so far) can all talk to each other.

IGPs and redistribution into MPLS



router eigrp 100
 network 3.3.3.0 0.0.0.0
 network 3.3.3.1 0.0.0.0
 network 3.3.3.2 0.0.0.0
 network 128.2.2.2 0.0.0.0
 eigrp router-id 3.3.3.0
router eigrp NY
 !
 address-family ipv4 unicast vrf 802101 autonomous-system 100
  !
  topology base
   redistribute bgp 1 metric 1000 10 100 1 1500
  exit-af-topology
  network 128.2.2.1 0.0.0.0
 exit-address-family
!
router bgp 1
 address-family ipv4 vrf 802101
  redistribute eigrp 100 metric 1
 exit-address-family
ip route vrf 802101 20.5.5.0 255.255.255.0 198.250.20.2
ip route vrf 802101 20.6.6.0 255.255.255.0 198.250.30.2
router eigrp LA
 !
 address-family ipv4 unicast vrf 802101 autonomous-system 300
  !
  topology base
   redistribute bgp 1 metric 1000 10 100 1 1500
  exit-af-topology
  network 198.250.20.0
  network 198.250.30.0
 exit-address-family
!
router bgp 1
 address-family ipv4 vrf 802101
  redistribute eigrp 300 metric 1
  red static metric 1
 exit-address-family
router eigrp LON
 !
 address-family ipv4 unicast vrf 802101 autonomous-system 200
  !
  topology base
   redistribute bgp 1 metric 1000 10 100 1 1500
  exit-af-topology
  network 163.4.4.0 0.0.0.255
 exit-address-family
!
router bgp 1
 address-family ipv4 vrf 802101
  redistribute eigrp 200 metric 1
 exit-address-family

We don't really need EIGRP on LA1. LA-FW (because it is running ASA 8.4 and in multiple-context mode) does not support routing protocols, so we can do with redistributing the static routes only. We really dont need these anyway, as they will be behind NAT. So take them or leave them!

Still missing a few bits, such as ACLs on the LA-FW. So, while we are on a good run, let's just save the work so far, and add those in. This is for the C1 context:
object-group network INSIDE-NAT-SUBNETS
network-object 20.5.5.0 255.255.255.0
network-object 20.5.10.0 255.255.255.0
network-object 20.5.20.0 255.255.255.0
access-list outside->in extended permit ip any any 
access-list outside->in extended permit icmp any any 
access-list outside->in extended permit icmp any any echo-reply 
access-group outside->in in interface Outside
nat (Inside,Outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
And this is for the C2 context:
object-group network INSIDE-NAT-SUBNETS
network-object 20.6.5.0 255.255.255.0
network-object 20.6.10.0 255.255.255.0
network-object 20.6.20.0 255.255.255.0
access-list outside->in extended permit ip any any 
access-list outside->in extended permit icmp any any 
access-list outside->in extended permit icmp any any echo-reply 
access-group outside->in in interface Outside
nat (Inside,Outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
We can test connectivity now:
LA2#ping 3.3.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/17/32 ms
LA2#

LA3#ping 3.3.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/16/20 ms
LA3#

NY2#ping 163.4.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 163.4.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/9/13 ms
NY2#
Excellent, all seems to be working again.

This is what the lab looks like at the moment:



You can find the topology file under the Security link on the "Labs" drop down menu at the top.

A change is as good as a ReST - UNetLab and the API

Hit a bit of a hiccup with my CCIE Security lab topology. It got wiped. Not happy to be honest, but you have to take the rough with the smooth sometimes.

So, now I have to rebuild it. From scratch. It's a ball ache, but needs to be done. I like to think I am a positive person, so let's try and put a positive spin on this. Can I recreate it in a more interesting way?

Maybe.

Since UNetLab 0.8.6-1 we have a ReST API (Representative State Transfer). Now in the interest of full disclosure I should point out that I know fuck-all about ReST - apart from the fact that it's supported in ASAs, and mans that you can call functions via a URL - so, can I recreate some of the CCIE lab using ReST?

First of all, where is the api? It's a file under the html folder - which makes sense as we need to access it through a browser:
root@unl01:~# ls /opt/unetlab/html/
api.php  configs  favicon.ico  files  images  includes  templates  themes
root@unl01:~#
Looking through the api.php file (too much to reprint here), there are some quick wins to get us started. We can list our folders, using the URL: "http://<unetlab server>/api/folders/" (note that my IP is 192.168.0.16 and that I have moved the output around for ease of reading):
{"code":200,"status":"success","message":"Successfully listed path (60007).",
"data":{"folders":[
{"name":"802101","path":"\/802101"},
{"name":"CCNA","path":"\/CCNA"},
{"name":"CheckPoint","path":"\/CheckPoint"},
{"name":"RS","path":"\/RS"},
{"name":"Security LAB","path":"\/Security LAB"},
{"name":"SP LAB","path":"\/SP LAB"},
{"name":"Test","path":"\/Test"},
{"name":"Thunderhead","path":"\/Thunderhead"}]
,"labs":[
{"file":"11routers.unl","path":"\/11routers.unl"},
{"file":"Active_ASA_test.unl","path":"\/Active_ASA_test.unl"},
{"file":"DMVPN.unl","path":"\/DMVPN.unl"},
{"file":"sdf-test.unl","path":"\/sdf-test.unl"},
{"file":"sdf-Win10-UCS.unl","path":"\/sdf-Win10-UCS.unl"},
{"file":"Test Lab custom topology.unl","path":"\/Test Lab custom topology.unl"}]}}
I started to recreate the Security topology, so already have the .unl file created, and it's in the 802101 directory. We can look at the contents of this by changing the URL to "http://192.168.0.16/api/folders/802101":
{"code":200,"status":"success","message":"Successfully listed path (60007)."
,"data":
{"folders":[{"name":"..","path":"\/"}],"labs":[
{"file":"BGP for Cisco Networks.unl","path":"\/802101\/BGP for Cisco Networks.unl"},
{"file":"CCIE Security.unl","path":"\/802101\/CCIE Security.unl"},
{"file":"MPLS for Cisco Networks.unl","path":"\/802101\/MPLS for Cisco Networks.unl"},
{"file":"VPNs and NAT for Cisco Networks.unl","path":"\/802101\/VPNs and NAT for Cisco Networks.unl"}]}}
OK, getting nearer.

Now, what happens if we look at this file via the api, by calling the URL "http://192.168.0.16/api/labs/802101/CCIE%20Security.unl":
{"code":200,"status":"success","message":"Lab has been loaded (60020)."
,"data":{"author":"Stuart Fordham","description":"","body":"",
"filename":"CCIE Security.unl","id":"4dd7e0ac-cd86-4ab7-aab8-dfc8744afb7a",
"name":"CCIE Security","version":"1"}}
OK, we can drill down. can we see if we have any existing objects?

Using the API to configure UNetLab

Adding nodes isn't quite as easy as the above examples. From the api.php code, the important bit looks to be:
 
} else if (preg_match('/^\/[A-Za-z0-9_+\/\\s-]+\.unl\/nodes$/', $s)) {
if (isset($p['count'])) {
 // count cannot be set from API
  unset($p['count']);
 }
 $output = apiAddLabNode($lab, $p, $o);
So, we need to pass three variables, the lab, which should already be in the URL, p, and o. These then get passed to another php file (api_nodes.php). So, what are p and o?
 $event = json_decode($app -> request() -> getBody());
 $p = json_decode(json_encode($event), True); // Reading options from POST/PUT
 $s = '/'.implode('/', $path);
 $o = False;
So after a bit of playing around I had to have a rethink. This should all be done using CURL commands, it'll make it much more programmable. So I headed down that route. Because this entails leaving the browser, we lose the fact that we are logged in, so need to log in again. After a could of hours blindly bashing away at the keyboard, I found this excellent guide to ReST: https://docs.phalconphp.com/en/latest/reference/tutorial-rest.html. Give it a read, it's very good. This made life much easier, and I was able to log in. More importantly, I got a good idea of the syntax, which is, you know, kind of important:
Stuarts-MacBook-Pro:~ stuart$ curl -i -X POST -d '{"username":"admin","password":"unl"}' http://192.168.0.16/api/auth/login
HTTP/1.1 200 OK
Date: Sun, 13 Mar 2016 19:38:46 GMT
Server: Apache/2.4.7 (Ubuntu)
X-Powered-By: PHP/5.5.9-1ubuntu4.14
X-Powered-By: Unified Networking Lab API
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: unetlab_session=4ad092ad-6ec1-471a-a24f-a9fab738583c; domain=192.168.0.16; path=/api/; expires=Mon, 13-Mar-3600 19:38:46 UTC
Content-Length: 67
Content-Type: application/json

{"code":200,"status":"success","message":"User logged in (90013)."}Stuarts-MacBook-Pro:~ stuart$ 
Stuarts-MacBook-Pro:~ stuart$ 
The problem here is that subsequent commands all failed due to authentication. Back to the Googles...

ReST Authentication and how to stay authenticated

I then found this web page: https://www.drupal.org/node/1795770. We can push the authentication data into a text file, and then call it later on. This works nicely. Note though that I am on a different machine now:
[root@spoon ~]# curl -X POST -i -H "Content-type: application/json" -c cookies.txt -X POST http://192.168.3.239/api/auth/login -d '
> {
> "username":"admin",
> "password":"unl"
> }
> '
HTTP/1.1 200 OK
Date: Mon, 14 Mar 2016 10:35:15 GMT
Server: Apache/2.4.7 (Ubuntu)
X-Powered-By: PHP/5.5.9-1ubuntu4.11
X-Powered-By: Unified Networking Lab API
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: unetlab_session=916665da-cfcb-4230-b5df-01b5f0bf78a9; domain=192.168.3.239; path=/api/; expires=Tue, 14-Mar-3600 10:35:15 UTC
Content-Length: 67
Content-Type: application/json

{"code":200,"status":"success","message":"User logged in (90013)."}
[root@spoon ~]#
We get authenticated, and the information is stored in a file called cookies.txt. We then us the -b command to call this file, if we don't use the -i flag then we get cleaner output:
[root@spoon ~]# curl -b cookies.txt -X GET http://192.168.3.239/api/folders/
{"code":200,"status":"success","message":"Successfully listed path (60007).","data":{"folders":[{"name":"CCNA_and_Beyond","path":"\/CCNA_and_Beyond"},{"name":"Pedro","path":"\/Pedro"},{"name":"RS","path":"\/RS"},{"name":"SP","path":"\/SP"}],"labs":[]}}You have new mail in /var/spool/mail/root
[root@spoon ~]#
OK, so this is a different machine, so I need to start from scratch. Let's try and create a folder.

Creating folders in UNetLab using ReST

Making sure that we pass the authentication data to UNL, we should be able to create a folder by specifying the name and the path (leaving the path empty if you want it at the top level):
[root@spoon ~]#  curl -X POST  -H "Content-type: application/json" -b cookies.txt  http://192.168.3.239/api/folders -d '
> {
> "name":"802101",
> "path":""
> }
> '
{"code":200,"status":"success","message":"Folder has been created (60014)."}
[root@spoon ~]#
So, does this appear in the folder list? Yes, it does!
[root@spoon ~]# curl -b cookies.txt -X GET http://192.168.3.239/api/folders/
{"code":200,"status":"success","message":"Successfully listed path (60007).","data":{"folders":[{"name":"802101","path":"\/802101"},{"name":"CCNA_and_Beyond","path":"\/CCNA_and_Beyond"},{"name":"Pedro","path":"\/Pedro"},{"name":"RS","path":"\/RS"},{"name":"SP","path":"\/SP"}],"labs":[]}}
[root@spoon ~]#
Wonderful, now lets try and create the CCIE Security lab!

Creating labs in UNetLab using the API

I won't show the misses I have had in trying to gauge the correct commands, but eventually I got it. The key is to look at the GUI and work out whats needed:
[root@spoon ~]#  curl -X POST  -H "Content-type: application/json" -b cookies.txt  http://192.168.3.239/api/labs -d '
> {
> "path":"/802101",
> "name":"CCIE Security",
> "version":"1",
> "author":"Stuart",
> "description":"CCIE"
> }
> '
{"code":200,"status":"success","message":"Lab has been created (60019)."}
[root@spoon ~]#
We can confirm this from the GUI - but note that this will mean that we have to authenticate again (might be worthwhile setting up different accounts for the API use, and checking in the GUI to save time):


OK, so now we have the folder, and the lab created. Let's add an object!

Creating nodes in UNL using ReST

After a few trials I managed to come down to this:
curl -X POST  -H "Content-type: application/json" -b cookies.txt http://192.168.3.239/api/labs/802101/CCIE%20Security.unl/nodes -d '
 {
 "type":"iol",
 "template":"iol",
 "image":"L3-ADVENTERPRISEK9-M-15.5-2T.bin",
 "name":"R1",
 "icon":"Router.png",
 "nvram":"1024",
 "ram":"256",
 "ethernet":"1",
 "serial":"0",
 "delay":"0",
 "config":"Unconfigured"
 }
 '
Which got me this:
{"code":201,"status":"success","message":"Lab has been saved (60023)."}
We can even see it on the GUI:


OK, so now we can add nodes to our lab. let's add a network:

Creating Networks using ReST

[root@spoon ~]#  curl -X POST  -H "Content-type: application/json" -b cookies.txt http://192.168.3.239/api/labs/802101/CCIE%20Security.unl/networks -d '
 {
 "type":"bridge",
 "name":"Net1"
 }
 '
{"code":201,"status":"success","message":"Network has been added to the lab (60006)."}
[root@spoon ~]#
Now we can add the network to our interface:



So, with a bit of digging about, it's now pretty simple to create folders and labs, and to add nodes and networks to the labs.

It's taken me about half a day to get this far, but it opens up a world of possibilities. This means that it could be scripted, and maybe even be able to create a topology in something like Visio and then call a script to create the lab in UNetLab... at least that's the idea.

Hands on with UNetLab 1.0

UNetLab has just reached version 1.0 (stable). It's actually 1.0.0-4 to be exact, and a lot has changed.

Installing the new version is no different to doing any Linux upgrade, however, I did encounter a problem:
root@unl01:~# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
 linux-image-virtual : Depends: linux-image-3.13.0-79-generic but it is not installed
E: Unmet dependencies. Try using -f.
root@unl01:~# apt-get -f install
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
....
dpkg: error processing archive /var/cache/apt/archives/linux-image-3.13.0-79-generic_3.13.0-79.123_amd64.deb (--unpack):
 cannot copy extracted data for './boot/vmlinuz-3.13.0-79-generic' to '/boot/vmlinuz-3.13.0-79-generic.dpkg-new': failed to write (No space left on device)
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.13.0-79-generic /boot/vmlinuz-3.13.0-79-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.13.0-79-generic /boot/vmlinuz-3.13.0-79-generic
Errors were encountered while processing:
 /var/cache/apt/archives/linux-image-3.13.0-79-generic_3.13.0-79.123_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@unl01:~#
It looks like /boot is a bit low on space:
root@unl01:~# df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rootvg-rootvol  185G  156G   22G  89% /
none                        4.0K     0  4.0K   0% /sys/fs/cgroup
udev                         20G  4.0K   20G   1% /dev
tmpfs                       4.0G  3.0M  4.0G   1% /run
none                        5.0M     0  5.0M   0% /run/lock
none                         20G     0   20G   0% /run/shm
none                        100M     0  100M   0% /run/user
/dev/sda1                   232M  218M     0 100% /boot
root@unl01:~#
Yep, no room left, so let's make some space:
root@unl01:~# cd /boot/
root@unl01:/boot# rm -f initrd.img-3.13.0-61-generic
root@unl01:/boot# rm -f initrd.img-3.13.0-62-generic
root@unl01:/boot# rm -f initrd.img-3.13.0-63-generic
root@unl01:/boot# rm -f initrd.img-3.13.0-65-generic
root@unl01:/boot# rm -f initrd.img-3.13.0-66-generic
root@unl01:/boot# rm -f vmlinuz-3.13.0-61-generic
root@unl01:/boot# rm -f vmlinuz-3.13.0-62-generic
root@unl01:/boot# rm -f vmlinuz-3.13.0-63-generic
root@unl01:/boot# rm -f vmlinuz-3.13.0-65-generic
root@unl01:/boot# rm -f vmlinuz-3.13.0-66-generic
root@unl01:/boot# df -f
df: invalid option -- 'f'
Try 'df --help' for more information.
root@unl01:/boot# df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/rootvg-rootvol  185G  156G   22G  89% /
none                        4.0K     0  4.0K   0% /sys/fs/cgroup
udev                         20G   12K   20G   1% /dev
tmpfs                       4.0G  3.0M  4.0G   1% /run
none                        5.0M     0  5.0M   0% /run/lock
none                         20G     0   20G   0% /run/shm
none                        100M     0  100M   0% /run/user
/dev/sda1                   232M  137M   80M  64% /boot
root@unl01:/boot#
OK, thats better. Lets run the update:
root@unl01:/boot# apt-get install unetlab
Reading package lists... Done
Building dependency tree       
Reading state information... Done
...
Do you want to continue? [Y/n] Y
Get:1 http://www.unetlab.com/apt/ trusty/rrlabs unetlab amd64 1.0.0-4 [9,921 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu/ trusty/main libaio1 amd64 0.3.109-4 [6,364 B]
Get:3 http://us.archive.ubuntu.com/ubuntu/ trusty/main telnet amd64 0.17-36build2 [67.1 kB]
Get:4 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main python3-pexpect all 3.1-1ubuntu0.1 [37.9 kB]
Fetched 10.0 MB in 5s (1,739 kB/s)         
...
Setting up python3-pexpect (3.1-1ubuntu0.1) ...
Setting up unetlab (1.0.0-4) ...
Processing triggers for libc-bin (2.19-0ubuntu6.6) ...
Processing triggers for initramfs-tools (0.103ubuntu4.2) ...
update-initramfs: Generating /boot/initrd.img-3.16.7-ckt8-unetlab
root@unl01:/boot#
I always like to reboot at this point, but you don't have to. So let's see what we have now!

The status page has a few changes, we now have a POD number (for multi-user), and we can see the UNetLab version and the Qemu version:


The usage indictors in the middle also update every few seconds, which is kind of useful.

If we look at the Users tab, we can see the default user, and what (if any) lab they are running:


Using the Actions menu, we can create a new user:




So, now you can have a pretty decent UNetLab server catering for a large number of users, and each can run their own lab. Pretty neat!

So, let's move onto the labs and see what's changed there.

It's all changed:


We have lost the menu at the top, and gained one at the side. From the top down we can add new things, such as networks, node, pictures, and now shapes and text:


Beneath this we have the lab details, and then an icon for the nodes:


If you have ever used Web-IOU then you'll be familiar with the icons at the right hand side to stop, start and reload devices.

We then have the networks icon, and then one for startup configs:


We then have icons for configuring pictures and text objects, and then one for "more actions":


We then can refresh the topology, and then there is an icon for free select. The major change is that we can now edit the topology and use it from within the same page, no more switching modes, which is so much better. However, if you do click on the free select icon, then you will need to click on it again to de-select it if you want to do anything with the nodes.

Speaking of the nodes, the right click menu has changed here as well:

Notice how the Manage menu minimises when we click on the Capture menu, this is a nice feature especially if you don't have the largest of displays.

Lastly we have a quick access button for the system status, we can close the lab, or log out completely.

It's much smoother, and configurable now. The addition of custom objects makes making labs much nicer (along with the fact that objects line up perfectly now! Now we can have nicely annotated labs:


It would be nice to be able to join objects (such as a square box and the text object within it), but this is a minor issue.

It is clear that a lot of thought has gone into this major release, it's fluid, sharp, and a pleasure to work with.

UNetLab and Wireshark for OSX - update

Hi all,

Quick post.

I have been meaning to get around to this for some time, and finally had some free minutes.

I originally posted about this back in September, and this is an updated version. The first version ran fine, unless you wanted to run the same capture again. Because there was no form of capture numbering, the capture would fail as the original file could not be overwritten.

I have now implemented some versioning (basically appending the date and time to the capture).


Now it *should* be a bit smoother!

Please test it out and let me know if there are any issues.

The link is below, it should be a simple extract, replace job:

Download link

https://sites.google.com/site/802101files/books/UNL_WiresharkV2.zip

Enjoy!

UNetLab topologies now available.

It seems that (and I am very thankful for this) UNetLab is making strong gains in popularity, as it should.

Whilst I do get the occasional email asking for setup help with GNS3 (which I am more than happy to do), I get far more emails asking when the book topologies will be available for UNetLab.

So, now that things have quietened down a bit, I have had time to do this.

On the relevant pages (above, under the Books menu) there are links for the files for the main topologies for all the books.

They are also here, to make it easier.

To import them you just need to create a folder called 802101 (you don't really have to have a folder, but it makes it neater):




Once thats done, go into the folder and then import an external object. Make sure its the whole zip file!


Then you should get a nice bunch of new labs:


The download links are below.

UNetLab Topology download links:

BGP for Cisco Networks
MPLS for Cisco Networks
VPNs and NAT for Cisco Networks

UNetLab Competition winner!

I recently ran a little competition to design a lab for UNetLab over on the forum. The idea behind it was to try and raise the profile of UNetLab, give it a bit more exposure in a different way and so that people could see it's potential.

We had three entries. Not the earth shattering 100's I was hoping for, but it certainly made the job of picking a winner much easier!

The cool thing is that each entrant picked a different level of ability:

Luis picked CCNA:

  Nikita chose CCNP:


Peter chose a CCIE level:


This made it much harder to choose a winner though.

Should the winner be chosen just because it is more complex? Not really, that would not be fair. Each should be judged on it's own merits.

Luis did a great job a VLSM, clearly a lot of thought went into that.

Nikita threw in some troubleshooting, which was a great idea!

Peter build an entire infrastructure and really pushed the boundary!

So with the variation of designs and different target audiences it's very hard to pick an outright winner. Clearly a lot of effort was made by each of you.
Therefore (because I am in a jolly mood) each of you will get all three volumes of the books. Each of you will have your labs added to the official UNetLab distribution. Each of you will get a T-shirt.

Peter's t-shirt will be changed though, to say "I won the #UNetLab challenge".

Send me a private message on the forum with your addresses and preferred t-shirt size and I will get the goodies ordered. I'll let you know when they have been sent, and supply tracking information, if possible.

UNetLab podcast - listen to it, learn it, love it

Hi everyone.

I havn't been blogging much recently, am busy working hard at a new thing which is taking most of my free time but should be back on track (and doing more CCIE Security stuff soon hopefully). Anyway, Andrea and Uldis gave a brilliant podcast, courtesy of those nice guys at Packet Pushers.


Have a listen to it. Its really informative and a great way to understand what UNetLab is all about.

The link is: http://packetpushers.net/podcast/podcasts/pq-show-61-unetlab-project/


Competition: Design and Win!

It is time for a new competition!

UNetLab challenge t-shirt

For this one you will need UNetLab, some routers and switches and other good things, and a little imagination (and maybe a paint or design program).

The challenge

Design us a lab. Simple as that.

The lab must have the following:

A PDF file with:

1: A list of the images used, including memory requirements.
2: A number of objectives, clearly stating the level of experience (Beginner, intermediate, Advanced). The objectives should include basic connectivity, some switching, some routing, and some verification. Extra points will be awarded for troubleshooting exercises.

A UNL file with the topology.

Points will be deducted for sending us labs used in real exams (i.e. don't send us a CCIE lab).

Submitting your design

Please post your designs on the competitions topic on the forum: here.

The prizes

First prize

  • All three volumes of my books; that's the BGP one, the MPLS one and the VPNs one.
  • An "I survived the #UNetLab challenge" t-shirt* 
  • Your lab will be included in the official repo, with full credits to you.

3 Runners-up prizes

  • A copy of MPLS for Cisco Networks
  • An "I survived the #UNetLab challenge" t-shirt* 
  • Your lab will be included in the official repo, with full credits to you.

* The design of the t-shirt may differ

We might even throw in some other stuff that we have lying about.

The competition closes on October 31st 2015.

How to run Barracuda NG Firewall on UNetLab

Sometimes you need to step outside of your usual sphere of technologies, and this is one of those times. I have, for a project, needed to become quite conversant with the Barracuda NG Firewall.

So, it makes sense that I can get one to play with at home. It will run on KVM, Xen, Citrix XenServer, Hyper-V and VMWare. But will it run in UNetLab?

Let's find out. Before we do that though I am going to do a very quick review.

Barracuda NG Firewall review

I must say that when I was given the options of what firewall to run (the choices being either Check Point or Barracuda, I immediately banged my hand on the table and proclaimed my desire to run Check Point.

Have you every tried to download a trial from Check Points website? It's almost impossible without having to sacrifice a goat or something. Barracuda, on the other hand, make getting an eval a very simple task.

So, we rolled out our first NG Firewall and, with a lot of help from Barracuda, I must say I am rather impressed.

Coming from an ASA background, some things don't seem to work as easily, such as the firewall ruleset, but in reality, this is just a mindset issue, and really, it does work well if you stop thinking like an ASA.

There are a couple of things I really love about the NG Firewalls, and that is the ability to cut and paste. Now I know that cutting and pasting has been around for ages, but it's nice that if you have two firewalls, one already set up with Site to Site VPNS, you can copy the VPN settings to the clipboard, and paste them onto the new firewall.

It makes life so much easier, you can do this access-rules as well, and it will even change the box IPs for you, and automatically create any custom objects required for the rule.

It's early days yet, but as I get more to grips with the NG, the more I like it.

Anyway, that's my three minute Barracuda NG Firewall review. Let's set one up in UNetLab.

Running the Barracuda NG Firewall in UNetLab

This is my very simple topology.

Barracuda NG Firewall in UNetLab

The router (lazily named "R") will have the IP address 192.168.100.1 (/24), and the NGF will use 192.168.100.10, the Windows PC will use 192.168.100.21.

To install the NG Firewall in UNetlab you need to download the OVA file from Barracuda. You can sign up for free at https://www.barracuda.com/purchase/evaluation. Select Firewall NG and fill out the form.

To install it you need to copy the OVA file to your UNetLab machine, extract, convert, rename, move it and run the fixpermissions wrapper:
root@unl01:/tmp# cd /tmp/
root@unl01:/tmp# tar -xvf GWAY-6.1.0-112-VC610.ova
root@unl01:/tmp# /opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 GWAY-6.1.0-112-VC610-disk1.vmdk hda.qcow2
root@unl01:/tmp# mkdir /opt/unetlab/addons/qemu/win-barracuda-6.1.0
root@unl01:/tmp# mv hda.qcow2 /opt/unetlab/addons/qemu/win-barracuda-6.1.0/
root@unl01:/tmp# /opt/unetlab/wrappers/unl_wrapper -a fixpermissions
Once this is done, you can create the topology add it. Note that there will soon be a proper UNetLab template for this! All being well, it will boot up:

Barracuda NG Firewall bootup

The VM will then enter ART (Active Recovery Technology), here you can set a static IP address:

Barracuda NG Firewall ART configuration

Now save it. If you are using a Mac, then press fn + F3 to save.

You should now have connectivity:
Router(config)#int e0/1
Router(config-if)#ip add 192.168.100.1 255.255.255.0
Router(config-if)#no shut
Router(config-if)#end
Router#ping 192.168.100.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.10:
!!!!!
Success rate is 100 percent (5/5)
Router#
The tricky part is how to get the NGAdmin utility loaded on the Windows VM, this was a neat little thing I learnt today. It also deserves (well I think so) a post of it's own, so click here to find out how to load files into a Qemu VM.

So once we have our files loaded into the Windows VM, we can fire up the NGAdmin console.

Barracuda NGAdmin-6-1-1 download for Windows

It shows us the splash screen:

Barracuda NGAdmin

And we can log in using root and the password of "ngf1r3wall".

Barracuda NGAdmin login default username and password

Click on Trust at the Authentication check box

Barracuda NGAdmin login certificate

If (like me) you havn't got your UNetLab network hooked into your main network, then click on Cancel at this box:

Barracuda NGAdmin licensing

After a few moment, we have logged into the box, and we have two days in which to register it with Barracuda. So, it will need to have proper internet access.

Barracuda NGAdmin dashboard

A couple more screenshots:

Barracuda NG firewall dashboard

Barracuda NG firewall disk usage

it all looks pretty happy. I havn't done any of the configuration yet, but will do posts on those later on. Need to get my NG licensed first.