James Carlson wrote:
[EMAIL PROTECTED] writes:
In any event, I don't think MTU is at all ambiguous here. It's the IP
MTU which happens to be equal to the maximum MAC client SDU on
Ethernet. (Well, it needs to be _less_ or equal, but it's almost
always equal.)
Ok, well, it seems a little odd to me that we report an IP thing
amongst a collection of link layer properties. In that case, does
it even belong here? Why not also present the TCP MSS too?
I hope that was meant as hyperbole. I can't tell.
Yes, it was.
...
However, I do think that referring to this value using the network
layer's view of the limit is in keeping with standard administrative
practices and would not be in any way confusing.
This is a very different concept from the ifconfig versus dladm issue,
which is what I think has you hung up here. Ifconfig on BSD platforms
refers to the ifnet ("we'd call it 'if' but C isn't PL/1") structure,
which represents a mix of L2 and L3 concepts, and which is used for
non-IP protocols. The same thing isn't true on Solaris, and ifconfig
has _always_ shown the IP view of the universe, not the link layer
view, and has _always_ been IP-only.
Yes, we've driven far out of our way to confuse users -- by allowing
"ether" as a keyword and printing MAC layer addresses and by using the
same name to refer to the driver and IP instances of a given "link."
...
It'd be nice if ifconfig could report what the maximum settable MTU
might be. That'd probably be pretty helpful. I don't see how that
influences whether dladm should report the datalink layer's maximum
SDU. That's an important property, and remains important even if
you're not using IP (and thus, on Solaris, not using ifconfig)
It just seems odd that the same property, at two different places
in our stack, has the very same value.
Maybe the concept of IP having its own MTU is lost, for surely if
we say the MTU of ethernet is 1500 (exclude headers, etc), should
it not be 1480 for IP by way of the same calculation?
It seems like something should be different but perhaps this is a
lost cause now...
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
