New tracert.exe

Need help?
Post Reply
User avatar
Mali Mrav
Member
Posts: 305
Joined: January 2nd, 2015, 1:53 pm
Contact:
Croatia

New tracert.exe

Post by Mali Mrav » August 31st, 2019, 6:09 pm

so this one is on 170 ping as it should bee
C:\WINDOWS\system32>tracert.exe 47.190.52.113

Tracing route to static-47-190-52-113.dlls.tx.frontiernet.net [47.190.52.113]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms speedport.ip [192.168.1.1]
2 19 ms 20 ms 17 ms 172.29.252.117
3 27 ms 17 ms 18 ms 172.29.33.85
4 24 ms 26 ms 37 ms htr11-hst12-2.ip.t-com.hr [195.29.3.205]
5 23 ms 22 ms 22 ms gdr11-htr11-3.ip.t-com.hr [195.29.144.26]
6 29 ms 28 ms 28 ms 10ge4-4.core1.zag1.he.net [216.66.80.65]
7 29 ms 29 ms 29 ms 100ge8-2.core1.vie1.he.net [184.104.193.113]
8 56 ms 51 ms 52 ms 100ge13-1.core1.par2.he.net [184.105.65.5]
9 128 ms 127 ms 128 ms 100ge10-2.core1.ash1.he.net [184.105.213.173]
10 139 ms 139 ms 139 ms 100ge8-2.core1.atl1.he.net [184.105.213.69]
11 166 ms 167 ms 165 ms 100ge12-1.core1.dal1.he.net [184.105.81.170]
12 * * * Request timed out.
13 176 ms 164 ms 164 ms ae3---0.scr01.dlls.tx.frontiernet.net [74.40.4.13]
14 168 ms 166 ms 167 ms be10---0.lcr21.dlls.tx.frontiernet.net [74.40.3.18]
15 166 ms 166 ms 166 ms 172.102.51.237
16 170 ms 166 ms 176 ms static-47-190-52-113.dlls.tx.frontiernet.net [47.190.52.113]

Trace complete.


and this one is with 200 ping


C:\Windows\System32>tracert.exe 47.190.52.113

Tracing route to static-47-190-52-113.dlls.tx.frontiernet.net [47.190.52.113]
over a maximum of 30 hops:

1 1 ms 2 ms 1 ms speedport.ip [192.168.1.1]
2 18 ms 17 ms 17 ms 172.29.252.117
3 18 ms 17 ms 17 ms 172.29.33.197
4 23 ms 22 ms 23 ms htr11-hst12.ip.t-com.hr [195.29.3.69]
5 23 ms 23 ms 23 ms gdr11-htr11-3.ip.t-com.hr [195.29.144.26]
6 31 ms 28 ms 29 ms 10ge4-4.core1.zag1.he.net [216.66.80.65]
7 29 ms 30 ms 29 ms 100ge8-2.core1.vie1.he.net [184.104.193.113]
8 53 ms 63 ms 53 ms 100ge13-1.core1.par2.he.net [184.105.65.5]
9 130 ms 135 ms 131 ms 100ge10-2.core1.ash1.he.net [184.105.213.173]
10 142 ms 141 ms 142 ms 100ge8-2.core1.atl1.he.net [184.105.213.69]
11 166 ms 165 ms 165 ms 100ge12-1.core1.dal1.he.net [184.105.81.170]
12 * * * Request timed out.
13 197 ms 197 ms 197 ms ae3---0.scr02.dlls.tx.frontiernet.net [74.40.1.81]
14 201 ms 199 ms 196 ms be10---0.lcr22.dlls.tx.frontiernet.net [74.40.3.26]
15 196 ms 197 ms 197 ms 172.102.51.239
16 202 ms 205 ms 196 ms static-47-190-52-113.dlls.tx.frontiernet.net [47.190.52.113]

i dont see any other connection that would affect my ping
:-(
Silent Assassin

User avatar
Trench
Admin
Admin
Posts: 1840
Joined: May 22nd, 2012, 3:19 am
Location: Dallas / Fort Worth
Contact:
United States of America

Re: New tracert.exe

Post by Trench » August 31st, 2019, 7:36 pm

Yeah, it looks like whatever non-responsive router is at hop #12 was directed to send the traffic into Frontier via 0.scr02.dlls.tx.frontiernet.net and 0.lcr22.dlls.tx.frontiernet.net, instead of through 0.scr01.dlls.tx.frontiernet.net and 0.lcr21.dlls.tx.frontiernet.net.

I don't know who that non-responsive router is; it could be a router on the edge of the http://he.net/ network your traffic was exiting; or it could have been a router on the edge of the https://frontier.com/ network your traffic was entering; or it could be a router belonging to a entirely different tier 1 carrier (Level3, GTT, etc.). This latter case probably makes the most sense, because it's the only router not responding to ICMP Echo / ICMP Time To Live expiration.

But it would appear that at the moment you took the traceroute, the routing protocol known to hop #12 said "the traffic needs to be sent to 0.scr02.dlls.tx.frontiernet.net." It's "normal" that this isn't always exactly the same decision, since avoiding routers that are down or routers that are overloaded during prime time traffic periods is exactly what these routing protocols are supposed to do.

Just like the router close to your home decided this time to go through 172.29.33.197 and htr11-hst12.ip.t-com.hr, instead of 172.29.33.85 and htr11-hst12-2.ip.t-com.hr. It simply depends on time of day, what reasons there are for the traffic load on "your usual router" to be higher than normal, or what maintenance and routers may be temporarily offline.

Just out of curiosity though, during these same times you're trying to get to the EA117 Dallas server, also run a tracert for 68.232.164.142, which is one of GameServers.com's BF1942 servers here in Dallas. Just wondering whether it will come through the same #12 hop to them or not, which might confirm it's Level3 since I'm pretty sure that's who GameServers.com is peered to here in Dallas.

compare.png
You do not have the required permissions to view the files attached to this post.

User avatar
Mali Mrav
Member
Posts: 305
Joined: January 2nd, 2015, 1:53 pm
Contact:
Croatia

Re: New tracert.exe

Post by Mali Mrav » September 1st, 2019, 2:57 pm

Here Trench

C:\Windows\System32>tracert.exe 68.232.164.142

Tracing route to 68.232.164.142.choopa.net [68.232.164.142]
over a maximum of 30 hops:

1 2 ms 2 ms 1 ms speedport.ip [192.168.1.1]
2 * * * Request timed out.
3 19 ms 29 ms 18 ms 172.29.33.217
4 25 ms 25 ms 24 ms hdr11-hst11-2.ip.t-com.hr [195.29.144.85]
5 26 ms 84 ms 35 ms gdr11-hdr11-3.ip.t-com.hr [195.29.240.162]
6 66 ms 37 ms 33 ms 195.81.47.133
7 166 ms 165 ms 165 ms xe-2-0-1.cr0-dal2.ip4.gtt.net [141.136.107.74]
8 167 ms 171 ms 179 ms ip4.gtt.net [173.205.43.82]
9 * * * Request timed out.
10 165 ms 164 ms 165 ms 68.232.164.142.choopa.net [68.232.164.142]

Trace complete.
Silent Assassin

User avatar
Mali Mrav
Member
Posts: 305
Joined: January 2nd, 2015, 1:53 pm
Contact:
Croatia

Re: New tracert.exe

Post by Mali Mrav » September 1st, 2019, 3:05 pm

C:\Windows\System32>tracert.exe 47.190.52.113

Tracing route to static-47-190-52-113.dlls.tx.frontiernet.net [47.190.52.113]
over a maximum of 30 hops:

1 2 ms 3 ms 2 ms speedport.ip [192.168.1.1]
2 * * * Request timed out.
3 23 ms 22 ms 22 ms 172.29.33.225
4 25 ms 27 ms 25 ms hdr11-hst11-2.ip.t-com.hr [195.29.144.85]
5 24 ms 24 ms 24 ms gdr11-hdr11-3.ip.t-com.hr [195.29.240.162]
6 32 ms 31 ms 32 ms 10ge4-4.core1.zag1.he.net [216.66.80.65]
7 37 ms 34 ms 38 ms 100ge8-2.core1.vie1.he.net [184.104.193.113]
8 46 ms 46 ms 50 ms 100ge13-1.core1.par2.he.net [184.105.65.5]
9 123 ms 128 ms 124 ms 100ge10-2.core1.ash1.he.net [184.105.213.173]
10 134 ms 135 ms 134 ms 100ge8-2.core1.atl1.he.net [184.105.213.69]
11 161 ms 161 ms 162 ms 100ge12-1.core1.dal1.he.net [184.105.81.170]
12 * * * Request timed out.
13 194 ms 194 ms 194 ms ae3---0.scr02.dlls.tx.frontiernet.net [74.40.1.81]
14 200 ms 198 ms 199 ms be10---0.lcr22.dlls.tx.frontiernet.net [74.40.3.26]
15 205 ms 197 ms 198 ms 172.102.55.111
16 196 ms 195 ms 195 ms static-47-190-52-113.dlls.tx.frontiernet.net [47.190.52.113]

Trace complete.

now there is on 2. hop time out
Silent Assassin

User avatar
Trench
Admin
Admin
Posts: 1840
Joined: May 22nd, 2012, 3:19 am
Location: Dallas / Fort Worth
Contact:
United States of America

Re: New tracert.exe

Post by Trench » September 2nd, 2019, 3:15 am

Mali Mrav wrote:
September 1st, 2019, 2:57 pm
10 165 ms 164 ms 165 ms 68.232.164.142.choopa.net [68.232.164.142]
Oh well. That route is definitely not using the same backbone carrier to get here. And it doesn't even use http://he.net to leave Europe, so the route is entirely different at both ends of the journey. Doesn't let us guess anything more specific about what hop #12 might be.
Mali Mrav wrote:
September 1st, 2019, 3:05 pm
now there is on 2. hop time out
That is a little unusual for the second hop to have changed at all, since that's essentially "the first router of your ISP after your home modem/gateway."
Which is not typically someplace where "a different choice is made based on the destination address." But the third hop is still a router in the 172.29.33.xx network, so I don't think very much actually changed. They might have just de-prioritized ICMP Echo and ICMP Time To Live timeout responses due to the current load, so it just shows as non-responsive even though you were probably still hitting the exact same router.

The "slow" traceroutes thus far haven't shown any higher latency close enough to the server end for me to potentially be something in our control, other than just switching ISPs or server hosting services. Unfortunately just a lot of variables between here and Europe.

Post Reply