Рейтинг Rambler's Top100
IQM: FAQ PDF Print E-mail
Written by Максим   
Wednesday, 31 March 2010 13:06

Last changed 2011-01-11

Load in pdf format


What is IQM?

PDF Print E-mail
Wednesday, 31 March 2010 13:10

IP Quality Monitor (IQM) — is a hardware+software appliance, which provides  measurement and management of IP quality parameters thrughout network. Network-supported Classes of Services and Zone structure are taken into account during measurements.  IQM system supports distributed monitoring of IP network quality parameters. Actually, it is the most used mode of IQM deployment.

Last Updated on Wednesday, 22 July 2015 18:31

What can I use IQM for?

PDF Print E-mail
Wednesday, 31 March 2010 13:13

IQM could be used for:

  • SLA quality parameters measurement and management
  • Active measurement of  IP networks quality parameters
  • Network services troubleshooting and bottleneck detection.
Last Updated on Thursday, 23 July 2015 13:51

What is measured?

PDF Print E-mail
Wednesday, 31 March 2010 13:15
Performing tests on channel-network layers (L2-3 OSI) allows monitoring the following parameters:
  • Packet loss.
  • Round-trip time delay.
  • One way delay.
  • Packet delay variation (jitter).
  • Value of received test traffic.
  • Data transmission rate. Calculated as a value of traffic received per time unit.
  • Maximum channel throughput.
  • Percent of packets delivered with changed class of service marker (remarked packets).
  • Service availability from the point of view of controlled parameters.
Performing tests on application layers (L7 OSI) allows monitoring the following parameters:
  • Service availability: percent of successful queries among the whole testing session.
  • Network service reaction time (minimum, average, maximum at the measurement session). This time consists of time spent for domain name resolving, time for network communication setup and time for complete receiving data requested from the service.
  • Network service reaction time variation. This parameter characterizes the stability of network service response.
  • Speed of service data receiving (minimum, average and maximum along measurement session).
  • Value of data received per service request.
  • Service location in terms of URL: requested URL, effective URL, redirected URL.
  • For HTTP, FTP or SMTP services – it is possible receiving service response codes.

Last Updated on Thursday, 18 April 2013 18:10

What standards are supported?

PDF Print E-mail
Thursday, 18 April 2013 13:06
It’s worth to mention the following standards, that are supported by IQM stsyem:
RFC 1242, 2678 - 2681 - terminology, metrics for connectivity, throughput, one-way delays, round-tip delays, one-way losses
RFC 2544 - methodology
RFC 3393, 3550 — packet-delay variation metrics, incremental PDV calculation method

Last Updated on Thursday, 23 July 2015 14:04

IQM: the functional composition

PDF Print E-mail
Wednesday, 31 March 2010 13:33

Functional composition of the IP Qiality Monitor system could be seen here.

There are two main elements: IQMA (Agents) and IQMM (Managers).

Agents: There are special network appliances used for quality measuremets, which are located in the main network nodes. They are small computers running IQMA software, and are called probes or agents. Agents automatically (on demand or on schedule) run tests between them (agents) and measure delivery parameters losses, delay (RTT), variation (jitter) and bandwidth. Gathered data is than pre-processed, stored in text files and delivered to higher level –

Manager. IQM Manager is the brain of IQM system, providing agent management, data processing and analysis, user interface. IQMM provides:

  • IQMA agents management:
    • Policy configuration
    • Threshold management
    • Test by schedule configuration
    • Test by demand configuration
  • IQMM (lower level managers) management for distributed systems
  • Automated processing of acquired data:
    •  Export of data to SQL DB
    • Data reduction and pre-processing for storage
    • Data storage
    • Data analysis and consistency checks
  • Data violation signalization
  • Stats graphing and user interface



Last Updated on Tuesday, 16 November 2010 14:32

IQM Principles of operations: Simple introduction

PDF Print E-mail
Wednesday, 31 March 2010 13:37
IQM Agent runs under Linux or another Unix variant. Bundled versions use our own Linux distribution optimized for low delay. Major part of software is written is C++, so it is fast and compact.

SSH (TCP 22) and NTP (TCP/UDP-123) should be configured and running on the agent and configured on the agent’s and LAN firewall (if any). Precise time synchronization is vital for network measurements, so selecting the best available NTP servers is major task.

Inter-agent tests are precisely managed data packets series interchanged between them. Based on the measured timings, major network parameters, such as Packet Loss, PDV (Jitter), RTT (Delay) and Bandwidth are calculated. Some type of measurement require special types of payload and/or packet management. All tests now use UDP. UDP ports in use could be dynamically allocated or statically configured by administrator (for firewalls, etc). Data acquisition stores results to text files. Using pre-configured criteria (lines number, time period etc) CDR files are rotated and delivered to IQMM using FTP or SSH (SCP).

IQMM runs data checks and simplifications, loads data into SQL DB, prepares reports and runs user interface. Alarms are generated when violation occurs.

IQMA control protocol (proprietary) uses TCP port 1189 and features handshake, authorization and so on. Agent password is never transmitted in clear.

Last Updated on Wednesday, 31 March 2010 14:52

What network services can be used as agents for network quality parameters measurements?

PDF Print E-mail
Thursday, 18 April 2013 20:07

  • Tests could run between IQMA-based agents, or could be initiated from IQMA to different response-mode agents.
  • IQM system provides support for specific quality measurement agents based on Cisco IP SLA, Juniper RPM.
  • IQMA could use any network device with UDP-echo running as response agent.
  • IQMA could use any network device with ICMP-echo running as response agent (near to any network device)
  • When performing application-layer tests (L7 OSI) IQMA could use the following network services as response-mode agents: FTP, HTTP, IMAP, RTSP, SMTP, TFTP etc.
Last Updated on Thursday, 23 July 2015 14:19

Agent IQMA hardware requirements

PDF Print E-mail
Wednesday, 31 March 2010 13:37
IQMA is not greedy for hardware, and  could use almost any x86- or ARM- compatible platform. IQMA has been ported to NSG-router and SheevaPlug appliance.

General Probe (Agent) hardware requirements

Up to 100 megabits per second:
  • Atom 230 and faster,
  • 1GB RAM and more,
  • USB-Flash (512MB – minimum, 1GB - recommended) , computer MUST support USB flash boot.
  • FastEthernet
Up to 200megabits per second:

  • Atom 330 and faster,
  • 2GB RAM and more,
  • USB-Flash (512MB – minimum, 1GB - recommended) , computer MUST support USB flash boot.
  • Gigabit Ethernet

Up to 1 Gigabit per second:

  • Intel Core2Duo 2GHz and faster
  • 2MB cache and more,
  • 3GB RAM and more,
  • USB-Flash (Fast 1GB minimum, 16-32GB recommended due to speed factor) computer MUST support USB flash boot 1-2 Gigabit Ethernet.

All hardware used should be 100% Linux compatible with 2.6.30 kernels and higher.
Last Updated on Monday, 03 August 2015 15:52

Manager (IQMM) hardware requirements

PDF Print E-mail
Wednesday, 31 March 2010 13:38
IQMM hardware requirements are a functions of test load, system topology, domains number (if distributed), amount of details, user requirements and so on. So it is rather hard to guess required system parameters based on number of probes alone. So, following guesstimates should be considered only as starting point:

Up to 10 agents:

CPU Intel Core2Duo 1.8 GHz and more >=4GB RAM, 300 GB 10Krpm SATA HDD, Fast Ethernet
Up to 30 agents:

Intel Core2Duo 3GHz (e.g. E8400) and more; >=6GB RAM, 2x300 GB 10Krpm SATA HDD, Gigabit Ethernet

Up to 50 agents:

Intel Dual Core i5/Xeon 3GHz 4MB cache (e.g.-i5-650,i5-750)and more ; >=8GB RAM, 3x300 GB 15Krpm SAS or SATA RAID, 2xGigabit Ethernet

Up to 100 agents:

Intel Quad Xeon/i7 (e.g.-Q9550,i7-950) 2.8 GHz/8MB cache and more; >= 16GB RAM, RAID 5,6,10 2TB and more, 2xGigabit Ethernet

Up to 200 agents:

2xIntel Quad/Hexa Xeon (e.g.-X5470,W3570,W5580) 3GHz, 8MB cache and more; >=32GB RAM, RAID 5,6,10 4TB and more, 2xGigabit Ethernet

Keep in mind, RAM is crucial for report generation. If you want fast report generation, increase RAM.

All hardware used should be 100% Linux compatible with 2.6.30 kernels and higher.

Last Updated on Monday, 03 August 2015 14:15

What are preconfigured IQM options?

PDF Print E-mail
Tuesday, 16 November 2010 15:56
Usually, you can buy IQMA either pre-packaged (Small Form-Factor Micro-ITX PCs featuring Atom Dual-Core board, 2GB RAM, GigaBit Ethernet) or USB Flash Image for use with your own hardware (e.g. obsolete office Pentiums-III or Celerons).

However, there are some other options for low-speed specialized tasks:

Software IQMA module for NSG series 800 router. Provides IQMA functions for popular NSG-800 and NSG-900 routers widely used for POS and ATM terminals. Should be installed by Net-Probe only.

IQMA for ARM. We now support Sheeva Plug and are working on another implementations.

Last Updated on Monday, 03 August 2015 15:47

Какие агенты других производителей поддерживаются в IQM?

PDF Print E-mail
Tuesday, 10 December 2013 18:54
There are no translations available.

Система IQM поддерживает работу с агентами измерения встроенными в сетевое оборудование производителей:

  • Cisco: агент в строенный в функционал сетевой операционной системы IOS IP SLA
  • Juniper: агент в строенный в функционал сетевой операционной системы JUNOS RPM
  • Accedian Networks. Проверено взаимодействие с пограничными устройствами линейки EtherNID и MetroNID


What kinds of tests are available in IQMA?

PDF Print E-mail
Wednesday, 31 March 2010 13:38
Currently the following tests are available:
  • Tests for maximum channel throughput measurement. Tests can be carried out with partial or full load of channel capacity. Tests can be started periodically repeating with definite period or with definite time start template or on demand.
  • Auto speed determination with fixed loss percentage and accuracy.
  • Basic quality tests:  jitter, loss, delay, bandwidth etc.
  • Audio/Video streams simulations
  • Emulation of different applications/services
  • ICMP or UDP-echo tests for nodes without IQMA installed.
  • Application-layer tests: FTP, HTTP, IMAP, RTSP, SMTP, TFTP etc.
  • Application layer tests supports:
    • Availability for multiple interactions with service in one transport connection. This will allow speed up TCP session.
    • Availability of marking service traffic with definite class of service.
    • Service access authorization.
  • When testing with HTTP service the following are supported:
    • cookies,
    • HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses.

Last Updated on Monday, 03 August 2015 15:49

How is test start time determined?

PDF Print E-mail
Wednesday, 31 March 2010 13:39
There are several mechanisms to start test timely.
  • Periodical: test starts every time period specified elapses since test creation or agent reboot.
  • Template-based: uses Cron-like strategy.
  • On demand: Run once or number of times specified by hand. For manual usage.
Periodical tests are most suitable for regular measurements. Since they use limited bandwidth, they do not affect running applications.
Template-based tests are used for regular measurements using stress-tests or other bandwidth-intensive tests affecting payload. You can specify night hours and weekend days in template to avoid  harm to  payload. Also, template-based tests could make simultaneous start of test group, which is  used in diffserv/QoS tests.
On-demand tests are used by operators for irregular and spontaneous troubleshooting, etc. There is no storable history for these tests.

Last Updated on Wednesday, 31 March 2010 15:14

Do tests affect each other?

PDF Print E-mail
Wednesday, 31 March 2010 13:39
IQM implements several techniques to overcome mutual influence of running tests and  provide concurrent stress tests when they are needed.
Common practice is to lessen or completely eliminate the mutual influence of tests. Mutual influence could be caused by:
  1. Sharing hardware resources of probe.
  2. Sharing limited network resources.
So, mutual interference affects performance during lack of at least one of the shared resources. When limiting factor is network bandwidth and/or network elements load, measurement errors are affected either by payload influence (in this case we would see the real network behavior) or by stress load, generated by agents. Stress load generation also loads hardware resources both of the agent and network elements. To lessen the burden during periodical stress tests, pseudo-random time-shift interval of 1 to 59 seconds is used. When on-demand tests should be run, systems has ability to temporary suspend periodical and template-based tests in the specified time interval and wait for completion of the tests already running.
For non-stress tests, bandwidth allocation is specified to avoid bandwidth hog.
If concurrent tests are needed, templates should be used to configure them.

Last Updated on Wednesday, 31 March 2010 15:16

What bandwidth does test consume?

PDF Print E-mail
Wednesday, 31 March 2010 13:40
Bandwidth limit is specified for all non-stress tests. Default limit is 64 kbits/s, and should not be lessen without considerations, since it could adversely affect measurements quality.
Stress-test are only limited by hardware and network resources. You can see Agent IQMA hardware requirements  for more information.

Last Updated on Wednesday, 31 March 2010 15:18

How to calculate the proper number of tests for measurement?

PDF Print E-mail
Wednesday, 31 March 2010 13:43
Given number of agents, how much tests should we create in order to reliably measure the performance of network in all needed directions?
If you need to run tests in full-mesh mode, then total number of tests should be equal to number of links between nodes:

<Number of tests>=N(N-1)/2
Where N is the number of nodes.

Many networks have explicit or implicit traffic concentration points, which are much less in number than total number of nodes. So it is worth to avoid running tests between nodes, which have small or no traffic between them. For example, in star topology, only the central node should have “active” agent, where terminal nodes could be considered “inactive” and have agents configured to run in “coupled” (responder-only) mode.
In this case, number of tests for full-mesh network should be corrected by subtracting number of “holes” (missing direct inter-nodal links) defined by “inactive” network elements:

<Number of tests>=N(N-1)/2-I(I-1)/2=(N-I)(N+I+1)/2

Where N is the total number of nodes, I – number of “inactive” nodes.
If we use A=N-I as a number of “active” nodes (traffic concentration points), we have:

<Number of test>=A(2N-A-1)/2
In extreme case, when network has explicit star topology with single center, we have:

<Number of tests> = N-1

Result should be multiplied by number of managed classes of service C. i.e. universal formula for number of tests for the network with N total nodes, A active (concentration) nodes and C classes of service should look like

<Number of tests> = A*С*(2*N-A-1)/2

Last Updated on Wednesday, 31 March 2010 15:19

What is maximum depth of history?

PDF Print E-mail
Wednesday, 31 March 2010 13:44
The size of stored history is limited only by the available disk space volume. Data acquired in one test, after two aggregations, consumes approximately 150 bytes. Given test interval t minutes and T days total run time, using formula from previous answer:
<Data volume> = 150 * (T*24*60/t) * (A*С*(2*N-A-1)/2) = 108000*T*A*С*(2*N-A-1)/t
Given free disk space V bytes, we have:
<Maximum storable history period (days)> = T = V*t/(108000*A*С*(2*N-A-1))
Given V=100GB disk space,  N=100 nodes,  A=1 active traffic concentration point, C=3 classes of service, t=1 minute tests interval, we have 4.5 years of history. If we have A=10 then history size drops to 6 months, if we use full-mesh then 33 days.

Last Updated on Wednesday, 31 March 2010 15:21

How is Round-Trip Time (RTT) measured?

PDF Print E-mail
Tuesday, 11 January 2011 13:44
One IQM agent is used during U7-type (UDP-echo) test, responder should run UDP-echo service. IQM agent encapsulates test request timestamp in the UDP datagram date field. Time is gathered from the local clock of the IQM agent. Request is forwarded to the measured host running UDP-echo service.  According to RFC 862 (Echo Protocol), echo service should reply data without changes. So, the IQM agent gets information on the request origination time from datagram replied.  RTT is calculated as a time difference between request origination timestamp and time of reply received. Since both times are gathered from the IQM agent local clock, there is no additional time error.

Two IQM agents are used during U0-type tests. Agents send test request series to their respective counterpart. One-way trip times from source to destination  (SD) and destination to source (DS) are measured.  Test UDP datagram contains encapsulated timestamp gathered from originator’s local clock. Receiving side gets it’s own local time. One-way trip time is calculated as a time difference between request origination timestamp (using originator’s local clock) and local time of receiver at the test request delivery. RTT is calculated as the sum of the two one-way trip times. Local clocks of the agents should be synchronized.


How is delay variation (jitter) measured?

PDF Print E-mail
Tuesday, 11 January 2011 13:50
Delay variation  (Jitter) is calculated during tests according to RFC 3550 method:

Ji = Ji-1 + (|Di-1,i| - Ji-1)/16

  • Ji – measured delay variation at i-th iteration.
  • Di-1,i – difference of receiving times of two consecutive test requests.

Di-1,i = (Ri-1 – Si-1) - (Ri - Si)

R – test request generation time,  S – test request receive time.

During U7-type (UDP-echo) test the variation of round-trip time is measured, using the local time of originating IQM agent.
During U0-type test the variations of one-way trip delays are measured in both directions. Originating agent’s local time is used for test timestamp, receiving agent’s local time is used for packet delivery time.

Last Updated on Tuesday, 11 January 2011 14:35

How does agents clock synchronization affects measurements?

PDF Print E-mail
Tuesday, 11 January 2011 14:35

During U7-type (UDP-echo) tests only originating agent’s local clock is used, and only RTT parameters are measured. Clock state of the bound passive agent is irrelevant for the measurement precision.
Now, let’s see, how is round-trip time calculated for tests involving one-way requests between two IQM agents. (RTT measurement details could be seen in the “How is Round-Trip Time (RTT) measured?” article).

Let us designate local time difference on the agents as dT.

  • dT = T2 – T1 (T1, T2 – local times at the corresponding active and passive agents)
  • T1s – test request generation time by the active (originating) agent according to its local clock
  • T2(s) - test request generation time by the active agent according to passive (receiving) agent’s local clock
  • T2r – test request delivery time at the passive agent according to its local clock
  • T2s – back-flow test request origination time at the passive agent according to its local clock
  • T2(s) – back-flow test request origination time at the passive agent according to the active agent local clock
  • SDD – Source to Destination delay, real test request delay between active and passive agents
  • DSD – Destination to Source delay, real back-flow test request delay between passive and active agents
  • sdd, dsd – calculated values of one-way delays

Following diagram shows the process of one-way delays measurements, which are used for round-trip delay (round-trip time) calculations:

 Request delivery times T2r and T1r (local clock-based) could be expressed as:
T2r = T2(s) + SDD = T1s + dT + SDD                        (1)
T1r = T1(s) + DSD = T2s – dT + DSD                        (2)

As illustrated in the «How is round-trip time (RTT) measured?» article, SDD is calculated as :
sdd = T2r – T1s = (using (1)) = T1s +dT + SDD - T1s = SDD + dT        (3)
dsd = T1r – T2s = (using (2)) = T2s – dT + DSD – T2s = DSD – dT       (4)
RTT = sdd + dsd = (using (3,4)) = SDD + DSD

As we can see, agents’ local clocks offset does not affect the precision of RTT calculation. However, additional condition should be met: dsd>0 and sdd>0, thus for correct calculations, local clocks offset should be no more than one-way delay.

Let’s see, how is delay variation (as described in the article “How is delay variation (jitter) measured?”) calculated:

Di-1,i parameter is difference of delays of two consecutive requests:

Di-1,i = (Ri-1 – Si-1) - (Ri - Si) = (Si – Si-1) – (Ri – Ri-1) = DS – DR

Since only relative time differences are used in the calculations, local clock’s offset does not affect the precision.

Condition of positive values of calculated parameters dsd > 0 and sdd > 0 should be met, thus local clock offset of agents should be not more than one-way delay for correct calculations.

Last Updated on Tuesday, 11 January 2011 16:24

Is it possible to use IQM in the networks with address space collision?

PDF Print E-mail
Tuesday, 11 January 2011 14:55
IQM could be used for quality measurements in the networks with address space collision (intersection, coincidence). This is often the case for IP VPN providers adding SLA quality monitoring. There are two possibilities to handle the task:

  1. Deployment of NAT (Network address translation) for external representation of VPN address space. MPLS network could use VRF-aware NAT technology. So, IQM agent deployed in the customer’s network core could be represented with unique global (external) IP address in the management network.
  2. Administration of customer’s address spaces, giving unique addresses to IQM agents and providing IP interconnection between agents and management system.


One or several IQM agents are deployed on the provider’s edge. They should be connected with customer’ VPNs through physical or VLAN interfaces. Details could be seen here:

Last Updated on Tuesday, 11 January 2011 15:04

How to disable Apache SELinux Protection?

PDF Print E-mail
Monday, 01 August 2011 13:18

Configuration is correct, but when I try to go for an http alias / iqm / or / pa / an error with the access rights:

[Mon Aug 01 13:25:44 2011] [error] [client x.x.x.x] (13)Permission denied: access to /iqm/ denied
[Mon Aug 01 13:25:46 2011] [error] [client x.x.x.x] (13)Permission denied: access to /iqm denied
[Mon Aug 01 13:25:51 2011] [error] [client x.x.x.x] (13)Permission denied: access to /pa/ denied

what is wrong?


It looks like SELinux working. It is recommended to switch off SELinux for Apache. For this you have to set httpd_disable_trans value to 1 using setsebool command. After this restart apache service.

[root@iqm selinux]# setsebool httpd_disable_trans 1
[root@iqm selinux]# service httpd restart

Last Updated on Monday, 03 August 2015 16:15

How to tune ACLs for IQM's proper work?

PDF Print E-mail
Tuesday, 06 December 2011 17:52

For the IQM works properly the following traffic should be permitted:

Between agents (IQMA):

TCP1189 (control channel)
UDP - user-space range (for testing), if the opening of the full range is prohibited - you can open the pool of UDP-ports for each agent (one port per test).

From management system (IQMM) to agents (IQMA):

TCP1189 (control channel)
TCP22 (SSH) (for agents administration)
UDP161 (SNMP) (When you'd like to get agents information via SNMP)

From agents (IQMA) to management system (IQMM):

TCP21 (FTP) + FTP_DATA (FTP from the agents to the management system. Agents pushes collected statistics using FTP (passive mode))

From agents (IQMA) and mamagement (IQMM) to the NTP-server (NTP server can be combined with IQMM):

UDP123 (NTP) (to synchronize clocks on agents and management system)

Last Updated on Monday, 03 August 2015 16:08

Возможен ли мониторинг основного и резервного канала?

PDF Print E-mail
Tuesday, 10 December 2013 18:38
There are no translations available.

Да. Агенты IQM позволяют осуществлять измерение качественных параметров на различных направлениях. Для контроля множества альтернативных каналов, используемых для передачи трафика между двумя площадками, достаточно двух агентов. Агенты подключаются физическими или логическими интерфейсами к соответствующим каналам, возможно использование secondary IP. Для того, чтобы тестовый трафик попадал в нужный канал используется маршрутизация.
Так же см. вопрос «Возможна ли работа IQM в сетях с пересекающимся планом адресации?»


Last Updated on Tuesday, 07 May 2013 11:53
Copyright © 2021 Net-Probe LLC. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.