July 2001 - Test - lists.nanog.org

Good Job, White House!
by Alan Clegg 23 Jul '01

23 Jul '01

According to: http://abcnews.go.com/sections/world/DailyNews/militarycyberattack_010723.h… > In recent weeks, variations of the virus are believed to have infected at > least 225,000 business and institutional computer systems. Last Thursday, > infected computers were instructed to flood the White House Web site, but > with minutes to spare the White House was able to protect itself. I'm personally more pleased with the network operators that dealt with the problem. Thanks, Guys! I'm not exactly sure what the White House did. The above web page also confirms that http://*.mil:80 is currently unavailable. I guess the military should contact the White House to see how to go about fixing the problem. AlanC

1 0

Re: Clarification: List of AS names by ASN?
by George Michaelson 23 Jul '01

23 Jul '01

I probably didn't word that last posting well. I don't accuse AS stats people of being spammers, its more that in an operational sense, grazing the whois database for AS information is probably going to look much like grazing the whois database for SPAM information, so our logfile checks may well block this class of access. That, and that there are substantive scaling and policy issues in how we make reliable, trustable, consistent data about AS and other address information accessible to the community when we have a small number of whois servers, all of which may be taking load. I doubt if NANOGers are capable of being suprised by anything, but it suprised me that whois is actually very heavily used. It didn't occur to me that firewall and spamblocking s/w would assume whois was able to answer their questions about where the source of the badstuff was coming from, and that this was automatable. That they ask both the wrong whois server (I hate to think about the load ARIN takes in respect of APNIC and RIPE data) and the wrong questions doesn't help much. In short, whois is a very limited use tool in this context, and automatic grazing of whois to mail back spammers is pretty broken right now and probably for the forseeable future, at least as long as whois data is semi voluntary. I don't see the kinds of trends in Internet governance which can help the data accuracy problem. What we can do is make the service more widely available, replicated, reliable at a machine level. I'm sensitive that APNIC has had more than its share of problems lately. We do realize its not (yet) a HA service, we do realize this is impacting on what people (including NANOGites) want to do. cheers -George -- George Michaelson | APNIC Email: ggm(a)apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net

1 0

Re: Clarification: List of AS names by ASN?
by George Michaelson 23 Jul '01

23 Jul '01

"We live to serve" might be the RIR motto (it should be) but it should be borne in mind: Whois is a centralized service, it has scaling limits and grazers which walk the space are almost certainly going to be presumed to be SPAM robots and ultimately rejected. I think there are many operational and policy issues in respect of whois data, and how its used. Can I suggest that we should talk about this kind of thing as much as "just do it" cheers -George -- George Michaelson | APNIC Email: ggm(a)apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net

1 0

Re: *.mil:80 disconnected in self-defense?
by George William Herbert 23 Jul '01

23 Jul '01

I wrote: >I have a report that .mil disconnected port 80 traffic >from outside hosts, and possibly some other stuff, >in response to DOS attacks last week. >There was some discussion on the inetproviders list this >morning on the topic, and then I asked someone inside >who confirmed the cutoff and said there's a DISA alert >and operational bulletin about it. >It seems to be Just One of Those Months. I've since received a second and third confirmation on this, both of whom want to remain anonymous. -george william herbert gherbert(a)retro.com

1 0

RE: Update: CSX train derailment
by Rowland, Alan D 23 Jul '01

23 Jul '01

It's not uncommon for empty conduit in the ground to accumulate water, sometimes very dirty water. The usual quick fix is some compressed air in one end and all the goop hopefully comes out the other. Be sure to let anyone around the other end know before you turn on the air so they can clear the end of the cable. Imagine Old Faithful as a cold mud bath... :) -Al -----Original Message----- From: David Lesher [mailto:wb8foz@nrk.com] Sent: Saturday, July 21, 2001 6:18 PM To: nanog(a)merit.edu Subject: Re: Update: CSX train derailment I asked a resident who happen to work in the area re: the 30kft temporary fiber run. See <http://www.sunspot.net/news/local/bal-traingridlockmap.graphic> for a map. It must be in a tunnel. I drove right past there today on my way to work and didn't see anything at all. The Sun {newspaper} is on Calvert St. between Center and Orleans. There are no visible aboveground cables (phone, electrical, cable) on Calvert or on Guilford for as far as I can see from the windows right now. There was a later reference to pipes blocked with mud. Do we infer they got permission to run it through storm sewers? In any case, that was fast work by the fiber folks.. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

RE: Update: CSX train derailment
by Rowland, Alan D 23 Jul '01

23 Jul '01

Not to mention almost continuous on-going Corps Of Engineers dredging operations. -Al -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Saturday, July 21, 2001 12:48 PM To: up(a)3.am Cc: nanog(a)merit.edu Subject: RE: Update: CSX train derailment > I would think that if fiber can be run across oceans without using tunnels > or bridges, that it could be run across some rivers much the same way, no? the biggest exposure to cut for wet fiber is shallow water. anchors, idiots, ...

1 0

RE: *.mil:80 disconnected in self-defense?
by Roeland Meyer 23 Jul '01

23 Jul '01

As soon as CERT released info on the IIS exploit, before Code Red, we yanked all our IIS servers down. We are moving those vhosts back to OpenLinux-Apache/FrontPage. > -----Original Message----- > From: George William Herbert [mailto:gherbert@retro.com] > Sent: Monday, July 23, 2001 2:04 PM > To: nanog(a)merit.edu > Cc: gherbert(a)gw.retro.com > Subject: *.mil:80 disconnected in self-defense? > > > > > I have a report that .mil disconnected port 80 traffic > from outside hosts, and possibly some other stuff, > in response to DOS attacks last week. > > There was some discussion on the inetproviders list this > morning on the topic, and then I asked someone inside > who confirmed the cutoff and said there's a DISA alert > and operational bulletin about it. > > It seems to be Just One of Those Months. > > > -george william herbert > gherbert(a)retro.com >

1 0

*.mil:80 disconnected in self-defense?
by George William Herbert 23 Jul '01

23 Jul '01

I have a report that .mil disconnected port 80 traffic from outside hosts, and possibly some other stuff, in response to DOS attacks last week. There was some discussion on the inetproviders list this morning on the topic, and then I asked someone inside who confirmed the cutoff and said there's a DISA alert and operational bulletin about it. It seems to be Just One of Those Months. -george william herbert gherbert(a)retro.com

2 1

RE: Netflow bug on 3-GE cards (Trident) in Cisco GSRs
by David Sinn 23 Jul '01

23 Jul '01

I'm sorry, but ACL's are support on E0's and E1's. Who ever told you otherwise is incorrect. I worked on numerous accounts while at Cisco, and have multiple deployments at my new employers where ACL's are implemented on E1 8-port FE, E1 1-port GE, E0 1-port ATM OC12, E1 12-port DS3's, plus many others. This includes GSR's running 12.0(6)S, 12.0(9)S, 12.0(14)S, 12.0(16)S, and 12.0(17)S1 (plus numerous images in-between that I can't remember). Are you confusing the limitation that the ACL's must be inbound and not outbound? Another words when you went to migrate your 7500's config, which probably followed prior recommendation outbound ACL's, it failed? Because of the design of the GSR, all ACL's are actually process on the inbound interface, regardless of how you define the ACL's (this will change with the E3 and E4+ based cards), and given certain versions of IOS you can define outbound ACL's that the router translates into inbound ACL's for you (again with further limitations). This is highly looked down upon by the TAC. I also do not believe that they are planning a 10 port GE card based on the E3. It is also a 2.5 Gig engine, so you would have massive over subscription would that turn out to be the case. E4's are the 10Gig engine, and there are various ones underdevelopment, but you should talk to your account team about the status of them. David -----Original Message----- From: Andrew C. Ohnstad [mailto:andrewo@gblx.net] Sent: Monday, July 23, 2001 11:12 AM To: David Sinn Cc: Mikael Abrahamsson; nanog(a)merit.org Subject: Re: Netflow bug on 3-GE cards (Trident) in Cisco GSRs On Mon, Jul 23, 2001 at 10:42:26AM -0700, David Sinn wrote: > I beg to differ. > > As a former employee of Cisco, you comments about ACL's on E0 and E1 > cards are totally off base. I'm not sure where you got this > "information", but it is most certainly not the case. > > Standard ACL's & Extended ACL's have been supported by the E0's and E1's > that were released in 12.0(5)S (most) and 12.0(6)S (2 port OC-12 DPT) > versions of IOS. This includes the 8 port FE and 1 port GE cards. This > includes support by the development organization that oversees software > on the GSR, and by the TAC. (Whether the TAC engineer is capable of > supporting you is another issue.) I apologize, I made a couple mistakes in my response. ACLs are not supported on E0 and E1 Gig/FE cards. You used to be able to do them anyways, but they didn't work. They were removed in recient releases. They will be supported by (and re-enabled on) the Engine3 10 port GigE cards under development. We found this out the hard way when we upgraded a pair of GSR with GigE "DMZ" type interfaces behind it. We had to scramble to install a 7xxx series routers to serve as dedicated DMZ routers and do the ACLs on them. -- =-=andrewo

1 0

RE: Netflow bug on 3-GE cards (Trident) in Cisco GSRs
by David Sinn 23 Jul '01

23 Jul '01

I beg to differ. As a former employee of Cisco, you comments about ACL's on E0 and E1 cards are totally off base. I'm not sure where you got this "information", but it is most certainly not the case. Standard ACL's & Extended ACL's have been supported by the E0's and E1's that were released in 12.0(5)S (most) and 12.0(6)S (2 port OC-12 DPT) versions of IOS. This includes the 8 port FE and 1 port GE cards. This includes support by the development organization that oversees software on the GSR, and by the TAC. (Whether the TAC engineer is capable of supporting you is another issue.) Turbo ACL's were added in 12.0(6)S for all E0 and E1 cards that were out at the time. One correct point in your statement is that newer rev's of software are better at not allowing you to implement ACL's on interfaces that the hardware/software doesn't support. This includes ACL's, NetFlow, CAR, and others. Further there is no E2 based 10xGIGE card. The E2 is only a 2.5Gig engine, so you can at MOST run 1/4 line rate, and they aren't that crazy. Did you mean the E4/E4+ based cards that are in development? David -----Original Message----- From: Andrew C. Ohnstad [mailto:andrewo@gblx.net] Sent: Monday, July 23, 2001 7:20 AM To: Mikael Abrahamsson Cc: nanog(a)merit.org Subject: Re: Netflow bug on 3-GE cards (Trident) in Cisco GSRs On Sat, Jul 21, 2001 at 09:37:36AM +0200, Mikael Abrahamsson wrote: > > On Fri, 20 Jul 2001, Dani Roisman wrote: > > > Turns out you can only run netflow on the first port of a 3-GigE port > > on the current S-tract software rev. If you have been struggling with > > this as well, I'm eager to hear about it off-list. > > In 12.0.15S you cannot use access-lists on subinterface on the 3GE either. > Wonder if that's a software bug too, or hardware limitation (like the MTU > difference on the 3GE compared to the 1GE). Actually Cisco has never supported ACLs on Engine 0 or Engine 1 cards in the GSR. Used to be that you could apply those ACLs, but they were implemented by the router very erratically. Cisco finally removed the ability to apply ACLs to an ineligible interface because the TAC was tired of telling people "it's not supported, even though it's there." Best wait another 6 months for the Engine 2 10xGIGE card which will support ACLs, or change to/add something from the 7xxx platform. DownReving the router isn't really an option, like I said because the ACLs never really worked right anyway. I don't remember the exact details (I can get them if anyone wants) but I believe it did something like arbitrarily testing random packets with random rules, whereas some packets would get thru without being checked at all. -- =-=andrewo

3 2