> > The multicast I want to keep in global - yes you can do > > multicast VRFs, but I had a long chat with someone from > > LAN Switching TAC in RTP a while back and one of my > > takeaways was an emphatic "don't do this if you don't > > have to". > > Different from what you initially wanted to know, and a bit > late in responding, but I'm curious why Multicast is > recommended to run in the global routing table. > > How do you handle situations where your customers (the > Multicast source) are using the same Multicast group > address(es)?
Well, first off, I don't have customers. So I can't answer that part. :) It has more to do with how multicast MPLS is implemented - to oversimplify (and someone correct me if I'm missing something), the model is: - you define a single mcast addr in global which carries all the mcast for the VRF (it might be possible to map to multiple addrs to break it out some based on what your subscrip pattern might be) - various hooks are shoved in to transport and handle PIM and mroutes on a per-VRF basis OOB - mcast within the VRF is GRE-encap'ed then transported over the single mcast addr to the dest I'm sure it works, though I haven't tried it. But it means you have mcast (in global) carrying GRE-encap mcast for the VRFs floating around your net. I think you have to set up PIM in global to carry the transport groups. Merely thinking about trying to manage/debug that makes my head hurt. Plus, GRE encap with MPLS means a recirc through the EARL so you pay the latency penalty twice plus the extra load. And you need jumbo frames to encap at full standard 1500 MTU. Hence, don't do it if you don't have a really good reason to. I don't, so I don't. -bacon _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
