Hey Mike, That actually came from an experience I had. I can actually show you a PCAP of where it happened. It was a DoD customer so I’d have to sanitize/renumber all the IPs first. In my case; I did not have access to the far end (and obviously couldn’t pull pcaps on the subscriber CLI because it would not fully install); so I wasn’t able to positively identify the MTU issue without samples from both sides.
On the publisher, shortly after the TCP retransmission started (in the packet capture timeline), I started to see fragmentation where fragmentation was not expected. I’m no packet/route/switch expert but I only knew of a few things (outside of a bad uplink cable) that would cause this so I took an educated guess and forwarded the pcap to the customer’s network group. They were able to fully diagnose and confirmed the mismatched MTU. In this customer’s case, they had no need for the non-standard MTU, it was just a legacy config that no one changed “cause it never caused a problem before”. -Ryan On Oct 12, 2017, at 1:48 PM, Mike King <m...@mpking.com<mailto:m...@mpking.com>> wrote: On Wed, Oct 11, 2017 at 4:10 AM, Ryan Huff <ryanh...@outlook.com<mailto:ryanh...@outlook.com>> wrote: - Make sure you’re accounting for any non-standard MTU between the publisher and subscriber nodes. By default, CUCM will use 1500 if you don’t change it (which is the typical network standard). For example; If you have jumbo frame support in the network path between the two nodes and you set 1500 MTU on the publisher and subscriber, the subscriber installation will typically “fail node connectivity validation” with no visible clue as to why. This is because this is the first point in the subscriber installation where there is enough back/fourth TCP with the publisher to cause the TCP window to burst, which causes the TCP retransmission error. Since it happens at this point, CUCM assumes it’s because the publisher can’t verify the subscriber. Hey Ryan, Do you have links for that? I find the behavior very odd, and not the way I understood standard MTU over a Jumbo enabled network to function. Or is this just a Cisco Caveat type deal? Mike _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
