said by jig:sorry, do we know that the data packet is dropped?
We don't. I'm going purely off of
the information provided here, which looks more like it comes from a torrent client than Ethereal/tcpdump/snoop.
said by jig:also, as you've drawn the diagram, there's no way that the juniper box would see sandvine packets anywhere near the time customer packets would arrive from the switch, unless there was a purposeful delay thrown in (each interface at Gige speeds has at least a 1ms latency add-on).
This is true. I did consider this when drawing the diagram, but I wasn't sure of the implications. I indirectly touched based on this with question #1.
You're right though.
said by jig:anyway, another approach would be to use the mirror port data to determine which IPs are sending p2p data, then splitting that data off the trunk at some early point (some switches can tag packets making routing easy later on) and running it inline through sandvine hardware. that's one way to segment off the unwanted traffic.
QoS tagging comes to mind (absolutely 100% sure a switch can do this). There's definitely more than one way to accomplish this of course.
said by jig:but really, i think they're just sending rst's without blocking data packets. the rst reaches the data packet sender before a response from the receiver can turn around...
I was going solely off of the information provided in the thread.
It makes much more sense to simply inject RST and not bother with dropping/denying subsequent packets. I'd have to confirm that, though. Running Ethereal on either end of the connection should suffice. I'll do this myself either later tonight or tomorrow and report back.