July 1997 - Test - lists.nanog.org

Re: Custom/Priority Queueing
by rbuchals＠hotmail.com 15 Jul '97

15 Jul '97

>From: rbenn(a)clark.net >On Mon, 14 Jul 1997, Alex Rubenstein wrote: >> Does anyone have a example of how to route packets based upon service? IE, >> if I have a slow 64kb/s Frame, and a fast DS1, I want to send >> non-interactive traffic over the 64k, like mail, etc., but www/ftp over the >> DS1. >> > >You may want to continue utilizing both links for all traffic, but >implement custom or priority queueing on them. The only other alternative >that comes to mind would be extended access lists. Not really sure how >the 2 methods would compare regarding performance or router utilization, >though. Policy routing will allow you to do this. -rb _______________________________________________________ Get Private Web-Based Email Free http://www.hotmail.com

1 0

None
by Alex Rubenstein 15 Jul '97

15 Jul '97

Does anyone have a example of how to route packets based upon service? IE, if I have a slow 64kb/s Frame, and a fast DS1, I want to send non-interactive traffic over the 64k, like mail, etc., but www/ftp over the DS1. --- "Don't go with a spineless ISP; we have more backbone." Alex Rubenstein -- alex(a)nac.net -- KC2BUO -- www.nac.net net @ccess corporation, 201-983-0725 -- 201-983-0725

2 1

No Subject
by JimTLange＠aol.com 14 Jul '97

14 Jul '97

Likewise, I've been receiving unsolicited e-mail from IEMMC. When I tried to respond, I received error messages from my ISP. Also, cannot contact IEMMC via web. Server refuses connection! Some agreement. Jim Lange

1 0

Microsoft Registered Domains
by Robert A. Pickering Jr. 14 Jul '97

14 Jul '97

I'll admit, the Operations value of this message is a bit low. But, it does clarify how the InterNIC's use of automation is allowing people to register domain names against another company, with no trace of who the culprit may have been. I thought the correct procedure was to get an ACK/NACK acknowledgement from the owner of the DNS servers BEFORE going ahead and registering the domains. There's also some humor value as well: -Rob Some domains registered to Microsoft: Start: 7/11/97 9:56:21 AM Whois user[@]: do weshallprevail.com [rs.internic.net.] Microsoft Corporation (WESHALLPREVAIL-DOM) 3635 157th Avenue Redmond, WA 98052 US Domain Name: WESHALLPREVAIL.COM Administrative Contact: MSN Hostmaster (MH37-ORG) msnhst(a)MICROSOFT.COM tel.: 206 882 8080 fax.: 206 703 2641 Technical Contact, Zone Contact: MSN NOC (MN5-ORG) msnnoc(a)MICROSOFT.COM 206 882 8080 Billing Contact: MSN Domain Billing (MDB-ORG) msnbill(a)MICROSOFT.COM 206 882 8080 Record last updated on 24-Jun-97. Record created on 24-Jun-97. Database last updated on 11-Jul-97 04:20:56 EDT. Domain servers in listed order: ATBD.MICROSOFT.COM 131.107.1.7 DNS1.MICROSOFT.COM 131.107.1.240 DNS3.NWNET.NET 192.220.250.7 DNS4.NWNET.NET 192.220.251.7 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. * Whois complete 7/11/97 9:56:40 AM * Start: 7/11/97 9:57:12 AM Whois user[@]: do RESISTANCE-IS-FUTILE.COM [rs.internic.net.] Microsoft Corporation (RESISTANCE-IS-FUTILE-DOM) 3635 157th Avenue Redmond, WA 98052 US Domain Name: RESISTANCE-IS-FUTILE.COM Administrative Contact: MSN Hostmaster (MH37-ORG) msnhst(a)MICROSOFT.COM tel.: 206 882 8080 fax.: 206 703 2641 Technical Contact, Zone Contact: MSN NOC (MN5-ORG) msnnoc(a)MICROSOFT.COM 206 882 8080 Billing Contact: MSN Domain Billing (MDB-ORG) msnbill(a)MICROSOFT.COM 206 882 8080 Record last updated on 24-Jun-97. Record created on 24-Jun-97. Database last updated on 11-Jul-97 04:20:56 EDT. Domain servers in listed order: ATBD.MICROSOFT.COM 131.107.1.7 DNS1.MICROSOFT.COM 131.107.1.240 DNS3.NWNET.NET 192.220.250.7 DNS4.NWNET.NET 192.220.251.7 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. * Whois complete 7/11/97 9:57:32 AM * Start: 7/11/97 9:57:50 AM Whois user[@]: do BILL-IS-LORD.COM [rs.internic.net.] Microsoft Corporation (BILL-IS-LORD-DOM) 3635 157th Avenue Redmond, WA 98052 US Domain Name: BILL-IS-LORD.COM Administrative Contact: MSN Hostmaster (MH37-ORG) msnhst(a)MICROSOFT.COM tel.: 206 882 8080 fax.: 206 703 2641 Technical Contact, Zone Contact: MSN NOC (MN5-ORG) msnnoc(a)MICROSOFT.COM 206 882 8080 Billing Contact: MSN Domain Billing (MDB-ORG) msnbill(a)MICROSOFT.COM 206 882 8080 Record last updated on 24-Jun-97. Record created on 24-Jun-97. Database last updated on 11-Jul-97 04:20:56 EDT. Domain servers in listed order: ATBD.MICROSOFT.COM 131.107.1.7 DNS1.MICROSOFT.COM 131.107.1.240 DNS3.NWNET.NET 192.220.250.7 DNS4.NWNET.NET 192.220.251.7 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. * Whois complete 7/11/97 9:58:08 AM * -- Robert A. Pickering Jr. Internet Services Manager Cincinnati Bell Telephone rob(a)fuse.net A Rough Whimper of Insanity (Information Superhighway) PGP key ID: 75CAFF7D 1995/05/09 PGP Fingerprint: B1 63 0C 09 D8 2E 5D 69 BB 61 A2 92 22 37 63 C3 ---------- Forwarded message ---------- Date: Fri, 11 Jul 1997 10:29:45 -0400 (EDT) From: "Robert A. Pickering Jr." <pickerin(a)Fuse.net> To: bob(a)mhmh.org Subject: Microsoft domains (fwd) -- Robert A. Pickering Jr. Internet Services Manager Cincinnati Bell Telephone rob(a)fuse.net A Rough Whimper of Insanity (Information Superhighway) PGP key ID: 75CAFF7D 1995/05/09 PGP Fingerprint: B1 63 0C 09 D8 2E 5D 69 BB 61 A2 92 22 37 63 C3 ---------- Forwarded message ---------- Date: Fri, 11 Jul 1997 10:26:39 -0400 (EDT) From: "Christopher J. Utley" <cutley(a)fuse.net> To: fusers(a)fuse.net, operations(a)fuse.net Subject: Microsoft domains Some domains registered to Microsoft: Start: 7/11/97 9:56:21 AM Whois user[@]: do weshallprevail.com [rs.internic.net.] Microsoft Corporation (WESHALLPREVAIL-DOM) 3635 157th Avenue Redmond, WA 98052 US Domain Name: WESHALLPREVAIL.COM Administrative Contact: MSN Hostmaster (MH37-ORG) msnhst(a)MICROSOFT.COM tel.: 206 882 8080 fax.: 206 703 2641 Technical Contact, Zone Contact: MSN NOC (MN5-ORG) msnnoc(a)MICROSOFT.COM 206 882 8080 Billing Contact: MSN Domain Billing (MDB-ORG) msnbill(a)MICROSOFT.COM 206 882 8080 Record last updated on 24-Jun-97. Record created on 24-Jun-97. Database last updated on 11-Jul-97 04:20:56 EDT. Domain servers in listed order: ATBD.MICROSOFT.COM 131.107.1.7 DNS1.MICROSOFT.COM 131.107.1.240 DNS3.NWNET.NET 192.220.250.7 DNS4.NWNET.NET 192.220.251.7 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. * Whois complete 7/11/97 9:56:40 AM * Start: 7/11/97 9:57:12 AM Whois user[@]: do RESISTANCE-IS-FUTILE.COM [rs.internic.net.] Microsoft Corporation (RESISTANCE-IS-FUTILE-DOM) 3635 157th Avenue Redmond, WA 98052 US Domain Name: RESISTANCE-IS-FUTILE.COM Administrative Contact: MSN Hostmaster (MH37-ORG) msnhst(a)MICROSOFT.COM tel.: 206 882 8080 fax.: 206 703 2641 Technical Contact, Zone Contact: MSN NOC (MN5-ORG) msnnoc(a)MICROSOFT.COM 206 882 8080 Billing Contact: MSN Domain Billing (MDB-ORG) msnbill(a)MICROSOFT.COM 206 882 8080 Record last updated on 24-Jun-97. Record created on 24-Jun-97. Database last updated on 11-Jul-97 04:20:56 EDT. Domain servers in listed order: ATBD.MICROSOFT.COM 131.107.1.7 DNS1.MICROSOFT.COM 131.107.1.240 DNS3.NWNET.NET 192.220.250.7 DNS4.NWNET.NET 192.220.251.7 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. * Whois complete 7/11/97 9:57:32 AM * Start: 7/11/97 9:57:50 AM Whois user[@]: do BILL-IS-LORD.COM [rs.internic.net.] Microsoft Corporation (BILL-IS-LORD-DOM) 3635 157th Avenue Redmond, WA 98052 US Domain Name: BILL-IS-LORD.COM Administrative Contact: MSN Hostmaster (MH37-ORG) msnhst(a)MICROSOFT.COM tel.: 206 882 8080 fax.: 206 703 2641 Technical Contact, Zone Contact: MSN NOC (MN5-ORG) msnnoc(a)MICROSOFT.COM 206 882 8080 Billing Contact: MSN Domain Billing (MDB-ORG) msnbill(a)MICROSOFT.COM 206 882 8080 Record last updated on 24-Jun-97. Record created on 24-Jun-97. Database last updated on 11-Jul-97 04:20:56 EDT. Domain servers in listed order: ATBD.MICROSOFT.COM 131.107.1.7 DNS1.MICROSOFT.COM 131.107.1.240 DNS3.NWNET.NET 192.220.250.7 DNS4.NWNET.NET 192.220.251.7 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. * Whois complete 7/11/97 9:58:08 AM * -- Christopher J. Utley Webmaster Cincinnati Bell Telephone chris(a)fuse.net

6 7

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