RE: Color vision for network techs
For pulling cable, the colors are fixed inside the jacket. I have found differences in cable manufacturers and prefer Mohawk brand cable because the colors are easier for me to see. White is white instead of clear. Blue, green, orange and brown are noticeably different. So, my take is stick to manufacturers that do a good job. If my tired old eyes can tell the difference, the employees that work with me probably won't have a problem. Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com -Original Message- From: Larry LaBas [mailto:lla...@gmail.com] Sent: Friday, August 31, 2012 10:55 AM To: telmn...@757.org Cc: nanog@nanog.org Subject: Re: Color vision for network techs The Military has colour screening for obvious reasons but I am not sure if it's needed for Networking. My take is that I designed all to have a wide variance. IE: Red, Blue, Yellow and Black which helped lower issues. Not solve them but if you limit the use of Red to certain areas (ie: Yellow / Red on one patch panel) then it helps. Yes, I did have a team lead who was colour blind and that did help to lead me down that path. When he was on our internet facing patch panel which was Red/Yellow if he saw black he knew it was Red. Sincerely, Larry A. LaBas(CD) On Fri, Aug 31, 2012 at 7:46 AM, telmn...@757.org wrote: When doing Cat5 connectors, a friend couldn't tell the orange versus brown (or was it green.) He found that with a red LED flashlight he could then tell. There are ways to work around things.
Re: yahoo admin mail contact (or answer)
Check reverse DNS. We had same problem with AOL. Sent from my iPhone On Aug 16, 2012, at 12:51 PM, Georgios Vlachos g.vlac...@kestrel-is.gr wrote: Hello all, We put into production a new mailserver 2 weeks ago, and we can send email to everybody (no complaints and testing) except yahoo! All their mailservers reset the TCP connections, before SMTP even starts. This happens randomly on all their mta (look below). As a sequence almost half the email we send to yahoo stay in the queue for a day in our mailserver and then get discarded (with a connection died message). We get the SYN, SYN-ACK, ACK normal handshake and then a TCP reset from their mailserver. Any idea or off-list contact is very welcome. From their website I could not find a way to email them. C:\Windows\system32dig yahoo.com MX ; DiG 9.3.2 yahoo.com MX ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 970 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 24 ;; QUESTION SECTION: ;yahoo.com. IN MX ;; ANSWER SECTION: yahoo.com. 72 IN MX 1 mta6.am0.yahoodns.net. yahoo.com. 72 IN MX 1 mta7.am0.yahoodns.net. yahoo.com. 72 IN MX 1 mta5.am0.yahoodns.net. ;; ADDITIONAL SECTION: mta6.am0.yahoodns.net. 141 IN A 66.196.118.34 mta6.am0.yahoodns.net. 141 IN A 66.196.118.36 mta6.am0.yahoodns.net. 141 IN A 67.195.168.230 mta6.am0.yahoodns.net. 141 IN A 98.136.217.202 mta6.am0.yahoodns.net. 141 IN A 98.139.54.60 mta6.am0.yahoodns.net. 141 IN A 66.94.237.64 mta6.am0.yahoodns.net. 141 IN A 66.94.237.139 mta6.am0.yahoodns.net. 141 IN A 66.94.238.147 mta7.am0.yahoodns.net. 289 IN A 98.139.54.60 mta7.am0.yahoodns.net. 289 IN A 66.94.236.34 mta7.am0.yahoodns.net. 289 IN A 66.94.237.64 mta7.am0.yahoodns.net. 289 IN A 66.196.118.33 mta7.am0.yahoodns.net. 289 IN A 66.196.118.35 mta7.am0.yahoodns.net. 289 IN A 67.195.168.230 mta7.am0.yahoodns.net. 289 IN A 98.136.216.26 mta7.am0.yahoodns.net. 289 IN A 98.136.217.202 mta5.am0.yahoodns.net. 185 IN A 66.196.118.35 mta5.am0.yahoodns.net. 185 IN A 66.196.118.36 mta5.am0.yahoodns.net. 185 IN A 98.136.216.25 mta5.am0.yahoodns.net. 185 IN A 98.136.216.26 mta5.am0.yahoodns.net. 185 IN A 98.136.217.202 mta5.am0.yahoodns.net. 185 IN A 66.94.236.34 mta5.am0.yahoodns.net. 185 IN A 66.94.238.147 mta5.am0.yahoodns.net. 185 IN A 66.196.118.34 Thank you, Georgios Vlachos ___ Kestrel Information Systems s.a. 340, Kifissias Ave., 154 51, Neo Psychico, Athens Τ.: +30.210.6747740, ext. 105 F.: +30.210.6771585 M.: +30.6936 807513 http://www.kestrel-is.gr/ logo kestrel.jpg
RE: [SMBManagedServices] RE: next hop packet loss
Get a load of this: New version of Firefox works fine. Methinks Mozilla released a turd. -Original Message- From: smbmanagedservi...@yahoogroups.com [mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of James_TDS Sent: Friday, August 10, 2012 11:47 AM To: smbmanagedservi...@yahoogroups.com Subject: RE: [SMBManagedServices] RE: next hop packet loss As I said I suspect Checkpoint is breaking the Internet in an attempt to block various DDOS attacks. The failure of tracert and ICMP is not isolated to Checkpoint and Above.net as I had a similar problem with a local TW customer on a static IP. Because their in house router was down and not responding to anything TW would drop the Tracert long before it even came close to my client. I gave them heck about this as it made it impossible to remotely monitor the customer because when the customer calls and says the Internet is down the first thing I do is tracert to their IP. When I see the route die in another city that tells me the ISP is having issues vs. the route dying one hop out from my customer's IP. They gave me some crap about active routing and such. Put anything on that IP and have it respond to pings and the route will complete. As I said Telnet checkpoint.com 80 fails for me but SLChecker works so again it's probably some DDOS thing and they are checking user agents before replying and I assume SLCheck mimics IE or something. Handy tool. -Original Message- From: smbmanagedservi...@yahoogroups.com [mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of Jim Ray Sent: Friday, August 10, 2012 8:23 AM To: smbmanagedservi...@yahoogroups.com Subject: RE: [SMBManagedServices] RE: next hop packet loss I am stumped why http://www.checkpoint.com won't resolve with Firefox yet will with Internet Explorer and Safari. I know Microsoft won't let you do what you need to do with Firefox yet am surprised with Check Point. Above.net is not echoing ICMP, though, before one reaches Check Point. From the NANOG group, I found out it is possible to use command line switch to specify type of traffic and to get around ICMP issue. Apparently, TCP works; however, another person said UDP is preferred embodiment. This test resolved web site yet resulted in lost connection: telnet www.checkpoint.com 80 GET / HTTP/1.1 Host: www.checkpoint.com I captured packets with Wireshark yet did not see anything that jumped out at me as root cause for failure. Meanwhile back at the ranch, my friend brought over business card for Check Point representative, and I plan to pick up the phone and call thereby bypassing TCP/IP in its entirety. -Original Message- From: smbmanagedservi...@yahoogroups.com [mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of James_TDS Sent: Thursday, August 09, 2012 10:50 AM To: smbmanagedservi...@yahoogroups.com Subject: RE: [SMBManagedServices] RE: next hop packet loss Go back a few post and see where I mentioned that the hop in question was not responding to the ICMP request, it wasn't down they just refuse to echo. Probably a more valid test would have been: telnet checkpoint.com 80 GET However I just tested that as well and Checkpoint doesn't respond correctly. Not sure what they are doing on the frontend but they are breaking Internet rules probably in an effort to not be DDOS'd. I checked again with SLChecker and it responds correctly so they are likely not responding to Telnet because it doesn't send a user agent ID. -Original Message- From: smbmanagedservi...@yahoogroups.com [mailto:smbmanagedservi...@yahoogroups.com] On Behalf Of Jim Ray Sent: Thursday, August 09, 2012 8:39 AM To: smbmanagedservi...@yahoogroups.com Cc: Herring, David Subject: [SMBManagedServices] RE: next hop packet loss Hey, I get the idgit award for this one. Time Warner's next hop that was dropping packets was really a situation where next hop was not responding to ICMP from tracert. Neither of us was able to diagnose the problem until last night when I found out Safari pulled up http://www.checkpoint.com from same network and Firefox on PC did not. So, apparently, Check Point does not like Firefox. Internet Explorer worked. Meanwhile back at the ranch, I have learned about TCP switch in tracert thanks to peers here and on NANOG and have gotten down and dirty with Wireshark. Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com -Original Message- From: Herring, David [mailto:david.herr...@twcable.com] Sent: Thursday, August 09, 2012 7:54 AM To: Jim Ray; Adrian Bool Subject: RE: next hop packet loss Got it.. no worries.. I know we are not always the best either! What would be great- that you let the below be known to your user group? I know we let them know when we thought it was Business class problem... David Herring Channel Manager | Channel Partner Program, East Region TWC Business Class 101
RE: next hop packet loss
They've had me blocked for a few weeks now. I've always been able to reach it on Verizon network with iPhone, just not with Time Warner Business Class. I plan to take advice from kind members of group that offered it and investigate a little more with Wireshark yet have been in middle of client migration of aging Exchange 2003 server to 2010 version in the cloud since Friday. http://www.CheckPoint.com can wait. I had a great face to face meeting with person from another UTM company this morning http://www.sophos.com Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com -Original Message- From: Eugeniu Patrascu [mailto:eu...@imacandi.net] Sent: Wednesday, August 08, 2012 5:07 AM To: Jim Ray Cc: t...@ninjabadger.net; nanog@nanog.org Subject: Re: next hop packet loss On Tue, Aug 7, 2012 at 4:12 PM, Jim Ray j...@neuse.net wrote: Sorry, I do not give verbose responses via iPhone on that small device with my tired old eyes. I ran Wireshark this morning. Without sniffing packets, the layman's description of problem is I can't get to vendor web site, http://www.CheckPoint.com, on Time Warner Business Class network I use. Hence, http is blocked in addition to ICMP. Yesterday, Check Point's website was unreachable from other parts of the world for some time with intermittent access for around an hour or so I believe. Eugeniu
RE: next hop packet loss
telnet www.checkpoint.com 80 GET / HTTP/1.1 Host: www.checkpoint.com ...resolved some information and then lost connection according to this trailer from the screen scrape: !-- Column 2 -- div class=column !--- h2a href=https://supportcenter.checkpoint.com/supportcenter/p ortal?ev Connection to host lost. Site resolves fine on Verizon network with my iPhone and not on Time Warner network. Maybe Check Point is mad because my network is behind a Sonic Wall and not their product. Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com -Original Message- From: wher...@gmail.com [mailto:wher...@gmail.com] On Behalf Of William Herrin Sent: Tuesday, August 07, 2012 10:51 AM To: Jim Ray Cc: nanog@nanog.org Subject: Re: next hop packet loss On Mon, Aug 6, 2012 at 11:27 AM, Jim Ray j...@neuse.net wrote: I have a Time Warner Business Class connection and am unable to reach http://www.checkpoint.com to research product line I wish to carry. I did a trace route and confirmed packets are past my network, Time Warner network and onto next hop where they execute jump to nowhere instruction. Here is the tracert just now (it has been failing for weeks): That's an artifact of Checkpoint blocking pings. Note the difference between ICMP and TCP-based traceroutes: traceroute -I 216.200.241.66 traceroute to 216.200.241.66 (216.200.241.66), 30 hops max, 60 byte packets 1 sark.dirtside.com (70.182.189.216) 0.462 ms 0.494 ms 0.555 ms 2 10.1.192.1 (10.1.192.1) 9.023 ms 9.197 ms 9.247 ms 3 ip72-196-255-1.dc.dc.cox.net (72.196.255.1) 15.210 ms 15.497 ms 15.548 ms 4 mrfddsrj01gex070003.rd.dc.cox.net (68.100.0.141) 13.594 ms 13.765 ms 13.817 ms 5 68.1.4.139 (68.1.4.139) 14.752 ms 15.016 ms 14.951 ms 6 ge-8-0-7.er2.iad10.us.above.net (64.125.12.241) 15.075 ms 9.565 ms 9.384 ms 7 xe-5-1-0.cr2.dca2.us.above.net (64.125.29.77) 33.238 ms 26.629 ms 26.554 ms 8 xe-2-2-0.cr2.iah1.us.above.net (64.125.30.53) 45.079 ms 45.230 ms 45.264 ms 9 xe-0-3-0.cr2.lax112.us.above.net (64.125.30.50) 75.982 ms 76.212 ms 76.154 ms 10 xe-2-1-0.cr2.sjc2.us.above.net (64.125.26.30) 93.901 ms 94.044 ms 88.715 ms 11 xe-1-1-0.er2.sjc2.us.above.net (64.125.26.202) 88.542 ms 88.885 ms 90.094 ms 12 64.124.201.230.b709.above.net (64.124.201.230) 89.691 ms 89.060 ms 88.895 ms 13 * * * 14 * * * 15 * * * traceroute -T -p 80 216.200.241.66 traceroute to 216.200.241.66 (216.200.241.66), 30 hops max, 60 byte packets 1 sark.dirtside.com (70.182.189.216) 0.487 ms 0.520 ms 0.568 ms 2 10.1.192.1 (10.1.192.1) 20.018 ms 24.851 ms 25.144 ms 3 ip72-196-255-1.dc.dc.cox.net (72.196.255.1) 25.415 ms 25.502 ms 25.591 ms 4 mrfddsrj01gex070003.rd.dc.cox.net (68.100.0.141) 25.139 ms 25.178 ms 25.260 ms 5 68.1.4.139 (68.1.4.139) 37.509 ms 37.437 ms 37.362 ms 6 ge-5-3-0.mpr2.iad10.us.above.net (64.125.13.57) 91.097 ms 89.808 ms ge-8-0-7.er2.iad10.us.above.net (64.125.12.241) 24.078 ms 7 xe-5-1-0.cr2.dca2.us.above.net (64.125.29.77) 26.324 ms 11.950 ms 12.477 ms 8 xe-2-2-0.cr2.iah1.us.above.net (64.125.30.53) 74.680 ms 74.575 ms 74.355 ms 9 xe-0-3-0.cr2.lax112.us.above.net (64.125.30.50) 76.781 ms 76.330 ms 76.118 ms 10 xe-2-1-0.cr2.sjc2.us.above.net (64.125.26.30) 100.310 ms 100.026 ms 98.495 ms 11 xe-1-1-0.er2.sjc2.us.above.net (64.125.26.202) 98.631 ms 93.570 ms 94.380 ms 12 64.124.201.230.b709.above.net (64.124.201.230) 94.420 ms 97.053 ms 95.015 ms 13 208.185.174.208 (208.185.174.208) 96.208 ms 96.541 ms 96.384 ms 14 www.checkpoint.com (216.200.241.66) 97.406 ms 97.534 ms 97.891 ms Since you get all the way to the Checkpoint border, try some basic diagnostics like: telnet www.checkpoint.com 80 GET / HTTP/1.1 Host: www.checkpoint.com Wait for the telnet to succeed before you type GET. Make sure you press enter twice after the last line. You're hand-jamming an HTTP request. If you don't connect then checkpoint is blocking your IP address for one reason or another. Maybe there are hackers in your neighborhood. Take it up with them by phone. If you do connect but get no response to the get http request then most likely checkpoint is blocking all ICMP packets and your path MTU is smaller than 1500 bytes. The ICMP block prevents the fragmentation needed message from reaching their web server, so it never figures out it needs to shorten its packets. If, as a firewall company, they have made this beginner mistake... 'nuff said. And of course if you do get complete content back from the web server then you have some other problem with your PC that's getting in the way. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Packets dropped due to ICMP off
Awe, man, don't laugh too hard. Turned out to be problem with Firefox. Safari on iPhone and IE on PC work. I learned something, too, and appreciate the input: tracert using ICMP is not valid test. Not everyone has ping enabled. So, what looks like packet loss at next hop is really ICMP turned off. Sent from my iPhone
RE: next hop packet loss
Sorry, I do not give verbose responses via iPhone on that small device with my tired old eyes. I ran Wireshark this morning. Without sniffing packets, the layman's description of problem is I can't get to vendor web site, http://www.CheckPoint.com, on Time Warner Business Class network I use. Hence, http is blocked in addition to ICMP. It is what it is. Personally, I plan to use the phone to reach Check Point since TCP/IP won't work. I also got call back from top local executive at Time Warner this morning that has known me 17 years, understands the problem and is trying to help. Again, no emergency here. Still, I would like it to work and pay extra to have the commercial connection with service level agreement. Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com -Original Message- From: t...@ninjabadger.net [mailto:t...@ninjabadger.net] Sent: Tuesday, August 07, 2012 5:38 AM To: Jim Ray Cc: Tom Hill; nanog@nanog.org Subject: Re: next hop packet loss Well, you haven't provided any proof of that. Their website works just fine for me (TM). Since your troubleshooting is limited to methods that are blocked by Checkpoint's network, you might need to revisit how you're going about diagnosing the problem you're facing. In any case, I won't be providing any further input following that response. Tom It is a problem with http protocol regardless of ICMP. Sent from my iPhone On Aug 6, 2012, at 5:51 PM, Tom Hill t...@ninjabadger.net wrote: Hi Jim, On 06/08/12 22:27, Jim Ray wrote: What is the best way to solve this type of problem? It's not a problem, it's checkpoint purporting to be 'secure' when all they're doing is blocking ICMP outright, seemingly. If I try 'tcptraceroute' (from Linux) it works just fine, bare the Above.net hop in the middle that doesn't respond - ignore. $ sudo tcptraceroute -n checkpoint.com traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte packets 1 81.187.203.81 0.719 ms 1.050 ms 1.298 ms 2 90.155.53.54 30.184 ms 31.604 ms 32.370 ms 3 90.155.53.43 33.891 ms 35.072 ms 36.021 ms 4 85.91.238.217 37.016 ms 38.236 ms 39.215 ms 5 85.91.224.10 40.226 ms 41.358 ms 42.354 ms 6 212.187.200.145 164.713 ms 164.102 ms 164.020 ms 7 4.69.139.99 45.316 ms 194.042 ms 194.088 ms 8 64.125.14.17 194.297 ms 193.943 ms 193.558 ms 9 64.125.31.198 194.304 ms 194.462 ms 193.560 ms 10 * * * 11 64.125.26.37 288.267 ms 284.237 ms 166.340 ms 12 64.125.24.38 178.571 ms 179.467 ms 156.769 ms 13 64.125.28.238 148.002 ms 147.244 ms 147.501 ms 14 64.125.26.141 206.010 ms 205.574 ms 205.426 ms 15 64.125.28.57 201.753 ms 172.439 ms 174.169 ms 16 64.124.201.230 176.866 ms 172.412 ms 172.510 ms 17 208.185.174.208 173.668 ms 174.310 ms 173.999 ms 18 216.200.241.66 syn,ack 172.504 ms 172.386 ms 172.700 ms Tom
next hop packet loss
Good afternoon. I am a newbie to this group, and this post is my first post ever. A friend from another list recommended this group. I have a Time Warner Business Class connection and am unable to reach http://www.checkpoint.com to research product line I wish to carry. I did a trace route and confirmed packets are past my network, Time Warner network and onto next hop where they execute jump to nowhere instruction. Time Warner says it is off their network, and they can't help. I received no reply from above.net next hop. What is the best way to solve this type of problem? Here is the tracert just now (it has been failing for weeks): C:\Documents and Settings\jim.raytracert checkpoint.com Tracing route to checkpoint.com [216.200.241.66] over a maximum of 30 hops: 152 ms28 ms37 ms 10.129.96.1 210 ms12 ms16 ms ten13-0-0-238.rlghnca-rtr1.nc.rr.com [66.26.32.2 42] 316 ms12 ms12 ms ae19.rlghncpop-rtr1.southeast.rr.com [24.93.64.0 ] 419 ms23 ms24 ms 107.14.19.20 516 ms19 ms19 ms 107.14.19.133 628 ms20 ms19 ms xe-0-1-1.er2.iad10.us.above.net [64.125.12.61] 723 ms19 ms19 ms xe-2-0-0.cr2.dca2.us.above.net [64.125.31.209] 874 ms49 ms56 ms xe-0-2-0.cr2.iah1.us.above.net [64.125.28.50] 977 ms79 ms79 ms xe-0-3-0.cr2.lax112.us.above.net [64.125.30.50] 1085 ms86 ms86 ms xe-1-0-0.cr2.sjc2.us.above.net [64.125.31.233] 1184 ms92 ms86 ms xe-1-1-0.er2.sjc2.us.above.net [64.125.26.202] 1286 ms86 ms 105 ms 64.124.201.230.b709.above.net [64.124.201.230] 13 *** Request timed out. 14 *** Request timed out. 15 *** Request timed out. 16 *** Request timed out. 17 *** Request timed out. 18 *** Request timed out. 19 *** Request timed out. 20 *** Request timed out. 21 *** Request timed out. 22 *** Request timed out. 23 *** Request timed out. 24 *** Request timed out. 25 *** Request timed out. 26 *** Request timed out. 27 *** Request timed out. 28 *** Request timed out. 29 *** Request timed out. 30 *** Request timed out. Trace complete. Regards, Jim Ray, President Neuse River Networks 2 Davis Drive, PO Box 13169 Research Triangle Park, NC 27709 919-838-1672 x100 www.NeuseRiverNetworks.com http://www.neuserivernetworks.com/ http://www.neuserivernetworks.com/ image001.jpg
Re: next hop packet loss
It is a problem with http protocol regardless of ICMP. Sent from my iPhone On Aug 6, 2012, at 5:51 PM, Tom Hill t...@ninjabadger.net wrote: Hi Jim, On 06/08/12 22:27, Jim Ray wrote: What is the best way to solve this type of problem? It's not a problem, it's checkpoint purporting to be 'secure' when all they're doing is blocking ICMP outright, seemingly. If I try 'tcptraceroute' (from Linux) it works just fine, bare the Above.net hop in the middle that doesn't respond - ignore. $ sudo tcptraceroute -n checkpoint.com traceroute to checkpoint.com (216.200.241.66), 30 hops max, 60 byte packets 1 81.187.203.81 0.719 ms 1.050 ms 1.298 ms 2 90.155.53.54 30.184 ms 31.604 ms 32.370 ms 3 90.155.53.43 33.891 ms 35.072 ms 36.021 ms 4 85.91.238.217 37.016 ms 38.236 ms 39.215 ms 5 85.91.224.10 40.226 ms 41.358 ms 42.354 ms 6 212.187.200.145 164.713 ms 164.102 ms 164.020 ms 7 4.69.139.99 45.316 ms 194.042 ms 194.088 ms 8 64.125.14.17 194.297 ms 193.943 ms 193.558 ms 9 64.125.31.198 194.304 ms 194.462 ms 193.560 ms 10 * * * 11 64.125.26.37 288.267 ms 284.237 ms 166.340 ms 12 64.125.24.38 178.571 ms 179.467 ms 156.769 ms 13 64.125.28.238 148.002 ms 147.244 ms 147.501 ms 14 64.125.26.141 206.010 ms 205.574 ms 205.426 ms 15 64.125.28.57 201.753 ms 172.439 ms 174.169 ms 16 64.124.201.230 176.866 ms 172.412 ms 172.510 ms 17 208.185.174.208 173.668 ms 174.310 ms 173.999 ms 18 216.200.241.66 syn,ack 172.504 ms 172.386 ms 172.700 ms Tom
