[cisco-voip] 7900 series and ARP

[Wes Sisk]

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
>   
>
>  
>

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