Tracking a UDP stream

[wwwlstr0707]

I’m tracking a UDP stream through multiple devices. It’s difficult obviously, all the reliable metrics that tcp uses don’t exist. So I’m looking at the source/destination port numbers and the inner IP identification field, it’s a gre tunnel.

I have a capture pulled from the ingress interface of this traffic, and the egress interface of the other router. The ingress cap started a few seconds before the egress, so what may be upd stream id 125 on the ingress side may be udp stream id 5 on the egress. I’m pretty positive I’m catching the same stream through the network. 
The problem I’m seeing is the number of packets in the stream doesn’t always match. In the above example the ingress cap may have 150 packets but the corresponding egress cap 155. 

Any thoughts on the discrepancy?

thanks. 

[Flavio Miranda · Accepted solution]

@wwwlstr0707 

Small difference would be expected. UDP as connectionless protocol dont care about Lost packet and will keep sending traffic dont matter what. 

Now, figure out why some packets is dropped in the path between Router can be difficult.

[wwwlstr0707]

Good point. The first capture stopped a few seconds before the second so the flow just kept going. 

[M02@rt37]

Hello @wwwlstr0707 

The packet count discrepancy between the ingress and egress captures could be attributed to several factors related to GRE tunneling and UDP stream behavior...

One common reason is fragmentation. When UDP packets are encapsulated within a GRE tunnel, the added headers may exceed the MTU of the underlying network, causing the encapsulated packets to be fragmented into smaller pieces. This can lead to an increased packet count on the egress side compared to the ingress, where packets were still unfragmented.

--To confirm this, you can analyze the egress capture for IP fragmentation headers and compare the total payload sizes in both captures to ensure they match.

Another potential issue is duplicate packets. Network devices might introduce duplicate packets during retransmissions or as a result of misconfigurations in the GRE tunnel. These duplicates would increase the packet count on the egress side. Examining timestamps, sequence numbers, and inner IP identification fields in the egress capture can help identify duplicates...

Similarly, packet loss or missed packets in the ingress capture could create a mismatch. Hardware or software limitations during the capture process might lead to dropped packets, making it appear as though fewer packets were sent than received.

GRE tunnel processing itself could also be a factor. Certain implementations might modify the encapsulated packets, such as splitting or combining payloads, or introducing control traffic into the tunnel. This could result in a different number of packets on the egress side. Additionally, packet reordering within the tunnel could make it challenging to match packets between captures.

So, checking timestamps and reassembling the packet sequence can help determine whether reordering is contributing to the discrepancy.

Finally, network asymmetry or capture timing could play a role. If the ingress and egress captures are not perfectly synchronized, or if traffic takes an asymmetric path, some packets might bypass the capture points, leading to mismatched counts. Ensuring your captures cover the entire path and are accurately synchronized is critical. By investigating these factors—fragmentation, duplication, packet loss, GRE processing, and network asymmetry—you can identify the root cause of the packet count difference in your UDP stream analysis.

[MHM Cisco World]

This is  VoIP stream ?

The hops can change Mac add IP header but not change the stream id. 

Also why you not capture traffic in each hops' capture traffic end to end not give you anything.

MHM