[Xorp-users] Multicast without PIM on internal interface while PIM on external

Pavlin Radoslavov pavlin@icir.org
Thu, 16 Jun 2005 12:39:34 -0700


> >> > It is normal to receive NOCACHE signal with src that is not directly
> >> > connected, because NOCACHE is triggered when the multicast
> >> > forwarding plane sees a multicast data packet (eventually from a
> >> > sender several hops away) and the forwarding plane doesn't have a
> >> > matching forwarding entry for that packet.
> >> 
> >> 	Well. And what about directly connected src ? I'm sure the NOCACHE is 
> >> generated for directly connected sources also (see log bellow). If it's 
> >
> >It is normal to receive NOCACHE for sources regardless whether they
> >are directly connected or not.
> >In any case, the interface the packet was received on must be
> >enabled in the MFEA configuration section.
> >
> >One thing you were probably seeing is that in the MFEA section you
> >enabled the interface toward the source, but you disabled it in the
> >PIM section: the MFEA received the NOCACHE upcall and accepted it,
> >but then PIM (correctly) threw it away.
> >
> >Pavlin
> >
> >
> 
> This scenario could cause performance degrade of PIM router. 
> Say, a source is multicasting large volumn data, PIM process
> router will constantly receive NOCACHE notification from kernel
> even if it isn't enabled on that interface.
> 
> One method to alleviate the problem is to have MFEA MRT_ADD_VIF
> to kernel only those PIM enabled interfaces. But, this still doesn't

For the time being the simple solution is in the XORP configuration
to enable the MFEA interfaces only if the PIM-SM interfaces are also
enabled.
What Dan was trying to do with enabling only the MFEA interfaces
doesn't work anyway so there is no point of enabling an interface
only in the MFEA section.
Though, yes, in general I agree that the MFEA should call
MRT_ADD_VIF on an interface only after a multicast routing protocol
expresses interest in using that interface. This will be fixed in
the future.

> prevent the not-directly-connected-network-source-address multicast
> host from bugging MFEA. Anybody have good method to solve the problem?

It doesn't matter whether a source is directly connected.
If the MFEA doesn't call MRT_ADD_VIF on an interface, then the
kernel won't trigger any upcalls to the MFEA for packets that
arrived on that interface.

> Another similar scenario cause performance degrade of PIM router
> is about WHOLEPKT. When a source is multicasting large volumn data
> and PIM router has no idea about a particular RP(G), PIM process
> will constantly receive WHOLEPKT notification from kernel.
> Add below code might alleviate the problem on FBSD with advance mcast api.
> 
> in ip_mroute.c/pim_register_send
> 
> 	if (mrtdebug & DEBUG_PIM)
> 		log(LOG_DEBUG, "pim_register_send: ");
>  
> +	if ((mrt_api_config & MRT_MFC_RP) &&
> +		(rt->mfc_rp.s_addr == INADDR_ANY)) {
> +		return 0;
> +	}
> 
> (Pls let me know if you find the above code piece has defect)

The advanced multicast API has been intentionally designed to send
WHOLEPKT to user-space if the RP address in the matching MFC entry
in the kernel is not set. It is also documented in the multicast(4)
manual page (on *BSD).
The reason for this is to allow greater flexibility: for some (S,G)
MFC entries the userland program may want to do something special
with the PIM Registers encapsulation so it wants to receive
WHOLEPKT, while for other entries it may want the kernel to handle
the encapsulation.

The proper solution would be that if the userland program doesn't
know the RP address, then it shouldn't include the register_vif in
the MFC entry's outgoing interface set.
I will add a note that we should do this in XORP.

Pavlin