• Агрегирование каналов выполняется в соединительной линии, которая

обеспечивает прямое двустороннее соединение между двумя устройствами,

например между одноранговыми маршрутизаторами, коммутаторами или
маршрутизатором и коммутатором, расположенными с обеих сторон линии
связи. При агрегировании каналов выполняется объединение каналов,
входящих в состав соединительной линии Ethernet. Благодаря этому
физические каналы работают как один логический канал. Функция
агрегирования каналов поддерживает высокую доступность, позволяя
физическим каналам интерфейса-участника переключать трафик на другую
линию при сбое определенного интерфейса. При агрегировании каналов
выполняется также объединение полос пропускания интерфейсов-участников
соединительной линии. Т.е. полоса пропускания становится равной сумме
полос пропускания всех интерфейсов-участников. Это позволяет эффективно
увеличить полосу пропускания для передачи трафика по логическому каналу.
Кроме того, агрегирование каналов позволяет реализовать распределение
нагрузки на интерфейсе соединительных линий. Трафик интерфейса
соединительных линий распределяется между интерфейсами-участниками, а
затем передается по каналам-участникам в один пункт назначения,
минимизируя, таким образом, вероятность перегрузки сети.
• Часто агрегирование каналов применяется в тех сегментах корпоративной сети,
где существует вероятность высокоскоростного подключения и возможность
перегрузки. Как правило, это приравнивается к базовой сети, на которой лежит
ответственность за высокоскоростное переключение, и где обычно собирается
трафик из всех частей корпоративной сети, прежде чем он будет
перенаправлен в пункты назначения, расположенные в других частях сети или
в удаленные пункты назначения за пределами корпоративной сети. В данном
примере показано агрегирование каналов-участников соединения между
базовыми коммутаторами (SWA и SWB), которое обеспечивает защиту от
перегрузки в критической точке сети.
• Агрегирование каналов поддерживает два режима реализации: режим распределения
нагрузки вручную и режим статического агрегирования с помощью LACP. В режиме
распределения нагрузки интерфейсы-участники вручную добавляются в группу
агрегирования каналов (LAG). Все интерфейсы, сконфигурированные с
распределением нагрузки, находятся в статусе переадресации. AR2200 поддерживает
распределение нагрузки на базе MAC-адресов пунктов назначения, MAC-адресов
источников, «исключающего ИЛИ» MAC-адресов источника и пункта назначения, IP-
адресов источников, IP-адресов пунктов назначения или «исключающего ИЛИ» IP-
адресов источника и пункта назначения. Режим распределения нагрузки вручную не
работает по протоколу LACP, поэтому AR2200 использует данный режим, если
одноранговое устройство не поддерживает LACP.
• В режиме статического агрегирования LACP устройства с обеих сторон канала
согласовывают параметры агрегирования путем обмена пакетами LACP. После
завершения согласования два устройства определяют активный интерфейс и
неактивный интерфейс. В этом режиме необходимо вручную создать Eth-Trunk и
добавить участников. Согласование LACP определяет, какие интерфейсы активны, а
какие неактивны. Режим статического агрегирования LACP также называется режимом
M:N, где M означает количество активных каналов-участников, которые выполняют
передачу данных в режиме распределения нагрузки, а N – это неактивные каналы,
созданные для поддержки механизма избыточности. При неисправности активного
канала переадресация данных будет выполняться по резервному каналу с наивысшим
приоритетом, и статус резервного канала изменится на активный. В режиме
статического агрегирования LACP некоторые каналы могут функционировать в
качестве резервных, тогда как все интерфейсы-участники находятся в
состоянии переадресации и работают в режиме распределения нагрузки
вручную. В этом и заключается основное различие между этими двумя
режимами.
• В качестве логического интерфейса для привязки нескольких физических интерфейсов и ретрансляции
данных верхнего уровня, интерфейс соединительной линии должен обеспечивать согласованность всех
параметров физических интерфейсов (интерфейсов-участников) с обеих сторон соединительной линии. К
параметрам, требующим согласования, относятся количество физических интерфейсов, скорости
передачи и дуплексные режимы физических интерфейсов, а также режимы управления трафиком
физических интерфейсов, для которых следует отметить, в качестве интерфейсов-участников могут быть
интерфейсы второго или третьего уровня. В тех случаях, когда скорость интерфейса не согласована,
соединительная линия все еще будет работать, однако это может привести к потере кадров
интерфейсами, работающими с более низкой скоростью.
• Кроме того, последовательность потока данных должна оставаться неизменной. Поток данных можно
рассматривать как группу кадров с одинаковым MAC-адресом и IP-адресом. Например, соединение Telnet
или FTP между двумя устройствами может рассматриваться как поток данных. Если интерфейс
соединительной линии не сконфигурирован, то кадры, которые принадлежат потоку данных, будут
достигать пункта назначения в правильном порядке, потому что потоки данных передаются по
единственному физическому каналу. При использовании технологии соединительных линий, выполняется
привязка нескольких физических каналов к одной и той же соединительной линии, и по этим физическим
каналам осуществляется передача кадров. Если первый кадр передается по одному физическому каналу,
а второй кадр передается по другому физическому каналу, возможно, что второй кадр достигнет пункта
назначения раньше, чем первый кадр.
• Агрегирование каналов выполняется с помощью команды interface Eth-trunk <trunk-id>.
Данная команда создает интерфейс Eth-Trunk и позволяет получить доступ к режиму
интерфейса Eth-Trunk. Параметр Trunk-id используется для уникальной
идентификации Eth-trunk, его значением может быть любое целое число от 0 до 63.
Если указанный Eth-Trunk уже существует, то можно непосредственно перейти в
режим интерфейса Eth-Trunk с помощью команды interface Eth-trunk. Удалить Eth-Trunk
можно только, если он не содержит интерфейсов-участников. При добавлении к Eth-
Trunk интерфейсов-участников layer 2 Eth-Trunk они должны быть интерфейсами
второго уровня, а при добавлении интерфейсов-участников layer 3 Eth-Trunk –
интерфейсами третьего уровня. Eth-Trunk поддерживает максимум восемь
интерфейсов-участников. Для интерфейса-участника нельзя сконфигурировать какие-
либо сервисы или статический MAC-адрес. Интерфейсы, добавляемые в Eth-Trunk,
должны быть гибридными (тип интерфейса по умолчанию). В Eth-Trunk нельзя
добавлять другие интерфейсы Eth-Trunk в качестве участников. Интерфейс Ethernet
может быть добавлен только в один интерфейс Eth-trunk.
• Для добавления интерфейса Ethernet в другой Eth-trunk сначала необходимо удалить
интерфейс Ethernet из текущего Eth-trunk. Интерфейсы-участники Eth-trunk должны
быть одного типа, например, интерфейс Fast Ethernet и интерфейс Gigabit Ethernet не
могут быть добавлены в один интерфейс Eth-trunk. Одноранговый интерфейс,
напрямую подключенный к интерфейсу-участнику локального Eth-Trunk, также должен
быть добавлен в Eth-Trunk, в противном случае устройства с двух сторон канала не
смогут обмениваться данными. Когда интерфейсы-участники имеют разные скорости,
это может привести к перегрузке интерфейсов с более низкими скоростями, в
результате чего произойдет потеря пакетов. После добавления интерфейса в
Eth-Trunk изучение MAC-адреса осуществляет Eth-Trunk, а не интерфейсы-
участники.
• Чтобы сконфигурировать агрегирование каналов третьего уровня на
соединительной линии Ethernet, необходимо перевести линию со второго на
третий уровень с помощью команды undo portswitch, выполненной на
логическом интерфейсе Eth-trunk. После выполнения команды undo portswitch
логическому интерфейсу может быть назначен IP-адрес и добавлены
физические интерфейсы, которые должны иметь привязку к соединительной
линии Ethernet.
• Для подтверждения успешного агрегирования каналов между двумя
одноранговыми устройствами используется команда display interface eth-trunk
<trunk-id>. Данную команду также можно использовать для сбора статистики
трафика и обнаружения неисправностей интерфейса.
• Если Eth-trunk имеет статус UP, значит интерфейс работает исправно. Если
интерфейс имеет статус DOWN, значит на физическом уровне произошла
ошибка, тогда как ошибка административного уровня указывает на то, что на
интерфейсе была выполнена команда shutdown. В случае неисправности
конкретную ошибку можно обнаружить путем проверки статуса портов. В
исправном состоянии все порты должны иметь статус UP. Распределение
нагрузки поддерживается при одинаковом весе всех каналов.
1. Интерфейсы Fast Ethernet и Gigabit Ethernet не могут быть добавлены в один
интерфейс Eth-trunk. В случае попытки добавить интерфейсы разных типов
появится сообщение об ошибке, связанной с добавлением интерфейса-
участника другого типа. Следует отметить, что коммутатор серии S5700
поддерживает только интерфейсы Gigabit Ethernet, однако это применимо и к
другим моделям, включая коммутатор S3700.
2. Режим LACP позволяет создавать резервные каналы.
По мере расширения локальных сетей увеличивается трафик, и большое
распространение получают технологии широковещательной передачи. Внутри
такой расширяющейся сети нет реальных границ, что может привести к
прерыванию передачи или увеличению нагрузки трафика. Данная проблема
традиционно решалась путем реализации в локальной сети устройств третьего
уровня для создания доменов широковещательной передачи. Однако при этом
возникали дополнительные расходы, и методы передачи, используемые такими
устройствами, не обеспечивали такую эффективную пропускную способность, как
в случае использования коммутаторов. Это приводило к появлению узких мест в
транзитных узлах между широковещательными доменами.
Принцип технологии VLAN заключается в изоляции трафика на канальном уровне.
Использование данной технологии дает то преимущество, что трафик изолируется
без ограничения физических границ. Пользователи могут быть физически
рассредоточены, но все равно быть частью одного широковещательного домена.
Пользователи изолируются от других групп пользователей на канальном уровне.
Сегодня технология VLAN применяется для решения различных задач.
Идентификация кадров VLAN выполняется с помощью заголовка с тегом, который
добавляется в кадр Ethernet, с целью отличия кадров одной VLAN, от другой.
Формат тега VLAN содержит идентификатор протокола тега (Tag Protocol Identifier;
TPID) и связанную информацию управления тегами (Tag Control Information; TCI).
TPID используется для идентификации тегированного кадра (в примере
используется формат тега IEEE 802.1Q). Для идентификации данного формата
используется значение 0x8100. TCI содержит поля с типом формата тега.
Priority Code Point (PCP) – это поле классификации трафика, которое
используется для отличия одной формы трафика от другой, то есть установления
приоритетов трафика. Как правило используется следующая классификация:
голос, видео, данные и т. д. PCP – это 3-битовое поле, которое принимает
значения в диапазоне от 0 до 7 согласно общим принципам подразделения на
классы услуг 802.1p (CoS). Индикатор Drop Eligibility Indicator (DEI) – это 1-битовое
поле, которое принимает значение True или False и служит для определения
условий отбрасывания кадра в случае перегрузки трафика.
Поле VLAN ID содержит идентификатор той VLAN, с которой ассоциирован кадр.
Размер поля — 12 бит. Значения VLAN ID находятся в диапазоне от 0x000 до
0xFFF. При этом резервирование двух значений — верхнего и значений —
позволяет использовать 4094 возможные комбинации VLAN. Для реализации VRP
Huawei использует VLAN 1 в качестве сети по умолчанию (PVID) в соответствии со
стандартом IEEE802.1Q.
Каналы VLAN могут быть двух типов: канал доступа (access) и транковый (trunk)
канал. Канал доступа – это канал между конечной системой и коммутационным
устройством, участвующим в тегировании VLAN, то есть все каналы между хост-
терминалами и коммутаторами являются каналами доступа. Транковый канал –
это канал, по которому, вероятно, будут передаваться тегированные кадры VLAN.
Таким каналами являются каналы между коммутаторами.
Каждый интерфейс устройства, участвующего в тегировании VLAN, будет
привязан к VLAN. Идентификатор VLAN, который будет использован для
интерфейса по умолчанию, задается с помощью параметра Port VLAN ID (PVID).
Данное значение определяет характер приема и передачи любых кадров через
интерфейс.
Порты доступа выполняют привязку к каналам доступа, и полученным кадрам
присваивается тег VLAN, который равен значению параметра Port VLAN ID (PVID)
интерфейса. Во время передачи кадра с интерфейса, прежде чем он будет
переслан в конечную систему, которой не известна данная VLAN, из него обычно
удаляется тег VLAN. Однако, если тег и PVID различаются, то пересылка кадра не
происходит, и он отбрасывается. В этом примере кадр (без тегов) пересылается
на интерфейс коммутатора, что рассматривается как передача на все остальные
пункты назначения.
После получения кадра коммутатор выполняет привязку кадра с VLAN 10 на базе
PVID интерфейса. Коммутатор выполняет идентификацию PVID на интерфейсе
порта и принимает решение о том, можно ли выполнить пересылку кадра. На
хосте C обнаруживается, что PVID совпадает с VLAN ID, выполняется удаление
тега и кадр передается дальше. На хосте B обнаруживается, что кадр и PVID
отличаются, и поэтому передача кадра к данному пункту назначения запрещается.
Для транковых портов, которые ассоциированы с транковыми каналами, параметр
Port VLAN ID (PVID) определяет, какие кадры VLAN должны передавать тег VLAN
перед пересылкой, а какие – нет. В данном примере представлен транковый
интерфейс с PVID 10, для которого всем VLAN разрешено использовать
транковый канал. Согласно значению PVID, без тега VLAN будут пересылаться
только кадры, ассоциированные с VLAN 10. Во все остальные кадры VLAN тег
VLAN должен быть включен перед передачей по транковому каналу, и на порту
должно быть разрешение на его пересылку. Кадры, ассоциированные с VLAN 20,
передаются транковому каналу с тегами.
Гибридные порты – это тип портов по умолчанию для устройств Huawei, которые
поддерживают работу VLAN и предоставляют средства управления процессом
переключения тегов для всех интерфейсов. Каждый порт может рассматриваться
как тегированный порт или нетегированный порт. Порты, которые работают в
качестве портов доступа (нетегированные) и порты, которые работают в качестве
транковых портов (тегированные).
Порты, которые считаются нетегированными, обычно получают от конечных
систем кадры без тега и отвечают за добавление тега к такому кадру в
соответствии с параметром Port VLAN ID (PVID). Одно из ключевых отличий
заключается в способности гибридного порта выборочно выполнять удаление
тегов VLAN из кадров, которые отличаются от PVID интерфейса порта. В данном
примере хост D подключен к порту с PVID, равным 20, в то же время он
сконфигурирован на удаление тега из кадров, полученных из VLAN 10. Это
позволяет хосту D принимать трафик от обеих VLAN — 10 и 20.
Тегированные гибридные порты будут работать аналогично обычному транковому
интерфейсу, однако существует одно важное отличие. Во время передачи те
кадры VLAN, которые соответствуют PVID и разрешены портом, сохранят теги.
Назначение VLAN может быть реализовано на базе одного из пяти методов: на
базе портов, на базе MAC-адресов, на базе IP-адресов подсети, на базе
протоколов и на базе политик. Метод на базе порта представляет собой
стандартный и наиболее распространенный метод назначения, при котором VLAN
классифицируются на коммутирующем устройстве по номерам портов.
Администратор сети настраивает PVID, представляющий собой идентификатор
VLAN по умолчанию, для каждого порта на коммутирующем устройстве. Кадр
данных, достигший порта, маркируется PVID, если не имеет тега VLAN, а порт
сконфигурирован с PVID. Если кадр данных содержит тег VLAN, коммутационное
устройство не будет добавлять тег VLAN к кадру данных, даже если порт
сконфигурирован с PVID.
При использовании метода назначения на базе MAC-адресов VLAN
классифицируются по MAC-адресам сетевых интерфейсных плат (NIC).
Администратор сети конфигурирует связь между MAC-адресами и
идентификаторами VLAN. В данном случае, коммутационное устройство, приняв
кадр без тега, находит тег в таблице MAC-VLAN и добавляет его в кадр, в
соответствии с MAC-адресом кадра. В методе назначения на базе IP-адреса
подсети, после приема кадра без тега коммутационное устройство добавляет тег
VLAN к кадру в соответствии с IP-адресом заголовка пакета.
При использовании метода назначения VLAN на базе протокола, идентификаторы
VLAN назначаются пакетам, полученным на интерфейсе, в соответствии с типом
протокола (набора протоколов) и форматом инкапсуляции пакетов.
Администратор сети конфигурирует связь между типами протоколов и
идентификаторами VLAN. При использовании метода назначения на базе
политик, выполняется целая комбинация критериев, включая IP-адрес
подсети, порт и MAC-адрес. При этом для назначения VLAN все критерии
должны соответствовать.
Реализация VLAN начинается с создания VLAN на коммутаторе. Команда
vlan<vlan-id> используется для первоначального создания VLAN на коммутаторе,
который рассматривается как существующий, как только пользователь входит в
представление VLAN, как показано в приведенном примере. Значение VLAN ID
находится в диапазоне от 1 до 4094. Если необходимо создать несколько VLAN
для коммутатора, используется команда vlan batch <vlan-id1 to vlan-id2>, где
необходимо создать диапазоны смежных (contiguous) VLAN, и команда vlan batch
&<1-4094>, где знак «&» – это пробел между диапазонами несмежных (non-
contiguous) VLAN. Все порты по умолчанию ассоциированы с VLAN 1 и
используют ее в качестве VLAN по умолчанию, поэтому функция передачи не
запрещена.
После создания VLAN результат можно проверить с помощью команды display
vlan. Можно запросить информацию обо всех VLAN и, если параметры не будут
указаны, то пользователь получит краткую информацию обо всех VLAN.
Дополнительные параметры получают с помощью команды display vlan <vlan-id>
verbose, которая выводит подробную информацию об указанной VLAN, включая
идентификатор, тип, описание и состояние VLAN, статус функции статистики
трафика, интерфейсы VLAN и режим, в котором интерфейсы добавляются к
VLAN. Команда display vlan <vlan-id> statistics позволяет просматривать статистику
трафика на интерфейсах указанной VLAN. Команда display vlan summary
предоставляет сводную информацию обо всех VLAN в системе.
Настройка типа канала порта выполняется в представлении интерфейса для
каждого интерфейса активного коммутатора VLAN. По умолчанию на
коммутаторах Huawei установлен гибридный (hybrid) тип канала порта hybrid.
Команда port link-type <type> используется для конфигурирования типа канала
порта, где значениями параметра type могут быть access, trunk или hybrid.
Четвертая опция QinQ не рассматривается в рамках данного курса. Следует также
отметить, что если в конфигурации не отображается тип порта, то будет
сконфигурирован гибридный тип по умолчанию. Перед изменением типа также
необходимо восстановить конфигурацию VLAN по умолчанию данного
интерфейса, чтобы интерфейс принадлежал только к VLAN 1 по умолчанию.
Ассоциация порта с созданной VLAN реализуется с использованием двух методов
настройки, первый из которых выполняется в представлении VLAN, где
интерфейс, который будет ассоциирован с данной VLAN, настраивается с
помощью команды port <interface>. Второй метод назначения портов для VLAN
выполняется в представлении интерфейса, где данный интерфейс добавляется к
VLAN, и выполняется команда port default <vlan-id>, где vlan-id – это VLAN, к
которой добавляется порт.
Для проверки изменений, внесенных в конфигурацию, и подтверждения привязки
интерфейсов портов к VLAN, для которой были назначены порты, используется
команда display vlan. В данном примере интерфейсы портов Gigabit Ethernet 0/0/5
и Gigabit Ethernet 0/0/7 ассоциированы с VLAN 2 и 3 соответственно. Значение UT
означает, что порт считается нетегированным. Для этого канал порта
настраивается как порт доступа либо как нетегированный гибридный порт. Также
можно определить текущее состояние канала как up (U) или down (D).
При настройке типа канала порта как trunk (транковый) становится возможной
передача кадров VLAN нескольких VLAN между коммутаторами, однако для
передачи кадров через транковый интерфейс необходимо применить разрешения.
Для установки разрешения для каждой VLAN используется команда port trunk
allow-pass vlan <vlan-id>, где vlan-id – это идентификатор разрешенной VLAN.
Также необходимо включить в команду PVID для транкового интерфейса, чтобы
по транковому каналу мог передаваться нетегированный трафик. В данном
примере показано изменение идентификатора порта VLAN по умолчанию (PVID)
для интерфейса на 10 и применение разрешения передачи для VLAN 2 и 3 по
транковому каналу. В данном случае любые кадры, ассоциированные с VLAN 10,
не будут передаваться по транковому каналу, даже если VLAN 10 теперь является
VLAN по умолчанию для транковому порта. Команда port trunk allow-pass vlan all
может использоваться для разрешения прохождения всех VLAN по транковому
каналу.
С помощью команды display vlan, в которой отражается информация о
применении VLAN по транковому каналу, можно отслеживать изменения в
разрешениях VLAN. Значение TG указывает, что VLAN были ассоциированы с
тегированным интерфейсом либо через транковый интерфейс, либо через
тегированный интерфейс гибридного порта. В данном примере сети VLAN 2 и 3
получили разрешение на прохождение через тегированный интерфейс Gigabit
Ethernet 0/0/1, который в данный момент активен.
В конфигурации гибридного порта указывается тип порта по умолчанию на
интерфейсах порта коммутатора, и поэтому команда port link-type hybrid, как
правило, используется только при изменении типа access или trunk на тип hybrid.
Однако для каждого порта может потребоваться выполнить привязку к PVID по
умолчанию, в соответствии с которым будут добавляться или не будут
добавляться теги к кадрам. Команда port hybrid pvid vlan <vlan-id> позволяет
назначать PVID по умолчанию для каждого порта в отдельности, после чего также
необходимо настроить метод передачи для данного порта..
Для портов, которые должны работать как порты доступа, настройка выполняется
с помощью команды port hybrid untagged vlan<vlan-id>. Следует четко понимать,
что многократное использование данной команды в одном и том же
представлении интерфейса приведет к тому, что будет выполнена привязка
интерфейса ко всем указанным VLAN, а из соответствующих кадров VLAN будут
удалены теги перед пересылкой. Чтобы восстановить настройки VLAN1 по
умолчанию и вернуться в нетегированный режим по умолчанию, необходимо
использовать команду undo port hybrid vlan.
Для портов, которые должны работать как транковые порты, используется
команда port hybrid tagged vlan <vlan-id>. Следует четко понимать, что
многократное использование данной команды в одном и том же представлении
интерфейса приведет к тому, что будет выполнена привязка интерфейса ко всем
указанным VLAN, а к соответствующим кадрам VLAN будут добавлены теги перед
пересылкой. В данном примере интерфейс гибридного порта Gigabit Ethernet 0/0/1
выполнит тегирование всех кадров, которые ассоциированы с VLAN 2 и 3, прежде
чем будет выполнена пересылка таких кадров через интерфейс.
С помощью команды display vlan можно проверить результаты конфигурации
тегированного и нетегированного гибридного порта. Интерфейс Gigabit Ethernet
0/0/7 установлен как нетегированный интерфейс VLAN 2, а интерфейс Gigabit
Ethernet 0/0/5 был установлен как нетегированный интерфейс, ассоциированный с
VLAN 3. Кадры, ассоциированные с любой из VLAN (VLAN 2 и VLAN 3), будут
передаваться как тегированные кадры через интерфейс Gigabit Ethernet 0/0/1.
В отношении интерфейсов порта коммутатора можно использовать команду port
hybrid untagged vlan <vlan-id> [to <vlan-id>], в соответствии с которой интерфейс
порта будет удалять теги из кадров для множества VLAN, указанных в одной
групповой команде. Такая настройка позволяет гибридным интерфейсам
разрешать пересылку нетегированного трафика из нескольких VLAN в данную
конечную систему. Весь трафик, пересылаемый из конечной системы,
ассоциирован с PVID, который назначен порту и, соответственно, тегирован.
Чтобы применить настройку нетегрированной передачи на VLAN 2 и VLAN 3, на
интерфейсе Gigabit Ethernet 0/0/4 выполняется команда port hybrid untagged vlan 2
to 3. Это означает, что любой трафик, перенаправленный с хоста,
ассоциированного с любой VLAN, в конечную систему, ассоциированную с
интерфейсом Gigabit Ethernet 0/0/4, будет успешно принят.
Рост и развитие IP привели к объединению множества технологий, которые
позволяют передавать высокоскоростные Интернет-сервисы (High Speed Internet;
HSI), сервисы передачи голоса поверх IP (VoIP) и сервисы IP-телевидения (IPTV)
по общей Ethernet-сети и сети TCP/IP. Сети, на базе которых были развиты эти
технологии, отличаются принципом передачи. VoIP создана на базе сети с
коммутацией каналов, которые предусматривают установление фиксированного
канала между источником и пунктом назначения, по которому создается
выделенный путь, гарантирующий, что голосовые сигналы поступят с небольшой
задержкой и по принципу FIFO «первым пришел – первым вышел».
Высокоскоростной Интернет работает на базе сети с коммутацией пакетов, при
этом имеют место множественные одновременные запросы и пересылка пакетов
без гарантии доставки в правильной последовательности, что часто требует
переупорядочивать пакеты. Необходимость реализации возможности работы
технологий с коммутацией каналов в сетях с коммутацией пакетов породила
новые задачи. Эти задачи направлены на то, чтобы службы могли отличать
голосовые данные от других данных. Решение включает в себя изоляцию трафика
VoIP различных VLAN и присвоение более высокого приоритета для обеспечения
качества передачи голоса. На коммутаторе можно настроить специальные
голосовые (voice VLAN), благодаря чему коммутатор сможет назначать
предварительно сконфигурированный параметр VLAN ID и более высокий
приоритет для VoIP-трафика.
Конфигурирование определенной голосовой VLAN осуществляется с помощью
команды voice-vlan <vlan-id> enable. Голосовая VLAN может быть ассоциирована с
любой VLAN в диапазоне от 2 до 4094. Команда voice-vlan mode <mode>
определяет рабочий режим, с помощью которого интерфейс порта добавляется в
голосовую VLAN. По умолчанию это происходит автоматически, но также может
быть выполнено вручную. Команда voice-vlan mac-address <mac-address> mask
<mask> позволяет идентифицировать голосовые пакеты с IP-телефона, и
ассоциировать их с голосовой VLAN на базе OUI (уникальный идентификатор в
пределах организации), чтобы в конечном итоге обеспечить голосовому трафику
более высокий приоритет.
Команда display voice-vlan status позволяет просматривать информацию голосовой сети
VLAN, включая состояние, режим безопасности, время устаревания и интерфейс, на
котором включена функция voice VLAN. Состояние (status) определяет, включена ли
голосовая VLAN в настоящее время или отключена. Режим безопасности (security mode)
имеет два значения: обычный (normal) и безопасный (security) режим. Обычный режим
позволяет интерфейсу со включенной голосовой VLAN передавать как голосовые
данные, так и служебные, но он остается уязвимым для атак недействительными
пакетами. Эта настройка используется, когда осуществляется передача нескольких
сервисов (HSI, VoIP и IP-ТВ) в сеть второго уровня через один интерфейс, и этот
интерфейс передает как голосовые данные, так и служебные данные. Режим
безопасности, примененный к интерфейсу со включенной голосовой VLAN, проверяет,
соответствует ли исходный MAC-адрес каждого пакета, который входит в голосовую
VLAN, значению OUI. Это применяется там, где интерфейс голосовой VLAN передает
ТОЛЬКО голосовые данные. Режим безопасности позволяет защитить голосовую VLAN
от атак недействительными пакетами, однако проверка пакетов занимает определенные
системные ресурсы.
Параметр Legacy определяет, может ли интерфейс взаимодействовать с голосовыми
устройствами других производителей, где включенный интерфейс означает, что такое
взаимодействие разрешено. Параметр Add-Mode определяет режим работы голосовой
VLAN. В режиме автоматической голосовой VLAN интерфейс может быть автоматически
добавлен к голосовой VLAN после того, как на интерфейсе будет включена функция
голосовой VLAN, и добавляет интерфейс, подключенный к голосовому устройству, к
голосовой VLAN, если исходный MAC-адрес пакетов, отправленных с голосового
устройства, соответствует OUI. Интерфейс будет автоматически удален, если он не
получит никаких пакетов с голосовыми данными от голосового устройства в течение
времени устаревания (aging time). В ручном режиме интерфейс должен быть добавлен к
голосовой VLAN вручную после включения функции голосовой VLAN на интерфейсе.
1. PVID на транковом канале определяет только характер тегирования, который
будет применяться на интерфейсе транкового канала. При использовании
команды port trunk allow-pass vlan 2 3, по магистральному каналу будут
передаваться только кадры, ассоциированные с VLAN 2 и VLAN 3.
2. Порт доступа, сконфигурированный с PVID 2, помечает все полученные
нетегированные кадры тегом VLAN 2. Это используется коммутатором для
определения, может ли кадр пересылаться через другие интерфейсы доступа
или будет передаваться по транковому каналу.
Принцип реализации VLAN заключается в обеспечении изоляции сетей, зачастую
как средства минимизации размера существующего широковещательного домена.
При этом пользователи одного домена VLAN будут изолированы от пользователей
в других доменах VLAN. Для восстановления связи между широковещательными
доменами по достижимым маршрутам требуется установление IP-связи на
третьем уровне. Идеальным решением для поддержки маршрутизации VLAN,
наряду с одновременным снижением эксплуатационных расходов, является
развертывание коммутатора третьего уровня. Однако одним из ограничений
маршрутизации VLAN является необходимость строгого управления IP-адресами.
В целом маршрутизация VLAN подходит для применения в небольших сетях, в
которых пользователи принадлежат к разным сегментам сети, а IP-адреса
пользователей редко меняются.
После конфигурирования VLAN хосты в различных VLAN не могут напрямую
взаимодействовать друг с другом на втором уровне. Поэтому для обеспечения
этого взаимодействия необходимо создать маршруты между VLAN. Как правило,
существуют два основных способа. Первый основан на развертывании
маршрутизатора, подключенного к коммутатору второго уровня. Трафик VLAN
проходит через маршрутизатор перед передачей в пункт назначения. Это может
быть реализовано посредством отдельных физических каналов, что приводит к
нерациональному и чрезмерному использованию ресурсов канала, или через
один физический интерфейс, как показано в примере.
Второй способ является более эффективным и основан на использовании
коммутатора третьего уровня, который совмещает в себе функции как
коммутатора, так и маршрутизатора.
Для обеспечения связи по отдельному интерфейсу соединительной линии
необходимо логически разделить физический канал на субинтерфейсы. Каждый
субинтерфейс представляет собой логический канал для передачи трафика
VLAN, прежде чем маршрутизатор передаст его через другие логические
субинтерфейсы в другие пункты назначения VLAN. Каждому субинтерфейсу
должен быть назначен IP-адрес в том же сегменте сети, что и VLAN, для которой
он создан. Поскольку трафик передается между несколькими VLAN IP-адрес
также необходим для инкапсуляции 802.1Q, которая обеспечит возможность
привязки трафика к VLAN.
Также необходимо сконфигурировать тип Ethernet-порта коммутатора, который
подключается к маршрутизатору, и осуществляет передачу либо по
соединительному каналу, либо по гибридному каналу, и разрешить прохождение
кадров связанных VLAN (в данном случае VLAN 2 и VLAN 3).
Для поддержки передачи трафика нескольких VLAN, необходимо установить
соединительную линию между коммутатором и маршрутизатором. Для этого
необходимо выполнить команду port link-type trunk или port link-type hybrid, а также
команду port trunk allow-pass vlan 2 3 или port hybrid vlan 2 3 соответственно. Для
логической передачи трафика между VLAN по соединительной линии, сразу же
после установления соединительной линии, необходимо создать субинтерфейсы
VLAN.
Для создания субинтерфейса маршрутизатора используется команда interface
<interface-type interface-number.sub-interface number> в интерфейсном режиме, где
sub-interface number – это канал логического интерфейса в физическом
интерфейсе. Команда dot1q termination vid <vlan-id> используется для выполнения
двух конкретных функций. При приеме пакета VLAN порт сначала удаляет тег
VLAN из кадра и передает этот пакет, используя маршрутизацию третьего уровня.
При отправке пакетов порт добавляет тег к кадру в соответствии с настройками
VLAN и IP для логического интерфейса маршрутизатора. Наконец, для каждого
логического интерфейса выполняется команда arp-broadcast enable. Это
необходимо, так как возможность широковещательной передачи ARP на
субинтерфейсах по умолчанию отключена. Если данная функция останется
отключенной, маршрутизатор будет отбрасывать пакеты. В таких случаях маршрут
до субинтерфейса, как правило, рассматривается как маршрут типа «черная
дыра», поскольку пакет фактически теряется без какой-либо трассировки. Если на
субинтерфейсе включена широковещательная передача ARP, то система может
создавать тегированные широковещательные пакеты ARP и отправлять их с
виртуального интерфейса.
После конфигурирования маршрутизации VLAN между VLAN 2 и VLAN 3 для
проверки достижимости маршрута используется команда ping. В данном примере
показано, как хост A (192.168.2.2) в VLAN 2 достигает хоста B (192.168.3.2) в VLAN
3. TTL означает, что пакет прошел маршрутизатор, чтобы достичь пункта
назначения в VLAN 2.
Использование коммутаторов третьего уровня для реализации маршрутизации
VLAN имеет свои преимущества, которые невозможно получить при
использовании маршрутизатора. Одним из таких преимуществ является
возможность передачи трафика VLAN с очень малой задержкой, благодаря
поддержке так называемой передаче трафика со скоростью линии. Это
реализуется благодаря использованию микросхем ASIC нижнего уровня, которые
позволяют передавать трафик на базе аппаратного, а не программного
обеспечения. Наряду с этим, отдельное устройство используется без
соединительной линии, на которой может возникнуть перегрузка при высокой
интенсивности трафика. Маршрутизация VLAN на базе коммутатора третьего
уровня зависит от реализации интерфейсов VLAN (VLANIF). Если несколько
пользователей сети принадлежат к разным VLAN, то для каждой VLAN необходим
VLANIF, который работает в качестве шлюза VLAN и, следовательно, должен
иметь привязку к IP-адресу, соответствующему сети VLAN. Однако, при наличии
большого количества VLAN требуется большое количество IP-адресов для
поддержки каждого VLANIF, а также хостов, которые являются частью VLAN, с
которой связан VLANIF. Благодаря VLANIF поддерживается маршрутизация между
различными VLAN.
Для конфигурирования маршрутизации VLAN на коммутаторе, работающем на
третьем уровне, необходимо, чтобы VLAN были созданы и ассоциированы с
соответствующими интерфейсами. Конфигурирование включает в себя настройку
параметра port link-type для каждого порта и PVID, который связан с каждым
интерфейсом порта.
Конфигурирование маршрутизации VLAN осуществляется путем создания
интерфейсов VLAN, которые функционируют в качестве интерфейсов шлюза для
каждой VLAN на коммутаторе третьего уровня. Для перехода к режиму VLANIF
необходимо выполнить команду interface vlanif <vlan-id>, где vlan-id означает
соответствующую VLAN. IP-адрес интерфейса должен находиться в том же
сегменте сети, что и хосты. Этот IP-адрес является шлюзом для хостов и
поддерживает связь между VLAN.
1. Команда dot1q termination vid <vlan-id> используется для выполнения двух
определенных функций. При получении пакета VLAN порт сначала удаляет тег
VLAN из кадра, а затем передает этот пакет посредством маршрутизации
уровня 3. При отправке пакета порт добавляет к нему тег в соответствии с
настройками VLAN и IP-адреса логического интерфейса маршрутизаторов.
2. На коммутаторе необходимо включить функцию присвоения тегов кадрам,
передаваемым через коммутатор или маршрутизатор. Это можно сделать с
помощью команды trunk или с помощью тегированных гибридных
интерфейсов. Кроме того, необходимо разрешить передачу трафика VLAN по
данному каналу с помощью команды port trunk allow-pass vlan <vlan> или port
hybrid tagged vlan <vlan>.
Последовательные соединения являются устаревшей технологией, которая до сих
пор используется для передачи данных в глобальной сети (WAN). Возможны два
режима последовательной передачи: синхронный и асинхронный. В режиме
асинхронной передачи данные дополняются специальными битами, называемыми
стартовым и стоповым. Назначение этих битов состоит в том, чтобы, во-первых,
известить приемник о приходе данных и, во-вторых, чтобы дать приемнику
достаточно времени для выполнения некоторых функций, связанных с
синхронизацией, до поступления следующего байта. Стартовый бит всегда имеет
значение 0, а стоповый бит – значение 1. Одной из основных проблем этого
режима передачи данных является дополнительная служебная информация для
каждого передаваемого кадра, причем стартовый и стоповый биты представляют
большой процент от общего размера кадра. Однако этот метод обычно
ассоциируется с такими технологиями, как ATM, в которой генерируются кадры
(ячейки) фиксированного размера 53 байта, что обеспечивает более низкий
джиттер путем минимизации времени обработки очередей. Благодаря этим
особенностям, данный метод становится идеальным решением для реализации
связи в режиме реального времени, например голосовой связи. Однако данный
метод начал уступать место новым технологиям, таким как коммутация MPLS, так
как не выдерживает с ними конкуренции в плане скоростей обработки кадров,
которые теперь возможны с помощью маршрутизаторов и коммутаторов.
В синхронном режиме передачи используется механизм синхронизации между
одноранговыми устройствами, в которых одна сторона (DCE)
предоставляет тактовые сигналы для синхронизации связи. Эти тактовые
сигналы добавляются к данным и передаются между отправителем и
получателем.
Высокоуровневый протокол управления каналом передачи данных (HDLC) – это
бит-ориентированный протокол канального уровня сетевой модели OSI,
способный поддерживать как синхронную, так и асинхронную передачу данных.
Полный кадр HDLC состоит из полей Flag, которые используются для маркировки
начала и конца кадра HDLC, часто как 01111110 или 01111111, когда кадр должен
быть внезапно отменен и отброшен. Поле Address необходимо, когда один или
несколько вторичных терминалов обмениваются данными с первичным
терминалом в многоточечной (многоабонентской) топологии, которая считается
топологией с несбалансированными соединениями, в отличие от более широко
применяемых сбалансированных («точка-точка») соединений. Поле Control
определяет тип кадра как информационный, контрольный или ненумерованный, а
также поле FCS (контрольная сумма проверки кадра) для обеспечения
целостности кадра.
Из типов кадров, определяемых полем Control, маршрутизаторы Huawei серии
ARG3 поддерживают только тип информационного кадра, который используется
для передачи данных. Информационный тип кадра передает N(S) и получает N(R)
порядковых номеров, а также Poll and Final bits (P/F) для передачи состояния
связи между первичной и вторичной станциями. Контрольные типы кадров в
HDLC используются для управления ошибками и потоками, а ненумерованные
типы кадров используются для управления установлением линии связи,
например, между первичной и вторичной станциями.
Использование HDLC в качестве протокола канального уровня по
последовательным соединениям требует настройки протокола связи с помощью
команды link-protocol hdlc в режиме интерфейса для последовательного
интерфейса. До установления соединения типа «точка-точка» необходимо на
обоих одноранговых интерфейсах, подключенных к сети, выполнить
конфигурирование протокола канала.
Если у интерфейса нет IP-адреса, он не может генерировать маршруты и
пересылать пакеты. Механизм ненумерованного IP-интерфейса позволяет
интерфейсу без IP-адреса заимствовать IP-адрес другого интерфейса. Механизм
ненумерованного IP-интерфейса позволяет оптимизировать использование
ресурсов IP-адресов, так как не требует, чтобы интерфейс постоянно занимал
определенный IP-адрес. Рекомендуется, чтобы IP-адрес для ненумерованного
интерфейса заимствовался у loopback-интерфейса, поскольку интерфейсы этого
типа, как правило, всегда активные и могут предоставлять доступные адреса.
При использовании механизма ненумерованного интерфейса необходимо
конфигурировать статический маршрут или протокол динамической
маршрутизации, чтобы интерфейс, заимствующий IP-адрес, мог генерировать
маршрут между устройствами. Если используется протокол динамической
маршрутизации, то длина полученной маски маршрута должна быть больше, чем
длина маски IP-адреса арендодателя, поскольку маршрутизаторы серии ARG3 при
поиске маршрутов используют правило самого длинного соответствия. Если
используется статический маршрут, а IP-адрес арендодателя использует 32-
битную маску, длина маски статического маршрута должна быть короче 32 бит.
Если используется статический маршрут, а IP-адрес арендодателя использует
маску, которая короче 32-бит, то длина маски статического маршрута должна быть
больше длины маски IP-адреса арендодателя.
С помощью команды display ip interface brief можно вывести на экран сводную
информацию о назначении адресов. В случае назначения адреса
ненумерованному интерфейсу значение адреса будет отображаться на
нескольких интерфейсах, свидетельствуя о том, что IP-адрес был успешно
заимствован у логического loopback-интерфейса для использования на
физическом последовательном интерфейсе.
Протокол PPP (протокол типа «точка-точка») – это протокол канального уровня,
который инкапсулирует и передает пакеты сетевого уровня по прямому каналу
связи между двумя устройствами. PPP поддерживает двухточечную передачу
данных по полнодуплексным синхронным и асинхронным каналам.
PPP построен на базе Интернет-протокола для последовательного канала (SLIP).
PPP поддерживает как синхронные, так и асинхронные каналы, тогда как другие
протоколы канального уровня, такие как Frame Relay (FR), поддерживают только
синхронные каналы. PPP является расширяемым протоколом и поддерживает
расширение не только IP, но и других протоколов, а также согласование атрибутов
канального уровня. Для согласования различных атрибутов сетевого уровня PPP
поддерживает несколько протоколов управления сетью (NCP), таких как
управляющий протокол семейства IP (IPCP) и протокол управления межсетевым
обменом пакетами (IPXCP). PPP предоставляет протокол аутентификации по
паролю (PAP) и протокол аутентификации с предварительным согласованием
вызова (CHAP) для обеспечения сетевой безопасности. PPP не поддерживает
механизм повторной передачи, что снижает стоимость сети и приводит к
ускорению передачи пакетов.
Инкапсуляция PPP предусматривает одновременное мультиплексирование
различных протоколов сетевого уровня в одном канале. Однако в современных
сетях для использования возможностей PPP обычно необходима поддержка
решения «IP only». Универсальность PPP при использовании в различных средах
хорошо поддерживается с помощью протокола управления каналом (Link Control
Protocol, LCP). Для установления двухточечного соединения каждый конец канала
PPP должен сначала отправить пакеты LCP, которые позволят сконфигурировать
и протестировать канал передачи данных. В частности, LCP используется для
согласования параметров и определения формата инкапсуляции, управления
MRU пакетов, обнаружения loopback-канала с помощью специального кода (Magic-
Number) и определения ошибок в конфигурации параметров, а также для
завершения работы установленного канала связи. Дополнительные средства LCP
обеспечивают одноранговую аутентификацию на канале, а также определение
исправной работы и неисправности канала.
После установления связи и согласования дополнительных средств, как того
требует компонент LCP протокола PPP, должна осуществляться передача пакетов
NCP для выбора и конфигурирования одного или нескольких протоколов сетевого
уровня. Типичные протоколы управления сетью на базе IP обеспечивают такие
функции, как конфигурирование адресов (IPCP) и сжатие заголовков TCP/IP по
методу Ван Якобсона.
Инициирование и завершение работы канала PPP начинается и заканчивается
этапом Dead. Когда два устройства связи обнаруживают, что между ними
активирован физический канал (например, на физическом канале
обнаруживаются сигналы несущей), то PPP переходит от этапа Dead к этапу
Establish. На этапе Establish два устройства выполняют настройку LCP для
согласования рабочего режима (одноканальный (SP) или многоканальный (MP)),
максимальной длины получаемых пакетов (MRU), режима аутентификации и т. д.
Если сконфигурирован режим аутентификации, то будет инициирован
дополнительный этап Authenticate. PPP предоставляет два режима
аутентификации по паролю: аутентификация PAP и аутентификация CHAP.
Доступны два режима аутентификации CHAP: однонаправленная и
двунаправленная. В процессе однонаправленной аутентификации CHAP
устройство на одном конце является аутентифицирующим устройством, а
устройство на другом конце - аутентифицируемым. При двунаправленной
аутентификации CHAP оба устройства проверяют друг друга перед
установлением соединения. Однако на практике используется только
однонаправленная аутентификация CHAP. После успешной аутентификации
начинается этап Network, на котором выполняется настройка NCP для
согласования и конфигурирования параметров сетевого протокола и параметров
сетевого уровня.
Открытие и закрытие каждого NCP может осуществляться в любое время. После
открытия NCP ​данные сетевого уровня могут передаваться по каналу
PPP.
PPP может закрыть канал связи в любое время. Канал связи может быть
закрыт вследствие какого-либо сбоя в работе, сбоя аутентификации и т.
д., а также вручную администратором.
PPP обычно использует формат кадров HDLC для передачи данных по
последовательным соединениям. Поля Flag используются для обозначения
начала и конца кадра PPP, который можно идентифицировать из двоичной
последовательности 01111110 (0x7E). Поле Address, хотя и присутствует, но не
применяется к PPP, как и в случае с HDLC, и поэтому всегда должно содержать
значение 11111111 (0xFF), которое означает адрес «All-Stations». Поле Control
также имеет фиксированное значение 00000011 (0x03), представляющее
ненумерованную информационную команду.
Контрольная сумма проверки кадра (FCS) обычно представляет собой 16-битное
значение, используемое для поддержания целостности кадра PPP. PPP
дополнительно определяет 8 или 16-битное поле протокола, которое
идентифицирует дейтаграмму, инкапсулированную в поле Information пакета.
Типичным примером является 0xc021 для протокола управления каналом, 0xc023
для протокола аутентификации по паролю и 0xc223 для протокола
аутентификации с предварительным согласованием вызова. Поле Information
содержит дейтаграмму для протокола, указанного в поле Protocol.
Максимальная длина поля Information (за исключением поля Protocol)
определяется максимальной длиной получаемых пакетов (MRU), которая по
умолчанию равна 1500 байтов. Там где реализовано значение 0xc021,
взаимодействующие друг с другом устройства выполняют согласование путем
обмена пакетами LCP для установления канала PPP.
Формат пакета LCP включает поле Type, определяющее различные типы
пакетов во время согласования PPP, например Configure-Request (0x01),
Configure-Ack (0x02), Terminate-Request (0x05) и т.д. Поле Data включает
различные параметры тип/длина/значение (TLV) для согласования,
включая MRU, протоколы аутентификации и т. д.
Для осуществления согласования LCP определено несколько типов пакетов,
которые позволяют согласовывать параметры до установления канала передачи
данных PPP. Необходимо, чтобы два взаимодействующих устройства согласовали
атрибуты канального уровня, такие как MRU и режим аутентификации. Чтобы
достичь этого, используются различные типы пакетов.
Тип пакета Configure-Request передается для инициирования согласования LCP
между одноранговыми устройствами. Существует несколько типов ответных
пакетов. Если все параметры конфигурации, полученные в запросе, можно
распознать, и их значения являются приемлемыми, то будет передан тип пакета
Configure-Ack.
Если все параметры конфигурации в пакете Configure-Request распознаны, но
некоторые значения не приемлемы, то передается пакет Configure-Nak с
указанием непринятых параметров. Configure-Reject используется, когда
определенные параметры конфигурации, полученные в Configure-Request, не
распознаются и, следовательно, не принимаются для согласования.
К общим параметрам конфигурации, которые согласовываются и передаются как
часть пакета LCP, относятся MRU, протокол аутентификации, поддерживаемый
узлом-отправителем пакета, а также параметр Magic-Number.
Данный параметр предоставляет метод обнаружения закольцованных каналов и
других ошибок канального уровня. При получении сообщения Configure-Request,
содержащего Magic-Number в качестве параметра конфигурирования,
осуществляется сравнение полученных Magic-Number в разных сообщениях
Configure-Request, отправленных одноранговому узлу. Если два Magic-Number в
полученных сообщениях Configure-Request отличаются, то считается, что канал не
закольцован. В ответ отправляется сообщение Request-Ack. Однако, если два
Magic-Number равны друг другу, то существует вероятность, что канал
закольцован, и для данного сообщения Configure-Request необходимо выполнить
дополнительную проверку. Для запроса другого значения параметра Magic-
Number выполняется отправка сообщения Configure-Nak.
Перед установлением соединения PPP между двумя одноранговыми узлами
осуществляется отправка пакета Configure-Request на одноранговое устройство.
После получения данного пакета получатель должен оценить параметры
конфигурации, чтобы определить формат пакета для ответа. В случае, если все
полученные параметры конфигурации распознаны, а их значения являются
приемлемыми, то получатель отвечает отправкой пакета Configure-Ack.
Если после передачи пакета Configure-Request в рамках согласования PPP все
параметры конфигурации распознаны, но некоторые значения являются
неприемлемыми, то отправляется ответный пакет Configure-Nak. При получении
пакета Configure-Nak генерируется и отправляется новый Configure-Request с
соответствующими изменениями параметров конфигурации.
В пакете Configure-Nak может быть указано несколько вариантов значений
параметров конфигурации. Одноранговый узел должен выбрать одно значение
для его включения в следующий пакет Configure-Request.
Если в процессе согласования LCP PPP один или несколько параметров
конфигурации, полученных в Configure-Request, не распознаны или считаются
неприемлемыми для согласования, передается пакет Configure-Reject. После
получения сообщения Configure-Reject неприемлемые параметры конфигурации
не будут включены в новый пакет Configure-Request.
При установке PPP необходимо указать протокол канального уровня на
последовательном интерфейсе. Для маршрутизаторов серии ARG3 протокол PPP
включен по умолчанию на последовательном интерфейсе. В случае, если
интерфейс в настоящее время не поддерживает PPP, используется команда link-
protocol ppp для включения PPP на канальном уровне. Будет запрошено
подтверждение изменения протокола инкапсуляции, как показано в примере
конфигурирования.
PAP – это протокол аутентификации путем двухстороннего «рукопожатия»,
который передает имя пользователя и пароль в виде простого текста. При
первоначальном установлении соединения выполняется аутентификация PAP.
После завершения этапа установления соединения одноранговое устройство
будет повторно отправлять имя пользователя и пароль аутентифицирующему
устройству до тех пор, пока аутентификация не будет подтверждена или
соединение не будет разорвано. Аутентификация PAP эффективно моделирует
операции входа в систему, в которых для установления доступа к удаленному
хосту используются пароли, которые вводятся в виде простого текста. Устройство,
прошедшее аутентификацию, отправляет локальное имя пользователя и пароль
устройству, которое выполняет аутентификацию. Аутентифицирующее устройство
проверяет имя пользователя и пароль аутентифицируемого устройства по
таблице локальных пользователей и отправляет соответствующий ответ
аутентифицируемому устройству для подтверждения или отклонения
аутентификации.
Протокол аутентификации с предварительным согласованием вызова (CHAP)
используется для периодической проверки однорангового устройства с помощью
механизма «трехстороннего рукопожатия». Это выполняется при первоначальном
установлении соединения и может периодически повторяться. Принципиальным
отличием CHAP является защита, обеспечиваемая путем предотвращения
передачи любого пароля по каналу. Вместо этого CHAP использует процесс
отправки запроса и получения ответа, который может быть успешным только в
том случае, если оба устройства (аутентифицирующее и аутентифицируемое)
поддерживают секретный код. Алгоритм, например MD5, обычно используется для
хэширования любого запроса и ответа, чтобы гарантировать целостность
значения и результирующего хэш-значения, и сравнивается с результатом,
сгенерированным аутентифицирующим устройством. Если значения совпадают,
то это означает, что устройство успешно прошло аутентификацию.
Протокол управления IP (IPCP) отвечает за конфигурирование, включение и
отключение модулей IP-протокола с обеих сторон двухточечного канала (point-to-
point). IPCP использует тот же механизм обмена пакетами, что и протокол
управления каналом (LCP). Обмен пакетами IPCP не возможен, пока PPP не
достигнет этапа Network. Пакеты IPCP, полученные до достижения этого этапа,
будут отбрасываться без уведомления. Параметр конфигурации согласования
адресов определяет способ согласования IP-адреса, который будет
использоваться на локальном конце канала. Статически определенный метод
позволяет отправителю Configure-Request указать, какой IP-адрес требуется.
После конфигурирования IP-адреса отправляется сообщение Configure-Request,
содержащее требуемый IP-адрес, а затем одноранговое устройство передает
Configure-Ack, чтобы подтвердить, что IP-адрес принят.
Локальное устройство, работающее как клиент, и которому необходимо назначить
IP-адрес в диапазоне удаленного устройства (сервера), должно отправить запрос
на допустимый адрес, использовав команду ip address-pppgotiate на физическом
интерфейсе, по которому клиент взаимодействует с сервером. С помощью
данного метода клиент может получить действительный адрес. Это применимо в
тех случаях, когда клиент получает доступ к сети Интернет через сеть поставщика
Интернет-услуг (ISP), и через которую он может получить IP-адрес от поставщика.
Адрес будет предложен клиенту после получения запроса на конфигурирование
без указанного IP-адреса. Сервер PPP (RTB) отвечает сообщением Configure-Nak
с рекомендуемыми параметрами IP-адреса для RTA. Последующее сообщение
Configure-Request с изменением IP-адресации позволяет (NCP) IPCP успешно
устанавливать протоколы сетевого уровня.
Для аутентификации PAP необходимо, чтобы один одноранговый узел работал в
качестве аутентифицирующего устройства, а второй – в качестве
аутентифицируемого устройства. Аутентифицирующее устройство PPP PAP
определит режим аутентификации, локальное имя пользователя и пароль, а также
тип сервиса. Если указан домен, которому принадлежит локальный пользователь
(как определено AAA), то в режиме аутентификации PAP также должен быть
указан домен аутентификации.
Аутентифицируемый одноранговый узел запрашивает имя пользователя и пароль,
установленные аутентифицирующим устройством. Для этого на
аутентифицируемом устройстве необходимо выполнить команду ppp pap local-
user <username> password { cipher | simple } <password>.
С помощью команд отладки, которые обеспечивают вывод информации
определенных протоколов в реальном времени, можно посмотреть процесс
запроса аутентификации. Как показано в примере, был выполнен запрос PAP-
аутентификации, который завершился успешным прохождением аутентификации.
При аутентификации CHAP аутентифицируемое устройство отправляет
аутентифицирующему устройству только имя пользователя. Считается, что CHAP
обеспечивает более высокий уровень безопасности, поскольку пароли не
передаются по каналу. Вместо этого передаются хэшированные значения для
проверки аутентифицируемого устройства на базе сконфигурированного пароля
на двух одноранговых устройствах. При самой простой реализации CHAP
выполняется на базе параметров локального пользователя, как с PAP, или может
включать более строгие формы аутентификации и учета при использовании AAA и
серверов аутентификации/учета.
Как показано в примере, для конфигурирования CHAP на базе локально
определенных пользователей необходима ограниченная конфигурация
параметров локальных пользователей и включение режима аутентификации
CHAP PPP на аутентифицирующем устройстве. Там, где существуют домены, для
определения используемого домена (если он отличается от домена по
умолчанию) может потребоваться аутентифицирующее устройство.
С помощью команды debugging ppp chap all можно посмотреть этапы
аутентификации CHAP. При отправке запроса аутентифицируемое устройство
должно предоставить ответ, для которого генерируется хэш-значение, включая
установленные параметры аутентификации на аутентифицируемом одноранговом
устройстве (пароль), чтобы аутентифицирующее устройство, выполнило
незамедлительную проверку и предоставило ответ об успешном завершении или
неудаче.
1. При использовании PPP в качестве режима инкапсуляции канального уровня
пакет Configure-Ack должен быть отправлен для успешного установления
канального уровня.
2. Для согласования модулей IP-протокола как части процесса согласования NCP
используется протокол управления IP-протоколом (IPCP). Согласование
происходит во время фазы Network.
DSL является технологией широкополосной связи, которая использует
существующие телефонные сети для передачи данных. Связь осуществляется
через удаленный блок трансивера или модем в помещении клиента, который
связывается по существующим телефонным линиям с блоком трансивера в
центральном офисе. Блок трансивера в центральном офисе является
мультиплексором доступа цифровой абонентской линии (Digital Subscriber Line
Access Multiplexer, DSLAM), который мультиплексирует трафик для
транспортировки по каналам высокоскоростной сети ATM или сети Ethernet, а
затем на маршрутизатор широкополосного удалённого доступа (Broadband
Remote Access Server, BRAS) или сервер PPPoA/PPPoE в сети провайдера услуг.
Расстояние между трансиверами зависит от применяемой технологии DSL. В
случае использования асинхронной цифровой абонентской линии (ADSL)
расстояние увеличивается примерно до 5460 метров в традиционной сети АТМ,
тогда как при использовании высокоскоростной цифровой абонентской линии
(VDSL2) расстояние между локальными шлейфами составляет всего лишь около
1500 метров из-за применения технологии FTTx для обеспечения Ethernet-
передачи трафика на BRAS (сервер PPPoE).
PPPoE – это протокол инкапсуляции кадров PPP и их передачи через Ethernet для
обеспечения высокоскоростного соединения с маршрутизатором
широкополосного удалённого доступа (BRAS), расположенным в сети провайдера
услуг. Это необходимо для реализации процесса аутентификации и учета до
получения доступа к удаленной сети, такой как Интернет. Маршрутизатор RTA
выполняет функции клиента для установления сеанса PPPoE с сервером PPPoE,
через который устанавливается авторизованное соединение для доступа к
удаленным сетям и ресурсам. Модем DSL обеспечивает модуляцию и
демодуляцию сигналов, передающихся по медным телефонным проводам,
которые существует в домах и офисах.
Процесс функционирования PPPoE разделен на два отдельных этапа: этап
обнаружения и этап сеанса PPP. При инициации клиентом сеанса PPPoE он
должен пройти этап обнаружения, который состоит из четырех шагов, на каждом
из которых осуществляется отправка определенного пакета. На первом шаге
клиент посылает широковещательный запрос (PADI PPPoE Active Discovery
Initiation) на поиск сервера со службой PPPoE. Этот запрос получают все
пользователи сети, но ответит на него только тот, у кого есть поддержка службы
PPPoE. Ответный пакет от концентратора доступа (PADO PPPoE Active Discovery
Offer) посылается в ответ клиенту, но если в сети есть много устройств со службой
PPPoE, то клиент получит много пакетов PADO. В этом случае, программное
обеспечение клиента выбирает необходимый ему концентратор доступа и
посылает ему пакет (PADR PPPoE Active Discovery Request) с информацией о
требуемой службе (требуемый класс обслуживания зависит от услуг провайдера),
имя провайдера и т.д. После получения запроса, концентратор доступа
подготавливается к началу сеанса PPP и посылает клиенту пакет PADS (PPPoE
Active Discovery Session-confirmation). Если все запрашиваемые клиентом службы
доступны (в состав этого пакета входит уникальный идентификатор сеанса,
присвоенный концентратором), то начинается второй этап - стадия установленной
сеанса. Если требуемые клиентом услуги не могут быть предоставлены, клиент
получает пакет PADS с указанием ошибки в запросе услуги. Завершение
соединения PPPoE происходит по инициативе клиента или концентратора
доступа при помощи посылки пакета PADT (PPPoE Active Discovery Terminate).
На этапе обнаружения, когда клиент (RTA) обращается к серверу, используя
PPPoE, клиент должен идентифицировать MAC-адрес Ethernet-сервера и
установить идентификатор сеанса PPPoE. По завершению этапа обнаружения
оба одноранговых узла знают значение идентификатора сеанса Session_ID
PPPoE и Ethernet-адреса друг друга, которые совместно обеспечивают
уникальную идентификацию сеансов PPPoE. Процесс обнаружения включает
широковещательную передачу клиентом пакета PADI, в котором содержится
информация о необходимой клиенту услуге. После получения пакета PADI
серверы сравнивают запрашиваемые услуги с услугами, которые они могут
предоставить. В пакете PADI параметр Destination_address является
широковещательным адресом, поле Code имеет значение 0x09, а поле Session_ID
– значение 0x0000.
Серверы, которые могут предоставить запрошенные услуги, отправляют ответные
пакеты PADO. Клиент (RTA) может получить несколько пакетов PADO от разных
серверов. Поле адреса пункта назначения – это индивидуальный адрес клиента,
который отправляет пакет PADI. Поле Code имеет значение 0x07. Поле Session_ID
имеет значение 0x0000.
Поскольку выполняется широковещательная передача пакетов PADI, то клиент
может получить более одного пакета PADO. Он просматривает все принятые
пакеты PADO и выбирает один сервер на основании параметра AC-Name (имя
концентратора доступа), который однозначно идентифицирует один сервер от
другого, или на базе услуг, предлагаемых в пакете PADO. Далее клиент
отправляет пакет PADR на выбранный сервер. В качестве адреса пункта
назначения устанавливается индивидуальный адрес сервера доступа, который
отправил выбранный пакет PADO. Поле Code имеет значение 0x19. Поле ID
сеанса имеет значение 0x0000.
При получении пакета PADR сервер доступа начинает готовиться к началу сеанса
PPPoE. Он генерирует уникальный идентификатор для сеанса PPPoE и
отправляет клиенту пакет PADS с подтверждением. Поле адреса пункта
назначения – это индивидуальный Ethernet-адрес клиента, который был указан в
пакете PADR. Поле Code имеет значение 0x65. Для параметра ID сеанса
необходимо установить значение, созданное для данного сеанса PPPoE. Сервер
генерирует уникальный идентификатор для идентификации сеанса PPPoE с
клиентом и отправляет его в пакете PADS. Если ошибок не возникает, то и сервер,
и клиент переходят к этапу установленного сеанса PPPoE.
После начала сеанса PPPoE выполняется отправка данных PPP, как и при любой
другой инкапсуляции PPP. Все Ethernet-пакеты являются одноадресными. Поле
ETHER_TYPE имеет значение 0x8864. Для кода PPPoE должно быть установлено
значение 0x00. Значение SESSION_ID должно быть значением, определенным на
этапе обнаружения, и не должно меняться для данного сеанса PPPoE. Пакет
PPPoE включает кадр PPP. Кадр начинается с PPP Protocol-ID.
В процессе установления сеанса PPPoE выполняется согласование LCP PPP,
после чего согласовывается максимальный размер получаемых пакетов (MRU).
Максимальный размер полезной нагрузки в пакете Ethernet обычно не превышает
1500 байт, из которых 6 байтов занимает заголовок PPPoE и 2 байта – ID
протокола PPP. Максимальный размер получаемых пакетов PPP (MRU) не может
быть больше 1492 байтов, поскольку это может привести к фрагментации пакета.
Когда LCP завершает работу, клиент и концентратор доступа (сервер) прекращают
использовать этот сеанс PPPoE. Если клиенту необходимо запустить другой сеанс
PPP, то он возвращается к этапу обнаружения.
Пакет PADT, отправленный в любое время после установления сеанса, служит
подтверждением завершения сеанса PPPoE. Пакет PADT может быть отправлен
клиентом или сервером доступа. Поле адреса пункта назначения – это
индивидуальный адрес Ethernet. Поле Code имеет значение 0xA7. ID сеанса
должен быть установлен для определения сеанса, который завершается. Для
пакета PADT тег не требуется. После получения пакета PADT трафик PPP уже не
может передаваться в данном сеансе PPPoE. После отправки или получения
пакета PADT даже обычные пакеты завершения PPP не могут быть отправлены.
Одноранговый узел PPP должен использовать протокол PPP для завершения
сеанса PPPoE, но так как PPP не может использоваться, то используется пакет
PADT.
Для настройки клиента PPPoE требуется выполнить три отдельных шага, начиная
с настройки интерфейса номеронабирателя (Dialer). Эти настройки необходимы
для того, чтобы устанавливать соединение по требованию и разрывать
соединение, если оно не будет использоваться в течение определенного периода
времени. Команда dialer-rule позволяет перейти в режим dialer-rule, в котором
можно настроить параметр dialer-rule для определения условий инициирования
соединения PPPoE.
Пользователь выбирает интерфейс номеронабирателя для приема вызова в
соответствии с именем удаленного пользователя, согласованным с PPP.
Пользователь номеронабирателя запускает центр управления набором номера и
указывает имя удаленного конечного пользователя, которое должно совпадать с
именем пользователя PPP на удаленном оконечном сервере. Если параметр user
name не указан в команде undo dialer user, то функция центра управления
набором номера отключена, и все имена удаленных пользователей будут
удалены. Если же данный параметр указан, то будет удалено только указанное
имя пользователя. Для привязки физических интерфейсов и интерфейсов
номеронабирателя в AR2200E используется команда dialer bundle <number>.
Для аутентификации клиентского соединения с сервером необходимо настроить
параметры аутентификации PPP, а также выполнить команду ip address ppp-
negotiate для согласования параметров на интерфейсе, чтобы интерфейс мог
получить IP-адрес от удаленного устройства.
Второй этап включает в себя установление привязки сеанса PPPoE группы
номеронабирателя к интерфейсу, с помощью которого должно выполняться
согласование сконфигурированных параметров номеронабирателя. Для этого
используется команда pppoe-client dial-bundle-number <number>, где number – это
номер группы, сконфигурированной вместе в параметрами номеронабирателя.
Если параметр on-demand не задан, сеанс PPPoE находится постоянно в онлайн-
режиме. Если данный параметр указан, сеанс PPPoE работает в режиме набора
номера по требованию. AR2200 поддерживает режим запуска пакетов для набора
номера по требованию. В постоянном онлайн-режиме AR2200 инициирует сеанс
PPPoE сразу после установления физического канала. Сеанс PPPoE
продолжается до тех пор, пока не будет выполнена команда undo pppoe-client dial-
bundle-number для его завершения. В онлайн-режиме, который был запущен,
AR2200 не инициирует сеанс PPPoE сразу же после установления физического
канала. Вместо этого AR2200 инициирует сеанс PPPoE, только при необходимости
передачи данных по каналу. Если данные не передаются по каналу PPPoE в
течение интервала, указанного в параметре dialer timer idle <seconds>, то AR2200
завершает сеанс PPPoE. При необходимости передачи данных по каналу PPPoE
AR2200 снова устанавливает сеанс PPPoE.
На последнем шаге необходимо настроить статический маршрут по умолчанию,
чтобы разрешить трафику, для которого сеть назначения не определена,
установить наиболее длинное совпадение в таблице маршрутизации, для
инициирования сеанса PPPoE через интерфейс номеронабирателя.
Для проверки текущего статуса конфигурации номеронабирателя и обнаружения
ошибок на интерфейсе номеронабирателя используется команда display interface
dialer. Текущий статус номеронабирателя «UP» указывает, что интерфейс активен,
а статус «DOWN» свидетельствует о наличии неисправности. Статус протокола
линии – это статус протокола канального уровня, значение «UP» подтверждает
активное соединение.
Канал будет иметь статус «DOWN», если для его интерфейса не назначен IP-
адрес, или он находится в подавленном состоянии. Подавление может быть
вызвано демпфированием интерфейса, главным образом из-за нестабильности
интерфейса. После перехода согласования LCP PPP в статус «Opened» таймеры
удержания соединения PPP отправляют heartbeat-сигналы. Согласование
интернет-адреса выполняется из пула IP-адресов на сервере PPPoE. Если адрес
отсутствует, то система выдаст сообщение «Internet protocol processing: disabled»
(«Обработка интернет-протокола отключена»). IP-адрес назначается при
согласовании соединения, т.е. посредством отправки ping-запроса в пул.
Статус согласования LCP определяет текущее состояние, где «initial» указывает,
что обнаружены неисправности на физическом уровне, или что согласование не
было начато. Статус «Opened» означает, что система отправила пакет Configure-
Ack на одноранговое устройство и получила пакет Configure-Ack от этого
устройства. Это подтверждает исправность работы канального уровня.
Для предоставления информации о сеансах PPPoE на PPPoE-клиенте, включая
статус сеанса и статистику, используется команда display pppoe-client session
summary. Для того, чтобы показать разницу между статусами сеанса PPPoE,
приведены два примера. ID – это идентификатор PPPoE, в то время как
идентификатор группы и идентификатор номеронабирателя соответствуют
значениям, указанным в конфигурации параметров номеронабирателя.
Значение Intf – это интерфейс, на котором выполняется согласование на
стороне клиента. MAC-адрес клиента и сервера PPPoE также определены, однако
MAC-адрес сервера получает значение только после установления согласования.
PPPoE поддерживает четыре статуса. Статус «IDLE» указывает, что сеанс PPPoE
в настоящее время не установлен, и не было предпринято никаких попыток его
установить.
Статус «PADI» означает, что сеанс PPPoE находится на этапе обнаружения, и был
отправлен пакет PADI. Статус «PADR» означает, что сеанс PPPoE находится на
этапе обнаружения, и был отправлен пакет PADR. Статус «UP» указывает на то,
что сеанс PPPoE был успешно установлен.
Большая часть реализации PPPoE была сосредоточена на установлении
обычного соединения типа «точка-точка», однако это возможно только в
лабораторной среде. При практическом применении клиент PPPoE часто
представляет собой шлюз между корпоративной сетью и глобальной сетью (WAN),
к которой подключаются внешние узлы и устройства.
Внутренняя корпоративная сеть обычно использует схему частной сети для
сохранения адресов, и эти адреса не могут использоваться для установления IP-
связи через инфраструктуру сети общего пользования. Для этого необходимо,
чтобы AR2200 предоставлял функцию трансляции сетевых адресов (NAT) для
преобразования IP-адресов частной сети в IP-адреса сети общего пользования.
Данная функция позволяет упростить установление связи внутренней сети через
PPPoE.
1. Максимальный размер полезной нагрузки для IP-пакетов составляет 1500 байт,
однако при использовании вместе с PPPoE требуются дополнительные 6
байтов, а также еще 2 байта для идентификатора протокола PPP, что приводит
к превышению максимального размера полезной нагрузки в пакете. Таким
образом, согласованное значение MRU пакета LCP, поддерживающего PPPoE,
должно быть не более 1492 байтов.
2. Команда dialer bundle устанавливает привязку физического интерфейса с
интерфейсом номеронабирателя, который используется для установления
соединения PPPoE.
Одной из основных проблем, с которыми сталкивается расширяющаяся сеть,
является постепенное исчерпание IP-адресов в результате растущего на них
спроса. Существующая схема адресации IPv4 не справляется с постоянным
ростом числа устройств Интернет. IANA, отраслевой орган, который отвечает за
распределение адресов между региональными регистраторами по всему миру,
уже давно заявила об ограничении выделения адресов в связи с
израсходованием резерва.
Одним из временных решений стало выделение диапазона частных адресов на
базе существующих классов IP-адресов, которые можно использовать повторно.
Таким образом, в сетевых доменах стала возможной реализация схемы
адресации на базе диапазона частных адресов в соответствии с масштабом
сетевого домена. Это позволяет передавать трафик, источник и пункт назначения
которого находятся в одном домене, без расходования ценного резерва
публичных адресов.
Однако в этом случае возникает проблема организации маршрутов за пределами
домена частной сети, когда пункты назначения трафика существуют в публичном
домене или в другом частном домене за пределами этого публичного домена.
Технология преобразования сетевых адресов, позволяющая конечным
устройствам пересылать трафик через домен публичной сети из частной сети,
стала стандартным решением данной проблемы.
Механизм NAT определяет сетевые домены для преобразования по границе
маршрутизатор-шлюз. Домены рассматриваются как внутренние частные сети или
внешние публичные сети, между которыми выполняется NAT. Основной принцип
заключается в приеме трафика, адрес источника которого находится в частной
сети, а адрес пункта назначения — за пределами домена частной сети.
Предполагается, что маршрутизатор будет выполнять NAT для преобразования
частного адреса в публичный адрес таким образом, чтобы публичный адрес
назначения смог получить действительный обратный адрес, по которому можно
отвечать на полученные пакеты. NAT также должен создать таблицу
сопоставления в шлюзе, чтобы шлюз мог определить, по какому адресу
назначения частной сети должен быть отправлен пакет, полученный из публичной
сети, что снова требует преобразования адреса в обратном направлении.
Существует несколько концепций NAT, которые могут применяться в различных
ситуациях. Статический NAT представляет собой механизм прямого взаимно-
однозначного сопоставления «один к одному», которое позволяет преобразовать
IP-адрес конкретной конечной системы в конкретный публичный адрес. В больших
масштабах сопоставление «один к одному» не решает проблему нехватки
адресов, однако эта концепция применима в тех случаях, когда хосту необходимо
предоставить определенные привилегии относительно адреса, с которым хост
связан статически. Этот же принцип может также применяться к серверам, к
которым может потребоваться доступ из внешней сети по определенному
публичному адресу.
В данном примере пакеты от источника 192.168.1.1 передаются узлу с публичным
сетевым адресом 1.1.1.1. Сетевой шлюз RTA создает соответствие между
частным адресом 192.168.1.1 и публичным адресом 200.10.10.5, который
назначается в качестве исходного адреса пакета перед его передачей шлюзом к
планируемому месту назначения. Любой ответный пакет будет отправлен узлу
назначения с адресом 200.10.10.5, на котором шлюз будет выполнять статическое
преобразование, прежде чем пересылать пакет на ассоциированный хост
192.168.1.1. Статическое сопоставление адресов не требует реального
управления выделением адресов пользователям, поскольку адреса назначаются
вручную.
Динамический NAT работает по принципу адресных пулов, с помощью которых
внутренние конечные системы, планирующие передавать трафик через
публичную сеть, привязываются к публичному адресу из пула адресов. Конечные
системы, которым требуется установить связь с получателями в домене
публичной сети, должны быть привязаны к уникальному публичному адресу,
который доступен в диапазоне пула публичных адресов.
Адрес назначается из пула адресов сервера NAT, поскольку каждая конечная
система пытается перенаправить трафик в пункт назначения публичной сети.
Количество IP-адресов, принадлежащих серверу NAT, намного меньше
количества внутренних хостов, поскольку не все внутренние хосты одновременно
обращаются к внешним сетям. Обычно это определяется количеством внутренних
хостов, которые получают доступ к внешним сетям в часы пик.
Как показано в данном примере, два внутренних хоста генерируют пакеты,
предназначенные пункту назначения 1.1.1.1/24, при этом каждому внутреннему
хосту присваивается уникальный адрес из адресного пула для различия этих
хостов в публичной сети. При отсутствии необходимости связи через публичную
сеть данное сопоставление адресов будет удалено, чтобы вернуть публичный
адрес в адресный пул.
В дополнение к методу преобразования адресов «многие ко многим» в
динамическом NAT используется еще один метод — преобразование сетевых
адресов на уровне портов (NAPT), который реализует параллельное
преобразование. NAPT позволяет сопоставить несколько внутренних адресов
одному общему адресу. Это также называется многоадресной трансляцией
адресов или мультиплексированием адресов. NAPT сопоставляет IP-адреса и
интерфейсы. Дейтаграммы с разных внутренних адресов сопоставляются с
интерфейсами с одним публичным адресом и разными номерами портов, то есть
дейтаграммы имеют один и тот же публичный адрес.
Маршрутизатор получает пакет запроса, отправленный с хоста в частной сети для
доступа к серверу в публичной сети. Исходный IP-адрес пакета - 192.168.1.1, а
номер его порта - 1025. Маршрутизатор выбирает неиспользуемый публичный IP-
адрес и номер незанятого порта из пула IP-адресов и устанавливает прямые и
обратные записи NAPT, которые сопоставляют IP-адрес источника номеру порта
пакета, а также публичный IP-адрес номеру порта. Маршрутизатор преобразует
IP-адрес источника пакета и номер порта в публичный IP-адрес и номер порта на
базе прямой записи NAPT и отправляет пакет на сервер в публичной сети. После
трансляции исходный IP-адрес пакета - 200.10.10.11, а номер порта - 2843.
Процесс «Easy IP» используется в тех случаях, где узлам в небольших локальных сетях
требуется доступ к публичной сети или Интернет. Если планируется использовать только
несколько внутренних узлов, а исходящий интерфейс будет получать временный
публичный IP-адрес посредством коммутируемого доступа, обычно развертываются
небольшие LAN-сети. Для доступа к Интернет внутренние узлы используют временный
публичный IP-адрес, и для этого используется технология Easy IP.
В данном примере показан процесс Easy IP. Маршрутизатор получает пакет,
отправленный с хоста частной сети, который содержит запрос на доступ к серверу
публичной сети. IP-адрес источника пакета в данном случае - 192.168.1.1, а номер порта -
1025. Маршрутизатор устанавливает прямые и обратные записи Easy IP, которые
определяют соответствие между IP-адресом источника и номером порта пакета, а также
между публичным IP-адресом и номером порта интерфейса, подключенного к публичной
сети. Маршрутизатор выполняет преобразование IP-адреса источника и номера порта
пакета в публичный IP-адрес и номер порта и отправляет пакет на сервер публичной
сети. После преобразования IP-адрес источника пакета будет 200.10.10.1, а номер порта
- 2843.
Получив ответ от сервера, маршрутизатор запрашивает обратную запись Easy IP на
основе IP-адреса пункта назначения и номера порта. Маршрутизатор транслирует IP-
адрес и номер порта пункта назначения пакета в частный IP-адрес и номер порта хоста
частной сети и отправляет пакет на хост. После преобразования IP-адрес пункта
назначения пакета - 192.168.1.1, а номер порта - 1025.
NAT позволяет защитить хосты в частных сетях от пользователей публичных сетей. Если
пользователи публичной сети пользуются веб-сервисами и FTP-сервисами частной сети,
серверы в этой частной сети должны быть доступны таким пользователям в любое
время.
Данная проблема решается в помощью метода «сервер NAT», который преобразует
публичный IP-адрес и номер порта в частный IP-адрес и номер порта на основе
предварительно настроенного сопоставления.
Настройка записей преобразования адресов сервера NAT выполняется на
маршрутизаторе, после чего маршрутизатор получает запрос на доступ, отправленный с
хоста публичной сети. Маршрутизатор запрашивает запись преобразования адреса в
соответствии с IP-адресом пункта назначения пакета и номером порта. Маршрутизатор
транслирует IP-адрес и номер порта назначения пакета в частный IP-адрес и номер
порта согласно данной записи и отправляет пакет на сервер частной сети. IP-адрес
пункта назначения пакета, отправленного хостом публичной сети - 200.10.10.5, а номер
порта назначения - 80. После выполнения маршрутизатором преобразования IP-адрес
пункта назначения пакета будет 192.168.1.1, и его номер порта - 8080. После получения
ответного пакета, отправленного с сервера частной сети, маршрутизатор запрашивает
запись преобразования адреса в соответствии с IP-адресом исходного пакета и номером
порта. Маршрутизатор преобразует IP-адрес исходного пакета и номер порта в
публичный IP-адрес и номер порта на основе данной записи и отправляет пакет хосту
публичной сети. Источником ответного пакета, отправленного с хоста частной сети, будет
192.168.1.1, а номер порта - 8080. После преобразования маршрутизатором IP-адрес
источника пакета будет 200.10.10.5, и номером порта будет снова порт 80.
Статический NAT означает, что частный адрес будет статически привязан к
публичному адресу при выполнении преобразования. Публичный IP-адрес в
статическом NAT используется только для преобразования уникального и
фиксированного частного IP-адреса хоста. Команда nat static [protocol
{<tcp>|<udp>}global { <global-address >| current-interface <global-port>} inside {<host-
address> <host-port >} vpn-instance <vpn-instance-name> netmask <mask> acl <acl-
number> description <description >] используется для создания статического NAT и
определения параметров трансляции.
В приведенном примере используются ключевые параметры: глобальные
параметры для настройки внешних данных NAT, в частности внешнего адреса, и
внутренние параметры для настройки внутренних данных NAT. В обоих случаях
для трансляции определяется адрес и номер порта. Глобальный порт определяет
номер порта службы, предоставляемой для внешнего доступа. Если этот
параметр не указан, то значение параметра global-port равно 0. То есть может
быть предоставлен любой тип сервиса. Порт хоста определяет номер порта
сервиса, предоставляемый внутренним сервером. Если этот параметр не указан,
значение host-port совпадает со значением global-port.
Для просмотра конфигурации статического NAT используется команда display nat
static. Команда выводит информацию применительно к интерфейсу, через
который выполняется преобразование — глобальные и внутренние адреса
вместе с используемыми портами. Если порты не указаны, то в командном выводе
появится нулевой результат. При настройке механизма преобразования можно
указать протоколы TCP или UDP. В этом случае командный вывод будет
содержать запись Protocol.
Для конфигурирования динамического NAT используется команда nat outbound.
Для этого используется предварительно настроенный список контроля доступа к
сети, в котором указывается правило идентификации конкретного трафика, к
которому будет применено событие или операция. Подробная информация о
списках контроля доступа рассматривается в следующем разделе. Между
правилами контроля доступа и пулом адресов NAT должна быть установлена
связь. Таким образом, адреса, указанные в списке контроля доступа, могут
преобразовываться с использованием пула адресов NAT.
В данном примере показано, как выполнена привязка списка контроля доступа к
идентификатору 2000 с помощью команды nat outbound, чтобы преобразовать
адрес из сетевого диапазона 192.168.1.0/24 как часть адресной группы,
называемой группой адресов 1. Эти адреса определяют пул адресов в диапазоне
от 200.10.10.11 до 200.10.10.16, внутренние адреса которого будут использоваться
для преобразования. Параметр no-pat в команде означает, что преобразование
портов не будет выполняться, поэтому должно быть выполнено преобразование
адреса каждого хоста в уникальный глобальный адрес.
Используются две команды, которые позволяют проверить подробную
информацию о настройке динамического метода NAT. Команда display nat address-
group <group-index> позволяет определить общий диапазон сетевых адресов в
пуле, используемых для трансляции. Команда display nat outbound предоставляет
конкретные данные о любой конфигурации динамического NAT, примененной к
данному интерфейсу. В данном примере показано, что интерфейс Serial1/0/0
привязан к правилу списка контроля доступа вместе с группой адресов 1 для
преобразования адресов на данном интерфейсе. Значение no-pat подтверждает,
что преобразование адреса порта не выполняется.
Настройка «Easy IP» очень похожа на настройку динамического преобразования
сетевых адресов на базе созданного списка контроля доступа, в котором
определяется диапазон адресов, подлежащих преобразованию, и здесь также
используется команда nat outbound. Основное отличие заключается в отсутствии
команды address group, поскольку при настройке «Easy IP» пул адресов не
используется. Вместо этого для представления внешнего адреса используется
адрес исходящего интерфейса. В данном случае это внешний адрес 200.10.10.1
интерфейса serial1/0/0. Кроме того, здесь необходима трансляция порта, но
параметр no-pat не используется, если адресная группа не существует. nat
outbound 2000 – это привязка операции NAT к правилу списка контроля доступа с
подробным описанием диапазона адресов, к которому будет применяться
преобразование.
Одна и та же команда display nat outbound может использоваться для просмотра
результатов конфигурирования, выполненного командой nat outbound, и проверки
корректности настроек. Для исходящего преобразования (outbound NAT)
указывается привязка интерфейса к списку контроля доступа (ACL), а также сам
интерфейс (как в данном случае). Значение easyip в поле type подтверждает
правильность настройки «Easy IP».
При необходимости предоставления доступа к внутренней сети внешним
пользователям, например в случае общедоступного сервера, который является
частью внутренней сети, выполняется настройка сервера NAT, которая
преобразует внешний адрес назначения трафика и номер порта во внутренний
адрес назначения и номер порта.
Команда nat server [protocol {<tcp >|<udp>}global {<global-address> | current-interface
<global port>} inside {<host-address ><host-port> vpn-instance <vpn-instance-name>
acl <acl-number> description <description >] позволяет выполнять преобразование
внешнего адреса, где параметр protocol означает конкретный протокол (TCP или
UDP в зависимости от сервиса), используемый для преобразования, параметр
global address означает внешний адрес для трансляции, inside address означает
внутренний адрес сервера.
Необходимо определить номер порта для внешнего адреса, который обычно
связан с определенным сервисом, например http (www) на порте 80. В качестве
средства дальнейшего улучшения общей защиты номеров внутренних портов от
внешних угроз, для внутренней сети используется альтернативный номер порта, и
его преобразование выполняется с помощью тех же средств, которые
используются и для преобразования адресов.
С помощью команды display nat server можно просмотреть подробную
информацию с результатами конфигурирования и проверить правильность
настройки механизма сервера NAT. Интерфейс определяет узел, в котором будет
выполнено преобразование. Таким образом проверяются глобальные и
внутренние IP-адреса и привязанные номера портов. В приведенном примере
будет выполнено преобразование глобального адреса 202.10.10.5 с номером
порта 80 (www) во внутренний адрес сервера 192.168.1.1 с номером порта 8080 в
качестве дополнительной защиты от потенциальных атак на базе портов.
Преобразование будет выполнено только в отношении TCP-трафика,
направленного на данный адрес и порт.
С помощью настройки внутреннего сервера NAT выполняется привязка
уникального адреса публичной сети к узлу назначения сервера частной сети,
таким образом, после преобразования пропускается поток входящего трафика,
идущего из внешней сети. Внутренние пользователи могут получить доступ к
серверу по его частному адресу.
Функция PAT выполняет преобразование на базе номера порта, а также IP-
адресов. Функция позволяет экономить адреса в условиях, когда количество
адресов публичной сети, доступных для преобразования, ограничено или
недостаточно для поддержки тех частных адресов, которым, возможно,
потребуется преобразование.
Список контроля доступа (ACL) – это механизм, который управляет доступом к
системным ресурсам путем составления списка объектов, которым разрешен
доступ к определенному ресурсу, на базе определенных параметров, а также
разрешает доступ в определенном режиме. В целом, можно ACL рассматривать
как средство фильтрации и применять для управления потоком трафика, а также
для определения трафика, с которым должны выполняться особые операции.
В общем сценарии сети используется шлюз, у которого есть узел назначения,
осуществляющий пересылку в различные сети. В этом сценарии для принятия
решения, какой поток трафика в какую сеть будет направлен, можно применить
механизм ACL. В данном примере сеть 192.168.1.0/24 рассматривается как
имеющая доступ к внешней сети, в данном случае к Интернет, тогда как узлы,
представленные сетью 192.168.2.0/24, не могут пересылать трафик. Таким
образом, это приводит к сбою передачи. В случае с сервером A, наоборот -
разрешение на доступ шлюз предоставляет сети 192.168.2.0/24, однако
ограничивает его всем хостам, входящим в состав сети 192.168.1.0/24.
В тех случаях, когда выполняется фильтрация определенного типа трафика,
общие ограничения отсутствуют, но вместо этого могут выполняться
дополнительные операции, которые отразятся на текущих данных. В примере
показан сценарий, в котором входящие данные фильтруются на базе
определенных критериев ( в данном случае это IP-адрес источника) и, когда
обнаруживается, что к данным необходимо применить список контроля доступа,
выполняются соответствующие действия. Общие действия могут включать
изменение параметров в маршрутизируемом IP-трафике для протоколов,
например метрик маршрута в RIP и OSPF, а также инициирование
зашифрованных сетевых соединений для передачи определенного типа трафика,
что часто используется в таких технологиях, как виртуальные частные сети (VPN).
В маршрутизаторах серии ARG3 используются три основных типа ACL, включая
basic (базовый), advanced (расширенный) и layer2 access control list (список
контроля доступа второго уровня). Базовый ACL сопоставляет пакеты по IP-
адресам источников, флагам фрагментов и временных диапазонов, и
поддерживает значения в диапазоне 2000–2999. Расширенный ACL обеспечивает
более высокую точность сравнения параметров и сопоставляет пакеты по IP-
адресам источника и пункта назначения, номерам портов источника и пункта
назначения и типам протоколов.
Расширенный ACL поддерживает значения в диапазоне 3000–3999. Наконец, ACL
второго уровня сопоставляет пакеты по данным второго уровня: MAC-адресам
источников, MAC-адресам пунктов назначения и типам протоколов второго
уровня. Фильтрация трафика выполняется на базе правил, содержащих
параметры, определенные соответствующим типом ACL.
Списки контроля доступа работают по принципу упорядоченных правил. Каждое правило
включает условия разрешения или запрета. Правила могут перекрывать друг друга или
конфликтовать друг с другом. Одно правило может содержать другое правило, но эти два
правила должны быть разными. AR2200 поддерживает два порядка сопоставления
правил: конфигурационный и автоматический. В первом случае сопоставление правил
ACL выполняется в порядке возрастания идентификаторов правил, в то время как
автоматический режим следует принципу «в глубину», который позволяет сначала
сопоставлять более точные правила. Сопоставление правил в конфигурационном
порядке используется по умолчанию и определяет приоритеты правил в ACL по
идентификатору правила. Приоритеты правил, как таковые, позволяют решить любой
конфликт между перекрывающимися правилами. Для каждого идентификатора правила
ACL определяет, применимо ли это правило. Если правило не применяется, то
рассматривается следующее правило. Как только будет найдено соответствие правила,
действие правила будет выполнено, и процесс ACL завершится. Если ни одно из правил
не соответствует пакету, то система не обрабатывает пакет.
В этом примере пакеты, исходящие из двух сетей, проходят проверку списком ACL в
пределах RTA. Пакеты из сетей 172.16.0.0 и 172.17.0.0 будут по умолчанию оцениваться
по значению идентификатора правила (конфигурационный порядок). Если правило
обнаружит совпадение для сети по шаблону маски, то правило будет применено. Для
сети 172.16.0.0 правило 15 будет сопоставлять любые пакеты с адресом 172.16.0.X, где X
может быть любым двоичным значением в октете. Если никакого конкретного правила,
соответствующего сети 172.17.0.0, не будет найдено в списке контроля доступа, то
процесс ACL не будет выполняться, однако чтобы получить оптимальный механизм ACL,
в правиле 20 было определены условия catch all (универсальные условия), которые
разрешают осуществлять передачу всем сетям, для которых не сконфигурировано
специальное правило.
Для создания базового (basic) списка контроля доступа необходимо, чтобы
администратор сначала определил источник трафика, к которому будет
применяться ACL. В данном примере это источник с IP-адресом в диапазоне
192.168.1.0/24. Все пакеты, содержащие IP-адрес источника из этого диапазона,
будут отбрасываться шлюзом. Передача трафика хостами с сетевыми адресами в
диапазоне 192.168.2.0/24 разрешена, и никаких дальнейших действий для этих
пакетов не предпринимается. Базовый ACL применяется к интерфейсу Gigabit
Ethernet 0/0/0 в исходящем направлении, то есть механизм ACL будет
применяться только к пакетам, которые соответствуют критериям интерфейса и
направления.
С помощью команды display acl <acl-number> можно проверить правильность
сконфигурированного базового ACL, где acl-number – это номер, который был
назначен сконфигурированному ACL. В командном выводе можно увидеть, что
правила, которые были созданы для запрета (отбрасывания) любых IP-пакетов с
IP-адресом источника в диапазоне 192.168.1.0/24 и разрешения передачи пакетов
с адресами диапазоне 192.168.2.0/24, выполняются.
Также следует отметить, что при создании списка контроля доступа каждому
правилу автоматически присваивается номер. Номер правила определяет
порядок, в котором выполняется его обработка. По умолчанию в маршрутизаторах
Huawei серии ARG3 шаг увеличения ID правил имеет значение 5. Между
номерами правил устанавливается шаг ACL. Например, если для шага ACL
установлено значение 5, то правила нумеруются 5, 10, 15 и т. д. Если для шага
ACL установлено значение 2, и система автоматически генерирует
идентификаторы правил, первым автоматически сгенерированным
идентификатором правила будет 2. Шаг позволяет добавлять новое правило
между существующими правилами. Там где это необходимо, можно
сконфигурировать номер правила для базового ACL.
Расширенные (advanced) списки контроля доступа позволяют фильтровать по
нескольким параметрам, чтобы обеспечить более детальный процесс выбора
маршрута. В то время как базовый ACL фильтрует по IP-адресу источника,
расширенный ACL способен выполнять фильтрацию по IP-адресу источника и
пункта назначения, номерам портов источника и пункта назначения, протоколам
как сетевого, так и транспортного уровня, а также параметрам на каждом
уровне, таким как классификаторы IP-трафика, значения флагов TCP
(SYN|ACK|FIN и т. д.).
Расширенный ACL принимает значения в диапазоне 3000–3999, как показано в
примере, для которого определены правила ограничения TCP-пакетов,
исходящих со всех адресов источников в диапазоне от 192.168.1.1 до
192.168.1.255, с IP-адресом пункта назначения – 172.16.10.1, и портом
назначения – 21. Аналогичное правило используется для ограничения всех IP-
пакетов с адресами источников в диапазоне 192.168.2.0/24 и единым адресом
пункта назначения 172.16.10.2. Универсальное правило catch all можно
применить таким образом, чтобы все IP-пакеты остального трафика либо
пропускались механизмом ACL, либо отбрасывались.
Проверка сконфигурированного расширенного ACL выполняется с помощью
команды display acl <acl-number>, где acl-номер – это номер, который был
назначен сконфигурированному ACL. Полученный в командном выводе результат
подтверждает, что были созданы три правила для запрета любых TCP-пакетов с
IP-адресом источника в диапазоне 192.168.1.0/24, предназначенные для пункта
назначения 172.16.10.1, от порта 21 (ftp) и от любого IP-адреса источника в
диапазоне 192.168.2.0/24, предназначенные для IP-адреса пункта назначения
172.16.10.2. При этом передача всего остального IP-трафик разрешена.
ACL-механизм, применяемый в трансляции сетевых адресов (NAT), фильтрует
хосты на базе IP-адресов, принимая таким образом решение, трансляция каких
внутренних сетей будет выполняться, и через какие конкретные пулы внешних
адресов, если имеются несколько пулов. Это может произойти, когда в
корпоративной сети существуют соединения от нескольких поставщиков услуг, для
которых различные внутренние пользователи, входящие в состав различных
сетей/подсетей, хотят осуществлять трансляцию и передачу данных на базе
определенной группы адресов через uplink-интерфейсы альтернативного
маршрутизатора к сетям различных поставщиков услуг.
В данном случае приведен упрощенный пример, в котором выполняется
фильтрация хостов во внутренней сети по базовом правилам ACL, для которых
применяется решение динамического NAT. Данное решение позволяет выполнять
трансляцию данного публичного адреса определенной адресной группы. В
частности, трансляция хостов из сети 192.168.1.0/24, будет выполняться с
использованием публичных адресов в пуле, который связан с адресной группой 1,
тогда как фильтрация хостов в сети 192.168.2.0/24 будет выполняться на базе
пула, связанного с адресной группой 2. Для привязки NAT и ACL в исходящем
направлении в режиме интерфейса Gigabit Ethernet выполняется команда nat
outbound <acl-number> address-group <address-group number>, а соответствующий
диапазон IP-адресов определяется указанной адресной группой.
1. Расширенный ACL способен выполнять фильтрацию трафика на базе IP-
адресов источника и пункта назначения, номеров портов источника и пункта
назначения, протоколов как сетевого, так и транспортного уровня, а также
атрибутов каждого уровня, таких как классификаторы IP-трафика и значения
флагов TCP (SYN|ACK|FIN и т. д.).
2. Как только в списке контроля доступа для проверяемого условия будет
найдено соответствие правила, действие правила будет выполнено, а процесс
ACL будет завершен.
Аутентификация, авторизация и учет (Authentication, Authorization,
Accounting, AAA) – это технология безопасности, которая при
совершении пользователем какого-либо действия в сети отслеживает,
кто инициирует это действие (authentication), и имеет ли пользователь
право на выполнение этого действия (authorization), а также записывает
в журнал все действия пользователей сетевых ресурсов (аccounting).
VRP поддерживает локальные службы аутентификации и авторизации
AAA на маршрутизаторах серии ARG3, которые называются серверами
сетевого доступа (Network Access Server, NAS), однако службы учета, как
правило, реализуются через внешний сервер учета AAA. В приведенном
здесь примере показано как пользователи, которые считаются частью
домена Huawei, могут получить доступ к ресурсам сети назначения.
Сервер сетевого доступа (NAS) работает как шлюзовое устройство,
которое может выполнять аутентификацию и авторизацию
пользователей или поддерживать аутентификацию и авторизацию
пользователей на сервере AAA. Те пользователи, которые прошли
аутентификацию и авторизацию для доступа к сети назначения на
сервере AAA, могут также инициировать учет на сервере AAA во время
активного сеанса.
AAA поддерживает три режима аутентификации: без аутентификации, локальная аутентификация
и удаленная аутентификация. В режиме без аутентификации пользователям предоставляется
доступ без выполнения проверки их подлинности. Данный режим используется редко по
очевидным причинам возникновения рисков безопасности. В режиме локальной аутентификации
на сервере сетевого доступа (NAS) выполняется конфигурирование пользовательской
информации, включая имена, пароли и параметры локальных пользователей. Преимуществами
локальной аутентификации является быстрая обработка и низкие эксплуатационные расходы.
Недостатком локальной аутентификации является ограниченный объем хранения данных из-за
ограниченности аппаратных средств. В режиме удаленной аутентификации на сервере
аутентификации выполняется конфигурирование пользовательской информации, включая имена,
пароли и параметры пользователей. AAA может выполнять удаленную аутентификацию
пользователей с помощью протокола RADIUS или HWTACACS компании Huawei. В качестве
клиента NAS взаимодействует с сервером RADIUS или HWTACACS.
Если в схеме аутентификации используется несколько режимов аутентификации, то эти режимы
вступают в силу в той последовательности, в которой они были сконфигурированы. Если
удаленная аутентификация была сконфигурирована раньше локальной аутентификации, а
учетная запись пользователя для входа, созданная на локальном устройстве, недоступна на
удаленном сервере, то AR2200 считает, что пользователь этой учетной записи не прошел
удаленную аутентификацию, и поэтому локальная аутентификация не выполняется. Локальная
аутентификация будет выполняться только, если сервер удаленной аутентификации не отвечает.
При использовании режима без аутентификации его необходимо конфигурировать в последнюю
очередь.
Функция авторизации AAA, поддерживающая различные режимы, используется
для определения разрешений пользователей на получение доступа к
определенным сетям или устройствам. В режиме без авторизации проверка прав
пользователей на доступ не выполняется. В режиме локальной авторизации
предоставление пользователям определенных прав выполняется на основании
соответствующих атрибутов учетных записей, сконфигурированных в NAS. В
качестве альтернативы для авторизации пользователей на сервере TACACS
может использоваться протокол HWTACACS.
В режиме авторизации на основании аутентификации пользователи считаются
авторизованными, если они проходят проверку подлинности в режиме локальной
или удаленной аутентификации. Авторизация RADIUS используется для
предоставления пользователю определенных прав после их аутентификации на
сервере RADIUS. Алгоритмы аутентификации и авторизации протокола RADIUS
связаны друг с другом, поэтому RADIUS не может использоваться только для
выполнения авторизации. Если в схеме авторизации используется несколько
режимов, то авторизация выполняется в той последовательности, в которой они
были сконфигурированы. Так как вступление режимов в силу происходит в
порядке их конфигурирования, то рекомендуется конфигурирование режима без
авторизации выполнять в последнюю очередь.
Процесс учета используется для мониторинга активности и используемых
ресурсов авторизованными пользователями, которые получили доступ к сетевым
ресурсам. Учет AAA поддерживает два режима. В режиме без учета
пользователям предоставляются бесплатные услуги без каких-либо записей в
журнал активности.
В режиме удаленного учета активность пользователей регистрируется на сервере
RADIUS или HWTACACS. Эти серверы используются для поддержки процесса
учета, так как для хранения информации журналов доступа и активности каждого
авторизованного пользователя необходима дополнительная память. В данном
примере показана стандартная информация, которая записывается в журналы
учета пользователей.
Домены используются для управления пользователями. К домену могут применяться
схемы аутентификации, авторизации и учета, чтобы устройство могло выполнять
аутентификацию, авторизацию или выставлять пользователям домена счета за
обслуживание. Каждый пользователь устройства принадлежит к определенному домену.
Домен, к которому принадлежит пользователь, определяется символьной строкой,
добавленной к имени домена после разделителя. В качестве разделителя могут
использоваться символы: @, | или %.
Например, пользователь использует имя user@huawei, значит он принадлежит к домену
huawei. Если после имени пользователя нет символа @, значит он принадлежит к домену
по умолчанию, который в системе называется default. Устройство поддерживает два
домена по умолчанию: default (глобальный домен по умолчанию для пользователей
общего доступа) и default_admin (глобальный домен по умолчанию для
администраторов). Настройки этих двух доменов можно изменить, но удалить эти
домены нельзя.
Если не удалось прикрепить пользователя доступа к определенному домену, то
используется домен по умолчанию. Домен default используется для пользователей
доступа, таких как пользователи доступа NAC. Для пользователей в данном домене по
умолчанию выполняется локальная аутентификация. Домен default_admin используется
для администраторов, которые выполняют вход в систему по протоколам HTTP, SSH,
Telnet, FTP и с терминалов. Для пользователей в данном домене по умолчанию
выполняется локальная аутентификация. Устройство поддерживает максимум 32
домена, включая два домена по умолчанию.
Для реализации схем аутентификации и авторизации в качестве сервера сетевого
доступа (NAS) можно использовать маршрутизатор AR2200. В данном примере показан
типичный процесс, необходимый для успешной реализации локальной системы AAA.
Создание пользователей для аутентификации выполняется с помощью команды local-
user <user-name> password [cipher \simple]<password> privilege level <level >. Данная
команда определяет имя пользователя. Если имя пользователя содержит разделитель
имени домена, например @, то символы перед @ – это имя пользователя, а символы
после @ – это имя домена. Если в имени пользователя нет символа @, то вся
символьная строка считается именем пользователя, а именем домена считается домен
по умолчанию default.
Для аутентификации пользователей создается схема аутентификации. Ее необходимо
создать перед конфигурированием дополнительной аутентификации. Используются
следующие схемы аутентификации: локальная аутентификация, аутентификация Radius,
аутентификация HWTACACS или без аутентификации. За исключением схемы без
аутентификации, другие схемы аутентификации должны быть перечислены в порядке, в
котором должна выполняться аутентификация. Например, при появлении ошибки
аутентификации HWTACACS после использования команды authentication-mode hwtacacs
local маршрутизатор AR2200E запустит локальную аутентификацию. Для авторизации
пользователей также необходимо создать схему авторизации (за исключением тех
случаев, когда используется сервер Radius), в которой будет определен режим
авторизации. Команда authorization-mode поддерживает следующие режимы
авторизации: авторизация HWTACACS, локальная авторизация, авторизация после
успешного прохождения аутентификации и режим без авторизации.
Для создания нового домена используется команда domain <domain-name>. Для
внедрения схем аутентификации и авторизации для данного домена используются
команды authentication-scheme <authentication-scheme> и authorization-scheme
<authorization-scheme> в режиме домена.
Проверка конфигурации локального домена AAA и схем аутентификации и авторизации
выполняется с помощью команд команд display domain или display domain name <domain-
name>. Для предоставления краткой информации обо всех созданных доменах, включая
имя домена и индекс домена, который используется для обращения к каждому
созданному домену, используется команда display domain.
Для получения сведений о конкретном домене используется команда display domain
name <domain-name>, в которой параметр domain-name указывает имя домена. Наряду с
параметром domain-name указывается статус домена (domain-state), который может
принимать значения Active или Block. Значение Block – это заблокированный домен,
пользователи которого не могут входить в систему. Это реализуется с помощью
дополнительной команды state [active | block] в режиме домена AAA. После создания по
умолчанию домен находится в активном состоянии.
Параметр authentication-scheme-name связывает созданную схему аутентификации
(параметр authentication-scheme) с доменом. То же самое относится и к схеме
авторизации (authorization-scheme). Схема учета не сконфигурирована локально, поэтому
она не привязана к созданному домену. Для домена указана схема учета по умолчанию.
Если для поддержки сервисов AAA используется конфигурация RADIUS или HWTACACS,
а не локальная конфигурация, то привязка данных сервисов к домену будет
определяться параметром server-template.
1. Конфигурация VRP в локальном режиме будет поддерживать как схему
аутентификации, так и схему авторизации. Для схемы учета необходима поддержка
удаленного управления через сервер HWTACACS или RADIUS.
2. Если для пользователя не был указан домен, то он будет автоматически привязан к
домену по умолчанию default.
IPSec (Internet Protocol Security, IPSec) – это набор протоколов, разработанных рабочей группой
IETF, для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, путем
аутентификации и/или шифрования каждого IP-пакета сеанса связи. Две взаимодействующие
стороны могут выполнять шифрование данных и/или выполнять аутентификацию данных с IP-
уровня, чтобы обеспечить конфиденциальность данных, целостность и доступность сервисов.
Конфиденциальность данных – это услуги, которые обеспечивают защиту данных на прикладном
уровне от их неполномочного раскрытия. Конфиденциальность потока трафика – это услуга,
которая используется для сокрытия адресов источника и пункта назначения, длины сообщения
или частоты связи.
Целостность данных – это услуги, которые предотвращают активные угрозы. IPSec поддерживает
две формы обеспечения целостности данных: без установления соединения и частичная
целостность последовательности. Целостность без установления соединения – это сервис,
который позволяет обнаружить изменение отдельной IP-датаграммы, без учета порядка
датаграммы в потоке трафика. Частичная целостность последовательности, предлагаемая в
IPSec, - это anti-reply сервис, с помощью которого определяется получение дубликатов
IP-датаграмм (в пределах ограниченного окна). В отличие от этих форм, целостность в режиме с
установлением соединения предъявляет более строгие требования к последовательности
трафика, например, для обнаружения потерянных или пересортированных сообщений. Хотя
сервисы аутентификации и проверки целостности часто упоминаются отдельно, на практике они
тесно взаимосвязаны и работают последовательно друг за другом.
Доступность, как сервис безопасности, позволяет решить проблемы безопасности, связанные с
атаками на сеть, которые приводят к отказу или ухудшению качества обслуживания. Например, в
контексте IPSec использование механизмов anti-replay в базовых протоколах, в частности AH и
ESP, обеспечивает защиту от атак, инициируемых злонамеренными пользователями, путем
повторной отправки перехваченных пакетов.
IPSec использует два протокола для обеспечения безопасности трафика: заголовок аутентификации (AH) и
безопасная инкапсуляция полезной нагрузки (ESP). Заголовок IP-аутентификации (AH) обеспечивает
целостность без установления соединения, аутентификацию источника данных и дополнительный сервис
защиты от повторного воспроизведения. Протокол ESP позволяет обеспечить конфиденциальность данных
(шифрование) и конфиденциальность ограниченного потока трафика.
ESP дополнительно обеспечивает конфиденциальность трафика. Уровень конфиденциальности частично
зависит от используемого алгоритма шифрования, который может принимать три основные формы. ESP
также может дополнительно предоставлять аутентификацию, однако аутентификация, предлагаемая ESP,
является более узкой, чем AH, поскольку внешний IP-заголовок (туннельный режим) и ESP-заголовок
защищены/не защищены при аутентификации ESP.
Стандарт шифрования данных с блочной передачей зашифрованного текста (DES-CBC) является
алгоритмом симметричного шифрования на секретном ключе, который использует размер ключа 64 бита, но
он обычно известен как 56-битный ключ, поскольку ключ имеет 56 значащих битов; младший бит в каждом
байте – это бит четности. Его использование сегодня ограничено из-за появления атак методом перебора в
течение значительно ограниченного периода времени. Стандарт тройного шифрования данных (3DES) - это
168-битный алгоритм шифрования, который включает в себя итерацию процесса DES с добавлением вектора
инициализации (IV) – значения, используемого для маскировки шаблонов в зашифрованных данных, в целях
улучшения общей конфиденциальности данных. Расширенный стандарт шифрования (AES) поддерживает
шифрование до 256 бит, и снова использует CBC и IV для усиления шифрования. По мере усложнения
шифрования увеличивается и время обработки, необходимое для шифрования и дешифрования.
AH поддерживает алгоритм MD5, который принимает на входе сообщение произвольной длины и выдает на
выходе 128-битный «отпечаток» или «профиль сообщения», в то время как SHA-1 на выходе выдает 160-
битный профиль сообщения. SHA-2 – это следующее поколение алгоритмов аутентификации для
расширения механизма безопасной аутентификации, разработанных после обнаружения определенных
слабых мест в SHA-1.
Термин SHA-2 официально не определен, но обычно используется для обозначения совокупности
алгоритмов SHA-224, SHA-256, SHA-384 и SHA-512. VRP, в настоящее время поддерживаемый AR2200E,
обеспечивает поддержку только SHA-256, SHA-384 и SHA-512, где в качестве значения используется битовая
длина профиля.
Security Association (SA) – это соединение, устанавливаемое в одном направлении, предоставляет
службы обеспечения безопасности трафика, который передаётся через него. Каждое соединение
SA реализует один режим и протокол; таким образом, если для одного пакета необходимо
использовать два протокола (как например, AH и ESP), то требуется два SA. Чтобы обеспечить
безопасную двунаправленную связь между двумя хостами или двумя шлюзами безопасности, как
показано в примере, требуются два соединения SA (по одному в каждом направлении).
IPSec SA устанавливаются либо в ручном режиме, либо в режиме согласования IKE (протокол
обмена ключами). При создании SA в ручном режиме необходимо, чтобы вся информация,
например, параметры были настроены вручную. Однако SA, установленные в ручном режиме,
никогда не устаревают. Установка SA с использованием режима согласования IKE проще,
поскольку данные о согласовании IKE должны быть сконфигурированы только на двух узлах, а SA
создаются и поддерживаются посредством согласования IKE. Сложность, главным образом,
заключается в самом процессе автоматического согласования IKE (подробно не рассматривается
здесь). SA, установленные в режиме согласования IKE, имеют время жизни по времени или на
базе трафика. При достижении указанного времени или объема трафика SA становится
недействительным. Когда срок действия SA истекает, IKE согласовывает новый SA.
Транспортный режим – это соединение SA между двумя хостами. В IPv4 заголовок протокола
безопасности транспортного режима вставляется сразу после IP-заголовка и перед
заголовками протоколов верхнего уровня (например, TCP или UDP). В транспортном
режиме протоколы обеспечивают защиту, главным образом, для протоколов верхнего уровня.
Заголовок AH или ESP вставляется между IP-заголовком и заголовком протокола транспортного
уровня. В случае ESP транспортный режим SA предоставляет услуги безопасности только для
этих протоколов более высокого уровня, а не для IP-заголовка или каких-либо расширенных
заголовков, предшествующих заголовку ESP. В случае AH защита также распространяется на
выбранные поля IP-заголовка, а также на выбранные параметры.
В контексте IPSec использование ESP в туннельном режиме, особенно на шлюзе безопасности,
может гарантировать некоторый уровень конфиденциальности потока трафика. Адрес источника и
адрес пункта назначения во внешнем IP-заголовке определяют конечные точки туннеля. Адреса
источника и пункта назначения во внутреннем IP-заголовке идентифицируют исходного
отправителя и получателя датаграммы (с точки зрения данного туннеля) соответственно.
Внутренний IP-заголовок не изменяется, кроме как для уменьшения TTL, и остается неизменным
во время его доставки к точке выхода из туннеля. Во время доставки инкапсулированной
датаграммы через туннель не происходит никаких изменений в IP-параметрах или заголовках
расширений. Перед исходным IP-заголовком вставляется заголовок AH или ESP, а новый IP-
заголовок вставляется перед заголовком AH или ESP.
В приведенном примере показан туннельный режим IPSec во время передачи пакетов по
протоколу TCP. Если AH также применяется и к пакету, то он применяется к заголовку ESP,
полезной нагрузке пакета, хвосту ESP и данным аутентификации ESP (ICV), если такие поля
присутствуют.
Для реализации виртуальной частной сети (VPN) IPSec необходимо проверить достижимость на сетевом
уровне между инициатором и получателем, чтобы проверить наличие связи без использования IPSec перед
созданием туннеля IPSec VPN. Правила целостности или конфиденциальности применяются не ко всему
трафику и, поэтому, чтобы определить интересующий трафик, за который будет отвечать IPSec, необходимо
применить фильтрацию трафика к потоку данных. Поток данных представляет собой совокупность трафика,
который может быть идентифицирован по адресу/маске источника, адресу/маске пункта назначения, номеру
протокола, номеру порта источника и номеру порта пункта назначения. При использовании VRP потоки
данных определяются с помощью групп ACL. Потоком данных может быть одно TCP-соединение между
двумя хостами или весь трафик между двумя подсетями. Первый шаг конфигурирования IPSec заключается
в определении этих потоков данных.
Предложение IPSec определяет протокол безопасности, алгоритм аутентификации, алгоритм шифрования и
режим инкапсуляции для защищаемых потоков данных. Протоколы безопасности AH и ESP могут
использоваться независимо или вместе. AH поддерживает алгоритмы аутентификации MD5, SHA-1 и SHA-2.
ESP поддерживает три алгоритма аутентификации (MD5, SHA-1 и SHA-2) и три алгоритма шифрования (DES,
3DES и AES). IPSec также поддерживает транспортный и туннельный режим инкапсуляции. Для передачи
одного и того же потока данных одноранговые узлы с обеих сторон туннеля безопасности должны
использовать один протокол безопасности, алгоритм аутентификации, алгоритм шифрования и режим
инкапсуляции. Для реализации IPSec между двумя шлюзами рекомендуется использовать туннельный
режим для защиты фактически используемых IP-адресов источника и пункта назначения.
Политика IPSec определяет протокол безопасности, алгоритм аутентификации, алгоритм шифрования и
режим инкапсуляции для потоков данных путем обращения к предложению IPSec. Для однозначного
определения политики IPSec используется имя и порядковый номер. Политики IPSec подразделяются на
политики IPSec, используемые для установки SA вручную, и политики IPSec, используемые для установки SA
путем выполнения согласования IKE.
Для конфигурирования политики IPSec, которая используется для установления SA вручную, необходимо
указать ключ и SPI. Если сконфигурирован туннельный режим, также необходимо установить IP-адреса для
двух конечных точек туннеля безопасности. Для конфигурирования политики IPSec, которая используется
для установления SA путем согласования IKE, такие параметры, как ключ и SPI, устанавливать не нужно, так
как они генерируются автоматически при согласовании IKE. Политики IPSec с одним именем, но с разными
порядковыми номерами составляют группу политик IPSec.
В группе политик IPSec политика IPSec с меньшим порядковым номером имеет более высокий
приоритет. После применения группы политик IPSec к интерфейсу все политики IPSec в группе
будут применены к данному интерфейсу. Это позволяет использовать разные SA для различных
потоков данных.
Связь на сетевом уровне – это начальная предпосылка установления любого VPN-соединения
IPsec. В данном примере это поддерживается созданием статического маршрута, указывающего
на адрес следующего перехода RTB. Для обеспечения двунаправленной связи между сетями
необходимо обеспечить статические маршруты в обоих направлениях. Расширенный ACL
создается для идентификации интересующего трафика, для которого будет инициироваться IPsec
VPN. Расширенный ACL будет выполнять фильтрацию трафика на базе определенных
параметров и выберет либо отбросить, передать или защитить отфильтрованные данные.
Команда ipsec proposal создает предложение IPSec и осуществляет переход в режим предложения
IPSec. При конфигурировании политики IPSec для указания протокола безопасности, алгоритма
шифрования, алгоритма аутентификации и режима инкапсуляции, используемых с обеих сторон
туннеля IPSec, выполняется обращение к предложению IPSec. Новое предложение IPSec,
созданное с помощью команды ipsec proposal по умолчанию, использует протокол ESP, алгоритм
шифрования DES, алгоритм аутентификации MD5 и режим инкапсуляции туннеля. Их можно
настроить с помощью различных команд в режиме предложения IPSec. Команда transform [ah | ah-
esp | esp] позволяет изменить текущий набор преобразований, команда encapsulation-mode
{transport | tunnel } позволяет изменить средства, используемые для инкапсуляции пакетов.
Команда esp authentication-algorithm [md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ] позволяет
установить алгоритм аутентификации, используемый протоколом ESP, а команда esp encryption-
algorithm [des | 3des | aes-128 | aes-192 | aes-256 ] используется для назначения шифрования ESP.
Команда AH протокола ah authentication-algorithm [md5 | sha1 | sha2-256 | sha2-384 | sha2-512 ]
позволяет установить аутентификацию на базе AH.
Проверка параметров предложения IPSec может быть выполнена с помощью команды display
ipsec proposal [name <proposal-name>]. В результатах можно посмотреть выбранные предложения
или все созданные предложения. Параметр name определяет имя созданного предложения IPSec.
В режиме инкапсуляции указывается текущий режим, который используется для данного
предложения. Это может быть транспортный или туннельный режим. При выполнении
преобразования используются различные алгоритмы. Это может быть AH, ESP или комбинация
преобразования AH и ESP. В зависимости от используемого преобразования будут перечислены
соответствующие алгоритмы.
Для настройки политики IPSec используются параметры policy-name и seq-number. Несколько
политик IPSec с одинаковым именем составляют группу политик IPSec. Группа политик IPSec
содержит максимум 16 политик IPSec, а политика IPSec с наименьшим порядковым номером имеет
наивысший приоритет. После применения группы политик IPSec к интерфейсу для защиты
различных потоков данных все политики IPSec в группе будет применены к данному интерфейсу.
Наряду с параметрами policy-name и seq-number, политика определяет режим создания SA либо
вручную, либо посредством согласования IKE.
При использовании согласования IKE настройка параметров осуществляется с помощью команды
ipsec-policy-template. В данном примере показано конфигурирование параметров вручную.
Созданный ACL связан с политикой, а также с созданным предложением. Команды tunnel local и
tunnel remote используются для определения интерфейсов, между которыми будет устанавливаться
туннель IPSec. Необходимо определить входящий и исходящий SPI (индекс параметра источника).
Входящий SPI на локальной стороне должен совпадать с исходящим SPI на удаленной стороне.
Исходящий SPI на локальной стороне должен совпадать со входящим SPI на удаленной стороне.
Этот номер используется для обращения к каждой SA. Учитывая, что SA применяется только в
одном направлении, требуется указать SPI в обоих направлениях. Наконец, должны быть повторно
определены как входящие, так и исходящие ключи аутентификации. Исходящий ключ
аутентификации на локальной стороне должен совпадать со входящим ключом аутентификации на
удаленной стороне. При использовании согласования IKE происходит автоматическое согласование
SPI и ключей аутентификации.
После создания политики и привязки предложения и ACL к политике сама политика может быть
применена к физическому интерфейсу, на котором трафик будет подвергаться обработке IPSec. В
приведенном примере между интерфейсом Gigabit Ethernet 0/0/1 RTA и Gigabit Ethernet 0/0/1 RTB
должен быть установлен туннель IPSec. В интерфейсном режиме команда ipsec policy
используется для применения созданной политики к интерфейсу.
На одном интерфейсе может использоваться только одна группа политик IPSec. Для применения
новой группы политик IPSec к интерфейсу сначала необходимо удалить предыдущую группу
политик. Группа политик IPSec, которая устанавливает SA через согласование IKE, может
применяться к нескольким интерфейсам, тогда как группа политик IPSec, которая устанавливает
SA в ручном режиме, может применяться только к одному интерфейсу. При отправке пакета с
интерфейса AR2200 сопоставляет пакет с каждой политикой IPSec в группе политик IPSec. Если
пакет соответствует политике IPSec, AR2200 инкапсулирует пакет в соответствии с политикой. В
противном случае пакет будет отправлен без инкапсуляции.
Для просмотра конкретной политики IPSec или всех политик IPSec используется команда display
ipsec policy [brief | name policy-name [ seq-number ] ]. Параметры отображаемой политики IPSec
включают имя политики и порядковый номер политики, которые обычно используются для
различия приоритета политик в группе, где более низкий порядковый номер означает более
высокий приоритет. Вместе с адресами локального и удаленного туннеля политики IPSec
отображается имя предложения и ACL, который используется для фильтрации трафика в
политике.
Команда display ipsec policy также определяет настройки конкретного параметра для SA как во
входящем, так и в исходящем направлениях. SPI использует SA в каждом направлении. Этот
механизм может использоваться как часть процесса устранения неполадок, чтобы гарантировать,
что SPI на исходящем локальном интерфейсе соответствует тому, который установлен для
входящего удаленного интерфейса на одноранговом интерфейсе (соответствует удаленному
адресу туннеля). Для входящего и исходящего SA определяется строка ключа. Также выполняется
оценка локальной и удаленной конфигурации.
1. Security Association (SA) – это соединение, устанавливаемое в одном направлении,
предоставляет службы обеспечения безопасности трафика, который передаётся через него.
Чтобы обеспечить безопасную двунаправленную связь между двумя хостами, требуются два
соединения SA.
2. Весь трафик, предназначенный для пересылки через исходящий интерфейс, на котором
установлен IPSec, сначала будет подвергнут фильтрации с помощью базы данных политики
безопасности (SPD). SPD может указать для пакета данных одно из трёх действий: отбросить
пакет, не обрабатывать пакет с помощью IPSec, обработать пакет с помощью IPSec. В
последнем случае SPD также указывает, какой SA необходимо использовать (если, конечно,
подходящий SA уже был создан) или указывает, с какими параметрами должен быть создан
новый SA.
• Применение технологии IPSec в экономичных решениях организации обмена между частными
сетями позволяет использовать сети общего доступа в качестве среды передачи между
удаленными офисами. Данное решение обеспечивает безопасную передачу полезной нагрузки
IP-пакетов, но не позволяет передавать пакеты протоколов маршрутизации, таких как RIP и
OSPF, между двумя конечными точками туннеля. Первоначально GRE был разработан в
качестве средства поддержки передачи протоколов, таких как IPX, по IP-сетям, однако со
временем основная роль GRE стала заключаться в поддержке маршрутизации на основе
протокола туннелирования.
• GRE можно применять в автономной системе с целью устранения ограничений, обнаруженных
в протоколах IGP. Например, чтобы увеличить число транзитных узлов для RIP-маршрутов,
лимит которых равен 15, все маршруты следуют правилу бесконечности. Применение GRE в
таких средах позволит создать туннель, по которому можно передавать обновления
маршрутной информации, что при необходимости значительно увеличит возможности
маршрутизации по вектору расстояния.
• Один из главных недостатков GRE — это отсутствие механизма обеспечения безопасности
пакетов, передаваемых по сети общего пользования. Трафик, передаваемый в туннеле GRE, не
шифруется, так как такие функции не поддерживают механизм GRE. Комбинация IPSec с GRE
позволит устанавливать туннели GRE в туннелях IPSec, что расширит функции GRE, включая
обеспечение целостности и конфиденциальности передаваемой информации.
• Пакет, полученный от интерфейса, который подключен к частной сети, передается в модуль
протокола частной сети для обработки. Данный модуль проверяет поле получателя в заголовке
пакета частной сети, ищет исходящий интерфейс в таблице маршрутизации или таблице
переадресации частной сети и определяет, как направить этот пакет. Если исходящий
интерфейс является интерфейсом туннеля, модуль протокола частной сети отправляет пакет
на модуль туннеля.
• Получив пакет, модуль туннеля сначала инкапсулирует его в соответствии с типом
транспортного протокола, при этом для текущего туннеля GRE настраиваются параметры
контрольной суммы. То есть, модуль туннеля добавляет к пакету заголовок GRE. Далее
добавляется IP-заголовок в соответствии с конфигурацией. Исходным адресом этого IP-
заголовка является исходный адрес туннеля; адресом назначения IP-заголовка является адрес
назначения туннеля, по которому пакет передается в IP-модуль. IP-модуль ищет
соответствующий исходящий интерфейс в таблице маршрутизации сети общего пользования
на основе адреса назначения в IP-заголовке и пересылает пакет. Затем инкапсулированный
пакет передается по сети общего пользования.
• Получив пакет от интерфейса, подключенного к сети общего пользования, выходной интерфейс
анализирует IP-заголовок, определяет получателя пакета и обнаруживает, что в поле Protocol
Type стоит значение 47, которое указывает, что используется протокол GRE.
• Выходной интерфейс передает пакет на модуль GRE для обработки. Модуль GRE удаляет IP-
заголовок и заголовок GRE и по значению поля Protocol Type в заголовке GRE узнает, что
транспортным протоколом является протокол, работающий в частной сети, после чего модуль
GRE передает пакет этому протоколу. Сам протокол обрабатывает данный пакет так же, как и
любой обычный пакет.
• Аутентификация с помощью ключа выполняется на интерфейсе туннеля. Этот механизм
безопасности предотвращает ситуации неправильной идентификации и получения пакетов
интерфейсом туннеля от других устройств. Если бит K в заголовке GRE установлен в значение
1, то поле «Ключ» вставляется в заголовок GRE. Как приемник, так и отправитель выполняют
проверку подлинности ключа в туннеле.
• Поле «Ключ» содержит 4-байтное значение, которое вставляется в заголовок GRE во время
инкапсуляции пакетов. Поле «Ключ» используется для идентификации трафика в туннеле.
Пакеты одного и того же потока трафика имеют одинаковое содержимое поля «Ключ».
Распознавание пакетов, принадлежащих одному потоку трафика, осуществляется после
декапсуляции пакетов в конце туннеля по содержимому данного поля. Процедура проверки
подлинности считается пройденной только в том случае, если значения поля «Ключ»,
установленные на противоположных концах туннеля, идентичны, иначе пакеты отбрасываются.
• Функция обнаружения keepalive используется для выявления в любое время канала туннеля,
который находится в состоянии keepalive, с целью получения информации о доступности
равноправного узла туннеля. Если равноправный узел недоступен, туннель разъединяется,
чтобы предотвратить возникновение «черных дыр». После включения функции keepalive
локальный конец туннеля GRE периодически отправляет пакет обнаружения состояния
keepalive на равноправный узел. Если такой узел доступен, локальный узел получает от него
ответный пакет. Функция keepalive будет работать до тех пор, пока по крайней мере на одном
конце будет настроена данная функция, при этом нет необходимости включать функцию
keepalive на равноправном узле. Получив пакет обнаружения состояния keepalive,
равноправный узел отправляет ответный пакет на локальный узел независимо от того,
настроена ли на нем функция keepalive.
• После включения функции keepalive источник туннеля GRE создает счетчик, периодически
отправляет пакеты обнаружения состояния keepalive и подсчитывает количество пакетов
обнаружения. После отправки очередного пакета обнаружения количество увеличивается на
единицу.
• Если источник получит ответный пакет до того, как значение счетчика достигнет заданного
значения, источник будет считать, что равноправный узел доступен. Если источник не получит
ответный пакет до того, как счетчик достигнет заданного значения, определяющего число
попыток, то источник признает равноправный узел недоступным и разъединит соединение
туннеля.
• Для установления GRE необходимо сначала создать интерфейс туннеля. После создания
интерфейса укажите тип инкапсуляции — GRE, задайте адрес источника туннеля или
интерфейс источника и задайте адрес назначения туннеля. Также установите сетевой адрес
интерфейса туннеля, чтобы туннель мог поддерживать маршруты. Маршруты для туннеля
должны быть доступны как на устройстве отправителя, так и на устройстве получателя, только
в этом случае пакеты, инкапсулированные с помощью GRE, будут правильно переданы.
Маршрут, проходящий через интерфейсы туннелей, может быть статическим или
динамическим.
• Еще одним ключевым моментом, который необходимо учитывать на этапе конфигурирования,
является MTU. GRE увеличивает объем служебной информации, добавляя дополнительные 24
байта к существующим заголовкам и полезной нагрузке, что может привести к ненужной
фрагментации. Это можно устранить путем корректировки размера MTU с помощью команды
mtu <mtu>, которая компенсирует дополнительные заголовки в пакете. MTU размером 1476
считается достаточным, чтобы уменьшить дополнительную нагрузку на интерфейс.
• После создания интерфейса туннеля GRE можно отслеживать его рабочее состояние и
маршрутную информацию. Состояние туннельного интерфейса считается активным, если
текущее состояние туннеля и состояние протокола канального уровня имеют значение UP.
Любая корректировка существующего MTU служит для того, чтобы не допустить создание
дополнительной служебной информации в результате фрагментации. Интернет-адрес
представляет собой сконфигурированный IP-адрес туннеля на выходном интерфейсе. Источник
и пункт назначения туннеля отображают IP-адреса используемого физического интерфейса,
через который устанавливается туннель GRE.
• Достижимость сетей по туннелю GRE определяется по записи в таблице IP-маршрутизации,
которую можно просмотреть с помощью команды display ip routing table. В этом случае
идентифицируется внутренний адрес источника локальной сети и способность достичь адреса
сети назначения удаленной сети по интерфейсу туннеля на основе GRE. Адрес назначения —
это сетевой адрес, достижимый по туннелю GRE, а адрес следующего узла — это IP-адрес
интерфейса удаленного туннеля GRE.
• Функция keepalive включается на интерфейсе туннеля GRE командой keepalive [period <period>
[retry-times <retry-times> ] ], где параметр period определяет количество секунд до отправки
каждого keepalive-сообщения и по умолчанию устанавливается в значение 5 секунд.
Количество попыток отправки keepalive-сообщения определяется параметром retry-times <retry-
times>, который по умолчанию устанавливается в 3 попытки. Если равноправный узел не
ответит в течение установленного количества предпринятых попыток, соединение между
противоположными узлами туннеля будет считаться неустановленным, и туннель GRE будет
разъединен.
• Для оценки активности туннеля GRE после потери связи между конечными точками туннеля
можно заново применить команду display interface tunnel. В приведенном примере установлено,
что канал GRE туннеля перешел в отключенное состояние, означающее, что произошел сбой
связи. Функция keepalive в настоящий момент включена и отображает период отправки
сообщений keepalive, равный трем секундам. Количество повторных попыток допускает потерю
ответов до трех раз.
1. GRE – это механизм установления динамической маршрутизации между удаленными сетями,
которые обычно относятся к одному административному домену, например как в случае с
филиалами компании. IPSec VPN, как правило, используется для предоставления частного
туннеля site-to-site, по которому может передаваться информация о динамической
маршрутизации, однако туннели IPSec VPN не поддерживают прямую передачу обновлений
маршрутной информации по IPSec, поэтому в этом случае реализуется механизм GRE.
2. Интернет-адрес представляет собой адрес виртуального туннеля, по которому
устанавливается GRE, в то время как источник туннеля представляет собой исходную точку, с
которой устанавливается туннель.
Простой протокол управления сетью (Simple Network Management Protocol; SNMP)
— это протокол управления сетью, широко используемый в сети TCP/IP. SNMP
представляет собой метод управления сетевыми элементами с помощью рабочей
станции, которая управляет программным обеспечением в системе управления
сетью.
SNMP может использоваться в ряде операций связи. SNMP используется
станцией управления сетью (Network Management Station; NMS) для определения
источников сетевой информации и получения информации о сетевых ресурсах.
Также этот протокол используется в ретрансляции отчетов в виде trap-сообщений
в NMS с целью информирования станции о состоянии сети в режиме реального
времени и гарантии быстрого принятия мер сетевым администратором в случае
обнаружения несоответствий и сбоев системы.
SNMP часто используется для управления прикладным программным
обеспечением, учетными записями пользователей, правами на запись и чтение
(лицензиями) и т.д., а также для управления аппаратными средствами,
входящими в состав сети, включая рабочие станции, серверы, сетевые карты,
устройства маршрутизации и коммутаторы. Обычно такие устройства
размещаются далеко от центрального офиса, в котором работает сетевой
администратор, и сообщения о неисправностях устройств должны автоматически
приходить сетевому администратору. SNMP эффективно работает как среда
передачи между сетевыми элементами и сетевым администратором/NMS.
Сетевые элементы, такие как хосты, шлюзы, терминальные серверы и т.д.,
содержат два важных компонента, поддерживающих функции управления сетью,
запрашиваемые станциями управления сетью. Агент управления, размещаемый
на сетевом элементе, извлекает (получает) или изменяет (устанавливает)
переменные.
Станции управления сетью (NMS) ассоциируются с агентами управления, которые
отвечают за выполнение функций управления сетью, запрашиваемых NMS. MIB
хранит ряд переменных, связанных с сетевым элементом, при этом каждая из
этих переменных считается объектом MIB. Обмен сообщениями SNMP внутри IP-
сети требует только поддержки UDP — ненадежной службы датаграмм —
согласно которой каждое сообщение независимо представляется одной
транспортной датаграммой.
Информационная база управления (Management Information Base; MIB)
определяет переменные, поддерживаемые сетевыми элементами. Такие
переменные представляют собой данные, которые можно запросить и настроить в
процессе управления. MIB представляет структуру данных, выполняющую сбор
всех возможных управляемых объектов по сети. В базе SNMP MIB используется
структура дерева, аналогичная структуре системы доменных имен (Domain Name
System; DNS).
Дерево присвоения имен объектам имеет три важных ветви, которые
соответствуют стандартам, контролируемым следующими организациями: ISO,
ITU-T (первоначально CCITT) и совместные национальные и международные
организации. Под контролем ISO находятся четыре объекта, среди которых номер
3 соответствует объекту идентифицированной организации — Identified
organization. Поддерево, соответствующее стандартам, которые создавались под
эгидой Министерства обороны США (Department of Defense, DoD) (6),
расположено под Identified organization (3), и уже под ним расположено поддерево
стандартов Интернета (1). Объект под объектом Интернета называется mgmt (2).
Под объектом mgmt (2) находится MIB-II — новая редакция MIB, определенная в
1991 году. Сам путь дерева может быть определен как значение идентификатора
объекта (OID) {1.3.6.1.2.1}.
SNMP определяет пять типов блоков данных протокола (Protocol Data Unit; PDU),
то есть пакетов SNMP, которые передаются между процессами управления и
агента. get-request указывает на то, что процесс управления считывает одно и
более значений параметров из базы MIB процесса агента. get-next-request
означает, что процесс управления считывает значение следующего параметра в
лексикографическом порядке из базы MIB процесса агента. set-request указывает
на то, что процесс управления устанавливает одно и более значений параметров
из базы MIB процесса агента. get-response возвращает одно и более значений
параметров. Эта операция выполняется процессом агента. Это ответ на три
предыдущих операции. Наконец, функция trap, которая инициируется процессом
агента, информирует процесс управления о важных или критических событиях.
SNMPv1 — это исходный протокол прикладного уровня, с помощью которого
можно проверять или изменять переменные MIB агента. Эволюция SNMP
коснулась не только протокола, но и MIB. В результате добавления новых
объектов была создана MIB-II (или MIB-2). Такие объекты, как, например,
sysContact, Sysname, sysLocation, sysServices служат для предоставления
контактных, административных, локальных и сервисных данных об управляемом
узле в группе системы, а также объектов ipRouteMask, ipRouteMetric5 и
ipRouteInfo, включенных в объект таблицы IP-маршрутов.
Переход на SNMP версии 2 повлек ряд изменений, которые привели к разработке
SNMPv2c. Среди изменений — внедрение нового типа — GetBulkRequest-PDU,
который позволяет получать информацию от нескольких объектов в одном
запросе, и Inform Request, менеджера управления PDU, используемого в тех
случаях, когда один менеджер посылает информацию из MIB-представления
другому менеджеру. Определенные объекты также используют счетчики в
качестве синтаксиса, который в SNMP версии 1 представляет собой 32-разрядное
значение. Это означает, что в данных объектах, например, в объекте подсчета
количества байтов интерфейсов, счетчик легко завершает полный цикл подсчета
и сбрасывается аналогично одометру, который измеряет пробег транспортных
средств.
С помощью 32-битного счетчика октеты на интерфейсе Ethernet, передающем
данные со скоростью 10 Мбит/с, обнулятся через 57 минут. При скорости 100
Мбит/с счетчик сбросится через 5,7 минут, а при скорости 1 Гбит/с полный
цикл счетчика займет всего 34 секунды. Объекты обычно опрашиваются
(проверяются) каждые 1 или 5 минут, и проблемы возникают, когда
счетчики сбрасываются более одного раза между опросами объекта по
причине невозможности получить истинные измерения.
Чтобы решить эту проблему, в SNMP версии 2c определены новые 64-
разрядные счетчики, которые подходят в любых ситуациях, в которых 32-
разрядные счетчики сбрасываются слишком быстро. Таким образом,
скорость подсчета на любом интерфейсе — быстрее 650 миллионов бит
в секунду. Для сравнения, 64-битный счетчик для подсчета октетов на
скорости 1 Тбит/с (1000 Гбит/с) завершит цикл в течение чуть менее 5
лет, а чтобы достичь цикла в 30 минут, потребуется канал 81 000 000
Тбит/с.
Одним из ключевых улучшений SNMPv3 является безопасность передачи
информации объекта MIB. Эта версия способна выявлять различные угрозы, в
том числе изменение информации объекта со стороны неразрешенного объекта
во время транзитной передачи, выполнение неразрешенных управляющих
операций пользователями, которые маскируются под другого пользователя,
имеющего права на управление, перехват сообщений и изменение потока
сообщений с помощью таких методов, как повторная передача ранее переданного
сообщения.
SNMP повышает безопасность путем применения четырех мер защиты.
Обеспечение целостности данных: гарантирует, что данные не будут
несанкционированно изменены или уничтожены, а последовательность данных не
будет изменена злонамеренно.
Аутентификация источника данных: гарантирует, что подлинность пользователя,
от которого поступают данные, будет подтверждена с использованием методов
MD5 и SHA-1. Конфиденциальность данных: гарантирует, что информация не
будет передана или разглашена лицам, организациям или процессам, не
имеющим на нее разрешение. Решения для защиты от повторной передачи
сообщения: гарантирует, что сообщение, время генерации которого выходит за
диапазон указанного временного окна, не будет принято.
Агент SNMP представляет собой процесс агента на устройстве сети. Агент SNMP,
обслуживающий управляемые сетевые устройства, реагирует на запросы NMS и
отправляет данные управления в NMS. Для конфигурирования SNMP на
устройстве необходимо включить агент SNMP командой snmp-agent.
Команда snmp-agent sys-info настраивает системную информацию SNMP и
используется для указания поддерживаемой версии(й) SNMP посредством snmp-
agent sys-info version [ [ v1 | v2c | v3 ] * | all ]. Следует отметить, что все версии
SNMP поддерживаются по умолчанию. Команда snmp-agent trap enable активирует
функцию отправки trap-сообщений в NMS, после чего устройство будет оповещать
NMS о любых сконфигурированных событиях.
Кроме того, необходимо указать интерфейс, через который будут отправляться
уведомления о прерывании. Этот интерфейс должен указывать на
местоположение NMS, например, интерфейс к NMS — Gigabit Ethernet 0/0/1.
Команда display snmp-agent sys-info отображает контактную информацию
персонала, ответственного за техническое обслуживание системы, физическое
местоположение устройства и поддерживаемую в настоящее время версию(и)
SNMP. Приведенная информация в данном примере представляет собой
типичную информацию о системе по умолчанию, включаемую в маршрутизаторы
серии Huawei AR2200, однако она может быть изменена с помощью параметров
snmp-agent sys-info [contact | location | version ], которые отражают данные о
контактах и местоположении, относящиеся к каждому отдельному устройству.
В маршрутизаторе серии Huawei AR2200 все версии SNMP (SNMPv1, SNMPv2c и
SNMPv3) включены по умолчанию.
trap-сообщения передаются в Network Management Station (NMS) агентом с
использованием UDP-порта назначения №162.
Являясь набором спецификаций, определенных Internet Engineering Task Force
(IETF), Internet Protocol версии 6 (IPv6) является стандартом протокола сетевого
уровня следующего поколения и преемником Internet Protocol версии 4 (IPv4).
Наиболее очевидное различие между IPv6 и IPv4 заключается в удлинении IP-
адресов с 32 до 128 битов, благодаря чему IPv6 поддерживает больше уровней
иерархии системы адресации, гораздо большее количество адресных узлов и
упрощенную автоматическую конфигурацию адресов.
Существующий диапазон адресов IPv4 был реализован в то время, когда такие
сети, как ARPANET и National Science Foundation Network (NSFNET),
предоставляли основную магистральную сеть, и IPv4 считался более чем
достаточным для поддержки хостов, подключаемым к таким формирующим сетям.
Непредвиденный темп развития Интернета привел к быстрому расходованию
адресного пространства IPv4, состоящего из 4,3 млрд адресов (многие из которых
зарезервированы), для чего были приняты контрмеры в виде NAT и CIDR, которые
оптимизировали использование адресов и дали время, чтобы подготовить более
постоянное решение. Кроме того, ранние методы распределения сетевых адресов
IPv4 не позволяли добиться смежности, что затрудняло объединение адресов в
кластеры и эффективные группы и не давало возможности снизить нагрузку
глобальных таблиц IP-маршрутизации, используемых в протоколах
маршрутизации на основе автономной системы, таких как BGP.
Ожидается, что постепенно IPv6 вытеснит IPv4-адресацию, обеспечив емкость
более 340 ундециллионов уникальных адресов, что считается более чем
необходимым для продолжения развития IP-сети. Наряду с этим,
распределение адресов Администрацией адресного пространства
Интернет (IANA) гарантирует, что методы IPv6 позволяют добиться
смежности, что будет эффективно управления таблицами IP-
маршрутизации в будущем.
Заголовок IPv6 пришлось расширить, чтобы уместить увеличенный в размере IP-
адрес, а поля, которые во многих случаях пересылки пакетов считались
избыточными, были удалены, чтобы упростить общий формат заголовка IPv6 и
оптимизировать объем служебной информации, передаваемой во время
передачи каждого пакета по сети. По сравнению с заголовком пакета IPv4
заголовок IPv6 больше не содержит полей длины заголовка Интернета (IHL),
идентификатора, флагов, смещения фрагмента, контрольной суммы заголовка,
опций или полей для заполнения блока данных незначащей информацией, а
вместо этого содержит поле метки потока.
Термин «поток» можно понимать как непрерывный поток одноадресных (unicast),
многоадресных (multicast) или произвольных (anycast) пакетов, относящихся к
конкретному приложению или процессу, которые исходят из определенного
источника и передаются в заданный пункт назначения или несколько пунктов
назначения. Сеть с коммутацией пакетов работает таким образом, что такие
потоки трафика могут передаваться по нескольким путям и поступать в
планируемый пункт назначения не по порядку. Затем системные ресурсы должны
повторно упорядочить поток пакетов, прежде чем он сможет быть обработан
верхними уровнями.
Метка потока предназначена для идентификации таких потоков трафика вместе с
полями адреса источника и назначения, чтобы обеспечить общий маршрут по
сетям всем пакетам, связанным с данным потоком трафика. При этом пакеты
сохраняют порядок следования по IP-сети, что оптимизирует
эффективность процесса.
С объединением передачи разных услуг по IP-сетям поле метки потока
становится еще более важным, например, для передачи голоса, которая
основана на технологии коммутации каналов и требует
производительности, близкой к реальному времени.
Также новый протокол поддерживает различные опции без изменения
существующего формата пакета путем включения полей заголовка
расширения. Идентификатор заголовка расширения содержится в поле
Next Header, которое заменяет поле Рrotocol в IPv4, обеспечивая
дополнительную гибкость в IPv6.
Заголовок расширения, являющийся одним из основных изменений в IPv6,
оптимизирует структуру заголовка IPv6. Существует несколько заголовков
расширений, шестнадцатеричные значения которых указываются в поле Next
Header, так же, как идентификаторы заголовков ICMP, TCP, UDP указываются в
поле protocol заголовка IPv4. Каждый заголовок расширения также содержит поле
Next Header для ссылки на следующий заголовок после обработки заголовка
расширения. К одному пакету могут относиться несколько заголовков расширений
в порядке их следования. Список заголовков расширений и последовательность
их обработки:
IPv6
Hop-by-Hop Options (Дополнительные функции: ретрансляция)
Destination Options (Дополнительные функции: узел-получатель)
Routing (Маршрутизация)
Fragment (Фрагментация)
Authentication (Аутентификация)
Encapsulating Security Payload (Повторное обрамление поля полезной
нагрузки с целью её защиты)
Destination Options (Дополнительные функции: узел-получатель)
Upper-layer (Верхний слой заголовка) (как в туннелировании IPv6)
Каждый заголовок расширения должен встречаться не более
одного раза, за исключением заголовка Destination Options,
который должен встречаться не более двух раз (один раз перед
заголовком Routing и один раз перед заголовком Upper-layer).
Другим ключевым аспектом заголовков расширений является
введение протоколов IPSec в форме AH и ESP для повышения
общей безопасности IPv6.
Адрес IPv6 является 128-битным идентификатором, который связан с
интерфейсом или набором интерфейсов (в случае присвоения адреса anycast,
описанного ниже). В связи с размером, адрес представляется в
шестнадцатеричном формате и записывается в виде
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, где xxxx относится к четырем
шестнадцатеричным цифрам, которые переводятся в 16-битный двоичный код.
128-битный адрес IPv6 состоит из набора шестнадцатеричных значений,
сгруппированных 8*16 бит.
Сам адрес состоит из префикса IPv6, который используется для определения сети
IPv6, за которым следует идентификатор интерфейса. Базовая схема адресации
представляет собой двухуровневую архитектуру префикса и идентификатора
интерфейса, однако типы адресов IPv6 могут содержать много подуровней,
которые позволяют формировать обширную архитектуру иерархической
адресации в сети IPv6, обеспечивая эффективную группировку и управление
пользователями и доменами.
Общее письменное обозначение такого длинного 128-битного адреса IPv6 может
быть непрактичным во многих случаях. Еще одно непрактичное свойство адреса
— наличие длинных строк нулевых битов, главным образом из-за непостижимой
масштабности адресной шкалы. Все это стало причиной появления методов
упрощения и повышения практичности написания адресов IPv6, содержащих
нулевые биты. Одним из таких методов является удаление любых нулей в
старших разрядах, которые встречаются в каждом наборе 16-битных
шестнадцатеричных значений.
Для дальнейшего сжатия нулей доступен также специальный синтаксис, который
представлен в виде двойного двоеточия "::". Это значение указывает одну или
несколько 16-битных групп нулей. Однако, чтобы можно было определить размер
строки, "::" может появляться только один раз в адресе. Двойное двоеточие "::"
может использоваться для сжатия нулей в старших разрядах адреса, как показано
в данном примере.
Адресное пространство IPv6 должно быть полностью определено, во-первых, по
причине его размера, из-за чего оно вряд ли будет использовано в ближайшем
будущем, во-вторых, разработка схем адресации все еще находится в начальной
стадии, при этом много разногласий наблюдаются в отношении типов адресов,
которые должны применяться.
В настоящее время часть адресов используется в диапазоне 2000::/3, который
представляет глобальный диапазон адресов одноадресной рассылки, то есть
любой адрес, на который можно направить трафик в публичной IP-сети.
Руководящий орган IANA (в настоящее время входит в состав ICANN) отвечает за
распределение блоков этого диапазона адресов между различными
региональными интернет-регистраторами (RIR), которые распределяют адреса в
одном из пяти регионов мира. Были выделены также диапазоны адресов 2400::/12
(APNIC), 2600::/12 (ARIN), 2800::/12 (LACNIC), 2A00::/12 (RIPE NCC) и 2C00::/12
(AfriNIC), что позволяет указывать регион и осуществлять управление, используя
один префикс адреса. Также в пределах диапазона префиксов 2000::/3 находятся
зарезервированные поля адреса, включая 2001:0DB8::/32, которые используются
для примеров в документации.
Многоадресная передача определяется в IPv6 диапазоном FF00::/8, при этом
большая часть области адресации резервируется для конкретных адресных
диапазонов (таких как link local) и в поддержку протоколов маршрутизации, так же,
как используются адреса многоадресной передачи в IPv4. Одно из основных
изменений в IPv6 заключается в том, что в нем нет широковещательных
адресов, их функция заменяется адресами многоадресной рассылки, что
уменьшает объем нежелательной обработки конечными станциями на
MAC-уровне в сетях IPv6, так как хосты могут фильтровать группы MAC-
адресов многоадресной рассылки.
В IPv6 также существуют некоторые специальные адреса, включая
неуказанный адрес ::/128 для интерфейса, для которого в настоящее
время IP-адрес не назначен. Однако это не следует путать с IP-адресом
::/0, который используется как адрес по умолчанию для любой сети так
же, как адрес по умолчанию 0.0.0.0/0 используется в IPv4. Для loopback-
интерфейса (127.0.0.1) в IPv6 определен зарезервированный адрес
::1/128.
В одноадресной передаче используются в основном префиксы глобальных
адресов одноадресной передачи (global link local) и префиксы локальных адресов
канала одноадресной передачи (unicast link local), однако существуют и другие
формы. Все глобальные адреса одноадресной передачи имеют 64-битное поле ID
интерфейса, за исключением адресов, для которых первые три бита в адресе 000.
Для таких адресов нет ограничений по размеру или структуре поля
идентификатора интерфейса. Формат глобальных адресов одноадресной
передачи иерархичен: префикс глобальной маршрутизации и идентификатор
подсети, за которым следует идентификатор интерфейса. Структура префикса
глобальной маршрутизации позволяет региональным интернет-регистраторам
(RIR) и поставщиками интернет-услуг (ISP), между которыми регистраторы
распределяют эти префиксы, иерархически систематизировать его.
Администратор сайта должен иерархически структурировать поле подсети, чтобы
обеспечить до 65 535 отдельных подсетей.
Локальный адрес канала одноадресной передачи FE80::/10: первые 10 битов
четко определены как 1111111010. Диапазон адресов 64-битного интерфейса
более чем достаточен для выделения адресов хостам, и поэтому оставшиеся 54
бита в локальном адресе канала поддерживаются равными 0. В этом примере
показаны форматы адресов, которые обычно могут быть связаны с каждым из
общих типов адресов одноадресной рассылки.
Следует также отметить, что третья схема адресации при одноадресной
рассылке, называемая адресацией локального сайта (FC00::/7), была
первоначально предложена в RFC3513 и может появляться в некоторых
реализациях IPv6, однако диапазон адресации устарел, как и в RFC4291,
так что следует избегать его использования в будущих реализациях.
Адрес многоадресной передачи является идентификатором набора интерфейсов
(обычно принадлежащих разным узлам). Пакет, отправленный на адрес
многоадресной передачи, доставляется на все интерфейсы,
идентифицированные этим адресом. Диапазон адресов многоадресной передачи
определяется по префиксу адреса FF00::/8 и четко отличается от первых 8 битов,
которые всегда установлены как 11111111. Архитектура адреса многоадресной
передачи состоит из полей flags (флаги), scope (область действия) и group ID
(идентификатор группы).
Поле флагов размером в 4 бита в настоящее время используется для поддержки
идентификации того, является ли адрес многоадресной передачи общеизвестным
(назначенным и признанным органом глобальной нумерации в Интернете) или
переходным, то есть временно назначенным. Значение второго бита используется
в поле флагов, чтобы определить, основан ли адрес многоадресной передачи на
префиксе сети. Оставшиеся два бита более высокого порядка зарезервированы и
остаются равными 0.
Область действия определяет ряд потенциальных диапазонов, к которым
применяется многоадресная передача. Обычно это область действия локального
узла FF01:: или область действия локального канала FF02::, то есть адреса
приемных узлов в области действия на уровне канала, например, сегмент
Ethernet, для которого шлюз определяет границу. Обычные локальные адреса
канала многоадресной передачи (multicast link local) включают FF02::1, который
используется для пересылки всем узлам, и FF02::2, который
обеспечивает многоадресную передачу всем адресам маршрутизаторов.
Адрес многоадресной передачи является идентификатором набора интерфейсов
(обычно принадлежащих разным узлам). Пакет, отправленный на адрес
многоадресной передачи, доставляется на все интерфейсы,
идентифицированные этим адресом. Диапазон адресов многоадресной передачи
определяется по префиксу адреса FF00::/8 и четко отличается от первых 8 битов,
которые всегда установлены как 11111111. Архитектура адреса многоадресной
передачи состоит из полей flags (флаги), scope (область действия) и group ID
(идентификатор группы).
Поле флагов размером в 4 бита в настоящее время используется для поддержки
идентификации того, является ли адрес многоадресной передачи общеизвестным
(назначенным и признанным органом глобальной нумерации в Интернете) или
переходным, то есть временно назначенным. Значение второго бита используется
в поле флагов, чтобы определить, основан ли адрес многоадресной передачи на
префиксе сети. Оставшиеся два бита более высокого порядка зарезервированы и
остаются равными 0.
Область действия определяет ряд потенциальных диапазонов, к которым
применяется многоадресная передача. Обычно это область действия локального
узла FF01:: или область действия локального канала FF02::, то есть адреса
приемных узлов в области действия на уровне канала, например, сегмент
Ethernet, для которого шлюз определяет границу. Обычные локальные адреса
канала многоадресной передачи (multicast link local) включают FF02::1, который
используется для пересылки всем узлам, и FF02::2, который
обеспечивает многоадресную передачу всем адресам маршрутизаторов.
После установления физического соединения с сетью IPv6 хосты должны
установить уникальный адрес IPv6 и связанные с ним параметры, такие как
префикс сети. Маршрутизаторы отправляют сообщения Router Advertisement
периодически, а также в ответ на запрос Router Solicitation (RS) в целях
обнаружения соседнего маршрутизатора и изучения префикса адреса и
параметров конфигурации для автоматической настройки адреса.
IPv6 поддерживает автоматическую настройку адреса без сохранения
состояния (stateless address auto-configuration; SLAAC), которая позволяет
хостам получать префиксы IPv6 и автоматически генерировать идентификаторы
интерфейса, без необходимости использования внешней службы, такой как
DHCP. Для автоматической настройки адреса IPv6 используется сообщение
Router Discovery, которое реализуется в двух форматах.
Сообщения Router Advertisement (RA), периодически отправляемые каждым
маршрутизатором в многоадресной рассылке, содержат параметры
конфигурации сети и служат для объявления о существовании маршрутизатора
хостам уровня 2 и другим маршрутизаторам. Сообщение RA идентифицируется
значением 134 в поле type. Сообщения запроса Router Solicitation (RS)
генерируются после подключения хоста к сети.
Маршрутизаторы будут периодически отправлять сообщения RA, однако, если
хост захочет запросить сообщение RA, он отправит сообщение RS.
Маршрутизаторы в сети сгенерируют сообщение RA для всех узлов, чтобы
сообщить хосту маршрутизатора по умолчанию о сегменте и связанных
параметрах конфигурации. Сообщение RS, сгенерированное хостом, можно
отличить по полю type, которое содержит значение 133.
Для организации связи по сети IPv6 каждому интерфейсу должен быть присвоен
действительный адрес IPv6. Идентификатор интерфейса адреса IPv6 может быть
определен либо посредством ручной настройки сетевым администратором, либо
сгенерирован с помощью системного программного обеспечения, либо
сгенерирован с использованием формата 64-битного расширенного уникального
идентификатора IEEE (EUI-64).
Из-за практичности наиболее распространенным методом адресации IPv6
является генерация идентификатора интерфейса в формате EUI-64. Для этого
используется MAC-адрес интерфейса, который представляет собой 48-битный
адрес, но требуемый идентификатор интерфейса должен состоять из 64-битного
значения. Первые 24 бита (выраженные c) MAC-адреса представляют
идентификатор поставщика (компании), а оставшиеся 24 бита (выраженные e)
представляют уникальный идентификатор расширения, назначенный
производителем.
Старший седьмой бит в адресе представляет универсальный/локальный бит для
включения идентификаторов интерфейса с универсальной областью действия.
Если это значение равно 0, MAC-адрес уникален глобально. Во время
преобразования процесс EUI-64 вставляет два октета значений «0xFF» и «0xFE»
на общую сумму 16 битов между идентификатором поставщика и
идентификатором расширения MAC-адреса, и универсальный/локальный бит 0
заменяется единицей (1), чтобы указать, что ID интерфейса теперь представляет
глобально уникальное значение адреса. 64-битный идентификатор
интерфейса создается и привязывается к префиксу интерфейса для
генерации адреса интерфейса IPv6.
Перед тем, как адрес одноадресной передачи IPv6 будет присвоен интерфейсу,
выполняется функция обнаружения дублирующихся адресов (DAD), которая
проверяет, используется ли этот адрес другим узлом. DAD требуется, если IP-
адреса настраиваются автоматически. Адрес IPv6 одноадресной передачи,
назначенный интерфейсу, но не проверенный функцией DAD, называется
предварительным адресом. Интерфейс не может использовать предварительный
адрес для одноадресной передачи, но может присоединиться к двум группам
многоадресной рассылки: группе многоадресной рассылки на все узлы (ALL-node)
и группе многоадресной рассылки на запрашиваемые узлы (Solicited-Node).
Адрес многоадресной передачи запрошенным узлам создается путем взятия
последних 24 битов одноадресного или произвольного адреса и добавления к
адресу префикса FF02:0:0:0:0:1:FF00::/104. В случае использования адреса
2000::1 будет сгенерирован адрес многоадресной передачи Solicited-Node
FF02::1:FF00:1.
IPv6 DAD похож на протокол gratuitous ARP, используемый в IPv4 для
обнаружения дублированных адресов хоста IPv4 при назначении адреса или
подключении хоста к сети. Узел отправляет сообщение neighbor solicitation (NS),
содержащий запрос предварительного адреса, который будет использоваться в
качестве адреса назначения для группы многоадресной передачи
запрашиваемому узлу.
Если узел получает ответное сообщение neighbor advertisement (NA),
предварительный адрес считается занятым другим узлом, и узел не будет
использовать его для связи, после чего потребуется назначение адреса
вручную администратором.
Адрес 2001:0DB8:0000:0000:0000:0000:032A:2D70 можно сжать до
2001:DB8::32A:2D70. Двойное двоеточие можно использовать для сжатия строк с
нулями, которые часто могут существовать из-за непостижимого размера
адресного пространства IPv6, но могут использоваться только один раз. Нулевые
значения в старших разрядах сжать можно, однако в младших разрядах нули
должны сохраняться.
Для генерации уникального адреса IPv6 может использоваться формат 64-битного
расширенного уникального идентификатора (EUI-64). Это достигается путем
вставки двух октетов «FF» и «FE» в существующий 48-битный MAC-адрес
интерфейса, чтобы создать уникальное 64-битное значение, которое принимается
как IPv6-адрес интерфейса конечной станции. Проверка правильности адреса как
уникального значения подтверждается протоколом обнаружения дублирующихся
адресов (DAD).
OSPFv3 — это версия протокола OSPF, которая используется в сетях IPv6. Для
организации передачи каждому маршрутизатору назначаются локальные адреса
одноадресной передачи на каждом из подключенных к маршрутизатору
физических каналов. Пакеты OSPF отправляются с использованием в качестве
адреса источника соответствующего локального адреса одноадресной передачи
данного физического интерфейса. Маршрутизатор изучает локальные адреса
каналов всех остальных маршрутизаторов, подключенных к его каналам, и
использует эти адреса как адреса следующих транзитных узлов во время
пересылки пакетов. Эта операция верна для всех физических каналов, за
исключением виртуальных каналов, которые не рассматриваются в данном
разделе.
Зарезервированному адресу многоадресной передачи «AllSPFRouters» присвоено
значение FF02::5, которое соответствует адресу многоадресной передачи
224.0.0.5, используемому в OSPFv2. Следует отметить, что эти две версии
несовместимы. Все маршрутизаторы, работающие с OSPFv3, должны быть готовы
к приему пакетов, отправленных на этот адрес. Пакеты Hello всегда отправляются
в этот пункт назначения, а также определенные пакеты протокола OSPF во время
лавинной рассылки (flooding).
Параметр router ID играет важную роль в OSPFv3 и теперь всегда используется
для идентификации соседних маршрутизаторов. Ранее идентификация
осуществлялась по IPv4-адресу широковещательной передачи, NBMA (не-
широковещательный многостанционный доступ) и двухточечной связи. Каждый
идентификатор маршрутизатора (а также идентификатор зоны — параметр area
ID) имеет формат 32-битного десятичного числа с точками, и его нельзя настроить
с использованием адреса IPv6.
Идентификатор маршрутизатора также продолжает использоваться для
арбитража в ситуации, когда приоритеты маршрутизаторов с включенным OSPFv3
равны. В таких случаях выделенный маршрутизатор (DR) рассматривается как
устройство, имеющее самое высокое значение router ID. В отсутствии
выделенного маршрутизатора отправленные сообщения Hello будут содержать
идентификатор маршрутизатора, установленный в значение 0.0.0.0. Тот же
принцип применяется к резервному выделенному маршрутизатору,
идентифицированному следующим самым высоким значением router ID.
Приоритет 0, установленный для интерфейса маршрутизатора, участвующего в
OSPFv3, означает, что маршрутизатор не подходит для участия в выборе
устройств DR/BDR. Приоритет маршрутизатора (Router Priority) настраивается
только для интерфейсов, связанных с широковещательной сетью и сетями NBMA.
Адресу многоадресной передачи «AllDRouters» было присвоено значение FF02::6,
эквивалентное адресу 224.0.0.6, используемому в OSPFv2 для IPv4. Выделенный
маршрутизатор (DR) и резервный выделенный маршрутизатор (BDR)
должны быть готовы к приему пакетов, направленных на этот адрес.
В IPv6 термин «канал» используется в качестве среды передачи между узлами на
канальном уровне. Таким образом, интерфейсы подключаются к каналам, и к
одному каналу могут быть привязаны несколько подсетей IPv6, поэтому даже
если два узла и не используют общую подсеть IPv6 (с префиксом IPv6), они все
равно могут обмениваться данными напрямую по такому каналу. В результате
OSPFv3 работает на основе канала, а не IP-подсети, как в IPv4. Поэтому термин
«канал» используется для замены терминов «сеть» и «подсеть», используемые в
OSPFv2. То есть, интерфейсы OSPF подключаются к каналу, а не к IP-подсети.
Это изменение влияет на процесс получения пакетов протокола OSPF,
содержимое пакетов Hello и network-LSA.
Также это изменение можно увидеть по способности OSPFv3 поддерживать
несколько экземпляров протокола OSPF в одном канале. То есть отдельные
домены маршрутизации OSPF, планирующие остаться отдельными, работают в
одном или нескольких физических сегментах сети (каналах), которые являются
для них общими. В IPv4 требовалось изолировать домены посредством
аутентификации, но этот метод не стал практической реализацией данного
требования.
Принцип per-link также означает, что пакет Hello больше не содержит никакой
информации об адресе, зато содержит идентификатор интерфейса, который
исходный маршрутизатор назначает для уникальной идентификации (среди своих
собственных интерфейсов) своего интерфейса.
Аутентификация в OSPFv3 больше не поддерживается, и поэтому поля типа
аутентификации и значения аутентификации в заголовке пакета OSPF больше не
существуют. В IPv6 изменения в заголовке IP позволили использовать протоколы
безопасности, которые присутствовали в IPv4 только в виде набора IPsec,
поскольку первые разработки TCP/IP в конце 1960-х годов не учитывали вопрос
безопасности, так как это условие не ставилось как обязательное будущее
требование.
Благодаря улучшениям безопасности, внесенным в IPv6, и использованию
заголовков расширений в наборе протоколов, во время обмена информацией
маршрутизации OSPFv3 применяет механизмы Authentication Header и
Encapsulating Security, обеспечивающие аутентификацию отправителя
информации, целостность и конфиденциальность данных.
Для реализации OSPFv3 между одноранговыми узлами требуется, как и в RIPng,
чтобы маршрутизатор поддерживал IPv6. Кроме того, на маршрутизаторе
необходимо глобально включить протокол OSPFv3 в режиме system-view.
Каждому интерфейсу должен быть присвоен адрес IPv6. В примере настройки
RIPng было продемонстрировано, как автоматически сконфигурировать
интерфейс для назначения локального адреса канала (link local). В данном
примере показан альтернативный и рекомендуемый метод назначения локального
адреса канала. Локальный адрес IPv6 настраивается вручную с помощью
команды ipv6 <link local address> link-local. Если адрес, связанный с физическим
интерфейсом, является глобальным адресом одноадресной передачи IPv6,
интерфейс также автоматически генерирует локальный адрес канала.
Для создания маршрута OSPFv3 в данном примере назначаются глобальные
адреса одноадресной передачи loopback-интерфейсу каждого маршрутизатора.
Физические и логические интерфейсы должны быть привязаны к процессу
OSPFv3 и иметь определенный ID процесса (обычно один и тот же ID, если они не
должны функционировать в качестве отдельных экземпляров OSPFv3). Также
указывается зона (в данном случае area 0).
Как уже упоминалось, узлы OSPFv3 определяют соседние маршрутизаторы по
параметру router ID (идентификатор маршрутизатора), и поэтому каждому
маршрутизатору должен быть присвоен уникальный router ID в соответствии с
протоколом OSPFv3 после конфигурирования команды ospfv3 .
После конфигурирования соседних маршрутизаторов, участвующих в OSPFv3,
выполняется команда display ospfv3 для проверки выполнения операции и
параметров, связанных с OSPFv3. Каждый маршрутизатор будет показывать
запущенный процесс OSPFv3 и уникальный идентификатор маршрутизатора.
Если смежность между соседями установлена, число соседей в состоянии FULL
будет больше нуля.
Для уникальной идентификации каждого узла, на котором включен OSPFv3,
используется 32-битный идентификатор router ID.
Протокол динамического конфигурирования хостов для IPv6 (DHCPv6) — это
технология, позволяющая осуществить централизованное динамическое
управление и конфигурацию IPv6-адресов. Он предназначен для назначения IPv6-
адресов и других параметров конфигурации сети хостам. Протокол DHCPv6
работает в соответствии с моделью клиент-сервер. Клиент запрашивает с сервера
конфигурации, такие как адрес IPv6 и адрес DNS-сервера. Сервер посылает
сообщение-ответ, содержащее запрашиваемые конфигурационные параметры на
основе политик.
При автоматической настройке адресов без отслеживания состояния (SLAAC)
маршрутизаторы не записывают адреса IPv6 хостов, поэтому такой режим
настройки имеет слабые возможности управления. Кроме того, узлы, настроенные
с автоматической настройкой адреса без отслеживания состояния, не могут
получить другие параметры конфигурации, такие как адрес сервера DNS.
Интернет-провайдеры не предоставляют инструкции для автоматического
назначения префиксов IPv6 для маршрутизаторов. Поэтому пользователям
необходимо вручную настраивать адреса IPv6 устройств во время развертывания
сети IPv6.
DHCPv6 позволяет решить эту проблему за счет автоматической настройки
адресов IPv6 с отслеживанием состояния. При использовании DHCPv6 с
отслеживанием состояния, сервер DHCPv6 назначает хосту полный IPv6-адрес и
предоставляет другие данные конфигурации. Такие параметры, как адрес DNS-
сервера и имя домена. Для пересылки пакетов DHCPv6 может
использоваться Агент ретрансляции, однако в данном документе
описания этого процесса не приводится. Сервер DHCPv6 привязывает
IPv6-адрес к клиенту, что позволяет оптимизировать возможности
управления сетью.
Клиенты и серверы обмениваются сообщениями DHCP при помощи
протокола UDP. Клиент использует адрес локального канала,
определенный другими механизмами, для передачи и получения
сообщений DHCP. Клиенты прослушивают UDP-порт 546 на предмет
DHCP-сообщений, а серверы (и агенты ретрансляции) — UDP-порт 547.
Перед распределением адресов следует четко понимать, что узел IPv6 (клиент)
необходим для генерации адреса локального канала и оценки с помощью
процесса обнаружения дублирующихся адресов (DAD). После этого включается
процесс обнаружения маршрутизатора, для которого клиентский узел IPv6
передает сообщение запроса маршрутизатора (RS), после получения которого
маршрутизатор канала отвечает сообщением Router Advertisement (RA,
объявление маршрутизатора).
В сообщении RA содержатся многочисленные поля с параметрами конфигурации
для локальной сети. Одно поле, в частности, поле Autoconfig Flags, представляет
собой 8-битное поле, которое содержит два конкретных битовых значения для
определения процесса автоматической конфигурации для локальной сети. «Флаг
управляемой настройки адреса» (M) — это значение первого бита,
предназначенное для определения необходимости использования конфигурации
адреса с отслеживанием состояния, обычно применяемой при наличии сервера
DHCPv6 в локальной сети. Если значение равно 1, то используется адресация с
отслеживанием состояния, то есть клиент IPv6 должен получать IPv6-адрес с
помощью DHCPv6 с отслеживанием состояния.
«Флаг других параметров настойки» (O) представляет значение второго бита в
поле Autoconfig Flags и определяет, должны ли другие параметры конфигурации
сети, такие как DNS и SNTP (для серверов управления временем), определяться с
помощью DHCPv6 с отслеживанием состояния. RFC2462 определяет, что там, где
бит M имеет значение true (значение 1), бит O также должен иметь
значение true, однако на практике бит M и бит O могут быть
взаимозаменяемыми для поддержки адресации без отслеживания
состояния в DHCPv6, при которой IPv6-адрес не назначается, а
параметры указаны.
Следует также отметить, что управление Флагом управляемой настройки
адреса (M) и Флагом других параметров настойки (O) осуществляется
через VRP на маршрутизаторе и не устанавливаются в сообщении RA по
умолчанию. Для того чтобы установить эти флаги на шлюзе, отвечающем
за генерацию сообщений RA, должны быть настроены команды ipv6 nd
autoconfig managed-address-flag и ipv6 nd autoconfig other-flag.
Обслуживание клиентских узлов, инициированных в сети с поддержкой адресации
с отслеживанием состояния, может выполнять как один, так и несколько серверов
DHCPv6. Клиент IPv6 использует адрес локального канала, назначенный
интерфейсу, для которого он запрашивает информацию о конфигурации, в
качестве адреса источника в заголовке датаграммы IPv6.
Адрес многоадресной передачи FF02::1:2 является зарезервированным адресом,
который представляет «All_DHCP_Relay_Agents_and_Servers» и используется
клиентом для связи с соседними серверами. Все серверы (и агенты
ретрансляции) являются членами этой многоадресной группы. Ожидается, что
любой клиент, отправляющий сообщение DHCP на адрес
All_DHCP_Relay_Agents_and_Servers, использует интерфейс, для которого
запрашивается информация о конфигурации, однако, когда два интерфейса на
клиенте связаны с одним и тем же каналом, для которого возможно
использование альтернативного интерфейса, могут возникнуть исключения из
правила. В любом случае, в качестве адреса источника должен использоваться
адрес локального канала интерфейса пересылки.
Для получения адресов с отслеживанием состояния и других параметров сервера
DHCPv6 требуется отправить несколько сообщений. Сначала клиент отправляет
сообщение-обращение (solicit) для поиска серверов, от которых можно получить
параметры адресации и конфигурации.
После сообщения-обращения сервер DHCPv6, поддерживающий канал,
генерирует сообщение-объявление (advertise) в ответ на сообщение-обращение,
которое указывает клиенту IPv6-адрес сервера, предоставляющего требуемую
услугу DHCPv6. Затем клиент может использовать этот адрес IPv6 для ссылки на
сервер DHCPv6 и сгенерировать сообщение-запрос (request). Если на запрос
отвечают несколько серверов, клиенту необходимо решить, какой сервер DHCPv6
следует использовать. Как правило, это определяется по значению приоритета
сервера, которое определяет администратор DHCPv6 на сервере, и которое
передается в сообщении-объявлении (advertise). Сервер так же может содержать
параметры, включая параметр одноадресной рассылки, которые позволяют
клиенту использовать IPv6-адрес сервера DHCPv6 для дальнейшей передачи
сообщений в качестве сообщений одноадресной рассылки.
Сообщение-запрос передается на выбранный DHCP-сервер для запроса
параметров конфигурации и одного или нескольких адресов IPv6, которые должны
быть назначены. Наконец, сервер DHCPv6 передает сообщение-ответ (reply),
которое содержит подтвержденные адреса и параметры конфигурации сети.
DHCP также может использоваться для поддержки конфигурации без
отслеживания состояния в том случае, когда хост способен извлекать
информацию IPv6-адресации с помощью средств конфигурации без отслеживания
состояния и ему нужны только определенные параметры конфигурации с сервера
DHCPv6. В этом случае генерируются сообщения Information-request (Запрос
информации) и отправляются с клиента на сервер для запроса параметров
конфигурации. Клиент может получить информацию о конфигурации, такую как
адреса серверов и информацию о домене, в виде списка доступных параметров
конфигурации, используя только одно сообщение и ответ, которым обменивается
с сервером DHCP.
Сообщение Information-request отправляется на адрес многоадресной рассылки
«All_DHCP_Relay_Agents_and_Servers», после чего серверы отвечают
сообщением Reply, содержащим информацию о конфигурации для клиента.
Поскольку динамическое состояние не поддерживается (то есть в форме
назначения IPv6-адресов), распределение информации о конфигурации
понимается как процесс «без отслеживания состояния».
Уникальный идентификатор DHCP (DUID) — это значение, которое используется
для различения клиентов и сервера DHCP, которые имеют только один DUID.
Клиенты могут иметь один или несколько интерфейсов, каждому из которых будет
назначен IPv6-адрес наряду с другими параметрами конфигурации и на которые
можно ссылаться с помощью идентификатора (IAID). Они используются вместе с
DUID, чтобы серверы DHCPv6 могли ссылаться на клиента и адрес
интерфейса/параметры конфигурации, которые должны быть назначены.
Для каждого клиента используется DUID для идентификации конкретного DHCP-
сервера, с которым клиент хочет установить связь. Длина значения DUID может
варьироваться в диапазоне от 96 битов (12 байтов) до 160 битов (20 байтов), в
зависимости от используемого формата. Существует три таких формата,
использующих либо адрес канального уровня (DUID-LL), либо комбинацию адреса
канального уровня и корпоративного номера (DUID-EN), либо значение,
назначенное поставщиком в пункте изготовления устройства, либо комбинацию
адреса канального уровня и значения метки времени (DUID-LLT),
сгенерированные в секундах в момент создания DUID с полуночи 1 января 2000
года (GMT), по модулю 232.
Начальные 16-битные значения (00:01) представляют используемый формат, где
«00:01» обозначает формат DUID-LLT, «00:02» формат DUID-EN и «00:03» формат
DUID-LL. В случае форматов DUID-LL и DUID-LLT 16 битов, следующих сразу за
ними, представляют аппаратный адрес на основе назначений параметров типа
оборудования IANA, где 00:01 представляют Ethernet (10 МБ), а 00:06
определяют сетевые стандарты IEEE 802. Временная метка следует в
формате DUID-LLT и, наконец, значение адреса канального уровня. Для
DUID-LL следует только адрес канального уровня.
Команда dhcpv6 duid используется для назначения формата DUID, для чего может
применяться формат DUID-LL или DUID-LLT. Формат DUID-LL применяется по
умолчанию. Для DUID-LLT значение метки времени (timestamp) указывает время с
момента применения команды dhcpv6 duid llt. Команда display dhcpv6 duid может
использоваться для проверки текущего формата, на основании длины значения
DUID, а также самого значения DUID.
Реализация адресации с отслеживанием состояния требует, чтобы пул адресов
был определен с типичным префиксом адреса, установленным для данного
диапазона, а также с конкретными параметрами пула. Данный пример
демонстрирует способ создания пула с определением пула и связанного имени
пула, а также префикса адреса, на основании которых будет выделен диапазон
адресов хоста.
Исключенные адреса — это адреса, которые составляют диапазон пула, но
которые не должны выделяться через DHCP, поскольку они обычно используются
для других приложений, таких как адрес интерфейса сервера DHCP. Для данного
пула также определяются дополнительные параметры, например, адреса
серверов и доменные имена, которые указываются для назначения параметров
клиентам DHCPv6.
Создаваемый пул DHCPv6 должен быть связан с интерфейсом, через который он
будет обслуживать клиентов DHCP. Адрес IPv6 присваивается интерфейсу
сервера DHCPv6 и интерфейсу, связанному с адресным пулом. В этом случае
значение исключенного адреса использовалось для отображения адреса
интерфейса, чтобы сервер DHCPv6 не предпринимал попыток присвоить адрес
интерфейса DHCP-клиенту.
Получаемую в итоге конфигурацию сервера DHCPv6 можно уточнить с помощью
команды display dhcpv6 pool, позволяющей идентифицировать определенный пул
и определить префикс адреса, связанный с пулом. Можно просмотреть
дополнительную информацию, такую как срок службы, для которой срок действия
арендованного адреса по умолчанию составляет 86400 секунд, или 1 день, и
может быть перенастроен по мере необходимости с помощью команды
information-refresh в режиме dhcpv6 pool <pool-name>. Если активные клиенты
имеют арендованные адреса с сервера DHCP, то здесь можно найти
соответствующие статистические данные.
Маршрутизатор серии AR2200 поддерживает форматы Link Layer (DUID-LL) и Link
Layer с Time (DUID-LLT).
При получении сообщения-объявления маршрутизатора, содержащего значения
битов M и O, равные 1, клиент выполнит обнаружение сервера DHCPv6 для
конфигурации адреса с отслеживанием состояния. Такая конфигурация будет
включать в себя IPv6-адрес и другие параметры конфигурации, например,
префиксы и адресацию серверов, предоставляющих услуги DNS.
В традиционной модели переадресации IP-пакетов физический уровень получает
пакет от порта на маршрутизаторе, а затем отправляет его на канальный уровень.
После удаления инкапсулированной информации на канальном уровне данные
отправляются на соответствующий сетевой уровень согласно информации,
содержащейся в поле протокола пакета.
На сетевом уровне проверяется, на это ли устройство отправлен пакет; если пакет
отправлен на это устройство, то происходит удаление инкапсулированной
информации с сетевого уровня и ее последующая отправка на протокол верхнего
уровня. Если нет, то происходит поиск маршрута в таблице маршрутизации
согласно IP-адресу назначения пакета. При соответствии маршрута пакет будет
отправлен на канальный уровень соответствующего порта и, после инкапсуляции
на канальном уровне, передан дальше. При отсутствии соответствий пакет
отбрасывается.
В традиционной модели переадресации IP-пакетов используется переадресация
данных в режиме hop-by-hop (последовательная передача). Процесс реализуется
на каждом маршрутизаторе, через который проходит пакет (как показано на
рисунке, RTA получает пакет данных с IP-адресом назначения 10.2.0.1, затем
просматривает таблицу маршрутизации и производит передачу согласно
сопоставимому маршруту; такие же действия выполняют RTB, RTC и RTD).
Эффективность такой передачи низка, так как всем маршрутизаторам необходимо
обладать информацией обо всех маршрутах во всей сети или маршрутах по
умолчанию.
Кроме того, традиционная модель переадресации IP-пакетов не
ориентирована на установление соединения, поэтому трудно произвести
развертывание QoS.
MPLS — это технология переадресации меток, в которой используются плоскость
управления, не ориентированная на соединение (connectionless control plane), и
плоскость данных, ориентированная на соединение (connection oriented data
plane). Плоскость управления, не ориентированная на соединение, реализует
маршрутную передачу и распределение меток, а плоскость данных,
ориентированная на соединение, реализует передачу пакетов по установленному
ранее LSP (маршруту с коммутацией меток).
В сетевом домене MPLS маршрутизатору не нужно анализировать каждый IP-
адрес назначения пакета: он производит передачу в соответствии с меткой,
добавленной перед IP-заголовком (как показано на рисунке, RTB получает от RTA
пакет, содержащий метку, затем производит передачу в соответствии с меткой;
аналогичная процедура совершается и для RTC). По сравнению с традиционной
переадресацией IP-пакетов, переадресация меток с помощью MPLS значительно
повышает эффективность передачи данных.
Однако, с развитием технологии ASIC (application-specific integrated circuit,
«интегральная схема специального назначения») скорость поиска маршрутов уже
не является «узким местом» для развития сети. Повышение скорости
переадресации перестало быть очевидным преимуществом сети MPLS.
MPLS объединяет в себе преимущества двух технологий переадресации: мощную
функцию маршрутизации уровня 3 IP-сети и высокоэффективный механизм
переадресации в традиционной сети уровня 2; плоскость переадресации MPLS
ориентирована на соединение и напоминает уже существующий метод
переадресации в сети уровня 2.
Таким образом, MPLS может легко и эффективно реалализовывать сочетание IP-
сетей и АТМ, Frame Relay и других сетей уровня 2, а также предоставляет лучшее
решение для ТЕ (Traffic Engineering, инжиниринг трафика), VPN (Virtual Private
Network, виртуальная частная сеть), QoS (Quality of Service, качество
обслуживания) и других сценариев применения.
VPN, основанная на MPLS, может сочетать в себе различные ответвления частной
сети, формируя единую сеть. Также такая VPN поддерживает управление связью
между различными VPN. Как показано на рисунке, СЕ является пограничным
устройством пользователя; РЕ – пограничный маршрутизатор поставщика услуг,
расположенный в магистральной сети. P – магистральный маршрутизатор в сети
поставщика услуг; маршрутизатор P не соединяется напрямую с СЕ. Данные VPN
передаются по LSP (маршруту с коммутацией по меткам), в который
инкапсулирована метка MPLS.
MPLS TE объединяет технологию MPLS и TE, резервирует ресурсы посредством
установления туннелирования LSP к назначенному пути, позволяет избежать
перегрузки узла и, таким образом, достичь цели — балансировки сетевого
трафика.
Как показано на рисунке, 70% трафика от сети А к сети В передается по маршруту
RTB-RTC-RTD, а 30% трафика — по маршруту RTB-RTG-RTH-RTD.
Такой же объем трафика передается от сети В к сети С.
На данном слайде представлена типичная структура сети MPLS: маршрутизатор и
коммутатор АТМ, расположенные внутри домена MPLS, называются LSR;
маршрутизатор и коммутатор АТМ, расположенные на границе домена MPLS,
который используется для подключения к IP-сети или другим видам сетей,
называются LER.
В IP-сети реализуется традиционная модель переадресации IP-пакетов; в домене
MPLS реализуется переадресация меток.
И LER, и LSR обладают возможностью переадресации меток, однако данные
маршрутизаторы расположены в разных местах, и процедура обработки пакетов у
них различается. LER должен получить IP-пакет из IP-сети, вставить метку в пакет
и передать пакет LSR. Кроме того, LER также должен получить пакет с меткой из
LSR, удалить метку и передать пакет в IP-сеть. LSR, в свою очередь, должен
осуществить передачу в соответствии с меткой.
Маршрут, по которому проходит пакет в домене MPLS, называется маршрутом с
коммутацией по меткам (LSP). Данный маршрут устанавливается и
подтверждается различными протоколами до переадресации пакетов. Таким
образом, пакеты будут передаваться по указанному LSP.
В сети MPLS переадресация пакетов производится в соответствии с меткой. Но
как генерируется метка? Какой механизм используется MPLS для реализации
переадресации данных?
MPLS включает две плоскости: плоскость управления и плоскость данных.
Плоскость управления предназначена для генерирования и сохранения
информации о маршрутах и метках. Плоскость данных выполняет
стандартную переадресацию IP-пакетов и пакетов с метками. В плоскости
управления модуль протокола маршрутизации используется для передачи
информации о маршруте, формирования таблицы маршрутизации.
Протокол распределения меток используется для завершения обмена
метками и установления маршрута коммутации по меткам.
Плоскость данных включает в себя таблицу IP-переадресации и таблицу
переадресации меток. Если идет стандартная переадресация IP-пакетов, то
при получении стандартных IP-пакетов происходит поиск маршрута в
таблице маршрутизации и дальнейшая передача; если же идет
переадресация меток, то передача совершается по таблице переадресации
меток. Если необходимо совершить передачу по меткам, то при получении
пакетов с метками передача должна осуществляться по таблицам
переадресации меток; если необходимо передать данные в IP-сеть, то
необходимо удалить метки и осуществить передачу в соответствии с
маршрутом в таблице IP-маршрутизации.
Метки MPLS используются для передачи информации MPLS. Маршрутизаторы
обмениваются метками для передачи данных по установленным маршрутам
переадресации меток.
 Длина заголовка MPLS составляет 32 бита и включает в себя: поле метки (20
битов; используется для переадресации данных); EXP (3 бита; используется
для передачи приоритета IP-пакета); S (1 бит, находится на дне стека метки и
указывает, последняя ли это метка, так как возможно наличие нескольких
вложенных меток MPLS); TTL (8 битов, его функция аналогична функции TTL IP-
заголовка; TTL используется для предотвращения зацикливания данных).
Поле протокола PID в заголовке уровня 2 указывает, что полезная нагрузка
начинается с пакета, имеющего инкапсулированную метку, или IP-заголовка.
Например, в протоколе Ethernet PID=0x8847 указывает, что полезная нагрузка
кадра — это пакет многоадресной передачи MPLS. PID=0x8848 указывает, что
полезная нагрузка кадра — пакет одноадресной передачи MPLS. PID=0x0800
указывает, что полезная нагрузка кадра — IP-пакет одноадресной передачи. В
протоколе РРР, PID=0x8281 указывает, что полезная нагрузка кадра — пакет
одноадресной передачи MPLS. PID=0x8283 указывает, что полезная нагрузка
кадра — это пакет многоадресной передачи MPLS.
S-бит в заголовке MPLS указывает, является ли следующий заголовок другой
меткой или IP-заголовком уровня 3.
Обычно MPLS назначает пакету только одну метку, но в некоторых передовых
сценариях применения MPLS используется несколько меток. Например, в MPLS
VPN используются 2 уровня меток (в сложных случаях количество уровней меток
может достигать 3); внешняя метка (out-label) используется для передачи данных
в общедоступной сети, а внутренняя метка (in-label) — для обозначения того, к
какой VPN относится пакет. В MPLS ТЕ также используются два или более уровня
меток; самая верхняя метка используется для указания туннелирования TE, а
внутренняя метка указывает на адрес назначения пакета.
Примечание: Метка 1, Метка 2, Метка 3 означают 4 байта заголовка MPLS,
который включает в себя информацию о метках размером 20 битов.
Класс эквивалентности передачи (FEC) — это группа IP-пакетов, которые
пересылаются в согласно методу эквивалентности. Например, группе IP-пакетов с
одним и тем же IP-префиксом назначения будет присвоена уникальная метка. В
этом случае пакет с IP-префиксом назначения 10.2.0.0/24 относится к FEC, метка,
присвоенная для этого FEC, — 1030.
NHLFE используется при переадресации пакетов, снабженных меткой, и содержит
следующую информацию:
1. следующий переход пакета;
2. операции, выполняемые в стеке меток пакета (который содержит
информацию о добавлении новой метки, удалении метки и замене
исходной метки новой). NHLFE может также содержать другую
информацию, например, инкапсуляцию канального уровня, используемую
при передаче пакетов. В этом случае следующий переход будет 10.1.1.2, а
операция с меткой — «push».
 FEC представляет пакеты одного и того же типа. NHLFE содержит информацию
о следующем переходе, операции с метками и другую информацию. Только при
связи FEC с NHLFE возможно осуществить передачу пакетов одного и того же
типа по определенным меткам. Эту функцию может выполнить FTN (FEC-to-
NHLFE). FTN указывает на сопоставление FEC с NHLFE; если существует
несколько равноценных маршрутов, один FEC может быть сопоставлен с
несколькими NHLFE.

 Когда IP-пакет поступает в домен MPLS, ingress LER (RTA) анализирует пакет,
определяет, какую метку инкапсулировать в пакет в соответствии с
характеристиками пакета (обычно путем анализа префикса IP-адреса
назначения), а также какой следующий переход и из какого интерфейса
необходимо совершить.

Для управления переадресацией пакетов на входе (ingress) запрашивается

таблица NHLFE.
Транзитный узел LSR (RTB) получает от RTA сообщение с меткой MPLS 1030 и
пересылает его в соответствии с меткой MPLS. RTB находит следующий переход
10.1.1.6, заменяет входящую метку исходящей и затем продолжает
переадресацию. (Данный случай особый: исходящая и входящая метки
одинаковы.)
ILM сопоставляет каждую входящую метку с набором NHLFE, который
используется при переадресации входящих пакетов, снабженных меткой. Если
существует несколько равноценных маршрутов, одна входящая метка
сопоставляется с несколькими NHLFE.
 Как и в случае с RTB, при получении сообщения с меткой 1030, RTC
пересылает пакет в соответствии с меткой и заменяет исходную метку
исходящей.

 В этом случае RTC исходящей меткой 1032 заменяет входящую метку, затем
передает пакет с исходящего интерфейса Serial3; следующий переход —
10.1.1.10.
 Egress LSR (RTD) получает сообщение с меткой 1032, удаляет метку, находит
маршрут в таблице IP-маршрутизации и пересылает сообщение по данному
маршруту.

 В этом случае RTD удаляет метку 1032 и пересылает сообщение на следующий

переход 10.2.0.2.
Ответы:
1: C
2: ABC
LDP (Label Distribute Protocol, протокол распределения меток): осуществляет
распределение меток на основе адресов назначения, причем вместо IP-передачи
используется переадресация меток. Преимущества LDP: LDP изолирует
маршруты общедоступной сети, выбирает оптимальные маршруты передачи и
поддерживает технологию ECMP. Конфигурация LDP проста.
Различные типы сервисов, такие как передача голосовых, видео и других данных,
а также VR предъявляют различные требования к сети. Требования к полосе
пропускания растут, стремительно расширяется масштаб сети. В традиционной
модели технологии MPLS требуется использование специального протокола
распределения меток. Каждому LSP необходимо назначить метки, которые
занимают большой объем ресурсов. Пакеты протокола состояния обслуживания
занимают большую полосу пропускания. Необходимо синхронизировать LDP с
протоколом IGP. Однако развертывание и обслуживание сопряжено со
сложностями, к тому же, LDP обладает слабыми возможностями
масштабирования. Данный режим работы сети не может удовлетворить
требования поставщиков услуг, которым необходимо совершить быстрое
развертывание сетевых услуг по требованию. К тому же, с увеличением масштаба
линейно увеличиваются и операционные затраты (OPEX).
 LDP рассчитывает LSP в зависимости от данных в таблице маршрутизации IGP.
RSVP: протокол резервирования ресурсов. RSVP-TE используется для решения
проблемы передачи данных только по оптимальному маршруту в традиционной
IP-сети, где маршрут не может быть запланирован. RSVP-TE обладает многими
преимуществами, такими как планирование указанного маршрута,
резервирование ресурсов полосы пропускания и наличие нескольких схем
защиты.
Для поддержания статуса соседа и канала RSVP полагается на IGP, усложняя
плоскость управления, процедуру обслуживания сети и локализацию
неисправностей.
Для реализации функции ECMP протоколу RSVP-TE необходимо создать
несколько туннелей.
При обслуживании состояния LSP необходимо постоянно обновлять PATH и
RESV. После увеличения объема сервисов на промежуточном узле возникают
проблемы с производительностью (услуги накладываются друг на друга). К тому
же, операторы всегда критикуют количество конфигураций туннеля RSVP-TE. Для
каждого туннеля необходимо сконфигурировать в среднем восемь туннелей.
C: Контроль
F: Переадресация
SDN (Software defined Network) — это инновационная архитектура сети,
предложенная абсолютно с нуля исследовательской группой Стэндфордского
университета. Базовая технология отделяет плоскость управления от плоскости
данных для реализации гибкого управления сетевым трафиком и предоставляет
эффективную платформу для усовершенствования базовых сетей и приложений.
В революционной сети SDN используется архитектура централизованного
управления. Функции управления сетевыми устройствами (такие как расчет
маршрута) сосредоточены на одном контроллере, таблица переадресации
генерируется и доставляется контроллером на устройство. В упрощенные
функции устройства входит только выполнение переадресации. OpenFlow
является интерфейсом управления между контроллером и устройствами.
Инкрементальная сеть SDN расширяет существующую сеть. Существующие
устройства формируют SDN. Некоторые функции управления на устройстве
зарезервированы. Некоторые функции, требующие централизованного
управления, обрабатываются на контроллере, что является доказательством
способности устройства к осуществлению плавной эволюции.
Префиксный сегмент (Prefix Segment) указывает на адрес назначения, а сегмент
смежности (Adjacency Segment) — это исходящий канал пакета данных, который
может быть схожим с IP-адресом назначения и исходящим интерфейсом в
традиционной IP-передаче. В области IGP, устройство сетевого элемента
выполняет лавинную рассылку SID узла и SID смежности устройства сетевого
элемента, используя расширенное сообщение IGP, так что любой сетевой
элемент может получить информацию о другом сетевом элементе. Любой
маршрут в сети может быть построен путем последовательного объединения
префиксного SID/SID узла и SID смежности. При совершении переходов по
маршруту каждый следующий переход отличается от другого информацией
верхнего сегмента стека. Информация о сегментах последовательно размещается
поверх заголовка данных. Если в информации о верхнем сегменте стека
содержится идентификатор другого узла, принимающий узел передает пакет
данных на следующий узел по маршрутам равной стоимости (ECMP). Если в
информации о верхнем сегменте стека содержится идентификатор текущего узла,
то принимающий узел высвечивает верхний сегмент и выполняет задачу,
требуемую для следующего сегмента.
В фактических сценариях применения сегмент смежности, префиксный сегмент и
сегмент узла могут использоваться независимо или совместно.
Существует три сценария: префиксный сегмент, сегмент смежности, сегмент
смежности + сегмент узла.
В сегментной маршрутизации последовательность сегментов, представляющая
маршрут передачи, инкапсулируется в заголовок пакета данных, затем данный
пакет передается вместе с пакетом данных. После получения пакета данных
сетевой узел анализирует последовательность сегментов. Если верхний
идентификатор сегмента в последовательности сегментов — SID узла, сетевой
узел пересылает последовательность сегментов на узел по кратчайшему
маршруту, рассчитанному SPF (при существовании эквивалентного маршрута
может быть реализован ECMP); если маршрут — SID смежности,
последовательность сегментов пересылается на следующий узел в соответствии
с SID смежности; затем пакет данных достигает узла назначения.
В качестве примера рассмотрим LSP от узла PE1 до узла PE2.
1. Петлевой адрес (loopback address) интерфейса LoopBack1 на исходящем PE2
— x.x.x.x/x, SID, назначенный адресу, — 10; производится лавинная рассылка
информации по всему домену IS-IS.
2. Все узлы получают SID узла от узла PE2 и генерируют таблицу переадресации меток.

Входящая метка: начальное значение локального SRGB + освобожденное значение

смещения.

Исходящая метка: начальное значение SRGB следующего перехода + объявленное

значение смещения.

Следующий переход исходящего интерфейса: следующий переход исходящего

интерфейса по кратчайшему маршруту, рассчитанному IGP.
3. Входной PE1 выполняет расчет IS-IS SPF для получения двух кратчайших маршрутов к
узлу PE2 из ECMP.
Тип операций с метками SR совпадает с типом в протоколе MPLS, включая добавление
стека меток (label stack push), замену стека меток (label stack swap) и удаление стека
меток (label popping, Pop).

На рисунке ниже в качестве примера используется туннель SR-BE от PE1 к PE2.

1. PE1 на входном узле: после получения пакета услуг PE1 инкапсулирует исходящую
метку, назначенную на следующий переход P в соответствии с адресом назначения,
таблицей переадресации меток и алгоритмом распределения трафика ECMP, а затем
передает пакет через соответствующий интерфейс на основе префиксного SID
назначения и таблицы переадресации меток.

Пример:

Push 210 to P1 (добавление 210 к P1)

Push 310 to P2 (добавление 310 к P2)

2. Транзитный узел: следующему переходу назначается исходящая метка SR в
соответствии с внешней меткой и таблицей переадресации меток, а исходящая метка
передается через соответствующий интерфейс.

Пример:

Swap 210 to 410 on P1 (замена 210 на 410 на узле P1)

Swap 310 to 510 on P2 (замена 310 на 510 на узле P2)

3. Выходной узел PE2: если осталась только внешняя метка, она удаляется, а пакет услуг
передается на СЕ в соответствии с внешним IP-адресом.

Пример:

Pop 610 from P3 (удаление 610 из P3)

Pop 610 from P4 (удаление 610 из P4)

1. Генерация меток, таблиц переадресации меток и информации о топологии.
Узлы в сети используют протокол SR IS-IS для распределения SID смежности,
совершают лавинную рассылку идентификаторов по всей сети и генерируют записи
передачи меток для локальных SID смежности, выделенных узлам. Кроме того,
генерируется информация о топологии с информацией о SID смежности.
Также сконфигурированные вручную SRGB/префиксный SID/SID узла, емкость SRGB и
алгоритм SRGB лавинно рассылаются в домен IGP через пакеты IGP. С помощью IS-
IS SPF каждый узел рассчитывает кратчайший маршрут передачи меток каждого узла
и генерирует таблицу переадресации меток.
2. Отчет о метках и информация о топологии.
Каждый узел в сети передает информацию о топологии с информацией о SID смежности
контроллеру через протокол BGP Link-State (BGP-LS).
3. Расчет пути
С помощью элемента расчета маршрута (PCEP) контроллер рассчитывает маршрут
передачи метки.
4. Доставка маршрутов.
Контроллер передает информацию о туннеле через PCEP и атрибуты туннеля первому
узлу туннеля через NETCONF. Первый узел туннеля сообщает о статусе туннеля
 контроллеру через PCEP.
5. Создание туннеля.
Первый узел туннеля создает туннель SR-TE на основе стека меток,
поставляемого контроллером.
1. Генерация меток, таблиц переадресации меток и информации о топологии.
Узлы в сети используют протокол SR IS-IS для распределения SID смежности,
совершают лавинную рассылку идентификаторов по всей сети и генерируют записи
переадресации меток для локальных SID смежности, выделенных узлам. Кроме того,
генерируется информация о топологии с информацией о SID смежности.
Также сконфигурированные вручную SRGB/префиксный SID/SID узла, емкость SRGB и
алгоритм SRGB лавинно рассылаются в домен IGP через пакеты IGP. С помощью IS-
IS SPF каждый узел рассчитывает кратчайший маршрут переадреации меток каждого
узла и генерирует таблицу переадресации меток.
2. Отчет о метках и информация о топологии.
Каждый узел в сети передает информацию о топологии с информацией о SID смежности
контроллеру через протокол BGP Link-State (BGP-LS).
3. Расчет пути
С помощью элемента расчета маршрута (PCEP) контроллер рассчитывает маршрут
переадресации метки.
4. Доставка маршрутов.
Контроллер передает информацию о туннеле через PCEP и атрибуты туннеля первому
узлу туннеля через NETCONF. Первый узел туннеля сообщает о статусе туннеля
 контроллеру через PCEP.
5. Создание туннеля.
Первый узел туннеля создает туннель SR-TE на основе стека меток,
поставляемого контроллером.
 Узел SR выполняет операцию с меткой пакета согласно стеку меток,
соответствующему туннелю SR-TE в заголовке пакета. Затем в соответствии с
верхней меткой стека выполняется поиск исходящего интерфейса в режиме hop-by-
hop для указания адреса назначения туннеля пакетам данных, которые необходимо
передать.

В качестве примера рассмотрим строгий маршрут (strict path) по туннелю SR-TE от PE1 к
PE2.

1. PE1 на входном узле: после получения пакета услуг PE1 инкапсулирует стек меток,
соответствующий туннелю SR-TE, согласно туннелю SR-TE, определяемому политикой
маршрутизации или политикой туннеля, сконфигурированной в услуге. Если определено,
что соответствующая верхняя метка стека 501 является SID смежности, она удаляется, а
оставшаяся часть [103, 304, 406] стека меток инкапсулируется в пакет услуг и передается
с соответствующего интерфейса PE1->P1 в соответствии с верхней меткой и таблицей
переадресации меток.
2. Транзитный узел: если верхняя метка стека является SID смежности, отображается
верхняя метка стека, и верхняя метка стека и таблица переадресации меток
пересылаются через соответствующий интерфейс.

В качестве примера возьмем P1: если определено, что верхняя метка стека 103 является
SID смежности, появляется верхняя метка стека 103, затем верхняя метка стека 103
передается из соответствующего интерфейса P1->P3 согласно верхней метке 103 и
таблице переадресации меток.
 3. Выходной узел PE2: передает пакеты услуг СЕ в соответствии с внешним IP-
адресом пакетов услуг.
Узел SR выполняет операцию с меткой пакета согласно стеку меток, соответствующему
туннелю SR-TE в заголовке пакета. Затем в соответствии с верхней меткой стека
выполняется поиск исходящего интерфейса в режиме hop-by-hop для указания адреса
назначения туннеля пакетам данных, которые необходимо передать.

В качестве примера рассмотрим свободный маршрут (loose path) по туннелю SR-TE от

PE1 к PE2.

1. PE1 на входном узле: после получения пакета услуг PE1 инкапсулирует стек меток
[1004, 403, 306], соответствующий туннелю SR-TE, согласно туннелю SR-TE,
определяемому политикой маршрутизации или политикой туннеля, сконфигурированной
в услуге. PE1 инкапсулирует исходящую метку SR 1004, назначенную узлом Р
следующего перехода, в соответствии с внешней меткой и таблицей передачи меток и
передает исходящую метку SR 1004 в соответствии с таблицей переадресации меток.
2. Транзитный узел P2: в соответствии со внешней меткой 1004 и таблицей
переадресации меток, внешняя метка заменяется на исходящую метку 1004,
назначенную следующему переходу, и пересылается через соответствующий интерфейс
P2->P4.
3. Транзитный узел P4: осталась только внешняя метка 1004, поэтому происходит ее
удаление. Определив, что метка следующего уровня 403 — это SID смежности, узел
удаляет метку 403 и пересылает таблицу переадресации меток с соответствующего
интерфейса P4->P3 согласно таблице переадресации меток.
4. Транзитный узел P3: определяет, что внешняя метка 306 — это метка смежности,
удаляет внешнюю метку 306 и пересылает ее с соответствующего интерфейса P3->PE2
согласно таблице переадресации меток.
5. Выходной узел PE2: передает пакеты услуг СЕ в соответствии с внешним IP-адресом
пакетов услуг.
Ответ
1:ABD
2:ABC