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 known 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. 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 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?

And just in case you’re interested in slightly more scalable (but sometimes no less weird) DMVPN topics, check out my new DMVPN: the new features in IOS release 15 webinar (register here).

3 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.

    ReplyDelete
  2. Ivan Pepelnjak24 April, 2011 17:34

    Thanks for the feedback! It's nice to hear this thing actually works in a real-life network.

    ReplyDelete
  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.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.