When creating a network path in Delivery monitoring, there are a number of things to keep in mind. The sections that follow discuss a number of the important considerations.
Single-ended vs Dual-ended paths
There are two network path types used in Delivery monitoring: single-ended and dual-ended.
A single-ended path is one that is monitored in only one direction: source to target. Single-ended monitoring involves sending a train of ICMP echo requests to the path target and measuring various aspects of the packets received in response. Network devices and end-stations generally respond to ICMP echo requests, so the target does not need to be a monitoring point.
A dual-ended path is one that is monitored independently in both directions. It uses UDP in addition to ICMP so an AppNeta monitoring point is required as a target to respond to UDP probes and to initiate Diagnostics tests in the reverse direction. Monitoring in both directions is required for paths that include a link provisioned for asymmetric loads (for example, a typical home ISP connection) because capacity measurements using single-ended monitoring will only detect the slower of the two directions. With dual-ended monitoring, capacity can be measured in each direction independently.
Characteristics of dual-ended paths include:
- they require monitoring points at both ends
- they use UDP in addition to ICMP
- the path performance page displays one chart for each direction
- exceptions are the Latency and Round-Trip Time charts as they already account for two directions
- there are some restrictions when running Diagnostics
Because these two path types use different protocols, and these protocols may be treated differently in your network, it is possible that their respective performance metrics do not match.
Determining the return path for a Dual-ended path
For Dual-ended network paths, the path from the target monitoring point back to the source depends on how the path is set up.
- When identifying a dual-ended path target, use either its IP address or its hostname (note that this is not necessarily the same as its name in APM).
- If you want the return path to target a specific source monitoring point interface, create the path using that interface and specify the target’s IP address.
- If you want the return path to target the source monitoring point hostname, create the path using the target’s hostname.
Source interface selection
By default, all network paths use the primary network connection port (the default interface) on a monitoring point. Some monitoring points have secondary network connection ports that can also be used.
To use a secondary port for a network path:
- When creating a network path using the Path Setup Wizard, select the appropriate Local Network Interface in Step 1 of the wizard.
- If the secondary port does not appear in the Local Network Interface drop-down:
- Confirm that your monitoring point has a secondary network connection port.
- If so, configure the additional physical interface or wireless interface on the monitoring point.
- Re-run the Path Setup Wizard.
- If the secondary port does not appear in the Local Network Interface drop-down:
Known issue on m22, m30, r40, r400: Be aware that, for interfaces with DHCP-assigned addresses that become unavailable (because the interface was deleted, shutdown, or the IP address changed) all network paths that use the interface will enter the connectivity lost state. When you try to configure a network path from the Network Paths page by selecting > Configure for the network path you are interested in, the interface will be marked ‘missing’. If you save a path configuration that uses a missing interface, the connectivity check will pass but the subsequent diagnostic will hang.
When choosing a network path target, keep in mind that the goal is typically to measure performance through the network. In other words, from one network endpoint to another. If you try to target a network device such as a router, the capacity measurements you see may be less than expected as routers prioritize traffic forwarding over responding to ICMP echo requests.
The image below shows the difference between targeting network devices and targeting end-stations on a gigabit network. The end-stations report the expected capacity while the network devices show a lower than expected capacity.
Target selection considerations include:
- AppNeta monitoring points and AppNeta WAN targets make the best targets as they are dedicated to network and application performance measurement.
- Servers and workstations are good targets but you may see as low as 70% of the expected bandwidth due to things like the quality of the NIC, the network driver, and the behavior of the host operating system.
- If you want to monitor the performance of a web application, target the webserver it runs on.
- If you target a workstation:
- make sure that it is configured to allow ICMP responses.
- make sure it is not protected by Symantec endpoint protection. If so, you’ll need to create an exception.
- Windows machines are suitable as targets only on paths up to 100 Mbps.
- If you want to monitor voice or video, the best target is an AppNeta monitoring point in the same network segment as the handset or workstation of the person you are trying to contact.
- If you want to run a voice test, you’ll need a monitoring point as the target.
- Voice handsets, depending on the model, can make good targets. It is generally safe to monitor them for connectivity. Even then, high packet loss can register as connectivity loss.
- Network devices should be targeted only in special circumstances. For example, you may only be able to connect to the outside interface of a remote WAN router, or you may want to know when a device stops responding.
- If you target a c50 deployed using AKS, run the terraform output command within the Azure Cloud Shell to determine the Load balancer fqdn to target.
- For c50s deployed using AKS, we recommend dual-ended paths.
For licensing purposes, there is a distinction between a network path target on a WAN and one on a LAN. Network paths created in Delivery monitoring with a WAN target consume an application license. Those with a LAN target do not. LAN paths and WAN paths are defined as follows:
LAN path - < 4 hops (including the target) or latency < 5ms.
WAN path - >= 4 hops (including the target) and latency >= 5ms.
When configuring a network path, you can specify the Network Type according to these definitions. If you are not sure, use LAN. APM checks all paths nightly and any that are configured as LAN but have WAN path characteristics will be changed to WAN and an application license will be consumed (be aware that this may cause you to run out of licenses). Also, note that the reverse is not true. WAN paths are never changed to LAN even if LAN is the appropriate designation or a transient condition flipped the path from LAN to WAN.
Data or Voice
The only difference between creating a network path to monitor data and one to monitor voice is that, to monitor a network for voice quality, you need to know which audio codec your VOIP deployment is configured to use so that APM can properly simulate that traffic. For video traffic this is not a requirement (even though video data is subject to sampling and compression like voice and the same application level protocols are used to transmit that data) as video traffic is treated as a large data transfer.
Monitoring the path of application data through your network should take into consideration the prioritization, or quality of service (QoS), the traffic receives while in transit. This enables you to understand the network from the perspective of your application data.
Prior to creating a network path, you should determine whether QoS is applied within your administrative domain (AD). If it is, you’ll specify that in the network path configuration, and choose an alert profile with a QoS condition so that you can verify that the QoS you expect isn’t being changed en route.
The link that connects your LAN to the access layer of your ISP is often provisioned asymmetrically. Typically, more bandwidth is allocated to the downlink direction (traffic flowing from the internet) than to the uplink direction (traffic flowing to the internet). Because of this, this link can be a network bottleneck.
If you know the link to be asymmetric, you should definitely configure network paths that use it as dual-ended because when a single-ended path is used in this this scenario, capacity measurements will only reflect the slower of the two directions.
Even if you know that the link is provisioned equally in both directions, we recommend that any network path that includes this link be dual-ended. At a minimum, make at least one of your paths dual-ended (perhaps to an AppNeta WAN target) so that you can verify what your applications and end users are experiencing across this link.
When creating a network path, it is generally a good idea to change the Alert Profile to something other than Connectivity. This will allow Diagnostics tests to be generated when alert thresholds on the path are violated. Diagnostics are not generated when the Alert Profile is set to Connectivity. See Setting Good Alert Thresholds for suggestions.