Poor performace due to Inet backbone

D

DelJo63

Purely FYI: Access to techspot.com is deplorable from L.A. today, eg
Code:
ping techspot.com
 
Pinging techspot.com [50.22.252.218] with 32 bytes of data:
Reply from 50.22.252.218: bytes=32 time=[COLOR=#ff0000]1578ms[/COLOR] TTL=53
Reply from 50.22.252.218: bytes=32 time=1415ms TTL=53
Reply from 50.22.252.218: bytes=32 time=1562ms TTL=53
Reply from 50.22.252.218: bytes=32 time=1477ms TTL=53
but it's not a webserver/website issue - - it is the nodes owned by networklayer..com - -
just look at the loss of data in those nodes:
Code:
Computing statistics for 400 seconds...
			Source to Here  This Node/Link
Hop  RTT	Lost/Sent = Pct  Lost/Sent = Pct  Address
  0										  jeffPC7 [192.168.0.5]
								0/ 100 =  0%  |
  1	0ms	0/ 100 =  0%	0/ 100 =  0%  localRouter [192.168.0.1]
								0/ 100 =  0%  |
  2  593ms	0/ 100 =  0%	0/ 100 =  0%  cpe-108-184-144-1.socal.res.rr.com [108.184.144.1]
								0/ 100 =  0%  |
  3  529ms	0/ 100 =  0%	0/ 100 =  0%  tge7-8.wlvgcabn02h.socal.rr.com [76.166.19.221]
								0/ 100 =  0%  |
  4  536ms	0/ 100 =  0%	0/ 100 =  0%  tge0-8-0-10.vnnycajz02r.socal.rr.com [72.129.13.108]
								0/ 100 =  0%  |
  5  549ms	0/ 100 =  0%	0/ 100 =  0%  agg29.tustcaft01r.socal.rr.com [72.129.13.2]
								0/ 100 =  0%  |
  6  552ms	0/ 100 =  0%	0/ 100 =  0%  ae-6-0.cr0.lax30.tbone.rr.com [66.109.6.214]
								0/ 100 =  0%  |
  7  554ms	0/ 100 =  0%	0/ 100 =  0%  ae-1-0.pr0.lax00.tbone.rr.com [66.109.6.129]
							   0/ 100 =  0%  |
  8  ---	100/ 100 =100%  100/ 100 =100%  te1-6.bbr01.cs01.lax01.networklayer.com [66.109.11.42]
								0/ 100 =  0%  |
  9  ---	100/ 100 =100%  100/ 100 =100%  ae7.bbr01.cs01.lax01.networklayer.com [173.192.18.166]
								0/ 100 =  0%  |
10  ---	100/ 100 =100%  100/ 100 =100%  ae19.bbr01.eq01.dal03.networklayer.com [173.192.18.140]
								0/ 100 =  0%  |
11  ---	100/ 100 =100%  100/ 100 =100%  ae7.bbr02.eq01.dal03.networklayer.com [173.192.18.209]
								0/ 100 =  0%  |
12  ---	100/ 100 =100%  100/ 100 =100%  ae1.bbr01.tl01.atl01.networklayer.com [173.192.18.135]
								0/ 100 =  0%  |
13  ---	100/ 100 =100%  100/ 100 =100%  ae0.bbr01.eq01.wdc02.networklayer.com [173.192.18.152]
								0/ 100 =  0%  |
14  ---	100/ 100 =100%  100/ 100 =100%  ae0.dar02.sr01.wdc01.networklayer.com [173.192.18.203]
								0/ 100 =  0%  |
15  ---	100/ 100 =100%  100/ 100 =100%  po2.fcr02.sr01.wdc01.networklayer.com [208.43.118.151]
								0/ 100 =  0%  |
16  617ms	0/ 100 =  0%	0/ 100 =  0%  techspot04.techspot.com [50.22.252.218]
 
Trace complete.
 
Symptom lasted about 24 hrs and then networklayer.com apparently got tired of all the helpdesk calls
and fixed it :)

The whole point of the post was demonstrating (to all) how to differentiate a website issue from an internet backbone problem.
 
The whole point of the post was demonstrating (to all) how to differential a website issue from an internet backbone problem.
With weak links, shouldn't a faster link be used? I mean at that particular time, was "networklayer.com" the fastest link to be found? In other words the only path to be taken?
 
The short answer is We Have No Control.

We have control only at the two endpoints, the user {you,me} and the admins at TS. Every other node is controlled by the routing table in that node. That's why a network admin must be proactive to monitor the systems networks and resolve issues asap. Every user that crosses a node gets the impact of all issues and users on both sides of the symptomatic node start to complain.
 
The short answer is We Have No Control.

We have control only at the two endpoints, the user {you,me} and the admins at TS.
I understand this

Every other node is controlled by the routing table in that node. That's why a network admin must be proactive to monitor the systems networks and resolve issues asap. Every user that crosses a node gets the impact of all issues and users on both sides of the symptomatic node start to complain.
And there is no way for each node to know the condition of each node within the routing table? What you describe is a parent node having all control and doesn't monitor child node status.

Consider me ignorant on how network traffic communicates, because that is what I am.

It seems a little more communication between nodes could solve this, unless the issue is spread across all nodes within the routing table. In which case traffic should be routed elsewhere, by notifying its parent node. But then what do I know, I'm sure they are doing everything they can to minimize these issues.

Thanks for posting jobeard
 
And there is no way for each node to know the condition of each node within the routing table? What you describe is a parent node having all control and doesn't monitor child node status.
that's about it

It seems a little more communication between nodes could solve this, unless the issue is spread across all nodes within the routing table. In which case traffic should be routed elsewhere, by notifying its parent node. But then what do I know, I'm sure they are doing everything they can to minimize these issues.

Routing is blind (ie knows nothing).
Look at your own routing table (run ROUTE PRINT)
There are several lines but only two of are real consequence:
the first line: 0.0.0.0 0.0.0.0 {your router addr} {your ip addr}
and a line that has mask 255.255.255.0 {your ip addr}
the first is the default route
the other is routing for your lan system(s)

Notice: your ISP address is not there, neither are your DHCP or DNS addresses.

So the routing table (in english) is saying "if it's not on my lan, then send it to the gateway (eg: router) and someone brighter than I am will have to work this out".

This continues until some node in the path says "I know where that is!"

To be fair, there is a RIP protocol for routers to get updates, but it is also a BIG security risk and only the backbone nodes use and trust that system.

There is also a SNMP protocol to get information from another system, but it too is a security exposure.
 
Routing is blind (ie knows nothing).

This continues until some node in the path says "I know where that is!"
I believe that explains the concept to me very well. So the only nodes that actually know where TechSpot is at, is the nodes directly connected to TechSpot? All other nodes are simply requesting the where abouts? Then if I am following correctly (pun not intended); traffic is diverted through the route that responds first, regardless of node status along the way.
 
Back