- Test - lists.nanog.org

This frogans thing? Hoax?
by dani＠roisman.com 10 Jul '01

10 Jul '01

I'm sure you've all received your "reserve your frograns address now" emails by now. We're debating internally whether this is an elaborate hoax, or a dot.bomb that hasn't yet run out of VC cash. I'm interested in nanog'ers take on it? - Dani

2 1

OT: The End of Empire
by Mikey Wilsker 10 Jul '01

10 Jul '01

Something to perk up your Tuesday... -- mikey Forwarded-by: Gene Spafford <spaf(a)cerias.purdue.edu> Forwarded-by: David Farber <dave(a)farber.net> Forwarded-by: Stuart Staniford [mailto:stuart@silicondefense.com] Forwarded-by: Shamim Mohamed <shamim(a)languid.org> Darth Vader took two giant strides toward the immense visiscreen that occupied the forward wall of the bridge of his flagship Imperial star destroyer. "We've got them now," he rumbled. Whirling on the technicians cowering at their consoles, Vader snapped, "Tractor beam!" "Yes, Lord Vader," replied one, bending attentively to his task. Then he looked up hesitantly. Vader gestured dramatically at the screen, indicating the fleeing spacecraft. "I want a tractor beam on that ship," he declared. "Now!" The technician busied himself with switches and dials. "Where's that tractor beam?" roared Vader, his voice dark with menace. The other technicians turned frightened eyes on their peer. They knew what happened when Darth Vader's instructions weren't executed instantly. "The tractor beam seems to be down, sir," quavered the technician. "What do you mean down?" Vader inquired with a disturbing silkiness to his voice. "It's not accepting commands, sir," the technician explained. Another technician leaned over and examined the console. "That's odd. The beam itself is showing green," he pointed out. "Yes, I know," agreed the first. "But I'm not getting any acknowledgment to my 'Engage' command." He pressed a button several times to demonstrate. "Maybe the network's down again," suggested a third technician. "Oh, that could be," admitted the first technician. "The network might be down, Lord Vader," he informed the large black figure trembling with rage. "What network?" Vader asked ominously. The second technician jumped in. "Since we've moved to a distributed architecture on the Imperial star destroyers, everything is on a network. It was felt that the direct connections were too unreliable." The third technician added. "The tractor beam is on one of the peripherals sub networks, with the printers and the scanners. It's not on the main weapons network." "Why isn't the tractor beam on the weapons network?" asked Vader, now more puzzled than angry. The technicians exchanged sheepish looks. It was embarrassing to have to point out something so obvious to a superior. The second technician cleared his throat. "Well, sir, the weapons network is a higher priority. It makes more sense to put the less commonly used systems on a separate sub network that has lower QOS." "QOS?" Vader queried. "Hang on a second," said the first technician. "If the network is down, how come we're getting a green light for the tractor beam?" The third technician brightened. "Ah! Maybe the console is retrieving old MIB data and displaying that." "MIB?" rumbled Vader. The first technician answered "We use SNMP to monitor the network elements. When the server queries the element, it stores its current status. If the network goes down, it can't query the element anymore, and all you have is the latest status in the MIB." He turned to the other technicians, musing. "We really should have an indicator of when the last successful query was, instead of just a green or red light." "Good idea," said the third technician. "I'll call tech support." "Say," said the second technician. "How about if we ping the tractor beam? Let me bring up a telnet window." "Telnet?" asked Vader, now obviously confused. "Ping?" The first technician glanced briefly at Vader, a little annoyed at the interruptions. Why couldn't this guy keep up with the service bulletins? "The system runs Unix, but the consoles run NT 5000," he replied with exaggerated patience. "You need a telnet window to ping the element." He turned his attention back to the screen. "That's strange. It comes back 'active'. Listen, when you get tech support tell them we can't engage the tractor but we can ping it." "Right," said the third technician. "I'm still on hold." "Here's a thought," said the second technician. "What if we just call the guys down at tractor control and have them engage the beam manually?" Vader seemed to brighten up at this, and swiveled his head from one to another. "Good idea," said the first technician. He lifted his communicator and tapped the switch several times. "Nothing," he said. The second technician shook his head. "Didn't we tell them we couldn't do voice and data with that little bandwidth?" Suddenly Vader noticed the visiscreen and let out a bellow of anger. "They're gone!" he boomed. The third technician looked up smiling. "Hey, I got tech support!" -- .--------------------------------------------------------------, |Michael Wilsker Director, Network Engineering | |mikey(a)interpacket.net and Operations | |Tel: +1.310.382.3344 ,---------, Verestar, Santa Monica | '-----------------------' `--------------------------' "Satellite in my eyes - Like a diamond in the sky" - DMB

1 0

space wanted in 1220 L, 25 Broadway and 60 Hudson
by alex＠yuriev.com 10 Jul '01

10 Jul '01

Hello, I am looking for (1/4 rack to 1 rack) in 1220 L in DC and 25 Broadway in NYC, and 60 Hudson in NYC. If anyone has any pointers, I would greatly appreciate it. Should one be a sales person, please feel free to contact me for RFQ. Thanks, Alex

1 0

Getting an AS and /18
by Andy Ellifson 10 Jul '01

10 Jul '01

I have a customer that is a cable modem provider. They submitted the form to request an AS and some address space. The response from ARIN wanted a ton of documentation. I understand why ARIN requires all of the documentation. Does ARIN require a ton of SWIPS be present for the customer before they will issue address space? This customer genuinely needs the address space but doesn't have the time to gather up all the information that is 'required'. Does anyone know of a person they can talk to at ARIN to help with this process? -Andy Ellifson __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

21 29

Cisco RFC1997 implementation clarification.
by John Fraizer 10 Jul '01

10 Jul '01

While researching an RFC1997 issue this morning, I made the following observations: According to RFC1997: " Well-known Communities The following communities have global significance and their operations shall be implemented in any community-attribute-aware BGP speaker. NO_EXPORT (0xFFFFFF01) All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself). NO_ADVERTISE (0xFFFFFF02) All routes received carrying a communities attribute containing this value MUST NOT be advertised to other BGP peers. NO_EXPORT_SUBCONFED (0xFFFFFF03) All routes received carrying a communities attribute containing this value MUST NOT be advertised to external BGP peers (this includes peers in other members autonomous systems inside a BGP confederation). " On Cisco's site at http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_… I find the following: " internet - Advertise this route to the Internet community. All routers belong to it. no-export - Do not advertise this route to EBGP peers. no-advertise - Do not advertise this route to any peer (internal or external). local-as - Send this route to peers in other sub-autonomous systems within the local confederation. Do not advertise this route to an external system. " Unless I'm mistaken, there are some potential interop issues with this. CISCO no-export = RFC1997 NO_EXPORT_SUBCONFED CISCO no-advertise = RFC1997 NO_ADVERTISE CISCO local-as = RFC1997 NO_EXPORT Can someone more familiar with the RFC1997 implementation in IOS comment on this? Thanks, --- John Fraizer EnterZone, Inc

2 1

Re: The MSN Messenger
by Moe Allen 09 Jul '01

09 Jul '01

Well, we are one of those small ISP's. Our company, over the past 6 years, had an association with a larger ISP. This larger ISP had customers in a Metroplex area as well as customers in South America. If you believe in the old adage, all things are equal, when everyone is running the same two programs (MSIE & Netscape) and same type of equipment, then the percentage of trouble tickets would be the same in a small ISP as it would be in a large one. On one occasion the President of the larger ISP call and ask if I could come down for a meeting. So I did. The main topic of this meeting was, why were we having less customer complaints, than the big boys. Both companies were handling everything the same. My answer was, we started a Help Desk. Everytime something went wrong, I sent out an e-mail. The e-mail detailed the problems and how long I thought it was going to take to fix. If during the repair, we found it was going to be longer, I sent another e-mail to our customers. Upon repair, I sent another e-mail and explained the problems and include, if the repair was a band-aid or a solid repair. I also e-mailed our group about planned outages, C&W problems, etc. Well it have been 6 years and I am still writing the e-mails. But now, we call the "Vidnet -- Alerts" In our last poll, I asked if our customers wanted the "Alerts" stopped. To my surprise, a 100% of the users that replied stated, "No, keep up the good work." So, I don't believe you can go wrong, if you keep your customers informed. It doesn't matter if you are an ISP or a Software Company. The more information you can supply to the customer, the happier the customer. Even if they don't understand everything in the e-mail... Respectfully, Morris Allen President VidcomNet, Inc.

2 1

IN-ADDR.ARPA Progress Report
by ARIN IN-ADDR Role 08 Jul '01

08 Jul '01

Goal: Reduce the size of the IN-ADDR.ARPA zone file. This file will be reduced in size by only containing name servers for /8 networks. Completed Steps: Apr 2001 - Established relationships with 2 companies to provide independent server networks for all ARIN IN-ADDR zone files. Jun 2001 - Released a new IN-ADDR.ARPA zone file generator to correct existing erroneous data. Next Step: July 9, 2001 - ARIN will begin revising the IN-ADDR.ARPA zone for those direct /8 delegations to ARIN. These /8 zone files will be serviced by the two ARIN nameserver networks. These changes will not affect the performance of reverse lookup in any of the IPv4 Address space. Please direct any questions to inaddr(a)arin.net. Ginny Listman Director of Engineering American Registry for Internet Numbers

2 1

The MSN Messenger
by Sean Donelan 07 Jul '01

07 Jul '01

Since it is always difficult to predict how long it will take to fix a problem, the question for the PR people always is: Do you say as little as possible, hoping it will be over soon? The problem with this strategy is if your problem continues for a long time, you look incenitive or even incompetant. Do you confirm you have a problem, and provide customer updates? The problem with this strategy is you draw attention to minor issues, which few people would have noticed otherwise. After four days, Microsoft finally added a statement to their MSN Messenger web site. I guess Microsoft's PR people decided they couldn't make things worse at this point. > July 6, 2001/8:00 pm PST > > MSN Messenger is currently experiencing a service outage for many > customers on a worldwide basis. We wholeheartedly apologize for the > inconvenience you may be experiencing. Our operations team is working > diligently to restore full service (including restoration of all > personal contact lists) as soon as possible. We are working around > the clock to have MSN Messenger up ASAP. We expect to have the service > restored by the end of the day today. Please continue to check back > for updated status reports. Thank you for your patience. > > The MSN Messenger

3 2

The Cidr Report
by Tony Bates 07 Jul '01

07 Jul '01

This is an auto-generated mail on Fri Jul 6 23:00:00 PDT 2001 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 GX Networks 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 06Jul01 0) General Status Table History ------------- Date Prefixes 290601 100654 300601 101008 010701 100929 020701 100843 030701 101022 040701 101049 050701 100922 060701 101036 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: 11154 Number of ASes announcing only one prefix: 6601 (3771 cidr, 2830 classful) Largest number of cidr routes: 1007 announced by AS701 Largest number of classful routes: 1423 announced by AS701 1) Gains by aggregating at the origin AS level --- 06Jul01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1342 1000 342 25.5% UNKNOWN AS701 1423 1209 214 15.0% UNKNOWN AS4293 394 282 112 28.4% UNKNOWN AS6595 158 57 101 63.9% UNKNOWN AS7018 743 651 92 12.4% UNKNOWN AS6429 201 109 92 45.8% UNKNOWN AS705 225 134 91 40.4% UNKNOWN AS4755 207 122 85 41.1% UNKNOWN AS4151 159 77 82 51.6% UNKNOWN AS8013 298 218 80 26.8% UNKNOWN AS13999 94 15 79 84.0% UNKNOWN AS724 246 172 74 30.1% UNKNOWN AS577 247 174 73 29.6% UNKNOWN AS6471 118 55 63 53.4% UNKNOWN AS3464 152 90 62 40.8% UNKNOWN AS7046 306 245 61 19.9% UNKNOWN AS1 584 524 60 10.3% UNKNOWN AS16758 63 6 57 90.5% UNKNOWN AS1239 446 391 55 12.3% UNKNOWN AS226 144 91 53 36.8% UNKNOWN AS6413 65 13 52 80.0% UNKNOWN AS3908 205 154 51 24.9% UNKNOWN AS17561 112 61 51 45.5% UNKNOWN AS852 211 161 50 23.7% UNKNOWN AS2149 323 273 50 15.5% UNKNOWN AS9842 54 5 49 90.7% UNKNOWN AS12302 79 30 49 62.0% MobiFon S.A. AS5106 81 33 48 59.3% UNKNOWN AS15290 237 191 46 19.4% UNKNOWN AS3602 221 176 45 20.4% UNKNOWN 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

Building NOCs
by Timothy Brown 06 Jul '01

06 Jul '01

Hi NANOG, hope everyone had a great July 4th. Our operation is at a stage where it's time to really invest some money in building a classy network operations facility. Our data center functions are handled seperately, so at this time, this is merely a place for housing operations staff. I've searched the cctec archives and found a few really old threads regarding how to tackle the NOC building process. We're a systems house, but I imagine the principles exist along the same lines. Obviously, some of the principles from building data centers apply here - i'm not totally out of my depth. I've thought about things like lighting, ergonomics, information sources, phones, power, environmental, etc. What i'm really looking for from the community are a) links to manufacturers of good NOC gear, b) recommendations on the above, and c) financial worksheets detailing cost proposals, if any. In addition, any contractor suggestions would be greatly appreciated. When I say NOC gear, what I really mean is NOC furniture, large information displays, and guidance/standards on how to build facilities. It's been a long time since i've done this sort of thing on any kind of a serious level. Since I know that some of the information i'm requesting is proprietary, feel free to eliminate the names of the accused and reply privately off-list. I'll summarize if it looks necessary. Thanks, Tim

2 1