TechSpot

Poor performace due to Inet backbone

By jobeard
Nov 26, 2013
Post New Reply
  1. 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.
     
  2. Julio Franco

    Julio Franco TechSpot Editor Posts: 7,059   +646

    Thanks jobeard. One week later, was this a temporary issue or is it holding on?
     
  3. jobeard

    jobeard TS Ambassador Topic Starter Posts: 9,342   +622

    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.
     
    Matthew and cliffordcooley like this.
  4. cliffordcooley

    cliffordcooley TS Guardian Fighter Posts: 8,558   +2,900

    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?
     
  5. jobeard

    jobeard TS Ambassador Topic Starter Posts: 9,342   +622

    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.
     
    cliffordcooley likes this.
  6. cliffordcooley

    cliffordcooley TS Guardian Fighter Posts: 8,558   +2,900

    I understand this

    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
     
  7. jobeard

    jobeard TS Ambassador Topic Starter Posts: 9,342   +622

    that's about it

    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.
     
    cliffordcooley likes this.
  8. cliffordcooley

    cliffordcooley TS Guardian Fighter Posts: 8,558   +2,900

    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.
     
    Matthew likes this.
  9. jobeard

    jobeard TS Ambassador Topic Starter Posts: 9,342   +622

    Fair comment
     

Similar Topics

Add New Comment

You need to be a member to leave a comment. Join thousands of tech enthusiasts and participate.
TechSpot Account You may also...