October 1999 - Test - lists.nanog.org

Re: "firewalls" at high speed -- resending
by Hank Nussbacher 03 Oct '99

03 Oct '99

Hopefully this gets thru this time since the last time I sent it (Sept 30) I received: <nanog(a)merit.edu>: Command died with status 2: "/private/majordomo/wrapper resend -l nanog -h merit.edu -s nanog-outgoing". Command output: Can't locate getopts.pl in @INC (@INC contains: /usr/local/perl-5.004_04/lib/sun4-solaris/5.00404 /usr/local/perl-5.004_04/lib /usr/local/perl-5.004_04/lib/site_perl/sun4-solaris /usr/local/perl-5.004_04/lib/site_perl .) at /private/majordomo-1.94.4/resend line 74. and no one from Merit has responded yet to my email. >Alex Rudnev observed, > >>Folks, why all you are saying about the Gigabit traffic for the firewall? >> >>Usially, firewall stand between intranet and internet, and it should >>proceed your upstream traffic, not more... And than, it's important to >>measure the throughput in packets/per_second, not in the gigabits... >> >>Everything other is true - I suggess no one good firewall can proceed >>gigabit traffic at all, and only a few specially designed boxes can >>proceed 100Mbit traffic. But just again - it's a rare case when you does >>have 100Mbit upstream link. Super Firewalls! http://www.data.com/issue/990521/firewalls.html Almost all hit 72Mb/sec or more whether NAT was disabled or enabled. To quote from the article: Once again we started with a baseline test. With no firewall on the test bed, we achieved TCP forwarding rates of 15.6 Mbyte/s over each four-minute run of the test scripts; this works out to nearly 125 Mbit/s. So why didnt we get the 200-Mbit/s theoretical maximum of a switched, full-duplex test bed? First and foremost, our measurements are taken at the application layer. Its likely that packet headers and the continuous opening and closing of SMTP connections took a bite out of the effective data rate. Second, clients offered lots of traffic that the rule sets expressly deniedso at least some of the time the wire was occupied carrying traffic that wouldnt be forwarded. Third, there may have been a firepower limitation in the amount of traffic our clients and servers could offer. We cant say for certain how much the degradation is due to application overhead, and how much to test platform limitations. I would think that 200Mb/sec is achievable with not much effort and perhaps the next testing round will prove it. -Hank

1 0

Sunday NANOG 17 activities
by Pascal Gosselin 02 Oct '99

02 Oct '99

Now that many of you are here, here is an update on the activites that are taking place tomorrow: Sunday MORNING: FREE activity, free transportation: Visit of Teleglobe's iNOC (International Network Operations Center), a futuristic NOC that is worth the visit. Two tours, departures from all three hotels, tour takes about one hour. First tour: 9:00am Holiday Inn Select 9:15am Hotel Wyndham 9:30am Hotel Delta Second tour: 10:15am Holiday Inn Select 10:30am Hotel Wyndham 10:45am Hotel Delta Please email pascal(a)mlink.net to reserve your spot for either tour. Sunday AFTERNOON: TUTORIALS (see http://www.nanog.org/mtg-9910/) Sunday NIGHT: PAYING activity, FREE transportation courtesy of Nortel Indoor Go-Karting, 9HP 42MPH go-karts. Bus leaves Wyndham hotel at 8:45pm. Please email pascal(a)mlink.net to reserve your spot. Cost is $35 Cdn + taxes (about $26 US taxes included), 30 minutes of track time including warm up, qualifications and finals in three categories. See you there! -Pascal +---------------------------------------------------------------+ Pascal Gosselin Montr�al, Qu�bec, Toronto, Ottawa, Hull, pascal(a)Mlink.NET Calgary, Vancouver tel.(514) 861-3737 Mlink Internet Inc. http://www.Mlink.NET/ fax.(800) MLINK-84 tel. (888) MLINK-56

1 0

Re: Martian list of IP's to block???
by rfuller＠3x.com 02 Oct '99

02 Oct '99

I used the ones Cisco outlined in their document IOS Essentials every ISP Should Know. Here is a copy of the list I use for out clients: deny ip host 0.0.0.0 any log deny ip 127.0.0.0 0.255.255.255 any log deny ip 10.0.0.0 0.255.255.255 any log deny ip 172.16.0.0 0.15.255.255 any log deny ip 192.168.0.0 0.0.255.255 any log deny ip xxx.xxx.xxx.0 0.0.0.255 any log deny ip 224.0.0.0 31.255.255.255 any log We are denyingy anyone that claims that their IP address is 0.0.0.0, Loopback addresses, all of the RFC 1918 addresses, address coming into us claiming they belong to our subnet, and multicast addresses. It seems to work for us. I also turn of ip directed broadcasts to minimize smurf/DoS attacks. If you would like a copy of the document I used, let me know and I'll e-mail a copy to you. Ron Fuller, CCDP, CCNP-ATM, CCNP-Security, MCNE, MCP 3X Corporation rfuller(a)3x.com "John M. Brown" <jmbrown(a)ihighway.net>@merit.edu on 10/01/99 04:18:29 AM Sent by: owner-nanog(a)merit.edu To: nanog(a)merit.edu cc: Subject: Martian list of IP's to block??? working on a document and was wondering if people could provide the various versions of the Martian list that is used... thanks

7 8

Re: Martian list of IP's to block???
by sthaug＠nethelp.no 02 Oct '99

02 Oct '99

> > deny ip 10.0.0.0 0.255.255.255 any log > > deny ip 172.16.0.0 0.15.255.255 any log > > deny ip 192.168.0.0 0.0.255.255 any log > > These three clauses will block things like ICMP would-fragment and > ttl-expired messages, in the event that some transitory bit of network > between your customer and someone else's customer is numbered using > RFC1918 address space (and causes such messages to be sent). > > I know of several networks which use RFC1918 addresses like this, > in the belief that since the elements with these numbers never > need to receive a packet from anybody outside the operator's network, > there is no need for the numbers to be globally unique. Unfortunately, they're wrong. > In my opinion, such RFC1918 visibility in the public network is > misguided, and half of the disruption to service caused by rules > like those above could be considered just punishment. Agreed. > Trouble is, the other half of the disruption is for your customers, > and you know who they're going to blame if they can't reach their > favourite repository of huge flesh-tone jpegs. > > Operational content: does anybody actually block packets inbound > from off-net, in the case where they are sourced from an RFC1918 > address? If so, do your customers complain? We (UNINETT, AS224) block RFC 1918 source addresses on our border routers, and have been doing so for a couple of years now. We have had zero complaints about this. We certainly intend to continue. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

nocs page updated
by Jared Mauch 01 Oct '99

01 Oct '99

It's been awhile since I 'validated' entries submitted on my nocs page. I have updated them all. I apologize if your entry was not udpated. You can find my page at http://puck.nether.net/netops/ It lists all the network operations centers that I have contact information for. Please feel free to fill out the form that allows you to update or submit a new entry. there is a link to it off the page. Thanks. - Jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |

1 0

Merit IRR transition to RPSL announcement
by Gerald Andrew Winters 01 Oct '99

01 Oct '99

Merit is pleased to announce that the RADB Internet Routing Registry database service has begun production use of the next-generation Routing Policy Specification Language (RPSL). After several weeks of beta trials, the service is production quality and Merit strongly recommends that users begin migration to the new database language. The new RPSL database contains both native RPSL objects, as well as objects mirrored in near real-time from the RIPE-181 database servers. RADB users can now query RPSL objects by issuing the following query: whois -h whois-rpsl.radb.net Objects may be submitted by sending mail to: auto-rpsl(a)radb.net Users may also use the Web-based GUI interface at: http://www.radb.net/irrj.html RPSL RFCs and Internet-Drafts are available through: http://www.ietf.org/html.charters/rps-charter.html IMPORTANT: --------- During the months of September and October, Merit will continue to operate both RIPE-181 and RPSL RADB database servers. As of November 1, 1999, the whois.radb.net and auto-dbm(a)radb.net services will default to the RPSL database. This means that whois queries to whois.radb.net after November 1 will return RPSL objects. RIPE-181 queries will still be possible after November 1 via whois queries to whois-ripe181.radb.net. RIPE-181 submissions can continue to be sent via email to auto-ripe181(a)radb.net. RIPE-181 submissions made between 11/1/1999 and 1/1/2000 will be visible on whois.radb.net as RIPE-181 objects converted to RPSL. The objects will be converted every five minutes from the whois-ripe181.radb.net database. Availability of the database in both syntax languages will ease the transition to RPSL by allowing users to view RIPE-181 objects converted to RPSL. After January 1, 2000, RIPE-181 object submissions will no longer be accepted. DATE CHANGE ---- ------ 9/1/1999 RADB begins production RPSL service and enters the final stage of RPSL transition. RPSL queries are available from whois-rpsl.radb.net and submissions may be sent to auto-rpsl(a)radb.net. RIPE-181 and RPSL databases operate in parallel. whois.radb.net and auto-dbm(a)radb.net default to RIPE-181. 11/1/1999 Default whois.radb.net and auto-dbm(a)radb.net addresses change to RPSL database. RIPE-181 queries still possible via whois-ripe181.radb.net and RIPE-181 submissions still possible via email to auto-ripe181(a)radb.net. auto-ripe181(a)radb.net submissions will be auto-converted to RPSL and mirrored to the RPSL database every 5 minutes. Therefore, auto-converted RIPE-181 submissions will be visible on whois.radb.net and corresponding RPSL entries may be overwritten. 1/1/2000 RIPE-181 queries and sumbmissions are no longer accepted and the RADB RPSL transition is complete. Comments or questions about the transition are welcome; please send email to db-admin(a)radb.net. --Gerald Winters Merit, IRRd Team

1 0

The Cidr Report
by Tony Bates 01 Oct '99

01 Oct '99

This is an auto-generated mail on Fri Oct 1 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 01Oct99 0) General Status Table History ------------- Date Prefixes 060999 63135 070999 63155 080999 62994 270999 64154 280999 63958 290999 64074 300999 64030 011099 64019 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: 5723 Number of ASes announcing only one prefix: 2996 (1637 cidr, 1359 classful) Largest number of cidr routes: 556 announced by AS701 Largest number of classful routes: 910 announced by AS701 1) Gains by aggregating at the origin AS level --- 01Oct99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 383 146 237 61.9% BCnet Backbone AS2609 127 13 114 89.8% EUnet-TN AS1221 585 478 107 18.3% TELSTRA-AS AS9269 128 28 100 78.1% Hong Kong CTI AS174 589 494 95 16.1% Performance Systems International AS7046 337 250 87 25.8% UUNET-CUSTOMER AS4293 228 142 86 37.7% Internal ASN for C&W AS577 263 178 85 32.3% Bell Canada Backbone AS7545 141 61 80 56.7% TPG Internet Pty Ltd AS7657 244 167 77 31.6% The Internet Group Limited AS7496 109 33 76 69.7% Power Up AS6944 92 16 76 82.6% RapidSite, Inc. AS3749 139 64 75 54.0% TECNET AS4200 181 109 72 39.8% AGIS (Apex Global Information Ser AS719 464 408 56 12.1% LANLINK autonomous system AS4740 342 288 54 15.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS2493 138 91 47 34.1% iSTAR Internet, Inc. AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS209 296 250 46 15.5% Qwest Communications AS6528 45 7 38 84.4% WORLD-LYNX AS549 200 162 38 19.0% ONet Backbone AS4755 112 76 36 32.1% Videsh Sanchar Nigam Ltd. India AS3737 99 66 33 33.3% PenTeleData Inc. (ASN-PTD) AS701 910 878 32 3.5% Alternet AS9453 33 2 31 93.9% Soongsil University AS7745 40 9 31 77.5% BIGSKY-AS AS4307 32 1 31 96.9% SVINET-1 AS1785 234 203 31 13.2% NYSERNet Backbone AS10479 40 9 31 77.5% ITESM-Rectoria Zona Norte AS1 489 458 31 6.3% GTE Internetworking 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

fiber cut in slc
by Christian Nielsen 01 Oct '99

01 Oct '99

Looks like another fiber cut. This one in SLC. Since this is a MFS cut, I bet this is the reason UU is seeing issues on their network. Christian (who will be in SLC in a few hours :)

1 0

C&W
by Morris Allen 01 Oct '99

01 Oct '99

Anyone else having Noc's problems with Cable & Wireless? They are killing us. thanks Morris Allen VidcomNet, Inc.

1 0

Interesting multiple OSPF area dilemma
by Dustin Clampitt 01 Oct '99

01 Oct '99

Greetings: I seek input on a decision I must make regarding using multiple areas in a network using OSPF as the IGP. I have reviewed the NANOG archive messages regarding OSPF hierarchy, KISS principle, OSPF design, etc., but I'd still enjoy some feedback. * We have an existing nationwide network all carried by a single ATM carrier. (Carrier "A") * The network is flat. Everything is area 0.0.0.0. Currently less than 1000 OSPF route table entries. * We are expanding the network via a second carrier. (Carrier "B") * As we do more business with the new carrier "B" we expect to swing cities currently on the "A" network over to the "B" network. * I have a fresh /18 from ARIN to apply to the build out with new Carrier "B" * Both networks will tie into the same hubs on the east and west coasts. The questions are: 1. Do I even consider creating a second area "1" for the new network? I don't have a huge number of routers, or routes, yet. Our existing address space is highly fragmented for various reasons, but that doesn't mean we shouldn't attempt to inject some order to the network as we move forward. 2. If we are successful in moving all business away from existing carrier "A" then we have to create a new area 0. That puts us in the position of having to put interfaces linking cities into the new area 0, while each city then has to have a unique new area for the "local" interfaces. I don't even want to think about virtual link games as I'm a big believer in the KISS principle. (I'm lazy, and I don't expect to be the one supporting this forever.) How do I move area 0? I suppose I could start by putting all inter-city links in the new network in area 0, but then right off the bat I have 2 OSPF areas in every new city. That seems to be counter to much that I've read. I expect the vast majority of "local" interfaces to be stub areas anyway. 3. Are any gains in route aggregation and fault tolerance offset by: * the additional "cost" of complexity * additional CPU load necessary to process multiple areas? More Gory details: Existing network "A": * East Coast hub with transit via UUNET * West Coast hub with transit via SAVVIS * 16 Satellite cities. Each city is dual homed to East/West Coast Hubs via ATM * 2 dozen routers in network. * Currently less than 1000 OSPF routes all in area 0. * BGP4 as the I/EBGP New network "B" * connects to same east/west coast hubs as network "A" * we have a fresh /18 to apply to this buildout --- I apologize for turning the list into OSPF design 101. It seems to me to be apropos and an interesting dilemma that may be faced by others who inherit a network that grew without benefit of a master plan. Actually, in deference to those list readers who I know at one time were formerly involved with this network, I'm sure there was a plan, but it was lost before I got here. And 2.5 years ago I probably wouldn't have recognized it if it came up and bit me on the butt. I could just punt, and put it all in area 0, but I just had to ask. Sincerely, Dustin Clampitt

3 2