[Xorp-hackers] Some thoughts

[Kristian Larsson]

On Mon, Nov 07, 2005 at 02:29:01PM +0200, Hasso Tepper wrote:
> Mark Handley wrote:
> > 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?
> 
> What is "change"? Two actions can be done by kernel (via ifconfig or
> any other mechanism) - add address or delete address. 
>  
> > 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.
> 
> Xorp has to force the use of address which is configured in rtrmgr. If
> address is deleted by kernel and event to delete is not initiated by
> Xorp, it has to send address_add message again to the kernel.
> 
> > 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.
> 
> No way. Nothing should change running config automatically. All addresses
> coming from system should have meaning for rib only.
> 
> > 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.
> 
> My view is something like this:
> 
> * Xorp is in charge, but it listens kernel if it doesn't conflict with
>   Xorp's view of things.
> * All addresses and connected routes configured/added by kernel have
>   meaning for rib only - no configuration changes.
> 
> Situations:
> 
> Interface is created in Xorp (it has to exist in the system for now, but
> hopefully this will change). Addresses already on interface are added to
> the RIB (like it's done with default-system-config at the moment). If
> there are addresses configured in Xorp, they are added to the interface.
> 
> Xorp receives address_add message from kernel - address are added to the
> RIB with connected route (if it isn't there already).
> 
> Xorp receives address_del message from kernel. If it is the address not
> configured from Xorp, delete it from RIB. If it is configured from Xorp,
> add it back - ie. send address_add to the kernel.
> 
> Interface is deleted in Xorp. Only the addresses configured from Xorp are
> removed from interface.
> 
> If you see any problem with this approach, please tell me. This fixes
> both link-local and vrrp/carp cases.
> 
> Btw, it also fixes secondary address handling in Linux for example. At
> the moment you can try something like this on Linux:
> 
> XORP# create interfaces interface eth0 vif eth0 address 10.10.10.1
> prefix-length 24
> XORP# commit
> XORP# create interfaces interface eth0 vif eth0 address 10.10.10.2
> prefix-length 24
> XORP# commit
> XORP# delete interfaces interface eth0 vif eth0 address 10.10.10.1
> XORP# commit
> 
> Result is that interface eth0 has no addresses configured, but 10.10.10.2
> is still configured in Xorp. That's because Linux deletes all secondary
> addresses from interface if primary is deleted.
I beleive there is an option for this.
Promote secondary IPs
When deleting a primary the 'next' secondary will
become primary.
Of course, most people don't have this ( I think
it is available as of 2.6.13 or .14) so what
you're saying still holds true.

   Kristian.
> 
> 
> with my bets wishes,
> 
> -- 
> Hasso Tepper
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers