3Com Vortex/Boomerang 10/100 Mb/s claims to support
FIDDI size packets 4.5K.
Texas Instruments ThunderLAN 10/100Mbps PCI Network Controller can support
65536 bytes.
Details http://www.scyld.com/expert/100mbps.html
Any one has experience with TI chipset ?
for those who interested in IPv6, Path MTU Discovery is not in IPv6 stack.
To have end to end jumbo frames in native v6 we NAPs in the path
should support jumbo frames.
-antony
Mikael Abrahamsson wrote:
> If NAPs do not support jumbos, then end systems will never support them.Many end systems will never support jumbo frames, period. There are
lots of 10/100 Mb/s ethernet hosts that will not ever be upgraded.
While not a standard feature, many 100mbit nics support jumbo on
full-duplex links and some 100tx switches do as well.
Certainly. In a nutshell, it might be best to take steps to avoid
fragmentation elsewhere in the network. Perhaps a rule of thumb that
should be stressed is to use jumbo frames if you know for sure the other
end system(s) support it, otherwise default to 1500.
Path MTU discovery works fine. (except for broken firewalls) Your
complaint about end systems never supporting jumbos is a moot point
because if neither end supports them, then PMTU discovery isn't even an
issue.
Folks sending anything larger than IEEE standard frame sizes
on any Ethernet need to be sure to re-configure all the equipment
accordingly and test the whole subnet out thoroughly. For now,
there seems to be no substitute for that (and yes, it is
a fair bit of work). As near as I can tell, all switches ship
with IEEE-standard MTU as the default, so require manual operator
reconfiguration to support any larger frame size.
Ran
rja@inet.org
More precisely, with IPv6 networks, either:
(1) Path MTU Discovery is ALWAYS enabled and cannot be disabled
XOR
(2) the sending system never sends an IP packet
larger than 1280 bytes.
[Source: RFC-2460, Section 5, Page 24]
Ran
rja@inet.org
3Com Vortex/Boomerang 10/100 Mb/s claims to support
FIDDI size packets 4.5K.
They do.
for those who interested in IPv6, Path MTU Discovery is not in IPv6 stack.
To have end to end jumbo frames in native v6 we NAPs in the path
should support jumbo frames.
What? That is incorrect! Any IPv6 host which can sent over the minimum MTU
*MUST* support Path MTU Discovery. It can get away without it if it always
uses the minimum MTU, which it will tell the other end about directly,
thus no issue.
>for those who interested in IPv6, Path MTU Discovery is not
>in IPv6 stack. To have end to end jumbo frames in native v6
>we NAPs in the path should support jumbo frames.More precisely, with IPv6 networks, either:
Sorry. I ment to say routers don't perform fragmentation of packets they're
forwarding. If a packet is to be forwarded onto a link whose
link MTU is less than the size of the packet, the node
must discard the packet and send an ICMP Packet Too Big message to
the packet's Source Address. ICMP error message also contains
MTU of the link. Host can retransmit with size obtained from the ICMP message.
To have jumbo frames in IPv6 from end to end and path is via NAP,
NAPs should support it. Or am I still mistaken ?
[Source: RFC-2460, Section 5, Page 24]
Same RFC section 4.4 and 4.5
-antony
Currently, it is an Ethernet NAP, similar to PAIX.
If you like PAIX and want to be in Miami, it seems simplest to just use
the PAIX Miami switch-fabric i the Switch & Data facility...
http://www.switchanddata.com/locations/pdf/miami_site_specs.pdf
Then once NOTA comes online, you can just buy a VLAN over to there, or
peer with whichever NOTA folks connect to the PAIX switch-fabric there,
assuming it goes in.
I think this is the same situation as in the San Francisco area, where the
PAIX switch-fabric appears in Palo Alto, San Francisco, and down at
MAE-West/AMES.
-Bill