|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: exchange point media
On Mon, 17 Jul 2000, Mikael Abrahamsson wrote: > > On Mon, 17 Jul 2000, Richard A. Steenbergen wrote: > > > A Foundry BigIron doing L3 should, exactly as if it was a router and > > interfaces 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. I'm not sure if there is anyone who is doing L3 only in regards to fragmentation when traversing through a switch with multiple interfaces and disparate MTUs in a modern environment. You'd have to ask the switch vendors, my guess is if its a L3 switch-functionality it could be made to do so at decent levels of performance, but this is still bad. > > 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 OS model you're refering to lets you derive it from the routing entry instead of just the physical interface, so you can specify a different MTU for a different prefix, for whatever reason, even if its on the same physical interface. At this point you're talking a grody poorly managed hack which assumes an aweful lot and probably is going to break a lot of things. > > 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. This could work in a very backwards fashion. Something like both sides starting with an MTU of 1500, but configured to try and reach 9k if possible. During a BGP Peer, Router1 lies and offers up an MSS of 9k in its SYN, and if Router2 accepts and both sides complete a handshake with an agreed upon value, both physical MTUs would be increased. This is a horrible hack, among other things it assumes there must be a TCP based BGP peer in order for the sides to negiotiate > 1500, and that the switch will accept this. I can't imagine it working like this in any production system. > 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. There is no standardization on maximium size of the jumbo frame, or guarentee to support them at all. There is also no guarentee that the ability to go > 1500 will not disappear in 10GigE. > > 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. I would agree with that, but is the IEEE taking that into account or just focusing on traditional desktop server and datacenter networking? One of the most powerful advantages ethernet offers is the ability to be cheaply and easily switched. Personally I'd love to have a cheap effective high density OC48 PoS switch (no flames please). :P -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
|