[c-nsp] egress replication capability on CFCs?

Tim Stevenson tstevens at cisco.com
Tue Oct 10 10:55:57 EDT 2006

At 09:47 AM 10/10/2006 +0100, christian.macnevin at uk.bnpparibas.com commented:

>Right, now I remember, it was the lookups alone, not the actual replication.


>Our recommendation from your learned selves so far has been to stick 
>away from egress replication in
>financial networks until it's a bit more mature, and hard code the 
>devices to ingress.

I wouldn't say that, I think egress is perfectly matured, but whether 
it has benefits in a non-DFC system depends on the # of lookups 
required, the replication load, the configuration (eg, distribution 
of interfaces), etc.

If you have low enough data rates, then ingress will work just fine, 
you just want to monitor your fabric channel utilization to make sure 
you aren't nearing capacity.

>How strong is egress replication looking these days? I imagine many 
>of the service provider psychos
>with their MVPNs might be running it? :P

Don't think so, since MVPN is only supported with ingress mode ;)

But for large bandwidth replications such as many video streams, yes, 
egress with "local" MET programming (mls ip multicast egress local) 
is a requirement to conserve replication engine & fabric channel bandwidth.


>tstevens at cisco.com
>09/10/2006 18:45
>Christian MACNEVIN, cisco-nsp
>Re: [c-nsp] egress replication capability on CFCs?
>Strictly speaking, no, egress replication does NOT require DFC, it
>only requires a switch fabric & egress capable replication engines on
>the linecards (such as those on 67xx cards).
>The auto-detection is based only on card type, not whether there is a
>DFC present. It could be argued either way which is the better mode
>for CFC equipped cards, ingress or egress.
>With CFC, egress replication still gives you decreased fabric
>bandwidth consumption and distributed replication - but, at the same
>time, it could increase your system bus utilization, especially in a
>VLAN/SVI or distributed etherchannel environment, because you may do
>multiple lookups for the "same" OIF, one for each egress card with
>that OIF (eg, SVI 100 on cards 1 2 & 3 would each submit a lookup for
>the replicated copy to the PFC over the bus in egress mode; vs
>ingress mode where only one copy would be looked up at the PFC).
>In the end, though, at realistic packet sizes & data rates, this is
>probably not a major consideration, but you should probably consider
>monitoring bus, fabric, and fwding engine utilization to make sure
>you're not on the hairy edge.
>At 04:51 PM 10/9/2006 +0100, christian.macnevin at uk.bnpparibas.com commented:
> >Hi,
> >
> >I was under the impression that egress multicast replication required an
> >onboard DFC on a 67XX card, yet
> >I've got a box fully populated with 6748-SFP cards here telling me it's
> >current mode of replication is Egress.
> >
> >Doesn't this require the MET to be programmed onto the DFCs?
> >
> >Cheers
> >Christian
> >
> >
> >This message and any attachments (the "message") is
> >intended solely for the addressees and is confidential.
> >If you receive this message in error, please delete it and
> >immediately notify the sender. Any use not in accord with
> >its purpose, any dissemination or disclosure, either whole
> >or partial, is prohibited except formal approval. The internet
> >can not guarantee the integrity of this message.
> >BNP PARIBAS (and its subsidiaries) shall (will) not
> >therefore be liable for the message if modified.
> >
> >******************************************************************* 
> ***************************
> >
> >BNP Paribas Private Bank London Branch is authorised
> >by CECEI & AMF and is regulated by the Financial Services
> >Authority for the conduct of its investment business in
> >the United Kingdom.
> >
> >BNP Paribas Securities Services London Branch is authorised
> >by CECEI & AMF and is regulated by the Financial Services
> >Authority for the conduct of its investment business in
> >the United Kingdom.
> >
> >BNP Paribas Fund Services UK Limited is authorised and
> >regulated by the Financial Services Authority
> >
> >_______________________________________________
> >cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >https://puck.nether.net/mailman/listinfo/cisco-nsp
> >archive at http://puck.nether.net/pipermail/cisco-nsp/
>Tim Stevenson, tstevens at cisco.com
>Routing & Switching CCIE #5561
>Technical Marketing Engineer, Catalyst 6500
>Cisco Systems, http://www.cisco.com
>IP Phone: 408-526-6759
>The contents of this message may be *Cisco Confidential*
>and are intended for the specified recipients only.

Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Catalyst 6500
Cisco Systems, http://www.cisco.com
IP Phone: 408-526-6759
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

More information about the cisco-nsp mailing list