[Xorp-users] Using XORP for PIM-SM

[Pavlin Radoslavov]

James Courtier-Dutton <james.dutton at gmail.com> wrote:

> Hi,
> 
> 1) If I have two virtual networks running through a single box. I know
> I can have two unicast routing tables. How do I get XORP to handle two
> multicast routing tables and be able to isolate the traffic between
> them. Essentially, I want to have two isolated IP networks running
> through a single box and have XORP maintain the isolation for the
> multicast traffic running over those two networks.

As Ben said in his reply, this is not possible without modifying
both the UNIX kernel and XORP. This is a new frontier for the UNIX
multicast world, so it might take a while until it becomes
mainstream. In the mean time your best bet is to work with Ben and
use his patches (when they are ready) for both Linux and XORP.

> 2) I am trying to use tunX interfaces with XORP.
> If I place an any source multicast (ASM) source at the remote end of
> the tunX interface. Will XORP be able to treat it as a directly
> connected interface and correctly forward it in register messages to
> the RP?

It should. However, XORP itself cannot create tunX interfaces on its
own so you have to create them outside of XORP.
Configuration-wise (IP addresses, etc), you might be able to
configure them via XORP, but if it doesn't work, then you should use
the default-system-config statement in configuraiton like:

interfaces {
    interface tun0 {
        default-system-config
    }
    interface tun1 {
        default-system-config
    }
    ...
}

> 3) How many tunX interfaces can XORP handle?

As Ben mentioned in another email, there is the 32 interfaces
limit in the BSD multicast routing model.
There is a work-around this, but then you will start hitting other
limits in the system (number of max. joined multicast groups, etc).
Please see entries "MLD/IGMP" and "PIM-SM" inside file xorp/ERRATA.
There you will find information how to get around those limits.
Note that the information there is from July 2006 so it might or
might not work for more recent OS-es.

Please let us know whether that information is sufficient to get
around the limit or whether something else is missing.

> 4) How up to date is the current documentation?

What is on the Web site is for XORP-1.4 release.
The documentation that you get from anon CVS (in the xorp/docs
sub-directory) should be up to date with the current code
(note that you need LaTeX to compile all the documents).
The notable exception is the FEA: it has been through major design
changes since the 1.4 release, but its internals shouldn't matter
to you.

> 5) If my tunX interfaces dynamically appear and disappear, is xorpsh
> still the only way to inform XORP that there is a new interface that
> the PIM-SM should talk to. Is it possible to inform XORP about this
> change without impacting multicast traffic going through the current
> XORP instance?

If you use the default-system-config statement (see above), and if
you use the latest XORP code from CVS then you should be able to
start XORP even if the interfaces are not there. Once they are
configured, then the XORP FEA should pick-up the new information and
propagate it to the routing processes.
However, I am not sure whether all routing protocols will be able
to work properly.
The multicast protocols (IGMP/MLD and PIM-SM) for example have some
old outstanding bugs that are related to not being able to start if
some of the interfaces are not configured/operating properly.
Make sure you use the latest code from CVS and give it a try to see
whether it works.
If this fails to work, then you need to have a script that uses
xorpsh to manipulate the XORP configuration (adding/deleting
interfaces, etc).

> 6) I have an application that might mean that I would want to modify
> the olist from PIM-SM. For example, If I receive a PIM-Join on
> interface tun1, I would actually want the multicast for that
> particular group to leave via tun10 instead. So, I would be adding a
> dynamic config item to the tun1 interface, saying, if I receive a
> PIM-Join(S,G1), instead of actually forwarding multicast traffic out
> of tun1, divert (S,G1) traffic to tun10 by adding tun10 to the olist
> instead of tun1 for that particular group. Where in XORP is the olist
> calculations done?

One good interception point in the olist calculation is
method PimMfc::update_mfc() inside file pim/pim_mfc.cc

I would be interested to see what solution you will use at the end
to achieve this inter-interface mechanism.

Regards,
Pavlin