Erik Nordmark writes: > James Carlson wrote: > > > Rather than adding new strict_src ndd tunables, I would like to see us > > just add a simple "strong-ES" flag that does both and get rid of the > > old strict_dst. > > Getting rid of the old means that customer's scripts which set > strict_dst would break. We could introduce a strong-ES ndd variable (or > per-interface flag) which has the semantics of "strict_dst + strict_src" > if we assume that most users that care would want both semantics instead > of just one half.
We never really did give much stability to these ndd things, precisely because they were so hackish in usage. Breaking strict_dst on a Minor release boundary wouldn't offend me much, and with OpenSolaris claiming Major release binding, I think it's just irrelevant. There's no upgrade path planned (as far as I know) from S10 to anything -- the path from there goes into S10-branded zones, and not a system upgrade. > > It's probably something that could be reasonably defined as an IP > > interface flag, but if it's just an IP global, I wouldn't complain too > > much. Either way, strong-ES completely breaks routing, so I likely > > wouldn't want to use it. ;-} > > The way strict_dst is implemented it can be used on a router (it only > applies to interfaces that do not have ILLF_ROUTER set) I didn't say you couldn't turn on strict_dst and then "exempt" some of the interfaces from those restrictions by setting the "router" flag. Instead, I said that strong-ES (as defined) doesn't work with routing. Our strict_dst implementation just makes the two states mutually exclusive: you either get forwarding on an interface or strict_dst, but you can't get both. In any event, I'm not the audience for strong-ES. > and we can > define and implement the strict_src semantics the same way. That allows > us or customers to always enable this, and routers would still work. Sure. It just seems gratuitous to me at a time when we're busy trying to rip out ndd variables to be multiplying these ones. This should be aligned with Brussels. > > There are a *LOT* of complaints and general customer unhappiness with > > Solaris buried under this particular rock. See CRs 4777670, 4173841, > > and 4085133. And approximately a zillion discussions on sig.oe and > > sig.ns. > > Sounds like this is worth-while to fix given that the complexity is > reasonable once we have IP datapath refactoring. Yes. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
