Порядок создания СЗПДн. Требования к сетевым устройствам

• Название: Требования к сетевым устройствам
• Анкор: Порядок создания СЗПДн
• Дата: 11.10.2021
• Размер: 1.38 Mb.
• Имя файла: rfc1122_HOST1_tr.doc
• Тип: Протокол; #245378
• страница: 6 из 11

§3.2.3. Протоколуправления Internet-группами

(Internet Group Management Protocol — IGMP-протокол)

IGMP-протокол (RFC-1112 и RFC-2236) используется между ГВМ и шлюзами в одиночной сети для формирования из нескольких ГВМ соответствующих пулов с групповой IP-адресацией (multicast groups). Шлюзы используют эту информацию совместно с протоколом групповой маршрутизации с цель обеспечения доставки IP-пакетов с групповой адресацией через Internet-сеть.

Вместе с тем, применение IGMP-протокол является не обязательным. ГВМ, не используя этот протокол, может также разделять присоединённые сети с использованием локальной групповой IP-адресацией.
§3.3. Специфические проблемы

§3.3.1. Маршрутизация исходящих IP-пакетов

Программный модуль IP-уровня определяет для каждого подлежащего передаче IP-пакета первый ретрансляционный участок “оптимального” маршрута доставки этого пакета. Если получателем является присоединённая сеть, то IP-пакет передаётся непосредственно ГВМ-получателю. В противном случае, IP-пакет направляется на шлюз присоединённой сети.
§3.3.1.1. Принятие решения о локальном/удалённом

получателе IP-пакета

В случае если получателем IP-пакета является присоединённая сеть, то для принятия решения должен использоваться следующий алгоритм (RFC-950):

1. 
   адресная маска (приемлемая для локального IP-адреса многоадресной ГВМ) представляет собой 32-битовую маску, с помощью которой соответствующего IP-адреса выбираются поля, содержащие номер сети и номер подсети;
   
2. 
   если биты IP-адреса получателя, извлечённые с помощью адресной маски, совпадают с битами IP-адреса отправителя, извлечёнными с помощью той же самой адресной маски, то получатель IP-пакета расположен в соответствующей присоединённой сети, а сам IP-пакет должен быть передан непосредственно ГВМ-получателю;
   
3. 
   в противном случае получатель IP-пакета доступен только через шлюз.
   

В отдельных случаях IP-адрес получателя обрабатывается следующим образом:

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

Программный IP-модуль в ГВМ должен корректно функционировать в минимальном сетевом сегменте, и даже в условиях отсутствия шлюзов. Например, если программный IP-модуль в ГВМ настойчиво требует поиска как минимум одного шлюза для своей инициализации, тот ГВМ не будет способна функционировать в одиночной изолированной широковещательной сети.
§3.3.1.2. Выбор шлюза

Для обеспечения эффективности процесса маршрутизации последовательности IP-пакетов при передаче одному и тому же получателю, ГВМ-отправитель обязана хранить в кэш-памяти маршруты, определяющие шлюзы, расположенные на противоположных концах первых ретрансляционных участков. ГВМ используют следующий базовый алгоритм (рис.6) с использованием кэш-памяти при выборе маршрутов передачи IP-пакетов (этот алгоритм разработан с целью переноса наибольшей нагрузки, связанной с первичной процедурой определения маршрута, на шлюзы, RFC-816):

1. 
   если в кэш-памяти не содержится маршрутная информация интересах кон­кретного получателя, то ГВМ выбирает шлюз в режиме “по умолчанию” и передаёт ему IP-пакет. Одновременно с этим, ГВМ заносит соответствующую информацию о выбранном маршруте в кэш-память;
   
2. 
   если выбранный “по умолчанию” шлюз расположен на противоположном конце не лучшего первого ретрансляционного участка для конкретного получа­теля, то этот шлюз перенаправит этот IP-пакет на другой шлюз, который расположен на противоположном конце лучшего первого ретрансляционного уча­стка для этого получателя. Одновременно с этим, выбранный “по умолчанию” шлюз направит ICMP-сообщение “перенаправление” (“Redirect”) ГВМ, передавшей IP-пакет;
   

Рис.6. Алгоритм выбора маршрута доставки IP-пакета с использованием кэш-памяти

(а. выбор маршрута “по умолчанию” при незаполненной кэш-памяти;

в. обновление данных в кэш-памяти после получения

ICMP-сообщения “перенаправление”)

3. 
   когда ГВМ получит ICMP-сообщение “перенаправление”, то она исправляет запись в кэш-памяти и заносит в неё данные о шлюзе, который расположен на другом конце лучшего первого ретрансляционного уча­стка для этого получателя. И вследствие этого все последующие IP-пакеты, предназначенные для данного получателя, будут направляться на “лучший” шлюз.
   

Так как маска подсети, которая соответствует IP-адресу получателя, в действительности не известна, то ICMP-сообщение “перенаправление от сети” (“NetworkRedirect”) должно рассматриваться так же как и ICMP-сообщение “перенаправление от ГВМ” (“HostRedirect”). Другими словами, кэш-запись, содержащая данные о ГВМ-получателе, могла бы (только) пополниться данными о новом шлюзе (или заново сформироваться при условии, что запись об этой ГВМ отсутствовала).

Данный стандарт предназначен для защиты от шлюзов, которые с вредоносными целями передают ICMP-сообщения “перенаправление от сети” в сегментированную сеть, и нарушают, таким образом, требования к шлюзам, определённые стандартом RFC-1009.

Когда кэш-запись о маршруте доставки IP-пакета для соответствующей ГВМ-получателя с конкретным IP-адресом отсутствует (и ГВМ-получатель не расположена в присоединённой сети), программный IP-модуль должен выбрать шлюз из своего перечня шлюзов “по умолчанию”. программный IP-модуль должен поддерживать несколько шлюзов “по умолчанию”.

В качестве дополнительной функции программный IP-модуль ГВМ может использовать таблицу “статических маршрутов”. Каждый такой статический маршрут может включать дополнительный указатель (“флаг”), который указывает может ли этот маршрут быть отменён с помощью ICMP-сообщений “перенаправление”.

Обычно ГВМ необходимо знать, по крайней мере, один шлюз “по умолчанию” перед началом своего функционирования в системе. Такая информация может быть получена из файла настройки или ещё из символьной последовательности запуска ГВМ, например, с помощью BOOTP-протокола (RFC-1123).

Рекомендуется, чтобы ГВМ могла актуализировать свой список шлюзов “по умолчанию” путём записи всех новых шлюзов, которые она “узнала”. Например, ГВМ может записывать данные о каждом шлюзе, которые поступили в составе ICMP-сообщений “перенаправление”. Рассмотренная функция, которая может быть полезной в некоторых ситуациях, тем не менее может стать источником проблем в других ситуациях (например, не все шлюзы эквивалентны) и поэтому её реализация не рекомендуется.

Статический маршрут обычно представляет собой отображение первого ретрансляционного участка от ГВМ- или сети-получателя до соответствующего шлюза, расположенного на противоположной стороне соединения. Он может также зависеть от типа обслуживания (“Type-of-Service”). Статические маршруты могли бы устанавливаться системными администраторами с целью отключения обычного автоматического способа маршрутизации и перехода на ручное управление в нештатных ситуациях. Тем не менее, любая информация о статической маршрутизации является потенциальным источником сбоя или нештатной ситуации при смене настроек или сбое в программно-аппаратной части.
§3.3.1.3. Кэш-запись о маршруте

Каждая кэш-запись о маршруте (route cache entry) должна содержать следующие поля:

1. 
   локальный IP-адрес (для многоадресной ГВМ);
   
2. 
   IP-адрес получателя;
   
3. 
   тип(ы) обслуживания;
   
4. 
   IP-адрес шлюза, расположенного на противоположной стороне первого ретрансляционного участка.
   

Поле 2 может быть полным IP-адресом ГВМ-получателя, или только номером сети-получателя. Поле 3, “Type-of-Service”, целесообразно включать.

Включение поля “Type-of-Service” в кэш-запись о маршруте обеспечивает её использование при выполнении процедуры выбора маршрута.

Каждая в кэш-запись о маршруте определяет оконечные точки всего маршрута доставки IP-пакета (сквозное соединение) по Internet-сети. Несмотря на то, что сквозное соединение может изменяться динамически и при этом произвольным образом, параметры передачи на всём маршруте доставки IP-пакета, как правило, остаются примерно постоянными на протяжении всего периода времени, который более продолжительнее, чем типовое однократное соединение между ГВМ на транспортном уровне. Более того, кэш-запись о маршруте занимает обычное место среди всех данных в кэш-памяти о свойствах всего маршрута доставки IP-пакета (сквозного соединения). Примерами таких свойств являются:

• 
  максимальный размер IP-пакета, не подлежащего фрагментации;
  
• 
  усреднённое значение времени задержки петлевого маршрута, измеренное транспортным протоколом.
  

Эти данные, как правило, формируются и используются протоколом более высокого уровня, например, ТСР или прикладным процессом, функционирующим с UDP-протоколом.

В настоящее время нет единого взгляда на хранение в маршрутной кэш-памяти IP-адресов, либо только IP-адреса ГВМ-получателей, либо IP-адреса ГВМ-получателей и сетей одновременно. Те, кто предпочитают хранение только IP-адресов ГВМ-получателей, аргументируют свой выбор следующим образом:

1. 
   ICMP-сообщения “перенаправление” будут всегда формироваться на основе записей, содержащих IP-адреса ГВМ-получателей. Всегда для использования IP-адреса ГВМ можно было бы использовать самую простейшую и наиболее общую схему;
   
2. 
   Программный IP-модуль не всегда может знать адресную маску для сетевого IP-адреса в сложном сетевом пространстве, разделённом на подсети;
   
3. 
   Использование только IP-адресов ГВМ позволяет применять IP-адрес ГВМ-получателя как простой 32-битовый номер, который, в свою очередь, обеспечит более простое распространение Internet-архитектуры в дальнейшем, причём без каких-либо изменений в ГВМ.
   

Противоположный взгляд, позволяющий хранение в маршрутной кэш-памяти IP-адресов ГВМ-получателей и сетей одновременно, имеет следующие аргументы:

1. 
   Экономия общего объёма памяти;
   
2. 
   Упрощает структуру данных, обеспечивает простое объединение кэш-записей с таблицами в режиме “по умолчанию” и статических маршрутов;
   
3. 
   Обеспечивает более полное размещение в кэш-памяти свойств маршрута доставки IP-пакетов.
   

Кэш-память должна быть достаточно большой для хранения в ней данных о максимальном числе ГВМ-получателей, которые могут использоваться одновременно.

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

Программному IP-модулю может понадобиться снижение затрат на сканирование кэш-записи о маршруте при обработке IP-пакета, подлежащего передаче. Указанное требование может быть выполнено за счёт использования упорядоченной определённым образом таблицы (хэш-таблица, hash table) для ускорения процедуры просмотра, либо путем передачи “подсказки” транспортному протоколу с установлением соединения, либо путём передачи ему временного управления соответствующей кэш-записью, которая потом доставляется на IP-уровень с каждым последующим IP-пакетом.

Несмотря на то, что в данном стандарте концептуальные понятия “кэш-запись о маршруте”, перечни шлюзов, используемых в режиме “по умолчанию”, и таблица статических маршрутов представлены как самостоятельные (отдельные), на практике они могут быть объединены в одну информационную конструкцию, именуемую “маршрутной таблицей”.
§3.3.1.4. Обнаружение неисправного (неработающего) шлюза

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

Подробная процедура обнаружения неисправного шлюза описана в стандарте RFC-816. На сегодняшний день не существует совершенного алгоритма, который удовлетворял бы всем требованиям к процедуре обнаружения такого шлюза. И тем не менее, алгоритм, представленный в стандарте RFC-816, позволяет определить некоторые запрещённые маршруты. Кроме того, в этом же стандарте рассматриваются весьма перспективные способы обнаружения неисправного шлюза. В этой связи, предлагаются следующие рекомендации:

• 
  соответствующий шлюз не должен использоваться “бесконечно” долго, если отсутствуют позитивные данные о его нормальном функционировании;
  
  • 
    активное зондирование, например, использование метода эхо-контроля (обмен ICMP-сообщениями (запросами и ответами) “Эхо-контроль”), является весьма не эффективным. Поэтому ГВМ не должны постоянно проверять состояние шлюзов, расположенных на противоположных сторонах первых ретрансляционных участков, только путём непрерывного эхо-контроля;
    
    • 
      даже если существует только эффективный способ проверки состояния шлюза, эхо-контроль должен использоваться только тогда, когда трафик транслируется в соответствующий шлюз и когда нет любых других позитивных данных о его нормальном функционировании;
      

• 
  для предотвращения использования процедуры эхо-контроля, целесообразно, чтобы уровни, расположенные выше и/или ниже IP-уровня, имели возможность доставлять последнему “уведомление” о состоянии шлюза, используя для этого кэш-записи о маршрутах, содержащие доступную, либо позитивную (шлюз работоспособен), либо негативную (шлюз неисправен) информацию.
  

Если программный IP-модуль не реализует адекватный способ выявления неисправного шлюза и изменения маршрута доставки IP-пакетов, то такой шлюз может по всей видимости стать причиной исчезновения IP-пакетов, то есть превратиться в “чёрную дыру”. Такое событие может серьёзно навредить пользователям и существенно усложнить работу сетевых администраторов по обнаружению и устранению неисправностей.

Способ выявления неисправного шлюза не должен вызывать проблем с загрузкой ГВМ, присоединённых сетей и шлюзов, расположенных на противоположных сторонах первых ретрансляционных участков. Точность и своевременность обнаружения неисправного шлюза и приемлемой загрузки может частично варьироваться в зависимости от функционального предназначения ГВМ. Но, в принципе, ГВМ нуждается в достаточно быстрой процедуре обнаружения неисправного шлюза, расположенного на противоположной стороне первого ретрансляционного участка, чтобы соединения, установленные на транспортном уровне, не были прерваны ещё до выбора возможного альтернативного шлюза.

Получение уведомления от других уровней (протоколов) Internet-архитектуры усложняет интерфейсы между уровнями, однако такое усложнение более предпочтительнее для обнаружения неисправных шлюзов. “Подсказка” может прийти едва ли не от каждого уровня Internet-архитектуры, но такими наиболее вероятными уровнями будут транспортный и канальный. Далее приводятся некоторые источники уведомлений для шлюзов:

• 
  ТСР-протокол или любой иной транспортный протокол с установлением соединения должны быть способны давать негативное уведомление, например, уведомление о чрезвычайно большом числе повторных передач;
  
  • 
    ТСР-протокол может давать положительное уведомление, когда (новые) данные подтверждаются. Даже если маршрут может быть ассиметричным, подтверждение новых данных указывает на то, что подтверждаемые данные были переданы успешно;
    
    • 
      ICMP-сообщение “перенаправление”, поступившее от соответствующего шлюза, должно восприниматься как позитивное уведомление о данном шлюзе;
      
      • 
        информация канального уровня, который достоверно сообщает об обнаружении неисправности в ГВМ, должна использоваться в качестве негативного уведомления;
        
        • 
          неисправность, обнаруженная ARP-протоколом или подтверждённая этим протоколом, может использоваться в качестве негативного уведомления по отношению к конкретному IP-адресу;
          
          • 
            IP-пакеты поступающие с канального уровня, который имеет конкретный канальный адрес, являются свидетельством того, что система с этим адресом функционирует. Однако, для преобразования этой информации в уведомление о шлюзах необходимо отобразить адрес канального уровня в IP-адрес, и после этого проверить данный IP-адрес, что он действительно принадлежит тем шлюзам, которые указаны в кэш-записях о маршрутах. Такой подход, скорее всего, — чрезвычайно неэффективен.
            

Следует заметить, что позитивное уведомление, которое сопровождает каждый принимаемый IP-пакет, может вызвать нежелательную перегрузку в программном IP-модуле. Несмотря на то, что уведомление может быть передано на IP-уровень, используя для этого требуемые во всех интерфейсах параметры, некоторые протоколы транспортного и прикладного уровней не могут сформировать корректное уведомление. По этой причине эти интерфейсы обязаны признавать промежуточный код в уведомлении, так как использование только, либо позитивного, либо негативного уведомления повлечёт за собой нештатную ситуацию.

Существует другой способ обнаружения неисправного шлюза, который, в принципе, можно использовать, однако, его применение не рекомендовано. Этот способ основан на приёме (“wiretapping”, прослушивание) IP-пакетов IGP-протокола (Interior Gateway Protocol — протокол функционирования внутреннего шлюза), которыми шлюзы обмениваются между собой в широковещательном режиме. Данный способ имеет один недостаток, который заключается в том, что ГВМ должна знать все используемые шлюзами IGP-протоколы (RFC-1009). Кроме того, этот способ работает только в широковещательных сетях.

В настоящее время, эхо-контроль (например, использование ICMP-сообщений “Эхо-контроль”) является способом зондирования шлюзов, но только в тех случаях, когда он безусловно необходим. Успешная процедура эхо-контроля гарантирует, что интерфейс с зондируемым адресом и связанное с ним сетевое устройство имеют место быть, но она не гарантирует, что сетевое устройство является шлюзом в отличие от ГВМ. Из этого следует естественный вывод: если бы ICMP-сообщение “перенаправление” или другое события указывали на то, что сетевое устройство было шлюзом, то успешные процедуры эхо-контроля, в свою очередь, будут указывать на то, что сетевое устройство по-прежнему имеет место быть и к тому же это шлюз. Тем не менее, так как ГВМ в режиме “по умолчанию” уничтожает IP-пакеты, которые шлюз мог бы ретранслировать или перенаправлять, такое предположение иногда бы не могло быть реализовано. Для устранения этой проблемы необходимо включить в логическую характеристику ICMP-протокола новое сообщение/запрос “вы являетесь шлюзом?” (“are you a gateway?”).

Для решения задачи обнаружения неисправного шлюза рекомендован следующий специализированный алгоритм:

1. 
   “Закрепить” таймер “смены маршрута” за каждым шлюзом, указанным в кэш-записи о маршруте;
   
2. 
   Установить таймер в начальное значение Т_r, которое должно быть небольшим, но достаточным для проведения процедуры обнаружения неисправного шлюза ещё до окончания периода тайм-аута виртуального соединения, контролируемого транспортным уровнем;
   
3. 
   Позитивное уведомление могло бы переустановить таймер в начальное значение Т_r. Негативное уведомление могло бы уменьшить или обнулить значение таймера “смены маршрута”;
   
4. 
   Всякий раз когда программный IP-модуль использовал соответствующий шлюз для направления IP-пакета по некоторому маршруту, он мог бы проверить “прикреплённый” таймер “смены маршрута”. Если таймер был просрочен (обнулился), программный IP-модуль мог бы передать на шлюз ICMP-запрос “Эхо-контроль”, следующий сразу за IP-пакетом;
   
5. 
   ICMP-запрос “Эхо-контроль” мог быть передан снова, если это необходимо, вплоть до N раз. Если ICMP-ответ “Эхо-контроль” не был получен после N попыток, то можно было бы предположить, что шлюз неисправен. После этого можно было бы выбрать новый шлюз на первом ретрансляционном участке из всех кэш-записей о маршрутах, а в последних указать неисправный шлюз.
   

Необходимо заметить, что размер величины Т_r обратно пропорционален числу приемлемых уведомлений. Величина Т_r должна быть достаточно большой для гарантии того, что:

• 
  любая процедура эхо-контроля будет передавать ICMP-запросы в количестве менее 10% от всех IP-пакетов, переданных ГВМ шлюзу;
  
• 
  процедура эхо-контроля является нечастой (например, каждые 3минуты).
  

Так как рекомендуемый алгоритм скорее связан со шлюзами, указанными в кэш-записях о маршрутах, чем с самими кэш-записями как таковыми, то для применяемой кэш-записи о маршруте может наиболее приемлемой двухуровневая структура данных (которая возможно будет согласована с кэш-записью ARP-протокола или с подобными кэш-записями).
§3.3.1.5. Обнаружение нового шлюза

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

Когда шлюз неисправен, то другие шлюзы в присоединённой сети будут узнавать о его неисправности с помощью некоторого протокола маршрутизации для автономной сети. Однако, это не произойдёт мгновенно, так как протоколы маршрутизации для автономной сети обычно стабилизируют ситуацию в ней (то есть выравнивают нагрузку (трафик) между всеми шлюзами) в течении 30-60 секунд. Если ГВМ “выбирает” альтернативный шлюз ещё до того, как шлюзы узнают о неисправном маршрутизаторе, вновь избранный шлюз вероятнее всего будет ретранслировать IP-пакет на неисправный шлюз и передавать ответное ICMP-сообщение “перенаправление” ГВМ, IP-адрес которой был указан в заголовке IP-пакета, переданного неисправному шлюзу (!). Наиболее вероятным результатом этого будет стремительное изменение содержания в кэш-записи о маршруте в ГВМ в течении всего периода стабилизации автономной сети. Предполагалось, что логическая схема неисправного шлюза должна была иметь специальное средство запаздывания с целью предотвращения таких стремительных изменений. Тем не менее, опыт предыдущей эксплуатации не выявил какого-либо ущерба от таких изменений в кэш-записях, так как сервис не может быть восстановлен в ГВМ до тех пор, пока маршрутная информация в шлюзах не стабилизируется.

Первый способ выбора нового шлюза, используемого в режиме по умолчанию, заключается в простом циклическом переборе таких шлюзов в сформированном в ГВМ перечне. Другой способ — ранжирование шлюзов в порядке их приоритета, и когда текущий шлюз, используемый в режиме по умолчанию, не имеет высшего приоритета, то частота проведения процедуры эхо-контроля с целью обнаружения высоко приоритетных шлюзов замедляется по мере поступления от них ответов. Такая процедура эхо-контроля может проводиться весьма редко, например, 5×10^-3 в сек.
§3.3.1.6. Начальная загрузка (инициализация)

При инициализации в обязательном порядке должна загружаться следующая параметрическая информация:

1. 
   IP-адрес(а);
   
2. 
   Адресная(ые) маска(и);
   
3. 
   Перечень шлюзов, используемых в режиме по умолчанию, с учётом их приоритетности.
   

Для загрузки этих данных обязательно должен быть предусмотрен ручной способ настройки. Кроме того, для определения перечисленных данных могут использоваться динамические способы (RFC-1123).

Некоторые варианты реализации ГВМ используют протоколы прослушивание (“wiretapping”) шлюзов в широковещательных сетях с целью определения какой из шлюзов исправно функционирует. В настоящее время стандартный метод обнаружения шлюза, используемого в режиме по умолчанию, продолжает совершенствоваться.