- NANOG - lists.nanog.org

New and improved Traceroute
by Ehud Gavron 21 Jul '95

21 Jul '95

Steffen Baur identified a long-standing bug in traceroute that causes it to appear to hang on non-returned packets on hosts which received lots of ICMP traffic. This fix, as well as some ANSI stuff to make it work on SunOS, Ultrix, BSDI, (and of course, VMS), have now been integrated. ftp.aces.com, cd [.software.traceroute], mget *.*, there's a 0_readme.txt and traceroute.c. This pretty much completes any of the major fixes I'd planned to do for this quarter, so unless someone comes up with anything revolutionary to put in, I won't post another comment for a while... Ehud gavron(a)aces.com

1 0

RIPE automatic inaddr-arpa checking tool available
by RIPE NCC IN-ADDR. ARPA Role Account 21 Jul '95

21 Jul '95

Dear all, After many requests I have published the inaddr-arpa checking tool I developed at the RIPE NCC. We use it now at RIPE NCC quite for some time and it really saves us a lot of time, although the program is not perfect and still needs some polishing. Beware of changing/adapting the tool too much since I expect to make some big changes in the output format to facilitate further automatic processing. Furthermore, I want to split it in some smaller files and a config file for better maintainability. Of course comments and bug reports are welcome. Please read the included README file for more details. Kind regards, David Kessens RIPE NCC PS I am on vacation during the next two weeks, but I will certainly deal with any comments/bug reports when I return! -------- README for the inaddrtool v0.1 Date: 950719 Author: David Kessens, RIPE NCC NOTE: THE TOOL HAS BEEN MADE PUBLICLY AVAILABLE BECAUSE OF THE LARGE NUMBER OF REQUESTS OF OUR CUSTOMERS TO DO SO. THE TOOL ITSELF HAS PROVEN IT'S USEFULNESS, BUT NOTE THE FACT THAT I EXPECT TO MAKE SOME BIG CHANGES BEFORE RELEASING A FINAL VERSION. ALSO SOME ADD-ON PROGRAMS THAT WILL MAKE IT POSSIBLE TO ADD THE REVERSE DELEGATION CHANGES/REQUESTS AUTOMATICALLY TO (Y)OUR ZONEFILES ARE STILL MISSING. THE PROGRAM IS DESIGNED AS SITE INDEPENT AS POSSIBLE. PLEASE USE THE NORMAL PROCEDURE AS DESCRIBED IN RIPE-105 IF YOU WANT TO DO A REVERSE DELEGATION REQUEST FOR A REVERSE DOMAIN MANAGED BY THE RIPE NCC, BUT SEND YOUR REQUEST TO <AUTO-INADDR(a)RIPE.NET> INSTEAD OF <HOSTMASTER(a)RIPE.NET> Reverse delegation tool (Alpha version!) ---------------------------------------- As of today the RIPE NCC offers an automated method for the submission of reverse zone delegations in 193.in-addr.arpa and 194.in-addr.arpa. The reverse delegation requests and the zone files on all nameservers will be checked automatically. The diagnostics generated by these checks will be returned to you automatically too. This will make you aware of any problems very quickly, so that you can correct them and re-submit your request. The most recent version of the tool is now publicly available at: ftp://ftp.ripe.net/tools/inaddrtool0.1.tar.gz The tool uses some other external programs for gathering the information it needs for checking your zone files: ftp://ftp.ripe.net/tools/ping.tar.Z ftp://ftp.ripe.net/tools/dns/host.tar.Z ftp://ftp.ripe.net/pride/tools/prtraceroute-2.0beta3.shar.gz Installing the software: - uncompress/unzip and untar the tool and the external programs - edit the variables in the source code (if needed): $TESTMODE=1 for testing, 0 for normal use $UPDLOGDIR="Directory for logging the incoming requests"; $ACKLOGDIR="Directory for logging the outgoing acknowledgements"; $FWLOGDIR="Directory for logging the outgoing approved requests"; $MSGQUEUEDIR="Directory for temporarily storing the requests"; $NSNAME="The name of your nameserver"; $NAMESERVERCHECK=; see for details the source code $MAILCMD=; see for details the source code $NICECMD="Your nice program if you want" else use ""; $HUMANMAIL="The E-mail address of the human processing the approved requests and answering questions. When $TESTMODE=1, all mail will be send to this address"; $AUTOMAIL="The E-mail address of the mail box that will auto process incoming requests"; - Put something like: "|/home/user/bin/inaddrtool 2>/dev/null" in the .forward file of user $AUTOMAIL Note: there is *NO* queuing mechanism yet, so beware of overloading your machine with a large number of requests. The input: The tool expects to read an E-mail message from standard input although there is no problem when using it stand-alone. The E-mail message should contain a valid RIPE database object as described in the ripe-105 (ftp://ftp.ripe.net/ripe/docs/ripe-105) procedure. When the automated procedure does not detect any errors, the request is forwarded to the $HUMANMAIL role account person for some additional manual checks and the processing of the delegation itself. An acknowledgement of this fact is also sent to the people mentioned in the From:/Reply-To: and Cc: field in the E-mail message. The tool will return an error report if errors are found. If $TESTMODE=1 all mail will be send to $HUMANMAIL. You can use some keywords in the 'Subject:' line of your E-mail to control the checking process. The use of the LONGACK keyword is very recommended. HELP - will send you a (patched) ripe-105 document CHANGE - is needed if you want to change an existing reverse delegation LONGACK - will give you the most verbose output as possible TEST - do the checks, but sent only a report back to the user even if no errors are found You also might want to use the special variable NSNAME that's documented in the source code itself (for experts only). RIPE document ripe-105 requires you to send in a RIPE database 'inetnum' object with a 'rev-srv' attribute for each nameserver for single/multiple C's reverse delegation requests and for whole blocks 'domain' objects with 'nserver' attributes for each nameserver. I am neither a DNS expert or native English writer ;-) so all your comments are welcome! Please send them together with complaints, bug reports or special requests to <inaddr(a)ripe.net>.

1 0

Re: Internic procedure problems
by Geoff Huston 21 Jul '95

21 Jul '95

That last null message from me was fat finger syndrome - sorry 'bout that. I was just noting that there is a WEB page which deals in in-addr delegations at http://aunic.net/aunic/inaddr-template.html The procedure does not email the SOA with the delegation details unless the listed nameservers are a) visible b) functioning and c) consistent. It would be trivial to modify this form to handle generic domain names rather than the special case of in-addr.arpa domain names. Geoff >From list-admin(a)merit.edu Fri Jul 21 08:32:34 1995 >From: Geoff Huston <G.Huston(a)aarnet.edu.au> >Subject: Re: Internic procedure problems >To: markk(a)internic.net (Mark Kosters) >Date: Fri, 21 Jul 1995 07:31:46 +1000 (EST) >Cc: kozowski(a)structured.net, nanog(a)merit.edu > >> >> Its coming - now that the new domain templates are getting to be a larger >> and larger percentage of the total daily domain intake. >> >> Mark >> > >> > >Another thing that would be nice to see is some method for updating domain >> > >information similar to the way routing policy is updated. If I wish to >> > >change secondary nameservers, I should be able to directly update records >> > >for my domain rather than submit an email request and wait 3-4 weeks for >> > >an overworked human being to get around to it. >> > >> > Somthing along the lines of the auto-dbm for the RADB would be great for >> > domain name chages, etc. Just my $.02. >> >> -- >> >> Mark Kosters markk(a)internic.net +1 703 742 4795 >> Software Engineer InterNIC Registration Services >> >> > > >

2 1

Re: Internic procedure problems
by Eric Kozowski 20 Jul '95

20 Jul '95

>Another thing that would be nice to see is some method for updating domain >information similar to the way routing policy is updated. If I wish to >change secondary nameservers, I should be able to directly update records >for my domain rather than submit an email request and wait 3-4 weeks for >an overworked human being to get around to it. Somthing along the lines of the auto-dbm for the RADB would be great for domain name chages, etc. Just my $.02. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS3

4 3

Mae-East instability
by Curtis Villamizar 20 Jul '95

20 Jul '95

Some of our peers have been dropping BGP a bit more often lately. Somebody had a real bad day on Tuesday. Jul.18: 192.41.177.252 1:35:13 mae-east-rt2.es.net Jul.18: 192.41.177.125 1:23:29 mae-east.nsn.nasa.gov Jul.18: 192.41.177.251 0:59:05 mae-east-rt1.es.net Jul.18: 192.41.177.241 0:08:56 sl-mae-e-F0/0.sprintlink.net Here's a list giving the number of disconnects (where there were 5 or more disonnects per day). The majority of flapping seems to be at Mae-East and Mae-West. date peer hits Jul 18 192.157.69.250 8 rs1.sprint.ra.net NY NAP Jul 18 192.41.177.125 72 mae-east.nsn.nasa.gov MaeE Jul 18 192.41.177.251 34 mae-east-rt1.es.net MaeE Jul 18 192.41.177.252 56 mae-east-rt2.es.net MaeE The July 18 problem was mostly concentrated over one 3.5 hour period of continuous flap. Jul 18 07:19:28 to Jul 18 10:52:30 (122:47 / 213:02) 192.41.177.125 took 50 hits (57:00) 192.41.177.252 took 41 hits (62:31) 192.41.177.251 took 17 hits (34:19) Any clues from NASA and ESNET as to why this instability occurred at Mae-east? Was this some form of BGP meltdown or just hardware trouble at or getting to the Mae? Curtis

2 1

None
by Allwyn Crichlow 20 Jul '95

20 Jul '95

2 1

send info
by Allwyn Crichlow 20 Jul '95

20 Jul '95

send info

1 0

broken glue in .net domain
by Michael Dillon 19 Jul '95

19 Jul '95

We are attempting to get the Internic to change our secondary nameserver for the junction.net domain but not having much luck. Our change requests for in-addr.arpa went through in a few days. But the Internic rejected the first request saying we needed to use a new form. So we resubmitted but it is now almost two weeks ago. What is the point of a new form if we cannot get things updated any faster? Then we noticed that DNS to our new secondary nameserver ns2.bc.net was acting wierd. So we dug into the .net domain and discovered several A records with the WRONG IP ADDRESS. I don't know whether it was a typing error at the Internic or whether somebody at BC.NET screwed up, but why do changes like this take so long if nobody even verifies such a simple and obvious thing? You can see this by trying the whois command on sno.net, infoserve.net or concordpacific.net Compare the IP address for ns2.bc.net with the one given by nslookup when talking to an authoratative server for the domain like jade.bc.net In addition there is at least one glue record for ns1.bc.net which erroneously reports its IP address to be 128.198.4.1 which is also wrong since ns1 is the same as jade.bc.net Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael(a)memra.com michael(a)junction.net

1 0

Re: Call for Mbone reflectors
by rsingleton＠hai-net.com 16 Jul '95

16 Jul '95

Hi my name is Rickie Singleton from Arlington VA. I would like to become an active participant on the Mbone and I would like to set up a reflector. I will be using an SGI extreme 2. Can anyone point me in the right direction to get a reflector setup. I am hoping the mrouted 3.x will fix my mbone problem and I am currently running CUSEEME on my mac. Now comes the task of setting up a reflector on the SGI. Would appreciate any comments. thx Rickie ______________________________ Reply Separator _________________________________ Subject: Call for Mbone reflectors Author: bmanning(a)ISI.EDU at internet Date: 7/12/95 12:06 PM > > Bill, > > We have the mbone slot reserved for ISN. I will post this note to teachers > today and begin doing what I can to get them involved. What needs to be > done to push providers to get reflectors set up? > > Thanks, > J > =-=-=-=-NOTE TO POST TO ED LISTS-=-=-=-= > To all Educators able to use CU-SeeMe this summer! > > The Internet School Networking (ISN) group of the Internet Engineering > Task Force (IETF) will be broadcasting its thrice-yearly meeting over the > mbone on Monday, July 17. The meeting will be held in Stockholm, Sweden, > from 9:30 to 11:30 a.m. local time. > > If you would like to participate, please notify me as soon as possible! > > Thanks, > Jennifer Sellers > ISN Co-chair > > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > sellers(a)quest.arc.nasa.gov NASA's K-12 Internet Initiative > gopher quest.arc.nasa.gov Sterling Software > http://quest.arc.nasa.gov 700 13th Street, NW > phone: 202-434-8954 Suite 950 > fax: 202-434-4599 Washington, DC 20005 > ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ > > =-=-=-=-END OF NOTE TO ED LISTS-=-=-=-= > Hi all, If we are actually going to have real teachers participate in the ISN - WG remotely, there should be an identified reflector net setup, since most of the target audience has access to CUSeeMe and not traditional mbone tools. (Odd, traditional & mbone linked together.. :) It should be possible to identify where on the Mbone topology current reflectors sit, and then we will have a better idea where new reflectors need to be. What I really want to avoid is a reflector hosted at the IETF site and all that CUSeeMe traffic converging on that machine.. :) Any clues/assistance etc. would be helpful. -- --bill

1 0

Re: New Reflector info (fwd)
by bmanning＠ISI.EDU 12 Jul '95

12 Jul '95

> We have a version of the new reflector code up on the Cornell > reflector at 132.236.91.204 now. However, it only tracks for new versions > of the desktop app, the Mac version of which will go to alpha testers today > maybe. We're trying to update the reflector so it will also track (more > crudely) the old versions of the app. As this will be the first version of > the reflector to be released in binary only (except to source licensees), > we're co-ordinating with White Pine to get it compiled for all the popular > platforms and binaries posted. We may have updates out several times in > the next couple weeks as the bw management algorithms get tuned. > If all goes well, we should have both Mac and Windows apps out as > beta versions by the time of IETF. > Some thought on best way to configure reflectors for IETF is > probably a good idea. In general, a feed from a reflector at IETF to the > mbone, picked up by other reflectors in useful places might be a good > approach. > > Cheers, -Dick > > >Bill Manning from ISI is trying to set up and MBONE/CU-SeeMem > >transmission of some IETF sessions from Sweden in 2 weeks. He > >wanted to know when the nex reflector software with the > >better bandwidth management will be released - and if not before > >IETF, is there a way to push the release day up.. > > > >martyne > > --bill

1 0