Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Understanding Multicast Route Leaking for VRF and Virtual Router Instances

Service providers use Layer 3 VPNs to keep traffic separate and private for multiple customers. To separate a VPN’s routes from routes in the public Internet or those in other VPNs, provider devices maintain separate routing tables (called VRF tables) for each VPN that connects to a customer edge device. Devices supporting customers or sites that belong to the VPN can access only the routes in the VRF tables for that VPN.

However, providers might need to share services with more than one customer or site while keeping general services private among their customers. Providers can achieve this by making some routes available in the routing tables for particular customer VRF or virtual router instances. This practice is called route leaking, which enables a device to share route information from one configured VRF or virtual router routing instance to another using internal route export and import policies.

Providers might also want to use route leaking for multicast services such as IPTV and other streaming media services.

Static Multicast VRF Route Leaking Implementation on Switches

On Junos OS switches, the multicast VRF route leaking implementation enables you to statically share multicast routes from a Layer 3 VPN routing instance running a multicast protocol such as Protocol Independent Multicast (PIM) with customer virtual router or VRF instances. You can leak only static multicast routes with a prefix length of /32. Therefore, routes are shared for Internet Group Management Protocol (IGMP) groups and not for a specific source. All Layer 2 and Layer 3 interfaces must have IGMP version 3 enabled. No other version of IGMP is supported.

Additionally, you must configure an integrated routing and bridging (IRB) interface for each Layer 3 interface. To ensure that the multicast static routes are present in the routing instance that is running multicast, use IGMP to add the routes to each IRB interface configured in the routing instance. Include the group multicast-group-address source ip-address statements at the [edit protocols igmp interface irb-interface-name static] hierarchy level.

Note:

For multicast route leaking to work robustly, you must also configure Protocol-Independent Multicast (PIM) on each IRB interface included in the virtual router or VRF instance.

  • For example, to add the IRB interface, irb.1023, to a routing instance named cust-11 and enable PIM on the IRB interface:

This implementation also requires you to enable IGMP snooping on all customer interfaces receiving multicast traffic. Use the multicast-router-interface statement to configure each customer interface to face the multicast routing instance. You must also add each multicast group to each customer interface by including the group multicast-group-address statement at the [edit protocols igmp-snooping vlan vlan-id interface interface-name] hierarchy level. The customer VRF or virtual router instances are not required to have a multicast protocol such as PIM configured.

To enable multicast route leaking, configure static multicast routes in a customer VRF or virtual router instance for each configured multicast group and point each route to the routing table for the multicast routing instance. To configure, include the static route destination-prefix/32 next-table instance-name.inet.0 group of statements at the [edit routing-instances routing-instance-name routing-options] hierarchy level.

For example, to leak multicast route 233.252.0.0/32 to a customer routing instance named cust-11:

In this example, the static multicast route is configured on the customer routing instance and points to the routing table for the multicast routing instance, HQ. This configuration ensures that multicast traffic is forwarded.

Related Documentation