[afnog] MTU Size for transit links for ISPs

[Mark Tinka]

On Sunday, September 22, 2013 01:02:35 AM Randy Bush wrote:

> if we assume s/peering/external/.

Yes, by peering I mean eBGP sessions (be they toward 
upstreams, peers or customers).

> and for most networks,
> is not the vast majority of the traffic external.  thus,
> will the above advice not cause your border routers to
> have to fragment all outbound traffic?

MTU size in the core doesn't positively influence external-
to-external traffic, only negatively, i.e., customers-to-
Internet, Internet-to-customers. The customers' or 
destination online resource MTU notwithstanding, typical MTU 
values for customer-to-provider links tend to be the same as 
provider-to-upsteam/peering links, i.e., 1,500 bytes.

We like to set customer-facing ports to 9,178 bytes (a value 
that can be standardized across the various Cisco and 
Juniper line cards). This really doesn't help off-net 
traffic (i.e., traffic heading to upstreams and peers), as 
upstreams and peers generally run at 1,500 bytes. It may 
help other customers on the same network whom we'll also run 
at Jumbo frames, but that setting is only on our side. The 
customer would still not only have to configure their router 
to support Jumbo frames, but also be able to generate them 
from (and accept them on) their computing devices.

> it might be good to negotiate higher mtus with external
> links.

Tend to agree with you. But just as much as the industry has 
failed to standardize on Jumbo frames, the majority of 
providers we've spoken to about negotiating Jumbo frames 
across an IP Transit interconnect have been reluctant to do 
so.

Downstream, demand for Jumbo frames comes from customers 
looking to hand-off private traffic, i.e., l2vpn's, l3vpn's, 
walled-garden stuff like Multicast, e.t.c., which works 
because this is all on-net for us, and as such, under our 
control. As soon as it leaves our routing domain, 
particularly toward the Internet, it becomes like everything 
else on the web - best effort.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20130922/b8bd7df7/attachment.sig>