Tales of a Fourth Grade Nothing

I've been hit by network problems for most of this week: my router dropped its DSL connection earlier in the week and has been stuck in a down/up loop ever since. I've finally fixed the problem by reseating all the cables — actually I moved the box to the main phone point and then moved it back once I'd confirmed everything was OK and the reseat was completely incidental — I really hope this isn't a first indication that my ancient router isn't about to die for good...

Something of a busman's holiday, trying to sort out a way to extend wifi coverage to the ground floor using a Netgear WGR614 and an ethernet-over-power-line access point. After much fussing over the subnetting, caused a duff steer from the howto pater grabbed from the internet, we eventually fixed the problem by setting the modem side of the router to dynamic and using the wifi to forward DHCP requests to the primary router. Even so, I still wasn't convinced that the routers were dishing out the right default routes but by that point I'd reverted back to holiday mode, leaving pater to mop up the last few details.

Most of the rest of the afternoon was lost to my parents less than successful attempts to get my nephew to do his half-term English homework — to write a report of a non-fiction book about something he was interested in. Slightly better was my attempt to solve a primative substitution cypher using a combination of crossword skills and frequency analysis. Fortunately, before long, the boy realised that the first few words referred to the Babington Plot and the whole thing tumbled into place. But having foolishly demostrated my computer savvy while solving the puzzle, I then spent the rest of the day fending off requests to set up a minecraft server and trying to explain why the idea was basically a non-starter.

A little while ago, we discovered an interesting GPFS glitch that caused panicky unmounts on some of the systems. When we investigated in detail, we traced the problem to revoke messages from a specific NSD server in the storage cluster and when we examined the network connectivity, we realised that the topology was such that it forbade direct connections to the problem server from the compute environment. Consequently, during token operations involving more than one compute cluster — operations that required arbitration from the NSD server in order to resolve the lack of direct connectivity between the compute clusters — the NSD could not be contacted, triggering a revoke of one of the requesting.

Following this discovery, we've been working on interesting ways to try to work around the communications problem. The US suggested configuring the NSD with an IP alias in a different subnet and using one of the nodes with universal connectivity to act as a router But during a chance conversation with the colleague who was working on implementing the solution, I pointed out that we might be able to solve the problem by altering the subnet mask on the NSD server to partition the topology into directly connected systems and systems that needed to be accessed via that gateway but we would still need come up with a way to route the traffic back from the indirectly connected systems without changing their netmasks, a problem I thought was intractable. So imagine my surprise when my colleague suggested this as a solution!

According to my understanding of IP routing, the determination of whether a system is local or not is made by comparing the network components of an address with the network components of the machine's own interfaces. If the components match, the address is on the local network and the routing table is not examined. If the address is remote, attempts are made to match the target address to entries in the routing table starting with host routes and widening out until the default route is reached as a destination of last resource.

However it turns out that AIX, post 5.1 at least, does not behave like this. Rather it seems to examine the routing table regardless of the network component of the target address, allowing host specific routes to be matched ahead of the local interfaces. Thus my colleague was able to increase the size of the mask on the NSD, add host specific routes on the other side and have the traffic route through the gateway, contrary (to my, at least) theoretic expectations, giving us a nice clean solution to our underlying problem.

... and I was using kermit over a 14kbit modem. The experience was bad, but I didn't know any better. Fast forward to 2005 and I've been using ssh over TCP on a 56kbit modem. The experience was the pits - worse than the 14kbit modem - with endless line drop outs, 10 seconds of transmission lag and random two minute freezes.

I blame XP for running loads of stuff behind the scenes, doing lame stuff like updating my anti-virus software and stuff like that. I'm sure that sort of thing is find if you're just browsing the web, but if you're trying to run an interactive terminal session over the same line, it's a total nightmare.