There was lightning last night to the south east of us, in the Linne Shléiteach, which is the bit of the Atlantic separating Skye from the mainland, and the strikes shown on the BlitzortungLive map were down near the southern tip of The Island, two there and another one further south east just off the coast of the mainland.
I heard the rumble of thunder and Mrs Weaver turned off all the modems and unplugged them from the wall. This was the first time the Firewall 3G dongle failover system had been used with a real DSL outage. Before I had cheated by tweaking the Firebrick config so that it couldn’t find any of the modems. Anyway it worked superbly, AA at their end and the Firebrick here both switched over to directing all of the traffic through the 3G dongle.
It used all the exact same IP addresses, so TCP connections could simply carry on without a clue that anything had happened. Changing IP addresses would have meant having to bin TCP connections as TCP cannot handle such a change (although more advanced protocols such as SCTP can iirc) and also the remote end wouldn’t know who the new IP address was that suddenly started talking to it because it uses the old address to identify the particular client.
One really bad thing is the fact that the 3G/4G network doesn’t speak IPv6, but luckily AA and the Firebrick both compensate by going over to tunnelling IPv6 traffic in IPv4. IPv6 was tested using the two test websites test-ipv6.com and ipv6-test.com and got 100% top marks score from each.
The other really bad thing is the low MTU of the network + dongle combination, which is only 1440 bytes (for an IP PDU). Why, I have no idea. I had complained to AA about this, seeing as they had told porkies about full 1500 byte MTU in their advertising and they seemed surprised and unaware, and had to simply confess that they had got it wrong somehow. At the time of failover, there will be a change of MTU in the middle of a session and if TCP connections or other protocol conversations are open then this might cause all kinds of disruption. Shudders. The way I have it set up, the effect on IPv6 will be different from the effect on IPv4. I really need to test both with downloads or uploads in progress at the time of a switchover.
It will need several pairs of hands, some accompanying dexterity and a load of coordinated actions, but with the setting up IPv4 and IPv6 transfers in both directions using various protocols and talking to various remote servers this could test his well protocols and software copes with the change of MTU mid-stream, if any. I would need to do traffic captures which I can do, because AA has a facility to do so and so do my WAPs. I struggle to make sense of these, the amount of information is overwhelming. Firstly, I could do with some decent software to break headers down really clearly with full explanations. Secondly I need help linking the packets that belong to each flow. And thirdly something that can help me spot salient features of the sequence of events in protcols such as TCP, including retransmission, out-of-order packet arrival and repeated duplicates, and especially important here, ICMP packets plus the reaction to them.
Anyway, despite the lack of detailed tests and challenging situations, the whole thing was a resounding success with every device just keeping on going.