[cisco-voip] 7900 series and ARP

[Wes Sisk]

A packet capture of all traffic in/out of the phone would help 
significantly with conditions for any lab test or recreate.

/Wes

On Thursday, July 01, 2010 3:47:46 PM, Pawlowski, Adam 
<ajp26 at buffalo.edu> wrote:
> Absolutely. Like several other quirks and bugs, it may turn out that there is a very specific set of circumstances which contributes to this problem, which may likely disappear after a change like a new load, one piece or another rebooting, something else on the network leaving, etc.
>
> Thanks though for the help and I will post if I find anything new.
>
> Adam Pawlowski
> CIT/OSS Repair Services
> University at Buffalo
>
>   
>> -----Original Message-----
>> From: Wes Sisk [mailto:wsisk at cisco.com]
>> Sent: Thursday, July 01, 2010 3:07 PM
>> To: Ryan Ratliff
>> Cc: Pawlowski, Adam; cisco-voip at puck.nether.net
>> Subject: Re: [cisco-voip] 7900 series and ARP
>>
>> And after that it will likely be best to proceed through a formal TAC
>> case.  There isn't a plethora of information available in this area so
>> it will take some dedicated time and communication.
>>
>> /Wes
>>
>> On Thursday, July 01, 2010 2:58:27 PM, Ryan Ratliff
>> <rratliff at cisco.com>
>> wrote:
>>     
>>> Before you do anything you need to upgrade the phone firmware to the
>>>       
>> latest load.
>>     
>>> -Ryan
>>>
>>> On Jul 1, 2010, at 2:06 PM, Pawlowski, Adam wrote:
>>>
>>> The phones are 7961G-GE's and 7941G-GE's. Load is 8.5.3S . I have a
>>>       
>> partial capture, not being mindful of my buffering when I was able to
>> reproduce it, I missed call setup. Basically there is a bunch of
>> broadcast ARP request from the destination phone to the originating
>> phone but it does not reply. I toggled GARP from off to on, which
>> shouldn't have really made a difference, and following is the start of
>> the next call which then it answers the first request and the call
>> begins.
>>     
>>> Except for that one instance I haven't been able to reliably
>>>       
>> reproduce it, only receive reports of the issue, and then I can see on
>> the console log, from the phone, the ERR about not receiving any RTP
>> packets. Of course within the last couple of loads the log just fills
>> up with "CDP-D: holdThrd SendingCmd:proto:1 port:0" leaving us with
>> only a short time window to observe, if the user happens to call in as
>> soon as it happens.
>>     
>>> If there is a theoretical scenario it may be easier to try and
>>>       
>> reproduce it here in a test environment, barraging the phone with some
>> variety of traffic, if need be.
>>     
>>> -----------
>>>
>>> Adam
>>>
>>>
>>>       
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100701/da2ca0bf/attachment.html>