[cisco-voip] 7900 series and ARP

[Ryan Ratliff]

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> 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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>   
>  

_______________________________________________
cisco-voip mailing list
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/51af3497/attachment.html>