Coredump

Our telephone cables got stolen Thursday night. Thieves cut off a long portion (about 50 meters) of phone lines just a couple of kilometers from the campus.

So now, we’re without voice, fax and data communications to the outside world. Networking = NOTworking.

I transferred Angelica to the DA NIN VSAT connection. Hopefully, users can connect to the Net through that. But my subsequent testing results show that the connection is way too clunky. Most connections are dropped or outright refused. I would have to tweak Squid settings yet again. I can’t change the settings on the VSAT proxy, but I would love to — that might kick it up a bit.

The loss came right after we were about to clean up one solution to our last-mile connection problem. We just received a new IP block from Preginet, and with that, we can probably implement alternative DNS entries for Preginet and AFRDIS. They say the theft is not new, that this had happened in the past.

We would probably be voiceless, faxless and dataless over Christmas and through New Year’s Day. Bummer.

One of our links has been down for two weeks now. It seems the modem at the telco outplant couldn’t handle the stress.

Too bad, because that link had just been upgraded. It would’ve been real nice to test its performance, then we can go rollout one of the link failover solutions we were brewing.

We were planning three separate approaches to the last-mile problem, i.e. how to switch over to a secondary link once the primary goes down. In our case, our primary and secondary links, ideally, should handle the same loads. In reality, though, we have stretched the primary and underutilized the secondary.

The solutions:

1. BGP routing. It’s not really feasible in our case since we have piecemeal IP blocks, not the /19 behemoths. Even if we can somehow try private AS numbers, it would be a hassle to blow holes at the provider side for our IPs.
2. Concurrent DNS entries. We can have a primary nameserver using the primary link, and a secondary on the other. Problem would be to set the TTL values low enough for clients to refresh in a significantly minimum amount of time once one nameserver fails.
3. Using LVS for the various services. This one, so far, is the most attractive solution, and would entail the minimum fuss. We can set the virtual server to have two parallel IPs, set name records for those IPs with appropriate TTLs, and have LinuxDirector either NAT or tunnel services to the real servers, which are then connected to concurrent storage devices for high availabilty. The virtual server, of course, would have a backup.

But for now, we content ourselves to manually switching the IPs for all the servers and cross our fingers that the propagation would follow through over the weekend. What a lousy hack.

I have immersed myself today in docs about BGP, which is what we need to implement multihoming on our network.

A few notes:

1. We need an AS number. We’ll probably have to get this from Preginet.
2. We need a routable IP address block, or two same-sized address block from AFRDIS and Preginet.
3. I need a router simulator to test my network design, and not frag things up.
4. I need a book on BGP. The docs available on the net are just too overwhelming, and I wouldn’t know where to start.
5. I’d probably have to consult with Preginet, and beyond that, with PLDT Datanet people.

Took us the whole day figuring how to setup the dial-in lines using TACACS+ and AAA on a Cisco 2500 series router and Maui.

It was doubly hard because although there was an existing config on the router, I only had very basic IOS knowledge. Thank goodness for Google, but even then I had to RTFM every once in a while to check up on what we’re doing.

Setting up Maui for TACACS+ was a breeze, though, since there was an existing tacacs database in MySQL. It was only a matter of building version 9, and tweaking the settings to match that of the AAA router.

Actually connecting through the dial-up modem was another matter altogether, though. We still can’t figure out why it would connect one moment, not connect at all the next, and when it does connect, it’s extremely slllooooowwww (around 9 - 11 kbps).

Probably a noisy line? Or a misconfig on the router? Perhaps. We’ll see.