IP Multicast in a VRF

Author
Peter Welcher
Architect, Operations Technical Advisor

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:

R2#ter len 0
R2#show run

hostname R2
ip routing
!
ip vrf v1
rd 1:1
!
ip multicast-routing vrf v1 distributed
!
interface GigabitEthernet0/1
! customer edge (PC)
!
interface GigabitEthernet0/2
! trunk to R1
port-type nni

switchport trunk allowed vlan 2-4
switchport mode trunk
!
interface Vlan1
ip vrf forwarding v1
ip address 10.1.3.1 255.255.255.0
ip pim sparse-mode
!
interface Vlan2
ip vrf forwarding v1
ip address 10.1.2.2 255.255.255.0
ip pim sparse-mode
!
!
router eigrp 1
!
address-family ipv4 vrf v1
autonomous-system 1
network 10.0.0.0
exit-address-family
!
ip pim vrf v1 autorp listener
no ip pim vrf v1 dm-fallback
ip pim vrf v1 spt-threshold infinity
!
ip msdp vrf v1 peer 10.1.2.1 connect-source Vlan2
ip msdp vrf v1 cache-sa-state
!
end

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

R1#ter len 0
R1#show run
!
hostname R1
ip routing
!
ip vrf v1
rd 1:1
!
ip multicast-routing vrf v1 distributed
!
interface GigabitEthernet0/1
! customer link (PC)
!
interface GigabitEthernet0/2
! trunk to R2
port-type nni
switchport trunk allowed vlan 2-4094
switchport mode trunk
!
interface GigabitEthernet0/3
port-type nni
no switchport
no ip address
!
interface Vlan1
ip vrf forwarding v1
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
!
interface Vlan2
ip vrf forwarding v1
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
!
router eigrp 1
!
address-family ipv4 vrf v1
autonomous-system 1
network 10.0.0.0
exit-address-family
!
ip pim vrf v1 autorp listener
no ip pim vrf v1 dm-fallback
ip pim vrf v1 spt-threshold infinity
!

ip pim vrf v1 send-rp-announce Vlan2 scope 16
ip pim vrf v1 send-rp-discovery Vlan2 scope 16
ip pim vrf v1 accept-register list ipmc-accept
!
ip msdp vrf v1 peer 10.1.2.2 connect-source Vlan2
ip msdp vrf v1 cache-sa-state
!
ip access-list extended ipmc-accept
permit ip any 239.1.0.0 0.0.255.255
deny   ip any any log
!
R1#

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.

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.