- NANOG - lists.nanog.org

trawhoisd beta testing
by Xin Liu 20 May '97

20 May '97

ftp://ftp.merit.edu/routing.arbiter/tools/trabeta.tar.gz It needs perl5.003. It works with RtConfig. ---------------------------Liu, Xin------------------------------ Merit Network, Inc Phone: (313)936-2115 (o) http://home.merit.edu/~xliu -----------------------------------------------------------------

1 0

MEETING INFO CORRECTION
by Pam Ciesla 19 May '97

19 May '97

The Nanog Meeting in Tampa at the Hyatt will be held in the Audubon Ballroom, section B thru F. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

Feb 1997 notes are almost complete
by sob＠academ.com 18 May '97

18 May '97

Finally, I have been able to get all the notes (except those concerning the Gigaswitch) on line. I have also been able to get a number of slides on-line, but I don't have all of them. I expect to get the Gigaswitch notes on line later this week. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Emergency backup for a small net
by Hank Nussbacher 18 May '97

18 May '97

At 09:04 AM 5/18/97 -0400, Bradley Dunn wrote: This brings up a problem I have been trying to solve for a while that I have not found an answer to. A company with an old style Class B (/16) wants to be multihomed and split their incoming load between 2 ISPs (outgoing they can live with going via 1 and if the primary fails they fallback to the secondary conenction). In order to split the load on incoming, one ISP has to announce a /17 and the other ISP has to announce a /17 (or even the entire /16). But since this net is from the 147.x.x.x range, various ISPs around the globe will filter out the /17. This means that having a /16 from the 192.x.x.x range is better (these days), unless someone can show me a solution. Thanks, Hank >Hi, > >We have a small ISP customer that wants to run a circuit to another local >ISP and the ISPs would use that pipe only in the case of primary link >failure. The two ISPs would split the cost, etc. > >The obvious solution would be for both ISPs to set up BGP peering with >their upstreams and not announce anything in normal operation. The >upstreams would continue to statically route the smaller ISPs' blocks and >the smaller ISPs would default to their upstreams. The smaller ISPs would >also put in a default pointing at each other with a higher cost. Then in >the case of primary link failure the ISP who still has a path to the net >would begin announcing the other ISP's block(s) to their upstream. The >upstream would in turn see this as a valid announcement and propagate it >to the world. Therefore specificity should draw all the traffic to the >correct place. > >The problem is both ISPs are small and have /24s from their providers. The >/24s would be filtered by many, leading to only partial connectivity in >the case of failure. (Partial connectivity is better than no connectivity, >I guess...) > >Another possible solution I thought of is to use NAT. The small ISPs would >use RFC1918 internally and use a block from their provider to translate >into. When the primary link fails they switch over to using a block from >the other ISP's provider. They would also have to use very low TTLs for >their DNS zones and be prepared to switch the DNS zones to point to the >other block. Does the NIC consider this efficient utilization >to have a block lying around that only gets used when a link fails? > >An important thing to remember here is that the backup link will not be >used in normal operation. This is not multihoming. They do not want load >balancing. > >I would be interested to hear others' thoughts on this. If you reply >privately I will summarize any interesting replies to the list. > >Thanks! > >pbd >-- >You can make it illegal, but you can't make it unpopular. > >

3 2

Mbone help
by Forrest W. Christian 17 May '97

17 May '97

I know that this is slightly off subject so I'll keep it short. Is there a kind person out there who would like to help me with some basic questions about getting a mbone feed set up so I can watch nanog? I have read the FAQ's and the like and I am still a little lost with the whole thing. I understand the basic concepts but putting that into action is a different thing. Thanks, forrestc(a)imach.com P.S. Reply by e-mail. No need wasting additional bandwidth :)

1 0

Re: Yesterdays Spam....
by Dave O'Shea 17 May '97

17 May '97

Curt Howland <howland(a)conxion.com> writes: >I could not imagine anyone stupid enough to spam the NANOG >mailing list, until I did a WHOIS on their return mail domain.... Our friend Sanford must be even less intelligent than I had originally thought. I'm tired of trying to block off one bogus site after another, so last night I denied AS4200 in our core routers. No complaints so far. Shame, though, that all of AGIS's customers have to suffer because of one bad apple.

2 1

Yesterdays Spam....
by Curt Howland 16 May '97

16 May '97

I could not imagine anyone stupid enough to spam the NANOG mailing list, until I did a WHOIS on their return mail domain.... Curt- >From owner-nanog(a)merit.edu Thu May 15 18:29:19 1997 Return-Path: <owner-nanog(a)merit.edu> Received: from merit.edu by asilomar.noc.conxion.net (8.6.12/SMI-4.1) id SAA00293; Thu, 15 May 1997 18:29:18 -0700 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id VAA21968; Thu, 15 May 1997 21:16:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 15 May 1997 21:15:52 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA21944 for nanog-outgoing; Thu, 15 May 1997 21:15:52 -0400 (EDT) Received: from hydrogen.inbe.net (root(a)hydrogen.inbe.net [194.7.1.8]) by merit.edu (8.8.5/8.8.5) with ESMTP id VAA21940 for <nanog(a)merit.net>; Thu, 15 May 1997 21:15:48 -0400 (EDT) >From: a8(a)04194.com Received: from mail.innet.be (1Cust105.Max3.Las-Vegas.NV.MS.UU.NET [153.34.59.233]) by hydrogen.inbe.net (8.8.5/8.8.5) with SMTP id DAA19412; Fri, 16 May 1997 03:10:20 +0200 (MET DST) Date: Thu, 15 May 97 16:58:29 EST To: Friend(a)public.com Subject: New Message-ID: <> Sender: owner-nanog(a)merit.edu Content-Length: 1268 X-Lines: 45 Status: RO > > Below are just two examples of which may be of interest to you. > We honor all request for removal from our mailing list, BUT YOU > MUST type in REMOVE in the subject heading to be removed. > Reply to: a8(a)mary-world.com > System is automated ONLY! All subcribers to any of the following information > MUST type the Subject heading: Subscribe JPA2, or BC1. > > Thank You [snip]

1 0

Re: Questions about Internet Packet Losses
by Curtis Villamizar 16 May '97

16 May '97

Bob, How embarrassing. Please disregard my last message (except the part about leaving us alone, that still applies). I presort my mail and got my inbox-nanog mailbox mixed up with inet/nanog and replied to some old mail. Sorry about that, Curtis

1 0

iSTAR Outage
by Lyndon Nerenberg 16 May '97

16 May '97

Anyone know the cause of iSTAR's network outage in western Canada yesterday? Our ISP (who gets their connectivity through iSTAR) didn't seem to know much about what was happening. The best I could make out was that there was a problem with the link between Calgary and Vancouver. I'm curious about two things: 1) Why didn't the traffic reroute over the Calgary-Toronto pipe, and 2) Can we expect to see more downtime this weekend? Lyndon Nerenberg Sr. Software Developer Server Products

1 0

Re: Who Are The Good Guys?
by Scott Hazen Mueller 15 May '97

15 May '97

>Maybe in this case you were being sharked, but before we got everything >clamped down on our servers we saw a number of spammers who were 'multi- >hopping' their UCE and including faking headers and sending false HELO data. That reminds me, I've seen spammers using SMTP route-addrs, which would create this multi-hop effect through multiple relays. -- Scott Hazen Mueller zorch(a)wenet.net +1 415 281 6550 x269 Vice President Engineering, Whole Earth Networks (Hooked and The Well)

1 0