Discussion:
"netstat -ranl" and MTU
(too old to reply)
Fredrik Pettai
2012-09-25 13:51:52 UTC
Permalink
Hi,

I see that "netstat -ranl" only show MTU for the lo0 address(es).
Isn't it suppose to show the local ethernet interface MTU as well?

And NetBSD doesn't seem to store the MTU for all the host routes it learned?

Re,
/P
Ignatios Souvatzis
2012-09-25 14:22:15 UTC
Permalink
Post by Fredrik Pettai
Hi,
I see that "netstat -ranl" only show MTU for the lo0 address(es).
Isn't it suppose to show the local ethernet interface MTU as well?
And NetBSD doesn't seem to store the MTU for all the host routes it learned?
It does. I'm seeing one after a test with traceroute -D.

-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Fredrik Pettai
2012-09-25 14:40:07 UTC
Permalink
Post by Ignatios Souvatzis
Post by Fredrik Pettai
Hi,
I see that "netstat -ranl" only show MTU for the lo0 address(es).
Isn't it suppose to show the local ethernet interface MTU as well?
And NetBSD doesn't seem to store the MTU for all the host routes it learned?
It does. I'm seeing one after a test with traceroute -D.
I don't see that even afterward a traceroute -D.
Which NetBSD version are you running? Was this added post netbsd-6 branching?

Re,
/P
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Mouse
2012-09-25 14:56:50 UTC
Permalink
Post by Fredrik Pettai
I see that "netstat -ranl" only show MTU for the lo0 address(es).
ITYPM "route(s)" here...?
Post by Fredrik Pettai
Isn't it suppose to show the local ethernet interface MTU as well?
In my experience, not recently.
Post by Fredrik Pettai
And NetBSD doesn't seem to store the MTU for all the host routes it learned?
This is at least partially version-dependent. The versions I run
differ on this point; 1.4T reports an MTU with each route, whereas 2.0
and 4.0.1 just prints a dash for most MTUs. Looking at 4.0.1's netstat
code, the dash means the MTU fields of their data structures are zero;
looking at the kernel code, I think this means that the route does not
restrict packet size, letting the destination interface, if anything,
do that.
It does. I'm seeing one after a test with traceroute -D.
The ICMPs that drive PMTU-D (and traceroute -D) update route MTUs, so
this is perfectly reasonable.

However, if PMTU-D is disabled (net.inet.ip.mtudisc=0), or if the route
has never run into MTU limits, then the route's MTU may have never been
set. This is the case for most routes for me.

So, yes, NetBSD is capable of storing route MTUs, but it does not
necessarily actually do so for any particular route. As for "host
routes it learned", I speculate that that depends on how it learned the
route. For example, host redirects don't carry MTUs, so a route
learned that way might well not have one set.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ignatios Souvatzis
2012-09-25 14:55:52 UTC
Permalink
Post by Fredrik Pettai
Post by Ignatios Souvatzis
Post by Fredrik Pettai
Hi,
I see that "netstat -ranl" only show MTU for the lo0 address(es).
Isn't it suppose to show the local ethernet interface MTU as well?
And NetBSD doesn't seem to store the MTU for all the host routes it learned?
It does. I'm seeing one after a test with traceroute -D.
I don't see that even afterward a traceroute -D.
Then, maybe, you don't get need fragment back.

After a

ping6 -m -s 1500 to my home machine I get:

2001:db8::1337 fe80::2d0:b7ff:fe75:c02c%xennet0 UGHD 0 3 1280 xennet0

Hm, I can't see a recorded MTU for IPv4, but I remember having seen
it in the past.

-is
Post by Fredrik Pettai
Which NetBSD version are you running? Was this added post netbsd-6 branching?
Re,
/P
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...