- Test - lists.nanog.org

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

Cisco scripts??
by Tim Kempka 09 Jul '98

09 Jul '98

Does anyone know where I can get ahold of some sort of script that querys the routers via SNMP that shows the running configs on them? I want to have a web based interface that ONLY shows the running configs. I am aware of the built in http server that is on the routers, but I would rather do it via SNMP . Any information would be appreciated. Thanks, Tim Kempka ____________________________________________________ Tim Kempka E-Mail: tim(a)flash.net Network Engineer Pager: page_tim(a)flash.net FlashNet Communications Phone: 817-589-2390 ext. 378

8 7

Re: T1 Circuit actual throughput 1290Kbps
by Sean Butler 09 Jul '98

09 Jul '98

Tony Hariman wrote: >Does anybody have experience having a T1 circuit with PPP >encapsulation getting only 1290 Kbps maximum throughput looking >at "sh int" result from cisco router or MRTG ? Is it a long delay link running TCP traffic? Long delay links will always show significanlty lower utilization than the max theoretical... You can check out the following paper for more details, but I'll give a quick example below. Lakshman&Madhow "The Performance of TCP/IP for Networks with High BWxDelay products and random loss" ,IEEE Trans. on Networking Vol5(3), june 97, pp329-335 http://tesla.csl.uiuc.edu/~madhow/publications/ton97.ps >From that paper, you can create the following chart: Buffer Size Link Utilization 60K 81% 120K 87% 180K 91% 480K 99% The percentage utilization is based on the bandwidth * the delay, so if you have a T1 at 1536K with a delay of 400ms, you get just over 600K (very pessimistic... -- you can play with the numbers based on the delay of the link. My numbers are based on an analysis I did of a satellite link some time ago...) The buffer sizes are percentages of that 600K, at 10%, 20%, etc. The buffer size is also the queue length * the max packet size of the buffer.... So a Cisco with a default queue length of 40 and an MTU of 1500 = 60K, at which point you'd only see 81% utilization for 1 TCP session... That is just 1 session, so you'd expect to see higher utilization for more sessions. This all assumes FIFO queing... Another point to consider is that with Internet traffic, there are many many 'small flows' where it takes time to ramp up the send window size, and before the time it would ramps up to use the whole pipe, the flow is done Sean Butler

1 0

Re: Cisco scripts??
by Ron Johnson 09 Jul '98

09 Jul '98

I will have to say, that rtrmon is one of the best tools that we have for management of our routers. Simple, elegant, hard to port to non BSD, does all kinds of routine tasks easy. > > Does anyone know where I can get ahold of some sort of script that querys > > the routers via SNMP that shows the running configs on them? I want to > > have a web based interface that ONLY shows the running configs. I am aware > > of the built in http server that is on the routers, but I would rather do > > it via SNMP . Any information would be appreciated. > > I know someone said it can be done with SNMP but we don't do it that way here. > > http://www.vix.com/rtrmon/ > http://www.vix.com/vulture/ > > Both of these were paid for by Genuity but are freely redistributable. > -- > Paul Vixie > La Honda, CA "Many NANOG members have been around > <paul(a)vix.com> longer than most." --Jim Fleming > pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

3 2

Re: Cisco scripts??
by Paul Vixie 08 Jul '98

08 Jul '98

> Does anyone know where I can get ahold of some sort of script that querys > the routers via SNMP that shows the running configs on them? I want to > have a web based interface that ONLY shows the running configs. I am aware > of the built in http server that is on the routers, but I would rather do > it via SNMP . Any information would be appreciated. I know someone said it can be done with SNMP but we don't do it that way here. http://www.vix.com/rtrmon/ http://www.vix.com/vulture/ Both of these were paid for by Genuity but are freely redistributable. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

1 0

Re: Process management
by Sean Donelan 08 Jul '98

08 Jul '98

Ok, I give up, here are the cites (pun intended). The U.S. Military 'lessons learned' web site I refered too is http://redwood.do.langley.af.mil/ The Nuclear Regulatory Commission reports I refered too is http://www.nrc.gov/NRC/GENACT/GC/gcabout.html Information about subscribing to the mailing list is at the bottom of the page. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0