Глава 2. Multicast, IGMP: различия между версиями
м (→Routing tables) |
м (→Routing tables) |
||
Строка 82: | Строка 82: | ||
MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2. | MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2. | ||
Чтобы ISIS стал заполнять inet.2 - нужно включить | |||
set protocols isis topologies ipv4-multicast | |||
Все остальные протоколы для заполнения таблицы должны заниматься копированием в inet.2 маршрутов с помощью '''RIB-groups'''. | Все остальные протоколы для заполнения таблицы должны заниматься копированием в inet.2 маршрутов с помощью '''RIB-groups'''. | ||
Версия 13:50, 8 июля 2018
Общее
Мультикаст = поток UDP на определенные адреса.
Адресация
- 224/24 - local network control block
- 224.2.0.0/16 - SDP/SAP, адреса, использующиеся для передачи multicast session.
- 232/8 - под SSM
- 233/8 - используется под глобальную мультикаст-адресацию (GLOP) || 233.[first byte of AS].[second byte of AS].1-255 || только для 16-ти битных AS
- 234/8 - unicast-prefix-based IPv4
- 239/8 - administratively scoped block || это адреса, которые могут быть использованы в разных частях сети. Тоже самое, что и private IP.
Multicast IP => multicast mac
Если не заморачиваться почему так, то правило перевода простое:
Конвертируем последние 23 бита IP в десятичную систему счисления.
- 224.10.8.5: 0001010.00001000.00000101 => 0a.08.05
Прибавляем к "01-00-5e" переведенное значение.
- 01-00-5e + 0a-08-05 = 01-00-5e-0a-08-05
Проблема в том, что для разных мультикаст-групп (адресов) - мак-адреса будут пересекаться, т.к. не учитываются первые биты ip-адреса.
Multicast forwarding
- unicast forwarding основан на dest ip.
- multicast forwarding основан на source ip.
RPF-check для источника: сравнивается с какого интерфейса фактически пришел мультикаст пакет с тем, откуда по unicast table пакет должен приходить (источник или RP).
Если одинаков - rpf done, разные - fail. То, что прошло RPF-check хранится в inet.1.
show multicast rpf <group ip>
Routing tables
inet.0 - дефолтная таблица для проведения RPF-check [можно использовать inet.2, которая для этого и предназначена]ю Если unicast и multicast топологии одинаковые, то inet.0 и inet.2 будут одинаковы.
inet.1 - записываются результаты RPF-check, исходя из этой таблицы производится передача трафика.
>show route table inet.1 inet.1: 238 destinations, 238 routes (238 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 224.0.0.0/4 *[Multicast/180] 74w2d 13:10:11 MultiResolve 224.0.0.0/24 *[Multicast/180] 74w2d 13:10:11 MultiDiscard 232.0.0.0/8 *[Multicast/180] 74w2d 13:10:11 MultiResolve 232.192.1.1,10.200.86.1/32*[PIM/105] 6w0d 08:32:53 Multicast (IPv4) Composite 232.192.1.1,10.200.86.2/32*[PIM/105] 8w3d 15:25:48 Multicast (IPv4) Composite 232.192.1.2,10.200.86.1/32*[PIM/105] 6w0d 08:32:52 Multicast (IPv4) Composite 232.192.1.2,10.200.86.2/32*[PIM/105] 8w3d 15:25:52 Multicast (IPv4) Composite 232.192.1.4,10.200.86.1/32*[PIM/105] 23:11:56 Multicast (IPv4) Composite ...
Detailed
232.192.1.1.10.200.86.1/64 (1 entry, 1 announced) *PIM Preference: 105 Next hop type: Multicast (IPv4) Composite, Next hop index: 1048796 Address: 0xa4edf30 Next-hop reference count: 28 State: <Active Int Ext AckRequest> Local AS: 100 Age: 6w0d 8:35:30 Validation State: unverified Task: PIM.master Announcement bits (1): 0-KRT AS path: I AS path: Recorded
inet.2 - если для multicast на сети должна быть использована другая топология, то используем эту таблицу. inet.2 в таком случае будет использоваться для RPF-check.
MP-BGP и multitopology IS-IS могут напрямую заполнять маршрутной информацией inet.2.
Чтобы ISIS стал заполнять inet.2 - нужно включить
set protocols isis topologies ipv4-multicast
Все остальные протоколы для заполнения таблицы должны заниматься копированием в inet.2 маршрутов с помощью RIB-groups.
IMPORT-RIB: для протокола PIM import-rib копирует маршруты из протокола в указанную таблицу. То есть указываем только одну таблицу. Указанная таблица будет использоваться для RPF.
Для остальных протоколов первая таблица <> - откуда копируются маршруты, вторая <to-inet2> - куда копируются.
set routing-options rib-groups mcast-table import-rib inet.2 set protocols pim rib-group inet mcast-table
set routing-options rib-groups import-rib to-inet2 [inet.0 inet.2] set routing-options rib-groups import-policy static *по желанию/необходимости set protocols ospf rib-groups to-inet.2 set routing-options interface-routes rib-group inet to-inet2
В обычном понимании: если задаём export-ribs, то при этом указывается только одна таблица, куда будут скопированы маршруты. Но для PIM не работает rib-export.
IGMP
Internet group management protocol
IGMP не протокол маршрутизации. Работает между получателями и роутером, с которого отдается мультикаст в сегменте. Он просто передает информацию роутеру о заинтересованных получателях и получателях, которые хотят покинуть группу.
Для IPv6 используется точно такой же по принципу работы протокол MLD.
Сообщения
Report/Join message: отправляет хост, когда хочет подписаться на какую-то группу. DA = group address. После того как хост подписался на группу, он должен отвечать на query message от роутера. TTL = 1, т.к. сообщение должно долететь только до ближайшего маршрутизатора.
General query: роутер шлет general query на 224.0.0.1 всем хотсам (роутер при этом называется query-router (опрашивающий)). Хосты в ответ присылают группы, на которые они еще хотят быть подписаны. TTL тоже = 1.
Чтобы не дублировались ответы с одной группой от разных хостов, хосты шлют ответы с разным временным интервалом. Если хост видит, что о его группе сообщил другой хост, то он не будет отправлять ответ роутеру. Роутер итак сохранит интерфейс как downstream для данной группы.
Если в домене несколько query-роутеров, то в качестве активного будет выбран с наименьшим ip.
Leave message:
- IGMP2: Хост отправляет leave message для конкретной группы на общий адрес 224.0.0.2.
- IGMP1: Хост просто перестает отвечать на query от роутра. Если больше нет подписчиков на группу, роутер по истечению какого-то интервала перестает слать трафик в интерфейс.
Group-specific query:
- IGMP2: Когда роутер получил leave от хоста, он отправляет general-specific query на адрес этой группы, чтобы понять есть ли еще заинтересованные получатели.
Разные версии протокола
- IGMP v 1
- Чтобы получить трафик от конкретной группы, хост отправляет роутеру report message.
- Для отключения от группы хост просто перестает отвечать роутеру на query.
- Таймаут, после которого роутер перестает вещать группу в downstream interface = 260.
(robustness count * igmp_query interval) + (1*IGMP response interval) = (2*125)+(1*10) = 260
- Для выбора query-router нет отдельного механизма. Выбирать должен routing protocol.
- IGMP v 2
- Чтобы подписаться, хосты шлют report-message.
- Чтобы отписаться, хосты шлют leave-group message.
- Чтобы проверить наличие подписчиков, роутер шлет group-specific message.
- Таймаут, после которого роутер перестает вещать: нет ответа от хостов в течение 2 сек (дефолт).
robusness count * IGMP last member query interval = 2*1 = 2
- Query-router - с наименьшим ip. Если падает query-router, его роль выполняет non-query router.
- IGMP v 3
Все улучшения для v 2.
Используется для SSM, поэтому report message (на адрес 224.0.0.22 - all IGMPv3) может содержать source information.
L2 switches
Свитчи обрабатывают мультикаст трафик как бродкаст, по умолчанию, т.е. шлет трафик во все порты.
IGMP-snooping позволяет выделить мультикаст трафик. С помощью IGMP сообщений, свитч может понять где получатели и слать трафик только к ним. Делит порты на multicast-router interface (откуда приходят query, либо заданы статически), host-side interface (все остальные).
Передача трафика:
- Весь трафик направлен в multicast-router интерфейс.
- Если через IGMP-snooping свитч узнает о портах, за которыми сидят получатели, то шлет трафик туда.
- 224/8 сеть бродкастом идет во все порты, кроме входящего.
Стандартное расширение IGMP позволяет только обрабатывать query от роутера и сообщения от получателей. Не генерирует IGMP сообщения.
IGMP snooping proxy ведет себя как роутер для получателей (генерирует query), работает как получатели для роутера (генерирует leave и join сообщения).
Тем самым уменьшается кол-во report-сообщений для роутера.
Configuration
На интерфейсах с активным pim, автоматически включается IGMPv2.
Можно менять дефолтные значения всяких таймеров.
Можно статически подписываться на какую-то группу (полезно для тестов). При этом интерфейс просто добавляется в outgoing list.
По умолчанию на Juniper используется IGMPv2, но при необходимости можно задать на интерфейсах нужную версию.
set protocols pim interface ge-0/0/0.910 set protocols igmp interface ge-0/0/0.910 version 1 set protocols igmp interface ge-0/0/0.910 static group 239.100.1.1
Troubleshoting
sh igmp interfaces sh igmp groups sh igmp statistics traceoptions