[Xorp-users] IGMP/PIM question ?

Pavlin Radoslavov pavlin at icir.org
Tue May 23 10:17:40 PDT 2006


>   I am trying to check whether I will be able to use XORP. Specifically, 
> here is what I am trying to do:
> 
> The multicast applications reside on a linux box which acts as a router as 
> well. There are no 'end hosts' per-se. A string of these linux 
> 'routers/hosts' are connected to each other and unicast routes are 
> available. Initially, I will set the unicast routes statically, but later 
> on move to a xorp-rip or ospf daemon.
> 
> What I intend to see is whether I will be able to run PIM-SM (with 
> statically configured RPs) in a scenario like this. When the receiver 
> application starts, I want the local PIM daemon to respond to the local 
> IGMP Membership Report (which would have ordinarily used been used to join 
> a group). Of course, the PIM daemon in the adjacent router that would have 
> ordinarily responded to this IGMP message should neglect it in the 
> scenario I want to create.
> 
> Similar to the above functionality, a host of other IGMP/PIM interactions, 
> also have to be limited to "local" daemons (IGMP and PIM) rather than the 
> traditional relationships between 'end-hosts' and their corresponding 
> "pure" routers. For example, an IGMP membership Query should be handled 
> locally to trigger any PIM prunes or grafts
> 
> I am open to modifying the code to suit my needs.. but would prefer if I 
> could execute the above with configuration setups only.
> 
> I am new to the XORP architecture, so I might be way off in what I think I 
> can accomplish using XORP. In any case, any insight will be very welcome

In general, a router could act as a sender/receiver as well.
If you don't care which particular router on the receiver's LAN
reacts to the multicast Join/Leave events, etc, then it should
work without any source modifications.

However, if I understand correctly your question, you want to
influence the choice of which router reacts to IGMP Join messages,
and this choice should be a function of the receiver's address.
This is not how the IGMP and PIM-SM protocols operate, so most
likely you won't be able to do it even with source code modification
(the answer depends on the details about what exactlty you need to
achieve).

Below are the issues with IGMP and PIM-SM reacting as a function of
the receiver's address:

 * In case of IGMP, the adjacent routers need to elect the IGMP
   Querier. The Querier is elected per LAN and the router with the
   lowest IP address on the LAN is the winner. Though, from PIM-SM
   perspective you shouldn't care which router is the IGMP Querier, so
   the IGMP Querier choice shouldn't impact you.

 * In case of PIM-SM, the adjacent routers need to elect the
   Designated Router. The DR is elected per LAN, and the election is
   a function of the routers' IP addresses and their DR priority
   (configurable by the PIM-SM dr-priority configuration
   option). Only if a PIM-SM router is the DR for the LAN, it will
   take into account the IGMP Join event to initiate the PIM-SM Join
   message.

   The fundamental problem here is that the IGMP and PIM-SM
   protocols do not track the IP address of the multicast
   receiver. In other words, IGMP and PIM-SM care only if there is
   a multicast receiver for a particular multicast group, but they
   don't care about the particular IP address of the receiver.
   Hence, when the IGMP module detects an IGMP Join event, it tells the
   PIM-SM module about the joined multicast group, but it doesn't
   tell anything about the receiver's address.
   One of the reasons IGMP and PIM-SM cannot track the receivers'
   addresses is because the IGMP host protocol uses IGMP Join
   suppression: if there are two or more receivers on a LAN for the
   same multicast group, only one of the hosts originates IGMP Join
   messages.

Please let me know if I have misunderstood your question and you
need to do something different.

Pavlin

P.S. I should mention the following to avoid any surprises.
Some time ago it was brought to my attention the following Linux
kernel bug: if you are running PIM on a network interface, and if
your multicast application running on the router joins a
multicast group on that same interface, then the IGMP Join
message will trigger a kernel NOCACHE upcall (even if there is no
multicast data). This bogus upcall should be harmless, but could
be confusing if you are debugging some multicast-related issues.
Though, I haven't check whether the bug is still in the most
recent Linux kernel.



More information about the Xorp-users mailing list