[Xorp-users] XORP versions

[Pavlin Radoslavov]

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.

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.

> > 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.

Regards,
Pavlin