[c-nsp] CEF and multicast on a 3750

[John Gill]

Luckily, buffering issues are easy to check.  Look for output drops in 
"show interface" as well as "sh plat port-asic stats drop gi x/y/z"

Don't forget, as some others have touched on, state changes.  If TCNs 
occur, we fast-age mac addresses - including IGMP-learned.

Who is the mrouter/querier?  Does this device always have igmp/mrouter 
state?  IGMP join/leave activity should be investigated.

It's an important distinction to see if you are missing traffic on all 
receivers, or a subset.

Regards,
John Gill
cisco



On 6/26/12 11:31 AM, Gert Doering wrote:
> Hi,
>
> On Tue, Jun 26, 2012 at 09:07:32AM -0600, John Neiberger wrote:
>> These are extremely expensive real-time video encoders taking in
>> baseband video and outputting multicast MPEG at a constant bit rate
>> for customer-facing video feeds. Any pauses would be unacceptable, as
>> are dropped packets, unfortunately for this site.  hehe
>
> Bit rate is never "constant".  It's always "constant if averaged over
> a certain time window".
>
> If you send 20 packets per second, and send them in bursts of 20 packets
> and then 0.99s of silence, you are *still* sending a "constant bit rate
> of 20 packets per second", if averaged over a time window of 5 seconds.
>
> Unless you are really sure (by having done a wireshark / tcpdump dump
> with time stamps directly on the encoder port, with no other gear in
> between) that packets are space out evenly, with only one packet ever
> sent per burst, and then a delay that's the same for every packet, do
> not assume that "constant bit rate" is really non-bursty at the microsecond
> level.
>
> We've learned this the hard way with our audio streaming setup - some
> streaming server software is quite good at pacing the packets (windows
> media server), some is particularily bursty (icecast, if I remember
> right).  Of course I do not know the application that you're using, just
> trying to break some "it can not be this!" assumptions.
>
>> I'm engaging our Cisco team on this to have them investigate queueing
>> and buffer issues. I don't think they've looked at that yet.
>
> "We do not have buffer issues in these switches!  They do not HAVE
> enough buffers to have issues with them!"
>
> gert
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>