<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 11, 2017 at 4:10 AM, Ryan Huff <span dir="ltr"><<a href="mailto:ryanhuff@outlook.com" target="_blank">ryanhuff@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div dir="auto">
<div><span></span></div>
<div><div><div><div><br>
</div>
<div>- 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.</div>
<div><br></div></div></div></div></div></blockquote><div><br></div><div><br></div><div>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?</div><div><br></div><div>Mike</div></div></div></div>