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:
-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.
-optimizing server thruput by reducing per-packet
overhead, and directly mapping data payload
to a memory chunk with no "SAR" buffering
-scope is LAN/MAN