March 1997 - Test - lists.nanog.org

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 08 Mar '97

08 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 08 Mar '97

08 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

RE: Remote Operations question
by Rodney Joffe 08 Mar '97

08 Mar '97

Thanks Alex...... As far as why........ well let's see; when the router gets hosed in our cage, and we open a ticket with MFS, and it takes 5 hours before they arrive..... it seems a lot more logical to be able to power cycle it out of band without waiting. Now if MFS's facility was truly a 24 x 7 facility, which you would expect for a place that was that important :-) By the way, your $500 is much less than the last bill they sent us ... $750. Amazing... and we didn't even see the gun in their hands. Rodney Joffe Genuity Inc., a Bechtel company http://www.genuity.net >-----Original Message----- >From: Alex Rubenstein [SMTP:alex@nac.net] >Sent: Saturday, March 08, 1997 4:22 PM >To: Rodney Joffe; 'nanog(a)merit.edu' >Subject: Re: Remote Operations question > > >Leviton has some stuff the we use, they have some things that can do 20 amps. > >The better question; why? What is the 7513 doing that you need it to be >rebooted? I can be paid to go do it for you; lets say, $500 ea time? :-) > > >At 04:18 PM 3/8/97 -0700, Rodney Joffe wrote: >>Is anyone using any kind of out of band controlled power system that >>will support remote power cycling of multiple devices with high power >>ratings? I'd like to be able to cycle individual components in our racks >>at NAPs (especially MAE E!) including 7513s. All the devices we've >>found are limited to 15 amps total. I think a 7513 requires 20amps on >>its own. >> >>Thanks >> >>Rodney Joffe >>Genuity Inc., a Bechtel company >>http://www.genuity.net >> >> >>

1 0

Re: Remote Operations question
by Alex Rubenstein 08 Mar '97

08 Mar '97

Leviton has some stuff the we use, they have some things that can do 20 amps. The better question; why? What is the 7513 doing that you need it to be rebooted? I can be paid to go do it for you; lets say, $500 ea time? :-) At 04:18 PM 3/8/97 -0700, Rodney Joffe wrote: >Is anyone using any kind of out of band controlled power system that >will support remote power cycling of multiple devices with high power >ratings? I'd like to be able to cycle individual components in our racks >at NAPs (especially MAE E!) including 7513s. All the devices we've >found are limited to 15 amps total. I think a 7513 requires 20amps on >its own. > >Thanks > >Rodney Joffe >Genuity Inc., a Bechtel company >http://www.genuity.net > > >

1 0

Remote Operations question
by Rodney Joffe 08 Mar '97

08 Mar '97

Is anyone using any kind of out of band controlled power system that will support remote power cycling of multiple devices with high power ratings? I'd like to be able to cycle individual components in our racks at NAPs (especially MAE E!) including 7513s. All the devices we've found are limited to 15 amps total. I think a 7513 requires 20amps on its own. Thanks Rodney Joffe Genuity Inc., a Bechtel company http://www.genuity.net

1 0