- NANOG - lists.nanog.org

N-Base Vulnerability Advisory
by TTSG 21 Jul '98

21 Jul '98

Hello, I won't post it in its entirety, but if you have any N-Base equipment, you might want to check out : The Telecom Security Group http://www.ttsg.com/TTSG/ ** TTSG VULNERABILITY ADVISORY ** Summary: Date: July 20, 1998 Subject: N-Base vulnerability Contact Address: nbase(a)ttsg.com Result: Comprimise security of switch, or render inoperable

1 0

Stac compression ?
by HANGU JEONG 21 Jul '98

21 Jul '98

Hi ! I would like to know that the modem throghput concerned with stac compression. The most of users using 56K V90 modems in windows 95 environment. Does anyone have idea about stac compression? Thanks Regards Jeong

1 0

MCI, CA*Net, & ANS routeserver information
by Jason Lixfeld 20 Jul '98

20 Jul '98

I'm looking for a little information on these routeservers. Currently, I am posting all information to the RADB but I am not sure if I should also be sending objects to the aforementioned DBs aswell. My upstreams are UUNet (AS816), SprintLink via Rogers Network Services (AS6463), CA*Net via Bell Global Solutions (AS3804) and soon to be linked to Sprint Canada directly. Is RADB sufficient? If so, why? If not, why? If I need to post objects to other route servers where can I find documentation on where to send the objects (ie: RADB is auto-dbm(a)ra.net and dbm-admin(a)ra.net) Any help would be appreciated. -- Regards, Jason A. Lixfeld Network Engineer, iDirect Network Operations --------------------------------------------------------------------- TUCOWS Interactive Ltd. | Internet Direct Canada Inc. 5415 Dundas Street West | Suite 301, Toronto Ontario | (416) 233-6036 x 18 (T) M9B-1B5 CANADA | (416) 236-5804 (F) --------------------------------------------------------------------- jlixfeld(a)idirect.ca | jlixfeld(a)idirect.com ---------------------------------------------------------------------

2 1

Re: MCI, CA*Net, & ANS routeserver information
by Joe Provo - Network Architect 20 Jul '98

20 Jul '98

> I'm looking for a little information on these routeservers. I'd suggest re-visiting the IRR web data from the RA/Merit (http://www.merit.edu/radb/docs/irr.html) for another description, check the infopage.mci.net data. The IRR is the collection of all the Routing Registries. If your provider/IP registry has their own routing registry, they will generally expect you to use it, or make provisions with them to pull data from other RRs. All others (generally those of us in the US) go thru the RA's RR. > be sending objects to the aforementioned DBs aswell. My upstreams are > UUNet (AS816), SprintLink via Rogers Network Services (AS6463), CA*Net via > Bell Global Solutions (AS3804) and soon to be linked to Sprint Canada > directly. Check with "Bell Global Solutions" WRT their relation with the CA*Net RR. That's the only potential confusion in what you list. > If I need to post objects to other route servers where can I find > documentation on where to send the objects (ie: RADB is auto-dbm(a)ra.net > and dbm-admin(a)ra.net) Each registry will have their own methods. I'm curious what the ANS/MCI registries will consist of/who they will be used by with all the merges and acquisitions... Cheers, Joe Provo -- Joe Provo, Network Architect 508.229.8400 x3006 Commercial Internet Services Group Fax 508.229.2375 UltraNet Communications, Inc., an RCN Company <jprovo(a)ultra.net>

1 0

Real world broadband backbone architecture. Thanks
by Yu Ning 20 Jul '98

20 Jul '98

Hi friends, I've found here is plenty of traffic in the list, so I hope my question can be answered. Thanks in advance. I'm curretly on a survey of current broadband data network backbone. And I 've heard that many ISP, or US national testbed has adopted ATM as the infastructure to support upper layer IP service, such as UUnet (siad have around 300 ATM switch connected, really?), vBNS, Internet2, Sprint .... But I just can't find detailed discription about their network architecture and method/model to integrated IP with ATM, only some network topology map and service info can be found in their site (except in vBNS, comprehensive archetecture info can be found). Because there are many academic debate about the shortcoming of ATM to support, I just want to see in the real world, why and how the operator/testbed do it. Can any friend give recommend me some URL, or article on this, such as of UUnet or Sprint? Thanks. Yu Ning. ----------------------------------------------------------------------* Yu Ning ATM R&D Center BUPT (Beijing U. of Posts&Telecom) Beijing (ZIP: 100876, MBox: 147#), P. R. China Tel:86-10-62283123; Fax:86-10-62283124 mailto:yuning@mindless.com or yuning(a)263.net -------------------------------------------------------------------------

1 0

Real world broadband backbone architecture. Thanks
by Yu Ning 18 Jul '98

18 Jul '98

Hi friends, I've found here is plenty of traffic in the list, so I hope my question can be answered. Thanks in advance. I'm curretly on a survey of current broadband data network backbone. And I 've heard that many ISP, or US national testbed has adopted ATM as the infastructure to support upper layer IP service, such as UUnet (siad have around 300 ATM switch connected, really?), vBNS, Internet2, Sprint .... But I just can't find detailed discription about their network architecture and method/model to integrated IP with ATM, only some network topology map and service info can be found in their site (except in vBNS, comprehensive archetecture info can be found). Because there are many academic debate about the shortcoming of ATM to support, I just want to see in the real world, why and how the operator/testbed do it. Can any friend give recommend me some URL, or article on this, such as of UUnet or Sprint? Thanks. Yu Ning. ----------------------------------------------------------------------* Yu Ning ATM R&D Center BUPT (Beijing U. of Posts&Telecom) Beijing (ZIP: 100876, MBox: 147#), P. R. China Tel:86-10-62283123; Fax:86-10-62283124 mailto:yuning@mindless.com or yuning(a)263.net -------------------------------------------------------------------------

1 0

Re: NOC communications
by Sean Donelan 18 Jul '98

18 Jul '98

>Having a different number/email address on your AS than what's on your >domain name might solve some of these problems- it might not. Being much >more aggressive and outwardly unfriendly to people who call the number on >your AS records becomes realistic if you have distinctly declared it for >NOC communications only. Please define "NOC communications only." Are Smurf reports considered NOC communications. How about Spam reports, spoofing addresses, or web pages being down? How about "I can't get through (i.e. I didn't want to wait) to your regular number so I called this one." Fact of the matter is every piece of contact information I have listed in ARIN's database or on a public web page has ended up on a junk mailing/calling list. The contact information which I only give out directly to other NOCs has NEVER been abused. Perhaps we should ask GTE Superpages, UUNET telemarketing, and Bull's Eye Target E-mail why do they use these particular set of contacts for their marketing efforts? >I disagree with your point that NOC-to-NOC communications should ever be >forwarded to a general number, even with adequate training. Is there a Turing test for contact information? There are organizations with extremely good communication operations which provide even better service than calling your favorite NOC engineer directly. Unfortunately they are rare, and as you pointed out, tend to only last as long as the next re-organization plan. >My point exactly - we all have proof that the current system doesn't work >very well. If it doesn't affect the share price, it seems like the management of most major ISPs could care less. This is, was, and always will be a management problem. We can come up with all the clever technical ideas to try to address reasons management gives for not doing something. But until some clever analysist decides this is an issue that can affect earnings, e.g. the Y2000 issue, not much is going to happen. >We already have a central authority that collects two perfectly good points >of information about each AS in North America (supposedly.) Yeah, right. Dear Sprint, Vab is gone. Since you have not updated your contact information in a prompt fashion, your AS numbers will be withdrawn at Midnight. Have a nice day. As far as most provider's are concerned there is no penalty for having out of date or bogus contact information. They view it as just one more added cost, and something that only benefits their competitors and not themselves. That is until they read about themselves on the front-page of the New York Times. Then the managers start yelling at the engineers "Why didn't you tell us it was a problem." Well, I think I've flogged this dead horse enough this time. Maybe we can have this discussion again in another six months. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

8 7

IS-IS or OSPF as BGP IGP
by Martin, Christian 17 Jul '98

17 Jul '98

All, Does anyone have any information on redistributing BGP traffic into OSPF versus ISIS? What about just carrying IBGP sessions? My OSPF database is growing, and I'd rather not carry LSAs with BGP routes as well as private routes, etc. Too messy. By introducing ISIS and using it only as a BGP IGP, what can I expect? Experiences with Cisco gear preffered. -Christian

1 0

preliminary 3q98 results
by Bill Manning 17 Jul '98

17 Jul '98

For your consideration. I appologise for duplicates. The 3rd quarter 1998 in-addr audit results. ------------------------------------------------------------------------- Refused are servers who refused to transfer the zone. <REFUSED> Errors were generally related to the following conditions: <timeout> - delegation to the host level e.g. 2.2.0.192.in-addr.arpa. This is also how the CNAME haq works for CIDR delegations so its hard to tell how much of an error this really is. - use of slashes e.g. 0/2.2.0.192.in-addr.arpa. An older method of doing bit-level delegation... - alpha strings e.g. test.2.0.192.in-addr.arpa. - other non-numberics e.g. #???.2.0.192.in-addr.arpa. - failure to fully qualify zones, e.g. the missing "." - event-horizon e.g. behind firewall Other failures seem to be related to server configuration or network reachability of either the end system or the nameservers used in generating the queries. The no-server number is the total of the refused, error, & other rows. inital zone runtime total# #correct no-svr refused error other 3q97 97667 657 h 380021 220030 57.9% 159991 26335 90832 42824 4q97 99587 654 h 478311 281368 58.8% 196861 26871 103108 66882 1q98 91555 372 h 500397 250107 50.1% 250210 54925 150114 45171 2q98 (1) 112 h 532504 253000 47.5% 279484 124626 31841 123017 3q98 100185 189 h 551631 277878 50.3% 273626 145592 (*) (*) (1) extrapolated from partial/overlapping data (corrupted disk) (*) intermediate results -- --bill

1 0

The Cidr Report
by Tony Bates 17 Jul '98

17 Jul '98

This is an auto-generated mail on Fri Jul 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 17Jul98 0) General Status Table History ------------- Date Prefixes 100798 52359 110798 52365 120798 52291 130798 52391 140798 52359 150798 52389 160798 52656 170798 52681 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 213.102.1.0 from AS3259 *** Bogus 214.0.0.0/8 from AS568 *** Bogus 215.0.0.0/9 from AS568 *** Bogus 216.0.0.0/14 from AS2548 *** Bogus 216.13.0.0/19 from AS6401 *** Bogus 216.13.32.0/19 from AS6401 *** Bogus 216.15.0.0/19 from AS10368 *** Bogus 216.15.128.0/19 from AS7393 *** Bogus 216.16.0.0/19 from AS6304 *** Bogus 216.18.0.0/19 from AS6539 *** Bogus 216.19.0.0/18 from AS4492 *** Bogus 216.22.0.0/19 from AS7960 *** Bogus 216.23.0.0/19 from AS8079 *** Bogus 216.27.0.0 from AS7349 *** Bogus 216.214.0.0/18 from AS7194 AS Summary ---------- Number of ASes in routing system: 3750 Number of ASes announcing only one prefix: 1827 (964 cidr, 863 classful) Largest number of cidr routes: 360 announced by AS3561 Largest number of classful routes: 1143 announced by AS701 1) Gains by aggregating at the origin AS level --- 17Jul98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 485 278 207 42.7% iSTAR Internet, Inc. AS3602 516 311 205 39.7% Sprint Canada Inc. AS701 1143 941 202 17.7% Alternet AS271 340 144 196 57.6% BCnet Backbone AS4293 450 257 193 42.9% IMCI AS3749 223 66 157 70.4% TECNET AS174 731 589 142 19.4% Performance Systems International AS2685 266 161 105 39.5% IBM Global Network - US AS5668 135 49 86 63.7% Century Telephone Inc. AS2764 428 347 81 18.9% connect.com.au pty ltd AS4755 117 41 76 65.0% Videsh Sanchar Nigam Ltd. India AS3221 112 42 70 62.5% EENet Autonomous System AS3804 220 155 65 29.5% Bell Solutions AS7046 228 165 63 27.6% UUNET-CUSTOMER AS4740 401 344 57 14.2% ASN-OZEMAIL (Ozemail Pty Ltd) AS10928 102 45 57 55.9% UNKNOWN AS3403 179 127 52 29.1% TIAC AS8517 123 72 51 41.5% ULAKNET-ASN AS6335 68 19 49 72.1% NTRNET AS72 85 37 48 56.5% Schlumberger Information Network AS1239 540 493 47 8.7% SprintLink Backbone AS719 450 404 46 10.2% LANLINK autonomous system AS4539 71 26 45 63.4% NETROPOLIS AS4200 142 97 45 31.7% AGIS (Apex Global Information Ser AS852 157 116 41 26.1% AGT Advance Communication AS762 118 80 38 32.2% WELLFLEET-AS AS1785 287 249 38 13.2% NYSERNet Backbone AS6392 66 29 37 56.1% MidWest Communications, Inc. AS6181 65 28 37 56.9% FUSE-NET AS549 174 137 37 21.3% ONet Backbone 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