Girish M G writes: > James Carlson wrote: > > b. The interface dynamically uses the global value as long as the > > local value is not configured specifically for that interface. > > Once it's configured, the connection with the global value is > > severed. > In the same way how 'ip_forwarding' ndd tunable is handled today, > right?.
Sort of ... the existing ip_forwarding mechanism is actually much simpler in definition. It's more like variant (a): when you set the global variable, we go out and change all of the current interfaces to match. When you plumb a new interface, the interface inherits a simple copy of the current global variable. If you just use the global variable functions, everything works as it did long ago. > You can set it for all the interfaces using 'ndd' and control > per interface forwarding ability using 'ifconfig <inf> [-/+]router'. Yes. > Now the question is should we change 'ndd -get' output to display per > interface property just like how we do for 'ip_forwarding'. For 'ndd' > always meant global and there wasn't no per interface stuff. How much > effort we need to put on a tool (read 'ndd') which is eventually going > to die. No; don't do that. The only reason it is still there for ip_forwarding is that someone long ago embellished the ndd ip_forwarding flag to work per-interface within ndd. There's no reason at all to replicate that. If we had added the IFF_ROUTER stuff _before_ the ndd flag had mutated, we would never have done that. > The larger issue is how do we handle things where we will have two tools > 'ndd' and 'ipadm' to begin with and people start using these tools > interchangeably. Yes; I agree. But keep it simple. (And I think the ndd ip_forwarding model, sans the unnecessary "intf:ip_forwarding" hack, is a good way forward.) -- 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
