If I remember the original 7912 had a traffic issue with the built-in switch, but I think that was just broadcast traffic and the next gen of that model fixed it.
The original 7912 didn’t have a switch, it was all done in CPU. This is why it rolled over with lots of unicast or broadcast packets. My distaste for that phone persists to this day because of this. -Ryan On Feb 14, 2017, at 2:37 PM, Stephen Welsh <[email protected]<mailto:[email protected]>> wrote: Thank you for sharing your findings Adam, Did you determine if the high volume traffic causing an issue is just that sent to/from the phone, or all data via the built-in switch? If it’s the latter I’d be surprised if this is a new finding. If I remember the original 7912 had a traffic issue with the built-in switch, but I think that was just broadcast traffic and the next gen of that model fixed it. Not much consolation but at least you ‘only' have the hardware cost of the phones to factor if you leverage the trade-in program and get your free copy of MigrationFX. MigrationFX has now been used to migrate 10’s of thousands of phones and used with clients with as large as 80,000 phones. We are launching the next release of MigrationFX (Version 2.0) on the 1st March (http://events.unifiedfx.com<http://events.unifiedfx.com/>), here are some of the main enhancements: * 64Bit Support (unlocks access to all system memory, not just the first 2Gb) * Next generation datastore for increased scaleability * Significantly improved multi-cluster performance * Ability to specify per device Migration Phone & Button Template allowing granular control of migrated configurations * Copy Side Car configuration from Phone Template * Better handling of devices with Intercom buttons * Fixes issue when migrating phones with an apostrophe character in the description * Simpler Topology lookup with the option to use historical topology * Improved Windows Service Startup * Extension Mask lookup as part of Search by Extension * Ability to customise the CUCM Access Group used for access to the AutomationFX web interface Of particular note is the ability to specify a custom Migration Phone and/or Button Template per device before the migration. This provides the following benefits: * Use your own naming convention for Phone and Button Templates, no need to re-name afterward * Granular control of device configuration including Product Specific Configuration * Single operation for complex migrations like a 6 line 7865 to a 5 line 8851 with side cars * Consolidate multiple (or individual) button templates automatically as phones are migrated Kind Regards Stephen Welsh CTO UnifiedFX On 14 Feb 2017, at 18:55, Pawlowski, Adam <[email protected]<mailto:[email protected]>> wrote: All, Just to follow up on this one, though it has been a long time… While the details on the whole thing are very slim, TAC was able to actually reproduce the issue we were reporting on the 7941/61 and G-GE flavors of phone. Phones that receive “too much” traffic (somewhere in the order of billions of packets) seem to fall apart, which results in poor audio quality internal to the phone (jitter/loss not seen in captures before or through the phone), high ICMP echo latency, delay in functionality, etc – until the phone is power cycled. Clicking “Reset” in the UCM does nothing to fix this. I have one site where this occurs frequently, and another with similar behavior issues but the condition seems to be transient. Unfortunately, I don’t have a confirmation if this is a hardware or software issue, but, this conclusion was reached only just after the 1/31 end of software support for these models, and given the hardware end of support dates being long ago, the issue will not be fixed. It is implied it is a hardware issue, but we don’t know what actually is going on in the background on the device. Something with the nature of the traffic that these phones are exposed to (volumes? Types? Sizes?) is a problem, and the 7900 series, save for the 7945/65/75 and the 7916, are dead and done. The recommendation has been to move to the 7800/8800 series of phones, which will not be a cheap nor prompt fix, but, if you all are still chasing this sort of issue, unfortunately, if it is the same as ours there is not much to be done it seems. Regards, Adam Pawlowski University at Buffalo From: Stephen Welsh [mailto:[email protected]] Sent: Tuesday, November 08, 2016 12:59 PM To: Pawlowski, Adam Cc: Executive; Wes Sisk (wsisk) Subject: Re: [cisco-voip] Traffic Issues with 7900 Series Phones Hi Adam/Wes, Thought it may be of interest Wes so copied you in. We got confirmation from another client that they have an issue that causes their phones to unregister (reset as far is we can tell) when taking a screenshot (using PhoneView or manually with the direct URL on the phones web pagehttp://[PhoneIP/CGI/Screenshot]). The client had an issue on the 7962 running SCCP42.9-4-2SR2-2S, specifically when using a hostname for the AuthenticationURL, when he changed it to an IP Address it resolved the issue. I suspect this may be a firmware bug (possibly a new one), but it may also have been an issue with the host(s) the hostname was pointing too. However this is the first time we have seen this behaviour and the phone should not un-register just because it cannot communicate with the authentication server. Kind Regards Stephen Welsh CTO <image001.png> On 4 Nov 2016, at 20:37, Pawlowski, Adam <[email protected]<mailto:[email protected]>> wrote: Hi Stephen, We are a PhoneView user certainly. If you are accessing the phone web server we have noted that it will cause other operations to be missed that involve it (XML anyways) . We aren’t running an idle URL here, nor is our homegrown user location polling script running, as far as I am aware – but I will check. If there’s some information we can provide that would be useful to you, or that we can look at here, we can work on that sure. We’re on 9.4.2SR1-1, testing 9.4.2SR2-2 to the same result. I have not tried to roll back to a previous version, but I am having flash backs to off hook autodialing and expansion module crashing issues that I certainly don’t want to go back to. Regards, Adam From: Stephen Welsh [mailto:[email protected]] Sent: Thursday, November 03, 2016 2:13 PM To: Pawlowski, Adam Cc: Executive Subject: Re: [cisco-voip] Traffic Issues with 7900 Series Phones Hi Adam, I believe your organisation is a PhoneView customer, we have a recent support ticket that may be related to this issue, he describes issues with the phone responding when taking screenshots (i.e. accessing the phones web server), I wonder if this may be a new bug introduced in a new version of firmware. Happy to host a WebEx session to investigate. Kind Regards Stephen Welsh CTO <image001.png> On 2 Nov 2016, at 18:22, Pawlowski, Adam <[email protected]<mailto:[email protected]>> wrote: After much hair pulling and frustration, I wanted to ask the group here in case anyone has seen this or has any thought on what we should be looking for. We have a number of 7900 series phones that have been exhibiting issues that appear to me to be that the phone is getting hung up on something. Some sort of frame or packet is screwing with the network chip/board or the OS which is causing it trouble. I see missed traffic, missed responses, high ICMP echo times - and phones that eventually get stuck with their ICMP echo response times being all over the board - with some report of call trouble and CMR showing crazy jitter. If I power cycle the phone that clears and it works fine for a while. I realize these items are pretty much end of useful life, pretty much all done with software support, and are going to drop off of the compatibility matrix and probably functional support in the near future. But, while we still have a ton of them - has anyone noted any particular type of traffic that causes the 7900 series phones grief? I don't have loss on the network, there do not seem to be any transient broadcast storms rolling by. We do see an increased amount of mDNS, IPv6 (phones are v4 only) etc, but nothing stands out as causing a particular problem. It just seems that whatever this is, is causing a memory leak or something, wherein it gets bad enough that things go to hell eventually. Any thoughts? Adam P SUNYAB _______________________________________________ cisco-voip mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip _______________________________________________ cisco-voip mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
