Thanks for all the input guys. I found the root of my problem. It looks like adding the DFCs would have solved the issue immediately if we had added them in when we were still running the SXF train code. As it is, we had added the DFCs into the mix AFTER we had already upgraded our code to 12.2(33)SXH3a. It looks as if Cisco changed the default behavior of egress SPAN in SXH2a (and later releases) to centralized SPAN. More info on this here:
http://www.cisco.com/en/US/docs/ios/fundamentals/command/reference/cf_m1.html#wp1087064 Simply adding a "monitor session egress replication-mode distributed" coupled with the DFCs we had already added and using our current 12.2(33)SXH3a code did the trick. Our SPAN output traffic is now spot on with the cumulative total of the three source interfaces in the session. One other thing of note: There was no indication that the PFC3BXL was overwhelmed at all by this session while we were still in centralized mode. All the data we looked at ('show platform hardware capacity looking at SP utilization on the 720 and fabric connections, etc.) never seemed to imply we were in any danger and had plenty of headroom. However, one can't argue with the end result that by tossing in the DFCs and changing the SPAN mode to leverage them (egress replication-mode distributed) -- the problem went away. ;) Just thought I'd follow up in case anyone else ever runs into this one. Cheers, -Jeremy
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
