Solved: pim dense mode multicast not pruned

prekursor · ‎01-26-2010

My router R3 is connected to 2 other routers, R1 and R2. Each of them is sending me one multicast group that I can subscribe to.

They are all running PIM-DM.

what I have noticed is that, multicast traffic that is received from R1 is being also pushed by my router R3 on the port

that connects to R2, and vice versa.

when I do sh ip igmp interface where router R1 and R2 are connected I do not see them joining any of those groups.

Why is my router pushing multicast to those ports and never prunes them?

I can see outgoing bandwidth utilization on one port being exactly the same as the incoming bandiwdth utilization on the other.

(x.x.x.x,x.x.x.x), 02:02:53/00:02:51, flags: T
Incoming interface: GigabitEthernet7/38, RPF nbr 192.x.x.x, RPF-MFD
Outgoing interface list:
   GigabitEthernet4/47, Forward/Dense, 02:02:53/00:00:00, H
    Vlan10, Forward/Dense, 02:02:53/00:00:00, H
    GigabitEthernet7/39, Prune/Dense, 00:02:53/00:00:06

(x.x.x.x, x.x.x.x), 02:03:42/00:02:51, flags: T
Incoming interface: GigabitEthernet4/47, RPF nbr 192.1x.x.x, RPF-MFD
Outgoing interface list:
   GigabitEthernet7/38, Forward/Dense, 02:03:42/00:00:00, H
    Vlan10, Forward/Dense, 02:03:42/00:00:00, H
    GigabitEthernet7/39, Prune/Dense, 00:00:40/00:02:19

How can I stop R3 to stop multicast that came on 7/38 from going out on 4/47 while alowing multicat traffic to come in on 4/47 and vice-versa?

Giuseppe Larosa · ‎01-26-2010

Hello prekursor,

you have been kind to provide a feedback this makes this thread a complete story with an happy end

edit:

did the multicast boundary worked or not?

I see you have removed the text of your message

Best Regards

Giuseppe

View solution in original post

Giuseppe Larosa · ‎01-26-2010

Hello prekursor,

between multicast enabled routers the protocol spoken is PIM, PIM DM in your case.

So checking what IGMP groups are on interfaces betwern these routers may be misleading

the sh ip mroute tells you that the forwarding state is timed the timer is 240 seconds (3 minutes)

GigabitEthernet7/39, Prune/Dense, 00:02:53/00:00:06

the group is in this state in the last two hours

PIM DM uses a flood and prune approach: until an explicit PIM prune message is received the group is sent out for 240 seconds.

The other device has 240 seconds to send this PIM prune if it doesn't the forwarding state is renewed for other 240 seconds.

This is an opposite logic in comparison to PIM SM where an explicit Join is needed before sending multicast packets out an interface.

You probably have receivers on client vlans downstream the multilayer switches

Hope to help

Giuseppe

prekursor · ‎01-26-2010

(x.x.x.x, x.x.x.x), 02:03:42/00:02:51, flags: T
Incoming interface: GigabitEthernet4/47, RPF nbr 192.1x.x.x, RPF-MFD
Outgoing interface list:
   GigabitEthernet7/38, Forward/Dense, 02:03:42/00:00:00, H
    Vlan10, Forward/Dense, 02:03:42/00:00:00, H
   GigabitEthernet7/39, Prune/Dense, 00:00:40/00:02:19

I have clients on VLAN10 interface and on Gi7/39

gi4/47 and gi7/38 ports are used to connected to our business partner.

Their routers R1, and R2 have other routers that subscribe to the same multicast groups as we do.

is there a way for me to stop sending multicast out of Gig7/38 even though the neighboring router that is connected to Gi7/38

is not sending me prune messages?

Also, I cannot disable multicast on that interface( Gi7/38) since it is used as a source for some other multicast group.

prekursor · ‎01-26-2010

.

Giuseppe Larosa · ‎01-26-2010

Hello prekursor,

you have been kind to provide a feedback this makes this thread a complete story with an happy end

edit:

did the multicast boundary worked or not?

I see you have removed the text of your message

Best Regards

Giuseppe

prekursor · ‎02-17-2010

i have used multicast ttl-threshold command to stop traffic from going out on unwanted PIM-DM enabled interfaces.

I removed the text of my message about multicast boundary because it initialy did not work. (my fault. I had incorrect ACL)

I just confirmed that using ip multicast boundary will fix my problem and I can replace my previous multicast ttl-threshold command.