So there we are. Want to bet on whether 40 GigE will still have the 1522
byte limit?
Given the growing number of folks who will only buy xGigE equipment
that supports 9000 byte MTUs I'd say the chances are very good that
40GigE will no longer have a 1522 byte limit.
--Michael Dillon
On 6-feb-04, at 11:24, [EMAIL PROTECTED] wrote:
So there we are. Want to bet on whether 40 GigE will still have the
1522
byte limit?
Given the growing number of folks who will only buy xGigE equipment
that supports 9000 byte MTUs
I had that happen one time: when evaluating some gigE switches a
So there we are. Want to bet on whether 40 GigE will still have the 1522
byte limit?
Given the growing number of folks who will only buy xGigE equipment
that supports 9000 byte MTUs I'd say the chances are very good that
40GigE will no longer have a 1522 byte limit.
strange planet you live
Ok, I know that this is getting away from the original thread, but I've
always wondered this...
Why is the MTU on Ethernet 1500 bytes? I have looked through various
docs (eg IEEE Std 802.x) and can find where maxUntaggedFrameSize is
listed as 1518 octets, but there is no mention of why this
From: Warren Kumari [EMAIL PROTECTED]
Date: Thu, 5 Feb 2004 15:04:00 -0500
Sender: [EMAIL PROTECTED]
Ok, I know that this is getting away from the original thread, but I've
always wondered this...
Why is the MTU on Ethernet 1500 bytes? I have looked through various
docs (eg IEEE
Warren Kumari wrote:
Ok, I know that this is getting away from the original thread, but I've
always wondered this...
Why is the MTU on Ethernet 1500 bytes? I have looked through various
docs (eg IEEE Std 802.x) and can find where maxUntaggedFrameSize is
listed as 1518 octets, but there
Kevin Oberman wrote:
So there we are. Want to bet on whether 40 GigE will still have the 1522
byte limit?
What was the last year that automobiles had the fitting for
a crank on the front of the engine? (My recollection is that
it was several years after there was hole through the sheetmetal
As late as 1973 Dodge Power Wagons (WDX style, at least) still
had the aperture and the crankshaft end coupling for a hand crank. Dunno
about any later models.
David Leonard
ShaysNet
On Thu, 5 Feb
M. David Leonard wrote:
As late as 1973 Dodge Power Wagons (WDX style, at least) still
had the aperture and the crankshaft end coupling for a hand
crank. Dunno about any later models.
Kind of my point--I doubt that you could actually crank one
to start it (just guessing
And why 4470 for POS? Did everyone borrow a vendor's FDDI-like default
or is there a technical reason? PPP seems able to use 64k packets (as
can the frame-based version of GFP, incidentally, POS's likely
replacement).
According to this URL
How does a 50Mbyte MTU sound like?
http://www.psc.edu/~mathis/MTU/
~Hani Mustafa
On 3-feb-04, at 11:47, [EMAIL PROTECTED] wrote:
Which (as discussed previously) breaks things like Path MTU Discovery,
traceroute,
If RFC1918 addresses are used only on interfaces with jumbo MTUs
on the order of 9000 bytes then it doesn't break PMTUD in a
1500 byte Ethernet world. And it doesn't
[EMAIL PROTECTED] disait :
Search the archives, Comcast and other cable/DSL providers use the
10/8 for their infrastructure. The Internet itself doesn't need to be
Internet routable. Only the edges need to be routable. It is common
practice to use RFC1918 address space inside the
Which (as discussed previously) breaks things like Path MTU Discovery,
traceroute,
If RFC1918 addresses are used only on interfaces with jumbo MTUs
on the order of 9000 bytes then it doesn't break PMTUD in a
1500 byte Ethernet world. And it doesn't break traceroute.
We just lose the DNS hint
A more important question is what will happen as we move out
of the 1500 byte Ethernet world into the jumbo gigE world. It's
only a matter of time before end users will be running gigE
networks and want to use jumbo MTUs on their Internet links.
The performance gain achieved by using jumbo
A more important question is what will happen as we move out
of the 1500 byte Ethernet world into the jumbo gigE world. It's
only a matter of time before end users will be running gigE
networks and want to use jumbo MTUs on their Internet links.
The performance gain achieved by
bill wrote:
for some, yes. running 1ge is fairly common and 10ge is
maturing. bleeding edge 40ge is available ... and 1500byte
mtu is -not- an option.
Me wonders why people ask for 40 byte packets at linerate if the mtu is
supposedly
larger?
Pete
On Tue, 3 Feb 2004, Terry Baranski wrote:
A more important question is what will happen as we move out
of the 1500 byte Ethernet world into the jumbo gigE world. It's
only a matter of time before end users will be running gigE
networks and want to use jumbo MTUs on their Internet
A more important question is what will happen as we move out
of the 1500 byte Ethernet world into the jumbo gigE world. It's
only a matter of time before end users will be running gigE
networks and want to use jumbo MTUs on their Internet links.
The performance gain achieved by using jumbo
[EMAIL PROTECTED] wrote:
If RFC1918 addresses are used only on interfaces with jumbo MTUs
on the order of 9000 bytes then it doesn't break PMTUD in a
1500 byte Ethernet world. And it doesn't break traceroute.
We just lose the DNS hint about the router location.
I'm confused about your
On Tue, 03 Feb 2004 06:39:33 PST, Joel Jaeggli said:
edge networks that are currently jumbo enabled for the most part do just
fine when talking to the rest of the internet since they can do path mtu
discovery...
Well, until you hit one of these transit providers that uses 1918 addresses
for
In a message written on Tue, Feb 03, 2004 at 08:15:13AM -0600, Terry Baranski wrote:
The performance gain achieved by using jumbo frames outside of very
specific LAN scenarios is highly questionable, and they're still not
standardized. Are jumbo Internet MTUs seen as a pressing issue by
ISPs
* [EMAIL PROTECTED] (Petri Helenius) [Tue 03 Feb 2004, 15:42 CET]:
Me wonders why people ask for 40 byte packets at linerate if the mtu
is supposedly larger?
Support for the worst-case scenario. Same why you spec support for
a BIGINT-line ACL without excessive impact on forwarding capacity.
Niels Bakker wrote:
* [EMAIL PROTECTED] (Petri Helenius) [Tue 03 Feb 2004, 15:42 CET]:
Me wonders why people ask for 40 byte packets at linerate if the mtu
is supposedly larger?
Support for the worst-case scenario. Same why you spec support for
a BIGINT-line ACL without excessive impact
Leo Bicknell wrote:
because at the higher data rates (eg 40 gige) it makes a huge difference
in host usage. You can fit 6 times in the data in a 9K packet that
you can in a 1500 byte packet, which means 1/6th the interrupts, DMA
transfers, ACL checks, etc, etc, etc.
This is wrong. Interrupt
In a message written on Tue, Feb 03, 2004 at 08:40:22PM +0200, Petri Helenius wrote:
If you're paying for 40 byte packets anyway, there is no incentive to
ever go beyond 1500
With a 20 byte IP header:
A 40 byte packet is 50% data.
A 1500 byte packet is 98.7% data.
A 9000 byte packet is
Why large MTU then? Most modern ethernet controllers don´t care if you´re
sending 1500 or 9000 byte packets. (with proper drivers taking advantage of
the features there) If you´re paying for 40 byte packets anyway, there is no
incentive to ever go beyond 1500 byte MTU.
I think its partially
Leo Bicknell wrote:
because at the higher data rates (eg 40 gige) it makes a huge difference
in host usage. You can fit 6 times in the data in a 9K packet that you
can in a 1500 byte packet, which means 1/6th the interrupts, DMA
transfers, ACL checks, etc, etc, etc.
* [EMAIL PROTECTED]
Stephen J. Wilcox wrote:
Why large MTU then? Most modern ethernet controllers don´t care if you´re
sending 1500 or 9000 byte packets. (with proper drivers taking advantage of
the features there) If you´re paying for 40 byte packets anyway, there is no
incentive to ever go beyond 1500 byte MTU.
Niels Bakker wrote:
Just like the extra chopping up of the data you want to send into more
packets, it's things you have to do a few extra times. That takes time.
There is no way around this. What Leo wrote is in no way wrong.
Maybe we need to define what the expression huge difference
In a message written on Tue, Feb 03, 2004 at 09:53:30PM +0200, Petri Helenius wrote:
Sure, if you control both endpoints. If you don´t and receivers have
small (4k,8k or 16k) window
sizes, your performance will suffer.
Maybe we should define if we´re talking about record breaking attempts
On Tue, 3 Feb 2004, Petri Helenius wrote:
Stephen J. Wilcox wrote:
Why large MTU then? Most modern ethernet controllers don´t care if you´re
sending 1500 or 9000 byte packets. (with proper drivers taking advantage of
the features there) If you´re paying for 40 byte packets anyway, there is
Leo Bicknell wrote:
Google and Akamai are just two examples of companies with hundreds
of thousands of machines where they move large amounts of data
between them and have control of both ends. Many corporations are
now moving off-site backup data over the Internet, in large volumes
between two
Leo Bicknell wrote:
Since most POS is 4470, adding a jumbo frame GigE edge makes
this application work much more efficiently, even if it doesn't
enable jumbo (9k) frames end to end. The interesting thing
here is it means there absolutely is a PMTU issue, a 9K edge
with a 4470 core.
This
From: Terry Baranski [EMAIL PROTECTED]
Date: Tue, 3 Feb 2004 16:42:55 -0600
Sender: [EMAIL PROTECTED]
Leo Bicknell wrote:
Since most POS is 4470, adding a jumbo frame GigE edge makes
this application work much more efficiently, even if it doesn't
enable jumbo (9k) frames end to
On Tue, Feb 03, 2004 at 11:02:16AM -0500, Leo Bicknell wrote:
While the rate of request is still very low, I would say we get
more and more requests for jumbo frames everyday. The pressing
application today is larger frames; that is don't think two hosts
talking 9000 MTU frames to each
Title: Strange public traceroutes return private RFC1918 addresses
Any ideas how (or why) the following traceroutes are leaking private RFC1918 addresses back to me when I do a traceroute?
Maybe try from your side of the internet and see if you get the same types of responses.
It's really
This is quite often used. You cant (d)DoS the routers this way, nor try
to do any harm to them as you cant reach them.
Regards,
Jonas
On Tue, 2004-02-03 at 00:01, Brian (nanog-list) wrote:
Any ideas how (or why) the following traceroutes are leaking private
RFC1918 addresses back to me when I
Search the archives, Comcast and other cable/DSL providers use the
10/8 for their infrastructure. The Internet itself doesn't need to be
Internet routable. Only the edges need to be routable. It is common
practice to use RFC1918 address space inside the network. Companies
like Sprint and
On Feb 2, 2004, at 6:20 PM, Jonas Frey (Probe Networks) wrote:
This is quite often used. You cant (d)DoS the routers this way, nor try
to do any harm to them as you cant reach them.
Sure you can, easy, attack a router 1 hop past your real target and
spoof your target as the source. The
Matthew Crocker wrote:
Search the archives, Comcast and other cable/DSL providers use the
10/8 for their infrastructure. The Internet itself doesn't need to be
Internet routable. Only the edges need to be routable. It is common
practice to use RFC1918 address space inside the network.
PROTECTED]
Sent: Monday, February 02, 2004 9:25 PM
Subject: Re: Strange public traceroutes return private RFC1918 addresses
Search the archives, Comcast and other cable/DSL providers use the
10/8 for their infrastructure. The Internet itself doesn't need to be
Internet routable. Only
On Tue, 3 Feb 2004, Rubens Kuhl Jr. wrote:
Using real but announced IPs for routers will make their packets fail
unicast-RPF checks, dropping traceroute and PMTUD responses as happens with
RFC1918 addresses.
I guess you meant unannounced.
This is the case for those who run uRPF towards their
43 matches
Mail list logo