- NANOG - lists.nanog.org

IP utillization software
by Tim Finkenstadt 19 Aug '99

19 Aug '99

Greetings. I am looking for IP address utilization software for the following purpose: I work for a very large company with lots of facilities and offices. Our group needs to reclaim the space that was previously allocated before the days of VLSM. For example: facility allocated 172.28.32/19 . I want to be able to find out how much that facility is utilizing. thanks, tim

3 2

snmpstat monitor ver. 1.2.e - see http://noc.bn.ru/~alex/MON
by Alex P. Rudnev 18 Aug '99

18 Aug '99

I completed, as promised, the work of collecting distribution pack for the snmpstat monitor (version 1.2.e, where 'e' means _english menu available_). The system was tested for the FreeBSD and Solarys 2.6, but I believe it can work fine on any Unix where CMU SNMP library can be translated. This pack include: - the russion and english dicumentation; - the installation pack (tested for the fixed /p/stat and user: monitor group: monitor configs but theoretically allowing to use any location and user), including snmpstatd daemon, WWW interface to the monitoring system, LINKS data base and WWW interface for it, and (in addition) modems_poll monitor (withouth any WARRANTIES and docs). This (1.2) is SHAREWARE software - we ask you to contact us in case this appear to be usefull for your market or provision work, if you are the commercial company. I can't promise the next (with the object priorities, snmp polling of the modems, service monitoring etc) version should be just as free as this one, but it should not bee 100% commercial anyway. Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

Re: WWW/DNS problems
by Simon Leinen 18 Aug '99

18 Aug '99

> We currently have two blocks of IP address space, 195.224.206/24 and > 193.193.186/23. Everything works fine from 195.224.206 but from > 193.193.186 there are often problems [...] Did you try registering a "route" object for 193.193.186.0/23 in the routing registry? That might improve connectivity to those addresses. At least from here (Switzerland) we don't see the announcement for 193.193.186.0/23 from our European transit provider, presumably because it is filtered out. swiCE1>trace 195.224.206.1 Type escape sequence to abort. Tracing the route to gatekeeper.olf.co.uk (195.224.206.1) 1 switch.ch.ten-155.net (212.1.192.169) [AS 8933] 4 msec 4 msec 0 msec 2 ch-se.se.ten-155.net (212.1.192.46) [AS 8933] 52 msec 52 msec 52 msec 3 sw-gw.nordu.net (212.1.192.154) [AS 8933] 52 msec 52 msec 52 msec 4 west-gw.nordu.net (193.10.252.133) [AS 2603] 52 msec 52 msec 52 msec 5 et0-llb-x-dg.DG1.core.rtr.xara.net (194.68.128.46) 92 msec 92 msec 92 msec 6 at0-0-llb-pvc202-dg1.TH1.core.rtr.xara.net (194.143.164.105) [AS 5519] 92 msec 92 msec 92 msec 7 fd1-0-0-llb-x-many.TH28.core.rtr.xara.net (194.143.163.36) [AS 5519] 92 msec 92 msec 92 msec 8 hs0-0-0-llb-th28.HE1.core.rtr.xara.net (194.143.164.166) [AS 5519] 92 msec 92 msec 96 msec 9 fd1-1-0-llb-x-many.HE2.core.rtr.xara.net (194.143.163.114) [AS 5519] 92 msec 96 msec 96 msec 10 fd5-0-0-llb-x-many.HE5.core.rtr.xara.net (194.143.163.115) [AS 5519] 96 msec 92 msec 92 msec 11 olf-avnet-router.olf.co.uk (195.224.74.230) [AS 5519] 104 msec 104 msec se0-xfs-d600-he5.aviators.cust.rtr.xara.net (195.224.219.105) [AS 5519] 96 msec 12 olf-avnet-router.olf.co.uk (195.224.74.230) [AS 5519] 100 msec 100 msec 100 msec 13 olf-router-01.olf.co.uk (193.193.186.254) 128 msec 168 msec 172 msec 14 gatekeeper.olf.co.uk (195.224.206.1) [AS 5519] 112 msec 120 msec 144 msec swiCE1>trace 193.193.186.1 Type escape sequence to abort. Tracing the route to gatekeeper.olf.co.uk (193.193.186.1) 1 swiEZ1-A0-0-0-8.switch.ch (130.59.33.26) 8 msec 4 msec 8 msec 2 swiEG1-F1-0-0.switch.ch (130.59.20.211) 4 msec 8 msec 4 msec 3 swiNY1-A5-0-0-1.switch.ch (130.59.33.2) 100 msec 100 msec 100 msec 4 39.atm4-0-0.GW3.NYC4.ALTER.NET (157.130.13.61) 104 msec 100 msec 100 msec 5 110.ATM2-0.XR1.NYC4.ALTER.NET (152.63.21.202) 100 msec 100 msec 100 msec 6 189.ATM2-0.TR1.NYC1.ALTER.NET (146.188.179.18) 104 msec 100 msec 104 msec 7 104.ATM5-0.TR1.DCA1.ALTER.NET (146.188.136.213) 104 msec 108 msec 104 msec 8 199.ATM7-0.XR1.DCA1.ALTER.NET (146.188.161.133) 104 msec 104 msec 108 msec 9 195.ATM9-0-0.GW3.DCA1.ALTER.NET (146.188.161.77) 108 msec 112 msec 108 msec 10 abovenet-dca-gw.customer.ALTER.NET (157.130.37.254) 108 msec 104 msec 108 msec 11 main1-core1-oc3-1.iad.above.net (209.249.0.18) 108 msec 272 msec 104 msec 12 u-net.customers.iad.above.net (209.249.97.37) 156 msec 200 msec 168 msec 13 195.102.254.61 [AS 5669] 180 msec 192 msec 156 msec 14 195.102.254.70 [AS 5669] 172 msec 160 msec 180 msec 15 195.102.208.214 [AS 5669] 184 msec 192 msec 188 msec 16 gatekeeper.olf.co.uk (193.193.186.1) 180 msec 192 msec 208 msec -- Simon.

1 0

Re: WWW/DNS problems
by shields＠msrl.com 17 Aug '99

17 Aug '99

In article <4.1.19990817105005.00a44360(a)mailhost.broadcast.com>, ddivinia(a)broadcast.com (Darin Divinia) wrote: > I also had one to ti.com bounce. At about 9:30 UTC h.root-servers.net was returning NXDOMAIN for most though not all .com domains. For example, amazon.com and netsol.com were broken. msrl.com worked, but all of its nameservers are in .net; ibm.com worked, but all of its nameservers are within ibm.com and are covered by glue records. The pattern seemed to be that any domain with all of its nameservers in .com but outside of its own zone would fail to resolve from h.root-servers.net. I only tried about a dozen domains so the actual pattern may have been different. I sent a mail this morning to hostmaster(a)internic.net (with no response of course, but that's the SOA contact for .) and cc'd to nanog (but I had neglected to subscribe to nanog-post). It's interesting that there was no mention of this outage, which caused hard mail bounces and other problems. -- Shields.

1 0

NANOG 17 HOTEL REMINDER
by Pam Ciesla 16 Aug '99

16 Aug '99

NANOG 17 will be held in Montreal, Canada on October 3-5, 1999 at the Hotel Wyndham Montreal. The room block for the NANOG 17 hotel ends on September 2nd. The room rate of $160 (Canadian) can not be guaranteed beyond that date. The Wyndham Montreal is about 20 minutes by taxi from the Dorval Airport and the taxi cost about $25. Information about the hotel and meeting can be found on the webpage http://www.nanog.org. Reminder to US citizens to bring proof of citizenship. If you are bringing any equipment it would be advisable to bring proof of ownership. Any questions please contact me. Hope to see you there. Pam Hotel Wyndham Montreal 514-285-1450 - phone 800-361-8234 - toll free US & Canada 514-841-2037 - fax Mention Merit NANOG Meeting Pam Ciesla Merit Network,Inc. 734-936-0172 - phone 4251 Plymouth Road 734-647-3185 Bldg.I, Suite C pam(a)merit.edu Ann Arbor, MI 48107

1 0

Shared network services and transit providers
by Sean Donelan 15 Aug '99

15 Aug '99

Shared registries and backup, note: this is not intended to be NSI bashing. Although NSI receives free transit from a number of backbone's, it appears NSI is only announcing its own registry via the free transit it receives. The shared registry whois.crsnic.net appeared to be single-homed through Sprint today. This came up, because there was a network problem reaching whois.crsnic.net, but it didn't affect NSI's own service. I also looked at several of the other well-known registries. From my network vantage point (BGP only shows the 'best' transit): ARIN seems to have at least two ISP connections, RIPE at least three connections. APNIC appears single-homed through Telstra, I guess shouldn't be surprising since its in Australia. Are these shared services important enough for network operators to try to coordinate multiple connections for them? Or with competition coming, let them each do whatever they want? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: NetCool
by jrg＠blodwen.demon.co.uk 15 Aug '99

15 Aug '99

Mike Heller <mikeh(a)earthweb.com> writes: > Would anyone like to share positive or negative experiences with this > product on or off the list? From what I've seen of it, I'm very > impressed. I'd like to get real world feedback. you could also try asking on the 'netcool/omnibus users' list - email nco-users-request(a)gbnet.net ('subscribe' in the message body) to join. James.

1 0

The Cidr Report
by Tony Bates 13 Aug '99

13 Aug '99

This is an auto-generated mail on Fri Aug 13 12:00:00 PDT 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 13Aug99 0) General Status Table History ------------- Date Prefixes 060899 61906 070899 61697 080899 61812 090899 61912 100899 62034 110899 62198 120899 63033 130899 63211 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 5428 Number of ASes announcing only one prefix: 2841 (1563 cidr, 1278 classful) Largest number of cidr routes: 472 announced by AS701 Largest number of classful routes: 993 announced by AS1890 1) Gains by aggregating at the origin AS level --- 13Aug99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1890 993 436 557 56.1% UUNET NL Autonomous System AS271 343 148 195 56.9% BCnet Backbone AS2609 124 20 104 83.9% EUnet-TN AS1221 541 444 97 17.9% TELSTRA-AS AS174 577 483 94 16.3% Performance Systems International AS577 286 193 93 32.5% Bell Canada Backbone AS7046 323 236 87 26.9% UUNET-CUSTOMER AS4293 235 148 87 37.0% IMCI AS4200 183 104 79 43.2% AGIS (Apex Global Information Ser AS7657 235 159 76 32.3% The Internet Group Limited AS209 323 247 76 23.5% Qwest Communications AS7545 141 66 75 53.2% TPG Internet Pty Ltd AS3749 139 64 75 54.0% TECNET AS7496 108 34 74 68.5% Power Up AS10928 118 48 70 59.3% UNKNOWN AS9269 85 20 65 76.5% Hong Kong CTI AS6944 63 6 57 90.5% RapidSite, Inc. AS4755 137 80 57 41.6% Videsh Sanchar Nigam Ltd. India AS4740 354 298 56 15.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS719 458 407 51 11.1% LANLINK autonomous system AS2493 156 107 49 31.4% iSTAR Internet, Inc. AS684 91 46 45 49.5% Manitoba Regional Network Backbon AS3737 105 65 40 38.1% PenTeleData Inc. (ASN-PTD) AS549 210 171 39 18.6% ONet Backbone AS1 499 463 36 7.2% BBNPLANET AS1785 242 209 33 13.6% NYSERNet Backbone AS4307 32 1 31 96.9% SVINET-1 AS10479 40 9 31 77.5% ITESM-Rectoria Zona Norte AS8023 43 13 30 69.8% CASTLES AS7745 38 8 30 78.9% BIGSKY-AS For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Reminder: Ameritech EP renumbering
by Mark A. Cnota 13 Aug '99

13 Aug '99

This is a reminder to everyone about the renumbering activity this weekend. Customers received the below note several weeks ago. Please e-mail if there are any questions. -Mark --- To customers of the Ameritech ATM exchange point in Chicago: As previously announced, Ameritech will be changing the address space used for customers at the exchange point. The current space was formerly managed by ISI as part of the Routing Arbiter project but is now administered by JAM. The new space has been allocated directly to Ameritech, specifically for the Chicago exchange point, and will be managed by Merit Networks. This change will involve a one-time renumbering effort for all customers. In order to allow for as much coordination and preparation among customers as necessary, we are giving everyone an extended forward notice of this activity. The scheduled date for the renumbering is Sunday, 15 August 1999. In the next few weeks, further information including new address assignments will be made available on our web site, http://nap.aads.net. Questions should be directed to nap-info(a)nap.aads.net.

1 0

IP Allocations
by Mark Cobb 13 Aug '99

13 Aug '99

I have a question about how much IP space to allocate for downstream customers. I know that when we want to obtain IP space that we have to go to ARIN with the proper justification forms to show that we have effeciently utilized our assigned IP CIDR's and also to verify that they have been SWIP'd, etc... We also offer transport, so I came up with a basic "rule of thumb" to use as a guideline. Up until recently, this has worked fine. Now I am uncertain of what I should do with a customer that is requesting a /23 CIDR, yet they only have 256K bandwidth. Part of me says give it to them and let thier customers deal with the service that they will receive, but then I feel obligated to not support bad ISP service. I guess that I am looking for an industry guideline as opposed to the one that I am trying to use or if I should even care. I use the following: 256K = /26, 512K = /25, full T1 = /24, etc.. Let me know what everyone thinks, is this fair or not, and should I care??

4 3