Сообщение ICMP, использующееся протоколом IRDP.

Маршрутизаторы периодически рассылают в сетевой сегмент такие сообщения, чтобы уведомить все узлы о своём наличии и параметрах IP. В качестве адреса назначения указывается 224.0.0.1 или 255.255.255.255, если маршрутизатор не поддерживает мультикаст.

TTL пакета равен 1.

Сообщение ICMP, использующееся протоколом IRDP.

Такие сообщения отправляются узлами на адрес 224.0.0.2 или 255.255.255.255 в поисках шлюза в данном сегменте. Все маршрутизаторы, получив Router Solicitation, должны ответить на него сообщением Router Advertisement.

Используется, например, при подключении нового узла в сеть.
TTL пакета равен 1.

Идентификатор устройства в IPv4. Состоит из 32 бит. Для удобства записи делится на 4 октета (группа из 8 бит) и каждый октет записывается в десятичном формате, например, 192.168.1.247.

Два устройства, имея IP-адреса, могут передавать друг другу данные, где бы они ни находились — главное, чтобы работала маршрутизация.
Существует два принципа адресации в IPv4 — классовая и бесклассовая.

Маска определяет, какая часть IPv4-адреса будет адресом сети, а какая адресом узла в этой сети.

Она представляет из себя строку длиной в 32 бита, как и IP-адрес.

В маске сначала идут только единицы, потом только 0 (0 и 1 не могут перемежаться). Та часть, где идут единицы — это адрес сети, где нули — адрес узла в сети.

При назначении адреса узлу между IPv4 адресом и IPv4 маской прямое соответствие: там, где в маске 1, там биты адреса не могут меняться, там, где 0 — могут.

Например, если для сети 192.168.1.0 (двоичная запись: 11000000.10101000.00000001.00000000) маска выглядит так: 11111111.11111111.11111111.00000000, это означает, что первые три октета для адресов из этой сети будут оставаться неизменными: 192.168.1, а биты последнего октета будут менять от всех нулей до всех единиц: 00000000-11111111 (0-255).

То есть в данном случае 192.168.1 — адрес сети, а адреса хоста может быть выбран в диапазоне 0-255.

В записи CIDR это бы выглядело так: 192.168.1.0/24.

Длина заголовка IP-пакета в 32-битных словах. Указывает по сути на начало блока данных.

Флаг IP-пакета, который сообщает, что пакет нельзя фрагментировать.

Флаг IP-пакета, который информирует о том, не является ли данный пакет последним фрагментом фрагментированного пакета.

Поле заголовка IP, изначально предназначенное для реализации функций QoS. Длина 8 бит. Как таковое сейчас разделено на два поля: DSCP и ECN.

Специальный диапазон IP-адресов, которые позволяют устройствам взаимодействовать только в пределах одного широковещательного домена — отсюда и название — локальный для линии. Трафик от адресов IPv4LL не может проходить через маршрутизаторы.

Диапазон адресов IPv4LL: 169.254.0.0/16.

Наивысший приоритет для пакетов, которому соответствует значение DSCP 46(101110) согласно RFC3246.

Выше EF только CS6 и CS7.

Название Expedited Forwarding говорит о том, что для передачи пакета будут обеспечены необходимые ресурсы на каждом узле. Пакеты с маркировкой EF обычно попадают с самую приоритетную аппаратную очередь на сетевом оборудовании.

Наиболее низкий класс трафика, которому соответствует значение DSCP 0.

То есть пакеты с этим приоритетом будут обслужены в последнюю очередь.

Название говорит о том, что они будут пытаться сделать всё, что в их силах, чтобы пробиться. Правда это не гарантирует никакого результата.

Наиболее низкий класс трафика, которому соответствует значение DSCP 0.

То есть пакеты с этим приоритетом будут обслужены в последнюю очередь.

Название говорит о том, что они будут пытаться сделать всё, что в их силах, чтобы пробиться. Правда это не гарантирует никакого результата.

Наиболее низкий класс трафика, которому соответствует значение DSCP 0.

То есть пакеты с этим приоритетом будут обслужены в последнюю очередь.

Название говорит о том, что они будут пытаться сделать всё, что в их силах, чтобы пробиться. Правда это не гарантирует никакого результата.

CS6 выдаётся уже только служебным сетевым протоколам, например OSPF и BGP, пакеты которых по-умолчанию передаются с меткой DSCP 48(110000).

Пакеты с маркировкой CS6 наряду с EF, при прочих равных. также обрабатываются в приоритетной очереди на сетевом оборудованиии.

Наивысший приоритет для пакетов, которому соответствует значение DSCP 46(101110) согласно RFC3246.

Выше EF только CS6 и CS7.

Название Expedited Forwarding говорит о том, что для передачи пакета будут обеспечены необходимые ресурсы на каждом узле. Пакеты с маркировкой EF обычно попадают с самую приоритетную аппаратную очередь на сетевом оборудовании.

Наивысший приоритет для пакетов, которому соответствует значение DSCP 46(101110) согласно RFC3246.

Выше EF только CS6 и CS7.

Название Expedited Forwarding говорит о том, что для передачи пакета будут обеспечены необходимые ресурсы на каждом узле. Пакеты с маркировкой EF обычно попадают с самую приоритетную аппаратную очередь на сетевом оборудовании.

Наивысший приоритет для пакетов, которому соответствует значение DSCP 46(101110) согласно RFC3246.

Выше EF только CS6 и CS7.

Название Expedited Forwarding говорит о том, что для передачи пакета будут обеспечены необходимые ресурсы на каждом узле. Пакеты с маркировкой EF обычно попадают с самую приоритетную аппаратную очередь на сетевом оборудовании.

Узел, поддерживающий ECN.

Значение поля ECN, равное 11, означает, что маршрутизатор испытывает перегрузку на интерфейсах и сообщает узлам об этом.

Адрес протокола IPv6. Состоит из 128 бит.

Для удобства чтения и записи адреса представляются в шестнадцатеричном формате: 8 групп по 4 шестнадцатеричных цифры, повторяющиеся нули могут быть заменены на знак "::", но только один раз — в адресе не может дважды встречаться "::".

Стандарт предписывает выдавать сети минимум /64 каждому пользователю.

Поле заголовка IPv6 — аналог поля ToS в заголовке IPv4. Состоит из двух частей — DSCP (6 битов) — для обеспечения QoS, ECN (2 бита) для контроля перегрузки.

Собственно, в формулировке термина вся суть. Аналог поля TTL в IPv4, только с более логичным названием.
Поскольку в заголовке IPv6 нет контрольной суммы, то после уменьшении значения поля Hop Limit, нет нужды её пересчитывать.

Два общающихся узла в IPv6 могут передавать данные в несколько потоков параллельно. Данное поле позволяет маршрутизаторам и конечным узлам различать пакеты разных потоков.

В этом поле заголовка IPv6 указывается размер вложенного блока данных, без учёта самого заголовка IPv6 (в отличие от IPv4, где заголовок учитывается).

Пакет IPv6 содержит фиксированный заголовок длиной 40 байтов и может также иметь расширенные заголовки. Так вот поле Next Header определяет как раз расширенные заголовки. В последнем таком заголовке или если их нет вообще, указывается инкапсулированный протокол (например, TCP или UDP).

В IPv6 маршрутизаторы периодически рассылают свои анонсы, уведомляя станции о своём существовании и о том, какие сетевые настройки они предлагают, могут ли выступать в качестве шлюза по умолчанию.

Один из важнейших протоколов IPv6. Во-первых, он заменяет собой ARP, во-вторых, помогает механизму SLAAC, в-третьих, реализует Router Redirection.

NDP используется совместно с протоколом ICMPv6. А именно ему нужны сообщения RS, RA, NS, NA и Redirect.
Router Redirect работает точно также, как в обычном ICMP — если маршрутизатор получает трафик, но знает, что есть более удачный маршрутизатор в сети, он посылает первоначальному отправителю сообщение Redirect, направляя его на путь истинный.

Интересно то, как NDP реализует свою основную функцию — обнаружение соседей.

Когда узел А хочет отправить данные узлу Б, он знает его IPv6-адрес, и ему необходимо узнать его канальный адрес. NDP на узле А отправляет запрос NS (Neighbor Solicitation) в сеть. В отличие от ARP, такие сообщение не широковещательные, а мультикастовые. Они отправляются на мультикастовый адрес, который вычисляется из IP-адреса узла Б — узла назначения. А сам искомый адрес находится внутри пакета.

При таком подходе запрос обрабатывают только те, кто может оказаться искомым. Все узлы в IPv6-сети всегда слушают мультикастовую группу, соответствующую их адресу.

Когда Б получает запрос NS и видит, что А ищет именно его, Б отправляет в ответ NA (Neighbor Advertisement), в котором несёт свой канальный адрес.

Также узлы могут отправлять NA и просто так, чтобы уведомить других о себе. Это аналог Gratuitous ARP.
RFC 4861.

Один из механизмов IPv6 для автоматической настройки адресов на конечных узлах.

При подключении станция отправляет мультикастовый запрос. Шлюз, получив такой запрос, отвечает специальным сообщением, где указывает префикс для этого клиента.

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

Если домашний маршрутизатор не поддерживает IPv6, а провайдер его предоставляет, данный механизм позволяет передавать IPv6 трафик прозрачно на компьютер. То есть в этом случае маршрутизатор выступает в качестве моста.

Поскольку IPv6 принципиально отличается от IPv4, переход не может быть совершён разом в один день по всей планете. Разные адреса, разные заголовки, разные принципы работы. Часть оборудования провайдеров и вовсе не поддерживается IPv6.

По этой причине IETF и другие наплодили целую гору механизмов перехода, но основных концепции три:

• Dual Stack — на сети работает сразу оба протокола.


• Туннелирование — пакеты IPv6 помещаются внутрь IPv4 или наоборот.


• Трансляция — адреса IPv6 транслируются в IPv4 и наоборот.

При внедрении IPv6 любыми способами стараются избежать классического statefull NAT, поэтому бОльшая часть подходов является stateless.

Выделяют следующие этапы перехода:

1. Чистый IPv4


2. Океан IPv4 с маленькими островками IPv6


3. Океан IPv6 с маленькими островками IPv4


4. Чистый IPv6

Наивысший приоритет для пакетов, которому соответствует значение DSCP 46(101110) согласно RFC3246.

Выше EF только CS6 и CS7.

Название Expedited Forwarding говорит о том, что для передачи пакета будут обеспечены необходимые ресурсы на каждом узле. Пакеты с маркировкой EF обычно попадают с самую приоритетную аппаратную очередь на сетевом оборудовании.

Наиболее низкий класс трафика, которому соответствует значение DSCP 0.

То есть пакеты с этим приоритетом будут обслужены в последнюю очередь.

Название говорит о том, что они будут пытаться сделать всё, что в их силах, чтобы пробиться. Правда это не гарантирует никакого результата.

Наиболее низкий класс трафика, которому соответствует значение DSCP 0.

То есть пакеты с этим приоритетом будут обслужены в последнюю очередь.

Название говорит о том, что они будут пытаться сделать всё, что в их силах, чтобы пробиться. Правда это не гарантирует никакого результата.

Наиболее низкий класс трафика, которому соответствует значение DSCP 0.

То есть пакеты с этим приоритетом будут обслужены в последнюю очередь.

Название говорит о том, что они будут пытаться сделать всё, что в их силах, чтобы пробиться. Правда это не гарантирует никакого результата.

CS6 выдаётся уже только служебным сетевым протоколам, например OSPF и BGP, пакеты которых по-умолчанию передаются с меткой DSCP 48(110000).

Пакеты с маркировкой CS6 наряду с EF, при прочих равных. также обрабатываются в приоритетной очереди на сетевом оборудованиии.

Наивысший приоритет для пакетов, которому соответствует значение DSCP 46(101110) согласно RFC3246.

Выше EF только CS6 и CS7.

Название Expedited Forwarding говорит о том, что для передачи пакета будут обеспечены необходимые ресурсы на каждом узле. Пакеты с маркировкой EF обычно попадают с самую приоритетную аппаратную очередь на сетевом оборудовании.

Наивысший приоритет для пакетов, которому соответствует значение DSCP 46(101110) согласно RFC3246.

Выше EF только CS6 и CS7.

Название Expedited Forwarding говорит о том, что для передачи пакета будут обеспечены необходимые ресурсы на каждом узле. Пакеты с маркировкой EF обычно попадают с самую приоритетную аппаратную очередь на сетевом оборудовании.

Наивысший приоритет для пакетов, которому соответствует значение DSCP 46(101110) согласно RFC3246.

Выше EF только CS6 и CS7.

Название Expedited Forwarding говорит о том, что для передачи пакета будут обеспечены необходимые ресурсы на каждом узле. Пакеты с маркировкой EF обычно попадают с самую приоритетную аппаратную очередь на сетевом оборудовании.

Это тип NAT'а, когда разрешены входящие соединения от любых хостов во внешней сети. При этом паре внутренний адрес — внутренний порт статически ставится в соответствие пара внешний адрес — внешний порт. Такая связка закреплена на долгий период времени. Full Cone NAT часто называют статическим (Static NAT).

• Внутренний узел всегда выходит во внешнюю сеть под одним адресом.


• Любой узел в глобальной сети может установить соединение с любым портом внутреннего узла.

Примером использования является публично-доступный WEB-сервер — кто угодно может к нему подключиться.

Похож на Full Cone, но с ограничениями на адрес. Так же паре внутренний адрес — внутренний порт статически ставится в соответствие пара внешний адрес — внешний порт. Такая связка закреплена на долгий период времени.

• Внутренний узел всегда выходит во внешнюю сеть под одним адресом.


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

Например, если узел (А за NAT) установил сессию с внешним узлом Б, то Б может сам отправлять данные с любого порта на А, главное, что внешний адрес и внешний порт А остаются прежним.

То же, что Address-restricted Cone NAT, но узел в глобальной сети теперь может отправлять данные только на тот внешний адрес и тот внешний порт, с которых установил соединение внутренний узел, и только с того адреса и с того порта, на которые оно было установлено.

То есть если узел А (за NAT) установил сессию с определённым портом внешнего узла Б на , то Б может посылать данные на А только с того же внешнего адреса и того же внешнего порта на те же адрес и порт.

Самый простой тип. Паре внутренний адрес — внутренний порт каждый раз выделяется случайная пара внешний адрес — внешний порт. Никакой однозначности нет. Соответственно инициировать сессию извне нельзя вообще никаким образом.

Это «обычный» NAT, использующийся для предоставления клиентам доступа в Интернет.

Некоторые протоколы (VoIP, например) работают поверх UDP и, если оба узла находятся за NAT, что не редкость, установить сессию не удастся — узлы не знают, на какие адреса отсылать данные.

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

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


Ранее расшифровывалось, как Simple Traversal of UDP through NATs.

RFC5389

NAT нарушает End-to-End связность между узлами — многие протоколы не могут преодолеть его напрямую. Самая сложная ситуация, когда принимающий и передающий узлы оба находятся за NAT. TURN — один из способов решения такой проблемы и является расширением STUN.

Где-то в Интернете располагается специальный TURN-сервер с известным публичным адресом, и узлы устанавливают сессии именно с ним. То есть TURN-сервер является посредником, и весь трафик проходит через него.

Когда два узла желают обмениваться данными по UDP, но оба находятся за NAT'ом, NAT становится препятствием, поскольку узлы не могут установить связь. Существует много способов обхода NAT, таких как ALG, STUN, TURN. Каждый из них решает эту проблему по-своему и подходит не для всех протоколов. Поэтому в каждом случае необходимо отдельно определять механизм.

ICE самостоятельно выбирает, как устанавливать соединение, перебирая все возможные варианты.
ICE является расширением стандартного механизма offer/answer протокола SDP. Он добавляет в пакет SDP данные обо всех IP-адресах (приватных, публичных, TURN-серверов итд).

Оба узла должны поддерживать ICE.

RFC 5245

Реализация ICE для TCP.

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

RFC 6887

Для того, чтобы проникнуть извне на узел через домашний NAT-маршрутизатор, вообще говоря, нужно настроить вручную проброс портов. Делать это для каждого случая (особенно в случае P2P) неразумно. Но IGD позволяет клиентским устройствам запрашивать проброс портов в автоматическом режиме.

Является альтернативой протоколу UPnP IGD и также служит цели автоматической настройки проброса портов на домашнем NAT-маршрутизаторе. Поддерживается большим количеством протоколов и приложений(Torrent, Nmap, Skype). NAT-PMP — предшественник современного PCP.


RFC 6886

Middlebox — это устройства-помехи между двумя узлами, желающими обмениваться данными — файрволы и NAT-сервера.

В обычной ситуации промежуточное устройство само частично пытается обеспечить работоспособность протоколов. В случае MIDCOM специальный узел, называемый MIDCOM-агент, берёт на себя данные функции и потом говорит Middlebox'у по протоколу MIDCOM о том, что нужно сделать, чтобы клиентские пакеты свободно проходили.

То есть MIDCOM-агент определяет, что нужно приложению, и инструктирует Middlebox (Firewall или NAT-сервер) о необходимой конфигурации.

Существует специальный MIDCOM PDP (Policy Decision Point). Он является репозитарием для политик и сообщает заинтересованным, можно ли данному приложению давать доступ.


RFC 3303

Протокол, осуществляющий проксирование трафика. Если не получается установить связь напрямую к удалённому узлу, например, через NAT или файрвол, связь устанавливается до специального проксирующего SOCKS сервера, а этот сервер уже подключается к удалённому узлу.

Отличие от обычного HTTP Proxy в том, что проксироваться может не только HTTP, но и трафик более низких уровней, например, UDP.
RFC 3089 и RFC 1928.

Данный функционал обеспечивает работу VoIP через NAT, который не поддерживает ALG, например, слабые HGW.

В своей сети провайдер устанавливает специальное устройство, которое может называться SBC и фактически выполняет функции ALG, при этом сама трансляция адресов происходит в другом месте. Это и есть HNT.
HNT возник в тот момент, когда ещё не было других механизмов NAT-traversal, поэтому в данный момент он устарел и его использование не рекомендуется.

HNT может также называться Far-end NAT Traversal.

Метод подключения абонентов, когда каждый из них помещается в свой отдельный VLAN. Таким образом пользователи изолрированы друг от друга на канальном уровне и могут взаимодействовать только на сетевом.
Обычно все эти VLAN стекаются в ядро сети или устройства уровня агрегации.

Обычно для организации VLAN-per-user прибегают к QinQ.

Это расширение для стандарта IEEE 802.1q. Суть в том, что кадр Ethernet здесь несёт больше одного тега VLAN. Обычно два, но может быть и больше. Каждый дополнительный заголовок — это те же полноценные 4 байта.

Одна из причин его появления в нехватке меток VLAN, коих всего 4096. При организации такой услуги, например, как VLAN-per-user, их может оказаться недостаточно.

Устройства, которые не поддерживают QinQ, могут передавать кадр, основываясь только на внешней метке.

Может использоваться в сетях MetroEtnernet, при организации услуг Vlan-per-user и Triple Play.

Иначе называется 802.1ad, IEEE 802.1QinQ, Q-in-Q, Stacked VLANs, Provider Bridging.

Кадр, рассылающийся коммутаторами, предназначенный для выбора Root коммутатора и определения потери линков. Рассылается каждые 2 секунды на MAC назначения 01:80:с2:00:00:00. Содержит 12 полей, из которых сейчас нам интересны только 4 поля Bridge ID (2 поля) и Root ID (2 поля). В поля BID записан идентификатор коммутатора, в начале каждый коммутатор считает себя Root, поэтому записывает в это поле свой ID. Получив BPDU от другого коммутатора сравнивается BID и если он больше собственного, то коммутатор рассылает BPDU с данным ID. А так же обновляет свой Root ID.

В исходном STP — поле, в кадре BPDU, размером 8 байт, содержащее приоритет моста (16 бит) и MAC адрес (48 бит). В MSTP, PVST, PVST+ данное поле также состоит из 8 байт, но содержит три значения: уже знакомые нам Bridge Priority и MAC, и расширенный идентификатор системы (Extended System ID, размером 12 бит) — для определения идентификатора VLAN

"Стандарт 802.1w. Схождение дерева более быстрое, в отличие от оригинального STP. От STP, кроме скорости перестроения дерева отличается типами портов.

Типы портов: Root и Designated нам уже известны по STP, и два новых типа Альтернативный (Alternate) — порт не Root и не Designated, находится в состоянии сбрасывания кадров, но получает BPDU. Резервный (Backup) — порт в состоянии сбрасывания, но получает BPDU".

Одна из вариаций на тему STP. Разработан компанией Cisco. Используется для работы в разных VLAN. Т.е. на каждый VLAN приходиться свой экземпляр RSTP. Можно распределять нагрузку между коммутаторами, например, на порту 2 блокировать VLAN 2, и на нем же разрешать пересылку VLAN 3. Соответственно используются различные Root bridge для различных VLAN. Имеет несколько состояний портов (Alternate — получает BPDU, остальное отбрасывает; Listen — прослушивает порты к Root, отправляет/принимает BPDU, готовится к участию в топологии; Learning — изучает MAC адреса, отправляет/принимает BPDU, готовится к FWD; Forwarding — принимает/отправляет BPDU, кадры данных; Shutdown — порт выключен). Появилась поддержка новых функций, таких как PortFast, BPDUGuard, RootGuard, loop guard, uplink fast, backbone fast, BPDU filter.

Усовершенствованный Cisco протокол PVST+. Более быстрая сходимость, высокая нагрузка на коммутатор. Появились типы каналов point-to-point (full duplex) и shared (half duplex). В состояние пересылки быстро переходят только граничные порты и point-to-point. К граничным портам подключаются только пользовательские устройва, не коммутаторы. Использует тот же формат BPDU что и прошлая версия, за исключением того что поле "версия" содержит значение 2, и флаги используют все 8 бит.

Link-State протокол маршрутизации мультикастового трафика, основанный на OSPF. По сути это стандартный OSPF, в который добавлены новый тип LSA — Group-Membership LSA (Type 6) — и механизмы работы с мультикастовыми группами.

Обратно совместим с OSPF-маршрутизаторами, которые не поддерживают мультикастовую маршрутизацию.


Принцип работы следующий: маршрутизатор, у которого есть получатели (IGMP-клиенты или другие маршрутизаторы) высылает Group-Membership LSA (один для каждой группы), сообщая, что для группы G есть получатели в сети N.

Данный LSA расходится по сети вплоть до источника согласно стандартному механизму OSPF.

Ближайший к источнику маршрутизатор, получив хотя бы один LSA для данной группы, понимает, что пора вещать. Далее с помощью алгоритма SPF рассчитывается кратчайший путь от источника до получателя, определяется нисходящий интерфейс, и в него начинает передаваться мультикастовый трафик.

Каждый следующий маршрутизатор, получив первый мультикастовый пакет для группы, запускает SPF и тоже рассчитывает кратчайший путь от источника до получателя. Если этот путь лежит через этот маршрутизатор, он начинает передавать трафик через нисходящий интерфейс. Если кратчайший путь проходит через другой узел, трафик не передаётся.

Важно понимать, что в отличие от обычного OSPF, в расчёт берётся не только адрес получателя, но и адрес источника, и кратчайший путь рассчитывается не от данного маршрутизатора, а глобально по домену OSPF, ведь вся топология маршрутизатору известна. Этот подход называется Source/Destination Routing.

Построение MDT провоцируется первым полученным мультикастовым пакетом. До данного события ничего не рассчитывается, потому что не известен источник.



MOSPF очень громоздкий протокол и требует много ресурсов, потому что для каждой пары источник-группа и для каждого сегмента, где находятся получатели, SPF запускается отдельно. При большом количестве Group-Membership LSA, рассёт кратчайшего пути может отнимать очень много ресурсов маршрутизатора.

Фактически MOSPF сейчас почти не используется и мало у кого даже есть его поддержка.



RFC 1584.

По сути тот же RIP, только для IPv6. Поддержки IPv4 нет.

RFC 2080.

Клиент сообщает, что хочет получать трафик только от тех источников, которые он указал.

Клиент сообщает, что не хочет получать трафик от тех источников, которые он указал.

Отправляется маршрутизатором, чтобы узнать, в каких группах в данный момент есть клиенты, подключенные к данному интерфейсу. Отправляются на адрес 224.0.0.1. Мол, парни, кто какие каналы смотрит?

Иногда называется IGMP GQ.

Такое сообщение позволяет маршрутизатору узнать, есть ли получатели у данной конкретной группы.
Обычно отправляется в ответ на полученное сообщение Leave от клиента, чтобы узнать, есть ли для данной конкретной группы ещё получатели. Если маршрутизатор не получает ответ на такой запрос, он отключает указанную группу на данном интерфейсе.

Иногда называется IGMP GSQ.

То же, что IGMP General Query, но позволяет указать список источников мультикаста.

Появился IGMPv3.
Иногда называется IGMP GSSQ.

Механизм, позволяющий сократить количество IGMP сообщений в сети. При обычной схеме маршрутизатор отправляет периодически IGMP Query в интерфейс, и коммутатор пересылает его всем активным мультикастовым клиентам. Те в свою очередь должны выслать в ответ IGMP Report. Для подавления таких веерных рассылок, коммутатор может проксировать IGMP-пакеты, отсылая, например, один единственный IGMP Report маршрутизатору сразу после IGMP Query, вместо того, чтобы рассылать его клиентам.

То есть коммутатор для маршрутизатора становится единственным клиентом мультикаста, а для узлов-клиентов маршрутизатором.

Если в пределах одного коммутатора есть несколько VLAN, пользователи которых должны получать один и тот же мультикастовый трафик, то от маршрутизатора к коммутатору пойдут несколько копий одного трафика в разных пользовательских VLAN. MVR позволяет избежать этого, мультикастовый трафик передаётся от маршрутизатора только в мультикастовом VLAN'е, а на коммутаторе копируется во все пользовательские. Тем самым снимается нагрузка с вышестоящего маршрутизатора, и меньше утилизируется линия.

Специальное сообщение PIM DM, позволяющее снова присоединиться к дереву, которое было "отрезано" до этого.

То есть сначала маршрутизатор не хотел получать трафик данной группы, который начало вещать вышестоящее устройство, и отправил Prune. После этого на нём появился клиент, а трафика нет.

В PIM DM нет сообщения Join, которое явно позволило бы запросить дерево, но существует Graft. Именно он и позволяет перезапросить подключение к дереву.

Применимо только к протоколу PIM DM.

PIM-SM-маршрутизатор, обычно занимающий центральное положение в сети, функцией которого является слежение в реальном времени за доступными в сети мультикаст-группами, их источниками и подписчиками. Используется как точка сбора и хранения информации, а так же как "координатор" в процессе установления деревьев передачи мультикаст-потоков (MDT).
Является

• точкой отсчёта (или корнем) для дерева RPT в сторону FHR (источника);


• точкой назначения дерева RPT со стороны получателей (LHR);


• точкой объединения этих двух деревьев.

Остальные PIM-SM-маршрутизаторы сети сообщают RP

• о замеченных источниках мультикаста (S, G) в своих подключенных сетях (с помощью unicast-сообщений PIM Register).


• об обнаруженных подписчиках на мультикаст-группы (*, G) в своих подключенных сетях (с помощью сообщений PIM Join).

Без RP:

• источники мультикаста негде зарегистрировать.


• некуда слать PIM Join, поэтому непонятно, как LHR получить информацию о местонахождении источника запрошенной группы и построить мультикаст дерево от него к себе.

После

• установления деревьев RPT LHR<->RP и RP<->FRH;


• передачи по ним первых мультикаст-пакетов на LHR;


• успешного переключения потока мультикаста на дерево оптимального маршрута от источника к получателям (SPT от источника);

RP обычно уходит с пути трафика и перестаёт участвовать в его передаче.

Все маршрутизаторы в сети должны быть согласны по поводу адресов RP и списков групп, которые те обслуживают.
Адрес RP может быть настроен статически на всех PIM-SM-маршрутизаторах, либо изучаться с помощью протокола Auto-RP (Cisco) или BSR.

MDT с корнем в некой единой точке, отличной от источника. Общее название.
Однако обычно используется как синоним RPT — Shared Tree с корнем в RP.

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

RPT — это MDT с корнем в RP — по сути Shared Tree. Применимо только к PIM SM, поскольку в PIM DM нет понятия RP.

После того, как RP изучил источник и местоположение клиентов, он строит дерево, которое и является RPT.

Трафик от источника к RP идёт напрямую, а от RP к клиентам по RPT.

Процесс переключения с дерева RPT на SPT. После того, как PIM SM установил RPT, весь мультикастовый трафик конкретной группы сначала отправляется на RP, куда бы он на самом деле ни был предназначен. Этот путь не всегда оптимальный и в случае большого объёма мультикастового трафика, это может привести к повышенной нагрузке на RP.

Поэтому при достижении определённого порога трафика происходит переключение с RPT на SPT. Тем самым мультикастовый трафик отправляется оптимальным путём и снимается нагрузка с RP.


Переключение может инициироваться RP или Receiver DR.

На практике, обычно SPT Switchover происходит сразу же после получения первого мультикастового пакета.

Используется в целях увеличения надёжности и балансировки нагрузки на RP.

В сети настраиваются несколько маршрутизаторов в качестве RP. На них назначается одинаковый IP-адрес с маской /32 на интерфейс Loopback, и вместе они будут выполнять одну функцию.

В качестве активной для всех получателей и источников будет выбираться ближайшая RP.

В случае выхода из строя одной RP, её работу берёт на себя другая.

Поскольку разные RP могут обслуживать разные группы и Источники, все они должны быть связаны. Для этого используются протоколы MSDP или собственно PIM.

Самый простой способ определения RP — настройка его адреса вручную на каждом узле для каждой RP.

Неплохо подходит для небольших сетей. Но с помощью статической RP нельзя обеспечить надёжность, гибкость и масштабируемость.

Статическая RP может быть настроена вместе с динамическими протоколами (например, BSR). В этом случае преимущество будет у динамических RP.

В IPv6 существует альтернатива Static RP — Embedded RP. В этом случае адрес RP встраивается в адрес мультикастовой группы.

Такие адреса начинаются с ff700::/12.

То есть любой маршрутизатор, зная адрес группы, может вычислить адрес RP.

Не поддерживается несколько RP, BIDIR PIM. Есть вероятность того, что RP станет слабый маршрутизатор, которому придётся обрабатывать большой объём информации.

RFC 3956.

Source DR-маршрутизатор, получив впервые мультикастовый трафик от Источника, инкапсулирует его в сообщение Register и юникастом отправляет прямиком на RP.

Когда RP получает Register — он создаёт запись (S, G) и отправляет Source Specific Join с запросом (S,G) в сторону Источника, чтобы построить SPT от Источника до RP.

Применимо только к PIM SM.

После получения PIM Register RP инициирует построение SPT от Источника до RP, отправляя Join с (S, G) в сторону источника.

После того, как дерево построено, RP начинает получать две копии мультикастового трафика — одна, инкапсулированная в юникастовый пакет, вторая — чистый мультикаст.

Как только это произошло, RP посылает сообщение Register-Stop в сторону источника.

Когда DR получает Register-Stop, он прекращает посылать инкапсулированный трафик, но продолжает слать чистый мультикаст.

Применимо только к PIM SM.

Тип сообщения PIM Join, в котором запрашивается (S,G), то есть трафик для группы G, который передаётся Источником S.
Такие сообщения рассылаются для построения дерева SPT при, например, SPT Switchover или при использовании SSM.

Тип сообщения PIM Prune, в котором указывается (S,G), то есть трафик для группы G, который передаётся Источником S.

Пример использования: IGMPv3 запрашивает трафик для группы G, который передаётся любым Источником, кроме определённых. Тогда DR может отправить Join (*, G) и параллельно Prune (S,G,rpt). То есть "хочу подключиться к группе G, но не передавайте мне трафик от Источника S"

В BIDIR PIM RP не несёт какую-то специфическую функцию, как в обычном PIM SM. Это просто некое символическое место, куда стремится трафик от источников. Поэтому адрес RP на самом деле не обязательно должен быть настроен на каком-то устройстве. Например, это может быть произвольный адрес подсети. Такая RP называется фантомной, потому что точка притяжения есть, а как такового устройства нет.

Специальное понятие BIDIR-PIM, заменившее собой некоторые механизмы PIM SM, такие как RPF, Assert, DR.

DF выбирается для каждой RP, в каждом сетевом сегменте, включая и широковещательные и P2P.

Идея в том, что в каждом случае известно, кто может передавать трафик, а кто нет, это позволяет избежать и петель и дублирования трафика.

Для выбора DF каждый PIM-маршрутизатор сегмента в специальных сообщениях BIDIR-PIM анонсирует своим соседям свою метрику маршрута до RP. У кого метрика лучше, тот и становится DF.

Сообщений протокола MSDP. Когда к одной из RP подключается новый источник, RP отправляет сообщение SA своим MSDP-соседям, которое содержит:

• Адрес Источника


• Адрес мультикастовой группы


• Адрес RP

Сообщение протокола MSDP. Рассылается, как и сообщения Keepalive других протоколов, периодически для уведомления соседей, что всё в порядке, если не было других MSDP-сообщений.

Рекомендованное значение 60 с.

Объект сообщения RSVP-Path. Несёт в себе список узлов, через которые которые должен в итоге пройти LSP.

Обычно ERO формируется с помощью алгоритма CSPF, который рассчитывает лучший путь с учётом ограничений, накладываемых TE-туннелем и доступных сетевых ресурсов.

Каждый узел, через который проходит сообщение Path, удаляет себя из ERO.

Данный объект сообщает маршрутизатору LSR, получившему сообщение Path, что нужно выделить метку для данного FEC.

Одно из сообщений RSVP. Передаётся от Ingress LSR к Egress LSR. Его задача — указать промежуточным LSR, какие ресурсы нужно выделить потоку.
Если свободные ресурсы есть, сообщение Path передаётся дальше, если нет, то на Ingress LSR отсылается сообщение Path-error.

Обычно Path путешествует по сети в соответствии со списком ERO — каждый следующий узел заранее определён.

А ещё это запрос метки — в Path есть специальный объект — Label Request — он сообщает LSR, что нужно выделить метку для данного FEC.

Одно из сообщений RSVP. Передаётся от Ingress LSR к Egress LSR. Его задача — указать промежуточным LSR, какие ресурсы нужно выделить потоку.
Если свободные ресурсы есть, сообщение Path передаётся дальше, если нет, то на Ingress LSR отсылается сообщение Path-error.

Обычно Path путешествует по сети в соответствии со списком ERO — каждый следующий узел заранее определён.

А ещё это запрос метки — в Path есть специальный объект — Label Request — он сообщает LSR, что нужно выделить метку для данного FEC.

Вариация протокола LDP для обмена метками между удалёнными узлами.
Обычный LDP сначала ищет соседей с помощью UDP-дейтаграм и только потом устанавливает TCP-сессию для обмена метками, а tLDP сразу же приступает к TCP, потому что его соседи уже определены конфигурацией.
tLDP, как правило, используется для обмена метками VPN.

Например, один узел сообщает другому, что если сервисная метка в пакете будет Х, значит он принадлежит VPN Y.

Подразделение IAB, которое проводит долгосрочные исследовательские программы, связанные с вопросами развития архитектуры сети Интернет и используемыми в ней протоколах.

То есть, если IETF ориентирован на настоящее, пытаясь максимально подробно разобрать существующие технологии, IRTF ориентирован на развитие, на будущее.

Региональный Интернет-Регистратор — региональная организация, занимающаяся распределением блоков IP-адресов, номеров Автономных Систем и доменных имён.

Интерент-ресурсы RIR получает от IANA, но статус RIR присваивается ICANN.

Обычно RIR имеет контракты с более мелкими организациями, которые в свою очередь также занимаются распределением ресурсов на локальной территории.

Организует интерфейсы для подключения конечных устройств к аппаратуре ВЧ-связи.

Модемы предназначены для последовательной синхронной передачи данных по выделенным трактам аналоговых систем передачи (АСП), включая тракты, организованные по ЛЭП.