I found out the other day that the HP 9300 series Procurve routing switches (9304m, 9308m, and 9315m) support NetFlow in software release 07.6.04 or greater.  In the Advanced Configuration and Management Guide on page A-8 the NetFlow capabilities are outlined. It also supports sFlow which is discussed on page A-30.  In this blog however, I’m going to discuss the impressive HP NetFlow support.

Here are some highlights of the HP 9300 NetFlow Support abilities:

• You can use a total of 15 collectors. You can specify up to 10 collectors for the main flow cache, and one additional collector for each aggregate cache.
• The support NetFlow v1 and v5 for traditional exports and v8 for aggregated exports but, I didn’t see anything about v9 or IPFIX.  The default configuration is v5 which is the most popular.
• The configuration process is very similar to a Cisco IOS NetFlow setup
• You can Disable the export for specific transport protocols.
• You can export peer or origin autonomous system information
• It supports the ability to configure NetFlow aggregation using NetFlow v8.

The HP NetFlow Configuration Process

To enable NetFlow, enter the following command at the global CONFIG level of the CLI:

HP9300(config)# ip flow-export enable
HP9300(config)# ip flow-export version 5
HP9300(config)# ip flow-export destination 10.10.10.1 2055 1
HP9300(config)# ip flow-cache timeout active 1
HP9300(config)# ip flow-cache timeout inactive 15
HP9300(config)# ip flow-export source loopback 1/1
HP9300(config)# exit

Read the manual to get details on the above.  The point is that it is very similar to a Cisco IOS NetFlow configuration.

To enable Flow Switching on an interface, enter commands such as the following:

HP9300(config)# interface ethernet 1/1
HP9300(config-if-1/1)# ip route-cache flow
HP9300(config-if-1/1)# exit
HP9300(config)# interface ethernet 1/2
HP9300(config-if-1/1)# ip route-cache flow
HP9300(config-if-1/1)# exit
HP9300(config)# interface ethernet 1/3
HP9300(config-if-1/1)# ip route-cache flow
HP9300(config-if-1/1)# exit
;Repeat the above for each interface
HP9300(config)# exit
HP9300# reload

Perhaps the feature that impressed me that most is the ability to configure NetFlow aggregation in 5 different ways:

• as – Configures an AS cache. Flows are aggregated based on AS number.
• destination-prefix – Configures a destination prefix cache. Flows are aggregated based on destination network prefix.
• prefix – Configures a prefix cache. Flows are aggregated based on both source and destination network prefixes.
• protocol-port – Configures a protocol port cache. Flows are aggregated based on source and destination IP protocol port.
• source-prefix – Configures a source prefix cache. Flows are aggregated based on source network prefix.

The above aggregation methods allow for the dramatic reduction in flow exports at the cost of less detail but, the benefit is that you don’t have to resort to sampling like sFlow. I would prefer the ability to specify my own custom aggregation method like I can with Cisco IOS but, the way the manual read, I don’t think you can.  Personally, I might like to aggregate based on Source/Destination IP address, protocol, nexthop, and subnet mask.  By removing source and destination port from the aggregation, the volume of flows can often be reduced by well over half!

Example Aggregation Configuration for AS number:

HP9300(config)# ip flow-aggregation cache as
HP9300(config-flow-cache_as)# cache entries 2046
HP9300(config-flow-cache_as)# cache timeout inactive 200
HP9300(config-flow-cache_as)# cache timeout active 45
HP9300(config-flow-cache_as)# export destination 10.42.42.1 9992
HP9300(config-flow-cache_as)# enabled

Finally, the following command will display the NetFlow configuration:
HP9300(config)# show ip flow export

Again, the manual has way more information than I’m providing here.  Read up if you have any questions on how to get this configured and give us call if you need help.  BTW: the HP SR6600, the HP 10500 Switch and the EFS WAN Accelerator  all support Netflow as well.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post HP 9300 NetFlow Configuration appeared first on NetFlowKnights.com.

With the increasing popularity of vSwitches; some of you may be asking “how do I go about enabling NetFlow / IPFIX in a virtual environment?” Well today, I’m going to help answer that question for not one, but 3 of the most popular virtual switches: OpenVSwitch, VMware vSphere, and the Cisco Nexus 1000v.

OpenVSwitch ( Xen ):

Open vSwitch is a production quality, multilayer virtual switch licensed under the open source Apache 2.0 license. It is currently included with the Xen Hypervisor and has been gaining a lot of popularity in the vswitch world. Open VSwitch monitoring can be a very valuable resource in solving virtual network issues.

OpenVSwitch NetFlow Configuration:

root@XorPlus# ovs-vsctl –db=tcp:10.10.50.215:6633 — set Bridge br0 netflow=@nf — –id=@nf

create NetFlow targets=\”10.10.50.207:2055\” active-timeout=1

root@XorPlus#

In above CLI, the parameter is shown as following:

COLLECTOR_IP=10.10.50.207

COLLECTOR_PORT=2055

ACTIVE_TIMEOUT=1

VMware vSphere ESX v5.1:

The vSphere Distributed Switch provides rich monitoring and troubleshooting capabilities. Added in version 5.1 was vSphere IPFIX support which makes for better details in its flow exports.

VMware IPFIX configuration:

First, edit the settings of the distributed switch by right clicking on your virtual switch; then click on the 4^th tab over labeled “NetFlow”. IPFIX on Distributed Switches can be enabled at the port group level, at an individual port level or at the uplink level.

If you configure IPFIX export here first, be sure to ENABLE NetFlow at the port group level, at an individual port level or at the uplink level.

The NetFlow configuration screen shows the different parameters that can be controlled during the setup.

1.      The Collector Settings of IP address and Port should be configured according to the information collected about the collector tool installed in your environment.

2.      The Advanced Settings parameters allow you to control the timeout and sampling rate for the flows. To change the amount of information that is collected for a flow, you can change the sampling rate. For example, a sampling rate of 2 indicates that the Virtual Distributed Switch (VDS) will collect data from every other packet. You can also modify the Idle flow export timeout values.

3.      The VDS IP address configuration is useful when you want to see all flow information in the collector tool as part of one VDS IP address and not as a separate host management network IP address.

If the VDS IP address is left blank each virtual machine will appear as a separate exporter at the collector.

When configuring IPFIX at the port level, administrators should select the NetFlow override tab, which will make sure that flows are monitored even if the port group–level IPFIX is disabled.

Nexus 1000v:

Cisco Nexus 1000V Series Switches provide a comprehensive and extensible architectural platform for virtual machine (VM) and cloud networking. Cisco is the organization who invented NetFlow and was the first to have virtual NetFlow support. The 1000v NetFlow configuration is very similar to its hardware based Nexus 7000 cousin.

Nexus 1000v Netflow configuration:

Configuring virtual switch NetFlow is very easy no matter what Hypervisor you are monitoring. NetFlow technology doesn’t only provide valuable information about virtual network issues but it can help keep the network secure by performing behavioral analysis and IP reputation checking on the network as a whole. Are you taking full advantage of the monitoring features available in your vSwitch solution? Please share your success stories in the comments below.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Enabling NetFlow on a vSwitch appeared first on NetFlowKnights.com.

For today’s blog, I’ll be discussing how to configure NetFlow on the Silver Peak WAN Optimizer.

We’ve previously mentioned Cisco WAAS NetFlow support and Riverbed Steelhead NetFlow support.

And now, with Silver Peak Systems taking more of the WAN Optimization market share, it’s about time we help you get the most out of your investment by leveraging flow technologies available from your Silver Peak.

The NetFlow configuration for the Silver Peak WAN optimizer is a simple, 4 step process.

Referring to the image below, go to ‘Configuration – NetFlow’ on the Silver Peak WAN optimization controller.

1. Check ‘Flow Exporting Enabled’
2. Set ‘Active Flow Timeout’ to 1 minute
3. Select ‘Traffic Type(s)’ – to see both ingress and egress flows for your WAN and LAN, select WAN Tx, Rx, and LAN Tx, and Rx.
4. Enter the IP Address for your flow collector in ‘Collector1 IP’, and the listening port in ‘Collector1 Port’.   (You can configure up to 2 flow collectors.)

Setting the Active Flow Timeout is important because Scrutinizer calculates bandwidth utilization based on 1 minute intervals.  Typically, the default value is 30 minutes.

What this means is that if you have a long-lived conversation, such as a file download, or a telnet session, then the flow export for that conversation will not occur until it completes, or 30 minutes has passed, whichever comes first.  The resulting reporting in Scrutinizer may then display huge spikes at the end of the 30 minutes, and also very low utilization where there has been traffic not yet reported.

Step 3, enabling both transmit and receive on both lan and wan traffic, is critical with WAN optimizers, to accurately report the compressed flow data leaving the Silver Peak.  This allows flow reporting based on both ingress flows and egress flows.

Without exporting egress flows, your NetFlow Analyzer solution must use ingress flows to report outbound data.  So if the data was compressed, using the ingress flows to report the data will not be accurately reporting the byte reduction, but rather, will report outbound identical to inbound.  So the outbound data reported will be misleading.

Exporting both interfaces, with both Tx and Rx, however, gives you complete visibility of inbound and also the outbound compressed data rates, and is the preferred and recommended flow configuration.

For more detailed information on Silver Peak Systems NetFlow configuration, go to page 75 of the Appliance Manager Operator’s Guide.  Then, for rich flow reporting of all flows exported by the Silver Peak, check out this Best in Class NetFlow and sFlow solution.

Do you need (or want?) more visibility of your network?  Contact us with your list of network devices and we can let you know if and how they support flow exports.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Silver Peak Systems: How to configure NetFlow appeared first on NetFlowKnights.com.

Lately in support we have been getting a lot of questions on how to configure Cisco Nexus 7000 switches for NetFlow. The Nexus 7000-M series supports full and sampled NetFlow while the 7000-F series only supports sampled. So now you might be asking what is the difference in the two and which one should I use.

Sampled NetFlow/Full NetFlow

Sampled NetFlow allows you to collect NetFlow statistics on a subset of the data that is coming into the interface. An example would be to collect 1 in 100 packets. The benefit of this of course is less overall load on the device and faster switching since most of the data will not have to be processed for NetFlow. So now you may be asking yourself, “that sounds great but there has to be some kind of a downside”; there is.  The problem we run into with sampled NetFlow is that, since we are taking a sample of the data, we are not going to see a lot of the crucial information in our NetFlow monitoring tool since it might not make it into the sample, but it is, however, better than not sending any NetFlow. I will go through a Nexus 7000 configuration below. Make note that you only need to create and apply the sampler if using Sampled NetFlow.

Create Flow Record

First we want to create our flow record which we will call “Test”:

switch# conf t
switch(config)# feature netflow
switch(config)# flow record Test
switch(config-flow-record)# match ip protocol
switch(config-flow-record)# match tos protocol
switch(config-flow-record)# match ipv4 source address
switch(config-flow-record)# match ipv4 destination address
switch(config-flow-record)# match transport destination-port
switch(config-flow-record)# match transport source-port
switch(config-flow-record)# match datalink mac source address input
switch(config-flow-record)# match datalink mac destination address input
switch(config-flow-record)# collect transport tcp flags
switch(config-flow-record)# collect interface input
switch(config-flow-record)# collect interface output

Create Flow Exporter:

For this example we will call our flow exporter “ExporterTest”:

switch# conf t
switch(config)# flow exporter ExporterTest
switch(config-flow-exporter)# description export netflow to collector
switch(config-flow-exporter)# destination 10.1.3.138
switch(config-flow-exporter)# export Version 9
switch(config-flow-exporter)# transport udp 2055
switch(config-flow-exporter)# source loopback 0

We will also call our flow monitor “MonitorTest” and apply our flow record “Test”:

switch(config)# flow monitor MonitorTest
switch(config-flow-monitor)# exporter ExporterTest
switch(config-flow-monitor)# record Test
switch(config)#exit

Create Sampler: (Only needed if using Sampled Netflow)

Now we need to create our Sampler which will be used if exporting Sample NetFlow (needs to be configured if using a Nexus 7000-F series):

switch(config)# sampler SampleTest
switch(config-flow-sampler)# mode 1 out-of 100
switch(config-flow-sampler)# exit
switch(config)#

Apply flow monitor to interfaces:

Now we will need to apply the flow monitor and sampler if needed to our interfaces:

switch (config)# interface Vlan###
switch(config-if)# ip flow monitor MonitorTest input SampleTest
switch(config-if) exit

Save:

Now we just need to save the running config:

switch(config)# copy running-config startup-config
switch(config)# exit

There you have it! You now should be exporting NetFlow on your Nexus 7000-M/F Series switch. If you run into any issues or have any questions on configuring NetFlow feel free to contact us in support.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Nexus 7000 NetFlow Support appeared first on NetFlowKnights.com.

Instructions for the Cisco WLC NetFlow configuration can be found in the Cisco Wireless LAN Controller Configuration Guide, Release 7.4, page 130.   The NetFlow configuration instructions are also outlined below.

Enabling NetFlow exports from the Cisco Wireless LAN Controller gives you Cisco’s Application Visibility and Control reporting in Scrutinizer v11.  Examples of these advanced reporting features are also included below.

Configuring Cisco WLC NetFlow (GUI)

Configuring NetFlow (CLI)

• Create an Exporter by entering this command:
config flow create exporter exporter-name ip-addr port-number
• Create a NetFlow Monitor by entering this command:
config flow create monitor monitor-name
• Associate or dissociate a NetFlow Monitor with an Exporter by entering this command:
config flow {add | delete} monitor monitor-name exporter exporter-name
• Associate or dissociate a NetFlow Monitor with a Record by entering this command:
config flow {add | delete} monitor monitor-name record ipv4_client_app_flow_record
• Associate or dissociate a NetFlow Monitor with a WLAN by entering this command:
config wlan flow wlan-id monitor monitor-name {enable | disable}
• See a summary of NetFlow Monitors by entering this command:
show flow monitor summary
• See information about the Exporter by entering this command:
show flow exporter {summary | statistics}
• Configure a debug of NetFlow by entering this command:
debug flow {detail | error | info} {enable | disable}

Cisco Wireless NetFlow Reporting

Now that we have the Wireless LAN Controller NetFlow configuration covered, let’s talk about Cisco Wireless NetFlow Support, Wireless NetFlow reporting and the Application Visibility and Control reporting available from Scrutinizer.

For AVC configuration assistance, please refer to the Application Visibility and Control Deployment Guide.

The Advanced NetFlow Wireless reports available are:

• Applications Downstream
• Applications Upstream
• Applications by Wireless Host
• Applications by Wireless Host with DSCP
• Hosts by SSID
• Hosts with MAC
• SSID List

In addition, the following Cisco AVC report is available for the WLC:

• NBAR: Applications

Here is an example of the NBAR: Applications report for the Wireless LAN Controller.

As explained in Jimmy D.’s blog on Cisco WLC NetFlow support, the applications report is proved by a “robust, proven NBAR2 library” which supports more than 1000 applications.  This NBAR2 (Network Based Application Recognition) library is also regularly updated to provide the most up-to-date Application reporting.

Also, using the simple reporting navigation available in our NetFlow Analyzer, with just one click from the NBAR: Applications report, you can now see who accessed those applications!

In the example above, in the NBAR: Applications report, we can select an application (Facebook, for example) and then select a WLC NetFlow report such as Hosts with MAC.  The application “Facebook” is automatically added to the Hosts with MAC report, resulting in a report showing IP Address, the STA MAC Address, AP MAC Address, and traffic bit rate based on their use of Facebook on the wireless network; just clicks away to a wealth of information from your Wireless Controllers.

To see this Advanced NetFlow reporting for yourself, please give us a call at 207-324-8805 x3.  We can show you the rich reporting and analytical features available, and also help you install (and configure!) at your site for first-hand testing in your environment.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Cisco WLC NetFlow Configuration appeared first on NetFlowKnights.com.

I recently discovered that the Ecessa appliance has the ability to send NetFlow v5 or IPFIX information to a NetFlow/IPFIX collector. In this blog, I am going to explain how to configure NetFlow with Ecessa appliances.

According to Ecessa’s website, the Powerlink 175EHQ, Powerlink 600EHQ, and the Powerlink 1200EHQ all provide support for NetFlow/IPFIX, but their support site indicates that the Clarilink CL175EHQ also supports NetFlow. The documentation on their website shows the configuration being done with the CL175EHQ and the support is for IPFIX, even though it states “Enable NetFlow”. For those with the smaller Outpost PL and Outpost PL+, these devices are also capable of sending NetFlow/IPFIX data. So if you already have a NetFlow solution, like the one Plixer offers, you can opt for the lower cost Outpost PL over the higher-end PowerLink appliances and still get full visibility on your network.

How to enable NetFlow

Click on NetFlow under Advanced Setup in the left-hand menu. On the NetFlow configuration page:

1. Select the Enable NetFlow checkbox.
2. Click the “Add a new NetFlow Collector” button. The Host IP is the IP address of the NetFlow collector. The Host Port is the appropriate UDP port the collector uses to listen for reports.
3. Click the Activate button to save the changes.

There you have it, your Ecessa appliance is now sending IPFIX data to your collector(s). A few important things to keep in mind regarding the Ecessa appliance:

• If the address entered for the NetFlow collector is not in the same network as the Ecessa appliance, make sure the Ecessa appliance has a route to the collector so the information can be sent properly.
• The Sample Rate field indicates how often packets should be processed. For example, a sample rate of 20 means 1 out of every 20 packets will be processed, which is suitable for most configurations. A sample rate of 1 will cause every packet to be processed. If you want full visibility in your network then you will need to configure the device with a sample rate of 1; otherwise, any data that is not sampled will not be reported in your netflow collector. Choosing a sample rate of greater than 1 would be the equivelent of using sFlow technology. One thing to note, however, is that if you have a high flow volume the sample rate of 1 will cause higher CPU utilization.
• The NetFlow support on the Ecessa appliance is for LAN interfaces only; traffic going over the WAN would not be included. You could, however, connect your Ecessa appliance to an Internet facing router/switch and then collect the NetFlow from that device.

Let us know if you need help setting up NetFlow/IPFIX on your Ecessa appliance or other exporters; we are here to help.

Justin


For a free 30 day trial of Scrutinizer, Download Now!
Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Configure NetFlow with Ecessa appeared first on NetFlowKnights.com.

If you are looking to gain more visibility of your network traffic through your WAN Optimizer, then please read on.  In this blog I will take you step by step through the Exinda NetFlow configuration.

Exinda NetFlow Configuration

To start on the WAN Optimization NetFlow configuration on your Exinda appliance, the first step is to select NetFlow Configuration in the System Setup section of the Exinda Appliance.

The next step is to ‘Add New NetFlow collector’.

• IP Address – Enter your NetFlow collectors IP address here
• Port – This is the UDP port used for the NetFlow exports, UDP Port 2055 is one of the standard, commonly used ports
• Version – This is the NetFlow export version. Version 9 is the latest version of NetFlow supported by the Exinda appliance, so would be the optimal choice.

After all of the fields are filled out, then click the ‘Add NetFlow Collector’ button.

NetFlow Options

The next step is to customize the NetFlow record exports using the NetFlow Options form as shown below.

For detailed information on each of these fields, access the Exinda NetFlow configuration guide at page 53 of the Exinda User Manual.

Some fields to note are:

• Active flow timeout – recommended setting is 1 minute, so that long-lived conversations have flows exported every minute, providing more accurate flow reporting by the NetFlow collector.
• Template Timeout Rate – recommended setting is 1 minute, to allow more timely updates of flow templates
• General Options Timeout Rate – recommended setting is 1 minute, for more timely updates of options templates

V9 Optional Fields allow for export of extended data, such as:

• L7 Application ID
• Policy ID
• Type of Service (TOS)
• VLAN ID
• Min and Max Packet Sizes
• Min and Max TTL
• Flow Direction
• SNMP Input and Output Interfaces
• Output byte and packet counters
• Username details
• VoIP MOS and rFactor
• Hostnames
• Traffic class

V9 Option Fields – Metrics

• RTT
• Network Delay
• Network Jitter
• Server Delay
• Bytes Lost
• APS Score

Combining the flexibility of defining which elements to export in the Exinda flow records with our Advanced NetFlow solution provides even deeper visibility into your network traffic.  Applications and Network Delay are just a few examples of this.

So what does this mean for you?

Since Exinda NetFlow support has now taken their NetFlow exports to the next level, an advanced NetFlow reporting solution can then also take the flow reporting for Exinda WAN Optimizers to the next level.

Scott Robertson will be discussing the new Exinda NetFlow reporting available in our Advanced NetFlow reporting solution in an upcoming blog.  Don’t miss it.

Did you know that Exinda is not the only WAN Optimizer with NetFlow support?  Riverbed, SilverPeak, and Cisco WAAS are others that also support flow exports.  For configuration instructions on these devices and others, either visit our Configuring NetFlow, IPFIX & sFlow page, search our blogs, or contact us directly at 207-324-8805 for support with the flow configurations.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Exinda NetFlow Configuration appeared first on NetFlowKnights.com.

The Dell SonicWALL Next Gen NetFlow configuration is slightly different due to enhancements to the firewall configuration GUI.  The SonicWALL IPFIX support blog, written by Adam Caesar in 2011, lists the steps required for pre-Generation 5 and 6 SonicWALL firewalls.  Today I will cover what has changed in the Next Gen firewalls’ NetFlow config and also include other configuration options that can affect your network traffic monitoring experience.

SonicWALL NetFlow configuration

To start your Dell SonicWALL Next Gen NetFlow configuration, in the firewall GUI, go to AppFlow>>Flow Reporting, then select External Collector from the buttons just above the Flow Reporting Statistics.

That will take you to the page displayed below.

1. Check Send Flows and Real-Time Data to External Collector (you may need to reboot the firewall for the enable/disable flows to take effect).

2. Select IPFIX with extensions from the External Flow Reporting Format dropdown selection list.

3. Enter your NetFlow collector’s IP Address in the External Collector’s IP Address field.

4. Check both Send IPFIX/Netflow Templates at Regular Interval and Send Static AppFlow at Regular Interval

5. For richer flow reporting, ensure that the Send Static AppFlow for Following Tables and Send Dynamic AppFlow for Following Tables lists match the example above.

6. Next, Report on Connection OPEN and Report on Connection CLOSE should both be selected.

7. Also check Report Connection on Active Timeout, leaving the Number of Seconds at 60.  (This setting specifies the firewall to export flows every minute, as opposed to waiting until the flow cache is full.  That allows your NetFlow reporting solution to report traffic in a more timely manner.)

a. Since it’s either Report Connection on Active Timeout OR Report Connection on Kilo BYTES exchanged, we’ll leave the Kilo BYTES Exchanged option unchecked.

8. And, lastly, make sure that the Report Connections on Following Updates list matches the above example.

9. Click the Accept button at the top, and that’s it for the SonicWALL NetFlow configuration.

In a few minutes you should start seeing flows in your NetFlow Analyzer and you are on your way to in-depth network traffic monitoring.

SonicWALL SNMP config

Our Advanced NetFlow Analyzer solution uses SNMP Read-Only access to gather interface descriptions and speeds to add ease of use in your SonicWALL NetFlow reporting.

Using the image below as an example, go to System>>SNMP

1. Check the checkbox for Enable SNMP, then click Configure

2. Complete the System Name, Contact, and Location fields

3. Enter a Get Community Name

4. Enter your NetFlow collector’s IP Address in one of the Host fields.

5. Click OK

6. Next, go to Network>>Interfaces, click on the Configure icon for the interface you are exporting flows through, and make sure that in the Management section, SNMP is selected.

7. Click OK

 SNMP is now enabled and ready for your NetFlow collector to access.

Live SonicWALL Configuration Demo available

To walk through these steps before implementing in your live network, check out the Dell SonicWALL live demo site first.

SonicWALL NetFlow Reporting

We also have an evaluation of our NetFlow Analyzer available by clicking the link below, which adds value to the SonicWALL NetFlow exports by providing extended reporting on:

• HTTP URLs per connection
• User Name reporting
• Application detection
• VoIP details
• Intrusions
• Viruses

That is in addition to the standard NetFlow reporting – conversations, hosts, top protocols, and more, to simplify your network traffic monitoring and more easily provide management level reporting.

If you still have questions on configuring your Next Gen firewall to export flows, please do not hesitate to contact us directly, or for more information on what other advanced reporting is available for the Dell SonicWALL firewall, please read the SonicWALL NetFlow reporting blog. If you have any other NetFlow related questions, or would like to test our solution, please download from this page, or contact us directly at 207.324.8805 x3.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post SonicWALL Next Gen NetFlow config appeared first on NetFlowKnights.com.

Cisco UCS Netflow Support was recently added with the release of version 2.2(2c).  NetFlow exports can be configured either in the GUI or the CLI.  The configuration is somewhat different from the typical Flexible NetFlow configuration.  In this blog we will take a look at the CLI configuration method and some of the different aspects of this new NetFlow export!

Figure 1: Cisco UCS NetFlow Support [Source]

Cisco UCS NetFlow CLI Configuration:

The fundamentals of typical IOS Flexible NetFlow configuration are present in this new export as you configure a record, exporter, and monitor – then apply that monitor to what interface you want to see metrics on.  The commands, though, are quite different.

First off, we need to build the Flow Record; in this case I built two, one for IPv4 and one for layer two traffic:

scope eth-flow-mon
enter flow-record flow-record-ipv4
set keytype ipv4keys
set ipv4keys ipv4-src-address ipv4-dest-address src-port dest-port ip-protocol ip-tos
set nonkeys counter-bytes-long counter-packets-long sys-uptime-first sys-uptime-last
commit-buffer

scope eth-flow-mon
enter flow-record flow-record-l2
set keytype l2keys
set l2keys src-mac-address dest-mac-address ethertype
set nonkeys counter-bytes-long counter-packets-long sys-uptime-first sys-uptime-last
commit-buffer

Next, we need to configure a NetFlow Exporter Profile.  This differs from FNF and is specific for the Cisco UCS.  This profile contains the networking properties used to export NetFlow packets and is a global configuration.

scope eth-flow-mon
scope flow-profile flow-exporter-profile
enter vlan xxx
enter fabric a
set addr xx.xx.xx.xx subnet 255.255.255.0
up
enter fabric b
set addr xx.xx.xx.xx subnet 255.255.255.0
commit-buffer

Now we need to specify the NetFlow Collector.  Each flow collector contains an IP address, port, external gateway IP, and VLAN that defines where the flows are sent.

scope eth-flow-mon
enter flow-collector flow-collector
set dest-port 2055
set vlan vlanxxx
enter ip-if
set addr xx.xx.xx.xx
set exporter-gw xx.xx.xx.xx
commit-buffer

After that we can return to a more configuration that resembles a Flexible NetFlow Configuration, and configure the Flow exporter, which includes the template timeouts.  Please note that this not the active timeout!!  We will get to that later in the configuration.

scope eth-flow-mon
enter flow-exporter flow-exporter
set dscp x
set flow-collector flow-collector
set exporter-stats-timeout 300
set interface-table-timeout 300
set template-data-timeout 300
commit-buffer

Next, we need to configure a Flow Monitor(s).  A flow monitor consists of a flow record, one or two flow exporters, and a timeout policy.  Note: Each flow monitor operates in either the ingress or egress direction because we do not match and collect interface information.

scope eth-flow-mon
enter flow-monitor flow-monitor-ipv4
set flow-record flow-record-ipv4
create flow-exporter flow-exporter
commit-buffer

scope eth-flow-mon
enter flow-monitor flow-monitor-l2
set flow-record flow-record-l2
create flow-exporter flow-exporter
commit-buffer

If we have two flow records and two monitors, we can create a Flow Monitor Session:

scope eth-flow-mon
scope flow-mon-session flow-monitor-session
create flow-monitor flow-monitor-ipv4
create flow-monitor flow-monitor-l2
commit-buffer

Configuring NetFlow Cache Active and Inactive Timeout:

scope eth-flow-mon
scope flow-timeout default
set cache-timeout-active 60
set cache-timeout-inactive 15
commit-buffer

Associating a Flow Monitor Session to a vNIC:

Scope org /
Scope service-profile flow-service-profile
Scope vnic ethx
enter flow-mon-src flow-monitor-session
commit-buffer

Cisco UCS NetFlow Reporting:

Once you have all the configuration out of the way, you should see NetFlow in your collector.  The below figure is a typical export from a Cisco UCS Netflow export:

Figure 2: Cisco UCS NetFlow Reporting

A couple of notes on this export.  There are no Deep Packet Inspection capabilities so don’t expect NBAR or AVC Support like there is with FNF.  Also, VLAN’s must be defined as an exporter interface before they can be used with a flow collector.  There are some specific limitations based on UCS Fabric and VIC adaptors as well:

NetFlow monitoring is not supported on:
Cisco UCS 6100 Series Fabric Interconnect

NetFlow monitoring is only supported on:
Cisco UCS VIC 1240
Cisco UCS VIC 1280
Cisco UCS VIC 1225
First generation or non-Cisco VIC adapters are not supported.

More on Cisco UCS NetFlow

Exporting NetFlow on your Cisco UCS gives you another vantage point into traffic on the network.   Do you have questions on exporting Cisco UCS NetFlow?

Contact our team to learn more on Cisco UCS and about how exporting NetFlow from every point capable on the network can help security monitoring and the mitigation of threats.

The post Cisco UCS NetFlow Support appeared first on NetFlowKnights.com.

Do you have Cisco ASR1000 or ISR G2 routers?  Are you looking to get advanced NetFlow reporting from these routers, but the complexity of the Cisco Performance Monitoring configuration instructions is a show stopper for you?  Well, that changes with the Cisco EzPM NetFlow configuration by taking a very complicated task and truly making it “Easy Performance Monitoring”!

Many network administrators have been overwhelmed with the plethora of configuration options that can be made with Cisco Performance Monitoring. While it is incredibly flexible, it does require a lot of research just to understand how to configure this feature.

In our research, we’re always striving to help you understand advanced NetFlow configurations, and in this case, we have come across a much simpler method.  In fact, it is so easy, Cisco called it EzPM (Easy Performance Monitoring)!

In just a few configuration lines, you can configure all the cool Application, Visibility and Control (AVC) features on your ASR or ISR G2 routers!  (What originally consisted of several hundred lines of configuration!)

But before you get too excited, we should tell you that you must be running specific versions of code.  Following are the minimum code versions required:

• ASR1K – IOS XE Release 3.10S or newer
• ISR G2 – IOS Release 15.4(1)T or newer

EzPM configuration

Now let’s dive into the meat and potatoes. The following 3 lines of configuration will configure all of the monitoring possible in Performance Monitoring (Phase 2) with the recommended traffic classes.

performance monitor context my-scrutinizer-context profile application-experience

exporter destination x.x.x.x source loopback0 transport udp port 2055

traffic-monitor all

Then apply the profile to your interfaces.

Interface Gi0/0/1

performance monitor context my-scrutinizer-context

You can also look at what the configuration looks like without EzPM by entering the following command:

show performance monitor context my-scrutinizer-context

The ‘show performance monitor context {context-name}‘ command will show all of the configuration for the specified context.

Here is a snippet of what the configuration looks like without EzPM.

Network Performance Monitoring configuration

For a full list of all the configuration statements generated by the EzPM configuration, click on the snippet image above.

Now aren’t you glad Cisco decided to do this!? I sure am!

So let’s move on to what these NetFlow exports can provide for you.

Network Performance Monitoring

What can we get for Cisco AVC reporting?  Probably a lot more than you expected.

• URLS
• Latency
• Retransmits
• Packet size
• TCP window size
• Jitter
• Packet loss
• and more

Here’s an AVC report example combining several of the elements listed above.  This Root Cause Delay report is very useful for isolating network performance problems.

So now you know how to easily configure Cisco AVC NetFlow exports using Cisco EzPM, and the extensive reporting available for AVC, what are you waiting for?

And one last thing – did you know that Cisco AVC reporting is also available for Cisco Wireless LAN Controllers? Read all about it in this blog on Cisco AVC support.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Cisco EzPM NetFlow config: Easy Performance Monitoring appeared first on NetFlowKnights.com.

Talari NetFlow Support has been available since their APN 2.5 release through their current release of APN 4.0 (May 2014).  Recently, a customer I was working with had questions on the Talari device and how well it supported NetFlow.  This peaked my interest as this was the first time seeing Talari NetFlow in the field!  In this blog I will take a look at how you configure the Talari NetFlow export and the differences from other WAN Optimization NetFlow Exports!

Figure 1: Talari Networks Appliances [Source]

First, a little background on Talari before we get started on the NetFlow!  They provide appliances, as seen in Figure 1, that improve WAN connections by both load balancing and providing redundancy controllers.  They also have an interface that allows the monitoring of both the network and application performance on the links they connect.

Talari NetFlow Configuration

The configuration process is available in Talari’s Adaptive Private Networking Appliance Operation Guide for APNware Release 2.5.  The first step for setting up NetFlow, after logging into the Talari Appliance, is to click the “Integrate” tab as shown in Figure 2.

Figure 2: Integrate NetFlow [Source]

Figure 3: Configuring NetFlow Host Settings [Source]

Talari NetFlow Export

When NetFlow is that easy to configure, in my experience and to give it a Cisco twist, it is not very flexible.  In figure 4, you can see a portion of the flow export from the Talari Device.  The column that I wanted to point out is TCP Control Bits.

Figure 4: Data from Talari NetFlow Export

This means they are not following the internet standard for NetFlow exports based on RFC 7011 which has element ID 6 for tcpControlBits (IANA).  Without TCP Flags, calculating round trip time (RTT), latency, jitter, and other performance metrics in the flow data will not be possible.  Vendors like Riverbed, Exinda, Bluecoat, and others are exporting this type of information.  From the security side, without TCP flags, the NetFlow collector cannot determine if there are FIN, ACK/RST, or SYN scans occurring.  With that being said, it doesn’t hurt to have another metering location on the network if it’s available.  Just do not expect to see detailed information that you would see from other NetFlow/IPFIX exporting vendors.

What is next for Talari NetFlow Support?

It is great to see vendors exporting NetFlow, even if it is basic NetFlow v5.  Hopefully in the future they will export IPFIX.  If you were looking for more than the basics in your NetFlow exports, check out both this page on performance metering with NetFlow and this whitepaper on Measuring Latency Using NetFlow.  If you have any questions on setting up your NetFlow exports or the information that is being collected, feel free to comment below or reach out to the Plixer Support Team at 207-324-8805 x4

The post Talari NetFlow Support appeared first on NetFlowKnights.com.

Last week, on a call with a customer, I had the pleasure of learning more about the Cisco 6500 Flexible NetFlow record configuration.    And today I will share that information with you.

Flexible NetFlow was already configured on the Cisco 6500, but the predefined platform-original Flexible NetFlow record was not providing all of the information that they required.  Which led us to creating a custom record.

How do you create a custom flexible NetFlow record?

The first step is to determine what you want for reporting from Flexible NetFlow.  A good NetFlow reporting solution will be able to provide reporting tailored to the flow elements exported.  So you determine what you want to report on, and build your Flexible NetFlow record with the elements required for that reporting.

In our case, our customer wanted QoS reporting and also subnet reporting.  The elements required for this reporting were not available in the platform-original record, so by following the guidelines in the Flexible NetFlow Key and Non-Key Fields section of the Cisco 6500 Sup2T NetFlow documentation, we found the supported elements for this device.

From the list of key and non-key fields, we came up with the following custom flow record.

flow record NetFlow

match ipv4 source address
match ipv4 destination address
match transport tcp source-port
match transport tcp destination-port
match ipv4 protocol
match input interface
match output interface
match ipv4 tos
match flow direction

collect counter bytes
collect counter packets
collect routing source as
collect routing destination as
collect routing next-hop address ipv4
collect transport tcp flags
collect ipv4 source prefix
collect ipv4 destination prefix
collect timestamp sys-uptime first
collect timestamp sys-uptime last

The key fields are defined in the ‘match’ statements and define how each flow is aggregated in the flow cache table.  All packets with the same ‘matching’ attributes are grouped into a flow, then the ‘collect’ statements define what additional information is added to those flow records.

In this example, our key fields include source and destination addresses, source and destination transport ports, protocol, input and output interfaces, type of service, and flow direction.  Then we added counters for both bytes and packets so that we can track network bandwidth utilization.  In addition to Type of Service, which was one of the critical elements for this customer, our collect statements also include the source and destination prefixes, which allow for subnet reporting.  We also added a few additional elements for good measure, as they were available and even if they weren’t on their critical list, they were definitely ‘nice to haves’.  For that list, we added Autonomous System elements, and Next Hop addresses.

End result was that we provided our customer with QoS reporting between two of his key locations.  The reporting example below shows a Grouped Flows (TOS) report, showing source/destination IP Address pairs with Type of Service per flow also.

By using the full power of Flexible NetFlow, we were able to provide our customer with exactly what he was looking for.  For more information and complete steps for the Cisco 6500 Sup2T Flexible NetFlow configuration, please read Paul’s configuring Sup2T NetFlow blog.

If you are interested what else you can do with Flexible NetFlow, I invite you to check out this article on Cisco Application Visibility and Control.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Cisco 6500 Flexible NetFlow Record Configuration appeared first on NetFlowKnights.com.

At the beginning of the year Dale wrote a blog on F5 Networks IPFIX Support. Today, I want to follow up on that post by explaining F5 IPFIX Configuration and configuring IPFIX logging for SIP DoS.

These are the steps required to configure IPFIX logging of SIP DoS events on the BIG-IP system (specifically BIG-IP Advanced Firewall Manager (AFM 11.6.0)). To learn which elements are supported visit the IPFIX Templates for AFM SIP Events article on F5’s website.

A quick note before you begin: Enabling IPFIX logging impacts BIG-IP system performance.

Assembling a pool of IPFIX collectors

Assembling a pool of IPFIX collectors is the first step in the configuraton. Get together the IP address of the collectors that you wish to include in the pool. Additionally, make sure your collectors are configured to listen to, and receive, log messages from the BIG-IP system.

Follow these steps to create a pool of IPFIX colelctors.

1. On the Main tab, click Local Traffic > Pools. The Pool List screen opens.
2. Click Create. The New Pool screen opens.
3. In the Name field, type a unique name for the pool.
4. Using the New Members setting, add the IP address for each IPFIX collector that you want to include in the pool:
   1. Type the collector’s IP address in the Address field, or select a node address from the Node List.
   2. Type a port number in the Service Port field. By default, IPFIX collectors listen on UDP or TCP port 4739 and Netflow V9 devices listen on port 2055, though the port is configurable at each collector.
   3. Click Add.
5. Click Finished.

Creating an IPFIX log destination

A log destination of the IPFIX type specifies that log messages are sent to a pool of IPFIX collectors. Use these steps to create a log destination for IPFIX collectors

1. On the Main tab, click System > Logs > Configuration > Log Destinations. The Log Destinations screen opens.
2. Click Create.
3. In the Name field, type a unique, identifiable name for this destination.
4. From the Type list, select IPFIX.
5. From the Protocol list, select IPFIX or Netflow V9, depending on the type of collectors you have in the pool.
6. From the Pool Name list, select an LTM^® pool of IPFIX collectors.
7. From the Transport Profile list, select TCP, UDP, or any customized profile derived from TCP or UDP.
8. The Template Retransmit Interval is the time between transmissions of IPFIX templates to the pool of collectors. The BIG-IP system only retransmits its templates if the Transport Profile is a UDP profile. An IPFIX template defines the field types and byte lengths of the binary IPFIX log messages. The logging destination sends the template for a given log type (for example, NAT44 logs or customized logs from an iRule) before sending any of those logs, so that the IPFIX collector can read the logs of that type. The logging destination assigns a template ID to each template, and places the template ID into each log that uses that template.The log destination periodically retransmits all of its IPFIX templates over a UDP connection. The retransmissions are helpful for UDP connections, which are lossy.
9. The Template Delete Delay is the time that the BIG-IP device should pause between deleting an obsolete template and re-using its template ID. This feature is helpful for systems that can create custom IPFIX templates with iRules.
10. The Server SSL Profile applies Secure Socket Layer (SSL) or Transport Layer Security (TLS) to TCP connections. You can only choose an SSL profile if the Transport Profile is a TCP profile. Choose an SSL profile that is appropriate for the IPFIX collectors’ SSL/TLS configuration. SSL or TLS requires extra processing and therefore slows the connection, so we only recommend this for sites where the connections to the IPFIX collectors have a potential security risk.
11. Click Finished.

Creating a publisher

A publisher specifies where the BIG-IP^® system sends log messages for IPFIX logs.

1. On the Main tab, click System > Logs > Configuration > Log Publishers. The Log Publishers screen opens.
2. Click Create.
3. In the Name field, type a unique, identifiable name for this publisher.
4. Use the Log Destinations area to select an existing IPFIX destination (perhaps along with other destinations for your logs): click any destination name in the Available list, and click << to move it to the Selected list.
5. Click Finished.

Creating a custom DNS DoS Protection Logging profile

Create a custom Logging profile to log DNS DoS Protection events and send the log messages to a specific location.

1. On the Main tab, click Security > Event Logs > Logging Profiles. The Logging Profiles list screen opens.
2. Click Create. The New Logging Profile screen opens.
3. Select the DoS Protection check box.
4. In the DNS DoS Protection area, from the Publisher list, select the publisher that the BIG-IP system uses to log DNS DoS events. You can specify publishers for other DoS types in the same profile, for example, for SIP or Application DoS Protection.
5. Click Finished.

Assign this custom DNS DoS Protection Logging profile to a virtual server.

That’s it! You’re done!

Let us know if you need further clarification on setting up IPFIX logging for SIP DoS on your BIG-IP AFM; we’re here to help.

Justin
Marketing Manager

The post F5 IPFIX Configuration: IPFIX logging for SIP DoS appeared first on NetFlowKnights.com.

Did you ever consider that using Flexible NetFlow, specifically an NBAR NetFlow configuration, could provide another aspect of network security for you?

Exporting NBAR (Network Based Application Recognition) in Flexible NetFlow records provides the opportunity for deep packet inspection visibility in NetFlow reporting.  Once you have that visibility, you’re just a half step away from also using that information for detecting unwanted traffic on your network.

It may be malicious traffic, or it may be someone abusing your network resources, such as watching Youtube videos or NetFlix during the business day, consuming valuable bandwidth.

So how do you get this application information in NetFlow, you ask?  Well, read on, and I’ll tell you how.

There are 4 basic steps:

1. Create the Flexible NetFlow record
2. Create an Exporter
3. Create a Monitor
4. Apply the Monitor

In this sample NBAR NetFlow configuration, we first define the flow record.  The ‘match’ statements are your key fields and define the tuple.  The ‘collect’ statements are used to add whatever other information you want in the record.  So you ‘match’ statements are the elements that are ‘matched’ to define a conversation, and the ‘collect’ statements are for the additional data you want to ‘collect’.

How nice of Cisco to make that logical for us.

!define flow record
flow record NetFlow
match ipv4 source address
match ipv4 destination address
match transport tcp source-port
match transport tcp destination-port
match ipv4 protocol
match input interface
match ipv4 tos
match flow direction

collect output interface
collect counter bytes long
collect counter packets long
collect routing source as
collect routing destination as
collect routing next-hop address ipv4
collect transport tcp flags
collect ipv4 dscp
collect ipv4 ttl
collect ipv4 source prefix
collect ipv4 destination prefix
collect transport round-trip-time
collect transport event packet-loss counter
collect timestamp sys-uptime first
collect timestamp sys-uptime last
collect application name

** Please note that  match input interface and collect output interface may have different syntax in your IOS version, for example:

match interface input
collect interface output

Next we are on to defining the exporter.  This is where we say where we will send the flows to, using what transport port, and what the source interface will be (the door that the flows are sent out through).  There are also timeout settings and option templates that can be included in the exporter definition.

!define exporter
flow exporter Export-to-Scrutinizer
destination x.x.x.x !Scrutinizer’s ip address
source XXXXXXX !interface name
transport udp 2055
template data timeout 60
option interface-table
option application-table

The monitor brings all of this together, what exporter definition you will use, and what flow record to export, and the active timeout setting – very critical!

!create monitor
flow monitor Scrutinizer-monitor
record NetFlow
exporter Export-to-Scrutinizer
cache timeout active 60

Last step is to apply the monitor to each interface that you want to monitor flow data for.  Applying as an input AND an output configures for both ingress and egress metering.

!Apply ingress/egress monitors to an interface
interface XXXXXX !interface name
ip flow monitor Scrutinizer-monitor input
ip flow monitor Scrutinizer-monitor output

That’s it!  That completes the basic Flexible NetFlow NBAR configuration.

So what do you get with NBAR reporting?  Here’s an example report showing a summary of applications traffic by name and their respective traffic volumes.  This could be taken a step further by clicking on an application, such as youtube, and displaying what host IP Address was generating the youtube traffic.

With this application level reporting, you’ve got a good start towards isolating unnecessary or unwanted network traffic from the legitimate traffic, and also potentially malicious or illegal – such as bittorrent traffic.

If you’re interested in reading more on this subject, then check out this Network Security Solutions article.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Flexible NetFlow: NBAR NetFlow configuration appeared first on NetFlowKnights.com.

We’ve been discussing Cisco AVC NetFlow reporting a lot lately, but what if you’re not yet at the latest Cisco IOS revisions?  If you have IOS 15.1(3), but not 15.1(4), no worries, Cisco Performance Monitoring NetFlow reporting can still provide some valuable performance metrics reporting for you.

The minimum revision requirement for performance monitor phase 1 is Cisco IOS version 15.1(3)T.  Phase 1 provides data for reporting on jitter, packet loss, round trip times, NBAR reporting, and more.

Here’s an example of the rich NetFlow reporting available with Performance Monitor Phase 1.

Not only do you get some really great network performance reporting, but you can also get basic flow accounting information for your NetFlow reporting (bandwidth monitoring, conversations, top talkers, etc.).  I came upon this while working with a prospective customer, Lee, helping him with his router’s NetFlow configurations.

Performance Monitoring NetFlow configuration

So without further ado, let’s jump into the Flexible NetFlow configuration required for that advanced reporting.

We started with the NetFlow configuration example given in the Cisco Performance Reporting on your Medianet blog and expanded on it to include the basic flow accounting information that Lee required.

By adding an additional flow record, and with a little tweaking here and there, Lee was then able to meet his own requirements and very graciously shared his configuration with us.

I’ve included the full Performance Monitoring NetFlow configuration below, with Lee’s additions for basic Flow Accounting in red.

ip cef
!
flow record type performance-monitor TCP
match ipv4 protocol
match ipv4 source address
match ipv4 source prefix
match ipv4 destination address
match ipv4 destination prefix
match transport source-port
match transport destination-port
collect routing forwarding-status
collect ipv4 dscp
collect ipv4 ttl
collect ipv4 source mask
collect ipv4 destination mask
collect transport round-trip-time
collect transport event packet-loss counter
collect interface input
collect interface output
collect counter bytes
collect counter packets
collect counter bytes rate
collect timestamp interval
collect application media bytes counter
collect application media packets rate
collect application media event
collect monitor event
!
!
flow record type performance-monitor RTP
match ipv4 protocol
match ipv4 source address
match ipv4 source prefix
match ipv4 destination address
match ipv4 destination prefix
match transport source-port
match transport destination-port
match transport rtp ssrc
collect routing forwarding-status
collect ipv4 dscp
collect ipv4 ttl
collect ipv4 source mask
collect ipv4 destination mask
collect transport packets expected counter
collect transport packets lost counter
collect transport packets lost rate
collect transport event packet-loss counter
collect transport rtp jitter mean
collect transport rtp jitter minimum
collect transport rtp jitter maximum
collect interface input
collect interface output
collect counter bytes
collect counter packets
collect counter bytes rate
collect timestamp interval
collect application media bytes counter
collect application media bytes rate
collect application media packets counter
collect application media packets rate
collect application media event
collect monitor event
!
!
flow record FNF
 match ipv4 tos
 match ipv4 protocol
 match ipv4 source address
 match ipv4 destination address
 match transport tcp source-port
 match transport tcp destination-port
 match interface input
 match interface output
 match flow direction
 collect routing source as
 collect routing destination as
 collect routing next-hop address ipv4
 collect ipv4 source prefix
 collect ipv4 destination prefix
 collect transport tcp flags
 collect counter bytes
 collect counter packets
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
!
!
flow exporter SCRUTINIZER
description FLEXIBLE NF V9
destination [ Scrutinizer's IP]
source [Interface]
transport udp 2055
template data timeout 60
option interface-table
option exporter-stats
option application-table
!
!
flow monitor type performance-monitor RTP
description RTP stats
record RTP
exporter SCRUTINIZER
!
!
flow monitor type performance-monitor TCP
description TCP stats
record TCP
exporter SCRUTINIZER
!
!
flow monitor FNF
 exporter SCRUTINIZER
 cache timeout active 60
 record FNF
!
class-map match-any TCP-class
match access-group 100
!
class-map match-any realtime
match protocol rtp audio
match protocol rtp video
match protocol cisco-phone
!
policy-map type performance-monitor RTPMON
class realtime
flow monitor RTP
monitor parameters
interval duration 10
flows 100
class TCP-class
flow monitor TCP
monitor parameters
flows 1000
!
access-list 100 permit tcp any any
!

!Interface configuration

ip flow monitor FNF input
ip flow monitor FNF output
service-policy type performance-monitor input RTPMON
service-policy type performance-monitor output RTPMON

If you’d like to discuss this further, please contact us directly at 207-324-8805 x3 and we can show you how to get the most out of Cisco Performance NetFlow reporting.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Cisco Performance Monitoring NetFlow config appeared first on NetFlowKnights.com.

The Cisco Catalyst 2960-CX/3560-CX Series Switches are the next generation of the world’s most widely deployed access switches, providing Layer 2 and Layer 3 access features. Designed for operational simplicity to lower TCO, this platform also offers superior security capabilities. Also, the Cisco Catalyst Compact Switches easily extend your Catalyst switching infrastructure outside the wiring closet to enable new workspaces, extend wireless LANs, and connect PoE devices. These fanless, small form-factor switches are ideal for space-constrained deployments where multiple cables runs would be challenging. Today, I am going to explain how to configure NetFlow on the Catalyst 2960-CX/3560-CX.

Enabling NetFlow Lite on the Catalyst 2960-CX/3560-CX

Step 1: Create a flow record

flow record flow-mon
match datalink ethertype
match datalink mac source address input
match datalink mac destination address input
match ipv4 tos
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
collect transport tcp flags
collect interface input
collect interface output
collect flow sampler
collect counter bytes long
collect counter packets long
collect timestamp sys-uptime first
collect timestamp sys-uptime last
!
!

Step 2: Create a flow exported

flow exporter export-to-inside
description flexible NF
destination 10.1.4.66
source Vlan1
transport udp 2002
template data timeout 60
option interface-table
option exporter-stats
option sampler-table timeout 60
option application-table
!
!

Step 3: Create a flow monitor

flow monitor myflowmon
exporter export-to-inside
cache timeout active 60
statistics packet protocol
record flow-mon
!
!

Step 4: Apply the flow monitor to each interface

! we are using random sampling because it is the most statistically accurate of the two.
sampler my-random-sampler
  mode random 1 out-of 100

interface GigabitEthernet0/1
  ip flow monitor myflowmon sampler my-random-sampler input
interface GigabitEthernet0/7
  ip flow monitor myflowmon sampler my-random-sampler input

Enabling NetFlow on the Catalyst 2960-CX/3560-CX for Performance Monitoring

Step 1: Create a flow record for performance monitoring

flow record type performance-monitor TCP
match ipv4 protocol
match ipv4 source address
match ipv4 source prefix
match ipv4 destination address
match ipv4 destination prefix
match transport source-port
match transport destination-port
match interface input
match interface output
match flow direction
collect routing forwarding-status
collect ipv4 dscp
collect ipv4 ttl
collect ipv4 source mask
collect ipv4 destination mask
collect transport round-trip-time
collect transport event packet-loss counter
collect transport tcp flags
collect counter bytes
collect counter packets
collect timestamp sys-uptime first
collect timestamp sys-uptime last
collect timestamp interval
collect application media bytes counter
collect application media packets rate
collect application media event
collect policy performance-monitor classification hierarchy
!
!
flow record type performance-monitor RTP
match ipv4 protocolmatch ipv4 source address
match ipv4 prefix
match ipv4 destination address
match ipv4 destination prefix
match transport source-port
match transport destination-port
match transport rtp ssrc
match interface input
match interface output
match flow direction
collect routing forwarding-status
collect ipv4 dscp
collect ipv4 ttl
collect ipv4 source mask
collect ipv4 destination mask
collect transport packets expected counter
collect transport packets lost counter
collect transport packets lost rate
collect transport event packet-loss counter
collect transport rtp jitter mean
collect transport rtp jitter minimum
collect transport rtp jitter maximum
collect counter bytes
collect counter packets
collect timestamp sys-uptime first
collect timestamp sys-uptime last
collect timestamp interval
collect application media bytes counter
collect application media bytes rate
collect application media packets counter
collect application media packets rate
collect application media event
!
!

Step 2: Create a flow exporter

flow exporter export-to-inside
description flexible NF
destination 10.1.4.66
source Vlan1
transport udp 2002
template data timeout 60
option interface-table
option exporter-stats
option sampler-table timeout 60
option application-table
!
!

Step 3: Create Performance Monitoring flow monitor

flow monitor type performance-monitor TCP
destination TCP stats
record TCP
exporter export-to-inside
cache entries 10000
cache timeout synchronized 60
!
!
flow monitor type performance-monitor RTP
description RTP stats
record RTP
export-to-inside
cache entries 10000
cache timeout synchronized 60
!
!
flow monitor myflowmon
exporter export-to-inside
cache timeout active 60
statistics packet protocol
record flow-mon
!
!

Step 4: Create a policy map that defines what monitors will be monitoring different types of traffic

policy-map type performance-monitor RTPMON
 description RTP stats
 class realtime
 flow monitor RTP
  monitor metric rtp
  min-sequential 10
  max-dropout 10
  max-reorder 10
  ssrc maximum 10
  monitor metric ip-cbr
  rate layer3 packet 500
 class tcpclass
  flow monitor TCP

Step 5: Add Service Policy to interfaces where performance monitors are desired

interface GigabitEthernet0/1
 service-policy type performance-monitor input RTPMON

interface GigabitEthernet0/7
 service-policy type performance-monitor input RTPMON

If you have any questions getting NetFlow running, reach out to our support team.

Justin
Marketing Manager

The post Cisco Catalyst 2960-CX/3560-CX NetFlow Configuration appeared first on NetFlowKnights.com.

Recently, I discovered that the HP 6600 Router Series has support for NetFlow. If you search for HP 6600 NetFlow Support, though, you don’t find much. This is because HP’s version of NetFlow is called NetStream (likely from their acquisition of 3Com). I first learned about this when I browsed HP’s website to see if they offered NetFlow/IPFIX support. After much searching, I found what I was looking for. Today, I want to help you configure your HP 6600 Routers to send flow data to your collector.

A colleague of mine contacted HP to see what information they had on the HP 6600 Router Series. Unfortunately, much to my surprise, they did not have any documentation regarding ‘IPFIX’. After scouring the interwebs to find something on how to configure the device, I discovered that, though there are a number of models in the 6600 series, many of them use the same configuration.

HP 6600 NetFlow Support Configuration

To configure the HP 6600 Router Series to send NetFlow (NetStream) to your collector, you need to enter system view and issue a number of commands.

In this example, see Figure 1, we will configure NetStream on Router A: enable NetStream for incoming traffic on GigabitEthernet 2/0/0 and for outgoing traffic on GigabitEthernet 2/0/1, and configure the router to export NetStream traditional data to UDP port 2055 of the NetStream server at 12.110.2.2/16.

A quick note: NetStream exports data in UDP datagrams in one of the following formats:

• Version 5—Exports original statistics collected based on the 7-tuple elements. The packet format is fixed and cannot be extended flexibly.
• Version 8—Supports NetStream aggregation data export. The packet formats are fixed and cannot be extended flexibly.
• Version 9—The most flexible format. Users can define templates that have different statistics fields. The template feature supports different statistics, such as BGP next hop and MPLS information.

We will be using the Version 5 export in this example.

Figure 1

Enable NetStream for incoming traffic on GigabitEthernet 2/0/0.

<RouterA> system-view
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 11.110.2.1 255.255.0.0
[RouterA-GigabitEthernet2/0/0] ip netstream inbound
[RouterA-GigabitEthernet2/0/0] quit

Enable NetStream for outgoing traffic on GigabitEthernet 2/0/1.

[RouterA] interface gigabitethernet 2/0/1
[RouterA-GigabitEthernet2/0/1] ip address 12.110.2.1 255.255.0.0
[RouterA-GigabitEthernet2/0/1] ip netstream outbound
[RouterA-GigabitEthernet2/0/1] quit

Configure the destination address and the destination UDP port number for the NetStream traditional data export.

[RouterA] ip netstream export host 12.110.2.2 2055

Configure Flow Aging

Because the default aging time for active and inactive flows is higher than we recommend (1800 and 30 seconds respectively), we need to set them manually. To do this issue the following commands.

<RouterA> system-view
[RouterA] ip netstream aging
[RouterA] ip netstream timeout active 60
[RouterA] ip netstream timeout inactive 15
[RouterA] quit

If you have any questions on how to configure this device please reach out to our support team or review the “HP 6600/HSR6600 Routers Network Management and Monitoring Configuration Guide“.

Justin
Marketing Manager

The post HP 6600 NetFlow Support appeared first on NetFlowKnights.com.

We have received numerous requests for assistance with the Cisco Catalyst 3850 NetFlow configuration recently, and in researching this particular configuration, uncovered a licensing requirement.  One of the customers that we worked with had the LAN base license level.  NetFlow exports are not supported for that licensing level, rather, an IP base license level is included in the  Cisco 3850 NetFlow requirements.

Once that requirement is met, we can then move on to configuring Flexible NetFlow.

As with any Flexible NetFlow configuration, there are 4 main steps:

1. Define the Flow Record – defines which fields are exported
2. Define the Flow Exporter – defines where flows are exported to
3. Define the Flow Monitor – joins the Flow Record(s) and Flow Exporter(s) together
4. Apply the Flow Monitor to the interface(s)

Here is a sample 3850 NetFlow configuration.  Note that there are 2 flow record definitions and 2 flow monitor definitions.  That is because only one flow monitor per interface and per direction is supported.  (Another Flexible NetFlow restriction for the Catalyst 3850).  So there is one record definition for ingress flows another one for egress, and also two flow monitors, one each for ingress and egress flows.

***********************************************************************************

flow record FNF-input

description IPv4 NetFlow
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match ipv4 protocol
match interface input
match ipv4 tos
match datalink mac output
match flow direction

collect interface output
collect counter bytes
collect counter packets
collect transport tcp flags
collect timestamp absolute first
collect timestamp absolute last

flow record FNF-output

description IPv4 NetFlow
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match ipv4 protocol
match interface output
match ipv4 tos
match datalink mac output
match flow direction

collect interface input
collect counter bytes
collect counter packets
collect transport tcp flags
collect timestamp absolute first
collect timestamp absolute last

flow exporter Scrutinizer

description Export to Scrutinizer
destination 10.1.1.10
source gigabitEthernet1/0/1
transport udp 2055

flow monitor Scrut_mon_input

description IPv4 FNF ingress exports
exporter Scrutinizer
record FNF_input
cache timeout active 60

flow monitor Scrut_mon_output

description IPv4 FNF egress exports
exporter Scrutinizer
record FNF_output
cache timeout active 60

Applying the flow monitor(s) to interface(s).  This last step is repeated for all interfaces that are to be monitored.

interface GigabitEthernet1/0/1
ip flow monitor Scrut_mon_input input
ip flow monitor Scrut_mon_output output

To verify that the correct information was entered for each of the Flexible NetFlow configuration steps, the following commands can be run on the Catalyst 3850.

show flow record [record-name]
example: show flow record FNF

show flow exporter [exporter-name]
example: show flow exporter Scrutinizer

show flow monitor [monitor-name]
example: show flow monitor FNF_Scrutinizer

show flow interface [interface-type number]
example: show flow interface GigabitEthernet1/0/1

***********************************************************************************

Now that you have Flexible NetFlow configured, what benefits are available to you with Cisco 3850 NetFlow support?

Well, by combining the Flexible NetFlow exporting capabilities of the 3850 with a powerful advanced flow reporting and analyzing solution, reporting such as displayed in the example below is just one of the possibilities.

This particular flow report gives a translation table of MAC addresses and IP Addresses for host to host conversations.  Other standard flow reports such as Conversations, Top Source/Destination Hosts, Top Countries, etc., are also available.  Also, any advanced flow analyzing, providing additional network security, can also be applied to the flow data received from the 3850 NetFlow exports.

The Cisco Catalyst 3850 Flexible NetFlow exports open the door to some amazing flow reporting. If you need any additional help with getting this set up, please let us know.

For a free 30 day trial of Scrutinizer, Download Now!

Sign up for Advanced NetFlow Training™ coming to a city near you!

The post Cisco Catalyst 3850 NetFlow configuration appeared first on NetFlowKnights.com.

In order to configure Cisco ISE NetFlow, we’re going to take advantage of Scrutinizer’s API (Application Program Interface) by enabling ERS (External RESTful Services), on the ISE appliance.

You probably already know about Cisco ISE (Identity Service Engine) profiling using the NetFlow Probe. However, the ISE appliance can be integrated into your Network Response System, in order to give you contextual details into who is generating traffic on your network.

I recommend enabling ERS and creating a new user with at least read credentials for this.

Here is the guide for enabling ERS for ISE 1.4, ISE 1.3 and ISE 1.2.

To test your configuration outside of Scrutinizer, use POSTMAN to do a GET, using this URL:

https://[ISE_SERVER]/ise/mnt/Session/AuthList/null/null

*tip: when using postman, first navigate to the server with your browser, tell chrome it is OK to use a bad certificate and leave that window open.

Next step, is to add the user you just created in Scrutinizer, via command line:

# ./plixer/scrutinizer/bin/scrut_util.exe -ciscoisenode add --host  --port  --user  --pwd

That’s it. For all your hard work, Scrutinizer will poll the ISE appliance every 5 minutes to get updated username information. By going to Status>Views>Cisco ISE, you will see a list of users with details like username, IP address, MAC address, access time and more:

Cisco ISE fields

Similarly, you can search the entire database for username, host, domain name, or MAC address:

Cisco ISE search

If you’re already investigating a report, you can click on a host and select the Cisco ISE option from the “Other” menu to quickly figure out what user is responsible for this traffic. Let’s see what applications Maciej is using:

Cisco ISE user applications

Available on your Scrutinizer appliance, virtual and/or hardware.

If you have any questions, need help with your Cisco ISE NetFlow configuration, or would like to add username reporting to your incident response system, please contact Plixer.

The post Configure Cisco ISE NetFlow appeared first on NetFlowKnights.com.

Juniper MX5 NetFlow Configuration

Recently while looking at my router’s NetFlow reporting, I came across an issue regarding the Juniper MX5 router’s NetFlow configuration. I had a customer recently with two Juniper MX5 routers; both running the same configuration, but one had newer firmware, Junos version 14.2R2.8. We found was both devices were actively exporting flows to the analyzer, but only one device was able to pull reports. When we tried running a report in our IPFIX and NetFlow Analyzer we were prompted with the ‘Select Template’ message, even though we had already received option templates and they were readily available. Juniper’s site offers additional details about configuring for your Juniper router.

Investigating Further:

When trouble shooting flow data, I start by taking a packet capture in order to provide additional contextual details as to what might be going on. Using a tool like Wireshark, I can collect each packet, allowing me to perform a Deep Packet Inspection (DPI). DPI not only gives me access to the elements being exported to my IPFIX and NetFlow Analyzer, but also will show me the non key fields not being exported as flow data. After taking a packet capture and investigating the situation, I found that both devices were exporting flows as well as option templates. The router with newer firmware, however, was exporting an additional element: flow direction. Normally, exporting direction details won’t cause an issue, but the packet capture showed the field as being exported as ‘Direction: Unknown (255)’. As you can see in the image below, we are exporting the expected fields such as source/destination IP, port, protocol, inbound interface, source port, destination port and octetDelta count. You’ll also see another element, ‘Direction’. This element is not exported from the other on-site MX5 running the older firmware.

Now that I knew where the issue lied, I was able to go back into our IPFIX and NetFlow Analyzer and look at a Flow View report to verify the flow direction element was the true problem. Right away I confirmed what we saw in the packet capture. In the image below you’ll see the flowDirection element reporting as NIT, or Not In Template:

The Workaround:

To report on the flows being received from this device we have to ignore this field. This is a temporary fix, however,  and the better long-term solution would be to convert this field into the default value.

According to RFC5102 the default values for the element flowDirection will be 0x00: ingress flow and 0x01: egress flow. If a value other than 0x00 or 0x01 is exported, we should replace it with the default ingress value of 0x00. Applying this change makes the flow reports available in our IPFIX and NetFlow Analyzer again. Once this workaround has been applied, you can verify the change has been committed by running a ‘Flow View’ report which will give us an output like this:

You’ll notice the element ‘flowDirection’ is now converted to ingress, allowing us to report on this device’s exports accurately.

If you have any questions regarding your Juniper Device configuration, don’t hesitate to reach out to us in Tech Support.

Or for a free 30 day trial of Scrutinizer, Download now!

Jeff Morrison

Jeff Morrison

For a free 30 day trial of Scrutinizer, Download Now!

The post Juniper MX NetFlow Configuration appeared first on NetFlowKnights.com.