Ping ok but mtr does not reach destination? Trying to understand this

OhJohn

What could be the reason for a normal ping (icmp) to get through but a mtr (in icmp mode) does not reach the destination but hangs after a hop with a waiting for reply?

mtr -u (udp) or -T (TCP) gets through, does not show the hops (waiting for reply after the special one) but reaches the destination though with a high packet loss at the destination.

OhJohn

Could this be a loop problem somewhere along the route?

I'm trying to reach 34.248.0.0/13 (AWS EU-West-1 range) via LINX from AS42831 (UKServers) or AS212027 (Pebblehost) but both stop after 195.66.225.175 (AWS peering in LINX) in mtr?

Other ranges in destination AWS-EU-West-1 don't have this problem, e.g. a mtr to 34.240.0.0/13 gets through.

OhJohn

Same problem with an unreachable destination through mtr but pingable via ping from AS12876 (Scaleway France). The route shows some AWS IPs from Herndon, VA (sic) that are not in Herndon but probably Paris (by latency) but then it stops as well.

Not idea what AWS is doing in there AWS-EU-West-1 route configurations.

plumberg

@OhJohn said:
What could be the reason for a normal ping (icmp) to get through but a mtr (in icmp mode) does not reach the destination but hangs after a hop with a waiting for reply?

mtr -u (udp) or -T (TCP) gets through, does not show the hops (waiting for reply after the special one) but reaches the destination though with a high packet loss at the destination.

Sometimes there is an issue with your isp.

I have had this challenge in usa with fios.
Ping is fine. Mtr or traceroute will give just first and destination hops and nothing in between

OhJohn

But in this case I'm having this between different ASNs, e.g. UK Servers or Pebblehost in the UK or Scaleway in France all seeming to have problems with that one /13 range in AWS (but not other ranges in AWS).

And I cannot even reach the destination via icmp but only via tcp (and that only with a lot of hops missing).

Clouvider

Routers implement various ACLs on the way. This is most likely the cause.

OhJohn

@Clouvider you do probably peer with AWS in LINX, right?

Can you reach 34.248.0.0/13 there with test dest ip 34.248.60.213 (from https://ec2-reachability.amazonaws.com/)?

babywhale

reboot

Clouvider

Sure - and no, can't reach via default mtr.

mtr 34.248.60.213 --report -c 2
Start: 2023-11-16T11:57:54+0000
HOST: dumbledore.clouvider.net    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway                   0.0%     2    5.1   3.1   1.2   5.1   2.7
  2.|-- [snipped]                0.0%     2    0.2   0.3   0.2   0.4   0.1
  3.|-- [snipped]                 0.0%     2    0.8   0.9   0.8   1.0   0.2
  4.|-- [snipped]                 0.0%     2    0.6   0.8   0.6   1.0   0.3
  5.|-- linx-lon1.thn2.peering.cl  0.0%     2    0.5   0.6   0.5   0.6   0.1
  6.|-- 195.66.225.175             0.0%     2    0.6   0.6   0.6   0.6   0.0
  7.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0

With TCP - I presume same thing you were reporting.

mtr 34.248.60.213 --report -c 2 -T
Start: 2023-11-16T11:58:58+0000
HOST: dumbledore.clouvider.net    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- _gateway                   0.0%     2   27.4  14.0   0.7  27.4  18.8
  2.|-- [snipped]                0.0%     2    0.2   0.3   0.2   0.4   0.1
  3.|-- [snipped]                 0.0%     2    0.8   0.9   0.8   1.0   0.2
  4.|-- [snipped]                 0.0%     2    0.6   0.8   0.6   1.0   0.3
  5.|-- linx-lon1.thn2.peering.cl  0.0%     2    0.5   0.6   0.5   0.6   0.1
  6.|-- 195.66.225.175             0.0%     2    0.7   0.6   0.5   0.7   0.1
  7.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  8.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  9.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 10.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 11.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 12.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 13.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 14.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 15.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 16.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 17.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 18.|-- ec2-34-248-60-213.eu-west  0.0%     2   10.4  11.0  10.4  11.6   0.8

it's most likely an ACL within Amazon, possibly also some MPLS on hops 7-17 on the TCP one.

Clouvider

@babywhale said:
reboot

leave the bus and re-enter the bus to see if this fixed the engine ;-).

OhJohn

@Clouvider great, thank you, you are seeing exact the same behavior I'm getting here on different ASNs in checking that AWS route.

Could this be a reason for dropped connections between those ASNs and AWS or packet loss on tcp level?

bdl

@Clouvider said:

@babywhale said:
reboot

leave the bus and re-enter the bus to see if this fixed the engine ;-).

Clouvider

This in itself? Definitely not. This MTRs don't indicate any issue (but also mask a lot of data so really... You don't get the whole picture).

You may have more luck investigating from within Amazon to the destination IP else, maybe that will turn up some hops with actual lost packets and the loss carrying over to aid further investigations.