Chesapeake NetCraftsmen

I've been working with two customers that I'd describe as "rural fiber network providers". For background info, see http://www.netcraftsmen.net/resources/blogs/rural-fiber-networking.html. 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 http://www.netcraftsmen.net/resources/blogs/vrf-lite-eigrp-and-static-routes.html.

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.

Comments (2)

Subscribe to this comment's feed

Configuration multicast avec vrf sans activé le mpls
written by EKOUNGOULOU, April 11, 2011

Bonjour,
j'ai un problème, j'ai activé le multicast et les vrf sur trois PE avec le protocole de routage dynamyque ospf. sur les CE, j'ai activé: le routage statique par defaul le multicast sauf les vrf. Quand je fais sh ip route vrf nom; j'ai les routes. Pour faire un ping vers les réseaux LAN sa ne fonne pas. Par contre sur le backbone entre les PE le ping fonctionne sans problème.

• 
• +0
• 
• 

Followup to EKOUNGOULOU
written by Pete Welcher, April 11, 2011

Google translated that as the following (with a little cleanup by me, my French is thin):

I have a problem, I enabled and multicast vrf three PE's with dynamic OSPF routing protocol on the CE. I activated the static default route with multicast vrf. When I do sh ip route vrf name and I have the routes. To make a ping to the LAN's does not work. By contrast, on the backbone between PE ping works without problems.

Response:

What is the source of your ping? If you are pinging the LAN from the PE, you need "ping vrf IP" to ping within the VRF context.

Also: does CE to different CE ping work? If so, you've got pretty good connectivity for unicast.

Check the VRF unicast routing table. If the connected links from PE to CE are not in the VRF routing table, your CE to CE ping will not work.

If you want, email me ( This e-mail address is being protected from spambots. You need JavaScript enabled to view it ) and we can sort your problem out privately.

• 
• +0
• 
• 

Name

Email

Title

Comment

smaller | bigger

Subscribe via email (registered users only)

I have read and agree to the Terms of Usage.

Add Comment