January 1999 - Test - lists.nanog.org

RE: ATM Switch Interoperability
by Martin, Christian 16 Jan '99

16 Jan '99

We have it matched to the policing policy of the Network Provider. By increasing the CDVT, we gain some bucket depth, but we are only MUXing 5 VCCs over one VP. There shouldn't be too much clumping, espescially considering the load on the switches(low). One thing is interesting, though: The far end (customers) are all running over DS3 using HEC delineation. A curiosity: Given the parameters below for the contract, particularly the MBS and CDVT, does it appear that we are being cheated? From my understanding of the UNI 3.1 spec, the MBS should be adjustable according to SCR/PCR, given the fact that CDVT is defined as the same for both SCR and PCR buckets. One obstacle that myself and my colleagues have not been able to overcome is the use (aside from bucket calculation) of the Burst Tolerance. It is obviously proportional to the MBS, but again, it appears as if a contract specifying a PCR/SCR of 100000/50000 cells per sec, should have a higher MBS than a 10000/5000 cell/sec contract. Any insights? Chris -----Original Message----- From: Danny McPherson [mailto:danny@qwest.net] Sent: Friday, January 15, 1999 11:33 PM To: Martin, Christian Subject: Re: ATM Switch Interoperability Have you attempted increasing CDVT on LS1010? -danny "Martin, Christian" wrote: >All, > >Does anyone have an experience dealing with cell loss between LS1010s >and Cascade/Ascend CBX 500s using VBRnrt? It appears that either the >LS1010 or the CBX is performing UPC operations differently, as we are >seeing between .1 and 2% packet loss at the AAL, and .1 to .5% at the >cell level. By allowing flexibility in the policing, or by removing >policing completely on the Cascade boxes, cell loss disappears. It >appears that the LS may be sending cells too close together, but we are >unsure and cannot truly test thi without an Analyzer, of which no one >here has any experience using (even if we had one!). The parameters are >as follows: > >7513 w/AIP >PCR 30000 >SCR 15000 >mbs 3 (*32) = 96 >AAL5SNAP > >LS1010 >CDVT 600 >mbs 100 cell times >PCR 30000 CLP0+1 >SCR 15000 CLP0 > >Cascade (As far as I know) >mbs 100 >PCR 70754 cells/sec >SCR 35377 cells/sec >CDVT 600 > >I apologize for the vendor references, and I hope some don't view this >as off-topic! > >Regards, >Chris

1 0

RE: ATM Switch Interoperability
by Webb, Tremayne 15 Jan '99

15 Jan '99

Remember that the LS1010s do not shape the traffic and try to confirm that the other end is not the cause of the cell loss. -----Original Message----- From: Martin, Christian Sent: Friday, January 15, 1999 8:03 PM To: 'nanog(a)merit.edu' Subject: ATM Switch Interoperability All, Does anyone have an experience dealing with cell loss between LS1010s and Cascade/Ascend CBX 500s using VBRnrt? It appears that either the LS1010 or the CBX is performing UPC operations differently, as we are seeing between .1 and 2% packet loss at the AAL, and .1 to .5% at the cell level. By allowing flexibility in the policing, or by removing policing completely on the Cascade boxes, cell loss disappears. It appears that the LS may be sending cells too close together, but we are unsure and cannot truly test thi without an Analyzer, of which no one here has any experience using (even if we had one!). The parameters are as follows: 7513 w/AIP PCR 30000 SCR 15000 mbs 3 (*32) = 96 AAL5SNAP LS1010 CDVT 600 mbs 100 cell times PCR 30000 CLP0+1 SCR 15000 CLP0 Cascade (As far as I know) mbs 100 PCR 70754 cells/sec SCR 35377 cells/sec CDVT 600 I apologize for the vendor references, and I hope some don't view this as off-topic! Regards, Chris

1 0

Re: NRIC meeting
by Sean Donelan 15 Jan '99

15 Jan '99

As several folks pointed out. It should be Michael (Mike) Armstrong, chairman of AT&T. Obviously I was still thinking of the Senate trial of William (Bill) Clinton, and munged the names. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Is Internic Hosed?
by Jay Stewart 15 Jan '99

15 Jan '99

OBRandyDisclaimer: No, I did not mistake this list for the Internic NOC. I would have to be mental (or masochistic) to think of wasting my time attempting to do something as crude as using the telephone to contact the Internic. :-) OperationalContent: I got the attached error message when attempting to register a domain. I've also noticed responses to e-mail registration requests taking *MUCH* longer over the last couple of weeks. Has anyone else noticed problems? Is Internic hosed? Jay Stewart Vice President Olympia Networking Services - "Olympia's Premier ISP" http://www.olywa.net ------------- The original message was received at Fri, 15 Jan 1999 12:48:49 -0500 (EST) from opsmail.internic.net [198.41.0.91] (may be forged) ----- The following addresses had permanent fatal errors ----- "|/usr/local/lib/majordomo/wrapper archive2.pl -a -d -f /home/reg/mts/logs/hostmaster/hostmaster" (expanded from: hostmast) ----- Transcript of session follows ----- Can't append to /home/reg/mts/logs/hostmaster/hostmaster.990115: Interrupted system call at /usr/local/lib/majordomo/archive2.pl line 184. 554 "|/usr/local/lib/majordomo/wrapper archive2.pl -a -d -f /home/reg/mts/logs/hostmaster/hostmaster"... unknown mailer error 4

2 1

The Cidr Report
by Tony Bates 15 Jan '99

15 Jan '99

This is an auto-generated mail on Fri Jan 15 12:00:00 PST 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 15Jan99 0) General Status Table History ------------- Date Prefixes 080199 54976 090199 54679 100199 54744 110199 54918 120199 54860 130199 54884 140199 55099 150199 55155 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: 4408 Number of ASes announcing only one prefix: 2168 (1156 cidr, 1012 classful) Largest number of cidr routes: 355 announced by AS3561 Largest number of classful routes: 1013 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 389 144 245 63.0% UNKNOWN AS701 1013 860 153 15.1% UNKNOWN AS2493 319 173 146 45.8% UNKNOWN AS174 650 536 114 17.5% UNKNOWN AS5668 129 35 94 72.9% UNKNOWN AS3749 157 65 92 58.6% UNKNOWN AS4200 178 91 87 48.9% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4755 147 74 73 49.7% UNKNOWN AS4293 208 137 71 34.1% UNKNOWN AS549 218 152 66 30.3% UNKNOWN AS4740 388 326 62 16.0% UNKNOWN AS8517 134 75 59 44.0% UNKNOWN AS1221 395 336 59 14.9% UNKNOWN AS7657 142 87 55 38.7% UNKNOWN AS7545 111 58 53 47.7% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS3493 252 200 52 20.6% UNKNOWN AS7046 238 187 51 21.4% UNKNOWN AS1239 531 484 47 8.9% UNKNOWN AS10928 96 49 47 49.0% UNKNOWN AS7496 74 28 46 62.2% UNKNOWN AS577 210 164 46 21.9% UNKNOWN AS852 175 132 43 24.6% UNKNOWN AS719 452 409 43 9.5% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 71 35 36 50.7% UNKNOWN AS6897 62 27 35 56.5% UNKNOWN AS7122 109 75 34 31.2% UNKNOWN AS2764 327 294 33 10.1% UNKNOWN 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

NRIC meeting report
by Sean Donelan 15 Jan '99

15 Jan '99

I was in Washington DC yesterday (January 14) and had a choice. I had some free time and could either spend the afternoon at the Senate watching the trial, or I could go over to the FCC and watch the NRIC meeting. I choose the NRIC meeting. The Network Reliability and Interoperability Council, chaired by Bill Armstrong chairman of AT&T, moved along pretty quickly. Most of the focus was on Year 2000 issues telco issues. No great surprises, like most industries, most reports were positive were positive about the industry. Most telephone companies in the USA are on track to completing their Year 2000 project on time, and there are no PSTN to CPE year 2000 problems. Most of the problems were called "second-order" affects. For example, your T1 line and demarc have no Year 2000 issues, but your router or super-smart CSU/DSU might have some. POTS (plain old telephone service) seemed most unaffected. In other words a plain voice line with no options, and a Western Union 2500 telephone set. Its when you get into POTS+ services issues show up. The phone line works, but a fax machine may print the wrong date at the top of the fax page. 9-1-1 calls will go through, but some secondary PSAP equipment (e.g. GIS map systems, dispatching, voice recorder timestamping, etc) might have a year 2000 issue. A repeated theme of the meeting was the second-order problems were the customer's responsibility, and the customer needed to take action to fix them not the phone company. Things were pretty much focused on traditional wireline carriers. Very little was said about wireless, and there was no representation from new things such as the Internet or ISPs. Bill Armstrong reported he as sent two letters out, but received essentially no response. I'm not sure who Mr. Armstrong sent the letters to. I know I haven't ever received one. But I'm was amused to hear I'm not the only one who has trouble getting information out of ISPs :-) I'm not sure how many people on the Council realized it, but it was interesting to watch the Internet being transformed from a convenience to a critical component. Although neither the NRIC nor the FCC seem to know how to communicate with the ISPs, an amazing amount of information and contingency plans are primarily being distributed via the web. But there seems to be no contingency plan for keeping, or restoring the web operation. The contingency plans that do exist, currently exclude Internet service providers unless they happen to be part of a traditional wireline facility based provider. But even then, I've noticed the ISP NOC and the wireline NOC's at the same provider have no contingency plan for communicating with each other. I know, you've heard me beat that drum before. The final part of the meeting was the 1998 annual report from the Network Reliability Steering Committee. The full report is on the ATIS site, but a few highlights. You should read at least the last page on the AT&T frame-relay outage. The frame-relay part of the outage was only important in it caused congestion on the switched network when all the remote sites dialed up their backup lines at the same time. This year NRSC did a root cause analysis across all their outages and found "Procedural Errors" were the top root cause of 32% of all outages. DACS problems are continuing to increase, with 1998 being the highest year yet. Facility failures and CO power problems were continuing areas of concern. The NRIC committee asked the NRSC to track if the National One-Call legislation passed last year had any affect on the number of cable dig-ups. The NRIC web site is <http://www.nric.org/>. A number of reports and presentations are online. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Solution: Re: Huge smurf attack
by Peter Swedock 15 Jan '99

15 Jan '99

On Jan 13, 1:23pm, Phil Howard wrote: > > Filtering .0 and .255, or filtering echos or ICMPs, are all indeed a form > of "fixing" the symptom. These things are being done because fixing the > cause isn't practical. > > But what is the cause? Is it that kids with scripts will attack and try > to bring down an IRC server or the network that hosts it? Or is it that > they have the scripts in the first place? Or is it that they are using > networks that allow them to do this in the first place? I think blamin' the 'scriptkidz' in this instance isn't accurate. I think this incident had a political component that is overlooked here, and one that requires discussion. And that this smurfing was, quite possibly, an answer to that political component. I'm speaking about the "Nuremburg Files" which is downstream of Mindspring. For those of you who don't know, this page is a listing of abortion providers, clinic workers and their respective spouses. Those abortion providers and clinic workers who have been killed are struck-through on this page, those who have been wounded, or who have stopped providing abortions for whatever reason, are grayed out and those remaining are, for lack of a better term, targeted, through the collection of personal information (licsense plate numbers, home addresses, phone numbers, etc...) I bring this up, not to discuss content, but because a lawsuit has been brought, and which began Friday, against this page charging that it is a hit-list that crosses the line of free speech into incitement to violence. The suit has received some national attention (was prominently featured on the CNN webpage) and appears to be, at present, ground zero for the pro-life/pro-choice debates... Given all that, is it hard to beleive that some-one, moderately skilled in networking but extreme in political views, attempted to shut down this page by shutting down Mindspring? This is the real world, people. This isn't the goodgeeks vs. the skriptkiddiez in their own private internet bubble. It is entirely plausible (even likely, given the timing of the case opening Friday, the subsequent publicity and the "huge smurf attack" Saturday...) that this was a political act, and guess what... we're squeezed in the middle. It ain't about which side of the debate any on NANOG will fall on, but the fact that the debate may be falling on us. > The cause of burglaries and thefts is bad people. But the cause of political terrorism is extreme people. I think that, if this smurf attack was in response to the web page "The Nuremburg Files", it is an act of terrorism in response to an act of terrorism: that is to say the page is extreme, so why do we not expect responses to it to be extreme? And, in the middle, network engineers putting out the fires... networks being the battlegrounds that these people have chosen. > I admire Mindspring's position of making Internet access unrestricted. > But what is the real motivation? Is it the goal of "perfect IP" or is > the business case of decreasing tech support costs? They are, afterall, > in the business of providing consumer dialup access, and as we all know > that line of business is very costly in areas of tech support. Network > attacks are also a real cost. I would suggest that treating some of the > symptoms, at least for now, will cut some costs until the day that we > can achieve the utopian goal of the perfect solution to the cause. But if you want "unrestricted internet access" you'll get pages like "The Nuremburg Files" and you'll get people who object to that... I don't know what the solution is... but I do think we'll all be better off opening our eyes to the situation, rather than simply blaming the 'skriptkiddiez'. Peace, Petr -- "Everything should be made as simple as possible, but not simpler" A. Einstein Petr Swedock, Associate Engineer | Network Operations ,o __|-. GTE INTERNETWORKING, POWERED BY BBN ,_~o/ \/ \ ph: 781.262.6300/781.262.6541 |/ | fax: 781.262.6234 / > | ' ` | email: pswedock@bbnplanet.com/pswedock@gtei.net | ______________________________________________________________|

10 15

Anyone with a clue from Concentric?
by Vadim Antonov 14 Jan '99

14 Jan '99

Hi -- is there anyone with a clue from Concentric? The reverse DNS zones at Concenric are hopelessly screwed up and the only DNS person i was able to get hold of doesn't seem to know what he's doing. Please respond personally, and excuse me for bringing that to the list. --vadim

1 0

Re: Performance problems between sprint and uunet?
by jprovo＠ma.ultranet.com 14 Jan '99

14 Jan '99

>Apologies for bothering the list, but we have had tickets open with [snip] >Is anyone else seeing this? Yes, for quite some time. There's apparently an interconnect upgrade planned/in processes/in molasses. Cheers, Joe -- 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

Denver update
by Susan R. Harris 14 Jan '99

14 Jan '99

Greetings everyone - just wanted to let you know that we've made a couple of scheduling changes for the Denver NANOG meeting. As you know, the BGP routing tutorials by Howard Berkowitz and Avi Freedman will start at 1:00 p.m. on Sunday afternoon, Jan. 31. And, following suggestions from many of you, we'll be ending a bit earlier on Tuesday, most likely at noon or early in the afternoon. We've scheduled a few new presentations, and you'll find an update here: http://www.nanog.org/mtg-9901/topics.html Questions, comments welcome, send 'em to nanog-support(a)nanog.org. See you in Denver, where there CAN'T BE as much snow as we have in Michigan ...

1 0