cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1507
Views
25
Helpful
14
Replies

PIM-DM timer question

Laszlo Zoltan
Beginner
Beginner

Hi all,

I have a multicast network like this:

      +-----+

      | SRC |

      +--+--+

         |

----+----+----+----

    |         |

    ~         ~

    |         |

 +--+--+   +--+--+

 | R1  +---+ R2  |

 +--+--+   +--+--+

    |         |

 +--+--+   +--+--+

 | RCV1|   | RCV2|

 +-----+   +-----+

 

There is a source node (SRC) that send multicast traffic to two routers (R1 and R2).

The routers route this traffic to their receiver (RCV1 or RCV2). In normal case the paths are these:

SRC -> R1 -> RCV1

SRC -> R2 -> RCV2

The R1 and R2 are far from the SRC. The RCVx is near the Rx.

In case of the link error between SRC and R1 the multicast traffic must be on this path:

SRC -> R2 -> R1 -> RCV1

The line break is detected by IP SLA ping to a host near SRC. If ping is success then a static route is inserted in the router to the SRC via direct line, and multicast is received from the direct line. If the ping is failed then a persistent unicast static route with higher metric to SRC via other router is active, and the multicast traffic is received from other router.

The multicast routing is working fine in this manner.

But the transition from the normal path to the alternate path needs about 90 secs. IP SLA can detect the line break in 3 secs. So the 90 secs are because of PIM timers. Unfortunately I do not know which PIM timer is responsible for this.

How can I set PIM-DM in order to faster transition?

Thanks,

Laszlo

14 Replies 14

ngkin2010
Rising star
Rising star

Hello,

 

I am learning on the multicast routing and I am interested to check on your problem, hope I can help.

 

First, according to your description, R1 and R2 are far away from the SRC, I assume neither R1 nor R2 are the gateway of SRC, there is another router(s) between SRC and (R1,R2).

 

But could you please share if both receivers are not joining the same multicast group?

 

If so, in normal situation, the multicast traffic (to RCV2) will forwarded to RCV2 by R2, but becoz you are using PIM dense mode, the multicast traffic will also forwarded to R1 by R2.

 

When R1 received that multicast traffic, it find that none of the downstream devices interested for this multicast group, so it send Prune message to R2 (which tell R2 stop sending the multicast traffic to R1).

 

So, in a steady-state situation, R2's interface that facing to R1 is pruned.  (verify by show ip mrouting)

 

But if the link is down, R2's interface will not resume from pruned state to forward state immediately.. In stead, it wait until the prune timer expire (that is default 180 seconds), after that it will resume to forward state again.

 

Not sure if it make sense or not..

Hello,

Thank you for the fast response.

There is not any router between SRC and (R1, R2).

Both receivers join to the same multicast group.

I think that the normal case the R1 drops the multicast traffic arrived from the R2  because R1 has better route to the multicast source via direct line. In this case does R1 send prune message to R2?

Thanks,

Laszlo

Hi Laszlo,

"I think that the normal case the R1 drops the multicast traffic arrived from the R2 because R1 has better route to the multicast source via direct line"

If that is the case, the RPF check will fail, and discard the multicast traffic. But you said the IP SLA can detect the link down in 3 seconds, and shouldn't the route will change accordingly? Could you verify?

Hello,

In normal case the IP SLA ping installs a route to SRC via direct line in R1 so RPF check enables multicast traffic from SRC via direct line and the RPF check fails on the line between R2 and R1.

In case of error on direct line the IP SLA ping fails and removes the earlier installed route in R1 so the persistent unicast static route with higher metric to SRC via other router is active and the RPF check enables multicast traffic from SRC via other router.

It is working well. The transition time is long only.

Thanks,

Laszlo

 

Hello Laszlo,

So, the actual problem is the "route to SRC via direct line" takes long time (90 seconds) to be uninstalled from routing table by IP SLA? Please confirm, thanks.

Best,
Ngkin