[Xorp-users] GRE for multicast (but no PIM-SM on the tunnel)

Pavlin Radoslavov pavlin at icir.org
Thu May 3 11:00:12 PDT 2007


Vikram Kaul <vkaul at research.telcordia.com> wrote:

> Folks
> 
>  A few question about the details of GRE tunnels between two disjoint 
> multicast enabled (using PIM-SM) domains in XORP.
> 
>  Firstly, I understand that GRE tunnels can be created between two 
> gateway routers (each one taking care of its own "domain"). I refer to
> http://mailman.icsi.berkeley.edu/pipermail/xorp-users/2007-February/001660.html 
> 
> which dealt with a xorp router interacting with a cisco box with PIM-SM 
> enabled on the tunnel on both ends so that the end-points see each other 
> as PIM neighbors.
>  Given that, the need for static rp-address configuration (same at both 
> ends) pointing to the same RP and default mroute (on cisco) and 
> mrib-route (on xorp)
> 
>  My situation is different. Those differences lie in:
> 
>  - I need to have individual separate RPs for each domain for the same 
> group. The gateway routers could be the RPs.
>     I am ok with static configurations on all routers on each "domain" 
> pointing to the respective gateway router as the RP.

In general, if you want have separate RPs for the same multicast
group, then you need to use something between them like
MSDP (RFC 3618) or Anycast-RP (RFC 4610).

Currently XORP doesn't implement either one, and for several reasons
we do not plan to implement MSDP.
We do plan to implement Anycast-RP, but unfortunately currently it
is very low priority on our TODO list.

>  - The above creates the need for disabling PIM-SM on  the tunnels.
>     I want them to be pure tunnels for multicast traffic alone. No PIM 
> hellos or Join/Prunes are exchanged between these
>     RP/gateway routers
> - I am ok with disabling RPT-to-SPT switchover so that the RP is always 
> the root of the tree in each domain.
>     I merely want to "tunnel" the data from this RP/gateway to the other 
> side and be disseminated

Do you always want to tunnel the data or only when there is a
receiver on the other side?
Obviously, the solution (if exists given the limitations) eventually
will be simpler if you always tunnel the data, but then you will be
wasting bandwidth if there are no receivers on the other side.

> 
>       \     /                                                            
>      \     /
>        \   /                                                            
>        \   /
>         \ /                                                             
>         \ /
>          /                                                               
>          /
>         /                                                                
>          /
>        /                            GRE Tunnel                           /
>    RP/GW----------------------------------------RP/GW
>        \                                                                 
>          \
>         \                                                               
>            \
>          \                                                               
>            \
>    ------
> 
> First, I want to implement this purely for two gateway XORP routers. 
> Essentially, the questions are :
> 
>  1. Can I have a multicast tunnel in XORP without enabling PIM on it ?

In XORP there is no explicit support for multicast tunnels.
In fact, the GRE tunnels for example look like any other interface
to XORP (from MFEA, IGMP, PIM-SM, etc. point of view), except that
you need to configure them in advance before starting XORP.

>  2. How do I configure the an mrib-route like
> 
> /       mrib-route 224.0.0.0/4 {
> //                 next-hop: 200.x.x.153 /* tunnel */
>          }
> /
> 
>     which acts in addition to the multicast forwarding caches that might 
> have been established in the RP.

You can't.
The purpose of the mrib-route statements is to add static RPF
entries to the MRIB: those entries are used by PIM-SM to check the
RPF information.

In other words, those entries cannot manipulate the multicast
forwarding caches.
In general you cannot (and shouldn't) manipulate the multicast
forwarding using static configuration, because if you ever create a
multicast loop this will be a disaster.

> 3. For PIM Register packets that arrive at the RP, I want them to be 
> forwarded on the tunnel after they have been decapsulated. Does XORP 
> configuration allow for forwarding on an interface which is not "PIM 
> capable" ? Will "mrib-route" do the trick if the next hop is on an 
> interface which is not PIM capable ?

No (see above).

> Any pointers on feasibility/alternatives/gaping holes in approach are 
> welcome.
> Any ideas on if this were possible in XORP, how well could it fit into 
> interoperability with a cisco box ?

The cleaner solution would be to use Anycast-RP for example which is
relatively simple, but it has its gotchas (see the RFC for details).


However, there is one ugly hack that just came to mind.
It assumes that all the routers on the path between the two RPs have
implemented the (*,*,RP) PIM-SM mechanism as specified in the PIM-SM
spec: this is true for XORP, but I don't know whether Cisco actually
implemented that part of the spec.

My guess is they didn't so if this is the case then you would have
to replace your Cisco with XORP :)
[To be fair, the alternative is to replace XORP with Cisco that
implements MSDP or Anycast-RP :)]

Anyway, here is the basic idea of this ugly hack just to give
you some feeling what you could do without Anycast-RP.

The purpose of the (*,*,RP) PIM-SM Join messages is to "pull" all
multicast traffic that is rooted in a particular RP.
FYI, the (*,*,RP) mechanism was originally added to PIM-SM for
interoperability purpose: e.g., to facilitate connecting PIM-SM
domains with other domains that might even run different multicast
routing protocols.
Hence, if forwarding all multicast traffic from one RP to the other
is not an issue (even if there are no receivers in the other
domain), then you could have each RP to send (*,*,RP) PIM-SM Join
toward the other RP.
Eventually, this will pull-down the traffic from one RP toward the
other using existing PIM-SM mechanisms.

The uglier part of the hack is how to tell the RP to originate those
(*,*,RP) Joins, because the PIM-SM spec describes how to handle
the Joins, but doesn't describe when they are originated (simply
because the "originator" is some other mechanism that uses PIM-SM).
In XORP you can actually do it by sending special XRLs to the PIM-SM
module to tell PIM-SM to originate various PIM-SM control messages
(including (*,*,RP) Join/Prune messages).
Those XRLs were originally added for testing purpose, but in
your case you can have an external program (e.g., a shell script)
that periodically sends them to the XORP router.

However, it is important to note that those XRLs will trigger the
Join messages, but will NOT create the necessary (*,*,RP) forwarding
entry in the XORP router that originates them.
To get around this problem you could simply have a PIM-SM XORP
router N that is a neighbor of RP1 sends them to RP1 with content
(*,*,RP2) Join: thus RP1 will have internal (*,*,RP2) routing entry
and will forward the (*,*,RP2) Join toward the other RP (RP2).
The downside is that all multicast traffic from RP2 will reach not
only RP1, but N as well. If this extra hop overhead is an issue then
we can think about an alternative. Such alternative is to use the
"alternative-subnet" configuration statement on the RP1 PIM-SM
interface toward RP2.

FYI, there are variations of this scheme such like generating (*,G)
Joins instead, but then you need extra monitoring of the (*,G)
routing state inside each RP to know when to generate those
messages.

Please let me know if you want to give a try of the above hack (or
some of its variations), and I can provide you the details how to
use those special XRLs to tell XORP to originate the (*,*,RP) or
(*,G) Joins.

Regards,
Pavlin

> regards..
> Vikram
>  
> 
> _______________________________________________
> 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