IP Multicast in a VRF

I’ve been working with two customers that I’d describe as “rural fiber network providers”. For background info, see the blog about Rural Fiber Networking. As I noted there, one of my customers had the need for some IP multicast (IPmc) within a VRF, initially at least, to support IP telephony. Since it is a school system, I have a suspicion multicast “channels” of video might be lurking in their future.

The basic approach was to build a small fiber network to service a small number of customers or different applications using VRF Lite. Our Carole Warner Reece wrote a technical blog relating to one, with some configuration snippets, in Using VRF-Lite, EIGRP, and Static Routesw.

I built a small lab configuration of two ME 3400 12 CS switches to verify proper IPmc configuration and operation within a VRF. (Thanks to Brian and BCC for the opportunity to do this!)

I also spent some time at the site going over how IP multicast works, and show commands and how to maintain it. That’s where I’d like to think I (we) add some extra value. Actual IPmc-in-VRF deployment was simple. It’s the troubleshooting and understanding part that’s harder. And determining the best answer for some of the design / deployment choices.

(Multicast and QoS both require attention to detail in rollout. For multicast, the actual configuration is relatively simple. For QoS the configuration is messy, and requires a lot of care in deployment, also verification before deployment since it is really easy to miss ports used by actual applications, IP PBXs, etc. — they tend not to document them well. With QoS, the biggest problem is making sure its really working the way you think it is — by checking those somewhat invisible DSCP markings.)

Here is a diagram of the lab layout (pretty simple):

In the lab, router R1 was the PIM Sparse Mode Rendezvous Point. R2 was the other router. User sites were simulated with VLAN 1 on each end, and VLAN 2 across a trunk cable between the routers was the backbone network. Both routers were in principle Provider Edge (PE) devices — with VRF Lite there is no separate Provider-only (P) core. PC’s directly connected — we did not simulate Customer Edge routers, since they just run ordinary multicast — same commands, omit the VRF part. In some cases the CE was just a stack of Dell or other vanilla one-VLAN switches. (Not necessarily a recommended design, but cheap, and what was in place.)

The ME 3400’s were preconfigured with the exec mode command “sdm prefer default”, and rebooted, to get the routing template in place. Otherwise, routing performance can be pretty awful.

So Show Me the Configs!

Here are selected configuration snippets relating to IPmc in a VRF.

R2 (the non-RP router) first:

Here’s the relevant parts of the configuration for R2:

Here’s the IPmc and routing related configuration for R1 (the RP):

Explanation and Comments

If you’re doing one of these VRF Lite on switch designs, you can’t use routed subinterfaces. When using VLANs on trunks, you have to prevent “VLAN leakage” by carefully pruning each trunk to localize the VLANs crossing it to just that trunk. Otherwise you create one big spanning tree domain, which somewhat defeats the whole point of having a routed approach for stability.

I configured MSDP to see if Anycast RP was a possibility (using loopbacks within the VRF’s), despite R2 not being set up as an RP. It worked! (Didn’t test it in the lab, but highly recommend it for Highly Available RP’s. And it’s sort of fun deliberately having duplicate IP addresses — although you do have to be careful they don’t become router ID’s for the IGP routing protocol!)

The approach uses AutoRP. In a VRF, of course.

I show the accept-register commands. They didn’t work in the lab, since the RP happened to also be the router the IPmc source was connected to.

Summary

Cisco did a great job with the syntax for this! Just stick “vrf ” in the right place in all your favorite IPmc commands.