<div dir="ltr"><div><div>While you are checking that, you may also want to confirm whether you did not introduce any new device/network at the distribution/access layer that may be causing the trouble. Perhaps its just a coincidence that its happening just when you introduce ethernet upstream links. <br>
<br></div>The network bottleneck may be within the local-network and not related to the upstream provider. A way to check this is to do a top - bottom troubleshooting approach; Connect the new ethernet upstream provider link to just one system and watch the performance, then start connecting your networks by segment while keeping an eye on the network performance.<br>
<br></div>Cheers!<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 20, 2013 at 1:12 PM, Perreau, Luc <span dir="ltr"><<a href="mailto:Luc.Perreau@cwseychelles.com" target="_blank">Luc.Perreau@cwseychelles.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nishal, thanks for this very comprehensive explanation. It makes sense that the issue may not be related to MTU. What we noticed though, is that when we removed flow control on the MUX, it improved for a while.<br>

<br>
I will keep checking for fragmented packets though.<br>
<br>
Mohamed and Johan, I'm still waiting for the upstream to give me their MTU setting anyway.<br>
<br>
Will keep everyone posted about how this turns out.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Luc Perreau<br>
</font></span><div class="im HOEnZb"><br>
<br>
-----Original Message-----<br>
From: <a href="mailto:nishal@controlfreak.co.za">nishal@controlfreak.co.za</a> [mailto:<a href="mailto:nishal@controlfreak.co.za">nishal@controlfreak.co.za</a>] On Behalf Of Nishal Goburdhan<br>
Sent: Friday, September 20, 2013 3:56 PM<br>
To: Perreau, Luc<br>
Cc: <a href="mailto:afnog@afnog.org">afnog@afnog.org</a><br>
Subject: Re: [afnog] MTU Size for transit links for ISPs<br>
<br>
</div><div class="HOEnZb"><div class="h5">On 20 Sep 2013, at 9:11 AM, "Perreau, Luc" <<a href="mailto:Luc.Perreau@cwseychelles.com">Luc.Perreau@cwseychelles.com</a>> wrote:<br>
<br>
> Hi all,<br>
><br>
> We have been working with POS interfaces for a while and with no issues at all. Our MTU size is always set to 4500.<br>
><br>
> However, we have recently installed some Ethernet links with default MTU size of 1500. These are STM1 size links and we found that there is degraded performance on browsing and download, but P2P torrent traffic is not affected.<br>

<br>
luc,<br>
<br>
it's unlikely (though, not impossible) that the change to MTU=1500 on your transit interface is causing your problems.<br>
<br>
although you've had POS interfaces, with MTU set to 1500+ for those interfaces, it's likely that the end hosts that you're communicating with - for example a web/ftp server out on the internet, hosted on a typical ethernet network in a typical data-centre - only supported an MTU of 1500.<br>

people inside your network, on typical ethernet networks where the MTU=1500, would have likewise, have been communicating *through* your high-mtu link, using 1500 sized packets [*]  - because that's the most that they could get across *their* lan  (forget about your high-mtu POS link...)<br>

<br>
practically, the MTU is really the largest unit that can get transferred across the *path* of the communications channel.  not just across one component of it.<br>
for the 4500 mtu to have been practically useful to your network, end systems/users need to know that you had a large mtu available along the entire path.<br>
so, unless you had that 4500 MTU (or something else reasonably large) available all the way down to end-systems, it's unlikely that the change you mention would affect performance.<br>
<br>
with MTU, you actually care about the *smallest* MTU along a path;  that's the most significantly limiting part of the equation...<br>
<br>
<br>
> What is the best way forward to confirm that it is an MTU issue, and if so, what is the best MTU size to set? Jumbo (9000) or mutually agreed size with the transit provider?<br>
<br>
<br>
you can generally find the mtu along your transmission path, by sending packets of variable sizes using the "ping -s" option.<br>
you've should tell the devices in between not to fragment your packet;  so set your -D option as well.<br>
here's a quick example:<br>
[katala:~] # ping -g 1440 -h 10 -G 1510 -D 196.36.80.177 PING 196.36.80.177 (196.36.80.177): (1440 ... 1510) data bytes<br>
1448 bytes from <a href="http://196.36.80.177" target="_blank">196.36.80.177</a>: icmp_seq=0 ttl=255 time=3.740 ms<br>
1458 bytes from <a href="http://196.36.80.177" target="_blank">196.36.80.177</a>: icmp_seq=1 ttl=255 time=2.267 ms<br>
1468 bytes from <a href="http://196.36.80.177" target="_blank">196.36.80.177</a>: icmp_seq=2 ttl=255 time=2.367 ms<br>
1478 bytes from <a href="http://196.36.80.177" target="_blank">196.36.80.177</a>: icmp_seq=3 ttl=255 time=4.783 ms<br>
ping: sendto: Message too long<br>
ping: sendto: Message too long<br>
Request timeout for icmp_seq 4<br>
ping: sendto: Message too long<br>
Request timeout for icmp_seq 5<br>
ping: sendto: Message too long<br>
Request timeout for icmp_seq 6<br>
--- 196.36.80.177 ping statistics ---<br>
8 packets transmitted, 4 packets received, 50.0% packet loss round-trip min/avg/max/stddev = 2.267/3.289/4.783/1.040 ms [katala:~] #<br>
<br>
...so you can guess that the MTU between my test host, and the remote IP lies somewhere between 1478 and 1488.<br>
you can read more on this process here:  <a href="http://en.wikipedia.org/wiki/Path_MTU_Discovery" target="_blank">http://en.wikipedia.org/wiki/Path_MTU_Discovery</a><br>
<br>
in practice, you want the MTU across your backbone links to *not* be smaller to your users than what is available to them across their last mile.  so, for example, if your users are on ethernet networks, where MTU=1500, then the MTU inside your core, should not be less than 1500.  if it is, then user data starts to get fragmented, and that causes issues...<br>

also, if you're running other interesting things inside your core, like vlans, mpls, etc. you'd *definitely* need higher than MTU=1500.<br>
<br>
there's no "magic number" per se, other than, try your best to avoid fragmentation, because that will hurt your network.<br>
so, look at your router interfaces carefully, and if you can, through tools like netflow, to see if you have lots of fragments.<br>
if you do, that's a place to start to examine your infrastructure.<br>
<br>
--n.<br>
<br>
* simplification.   let's ignore overhead, etc. for now.<br>
<br>
_______________________________________________<br>
afnog mailing list<br>
<a href="http://afnog.org/mailman/listinfo/afnog" target="_blank">http://afnog.org/mailman/listinfo/afnog</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>------------------------------------------------------------------------<br><font color="#888888"><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;font-family:garamond,serif">

<i><span style="color:rgb(0,102,0)">Seun Ojedeji,<br style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">Federal University Oye-Ekiti<br style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">web:      </span><a href="http://www.fuoye.edu.ng" target="_blank">http://www.fuoye.edu.ng</a><br>

<span style="color:rgb(0,102,0)"></span><span style="color:rgb(0,102,0)">Mobile: <a value="+2348035233535">+2348035233535</a></span><span style="color:rgb(0,102,0)"></span><br></i><i><span style="color:rgb(0,102,0)">alt email:<a href="http://goog_1872880453" target="_blank"> </a><a href="mailto:seun.ojedeji@fuoye.edu.ng" target="_blank">seun.ojedeji@fuoye.edu.ng</a></span></i><br>
</blockquote></font><br>
</div>