Каждое icmp сообщение непосредственно в пределах одного ip пакета
Обновлено: 05.07.2024
Задачи, решаемые ICMP
Подводя итоги, можно сказать, что ICMP-протокол осуществляет:
Следует только иметь в виду, что получив отклик на посланный запрос, мы узнаем состояние объекта не в данный момент, а RTT/2 тому назад.
Схема вложения ICMP-пакетов в Ethernet-кадр
Рис. 4.4.4.1. Схема вложения ICMP-пакетов в Ethernet-кадр
Форматы пакетов ICMP
Рис. 4.4.4.2. Формат эхо-запроса и отклика ICMP
Поле идентификатор бывает важно, когда ЭВМ используется как программируемый генератор трафика. В этом случае очередной ICMP-пакет посылается, не дожидаясь прихода отклика. Более того, такие пакеты могут генерироваться несколькими процессами одновременно. В этом случае поле идентификатор становится необходимым, чтобы определить, какому процессу ОС передать очередной отклик.
Время распространения ICMP-запроса, вообще говоря, не равно времени распространения отклика. Это связано не только с возможными изменениями в канале. В общем случае маршруты их движения могут быть различными.
Так как собственные часы различных ЭВМ имеют свое представление о времени, протокол ICMP, среди прочего, служит для синхронизации работы различных узлов, если это требуется (запросы временных меток). Протокол синхронизации NTP (network time protocol) описан в RFC-1119.
Рис. 4.4.4.4. Формат icmp-запроса снижения загрузки
Рис. 4.4.4.5. Формат ICMP-запроса переадресации
Команды переадресации маршрутизатор посылает только ЭВМ и никогда другим маршрутизаторам. Рассмотрим конкретный пример. Пусть некоторая ЭВМ на основе своей маршрутной таблицы посылает пакет маршрутизатору M1. Он, просмотрев свою маршрутную таблицу, находит, что пакет следует переслать маршрутизатору M2. Причем выясняется, что пакет из M1 в M2 следует послать через тот же интерфейс, через который он попал в M1. Это означает, что M2 доступен и непосредственно для ЭВМ-отправителя. В такой ситуации M1 посылает ICMP-запрос переадресации ЭВМ-отправителю указанного пакета с тем, чтобы она внесла соответствующие коррективы в свою маршрутную таблицу.
Рис. 4.4.4.7 Формат запроса маршрутной информации
Значение поля код определяет природу тайм-аута (см. табл. 4.4.4.1).
Рис. 4.4.4.10. Формат ICMP-запроса временной метки
Отсюда видно, что наиболее узкими участками маршрута являются Гамбург-Дюссельдорф-Берн-CERN. Следует иметь в виду, что канал МГУ-Гамбург является спутниковым и 500мс задержки здесь вносит время распространения сигнала до спутника и обратно. Участок Гамбург-Дюссельдорф (X.25, квота 256кбит/с) является общим также и для потока данных из Германии в США. Передача IP поверх X.25 также снижает эффективную широкополосность канала. Остальные связи обладают недостаточной пропускной способностью. Программа ping показывает для данных участков в часы пик высокую долю потерянных пакетов. Таким образом, имея карту связей и используя указанные процедуры, вы можете успешно диагностировать ситуацию в сети. Продвинутые же программисты могут легко написать свои диагностические программы, базирующиеся на ICMP, как для локальной сети, так и для "окрестного" Интернет.
При работе с субсетью важно знать маску этой субсети. Как уже отмечалось выше, IP-адрес содержит секцию адреса ЭВМ и секцию адреса сети. Для получения маски субсети ЭВМ может послать "запрос маски" в маршрутизатор и получить отклик, содержащий эту маску. ЭВМ может это сделать непосредственно, если ей известен адрес маршрутизатора, либо прибегнув к широковещательному запросу. Ниже описан формат таких запросов-откликов (рис. 4.4.4.11).
Рис. 4.4.4.11. Формат запроса (отклика) маски субсети
Internet Control Message Protocol
Содержание
Технические подробности
Протокол ICMP описан в RFC 792 (с дополнениями в RFC 950) и является стандартом Интернета (входит в стандарт STD 5 вместе с IP). Хотя формально ICMP использует IP (ICMP-пакеты инкапсулируются в IP пакеты), он является неотъемлемой частью IP и обязателен при реализации стека TCP/IP. Текущая версия ICMP для IPv4 называется ICMPv4. В IPv6 существует аналогичный протокол ICMPv6.
ICMP основан на протоколе IP. Его цели отличны от целей транспортных протоколов, таких как TCP и UDP: он, как правило, не используется для передачи и приема данных между конечными системами. ICMP не используется непосредственно в приложениях пользователей сети (исключение составляют инструменты Ping и Traceroute).
Поле типа может иметь следующие значения:
Эхо-протокол
Во многих операционных системах используется утилита ping, которая предназначена для тестирования достижимости узлов. Эта утилита обычно посылает серию эхо-запросов к тестируемому узлу и предоставляет пользователю статистику об утерянных эхо-ответах и среднем времени реакции сети на запросы.
Код | Причина | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0 | Сеть недостижима | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
1 | Узел недостижим | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2 | Протокол недостижим | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3 | Порт недостижим | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
4 | Требуется фрагментация, а бит DF установлен | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
5 | Ошибка в маршруте, заданном источником | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
6 | Сеть назначения неизвестна | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
7 | Узел назначения неизвестен | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
8 | Узел-источник изолирован | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
9 | Взаимодействие с сетью назначения административно запрещено | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
10 | Взаимодействие с узлом назначения административно запрещено | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
11 | Сеть недостижима для заданного класса сервиса | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
12 | Узел недостижим для заданного класса сервиса |
Узел или сеть назначения могут быть недостижимы из-за временной неработоспособности аппаратуры, из-за того, что отправитель указал неверный адрес назначения, а также из-за того, что маршрутизатор не имеет данных о маршруте к сети назначения.
Недостижимость протокола и порта означают отсутствие реализации какого-либо протокола прикладного уровня в узле назначения или же отсутствие открытого порта протоколов UDP или TCP в узле назначения.
Ошибка фрагментации возникает тогда, когда отправитель послал в сеть пакет с признаком DF, запрещающим фрагментацию, а маршрутизатор столкнулся с необходимостью передачи этого пакета в сеть со значением MTU меньшим, чем размер пакета.
Перенаправление маршрута
Маршрутные таблицы у компьютеров обычно являются статическими, так как конфигурируются администратором сети, а у маршрутизаторов - динамическими, формируемыми автоматически с помощью протоколов обмена маршрутной информации. Поэтому с течением времени при изменении топологии сети маршрутные таблицы компьютеров могут устаревать. Кроме того, эти таблицы обычно содержат минимум информации, например, только адреса нескольких маршрутизаторов.
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
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:
Metrics
When loaded, PING subagent adds the following parameters to agent:
ICMP ping response time from target. Agent will send echo request as soon as it receives
request for parameter’s value, and will return response time for that particular request. Argument
target should be an IP address. Optional argument timeout specifies timeout in milliseconds.
Default timeout is 1 second. Optional argument psize specifies packet size in bytes, including
IP header. If this argument is omitted, value from DefaultPacketSize configuration parameter
will be used.
Please note that other parameters just return result of background ping process, while this
parameter waits for actual ping completion and then returns the result. Because of this behavior,
it is not recommended to use Icmp.Ping parameter for instant monitoring, only for
occasional tests. For instant monitoring, you should configure targets for background ping and use
Icmp.AvgPingTime or Icmp.LastPingTime parameters to retrieve results.
Tables
Table of configured ping targets. Columns:
- IP address
- Last response time (milliseconds)
- Average response time (milliseconds)
- Packet loss (percents)
- Configured packet size
- Name
- DNS name
- Automatic
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:
Parameter | Format | Description | Default value |
---|---|---|---|
DefaultPacketSize | bytes | Set default packet size to bytes. | 46 |
PacketRate | packets | Set ping packet rate per minute. Allowed values are from 1 to 60 and values below or above will be adjusted automatically. | 4 |
Target | ip:name:psize | Add target with IP address ip to background ping target list and assign an optional name name to it. Target will be pinged using packets of psize bytes size. Name and packet size fields are optional and can be omitted. This parameter can be given multiple times to add multiple targets. | none |
Timeout | milliseconds | Set response timeout to milliseconds. Allowed values are from 500 to 5000 and values below or above will be adjusted automatically. | 3000 |
Response time of 10000 indicate timeout
DPI — глубокий анализ пакетов ( Deep Packet Inspection)
Во время обычного анализа пакетов считываются метаданные пакета (в основном заголовки). DPI же просматривает содержимое пакета. По сути, DPI анализирует полезную нагрузку и пытается понять, всё ли с ней нормально.
В нашем случае DPI с помощью отслеживания аномалий может обнаружить ICMP-туннель, просмотрев полезную нагрузку и увидев, что она отличается от ожидаемой. Таким образом, мы не сможем скрыть все параметры.
Так а зачем тогда вообще возиться с ICMP-туннелированием?
Почему он может её не активировать?
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
Type 0 — Echo Reply
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
No Code |
Type 3 — Destination Unreachable
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
Net Unreachable | ||
1 | Host Unreachable | |
2 | Protocol Unreachable | |
3 | Port Unreachable | |
4 | Fragmentation Needed and Don’t Fragment was Set | |
5 | Source Route Failed | |
6 | Destination Network Unknown | |
7 | Destination Host Unknown | |
8 | Source Host Isolated | |
9 | Communication with Destination Network is Administratively Prohibited | |
10 | Communication with Destination Host is Administratively Prohibited | |
11 | Destination Network Unreachable for Type of Service | |
12 | Destination Host Unreachable for Type of Service | |
13 | Communication Administratively Prohibited | |
14 | Host Precedence Violation | |
15 | Precedence cutoff in effect |
Codes | Description | Reference |
---|---|---|
No Code |
Type 5 — Redirect
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
Redirect Datagram for the Network (or subnet) | ||
1 | Redirect Datagram for the Host | |
2 | Redirect Datagram for the Type of Service and Network | |
3 | Redirect Datagram for the Type of Service and Host |
Codes | Description | Reference |
---|---|---|
Alternate Address for Host |
Type 8 — Echo
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
No Code |
Type 9 — Router Advertisement
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
Normal router advertisement | ||
16 | Does not route common traffic |
Type 10 — Router Selection
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
No Code |
Type 11 — Time Exceeded
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
Time to Live exceeded in Transit | ||
1 | Fragment Reassembly Time Exceeded |
Type 12 — Parameter Problem
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
Pointer indicates the error | ||
1 | Missing a Required Option | |
2 | Bad Length |
Type 13 — Timestamp
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
No Code |
Type 14 — Timestamp Reply
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
No Code |
Codes | Description | Reference |
---|---|---|
No Code |
Codes | Description | Reference |
---|---|---|
No Code |
Codes | Description | Reference |
---|---|---|
No Code |
Codes | Description | Reference |
---|---|---|
No Code |
Type 40 — Photuris
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
Bad SPI | ||
1 | Authentication Failed | |
2 | Decompression Failed | |
3 | Decryption Failed | |
4 | Need Authentication | |
5 | Need Authorization |
Type 41 — ICMP messages utilized by experimental mobility protocols such as Seamoby
Type 42 — Extended Echo Request
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
No Error | ||
1-255 | Unassigned |
Type 43 — Extended Echo Reply
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
No Error | ||
1 | Malformed Query | |
2 | No Such Interface | |
3 | No Such Table Entry | |
4 | Multiple Interfaces Satisfy Query | |
5-255 | Unassigned |
Type 253 — RFC3692-style Experiment 1 []
Type 254 — RFC3692-style Experiment 2 []
ICMP Extension Object Classes and Class Sub-types
Reference Available FormatsRange | Registration Procedures |
---|---|
0-246 | First Come First Served |
247-255 | Private Use |
Class Value | Class Name | Reference |
---|---|---|
1 | MPLS Label Stack Class | |
2 | Interface Information Object | |
3 | Interface Identification Object | |
4 | Extended information | |
5-246 | Unassigned | |
247-255 | Reserved for Private Use |
Sub-types — Class 1 — MPLS Label Stack Class
Registration Procedure(s) Reference Available FormatsC-Type (Value) | Description | Reference |
---|---|---|
Reserved | ||
1 | Incoming MPLS Label Stack | |
2-246 | Unassigned | |
247-255 | Reserved for private use |
Sub-types — Class 2 — Interface Information Object
Reference Available FormatsC-Type (Value) | Description | Reference |
---|---|---|
0-1 | Interface Role field | |
2 | Unallocated — allocatable with Standards Action | |
3 | Unallocated — allocatable with Standards Action | |
4 | ifIndex included | |
5 | IP Address Sub-object included | |
6 | Name Sub-object included | |
7 | MTU included |
Sub-types — Class 2 — Interface Information Object — Interface Roles
Available FormatsValue | Description | Reference |
---|---|---|
Incoming IP Interface | ||
1 | Sub-IP Component of Incoming IP Interface | |
2 | Outgoing IP Interface | |
3 | IP Next-hop |
Sub-types — Class 3 — Interface Identification Object
Registration Procedure(s) Reference Available FormatsCodes | Description | Reference |
---|---|---|
Reserved | ||
1 | Identifies Interface By Name | |
2 | Identifies Interface By Index | |
3 | Identifies Interface By Address | |
4-255 | Unassigned |
Sub-types — Class 4 — Extended information
Registration Procedure(s) Reference Available FormatsValue | Description | Reference |
---|---|---|
Reserved | ||
1 | Pointer |
Contact Information
Эхо-протокол
Во многих операционных системах используется утилита ping, которая предназначена для тестирования достижимости узлов. Эта утилита обычно посылает серию эхо-запросов к тестируемому узлу и предоставляет пользователю статистику об утерянных эхо-ответах и среднем времени реакции сети на запросы.
Структура ICMP пакета
Bit 0 — 7 | Bit 8 — 15 | Bit 16 — 23 | Bit 24 — 31 |
---|---|---|---|
(20 bytes) | Version/IHL | Type of service | Length |
Identification | flags and offset | ||
Time To Live (TTL) | Protocol | Checksum | |
Source IP address | |||
Destination IP address | |||
ICMP Header(8 bytes) | Type of message | Code | Checksum |
Header Data | |||
ICMP Payload(optional) | Payload Data |
Общее содержание ICMP пакета
Технические подробности
Так как эхо-запрос и эхо-ответ передаются по сети внутри IP-пакетов, то их успешная доставка означает нормальное функционирование всей транспортной системы сети.
Во многих операционных системах используется утилита ping, которая предназначена для тестирования достижимости узлов. Эта утилита обычно посылает серию эхо-запросов к тестируемому узлу и предоставляет пользователю статистику об утерянных эхо-ответах и среднем времени реакции сети на запросы.
Таблица 2.15 – Причины недоставки пакета
Узел или сеть назначения могут быть недостижимы из-за временной неработоспособности аппаратуры, из-за того, что отправитель указал неверный адрес назначения, а также из-за того, что маршрутизатор не имеет данных о маршруте к сети назначения.
Недостижимость протокола и порта означает отсутствие реализации какого-либо протокола прикладного уровня в узле назначения или же отсутствие открытого порта протоколов UDP или TCP в узле назначения.
Ошибка фрагментации возникает тогда, когда отправитель послал в сеть пакет с признаком DF, запрещающим фрагментацию, а маршрутизатор столкнулся с необходимостью передачи этого пакета в сеть со значением MTU меньшим, чем размер пакета.
Маршрутные таблицы у компьютеров обычно являются статическими, так как конфигурируются администратором сети, а у маршрутизаторов – динамическими, формируемыми автоматически с помощью протоколов обмена маршрутной информации. Поэтому с течением времени при изменении топологии сети маршрутные таблицы компьютеров могут устаревать. Кроме того, эти таблицы обычно содержат минимум информации, например только адреса нескольких маршрутизаторов [22].
Мультикастингом (multicasting) называется рассылка дейтаграмм группе получателей. Для идентификации групп используются специальные адреса получателя; эти адреса назначаются из класса D в диапазоне 224.0.0.0–239.255.255.255. Дейтаграмма, направленная на групповой адрес, должна быть доставлена всем участникам группы.
Ряд адресов зарезервирован для специальных групп. Вот только некоторые из них:
1) 224.0.0.1 – все узлы в данной сети;
2) 224.0.0.2 – все маршрутизаторы в данной сети;
3) 224.0.0.5 – все OSPF-маршрутизаторы;
4) 224.0.0.6 – выделенные OSPF-маршрутизаторы;
5) 224.0.0.9 – маршрутизаторы RIP-2;
6) 224.0.1.1 – получатели информации по протоколу точного времени NTP.
Все адреса в диапазоне 224.0.0.0–238.255.255.255 предназначены для использования в масштабе Интернета. Адреса вида 239.Х.Х.Х зарезервированы для внутреннего использования в частных сетях.
Получателей дейтаграмм с определенным групповым адресом мы будем называть членами данной группы. Отметим, что отправитель групповой дейтаграммы не обязан знать индивидуальные IP-адреса получателей и не должен быть членом группы.
Недостатком групповой рассылки является очевидная невозможность использования на транспортном уровне протокола TCP. Использование же протокола UDP имеет типичные для него негативные последствия: ненадежность доставки, отсутствие средств реагирования на заторы в сети и т. д. Кроме того, в отдельных случаях при изменении маршрутов рассылки групповые дейтаграммы могут не только теряться, но и дублироваться, что должно учитываться приложениями.
Построение системы сетей с поддержкой мультикастинга является гораздо более сложной задачей, чем организация групповой рассылки в пределах одной IP-сети. Для продвижения групповых дейтаграмм от отправителя к получателям через систему сетей необходимо осуществлять маршрутизацию дейтаграмм. Однако по групповой дейтаграмме нельзя определить индивидуальные IP-адреса ее получателей; следовательно, использование обычной IP-маршрутизации и даже ее принципов не имеет смысла. Поэтому для маршрутизации групповых дейтаграмм были разработаны специальные методы и протоколы, которые будут рассмотрены ниже.
2. Membership Report (Type = 22) – уведомление о наличии в сети члена группы (отправляется хостом – членом группы – по адресу группы);
Групповой IP-адрес (Group Address) представляет собой четырехбайтовое поле, куда заносится IPv4 адрес групповой рассылки.
Работа протокола IGMP продемонстрирована ниже.
Существует большое количество методов маршрутизации групповых дейтаграмм, то есть продвижения их через систему сетей от отправителя к членам группы.
Классическим методом является Веерная рассылка (Flooding) – наиболее простой метод маршрутизации групповых дейтаграмм, при котором дейтаграмма рассылается во все сети системы независимо от наличия в той или иной сети членов группы. При поступлении групповой дейтаграммы маршрутизатор проверяет, впервые ли он ее получает. Если да, то маршрутизатор рассылает дейтаграмму через все свои интерфейсы, кроме того, с которого она была получена; в противном случае дейтаграмма игнорируется.
Рис. 2.16 – Метод остовых деревьев
После построения остового дерева любой маршрутизатор должен хранить для каждого из своих интерфейсов значение принадлежности или непринадлежности дереву. Групповая дейтаграмма от любого узла распространяется следующим образом: полученная маршрутизатором дейтаграмма ретранслируется через все интерфейсы, принадлежащие дереву, кроме того интерфейса, с которого она была получена.
Метод остовых деревьев многие считают лучше веерной рассылки, поскольку здесь дейтаграммы распространяются по строго определенным маршрутам и в каждую сеть попадает только один экземпляр дейтаграммы. Кроме того, существенно снижена нагрузка на маршрутизаторы, которым больше не требуется хранить устаревшие таблицы дейтаграмм. Однако групповые дейтаграммы по-прежнему рассылаются во все сети независимо от наличия в них получателей. Еще существует большое количество сложных методов, оптимизирующих маршрутизацию групповых рассылок, среди которых наиболее популярными являются методы RPF (Reverse Path Forwarding) и CBT (Core Based Trees) [24].
В главе 2 нами была проанализирована теоретическая основа функционирования любых вычислительных сетей – модель OSI, рассмотрены функциональные особенности каждого из семи ее уровней (представленные сведения систематизированы и проиллюстрированы рядом рисунков и таблиц). Определено соответствие между уровнями теоретической модели OSI и применяемым на практике стеком протоколов TCP/IP. Были выявлены особенности функционирования протоколов транспортного и сетевого уровней стека протокола TCP/IP. Особое внимание уделено анализу современных систем адресации, различным подходам к классификации протоколов маршрутизации, а также структурным единицам основных протоколов стека TCP/IP (Приложение В).
Контрольные вопросы
1. Определение и назначение многоуровнего подхода к сетевому взаимодействию.
2. Соотношение понятий интерфейс, протокол и стек протоколов.
3. Инкапсуляция данных в модели OSI.
4. Два основных типа протоколов модели OSI.
5. Функциональные особенности физического и канального уровней модели OSI.
6. Функциональные особенности сетевого и транспортного уровней модели OSI.
7. Общая характеристика протоколов сетевого уровня модели OSI.
8. Функциональные особенности сеансового, представительного и прикладного уровней модели OSI.
9. Общая характеристика трех уровней стека протоколов TCP/IP.
10. Причины возникновения гибридной модели сетевого взаимодействия и характеристика ее уровней.
11. Общая характеристика протоколов сетевого и транспортного уровней стека TCP/IP.
12. Пример взаимодействия двух компьютеров в рамках гибридной модели.
13. Пример инкапсуляции пакетов в стеке TCP/IP.
14. Характеристика функциональных особенностей протокола межсетевого взаимодействия IP.
15. Общая характеристика структуры пакета IPv4.
16. Основные отличия протокола IPv6 от IPv4.
17. Общая характеристика структуры пакета IPv6.
18. Заголовки расширений пакета IPv6.
19. Проблема перехода с протокола IPv4 на IPv6
20. Основные требования к современным системам адресации.
21. Функции и назначение MAC-адресов.
22. Характеристика символьной системы адресации.
23. Назначение и применение составных числовых адресов (на примере адреса IPv4).
24. Упрощенный подход к IPv4-адресации.
25. Классовый подход к IPv4-адресации.
26. Соотношение понятий маска подсети и рабочая группа.
27. Классы IPv4-адресов.
28. Ограничения и особые адреса в IPv4-адресации.
29. Примеры деления IP-адреса в соответствии с трехуровневой архитектурой.
30. Проверка принадлежности IPv4-адресов к одной подсети.
31. Специфика IPv6-адресации.
32. Сущность технологии бесклассовой междоменной маршрутизации CIDR и понятие префикса.
33. Соответствие адресов различных типов в одноранговых и доменных сетях.
34. Общая характеристика работы протокола ARP для разрешения МАС- и IP-адресов.
36. Соотношение понятий ARP-кэш и ARP-таблица.
37. Централизованный и распределенный подход установления соответствия между символьными и IP-адресами.
38. Соотношение понятий мультеплексирвоание и демультиплексирование в протоколах транспортного уровня.
39. Соотношение понятий сегмент и дейтограмма в протоколах транспортного уровня.
40. Соотношение понятий порт, адрес и сокет в стеке TCP/IP.
41. Структура UDP-заголовка.
42. Структура TCP-заголовка.
43. Основные отличия транспортных протоколов TCP и UDP.
44. Общая характеристика бестабличной маршрутизации.
45. Централизованный и распределенный подходы к табличной маршрутизации.
46. Адаптивная и статическая маршрутизации.
47. Внешние и внутренние протоколы маршрутизации.
48. Общая характеристика и функциональные возможности дистанционно-векторного протокола RIP.
49. Общая характеристика и функциональные возможности протокола состояния связей OSPF.
50. Общая характеристика и функциональные возможности шлюзового протокола BGP.
51. Сфера применения внутренних протоколов RIP и OSPF.
Читайте также: