[Xorp-users] PIM-SM in xorp cvs

[Pavlin Radoslavov]

> > > Just for the record, one needs PIM in all interfaces where multicast
> > > packets will flow, why is that technically necessary just for curiosity?
> > 
> > Because this is how the PIM-SM protocol operates. E.g., a multicast
> > data packet will be forwarded on an interface only if an explicit
> > Join (PIM-SM or IGMP/MLD) message has been received.
> 
> Is this true for SSM model too and for IPv6? Thanks.

Yes.

> > > Now I'm getting lots of this errors just with differents interfaces and
> > > differents from IP addresses:
> > > 
> > > [ 2006/08/22 20:36:07  ERROR xorp_pimsm4:30195 PIM +2623 xrl_pim_node.cc mfea_client_send_protocol_message_cb ] Cannot send a protocol message: 102 Command failed Cannot send PIMSM_4 protocol message from 10.0.2.1 to 200.0.204.169 on vif eth4: sendmsg(proto 103 size 28 from 10.0.2.1 to 200.0.204.169 on vif eth4) failed: Operation not permitted
> > > 
> > > If you see the 200.0.204.169 router is in eth6, why XORP try to send
> > > from 10.0.2.1 to 200.0.204.169 on eth4? that obviously will fail and
> > > probably is why is not permitted, maybe is the source of the other
> > > problem when I see bogus from IP addresses in PIM-register messages.
> > 
> > If 200.0.204.169 is directly connected to eth6, then eth6 should
> > have been used to transmit the message.
> > The above information is not sufficient to answer why eth4 is used
> > instead. The first thing to check is the MRIB entries, and whether
> > PIM-SM is actually running on the 200.0.204.169 interface.
> 
> PIM-SM is running on all interfaces, as I'm not running BGP in XORP
> but in Quagga I'm using the fib2mrib to populate it, I can confirm
> that the URIB is ok and the route to 200.0.204.169 is via eth6, dunno
> why xorp try to send to 200.0.204.169 via other interfaces, should I
> check in another place?

Try the XLOG_INFO() debug statement I sent you in an earlier email.
This might give us some additional info about the issue.

Also, one more thing you should try is to run XORP only (without
running BGP from quagga or even from XORP itself), and install
static routes toward the RP. Then see whether you have the same
issue with selecting the RPF interface.

> > > It should send to 200.0.204.169 using the primary IP in eth6 which is
> > > the interface towards the RP as we have talked previously.
> > > 
> > > 989.877636 168.234.203.126 -> 200.0.204.169 PIMv2 Register
> > > 989.941391 200.0.204.169 -> 168.234.203.126 PIMv2 Register-stop
> > > 1576.736525 168.234.203.5 -> 200.0.204.169 PIMv2 Register
> > > 1576.800376 200.0.204.169 -> 168.234.203.5 PIMv2 Register-stop
> > > 
> > > What Register-stop packets means?
> > 
> > The Register-stop packet is sent by the RP to the DR and indicates
> > that the RP is not interested in receiving PIM Register messages for
> > a particular source and group address.
> > E.g., typically it is sent when there are no (*,G) receivers.
> 
> Ok.
> 
> > > And as you can see there are two different IP sources for PIM Register
> > > packets, that is the problem I mentioned above about bogus sources.
> > 
> > The source addresses seem fine: the PIM Register is sent from the DR
> > to the RP, and the PIM Register-Stop is sent from the RP to the DR.
> > Hence, I don't think there is a problem here.
> 
> I think it is a problem because there are 2 differents source addresses
> used by XORP 168.234.203.126 and 168.234.203.5, if I understand
> correctly XORP will pick _ONE_ time it's primary address (168.234.203.5)
> and and stick to it for talking to the RP.  Other address to talk to the
> RP is dubious IMO.

Yes, sorry, I didn't realize that both 168.234.203.126 and
168.234.203.5 belong to the same XORP router.
What is the output of the "show pim interface" and
"show pim interface address" for that router?

Also, here again please try running XORP with static routes only and
see whether it will again select a different source address for each
PIM Register message.

Thanks,
Pavlin