Network question: Keeping remote IP Phones online when failing over to a backup ISP.

Factual Questions
1

I’ll try to explain the issue. We use Mitel IP phones. We ran into a somewhat counter-intuitive issue with them because of the storm.

We use ISP A as our main provider. ISP B is an inexpensive smaller bandwidth provider we use as a backup. Our router is configured to automatically failover to ISP B if ISP A becomes unavailable.

Here in the Philly office, the IP phones are plugged into the LAN. This is not dependent in any way on the internet and they’ll continue to work even if we lose both ISP A and ISP B.

In our west coast office, the phones are configured as teleworker phones, so they are VOIP phones that go over the internet to connect to our Mitel server in Philly. They are programmed with the static IP address provided by ISP A. Because of this they can be dialed by 4 digit extensions as if they were in the Philly office (they also have direct dial numbers).

Tuesday morning, because of the storm, we lost service from ISP A and automatically failed over to ISP B. No problem! We still had internet, just a little slower. Except that when the west coast office opened a few hours later, the manager called me on her cell phone to inform me that their phones were dead, with no dialtone or display. :smack:

They didn’t get phone service back until this morning when ISP A restored service.

Okay, storms of this magnitude are rare, but the reason we got the backup provider was because ISP A does occasionally go offline for 10 or 15 minutes. Just about any provider can have occasional short outages.

Until now we never thought about the west coast phones being impacted by this. Now that I realize it, I’m concerned about the occasional temporary outages, as well as any future prolonged outages.

I’m looking for a solution. A way for the phones to essentially failover to ISP B’s IP if A stops responding.

The phones don’t appear to have this capability built in. What I’m wondering is if there’s some device that they could plug into locally with a known local IP address which would then forward them to our IP address and failover to the secondary IP if the first stops responding. I want to sort of virtualize the IP address for the phones so they can continue to communicate with the same address regardless of the actual endpoint.

Forgive me if this is a duh! question. I’m not yet a networking guru.

2

The easiest way to do this is to have a router at each end and create a site-to-site VPN. This creates a tunnel between your two offices.

When the tunnel is up and running, the ip phones can be on the same network without any knowledge of the underlying ISP network. If ISP A fails, the head office router will fail over to ISP B and reconnect the tunnel.

There are other methods including using Border Control Gateway Protocol (BCGP) to allow the same IP address to available through different ISPs, but it is probably overkill for this application.

3

So the router in Philly would reconnect by knowing the IP address in the other office?

4

That is correct.

5

And the phones would see the router as a local network? They would no longer be programmed as teleworker phones? Am I understanding this right?

6

Unfortunately, I don’t know your phone system but I would think so.

7

Yes.

Either the phones are teleworker - talk to a public IP address - or they are “local” and thanks to the VPN tunnel think they are on your local office network.

The absolutely simplest solution would be to tell the remote phone people how to reprogram the remote IP dderes if possible.

Otherwise, I don’t think remote phones can have 2 addresses.

8

I can’t have them reprogramming the phones every time it fails over for 10 minutes, and I think there’s an added complication that I didn’t think of before.

While our main ISP has a static IP address, our backup is an inexpensive 4G provider that most likely does not have a static IP address, so anytime it fails over I’d have to determine it’s address and then contact the other office somehow and tell them what it is. Since they’re on the west coast, they are there 3 hours after I leave for the day so if there’s a problem during that time, there’s nothing they can do.

I think the VPN is the best solution.

9

Ok, I think I see what’s going on. Basically, your phones in LA are configured to hit your public IP address in Philly to get service. When you switch to a different provider, obviously your public IP changes, since it would be two different address blocks because it’s two different vendors. Correct?

Assuming that’s the case, you could do the nailed up VPN thing FinsToTheLeft mentioned…that would eliminate having to use a public IP. Basically, when there is a fail over, you’d need to have your firewall/gateway in Philly simply nail up a new channel using the alternative ISP connection to the firewall/gateway device in LA and Bob’s your Uncle…everything is peachy.

Alternatively, you could use DNS to play some games with alternative gateways, and use a name instead of an IP address for your phones. You will have some convergence weirdness, but it’s do-able. But for simplicity, assuming I’m getting what you are writing in your OP, I’d probably go with option A (FinsToTheLeft) as the simpler and more elegant solution.

10

Hmm. Now I’m wondering if the other office has a static IP. There may be a reason this was set up this way.

11

If you are talking about a static public, then most likely they don’t, unless you have a requirement for a static IP on your remote site ISP (like, if you have a web server or something like that at that facility that requires a static public, or if you are allowing your users to VPN into the remote facility…something like that). I’m sure your main Philly facility DOES have a static public IP address (maybe something like a /29 block of addresses if you require multiple public IP for different servers or different services), and that this is the issue…your static public address or block of addresses would be different between different vendors, since each vendor has their own block of public addresses to provide to their customers.

A nailed up VPN between your LA and Philly site would solve a lot of your issues, since to the phones it would all be the same…they would access your phones simply through a local, private IP address scheme, regardless of where the channel was nailed too. The only challenging aspect is simply setting up your Philly firewall/gateway device to know when the primary link has failed and use the secondary one to nail up the channel…and your remote LA facility to accept a VPN channel from either public IP.

ETA: You would need that remote LA site to have a static public, so if you don’t have one you’d need to get one to do this.

12

That’s my concern.

This isn’t really my decision. It’s just something I’m thinking about. I have to have some specifics before suggesting it to management.

I know that some people weren’t very happy about losing the phones in CA. As far as I can see, a VPN solution would be a small one time cost (the routers) and possibly a small ongoing cost for a static IP in CA, so it probably wouldn’t be a hard sell.

13

Well, you can tell them that the alternative to ensuring phones is to bring in a PRI at your remote site and get another Mitel server there. We actually have that method for one of our networks, despite having T1’s between remote sites, because some of our facilities (like some of the prisons/detention centers, some of the fire stations and critical police departments, etc) MUST have phone, even if the main facility or parts of the remote network are down. It costs a bundle though (your tax dollars at work!).

If you don’t have firewalls at your facilities, then I’d bundle that into part of the cost to benefits. A couple of Sonicwalls, for instance, aren’t that expensive…but would give you a higher level of protection if you don’t currently have firewalls in place.

14

since its just for failover purposes running a hamachi client on both ends might do as well simple for even non techy types to manage, it wont care which ISP its connecting over.

I know it is a type of VPN, just kind of a slow stupid one, but it would not require any additional hardware or modifications to ISP accounts.