- NANOG - lists.nanog.org

RE: class B for sale
by Jim Fleming 09 Mar '97

09 Mar '97

On Sunday, March 09, 1997 6:48 AM, Brett L. Hawn[SMTP:blh@nol.net] wrote: @ So that I'm not misunderstood let me say this: @ @ 1: I do not neccessarily agree with the sale of IPs, personally, I don't @ think its a good idea @ There are several issues here: 1. The ownership of aggregated IPv4 addresses (i.e. blocks). 2. The leasing of those blocks. 3. The registration of those blocks. 4. The reverse resolution of those blocks. 5. The routing announcement of those blocks. An "owner" [#1] may not be involved in any of the remaining activities above and may only care about collecting "rent". People might find it interesting that several of the companies with massive /8 allocations do not think they "own" the blocks. They can not own them because they never paid for them. Likewise, they are not leasing the blocks, because they do not know who the owner is and would be willing to pay "rent" if they could identify the owner. @@@@@@@@ First 25% of IPv4 Address Space @@@@@@@@@@ CA 0.0.0.0 IANA (RESERVED-1) CA 1.0.0.0 IANA (RESERVED-9) CA 2.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-2) NJ 3.0.0.0 General Electric Company (NET-GE-INTERNET) MA 4.0.0.0 BBN Planet (NET-SATNET) CA 5.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-5) AZ 6.0.0.0 Army Information Systems Center (NET-YPG-NET) CA 7.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED-11) MA 8.0.0.0 Bolt Beranek and Newman Inc. (NET-BBN-NET-TEMP) NY 9.0.0.0 IBM Corporation (NET-IBM) CA 10.0.0.0 IANA (RESERVED-6) CA 11.0.0.0 DoD Intel Information Systems (NET-DODIIS) FL 12.0.0.0 AT&T ITS (NET-ATT) CA 13.0.0.0 Xerox Palo Alto Research Center (NET-XEROX-NET) CA 14.0.0.0 Public Data Network (NET-PDN) CA 15.0.0.0 Hewlett-Packard Company (NET-HP-INTERNET) CA 16.0.0.0 Digital Equipment Corporation (NET-DEC-INTERNET) CA 17.0.0.0 Apple Computer, Inc. (NET-APPLE-WWNET) MA 18.0.0.0 Massachusetts Institute of Technology (NET-MIT-TEMP) MI 19.0.0.0 Ford Motor Company (NET-FINET) VA 20.0.0.0 Computer Sciences Corporation (NET-CSC) VA 21.0.0.0 DDN-RVN (NET-DDN-RVN) DC 22.0.0.0 Defense Information Systems Agency (NET-DISNET) CA 23.0.0.0 IANA (NET-DDN-TC-NET) CA 24.0.0.0 @Home Network (NETBLK-ATHOME) ATHOME 24.0.0.0 - 24.3.255.0 UK 25.0.0.0 Royal Signals and Radar Establishment (NET-RSRE-EXP) VA 26.0.0.0 Defense Information Systems Agency (NET-MILNET) CA 27.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED-10) VA 28.0.0.0 ARPA DSI JPO (NET-DSI-NORTH) DC 29.0.0.0 Defense Information Systems Agency (NET-MILX25-TEMP) DC 30.0.0.0 Defense Information Systems Agency (NET-ARPAX25-TEMP) CA 31.0.0.0 IANA (RESERVED-12) Norway 32.0.0.0 Norsk Informasjonsteknologi (NET-NORGESNETT) OH 33.0.0.0 DLA Systems Automation Center (NET-DCMC) TX 34.0.0.0 Halliburton Company (NET-HALLIBURTON) MI 35.0.0.0 Merit Network Inc. (NET-MERIT) CA 36.0.0.0 Stanford University (NET-SU-NET-TEMP) CA 37.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED-37A) VA 38.0.0.0 Performance Systems International (NET-PSINETA) CA 39.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED-39A) IN 40.0.0.0 Eli Lilly and Company (NET-LILLY-NET) CA 41.0.0.0 Internet Assigned Numbers Authority (RESERVED-41A) CA 42.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-42) Japan 43.0.0.0 Japan Inet (NET-JAPAN-A) CA 44.0.0.0 Amateur Radio Digital Communications (NET-AMPRNET) CA 45.0.0.0 Interop Show Network (NET-SHOWNETA) MA 46.0.0.0 Bolt Beranek and Newman Inc. (NET-BBNNET) Canada 47.0.0.0 Bell-Northern Research (NET-BNR) NY 48.0.0.0 Prudential Securities Inc. (NET-PRUBACHE) 49.0.0.0 No match for "49.0.0.0". 50.0.0.0 No match for "50.0.0.0". UK 51.0.0.0 Department of Social Security of UK (NET-ITSANET) DE 52.0.0.0 E.I. duPont de Nemours and Co., Inc. (NET-DUPONT1) Germany 53.0.0.0 cap debis ccs (NET-DB-NET2) NJ 54.0.0.0 Merck and Co., Inc. (NET-MERCK2) VA 55.0.0.0 Army National Guard Bureau (NET-RCAS2) NC 56.0.0.0 U.S. Postal Service (NET-USPS1) France 57.0.0.0 SITA-Societe Internationale de Telecommunications Aeronautiques (NET-SITA2) CA 58.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-58) CA 59.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-59) CA 60.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-60) CA 61.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-61) CA 62.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-62) CA 63.0.0.0 Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-63) <...> @@@@@@@@@ This situation is similar to what happens when you convert a country from a government where the land is owned by the state to a situation where private ownership is allowed. There is a ONE-TIME chicken and egg problem that has to be solved. Once that occurs, then the free market dictates the rest. @ 2: This is a real world economy now, outdated academic practices which are @ currently being enforced are as wrong as the sale of IPs. @ The real world economy pre-dates the Internet by a few years... @ 3: Wether you, ARIN, or anyone else likes it or not, IPs are for all intents @ and purposes a resellable commodity, otherwise ARIN et all can (ala Jim @ Flemming) be called on as being a Monopoly. @ Again, ARIN is a local solution for an InterNIC/NSF/NSI/SAIC problem. I suggest that you study that situation and business restructuring. It is not in the best interest of the Internet to have obscur, complex, internal problems shape the future of the Global Internet. I suggest that you think global and act local. By local...I mean local to you...if you "own" [#1] IP addresses then you might want to lease [#2] them. If you lease them, then you might want to register[#3], resolve[#4], and route[#5] them. Some people will be involved in all 5 functions and some in only one of the functions. As owners [#1] step forward to start charging "rent", the people currently leasing the space without charge have several options... 1. Pay the rent 2. Buy the space 3. Find another place to homestead Prior art will determine who can sell the addresses. I suggest that people interested in these areas, carefully study that. @ 4: The simple fact of the matter is that the RFCs are not at any time, the @ law of the land. They are at best guidelines and good ideas set down for @ others to follow, but there is no rule stating that you _must_ follow them. @ The law of the land is the law of the land...most lawyers have never heard of an RFC...if you do not believe me just ask them... @ 5: Before you start chasing wild geese selling Class B address space I @ suggest you go back and check on all those folks that got space long before @ there were any 'restrictions and justifications'. I have no doubt that there @ is a veritable feast of IPs sitting unused at MIT, USC, and other such @ institutions that would be better used elsewhere instead of sitting in a @ corner like a dusty grad student. @ Those people are homesteading. When the "owners" of those spaces come knocking on their door for a rent check, then they will have to make some decisions. @ 6: Finally and most importantly, stop pretending you still live in the world @ of happy academia where everyone is willing to follow the rules you set down @ just because you're the proffessor and they're the student. This just does @ not work anymore, you may scoff at people like Jim Flemming but for each one @ you knock down there is another one to learn from his mistakes and take his @ place. Do not pretend you can sit idle and call people who don't fall in @ line behind you names so that you can sit back in your dusty chair and @ pretend nothing is wrong. The internet as a whole is growing at an unthought @ of pace and your failure to keep up will not be fixed by being tight assed @ and making it harder on those that follow. Eventually someone else will take @ the forefront and throw you off your high horse like yesterdays newspaper. @ You purport to be leaders of the internet, then its about time you acted @ like it and start to solve the problems instead of trying to make the @ problems go away by being ignorant of reality. @ The "world of happy academia" is not a place where people follow the rules. That is one of the reasons why many people like that world. They have tenure, they teach what they want, they post office hours as they like, they dress as they like, and they use the university and government supplied computers as they like. The commercial world follows the rules...the rules needed to bring order to the IPv4 address space are very simple.... -- Jim Fleming Unir Corporation e-mail: JimFleming(a)unety.net JimFleming(a)unety.s0.g0 (EDNS/IPv8)

1 0

IP Address Ownership
by Jim Fleming 09 Mar '97

09 Mar '97

On Sunday, March 09, 1997 12:34 PM, Alec H. Peterson[SMTP:ahp@hilander.com] wrote: @ This is really more appropriate on NAIPR, so replies are directed @ there... @ @ On Mar 9, 1997, Brett L. Hawn wrote: @ > @ > Ok, I'm leasing it, consider my 'sale' of such as sublease, if I'm @ > paying money for it (which indeed I am with ARIN) then I certainly @ > have some rights. @ @ No, that is _not_ what paying ARIN gives you rights to. All you pay @ ARIN for is the registration service, not for the addresses themselves @ (be it a lease or a sale). @ @ > Add to which (and god how I hate sounding like flemming or denniger @ > here but..) who voted them to be the end all be all of IP @ > allocations? @ @ Please don't go there, that's a whole can of worms that has already @ been discussed many times. @ ARIN does not solve any GLOBAL Internet problems. ARIN mostly attempts to solve some internal InterNIC, NSI (SAIC), and NSF problems. If people want to study ARIN, I suggest they do that via <http://www.arin.net> and the proposed ARIN Board of Trustees. IP Address Ownership IS a global Internet issue. In my opinion I would think that it is an important issue for NANOG members. Some suggest that it is not, since it is largely a techno-political issue and not a router failure or network outage problem. In the coming months you will be seeing some interesting news, proposals, products and services coming on the scene. The leadership of NANOG may choose to keep you informed, they may not, that is their choice and your choice. If anyone is interested in discussing IP Address Ownership off-line, you know where I am at in the Caribbean...;-) -- Jim Fleming Unir Corporation e-mail: JimFleming(a)unety.net JimFleming(a)unety.s0.g0 (EDNS/IPv8)

1 0

Re: Class "B" forsale (fwd)
by Scott Bradner 09 Mar '97

09 Mar '97

Bret fumed: -- I could turn around tomorrow and create an MUA that doesn't follow the SMTP RFC except in the most remote cases and whats going to happen? _NOTHING_, why? because RFCs simply are not the GOSPEL, and lets face it, stupid traditions are just that, stupid traditions, this is no longer your cozy little lounge, there are millions of people here and just because you got here first doesn't mean you're allowed to make decisions for the rest of them. -- oh please do - it is a great business plan for you to do that (at least for the rest of us) "standards", standards-track RFCs among them, are generally not "enforced". If I recall correctly many governments tried to do that with GOSIP, sure did that set of standards a lot of good. Some standards are not even perfect. But building to a standard is far better for the consumer (remember twisted- pair Ethernet before the 10BaseT standard?) and better for the vendor. Just because you decide to start building twisted pair Ethernet after the standard was adopted does not mean that it all that good a business plan to do so in a way that is not complient with 10BBaseT. Scott

1 0

RE: Class "B" forsale (fwd)
by Jim Browning 09 Mar '97

09 Mar '97

>From: Michael Dillon[SMTP:michael@memra.com] >Sent: Sunday, March 09, 1997 9:43 AM > >On Sun, 9 Mar 1997, Brett L. Hawn wrote: > >> On Sun, 9 Mar 1997, David R. Conrad wrote: >> >> > > The way I see it, it is worth no more than $10,000. As that is what >> > >ARIN is going to charge any corp to get a Class B. >> > >> > How much is your time (spent making up and writing the justification for >> > a class B) worth? >> >> I think you miss my point, since the ARIN is for all intents and purposes >> selling address space, who are they to say no? > >But ARIN is *NOT* selling address space. That is not the intent of ARIN >nor is it the purpose of ARIN. With that thought in mind, try reading >through the material at http://www.arin.net once again. > >> doing, but I certainly can't say anything 'wrong' about it either. > >Read RFC2050. It has this statement > > 7. The transfer of IP addresses from one party to another must be > approved by the regional registries. The party trying to obtain > the IP address must meet the same criteria as if they were > requesting an IP address directly from the IR. > >> I change all the records to point to them, swip it out to them, basically do >> everything needed to make them the legitimate 'owners' of that block, they >> pay me a nice lump of cash and we're both happy. > >According to that clause above, you can't SWIP it out to them without >lying. Lying is wrong. According to the above clause, the new owner has to >meet the same criteria for receiving address space as you do. If they >did meet those criteria and if you charge them more than the cost of >applying for free address space then you are ripping them off which is >wrong. Internet Service Providers provide a wide variety of services. Among them is loaning the use of IP addresses within the space allocated to them by one of the registries. Some providers are already charging for this service, ostensibly to apply economic forces to the conservation of their allocated space. This practice will certainly increase when ARIN begins charging registration fees. If the owner of the Class B in question allocates the vast bulk (let's say about 100% :-) of the space allocated to them to a single customer, it appears to me that even if this space is inefficiently used (let's say about 0% initially :-), the only recourse the registry has is to withhold future allocations to the "seller". In this case, I believe the seller could care less about that 'penalty', as they would appear to have no need for additional space. What am I missing here? -- Jim Browning

1 0

Re: Class "B" forsale (fwd)
by root＠netreach.net 09 Mar '97

09 Mar '97

This entire discussion reminds me of the way they do business on the streets of New York City when it comes to vendors. It is ILLEGAL to sell a vending license in the city of new york. That, however, does not prevent some enterprising individuals from selling the use of carts to vend goods along with a free license thrown in. It also does not prevent someone from selling not an IP address block, but selling ownership of a company that happens to own an IP address block. The geometric possibilities alone are astounding..... -dave netreach

4 5

RE: Class "B" forsale (fwd)
by Jim Browning 09 Mar '97

09 Mar '97

>From: Vab Goel[SMTP:vgoel@sprint.net] >Sent: Saturday, March 08, 1997 10:18 PM > >>On Sat, 8 Mar 1997, Pete Kruckenberg wrote: > >> What kinds of guarantees are there that if someone buys it, that they >>will actually be able to get and keep this Class B? > >If buyer & seller make a deal, with the current model buyer will be able >to use it without any problem. When what is actually happening differs wildly from documented policies, it is a pretty good sign that something needs to change. RFCs should either be followed or changed. Otherwise a crack is opened which may allow splinter groups to define their own policies in other areas (AlterNIC, etc.) - Jim Browning

2 1

Re: Class "B" forsale (fwd)
by Paul Ferguson 09 Mar '97

09 Mar '97

At 10:01 AM 3/9/97 -0500, Nathan Stratton wrote: > >Next time you rent a car, when you finish driving over the things that can >kill your tires. Just yell to the guy 'Possession is 9/10'th of the law' >and never come back. > Bad analogy. - paul

1 0

Re: Class "B" forsale (fwd)
by Paul Ferguson 09 Mar '97

09 Mar '97

At 06:17 PM 3/8/97 -0700, Pete Kruckenberg wrote: > >I'm just a little curious. If the current policy (as stated by at least >one Draft RFC) is that IP address space is not owned, how can someone sell >a Class B? If they are selling it, that must mean that they don't actually >need it, so therefore they are obligated to return it to InterNIC. On the >other side, maybe InterNIC has an obligation to take it back. > >What kinds of guarantees are there that if someone buys it, that they will >actually be able to get and keep this Class B? > You know what they say, 'Possession is 9/10'ths of the law'. ;-) - paul

3 2

Re: measurement
by randy＠psg.com 09 Mar '97

09 Mar '97

I promised to summarize responses to my query > So who actually measures their network performance and how? As most responses were private, I have removed attribution. Thanks to all constructive respondees. I have proposed a survey panel for the next NANOG if we do not exhaust the subject beforehand. randy - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - We do SNMP polling ever 15 minutes at SESQUINET on every line over which we have administrative control and over every peering point. We produce a daily reports on errors and usage. We are getting ready to switch to Vulture or NetScarf (or some combo) to give us more interactive information. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - We perform measurement of certain basic network parameters, such as usage (bandwidth used / total bandwidth) and line error rates on all of our non-customer links. We perform CPU usage, memory usage, and eviron- mental monitoring of all our routers. We also perform the line usage and error rate on all customer lines. We monitor all of our customers' routers unless they say otherwise, and notify them of any problems. Finally, we monitor select points throughout the Internet (root name servers, etc.) on a 4 times an hour basis using pings. We accomplish this monitoring using the following items an in-house built package that uses SNMP, traceroute, and ping to provide graphs and tabular statistical information. We use cabletron's Spectrum for a quick network overview. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - We do. SNMP MIB-II stuff, plus the cflowd stuff and something we call 'mxd' (measures round trip times, packet loss and potential reason, etc. from a whole bunch of different points in our network to a bunch of other points in our network... we use it to create delay matrices, packet loss reports and other reports). There are some other things, but these are the biggies. I was hoping to get our mxd developer to present at NANOG, but she was unable to attend and is sort of the shy type (too bad, she's one of our better people). Maybe I can throw together some information on what we measure for a bullet or two at ISMA, and why. If there's any interest, that is. The mxd thing was originally just sort of a toy for neat reports, but in the last year it's become a critical tool for measuring delay variance for one of our VPDN customers that does real-time video stuff (and is to some extent helping us figure out where we've got delay jitter and why; on the other hand it's also raising more questions :-)). - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - Since most of my professional career has been in the enterprise world, I can offer you what we used to measure availability to our mail servers, web servers, DNS servers, etc., at one of my previous employers. We employed several application tests, along with network performance tests. Our primary link was via UUnet, a burstable T1. We purchased an ISDN account from another local provider, who wasn't directly connected to UUnet. Probably a good example of a joe-average-user out there. Every 5 minutes, we measured round-trip response times to each of the servers and gateway router (via ping) and recorded it. We also had application tests, such as DNS lookups on our servers, timing sendmail test mails to a /dev/null account, and time to retrieve the whole home page. We trended the results into graphs and used it This wasn't meant to be a really great performance monitoring system; it was actually meant to 1) check how our availability looked from a "joe user" perspective on the net (granted, reachability/availability wasn't perfect because it was only one point in the net) and 2) look at response time trends / application trends to see if our hardware/software was cutting it. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - We use a traffic flow monitoring system from Kaspia Systems. (www.kaspia.com) The Kaspia product collects all sorts of data from router ports and RMON probes, stores the data and performs various trend analysis. We collect traffic flow, router CPU usage and router memory information plus various errors. There is a data reduction process which runs once a day, and a very nifty web interface. The product isn't cheap, but the system definitely fills a void here. Maybe I should organize a talk on what we're doing with it for an upcoming NANOG? As an old instrumentation engineer, I think the basis of our use of the tool is pretty solid. Plus, I actually developed a means for calibration of the accuracy of the flow data. Haven't had time yet to work out a validation for the trends, but I'll get to it one of these decades. Also, the Kaspia people will give you a thirty day trial on their product at no charge. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - It's brain-dead simple, and probably not of real interest to you, but we keep a few basic stats, going back about two years... For non-intrusive stuff, we keep a log of all interface status changes on our routers, and we pull five-minute byte-counts inbound and outbound on each interface, which we graph against port speed. Watching the graphs for any sort of clipping of peaks gives a pretty good indication of problems, and watching for shifts of traffic between ports on parallel paths likewise. As far as intrusive testing, we do a three-packet min-length ping to the LAN-side port of each of our customers' routers once each five minutes, and follow that up with additional attempts if those three are lost. We log latency, and if we have to follow up with a burst, we log loss rate from the burst. Pinging through to the LAN port obviously lets us know when CPE routers konk out, as occasionally we see hung routers that still have operational WAN ports talking to us, likewise, simply watching VC-state isn't a reliable enough indicator of the status of the remote router. Plus it tells you if the customer has kicked the Ethernet transceiver off their equipment, for instance. Wouldn't matter to you, probably, but our demarc is all the way out at their WAN port, since we own and operate our customers' CPE. I think a bit about what more we could be doing; flows-analysis and whatnot... It's nice to think about, and eventually we'll get around to it, but programmer-time is relatively precious, and other things have higher priority, since the current system works and tends to tell us most of what we seem to need to know to provide decent service. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - we do. in fact, we place quite a bit of emphasis on network stats. currently we have about 3 years of stats online, and are working on converting our inhouse engine to an rdbms so we can more easily perform trend analysis. besides kaspia, other commercial packages include trendsnmp (www.desktalk.com) and concord's packages (www.concord.com) our inhouse stuff is located at http://netop.cc.buffalo.edu/ if you are curious about what we do. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - We're neanderthals right now - we use a hacked rcisco to feed data to nocol. We watch bandwidth (separately as well) on key links - and also watch input errors and interface transitions (for nocol) - all done with perl and expect-like routines, parsing 'sho int's every few minutes. Emergency stuff goes through nocol; bandwidth summaries are mailed to interested parties overnight. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - We have running here now the MRTG package that generate some fancy graphics, but in my opinion these graphics are useless and looking in detail to some of the reports they are not accurate, several of our clients request the raw data but this package only mantain few raw data just to generate the graphs, mean also useless. In the past we use to have also a kind of ascii reports (Vikas wrote some of the scripts and programs) generated from information obtained using the old snmp tool set developed by nysernet but I guess that nobody mantained the config files and I believe that the snmp library routines used aren't working fine. So, I need to invest some time to provide a fast solution to this, I'll apreciate your help to identify some useful package or directions about how to generate some good looking and consistent reports. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - We have been using the MRTG package which is basically a special SNMP agent that queries the routers for stats and then does some nice graphing of the data on the web. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - SNMP queries with a heavily-modified version of MRTG from the nice guy in Germany. Works very nicely. We have recently installed NetScarf 2.0, and are contemplating merging NetScarf 3.0 with the MRTG front end. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - I'm researching whether I can rewrite Steve Corbato's fastpoll program using the fastsnmp library from the NetScarf people. I think this will allow fastpoll to scale better. I've successfully written a quick C program that uses the library to collect the required data for a router -- now I've just got to make it so we can manage it easily (i.e. auto-generated config files from our databases). My goal is to be able to collect 1-2 minute period data on all links that are greater than 10 Mbps -- 15 minutes data for everything else. The 2 minute collection period will allow to scale up to 280Mbps before experiencing two counter roll-overs within a polling interval. Hopefully that will hold us over the interface counters are available as Counter64 objects via SNMPv2 (if that ever happens). BTW -- what fastpoll collects now is ifInOctets, ifOutOctets, ifInUcastPkts, ifOutUcastPkts, ifInErrors and ifOutDiscards. Rather than storing the raw counters, it calculates the rate by taking the delta and dividing by the period. Getting the accurate period is actually the hard part -- I'm having SNMP send me the uptime of the router in each query and using that to calculate the interval between polls and to detect counter resets due to reboots. The other trick to handle is the fact that, while IOS updates the SNMP counters for process-switched packets as they are routed, it looks like the counter for SSE switched packets on C70X0 routers only get updated once every 10 seconds. I'll let you know how my tests come out. -30-

1 0

The Class B in Question
by Len Rose 09 Mar '97

09 Mar '97

If I am coordinator does this mean I own it :-) Len # whois 165.90.0 Pagesat Inc. (NET-PAGESAT) Pagesat Inc. 992 San Antonio Rd. Palo Alto, CA 94303 Netname: PAGESAT Netnumber: 165.90.0.0 Coordinator: Rose, Leonard (LR69) len(a)NETSYS.COM 415-233-0441 Domain System inverse mapping provided by: NS1.PAGESAT.NET 165.90.2.2 PAGESAT.NET 165.90.2.3 Record last updated on 12-Jul-94. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information.

1 0