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. 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?" Perhaps the answer is that we need to supply a service profile that disables all known routing protocols. > > [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. 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. No, you very likely would _not_ want to use traditional static routes with a routing daemon. Or, at least, doing so would be somewhat unwise. > > Sure; I think having a static route control daemon is actually an > > interesting idea, as it can (just like any other routing service) > > interact properly with policy rules. Traditional static routes can't > > do that. > > > > But I think that's a much longer-term direction. > > But won't these service names be Committed? I hope not. What could possibly depend on them? > 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. There are clear benefits to doing so, but there's a large mountain of FUD to climb first. In the past, we've avoided fighting that battle. > > 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. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
