[Xorp-users] Question on supporting multiple routing tables.
Pavlin Radoslavov
pavlin at icir.org
Thu Aug 9 00:51:23 PDT 2007
> >> 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
OK, I just committed to CVS the changes for configuring the table
ID. You can do it with configuration like:
fea {
unicast-forwarding4 {
table-id: 20
}
unicast-forwarding6 {
table-id: 20
}
}
Obviously, you won't need the unicast-forwarding6 section if you
don't need IPv6.
I just did some simple testing and it appears to work.
Please get the latest code from anon. CVS and let us know whether it
works for you:
http://www.xorp.org/cvs.html
> 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.
Eventually, in the future we should add support for configuring the
Finder's address and port inside the XORP confuguration file, but
such change probably won't be trivial.
BTW, if you set the environmental variable before starting the XORP
rtrmgr, you need to set that variable as well before starting the
corresponding xorpsh CLI.
> 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...
Probably you will be the first one to try 100s of XORP instances, so
we would be very interested to know how it goes.
BTW, in Linux you cannot have more than 255 or so forwarding tables,
and some of those tables shouldn't be touched, so ~250 is the
max. number of table IDs and XORP instances you can try.
> > 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.
Yes, once we have proper VR support in XORP, eventually we will use
configuration sections like what you suggest above.
However, this is down the road so I am afraid that for the time
being the burden is on you to configure properly each XORP instance.
Though, the UCL folks who are looking into that space might have
some other ideas/suggestions.
Regards,
Pavlin
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
More information about the Xorp-users
mailing list