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

ACL на свичи доступа убиваем абонентский мусор

Добрый день коллеги.

Задался вопросом, с помощью ACL зарезать весь мусорный трафик. На данный момент использую только 1 ACL, которая режет абонентские DHCP.

В принципе написать ACL которые будут резать ARP, multicast, igmp не проблема. Интересует абонентская сторона, не будет ли слюней от абонентов, что какая нибудь онлайн игра отвалилась, или порники на каком нибудь сайте перестали грузиться?

Share this post


Link to post
Share on other sites

Сейчас посыпятся посты мол делайте vlan-per-customer и все эти ACL не нужны. :)

 

Что у вас за устройства и о сети расскажите чуть больше.

Share this post


Link to post
Share on other sites

Сейчас посыпятся посты мол делайте vlan-per-customer и все эти ACL не нужны. :)

 

Что у вас за устройства и о сети расскажите чуть больше.

Как у всех, зоопарк. В основном Cisco/Extreme ну а дальше D-Link, Edge-Core.

Зачем vlan-per-customer, существующая схема меня вполне устраивает, абоненты не жалуются, скорость не проседает. Просто когда запускал у себя Cisco 4948, она начала гнуться потому что CEF начал скидывать мусор на проц, снял зеркало с проца, а там multicast, arp от роутеров, BPDU, igmp.

Share this post


Link to post
Share on other sites

Сейчас посыпятся посты мол делайте vlan-per-customer и все эти ACL не нужны. :)

 

Что у вас за устройства и о сети расскажите чуть больше.

помоему от мультикаста это не спасёт.

Share this post


Link to post
Share on other sites

от мультикаста хорошо спасает приведение версии кверьера на всей сети к единому знаменателю - ни одна железка не любит, когда в нее лупят пакеты иной версии ;)

Share this post


Link to post
Share on other sites

Можно ещё указать мроут порты и дропать лишние квери и репорты

Share this post


Link to post
Share on other sites

Как правило можно безболезненно со стороны абонента порезать мультикаст storm-control до level pps 5 2, сильно облегчает жизнь спу вышестоящих кошек.

Share this post


Link to post
Share on other sites

В принципе написать ACL которые будут резать ARP, multicast, igmp не проблема. Интересует абонентская сторона, не будет ли слюней от абонентов, что какая нибудь онлайн игра отвалилась, или порники на каком нибудь сайте перестали грузиться?

На самом деле написать ACL - проблема. Вернее, написать конкретные ACL для конкретного случая - легко, а вот собрать все правила в кучу и заставить все работать целостно - то еще кунг-фу. На D-Link я постоянно упираюсь в различные технические ограничения, а если захочется поменять какое то правило иногда это требует переработки всей структуры ACL.

 

Еще большая проблема блокировок - можно ненароком заблокировать всякие "спецсхемы", вип-клиентов и прочие нестандартные штуки. К примеру в абонентском свичике 23 абонента, которым нельзя вещать свой мультикаст, и один супер-друг-директора, которому можно. Если это предусмотреть, то на абонентах никак не отразится.

 

В корпоративной wiki есть вот такая табличка:

porttypes.png

В ней показано, какие настройки изменят свое состояние при изменении типа абонентского порта. Практически все ситуации сюда укладываются. Подключаем чью то чужую сеть транзитом, меняем тип порта на VIP, обновляем конфиг и лишние блокировки для порта снимаются.

 

Сейчас при помощи ACL нашей сети решаем следующие задачи:

 

  • Блокировка трафика от абонентов к сетям управления.
  • Блокировка определенных портов для предотвращения доступа к общим сетевым ресурсам.
  • Блокировка неправильных ARP-пакетов от абонентов (в целях предотвращения ARP-spoofing'а).
  • Блокировка IP-пакетов с поддельными SRC IP-адресами (IP-Spoofing) в целях предотвращения DDoS-атак и исчерпания пула NAT.
  • Отправка приоритетного трафика (телевидение) в определенную очередь (резервирование полосы пропускания). (не так давно переделал, теперь другой механизм)
  • Блокировка мультикаста от абонентов.
  • Разрешение любого трафика с порта (включается вручную).

 

При этом используем схему vlan на коммутатор + сегментация трафика для абонентов.

 

После введения блокировок коммутаторы перестали "моргать" на карте. Иногда они это делали, т.к. хоть в какие vlan засовывай абонентов, трафик может просачиваться на CPU коммутатора и начинает его нагружать.

 

В общем, во многом ACL нужны для уменьшения нагрузки на свою сеть, для НЕ попадания в разные блок-листы и для предотвращения прочих проблем. Самих абонентов это касается в меньшей степени.

Share this post


Link to post
Share on other sites

Мы делаем изоляцию портов до агрегации, где стоит Extreme/Cisco и он уже делает ingress и egress ACL. А мультикаст мы на доступе в отдельный vlan переносим - соответвенно на агрегации в пользовательских vlan дропаем весь 224.0.0.0/4.

LLDP и STP блокируем на доступе настройками этих функций. ACL используем только для блокирвки MAC-адресов.

Share this post


Link to post
Share on other sites

что только люди ни делают, лишь бы не внедрять vlan per customer :P

Share this post


Link to post
Share on other sites

У меня вопрос по ACL, точнее по cpu access profile. Я их прописываю на кластерах, точнее сказать на DGS-3120. Так вот вроде бы всё норм, но у меня дома медиаплеер иконбит не хочет нормально работать. Подписка просто устаревает и канал отваливается. Поснифал - он шлёт запросы на ssdp 239.255.255.250. Но при этом другие плееры, например eltex или dune этого не делают.

Вы у себя разрешаете этот адрес?

Share this post


Link to post
Share on other sites

xcme: табличка занятная, спасибо. А что под патчкордом подразумевается?

Share this post


Link to post
Share on other sites

У меня вопрос по ACL, точнее по cpu access profile. Я их прописываю на кластерах, точнее сказать на DGS-3120. Так вот вроде бы всё норм, но у меня дома медиаплеер иконбит не хочет нормально работать. Подписка просто устаревает и канал отваливается. Поснифал - он шлёт запросы на ssdp 239.255.255.250. Но при этом другие плееры, например eltex или dune этого не делают.

Вы у себя разрешаете этот адрес?

Неа. В CPU ACL разрешаем 224.0.0.2 (leave) и диапазон вещания, который разрешаем еще в mcast filtering. Остальное от абонентов режется как CPU ACL, так и обычными ACL. Дополнительно на портах к абонентам filtering unregistered group. Ну и на аплинке загоняем мультикаст в приоритетную очередь. Проблем с недоступностью незамечено, левых групп на коммутаторах тоже нет.

Share this post


Link to post
Share on other sites

xcme: табличка занятная, спасибо. А что под патчкордом подразумевается?

Это для удобства. В самописной системе управления схематично отображается коммутатор со своими портами и абоненты на этих портах. Спец порты и магистрали там также помечены. Магистралью мы считаем линк с другим коммутатором или маршрутизатором, а патчкордом договорились называть линк с другим коммутатором в этом же боксе. Расцветка помогает быстро понять есть ли еще другие коммутаторы в этом же боксе или нет. То есть открываем "морду" и видим: "Ага, аплинк в 28-м порту, один транзитный линк на другой подъезд в 27-м и два коммутатора здесь же рядом". :)

Share this post


Link to post
Share on other sites
У меня вопрос по ACL, точнее по cpu access profile. Я их прописываю на кластерах, точнее сказать на DGS-3120. Так вот вроде бы всё норм, но у меня дома медиаплеер иконбит не хочет нормально работать. Подписка просто устаревает и канал отваливается. Поснифал - он шлёт запросы на ssdp 239.255.255.250. Но при этом другие плееры, например eltex или dune этого не делают. Вы у себя разрешаете этот адрес?

#define UPNP_SSDP_V4_ADDR "239.255.255.250"

#define UPNP_SSDP_V6_ADDR_LINK_LOCAL "FF02::C" // link local scope

#define UPNP_SSDP_V6_ADDR_SITE_LOCAL "FF05::C" // site local scope

#define UPNP_SSDP_V6_ADDR_LINK_LOCAL_EV "FF02::130" // for link local multicast eventing

#define UPNP_SSDP_V6_ADDR_SITE_LOCAL_EV "FF05::130" // for site local multicast eventing

#define UPNP_SSDP_PORT 1900 // default value for ssdp unicast, const for multicast

#define UPNP_SSDP_UC_PORT_MIN 49152 // unicast search

#define UPNP_SSDP_UC_PORT_MAX 65535

#define UPNP_SSDP_V6_EVENT_PORT 7900

 

Это не подписка, это UPnP/DLNA обнаружение устройств, если резать от абонента то у него может долго искать UPnP/DLNA сервера в вашей сети и потом их терять, впрочем я в своём SSDP анонсере просто сделал опцию где интервал между анонсами задаётся отдельно от времени их валидности, и ставлю чтобы анонсило раз в 10 секунд а жило 10 минут.

Если же у вас только мультикастом тв то там есть служебные мультикаст адреса куда ходит IGMP, вики/рфк в помощь.

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