A Net-Tracer is a synthetic test that provides end-to-end and hop-by-hop network performance analysis:
- Network path visualization graph
- Local node level metrics: link delay and packet loss
- Path level metrics: round trip delay, packet loss and path length
As explained below, the Net-Tracer can be configured to use the following types of packets (methods):
- UDP packets
- TCP SYN packets
- TCP/ACK packets
- ICMP packets
In order to compute valid end-to-end performance data (network latency and packet loss), the target you configure in the Net-Tracer configuration:
- should not listen to the following UDP ports range (33.435 - 33.535) - only for UDP-based Net-Tracers
- should not listen to the following TCP ports range (33.435 - 33.535) - only for TCP-based Net-Tracers
- should allow ingress ICMP Echo Requests - only for ICMP-based Net-Tracers
- must allow egress ICMP error messages (Destination Unreachable - Port Unreachable) back to the Kadiska Station(s) you use
Furthermore, all intermediate nodes (e.g. : potential firewalls) must allow these packets from the chosen Kadiska Station(s) to the target.
Principles of a UDP-based Net-Tracer
The principle of UDP-based Net-Tracer test can be schematized as follows :
Net-Tracer discovers the network path to a target by sending UDP segments with an incremental IP header TTL (Time To Live) field. So the first UDP segment is sent from the Kadiska Station to the target with a TTL=1 value in the IP header. As this packet cannot be routed by the first router on the path, the router drops the packet and sends an ICMP error message "TTL exceeded in transit" back to the Kadiska Station. The process continues with a TTL=2 IP header field to discover the second router. It goes on with incremental TTL field values up to the target. When the target is reached, this latter replies back with an ICMP error message "Destination unreachable - Port unreachable", informing the Kadiska Station that the used UDP port is closed.
At each hop, a minimum of 6 probing segments are being sent. In case the Kadiska Station does not receive ICMP error messages back, it automatically increases the number of tests. Up to 12 tests per hop can be triggered. If the router is configured so that it drops packets without generating ICMP error messages, the router is still identified in the path visualization graph but no performance metrics can be computed.
Each UDP segment sent uses a different UDP server port (from 33.435 to 33.535). When the UDP segments reach the target, this latter should at least have one of the 6 different UDP ports closed (in most of the cases, the majority of UDP ports > 1.024 will be closed, if not all), so that it sends ICMP error messages "Destination unreachable - Port unreachable" back to the Kadiska Station.
From all collected data, the Kadiska Station computes network round trip times as well as packet loss for each hop.
Other types of Net-Tracers
In some cases, the target configured in the Net-Tracer may just silently filter UDP packets and not send any ICMP message back to the Kadiska Stations. It may also be the case for intermediate routers in the path. In such a situation, the reported metrics will relate to the furthest discovered router. This is clearly identified in the path visualization graph as well as related time series.
Obviously, reaching the target ensures a better network performance metrics reporting. So in case one test method does not provide the end-to-end visibility, you can try the other available methods, which are sending TCP SYN packets, TCP ACK packets, or pure ICMP Echo Request packets. The main principles remains the same as explained above (the Kadiska Station sends packets with incremental TTL).
You can use multiple methods at the same time. In such a case, all reported metrics will take this combination into account. You can still get metrics corresponding to a specific method by creating a global filter.