Sebastien Roy writes: > > Requiring that network interfaces be set up before setting up tunnels > > sounds to me like a bug, not a feature. > > The only aspect of this that smells like a feature is the fact that if > you fat-finger the source address of a tunnel, the UI will return an > error rather than letting you figure that out later when you realize > there is no connectivity through the tunnel.
I (weakly) agree. Still, you can have connectivity problems for so many reasons that I don't think baking this one into the user interface is sound. It gives a false sense of security because "up" doesn't actually mean "up." > > A tunnel is a detached object. It doesn't explicitly use any > > particular underlying network interface. > > It does explicitly use a particular underlying fixed IP source address, > much like any application that binds to a specific local address, so > it's not at all completely "detached" from other networking objects on > the system. It's not really 'using' that interface to do anything. All that it's using is the IP address. The reason I'm making that distinction is that, for purposes of determining where the packets go, it doesn't matter what local IP address matches tsrc. You could have an lo0 alias or vni holding that address, and those interfaces can't be used for output. For what it's worth, and though we don't allow this today, it'd be entirely reasonable to allow an unspecified tsrc, in exactly the same way an application can bind an unspecified source address. The meaning is exactly the same: on outbound packets, we choose a source address based on the next hop lookup, and on inbound, we allow any local IP address to match. And, of course, if you have multiple output interfaces, you can use "usesrc" to make sure that a consistent address is used. So, yes, I view it as very much like binding. Only not enough. ;-} > I see your point, although in 99.9% of cases, if you type "ifconfig -a" > and see an IP address there, and you try to configure a tunnel using > that IP address five seconds later, you'll succeed in creating the > tunnel. If that IP address disappeared in the mean time, then I'd > venture to say that this would normally not be what the administrator > expects, and something needs to be fixed. An error condition being > returned by the tunnel creation wouldn't be entirely unexpected or > puzzling to the administrator. But if that source address disappears one millisecond *after* you configure the interface, you get no notification at all, and your tunnel just stops working silently. The fact that the order of operations matters so much here seems to me to be a defect. > > Yes, I know that's how it works today. I think it's a bug, though. I > > don't like the idea of codifying bugs and design errors into SMF > > dependencies. > > Fixing the tunnel module's behavior isn't entirely obvious. The > existing tunneling implementation is simple. When a tunnel is created, > the tunnel module binds with ip to receive packets destined to a > specific IP address (the tunnel's source). If that bind fails, then the > creation also fails. Yep; understood. > To fix this, the tunnel module would need to register to receive events > of IP address creation. When such an event is received, it would then > need to see if any tunnels not currently bound need to be bound to that > IP address. If so, then it needs to hurry up and bind before that IP > address disappears again. ;-) This would probably be made easier using > the netinfo stuff being provided by the Packet Filtering Hooks > project... This actually sounds to me like it's in the same class of problems as with static route management. A better answer for those is to have some sort of user-space daemon (such as Quagga's zebrad) that's able to implement policy rules to determine what things to bring up, and when to bring them up. So, no, I don't think it's related to packet filtering hooks or other kernel-resident mechanisms, unless that's just a means to a simpler end. Burying policy in the kernel sounds hazardous to me. For statically-configured tunnels, allowing an unspecified tsrc seems much simpler and much more robust. (Though I agree that the current implementation makes that tricky.) -- 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
