Finding and matching UDP packets is often more difficult than doing the same for TCP packets, simply because there is no “conversation” going on. It’s not possible to say which of both is easier to achieve since both can get pretty complex. Depending on the problem situation this usually means either to find matching packets and conversations at each location, or determining where the differences are. Old school ftw! 😉 Comparing capturesĪfter recording the packets the task at hand is to compare the capture files. Using SPAN is really only good for application behavior tracking, and when you really do not care about network/packet transmission characteristics. Quick reminder: situations like the three mentioned above will most likely require the use of network TAPs to exclude packet loss/timing issues caused by SPAN ports. when you capture at a client and at a server (and have enough TAPs and capture devices, of course). One of the problems is to select the correct capture locations, but let’s assume we got that covered for the sake of the length of this post. determining if all conversations look the same on both (or more) capture locations.checking if there is packet loss, checksum errors (which is basically leading to packet loss, too) or any unwanted packet modification “on the way”.having to determine if packets get delayed at some point in the network (this would be one of the few cases where “it IS the network”).
Some reasons for such multi-point captures include Every now and then most analysts run into a troubleshooting situations where they need to capture the same packets at different locations in the network.
0 kommentar(er)
