On Thu, Aug 03, 2006 at 03:12:04PM -0400, James Carlson wrote: > Nicolas Williams writes: > > > If it's a matter of saying "turn off RIP, turn off BGP, turn off OSPF, > > > turn off IS-IS, turn off DVMRP, turn off ..." and iterating through a > > > huge list, then I think we've lost part of the control that's desired > > > here. > > > > I'd expect them to have to turn ON the routing protocols they want, not > > OFF; I'd expect them to know what protocols they want on, how to > > configure them, etc... > > I think that misses the point that some people are _really_ afraid of > routing protocols. They like the fact that /etc/defaultrouter is a > big hammer: it disables dynamic routing protocols.
I thought that default routes (static or discovered through DHCP or what have you) should be handled by a svc:/network/initial, say... > If you get rid of the big hammer, the first question will be: "so, how > do I get this back, because I want to be really sure?" ...then your big hammer is: is the routing service's enabled/disabled state. > Perhaps the answer is that we need to supply a service profile that > disables all known routing protocols. Certainly when profiles can do more than enable/disable services we could do that. > > > [1] No, I don't completely understand this point of view, so it's hard > > > for me to describe it adequately. Perhaps one of the adherents > > > will chime in. ;-} > > > > Does noone mix dynamic and static routing? > > Here's where implementation details and high-level descriptions > collide. > > If you're doing both at the same time, then you generally configure > your static routes in a completely different way. You want them to > interact properly with the routing protocols (and policies) you're > using, so you configure them as part of the routing protocol daemon > configuration. > > When you are doing static routing _only_, you typically just arrange > for a series of "route add" commands to get run at boot time, and then > forget about it. That's what the new "route -p" option is about. It may that we're stuck with this split, and stuck with it for good. But other routers don't have this split, and I find that cleaner. > The two aren't really the same. When you use the routing daemon > configuration interfaces, you can add attributes to your routes that > are meaningless to the kernel (such as metrics) but that affect how > the routes are advertised and used in the rest of the network (if at > all). But to do that, you have to run a routing daemon, which is > something that some users seem to want to avoid. > > When you configure "traditional" static routes, you don't get any of > that goodness. It's just a next hop and an interface. That's it. But you could have a daemon manage static routes, and then later you might turn on an IGP, say, redistribute some or all of those static routes into the IGP, etc... With this static vs. dynamic+static dichotomy the switch from one to the other requires using different interfaces; that seems lame. Perhaps one would so rarely switch that it doesn't matter. > > But won't these service names be Committed? > > I hope not. What could possibly depend on them? Scripts, profiles, people? > > My point is that if we weren't forced to specify transient-ness in the > > service configuration then we could avoid splitting these services if we > > lack a routing daemon that can be configured to just install some static > > routes and sit there. > > Possibly ... but I think that works only if we can sell users on the > idea of running a routing daemon for static routes. Er, you misunderstood. Suppose you have only static routes configured (beyond the default route). Then suppose the start method of this service added them to the forwarding table using the route(1M) command, and exited without starting any daemons -- that would be a problem if the service was not declared to be transient, no? Then consider the opposite. You have a dynamic routing protocol configured, so the start method should start a daemon. The service shouldn't be considered transient then, else it won't be restarted if the daemon dies. I'm considering the possibility of a service that decides, when its start method runs, whether it will be transient or not. > > > The issue, I think, is still how one can enable and disable desired > > > services. In this case, I see no clear way to disable the "dynamic > > > routing protocol" service, unless it exists as an SMF entity. > > > > Huh? If you want forwarding to be enabled then you'd configure routing > > (static and/or dynamic) and enable the service, and if you wanted no > > forwarding then you'd leave the service disabled (or disable it if it > > had been enabled). > > I'm not asking about forwarding at all. I'm asking about dynamic > routing protocols. > > As I mentioned earlier, they're not the same thing, and actually not > related. You can do either one, both, or neither, as you choose. But this doesn't mean that you can't have one service -- the transient-ness issue would force you to have more than one service. That's one thing I'm getting at. Nico --
