- NANOG - lists.nanog.org

Cisco IOS Vulnerability
by Larry Diffey 30 Jun '01

30 Jun '01

CERT and Cisco have issued a warning about a vulnerability in the Cisco IOS starting at version 11.3 and affecting all later versions. If your Cisco equipment is HTTP enabled and you're not using TACACS+ or RADIUS for authentication it is vulnerable to complete takeover. The hack is very simple. Please read the Cisco warning and/or the CERT advisory for further information. The warnings were released yesterday. Happy Hacker Stopping. Larry Diffey

3 2

Nasdaq Breaks Down for 2nd Day, Disrupts Trading
by Rishi Singh 30 Jun '01

30 Jun '01

New York, June 29 (Bloomberg) -- The Nasdaq Stock Market broke down for a second straight day, disrupting traders for about 90 minutes this afternoon on one of the busiest days of the year. The No. 2 U.S. stock exchange cancelled its aftermarket session. Complete story here: http://quote.bloomberg.com/fgcgi.cgi?ptitle=Top%20Financial%20News&s1=blk&tp =ad_topright_topfin&refer=topsum&T=markets_bfgcgi_content99.ht&s2=blk&bt=ad_ position1_topfin&middle=ad_frame2_topfin&s=AOz0AhxPxTmFzZGFx

4 3

Re: My apologies to the list
by Sean Donelan 30 Jun '01

30 Jun '01

On Fri, 29 June 2001, Rishi Singh wrote: > I offering a general apology to the entire nanog list. At least one > subscriber found my post about the NASDAQ outage not relevant to the charter > of NANOG. Those that don't remember the past are doomed to repeat it. The fact it was NASDAQ is not very interesting. The fact some error by a network technician disrupted a large, normally reliable is relevant to network operators. Did the network technician have a chance, make a mistake, or was it inherent to the equipment or design? Was the root cause a vulnerability that other network operators may also have in their network. The reason why NRIC and the FCC require telecommunication carriers report errors isn't to punish bad network technicians. But to identify and correct common errors which may exist in multiple carriers. Sticking your head in the sand, and not talking about it doesn't fix anything. If you do not know what went wrong with Worldcom's network, you don't know if your network may be vulnerable to the same thing. Problems in non-Internet networks have later shown up in the same equipment and operations used for the Internet.

1 0

My apologies to the list
by Rishi Singh 29 Jun '01

29 Jun '01

I offering a general apology to the entire nanog list. At least one subscriber found my post about the NASDAQ outage not relevant to the charter of NANOG. I thought it would be quite handy to a few folks who's companies, like mine have network connections directly to NASDAQ stock market along with a multitude of ECNs. I consider NASDAQ a major networked system as well, although not a public ip network, carries quite important information. In addition I am willing to guess that a lot of people on this list work for publicly traded companies who would find the news helpful. -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Friday, June 29, 2001 6:49 PM To: nanog(a)merit.edu Subject: Re: Nasdaq Breaks Down for 2nd Day, Disrupts Trading On Fri, 29 June 2001, Rishi Singh wrote: > New York, June 29 (Bloomberg) -- The Nasdaq Stock Market broke down for a > second straight day, disrupting traders for about 90 minutes this afternoon > on one of the busiest days of the year. The No. 2 U.S. stock exchange > cancelled its aftermarket session. Officials of the computerized stock market said an error by an MCI Worldcom technician led to the problems.

1 0

Re: Nasdaq Breaks Down for 2nd Day, Disrupts Trading
by Sean Donelan 29 Jun '01

29 Jun '01

On Fri, 29 June 2001, Rishi Singh wrote: > New York, June 29 (Bloomberg) -- The Nasdaq Stock Market broke down for a > second straight day, disrupting traders for about 90 minutes this afternoon > on one of the busiest days of the year. The No. 2 U.S. stock exchange > cancelled its aftermarket session. Officials of the computerized stock market said an error by an MCI Worldcom technician led to the problems.

1 0

RE: New NAP Opening in Miami this week
by Sean Donelan 29 Jun '01

29 Jun '01

On Thu, 28 June 2001, "Daniel Golding" wrote: > Very little in Florida is much above sea level, especially in coastal areas. > 32 feet is plenty to avoid flooding, and the building is extremely solid, > and is certainly capable of surviving a storm surge. Of course, the many > structures in between the NAP and the beach would help with that as well. > It's not like the facility is actually on the beach. It's about two blocks > from the Miami Arena. I had equipment co-located in Florida during Hurricane Andrew. I didn't loose connectivity throughout the entire storm. The problem with having the well constructed building, great communications facilities and a backup generator? FEMA took over the building for about three weeks to use as their county emergency operations center. It makes sense, but I didn't think to check if the public library building was also a designated emergency shelter. Building a NAP is much like outrunning a bear, you don't have to be the fastest runner. Just faster than the other guy. It upsets the accountants, but there is not a fixed standard for NAPs. Locating the first NAP in a parking garage may not have been a problem. During its life-time, I never heard of a single problem at MAE-East due to it being located in a parking garage. All the problems could have occurred anywhere it was located. But as other people improved their exchange points, the bar was raised for everyone. As long as all the other NAPs in Florida are lower than 32 feet, it doesn't matter. If not, we'll get to add to the list of underwater "carrier-grade" facilities like Rochelle Park, NJ and East Houston, TX.

1 0

unscientific multi-homing survey: results
by Joe Abley 29 Jun '01

29 Jun '01

Results of my unscientific straw poll for multi-homed operators, as requested by a few people. Some people gave multiple answers to questions, and some didn't answer particular questions at all. Figures in brackets indicate frequency of particular responses. Like I said, unscientific :) Thanks to those who sent me mail. Joe On Tue, Jun 26, 2001 at 09:15:09AM -0400, Joe Abley wrote: > If you currently multi-home between two or more providers using IPv4: > > + why do you do it? What are the high-level goals you are hoping to achieve? > Are you finding that you are achieving them? redundancy (3) load-balancing (2) "shorter paths", performance, better throughput for users (4) geographic redundancy (2) provider redundancy (3) we are achieving these objectives (7) > + how often does your traffic shift between transit providers due to > a failure of some kind triggering a re-homing? a couple of times per day (1) once per week (1) once per month (1) a couple of times per month (2) we don't notice when it shifts (1) rarely (1) once per six months per circuit (1) > + how often do you manually shift traffic, and why? Just inbound traffic? > Or outbound too? never (1) normally never (1) once per month (1) occasionally (1) when we get complaints from specific netblock/asns that we can fix (1) when we need to due to transient heavy traffic loads (e.g. a promotion) (1) rarely (three or four times a year) (1) to rebalance costs after some kind of DoS attack (1) (never) because we are overprovisioned with capacity and traffic shifting isn't necessary (1) to optimise use of various peering links (1) manually setting best paths for various ASes (where BGP doesn't see the best path) (1) to avoid some specific poor connectivity on a short path (1) both inbound and outbound (2) > + what impact does a manual or automatic shift in traffic between providers > have to your users? Do their TCP sessions break? Or do you think they > normally stay alive, maybe after a delay? What makes you think this? people don't normally notice the transition (1) transparent if done right (1) stuff breaks a bit, but most TCP sessions remain up (1) minimal impact (1) for 90% of people the sessions sit for a while and then resume, based on feedback in a support forum (1) there is a several minute delay as the BGP tables across the internal core routers adjust (1) VPN users get kicked out when there is a transition, since we don't have provider-independent space and the addresses associated with the down provider become unreachable (1) most traffic is HTTP which is not really affected as long is there isn't too much flapping (1) assume all drop and take any that don't as a bonus (1) no detectable effect (1) we have never had a ticket opened which resolved to TCP session breakage due to a re-homing transition (1) > + what is *bad* about the way that multi-homing works in IPv4? need more control of incoming traffic (1) hard to limit incoming via upstream, although outgoing preference is easy (1) nothing that needs fixing at layer 3 (1) withdrawing and advertersing routes socks the network too much (1) synchronisation takes too long, and sucks up too much router cpu (1) nothing (1) bgp is unintelligent, and requires too much manual tweaking to find the "best" route (1) finding providers which will let you multi-home is hard (1) needing provider-independent address space (1) it can get ugly (1) router vendors need to make more boxes with more memory (1) i would like to have confidence in using RRs more (1) having to trust and cooperate with your peers (1) bgp convergence sucks (1) > + what is good about it? it works (4) it can be done using lots of devices "besides just cisco" (1) it's pretty obvious how it works, and even level-1 ticket takers at backbone providers understand it most of the time (1) it allows us to increase performance, and we like redundancy (1) "The redundancy! The multiple paths! The ability to choose." (1) reliability and shorter paths (1)

1 0

Re: Akamai Servers: Normal or Weird?
by rs＠seastrom.com 29 Jun '01

29 Jun '01

Have you contacted Akamai about this? ---Rob (not speaking for employer) Chris Rapier <rapier(a)psc.edu> writes: > Is something funny happening with them lately or is it normal to see > 45Mbps of UDP traffic between akamai servers (45Mps peak, average for > the past 24 hours is around 15Mbps. Prior to that it wasn't enough to > show up in our graphs). More information: Our akamai farm is the one > recieving all of the data - its coming into our various akamai hosts on > port 1455. > > I've never looked at this traffic before so I don't know if this is > normal or not. I understand that the servers have to talk to each other > to distribute content but why UDP and why consume so much bandwidth? > > Chris

2 1

Re: Cable Modem [really responsible engineering]
by Fletcher E Kittredge 29 Jun '01

29 Jun '01

On Tue, 26 Jun 2001 09:25:08 -0700 Ted Lemon wrote: > > Also, if the cable/dsl/wireless modem is a router, life > > becomes much simpler as one can just gather the necessary information > > via tracing. However, I am not sure requiring modems to be routers is > > a good thing... > > I think you should sit down and read the DOCSIS specifications > carefully before you say things like this. If implemented correctly, > it actually works, believe it or not. The modem does _not_ have to > be a router in order for it to work. Ted; Thank you so much!! I will set right out to do so! regards, fletcher

2 6

Re: Open Peers at PAIX
by Richard A. Steenbergen 29 Jun '01

29 Jun '01

On Thu, Jun 28, 2001 at 10:38:39PM -0700, Christian Nielsen wrote: > > On Thu, 28 Jun 2001, Pete Ashdown wrote: > > > It was neither a cheap nor an easy proposition for us to get our > > router into PAIX. In fact, its probably the most expensive bandwidth > > I run since the DS3 is way under utilized. The main reason I did it > > was to reduce network distance to major peers. My only wish is that > > peering at all exchanges was more open, as it increases their > > usefulness. Finding another peering point where I can get 20+ willing > > peers like PAIX is a struggle. > > if and when paix links to mae-west-ames, you can get a link to the FDDI > exchange. there is always PBNap and MAE-WEST-ATM (tho I dont know the > costs) Didn't he say he was trying to increase the quality of his connectivity? :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

2 1