- Test - lists.nanog.org

Linux routing
by Ralph Doncaster 22 May '02

22 May '02

I don't really trust the vmstat system time numbers. Based on some suggestions I received, I ran some CPU intensive benchmarks during different traffic loads, and determined how much system time was being used by comparing the real and user times. The results seem to show that if I want to do 50Mbps full-duplex on 2 ports (200M aggregate) that the standard Linux 2.2.20 routing code won't cut it. Unloaded Duron 1G root@TO-VS ~# time bzip2 /tmp/words real 0m0.414s user 0m0.400s sys 0m0.010s 750Mhz Duron, ~20Mbps traffic, 8K int/sec vmstat reported CPU idle: 98% (2% system) root@tor-router ~# time bzip2 /tmp/words real 0m0.628s user 0m0.380s sys 0m0.160s CPU load ~= 40% root@tor-router ~# time bzip2 /tmp/words real 0m0.552s user 0m0.460s sys 0m0.090s CPU load ~=16% 750Mhz Duron, ~60Mbps traffic, 20K int/sec vmstat reported CPU idle: 95% (5% system) root@tor-router ~# time bzip2 /tmp/words real 0m1.071s user 0m0.370s sys 0m0.690s CPU load ~= 65% root@tor-router ~# time bzip2 /tmp/words real 0m1.041s user 0m0.440s sys 0m0.600s CPU load ~= 58%

4 4

'SQLsnake' Worm Blamed For Spike In Port 1433 Scans
by blitz 22 May '02

22 May '02

> 'SQLsnake' Worm Blamed For Spike In Port 1433 Scans >http://www.newsbytes.com/news/02/176701.html > >By Brian McWilliams, Newsbytes >SAN MATEO, CALIFORNIA, U.S.A., >21 May 2002, 11:04 AM CST > >A mounting trail of evidence has security experts warning that a new >Internet worm targeting Microsoft SQL servers could be on the loose. > >Since Monday, a sharp spike in remote probes of TCP port 1433, which >commonly is used by Microsoft's SQL database, has been reported by >many server administrators, according to SecurityFocus, which operates >an incident-reporting system called ARIS. --snipped for brevity, full article at url above.

1 0

Spammers could face fines
by blitz 21 May '02

21 May '02

We can hope cant we? Forward from another list: >Spammers could face fines > >Reuters >May 17, 2002, 12:20 PM PT > >A bill aimed at limiting unwanted junk e-mail was approved and sent >to the floor by the Senate Commerce Committee on Friday with >unanimous support from Democrats and Republicans. It would strengthen >the Federal Trade Commission's enforcement authority by allowing it >to impose fines of up to $10 each on e-mails that violate existing >laws against spam, with a cap of $500,000. > >Sen. Conrad Burns, a Montana Republican and co-sponsor of the >legislation, said the bill would help both e-commerce and consumers >burdened by unsolicited junk or pornographic e-mails. "Rampant >pornography and fraudulent credit deals were never the destiny of the >Internet, but they have become commonplace fixtures in in-boxes >everywhere," he said. > >No similar measure is pending in the U.S. House of Representatives. > >New Mexico Republican Rep. Heather Wilson's bill requiring spammers >to use a legitimate return address--so unwanted e-mail can more >easily be blocked--has not yet been scheduled for a vote. > >Twenty-two states have passed anti-spam legislation. Spam has >especially been a problem for rural consumers, many of whom pay >long-distance charges for Internet connections and waste time and >money erasing their unwanted e-mails, Burns said. > >The Senate Commerce Committee on Friday approved an amendment by Sen. >Barbara Boxer, a California Democrat, that would prohibit >transmitting unwanted e-mails to addresses that were illegally >obtained from Web sites. > >Co-sponsor Sen. Ron Wyden, an Oregon Democrat, said moving the bill >would help the FTC deal with thousands of complaints it has received >about spam. > >"The problem is, the technology is on the side of the spammer," Wyden >said. > >The proposal would also require e-marketers to include a working >return address to allow recipients the option of refusing further >e-mails, and give Internet service providers the ability to bring >suit to keep unlawful spam off their networks. > >It would also subject spammers who intentionally disguise their >identities to misdemeanor criminal penalties.

1 0

DoS on ftp port
by Brian Wilson 21 May '02

21 May '02

Just wondering if anyone else has seen this happen recently: https://uni01nf.unity.ncsu.edu/ncsu/usage/io-fps-service-daily.html We maxed out at about 10,000 flows/sec. I'm currently going back through our argus logs and collecting a list of source hosts (all appear to be spoofed of course). In a 15 minute period we had 4.2 million unique hosts pounding one of our servers. The only reason I post this is that on some other off-campus machines I maintain, I've seen an increase in ftp connections. So, I was wondering if this is some new worm, ddos, or something of that nature. If anyone would care to comment, I'm all ears. Brian -- Brian Wilson wilson(a)ncsu.edu Network Analyst W: 919.513.3472 Communication Technologies F: 919.513.1893 North Carolina State University http://www.ncstate.net

5 5

Re: "portscans" (was Re: Arbor Networks DoS defense product)
by Scott Francis 21 May '02

21 May '02

On Sat, May 18, 2002 at 05:25:27PM -0400, woods(a)weird.com said: > [ On Saturday, May 18, 2002 at 13:48:27 (-0700), Scott Francis wrote: ] > > Subject: Re: "portscans" (was Re: Arbor Networks DoS defense product) > > > > > However a "portscan" is not an attack. > > > > Precursor to an attack, certainly. > > B.S. A plain old port or IP scan is nothing more than an information > gathering excercise. Unless you're the one running it you almost > certainly have no clue whatsoever why it was started. (Unless you can > prove somehow that the scan pattern and/or packets matches a signature > that's proven to be _unique_ to some known attack tool.) And why, pray tell, would some unknown and unaffiliated person be scanning my network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks). -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui

12 32

mssql worm, contact info for postone.com
by Johannes Ullrich 21 May '02

21 May '02

The new sql worm we started covering yesterday is sending password lists to ixltd(a)postone.com . Just a quick heads up that you may want to watch stuff sent to that address. Anybody here from Singapore? postone.com is registered to a singapore company. -- --------------------------------------------------------------- jullrich(a)sans.org Collaborative Intrusion Detection join http://www.dshield.org

1 0

RE: The market must be coming back
by Christopher J. Wolff 21 May '02

21 May '02

Jason, Are you espousing Juniper or Foundry for 10ge? -----Original Message----- From: Jason LeBlanc [mailto:jml@packetpimp.org] Sent: Monday, May 20, 2002 9:35 PM To: Gary; Christopher J. Wolff Cc: nanog(a)merit.edu Subject: RE: The market must be coming back Juniper. Sorry I'm a fan, they've done a lot right. Cisco is ~$35k per port of 10ge, and unless you get a 6513 you can't get many interfaces. This makes 10ge in a real network (where everything needs to be redundant, multiple interfaces, etc) a bit impossible on the Catalyst platform. If your needs are but a few interfaces, maybe it works. Cisco is woefully behind here. The SUP2/SFM method of doing things is a patch at best to boot. Foundry is cheaper and a bit ahead in many aspects, granted there are SW issues still looming, but the 'life of a packet' as a packet is handled by a Foundry switch makes a lot more sense. Foundry ASIC's are rockin, as are Juniper's, Cisco seems to be lost here. I think the ASIC designers ran off to Foundry and Juniper. ;) If only Juniper made 'switches', such that density were higher, cost per port were lower and they were more applicable to switching (L2/STP, etc) and LAN specific needs. Additionally, anyone have thoughts on the Unisphere purchase by Juniper? I think it should scare the bejesus out of Cisco. Always interested in the opinions of the brightest, let the flames begin. ;) -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Gary Sent: Monday, May 20, 2002 9:15 PM To: Christopher J. Wolff Cc: nanog(a)merit.edu Subject: RE: The market must be coming back Chris: > I've been thinking about leasing some dark fiber and running one of > the new 10gigE blades for the Cat 6500 chassis. Be careful here. Last I tested (at one of our channels that also resells Cisco) is that the 10GbE on the Catalyst 6500 hasn't broken 4G throughput yet. Sort of like buying a GbE interface for a 7200 (It only get's 10% throughput... Why waste the money, just buy FE!). The GSR is up to about 8G throughput nowadays from what I've seen. Foundry Networks (my company) can get a perfect clean 8G throughput on all of our chassis with management modules M2 or above (we don't support 10GbE on the legacy M1). Our NG chassis will be available later in the year for those folks that want 4 X 10 GbE on each module (8 slot chassis). I expect this will be a perfect 40G throughput since I've never seen us do anything less than perfect (been working here since August). Additionally, you would be the first customer I've heard about doing standards based 10GbE on a Catalyst. (feel free to chime in if you're doing this... Can I bring my SmartBits 600 to your site to test throughput?). Good luck! Foundry has a few references: Deployed: http://www.foundrynet.com/about/newsevents/releases/pr4_3_02.html http://www.foundrynet.com/about/newsevents/releases/pr4_2_02.html http://www.foundrynet.com/about/newsevents/releases/pr2_11_02.html Many others that we don't press release. We've got these blades running in production networks here in Japan that I'm not allowed to talk about. Also many other places. Deploying: http://www.foundrynet.com/about/newsevents/releases/pr5_8_02.html Performance: http://www.spirentcom.com/news/press.cfm?id=87 > Throw in the Cisco "Flamethrower" GBIC and I should be good for 50 > miles. Has anyone tried > this? Foundry Network's Long Haul (LHB: 150 km, LHA: 70 km) Ethernet optics exceed Cisco's on GbE (ZX: 100 km). I'm sure we exceed them on the ER LAN PHY for 10GbE. We've only tested to 85 kilometers (ER). 802.3ae standard is 40 km: http://biz.yahoo.com/prnews/020508/nyw068_1.html Cisco's website says they can do the 802.3ae standard 40 km on the 1550 nm blade. I'm not sure if the optics are changeable either: http://www.cisco.com/warp/public/cc/pd/ifaa/6500ggml/ I doubt if there is a GBIC for 10GbE available. We use the same blade with changeable optics; however, I would not call the SR (300 meters), LR (10 km), and ER LAN PHY optics GBIC's... Moral of this story is that BEFORE you buy these blades from Cisco (or anybody), test them! If you don't have 10GbE SmartBits or IXIA, you can use 1GbE interfaces and wrap them around until you get 8G (no need to produced anything higher 'cause the Cat 6500 has an 8G throughput limitation). Don't test latency with this method :-). I don't believe the marketing from any company, not even my own. I test, then tell. I've personally never seen a packet drop at a steady 8G rate for up to 72 hours; however, one of our customers evaluating the 10GbE blades reported 2 64 byte packet's were dropped in a 12 hour line rate test. I suspect they had bad fiber. Gary Blankenship Systems Engineer Foundry Networks

1 0

RE: Network Reliability Engineering
by Randy Neals 21 May '02

21 May '02

While it is possible to get the FIT numbers for hardware and calculate network availability, our experience has been that modelling hardware reliability and calculating network availability was not particularly usefull as hardware and fiber transmission systems are usually the least signifigant factor in overall network availability. Hardware failures are also easy to design around by redundant hardware, or more boxes, or diverse fiber routes. Network software issues and Operational mistakes seem to affect Network Availability more than hardware. An example would be a bug in a routing protocol that causes an erroneous update to propagate through the network. Or in the operational category, a typo which causes unintended results. In both cases these failures are not limited to one box, but often cause problems or their effects to propagate throughout the entire network. How do you objectively calculate the network availability when the network is highly dependant upon the correct functioning of a binary blob of proprietary code, but your only visability inside the blob is a release note listing the symptoms experienced by others who have run the code in a similar, but probably not identical network configuration? It seems unlikely that vendors are going to disclose more about their proprietary blob of binary to protect their I.P. assets. This leaves teh netwrok operator without much to assess code reliability. Perhaps we need to change the business model around network code licensing to ensure vendors comprehend the impact of a bad release, and share the pain when they release a buggy blob that has customer impact on the network. Rather than a one-time fee to license the code when you buy the box, a small recurring monthly license fee, with no payment in any month that a software bug crashes your network, would act as a continuous form of positive reinforcement for your box vendor to ensure your network has high availability code. The box vendor would have a recurring revenue stream for software licensing that is only as stable and reliable as their software. -R -----Original Message----- From: Pete Kruckenberg To: nanog(a)merit.edu Sent: 5/18/2002 7:13 PM Subject: Network Reliability Engineering I'm looking for some good reference materials to do some "reliability engineering" calculations and projections. This is to justify increased redundancy, and I want to include quantifiable numbers based on MTBF data and other reliability factors, kind of a scientific justification instead of just the typical emotional appeal using analyst/vendor FUD. I'd appreciate references on how to do this in a network environment (what data to collect, how to collect it, how to analyze, etc). Also any data (or rules of thumb) on typical MTBFs for network events that I won't find on vendor product slicks (like what's the MTBF on IOS, or human-caused service outages of various types, etc). If someone has put together something remotely like this that they'd care to share, that'd be incredibly helpful. Thanks. Pete.

1 0

RE: The market must be coming back
by Joe Blanchard 21 May '02

21 May '02

Don't know whats up with the list server. I didn't get any messages all last week then checked the archives page and saw tons of msgs that I never got. I re-subscribed and now there are some coming thru, and some are missing. I sent an email about this to www(a)medit.edu, but I don't know if thats the right contact. Anyone else having problems? -Joe -----Original Message----- From: Christopher J. Wolff [mailto:chris@bblabs.com] Sent: Monday, May 20, 2002 5:27 PM To: nanog(a)merit.edu Subject: The market must be coming back

1 0

Canonical bogon list?
by kevin graham 21 May '02

21 May '02

Does anyone know of a source for a reliable bogon list? The best I know if is from Rob Thomas, but his last template update was 10/01, and IANA's made allocations since then. http://www.iana.org/assignments/ipv4-address-space is the best I can find, but wanted to see if anyone had a more thorough compilation.. If someone (IANA?) kept a MAINT-BOGON object in one of the IRR's, it'd be fantastic w/ just a bit of hacking on RtConfig. Any takers? ..kg..

3 2