[Xorp-hackers] Some thoughts

[Mark Handley]

On 11/6/05, Hasso Tepper <hasso@linux.ee> wrote:

> Interface handling.
>
> Xorp ignores runtime address/interface deletes/adds from OS and users
> have to configure all interfaces in Xorp. As I understand it, it's done
> by design and I remember some of developers saying that it will not
> change as main focus of Xorp is research platform. It prevents to use
> Xorp as software for production in many cases (including mine, seems).
> But this requirement is IMHO strange even for research platform:
>
> * You have to configure even IPv6 link local addresses which is business
>   of underlying stack and out of users control in every platform I know
> * It doesn't allow to use Xorp together with software which modify
>   addresses and routes - high availability stuff for example (vrrp, carp
>   etc.)

This is nothing to do with it being a research platform, and
everything to do with not having a well-defined alternative.

The question is really one of who is in charge.  The long-term goal is
to have a complete router, where you never want or need to bypass the
FEA for something as basic as interface config.

Now, suppose I configure the IP address of an interface through the
rtrmgr.  The FEA will set this interface address.  And now someone
changes it through ifconfig or whatever.  What is the correct action
for XORP to do?

The IP address has been configured in XORP, so XORP should in
principle believe this is still what is wanted.  If it observes the
change, then it should re-configure it back, as XORP is still
configured to set this particular address.

An alternative is for XORP to monitor the machine state, and consider
the rest of the machine is in charge.  In which case it would then
change it's running config automatically.  But the general idea is the
running config is set by a human, so having this change under you
isn't principle of least surprise.

The end result is that there is no good answer to this.  As XORP is
intended not as just a routing daemon, but as the entire router
control plane (yes, long-term plan), then the most sensible (and
certainly simplest) answer is "XORP is in charge".

We discussed this ad-nauseum in the early days of XORP, and ended up
with this decision.  There is simply no good solution to this that
everyone would be happy with - you have to decide who is in charge.


Now, the IPv6 link-local address issue is one where the kernel should
be in charge.  Not any other user-space daemon.  Thus this is
obviously one we should handle better than we do.

And issues such as CARP/VRRP should be handled in a what that the user
specifies somehow that this address is to be set automatically, and so
can change under you.  We don't have the hooks for this right now, and
should have.  But there's only so much time, and so many things to do.

Cheers,
Mark