- Test - lists.nanog.org

TRACEROUTE Update: support for Linux, Solaris X86
by Ehud Gavron 06 Jan '99

06 Jan '99

Traceroute 2.8.2 1. Linux support (thanks Brian Murphy) 2. Sol X86 support (thanks Craig Watkins) 3. Minor bugfixes Traceroute 2.8.2 is at ftp://ftp.aces.com/pub/software/traceroute/beta/traceroute.c The readme contains compilation instructions and is at ftp://ftp.aces.com/pub/software/traceroute/beta/0_readme.txt If you want to add to the version matrix, email me your compile line and your uname -a. Ehud Tested Version Matrix 01/05/1999 ------------------------------------------------------- Operating System TR2.7 TR2.8 TR2.8.2 ------------------------------------------------------- AIX 3.2.5 2.7 BSDI 1.1 2.7 Digital UNIX 3.2c 2.7 Digital UNIX 4.0 2.8 2.8.2 FreeBSD 2.0.5 2.7 FreeBSD 2.2.x(1,6) 2.8 2.8.2 FreeBSD 2.2.7 2.8.2 FreeBSD 2.2.8 2.8.2 FeeeBSD 3.0 2.8.2 Mach10 2.7 Ultrix 4.3 2.7 2.8 Unixware 1.0.3 2.7 SunOs 5.4 2.7 Solaris 2.5.x(0,2) 2.7 Solaris 2.6 2.8 2.8.2 Solaris X86 2.5.1 2.8.2 VMS6 or 7 MultiNet 3 or4 2.7 2.8 2.8.2

1 0

Re: Where's 209.240.157.34 ?
by Richard Parker 06 Jan '99

06 Jan '99

John R Levine wrote >Where's 209.240.157.34 ? > >Got a spam advertising a web page there, ARIN claims it's not allocated >although all the space around it is. It routes through Tierranet. TierraNet (ASN 10732) is advertising 209.240.128.0/19, which includes 209.240.157.34 (ns1.netcolony.com) ARIN reports that they've only been allocated 209.240.128.0/20 and that the other half of the /19 that they're announcing (209.240.144.0/20) is unallocated. Perhaps ARIN has reserved the entire /19 for TierraNet, but only actually allocated the lower /20 to them? Perhaps TierraNet is announcing their /20 as a /19 to get past Sprint's route filters? -Richard

3 2

Re: Operational question: Building filters from IRRdbs
by Gerald Andrew Winters 06 Jan '99

06 Jan '99

Alex, > Which version of peval do I have to run (3.xxx???) to work > with the production servers? 4.xxx doesn't work with RADB > etc. Our production server, whois.ra.net/43, is RIPE181 compliant until the community decides on a final transition date (hopefully this spring/summer). The ISI version 3.x tools are RIPE181 compliant and version 4.x are RPSL tools exclusively. Please let me know if you have any problems. regards, --jerry ps Unfortunately, ISI does not default to our server and you must specifically set a command line flag so the tools can parse the server output. Check the man page for the correct flag to select.

2 1

Re: Operational question: Building filters from IRRdbs
by Alex Bligh 06 Jan '99

06 Jan '99

Gerald, Oh OK - that explains it. Which version of peval do I have to run (3.xxx???) to work with the production servers? 4.xxx doesn't work with RADB etc. Alex Bligh GX Networks (formerly Xara Networks) > Hello Alex, > > I have resynchronized the data on our experiemental/educational > rpsl.merit.edu/43 server. As far as the server running at > low priority goes, this has nothing to do with the 'up to dateness' > of the data. Normally data is refreshed every 15 minutes > with production server, whois.ra.net/43. However, this is > a transitional period in which experimentation and code development > are occuring. There is no stable RPSL database code distribution > at this point in time and the effort to bring this code to prodcution > status is still on-going. And as such, you can expect data staleness, > outages, etc... occasionally as the bugs are finally ironed out. > > The situation on our production server is quite different. > We are the authoritative source for the radb and ans db's > and we mirror ripe @15mins. Bell Canada/canet and MCI/CW > are non-mirrored db's and we download them @24hrs. However, > our production server is RIPE181 compliant whereas rpsl.merit.edu > is a playpen for the next db syntax, RPSL. > > regards, > > --jerry (Merit) > > Alex Bligh (amb(a)gxn.net) on January 3: > > Here's a couple of operational questions for those who build > > filters from IRRdb's. > > > > Background: > > > > * peval / rpsl.merit.edu *may* be incorrectly evaluating > > RIPE database entries currently - but this isn't my main > > thrust. The scary thing is suddenly what I'm 99% sure used > > to work (expanding AS Macros) now silently fails if they > > are in RIPE. [for details see the end] > > > > * I'm not saying the server is broken (I guess it has something to > > do with the 'server is running at low priority' line), but if I had > > this in an automatic filter generating run, it would generate > > the RADB stuff just fine, and silently filter out all RIPE based > > peerings. Even if it's working perfectly correctly, the questions > > are still interesting, at least to me. > [snip...]

2 1

Re: Where's 209.240.157.34 ?
by Richard Parker 06 Jan '99

06 Jan '99

Chris Bradley wrote: >Richard Parker wrote: > >> John R Levine wrote >> >Where's 209.240.157.34 ? >> > >> >Got a spam advertising a web page there, ARIN claims it's not allocated >> >although all the space around it is. It routes through Tierranet. > >[edit] > >> Perhaps ARIN has reserved the entire /19 for TierraNet, but only >> actually allocated the lower /20 to them? Perhaps TierraNet is >> announcing their /20 as a /19 to get past Sprint's route filters? > >ARIN policy for initial allocations to ISPs declares that a provider will be >allowed to temporarily announce a /19, when they have been allocated a /20. Well...that explains why they're announcing a /19 when they've been allocated a /20, but it leaves the question "Why do they have machines with addresses in the top portion of the /19 announcement that are not in the /20 they've been allocated?" -Richard

3 2

Re: IGP Comparison (Summary of Responses)
by Scott Brim 06 Jan '99

06 Jan '99

From: Henk Smit <hsmit(a)cisco.com> > Most of the large ISPs in the US run IS-IS as their IP IGP. > In europe a number of PTTs have chosen IS-IS as the IGP for their new > IP Internet backbones. That might be an indication if IS-IS is dead. This points out the real issue. OSPF and IS-IS are close enough that other factors usually outweigh their differences. The choice of IS-IS in this case is really the result of the choice of an equipment vendor. These days at least, vendors are not chosen because they implement IS-IS. IS-IS is chosen because of some vendors' protocol implementations.

3 2

RE: IGP Comparison (Summary of Responses)
by Dan Rabb 06 Jan '99

06 Jan '99

> We should also point out that the IETF is now an OSI liason > organization > and can make contributions to the ISO process. Further, given the > technical expertise of the folks working in the IETF, the > effective death > of CLNP, and the fact that a significant proportion of the > systems running > IS-IS are actually doing so to forward IP, any contributions > made by the > IETF will be taken very seriously by ISO. > > Regards, > Tony Li > IS-IS WG co-chair > Does anyone have any theoretical numbers that would indicate which protocol has a faster convergence time in a given situation? Are there any true performance diffrences? Dan Rabb Network Engineer digital broadcast network dan(a)dbn.net

2 1

Re: IGP Comparison (Summary of Responses)
by Tony Li 06 Jan '99

06 Jan '99

hsmit(a)cisco.com (Henk Smit) writes: > > "There were also non-technical considerations. Many people felt that it was > > better that the IETF have complete control over the OSPF protocol design > > rather than depend on an ISO committee whose goals, namely to produce a > > routing protocol for the OSI protocol stack, were somewhat different."(2) > > This is all history, and should not be a reason for you to pick one > protocol over the other. The IETF has become what OSI was (and even > worse). Right now there are active OSPF *and* IS-IS workgroups. The IETF > can extend IS-IS as much as is needed. We should also point out that the IETF is now an OSI liason organization and can make contributions to the ISO process. Further, given the technical expertise of the folks working in the IETF, the effective death of CLNP, and the fact that a significant proportion of the systems running IS-IS are actually doing so to forward IP, any contributions made by the IETF will be taken very seriously by ISO. Regards, Tony Li IS-IS WG co-chair

2 1

Re: IGP Comparison (Summary of Responses)
by Tony Li 06 Jan '99

06 Jan '99

SEAN(a)SDG.DRA.COM (Sean Donelan) writes: > If you didn't have an installed base, and didn't already know one or > the other, which would you choose? Or just punt, and use iBGP.... I'm only slightly biased, but... Having implemented IS-IS; having listened to a certain former IS-IS implementor gripe greviously about the fun he was having implementing OSPF; having watched both successful and unsuccesful OSPF implementations; knowing what I know about both protocols, and given Murphy's tendency to veer towards complexity, my decision would take less time than an SPF. ;-) Tony

1 0

Re: IGP Comparison (Summary of Responses)
by Sean Donelan 06 Jan '99

06 Jan '99

randy(a)psg.COM (Randy Bush) writes: >> Most of the large ISPs in the US run IS-IS as their IP IGP. >> In europe a number of PTTs have chosen IS-IS as the IGP for their new >> IP Internet backbones. That might be an indication if IS-IS is dead. > >hypothesis: big isps talk less. except a few loudmouths <g>, and when jhawk >gets pissed off <g^2>. I know why most of the older large ISPs use IS-IS, because it was the only option that worked at the time. But now that some router vendors have come out with workable OSPF implementations, I've been wondering which road the new ISP competitors would take. So far, they've been hiring all the engineering staff away from the older ISPs. And then the engineers set up the new network with the same skills, meaning IS-IS. But what if you started from a clean slate... If you didn't have an installed base, and didn't already know one or the other, which would you choose? Or just punt, and use iBGP.... -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4