<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.hoenzb
{mso-style-name:hoenzb;}
span.m-8103644660611907633apple-converted-space
{mso-style-name:m_-8103644660611907633apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I just want to ask this – and it may be unrelated – but it can’t hurt.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">When we had attempted to use “Peer Firmware Sharing” in the past, it was a total disaster. We applied a new load and a large percentage of devices just sat
there and did nothing on the firmware download screen until they were reset. That was …. Several years ago.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Since it was suggested earlier that we go and look at settings to see what is going on, I noted that a number of these devices have PFS enabled in the configurations
somehow. I plan to turn it off, but, before I do – my understanding is that this mechanism is idle once the phone is booted and is only applicable when an upgrade is taking place. There are a couple of bugs out there for UDP traffic to the PFS port causing
issues with the phone, as well as the phones getting stuck in configuring IP and not functioning (we have seen some at this site just bomb off and refuse to do anything other than arp for the gateway, despite a successful DHCP transaction. They won’t communicate
with anything on the same subnet either until power cycled). Some of these bugs seem to be open or in 9.4(2) in general.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Is this mechanism still “alive” while the phone is operating? Again I plan to turn it off, but, just curious.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Adam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> bmeade90@gmail.com [mailto:bmeade90@gmail.com]
<b>On Behalf Of </b>Brian Meade<br>
<b>Sent:</b> Monday, November 21, 2016 10:55 AM<br>
<b>To:</b> Wes Sisk (wsisk)<br>
<b>Cc:</b> Pawlowski, Adam; cisco-voip@puck.nether.net<br>
<b>Subject:</b> Re: [cisco-voip] Traffic Issues with 7900 Series Phones<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Also are you running any XML applications on the phones that may be bogging down the CPU?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Tue, Nov 15, 2016 at 11:31 AM, Wes Sisk (wsisk) <<a href="mailto:wsisk@cisco.com" target="_blank">wsisk@cisco.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal">Adam, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Are you using dot1x? There are some interesting things in that space.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Otherwise, maybe get 9.4.2es3 to pickup the fix for<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">CSCuq88325 7965 7945 excessive core files cause phone stability problems <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">-w<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On Nov 15, 2016, at 8:50 AM, Pawlowski, Adam <<a href="mailto:ajp26@buffalo.edu" target="_blank">ajp26@buffalo.edu</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">All,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We’re still looking at this with TAC, though the initial response was that the 7941, 7961, etc done with hardware and software support. There was an announcement
on October 20<sup>th</sup><span class="m-8103644660611907633apple-converted-space"> </span>that said software maintenance ended immediately (oops). Our timers and such are ubiquitous across our network, all defaults, and we don’t have this problem elsewhere.
I went with looking for MAC change traps and didn’t run into anything, going down that road. The phones don’t log any VLAN changes either in their logs. The phones are going out of service for UCM Closed TCP or UCM Reset TCP, and we see what looks like the
UCM not responding back with the proper SCCP KeepAliveAck, which causes the phone to sort of do nothing for 60 seconds. By then, since both the phone is waiting 60.0 seconds and the UCM is as well to hear from it, the connection is reset and closed.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Phones that are not sharing the data VLAN have been fine, but, we cannot implement that across this entire area due to the needed cabling, switchports, etc.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In another location we have these phones going what appears to be high CPU – the latency on the phone goes way up, with ICMP response, the response of the phone
to buttons and actions, and the call suffers from high jitter and broken conversations. Oddly enough, when we cap with SPAN enabled on the phone, the data looks fine going through it. Power cycling the phone clears this temporarily.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Everyone thus far has wanted to go down the road of loss somewhere on the network, but, as we continue to take captures, we see the conversation complete at
the UCM, and beyond the phone via “SPAN to PC port”, or at it with SPAN at the edge – the phone application itself is simply not responding in a timely manner, at least based on initial observation.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Given the earlier response that these devices are now done with support, this does not bode well, but, we are still looking.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Adam Pawlowski</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">SUNYAB NCS</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span class="m-8103644660611907633apple-converted-space"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> </span></span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Wes
Sisk (wsisk) [<a href="mailto:wsisk@cisco.com" target="_blank">mailto:wsisk@cisco.com</a>]<span class="m-8103644660611907633apple-converted-space"> </span><br>
<b>Sent:</b><span class="m-8103644660611907633apple-converted-space"> </span>Tuesday, November 08, 2016 12:50 PM<br>
<b>To:</b><span class="m-8103644660611907633apple-converted-space"> </span>Pawlowski, Adam<br>
<b>Cc:</b><span class="m-8103644660611907633apple-converted-space"> </span>Tommy Schlotterer;
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b><span class="m-8103644660611907633apple-converted-space"> </span>Re: [cisco-voip] Traffic Issues with 7900 Series Phones</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Not much visibility into L1/L2 on those phones; drop counters on the webpage or phone UI is about all you get.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Are the phones randomly unregistering? This is good baseline: <a href="https://supportforums.cisco.com/document/52176/understanding-sccp-phone-unregistration-and-failover-networks-perspective" target="_blank"><span style="color:purple">https://supportforums.cisco.com/document/52176/understanding-sccp-phone-unregistration-and-failover-networks-perspective</span></a><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">If some sort of frame issue, correct, not many options.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">What are the nature of messages being retransmitted?<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Also, anything interesting looking in the log files?<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">One age old odd one is CDP timers out of sync btwn phone and switch. Phone keeps IP but gets dumped into data vlan. Your choice on how to approach that.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">One possibility: If phones are unregistering then check the lastoutofservice reason on the phone, in the CM traces, or in the RTMT reports if you’re on a new enough version. I *think* we got these phones fixed to say “vlan change’ or ‘cdp
timeout’ or ‘ip change’ something like that if there were changes in the network interface.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Alternatively take a few phones stick them in a port that not trunked but in the voice vlan… do these exhibit the same problem?<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">next ‘heuristic’ guess after that is possibly arp cache refresh on the switch. have seen several issues where arp cache timeout was set low, switch re-arp for many devices concurrently, arp response dropped by input queue overflow and input
queue drop. net result the switch ‘forgets’ which port that phone is on.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">So…. where do the packets/frames EXIST and NOT EXIST in the network?<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">-Wes<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On Nov 4, 2016, at 4:32 PM, Pawlowski, Adam <<a href="mailto:ajp26@buffalo.edu" target="_blank"><span style="color:purple">ajp26@buffalo.edu</span></a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Wes,<br>
<br>
Thanks, that's good to know about ICMP. We've seen phones that get into a state where they reply with response times all over the board, lossy, which, Reset/Restart from the UCM does not rectify. Powering the device down does clear the condition - the set is
otherwise idle. I need to get into one of those via SSH and pull the CPU to see if it is up at that time, to see if there's an identifiable process that covers this.<span class="m-8103644660611907633apple-converted-space"> </span><br>
<br>
We did get some captures from in front of the firewall where the UCM resides, and from a monitor session from the switch out at the edge where the phone is connected. We can see the UCM sending re-transmissions to the phone, and the phone eventually replying
some time later. Unless there is a reason for us to try and get a copper tap on the segment between the switch and the phone, then, it would seem to be that there is some reason the phone is not replying to the UCM. There is nothing behind the phone, or any
output buffer drops. Our delay here in reply is in some number of seconds, so I don't believe there's any buffering involved that would be to that extent. <br>
<br>
What I fear is that if we get to a point where we can determine there is some frame that is an issue, these devices are past the point of any patching being done.... as of a few weeks ago. But, since replacing phones is not free and takes a bunch of time, I
still have to come up with something. I only saw a bug for large sized ICMPv6 with nothing particularly helpful in the wording and the workaround of "don't do that" so I'm not hopeful.<span class="m-8103644660611907633apple-converted-space"> </span><br>
<br>
We have our AM and SE aware of what is going on, and they've offered to help, so I'm hopeful we can eventually confirm the reason we're having trouble, even if we can't directly fix it.<br>
<br>
<br>
Adam<br>
<br>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">-----Original Message-----<br>
From: Wes Sisk (wsisk) [<a href="mailto:wsisk@cisco.com" target="_blank"><span style="color:purple">mailto:wsisk@cisco.com</span></a>]<br>
Sent: Friday, November 04, 2016 12:52 PM<br>
To: Pawlowski, Adam<br>
Cc: Tommy Schlotterer;<span class="m-8103644660611907633apple-converted-space"> </span><a href="mailto:cisco-voip@puck.nether.net" target="_blank"><span style="color:purple">cisco-voip@puck.nether.net</span></a><br>
Subject: Re: [cisco-voip] Traffic Issues with 7900 Series Phones<br>
<br>
Phones process ICMP traffic with low priority and throttling. This was<br>
implemented to stem DoS attempts. Consider looking more at Voice Quality<br>
effects, retransmits in packet captures, or parsing CCM traces for round<br>
trip times. As you state these phones are relatively late in life and<br>
therefore relatively stable.<br>
<br>
-Wes<br>
<br>
<br>
On Nov 2, 2016, at 2:42 PM, Pawlowski, Adam <<a href="mailto:ajp26@buffalo.edu" target="_blank"><span style="color:purple">ajp26@buffalo.edu</span></a>> wrote:<br>
<br>
Tommy,<br>
<br>
Sorry about that. These are a mixed bag. 41/61 both G and G-GE<br>
phones, with the gigabit ones primarily. Some SCCP, some SIP, mostly<br>
9.4.2SR1-1, but seen on 9.4.2SR2-2. PC attached or not, no difference, the<br>
only difference we've been able to create that stops this, is changing the<br>
data VLAN that runs through the phone to a different one, or something<br>
null (with no PC).<br>
<br>
Adam<br>
<br>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-----Original Message-----<br>
From: Tommy Schlotterer [<a href="mailto:tschlotterer@presidio.com" target="_blank"><span style="color:purple">mailto:tschlotterer@presidio.com</span></a>]<br>
Sent: Wednesday, November 02, 2016 2:37 PM<br>
To: Pawlowski, Adam;<span class="m-8103644660611907633apple-converted-space"> </span><a href="mailto:cisco-voip@puck.nether.net" target="_blank"><span style="color:purple">cisco-voip@puck.nether.net</span></a><br>
Subject: RE: Traffic Issues with 7900 Series Phones<br>
<br>
What specific Models of phones eg. 41s/61s? or 40s/60s?<br>
<br>
Thanks<br>
<br>
Tommy<br>
<br>
Tommy Schlotterer | Systems Engineer<br>
Presidio |<span class="m-8103644660611907633apple-converted-space"> </span><a href="http://www.presidio.com/" target="_blank"><span style="color:purple">www.presidio.com</span></a><br>
20 N. Saint Clair, 3rd Floor, Toledo, OH 43604<br>
D: <a href="tel:419.214.1415" target="_blank">419.214.1415</a> | C: <a href="tel:419.706.0259" target="_blank">
419.706.0259</a> |<span class="m-8103644660611907633apple-converted-space"> </span><a href="mailto:tschlotterer@presidio.com" target="_blank"><span style="color:purple">tschlotterer@presidio.com</span></a><br>
<br>
-----Original Message-----<br>
From: cisco-voip [<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank"><span style="color:purple">mailto:cisco-voip-bounces@puck.nether.net</span></a>] On Behalf<br>
Of Pawlowski, Adam<br>
Sent: Wednesday, November 02, 2016 2:23 PM<br>
To:<span class="m-8103644660611907633apple-converted-space"> </span><a href="mailto:cisco-voip@puck.nether.net" target="_blank"><span style="color:purple">cisco-voip@puck.nether.net</span></a><br>
Subject: [cisco-voip] Traffic Issues with 7900 Series Phones<br>
<br>
After much hair pulling and frustration, I wanted to ask the group<br>
here in case anyone has seen this or has any thought on what we should<br>
be looking for.<br>
<br>
We have a number of 7900 series phones that have been exhibiting<br>
issues that appear to me to be that the phone is getting hung up on<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">something.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Some sort of frame or packet is screwing with the network chip/board<br>
or the OS which is causing it trouble. I see missed traffic, missed<br>
responses, high ICMP echo times - and phones that eventually get stuck<br>
with their ICMP echo response times being all over the board - with<br>
some report of call trouble and CMR showing crazy jitter. If I power<br>
cycle the phone that clears and it works fine for a while.<br>
<br>
I realize these items are pretty much end of useful life, pretty much<br>
all done with software support, and are going to drop off of the<br>
compatibility matrix and probably functional support in the near<br>
future. But, while we still have a ton of them - has anyone noted any<br>
particular type of traffic that causes the 7900 series phones grief?<br>
<br>
I don't have loss on the network, there do not seem to be any<br>
transient broadcast storms rolling by. We do see an increased amount<br>
of mDNS, IPv6 (phones are v4 only) etc, but nothing stands out as<br>
causing a particular problem. It just seems that whatever this is, is<br>
causing a memory leak or something, wherein it gets bad enough that<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">things go to hell eventually.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
Any thoughts?<br>
<br>
Adam P<br>
SUNYAB<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank"><span style="color:purple">cisco-voip@puck.nether.net</span></a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank"><span style="color:purple">https://puck.nether.net/mailman/listinfo/cisco-voip</span></a><br>
<br>
<br>
This message w/attachments (message) is intended solely for the use of<br>
the intended recipient(s) and may contain information that is<br>
privileged, confidential or proprietary. If you are not an intended<br>
recipient, please notify the sender, and then please delete and<br>
destroy all copies and attachments. Please be advised that any review<br>
or dissemination of, or the taking of any action in reliance on, the<br>
information contained in or attached to this message is prohibited.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank"><span style="color:purple">cisco-voip@puck.nether.net</span></a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank"><span style="color:purple">https://puck.nether.net/mailman/listinfo/cisco-voip</span></a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>