We use packet brokers to capture data from optical taps, filter data for specific applications, decrypt SSL traffic and then send that traffic on to the AMD probes.
In order to ensure that the timing is as accurate as possible, I want to use the packet timestamp functionality in the packet brokers.
Can the AMD read these timestamps & use them as the operation time?
I've been assured by the packet broker vendor that other monitoring tool providers have implemented any changes required to read these timestamps with a short turnaround time for development work.
I believe the timestamp is appended to the packet, and CRC is re-calculated within the packet broker.
Isn't this when you forward the packets through a tunnel such as RSPAN or other?
When yuo capture in a TAP and go through a packet broker, there shouldn't be any header added or timestamp altered, which is really the point of a DAN.
Hello, the data is captured by the physical optical tap. It seems that the timestamp of the operation is when it arrives at the NIC on the AMD server?
I've seen operation start times that seem to indicate this, where for example
Server 1 > Server 2 > Server 3
I see the following time order
Server 1 00:01
Server 3 00:02
Server 2 00:03
This could be due to latency through the packet brokers, or more than likely - it's because there is queuing occurring on the AMD NIC, waiting for the packets. By adding the timestamp as close to source as possible, accuracy is greatly improved.
I guess it's not supported OOTB currently?
In what trace file do you see this?
If you refer to a trace file on the AMD , nothing should be added or changed. If you see a sequence of similar packets with small time difference, then most likely it's packets that just "bounce" in some interface or VLAN. It's crucial to understand how data flows when setting up the AMD. There is a deduplication mechanism in the AMD that should take care of most cases. Sometimes it's actually the most resource consuming process due to a bad setup of how the data/packets are directed to the AMD.
If your tap sits on a uplink between a distribution switch and a core switch then this is very likely to give effects like you describe. I would then advice you to use the deduplication mechanism in the packet broker rather than the AMD as the AMD should be busy decoding "real" traffic and not sorthing out duplicates.