10

I need to set up a PC to listen in on a multicast (PIM-SM) data feed. The multicast sources and (anycast) Rendezvous point are behind a "HSRP/VRRP address" on the other side of a WAN link. (The instructions actually say "HSRP/VRRP")

As per the received documentation, I have set up a router with a static route to the HSRP/VRRP address, and the other side has added a route to my network. Unicast traffic works fine, but I am not receiving any multicast traffic. Wireshark shows no PIM joins are sent by my router.

What could be wrong?

Improve this question

4 Answers 4

Reset to default
7

PIM messages are not sourced from HSRP VIP's so the RPF check fails since the HSRP VIP is your RPF neighbor. There are two ways around this though.

  1. Set up a dynamic routing protocol between your router and the other sides routers so HSRP is not needed.

  2. Configure static mroutes to the other sides actual interface IP's such as:

    ip mroute 0.0.0.0 0.0.0.0 1.1.1.1

Improve this answer
2

The problem is that the remote routers are announcing themselves with PIM Hello messages from their own IP addresses and my router registers these addresses as PIM neighbours.

The gateway in the routing table however contains the HSRP virtual address. When the router wants to join the multicast group, it looks for the route to the Rendezvous Point which has the HSRP virtual address as the next hop. Because this next-hop HSRP address is not one of the known PIM neighbours, the PIM-SM RFC specifies no Join should be sent.

Changing the static route to use an actual IP address of one of the HSRP routers makes the multicast work, but of course this makes the HSRP useless.

I have not tested VRRP because the other side did not want to change the network. VRRP would probably not have this problem since it does not use a virtual router IP, but uses the real IP address of the master router.

Improve this answer
3
  • The now obsolete RFC 2362 actually states "Join/Prune messages are only sent if the RPF neighbor is a PIM neighbor." I cannot find the exact same thing in the current RFC 4601, but it says " In general, a PIM Join/Prune message should only be accepted for processing if it comes from a known PIM neighbor."
    – Gerben
    Commented May 31, 2013 at 0:30
  • 1
    ...it would be better to edit additional info into your original question if you've learned more since writing the Q. Or if this is meant to be an answer to your own question (which is perfectly acceptable), it needs a lot of work to make sense.
    – Craig Constantine
    Commented May 31, 2013 at 19:47
  • You would see the same behavior with VRRP as most modern implementations do use a VIP.
    – netdad
    Commented Jun 3, 2013 at 12:52
2

Perhaps using a static mroute that points to the 'real' interface IP address, then a normal static route pointing to HSRP. then at least you get HSRP for unicast. OR point either the mroute or static route to the interface rather than an IP address.

Improve this answer
1
  • In this case, the setup was built only for displaying the information coming in through multicast, but otherwise this could be an improvement.
    – Gerben
    Commented May 31, 2013 at 7:46
2

Assuming you're in a Cisco environment....have you enabled ip pim sparse-mode on all the interfaces between that device and the RP?

Also don't forget to have ip pim autorp listener so it finds the RP automatically.

Also - if you have redundant links between you and the RP...PIM routing (or branches) do not follow the same path as the regular routing table. They WILL check for the RPF (reverse path forwarding) to make sure the source of the multicast stream is coming from the right direction. But it is possible to have the standby HSRP link be the DR (designated router) on the PIM side of the house. You can change this behaviour by setting the DR priority. ip pim dr-priority x the higher the X the higher in value.

You can also check to see whether the router see's the multicast joins by issuing show ip mroute it should also list the RP.

show ip pim neigh will also tell you if it see's the upstream multicast neighbour

I believe VRRP follows the same concept however I am not 100% sure since I infrequently use multi-vendor default gateways.

Improve this answer
1
  • "They" were on Cisco, "we" were on Juniper.
    – Gerben
    Commented May 31, 2013 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.