2) Specify a collector:
add appflow collector <name> -IPAddress <ipaddress> -port <port_number> -netprofile <netprofile_name>
show appflow collector <name>
Example
> add appflow collector col1 -IPaddress 10.102.29.251 -port 8000 -netprofile n2
Now it's time to configure an AppFlow Action which is a set collectors, to which the flow records are sent if the associated AppFlow policy matches.
3) Configure an AppFlow action:
add appflow action <name> --collectors <string> ... [-comment <string>]
show appflow action
Example
> add appflow action apfl-act-collector-1-and-3 -collectors collector-1 collecter-3
Now it's time to configure an AppFlow Policy that is based on a rule, which consists of one or more expressions.
Note: For creating and managing AppFlow policies, the configuration utility provides assistance that is not available at the command line interface.
4) To configure an AppFlow policy:
add appflow policy <name> <expression> <action>
show appflow policy <name>
Example
> add appflow policy apfl-pol-tcp-dsprt client.TCP.DSTPORT.EQ(22) apfl-act-collector-1-and-3
Now it's time to Bind an AppFlow Policy. To put a policy into effect, you must bind it either globally, so that it applies to all traffic that flows through the NetScaler, or to a specific virtual server, so that the policy applies only to the traffic related to that virtual server.
When you bind a policy, you assign it a priority. The priority determines the order in which the policies you define are evaluated. You can set the priority to any positive integer.
In the NetScaler operating system, policy priorities work in reverse order—the higher the number, the lower the priority. For example, if you have three policies with priorities of 10, 100, and 1000, the policy assigned a priority of 10 is performed first.
You can leave yourself plenty of room to add other policies in any order, and still set them to evaluate in the order you want, by setting priorities with intervals of 50 or 100 between each policy when you globally bind it. You can then add additional policies at any time without having to change the priority of an existing policy.
5a) To globally bind an AppFlow policy:
bind appflow global <policyName> <priority> [<gotoPriorityExpression [-type <type>] [-invoke (<labelType> <labelName>)]
show appflow global
Example
> bind appflow global af_policy_lb1_10.102.71.190 1 NEXT -type REQ_OVERRIDE -invoke vserver google
5b) To bind an AppFlow policy to a specific virtual server:
bind lb vserver <name> -policyname <policy_name> -priority <priority>
Example
> bind lb vserver google -policyname af_policy_google_10.102.19.179 -priority 251
If you decide to go the virtual server route, you now need to enable AppFlow for the Virtual Servers. If you want to monitor only the traffic through certain virtual servers, enable AppFlow specifically for those virtual servers. You can enable AppFlow for load balancing, content switching, cache redirection, SSL VPN, GSLB, and authentication virtual servers.
6) To enable AppFlow for a virtual server:
set cs vserver <name> <protocol> <IPAddress> <port> -appflowLog ENABLED
Example
> set cs vserver Vserver-CS-1 HTTP 10.102.29.161 80 -appflowLog ENABLED
Now it's time to enabling AppFlow for a Service
7) Enable AppFlow for services that are to be bound to the load balancing virtual servers:
set service <name> -appflowLog ENABLED
Example
> set service ser -appflowLog ENABLED
Getting closer! Now we need to set the AppFlow parameters to customize the exporting of data to the IPFIX collector.
set appflow param [-templateRefresh <secs>] [-appnameRefresh <secs>] [-flowRecordInterval <secs>] [-udpPmtu <positive_integer>] [-httpUrl ( ENABLED | DISABLED )] [-httpCookie ( ENABLED | DISABLED )] [-httpReferer ( ENABLED | DISABLED )] [-httpMethod ( ENABLED | DISABLED )] [-httpHost ( ENABLED | DISABLED )] [-httpUserAgent ( ENABLED | DISABLED )] [-httpXForwardedFor ( ENABLED | DISABLED )][-clientTrafficOnly ( YES | NO)]
show appflow Param
Example
> set appflow Param -templateRefresh 240 -udpPmtu 128 -httpUrl enabled
8) Now you can configuring AppFlow for DataStream
> enable feature appflow
> add db user sa password freebsd
> add lbvserver lb0 MSSQL 10.102.147.97 1433 -appflowLog ENABLED
> add service sv0 10.103.24.132 MSSQL 1433 -appflowLog ENABLED
> bind lbvserver lb0 sv0
> add appflow collector col0 -IPAddress 10.102.147.90
> add appflow action act0 -collectors col0
> add appflow policy pol0 "mssql.req.query.text.contains(\"select\")" act0
> bind lbvserver lb0 -policyName pol0 -priority 10
When the Netscaler appliance receives a database request, the appliance evaluates the request against a configured policy. If a match is found, the details are sent to the AppFlow collector configured in the policy.
Here’s another link on the Citix web site for configuring AppFlow. BTW: our Network Incident Response system has extensive NetScaler Appflow support. Below is an example of the reporting available:
9) If you want more!
The EdgeSight Monitoring application provides web page monitoring data. You can monitor the performance of various Web applications served in a Netscaler environment. This data can be exported to AppFlow collectors and provides you with an in-depth analysis of the web page applications. Our AppFlow reporting solution supports this as well.
With VoIP, BitTorrent, Skype, iCloud and the like now on the network, administrators are dealing with even more flows. On the NetFlow and IPFIX reporting side of things, vendors often find that 2-3 issues come into play when scaling NetFlow tools:
High speed NetFlow collection can lead to very large database tables. Large tables, if not indexed or queried correctly can lead to poor performance in traffic analysis reporting. As a consumer, how a vendor deals with enormous amounts of flow data can and should be part of the vendor selection process.
High NetFlow volumes does not necessarily mean you have to use multiple distributed NetFlow collectors. Many NetFlow and IPFIX collectors can handle tens of thousands or even over one hundred thousand flows per second with a single appliance (e.g. Scrutinizer). Distributed NetFlow collection should be configured when sending all of the flows over a wide area link doesn’t make sense. Enterprise NetFlow analysis requires a careful understanding of the IT managers goal, the budget constraints and the potential bottle neck areas on the network.
Work with your vendor to determine if a single flow collector or if distributed NetFlow collection is in your companies best interest. Beware of the necessary add-on modules and remember to ask about the yearly maintenance cost.
Join NetFlow Developments on Linkedin.
]]>