unexpected hassles in moving a DSL line

[rmorin]

This note is mostly directed at the folks that run Sonic.net; however, others may find it interesting...

I have spent the last couple of hours trying to set up a smooth transition of my DSL service between two of my telco lines. Everyone I've spoken with has been helpful and courteous, but the results have not been optimal. Indeed, I'm quite surprised at how baroque things have become. Details follow.

We have two voice lines, one of which we no longer need. However, because this line is used for DSL, we can't just turn it off. Instead, we have to move the DSL service over to the second voice line, then cancel the first one. No problem.

When I asked Sonic about making the transfer, I was told that I would be told when (ie, what day) to expect the change. At that time, I could move my DSL modem onto the second line. Of course, if anything went wrong, we'd be offline until all problems were resolved.

I didn't like this proposal very much, so I asked about setting up parallel DSL service on the second line. This would allow me to fall back to the first line if the second one didn't work. I was told that I could set up a new account for the second line and that I would be charged a pro-rated fee for the time (eg, a day or so) when both accounts were (nominally) active. This seemed like a reasonable solution, so I placed the order for the second account.

Unfortunately, DNS issues then came to light. We have a (small) set of static IP addresses for which we supply DNS. In order to prevent a gap in DNS coverage (or worse), I asked that I be given the new addresses as soon as possible. This, I reasoned, would let me set up the new addresses as fallbacks to the current ones. I could then use the first set until I knew that the new set (and line) were working.

I was then told that things couldn't be done that way. In fact, the only procedure that I could use to avoid a gap in service would be as follows (no, I'm not making this up):

• New service, with a single IP address, would be set up on my second line.
• I could then request a new set of static IP addresses.
• Once these were in place, I could add them to my DNS configuration.
• Once the new addresses had promulgated, I could try the new line.
• As soon as the new setup seemed reliable, I could cancel the old account.

The result of all this is a week-or-so delay in switching to the new account, plus charges for a duplicate (but unusable) account over a period of several days. None of this is terribly onerous, but it wasn't the kind of thing I have come to expect from Sonic. Is someone confused (other than me)?

-r

[virtualmike]

Honestly, it sounds like you had a very rare situation. You don't need to defend your reasons, but in most cases, people would just drop the line without DSL. The fact you have multiple static addresses made it more complicated, requiring a procedure for which there's not really a standardized, documented process.

[rmorin]

I agree that this is a somewhat unusual situation. FWIW, the reason we aren't dropping the non-DSL line is that it is our main number. The voice channel on the current DSL line is only being used for fax and incidental calls.

My real questions, however, have to do with the provisioning process:

• Why can't Sonic allocate the new IP block now, so that I can put it into my DNS configuration?
• Why do they need to set up a single IP address, then replace it with the IP block a few days later.

The folks I talked to told me (several times) that "the system" wouldn't let them do this or that. In that case, the system may need a bit more flexibility. More to the point, there should be ways to do manual workarounds when the system's overweening process is preventing a rational approach from being taken.

[virtualmike]

I understand the points, but again, if this situation has not been encountered before, it's difficult to fault Sonic.net for not having anticipated it. And if it's not a common request, Sonic.net may be reluctant to expend resources to develop a solution for this situation, when the list of requests from members is already fairly long.

Regardless of your experience, how likely are you to need to do this again?

Though your post didn't state, I'm guessing that your phone is through AT&T, not Sonic.net Fusion? That also makes it more complex. With Fusion, I'm pretty sure that the numbers could have been swapped and then the unneeded line could have been dropped. However, AT&T won't make it that simple, which led to the complex process you encountered. Why not put some of the blame on AT&T?

[rmorin]

Why not put some of the blame on AT&T?

I'm quite willing to believe that AT&T imposes assorted restrictions and hassles on Sonic, but I doubt that this extends into the area of IP address allocation and management. Nor am I expecting Sonic to recode their "system" just for me.

It just seems odd that they can't provision a block of IP addresses in one pass, rather than two, and that there seems to be no way to allocate a block of addresses pre-emptively. After all, Sonic controls their own IPs...

[kgc]

t just seems odd that they can't provision a block of IP addresses in one pass, rather than two, and that there seems to be no way to allocate a block of addresses pre-emptively. After all, Sonic controls their own IPs...

The issue is that the provisioning, including IP assignment, is all fully automated so any manual work like this literally means that a developer would have to go in and figure out the correct SQL statements needed to massage the databases to achieve the desired outcome. There are a lot of reasons why we do our best to avoid that kind of work. However, unless I'm mistaken, the DSL order forms allows you to select multiple static IPs? If not, you should be able to use the membertools to upgrade to your desired block size as soon as the service goes up - it is a real time operation.

[virtualmike]

I'm quite willing to believe that AT&T imposes assorted restrictions and hassles on Sonic, but I doubt that this extends into the area of IP address allocation and management.

My point was that AT&T's policy not to simply swap the phone numbers, but instead require that a separate DSL service be established on the line to be retained, led to this situation.

If AT&T had flipped the numbers, so that the phone number you want to keep was on the line with the DSL, would we be having this conversation?