cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2028
Views
0
Helpful
3
Replies

Multicast receiving but not forwarding?

bfisk
Level 1
Level 1

Hi,

I'm about to retire in a few weeks and this could be my last troubleshooting job so I'd love to see it resolved.

The problem is as per the title. There is a  core ring of routers feeding numerous outstation routers, dual attached to different core sites for resilience.

The requirement is to get Multicast working and at present I'm working on just one remote site.

       -------------------------------------------------------------------------------------------------------------------------------------

       |                                                                                                                                    |

RP---core router----core router----|etc|-----core router R1¬ -----core router-----|etc|-----core router-------

                                                                               |

                                                                               |

                                                                       Spoke router R2

                                                                               |

                                                                               |

                                                                       Spoke switch/router R3

                                                        

What I have managed to prove so far is that configuring ip igm join-group 239.192.2.10 on a Vlan on R3 starts up a multicast stream on the core ie if I look on R1  I see :-

R1>sh ip mr ac
Active IP Multicast Sources - sending >= 4 kbps

Group: 239.192.2.10, (?)
  RP-tree:
     Rate: 431 pps/4683 kbps(1sec), 4683 kbps(last 0 secs), 0 kbps(life avg)
R1>sh ip mr 239.192.2.10
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, E - Extranet,
       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,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.192.2.10), 00:08:25/00:02:56, RP 10.4.2.2, flags: S
  Incoming interface: GigabitEthernet0/0/2, RPF nbr 192.168.251.65
  Outgoing interface list:
    GigabitEthernet0/0/0.142, Forward/Sparse, 00:03:09/00:02:56

R1>sh ip mr 239.192.2.10 cou
IP Multicast Statistics
15 routes using 7776 bytes of memory
10 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.192.2.10, Source count: 0, Packets forwarded: 150637, Packets received: 150637
  RP-tree: Forwarding: 150637/426/1358/4629, Other: 150637/0/0

Looking on R2 [3945 ver 15.0(1)M] I see :-

R2>sh ip mr ac
Active IP Multicast Sources - sending >= 4 kbps
R2>sh ip mr 239.192.2.10
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, E - Extranet,
       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,
       V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.192.2.10), 00:09:36/00:03:07, RP 10.4.2.2, flags: S
  Incoming interface: GigabitEthernet0/0.142, RPF nbr 192.168.254.17
  Outgoing interface list:
    GigabitEthernet0/1, Forward/Sparse, 00:04:20/00:03:07

R2>sh ip mr 239.192.2.10 co
IP Multicast Statistics
15 routes using 7728 bytes of memory
10 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.192.2.10, Source count: 0, Packets forwarded: 0, Packets received: 0

Checking the i/c interface on R2 gi0/0 when the join command has been implemeted on R3, the multicast rate is increasing rapidly so I assume the stream is reaching R2. Conversely when the join command is removed the multicast packet rate drops to next to nothing.

So the question is, why isn't R2 forwarding the packets? All docs point towards RPF failures but there doesn't appear to be any?  As a precaution I have added /32 static routes and mroutes both ways to the end devices.

I'm assuming the signalling is OK because I can get the stream generated, so am I looking at a data plane issue in R2?

I've also tried to turn off fast switching for multicast but this box/IOS uses mfib so there's no command I can see like no ip mroute-cache. Maybe I've missed something in mfib docs?

For configuration of R2 it's real basic, ip multicast routing and ip pim sparse-mode on the gi0/0.142 and gi0/1 interfaces and ip pim rp-address 10.4.2.2

One thing I thought I should be seeing is an S,G pair which I don't, even on the core router R1 which shows the stream as active?

Any thoughts gratefully received.

Thanks

Bob

3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee

Hi Bob,

I wonder... What is the original TTL of the multicast packets as they are generated into your network? It is possible that the TTL is set to quite a low value, and at a certain point in a network, the multicast stream simply expires because its TTL gets decremented to 0. Can you verify that the stream is generated with a sufficiently high TTL value?

Best regards,

Peter

Thanks for the reply Peter.

I did think that could be a possibility but checking sh ip traffic I don't see lots of time exceeded counts. Might be a good idea just to check with the customer what the actual TTL is just in case.

Cheers

Bob

Hello Bob,

Hmmm... Perhaps the show ip traffic does not count multicast exceeded TTLs - I do not know for sure. Verifying the TTL, ideally using some sort of a packet sniffer to go beyond all doubts, would be the very first thing I'd do.

Best regards,

Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card