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
