>> We had broadcast video teams internally years ago that would come to >> us with all kinds of similar 'small burp' problems, and blame the >> network for it. In 95% of cases, the problem turned out to be their >> equipment or applications doing it to themselves. Had nothing to do >> with the network at all. Hundreds of hours were sunk proving that. >>
>The flip side to that, though, is the 5% of the time when it turns out to be >misunderstood queue handling on a particular type of linecard when it is >configured with non-default queue parameters and microbursts hit the linecard >buffers...and after hundreds of hours of debugging, it really does turn out to >be a network problem. The customer always >remembers that 5%, and comes back >wagging the finger at the network for every hiccup, conveniently forgetting >the other 95% of the times when it wasn't the >network. ^_^;; Reminds me of one time long ago at an MSP - I identified a faulty Verizon line card in a router hop. One office that was being supported was having issues with youtube videos playing, but no one else was complaining, so we checked with all the other sites/clients we supported.... And found two more with faulting issues. Between all of them, Verizon's business support actually doing their job, and the traceroutes pointing to a specific router hostname in common, they were able to have someone determine that - yes - that line card that was part of the hostname apparently, was faulty and causing the issue. These were all DSL circuits, all in a nearby geographical region. That was quite an interesting diagnosis, going back and forth with VZ until I could throw the commonalities at them. And the only noticeable problem (that we ever knew of) was failure of youtube videos to play properly. On the surface, without that, everything seemed 100% okay. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/OWDFCKJMIF7JZGK7RQRME27NLTCE3ASH/
