Jump to content
Калькуляторы

IPTV как защититься от вещания со стороны клиента сыпется картинка - подозрение на флуд от клиента

Доброе время суток!

 

Мы получаем поток от аплинка используя взаимодействие 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

 

Когда прекращается трансляция на проблемный сегмент сети нашего клиента или при выключении в сети нашего клеинта источника помех картинка стабилизируется.

Помогите разобраться с проблемой.

Share this post


Link to post
Share on other sites

Навесить ацл на его порт, чтобы по макам резал весь мультикаст, кроме броадкаста.

Заодно флоуконтрол везде проверьте чтобы выключен был.

Share this post


Link to post
Share on other sites

Навесить ацл на его порт, чтобы по макам резал весь мультикаст, кроме броадкаста.

Заодно флоуконтрол везде проверьте чтобы выключен был.

 

А можно пример 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

но данная настройка на работает

Share this post


Link to post
Share on other sites

даже навесить фильр на порт на оборудовании доступа... куда он включен....

Share this post


Link to post
Share on other sites

даже навесить фильр на порт на оборудовании доступа... куда он включен....

 

Есть ли проверенные на практике решения для D-Link DGS 3420-28SC?

Share this post


Link to post
Share on other sites
А можно пример ACL?

Я в железках редко копаюсь, потому увы.

 

в настройках интерфейса и

У мультикаста подсеть гораздо шире: 224/4

Я бы фильровал по макам: выставленный бит в первом байте говорит что это мультикаст, но предварительно нужно разрешить/добавить исключение ff::ff чтобы броадкаст ходил.

Share this post


Link to post
Share on other sites

даже навесить фильр на порт на оборудовании доступа... куда он включен....

 

Есть ли проверенные на практике решения для D-Link DGS 3420-28SC?

нет

но можно посмотреть в сторону packet content filter (некоторые примеры есть на сайте длинка)

Share this post


Link to post
Share on other sites

Я думал что в роли этого 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.

Рассыпание только на одной группе/канале или на всех сразу?

Share this post


Link to post
Share on other sites

Я думал что в роли этого 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

Share this post


Link to post
Share on other sites

switchport block multicast на порту, на всякий случай ))

Share this post


Link to post
Share on other sites

На длинке же вроде бы для этого

config multicast vlan_filtering_mode vlanid 1212 filter_unregistered_groups 

Edited by lousx

Share this post


Link to post
Share on other sites

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" вот это сначала.

Share this post


Link to post
Share on other sites

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 или чем-то мультикастовым не светит:

Share this post


Link to post
Share on other sites

А как вещать мультикаст в направлении клиента? Думаю это точно не вариант.

switchport block multicast = Block unknown multicast addresses

Если всё настроено "как надо", то будет счастье

Share this post


Link to post
Share on other sites

allan_sundry

Вроде бы boundary именно мультикаст-дата-трафик режет. Входящий в вашем случае. И у вас там не IGMP ходят, а PIM-join/prune и тп.

Share this post


Link to post
Share on other sites

не знаю как на длинках это делается, а на хуавее настраивается на порту в сторону роутера вещающего мультикаст: igmp-snooping static-router-port vlan xxx

т.е. запрещает коммутатору самому выбирать, откуда будет приходить мультикаст.

Edited by cryptospy

Share this post


Link to post
Share on other sites

Просмотр сообщения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

Share this post


Link to post
Share on other sites

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

 

Это конечно хорошо, но как это применить на этапе стыка с клиентом который уже дальше в своей сети раздает мультикаст непосредственно абонентам со своего оборудования?

Share this post


Link to post
Share on other sites

Это конечно хорошо, но как это применить на этапе стыка с клиентом который уже дальше в своей сети раздает мультикаст непосредственно абонентам со своего оборудования?

А если заставить его сконвертировать мультикаст в его сетке в другой влан?

Share this post


Link to post
Share on other sites

да и как вещание в "левых" группах может цеплять остальные?!

Если только они совпадают с вашими по мак-адресу т.к. там на один мак 32 IP маппится (http://nettools.aqwnet.com/ipmaccalc/ipmaccalc.php)

Исходя из того что проблема на всех группах, можно предположить что клиентский RP регистрирует ваши группы у себя, а затем с помощью механизма auto-rp (он кстати приоритетнее статики) он начинает выступать RP для ваших же групп в вашей же сети. Однако boundary фильтр такое должен предотвращать...

Share this post


Link to post
Share on other sites

ТС я советую прочитать как работает 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 ХХХ интерфейса маршрутизатора, который смотрит на сегмент нехорошего клиента

Share this post


Link to post
Share on other sites

Вы пробовали это на практике? На каком оборудовании?

ME3400

Share this post


Link to post
Share on other sites
т.е. не все однозначно, да и как вещание в "левых" группах может цеплять остальные?!

См счётчики дропа пакетов.

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

 

 

Если только они совпадают с вашими по мак-адресу т.к. там на один мак 32 IP маппится (http://nettools.aqwn...c/ipmaccalc.php)

Это где?

В обычных ОС IPv4 адрес целиком пишется в мак, младший байт =1, следующий =0 и дальше идёт ип адрес мультикаст группы.

Share this post


Link to post
Share on other sites

Ivan_83

В RFC 1112 например

IP-адрес группы отображается на multicast-адрес Ethernet путем помещения 23 младших битов адреса IP в 23 младших бита multicast-адреса Ethernet 01-00-5E-00-00-00 (шестнадцатеричный). Поскольку значащая часть группового адреса IP содержит 28 битов, несколько групп хостов могут отображаться на один multicast-адрес Ethernet.

Share this post


Link to post
Share on other sites

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, но перегузки трафиком на коммутаторах наш клиент не нашел, как и не поступало жалоб от его абонентов, которые работают с этого же коммутатора.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this