RE: jumbo frames

Has anybody been running PMTU-D scans across networks from a
4470-connected host? I would love to see some data.

I have been tracking jumbo frame support trends for a while, and
am reasonably disappointed by lack of standards and vendor willingness
to support jumbos (yes there are very REAL h/w design considerations,
so until operators demand jumbo support and folks test it in realistic
environments, it's not going to happen).

Unfortunately, many of the folks most adamant about maintaining 4470
in their core are therefore sticking with POS everywhere, so their
requirement is not making it to the ether vendors.

There are different reasons to use several different sizing parameters:

  "Mini-jumbo": say 1518, 1540, etc. the idea here is that you
    can handle stacked tunnels and LAN encapsulations, such
    as stacked headers of 802.1Q, MPLS, IP/GRE tunnels, etc.
    while still preserving "1500 for the edge"

    Applicability: 802.1Q, VPN, MPLS, and other encap-based
      or tunnel-based applications

  "Mid-jumbo": say 4470: the idea is to make sure a backbone can
    preserve its MTU across both ethernet, ATM, and POS links
    within its diameter, and conceivably between networks via
    IX's that support jumbos. This in fact may be critical
    for folks running large ISIS implementations that need
    to ration # of LSPs:

http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-02.txt

    Applicability:
      -internal: maintain 4470 for router-router control
        traffic such as ISIS
      -external: allow for customers that use larger MTU,
        preserve MTU across IX peering points

  "Real jumbo": not standardized, but somewhere between 8100-9100B,
    this is for servers that want to pack GigE links with
    optimized I/O based on 8K memory chunks, ala the original
    reasons for Alteon jumbo support. Of course, need for these

    jumbos is probably still within LAN/MAN scope for the next
    generation of operational deployment.

    Applicability:
      -optimizing server thruput by reducing per-packet
        overhead, and directly mapping data payload
        to a memory chunk with no "SAR" buffering
        function.
      -scope is LAN/MAN

Cheers,
-Lane

This is what I find most interesting. If we can just have GE support
basically the same size as POS etc, then it becomes much more useful.

Too bad ciscos 3GE card only supports 2450 MTU. The 1GE supports 9180 and
the PA-GE supports 4470. Oh joy, pick a standard, glad there are so many
to choose from.

It seems more newer L2 GE-switch manufacutrers support jumbo (real jumbo,
up to at least 8192, most of them even higher) than the older router
manufacturers (or is it just cisco?).

Too bad ciscos 3GE card only supports 2450 MTU. The 1GE supports 9180 and
the PA-GE supports 4470. Oh joy, pick a standard, glad there are so many
to choose from.

For those non-oldtimers:
        4470 == FDDI MTU
        9180 == ATM AAL5 IP MTU (RFC-1626)

        Off hand, 2450 sounds like someone forgot to put enough RAM
on the card when doing the board design and that is what they
could actually support when the board appeared. Sigh.

It seems more newer L2 GE-switch manufacutrers support jumbo (real jumbo,
up to at least 8192, most of them even higher) than the older router
manufacturers (or is it just cisco?).

        Mostly cisco has had trouble getting with the Jumbo MTU program,
though occasionally they do something reasonable. Most non-cisco
GigE products are engineered to support the 9180 IP MTU (RFC-1626).

Ran
rja@inet.org

        Mostly cisco has had trouble getting with the Jumbo MTU
program, though occasionally they do something reasonable. Most
non-cisco GigE products are engineered to support the 9180 IP MTU
(RFC-1626).

Foundry being a notable exception, although they intend to support
larger-than-1500-bytes MTUs on upcoming line card designs.