- Test - lists.nanog.org

Re: SMURF amplifier block list
by Hank Nussbacher 17 Apr '98

17 Apr '98

At 09:33 PM 4/13/98 -0700, Vadim Antonov wrote: >You're right, silly me. > >--vadim > > >Forrest W. Christian <forrestc(a)iMach.com> wrote: > >On Mon, 13 Apr 1998, Vadim Antonov wrote: > >> Uh. Just modify BGP routes from that feed to have a next hop pointing >> to a black hole. route-maps are sometimes useful. > >Could someone PLEASE explain to me how this is accomplished? > >Let's assume that you do use a route-map to set next hop to a null >interface or a black hole or something for a prefix. AND set local pref >appropriately so that route gets preferred. > >You now have a routing entry which essentially says: > > "forward packets DESTINED FOR the evil network to the black hole". > >What you really want is a routing entry which says: > > "forward packets FROM the evil network to the black hole". > >Now, if someone could enlighten me to a way which you can get BGP to make >a routing/filter entry to do this second one, I'd be most grateful. Why wouldn't this work (on IOS 11.3 at least): a) pick an unused interface (shutdown): inter s0/2 ip address 192.168.1.5 255.255.255.252 shutdown ip route 192.168.1.0 255.255.255.0 Null0 254 b) Say the spammer is 220.88.182.128/27: access-list 20 permit 220.88.182.128 0.0.0.31 route-map spam-filter permit 10 match ip address 20 set ip default next-hop 192.168.1.6 c) On your Fast Ethernet - or whatever interface you use to feed pkts to your outgoing lines: int fa1/0 ip policy route-map spam-filter All outgoing pkts to 220.88.192.128/27 now should go to Null0. I am sure one can improve on the logic even more. -Hank

4 3

Re: SMURF amplifier block list
by James R. Cutler 17 Apr '98

17 Apr '98

Jay, I now understand the confusion -- You are speaking of the dotted decimal representation of the 32 bit IP address without regard to masking. I am speaking of the masked address which results in a (mask length) network number part and a (32 - mask length) host number. This means you think of address components as octets (bytes) and I think of the effective network number and the effective host number, the sizes of which are determined only by the mask. Or another way to this is that the routers and hosts do not see the dotted notation except in the configuration dialogs. Internal to the routing processes the effective network number determines the routing between subnets and a broadcast address is any address where the host number is all ones. Another way to look at this is to say you are thinking about IP addressing in a "classful" manner whilst I am speaking in a "classless" manner. Believe me, the transition from classful to classless thinking in IP addressing is not an easy thing. None of the RFCs are simple to understand. So, I guess I'm not in trouble after all. Regards. JimC At 8:49 PM -0400 4/14/98, Jay R. Ashworth wrote: >On Tue, Apr 14, 1998 at 04:52:06PM -0400, James R. Cutler wrote: >> I have a B assignment. I have switched infrastructure segments >> with /22 masking. Do you mean to say that the host number >> range on each /22 masked segment is not continuous 1 through 1022, >> but has several holes instead.? The network seems to be working >> properly. I may be in big trouble! >> >> None of my TCP/IP courses or books or Cisco CDs have prepared me for >> such a surprise. Please point me to a text which will explain this. > >None of my study of TCP in the past 5 years has prepared me for the >idea that someone might think that any component of an IP address might >be greater than 255. They're decimal representations of _8 bit_ >numbers. > >No matter _where_ the net/subnet break is, you _still_ _write_ them as >AAA.BBB.CCC.DDD. > >Yes, conceptually, you might _read_ the addresses that way, but I'm >pretty sure that not one piece of equipment you own will let you >_write_ them that way, will they? > >Now, to get back to the conversation at hand: the proposition was that >blocking ingress to addresses ending in .255 makes it much more >difficult for your network to be used as a "smurf amplifier" (and if >you don't know what that is, you haven't been following the discussin >(and links) on this list in the last month or 3). > >Yes, if you have internal networks larger than a /24, then that means >you'll lose extra addresses if you do this. > >The point is that if you _don't_ avoid using host addresses that end in >.255 _whether that address is a broadcast address based on your netmask >or not_, then you're likely to find yourself with hosts that either can't >talk, or can't be talked _to_. > >Now have I made myself clear? > >Cheers, >-- jra >-- >Jay R. Ashworth jra(a)baylink.com >Member of the Technical Staff Unsolicited Commercial Emailers Sued >The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, >Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 > >Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com - James R. Cutler EDS , 800 Tower Drive, Troy, MI 48098 Phone: +1 248 265 7514 FAX: +1 248 265 7514 EDS Internal Web: <http://www.iscg.eds.com/cutler/> World Wide Web: <http://www.ltu.edu/midecus/dechtm/cutler/cutler.htm>

3 2

The Cidr Report
by Tony Bates 17 Apr '98

17 Apr '98

This is an auto-generated mail on Fri Apr 17 12:00:00 PDT 1998 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 17Apr98 0) General Status Table History ------------- Date Prefixes 100498 50729 110498 50709 120498 50690 130498 50676 140498 51036 150498 51181 160498 50874 170498 51188 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: 3462 Number of ASes announcing only one prefix: 1628 (850 cidr, 778 classful) Largest number of cidr routes: 378 announced by AS3561 Largest number of classful routes: 1088 announced by AS701 1) Gains by aggregating at the origin AS level --- 17Apr98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 438 216 222 50.7% IMCI AS2493 560 344 216 38.6% iSTAR Internet, Inc. AS816 666 454 212 31.8% UUNET Canada (ASN-UUNETCA-AS4) AS3602 468 300 168 35.9% Sprint Canada Inc. AS701 1088 924 164 15.1% Alternet AS174 786 624 162 20.6% Performance Systems International AS3749 216 71 145 67.1% TECNET AS8505 155 34 121 78.1% Middle East Technical University AS7046 234 134 100 42.7% UUNET-CUSTOMER AS5668 118 44 74 62.7% Century Telephone Inc. AS2048 162 90 72 44.4% LaNet AS11003 129 57 72 55.8% UNKNOWN AS3221 110 41 69 62.7% EENet Autonomous System AS4755 91 28 63 69.2% Videsh Sanchar Nigam Ltd. India AS271 111 52 59 53.2% BCnet Backbone AS3804 200 142 58 29.0% Bell Solutions AS10928 100 42 58 58.0% UNKNOWN AS549 209 158 51 24.4% ONet Backbone AS1239 541 491 50 9.2% SprintLink Backbone AS72 84 36 48 57.1% Schlumberger Information Network AS6392 79 32 47 59.5% MidWest Communications, Inc. AS4763 123 76 47 38.2% Telstra New Zealand AS1221 286 239 47 16.4% AARNET-AS AS4740 356 313 43 12.1% ASN-OZEMAIL (Ozemail Pty Ltd) AS1982 162 119 43 26.5% Northwest Nexus, Inc. AS852 157 117 40 25.5% AGT Advance Communication AS684 94 54 40 42.6% Manitoba Regional Network Backbon AS4200 132 94 38 28.8% AGIS (Apex Global Information Ser AS3493 164 126 38 23.2% INTERLINK AS6335 63 27 36 57.1% NTRNET 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

1 0

Re: ARIN Services
by Barry Dykes 17 Apr '98

17 Apr '98

Round robin works fine if they are all up. Otherwise one goes down, you cache the name, and you keep trying to reach the downed server until it comes up or the name times out of the cache. Of course if you have 4 servers being round robin-ed then this only affects 25% of all queries :) Barry > > Why even use a different name? Round robin works fine, and if all the > registries participate in a cross-mirroring program, then all would be > well, no? If you mirror correctly, it doesn't much matter _which_ host > you hit. > > Cheers, > -- jra

2 1

Private routes advertised
by administrator＠lamere.net 17 Apr '98

17 Apr '98

Hello, alter.net is advertising private routes 192.168.nnn.nnn. who do I contact to get that shutdown? Here is the traceroute on it. [C:\]tracerte 192.168.2.5 0 lamere-r1.lamere.net (206.249.60.1) 8 ms 8 ms 0 ms 1 lamere-r1.lamere.net (206.249.60.1) 0 ms 0 ms 0 ms 2 206.249.57.241 (206.249.57.241) 8 ms 0 ms 0 ms 3 loki.wordwrap.net (206.249.56.1) 0 ms 7 ms 0 ms 4 bbr2-s401-wordwrap.ctel.net (208.221.76.165) 8 ms 203 ms 180 ms 5 905.Hssi2-0.GW1.BOS1.ALTER.NET (157.130.4.25) 31 ms 156 ms 234 ms 6 123.ATM2-0-0.XR2.BOS1.ALTER.NET (146.188.176.238) 8 ms 24 ms 15 ms 7 190.ATM10-0-0.XR2.EWR1.ALTER.NET (146.188.176.153) 32 ms 85 ms 32 ms 8 100.ATM10-0-0.TR2.EWR1.ALTER.NET (146.188.176.90) 39 ms 31 ms 23 ms 9 105.ATM6-0.TR2.DCA1.ALTER.NET (146.188.136.189) 24 ms 23 ms 24 ms 10 198.ATM8-0-0.XR2.TCO1.ALTER.NET (146.188.161.185) 32 ms 23 ms 24 ms 11 192.ATM1-0-0.GW2.TCO1.ALTER.NET (146.188.160.53) 31 ms 32 ms 23 ms 12 quantum-gw.customer.alter.net (157.130.34.170) 31 ms 31 ms 39 ms 13 192.168.4.1 (192.168.4.1) 86 ms * 93 ms 14 192.168.10.2 (192.168.10.2) 94 ms 94 ms 93 ms 15 192.168.11.23 (192.168.11.23) 94 ms 86 ms 125 ms 16 192.168.2.5 (192.168.2.5) 93 ms * Curtis -- ----------------------------------------------------------- Curtis Maurand System Administrator lamere.net Business Center We'll get you Wired. administrator(a)lamere.net -----------------------------------------------------------

9 10

Re: Private routes advertised
by administrator＠lamere.net 16 Apr '98

16 Apr '98

Further investigation is showing that these routes are not advertised outside of alter.net, but they are advertised on alter.net's network. Sorry to scare everyone. Curtis Maurand <m0yPqrD-002pBUC(a)rhoen.regio.net>, on 04/16/98 at 05:45 PM, horke(a)mail.regio.net (Bernhard Kroenung) said: >> alter.net is advertising private routes 192.168.nnn.nnn. who do I >> contact to get that shutdown? >gw1.regio.net>show ip bgp 192.168.0.0 255.255.0.0 longer-prefixes >gw1.regio.net> >I do not see any ... > Ciao > Bernhard -- ----------------------------------------------------------- Curtis Maurand System Administrator lamere.net Business Center We'll get you Wired. administrator(a)lamere.net -----------------------------------------------------------

1 0

Re: AT&T DSNOC status
by Bob Collie 16 Apr '98

16 Apr '98

Well.. they list the following: BFLONY80 PHLAPA81 SHOKCA80 SNFPCA80 of which I can decipher three: BFLONY - Buffalo, NY PHLAPA - Philadelphia, PA SNFPCA - San Francisco, CA I do somewhat doubt that these dispersed switches are the root of the problem as they have clearly said that it was between two of the switches.... But, as usual, I could be wrong. -Bob --On Wed, Apr 15, 1998 9:58 PM -0400 "Rob M VanHooren" <rob(a)linkd.net> wrote: > > FYI, status on AT&T F/R can be had at +1 732 885-7791, option 2. > > (But I bet you already knew that...) > > --R. > > PS: Interesting, it also lists med-sev tickets on 4 nodes, effective at > exactly midnight tonight. All CA-80 gear, too (Cisco/Strata?). If you > can decipher Bellcore's CLLI/CLEI conventions from memory better than I > can, my guess is you'll find the original nodes that freaked out. > > Anybody around have a copy of Bellcore's DERG, LIDB-LARG, GEL, or other > TRA tables on CD-ROM they'll let me have a peek through? I'd buy them > myself, but I'm too poor (and too cheap - heheheh). > > > ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-.._..-*~ > Rob M. VanHooren - Chief Plumber, +1 519 679-1155 x33 > Packet Pusher, and Resident Mad Scientist(tm) Alarms to 646-4724 > Network Engineering Services 171 Queens Avenue, Suite 320 > Linkdata Communications Inc. London, CANADA > -- Bob Collie, VP/Chief Technical Officer, Telalink Corporation mailto:bob.collie@telalink.net

3 2

Lame RFC1918 delegations
by Barry Margolin 16 Apr '98

16 Apr '98

Several people have forwarded to me a message you sent to NANOG saying that the problem with the RFC 1918 delegations was fixed yesterday. As far as I can tell, this is not true. I'm still seeing lame responses from both blackhole.isi.edu and ns2.internic.net (which replaced rs0.internic.net in the delegations yesterday). Also, we have a system here configured as a secondary server for the RFC 1918 domains, so that we can point customer firewalls to it for their zone transfers (this way, if the original primary moves, we only have to update one system, not all the firewalls). It used to use ns.isi.edu as its primary, but that stopped working on 3/25. Is there a machine that can be used instead? tools:~#58% whois 172.16 IANA (IANA-BBLK-RESERVED) Internet Assigned Numbers Authority Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 Netname: IANA-BBLK-RESERVED Netblock: 172.16.0.0 - 172.31.0.0 Coordinator: Internet Assigned Numbers Authority (IANA-ARIN) iana(a)iana.org (310) 822-1511 Domain System inverse mapping provided by: BLACKHOLE.ISI.EDU 128.9.64.26 NS2.INTERNIC.NET 198.41.0.11 tools:~#61% dig -x 172.16 any @blackhole.isi.edu ; <<>> DiG 2.1 <<>> -x any @blackhole.isi.edu ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 2, Addit: 2 ;; QUESTIONS: ;; 16.172.in-addr.arpa, type = ANY, class = IN ;; ANSWERS: 16.172.in-addr.arpa. 295906 NS RS0.INTERNIC.NET. 16.172.in-addr.arpa. 295906 NS BLACKHOLE.ISI.EDU. ;; AUTHORITY RECORDS: 16.172.in-addr.arpa. 295906 NS RS0.INTERNIC.NET. 16.172.in-addr.arpa. 295906 NS BLACKHOLE.ISI.EDU. ;; ADDITIONAL RECORDS: RS0.INTERNIC.NET. 43877 A 198.41.0.5 BLACKHOLE.ISI.EDU. 25946 A 128.9.64.26 ;; Total query time: 427 msec ;; FROM: tools.bbnplanet.com to SERVER: blackhole.isi.edu 128.9.64.26 ;; WHEN: Fri Apr 3 09:39:09 1998 ;; MSG SIZE sent: 37 rcvd: 158 tools:~#63% dig -x 172.16 any @ns2.internic.net ; <<>> DiG 2.1 <<>> -x any @ns2.internic.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 4, Auth: 0, Addit: 2 ;; QUESTIONS: ;; 16.172.in-addr.arpa, type = ANY, class = IN ;; ANSWERS: 16.172.in-addr.arpa. 86400 NS NS.ISI.EDU. 16.172.in-addr.arpa. 86400 NS rs0.internic.net. 16.172.in-addr.arpa. 86400 NS ORB.ISI.EDU. 16.172.in-addr.arpa. 86400 SOA NS.ISI.EDU. bmanning.zed.ISI.EDU. ( 19941005 ; serial 10800 ; refresh (3 hours) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ;; ADDITIONAL RECORDS: NS.ISI.EDU. 172800 A 128.9.128.127 rs0.internic.net. 172800 A 198.41.0.5 ;; Total query time: 60 msec ;; FROM: tools.bbnplanet.com to SERVER: ns2.internic.net 198.41.0.11 ;; WHEN: Fri Apr 3 09:39:27 1998 ;; MSG SIZE sent: 37 rcvd: 190 -- Barry Margolin, barmar(a)bbnplanet.com GTE Internetworking, Powered by BBN, Cambridge, MA

3 3

AT&T DSNOC status
by Rob M VanHooren 16 Apr '98

16 Apr '98

FYI, status on AT&T F/R can be had at +1 732 885-7791, option 2. (But I bet you already knew that...) --R. PS: Interesting, it also lists med-sev tickets on 4 nodes, effective at exactly midnight tonight. All CA-80 gear, too (Cisco/Strata?). If you can decipher Bellcore's CLLI/CLEI conventions from memory better than I can, my guess is you'll find the original nodes that freaked out. Anybody around have a copy of Bellcore's DERG, LIDB-LARG, GEL, or other TRA tables on CD-ROM they'll let me have a peek through? I'd buy them myself, but I'm too poor (and too cheap - heheheh). ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-.._..-*~ Rob M. VanHooren - Chief Plumber, +1 519 679-1155 x33 Packet Pusher, and Resident Mad Scientist(tm) Alarms to 646-4724 Network Engineering Services 171 Queens Avenue, Suite 320 Linkdata Communications Inc. London, CANADA

1 0

NANOG 13 REGISTRATION
by Pam Ciesla 15 Apr '98

15 Apr '98

Our Registration Webpage was acting alittle strange, we have since corrected the problem. Please check the Attendee list if you have registered and are not on the list please re-register. Thanks, sorry for the inconvenience. Attendee list update at 10:30AM EDT 4/15. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0