On 06/01/11 13:15, Jeff Bacon wrote:
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.
I just noticed this in SXI (only just getting there - I'm trying to read
through the release notes during morning exercise... could take weeks :(
).
This however frightens me, because during that transition it seems as
though you're bound to drop a packet somewhere. It's ok if you're IPTV
or some other multimedia streaming, but for financial market data that's
a no-no of highest order.
Very probably. However this ought to only be an issue for streams where
listeners are leaving and joining, or the bit-rate is changing to go
above & below the threshold.
(It's worth noting the threshold detection is a bit sluggish as well -
on the order of tens of seconds)
Obviously it's not optimal in all conditions.
As for MTU - if you're running MPLS you presumably have jumbos enabled
anyway?
Doesn't mean your WAN provider gave you enough MTU to fit both headers,
though. (One provider I work with has all long-haul capped at 1546,
presumably a holdover from fast-enet days)
True. There are other non-MPLS multicast MTU issues though; we've had
problems with PIM registered between JunOS and IOS, where IOS fragments
the inner packet, JunOS the final outer PIM register.
My rule of thumb based on experience here is that multicast with >1400
byte packets is a grey area.
Is MVR any use to you? We're investigating a hybrid approach where
certain multicast groups are distributed in the a multicast VLAN using
MVR and access-lists. This multicast VLAN can then be in the default
VRF. There are implications for bidirectional traffic of course, due to
the RPF check...
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
