lukasz at bromirski
Mar 2, 2012, 4:17 AM
Post #9 of 15
On 2012-03-02 12:44, Artyom Viklenko wrote:
> Switch Fabric Resources
> Bus utilization: current: 13%, peak was 51% at 21:31:26 EET Sat Feb 18 2012
> Fabric utilization: Ingress Egress
> Module Chanl Speed rate peak rate peak
> 2 0 20G 23% 46% @22:57 30Jan12 18% 49% @22:02 31Jan12
> 2 1 20G 21% 49% @20:08 01Feb12 25% 46% @20:14 25Feb12
> I.e. 4,6 Gbps on channel 0 and 4,2 Gbps on channel 1. No DFC on module.
> Total input on all four 10GE ~ 19 Gbps. Fabric switching only 8,8 Gbps.
> Similar approach I see on 6708 with DFC. Some part of traffic goes via
> fabric and some in line card itself.
That's normal for "non-optimized" traffic patters, so in real life :)
You can check for example using NetFlow, if there are flows that
could be optimized within one Port ASIC on one LC. Some people decide
it's worth and do it, some skip it.
> AFAIK, presense of DFC influence only forwarding decisions process (and
> policyng, for example) but not on moving traffic itself?
Yes, see my answer to Ytti.
> Anyway, if traffic should be switched in ASIC what is the limitations
> in terms of bandwidth or PPS?
The bandwidth for 6704 is line rate of front ports, as it
connects using 2x20Gbit/s channels to the fabric. The DFC however
is limited to 48Mpps and the traffic through the fabric uses additional
So if you have 4 10GE ports doing forwarding for 64B packets fully
locally, it will be 4x14.8Mpps=59.2Mpps, while the DFC can only do
Depending on your traffic profile, you'll either hit PPS limitation
of the DFC (or the centrally located PFC) or the bandwidth constrain
for the 64B packets (DDoS for example).
"There's no sense in being precise when | Łukasz Bromirski
you don't know what you're talking | jid:lbromirski [at] jabber
about." John von Neumann | http://lukasz.bromirski.net
cisco-nsp mailing list cisco-nsp [at] puck
archive at http://puck.nether.net/pipermail/cisco-nsp/