Adventures in IOS Land: Netflow

 Cisco, Computing  No Responses »
Mar 122013
 

Netflow (or perhaps IPFIX if you want to be vendor agnostic) is a means by which information on network traffic flows can be stored and sent on to an analysis workstation. As such there are two parts to the process of getting it all up and running – getting flows exported from the router, and getting something to read the flows for analysis.

Configuring The Flow Export

The first thing to do is to determine what interface(s) to monitor network traffic on as each interface needs to be independently configured. In most circumstances, the WAN link is the interface of interest, so we enable things on that interface :-

# conf t
config# interface dialer 0
config_if# ip route-cache flow
config_if# end
# wr mem

The guide I followed also suggested setting the bandwidth value to enable percentage utilisation calculations. I was lazy and skipped this. It also noted that for accurate flow statistics it is necessary to enable flow collection on all participating interfaces. Once this has been enabled, it should be possible to see something of what is going on with the show ip cache flow.

It is also a good idea to export the flows somewhere :-

# conf t
config# ip flow-export destination scrofula 9996
config# ip flow-export source dialer 0
config# ip flow-export version 9
config# snmp-server ifindex persist
config# end
# wr mem

The use of version 9 is dependant on what your analyser software can support. The snmp-server command keeps interface indexes persistent across reboots.

Analysing with NTOP

The installation of this package was accomplished with :-

# apt-get install ntop

This rather depends on the server in question running Debian of course! The details of configuring Ntop are left as an exercise!

 

Raspberry PI Alternatives

 Computing, Linux  No Responses »
Feb 222013
 

The Raspberry PI is a pretty cool device, but it is not the only small cheap computer around, and given that the PI is more hardware hacking orientated I thought I’d dig up some links for some of those other devices. Especially as I’ve got two Arduino projects on the go.

There’s actually a surprising number of devices out there; some running Linux and some running Android. And in a surprising variety of form factors; I’ve avoided looking at the simple boards – the point here is to look at devices that are different :-

  1. The Trim-Slice looks quite an interesting device, but all seems to have gone quiet since March 2012.
  2. The Giada Q11 is a similar device which is about the size of a VCR … or a 3.5″ external hard disk enclosure.
  3. The Cloud Client mini PC is a touch smaller being roughly the size of a double-CD case.
  4. The CuBox is more square than the rest and is roughly the same size as a mains plug.
  5. The Cotton Candy is an ARM in a USB stick; a cheaper option but possibly via Ebay is the U2, although most cheaper options don’t have quite the same features as the Cotton Candy.

This is not to imply that there are not others out there, nor that these are “better” in any way. I’ve not used any of them.

FreeBSD: Increasing The Size Of Disks In A ZFS Pool

 Computing, Working Notes  No Responses »
Feb 112013
 

One of the obvious things to do with a ZFS storage pool is to increase the size of the disks in it – after all disks get bigger and cheaper over time. Not that it is a very difficult thing to do, but it is always worth doing a quick search to find out what others have done before setting forth. And if nobody blogs their own experience, there’s nothing for anybody to find!

So I started off with four 2Tbyte drives configured as two vdevs each of which was a mirror. And I had two 3Tbyte disks to swap in. So I was going to be swapping one of the vdevs (consisting of two 2Tbyte drives) with the 3Tbyte drives.

In the details below, I have a storage pool called zroot and the two disks being replaced are gpt/disk3 and gpt/disk2. As you will notice, I am growing the storage pool I boot off; however the disks I am using do not contain a boot partition with the boot code.

The first job was to swap out one of the 2Tbyte drives. This was done by :-

  1. Take disk to be swapped out offline: zpool offline zroot gpt/disk3
  2. Shut down the server and take the selected drive out. Swap over the disk caddy onto a new 3Tbyte drive, and swap that back in.
  3. Power on the server.
  4. Create an EFI partition table: gpart create -s gpt ada3
  5. Optionally create a swap partition: gpart add -t freebsd-swap -s 4G -l swap3 ada3
  6. Create a ZFS partion: gpart add -t freebsd-zfs -l disk3 ada3
  7. Replace the device: zpool replace zroot gpt/disk3

Now is the time to wait for the resilvering process to complete. Once that has finished, the steps above can be repeated for the other drive in the vdev. Once the resilvering for that replacement has finished, you may want to check the size of the pool.

If the size has not increased, you may need to do: zpool online -e zroot gpt/disk2 gpt/disk3.

Linux Volume Manager: Growing Filesystems

 Computing, Linux, Working Notes  No Responses »
Feb 062013
 

If you have previously used Linux’s volume manager (LVM) to set up disk storage, you may want to know about how to grow a filesystem safely.

Which is probably the big feature of any decent volume manager because accurately predicting the size of filesystems is a black art, and the only alternative – to make the root filesystem contain all of the storage is a dumb idea.

It’s actually really easy and can be done non-disruptively. It is done in two parts – effectively growing the “disk” device and then growing the filesystem itself.

Extending The Volume

First identify the volume you need to extend. You can of course simply run lvscan which will show a list of the volumes, and if you have named them sensibly will allow you to pick out the volume to extend. But the simplest way is simply to run df to look at the filesystem you want to extend :-

/dev/mapper/ssd-opt         7.9G  5.5G  2.1G  73% /opt

The device (in the first column) is what we extend. Now to decide how much to grow the volume by; just for the case of this example, we’ll assume that 2Gbytes is a sensible amount to grow the volume by. The command needed is :-

lvextend --size +2G /dev/mapper/ssd-opt

And that’s it. No need to shut down the server, dismount the filesystem, etc. Of course we haven’t quite finished yet.

Growing The Filesystem

What we have done at this point is the equivalent of making the disk bigger. We also need to tell the filesystem it is sitting on a bigger disk, and to do so we need to know the type of the filesystem. The canonical place for checking that is the file /etc/fstab (actually it’s the filesystem itself but that is going too far) :-

# grep opt /etc/fstab
/dev/mapper/ssd-opt	/opt		ext4	noatime		0 3

It is probable that you are looking at growing an ext3, ext4, or xfs filesystem. If not you will have to look up the details yourself.

Growing ext3, or ext4 Filesystems

This is done with the resize2fs command :-

resize2fs /dev/mapper/ssd-opt

Several points :-

  1. Yes it can be done “online” whilst the filesystem is mounted (and applications are busy using it).
  2. You need to specify the device containing the filesystem to grow and not the mount point.
  3. There is no need to specify the size … the size will be determined from the size of the device underneath the filesystem.

Growing xfs Filesystems

This is done with the xfs_growfs command :-

# xfs_growfs /opt

Several points :-

  1. Yes, it can be done “online”. In fact you have to do it with the filesystem mounted.
  2. You need to specify the mountpoint of the filesystem and not the device. Irritatingly different from the above!
  3. There is no need to specify the size.

How Reliable Is This?

Very.

There is always the chance that something could go wrong especially if you are operating “at the edge” (say you have a filesystem that is unusually large – several petabytes). But I’ve done online filesystem resizing for years in countless circumstances without an issue.

I’ll quite happily do it on the most important systems during working hours without losing a moment’s thought. However I do work in a place that takes backups seriously!

Adventures in Cisco IOS Land: A Route For “Unknown” Internal Networks

 Cisco, Computing, Working Notes  No Responses »
Jan 262013
 

First defining the problem. Let us say that I have a network with plenty of space for subnets (perhaps 10/8) and I am only using a very small number of the possible subnets – for this example, perhaps 10.0/16, 10.1/16, 10.2/16. What happens when I ping something like 10.52.1.3? Or perform a network scan of 10/8 ?

Well logically if a packet is destined for an unknown network, it will get routed to the default gateway (or “gateway of last resort” in Cisco’s rather gloomy terminology). Given that in most cases, the default gateway is going to be pointed in your ISP’s direction, this is probably not a sensible choice. In most circumstances it probably doesn’t matter, but there are a number of scenarios where it could be an issue :-

  • If the default gateway thinks that the route to 10/8 is back down to the router, then you’ll have packets bouncing back and forth for a while. This may not be a major issue … or it could be if someone tries to flood all your unknown networks as quick as possible.
  • Your default gateway could be a firewall of some kind which helpfully blocks such packets itself. However it may also helpfully log all these in your log files as problems which unhelpfully conceals other issues. You do inspect your log files, don’t you?

There are quite possibly other problems I cannot think of on a lazy Saturday, but it’s also the case that preventing packets destined for unknown packets leaking is the right thing to do.

So how to do it ? With a static route of course :-

conf t
> ip route 10.0.0.0 255.0.0.0 Null0 254
> ipv6 route 2001:db8:beef::/48 Null0 254

The choice of the device Null0 is a bit problematic; it should really be a “device” that returns a ICMP destination unreachable immediately. However it’s better than nothing.

The choice of the “metric” 254 (or “administrative distance”) is specifically chosen to allow any other route learnt by any mechanism to overrule this route.

Having a route to Null0 that covers all your internal subnets may seem alarming, but it seems to work – at least for my network. It is also documented that routing will choose the most specific route in preference to the least specific route – or in other words a route to 10.0/16 is used in preference to the route to 10/8.

Of course if some Cisco routing guru comes along, I’d be more than willing to be corrected. I’ve also tried to check this against Cisco’s “routing for dummies” document.

 Older Entries  Newer Entries