mroute showing multicast route as being pruned, help!

[christopher.wood]

Hello,

I have an issue getting multicast to work for a new device. Trying to replace the old device, but it seems that when the new device is using multicast the route is pruned. Not sure how to fix this. Using PIM sparse-mode.

(*, 239.192.0.25), 05:18:13/stopped, RP 172.31.255.1, flags: SP
  Incoming interface: GigabitEthernet0/1, RPF nbr 172.27.65.3
  Outgoing interface list: Null

(172.27.1.60 (old), 239.192.0.25), 05:18:13/00:02:08, flags: T
  Incoming interface: GigabitEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/1, Forward/Sparse, 05:18:13/00:03:03

(*, 239.192.0.5), 00:01:00/stopped, RP 172.31.255.1, flags: SP
  Incoming interface: GigabitEthernet0/1, RPF nbr 172.27.65.3
  Outgoing interface list: Null

(172.27.1.81 (new), 239.192.0.5), 00:01:00/00:02:07, flags: PT
  Incoming interface: GigabitEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(*, 239.192.0.3), 03:19:35/stopped, RP 172.31.255.1, flags: SP
  Incoming interface: GigabitEthernet0/1, RPF nbr 172.27.65.3
  Outgoing interface list: Null

(172.27.1.60 (old), 239.192.0.3), 03:19:38/00:02:54, flags: T
  Incoming interface: GigabitEthernet0/0, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/1, Forward/Sparse, 03:19:38/00:02:43

(*, 224.0.1.40), 7y34w/00:02:57, RP 0.0.0.0, flags: DPL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

It almost sounds like I just need to turn the old one off and let the new one work and the old route should age out and the new route can start working from what I've read?

[christopher.wood]

Anyone?

[christopher.wood]

Trying one more time here, can anyone help me?

[chrihussey]

Is the new device generating the multicast stream and is there anything on the network trying to join the group?

[christopher.wood]

This was during our attempt at generating the stream and having devices join the group. The timers for these routes have likely aged out since.

[chrihussey]

Trying to understand the issue. Do you see the multicast group from the 172.27.1.81 on its local LAN segment? Meaning it is generating the appropriate stream.

And when a device attempts to join the group it fails?

[christopher.wood]

I believe so. I took a capture of a bunch of different commands, and it was comparable to the old device 172.27.1.60. Just seems for whatever reason the mroute for 172.27.1.81 is being pruned when it shouldn't be. I don't know how to fix that so it is no longer pruned.

Is there any specific commands that would display more information that would help? Like I said I captured a bunch of items when we were trying to make it work. We also have two routers setup in HSRP and there was no mroute for 172.27.1.81 on the standby router.

[chrihussey]

What you are seeing may just have been that what was ever receiving the multicast, left the group and it was then pruned.

Since multicast routing is operating on your network I will assume all is set up correctly and you have no ACLs or configurations prohibiting the multicasts the 172.27.1.81 host is sending.

A simple test to verify the multicast is working would be:

1- Verify 172.27.1.81 is sending the multicast on its local subnet.

2- Go to a remote subnet where hosts should join the group and in interface configuration mode type "ip igmp join-group 239.192.0.5" or whatever group it is supposed to be. This will cause the interface to join the group.

Then check the path between source and destination and verify it's working with the "sh ip mroute" command. While the join is in place, you should see and outgoing interface and the T.

To remove the group from the interface just enter "no ip igmp join-group 239.192.0.5"

Once this is done, you should see the prune.

Please report  back the results, with some outputs for that group and we can take it from there.

[christopher.wood]

I will do this and get back to this conversation ASAP. Thanks for the help.

[christopher.wood]

Actually, I do have a wireshark capture from the local subnet when I was trying to troubleshoot this. I'll get Part 2 done in a few days as the person I'm working with is off til next week.

[chrihussey]

OK, that's fine.

The capture shows for group 239.192.0.11 and the output in the original post shows for 239.192.0.5. Not much to glean from that other than we can assume the 172.27.1.81 application uses a range of multicast addresses.

[christopher.wood]

So I have some more information, but wasn't able to perform the join group command.

So Client side router seeing this in the mroute, but nothing mapping the 172.27.1.81 to the route.

RTR-6#sho ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(*, 239.192.0.1), 00:18:14/00:02:12, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    BVI1, Forward/Dense, 00:16:19/00:00:0

It can ping the 172.27.1.81 address though.

And then the router that is directly connected, that routes to the client routers doesn't see 172.27.1.81 being announced at all.

olgc-lesmill#sho ip mroute vrf RBV-OLGC-TEST
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(*, 239.192.0.13), 1w0d/stopped, RP 172.31.255.1, flags: SP
  Incoming interface: Vlan4094, RPF nbr 172.31.255.5, RPF-MFD
  Outgoing interface list: Null
 
(172.27.1.60, 239.192.0.13), 1w0d/00:03:24, flags: T
  Incoming interface: Vlan509, RPF nbr 172.27.65.1, RPF-MFD
  Outgoing interface list:
    Vlan4094, Forward/Sparse, 1w0d/00:02:43, H
 
(*, 239.192.0.3), 1d03h/stopped, RP 172.31.255.1, flags: SP
  Incoming interface: Vlan4094, RPF nbr 172.31.255.5, RPF-MFD
  Outgoing interface list: Null
 
(172.27.1.60, 239.192.0.3), 1d03h/00:03:24, flags: T
  Incoming interface: Vlan509, RPF nbr 172.27.65.1, RPF-MFD
  Outgoing interface list:
    Vlan4094, Forward/Sparse, 1d03h/00:03:07, H
 
(*, 239.192.0.25), 1d20h/stopped, RP 172.31.255.1, flags: SP
  Incoming interface: Vlan4094, RPF nbr 172.31.255.5, RPF-MFD
  Outgoing interface list: Null
 
(172.27.1.60, 239.192.0.25), 1d20h/00:03:15, flags: T
  Incoming interface: Vlan509, RPF nbr 172.27.65.1, RPF-MFD
  Outgoing interface list:
    Vlan4094, Forward/Sparse, 1d20h/00:02:46, H
 
(*, 224.0.1.40), 5y47w/00:02:32, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback11, Forward/Sparse, 5y47w/00:02:32

I don't know if this gives any useful information since the route is being pruned in the mroute table.

[chrihussey]

It is difficult to figure out what's going on here. Please understand that it's just the nature of the forum. However, please reference the multicast address that we need to look at in any future posts. Also, you only need to apply the "ip igmp join-group x.x.x.x" configuration to the one LAN interface where a receiver would be. This is only for testing purposes. It should not affect anything.

Something that I do notice, is that your last output from the two different routers show that one is operating in sparse mode and the other dense mode. Your original post said it was a sparse mode environment. Why is dense mode showing? Might be something there.

Not sure how large your network is, but if you could provide a simple diagram, even if it is a small portion that applies for testing it would help. Also, if you could provide the configs of the routers on either end that would help. Based on that information it would be easier to figure out what is going on. 

Finally, and this has been on my mind, if you have a network the has been running multicast and you are just replacing the device/application and using the same multicast range it is tough to believe that it is a network issue and not an application issue. If this isn't the case, please elaborate.

[christopher.wood]

Ah, I asked the tech to apply it to the BVI interface of the client (receiver). It was the BVI that had the main IP we use to route to it. Should it have been applied to just the LAN then? The issue is the network is part on an ISP and the other part my department. So the two router outputs are from our ISP.

I uploaded a high level overview of the network. It seems like the route shows up, but with no information on where to connect.

(*, 239.192.0.1), 00:18:14/00:02:12, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    BVI1, Forward/Dense, 00:16:19/00:00:0

Should have the 172.27.1.81 address. The 239.192.0.1 was the multicast address we were using for the 172.27.1.81. Seems like the 172.27.1.81 is not being announced to our ISPs router? Mind you the route shows pruned on our router.

Thanks for looking into this with me, btw. Its much appreciated.

[chrihussey]

So the clients can get the multicast stream from the old server (172.16.1.60) and not the new (172.16.1.81), is that correct?

I doubt it is a routing issue in that I assume the ISP is routing to the 172.16.1.X LAN segment and not just host routes.

Yes, you put the "ip igmp join-group x.x.x.x" command only on the LAN interface of a client. Then check the RP and see it you see the join. If you want send a config of a client router and your RP router.

Glad to help if I can. Might take a few iterations.