AAA

RFC 3549 — Linux Netlink как протокол для служб IP

Статус документа

Этот документ содержит информацию, предназначенную для сообщества Internet, и не задает каких-либо стандартов Internet. Документ может распространяться без ограничений.

Тезисы

Данный документ описывает интерфейс Netlink ОС Linux, который используется операционной системой для обмена сообщениями как между процессами ядра, так и между ядром и пользовательскими процессами. Основное внимание в документе уделяется описанию функциональности Netlink как протокола, связывающего компоненты FEC (Forwarding Engine Component) и CPC (Control Plane Component), которые определяют работу сервиса IP. Прочие варианты использования Netlink, включая обмен сообщениями внутри ядра и между процессами IPC (Inter-process communication), а также настройка конфигурации служб, не относящихся к IP (несетевые службы или сетевые службы других протоколов), в данном документе не рассматриваются.

Документ предназначен для создания информационного контекста на начальном этапе работы группы ForCES IETF.1

1. Введение

Концепция разделения служб IP на управление и пересылку впервые была реализована в начале 1990-х годов в сокетах маршрутизации BSD 4.4 [9]. В то время наибольшую важность представляло простое решение вопроса пересылки пакетов IP (v4) и управление таблицами пересылки IPv4 в CPC (с помощью консольного интерфейса или демона динамической маршрутизации.

Мир IP-сетей с тех давних пор существенно изменился. Linux Netlink с точки зрения обеспечения сервиса и управления кроме поддержки сокетов маршрутизации обеспечивает ряд дополнительных функций. Начиная с ядра Linux 2.1, сокет Netlink обеспечивает абстракцию служб IP для нескольких типов сервиса кроме классической пересылки IPv4 в соответствии с .

Мотивом создания этого документа послужило отнюдь не желание описать весь набор служб, для которых можно использовать Netlink. Фактически многие типы сервиса (групповая маршрутизация, туннелирование, маршрутизация на основе правил и т. д) просто не рассматриваются в данном документе. Не предназначен документ и для использования в качестве учебника по Netlink. Идея документа заключается в общем описании Netlink и более подробном рассмотрении обязательных компонент в контексте работы группы ForCES — IPv4 и QoS. Документ также служит предварительным описанием множества механизмов, изучение которых представляет интерес в рамках ForCES. Рассматривается подмножество функций, доступных в ядре версии 2.4.6, которая была последней во время подготовки данного документа. Кроме того, документ рассматривает лишь функции, связанные с IPv4.

Документ начинается с концептуальных определений, после чего приводится рассмотрение Netlink в свете этих определений.

1.1. Определения

CP представляет собой среду исполнения, которая может иметь несколько субкомпонент, которые будут обозначаться как CPC. Все CPC, обеспечивающие контроль для разных служб IP, будут выполняться посредством машины пересылки FE. Такие отношения между компонентами означают возможность наличия нескольких CPC для одной физической CP, если они контролируют несколько служб IP. По сути, связь между CP и FE является абстракцией сервиса.

1.1.1. Компоненты CPC

Компоненты управляющего плана CPC включают сигнальные протоколы от динамических протоколов маршрутизации (например, OSPF [5]) до протоколов распространения тегов (например, CR-LDP [7]). Классические протоколы и операции управления также входят в эту категорию. Среди них такие механизмы, как SNMP [6], COPS [4] и фирменные средства настройки конфигурации CLI/GUI. Задача управляющего плана состоит в обеспечении среды исполнения для перечисленных действий с целью настройки конфигурации и управления второй компонентой элемента сети (NE) — машиной пересылки FE. Результат настройки конфигурации определяет способ трактовки пакетов, проходящих через FE.

1.1.2. Компоненты FEC

Машина пересылки FE представляет собой объект NE, который первым получает сетевые пакеты (из сети в NE).

Связанная с сервисом компонента FE просматривает пакет с целью обеспечения для него обработки, определенной компонентами CPC для данного типа сервиса IP. Различные службы будут использовать различные компоненты FEC. Сервисные модули могут объединяться в цепочки для поддержки более сложных типов сервиса (в рамках описанной ниже модели Linux FE).

Будучи созданной для поддержки конкретной службы, сервисная компонента FE будет по-прежнему соответствовать принципам модели пересылки.

1.1.2.1. Модель машины пересылки IP в Linux

                          ____      +---------------+
                     +->-| FW |---> | TCP, UDP, ... |
                     |   +----+     +---------------+
                     |                   |
                     ^                   v
                     |                  _|_
                     +----<----+       | FW |
                               |       +----+
                               ^         |
                               |         Y
                         В сетевой    Из сетевого
                         стек хоста   стека хоста
                               ^         |
                               |_____    |
Приемное                             ^   Y
устройство ____    +-------+        +|---|--+   ____   +----------+ Выходное
  ->----->| FW |-->|Входной|-->---->| Пере- |->| FW |->| Выходной | устройство
          +----+   |  TC   |        | сылка |  +----+  |    TC    |-->
                   +-------+        +-------+          +----------+

На рисунке показана модель Linux FE для отдельного устройства. Единственной обязательной частью этой модели является модуль пересылки (Пересылка), соответствующий RFC 1812. Различные модули сетевого экранирования (FW), управления входящим и исходящим трафиком (TC) не являются обязательными и могут даже использоваться для обхода модуля RFC 1812. Эти модули показаны в виде простых блоков на пути передачи данных и, фактически, могут представлять собой каскады из множества субмодулей. Дополнительную информацию о таких модулях вы найдете на сайтах [10] и [11].

Пакеты, прибывающее на входное устройство, сначала проходят через модуль межсетевого экранирования (FW), который может отбрасывать (drop) и изменять (mangle) пакеты или выполнять с ними иные операции. После прохождения модуля FW входящие пакеты в зависимости от принятой политики, могут попадать во входной модуль контроля трафика TC, который выполняет операции по измерению и регулированию потоков входящего трафика. Пакеты могут отбрасываться входным модулем TC в зависимости от результатов измерения уровня трафика и принятой политики. После этого пакет передается единственному обязательному модулю, который обеспечивает пересылку в соответствии с требованиями RFC 1812. Пакет может быть отброшен, если он не соответствует требованиям RFC 1812, 1122, а также дополняющих их документов. Этот модуль является точкой выбора пути, из которой пакет, направленный принявшему его сетевому элементу NE, может быть передан сетевому стеку хоста.

Пакеты, которые не адресованы данному NE, могут проходить через субмодуль маршрутизации на базе правил (часть модуля пересылки), если такая маршрутизация поддерживается. После этого пакет передается следующему модулю сетевого экранирования, который может отбросить или изменить пакет в зависимости от настроек своих субмодулей и выбранной политики. После прохождения модуля экранирования пакет попадает в выходной фильтр контроля трафика (TC).

Выходной TC может отбрасывать пакеты с учетом политики, состояния очередей, уровня насыщения и правил управления скоростью исходящего потока. На этом этапе используются выходные очереди и задержки или отбрасывание пакета могут происходить как до его включения в очередь, так и после этого. Судьба пакета определяется выбранными для модуля алгоритмами и политикой.

1.1.3. Службы IP

Служба IP представляет собой процессы обработки пакета IP внутри NE. Эти процессы определяются комбинацией CPC и FEC.

Занимаемое службой время начинается с момента прихода пакета в NE и заканчивается в момент, когда пакет покидает NE. Существенно, что поведение служб IP в этом контексте определяет конкретным хостом. Компоненты CP, запущенные на NE, определяют сквозной для всего пути контроль служб с помощью управляющих приложений и сигнальных протоколов. Такие распределенные компоненты CPC унифицируют сквозное представление служб IP. Как было отмечено выше такие компоненты CP определяют поведение FE (и, следовательно, NE) по отношению к описываемому пакету.

Простым примером службы IP может служить классическая пересылка IPv4. В этом случае управляющие компоненты (протоколы маршрутизации OSPF, RIP и т. п.) и фирменные средства настройки конфигурации CLI/GUI изменяют таблицы пересылки FE для того, чтобы обеспечить простой сервис по пересылке пакетов на следующий интервал (next hop). Обычно NE, обеспечивающие такой сервис, называют маршрутизаторами.

На рисунке показан простой пример реализации FE<->CP для обеспечения классической пересылки IPv4 с некоторыми дополнительными функциями QoS для управления выходными очередями.

                        Плоскость управления (CP)
                       .------------------------------------
                       |    /^^^^^^\      /^^^^^^\         |
                       |   |        |    | COPS  |-\       |
                       |   | ospfd  |    |  PEP  |  \      |
                       |   \       /      \_____/    |     |
                     /------\_____/         |       /      |
                     | |        |           |     /        |
                     | |_________\__________|____|_________|
                     |           |          |    |
                    ******************************************
     Машина         ************* Сетевой уровень ************
     пересылки (FE) *****************************************
       .-------------|-----------|----------|---|-------------
       |       Сервисная компо-  |              |             |
       |       нента FE для     /               /             |
       |       пересылки IPv4  /               /              |
       |       ---------------/---------------/---------      |
       |       |             |                |        |      |
вход   |       |     --------|--        ------|-----   |   выход
пакета |       |     |Пересылка |      | Выходной   |  |   пакета
-->--->|------>|---->|   IPv4   |----->| планировщик|->| ---->|->
       |       |     |          |      | Scheduler  |  |      |
       |       |     -----------        ------------   |      |
       |       |                                       |      |
       |        ---------------------------------------       |
       |                                                      |
       -------------------------------------------------------

Демон ospfd управляет работой протокола OSPF, а COPS PEP представляет собой дополнительную компоненту CPC. Компонента IPv4 FE включает модуль пересылки IPv4, а также модуль выходного планировщика QoS. В качестве дополнительной службы может быть добавлен сервис пересылки на основе правил между модулем пересылки IPv4 и модулем планировщика QoS. Простейший классический вариант будет включать только модуль пересылки IPv4.

Опыт использования сетей говорит о важности добавления в маршрутизаторы новых типов сервиса, удовлетворяющих современным требованиям. Для решения этих задач были созданы и стандартизованы новые службы, которые могут выходить за пределы содержимого заголовков сетевого уровня. Однако, для обеспечивающих пересылку пакетов устройств NE по-прежнему используется термин «маршрутизатор». Новые службы (которые могут выходить за классические пределы заголовков L3) включают межсетевое экранирование, QoS с использованием Diffserv и RSVP, NAT, маршрутизацию на базе правил и т. п. Для таких служб создаются новые протоколы и средства управления.

Одним из экстремистских определений сервиса IP является «все, за что сервис-провайдеры могут взять деньги».

2. Архитектура Netlink

Управление компонентами IP-сервиса определяется с использованием шаблонов.

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

Взаимодействие между FEC и CPC в контексте Netlink определяется протоколом. Netlink предоставляет механизмы для CPC(находится в пользовательском пространстве) и FEC (находится в ядре), позволяющие им получить свои собственные определения для протокола. Это связано с тем, что пользовательское пространство и ядро находятся на разных уровнях безопасности. Следовательно, для обмена информацией между компонентами требуется протокол. Такой протокол обычно обеспечивается неким привилегированным сервисом, который имеет возможность копирования данных между различными уровнями безопасности. Будем называть такую службу сервисом Netlink. Этот сервис может также инкапсулироваться в протоколы транспортного уровня, если CPC и FEC выполняются на разных узлах. Компоненты FEC и CPC, используя механизмы Netlink, могут выбрать надежный протокол для обмена данными. По умолчанию, однако, Netlink не обеспечивает гарантированного обмена данными.

Отметим, что FEC и CPC могут располагаться на одном уровне защиты памяти и использовать системный вызов connect() для создания прямого пути и обмена информацией через этот путь. В данном документе этот механизм рассматриваться не будет — отметим лишь возможность его реализации. В данном документе предполагается, что FEC является частью ядра, а CPC размещается в пользовательском пространстве. Это не означает однако, что приведенная в документе информация относится лишь к случаю размещения этих компонент в разных областях защиты и не привязывает компоненты к одному узлу.

Отметим, что Netlink позволяет обеим компонентам участвовать в предоставлении сервиса IP.

2.1. Логическая модель Netlink

На приведенном рисунке показана простая диаграмма логических связей между компонентами FEC и CPC. В качестве примера использована FEC пересылки IPv4 (служба NETLINK_ROUTE, описанная ниже).

                    Плоскость управления (CP)
                   .-------------------------------------
                   |    /^^^^^\        /^^^^^\           |
                   |   |       |      / CPC-2 \          |
                   |   | CPC-1 |     | COPS   |          |
                   |   | ospfd |     |  PEP   |          |
                   |   |      /       \____ _/           |
                   |    \____/            |              |
                   |      |               |              |
                *****************************************|
                ******** Широковещательная среда  *********
FE------------- *******************************************.
|     Компонента      |       |            |               |
|     пересылки IPv4  |       |            |               |
|       -------------/ -------|------------|-----------    |
|       |           /         |            |           |   |
|       |     .--------.  .---------.  .---------.     |   |
|       |     |Входная |  | IPv4    |  |Выходной |     |   |
|       |     |политика|  |Пересылка|  | планиров|     |   |
|       |     |________|  |_________|  | QoS     |     |   |
|       |                               ---------      |   |
|        ----------------------------------------------    |
|                                                          |
 ----------------------------------------------------------

Netlink логически моделирует FEC и CPC в форме узлов, связанных между собой через широковещательную среду.

Свойства среды обусловлены сервисом. В приведенном примере показана широковещательная среда, принадлежащая к расширенному сервису пересылки IPv4.

Узлы (CPC и FEC в рассматриваемом примере) подключены к среде передачи и регистрируются для получения сообщений определенных типов. CPC может подключаться к множеству сред, если это способствует более эффективному управлению сервисом. Все узлы (CPC и FEC) принимают пакеты из широковещательной среды. Пакеты могут отбрасываться средой передачи, если они имеют некорректный формат или содержат ошибки. Отброшенные пакеты не поступают ни на один из узлов. Сервис Netlink может передавать отправителю сигналы об ошибках при обнаружении некорректных пакетов Netlink.

Передаваемые в среду пакеты могут быть широковещательными, групповыми или адресованными конкретному узлу. Узлы FEC и CPC регистрируют свою заинтересованность в сообщениях определенного типа для их обработки или простого мониторинга.

В приложениях 1 и 2 приведено более детальное рассмотрение этого взаимодействия.

2.2. Формат сообщений

В сообщениях Netlink существует три уровня — заголовок сообщения Netlink, шаблон IP-сервиса и связанные с IP-сервисом данные.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                  Заголовок сообщения Netlink                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       Шаблон IP-сервиса                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|             Связанные с IP-сервисом данные в TLV              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Сообщения Netlink используются для обмена данными между FEC и CPC, параметризации FEC, асинхронной передачи сведений о событиях FEC компонентам CPC и сбора/просмотра статистики (обычно с помощью CPC).

Заголовок сообщения Netlink используется для всех типов сервиса, тогда как шаблоны (IP Service Template) связаны с конкретными типами сервиса. Каждая служба IP передает данные параметризации (от CPC к FEC) или отклики (от FEC к CPC). Эти данные передаются в формате TLV и являются уникальными для сервиса.

Отдельные компоненты сообщений Netlink подробно рассматриваются ниже.

2.3. Модель протокола

В этом разделе описано как Netlink обеспечивает механизм ориентированного на службы взаимодействия между FEC и CPC.

2.3.1. Адресация служб

Для получения доступа сначала нужно соединиться с сервисом на FE. Соединение организуется путем системного вызова socket() для домена PF_NETLINK. Каждая компонента FEC идентифицируется номером протокола. В результате вызова могут создаваться сокеты типа SOCK_RAW или SOCK_DGRAM, хотя Netlink не различает сокеты этих типов. Соединение с сокетом обеспечивает основу для адресации FE<->CP.

После этого организуется подключение к сервису (в любой момент в течение срока существования соединения) путем ввода обусловленной сервисом команды (от CPC к FEC, в основном для настройки конфигурации), команды сбора статистики или подписки/отказ на уведомления о связанных с сервисом событиях. Закрытие сокета прерывает транзакцию.

Примеры рассматриваются в приложениях 1 и 2.

2.3.2. Заголовок сообщений Netlink

Сообщения Netlink представляют собой поток байтов с одним или несколькими заголовками Netlink и связанными с ними данными (payload). Если данных слишком много для одного сообщения, они могут быть разделены на несколько сообщений Netlink, которые обычно называют многокомпонентным сообщением. Для таких сообщений первый и последующие заголовки, за исключением последнего, содержат флаг NLM_F_MULTI. В заголовке последнего сообщения указывается тип NLMSG_DONE.

Формат заголовка сообщения Netlink показан на рисунке:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Length                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Type              |           Flags              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Process ID (PID)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Заголовок включает следующие поля:

2.3.2.1. Механизмы создания протоколов

Один из способов организации надежного протокола обмена между FEC и CPC является использование комбинации порядковых номеров, ACK и таймеров повтора передачи. Порядковые номера и подтверждения ACK обеспечиваются Netlink, таймеры обеспечиваются ОС Linux.

Можно также создать heartbeat-протокол для обмена между FEC и CPC за счет использования флагов ECHO и сообщений типа NLMSG_NOOP.

2.3.2.2. Сообщение ACK в Netlink

Эти сообщения используются как для передачи подтверждений (ACK), так и для передачи информации об отрицательном результате (NACK). Обычно такие сообщения передаются от FEC к CPC (в ответ на сообщение с запросом подтверждения). Однако CPC должны обеспечивать возможность передачи сообщений ACK в адрес FEC при наличии соответствующего запроса. Семантика этих сообщений специфична для IP-сервиса.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Netlink message header                  |
|                       type = NLMSG_ERROR                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Error code                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Старый заголовок сообщения  Netlink              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Нулевое значение кода ошибки говорит о том, что сообщение является подтверждением успешного результата (ACK). Такие сообщения содержат заголовок исходного сообщения Netlink, который может использоваться для сравнения (например, порядкового номера).

Отличный от нуля код говорит об отрицательном результате (NACK). В таких ситуациях данные Netlink, которые были переданы ядру, возвращаются вместе с исходным заголовком Netlink. Устанавливается также пригодное для вывода с помощью perror() значение кода ошибки(не в заголовке сообщения, а в переменной окружения).

2.3.3. Шаблоны FE системных служб

Существуют системные службы, которые предлагают свой сервис для использования другими службами. Обычно они включают возможность настройки конфигурации, сбора статистики, прослушивание сведений об изменении разделяемых ресурсов, управление адресами IP, канальные события и т. п. Данный раздел включает описание подобных служб для их логического разделения (несмотря на то, что все они доступны через FEC NETLINK_ROUTE). Причина этого заключается в том, что они существуют в NETLINK_ROUTE в силу исторически сложившихся причин (ошибки), связанных с тем, что сокеты BSD 4.4 Route реализованы как часть сокетов пересылки IPv4.

2.3.3.1. Сервисный модуль сетевого интерфейса

Эта служба обеспечивает возможность создания и удаления сетевых интерфейсов, а также получения информации о существующем интерфейсе. Интерфейс может быть физическим или виртуальным и не связан с сетевым протоколом (например, с помощью такого сообщения можно определить интерфейс x.25). Шаблон сообщения показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Family    |   Reserved  |          Device Type              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Interface Index                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Device Flags                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Change Mask                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

К данному типу сервиса относятся сообщения Netlink RTM_NEWLINK, RTM_DELLINK и RTM_GETLINK.

2.3.3.2. Модуль службы адресов IP

Эта служба обеспечивает возможность добавления и удаления адресов, а также получения сведений об IP-адресах, связанных с данным интерфейсом. Шаблон сообщения службы предоставления адресов показан на рисунке:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Family    |     Length    |     Flags     |    Scope      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Interface Index                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Определенные в данный момент IP-службы Netlink

Хотя, как было отмечено выше, существует множество других служб IP, использующих Netlink, в данном документе рассматривается лишь небольшая часть этих служб, интегрированных в ядро версии 2.4.6. К таким службам относятся NETLINK_ROUTE, NETLINK_FIREWALL и NETLINK_ARPD.

3.1. Служба NETLINK_ROUTE

Эта служба позволяет CPC изменять таблицу маршрутизации IPv4 в машине пересылки FE. Кроме того, данный сервис может применяться CPC для получения данных об обновлении маршрутов и сбора статистики.

3.1.1. Модуль службы маршрутизации

Эта служба обеспечивает возможность создания и удаления маршрутов, а также получения информации о сетевых маршрутах. Формат шаблона сообщения показан на рисунке:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Family    |  Src length   |  Dest length  |     TOS       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Table ID   |   Protocol    |     Scope     |     Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Flags                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.2. Модуль учета соседей

Этот сервис обеспечивает возможность добавления и удаления записей о соседях (например, ARP, IPv4 neighbor solicitation и т. п.), а также получения информации о существующих записях таблицы соседей. Шаблон сообщений этой службы показан на рисунке:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Family    |    Reserved1  |           Reserved2           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Interface Index                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           State             |     Flags     |     Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.3. Служба контроля трафика

Этот сервис обеспечивает возможность генерации, запроса и прослушивания событий, связанных с контролем трафика. Эта служба включает дисциплины очередей (планировщики и алгоритмы обслуживания очередей — например, планировщики на основе уровней приоритета или алгоритм RED) и классификаторы трафика. Система управления трафиком в Linux обеспечивает высокий уровень гибкости о поддерживает иерархическое каскадирование различных блоков для совместного использования ресурсов каналов передачи трафика.

       ++    ++                 +-----+   +-------+   ++     ++ .++
       || .  ||     +------+    |     |-->| Qdisc |-->||     ||  ||
       ||    ||---->|Фильтр|--->|Класс|   +-------+   ||-+   ||  ||
       ||    ||  |  +------+    |     +---------------+| |   ||  ||
       || .  ||  |              +----------------------+ |   || .||
       || .  ||  |  +------+                             |   ||  ||
       ||    ||  +->|Фильтр|-_  +-----+   +-------+   ++ |   || .||
       || -->||  |  +------+  ->|     |-->| Qdisc |-->|| |   ||->||
       || .  ||  |              |Класс|   +-------+   ||-+-->|| .||
->dev->||    ||  |  +------+ _->|     +---------------+|     ||  ||
       ||    ||  +->|Фильтр|-   +----------------------+     || .||
       ||    ||     +------+                                 || .||
       || .  |+----------------------------------------------+|  ||
       ||    |        Родительская дисциплина очередей        | .||
       || .  +------------------------------------------------+ .||
       || . . .. . . .. . .                 . .. .. .. .      .. ||
       |+--------------------------------------------------------+|
       |             Родительская дисциплина очередей             |
       |             (связана с выходным устройством)             |
       +----------------------------------------------------------+

На приведенном рисунке показана пример схемы выходного блока TC. В этом документе приводится весьма краткое рассмотрение этого вопроса; дополнительную информацию можно найти на сайте [11]. Пакет сначала проходит через фильтр, используемый для идентификации класса трафика, к которому может быть отнесен данный пакет. Термин «класс» относится к дисциплинам очередей и связан с конкретной очередью. Очередь может использовать простой алгоритм (например, FIFO) или более сложные механизмы типа RED или token bucket. Дисциплину очереди, наиболее удаленную от родительской дисциплины, обычно называют планировщиком. В показанной здесь иерархии планировщик может включать различные алгоритмы планирования, что делает системы управления трафиком на выходе в ОС Linux очень гибкими.

Шаблон сообщения для этого типа сервиса показан ниже. Этот шаблон используется для дисциплин входных и выходных очередей (относительно модели управления трафиком на выходе, описанной в разделе для модели FE на стр. 3). Каждая специфическая компонента модели имеет уникальные атрибуты, описывающие ее наилучшим способом. Атрибуты общего назначения рассматриваются ниже.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Family    |  Reserved1    |         Reserved2             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Interface Index                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Qdisc handle                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Parent Qdisc                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        TCM Info                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2. Служба NETLINK_FIREWALL

Эта служба позволяет CPC принимать пакеты через сервисные модули межсетевого экрана IPv4 в FE, манипулировать этими пакетами и повторно передавать их. Правило межсетевого экрана является первым из числа вставляемых для активизации перенаправления пакетов. CPC информирует FEC о своем желании получать метаданные для пакета или реальные данные из него, а также сообщает максимальный размер данных, которые будут перенаправляться. Перенаправленные пакеты по-прежнему сохраняются в FEC, ожидая решения о своей судьбе от CPC. Решение может быть простой командой на восприятие или отбрасывание пакета (в этом случае решение применяется к пакету, все еще находящемуся в FEC) или включать измененный пакет, который должен быть передан взамен исходного.

Существует два типа сообщений, передаваемых от CPC к FEC — Mode (режим) и Verdict (решение). Сообщения типа Mode незамедлительно передаются FEC и сообщают о том, что CPC желает принимать от FEC. Сообщения типа Verdict передаются FEC после принятия решения о дальнейшей судьбе полученного пакета. Формат сообщений рассматривается ниже.

Опишем сначала сообщение, указывающее режим.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Mode    |    Reserved1  |           Reserved2             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Range                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Пакет и связанные с ним метаданные, полученные из пользовательского пространства, показаны на рисунке:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Packet ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Mark                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       timestamp_m                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       timestamp_u                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          hook                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       indev_name                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       outdev_name                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           hw_protocol       |        hw_type                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         hw_addrlen          |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       hw_addr                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       data_len                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Payload . . .                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Формат сообщений типа Verdict показан на рисунке:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Value                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Packet ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Data Length                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Payload . . .                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3. Служба NETLINK_ARPD

Этот сервис используется CPC для поддержки таблицы соседей в FE. Формат сообщений, передаваемых между FEC и CPC, описан параграфе, посвященном службе учета соседей (стр. 10).

Предполагается, что сервис CPC принимает участие в работе протоколов организации соседских отношений (neighbor solicitation protocol).

Сообщение типа RTM_NEWNEIGH передается CPC от FE для информирования CPC об изменениях, которые могут произойти с записью для этого соседа.

Сообщения RTM_GETNEIGH используются для получения информации о конкретном соседе.

4. Литература

4.1. Нормативные документы

  1. Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
  2. Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  3. Blake, S., Black, D., Carlson, M., Davies, E, Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998
  4. Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
  5. Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
  6. Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990
  7. Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
  8. Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for DiffServ Routers", RFC 3290, May 2002.

4.2. Дополнительная литература

  1. G. R. Wright, W. Richard Stevens. "TCP/IP Illustrated Volume 2, Chapter 20", June 1995.

5. Вопросы безопасности

Netlink работает в безопасной среде (trusted environment) на одном хосте с разделением ядра и пользовательского пространства. Средствами Linux обеспечивается возможность открывать сокет только для процессов с флагом возможностей CAP_NET_ADMIN (обычно процессы, запущенные пользователем root).

6. Благодарности

  1. Andi Kleen за страницы руководства (man pages) для netlink и rtnetlink.
  2. Alexey Kuznetsov за добавление модели службы доставки IP в Netlink. Исходный вариант символьного устройства Netlink создал Alan Cox.
  3. Jeremy Ethridge за исполнение роли «непонимающего Netlink»и обзор документа с точки зрения его восприятия.

Приложение 1: Пример иерархии служб

На рисунке показан пример единичного IP-сервиса foo и взаимодействие компонент CP и FE для этой службы (метки 1-3).

Эта схема используется так же как пример адресации CP<->FE. В этом приложении иллюстрируется только семантика адресации. В Приложении 2 эта схема рассматривается с точки зрения протокольного взаимодействия между компонентами CPC и FEC сервиса (метки 4-10).

 CP
[--------------------------------------------------------.
|   .-----.                                              |
|  |                         . -------.                  |
|  |  CLI   |               /           \                |
|  |        |              | Протокольная|               |
|         /->> -.          |  компонента | <-.           |
|    __ _/      |          |  CP для IP- |   |           |
|                |         | службы foo  |   ^           |
|                Y         |             |   |           |
|                |           ___________/    ^           |
|                Y   1,4,6,8,9 /  ^ 2,5,10   | 3,7       |
 --------------- Y------------/---|----------|-----------
                 |           ^    |          ^
               **|***********|****|**********|**********
               ************* Уровень Netlink ***********
               **|***********|****|**********|**********
       FE        |           |    ^          ^
       .-------- Y-----------Y----|--------- |----.
       |                    |              /      |
       |                    Y            /        |
       |          . --------^-------.  /          |
       |          | Компонента/модуль |/          |
       |          | FE для IP-службы  |           |
--->---|------>---| foo               |----->-----|------>--
       |           -------------------            |
       |                                          |
       |                                          |
        ------------------------------------------

Протокол плоскости управления для IP-службы foo выполняет перечисленные ниже операции для подключения к FE (нумерация в списке соответствует номерам на рисунке).

  1. Подключение к IP-сервису foo через сокет. Обычно соединение организуется с помощью вызова socket(AF_NETLINK, SOCK_RAW, NETLINK_FOO).
  2. Привязка с целью прослушивания специфических асинхронных событий для сервиса foo.
  3. Привязка с целью прослушивания специфических асинхронных событий FE.

Приложение 2: Пример протокола для IP-службы Foo

В этом примере IP-сервис foo используется теперь для демонстрации простого управления сервисом IP с использованием Netlink.

Этапы этого управления осуществляются после операций, указанных в Приложении 1 и списки используют общую нумерацию.

  1. Запрашивается текущая конфигурация компоненты FE.
  2. Принимается отклик на запрос (4) через канал, организованный на этапе (3).
  3. запрашивается текущее состояние IP-сервиса foo.
  4. Принимается отклик на запрос (6) через канал (2).
  5. регистрируются связанные с протоколом пакеты, которые хочется получать от FE.
  6. Передаются специфические для данной службы команды foo и (при необходимости) принимаются отклики на них.

Приложение 2a: Взаимодействие с другими службами IP

На схеме в Приложении 1 показана другая компонента, которая может конфигурировать тот же сервис. В данном случае это фирменный командный интерфейс CLI. Интерфейс CLI может или не может использоваться Netlink для взаимодействия с компонентами foo. Если CLI дает команды, которые оказывают влияние на политику FEC для сервиса foo компонента CPC получает уведомления об этом. На основе этих уведомлений может приниматься решение. Например, если FE позволяет другому сервису удалять правила, установленные иной службой и установленные foo правила были удалены сервисом bar, может возникнуть необходимость распространить это всем партнерам службы foo.

Приложение 3: Примеры

В этом примере рассматривается простое конфигурационное сообщение Netlink, передаваемое от TC CPC выходной очереди TC FIFO. Этот алгоритм управления очередью основан на учете пакетов и отбрасывании пакетов при достижении порогового значения 100. Предполагается, что очередь находится в иерархии с родителем Parent = 100:0 и Classid = 100:1 и размещается на устройстве с ifindex = 4.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Length (52)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (RTM_NEWQDISC)           | Flags (NLM_F_EXCL |         |
|                               |NLM_F_CREATE | NLM_F_REQUEST)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Sequence Number(произвольное значение)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Process ID (0)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Family(AF_INET)|  Reserved1    |         Reserved1           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Interface Index  (4)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Qdisc handle  (0x1000001)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Parent Qdisc   (0x1000000)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        TCM Info  (0)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Type (TCA_KIND)   |           Length(4)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Value ("pfifo")                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Type (TCA_OPTIONS) |          Length(4)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Value (limit=100)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Адреса авторов

Jamal Hadi Salim
Znyx Networks
Ottawa, Ontario Canada
EMail: moc.xynz@idah

Hormuzd M Khosravi
Intel
2111 N.E. 25th Avenue JF3-206
Hillsboro OR 97124-5961 USA
Phone: +1 503 264 0334
EMail: moc.letni@ivarsohk.m.dzumroh

Andi Kleen
SuSE
Stahlgruberring 28
81829 Muenchen Germany
EMail: ed.esus@ka

Alexey Kuznetsov
INR/Swsoft
Moscow Russia
EMail: ur.ca.rni.2sm@tenzuk

Перевод на русский язык

Николай Малых, moc.milib@hkylamn