> > No, I have not encountered this problem. The targets mount just in time
> > for my zones. But it sounds to me like a dependency on
> > svc:/network/routing/route:default for cluster could help this along?
> > CT
> Hi Christine,
> We have dependencies upon routing.
> However, this dependency only let's us know when
> initialization of routing started and does not
> tell us when things are ready.
That's correct, though it's actually worse than that.
Fundamentally, it's not possible to build such a dependency. There is
no way to know whether you will ever receive any routing information
from the other systems out on the network, or whether that information
will ever be complete or even sufficient to perform the task you want
to do. "Ready" makes no sense.
As a simple (but by no means exclusive) example case that illustrates
the problem, let's assume the following:
- You're on the 192.168.0.0/24 network. This network using RIP-2
- There's a router located at 192.168.0.1. This router advertises
the default route, because it connects to most of the rest of the
networks in the area, and knows how to reach the (off-link) NAT to
get to the wider Internet.
- There's another router located at 192.168.0.2. This router
advertises only a route to 10.0.0.0/24, because that's the only
other interface it has. For simplicity, 192.168.0.2 is the only
path to 10.0.0.0/24.
- The router at 192.168.0.1 reaches 10.0.0.0/24 via 192.168.0.2. In
other words, your local 192.168.0.0/24 network is also used for
some internal transit traffic; it's not just a simple stub.
Now suppose the server you want to reach is at 10.0.0.1. If
192.168.0.2 is down, you won't be able to get there because the only
path is cut. A strictly "dependency-based" check, though would
suggest that you *can* get there. After all, not only does routing
come up on your local system, but you also hear a default route from
192.168.0.1. As far as dependency checking can go, you've got
everything you need.
Your packets, though, would end up errantly matching the default
route, being sent via 192.168.0.1, and then either dropped silently,
replied-to with ICMP Destination Unreachable, or perhaps even with a
redirect to the unusable 192.168.0.2 router (because redirects stink
as a routing protocol ;-}). In any event, you can't get there from
In other words, by talking about such a dependency, I believe you're
really asking the wrong question. The only "dependency" a networking
application ought to have should be: "is the networking stack
initialized?" And even that one (in a perfect world) ought to be a
simple "yes" at all times.
The right questions are:
"How do I set up a retry algorithm?"
"Are there any ways to get hints for retries?"
If you're using TCP or SCTP, then the transport layer itself does the
retries. You don't need to mess about with it; just let it do its
job. At most, you need an application-layer retry, but that ought to
be a fairly long timer: there's not much reason to pester a broken
network with useless packets.
For the second question, you can listen to a routing socket if you
want. You'll get notified of routing changes, and these (particularly
RTM_ADD) may well signal a good time to schedule another connection
Any time the dependency lines on the graph extend outside the confines
of the box, we need to be very careful. Networking is _not_ the same
as system design, and SMF addresses only the latter.
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
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
zones-discuss mailing list