[Xorp-hackers] Is it possible for XORP to act like N independent routers ?

[Pavlin Radoslavov]

> 1. there are multiple physical interfaces on a Linux
> box
> 2. each physical interface has the same set of VLAN
> interfaces
> 3. the router should treat each set of VLAN interfaces
> with the same ID as an independent "routing domain"
> that is completely independence of the other "routing
> domains" and the addresses might even overlap, i
> believe i am misusing the term "routing domain" here
> but please forgive me for a lack of a better term.
> 4. at the kernel routing layer each "routing domain"
> will have its own routing table
> 5. packets are fwmarked at the VLAN interfaces
> 6. packets are policy routed according to the fwmark
> to the corresponding routing tables
> 7. the routing software maintains all the independent
> route tables
> 
> 
> some one tell me am i insane ?
> some how the project I'm working on has led me to this
> conclusion. could this be easily done ?
> would people accept this into the XORP code base ?
> can it already be done ?

One simple solution that comes to mind is to run N independent
instances of XORP on the same machine. E.g., N FEAs, N RIBs, N BGPs,
etc, and each instance configured with its own configuration file.
This should work in case of unicast routing, but if you want to run
multicast routing as well the solution needs to be adjusted to run
only one FEA/MFEA, because the UNIX kernel allows only one multicast
routing socket open at a time.

To run more than one XORP instance at a time, you need to do the
following, but I should warn you upfront that there is a small
catch:

Set the XORP_FINDER_SERVER_PORT environmental variable to use an
unique TCP port for each XORP instance. The default value I believe
is 19999. You need to set it before running the rtrmgr (e.g.,
"setenv XORP_FINDER_SERVER_PORT 30000" in case of tcsh), and you
also need to set it before starting the corresponding xorpsh
instance that will communicate with that rtrmgr.

The catch is that on startup the FEA removes all leftover unicast
routes installed by XORP in the UNIX kernel (those routes are marked
with a special flag so the FEA can recognize them when it pulls the
forwarding table from the kernel). Also, on shutdown it removes all
XORP routes as well. Unfortunately, currently this removal is
unconditional, but ideally it should be configurable.
What that means is that if the first instance of XORP adds some
routes to the kernel, then if you start a second instance of XORP,
the second FEA instance will remove all XORP routes already
installed in the kernel by the first XORP instance.

The simple way to get around the above catch is to comment-out the
following lines:

    delete_all_entries4();
    delete_all_entries6();

Those are inside methods start() and stop() inside the following
files:

  fticonfig_table_set_click.cc
  fticonfig_table_set_dummy.cc
  fticonfig_table_set_iphelper.cc
  fticonfig_table_set_netlink.cc
  fticonfig_table_set_rtsock.cc

Strictly speaking, typically you need to comment them out in only
one file. E.g., in case of Linux it would be
fticonfig_table_set_netlink.cc and in case of BSD it would be
fticonfig_table_set_rtsock.cc.


Probably there are other solutions of your problem so I would be
interested to hear other ideas.

Pavlin