Hi All,

With EoIP tunneling, is there a way to make the EoIP tunnel show up as a hop in the traceroute? Below, 10.99.101.254 is Site A and 10.15.101.254 is Site B, with an EoIP tunnel between them.

PS C:\Windows\system32> tracert 10.15.101.254
Tracing route to 10.15.101.254 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.99.101.254
2 20 ms 20 ms 20 ms 10.15.101.254
Trace complete.

Please post:
- purpose of having EoIP in the trace
- post the netmasks
- post detailed configuration for the existing network

Generally speaking, it is possible. You can allocate a small network for the EoIP link and pick 2 IPs from this network and set it on both side of EoIP tunnel.
in this way you can treat EoIP as a layer 3 link

Hi payam124,

The guy who I am doing this for wants the tunnel to show.

Each site has an external public IP address, an internal network with a prefix of 10.nn.101.0/24 and is connected to every other site via an EoIP tunnel with /30 subnets configured on the interfaces. I have configured static routes on the routers to route the traffic (e.g. Site A has an internal subnet of 10.14.101.0/24 and a tunnel IP of 169.254.0.1/30, Site B has 10.15.101.0/24 and a tunnel IP of 169.254.0.2/30, Site A will route 10.15.101.0/24 to 169.254.0.2 and Site B will route 10.14.101.0/24 to 169.254.0.1). The subnets are below (and the routers are on the internal .254 addresses):

Site A Internal Network - 10.14.101.0/24
Site B Internal Network - 10.15.101.0/24
Site C Internal Network - 10.16.101.0/24
Site D Internal Network - 10.17.101.0/24
Site E Internal Network - 10.99.101.0/24

A to B Tunnel - 10.10.100.0/30
A to C Tunnel - 10.10.100.4/30
A to D Tunnel - 10.10.100.8/30
A to E Tunnel - 10.10.100.12/30

B to C Tunnel - 10.10.100.16/30
B to D Tunnel - 10.10.100.20/30
B to E Tunnel - 10.10.100.24/30

C to D Tunnel - 10.10.100.28/30
C to E Tunnel - 10.10.100.32/30

D to E Tunnel - 10.10.100.36/30

Currently if a desktop computer at A on IP 10.14.101.116 tries to ping another desktop at C on 10.16.101.235 it will show the tunnel hop. I guess a more appropriate question would be if the router at A on 10.14.101.254 tried to ping the router at B on 10.15.101.254, is it possible to show the tunnel hop between the two? I don't think it is, but wanted to confirm.

while still I can not understand why you want to see any hop with you ping a router connected to you using EoIP, let me explain you how the network works in your case and you would realize why you don't see any hop
Also I'm not clear about: "A to B Tunnel - 10.10.100.0/30" when you mentioned you used 169.254.0.1 and 169.254.0.2 for the tunnel between A and B. Please explain

when you try trace address of router B (10.15.101.254) from Router A, router A checks its routing table and sees 10.15.101.0/24 is readable through 169.254.0.2 over tunnel. so it would pick (by default) 169.254.0.1 as the source of packet, and create a packet which its destination is 10.15.101.254 and set TTL=1 and send the packet to 169.254.0.2 as it is directly connected to this Router using the Tunnel. Attention: when 2 nodes are directly connected, there isn't any hop in between.
then 169.254.0.2 (Router B) receives the packet (whose source is 169.254.0.1) and check the destination which is 10.15.10.254. it finds that the destination is an IP address of its own. so just reply back. no any hop in between.

To trace the tunnel hops and to be visible to the tunnel traffic, this would mean that ALL routers along the way need to support EoIP, unpack the packet inside, decrease its TTL, repack it and send it to the destination. To expect something like this is hilarious at best, and totally inefficient.
If you need to trace the tunnel hops, explore the endpoint IP by a regular trace, not the tunnel itself. EoIP is just a payload in an IP data flow and there is nothing you can do about it.
In Linux, this is possible on VPNs because there is an option to set the endpoint connection's TTL to be inherited from the tunnel interface's one. But this is a synthetic solution, and I really see no benefit since it would expect the tunneled traffic to need high TTL's without added benefits because the number of hops would not be perdictible like in the regular behavior.