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?)

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

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 (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:

interface FastEthernet0/0
 ip address
 ip policy route-map pbr1

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

access-list 1 permit

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):
Type escape sequence to abort. Tracing the route to 

Type escape sequence to abort.
Tracing the route to

  1 28 msec 4 msec 16 msec
  2 24 msec 8 msec 32 msec
  3 24 msec 40 msec 36 msec
  4 64 msec 32 msec 68 msec
  5 52 msec 40 msec 64 msec
  6 40 msec 68 msec 36 msec
  7 44 msec 68 msec 64 msec
  8 64 msec 64 msec 72 msec
  9 64 msec 100 msec 68 msec
 10 88 msec 60 msec 68 msec
 11 160 msec 88 msec 100 msec
 12 72 msec 188 msec 140 msec
 13 116 msec 88 msec 96 msec
 14 104 msec *  160 msec

Type escape sequence to abort.
Tracing the route to

  1 16 msec 40 msec 12 msec
  2 20 msec 28 msec 28 msec
  3 40 msec 28 msec 40 msec
  4 20 msec 84 msec 28 msec
  5 28 msec 56 msec 60 msec
  6 40 msec 60 msec 44 msec
  7 64 msec 64 msec 48 msec
  8 124 msec 84 msec 68 msec
  9 92 msec 72 msec 160 msec
 10 116 msec 76 msec 52 msec
 11 140 msec 88 msec 108 msec
 12 80 msec 68 msec 80 msec
 13 112 msec 112 msec 100 msec
 14 76 msec 92 msec 152 msec
 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.

crypto isakmp policy 10
authentication pre-share
crypto isakmp key linearnet address
crypto ipsec transform-set linearset esp-3des esp-sha-hmac
mode transport
crypto map 4over6 10 ipsec-isakmp
set peer
set transform-set linearset
match address 150
access-list 150 permit gre host host
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.


interface Tunnel1
ip address
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

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

interface Tunnel1
ip address
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


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:

Type escape sequence to abort.
Tracing the route to
1 16 msec 28 msec 36 msec
2 48 msec 52 msec 24 msec
3 100 msec 52 msec 20 msec
4 100 msec 52 msec 24 msec
5 68 msec 44 msec 64 msec
6 40 msec 120 msec 56 msec
7 96 msec 56 msec 100 msec
8 56 msec 84 msec 96 msec
9 104 msec 88 msec 124 msec
10 68 msec 116 msec 44 msec
11 148 msec 100 msec 132 msec
12 88 msec 140 msec 96 msec
13 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 network and the IPv6 tunnel hides Here is the traceroute, and I warn you, if you get bored easily stop reading here.


Type escape sequence to abort.

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


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


Type escape sequence to abort.

Tracing the route to

  1 16 msec 32 msec 12 msec

  2 12 msec 80 msec 28 msec

  3 72 msec 24 msec 40 msec

  4 72 msec 60 msec 36 msec

  5 104 msec 92 msec 56 msec

  6 52 msec 80 msec 92 msec

  7 68 msec 48 msec 104 msec

  8 72 msec 84 msec 60 msec

  9 96 msec 92 msec 56 msec

 10 88 msec 100 msec 112 msec

 11 112 msec 92 msec 140 msec

 12 112 msec 96 msec 148 msec

 13 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...


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...

interface FastEthernet0/0
ip address 255.255.255
ip route

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.

interface FastEthernet0/1
 ip address
 ip ospf 1 area 1
router ospf 1
redistribute connected subnets
area 1 nssa
interface FastEthernet0/0
 ip address
 ip ospf 1 area 1
interface FastEthernet0/1
 ip address
 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#show ip route
Routing entry for
  Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 10
  Last update from on FastEthernet0/0, 00:10:20 ago
  Routing Descriptor Blocks:
  *, from, 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
 area 2 virtual-link
router ospf 1
 area 2 virtual-link
And proof if it were needed: R5
R5#show ip ospf virtual-links 
Virtual Link OSPF_VL0 to router 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#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface           0   FULL/  -           -         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.

router rip
 version 2
 redistribute ospf 1 metric 1

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

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
 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:

interface Port-channel1
 switchport mode trunk
interface FastEthernet0/0
 ip address
 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
 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:


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

   except ValueError:

      print "Try Again"


     if choice == 1:

      r ='', auth=(user, password))

      print r.text

     elif choice == 2:

      r ='', auth=(user, password))

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


       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 > nul 2>&1

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

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:


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


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

# client        server  secret                  IP addresses
nick    pptpd   xyzpass

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?