Ensuring that EFC Sees an Effectively Comprehensive Traffic Set

The EFC module may be set up to consume two different types of data: observing actual traffic via SPAN/Monitor functionality or consuming NetFlow data feeds.

The SPAN/Monitor approach presents several potential issues, including:

• Issues related to moving SPAN/Monitor traffic across a network
• Issues related to capacity constraints of forcing full-duplex traffic into a single transmit channel
• Issues related to consolidating multiple SPAN/Monitor traffic sources
• Issues related to traffic approaching “Line Rate”

In general our experience is that the SPAN/Monitor approach is to application traffic reporting faces increasing challenges as the size of the overall network, and volume of traffic, increase.

A NetFlow-based approach mitigates several of these constraints:

• NetFlow data export traffic is much easier to move across a network
• NetFlow data export traffic is much smaller than actually traffic, and thus does not face the “Full Duplex Squeeze” issue
• NetFlow data export traffic can be effectively consolidated from multiple sources
• Aggregate NetFlow data export volumes are typically far less than typical line speed configurations

NetFlow does face some complicating factors of its own, however. In general, the objective is to ensure the comprehensive collection of traffic from a specific “perimeter” of the network. Achieving this goal requires that several factors are considered:

• Per-Interface configuration
• Directionality of NetFlow Data
• Avoiding Double-Counting Data
• Cisco Catalyst-specific considerations

NetFlow statistics are only generated on interfaces that have NetFlow configured (via the route-cache flow command, in most cases). Identifying the set of interfaces which should have NetFlow configured requires explicitly identifying both the specific “perimeter” for which traffic is to be reported, as well as the directionality of the desired traffic reporting.

Within this scope, the nature of application traffic reporting makes it important to avoid having traffic flows “double counted” as viewed by the EFC module. One common topological pattern to look for here is direct connections between devices that are both NetFlow sources. In general, such “direct interconnection interfaces” should NOT be the source of NetFlow statistics.

The Cisco Catalyst architecture presents another set of challenges. First, it is important to understand that there are two completely different paths that packets follow through these devices. In general, the first packet in each flow is initially presented to the Route Processor, which then defines the flow-forwarding pattern; and then future packets within the flow are presented directly to the switch fabric for forwarding. For our purposes, it is important to understand that the Route Processor and the switch fabric are independent sources of NetFlow data for the traffic that is presented to them. Thus, a comprehensive NetFlow data collection configuration requires that BOTH of these levels of the architecture have appropriate Flow Export configurations enabled. This task is further complicated by the fact that these devices can be running in two different configurations, each with its own specific configuration details: a “Native IOS” mode, or a “Split IOS/CatOS” mode. Please see appropriate Cisco documentation for details.