With the wave of failing dot coms and ISPs, should you be thinking about changing your ISP? After all, you don’t want to be left without an Internet connection if your ISP suddenly goes under. It may be a good idea at this point to check with your ISP to find out if there are any changes on the horizon that you need to know about (like bankruptcy). Even so, if your ISP does go down the dot-com drain, there is a good chance that another, larger provider may buy out their assets as well as the subscriber base (i.e., you).
One such ISP, named Darwin (ironically enough), recently fell to that law of business selection, leaving its customers in a precarious position. The big question you’ll want to ask (if you find yourself in such a predicament) is what type of service the ISP will be able to provide during the transition of assets. However, that point could be moot if you decide to seek another provider. Either way, there are three relevant questions when considering a change: when, why, and how.
Deciding when is fairly easy: before your ISP goes under. Actually, the goal here is to time it far enough in advance to accommodate the provisioning lead time. With many carriers, it can take from three to six weeks to get a T1 installed. Dealing with why (or why not) is a little more complex. Change your ISP if you can’t get support answers or if you fear the company is slipping under. Now, this is no small decision to make. Consider carefully before pulling the plug. I’m a big fan of the small, local ISP and would never encourage a client to pull their business unless there were very real problems looming. However, the bigger carriers and providers, if nothing else, are generally very stable. It all comes down to the level of service you require. If the ISP is not providing that service, or if it has fallen off recently, the writing is on the wall. How do you switch to a new ISP? As painlessly as possible. The one thing to keep in mind is overlap. If you can continue service with your existing ISP until you can turn up the connection to a new provider, you will have no lapse in service. As a result, your network users won’t notice any disruption at all. Now, let’s continue our discussion with an actual recent situation in which I helped a client through just such a transition process.
A smooth transition
Fortunately, the client had already subscribed with a new ISP, since their existing provider was in Chapter 11. The client was awaiting a T1 installation, and the new ISP was dealing directly with the carrier to insure that all configuration details were correct. This was really an added bonus for the client, because they had no real technical staff in-house. Their existing ISP was still up and running, but service was a bit intermittent. I got the call to switch them when the T1 was terminated. Arriving on site, I found that they were using a Cisco 2600 series router with a fairly current 12.x IOS. One of the Ethernet ports was used to connect to the ISP, as they had a backbone in the building. I installed a Cisco internal T1 CSU WIC card in the router. Since this card is not hot-pluggable, we notified all users that the Internet connection would be down briefly. After shutting down the router and installing the WIC, we brought it back online. At this point, I checked the default settings for the new WIC, using the following commands:
Inet-router# show interface serial0/0
Inet-router# show service-module serial0/0
This device is capable of T1 or fractional T1, and I had no good information about how the T1 was configured. These commands yield basic information about the device configuration, such as framing, line coding, channel setup, etc. After connecting the CSU to the T1 smart jack, there was a green light showing on the CD LED, which was a good thing. However, the ALARM LED was yellow, which was not so good. So before changing any settings, I called the new ISP and had them reset the port at their end. Voila—instant connectivity. Fortunately, it was a full T1 and all the standard defaults were correct. I then configured the address on the WAN port S0/0 like so.
The information in these examples has been changed for obvious reasons.
I then tested the connection by pinging the ISP interface at the other end of the T1. Keeping in mind that we were still connected to the old ISP, we scheduled the changeover for lunchtime, when no users would be around. I then checked back with the new ISP to see if they had made the DNS changes regarding e-mail; they had done so that morning. They supplied the global address for the internal mail server, and at lunchtime, I would change the existing NAT settings on the router to reflect this and the new outside interface.
So that the router would be able to pass mail through, I performed a static NAT mapping from the internal address of the mail server to the new global address for the mail server. I designated the new WAN interface, serial0/0, as the outside NAT interface. Then I shut down the port connection to the old ISP. We tested again from the router by pinging, and all was well. However, when we tried it from a workstation, ping failed. I checked the NAT settings first, using the following command:
Inet-router# show ip nat translation
The static NAT translation showed up, as well as the workstation from which I attempted the ping. It was time to look elsewhere. Oops! I had forgotten the obvious. The default route was still pointing to the old ISP, and since that interface was shut down and disconnected, we were going nowhere fast. I changed the route like so.
At this point, the workstations were able to ping by address but not by domain name. Once we pointed the workstation to the DNS server at the new provider, name resolution worked fine. We were able to browse the Internet, but testing incoming e-mail would be a little more difficult. Since the DNS record changes hadn’t had time to propagate, we called the ISP and had them test it. To test mail connectivity, they simply telneted to the mail server on SMTP port 25 at the new global address. They were able to connect, and all was well. The last thing that we did was to install basic, inbound access control lists on the router external interface for security reasons. The list was configured to allow only necessary traffic from the Internet, such as e-mail, DNS, etc.
This particular ISP switch went well but only because most of the conditions were favorable. Regardless of whether or not your ISP is struggling, you might want to consider contingency planning. It’s not a bad idea to consider a backup plan in case your primary, high-speed link fails. A dial-up backup can be easily configured at your end, and you can make arrangements with the ISP to accommodate it at their end. Whatever you do, don’t throw away all of your old modems, because you may need them in a pinch if your ISP suddenly closes its doors.