[Xorp-users] Redistributing the system kernel route table into OSPF

[Bruce M Simpson]

Hello there,

A few more thoughts spring to mind.

On Sat, Apr 15, 2006 at 08:31:11AM -0700, Frank E. Renwick wrote:
> All this said, I do not expect that XORP should develop a capability just to
> meet my needs.  I appreciate the discussion, and I will meet with my team to
> discuss the option of participating in the development of OLSR as a XORP
> routing protocol.  

This would indeed be the ideal solution.

You can still run XORP and OLSR independently at the same time; XORP
itself just won't see the updates in Windows' routing table.

Three points.

1. Seeing updates would require the use of and integration of the IP
Helper functions NotifyAddrChange() and NotifyRouteChange().

These functions are known to use Win32 Event objects to signal completion.
The XORP event loop code on Windows is an interesting synthesis because
it attempts to manage Win32 objects which signal completion via WFMO
in a single thread.

They only tell you that *something* in the Windows interface stack or
the IPv4 forwarding table changed. They don't tell you what. So an entire
rescan would be needed.

2. Protocols which use IP Helper for route management are tricky because
we can't differentiate their routes from XORP's; as per the documentation
for CreateIpForwardEntry(), any MIB_IPFORWARDROW structures passed
must have the owning protocol set to PROTO_IP_NETMGMT. There's a
minor risk of update collisions.

Until XORP manages to grow support for RRAS, there's no real way of
differentiating forwarding entries managed by one protocol versus
another, so there is a danger of update collisions. You or your team
may be aware that the Win32 APIs involved will fill out the metric with
the interface metric as a default if it isn't specified, providing
a crude form of administrative distance.

We recently committed some fixes for dealing with the situation where
multiple routing protocols in XORP manage routes to the same destination;
when using IP Helper (which in turn indirectly uses MPR) it's necessary
to fill out the MIB_IPFORWARDROW structure *fully* to add/delete the
entry correctly.

The RIB and FEA still assume a single next-hop for a single prefix as
is the case in most PATRICIA trie based RIBs such as 4.4BSD (see Keith
Sklower's original paper) -- there is no multipath support... yet!

3. Currently XORP detects if RRAS is running and will print a warning
if so, as the IP Helper route management APIs may behave inconsistently.
The purpose of this is to enable us to grow support for RRAS eventually.

As you can probably infer from the above commentary, IP Helper isn't an
ideal API for a routing daemon on Windows, nor was it intended to be --
but in the absence of better hints / documentation, it's what everyone
in open source land has ended up using; I haven't seen any open source
RRAS examples other than what Microsoft started shipping in their SDK.

Patches for any of the above gratefully accepted!

HTH,
BMS