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