<div dir="ltr">Well, that didn't work... weird, I can get some of them to register (4) and the others don't... it seems random....<div><br></div><div><br></div><div><br></div><div>Jonathan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 27, 2015 at 10:26 AM, Charles Goldsmith <span dir="ltr"><<a href="mailto:wokka@justfamily.org" target="_blank">wokka@justfamily.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It may not just be MTU, we had issues with MSS a few years ago with<br>
IPSEC/GRE tunnels and SSL certs.  it was causing fragmentation and SSL<br>
was complaining.<br>
<br>
ip tcp adjust-mss 1340 resolved it, that had a bit of buffer room<br>
built in, but it worked, and we applied that to all of our tunnel<br>
interfaces that were encrypted.<br>
<br>
Maybe try that, and increase it until it breaks, if it does resolve it?<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Apr 24, 2015 at 3:18 PM, Jonathan Charles <<a href="mailto:jonvoip@gmail.com">jonvoip@gmail.com</a>> wrote:<br>
> Cranked the MTU to 1500, no change, dropped it down to 1100, no change...<br>
> they will not register over the backup link... we have confirmed full<br>
> connectivity over this link...<br>
><br>
><br>
> Jonathan<br>
><br>
> On Fri, Apr 24, 2015 at 11:22 AM, Chris Ward (chrward) <<a href="mailto:chrward@cisco.com">chrward@cisco.com</a>><br>
> wrote:<br>
>><br>
>> VPN registration issues usually point to MTU issues. Or at least packet or<br>
>> fragments due to MTU issues. I suspect there is a different in packet size<br>
>> during the registration of these two devices or capabilities that affects<br>
>> packet size.<br>
>><br>
>><br>
>><br>
>> When the primary link is down, you could run some ping tests while setting<br>
>> the ping size to 1X00 and setting the DF bit as well, this will help you<br>
>> find the max size packet with overhead that can fit over the tunnel.<br>
>> Typically VPN tunnels take at least 80 bytes of overhead, so the largest MTU<br>
>> I would expect you could fit over the tunnel would be 1420.<br>
>><br>
>><br>
>><br>
>> I would try and adjust your tunnel MTU down to 1400 or even 1300 just as a<br>
>> test to see if it helps. (In my demo setups with EZVPN tunnels, I can only<br>
>> use 1350 max) Also, are your VPN endpoints able to fragment packets or clear<br>
>> DF bits so that they can fragment large packets? If you can clear df-bit at<br>
>> the interface, that may help move some of the larger packets through IF they<br>
>> have the DF-bit set.<br>
>><br>
>><br>
>><br>
>> +Chris<br>
>><br>
>> TME - Unity Connection and MediaSense<br>
>><br>
>><br>
>><br>
>> From: cisco-voip [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a>] On Behalf Of<br>
>> Jonathan Charles<br>
>> Sent: Friday, April 24, 2015 11:44 AM<br>
>> To: Charles Goldsmith<br>
>> Cc: <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
>> Subject: Re: [cisco-voip] Cisco 8851 not failing over to backup circuit...<br>
>><br>
>><br>
>><br>
>> MTU was set to 1440, we set it to Auto, no change...<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> Jonathan<br>
>><br>
>><br>
>><br>
>> On Thu, Apr 23, 2015 at 10:13 PM, Charles Goldsmith <<a href="mailto:wokka@justfamily.org">wokka@justfamily.org</a>><br>
>> wrote:<br>
>><br>
>> What's your MTU over the backup VPN?  I've seen odd issues on some<br>
>> networks with different providers and MTU and fragmenting packets<br>
>> always caused issues until the MSS was set.<br>
>><br>
>> I'm not sure why this would affect the 8851's, but we've noticed some<br>
>> other oddities with the 8851's.  For instance, computers with intel<br>
>> nic's behind the phone have issues after we apply config, and we<br>
>> narrowed it down to intel gigabit master slave mode setting on the<br>
>> driver, at least, setting that to slave instead of auto resolves the<br>
>> problem.  Otherwise, you have to reboot the phone a couple of times to<br>
>> get consistent connection through the 8851.  Phones are connected to a<br>
>> 2960 with a basic config, nothing out of the ordinary.<br>
>><br>
>><br>
>> On Thu, Apr 23, 2015 at 6:35 PM, Jonathan Charles <<a href="mailto:jonvoip@gmail.com">jonvoip@gmail.com</a>><br>
>> wrote:<br>
>> > We have CUCM 8.6.2 with Cisco 8851, Cisco 8831 phones at a remote<br>
>> > location;<br>
>> > they are connected over MPLS and a Peplink Balance VPN as a backup.<br>
>> ><br>
>> > When we yank the MPLS, the 8831 registers with CUCM and works fine....<br>
>> > the<br>
>> > 8851s do NOT.<br>
>> ><br>
>> > Any reason the 8851 would act differently?<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > Jonathan<br>
>> ><br>
>><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><br>
>> ><br>
>><br>
>><br>
><br>
><br>
</div></div></blockquote></div><br></div>