September 2003 - Test - lists.nanog.org

157.112.0.0/16 ARIN info updated, AT&T still announcing /16
by Kai Schlichting 11 Sep '03

11 Sep '03

>From the [Hijacked] list: > The ARIN information has been updated to have up-to-date contact info for > the original owner, the original owners' ISP is announcing 4 /18s but AT&T > is still announcing 157.112.0.0/16. Can whoever's been bugging AT&T to stop > announcing it to bug them some more? abuse(a)att.net seems to be a dead horse - demands from numerous parties, including the owner of this /16 (the true source of records is JPNIC: whois -h whois.nic.ad.jp "157.112.0.0 /e" , ARIN has not proceeded with 'early registration' transfer of this group of records to JPNIC, it seems) that have been mailed there and to various other @att.net addresses, including their so-called "legal demands center" (that is reportedly hard to reach via email) have been summarily ignored, and we mean "/dev/null'd". AT&T, for lack of presenting any TRO forcing them to keep routing this, appears to willingly conspire with the Empire Towers IP space hijackers while presented with overwhelming evidence that whatever forged documents Empire Towers and Thomas Cowles may have presented to them are indeed that - forged. ARIN zapping the legacy record for this block apparently isn't convincing enough for them to stop announcing this route. The ISP for Systems Clipper Inc. (AS 23720) had started announcing a competing /16 almost 2 weeks ago, but for reasons obvious to nearly all members of this list, that of course wasn't good enough: it's four /18's now, and AT&T should be seeing none of the traffic just about now. If you are peering with AS 7018, a nicely worded email to your peering contacts expressing your concern with AT&T's non-existent cooperation in IP space hijacking cases would be appreciated. Thank you. bye,Kai ps: and this says nothing about the amount and nature of actual abuse that's been reported from this /16 while it originated from AS 7018.

6 5

ISS X-Force MS03-039 Free Scanner
by Ingevaldson, Dan (ISS Atlanta) 11 Sep '03

11 Sep '03

Please see our X-Force Alert for more information about the new set of MSRPC issues. We have published a free CLI tool to scan for computers vulnerable to MS03-039. X-Force Alert: http://xforce.iss.net/xforce/alerts/id/152 Free Scanner: http://www.iss.net/support/product_utilities/Xfrpcss.php Regards, =============================== Daniel Ingevaldson Engineering Manager, X-Force R&D dsi(a)iss.net 404-236-3160 Internet Security Systems, Inc. The Power to Protect http://www.iss.net ===============================

1 0

Migrating DSL Agg from Redback to Cisco
by Nick A Montante 11 Sep '03

11 Sep '03

Hello all- We are trying to move all of our DSL aggregation off of a Redback SMS1000 to a Cisco 7513. We are using the PA-A3-T3 card on the Cisco to talk to our DSL subscribers. We are currently running rfc1483 routed and bridged customers on the same ATM DS3 on the Redback. We're trying to figure out how to convert the config from the Redback to a Cisco config with no luck as of yet. Does anyone have a sample Cisco config for rfc1483 routed and bridged subs? TIA

1 0

RE: Cisco IOS Failure due to Virus
by Niaz, Wajahat 11 Sep '03

11 Sep '03

Try using only CEF. I have seen similar problems in the past using dcef -----Original Message----- From: Richard J.Sears [mailto:rsears@adnc.com] Sent: Thursday, September 11, 2003 12:26 AM To: Robert Blayzor Cc: Nanog Subject: Re: Cisco IOS Failure due to Virus Hi Robert, Thanks for the info. We are running dCEF...routers show about 4% CPU load and the following memory: BR02#sh mem Head Total(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 613AE340 247798976 106515996 141282980 140653360 134546752 Fast 6138E340 131080 37240 93840 93840 93788 Also, we are not blocking 92 byte ICMP due to the traceroute problems on customers networks... Thanks On Wed, 10 Sep 2003 23:17:01 -0400 Robert Blayzor <rblayzor(a)inoc.net> wrote: > > On 9/10/03 10:58 PM, "Richard J.Sears" <rsears(a)adnc.com> wrote: > > > %SYS-2-MALLOCFAIL: Memory allocation of 704 bytes failed from > > 0x60329F00, alignment 0 > > Pool: Processor Free: 92744 Cause: Memory fragmentation > > Alternate Pool: None Free: 0 Cause: No Alternate pool > > -Process= "Pool Manager", ipl= 0, pid= 6 > > -Traceback= 6038049C 60382200 60329F08 6038DEDC > > > > %TCP-6-NOBUFF: TTY0, no buffer available > > -Process= "BGP Router", ipl= 0, pid= 132 > > > > %% Low on memory; try again later > > Did you enable CEF? > Are you dropping 92 byte ICMP packets where needed? > > -- > Robert Blayzor, BOFH > INOC, LLC > rblayzor(a)inoc.net > PGP: http://www.inoc.net/~dev/ > Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 > > "I don't need parents. All I need is a recording that says, 'Go play > outside!" - Calvin and Hobbes > ****************************************** Richard J. Sears Vice President American Digital Network ---------------------------------------------------- rsears(a)adnc.com http://www.adnc.com ---------------------------------------------------- 858.576.4272 - Phone 858.427.2401 - Fax ---------------------------------------------------- I fly because it releases my mind from the tyranny of petty things . . "Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching."

1 0

Re: Max TNT ping thing
by Andy Walden 10 Sep '03

10 Sep '03

Drew, I believe this was the last message about it. Basically, put on all of your filters on all interfaces for both worms, play with the cache as indicated below and make sure you are running later code. At least 9.0.0.9 if I recall if not TAOS 10+. andy -- PGP Key Available at http://www.tigerteam.net/andy/pgp On Sat, 30 Aug 2003, Edward Murphy wrote: > Geo. said: > > > Tonight we either made to double checked the following parameters and the > > > problem seems to have cleared up: > > > > > > iproute-cache-enable = yes > > > ipport-cache-enable = yes > > > suppress-host-routes = no > > > iproute-cache-size = 1500 > > > ignore-icmp-redirects = yes > > > icmp-reply-directed-bcast = no > > > send-icmp-dest-unreachable = no > > > tcp-syn-flood-protect = yes > > > > I just checked and we had: > > > > iproute-cache-size = 50 > > send-icmp-dest-unreachable = yes > > tcp-syn-flood-protect = no > > > > and our box has been staying up just fine. I just modified the last two in > > order to see if that does anything different. the iproute-cache-size of 50 I > > decided to leave alone because I figure that depends on how much memory you > > have and I don't know how your box compares to ours in that respect.

1 0

TnT ethernet card fix?
by Drew Weaver 10 Sep '03

10 Sep '03

Anyone ever come up with a solution for the performance/reliability issues with the TNT without having to buy a new Ethernet card? Thanks, -Drew

3 2

SoBig volume way down
by up＠3.am 10 Sep '03

10 Sep '03

the volume of SoBig virii hitting our mail server had gotten so big that I had to have a cron job delete the quarantine every hour. We were averaging about 400 of them per hour until around midnight last night, where the volume went to and remains about 1/10th of that. Did this thing expire (in which case, roughly 10% of all infected machines have misconfigured clocks, assuming the exp date was in UDT), or did something else happen? Just curious... James Smallacombe PlantageNet, Inc. CEO and Janitor up(a)3.am http://3.am =========================================================================

3 2

ISS Security Brief: Multiple Vulnerabilities in Microsoft RPC Service
by Ingevaldson, Dan (ISS Atlanta) 10 Sep '03

10 Sep '03

FYI, http://xforce.iss.net/xforce/alerts/id/152 Regards, =============================== Daniel Ingevaldson Engineering Manager, X-Force R&D dsi(a)iss.net 404-236-3160 Internet Security Systems, Inc. The Power to Protect http://www.iss.net ===============================

1 0

RE: SoBig volume way down
by Vachon, Scott 10 Sep '03

10 Sep '03

>Did this thing >expire (in which case, roughly 10% of all infected machines have >misconfigured clocks, assuming the exp date was in UDT), or did something >else happen? Just curious... According to sarc.com: The worm de-activates on September 10, 2003. The last day on which the worm will spread is September 9, 2003. Disclaimer : My own 2 cents..any further tags auto generated... Learn more about Paymentech's payment processing services at www.paymentech.com THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer.

1 0

RE: cef/process switching problem
by Michel Py 10 Sep '03

10 Sep '03

> Jay Austad wrote: > I've got a cisco MC3810 with a bunch of DSL customers on it. > CEF is enabled, but when I do a show int stat, I see that almost > 100% of the outbound packets on the ethernet interface are > process switched, and not being matched in the route cache. > The Input looks just fine, and the other interfaces are > borderline (usually 50% hit rate on the cache or a little > less). > CPU is sitting pretty high on this box during the day, and I > have strong suspicions that this is why. :) > I can't seem to find any info on why this would be happening > or how to figure out what's going on. Anyone have any > suggestions? I just troubleshoot something similar on a 7500 and it turned out that the culprit was the "traffic-shape rate" interface command. Using "rate-limit output" instead solved it. Whether or not this is your issue, it's likely to be an interface-level setting on the egress Ethernet interface. Michel.

1 0