- NANOG - lists.nanog.org

Carpet?
by Charles Sprickman 28 Oct '98

28 Oct '98

Hi, This is a bit off topic, but I'm sure someone here has opinions to share... I'm looking for carpeting for the area outside of a machine room that won't cause the "shuffle your feet and shock yourself" phenomenon. I noticed most datacenters I've seen are carpeted up to the entrance without any ESD problems. Is there special "anti-ESD" carpet? Where might I find it? Thanks, Charles =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork(a)inch.com access(a)inch.com | = =----------------=

11 12

RE: Route Leaks
by Bono, Vinny J (CORP, ITDG) 28 Oct '98

28 Oct '98

I hate to say it, but there are, uh, instances, where AS filtering would not come close to being enough. For example, if you had an IGP involved that runs between two border routers, and the external table from one router somehow gets redistributed into the IGP and then picked up by the other and gets passed on, all the routes go out *without any previous AS path information*. -The pain now surfaces- Further, if you have one of these new fancy rotuing switches that essentially runs a different routing process on each blade (gee, like the BNx platforms from Bay used to do) you could (theoretically of course) have a pair of such blades do what I described above all in one box! The bottom line is that what happened last week end happened to us two years ago, and to PSI the year before that. This is not a new problem. Unless you are using the routing registries, which can get to be a royal pain in the ass, we are all somewhat dependant on our fellow will filter their outbound announcements appropriately. -vb > -----Original Message----- > From: Sanjay Dani [mailto:sanjay@professionals.com] > Sent: Wednesday, October 28, 1998 2:57 AM > To: vbono(a)comstor.com > Cc: nanog(a)merit.edu > Subject: Re: Route Leaks > > > > > I'd like to propose a simple solution to the class of route > leak we've > > recently seen. > > I'd like to encourage our peers to put a simple filter in > place. If you > > peer with AS > > 3561, please do not accept any route with AS 3561 in the path from > > either your > > customers or your other peers. > > I feel almost silly to point out a simple solution, an extension > of the above, to the smart crowd here. But doesn't every one > at the very least filter routes from peers/customers to reject > ASes 701, 3561, 1, 1239 et al. (unless of course the peer is > one of them). Minimizes the damage right away. Of course, not > as tight as using routing registries. Has saved us a few > times. > > Now that is a positive side to the industry with a handful > few huge, transit-free, players. Just watch the mergers > and acquisitions news to stay current :-) > > -- > Regards, > Sanjay. > > --------------------------------------------------------------- > Web Professionals, Inc. Direct: +1 408-863-4850 > 20111 Stevens Creek Blvd, Suite 145 Biz/NOC: +1 408-863-4848 > Cupertino CA 95014 USA http://serverhosting.net > --------------------------------------------------------------- > -=- Data Center Server Hosting Inside an Internet Exchange -=- > >

1 0

RE: CISCO Easter Egg
by Martin, Christian 28 Oct '98

28 Oct '98

I laughed at that too. Anyone from Cisco want to claim this? ;) Chris > -----Original Message----- > From: Sam Etler [mailto:etler@cs.wisc.edu] > Sent: Wednesday, October 28, 1998 10:48 AM > To: Martin, Christian > Cc: 'nanog(a)merit.edu' > Subject: Re: CISCO Easter Egg > > > > Oct 28 02:35:25 EST: %IPC-2-NOMEM: No memory available for > .. something > > but I ca > > n't remember what.. > > > > The command is 'test ipc misc' > > typing 'test ipc ?' gives a menu with the following in it: > > misc Misc. Software Tests Du Jour > > cute. > > Sam Etler > UW Madison > CSL Networking > >

1 0

RE: UU Net sales tactics?
by Chris Mauritz 28 Oct '98

28 Oct '98

I've only been cold called by UUnet once. Digex was aggressively cold calling me a few months ago. I had been speaking briefly to Level3 (and decided not to use them), but another L3 person cold called someone else in our organization to sell colocation services at approximately the same time. Chris -----Original Message----- From: john(a)ciag.net [mailto:john@ciag.net] Sent: Wednesday, October 28, 1998 8:10 AM To: nanog(a)merit.edu Subject: UU Net sales tactics? Has anyone else received a phone call from a UUnet salesman out of the blue? It appears that he used the Boardwatch magazine, because he quoted me some information out of it about my company. I simply can not believe the egos they have. I will never do business with UUnet, with this or any other company I am with. I use Fiber Network Solutions currently and am very happy with the service. Todd and Kyle are excellent at what they do. The comments that peaked my anger the most were. "Im sure companies as small as yours would b content with someone as small as Fibernet" When I stated to them that their company is one of the most expensive T1 providers, he responded with "Not every company is able to afford the best Internet that can be offered" (implying UUnet is directly that). Any comments or stories that can be shared?

1 0

RE: root name servers
by Kamau Wanguhu 28 Oct '98

28 Oct '98

How about the other ones from L-M where are they "physically" located? ---- Kamau Wanguhu Cambridge Research Lab Compaq Computer Corporation kamau(a)crl.dec.com <mailto:kamau@crl.dec.com> +1.617.692.7613 > -----Original Message----- > From: Phil Howard [mailto:phil@whistler.intur.net] > Sent: Wednesday, October 28, 1998 09:34 > To: jra(a)scfn.thpl.lib.fl.us > Cc: nanog(a)merit.edu > Subject: Re: root name servers > > > Jay R. Ashworth writes... > > > On Tue, Oct 27, 1998 at 08:29:43AM -0800, > bmanning(a)vacation.karoshi.com wrote: > > > > anybody knows the physical location > > > > of all root name servers, or a pointer ? > > > Is it really important? > > > > The sort of person who wants to know this is roughly the > same sort of > > person who is interested in knowing that the AT&T Startum 1 > clock is in > > Hillsboro MO. > > > > You know: geeks. :-) > > OTOH, some of us don't care about those root servers because > we already > know where our own root servers are. All but one of my DNS > servers are > grass roots servers. You can take down all the root servers, > and if that > didn't also take out the TLD (e.g. .COM, .NET, .ORG, .GOV) > servers, then > I won't notice it much (except to wonder why there is a dropoff in my > load on smtp and http). > > BTW, knowing where the main root servers are topologically is probably > more dangerous than knowing where they all are physically. > And that is > information most everyone already has. > > -- > -- *-----------------------------* Phil Howard > KA9WGN * -- > -- | Inturnet, Inc. | Director of Internet > Services | -- > -- | Business Internet Solutions | eng at intur.net > | -- > -- *-----------------------------* philh at > intur.net * -- >

1 0

Re: Linux router (don't laugh) WAS:Re: test
by John Fraizer 28 Oct '98

28 Oct '98

It's a pentium 150 with 64Mb. Overkill for memory: [root@core0-eth0]:~ # free total used free shared buffers cached Mem: 63184 7720 55464 6228 1092 3520 -/+ buffers/cache: 3108 60076 Swap: 68508 0 68508 At 05:37 PM 10/27/98 -0500, William F. Maton wrote: >On Tue, 27 Oct 1998, John Fraizer wrote: > >> Routing 3 /24's and a /26 using 3 3c905's. eth0 goes to the cisco->world. >> eth1, eth1:0 and eth1:1 go to an ethernet switch that is serving machines >> from the three /24's. eth2 goes to a hub for one of our co-location clients. >> >> Attached is an mrtg graph from someone decided to throw about 8MB of >> garbage our way for a few hours. This little linux router just sat there >> and idled through it. > >John, > What kind of CPU/box is that? > >wfms > > ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

Route Leaks
by Jeffrey S. Young 28 Oct '98

28 Oct '98

It would seem that the routes that leaked into the routing system with an AS path: origin 3561 286 209... are mostly withdrawn and now under control. There may be a number of routes that persist and we feel that the best way to clear them out is to concentrate on them on a case-by-case basis. The (Cisco suggested) workaround to quickly remove these routes even though they have been withdrawn from BGP at their insertion point is to announce more specifics from the origin AS. Rather than burden the routing system with additional, unnecessary more specific routes from AS 3561, we would like to hear from other providers or from the owners of these routes. If you're seeing routes with the above AS path or if your network is currently routing through this path please contact us. You can send mail to trouble(a)cw.net to coordinate. If you choose to copy nanog that's ok. Now, that said. This particular problem has plagued the Internet, hitting us as a community a number of times this calendar year. On the nanog list we've discussed filtering, we've pointed out how particular providers are unaffected, but as yet we are all still vulnerable. The Cable & Wireless network filters routes from customers based on routing registry entries. We believe that this is the best defense against unintentional routing leaks, it protects us and our peers from our customers. We realize that not everyone in the industry agrees with us :-). We realize that many that agree with us would find it nearly impossible to implement such a system. I'd like to propose a simple solution to the class of route leak we've recently seen. I'd like to encourage our peers to put a simple filter in place. If you peer with AS 3561, please do not accept any route with AS 3561 in the path from either your customers or your other peers. We already do this for a number of networks, without commenting on the size or importance of any of them, they are just networks that we only expect to hear on specific peering links. I still believe that the way to a more stable routing system is through route registries and filtering. I don't believe that any of us can rest easy (whether or not our networks were affected by the current leak) until we fix the system. For my own selfish interests, please, filter on my AS number.

2 1

RE: Clue's for Clue-less
by Martin, Christian 28 Oct '98

28 Oct '98

11.1-20CC also has this feature. -Chris > -----Original Message----- > From: Richard Irving [mailto:rirving@onecall.net] > Sent: Tuesday, October 27, 1998 11:02 PM > To: Sharif Torpis; nanog(a)merit.edu > Subject: Re: Clue's for Clue-less > > > Sharif Torpis wrote: > > > > this must be an 11.2 thing? > > > Unknown... > Have you ever met an 11.1.xx technician *not* > wearing synthetics to test it ? > > :) > > > > > Richard Irving wrote: > > > > > > It is built into IOS.... As you approach the ceiling, it > sends out an > > > SNMP log alert. > > > > > > Now, how I select the number is confidential.... > > > > > > Ok. I will give you a hint.... I bring up the original sessions, > > > and confirm integrity... > > > > > > Then I look at the routes, size and count. > > > > > > Then in the dark of the moon, wearing *no* synthetics, > > > facing *magnetic* north... I devine the target number. > > > > > > In other words... It is a judgement call... > > > > > > Downstreams are easier. They must file routes with me, > before I route > > > them. I filter to the prefix. > > > > > > Consider this merely another fall back mechanism to the > general IOPS > > > model. > > > > > > Sharif Torpis wrote: > > > > > > > > can u elaborate on the detection mechanism for setting off such > > > > alarms? do u look at % change in total routes in core > of internet? > > > > e.g. sunday saw a change of 55k -> 60k which is ~10% > change ... or do > > > > u look at specific blocks that should not be > deaggregated and catch > > > > them if they are deaggregated ... thanks > > > > > > > > Richard Irving wrote: > > > > > > > > > > The only neighbors I lost on this one, dumped something > > > > > they shouldn't..... If someone de-aggregates a /16, > > > > > it fires off alarms.... Although these may be valid > advertisements, > > > > > We have opted for the "safe, rather than sorry" perspective. > > > > > (Besides, the alarms *assure* prompt attention) > > > > > > > > > > PS: 11.2.xx and higher have this command... >

1 0

Re: Clue's for Clue-less
by Richard Irving 28 Oct '98

28 Oct '98

Sharif Torpis wrote: > > this must be an 11.2 thing? > Unknown... Have you ever met an 11.1.xx technician *not* wearing synthetics to test it ? :) > Richard Irving wrote: > > > > It is built into IOS.... As you approach the ceiling, it sends out an > > SNMP log alert. > > > > Now, how I select the number is confidential.... > > > > Ok. I will give you a hint.... I bring up the original sessions, > > and confirm integrity... > > > > Then I look at the routes, size and count. > > > > Then in the dark of the moon, wearing *no* synthetics, > > facing *magnetic* north... I devine the target number. > > > > In other words... It is a judgement call... > > > > Downstreams are easier. They must file routes with me, before I route > > them. I filter to the prefix. > > > > Consider this merely another fall back mechanism to the general IOPS > > model. > > > > Sharif Torpis wrote: > > > > > > can u elaborate on the detection mechanism for setting off such > > > alarms? do u look at % change in total routes in core of internet? > > > e.g. sunday saw a change of 55k -> 60k which is ~10% change ... or do > > > u look at specific blocks that should not be deaggregated and catch > > > them if they are deaggregated ... thanks > > > > > > Richard Irving wrote: > > > > > > > > The only neighbors I lost on this one, dumped something > > > > they shouldn't..... If someone de-aggregates a /16, > > > > it fires off alarms.... Although these may be valid advertisements, > > > > We have opted for the "safe, rather than sorry" perspective. > > > > (Besides, the alarms *assure* prompt attention) > > > > > > > > PS: 11.2.xx and higher have this command...

1 0

Re: root name servers
by Sean Donelan 27 Oct '98

27 Oct '98

noc(a)nso.ORG (Network Operations Center) writes: >anybody knows the physical location >of all root name servers, or a pointer ? The precise physical location (e.g. room number and rack) of all the root name servers is not generally available public information. It isn't "classified" information in the military sense, but some people get nervous nonetheless. Anyone who has been around the Net for a while will pick up that information eventually. A list of the general physical location (e.g. city and organization) can be found at <http://www.nic.mil/DNS/root-server.html>. It isn't precisely accurate, but I don't know if it is deliberate deception, or just an Oops, close enough for government work. It doesn't include the more recent root-servers servers at LINX and WIDE. However, as the last few attempts by NSI proved, geographic location isn't as important as network topology. Putting a GTLD name server in London doesn't do any good if its network connectivity sucks. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0