Each module requires an appliance of some type: PathView takes any type, FlowView takes a physical appliance, and you’ll need a physical or virtual appliance for AppView if there’s no global web monitor in the location you want to monitor from. So before you can dive into all these modules, you’ll first need to deploy an appliance. Deploying actually requires a bit more planning than doing—you’ll need to coordinate with your network administrator—so you don’t need to wait until your appliance is in hand to get started.

Pre-configuring your appliances before shipping them to remote offices will minimize the local setup required.

Where will you deploy?

The key to successful deployment is to first decide what application you want to monitor, and then from there determine who is using those applications.

Deploying for PathView

Nine times out of ten you’ll want to place the appliance in the network segment that the application end-users are in so that one, you’re monitoring the paths on which the application is being delivered; and two, you are are monitoring from perspective of those using the app. For example, if you are monitoring voice traffic, you want to deploy the appliance as an end-station in your voip vlan.

Sometimes, you might want to deploy in such a way that the paths you are monitoring are not entirely congruent with the application path. For example, if you do discover a performance issue, you can re-deploy the appliance upstream to try and isolate the problem. There are no limitations where you position your appliance, it depends entirely on your network architecture. But, one thing to consider is ease of deployment. For example, if you deploy in a dmz, you might need to adjust your firewall rules; or, if you deploy in front of your firewall, dhcp might not be available, which means that you’ll need to statically address the appliance with a public address.

Deploying for FlowView

FlowView is designed to uncover network usage. Strategic positioning involves finding an aggregation point like a gateway or a vlan trunk which is likely to capture the full variety of applications in use. Be sure to consider the horsepower of your appliance model. The hardware inside r40 and r400 has enough performance to keep up when deployed at a higher aggregation layer like a datacenter. The other appliance models don’t because they’re intended for branch office deployment where the traffic and flow rates are lower.

Adjust your firewall rules

Once you’ve decided where you want to deploy your appliance, you should consult your network administrator on what level of access to the internet is permitted from that network segment. Your appliance—or appliance host in the case of virtual appliances and software sequencers—will definitely need to be able to connect to our servers. Beyond that, the port and protocol requirements are mostly based on what modules and features you intend on using, and that is how the following list is organized.

Your appliance will be able to connect to all service components if you just adjust your firewall rules to allow outbound tcp connections to *.pathviewcloud.com on ports 80, 8080, and 443.

AppNeta servers
Assigned PVC server
Outbound TCP 80 An appliance attempts to connect to AppNeta on port 80, then 8080; whether you are connecting directly or through a proxy, you must allow outbound TCP connections to your assigned server on one or both of these ports. Log in to AppNeta and look in your browser address bar to discover the name of your assigned server.
Outbound TCP 8080
e.g., pvc-esp-1.pathviewcloud.com
Relay server
Outbound TCP 443 An appliance first tries to connect to your assigned server on port 80, then 8080. If it cannot—for example, when your security policy disallows HTTPS—the appliance attempts to connect to AppNeta via an SSL relay server. In this case, you must allow outbound TCP connections on port 443 to this server.
Capture server
Outbound TCP 443 Capture servers receive flow records and packet captures, and provide a reverse proxy for SSL connections from the PVC server to appliances. You must allow outbound TCP connections on port 443 to all of these servers.
Upgrade repository
Outbound TCP 80 You must allow outbound TCP connections on port 80 and 443 to this server so that your appliance can download new software versions.
Outbound TCP 443
Outbound TCP 80 (Optional) You may allow outbound TCP connections on port 80 and 443 to this server in case the appliance is ever not able to connect to pvc-repoproxy.pathviewcloud.com.
Outbound TCP 443
Proxy server
e.g., permit tcp host appliance-ip host proxy-ip eq proxy-port If HTTP traffic is directed to a proxy server, make sure that no access control lists prevent the appliance from connecting to it. This might be the case if the appliance is deployed in a subnet reserved for network infrastructure rather than one for end-stations. If the proxy service requires authentication, it must use either basic or digest authentication; NTLM and Kerberos are not supported.
See: Configure appliance for proxy or Configure software sequencer for proxy.
NTP server
Outbound UDP 123 Unless you have your own NTP server, the appliance needs an outbound connection for NTP to ensure precise time stamping.
DNS server
Outbound UDP 53 DNS is required for hostname to IP resolution.
Web admin
Outbound TCP 443 When you access web admin via the manage appliances page, a capture server provides a reverse proxy so that your connection remains secure.
Outbound ICMP ICMP is the instrument for PathView and Path Plus measurements on single-ended paths, so it is essential that these messages are allowed in the outbound direction.
echo-request, echo-reply, time-exceeded, port-unreachable, fragmentation-needed
Inbound UDP 3239 Allow inbound and outbound UDP messages on port 3239 so that appliances can coordinate dual-ended monitoring: allow outbound for source appliances and inbound for target appliances.
Outbound UDP 3239
Inbound UDP 45056-49151 Allow inbound and outbound UDP messages on this range so that appliances can perform dual-ended monitoring and detect QoS changes; this range is also used for PathView Voice Tests. Customize this range.
Outbound UDP 45056-49151
Outbound UDP 49152-65535 PathView sends UDP packets to ports in the stated range as part of QoS diagnostics, path MTU determination, and network discovery. ICMP port-unreachable messages are expected in response. Keep in mind that path targets must actually respond with an ICMP port-unreachable for any of these processes to be successful.
Outbound UDP 161 Allow outbound UDP messages on port 161 so that appliances can query network devices via SNMP.
Path Plus
Outbound TCP 3236 Allow outbound TCP and UDP messages on port 3236 so that PathTests can target PathView appliances. The source and target appliances coordinate on TCP 3236 before and after tests, so it must be opened even if the testing protocol is UDP.
Outbound UDP 3236
PathView Voice/Video
Inbound UDP 3239 Appliances coordinate over UDP 3239 for PathView Voice and Video Tests: allow outbound for source appliances and inbound for target appliances.
Outbound UDP 3239
Outbound UDP 5060 Video and voice tests can use one of two signaling protocols: SIP uses port 5060, and H.323 uses port 1720; if you need to use different ports for signaling, open a support ticket.
Outbound UDP 1720
Inbound UDP 45056-49151 For video and voice tests, RTP and RTCP automatically select ports between 45056-49151.
Outbound UDP 45056-49151
Outbound TCP 80 Outbound TCP connections on port 80 are essential to web monitoring. Allow outbound connections on port 443 if a scripted transaction will include logging in to the target site.
Outbound TCP 443
Outbound UDP 162 Allow outbound UDP messages on port 162 so that appliances can send SNMP traps.

Connect your appliance

Follow the setup instructions for your appliance type:

Assign licenses

AppNeta divides monitoring capabilities into separately-licensable modules. Every appliance comes with a base license, and other licenses may be added as needed. For example, in AppView, only appliances licensed for AppView can be monitoring locations. In addition to module licenses, if an appliance has reached its max path limit, more LAN/WAN packs can be purchased.

If you set up the appliance using the usb or direct connect methods, you’ll be prompted to assign the appliance a license. Assign it at least a base license, and then consider PathView Voice, PathView Video, AppView, FlowView, and Packet Capture depending on how the appliance will be used. The are a couple caveats for FlowView:

  • In FlowView each interface that will be used to capture flows must have a license. Don’t worry about this for now since there’s only one capture interface by default. Bringing up a second one is covered in deploy FlowView.
  • The r400 10G interface needs a 10G license.

If you’re unsure about any of those decisions, you can always add/move licenses via > manage licenses > > assign licenses.

Set the appliance location

AppNeta modules are all about monitoring from the perspective of your end users, and so the appliance location provides essential context for the data it collects. In AppView, location is baked into the definition of web application, and you won’t really be able to get along without it. In PathView apart from enabling path map, the location setting also determines the appliance timezone, which impacts PathView alerts and performance charts.

  • PathView alert time ranges rely on the appliance time zone; if the timezone is incorrect, your alert conditions we not be applied at the time you intended.
  • In addition, a toggle is provided to display path performance charts according to appliance time zone; make sure that the appliance timezone matches its physical location so that your data is shifted the correct number of hours before it is displayed.

If you set up the appliance using the usb or direct connect methods, you’ll be prompted to enter the appliance location. If you need to edit the location, you can do that from > manage appliances > > edit location.