allan_sundry Опубликовано 29 октября, 2013 · Жалоба Доброе время суток! Мы получаем поток от аплинка используя взаимодействие MBGP + MSDP + PIM, кроме того построено MBGP + MSDP + PIM взаимодействие с рядом клиентов. От одного из клиентов (который раздает IPTV в своей домосети) приходит флуд, который вызывает проблемы с картинкой - сыпется изображение, пропадает звук. Как можно отфильтровать весь мультикастовый вход от проблемнго клиента что-бы он не влиял на всех остальных? С нашей стороны Cisco 6504E + 3BXL + WS-6704-10GE: ip multicast-routing interface TenGigabitEthernet3/4.196 description -= MBGP-MSDP-PIM-CLINET =- encapsulation dot1Q 196 ip address 10.254.11.1 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp ip pim bsr-border ip pim sparse-dense-mode ip multicast boundary 2 in no cdp enable interface TenGigabitEthernet3/4.945 description -= MBGP-MSDP-PIM-UPLINK =- encapsulation dot1Q 945 ip address 10.224.1.26 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp ip pim bsr-border ip pim sparse-dense-mode no cdp enable access-list 2 remark -= MULTICAST BOUNDARY =- access-list 2 deny 239.0.0.0 0.255.255.255 access-list 2 permit any router bgp XXXX no bgp enforce-first-as bgp log-neighbor-changes neighbor 10.224.1.25 remote-as UUUU neighbor 10.224.1.25 description MBGP-UPLINK neighbor 10.254.11.2 remote-as CCCC neighbor 10.254.11.2 description MBGP-CLIENT address-family ipv4 no neighbor 10.224.1.25 activate no neighbor 10.254.11.2 activate exit-address-family address-family ipv4 multicast neighbor 10.224.1.25 activate neighbor 10.224.1.25 route-map NOTHING-OUT out neighbor 10.254.11.2 activate neighbor 10.254.11.2 route-map NOTHING-IN in exit-address-family ip pim rp-address 10.224.1.26 SM-Groups override ip msdp peer 10.224.1.25 remote-as UUUU ip msdp description 10.224.1.25 MSDP-ULINK ip msdp sa-filter out 10.224.1.25 ip msdp peer 10.254.11.2 remote-as CCCC ip msdp description 10.254.11.2 MSDP-CLINET ip msdp sa-filter in 10.254.11.2 ip msdp cache-sa-state ip msdp cache-rejected-sa 1000 ip msdp default-peer 10.224.1.25 ip access-list standard SM-Groups deny 224.0.1.39 deny 224.0.1.40 permit 224.0.0.0 15.255.255.255 со стороны проблемного клиента Cisco 3750: ip multicast-routing distributed interface Vlan196 description UPLINK ip address 10.254.11.2 255.255.255.252 no ip redirects no ip unreachables no ip proxy-arp ip pim bsr-border ip pim sparse-dense-mode interface Vlan999 description CLIENTS ip address 10.254.3.1 255.255.255.0 no ip redirects no ip proxy-arp ip pim passive router bgp CCCC bgp log-neighbor-changes neighbor 10.254.11.1 remote-as XXXX neighbor 10.254.11.1 description UPLINK ! address-family ipv4 no neighbor 10.254.11.1 activate exit-address-family address-family ipv4 multicast neighbor 10.254.11.1 activate exit-address-family ip pim rp-address 10.254.11.2 SM-Groups override ip msdp peer 10.254.11.1 remote-as XXXX ip msdp description 10.254.11.1 UPLINK ip msdp cache-sa-state ip msdp default-peer 10.254.11.1 ip access-list standard SM-Groups deny 224.0.1.39 deny 224.0.1.40 permit 224.0.0.0 15.255.255.255 Когда прекращается трансляция на проблемный сегмент сети нашего клиента или при выключении в сети нашего клеинта источника помех картинка стабилизируется. Помогите разобраться с проблемой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 29 октября, 2013 · Жалоба Навесить ацл на его порт, чтобы по макам резал весь мультикаст, кроме броадкаста. Заодно флоуконтрол везде проверьте чтобы выключен был. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
allan_sundry Опубликовано 29 октября, 2013 · Жалоба Навесить ацл на его порт, чтобы по макам резал весь мультикаст, кроме броадкаста. Заодно флоуконтрол везде проверьте чтобы выключен был. А можно пример ACL? Я думал что в роли этого ACL выступает следующее: ip multicast boundary 2 in в настройках интерфейса и access-list 2 remark -= MULTICAST BOUNDARY =- access-list 2 deny 239.0.0.0 0.255.255.255 access-list 2 permit any но данная настройка на работает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 29 октября, 2013 · Жалоба даже навесить фильр на порт на оборудовании доступа... куда он включен.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
allan_sundry Опубликовано 30 октября, 2013 · Жалоба даже навесить фильр на порт на оборудовании доступа... куда он включен.... Есть ли проверенные на практике решения для D-Link DGS 3420-28SC? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 30 октября, 2013 · Жалоба А можно пример ACL? Я в железках редко копаюсь, потому увы. в настройках интерфейса и У мультикаста подсеть гораздо шире: 224/4 Я бы фильровал по макам: выставленный бит в первом байте говорит что это мультикаст, но предварительно нужно разрешить/добавить исключение ff::ff чтобы броадкаст ходил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 30 октября, 2013 · Жалоба даже навесить фильр на порт на оборудовании доступа... куда он включен.... Есть ли проверенные на практике решения для D-Link DGS 3420-28SC? нет но можно посмотреть в сторону packet content filter (некоторые примеры есть на сайте длинка) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Minya Опубликовано 31 октября, 2013 · Жалоба Я думал что в роли этого ACL выступает следующее: ip multicast boundary 2 in в настройках интерфейса и access-list 2 remark -= MULTICAST BOUNDARY =- access-list 2 deny 239.0.0.0 0.255.255.255 access-list 2 permit any но данная настройка на работает Этими настройками вы обозначиваете границу сети и запрещаете 239/8 на входе. Вам уже предложили заменить сеть в этом фильтре на 224/4. Рассыпание только на одной группе/канале или на всех сразу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
allan_sundry Опубликовано 31 октября, 2013 · Жалоба Я думал что в роли этого ACL выступает следующее: ip multicast boundary 2 in в настройках интерфейса и access-list 2 remark -= MULTICAST BOUNDARY =- access-list 2 deny 239.0.0.0 0.255.255.255 access-list 2 permit any но данная настройка на работает Этими настройками вы обозначиваете границу сети и запрещаете 239/8 на входе. Вам уже предложили заменить сеть в этом фильтре на 224/4. Рассыпание только на одной группе/канале или на всех сразу? Группы в которых идет вещание в сети работают в диапазоне 239.0.0.0/8. При флуде от проблемного клиента сыпятся все каналы. Попробую поменять в ACL подсеть. Прибил ACL вида: access-list 2 remark -= MULTICAST BOUNDARY =- access-list 2 deny 224.0.0.0 15.255.255.255 access-list 2 permit any Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilili Опубликовано 31 октября, 2013 · Жалоба switchport block multicast на порту, на всякий случай )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lousx Опубликовано 31 октября, 2013 (изменено) · Жалоба На длинке же вроде бы для этого config multicast vlan_filtering_mode vlanid 1212 filter_unregistered_groups Изменено 31 октября, 2013 пользователем lousx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Minya Опубликовано 31 октября, 2013 · Жалоба switchport interface TenGigabitEthernet3/4.196 ip address 10.254.11.1 255.255.255.252 allan_sundry меня смущает sparse-dense-mode на ваших с пользователем граничных интерфейсах, auto-RP какой-нибудь может всё ломать. не уверен что на цисках ip multicast boundary ещё и auto-rp режет. В общем попробуйте просто sparse. upd: "...Auto-RP filter-autorp option is in use on the ip multicast boundary interface command" вот это сначала. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
allan_sundry Опубликовано 31 октября, 2013 · Жалоба switchport block multicast на порту, на всякий случай )) А как вещать мультикаст в направлении клиента? Думаю это точно не вариант. Пробовал на 65-й прибивать на сабинтерфейс: ip multicast rate-limit in 0 но эффекта не дало - убрал. На длинке же вроде бы для этого config multicast vlan_filtering_mode vlanid 1212 filter_unregistered_groups пробовал - не помогает... allan_sundry меня смущает sparse-dense-mode на ваших с пользователем граничных интерфейсах, auto-RP какой-нибудь может всё ломать. не уверен что на цисках ip multicast boundary ещё и auto-rp режет. В общем попробуйте просто sparse. upd: "...Auto-RP filter-autorp option is in use on the ip multicast boundary interface command" вот это сначала. можно попробовать, но сомневаюсь что поможет, кроме того сейчас у меня PR указана статически - насколько я понимаю приход autorp перебить статику не может. Кроме того вернулся к старому фильтру т.к. нашел интересную информацию: rfc2236 по IGMPv2: 9. Message destinations This information is provided elsewhere in the document, but is summarized here for convenience. Message Type Destination Group ------------ ----------------- General Query ALL-SYSTEMS (224.0.0.1) Group-Specific Query The group being queried Membership Report The group being reported Leave Message ALL-ROUTERS (224.0.0.2) соответственно Group-Specific Query и Membership Report отправляются на адрес группы в которую идет вещание, если зафильтровать ее на абонентском порту то до роутера не дойдет Membership Report соответственно IGMPv2 будет работать не корректно. Интересно другое - как флуд от абонента нашего клиента попал в магистральный стык между нами и нашим клиентом? У нашего проблемного клиента на доступе для его абонентов стоят коммутаторы D-Link с настроенным MVR: enable igmp_snooping multicast_vlan config igmp_snooping multicast_vlan forward_unmatched disable create igmp_snooping multicast_vlan ISM-XXX 21 config igmp_snooping multicast_vlan ISM-XXX tate enable replace_source_ip 10.x.x.x <== это адрес из сети PIM роутера, у каждого свича он свой config igmp_snooping multicast_vlan ISM-XXX add member_port 1-24 config igmp_snooping multicast_vlan ISM-XXX add source_port 25-28 config multicast vlan_filtering_mode vlanid <all-vlans> filter_unregistered_groups enable igmp_snooping config igmp_snooping vlan_name ISM-XXX fast_leave enable report_suppression disable а интернет для этого абонента терминируется на сервере где никаким PIM или чем-то мультикастовым не светит: Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilili Опубликовано 31 октября, 2013 · Жалоба А как вещать мультикаст в направлении клиента? Думаю это точно не вариант. switchport block multicast = Block unknown multicast addresses Если всё настроено "как надо", то будет счастье Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Minya Опубликовано 31 октября, 2013 · Жалоба allan_sundry Вроде бы boundary именно мультикаст-дата-трафик режет. Входящий в вашем случае. И у вас там не IGMP ходят, а PIM-join/prune и тп. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cryptospy Опубликовано 31 октября, 2013 (изменено) · Жалоба не знаю как на длинках это делается, а на хуавее настраивается на порту в сторону роутера вещающего мультикаст: igmp-snooping static-router-port vlan xxx т.е. запрещает коммутатору самому выбирать, откуда будет приходить мультикаст. Изменено 31 октября, 2013 пользователем cryptospy Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lousx Опубликовано 31 октября, 2013 · Жалоба Просмотр сообщенияlousx (Сегодня, 10:55) писал: На длинке же вроде бы для этого config multicast vlan_filtering_mode vlanid 1212 filter_unregistered_groups пробовал - не помогает... Есть еще в мануале: Настройка запрета передачи трафика от мультикаст-сервера 233.34.28.4 с/на порт 11 config limited multicast address 11 from 233.34.28.4 to 233.34.28.4 access deny state enable Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
allan_sundry Опубликовано 31 октября, 2013 · Жалоба allan_sundry (Сегодня, 12:07) писал: А как вещать мультикаст в направлении клиента? Думаю это точно не вариант. switchport block multicast = Block unknown multicast addresses Если всё настроено "как надо", то будет счастье Хм... Вы пробовали это на практике? На каком оборудовании? allan_sundry Вроде бы boundary именно мультикаст-дата-трафик режет. Входящий в вашем случае. И у вас там не IGMP ходят, а PIM-join/prune и тп. Надо разобраться детальнее... Например с тем же PIM бросается в глаза: PIMv2 Hellos are periodically multicast to the “All-PIM-Routers” (224.0.0.13) group address. (Default = 30 seconds) – Note: PIMv1 multicasts PIM Query messages to the “All-Routers” (224.0.0.2) group address. т.е. не все однозначно, да и как вещание в "левых" группах может цеплять остальные?! не знаю как на длинках это делается, а на хуавее настраивается на порту в сторону роутера вещающего мультикаст: igmp-snooping static-router-port vlan xxx т.е. запрещает коммутатору самому выбирать, откуда будет приходить мультикаст. Собственно в примере для D-Link тоже сразу видно где источник, а где клиентский порт. allan_sundry (Сегодня, 12:07) писал: Просмотр сообщенияlousx (Сегодня, 10:55) писал: На длинке же вроде бы для этого config multicast vlan_filtering_mode vlanid 1212 filter_unregistered_groups пробовал - не помогает... Есть еще в мануале: Настройка запрета передачи трафика от мультикаст-сервера 233.34.28.4 с/на порт 11 config limited multicast address 11 from 233.34.28.4 to 233.34.28.4 access deny state enable Это конечно хорошо, но как это применить на этапе стыка с клиентом который уже дальше в своей сети раздает мультикаст непосредственно абонентам со своего оборудования? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lousx Опубликовано 31 октября, 2013 · Жалоба Это конечно хорошо, но как это применить на этапе стыка с клиентом который уже дальше в своей сети раздает мультикаст непосредственно абонентам со своего оборудования? А если заставить его сконвертировать мультикаст в его сетке в другой влан? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Minya Опубликовано 31 октября, 2013 · Жалоба да и как вещание в "левых" группах может цеплять остальные?! Если только они совпадают с вашими по мак-адресу т.к. там на один мак 32 IP маппится (http://nettools.aqwnet.com/ipmaccalc/ipmaccalc.php) Исходя из того что проблема на всех группах, можно предположить что клиентский RP регистрирует ваши группы у себя, а затем с помощью механизма auto-rp (он кстати приоритетнее статики) он начинает выступать RP для ваших же групп в вашей же сети. Однако boundary фильтр такое должен предотвращать... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cryptospy Опубликовано 31 октября, 2013 · Жалоба ТС я советую прочитать как работает igmp (snooping) и на коммутаторе, где гадит клиент настроить жестко router-port как это настраивается на длинке, я у же за вас погуглил: ftp://ftp.dlink.ru/pub/Switch/DGS-3420%20Series/Description/DGS-3420_Series_FW_R1.50_CLI%20Reference%20Guide_v1.50.pdf стр. 444-445 еще интересно было бы посмотреть sh ip igmp int ХХХ интерфейса маршрутизатора, который смотрит на сегмент нехорошего клиента Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ilili Опубликовано 31 октября, 2013 · Жалоба Вы пробовали это на практике? На каком оборудовании? ME3400 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 31 октября, 2013 · Жалоба т.е. не все однозначно, да и как вещание в "левых" группах может цеплять остальные?! См счётчики дропа пакетов. Коммутатор заливает трафиком, ему не хватает буферов чтобы принять и переслать и он дропает. Если только они совпадают с вашими по мак-адресу т.к. там на один мак 32 IP маппится (http://nettools.aqwn...c/ipmaccalc.php) Это где? В обычных ОС IPv4 адрес целиком пишется в мак, младший байт =1, следующий =0 и дальше идёт ип адрес мультикаст группы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Minya Опубликовано 1 ноября, 2013 · Жалоба Ivan_83 В RFC 1112 например IP-адрес группы отображается на multicast-адрес Ethernet путем помещения 23 младших битов адреса IP в 23 младших бита multicast-адреса Ethernet 01-00-5E-00-00-00 (шестнадцатеричный). Поскольку значащая часть группового адреса IP содержит 28 битов, несколько групп хостов могут отображаться на один multicast-адрес Ethernet. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
allan_sundry Опубликовано 1 ноября, 2013 · Жалоба allan_sundry (Сегодня, 13:34) писал: Это конечно хорошо, но как это применить на этапе стыка с клиентом который уже дальше в своей сети раздает мультикаст непосредственно абонентам со своего оборудования? А если заставить его сконвертировать мультикаст в его сетке в другой влан? Так и происходит - стык MBGP + MSDP + PIM в VLAN 196, а раздача абонентам домосети в другом VLAN - 999, интернет к абонентам приходит в третьем VLAN. ТС я советую прочитать как работает igmp (snooping) и на коммутаторе, где гадит клиент настроить жестко router-port как это настраивается на длинке, я у же за вас погуглил: ftp://ftp.dlink.ru/pub/Switch/DGS-3420%20Series/Description/DGS-3420_Series_FW_R1.50_CLI%20Reference%20Guide_v1.50.pdf стр. 444-445 еще интересно было бы посмотреть sh ip igmp int ХХХ интерфейса маршрутизатора, который смотрит на сегмент нехорошего клиента Расскажите детальнее что неправильно в приведенном мною конфиге коммутатора доступа из сети нашего клиента? #sh ip igmp interface Te3/4.196 Te3/4.196 is up, line protocol is up Internet address is 10.254.11.1/30 IGMP is enabled on interface Current IGMP host version is 2 Current IGMP router version is 2 IGMP query interval is 60 seconds IGMP configured query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP configured querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query count is 2 Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 7 joins, 6 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 10.254.11.2 IGMP querying router is 10.254.11.1 (this system) No multicast groups joined by this system allan_sundry (Вчера, 13:34) писал: т.е. не все однозначно, да и как вещание в "левых" группах может цеплять остальные?! См счётчики дропа пакетов. Коммутатор заливает трафиком, ему не хватает буферов чтобы принять и переслать и он дропает. думаю такой порт было-бы легко увидеть на графиках с Cacti, но перегузки трафиком на коммутаторах наш клиент не нашел, как и не поступало жалоб от его абонентов, которые работают с этого же коммутатора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...