More Zonkyness

Blog

  • Adventures in Cisco IOS Land: Forwarding DHCP Requests

    Please read the disclaimer before continuing …

    Once the basics of my router were up and running, I wanted to ensure that my wireless network could be served by a DHCP server. This is complicated by the fact that :-

    1. My wireless network is a separate network.
    2. I use a Unix-based DHCP server (partially because I’m very familiar with it).

    The first thing to do is to configure a “helper address” on the wireless interface – in this case the vlan that incorporates the wireless network :-

    interface Vlan102
    

        ...
    

        ip helper-address 10.0.0.21
    

        ...

    You can configure more than one helper address in here, which may be useful for debugging purposes – or in a production environment you may wish to run a failover dhcp server.

    In theory, this should send all broadcast DHCP packets onto the specified network address. However it also forwards other UDP broadcast traffic onto that host which may not be what we want. Specifically for a DHCP server we don’t want DNS, TFTP, etc. These other protocols can be excluded with (at the global level) :-

    no ip forward-protocol udp tftp
no ip forward-protocol udp domain
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
no ip forward-protocol udp tacacs

    Using the ‘symbolic’ names for the protocols aids the readability of the configuration file.

    At which point the instinct is to fire up the dhcp server and see if it works. Very natural of course, but I would suggest that sniffing the traffic to check that the relevant packets are being forwarded is wise at this point. Or you are risking testing two things at once – the packet forwarding and the dhcp server. Despite being very experienced with DHCP servers, it turned out that my main problem in setting this all up was a faulty DHCP server!

    After fixing that problem, my newly configured wireless network worked fine.

    Some additional configuration that may be worth trying :-

    • ip dhcp relay prefer known-good-server – The explanation for this on the command line is somewhat mysterious, but the documentation indicates that with this turned on, the DHCP clients will need to renew their leases less frequently. How this works, I don’t know.
    • ip dhcp relay information option – This inserts information about the relay agent (the router) into “option 82”. This additional information can be logged which can be useful.

  • Adventures in Cisco IOS Land: Disclaimer

    Firstly I will point out that this series of blog entries has nothing to do with Apple’s OSX operating system build for the iPhone retrospectively named iOS; these are about a far older operating system from Cisco that runs on most of their routers and switches – IOS. They are intended as ‘aide memoires’ for myself – a crusty old Unix geek who wanted to find out about this IOS stuff when he finally got sick and tired of consumer grade routers.

    The router I’m using for all of this is a Cisco 881W running IOS version 15. This is a ridiculously overpowered router for a domestic broadband connection, but it does have lots of interesting stuff to play with.

    Now to the disclaimer part – I’m no CCIE; I’m a Unix geek and whilst I have considerable experience with networking, it has all been with networking services such as DNS and DHCP. So anything you find here could well be done better in a different way. Or perhaps I’ve encountered a feature that shouldn’t be used just yet, or perhaps I’ve found something in my ignorance that could actually be useful!

  • Streaming Media Stutters

    Becoming increasingly popular are various forms of streaming media services – Last.FM has personalised radio stations I can tune into on my phone, the BBC has their iPlayer which allows me to catch up on BBC TV (or radio) programmes I’ve missed, and my film rental service even has a streaming service that allows me to watch films without being worried about discs being mailed to me. All very cool of course, and it’s even quite handy but there are a few problems that need to be solved before streaming services can beat having the real disc – compact disc for music and blueray for films.

    We sometimes look at these services under the best of conditions and rarely consider how they would work under the worst of conditions.

    Firstly there is the quality issue. Whilst streaming music may well approach the quality of CDs, films and other forms of video are a long way from being of the same quality of the discs – sometimes not even getting close to the quality of DVDs when Bluerays are the quality to aim for. Sure it is no big deal – the convenience of online streaming makes up for the quality to a certain extent, but it does not replace the need for quality.

    Secondly, reliability is an issue. Not only does streaming media (even audio) have a tendency to stutter to the point where listening or watching becomes unbearable, but sometimes streaming services just crash through being overloaded – very frustrating when it is half-way through a film. In theory most of our network connections have more than enough bandwidth to support streaming media – at least audio. In fact my own network connection is good enough for streaming video with just the occasional stutter – maybe just once an hour – and of course the occasional stutter may well because of other activity on my network. I do after all have people visiting my “server under the stairs” for blog postings and photographs on a regular basis.

    However my wireless network is sufficiently bad that even streaming audio can get very bad in the evening. Not the fault of the streaming media companies that I live in a very dense environment with lots of wireless “noise”, but it still means that I tend to avoid using wireless networking except on devices where there is no choice. And on those devices I have sometimes been forced to put them away, or switch to using 3G.

    It would be helpful if media streaming companies allowed people to buffer larger amounts of the media stream to assist in this. I would not mind waiting 10 minutes for a buffer to fill up to ensure that I could watch a film all the way through without stuttering. Or indeed wait 60s for an audio stream to buffer.

    On the subject of media servers crashing, it is a little hard to see what can be done about this. The obvious thing is that streaming media companies need to be very careful about the code they write (or buy) to increase reliability. Software always has bugs, but increasing the importance of bug destruction would be very wise. Less obvious is to measure how reliable the media servers are at various loads, and limit the load to the level they can support reliably.

    A message saying “please wait for an available film slot” is better by far than trying to start playing a film only to have it drop out half-way through!

  • Ghosts In The Mist

    These two are from a short walk near Rowland’s Castle on a very foggy day – perhaps a little too foggy for my purposes. Very wet too.

    Ghosts In The Mist

    Ghosts In The Mist

    Misty Trees

    Misty Trees

  • Yule Photographs

    These were taken over Christmas Day and Boxing Day near Winchester (Otterbourne) with just a handful of shots – the batteries for my ancient Canon 1DS are somewhat reluctant in the cold – and it was very cold on the second morning!

    Grazing In The Misty Morning

    Grazing In The Misty Morning

    Misty Morning

    Misty Morning

    Mist On The Downs

    Mist On The Downs