September 2002 - Test - lists.nanog.org

RE: Cogent service
by David Diaz 20 Sep '02

20 Sep '02

I dont believe that number at all. Not to disagree with you at all Matt. But real world, it would depend on the design. If you are going router to router then it would be closer to accurate. I have seen 1-2ms added per router under load. That also might factor in a hop inside the room between 1 routers or another gear and a router. Coming in one card, having to do a lookup, going out another card to another box then out the layer 1 circuit to the next city. A VPN might not save this time though. But hubbing to a regional center, and then placing this traffic on an express circuit to the next regional city might save some of these ms. In other words LA to San Fran, an express fiber route to Chi, then out a peering connection. This would save 5-8ms compared to LA, San Fran, Portland, Salt Lake, Chi where at each hope 1-2 routers would insert themselves into the process. In my book, 5-8ms is not a real factor.... Dont get me started on speed of light on fiber... At 18:21 +0100 9/20/02, Matt Ryan wrote: >>The hop count question is interesting. Is the consensus that it's >>mostly a customer service issue, where latency isnt affected but >>customer perception is? Or is it a real latency issue as more >>routers take a few CPU cycles to make a routing decision. > >The routers these days make a forwarding decision in ~20 ns - its going to >take a few hops before this becomes significant. Speed of light on long >links is a couple of orders of magnitude more delay inducing. > > >Matt. > >------------------------------------------------------------------------------ >Live Life in Broadband >www.telewest.co.uk > > >The information transmitted is intended only for the person or >entity to which it is addressed and may contain confidential and/or >privileged material. >Statements and opinions expressed in this e-mail may not represent >those of the company. Any review, retransmission, dissemination or >other use of, or taking of any action in reliance upon, this >information by persons or entities other than the intended recipient >is prohibited. If you received this in error, please contact the >sender immediately and delete the material from any computer. > > >============================================================================== -- David Diaz dave(a)smoton.net [Email] pagedave(a)smoton.net [Pager] Smotons (Smart Photons) trump dumb photons

1 0

Re: Whitehouse Tackels Cybersecurity
by Gregory Hicks 20 Sep '02

20 Sep '02

There IS another list that goes to about the same group of people... NANOG-OT nanog-offtopic(a)lists.blank.org Just a thought... Regards, Gregory Hicks > Date: Fri, 20 Sep 2002 14:39:08 +0200 > From: Brad Knowles <brad.knowles(a)skynet.be> > > At 8:05 AM -0400 2002/09/20, Susan Harris wrote: > > > Brad, this message contains no technical content. Please keep political > > commentary in private email. Refer to the NANOG list AUP: > > > > http://www.nanog.org/aup.html > > > > Upon your next AUP violation, we'll need to remove your posting priveleges > > from the list. > > > > Susan Harris, Ph.D. > > Merit Network/Univ. of Mich. > > If I'm going to get one of these messages every time I submit > something to the list, then you might as well go ahead and > unsubscribe me now. > > If the list isn't about discussion, and other people continue to > post on the same subjects but don't get treated the same way, then > you have some very serious personal issues that you need to resolve. > > -- > Brad Knowles, <brad.knowles(a)skynet.be> > > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > -Benjamin Franklin, Historical Review of Pennsylvania. > > GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- > O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) > tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks(a)cadence.com "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff You can have it done good, fast, or cheap -- pick any two.

1 0

Re: Whitehouse Tackels Cybersecurity
by Brad Knowles 20 Sep '02

20 Sep '02

At 8:05 AM -0400 2002/09/20, Susan Harris wrote: > Brad, this message contains no technical content. Please keep political > commentary in private email. Refer to the NANOG list AUP: > > http://www.nanog.org/aup.html > > Upon your next AUP violation, we'll need to remove your posting priveleges > from the list. > > Susan Harris, Ph.D. > Merit Network/Univ. of Mich. If I'm going to get one of these messages every time I submit something to the list, then you might as well go ahead and unsubscribe me now. If the list isn't about discussion, and other people continue to post on the same subjects but don't get treated the same way, then you have some very serious personal issues that you need to resolve. -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

1 0

The Cidr Report
by cidr-report＠potaroo.net 20 Sep '02

20 Sep '02

This report has been generated at Mon Sep 16 18:33:13 2002 AEST. The report analyses the BGP Routing Table of the Route-Views router and generates a report on aggregation potential within the table. Check http://bgp.potaroo.net/cidr for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-09-02 121168 88703 10-09-02 121129 88787 11-09-02 121290 88946 12-09-02 121145 87146 13-09-02 121338 87745 14-09-02 121318 87720 15-09-02 121238 87859 16-09-02 122134 87830 Possible Bogus Routes 39.0.0.0/8 AS4554 EP0-BLK-ASNBLOCK-4 Exchange Point Blocks AS Summary 13914 Number of ASes in routing system 5301 Number of ASes announcing only one prefix 1804 Largest number of prefixes announced by an AS AS209 : ASN-QWEST Qwest 73154816 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is not proposed across non-advertised address space ('holes'). --- 16Sep02 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 121976 88656 33320 27.3% All ASes AS209 1804 1042 762 42.2% ASN-QWEST Qwest AS3908 1133 650 483 42.6% SUPERNETASBLK SuperNet, Inc. AS2548 1581 1127 454 28.7% ICIX-MD-AS Business Internet, Inc. AS7132 601 183 418 69.6% SBIS-AS Southwestern Bell Internet Services AS701 1762 1351 411 23.3% ALTERNET-AS UUNET Technologies, Inc. AS7018 1349 959 390 28.9% ATT-INTERNET4 AT&T WorldNet Services AS1221 1301 939 362 27.8% ASN-TELSTRA Telstra Pty Ltd AS4323 645 307 338 52.4% TW-COMM Time Warner Communications, Inc. AS7046 607 312 295 48.6% UUNET-CUSTOMER UUNET Technologies, Inc. AS6197 383 97 286 74.7% BATI-ATL BellSouth Network Solutions, Inc AS852 737 456 281 38.1% ASN852 Telus Advanced Communications AS7843 664 386 278 41.9% ADELPHIA-AS Adelphia Corp. AS18566 270 4 266 98.5% COVAD Covad Communications AS4151 284 32 252 88.7% USDA-1 USDA AS1 682 449 233 34.2% GNTY-1 Genuity AS6347 396 180 216 54.5% DIAMOND SAVVIS Communications Corporation AS4814 233 34 199 85.4% CHINANET-BEIJING-AP China Telecom (Group)Beijing Telecom CompanyBeijing China AS690 519 326 193 37.2% NSFNET-T3-RT-AS Merit Network Inc. AS4355 360 170 190 52.8% ERMS-EARTHLNK EARTHLINK, INC AS1239 851 662 189 22.2% SprintLink Sprint AS2386 418 233 185 44.3% INS-AS AT&T Data Communications Services AS4134 302 118 184 60.9% ERX-CHINALINK Data Communications Bureau AS6595 244 74 170 69.7% DODDSEUR DoD Education Activity Network Assistance Center AS3356 392 226 166 42.3% LEVEL3 Level 3 Communications, LLC AS1791 186 23 163 87.6% SPRINTLINK3 Sprint Government Systems Division AS11371 169 7 162 95.9% UUNET-AS-11371 UUNET Technologies, Inc. AS376 341 184 157 46.0% RISQ-AS Reseau Interordinateurs Scientique Quebecois (RISQ) AS17676 220 65 155 70.5% GIGAINFRA APNIC ASN block AS6539 350 200 150 42.9% GROUPTLCOM GT Group Telecom Services Corp. AS577 424 275 149 35.1% BACOM Bell Advanced Communications Inc. Total 19208 11071 8137 42.4% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Re: Cogent service
by Michael L. Barrow 19 Sep '02

19 Sep '02

> wouldn't affect anyone but us. They admitted we needed it and couldn't get > the affect any other way, but just couldn't do it. "That's not the product we > offer." Yeah -- those types of things suck, but from their perspective this kind of policy allows them to keep their service level consistent. One-offs can end up being expensive in the long run. "If I do it for you, everyone will want the same thing!" -- Michael L. Barrow E: michael(a)mlbarrow.com P: 805-566-0885

3 2

FYI: download.microsoft.com problem
by Mike Lewinski 19 Sep '02

19 Sep '02

We're seeing bad throughput via http from both IP addresses we resolve for this host (207.46.235.150 and 207.46.235.162). Connections from three unrelated AS all with T1 or better are giving throughput in tests with wget around 28-64Kbps). Each has a unqiue path to MS. One of our clients reports that from his AT&T cable modem, he gets 1.5Mbps+ for the same file at the same time. Perhaps they're caching the files? (not sure how comfortable I'd be with my provider caching something important like an OS update). Our outbound path to MS currently traverses AT&T fwiw. A test to ftp.microsoft.com when this was first reported to us last night yielded closer to 750Kbps peak and slowly climbing when it completed, so this doesn't look like a congestion issue AFAICT. Traceroutes to MS look quite good, no loss and low latency (all under 100ms) as far as they go. Tests to other sites from all three AS I checked looked significantly better by a factor of 20-50; I found no evidence of connectivity issues anywhere I checked except MS. Copies of the test results and traceroutes were sent to the listed MS contacts on jared's noc list. No auto-ack or bounces yet.... I made one last test (using IE instead of wget), and things seem slightly improved, yielding an initial 800kbps that quickly dropped to 300 dropped steadily to a final 112kbps on a 17MB file. Repeating the wget test also showed some improvement, but not as much (round robin makes this tough to accurately guage). Mike

3 2

Whitehouse Tackels Cybersecurity
by sgorman1＠gmu.edu 18 Sep '02

18 Sep '02

A little flavor of what I'd alluded to in some of the previous threads. Any guesses what the proposal to change both BGP and DNS to improve security might entail?? White House tackles cybersecurity By Declan McCullagh Special to ZDNet News September 16, 2002, 6:58 PM PT http://zdnet.com.com/2100-1105-958159.html The White House's cyberspace security plan, scheduled to be released Wednesday, envisions a broad new role for the federal government in maintaining Internet security.

4 3

RE: Vulnerbilities of Interconnection
by Kurtis Lindqvist 18 Sep '02

18 Sep '02

> I know that the capacity throughout the network I was working on > at the time was designed to handle peak loads with a comfortable > margin, and I would surmise that that is the case on many, if not > most networks. It seems obvious that the scope of the analysis of > this issue must include datacenters and servers, not only the net. > > Other than the electrical power issue in NYC, I don't recall any > loss of communications on 9/11/2001 that related directly to the > network. We where providing emergency transit services to operators in Europe during that day who lost parts or all of their transatlantic services. At the same time people where obviously relaying on the net for information (or we wouldn't have seen the congestions) but the net failed to deliver (congestions at the servers). So, perhaps it's time to start re-thinking what we did - to some extent I think that we already have. - kurtis -

1 0

How do you stop outgoing spam?
by Hank Nussbacher 18 Sep '02

18 Sep '02

Please try to keep this discussion technical and not diverge to opinions. I am not looking for opinions or religion. I am trying to find automated tools/systems/boxes that will stop spam from going *out* from an ISP. The ISP has no servers and allocates IP address space to downstream customers who spam. Yes, I know all about ACLs to block offending IPs. The ISP is willing to buy any box or system to stop outgoing spams and thereby stop constantly playing with ACLs. The spamming is usually done (but not only) from an Internet cafe where the spammer inserts a "spammer CD" and blasts away at open mail relays. When SMTP is blocked for that IP, they switch to HTTP and send the spam via MSN, Yahoo, Hotmail, Kukamail, Outblaze, Safe-mail, etc. to name just a few. Blocking port 80 is harder since it requires maintaining an ever larger list of free public web based mail systems or just block port 80 entirely. Technical solutions welcome. Thanks, Hank

29 76

Re: How do you stop outgoing spam?
by Dave Crocker 18 Sep '02

18 Sep '02

At 02:11 PM 9/16/2002 -0400, Greg A. Woods wrote: > > 2. The issue with email is authentication, not privacy. Authentication can > > be achieved can be achieved easily over port 25, without encryption. > >Well, no, not securely it can't. You cannot have a secure authenticated >service running over a raw TCP circuit across public networks. 1. You are adding to the requirement. No matter how reasonable or advisable, encryption (privacy) is a separate function from authentication. And the rationale for doing port 25 port blocking has to do with accountability, not privacy. 2. Just so there is no confusion, I meant encryption as in privacy (content encryption) rather than as part of an authentication mechanism. 3. SMTPAUTH does not require an alternate port, yet it is sufficient for ensuring accountability. Hence it is sufficient for dealing with the reason that port 25 is blocked, without requiring that it be blocked. > > Hence, blocking port 25 blocks legitimately validated email, > > as well as possible spam. > >Well, yes, but obviously that doesn't matter. This is the real world Dave. Thanks for noticing that. That is why I keep citing the impact on real, mobile users and the implication for such minor opportunities such as wireless hotspots. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850

3 3