Network Working Group                                                                                             J. Salim
Request for Comments: 3549                                                                       Znyx Networks
Category: Informational                                                                                  H. Khosravi
Intel
A. Kleen
Suse
A. Kuznetsov
INR/Swsoft
July 2003
Netlink как протокол для служб IP
Linux Netlink as an IP Services Protocol
Статус документа
Этот документ содержит информацию, предназначенную для сообщества Internet, и не задает каких-либо стандартов Internet. До­кумент может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2003). All Rights Reserved.
Тезисы
Данный документ описывает интерфейс Netlink ОС Linux, который используется операционной системой для обмена сообщения­ми как между процессами ядра, так и между ядром и пользовательскими процессами. Основное внимание в документе уделяется описанию функциональности Netlink как протокола, связывающего компоненты FEC1 и CPC2, которые определяют работу сервиса IP. Прочие варианты использования Netlink, включая обмен сообщениями внутри ядра и между процессами IPC3), а также на­стройка конфигурации служб, не относящихся к IP (несетевые службы или сетевые службы других протоколов), в данном доку­менте не рассматриваются.
Документ предназначен для создания информационного контекста на начальном этапе работы группы ForCES4 IETF.
1 Forwarding Engine Component
машина пересылки.
2 Control Plane Component
3 Inter-process communication – обмен информацией между процессами.
4 Forwarding & Control Element Separation – разделение функций пересылки и управления. Страница рабочей группы доступна по
Перевод RFC 3549
Оглавление
1. Введение ................................................................................................................................................................................ ...... .................... 3
1.1. Определения ....................................................................................................................................................................................... 3...
1.1.1. Компоненты CPC ................................................................................................................................................................... ...3...
1.1.2. Компоненты FEC .................................................................................................................................................. ..................... 3
1.1.2.1. Модель машины пересылки IP в Linux .............................................................................................................. ....... ..... 3
1.1.3. Службы IP ................................................................................................................................................................. ................. 4
2. Архитектура Netlink ........................................................................................................................................................................... ...... .....4
2.1. Логическая модель Netlink ........................................................................................................................................................ ..........5
2.2. Формат сообщений ........................................................................................................................................................................... .5.
2.3. Модель протокола ..................................................................................................................................................... ........ .................... 5
2.3.1. Адресация служб .............................................................................................................................................................. ........ 5
2.3.2. Заголовок сообщений Netlink ............................................................................................................................. ..... .. ................ 6
2.3.2.1. Механизмы создания протоколов ..................................................................................................................... ............ 7
2.3.2.2. Сообщение ACK в Netlink ........................................................................................................................... ..... .. .............. 7
2.3.3. Шаблоны FE системных служб .......................................................................................................................................... .....7.
2.3.3.1. Сервисный модуль сетевого интерфейса ................................................................................................................... ...7. .
2.3.3.2. Модуль службы адресов IP ...................................................................................................................................... ...... 8
3. Определенные в данный момент IP-службы Netlink .............................................................................................................................. 9...
3.1. Служба NETLINK_ROUTE ............................................................................................................................................................. ....9...
3.1.1. Модуль службы маршрутизации ...................................................................................................................................... ...... 9
3.1.2. Модуль учета соседей ............................................................................................................................................................ 10
3.1.3. Служба контроля трафика ................................................................................................................................................. ....11
3.2. Служба NETLINK_FIREWALL .................................................................................................................................................. ....12
3.3. Служба NETLINK_ARPD .................................................................................................................................................. .............. 13
4.  Литература ...................................................................................................................................................................................... ........... 14
4.1. Нормативные документы ................................................................................................................................................................ 1. .4...
4.2. Дополнительная литература ........................................................................................................................................................... 1..4...
5. Вопросы безопасности ................................................................................................................................................... ...... .. ..................... 14
6. Благодарности ..................................................................................................................................................................................... ........ 14
Приложение 1: Пример иерархии служб ................................................................................................................................... .. ................. 14
Приложение 2: Пример протокола для IP-службы Foo ........................................................................................................................... .1..5.
Приложение 2a: Взаимодействие с другими службами IP ................................................................................................................. 1. .5. .
Приложение 3: Примеры ............................................................................................................................................................. .. ................. 15
rfc.com.ru                                                                                     2                                                            rfc.com.ru
Перевод RFC 3549
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. Определения
CP5 представляет собой среду исполнения, которая может иметь несколько субкомпонент, которые будут обозначаться как CPC6. Все CPC, обеспечивающие контроль для разных служб IP, будут выполняться посредством машины пересылки FE7. Такие отноше­ния между компонентами означают возможность наличия нескольких CPC для одной физической CP, если они контролируют несколько служб IP. По сути, связь между CP и FE является абстракцией сервиса.
1.1.1. Компоненты CPC
Компоненты управляющего плана CPC включают сигнальные протоколы от динамических протоколов маршрутизации (напри­мер, OSPF [5]) до протоколов распространения тегов (например, CR-LDP [7]). Классические протоколы и операции управления также входят в эту категорию. Среди них такие механизмы, как SNMP [6], COPS [4] и фирменные средства настройки конфигура­ции CLI/GUI. Задача управляющего плана состоит в обеспечении среды исполнения для перечисленных действий с целью на­стройки конфигурации и управления второй компонентой элемента сети (NE8) - машиной пересылки FE. Результат настройки кон­фигурации определяет способ трактовки пакетов, проходящих через FE.
1.1.2. Компоненты FEC9
Машина пересылки FE представляет собой объект NE, который первым получает сетевые пакеты (из сети в NE).
Связанная с сервисом компонента FE просматривает пакет с целью обеспечения для него обработки, определенной компонентами CPC для данного типа сервиса IP. Различные службы будут использовать различные компоненты FEC. Сервисные модули могут объединяться в цепочки для поддержки более сложных типов сервиса (в рамках описанной ниже модели Linux FE).
Будучи созданной для поддержки конкретной службы, сервисная компонента FE будет по-прежнему соответствовать принципам модели пересылки.
1.1.2.1. Модель машины пересылки IP в Linux
На рисунке справа по­казана модель Linux FE для отдельного устрой­ства. Единственной обязательной частью этой модели является модуль         пересылки
(Пересылка), соответ­ствующий RFC 1812. Различные модули се­тевого экранирования (FW), управления вхо­дящим и исходящим трафиком (TC10) не яв­ляются обязательными и могут даже использо­ваться для обхода мо­дуля RFC 1812. Эти мо­дули показаны в виде
+
1
+
------------
TCP, UDP, .
---+
+->-| FW |--->
| +----+
1
л
.. |
1
V
1
+----<----+
1
_1_
I FW |
+----+
Л
1
1 Y
В сетевой
Из сетевого
стек хоста стека хоста 1 1 1
Приемное
Y
устройство ____
+-------+ +
->|Входной|-->---->|
|---|--+ _ Пере- |->|
___ + -------- + Выходное
->----->| EW |-
FW |->|Выходной| устройство
+----+
1 ТС |
1
сыпка | +-
---+ | ТС |>
+-------+
+
-------+
+--------+
простых блоков на
пути передачи данных и, фактически, могут представлять собой каскады из множества субмодулей. Дополнительную информа­цию о таких модулях вы найдете на сайтах [10] и [11].
Пакеты, прибывающее на входное устройство, сначала проходят через модуль межсетевого экранирования (FW), который может отбрасывать (drop) и изменять (mangle) пакеты или выполнять с ними иные операции. После прохождения модуля FW входящие пакеты в зависимости от принятой политики, могут попадать во входной модуль контроля трафика TC, который выполняет опера­ции по измерению и регулированию потоков входящего трафика. Пакеты могут отбрасываться входным модулем TC в зависимо-
5 Control Plane – плоскость управления
6  Control Plane Components – компоненты управляющего плана.
7  Forwarding Engine – машина пересылки.
8  Network Element
9  Forwarding Engine Components – компоненты машины пересылки.
10 Traffic Control – контроль трафика.
rfc.com.ru                                                                          3                                                                        rfc.com.ru
Перевод RFC 3549
сти от результатов измерения уровня трафика и принятой политики. После этого пакет передается единственному обязательному модулю, который обеспечивает пересылку в соответствии с требованиями 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 может служить классическая пересылка11 IPv4. В этом случае управляющие компоненты (протоко­лы маршрутизации OSPF, RIP и т. п.) и фирменные средства настройки конфигурации CLI/GUI изменяют таблицы пересылки FE для того, чтобы обеспечить простой сервис по пересылке пакетов на следующий интервал (next hop). Обычно NE, обеспечиваю­щие такой сервис, называют маршрутизаторами.
На приведенном справа рисунке по­казан простой пример реализации FE<->CP для обеспечения классиче­ской пересылки IPv4 с некоторыми дополнительными функциями QoS для управления выходными очередя­ми.
Демон ospfd управляет работой про­токола OSPF, а COPS PEP12 пред­ставляет собой дополнительную компоненту CPC. Компонента IPv4 FE включает модуль пересылки IPv4,
Плоскость управления (CP)
/лллл лл\
I                         I
I ospfd | \ / -\ /
/
l-\
| COPS | PEP \ _____
|
|
I
Машина
I                               I              I
******************************************
************* СбТбВОИ V1DOB6Hb ************ *************
пересыл
а также модуль выходного планиров­щика QoS. В качестве дополнитель­ной службы может быть добавлен сервис пересылки на основе правил между модулем пересылки IPv4 и
------- | ---------
Сервисная компо­нента FE для пересылки IPv4
-/-
/
---| -------
Выходной планировщик
QoS
I I >l
выход
пакета
--->|->
модулем планировщика QoS. Про-
вход
пакета
-->--->
|
-------- |--
|Пересылка ->| IPv4 |
->l
стейший классический вариант будет включать только модуль пересылки IPv4.
Опыт использования сетей говорит о
важности добавления в маршрутиза-
торы новых типов сервиса, удовле-
I
творяющих современным требовани-
ям. Для решения этих задач были со-зсдлаунжыб ы ,и ко тсотраындеа рмтоигзуотв авныых о динтоьв ыз еа                              -----------------------------------------------------------------------------------------------
пределы содержимого заголовков сетевого уровня. Однако, для обеспечивающих пересылку пакетов устройств NE по-прежнему используется термин “маршрутизатор”. Новые службы (которые могут выходить за классические пределы заголовков L3) включа­ют межсетевое экранирование, QoS с использованием Diffserv и RSVP, NAT, маршрутизацию на базе правил и т. п. Для таких служб создаются новые протоколы и средства управления.
Одним из экстремистских определений сервиса IP является “все, за что сервис-провайдеры могут взять деньги”.
2. Архитектура Netlink
Управление компонентами IP-сервиса определяется с использованием шаблонов.
Компоненты FEC и CPC участвуют в предоставлении услуг IP-сервиса путем обмена данными с использованием таких шаблонов. FEC может непрерывно получать обновления от компоненты CPC, указывающие как предоставлять услуги (например, для пере­сылки пакетов IPv4, добавления, удаления или изменения маршрутов).
Взаимодействие между FEC и CPC в контексте Netlink определяется протоколом. Netlink предоставляет механизмы для CPC(нахо-дится в пользовательском пространстве) и FEC (находится в ядре), позволяющие им получить свои собственные определения для протокола. Это связано с тем, что пользовательское пространство и ядро находятся на разных уровнях безопасности. Следователь­но, для обмена информацией между компонентами требуется протокол. Такой протокол обычно обеспечивается неким привилеги­рованным сервисом, который имеет возможность копирования данных между различными уровнями безопасности. Будем назы-
11 Forwarding
12 Policy Enforcement Point
точка реализации политики.
4
Перевод RFC 3549
вать такую службу сервисом Netlink. Этот сервис может также инкапсулироваться в протоколы транспортного уровня, если CPC и FEC выполняются на разных узлах. Компоненты FEC и CPC, используя механизмы Netlink, могут выбрать надежный протокол для обмена данными. По умолчанию, однако, Netlink не обеспечивает гарантированного обмена данными.
Отметим, что FEC и CPC могут располагаться на одном уровне защиты памяти и использовать системный вызов connect() для со­здания прямого пути и обмена информацией через этот путь. В данном документе этот механизм рассматриваться не будет – отме­тим лишь возможность его реализации. В данном документе предполагается, что FEC является частью ядра, а CPC размещается в пользовательском пространстве. Это не означает однако, что приведенная в документе информация относится лишь к случаю раз­мещения этих компонент в разных областях защиты и не привязывает компоненты к одному узлу.
Отметим, что Netlink позволяет обеим компонентам участвовать в предоставлении сервиса IP.
2.1. Логическая модель Netlink
На приведенном рисунке показана простая диаграм­ма логических связей между компонентами FEC и CPC. В качестве примера использована FEC пересыл­ки IPv4 (служба NETLINK_ROUTE, описанная ниже).
Netlink логически моделирует FEC и CPC в форме узлов, связанных между собой через широковеща­тельную среду.
Свойства среды обусловлены сервисом. В приведен­ном примере показана широковещательная среда, принадлежащая к расширенному сервису пересылки IPv4.
Плоскость управления (CP)
/лл лл л\
I                      I
| СРС-1 |
I ospfd |
|            /
\ /
/ЛЛ лл л\
/ СРС-2 \ | COPS | I PEP |
\_______/
I
FE-
|                                |
****************************************| ******** Широковещательная среда ********
Компонента
I
I
I
пересылки IPv4 | | | --------------/ ----|-----------|--------
Узлы (CPC и FEC в рассматриваемом примере) под-
/
I
I
ключены к среде передачи и регистрируются для по-
|Входная | |Пересылка| |Выходной| |политика| | IPv4 | |планиров| | ________ | | _________ | | QoS |
лучения сообщений определенных типов. CPC может подключаться к множеству сред, если это способ­ствует более эффективному управлению сервисом.
Все узлы (CPC и FEC) принимают пакеты из широко­вещательной среды. Пакеты могут отбрасываться средой передачи, если они имеют некорректный фор­
мат или содержат ошибки. Отброшенные пакеты не
поступают ни на один из узлов. Сервис Netlink может передавать отправителю сигналы об ошибках при обнаружении некорректных пакетов Netlink.
Передаваемые в среду пакеты могут быть широковещательными, групповыми или адресованными конкретному узлу. Узлы FEC и CPC регистрируют свою заинтересованность в сообщениях определенного типа для их обработки или простого мониторинга.
В приложениях 1 и 2 приведено более детальное рассмотрение этого взаимодействия.
2.2. Формат сообщений
В сообщениях Netlink существует три     0                                       1                                       2                                       3
уровня - заголовок сообщения Netlink,      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
шаблон IP-сервиса и связанные с IP-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ сервисом данные.
Сообщения Netlink используются для обмена данными между FEC и CPC, па­раметризации FEC, асинхронной пере­дачи сведений о событиях FEC компо­нентам CPC и сбора/просмотра стати­стики (обычно с помощью CPC).
Заголовок сообщения Netlink использу­ется для всех типов сервиса, тогда как шаблоны (IP Service Template) связаны
|                                         Заголовок сообщения Netlink                                     |
|                                                                                                                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                                                                                                                                        |
|                                                  Шаблон IP-сервиса                                                  |
|                                                                                                                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |                                                                                                                                        |
|                              Связанные с IP-сервисом данные в TLV                            |
|                                                                                                                                        |
с конкретными типами сервиса. Каждая +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ служба IP передает данные параметри­зации (от CPC к FEC) или отклики (от FEC к CPC). Эти данные передаются в формате TLV13 и являются уникальными для сервиса.
Отдельные компоненты сообщений Netlink подробно рассматриваются ниже.
2.3. Модель протокола
В этом разделе описано как Netlink обеспечивает механизм ориентированного на службы взаимодействия между FEC и CPC.
2.3.1. Адресация служб
Для получения доступа сначала нужно соединиться с сервисом на FE. Соединение организуется путем системного вызова socket() для домена PF_NETLINK. Каждая компонента FEC идентифицируется номером протокола. В результате вызова могут создаваться сокеты типа SOCK_RAW или SOCK_DGRAM, хотя Netlink не различает сокеты этих типов. Соединение с сокетом обеспечивает основу для адресации FE<->CP.
После этого организуется подключение к сервису (в любой момент в течение срока существования соединения) путем ввода обу­словленной сервисом команды (от CPC к FEC, в основном для настройки конфигурации), команды сбора статистики или под­писки/отказ на уведомления о связанных с сервисом событиях. Закрытие сокета прерывает транзакцию.
13 Type-Length-Value
тип-размер-значение
5
Перевод RFC 3549
Примеры рассматриваются в приложениях 1 и 2.
2.3.2. Заголовок сообщений Netlink
Сообщения Netlink представляют собой поток байтов с одним или несколькими заголовками Netlink и связанными с ними данны­ми (payload). Если данных слишком много для одного сообщения, они могут быть разделены на несколько сообщений Netlink, ко­торые обычно называют многокомпонентным сообщением14. Для таких сообщений первый и последующие заголовки, за исключе­нием последнего, содержат флаг NLM_F_MULTI. В заголовке последнего сообщения указывается тип NLMSG_DONE.
Формат заголовка сообщения Netlink пока­зан на рисунке справа.
Заголовок включает следующие поля:
Length - 32 бита
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)                                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
размер сообщения в байтах с учетом заго­ловка .
Type - 16 битов
Это поле определяет тип содержимого в сообщении.
Фактически поле может включать один из стандартных идентификаторов типа:
NLMSG_NOOP Сообщение игнорируется.
NLMSG_ERROR Сообщение сигнализирует об ошибке и поле данных содержит структуру nlmsgerr. Такие сообщения обычно передаются от FEC к CPC и могут рассматриваться как NACK15.
NLMSG_DONE Сообщение является последней частью многокомпонентного сообщения.
Отдельные службы IP могут использовать добавочные типы сообщений, например сервис NETLINK_ROUTE задает несколько та­ких типов, включая RTM_NEWLINK, RTM_DELLINK, RTM_GETLINK, RTM_NEWADDR, RTM_DELADDR, RTM_NEWROUTE, RTM_DELROUTE и др.
Flags - 16 битов
Стандартные флаги, используемые в заголовках Netlink, приведены в таблице
NLM_F_REQUEST Этот флаг должен устанавливаться для всех откликов (обычно они передаются из пользовательского про­странства в ядро).
NLM_F_MULTI
NLM_F_ACK
NLM_F_ECHO
Сообщение является частью (не последней) многокомпонентного сообщения. Для последней части указы­вается тип NLMSG_DONE.
Запрос на подтверждение при успехе. Обычно этот флаг устанавливается для сообщений из пользователь­ского пространства (CPC) в ядро (FEC).
Возвратить “эхо” для данного запроса. Обычно этот флаг устанавливается для сообщений из пользователь-
ского пространства (CPC) в ядро (FEC).
В запросах GET для конфигурационной информации, передаваемых в FEC используются дополнительные флаги.
NLM_F_ROOT
Возвращать полную таблицу вместо одной записи.
NLM_F_MATCH Возвращать все записи, соответствующие критерию, переданному в поле данных сообщения.
NLM_F_ATOMIC Возвращать атомарную картину (atomic snapshot) таблицы, которая указана. Установка этого флага может требовать специальных привилегий, поскольку флаг способен прерывать сервис FE на достаточно продол­жительное время.
Подходящим макросом для поля флагов является
NLM_F_DUMP = NLM_F_ROOT OR NLM_F_MATCH
В запросах NEW также могут использоваться дополнительные флаги.
NLM_F_REPLACE Заменить существующий объект конфигурации в соответствии с данным запросом.
NLM_F_EXCL          Не заменять существующий объект новым.
NLM_F_CREATE Создать объект конфигурации, если его не существует. NLM_F_APPEND Добавить объект в конце списка имеющихся.
Для тех, кто хорошо знаком с операциями на сокетах маршрутизации BSD в таблице справа приведены эквиваленты таких опера­ций:
Sequence Number - 32 бита
порядковый номер сообщения.
Process ID (PID) - 32 бита
Идентификатор процесса (PID), передающего сообщение. Значение PID используется ядром для мультиплексирования в корректный сокет. При передаче сообщений из ядра в пользовательское пространство устанавли­
BSD
Netlink
ADD
NLM_F_CREATE OR NLM_F_EXCL
CHANGE
NLM_F_REPLACE
Check
NLM_F_EXCL
APPEND
NLM_F_CREATE
вается PID = 0.
14 multipart message
15 Подтверждение отрицательного результата
Negative ACK. Прим. перев.
6
Перевод RFC 3549
2.3.2.1. Механизмы создания протоколов
Один из способов организации надежного протокола обмена между FEC и CPC является использование комбинации порядковых номеров, ACK16 и таймеров повтора передачи. Порядковые номера и подтверждения ACK обеспечиваются Netlink, таймеры обес­печиваются ОС Linux.
Можно также создать heartbeat-протокол для обмена между FEC и CPC за счет использования флагов ECHO и сообщений типа NLMSG_NOOP.
2.3.2.2. Сообщение ACK в Netlink
Эти сообщения используются как для      0 1 2 3
передачи подтверждений (ACK), так и      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
для передачи информации об отрица-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
тельном результате (NACK). Обычно    | Netlink message header |
такие сообщения передаются от FEC к   | type = NLMSG_ERROR |
CPC (в ответ на сообщение с запросом    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
подтверждения). Однако CPC должны    | Error code |
обеспечивать возможность передачи со-   +-+-+-+-+-+-+-0.00pt 0.00pt 56.88pt; text-align:left;">подтверждения). Однако CPC должны    | Error code |
обеспечивать возможность передачи со-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
общений ACK в адрес FEC при наличии    | Старый заголовок сообщения Netlink |
соответствующего запроса. Семантика    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ этих сообщений специфична для IP-сер-виса.
Error code - integer (обычно 32 бита)
Нулевое значение кода ошибки говорит о том, что сообщение является подтверждением успешного результата (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. Сервисный модуль сетевого интерфейса
Эта служба обеспечивает возможность      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 |
(например, с помощью такого сообще-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ния можно определить интерфейс x.25).   | Device Flags |
Шаблон сообщения показан на рисунке    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
справа.                                                       | Change Mask |
Family - 8 битов                                         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Это поле всегда имеет значение AF_UNSPEC.
Device Type - 16 битов
Определяет тип канала (Ethernet, туннель и т. п.). В данном документе рассматривается только IPv4, хотя тип канала не зависит от протокола L3.
Interface Index - 32 бита
Уникальный идентификатор интерфейса.
Device Flags - 32 бита
Флаги интерфейса, перечисленные в таблице.
16 Подтверждений
rfc.com.ru                                                                          7                                                                        rfc.com.ru
Перевод RFC 3549
Флаг
Значение
Флаг
IFFUP
Интерфейс активизирован администрато­ром
IFF_NOTRAILERS
IFF_BROADCAST
Установлен корректный широковеща­тельный адрес.
IFF_ALLMULTI
IFF_DEBUG
Флаг режима отладки для интерфейса.
IFFJMASTER
IFF_LOOPBACK
Петлевой интерфейс (loopback).
IFF_SLAVE
IFF_POINTOPOINT
Интерфейс типа “точка-точка”.
IFFJMULTICAST
Значение
ров.
Принимать все пакеты с групповыми ад­ресами.
Ведущий интерфейс для транка с распре­делением нагрузки.
Ведомый интерфейс для транка с распре­делением нагрузки.
Поддержка групповой адресации.
Интерфейс может выбирать тип среды с помощью ifmap.
IFF_RUNNING           Интерфейс находится в работающем со- IFF_PORTSEL
стоянии.
IFF_NOARP IFF PROMISC
Для интерфейса не требуется протокол IFF_AUTOMEDIA Активизирован ARP.                                                                                             типа среды.
автоматический выбор
Интерфейс работает в режиме захвата17. IFF_DYNAMIC
Интерфейс создан в динамическом режи­ме.
Change Mask - 32 бита
Зарезервированное поле, которое должно иметь значение 0xFFFFFFFF.
Применимые к данному сервису атрибуты перечислены в таблице.
Атрибут                                    Описание                              Атрибут
IFLA_UNSPEC          Не определен.                                             IFLA_MTU
IFLA_ADDRESS Аппаратный адрес интерфейса на уровне IFLA_LINK L2.
IFLA_BROADCAST Аппаратный широковещательный адрес IFLA_QDISC интерфейса на уровне L2.
Описание
Значение MTU для устройства
Значение ifindex для канала, к которому под­ключено устройство.
Строка ASCII, указывающая имя дисциплины управления выходными очередями18.
IFLA_IFNAME          Имя устройства (строка ASCII).                  IFLA_STATS Статистикаock style=" width:594.96pt; height:9.60pt;">
2.3.3.2. Модуль службы адресов IP
Эта служба обеспечивает возможность до­бавления и удаления адресов, а также по­лучения сведений об IP-адресах, связан­ных с данным интерфейсом. Шаблон сооб­щения службы предоставления адресов19 показан на рисунке справа.
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                                                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family - 8 битов
Идентификатор семейства адресов: AF_INET для IPv4 и AF_INET6 для IPv6.
Length - 8 битов
Размер маски адреса.
Flags - 8 битов
Флаг IFA_F_SECONDARY IFA_F_PERMANENT
Описание
Вторичный адрес (псевдоним интерфейса)
Постоянный адрес, установленный пользователем. Отсутствие этого флага говорит о динамическом вы­делении адреса (например, с помощью системы автоматической настройки конфигурации)
IFA_F_DEPRECATED Недействующий (deprecated) адрес IP.
IFA_F_TENTATIVE Предполагаемый (tentative) адрес IP. Процедура обнаружения дубликатов адресов находится в стадии разработки.
Scope - 8 битов
Область корректности адреса.
SCOPE_UNIVERSE Адрес глобального действия.
SCOPE_SITE              Адрес корректен в пределах данного сайта (только для IPv6).
SCOPE_LINK
SCOPE_HOST
Адрес имеет смысл только для данного устройства. Адрес имеет смысл только для данного хоста.
Атрибуты сервиса перечислены в таблице.
17 promiscuous mode.
18 egress root queuing discipline.
19 address provisioning service.
8
Перевод RFC 3549
Атрибут                              Описание                                 Атрибут                                         Описание
IFA_UNSPEC Не определен.                                          IFA_BROADCAST Широковещательный адрес для протокола RAW.
IFA_ADDRESS Адрес интерфейса для протокола RAW. IFA_ANYCAST Anycast-адрес для протокола RAW.
IFA_LOCAL Локальный адрес для протокола RAW. IFA_CACHEINFO Кэшированная информация об адресе.
IFA_LABEL Имя интерфейса (строка ASCII). К данному типу сервиса относятся сообщения Netlink RTM_NEWADDR, RTM_DELADDR и RTM_GETADDR.
3. Определенные в данный момент IP-службы Netlink
Хотя, как было отмечено выше, существует множество других служб IP, использующих Netlink, в данном документе рассматрива­ется лишь небольшая часть этих служб, интегрированных в ядро версии 2.4.6. К таким службам относятся NETLINK_ROUTE, NETLINK_FIREWALL и NETLINK_ARPD20.
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 |
на рисунке справа.                                         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Family - 8 битов                                             | Table ID | Protocol | Scope | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Идентификатор семейства адресов:    |                                                        Flags                                                                 |
AF_INET для IPv4 и AF_INET6 для IPv6.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src length - 8 битов
Размер префикса IP-адреса отправителя.
Dest length - 8 битов
Размер префикса IP-адреса получателя.
TOS - 8 битов
Восьмибитовое поле TOS (следует отказаться от него для освобождения места под DSCP).
Table ID - 8 битов
Идентификатор таблицы. Поддерживается до 255 таблиц маршрутизации.
RT_TABLE_UNSPEC Неуказанная таблица.                             RT_TABLE_MAIN Основная таблица.
RT_TABLE_DEFAULT Используемая по умолчанию таблица. RT_TABLE_LOCAL Локальная таблица. Пользователь может выделять дополнительные значения в диапазоне21 от RT_TABLE_UNSPEC (0) до RT_TABLE_DEFAULT (253).
Protocol - 8 битов
Указывает кто добавил маршрут в таблицу.
Протокол                 Источник маршрута              Протокол          Источник маршрута
RTPROT_UNSPEC Неизвестен.                             RTPROT_BOOT При загрузке системы.
RTPROT_REDIRECT Из сообщения ICMP redirect. RTPROT_STATIC Администратор.
RTPROT_KERNEL Ядро.
Значения, превышающие RTPROT_STATIC (4)22, не интерпретируются ядром и включены только с информационными целями. Эти значения могут использоваться, чтобы помечать источник маршрутной информации или различать разные демоны маршрути­зации. Идентификаторы уже присвоенные демонам маршрутизации вы можете найти в файле <linux/rtnetlink.h>.
Scope - 8 битов
Область видимости маршрута (корректная дистанция до получателя).
RT_SCOPE_UNIVERSE
Глобальный маршрут.
RT_SCOPE_SITE RT_SCOPE_LINK RT_SCOPE_HOST RT_SCOPE_NOWHERE
Внутренний маршрут локальной автономной системы. Маршрут на данном канале (соединении). Маршрут на локальном хосте. Получателя не существует.
20  На момент перевода документа (ядро 2.6.10) был определен целый ряд дополнительных служб, информацию о которых вы найдете в файле <linux/netlink.h>. Прим. перев.
21 Не включая граничные значения 0 и 253. Прим. перев.
22 В файле <linux/rtnetlink.h> указано, что значение RTPROT_STATIC (4) также не интерпретируется ядром. Прим. перев. rfc.com.ru                                                                          9                                                                        rfc.com.ru
Перевод RFC 3549
Значения в диапазоне от RT_SCOPE_UNIVERSE (0) до RT_SCOPE_SITE (200), не включая граничные, могут использоваться для пользовательских идентификаторов.
Type - 8 битов
Тип маршрута.
Тип RTN_UNSPEC RTN_UNICAST RTN_LOCAL
Неизвестный маршрут. Шлюз или прямой маршрут. Маршрут к локальному интерфейсу.
Получатель
RTN_BROADCAST
RTN_ANYCAST
RTN_MULTICAST
Локальный широковещательный маршрут (передается как broadcast). Локальный anycast-маршрут (передается как unicast) Локальный групповой (multicast) маршрут.
RTN_BLACKHOLE Маршрут для отбрасывания пакетов без уведомления (черная дыра).
RTN_UNREACHABLE Недостижимый получатель. Пакеты отбрасываются с передачей отправителю сообщения ICMP о недо­ступности адресата.
RTNPROHmiT RTN_THROW
Запрещенный маршрут. Пакеты отбрасываются с передачей отправителю сообщения ICMP о запрете
доступа к адресату.
При использовании маршрутизации на базе правил указывает на продолжение просмотра маршрутов в другой таблице. При обычной маршрутизации пакеты отбрасываются с передачей отправителю сообще­ния ICMP о недоступности адресата.
RTN_NAT
RTN_XRESOLVE
Правило трансляции сетевых адресов.
Указывает на внешний преобразователь (resolver). В настоящее время еще не реализовано.
Flags - 32 бита
Дополнительная информация о маршруте.
RTM_F_NOTIFY При изменении маршрута пользователю передается уведомление.
RTM_F_CLONED Маршрут клонирован из другого маршрута.
RTM_F_EQUALIZE Маршрут допускает случайный выбор следующего интервала (next hop) в случае наличия нескольких пу­тей (в настоящее время не реализовано).
Имеющие отношение к данному сервису атрибуты перечислены в таблице.
Атрибут                                                                      Описание
RTA_UNSPEC          Игнорируется.
RTA_DST                  Протокольный адрес источника маршрута.
RTA_SRC
RTA_HF
RTA_OIF
Протокольный адрес конечной точки маршрута. Индекс входного интерфейса. Индекс выходного интерфейса.
RTA_GATEWAY RTA_PRIORITY RTA_PREFSRC RTA_METRICS
Протокольный адрес шлюза для маршрута.
Приоритет маршрута.
Предпочтительный адрес отправителя при наличии нескольких адресов.
Присвоенная маршруту метрика (например, RTT, начальный размер окна TCP и т. п.).
RTA_MULTIPATH Атрибуты следующего интервала для маршрута с множеством путей (Multipath route). RTA_PROTOINFO Атрибут маршрутизации, основанный на политике межсетевого экрана. RTA_FLOW              Область маршрута (Route realm).
RTA_CACHEINFO Кэшированная информация о маршруте.
Для этого типа сервиса поддерживаются дополнительные сообщения Netlink RTM_NEWROUTE, RTM_DELROUTE и RTM_GETROUTE.
3.1.2. Модуль учета соседей
Этот сервис обеспечивает возможность добавления и удаления записей о соседях (например, ARP, IPv4 neighbor solicitation и т. п.), а также получения информации о существующих записях таблицы соседей. Шаблон сообщений этой службы показан на рисунке справа.
Family - 8 битов
Идентификатор семейства адресов: AF_INET для IPv4 и AF_INET6 для IPv6.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10
Перевод RFC 3549
Interface Index - 32 бита
Уникальный индекс интерфейса.
State - 16 битов
Битовая маска, которая может включать перечисленные в таблице биты состояния.
NUD_INCOMPLETE
NUD_REACHABLE
NUD_STALE
NUD_DELAY
NUD_PROBE
NUD_FAILED
NUD_NOARP
Продолжаются попытки преобразования адреса.
Подтверждено наличием рабочей записи в кэше.
Просроченная запись из кэша.
Сосед больше не достижим. Трафик передан, ожидается подтверждение.
В настоящее время осуществляется запрос на обновление записи в кэше.
Некорректная запись в кэше.
Устройство, которое не выполняет обнаружения соседей (ARP).
NUD_PERMANENT Flags - 8 битов
Статическая запись.
NTF_PROXY Запись proxy ARP NTF_ROUTER Маршрутизатор IPv6 Применимые к этому сервису атрибуты перечислены в таблице.
Атрибут                                     Описание
NDA_UNSPEC          Неизвестный тип.
NDA_DST                  Адрес сетевого уровня для кэша соседей.
NDA_LLADDR NDA_CACHEINFO
Адрес канального уровня для кэша соседей.
Статистика кэширования.
Для этого типа сервиса поддерживаются дополнительные сообщения Netlink RTM_NEWNEIGH, RTM_DELNEIGH и RTM_GETNEIGH.
3.1.3. Служба контроля трафика
Этот сервис обеспечивает возмож­ность генерации, запроса и прослу­шивания событий, связанных с контролем трафика. Эта служба включает дисциплины очередей (планировщики и алгоритмы обслу­живания очередей – например, пла­нировщики на основе уровней прио­ритета или алгоритм RED) и класси­фикаторы трафика. Система управ­ления трафиком в Linux23 обеспечи­вает высокий уровень гибкости о поддерживает иерархическое каска­дирование различных блоков для совместного использования ресур­сов каналов передачи трафика.
++
+------+
> | Фильтр I -
+------+
+------+
>I Фильтр I -
+------+
+------+
>I Фильтр I
+------+
+-----+ +
I I—>l
->|Класс I +
| +-----
+-----------
-------+
Qdisc | -
-------+
++ ->l I
I I--+l
---+
++ .++
++
+-----+ +
-------+
Qdisc | -
-------+
++ ->l I
I I---+I ---+
->dev->
_->i
Родительская дисциплина очередей
На приведенном справа рисунке по­казана пример схемы выходного блока TC. В этом документе приво­дится весьма краткое рассмотрение
+ -------------------------------------------------------------- +|
Родительская дисциплина очередей (связана с выходным устройством) + ---------------------------------------------------------------- +
этого вопроса; дополнительную информацию можно найти на сайте [11]. Пакет сначала проходит через фильтр, используемый для идентификации класса трафика, к которому может быть отнесен данный пакет. Термин “класс” относится к дисциплинам очере­дей и связан с конкретной очередью. Очередь может использовать простой алгоритм (например, FIFO) или более сложные меха­низмы типа RED или token bucket. Дисциплину очереди, наиболее удаленную от родительской дисциплины, обычно называют планировщиком. В показанной здесь иерархии планировщик может включать различные алгоритмы планирования, что делает си­стемы управления трафиком на выходе24 в ОС Linux очень гибкими.
Шаблон сообщения для этого типа сервиса показан ниже. Этот шаблон используется для дисциплин входных и выходных очере­дей (относительно модели управления трафиком на выходе, описанной в разделе для модели FE на стр. 3). Каждая специфическая компонента модели имеет уникальные атрибуты, описывающие ее наилучшим способом. Атрибуты общего назначения рассмат­риваются ниже.
Family - 8 битов
Идентификатор семейства адресов: AF_INET для IPv4 и AF_INET6 для IPv6.
Interface Index - 32 бита
Уникальный индекс интерфейса.
Qdisc handle - 32 бита
23 Traffic Control Service
24 Egress TC
11
Перевод RFC 3549
Уникальный идентификатор экземпляра    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
тификаторы рассматриваются как двух-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
компонентные (старшая:младшая) по 16   | Family | Reserved1 | Reserved2 |
битов в каждой части. Старшая часть но-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
мера будет также старшей частью в   | Interface Index |
номере родителя данного экземпляра.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parent Qdisc - 32 бита
|                                              Qdisc handle                                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Используется для иерархической    | Parent Qdisc |
структуризации дисциплин очередей. Если   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
это значение совпадает с   | TCM Info |
идентификатором и TC_H_ROOT, данный    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ экземпляр qdisc является называется корневым25 (старшим).
TCM Info - 32 бита
Для этого поля FE обычно устанавливает значение 1 за исключением тех случаев, когда экземпляр Qdisc уже используется (в этом случае в поле помещается значение счетчика использования данного экземпляра). При передаче со стороны CPC в направлении FEC это поле обычно имеет значение 0 за исключением тех случаев, когда оно используется в контексте фильтрации. В таких слу­чаях 32-битовое поле делится на 16-битовые поля приоритета и протокола. Протоколы определены в исходных кодах ядра (файл <include/linux/if_ether.h>). Наиболее широко используемым протоколом является ETH_P_IP (протокол IP).
Значение приоритета используется для разрешения конфликтов при пересечении фильтрующих выражений.
Базовые атрибуты этого типа сервиса перечислены в таблице.
Атрибут                                                   Описание
TCA_KIND         Каноническое имя компоненты FE.
TCA_STATS Базовая статистика использования FEC.
TCA_RATE Оценка скорости для FEC (расчет на основе текущего состояния).
TCA_XSTATS Специфическая статистика FEC.
TCA_OPTIONS Вложенные атрибуты, связанные с FEC. В приложении 3 дается пример конфигурации компоненты FE для дисциплины FIFO.
Для этого типа сервиса поддерживаются дополнительные сообщения Netlink RTM_NEWQDISC, RTM_DELQDISC, RTM_GETQDISC, RTM_NEWTCLASS, RTM_DELTCLASS, RTM_GETTCLASS, RTM_NEWTFILTER, RTM_DELTFILTER и RTM_GETTFILTER.
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 - 8 битов
Определяет тип информации в пакетах,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mode | Reserved1 |                       Reserved2                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
отправляемых CPC:                                      |                                                     Range                                                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPQ_COPY_META – копировать в CPC
только метаданные для пакета.
IPQ_COPY_PACKET – копировать в CPC метаданные и содержимое поля данных пакета.
Range - 32 бита
В режиме IPQ_COPY_PACKET это значение определяет максимальный размер копируемых данных.
25 root qdisc
rfc.com.ru                                                                                   12                                                           rfc.com.ru
Перевод RFC 3549                                                                                             
Пакет и связанные с ним метаданные, по-   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 - 32 бита                                        |                                                 Packet ID                                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Уникальный идентификатор пакета, пере- |                                                       Mark                                                                 |
даваемый CPC от FEC.                                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                 timestamp_m                                                         |
Mark - 32 бита                                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Значение внутренних метаданных, уста- |                                                 timestamp_u                                                         |
новленное для описания правила, в кото- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ром был взят пакет.                                       |                                                       hook                                                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ timestamp_m - 32 бита                                   |                                                 indev_name                                                           |
Время прибытия пакета (в секундах)             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                 outdev_name                                                         |
timestamp_u - 32 бита                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Время прибытия пакета (микросекунды, |                       hw_protocol | hw_type                                  |
добавляемые к timestamp_m)                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hw_addrlen |                       Reserved                         |
hook - 32 бита                                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Модуль межсетевого экрана, из которого |                                                 hw_addr                                                                 |
был взят пакет.                                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                 data_len                                                               |
indev_name - 128 битов                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                              Payload . . .                                                       |
Имя приемного интерфейса (строка +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ASCII).
outdev_name - 128 битов
Имя выходного интерфейса (строка ASCII).
hw_protocol - 16 битов
Аппаратный протокол (в сетевом порядке битов).
hw_type - 16 битов
Тип оборудования.
hw_addrlen - 8 битов
Размер аппаратного адреса.
hw_addr - 64 бита
Аппаратный адрес.
data_len - 32 бита
Размер данных в пакете.
Payload – размер задается полем data_len
Данные из полученного пакета.
Формат сообщений типа 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 - 32 бита
|                                                     Value                                                                 |
Решение, принятое по отношению к паке- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ту, который по-прежнему находится в |                                                Packet ID                                                             |
FEC. Поддерживаются значения:                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                              Data Length                                                           |
NF_ACCEPT – принять пакет для даль- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ нейшей обработки.                                         |                                              Payload . . .                                                       |
NF_DROP - отбросить (Drop) пакет.             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet ID - 32 бита
Уникальный идентификатор пакета, передаваемый CPC от FEC. Data Length - 32 бита
Размер данных в измененном пакете (в байтах). Если пакет не был изменен, это поле имеет значение 0. Payload – размер определяется значением поля Data Length.
3.3. Служба NETLINK_ARPD
Этот сервис используется CPC для поддержки таблицы соседей в FE. Формат сообщений, передаваемых между FEC и CPC, опи­сан параграфе, посвященном службе учета соседей (стр. 10).
Предполагается, что сервис CPC принимает участие в работе протоколов организации соседских отношений (neighbor solicitation protocol).
rfc.com.ru                                                                         13                                                                       rfc.com.ru
Перевод RFC 3549
Сообщение типа RTM_NEWNEIGH передается CPC от FE для информирования CPC об изменениях, которые могут произойти с записью для этого соседа.
Сообщения RTM_GETNEIGH используются для получения информации о конкретном соседе.
4.  Литература
4.1. Нормативные документы
[I]  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 181226, 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 232826, April 1998.
[6] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 115726, 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. Дополнительная литература
[9] G. R. Wright, W. Richard Stevens. "TCP/IP Illustrated Volume 2, Chapter 20", June 1995. [10] http://www.netfilter.org
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).
Протокол плоскости управления для IP-служ-бы foo выполняет перечисленные ниже опе­рации для подключения к FE (нумерация в списке соответствует номерам на рисунке).
1)   Подключение к IP-сервису foo через со-кет. Обычно соединение организуется с помощью вызова socket(AF_NETLINK, SOCK_RAW, NETLINK_FOO).
2)   Привязка с целью прослушивания специ­фических асинхронных событий для сер­виса foo.
3)   Привязка с целью прослушивания специ­фических асинхронных событий FE.
СР
CLI
/
------- .
\
/-»
Протокольная компонента CP для IP-службы foo ___________ /
I
_/
I
Y I
Y
2,5,10 | 3,7
1,4,6,8,9 / ---------/-
I-
Y
I
FE
I                                       I
**!***********!****!**********I ********** ************ уровень Netlink ************ **|***********|****|**********|**********
I                                                      I
I
->
I                                                                  /
Y                          /
. --------л-------•     /
| Компонента/модуль   |/
| ЕЕ для IP-службы     |
>---1 foo                        |----->-
26 На сайте rfc.com.ru имеется перевод этого документа на
усский язык. Прим. перев.
14
Перевод RFC 3549
Приложение 2: Пример протокола для IP-службы Foo
В этом примере IP-сервис foo используется теперь для демонстрации простого управления сервисом IP с использованием Netlink. Этапы этого управления осуществляются после операций, указанных в Приложении 1 и списки используют общую нумерацию.
4)   Запрашивается текущая конфигурация компоненты FE.
5)   Принимается отклик на запрос (4) через канал, организованный на этапе (3).
6)   запрашивается текущее состояние IP-сервиса foo.
7)   Принимается отклик на запрос (6) через канал (2).
8)   регистрируются связанные с протоколом пакеты, которые хочется получать от FE.
9)   Передаются специфические для данной службы команды foo и (при необходимости) принимаются отклики на них.
Приложение 2a: Взаимодействие с другими службами IP
На схеме в Приложении 1 показана другая компонента, которая может конфигурировать тот же сервис. В данном случае это фир­менный командный интерфейс CLI27. Интерфейс 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.
Адреса авторов
Jamal Hadi Salim
Znyx Networks
Ottawa, Ontario
Canada
Hormuzd M Khosravi
Intel
2111 N.E. 25th Avenue JF3-206
Hillsboro OR 97124-5961
USA
Phone: +1 503 264 0334
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)                                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Andi Kleen
SuSE
Stahlgruberring 28 81829 Muenchen Germany EMail: ak@suse.de
Alexey Kuznetsov
INR/Swsoft
Moscow
Russia
27 Command Line Interface
15
Перевод RFC 3549
Перевод на русский язык Николай Малых
BiLiM Systems
Russia
Полное заявление авторских прав
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Подтверждение
Финансирование функций RFC Editor в настоящее время обеспечивается Internet Society.
16
Новые впечатления с проститутками ждут вас уже сейчас. | Russia - escorts - backpage,moscow mature escort.