Enterprises using tools for network monitoring including bandwidth and traffic analytics will not run a copy of the reporting tool at every location. This due to it not being a cost effective or user friendly solution. What is done is have a central installation of the reporting tool, preferably at the data center or the head office, and have all the locations sent their data to this installation over WAN, MPLS or tunnels. The tool will collect the data and do the reporting. Easy to manage and maintain as well as consolidate.
When it comes to bandwidth and traffic analytics, the solution is NetFlow. NetFlow is not network intensive and still contains all the relevant data making it the choice. NetFlow is enabled on the routing and switching devices at all locations and the devices are configured to sent data to the reporting tool wherever it is installed. The problem comes up when the connectivity is over IPSec tunnels.
When using IPSec tunnels (GRE with IPSec is usually used for VPN over WAN), it is necessary that the packets transferred have to have the effect of the output features of the tunnel, namely QoS and Encryption. Only if the output features are applied on the packets will they be sent across to the destination over VPN. When it comes to NetFlow or self generated NetFlow to be specific, the output features will not take effect on these packets. ie. The NetFlow packets originating from the device where the tunnel has its source will not be encrypted thus preventing the NetFlow packets from being sent over the IPSec tunnel to the destination. This as Cisco says is by design but the end result is you end up not seeing NetFlow data exported from these devices though the destination IP Address is reachable from the source. The Cisco bug ID’s for this issue are CSCsk25481 and CSCef28662 and is applicable to both traditional and flexible NetFlow.
The solution is upgrading the IOS and Flexible NetFlow configured with output features. According to a Cisco blog, the bug has been fixed from IOS 12.4(20)T and 15.1(1)T of each release train. The next part is the Flexible NetFlow configuration to be applied on your routers which have to connect to the reporting server over IPSec tunnels. I will outline the flow exporter configuration here. You also need to create flow records and flow monitors (configuration not shown here) which then have to be associated to an interface to complete the configuration.
cisco_2811(config)#flow exporter FNFexp
cisco_2811(config-flow-exporter)#destination 192.168.116.80 // Replace with the IP Address of your NetFlow Analyzer server
cisco_2811(config-flow-exporter)#source FastEthernet 0/0 // Replace with the interface name of yoiur setup. Considering the scenario we discussed, this should be the tunnel source.
cisco_2811(config-flow-exporter)#transport udp 9996
cisco_2811(config-flow-exporter)#output-features
cisco_2811(config-flow-exporter)#export-protocol netflow-v9
The exporter and flow record has to be associated with a flow monitor which is then attached to an interface. In the configuration for the flow exporter, the key is output-features command. It is this option that sets NetFlow to have features applicable to the interface through which it is exported. In short, this command lets NetFlow packets generated on the router to be encrypted which lets it pass through the IPSec tunnel. The analyzer receives the flows and starts reporting. No more need to change the connectivity type just for the sake of NetFlow export.
Regards,
Don Thomas Jacob
Download | Interactive Demo | Product overview video | Twitter | Customers
REFERENCE:
i. Alec Water’s post in https://forums.manageengine.com/topic/netflow-for-remote-routers-over-ipsec-vpn
His quite interesting blog which discusses mainly on network security can be seen here.
It helped me a lot