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