From: paul cosgrove (paul.cosgrove@gmail.com)
Date: Wed Jan 14 2009 - 14:07:19 ARST
If end hosts send very large frames, both the endpoint NICs and the network
equipment between them should support those large frames. When performing
large file transfers on reliable links, sending larger chunks can improve
performance as you say. You should be careful though to ensure that the
packet the host is sending, plus any required overhead (e.g. MPLS tags), is
supported throughout your network.
Keep in mind though that if one of the intermediate (transit) IP network
devices has a lower configured MTU, then your large packets will be forcing
that device to perform fragmentation - which will increase its CPU. This
can cause real problems. Path MTU Discovery running on the end hosts helps
them determine the maximum end to end MTU supported across transit IP links,
which helps to avoid this problem (unless administrators block the ICMP type
is needs as is often the case). If your Layer 2 transit interfaces do not
support the required MTU then you are not so lucky, as your large frames
will be silently dropped.
Depending on how your network gets the packets between the two endpoints, it
may need to temporarily increase the size of those packets. If you are
tunneling, you add a tunnel header which increases the size of the frames.
If the MTU used on your transit network does not allow for this additional
overhead, then you may again cause IP fragmentation (or frame drops). So
it is common for a S.P. network to have larger configured interface MTUs
internally than those configured on customer device interfaces.
Transit devices do not bundle together smaller packets to make Giants. To
do so would be too heavy on processor and buffer resources when there could
potentially be many different flows on the same link. You would also be
introducing additional delay to all the bundled packets, and increasing the
risk of their being dropped further on, without much real benefit. Doesn't
happen yet as far as I know (but that approach may have benefits for
tunneling protocols).
On Switches, Gig ports commonly support MTUs of around 9000 bytes, with fast
ethernet ports supporting 1546. You will find that these vary a little
between vendors and in some IOS versions; for instance I think the Jumbo MTU
of 3750 SEB4 was higher than other releases. Packets less than 1560 are
referred to as Baby Giants (according to cisco docs - though I'm not sure if
that figure also varies between vendors). Larger packets are Giants.
Paul.
On Wed, Jan 14, 2009 at 2:57 PM, operator sid <ccie1@live.co.uk> wrote:
> so does that mean that Jumbo frames are generated by the PC Network adapter
> and jumbo frames must be enabled end to end through the network for them to
> work.
>
> Also can jumbo frames be used to consolidate smaller frames into bigger
> jumbo
> frames at the distribution/core for transport ??
>
> ive read a few documents but still not clear on this. can someone please
> explain...
>
> > Date: Wed, 14 Jan 2009 15:08:15 +0100> From: pitt2k@gmail.com> To:
> ccielab@groupstudy.com> Subject: Re: Please explain Jumbo Frames> >
> (...)While
> it may seem that setting the MTU for a network adapter is> sufficient to
> use
> jumbo frames (assuming the operating system supports> it), the reality is a
> lot more complex.> In a controlled network environment, purchasing
> equipment
> with> identical jumbo frame support may allow the use of large frames.>
> However, such equipment is typically much more expensive than>
> standard-only
> equipment(..)> > http://www.asicdesigners.com/jumbo_enet_frames.html> >
> HTH,>
> Piotr> > 2009/1/14 operator sid <ccie1@live.co.uk>:> > Hi,> >> > can
> someone
> please explain how and where jumbo frames are generated. I know> > that
> jumbo
> frames help increase throughput on gig links, but where and how are> >
> these
> jumbo frames created. Surely there is no point in enabling jumbo frames> >
> on
> ports, when there are no jumbo frames traversing the network in the first>
> >
> place.> >> > For example if an application is sending data across the
> network,
> does the> > application have to generate jumbo frames, or can smaller
> frames
> be> > consolidated into jumbo frames on the distribution and core switches
> and
> then> > broken down into the small frames down at the access.. If so how do
> you> > configure this.> >> > Please can someone clearify..> >> > Thanks in
> advance> >> >> >
> _________________________________________________________________> >
> Imagine a
> life without walls. See the possibilities> >
> http://clk.atdmt.com/UKM/go/122465943/direct/01/> >> >> > Blogs and
> organic
> groups at http://www.ccie.net> >> >
> _______________________________________________________________________> >
> Subscription information may be found at:> >
> http://www.groupstudy.com/list/CCIELab.html> > > Blogs and organic groups
> at
> http://www.ccie.net> >
> _______________________________________________________________________>
> Subscription information may be found at: >
> http://www.groupstudy.com/list/CCIELab.html> > > > > > >
> _________________________________________________________________
> Imagine a life without walls. See the possibilities
> http://clk.atdmt.com/UKM/go/122465943/direct/01/
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:37 ARST