sg-expiry-timer and show ip mroute output

Unanswered Question
Sep 8th, 2009

We have 20+ instruments which sent multicast alerts when certain monitor values are out of range. We've recently discovered that as long as they send alerts relatively constantly we never drop a packet. If they only send alerts every 10 minutes or so we periodically drop packets. All the instruments are synchronized so they tend to send alerts together and within microseconds of each other.

After some research I've set the sg-expiry-timer to 8 hours. It appeared we were running into a problem of the (S,G) routes in sparse mode getting pruned and the overhead of re-establishing them was too high.

So far so good. I'm confused by the output of 'show ip mroute'. Below is a snippet:

(*,, 06:25:13/stopped, RP, flags: DC

Incoming interface: Null, RPF nbr

Outgoing interface list:

Vlan153, Forward/Sparse-Dense, 06:24:30/00:00:00

Vlan600, Forward/Sparse, 06:25:12/00:02:24, H

(,, 00:01:47/00:02:41, flags: T

Incoming interface: Vlan604, RPF nbr

Outgoing interface list:

Vlan600, Forward/Sparse, 00:01:47/00:02:24, H

Vlan153, Prune/Sparse-Dense, 00:01:42/00:01:22, H

That last entry still shows a 2 minute, 24 second exipriation time for the sparse VLAN 600 route. I would have expected it to be 7 hours, 59 minutes, 24 seconds. The change was made longer ago than the age of the (, S,G route.

Is this mroute expire timer not the one sg-expiry-timer controls ?

Does the *,G route have to be flushed first ? The odd thing is early indications imply the problem is solved but I certainly expected the values from 'show ip mroute' to have changed.

James Robnett

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Giuseppe Larosa Tue, 09/08/2009 - 12:31

Hello James,

the expiration time is not an uptime: it is the time the router waits before removing the entry:

an IGMP report for the group or a PIM join from a downstream router can refresh it.

to see uptimes you should use

sh ip igmp groups

>> After some research I've set the sg-expiry-timer to 8 hours

May I ask you what command have you used?

Hope to help


jrobnett Tue, 09/08/2009 - 12:54

I guess I'm still confused. My understanding was sg-expiry-timer controlled the expiration time for (S,G) mroutes. I had assumed that timeout was the 2nd time in 'show ip mroute' given that the initial output of that command shown below

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

implies the timers are the age and a counter till it expires.

So in the original example:

(,, 00:01:47/00:02:41, flags: T

Incoming interface: Vlan604, RPF nbr

Outgoing interface list:

Vlan600, Forward/Sparse, 00:01:47/00:02:24, H

would become:

(,, 00:01:47/02:24:41, flags: T

Incoming interface: Vlan604, RPF nbr

Outgoing interface list:

Vlan600, Forward/Sparse, 00:01:47/07:59:24, H

The expire portion of age/expires for VLAN600 would change to just under 8 hours. Clearly I'm wrong but don't really get why.

'Show ip igmp groups' gives much the same result for that mcast group: Vlan600 06:59:10 00:02:36

I changed the value with 'ip pim sparse sg-expiry-timer 28800'

Thanks for the reply.


Giuseppe Larosa Tue, 09/08/2009 - 13:16

Hello James,

I've found the link in command reference


This command creates persistency of the SPT (source based tree) over the default 180 seconds for intermittent sources.

given this description I agree that this can be a solution for your problem.

How to verify this, what show command to use is a different matter.

Notice that this has an effect on the amount of memory used by multicast PIM process on your devices: I think it is safe to use it if there are few multicast sources in your network and no many-to-many applications (for these bidirectional PIM is the right tool).

also you can use an extended ACL to be more specific as suggested in the command reference and this can reduce the impact in memory usage giving persistency only to some (S,G) groups

Hope to help


jrobnett Tue, 09/08/2009 - 13:27

In our environment it's many (28) devices sending to few (2 or 3) logging hosts. I think we'll be ok memory wise. Generally all mappings are resident anyway. It's when they go quiescent for longer than the expire time and have to be recreated that we run into problems.

Hopefully somebody can shed some light on how to see that the command has actually don't something useful. Given the 'newness' of the command (apparently last year) I'm almost curious if 'show ip mroute' isn't looking in the right place.

IE, sg-expiry-timer has solved the problem but show ip mroute is still showing a result based on a default 180 second timeout.

Thanks again for the prompt replies.


jrobnett Wed, 09/09/2009 - 06:46

There's some hint that the expiry timer *only* applies to sparse routes. Prior to today we had both sparse and sparse-dense routes within an (S,G) group.

(,, 00:00:07/00:02:52, flags: T

Incoming interface: Vlan626, RPF nbr

Outgoing interface list:

Vlan600, Forward/Sparse, 00:24:07/00:02:52, H <--- SPARSE

Vlan153, Forward/Sparse-Dense, 00:24:06/00:02:56, H <--- SPARSE-DENSE

And the associated (*,G) route was Dense

(*,, 1d00h/stopped, RP, OIF count: 2, flags: DC <----- D = Dense

I changed VLAN 153 to sparse mode so all routes are now Sparse but the (*,G) route is still dense and the expiry-timer change to (S,G) routes still seems to have no affect even though the (S,G) routes within are all sparse.

I attempted to clear all the mroutes on the off hand chance one a (*,G) route is dense it's always dense. Sadly the 'clear ip mroute' command demands a vrf argument which doesn't apply to anything in our config.

3 questions

1) How do you clear mroutes with no vrf mapping short of rebooting.

2) Does the sg-expiry-timer command only apply to sparse routes and if so what dictates whether a route is sparse or dense.

3) Does the sg-expiry-timer command even apply here. It certainly seems to but it doesn't seem to be doing much.

I completely failed to mention we're running the latest IOS, 12.2(53)SG. Apologies for leaving that out.


Giuseppe Larosa Wed, 09/09/2009 - 07:19

Hello James,

>>> There's some hint that the expiry timer *only* applies to sparse routes

yes the command reference says this.

1) to be checked I will report later on this.


if for a (S,G) group no mapping to an RP exists it is treated as a dense mode so it is not interface based but it is decided on a per group basis.


you have seen a positive effect using it so it applies to it.

I admit I didn't know this command.

Hope to help



This Discussion