Jumbo-to-Regular frame bridge

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hello!

Our newer computers tend to come with NICs, that can handle big frame sizes
(at least 8 or 9 K, some even 15). We also have one 24-port switch, that
can handle 15K frames. But many desktops and the older servers can't handle
the frames above the 1500 bytes, of course, so the entire network is still
limited to the small frame size.

We could setup a small PC running something like FreeBSD to transparently
fragment packets from one interface to another, but I'm wondering, if such
devices are already available out there... Thanks!

-mi
8 answers Last reply
More about jumbo regular frame bridge
  1. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <15198068.kmfYAppCL7@Misha>,
    Mikhail Teterin <usenet@aldan.algebra.com> wrote:
    :Our newer computers tend to come with NICs, that can handle big frame sizes
    :(at least 8 or 9 K, some even 15). We also have one 24-port switch, that
    :can handle 15K frames. But many desktops and the older servers can't handle
    :the frames above the 1500 bytes, of course, so the entire network is still
    :limited to the small frame size.

    I thought this was the kind of situation that MTU path negotiation
    was invented for?
    --
    Strange but true: there are entire WWW pages devoted to listing
    programs designed to obfuscate HTML.
  2. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Mikhail Teterin <usenet@aldan.algebra.com> wrote:
    > Hello!

    > Our newer computers tend to come with NICs, that can handle big frame sizes
    > (at least 8 or 9 K, some even 15). We also have one 24-port switch, that
    > can handle 15K frames. But many desktops and the older servers can't handle
    > the frames above the 1500 bytes, of course, so the entire network is still
    > limited to the small frame size.

    > We could setup a small PC running something like FreeBSD to transparently
    > fragment packets from one interface to another, but I'm wondering, if such
    > devices are already available out there... Thanks!

    any router will do. Fragmenting is part of ipv4


    Have you done any measurment if you gain anything with jumbo frames ?

    > -mi

    --
    Peter Håkanson
    IPSec Sverige ( At Gothenburg Riverside )
    Sorry about my e-mail address, but i'm trying to keep spam out,
    remove "icke-reklam" if you feel for mailing me. Thanx.
  3. Archived from groups: comp.dcom.lans.ethernet (More info?)

    phn@icke-reklam.ipsec.nu wrote in <cgnnac$2poh$1@nyheter.ipsec.se>:

    > Mikhail Teterin <usenet@aldan.algebra.com> wrote:
    >> Hello!
    >
    >> Our newer computers tend to come with NICs, that can handle big frame
    >> sizes (at least 8 or 9 K, some even 15). We also have one 24-port switch,
    >> that can handle 15K frames. But many desktops and the older servers can't
    >> handle the frames above the 1500 bytes, of course, so the entire network
    >> is still limited to the small frame size.

    >> We could setup a small PC running something like FreeBSD to transparently
    >> fragment packets from one interface to another, but I'm wondering, if
    >> such devices are already available out there... Thanks!

    > any router will do. Fragmenting is part of ipv4

    That's the problem -- we don't want to split the network into subnets. Can't
    we stay one layer below routers -- a fragmenting bridge (pardon my clumsy
    terminology) of some sort, perhaps?

    > Have you done any measurment if you gain anything with jumbo frames ?

    No extensive studies to justify splitting into sub-networks. Only
    observations, that our app-server talk to the db-servers a LOT.

    Yours,

    -mi
  4. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Mikhail Teterin <usenet@aldan.algebra.com> wrote:
    > phn@icke-reklam.ipsec.nu wrote in <cgnnac$2poh$1@nyheter.ipsec.se>:

    >> Mikhail Teterin <usenet@aldan.algebra.com> wrote:
    >>> Hello!
    >>
    >>> Our newer computers tend to come with NICs, that can handle big frame
    >>> sizes (at least 8 or 9 K, some even 15). We also have one 24-port switch,
    >>> that can handle 15K frames. But many desktops and the older servers can't
    >>> handle the frames above the 1500 bytes, of course, so the entire network
    >>> is still limited to the small frame size.

    >>> We could setup a small PC running something like FreeBSD to transparently
    >>> fragment packets from one interface to another, but I'm wondering, if
    >>> such devices are already available out there... Thanks!

    >> any router will do. Fragmenting is part of ipv4

    > That's the problem -- we don't want to split the network into subnets. Can't
    > we stay one layer below routers -- a fragmenting bridge (pardon my clumsy
    > terminology) of some sort, perhaps?

    What's wrong with routing and deterministic network ?

    >> Have you done any measurment if you gain anything with jumbo frames ?

    > No extensive studies to justify splitting into sub-networks. Only
    > observations, that our app-server talk to the db-servers a LOT.

    I mean, have you done any measurment if jumbo-frames will give you
    anything but trouble ?

    For instance, if the majority part of your packets are < 1500 bytes
    then enabling jumbos won't give much of a boost.

    Don't use "features" just becouse some vendor says so. Use the
    features that will give your application(s) a boost AND that
    don't lock you into [vendor-dependence | scalability issues | maintanace
    trouble ]


    > Yours,

    > -mi

    --
    Peter Håkanson
    IPSec Sverige ( At Gothenburg Riverside )
    Sorry about my e-mail address, but i'm trying to keep spam out,
    remove "icke-reklam" if you feel for mailing me. Thanx.
  5. Archived from groups: comp.dcom.lans.ethernet (More info?)

    phn@icke-reklam.ipsec.nu wrote in <ch59fq$2v5h$4@nyheter.ipsec.se>:

    >> That's the problem -- we don't want to split the network into subnets.
    >> Can't we stay one layer below routers -- a fragmenting bridge (pardon my
    >> clumsy terminology) of some sort, perhaps?
    >
    > What's wrong with routing and deterministic network ?

    It is a _change_ and this requires _work_ -- such as configuring routers,
    modifying network settings on servers and DHCP-settings for clients.

    >>> Have you done any measurment if you gain anything with jumbo frames ?
    >
    >> No extensive studies to justify splitting into sub-networks. Only
    >> observations, that our app-server talk to the db-servers a LOT.
    >
    > I mean, have you done any measurment if jumbo-frames will give you
    > anything but trouble?

    I know, what you were asking, and I answered: NO, we HAVE NOT.

    Now, are you aware of a bridge-type device, I'm asking about?

    > For instance, if the majority part of your packets are < 1500 bytes
    > then enabling jumbos won't give much of a boost.

    I know, but conducting such study requires work, and work is expensive,
    compared to the device, I hope exists. So we go with "guestimates": our
    many applications use packet sizes of 4K to talk to Sybase servers. I
    think, it is a good guess, that making the entire packet fit into a single
    Ethernet frame can help performance. We also dump databases over NFS.

    > Don't use "features" just becouse some vendor says so. Use the
    > features that will give your application(s) a boost AND that
    > don't lock you into [vendor-dependence | scalability issues | maintanace
    > trouble ]

    There is no vendor.

    -mi
  6. Archived from groups: comp.dcom.lans.ethernet (More info?)

    In article <15198068.kmfYAppCL7@Misha>,
    Mikhail Teterin <usenet@aldan.algebra.com> wrote:

    > Hello!
    >
    > Our newer computers tend to come with NICs, that can handle big frame sizes
    > (at least 8 or 9 K, some even 15). We also have one 24-port switch, that
    > can handle 15K frames. But many desktops and the older servers can't handle
    > the frames above the 1500 bytes, of course, so the entire network is still
    > limited to the small frame size.
    >
    > We could setup a small PC running something like FreeBSD to transparently
    > fragment packets from one interface to another, but I'm wondering, if such
    > devices are already available out there... Thanks!
    >
    > -mi

    It is not possible to transparently fragment at the Link Layer. Ethernet
    (and most other LAN technologies) has no mechanism for fragmentation;
    equally important, there would be no means for the receiving end station
    to reassemble the fragments.

    Some network layer protocols (but not all) include
    fragmentation/reassembly capability, but these functions are notoriously
    inefficient. Since the vast majority of packets do *not* require
    fragmentation (one hopes), fragmentation/reassembly are generally
    performed outside the "fast path" of the code; as a result, performance
    suffers *significantly*. In addition, reassembly tends to be memory
    intensive (since buffers must be retained until all fragments of a
    packet have been received and reassembled).

    In any case, fragmentation in practical networks can only be performed
    in an IP-aware intermediate device (a router, or as another poster
    alluded to, a "transparent router," such as were once popular for
    FDDI-to-Ethernet connections). Even so, if the majority of packets are
    going to be exchanged between a jumbo-enabled server and
    non-jumbo-capable end stations (as you imply from your post), it would
    be *much* more efficient to disable the jumbo frame capability on the
    server, and let the packets stay intact throughout their journey. All
    you would be doing is shifting the function from the server to the
    intermediate device; the server can avoid invoking true IP fragmentation
    by simply using the smaller frame size. This is why MTU Discovery was
    developed; to allow end stations to use smaller packets rather than
    force intermediate routers to perform fragmentation.

    Furthermore, using an intermediate router would require that you divide
    your network into subnetworks across the router ports; by definition, a
    router only relays packets between IP subnets. You indicated that this
    was undesirable from an administration/management perspective.

    Bottom line--disable the jumbo frame capability, or use MTU Discovery
    (which will effectively do the same thing, only automatically).

    Patient: "Doctor, it hurts when I do this!"
    Doctor: "Then don't do this."


    --
    Rich Seifert Networks and Communications Consulting
    21885 Bear Creek Way
    (408) 395-5700 Los Gatos, CA 95033
    (408) 395-1966 FAX

    Send replies to: usenet at richseifert dot com
  7. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Long long ago, and far away, there were FDDI to Ethernet bridges (I'm
    starting to feel like Grandpa here :) that "fragmented" IP datagrams
    from the large MTU side (FDDI with a ~4500 byte MTU) to the small MTU
    side (Ethernet).

    However, my recollection (groups.google.com would be a good thing to
    check) is that the devices didn't work all _that_ well. They were
    doing one thing that "belonged" in the network (IP) layer, but did not
    do all the things required of the network layer (such as generate the
    PathMTU Discovery ICMP Datagram Too Big messages...)

    Also, if much of your traffic is TCP, enabling Jumbo on your servers
    isn't going to do much with traffic to the clients - the TCP
    connection establishment will have the servers say some large value,
    the clients the small value and the small value will be used anyway.
    That will also happen with the router.

    You would only get the JF TCP MSSes between two systems with
    JumboFrame enabled.

    That then ties-in with the queries about whether or not you've checked
    that going to JF would buy you anything in the first place. How much
    of your comms would be between JF-capable systems on a JF capable
    switch? If there is not a _lot_ of 1460 byte MSS (1500 byte MTU)
    traffic between those systems, and it is all smaller stuff of a few
    hundred bytes, then JF won't buy you anything except perhaps the
    occasional connectivity problem when the mythical bridge didn't behave
    properly.

    That means taking packet traces and/or generating some statistics from
    the network and/or link-level stats available on your systems.

    The other option is to use "large send" or what Linux 2.6 calls TSO.
    This is something of a "poor man's" JF - the NIC knows just enough
    (but no more) to offload segmentation work from TCP. TCP can then
    pass large sends to the NIC (via IP and the driver of course...) and
    the NIC then segments them into the standard sizes for transmission on
    the medium.

    I say "poor man's" because it only offloads the sending overhead - the
    reciever still gets a stream of 1460 byte TCP segments. You also have
    just as many ACK's with large send as you would have without it where
    JF also cuts the number of ACKs per MB. ACK's don't do much on the
    wire, but they do consume just about as much CPU in the host(s) as any
    other segment (particularly if there is zero-copy in the host.

    rick jones
    --
    Process shall set you free from the need for rational thought.
    these opinions are mine, all mine; HP might not want them anyway... :)
    feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
  8. Archived from groups: comp.dcom.lans.ethernet (More info?)

    Rich Seifert <usenet-@-richseifert-dot-com.invalid> wrote:
    > Bottom line--disable the jumbo frame capability, or use MTU Discovery
    > (which will effectively do the same thing, only automatically).

    Does PathMTU discovery even kick-in when the communicating ends are on
    the same broadcast domain/IP subnet? And if they were in different IP
    subnets, there would already be a router in place and presumeably a
    separation of broadcast domains so no need for that evil, cheating JF
    to regular frame device :).

    rick jones
    --
    Process shall set you free from the need for rational thought.
    these opinions are mine, all mine; HP might not want them anyway... :)
    feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
Ask a new question

Read More

Ethernet Card Networking