Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Ещё не читал (на досуге раскурю), но уже спасибо!
А кто-нибудь сталкивался с необходимостью использовать в продакшне NSSA/totally NSSA области?
Я даже больше скажу: редко когда есть смысл вообще бить сеть OSPF на области, и часто это только мешает :)
Суммаризация тоже относится к классу «обычно нет смысла, и временами мешает». Она осмыслена разве что с самого края сети, куда MPLS не дотянется. Ну например региональная сеть из сотен мелких железок подключена к паре больших железок — вот там да, nssa no-summary — правильная вещь (nssa, чтобы не лишать себя навеки возможности по какой-либо причине редистрибутить маршрут).
Хотя в случае описанной выше топологии правильное решение — EIGRP :)
Хотя в случае описанной выше топологии правильное решение — EIGRP :)
А если сеть не на цисках?
Печально. В топологии multihub&spoke OSPF — не лучшее решение.
И не везде нужен MPLS, часто хватает обычной маршрутизации.
Что не отменяет простого факта: при наличии всего нескольких сотен маршрутов разбиение сети на области и суммаризация совершенно необоснованны.
подразумевается, что это, так же, как и virtual-link, костыль для сетей, где «исторически сложилось» нечто ужасное.
Если надо в общем и целом держать область стабом, но по какой-то причине понадобилось редистрибутить статику или другой протокол с одной из железок — почему бы и нет? Я бы не назвал это чем-то ужасным.
А можно глупый вопрос. Не с точки зрения красоты и правильности дизайна, а с точки зрения практических проблем. Что будет, если будет только ареа0 а все остальное пойдет как редистрибьют коннектед с л3 устройств площадок, т. е. все маршруты будут внешними.
В общем случае — ничего плохого не будет. Это может даже упростить конфигурирование. Например — у свитча пара L3 аплинков (с соседями по OSPF) и 20 VLANов, которые надо анонсировать в OSPF, и еще пара L3 интерфейсов строго локально без анонса. Redistribute connected с роут-мапом — очень даже вариант, сэкономящий много строк в конфигурации.
Спасибо за ответ. Это действительно короче в смысле конфигруации. Тем более если эту редистрибьюцию не надо фильтровать вообще.
Понравилось про экономию строк в конфигурации. :)
Это ж как получается, инженер не экономией ресурсов оборудования озабочен или там правильным дизайном, а количеством написанный строк :)
Это ж как получается, инженер не экономией ресурсов оборудования озабочен или там правильным дизайном, а количеством написанный строк :)
При прочих равных можно и о собственном удобстве подумать.
То есть я правильно понимаю, что redistribute connected (static) равны не использованию оных (Использование LSA1 LSA2 вместо)?
С точки зрения архитектуры не равны. С точки зрения результата равны. Внимательно читайте условие.
Ну что ж.
С моей точки зрения (вычитал где-то, да и так понятно), следует предпочитать redistributed роуты (LSA 5), потому что они быстрее обсчитываются, потому как не принимают участия в построении графа, на который потом накладывается алгоритм Дейкстры.
Соот-но нагрузка на CPU становится меньше в больших ospf сетях.
В частности про это написано в главе 7.3.2 книги: OSPF and IS-IS: Choosing an IGP for Large-Scale Networks By Jeff Doyle
С моей точки зрения (вычитал где-то, да и так понятно), следует предпочитать redistributed роуты (LSA 5), потому что они быстрее обсчитываются, потому как не принимают участия в построении графа, на который потом накладывается алгоритм Дейкстры.
Соот-но нагрузка на CPU становится меньше в больших ospf сетях.
В частности про это написано в главе 7.3.2 книги: OSPF and IS-IS: Choosing an IGP for Large-Scale Networks By Jeff Doyle
Назовите конкретные цифры. Например: насколько замедлится схождение сети (включающее и время на обнаружение аварии, и время на расхождение LSU, и таймеры троттлинга) при наличии лишних пограничных LSA 2-го типа, которые не могут быть транзитными, и с учетом оптимизаций вроде ISPF? На один процент? Или даже на два?
И мы снова возвращаемся к вопросу «несущественно, потому делай как удобно». Если есть требование обеспечить сходимость в пределах максимум сотни миллисекунд при наличии большой сети, одним IGP тут уже не обойтись.
Само собой, в совсем крупных территориально распределенных сетях, на 10к+ префиксов, рекомендация «держать всё в одной арии» уже не дается.
И мы снова возвращаемся к вопросу «несущественно, потому делай как удобно». Если есть требование обеспечить сходимость в пределах максимум сотни миллисекунд при наличии большой сети, одним IGP тут уже не обойтись.
Само собой, в совсем крупных территориально распределенных сетях, на 10к+ префиксов, рекомендация «держать всё в одной арии» уже не дается.
Я проще напишу.
Меньше операций, меньше греем CPU, меньше выброса тепла, больше КПД оборудования. Ну и экология. И эта экономия есть _всегда_. Ну и как приятность — мы получим меньшее время конвергенции протокола, что не есть плохо, не правда ли?
А про как удобно — мне удобно конфиги забацать в vim-е и разлить по сети скриптом. И тут время простое — одна строчка — у меня где-то одна секунда создается, а может и меньше. Но эта одна затраченная секунда (ну пускай минута, для ровного счета), будет экономить электричество, выделять меньше тепла и т.д. и т.п.
К тому же, лично для меня, отдебажить ospf с маленьким LSA1 database и большим LSA5 гораздо проще, чем наоборот.
Так что же лучше?
Сэкономить минуту работы инженера — которая стоит 1$, или сэкономить явно заведомо большую сумму денег, которая уйдет на эл-во, отвод тепла, большую загрузку control-plane, что может вылиться в покупку нового оборудования…
Вопрос, конечно, философский.
Меньше операций, меньше греем CPU, меньше выброса тепла, больше КПД оборудования. Ну и экология. И эта экономия есть _всегда_. Ну и как приятность — мы получим меньшее время конвергенции протокола, что не есть плохо, не правда ли?
А про как удобно — мне удобно конфиги забацать в vim-е и разлить по сети скриптом. И тут время простое — одна строчка — у меня где-то одна секунда создается, а может и меньше. Но эта одна затраченная секунда (ну пускай минута, для ровного счета), будет экономить электричество, выделять меньше тепла и т.д. и т.п.
К тому же, лично для меня, отдебажить ospf с маленьким LSA1 database и большим LSA5 гораздо проще, чем наоборот.
Так что же лучше?
Сэкономить минуту работы инженера — которая стоит 1$, или сэкономить явно заведомо большую сумму денег, которая уйдет на эл-во, отвод тепла, большую загрузку control-plane, что может вылиться в покупку нового оборудования…
Вопрос, конечно, философский.
Меньше операций, меньше греем CPU, меньше выброса тепла, больше КПД оборудования.
Вот гляжу я на свой зоопарк шеститонников, у которых львиная доля тепла исходит от ASICов на линейных картах и не имеет никакого отношения к соntrol plane, и хочется мне пойти и обнять березку…
И какой еще к черту КПД?
И эта экономия есть _всегда_.
Вы в курсе, сколько ресурсов жрет банальный «show run», введенный на модульном коммутаторе с кучей портов, и если не применена одна маленькая читерская команда? А еще SNMP при опросе состояния портов тратит кучу тактов. То есть долой мониторинг, и не надо логиниться на железку… А hello пакеты OSPF? Это же кошмар! Срочно ставим hello/dead в 60/180. И убираем BFD к чертовой бабушке, это тоже электричество жрет.
Что еще? Ах да, сама передача пакета трансивером загрязняет экологию. Надо на все 10G интерфейсы навесить полисеры на 56к, тогда и линейные карты греться не будут.
А еще есть страшный монстр «блейд-корзина», выхлопом которого может одновременно и сдувать, и сжигать. Срочно вырубаем, и все простые сервера впридачу!
Ну и как приятность — мы получим меньшее время конвергенции протокола
…
заведомо большую сумму денег, которая уйдет на… большую загрузку control-plane
Цифры будут?.. Я пока не увидел причин, по которым изменение типа LSA способно дать хоть чуточку заметный выигрыш в тактах. Голая теория — это прикольно, но иногда бывает полезно думать своей головой. И уж точно не следует впадать в маразм, экономя милливатты там, где сжигаются мегаватты.
:) Что я вижу в этом ответе:
1. Похвастался «своим» (пока дядя не отобрал) «зоопарком» (а что так не организованно)
2. Похвастался знанием «читерской» команды (причислил себя к классу _очень_ умных цискарей)
3. Продолжаешь троллить неотносящимеся к теме терминами OSPF, BFD, hello/dead и так далее.
На мой взгляд, искусство инженера как раз и состоит в том, чтобы в каждом случае найти границу разумной применимости той или иной технологии.
Я был несогласен в том, что минимум вводимых инженером команд — не есть критерий хорошести конфигурации. На мой взгляд, удобство инженера — на 10-м месте. А на первом — эффективность использования вверенных ему ресурсов.
И я, кстати, книжку приводил в подкрепление своих слов — спорьте с ее автором: Jeff Doyle
P.S.: Прекращаю это бесполезный спор.
1. Похвастался «своим» (пока дядя не отобрал) «зоопарком» (а что так не организованно)
2. Похвастался знанием «читерской» команды (причислил себя к классу _очень_ умных цискарей)
3. Продолжаешь троллить неотносящимеся к теме терминами OSPF, BFD, hello/dead и так далее.
На мой взгляд, искусство инженера как раз и состоит в том, чтобы в каждом случае найти границу разумной применимости той или иной технологии.
Я был несогласен в том, что минимум вводимых инженером команд — не есть критерий хорошести конфигурации. На мой взгляд, удобство инженера — на 10-м месте. А на первом — эффективность использования вверенных ему ресурсов.
И я, кстати, книжку приводил в подкрепление своих слов — спорьте с ее автором: Jeff Doyle
P.S.: Прекращаю это бесполезный спор.
Что я вижу в этом ответе:
Вы видите что-то несуществующее. Снова. Какое-то у вас странное восприятие…
1. А чем тут хвастаться? Просто иллюстрация того, что существуют платформы, у которых control plane по сравнению с data plane не кушает энергию вообще.
2. Так как я — опытный тролль, я страхуюсь от глупых придирок со стороны оппонента. Упомянув банальную команду, кушающую 100% ЦП в течение нескольких секунд, было бы глупо подставляться, не упомянув и воркараунд — вдруг вы про него знаете и вздумаете прицепиться? :)
3. То есть hello пакеты и BFD кипалайвы не тратят энергию? Ни на свою генерацию, ни на отправку через порт? Потрясающе :) Вы в курсе, насколько просядет ЦП у железки с сотней соседей и hello таймером в секунду?
На мой взгляд, искусство инженера как раз и состоит в том, чтобы в каждом случае найти границу разумной применимости той или иной технологии.
Ага. Вы демонстрируете отсутствие искусства, отстаивая неприменимые в общем случае книжные заповеди и даже не пытаясь обдумать их.
А на первом — эффективность использования вверенных ему ресурсов.
Эффективность использования ресурса — это обычно близкая 100% его утилизация, а не простой :)
спорьте с ее автором
О том и речь. Учитесь думать своей головой, а не цитировать других.
Что в глаза бросилось:
Да ну на фиг? А прилетевший методом redistribute префикс — не сеть, и OSPF не будет его распространять?
Правильнее сказать «роутеры имеют полную карту топологии своей области».
Чтобы не смущать народ, напишите просто «area 0».
Нет. Этот алгоритм считает только кратчайшие маршруты до всех сетей.
Это значит, что роутеры не передают друг другу в качестве обновлений информацию о сетях. Вместо этого роутеры обмениваются информацией о состоянии своих интерфейсов или объявлениями о состоянии канала.
Да ну на фиг? А прилетевший методом redistribute префикс — не сеть, и OSPF не будет его распространять?
Правильнее сказать «роутеры имеют полную карту топологии своей области».
Есть магистральная область (Backbone, идентификатор 0.0.0.0)
Чтобы не смущать народ, напишите просто «area 0».
На каждом роутере отрабатывает Dijkstra, который просчитывает все возможные альтернативы до всех сетей.
Нет. Этот алгоритм считает только кратчайшие маршруты до всех сетей.
Тогда уж правильней сказать, что в LSA 1 и 2 содержится информация о топологии, а в LSA 3 собственно сети в привычном виде, в т.ч. и redistribute
Чтобы не смущать народ, напишите просто «area 0».
Народ смутится, когда увидит конфиги других вендоров, где будет что-то типа «area 192.168.1.1»
Если надо в общем и целом держать область стабом, но по какой-то причине понадобилось редистрибутить статику или другой протокол с одной из железок — почему бы и нет? Я бы не назвал это чем-то ужасным.
В stub-зону можно редистрибьютить? Это что же, LSA 5 типа летать начнут?
Спасибо, один из самых подробных гайдов по типам LSA и area.
Только у Вас есть ошибка в выводе команд. Вы когда рассказываете по External LSA (тип 5) — в database summary присутствуют только Type-7 LSA, а ASBR Summary (Type 5) нету. То есть там приводится пример вывода с роутера в NSSA-area, где Type-5 заменяется на Type-7
Только у Вас есть ошибка в выводе команд. Вы когда рассказываете по External LSA (тип 5) — в database summary присутствуют только Type-7 LSA, а ASBR Summary (Type 5) нету. То есть там приводится пример вывода с роутера в NSSA-area, где Type-5 заменяется на Type-7
В рассказали про LSA Type: 1, 2, 3, 5, 7
А что про Type:4? Без него Type:5 чувствует себя не по себе.
А что про Type:4? Без него Type:5 чувствует себя не по себе.
Год назад, в качестве конспекта по ccnp route, запилил свою вики shibaev.no-ip.info/wiki/Заглавная_страница.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Типы областей OSPF