July 1999 - Test - lists.nanog.org

Is there a PSI.NET person in the house?
by Roeland M.J. Meyer 11 Apr '00

11 Apr '00

I just got half a hundred of these (and 123 of these last Friday) and all e-mail, to the usual locations, bounces or gets ignored. I am livid, I am pissed, I am *really* wanting to SMURF PSI.NET because they have been a spam-harbor for *years*! PSI.NET should have made it into the RBL a long time ago. >Return-Path: <admin1(a)fnmail.com> >Received: from beta.pragmatix.com (epsilon.pragmatix.com [205.166.32.6] (may >be forged)) > by condor.lvrmr.mhsc.com (8.9.1/8.9.1) with ESMTP id FAA18857 > for <rmeyer(a)mhsc.com>; Mon, 1 Mar 1999 05:04:57 -0800 >Date: Mon, 1 Mar 1999 05:04:57 -0800 >From: admin1(a)fnmail.com >Message-Id: <199903011304.FAA18857(a)condor.lvrmr.mhsc.com> >Received: from jgroves (ip33.phoenix8.az.pub-ip.psi.net [38.29.61.33]) by >beta.pragmatix.com with SMTP (Microsoft Exchange Internet Mail Service >Version 5.5.1960.3) > id FS46B0Z3; Sun, 28 Feb 1999 18:33:11 -0500 >To: travelers(a)ibm.net >Subject: Make $$, Travel and Have Fun! >X-UIDL: 2ddab26e92763572b29a9545c30b592f ___________________________________________________ Roeland M.J. Meyer - e-mail: mailto:rmeyer@mhsc.com Internet phone: hawk.lvrmr.mhsc.com Personal web pages: http://staff.mhsc.com/~rmeyer Company web-site: http://www.mhsc.com ___________________________________________________ KISS ... gotta love it!

3 3

ARIN policy on acquisitions ?
by Brandon Applegate 05 Aug '99

05 Aug '99

Greetings all, Aplogies if this has already been covered (I couldnt find it :) ) Does any one know what ARIN's policy is on ISP acquisition ?? Is there one ?? In other words, ISP A buys ISP B. ISP B has some pre-ARIN allocated IP space (swamps from Internic, etc etc). When ISP A goes to modify these network objects in the ARIN DB, is there going to be a problem ?? Will ARIN say they have to be returned ?? Feel free to contact me off list if you feel this is not relevant to said list. TIA -------------------------------------------------- Brandon Applegate, CCNA : Network Administrator http://www.one.net : brandon(a)one.net --------------------------------------------------

4 3

SYN spoofing
by bandregg＠redhat.com 04 Aug '99

04 Aug '99

This past weekend I was contacted by several groups ranging from NASA to a small service provider in the Bay area regarding one of our hosts port scanning their networks using RESET packets. In each of these cases the machine seemed to be scanning random addresses in their networks on random, non-reserved (+1024), ports. After investigating these claims it appears as if someone is sending SYN packets to this machine (which serves ftp, which explains why the ports are open through the cisco) with a spoofed source address causing the machine to send RESET packets back to the spoofed host and setting off their firewalls. I cannot seem to get past level-1 or level-2 support from my upstream, GTE/BBN to find out where these packets are coming from to track this down. So, I come to you... Two currently on-going attacks are using the spoofed source addresses from the networks 134.50.x.x and 130.221.x.x. If you see activity from these networks inside of your borders, but the networks are not inside of your borders please contact me off of the list. Oh yeah, and filter this stuff out people, this is unacceptible. -- Bryan C. Andregg * <bandregg(a)redhat.com> * Red Hat, Inc. 1024/625FA2C5 F5 F3 DC 2E 8E AF 26 B0 2C 31 78 C2 6C FB 02 77 1024/0x46E7A8A2 46EB 61B1 71BD 2960 723C 38B6 21E4 23CC 46E7 A8A2

18 26

The Cidr Report
by Tony Bates 02 Aug '99

02 Aug '99

This is an auto-generated mail on Fri Jul 30 12:00:00 PDT 1999 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 xara.net 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 30Jul99 0) General Status Table History ------------- Date Prefixes 230799 61494 240799 61486 250799 61391 260799 61592 270799 61488 280799 61707 290799 61808 300799 61912 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: 5372 Number of ASes announcing only one prefix: 2813 (1550 cidr, 1263 classful) Largest number of cidr routes: 461 announced by AS701 Largest number of classful routes: 841 announced by AS701 1) Gains by aggregating at the origin AS level --- 30Jul99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 348 147 201 57.8% BCnet Backbone AS2609 121 28 93 76.9% EUnet-TN AS174 578 486 92 15.9% Performance Systems International AS1221 537 445 92 17.1% TELSTRA-AS AS577 280 189 91 32.5% Bell Canada Backbone AS3749 153 63 90 58.8% TECNET AS4293 235 149 86 36.6% IMCI AS7046 322 237 85 26.4% UUNET-CUSTOMER AS4200 182 103 79 43.4% AGIS (Apex Global Information Ser AS7545 141 66 75 53.2% TPG Internet Pty Ltd AS7496 108 34 74 68.5% Power Up AS7657 229 156 73 31.9% The Internet Group Limited AS10928 119 49 70 58.8% UNKNOWN AS9269 76 16 60 78.9% Hong Kong CTI AS4755 138 79 59 42.8% Videsh Sanchar Nigam Ltd. India AS6944 63 6 57 90.5% RapidSite, Inc. AS4740 307 253 54 17.6% Ozemail Pty Ltd (ASN-OZEMAIL) AS719 458 406 52 11.4% LANLINK autonomous system AS2493 159 110 49 30.8% iSTAR Internet, Inc. AS684 91 46 45 49.5% Manitoba Regional Network Backbon AS803 78 34 44 56.4% SaskNet Backbone AS549 215 172 43 20.0% ONet Backbone AS3737 108 67 41 38.0% PenTeleData Inc. (ASN-PTD) AS1785 253 215 38 15.0% NYSERNet Backbone AS209 251 216 35 13.9% Qwest Communications AS1 495 460 35 7.1% BBNPLANET AS10724 42 8 34 81.0% UNKNOWN AS6762 33 2 31 93.9% Telecom Italia international high AS4307 32 1 31 96.9% SVINET-1 AS11515 32 1 31 96.9% 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

3 2

Martian and RFC1918 addresses
by rfuller＠3x.com 31 Jul '99

31 Jul '99

I have been reading Cisco's "Essential IOS Features Every ISP Should Consider" document and came across a section called Martian and RFC1918 networks. It is discussing different bogus or reserved networks that should be filtered by every ISP. In the list are some addresses I thought were legal and after checking the ARIN Whois database, some of them seem to be. Can anyone give me some additional information as to the need to filter the following networks: 1.0.0.0 reserved for IANA 19.255.0.0 this belongs to Ford 59.0.0.0 reserved for IANA 129.156.0.0 this belongs to SUN 169.254.0.0 IANA use for local link numbers??? 192.0.2.0 reserved for IANA 192.5.0.0 no ARIN match 192.9.200.0 no ARIN match 192.9.99.0 this belongs to SUN If you can elaborate on what they are used for and if any problems would arise from filtering these networks, it would be appreciated. If you could also please include where you found the information, I would appreciate it. Some of them belong to companies, so why would you filter them? Are they development networks for Ford and SUN? Are there any other martian networks that should be filtered? Here is the URL for the doc if anyone is interested: http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip Thanks in advance! Ron Fuller, CCDP, CCNP-ATM, MCNE, MCP 3X Corporaton rfuller(a)3x.com

3 2

Can someone PLEASE fix this?
by John Fraizer 30 Jul '99

30 Jul '99

Will someone please remove steve.murray(a)wcom.com from the nanog list until he or his provider learns how to properly route email? Every message I send to NANOG results in a bounce from his provider: ----- The following addresses had permanent fatal errors ----- shmurray(a)gwsmtp.wcom.com (expanded from: <steve.murray(a)wcom.com>) ----- Transcript of session follows ----- 554 Too many hops 26 (25 max): from <John.Fraizer(a)EnterZone.net> via gwsmtp2.wcom.com, to <steve.murray(a)wcom.com> Reporting-MTA: dns; ndcrelay.mcit.com Received-From-MTA: DNS; gwsmtp2.wcom.com Arrival-Date: Fri, 30 Jul 1999 22:40:54 GMT Final-Recipient: RFC822; steve.murray(a)ndcrelay.mcit.com X-Actual-Recipient: RFC822; shmurray(a)gwsmtp.wcom.com Action: failed Status: 5.0.0 ------------ John Fraizer ------------ mailto:john.fraizer@EnterZone.Net http://www.EnterZone.Net http://www.EZ-Hosting.Net http://www.EZ-IP.Net ------------------------------------------ | __ _ | | | / / (_)__ __ ____ __ | The choice | | / /__/ / _ \/ // /\ \/ / | of a GNU | | /____/_/_//_/\_,_/ /_/\_\ | Generation | | | | ------------------------------------------

1 0

IS-IS and OSPF
by Johnson Kuruvila 30 Jul '99

30 Jul '99

Hi All, I hope this mail is appropriate for the charter of Nanog. Pardon me if it is not. Could someone comment on: Normally, is there is a need to run both IS-IS and OSPF on the same interface on a router? How does the vendors today support this? Thanks a million, --Johnson

2 1

Open Access debate out of hand?
by David Brouda 30 Jul '99

30 Jul '99

News.com has posted a Reuters story titled "Cisco under fire from "open access" groups" <http://www.news.com/News/Item/0,4,39939,00.html?st.ne.fd.tohhed.ni> Here's one sample statement: Referring to product literature passed out at a recent industry trade show by Cisco, one representative said, "This is the owner's manual that they're providing to the cable industry to monopolize the Internet," according to Jeff Chester, executive director of the Center for Media Education. The claims are that QoS gives companies too much control. I think it's time someone with a clue help them right a story. Perhaps this has gotten out of hand? -David

1 0

Sprint duplicate packets
by bcurnow 30 Jul '99

30 Jul '99

I don't have any NOC contacts, but since I saw the other post about Sprint duplicates, I thought I would mention that the following Sprint router also appears to have a problem: # ping 144.232.9.86 PING 144.232.9.86 (144.232.9.86): 56 data bytes 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=86.4 ms 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=92.0 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=110.3 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=121.5 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=162.7 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=168.4 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=174.9 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=195.5 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=233.8 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=239.5 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=247.0 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=263.7 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=281.4 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=299.7 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=318.0 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=335.6 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=375.5 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=406.4 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=412.1 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=438.1 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=443.8 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=449.6 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=471.8 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=478.1 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=495.3 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=513.3 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=551.4 ms (DUP!) Traffic going through that router only seems to double once, though. It has been doing it for at least two days. ----------------- Brian Curnow ----------------

2 1

Mysterious Mae-East Packets
by Deepak Jain 29 Jul '99

29 Jul '99

On our interface(s) at Mae-East we have been seeing some of the following: Jul 29 17:09:51: %SEC-6-IPACCESSLOGP: list 103 denied udp 0.0.0.0(1610) (Fddi1/1/0 0040.0bc0.6c25) -> 255.255.255.255(67), 1 packet Anyone know who belongs to/masquerades behind ARP address 0040.0bc0.6c25? Thanks for any assistance/advice. Deepak Jain AiNET

1 0