When to use DFCs

We're getting ready to order a couple 7600s for a core network rebuild. I'm trying to decide if we need DFCs for any of our line cards. We're putting a single Sup720-3BXL in each chassis which comes stock with the PFC3. We're also install a single 6724-SFP and 6548-GE-TX in each chassis along with a SFM2. The rest of the modules are service modules line the IDS2, IPSEC, and FWM modules. This will replace what we currently have; we'll add additional blades later. I'm reading this page currently:

formatting link
That page says that the 6548 doesn't support any DFCs. The next step up would be the 6748 which supports jumbo frames (not really needed) and only comes with 1.3MB of buffer per port (as compared to 8MB on the

6548).

Can anyone give me any ideas which would be better? These 7600s are going to be the core of a small ISP with about 4000 customers at present, about 80% are broadband. More bandwidth intensive services are coming onboard in the very near future too including many Gbps of mcast IPTV traffic across the core.

Is the DFC necessary?

Thanks J

Reply to
J
Loading thread data ...

If there is a lot of traffic between the devices that will be connected to the same 6x48 line card, then the DFC will be able to serve its purpose ...

Reply to
Merv

SFM equivalent is built into the Sup 720.

The rest of the modules are service modules

formatting link

it depends on how much traffic would stay "locally" on the card, and how much may go out via other 67xx blades with DFCs.

if you have a DFC on both blades involved in a flow, the traffic stays off the central MSFC / PFC. Where there is only a DFC on 1 of 2 cards, then you get some benefit (1 direction?) but not all. The DFC also seems to offload some multicast processing once a flow is set up (we used PIM SM on ours).

DFC doesnt affect layer 2 flows - those are switched in hardware anyway.

finally there are changes to Q facilities when you have DFCs - these may be important depending on what you plan to do.

Flip side is that the central PFC / MSFC can cope with a fairly heavy L3 load all on their own - the Sup 720 processing is roughly equivalent to a DFC for thruput This gives you best case performance numbers - best way to use it is to relate load on a known box / config to something you are thinking of using:

formatting link
if all you are going to move is "a few Gbps / Mpps" then DFCs may not matter - but given your stated other cards you may want to keep 720 processor capacity for the "classic" line cards in your mix.

Reply to
stephen

Both the 6548 and 6724 will infrastructure ports. The remote IP-based head-end will be at another site in town and will connect back via the

6724 or possibly 10GigE connections when the time comes from that to be implemented. The main users of IPTV will be ADSL2+ users and their gear will be dual-homed to the core routers via most likely copper.

I'm away from my dead-tree references at the moment. Does the DFC only handle forwarding decisions on only the one blade it's installed on? If that's the case then we probably won't need a DFC since most of the switching will be between the 6724 and 6548, I anticipate.

Thanks for the reply J

Reply to
J

A DFC will handle all traffic received on that LC, so if you effectively have 2 LC's one with a DFC and one without, the PFC on the sup720 will handle traffic from the LC without the DFC, and the DFC will handle the traffic received on the LC where it's installed.

If you need it or not depends on your traffic levels, a PFC (regardless if it's on a DFC or central on the sup720) can handle tens of millions of packets per second.

Reply to
Jesper Skriver

I figured that out later in the day. So the 720 has to sit in one of the slots that can touch all backplanes I'm guessing. I think that would be 7-8 on a 7613, but I'll have to research it to be certain.

I think I was getting confused on the actual functional purposes of the DFC. Now that I've thought about it some more I think the DFC may certainly be useful. All of the IPTV users (ADSL2+ users) will also be getting their phone service via SIP. The soft switch will be secured behind firewalls on the 6548 ports (or FWM but that hasn't been decided yet). That actually brings up two additional questions:

What implication do the service modules (FWM, IDS, IPSEC) have on the throughput and traffic flow of the chassis? I'm assuming that the IDS will simply be monitoring traffic via a span port. Traffic will have to be addressed to the IPSEC blade such as via a VPN tunnel for it to be put into use. The FWM makes me wonder though. I supposed it could either be consulted for a packet handling decision on all packets flowing through the VLANs associated with it or the entire packet could be passed through it (I have not gotten any hours with one of these blades so I'm in the dark). If the FWM slows down the SIP traffic we may want to keep the standalone Pix firewalls for that job.

These chassis will have a multiple BGP feeds in our current design. The core router will make the outward-facing routing decision before packets are delivered to either border router (fully multi-homed). They will also make the advertisement decisions due to their direct connection to another POP and the EGP advertising differences that POP will introduce. They'll advertise to the border routers what the border routers should advertise to their external peers (no eBGP from the external peers to the core). These routers are also the primary Internet-facing POP for all our other POPs. There will be a fair bit of L3 traffic to cope with. They will also have a fair amount of mcast flowing across them once IPTV is deployed. I think we should probably err on the side of caution and not under-size these units.

That's certainly good info. I expect the utilization to grow. We have the potential to onboard a large number of residential customers, small business customers, and larger customers needing offsite data center facilities. Personally I predict another substantial upgrade in the next 3-4 years. We're rebuilding the network with an eye towards MPLS.

I'm researching DFC options for the 6724 now. If I understand this page correctly I can put a DFC on a 67xx blade if I use the WS-F6700-DFC-3BXL:

formatting link
The SIP users from the remote POPs will come across via the 6724 or a possible POS blade. Keeping that traffic off the Sups would probably be desireable.

I've changed my parts list to include the 6748 and corresponding DFC-3BXL as well. We're getting such a good discount on this purchase that I think we should definitely spend a few extra $$ to get the best available gear for the job.

Thanks for the input J

Reply to
J

You might want to request a Cisco SE to vet your final bill of materials

Reply to
Merv

Me too!

My view is that unless you have been there, done that, then there is quite a risk of missing something.

Reply to
anybody43

formatting link

OK - NB using MPLS (as a PE router?) means you end up with a routing table per VRF.

formatting link

yes - DFC type needs to match the Sup 720.xxx type.

the DFC acts as a CEF offload engine - so it needs memory enough to handle the number of routes you expect (and all the ones you dont expect as well of course)

Reply to
stephen

I agree. We've met with a gaggle og engineers 3 weeks ago but things have changes a little bit since then. We'll have them vet it before we sign on the dotted line though.

I'm still waving on the DFCs. We do not currently have the PPS to justify the DFC. However given that this hardware is critical to the function of an ILEC in many towns and a CLEC in many more I'm tempted to say that it's worth the cost. The future relianance on IPTV makes me worry a bit too. Any finally the ultimate percent off that Cisco is giving us makes me want to buy 2 of everything they make.

I'll see what our local SE thinks and go from there. Thanks for the info.

J
Reply to
J

You really want to purchase 67xx cards and not 65xx cards. If you are going to be running enough traffic to justify DFC cards, than its a no brainer decision to go with the 67xx blades.

Scott

formatting link
>

Reply to
thrill5

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.