- NANOG - lists.nanog.org

The Cidr Report
by Tony Bates 10 Jul '98

10 Jul '98

This is an auto-generated mail on Fri Jul 10 12:00:01 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 10Jul98 0) General Status Table History ------------- Date Prefixes 020798 51673 030798 51528 050798 51481 060798 51579 070798 52104 080798 52116 090798 52255 100798 52359 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.4.0/23 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.19.0.0/18 from AS4492 *** Bogus 216.214.0.0/18 from AS7194 AS Summary ---------- Number of ASes in routing system: 3726 Number of ASes announcing only one prefix: 1823 (952 cidr, 871 classful) Largest number of cidr routes: 353 announced by AS3561 Largest number of classful routes: 1139 announced by AS701 1) Gains by aggregating at the origin AS level --- 10Jul98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 461 253 208 45.1% IMCI AS3602 514 310 204 39.7% Sprint Canada Inc. AS2493 485 281 204 42.1% iSTAR Internet, Inc. AS701 1139 937 202 17.7% Alternet AS271 339 144 195 57.5% BCnet Backbone AS3749 223 66 157 70.4% TECNET AS174 727 587 140 19.3% Performance Systems International AS2685 267 162 105 39.3% IBM Global Network - US AS4755 114 39 75 65.8% Videsh Sanchar Nigam Ltd. India AS3221 112 42 70 62.5% EENet Autonomous System AS5668 120 51 69 57.5% Century Telephone Inc. AS7046 226 161 65 28.8% UUNET-CUSTOMER AS3804 216 153 63 29.2% Bell Solutions AS4740 394 334 60 15.2% ASN-OZEMAIL (Ozemail Pty Ltd) AS10928 102 45 57 55.9% UNKNOWN AS3403 181 127 54 29.8% TIAC AS549 205 152 53 25.9% ONet Backbone AS8517 123 72 51 41.5% ULAKNET-ASN AS6335 69 18 51 73.9% NTRNET AS72 85 37 48 56.5% Schlumberger Information Network AS4539 73 25 48 65.8% NETROPOLIS AS1239 543 496 47 8.7% SprintLink Backbone AS719 449 403 46 10.2% LANLINK autonomous system AS3218 70 24 46 65.7% AS-RSSI AS4200 140 95 45 32.1% AGIS (Apex Global Information Ser AS852 158 117 41 25.9% AGT Advance Communication AS7545 102 61 41 40.2% TPG Internet Pty Ltd AS762 118 80 38 32.2% WELLFLEET-AS AS1785 290 252 38 13.1% NYSERNet Backbone AS6181 65 28 37 56.9% FUSE-NET 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

Co-Lo in 60 Hudson
by Jonathan Arneault 10 Jul '98

10 Jul '98

Does anyone know if there is available Co-Lo in 60 Hudson, NYC? If so, can you send me a contact name & address? Thanks, Jonathan Arneault Director of Business Development CMA jarneault(a)corp.cma.com jarneault(a)inet-solutions.net 518.783.9003

1 0

Re: Linux Vice ( Was: NAT Box )
by John Fraizer 10 Jul '98

10 Jul '98

At 12:27 PM 7/10/98 -0600, Stephen Fisher wrote: > >Mmmmm-Bop! > >Ewww.. wait.. anything but HANSON! Only if the modify the lyrics to be: Mmmmmm-Bop! dit dit dit dah dah dah dit dit dit Bop! (With subliminal messages that say "Someone send ammunition quickly! I'v fired all I have into my TV and radio and this stupid frequin' song is still playing!") > >:-) > >On Fri, Jul 10, 1998 at 10:46:11AM -0600, Charlie Watts wrote: >> On Fri, 10 Jul 1998, Alan B. Clegg wrote: >> >> > From: "Alan B. Clegg" <abc(a)cyclue.bsdi.com> >> > > vice a Linux box? >> >> > Yes, I can see a linux box as a vice. 8) >> >> That'd make a cool TV show for geeks, dontcha think? Linux Vice! Anybody >> want to write the theme music? >> >> -- >> Charlie Watts Quidquid latine dictum sit, altum viditur. >> cewatts(a)frontier.net (Whatever is said in Latin sounds profound.) > >-- > - Steve > - Systems Manager > - Community Internet Access, Inc. > - Gallup and Grants, New Mexico > > ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

NAT Box
by Shaun S. Amini 10 Jul '98

10 Jul '98

Can anyone recommend a Network Address Translation box, preferably with a 100 MB Ethernet port? Shaun

7 6

Internic Database not Updating.
by chaz＠mill.net 10 Jul '98

10 Jul '98

Any reason why internic hasn't updated their database in over 24 hours??? And is there a web page over at internic that discusses such infomation?? thanks

1 0

Re: SPAM, RE: Internic and there lame response
by Aaron Goldblatt 10 Jul '98

10 Jul '98

>>The InterNIC, like all Internet users, is impacted by individuals >>who send out "spam" (bulk e-mailing) on the network. However, >>Network Solutions is responsible for the administration of the >>name space and not for policing its content or use. >True. Which is why you can not register fuck.com. ag

1 0

Interesting stratum 1 NTP clock
by Tony Li 09 Jul '98

09 Jul '98

Folks who run NTP in their nets might wanna check out: http://www.coetanian.com/tss/tss100.htm This is a reasonably affordable, NTP-ready, GPS based stratum 1 chimer, complete with 10BaseT interface. It's also getting close to being plug-n-play. I've been beta testing one for a couple of weeks and it seems to chime reasonably well. Tony p.s. I have no finanical interest in this product or this company whatsoever. I'm just a time geek...

12 14

Re: T1 Circuit actual throughput 1290Kbps
by prue＠ISI.EDU 09 Jul '98

09 Jul '98

Ron, >It isn't D4 or ESF framing that causes a loss in usable bandwidth on a >T1, but AMI line coding. As stated above, when using AMI line coding, >the T1 will not be provisioned for clear channel (64k) DS0s, but will be >provisioned for 56k DS0s, thus providing an aggregate bandwidth of 1344 >kbps. The least significant zero of each DS0 is forced to a 'one', thus >insuring correct ones density on the line. The better solution is B8ZS >coding, which allows full use of each DS0's bandwidth. >Inverting the data on the router won't give you back the "lost" 192 kbps >of bandwidth, since you're still limited to using 56kb/s of each DS0. Sorry but you are wrong. AMI has a ones density requirement which causes CSU's to inject ones if the data that is presented it doesn't have enough ones transitions. Running HDLC data inverted can and does cause enough transitions so that the CSU won't inject a one (injecting an error in the data) to keep the phone company multiplexers happy. Several early CSU's had various options to permit you to run at speeds above 1.344 Mb/s including a scrambling method (not fool proof), various proprietary encoding methods, and the hdlc invert option. In all cases if the encoding method failed to provide one's density then the CSU circuitry would inject the required ones. Note that the ones stuffing in every low order channel bit exceeds the ones density requirement of AMI ciruits. Most AMI circuits require no more than 15 zero bits in a row and at least three one bits in every 24 bits. I believe that there was the FCC part 68 rule and the 62411 rule if I remember it right. They were slightly different. Most early CSU manufacturers took the easy implementation method of low order bit ones stuffing, but that was not the only solution nore the most bandwidth efficient solution to assuring ones density and data intetrity. However if you are running on a channelized T1 circuit then you really are limited to 56k X 24 or 1.344 Mb/s. That is not related to D4 or AMI. You would see that with an ESF circuit as well.

1 0

Re: T1 Circuit actual throughput 1290Kbps
by Ron Buchalski 09 Jul '98

09 Jul '98

>Date: Thu, 9 Jul 1998 10:18:51 -0400 (EDT) >From: "Robert E. Seastrom" <rs(a)bifrost.seastrom.com> >To: dorian(a)blackrose.org >CC: ltd(a)interlink.com.au, tonyh(a)noc.cbn.net.id, nanog(a)merit.edu >Subject: Re: T1 Circuit actual throughput 1290Kbps > > > From: Dorian Kim <dorian(a)blackrose.org> > > > A T1 is capable of achieving 1536 kbps maximum (24 x 64 kbps). > > While this doesn't seem to apply to Tony's case, I wouldn't make a blanket > statements like that. If the T1 is provisioned ESF, yes you can get > 1536 kbps, but there are places where you still can only get SF/D4 framing. > >Precisely. The most likely explanation is that the T1 is actually D4 >framed, which gives it a throughput of (24 * 56kbps) == 1344k. Or the >T1 may be properly provisioned but the CSU/DSUs incorrectly configured >for the old-fashioned framing (I think I saw this working at one >point, can't remember for sure). The PPP is hardly eating anything at >all in the grand scheme of things. > > ---Rob It isn't D4 or ESF framing that causes a loss in usable bandwidth on a T1, but AMI line coding. As stated above, when using AMI line coding, the T1 will not be provisioned for clear channel (64k) DS0s, but will be provisioned for 56k DS0s, thus providing an aggregate bandwidth of 1344 kbps. The least significant zero of each DS0 is forced to a 'one', thus insuring correct ones density on the line. The better solution is B8ZS coding, which allows full use of each DS0's bandwidth. Inverting the data on the router won't give you back the "lost" 192 kbps of bandwidth, since you're still limited to using 56kb/s of each DS0. -rb Ron Buchalski SE, Cisco Systems ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re: T1 Circuit actual throughput 1290Kbps
by prue＠ISI.EDU 09 Jul '98

09 Jul '98

>In some cases, if you can't get B8ZS line coding, and have to use AMI, >you might have to drop to 24x56=1344kbps (and use one bit on each DS0 >to maintin 1's density), but even then, if your routers or DSUs can >invert the data, you can still go 24x64=1536kbps. (HDLC guarantees >zero-density ... so if you invert it, you get guaranteed 1's density.) Yep. I've done that since 1988 on old circuits that were delivered before B8ZS was available. It does work. However you still can not get 1.536 over a T1 in general, close but not quite. Cisco framing as well as PPP framing uses HDLC encoding. The rules for HDLC encoding say that any time there are 5 one bits in a row within the data portion of a frame, a zero bit is inserted by the transmitter and removed by the receiver. This adds to the overhead of the T1 link. It is of course possible to send data that never has 5 one bits in a row, but real data will have this. The 5 ones don't have to be only within a byte. The contiguous one bits can cross byte boundries to incur this ones stuffing algorithm overhead. Walt

1 0