Речь пойдёт о протоколе OSPF и видах area. На хабре уже есть статья описывающая какие бывают виды областей. Считаем, что вы её уже читали. А тут я попробую написать о том зачем это нужно с примерами.
“Ну, во-первых, это красиво” — разбиение на области, агрегация и суммирование префиксов, таблица маршрутизации помещается на пару экранов 🙂
В остальном, если самое слабое оборудование которое вы используете у себя в сети это какое-нибудь “старьё” вроде “шеститонников” (а 1G линки это вчерашний день), то можете дальше не читать. Смело стройте всё на “backbone area” (0.0.0.0), многие тысячи ваших маршрутизаторов и не чихнут при этом.
если же это не так…
Во-вторых — это удобно, когда присутствует “естественная” необходимость разбивать сеть на части, например:
- они находятся под разным административным управлением (разные админы)
- географически разнесены (разные города, районы одного города, корпуса предприятия).
- OSPF area совпадают с Security Zone, тогда трафик между областями будет ходить только через ABR, на которых можно прописать все нужные правила
фильтрация префиксов в OSPFдействительно, в пределах области все маршрутизаторы имеют одинаковые LSDB, иначе нарушатся принципы на которых построен link state протокол. Между областями же OSPF действует как distance vector, поэтому фильтрация префиксов на ABR вполне приемлема
однако, большинству администраторов привычнее в этих случаях использовать для связи таких областей BGP, а внутри частей использовать или одну ареа, или вообще разные протоколы маршрутизации.
в-третьих — мы можем экономить ресурсы маршрутизаторов: процессор, память, нагруженость линков.
т.е. маршрутизаторы, которые долго обсчитывают SPF для всей сети, лучше вынести в отдельную область, чтоб они считали только её. Также есть смысл вынести части сети с большим количеством событий (нестабильными сегментами) в отдельные области, т.к. (вспомним таймеры «OSPF SPF Throttling» и их значения по умолчанию) хроническая нестабильность одного интерфейса может вызвать значительные задержки в сходимости всей сети.
Кстати, в рекомендациях 15летней давности было явно указано, что количество маршрутизаторов в области следует ограничить 60-80. Сейчас это может быть актуально если у вас, например: очень б/у (отлично работает на своём месте); L3 коммутатор с несильным ЦП у которого и так много дел кроме расчётов SPF; SOHO xWRT и т.д.
в продолжение темы про экономию процессора вспомню два способа анонсировать тупиковые сети/линки — через “Router LSA” и как «external LSA» (через redistribute connected). По большей части, при современном оборудовании это вопрос удобства и личных предпочтений ( вариант с Router LSA — “чуточку эстетичнее”). Но т.к. мы уже договорились что у нас не всё так радужно, то нужно понимать, что в случае Router LSA каждое изменение состояния интерфейса будет приводить к запуску алгоритма SPF, и постоянно флапающий интерефес может привести к неприятным последствиям (т.к. оборудование со слабым процессором, его может не хватить на другие задачи ), а если процессор одноядерный и нет разделения на control и data plane, то становится совсем плохо (но не настолько, как в случае L2 шторма:). С другой стороны мы можем анонсировать сеть как “external connected”, тут будет чуть больше строк в конфигурации и кое-что ещё.
Недостатки:
LSA2 —
- обязательный запуск SFP на всех маршрутизаторах при любом изменении интерфейса
LSA5(7) —
- иногда не работает ECMP
(проверьте своего вендора) - слегка сложнее конфигурация
(совсем немного) - не суммируются по “area range”,
только фильтруются в стаб ареа - отдельный LSA на каждую сеть, быстрее расходуется память.
несмотря на преимущество первого метода, если в сети генерируется много событий и control plane устройства заметно страдает от этого, то, возможно, вы предпочтёте «redistribute connected».
Начинаем экономить память. Первым делом используем механизм «area-range», так мы уменьшим количество Summary LSA и маршрутов распространяемых через них. Можно применить радикальный подход и сделать «area 0.0.0.0 area-range 0.0.0.0/0» но во-первых — некоторые вендоры запрещают такую конструкцию, во-вторых LSA3 (от других областей, не нулевой) и LSA5 будут ходить как ходили и занимать память. А ведь их может быть очень много, иногда и /19 может быть разложена на /32-е.
для борьбы с external LSA придумали «stub area», в ней полностью запрещены LSA5, а вместо них ABR может анонсировать в такую область LSA3 с дефолтом. Но как-то выяснилось, что это не удобно: мы не можем в такой области использовать наш любимый «redistribute connected» (и не только «connected»). Пэтому появились «не такие уж и тупиковые области» для которых всё также запрещены LSA5 но придуман свой способ работать с «внешними» маршрутами. На данный момент нет причин использовать «stub area» вместо «NSSA».
ну что же, нам осталось только победить LSA3 которые транзитом через backbone area распространяются ABR. Фильтр на них и дефолтвендор и назвал «totally stub/NSSA» area. Т.к. это не настоящий вид области, то настраивается она только на ABR, у других вендоров может называться по другому, а там где её нет можно накрутить аналогичное поведение через правила.
Ограничивая количество LSA можно не только экономить память маршрутизаторов, но и существенно ускорить сходимость сети в условиях медленных линков, т.к. если удалённое подключение организовано с помощью радио/FSO через жд/авто дорогу, с резервом через SHDSL, то время синхронизации LSDB может занимать десятки секунд, и тогда пригодятся все способы уменьшения количества LSA.
P.S. ещё одна ситуация когда приходит на помощь разбиение на области и вынос маршрутизаторов поглубже в “total stub area” это необходимость беречь “control plane” некоторых особо “нежных” и непредсказуемых устройств от лишнего беспокойства.
P.P.S. кто ещё примеров может добавить — пишите в комментарии! Т.к. варианты применения областей в современном мире не всегда очевидны.
ссылка на оригинал статьи http://habrahabr.ru/post/260327/
Добавить комментарий