Icmp

session.close ()

The method closes the underlying raw socket, and cancels all
outstanding requsts.

The calback function for each outstanding ping requests will be called. The
error parameter will be an instance of the class, and the
attribute set to .

The sessoin can be re-used simply by submitting more ping requests, a new raw
socket will be created to serve the new ping requests. This is a way in which
to clear outstanding requests.

The following example submits a ping request and prints the target which
successfully responded first, and then closes the session which will clear the
other outstanding ping requests.

ping.createSession ([options])

The function instantiates and returns an instance of the
class:

The optional parameter is an object, and can contain the following
items:

• — Either the constant or the
  constant , defaults to the constant

• — How many bytes each ICMP echo request packet should be,
  defaults to , if the value specified is less that then the value
  will be used (8 bytes are required for the ICMP packet itself, then 4
  bytes are required to encode a unique session ID in the request and response
  packets)
• — Number of times to re-send a ping requests, defaults to
• — A unique ID used to identify request and response packets sent
  by this instance of the class, valid numbers are in the range of
  to , defaults to the value of
• — Number of milliseconds to wait for a response before re-trying
  or failing, defaults to
• — Value to use for the IP header time to live field, defaults to

After creating the ping object an underlying raw socket will be
created. If the underlying raw socket cannot be opened an exception with be
thrown. The error will be an instance of the class.

Seperate instances of the class must be created for IPv4 and IPv6.

Ping subagent¶

This subagent can be used to measure ICMP ping response times from one location
to another. Measurements can be either scheduled by the agent itself or
requested by the server.

Metrics scheduled by the agent (based on “PacketRate” parameter):

• ICMP.AvgPingTime
• ICMP.LastPingTime
• ICMP.PacketLoss
• ICMP.PingStdDev

These metrics can be either defined in agent configuration file (using one or
more “Target” parameters), or registered automatically on first request from
server. If targets are registered automatically, default packet size is used.
First request to non-existing target will return “0” as a value. Automatically
registered targets are automatically removed after a timeout, if server stops
requesting metrics for that target.

Metrics available on demand:

ICMP.Ping

Metrics

When loaded, PING subagent adds the following parameters to agent:

Tables

Configuration file

All configuration parameters related to PING subagent should be placed into section of agent’s configuration file.
The following configuration parameters are supported:

Configuration example:

# This sample nxagentd.conf instructs agent to:
#   1. load PING subagent
#   2. Ping target 10.0.0.1 with default size (46 bytes) packets and 10.0.0.2 with 1000 bytes packets
#   3. Timeout for ping set to 1 second and pings are sent 12 times per minute (each 5 seconds)

MasterServers = netxms.demo
SubAgent = ping.nsm


Timeout = 1000
PacketRate = 12 # every 5 seconds
Target = 10.0.0.1:target_1
Target = 10.0.0.2:target_2:1000

Note

Response time of 10000 indicate timeout

DPI — глубокий анализ пакетов ( Deep Packet Inspection)

Во время обычного анализа пакетов считываются метаданные пакета (в основном заголовки). DPI же просматривает содержимое пакета. По сути, DPI анализирует полезную нагрузку и пытается понять, всё ли с ней нормально.

В нашем случае DPI с помощью отслеживания аномалий может обнаружить ICMP-туннель, просмотрев полезную нагрузку и увидев, что она отличается от ожидаемой. Таким образом, мы не сможем скрыть все параметры.

Так а зачем тогда вообще возиться с ICMP-туннелированием?

Потому что:

1. DPI встречается далеко не везде.
2. Большинство DPI-инструментов полагаются на базу с сигнатурами — если для ICMP-сообщений сигнатур нет, то и туннель обнаружить не получится.
3. Даже если в базе найдётся подходящая сигнатура, оператор сначала должен настроить её на работу в активном режиме.

Почему он может её не активировать?

• На проверку каждой сигнатуры требуются ресурсы (преимущественно процессор и время), что может замедлить сеть.
• Проверка сети может проводиться с помощью разных ping-сообщений с разным размером полезной нагрузки (например,  отправит ping-сообщение с полезной нагрузкой в размере 1234 байт) для диагностики проблем, связанных с MTU. Активация подобной сигнатуры приведёт к множеству ложных срабатываний, что будет раздражать команду мониторинга и, как следствие, снизит надёжность сигнатуры.

session.pingHost (target, callback)

The method sends a ping request to a remote host.

The parameter is the dotted quad formatted IP address of the target
host for IPv4 sessions, or the compressed formatted IP address of the target
host for IPv6 sessions.

The function is called once the ping requests is complete. The
following arguments will be passed to the function:

• — Instance of the class or a sub-class, or if no
  error occurred
• — The target parameter as specified in the request
  still be the target host and NOT the responding gateway
• — An instance of the class specifying when the first ping
  was sent for this request (refer to the Round Trip Time section for more
  information)
• — An instance of the class specifying when the request
  completed (refer to the Round Trip Time section for more information)

The following example sends a ping request to a remote host:

Code Fields

Reference

Note

Many of these ICMP types have a "code" field.  Here we list the types
again with their assigned code fields.
    

Type 0 — Echo Reply

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Type 3 — Destination Unreachable

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Reference

Available Formats

Type 5 — Redirect

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Reference

[]

Available Formats

Type 8 — Echo

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Type 9 — Router Advertisement

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Type 10 — Router Selection

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Type 11 — Time Exceeded

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Type 12 — Parameter Problem

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Type 13 — Timestamp

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Type 14 — Timestamp Reply

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Reference

Available Formats

Reference

Available Formats

Reference

Available Formats

Reference

Available Formats

Reference

[]

Reference

[]

Reference

Reference

Reference

[]

Reference

[]

Reference

[]

Reference

[]

Reference

[]

Reference

Reference

Reference

[]

Type 40 — Photuris

Registration Procedure(s)

IESG Approval or Standards Action

Reference

Available Formats

Type 41 — ICMP messages utilized by experimental mobility protocols such as Seamoby

Registration Procedure(s)

Specification Required or IESG Approval

Expert(s)

Unassigned

Reference

Type 42 — Extended Echo Request

Registration Procedure(s)

First Come First Served

Reference

Available Formats

Type 43 — Extended Echo Reply

Registration Procedure(s)

First Come First Served

Reference

Available Formats

Type 253 — RFC3692-style Experiment 1 []

Registration Procedure(s)

Standards Action or IESG Approval

Reference

Type 254 — RFC3692-style Experiment 2 []

Registration Procedure(s)

Standards Action or IESG Approval

Reference

ICMP Extension Object Classes and Class Sub-types

Reference

Available Formats

Sub-types — Class 1 — MPLS Label Stack Class

Registration Procedure(s)

First Come First Served

Reference

Available Formats

Sub-types — Class 2 — Interface Information Object

Reference

Available Formats

Sub-types — Class 2 — Interface Information Object — Interface Roles

Available Formats

Sub-types — Class 3 — Interface Identification Object

Registration Procedure(s)

First Come First Served

Reference

Available Formats

Sub-types — Class 4 — Extended information

Registration Procedure(s)

Standards Action

Reference

Available Formats

Contact Information

It is only appropriate to use these values in explicitly-
configured experiments; they MUST NOT be shipped as defaults in
implementations.  See RFC 3692 for details.

Эхо-протокол

Протокол ICMP предоставляет сетевым администраторам средства для тестирования достижимости узлов сети. Эти средства представляют собой очень простой эхо-протокол, включающий обмен двумя типами сообщений: эхо-запрос и эхо-ответ. Компьютер или маршрутизатор посылают по интерсети эхо-запрос, в котором указывают IP-адрес узла, достижимость которого нужно проверить. Узел, который получает эхо-запрос, формирует и отправляет эхо-ответ и возвращает сообщение узлу – отправителю запроса. В запросе могут содержаться некоторые данные, которые должны быть возвращены в ответе. Так как эхо-запрос и эхо-ответ передаются по сети внутри IP-пакетов, то их успешная доставка означает нормальное функционирование всей транспортной системы интерсети.

Во многих операционных системах используется утилита ping, которая предназначена для тестирования достижимости узлов. Эта утилита обычно посылает серию эхо-запросов к тестируемому узлу и предоставляет пользователю статистику об утерянных эхо-ответах и среднем времени реакции сети на запросы.

Структура ICMP пакета

Общее содержание ICMP пакета

• IP Header (синим цветом):
• ICMP Header (красным цветом):
  • Type of ICMP message (8 бит) — тип сообщения ICMP.
  • Code (8 бит).
  • Checksum (16 бит) — контрольная сумма, вычисляется из части ICMP пакета, заголовок не используется.
  • Header Data (32 бита) — содержит Идентификатор (Identifier) (16 бит) и Порядковый номер (Sequence number) (16 бит) необходимые для корректного определения отправителя.
• ICMP Payload

Технические подробности

ICMP-сообщение строится из IP-пакетов, сгенерировавших ICMP-ответ. Протокол IP инкапсулирует соответствующее ICMP-сообщение с новым заголовком IP (чтобы отправить ICMP-сообщение обратно отправителю) и передает полученные пакеты дальше.

Например, каждая машина (такая, как маршрутизатор), которая перенаправляет IP-пакеты, уменьшает Time to live (TTL) поля заголовка IP на единицу, если TTL достигает 0, ICMP-сообщение о превышении TTL отправляется на источник пакета.

ICMP основан на протоколе IP. Каждое ICMP-сообщение инкапсулируется непосредственно в пределах одного IP-пакета, и, таким образом, как и UDP и в отличие от TCP, ICMP является т. н. «ненадежным» (не контролирующим доставку и её правильность). В отличие от UDP, где реализация надёжности возложена на ПО прикладного уровня, ICMP (в силу специфики применения) обычно не нуждается в реализации надёжной доставки. Его цели отличны от целей транспортных протоколов, таких как TCP и UDP: он, как правило, не используется для передачи и приёма данных между конечными системами. ICMP не используется непосредственно в приложениях пользователей сети (исключение составляют инструменты Ping и Traceroute). Тот же Ping, например, служит обычно как раз для проверки потерь IP-пакетов на маршруте.

Формат пакета ICMP