- Test - lists.nanog.org

MAE West
by Rodney Joffe 14 Jul '97

14 Jul '97

Another Update from our guys... Power problems in the MFS facility caused the initial outage. Power has been restored, but the Gigaswitch has lost it's configuration causing all peers to remain down. Based on some of the mail to this list, it is GIGA 1 at MAE West, 2 and 3 are up. (Most of those complaining are on GIGA 1, Mathew at ACSI is on GIGA 2 and thinks he's up. I can't reach him directly from NASA/Ames, so my guess is that he is up, but can only see peers at GIGA 2 and 3 - see next para...) By the way, to expand the thread, I have the feeling that the three OC-3s from NASA Ames side to MFS all go to GIGA 1, which then has fddi loops to GIGA 2 and then to GIGA 3. Does anyone know if this is the case? If it is, seems that a better design would have been to route some of the OC-3s to the other GIGAs first. If 1 is down, then it can't pass traffic through to 2 and 3, so there is a single point of failure for all the switches at MFS. Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net

9 17

Re: default routes on Ciscos
by Srinivas Vegesna 14 Jul '97

14 Jul '97

=>> =>>> =>>> Hi there! =>>> =>>> Just curious if anyone out there knows of a way to configure default =>>> routes on a per interface basis on a Cisco. So that different interfaces =>>> had different default routes statically defined. =>> =>>Policy routing will do that at GREAT cost in CPU time. Actually, there is a clean way of doing it with the latest 11.2 code thru CSCdj14784. This is how it works: Command Syntax: router rip default-information originate [route-map <map-name>] Description: This command can be used to force a router to generate a default route via RIP even when the router does not carry a default route. The optional route-map can be used to specify the condition(s) (i.e., the match clause) under which a default route is generated, as well as to specify the interfaces (i.e., the "set interface" clause) to advertise the default route. If the optional route-map is not configured or if there is no "set interface" clause in the configured route-map, the default route is advertised to all interfaces running RIP. Here, extended access-lists can not be used in the route-map. thanks, Srinivas =>>> =>>> Any thoughts? =>>> =>>> Thanks! =>>> =>>> Nick Lauriat =>>> =>>> =>>> =>> =>>Dave Nordlund d-nordlund(a)ukans.edu =>>University of Kansas 913/864-0450 =>>Computing Services FAX 913/864-0485 =>>Lawrence, KS 66045 KANREN =>>

1 0

Intrusion Detection Systems
by Hamdi TOUNSI 14 Jul '97

14 Jul '97

Hello, I need some tools to monitor an ip network for intrusion detection. Can someone help me with this ? I tried before some public domain tools like argus but i need to know is someone has successfully constrcuted a good & complete intrusion detection solution (i.e monitoring, logging, real-time alarms, proactive monitoring, ..) I'm also interested in the developement of such a solutions, and i may coordinate the distributed developement effort with coordination with academic projects focusing the same goal. Best regards Hamdi

2 1

Re: Domain Name NASA.COM
by William Allen Simpson 14 Jul '97

14 Jul '97

> RFC_Violation: You saw it here first! > From: jamie(a)intuition.iagnet.net (Jamie Rishaw) > I've been a longstanding cheerleader for the NIC, but > That was your first mistake. Although what can one expect from someone who brags about violating RFCs? > Today, without notice, the InterNIC turned "off" the domain name NASA.COM, > a domain which had been registered now for over two years. > May I suggest that your customer sue, not the FTC or NASA, but the Internic for violation of the contract. You paid a fee, they are required to follow their own procedures. You should be able to get quite a bit for actual and punitive damages. And you would be doing all the rest of us a service, by setting a precedent. We really cannot have Internic becoming an extension of the US government, or making arbitrary actions. But enforcement of contracts generally requires a court. As far as I can see, you wouldn't even have to prove that NASA.COM was "in a manner reasonably calculated to convey the impression". That would be up to NASA and/or FTC, should Internic get them to come to the court (third party cross complaint, perhaps). Although, for curiousities sake, what did this NASA stand for, and what was their product? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

5 4

Re: NSPs and filters (fwd)
by Barney Wolff 14 Jul '97

14 Jul '97

> Date: Mon, 14 Jul 1997 12:29:32 -0400 > From: Daniel Senie <dts(a)proteon.com> > > And it goes beyond that... Every PC running Windows (or any other OS, > for that matter) has complete ability to do anything with IP. So, any > user on a dialup line into any ISP is a possible source of attacks. > > This is why I think the RAS servers need to be able to filter right at > the point of the dialup. There, the comparison is a simple compare of a > 32 bit integer (IP address assigned to the dialup user, compared to the > IP address of packets received from the user). Any discrepancies should > set off alarm bells... Some ISPs, including the very large one for which I wrote the PPP code, already do this. Source address assurance is the mirror image of destination-based routing. That's not to say that routing is always symmetrical, but the problem is no harder, and can be made no slower. Barney Wolff <barney(a)databus.com>

1 0

Re: MAE West
by Curt Howland 14 Jul '97

14 Jul '97

I wouldn't call 8.5 hours "quickly corrected". > From: bmanning(a)ISI.EDU (Bill Manning) > > To true. Would you care to cover the cost of replicating the 400Mbp/s > to build in better reliability? It appears that the owners/operators of > MAE-West are selecting an optimization path based on the assumption that > outages are infrequent and can be quickly corrected. > > --bill >

1 0

Kaspia E-mail to the group
by Steve Carter 14 Jul '97

14 Jul '97

Am I too suspicious/cynical or did Jeff Erwin just manage to get another plug for his company and products onto the NANOG list? > -----Original Message----- > From: William B. Norton [SMTP:wbn@merit.edu] > Sent: Monday, July 14, 1997 9:39 AM > To: nanog(a)merit.edu > Subject: Kaspia E-mail to the group <snip>

1 0

The Cidr Report
by Tony Bates 14 Jul '97

14 Jul '97

1 0

Re: Unacceptable Delay
by Brett D. Watson 14 Jul '97

14 Jul '97

we've just received a bunch of nanog mail here at genuity that was delay *eight* hours between the time it reached merit.edu, and the time our mx host recieved it from merit, according to the headers. we've received external mail from all over the place all day with no apparent delay. has *no* one else seen any great delays in the messages from nanog? i don't think the packet loss has been that bad for 8 hours. :) -brett > I would say a lot of the delay is in packet loss.. with MW down, ME is > really loaded at this time.. I get as much as 60% packet loss just pinging > across the Ring. OUCH! > > Eric > > > _______________________________________________________ > Eric D. Madison - Senior Network Engineer - > ACSI - Advanced Data Services - ATM/IP Backbone Group > 24 Hour NMC/NOC (800)291-7889 Email: noc(a)acsi.net > > > On Fri, 11 Jul 1997, Rodney Joffe wrote: > > > It's interesting to note the delay in the NANOG mailer. I don't know if > > there's any manual operation involved, but according to the headers, Rob > > posted this at 7:43, it was received at 7:43 pdt by MERIT, and shipped > > out at 8:15 pdt. > > > > I guess we're lucky this isn't an operational list, where time might be > > important ;-) > > > > Can we improve this? > > > > > > Rodney Joffe > > Chief Technology Officer > > Genuity Inc., a Bechtel company > > http://www.genuity.net > > > > Received: from postal1.genuity.net by x-files.genuity.net with SMTP > > (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) > > id 3T51M8BZ; Fri, 11 Jul 1997 08:15:13 -0700 > > Received: from merit.edu (merit.edu [198.108.1.42]) > > by postal1.genuity.net (Sendmail G2.3/8.8.5) with ESMTP id > > PAA19251; > > Fri, 11 Jul 1997 15:15:28 GMT > > Received: from localhost (daemon@localhost) > > by merit.edu (8.8.5/8.8.5) with SMTP id KAA15550; > > Fri, 11 Jul 1997 10:49:59 -0400 (EDT) > > Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 10:43:51 > > -0400 > > Received: (from majordom@localhost) > > by merit.edu (8.8.5/8.8.5) id KAA15338 > > for nanog-outgoing; Fri, 11 Jul 1997 10:43:49 -0400 (EDT) > > Received: from elite.exodus.net (rob(a)elite.exodus.net [209.1.115.69]) > > by merit.edu (8.8.5/8.8.5) with ESMTP id KAA15331 > > for <nanog(a)merit.edu>; Fri, 11 Jul 1997 10:43:41 -0400 (EDT) > > Received: (from rob@localhost) by elite.exodus.net (8.7.5/8.7.3) id > > HAA04422 for nanog(a)merit.edu; Fri, 11 Jul 1997 07:43:52 -0700 > > From: Robert Bowman <rob(a)elite.exodus.net> > > Message-Id: <199707111443.HAA04422(a)elite.exodus.net> > > Subject: It's always fun > > To: nanog(a)merit.edu > > Date: Fri, 11 Jul 1997 07:43:52 -0700 (PDT) > > X-Mailer: ELM [version 2.4 PL25] > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding: 7bit > > Sender: owner-nanog(a)merit.edu > > > > >

2 1

Cisco 12000 aka BFR aka GSR
by Peter Leppik 14 Jul '97

14 Jul '97

Apologies in advance for a non-operational question, but... Has anyone had the chance to get their hands on a real, live Cisco 12000 yet? I saw the plexiglass wonder at InterOp, and I'm wondering when there might be an actual box that real people can kick the tires on (even in beta). Thanks, -Peter

1 0