Girish M G wrote:
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.
But the CR merely states that a tunable is desired to work around
problems with too high packet rates. We don't need this to be a
user-accessible tunable ... self-tuning should be perfectly adequate here.
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).
Once upon a time I think there were busted stacks that would improperly
forward packets. I think the TTL was designed to guard against
forwarding loops. Hopefully such cases are now uncommon, and a default
TTL should be adequate for everyone.
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.
It sounds like like what you really want then is a boolean
"accept_icmp_redirect" or somesuch, not a tunable interval for flushing
the results.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
