CCM recovery when using TFTP addresses

Unanswered Question
Feb 24th, 2006
User Badges:
  • Silver, 250 points or more

I recently added a subscriber to my development environment. I don't have a separate network so my phones cannot make use of option 150 on the DHCP server. Rather they just get their IP from the inhouse DHCP, then figure out the callmanager via the TFTP address I program into the phones. This has worked like a charm. Now that I have my subscriber, I filled out the second TFTP address to all my phones. Then I shut down my publisher. The following happens:

My 7905 and IP Communicator rehome to the subscriber. My two 7960 and my 7970 go into a continuous loop. They only seem to try to connect to the default gateway in my network and my publisher.

Then the funny thing, if now I reprogram those 3 phones that have problems and make the subscriber the primary TFTP and the publisher the secondary TFTP, they come up again. But if I now activate the publisher and deactivate the subscriber, they once again loop.. so bottom line, even though they have 2 TFTPs, they are only able to connect to the first one.


Since this isn't a standard setup (normally you use option 150 and don't hardcode your call managers via TFTP options), none of my colleagues that set up call managers at customer sites have ever seen this problem. I know my callmanager setup is proper because my 7905 and IP Communicator can connect to either box. All my phones have the latest load available and I've already tried to reset the configuration on each phone.. it has no effect.


So I'm wondering, has anybody ever seen this rehoming problem on the 7960 and 7970 when using TFTP addresses rather than DHCP option 150 to make the phones find the callmanager, and do you have a solution for this problem (other than using option 150.. I'm not even supposed to have the server in this network but it's the only option that allows me to work productively and access the machine from all our offices and at home)

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
agopala Fri, 02/24/2006 - 11:22
User Badges:
  • Cisco Employee,

The fact that you are hardcoding TFTP server address is not a problem.


Take a look at this web page and read about TFTP redundancy. Althought cisco gives you an option, there are a lot of demerits to it.


http://www.cisco.com/application/pdf/en/us/guest/products/ps5820/c2001/ccmigration_09186a00804474f2.pdf


There are a couple of points I want to mention:


1. Why do you want a redundant TFTP server? The reason I ask this is, Your TFTP service is most needed when you deploy a new phone. Once the phone gets its configs/loads, even if the TFTP server fails, there is no impact. Right? When the TFTP server is down, IMO, the only real problem is you cannot deploy phones.. Your problem is when you have a pub or sub down.


2. How many phones do you have? and where are the TFTP servers? Note the amount of BW you need to get config/load files across a WAN.

3. If you have less than 200 phones, try to disable caching and then restart TFTP service on BOTH TFTP servers. See if that helps your situation. Caching can be disabled at TFTP advanced service parameters.


let me know if you have any questions.

Regards,

stephan.steiner Mon, 03/06/2006 - 05:55
User Badges:
  • Silver, 250 points or more

I guess I didn't do a good enough job explaining in my first post.


What I consider the "normal" configuration is that you have a DHCP server in the network, and you configure option 150 on it so that it points to whichever call manager you want your phones to connect to. From that, your phones get their load and config and all is well.


The problem is, my lab environment, is actually part of our productive network. Thus, my IP phones get their IP address via DHCP, however, there is no option 150 set on the DHCP server and it is not possible to set it (my two call managers aren't supposed to be in the productive network but it's the only way I can work productively.. ). Thus, my phones will get an IP address but will try to connect to the default gateway since there's no option 150 in the DHCP reply. In other words, the phones don't find my call manager. To fix that, I hardcode the TFTP servers into my phones. So when a phone starts up, it sends out a DHCP request, gets an IP address, then uses the hardcoded TFTP address as callmanager address, and it registers.

I cannot use static IP addresses for my IP phones either (once again, IT regulations require an approval process for fixed IPs, plus fixed IPs would mean the phones cannot be taken to another office for demo purposes). So I need the combination of DHCP plus TFTP addresses (which point to a ccm that has a static IP address.. I managed to sneak two static IPs through the approval process) for my phones to register with the call manager, anywhere in our company network. And if I have a demo at another office, I can just take a few phones from that location, and put in my call manager's IP address as TFTP address and they will register on my call manager.


I realize this is an unusual setup and you will not find it deployed at customer sites because it clearly doesn't correspond to best practices for IP phone setup. But it works for my scenario, and it's the only setup that works in my scenario.


Now, I add this second TFTP not for TFTP redundancy, but for call manager redundancy. And here's how it works out:


IP Communicator: no problem making the switch to my subscriber (TFTP2 in the config).

7905: no problem making the switch to the subscriber (TFTP2)

7960: does not even try to contact the TFTP2

7970: does not even try to contact the TFTP2


Now, since once registered, the phones should get the entire CCM list (and the hostnames are resolved via DNS), I also tried just having one TFPT defined. The 7960 and 7970 act just the same (even though they have both CCMs in the CCM list.. as do all my phones regardless of the type).

The 7905 doesn't even realize there's a second CCM anymore... it needs to have the TFTP2 configured.

The IP Communicator acts like it's supposed to.. it tries the first Call Manager, and when it doesn't respons, it tries the second and registers.


Regarding your other questions: 10 phones, and both CCMs (I use my CCMs as TFTP server, not an external one) are in the same location, and the same network as all the phones (in fact, everything is connected to the same switch so traffic never goes outside my own switched segment.. only PSTN calls go outside my own switched segment).



@edit: I found a more "regular" configuration that has the same problem: imagine that you have set up everything with static IP addresses. In that case, you need the TFTP on the phone as you cannot change the callmanager list on the phone. So you enter the IP address of one of your call managers, and the phone then registers. But if that call manager goes offline, the phone no longer finds its tftp and goes into an external loop (at least the 7960 and 7970 will.. and so will the 7905 but the 7905 will come back if you configure the second TFTP to point to your second callmanager.. which is not the case for the 7960 and 7970)

agopala Mon, 03/06/2006 - 12:10
User Badges:
  • Cisco Employee,


Ok, If you need call manager redundancy, you do not need to enable a second TFTP server. I have seen more problems created by this, that ease.


So, remove the second TFTP server address in the phone, also, shut down TFTP service in the subscriber.


Let us try to determine why your phones do not fail over when the primary server fails. First thing, when the phones are registered, check

settings -> 3 -> 21 and 22 and 23. Does it have info of your pri, sec and SRST CCMs? If it does not, go to the CCM admin page and check if you have the CCM groups setup properly. Use only IP addresses. Let me know what you find.


Actions

This Discussion