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.

[balaji.bandi]

is that your Tunnel config Trimmed ? can you post full configuration to look. ?

Do you have Tunnel UP between Hub and Spoke ?

[Mike Buyarski]

Yes the tunnel is up and connected. Attached is the full tunnel config.

[grabonlee]

Hi,

I assume that your multicast source is behind the Hub. There are some config errors on both your Hub and Spoke:

Hub

====

1. ip split-horizon eigrp 10 . Negate this command

Spoke

===

1. ip split-horizon eigrp 10 . Negate this command

2. no ip nhrp map multicast dynamic . This should be enabled with ip nhrp map multicast dynamic

After making these changes, could you post the sh ip mroute for the multicast group.

[Mike Buyarski]

yes the multicast source is behind the hub router. i attached the updates to the tunnel and results of the mroute command.

[grabonlee]

From the mroute output, it seems that you don't have an RP address configured (Static or Auto-RP). Sparse-Dense mode doesn't mean that Dense mode works automatically. PIM sparse-dense mode will fall back to dense mode but fallback happens only happens after the RP has been queried. Without an RP it doesn't work.

You can do a sh ip pim rp mapping to verify

You should configure Auto-RP on the Hub, preferably with loopback address. For example,

config#ip pim send-rp-announce loopback 0 scope 5

config#ip pim send-rp-discovery loopback 0 scope 5

If a group doesn't have a static rp-mapping, then 224.1.0.40 is used by the Hub to share the group mapping information with Dense Mode. In your case I don't think there's an Auto-RP config.

I would've expected to see a shared tree on the Hub (*, 224.0.0.40) and a Source Tree (RP_Address, 224.0.0.40), and should appear same on the Spoke.

[Mike Buyarski]

could i just add the line "ip pim autorp" on the hub?

[grabonlee]

Applying only ip pim autorp won't work. Auto-RP requires a Candidate RP and a Mapping Agent and that's why the commands;

ip pim send-rp-announce LoopbackX scope y  and ip pim send-rp-discovery LoopbackX scope y are required.

It depends how you want to design your Multicast environment. The Router closest to the Multicast Source can be the Mapping Agent and have the ip pim send-rp-discovery LoopbackX scope 5 command while the Hub can be the Candidate RP and have the announce command. You can also choose to have the HUB as both Mapping Agent and Candidate RP. The choice is yours.

Note that the Loopback must also be configured as Sparse mode or Sparse-dense mode.

[Mike Buyarski]

so far it does not seem to be working yet.

I added in the ip pim send-rp-discovery Loopback0 scope 5 to the spoke.

and ip pim send-rp-announce Loopback0 scope 5 and ip pim send-rp-discovery Loopback0 scope 5 to the hub, which is also closest to the multicast source.

it does not appear to be working yet. attached is the result of a "sh ip mroute"

[grabonlee]

---

@Mike Buyarski wrote:

so far it does not seem to be working yet.

I added in the ip pim send-rp-discovery Loopback0 scope 5 to the spoke.

and ip pim send-rp-announce Loopback0 scope 5 and ip pim send-rp-discovery Loopback0 scope 5 to the hub, which is also closest to the multicast source.

it does not appear to be working yet. attached is the result of a "sh ip mroute"

---

You may have misunderstood me.

ip pim send-rp-discovery Loopback0 scope 5 is not required on Spoke. Please remove it. RP-discovery message is used by the Mapping Agent to send information of the RP to the rest of PIM domain. In this case, the Hub is both RP-Candidate and Mapping Agent.

This is why below shows up in your sh ip mroute:

 ("loopback_spoke", 224.0.1.40), 00:30:16/00:02:30, flags: LT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:00:23/stopped, A

Also I specified scope 5 as a example. It is a TTL value, which helps limit the extent of the RP-Discovery message. Depending on the network size, it may be higher or lower.

This is also very important: ip pim autorp listener command that you mentioned earlier is only required in a PIM network with Sparse-Mode interfaces only, and all routers in the PIM domain would need that command configured. 

I personally wouldn't advise use SM-DM, but only SM, but that is a different conversation.

In your mroute log, I noticed some things wrong. For example, I would expect the shared tree for your multicast group to have the OIL towards the source, but I see it towards the Tunnel. This makes me wonder if you also have a Spoke router acting as RP.

(*, 239.255.255.253), 00:07:51/00:02:32, RP 192.168.252.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, 10.254.4.12, Forward/Sparse-Dense

I would also have expected to see a (S,G) on the Hub with the IIL of the Tunnel interface, but I see none and OIL towards the Multicast group source. For example,

(10.1.10.1, 239.255.255.250), 00:01:12/00:01:47, flags: T
Incoming interface: GigabitEthernet0/0/1.1

Please check your Multicast configs again and also remove the RP-discovery from the Spoke.

When done, post the following from both Hub and Spoke:

1. sh ip pim neighbor

2. sh ip pim rp mapping

3. sh ip mroute multicast_group

4. A diagram of your network showing where the Source and Receivers are and location of the RP. 

[Mike Buyarski]

I removed the discovery from the spoke, so far no luck.

i found getting multicast working through the core switch inter-vlan only seemed to work under sparse-dense mode. that's why i picked it.

Anyways attached is the results of the show commands.

[grabonlee]

Hello,

the output of sh ip mroute I wanted was for the multicast group that you have an issue with, i.e. the group that the Cisco phones are requesting the multicast traffic.

Let us recap before you send the logs:

1. Hub loopback is in Sparse mode. Can be in SD, but is not necessary.

2. TTL scope is 255, as multicast traffic isn't traversing within site and subnet

3. All interfaces along the L3 devices path the multicast traffic is expected to flow from interface facing the Source to last hop interface facing the Receiver are in Sparse-Dense mode.

In addition, could you post the following logs:

1. sh ip igmp group all multicast enabled devices between source and receiver

2. debug ip igmp on the Spoke router

3. debug ip mpacket multicast_group on both Hub and Spoke.`

Thanks

[Mike Buyarski]

ok so i found that multicasting internal on the main network stopped working. i and found it started working again after i removed the "ip pim send-rp-announce Loopback0 scope 255" command from the vpn router. i also found the alert is not activating the speaker phone but using whatever the user used last on the phone so either headset or handset. so i have to do more testing to see if it is working at the remote site and just not activating the speakerphone.

[grabonlee]

the scope keyword and ttl-value argument is used to specify the Time-to-Live (TTL) value in the IP header of Auto-RP discovery messages. Which effectively means number of Hops. If 255 is breaking your multicast network, then that means messages are going round and round with no end in your network and indicates a loop.

Where you able to get the logs I asked for? 

[Mike Buyarski]

so attached is the logs you asked for. most of the IP listed do not have anything to do with the multicast source and/or destination, thats why i kept them. But i did point out the IP's of the spoke or hub router.