On Mon, 17 Jul 2000, Richard A. Steenbergen wrote:
A Foundry BigIron doing L3 should, exactly as if it was a router and not a switch, I believe. At that point there is no real technical distinction between it and a router with lots of ethernet ports however. I'm not aware of any exchanges doing L3...
Well, the device should do no routing in the classical meaning of the word, not on L3 anyway. To do fragmentation it has to be semi-L3-aware though. It also needs an IP adress to send the needtofrag-ICMPs from.
FreeBSD lets you set the MTU based on the route... You could do something like this, enabling a larger MTU for specific targets, I suppose. I'm not aware of anyone who is doing this (or probably anyone who would, especially at L2, without a good reason). This assumes the exchange point has a switch capable of it.
We're talking L3 here (routers). Normally the L3 MTU is derived from the L2 MTU, here we would need to derive it from either static configuration or from the below MSS/MTU mechanism (which I don't think will happen as it has too much of a "hack" in it).
The TCP MSS is negiotated based off the MTU, so yo cannot base the MTU off the MSS, circular logic. I highly doubt you will ever get support for jumbo frames auto-negotiated without first standarding the jumbo-frames.
Yes, it can. Router1 should be able to figure out router2:s MTU from the MSS of its TCP session with router2. Router2 has no problem here since it's MTU is the lowest one anyway. I was under the impression that there is nothing magical about jumbo frames and that there are no interoperational problems with them as long as they're supported at all. Please correct me if I am wrong.
I for one would love to see an intelligent standard realizing that 1500 is a remarkably stupid and limiting number, and enabling us to bring new life to public exchange point peering.
I think any new exchange point technology needs to have an MTU > 1500. -- Mikael Abrahamsson email: swmike@swm.pp.se