- Test - lists.nanog.org

Oh yeah. Pictures.
by Steve Sobol 14 Jan '00

14 Jan '00

http://www.cleveland.com/news/sreports/flood/pages/1.html and if you prefer to read, rather than looking at pictures: http://www.cleveland.com/news/sreports/flood/ -- North Shore Technologies http://NorthShoreTechnologies.net 888.480.4NET Steve Sobol, President, Chief Website Architect and Janitor sjsobol(a)NorthShoreTechnologies.net My opinions DO, in fact, represent the official opinions of North Shore Technologies Corporation, since I own the company. Thanks for asking.

1 0

Re: Selection of Appropriate Local SMTP Relay
by Andrew Bender 13 Jan '00

13 Jan '00

> If you have routing loops in your network, chances are you have bigger > issues to worry about.. Discontiguous networks create a supportability problem, and increase the risk of these very issues. One is not well advised (IMHO) to create such a network without a darn good reason...and this (to me) does not seem to be a Darn Good Reason. > Oh, and the mentioned "stardust" problem will happen whether you > choose to deploy distributed mail/dns/cache servers, or whether you have > a big farm. You'll still need some form of load-balancing in front of > your cluster. That's exactly the point. It is easier to solve this problem (not to mention scale or plan) for a farm or cluster than for servers in each of 270 pops. And easier yet when I use names, rather than the silly "well knowns". Opinions aside, the infrastructure required to support stateful load balancing for these boxes in each of their routing islands is substantially more than most are committing these days... Regards, Mr. Stardust tns-inc.com

1 0

No Op. - Social action in SFO 5/6 February pre-NANOG mtgs.
by Lauren F. Nowlin 13 Jan '00

13 Jan '00

Hi all, Apologies to Randy for the non-operational content here... but of course we hope he joins us out on the Santa Cruz Boardwalk Sunday for bumper cars... should be smashing (gee I sound like Bill Norton!) entertainment. Saturday (5-Feb) afternoon: Paintball - e-mail Bill Norton <wbn(a)equinix.com> for details Saturday evening: Boating for an hour tour of the Bay (bring a jacket) - $10 per person. Meet at the entrance to Pier 39 (yeah, touristy but everyone can get directions to Pier 39) at 5:15 p.m. We want to make sure sunset is out on the water. Folks car-pooling from the Doubletree Hotel San Jose, 2050 Gateway Place, San Jose, CA 95110 should gather around 3:45 / 4 p.m. in the hotel lobby. It is about 50 miles between SJC & SFO and parking in SFO can be tough on the weekends. If you have a car reservation ask for a large vehicle and we'll load-up & caravan to the city. Saturday night (around 7:30 / 8 p.m.): Dinner in San Francisco at Fisherman's Grotto #9 down in the heart of the wharf. Chowder, sourdough & geeking.. I'm going to make a reservation for a party of 20 under the name NANOG. After a lengthy dinner & stroll of the Pier, we should do dessert at Ghiradelli Square (ice-cream sundaes to drool over) around 10 p.m. Clubbing/dancing - Locations TBD (Christian mentioned some 'Gold' club?)... lots of variety in SFO. Sunday: Santa Cruz on the Boardwalk is where we plan to recover the next day <g> http://www.beachboardwalk.com will display a few of the amusements. Rollercoasters run from 11 a.m. to 6 p.m. in February. Bumper cars, salt-water taffy, sand & the usual beachfront stores are all there. This is the boardwalk from the movie _The Lost Boys_ . The ancient arcade has Tron, Ms. Pacman, Centipede, a shooting gallery and of course the latest video games. Woody has the name of a great sushi spot in Santa Cruz (Cathy W. probably does too...) We are going to meet in the hotel lobby at 10:30 and sort out the carpool. Plan to return to the hotel ~3:30. Andrew Khoo insists sushi should be the dinner plan on Sunday night <g> He never gets enough... Anyway, RSVP for the dinner on Saturday night so that I'll have a better guesstimate of 20 or 30 for dinner at the Fisherman's Grotto. Please don't rsvp to the list... Thanks all, -Ren Lauren F. Nowlin, ren(a)onyx.net / peering(a)onyx.net Director, Peering & Interconnects Onyx Networks, Inc., a wholly owned subsidiary of Pacific Gateway Exchange Voice: 650-558-3262, Fax: 650-558-3154, Cellphone: 650-281-6963

1 0

Re: Selection of Appropriate Local SMTP Relay
by Andrew Bender 13 Jan '00

13 Jan '00

Jeff Mcadams <jeffm(a)iglou.com> wrote: > Not necessarily...if you can spread your mail servers out to different > parts of your network, then they're going to have the same IP address > and your dialup ports will "magically" find the closest one. Don't forget to mention that routing loops will never occur, and the aforementioned "stardust" will be mindful of server health, load, etc. Regards, Andrew Bender tns-inc.com

2 1

Fwd: Superior Building
by Derek J. Balling 13 Jan '00

13 Jan '00

>Date: Wed, 12 Jan 2000 19:05:12 -0500 (EST) >From: Steve Sobol <sjsobol(a)apk.net> >To: dredd(a)megacity.org >Posted-To: apk.general >Subject: Superior Building >Organization: North Shore Technologies Corp. 888.480.INET > > >(Cc'd to Derek Bailing: Derek, if you could please post this to NANOG >for me, I'd appreciate it) > >A water main break has led to a loss of building power at the Superior >Building at 815 Superior Avenue in Cleveland. There are a number of >local service providers in the building (including myself, NACS.NET and >Multiverse) and MCI Worldcom and NextLink Ohio also have facilities there. >(I did call my main phone number, which is serviced by NextLink, and I got >voice mail, so my guess is that their switches and other equipment are >still ok. They service the 216-619 prefix. I'm not sure which other >prefixes they handle.) > >Water is still coming into the basement of the building even as I post this >message. There is no ETA for repair.

1 0

NANOG 18 Registration Closed
by Pam Ciesla 12 Jan '00

12 Jan '00

The attendee registration for NANOG 18 has reached the 500 limit. I will have a wait list available, you can be added to this list by sending me e-mail only. NO walkins at the meeting. Registration fee of $300 is due by 1/28/00, the fee goes up to $350 after 1/28. If you are on the attendee list but unable to attend please cancel by contacting me. Thanks Pam Pam Ciesla Events Coordinator Merit Network,Inc. 734-936-0172 - phone 4251 Plymouth Road 734-647-3185 - fax Bldg.I, Suite 2000 pam(a)merit.edu Ann Arbor, MI 48105

1 0

Re: Selection of Appropriate Local SMTP Relay
by Michael Shields 12 Jan '00

12 Jan '00

In article <Pine.BSF.3.96.1000110222525.438A-100000(a)workhorse.iMach.com>, "Forrest W. Christian" <forrestc(a)iMach.com> wrote: > I'm going to make a pitch for the IP-address based method. > > Specifically, if you have a set of well known IP addresses for common > services, thus something like: > > 223.255.255.1 - Primary DNS > 223.255.255.2 - Secondary DNS > 223.255.255.3 - SMTP Mail > 223.255.255.4 - Time Server Why did you choose to have exactly 2 DNS servers and exactly 1 SMTP and "time" server? -- Shields.

3 2

Re: Selection of Appropriate Local SMTP Relay
by Joe Abley 12 Jan '00

12 Jan '00

On Mon, Jan 10, 2000 at 12:16:25PM -0500, Daniel Senie wrote: > Using DNS, as you propose, has some problems. In your example, you rely > on the topology of the network, and make assumptions about classful > structure. This isn't workable in the present network environment. I'm not convinced that I do. It's quite possible to specify a different mail relay for every individual address in an ISP's network. I might be using octet boundaries so that I can follow the same well-known in-addr.arpa zone structure as is currently used, but that's all. It seems to me that handing out mail relays in IPCP and DHCP are also very valid approaches, although they arguably require more software changes to be useful (e.g. in access-server firmware). Here are a couple of points: 1. The use of MX records in the manner I suggested allows the SMTP relays to be used to be changed fairly dynamically -- using IPCP, for example, a caller would only get one set per call (and calls can be pretty long-held; I see calls lasting five days here). 2. The use of MX records also allows backup mail relays to be specified, with an associated priority, in a familiar way. 3. Using a network-layer protocol like PPP or DHCP to collect the data requires some consistent application-layer interface to retrieve the specified nameserver info by client software; this, ideally, would require standardisation across platforms, and practically does not sound trivial. However, there's already a well-defined mechanism in almost every platform for applications to perform DNS queries. Thanks for the feedback, Joe

12 19

Re: Netgate.net.nz/ORBS spam colusion
by Dean Anderson 11 Jan '00

11 Jan '00

After all the bashing, I get to gloat a little. I see the guy in Russia took his model from ORBS, and did exactly the same thing: He apparently used a security exploit to get data, and published that data. So far, it doesn't sound like he made any credit card charges. Sounds like he didn't actually damage the compromised system. According to Derek Balling and a few others, he should be free and clear. According to those few people, the cracker hasn't done anything wrong. According to those same people, CD Universe accepted the consequences of having an insecure server. Anybody could accessed the data. So it must be publicly available information then. He just published some publicly available data. US law doesn't apply to Russians. The fault here is with CD Universe for operating an insecure server. There is no fault with the guy who published the credit cards. He is not responsible if other people misuse that data. Wrong. If it wasn't already clear to reasonable people, it certainly is now. Those people who made those stupid assertions are clearly full of crap. Now what happens to the Russian ISP that refuses to shut down the site? Yep. You guessed it. --Dean Around 05:37 PM 1/10/2000 -0800, rumor has it that Randy Bush said: > >>> And if anything disparaging about the chinese government were to appear on >>> his web site, he could be extradited and put to death! >> Who gets his organs..... > >warning, there may not be a full set > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

4 4

Re: Something very odd on an older 2514 .
by Dean Anderson 11 Jan '00

11 Jan '00

I think you are hitting a performance wall in the 2514. You can't really expect much more than 2 x T1 performance, and then you'll hit a wall. The 2500 series is only a 68040, (old ones are 030's) which "manually" shuffles packets, and can't handle sustained full ether bandwidth. If you look closely with a sniffer, you'd see that its dropping packets. Your FTP slows down because the TCP window is full. --Dean Around 07:46 PM 1/10/2000 -0800, rumor has it that Mr. James W. Laferriere said: > > > Hello All , I've just been doing a few tests on some 2514 routers > I had laying around . I setup the two ether interfaces & on each > like the diagram below > > +--------+ +--------+ > | 2514 |+----------------------+| 2514 | > +--------+ +--------+ > + + > [hub] [hub] > + + > +---------+[ ftp source ] +---------+[ ftp source ] > > I noticed a drastic lessening of expected bandwidth thru the > routers . On the range of seeing only 24-25% of available > ether bandwidth . > But when I plug the two 'ftp source's into the same hub I am > getting a more resonable 66-75% of the available ether bandwidth . > > Has anyone any info on what might be the cause of the lack of > expected thru put . Tia , JimL > > +----------------------------------------------------------------+ > | James W. Laferriere | System Techniques | Give me VMS | > | Network Engineer | 25416 22nd So | Give me Linux | > | babydr(a)baby-dragons.com | DesMoines WA 98198 | only on AXP | > +----------------------------------------------------------------+ > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0