Make NAM work!

This is the minimal set of actions required to start your NAM experience.

Install components

When running the NAM installation, pay attention to the order in which you install your components. The NAM Console and NAM Server are standard Windows installation packages. Make sure you have access to the Microsoft SQL Server before you start the installation. NAM Probe is a Linux installation package. See the detailed installation instructions below.

Install NAM Console

Install NAM Server

Install NAM Probe

Get components work together

Get the licenses. See Licensing.

Set it all up in the NAM Console. Add all the installed components to your NAM Console and assign data sources to your report servers. Your primary data source will most probably be NAM Probe. However, depending on your monitoring needs, these can also be AppMon UEM, Synthetic, or Enterprise Synthetic. See Devices.

Obtain good traffic

Your NAM Probe needs to sniff good traffic in order to provide good monitoring data. You can use SPAN (port mirroring) or Tap to let your NAM Probe sniff the traffic.

You activated your SPAN or Tap and connected your NAM Probe using its sniffing interface. Good job! Now, make sure you feed your NAM Probe with good quality data. When your system is up and running, we provide a set of tools that will help you troubleshoot the SPAN configuration issues. See Traffic diagnostics report.

Check the resources of your switch first

Your switch needs free resources (processor, memory) to process port mirroring. You need to verify the current consumption before you activate your SPAN. Make sure there's a lot left for performing the port mirroring.

Get rid of non-IP traffic

First things first. What you really need for your NAM Probe is a client-server data exchange, which basically means IP traffic. Make sure you filter out the non-IP traffic on your SPAN

Get unicast traffic

Make sure you are getting unicast traffic for the services you're about to monitor. Just multicast traffic will not get you any good results.

Beware of duplicates

If you span different ports to a single destination port (or if you  span a VLAN to a destination port), it is likely that some communication will be seen several times: as an example, if you span port A and port B to port C, all communications going from port A to / from port B will be copied twice to port C.

You must have a way to deduplicate traffic before you analyze, otherwise, you are likely to draw bad conclusions.

Make sure you are not dropping packets

If you are spanning several ports to one, it is likely that the sum of the capacity of all source ports exceeds the capacity of the destination port. In that case, you need to evaluate the risk of oversubscription of the destination port. Check Traffic diagnostics report and if you see dropped packets, see if this helps:

  1. Measure the level of usage of each source port before you activate the SPAN.
  2. Check that there is no oversubscription on the destination interface  of the switch (the traffic sent is lower than the maximum capacity).

Avoid errors on the interfaces

You may get some errors on the source and destination ports: you should check that there is no checksum, CRC errors (in your switch management interface).

Make sure you are seeing traffic both ways

Response time measurement needs to see the requests… and the responses and to measure the time intervals between them. If you see traffic only Client to Server or Server to Client, you will not get any meaningful data.