Sunday, 29 December 2013

Embedded Event Manager Suicide

I often use the Cisco embedded event manager to automate tasks such as applying diverts on timers etc.  Using a cron-entry this works very well, though I always test the script in GNS3 first before applying.  One slight issue has bothered me is having to return to the device and tidy off the script so it doesn't run again the following year.  What if you told the script to delete itself, would it still work?

The answer is yes, further more you can delete the script mid-operation, the script is clearly not dependent on running-config once executed.  Here is an example, with an added line to remove the script:

event manager applet update_divert 
event none
action 1.0 cli command "enable"
action 2.0 cli command "config t"
action 3.0 cli command "voice translation-rule 89"
action 4.0 cli command "rule 5 /0121111111/ /3900/"
action 4.1 cli command "exit"
action 4.2 cli command "no dial-peer voice 3420 voip"
action 4.3 cli command "no event manager applet update_divert"
action 5.0 cli command "exit"
action 6.0 cli command "write mem"
action 8.0 cli command "exit"

R1#event manager run update_divert
R1#
*Mar  1 00:05:01.955: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : CTL : cli_open called.
*Mar  1 00:05:01.955: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : 
*Mar  1 00:05:01.971: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:01.971: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1>
*Mar  1 00:05:01.975: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1>
*Mar  1 00:05:01.975: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1>
*Mar  1 00:05:01.975: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : >enable
*Mar  1 00:05:02.039: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:02.039: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1#
*Mar  1 00:05:02.043: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : #config t
*Mar  1 00:05:02.079: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:02.079: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : Enter configuration commands, one per line.  End with CNTL/Z.
*Mar  1 00:05:02.079: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1(config)#
*Mar  1 00:05:02.079: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : #voice translation-rule 89
*Mar  1 00:05:02.115: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:02.115: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1(cfg-translation-rule)#
*Mar  1 00:05:02.115: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : #rule 5 /01224585599/ /3900/
*Mar  1 00:05:02.135: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:02.135: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1(cfg-translation-rule)#
*Mar  1 00:05:02.135: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : #exit
*Mar  1 00:05:02.151: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:02.151: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1(config)#
*Mar  1 00:05:02.155: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : #no dial-peer voice 3420 voip
*Mar  1 00:05:02.215: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:02.215: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1(config)#
*Mar  1 00:05:02.219: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : #no event manager applet update_divert
*Mar  1 00:05:02.331: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:02.331: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1(config)#
*Mar  1 00:05:02.335: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : #exit
*Mar  1 00:05:02.339: %SYS-5-CONFIG_I: Configured from console by  on vty0 (EEM:update_divert)
*Mar  1 00:05:02.347: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:02.347: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1#
*Mar  1 00:05:02.351: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : #write mem
*Mar  1 00:05:04.515: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:04.515: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : Building configuration...
*Mar  1 00:05:04.515: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : [OK]
*Mar  1 00:05:04.519: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1#
*Mar  1 00:05:04.519: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : #exit
*Mar  1 00:05:04.587: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : 
*Mar  1 00:05:04.587: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : OUT : R1>
*Mar  1 00:05:04.587: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : IN  : >exit
*Mar  1 00:05:04.591: %HA_EM-6-LOG: update_divert : DEBUG(cli_lib) : : CTL : cli_close called.

A quick check of running-config and yes, everything is updated and the script removed.  Nice and tidy.

Friday, 1 November 2013

IP SLA, Syslog and Embedded Event Manager

Cisco's Embedded Event Manager offers a huge amount of potential for introducing logic and control over your configurations.  Combining syslog and ip sla with EEM is quite a toolkit all told.  Recently I have used Event Manager and IP SLA to complete WAN cutovers with minimal intervention.  EEM can also be used quite effectively in remote situations where access will be terminated by virtual of the very change you wish to make - in addition to the usual "reload in 005" get-out-of-jail...

In this post we use the intervention of disgruntled and malicious employee, Dr Doom, by using his special login as a trigger.  As he logs in it creates a syslog message on R1.  Event Manager listens for this syslog and reconfigures the interface fa 0/0 from 1.1.1.1 to 2.2.2.1.  Over on R2 an ip sla is probing R1, when it goes down it configures its interface to 2.2.2.2, thus completing Dr Doom's mission to seize control of the network and gain corporate riches.  Ok, so its not a very realistic scenario.  Here is the, err, topology:


The important bits of config are below:

DR-MCCOY# 
username admin privilege 15 secret ...
username drdoom privilege 15 secret ...

track 1 ip sla 1 reachability

interface FastEthernet0/0
 ip address 1.1.1.1 255.255.255.0
 duplex auto
 speed auto

ip sla 1
 icmp-echo 2.2.2.2
 frequency 10
ip sla schedule 1 life forever start-time now

event manager applet drdoom 
 event syslog occurs 1 pattern "user: drdoom"
 action 1.0 syslog msg "Dr DOOM IS COMING!"
 action 2.0 cli command "en"
 action 3.0 cli command "conf t"
 action 4.0 cli command "int fa 0/0"
 action 5.0 cli command "ip add 2.2.2.1 255.255.255.0"
 action 6.0 syslog msg "DR DOOM INTERFACE RECONFIGURED"

event manager applet drdoom-success 
 event track 1 state up
 action 1.0 syslog msg "MISSION ACCOMPLISHED"

And on R2, DR-KIMBLE:

track 1 ip sla 1 reachability
 default-state up
 delay down 20 up 5

interface FastEthernet0/0
 ip address 1.1.1.2 255.255.255.0
 duplex auto
 speed auto

ip sla 1
 icmp-echo 1.1.1.1
 frequency 5
ip sla schedule 1 life forever start-time now

event manager applet drdoom 
 event track 1 state down
 action 1.0 cli command "en"
 action 2.0 cli command "conf t"
 action 3.0 cli command "int fa 0/0"
 action 4.0 cli command "ip add 2.2.2.2 255.255.255.0"
 action 5.0 syslog msg "DR DOOM RECONFIGURED THIS ROUTER"

This worked pretty well, Dr Doom succeeded in his dastardly plan, but it barely scratches the surface of either IP SLA or EEM, merely one practical use.  Ping however is not a great decider to be reconfiguring links by, so use with caution - pings can be lost for any number of reasons.  If you tune the parameters though you can introduce a greater degree of certainty, in this case my track object has a delay to 20 seconds before it is considered down, with a frequency of 5 seconds.  If you were doing this during an agreed change window you could also impose life restrictions on the ip sla schedule so it only started at the right time.

Beware Dr Doom.


Tuesday, 8 October 2013

Run Cisco ASA on GNS3

Everyone wants a toy ASA to practice on, right? Well you can with GNS3. This took me about 4 hours to get right.  Previously I had this working on a Windows box, however transferring the settings was far from pleasant.  In fact they just didn't work.

First, for some reason I am using Ubuntu 10.10.  I just like it, it is out of date, but still it works for me.  In order however to get GNS3 running on it I needed to install the new 0.8.3.1 package from source.  Well I didn't need to, I wanted to.  So this meant removing the working GNS3 installed by the package manager and running the new GNS3 from source.

Once it was all unpacked and worked out how to run it, the first major problem is Qemu was an out of date unpatched version.  I would highly recommend working from step 8 of this post if you are reading this looking to solve Qemu patching problems:


You may also have to install Zliblg-dev package during the make process.  Anyhow, blah blah.  There are quite a few guides to installing ASA on GNS3, this post is more to put my spin on actually starting a firewall.  So lets cut to the configs, assuming you can test correctly Qemu and Dynamips connections, then here we go...

The most important bit of code:

kernel cmd line: ide_generic.probe_mask=0x01 ide_core.chs=0.0:980,16,32 console=ttyS0,9600n8 bigphysarea=65536 auto nousb ide1=noprobe hda=980,16,32 root_dev=0x6802

Qemu options: -icount auto 

Anything but the above was causing it to fail.




Next give the ASA an interface an address and finally give it a name to correctly install it:

ciscoasa(config)# interface gigabitEthernet 0

ciscoasa(config-if)# ip address 192.168.77.1 255.255.255.0

ciscoasa(config-if)# nameif management0

Ok so.  You have a working ASA, but you want to use the ASDM, right?  Basically then you are going to have to tftp the ASDM software to the virtual device, so next we have to create a loopback node, have the ASA connect to that network and then do the needful.





And now to tftp the ADSM binary. Startup your preferred TFTP software, I like Pumpkin:

ciscoasa# copy tftp flash

Address or name of remote host []? 192.168.77.2

Source filename []? asdm-647.bin

Destination filename [asdm-647.bin]?

Accessing tftp://192.168.77.2/asdm-647.bin...!!!!...

Writing current ASDM file disk0:/asdm-647.bin !!!!...

17902288 bytes copied in 96.340 secs (186482 bytes/sec)

Now a few things to make it all work, enable the http server, allow http and create user credentials:

ciscoasa(config)# asdm image flash:asdm-647.bin

ciscoasa(config)# http server enable

ciscoasa(config)# http 192.168.77.1 255.255.255.255 management0

ciscoasa(config)# username nicholas password cisco priv 15

Now browse to https://192.168.77.1 or whatever you have and you should be able to install the
ASDM software, you will need the username/password above.



Thursday, 23 May 2013

Cisco Router for BT Infinity

Update: I have recently taken annoyance to some of the details on this post, so removed them.  I guess you will never know.

Well, it has to be said that BT Infinity fibre broadband is pretty awesome.  It also has to be said the BT Home Hub is pretty woeful.  It is actually pretty irritating, the a service so good can be controlled by something so bad.  Anyone with any self-respect will want to swap it out, and here is how.

First, you need to keep the NTE.  That is the white box.  You are going to connect this to the ethernet interface of your Cisco router - assuming it supports vdsl - and give it these commands:

interface FastEthernet0/0  - or whatever will be your WAN interface
 no ip address
 pppoe enable group global
 pppoe-client dial-pool-number 1

interface Dialer1
 ip address negotiated
 no ip unreachables
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication chap pap callin
 ppp chap hostname bthomehub@btbroadband.com
 ppp chap password 7 0117090D5704090435444F1D0A1102020208
 ppp pap sent-username bthomehub@btbroadband.com password 7 0117090D5704090435444F1D0A1102020208
 ppp ipcp dns request

ip route 0.0.0.0 0.0.0.0 Dialer1

You will of course need to NAT.  Now, like me, I didn't have a wireless router, but don't worry.  Plug a LAN port of the Home Hub into your Cisco network and simple disable DHCP on the Homehub.  The DHCP on your Cisco will give out the correct gateway and the Home Hub switch the wireless traffic.

Done.  Good work.

Monday, 29 April 2013

IPv6 Basics

IPv6 is now major part of the CCNP curriculum, therefore I had better be proficient and well-versed in its ways if I am to pass the exams.  For me there is no better to way to learn something than to get in the console and start using it - then the theory makes sense.  Everyone is different.  So in this lab I set a few simple goals to build familiarity with IPv6:

1.  Establish a pure IPv6 network
2.  Use an IPv6 IGP like EIGRP
3.  Create IPv6 BGP peerings using loopbacks
4.  Redistribution and route-filtering

Pretty simple stuff, but great to prove that simple stuff with IPv6 is no harder than simple stuff with IPv4.  Using this topology I set about my business.


IPv6 Network

This is the easy bit.  It takes a while to get used to using IPv6 addresses.  One simple tool is the global prefix command, this can save you a bit of typing and allow you to use "simpler" host addresses.  While at it you have to enabled IPv6 unicast routing as the other global setting.  In this instance my prefix will be called "abz1":

ipv6 general-prefix abz1 2001:AE12:1234::/48
ipv6 unicast-routing

Easy now to address the interfaces:

interface FastEthernet0/0
 ipv6 address abz1 ::1/120

I am using /120 masks, as this leaves 8 bits for hosts - a force of habit from the IPv4 world.  I find it far easier getting to grips with IPv6 by thinking as I would IPv4.

Once all the interfaces are configured, a ping test is required to test the links before adding in an IGP, note the command:

R1#ping ipv6 2001:AE12:1234::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:AE12:1234::2, timeout is 2 seconds:
!!!!!

EIGRP

Without labouring the point and attempting to rewrite the manual, EIGRP works more or less as it does in IPv4, with a few subtle differences.  First of all you need to configure the global settings, then instead of using the network command you must enable it on the interface:

ipv6 router eigrp 1
 eigrp router-id 1.1.1.1

interface FastEthernet0/0
 ipv6 address abz1 1::1/120
 ipv6 eigrp 1

Yes, it is kind of annoying to have to use an IPv4 router-id.  At this point EIGRP neighbor relationships are formed and routes exchanged, check this using the show ipv6 route eigrp command:

R1#show ipv6 route eigrp
IPv6 Routing Table - default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - Neighbor Discovery
D   2001:AE12:1234::2:0/120 [90/30720]
     via FE80::C80B:14FF:FEC8:8, FastEthernet0/0
D   2001:AE12:1234:0:3:3:3:3/128 [90/158720]
     via FE80::C80B:14FF:FEC8:8, FastEthernet0/0

BGP

Now for a jolly I wanted to add in BGP.  I added in two loopback 0s on either end of my network to establish the BGP peerings with: normal, sane practice.  A further couple of loopbacks were added to play with routes.

BGP commands for IPv6 are all accessed via the usual BGP way.  If you are at all familiar with BGP then it is actually quite intuitive, I did not have to lookup any commands despite never having created IPv6 BGP peers before:

router bgp 65000
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 2001:AE12:1234:0:3:3:3:3 remote-as 65000
 neighbor 2001:AE12:1234:0:3:3:3:3 update-source Loopback 0

Remember, if you are peering with loopbacks, you better use update-source.  Go into the IPv6 address family to activate the peers:

 address-family ipv6
  no synchronization
  network 2001:AE12:1234:0:1:1:1:1/128
  neighbor 2001:AE12:1234:0:3:3:3:3 activate
 exit-address-family

This was hunky dory.  Confirm the peers using a pretty similar command to IPv4:

BGP neighbor is 2001:AE12:1234:0:3:3:3:3,  remote AS 65000, internal link
  BGP version 4, remote router ID 3.3.3.3
  BGP multisession with 2 sessions (2 established), first up for 00:46:59
  BGP table version 1, neighbor version 1/0
  BGP table version 6, neighbor version 6/0

Route Manipulation

Finally I wanted to do some route filtering, just the utter basics.  First I configured 2x loopbacks on R3, one of the routes would be filtered.  I am using /128 masks.

interface Loopback100
 no ip address
 ipv6 address 2001:AE12:1234:0:4:4:4:4/128
!
interface Loopback101
 no ip address
 ipv6 address 2001:AE12:1234:0:5:5:5:5/128

As you might IPv4 next create the access-list and route-map:

route-map 6filter permit 10
 match ipv6 address bgp
!
ipv6 access-list bgp
 permit ipv6 host 2001:AE12:1234:0:4:4:4:4 any

Finally redistribute the connected interfaces to get those routes into BGP:

 address-family ipv6
  redistribute connected route-map 6filter

Over to R1 and check the filtering of the "4:4:4:4" range.

R1#show ipv6 route bgp
IPv6 Routing Table - default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - Neighbor Discovery
B   2001:AE12:1234:0:4:4:4:4/128 [200/0]
     via 2001:AE12:1234:0:3:3:3:3

There we have it, just the single route.  So there it is, really IPv6 is pretty easy to use, once you start using it.  I for one am itching to get some IPv6 address space, there really comes a time when you just have to say enough with the NAT issues...

Wednesday, 6 March 2013

GNS3 on Android


Having just received my new Nexus 4, what is the first question I should ask of it's quad-core snapdragon prowess?  That's right, will GNS3 work on it?  The answer is yes, yes indeed: you can emulate Cisco IOS on your smartphone.  And whilst I'm sure no-one will give the slightest hint of a monkey, here is an overview.

First you need to install Linux.  There are some pretty good apps for this, I'm using Complete Linux Installer as found in the Google Play store.  It will advise you to follow-up and install a terminal emulator and VNC client.  It is not a bad app; it will offer you the choice to install a number of distros, though if I'm honest my attempts at Ubuntu 10 failed, as did Debian.  The Ubuntu 12 image worked a treat.  Download that and unpack it to /sdcard/ubuntu.  As seen below. (Pointless screenshot, but I just discovered Ice Cream Sandwich has native screenshot built-in, so everything was being captured...)


So while you are downloading the Ubuntu image (in the working version I actually used Ubuntu 12) you can install Android Terminal Emulator and Android VNC Viewer.  Both great apps in their own right.


Once this is all installed you can run the Linux application and then configure it.  Tip: donate.  If you donate you will receive a key to open some extra options, most importantly setting the screen resolution.  The default resolution desktop looks pretty small on the Nexus 4 screen, the donation is worth it.  But anyway, here is a screenshot post-donation:


Next you will be given the option to launch the image, I advise you to press it.  Great!  Hop over to the terminal emulator and you will see you Linux device kick-starting.  You will need to enter in a new password, then basically that is that.  You are off.  As so:




This might be a good point to test network connectivity, as I needed to install a few more packages on the virtual machine to get GNS3 up and running (not least GNS3 itself).  Now, there is no reason this shouldn't work as the Linux system is a chroot image mounted in Android, so as long as your Android has network then so should your image.  But anyway, pings are great things, never miss an opportunity:


Ok, tickety boo, so next step is to open your VNC viewer and point it at localhost:5900 using the distro password ("ubuntu" - in this instance).  Lo and behold, a desktop will appear!  On the Nexus I found a resolution of 1280x768 was ok, though it needs slightly more tweaking, it was just good enough at the time.

Next, using the complicated VNC tools (you will just have to experiment, trust me) open up a terminal to install some packages.  I needed these packages:

sudo apt-get install gns3
sudo apt-get install telnet
sudo apt-get install konsole

The first is to obviously install GNS3 from the Ubuntu repos.  The second is to enable GNS3 telnet to the virtual router.  The third is to install konsole, as I was having real problems (or lazy solutions) getting xterm to work.  


Once all this is in place, don't forget GNS3 is nothing without root privilages.  Edit the shortcut command to read either: gksudo gns3 or in the case of the LXDE desktop I required gksu gns3  There are explanations on the net for this...

Now the application as root, otherwise = pain in the arse, it won't work very well.


Now GNS3 is actually running you can feel joy.  This is a good time to reflect on the fact and say to yourself, "GNS3 is running on my frikking smartphone!!".  Try not to fall over when the Dynamips connection tests ok - this is almost it, the last barrier.  Add in an IOS image which you can acquire via t'internet somehow, I use a 3700 image which has almost all the options I need to practice.



Finally you really need to mess around and get the terminal settings correct.  As I say, contrary to the below I ended up installing konsole and using the built-in GNS3 command.  The internet is full of alternatives if you wish.  Well, not full per se, but there are options, however it is fiddly on the smartphone and I'm all for path-of-least-resistance.


Giddy with excitement you can drag over a router and start it up.  If not giddy then at least be mildly amused.


Finally, console to your device.  I was really pleased to have emulated a Cisco router on my smartphone, I don't know exactly how practical it is, perhaps if you do a lot of public transport and like tiny screens (in addition to hating tablets/laptops) then this could be the solution for you. Otherwise it is pure gimmick.



Anyway, point proven, you can exit it by typing "exit" on the terminal emulator (below) and unlikely you will ever use it again.


Thanks for reading.  Really, if you  made it to the end, thanks.  Leave a comment, feel free!

Monday, 18 February 2013

Not So Pointless

Well, despite it all - despite the years of neglect and idle tip-tapping at keyboards - despite the extraordinary unlikeliness of it actually occuring - I have actually signed up to run the Aviemore 1/2 marathon.  Let that information sink in for a while, you are as shocked as I am.


JustGiving - Sponsor me now!

Testing Cisco 802.1X Authentication with VMWare & GNS3

Yet another snappy blog title. I had reason recently to test 802.1X interface authentication using a GNS3 emulated Cisco 3725 and Freeradius, so here it is, delightfully pointless and true to the spirit of Pointless Posts; I did this merely as I wanted to see how it worked. Creating the topology, as ever, is almost as much fun as actually making it work: I have used a VMWare virtual adapter to get the 802.1x compatibility; the virtual Cisco router acts as the authenticator joining the vmware adapter to the physical network. This is NOT very reliable on a wireless adapter, but it proves the point.

First of all I created a VMWare virtual adpater which we were going to use for 802.1X authentication.  See the below screenshots.

VMWare Virtual Adpater Settings

This is connected to a Cisco 3725 running virtually on GNS3. The other interface of this connects to wireless adapater, thus can connect to the radius:



 The Cisco config itself is really easy :
hostname Cisco3725
aaa new-model
aaa authentication dot1x default group radius
!
dot1x system-auth-control
!
##this interface connects to LAN of radius server
interface FastEthernet0/0
 ip address 192.168.1.10 255.255.255.0
 duplex auto
 speed auto
!
##this interface connects to client
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
 dot1x pae authenticator
 dot1x port-control auto
!
radius-server host 192.168.1.74 auth-port 1812 acct-port 1813 key testing123
Once the interfaces can see each other it asks for authentication details:

Network Authentication dialogue appears

However there was an initial failure, so followed the debug:
[suffix] No '@' in User-Name = "nicholas", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 3 length 6
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry nicholas at line 205
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING: Auth-Type already set.  Not setting to PAP
++[pap] returns noop
Found Auth-Type = EAP
# Executing group from file /usr/local/etc/raddb/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP NAK
[eap] NAK asked for unsupported type PEAP
[eap] No common EAP types found.
[eap] Failed in EAP select
++[eap] returns invalid
Failed to authenticate the user.
        expand: Bad! -> Bad!
Login incorrect: [nicholas/] (from client 192.168.1.10 port 0 cli 0050.56c0.0001) Bad!
Using Post-Auth-Type Reject
No common EAP type seemed to be the issue. This was caused by not compiling Freeradius with OpenSSL libraries so PEAP/TLS requirements were actually ignored in eap.conf. PEAP needs TLS needs OpenSSL. It was required then to install Openssl then recompile Freeradius from source. This was done and when run as root a certificate generated – if its not then there is your alarm bell – make sure to get the right key in eap.conf to match the “whatever” in server.crt (I did not first time…!) Eap.conf needs a few minor changes to make it work:
Eap {
default_eap_type = peap
}
Check TLS configuration too:
       tls {
                        #
                        #  These is used to simplify later configurations.
                        #
                        certdir = /etc/raddb/certs
                        cadir = /etc/raddb/certs

                        private_key_password = whatever
                        private_key_file = /etc/raddb/certs/server.pem
Finally it all works, the windows adaptor authenticates using mschapv2 through PEAP on the radius through the Cisco:

Successful authentication,

Sunday, 17 February 2013

How to Configure PPP Sessions for MPLS VPNs

Sometimes you have a problem which is relatively complicated however you don't have the scope or time to solve it. This is just such a problem which has been bugging me for a long time, simmering away since a job almost a year old: how do you get PPP sessions such as DSL subscribers into a private MPLS VPN? As it was never in the remit at the time I never solved it, despite that it stayed in the back of my mind. One rainy day I decided to get rid of it and solve the problem with a pleasant GNS3 lab, happy in the knowledge it was fairly pointless to do so. The solution, as ever, was satisfyingly simple: radius attributes. [And when I say, "solution", I mean, "my solution" - I am certain there are other methods which I would love to hear of.]

In this topology I've created an MPLS framework with one Customer VPN. A radius server was implemented using a VMWare running Freeradius connected via a dedicated VMware virtual network. An LNS router has been configured to terminate PPP sessions by using the Radius server for authentication, and a Cisco 2600 is used as the PPP client. It goes without saying none of the below is of production quality, it is rough-and-ready lab to prove the point.


Ok so the PPP client is relatively straight-forward. The router PPPoEClient is desired to be in a VPN with CustA1 router. Both these routers have default routes for simplicity with BGP distributing VPN routes at the PE.
interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
encapsulation ppp
no ip mroute-cache
dialer pool 1
ppp authentication chap pap callin
ppp chap hostname nicholas
ppp chap password 0 nicholas
ppp pap sent-username nicholas password 0 nicholas
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
pppoe enable
pppoe-client dial-pool-number 1
So far so good. Next in the chain is the LNS router. Well, ahem, you might expect it be called an LNS in a production environment, however we're not actually terminating L2TP tunnels in this lab. I mean, come on. I am having a bit of brain-freeze as to what this should actually be called, if I remember I will come back to it.

Anyway, lets look at the problem. In the project environment all PPP subscribers will be terminating their PPP sessions in a common VRF due to whatever the virtual-template has decided for them. In my lab environment it doesn't really matter if the PPP subscribers mix with the global routing table, so to save time I haven't given the virtual-template any VRF context:
interface FastEthernet0/1
no ip address
duplex auto
speed auto
pppoe enable group global
!
interface Virtual-Template2
mtu 1472
ip unnumbered Loopback0
no ip redirects
ip tcp adjust-mss 1452
no peer default ip address
ppp authentication pap chap
ppp direction callin
But this particular subscriber has paid for an MPLS VPN so we require them to authenticate their session on the Radius and for routing appear in a private VRF, which I have cryptically called, "vpn1". Here is a selection of MPLS configuration for the lab:
ip vrf vpn1
rd 65001:1
vpn id 1:1
route-target export 1:1
route-target import 1:1
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
redistribute connected 
neighbor mpls peer-group
neighbor mpls remote-as 65000
neighbor mpls update-source Loopback0
neighbor 10.0.0.1 peer-group mpls
neighbor 10.0.0.2 peer-group mpls
neighbor 10.0.0.3 peer-group mpls
neighbor 10.0.0.4 peer-group mpls
no auto-summary
!
address-family vpnv4
neighbor mpls send-community both
neighbor 10.0.0.1 activate
neighbor 10.0.0.2 activate
neighbor 10.0.0.3 activate
neighbor 10.0.0.4 activate
exit-address-family
!
address-family ipv4 vrf vpn1
redistribute connected
no synchronization
network 172.16.0.0
network 172.30.3.0 mask 255.255.255.0
exit-address-family
The LNS also has a loopback in the private VRF, but why, what is it for?
interface Loopback5
ip vrf forwarding vpn1
ip address 172.16.6.1 255.255.255.255
We will find out soon. So all this config is great, but it doesn't work, the customer will appear in the global routing table. The answer to my pondering was happily simple: radius. So first it might be nice just to see the users file in Freeradius, thats the kind of useful stuff people come to blogs for:
nicholas Cleartext-Password := "nicholas"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 172.16.3.33,
Framed-IP-Netmask = 255.255.255.255,
Framed-Routing = Broadcast-Listen,
Framed-Compression = Van-Jacobsen-TCP-IP,
Cisco-AVPair="lcp:interface-config#1=ip vrf forwarding vpn1",
Cisco-AVPair+="lcp:interface-config#2=ip unnumbered loopback 5"
The spoiler is the Cisco-AVPair config. You can probably leave now. No, really, you want to stay? Wow. Ok. For those staying, the LNS radius config looks like this (Please note the 192.168.1.0/24 subnet connecting the radius and LNS is not to be confused with the VPN 192.168.1.0/30 subnet - which I dont think you know about anyway, well, its between CustA1 and MPLS1, so you know now):
aaa new-model
!
aaa authentication ppp default group radius
aaa authorization network default group radius local 
aaa accounting exec default
 action-type start-stop
 group radius
!
ip radius source-interface FastEthernet0/0 
!
radius-server host 192.168.1.74 auth-port 1645 acct-port 1646 non-standard key nicholas
And so to the solution. I am using Freeradius, it is familiar and easy to manage. The server itself is fairly simple to set-up. Using a wireless adapter to bridge the radius and LNS is a frustrating process, you can use a loopback and layer3 bridge however if you actually dont need to see the network on your LAN - which we all have to admit is kind of fun - then just connect both the vmware and GNS to a vmware host-only network.



And now let us behold the successful PPP negotiation (takes a wee while to debug so it does):


Now we can see the VPN routes on one of the MPLS switches:


With the critical AV-Pairs passing the virtual-template the required details the virtual-access interface is the right VRF. On the working model it is interesting to see how IOS builds the configuration with your radius values.  "Derived configuration", that is a nice touch rarely seen I would suspect :-)


Ok enough, finally can one side ping the other?


Great, so finally I solved my simple problem.  I hope this has been informative and I'd like to thank you for reading.  [Dear CBT, that's not trademarked is it??]

Wednesday, 30 January 2013

Pointless CCNP Topology Part 2

Welcome back to the second part of this most pointless GNS3 topology. In the previous post we covered lots of ground which should have proven beyond all doubt the pointlessness of the task in hand, and in this post we will continue to drive the nail home. It is however my opinion there are at least one or two items of interest in the second part of Linearnet, such as BGP, PBR, tunnels, 4over6 and the like. Interesting, but still without point.  Let us remind ourselves of the wonderful topology...



What a wonder of science.  However let us proceed where we left off, about hop R10.

R10 - R11 BGP


Although on the face of it this could be just another redistribution - and it is - one small fact made it interesting, which was iBGP will only redistribute eBGP routes into another IGP by default. This is to prevent routing-loops, however in the case of Linearnet, good-luck trying. Other than this the config is elementary (you'd think for all this effort I might throw in something tough, eh?)

R10
router bgp 65000
neighbor group1 peer-group
neighbor group1 remote-as 65000
neighbor 10.10.10.10 peer-group group1
!
address-family ipv4
redistribute eigrp 1
neighbor 10.10.10.10 activate
no auto-summary
bgp redistribute-internal
exit-address-family

R11 - R11.5 - R12 Policy-based Routing


At this point I decided to have a break from the seemingly mindless route-redistribution scenarios and do something different in the form of Policy-based Routing. Strictly speaking this was going to make a mockery of the lab title "Linearnet", however I am hoping no-one will notice - it's more of a roundabout than anything else anyway. Quite simply we want all traffic from 1.1.1.1 (Home) passing through router R11 to go via R11.5. This would take a simple access-list, route-map, set-next-hop and apply the ip policy to the incoming interface fa0/0. Like so:

R11
interface FastEthernet0/0
 ip address 10.10.10.11 255.255.255.0
 ip policy route-map pbr1

route-map pbr1 permit 10
 match ip address 1
 set ip next-hop 11.11.115.115

access-list 1 permit 1.1.1.1

All three routers - R11, R11.5 and R12 - are in the same EIGRP AD, by the way. And here are the relevant traceroutes, one before the policy applied, one after (check out hops 11 and 12 on the latter):
Home#trace 14.14.14.15 
Type escape sequence to abort. Tracing the route to 14.14.14.15 
Home#trace 14.14.14.15

Type escape sequence to abort.
Tracing the route to 14.14.14.15

  1 1.1.1.2 28 msec 4 msec 16 msec
  2 2.2.2.3 24 msec 8 msec 32 msec
  3 3.3.3.4 24 msec 40 msec 36 msec
  4 4.4.4.5 64 msec 32 msec 68 msec
  5 5.5.5.6 52 msec 40 msec 64 msec
  6 6.6.6.7 40 msec 68 msec 36 msec
  7 7.7.7.8 44 msec 68 msec 64 msec
  8 8.8.8.9 64 msec 64 msec 72 msec
  9 9.9.9.10 64 msec 100 msec 68 msec
 10 10.10.10.11 88 msec 60 msec 68 msec
 11 11.11.11.12 160 msec 88 msec 100 msec
 12 192.168.1.1 72 msec 188 msec 140 msec
 13 192.168.1.1 116 msec 88 msec 96 msec
 14 14.14.14.15 104 msec *  160 msec
Home#trace 14.14.14.15

Type escape sequence to abort.
Tracing the route to 14.14.14.15

  1 1.1.1.2 16 msec 40 msec 12 msec
  2 2.2.2.3 20 msec 28 msec 28 msec
  3 3.3.3.4 40 msec 28 msec 40 msec
  4 4.4.4.5 20 msec 84 msec 28 msec
  5 5.5.5.6 28 msec 56 msec 60 msec
  6 6.6.6.7 40 msec 60 msec 44 msec
  7 7.7.7.8 64 msec 64 msec 48 msec
  8 8.8.8.9 124 msec 84 msec 68 msec
  9 9.9.9.10 92 msec 72 msec 160 msec
 10 10.10.10.11 116 msec 76 msec 52 msec
 11 11.11.115.115 140 msec 88 msec 108 msec
 12 11.115.115.12 80 msec 68 msec 80 msec
 13 192.168.1.1 112 msec 112 msec 100 msec
 14 192.168.1.1 76 msec 92 msec 152 msec
 15 14.14.14.15 84 msec *  104 msec
The return route from Office to Home does of course take the preferable R12-R11 route, so just a small diversion on Linearnet.

R12 - R13 - R14 IPSec VPN


As we all now know - since I filled in the gap - a routing protocol will not work over an IPSec tunnel. It will however work over a GRE tunnel, and GRE over IPSec of course. So lets have one of those please. The config is as basic as it gets, without the "need" to do any NATing either so no thoughtful accecss-lists - just one to match the GRE tunnel packets. Here is the config on R14, much the same on R12.


R14
crypto isakmp policy 10
authentication pre-share
crypto isakmp key linearnet address 12.12.12.12
!
crypto ipsec transform-set linearset esp-3des esp-sha-hmac
mode transport
!
crypto map 4over6 10 ipsec-isakmp
set peer 12.12.12.12
set transform-set linearset
match address 150
!
access-list 150 permit gre host 192.168.1.1 host 192.168.1.2
!
interface Tunnel0
crypto map 4over6

The EIGRP neighbor came up nicely through the ipsec tunnel and routes in the chain continue.

R14 - R15 - OFFICE IPv4 over IPv6


Woohoo, it is nearly the end!! I wanted to do a bit of IPv6 to show how easy it is, which we all of course know anyway, right? Hopefully IPv6 will really begin to pick up pace and become available on major ISPs, until this point only a few early-adopters will be using it, and then I would imagine just for the heck, not because they need to. In the future as IPv6 becomes the norm I can see plenty of retrograde scenarios where aging networks cling-on to IPv4 address-space until the dinosaurs which manage them become instinct (there may of course be other, equally legitimate reasons). Enter the need for IPv4 over IPv6 - the tunnel of the future! Whilst we're all tunneling IPv6 over IPv4 just now, pay attention because this is coming.

Quick description: R14 and OFFICE act as the tunnel endpoints via R15. IPv6 static routes on both these routers point the way (could've used an IGP). The tunnel interfaces have IPv4 address and dont forget "tunnel mode ipv6" command or it won't work.

R14

interface Tunnel1
ip address 14.14.14.14 255.255.255.0
tunnel source 2000:14::14:1
tunnel destination 2000:15::15:2
tunnel mode ipv6
!
interface FastEthernet0/0
ipv6 address 2000:14::14:1/64
!
ipv6 route 2000:15::/64 2000:14::14:2


R15
interface FastEthernet0/0
ipv6 address 2000:14::14:2/64
!
interface FastEthernet0/1
ipv6 address 2000:15::15:1/64

OFFICE
interface Tunnel1
ip address 14.14.14.15 255.255.255.0
tunnel source 2000:15::15:2
tunnel destination 2000:14::14:1
tunnel mode ipv6
!
interface FastEthernet0/0
ipv6 address 2000:15::15:2/64

Conclusion


It is a fairly pointless network, however it has been a good practice, and if you learn one small thing each lab, then that is a result - what is the point labbing things you already know? I have learnt small things about redistribution, tiny things about IPv6...ok so not much else. I've also learnt you can run 15 GNS routers on cloud-hosting with only 2Gb RAM, a 2.5Ghz processor and a trusty Ubuntu 10.10 installation! Thank you for reading, I hope it has been mildly diverting. And finally, to conclude where it all began, here is the backward traceroute:

OFFICE#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
1 14.14.14.14 16 msec 28 msec 36 msec
2 192.168.1.2 48 msec 52 msec 24 msec
3 11.11.11.11 100 msec 52 msec 20 msec
4 10.10.10.10 100 msec 52 msec 24 msec
5 9.9.9.9 68 msec 44 msec 64 msec
6 8.8.8.8 40 msec 120 msec 56 msec
7 7.7.7.7 96 msec 56 msec 100 msec
8 6.6.6.6 56 msec 84 msec 96 msec
9 5.5.5.5 104 msec 88 msec 124 msec
10 4.4.4.4 68 msec 116 msec 44 msec
11 3.3.3.3 148 msec 100 msec 132 msec
12 2.2.2.2 88 msec 140 msec 96 msec
13 1.1.1.1 156 msec * 96 msec

Tuesday, 29 January 2013

Pointless CCNP Topology Part 1

Here I offer my contribution to the seemingly endless supply of pointless GNS3 topologies abounding the internet.  Not content however with merely attaining completely pointless status by default of not trying - or being too stupid - I have pushed the boat out and purposely designed the most pointless topology I could imagine.  This chaps is how I study for my CCNP exams - embroiled in futile mastery of pointless subject matter.  Behold:  Linearnet!


It took a while, and to be honest the burden of pointlessness was wearing me down, so it was a pleasing sight to finally see the traceroute working correctly.  You will note its VPN hop skipping the 13.13.13.0/24 network and the IPv6 tunnel hides 15.15.15.0/24. Here is the traceroute, and I warn you, if you get bored easily stop reading here.

OFFICE#ping 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 100/124/164 ms

OFFICE#traceroute 1.1.1.1

Type escape sequence to abort.

Tracing the route to 1.1.1.1

  1 14.14.14.14 16 msec 32 msec 12 msec

  2 192.168.1.2 12 msec 80 msec 28 msec

  3 11.11.11.11 72 msec 24 msec 40 msec

  4 10.10.10.10 72 msec 60 msec 36 msec

  5 9.9.9.9 104 msec 92 msec 56 msec

  6 8.8.8.8 52 msec 80 msec 92 msec

  7 7.7.7.7 68 msec 48 msec 104 msec

  8 6.6.6.6 72 msec 84 msec 60 msec

  9 5.5.5.5 96 msec 92 msec 56 msec

 10 4.4.4.4 88 msec 100 msec 112 msec

 11 3.3.3.3 112 msec 92 msec 140 msec

 12 2.2.2.2 112 msec 96 msec 148 msec

 13 1.1.1.1 100 msec *  112 msec

That this even works at all is something of a wonder to me, what with it being emulated on a dual-core, cloud-hosted linux server.  If you read my previous posts you will see I have the potential to leverage 20Ghz and 8Gb RAM, however all this nonsense is powered by a mere 2.5Ghz dual-core and 2GB RAM.  Wowser!

However, read on.  Read on and you may be alarmed to discover an increasing degree of potentially interesting facts about varied networking matters - mostly redistribution - which actually could be of some use to someone.  For example, did you know iBGP won't redistribute another IGP by default?  Did you know ISIS doesn't like to inject connected routes into itself for redistribution?  I didn't.  So, without further ado, here is the story of Linearnet...

HOME - R2


Nothing really to note here, certainly nothing of interest.  To start the ball-rolling I gave the home router a static route.  I suppose in order to not be so pointless and fulfill some of the CCNP curriculum I could've used a  dynamic routing protocol and fed this router a default route.  Or maybe you should just see the OSPF configuration NSSA Area1 for that...

R2
interface FastEthernet0/0
ip address 1.1.1.1 255.255.255
!
ip route 0.0.0.0 0.0.0.0 1.1.1.2

R2 - R3 OSPF Area 1 NSSA

This leg was designed to be a NSSA of an OSPF domain.  It would be injecting its connected interface to HOME into OSPF NSSA Area 1 whilst receiving OSPF inter-area routes and a default route injected from R3 using the default-information-originate command. It made for a wee bit of a strange routing table.

R2
interface FastEthernet0/1
 ip address 2.2.2.2 255.255.255.0
 ip ospf 1 area 1
!
router ospf 1
redistribute connected subnets
area 1 nssa
R3
interface FastEthernet0/0
 ip address 2.2.2.3 255.255.255.0
 ip ospf 1 area 1
!
interface FastEthernet0/1
 ip address 3.3.3.3 255.255.255.0
 ip ospf 1 area 0
!
router ospf 1
area 1 nssa default-information-originate

R3 - R4 OSPF Backbone


This is the OSPF backbone.  Nothing at all of interest here.  Move on, move on.  Instead of seeing the interface configuration, perhaps you would like to see the NSSA E2 route?  I thought so:

R3
R3#show ip route 1.1.1.1
Routing entry for 1.1.1.0/24
  Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 10
  Last update from 2.2.2.2 on FastEthernet0/0, 00:10:20 ago
  Routing Descriptor Blocks:
  * 2.2.2.2, from 2.2.2.2, 00:10:20 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

R4 -R5 OSPF Area 2 Virtual Link


The plan here was a plain-old OSPF area. It would however act as transit for area 3 via the virtual-link commands, therefore could not be stubby, neither totally or not so. You can imagine the interface config by now, I'm sure, here are the simple virtual-links R4
router ospf 1
 router-id 4.4.4.4
 area 2 virtual-link 5.5.5.5
R5
router ospf 1
 router-id 5.5.5.5
 area 2 virtual-link 4.4.4.4
And proof if it were needed: R5
R5#show ip ospf virtual-links 
Virtual Link OSPF_VL0 to router 4.4.4.4 is up
  Run as demand circuit
  DoNotAge LSA allowed.
  Transit area 2, via interface FastEthernet0/0, Cost of using 10
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:01
    Adjacency State FULL (Hello suppressed)
    Index 1/2, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

R5 - R6 OSPF Area 3


A simple OSPF area connected to the backbone via virtual-links.  Lets check the neighbor on R5, see that the virtual interface has been made happy with the backbone:

R5
R5#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           0   FULL/  -           -        4.4.4.4         OSPF_VL0


R6 - R7 RIP/OSPF Redistribution


Primarily for a laugh I decided to put a RIP hop in, but also to make the project more epic and silly. Redistribution is simple.

R6
router rip
 version 2
 redistribute ospf 1 metric 1
 network 6.0.0.0

R7 - R8 EIGRP Redistribution


Yawn, more redistribution. It is a theme of this labathon. You know how to redistribute into RIP, here is from RIP into EIGRP, blindingly simple just remember to invent a metric: R7
router eigrp 1
 redistribute rip metric 100 100 255 50 1500
 network 7.7.7.7 0.0.0.0
 auto-summary

R8 - R9 ISIS


You are still with me right? Guess what - redistribution. This time into ISIS. ISIS is slightly more interesting, it throws up a tiny problem to solve in that ISIS when being redistributed into say EIGRP or OSPF doesn't offer up it's connected route from that router ISIS is enabled on. If that makes sense, sounds a bit dumb. Perhaps if you see the redistribution command on EIGRP it will make sense... R8
router eigrp 1
 redistribute connected
 redistribute isis level-2 metric 1 1 1 1 1
 network 7.7.7.8 0.0.0.0
 no auto-summary
!
router isis 
 net 49.0001.0000.0000.000a.00
 is-type level-2-only
 redistribute eigrp 1 metric 10

R9 - R10 Port Channel


Things are starting to hot up now - relatively speaking and whilst still being totally and utterly without point. Bored with daisy chaining routing protocols together I decided to throw in a tiny bit of lan stuff and use the GNS3 emulation of NM-16ESW switch module. Binding 3 Fa interfaces together under one port-channel was the order of the day, using ISIS to share routing on VLAN interfaces. Lets see the config on R9, you can then guess R10 I would think:

R9
interface Port-channel1
 switchport mode trunk
!
interface FastEthernet0/0
 ip address 8.8.8.9 255.255.255.0
 ip router isis 
 duplex auto
 speed auto
!
interface FastEthernet1/0
 switchport mode trunk
 channel-group 1 mode on
!
interface FastEthernet1/1
 switchport mode trunk
 channel-group 1 mode on
!
interface FastEthernet1/2
 switchport mode trunk
 channel-group 1 mode on
!
interface Vlan2
 ip address 9.9.9.9 255.255.255.0
 ip router isis 
!
router isis 
 net 49.0002.0000.0000.000b.00
 is-type level-2-only

R10 - R11 BGP


Actually cooking with gas now. I suppose there is a fair amount going on at this hop. We have the port-channel interfaces, we have the vlan interfaces, we have ISIS and we have BGP, with mutual redistribution between the two. You've see the port-channel config. The BGP config is actually quite - dare I say it - interesting. Useful even. iBGP has a couple of wee caveats to make it work nicely, especially in this topology. It is worth taking a deep-breath and breaking this post into two. See you in part 2 for BGP, policy-routing, IPSec tunnels, IPv4 over IPv6 (in defiance of the norm - one day all you retrograde IPv4 die-hards will be doing it) and the final end to this misery. Thank you for reading (if you got this far).

Serverlove API - Python


To complete my adventure into the Serverlove GUI I ditched the batchfile and made a wee python script and converted that to exe, much nicer than bat files.  Not that I am much of a programmer - this is still well within the bounds of Pointless Posts.  I mean, to turn on and off a server I could just use the website control-panel, right?  The time I have wasted doing this would probably fuel several years worth of logging onto the portal and clicking the icon.  Utterly pointless, is all this.  Please note some details like, eh, passwords, have been changed.


import requests

from requests.auth import HTTPBasicAuth

user = 'a279f838-1234-1234-1234-277b1f414501'

password = '9nzfwh2atZcidontthinksoPfYqwgUGuGb8j6'

print "Please choose from the following options:\n\n\n(1) Start VPN Server\n\n(2) Stop VPN Server\n\n"

while True:

   try:

      choice = int(raw_input("Type here:"))

   except ValueError:

      print "Try Again"

   finally:

     if choice == 1:

      r = requests.post('https://api.z1-man.serverlove.com/servers/775f7bcb-7f07-1234-1234-af1fa8dc1fd9/start', auth=(user, password))

      print r.text

     elif choice == 2:

      r = requests.post('https://api.z1-man.serverlove.com/servers/775f7bcb-7f07-1234-1234-af1fa8dc1fd9/stop', auth=(user, password))

      print "Killing the VPN Server...\n"

     else:

       print "Hey that isnt an option yet!\n"



print r.url

print r.text

Serverlove API - Batch File


How is it possible to start/stop a remote server?  Easy.  Now a simple batch-script (which I will convert to exe) and job is done, clickable icons to turn on and off VPN server and GNS3!

@echo OFF

echo Stopping VPN Server....

@echo OFF
curl -v -i -H "Accept: application/json" -H "Content-Type: application/json" -u
username:password -X POST -k
https://api.z1-man.serverlove.com/servers/server-id/stop > nul 2>&1
Pause

And do now we can simply run a batch file to get the server running.  Pretty straight-forward, but it needs to be improved!


The BAT file in action.

Serverlove API - Curl

Ok so now  I have a Linux PPTP VPN server ready to rock on demand.  Please see my previous post on the PPTP business.  All it needs is it to be automated, because I need to make this simple to use for my "users".  I.e. I want a simple way to start and sstop the server - keeping it running costs money.

Enter in the Serverlove API.  It has a standard REST API which accepts JSON or text commands, check the site for details.  For testing (and execution) I have installed Curl for Windows.  I spent quite a while trying to get the right call and Curl options, which was failing as the server "name" is actually a massive long string of numbers on the settings page, not actually the "name" of it, so the call kept failing.  After the usual belligerent attempts, the 5 minute break then reading the instructions I managed to get Curl to make successful calls to turn on and off the servers, on demand!  Yay.  It looks a bit like this from the command line:

curl -v -i -H "Accept: application/json" -H "Content-Type: application/json" -u username:password -X POST -k https://api.z1-man.serverlove.com/servers/SERVER/start

It is actually pretty straightforward - there is quite a good API there if you need to do remotey-on-demandy things to servers etc.  My tip is where the url says," .../servers/SERVER/start", then insert the servers UID.

Linux PPTP Gateway

I've been looking for a suitable environment for my GNS3 software, it is fairly intensive and my laptop isn't really up to it.  What with being stuck abroad also I need a VPN gateway back to the UK so we can, err, stream "content" from the fair Isle.  VPN gateway providers are easily blacklisted, so I wanted my own solution.  I did try EC2 however it is also detected as have Irish origins - which is correct - so this was no good.  Enter Serverlove, by Melbourne Hosting.  Always highly-rated Melbourne hosting so I expected the same from their cloud offering.  Having a VPN server on demand along with a GNS3 server would be ideal, even better as its on demand I could ram up the CPU cycles to something mental like 20GHz if really required.

On-demand 20GHz. processing, 8GB RAM for 32p an hour.  Serious bargain.

PPTP Server


So first of all I needed a PPTP server.  This was fairly easily achieved through some basic trial and error, I'm not a VPN expert but I know enough.

The first thing you must do is install pptpd.  Now, this is pretty easy:

root@ubuntu:/etc/ppp# sudo apt-get install pptpd

Yawn.  Hard life.  Now, you need to edit pptpd.conf which in my case was found in /etc...

root@ubuntu:/etc/ppp# nano /etc/pptpd.conf

You want to be adding in your networks here:

localip 192.168.10.1
remoteip 192.168.10.99-245

My file references the location option /etc/ppp/pptpd-options for which you can make a few tweaks, here however I simply added in the Google DNS

ms-dns 8.8.8.8
ms-dns 8.8.4.4

Now to make the users, which is found in /etc/ppp/chap-secrets

# client        server  secret                  IP addresses
nick    pptpd   xyzpass 192.168.10.100

Now I had a bit of problem, I believe you should be tab separating this file, I will need to confirm this though.

All that remained is to add in a NAT statement and start the pptp server:

root@ubuntu:/etc/ppp# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Nice.  Ok.  So how about GNS3?  I had to stick with my trusty Ubuntu 10.10.  Launching another instance and installing GNS3 is fairly straightforward, though as 10.10 is pretty out of date the UK repos were playing up so you might have to change locations.  Just remember to save yourself the hassle and edit the GNS icon to launch as root:  gksudo gns3...

The when configuring your GNS3 chmod your image/project directories to allow your user account access, otherwise its annoying (I find).

Also, you have your own ISO images, right?