James Carlson wrote: >> Two things are different for externally visible behavior: >> - when the route is added the kernel does not require that the gateway >> is directly reachable. If RTF_INDIRECT is not set the gateway must be >> directly reachable as is the case in Solaris today. >> - when we lookup a route and first find an indirect route, we iterate >> to lookup the gateway in that route. (Today if we first find an >> offlink/offsubnet route i.e., one with RTF_GATEWAY set, we iterate by >> looking up its gateway. The indirect route in essence adds one more step >> in this iterative process.) > > Got it. So this is a flag that I-BGP should use when adding routes > that depend on an IGP. Right?
Yep. >> From an implementation perspective there is logic to ensure that the >> caching we do for performance proves the above visible behavior as >> routes are added and deleted; just ensuring that the caching stays >> consistent with the collection of forwarding table entries. >> >> Do you think we should document this somewhere? If so, where? route(1m)? > > By definition, to be a public interface, it must be documented. > > I'd suggest both route(1M) and route(7P). The latter is what routing > protocol authors are supposed to be reading. OK. Do you want to see draft man pages? (It would essenntially be my "two things" text above.) > Yep; that's how BSD works. > > It has RTF_CLONING for the former route, to indicate that when you > match it, you need to create a cloned route, and RTF_CLONED to mark > the entries that were created by the cloning process. > > http://www.daemon-systems.org/man/route.8.html And I think RTF_CLONED maps to 'W' if I don't misremember. Would it make sense to use 'W' instead of 'C' for Solaris in this context? > The multiple A/n case is the one I was interested in. By "do not do > anything special" do you mean this? > > Forwarding always just picks one of these routes (in some > unspecified way) and uses it; there is no load spreading. The > fact that you have multiple routes gives you no benefit -- other > than, perhaps, some robustness if one were deleted. Local > connections, on the other hand, are able to use all of the A/n > routes, and each connection will be assigned to one route in a > round-robin when connecting (or otherwise when establishing or > using the remote address). Yep. Note that right now the refactor-gate implementation for local connections doesn't have visibility to the port numbers when it does the ECMP behavior. We'd to fix that to get better spreading. > What other code (besides the TCP/IP stack) sends M_MULTIDATA? It was > a private interface, and I don't know of any other users. > > If we're disabling multidata, then why not start the process of > removing this old stuff? We could at least start the notification > process on the MDT contracts. Not enough hours in a day, and I don't want to spend those few hours on debating whether or not Cassini is the best Ethernet driver ever. (As far as I know Cassini is the only driver that uses multidata.) Erik
