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

[Dan Lukes]

Pavlin Radoslavov wrote:
>>>Can you replicate the problem by running a multicast receiver
>>>(only). I have suspicions that the multicast data packets originated
>>>by an application that is both a sender and a receiver are the
>>>trigger for the NOCACHE.

> If you really want to double-check your suspicion that IGMP Joins do
> trigger NOCACHE, you could do something like:

	Well, I try it today evening (there is deep night now).

	But it seems you are right - the NOCACHE has been triggered by packet, 
not IGMP.

> About the "src = 128.40.89.156 is NOT directly connected" message
> below, are you sure that this TRACE message was in the original
> source code?

>>[ 2005/06/16 01:45:10 TRACE xorp_pimsm4 PIM ] src = 194.160.23.22 is NOT 
>>directly connected

	I'm sure it's not. But it's trace message - it doesn't mean that non 
directly connected source is an error.

	I added it when searching why XORP doesn't respond to NOCACHE signals 
(it has been due disabled PIM on the interface).

> 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 
not kernel bug it explain why I have problem with my original 
configuration. There has been PIM disabled on vif_index=2 because there 
has been no other mrouter on the wire. When packet has been sent from 
195.113.24.3 to 224.0.1.22 the kernel generate NOCACHE with vif_index=2 
which has been dropped due (! pim_vif->is_up())

	I'm not sure about exact interpretation of the PIM specification. It 
seems to be pretty correct to drop the signal when source is not 
directly connected as we need PIM on the interface which is disabled. On 
the other side, when source is directly connected, then processing can 
be done with no PIM communication on the interface from the triggering 
packet come. There seems not to be reason to deny NOCACHE message 
because interface is not PIM enabled - just because the PIM over 
disabled interface is not necesarry to process the signal. It's true ? 
Miss I'm somethink ?


						Dan



[ 2005/06/16 03:09:19 TRACE xorp_fea MFEA ] RX kernel signal: 
message_type = 1 vif_index = 2 src = 195.113.24.3 dst = 224.0.1.22
[ 2005/06/16 03:09:19 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal from 
MFEA_4: vif_index = 2 src = 195.113.24.3 dst = 224.0.1.22
[ 2005/06/16 03:09:19 TRACE xorp_pimsm4 PIM ] src = 195.113.24.3 is 
directly connected
[ 2005/06/16 03:09:19 TRACE xorp_pimsm4 PIM ] install a MFC in the kernel
[ 2005/06/16 03:09:19 TRACE xorp_pimsm4 PIM ] Add MFC entry: 
(195.113.24.3,224.0.1.22) iif = 2 olist = ...O
....
....
....
[ 2005/06/16 03:12:52 TRACE xorp_fea MFEA ] RX kernel signal: 
message_type = 4 vif_index = 0 src = 0.0.0.0 dst = 0.0.0.0
[ 2005/06/16 03:12:52 TRACE xorp_fea MFEA ] RX dataflow message: src = 
195.113.24.3 dst = 224.0.1.22
[ 2005/06/16 03:12:52 TRACE xorp_pimsm4 PIM ] RX DATAFLOW signal: source 
= 195.113.24.3 group = 224.0.1.22 threshold_interval_sec = 210 
threshold_interval_usec = 0 measured_interval_sec = 210 
measured_interval_usec = 790337 threshold_packets = 0 threshold_bytes = 
0 measured_packets = 0 measured_bytes = 0 is_threshold_in_packets = 1 
is_threshold_in_bytes = 0 is_geq_upcall = 0 is_leq_upcall = 1
[ 2005/06/16 03:12:52 TRACE xorp_pimsm4 PIM ] Delete MFC entry: 
(195.113.24.3,224.0.1.22) iif = 2 olist = ...O