«

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:

http://www.cisco.com/en/US/products/...d8017376e.html

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
654.

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

> 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
> 654.

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 ...

"J" <> wrote in message
news: ups.com...
> 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.

SFM equivalent is built into the Sup 720.

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:
>
>
http://www.cisco.com/en/US/products/...d8017376e.html
>
> 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
> 654.
>
> 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?

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:
http://www.cisco.com/warp/public/765...erformance.pdf

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.
>
> Thanks
> J
--
Regards

- replace xyz with ntl

Merv wrote:
> > 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
> > 654.
>
> 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 ...

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

On 17 Jul 2006 13:31:25 -0700, J wrote:
> Merv wrote:
>> > 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
>> > 654.
>>
>> 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 ...
>
> 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.

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.

--
Jesper Skriver, CCIE #5456

stephen wrote:
> SFM equivalent is built into the Sup 720.

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.

> 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.

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.

> 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:
> http://www.cisco.com/warp/public/765...erformance.pdf

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.

> 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.

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:

http://www.cisco.com/en/US/products/...d_modules.html

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

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

Merv wrote:
> You might want to request a Cisco SE to vet your final bill of materials

Me too!

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

"J" <> wrote in message
news: oups.com...
> stephen wrote:
> > SFM equivalent is built into the Sup 720.
>
> 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.
>
> > 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.
>
> 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.
>
> > 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:
> >
http://www.cisco.com/warp/public/765...erformance.pdf
>
> 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.
>
> > 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.
>
> 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.

OK - NB using MPLS (as a PE router?) means you end up with a routing table
per VRF.
>
> 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:
>
>
http://www.cisco.com/en/US/products/...d_modules.html
>
yes - DFC type needs to match the Sup 720.xxx type.

> 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.

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)
>
> Thanks for the input
> J
--
Regards

- replace xyz with ntl

Merv wrote:
> You might want to request a Cisco SE to vet your final bill of materials

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