- Test - lists.nanog.org

evening bof's
by Brett_Watson＠enron.net 02 Feb '99

02 Feb '99

does anyone know if bof's will be encoded for network playout? -brett

1 0

Re: spam whore, norcal-systems.net
by George Herbert 01 Feb '99

01 Feb '99

This posting, may perhaps not be a nanog charter violation, though the thread is highly borderline. Please don't shoot me. Ravi described a packet filter, not monitoring or intercept. Blocking traffic doesn't constitute unauthorized examination, intercept, or access of email. You are welcome to attempt to establish otherwise in a court case, Dean, but your interpretation appears completely inconsistent with existing case law, attorneys interpretations, and the intent of the statute. Again. -george william herbert gherbert(a)crl.com I don't work for CRL, speak for it, or anything else.

1 0

RE: Cisco >224.0/3 problems..
by Martin, Christian 01 Feb '99

01 Feb '99

Did you try ip mroute? RES-RTR6(config)#ip mroute 224.0.0.0 255.255.0.0 Null0 RES-RTR6(config)#no ip mroute 224.0.0.0 255.255.0.0 Null0 RES-RTR6(config)#^Z RES-RTR6# Feb 1 17:53:56 EST: %SYS-5-CONFIG_I: Configured from console by chris on consol e RES-RTR6# RES-RTR6#conf t Enter configuration commands, one per line. End with CNTL/Z. RES-RTR6(config)#no ip multicast-rou RES-RTR6(config)#ip mroute ? A.B.C.D Source address RES-RTR6(config)#ip mroute 224.0.0.0 224.0.0.0 null 0 RES-RTR6(config)#ip multicast-rou RES-RTR6(config)#no ip mroute 224.0.0.0 224.0.0.0 null0 RES-RTR6(config)#^Z RES-RTR6# > -----Original Message----- > From: James Rishaw [mailto:jamie@dilbert.ais.net] > Sent: Monday, February 01, 1999 2:07 PM > To: nanog(a)merit.edu > Subject: Cisco >224.0/3 problems.. > > > Hello all, > > Ran into a problem, thought maybe someone else has run into this and > knows of a "fix", if this is intentional or what not. > > It seems that Cisco IOS has a problem dealing with addresses above > 224.0.0.0/3. > > This came up in an e-mail with Paul Vixie about MAPS RBL, > where I asked > him why 224+ wasn't filtered. The reply was: IOS ignores it. > GateD likes > it, IOS doesn't. > > I'm finding that IOS isn't propagating routes, etc., (nor > will it even > seem to *recognize*) address space above 224. > > To wit: > > > As a /3: > bordercore1.chi(config)#ip route 224.0.0.0 224.0.0.0 Null0 > %Invalid destination prefix > > /8, close to the end of address space: > bordercore1.chi(config)#ip route 252.0.0.0 255.0.0.0 null0 > %Invalid destination prefix > > As a /24: > bordercore1.chi(config)#ip route 225.0.0.0 255.255.255.0 Null0 > %Invalid destination prefix > > bordercore1.chi(config)#ip route 230.0.0.0 255.255.255.0 Null0 > %Invalid destination prefix > > It's not Null0: > > bordercore1.chi(config)#ip route 234.128.230.123 255.255.255.255 h9/0 > %Invalid destination prefix > > bordercore1.chi(config)#ip route 241.102.34.93 > 255.255.255.255 atm4/0 > %Invalid destination prefix > > I know this is all "multicast" space, but considering > classless routing > and CIDR, shouldn't this space be usable and able to be manipulated ? > > -jamie > -- > jamie rishaw (efnet:gavroche) @ AIS / Exodus > "I want peace on earth and goodwill towards men." > "We are the United States Government. We don't do that sort > of thing." > --sneakers >

1 0

spam whore, norcal-systems.net
by Ravi Pina 01 Feb '99

01 Feb '99

Just a heads up- Down stream customer and end-user spammer norcal-systems.net via layer9.net started spamming yesterday afternoon. At first I was going to dismiss this and wait till Monday, but the complaints came in at a constant and fast pace. So I placed a filter on their network t about 3:00pm EST yesterday. Extended IP access list 142 deny tcp 216.115.78.0 0.0.1.255 eq smtp any log (2226195 matches) permit ip any any (57747076 matches) What was really great is when I called layer9.net's provider, their Abuse guy suggested that we just null0 the offending block, but needs to get approval from his manager. Since its obvious this customer is going to get booted, make sure they don't find you! -r

1 0

recent update from ARIN
by bmanning＠vacation.karoshi.com 01 Feb '99

01 Feb '99

Subject: Lowering of minimum allocation from /19 to /20 .... more should be on the ARIN web site soon... --bill

4 3

BGP Metrics
by Rusty Zickefoose 01 Feb '99

01 Feb '99

-----BEGIN PGP SIGNED MESSAGE----- Hi all, I've occasionally noticed a requirement to disregard mask when determining preferred route in the BGP algorithm. Specifically, when a multi-homed customer wishes to announce both his delegated networks through both connections. The goal is to achieve true multi-homing, with out requiring the customer to get independent address space. Thus far, I've used various "miserable hacks". Has anyone else perceived a similar requirement? if so, has anything being done to get such a flag added? Or am I just missing the obvious? - -- Rusty Zickefoose | The most exciting phrase to hear in science, rusty(a)cw.net | the one that heralds new discoveries, is not | "Eureka!", but "That's funny ..." | -- Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Public key may be found at http://pgpkeys.mit.edu:11371 iQCVAgUBNrXVHu4+ch/bGDylAQExFAQAx4Xpmssc5W7621ZdU7Dg4Xu0jLTVk9bH gfWqKmoagX3vfsMuGNR5mhaMTXCbjO5URBLGxtYAhAqy6uwLFJm3HLy8MNMMf/Iq wWMJTbcr9CeQnl9IhDkePusyHbFYwS5XV51uP19Xx0RnoLJkueeqMviVNSqEBJ/0 Q2BjjVEpGi4= =QIWi -----END PGP SIGNATURE-----

1 0

Busy Connect
by William Allen Simpson 31 Jan '99

31 Jan '99

I don't know how many other small/dialup ISPs are seeing this problem. BellSouth just turned it on in our area. Sent our support calls through the ceiling during busy evening hours. >Date: Mon, 25 Jan 1999 14:39:31 -0600 >Subject: Please Help Us >From: "Howard Shere" <hshere(a)watervalley.net> > >BellSouth recently added a feature to your phone service called "Busy >Connect". This service plays a recording whenever you dial and get a busy >signal offering to keep trying the number for 75 cents. This service will >interfere with your modems ability to detect a busy signal and your computer >will report that "the computer you are dialing is not answering" or some >similar message. > >2 weeks ago BellSouth told us that this service was on our lines and we >asked that it be removed. They told us that this would solve the "no answer" >problems that our customers were reporting. We have continued to get >complaints from customers about "no answer" problems and when we talked to >BellSouth today, we were told that this service was on our customers lines >and not on ours. We are not sure why we were given the wrong information >when we first reported this trouble. > >We are asking that all of our customers call BellSouth and ask to have this >service removed. They have refused to help us directly and have said that >the only way to have this service removed is for our customers to call them >directly. > >BellSouth can be reached at 557-6500 (for home telephone customers) or >557-6000 (for small business customers). Tell them you want the "Busy >Connect" service removed from your line. There is no charge from BellSouth >for removing this service. >

7 7

Hello, Denver
by alex＠nac.net 31 Jan '99

31 Jan '99

I am here, and if anyone wants to hang tonight, hollar! -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP; we have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

1 0

roamabout in denver
by Eric Kozowski 30 Jan '99

30 Jan '99

doens anyone know the roamabout network id that'll be used for in denver for the 915mhz roamabouts? also what ip addresses?

2 1

The Cidr Report
by Tony Bates 29 Jan '99

29 Jan '99

This is an auto-generated mail on Fri Jan 29 12:00:00 PST 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 29Jan99 0) General Status Table History ------------- Date Prefixes 220199 55393 230199 55423 240199 55417 250199 55453 260199 55539 270199 55623 280199 55634 290199 55694 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: 4470 Number of ASes announcing only one prefix: 2208 (1180 cidr, 1028 classful) Largest number of cidr routes: 350 announced by AS3561 Largest number of classful routes: 1028 announced by AS701 1) Gains by aggregating at the origin AS level --- 29Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 387 140 247 63.8% BCnet Backbone AS701 1028 870 158 15.4% Alternet AS2493 323 174 149 46.1% iSTAR Internet, Inc. AS174 645 533 112 17.4% Performance Systems International AS11305 116 8 108 93.1% UNKNOWN AS3749 149 67 82 55.0% TECNET AS4755 156 75 81 51.9% Videsh Sanchar Nigam Ltd. India AS1267 111 30 81 73.0% IUNET-AS AS4293 211 140 71 33.6% IMCI AS549 218 152 66 30.3% ONet Backbone AS4200 160 98 62 38.8% AGIS (Apex Global Information Ser AS7046 269 208 61 22.7% UUNET-CUSTOMER AS1221 396 336 60 15.2% AARNET-AS AS4740 378 320 58 15.3% Ozemail Pty Ltd (ASN-OZEMAIL) AS1239 527 473 54 10.2% SprintLink Backbone AS72 89 37 52 58.4% Schlumberger Information Network AS7657 141 90 51 36.2% The Internet Group Limited AS7545 109 58 51 46.8% TPG Internet Pty Ltd AS7496 77 28 49 63.6% Power Up AS577 221 172 49 22.2% Bell Canada Backbone AS10928 99 50 49 49.5% UNKNOWN AS719 452 408 44 9.7% LANLINK autonomous system AS3221 84 42 42 50.0% EENet Autonomous System AS852 173 135 38 22.0% AGT Advance Communication AS3561 723 685 38 5.3% MCI AS803 72 36 36 50.0% SaskNet Backbone AS6897 64 28 36 56.2% Global-One Spain AS7122 110 76 34 30.9% MTS ADVANCED Network Policy AS2764 330 297 33 10.0% connect.com.au pty ltd AS6332 101 70 31 30.7% TELNOR 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