“Hello, Technical Support,” I said.
“Hey, this is F from XXXXXXXX.” It's the cusomter we set up the IP tunnel with DSL backup a few months ago. “Our T-1 was just installed.”
“Okay,” I said, unsure of the implications of what F just said. What does that have to do with us? I'm thinking.
“I was wondering if the T-1 has been installed on your end yet?” asked F.
Excuse me? I thought.
“The T-1 on your end. We're getting a T-1 through you guys,” said F.
“Oh, was that my ‘out loud” voice?”
“Yes,” said F.
That was how I found out about the new T-1 installation for our customer about a week or so ago. They dropped the IP tunnel and decided on a dedicated circuit with us. And they're keeping the DSL backup connection.
Now, the DSL circuit on our end comes in one Cisco router. The dedicated T-1s on our end come into another Cisco router. In this case, the T-1 is the primary circuit and the DSL is the secondary circuit.
Well, either we go static routing and I'm on call 24/7 and can never be more than two minutes from an internet connection so I was rewroute things if the T-1 fails, or we use a dynamic routing protocol like OSPF to handle these things for us.
I'm having to learn to configure OSPF across four routers to get this accomplished.
OSPF is not entirely new to me, but we only have it running between two routers, one on our side, and one to another customer. This customer though, requires OSPF configurations across four routers.
Fortunately, it wasn't that hard to set up, but it's not complete yet.
That firewall between our core router
CORE and our DSL router
keeping OSPF from
communicating across all the routers—OSPF communicates directly with neighboring routers, and
that firewall isn't a neighboring router.
To fix that, I need to:
- Set up a virtual OSPF link between
DSL, but that apparently involves multiple OSPF areas, which is something I don't care to get into with a network this small (and frankly, we can get by entirely with static routing if it weren't for the redundant links).
- Set up OSPF on the firewall. Easier than the first option, but still requires some work.
- Remove the firewall entirely. Nearly all the customers on DSL already have a firewall locally (heck, nearly everything that hooks up to the Internet has a firewall) so removing the firewall isn't that much of an issue.
Of those, the third option is the easiest one to handle.
Once the firewall is out of the way, and the T-1 functions between us and XXXXXXXX, then OSPF will handle the changes in routing in case any of links to our customers go down.
About the Vonage phone I recieved a few days ago:
- Jeff Cuscutis <XXXXXXXXXXXXXXXXXX>
- Sean Conner <email@example.com>
- Voip phone
- Tue, 25 Apr 2006 16:17:28 -0400
Those are very useful. After the hurricanes last year, we relocated the company to a hotel in Orlando with wifi and just forwarded the office number to the vonage number. It was pretty cool.
Okay, there is that.
Normally, I tend to quote email headers in posts as:
<p> <b>From:</b> John Doe <<span class="cut">XXXXXXXXXXXXXXXXXXX</span>><br> <b>To:</b> Sean Conner <firstname.lastname@example.org><br> <b>Subject:</b> You know, your posts are boring<br> <b>Date:</b> Date: Tue, 25 Apr 2006 17:17:17 -0400 </p> <p>You know, your posts are getting awfully dull lately ... </p>
Which would be rendered as thus:
From: John Doe <XXXXXXXXXXXXXXXXXXX>
To: Sean Conner <email@example.com>
Subject: You know, your posts are boring
Date: Tue, 25 Apr 2006 17:17:17 -0400
You know, your posts are getting awfully dull lately …
But there was an entry last month that made me rethink how I wanted to construct the headers when quoting email—basically, long email headers can span multiple lines but each subsequent line of a header should be indented with white space, and with the formatting I have above, that distinction isn't preserved (as well as the headers inherit the full justification I have for all my paragraphs, which shouldn't happen either).
So I thought about it, and I decided that really, headers could be construed as a type of dictionary list—a list of terms (the header name) and their definitions (the header contents). So the above would be encoded in HTML as:
<dl> <dt>From</dt> <dd>John Doe <<span class="cut">XXXXXXXXXXXXXXXXXXX</span>></dd> <dt>To</dt> <dd>Sean Conner <firstname.lastname@example.org></dd> <dt>Subject</dt> <dd>You know, your posts are boring</dd> <dt>Date</dt> <dd>Tue, 25 Apr 2006 17:17:17 -0400</dd> </dl>
Which I would like to render as:
- John Doe <XXXXXXXXXXXXXXXXXXX>
- Sean Conner <email@example.com>
- You know, your posts are boring
- Tue, 25 Apr 2006 17:17:17 -0400
Only if you aren't viewing this on my site with a CSS-capable browser, you won't see the intent I have for formatting, which gets us back to the post I made last month.
Am I the only one that has this concern over how my entries are presented?
Anyway, if the quoted email in the previous entry looks a bit odd, that's why—you aren't seeing it how I intended it to be seen.
While the T-1 may have been installed at XXXXXXXX, the router there (that we supplied) doesn't have a T-1 interface. So after work I drove over there to install one.
I had been in the process of setting up OSPF and installing some firewall rules (they are one of the few DSL customer that didn't have a firewall) when I lost the connection for a minute or so. It came back up before I left, but as I was driving over there, I received a call from F at XXXXXXXX saying the connection was down. I said I was on the way over and I'll take a look when I get there, so I didn't think too much on either incident.
Once there, I powered down the router, installed the interface and powered the router back up. A minute or two to let it boot up, and yes, they are down. I couldn't even ping the router, much less surf the Intarweb. I could see that the router was up and running, but without the special console cable, I couldn't diagnose the problem.
I then drove back to The Office. I couldn't reach their router from our side, so I grabbed the special console cable and headed back to their office.
Once back there with the ability to log into the router, I could see the problem—plugging the T-1 card in renumbered some other interfaces, including their DSL interface. When it powered back up, the configuration for interface
ATM0/0 (the DSL interface) was ignored because interface
ATM0/0 didn't exist. And consequently, interface
ATM1/0 wasn't configured because there was no configuration data for interface
And silly me, I didn't have a copy of the router configuration on hand, so it looked for a minute like I would have to drive back to The Office, print out the configuration for this router (I have backups of all our routers on my workstation) then drive back to the XXXXXXXX office, but then I had a better idea: I called Wlofie, had him log into my workstation and read off the DSL interface configuration.
That done, the connection came right back up. Then I could turn my attention to configuring the T-1 interface.
Only it didn't come up an interface, but a “controller.”
Didn't think much of it until I realized I couldn't assign an IP address to the T-1
interface controller. So I did what I always do in such a situation and called G, our Cisco consultant.
Turns out that the interface card we had was a voice T-1 card and not a data T-1 card.
Not much I can do until I get the right card (and we don't have a data T-1 card for this particular router at the office). But since the DSL was back up and running, I decided to call it a night.
Until half an hour later when I got a call from Smirk—they were still down. Fortunately, I was still in the area and had access to a computer. A quick test showed the DSL was up, but that anything else on their network was unaccessible. I called XXXXXXXX and talked to their IT manager C.
Now C is a nice guy and I'm sure he knows his computer stuff, but networking is not one of his strong points. And it because clear to me that I was going to have to go back and debug their network.
I knew the router was okay, since I could get to it from the Internet. And when I got to their office, I checked out their Linksys wireless unit (which does NATting) and found nothing wrong with it. That left the only thing sitting between the two—a switch.
On a lark, I power cycled the switch.
Their network started right back up.
It seems they've been having some power “issues” recently.
Everything else had been powercycled.
But the switch.