Tracking udp stream
I have a third party handing off a gre tunnel,which they are fragmenting each packet at their router. Yes, known issue but that’s not the question I’m after here.
I’m then transiting through several hops to another vendor where we hand off. Streams are udp traffic. So luckily due to the fragmentation 😉 I can see the inner ip and udp headers. Which gives me a pseudo way to track a stream with the inner ip identification field, it’s consistent through a stream, as is the src and dst port numbers.
I realize it’s udp and by definition there’s no reliable way to track a stream but at the ingress port to my network and the egress from/to the above vendors I’m pretty confident I’m finding the same stream. Ingress capture might be udp stream 125 that matches up to udp stream 5 on the egress so I’m not just matching WS steam indexes. But what I can’t explain is that occasionally the ingress capture will have less packets. Sometimes one or two or as many as 50. In other words for a particular stream the vendor hands off, that ingress capture may show 140 packets in that udp stream. But I match it up to the egress stream and it has 150 packets.
Any ideas on the discrepancy? And yes I realize there’s the potential I’m not matching the same stream on two routers separated by several hops, but for the sake of argument let’s assume it is the same stream. Is the only possibility that I’m fragmenting and adding additional packets to the stream?
WSUG: 7.1. The “Follow TCP Stream” dialog box (diagram similar for Follow->UDP Stream)
Have you compared the data byte totals for the ingress and egress streams?
What capture mechanism are you using to capture packets? If it's a SPAN port, then the switch might not be mirroring all packets. You might want to read Jasper Bongertz's blog, "The Network Capture Playbook Part 4 – SPAN Port In-Depth" for more insight.
That's funny i stumbled on that blog last week. It's not exactly a span port, it's a packet capture utility on the web interface. Makes grabbing captures 100x easier. I think i discovered the issue. I did another capture, this time the egress side started and ended first...ingress side had more packets. Think it's more a function of the constant nature of this udp traffic, it's not stopping because i started/stopped a cap :) Thanks to a Cisco forum for pointing me in that direction...