It’s much much cheaper to conserve bandwidth than it is to buy more. The goal of FlowView is to help you identify the kinds of traffic on your network so that when PathView tells you that you have low available capacity, or AppView tells you that application performance is poor, you know whether high network usage is the culprit. For example, FlowView can help you discover that traffic volume for ‘streaming media’ is high; that it’s consuming X Mbps of bandwidth at 1:30pm every day, the same time that other performance indicators are tanking; that 192.168.0.10 is generating that traffic, and—if you’re set up for it—who was logged onto that machine at the time.

Deploy FlowView

What you see in FlowView is the result of traffic monitoring. Setting up FlowView involves positioning the appliance so that it has access to the traffic passing through your network. When you start FlowView, the appliance starts generating flow records in real time. FlowView collates those records into groups and classes so that you can easily understand how your network resources are being consumed.

Address the prerequisites

Every AppNeta module has specific port and protocol requirements. Your appliance may have been set up with one of the other modules in mind, double-check that your firewall rules have been adjusted for FlowView.

Adjust your firewall rules for FlowView…

Choose an install location

Before you can use FlowView, you have to decide what point in your network you are going to monitor. FlowView is designed to analyze everything going in and out of your network, so it’s best to monitor some point where traffic is aggregated. In addition, the aggregation point that you choose should be before any address translation so that private IPs are viewable. With this in mind, here are a few options: you can monitor a trunk port on an access or aggregation switch, or you can monitor a router gateway. Once you’ve decided what you want to monitor, you’ll need decide how you’ll access the traffic of interest. This is done either by mirroring the traffic to the appliance, or allowing the traffic to physically pass through it. Either way, consider that if the appliance was deployed for PathView or AppView, it’s current position in your network may not be optimal for FlowView.

Add a second interface

Based on the previous step, you might have decided you want to monitor multiple points in your network. If you have appliance model r40 or higher, those models support a second capture interface. One interface is configured by default, eth5.

Add a physical interface now…

Connect the appliance

You have to connect the appliance to the point you want to monitor using one of two methods. One method, out-of-band, involves configuring port mirroring in your network, where the appliance will be connected to the mirroring destination port. The other method, inline, involves using the appliance’s fail-to-wire bypass to connect the appliance inline with the aggregation point.

Inline setup

This method does not use port mirroring; instead it requires placing the appliance between the aggregation point you want to monitor and the downstream section of your network. The appliance should already be connected to AppNeta, meaning one port is already connected to an access switch. Then add the additional connections shown for your appliance model. The following models support inline setup:

m25 inline
m30 inline
m35 inline
r40 inline
r45 inline
r400 1G inline

Out-of-band setup

This method requires you to configure port mirroring, where the source mirroring port is the aggregation point you want to monitor. Once that’s done, add the additional connections shown for your appliance model:

m22 out-of-band
m25 out-of-band
m30 out-of-band
m35 out-of-band
r40 out-of-band
r45 out-of-band
r400 1G oob
r400 10G oob

Assign a FlowView license

The appliance must must have a FlowView license. If you’re capturing on multiple interfaces, one license is required for each interface on which you intend to capture. See assign an appliance license, you’ll need to have org admin or advanced level privileges.

Set the appliance location

The AppNeta service is all about monitoring from the perspective of your end users, and so appliance location provides essential context for the data you’re collecting. In fact, you should stop thinking about your appliances as network devices and start thinking about them only as locations!

Set the appliance location now…

Declare local subnets

If you want FlowView to be able to distinguish between inbound and outbound traffic, you need to tell it which subnets are local to the appliance. Configuring traffic direction has the added benefit of preserving IP-to-hostname resolution for local subnets.

  1. Navigate to FlowView > appliances, and click ‘configure’ next to any appliance.
  2. Select ‘traffic direction’ from the drop down.
  3. Enter a network address and subnet mask; click ‘+’ for each additional subnet.
  4. Click ‘apply’ before navigating to another configuration option, e.g., traffic direction.

Traffic direction and hostname resolution

By default hostnames are resolved every time a FlowView page is loaded, whether or not the scrubbed time range is in the past. Configuring traffic direction ensures that ip addresses in local subnets are resolved at the time flow records are generated, and that that information preserved for the duration of FlowView history; addresses in external subnets will continue to be resolved in real-time.

Traffic direction and top hosts

When traffic direction is configured and host filters are applied, it’s common to misunderstand ‘outbound’ to mean ‘flows destined for remote targets’ and ‘inbound’ to mean ‘flows destined for the filtered host’. This leads to confusion when a filtered host is itself among the hosts generating ‘outbound’ flows. How can a host be generating outbound flows to itself?

Throughout FlowView, ‘inbound’ and ‘outbound’ are always with respect to the local subnets defined in the traffic direction configuration. When host filtering is applied, like on the ‘top hosts’ tab, all of the flows in which the filtered host is present are included, keeping in mind that a flow is defined by an n-tuple that includes both the source and destination. In which section flows are counted depends on whether the source or destination is local. Given this, we expect the filtered host to be at the top of the ‘outbound’ direction.

Set up FlowView alerts

FlowView can alert you based on the results of flow record analysis. Describe when FlowView should trigger alerts in terms of flow characteristics—e.g., rate, volume, ip address—and corresponding thresholds. A flow crossing the threshold in the increasing direction is a violate event; a flow crossing the threshold in the decreasing direction is a clear event. Whenever events occur, FlowView generates logs, annotates charts, highlights relevant table entries, and can notify you by email. Flow alerting doesn’t trigger notification by snmp.

Flow alert profiles are a collection of conditions; each condition has a flow characteristic—e.g., qos, application, category—and a corresponding threshold. A flow crossing the threshold in the increasing direction is a violate event; a flow crossing the threshold in the decreasing direction is a clear event. There are no system-defined profiles; you can make one from > manage alerts, but there is an easier way to make them within FlowView itself:

  1. Start FlowView on an appliance and then navigate to its FlowView appliance details page.
  2. Click on any link to open any tab.
  3. From the action menu of any table row, select create new alert profile.
  4. Add the proposed condition and/or your own.
  5. Apply the alert profile to the appliance from the appliance panel.

A flow crossing the threshold in the increasing direction is a violate event; a flow crossing the threshold in the decreasing direction is a clear event. Whenever events occur, FlowView generates logs, annotates charts, and highlights relevant table entries.

  • Events are marked on the time axis of every chart: a red diamond indicates a condition violated; a green diamond indicates the condition cleared.
  • Events are highlighted. Whenever results are filtered using a time range, and an event occurred in that range, relevant table rows are highlighted in red.
  • Events are logged. Navigate to FlowView > events to display all events for all appliances.
  • Events trigger notifications based on your notification profile.

Status icons in the appliance panel tell you at a glance whether an alert condition is currently in violation: is for no violation, is for violation. Whenever the currently applied profile is changed, the Appliance panel temporarily shows for indeterminate.

Pending release: PagerDuty is a popular tool used by teams to centrally manage alerts from multiple services and systems. You can optionally integrate AppNeta with PagerDuty so that our alerts can also be managed from there. See > manage PagerDuty integration, which will guide you through integration.

Update your notification profile

Event notices are emails about changes in appliance availability and network utilization. The set of rules which determine when notices are generated and sent are called profiles. There is a default profile which applies to all paths, but you can add exceptions to it by creating additional profiles. Within a profile you can specify the organization, paths, and events that trigger notices; the addresses to which notices are sent; and the frequency of notices.

  1. Navigate to > update notification options.
  2. ‘Default email addresses’—applies to all profiles that don’t have their own address list. Click the email address link to edit the default list.
  3. ‘Enable service bulletins’—we occasionally need to send service related emails. Emails are sent to the default addresses specified in your account settings. Make sure this is checked.
  4. For profiles that should not use the default list, add addresses through the profile action menu.
  5. The following events can be selected to trigger a notification. If you choose ‘digest summary’, all notices triggered during the digest period are aggregated into a single email, so that addressees receive fewer emails.
Violation event
Notices are triggered by alert threshold violation and clear events.
Appliance availability
Notices are triggered whenever the appliance loses its connection or reconnects to AppNeta . For time windows, enter times according to appliance timezone.

How to unsubscribe: the footer of event notification emails indicates which notification profile triggered that email, and contains a direct link to edit that notification profile.

Configure user resolution

FlowView can identify the users that are generating application traffic by correlating login records from your domain controller to the hosts found in flow records. Setup has three essential steps, as coordination is required between your domain controller, an appliance, and FlowView: all appliances within a single domain that should have user resolution enabled must be grouped together; you must then designate one of those appliances to be the login event collector, which receives logs from the domain controller via ssl; optionally, use a CA-signed certificate for the ssl connection. Step-by-step instructions are baked into the app under > user resolution setup.

Limited support: FlowView currently supports user resolution only in environments running Active Directory on Windows Server 2008 R2.

Define a custom app

The FlowView application library currently has over 1000 pre-defined applications. It’s regularly updated and will suit most of your needs out-of-the-box. But naturally, our library doesn’t have any of the custom apps your company uses internally. For maximum visibility, add those apps to the library so that FlowView can properly identify and classify the traffic they generate.

  1. Define your company’s custom applications. You can do this from the manage applications page, where you can either create one from scratch, or edit a pre-defined application. The other way to define a custom app is via host details > top conversations > 50x50_trans.png > ‘define custom application’. The latter method will pre-populate the appliance definition form with the ip/port details of the conversation.
  2. For each appliance, add your custom apps to the FlowView application library.
    1. Navigate to FlowView > appliances, and click ‘configure’ next to any appliance.
    2. Select ‘customized applications’ from the drop down.
    3. Select an application from the drop-down; click ‘+’ to add another app.
    4. Click ‘apply’ before navigating to another configuration option, e.g., alert profiles.

Reapply after editing: After editing a custom app definition, you need to reapply it to the appliance, i.e., repeat step 2 above.

Start FlowView

On the FlowView appliance list page, click ‘start FlowView’. It takes at least 5 minutes after starting FlowView for the first results to come in.

Is FlowView is running? Your AppNeta service instance is stateless, which is why you don’t readily see an indication of whether FlowView is running. Instead, when you re-visit this page, you can look at ‘most recent traffic rate’ which shows the average rate of traffic for the most recent five-minute period, but only if FlowView is on or was on in the last 10 minutes. So if this chart is updating, then FlowView is on.

Go solve problems!

Off the bat, here are some things you might want to take a look at:

View conversations between hosts

Go to top hosts > click on the host that you are interested in. The all conversation between it and other hosts is at the bottom of the page. In addition, you can create a ‘match all’ filter for two ip addresses to see the conversations between them.

Application and network latency

The implementation of FlowView application and network latency monitoring are based on concepts in this nTop article by Luca Deri.

Network latency

Network latency is essentially a packet’s travel time between client and server. It’s calculated using the TCP handshake because these packets are processed by the client/server only up to Layer 3, so we can assume negligible delay is introduced during the back-and-forth. In practice, FlowView takes the equivalent of one-half the total time between the client sending the SYN and the server receiving the ACK.

Network latency is only available for TCP flows in which the handshake is seen. There are two cases in which handshake will not be present in the flow:

  1. For long-lived sessions like ssl, every 5 minutes the existing flow is terminated and a new one is created. Only the initial flow contains the handshake and would therefore have latency calculations.
  2. Mid-stream TOS/DSCP changes are also interpreted as new flows. Again, only the initial flow contains the handshake and would therefore have latency calculations. Where latency couldn’t be calculated, you’ll see a ‘—’.

What’s the difference between FlowView ‘network latency’ and AppView ‘network response’? AppView is designed to illustrate and help improve end-user experience, while FlowView is essentially acontextual; thus their respective ‘network’ calculations are not meant to be compared 1:1. AppView essentially maps the activities involved in a page load to ‘server’, ‘network’, or ‘browser’. Specifically, this design results in ‘network response’ covering the time from the TCP handshake to the first byte of the response, while FlowView ‘network latency’, considers only the TCP handshake.

Application latency

Application latency is the time the server takes to field a request from the client. In practice, it is the time between the last request byte sent by the client to the first response byte received by the client. Naturally, the result includes network latency so we then subtract it. This has two notable consequences:

  1. The TCP handshake must be seen (else network latency cannot be calculated).
  2. For any flow where network latency is much much greater than application latency, application latency becomes inconsequential; in this case FlowView takes application latency to be zero.

FlowView provides two application latency values, the average of all matching flows and the maximum of all matching flows. This is possible because FlowView calculates latency on every client-server exchange that occurs within the flow. Whenever flow history is summarized or collated for presentation, the average of the average and the max of the max are taken. The calculated application latency applies equally to the inbound and outbound directions, so you’ll see the same values in each direction.

What’s the difference between FlowView ‘application latency’ and AppView ‘server response’? ‘Application latency’ and ‘server response’ are calculated the same way: you take the total response time (SYN to first byte in AppView, and GET to first byte in FlowView) and subtract the network component. So in theory, if measured simultaneously against the same web service, ‘application latency’ and ‘server response’ would be the same. In practice however, FlowView provides an average and a maximum, while AppView takes one single measurement periodically. Over time these measurements should be comparable but not equivalent.

Deploy Packet Capture

FlowView Packet Capture is a way of setting up a physical appliance to copying and storing packets. An appliance captures packets based on user-defined parameters that include which packets to capture, how much of each packet to capture, and when to stop capturing. An appliance can only capture based on one set of parameters at any given time. Packets from monitoring, assessments, diagnostic tests, and appliance communication are never captured. The packets are packaged into a standard file format and securely uploaded to AppNeta. You can explore the results there, or download the file to analyze using third-party software.

Address the prerequisites

Every AppNeta module has specific port and protocol requirements. Your appliance may have been set up with one of the other modules in mind, double-check that your firewall rules have been adjusted for FlowView.

Adjust your firewall rules for FlowView…

Choose an install location

Before you can use Packet Capture, you have to decide what point in your network you are going to monitor. Typically you’re interested in capturing packets to help diagnose a problem, and so at least for localized issues the network segment of interest should be self-evident. Generally however, the point you choose should be before any address translation so that private IPs are viewable. Also keep in mind that captures are capped at 1GB or 1 million packets, which ever comes first, so if you expect heavy traffic, you might want to use more specific match criteria or move downstream a bit. Once you’ve decided what you want to monitor, you’ll need decide how you’ll access the traffic of interest. This is done either by mirroring the traffic to the appliance, or allowing the traffic to physically pass through it. Those instructions will follow, but for now just decide which one is more suitable.

Add a second interface

Based on the previous step, you might have decided that you want to monitor a different point in your network than what the appliance is currently set up for. If you have an r40 or higher, you don’t have tear down the existing setup because those models support a second, separately-licensable interface.

Add a physical interface now…

Connect the appliance

Like FlowView, Packet Capture is premised on positioning the appliance so that it has access to the traffic you want to analyze. But, where the rest of FlowView uses the traffic passing through the appliance to generate flow records, packet capture makes a copy of the traffic so you can see what’s inside each packet. There are two ways to set up appliance: one is mirroring the traffic to the appliance, the other is by allowing the traffic to physically pass through it.

Connect the appliance now…

Assign a FlowView license

The appliance must must have a Packet Capture license. See assign an appliance license, you’ll need to have org admin or advanced level privileges.

Set up a passphrase

Set up the passphrase that will be used to keep your packet captures secure—you cannot use Packet Capture until you set the passphrase.

Remember the passphrase. Packet captures are stored in encrypted form using a key that is generated from the passphrase you choose. You need this passphrase to download captures. If you lose the passphrase, you can reset it, but then you can’t download any captures encrypted with the old passphrase.

Set the passphrase now…

Start a capture

An appliance captures packets based on user-defined parameters that include which packets to capture, how much of each packet to capture, and when to stop capturing. An appliance can only capture based on one set of parameters at any given time. Packets from monitoring, assessments, diagnostic tests, and appliance communication are never captured. Captures are capped at 1GB or 1 million packets, which ever comes first, on all appliances. In addition, regardless of any stop conditions, capturing stops when the space remaining on the appliance is too low: for full-packet captures (bytes ≥ 1500), capturing stops when less than 10MB remains; for partial-packet captures (bytes < 1500), capturing stops when less than 1MB remains. When you stop a capture, you cannot restart it. The Start Again option in the action menu starts a new capture based on an existing one.

To start a new capture:

  • click ‘+ Start New Capture’; or
  • to use an existing capture as a template, select > start again.

Could not connect to appliance… If you see the following error message when trying to start a packet capture, it’s possible that the appliance can’t connect to our capture servers. First try to connect to the appliance’s web admin by clicking ‘launch pathview appliance web admin’ on the appliance details panel of the manage appliances page. When you access web admin using this link, a capture server provides a reverse proxy so that your connection remains secure. If you can’t connect to web admin this way, should then double-check that outbound connections to web admin are not blocked by your firewall.

Condition Description
Capture Interface r4* appliance can have multiple capture interfaces.
Packet Limit Specify the maximum number of bytes to store of each captured packet. Default: 96 bytes. Range: 68 - 65,535. Deselect this option to capture entire packets.
Capture Filter Use libpcap syntax to specify which packets are captured, for example, those destined to a specific address and port; or, leave this field blank to capture all packets. Filtering for only the traffic you care about will reduce the capture size, which affords a longer captured duration, and it ensures that the capture analysis is relevant to the problem you are trying to solve. For examples, click the help icon .
Related Paths For any paths that you specify here, an event is logged and marked on the Capacity chart timeline on the Path Performance page.
Capture Stop Condition For single captures, packet capture stops if any of the conditions are met. For scheduled captures, conditions are applied to each individual scheduled capture; you must specify a time limit, along with any other conditions.

Schedule captures

A schedule triggers periodic packet captures. Along with the other parameters you must specify for an individual capture, in a schedule you specify: the number of captures in the series, the repeat interval, and when the first capture starts. There are two ways to create a schedule:

  • for an existing capture, select > ‘schedule this’. This option pre-populates the schedule with capture parameters;
  • navigate to Packet Capture > schedules > ‘create new schedule’.

When you stop a schedule from the capture schedules list page, the current capture and the schedule are stopped and you cannot restart them. When you stop a scheduled capture on the FlowView captures page, that capture stops but the schedule continues. Each appliance can run only one packet capture at a time. If two scheduled captures overlap, only the first one to start will complete; the other fails . Also, make sure you set a passphrase; if you don’t set one, the schedule will run, but every capture will fail.

Explore your results

Navigate to FlowView > Packet Capture, click a non-link portion of any row to reveal the side panel, then click on any link to see detailed capture results. Packet Capture presents analysis of the packet capture over several tabs on the capture details page. There are only a few actions you can perform on this page:

  • download the capture, start a new capture based on the same parameters, or delete the capture;
  • on the overview tab, edit the capture name and add comments;
  • on the related paths tab, click a path to display all of the captures related to that path.

Packet Capture uses the following Wireshark filters to provide alert and warning statistics:

Filter Expression
Bad TCP tcp.analysis.flags
DNS errors dns.flags.rcode > 0
BitTorrent bittorrent
SMTP errors smtp.response.code >= 400 and smtp.response.code < 600
FTP errors ftp.response.code >= 400 and ftp.response.code < 600
HTTP server errors http.response.code >= 500 and http.response.code < 600
HTTP client errors http.response.code >= 400 and http.response.code < 500
SIP errors sip.Status-Code >= 400
ICMP errors or warnings icmp.type eq 3 or icmp.type eq 4 or icmp.type eq 5
Spanning Tree topology change stp.type == 0x80

Download a capture file

Packet captures are packaged as .pcap files. To download a packet capture, select > download on the FlowView captures page. You will be prompted for the appliance packet capture passphrase. The file will be in gzip format with a .pcap extension, a delivery format supported by Wireshark. If you want to uncompressed the file, rename it with a .gz extension and then unzip it as you would normally.

Troubleshoot FlowView

Start FlowView by navigating to FlowView > appliance list and click play on the appliance of interest. You’re going to receive one of the following messages:

Started capturing flows on …

If you got this message you forgot to start FlowView or someone turned it off. Don’t worry about it, it happens all the time. Go get a coffee, your first results will roll in in 5 to 10 minutes.

FlowView has already been started ….

FlowView is runnning. Good. Now check the ‘most recent traffic rate’ column. You’ve already established that no data is coming in, so this column should say either ‘0 kbps’, or ‘-‘.

  • If it says ‘0 kbps’, the appliance has established a connection with our FlowView servers and can upload data. So that means that there’s either something wrong with your cabling or your port-mirroring connection.
  • If it says ‘-‘, the appliance ssl connection to AppNeta is probably down. If this is in fact the case you won’t be able to reach web admin via the ‘launch pathview appliance web admin’ link on the manage appliances page. Check this link and then open a support ticket anyway. We’ll take it from there.

Failed to connect to the appliance …

Something is wrong with your appliance setup generally because our servers can’t reach it.

  • Did you open up all the required ports?
  • Check the manage appliances page for the appliance status. If you see 50x50_trans.png next to it, use the connection lost article to troublehshoot.