[Xorp-users] IGMP/PIM question ?

[Pavlin Radoslavov]

> pavlin>However, if I understand correctly your question, you want to
> pavlin>influence the choice of which router reacts to IGMP Join messages,
> pavlin>and this choice should be a function of the receiver's address.
> pavlin>This is not how the IGMP and PIM-SM protocols operate, so most
> pavlin>likely you won't be able to do it even with source code modification
> pavlin>(the answer depends on the details about what exactlty you need to
> pavlin>achieve).
> 
> I took a cursory look at the code. Specifically, 
> 
> In igmp_proto.cc   in   Mld6igmpVif::igmp_process(...)
> 
> If right away, a check for source address is done as follows...
> 
>    // Only accept my own queries, neglect all others
> 
>     if (!(mld6igmp_node().is_my_addr(src)))
> 	return (XORP_ERROR);
> 
> then all IGMP messages from other nodes/routers can be neglected. Of 
> course this is not what the protocol is supposed to do, but I am merely 
> looking at all alternatives. Because if this check, the procedures for 
> selecting/electing IGMP Queriers will not happen and all nodes will be 
> IGMP Queriers only responding and taking care of 'themselves'

Yes, modifying the above code will have impact on accepting the IGMP
control messages by XORP.

However, this modification won't have impact on the IGMP host-side
implementation inside the kernel. This is where the IGMP Join
suppression happens. Hence, even if you reject the IGMP Queries and
Membership Report inside XORP, they will still be processed inside the
kernel. The processing of the IGMP Membership Report messages inside
the kernel may trigger the IGMP Membership Report suppression (if
there are 2+ receivers on the same LAN).
As a result, you may never see the IGMP Join event by multicast
application running on the local host.

> Similarly, 
> 
> In pim_proto_hello.cc   in    static bool pim_dr_is_better(...)
> 
> could be made to return "false" all the time so the initial selection of 
> this node/router as the designated router for PIM Join/Leaves is 
> maintained. 

Yes, the above modification inside PIM can make each PIM-SM router
believe it is the DR, but then you have to be very careful if there
is a sender with 2+ PIM-SM routers on same LAN. Each of the routers
will think it is the DR and will eccapsulate same multicast data
packet in PIM Registers and unicast it to the RP.
As a result, you will see duplicated packets from the sender.

> These two mods, in essence, should make each node/router 
> 
> A) An IGMP Querier taking care of only itself 
> B) A Designated Router taking care of only itself
> 
> It is almost like reverting back to old times when Quering and DR was 
> shared by the same router.. except this is much more drastic
> 
> pavlin>
> pavlin>Below are the issues with IGMP and PIM-SM reacting as a function of
> pavlin>the receiver's address:
> pavlin>
> pavlin> * In case of IGMP, the adjacent routers need to elect the IGMP
> pavlin>   Querier. The Querier is elected per LAN and the router with the
> pavlin>   lowest IP address on the LAN is the winner. Though, from PIM-SM
> pavlin>   perspective you shouldn't care which router is the IGMP Querier, so
> pavlin>   the IGMP Querier choice shouldn't impact you.
> 
>  See above
> 
> pavlin>
> pavlin> * In case of PIM-SM, the adjacent routers need to elect the
> pavlin>   Designated Router. The DR is elected per LAN, and the election is
> pavlin>   a function of the routers' IP addresses and their DR priority
> pavlin>   (configurable by the PIM-SM dr-priority configuration
> pavlin>   option). Only if a PIM-SM router is the DR for the LAN, it will
> pavlin>   take into account the IGMP Join event to initiate the PIM-SM Join
> pavlin>   message.
> 
> Once the IGMP messages from any other node/router other than self have 
> been neglected (above hack in igmp_proto.cc), then the DR will look at 
> IGMP Join events from itself alone. 
> 
> pavlin>
> pavlin>   The fundamental problem here is that the IGMP and PIM-SM
> pavlin>   protocols do not track the IP address of the multicast
> pavlin>   receiver. In other words, IGMP and PIM-SM care only if there is
> pavlin>   a multicast receiver for a particular multicast group, but they
> pavlin>   don't care about the particular IP address of the receiver.
> pavlin>   Hence, when the IGMP module detects an IGMP Join event, it tells the
> pavlin>   PIM-SM module about the joined multicast group, but it doesn't
> pavlin>   tell anything about the receiver's address.
> 
> I understand the functionality of the protocols as they are supposed to be 
> used. I am merely experimenting with them and was wondering if I could use 
> the current implementations in XORP (of course, after some mods) to 
> achieve my objectives.
> 
> pavlin>   One of the reasons IGMP and PIM-SM cannot track the receivers'
> pavlin>   addresses is because the IGMP host protocol uses IGMP Join
> pavlin>   suppression: if there are two or more receivers on a LAN for the
> pavlin>   same multicast group, only one of the hosts originates IGMP Join
> pavlin>   messages.
> pavlin>
> 
> Unfortunately, the above mods will eliminate that supression. But I am 
> willing to give something to get something in return. Of course, a more 
> careful look into the implementation could guide me into making (or at 
> least think of making) other mods which have minimal impact on the 
> protocols. 

Unfortunately, those mods won't eliminate the suppression problem,
because as I mentioned above it happens inside the kernel, and you
cannot disable it by userland programs.

Also, they won't eliminate the PIM Register encapsulation issue.
Though, if you always switch to the shortest path (to the sender)
after the first data packet, then the PIM Register duplicated packet
will happen only when a new sender becomes active (until the SPT
switch to that sender is completed).

Pavlin