CCM 3.0 and Remote Gatekeeper

[badelson]

With the Encore release of CCM, you are now able to register with one remote gatekeeper for call routing. This seems to work fine, but I have noticed infrequently that the registration times out and no subsequent RRQ messages are sent over. At this time, the easy fix is just to go into CCM And reset the gk ( even though it really doesnt reset it, it just forces another RRQ). This does not scale in the practical world and I was wondering if anyone else has seen something like this before ( a possible workaround). I have played with the TTL etc but I was not sucessful.

Thanks in advance.

[dgoodwin]

The only time I know this can happen is if the gatekeeper is shutdown and then is re-enabled.

If everything is functioning normally and the CallManager stops sending RRQs for no particular reason, that may be a new problem.

Please open a case with TAC. Be prepared to provide the CallManager version, gatekeeper version and config, and a CCM (and SDL if not already enabled) trace (DETAILED level) when this has happened.

[badelson]

Unfortunatley, this is not the case all the other endpoints remain registered with the Gatekeeper, just the CCM drops out. I have been meaning to open a case and will probably get to it soon, main problem is that this is a random problem, which means I can not get the exact log file that it occurs in etc.

It would be nice if the Cisco Gatekeepers has the ability to send a trap when a location times out of RRQ for does not re-register.

-Brian

[Daniel Baum]

Brian, I have two reports of this:

I had this issue with nine remote CM's homing to the gatekeeper at the host site via a Frame Relay WAN. They CM's (3.07) were losing connections to the GK (12.1T) periodically. I investigated and found that the Ethernet ports on all the Frame Relay router(s) were 10Mb but set to Full Duplex! The stats on the interface (all sites) had several thousand CRC's per one milliion packets. I had the customer clean each network and verify that all ports were set to auto negotiation. After this was done, the GK has not dropped since!

Another incident that this occured with one CM to a GK via a WAN and found that the cable from the WAN router was generating CRC's, replaced the cable and no more GK drops.

In both cases, nothing was wrong with the CallManager's or the Gatekeeper. It was all at Layer1!

Dan

Cisco SE

[badelson]

Dan,

Thanks for the suggestion. I have checked this and it is not the problem. On the interface, everything is clean:

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

Also, I have approximately 17 other Gateways registered to this gk at any given time period.

All the other units stay registered. Even if the RRQ was to timeout, it appears that the CCM does not retry.