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.