Top-10 ошибок настройки/дизайна СПД в ISP

1. Вся сеть (или большие сегменты) в одном VLAN. Аналогично и с управлением оборудованием. Совсем печальный случай, когда и управление и data-трафик находятся в одном единственном default VLAN. Такие схемы нормально не работают, проблемы практически не поддаются траблшутингу. Совсем хорошо, когда между абонентами нет L2-взаимодействия, а в идеале, когда они не могут влиять друг на друга по мак-таблице.

2. Анонс своей сети, не имея её в таблице маршрутизации (популярные в небольших ISP Quagga и Mikrotik RouterOS это позволяют). Эффект этого очевиден для любого грамотного инженера – петля маршрутизации. Обычно такое происходит при совмещении ASBR и BRAS в одной железке, про роут сети в NULL0/blackhole забывают.

3. Использование слишком сложных схем резервирования на L2. Кольца доступа+кольца агрегационных свитчей, да ещё и замыкание колец доступа на различных узлах агрегации и всё это с использованием какой-либо вариации STP или его аналога ни к чему хорошему не приводят. Аварий из-за слишком сложной топологии становится больше, чем пользы от такого резервирования.

4. Включение (точнее, невыключение) PIM/OSPF/прочего в сторону абонента. К чему это может привести догадаться не сложно. На деле, абоненты редко анализируют что к ним приходит и проводят попытки это как-то использовать с вредоносными целями. Однако, практика показывает, что любая потенциальная проблема дизайна или настройки рано или поздно превращается в аварию или проблему. Ниже пример(оригинал) (докладчик – широко известный в узких кругах Saab95), как на на конференции пользователей оборудования Mikrotik рассказывают о том как неправильно настраивать OSPF

5. Включение (точнее, невыключение) десктопных и сервисных функций на софтроутерах, что приводит к деградации производительности (packet drops). Наиболее часто это энергосбережение (пример, архив), некоторые offload-ы сетевых карт, предназначенные для увеличения производительности локальных сервисов (а не софтроутера). Здесь лидер это TSO (tcp segmentation offload). Относительно TSO можно найти тысячи радостных постов на просторах интернета о том как его выключение повышает производительность. Ещё одно большое зло для софтроутеров это IOMMU(VT-d), см. здесь(архив). Очень много информации о том как правильно готовить софтроутеры имеется на форуме nag.ru.

6. Политики безопасности ниже плинтуса. Например, оставить L3-связность между абонентом и интерфейсом управления оборудования, поставить пароль на CLI/web/прочее и больше ничего не делать. Так нельзя, некоторые D-Link’и убивались даже специально сформированным icmp-пакетом. Управление должно быть спрятано в VRF или защищено пакетным фаерволом, а не просто access-list’ом, который используется самим сервисом (пример такой разницы для IOS-XR). Каждый день в базах уязвимостей ПО появляются новые записи, поэтому всё, что можно закрыть на L3 нужно закрывать на L3, тем самым минимизировать взаимодействие untrusted трафика с сервисами управления. Сюда же стоит добавить рекурсивный DNS-сервис, открытый всему интернету и ntp. Относительно DNS фаервол уже мало спасёт и нужно осуществлять регулярные обновления безопасности ПО.
Особо печальный случай, что мне приходилось видеть это БД биллинга, доступная с любого хоста интернет, при этом логин, пароль и название базы данных было очень простым словарным словом (типа admin/admin/admin). В одном абзаце про политики безопасности в ISP не расскажешь, но надеюсь, что идея в целом понятная.

7. Отсутствие ограничений на NAT per-customer и слишком большое количество абонентов за одним внешним IPv4-адресом. Первое может привести к тому, что закончится таблица xlat, что вызовет почти полную деградацию сервиса, второе к появлению регулярных “капч” на различных сайтах или даже блокировка доступа со стороны каких-либо ресурсов. 50-100 абонентов за одним внешним адресом это нормально, можно и больше, но дальше уже появляются различные проблемы, иногда они существенные, иногда нет.

8. Классика жанра – ebgp без out-фильтров. Поднимаем 2 аплинка, прописываем свои сети и тупиковая AS становится потенциально транзитной. Об этом написано практически в любом курсе по BGP, но “мы сами с усами, а курсы от вендоров это лишь пропаганда их оборудования”. Любой нормальный аплинк, конечно же, зафильтрует то, что вы анонсируете не по делу, но сейчас и небольшие операторы, настраивающие OSFP по советам из видеоролика выше, могут продавать IP-транзит и не иметь нормальных фильтров на in в bgp в сторону тех, кто забывает фильтры на out.

9. Игнорирование проблемы микробёрствов. В ШПД это не так критично(до поры до времени), а вот для реалтайм-сервисов очень даже. Известный мне пример – использование свитчей Cisco 3560G, 3750E/X и т.п.(оборудование с маленьким пакетным буфером) для включения оборудования ЦТВ/КТВ, при этом трафика на даунлинк портах довольно много и аплинк 2G, так делать нельзя, если трафик сверху приходит не идеально равномерный (без бёрстов). Подробнее см. здесь.

10. redistribute bgp fv в ospf. Здесь должна была быть шикарная картинка, показывающая как это проиcходит, но не опубликована по просьбе главной героини этого коллажа.

Наглая копипаста отсюда