Garrett D'Amore wrote:
I've not been following too closely, but my thoughts follow. Note
that I'm normally *not* a fan of having a large number of tunables.
Its too easy for users to get themselves into a bad configuration, and
the complexity they add is IMO more painful then the benefit many of
them bring.
Very true. In that regard we are also in the process of 'eliminating'
some tunables, which really should have been auto-tuned, as part of 'ndd
cleanup work' and mails were sent out to 'sig.ns', 'sig.oe' and
'net-core' asking if any customers were using some tunable.
ip_fragment_timeout: why needed -- IMO this should be self tuned based
on link speed. Or perhaps instead of link speed, watch the IDs go
by. If more than 256/2 (i.e. 128) IDs go by, the fragment could be
tossed.
Several customers have requested for that. See CR 6815806. Also RFC 4963
(IPv4 Reassembly Errors at High Data Rates) leaves it up to layer above
IP to check for data corruption as it is difficult to identify
mis-association at IP given NAT and tunnels.
ip_def_ttl: why would anyone still need to tune this? I'd be happy
with this being locked away in a global (and undocumented) /etc/system
variable.
I don't know sufficient history behind this tunable. But to quote Jim,
(http://mail.opensolaris.org/pipermail/networking-discuss/2009-February/010281.html)
ip_def_ttl - SID 1.5 ip.c, November 1991 Mentat update
it seems like it could be related to some RFC issue (though not clear what).
ip_ire_redirect_interval: this one looks fishy to me. why needed?
If a router/gateway, not under your control, is issuing 'icmp redirect'
messages and you don't want that route to be instantiated in your
solaris routing table, then this tunable would help. At least that's the
purpose of this.
~Girish
_______________________________________________
networking-discuss mailing list
[email protected]
