Networking

Gatwick is in Sussex (UK) and is internationally notable for it’s airport. At one time (and probably still now – I just can’t be bothered to check because I have a blog post to write), it was the busiest single-runway international airport in the world.

Around airports, you traditionally get lots of freight businesses, shabby hotels, and the occasional industrial or technology park. In the late 1990s the environs of Gatwick Airport held hosted a curious tenant – the Motorola University – where for one week I found myself learing all sorts of interesting things about TCP/IP, WAN operations, RIP… yeah, it was a blast.

One of the things the class did was to build a worldwide WAN (in a lab, obvs, not in real locations) because Motorola made some rather fun WAN/LAN routers at the time and they presumably wanted to drum up some business by training people how to use the kit their company had just bought without asking them. Hey, it *was* the 90s !

Again with the 90s thing, people (ie TelCos) were moving from boring, old, leased lines that smelled faintly of used engine oil to flaky, variable-latency and yet squeaky-clean and fresh Frame Relay networks, presumably for their own ends. The class was to be taught in 2 sections: the first part of the week was using the trendy Frame Relay stuff, and the latter part using the old, fuddy duddy X25 networking that no-one was using any more bleh eww nasty X25.

This is going to be a longer post that I originally thought. Bear with me, though. I hope the payoff’s worth it…

In the days of BNC ethernet, you just wired up and went. Actually, that was *much* trickier than it sounds, but you get the idea – it’s relatively simple. On the course, the class were assigned a router each (I think I had Singapore) to configure with a name and an IP address that we had designed the topography of – all class C addresses for us ! (the nerds among us will understand), we plugged in the wire and… nothing.

After Turning It Off And On Again, it was noticed that no protocol has been attached to the interface ! Oopsie ! How we chuckled at our own ineptitude as we dutifully assigned Frame Relay to the inbound and outbound interfaces and sat smugly back. Our routers could now chat TCP/IP all day !

Actually, no they couldn’t. See, Frame Relay was/is an a**hole. Yes, you can send packets out of an interface, but to have a catcher at the other end needs an add-on (or Annex, in Frame Relay). So to get the routers catching packets that another router spit out, you need to apply Annex A.

Please note: I forget the acutal Annex notations. You can look these up if you want, but they all exist and are required, so I’m just going to go alphabet on this one for now).

So, your routers are now sending and receiving packets over Frame Relay (henceforth referered to as ‘WTF’), but do you have a functioning network ? Can you ping a known IP address on your network ?

No.

WTF ?

That’s a real WTF, not the acronym above, btw.

In life, four things are guaranteed : Life, Death, Taxes, and Lost Data. Guess which has occurred ? That’s right, networks are flaky AF sometimes, so things go missing. We should really apply Annex B to WTF which adds a Frame Check Sequence checksum to each packet. This means that incoming packets can be inspected to see if they’re in the same stream, and rejected if a packet comes in out of sequence.

Hang on, that’s not what we meant – if one packet takes the long way round the network we don’t want to bin the entire stream, so we need to install Annex C to WTF that caches entries until the next one in the sequence is recieved and then sent to the application in order. Phew.

Quick question: Do you think we have a functioning network yet ?

If you answered ‘Yes’, then I remind you – WTF. Sorry – “Frame Relay”.

The reason the answer is ‘No’ is, what happens when a packet really *does* go MIA ? It happens a lot more than you might be told by your network admins. With WTF Annex Whatever-we-applied-last-to-get-the-damn-thing-working, there’s no way to request a missing packet from the router that originally sent it, so we need to apply the retransmission Annex to WTF to be able to request missing packets from the originating router so we still have a fighting chance of getting this cat gif to where it needs to be.

At this point, things get a little hazy. It was late Friday lunchtime, and people were starting to think about the long drive home. I can’t remember if there’s a further Annex to WTF to enable a buffer on the sender to create a pool from which retransmissions can be requested, and I’m fairly sure there’s an Annex before Annex A to enable acknowledgments, but we’ve come so far and I think I’ve made my point.

And it’s this:

Before you do *anything*, be that on-prem or off-prem, take a *VERY LONG TIME* to understand what you need from your network, what the access paths and controls will be, and make sure you’ve covered everything on paper before you even go near any actual configuration. That includes before buying servers, designing applications, spinning up IaaS, whatever. You can acquire all the compute you want, but if you can’t connect it to anything, it’s just a line on your OpEx.

If you get your network wrong, at best it’s a pain to put right and at worst it’s company-killing security breach. If you have to jump though hoops, know what those hoops are, document them, adhere to them, and *never* play fast-and-loose with a firewall.

If you need an indication of the criticality of getting networking done right up front, try provisioning a VM in Azure. Networking is part of the bunch of questions, sure, but before you can do anything, you need a vNIC, and everything else hangs off that.

Thanks for reading. Back soon…..

Oh, and in case you were wondering, assign the X25 protocol to the ports, and it just works (Not Annex G that provides the abiltity to do X25 over WTF – that’s nuts). Just because it’s old, doesn’t mean it’s rubbish..