Spoke-to-Spoke IP Multicast over DMVPN?

A long-time reader has sent me an intriguing question: “would IP multicast work between DMVPN spokes?” In theory, the answer is “we could make it work”, but we all know theory and practice are not the same thing.

To make IP multicast work between DMVPN spokes, you’d need to configure multicast propagation between them with the ip nhrp map multicast remote-spoke-NBMA command. In a small DMVPN network where you need IP multicast only between a handful of spokes, that might even work; obviously this trick does not scale for a number of reasons:

  • Full-mesh manual configuration of multicast maps is required on spoke routers;
  • You’d have to change configurations on many spoke routers every time you add a spoke router;
  • Spoke NBMA (public-facing) addresses would have to be fixed. No more DHCP-addressed CPE devices.
  • Having a tool that would ensure you actually have a full-mesh configured would be extremely handy (hint: configuration automation). Missing multicast maps would be extremely fun to troubleshoot (not to mention the obvious increase in your job security);
  • The multicast maps would cause spoke-to-spoke IPsec sessions to be established immediately, resulting in a full mesh of IPsec sessions;
  • Multicast replication on spoke routers might become a (CPU) problem if you use low-end platforms as spoke routers;
  • Routing protocol updates would be sent over all those multicast maps, resulting in even more work for the spoke routers.

Obviously this “solution” belongs to the “just because you could doesn’t mean that you should” department, but sometimes we’re forced to do weird things to implement something our design was never meant to support. Did you ever have to deploy IP multicast over DMVPN? What’s your experience?

5 comments:

  1. I put together a configuration using dmvpn to get around a service provider not supporting multicast over their MPLA core. As you said above spoke-to-spoke is not really possible without multicast maps. I was lucky in my case as this was for a MoH source and there was only two potential sources. These were hubs with pim adjacencies to the rest of the spokes.

    I was playing around with pim nbma mode which worked nicely user 12.4T but behaved differently under 15T, how I have yet to investigate.

    I was hoping with pima nbma mode it would act in a similar fasion as ospf in point to point mode by having the hub as a point of replication for other spokes, but no dice.
    Even though each neighbor was individually listed in the OIL, replication only was to members on others on alternate interfaces in the OIL.
  2. Thanks for the feedback! It's nice to hear this thing actually works in a real-life network.
  3. Ivan, can you post the complete configuration of the devices because i still have problem multicasting from hub-to-spoke and spoke-to-spoke. to enable spoke-to-spoke multicast beside configure ip nhrp map multicast remote-spoke-nbma-add, what else should i configure? how about the RPF check if im using pim sparse-dense-mode or pim sparse-mode? hope that there will be a solution soon. many thanks.
  4. I have done this but not as you have explained. I did rollback to DMVPN Phase 1 without dynamic spoke-to-spoke tunnels. That way it works too.
  5. I'm wondering if with SDWAN/Overlay Orchestrator solutions, we can now make this work in a scalable way ?
Add comment
Sidebar