Комментарии 1
Интересная статья, спасибо автору(ам), что не поленились написать:)
Соглашусь с выводом статьи — заниматься трафик-инжинирингом, отключая включенные по умолчанию фичи на отдельно стоящем роутере (не просто так-то они и включены по дефолту) — не совсем хорошая идея.
Как минимум capability transit надо было бы тогда выключать на всех internal-роутерах данной зоны, чтобы обеспечить консистентный Control-Plane OSPF для них — и петли бы тогда не было ;)
Лучшая идея на мой неискушенный взгляд для задачи TE — использовать для этого предназначенные инструменты — MPLS-TE и\или всяческие другие overlay-техники — благо решений много.
На худой конец играть стоимостью OSPF :)
А по поводу петли — её также можно устроить просто не дав появиться маршруту в RT (ospf distribute-list in) — LSDB засинкалась по всей area, но роутер использует то, что видит в «отфильтрованном» RIB.
Но это не вина протокола, как и не вина протокола в том, что capability transit фича выключена на одном роутере и из-за этого не вышло консистентности Control-Plane по всей Area:)
VL сам по себе безвреден, и используется для того, чтобы закрыть просчеты по дизайну OSPF-домена — а это, имхо, благое дело. Да, можно использовать GRE до ABR — и помещать их в бэкбон зону, но ценой оверхедов на инкапсуляцию; можно сделать «разрывный» OSPF с default-originate по одной части бэкбона — да и вообще много чего сделать с дизайном OSPF, а потом страдать от side-effects:)
В общем Link-state OSPF не панацея от кривизны рук, хоть и очень хорош собой. А при использовании инструмента\фичи, надо либо досконально понимать как он работает, либо делать рабочее PoC-решение (но если на PoC вы используете другое ПО — старое\новое — не факт что сеть в продакшене поведет себя также — всегда есть возможность не предусмотреть баги\доп.фичи)
Соглашусь с выводом статьи — заниматься трафик-инжинирингом, отключая включенные по умолчанию фичи на отдельно стоящем роутере (не просто так-то они и включены по дефолту) — не совсем хорошая идея.
Как минимум capability transit надо было бы тогда выключать на всех internal-роутерах данной зоны, чтобы обеспечить консистентный Control-Plane OSPF для них — и петли бы тогда не было ;)
Лучшая идея на мой неискушенный взгляд для задачи TE — использовать для этого предназначенные инструменты — MPLS-TE и\или всяческие другие overlay-техники — благо решений много.
На худой конец играть стоимостью OSPF :)
А по поводу петли — её также можно устроить просто не дав появиться маршруту в RT (ospf distribute-list in) — LSDB засинкалась по всей area, но роутер использует то, что видит в «отфильтрованном» RIB.
Но это не вина протокола, как и не вина протокола в том, что capability transit фича выключена на одном роутере и из-за этого не вышло консистентности Control-Plane по всей Area:)
VL сам по себе безвреден, и используется для того, чтобы закрыть просчеты по дизайну OSPF-домена — а это, имхо, благое дело. Да, можно использовать GRE до ABR — и помещать их в бэкбон зону, но ценой оверхедов на инкапсуляцию; можно сделать «разрывный» OSPF с default-originate по одной части бэкбона — да и вообще много чего сделать с дизайном OSPF, а потом страдать от side-effects:)
В общем Link-state OSPF не панацея от кривизны рук, хоть и очень хорош собой. А при использовании инструмента\фичи, надо либо досконально понимать как он работает, либо делать рабочее PoC-решение (но если на PoC вы используете другое ПО — старое\новое — не факт что сеть в продакшене поведет себя также — всегда есть возможность не предусмотреть баги\доп.фичи)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Краткое пособие по созданию петель маршрутизации в OSPF в домашних условиях