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

edrt edrt@citiz.net
Thu, 16 Jun 2005 13:8:53 +0800


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

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)

FYI, WRONGVIF could also bugging PIM process constantly at certain 
topology & scenario. But the latest XORP PIM code could handle it
well.


Eddy