Today started out like yesterday ended. I was awaken by a call early this morning because a server I manage was down. I call over to the datacenter to have it rebooted, only to have it still down half an hour later.
Get into the data center to find:
Keyboard error. Press <F1> to continue across the screen.
After that, I had to give the new server the old IP address, only it kept refusing to accept the new IP address, saying that some other machine was using it. That's odd, I thought. I could have sworn the old machine was unplugged from the network. And lo, when I checked, it was.
Turns out Smirk had moved the site that was on the old server to one of our servers temporarily, but neglected to inform me of that little detail.
Then a rash of calls and support tickets screaming about email. Over and over again I had to inform our customers that because of the denial of service attack, email got backed up and our email server was having to process a huge backlog of emails just please be patient.
Things calmed down after that.
And I'm not saying anything past that—I don't fancy jinxing myself.
I also did manage to find a work-around for the little OSPF problem I've been having. What's happening is that on the customer's router, when the T-1 link is up, the routes, including the all important default route, are populated through OSPF. If the T-1 goes down, then all the OSPF generated routes disappear, including the all important default route.
Upshot—if the T-1 goes down, the customer can't see the Internet.
But oddly enough, when the T-1 goes down, OSPF still shows a neighbor connection through the DSL link. But it won't populate the routes.
The work-around? A static default route through the DSL connection but weighted so heavily that the default route through OSPF (in which case goes through the T-1) is preferred if it exists.
So now, the T-1 goes down, the OSPF routes disappear, leaving the static default route over the DSL so the customer can still see the Internet.
It works, but I don't like it.