The topics in our previous posts were mainly related to flow optimization and configuration in terms of achieving optimal results on the flow collector side. The diversity of routers and L3 switches on the market as well as their support of different flow standard implementation makes the flow export configuration sometimes a bit confusing. Next couple posts will help demystifying flow export configuration problem for two mayor vendors – Cisco and Juniper.
Cisco portfolio contains network devices targeted at enterprise and service provider environments. Consequently, Cisco offers operating system with appropriate features. Cisco IOS refers to a well-known and widely used network operating system that runs on Cisco routers and switches meant mainly for enterprise use. On the other hand, Cisco delivers IOS XR operating system to service providers who require a different set of features and have strict requirements in terms of availability, scalability and management. One of the main differences between these operating systems worth mentioning is that IOS XR is distributed, meaning that process separation is achieved through granular process management, whereas IOS is completely monolithic. Bearing in mind these differences, we present for each operating system the required Netflow configuration.
Each Netflow configuration may be logically divided into two basic steps – interface flow configuration and flow destination parameters. Configuration example is presented below:
! Flow export configuration Router(config)#ip flow-export destination 192.168.1.1 4444 Router (config)#ip flow-export version 9 Router (config)#ip flow-cache timeout active 5 Router (config)#ip flow-cache timeout inactive 15 ! Interface flow activation and configuration Router (config)#interface GigabitEthernet 0/1 Router (config-if)#ip flow ingress
Previous example contains basic Netflow configuration commands in order have a functional flow export. This means that flows are exported to address 192.168.1.1 via UDP port 4444. It is worth noting that Cisco routers support up to two export destinations simultaneously. This limitation can be addressed using Netflow reflector covered in previous post.
Aside from Netflow version 9 presented in the configuration example, Cisco additionally supports versions 1 and 5 (not compatible with version 9). Flow cache timeout commands can be used to manage flow cache size, more specifically, how fast active and inactive flows are removed from the flow cache. The values for active and inactive flows are specified in minutes and seconds, respectively.
Distinguishing between active and inactive flows and assigning proper timeout values is very important from the perspective of flow cache utilization and the accuracy of flow export. Flow transitions from active to inactive state if it does not detect packets for the period designated by the inactive timeout value (default is 15 seconds) or if the TCP termination flag shows up, i.e. FIN or RST. Such inactive flow is exported and subsequently flushed from cache. Long-lived active flows should be periodically exported in segments so that Netflow collector is able to aggregate flow information. Such fragmentation of active flows allows us to avoid potential flow cache overrun and increase in interface utilization over which flow export is achieved, which would happen if there were a lot of long-lived flows and long active timeout configured.
In terms of active timeout selection, it should configured according to the Netflow collector aggregation period and cache size. It is worth mentioning that if the flow cache is full, all flows are exported to the collector and flushed. For the inactive timeout value, recommended value is 15 seconds. When there is a lot of short-lived flows, lower timeout enables prompt release of cache memory, but on the other side if there are flows that are aged-out due to short inactive timeout flow correlation on collector will be harder. These parameters should be carefully tweaked according to the collector aggregation period (active timeout) and recommended values (15 seconds timeout for inactive flow) for majority of use cases and flow statistics.
Netflow interface configuration defines whether incoming (ip flow ingress) or outgoing (ip flow egress) flows are collected. Caution should be taken when using egress flow collection since Cisco states that such export may affect performance due to additional accounting-related computation that takes place on router forwarding path. Details regarding flow collection strategy and avoiding deduplication of exported flows can be found in the previous blog.
Cisco IOS XR
Netflow configuration on IOS XR consists of configuring sampler map, exporter map and flow monitor map. Sampler map contains details about sampling rate on the designated interface where flow should be collected. Exporter map specifies destination address and port, Netflow version and template content. Flow monitor map references export map and defines additional parameters pertaining to the flow cache timeout and address family (currently supported are IPv4, IPv6 and MPLS).
Example of Netflow configuration along with respective maps is depicted in the following snippet:
! Sampler map configuration RP/0/RP0/CPU0:router(config)# sampler-map flow-sample-1 RP/0/RP0/CPU0:router(config-sm)# random 1 out-of 1022 ! Flow exporter map configuration RP/0/RP0/CPU0:router(config)# flow exporter-map flow-export-1 RP/0/RP0/CPU0:router(config-fem)# destination 192.168.1.1 RP/0/RP0/CPU0:router(config-fem)# transport udp 4444 RP/0/RP0/CPU0:router(config-fem)# exit RP/0/RP0/CPU0:router(config-fem)# version v9 RP/0/RP0/CPU0:router(config-fem-ver)# template data timeout 600 ! Flow monitor map configuration RP/0/RP0/CPU0:router(config)# flow monitor-map flow-monitor-1 RP/0/RP0/CPU0:router(config-fmm)# record ipv4 RP/0/RP0/CPU0:router(config-fmm)# exporter flow-export-1 RP/0/RP0/CPU0:router(config-fmm)# cache timeout active 5 RP/0/RP0/CPU0:router(config-fmm)# cache timeout inactive 15
Previous configuration contains sampler map flow-sample-1, which specifies the sampling rate. Minimum sampling rate varies on the router model so product documentation should be consulted. It is important to highlight the same as with Cisco IOS in terms of flow timeout values, which are previously specified as active and inactive flow timeout and are equal to 5 minutes and 15 seconds, respectively. The selection of these values is made according to the Netflow collector aggregation interval and recommended inactive timeout value.
Flow monitor map and sample map must be applied to the designated interface like the following example:
RP/0/RP0/CPU0:router(config)# interface TenGigE 0/2/2/0 RP/0/RP0/CPU0:router(config-if)# flow ipv4 monitor flow-monitor-1 sampler flow-sample-1 ingress
Finally, don't forget to commit… :)