Проблемы с multicast'ом при включении в сеть Juniper'овского коммутатора.

[evil-man]

Дано:

• Плоская сеть (во влане IPTV) с коммутаторами Cisco 4948 и Cisco 4948E.
  
• В качестве IGMP Querier'а трудится Cisco 3560 (она же и RP). Конфиг могу показать, если нужно.
  
• Несколько коммутаторов Juniper (EX4450 и EX3300).
  
• IGMP снупинг во влане IPTV везде включен.
  
• При включении любого из Juniper-ов в сеть при поднятии линков, он отправляет IGMP Membership Query src=0.0.0.0 dst=224.0.0.1 во все вланы данного линка, в которых включен снупинг. После этого весь мультикаст IPTV устремляется в Juniper продолжает литься некоторое время (несколько минут). После чего всё возвращается в норму.
  

Вопросы:

• Нормально ли это? (Логика подсказывается, что нет).
  
• Как эту проблему побороть?
  

Edited September 10, 2013 by evil-man

[srg555]

покажите show protocols на juniper-е

[evil-man]

покажите show protocols на juniper-е

> show configuration protocols igmp-snooping 
vlan all {
   version 2;
}
vlan vlan0500 {
   interface ae0.0 {
       multicast-router-interface;
   }
}
vlan vlan0501 {
   interface ae0.0 {
       multicast-router-interface;
   }
}

 

Собственно, и всё из настроек мультикаста. Остальное - это ОСПФ и ERPS, но оно на мультикаст никак не влияет. Интерфейс ae0 смотрит в сторону querier'а. Неуказание интерфейса как multicast-router-interface на ситуацию никак не влияет.

[srg555]

у вас идёт join на 224.0.0.1 или всё-таки igmp query v2? Сделайте дамп пакета

[evil-man]

у вас идёт join на 224.0.0.1 или всё-таки igmp query v2? Сделайте дамп пакета

Ох блин, действительно идёт всё-таки igmp query. Дамп выложил здесь.

[srg555]

Как я и думал, там query. В соответствии с документацией http://www.juniper.net/techpubs//en_US/junos/topics/task/configuration/igmp-snooping-ex-series-cli.html#jd0e180 :

 

When an interface comes up, the switch sends an immediate general membership query to all hosts on the interface. By doing so, the switch enables the multicast routers to learn group memberships more quickly than they would if they had to wait until the IGMP querier sent its next general query.

 

Т.е. это не бага, а фича. Типа свитч хочет очень быстро построить таблицу igmp-snooping'а, чтоб не флудить мультикастом туда, где он не нужен, если "сверху" падает мультикаст

 

Возможности проверить решения у меня сейчас нет, поэтому могу только предложить несколько вариантов решений:

1. set protocols igmp interface all disable . дело в том, что igmp-snooping неявно наследует некоторые настройки из igmp, возможно это поможет, но сильно сомневаюсь в этом

2. сделать правило в фаевроле на out на RE. query генерится контрол-плейном, возможно вам получится его зарезать

3. зарезать igmp query на оборудовании, в которое включен этот EX-свитч, чтобы query получали только даунлики свитчи. на многом оборудовании есть фильтрация igmp query, явная(специальными командами) или неявная(всяческими acl)

[evil-man]

Спасибо большое. Ситуация теперь прояснилась. К сожалению, средствами самого Juniper'овского свитча зарезать эти query не удалось - они почему-то мимо файерволла пролетают, даже если вешать фильтр непосредственно на порт, а filter output на loopback интерфейсе не вешается. Поэтому решил резать эти запросы на вышестоящем свитче.

[srg555]

действитель, на EX нельзя повесит фильтр на RE на аут http://www.juniper.net/techpubs//en_US/junos/topics/concept/firewall-filter-ex-series-overview.html

[evil-man]

Как мне думается, проблема именно в цисках. В rfc4541 описаны правила работы igmp snooping-а. При этом, получение igmp query src 0.0.0.0 dst 224.0.0.1 не должно переводить порт в режим порта с подключенным mrouter'ом, но циска считает иначе. После получения этого igmp query, циска считает, что к этому порту подключен мультикаст-роутер, и начинает пересылать туда весь мультикаст трафик. Завтра потестирую ещё, чтобы убедиться в этом.

[srg555]

Весь RFC читать лень, можно выдержки, где написано именно то, о чём Вы говорите?

 

Де-факто, mrouter-порт как раз и определяется исходя из igmp v2 query на 224.0.0.1, другое дело, что обычно src не 0.0.0.0, а заданный IP валидного querier'а. Вы считаете, что если ip.src==0.0.0.0, то такие пакеты не должны порождать mrouter порты?

[evil-man]

Весь RFC читать лень, можно выдержки, где написано именно то, о чём Вы говорите?

 

Де-факто, mrouter-порт как раз и определяется исходя из igmp v2 query на 224.0.0.1, другое дело, что обычно src не 0.0.0.0, а заданный IP валидного querier'а. Вы считаете, что если ip.src==0.0.0.0, то такие пакеты не должны порождать mrouter порты?

 

На третьей странице. Вот выдержка.

 

The switch supporting IGMP snooping must maintain a list of

multicast routers and the ports on which they are attached. This

list can be constructed in any combination of the following ways:

 

...skip...

 

b) The arrival port for IGMP Queries (sent by multicast routers)

where the source address is not 0.0.0.0.

 

The 0.0.0.0 address represents a special case where the switch

is proxying IGMP Queries for faster network convergence, but is

not itself the Querier. The switch does not use its own IP

address (even if it has one), because this would cause the

Queries to be seen as coming from a newly elected Querier. The

0.0.0.0 address is used to indicate that the Query packets are

NOT from a multicast router.

[srg555]

Да, значит надо запилить кейс в Cisco(если саппорт куплен). Хотя со стороны Juniper довольно подло было сделать эту фишку неотключаемой, особенно учитывая то, что эта rfc 2006 года, а свитчи с igmp-snooping'ом были и до этого времени

[evil-man]

В release notes откопал вот такую вот штуку.

 

Symptom: IGMP query, with source IP address: 0.0.0.0, triggers a querier election process. As a

consequence, port on which this packet is received is marked as mrouter port for that VLAN.

 

Router#show ip igmp int vlan 1 
Vlan1 is up, line protocol is up Internet address is 1.1.1.1/24 IGMP querying router is 0.0.0.0 <----
Router#sh ip igmp snooping mrouter vlan ports
-----+---------------------------------------- 1 Po1,Po8,Router<-----

Conditions: This symptom is seen when IGMP query with source IP address: 0.0.0.0 is received.

Workaround: Configure an ACL to block packets with source IP address: 0.0.0.0 and apply it to

relevant interfaces.

 

access-list 100 deny ip host 0.0.0.0 any 
access-list 100 permit ip any any 
int vlan 1 
ip access-group 100 in

Further Problem Description: Per RFC 4541, IGMP query

with source IP address: 0.0.0.0 is used in special cases. When such query is received by a router,

it should not be used in the querier election process.

Edited September 17, 2013 by evil-man