July 2001 - Test - lists.nanog.org

Bush plan would revamp Net security
by Mitch Halmu 17 Jul '01

17 Jul '01

Very interesting article on c|net: Bush plan would revamp Net security http://investor.cnet.com/investor/news/newsitem/0-9900-1028-6594259-0.html?… --Mitch NetSide

1 0

Re: Utilization of the redundant ring in SONET
by Frank Coluccio 17 Jul '01

17 Jul '01

Some WAN Carriers make their 'protection' bandwidth available to ISPs and other takers on a preemtable basis. That is, when a ring failure occurs the protection bandwidth is reclaimed, or preempted, by the carrier for restoration purposes, thus "bumping" the original occumpant (you) into the ditch. Since this type of bandwidth comes at a discount, one has to weigh the operational risks (SLAs?) against the financial tradeoffs, which is what I suspect you are doing. It isn't all that bad if used in a straightforward mesh topology, or one where one for one link protection is used, because the ISP will normally design to recover their mesh through regular Layer 3 routing routines, anyway. It can get out of hand, however, if the particular ring in question is having intermittent troubles, causing the ISP to encounter an undesirable number of convergences per unit of time (hours, day, week, etc). > Hello: > > I would like to know how typical it is to have the redundant ring in > SONET used for the transport of data while still providing protection > switching features. Also, could any one give me insight into a few > vendors that does it. I would appreciate, if some one could provide > input on the above. > > Regards, > > Srihari Varada > > >

1 0

Public peering points in the Detroit, MI Area
by John Palmer (NANOG List) 17 Jul '01

17 Jul '01

Are there any public peering points in or around Detroit, MI?

6 5

Maintaining a central config database
by David Curran 17 Jul '01

17 Jul '01

I was wondering if anyone had any pointers on how to go about maintaining a central repository for various router configs. Specifically what I'm looking for is a way to keep access-lists, route-maps, prefix-lists, etc. in a central "store" and either push that info out at boot time or have the router request it. Any info would be appreciated, -david

2 1

Open Peers at MAE-Central
by Lee, Hansel 17 Jul '01

17 Jul '01

Does anyone have an list equivalent to the list below for MAE-Central? Thanks, Hansel -----Original Message----- From: Pete Ashdown [mailto:pashdown@xmission.com] Sent: Thursday, June 28, 2001 12:46 To: nanog(a)merit.edu Subject: Open Peers at PAIX What follows is a list I compiled of organizations at PAIX who peer without restrictions. Restrictions are "requirements" like nationwide or international OC-48 backbone, 45Mbit minimum traffic, four geographically disparate peering locations, bicoastal peering, and a standing seat on the Trilateral Commission. These restrictions are impossible for a small network like my own to fill. Usually by the time I am financially able to meet these restrictions, new ones have been crafted in their place. This list was compiled after an exaustive attempt to contact and peer with everyone participating at PAIX. The PAIX organization is unable to compile such a list, as it would violate their neutrality. I, however, am interested in peering with anyone and anything at PAIX, and I would presume that most networks who have made an investment to get there, would actually want to utilize their equipment. Without rehashing the endless debate on open peering, I believe it is more productive to promote the networks who are open peers, so time is not wasted filling out NDA's and applications only to be told, "No." I have only listed participants who are actively peering with me now. Several are still awaiting equipment and transit and have reacted positively to my requests. Also, I have not listed a particular network whom with I have peered for over two years. They have decided to place a "bicoastal restriction" on peering, and they are actually going through and depeering with former peers. This hasn't happened to me yet, but I'd imagine after this email, they'll accelerate their isolation. If anyone has any corrections or additions to this list, please email them to me directly. I will send this list to NANOG periodically unless there are major objections. Organization IP address AS# Email contact Vixie Enterprises 198.32.176.3 3557 noc(a)unnwo.net AboveNet 198.32.176.11 6461 noc(a)above.net DSL.net Santa Cruz 198.32.176.13 4436 admin(a)tycho.net Exodus 198.32.176.15 3967 peering(a)exodus.net Hurricane Electric 198.32.176.20 6939 mleber(a)he.net U-Net 198.32.176.22 5669 aid(a)u-net.net ValuServe 198.32.176.28 6123 noc(a)valuserve.com Global Crossing 198.32.176.29 3549 peering(a)gblx.net I.Net Technologies 198.32.176.30 3976 noc(a)nuri.net Lightning Internet 198.32.176.34 6427 noc(a)cp.net Critical Path 198.32.176.37 10627 wayne(a)criticalpath.net WebTV 198.32.176.39 6469 soc(a)corp.webtv.net XMission 198.32.176.42 6315 peering(a)xmission.com DACOM Corporation 198.32.176.43 3786 peering(a)bora.net Maxim Computer Systems 198.32.176.45 11388 peering(a)maxim.net PFM Communications 198.32.176.48 4513 help(a)pfmc.net SingTel 198.32.176.50 7473 peering(a)ix.singtel.com Zocalo 198.32.176.53 715 peering(a)zocalo.net KDDNet 198.32.176.65 2516 peering(a)kddnet.ad.jp WinterLAN 198.32.176.73 5081 noc(a)winterlink.net Hanaro Telecom 198.32.176.75 9318 peering(a)hanaro.com Hotmail 198.32.176.77 12076 dmcgilli(a)microsoft.com ViaNetWorks 198.32.176.80 7091 noc(a)via-net-works.com Open Data Network 198.32.176.86 4725 as-admin(a)gw.odn.ad.jp Digital Island 198.32.176.99 6553 mrose(a)digisle.net StarNet 198.32.176.100 6316 peering(a)starnetusa.net Electronic Arts 198.32.176.107 14891 rcortez(a)ea.com Sunrise Communications 198.32.176.110 6730 helpdesk(a)sunrise.ch Open Data Network 198.32.176.115 4725 as-admin(a)gw.odn.ad.jp Advanced Telcom Group 198.32.176.116 6971 peering(a)atgi.net DirecTV Broadband 198.32.176.119 12050 peering(a)telocity.net Nominum 198.32.176.120 17204 peering(a)nominum.com Thrunet 198.32.176.122 9277 noc(a)eng.thrunet.com Akamai 198.32.176.127 12222 peering(a)akamai.com One Call Communications 198.32.176.133 6402 rirving(a)onecall.net SITA Equant 198.32.176.140 2647 Juan.Vadillo(a)sita.int Compaq 198.32.176.241 33 noc(a)compaq.net Compaq 198.32.176.242 33 noc(a)compaq.net Internet Mainstreet 198.32.176.249 3856 woody(a)pch.net RSNG 198.32.176.251 178 rsngpeer(a)rsng.net RSNG 198.32.176.252 178 rsngpeer(a)rsng.net

1 0

Building a new NOC: Summary
by Timothy Brown 17 Jul '01

17 Jul '01

Hi folks! Several people asked for my summary of information I learned in the NANOG thread "building a new NOC" - I decided to assemble the summary and post it here, since enough people seemed to want it. I learned about several contractors who do NOC buildouts. To avoid seeming like a plugger, I won't give their names here. If you want the names of the contractor list i've assembled, please e-mail me privately. There were three major vendors of furniture that seemed to provide NOC-level stuff. APC-Wrightline, SMC, and Evans were the people that seemed to make items specifically built for use in an IT center or a NOC. I don't know where they compare on price; we're going through the process with each to determine who is the best bet. Evans by far seems to make the nicest furniture, though. I wasn't all that impressed with APC. Obviously a lot of the considerations for building a NOC come down to where you are building it at. Several people consider the same criteria for NOCs as they do for datacenters: Things like earthquake protection, good power, redundant everything, HVAC, etc. Several people also mentioned that you want to be careful that the building you're building your NOC in isn't required to use union labor, since that ups the cost significantly. For our NOC, we considered the following criteria: * Breakrooms * Lighting * Sleeping areas * Televisions and projection screens * Consoles with "roaming" capability - leave any console and move to another * Access control in and out of the facility * Laptops: For those people who must leave the NOC and go to a customer immediately * Whiteboards and conference rooms, inc. conference phones * Good chairs, keyboards, and required breaks for NOC personnel I roughly use the criteria of 50-100 machines/clusters per on-duty engineer (we're a systems shop). There's at least one senior engineer on staff for each shift. This probably varies widely among NANOG NOC managers. I considered several projector manufacturers. I haven't gotten all the way down to the lower level of detail on the projector scene, but we are told by an AV guy we're retaining that we should buy something between 700 and 1400 ANSI lumens. The big, 3000-3400 lumen units will run about $15K, and will project about 100+ ft in bright sunlight - obviously not necessarily for our purposes. The less lumened units, when placed closer to your projection screens, will provide more sharpness and clarity. (Any comments from AV people?) DLP projectors are the way to go. We're ordering three projectors. I'm still looking for either software or hardware that will allow me to multiplex PC signals onto one projector, and looking for what NOCs use to control the machines the projector is on. If anyone has info on this stuff, please let me know. In my pricing sheet for CFO consumption, I included the common items as well as the expensive technology stuff. We decided to include things like blankets and pillows. Rather than buy cots (there are lots of lumpy NOC people, like myself) we chose to build bunks out of sheets of plywood, and just lay the standard bed mats you find at camp stores over them. NOCs usually have pretty good AC, so we included lots of blankets. Cold and tired engineers have a hard time working - we included a fridge, a good microwave, and nice coffee machines. I'm getting into minutiae[sic] here. Our layout was for seven operators and three senior engineers. The engineers are officed behind the NOC people, with a good view of the screens through windows in their area. There's a dedicated staircase just to this room, to avoid traffic. The room is very low-light - just enough to see where you're going. We haven't decided on lighting fixtures yet, even for the overheads, but I think we've all come to the conclusion that we're just going to install some soft track lighting and let the engineers decide what kind of task lights they want over their consoles. The consoles are arrayed in such a way that even though they curve well so that everyone can see the screen, there is some privacy in the two-monitor setup we have. I chose Sun's line of Sun Ray workstations. These are really cool machines, folks. It's basically a dumb X terminal with a smart card reader - you take your smart card out, move to another machine, and your desktop is right there with no loss of anything. You can show another engineer something just by running your card over to his workstation. This was critical - in a shifted environment, you want everyone to have their own space. NOC people are picky. The workstations provided a good mix of that stuff. Fairly cheap, too. Everyone gets their own locker, including the senior engineers, to store personal items. We have a rule that nothing personal comes into the NOC except for books and cell phones - this keeps our engineers working. There is some music service available from an MP3 library, but there isn't any audio CD stuff on the workstations. The Sun Ray stuff really only seems good for terminal serving, and it requires its own segment. We run all our applications via tunneled SSH to separate PC or SPARC servers running Linux or Solaris. This helps us so that nobody can screw up the terminal server by installing software or changing parameters - everyone pretty much gets redirected to an appropriate machine upon login where they do their sandbox stuff. One thing I did like about the Sun Ray setup is that it does voice over IP. When you plug in your smartcard, your phone and voicemail also gets redirected to that location. It remains to be seen whether we'll use this solution, but I thought it was appropriate for NANOG consumption. I didn't really skimp on ergonomics. Since there is a high turnover in NOC personnel, we included every creature comfort we reasonably could. This includes Playstation 2 and Dreamcast, DVD, and large-screen TV with DSS for the guys. They're required to take 20 minute breaks every two hours, not including any Nazi bathroom permission or anything like that. This keeps them loose and relaxed. That rule isn't violated, even if everything's falling down around our ears. Personally, I think the biggest investment we make in the NOC is in people and creature comforts. The second biggest investment is in standard operating procedures - don't make people think if they don't have to. Make sure you invest on training your folks right when they come in. This is probably old hat to lots of you, and it's old hat to me, but it doesn't hurt to mention it. The hardest thing in a NOC is to make sure that things are kept quiet so that everyone can work, and make sure that the business types don't bring people in for tours without approval and/or scheduling. You don't want people walking through your NOC when there's a problem, whether it's obvious or not. I'm going to be building a web page to contain all of this information, as well as a mailing list, over the next couple of weeks. I'll post when available. Thanks very much to Brennan Murphy @NAI, Derrick Daugherty, Matt McGuirl, the folks over at NOCbuilder, and herb(a)tomobiki.urusei.net for excellent commentary and help. Thanks also to everyone else who contributed privately - there were so many responses. Tim

1 0

RE: When will 128M not be enough?
by Roeland Meyer 16 Jul '01

16 Jul '01

> From: Andy Walden [mailto:andy@tigerteam.net] > Sent: Sunday, July 15, 2001 3:02 PM > A unique situation such as the CW/PSI mess would > have called for a prefix filter tweak, which, albeit, not automatic, relatively > painless on a small scale (i.e, you don't have to change hundreds of > customer routers because they don't have the talent themselves). I disagree that the CW/PSI mess is unique. My analysis leads me to think that it might be a foreshadowing. Many of the mid-tier ISPs, and some of the larger ones, are over-extended on growth and short on revenue. They were caught by surpise, just as much as the rest of us, when the dot-com market tanked. That sucking sound you hear is the rest of us being dragged in. Those of us that have enough bank-cash to hold onto and sufficient revenue to resist the pull, will be successful. Two points, the DSL market (RBOCs are moving in) is soft and the wireless ISP market is soft (I hope Ricochet survives). The point is that one cannot assume that PSInet will be the last of those. The failure-mode is exactly the same as that for WebVan, excessive (debt funded) growth, excessive burn-rate, not enough revenue, and too long to ROI (not enough cash in the bank to last until profitability). Many ISPs are slicing the baloney so thin that you can see daylight through it. No one expected the market to collapse and impact revenues the way that it has. Couple this with a market that is used to getting everything for free and you have a major problem brewing. Monetizing such a customer-base is very much harder to do, than to say.

3 2

Viewpoints on how to handle errors
by Sean Donelan 16 Jul '01

16 Jul '01

Two viewpoints on handling a major outage, and dealing with the consequences of your mistake. Handling Even Your Big Glitches Gracefully http://www.washtech.com/news/atwork/11178-1.html Nasdaq: Outage Not Likely To Recur http://www.internetweek.com/story/INW20010711S0005

1 0

Re: When will 128M not be enough?
by rs＠seastrom.com 16 Jul '01

16 Jul '01

"Majdi S. Abbas" <msa(a)samurai.sfo.dead-dog.com> writes: > On Sun, Jul 15, 2001 at 09:41:05PM -0400, Christopher A. Woodfield wrote: > > True, I prefer $30 after rebate from Circuit City... :) > > Not for a 2650, you don't. > > cisco 'fixed' that particular problem. yeah, now you have to buy it from kingston, crucial, or transcend instead of buying true-ghetto off the shelf memory. only $131.00 from kingston for the KCS-D2650/128. oh the humanity! ---rob

1 0

RE: how to handle peering fights
by David Schwartz 15 Jul '01

15 Jul '01

> I must respectfully disagree: better in my opinion is > to receive partial routes from multiple providers > (specifically, the providers' own routes), and then > keep a default route to your least-used provider. If > you discover that some particular address isn't > reachable, direct the traffic elsewhere. The real > solution is to pay attention, and make sure that > you're aware of what your providers are doing: peering > loss between providers isn't nearly as bad as complete > business failure, although they can both be as deadly. You are fixing the example, rather than the problem. > My contention is that it's substantially more > effective (both in terms of cost and results) to use > human intervention to resolve this type of problem > rather than rely on an automatic system. There were > warnings before the whole C&W/PSI fiasco, and this > seems to be the rule rather than the exception. For the C&W/PSI fiasco, yes. For other types of connectivity losses, probably not. Some may only last for a few hours, by the time you respond, the problem is over. Without full routes from at least one provider, how can you tell what traffic is affected by the fiasco even if you know about it? You often can't just take customer routes and point default away from a link with a problem like that because so much traffic takes the default route that your other link(s) would be too heavily loaded. (Of course, if your providers are large, this is less of a problem since customer routes will cover more of your traffic). Wven having full routes won't help you when your provider sends you routes it can't actually handle traffic for. Sometimes, a sick router is too sick to withdraw routes, but it can still take an awfully long time for the BGP session(s) to it to break. If you have a lot of delay-sensitive traffic, taking full routes can also result in a performance improvement. Also, taking shorter routes generally means taking more reliable routes as there are fewer points for there to be problems that might not be reflected in the BGP routes (like a sick router, overloaded link, or misconfigured filter). I wasn't trying to start an argument about how to deal with peering fights, really. I was just trying to voice the other side of the 'no need to take full routes' fight. DS

1 0