IP Multicast routing through DMVPN

[Mike Buyarski]

i am trying to get ip multicast working through a DMVPN this is for paging to the phone via Cisco informcast paging. right now i am pretty sure the issue is with the multicasting

First the routers

hub router: cisco 4331 running IOS-XE version  16.6.3

Spoke router: Cisco 4321 running IOS-XE version 16.8.2

I did get ip multicasting working through our core layer 3 switch and can page at the corporate network. Phones are not on the same vlan as the call manager servers or informcast server.

On the core switch i just have:

IP multicast routing and ip pim sparse-dense-mode on each vlan needed including the vlan that the HUB router is connected to, and confirmed multicasting is working to that vlan.

I added a text document to give a better outline on what configs i have on each the hub and spoke router for multicasting.

[grabonlee]

Hi,

From the latest attached logs, I saw the statement below and didn't bother to go through the logs.

///////////////care switch seconday///////////////// <---even though this is a layer 3 switch i do not have ip multicast rounting enabled.

Let me explain:

Your topology is described as shown below from your post:

////////////low level of how its source and receivers are///////////////////////
Multicast source-->Core switch1 Main--->Core switch2 secondary--->Hub router--->Internet(DMVPN connecting location)--->Spoke Router--->layer2 switch--->Number of IP phones.

If Core_Switch2, which is between Core_Switch1 and the Hub router, doesn't have multicast routing enabled, how then would multicast packets get to and from the source?

The essence of PIM is to enable Source and Receiver to communicate if they aren't on directly attached LAN. If they're on directly attached LAN, then igmp snooping would suffice.

So for PIM to work, all routing interfaces between the source and the destination must have multicast routing enabled and a PIM mode.

Since debug ip mpacket doesn't work, then use debug ip mfib mpak. That should give same results.

Meanwhile you haven't confirmed what Multicast group you're concerned about. Is it 239.0.0.2?

[Mike Buyarski]

There is one thing i should mention with the secondary switch, between the core main and the hub vpn is still on the same vlan. while yes the core secondary is in between them its still only a layer2 connection between them, there is no inter-vlan routing going on between the core main and DMVPN hub.

[grabonlee]

Hi,

On your Core secondary switch, you have a PIM mode enabled, right? Once you have PIM enabled, then you must have IP multicast routing. If you want it to be purely Layer 2, then no PIM mode should be enabled.

Meanwhile, if you don't confirm what Multicast group that we're looking at, it's difficult to provide any help. For example, in your debug ip igmp on the Spoke, I see an IGMP join for 239.0.0.0.2, but none of your IGMP interfaces from Core_Main down to the Spoke have any mapping for 239.0.0.2. So if the First Hop Router (Core_Main) isn't aware of 239.0.0.2, how then would the branch router see any traffic from that group?

Were able to get a debug ip mfib mpak from the Hub and Spoke routers and could you also get the debug ip igmp from the Core switch. Please state what multicast group is of concern.

Thanks

[Georg Pauwen]

Hello,

in addition to the other posts, on the spoke router(s), try and replace:

tunnel mode gre multipoint

with

tunnel destionation x.x.x.x

and add

ip nhrp server-only

to the spoke tunnel(s).

[Mike Buyarski]

the spokes have two dmvpn tunnels would that affect the second tunnel if i am only putting it on the tun0?

[grabonlee]

If you apply tunnel destination x.x.x.x, then you effectively are using DMVPN phase 1. As you have 1 tunnel to 2 Hubs, then you need the GRE multipoint. This also ensures that Spoke-to-Spoke communication is supported, if you have Shortcut(Spoke) and Redirect(Hub) configured.