DMVPN Spoke RPF Failure

Jeremy Buck · ‎12-18-2012

I've got an issue whereby spoke routers in a DMVPN configuration will not send an RPT PIM join message towards the RP (which is through the DMVPN hub) to join the shared tree. The RP actually lies behind the DMVPN hub on a tandem router.

There is no multicast client on the spoke router, however an ip igmp join-group is configured on a LAN interface and traffic is sourced from that same interface. The initial RPT PIM Join message appears to never leave the local router and is dropped due to RPF failure. So the question here is, how is this failing RPF? The tunnel interface is configured with a correct multicast mapping for the hub using the physical endpoint address.

There is a static default mroute toward the DMVPN hub mGRE interface.

I attempted to debug mpacket on the router to verify the message generation and header contents but it looks like I have to disable the mroute-cache and the router is a 2951 using the new mfib syntax (which seems a bit more granular).

Any ideas are appreciated... as far as I am aware the RPT PIM Join message should be destined for the PIM v2 multicast address and should reach the DMVPN hub for processing--but this never appears to happen.

Peter Paluch · ‎12-18-2012

Hello Jeremy,

There is no multicast client on the spoke router, however an ip igmp  join-group is configured on a LAN interface and traffic is sourced from  that same interface.

I do not quite understand from this description whether the router's interface is receiving a multicast traffic from a source connected to this interface, or whether this interface is supposed to be an egress interface for a multicast traffic received via a different interface.

If this interface is supposed to receive the multicast traffic (i.e a multicast source is connected to it) then such interface never needs any IGMP-related configuration. The only required command on the router's interface towards a multicast source is the ip pim sparse-mode in case of PIM-SM.

If this interface is supposed to be an egress interface for a multicast flow then the ip igmp join-group command is not really what you want: it causes the CPU of the router to subscribe to the particular multicast group by actually sending IGMP Membership Report through that interface, in addition to placing this inteface into the OIF list. If the interface is supposed to be simply a static egress interface for a particular multicast group then you should use the ip igmp static-group command instead.

The initial RPT PIM Join message appears to never leave the local router  and is dropped due to RPF failure. So the question here is, how is this  failing RPF? The tunnel interface is configured with a correct  multicast mapping for the hub using the physical endpoint address.

How do you know that the PIM Join message is dropped due to failing RPF check? The multicast mapping configured with the ip nhrp map multicast has no relation to RPF, by the way. RPF checks are influenced by the contents of the unicast routing table and by the static ip mroute commands but you indicate that you have used that command.

A couple of questions:

Have you configured ip multicast-routing?
Are you running PIM Sparse Mode on all appropriate interfaces including the mGRE interface? Does the show ip pim neighbor command show a successful neighborship with the DMVPN hub?
Have you configured the RP (Rendezvous Point) address appropriately? Does the route towards the RP point out the mGRE interface?

Best regards,

Peter

Jeremy Buck · ‎12-19-2012

Thanks Peter,

So to get the questions out of the way:

1) Yes

2) Yes

3) Yes

The join-group is applied to the LAN side interface of the spoke to force the router to join the group and emulate a connected receiver. The multicast source itself would be through the mGRE interface, hub, and connected to the RP on the wired side. Outside of our DMVPN environment this works perfectly, that is to say, the full sparse-mode process is succcessfull resulting in a wired client joining both the shared-tree on the RP and also having a full source-tree back towards the source.

Both the unicast routes and a static mroute on the spoke point to the hub over DMVPN interface.

The info about the static-group is appreciated, I will begin using that.

The reason why I believe the RPT PIM Join is never sent is this, if I clear the mroute and then initiate traffic from the spoke router (sourced from the LAN side interface but destined for the group) the process of sparse-mode should initialize and the first action would be to establish the shared-tree, unfortunately this never happens (the hub nor the RP receive the PIM Join over the mGRE interface). Instead, the very first packet is dropped as seen by the Other 1/1/0 "show ip mroute count" command. The situation is repeatable, any new group or any unestablished group will result in the first packet being dropped due to RPF failure. This is the item I don't understand, why doesn't the spoke send this join over the mGRE interface to the hub? Perhaps it is my testing method that is resulting in the PIM RPT Join being crafted incorrectly in which it cannot be forwarded out the mGRE interface. I am working to have a client added for testing.

I cross reference the same test with a multicast customer on the enterprise side (non-DMVPN) and the shared three is established with no problem, this is using the same join-group command on a LAN side interface.

To reiterate, the reason why I believe the issue is on the spoke is because of the initial packet under "Other 1/1/0" being dropped. There are no problems establishing the source tree.

The major over-arching problem here is, no DMVPN spoke is able to join the shared-tree on the RP. This means no DMVPN spoke sites can receive multicast from non-DMVPN (Enterprise) sites.

What can you recommend for debugs and troubleshooting commands so that I can verify the shared tree process?

Your help is appreciated.

Peter Koltl · ‎12-19-2012

For the router to join the shared tree, it needs at least one receiver (IGMP joined member) in that group.

For the router to join the source tree, it needs a sender's packet .The router needs the 'ip pim sparse-mode ' command to run PIM and IGMP on its interface. In case of sparse mode, on the first packet from the source it sends a PIM register (not a join) message to the RP to build the source tree.

If the shared tree and the source tree has overlaps or possible shortcuts (shunting the RP) an SPT switchover takes place and the tree will be modified to optimize traffic flow.

You should inspect

show ip igmp groups

show ip igmp membership

show ip mroute

http://www.cisco.com/en/US/partner/tech/tk828/technologies_tech_note09186a0080093f21.shtml#showipigmpgroups

Peter Paluch · ‎12-19-2012

Hi Jeremy,

Would you care posting the current sanitized running-config from your spoke router, including any show command outputs you currently deem interesting or important? Let's have some technical stuff to begin with.

Best regards,

Peter