May 2002 - Test - lists.nanog.org

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 20 May '02

20 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 20 May '02

20 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 20 May '02

20 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

Re: The market must be coming back
by dre 20 May '02

20 May '02

On Mon, May 20, 2002 at 05:27:20PM -0700, Christopher J. Wolff wrote: > > Everyone's so busy there hasn't been a peep on here in weeks. > > Regards, > Christopher J. Wolff, VP CIO Nah, we're just not "allowed" to post here anymore. Inside joke with myself, please ignore ;> -dre

1 0

RADB mirroring
by Ralph Doncaster 20 May '02

20 May '02

RADB definately does not mirror (at least not daily) ARIN's RR. Time to setup with altdb... % ARIN Internet Routing Registry Whois Interface route: 66.11.160.0/20 descr: Doncaster Consulting Inc. 2720 Queensview Dr Ottawa, ON K2B 1A5 CA origin: AS21936 notify: sysadmin(a)istop.com mnt-by: MNT-ISTOP changed: sysadmin(a)istop.com 20020517 source: ARIN [ralph@cpu1693 lralph]$ whois 66.11.160.0(a)whois.radb.net [whois.radb.net] % No entries found for the selected source(s). Ralph Doncaster principal, IStop.com div. of Doncaster Consulting Inc.

5 4

Re: Interconnects
by ren 20 May '02

20 May '02

That depends on your corporate needs for power, security, remote hands, etc. The extended services found at Equinix & PAIX are very important for many networks. -ren At 08:00 AM 5/17/2002 -0400, Ralph Doncaster wrote: >What about NYIIX/6IIX? >Being in Telehouse where there are no monthly fees for for cross-connects >gives it a financial advantage over Equinix. > >Ralph Doncaster >principal, IStop.com >div. of Doncaster Consulting Inc. > >On Fri, 17 May 2002, ren wrote: > > > > > Hi Iljitsch, > > > > I would not consider Sprint NAP, a place closed to new customers for > > several years, an important interconnect location in the US. ATM based > IXs > > are not as participant rich as they were 2-3 years ago. > > > > The fastest growing US interconnect locations are cross-connect > > enabled. PAIX & Equinix. Equinix-Ashburn, PAIX-Seattle, Equinix-Newark > > and Equinix-Dallas and others have seen participation grow with a diverse > > blend of traffic from cable operators, telcos and content providers. > > > > Tier-1 means what? Look for growing sources of traffic. > > > > Your mileage may vary, -ren > > > > At 11:48 AM 5/17/2002 +0200, Iljitsch van Beijnum wrote: > > > > >A bunch of us are thinking about multihoming solutions for IPv6. For this > > >purpose, it is useful to know a bit more about how actual networks (rather > > >than the ones existing only as ASCII drawings) interconnect. So: > > > > > >- What are the 12 - 18 most important interconnect locations in the world? > > > MAE East, the Ameritech, Sprint and PacBell NAPs, PAIX, LINX and AMS-IX > > > come to mind, but from where I'm sitting it's hard to judge whether > > > others are important or marginal. > > > > > >- To how many of them do typical tier-1 and tier-2 networks connect? > > > > > >- Using private or public interconnects? > > > > > >

14 22

Routes down to yahoo.com, etc. from Wash DC?
by Mary Grace 20 May '02

20 May '02

IS it just us out hereon the Right Coast in the Washington DC area, but are a number of routes to the Bay Area and Southern California down? We can't get traceroutes through or customer connections to www.yahoo.com, while other like www.msn.com and http://home.netscape.com come in just fine. Is it www.yahoo.com, maybe? Just wondering, as I narrowly veer close to the edge of being on-topic..... :-) Mary Grace

2 1