July 2000 - Test - lists.nanog.org

RADB Maintenance on 7/19/00
by Mark A Gebert 22 Jul '00

22 Jul '00

On Wednesday 7/19/00, whois.radb.net which houses the RADB database will be down for approximately 15 minutes between 6-8AM EDT. All queries and submissions will be unavailable at that time. We are installing more memory to handle more of the load being put on the service. For the RADB Team, --geeb ------------------------------------------------------------- Mark A. Gebert Email: geeb(a)merit.edu Senior Research Programmer Voice:+1 734 936 2655 Merit Network, Inc Fax: +1 734 647 3185 4251 Plymouth Rd, Suite C, Ann Arbor, MI 48105-2785 ------------------------------------------------------------- If I show up at your door step, you probably did something to bring me there.... % cat std.disclaimers

2 3

Re: exchange point media
by Simon Leinen 22 Jul '00

22 Jul '00

>>>>> "ma" == Mikael Abrahamsson <swmike(a)swm.pp.se> writes: > I was under the impression that there is nothing magical about jumbo > frames and that there are no interoperational problems with them as long > as they're supported at all. Please correct me if I am wrong. I'm afraid you are wrong... all interfaces connected to a logical IP subnetwork should have the same MTU. For most Layers-2 there is a pretty well-established default such as 1500 for Ethernet, 4470 for FDDI (well for ATM many people use 4470 rather than the IETF suggestion of 9180). But for Gigabit Ethernet the only standard MTU is the Ethernet MTU (1500). For a new exchange point built on Gigabit Ethernet, it could be worthwhile to postulate a larger MTU such as 8192 or 9180 and make sure every participant actually uses exactly that. But most exchange points supporting GigE still provide bridging to legacy (Fast) Ethernet, on which larger MTUs are uncommon or not supported at all. And bridging between Layer-2s is similarly problematic to having different MTUs in a LIS, although I'm well aware that such configurations are being used in many places, and thanks to bridges that do clever stuff besides bridging this may even work more or less reliably. -- Simon.

6 6

Myrinet
by John Fraizer 22 Jul '00

22 Jul '00

-----BEGIN PGP SIGNED MESSAGE----- Does anyone on the list have any operational experience using Myrinet in quasi-production/production? We're looking for something that gives the performance of 1Gb/s minus the latency induced by most GigE devices. (I know. A little latency is not much of a tradeoff for the increased capacity but, I'm greedy!) For those of you who haven't heard of Myrinet at all, you can get information at http://www.myri.com/ - --- John Fraizer EnterZone, Inc -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQCVAwUBOXkerIbMmesdFkq5AQGoZwP/a8O6P5uD8F+cuvUeRgYu5HFxoWloY8T2 VSuCtrOpLlstvP3P4erN9OmKxJYPGPVe2i/FXWTZEicaXTzTJ0M7TeGY5piql/Zd MapMHsneXirahsUlTfdEBLmu5+u2Sa5q1+5EEMIQHSRuk+eac7qk12Zhv1xeYhRh R01XtIGKJKY= =/j3s -----END PGP SIGNATURE-----

1 0

More on black-holed reserved/8 block.
by Valdis.Kletnieks＠vt.edu 21 Jul '00

21 Jul '00

As one person explained to me, often miscreants broadcast a bogus route so they can launch an attack from a 'reserved' space. What I was probably not clear enough in my original question was why the person at bungi.com was even TRYING to traceroute to a 98/ address. Was it something that showed up in a access log as an failed attempt, or? Is it the case that above.net is black-holing packets with a *destination* in the RBL, but *not* filtering packets with a *source* address from the RBL? If so, this would still allow RPC-based attacks (and TCP as well, if the victim's box had bad sequence number prediction). What are other sites that use the RBL BGP feed doing in this case? (And yes, I understand that many routers can route to a blackhole destination a lot faster than they can apply an ACL on the source). -- Valdis Kletnieks Operating Systems Analyst Virginia Tech traceroute to 98.100.32.32 (98.100.32.32): 1-30 hops, 38 byte packets 1 main.bungi.com (207.126.97.9) 2.15 ms 1.73 ms 1.86 ms 2 above-gw2.above.net (207.126.96.217) 4.41 ms 4.88 ms 3.67 ms 3 core5-main2-oc3.sjc.above.net (216.200.0.205) 3.62 ms 4.56 ms 7.53 ms 4 core3-core5-oc48.sjc2.above.net (208.184.102.206) 6.34 ms 5.7 ms 5.3 ms 5 iad-sjc2-oc48.iad.above.net (216.200.127.25) 73.0 ms 79.7 ms 72.6 ms 6 hat.address.is.on.the.rbl.see.www.mail-abuse.org.for.more.information.above…

3 3

Correction: Re: MAE-West Ames (Gigaswitch)
by Sean Donelan 21 Jul '00

21 Jul '00

The problem was with the MAE-West(Ames) SmartSwitch Router (SSR). It had a Control Module fail, not the Gigaswitches. Also in other news, the problems with Pacific Bell Internet on Thursday was blamed on an AT&T router. The problems with Pacific Bell Internet on Friday was blamed on a configuration error.

1 0

The Cidr Report
by Tony Bates 21 Jul '00

21 Jul '00

This is an auto-generated mail on Fri Jul 21 12:00:00 PDT 2000 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 21Jul00 0) General Status Table History ------------- Date Prefixes 140700 82006 150700 82099 160700 81998 170700 81940 180700 82120 190700 82574 200700 82381 210700 82529 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: 7959 Number of ASes announcing only one prefix: 4467 (2482 cidr, 1985 classful) Largest number of cidr routes: 964 announced by AS701 Largest number of classful routes: 1068 announced by AS701 1) Gains by aggregating at the origin AS level --- 21Jul00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 436 149 287 65.8% BCnet Backbone AS7046 638 397 241 37.8% COQUI-NET PRTC Internet AS1221 560 401 159 28.4% TELSTRA-AS AS9706 154 21 133 86.4% Pusan Metropolitan City Office of AS2609 128 8 120 93.8% EUnet-TN AS7657 295 187 108 36.6% The Internet Group Limited AS9304 123 17 106 86.2% Hutchcity AS7545 155 57 98 63.2% TPG Internet Pty Ltd AS6429 213 115 98 46.0% RDC-INTERNET AS9269 154 63 91 59.1% Hong Kong CTI AS7496 126 38 88 69.8% Power Up AS4293 334 247 87 26.0% Internal ASN for C&W AS174 553 467 86 15.6% Performance Systems International AS577 256 171 85 33.2% Bell Backbone AS705 327 250 77 23.5% ALTERNET-AS AS724 218 150 68 31.2% DLA-ASNBLOCK-AS AS1727 161 94 67 41.6% MRMS-WEST AS3908 256 190 66 25.8% Supernet, Inc. AS701 1068 1007 61 5.7% Alternet AS6595 112 51 61 54.5% DODDSEUR AS5106 95 35 60 63.2% AADS-COLUMBUS AS3749 121 62 59 48.8% TECNET AS7568 81 24 57 70.4% C.S. Communications Co., Ltd. AS7018 551 494 57 10.3% AT&T WorldNet Service Backbone AS3602 300 244 56 18.7% Sprint Canada Inc. AS4755 154 101 53 34.4% Videsh Sanchar Nigam Ltd. India AS4740 323 271 52 16.1% Ozemail Pty Ltd (ASN-OZEMAIL) AS7993 78 28 50 64.1% Global One Communications AS1785 359 311 48 13.4% NYSERNet Backbone AS11252 86 38 48 55.8% Idaho State University 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

Sprint/AOL
by Richard A. Steenbergen 21 Jul '00

21 Jul '00

Ok fine I'll be the first one to say it... Is it just me (and I know it isn't :P) or did, well, all of Sprint decide to take a puke from 12:30AM EDT till around 1AM EDT? Simultanious with a significant failure to route AOL from a large number of networks... -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

4 3

MAE-West Ames (Gigaswitch)
by Sean Donelan 20 Jul '00

20 Jul '00

It appears its the Gigaswitch on the Ames side of Mae-west this afternoon. Multiple ISPs reported the Gigaswitch is having problems, but most said they are using alternate routes and customers should see little impact. In other news, PacBell Internet is reporting problems with northern california connectivity.

1 0

Re: someone RBL'd a reserveD-8 number from IANA
by Simon Leinen 20 Jul '00

20 Jul '00

>>>>> "pv" == Paul Vixie <vixie(a)mibh.net> writes: > I've also thought that if routers could filter based on lookup up > source addresses in a BGP-made RIB, rather than just destination > addresses, that the whole filtering-by-remote-control industry would > appreciate the hell out of it. I'm pretty sure that both the 12016 > and M160 have the hardware it would take to do this at wire speed, > but I'm also pretty sure that the market for this feature is > perceived by both vendors as "small." Cisco's "QoS Policy Propagation via BGP" could almost be used to implement this. The feature is described in http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/bgppr… You can map packets to a service policy according by source(!) or destination address, using an index (the "qos-group") that is stored in the FIB by a route-map action in BGP. The only problem is to define a service policy that drops such packets unconditionally. I haven't found a solution for that, but if there's enough demand, Cisco could easily come up with such a service policy I guess. Otherwise I think the following configuration should do it, given a sufficiently recent IOS: class-map illegal-source-addresses match qos-group 78 ! policy-map drop-illegal-source-addresses class illegal-source-addresses !!! note: the following doesn't work because the bandwidth has to be !!! at least 8 (kbps). Maybe Cisco could be talked into !!! implementing a "drop" command that could be used instead. bandwidth 0 ! interface POS2/1/0 description Evil Outside World bgp-policy source ip-qos-map ! router bgp 1234 table-map mark-illegal-source-addresses neighbor 5.6.7.8 description Vixie's BGP Feed Of Illegal Prefixes neighbor 5.6.7.8 remote-as 5678 ! ip as-patch access-list 56 permit ^5678_ ! route-map mark-illegal-source-addresses match as-path 56 set ip qos-group 78 -- Simon.

1 0

Re: someone RBL'd a reserveD-8 number from IANA
by Richard A. Steenbergen 20 Jul '00

20 Jul '00

On 20 Jul 2000, Paul Vixie wrote: > I've also thought that if routers could filter based on lookup up source > addresses in a BGP-made RIB, rather than just destination addresses, that > the whole filtering-by-remote-control industry would appreciate the hell > out of it. I'm pretty sure that both the 12016 and M160 have the hardware > it would take to do this at wire speed, but I'm also pretty sure that the > market for this feature is perceived by both vendors as "small." Paul I'm pretty sure we're not the only ones who have been asking for this. A dedicated protocol for managing filters would be even nicer, but perhaps a little too difficult to put together. Actually I think you might be very close to being able to put something like this together with some of Juniper's policying routing features, with either slight changes or upcoming software features. Congratulations to those who created an ASIC with enough functionality and generic design to do these kind of things. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0