4.-dr-assert-forwarder.md
1 # DR, Assert, Forwarder 2 3 Ещё несколько важных моментов при рассмотрении PIM. 4 5 **DR — Designated Router**. 6 Это выделенный маршрутизатор, который ответственен за отправку служебных пакетов на RP. 7 **Source DR** — отвечает за принятие мультикастовых пакетов непосредственно от источника и его регистрацию на RP. 8 Вот пример топологии: 9 10  11 12 Здесь ни к чему, чтобы оба маршрутизатора передавали трафик на RP, пусть они резервируют друг друга, но ответственный должен быть только один. 13 Поскольку оба маршрутизатора подключены в одну широковещательную сеть, они получают друг от друга PIM-Hello. На основе него они и делают свой выбор. 14 PIM Hello несёт значение приоритета данного маршрутизатора на данном интерфейсе. 15 16  17 18 Чем больше значение, тем выше приоритет. Если они одинаковы, то выбирается узел с **наибольшим IP-адресом** \(тоже из сообщения Hello\). 19 20  21 22 Если другой маршрутизатор \(не DR\) в течение Holdtime \(по умолчанию 105 с\) не получал Hello от соседа, он автоматически берёт на себя роль DR. 23 24 По сути Source DR — это [**FHR — First Hop Router**](http://lookmeup.linkmeup.ru/#term322). 25 26 **Receiver DR** — то же, что Source DR, только для получателей мультикастового трафика — [**LHR \(Last Hop Router\)**](http://lookmeup.linkmeup.ru/#term323). 27 Пример топологии: 28 29  30 31 Receiver DR ответственен за отправку на RP PIM Join. В вышеприведённой топологии, если оба маршрутизатора отправят Join, то оба будут получать мультикастовый трафик, но в этом нет необходимости. Только DR отправляет Join. Второй просто мониторит доступность DR. 32 Поскольку DR отправляет Join, то он же и будет вещать трафик в LAN. Но тут возникает закономерный вопрос — а что, если PIM DR'ом стал один, а IGMP Querier'ом другой? А ситуация-то вполне возможна, ведь для Querier чем меньше IP, тем лучше, а для DR, наоборот. 33 В этом случае DR'ом выбирается тот маршрутизатор, который уже является Querier и такая проблема не возникает. 34 35  36 37 Правила выбора Receiver DR точно такие же, как и Source DR. 38 39 **Assert и PIM Forwarder** 40 Проблема двух одновременно передающих маршрутизаторов может возникнуть и в середине сети, где нет ни конечных клиентов, ни источников — только маршрутизаторы. 41 Очень остро этот вопрос стоял в PIM DM, где это была совершенно рядовая ситуация из-за механизма Flood and Prune. 42 Но и в PIM SM она не исключена. 43 Рассмотрим такую сеть: 44 45  46 47 Здесь три маршрутизатора находятся в одном сегменте сети и, соответственно, являются соседями по PIM. R1 выступает в роли RP. 48 R4 отправляет PIM Join в сторону RP. Поскольку этот пакет мультикастовый он попадает и на R2 и на R3, и оба они обработав его, добавляют нисходящий интерфейс в OIL. 49 Тут бы должен сработать механизм выбора DR, но и на R2 и на R3 есть другие клиенты этой группы, и обоим маршрутизаторам так или иначе придётся отправлять PIM Join. 50 Когда мультикастовый трафик приходит от источника на R2 и R3, в сегмент он передаётся обоими маршрутизаторами и задваивается там. PIM не пытается предотвратить такую ситуацию — тут он действует по факту свершившегося преступления — как только в свой нисходящий интерфейс для определённой группы \(из списка OIL\) маршрутизатор получает мультикастовый трафик этой самой группы, он понимает: что-то не так — другой отправитель уже есть в этом сегменте. 51 52  53 54 Тогда маршрутизатор отправляет специальное сообщение **PIM Assert**. 55 Такое сообщение помогает выбрать **PIM Forwarder** — тот маршрутизатор, который вправе вещать в данном сегменте. 56 57  58 59 Не надо его путать с PIM DR. Во-первых, PIM DR отвечает за отправку **сообщений PIM Join и Prune**, а PIM Forwarder — за отправку **трафика**. Второе отличие — PIM DR выбирается всегда и в любых сетях при установлении соседства, А PIM Forwrder только при необходимости — когда получен мультикастовый трафик с интерфейса из списка OIL.