[cisco-voip] 7900 series and ARP

[Wes Sisk]

Yep:
CSCsc46296    Add the support for commands "show arp" / "clear arp"

/Wes

On Thursday, July 01, 2010 12:51:10 PM, Ryan Ratliff 
<rratliff at cisco.com> wrote:
> And no, you cannot dump the phone's ARP table (unfortunately).  
>
> -Ryan
>
> On Jul 1, 2010, at 11:52 AM, Wes Sisk wrote:
>
> Implementation details are going to be device specific. What model 
> phone are you using?  Do you have a packet capture? /Wes
>
> On Thursday, July 01, 2010 11:38:38 AM, Pawlowski, Adam 
> <ajp26 at buffalo.edu> wrote:
>>
>> Would you have any idea as to the behavior of the device when the 
>> cache is full ? It doesn’t appear that Option 35 is set, so if that 
>> is correct then the timeout would be 40 minutes. Since you can call 
>> numerous endpoints in that timespan I would assume it drops the 
>> oldest non-permanent entry. However, even with this behavior, should 
>>  it not still be able to successfully open the RTP stream, even if it 
>> were delayed in resolving the IP address ? Is there, then, perhaps  a 
>> problem with Gratuitous ARP being enabled, in that it is overflowing 
>> the table and causing a problem ? I logged into the phone via SSH, 
>> but there doesn’t seem to be a way to view the table from the device 
>> to see what it is populated with.
>>
>>  
>>
>> Thank you for your reply,
>>
>>  
>>
>> Adam
>>
>>  
>>
>> *From:* Wes Sisk [mailto:wsisk at cisco.com]
>> *Sent:* Thursday, July 01, 2010 10:58 AM
>> *To:* Pawlowski, Adam
>> *Cc:* cisco-voip at puck.nether.net
>> *Subject:* Re: [cisco-voip] 7900 series and ARP
>>
>>  
>>
>> The phones also have a very limited arp cache, I believe 16 entries.  
>> ARP entries corresponding to next hop for CM servers are permanently 
>> cached.  Recommendation is to avoid deploying phones in such a large 
>> L2 domain.  I believe this is covered in the UC SRND.  There is some 
>> history behind this:
>>
>> CSCdt28640 7960 Intermittant Delayed Dialtone when going off-hook
>>
>> /Wes
>>
>> On Wednesday, June 30, 2010 11:11:18 AM, Pawlowski, Adam 
>> <ajp26 at buffalo.edu> <mailto:ajp26 at buffalo.edu> wrote:
>>
>> Folks,
>>
>>  
>>
>>     I’ve seen some commentary about certain versions of Call  Manager 
>> not being suitable to sit directly on a subnet with a large number of 
>> endpoints due to a limited capacity of the ARP table, but, nothing 
>> similar from the VoIP telephones themselves.
>>
>>  
>>
>>      I have a large subnet of VoIP devices, a /19 with over 1500 
>> phones active at this time. Within this subnet, and, specifically, 
>> within a “building”, subset of network gear, there are specific 
>> telephones which are not able to complete a call to another telephone 
>> on that subnet, within the “building”. Each of these devices is 
>> direct attached to a Cat 3750G placing the voice traffic on the sub 
>> mentioned before.
>>
>>  
>>
>>      What I’ve seen in the one time I was able to isolate the 
>> problem, was the one of the two phones in the conversation would be 
>> continually ARPing for the other device, but, the other device, 
>> despite seeing it, wouldn’t reply, so the RTP stream never 
>> establishes. I toggled the GARP feature from off, to on (although we 
>> have phones elsewhere with it off and/or on) and it began working. 
>> The problem still exists with other, specific, sets, but, the feature 
>> is on and swapping it doesn’t help. Often, a second try at 
>> establishing a call will work.
>>
>>  
>>
>>       I guess what I’m asking is, is there a limit to the ARP table 
>> on the device? Does it even matter, since it attempts to lookup the 
>> MAC of the target phone on each call ? Anyone else had to deal with 
>> this ?
>>
>>  
>>
>>       You’ll see an error in the device’s console log about 0 RTP 
>> packets received, and stream stats will show no traffic sent or 
>> received, but, of course, the phone presents as though the call is 
>> flowing and thus the end users complain.
>>
>>  
>>
>> Thanks for your insights,
>>
>>  
>>
>> Adam Pawlowski
>>
>> University at Buffalo
>>
>>  
>> ------------------------------------------------------------------------
>>
>>
>>   
>>  
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>   
>>
>>  
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

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