Some New Nagios Plugins

Over the past ten years I have left many many new and hacked Nagios plugins on many servers around the globe. I’m now making a concerted effort to find them, clean them, maintain them centrally and release them.

To that end, I have created a repository on GitHub for the task with a detailed readme file:

As a starting point, there are four plugins available now:

  • check_chassis_cisco.pl – a script to poll a Cisco switch or router and check if the device was recently rebooted; its temperature sensors; its fans; its PSU; its CPU utilisation; and its memory usage.

 

  • check_chassis_server.pl – a script to poll a Linux / BSD server and check its load average; memory and swap usage; and if it has been recently rebooted.

 

  • check_portsecurity.pl – a script to check all ports on a Cisco switch and issues a critical alert if port security has been triggered resulting in a shutdown port on the device.

 

  • check_portstatus.pl – a script which will issue warnings if the port status on any Ethernet (by default) port on a Cisco switch has changed within the last hour (by default). I.e. a port up or a port down event.

So I’ve Made the Switch from SVN to Git…

…and I’m bloody delighted. 

The straw finally came when Nick forced my hand for a project we wanted to release through our work in INEX. I was pushing for Google Code but he had his heart set on GitHub. Now, in fairness, GitHub has some SVN bindings but after some research, I decided to dive right in.

Now, there’s both a steep learning curve but also a complete change of mindset required from centralised source code management (SCM) with SVN to the distributed model of Git. In the end, most projects will decide on a canonical Git repository anyway which pushes you slightly back towards centralised but there’s still a world of a difference.

So, what’s so good about Git? Well, lots. But first and foremost is it’s exceptionally powerful yet simple branching and merging that just works. And works fast – remember, with Git everything is local.

One work flow that used to kill me in SVN was that you’d be implementing feature X but someone needed bug Y fixed immediately involving some of the same code. Getting just the fix for Y in was tough and complicated. And branching in SVN isn’t quick or simple. In Git, I branch from the main development branch for every new feature, bug fix, etc and then merge what I need between them and back into develop when they’re ready to be pushed back to the agreed canonical repository.

I’ve been so impressed with Git that I’ve moved an open source project we created in Open Solutions over to Github: ViMbAdmin. I’ve also forced the rest of my team in Open Solutions over to Git and migrated a number of customer projects already. And we’re reaping productivity rewards!

How we work Git for projects was taken from this excellent post which I would fully recommend: A successful Git branching model.

Useful Git Links:

Three Rock Masts

Living below Three Rock mountain in Stepaside, I often look up the many communication masts. Today I trekked up on the bike and took a few (dark and bad) photos.

Duke Nukem Never Comes Early

I’m not a gamer and I never played Duke Nukem. But I was always taken by this article: “Learn to Let Go: How Success Killed Duke Nukem” which is required reading for anyone developing software products.

On May 6, 2009, everything ended. Drained of funds after so many years of work, the game’s developer,3D Realms, told its employees to collect their stuff and put it in boxes. The next week, the company was sued for millions by its publisher for failing to finish the sequel.

It looks like someone else is going to release Duke Nukem now but they’ve delayed the release date in hilarious fashion (hilarious assuming you’ve read the above article):

Curtains for SGU and the Stargate franchise

Curtains for SGU and the Stargate franchise: it was indeed a terrific ride which never failed to excite the sci-fi loving geeky kid hidden inside of me.

It’s a sad way to start a Monday when I browse the handful of feeds on my RSS aggregator  and read from an entry entitled until we meet again on Joseph Mallozzi’s  Weblog (Stargate Executive Producer and writer) that the end has arrived:

That was the title of the email I received from Brad Wright late yesterday, an email confirming the worst.  Despite his best efforts and a situation so fluid it vacillated from “almost yes” to “probably not” and back to “almost yes” on any given week, final word had come down.  There would be no SGU movie. Stargate, that had spanned fourteen years, 354 episodes, two DVD movies – that had helped build a network and establish itself as a studio’s most successful television franchise was coming to an end.  It was a terrific ride and, while it would have been great to give the fans that final chapter, that last crossover movie in which Brad had envisioned incorporating elements from all three shows (SG-1, SGA, and SGU), the truth is television is a fickle business.  When it comes down to decision time, it’s less”What have you accomplished?” and more “What have you done for me lately?”.

It was indeed a terrific ride which never failed to excite the sci-fi loving geeky kid hidden inside of me.

Benchmarking the Mikrotik Routerboards RB750 and RB750G

Continuing on from today’s earlier post, Benchmarking the Mikrotik Routerboard RB1100, I now present some results for the RB750 and RB750G using the same methodology and platform.

The RB750 and the RB750G are two identical looking routers intended for the SOHO environment:

The specifications for the RB750 (with differences for the RB750G in italics and parenthesis) are:

  • five FastEthernet 100Mbps (Gigabit 1Gbps) ports;
  • 32MB DDR SDRAM ;
  • 64MB on board NAND storage;
  • Atheros AR7240 400MHz (AR7161 680MHz) CPU;
  • powered by PoE or power jack;
  • up to 3W (6W) power consumption;
  • ports 2-5 share dedicated switch chip allowing full 100Mbps (1Gbps) throughput;
  • all ports can be individually configured.
  • €31.73 (€54.61) from Wireless Connect.

Both routers come with an L4 license of Mikritik’s RouterOS which is built on the Linux kernel so anyone familiar with Linux networking will get up to speed on these boxes in no time.

As a disclaimer in case it is not clear, all routing tests are done using just two ports – one for the traffic generator and one for the receiver – with the device under testing routing the packets between two networks. As such, on the RB750, the maximum throughput we could achieve would be 100Mbps.

I ran tests for plain routing and also, in evaluating it for certain uses, over a VPN tunnel.

All results are presented below. Given the wealth of features, I think these are super boxes at a super price. So far I’ve put them on the end of an Imagine DSL line providing IPv4 and v6 over PPPoE and the end of a 30Mb UPC line taking its UPC IP via DHCP. They provide firewall, NAT, port forwarding, OpenVPN tunnels, QoS, DHCP, DNS caching and VLANs for phone / VoIP and managment networks.

 

 

 

Benchmarking the Mikrotik Routerboard RB1100

I attended and gave a talk at the recent Irish Wireless Conf & Expo on behalf of INEX. I don’t get to do much with wireless links and as such I found many of the talks and exhibitors very interesting. One company that had a large presence through both Wireless Connect in Dublin and Irish Wireless in Shannon was Mikrotik – a company manufacturing routers built on Linux and some kit that I had been meaning to look at for some time.

Following the conference I picked up some RB750’s and RB750G’s and was very impressed. So much so, that I picked up a RB1100 also. The RB1100 specifications include:

  • 13 individual 1Gbps ports;
  • 2 x 5 port switch groups;
  • 800MHz Power PC MPC8544E processor;
  • SODIMM RAM slot with up to 1.5GB RAM;
  • 1 x microSD card slot;
  • 1U rack mount case.

I decided to benchmark this to see at just what rate it could route packets.

Benchmark Methodology and Tests

I used two PCs running Linux with iperf to measure TCP throughout with different packet sizes. To establish a baseline, I ran the same tests with the two PCs directly connected (this is the Direct Connection results below). The maximum achievable result with this is 1Gbps.

An example command line for the test which runs for 10 secs by default and for a packet size of 64 bytes is:

iperf -f m -i 1 -c 10.0.0.1 -l 64

Then I ran four test sets routing traffic between two networks as follows:

  1. No c/t, no f/w: connection tracking disabled and firewall set to allow all;
  2. No c/t, f/w: connection tracking disabled but with some simple firewall rules;
  3. C/t, no f/w: connection tracking enabled but firewall set to allow all;
  4. C/t, f/w: connection tracking enabled and stateful firewall rules.

In addition, I ran the above four tests with the RB1100 configured as a OpenVPN server:

/interface ovpn-server serverset auth=sha1,md5 certificate=cert1 \
cipher=blowfish128,aes128,aes192,aes256                          \
default-profile=your_profile enabled=yes                         \
keepalive-timeout=disabled mac-address=FE:50:A7:D5:FE:B7         \
max-mtu=1500 mode=ip netmask=24 port=1194                        \
require-client-certificate=no

One of the PCs was connected to the RB1100 as a VPN client pushing traffic to the other server on a non-VPN connect with all traffic routed through the RB1100. I also did a baseline test by running the VPN server with the same encryption on one of the PCs with a direct connect to the other and then pushing traffic over the VPN link.

Results:

The results can be seen in the following graph:

Without connection tracking and firewall, full line rate is achievable for packet sizes of 256bytes and higher – all in all, an excellent result. That said, no connection tracking and no firewall would be an unusual configuration and with these, the box maxes out at around 525Mbps – still an excellent result for less than €400.

The VPN tests yielded:

VPN throughput primarily relies on CPU horse power and the PCs used for the Direct Connection baseline test are pretty modern.

World IPv6 Day – Do Something – Anything!

June 8th, 2011 is World IPv6 Day and on that day, Google, Facebook, Yahoo!, Akamai and Limelight Networkswill be amongst some of the major organisations that will offer their content over IPv6 for a 24-hour “test flight”.

I’m trying to push June 8th as a ‘flag day’ for smaller companies to get something – anything – done with IPv6. Enabling AAAA on their websites (and leaving it on) would be super. Some other suggestions I have:

  1. Register on IPv6Ready.ie and add the badge to your site. Even if it’s Pending IPv6, the whole point of the project is to nudge the level of awareness up a notch and we need badges on sites for that.
  2. If you haven’t even used IPv6 before, get a SixXS tunnel and be sure to choose either HEAnet, Airwire or Digiweb as your tunnel broker. All are members of INEX with good IPv6 connectivity so you’ll see low latency with good connectivity on these.
  3. If you want to get IPv6 on your LAN and your ISP won’t provide it, then (a) bug them some more; and (b) as a intermediate measure, also get a subnet from SixXS for your LAN.
  4. Dual stack your mail server and add a AAAA record to your MX hosts. This is a really simple and painless first step as SMTP is such a resilient protocol, if the mail cannot be delivered over v6, it’ll fall back to v4. Postfix, Sendmail and others have been IPv6 capable for years.
  5. Dual stack your DNS server. Like Postfix / Sendmail, Bind has been IPv6 capable for years. Get it listening on v6 and then add AAAA records to at least one of them.
  6. Hurricane Electric have a very useful IPv6 Certification program (see it at http://ipv6.he.net/certification/) which certifies an individuals ability. It’s a free process and what’s great about it is that, even if not interested in the cert, working through the process gets you configuring IPv6 on your web server, email server and DNS.
  7. Always look for IPv6 when choosing an ISP, a hosting provider, equipment vendors, and SaaS. Even if not a deciding factor, ask for IPv6 support to keep nudging it up the list of priorities for service providers.
  8. Register and display a badge from www.ipv6ready.ie. Did I say that already?

 

We’re IPv6 Ready! Are you?

IPv6 ReadyOver in INEX, we just launched a new initiative to promote and increase awareness of IPv6 among content owners and businesses generating revenue from an online presence.

This project is called IPv6 Ready and it is essential a certification program for websites that are IPv6 ready to one of two standards:

Gold: The website has a AAAA (IPv6) DNS record; and

Platinum: At least one of the websites DNS name servers is additionally IPv6 enabled.

IPv6 PendingFor those websites that are not IPv6 enabled (and in many cases this is dependent on a third party hosting company), we also have a very cool IPv6 Pending badge which you can use to let your customers know that you are IPv6 aware.

The badges shown here are the large versions but we also have an extra large, medium and small so you’ll find an appropriate one for your site.

How do you get your badges? Easy, just head over to IPv6Ready.ie and register your site. Once you complete the simple process, you’ll be emailed all four personalised badges!

Help us make this a success! Please repost, blog, tweet and spread the word any way you can to help us raise awareness and push IPv6 forward – even just a little. If nothing else, please register and display a badge! You’ll also get a link such as this to your own certificate!