PIM register and SPT switchover threshold Vol 1 8.3

I've had a some odd results working through the first few multicast labs that I am struggling to explain.

the first such behavior that confused me was Vol1 8.3, in the solutions there is a line:

"In this scenario, there is a jidden issue. When you start pinging from R6, and
run debug ip mpacket on R4 (the router that registers the source) you will see
something like the following:"

it then presents some debug output of R4 failing an RPF check.

I didnt experience this issue as aside from the fact my OSPF link between R6 and SW1 was broken (MTU mismatch between router and switch) R4 by default was not the router that registered the source, R6 was the DR performing source registeration for the segment (even though the traffic was generted from its own interface). In the end I think I figured out what was going on and it pretty much made sense although I was unable to clarify wether the routers behaviour was RFC compliant as alot of the RFC has pseudo code in place of a normal explanation when it comes to the rules on a PIM RP processing the register message. I've tried to illustrate the scenario I encountered here:

http://imgur.com/mhRRt

For the above diagrams fixing the OSPF link and adding the ospf network point-to-point command on R5's loopback makes the solution work as described in the lab manual. I just thought it interesting that a router will only fail to send a PIM register over a non PIM link if it is the router building the register message and also that the RPF check at the RP on the register message can pass RPF even when recieved over a non PIM link.

the second issue which I have not yet figured out is related to lab 8.3 where setting the spt-threshold to 128k on SW4 seems to break my ability to ping 224.10.10.10 from R6. All expected Mroutes are present, SW4 and SW2 only have a *,G route for 224.10.10.10 as expected due to the SPT threshold setting and from the RP(R5)-R4-R6 there is a S,G route built (SPT). if i remove the SPT threshold on SW4 and clear the routes I can again ping 224.10.10.10 once SW2 and SW4 have joined the SPT and contain *,G and S,G for 224.10.10.10.

The lab manual doesnt indicate whether not being able to ping the address with the SPT threshold set to 128k is normal behaviour... I don't think it is... can anyone clarify thier results on this lab?

Comments

  • The reason R6 sends unicast register message is you enabled PIM on the loopback and it is /24 which represents a segment. So traffic is sent through the loopback and comesback to R6 which gives it the right to send a register-message to RP.

     

    The DR will only send PIM unicast-register messages on a PIM enabled interface. It doesn't make sense to use non-PIM interfaces.

     

    On RP the RPF check is not done on unicast-register messages but on the encapsulated multicast messages. i.e, it is done for the multicast source IP address not the DR IP address. In your case for R6's loopback address.

     

    I'm not sure why but the spt-threshold feature may experience some problem when using Dynampis. 

     

     

Sign In or Register to comment.