Home page logo
/

nanog logo nanog mailing list archives

RE: PMTU-D: remember, your load balancer is broken
From: rdobbins () netmore net
Date: Wed, 14 Jun 2000 16:56:15 -0700



Nobody expects anyone to change millions of dial-up MTUs; it was just a
response to the original poster's query as to the origin of that figure.

I've been DoSed via fragmentation, so it -can- happen.  Agreed, it's not all
that common.

Thanks much for the info on Cisco 'Giant Frame' support; I know that'll come
in handy!

Server folks will often tell you that they need huge MTUs - and in some
cases, they're correct.  In other cases, it actually ends up hindering
performance, depending upon the application and the entire end-to-end
network topology.

Playing with MTUs is very much like configuring filesystem block-size, or
the application-specific buffering in a big RDBMS like Oracle.  The main
difference is that although one doesn't often see big RDBMS servers used for
other things (allowing the server OS and the applications on it to be
tweaked so as to squeeze out every erg of performance for a single purpose),
networks in general, and carrier networks in particular, are generally used
for all sorts of things.  And besides the potential effect of an altered MTU
size on application performance, one then runs into the question of whether
it's an efficient use of bandwidth overall.

So, I guess it makes sense to have a -thorough- understanding of one's
topology and application characteristics prior to fiddling about with the
MTU size.  I can see that it may well offer the potential of a big win at
the core, but moving towards the edges, I should think the benefits tend to
taper off.  There can't really be a rule of thumb for this sort of thing, of
course; by nature, it's highly situationally dependent.

-----Original Message-----
From: Stephen Sprunk [mailto:ssprunk () cisco com]
Sent: Wednesday, June 14, 2000 3:48 PM
To: rdobbins () netmore net
Cc: North American Noise and Off-topic Gripes
Subject: Re: PMTU-D: remember, your load balancer is broken 


Sez <rdobbins () netmore net>
The 576 value of the MS PPP MTU is merely a default - it can be
changed with a registry hack.

Expecting the tens of millions of novice computer users to set their
systems for a 1500 byte MTU is irrational.  Those who are knowledgeable
enough to do so are generally reducing it due to "speed up your modem"
articles and programs which improve interactive performance at the
expense of throughput.

Forcing excessive fragmentation/defragmentation is an effective DoS.

Effective, but a fairly difficult problem to exploit.

I thought the frame-size limits for Gigabit Ethernet were 64-1518/1522
bytes?  And isn't that the limit on most host IP stacks for Ethernet
media?
Or am I off in left field, here?

IIRC, during development of the GigE spec, several vendors wished to
increase the GigE MTU to ~9000 bytes.  Due to the technical
ramifications of bridging to low-MTU FastE segments, as well as
inter-vendor politics, it didn't make it as part of the GigE spec but
was later published as an optional extension.

There are now several devices on the market that will do Jumbo frames on
GigE.  For instance, the Catalyst 6000 and GSR do:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cmd_r
efr/set_po_r.htm#xtocid661812

I know there are several other vendors who support Jumbo frames as well.

Finally, I would say that on any medium, <100% utilization in and of
itself
isn't grounds for fiddling with the MTU.  There are lots of other
things to
look at, first.

I hear consistent requests from server folks for higher MTUs; they claim
the per-frame CPU hit is significant enough to warrant using Jumbo
frames to increase throughput.  The results clearly show that it helps.

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, HCOE
   :|||:      :|||:       14875 Landmark Blvd #400; Dallas, TX
.:|||||||:..:|||||||:.    Email: ssprunk () cisco com



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault