Another tack might be to check out www.cert.org. Look at:
http://www.cert.org/advisories/CA-2001-11.html
It leads to a discussion of a vulnerability on Solaris boxes. Some hackers
have compromised Sun boxes then used them as a platform to attack other
computers.
Paul; Thanks for the heads up on Sun NIC cards.
> -----Original Message-----
> From: Paul Werner [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, August 25, 2001 12:40 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Re: Subject: Re: sh arp [7:17012]
>
>
> Teresa,
>
> Comments within and below.
>
>
>
> ________________________________________________
> Get your own "800" number
> Voicemail, fax, email, and a lot more
> http://www.ureach.com/reg/tag
>
>
> ---- On Sat, 25 Aug 2001, Teresa Presutto ([EMAIL PROTECTED]) wrote:
>
> > Paul,
> >
> > in my humble opinion have a new router doesn't resolve the
> problem. I =
> > didn't create a RMA case: I will create it when and if the
> problem will
> > =
> > appear.
>
> That is music to my ears. It is gratifying to know that there
> are still folks out there who are willing to do some serious
> troubleshooting before going through equipment replacement. In
> one of my former lives, I had technicians that worked for me
> repairing helicopters. Instead of doing any serious
> troubleshooting with engine malfunctions, their first reaction
> was to replace a million dollar engine - because they could.
>
> > In this week I opened two cases for the same problem: "high
> CPU =
> > utilizazion".
> > I had 4000 nat transaltion in few seconds. From the "sh ip
> nat =
> > translation" I was in able to see every source/destination
> IP address.
> > The workaround suggested by Cisco was to configure some
> static route for
> > =
> > these hosts to the Null0 interface.
>
> So you essentially dumped these packets into the bit bucket.
> Were these valid hosts on your network and should they have
> been using NAT to connect to the outside world? Was there a
> pattern to indicate whether a particular host or hosts were
> sending an inordinate number of packets for translation? Was
> this mainly coming from the Sun box you mentioned below?
>
> > This time the situation is different.
> > I have high CPU utilization but normal nat translations: and
> the IP =
> > input process is low.
> > Cisco doesn't think it is an attack or a code red.
>
> In a "show proc cpu", what was listed as the CPU hog, or was it
> not shown? Was the CPU getting hammered from all the interrupts
> caused by the SUN box?
>
> > I gave to Cisco the telnet access on my router:
> > -we upgraded IOS to 12.2 (3)
> > -we reset all the universe
>
> I love that expression. I will use it in the future when I
> need drastic action:-) It will work like this, "we tried
> everything, we changed out all the cards, and reseated all the
> modules, but to no avail... as a last ditch effort, we reset
> all the universe. Voila, it worked!" That's a great one!
>
> > and at the end they suggested to create a RMA case.
> >
> > Connected to this router I have a switch Lucent Cajun P333
> 24x4 UTP =
> > port 10/100 (92 port busy and only 4 available...)
> > I checked all the ports and (Murphy's Law) at the end (port
> 90) I =
> > found the "killer".
>
> Mr Murphy is as dependable as the day is long 8-)
>
> Now on the matter of this Solaris box, what exactly was the
> problem? Was it a screaming NIC spitting out malformed frames,
> or was it doing something else bad? In one of the networks
> that I manage, we have about 15-20 Sun/Solaris boxes. Some of
> the older NICs in some of the older boxes are very
> temperamental. If you set them to auto, they are not happy,
> If you set them to 100/full, they are not happy. If you set
> them to 100/half they are not happy. They are just unhappy
> little NICs. It seems that the best combination we achieved
> was hard coding the NICs to 100/half and doing the same on the
> CAT 3548XL. That produces the least amount of errors.
>
> > I removed this host (Sun Enterprise 220R / Solaris 2.6) and
> the =
> > situation has experienced a noticeble improvement (10% cpu =
> > utilization).
> > In networking matter I do not believe to the coincidences.
>
> Well, sometimes there are new bugs in code. It is regrettable
> that anybody in the field should have to discover them, but it
> happens. As a rule, I agree. Detailed and systematic
> troubleshooting will ultimately ferret out the culprit every
> time.
>
> > By the way the case is still open.
>
> Is it still open because it is unresolved, or you just want to
> monitor the router for a while to see that the situation has
> improved? I would be interested in your opinion of the 12.2(3)
> code. I downloaded it last night to test it out and the router
> would not stay booted. It crashed as soon as it got to the
> point of reading the startup-config. When I reset the config
> register to 0x2142 believing I had some part of my config
> causing a reload, it still crashed. I then decided to migrate
> it over to a router that had 16/2 RAM versus 14/2 for my other
> devices. It then booted normally. Although all of my 2500
> routers have 16MB RAM, most of them borrow 2MB for I/O
> operations. 12.2(3) code refused to run unless there was 16MB
> RAM *total* available(minus any allocated to I/O). I did find
> lots of bells and whistles in there.
>
> If you haven't already done so, you may want to add the NBAR
> entries for code Red since you now have 12.2(3) code(if you
> haven't already done so).
>
> v/r,
>
> Paul Werner
>
>
> > ----- Original Message -----=20
> > From: Paul Werner=20
> > To: [EMAIL PROTECTED]=20
> > Sent: Saturday, August 25, 2001 3:17 AM
> > Subject: Re: Re: Subject: Re: sh arp [7:17012]
> >
> >
> > Teresa,
> >
> > You can't argue with getting a new router :-) I would
> call=20
> > that a giant leap in the direction of problem resolution.
> >
> > If you are able to get a new router and the same
> conditions=20
> > appear to exist, then additional troubleshooting may be=20
> > required. If it is in fact some form of a hacking attack,=20
> > having a sniffer available will aid in discovering the
> nature=20
> > and severity of the hacking attack. Besides, it never
> hurts to=20
> > have a sniffer handy for general network troubleshooting
> and=20
> > analysis. BTW, make sure you document the IOS you have in
> the=20
> > router before it ships and don't forget to save your config
> to=20
> > a TFTP server and erase it from the router prior to
> shipping.=20
> >
> > Best of luck with the new router and let us know if the
> problem=20
> > got resolved.
> >
> > v/r,
> >
> > Paul Werner
> >
> > From my very poor Italian translation:)=20
> >
> > Avete una buona fine settimana!
> >
> >
> >
> >
> > ________________________________________________
> > Get your own "800" number
> > Voicemail, fax, email, and a lot more
> > http://www.ureach.com/reg/tag
> >
> >
> > ---- On Fri, 24 Aug 2001, Teresa Presutto ([EMAIL PROTECTED])
> wrote:
> >
> > > Paul,
> > >=20
> > > to be honest Cisco suggested to create a RMA case ( a
> new=20
> > router in 4 =3D
> > > hours).
> > >=20
> > > I know that could be a form of hacking attack and I'm=20
> > downloading the =3D
> > > sniffer you provided me.
> > > Thank you and have a goodnight,
> > >=20
> > > Teresa
> Report misconduct
> and Nondisclosure violations to [EMAIL PROTECTED]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=17275&t=17012
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
