- NANOG - lists.nanog.org

ISP Address Allocation
by rfuller＠3x.com 15 Nov '99

15 Nov '99

What is the best and most accurate way to determine an ISP's range of addresses? For example, if I wanted to see what AT&T's allocation of IP addresses are, how would I go about doing this in the most timely manner? What about for smaller ISPs? Thanks! Ron Fuller, CCDP, CCNP-ATM, CCNP-Security, MCNE, MCP 3X Corporation rfuller(a)3x.com

5 5

visual traceroute (was Re: RFC1712 - is anyone actually using GPOS RR's ?)
by k claffy 15 Nov '99

15 Nov '99

> > >We were thinking of adding this to our automated dns scripts ... but if > > >nobody actually uses them, we don't want to spend time on it ... > > > > use LOC (rfc1876) instead. it's more or less the same, but with more > > info. > > Thanks for the pointer, then my next question will be ... > Are any registering LOC for their routers/hosts ? > Any visual traceroute or similar applications using this ? > > /Jesper Several, including a new tool from the caida folks. LOCs are good stuff. --bill bill means: www.caida.org/Tools/GTrace/ (uses visualroute maps w permission) presented at Usenix last week http://www.usenix.org/events/lisa99/index.html uses NetGeo www.caida.org/Tools/NetGeo/ still not optimal, but headed in the right direction k

1 0

NANOG 18
by Pam Ciesla 15 Nov '99

15 Nov '99

NANOG 18 registration is now open. Registration page and meeting information can be found on the NANOG webpage http://www.nanog.org. Any questions please contact me. Thanks Pam Pam Ciesla Events Coordinator Merit Network,Inc. 734-936-0172 - phone 4251 Plymouth Road 734-647-3185 - fax Bldg.I, Suite C pam(a)merit.edu Ann Arbor, MI 48105

1 0

Adios to NSI?
by John K. Doyle, Jr. 14 Nov '99

14 Nov '99

Folks, After a recent near-death (well, near-career-limiting anyway) experience with NSI over a simple DNS server update to an existing registered domain, the thought occurs to me: Perhaps I should just switch ALL of my domains over to another Registrar as they get near their renewal dates. THAT way I'll never have to power-dial (703) 742-4777 for hours on end ever again! We don't do enough domain add/change/delete traffic to qualify for an assigned rep (not from NSI anyuway), but we do have a couple of dozen active registrations. So the question is, are any of the newer "alternative" registrars substantially better? NSI appears to be run by former Cable TV Customer Service types. Who can say whether or not some of them have snuck off to work for the newer Registrars and are therefore lowering the cluefulness level at their new places of employment? </rant> Seriously, I'm looking for comments on the operational reliability of register.com and similar. We don't have any particularly quirky expectations. It'd just be nice to be able to get the Registrar on the phone if necessary. Also, has anyone other than Ehud actually tried to "transfer" an active domain between Registrars? His recent post made it sounds like the process is fraught with pitfalls. I'll summarize any private reponses I receive for the list. Thanks, John ------------------------------------------------------------------------- John K. Doyle, Jr. | Oracle Corporation | Email: jkdoyle(a)us.oracle.com Location: 4op28 | Voice: (650) 506-2380 | FAX: (650) 633-2350

1 0

MAE ATMs... guessing & monitoring... in the absense of PeerMaker
by Lauren F. Nowlin 12 Nov '99

12 Nov '99

Hi all, More operational today than usual... "PeerMaker" with all the bells & whistles (i.e. any monitoring capability at the MAE ATM NAPs) has been shelved until next year due to 'performance hiccups' Great. This problem doesn't arise at AADS or PBNAP because the silly guesstimates and ceilings for sustained cell rate and assigned PVC sizes aren't an issue. It would seem noc troubleshooting MAE ATM cell drops would be nightmare if the peer is having an event or somesuch... I just spoke to a couple of peers with circuits soon to arrive (same boat Onyx is in) and we are wondering why we have to supply this guess if there isn't a way to monitor and make proper adjustments when necessary. My MAE account rep. is on vacation. Looking for feedback from participating peers... via private mail please. Thanks, -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

Y2K rollover status report participation
by Sean Donelan 12 Nov '99

12 Nov '99

Its getting towards the end, and I didn't want anyone to say "Nobody asked me." The reporting channels for a few of the major ISPs is established, but I didn't want to leave important folks out, e.g. exchange points, route servers, root servers, measurement servers, and anyone else with something to contribute. I will be using this information to make a list of which part of the Internet is being handled by which status reporting organization. For the parts of the Internet otherwise not being handled, I plan to set up a couple of very simple reporting methods. Since I don't think the Internet will be affected too much, it will be via standard Internet communications, including regular status templates via e-mail, a multicast sesssion, and possibly one or two others (we know USENET works during an earthquake). There is essentially no time to develop anything more than the simplest status reporting using time-tested methods. I expect most reports to be "Situation Normal, Nothing to Report." For exception reporting, there will be an out-of-band method and the details will be provided to those participating. Since e-mail and the other methods can handle much larger groups than a teleconference bridge, I expect to be able to handle a large group with only a few volunteers over those days. Yes, I also need a few people to do some work. Send e-mail if interested. No pay, but I will have a cool T-shirt for those who work. If you already believe you have a reporting channel (e.g. IOPS, NCS, Y2K/CC, PR Newswire), please fill this out. If you don't know or don't have one, and would like one, please enter "NEED" as your reporting channel. Under "Reporting For:" for networks enter the ASNs of the networks you will be responsible for reporting (e.g. don't list customers unless you will explicitly be reporting customer status), for root servers enter the machine name (e.g. a.root-servers.net) for exchange points enter the name of the exchange point and IP network(s) used, for other services enter whatever reasonably unique identify I can use. Organization Name: Reporting Channel: Reporting For: Admin Contact: Admin Address 1: Admin Address 2: Admin City: Admin State/Province: Admin Zip/Postal Code: Admin Country: Admin Voice Number: Admin Fax Number: Admin Email: I need this information no later than November 18, 1999. I can't add anyone after that point. As always, you could always decide later not to participate. Note: please send replies to sean(a)donelan.com, unless you really want to copy the entire nanog list.

1 0

PSI/Digex announcements
by Joe Shaw 11 Nov '99

11 Nov '99

I have a non peering T1 to PSI for VPN customers. While troubleshooting some problems for one of those VPN customers I came across these: HOUSTON_BR1#show ip bgp regex ^174$ Network Next Hop Metric LocPrf Weight Path *> 12.15.224.192/27 38.7.128.1 200 174 i *> 154.32.255.0/30 38.7.128.1 200 174 i *> 192.245.179.248/30 38.7.128.1 200 174 i *> 198.17.203.0/25 38.7.128.1 200 174 i *> 198.137.240.32/27 38.7.128.1 200 174 i *> 198.207.208.192/27 38.7.128.1 200 174 iA *> 204.4.196.32/27 38.7.128.1 200 174 i *> 204.4.196.64/27 38.7.128.1 200 174 i *> 204.4.196.96/27 38.7.128.1 200 174 i *> 204.68.218.0/27 38.7.128.1 200 174 i *> 204.180.67.160/27 38.7.128.1 200 174 i *> 206.181.125.188/30 38.7.128.1 0 200 174 i *> 206.119.241.96/27 38.7.128.1 200 174 i *> 207.37.154.120/29 38.7.128.1 200 174 i *> 207.138.126.128/27 38.7.128.1 200 174 i Isn't it considered "bad" to be announcing nets that small, especially the /30's? -- Joseph W. Shaw - jshaw(a)insync.net Free UNIX advocate - "I hack, therefore I am."

2 2

RE: PSI/Digex announcements
by Chris Flores 11 Nov '99

11 Nov '99

Joe, Yes - this is indeed not optimal. To keep routing tables manageable, BGP announcements should be aggregated into a shorter prefix such as /20 or /19 (whatever is possible). Many autonomous systems accidentally leak longer announcements for various reasons; accurate filtering can eliminate these mistakes. It looks like the autonomous system from your email is redistributing connected routes - you can start by contacting the originating autonomous system. Hope this helps. CF -----Original Message----- From: Joe Shaw [mailto:jshaw@insync.net] Sent: Thursday, November 11, 1999 3:58 PM To: nanog(a)merit.edu Subject: PSI/Digex announcements I have a non peering T1 to PSI for VPN customers. While troubleshooting some problems for one of those VPN customers I came across these: HOUSTON_BR1#show ip bgp regex ^174$ Network Next Hop Metric LocPrf Weight Path *> 12.15.224.192/27 38.7.128.1 200 174 i *> 154.32.255.0/30 38.7.128.1 200 174 i *> 192.245.179.248/30 38.7.128.1 200 174 i *> 198.17.203.0/25 38.7.128.1 200 174 i *> 198.137.240.32/27 38.7.128.1 200 174 i *> 198.207.208.192/27 38.7.128.1 200 174 iA *> 204.4.196.32/27 38.7.128.1 200 174 i *> 204.4.196.64/27 38.7.128.1 200 174 i *> 204.4.196.96/27 38.7.128.1 200 174 i *> 204.68.218.0/27 38.7.128.1 200 174 i *> 204.180.67.160/27 38.7.128.1 200 174 i *> 206.181.125.188/30 38.7.128.1 0 200 174 i *> 206.119.241.96/27 38.7.128.1 200 174 i *> 207.37.154.120/29 38.7.128.1 200 174 i *> 207.138.126.128/27 38.7.128.1 200 174 i Isn't it considered "bad" to be announcing nets that small, especially the /30's? -- Joseph W. Shaw - jshaw(a)insync.net Free UNIX advocate - "I hack, therefore I am."

1 0

Re: PSI/Digex announcements
by Joe Shaw 11 Nov '99

11 Nov '99

> *> 206.181.125.188/30 38.7.128.1 0 200 174 i HOUSTON_BR1#traceroute 206.181.125.189 Type escape sequence to abort. Tracing the route to dfw2-core1-s3-1-0.atlas.digex.net (206.181.125.189) 1 lspr.dallas.tx.ce.us.psi.net (38.7.128.1) [AS 174] 28 msec 8 msec 12 msec 2 dfw2-core1-s3-1-0.atlas.digex.net (206.181.125.189) [AS 174] 176 msec * 12 msec Sorry, I didn't mean to implicate it was you, it was that network that made me go back and look for all the others. The original title was PSI/DIgex announcement, then I changed it to announcements without removing Digex. My apologies for the confusion. -- Joseph W. Shaw - jshaw(a)insync.net Free UNIX advocate - "I hack, therefore I am." On Thu, 11 Nov 1999, Aaron Weintraub wrote: > Hi, I'm kind of curious as to how digex is implicated in this mail. I > can't seem to find any indication of our involvement here. Thanks, > > aw > -- > Aaron Weintraub - aaronw(a)digex.net > IP Operations

1 0

Re: IPv4 Hash Function
by Vadim Antonov 11 Nov '99

11 Nov '99

In my experience, Fibonacci hashing is faster and gives a better spreading. --vadim Richard Steenbergen <ras(a)above.net> wrote: I have seen the IPv4 hash function: (ip ^ (ip >> 23) ^ (ip >> 17)) & ~(bucketsize - 1) for power-of-2 sized hash tables attributed to Van Jacobson, in many places, but I have never found any paper or writing that is the actual source of this. Does anyone know where I might find such? Personal curiosity only.

1 0