Google contact?
Having a bit of diffculty with a Google matter. Was hoping to get pointed in the right direction by someone from Google. --Patrick Darden [EMAIL PROTECTED]
Re: Abuse response [Was: RE: Yahoo Mail Update]
William Herrin wrote: On Tue, Apr 15, 2008 at 8:49 PM, Martin Hannigan [EMAIL PROTECTED] wrote: Abuse desk is a $0 revenue operation. Is it not obvious what the issue is? Martin, So is marketing, yet marketing does have an impact on revenue. It can be useful to explain the abuse desk as being just another form of marketing, another form of reputation management that happens to be specific to Internet companies. Handling the abuse desk well (or poorly) builds (or damages) the brand. Even IF the reputation of an abuse desk had any effect at all on bringing in revenue (doubtful) ... I'm quite certain that dollar for dollar, the ROI on investment in Marketing generates MUCH greater revenue returns than investment in Abuse desk staff. Properly staffing an abuse desk is something a business does because It Is The Right Thing To Do, not because it's the best investment for their marketing dollars. jc
RE: Google contact?
Thanks everyone! Several people from Google responded very quickly, and the issue was resolved faster than I can believe. --Patrick Darden --ARMC
RE: Google contact?
It'd be nice if more companies of their size responded that way. :) -Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darden, Patrick S. Sent: Thursday, April 17, 2008 1:40 PM To: nanog@merit.edu Subject: RE: Google contact? Thanks everyone! Several people from Google responded very quickly, and the issue was resolved faster than I can believe. --Patrick Darden --ARMC
Re: Google contact?
Raymond L. Corbin wrote: It'd be nice if more companies of their size responded that way. :) they have ~6% of the employees of the employees of say verizon and slightly less than the 123 years of cruft that the later has. -Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darden, Patrick S. Sent: Thursday, April 17, 2008 1:40 PM To: nanog@merit.edu Subject: RE: Google contact? Thanks everyone! Several people from Google responded very quickly, and the issue was resolved faster than I can believe. --Patrick Darden --ARMC
Cogent Router dropping packets
Hi, Some of our VoIP customers are experiencing issues using our service and it only happens when routing through Cogent. Does anyone have a contact for them? Thanks Host Loss% Snt Last Avg Best Wrst StDev 1. adsl-63-194-xxx-xxx.dsl.lsan03.pacbell.net 0.0% 6049 13.7 24.2 8.4 72.2 11.1 2. dist3-vlan60.irvnca.sbcglobal.net 2.0% 6049 19.0 23.5 8.6 217.4 13.5 3. bb1-p6-7.emhril.ameritech.net 0.0% 6049 31.7 43.0 8.6 317.3 46.4 4. ex2-p14-0.eqlaca.sbcglobal.net 0.0% 6049 19.8 44.3 9.4 487.8 49.5 5. te8-1.mpd01.lax05.atlas.cogentco.com0.0% 6049 15.0 41.1 9.5 675.9 53.4 6. vl3491.ccr02.lax01.atlas.cogentco.com 3.3% 6049 34.3 29.4 9.9 337.5 25.4 7. te3-4.ccr01.lax04.atlas.cogentco.com5.2% 6049 19.3 30.1 10.4 275.1 23.6 8. vl3805.na21.b002695-2.lax04.atlas.cogentco.com 5.1% 6049 35.0 27.7 10.2 227.3 12.2 9. PAETEC_Communications_Inc.demarc.cogentco.com 5.3% 6049 18.3 35.8 9.8 252.4 33.6 10. gi-4-0-1-3.core01.lsajca01.paetec.net 5.5% 6049 17.3 37.9 13.3 1054. 43.5 11. po-5-0-0.core01.anhmca01.paetec.net 5.5% 6049 30.7 37.5 13.7 1042. 37.9 12. gi-3-0-0.edge03.anhmca01.paetec.net 5.3% 6049 19.7 33.3 12.9 385.1 20.7 13. 74.10.xxx.xxx5.9% 6049 23.8 35.8 18.1 86.5 11.8 14. 74.10.xxx.xxx5.2% 6049 40.4 36.4 18.0 91.1 11.8
Re: Google contact?
On Thu, 17 Apr 2008, Joel Jaeggli wrote: they have ~6% of the employees of the employees of say verizon and slightly less than the 123 years of cruft that the later has. Verizon is one company in name only. There are so many groups and business units, all with their own inbound numbers and no communication between them. Several hundred left hands and several hundred right hands, if you get my meaning. jms
Re: Cogent Router dropping packets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just spoke to cogent about another issue, said they only know about issues in Los Angeles. Nevertheless, 877.726.4386 or [EMAIL PROTECTED] /Ryan Mike Fedyk wrote: Hi, Some of our VoIP customers are experiencing issues using our service and it only happens when routing through Cogent. Does anyone have a contact for them? Thanks Host Loss% Snt Last Avg Best Wrst StDev 1. adsl-63-194-xxx-xxx.dsl.lsan03.pacbell.net 0.0% 6049 13.7 24.2 8.4 72.2 11.1 2. dist3-vlan60.irvnca.sbcglobal.net 2.0% 6049 19.0 23.5 8.6 217.4 13.5 3. bb1-p6-7.emhril.ameritech.net 0.0% 6049 31.7 43.0 8.6 317.3 46.4 4. ex2-p14-0.eqlaca.sbcglobal.net 0.0% 6049 19.8 44.3 9.4 487.8 49.5 5. te8-1.mpd01.lax05.atlas.cogentco.com0.0% 6049 15.0 41.1 9.5 675.9 53.4 6. vl3491.ccr02.lax01.atlas.cogentco.com 3.3% 6049 34.3 29.4 9.9 337.5 25.4 7. te3-4.ccr01.lax04.atlas.cogentco.com5.2% 6049 19.3 30.1 10.4 275.1 23.6 8. vl3805.na21.b002695-2.lax04.atlas.cogentco.com 5.1% 6049 35.0 27.7 10.2 227.3 12.2 9. PAETEC_Communications_Inc.demarc.cogentco.com 5.3% 6049 18.3 35.8 9.8 252.4 33.6 10. gi-4-0-1-3.core01.lsajca01.paetec.net 5.5% 6049 17.3 37.9 13.3 1054. 43.5 11. po-5-0-0.core01.anhmca01.paetec.net 5.5% 6049 30.7 37.5 13.7 1042. 37.9 12. gi-3-0-0.edge03.anhmca01.paetec.net 5.3% 6049 19.7 33.3 12.9 385.1 20.7 13. 74.10.xxx.xxx5.9% 6049 23.8 35.8 18.1 86.5 11.8 14. 74.10.xxx.xxx5.2% 6049 40.4 36.4 18.0 91.1 11.8 - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax:217-244-7089 1304 W. Springfield email: [EMAIL PROTECTED] Urbana, IL 61801 University of Illinois at Urbana/Champaign University of Illinois - ICCN -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFIB7SKtuPckBBbXboRApkwAJ90YSs6Fdy0JmaLXvNGT3U0xJ3hyQCeP+Hh GiwjrfIDwWUtC52aS2h+kDc= =Vxm1 -END PGP SIGNATURE-
Re: Google contact?
On Thu, Apr 17, 2008 at 11:40 AM, Darden, Patrick S. [EMAIL PROTECTED] wrote: Thanks everyone! Several people from Google responded very quickly, and the issue was resolved faster than I can believe. --Patrick Darden --ARMC Proof that free gourmet lunch and dinner, plus snacks == Great customer service http://www.google.com/support/jobs/bin/static.py?page=benefits.html Now we just need the rest of our employers to catch on... ;) ~Chris -- Those who do not create the future they want must endure the future they get. ~Draper L. Kaufman, Jr. --
Re: Google contact?
Although their growth rates are starting to match each other. ;) Joel Jaeggli wrote: Raymond L. Corbin wrote: It'd be nice if more companies of their size responded that way. :) they have ~6% of the employees of the employees of say verizon and slightly less than the 123 years of cruft that the later has. -Ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darden, Patrick S. Sent: Thursday, April 17, 2008 1:40 PM To: nanog@merit.edu Subject: RE: Google contact? Thanks everyone! Several people from Google responded very quickly, and the issue was resolved faster than I can believe. --Patrick Darden --ARMC
Re: Bandwidth issues in the Sprint network
Some people wanted to know what I found the problem to be. I have discovered. the problem for a fact is the TCP window size on uploads. I have a Linux box that I changed the Window sizes to match and I still get 32k on a upload window and 64k on a download window. With a ping time of 50ms I have a max theoretical throughput of 5.2Mbps Which is about what I was getting. The formula to calculate this is the following. (((Ts/Tw)*Rtd)/1000)+((Ts*8)/(Lr*1000))) Where the following are Ts = Transfer size in Bytes Tw = Tcp Window size in Bytes Rtd = Round trip Delay in milliseconds Lr = Line rate in bps At this point I am still trying to locate the offending device that is changing the window size. After I determine for sure whether the problem is with my router, the sprint network, or another upstream system I will let everybody know what I find. -- Brian Raaen Network Engineer [EMAIL PROTECTED] On Monday 07 April 2008, Brian Raaen wrote: I am currently having problems get upload bandwidth on a Sprint circuit. I am using a full OC3 circuit. I am doing fine on downloading data, but uploading data I can only get about 5Mbps with ftp or a speedtest. I have tested against multiple networks and this has stayed the same. Monitoring Cacti graphs and the router I do get about 30Mbps total traffic outbound, but individual (flows/ip?) test always seem limited. I would like to know if anyone else sees anything similar, or where I can get help. The assistance I have gotten from Sprint up to this point is that they find no problems. Due to the consistency of 5Mbps I am suspecting rate limiting, but wanted to know if I was overlooking something else. -- Brian Raaen Network Engineer [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
RE: Cogent Router dropping packets
Thank you, the issue seems to be fixed now at Cogent. Does anyone know how often issues like this seem to crop up? I'm wondering to see how hard I should push here for routing around cogent for networks our customers connect from. Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Harden Sent: Thursday, April 17, 2008 1:35 PM To: Mike Fedyk Cc: nanog@merit.edu Subject: Re: Cogent Router dropping packets -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just spoke to cogent about another issue, said they only know about issues in Los Angeles. Nevertheless, 877.726.4386 or [EMAIL PROTECTED] /Ryan Mike Fedyk wrote: Hi, Some of our VoIP customers are experiencing issues using our service and it only happens when routing through Cogent. Does anyone have a contact for them? Thanks Host Loss% Snt Last Avg Best Wrst StDev 1. adsl-63-194-xxx-xxx.dsl.lsan03.pacbell.net 0.0% 6049 13.7 24.2 8.4 72.2 11.1 2. dist3-vlan60.irvnca.sbcglobal.net 2.0% 6049 19.0 23.5 8.6 217.4 13.5 3. bb1-p6-7.emhril.ameritech.net 0.0% 6049 31.7 43.0 8.6 317.3 46.4 4. ex2-p14-0.eqlaca.sbcglobal.net 0.0% 6049 19.8 44.3 9.4 487.8 49.5 5. te8-1.mpd01.lax05.atlas.cogentco.com0.0% 6049 15.0 41.1 9.5 675.9 53.4 6. vl3491.ccr02.lax01.atlas.cogentco.com 3.3% 6049 34.3 29.4 9.9 337.5 25.4 7. te3-4.ccr01.lax04.atlas.cogentco.com5.2% 6049 19.3 30.1 10.4 275.1 23.6 8. vl3805.na21.b002695-2.lax04.atlas.cogentco.com 5.1% 6049 35.0 27.7 10.2 227.3 12.2 9. PAETEC_Communications_Inc.demarc.cogentco.com 5.3% 6049 18.3 35.8 9.8 252.4 33.6 10. gi-4-0-1-3.core01.lsajca01.paetec.net 5.5% 6049 17.3 37.9 13.3 1054. 43.5 11. po-5-0-0.core01.anhmca01.paetec.net 5.5% 6049 30.7 37.5 13.7 1042. 37.9 12. gi-3-0-0.edge03.anhmca01.paetec.net 5.3% 6049 19.7 33.3 12.9 385.1 20.7 13. 74.10.xxx.xxx5.9% 6049 23.8 35.8 18.1 86.5 11.8 14. 74.10.xxx.xxx5.2% 6049 40.4 36.4 18.0 91.1 11.8 - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax:217-244-7089 1304 W. Springfield email: [EMAIL PROTECTED] Urbana, IL 61801 University of Illinois at Urbana/Champaign University of Illinois - ICCN -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFIB7SKtuPckBBbXboRApkwAJ90YSs6Fdy0JmaLXvNGT3U0xJ3hyQCeP+Hh GiwjrfIDwWUtC52aS2h+kDc= =Vxm1 -END PGP SIGNATURE-
RE: Cogent Router dropping packets
I spoke too soon: Host Loss% Snt Last Avg Best Wrst StDev 1. adsl-63-194-XXX-XXX.dsl.lsan03.pacbell.net 0.0% 1099.2 19.2 8.4 57.9 11.0 2. dist3-vlan60.irvnca.sbcglobal.net 0.9% 1098.4 16.7 8.3 45.6 9.6 3. bb1-p6-7.emhril.ameritech.net 0.0% 1098.6 36.3 8.5 256.6 44.2 4. ex2-p14-0.eqlaca.sbcglobal.net 0.0% 109 10.3 39.4 9.3 209.3 46.2 5. te8-1.mpd01.lax05.atlas.cogentco.com0.0% 108 32.4 34.3 9.3 238.6 45.1 6. vl3491.ccr02.lax01.atlas.cogentco.com 3.7% 108 17.0 23.4 12.9 98.9 13.4 7. te3-4.ccr01.lax04.atlas.cogentco.com 17.6% 108 39.1 28.8 16.4 198.9 22.1 8. vl3805.na21.b002695-2.lax04.atlas.cogentco.com 12.0% 108 34.1 27.6 17.0 68.7 11.2 9. PAETEC_Communications_Inc.demarc.cogentco.com 10.2% 108 22.4 35.3 17.0 168.7 27.8 10. gi-4-0-1-3.core01.lsajca01.paetec.net 18.5% 108 21.2 34.2 21.0 188.6 20.6 11. po-5-0-0.core01.anhmca01.paetec.net10.3% 108 35.7 33.9 20.5 232.7 23.9 12. gi-3-0-0.edge03.anhmca01.paetec.net13.0% 108 21.0 31.6 20.2 157.9 16.6 13. 74.10.xxx.xxx 11.1% 108 25.7 33.9 25.2 55.2 8.9 14. 74.10.xxx.xxx 15.7% 108 26.7 35.7 25.0 70.8 11.7 -Original Message- From: Mike Fedyk Sent: Thursday, April 17, 2008 2:15 PM To: Ryan Harden Cc: nanog@merit.edu Subject: RE: Cogent Router dropping packets Thank you, the issue seems to be fixed now at Cogent.
Re: Bandwidth issues in the Sprint network
On Thu, Apr 17, 2008 at 1:00 PM, Brian Raaen [EMAIL PROTECTED] wrote: Some people wanted to know what I found the problem to be. I have discovered. the problem for a fact is the TCP window size on uploads. I have a Linux box that I changed the Window sizes to match and I still get 32k on a upload window and 64k on a download window. With a ping time of 50ms I have a max theoretical throughput of 5.2Mbps Which is about what I was getting. The formula to calculate this is the following. (((Ts/Tw)*Rtd)/1000)+((Ts*8)/(Lr*1000))) Where the following are Ts = Transfer size in Bytes Tw = Tcp Window size in Bytes Rtd = Round trip Delay in milliseconds Lr = Line rate in bps At this point I am still trying to locate the offending device that is changing the window size. After I determine for sure whether the problem is with my router, the sprint network, or another upstream system I will let everybody know what I find. -- Brian Raaen Network Engineer [EMAIL PROTECTED] On Monday 07 April 2008, Brian Raaen wrote: I am currently having problems get upload bandwidth on a Sprint circuit. I am using a full OC3 circuit. I am doing fine on downloading data, but uploading data I can only get about 5Mbps with ftp or a speedtest. I have tested against multiple networks and this has stayed the same. Monitoring Cacti graphs and the router I do get about 30Mbps total traffic outbound, but individual (flows/ip?) test always seem limited. I would like to know if anyone else sees anything similar, or where I can get help. The assistance I have gotten from Sprint up to this point is that they find no problems. Due to the consistency of 5Mbps I am suspecting rate limiting, but wanted to know if I was overlooking something else. -- Brian Raaen Network Engineer [EMAIL PROTECTED] Thanks for reporting back to curious minds. Mike Gonnason
Re: Postmaster @ vtext.com (or what are best practice to send SMS these days)
On Wed, 16 Apr 2008, David Ulevitch said: What else are operators doing to get the pages out when things go wonky? I added asterisk and a cheap X100P card to my Nagios setup. Now I can get a voice call if things are really bad. I started to install some text-to-speech tools also, but got depressed by all the additional ports that were coming along for the ride. So for now it just plays a prerecorded message: go check nagios! DW
Re: Cogent Router dropping packets
Cogent frequently have routing and packet loss issues. I can't imagine VoIP over their network is all that appealing to most people. Last time I used Cogent I had a problem approx. every month, and I purchased transit from them. Good luck :-) Mike Fedyk wrote: Thank you, the issue seems to be fixed now at Cogent. Does anyone know how often issues like this seem to crop up? I'm wondering to see how hard I should push here for routing around cogent for networks our customers connect from.
RE: Cogent Router dropping packets
Same here... frequent packet loss. We had Cogent GigE service for about 9 months if I recall - more than one major outage per month and packet loss issues at least once a week. You get what you pay for (within reason) --- Paul Stewart Senior Network Administrator Nexicom 5 King St. E., Millbrook, ON, LOA 1GO Phone: 705-932-4127 Web: http://www.nexicom.net Nexicom. Connected. Naturally. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Coulson Sent: Thursday, April 17, 2008 8:00 PM To: Mike Fedyk Cc: 'Ryan Harden'; nanog@merit.edu Subject: Re: Cogent Router dropping packets Cogent frequently have routing and packet loss issues. I can't imagine VoIP over their network is all that appealing to most people. Last time I used Cogent I had a problem approx. every month, and I purchased transit from them. Good luck :-) Mike Fedyk wrote: Thank you, the issue seems to be fixed now at Cogent. Does anyone know how often issues like this seem to crop up? I'm wondering to see how hard I should push here for routing around cogent for networks our customers connect from. The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
RE: Bandwidth issues in the Sprint network
even with tuned TCP window sizes, make sure you don't have TCP syncookies enabled on either endpoint. many syncookie implementations have implications on supporting RFC1323 options. cheers, lincoln. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Raaen Sent: Friday, 18 April 2008 7:00 AM To: nanog@merit.edu Subject: Re: Bandwidth issues in the Sprint network Some people wanted to know what I found the problem to be. I have discovered. the problem for a fact is the TCP window size on uploads. I have a Linux box that I changed the Window sizes to match and I still get 32k on a upload window and 64k on a download window. With a ping time of 50ms I have a max theoretical throughput of 5.2Mbps Which is about what I was getting. The formula to calculate this is the following. (((Ts/Tw)*Rtd)/1000)+((Ts*8)/(Lr*1000))) Where the following are Ts = Transfer size in Bytes Tw = Tcp Window size in Bytes Rtd = Round trip Delay in milliseconds Lr = Line rate in bps At this point I am still trying to locate the offending device that is changing the window size. After I determine for sure whether the problem is with my router, the sprint network, or another upstream system I will let everybody know what I find. -- Brian Raaen Network Engineer [EMAIL PROTECTED] On Monday 07 April 2008, Brian Raaen wrote: I am currently having problems get upload bandwidth on a Sprint circuit. I am using a full OC3 circuit. I am doing fine on downloading data, but uploading data I can only get about 5Mbps with ftp or a speedtest. I have tested against multiple networks and this has stayed the same. Monitoring Cacti graphs and the router I do get about 30Mbps total traffic outbound, but individual (flows/ip?) test always seem limited. I would like to know if anyone else sees anything similar, or where I can get help. The assistance I have gotten from Sprint up to this point is that they find no problems. Due to the consistency of 5Mbps I am suspecting rate limiting, but wanted to know if I was overlooking something else.
Re: Bandwidth issues in the Sprint network
Once upon a time, Lincoln Dale [EMAIL PROTECTED] said: even with tuned TCP window sizes, make sure you don't have TCP syncookies enabled on either endpoint. IIRC Linux (at least) syncookies only come into play when you are being syn-flooded (i.e. when the kernel has to start dropping syns). Having them enabled at other times has no impact, so there's rarely (if ever) a reason to disable them. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
