On 04/01/11 14:56, Jeff Bacon wrote:
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)
More or less. You can also define an "mdt data" group range. When
traffic for a particular (s,g) pair exceeds a configurable threshold, a
group is picked from this range and that (s,g) transitions to the new
group in the default VRF, and PEs with receivers join this group. This
means you don't flood high-bandwidth groups to every PE - just to PEs
which are interested.
- 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
As above, not necessarily to a single address.
It's also worth knowing that there's an evolved set of this called
mvpn-ng (not on Cisco IOS yet unfortunately) which dispenses with
various of the PIM-in-PIM layering. Since 6500/SXI doesn't support it,
I've never bothered to do more than read the RFC, but the terminology is
a lot more evolved and addresses some of the concerns like inter-AS and
such.
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.
You do have to setup PIM in the global space. However you can use
PIM-SSM meaning you don't need an RP, and never have any (*,g) joins,
because the source IP of the other PE(s) is known.
(There have been problems when using MPVN w/ SSM and interoperability
with JunOS in the past. as JunOS didn't support the "mdt" BGP AF used to
distribute the "mdt data" under newer IOS versions. My understanding was
that is now supported but I haven't looked into it, and solved the
problem by using ASM rather than SSM in the global space)
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.
I was under the impression that there's no recirc in this case, but I
could be wrong and can't find a reference.
As for MTU - if you're running MPLS you presumably have jumbos enabled
anyway?
Hence, don't do it if you don't have a really good reason to. I don't,
so I don't.
Well, the "good reason" for doing this is if you want multicast in MPLS
L3VPNs, surely ;o)
FWIW we run MVPN. It works fine, and after a bit of playing around to
understand it, I didn't find it massively confusing.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
