Showing results for 
Search instead for 
Did you mean: 

VSS with VRF and Multicast on different VRF

Hi to all , i have a very interesting scenario, but it's not working... :-((( I had setup a VSS lab and configured on it MPLS. The import/export route it's working like as expected as a charm.The problem is the multicast setup, i have 2 video server suited in two different VRF (Videosrv1 (vlan40) and Videosrv2 (Vlan50)) , and some client in another vrf (Videoclient (vlan60)).Now the request is that the clients on vrf Videoclient should be able to see multicast streaming from both videoservers VRFs. This is not working... The only thing working is if i put the client on the same vlan of the video server, but this is igmp snooping working , not multicast . I tried also to add another interface to Videosrv1 VRF (Vlan 45), and put the client on that interface, so the client and the videoserver are on the same vrf but not on the same vlan, but even this is not working.On the sh ip mroute vrf Videosrv1 i can see the multicast source as * , G , but the aren't outgoing interface.In attach you can find a powerpoint structure of the lab and the relevant part of the configuration, note i'm using 12.2(33)SXI2a , any idea ?

Many thanks in advance for any help,


Giuseppe Larosa
Hall of Fame Master

Hello Max,

you are trying to configure a multicast VPN extranet.

I think that something is missing in your VRF configuration for the multicast part.

You should configure MDT for each VRF.

see the following document

Hope to help


thanks for the help, but i don't need to tunnel multicast inside an MPLS cloud, i need only to mroute multicast between different vrf on the same chassis.moreover , for this to work , as i understand you need source and receiver on the same vrf (green as an example) and then the stream are replicated on the second (or third) vrf. In my case i have two different source in two different vrf , and the receivers are in another vrf, and all are on the same chassis... I really don't know if there 's a solution, it's a challenge. This works with a 12.4T on gns with 7200 emulation, but the same configuration doesn't work on VSS setup... :-(((

Hello Max,

I understand that all is confined in a single chassis.

However, something is needed or you have posted only part of interesting configuration.

I think two possible approaches are:


use same mdt default Group

on all VRFs


ip mroute vrf vrf-name source-address mask fallback-lookup {global | vrf vrf-name} [distance]

to pass RPF check


a possible different approach could be that of finding a way to redistribute in BGP multiprotocol in the appropriate address families if any.

newer mdt address-family can be used with an external route-reflector.

Hope to help


I tried with the same MDT group in all the VRF , but it didn't works, the ios told me there's an overlap on mdt address. I tried with different MDT address on the different VRF, but also this didn't works.I tried adding also the static mroute, but the problem is not the RPF check, i'm not able even to see the *,G on mroute table...Has Anyone an idea ?


I have gone through the config and i really don't understand why are u configuring pim dense-mode on Vlan45. U need to use same MDT on all vrfs. And one more thing is that the RP should be accessible from the Videoclient . Thats what i have been able to figure out. Try if ur getting mroutes with this changes.



this was an old config, the actual config is in attach.On vlan 45 is now configured pim sparse-mode, i tried to configure the same MDT group on all VRFs, but ios told me is not possible because this is an overlap, i think every different VRF need a different MDT group , and the RP is accessible from videoclient, 'cause it's imported as a route by route-target import throught BGP.But nothing of this works... :-(

Would you mind sharing the resolution for this one if you have found? I am in the planning and designing stage of an MPLS network which proabbly will require multicast routing. All our P and PE devices are VSS and thinking of any gotachas that may exist for the MVPNs in this scenario.