- NANOG - lists.nanog.org

RE: Rules and Regs for a LEC's and Non LEC's
by McBurnett, Jim 25 Aug '03

25 Aug '03

-RBOCs (note, not ILECs) cannot move inter-lata traffic without being -approved by PUC in each state for "interstate long distance". (I believe -this is part of 1984 MFJ). -CLECs have no restrictions on that. Neither do non-CLEC ISPs. ---alex I thought this only applied to VOICE traffic. AS far as I know Internet access traffic is non-regulated. I used to work at a CLEC and we never worried about PUC complaints on an Internet access level of service. now if the T-1 level was down, that was a different story. -J

3 2

Extreme + Nachi = ipfdb overflow
by Joshua Coombs 25 Aug '03

25 Aug '03

After battling Nachi and it's flood of icmp traffic, I've discovered that it's not the Cisco gear that gets hit hard by it, it was the Extreme gear. Nachi generates enough 'random' traffic to flood and subsequently thrash the ip forwarding DB on the Summit 1i we were using so badly as to drop it from gigabit capible to barely eeking out 6mb/sec. Before I redeploy the switch, I need to find a way to keep the ipfdb from flodding while allowing it to be the primary carrier of traffic. ACLs blocking ICMP on the Extreme act too late, by the time the cpu sees the packet to drop it, it's already horned its way into the ipfdb. Does anyone have any suggestions on ways to allow the switch to participate as an L3 router while minimizing the chances of a worm taking it out so easily again? Joshua Coombs GWI Networking

5 4

exchangecolo 200paul san francisco issues?
by Haesu 25 Aug '03

25 Aug '03

Is anyone aware of any problems/issues with 200 paul ave SFO? -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu(a)towardex.com Cell: (978) 394-2867

6 5

Layer 5+ inspection at the border?
by Rick Ernst 25 Aug '03

25 Aug '03

I'm looking for a beast that is roughly a combination of Cisco NBAR and Foundry URL inspection. NBAR worked pretty well for CodeRed, but I'd rather have a dedicated device rather than overloading a router with non-routing functions. I haven't used Foundry's URL inspection, but it looks reasonable, too. I would, however, like something that can do generic Layer 5+ inspection/alteration so things such as SMTP headers can also be inspected and processed/blocked/altered. I'd prefer a switching device that can replace the switches between my border and core, but allow transparent manipulation of the packets, preferably at wire-speed. Any suggestions? The idea is to have a central location that can watch for and block 'bad payload'. It looks like F5 may have a solution, but I'd like comments and experiences from those that have deployed such a device. Thanks, Rick

1 0

RE: TNT issues "workaround"
by Ejay Hire 25 Aug '03

25 Aug '03

In response to this, I'd like to comment on Lucent's excellent response to this issue. Never before have I seen such an effective application of hear-no-evil, see-no-evil, and speak-no-evil. While other vendors were wasting our time sending out notifications of bugs / vulnerabilities with workarounds / fixes, Lucent's response was much more efficient and eloquent. Here is a summary of the responses I've received over several days phone calls, calling for my current employer who does not have a service contract, and one for one of my consulting customers who does have a service contract. If you have a service contract, I'm allowed to tell you we aren't aware of any issues. If you don't have a service contract, I'm allowed to sell you a service contract. On that note, I might have some TNT's for sale pretty soon. -Ejay -----Original Message----- From: Brian Wallingford [mailto:brian@meganet.net] Sent: Saturday, August 23, 2003 12:41 AM To: nanog(a)merit.edu Subject: TNT issues "workaround" I haven't seen specific details posted here, so: Like many others, we've had a few TNTs online for years without hiccups or reboots until this week. Beginning late Sunday, we saw seemingly random blade reboots, and total system crashes. Errors ranged from memory leaks to infinite loops on the controller blade, but all blades were susceptible. HDLC2 blades seemed to be particularly vulnerable. We saw boxes that had been rock-solid for very long periods suddenly rebooting at periods ranging from 20 minutes to 4 hours, with no obvious cause (i.e., nothing more specific than the above). Border and core filtering of icmp echo * did little good. On the suggestion of some folks on another list, and against my better judgment, we disabled route caching in order to free up additional memory (though memory did not appear fragmented). This stabilized all involved boxes, and surprisingly, did not result in significant degradation of end user performance. Granted, it's not a true fix, but it may get you a few extra Z's at night. hth, brian

3 2

Virus
by Wesley Vaux 25 Aug '03

25 Aug '03

Has anyone noticed that after patching and cleaning machines that they become infected again? Is this just me? What is your process for remove Nachi.worm. Sorry for bringing this back up. Wes Vaux, CCNA, CCDA Network Security Engineer, 9000 Regency Pkwy Ste 500 Cary, NC 27511 t 919.463.6782 f 919.463.1290 Global Knowledge Experts Teaching Experts http://www.globalknowledge.com

1 0

Oh the shame of being lame!
by Rob Thomas 25 Aug '03

25 Aug '03

Hi, NANOGers. Are your DNS zones coming up lame? Why not check the DNS lamer report as you sip your Monday morning coffee? There are 19621 entries in the lamer report for the week ending 24 AUG 2003. These entries are often indicators of greater problems with name server configurations. <http://www.cymru.com/DNS/lame.html> We update this report each week, Sunday evening US CT. On a related note: We want your data! Please consider donating to Team Cymru the lame delegation log entries from your name server logs. We are happy to credit you and your employer, or keep the source anonymous, as you prefer. Such donations help the community at large. Be the first in your ASN to donate data! :) If you are interested in donating data, please contact us at team-cymru at cymru.com. Thanks! Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

RE: FW: TNT issues "workaround"
by John Lord 24 Aug '03

24 Aug '03

Ive been watching mine and finally see this error *Mar 19 14:48:53.951 UTC: %SYS-2-MALLOCFAIL: Memory allocation of 2708 bytes failed from 0x603FE6C0, alignment 0 Pool: Processor Free: 6402796 Cause: Memory fragmentation Alternate Pool: None Free: 0 Cause: No Alternate pool -Process= "ISDN L2 Process", ipl= 0, pid= 94 -Traceback= 603FC690 603FDC90 603FE6C8 60102990 600A84A8 600A8D34 *Mar 19 14:48:54.635 UTC: %SYS-2-CFORKMEM: Process creation of Async tty Reset failed (no memory). -Process= "Serial Background", ipl= 0, pid= 8 -Traceback= 6040D2A4 60414AEC 606B03C4 606B06A0 600704C4 Im doing b) blocking all echo/echo-reply coming in from dial-up users (i.e. apply an input acl to your virtual-template and/or group-async interfaces). But it doesn't seem to stop it from locking up. Ive been killing users as I see users with the worm , This is on a cisco as5300 by the way. Whats the command to disable route cache? John Lord(lord(a)allturbo.com) It Manager AllTurbo Internet Services Inc 410-213-9388 Office www.allturbo.com -----Original Message----- From: jlewis(a)lewis.org [mailto:jlewis@lewis.org] Sent: Saturday, August 23, 2003 6:43 PM To: Ross Chandler Cc: John Lord; nanog(a)merit.edu Subject: Re: FW: TNT issues "workaround" On Sat, 23 Aug 2003, Ross Chandler wrote: > > I seem to be having the same or similar problems with my Cisco boxes > > also , they either reboot or the pris hang , users get busy's but no > > one is logged in at all , when I do a show isdn status it shows b > > channels in use but no one on, the only way to fix is reboot the box > > , and it seems to be timed , everyday at 1400 and 2200 hours , since > > Monday anybody body heard of ciscos acting funny this week? > > Perhaps your fast switching route cache is filling up memory. If > you're willing to risk it enable CEF on all interfaces. Some of the older cisco access-servers don't even support CEF. The cisco failures seem to be memory starvation/fragmentation issues caused by out of control route-cache growth caused by the nachi worm's attempt to ping so many different hosts so quickly while looking for systems to spread to. You can work around the issue by: a) using policy routing to pass all dialup traffic through a route-map that sends 92 byte echo/echo-reply packets to null0. b) blocking all echo/echo-reply coming in from dial-up users (i.e. apply an input acl to your virtual-template and/or group-async interfaces). c) disabling route caching on the egress interface of the access server. I'm doing a mix of a (on the access-servers that this works on) and b where a doesn't work...and tested c this morning and found it appears to work. ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

2 1

Fortune: Peter Lewis reports from the front lines of the worm wars
by Sean Donelan 24 Aug '03

24 Aug '03

Peter Lewis, a writer for Fortune.com (and I believe previously for the New York Times) reviews his week in his Weblog. The East Coast blackout, two disk crashes, a backhoe cuts his phone lines, worm attacks on AOL Time Warner's corporate network, and then the worm gets him (or rather his computer). http://www.fortune.com/fortune/ontech/0,15918,477882,00.html The Worm Turns - August 22 2003 > > Did this week suck, or what? > > Perhaps as retribution for my smug comments on the radio last week that > MY house, MY office and MY computer networks were unaffected by the Big > Blackout of 2003, the technology banshees came visiting Monday morning. [...]

1 0

XO as Backbone provider - try again
by Bil Herd 24 Aug '03

24 Aug '03

Sorry for the HTML post (boo, hiss) Anyone have positive or negative experiences with XO as a 'tier1' provider? We are re-evaluating orur backbone connections. Bil Herd - INS

3 2