How is that possible at all: traceroute reports 2 hops with same IP. Take a look at the last 2 hops :

Think of how traceroute works. Next attempt will be with a TTL which is one higher. It could/will be the same answer again.
The local traceroute should have seen it was already there with TTL=10.
The path for TTL=11 could be one longer than the previous one (routes vary over time, as next hops can differ)
The 11 steps in the printed list are not from one travelling packet, but from 11 separate packets, each sent with increasing TTL.

Think of how traceroute works. Next attempt will be with a TTL which is one higher. It could/will be the same answer again.
The local traceroute should have seen it was already there with TTL=10.
The path for TTL=11 could be one longer than the previous one (routes vary over time, as next hops can differ)
The 11 steps in the printed list are not from one travelling packet, but from 11 separate packets, each sent with increasing TTL.

But the question was: why do the last 2 hops have the same IP ? How is that possible?
Ie. it much looks like that 2 machines have the same IP... Somehow illogical...

It probably is the same machine that answered.
The 10th line needed 10 hops before the TTL was reduced to zero (and that router reported the end of travel because TTL was used up)
The 11th line (Traceroute with TTL=11) ended after 11 hops of the packet. That path was 1 hop longer. IP routes can be dynamic depending on the routing protocol used, a broken link is replaced with another slower or longer path. Be it OSPF or BGP or any other routing protocol finding the best path. There could also be some load balancing involved, with different paths for the 10th and the 11th line.

Interesting is also the reported IP address with traceroute. Experiment with an alternate IP on on a router (eg IP of other interface with other subnet), but receive the IP from the interface that sent the answer to you.

MTR could generate a more stable (repeated) answer, as the Traceroute double IP can be caused by a one time missed answer.
The RouterOS Tools/traceroute in WinBox acts like MTR, with repeated checks

https://www.clouddirect.net/knowledge-b ... d-pathping

And I see CDN in one of the lines. Content Delivery Networks do have multiple hosts with the same IP address to optimize response time.
https://serverfault.com/questions/92825 ... le-servers

If packet, used by traceroute (linux traceroute usually uses UDP packet, targeting a random high port, some traceroute tools use ICMP packets), is DST-NATed, then the same final address will be shown twice:

1. when TTL expires at the moment when packet hits NAT-performing device and that device replies with ICMP time exceeded (using own WAN IP address as it should)
2. whn TTL expires at the moment when packet hits internal server and that device either replies in any way (either ICMP port forbidden or even with reply packet) and NAT-performing device reverse-NATs the reply (that packet is "related" to allowed connection).

If one uses tcptraceroute (which uses TCP SYN packets), then such "double" final IP address is shown quite often.
But not always: when DST NAT is in force, if router uses another IP address as own address but uses specific IP address for NATing a particular service, then penultimate hop will display router's "native" IP address and ultimate will show the IP address used for particular service. In such case it's hard (next to imposible) to tell if NAT is actually done or not.

Aha, thanks @MKX.

From my house , with ROS Tools/traceroute towards 192.229.221.95, ... with protocol ICMP set shows single response (12), protocol UDP set shows the double response (12-13)