DR, Assert, Forwarder
Ещё несколько важных моментов при рассмотрении PIM.
DR — Designated Router. Это выделенный маршрутизатор, который ответственен за отправку служебных пакетов на RP. Source DR — отвечает за принятие мультикастовых пакетов непосредственно от источника и его регистрацию на RP. Вот пример топологии:
Здесь ни к чему, чтобы оба маршрутизатора передавали трафик на RP, пусть они резервируют друг друга, но ответственный должен быть только один. Поскольку оба маршрутизатора подключены в одну широковещательную сеть, они получают друг от друга PIM-Hello. На основе него они и делают свой выбор. PIM Hello несёт значение приоритета данного маршрутизатора на данном интерфейсе.
Чем больше значение, тем выше приоритет. Если они одинаковы, то выбирается узел с наибольшим IP-адресом (тоже из сообщения Hello).
Если другой маршрутизатор (не DR) в течение Holdtime (по умолчанию 105 с) не получал Hello от соседа, он автоматически берёт на себя роль DR.
По сути Source DR — это FHR — First Hop Router.
Receiver DR — то же, что Source DR, только для получателей мультикастового трафика — LHR (Last Hop Router). Пример топологии:
Receiver DR ответственен за отправку на RP PIM Join. В вышеприведённой топологии, если оба маршрутизатора отправят Join, то оба будут получать мультикастовый трафик, но в этом нет необходимости. Только DR отправляет Join. Второй просто мониторит доступность DR. Поскольку DR отправляет Join, то он же и будет вещать трафик в LAN. Но тут возникает закономерный вопрос — а что, если PIM DR'ом стал один, а IGMP Querier'ом другой? А ситуация-то вполне возможна, ведь для Querier чем меньше IP, тем лучше, а для DR, наоборот. В этом случае DR'ом выбирается тот маршрутизатор, который уже является Querier и такая проблема не возникает.
Правила выбора Receiver DR точно такие же, как и Source DR.
Assert и PIM Forwarder Проблема двух одновременно передающих маршрутизаторов может возникнуть и в середине сети, где нет ни конечных клиентов, ни источников — только маршрутизаторы. Очень остро этот вопрос стоял в PIM DM, где это была совершенно рядовая ситуация из-за механизма Flood and Prune. Но и в PIM SM она не исключена. Рассмотрим такую сеть:
Здесь три маршрутизатора находятся в одном сегменте сети и, соответственно, являются соседями по PIM. R1 выступает в роли RP. R4 отправляет PIM Join в сторону RP. Поскольку этот пакет мультикастовый он попадает и на R2 и на R3, и оба они обработав его, добавляют нисходящий интерфейс в OIL. Тут бы должен сработать механизм выбора DR, но и на R2 и на R3 есть другие клиенты этой группы, и обоим маршрутизаторам так или иначе придётся отправлять PIM Join. Когда мультикастовый трафик приходит от источника на R2 и R3, в сегмент он передаётся обоими маршрутизаторами и задваивается там. PIM не пытается предотвратить такую ситуацию — тут он действует по факту свершившегося преступления — как только в свой нисходящий интерфейс для определённой группы (из списка OIL) маршрутизатор получает мультикастовый трафик этой самой группы, он понимает: что-то не так — другой отправитель уже есть в этом сегменте.
Тогда маршрутизатор отправляет специальное сообщение PIM Assert. Такое сообщение помогает выбрать PIM Forwarder — тот маршрутизатор, который вправе вещать в данном сегменте.
Не надо его путать с PIM DR. Во-первых, PIM DR отвечает за отправку сообщений PIM Join и Prune, а PIM Forwarder — за отправку трафика. Второе отличие — PIM DR выбирается всегда и в любых сетях при установлении соседства, А PIM Forwrder только при необходимости — когда получен мультикастовый трафик с интерфейса из списка OIL.
Last updated
