[quagga-dev 7606] Re: Q: zebra and RTA_IFP
carlsonj at workingcode.com
Mon Jan 11 18:42:53 GMT 2010
sowmini.varadhan at sun.com wrote:
> On (01/11/10 13:00), Greg Troxel wrote:
>>> Conversely, on Solaris, the kernel will *not* fill in the interface,
>>> so that you'll have an "unbound" route when RTA_IFP is not used.
>>> Does zebra care or rely on this latter behavior? (I can't see any
>>> reliance when I read the code, but I want to confirm from the list).
>> It's likely the basic answer is that this difference is not intentional.
>> Does the solaris route find the interface of the nexthop dynamically (at
>> each use)?
> Yes, the binding happens when you actually have to send the packet.
> I believe HPUX behaves the same way too, since they too are derived
> from the original Mentat stack.
> It can result in some oddness and unpredictability, because one could
> end up with routes for which the gateway is not resolvable interface
Packets like that should just drop, but getting back to the original
question: I believe that routing daemons should always generate routes
with RTA_IFP set to a particular interface, but the issue is a little
Routing protocols always know which interface should be used for
matching packets, and setting the RTA_IFP makes sure that the output
interface is correct. And, if the OS allows for really unnumbered
links, it's the only way to tell the system where the packets should go.
The complication is that Solaris (at least) tends to be a little too
helpful when RTA_IFP is set. For static routes, when the interface goes
down, the routes disappear from the table and are cached invisibly by
the kernel. There's no way to delete the routes while the interface is
down, and they pop back into existence most unexpectedly when the
interface comes back up.
For non-static routes, I think the system deletes the routes when the
interface goes down. This is mostly good, but it can confuse a routing
daemon that thinks it's in charge: when the daemon sees the interface go
down, it'll try to delete any routes that are affected by that change,
and it will fail those operations because the system has already removed
James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
More information about the Quagga-dev