- Test - lists.nanog.org

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

AS discovery tools / CAIDA
by curtis l owings 11 Jan '00

11 Jan '00

A while back I saw a demo of an applet that would display AS number as they connect to each other and a color indication of the number of route flaps within each AS. But, of course, my memory is too poor to remember which NANOG conference it was or what the name of the tool was. I'm specifically looking for a tool that will show an AS and what other networks connect to it (I don't really care about route flaps). I've done a quick scan of the NANOG site and CAIDA, but didn't find it. ____________________________________________ Curtis Owings phone: 913-534-2322 Sprint Broadband cell: 913-706-6157 BSC Engineer page: 1-800-724-3508 OP, KS <clowings(a)sprintparanet.com> ____________________________________________ "Your enemy is not evil in his own mind."

6 6

Read an email, lose your privacy
by Henry R. Linneweh 11 Jan '00

11 Jan '00

http://www.sunworld.com/sunworldonline/swol-01-2000/swol-01-silicon.html -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

3 2

Re: Selection of Appropriate Local SMTP Relay
by Sean Donelan 11 Jan '00

11 Jan '00

On Mon, 10 January 2000, "Forrest W. Christian" wrote: > Remember, that the purpose of this is for someone to be able to find the > "correct" server to provide the services which a roaming user will find at > different locations depending on where they are dialing in, thus, a > config for a user would be: > > DNS Servers - varies by location > SMTP server - varies by location > pop3/imap server - always home isp > time server - varies by location > > etc.... > > Thus the table would only list those services which should vary based on > where the user is dialing in/connecting. I disagree. You are making the assumption that servers are identical except for location, or that "local" users are always allowed to use the servers.

1 0