- Test - lists.nanog.org

RE: 12000 ACL issue
by Rubens Kuhl Jr. 21 Oct '01

21 Oct '01

Sup2(6500 or 7600) is not demand-based, there is no flow-based forwarding on it; it can actually go that far, but you are right about past (and most of current) Cisco claims. In order to have 30 Mpps inside 15Gbps traffic, packet size on the line would be 62.5 bytes and no silence between packets would be allowed. When preambles and inter-frame-gaps are included, bottom line traffic would be higher, and real packet size distribution would make it usable for up to lot more traffic. As this thread was started by ACL issues, are the 50/90/150 Mpps boxes you mentioned capable of ACLs at these line rates ? What other beasts besides IP II, Sup2, Eng 3 and Eng4/edge can handle high-rate ACLs ? Rubens Kuhl Jr. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Pete Kruckenberg Sent: Friday, October 19, 2001 3:44 PM To: nanog(a)merit.edu Subject: RE: 12000 ACL issue On Fri, 19 Oct 2001, Rubens Kuhl Jr. wrote: > Why do you think 6500/7600 doesn't have the required performance ? 30 > Mpps Sup 2 with fabric-enabled line-cards can perform incredibly > well... Having FlexWAN and other non-fabric line-cards will slow down > to 15 Mpps, which is usually enough. VLAN L3 interfaces are > required only on CatOS (which is today required by POS > modules, unfortunately), but not on Supervisor IOS. Those are advertised numbers, best-case assuming flows that can be distributed away from the MSFC. My experience with Cisco in the past is they rarely get close to advertised numbers, YMMV. Not that even 30Mpps (15Gb/s) is adequate for a GigE aggregation device, and 15Mpps (7Gb/s) is not enough. Even then, other vendors are advertising on the order of 50-90Mpps in the same size chassises, and at least in my lab they are achieving that. For the same price or less than 6500, lots less than 7600. And larger chassises are avaiable doing on the order of 150Mpps. In my experience, service providers that are doing lots of L3 GigE are not using 6500's or other Cisco products, at least for GigE services. 6500 is still strong in the L2 GigE space. With 10GigE, Cisco is even less appealing. SONET is a different story, of course. Pete.

2 2

RE: 12000 ACL issue
by Goodwin, Dustin T [IT] 21 Oct '01

21 Oct '01

It seems like just yesterday everyone was blown away by an OC-48 capable router. Now everyone is bitching that they can't apply access lists on 8 port GE card. I am absolutely blown away by what a short memory everyone in this industry has. - Dustin -

2 1

abha
by Randy Bush 20 Oct '01

20 Oct '01

abha is no longer with us in body. her s.o. says her family is probably going to hold a private service. if i learn where it is appropriate to send flowers, fruit, etc. i will post. randy

1 0

RE: 12000 ACL issue
by Rubens Kuhl Jr. 20 Oct '01

20 Oct '01

It seems that GigE edge features (ACL, rate limiting) is scheduled to be addressed with the 10-GigE port card for 12400, with the "Engine 4 with extra sauce". It was supposed to be available at this time frame, can anyone confirm or deny this ? Amyway, the distributed architeture of GSR means you need to heavily look, insist and beat them regarding having all the features you need on all possibile media cards, but time has shown that so far it didn't work. So, my message to Cisco is that if Cisco wants to use the "distributed versus centralized" slogan in the war against competition, it must provide all features at all possible media interfaces: POS, GigE, ATM, channelized Tn. Rubens Kuhl Jr. -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Leo Bicknell Sent: Friday, October 19, 2001 12:25 PM To: nanog(a)merit.edu Subject: Re: 12000 ACL issue On Fri, Oct 19, 2001 at 09:55:39AM +0100, James A. T. Rice <james_r-nanog(a)jump.org.uk> wrote: > Does anyone else here use ACL's on subinterfaces of single GigE > linecards on GSRs? As of 12.0(16S), the ability to type 'ip > access-group' while in the subinterface configuration was removed, > leaving me stuck on 12.0(15S3). > > Cisco seem to be under the impression that BBC are the only customer > who used this feature, if anyone else ACL's on GigE subinterfaces, > please get in touch so we can correct them. We've been beating on them for some time over this issue. In my personal experience, you can put the ACL on the physical port - making sure of course it passes everything you want it to for _every_ vlan on that interface allowing you to filter some traffic. Basically the ACL on the physical interface seems to get applied to every subinterface. Cisco has clearly not gotten the message, so for all those Cisco people reading this I will restate it clearly: _ALL_ interfaces must support basic ACL's or we're not going to buy them from you. There is no such thing as an interface that doesn't need ACL's, no matter how much you rationalize it. A number of us are already speaking out on this issue with our $$$ taking it to vendors who understand this. You don't need 50,000 line ACL's, 37 kinds of QOS, or all that other crap on every card, but the ability to do a 10 line filter is a critical feature, and not having it is like not having a routing engine, it makes the box useless. -- Leo Bicknell - bicknell(a)ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

5 7

The Cidr Report
by CIDR Report 20 Oct '01

20 Oct '01

This is an auto-generated mail on Fri Oct 19 23:00:00 PDT 2001 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 19Oct01 0) General Status Table History ------------- Date Prefixes 121001 104773 131001 104893 141001 104864 151001 104979 161001 105115 171001 105004 181001 105147 191001 104997 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: 11802 Number of ASes announcing only one prefix: 7010 (3983 cidr, 3027 classful) Largest number of cidr routes: 852 announced by AS701 Largest number of classful routes: 1392 announced by AS701 1) Gains by aggregating at the origin AS level --- 19Oct01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1231 944 287 23.3% Telstra Pty Ltd AS4151 306 171 135 44.1% USDA AS13999 136 9 127 93.4% Mega Cable S.A. de C.V. AS16473 201 76 125 62.2% Bell South AS577 304 184 120 39.5% Bell Advanced Communications Inc. AS4293 373 266 107 28.7% Cable & Wireless USA AS2048 216 116 100 46.3% State of Louisiana AS271 161 74 87 54.0% University of British Columbia AS11686 224 143 81 36.2% Education Networks of America AS4755 201 124 77 38.3% Videsh Sanchar Nigam Ltd. Autonom AS1239 488 414 74 15.2% Sprint AS12302 106 35 71 67.0% MobiFon S.A. AS4200 141 74 67 47.5% Apex Global Information Services, AS19632 72 7 65 90.3% Metropolis Intercom S.A. AS3464 160 96 64 40.0% Alabama SuperComputer Network AS17557 131 69 62 47.3% Pakistan Telecom AS16758 63 6 57 90.5% IKON Office Solutions AS209 308 253 55 17.9% Qwest AS306 60 6 54 90.0% National Guard Bureau AS226 146 93 53 36.3% Los Nettos AS400 136 85 51 37.5% Headquarters Standard Systems Cen AS17561 111 60 51 45.9% Internet service provision to Wes AS1913 155 106 49 31.6% Defense Logistics Agency AS1 527 479 48 9.1% BBN Planet AS10620 68 21 47 69.1% TVCABLE BOGOTA AS4323 247 201 46 18.6% Time Warner Communications, Inc. AS15290 248 202 46 18.5% AT&T Canada IES AS376 120 75 45 37.5% Reseau Interordinateurs Scientiqu AS16814 64 19 45 70.3% NSS, S.A. AS5106 81 38 43 53.1% Ameritech Advanced Data Services, 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

Re: WSJ: Trade Center Attack Highlights Problem
by Frank Coluccio 20 Oct '01

20 Oct '01

re: >One interesting thing I found during my research since September 11 is the Internet held up well because of its extensive use of alternate providers. < Lest we forget, there were considerable problems bringing certain IXs back on line that were in the affected zone back on line for a over a week after the day of the attacks, due to problems assoicated with on-site power generation. But ignoring those exceptions... ... yes, the Internet held up nicely, like you say, but for many reasons, including its use of alternate providers. Another reason, if we're to look at this in a comparative sense (which I've inferred is the case), that is, how the 'Net fared versus how 140 West Street did, was because none of the Internet's main exchanges or hubs took direct hits. ISPs and NSPs were spared a tremendous amount of grief, imo, but only as a result of serendipitous consequences, because the Twin Towers were NOT located just a couple of blocks closer to 60 Hudson Street. Even as it was, there was ongoing speculation that structural damage did exist at 60 Hudson, but fortunately those were _only_ speculations, as it turns out (and as far as I know). But had the towers been an 8th of a mile closer to 60 Hudson things would have turned out far differently for the 'Net, not only domestically, but internationally as well. Has anyone assessed the level of risk that exists to the 'Net due to the high levels of traffic concentration at 60 Hudson. Or, 1 Wilshire in LA, for that matter? Curious. -FAC > > > Tommorrow's edition (Oct 19) of the Wall Street Journal > has yet another article about Verizon's 140 West Street > office. > > "Others say the extensive damage to Verizon's hub demonstrated that it > is dangerous to rely on one company. They point out that only with the > help of smaller competitors did parts of New York get their dial tones > back. > > "We have buildings that would have been waiting for Verizon to get the > service up if there were not alternatives," says Agostino Cangemi, the > New York City commissioner in charge of telecom franchising > > One interesting thing I found during my research since September 11 > is the Internet held up well because of its extensive use of alternate > providers. Verizon tends to be very expensive, so ISPs needing lots > of "cheap" bandwidth purchased service from a variety of competitors. > Much of this was not planned, nor did ISPs have a clue where their > circuits ran. It just happened due to Adam Smith's invisible hand. > > That's not to say CLECs didn't have problems. AT&T/TCG was walloped > hard, and several ISPs have essentially abandoned some TCG facilities > because they won't be repaired for a long time. MFN lost a huge > amount of fiber. Worldcom won't say how bad MFS/Brooks/etc was hit > but Worldcom customers report their circuits were out for 3-4 weeks > and may not be repaired until the end of the year. > >

2 1

Content filters
by J.D. Falk 20 Oct '01

20 Oct '01

...that reply to the sender are inappropriate for public lists which allow such words (though, admittedly, that's not as bad as the ones that'll respond to the entire list.) ----- Forwarded message from System Attendant <MAIL-SA(a)syndesis.com> ----- Return-Path: <MAIL-SA(a)syndesis.com> Received: from MAIL.syndesis.com (sky.syndesis.com [206.221.244.80]) by unagi.cybernothing.org (8.11.3/8.10.1/JDF) with ESMTP id f9K3wK516479 for <jdfalk(a)cybernothing.org>; Fri, 19 Oct 2001 20:58:20 -0700 (PDT) Received: by mail.syndesis.com with Internet Mail Service (5.5.2653.19) id <QJHH61N6>; Fri, 19 Oct 2001 23:46:55 -0400 Message-ID: <E8484D0D9B25D511915B00D0B77419D90131C42B(a)mail.syndesis.com> From: System Attendant <MAIL-SA(a)syndesis.com> To: "'J.D. Falk'" <jdfalk(a)cybernothing.org> Subject: ScanMail Message: To Sender, sensitive content found and action t aken. Date: Fri, 19 Oct 2001 23:46:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-MD5-Body-Hash: 03a731afec1b89b05b34f6e14ec9f4ed Trend SMEX Content Filter has detected sensitive content. Place = nanog(a)nanog.org; ; Sender = J.D. Falk Subject = Re: NOC Question Delivery Time = October 19, 2001 (Friday) 23:46:50 Policy = Dirty Words Action on this mail = Quarantine message Warning message from administrator: Sender, Content filter has detected a sensitive e-mail. ----- End forwarded message ----- -- J.D. Falk "you can bomb the world to pieces, <jdfalk(a)cybernothing.org> but you can't bomb it into peace" -- Michael Franti

1 0

NOC Question
by Kath 20 Oct '01

20 Oct '01

Curious Question: What does your NOC look like (Or could you describe it any)? For some companies, it looks like NASA Mission Control (http://www.pihana.com/corporate/nocpictures-EN.htm) and for others it is like a closet with 2 guys inside with one watching DivX rips and the other running DOS ping. - James

13 16

RE: 12000 ACL issue
by Goodwin, Dustin T [IT] 20 Oct '01

20 Oct '01

Obey the power point presentation. 6513 with redundant sup and sfm gives you 9 usable slots. Each DFC card gives 15 Mpps forwarding and 16 GE ports. So that is in marketing land 144 GE ports and 135 Mpps. Plus netflow for accounting. Plus ACLs like the PFC2 has? Now throw in the new OSR line cards that can do traffic policing or shaping for thousands of flows at line rate using the PXF processor array. The goods news, it's real fast (maybe). The bad news, you can't afford to buy it. - Dustin -

1 0

What ISPs can do
by Sean Donelan 19 Oct '01

19 Oct '01

1. Keep the net running During any crisis keeping the lines of communications working is a key requirement. Almost every review of crisis and emergency response showed the importance of keeping communication systems working. (http://www.dtic.mil/ndia/2001wmd/scalingi.pdf) Unplugging things without reason seems to always make things worse. 2. Maintain the integrity of net data Implement procedures to assuring the integrity of the control data used in the net. This isn't the content of communications, but the routing and control data. This can be as simple as setting and synchronizing clocks used to generate timestamps, verifying IP address announcements, anti-spoofing filters, use routing passwords, patching known security holes. 3. Single point of contact A crisis is not the best time to learn that an ISP has decided to implement a voice mail system which won't allow any outside contact with their NOC until a 17 digit customer number is entered. All communciation providers need a reliable method to contact each other during a crisis. 4. Standardized law enforcement assistance forms Both law enforcement and ISPs need to work on specifying what the ISP needs from law enforcement and what law enforcement expects back from the ISP. There are a lot of language problems between the two groups, and often they don't understand what the other side is saying. It would also speed up the process of verifying the lawful authority for releasing the information if law enforcement knows ahead of time what ISPs expect. I understand we're not lawyers, that's why it needs to be decided ahead of time by the lawyers. But as engineers we can figure out what information is required to respond to specific, though generic, types of actions. It will also cut down on the mistakes which have happened.

1 0