RE: CIsco 7206VXR w/NPE-G1 Question
Richard J. Sears wrote: I am looking at upgrading my current 7507 backbone routers. Each of my routers has dual RSP4s Keep in mind that dual RSP does _not_ mean load sharing; it's for redundancy, if you can get RPR+ to work the way you want that is. and I was thinking of upgrading them to RSP8s when I started reading about the new 7206VXRs with the NPE-G1 engine. I was wondering if anyone has had experience with this router/engine combination, how well they perform in comparison to the RSP8s and actual total traffic capabilities when utilizing all three gig ports with a mixture of OC3, Gig and DS3 connections as well. In my experience, no 7507 is capable of this, nor a 7206VXR. As pointed out not too long ago, the RSP8 although intrinsically slower than a NPE-G1 will take more load because a lot of processing can be done by the VIPs in the 7507. The deal is that in a 7200 the NPE does the work of the RSP _plus_ the work of three VIPs; even if it's faster, it might not be that fast. That being said, I don't consider reasonable to get gig+ traffic trough a 7507; in my experience a 7500 will push 500mbps of traffic but will have trouble swallowing a full gig. My limited experience with the 7206 says that it might eventually be able to push _one_ gig from one PA to another, but not aggregate: say you have 4 or 5 OC3s aggregating into a GigE with some ACLs (which would run distributed on a 7500) I don't think that even the NPE-G1 is up to the task. IMHO, if you stay well below a gig, these el-cheapo eBay RSP8 deals are a valid solution but if you go over, GSR or Juniper is your answer. The 7200 has never been a core nor backbone router. Michel.
Re: updated root hints file
On Thu, Jan 29, 2004 at 10:44:42PM -0800, bill [EMAIL PROTECTED] wrote a message of 54 lines which said: http://www.root-servers.org/ seems to only have news on I's ASN change, no mention of B or J or the anycast F/K/I's ... methinks this info should have a home on this site.. why this site? Which site do you suggest?
RE: CIsco 7206VXR w/NPE-G1 Question
Michel Py wrote: My limited experience with the 7206 says that it might eventually be able to push _one_ gig from one PA to another, but not aggregate: say you have 4 or 5 OC3s aggregating into a GigE with some ACLs (which would run distributed on a 7500) I don't think that even the NPE-G1 is up to the task. Some notes (I sent some of these directly but since you're following up on-list, I will as well): * The 7206VXR prior to the NPE-G1 could only do around 560Mbps per bus typically, due to PCI limitations. * The NPE-G1 can do much more as the on-board 3xGE do not use the PCI bus (note, previous on-board GE ports in other 7200/7400 routers *did* still use a PCI bus). * As such, you have 3 ports which can run at gig rates, plus the ability to add two more gig ports (one per bus) around the 560Mbps rate. Or you can add OC3 cards on the other busses. But read Cisco's website re bandwidth points on PCI busses to confirm your intended configuration is viable if you intend to use many high-speed PAs. * Compiled ACLs on 12.2S perform very well on NPE-G1s. * Current IOS only uses one of the two CPUs present on the NPE-G1. An IOS which uses both CPUs is expected this year. However even with one CPU, the performance is significantly more than double a NPE400. * However you should do your own testing - it's a long time since I've done any performance tests and our production environment (being an Australian ISP) doesn't come close to 1Gbps on any interface but does use a lot of features (netflow, policing, NBAR, shaping, etc) with no performance hit. In the Australian environment, the 7206VXR NPE-G1 is a clear choice for many ISPs, due to the high demands on CPU-intensive features in the Australian environment and the massive performance improvements over the previous 7206VXR routers in the NPE-G1. David.
Kinda' funny...
http://www.theregister.co.uk/content/6/34919.html
Re: Misplaced flamewar... WAS: RE: in case nobody else noticed it, there was a mail worm released today
On 30-jan-04, at 7:20, Alexei Roudnev wrote: Second problem is directory structure. In Unix, when I configure IDS (osiris or Tripwire or Intact), I can just be sure, that 'bin' and 'etc' and 'sbin' and 'libexec' directories does not have any variable files - all non-static files are in /var (Solaris is an exception, they put some 'pid files into .etc, but even here, it is not a problem). But windose... you have not any directory which never changed, and I find few .dll files, changed every few days. Every application puts log and data files into it's own directory (with rare exception of applications, derived from Unix or written by people with Unix background). It makes terrible difficult to configure IDS, and makes system very vulnerable. Actually IMO putting all their crap in their own dir is a feature rather than a bug. I really hate the way unix apps just put their stuff all over the place so it's an incredible pain to get rid of it again. I think MacOS got it right: for most apps, installing just means dumping the icon wherever you want it to be, deinstalling is done by dropping it in the trash. The fact that the icon hides a directory with a bunch of different files in it is transparent to the user. And if an installer wants to mess with the system, a request to provide the administrator password comes up, even for users with administrator privilidges. Of course, it is all trade-off for functionality, but people overestimates it - many MS benefits come from it's dominance , not from functionality. I think MS's tradeoffs are mainly time to market vs even faster time to market. Hopefully they'll rip off Apple's ideas for their new stuff. Then add some zone alarm like stuff so apps can't mess with the network without the user's permission and we're in pretty good shape. And it all makes it a very good target for the viruses / worms. The fact that SMTP believes everything you tell it doesn't help either.
RE: Kinda' funny...
Sorry, I don't see the funny in 1200 people losing their homes. Is there something else to the story that I am missing? Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Painter Sent: January 30, 2004 1:03 AM To: [EMAIL PROTECTED] Subject: Kinda' funny... http://www.theregister.co.uk/content/6/34919.html
B.root-servers renumbering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Colleagues, This is to inform you about an IPv4 address change in b.root-servers.net. The old address is: 128.9.0.107 The new address is: 192.228.79.201 New Hints files can be found at: ftp://rs.internic.net/domain/db.cache ftp://rs.internic.net/domain/named.cache ftp://rs.ineternic.net/domain/named.root ftp://ftp.internic.net/domain/db.cache ftp://ftp.internic.net/domain/named.cache ftp://ftp.ineternic.net/domain/named.root The old address will continue to answer queries. John L Crain Manager of Technical Operations -BEGIN PGP SIGNATURE- Version: PGP 8.0 - not licensed for commercial use: www.pgp.com iQA/AwUBQBoiQtGxp5XUiliSEQIZQACg+cwOGbuSuE4FokrP7Sgl09cK8HkAnimQ JpFPJiPLJgS/5+q6PqoNE2Q3 =LJ/r -END PGP SIGNATURE-
Re: Kinda' funny...
- Original Message - From: Aaron Thomas [EMAIL PROTECTED] To: 'Michael Painter' [EMAIL PROTECTED] Sent: Thursday, January 29, 2004 11:13 PM Subject: RE: Kinda' funny... Sorry, I don't see the funny in 1200 people losing their homes. Is there something else to the story that I am missing? Aaron Your correct...poor choice for the Subject line and I apologize for that. I didn't mean it to refer to poor Niue at all, just the Register's take on the cc domains. --Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Painter Sent: January 30, 2004 1:03 AM To: [EMAIL PROTECTED] Subject: Kinda' funny... http://www.theregister.co.uk/content/6/34919.html
The Cidr Report
This report has been generated at Fri Jan 30 21:48:00 2004 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
23-01-04129825 91041
24-01-04129829 90960
25-01-04129792 90949
26-01-04129829 91029
27-01-04129940 90955
28-01-04129894 90911
29-01-04129760 90995
30-01-04129929 90988
AS Summary
16474 Number of ASes in routing system
6633 Number of ASes announcing only one prefix
1377 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 ATT WorldNet Services
73498880 Largest address span announced by an AS (/32s)
AS568 : SUMNET-AS DISO-UNRRA
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 30Jan04 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 130057909863907130.0% All ASes
AS4323 681 201 48070.5% TW-COMM Time Warner
Communications, Inc.
AS7018 1377 960 41730.3% ATT-INTERNET4 ATT WorldNet
Services
AS6197 676 263 41361.1% BATI-ATL BellSouth Network
Solutions, Inc
AS701 1348 951 39729.5% ALTERNET-AS UUNET
Technologies, Inc.
AS7843 513 116 39777.4% ADELPHIA-AS Adelphia Corp.
AS27364 382 33 34991.4% ACS-INTERNET Armstrong Cable
Services
AS6198 590 244 34658.6% BATI-MIA BellSouth Network
Solutions, Inc
AS4134 660 335 32549.2% CHINANET-BACKBONE
No.31,Jin-rong Street
AS22909 337 18 31994.7% DNEO-OSP1 Comcast Cable
Communications, Inc.
AS22773 337 35 30289.6% CCINET-2 Cox Communications
Inc. Atlanta
AS9583 311 19 29293.9% SATYAMNET-AS Satyam Infoway
Ltd.,
AS4355 385 99 28674.3% ERMS-EARTHLNK EARTHLINK, INC
AS1239 952 668 28429.8% SPRINTLINK Sprint
AS1221 902 644 25828.6% ASN-TELSTRA Telstra Pty Ltd
AS17676 293 42 25185.7% GIGAINFRA Softbank BB Corp.
AS6347 328 82 24675.0% DIAMOND SAVVIS Communications
Corporation
AS6140 358 125 23365.1% IMPSAT-USA ImpSat
AS25844 243 16 22793.4% SKADDEN1 Skadden, Arps, Slate,
Meagher Flom LLP
AS6478 267 45 22283.1% ATT-INTERNET3 ATT WorldNet
Services
AS209719 509 21029.2% ASN-QWEST Qwest
AS14654 2133 21098.6% WAYPORT Wayport
AS11305 243 42 20182.7% INTERLAND-NET1 Interland
Incorporated
AS2386 418 229 18945.2% INS-AS ATT Data
Communications Services
AS20115 605 419 18630.7% CHARTER-NET-HKY-NC Charter
Communications
AS4519 201 18 18391.0% MAAS Maas Communications
AS6327 205 28 17786.3% SHAW Shaw Communications Inc.
AS9929 199 30 16984.9% CNCNET-CN China Netcom Corp.
AS15270 208 39 16981.2% AS-PAETEC-NET PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS2048 248 84 16466.1% LANET-1 State of Louisiana
AS4766 409 248 16139.4% KIX Korea Internet Exchange
for 96 World Internet
Exposition
Total 14608 6545 806355.2% Top 30 total
Possible Bogus Routes
24.138.80.0/20 AS11260 ANDARA-HSI Andara High Speed Internet c/o Halifax
Cable Ltd.
64.62.126.0/23 AS25700
Re: An analysis.
Which one of you guys took down the world? We have separate carriers for internet, ATM, and Phone Whenever you get simultaneous outages for multiple telecom services at the same time it's almost always due to a local issue like a major cable cut or a central office fire. Sounds like a SONET ring that was either unprotected or both legs cut. After 10 minutes someone manually rerouted the circuits. --Michael Dillon P.S. Larry, what do you think? Leading by example?
reminder ipv4 allocation 83/8 (IANA to RIPE-NCC)
hello there, i just want to remind you, that IANA has allocated an new block in november 2003 (83/8). the reason why i remind again here is, we (as8514) have received a block within that range (83.64/15 -- RIPE-NCC) in the end of 2003 and customers complains still sites in the state they can´t reach. i kindly ask you to modifiy the BOGON list. thanks! christian steger -- Christian Steger| R D: Network Fon. 059 999 0 | Inode GmbH, Backbone Austria Fax. 059 999 6699 | Interxion, Shuttleworth Strasse 4-8, 1210 Wien www.inode.at| Raserei verbindet uns.
Re: Misplaced flamewar... WAS: RE: in case nobody else noticed it, there was a mail worm released today
On Fri, 30 Jan 2004, Iljitsch van Beijnum wrote: Actually IMO putting all their crap in their own dir is a feature rather than a bug. I really hate the way unix apps just put their stuff all over the place so it's an incredible pain to get rid of it again. Putting all crap in the working directory is bad design (no way to separate read-only stuff from mutable). Unix/Linux design (all over the place) is pure and simple lack of discipline, or hack before thinking approach. Plan 9 nearly got it right, but for the lack of persistent mounts (it's all in an rc file, executed at each login). I think MacOS got it right: for most apps, installing just means dumping the icon wherever you want it to be, deinstalling is done by dropping it in the trash. The fact that the icon hides a directory with a bunch of different files in it is transparent to the user. That's UI. Inside it's the same Unix crap. I think MS's tradeoffs are mainly time to market vs even faster time to market. It's mostly We don't care, we don't have to, we're The Microsoft mentality. --vadim
Re: updated root hints file
On Wed, Jan 28, 2004 at 09:19:43PM -0500, Coppola, Brian [EMAIL PROTECTED] wrote a message of 22 lines which said: In preparation for tomorrow morning's B-root IP change from 128.9.0.107 to 192.228.79.201 I notice trouble to reach the new server from many places. Here a machine connected by Global Crossing: master:~ % dig @192.228.79.201 SOA . ; DiG 9.2.1 @192.228.79.201 SOA . ;; global options: printcmd ;; connection timed out; no servers could be reached From other places, it works. I cannot find a common pattern. When it fails, the traceroute looks like (here from 146.82.138.7): master:~ % traceroute 192.228.79.201 traceroute to 192.228.79.201 (192.228.79.201), 30 hops max, 38 byte packets 1 mauser.brainfood.com (146.82.138.1) 0.232 ms 0.165 ms 0.121 ms 2 146.82.136.53 (146.82.136.53) 0.514 ms 0.478 ms 0.450 ms 3 146.82.136.9 (146.82.136.9) 0.422 ms 0.388 ms 0.368 ms 4 332.ge12-0.mpr1.dfw2.us.above.net (209.133.66.58) 0.828 ms 0.857 ms 1.162 ms 5 so-3-0-0.cr2.dfw2.us.above.net (216.200.127.217) 1.001 ms 0.990 ms 0.943 ms 6 pos3-0.er1.atl4.us.above.net (216.200.127.225) 18.004 ms 17.945 ms 17.921 ms 7 pos14-0.pr1.atl4.us.above.net (64.125.30.242) 18.015 ms 17.985 ms 17.954 ms 8 so-1-3.hsa2.Atlanta1.Level3.net (209.0.227.161) 18.123 ms 18.006 ms 17.997 ms 9 ge-6-2-1.bbr1.Atlanta1.Level3.net (64.159.3.73) 18.341 ms 18.142 ms 18.224 ms 10 so-3-0-0.mpls1.Tustin1.Level3.net (209.247.8.121) 53.037 ms 52.893 ms 53.471 ms 11 so-9-0.hsa1.Tustin1.Level3.net (209.244.27.174) 52.944 ms so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 52.913 ms so-9-0.hsa1.Tustin1.Level3.net (209.244.27.174) 52.884 ms 12 * * * 13 130.152.181.66 (130.152.181.66) 63.972 ms 65.680 ms 63.889 ms 14 * * * 15 * * * When it succeeds, I get (here from 66.93.172.18): voltaire:~ % traceroute 192.228.79.201 traceroute to 192.228.79.201 (192.228.79.201), 30 hops max, 38 byte packets 1 dsl093-172-001.pit1.dsl.speakeasy.net (66.93.172.1) 386.978 ms 59.405 ms 125.981 ms 2 border1.g4-3.speakeasy-40.wdc.pnap.net (63.251.83.187) 164.026 ms 306.738 ms 548.859 ms 3 core2.ge3-1-bbnet2.wdc002.pnap.net (216.52.127.72) 33.304 ms 242.007 ms 184.611 ms 4 ge-5-1-181.ipcolo1.Washington1.Level3.net (63.210.59.237) 78.556 ms 464.994 ms 357.447 ms 5 ae-0-56.bbr2.Washington1.Level3.net (64.159.18.162) 252.687 ms 518.383 ms 402.284 ms 6 so-3-0-0.mpls1.Tustin1.Level3.net (209.247.8.121) 631.193 ms 485.623 ms 500.692 ms 7 so-9-0.hsa1.Tustin1.Level3.net (209.244.27.174) 460.843 ms 259.303 ms 339.851 ms 8 67.30.130.66 (67.30.130.66) 305.469 ms 312.075 ms 341.656 ms 9 130.152.181.66 (130.152.181.66) 373.986 ms 499.069 ms 518.800 ms 10 b.root-servers.net (192.228.79.201) 461.216 ms 448.530 ms 488.763 ms So, apparently, 67.30.130.66 does not know how to reply to many places. IP addresses which have the problem: 192.134.4.152, 146.82.138.7, 194.117.194.82, 62.23.209.250.
Re: updated root hints file
On Thu, 29 Jan 2004, bill wrote: Well the answer is yes it changed a little while ago, having searched for a link to post I cant find one, thats bad.. http://www.root-servers.org/ seems to only have news on I's ASN change, no mention of B or J or the anycast F/K/I's ... methinks this info should have a home on this site.. why this site? I wanted info on root servers, root-servers.org seemed a good place, icann and iana were my second tries, then google, then i gave up.. someone mentioned k.root-servers.org, okay i didnt think to try that but i'd say the summary info and changes could be on www. otherwise i'm going to get bored checking 13 sites Steve Steve On Fri, 30 Jan 2004, Mr. James W. Laferriere wrote: Hello All , Hmmm , watching this thread having acquired the new cache ile I did a diff on it noticed that 'J' was changed as well (compared to MY cache file) . Did 'J' change sometime in the near past that I missed ? Tia , JimL ie: -B.ROOT-SERVERS.NET. 360 A 128.9.0.107 +B.ROOT-SERVERS.NET. 360 A 192.228.79.201 -J.ROOT-SERVERS.NET. 360 A 198.41.0.10 +J.ROOT-SERVERS.NET. 360 A 192.58.128.30 On Thu, 29 Jan 2004, Joe Abley wrote: On 29 Jan 2004, at 05:46, Randy Bush wrote: excuse me. this should be in a message from the iana signed with iana's pgp key ftp://ftp.internic.net/domain/INTERNIC_ROOT_ZONE.signatures (I agree, though, that a signed announcement from the proper authority would have been nice) Joe
RE: CIsco 7206VXR w/NPE-G1 Question
One more interesting feature - if you need a 4th GigE port, you can add the GigE I/O card which still uses none of the bus bandwidth points. The buses are fine for OC3 and below... Simon
Re: updated root hints file
On Thu, Jan 29, 2004 at 10:44:42PM -0800, bill [EMAIL PROTECTED] wrote a message of 54 lines which said: http://www.root-servers.org/ seems to only have news on I's ASN change, no mention of B or J or the anycast F/K/I's ... methinks this info should have a home on this site.. why this site? Which site do you suggest? the rssac site comes to mind, or B might put up a public site. but you did not answer my question. --bill
RE: CIsco 7206VXR w/NPE-G1 Question
Does anyone have definitive speed results on the 3 built-in Gig ports on the NPE-G1? I know that they aren't attached to the PCI Buses, and don't consume bandwidth points, but all of that is mute. Can all three of the ports do line rate Gig? The Gig PA is limited to 400Mbps. I have seen posts that allude to the fact the max throughput on the 3 Gigs are 800Mbps. It's is like a big mystery that cannot be solved. With a J M7i, I know I'm going to get line rate per port up to the total forwarding capacity of the FPC. We are trying to create a comparison matrix and any info you have would be great. Jack -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Hamilton-Wilkes Sent: Friday, January 30, 2004 9:36 AM To: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question One more interesting feature - if you need a 4th GigE port, you can add the GigE I/O card which still uses none of the bus bandwidth points. The buses are fine for OC3 and below... Simon ** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, ALLTEL requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else.
RE: CIsco 7206VXR w/NPE-G1 Question
Keep in mind, 72xx is still flow-based, so you need to count *both* shared fabric capacity (aka PCI buses) and capacity of NPE to establish flows (aka pps rate). NPE-G1 might probably route 3*GE, without any services and if all 3GE are in a single flow, but will melt down at a face of one-packet-per-flow DDoS (read: Nachi worm) at a far lower rate (I'd be surprised if it sustains 200kpps DDoS traffic, which can be as low as 150Mbit bandwidth). That is of course, as opposed to Juniper, which is truly line-rate at any interface, with any services, at any composition of traffic. -alex On Fri, 30 Jan 2004 [EMAIL PROTECTED] wrote: Does anyone have definitive speed results on the 3 built-in Gig ports on the NPE-G1? I know that they aren't attached to the PCI Buses, and don't consume bandwidth points, but all of that is mute. Can all three of the ports do line rate Gig? The Gig PA is limited to 400Mbps. I have seen posts that allude to the fact the max throughput on the 3 Gigs are 800Mbps. It's is like a big mystery that cannot be solved. With a J M7i, I know I'm going to get line rate per port up to the total forwarding capacity of the FPC. We are trying to create a comparison matrix and any info you have would be great. Jack -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Hamilton-Wilkes Sent: Friday, January 30, 2004 9:36 AM To: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question One more interesting feature - if you need a 4th GigE port, you can add the GigE I/O card which still uses none of the bus bandwidth points. The buses are fine for OC3 and below... Simon ** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, ALLTEL requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else.
Re: updated root hints file (fwd)
Date: Fri, 30 Jan 2004 11:39:40 -0500 To: bill [EMAIL PROTECTED] Subject: Re: updated root hints file I thought the RSSAC site was www.root-servers.org. root-servers.org is -NOT- the rssac site. --bill
RE: CIsco 7206VXR w/NPE-G1 Question
Do you get commission from Juniper? Matt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 16:51 Cc: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question Keep in mind, 72xx is still flow-based, so you need to count *both* shared fabric capacity (aka PCI buses) and capacity of NPE to establish flows (aka pps rate). NPE-G1 might probably route 3*GE, without any services and if all 3GE are in a single flow, but will melt down at a face of one-packet-per-flow DDoS (read: Nachi worm) at a far lower rate (I'd be surprised if it sustains 200kpps DDoS traffic, which can be as low as 150Mbit bandwidth). That is of course, as opposed to Juniper, which is truly line-rate at any interface, with any services, at any composition of traffic. -alex On Fri, 30 Jan 2004 [EMAIL PROTECTED] wrote: Does anyone have definitive speed results on the 3 built-in Gig ports on the NPE-G1? I know that they aren't attached to the PCI Buses, and don't consume bandwidth points, but all of that is mute. Can all three of the ports do line rate Gig? The Gig PA is limited to 400Mbps. I have seen posts that allude to the fact the max throughput on the 3 Gigs are 800Mbps. It's is like a big mystery that cannot be solved. With a J M7i, I know I'm going to get line rate per port up to the total forwarding capacity of the FPC. We are trying to create a comparison matrix and any info you have would be great. Jack -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Hamilton-Wilkes Sent: Friday, January 30, 2004 9:36 AM To: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question One more interesting feature - if you need a 4th GigE port, you can add the GigE I/O card which still uses none of the bus bandwidth points. The buses are fine for OC3 and below... Simon ** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, ALLTEL requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: CIsco 7206VXR w/NPE-G1 Question
Keep in mind, 72xx is still flow-based, so you need to count *both* shared fabric capacity (aka PCI buses) and capacity of NPE to establish flows (aka pps rate). Why do you say it is flow-based? You *do* use CEF, don't you? In which case 7200 with NPE-G1 is a prefix-based architecture, with software forwarding. NPE-G1 might probably route 3*GE, without any services and if all 3GE are in a single flow, but will melt down at a face of one-packet-per-flow DDoS (read: Nachi worm) at a far lower rate (I'd be surprised if it sustains 200kpps DDoS traffic, which can be as low as 150Mbit bandwidth). It's the pps that counts, not whether it is one packet per flow or many. We actually tested NPE-G1 a bit today with small (64 byte) packets, and we reached considerably higher pps numbers. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: CIsco 7206VXR w/NPE-G1 Question
Wow, that's quite an accusation. No, I don't use neither Cisco nor Juniper hardware in my network. For what its worth, 6500 with sup2 and better is also line-rate, at any mix of traffic, with any services. Happy now? Alex Pilosov| DSL, Colocation, Hosting Services President | [EMAIL PROTECTED](800) 710-7031 Pilosoft, Inc. | http://www.pilosoft.com On Fri, 30 Jan 2004, Matt Ryan wrote: Do you get commission from Juniper? Matt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 16:51 Cc: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question Keep in mind, 72xx is still flow-based, so you need to count *both* shared fabric capacity (aka PCI buses) and capacity of NPE to establish flows (aka pps rate). NPE-G1 might probably route 3*GE, without any services and if all 3GE are in a single flow, but will melt down at a face of one-packet-per-flow DDoS (read: Nachi worm) at a far lower rate (I'd be surprised if it sustains 200kpps DDoS traffic, which can be as low as 150Mbit bandwidth). That is of course, as opposed to Juniper, which is truly line-rate at any interface, with any services, at any composition of traffic. -alex On Fri, 30 Jan 2004 [EMAIL PROTECTED] wrote: Does anyone have definitive speed results on the 3 built-in Gig ports on the NPE-G1? I know that they aren't attached to the PCI Buses, and don't consume bandwidth points, but all of that is mute. Can all three of the ports do line rate Gig? The Gig PA is limited to 400Mbps. I have seen posts that allude to the fact the max throughput on the 3 Gigs are 800Mbps. It's is like a big mystery that cannot be solved. With a J M7i, I know I'm going to get line rate per port up to the total forwarding capacity of the FPC. We are trying to create a comparison matrix and any info you have would be great. Jack -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Hamilton-Wilkes Sent: Friday, January 30, 2004 9:36 AM To: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question One more interesting feature - if you need a 4th GigE port, you can add the GigE I/O card which still uses none of the bus bandwidth points. The buses are fine for OC3 and below... Simon ** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, ALLTEL requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
RE: CIsco 7206VXR w/NPE-G1 Question
Keep in mind, 72xx is still flow-based, so you need to count *both* shared fabric capacity (aka PCI buses) and capacity of NPE to establish flows (aka pps rate). Why do you say it is flow-based? You *do* use CEF, don't you? In which case 7200 with NPE-G1 is a prefix-based architecture, with software forwarding. Thanks for correction, yes, you are right, of course, that was a 'thinko'. To those watching on sideline: flow-based means router's performance is based on number of flows established, and first packet of each 'flow' is processed differently [slower] from all other within the flow, and things like nachi will kill it. NPE-G1 might probably route 3*GE, without any services and if all 3GE are in a single flow, but will melt down at a face of one-packet-per-flow DDoS (read: Nachi worm) at a far lower rate (I'd be surprised if it sustains 200kpps DDoS traffic, which can be as low as 150Mbit bandwidth). It's the pps that counts, not whether it is one packet per flow or many. We actually tested NPE-G1 a bit today with small (64 byte) packets, and we reached considerably higher pps numbers. I'm curious, what pps did you manage to get? -alex
Re: CIsco 7206VXR w/NPE-G1 Question
* The 7206VXR prior to the NPE-G1 could only do around 560Mbps per bus typically, due to PCI limitations. Which usually was not a problem with i-mix traffic or ddos-traffic, because pps limitation would hit sooner. * Compiled ACLs on 12.2S perform very well on NPE-G1s. I saw no mention of PXF on NPE-G1; it seemed the path 7200 would take after NSE-1. What happened ? interface but does use a lot of features (netflow, policing, NBAR, shaping, etc) with no performance hit. Features was indeed to focus of PXF, wasn't it ? Rubens
Re: CIsco 7206VXR w/NPE-G1 Question
Matt Ryan wrote: Do you get commission from Juniper? Where do I get my comission then? I´ve described inferior product as such many times and so far I haven´t seen deposits from vendors in my bank account? !!OT warning!! Pete Matt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 16:51 Cc: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question Keep in mind, 72xx is still flow-based, so you need to count *both* shared fabric capacity (aka PCI buses) and capacity of NPE to establish flows (aka pps rate). NPE-G1 might probably route 3*GE, without any services and if all 3GE are in a single flow, but will melt down at a face of one-packet-per-flow DDoS (read: Nachi worm) at a far lower rate (I'd be surprised if it sustains 200kpps DDoS traffic, which can be as low as 150Mbit bandwidth). That is of course, as opposed to Juniper, which is truly line-rate at any interface, with any services, at any composition of traffic. -alex On Fri, 30 Jan 2004 [EMAIL PROTECTED] wrote: Does anyone have definitive speed results on the 3 built-in Gig ports on the NPE-G1? I know that they aren't attached to the PCI Buses, and don't consume bandwidth points, but all of that is mute. Can all three of the ports do line rate Gig? The Gig PA is limited to 400Mbps. I have seen posts that allude to the fact the max throughput on the 3 Gigs are 800Mbps. It's is like a big mystery that cannot be solved. With a J M7i, I know I'm going to get line rate per port up to the total forwarding capacity of the FPC. We are trying to create a comparison matrix and any info you have would be great. Jack -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Hamilton-Wilkes Sent: Friday, January 30, 2004 9:36 AM To: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question One more interesting feature - if you need a 4th GigE port, you can add the GigE I/O card which still uses none of the bus bandwidth points. The buses are fine for OC3 and below... Simon ** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, ALLTEL requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
Re: in case nobody else noticed it, there was a mail worm released today
On Wed, Jan 28, 2004 at 07:37:09PM -0800, [EMAIL PROTECTED] said: Scott Francis [EMAIL PROTECTED] wrote: I've been wondering lately, after about 10 years of email worms spreading in exactly the same manner with every incarnation ... why do you think people haven't learned not to open unexpected attachments yet? Blaming it on end users is one way to look at the problem, but not a way that will result in a solution. You should be wondering, after 10+ years of virus laden MS operating systems, why they haven't fixed this stuff. Similar vulnerabilities in Unix, Mac, and other OS were fixed long ago. [snip] this is actually what I was driving at, but I've had so MANY anti-MS rants over the last few years, I thought I'd take a different tack. :) (Note: I really do not want this to degenerate into another rant against vendor M; Sorry for not sharing your disinterest in the actual reasons we continue to see these viruses and trojans infecting MS and, for all intents and purposes, only MS operating systems. oh, I share your position, believe me! It just seems that efforts to force MS to change have had little effect, and I was hoping that maybe if we attacked the issue from another angle, it might be productive. :) -- Scott Francis | darkuncle(at)darkuncle(dot)net | 0x5537F527 I gave you the chance of aiding me willingly, but you have elected the way of pain! -- Saruman, speaking for sysadmins everywhere pgp0.pgp Description: PGP signature
RE: CIsco 7206VXR w/NPE-G1 Question
It's not the Cisco bashing I was referring to, but the all singing all dancing Juniper performance claim. Matt. -Original Message- From: Petri Helenius [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 17:43 To: Matt Ryan Cc: [EMAIL PROTECTED] Subject: Re: CIsco 7206VXR w/NPE-G1 Question Matt Ryan wrote: Do you get commission from Juniper? Where do I get my comission then? I´ve described inferior product as such many times and so far I haven´t seen deposits from vendors in my bank account? !!OT warning!! Pete -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
Re: B.root-servers renumbering
On Jan 30, 2004, at 4:26 AM, John L Crain wrote: snip New Hints files can be found at: ftp://rs.internic.net/domain/db.cache ftp://rs.internic.net/domain/named.cache ftp://rs.ineternic.net/domain/named.root [EMAIL PROTECTED]:~$ whois ineternic.net Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. No match for INETERNIC.NET. Cheers, -- Daniel Kerr
RE: CIsco 7206VXR w/NPE-G1 Question
It's not the Cisco bashing I was referring to, but the all singing all dancing Juniper performance claim. That would not have anything to do with Juniper sucking the least? Alex
Re: CIsco 7206VXR w/NPE-G1 Question
Matt Ryan wrote: It's not the Cisco bashing I was referring to, but the all singing all dancing Juniper performance claim. If you feel differently, (and this might be a different list) you might want to back up your referring with some data. Pete
Re: AOL web troubles.. New AOL speedup seems to be a slowdown
At 09:43 PM 1/29/2004, Brian Bruns [EMAIL PROTECTED] wrote: Properly implemented watermarking won't be affected by the recompression. It may not be as clear to the program as it would be if it was in its old format, but its still legible. That's *visible* watermarking, not invisible *digital* watermarking which is hidden in the image file and marks the image as the property of the copyright owner. If AOL's recompression technique is stripping out the digital watermark (can anyone here verify this?), then: AOL is copying and redistributing the image in a new format *without the permission of the copyright holder* in a way that A) makes AOL money and B) removes protections that the copyright holder had placed on the image to help keep third parties from reproducing the image without permission. and in doing so: IMHO they are infringing on the copyright of those who have placed the digital watermark in the image. jc
Re: AOL web troubles.. New AOL speedup seems to be a slowdown
Yes, AOL has always been know for less than original image quality. But we are often having users getting no image. WIth the images show up as broken images (red x) in their browsers about 30% of the time. Optimized is one thing but optimzed to oblivion is very painful. Tracerouting to them is very slow while inside their network, altho perhaps due to prioritizing. As far a tampering with the images. Their was a lawsuit in england not long ago over cache engines containing a copy of the image. But I don't remember the outcome. Nicole On 30-Jan-04 Unnamed Administration sources reported Daniel Senie said : At 07:37 PM 1/29/2004, Stephen Sprunk wrote: Thus spake Kevin Loch [EMAIL PROTECTED] Nicole wrote: In the past few days our AOL users have been reporting serious problems Several Brickshelf users have complained about the new blurry images problem using AOL. I have not heard any reports of broken images or upload problems yet. In the past, some ISPs have used a quality-reduction algorithm on images to speed up dialup users' experience; I assume that's what AOL has adopted. Gotta use their lingo... your stuff's been optimized! I have been thinking about whether the use of lossy compression methods would constitute tampering with copyrighted material. After all, if a site was carefully designed to provide optimized images of fine art, and AOL or other ISPs mess with the quality, the value of the site content would be decreased, and the site could lose business due to users thinking the quality of the images is bad. This reminds me of an old saying, you can make any computation go faster if you don't care if it gives the right answer. Heh. |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- Daemons will now be known as spiritual guides -Politically Correct UNIX Page Witchcraft is in essence the worship of the powers of this world, beautiful and terrible, but all in a circle under the turning sky that is the One. -C.A. Burland, Echoes of Magic Connecting with energy is something humans have to be open to and talking about and expecting, otherwise the whole human race can go back to pretending that life is about power over others and exploiting the planet. If we go back to doing this, then we won't survive. -James Redfield, The Celestine Prophecy
RE: CIsco 7206VXR w/NPE-G1 Question
The Juniper software is great, very stable under testing (for 2 weeks in the lab). But as with all routers there are pro's and con's and it also has some issues. What is unfortunate is that the poster runs (by their own admission) neither Cisco or Juniper in their network and yet make unfounded claims about the performance of the Juniper under any conditions. Clearly this will never be true as the cost of developing such a box would be prohibitive and the delivery timescales far too long. I'm as happy as the next person to give Cisco a bashing but I also like to see some balance when unrealistic claims are made. Matt. -Original Message- From: Alex Yuriev [mailto:[EMAIL PROTECTED] Sent: 30 January 2004 14:45 To: Matt Ryan Cc: [EMAIL PROTECTED] Subject: RE: CIsco 7206VXR w/NPE-G1 Question It's not the Cisco bashing I was referring to, but the all singing all dancing Juniper performance claim. That would not have anything to do with Juniper sucking the least? Alex -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
Impending (mydoom) DOS attack
Is anyone taking any special precautions given the potential for a sudden increase in aggregate packets per second across your networks come Sunday afternoon when the original Mydoom virus enters into itsDOS phase? Does anyone know if the virus' assault will be slowed if it is unable to reach www.sco.com? I am hoping that if it cannot reach SCO's site that the HTTP GET command will be slow in returning, effectively reducing the volume of traffic a single PC is capable is generating. I am having a difficult time artificially forcing the virus to start its attack in a lab environment, so I am unable to confirm this. Any input would be appreciated. Thanks!
RE: CIsco 7206VXR w/NPE-G1 Question
[EMAIL PROTECTED] wrote: flow-based means router's performance is based on number of flows established, and first packet of each 'flow' is processed differently [slower] from all other within the flow, and things like nachi will kill it. That would be where the NPE-G1 would be better than an RSP8; however what I don't like is when you rely on the internal switching of the NPE-G1 you end up creating a 1-slot router with the PAs then becoming substandard additions. I understand that money is an issue, but the original question was about backbone use and I would rather go with a 7603 or a 7606 instead of a 7206VXR. Michel.
here are some postfix patterns i found useful today
what you do is, install postfix 2.0 or later, set header_checks to some filename (in your main.cf), and in that file, you put the following: /^Subject: Anti-Virus Notification/ REJECT av01 /^Subject: BANNED FILENAME/ REJECT av02 /^Subject: File blocked - ScanMail for Lotus/ REJECT av03 /^Subject: InterScan NT Alert/ REJECT av04 /^Subject: Message deleted/ REJECT av05 /^Subject: NAV detected a virus)/ REJECT av06 /^Subject: Norton AntiVirus detected/ REJECT av07 /^Subject: RAV AntiVirus scan/ REJECT av08 /^Subject: Symantec AntiVirus/ REJECT av09 /^Subject: VIRUS (.*) IN MAIL FROM YOU/ REJECT av10 /^Subject: VIRUS IN YOUR MAIL/ REJECT av11 /^Subject: Virus Detected by Network Assoc/ REJECT av12 /^Subject: Virus Notification:/ REJECT av13 /^Subject: Virus found in a message you sent/ REJECT av14 /^Subject: Virus found in sent message/ REJECT av15 i guess this isn't something you can cutpaste into an IOS box, but it's sure saving my ass here today, so i thought i'd share. i'm getting MUCH MORE E-MAIL TRAFFIC today from antivirus adware servers than from worms. see also http://www.attrition.org/security/rant/av-spammers.html.
Re: Impending (mydoom) DOS attack
I believe the only route to SCO comes via us, XO, to a customer of ours who provides bandwidth to SCO. We've been in contact with our customer and they have been in contact with SCO, discussing precautions we can take. I think we're relaying the results of those discussions to our major peers. Since I'm not directly involved, I will say no more...but at least you know we are trying to do something.. :) I would gather that you are correct in that if SCO's site cannot be reached.. in a way that connections have to 'time out', it would reduce the volume of traffic and the rate of packets. Windows would be waiting for the SYN ACK and not looping very quickly.. - Chris -- Chris Behrens Senior Software Architect XO Communications On Fri, Jan 30, 2004 at 04:18:03PM -0500, bcm wrote: Is anyone taking any special precautions given the potential for a sudden increase in aggregate packets per second across your networks come Sunday afternoon when the original Mydoom virus enters into its DOS phase? Does anyone know if the virus' assault will be slowed if it is unable to reach www.sco.com? I am hoping that if it cannot reach SCO's site that the HTTP GET command will be slow in returning, effectively reducing the volume of traffic a single PC is capable is generating. I am having a difficult time artificially forcing the virus to start its attack in a lab environment, so I am unable to confirm this. Any input would be appreciated. Thanks!
Re: Impending (mydoom) DOS attack
Having looked for some information to educate myself and my employer, I will say a weakness right now is that there is limited info about this worm. I have yet to see any good information on how effective the attack might be, or what some basic prevention steps (eg filtering) might do to the worm. Backbones don't often have people that disassemble worms. It would be nice to find some way for the anti-virus companies to share more details quicker with various backbones in order to effectively combat the DDOS portion of worms. If anyone has any good analysis on the current worm (other than it attacks www.sco.com), that would be welcome. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Impending (mydoom) DOS attack
In a message written on Fri, Jan 30, 2004 at 04:18:05PM -0800, Donovan Hill wrote: I think we should help out SCO by creating new wildcard entries into our DNS servers that point *.sco.com to 127.0.0.1 as well as blackholing all SCO SWIPd IP Address Space. I'm going to be one of the last people who will defend SCO recent actions. However, as much as I hate, and hate is the word, SCO I feel the need to speak up after your comments. Bruce Perens has said it far better than I ever could at http://perens.com/SCO/DOS/. Please read what he has to say. We (Open Source, ISPs, etc) must, MUST, come to SCO's defense on this one. I am doing what I can with my employer to do just that. Allowing attacks like this to succeed, either directly or indirectly is far more harmful than allowing SCO to stay online. We cannot condone these actions for any reason, the end does not justify the means in the case of worms. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
RE: CIsco 7206VXR w/NPE-G1 Question
On Fri, 30 Jan 2004, Michel Py wrote: That would be where the NPE-G1 would be better than an RSP8; however Isn't it somewhat wrong to compare the NPE-G1 to any RSP since most of the packets, most of the time, are handled by the processors on the VIPs and never bother the RSP other than flowing through its SRAM? Or at least a comparison should be NPE-G1 vs some combination of RSP and VIPs. If you take a 7500 as far as you can (RSP16, VIP6-80s), then how does it compare to a 7206VXR/NPE-G1? Cisco plainly admits that the GEIP tops out at around 400mbit/s, but it's based on the rather old VIP2-50. Anyone know if they plan to put out a more capable GEIP, perhaps based on the VIP6-80, which theoretically would double the GEIP's throughput? -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Lack of Info (was Re: Impending (mydoom) DOS attack)
On Fri, 30 Jan 2004, Leo Bicknell wrote: If anyone has any good analysis on the current worm (other than it attacks www.sco.com), that would be welcome. Yep, the information gap is pretty big on this one. Neither the anti-virus vendors nor the ex-Symantec guy at Homeland Security seems to be releasing much details how the virus actually behaves on the network. Lots of information about changing Windows registries, but not much about how often it checks or loads the network. Some people say they've gotten it to do something in the lab, other people report its a dud. I can't tell what the difference is.
Re: Impending (mydoom) DOS attack
Leo Bicknell wrote: Bruce Perens has said it far better than I ever could at http://perens.com/SCO/DOS/. Please read what he has to say. We (Open Source, ISPs, etc) must, MUST, come to SCO's defense on this one. I am doing what I can with my employer to do just that. I agree both with Mr. Bicknell, and with Mr. Perens for the reasons given. I believe further that condemning this attack and doing what we can to thwart it are simply the right things to do. Allowing attacks like this to succeed, either directly or indirectly is far more harmful than allowing SCO to stay online. We cannot condone these actions for any reason, the end does not justify the means in the case of worms.
Re: CIsco 7206VXR w/NPE-G1 Question
Once upon a time, [EMAIL PROTECTED] [EMAIL PROTECTED] said: Cisco plainly admits that the GEIP tops out at around 400mbit/s, but it's based on the rather old VIP2-50. Anyone know if they plan to put out a more capable GEIP, perhaps based on the VIP6-80, which theoretically would double the GEIP's throughput? I don't know how much more capable it is, but the GEIP+ is based on the VIP4. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Fw: Impending (mydoom) DOS attack
OK, enough ppl are asking so I will post this public, instead
of just sending this to those who asked.
Since I do not understand assembly or FORTH I cannot
verify what this guy on the full disclosure list said so far
no one on the list is commenting on this persons post.
So I make NO claims about this.
James Edwards
Routing and Security Administrator
[EMAIL PROTECTED]
At the Santa Fe Office: Internet at Cyber Mesa
Store hours: 9-6 Monday through Friday
505-988-9200 SIP:1(747)669-1965
This is from the full disclosure list:
: :
: : Here's why people have been getting inconsistent results when setting
: : the system date forward and looking for the DoS attack to start:
: :
: : Begining of DDoS date check subroutine:
: :
: : 4A3DB0 PUSH EBP ; callCreateSCOddos
: : 4A3DB1 MOV EBP,ESP
: : 4A3DB3 SUB ESP,10
: :
: :
: : Get the current system time as a FILETIME struct:
: :
: : 4A3DB6 LEA EAX,DWORD PTR SS:[EBP-8]
: : 4A3DB9 PUSH EAX
: : 4A3DBA CALL DWORD PTR DS:[KERNEL32.GetSystemTimeAsFileTime]
: :
: :
: : Convert the stored DoS start date from SystemTime to FileTime:
: :
: : 4A3DC0 LEA EAX,DWORD PTR SS:[EBP-10]
: : 4A3DC3 PUSH EAX
: : 4A3DC4 MOV EAX,DWORD PTR SS:[EBP+8]
: : 4A3DC7 ADD EAX,214
: : 4A3DCC PUSH EAX ; Feb 1, 2004
: : 4A3DCD CALL DWORD PTR DS:[KERNEL32.SystemTimeToFileTime]
: :
: :
: : Compare high-order dword dwHighDateTime:
: :
: : 4A3DD3 MOV EAX,DWORD PTR SS:[EBP-4]
: : 4A3DD6 CMP EAX,DWORD PTR SS:[EBP-C]
: : 4A3DD9 JB SHORT message.skipDoS
: :
: :
: : Compare low-order dword wLowDateTime:
: :
: : 4A3DDB MOV EAX,DWORD PTR SS:[EBP-8]
: : 4A3DDE CMP EAX,DWORD PTR SS:[EBP-10]
: : 4A3DE1 JB SHORT message.skipDoS
: :
: :
: : Start the DoS:
: :
: : 4A3DE3 CALL message.createSCOddos ; DoS_Loop
: : 4A3DE8 PUSH 400
: : 4A3DED CALL DWORD PTR DS:[KERNEL32.Sleep]
: : 4A3DF3 JMP SHORT message.DoS_Loop
: : 4A3DF5 LEAVE; skipDos
: : 4A3DF6 RETN
: :
: : From MSDN:
: : The FILETIME structure is a 64-bit value representing the number of
: : 100-nanosecond intervals since January 1, 1601 (UTC).
: :
: : typedef struct _FILETIME {
: : DWORD dwLowDateTime;
: : DWORD dwHighDateTime;
: : } FILETIME,
: : *PFILETIME;
: :
: : The stored starttime as filetime is:
: : 0xbe9ecb00
: : 0x01c3e8dd
: :
: : Because the dwords are compared independently, the DoS will not start
: : anytime the current dwLowDateTime is less than 0xbe9ecb00, no matter
: : what the dwHighDateTime is. Obviously, this is close to three-quarters
: : of the time.
: :
: : -Joe
: :
: : --
: : Joe Stewart, GCIH
: : Senior Security Researcher
: : LURHQ http://www.lurhq.com/
: :
: : ___
: : Full-Disclosure - We believe in it.
: : Charter: http://lists.netsys.com/full-disclosure-charter.html
: : - Original Message -
: : From: bcm [EMAIL PROTECTED]
: : To: [EMAIL PROTECTED]
: : Sent: Friday, January 30, 2004 2:18 PM
: : Subject: Impending (mydoom) DOS attack
: :
Re: Impending (mydoom) DOS attack
Are there any reliable estimates as to the amount of infected hosts out there? Looking at my stats for email sent this week, I am seeing a 70:1 ratio for mydoom.a as compared to Swen.a (the next most prevalent virus). Perhaps if we had some rough #s to work with we could start to approximate the range of traffic volumes we might see. ---Mike At 07:17 PM 30/01/2004, Leo Bicknell wrote: Having looked for some information to educate myself and my employer, I will say a weakness right now is that there is limited info about this worm. I have yet to see any good information on how effective the attack might be, or what some basic prevention steps (eg filtering) might do to the worm. Backbones don't often have people that disassemble worms. It would be nice to find some way for the anti-virus companies to share more details quicker with various backbones in order to effectively combat the DDOS portion of worms. If anyone has any good analysis on the current worm (other than it attacks www.sco.com), that would be welcome. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
MyDoom statistics (was Re: Impending (mydoom) DOS attack)
On Fri, 30 Jan 2004, Mike Tancsa wrote: Are there any reliable estimates as to the amount of infected hosts out there? Looking at my stats for email sent this week, I am seeing a 70:1 ratio for mydoom.a as compared to Swen.a (the next most prevalent virus). Perhaps if we had some rough #s to work with we could start to approximate the range of traffic volumes we might see. Reliable? Not really. McAfee's global virus statistics say 17% of all scanned computers were infected by W32/Mydoom.a. But I don't believe that number, because it is wildly different than other metrics. A lot of users have experienced the MyDoom file being on their computer (e.g. through a mail message). But I don't think that represents the number of people which clicked and executed the file, infecting their computer.
Re: CIsco 7206VXR w/NPE-G1 Question
... That is of course, as opposed to Juniper, which is truly line-rate at any interface, with any services, at any composition of traffic. No. While I was at my former employer, we took our edge ACL into the Juniper POC lab, and verified that an M40 stuffed full of OC48 linecards could sustain just over 85% of line rate with our edge ACL applied before sustaining packet loss; the POC lab engineers double checked and verified that there was nothing wrong with the test, that was simply the most the IPII processors could handle with that particularly hairy ACL. There's no such thing as a perfect router--there will always be conditions under which any given device has suboptimal (read sub-line-rate) performance. The trick is establishing what traffic patterns show up in *your* network, and purchase the appropriate hardware for _your_ traffic patterns. -alex Matt
Re: Impending (mydoom) DOS attack
On Friday 30 January 2004 04:39 pm, Leo Bicknell wrote: In a message written on Fri, Jan 30, 2004 at 04:18:05PM -0800, Donovan Hill wrote: I think we should help out SCO by creating new wildcard entries into our DNS servers that point *.sco.com to 127.0.0.1 as well as blackholing all SCO SWIPd IP Address Space. I'm going to be one of the last people who will defend SCO recent actions. However, as much as I hate, and hate is the word, SCO I feel the need to speak up after your comments. Bruce Perens has said it far better than I ever could at http://perens.com/SCO/DOS/. Please read what he has to say. We (Open Source, ISPs, etc) must, MUST, come to SCO's defense on this one. I am doing what I can with my employer to do just that. Allowing attacks like this to succeed, either directly or indirectly is far more harmful than allowing SCO to stay online. We cannot condone these actions for any reason, the end does not justify the means in the case of worms. Please don't misunderstand me. I in no way condone or encourage DoS attacking SCO/Caldera (or anyone for that matter). To my mind, that'd be like encouraging one group of people to attack another group of people for any reason. It's certainly not acceptable. My comments were meant in partial jest and partial frustration. Jest as a solution to the pending DDOS and frustration that SCO will spin this as an attack by the Linux community against SCO, which it is not. I apologize if I didn't make that clear. For the record, I fully believe that this worm (both variants) is designed to attack high profile targets in order to take the focus off of it's spamming capability and create uncertainty as to what group actually authored the worm. It is my firm belief that this worm was written by spammers for the purpose creating spam relays. Also, for the record, I believe everyone has the right to say what they will regardless of legitimacy, and this does include SCO. Again, I apologize if I gave the wrong impression that the pending DDOS attack on SCO was a good thing. It's not. -- Donovan Hill Electronics Engineering Technologist, CCNA www.lazyeyez.net, www.gwsn.com
Re: CIsco 7206VXR w/NPE-G1 Question
No. While I was at my former employer, we took our edge ACL into the Juniper POC lab, and verified that an M40 stuffed full of OC48 linecards could sustain just over 85% of line rate with our edge ACL applied before sustaining packet loss; the POC lab engineers double checked and verified that there was nothing wrong with the test, that was simply the most the IPII processors could handle with that particularly hairy ACL. Was that in the limits of the FPC ? It seems it does, just checking out. Was this a test with smallest possible packets ? Do you remember aggregate pps being routed ? It seems you could hit some of the real IP2 pps limits with ACLs, which is definitively not 40 Mpps. In one test I saw it hitted top at 12.5 Mpps, but it may be due to hitting FPC limits. Other people tests showed something in the 20-25 Mpps range. Rubens
Re: CIsco 7206VXR w/NPE-G1 Question
On Fri, Jan 30, 2004 at 03:29:41PM -0200, Rubens Kuhl Jr. wrote: * The 7206VXR prior to the NPE-G1 could only do around 560Mbps per bus typically, due to PCI limitations. Which usually was not a problem with i-mix traffic or ddos-traffic, because pps limitation would hit sooner. * Compiled ACLs on 12.2S perform very well on NPE-G1s. I saw no mention of PXF on NPE-G1; it seemed the path 7200 would take after NSE-1. What happened ? PXF is found in the 7400 (old) and 7300 (newer) series. The 7400 was extremely unstable until very recently (with 12.2(14)S5 it is quite stable, as long as you have the hardware with the fixed L3 cache or have the L3 cache disabled), which is perhaps why PXF was not pushed so heavily after that experience. I have not used a 7300. If you want to look at what features they are pushing into PXF on them, look at the 12.2(20)S release notes. After the pain of being an early adopter of the 7400 I'm staying well away from the 7300 until I see others using them without stability issues. 7400 is closely related to the NPE400 (actually NSE-1), 7300 is closely related to the NPE-G1. David.
Re: AOL web troubles.. New AOL speedup seems to be a slowdown
JC, I would encourage you to get more familiar with the HTTP 1.1 spec with regard to your claim of copyright infringement. I will summarize my interpretation of a part of it here. When someone provides HTTP content, they are agreeing to the protocols governing the transmission of that content, which includes caching and transformation of that content by proxy systems. Fortunately, the spec provides for netizens to send Cache-Control headers that can exclude their content from storage on and transformation by proxies. These headers are outlined in the spec, so I'm not going to detail them here. But as far as I have been able to tell, AOL is in compliance with the Cache-Control specs. I see it like this: Not including Cache-Control headers and claiming copyright infringement is like publishing a novel in English and distributing it in the U.S., but printing the copyright notice in Chinese. Clients accessing your content must be able to understand that you do not wish for it to be transformed; and since proxies speak HTTP, content providers need to include the appropriate HTTP headers so the proxies understand their wishes. Conversely, when a content provider excludes Cache-Control headers, ISPs have free reign to handle the content and deliver to the end user in whatever way they wish, as long as that way falls within the HTTP 1.1 spec. As an aside, I have a special folder on my Apache server for Jessica Stover's website where I keep images that I don't want to be compressed by all of these web accelerators (Earthlink and NetZero have them too, not just AOL). In that folder's .htacccess file, I have included instructions to send the Cache-Control: No-Transform header on all files requested via HTTP within that folder; those images are not modified in any way by the various web caching systems out there -- the end user gets the identical image to what is stored on my server. ~ The Gunn [EMAIL PROTECTED] AOL is copying and redistributing the image in a new format *without the permission of the copyright holder* in a way that A) makes AOL money and B) removes protections that the copyright holder had placed on the image to help keep third parties from reproducing the image without permission. and in doing so: IMHO they are infringing on the copyright of those who have placed the digital watermark in the image. jc
RE: CIsco 7206VXR w/NPE-G1 Question
At 03:51 AM 31/01/2004, [EMAIL PROTECTED] wrote: Keep in mind, 72xx is still flow-based 72xx NPE-xxx is NOT flow-based -- unless you explicitly configure it to be. (i.e. disable CEF, enable flow switching). CEF is prefix-based switching - where all possible prefixes (routes/RIB) are already programmed into the forwarding table (FIB). anything not programmed into the FIB doesn't exist in the RIB, ergo there is no route therefore is dropped. i believe the words you're looking for is NPE-xxx is SOFTWARE-based forwarding. this part is true enough - but a NPE-G1 has far more cpu cycles to switch/route than previous NPE-400/300/225/200/150 et al. software-based forwarding isn't so bad -- it means that platforms such as the 7200 typically have lots of features. this is different to the NSE-xxx which is part software-based forwarding and part PXE-based forwarding. the exact features accelerated by PXE varies depending what code release is used. your said: flow-based means router's performance is based on number of flows established, and first packet of each 'flow' is processed differently [slower] from all other within the flow, and things like nachi will kill it. no, this isn't true. (at ieast, it isn't unless you explicitly configure it that way). for a service-provider, you wouldn't want to use it in any forwarding mode other than CEF, unless there is very good reason to. to provide you with a summary of forwarding paths and their uses: CEF switching: prefix-based pre-populated FIB dCEF switching: distributed version of CEF - typically each linecard has its own FIB and therefore switching decisions are distributed per linecard Fast switching: destination-based demand switching. a 'route cache' exists of destinations to be forwarded to. the first packet to a destination is process switched, which installs the route-cache entry. subsequent packets are switched in the fast (aka interrupt) path. Process switching: all packets received (at interrupt level) are queued for process-level to route. then there's Flow Switching, whose definition has changed over time: Flow Switching: a variation on Fast-switching, but where a flow-entry is created based on a 5-tuple (srcip/dstip/proto/srcport/dstport/TOS). first packet is process- switched, which installs the flow entry, subsequent packets are switched at interrupt level now, Flow Switching has changed over time. you can enable both CEF+Flow and Flow simply becomes an accounting method that is useful for netflow - but you continue to have packets switched using CEF. as to the exact level of forwarding used for each packet, that varies -- if you enable a feature that isn't in the CEF path, then the packet is switched using the next-lower-layer that supports the 'feature'. for service-provider type environments, there aren't too many features necessary for /most/ deployments that aren't already covered in CEF on 7200, so you're mostly ok there. this is just a brief description of how a 72xx works - and there are many permutations and differences between different platforms and boxes. if you want the full rundown, Phil Harris normally gives a Router Architecture presentation at every Networkers i've ever attended, and it covers all this and more. cheers, lincoln. disclosure: my other email address is [EMAIL PROTECTED], but i work in Fibre Channel not IP these days.
RE: CIsco 7206VXR w/NPE-G1 Question
Michel Py wrote: That would be where the NPE-G1 would be better than an RSP8; [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Isn't it somewhat wrong to compare the NPE-G1 to any RSP since most of the packets, most of the time, are handled by the processors on the VIPs and never bother the RSP In general, yes indeed. However, you have to place it in the same context as I did, quoted below: [EMAIL PROTECTED] wrote: flow-based means router's performance is based on number of flows established, and first packet of each 'flow' is processed differently [slower] from all other within the flow, and things like nachi will kill it. Michel Py wrote: That would be where the NPE-G1 would be better than an RSP8; In this very case, where a large part of the traffic is a shitload of new flows, dCEF is irrelevant and the NPE-G1 has indeed an advantage over any RSP because it has a 700Mhz processor and the RSP16 is 400Mhz and the RSP8 250Mhz. Of course, this assumes that you are actually doing flow-based routing, which I don't see being that common among ISPs. If you take a 7500 as far as you can (RSP16, VIP6-80s), then how does it compare to a 7206VXR/NPE-G1? Ah that's an interesting academic question, and although I will take a shot at it, 1. The question is vague. 2. #include disclaimer.h 3. Can't really be answered without testing it. 4. Even when actually testing it with real traffic, your mileage may vary as the traffic patterns being used can indeed greatly the results. That being said, here's my take at it: We have on one side 7206VXR with NPE-G1 and 6x PA-POS-OC3 (or similar) And on the other: 7507MX with RSP16, 3x VIP6-80, 6x PA-POS-OC3 (or similar), 2x GEIP [ this setup is flawed in the first place, as the GEIP is based on the VIP2-50; the correct setup should be: 7507MX with RSP16, 4x VIP6-80, 6x PA-POS-OC3 (or similar), 2x PA-GE. Unfortunately, the VIP6-80 does not support the PA-GE :-( ] On each router: two of the GigE are connected to tier-1 transit, and the DS3s to either big customer or remote pop. I call this a draw. On one hand, if the traffic between the two GigE is not well balanced, the 7507 has a problem with the throughput of the GEIP. On the other hand, the NPE-G1 has a 700 Mhz CPU, but has to deal with all of the following: - two GigE - six PAs - BGP and flows where the 7507 has: - 2x 200Mhz VIP2-50 for the GigE - 3x 400Mhz VIP6-80 for the PAs - 1x 400Mhz RSP16 for BGP and flows My take is: in some situations, the 7507 will be better and in some others the 7206 will be better. The weak point of the 7507 setup is the GEIP, the weak point of the 7206 is that is has only one CPU. Now, _if_ in the 7507 you could replace 2x GEIP with 1x VIP6-80 + 2x PA-GE, I would give a clear advantage to the 7507 setup. In any case, a 7600 will beat the crap out of any 7200. Michel.
Re: Impending (mydoom) DOS attack
I've implemented a means of distributing the www.sco.com/32 or any other DDoS destination network block around my own AS and blocking it by routing to null on the edge routers. no need to update heaps of routers at the edge and when the attack its over simple to restore connectivity to DDoS destination. Basically. (relies on having BGP on all edge routers). Advertise the destination that is getting DDoS etc in BGP as a longer prefix (if it's more then a /32 make sure you think about load balanced servers, block the range). Set next-hop to RFC1918 address (assuming you route it to null on the edge routers). Make sure you filter the routes out to your ebgp neighbors besides they really shouldn't be accepting /32's anyway right? ;). Benefit is that any DDoS traffic will be dropped at edge, (keeping core happy, and upstream/wan/peer links low :) ). disadvantage, zero connectivity to that blocked destination. (Otherwise you could always play with some table-map function and do some fancy rate-limit base policies via BGP distribution with specific community string). Regards Phillip On Fri, 30 Jan 2004, bcm wrote: Is anyone taking any special precautions given the potential for a sudden increase in aggregate packets per second across your networks come Sunday afternoon when the original Mydoom virus enters into its DOS phase? Does anyone know if the virus' assault will be slowed if it is unable to reach www.sco.com? I am hoping that if it cannot reach SCO's site that the HTTP GET command will be slow in returning, effectively reducing the volume of traffic a single PC is capable is generating. I am having a difficult time artificially forcing the virus to start its attack in a lab environment, so I am unable to confirm this. Any input would be appreciated. Thanks!
