I normally don't top post, but there nothing I can meaningfully trim
from your excellent detailed description. So I'm leaving it below.
To your traceroute, route tracing (IIRC) depends on setting a max hop
count on the outbound packets. When the hop count is exceeded, you get
back an ICMP error packet indicating that the count was exceeded from
the router which decremented the counter to 0.
So to trace a route you send a packet with a max hop count of 1, and get
a packet back from your router, and that tells you the router IP. Then
you send one with a max hop count of 2 and get an error packet back from
the next router upstream, telling you its IP address. And so on.
Plenty of network routers do not respond to pings and do not return
these error packets - they just drop the packet on the floor. These just
show up as gaps in the traceroute, because traceroute does not receive
the ICMP response from the routers at that hop count.
So what you see below is normal. Don't sweat it. Here's an example from
where I'm sitting to a host on a TPG network:
traceroute to ************ (14.203.40.46), 64 hops max, 52 byte
packets
1 cskk-3g (10.0.0.138) 2.220 ms 1.824 ms 1.716 ms
2 * * *
3 10.4.37.50 (10.4.37.50) 31.144 ms 26.018 ms 55.897 ms
4 10.5.86.65 (10.5.86.65) 33.860 ms 34.792 ms 36.855 ms
5 10.5.86.72 (10.5.86.72) 49.968 ms 41.517 ms 30.999 ms
6 203.50.63.96 (203.50.63.96) 35.888 ms 34.900 ms 26.032 ms
7 bundle-ether26.chw-core10.sydney.telstra.net (203.50.61.96) 27.825
ms 31.547 ms 31.129 ms
8 bundle-ether1.chw-edge903.sydney.telstra.net (203.50.11.177) 28.825
ms 32.709 ms 35.956 ms
9 aap3461251.lnk.telstra.net (110.145.180.218) 30.886 ms 25.857 ms
29.599 ms
10 syd-sot-ken-wgw1-be-30.tpgi.com.au (203.219.107.193) 29.719 ms
28.821 ms 28.611 ms
11 203-221-3-109.tpgi.com.au (203.221.3.109) 33.221 ms 31.921 ms
203-221-3-45.tpgi.com.au (203.221.3.45) 40.022 ms
12 * * *
13 * * *
14 * * *
15 * * *
Cheers,
Cameron Simpson <cs@xxxxxxxxxx>
On 25Mar2022 19:29, Jack Craig <jack.craig.aptos@xxxxxxxxx> wrote:
>i have a networking mystery ; i hope someone might give me a clue.
>
>i am working to restore a web server to internet access that is failing
>after att update
>the att older modem (pace 5238ac) with arris BGW210-700.
>
>i have a static ip from att in the range 108.220.213.0/255.255.255.248,
>108.220.213.121 is the external ip for the server.
>
>the bgw210-700 is the primary router/modem and is connected to a 3rd party
>router, netgear nighthawk,
>
>the internal 10.0.0.0/ connects to the netgear nighthawk
>
>ATT's broadband configuration is
>
> Blackhole-ATT (wireless name)
>
> Broadband connection source DSL
> Broadband connection up
> Broadband network type lightspeed
> Broadband ipv4 address 108.90.204.76
> Broadband gateway address 108.90.204.1
>
>outbound packets from the server (WS), are routed from the 10.0.0.1
>nighthawk to the ATT router to the internet.
>
>the 108.90.204.0 network routing from the att router to the att's gateway.
>.76 is the router, .1 is the GW.
>
>sample route, ...
>
>10.0.0.101 ws.linuxlighthouse.com (internal IP) 2 packets
>transmitted, 2 received, 0% packet loss, time 1033ms
>10.0.0.1 Blackhole-NH 2
>packets transmitted, 2 received, 0% packet loss, time 1018ms
>192.168.1.254 Blackhole-ATT 2
>packets transmitted, 2 received, 0% packet loss, time 1001ms
>108.90.204.76 att subnet (local router) 2 packets
>transmitted, 2 received, 0% packet loss, time 1002ms
>108.90.204.1 att subnet (remote GW) 2 packets
>transmitted, 2 received, 0% packet loss, time 1001ms
>108.220.213.121 ws.linuxlighthouse.com (public IP) 2 packets transmitted,
>2 received, 0% packet loss, time 1001ms
>108.220.213.126 linuxlighthouse (public GW) 2 packets
>transmitted, 2 received, 0% packet loss, time 1001ms
>
>now the mystery. where 108.220.213.121 is a publicly visible ip for the
>server, a remote traceroute is wonky!!
>
>consider the below traceroute, it reports hops up to 108.90.204.76,
>stopping there instead of doing one more hop
>
>
> 1 <1 ms <1 ms <1 ms Linksys35675 [192.168.1.1]
> 2 9 ms 8 ms 17 ms 142-254-236-209.inf.spectrum.com
>[142.254.236.209]
> 3 12 ms 10 ms 11 ms lag-63.tjngcaac01h.netops.charter.com
>[24.30.172.49]
> 4 14 ms 13 ms 13 ms lag-29.lsaicaev01r.netops.charter.com
>[72.129.18.240]
> 5 12 ms 14 ms 11 ms lag-26.lsancarc01r.netops.charter.com
>[72.129.17.0]
> 6 19 ms 13 ms 14 ms lag-16.lsancarc0yw-bcr00.netops.charter.com
>[66.109.6.102]
> 7 25 ms 37 ms 42 ms lag-3.pr2.lax10.netops.charter.com
>[107.14.19.41]
> 8 17 ms 17 ms 17 ms 192.205.32.253
> 9 22 ms 21 ms 21 ms cr1.la2ca.ip.att.net [12.122.128.102]
> 10 24 ms 25 ms 25 ms 12.122.158.41
> 11 * * * Request timed out.
> 12 * * * Request timed out.
> 13 23 ms 21 ms 23 ms 99.134.39.15
> 14 25 ms 24 ms 26 ms 99.161.44.79
> 15 44 ms 43 ms 43 ms
>108-90-204-76.lightspeed.mtryca.sbcglobal.net [108.90.204.76]
> 16 * * * Request timed out.
> 17 * * * Request timed out.
> 18 * * * Request timed out.
> 19
>
>
>could anyone shed some light on this mystery??
>
>tia,jackc...
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
