3CX Fail Over

[Mark Jones]

Hi I'been trying to get the 3cx to failover but it has been unsuccessfull, meaning I waited for 10 to 15 minuets and while monitoring it i notice only a few phones failing over this use to be instant but not now both systems are on ver 16.0.1078 can anyone help. also the only way to get the dns to fail backover to the primary is rebooting the system there should be another way to do this in the system running Debaian. any help will do.

 

[ChrisKoll]

Not enough information.
Are you using 3CX FQDN or custom?
Do you have an enterprise license or pro?

 

[JohnS_3CX]

Hi Mark,

10-15 minutes for the phones to reconnect, OR for the passive server to start its service and come up?

 

[Mark Jones]

Not enough information.
Are you using 3CX FQDN or custom?
Do you have an enterprise license or pro?

using 3CX FQDN Pro license I've tested thisin the past and it failed over instantlly but not any more

 

[Mark Jones]

Hi Mark,

10-15 minutes for the phones to reconnect, OR for the passive server to start its service and come up?

10 t0 15 minutes to start failing over

 

[JohnS_3CX]

Hi Mark,

We need to get more specific though during troubleshooting, because failover is comprised of multiple steps.

So it's 10-15 mins for:

a) the phones to reconnect

OR

b) for the passive server to start its services and come up

 

[Mark Jones]

Hi Mark,

10-15 minutes for the phones to reconnect, OR for the passive server to start its service and come up?

for the passive to begin taking over and its like one phone at a time.

 

[Mark Jones]

When i first implemented this there was no issue with failing over but now I can see a few phones coming up but not fuctional.

 

[cobaltit]

for the passive to begin taking over and its like one phone at a time.

Ok, so your explanation is still unclear.

Passive server taking over is when the Passive server see's the active server is no longer responding and starts the services. This is 30 seconds by default.

At this point, you are failed over.

Phones registering to the new instance is entirely based on DNS and the phones. Without an explanation of your setup as requested here we're just guessing. But if your phones are using the 3CX FQDN and public DNS then the TTLs for Pro license are 6 hours so seeing phones in a few minutes is pretty good.

 

[Mark Jones]

Ok, so your explanation is still unclear.

Passive server taking over is when the Passive server see's the active server is no longer responding and starts the services. This is 30 seconds by default.

At this point, you are failed over.

Phones registering to the new instance is entirely based on DNS and the phones. Without an explanation of your setup as requested here we're just guessing. But if your phones are using the 3CX FQDN and public DNS then the TTLs for Pro license are 6 hours so seeing phones in a few minutes is pretty good.

ok this is how i test the failover i shut down the active server and wait for the passive server to take over this is not happening. so youre saying it will take 6 hours for the phones to register on the secondary server?? no way

 

[cobaltit]

Still haven't explained your setup nor what your definition of take over. If the services are started on the passive server and incoming calls from your dial tone source are hitting the PBX the it's taken over. And yes the TTLs for Standard and Pro are 6 hours. For Enterprise it's 5 minutes. If you are using public DNS then yes, it can take up to 6 hours for phones to failover if you are using public DNS. If you are using internal DNS then you have more control. But again. everything is just guessing if you don't explain your setup. Reading these might help also:

3CX Failover

FQDN Management and Allocation - FAQs | 3CX Guide

I assume you read the failover guide to get where are at, but the DNS failover is explain there and might be worth a second read.

 

[Mark Jones]

Ok guys I dont understand how you cant see the setup. I have 2 linux servers, a primary with 150 phones and a pri and a secondary passive server both using 3cx FQDN both with a Enterprise License ver 16.0.0178.

Enterprise Perpetual
Version Number	16.0.1078

. When testing the failover I Me I shut down the active server by sending the shutdown command and wait for the passive server to become the active server point blank. The FQDN changes instantly I know this because now the 3cx FQDN points to the secondary server, but the phones are slowly coming over, I check them after the 15 minutes mark and still only a couple of phones up on the passive server.*****************

in the past I've done this and the failover was instant but not now and nothing change on my end, I was posting this in the form to get answers but i see now I cant so I will be calling someone important later to get these answers.

 

[Mark Jones]

Still haven't explained your setup nor what your definition of take over. If the services are started on the passive server and incoming calls from your dial tone source are hitting the PBX the it's taken over. And yes the TTLs for Standard and Pro are 6 hours. For Enterprise it's 5 minutes. If you are using public DNS then yes, it can take up to 6 hours for phones to failover if you are using public DNS. If you are using internal DNS then you have more control. But again. everything is just guessing if you don't explain your setup. Reading these might help also:

3CX Failover

FQDN Management and Allocation - FAQs | 3CX Guide

I assume you read the failover guide to get where are at, but the DNS failover is explain there and might be worth a second read.

you mean to tell me that you dont know how a failover server is setup** smh, I've read the guide, I even wrote one for Toshiba IP Edge product, if you asking me if I know What Im doing i can probably do this better than you. But I'm only here for answers***** stop beating around the bush and lets get to the bottom of this, I can guess all day long by myself lets get on a call and test this system failover.

 

[JohnS_3CX]

Hi Mark,

If you saw the FQDN quickly change then you can be highly certain that failover worked as intended.

As for the phones it's a different story and has nothing to do with the 3CX failover.
It is entirely up to them to find the new server - period.

Normally what they do once the lose the primary is that they will try to resolve the FQDN again, and if they discover the IP has changed to the failover they will register there.

Hints: So perhaps, the issue is the specific phones, or the local DNS server that replies to those phones is not replying to them with the new IP of the secondary server.

I'm sure you can run a capture on one of your phones, then trigger the failover event, and once they (finally) register again you can go look at the capture and find out for yourself why they took so long. Go ahead and do this and I suspect you will gather some valuable information.

 

[Mark Jones]

Hi Mark,

If you saw the FQDN quickly change then you can be highly certain that failover worked as intended.

As for the phones it's a different story and has nothing to do with the 3CX failover.
It is entirely up to them to find the new server - period.

Normally what they do once the lose the primary is that they will try to resolve the FQDN again, and if they discover the IP has changed to the failover they will register there.

Hints: So perhaps, the issue is the specific phones, or the local DNS server that replies to those phones is not replying to them with the new IP of the secondary server.

I'm sure you can run a capture on one of your phones, then trigger the failover event, and once they (finally) register again you can go look at the capture and find out for yourself why they took so long. Go ahead and do this and I suspect you will gather some valuable information.

Awesome now we are getting some where! thanks! i will try this as soon as I can!

 

[accentlogic]

We have seen some firewalls hold DNS cache entries longer than the TTL specifies - sometimes many hours. If phones are using stale DNS records they will not cutover properly.

We prefer to use an SBC at client sites with more than one phone. One advantage to this is that failover for the desk phones no longer relies on DNS. The passive server is set in the SBC using the IP address. If the SBC finds the Active server is down it will start attempting connections to the passive server IP.

Using the above scenario gets you out of waiting on desk phones to connect, but you will still need to solve the DNS cache issue (or whatever it is) for softphones and web clients.