Re: Act Surprised.....
On 06:23 PM 7/21/02, Jeff Workman wrote: http://biz.yahoo.com/rb/020721/worldcom_bankruptcy_16.html I *am* surprised. How does a company file BK on a Sunday? jc
Re: Act Surprised.....
On Mon, 22 Jul 2002, JC Dill wrote: On 06:23 PM 7/21/02, Jeff Workman wrote: http://biz.yahoo.com/rb/020721/worldcom_bankruptcy_16.html I *am* surprised. How does a company file BK on a Sunday? jc Although most people aren't aware of it, *technically*, the Courts are a 24x7 operation. Of course, if you are just another Joe, I wouldn't count on getting that level of service (just because YOU paid for it!)... -- Yours, J.A. Terranson [EMAIL PROTECTED] If Governments really want us to behave like civilized human beings, they should give serious consideration towards setting a better example: Ruling by force, rather than consensus; the unrestrained application of unjust laws (which the victim-populations were never allowed input on in the first place); the State policy of justice only for the rich and elected; the intentional abuse and occassionally destruction of entire populations merely to distract an already apathetic and numb electorate... This type of demogoguery must surely wipe out the fascist United States as surely as it wiped out the fascist Union of Soviet Socialist Republics. The views expressed here are mine, and NOT those of my employers, associates, or others. Besides, if it *were* the opinion of all of those people, I doubt there would be a problem to bitch about in the first place...
Re: effects of NYC power outage
On Mon, 22 Jul 2002 08:05:21 -0400 Craig Partridge [EMAIL PROTECTED] wrote: Anyone got good data comparing the effects on the Net (BGP reachability, etc) of this weekend's NYC power outage with the effects power outage late on September 11th. Hello; To be honest, I did not see any BGP or other routing effects from the NYC fire (there were problems on Abilene this weekend, but they were due to a bad router update). My data are presented on http://www.multicasttech.com/status and are fairly coarse-grained, having a 6 hour update cycle. The 9/11 problems actually came starting on 9/13 and 14 when the battery / generator power started running out at 25 Broadway. My understanding is that the biggest problem was the inability to access the facility to refuel. My (multicast-centric) analysis of the 9/11 response was presented at Nanog 23 : http://www.nanog.org/mtg-0110/eubanks.html You should also look at the other two presentations on 9/11 and the Internet at that meeting : http://www.nanog.org/mtg-0110/agenda.html Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ I'm on a National Academy of Sciences committee looking at how the Internet fared on 9/11 and we're always in search of good comparative data. Thanks! Craig Partridge Chief Scientist, BBN Technologies
Re: effects of NYC power outage
You should also look at the other two presentations on 9/11 and the Internet at that meeting : http://www.nanog.org/mtg-0110/agenda.html BGP stability was normal on 9/11. As we know only the telephone network suffered more whereas internet remained stable. Their might have been some problems in the access because of the flash crowd problem. A particular slide from the nanog 23 presentation http://www.nanog.org/mtg-0110/ppt/misconfig/sld010.htm shows the behaviour on 9/11. Just observe closely the slide in the above link. It covers a period from a period from 8/1 to 9/26 and there was variation of 40-60 prefixes (between aug and september), except on 9/11 (there was 100 changes.) Only 0.1% of the route table was lost. BGP was more unstable during code red propagation(http://www.renesys.com/projects/bgp_instability/.) A quick peek into both the graphs will make one thing clear: *BGP is robust enough to withstand any extreme congestion.* But the question is: what can be an effective solution for access congestion on days like 9/11? __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: effects of NYC power outage
In message [EMAIL PROTECTED], senthil ayyasa my writes: BGP stability was normal on 9/11. As we know only the telephone network suffered more whereas internet remained stable. Their might have been some problems in the access because of the flash crowd problem. I've now seen a lot of data on 9/11 and BGP (and other metrics) and, while final results and interpretation will wait for the NRC report, I will say that the data on reachability and such like varies dramatically, depending on where measured, granularity of measurements and other issues. Thanks! Craig
Re: effects of NYC power outage
Craig, We saw real hits on both Genuity and on NYC Teleglobe on Saturday. Both in latency and in packet loss. Our 9/11 graphs are visible at //order.mids.org/~peter/index.html where I put them following the event and on the NANOG 23 (Oct. 2001) site. Peter --- Peter H. Salus Chief Knowledge Officer, Matrix NetSystems Ste. 501W 1106 Clayton Lane Austin, TX 78723 +1 512 451-7602 ---
Re: Act Surprised.....
On Mon, Jul 22, 2002 at 02:40:49AM -0700, JC Dill wrote: On 06:23 PM 7/21/02, Jeff Workman wrote: http://biz.yahoo.com/rb/020721/worldcom_bankruptcy_16.html I *am* surprised. How does a company file BK on a Sunday? The better to not have to pay the bills on monday... An easy way to spot a chpt11 filing-to-be is to watch for mysterious changes in payroll which result in regular employees being paid a day or more in advance of normal. WCOM(soon to be Q.OB)'s prepay made it to f* company, I called sunday when that happened and I was right. :) When GBLX filed they paid regular employees early and claimed it was a bank change, but what they actually did was file a day before severence checks for the month were to be paid to all the people they had already laid off. That money has still not been paid, and probably never will. But now back to something operational... Does a betting pool on chpt11 dates count as operational? :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
RE: effects of NYC power outage
A side-note on why 25 Broadway lost power. I am told they had the fuel, but the Local 3 union worker who was watching the gauges on the generator misread the dials, and a human error caused the generator to run bone dry. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Marshall Eubanks Sent: Monday, July 22, 2002 8:27 AM To: Craig Partridge; [EMAIL PROTECTED] Subject: Re: effects of NYC power outage On Mon, 22 Jul 2002 08:05:21 -0400 Craig Partridge [EMAIL PROTECTED] wrote: Anyone got good data comparing the effects on the Net (BGP reachability, etc) of this weekend's NYC power outage with the effects power outage late on September 11th. Hello; To be honest, I did not see any BGP or other routing effects from the NYC fire (there were problems on Abilene this weekend, but they were due to a bad router update). My data are presented on http://www.multicasttech.com/status and are fairly coarse-grained, having a 6 hour update cycle. The 9/11 problems actually came starting on 9/13 and 14 when the battery / generator power started running out at 25 Broadway. My understanding is that the biggest problem was the inability to access the facility to refuel. My (multicast-centric) analysis of the 9/11 response was presented at Nanog 23 : http://www.nanog.org/mtg-0110/eubanks.html You should also look at the other two presentations on 9/11 and the Internet at that meeting : http://www.nanog.org/mtg-0110/agenda.html Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ I'm on a National Academy of Sciences committee looking at how the Internet fared on 9/11 and we're always in search of good comparative data. Thanks! Craig Partridge Chief Scientist, BBN Technologies
RE: effects of NYC power outage
Nope. The main generator for the 5th floor apparently ran for a while, but the radiator became clogged with garbage floating aroung in the air, and therefore couldn't cool itself, and overheated. They shut it down to prevent it from hurting itself. Fuel was another issue. On Mon, 22 Jul 2002, Phil Rosenthal wrote: A side-note on why 25 Broadway lost power. I am told they had the fuel, but the Local 3 union worker who was watching the gauges on the generator misread the dials, and a human error caused the generator to run bone dry. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Marshall Eubanks Sent: Monday, July 22, 2002 8:27 AM To: Craig Partridge; [EMAIL PROTECTED] Subject: Re: effects of NYC power outage On Mon, 22 Jul 2002 08:05:21 -0400 Craig Partridge [EMAIL PROTECTED] wrote: Anyone got good data comparing the effects on the Net (BGP reachability, etc) of this weekend's NYC power outage with the effects power outage late on September 11th. Hello; To be honest, I did not see any BGP or other routing effects from the NYC fire (there were problems on Abilene this weekend, but they were due to a bad router update). My data are presented on http://www.multicasttech.com/status and are fairly coarse-grained, having a 6 hour update cycle. The 9/11 problems actually came starting on 9/13 and 14 when the battery / generator power started running out at 25 Broadway. My understanding is that the biggest problem was the inability to access the facility to refuel. My (multicast-centric) analysis of the 9/11 response was presented at Nanog 23 : http://www.nanog.org/mtg-0110/eubanks.html You should also look at the other two presentations on 9/11 and the Internet at that meeting : http://www.nanog.org/mtg-0110/agenda.html Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ I'm on a National Academy of Sciences committee looking at how the Internet fared on 9/11 and we're always in search of good comparative data. Thanks! Craig Partridge Chief Scientist, BBN Technologies -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
IP Options Needed?
-BEGIN PGP SIGNED MESSAGE- I am passing this question along from a friend who is in the process of designing some new network equipment. Any comments will be helpful. I will gather all the responses and send them to my friend. Thanks Matt Also, IP operations question; You are evaluating a router for purchase and initially it doesn't support IP options (Unrecognized, stream ID, source route, record route, time stamp , security). But it supports trace route and Ping. What is the impact for you during the evaluation? And do you currently disable IP options for security reasons on your routers that are in the network. Any info on the subject is greatly appreciated. __ http://www.invision.net/ ___ Matthew E. Martini, PEInVision.com, Inc. (631) 543-1000 x104 Chief Technology Officer [EMAIL PROTECTED](631) 864-8896 Fax ___pgp_ -BEGIN PGP SIGNATURE- Version: PGP 6.5.1i iQEVAwUBPTwv5GtXn16/JS7ZAQFrQAf+LiMIPIErEPAnyD2NoT6F/FJeEFMTemiX 2JN/F/Mmnw3eYo7i65NBDFWwAsJC0CXpcm/4vjmYQsGCl7HPp99qqWaY/iY26nOd +O2pFdKu0vaT/ElmLqatExDuMqnAgcPlnH1mVhd0jC4Woe+WTC0u+Zvpo5UvumPt rIssUy33qOGiE+9TYHPZmsYqhaLOQP6N3Iu6bm0rXIf/C4oslHtllJkbGzsUWnSE obRNBcDITrfe16+nowot77++CaNjI6DoFb/wGQb4SHDmsYvoVkMBL7ehIRDazOLj wk7R7GFL+e6KqA9rX4adWKTvsJDpYIuzZwX0LVAs77xUVxd1yazykQ== =sgON -END PGP SIGNATURE-
Requirement to store email for 90 days.
http://www.theregister.co.uk/content/55/26217.html Service providers are also required to keep customer records, including emails, for 90 days, under the bill. The bill has to go to Senate, where it is expected to receive little opposition, before becoming law. Talk to your senators folks. See if they're going to pay for the disk arrays required to store 90 days worth of SPAM for each and every one of your customers. I suggest that congress get the spammers under control prior to enacting legislation that requires us to archive all email for 90 days. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc| Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation|
Re: Requirement to store email for 90 days.
From the same URL: The bill encourages ISPs to report suspicious activity on their networks (whatever that might be), even if it poses no immediate threat, and shield them from lawsuits from anyone so just forward the spam to the authorities... after all, it is suspicous. Maybe some Al Quaida steggo hiding in it? On Mon, 22 Jul 2002 12:17:27 -0400 (EDT) John Fraizer [EMAIL PROTECTED] wrote: http://www.theregister.co.uk/content/55/26217.html Service providers are also required to keep customer records, including emails, for 90 days, under the bill. The bill has to go to Senate, where it is expected to receive little opposition, before becoming law. Talk to your senators folks. See if they're going to pay for the disk arrays required to store 90 days worth of SPAM for each and every one of your customers. I suggest that congress get the spammers under control prior to enacting legislation that requires us to archive all email for 90 days. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc| Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation| -- --- [EMAIL PROTECTED] Collaborative Intrusion Detection join http://www.dshield.org msg03896/pgp0.pgp Description: PGP signature
Re: Act Surprised.....
At 2:40 am -0700 22/7/02, JC Dill wrote: On 06:23 PM 7/21/02, Jeff Workman wrote: http://biz.yahoo.com/rb/020721/worldcom_bankruptcy_16.html I *am* surprised. How does a company file BK on a Sunday? They go to the Judge in Chambers and avoid upsetting the market in the middle of the day. Easy and quite common. How else do you get a search warrant in the middle of the night, you just page the on-call Judge. So to go on topic which bits of the non-US network are owned by the US corporation and subject to disruption? f
Re: Requirement to store email for 90 days.
On Mon, 22 Jul 2002, John Fraizer wrote: http://www.theregister.co.uk/content/55/26217.html Service providers are also required to keep customer records, including emails, for 90 days, under the bill. The bill has to go to Senate, where it is expected to receive little opposition, before becoming law. Talk to your senators folks. See if they're going to pay for the disk arrays required to store 90 days worth of SPAM for each and every one of your customers. I suggest that congress get the spammers under control prior to enacting legislation that requires us to archive all email for 90 days. Well...it's not quite like that. Here's the text: (URL posting doesn't work with their cgi. Go to http://thomas.loc.gov/ and search for bill number H.R. 3482, and pull up section 102 (b)) --- REPORTING OF DISCLOSURES A government entity that receives a disclosure under this section shall file, no later than 90 days after such disclosure, a report to the Attorney General stating the subparagraph under which the disclosure was made, the date of the disclosure, the entity to which the disclosure was made, the number of customers or subscribers to whom the information disclosed pertained, and the number of communications, if any, that were disclosed. The Attorney General shall publish all such reports into a single report to be submitted to Congress one year after enactment of the bill. --- That's the only place in the bill that mentions 90 days. However, it appears to me that they are referring to the period of time a government agency has to report to the Attorney General regarding the information that was disclosed. I'd love for somebody to point out the text indicating anybody is forced to archive anything. As best I can tell, and I'm the farthest thing from a lawyer, is that this bill doesn't mention anything about forcing anybody to archive anything. This has been debated for a couple of months now, and I'm not entirely convinced anybody knows the truth. As far as I can tell, the situations in which they can ask for your records is broadened, but that doesn't require you to keep records... I'd love for somebody to point out what I'm missing... Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
OT: If you thought Y2K was bad, wait until cyber-security hits
(shooting self in foot...) Just eliminate tech support and proprietary software! A list of our settings is available at www.domain.com/settings. And don't call us with tech problems. We don't do tech support. I know of at least one ISP out there already doing this. Not that they're highly successful, but imagine not having to tell someone, Yes, your username and password are case sensitive and must be spelled exactly as supplied. And it's .net, not .com ever again. Or alternately just require registration through a BBS system as a clue test. :) (Waiting for visit from the sales/marketing/shareholder folk...) Best regards, _ Alan Rowland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 20, 2002 10:03 PM To: Scott Francis Cc: [EMAIL PROTECTED] Subject: Re: If you thought Y2K was bad, wait until cyber-security hits Snip... I'll personally nominate for sainthood anybody who figures out how to make it work for an ISP's terms of service. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Re: Requirement to store email for 90 days.
At 12:17 PM 7/22/2002, John Fraizer wrote: http://www.theregister.co.uk/content/55/26217.html Service providers are also required to keep customer records, including emails, for 90 days, under the bill. The bill has to go to Senate, where it is expected to receive little opposition, before becoming law. Are you reacting to the contents of the bill (bill number?) or to the interpretations of a reporter? Could someone please cite the 90 days requirement in an actual bill? Not saying it's not there, but the bills I could find through Thomas don't seem to have any mention of this. I'm not calling my senators until I have precise citations. Talk to your senators folks. See if they're going to pay for the disk arrays required to store 90 days worth of SPAM for each and every one of your customers. I suggest that congress get the spammers under control prior to enacting legislation that requires us to archive all email for 90 days. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc| Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation| - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com
Re: Requirement to store email for 90 days.
The bill appears to be hr3482, looking at thomas.loc.gov's full text links, the only mention of 90 in there appears to be here, in section 102b. Nice Dragnet approach Dan. (b) REPORTING OF DISCLOSURES- A government entity that receives a disclosure under this section shall file, no later than 90 days after such disclosure, a report to the Attorney General stating the subparagraph under which the disclosure was made, the date of the disclosure, the entity to which the disclosure was made, the number of customers or subscribers to whom the information disclosed pertained, and the number of communications, if any, that were disclosed. The Attorney General shall publish all such reports into a single report to be submitted to Congress one year after enactment of the bill. Brian - Original Message - From: Daniel Senie [EMAIL PROTECTED] To: John Fraizer [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 22, 2002 10:02 AM Subject: Re: Requirement to store email for 90 days. At 12:17 PM 7/22/2002, John Fraizer wrote: http://www.theregister.co.uk/content/55/26217.html Service providers are also required to keep customer records, including emails, for 90 days, under the bill. The bill has to go to Senate, where it is expected to receive little opposition, before becoming law. Are you reacting to the contents of the bill (bill number?) or to the interpretations of a reporter? Could someone please cite the 90 days requirement in an actual bill? Not saying it's not there, but the bills I could find through Thomas don't seem to have any mention of this. I'm not calling my senators until I have precise citations. Talk to your senators folks. See if they're going to pay for the disk arrays required to store 90 days worth of SPAM for each and every one of your customers. I suggest that congress get the spammers under control prior to enacting legislation that requires us to archive all email for 90 days. --- John Fraizer | High-Security Datacenter Services | EnterZone, Inc| Dedicated circuits 64k - 155M OC3 | http://www.enterzone.net/ | Virtual, Dedicated, Colocation| - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com
RE: effects of NYC power outage
I have never seen the final root cause (actually direct cause, we know what the root cause was) report from Telehouse. Although I can understand why Telehouse wouldn't want to say what happened. Between replacing water pumps, reports of contanimation inside and outside the cooling system, fuel delivery delays, etc I'm not certain there was a single cause. From the outside there seemed to be multiple events, each with different direct causes. On Mon, 22 Jul 2002, Alex Rubenstein wrote: Nope. The main generator for the 5th floor apparently ran for a while, but the radiator became clogged with garbage floating aroung in the air, and therefore couldn't cool itself, and overheated. They shut it down to prevent it from hurting itself. Fuel was another issue.
RE: effects of NYC power outage
From what I recall, it failed due to a mechanical problem first... then after they fixed it and had it running for sometime, it ran out of fuel. -Simon On Mon, 22 Jul 2002 11:50:29 -0400, Phil Rosenthal wrote: A side-note on why 25 Broadway lost power. I am told they had the fuel, but the Local 3 union worker who was watching the gauges on the generator misread the dials, and a human error caused the generator to run bone dry. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Marshall Eubanks Sent: Monday, July 22, 2002 8:27 AM To: Craig Partridge; [EMAIL PROTECTED] Subject: Re: effects of NYC power outage On Mon, 22 Jul 2002 08:05:21 -0400 Craig Partridge [EMAIL PROTECTED] wrote: Anyone got good data comparing the effects on the Net (BGP reachability, etc) of this weekend's NYC power outage with the effects power outage late on September 11th. Hello; To be honest, I did not see any BGP or other routing effects from the NYC fire (there were problems on Abilene this weekend, but they were due to a bad router update). My data are presented on http://www.multicasttech.com/status and are fairly coarse-grained, having a 6 hour update cycle. The 9/11 problems actually came starting on 9/13 and 14 when the battery / generator power started running out at 25 Broadway. My understanding is that the biggest problem was the inability to access the facility to refuel. My (multicast-centric) analysis of the 9/11 response was presented at Nanog 23 : http://www.nanog.org/mtg-0110/eubanks.html You should also look at the other two presentations on 9/11 and the Internet at that meeting : http://www.nanog.org/mtg-0110/agenda.html Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc. 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ I'm on a National Academy of Sciences committee looking at how the Internet fared on 9/11 and we're always in search of good comparative data. Thanks! Craig Partridge Chief Scientist, BBN Technologies
Cogent issues at AADS PVC 5.34?
We're currently experiencing significant latency through Cogent at AADS. I've heard they have some general latency issues, but nothing concrete yet as to what and where. Does anyone have any details of any problems while we're waiting for a response back from the NOC? Thanks, John
RE: Cogent issues at AADS PVC 5.34?
John, I can't be certain this has anything to do with it, as I haven't called for a report today. But as of Friday I was seeing upwards of 1200 ms due to a fiber outage (Either a cut or turnoff, they wouldn't say.) and them running over capacity due to the outage. If I hear anything else I'll post to the list. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Kristoff Sent: Monday, July 22, 2002 1:49 PM To: [EMAIL PROTECTED] Subject: Cogent issues at AADS PVC 5.34? We're currently experiencing significant latency through Cogent at AADS. I've heard they have some general latency issues, but nothing concrete yet as to what and where. Does anyone have any details of any problems while we're waiting for a response back from the NOC? Thanks, John
Re: Cogent issues at AADS PVC 5.34?
We received notification this morning that there were some problems with at least one of the ATM switch cards @ AADS. If it is getting worse, lets hope they fix it before their scheduled maintenance (this next weekend). k - SBC/Ameritech NAP customers, We have been experiencing problems with the card that your circuit resides on. We are planning to swap it out on Sunday, July 28th at 12:01AM CST. With that you will experience a short outage. Thanks for your patience. Kevin Peterson ASI Technical Support John Kristoff [EMAIL PROTECTED]To: [EMAIL PROTECTED] du cc: Sent by: Subject: Cogent issues at AADS PVC 5.34? owner-nanog@m erit.edu 07/22/2002 01:49 PM Please respond to jtk We're currently experiencing significant latency through Cogent at AADS. I've heard they have some general latency issues, but nothing concrete yet as to what and where. Does anyone have any details of any problems while we're waiting for a response back from the NOC? Thanks, John
RE: Cogent issues at AADS PVC 5.34?
Okay...Just talked to Cogent. The fiber outage was resolved on Saturday. I'm not actually seeing latency on their network (I Just changed my preferences to actually follow some of their routes.) I'm out on AS 1 at 60 ms. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Derek Samford Sent: Monday, July 22, 2002 1:49 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Cogent issues at AADS PVC 5.34? John, I can't be certain this has anything to do with it, as I haven't called for a report today. But as of Friday I was seeing upwards of 1200 ms due to a fiber outage (Either a cut or turnoff, they wouldn't say.) and them running over capacity due to the outage. If I hear anything else I'll post to the list. Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Kristoff Sent: Monday, July 22, 2002 1:49 PM To: [EMAIL PROTECTED] Subject: Cogent issues at AADS PVC 5.34? We're currently experiencing significant latency through Cogent at AADS. I've heard they have some general latency issues, but nothing concrete yet as to what and where. Does anyone have any details of any problems while we're waiting for a response back from the NOC? Thanks, John
Re: OT: If you thought Y2K was bad, wait until cyber-security hits
On Mon, Jul 22, 2002 at 10:00:44AM -0700, [EMAIL PROTECTED] said: (shooting self in foot...) Just eliminate tech support and proprietary software! A list of our settings is available at www.domain.com/settings. And don't call us with tech problems. We don't do tech support. I know of at least one ISP out there already doing this. Not that they're highly successful, but imagine not having to tell someone, Yes, your username and password are case sensitive and must be spelled exactly as supplied. And it's .net, not .com ever again. http://www.flex.com/ Unfortunately, it looks like they took down the hate mail page, which was hysterical. *sigh* They target clueful users only, and seem to be getting by just fine. http://www.flex.com/adsl/ has a bit more of the intelligent users only pitch. -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui msg03908/pgp0.pgp Description: PGP signature
Re: effects of NYC power outage
I agree... I don't know why this is being discussed. I just thank -whoever- for 25bway still standing. -Simon On Mon, 22 Jul 2002 13:51:11 -0400 (EDT), Tuc wrote: From what I recall, it failed due to a mechanical problem first... then after they fixed it and had it running for sometime, it ran out of fuel. Hi, Ok, come on... That was 310 or so days ago. Exactly what happened shouldn't be a huge concern anymore. They addressed it, fixed it, and are making sure it doesn't happen again, thats the part we need to concentrate on. Phil, you weren't even a customer then, were you? And for those that didn't know/forgot I slept in the conference room the first 4 days after it all happened... And I think given the severity and magnitude of the event, they did a hell of a job. Only so much you can expect. Tuc/TTSG Internet Services, Inc.
Re: Cogent issues at AADS PVC 5.34?
Thanks to all those who responded. The problem appears to have mysteriously cleared up at the moment. Mysteriously, because I haven't yet heard official word from Cogent or other 3rd party on a definitive cause of the degradation. John
Anyone using Interspeed DSL gear?
If anyone is using any Interspeed DSL equipment, please email me offline? Thanks, Vin
Learning from the past (was Re: effects of NYC power outage)
Ok, come on... That was 310 or so days ago. Exactly what happened shouldn't be a huge concern anymore. They addressed it, fixed it, and are making sure it doesn't happen again, thats the part we need to concentrate on. The Morris worm happened over a decade ago. Computers are still being attacked using the same vulnerabilities used by the Morris worm, and amazingly some of the attacks are still working. The ATT New York City/FAA power failure happened over a decade ago (http://www.att.com/news/0991/910930.cha.html). Power problems continue to be a significant cause of network disruptions. ATT is a bit unusual. It almost always releases more information about its failures than any other telecommunications company. AS7007 happened over 5 years ago. Some networks still don't practicee safe filtering. Think volunteer fire department. The house you keep from burning down may be your own. If you don't want to participate, don't expect much help from your neighbors. Its amazing how often something happens to one organization, and continues to happen to other organizations. As an industry we want to make sure it not only doesn't happen to the same provider again, but the experience isn't repeated by other providers. That's why the electrical industry shares their experiences through DAWG (Disturbance Analysis Working Group) and the telephone industry shares their experiences through NRIC (Network reliability and interoperability council). I encourage folks to participate in the ISAC, NRIC and NSTAC programs. You may have the same vulnerability as several other providers, and don't know it. The solution you share may save yourself from a future vulnerability. The government cyber-protection groups have realized that they don't have good contacts with carrier hotel landlords, and it is an unknown exposure. Heck, there isn't even a good list of all the important carrier hotels. If you are a carrier hotel landlord, and aren't in contact with the government working groups examining infrastructure vulnerabilities, they want your input.
Re: OT: If you thought Y2K was bad, wait until cyber-security hits
On Mon, 22 Jul 2002, Scott Francis wrote: : On Mon, Jul 22, 2002 at 10:00:44AM -0700, [EMAIL PROTECTED] said: : : (shooting self in foot...) : : Just eliminate tech support and proprietary software! A list of our : settings is available at www.domain.com/settings. And don't call us with : tech problems. We don't do tech support. : : I know of at least one ISP out there already doing this. Not that they're : highly successful, but imagine not having to tell someone, Yes, your : username and password are case sensitive and must be spelled exactly as : supplied. And it's .net, not .com ever again. : : http://www.flex.com/ : : Unfortunately, it looks like they took down the hate mail page, which was : hysterical. *sigh* They target clueful users only, and seem to be getting by : just fine. http://www.flex.com/adsl/ has a bit more of the intelligent users : only pitch. One of Hawaii's fun things... ;-) http://www.flex.com/net_status/fan_con.html scott sorry sir but i find AOL easy to use, i didnt know that since AOL is a helluva lot easier to use than freakin IE im considered computer illteritate, just quit bashing AOL, not all of us are sado-masochists. *heh* no need to comment, but it surely is begging for it... :-)
Re: OT: If you thought Y2K was bad, wait until cyber-security hits
I met del at a mini Computer Expo at Wailea, Maui in '96. He was dealing Blackjack in his booth for prizes (I won an external 14.4 modem) and giving away beta test dialup accounts. I thought that 'shaka.com' was cool, so after 6 months of free beta, I signed up and have been with them since. --Michael - Original Message - From: Scott Weeks [EMAIL PROTECTED] To: Scott Francis [EMAIL PROTECTED] Cc: Rowland, Alan D [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 22, 2002 11:04 AM Subject: Re: OT: If you thought Y2K was bad, wait until cyber-security hits On Mon, 22 Jul 2002, Scott Francis wrote: : On Mon, Jul 22, 2002 at 10:00:44AM -0700, [EMAIL PROTECTED] said: : : (shooting self in foot...) : : Just eliminate tech support and proprietary software! A list of our : settings is available at www.domain.com/settings. And don't call us with : tech problems. We don't do tech support. : : I know of at least one ISP out there already doing this. Not that they're : highly successful, but imagine not having to tell someone, Yes, your : username and password are case sensitive and must be spelled exactly as : supplied. And it's .net, not .com ever again. : : http://www.flex.com/ : : Unfortunately, it looks like they took down the hate mail page, which was : hysterical. *sigh* They target clueful users only, and seem to be getting by : just fine. http://www.flex.com/adsl/ has a bit more of the intelligent users : only pitch. One of Hawaii's fun things... ;-) http://www.flex.com/net_status/fan_con.html scott sorry sir but i find AOL easy to use, i didnt know that since AOL is a helluva lot easier to use than freakin IE im considered computer illteritate, just quit bashing AOL, not all of us are sado-masochists. *heh* no need to comment, but it surely is begging for it... :-)
PSINet/Cogent Latency
There was some mail being tossed around earlier about Cogent having latency. I'm actually seeing this on PSINet (Now owned by Cogent.) Is anyone else still seeing the latency they were experiencing earlier? Derek
Re: PSINet/Cogent Latency
Yes, it's horrid. I've been peering with PSI for going on three years, and it's never been as bad as it is now. oddly enough, we see 30+ msec across a DS3 to them, which isn't that loaded (35 to 40 mb/s). Then, behind whatever we peer with, we see over 400 msec, with 50% loss, during business hours. On Mon, 22 Jul 2002, Derek Samford wrote: There was some mail being tossed around earlier about Cogent having latency. I'm actually seeing this on PSINet (Now owned by Cogent.) Is anyone else still seeing the latency they were experiencing earlier? Derek -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: PSINet/Cogent Latency
40mb/s isn't loaded for a DS3? --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Monday, July 22, 2002 8:27 PM To: Derek Samford Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency Yes, it's horrid. I've been peering with PSI for going on three years, and it's never been as bad as it is now. oddly enough, we see 30+ msec across a DS3 to them, which isn't that loaded (35 to 40 mb/s). Then, behind whatever we peer with, we see over 400 msec, with 50% loss, during business hours. On Mon, 22 Jul 2002, Derek Samford wrote: There was some mail being tossed around earlier about Cogent having latency. I'm actually seeing this on PSINet (Now owned by Cogent.) Is anyone else still seeing the latency they were experiencing earlier? Derek -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: PSINet/Cogent Latency
Nah, that's not loaded. Its not loaded until you make it go in to alarm by passing traffic:):). - Original Message - From: Phil Rosenthal [EMAIL PROTECTED] To: 'Alex Rubenstein' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 6:05 PM Subject: RE: PSINet/Cogent Latency 40mb/s isn't loaded for a DS3? --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Monday, July 22, 2002 8:27 PM To: Derek Samford Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency Yes, it's horrid. I've been peering with PSI for going on three years, and it's never been as bad as it is now. oddly enough, we see 30+ msec across a DS3 to them, which isn't that loaded (35 to 40 mb/s). Then, behind whatever we peer with, we see over 400 msec, with 50% loss, during business hours. On Mon, 22 Jul 2002, Derek Samford wrote: There was some mail being tossed around earlier about Cogent having latency. I'm actually seeing this on PSINet (Now owned by Cogent.) Is anyone else still seeing the latency they were experiencing earlier? Derek -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: PSINet/Cogent Latency
bwahaha, 2 funnee. I gotta think most people would be thinking of adding another ds3 at that point. Bri - Original Message - From: Phil Rosenthal [EMAIL PROTECTED] To: 'Alex Rubenstein' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 6:05 PM Subject: RE: PSINet/Cogent Latency 40mb/s isn't loaded for a DS3? --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Monday, July 22, 2002 8:27 PM To: Derek Samford Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency Yes, it's horrid. I've been peering with PSI for going on three years, and it's never been as bad as it is now. oddly enough, we see 30+ msec across a DS3 to them, which isn't that loaded (35 to 40 mb/s). Then, behind whatever we peer with, we see over 400 msec, with 50% loss, during business hours. On Mon, 22 Jul 2002, Derek Samford wrote: There was some mail being tossed around earlier about Cogent having latency. I'm actually seeing this on PSINet (Now owned by Cogent.) Is anyone else still seeing the latency they were experiencing earlier? Derek -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: PSINet/Cogent Latency
You certainly would, except for the fact that the provider is in bankruptcy and won't/can't answer the phone. We wanted to do an oc3 or oc12 or gig-e, but that was replied to with, wha? On Mon, 22 Jul 2002, Brian wrote: bwahaha, 2 funnee. I gotta think most people would be thinking of adding another ds3 at that point. Bri - Original Message - From: Phil Rosenthal [EMAIL PROTECTED] To: 'Alex Rubenstein' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 6:05 PM Subject: RE: PSINet/Cogent Latency 40mb/s isn't loaded for a DS3? --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Monday, July 22, 2002 8:27 PM To: Derek Samford Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency Yes, it's horrid. I've been peering with PSI for going on three years, and it's never been as bad as it is now. oddly enough, we see 30+ msec across a DS3 to them, which isn't that loaded (35 to 40 mb/s). Then, behind whatever we peer with, we see over 400 msec, with 50% loss, during business hours. On Mon, 22 Jul 2002, Derek Samford wrote: There was some mail being tossed around earlier about Cogent having latency. I'm actually seeing this on PSINet (Now owned by Cogent.) Is anyone else still seeing the latency they were experiencing earlier? Derek -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: PSINet/Cogent Latency
I call any upstream link 'over capacity' if either: 1) There is less than 50mb/s unused 2) The circuit is more than 50% in use I guess by my definition a DS3 is always 'over capacity' --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Brian Sent: Monday, July 22, 2002 9:36 PM To: [EMAIL PROTECTED]; 'Alex Rubenstein' Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency bwahaha, 2 funnee. I gotta think most people would be thinking of adding another ds3 at that point. Bri - Original Message - From: Phil Rosenthal [EMAIL PROTECTED] To: 'Alex Rubenstein' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 6:05 PM Subject: RE: PSINet/Cogent Latency 40mb/s isn't loaded for a DS3? --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Monday, July 22, 2002 8:27 PM To: Derek Samford Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency Yes, it's horrid. I've been peering with PSI for going on three years, and it's never been as bad as it is now. oddly enough, we see 30+ msec across a DS3 to them, which isn't that loaded (35 to 40 mb/s). Then, behind whatever we peer with, we see over 400 msec, with 50% loss, during business hours. On Mon, 22 Jul 2002, Derek Samford wrote: There was some mail being tossed around earlier about Cogent having latency. I'm actually seeing this on PSINet (Now owned by Cogent.) Is anyone else still seeing the latency they were experiencing earlier? Derek -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: PSINet/Cogent Latency
On Mon, 22 Jul 2002, Phil Rosenthal wrote: I call any upstream link 'over capacity' if either: 1) There is less than 50mb/s unused That must work well for T1's and DS3's. 2) The circuit is more than 50% in use I call it 'over capacity' too, but that doesn't mean all the ducks are in a row to get both sides to realise an upgrade is needed, and even if they do realise it, to actually get it done. I am sure 2238092 people on this list can complain of the same problem. So, what do you do? You monitor it's usage, making adjustments to make sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 mbit/sec, with little to none increase in latency from the norm. Many people do this as well, even up to OC12 or higher levels all the time. I guess by my definition a DS3 is always 'over capacity' Which must work very well for those DS3's doing 10 to 20 mb/s. Do you upgrade those to OC3 or beyond? -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: PSINet/Cogent Latency
Actually, I wouldn't think about getting T1, DS3 or OC3 in the first place ;) Oc-12 is the minimum link I would even look at -- and my preference is gig-e... Even if there is only 90 megs on the interface... --Phil -Original Message- From: Alex Rubenstein [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 10:02 PM To: Phil Rosenthal Cc: [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency On Mon, 22 Jul 2002, Phil Rosenthal wrote: I call any upstream link 'over capacity' if either: 1) There is less than 50mb/s unused That must work well for T1's and DS3's. 2) The circuit is more than 50% in use I call it 'over capacity' too, but that doesn't mean all the ducks are in a row to get both sides to realise an upgrade is needed, and even if they do realise it, to actually get it done. I am sure 2238092 people on this list can complain of the same problem. So, what do you do? You monitor it's usage, making adjustments to make sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 mbit/sec, with little to none increase in latency from the norm. Many people do this as well, even up to OC12 or higher levels all the time. I guess by my definition a DS3 is always 'over capacity' Which must work very well for those DS3's doing 10 to 20 mb/s. Do you upgrade those to OC3 or beyond? -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: PSINet/Cogent Latency
On Mon, Jul 22, 2002 at 10:01:36PM -0400, Alex Rubenstein wrote: So, what do you do? You monitor it's usage, making adjustments to make sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 mbit/sec, with little to none increase in latency from the norm. Many people do this as well, even up to OC12 or higher levels all the time. Just remember that while a 5 minute average may not be at 100%, the microbursts are probably quite a bit over that. For an ISP who actually cares about making money it's not *easy* to say I'm terminating my peer to PSI because of their degraded performance and unwillingness to upgrade, but a de-localpref'ing is probably a good idea. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
RE: PSINet/Cogent Latency
Good for you, Phil. Chime in again when you've got something useful to offer. In the meantime, you may want to review Economics 101 along with certain queueing schemes, especially RED (no, I'm not endorsing the idea of oversubscribing to the extreme, but then again, neither was Alex). Also, re-read the previous post. There's a big difference between choice and facility. Did you grow up spending Summers in the Hamptons with no conception of the value of a dollar, or are you simply trolling? -brian On Mon, 22 Jul 2002, Phil Rosenthal wrote: : :Actually, I wouldn't think about getting T1, DS3 or OC3 in the first :place ;) :Oc-12 is the minimum link I would even look at -- and my preference is :gig-e... Even if there is only 90 megs on the interface... : :--Phil : :-Original Message- :From: Alex Rubenstein [mailto:[EMAIL PROTECTED]] :Sent: Monday, July 22, 2002 10:02 PM :To: Phil Rosenthal :Cc: [EMAIL PROTECTED] :Subject: RE: PSINet/Cogent Latency : : : : :On Mon, 22 Jul 2002, Phil Rosenthal wrote: : : : I call any upstream link 'over capacity' if either: : 1) There is less than 50mb/s unused : :That must work well for T1's and DS3's. : : : 2) The circuit is more than 50% in use : :I call it 'over capacity' too, but that doesn't mean all the ducks are :in a row to get both sides to realise an upgrade is needed, and even if :they do realise it, to actually get it done. I am sure 2238092 people on :this list can complain of the same problem. : :So, what do you do? You monitor it's usage, making adjustments to make :sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 :mbit/sec, with little to none increase in latency from the norm. Many :people do this as well, even up to OC12 or higher levels all the time. : : : : : I guess by my definition a DS3 is always 'over capacity' : :Which must work very well for those DS3's doing 10 to 20 mb/s. Do you :upgrade those to OC3 or beyond? : : :-- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- :--Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- : : : :
RE: PSINet/Cogent Latency
With the price of transit where it is today: #1 Transit is often cheaper than peering (if you factor in port costs on public exchanges, or link costs for private exchanges) #2 The difference in price is likely not large enough for me to risk: saturation, latency, etc... My customers pay me to provide them a premium service, and I see value in providing that service. Some people have no problem selling cogent -- what can I say... You get what you pay for... And no, I'm not trolling. Is having a different opinion not allowed now? And 40mbit over a 45mbit circuit, if it is to an uplink/peer -- well, if he has customers who are connected at 100mbit switched uncapped (likely) -- then many customers (possibly even some DSL customers...) can flood off his peer links with only a 5mbit stream. --Phil -Original Message- From: Brian Wallingford [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 11:13 PM To: Phil Rosenthal Cc: 'Alex Rubenstein'; [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency Good for you, Phil. Chime in again when you've got something useful to offer. In the meantime, you may want to review Economics 101 along with certain queueing schemes, especially RED (no, I'm not endorsing the idea of oversubscribing to the extreme, but then again, neither was Alex). Also, re-read the previous post. There's a big difference between choice and facility. Did you grow up spending Summers in the Hamptons with no conception of the value of a dollar, or are you simply trolling? -brian On Mon, 22 Jul 2002, Phil Rosenthal wrote: : :Actually, I wouldn't think about getting T1, DS3 or OC3 in the first :place ;) :Oc-12 is the minimum link I would even look at -- and my preference is :gig-e... Even if there is only 90 megs on the interface... : :--Phil : :-Original Message- :From: Alex Rubenstein [mailto:[EMAIL PROTECTED]] :Sent: Monday, July 22, 2002 10:02 PM :To: Phil Rosenthal :Cc: [EMAIL PROTECTED] :Subject: RE: PSINet/Cogent Latency : : : : :On Mon, 22 Jul 2002, Phil Rosenthal wrote: : : : I call any upstream link 'over capacity' if either: : 1) There is less than 50mb/s unused : :That must work well for T1's and DS3's. : : : 2) The circuit is more than 50% in use : :I call it 'over capacity' too, but that doesn't mean all the ducks are :in a row to get both sides to realise an upgrade is needed, and even if :they do realise it, to actually get it done. I am sure 2238092 people on :this list can complain of the same problem. : :So, what do you do? You monitor it's usage, making adjustments to make :sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 :mbit/sec, with little to none increase in latency from the norm. Many :people do this as well, even up to OC12 or higher levels all the time. : : : : : I guess by my definition a DS3 is always 'over capacity' : :Which must work very well for those DS3's doing 10 to 20 mb/s. Do you :upgrade those to OC3 or beyond? : : :-- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- :--Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- : : : :
RE: PSINet/Cogent Latency
40mb/s isn't loaded for a DS3? if you are measuring 40mb at five min intervals, micro peaks are pegged out causing serious packet loss. randy
RE: PSINet/Cogent Latency
My point exactly -- I guess some people disagree... Probably with any sort of queuing there will only be minimal packet loss at 40mbit, but at any point one more stream can push it up to 43mbit, and then queuing might no longer be enough... (and even if it is, can we say lag?) --Phil -Original Message- From: Randy Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 11:31 PM To: Phil Rosenthal Cc: [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency 40mb/s isn't loaded for a DS3? if you are measuring 40mb at five min intervals, micro peaks are pegged out causing serious packet loss. randy
Re: PSINet/Cogent Latency
On Mon, Jul 22, 2002 at 11:34:44PM -0400, Phil Rosenthal wrote: My point exactly -- I guess some people disagree... Probably with any sort of queuing there will only be minimal packet loss at 40mbit, but at any point one more stream can push it up to 43mbit, and then queuing might no longer be enough... (and even if it is, can we say lag?) Efficient packet loss is still packet loss. Just because you manage to make the link look good by slowing down TCP before your queueing latency starts going up doesn't make your network any less ghetto. IMHO the biggest problem in peering is getting the other side to actively upgrade links to prevent congestion. If you're not in a position where you can dictate terms to your peer, move traffic off it and let economics take care of the rest. Leaving a congested peer up for your own benefit at the expense of your customers is one of the surest ways to lose customers to someone who doesn't. I'd rather have a noncongested gige public peer than a ds3 private peer any day. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
RE: PSINet/Cogent Latency
Is there patch or special config example available that would allow me to use mrtg (or rather rrdtool) to measure more often and then graph it in a way that would show standard 5-min graph but also separate line showing those micro burst and actual peak usage? On Mon, 22 Jul 2002, Randy Bush wrote: 40mb/s isn't loaded for a DS3? if you are measuring 40mb at five min intervals, micro peaks are pegged out causing serious packet loss. randy
RE: PSINet/Cogent Latency
On Mon, 22 Jul 2002, Phil Rosenthal wrote: : :With the price of transit where it is today: :#1 Transit is often cheaper than peering (if you factor in port costs on :public exchanges, or link costs for private exchanges) :#2 The difference in price is likely not large enough for me to risk: :saturation, latency, etc... : :My customers pay me to provide them a premium service, and I see value :in providing that service. : :Some people have no problem selling cogent -- what can I say... You get :what you pay for... : :And no, I'm not trolling. Is having a different opinion not allowed :now? :And 40mbit over a 45mbit circuit, if it is to an uplink/peer -- well, if :he has customers who are connected at 100mbit switched uncapped (likely) :-- then many customers (possibly even some DSL customers...) can flood :off his peer links with only a 5mbit stream. Much better. Your prior posts lacked context and continuity. I've always advocated overprovisioning myself, vs. creative buffering, queuing, and/or distracting the end user. The statement I wouldn't think of getting T1, DS3 or OC3 in the fist place, without context, easily lends itself to misinterpretation. cheers, brian : :--Phil : :-Original Message- :From: Brian Wallingford [mailto:[EMAIL PROTECTED]] :Sent: Monday, July 22, 2002 11:13 PM :To: Phil Rosenthal :Cc: 'Alex Rubenstein'; [EMAIL PROTECTED] :Subject: RE: PSINet/Cogent Latency : : :Good for you, Phil. Chime in again when you've got something useful to :offer. : :In the meantime, you may want to review Economics 101 along with certain :queueing schemes, especially RED (no, I'm not endorsing the idea of :oversubscribing to the extreme, but then again, neither was Alex). : :Also, re-read the previous post. There's a big difference between :choice and facility. : :Did you grow up spending Summers in the Hamptons with no conception of :the value of a dollar, or are you simply trolling? : :-brian : : :On Mon, 22 Jul 2002, Phil Rosenthal wrote: : :: ::Actually, I wouldn't think about getting T1, DS3 or OC3 in the first ::place ;) :Oc-12 is the minimum link I would even look at -- and my :preference is :gig-e... Even if there is only 90 megs on the :interface... :: ::--Phil :: ::-Original Message- ::From: Alex Rubenstein [mailto:[EMAIL PROTECTED]] ::Sent: Monday, July 22, 2002 10:02 PM ::To: Phil Rosenthal ::Cc: [EMAIL PROTECTED] ::Subject: RE: PSINet/Cogent Latency :: :: :: :: ::On Mon, 22 Jul 2002, Phil Rosenthal wrote: :: :: :: I call any upstream link 'over capacity' if either: :: 1) There is less than 50mb/s unused :: ::That must work well for T1's and DS3's. :: :: :: 2) The circuit is more than 50% in use :: ::I call it 'over capacity' too, but that doesn't mean all the ducks are ::in a row to get both sides to realise an upgrade is needed, and even if ::they do realise it, to actually get it done. I am sure 2238092 people :on :this list can complain of the same problem. :: ::So, what do you do? You monitor it's usage, making adjustments to make ::sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 ::mbit/sec, with little to none increase in latency from the norm. Many ::people do this as well, even up to OC12 or higher levels all the time. :: :: :: :: :: I guess by my definition a DS3 is always 'over capacity' :: ::Which must work very well for those DS3's doing 10 to 20 mb/s. Do you ::upgrade those to OC3 or beyond? :: :: ::-- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- ::--Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- :: :: :: :: : : :
Nanog traceroute format string exploit. (fwd)
This came through on bugtraq this afternoon. -jba __ [[EMAIL PROTECTED]] :: analogue.networks.nyc :: http://analogue.net -- Forwarded message -- Date: Sun, 21 Jul 2002 14:09:24 +0200 From: SpaceWalker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Nanog traceroute format string exploit. Hello, As the vulnerability has been published some weeks ago, and no working exploit has been released (the perl exploit was joke) I decided to release my private exploit. I do it only because -This exploit will never be used to haxor something because I never saw this traceroute used by default -This exploit find offsets by the proper way and doesn't place the target adresses in the format string. (and is interresting to study for beginners). Have phun, please don't haxor with it. SpaceWalker tracerouteexp.tgz Description: Binary data
RE: PSINet/Cogent Latency
Packet loss is not guaranteed, especially considering the queuing mechanism used is not disclosed. IE, a simply hold queue north of 2048 will cause no loss, but the occasional jitter/latency, most likely not even measureable by common endpoints on the net. I'm not endorsing, just correcting. On Mon, 22 Jul 2002, Randy Bush wrote: 40mb/s isn't loaded for a DS3? if you are measuring 40mb at five min intervals, micro peaks are pegged out causing serious packet loss. randy -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: PSINet/Cogent Latency
On Mon, Jul 22, 2002 at 08:38:58PM -0700, [EMAIL PROTECTED] wrote: Is there patch or special config example available that would allow me to use mrtg (or rather rrdtool) to measure more often and then graph it in a way that would show standard 5-min graph but also separate line showing those micro burst and actual peak usage? Cricket (cricket.sourceforge.net). -- - mdz
RE: PSINet/Cogent Latency
An effective way would to graph queue drops: Serial4/1/1 is up, line protocol is up Description: to PSI via 3x-xxx-xxx- Internet address is 154.13.64.22/30 Last clearing of show interface counters 5w4d Queueing strategy: fifo Output queue 0/40, 2275 drops; input queue 0/75, 0 drops 30 second input rate 5000 bits/sec, 6 packets/sec 30 second output rate 39911000 bits/sec, 4697 packets/sec 144472370 packets input, 2769590243 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 1 giants, 0 throttles 0 parity 5 input errors, 5 CRC, 0 frame, 0 overrun, 1 ignored, 0 abort 1969955129 packets output, 430008350 bytes, 0 underruns FYI, for those of you commenting on my full PSI pipe, with a very small queue depth of only 40 packets, we've seen 0.00011548% percent drop -- 1 in every 865914 packets sent. Agreed, not 0%, but still, arguably that would never, ever be noticed by anyone. Once again, I don't condone; however, 1/1th of a percent of packet loss is easily worth the decreased cost in traffic sent to this endpoint. Anyone disagree? (an important a seperate note is that CAR/CEF drops due to ICMP reaching over 10 mb/s would trigger the same counter) On Mon, 22 Jul 2002, [EMAIL PROTECTED] wrote: Is there patch or special config example available that would allow me to use mrtg (or rather rrdtool) to measure more often and then graph it in a way that would show standard 5-min graph but also separate line showing those micro burst and actual peak usage? On Mon, 22 Jul 2002, Randy Bush wrote: 40mb/s isn't loaded for a DS3? if you are measuring 40mb at five min intervals, micro peaks are pegged out causing serious packet loss. randy -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
RE: PSINet/Cogent Latency
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Richard A Steenbergen On Mon, Jul 22, 2002 at 11:34:44PM -0400, Phil Rosenthal wrote: I'd rather have a noncongested gige public peer than a ds3 private peer any day. Except apparently that's called trolling ;) --Phil
RE: PSINet/Cogent Latency
As you probably guessed, I do... TCP is designed to not saturate links, so... If you take what should be 60 megs of traffic and put it limit it to 45, else queue for a while, or drop if queue full... The sessions will slow-start back up to a slow enough speed that wont drop. No (or very little) packet loss, but lower quality of service anyway. --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Rubenstein Sent: Tuesday, July 23, 2002 12:05 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency An effective way would to graph queue drops: Serial4/1/1 is up, line protocol is up Description: to PSI via 3x-xxx-xxx- Internet address is 154.13.64.22/30 Last clearing of show interface counters 5w4d Queueing strategy: fifo Output queue 0/40, 2275 drops; input queue 0/75, 0 drops 30 second input rate 5000 bits/sec, 6 packets/sec 30 second output rate 39911000 bits/sec, 4697 packets/sec 144472370 packets input, 2769590243 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 1 giants, 0 throttles 0 parity 5 input errors, 5 CRC, 0 frame, 0 overrun, 1 ignored, 0 abort 1969955129 packets output, 430008350 bytes, 0 underruns FYI, for those of you commenting on my full PSI pipe, with a very small queue depth of only 40 packets, we've seen 0.00011548% percent drop -- 1 in every 865914 packets sent. Agreed, not 0%, but still, arguably that would never, ever be noticed by anyone. Once again, I don't condone; however, 1/1th of a percent of packet loss is easily worth the decreased cost in traffic sent to this endpoint. Anyone disagree? (an important a seperate note is that CAR/CEF drops due to ICMP reaching over 10 mb/s would trigger the same counter) On Mon, 22 Jul 2002, [EMAIL PROTECTED] wrote: Is there patch or special config example available that would allow me to use mrtg (or rather rrdtool) to measure more often and then graph it in a way that would show standard 5-min graph but also separate line showing those micro burst and actual peak usage? On Mon, 22 Jul 2002, Randy Bush wrote: 40mb/s isn't loaded for a DS3? if you are measuring 40mb at five min intervals, micro peaks are pegged out causing serious packet loss. randy -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: PSINet/Cogent Latency
On Mon, Jul 22, 2002 at 08:38:58PM -0700, [EMAIL PROTECTED] wrote: Is there patch or special config example available that would allow me to use mrtg (or rather rrdtool) to measure more often and then graph it in a way that would show standard 5-min graph but also separate line showing those micro burst and actual peak usage? It's usually not practical to sample data that often, at least over snmp. 30 seconds is reasonable if your poller doesn't suck (aka not mrtg), but thats still a fair amount of averaging. As an example, looking at an interface doing 135Mbps average on a pretty steady curve through Juniper's monitor interface which gives 2 second samples, I see between 120Mbps and 150Mbps fluctuations almost constantly. Personally I would like to see the data collection done on the router itself where it is simple to collect data very frequently, then pushed out. This is particularly important when you are doing things like billing 95th percentile, where a loss of connectivity between the polling machine and the device is a loss of billing information. Why Juniper won't spend 5 minutes to make a simple lib so a program could sample interface counters, so someone could write this kind of system to run on the RE, is beyond me. I blame generations of dumbed down network engineers wielding perl as their only tool. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: PSINet/Cogent Latency
On Tue, Jul 23, 2002 at 12:04:34AM -0400, Alex Rubenstein wrote: An effective way would to graph queue drops: Serial4/1/1 is up, line protocol is up ifInDiscards = 1.3.6.1.2.1.2.2.1.13 ifOutDiscards = 1.3.6.1.2.1.2.2.1.19 A far more interesting thing to graph than temperature IMHO. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: PSINet/Cogent Latency
- Original Message - From: Richard A Steenbergen [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency Personally I would like to see the data collection done on the router itself where it is simple to collect data very frequently, then pushed out. This is particularly important when you are doing things like billing 95th percentile, where a loss of connectivity between the polling machine and the device is a loss of billing information. Redbacks can actually do this with what they call Bulkstats. Collects data on specified interfaces and ftp uploads the data file every so specified often. Pretty slick. Course, this isn't very helpful with Redback's extensive core router lineup, but still. --Doug
RE: PSINet/Cogent Latency
Call me crazy -- but what's wrong with setting up RRDtool with a heartbeat time of 30 seconds, and putting in cron: * * * * * rrdscript.sh ; sleep 30s ; rrdscript.sh Wouldn't work just as well? I haven't tried it -- so perhaps this is too taxing (probably you would only run this on a few interfaces anyway)... The last time I tested such a thing was on an uplink doing ~200 mgs and deviation was about +/- 5mbs per second --Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Doug Clements Sent: Tuesday, July 23, 2002 12:59 AM To: Richard A Steenbergen Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency - Original Message - From: Richard A Steenbergen [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency Personally I would like to see the data collection done on the router itself where it is simple to collect data very frequently, then pushed out. This is particularly important when you are doing things like billing 95th percentile, where a loss of connectivity between the polling machine and the device is a loss of billing information. Redbacks can actually do this with what they call Bulkstats. Collects data on specified interfaces and ftp uploads the data file every so specified often. Pretty slick. Course, this isn't very helpful with Redback's extensive core router lineup, but still. --Doug
Re: PSINet/Cogent Latency
- Original Message - From: Phil Rosenthal [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency Call me crazy -- but what's wrong with setting up RRDtool with a heartbeat time of 30 seconds, and putting in cron: * * * * * rrdscript.sh ; sleep 30s ; rrdscript.sh Wouldn't work just as well? I haven't tried it -- so perhaps this is too taxing (probably you would only run this on a few interfaces anyway)... Redback's implementation overcame the limitation of monitoring say, 20,000 user circuits. You don't want to poll 20,000 interfaces for maybe 4 counters each, every 5 minutes. I think the problem with using rrdtool for billing purposes as described is that data can (and does) get lost. If your poller is a few cycles late, the burstable bandwidth measured goes up when the poller catches up to the interface counters. More bursting is bad for %ile (or good if you're selling it), and the customer won't like the fact that they're getting charged for artifically high measurements. Bulkstats lets the measurement happen independant of the reporting. --Doug
RE: PSINet/Cogent Latency
I don't think RRD is that bad if you are gonna check only every 5 minutes... Again, perhaps I'm just missing something, but so lets say you measure 30 seconds late , and it thinks its on time -- So that one sample will be higher , then the next one will be on time, so 30 seconds early for that sample -- it will be lower. On the whole -- it will be accurate enough -- no? Besides I think RRD has a bunch of things built in to deal with precisely this problem. I'm not saying a hardware solution can't be better -- but it is likely overkill compared to a few cheap intels running RRD -- assuming your snmpd can deal with the load... --Phil -Original Message- From: Doug Clements [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 23, 2002 1:50 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: PSINet/Cogent Latency - Original Message - From: Phil Rosenthal [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency Call me crazy -- but what's wrong with setting up RRDtool with a heartbeat time of 30 seconds, and putting in cron: * * * * * rrdscript.sh ; sleep 30s ; rrdscript.sh Wouldn't work just as well? I haven't tried it -- so perhaps this is too taxing (probably you would only run this on a few interfaces anyway)... Redback's implementation overcame the limitation of monitoring say, 20,000 user circuits. You don't want to poll 20,000 interfaces for maybe 4 counters each, every 5 minutes. I think the problem with using rrdtool for billing purposes as described is that data can (and does) get lost. If your poller is a few cycles late, the burstable bandwidth measured goes up when the poller catches up to the interface counters. More bursting is bad for %ile (or good if you're selling it), and the customer won't like the fact that they're getting charged for artifically high measurements. Bulkstats lets the measurement happen independant of the reporting. --Doug
Re: PSINet/Cogent Latency
On Tue, Jul 23, 2002 at 01:56:45AM -0400, Phil Rosenthal wrote: I don't think RRD is that bad if you are gonna check only every 5 minutes... RRD doesn't measure anything, it stores and graphs data. The perl pollers everyone is using can barely keep up with 5 minute samples on a couple dozen routers and a few hundred interfaces, requiring poller farms to be distributed across a network, 'lest a box or part of the network break and you lose data. Again, perhaps I'm just missing something, but so lets say you measure 30 seconds late , and it thinks its on time -- So that one sample will be higher , then the next one will be on time, so 30 seconds early for that sample -- it will be lower. On the whole -- it will be accurate enough -- no? enough is a relative term, but sure. :) I'm not saying a hardware solution can't be better -- but it is likely overkill compared to a few cheap intels running RRD -- assuming your snmpd can deal with the load... What hardware... storing a few byte counters is trivial, but polling them through snmp is what is hard (never trust a protocol named simple or trivial). Creating a buffer of samples which can be periodically sampled should be easy and painless. I don't know if I call periodic ftp painless but its certainly a start. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: PSINet/Cogent Latency
- Original Message - From: Phil Rosenthal [EMAIL PROTECTED] Subject: RE: PSINet/Cogent Latency I don't think RRD is that bad if you are gonna check only every 5 minutes... Again, perhaps I'm just missing something, but so lets say you measure 30 seconds late , and it thinks its on time -- So that one sample will be higher , then the next one will be on time, so 30 seconds early for that sample -- it will be lower. On the whole -- it will be accurate enough -- no? If you're polling every 5 minutes, with 2 retrys per poll, and you miss 2 retrys, then your next poll will be 5 minutes late. It's not disastrous, but it's also not perfect. Again, peaks and vallys on your graph cost more than smooth lines, even with the same total bandwidth. Do you want to be the one to tell your customers your billing setup is accurate enough, and especially that it's going to have a tendancy to be accurate enough in your favor? Besides I think RRD has a bunch of things built in to deal with precisely this problem. Wouldn't that be just spiffy! I'm not saying a hardware solution can't be better -- but it is likely overkill compared to a few cheap intels running RRD -- assuming your snmpd can deal with the load... No extra hardware needed. I think the desired solution was integration into the router. The data is already there, you just need software to compile it and ship it out via a reliable reporting mechanism. For being relatively simple, it's a nice idea that it could replace the almost in an almost accurate billing process. --Doug
Security of DNSBL spam block systems
What are the security implications of someone hacking a DNSBL (Real-time-spam-block-list) and changing the block list to include (deny email from) some very large portion or all IPv4 space? Given that a signifigant number of the spam blocking lists seem to operate on a shoestring budget in someone's basement, how can we be assured that they have sufficient resources to secure their systems adequatley, and monitor for intrusion 24x7? Unless I am missing something, this would seem to be a real handy and centralizedmethod for someonetointerfere substantially with the proper operation of a few thousand email servers and hold up global email traffic for a few hours. -BB
