проблема с маршрутизацией групп из диапазона Well-known

[YurkivVA]

Здравствуйте,

Столкнулись с проблемой маршрутизации до источников мультикаста, например:

ip route 10.121.94.24 255.255.255.248 vlan 10 name "PIM_sintera3"

Маршрут вида - ip route <source ip address> <mask> vlan <vlan id source>

при включенном ip igmp и PIM-dense на vlan клиентов и влан источников:

vlan 10
name "source"
tagged E23,Trk10-Trk11
ip address 10.10.1.11 255.255.255.0
ip igmp
ip pim-dense
ip-addr any
exit
exit

vlan 11
name "client"
tagged E23
untagged G23
ip address 192.168.11.1 255.255.255.0
ip igmp
ip pim-dense
ip-addr any
exit
exit

Для информации:

HP-Switch-5412Rzl2# sho ip mroute 239.0.0.30 10.121.94.26

IP Multicast Route Entry

Group Address : 239.0.0.30
Source Address : 10.121.94.26
Neighbor : 10.121.94.26
VLAN : 10
Up Time (sec) : 1227635
Expire Time (sec) : 282

Multicast Routing Protocol : PIM-DM
Unicast Routing Protocol : static

Metric : 1
Metric Pref : 1
Assert Timer : 0
RP tree : No

Downstream Interfaces

VLAN State Up Time (sec) Expire Time (sec)
---- ---------- ------------------ ------------------
11 pruned 1227635 0
354 pruned 1227635 0

Маршрутизация не отрабатывает если группы мультикаста попадает в следующие диапазоны (из мануала HPE_c04943222_HPE ArubaOS-Switch Multicast and Routing Guide YA_YB.16.01):

of 224.0.0.x to 239.0.0.x

of 224.128.0.x to 239.128.0.x

x is any value from 0 to 255

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

Почему? Это нормальная политика HPe или баг конкретной прошивки?

Если меняем группу например с 239.0.0.30 на 239.0.1.30 маршрутизация работает, если же попадаем в диапазон из таблицы выше то маршрутизация не работает.

[Ivan_B]

Здравствуйте, @YurkivVA !

Да, это нормальное поведение ProCurve (ArubaOS) серии. Не скажу за все продукты, но я встречался с данным поведением у некоторых коммутаторов этой серии. Почему не маршрутизируются 224.0.0.0/24 и так ясно, это зарезервированный диапазон для link-local трафика. С 239.0.0.0/24 и 239.128.0.0/24 все сложнее. С одной стороны понятно, почему не отрабатывает IGMP snooping - MAC адреса этих диапазонов это известные 0100-5E00-00xx, совпадающие с адресами группы 224.0.0.0/24 но с другой стороны маршрутизация это все же другое, тут mac адрес роли не играет и у многих вендоров она нормально отрабатывает в 239.0.0.0/24 диапазоне. Видимо для того, чтобы клиенты не использовали данные диапазоны для коммутации было принято решение исключить их также из маршрутизации. Как я уже упоминал данное поведение мне встречалось и на вопрос "почему так?" ответ был один - by design.

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

[YurkivVA]

Кейс пытались открыть, ответ был:

"

Добрый день, Вячеслав.

Ваш запрос не является break&fix и относительно конфигураций, пожалуйста, зайдите на наш официальный форум https://community.hpe.com

Ответ на многие многие вопросы так же можете найти в документации оборудования по поиску модели компонента или оборудования на странице Hewlett Packard Enterprise Support Center: https://support.hpe.com

Надеемся информация будет Вам полезна.

Желаем Вам приятного дня.

C уважением,
Вероника Тангер
Support Agent

Customer Solution Center
HPE Pointnext Services

support_desk@hpe.com
Technical Support Phone Numbers

Sofia, Bulgaria
hpe.com/pointnext"

[YurkivVA]

ладно бы только 224.0.0.0/24 и 239.0.0.0/24, так там же 32 диапазона, т.е. еще 225.0.0.0/24, 226.0.0.0/24, 227.0.0.0/24, 228.0.0.0/24 и т.д. 16 штук и так же с 224.128.0.0/24, 225.128.0.0/24, 2246128.0.0/24....

32 *255 = 8160 хостов которые не фильтруются IGMP filtering и не маршрутизируются о.0 как так то)

[Ivan_B · Accepted solution]

Ну почему диапазонов 32 как раз понятно - когда IPv4 группа мапится к мультикаст MAC адресу, используются не все биты, а только 23. поэтому реально соотношение IPv4 мультикаст адресов к мультикаст MAC адресам - 32:1. Т.е. у 32-х групп мультикаст МАК совпадает.

    |-----| Ambiguous bits              | IP Address  | MAC address
----------------------------------------+-------------+------------------
1110 0000 0000 0000 0000 0000 0000 0000 | 224.0.0.0   |01:00:5E:00:00:00
1110 0000 0000 0000 0000 0000 1111 1111 | 224.0.0.255 |01:00:5E:00:00:FF
1110 1111 0000 0000 0000 0000 0000 0000 | 239.0.0.0   |01:00:5E:00:00:00
1110 1111 0000 0000 0000 0000 1111 1111 | 239.0.0.255 |01:00:5E:00:00:FF

MAC адрес формируется так:
Берем префикс 0000 0001 0000 0000 0101 1110 0
и добавляем 23 последних бита из IPv4 адреса, т.е. из таблицы вверху незачеркнутые. Получаем:

0000 0001 0000 0000 0101 1110 0000 0000 0000 0000 0000 0000 для 224.0.0.0
и
0000 0001 0000 0000 0101 1110 0000 0000 0000 0000 0000 0000 для 239.0.0.0

вот так и выводим следующее правило:

The following IPv4 Multicast Group Address ranges MUST NOT be used
   in order to avoid overwhelming the control plane of network devices:

               IPv4 Multicast Unusable Group Addresses  

   224.128.0.0/24    225.0.0.0/24    225.128.0.0/24    226.0.0.0/24
   226.128.0.0/24    227.0.0.0/24    227.128.0.0/24    228.0.0.0/24
   228.128.0.0/24    229.0.0.0/24    229.128.0.0/24    230.0.0.0/24
   230.128.0.0/24    231.0.0.0/24    231.128.0.0/24    232.0.0.0/24
   232.128.0.0/24    233.0.0.0/24    233.128.0.0/24    234.0.0.0/24
   234.128.0.0/24    235.0.0.0/24    235.128.0.0/24    236.0.0.0/24
   236.128.0.0/24    237.0.0.0/24    237.128.0.0/24    238.0.0.0/24
   238.128.0.0/24    239.0.0.0/24    239.128.0.0/24

Уверен что теперь логика понятна - с точки зрения L2 multicast forwarding что 224.0.0.1/24 что 224.128.0.1/24 что 239.0.0.1/24 - все едино, у всех будет один и тот же MAC адрес 01:00:5E:00:00:01

Опять же - это все лишь с точки зрения Л2.  Для Л3 ограничивать 239.0.0.0 это уже спорное решение. Кстати, а вы пробовали 239.128.0.0/24 диапазон? Если догадка верна и вот эти все префиксы исключили из роутинга, тогда и он работать не будет.

[YurkivVA]

логика формирования MAC понятна,

239.128.0.0/24 пробовали тоже на маршрутизируется.