...

As a box designed with the enterprise datacenter in mind, the E- series looks to be missing several key service provider features, including MPLS and advanced control plane filtering/policing.

Ah, because Cisco does either of these in hardware?

Yes. PFC3 inside Supervisor 32, 720 and RSP 720 for Catalyst 6500/Router 7600 series perform both of these features in hardware. The article mentioned in this thread compares Force10 E against the 6500 series. james

...

Yes. PFC3 inside Supervisor 32, 720 and RSP 720 for Catalyst 6500/ Router 7600 series perform both of these features in hardware. The article mentioned in this thread compares Force10 E against the 6500 series.

Sorry, I was on an installation with 6500s and 720s trying to do uRPF and it kept falling back to software and killing the units. What your reading has no reality in my experience.

uRPF was problematic back in PFC2 based platforms (i.e. SUP2) where it is further dependent upon unicast routes in FIB TCAM. uRPF currently works fine enough on PFC3 based sups, the only problem however is currently only "one or the other" mode is supported for the entire box, as opposed to per interface. For example, configuring loose-mode uRPF in one interface, then configuring a strict-mode in another will result in entire box behaving as strict-mode interface for all uRPF enabled interfaces. Other than this caveat, I never had problems with it. However, these uRPF issues are fully documented. Reading manuals and documentation should help you avoid getting into operational problems such as "kept falling back and killing the units" scenario. Control plane policing via cp-policer works quite well on pfc3 based 6500's. This is ofcourse a very important feature (more important than uRPF in today's internet IMO) that appears to be missing in f10 gear which is what Paul was saying earlier. james

This statement is patently false. The uRPF failures I dealt with were based entirely on the recommended settings, and were confirmed by Cisco. Last I heard (2 months ago) the problems remain. Cisco just isn't being honest with you about them.

Would you mind telling us what is the scenario so we can avoid it ? Rubens

On Thu, Sep 4, 2008 at 11:35 AM, Jo Rhett <jrhett@netconsonance.com> wrote:

That's the surprising thing -- no scenario. Very basic configuration. Enabling uRPF and then hitting it with a few gig of non-routable packets consistently caused the sup module to stop talking on the console, and

What do you mean by 'non routable?' What was the src/dst makeup of the test traffic?

We also discovered problems related to uRPF and load balanced links, but those were difficult to reproduce in the lab and we couldn't affect their peering, so we had to disable uRPF and ignore so I don't have much details.

What version of code? Also, port-channel/lag or ECMP?

quickly, but that turns out not to be the case. To this day I've never

I've never seen the issues you speak of, so it could be code/platform/config specific. Also, what sup were you testing?

found a network operator using uRPF on Cisco gear. (note: network operator. it's probably fine for several-hundred-meg enterprise sites)

Forgive me, but what does bits/sec have to do with anything? -Tk

On Sep 6, 2008, at 10:20 AM, Anton Kapela wrote:

On Thu, Sep 4, 2008 at 11:35 AM, Jo Rhett <jrhett@netconsonance.com> wrote:

...

That's the surprising thing -- no scenario. Very basic configuration. Enabling uRPF and then hitting it with a few gig of non-routable packets consistently caused the sup module to stop talking on the console, and

What do you mean by 'non routable?'

Should have been dropped by UDP.

What was the src/dst makeup of the test traffic?

Both random sources and singular sources demonstrated the problem.

What version of code? Also, port-channel/lag or ECMP?

I don't have those details handy now, nor am I likely to anytime soon. If they've been solved in recent code, great. But I've seen nothing in the tech notes.

...

quickly, but that turns out not to be the case. To this day I've never

I've never seen the issues you speak of, so it could be code/platform/config specific.

Also, what sup were you testing?

720s, as said repeatedly.

Forgive me, but what does bits/sec have to do with anything?

The problem only appeared at high bits/sec, as I've said repeatedly. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On (2008-09-04 09:35 -0700), Jo Rhett wrote:

quickly, but that turns out not to be the case. To this day I've never found a network operator using uRPF on Cisco gear. (note: network operator. it's probably fine for several-hundred-meg enterprise sites)

To this day I've never met network operator not using uRPF on Cisco gear. (note: network operator. It's probably not used widely by enterprises) HOXBOX#sh run int ten4/1 Building configuration... Current configuration : 126 bytes ! interface TenGigabitEthernet4/1 no ip address no ip redirects no ip proxy-arp load-interval 30 hold-queue 4096 in end HOXBOX#sh run int ten4/1.42 Building configuration... Current configuration : 220 bytes ! interface TenGigabitEthernet4/1.42 encapsulation dot1Q 42 ip address 42.42.42.1 255.255.255.0 ip verify unicast source reachable-via rx allow-default no ip redirects no ip proxy-arp no snmp trap link-status end HOXBOX#debug ip cef drops rate 5 IP CEF drops debugging is on rate 5 HOXBOX#term mon HOXBOX# Sep 8 10:49:58.622 CEST: CEF-Drop: Packet from 103.63.17.0 (Te4/1.42) to 205.219.27.0, Verify Unicast Reverse-Path feature Sep 8 10:49:58.822 CEST: CEF-Drop: Packet from 121.215.245.0 (Te4/1.42) to 126.154.213.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.022 CEST: CEF-Drop: Packet from 150.38.77.0 (Te4/1.42) to 108.119.215.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.222 CEST: CEF-Drop: Packet from 133.69.24.0 (Te4/1.42) to 57.128.16.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.422 CEST: CEF-Drop: Packet from 114.46.39.0 (Te4/1.42) to 192.4.227.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.622 CEST: CEF-Drop: Packet from 135.96.1.0 (Te4/1.42) to 2.151.158.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.822 CEST: CEF-Drop: Packet from 162.16.59.0 (Te4/1.42) to 205.67.228.0, Verify Unicast Reverse-Path feature .... HOXBOX#sh int ten4/1 TenGigabitEthernet4/1 is up, line protocol is up (connected) Hardware is C6k 10000Mb 802.3, address is 0011.bb33.2600 (bia 0011.bb33.2600) MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 194/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 10Gb/s input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:05:00, output 00:00:37, output hang never Last clearing of "show interface" counters 00:05:26 Input queue: 0/4096/12860846/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 7618968000 bits/sec, 14880795 packets/sec 30 second output rate 0 bits/sec, 0 packets/sec L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 2 pkt, 180 bytes L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes 4538227508 packets input, 290446560820 bytes, 0 no buffer Received 2 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 6430423 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 5 packets output, 2130 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out HOXBOX#show processes cpu | i ^CPU CPU utilization for five seconds: 9%/0%; one minute: 3%; five minutes: 6% SRC: rand(43.0.0.0 .. 220.255.255.255) DST: rand(1.0.0.0 .. 220.255.255.255) It's entirely possible, and rather easy, to get interrupt load to 100% in PFC3. One easy way to do it, is to send L2 broadcast to valid L3 IP unicast. And others. Most likely you just generated packets that were punted to software, perhaps you may have been able to secure them with mls rate-limit or CoPP, but there are DoS vectors you can't protect PFC3 from. -- ++ytti

On (2008-09-11 00:50 -0700), Jo Rhett wrote:

As someone who does a lot of work talking to NOCs trying to chase down attack sources, I can honestly tell you that I haven't talked to a single NOC in the last 16 months who had BCP38 on every port, or even on most of their ports. And the majority response is "our (vendor) gear can't handle it". As we both know, Cisco is the largest by far vendor in the marketplace, and I've heard that name more than 70% of the time.

Sound like these shops are using 3550 as router, which is common for smaller shops, especially in EU. And indeed, 3550 would not do uRPF. (3560E does). -- ++ytti

On Thu, Sep 11, 2008 at 08:11:28PM +0300, Saku Ytti wrote:

Sound like these shops are using 3550 as router, which is common for smaller shops, especially in EU. And indeed, 3550 would not do uRPF. (3560E does).

Are you sure? According to the IOS guide for 3560E/3750E, "ip verify" is still an unsupported interface command. I don't have a 3560E handy to test on, but I know that a non-E 3560 refuses it with a notice regarding how verification is not supported by hardware. http://tinyurl.com/5qbqzb -- Brandon

The 3560E/3750E support uRPF as per docs: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/softwar e/release/12.2_46_se/configuration/guide/swiprout.html#wp1388196 The unsupported command guide looks in error.

-----Original Message----- From: Brandon Ewing [mailto:nicotine@warningg.com] Sent: Saturday, September 13, 2008 11:26 AM To: nanog@nanog.org; saku+nanog@ytti.fi Subject: Re: Cisco uRPF failures

On Thu, Sep 11, 2008 at 08:11:28PM +0300, Saku Ytti wrote:

...

Sound like these shops are using 3550 as router, which is common for smaller shops, especially in EU. And indeed, 3550 would not do uRPF. (3560E does).

Are you sure? According to the IOS guide for 3560E/3750E, "ip verify" is still an unsupported interface command. I don't have a 3560E handy to test on, but I know that a non-E 3560 refuses it with a notice regarding how verification is not supported by hardware.

http://tinyurl.com/5qbqzb

-- Brandon

On Mon, Aug 25, 2008 at 7:20 PM, Jo Rhett <jrhett@netconsonance.com> wrote:

...

http://www.eantc.de/en/test_reports_presentations/test_reports/force_10_sfm_...

http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-...

http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-...

Did you read these?

Yes.

They appear to be nonsense. They were bought and paid for by Cisco, and including nonsense things like "if you leave a slot open the chassis will burn up" as a decrement, which is also true in pretty much every big iron vendor.

Current-generation Cisco and Juniper hardware don't seem to have this problem. I don't think the "remove one SFM and all the others go offline" failure mode is commonplace among other vendors either.

They also deliberately detuned the force10 configuration. They re-ran the tests using the recommended configuration and got very different numbers -- which you can request from them, but they won't publish on the website.

I'd be interested in seeing this. Mind putting them up somewhere and sharing the URL?

Based on what? For E and C series boxes, Cisco is never cheaper. S-series are a different story.

I was comparing list pricing for the E-series up against Catalyst 6500, Supervisor 720-3BXL, 6700 blades with CFC... which I consider a fair comparison.

...

As a box designed with the enterprise datacenter in mind, the E-series looks to be missing several key service provider features, including MPLS and advanced control plane filtering/policing.

Ah, because Cisco does either of these in hardware?

Yes, they do, on the s720-3B and better. Drive Slow, Paul Wall

On Wed, Sep 3, 2008 at 8:28 PM, Jo Rhett <jrhett@netconsonance.com> wrote:

For equivalent redundancy and ports, the Force10 is always cheaper - even just in list price. (on the E-series -- Cisco has some cheaper options than the S-series so I've heard - don't care)

Some food for thought, comparing apples to apples... FORCE 10 ********************* CH-E300-BNA8-L $35,000.00 E300 110V AC Terascale Chassis Bundle: 6-slot E300 chassis with 400 Gb backplane, fan subsystem, 3 AC Power Supplies (CC-E300-1200W-AC) 1 Route Processor Module (EF3), 2 Switch Fabric Modules LC-EF3-1GE-24P $30,000.00 E300 Terascale 24-port Gigabit Ethernet line card - SFP optics required (series EF3) CC-E300-1200W-AC $4,000.00 E300 1200W/800W AC Power Supply CC-E-SFM3 $12,500.00 E-Series Switch Fabric Module LC-EF3-RPM $30,000.00E300 Terascale Route processor module (series EF3) ** BASIC CONFIG WITH 24 GIG-E (SFP PORTS): $65000.00 (USD) ** CISCO **************** WS-C6503-E Catalyst 6500 Enhanced 3-slot chassis,4RU,no PS,no Fan Tray 2500 WS-SUP720-3BXL= Catalyst 6500/Cisco 7600 Supervisor 720 Fabric MSFC3 PFC3BXL 40000 WS-X6724-SFP= Catalyst 6500 24-port GigE Mod: fabric-enabled (Req. SFPs) 15000 WS-CAC-3000W= Catalyst 6500 3000W AC power supply (spare) 3000 PWR-950-DC= Spare 950W DC P/S for CISCO7603/Cat 6503 1245 WS-C6503-E-FAN= Catalyst 6503-E Chassis Fan Tray 495 ** BASIC CONFIG WITH 24 GIG-E (SFP PORTS) (not counting two bonus ports on Sup :) 62240.00 (USD) ** Please realize that the above is list vs. list. Cisco 6500 series hardware is extremely popular in the secondary market, with discounts of 80% or greater on linecards, etc common, furthering the argument that Cisco is the cheaper of the two solutions.

...

...

...

As a box designed with the enterprise datacenter in mind, the E-series looks to be missing several key service provider features, including MPLS and advanced control plane filtering/policing.

Ah, because Cisco does either of these in hardware?

Yes, they do, on the s720-3B and better.

No, they don't. There are *no* *zero* providers doing line-speed uRPF on Cisco for a reason. Stop reading, start testing.

Cisco absolutely does MPLS and control-plane policing in hardware on the SUP720 (3B and higher), ditto uRPF. Force 10 doesn't even support the first two last I checked! On the subject of uRPF, it's true, Cisco's implementation is less than ideal, and is not without caveats. Nobody seems to get this right, though Juniper tries the hardest. Practically speaking, it can be made to work just fine. Possible solutions commonplace among larger tier 1/2 providers include having your OSS auto-generate an inbound access-list against a list of networks routed to the customer, or just applying a boilerplate "don't allow bad stuff" filter on the ingress. uRPF strict as a configuration default, on customers without possible asymmetry (multihoming, one-way tunneling, etc) is not a bad default. But when the customers increase in complexity, the time might come to relax things some. It's certainly not a be-all-end-all. And it's been demonstrated time after time here that anti-spoof/bogon filtering isn't even a factor in most large-scale attacks on the public Internet these days. Think massively sized, well connected, botnets. See also CP attacks (which, again, the F10 can't even help you with). Drive Slow, Paul Wall

On Sep 4, 2008, at 1:34 AM, Mark Tinka wrote:

catch inbound RFC 1918 and RFC 3330 with ACL's; and just to see how crazy things get, we stick our own prefixes in there since we really shouldn't be seeing them as sources from the wild.

So you are talking single site, or single peering location? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

Paul Wall wrote:

Please realize that the above is list vs. list. Cisco 6500 series hardware is extremely popular in the secondary market, with discounts of 80% or greater on linecards, etc common, furthering the argument that Cisco is the cheaper of the two solutions.

Secondary market prices aren't a fair measure, unless you include the corresponding cost for software and support. And the fact is, when we put this out for an RFP, we ended up with Force10 having the lowest price by a fair margin; the closest competitor in price was Foundry, with Cisco a distant third. List prices aren't a good measure o actual price; they're a number for salesmen to compare their discount to to make people feel special. In short: You can get the Force10 cheap.

On Sep 4, 2008, at 7:24 AM, James Jun wrote:

Indeed... In today's internet, protecting your own box (cp-policer/ control plane filtering) is far more important IMO than implementing BCP38 when much of attack traffic comes from legitimate IP sources anyway (see botnets).

I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, protecting yourself is so much more important than protecting anyone else. Anyone else want to stand up and join the "I am an asshole" club? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

Count you which way? You seem to agree with me. Everyone should be doing both, not discounting BCP38 because they aren't seeing an attack right now. On Sep 4, 2008, at 9:50 AM, John C. A. Bambenek wrote:

Count me in.

There is no reason to limit our defenses to the one thing that we think is important at one instance in time... attackers change and adapt and multimodal defense is simply good policy.

On Thu, Sep 4, 2008 at 11:45 AM, Jo Rhett <jrhett@netconsonance.com> wrote:

...

On Sep 4, 2008, at 7:24 AM, James Jun wrote:

...

Indeed... In today's internet, protecting your own box (cp-policer/ control plane filtering) is far more important IMO than implementing BCP38 when much of attack traffic comes from legitimate IP sources anyway (see botnets).

I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, protecting yourself is so much more important than protecting anyone else.

Anyone else want to stand up and join the "I am an asshole" club?

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

Patrick, it would appear that you are insulting me by your choice of quotes but from content one would assume you agree with me. Perhaps next time quote the idiot that said attacks BCP38 would stop don't happen any more? (top posted because the thread is already confused) On Sep 4, 2008, at 10:05 AM, Patrick W. Gilmore wrote:

On Sep 4, 2008, at 12:52 PM, Jo Rhett wrote:

...

Count you which way? You seem to agree with me. Everyone should be doing both, not discounting BCP38 because they aren't seeing an attack right now.

No one sees attacks that BCP38 would stop?

Wow, I thought things like the Kaminsky bug were big news. I guess all that was for nothing?

(Yes, I am being sarcastic. Anyone who thinks attacks which BCP 38 would stop are not happening in the wild is .. I believe the phrase used was "confused and misinformed".)

-- TTFN, patrick

...

On Sep 4, 2008, at 9:50 AM, John C. A. Bambenek wrote:

...

Count me in.

There is no reason to limit our defenses to the one thing that we think is important at one instance in time... attackers change and adapt and multimodal defense is simply good policy.

On Thu, Sep 4, 2008 at 11:45 AM, Jo Rhett <jrhett@netconsonance.com> wrote:

...

On Sep 4, 2008, at 7:24 AM, James Jun wrote:

...

Indeed... In today's internet, protecting your own box (cp- policer/control plane filtering) is far more important IMO than implementing BCP38 when much of attack traffic comes from legitimate IP sources anyway (see botnets).

I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, protecting yourself is so much more important than protecting anyone else.

Anyone else want to stand up and join the "I am an asshole" club?

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

Sorry for the confusion. ^^^^^

Yes, I am a BCP38 evangelist. I apologize if it came across wrong. ^^^^^^^^^^^

OK, Patrick is setting an example. Could we all do likewise and get back to a civil conversation?

TTFN, patrick

Kudos for a good example. People on this list should not be surprised that other list members do not know everything. This doesn't make them idiots, it just means that there is an opportunity for you to politely educate them and hopefully gain a few converts to whatever cause you are championing. --Michael Dillon

On Thu, Sep 4, 2008 at 12:45 PM, Jo Rhett <jrhett@netconsonance.com> wrote:

I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, protecting yourself is so much more important than protecting anyone else.

Anyone else want to stand up and join the "I am an asshole" club?

uRPF is important. But all the uRPF in the world won't protect you against a little tcp/{22,23,179} SYN aimed at your Force 10 box. Ya know what I mean? Paul Wall

On Thu, Sep 04, 2008 at 01:14:20PM -0400, Paul Wall wrote:

On Thu, Sep 4, 2008 at 12:45 PM, Jo Rhett <jrhett@netconsonance.com> wrote:

...

I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, protecting yourself is so much more important than protecting anyone else.

Anyone else want to stand up and join the "I am an asshole" club?

uRPF is important. But all the uRPF in the world won't protect you against a little tcp/{22,23,179} SYN aimed at your Force 10 box.

Ya know what I mean?

Hey Paul, would you be able to demonstrate this problem? I'd like to see it so that we can investigate and fix it. You are correct that the first generation of E-Series hardware (EtherScale) had little control plane protection. The current E-Series hardware (TeraScale) has a completely different architecture that rate limits, queues and filters all packets destined to the control plane. Greg* (* I am currently employed by Force10.) -- Greg Hankins <ghankins@mindspring.com>

On Thu, 4 Sep 2008, Jo Rhett wrote:

On Sep 4, 2008, at 7:24 AM, James Jun wrote:

...

Indeed... In today's internet, protecting your own box (cp-policer/control plane filtering) is far more important IMO than implementing BCP38 when much of attack traffic comes from legitimate IP sources anyway (see botnets).

I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, protecting yourself is so much more important than protecting anyone else.

Anyone else want to stand up and join the "I am an asshole" club?

"I'm an a??hole!" :o) (lotsa folks get corporate "bad words" filters, here). Seriously though, everyone should take care of their own end first. The problem is Jo doesn't seem to be in the loopon attacks from recent years, but I am unsure he would change his mind if he was/

-- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On Thu, 4 Sep 2008, Patrick W. Gilmore wrote:

On Sep 4, 2008, at 3:38 PM, Gadi Evron wrote:

...

On Thu, 4 Sep 2008, Jo Rhett wrote:

...

On Sep 4, 2008, at 7:24 AM, James Jun wrote:

...

Indeed... In today's internet, protecting your own box (cp-policer/ control plane filtering) is far more important IMO than implementing BCP38 when much of attack traffic comes from legitimate IP sources anyway (see botnets).

I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, protecting yourself is so much more important than protecting anyone else.

Anyone else want to stand up and join the "I am an asshole" club?

"I'm an a??hole!" :o) (lotsa folks get corporate "bad words" filters, here).

Seriously though, everyone should take care of their own end first. The problem is Jo doesn't seem to be in the loopon attacks from recent years, but I am unsure he would change his mind if he was/

Gadi,

Do you really want to suggest to people that they not implement BCP38?

No. Thank you for calling me on not explaining well. I suggest that the guy is right. People should tajke care of their security first before going out and shouting at the world. That said, I also state that he is probably not in touch with what's been going on in the past few years. Meaning, botnets *do* use spoofing, and DNS amplification attacks. The threat is not "theoretical" for a few years now and he may simply not be in on it. As to preaching BCP38, well... it's not an easy leap of thought to make, that your security is tied into the state of security of a box sitting half-way around the world. But that's the case. Gadi.

-- TTFN, patrick

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't think you will get any argument that the vast majority of CS departments teach theory and not as much valid practice when it comes to networking. Though, being formally at the UW, I can tell you that they wouldn't have been able to spoof on the campus or through it's upstream (which we also ran). That being said, I think another area that BCP38 is going to run into problems with is IPv6. Given that host are multi-addressed from day one and nominally follow a default route for returning traffic, they can easily appear to "spoof" perfectly valid traffic (6to4 in, native out for example). While some can be made as exceptions (6to4), some won't be done so easily without some implementation changes. And that's not even touching on the holes in RPF checks on Cisco (no feasible) or Juniper (not quite as feasible as is really feasible) platforms. David On Sep 4, 2008, at 10:22 PM, bmanning@vacation.karoshi.com wrote:

seems that some folks in the R&E community, with institutional support from Cisco, Google, and the US NSF, are exploiting our inability to take even rudimentary steps toward providing a level of integrity in routing by teaching students that spoofing IP space is ok. This whole thing works at all because so few people use/deploy/maintain BCP-38 compliance. This was an eye-opener for me.

http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf

--bill

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkjBtHoACgkQLa9jIE3ZamPYzQCgu2OdDu8/Uq896ffcJZjSX7X8 6jgAnR7iZFiRAsxN6+qn64ZVYIcNy1hy =E20v -----END PGP SIGNATURE-----

On Sat, 06 Sep 2008 06:49:05 PDT, k claffy said:

do that many networks really allow spoofing? i used to think so, based on hearsay, but rob beverly's http://spoofer.csail.mit.edu/summary.php suggests things are a lot better than they used to be, arbor's last survey echos same. are rob's numbers inconsistent with numbers anyone else believes to be true?

You can easily have a network configuration where 95% of the networks do very stringent BCP38 on their customer-facing connections, but the spoofing sources are carefully chosen to be within the 5% of places that aren't filtering... Plus, there's nothing that says that a network can't do BCP38 on 99.998% of its ports, but has a punchout for the 3 or 4 ports that need it for network monitoring/research. So a network could be reported as "non-spoofable" to the MIT project, *and* still provide a sensor machine for the reverse path project...

On Thu, 11 Sep 2008, Jo Rhett wrote:

I've been in, near, or directly in touch with enough big provider NOCs in the last year on various DoS attach research issues, and nearly nobody... that's right NONE of them were using BCP38 consistently. Name the five biggest providers you can think of. They ain't doing it. Now name the five best transit providers you can think of. They ain't doing it either. (note that all of these claimed to be doing so in that survey, but during attack research they admitted that it was only in small deployments)

If someone told me (truthfully) that there was 10% BCP38 compliance out there, I'd be surprised given what I have observed.

A problem I have with these discussions is that everyone has their own idea what "BCP38" implies. Others say their loose-mode uRPF setups are "BCP38". Others are using strict uRPF or similar (e.g. acls). Some think that Tier1 transit operators should apply one of the options above to their tier2 customers. Others think it should just be applied at the site-edges. Some don't consider spoofing protection at LAN interface level at all, others call that also BCP38. Etc. Your note above seems to imply that you would expect the five best transit providers you think of to apply BCP38 (strict?) to their customers. Even if the customer is a major ISP? (However, if your argument is about a smallish end-site, I'd agree spoofing protection should be applied there.) FWIW, I've tested what would happen if I were to enable strict-mode (feasible paths) uRPF on an Internet exchange (all peerings). If I recall correctly, the amount of dropped packets would have been in the order of 1%. We decided not to do it. Maybe those "five biggest providers you can think of" have similar experiences with their biggest customers? Loose mode URPF is seems (IMHO) pretty much waste of time and is confusing the discussion about real spoofing protection. The added protection compared to ACLs that drop private and possibly bogons is not that big and it causes transient losses when the routing tables are changing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Thu, 11 Sep 2008, Jo Rhett wrote:

...

[Pekka:] Loose mode URPF is [..] (IMHO) pretty much waste of time and is confusing the discussion about real spoofing protection. The added protection compared to ACLs that drop private and possibly bogons is not that big and it causes transient losses when the routing tables are changing.

I disagree. But I will say that if everyone would apply strict mode or ACLs to their end point interfaces, this would likely make most of the loose mode irrelevant.

FWIW, based on off-list discussion, Jo's disagreement seems to stem from a misunderstanding of how loose uRPF works (he didn't know it accepts any packet that has a route in the routing table). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Thu, 11 Sep 2008 00:28:25 PDT, Jo Rhett said:

I've been in, near, or directly in touch with enough big provider NOCs in the last year on various DoS attach research issues, and nearly nobody... that's right NONE of them were using BCP38 consistently. Name the five biggest providers you can think of. They ain't doing it. Now name the five best transit providers you can think of. They ain't doing it either. (note that all of these claimed to be doing so in that survey, but during attack research they admitted that it was only in small deployments)

Part of the problem is that if you're talking about the 5 biggest providers, and the 5 biggest transit, you're talking about places with routing swamps big enough, and with sufficient dragons in residence, that you really *can't* do BCP38 in any sane manner. AS1312 (us) is able to do very strict BCP38 on a per-port level on every router port, because we *know* what's supposed to be on every subnet. By the time you walk our list of upstreams to any of the '5 biggest anything', you've gotten to places where our multihomed status means you can't filter our source address very easily (or more properly, where you can't filter multihomed sources in general).

If someone told me (truthfully) that there was 10% BCP38 compliance out there, I'd be surprised given what I have observed.

The MIT Spoofer project seems to indicate that closer to 50% *of the edge* is doing sane filtering. And that's where you need to do it - *edge* not *core*.

On Thu, 11 Sep 2008, Jo Rhett wrote:

On Sep 11, 2008, at 10:10 AM, Valdis.Kletnieks@vt.edu wrote:

...

By the time you walk our list of upstreams to any of the '5 biggest anything', you've gotten to places where our multihomed status means you can't filter our source address very easily (or more properly, where you can't filter multihomed sources in general).

I don't agree with this statement. I hear this a lot, and it's not really true. Being multihomed doesn't mean that your source addresses are likely to be random. (or would be valid if they were)

A significant portion of our customers, and *all* of the biggest paying ones, are multihomed. And they might have a lot of different ranges, but we know what the ranges are and filter on those.

If you can manage ACLs for these customers, that's fine. But maybe your multihomed customers and '5 biggest anything' customers are different. Maybe your multihomed customer has 5 prefixes. The big ones could have 5000. That's a pretty big ACL to manage. This is where Strict URPF (+feasible paths) helps a lot because in some cases you don't need to manage those ACLs by hand. But this gets broken if the customer advertises more specific routes from another provider, but doesn't advertise these to you -- your route to those more specifics goes through another ISP, and if the site is sourcing packets from those more specifics through you, the strict uRPF would drop them. There are ways to work around this, e.g. by requiring that the customers advertise the more specifics to you as well but mark them so that you don't propagate them, but I suspect this is not feasible in the higher tiers of ISP business. http://tools.ietf.org/html/draft-savola-bcp84-urpf-experiences Section 3 discusses this a bit. FWIW: we use feasible-paths strict uRPF on all customer and LAN interface without exception. Multihomed ones as well, though it's a bit more work. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Date: Thu, 11 Sep 2008 11:24:43 -0700 From: "Kevin Oberman" <oberman@es.net>

...

Date: Thu, 11 Sep 2008 20:59:39 +0300 (EEST) From: Pekka Savola <pekkas@netcore.fi>

On Thu, 11 Sep 2008, Jo Rhett wrote:

...

On Sep 11, 2008, at 10:10 AM, Valdis.Kletnieks@vt.edu wrote:

...

By the time you walk our list of upstreams to any of the '5 biggest anything', you've gotten to places where our multihomed status means you can't filter our source address very easily (or more properly, where you can't filter multihomed sources in general).

I don't agree with this statement. I hear this a lot, and it's not really true. Being multihomed doesn't mean that your source addresses are likely to be random. (or would be valid if they were)

A significant portion of our customers, and *all* of the biggest paying ones, are multihomed. And they might have a lot of different ranges, but we know what the ranges are and filter on those.

If you can manage ACLs for these customers, that's fine. But maybe your multihomed customers and '5 biggest anything' customers are different. Maybe your multihomed customer has 5 prefixes. The big ones could have 5000. That's a pretty big ACL to manage.

It's big, but not un-workable. Just looking at our lists, the longest is over 212K entries and we have 5 over 5K and 20 over 1K. We would have even bigger ones if the IRR had more complete information.

Ack! Fat fingered it! Certainly not 212K entries. That was supposed to be 12K. Not nearly so impressive. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf

great work on a tough problem randy

bmanning@vacation.karoshi.com wrote:

On Sun, Sep 07, 2008 at 07:43:41PM +1200, Randy Bush wrote:

...

...

http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf great work on a tough problem yes, but would it work if we all did BCP38 filtering?

i think kc said it all well enough

On Sep 4, 2008, at 12:38 PM, Gadi Evron wrote:

Seriously though, everyone should take care of their own end first. The problem is Jo doesn't seem to be in the loopon attacks from recent years, but I am unsure he would change his mind if he was/

Nice going, Gadi -- let's insult someone who does a good job of protecting your network from his customers. I spend at least 8 hours a week tracking down attacks originating from non-BCP38 networks. This is still a real problem, and the idea that BCP-38 is some fad that is irrelevant now ... I have no words for this kind of idiocy. Everyone should be doing BCP-38. Why don't you apply this to your network, instead of sitting around insulting people for your incorrect assumptions about their job? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On Sep 4, 2008, at 2:56 PM, Gadi Evron wrote:

I apologize for making an incorrect assumption and apparently insulting you. My assumption was based on the threading in the email I replied to, as what you write here conpletely contradicts what was written there.

Yeah, I think the threading was getting confused quite a bit.

So, we all support BCP38 and nothing really changed from the last time we all had this discussion about why most of us don't use it.

On that you'll have to speak for yourself. We have it on every customer port ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On Sep 4, 2008, at 3:22 PM, Gadi Evron wrote:

...

On that you'll have to speak for yourself. We have it on every customer port ;-)

Now that is interesting. Can you share a bit about you rimplementation hardships, costs, customer complaints, etc?

One customer complaint. Found the customer was looping traffic between two uplinks and helped them fix the problem ;-) Implementation cost: time/labor to implement automatic management of ACLs on the customer ports. Not all that much cost, since we had already developed infrastructure to do the same thing for customer configurations. Maybe 12 hours of my time coding and testing. Honestly, I expected a lot more problems than we've had. Especially given the fallout I'd seen on the networks trying to do it with Cisco. But the Force10 gear didn't even notice the effect, and it's been ~2 years since I've even thought much about it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

Jo Rhett wrote:

On Sep 4, 2008, at 12:38 PM, Gadi Evron wrote:

...

Seriously though, everyone should take care of their own end first. The problem is Jo doesn't seem to be in the loopon attacks from recent years, but I am unsure he would change his mind if he was/

Nice going, Gadi -- let's insult someone who does a good job of protecting your network from his customers.

Reminder: Gadi isn't a native English speaker. I understood "Take care of their own end first" to mean "please do BCP38" -- it polices your "own" end.

I spend at least 8 hours a week tracking down attacks originating from non-BCP38 networks. This is still a real problem, and the idea that BCP-38 is some fad that is irrelevant now ... I have no words for this kind of idiocy. Everyone should be doing BCP-38. ...

Hopefully, we all agree! That's why it's been a "Best Current Practice" for a decade or so....

On Sep 7, 2008, at 12:18 AM, Randy Bush wrote:

normally i would have just hit delete. but your ad hominem attack on the messenger need a response.

the reality of life is that he is correct in that "attack traffic comes from legitimate IP sources anyway."

therefore, your first duty should be to keep your hosts from joining the massive army of botnets.

Having no hosts, I can't do much about that other than use various good best practices (including BCP38), run ids units looking for compromised hosts, and respond quickly to each abuse report if my IDS doesn't observe it first. Given that I know of no provider larger than us using BCP38 on every port, and no other provider larger than us that responds to every abuse report, it would appear that we are top of the class in that aspect. Therefore, when someone says "I don't need to do BCP38" because BCP38 doesn't cause problems for them, I consider them a jerk. And yeah, I feel pretty confident looking down my nose at someone like that. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On Sep 11, 2008, at 12:50 AM, Randy Bush wrote:

...

Having no hosts, I can't do much about that other than ...

i suggest you go back to the mail to which you responded obscenely vilifying the poster who was specifically saying he worried about his host before bcp38. that was specifically the subject.

"host" in that context was his router, which makes your comment make less sense. (having never seen a big iron router become a client in a botnet, myself) He was talking about big iron control plane policy controls. You must have missed the context.

...

Given that I know of no provider larger than us using BCP38 on every port

well, that sets an upper bound on the extent of your knowledge, eh. and not a very high one.

I just had a deep discussion with Verio about this very problem in their network last week. Verio claims no timetable for consistent BCP38 deployment. You want to stop being rude, and start making positive assertations about things you know? I'd love to be wrong, but I've got a whole lot of experience on this topic. If you know better, educate the rest of us. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On Sep 4, 2008, at 12:47 AM, Paul Wall wrote:

Some food for thought, comparing apples to apples...

FORCE 10 ********************* CH-E300-BNA8-L $35,000.00 E300 110V AC Terascale Chassis Bundle: 6-slot E300 chassis with 400 Gb backplane, fan subsystem, 3 AC Power Supplies (CC-E300-1200W-AC) 1 Route Processor Module (EF3), 2 Switch Fabric Modules LC-EF3-1GE-24P $30,000.00 E300 Terascale 24-port Gigabit Ethernet line card - SFP optics required (series EF3) CC-E300-1200W-AC $4,000.00 E300 1200W/800W AC Power Supply CC-E-SFM3 $12,500.00 E-Series Switch Fabric Module LC-EF3-RPM $30,000.00E300 Terascale Route processor module (series EF3) ** BASIC CONFIG WITH 24 GIG-E (SFP PORTS): $65000.00 (USD) **

You added a third SFM3 which has no place to go in this chassis. So $52,500 versus $62,240 for the Cisco.

Please realize that the above is list vs. list. Cisco 6500 series hardware is extremely popular in the secondary market, with discounts of 80% or greater on linecards, etc common, furthering the argument that Cisco is the cheaper of the two solutions.

Then you need to add recertify cost, which isn't cheap. And given that you can purchase Force10 stuff *NEW* at 60% discount, you're pitting new against used for similar prices. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On Sep 4, 2008, at 10:07 AM, Paul Wall wrote:

On Thu, Sep 4, 2008 at 12:40 PM, Jo Rhett <jrhett@netconsonance.com> wrote:

...

You added a third SFM3 which has no place to go in this chassis.

No, I did not. I did, however, list it as a point of reference for a-la-carte analysis.

...

So $52,500 versus $62,240 for the Cisco.

No, $65000.00 vs $62240.00.

I have a current spreadsheet here, and trust me your math went wrong somewhere. A completely full chassis is only a bit more than what you are quoting (at list) and the chassis itself is practically free. But no, I'm not going to redo the math. I'm not a F10 salesperson and I have much more important things to do right now. (not trying to be rude, just seriously...) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On Fri, Sep 5, 2008 at 2:37 PM, Paul Wall <pauldotwall@gmail.com> wrote:

Jo Rhett wrote:

...

Note the "not random" comment. People love to use the random feature of ixia/etc but it rarely displays actual performance in a production network.

Once upon a time, vendors released products which relied on CPU-based "flow" setup. Certain vintages of Cisco, Extreme, Foundry, Riverstone, etc come to mind. These could forward at "line rate" under normal conditions. Sufficient randomization on the sources

Jo, As Paul eludes, the measure of 'worth' today has moved from bits/sec to one of 'operations per second' - where 'operation' could be many different types of work. The 'ideal router' should be able to execute administrative policy, scheduling, queuing, and of course, route lookup and next-hop determination in as close to constant-time as possible without regard for the packet or traffic composition. This means that regardless the makeup or nature of the packet, the device is able to do the same number of lookups with 10, 1000, or 1,000,000 routes in its FIB. Commonly this is done through CAM and TCAM or in RAM using various data structures that exhibit efficient traversal and lookup behaviors. I would invite you to research these independently, as there is a sizable body of work to review (ultimately this work is a class of search/sort problem). Today we find most CAM based systems no longer are interesting insofar as their raw forwarding performance; nearly every feature that can be implemented in hardware will generally exhibit the same scaling and performance behaviors as regular IP forwarding. The same generally holds true for RAM-based systems, though implementations vary by vendor (i.e. juniper IP-I/IP-II vs. MX-series distributed CAM) and can preclude certain combinations of work being performed on the packet during forwarding. Bottom line: it's not bits/sec, it's ops/sec. -Tk

And 60 points off Cisco is possible, even for small shops with some negotiating ability.

That's not our experience; it seems that BUs protecting margins talk louder than the sales guys, so when it reaches discounts like that, even because of lack of adequate product from Cisco (lower gear can't handle it, big gear is too expensive), the competition winning is worse to Cisco but better to the BU numbers, so they leave it to that. Rubens

Paul Wall wrote:

On Fri, Aug 22, 2008 at 10:34 AM, Matlock, Kenneth L <MatlockK@exempla.org> wrote:

...

Does anyone here have real-world experience with Force 10 gear (Specifically their E-Series and C-Series)? They came and did their whole dog and pony show today, but I wanted to get real-world feedback on their gear.

I need to know about their

1) Reliability 2) Performance

EANTC did a comprehensive study of the E-series:

http://www.eantc.de/en/test_reports_presentations/test_reports/force_10_sfm_...

http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-...

http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2006-2008/Cisco-...

Standard benchmarketing. Not that I blame Cisco or EANTC for that, since they were debunking some benchmarketing done by Force10 and Tolly, but consider the source (and follow the money) when reading any "independent" test and what that means for accuracy. 80% of the EANTC report can be summed up as "The default CAM profile didn't do what we wanted, and we didn't bother asking Force10 for the commands to make it work." There are indeed some interesting product weaknesses, like any vendor has, but the fact that Force10's CAM can be partitioned to match the buyer's needs, rather than having a fixed configuration that all customers are forced to use, is an advantage in my book. S (Disclosure: I am a former employee of both Cisco and Force10, but have no ties to either today.)

On Aug 26, 2008, at 6:46 PM, Owen DeLong wrote:

Another thing to note (as near as I can tell, this applies to all vendors). All line cards will function only at the lowest common denominator line card CAM level.

IOW, if you have single, dual, and quad-cam cards in your F10 chassis, they'll all act like single-CAM cards.

Owen

I'd have to second that. This is a very annoying fact, that you will find mentioned nowhere. What I also used to dislike is the lack of verbosity of 'show features' - but that was back a year ago. Btw, you absolutely want to avoid the S series, the CLI is a pain, and is not the same as the E or C series, and lacks many features. Price/10G port is interesting though, but not as much as with Arastra, if that's switching you're into. (never tested any such kits though...) My own 2 cents. Greg VILLAIN

Sort of... There are still some notable differences in behavior. Owen On Sep 1, 2008, at 5:47 AM, jim deleskie wrote:

The S series runs the same FTOS as the C and E series, as of a number of months ago. The only exception is the 2410, ie all 10G ports L2 only.

-jim

On Mon, Sep 1, 2008 at 3:19 AM, Greg VILLAIN <nanog@grrrrreg.net> wrote:

...

On Aug 26, 2008, at 6:46 PM, Owen DeLong wrote:

...

Another thing to note (as near as I can tell, this applies to all vendors). All line cards will function only at the lowest common denominator line card CAM level.

IOW, if you have single, dual, and quad-cam cards in your F10 chassis, they'll all act like single-CAM cards.

Owen

I'd have to second that. This is a very annoying fact, that you will find mentioned nowhere. What I also used to dislike is the lack of verbosity of 'show features' - but that was back a year ago. Btw, you absolutely want to avoid the S series, the CLI is a pain, and is not the same as the E or C series, and lacks many features. Price/10G port is interesting though, but not as much as with Arastra, if that's switching you're into. (never tested any such kits though...) My own 2 cents.

Greg VILLAIN

On Aug 26, 2008, at 9:46 AM, Owen DeLong wrote:

Bottom line, in a few years, everyone carrying full tables with F10 gear will probably need to upgrade all of their line cards to quad-cam.

Why is this statement being limited to F10? It appears to be true of every vendor. But why quad-cam? The dual-cam cards have indecent amounts of storage. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

On Wed, Sep 3, 2008 at 5:38 PM, jim deleskie <deleskie@gmail.com> wrote:

This is an awesome thread... in the 18mts I tested F10 vs Juniper vs Cisco I need see my Cisco sales rep push this hard :)

it's easy to push this hard when you have empirical evidence on your side but seriously, this is definitely a f10-nsp list thread and that place could use some love

...

2) Performance

[Note: we have no 10g interfaces, so I can only speak to a many-singleg-port environment] Much higher than Cisco. So good at dealing with traffic problems that we have had multi-gig DoS attacks that we wouldn't have known about without having an IDS running on a mirroring port.

Do they have something with a few singleg-ports (could be only 2) but can route a large FIB (half a million, million routes) and some large RIBs (3 full-routing views, a hundred peers) ? Rubens

"Then again, I've always had a good support experience with Extreme, but I'm not about to run out and replace my core with Black Diamonds. :)" I once worked at a place where we had BD 6808's at the core; one of them consistently had hardware issues, and it took me the better part of a year of fighting with Extreme to get them to replace the chassis, but when they did, the problems went away, imagine that. I suppose similar isolated incidents could happen with anyone occasionally though. Chris On Tue, Aug 26, 2008 at 3:26 AM, Paul Wall <pauldotwall@gmail.com> wrote:

On Mon, Aug 25, 2008 at 7:26 PM, Jo Rhett <jrhett@netconsonance.com> wrote:

...

...

1) Reliability

Very good. Across our entire business we've lost 1 RPM module in ~2 years.

How many boxes in total? Losing a single routing engine in two years is not a bad MTBF, though I wonder if we're talking about one chassis or one thousand.

...

...

2) Performance

[Note: we have no 10g interfaces, so I can only speak to a many-singleg-port environment] Much higher than Cisco. So good at dealing with traffic problems that we have had multi-gig DoS attacks that we wouldn't have known about without having an IDS running on a mirroring port.

Routing n*GE at line rate isn't difficult these days, even with all 64-byte packets and other "DoS" conditions.

Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 switches sold at Fry's for a couple benjamins a pop. :)

Now mind you, this is all traffic through the router. I'd imagine Force 10 would have a problem with traffic aimed at its interface or loopback IPs, given their lack of control plane policing/filtering, unlike say:

http://aharp.ittns.northwestern.edu/papers/copp.html

...

...

3) Support staff (how knowledgeable are they?)

Significantly higher than Cisco, and escalation is easier. On par with Juniper.

This is good, though not necessarily hard when you have a small pool of TAC people.

Then again, I've always had a good support experience with Extreme, but I'm not about to run out and replace my core with Black Diamonds. :)

...

These things are so very solid that I rarely spend any time doing network work any more. Gigabit line-speed BCP38 makes life easier for the abuse helpdesk too.

I'm unaware of any hardware-forwarding-based platforms which can't do this.

Though if I find any, I'll be sure to steer clear!

Paul Wall

On Aug 26, 2008, at 12:26 AM, Paul Wall wrote:

Routing n*GE at line rate isn't difficult these days, even with all 64-byte packets and other "DoS" conditions.

Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 switches sold at Fry's for a couple benjamins a pop. :)

Sorry, I thought you were serious. I didn't realize you were joking. Carry on. *plonk* -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

Paul Wall wrote:

On Wed, Sep 3, 2008 at 8:29 PM, Jo Rhett <jrhett@netconsonance.com> wrote:

...

On Aug 26, 2008, at 12:26 AM, Paul Wall wrote:

...

Routing n*GE at line rate isn't difficult these days, even with all 64-byte packets and other "DoS" conditions.

Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 switches sold at Fry's for a couple benjamins a pop. :) Sorry, I thought you were serious.

I am. All of these boxes can forward packets at line rate, and list for a fraction of the price of the Force 10 S-Series.

a dlink dsg-3627g is a quite a few benjamins... but given that switch asics for said class of products are widely available and cheap, the difference between vender a and vendor b in that class of switch is futher up in the software stack.

I'll be correcting your other posts shortly!

Drive Slow, Paul Wall

On Thu, Sep 4, 2008 at 12:36 PM, Jo Rhett <jrhett@netconsonance.com> wrote:

...

...

...

Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 switches sold at Fry's for a couple benjamins a pop. :)

...

I am. All of these boxes can forward packets at line rate, and list for a fraction of the price of the Force 10 S-Series.

You and I (and any real network operator) must have different definitions of "forward at line rate".

"forwards a gig-e full of 64 byte packets, random src/dst, when you hook a smartbits/ixia up to it" is mine. What's yours? Mind you, this is probably one of the more useless metrics for vendor selection these days, and nobody has a major problem with it. Drive Slow, Paul Wall