0

Using MTR (using TCP, not ICMP), I'm consistently seeing packet loss on one router that does normal ICMP flood limiting. UDP does the same - I still see the loss.

However, when I use other tools, ie, TCPing.exe, hping3, PRTG QOS, I rarely see loss (except for the normal ICMP loss).

What can possibly account for MTR showing consistently different results than other tools?

Hop 2 is the Cisco router with ICMP flood limiting: and look at the ms times in MTR:

mtr -P 445 -T -rn 172.31.xx.5
Start: 2020-09-02T11:54:26+0800
HOST: xxxx                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.20.x.254               0.0%    10    0.6   0.7   0.5   1.9   0.4
  2.|-- 172.18.x.239              10.0%    10  7014. 3339.   0.2 7018. 3506.6
  3.|-- 172.31.x.32                0.0%    10    4.3   2.4   2.0   4.3   0.7
  4.|-- 172.18.x.211               0.0%    10    2.4   2.5   2.4   2.6   0.0
  5.|-- 172.31.x.5                 0.0%    10   81.4  81.7  81.4  82.5   0.4

hping:

sudo hping3 -q --fast -n -c 100 172.31.x.5 -p 445 -T
HPING 172.31.x.5 (ens160 172.31.x.5): NO FLAGS are set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=172.20.x.254
hop=1 hoprtt=0.9 ms
hop=2 TTL 0 during transit from ip=172.18.x.239
hop=2 hoprtt=0.8 ms
hop=3 TTL 0 during transit from ip=172.31.x.32
hop=3 hoprtt=2.8 ms
hop=4 TTL 0 during transit from ip=172.18.x.211
hop=4 hoprtt=2.8 ms

--- 172.31.x.5 hping statistic ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 0.8/78.7/86.4 ms

TCPing.exe:

./tcping -i .1 -p 445 -n 50 172.31.x.5
Probing 172.31.x.5:445/tcp - Port is open - time=81.423ms
Probing 172.31.x.5:445/tcp - Port is open - time=81.375ms
Probing 172.31.x.5:445/tcp - Port is open - time=81.246ms

Ping statistics for 172.31.x.5:445
     50 probes sent.
     50 successful, 0 failed.  (0.00% fail)
Approximate trip times in milli-seconds:
     Minimum = 81.246ms, Maximum = 85.690ms, Average = 81.628ms
     
7
  • mtr is showing the "different" result for 172.18.x.239 though, not 172.31.x.5 Sep 2, 2020 at 7:16
  • Yes, @HåkanLindqvist, thats what I'm after. The destination doesn't show any loss. But the point is I'm only sending TCP packets in all tools, not ICMP. I'm trying to find why it is different for MTR than the other tools.
    – Jason
    Sep 2, 2020 at 7:49
  • Can you confirm that you actually get different results with the other tools if you test 172.18.x.239 with all of them? Currently the question appears to be based on comparing results for different hosts. Sep 2, 2020 at 8:25
  • @HåkanLindqvist They are all testing the same host, 172.31.x.5, and the same router at hop 2 172.18.x.239. Apples to apples. I can't test TCP SYN direct to that router as it won't respond to anything but SSH on port 22, which is a different test altogether. So the only way to test TCP packet loss inside this router is to send the packets to a host after the hop 2 router, so it passes the TCP packets on like a router should. That's the test - showing it drops some TCP packets, which it should not be. But other tools are not showing TCP packet loss. Open to further suggestions.
    – Jason
    Sep 3, 2020 at 2:36
  • It seems to me that MTR is the only tool that actually monitors the intermediate hops, and you seem to be asking about the result for one of the intermediate hops specifically? There is no disagreement that there is 0% packet loss for the destination, the alleged disagreement is regarding one of the intermediate hops, what I'm trying to point out is that you only have output from 1 tool for that, so there is nothing to compare. (tcping doesn't seem to do any sort of trace at all, hping3 does a trace but then seems to only monitor the destination, mtr does the trace and monitors all hops) Sep 3, 2020 at 11:26

1 Answer 1

0

Not sure about the other tools you used, but mtr, when using TCP sends a TCP SYN packet to the destination and incrementing the TTL from 1 until it reaches the destination. So the routers in the path still send back an ICMP type 11 - Time-to-live exceeded, when they are the ones where the packet reaches TTL 0. This could potentially account for the perceived loss on the router if control plane policing was in effect on it.

You can read about control plane policing a bit here if interested: https://nwmichl.net/2021/02/03/coping-with-copp-why-icmp-drops-happen/

1
  • i tested with hping3 as well, and it seems like when using the -T flag it only sends a single packet to the path destinations and all the rest to the end destination, so in your case 172.18.x.239 would have received a single packet and the end destination 172.31.x.5 the full 100 (or maybe just the remaining 95, not sure, didnt bother to count). A better testing methodology would be to hping the router at 172.18.x.239 maybe with ICMP if allowed and see if it produces a loss... I know its a year old thread but perhaps others will find it later.
    – blue212121
    Oct 5, 2021 at 20:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .