0

Greetings in the name of network engineering!

BACKGROUND:

The IPV4 network consists of the following nodes:

Node 0:127.0.0.1
Node 1:10.1.1.1
Node 2:192.168.0.1
Node 3:192.168.1.1
Node 4:210.x.x.x

Node 0 is of, of course, the source node, internal to the computer. Node 1 and 2 are intermediate routers on different floors of the building. Node 3 and node 4 are the inside and outside addresses of the fibre optic to the premise modem.

THE CONUNDRUM: Node 0 is of course, is the source node. The network can be accessed through wireless at any of Nodes 1, 2, or three.

However, when the command traceroute in a linux environment, or tracert in a windows environment, is executed the OS does not report the whole route. A ping command indicates that the connected node is there, but the traceroute does not.

Example: while connected to Node 1 the command tracert (Windows 10) was run to an IPV4 to an address outside the modem i get this result:

Tracing route to ddg.gg [20.43.161.105]
over a maximum of 30 hops:

  1     2 ms     1 ms     1 ms  192.168.0.1
  2     2 ms     1 ms     2 ms  192.168.1.1
  3    11 ms    10 ms    16 ms  210.x.x.x
^C

Trace was stopped after modem.

Again a traceroute (CentOS Linux) was sent to the same site with the following result:

[websdr@localhost ~]$ traceroute ddg.gg
traceroute to ddg.gg (20.43.161.105), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  1.520 ms  1.538 ms  1.592 ms
 2  210.x.x.x  8.844 ms  9.659 ms  9.642 ms

 
[7]+  Stopped                 traceroute 

A ping from either the linux or windows machine to 127.0.0.1 and 10.1.1.1 (in the case of the linux machine 192.169.0.1) all receive ping replies in less than 1 millisecond, with a full complement of Time To Live, 128 Ms on the internal/source IP, and on external IPs 64 Ms.

THE QUESTIONs: Are their any setting to force the tracert to report the whole IPV4 route?

As a 6 decade plus old NOOB, i hesitate saying there is a design problem with the route tracing commands, but it appears to me there is. I can understand why the route tracing command does not report the internal IP 127.0.0.1 but i fail to understand why the whole external route IS NOT reported. What command in linux, or windows might i use to get the whole external IPV4 route? I realize this is kind of an academic question, but still ... and why does linux fail to report the IPV4 ROUTE minus the first two external addresses?

Thanks in advance for the help!

Gwapo George +++

8
  • When posted the fomatting was stripped that did not appear in the previes of the post AAAARGG!! Commented Mar 7, 2023 at 15:20
  • The traces should be HOP NUMBER 1 2 ms 1 ms 1 ms 192.168.0.1 -------- HOP NUMBER 2 2 ms 1 ms 2 ms 192.168.1.1 --------- HOP NUMBER 3 11 ms 10 ms 16 ms 210.x.x.x Commented Mar 7, 2023 at 15:22
  • When you traceroute, the source is not 127.0.0.1, but your network interface IP. but questions about host configuration are off topic here. You can try asking this question on Server Fault.
    – Ron Trunk
    Commented Mar 7, 2023 at 15:25
  • and the second trace should be;----------------------------------------------------------traceroute to ddg.gg (20.43.161.105), 30 hops max, 60 byte packets--------------------------------------------------------------------------------------- 1 192.168.1.1 (192.168.1.1) 1.520 ms 1.538 ms 1.592 ms------------------------------------------------------------------------------------------ 2 210.x.x.x------------------------------------------------------------------------------------------------------------------- which reads only a litrtle bit better., SORRY I AM A BIT OF AN OCD PERFECTIONIST. Commented Mar 7, 2023 at 15:27
  • I would say the HTML on the "post a new question" needs a bit of tweeking. Or mabe twerking! Commented Mar 7, 2023 at 15:29

1 Answer 1

2

Are their any setting to force the tracert to report the whole IPV4 route?

Tracert/traceroute work by sending probe packets (usually ICMP echo requests) with increasing TTL values and reporting the hops that return the according ICMP message Time exceeded - TTL expired in transit.

Accordingly, tracert can only ever report hops that

  1. decrement TTL when forwarding - non-decrementing hops are invisible in tracert
  2. care to send ICMP timeout messages - silently discarding hops are visible as * * * timeouts in tracert

A ping command indicates that the connected node is there, but the traceroute does not.

It's technically possible that the hop/node in question does respond to an ICMP echo request but fails to return a ICMP timeout message. That's not an issue with tracert itself but with that node's configuration.

Node 0 [127.0.0.1] is of, of course, the source node, internal to the computer.

That is a misconception. 127.0.0.1 is the address of the host's internal, virtual loopback interface. For communicating across the network, the host requires an additional interface with a valid subnet address. If the application doesn't specify otherwise and uses the unspecified address 0.0.0.0 when binding its socket, then outgoing packets will use the address of the egress interface.

For tracert you can specify the local source address by using the -S option. However, tracert does not accept 127.0.0.1 as source as that's not a valid address to use on any network. It's only used and usable for talking to your local loopback interface and must not be used as source address in any egress packet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.