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
