So We have a 700+ seat roll out of an Avaya MultiVantage Solution, with 4612 IP phone sets (standard), utilizing Avaya's power mispans for Power over Ethernet in the distribution wiring closets. A significant number (about 1/3) of our phones "die" every 50 days or thereabouts, oddly close to 49.7, makes me wonder. Regardless they all go into a "Discoverying..." state, or "DHCP Count..." state, the ones in DHCP count occasionally flood my network with about 25,000 packets of ICMP redirect every minute from some IP address it decided to give itself to a valid CLAN card IP! No joke, very odd. Now I'm wondering has anyone else ever had this problem or heard of this problem. Avaya is saying much, we've had a slew of Avaya and in house experts look into the situation, nothing firm. These phones run Agere's 8301 and 8302 "Phone-on-a-Chip" silicon.

For the last 150+ days now, we've had a crash every 50 days. Not good. We're all up to date on the firmware versions throughout house, or so I'm told.

Sorry, an above sentance should have read, "Avaya is NOT saying much"

In response to the large number of failures on the S8700 IP solution we are a distributor of this technology with 3 1000 seat contact centres which do not experience this type of problem. We do find that the new generation of IP telephones is significantly better than the early 4612 range. We also have a number of high volume traditional endpoint contact centres using the S8700 technology again with no significant problems to date.

I hope this helps

Jason

This may be a stupid idea, but I have come across the strangest things doing software support.

Is it possible that a log file is being filled every 50 days and this is stopping the software.

probably not, but there it is.

regards

DaveC

Jason I may havefound your problem,

The "smurf" attack, named after its exploit program, is one of the most recent in the category of network-level attacks against hosts. A perpetrator sends a large amount of ICMP echo (ping) traffic at IP broadcast addresses, all of it having a spoofed source address of a victim. If the routing device delivering traffic to those broadcast addresses performs the IP broadcast to layer 2 broadcast function noted below, most hosts on that IP network will take the ICMP echo request and reply to it with an echo reply each, multiplying the traffic by the number of hosts responding. On a multi-access broadcast network, there could potentially be hundreds of machines to reply to each packet.



The "smurf" attack's cousin is called "fraggle", which uses UDP echo packets in the same fashion as the ICMP echo packets; it was a simple re-write of "smurf".




There are two parties who are hurt by this attack... the intermediary (broadcast) devices--let's call them "amplifiers", and the spoofed address target, or the "victim". The victim is the target of a large amount of traffic that the amplifiers generate.

I'm not sure about the 50 day cycle, but I suppose it could be a more sophisticated version of the original exploit programme?

Cheers
Jason

I am curious as to whether my information was of any help Jason !!!!!

Regards
Jason

I would like to congratulate Jason D on your response to Jason H. Like many others in the forum, you contributed your knowledge to hopefully help solve a complex question for a real situation.

I think that this is exactly the input we need, keep it up!

Jason H, did this help you? If not then how have you / technical experts / Avaya moved the situation on? Have you planned to set up monitoring facilities for the next expected crash? Are the phones affected the same each time or different banks? what contingency plans have you and the call centre generated to keep traffic moving? There is a lot to be gained from all different members of the community here, resourcing, operations, reporting, sales and marketing. Let alone of all the techies :)

Regards,

Ian

I have come across this issue but the solution did not provide 100 % resolution, still couple of phones look for discover DHCP . Worked with the MID SPAN unit PDU version package to fix this, seems satisfactory

Hi,

This is a follow up to an old post. We where never successful in full eliminating this behavior but did find vintage hardware CLAN's had a part in it.

Jason D, I do have to correct you here, smurf is an program that came out the the mid to late 90's, it's not one of the more recent DoS attacks, and surely other devices would have been effected on the network.

My advice is to stay away from the 4612 IP Phone sets, and insist your CLAN and MedPro's are all of the latest hardware versions, firmware versions, and all are identical. Also, if you're investigating the Avaya VoIP products, ask up front how many devices they recommend you use in a single collision domain. We where denied responsive support because we had greater than 250 phones in one collision domain.

Thanks for the update, Jason.

It's always nice to hear how things pan out for our members, even if it isn't always good news. Way too many posts seek answers or pose questions without any follow-up, which is a shame. It's always good to see some kind of resolution or update, and one member's experience can perhaps assist another.

Hope to see you posting more, Jason.

Regards,

John