Teleglobe sent following email 1/21/00: This e-mail is in order to provide you with the latest update concerning trouble ticket 166619. As per our internet specialists, by looking into the first trace provided they cannot see any latency accept for the one originated at SFL.NET in hop 14. At this moment, our internet specialists have indicated that the latency from SFL.NET is not even seen anymore. Below you will find the results. Would you be so kind as to advise us whether you wish us to pursue the investigation or close this trouble ticket. As always should you have any questions or concerns please feel free to communicate with us at any time. Best Regards, Tony Guerrera Global Customer Service Tel: 1-514-868-7875 Fax: 1-514-868-7875 E-mail: trouble@teleglobe.com ***********************************Beginning of Copy****************** >>TRACING FROM HTTP://WWW.SLAC.STANFORD.EDU/CGI-BIN/NPH-TRACEROUTE.PL TO DESTANATION. SLAC. NET ARE NOT USING TELEGLOBE LINK. THEY ARE USING UUNET AT THIS MOMENT TRACEROUTE TO GREYOWL.PLATFORM.COM (192.219.104.253): 3-25 HOPS, 38 BYTE PACKETS 3 ESNET-A-GATEWAY.SLAC.STANFORD.EDU (192.68.191.66) 0.846 MS (TTL=253) 4 SNV-SLAC.ES.NET (134.55.208.30) 1.39 MS (TTL=251!) 5 CHI-SNV.ES.NET (134.55.205.2) 49.3 MS (TTL=250!) 6 DCHUB-CHI.ES.NET (134.55.208.165) 85.8 MS (TTL=250) 7 DCCONN-DCHUB.ES.NET (134.55.208.174) 109 MS (TTL=249) 8 192.41.177.249 (192.41.177.249) 111 MS (TTL=248) 9 112.AT-2-0-0.XR2.TCO1.ALTER.NET (146.188.160.86) 210 MS (TTL=246!) 10 292.AT-0-1-0.TR2.DCA8.ALTER.NET (152.63.32.218) 193 MS (TTL=245!) 11 115.ATM7-0.TR2.TOR2.ALTER.NET (146.188.141.214) 192 MS (TTL=245) 12 298.ATM7-0.XR2.TOR2.ALTER.NET (152.63.128.61) 129 MS (TTL=244) 13 194.ATM6-0.GW1.TOR2.ALTER.NET (152.63.128.109) 129 MS (TTL=243) 14 157.130.159.54 (157.130.159.54) 130 MS (TTL=242) 15 216.18.63.94 (216.18.63.94) 138 MS (TTL=244!) 16 MT-PLATFORM-3.MT.SFL.NET (209.135.96.58) 154 MS (TTL=243!) 17 * **************************************************************************** ************************ TYPE ESCAPE SEQUENCE TO ABORT. TRACING THE ROUTE TO GREYOWL.PLATFORM.COM (192.219.104.253) 1 IF-1-0-1.BB5.NEWYORK.TELEGLOBE.NET (207.45.223.5) 8 MSEC IF-1-0-0.BB5.NEWYORK.TELEGLOBE.NET (207.45.223.85) 12 MSEC IF-1-0-1.BB5.NEWYORK.TELEGLOBE.NET (207.45.223.5) 8 MSEC 2 IF-1-0.CORE2.NEWYORK.TELEGLOBE.NET (207.45.221.66) 16 MSEC IF-3-0.CORE2.NEWYORK.TELEGLOBE.NET (207.45.221.98) 8 MSEC IF-1-0.CORE2.NEWYORK.TELEGLOBE.NET (207.45.221.66) 12 MSEC 3 IF-1-0.CORE2.SCARBOROUGH.TELEGLOBE.NET (207.45.220.164) 32 MSEC 36 MSEC 32 MSEC 4 IX-5-3.CORE2.SCARBOROUGH.TELEGLOBE.NET (207.45.198.6) 48 MSEC 36 MSEC 52 MSEC 5 216.18.63.110 [AS 6539] 40 MSEC 40 MSEC 44 MSEC 6 MT-PLATFORM-3.MT.SFL.NET (209.135.96.58) [AS 6539] 44 MSEC 40 MSEC 40 MSEC 7 * * * **************************************************************************** GIN-NQT-CORE2#PING PROTOCOL [IP]: TARGET IP ADDRESS: 207.45.220.164 REPEAT COUNT [5]: 500 DATAGRAM SIZE [100]: 1000 TIMEOUT IN SECONDS [2]: EXTENDED COMMANDS [N]: Y SOURCE ADDRESS OR INTERFACE: TYPE OF SERVICE [0]: SET DF BIT IN IP HEADER? [NO]: VALIDATE REPLY DATA? [NO]: DATA PATTERN [0XABCD]: LOOSE, STRICT, RECORD, TIMESTAMP, VERBOSE[NONE]: SWEEP RANGE OF SIZES [N]: TYPE ESCAPE SEQUENCE TO ABORT. SENDING 500, 1000-BYTE ICMP ECHOS TO 207.45.220.164, TIMEOUT IS 2 SECONDS: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!! TARGET IP ADDRESS: 207.45.198.6 REPEAT COUNT [5]: 500 DATAGRAM SIZE [100]: 1000 TIMEOUT IN SECONDS [2]: EXTENDED COMMANDS [N]: Y SOURCE ADDRESS OR INTERFACE: TYPE OF SERVICE [0]: SET DF BIT IN IP HEADER? [NO]: VALIDATE REPLY DATA? [NO]: DATA PATTERN [0XABCD]: LOOSE, STRICT, RECORD, TIMESTAMP, VERBOSE[NONE]: SWEEP RANGE OF SIZES [N]: TYPE ESCAPE SEQUENCE TO ABORT. SENDING 500, 1000-BYTE ICMP ECHOS TO 207.45.198.6, TIMEOUT IS 2 SECONDS: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!! SUCCESS RATE IS 100 PERCENT (500/500), ROUND-TRIP MIN/AVG/MAX = 24/29/364 M *****************************************End of Copy****************** Cottrell sent following email 1/20/00: De : Cottrell, Les [mailto:cottrell@SLAC.Stanford.EDU] Envoyé : 01-01-20 19:39 À : 'Data Customer Service'; 'James F. Leighton'; 'trouble@es.net' Cc : Melen, Randal; Russell, Edwin S. Objet : RE: Problems in Teleglobe/ 166619 We are still experiencing very bad packet loss between SLAC and ftp.platform.com: The following is a summary of ping from flora.slac.stanford.edu run 1/20/01, 4:32pm PST. See http://www.slac.stanford.edu/grp/scs/net/case/platform/ for our understanding of the problem. How does one get an estimate or expectation of when the problem is expected to be addressed? Should we contact noc@sprint.net (in which case we need to know the trouble ticket number they assigned to your report to them), or do we rely on you to act on Platform's and our behalves? Teleglobe wrote 1/16/00, 12:21pm The following e-mail is in order to provide you with the latest update concerning the trouble ticket number #166619. As per our technical department this is a Sprint NAP known issue, and they are working in upgrading the FDDI ring but there is no ETR. As soon as any other technical input is available, we will communicate with you. Should you have any concerns or if there is something else we could assist you with, please feel free to communicate with us at any time. Best Regards, Eduardo Torres Global Customer Service Center Tel: +1-514-868-7875 Fax: +1-514-868-8996 ESnet wrote 1/15/01, 9:15pm PST We have opened ESnet Trouble Ticket #7097 and are currently working with Teleglobe on this issue. Ed Russell wrote 1/15/01, 6:13pm PST FYI, I did an ssh to cardinal.stanford.edu and got no packet loss going to Platform. In fact, I did some ftp's from there and got quite reasonable response. The traceroute from cardinal does include some Teleglobe.net nodes but not esnet. Jim Leighton wrote 1/15/01, 5:26pm PST I see about 12% loss doing a ping test to ftp.platform.com from home using my @Home connection, at 5PM on a holiday, via a route which doesn't touch ESnet - assuming it is symmetric. Traceroute below. If I ping the first NY based Teleglobe node (207.45.223.178), I also see about 12% loss If I ping the LA based Teleglobe node (207.45.222.181) 0% loss. JFL Les Cottrell wrote 1/15/01, 5:00pm PST > I do not believe this ticket should be closed. We are still experiencing bad > performance (15% packet loss from SLAC to ftp.platform,com). As I mentioned > earlier and your tests appear to confirm the problem appears to be between > ESnet and Teleglobe. Thus it will probably need cooperation between both > ISPs (Teleglob and ESnet) to pin-point the problem. I am therefore sending > this to trouble@es.net to request them to assist in pin pointing and > by-passing/solving the problem. For the latest information see: > http://www.slac.stanford.edu/grp/scs/net/case/platform/ TeleGlobe wrote at 1/15/01 4:35pm PST Dear Mr. Cottrell, We were provided with the latest update from our IP-Specialists: At the same time, we would like to verify status from your side; do you still experience other problems on your internet link? May we close this ticket for your convenience? PACKET LOSS OVER THE SPRINT FDDI RING TOWARD ORIGIN (STANFORD): PING TO ES PEER (AS293) GIN-SPN-BB1>PING PROTOCOL [IP]: TARGET IP ADDRESS: 192.157.69.12 REPEAT COUNT [5]: 1000 DATAGRAM SIZE [100]: 1500 TIMEOUT IN SECONDS [2]: EXTENDED COMMANDS [N]: SWEEP RANGE OF SIZES [N]: TYPE ESCAPE SEQUENCE TO ABORT. SENDING 1000, 1500-BYTE ICMP ECHOS TO 192.157.69.12, TIMEOUT IS 2 SECONDS: !!!!!!!!!!!!!!!.!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!.!!!!!!!!!!!!!!!!!.!!!!! !!.!.!!..!!!!!.!!...!!..!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!.!!. SUCCESS RATE IS 87 PERCENT (130/148), ROUND-TRIP MIN/AVG/MAX = 4/18/200 MS --- PACKET LOSS WITHIN AS6539 (WHERE FTP.PLATFORM.COM RESIDES): GIN-TTT-CORE2#PING PROTOCOL [IP]: TARGET IP ADDRESS: 192.219.104.253 REPEAT COUNT [5]: 10000 DATAGRAM SIZE [100]: 500 TIMEOUT IN SECONDS [2]: EXTENDED COMMANDS [N]: SWEEP RANGE OF SIZES [N]: TYPE ESCAPE SEQUENCE TO ABORT. SENDING 10000, 500-BYTE ICMP ECHOS TO 192.219.104.253, TIMEOUT IS 2 SECONDS: !!!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!.!!!.!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!.!!!!!.!!!!!.!!!!!!!.!!!!!!!!!!!!!! !!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!.!..!!!! !!!!!!!!!!!.!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!.! !!!.!!!!!!..!!..!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!.!!!.!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!! .!!!!!!!!!!!!!!!!!!!.!!!!!!!!!.!!!.!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!! .!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!! !!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!! !!!!!!!..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!.!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! .!!!!!!!!!!!!!!!!!!!!.!.!!!!!!!!!!.!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!..!!!!!!!!!!!!!!!!!!!!!!!!.!!!.!!!!!! !!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!.!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!.!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!.!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!...!!!!!!!!!!!!!!!!!!!!!!!!!. SUCCESS RATE IS 95 PERCENT (1834/1921), ROUND-TRIP MIN/AVG/MAX = 12/87/332 MS Les Cottrell wrote at 1/15/01 12:46pm PST. As Ed Russell says, we are still experiencing the problem (i.e. heavy packet loss as we enter the TeleGlobe network). This an be seen in the pingroute that I enclose below, where the losses start at hop 7. One place to look would be between ESnet and Teleglobe. As you say it is probably caused by congestion. This needs to be fixed. At this level of packet loss interactive applications are unusable, and even ftp will start to fail fairly regularly. For acomplete summary of what we know at the moment see: http://www.slac.stanford.edu/grp/scs/net/case/platform/ If you need to do a traceroute from SLAC then use the reverse traeroute server at: http://www.slac.stanford.edu/cgi-bin/nph-traceroute.pl Concerning your point 1, it is not latency that is bothering us but packet loss. Concerning your point 2, indeed the traces are not very useful for discovering the onset of packet loss, but pingroute and pchar/pipechar/pathchar can be helpful (to find these tools see http://www.slac.stanford.edu/xorg/nmtf/nmtf-tools.html), and the results from such tools are available at http://www.slac.stanford.edu/grp/scs/net/case/platform/ Also if you wish to a traceroute from the SLAC end then use the reverse traceroute server at http://www.slac.stanford.edu/cgi-bin/nph-traceroute.pl It might be useful to logon to your router at gin-nyy-bbl.teleglobe.net (192.157.69.33) and use its ping tool to look a packet loss in the 2 directions. You may also want to contact trouble@es.net or 1-800-33ESNET to get them to do pings from nyc-snv.es.net Concerning your point 3: One interesting (but fairly irrelevant since it has nothing to do with the problem of packet loss) observation is that a traceroute from a Windows NT machine at SLAC (and also at Stanford university) can detect the host ftp.platform.com (alias greyowl.platform.com), see the traceroute below. This maybe since WNT tracert uses UDP for its probes whereas Unix/Solaris uses ICMP, and maybe the ICMP probes are being blocked from ftp.platform.com. Other studies indicate taht ICMP echoes are not being blocked (and do not appear to be rate limited) to ftp.platform.com. Ed could you pursue this latter observation (traceroute cannot see ftp.platform.edu from a Unix machine) with Platform. Concerning your point 4, the problem is still with us and needs addressing. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Pingroute from Solaris machine at SLAC to ftp.platform.edu 4cottrell@flora06:~>bin/pingroute.pl -c 100 ftp.platform.com Mon Jan 15 10:26:44 2001 Architecture=SUN5, commands=traceroute -q 1 and ping -s ftp.platform.com 1400 100 pingroute.pl version=1.6, 1/15/01. Author cottrell@slac.stanford.edu, debug=1 pingroute.pl version 1.6, 1/15/01 using traceroute to get nodes in route from flora06 (w.x.y.z ) to ftp.platform.com traceroute: Warning: ckecksums disabled traceroute to greyowl.platform.com (192.219.104.253), 30 hops max, 40 byte packets pingroute.pl version 1.6, 1/15/01 found 30 hops in route from flora06 to ftp.platform.com 1 router (w.x.y.z) 0.627 ms 2 RTR-MSFC-DMZ.SLAC.Stanford.EDU (134.79.135.21) 0.647 ms 3 ESNET-A-GATEWAY.SLAC.Stanford.EDU (192.68.191.66) 0.748 ms 4 snv-slac.es.net (134.55.208.30) 1.484 ms 5 nyc-snv.es.net (134.55.205.22) 75.567 ms 6 nynap-nyc.es.net (134.55.208.146) 81.662 ms 7 gin-nyy-bbl.teleglobe.net (192.157.69.33) 98.237 ms 8 if-1-0-1.bb5.NewYork.Teleglobe.net (207.45.223.5) 99.873 ms 9 if-1-0.core2.NewYork.Teleglobe.net (207.45.221.66) 102.889 ms 10 if-1-0.core2.Scarborough.Teleglobe.net (207.45.220.164) 125.874 ms 11 ix-5-3.core2.Scarborough.Teleglobe.net (207.45.198.6) 128.077 ms 12 216.18.63.110 (216.18.63.110) 139.599 ms 13 mt-platform-3.mt.sfl.net (209.135.96.58) 129.326 ms 14 * 15 * 16 * 17 * 18 * 19 * 20 * 21 * 22 * 23 * 24 * 25 * 26 * 27 * 28 * 29 * 30 * Wrote 30 addresses to /tmp/pingaddr, now ping each address 100 times from flora06 pings/node=100 100 byte packets 1400 byte packets NODE %loss min max avg %loss min max avg from flora06 w.x.y.z router 0% 0.0 7.0 0.0 0% 1.0 11.0 1.0 Mon Jan 15 10:28:36 PST 2001 134.79.135.21 RTR-MSFC-DMZ.SLAC.STANFORD.EDU 0% 0.0 1.0 0.0 0% 1.0 12.0 1.0 Mon Jan 15 10:31:54 PST 2001 192.68.191.66 ESNET-A-GATEWAY.SLAC.STANFORD. 0% 0.0 398.0 18.0 0% 1.0 424.0 22.0 Mon Jan 15 10:35:12 PST 2001 134.55.208.30 SNV-SLAC.ES.NET 0% 1.0 11.0 1.0 0% 3.0 8.0 3.0 Mon Jan 15 10:38:30 PST 2001 134.55.205.22 NYC-SNV.ES.NET 0% 75.0 78.0 75.0 0% 76.0 79.0 77.0 Mon Jan 15 10:41:48 PST 2001 134.55.208.146 NYNAP-NYC.ES.NET 0% 80.0 223.0 85.0 0% 82.0 197.0 87.0 Mon Jan 15 10:45:07 PST 2001 192.157.69.33 GIN-NYY-BBL.TELEGLOBE.NET 13% 94.0 243.0 101.0 26% 95.0 302.0 104.0 Mon Jan 15 10:48:25 PST 2001 207.45.223.5 IF-1-0-1.BB5.NEWYORK.TELEGLOBE 16% 97.0 322.0 115.0 18% 99.0 477.0 128.0 Mon Jan 15 10:51:45 PST 2001 207.45.221.66 IF-1-0.CORE2.NEWYORK.TELEGLOBE 18% 98.0 108.0 102.0 15% 97.0 111.0 104.0 Mon Jan 15 10:55:06 PST 2001 207.45.220.164 IF-1-0.CORE2.SCARBOROUGH.TELEG 9% 117.0 133.0 125.0 14% 124.0 136.0 128.0 Mon Jan 15 10:58:26 PST 2001 207.45.198.6 IX-5-3.CORE2.SCARBOROUGH.TELEG 12% 108.0 297.0 128.0 26% 126.0 263.0 133.0 Mon Jan 15 11:01:46 PST 2001 216.18.63.110 216.18.63.110 24% 125.0 677.0 166.0 17% 129.0 716.0 163.0 Mon Jan 15 11:05:06 PST 2001 209.135.96.58 MT-PLATFORM-3.MT.SFL.NET 25% 128.0 216.0 151.0 18% 150.0 262.0 178.0 Mon Jan 15 11:08:26 PST 2001~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Traceroute from Windows NT machine at SLAC to ftp.platform.com -----Original Message----- From: Data Customer Service [mailto:DataCustomerService@teleglobe.ca] Sent: Sunday, January 14, 2001 9:51 PM To: Russell, Edwin S.; Data Customer Service Cc: Cottrell, Les; 'trouble@es.net'; Melen, Randal Subject: RE: Problems in Teleglobe/ 166619 Dear Mr. Russell, Thank you for your response. For your information, the trouble ticket was updated and forwarded to our internet specialists. They are pursuing the investigation, and we will keep you posted with more details as they become available. Should you need assistance in the meantime, please let us know. Regards, Julien Larose TELEGLOBE Global Customer Service Centre ( (514) 868-7875 7 (514) 868-8996 8 .trouble@teleglobe.net -----Message d'origine----- De : Edwin S. Russell [mailto:esr@SLAC.Stanford.EDU] Envoyé : 14 janvier, 2001 17:19 À : Data Customer Service Cc : 'Cottrell, Les'; 'trouble@es.net'; Randy Melen Objet : RE: Problems in Teleglobe/ 166619 On Sun, 14 Jan 2001, Data Customer Service wrote: > Greetings, > > As per the last e-mail sent to you by our customer service group, would > you be so kind as to let us know if we can close the ticket? In the > meantime the trouble ticket will remain on hold. We would like to assure > you that we are taking every step possible to resolve and ensure the quality > of the service. Should you have any concerns or if there is something else > we can assist you with, please feel free to communicate with us at any time. > > > Best regards, > > Karyne Soucy > Teleglobe > Global Customer Service > Tel: +514-868-7875 > Fax:+514-868-8996 > trouble@teleglobe.net Dr. Cottrell has apparently not checked email recently so I will respond until he has a chance to check more thoroughly. The answer is that things are _slightly_ better in that we now get only 20% packet loss with ping rather than the 33% we were getting yesterday. Response to anything going through your site is essentially unuseable. esr@farmboss $ ping ftp.platform.com PING greyowl.platform.com: (192.219.104.253): 56 data bytes 64 bytes from 192.219.104.253: icmp_seq=0 ttl=242 time=132 ms 64 bytes from 192.219.104.253: icmp_seq=1 ttl=242 time=128 ms 64 bytes from 192.219.104.253: icmp_seq=2 ttl=242 time=130 ms 64 bytes from 192.219.104.253: icmp_seq=3 ttl=242 time=155 ms 64 bytes from 192.219.104.253: icmp_seq=4 ttl=242 time=137 ms 64 bytes from 192.219.104.253: icmp_seq=5 ttl=242 time=131 ms 64 bytes from 192.219.104.253: icmp_seq=7 ttl=242 time=132 ms 64 bytes from 192.219.104.253: icmp_seq=9 ttl=242 time=132 ms ^C ----greyowl.platform.com PING Statistics---- 10 packets transmitted, 8 packets received, 20% packet loss round-trip min/avg/max = 128/134/155 ms esr@farmboss $ traceroute ftp.platform.com traceroute to greyowl.platform.com (192.219.104.253), 30 hops max, 40 byte packet s 1 router (w.x.y.z) 1 ms 0 ms 0 ms 2 RTR-MSFC-DMZ.SLAC.Stanford.EDU (134.79.135.21) 1 ms 1 ms 1 ms 3 ESNET-A-GATEWAY.SLAC.Stanford.EDU (192.68.191.66) 1 ms 1 ms 0 ms 4 snv-slac.es.net (134.55.208.30) 2 ms 1 ms 2 ms 5 nyc-snv.es.net (134.55.205.22) 75 ms 75 ms 75 ms 6 nynap-nyc.es.net (134.55.208.146) 81 ms 81 ms 81 ms 7 gin-nyy-bbl.teleglobe.net (192.157.69.33) 99 ms * 100 ms 8 * if-1-0-1.bb5.NewYork.Teleglobe.net (207.45.223.5) 104 ms 185 ms 9 * if-3-0.core2.NewYork.Teleglobe.net (207.45.221.98) 104 ms 106 ms 10 * if-2-3.core1.Scarborough.Teleglobe.net (207.45.220.2) 125 ms 130 ms 11 if-1-0.core2.Scarborough.Teleglobe.net (207.45.220.164) 124 ms 128 ms 128 ms 12 * ix-5-3.core2.Scarborough.Teleglobe.net (207.45.198.6) 125 ms 127 ms 13 216.18.63.110 (216.18.63.110) 132 ms * 127 ms 14 mt-platform-3.mt.sfl.net (209.135.96.58) 131 ms 129 ms * ping to nynap-nyc.es.net has no loss. ping to bb5.NewYork.Teleglobe.net has significant loss. esr@farmboss $ ping nynap-nyc.es.net PING nynap-nyc.es.net: (134.55.208.146): 56 data bytes 64 bytes from 134.55.208.146: icmp_seq=0 ttl=250 time=81 ms 64 bytes from 134.55.208.146: icmp_seq=1 ttl=250 time=80 ms 64 bytes from 134.55.208.146: icmp_seq=2 ttl=250 time=80 ms 64 bytes from 134.55.208.146: icmp_seq=3 ttl=250 time=81 ms 64 bytes from 134.55.208.146: icmp_seq=4 ttl=250 time=82 ms ^C ----nynap-nyc.es.net PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 80/80/82 ms esr@farmboss $ ping bb5.NewYork.Teleglobe.net PING gin-nyy-bb5.teleglobe.net: (207.45.223.248): 56 data bytes 64 bytes from 207.45.223.248: icmp_seq=1 ttl=248 time=100 ms 64 bytes from 207.45.223.248: icmp_seq=3 ttl=248 time=102 ms 64 bytes from 207.45.223.248: icmp_seq=4 ttl=248 time=105 ms 64 bytes from 207.45.223.248: icmp_seq=5 ttl=248 time=103 ms 64 bytes from 207.45.223.248: icmp_seq=6 ttl=248 time=100 ms 64 bytes from 207.45.223.248: icmp_seq=7 ttl=248 time=104 ms ^C ----gin-nyy-bb5.teleglobe.net PING Statistics---- 8 packets transmitted, 6 packets received, 25% packet loss round-trip min/avg/max = 100/102/105 ms > -----Message d'origine----- > De : Data Customer Service > Envoyé : 12 janv. 2001 23:20 > À : 'Cottrell, Les'; Data Customer Service; 'trouble@teleglobe.net' > Cc : 'trouble@es.net'; Russell, Edwin S. > Objet : Problems in Teleglobe/ 166619 > > > Dear Sirs, > > Thank you very much for the feedback that you sent us > regarding your existing trouble ticket 166619; please > note that our IP-Specialists have provided us with with > additional input, such as the following findings: > > 1) We performed a trace to the destination in question, in particular > to FTP.PLATFORM.COM; from the first Teleglobe Hop on the trace, > namely Hop 7, where we could not find any latency. > 2) Also, the traces cannot tell whether there are packet losses; > in fact, the cause of the packet-loss problem could have been high > utilization of the link - unfortunately, we do not have access to > your link - also, we could not determine a bad return path > > 3) Moreover, as demonstrated in the analysis from below, both your and > our traces timed out at the end of the destination network but we were > able to get there. > > 4) Could you please confirm if the status of your link is back to > normal and we can proceed to close this ticket for your convenience? > > *********************************Start of Analysis************************** > GIN-SPN-BB1>TR FTP.PLATFORM.COM > TRANSLATING "FTP.PLATFORM.COM"...DOMAIN SERVER (199.202.55.2) [OK] > > TYPE ESCAPE SEQUENCE TO ABORT. > TRACING THE ROUTE TO GREYOWL.PLATFORM.COM (192.219.104.253) > > 1 IF-1-0-0.BB5.NEWYORK.TELEGLOBE.NET (207.45.223.85) 4 MSEC > IF-1-0-1.BB5.NEWYORK.TELEGLOBE.NET (207.45.223.5) 8 MSEC > IF-1-0-0.BB5.NEWYORK.TELEGLOBE.NET (207.45.223.85) 0 MSEC > 2 IF-3-0.CORE2.NEWYORK.TELEGLOBE.NET (207.45.221.98) 8 MSEC > IF-1-0.CORE2.NEWYORK.TELEGLOBE.NET (207.45.221.66) 0 MSEC > IF-3-0.CORE2.NEWYORK.TELEGLOBE.NET (207.45.221.98) 4 MSEC > 3 IF-2-3.CORE1.SCARBOROUGH.TELEGLOBE.NET (207.45.220.2) 24 MSEC 28 MSEC 28 > MSEC > 4 IF-1-0.CORE2.SCARBOROUGH.TELEGLOBE.NET (207.45.220.164) 28 MSEC 28 MSEC > 28 MSEC > 5 IX-5-3.CORE2.SCARBOROUGH.TELEGLOBE.NET (207.45.198.6) 28 MSEC 28 MSEC 28 > MSEC > 6 216.18.63.110 [AS 6539] 36 MSEC 32 MSEC 32 MSEC > 7 MT-PLATFORM-3.MT.SFL.NET (209.135.96.58) [AS 6539] 84 MSEC 68 MSEC 60 > MSEC > 8 * * * > 9 * * * > 10 * * * > 11 * * * > **************************************End of > Analysis************************* > > Regards, > > Andrea Eble > Global Data Services Agent > Teleglobe - Customer Service > Tel: +514-868-7875 > Fax: +514-868-8996 > Email - General: cservice@teleglobe.com > Email - Internet: trouble@teleglobe.net > > > -----Message d'origine----- > De : Cottrell, Les [mailto:cottrell@SLAC.Stanford.EDU] > Envoyé : 01-01-12 21:50 > À : 'Data Customer Service'; 'trouble@teleglobe.net' > Cc : 'trouble@es.net'; Russell, Edwin S. > Objet : RE: Problems in Teleglobe/ 166619 > > > We (SLAC) do not run a 24x7 NOC. Our ISP, ESnet, does. Their email address > is trouble@es.net and their phone is 1-800-33ESNET. As for intrusive > testing, we would need to have a better idea of what you have in mind. Using > traceroute and ping to our site is fine (a good host to test is > www.slac.stanford.edu since it is always up). I am reachable by email and > read my email at weekends. I am the site's technical point of contact for > this trouble ticket. If you need to reach me during normal working hours > (PST) my number is 650-926-2523. Hope that helps. > > -----Original Message----- > From: Data Customer Service [mailto:DataCustomerService@teleglobe.ca] > Sent: Friday, January 12, 2001 1:06 PM > To: Cottrell, Les; Data Customer Service; 'trouble@teleglobe.net' > Cc: 'trouble@es.net'; Russell, Edwin S. > Subject: RE: Problems in Teleglobe/ 166619 > > > Greetings, > > Thank you Sir for the information, we have opened a trouble ticket on your > behalf, the ticket number is 166619. We have forwarded this information to > our technical staff and as soon as more details become available we will > contact you immediately. In order to conduct a faster investigation, would > you be so kind as to provide us with a telephone number of a technical point > of contact 24/7? Also, please advise if it is possible to conduct intrusive > testing if need be and the time the tests could be performed? We do > appreciate your assistance in this matter and we hope to hear from you > shortly. > > > Best regards, > > > Eunice Fernandes > Teleglobe GCSC > Tel: 514 868 7875 Fax: 514 868 8996 > E-Mail: Efernand@teleglobe.com > > > > -----Message d'origine----- > De : Cottrell, Les [mailto:cottrell@SLAC.Stanford.EDU] > Envoyé : 01-01-12 15:48 > À : 'Data Customer Service'; 'trouble@teleglobe.net' > Cc : 'trouble@es.net'; Russell, Edwin S. > Objet : RE: Problems in Teleglobe > > > There is a traceroute and much more in the refernced URL below (or you can > go directly to > http://www.slac.stanford.edu/grp/scs/net/case/platform/traceroute). I have > also extracted the traceroute and will embed it below: > > esr@farmboss $ traceroute ftp.platform.com > traceroute to greyowl.platform.com (192.219.104.253), 30 hops max, 40 byte > packets > 1 router (w.x.y.z) 1 ms 0 ms 0 ms > 2 RTR-MSFC-DMZ.SLAC.Stanford.EDU (134.79.135.21) 1 ms 1 ms 1 ms > 3 ESNET-A-GATEWAY.SLAC.Stanford.EDU (192.68.191.66) 1 ms 1 ms 0 ms > 4 snv-slac.es.net (134.55.208.30) 2 ms 2 ms 2 ms > 5 nyc-snv.es.net (134.55.205.22) 75 ms 75 ms 75 ms > 6 nynap-nyc.es.net (134.55.208.146) 81 ms 81 ms 81 ms > 7 gin-nyy-bbl.teleglobe.net (192.157.69.33) 98 ms * 98 ms > 8 if-1-0-1.bb5.NewYork.Teleglobe.net (207.45.223.5) 117 ms 142 ms * > 9 if-3-0.core2.NewYork.Teleglobe.net (207.45.221.98) 101 ms 101 ms 123 > ms > 10 if-1-0.core2.Scarborough.Teleglobe.net (207.45.220.164) 128 ms * 126 > ms > 11 ix-5-3.core2.Scarborough.Teleglobe.net (207.45.198.6) 129 ms * 157 ms > 12 216.18.63.110 (216.18.63.110) 160 ms 133 ms 136 ms > 13 mt-platform-3.mt.sfl.net (209.135.96.58) 199 ms * 217 ms > 14 * * * > ^C > > -----Original Message----- > From: Data Customer Service [mailto:DataCustomerService@teleglobe.ca] > Sent: Friday, January 12, 2001 10:43 AM > To: Cottrell, Les; 'trouble@teleglobe.net' > Cc: 'trouble@es.net' > Subject: RE: Problems in Teleglobe > > > Greetings, > > Thank you for your e-mail, however in order to conduct an investigation > would you be so kind as to provide us with a trace route in a TEXT format in > order to forward it to our Internet specialist? We will then be able to > provide you with a trouble ticket. We thank you in advance for your > assistance and await your reply. > > > Best regards, > > > Eunice Fernandes > Teleglobe GCSC > Tel: 514 868 7875 Fax: 514 868 8996 > E-Mail: Efernand@teleglobe.com > > > > -----Message d'origine----- > De : Cottrell, Les [mailto:cottrell@SLAC.Stanford.EDU] > Envoyé : 01-01-12 13:31 > À : 'trouble@teleglobe.net' > Cc : 'trouble@es.net' > Objet : Problems in Teleglobe > > > We appear to be seeing heavy packet loss in the Teleglobe network. See > http://www.slac.stanford.edu/grp/scs/net/case/platform/ > for more details.