[Xorp-users] XORP versions

[Mikael Johansson]

On Jan 14, 2008 9:33 PM, Pavlin Radoslavov <pavlin at icir.org> wrote:
> Mikael Johansson <johansson500 at gmail.com> wrote:
>
> > > In the context of virtualization, you can run multiple XORP
> > > instances, but only for unicast protocols (BGP probably excluded due
> > > to some short-term reasons), and only on Linux which supports
> > > multiple unicast forwarding tables.
> > > You can't run do this for multicast. One of the reasons is that the
> > > UNIX kernel allows only a single instance of the special multicast
> > > routing socket.
> >
> > We need to do multicast too, so running multiple XORP instances is
> > probably not the solution for us.
> >
> > We don't even necessarily need multiple forwarding tables (although it
> > would be preferable). A kind of a hack which would do almost
> > everything we need would be to somehow be able to control which routes
> > are advertised to which OSPF or BGP neighbor, and there are different
> > configurations. For example if a device has two BGP neighbors and two
> > OSPF neighbors, the routes from one BGP neighbor could  be advertised
> > to only one OSPF neighbor. I don't think this is possible in XORP.
>
> Currently, the multiple (unicast) forwarding tables is the only way
> to run multiple XORP instances on the same stack. Otherwise, the
> result can be unpredictable (e.g., if two XORP instances try to
> install the same route into the single forwarding table).
>
> Regarding the routes advertisement, actually you can achieve a lot
> with policy statements. They are very flexible and give you lots of
> control. So you might be able to achieve what you want with some
> policy configuration.

Yes, we can achieve almost everything we need by using BGP policy
rules, but not when OSPF is used. Another example of the kind of
things we need to do is to disable advertising between two OSPF
interfaces. I don't think this is possible in XORP, at least not in
all cases (AS-external routes, or OSPF interfaces belonging to the
same area).

> BTW, when you mention advertising BGP routes into OSPF, I hope you
> are not planning to export full BGP feed (200K+ routes) into OSPF.
> IGP protocols like OSPF are not designed to carry that amount of
> load so for that you should use iBGP instead.

There is no need to process that many routes (the design of the
network is quite unusual).

> > > If you want to run multiple XORP instances, please drop us an email,
> > > so we can give you the technical details (they are not in the in the
> > > user documentation yet).
> > >
> > > If you use XORP on top of Xen or Vmware, then you are practically
> > > running multiple OS instances, so the above limitations don't
> > > apply.
> > >
> > > An alternative solution is to use IMUNES:
> > > http://www.imunes.net/
> > > http://www.tel.fer.hr/imunes/
> > >
> > > It virtualizes the kernel networking stack itself and is extremely
> > > lightweight. It also has a very cool GUI which gives you lots of
> > > control over the virtual topology management.
> > > It is available for FreeBSD, so if you don't have OS requirements
> > > I'd strongly recommend considering it.
> > > Marko Zec (who wrote IMUNES) is on this mailing list and can give
> > > you more information about it.
> >
> > We also need to run another application which is only for Linux, so we
> > can't use FreeBSD.
>
> FYI, FreeBSD has Linux binary compatibility support (e.g., you can
> run Linux Firefox binary on FreeBSD). Unless your application is
> doing something Linux-specific, you might actually be able to run
> the binary on a FreeBSD box.
>

It is Linux-specific, the main part is a Linux kernel module. There
are also other reasons that force us to use Linux.

Regards, Mikael