Path performance

PathView plots performance in real-time; no page refresh is required. If you change an attribute essential to monitoring, i.e., source, target, target type, instrumentation, QoS, alert profile, a vertical line marks the point at which you reconfigured the path, or restarted the sequencer process. Gray horizontal lines mark path alert thresholds. When a metric crosses a threshold, it is an event. In case of a violation event the area beyond the threshold is colored red. Whenever a non-default alert profile is applied, faint vertical lines mark the beginning and end of alert profile time ranges.

Path status

Throughout the service, colored icons indicate path status:

OK 50x50_trans.png
The target is responding to test packets, and the path is not violating any alert thresholds.
Violation 50x50_trans.png
The target is responding to test packets, but the path is violating one or more alert thresholds.
Diagnostic 50x50_trans.png
PathView is running a diagnostic on the path.
Connection lost 50x50_trans.png
The path target is not responding to test packets, i.e., 100% packet loss.
Unknown 50x50_trans.png
The path status is unknown. This could be because the source appliance is offline, a path attribute has changed and more data must be collected so that performance can be assessed, or the target hostname cannot be resolved.
Disabled 50x50_trans.png
Monitoring is disabled on the path.
Unlicensed 50x50_trans.png
The path source is not licensed; either the PathView base license or an additional capacity license must have expired.

Path events

An event occurs anytime something about a path changes. Events are logged, marked on the performance charts, and you might receive an email depending on how you’ve set up event notification.

Events are logged. All events for all paths in an organization are logged, and retained for seven days. Each entry in the table has a status icon; this status is the current status, not the status of the path at the time of the event. The event log under PathView > events shows the events for the entire organization; the events tab on the path performance page shows only the events that occurred on the relevant path.

Events trigger notifications. Event notices are emails that contain information about appliance availability 50x50_trans.png and path service quality violations 50x50_trans.png and clears 50x50_trans.png. There’s a set of rules called a notification profile that determines when notices are sent; read more about them in deploy PathView.

Events are marked on the time axis of the top-most chart (MOS or capacity, depending on target type) using colored diamonds. Mouse over the marker for a tooltip. Click the funnel to choose which events are displayed. Locate events throughout the history of the path by clicking and dragging across the histogram above the capacity chart.

Violation event 50x50_trans.png
Path performance surpassed an alert threshold.
Clear event 50x50_trans.png
Path performance returned to acceptable parameters.
Availability 50x50_trans.png
Source appliance availability changed, from available to unavailable, or vice versa.
Diagnostic test 50x50_trans.png
A diagnostic test completed.
Route change 50x50_trans.png
The path route changed.
Packet Capture 50x50_trans.png
A packet capture related to this path started, stopped, failed, or completed.
Monitor Enable/Disable 50x50_trans.png
Monitoring was either disabled or enabled.

How long was a path in violation?

On the events page, use the search to filter down to a single path, and then sort by event time. It should be pretty easy to pair violations and clears, depending on how many conditions violated during the filtered time range, and then from there use the timestamps to manually calculate the duration of the violation. There are no downloadable reports that can provide this information, and the events page only shows the last 7 days of events. For analysis of a greater time range, you’ll need to go to the path performance page and hover over the event markers, or comb through your email notifications if they were set up.

Dual-ended monitoring

Dual-ended continuous monitoring is the same as singled-ended. The only difference is that the charts on the Path Performance page display data for two directions instead of one. The chart makes use of both sides of the x-axis: the outbound direction is displayed on the positive side, and the inbound direction on the negative.

What about latency and RTT? RTT doesn’t display info for both directions because the metric already considers both directions; likewise for latency since it’s derived from RTT.

Provisioned capacity

Provisioned capacity is either the highest total capacity seen during the filtered time range, or an amount that you set based on what is specified in the service level agreement with your ISP.

When provisioned capacity isn’t set, the yellow line on your capacity chart represents only the capacity of bottleneck, which is either the result of a physical or configured limit. But, even though the high point will change a bit due based on the filtered time range, it should stay steady. If you notice a change, this could be the result of a route change or a configuration change by an ISP, continue reading total capacity is lower than expected.

Leaving provisioned capacity unset is the approach you should use when end-to-end performance isn’t guaranteed by your SLA. While the link speed to your ISP might be guaranteed, everything on the public internet is best effort. Generally what you buy from the ISP does end up correlating to end-to-end performance, but you’re not justified in being too strict about your expected level of service.

When you’re monitoring a network circuit that does have a guaranteed end-to-end service level, this is when you should set provisioned capacity. Under the best circumstances, the line would be in the same place as if you had let it float, but it is rightfully fixed and total capacity should never dip below provisioned for long periods. If it does, continue reading total capacity is lower than expected.

Rate-limited capacity

Sometimes an ISP prevents its users from using the full capacity of its network; this is called rate limiting. Some ISPs trigger rate limiting when your traffic rate crosses a threshold, other ISPs market a ‘burst’ technology, which means that they’re limiting your regular capacity, but give you more for short periods of time, e.g., during large downloads. In either case, your true available capacity is the one in rate-limited state.

PathView is capable of measuring rate-limited capacity, but only on dual-ended paths because an appliance is needed at both ends. PathView floods the path with controlled bursts of packets at the total capacity rate in order to trigger rate limiting. The source floods outbound and the target floods inbound. The rate at which the appliances receive the packet bursts determines the rate-limited capacity. These floods, though brief, have significantly more impact on the network than standard monitoring, but they’re needed because the standard bursts aren’t enough to trigger rate limiting.

To enable monitoring on rate-limited paths, open a support ticket. Once enabled, the rate limiting capacity chart appears on the path performance page. There are some chart controls in the analysis modules panel; if you disable rate-limited monitoring, only we can re-enable it.

Timezone selection

By default, all time series charts within the service display according to the timezone set in your user profile; hover on your username, click ‘update time zone’, and make sure that it’s set correctly. In PathView, path performance charts can optionally be displayed according to appliance time zone if that perspective suits you better. In that case, make sure that the appliance timezone matches the location so that your data is shifted the correct number of hours before it is displayed. To set the appliance timezone, see appliances. There is a minor caveat when using daylight saving timezone: when your time range filter includes the daylight savings boundary, the x-axis of the time series honors standard time. If this is undesirable you can temporarily change your user profile to use a standard timezone.

Embeddable charts

Some charts on the path performance page offer an embed code. Embeddable charts enables you to construct a central dashboard outside of our service to display data from multiple monitoring solutions side-by-side. The chart can be customized, and this is done by changing the key/values in the JSON.

Customization not supported.
Specified in milliseconds. Default: 60000. Min: 60000.
Defaults to the current path name and may be changed as desired.
There’s a system-defined default, which can be overidden by a user-defined value. Specify in pixels, but omit the units.
Not defined by default, so by default the chart is responsive. Specify a value to fix the width. Specify in pixels, but omit the units.
Customization not supported.
Customization not supported.
Customization not supported.
Specify the last X minutes/hours/days. Use whole numbers only, and specify units as ‘m’, ‘h’, or ‘d’.
Defaults to a deep link of the path, but may be changed.
We recommend using this in combination with endTime. If used alone, the effective time range becomes the specified time to current time. Specify in UTC. The chart will continue to auto update if this option is used.
We recommend using this in combination with startTime. If used alone, the effective time range becomes the 1 hour preceding the specified time. Specify a UTC. The chart will not auto update if this option is used.
Add "mode": "sparkline" to render the chart without axis.

No data? If your chart is blank you are reporting on a range that has no data, you have an error in your code, or the appliance is off line.

Route analysis

In PathView, a path is the series of hops between two devices, plus the quality of service traffic receives en route. As part of continuous monitoring PathView regularly traces the physical route, hop-by-hop, from source to target. The route analysis tab displays the results of these traces.

Network devices

The network devices page is a catalog of typically routers that PathView encounters during diagnostics. When PathView return its hop-by-hop analysis, you can choose to save routers of interest for snmp polling, and those that you’ve identified are listed here.

You can add network devices to this page directly too, and they can be any network device of interest, though they should be in your administrative domain. You can manually add a device via ‘+add device’, which presents the same pop-up from that you would see when adding a device via diagnostics. Or you can use the network discovery feature by clicking ‘+discover devices’. The page that you land on is the same one that you use for path setup. Network discovery based on two inputs: an address range and a choice of whether to discover appliances or other network devices; ‘network devices’ should already be selected.

Network device details

Click a table row to go the network device details page where you can initial snmpwalks and view results.

SNMP walk
PathView has access to an extensive snmp MIB library, that covers commons vendors like: Alcatel, Broadcom, Avaya, Cisco, IBM, Lucent, Nortel, Xerox, etc. With access to this library, PathView can automatically determine which MIBs are available on a device, and then walk each one. The results are organized in a hierarchical tree that you can walk manually or search. OIDs that can’t be matched to a MIB are grouped under ‘unknown OIDs’; and if the device doesn’t return a value for MIB, it is hidden by default.
Device info
Presents commonly queried OIDs in a series of tables.

Tree map

Tree map is essentially a word cloud of all monitored paths in your organization. Each path is represented by a color-coded box. Mouse over a rectangle to display the path configuration; click once to reveal side panels; click twice to go to its path performance page.

Size by importance
Paths set to one will be bigger than those set to five; likewise, size by number of violations, and path with more violations will be bigger (tree map does not display paths with zero violations during the selected period).
Group by path attribute
Paths will be separated and then sized; grey headers show attribute values.

Path map

Lines representing WAN paths are color-coded based on the selected metric, and their intensity is based on the metric value, e.g., 0% is lighter than 50%. If the selected metric doesn’t apply to a path’s target type, the path isn’t shown. If multiple paths have the same source and target locations, an order of precedence determines which path’s information is shown. First path status is consulted using the following order of precedence: failed, connectivity loss, violated, testing, ok, disabled. If all states are equal then we consult all other metrics for: failed, connectivity loss, highest to lowest measurement, and finally disabled.

Performance analysis

Performance charts are black

A black overlay means that the appliance can’t reach the path target. This could either be because the target doesn’t respond to icmp, or because the source appliance could not resolve the target hostname.

Performance charts are grey

A grey block means that AppNeta hasn’t heard from the appliance. If you see a grey bar and manage appliances says that the appliance is offline, this is expected; see connection lost to determine why that is. If the appliance is online, then you should check

A grey block isn’t a problem in and of itself. Appliances traverse the public internet in order to reach AppNeta. In some cases, glitches happen, and in fact the appliance has been designed with this in mind. Appliances can cache up to 2 hours of data locally, and back fill the charts when they reconnect. So a handful of events like these aren’t a big deal, but if the condition persists it probably represents a major issue.

Rarely, though worth mentioning, it’s possible that a grey bar persists because it fails to connect to AppNeta on it’s first few attempts. The appliance employs a backoff strategy where it attempts to connect every few seconds, then every minute, and so on until it dampens down to once every thirty minutes. So if some obstruction preventing the appliance from connecting to AppNeta is subsequently removed, it could take up to 30 minutes for the grey bar to resolve.

Total capacity is higher than expected

If total capacity measurements are way beyond what you expect, this is usually because the link to your ISP is physically capable of greater speed, but your ISP has used a traffic engineering technique called ‘rate limiting’ to clamp you to the amount specified in your SLA. Usually transactional data and control data is allowed through at full capacity because they are short bursts of traffic, but sustained data transfers like streaming media will trigger the rate limiter.

Because PathView is extremely light weight, it too might not be able trigger the rate limiter. As a result, you’ll end up seeing the entire capacity of the link, rather than the amount that has been provisioned for you by your ISP. If you have another appliance at the target customer care can enable rate-limited monitoring for you, which increases the amount of data sent in the test in order to trigger rate limiter. See rate-limited capacity.

Total capacity is lower than expected

There are several reasons why total capacity might be lower than expected. But the first reason might actually be your expectations if you’re used to measuring bandwidth. Remember that capacity is always an end-to-end measurement where the bandwidth provisioned by your ISP is almost certainly with respect to one or a few links. That aside, total capacity for any link or set of links will always be less than bandwidth because it’s a network layer measurement while bandwidth is a physical layer measurement. Link-layer headers and framing overhead reduces rated capacity to a theoretical maximum, which is different for every network technology.

Further reducing capacity is the fact that NICs, routers, and switches are sometimes unable to saturate the network path, and therefore the theoretical maximum can’t be achieved. ‘saturate’ means the ability to transmit packets at line rate without any gaps between packets. All switches can go line rate for the length of time that a packet is being sent. The trick is to be able to send the next packet without rest in between. This capability is referred to as ‘switch capacity’ and is practically impossible to control for even within your own administrative domain, let alone across the public internet.

Considering both of the these factors—the latter being variable—PathView offers the range for total capacity that you can expect given the physical medium and modern equipment with good switching capacity.

Half-duplex links: Total capacity is based on the assumption that traffic will flow in both directions. Therefore, you can expect the total capacity for half-duplex links to be roughly half of what it would be with full-duplex.

Standard Standard link speed L1 + L2 overhead Theoretical total capacity Optimal total capacity
DS0 or ISDN 64 Kbps 3.9% 61.5 Kbps 61.5 Kbps
ISDN dual channel 128 Kbps 3.9% 123 Kbps 123 Kbps
T1 (HDLC+ATM) 1.544 Mbps 11.6% 1.365 Mbps 1.325-1.375 Mbps
T1 (HDLC) 1.544 Mbps 3.5% 1.49 Mbps 1.40-1.49 Mbps
E1 2.0 Mbps 3.5% 1.93 Mbps 1.86-1.95 Mbps
T3 45 Mbps 3.5% 43.425 Mbps 42.50-43.45 Mbps
10M Ethernet full-duplex 10 Mbps 2.5% 4.875 Mbps 4.8-4.9 Mbps
10M Ethernet full-duplex 10 Mbps 2.5% 9.75 Mbps 9.7-9.8 Mbps
100M Ethernet half-duplex 100 Mbps 2.5% 48.75 Mbps 48.5-49.0 Mbps
100M Ethernet Full-duplex 100 Mbps 2.5% 97.5 Mbps 90-97.5 Mbps
Gigabit Ethernet Full-duplex 1 Gbps 2.5% 975 Mbps 600-900 Mbps

Once your expectations are in line with what PathView measures, make sure you choose a good target , because some devices are better than others.

Capacity can also be misleading on a single-ended path. When you have a link with different up/down speeds, e.g., your cable connection at home, a single-ended path only shows the slowest of the two. For example, if you have 50 Mbps download and 5 Mbps upload on your home DSL connection, a single-ended path only shows a capacity of 5 Mbps. You should always use dual-ended paths for asymmetric paths, and you see measurements that don’t look right at least set up an additional dual-ended path to verify that asymmetry isn’t the issue.

Next, it’s important to note that when low capacity as a persistent rather than transient condition is caused by the bottleneck, not congestion. And the bottleneck can be at any point in the path not just the first/last mile. It could instead be far away on the public internet. To verify which is the case, make an additional path to an AppNeta WAN target, verifying through path route that a different route is taken. If the capacity measurements are the same, then the bottleneck is likely the link to your ISP. Otherwise, the bottleneck is somewhere else on the path, and the capacity you’re seeing is accurate.

Are you seeing corresponding packet loss? Every 1 minute, capacity is measured by sending multiple bursts of back-to-back packets as described in how PathView works. To measure total capacity, at least one burst must come back with zero packet loss. If that is not the case, then capacity is skipped for that interval. In the case of intermittent packet loss, this leads to a choppy graph, and in the case of sustained packet loss, you’ll see capacity bottom out.

If all of the above checks out, the next thing you want to do is run PathTest, to corroborate the low capacity measurements. Remember that this is a destructive test which measures bandwidth, not capacity.

  • If PathTest supports the capacity measurements, then is possible that you’re not getting the proper provisioning from your ISP.
  • If the PathTest result is incongruent with your capacity readings, you should open a support ticket so we can help you further investigate.

PathView doesn’t match my ISP

Sometimes your expectations of capacity are based on a speed test provided by your ISP. Different tests yielding different results is not uncommon, but there are reasons why the comparison might not be legitimate. To make sure you’re comparing apples to apples:

  1. Run a dual-ended path. Speed tests usually return an up value and a down value. Running a single-ended path won’t do because they return only one number, the lower value of inbound and outbound.
  2. Make sure PathView is targeting the same geographic region as the speed test. PathView measures the capacity of the bottleneck between two locations. A path from A-to-B could have a different bottleneck than and A-to-C, and so we expect that their test results could be irreconcilable.
  3. If still no match, run PathTest. PathView PathTests are your source of truth because it uses flooding instead of packet dispersion. Use udp for the protocol because it gets treated like actual data traffic by network equipment, where as icmp is control traffic, which gets treated differently. Make sure you’re testing in both directions, and when it comes to choosing a bandwidth, set it to ‘max’.
  4. If PathTest doesn’t match PathView continuous monitoring, rate limiting or some other traffic engineering might be at play. In this case open support ticket so that customer care can turn on rate-limited monitoring.

What a chore, right? Admittedly, what’s outlined above is going to be a chore. It’s not often that our customers have a spare appliance laying around at precisely the geographic location needed. You’re better off working with your ISP to re-run the test with their tool but with a source and target that are congruent to your path.

Recognizing oversubscription

Oversubscription is a technique your ISP uses in order to sell the full bandwidth of a link to multiple customers. It’s a common practice and usually not problematic, but if it is impacting performance, you’ll see it first in your utilized capacity measurements. Always corroborate capacity measurements with RTT, loss, and jitter. If there are no corresponding anomalies, then whatever triggered the high utilization isn’t really impacting performance. If there are, you’ll then need to head over to FlowView to check for an increase in network utilization. High utilized capacity coupled with no increase in flow data is a classic sign of oversubscription, and it’s time to follow up with your ISP.

Sustained packet loss

If a path shows sustained packet loss, look at its latest diagnostic to understand where the loss is occurring:

  • If the loss is occurring at the last hop, make sure that firewall/endpoint protection at the target allows icmp.
  • If the loss is occurring mid-path, make sure routing policies are not de-prioritizing icmp, and access control lists are not blocking icmp. Mid-path firewalls might also be impacting end-to-end performance with respect to bursty data.

In any case, ICMP limitations might not affect production traffic. Set up a dual-ended path to test whether other protocols are affected.

Path alerts

An alert profile is a set of performance thresholds, the purpose of which is to continuously monitor for undesirable performance. In PathView, alert profiles can be used to monitor for a variety of path metrics including network connectivity, utilized capacity, and dscp changes. Choose a system-defined profile or create your own, and then apply one or more to a path. PathView will then annotate performance charts, generate logs, and notify you by email and/or snmp any time performance is not up to par.

Path alert profiles are comprised of one or more conditions; generally, conditions follow the format ‘Condition A violates if greater/less than B for C minutes, and clears if greater/less than D for E minutes.’ You can see that the basic components are a violation clause, a clear clause, and an evaluation period. The violation clause describes poor performance, the clear clause describes acceptable performance, and the evaluation period confirms that the condition is persistent before declaring a violation or clear event.

Alert profile selection is part of the PathView add path process. To apply a profile to an existing path or change the profile that is already applied, you have two options:

  • click on the profile name in the path details panel on the path performance page, or
  • select > configure path on the path list page.

The profile selection drop-down does not contain every system-defined and custom profile; this is because your choices are narrowed based on path target type and instrumentation. If all conditions in the profile are not applicable to the path target type and instrumentation, the profile is filtered from the list.

Connectivity profile

The connectivity alert profile/condition monitors the appliance connection to the target, and is unrelated to the appliance availability events, which refers the appliance connection to AppNeta. Loss of connection to the target is marked by a red diamond because that’s a violation of an alert condition. On the other hand, PathView always monitors for the appliance availability and no additional alert condition is required; hence, loss of that connection is denoted by a purple diamond .

Custom alert profiles

When you are making a custom profile, you can either use a system-defined profile as a template or start from scratch. In either case, if you add a condition that is already used, the new condition replaces the old one.

Before you start creating an profile, it’s helpful to know the target type and instrumentation for the paths to which you’ll apply it because these details affect which conditions you include. For example, a MOS condition is not applicable to a path with target type ‘Server: WAN Webserver’; MOS is a voice condition and so the profile will be filtered from the drop-down when you try to apply it. Likewise:

  • data loss; data jitter; and total, available and utilized capacity are data conditions.
  • voice loss, voice jitter, and MOS are voice conditions.
  • total capacity symmetry and conditions with directional components are for dual-ended paths.
  • connectivity, QoS change, route change, latency, and RTT are general conditions and can be applied to any path.

Target type: auto
If your target type is auto, you can use data and voice conditions.

Applying multiple profiles

Path alert profiles can be either system-defined or custom, and you can apply one or more to a path. But, PathView can only alert according to one profile at a time. So, in order to apply multiple profiles to a path, each profile has to be paired with a time range so that PathView knows when to start and stop alerting. The default profile, ‘connectivity’, is paired with the one system-defined time range, ‘always’. You can define more time ranges and mix and match them with profiles at any time. If time ranges overlap, there is an order of precedence to time ranges that determines which profile is applied.

Time ranges

Using time ranges, a path can have a different alert profile at different times. For example, you might apply the ‘WAN’ profile during business hours to alert on data loss, latency, etc.; but after end-of-business, when performance is less critical, switch over to the basic ‘connectivity’ profile. Assuming a 9 to 5 workday your time ranges might look like this:

Business hours
M-F 9:00-17:00
Sat-Sun 0:00-11:59
Mon-Fri 0:00-8:59
Mon-Fri 17:01-11:59

One continuous range, ‘always’, is pre-defined, and it’s applied when no other ranges are defined. To define other time ranges navigate to > manage time ranges. Time ranges rely on the appliance time zone setting</strong>. If the timezone is incorrect, your alert conditions won’t be applied at the time you intended; to set the timezone see appliances.

After you create your time ranges, you can pair them with alert profiles when you are creating or editing a path. Profile/time-range pairs are a per-path configuration; for example, ‘network health’ can be paired with the ‘business hours’ time range for one path, but with the ‘weekend’ range for another path.

If you delete a time range that is assigned to a path, the time range and its corresponding alert profile are removed from the path; if no other profile/time-ranges are assigned, then the last applied alert profile is paired with the default range ‘always’.

Overlapping time ranges

When applying multiple alert profiles, time ranges with the same frequency (e.g daily, weekly, etc.) and period (e.g 00:00-24:00) cannot overlap. When ranges with different frequencies have overlapping periods, an order of precedence determines which profile is applied: yearly time ranges supersede monthly, monthly supersedes weekly, weekly supersedes daily.

For example, two weekly ranges defined Friday 08:00-17:00 and Friday 16:00-18:00 cannot be applied to the same path. However, a monthly range, recurring on the 15th from 16:00-18:00, and a weekly range, Friday from 16:00-18:00, can be applied to the same path; if the 15th day of the month is ever a Friday, the monthly range is applied.

‘Always’ and ‘Daily’ are considered overlapping ‘Always’ and ‘Daily’ are considered overlapping and so they cannot be applied concurrently.

Evaluation periods

Some conditions have an evaluation period, e.g., ‘for 5 minutes’. This period is how long a condition must exceed its threshold before it triggers a violation or clear event. During this period, any single measurement non-conforming to the condition will cancel the evaluation, and the 5 minutes will start over the next time the threshold is crossed.


Alerting on qos changes

The ‘qos change’ condition violates when qos has been altered in either the outbound or inbound direction.

For the outbound direction, PathView uses icmp port-unreachable messages to monitor for when that happens. Small udp packets are sent to a random high port at the target, which is most likely unused. This is done to elicit a port-unreachable (PU) icmp message. The PU packet contains in its payload the ip header of the denied udp packet. By comparing the qos marking in that header to the qos marking we sent, we know whether qos was altered enroute: if the qos found in the payload was altered or cleared, the condition violates; if it matches what we sent, we then check the inbound direction.

In order to know whether qos was altered from target to source we compare the icmp echo and response pairs used for continuous monitoring. Generally, the target will use the same qos value as arriving packets, or it will zero the qos. If the echo-response qos is zero we have no way of determining whether the target cleared it, or it was cleared enroute. So, the condition is not violated. If the echo-response qos is non-zero and different from the echo-request, we know from the PU check that the outbound direction is fine, so most likely the qos change happened inbound, and the condition is violated.

For dual-ended paths, the qos detection in the inbound direction is different since dual-ended paths use udp not icmp. The source and target appliance are both configured to use the user-specified qos value, so the source appliance simply has to inspect incoming udp packets to determine whether the qos was altered enroute.

Quality of service changes are detected only if the path settings include qos markings and an alert profile with qos condition is applied. Quality of service changes are also only detected by the source appliance, so if qos is added and then stripped by your ISP, which is upstream, changes to those markings won’t be detected by the appliance.

The PU check normally occurs every 5 minutes. This means that if a qos change violation occurs, it takes this long to clear.


Alert status

Quickly find out the state of the paths in your organization from the home page. Service quality compliance shows the percentage of each hour that any monitored path was in violation; violations by type shows the total number of violations per hour; and path tree shows the current state of each path in the organization.

Status icons are used throughout PathView to tell you at a glance something about the current state of the path, including when the path is in violation. The path details panel uses and to indicate the status of each condition in the currently applied alert profile.

Alerts in action

The application of an alert profile is immediately reflected in the performance charts. A black vertical line marks when an alert profile is applied or changed. If an alert profile contains a threshold, it appears as a horizontal line on the corresponding chart. If more than one profile is applied to the path, faint vertical lines mark the beginning and end of the time range.

If performance crosses the threshold in the violation direction, the area of the chart beyond the threshold and the threshold line are colored red. The threshold line might remain red even after performance subsequently crosses the threshold in the clear direction because performance must be acceptable for the amount of time specified in the definition before the violation clears.

If the profile time range expires while a condition is in violation, the condition is cleared, and the event log cites ‘threshold suppressed’.

Violations that occur while an appliance is disconnected from the service don’t raise an event until the connection is restored.

Alert threshold violations and clears are events:

  • Events are marked on the time axis of the top chart using colored diamonds: a red diamond
    indicates a condition violated; a green diamond indicates the condition cleared. Every violation triggers a path diagnostic, if one is not already in progress; its completion is a test status event and is also marked using a pink diamond .
  • Events are logged. Navigate to PathView > events to display all events for all paths in an organization; click on the events tab on a path performance page to display all events for a path.
  • Events trigger notifications based on your notification profile.

Path setup

In general a path is the series of routers that packets take to get from one network device to another. But, in the context of PathView, a path not only the series of hops between device A and device B, but also by the quality of service the packets receive en route. This is because PathView is not just about performance along a path, but performance along a path from the perspective of the applications taking the path. Navigate to PathView > path list > ‘+add path’. From there you have three options for adding a path: path setup wizard, discover my network, and add demonstration paths. Path setup wizard is the recommended method for new users.

Path setup wizard

Paths are added in PathView via the add paths page. Using the left-side navigation panel, select PathView > path list and then click ‘+ add path’. The path setup wizard is the most involved of the three add-path methods in PathView. You can configure one or more paths at a time, target any reachable IP address world-wide including other appliances, and it makes all path attributes available for customization.

Step 1: choose appliances. In PathView, all paths originate from a PathView appliance. The appliance you select here will be the device that sends out test packets and collects performance information. All of the appliances in your organization are listed; select multiple to create more than one path.

Step 2: choose targets. Select the network devices that will be the end points by entering either the ip address or hostname of any network device in the world, including PathView appliances. For best results, enter a computer workstation, server, or PathView appliance, not a router or switch. Routers often return worse results than expected because they’re designed to pass traffic, not to respond to traffic. We highly recommend that you set the target location because the whole point of PathView is assessing network performance from various geographic perspectives. Appliance and target locations are also used in the default path descriptions in the next step. If you intend to keep the default description or use the variable, be sure to set the target location here so that the path description field doesn’t come up blank. Before you move to step 3, the Path Setup wizard verifies that the source appliance can reach the target. You may skip it.

Step 2.5: set appliances as endpoints. If you selected multiple appliances in step 1, you can make those appliances the end points. This feature only works if the source and destination appliances can resolve each other by hostname. If they can’t, you will see a black overlay on your path performance charts because the appliance cannot connect to the target. If you meet that prerequisite, then in this step you can interconnect appliances using a graphical interface to quickly set up multiple paths. You have two choices for network topology: ‘mesh’ and ‘hub-and-spoke’. To illustrate the difference let’s suppose you select four appliances in step 1:

You’ll get at least one path from each appliance to every other appliance.
  • Single-ended gets you six paths because every appliance is either a source or a destination. You might be expecting twelve paths for a full-mesh—A to B and B to A, for every appliance—but if you want monitoring in both directions, you should select ‘dual-ended’.
  • Dual-ended gets you six paths just like single-source. You don’t need 12 paths for a full mesh because each path monitors in both directions; it doesn’t matter which appliance is the source because the monitoring method is the same in both directions.
  • Single and dual-ended gets you six single-ended and six dual-ended.
This option chooses one appliance—the first one, alphabetically—to be the source, and all other appliances are targets. You can change the hub appliance from an additional drop-down. Click a path to reveal ‘remove path’ and ‘change direction’ options.

Set appliances as endpoints only works if the source and destination appliances can resolve each other by hostname. If they can’t, you will see a black overlay on your path performance charts because the appliance cannot connect to the target.

Step 3: customize settings. This step is totally optional. If you’re creating your first path, and you just want to see how everything works, skip it. You can always go back and change these parameters later. The settings shown here will be applied to all of your new paths, but some individual customization will still be available in the next step. There are a lot of options in this step, which might look daunting, but the tooltips contain all the information you need.

Step 4: preview. This step lists all of the paths that are about to be created. Unlike step 3, where any changes you make are applied to every path, this step lets you make changes to each path individually. The ones you don’t want to add can be de-selected. Paths eligible to be dual-ended are marked in the last column; if you mark any others, be sure to double-check their names. Default path names use the variable, which means that you could end up with a dual-ended path that says ‘(single)’ instead of ‘(dual)’ in the path name. There’s no sense in monitoring the same path twice so paths that don’t have a unique combination of source, target, and qos are rejected.

Discover my network

Discover my network is a convenience for adding paths en masse. Choose a source appliance and specify a local subnet or remote address range that contains potential targets. PathView automatically configures paths to every device that the source can reach. You can preview and customize them before adding, but, because this is a bulk configuration, only the essential parameters are available. Network Discovery uses icmp and udp to discover hosts. In order to be discovered hosts must: allow inbound icmp echo-requests and respond to them with echo-reply; and allow inbound udp packets to high ports and respond to them with icmp port-unreachable. The network discovery page is the same for discovering devices and adding paths. The only difference is that ‘discover’ is pre-selected based on how you arrived at the page; for path setup, ‘paths’ is pre-selected.

Add demonstration paths

This method is for PathView beginners. It’s a distilled version of the path setup wizard in which all you have to do is fill in the source and target; all of the other parameters will use their respective defaults. In addition, the targets are limited to a multiple choice of well-known websites.

Path template groups

Suppose you’re setting up a new appliance, and you want the appliance to have the same paths as your first appliance— for each path you want the same target, same instrumentation, same alert profiles, etc. How would you do it? You might write down the configuration for each path, go to the Add Paths page, and then enter the parameters one at a time. Tedious and error-prone. And then what if you add still one more appliance? To solve this problem, AppNeta offers path templates.

A path template is a path configuration—minus the source—that you save for reuse. A path template group is a container for one or more path templates. It works like this: you place individual path templates in a group, subscribe appliances to the group, and then publish the group. Then, any time you make a change to the group, e.g., add, remove, or edit a path template, you publish it again to propagate the changes to subscribers.

To create a path template group:

  1. Create a path template group:
    1. Navigate to > manage path template groups.
    2. Click ‘add path template group’
    3. Name the group and add a description if you want.
    4. Click ‘save’
  2. Add path templates to a group
    1. Click ‘add path template’
    2. The interface that follows is the same as the add path page, except that you don’t have the opportunity to select a source appliance. Go through the configuration options and then click ‘add template path’.
  3. Subscribe appliances to a new path template group
    1. On the edit path template group page, click ‘publish path template group’.
    2. Select the bulk action ‘publish’.
    3. Select the appliances that will be sources for the paths in the path template group.
    4. Click ‘subscribe’.

If an appliance has an existing path with the same combination of target hostname, qos, and instrumentation as one of the templates, it will not be able to subscribe to the group.

Edit a path template group

Change a path template or template group and push those changes to subscriber appliances

  1. Navigate to > manage path template groups.
  2. Add, remove, or edit a path template.
  3. On the edit path template group page, click ‘publish path template group’.
  4. Select the bulk action ‘publish’
  5. Select the appliances to which you want to push the changes.
  6. Click ‘publish changes’

Make templates from existing path

To template existing paths so that you can get them onto other appliances quickly, use ‘copy to template group’ from the action or bulk action menu on the path list page. For each selected path, a template will be created and added to the template group you select—recall that at template is the entire path configuration, minus the source. If any template in the template group has the same combination of target and qos, your attempt to template the path is rejected.

Update a path template

Change a path that was created from a template, and then update the template.

Select ‘configure’ from the action or bulk action menu on the path list page. Make your edits and then choose ‘save and update template’. This option updates the template, minus the name and description. You have to publish the template again to propagate the changes to the other appliances subscribed to the template group.

Make sure you save your changes. ‘Save’ only updates the individual path, and the next time that path’s template group is published your changes will be overwritten.

Single- vs. dual-ended paths

A single-ended path is one that is monitored in only one direction: source to target. A dual-ended path is one that is monitored independently in both directions; for this the path must have one PathView appliance as the source and another as the target. Monitoring in both directions is useful for paths that have links that are known to be asymmetric, like the connection to your ISP, or where the path is equally burdened in both directions, like for video conferencing and voip.

Under the hood, there is a further difference between single- and dual-ended paths, which explains why they have different capabilities. Single-ended monitoring involves sending a train of icmp echos to the path target and measuring various aspects of the packets received in response. Network devices and end-stations generally respond to icmp echos, which is why an appliance isn’t required at the far end. The trade off is that there is no appliance then to initiate inbound diagnostics. Dual-ended monitoring on the other hand uses udp. udp isn’t purpose-built for discovering and announcing network presence like icmp, so a PathView appliance is required at the far end to respond to udp probes.

Because these two path types use different protocols and your network might treat those protocols differently, it’s possible that their respective performance metrics might not match.

On a dual-ended path, the monitoring method is the same in both directions, but there might be an impact on diagnostics depending on which appliance is designated the source.

Creating dual-ended paths

A dual-ended path is one that is monitored independently in both directions; for this the path must have an appliance at both end points. Monitoring in both directions is useful for paths that have links that are known to be asymmetric, like the connection to your ISP, or where the path is equally burdened in both directions, like for video conferencing and voip.

In the path setup wizard, there are three opportunities to configure a path as dual-ended:

  • Two of your own appliances—Since the path requires that both the source and target are appliances, you might select two appliances in step 1 of the path setup wizard. In this case, step 2 of the wizard allows you to select ‘set appliances as endpoints’. Select this option and you’ll see the ‘instrumentation’ drop-down. Select ‘dual-ended’ or ‘single and dual-ended’. The second option simply creates two paths, as you’ll see in step 4.
  • One of yours, one of ours—Instead of using two of your own appliances, you can use an AppNeta WAN target instead. If you do, don’t skip the connectivity test in step 2 because it’s tied to your opportunity to make the path dual-ended in step 3. In Step 3, check ‘dual ended path’; you’ll then have the option of naming the inbound and outbound directions. In step 4, the paths that can be dual-ended are marked in the right-most column.
  • In Step 4, the right-most column indicates whether the path is dual-ended; you can check or un-check this box to make it single or dual-ended. Note that the path name does not automatically update, so the if the path name includes ‘(single)’ or ‘(dual)’, be sure to update it before clicking ‘add paths’.


A local area network usually co-locates hosts across a small geographic area, e.g., one or more buildings; primarily uses Layer 2 devices; and is owned and controlled by a single person or company. A wide area network is usually spread across a large geographic area, one that crosses metropolitan, regional, or national borders; uses more Layer 3 devices; and is often connected via public networks. In general, when creating paths, choose LAN if the path source and path target are in the same building, and choose WAN if the path between the source and target will cross a public network.

Regardless of your choice, AppNeta makes its own determination of whether a path is LAN or WAN during path setup. LAN paths have fewer than three hops or an average latency of less or equal to 5 ms over the last 24 hours; WAN paths have three or more hops and average latency of greater than 5 ms over the last 24 hours. If you choose contrary to these definitions—which might happen when you’re creating multiple paths—AppNeta will automatically change the incorrect designations for you; you’ll notice this is the final step of the path setup wizard.

AppNeta checks LAN/WAN designations nightly. A path will automatically be changed to WAN if it doesn’t meet the criteria for LAN; paths will not be changed from WAN to LAN if the WAN criteria is not met. To be clear, once the nightly check changes a LAN path to WAN, it will never be changed back, even if it currently meets the LAN requirements.

Choosing path targets

When choosing a path target, keep in mind is that you should be trying to measure performance through the network. By design network equipment responds differently if the traffic is intended to be processed locally; it’s common to see lower capacity and sometimes data loss when targeting to these devices directly. The attached image shows the difference between network equipment and end-stations targeted across a gigabit network: the end-stations report the expected capacity, while the network equipment is dubiously lower.

That said, PathView appliances are your best target candidate. Servers and workstations are good targets, but you’ll often see 70%+ of the expected bandwidth; this is due to the quality of the NIC, the network driver, and the behavior of the host operating system. In addition, Windows machines are suitable as targets only on paths up to 100 Mbps. Finally, there are cases in which you might choose to target network equipment, despite their poor capacity measurements: you might only be able to connect to the outside interface of a remote WAN router and no other devices beyond it, or you might want to know when a device stops responding.

A couple of additional notes: voice handset sometimes make good targets and sometimes not; it varies model to model. It’s generally safe to monitor them for connectivity, but sometimes high packet loss can register as connectivity loss. Also, to target workstations, the workstations must allow icmp responses. If symantec endpoint protection is in place, you’ll need to create an exception.


Target types

You should keep the default ‘auto’. The other target types are legacy.

AppNeta WAN targets

We’ve made some of our own appliances publicly available so that you can test the health of your Internet connection. Target them using single- or dual-ended WAN paths.

Vancouver @1G
Vancouver @1G
Boston @10G
Boston @1G

Source interface selection

Suppose an r40 appliance has set up two interfaces eth4 and eth5. eth4 is in subnet A, eth5 is in subnet B, and default gateway is in A. Now, if the appliance is monitoring a target that is reachable from both networks, it would always take the path through A. So how do we get monitoring to go through B for a specific target? Simply add a second interface, and the path configuration wizard then allows you to select a source interface for the path. Upon changing the source interface to eth5, the appliance immediately routes monitoring traffic for the path over eth5 while all other paths remain on eth4. Behind the scenes, what’s happening is the source appliance adds a route table for the source interface and it is always consulted before the main routing table. You can see these routes in web admin > network configuration > active routes.

Known issue: m20 | m22 | m30 | r40 | r400

There is a special case for interfaces with DHCP-assigned addresses. When a path is configured using an interface which later becomes unavailable—because the interface was deleted, shutdown, or the IP address changed—the path will enter the 50x50_trans.png connectivity lost state. Under 50x50_trans.png > ‘configure’ the interface will be marked “missing”. If you save a path config that uses a missing interface the connectivity check will pass, but the subsequent diagnostic will hang.

Port customization for PathView

Monitor engineered traffic patterns with PathView by specifying the port range used for dual-ended paths. Using a custom, narrow port range enables network admins to classify udp probes between source and target using extended acls so that the probes can be influenced by policy-based qos, policy-based routing, and port-based traffic filtering. Ports can be customized by uncommenting ‘# UDP Port Range: 45056,49151’ in web admin > appliance configuration > sequencer configuration.

Saved lists

Saved lists are like groups in that you can search, rearrange path lists, and filter reports by them. But there’s one key difference: a path can belong to more than one list; this is so that you have flexibility when assembling paths that have multiple attributes in common. Navigate to settings > manage saved lists.

Static list
Static lists contains paths that you explicitly include, so they can only be updated manually.
Smart list
Smart lists dynamically populate based on path attributes that you select such as group or target type. Smart lists are powerful because you can build notifications and reports from them, and those notifications and reports will automatically include any new paths that meet the list criteria.

Path management

As you add paths, you’ll see your path list page getting longer and it might become harder to find what you’re looking for; this will also be true anywhere you’re asked to select a path. Fortunately, PathView gives you some tools to help keep your organization tidy, and make you more efficient.

Group by
On the path list page you can separate one long list into multiple smaller lists based on a path attribute. If you want to re-arrange the list by a combination of attributes, you should create a saved list and then group by saved list.
Bulk action
On the path list page you can edit a path attribute or perform an action on multiple paths at once.
Saved lists
See saved lists.
Group and importance
These attributes exist only for the purpose of helping you find and filter for paths. You can re-arrange the path list page, re-arrange the path tree, filter reports, and search by either of these attributes. Group is simply a label you make up to identify a similarity among multiple paths; make it meaningful like a location or what the paths are used for; each path can belong to only one group. Groups are useful when paths can’t be grouped by other path attributes like target type. Importance is number you assign to a path between 1 to 10, based on how important do you think this path is to your business; use 10 for the most important paths.
Search and sort
You can search by any path attribute, and tables can be sorted by any column.

Edit existing paths

You can edit a path after it’s been created:

  • Edit one attribute: path performance > path details panel.
  • Change many attributes at once: PathView > path list > > configure path.
  • Change an attribute or perform an action on multiple paths at once: PathView > path list > bulk action.

PathView prevents you from combining conflicting attributes like data target type with voice alert threshold. Even when bulk editing, the if there’s a mismatch, the change isn’t applied to the offending path. Any time you change a path attribute, monitoring is restarted; this point is marked on performance charts with a vertical grey line.

Delete a path

You can delete a path from PathView > path list > > delete. If this option is disabled, it’s because the path is being used by AppView and cannot be deleted directly. Instead remove the appliance from the web app definition or delete the web app entirely.

Reset path name

At any time, you can rename a path to the default SourceName <-> TargetName: PathView > path list > > reset path name. After a hostname change use this option to update your paths. This only available as a bulk action if the path name is already set to SourceName <-> TargetName.

Change existing path to dual-ended

Select ‘configure’ from the action menu on the path list page. Click ‘create this path with dual-ended instrumentation’. Name the inbound and outbound directions of the path (optional), and then click ‘submit’.

Create a group

There are three opportunities to create a group:

  • settings > manage groups.
  • While editing a path: PathView > path list > path performance > > configure path.
  • While creating a path: PathView > path list > ‘+ add path’.

Add a path to a group

  • While editing a path: PathView > path list > path performance > > configure path.
  • While creating a path: PathView > path list > ‘+ add path’.

Edit a group

See > manage groups. > edit.