Thanks for the reply. Since my original posting, I have discovered that when a Ghost session is set up to image a computer, all of the 7937 phones plugged in to the same switch as the Ghost server will be unregistered. As soon as the Ghosting is done, the phones come back up.

I am working with TAC and giving them trace files, but it looks like the only thing they can do right now is to create a bug on the problem.

I thought I would update this posting in case somebody experiences the same problem and goes looking for a solution...

After a failed attempt at throwing a new firmware version at the problem, it turns out that multicast support is a "feature" of the 7937 phones. It interprets a Ghost multicast session as a denial of service event and goes into an unregistered mode as a security feature. (Feature-rich products are such a pain!) Our 7936 and 7961/41 phones simply drop the Ghost traffic at the phone level and have no problems staying active.

It was recommended to me to disable multicast traffic on the phone VLAN at the switch level. Either that, or I could continue to make the hardware technicians set up a separate network for imaging PC's.

Hi Patrick,

Interesting problem (that must have taken awhile to figure out :)+5 points for this very kind follow-up!

Take care,

Rob

What does not make sense about this, that if that is a "Feature" concerning some type of DoS attack, why the phone drops the call and unregisters....??? This is still a denial of service....

I had the same thoughts exactly that the security feature was still denying me the ability to make and receive calls. Here is the technical explanation I received, which gives more details about what is happening:

Here is the Design Differentiation between 7936 and 7937 conference station phones.

The New 7937 phones are designed to support multicast. However the side effect of this what we observe during multicast ghost traffic.

GI-01 Remain stable during flooding attack:

During a Reference Flood directed to or through the device, the Standalone Device MUST remain stable which means continuing to operate without reloading its software, and maintaining the integrity and consistency of its internal data structures, and the device MUST recover gracefully after the attack has ended. No human intervention MUST be required. M

In idle state, 7937 may temporarily un register during flooding and re-register with the call manager once the attack is stopped.

This is primarily because of the flooded network which doesn't allow the phone to gets its keepAlive Ack.

In Active call state, 7937 doesn't drop the call in spite of the flooded network. Choppy voice experience as the quality of voice degrades.

It also loses registration.

This is again because of the flooded network blocking skinny and RTP packets.

Voice quality is resumed once the attack is stopped.

M=7937

7937 has the capability to receive both unicast and multicast data.

Multicast support is provided for receiving RTP data for XML services(RTPMrx and RTPMtx).

When ghost process is in progress, all the multicast packets are directed to 7937's voice vlan.

Since 7937's architecture allows all multicast packets on account of its XML services feature, any high rate multicast stream(debug load phones receiving 3000 packets/sec) is equivalent to a DOS attack.

Hence when 7937 is subjected to receive high rate multicast stream, it losses registration.No new socket can be created and the old ones are closed UNDER ATTACK.

7937 keeps sending KeepAliveMessage to the callmanager. Since the network is flooded with multicast traffic, the messages cannot be reached to the CUCM. As per TCP protocol, if a message is not delivered to destination, the stack does the retransmission of the message. The maximum number of retransmissions is 12, and if the message is not delivered within the given number of tries , the socket shuts down causing the phone to lose registration.

When compared to other Cisco phones like 7940\60, these phones have switch that keep discarding the unnecessary multicast traffic.

7936 is tuned to accept multicast data from specified address like CDP address.It doesn't accept multicast data other than the one it is tuned to, so the multicast data received by it , will be discarded at the hardware level.

Whereas in 7937, multicast discarding cannot be done at hardware level because of absence of switch and also cannot be tuned to accept multicast data from specified addresses as it will be a limitation against XML services.

Having said that A workaround to inhibit the ghost traffic for Voice VLAN can help

by changing router / switch interface (eg. ip pim xxxxx ) of voice vlan on which 7937 is running .