Internet Exchanges supporting jumbo frames?

Martin Pels m.pels at
Thu Mar 10 14:15:55 UTC 2016

On Thu, 10 Mar 2016 08:23:30 +0200
Tassos Chatzithomaoglou <achatz at> wrote:

> Niels Bakker wrote on 10/3/16 02:44:
> > * nanog at (Kurt Kraut via NANOG) [Thu 10 Mar 2016, 00:59
> > CET]:
> >> I'm pretty confident there is no need for a specific MTU consensus
> >> and not all IXP participants are obligated to raise their
> >> interface MTU if the IXP starts allowing jumbo frames.
> >
> > You're wrong here.  The IXP switch platform cannot send ICMP Packet
> > Too Big messages.  That's why everybody must agree on one MTU.
> >
> >
> Isn't that the case for IXP's current/default MTU?
> If an IXP currently uses 1500, what effect will it have to its
> customers if it's increased to 9200 but not announced to them?

None. Until someone actually tries to make use of the higher MTU. Then
things start breaking.

Let's say I'm a customer at this IXP. I have 100 peers. I have one peer
that likes large MTUs, so I set my L3 MTU to 9000 (or whatever I agree
with this peer). Now I have broken connectivity towards my 99 other
peers who are all still at 1500.

So today you need a separate VLAN for Jumbo's, which some IXPs have. On
this VLAN you will only find the peers that actually care about
Jumboframes. The majority of IXP participants don't bother to connect
to this VLAN for varying reasons. If the number of interested parties
is too low, IXPs may well decide it is not worth the investment of time
and resources to set this up, implement monitoring for it, deal with
customers messing up their configs, etc.

In order for Jumboframes to be successful on IXPs _on a large scale_
the technology has to change. There needs to be a mechanism to negotiate
MTU for each L2 neighbor individually. Something like
draft-van-beijnum-multi-mtu-03, which was mentioned before in this
thread. With this in place individual sets of peers could safely use
different MTUs on the same VLAN, and IXPs would have a migration path
towards supporting larger framesizes.


Kind regards,

Martin Pels
Network Engineer
LeaseWeb Technologies B.V.

T: +31 20 316 0232
E: m.pels at

Luttenbergweg 8, 1101 EC Amsterdam, Netherlands

More information about the NANOG mailing list