MTR - Base Documentation

From IT-Arts.net


Return to Wiki Index


Common MTR Commands

Basic Traceroute with MTR

To perform a simple traceroute to a host:

mtr example.com

This command performs a traceroute to the destination `example.com`, showing each hop along the route and the round-trip time to each hop.

Displaying MTR with Numeric IPs

To prevent DNS resolution and show IP addresses instead of hostnames for the route, use the `-n` option:

mtr -n example.com

This command is useful if you are troubleshooting network issues and do not want to wait for DNS lookups.

Show Detailed Output with Report Mode

To generate a summary report at the end of the MTR execution:

mtr -r -c 10 example.com

This will run MTR, sending 10 packets to each hop, and then provide a report with statistics about packet loss, average latency, and other data.

Limiting the Number of Pings

To limit the number of packets sent to each hop, use the `-c` option followed by the desired count:

mtr -c 5 example.com

This will limit the test to sending only 5 packets per hop.

Using MTR with TCP Packets

MTR by default uses ICMP Echo Request packets, but sometimes TCP packets are necessary to bypass ICMP restrictions on the network. To send TCP packets, use the `-T` option with a specified port number:

mtr -T 80 example.com

This sends TCP packets to port 80, which is often open and might bypass firewalls that block ICMP.

Displaying MTR Output with Hostnames and IPs

To display both hostnames and IP addresses in the MTR output, use the `-b` option:

mtr -b example.com

This command will show both the DNS-resolved hostnames and their associated IP addresses.

Adjusting the Time-to-Live (TTL) Value

The `-t` option allows you to specify the Time-to-Live (TTL) value for the packets sent by MTR. The TTL determines the maximum number of hops (routers) the packet will pass through before being discarded:

mtr -t 30 example.com

This limits the traceroute to a maximum of 30 hops.

Setting the Interval Between Packets

The `-i` option sets the interval in seconds between each packet sent. The default interval is 1 second, but you can change it as needed:

mtr -i 0.5 example.com

This command sets the interval to 0.5 seconds between packets.

Displaying a Continuous Live Update

To keep the output live and continuously updating, use the `-u` option:

mtr -u example.com

This will show continuous updates of latency and packet loss in real time.

Setting a Maximum Hops Limit

The `-m` option allows you to set a maximum number of hops for the traceroute. This is useful if you want to limit the trace to a smaller part of the route:

mtr -m 15 example.com

This limits the trace to a maximum of 15 hops.

Displaying MTR Output in a Report-Friendly Format

To generate a plain text report after MTR finishes running, use the `-r` option:

mtr -r -c 10 example.com

This command will generate a report after sending 10 packets to each hop, summarizing the statistics.

Showing MTR in JSON Format

For easier integration with other tools or for advanced logging, MTR can output data in JSON format. Use the `--json` option:

mtr --json example.com

This command outputs the MTR results in a structured JSON format, which can be processed by other applications.

Security Concepts

Detecting Network Path Issues

MTR helps in identifying network path issues by showing where latency or packet loss is occurring. By analyzing each hop along the route, you can pinpoint the devices or network segments that are introducing delays or dropping packets.

Look for hops that show high latency or packet loss:

mtr -c 5 example.com

If packet loss is occurring at a specific hop, it suggests that either the router at that hop is experiencing issues or it is intentionally dropping ICMP packets.

Identifying Malicious Network Behavior

MTR can also be used to identify unusual routing paths, which may indicate a man-in-the-middle attack or unauthorized redirection of traffic. For example, if the trace to a known destination unexpectedly passes through an untrusted network, further investigation is warranted.

Look for unexpected or unauthorized IP addresses in the trace:

mtr example.com

If suspicious routes or IP addresses appear, there may be network manipulation or compromised routers.

Testing Network Security Controls

Some firewalls may block ICMP packets or restrict MTR. Using TCP packets instead of ICMP can bypass such restrictions:

mtr -T 443 example.com

This sends TCP packets to port 443, which is less likely to be blocked by firewalls compared to ICMP packets.

Firewall and MTR

MTR is an effective tool for ensuring that firewalls are properly configured. By analyzing the open ports and network paths, MTR can help identify any misconfigurations in firewalls or network security devices.

Use MTR to ensure that no unauthorized ports or paths are accessible:

mtr -T 443 example.com

By sending TCP packets, you can verify that your firewall allows legitimate traffic and blocks malicious attempts.

Troubleshooting

MTR Does Not Complete or Times Out

If MTR times out or fails to complete, it may indicate that one or more routers in the network path are blocking ICMP traffic. To troubleshoot:

1. Check if intermediate routers block ICMP with `mtr -n`. 2. Use TCP-based MTR to bypass firewalls that block ICMP:

mtr -T 443 example.com

This may help complete the trace when ICMP is blocked.

High Latency or Packet Loss Detected

When MTR shows high latency or packet loss, it suggests network congestion or issues at specific hops. To isolate the issue:

1. Identify the hop with the highest latency or packet loss. 2. Contact the network administrator for that hop or check the device/router at that hop.

For example, if hop 3 shows high latency:

mtr -c 10 example.com

This indicates that the issue is at hop 3 and may need further investigation.

MTR Output Shows "Unreachable" Hops

If the MTR output shows "unreachable" or timeouts at certain hops, it may indicate that those routers are configured not to respond to ICMP requests. These routers are likely still forwarding traffic, but not responding to traceroute queries.

You can verify this by checking for other responses along the path:

mtr -n example.com

The issue might not lie with the destination, but with the router blocking ICMP traffic.