[Xorp-users] Question on supporting multiple routing tables.

[Ben Greear]

Pavlin Radoslavov wrote:
> Ben Greear <greearb at candelatech.com> wrote:
>
>   
>> Hello!
>>
>> I am curious how hard it would be to get Xorp to support
>> multiple routing tables.  My goal is to support virtual routers (VR).
>>
>> For instance, suppose eth0 and eth1 belong to one VR, and eth2 and eth3 to
>> a second VR.  I'd associate eth0 and eth1 with routing table X, and eth2 and eth3
>> with routing table Y.  I'd want the Xorp daemon to treat the two sets of
>> interfaces completely separate, and update the correct routing table as needed.
>> Xorp should NOT, for instance, think that eth2 can talk to eth0 unless OSPF
>> messages or similar are received on the eth0 and eth2 interfaces allowing such
>> communication.
>>
>> I already have scripts to create the proper routing tables and a few patches
>> to the kernel to make this work, but I'd like to support 'real' routing protocols
>> as well.
>>     
>
> What kind of isolation do you want between the VRs?
> E.g., do you want to run a single XORP instance that will control
> two forwarding tables, or do you want to run 2+ XORP instances
> (one per forwarding table).
>
> If you want to run 2+ XORP instances, you can probably do it with
> just a little bit extra work:
>
> * Right now all forwarding entries are installed in the main
>   forwarding table RT_TABLE_MAIN.
>   You need to modify the FEA such that it allows to specify the
>   corresponding routing/forwarding table ID it should be
>   manipulating. The table ID is used inside the
>   fea/data_llane/fibconfig/ directory (search for rtm_table).
>   There are total of three places where rtm_table is used. In all
>   those cases it should take some pre-configured table ID.
>
>   A new configuraion XRL should be added to the FEA that will be
>   used to configure/specify the forwarding table ID.
>   This XRL should be added to xrl/interfaces/fti.xif and should
>   look like:
>
>     /**
>      * Set the forwarding table ID.
>      *
>      * @param table_id the forwarding table ID.
>      */
>     set_forwarding_table_id ? table_id:u32
>
>   Then, obviously, the processing side for this XRL needs to be
>   implemented inside fea/xrl_fea_target.hh and fea/xrl_target.cc
>
>   Finally, inside etc/templates/fea.tp there should be a
>   configuration entry for the forwarding table ID.
>
> * Before starting each XORP instance you must specify a different
>   port number to be used by the XORP Finder. E.g.:
>
>   setenv XORP_FINDER_SERVER_PORT 20001
>   # Start first XORP instance
>
>   setenv XORP_FINDER_SERVER_PORT 20002
>   # Start second XORP instance
>  
> * It is up to you to make sure that inside the XORP configuration
>   for each XORP instance you configure/use only those interfaces
>   that   correspond to the particular forwarding table. E.g., in the
>   first XORP instance you should configure only eth1 and eth2, and
>   in the second XORP instance you should configure only eth3 and
>   eth4.
>
> BTW, note that the above solution might work for unicast, but won't
> work for multicast forwarding, because the UNIX kernel allows
> only one open multicast routing socket per system.
>
> If the above is sufficient for your need, then it is relatively easy
> to implement it. It will be actually useful for XORP itself, so we
> might actually implement it anyway (for free :).
>   
This sounds like a good first step, and it sounds like it meets my 
immediate needs.  Instead
of an environment variable, I'd prefer a cmd-line variable and/or 
something in
the xorp router config file.  However, I know almost nothing about how Xorp
is written, so if it needs to be an environ variable, that is OK.

I do not need this to support multicast at the moment.

Eventually, I'd like to scale to 100s of VRs, so it would probably be 
more efficient to run a
smaller number of Xorp processes, each able to handle a lot of routing 
tables, but
that can be dealt with later.  And, it may turn out that running 100+ 
processes
is not such a big deal considering all of the cores on newer systems...

> However, if you want to run a single XORP instance that will control
> 2+ forwarding tables, this will be much more complicated to do.
> For example, there should be somewhere a mapping which interfaces are
> associated with each forwarding table. Futhermore, if each routing
> process needs to be aware about the separation, then it will become
> ever more complicated. This might lead to a design which will allow
> you to configure, say, 2 OSPF instances each of them talking to 2
> RIB instances.
>   

I'd expect to configure which route-table an interface belongs to 
similar to how
you add an IP to a interface.  Or, could have a larger 'virtual-router' 
section that
holds all the ports & info for that router instance.  It's likely the 
individual logic
units would be one per VR, and they would not talk to each other 
directly (but only
through normal message passing on the interfaces).  I figure this will 
be more
efficient because there will be only one process, but again, I could be 
wrong
about that.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com