Wednesday, 23 December 2015

Friday, 22 May 2015

IOS Conundrum

I haven't posted anything in a long time, despite this I have oceans of Pointless material I could well waste time sharing with the world.  Today however I have stumbled across some very epic pointlessness on the Cisco IOS CLI that demands to be shared.  Behold (all usernames and passwords very slightly changed):

hostnameX(config)#username aussiesrus priv 3 secret thr0sn@gs0nbBq
Replacing <username aussiesrus priv 3 secret thr0sn@gs0nbBq> with <username aussiesrus priv 3 secret thr0sn@gs0nbBq>

Dear Cisco,


Thursday, 19 June 2014

HSRP and Static Route

I don't use HSRP often, but it does fill a very handy gap in certain situations.  I had a strange scenario recently with mulitple HSRP groups and a static route which wouldn't behave.

We have two gateways, both "inside" interfaces have two HSRP groups, so that the client can load-balance a bit more effectively.  Here's a bad picture:

The scenario is actually a bit more complicated than this in reality, but for the rough and ready sake of this post it will do.  Here is R1 and R2 fa 0/1 "inside" configuration:

interface FastEthernet0/1
 ip address
 ip nat inside
 standby use-bia
 standby 1 ip
 standby 1 preempt
 standby 1 track FastEthernet0/0 20
 standby 2 ip
 standby 2 priority 99
 standby 2 preempt
 standby 2 track FastEthernet0/0 20

interface FastEthernet0/1
 ip address
 ip nat inside
 standby use-bia
 standby 1 ip
 standby 1 priority 99
 standby 1 preempt
 standby 1 track FastEthernet0/0 20
 standby 2 ip
 standby 2 preempt
 standby 2 track FastEthernet0/0 20

So that's fine isn't, we have R1 as "priority" for group 1 and standby for group 2 - vice versa for R2.  Note the "use-bia" command, this is required when, as Cisco say, "controllers in low-end products can only have a single unicast Media Access Control (MAC) address in their address filter. These platforms only permit a single HSRP group, and they change the interface address to the HSRP virtual MAC address when the group becomes active. Load sharing on platforms with this limitation is not possible with HSRP."  Which is exactly what was happening - despite HRSP being completely aware of changed priorities, without use-bia multiple groups did not function.

Anyway, blah, blah.  To the point, if there is one.  Due to a multiple VPN issue where we'd have both gateways establishing a session back to head-office it was decided not to load-balance the subnets on the other side of the VPN, so all clients must use the active group 1 virtual gateway when sending traffic via VPN.  So how to achieve this?  Well, I thought, first I will put a static route on R2 pointing the VPN subnet at the group 1 address:

ip route

This works, but what happens when R2 becomes active for group 1, this static route will then have a next-hop of itself.  What would happen, would it ignore the static route?  It tried it, the static route persisted, though note I could not add additional static routes due to next-hop error (also please ignore the next-hop fa 0/0 on the default route, I wouldn't normally...):

*Jun 19 22:59:54.587: %HSRP-5-STATECHANGE: FastEthernet0/1 Grp 1 state Standby -> Active

R2#show ip route

Gateway of last resort is to network is subnetted, 1 subnets
C is directly connected, FastEthernet0/0 is subnetted, 2 subnets
S [1/0] via
C is directly connected, FastEthernet0/1

S* is directly connected, FastEthernet0/0

R2(config)#ip route

%Invalid next hop address (it's this router)

Crucially of course it breaks the routing, this static route kills the path, I really wanted IOS to be clever and ignore the command.  This was the whole point of the post however its not all that great a point I suppose, just a curio.  

So anyway, what to do?  I wanted to resolve this with static routes, but this "faulty" static needs to be removed when R1 outside interface is down, some fairly basic stuff could solve this.  So an IP SLA job first with a static route on R2 for the R1 WAN address:

ip route

ip sla 1
 icmp-echo source-interface FastEthernet0/1
ip sla schedule 1 life forever start-time now
track 1 ip sla 1

Now a new static route for the VPN subnet tracking this SLA job:

ip route track 1

And this of course worked fine, the static route was added and removed as required.  Now I need to think of better ways to do this, or is this the ultimate?  (Hahaha)

Tuesday, 11 March 2014

SIP-UA Registration Alarm EEM Script Thing

Today I had yet another instance of EEM script saving the day - or at least proposing a solution which might one day save the day.  I desperately want to monitor a sip-ua registration on a Cisco gateway, something was up with one of my gateways and it would spontaneously stop registering.  And not start again, which is deeply not funny when you are on call GMT-time and they are in Australia.  The only solution was to remove reapply the sip-ua config, which turned out to be an IOS bug, I believe.

However going forward and moving on to the brighter, less-buggy future how could we monitor the trunk going down if this happened again?  As it stood we relied on irate punters to sound the alarm - as we all know being forewarned of an impending angry caller is far more preferable to ignorance as you can magic up brilliant sounding diagnostic measures in advance (reboot it).  Was there a MIB to show this status however so we could beat them to it?  I couldn't find one.  Enter EEM.

Step1.  Use event manager to run the “show sip-ua register status” command and run over each line looking for a regex match.  The output would be:

XX-XX-2911#show sip-ua register status
Line                             peer       expires(sec) reg survival P-Associ-URI
================================ ========== ============ === ======== ============
1XX437                           -1         2194         yes normal

So our script could look like this (if like me you have hashed it together from far more intelligent posts than this):

event manager applet trunk
event none
action 100 cli command "en"
action 200 cli command "show sip-ua register status"
action 250 foreach line "$_cli_result" "\n"
action 300  regexp "1XX437(.*) no " $line
action 400  if $_regexp_result eq "1"
action 600   syslog msg "The trunk is down"
action 700  end
action 800 end

Note the white spaces in action 300, unless you want to match the "no" of  "normal" you are going to need them".  I would change the event to a cron timer running every so often, 5 minutes or so should do it.  To test the reverse, say the trunk is up, change action 300 to “yes” and see the result,:

Mar 12 06:27:20.812 WST: %HA_EM-6-LOG: trunk: The trunk is down ßreally means up

Finally add in an action 601 to send the monitoring solution of your choice a custom trap, if the result is positive, and yes we have an alarm should SIP trunk not be registered.  Happy days.

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
*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 to  Over on R2 an ip sla is probing R1, when it goes down it configures its interface to, 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:

username admin privilege 15 secret ...
username drdoom privilege 15 secret ...

track 1 ip sla 1 reachability

interface FastEthernet0/0
 ip address
 duplex auto
 speed auto

ip sla 1
 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"
 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
 duplex auto
 speed auto

ip sla 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"
 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 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

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 []?

Source filename []? asdm-647.bin

Destination filename [asdm-647.bin]?

Accessing tftp://!!!!...

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 management0

ciscoasa(config)# username nicholas password cisco priv 15

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

Google+ Followers