Re: [c-nsp] do i *need* DFCs on the 6500?
Ben Steele wrote: Unless you are hitting a cam limit on any of your resources on your SUP(very possible if you are exporting netflow) OR you are congesting the crossbar fabric(sh fabric util) which is pretty unlikely when you are talking a 24G linecard on a 40G fabric connection then you probably won't see any difference putting a DFC on a 6724 That depends completely on what other cards are on the box, what their offered forwarding load is, and whether they have DFCs. Remember these chassis are a hardware only based forwarding solution, so all your doing with a DFC is moving cam/asic resources off the sup, so in regards to your specific questions unless you have filled all your QoS queues on the sup you are going to see nothing more on the DFC, also the sup does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment No. The PFC3 does 30Mpps IPv4 (and 15Mpps IPv6 I think). A DFC3 does 48Mpps IPv4 (and 24Mpps IPv6). http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_item09186a00809a7673.shtml A fully-populated and fully-DFCed 6509 does 400Mpps IPv4 or 200Mpps IPv6 (well, actually 192Mpps - 24x8 linecards). In this configuration, the PFC does very little. It's worth noting that a 6724 doing 64-bytes packets on all ports offers ~47Mpps forwarding load - well in excess of the PFC capacity. A chassis full of 6724s without DFCs at 10% load with 64-bytes packets also exceeds the PFC capacity. Obviously these are worst-case numbers but illustrative of the problems you can get yourself into if you don't capacity plan well. It's worth noting that some linecards have different (i.e. more flexible) rx tx queueing methods with a DFC versus the CFC. There's also the bus-stall issues, which go away (supposedly) with a DFC installed since they're not connected to the bus. you are even remotely close to this, and the global ipv6 routing table is no where near the cam limit for that either, by the way is your SUP an XL? does the DFC's on the 10G's match the sup or have they fallen back to the lowest common configuration? I'm not sure why you mention CAM limits, but it's worth noting that DFCs do not help with FIB CAM at all, since they hold a copy of the PFC FIB. Personally we get DFCs on everything since we're using plain -3B (or -3C not) rather than XL, and the cost of the DFC is a pretty minimal percentage of the linecard for the future-proofing. We've also seen software bugs manifest on CFC cards in the past; this implies to me that Cisco prefer DFC chassis. Similarly some of the new linecards e.g. 6708/6716 are DFC-only. I suspect that will be the case going forward. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
On Thu, Sep 3, 2009 at 7:35 PM, Phil Mayers p.may...@imperial.ac.uk wrote: Ben Steele wrote: Unless you are hitting a cam limit on any of your resources on your SUP(very possible if you are exporting netflow) OR you are congesting the crossbar fabric(sh fabric util) which is pretty unlikely when you are talking a 24G linecard on a 40G fabric connection then you probably won't see any difference putting a DFC on a 6724 That depends completely on what other cards are on the box, what their offered forwarding load is, and whether they have DFCs. Hence asking him to check these values, or at least implying from that sentence that he should :) Remember these chassis are a hardware only based forwarding solution, so all your doing with a DFC is moving cam/asic resources off the sup, so in regards to your specific questions unless you have filled all your QoS queues on the sup you are going to see nothing more on the DFC, also the sup does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment No. The PFC3 does 30Mpps IPv4 (and 15Mpps IPv6 I think). A DFC3 does 48Mpps IPv4 (and 24Mpps IPv6). http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_item09186a00809a7673.shtml A fully-populated and fully-DFCed 6509 does 400Mpps IPv4 or 200Mpps IPv6 (well, actually 192Mpps - 24x8 linecards). In this configuration, the PFC does very little. Ok my bad, my memory was for the full chassis not the individual PFC, should read docco next time before posting! i'm still quite certain our OP isn't doing 15Mpps of IPv6, if he is then he must be the IPv6 hub of the world. It's worth noting that a 6724 doing 64-bytes packets on all ports offers ~47Mpps forwarding load - well in excess of the PFC capacity. A chassis full of 6724s without DFCs at 10% load with 64-bytes packets also exceeds the PFC capacity. Obviously these are worst-case numbers but illustrative of the problems you can get yourself into if you don't capacity plan well. I think it's safe to say our OP is no where near these limits or he would definitely know about it, in fact I doubt anyone in the world has hit 47Mpps on any 6500 linecard(in a real world situation, no labs), please if someone has feel free to let me know about it. But yes capacity planning is very important. It's worth noting that some linecards have different (i.e. more flexible) rx tx queueing methods with a DFC versus the CFC. True but keep in mind the OP already has some DFC enabled linecards so I would assume he is familiar with what QoS he can and can't schedule on the CFC vs DFC, his particular comment related to performance and offloading of QoS - not features, the same goes for different line cards in general though, like the 4 and 8 port 10Gb line cards, totally different buffering capabilities, you need to choose your line card wisely, our OP already has his in place. There's also the bus-stall issues, which go away (supposedly) with a DFC installed since they're not connected to the bus. Interesting.. i'll take your word for that, can't say i've seen much in the way of bus stalls when working with them(at least in recent times) except the standard OIR one, i'll assume this is an actual performance impacting stall you are referring to, does this apply even if the chassis is in compact mode? you are even remotely close to this, and the global ipv6 routing table is no where near the cam limit for that either, by the way is your SUP an XL? does the DFC's on the 10G's match the sup or have they fallen back to the lowest common configuration? I'm not sure why you mention CAM limits, but it's worth noting that DFCs do not help with FIB CAM at all, since they hold a copy of the PFC FIB. Yeah my ipv6 FIB CAM statement was pretty irrelevant and was more me typing then realising i'm not sure if we are even talking XL or not here, wasn't the greatest sentence. Personally we get DFCs on everything since we're using plain -3B (or -3C not) rather than XL, and the cost of the DFC is a pretty minimal percentage of the linecard for the future-proofing. No doubt it's better to have a DFC than not have a DFC but some companies are tight with money and justifying just a few thousand for something you don't *really* need can be hard, while non XL upgrade might seem trivial I think you'll find to upgrade a 6724 from stock to a 3CXL DFC is around the price of the actual line card itself, that said neither of us know what PFC the OP is running :) We've also seen software bugs manifest on CFC cards in the past; this implies to me that Cisco prefer DFC chassis. Similarly some of the new linecards e.g. 6708/6716 are DFC-only. I suspect that will be the case going forward. Well from a performance point of view it makes sense, but it all equals $$ and companies are being stingier than ever with the GFC in everyones head. I still get the feeling the OP doesn't need the DFC, generally you
Re: [c-nsp] do i *need* DFCs on the 6500?
There's also the bus-stall issues, which go away (supposedly) with a DFC installed since they're not connected to the bus. The chassis bus stall is done by 3 physical pins in the slot, so DFC or not you still stall and potentially reboot the chassis while inserting/removing a card- however DFC enabled line cards are not subject to the packet loss associated with a bus stall [1]. ~Matt 1: http://www.cisco.com/en/US/products/hw/switches/ps708/products_qanda_ite m09186a00809a7673.shtml#qa4 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
congesting the crossbar fabric(sh fabric util) which is pretty unlikely when you are talking a 24G linecard on a 40G fabric connection Just a nitpick or two - the 6724 only has one channel of fabric, so it's a 24G linecard with a 20G fabric connection, thus a slight oversubscription. If you're extremely rigorous about line-rate, leave four of those ports unused. But the DFC issue is more about Mpps than Mbps. As Phil pointed out, you could run them well under their line-rate, but with small packets, and overwhelm the forwarding capacity of the PFC. -Geoff On Wed, Sep 2, 2009 at 5:59 PM, Ben Steeleillcrit...@gmail.com wrote: Unless you are hitting a cam limit on any of your resources on your SUP(very possible if you are exporting netflow) OR you are congesting the crossbar fabric(sh fabric util) which is pretty unlikely when you are talking a 24G linecard on a 40G fabric connection then you probably won't see any difference putting a DFC on a 6724 Remember these chassis are a hardware only based forwarding solution, so all your doing with a DFC is moving cam/asic resources off the sup, so in regards to your specific questions unless you have filled all your QoS queues on the sup you are going to see nothing more on the DFC, also the sup does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment you are even remotely close to this, and the global ipv6 routing table is no where near the cam limit for that either, by the way is your SUP an XL? does the DFC's on the 10G's match the sup or have they fallen back to the lowest common configuration? ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) - I think you might be on the money here. If you give us the current utilization of your cam resources(from the sup) and the 6724 linecard throughput and what its functions are(netflow/qos/mac/acls etc) then we can tell you for sure. Ben On Wed, Sep 2, 2009 at 9:16 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: hi, okay, from the background of I know what the DFC is and how it operates etc... i know I want them - however, I need to justify the upgrade/part cost to sort out a couple of 6500's. in some of our 6500's, the 10G blades have DFCs already...but several 6724's dont (they just have CFC). ...as i said, I want them, but need to get some management/funding buy-in - and they dont want the 'what it does' information - they want some hard and fast facts that Cisco dont sem to want to tell me . so, the question is 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps per blade with DFC) ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) alan ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
On Wed, Sep 02, 2009 at 02:42:31PM +0200, Peter Rathlev wrote: Agreed, and introducing DFCs can give you some headaches with e.g. policers, since each forwarding engine operates independently from the others. I guess here you're referring to the fact that there is no communication of ingress rates between individual DFCs, or back to the PFC? I posed this question to Cisco at a CPOC lab, and have also heard the same from TAC. Consider the following scenario: Two flows are ingress on a 6500, one on Gi1/0 (where slot 1 has a DFC), and one on Gi2/0 (where slot 2 also has a DFC). They are egress on a third port Gi3/0, which also has a DFC. Since the policing is performed by the ingress LC, if Gi3/0 has a 50Mbps policer, and the flows at Gi1/0 and Gi2/0 are both 40Mbps, neither card will drop any packets, and hence the egress rate at port Gi3/0 is 80Mbps, despite having a 50Mbps policer configured. Unfortunately, I don't have the resources to test this - has anyone tried this scenario, and verified this is _actually_ how things work, rather than theoretically? (I think the official answer for this was...This will be fixed in EARL 8) Thanks, Rob -- Rob Shakir r...@eng.gxn.net Network Development EngineerGX Networks/Vialtus Solutions ddi: +44208 587 6077mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] do i *need* DFCs on the 6500?
hi, okay, from the background of I know what the DFC is and how it operates etc... i know I want them - however, I need to justify the upgrade/part cost to sort out a couple of 6500's. in some of our 6500's, the 10G blades have DFCs already...but several 6724's dont (they just have CFC). ...as i said, I want them, but need to get some management/funding buy-in - and they dont want the 'what it does' information - they want some hard and fast facts that Cisco dont sem to want to tell me . so, the question is 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps per blade with DFC) ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
On Wed, 2 Sep 2009, Alan Buxey wrote: 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? You're probably thinking of show mls statistics. 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? I'd say that if you're not hitting over 10MPPS on the CFC, you don't really need DFC. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. The others on the list can probably give you much more in-depth views on the other aspects of the card but I found CoPP to be a big enough selling point. It wouldn't be good is a simple little DoS attack took down my core 7600s. Justin Alan Buxey wrote: hi, okay, from the background of I know what the DFC is and how it operates etc... i know I want them - however, I need to justify the upgrade/part cost to sort out a couple of 6500's. in some of our 6500's, the 10G blades have DFCs already...but several 6724's dont (they just have CFC). ...as i said, I want them, but need to get some management/funding buy-in - and they dont want the 'what it does' information - they want some hard and fast facts that Cisco dont sem to want to tell me . so, the question is 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps per blade with DFC) ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
On Wed, 2009-09-02 at 14:04 +0200, Mikael Abrahamsson wrote: On Wed, 2 Sep 2009, Alan Buxey wrote: 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? I'd say that if you're not hitting over 10MPPS on the CFC, you don't really need DFC. Agreed, and introducing DFCs can give you some headaches with e.g. policers, since each forwarding engine operates independently from the others. Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
Not to thread hijack here, but speaking of withstanding DoS attacks, has anyone seen any decent published baseline configurations for CoPP to deflect things similar to TTL Expiry attacks and the like? Perhaps some sort of template they use (if they can share it) would be really nice. I would just like to see what others are doing. -Drew -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Justin Shore Sent: Wednesday, September 02, 2009 8:40 AM To: Alan Buxey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] do i *need* DFCs on the 6500? You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. The others on the list can probably give you much more in-depth views on the other aspects of the card but I found CoPP to be a big enough selling point. It wouldn't be good is a simple little DoS attack took down my core 7600s. Justin Alan Buxey wrote: hi, okay, from the background of I know what the DFC is and how it operates etc... i know I want them - however, I need to justify the upgrade/part cost to sort out a couple of 6500's. in some of our 6500's, the 10G blades have DFCs already...but several 6724's dont (they just have CFC). ...as i said, I want them, but need to get some management/funding buy-in - and they dont want the 'what it does' information - they want some hard and fast facts that Cisco dont sem to want to tell me . so, the question is 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps per blade with DFC) ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
On Sep 2, 2009, at 8:48 AM, Drew Weaver wrote: Not to thread hijack here, but speaking of withstanding DoS attacks, has anyone seen any decent published baseline configurations for CoPP to deflect things similar to TTL Expiry attacks and the like? Perhaps some sort of template they use (if they can share it) would be really nice. ttl expire can be protected with mls rate limiters. 10 100 seems plenty. - jared ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
On Wed, 2 Sep 2009, Alan Buxey wrote: is this a figure that can be quoted from somewhere? it seems a very useful pointer - I can easily graph this value (i hope!) via SNMP and therefore can see if/when we need the kit :-) 10 MPPS comes from worst case is 15 Mpps (two recycles in the 30Mpps CFC) and upgrade before it gets even close to that. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
Hi, On Wed, Sep 02, 2009 at 07:39:34AM -0500, Justin Shore wrote: You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. Why? Wouldn't the Sup PFC handle CoPP-in-hardware if you have no DFCs? (Assuming that the total incoming packet volume is still inside the bounds that the PFC can handle) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpjz6TOSr74E.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
The PFC is capable of the same things as a DFC, just in a centralized manner. So, for example, CoPP works just fine in hardware with a PFC - you don't NEED to offload the QoS to the LCs. You need a DFC only if some resources are close to exhaustion (like pps rates supported by centralized forwarding, netflow entries, QoS entries and so on). On Wed, 2 Sep 2009, Justin Shore wrote: You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. The others on the list can probably give you much more in-depth views on the other aspects of the card but I found CoPP to be a big enough selling point. It wouldn't be good is a simple little DoS attack took down my core 7600s. Justin Alan Buxey wrote: hi, okay, from the background of I know what the DFC is and how it operates etc... i know I want them - however, I need to justify the upgrade/part cost to sort out a couple of 6500's. in some of our 6500's, the 10G blades have DFCs already...but several 6724's dont (they just have CFC). ...as i said, I want them, but need to get some management/funding buy-in - and they dont want the 'what it does' information - they want some hard and fast facts that Cisco dont sem to want to tell me . so, the question is 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps per blade with DFC) ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
Drew, Have a look at using mls rate-limit all ttl-failure Here is a paper I worked on, more with an Enterprise feel. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper _c11_553261.html David -- http://dcp.dcptech.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Drew Weaver Sent: Wednesday, September 02, 2009 8:48 AM To: 'Justin Shore'; Alan Buxey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] do i *need* DFCs on the 6500? Not to thread hijack here, but speaking of withstanding DoS attacks, has anyone seen any decent published baseline configurations for CoPP to deflect things similar to TTL Expiry attacks and the like? Perhaps some sort of template they use (if they can share it) would be really nice. I would just like to see what others are doing. -Drew -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Justin Shore Sent: Wednesday, September 02, 2009 8:40 AM To: Alan Buxey Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] do i *need* DFCs on the 6500? You eluded to one of my strongest selling points on DFCs though I don't think you made that particular connection yet. DFCs offload QoS to the LC as you said. That also means that CoPP is also handled in hardware if you have DFCs in place since it requires MLS QoS on that platform. Ie, if your 6500/7600 is going to be publicly-accessible on the Internet in any capacity and you want it to be able to use CoPP to withstand a targeted DoS attack then DFCs are not optional, they're critical. The others on the list can probably give you much more in-depth views on the other aspects of the card but I found CoPP to be a big enough selling point. It wouldn't be good is a simple little DoS attack took down my core 7600s. Justin Alan Buxey wrote: hi, okay, from the background of I know what the DFC is and how it operates etc... i know I want them - however, I need to justify the upgrade/part cost to sort out a couple of 6500's. in some of our 6500's, the 10G blades have DFCs already...but several 6724's dont (they just have CFC). ...as i said, I want them, but need to get some management/funding buy-in - and they dont want the 'what it does' information - they want some hard and fast facts that Cisco dont sem to want to tell me . so, the question is 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps per blade with DFC) ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] do i *need* DFCs on the 6500?
Unless you are hitting a cam limit on any of your resources on your SUP(very possible if you are exporting netflow) OR you are congesting the crossbar fabric(sh fabric util) which is pretty unlikely when you are talking a 24G linecard on a 40G fabric connection then you probably won't see any difference putting a DFC on a 6724 Remember these chassis are a hardware only based forwarding solution, so all your doing with a DFC is moving cam/asic resources off the sup, so in regards to your specific questions unless you have filled all your QoS queues on the sup you are going to see nothing more on the DFC, also the sup does (from memory) up to 100-200m pps in ipv6, I don't believe for a moment you are even remotely close to this, and the global ipv6 routing table is no where near the cam limit for that either, by the way is your SUP an XL? does the DFC's on the 10G's match the sup or have they fallen back to the lowest common configuration? ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) - I think you might be on the money here. If you give us the current utilization of your cam resources(from the sup) and the 6724 linecard throughput and what its functions are(netflow/qos/mac/acls etc) then we can tell you for sure. Ben On Wed, Sep 2, 2009 at 9:16 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: hi, okay, from the background of I know what the DFC is and how it operates etc... i know I want them - however, I need to justify the upgrade/part cost to sort out a couple of 6500's. in some of our 6500's, the 10G blades have DFCs already...but several 6724's dont (they just have CFC). ...as i said, I want them, but need to get some management/funding buy-in - and they dont want the 'what it does' information - they want some hard and fast facts that Cisco dont sem to want to tell me . so, the question is 1) is there any way of showing the sup720 strain/utilisation...particularly is there a way of showing DFC usage on the blades where we have them? 2) it offloads IPv6 and QoS - we're into both of those (and more so over the next year) - any particular insights into QoS performance/issues without DFC ? any throughput figures for IPv6 ? (i know that with CFC we're limited to the backplane (32mpps?) and we get ~ 48mpps per blade with DFC) ...or could it be that DFC's are only really useful to a particular deployment and I just *think* i need them? ;-) alan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
