Настройка OSPFv2 в Cisco IOS (часть 2)

Продолжаем говорить про протокол OSPF. Мы в прошлый раз настроили связь по туннельному линку в лабе и убедились, что действительно OSPF у нас работает, он перетаскивает маршрут, и в таблицу маршрутизации маршруты попадают. Всё это происходит благодаря тому, что каждый роутер выпускает какие-то LSA, которые попадают в LSDB, и дальше LSDB синхронизируется на соседних роутерах. Самый простой тип LSA — это LSA первого типа, мы её видели, она действительно выпускается. Есть LSA другого типа: 2, 3, 4, 5 и 7. Давайте разбираться, как эти LSA будут выглядеть, как в таблице посмотреть содержимое LSA определённого типа и как LSDB будет собирать пазл из этих самых LSA. У нас есть пример: две area, они связаны между собой через — здесь нарисован свитч, на самом деле это просто Ethernet-среда.

Неважно, есть там свитч или нет свитча, может быть просто прямой провод, но свитч нарисован как будто он там есть, и показана сеть 10.1.2.0/24 в этом проводе. На одном из роутеров у нас есть интерфейс с IP-шником 192.168.1.чего-то по маске /24. Этот интерфейс у нас в нулевом регионе, так же как и все остальные интерфейсы. На другом роутере тоже есть интерфейс с сетью 192.168.2.0, там возможно IP-шник 2.1 или 2.2, неважно. Но этот интерфейс будет в другом регионе. Что в такой ситуации у нас будет выпускаться, какие LSA будут — вы должны хорошо себе представлять. На экзамене будут вопросы типа: у вас такая сеть, какие LSA там будут выпускаться. Здесь вы должны сразу сказать, что у нас, во-первых, будут две LSA первого типа. Каждый роутер выпустит одну LSA первого типа в каждом регионе. Есть две LSA за роутер 1.1.1.1, за роутер 2.2.2.2 в нулевом регионе.

Кроме того, есть одна LSA первого типа в первом регионе, потому что роутер 2.2.2.2 в этом регионе тоже присутствует. Если мы разбираем, например, только нулевой регион, то все роутеры в нулевом регионе будут видеть LSA первого типа от роутера первого и от роутера второго. Кроме того, поскольку связь по Ethernet происходит между этими двумя роутерами, в этом Ethernet у нас по умолчанию тип среды выбирается broadcast. Как следствие, в этом канале у нас должен выбираться DR, и он будет выпускать LSA второго типа. Поэтому, помимо того, что у нас есть LSA первого типа от каждого роутера, DR придумает ещё LSA второго типа, и роутеры по факту будут дружить именно с ней. При сборке пазла нам нужно будет сначала найти LSA первого типа, посмотреть, к какой LSA второго типа она подключена, и какие ещё роутеры подключены к этой LSA второго типа. LSA третьего типа в нулевом регионе тоже будет присутствовать, потому что сеть 192.168.2.0 будет переложена ABR-ом.

ABR у нас 2.2.2.2. И он будет её перекладывать в виде LSA третьего типа. Если вы хотите посмотреть содержимое таблицы LSDB, то вы можете это сделать с помощью команды show ip ospf database. Она покажет, какие LSA у нас здесь будут присутствовать. Мы видим, что у нас есть LSA первого типа — Router Link States. Это LSA Type 1. Type 1. В нулевом регионе видно LSA роутера R1 и R2. Каждый из роутеров выпустил LSA сам про себя и показывает, что у каждого роутера есть некоторое количество интерфейсов. Здесь показывается два линка, здесь показывается два линка. Кроме того, показывается, что у нас есть одна LSA типа 2. Type 2. Net Link States. Это LSA, выпускаемые DR-ом. Про то, что в канале есть множественный доступ. Эти LSA получают Link ID, идентификатор самой LSA, совпадающий с IP-шником DR.

Так что мы знаем, что 10.1.2.2 — это IP-шник DR. Судя по схеме, которая у нас нарисована на слайде, DR-ом в этой сети был выбран роутер 2. И это неудивительно, при условии, что у нас приоритеты по умолчанию. Если приоритеты по умолчанию одинаковые у обоих, то ID-шник будет больше у роутера 2. Всё честно. Advertising Router показывается Router ID того, кто придумал такую LSA. Да, Router ID DR. Дальше. Вот это IP DR, а вот это ID DR. Суммарка. LSA-тройка. Type 3 LSA. Summary Net Link States. Показывается, что у нас есть LSA, у которой ID-шник 192.168.2. Это IP-шник той сети, которая анонсируется ABR-ом. Advertising Router — кто придумал такую LSA — это Router ID ABR.

Внутри самой LSA, помимо ID-шника, хранится маска. Например, /24. /24 тоже в мясе. А Link ID — это IP-шник сети. Получается, что отдельно хранится IP-шник и отдельно маска. Помимо того, мы видим здесь ещё пятёрку. Type 5 AS External Link States — это пятёрки. И они не привязаны к региону. Эта пятёрка распространяется во всей автономной системе. Link ID — IP-шник той сети, про которую идёт рассказ. Внутри LSA-пятёрки в мясе содержится маска. Там /32, /16 или /24 — что у нас будет, неважно. Advertising Router — это у нас ASBR ID. Поскольку ASBR ID находится внутри региона, этот ID-шник роутера 2.2.2.2 известен нам через LSA первого типа, то LSA типа 4 нам не нужна.

У нас пазл и так собирается. Можно заказать конкретное содержимое LSA. В LSA второго типа показывается, что есть IP-шник DR. Кроме того, указывается маска. Или в LSA типа 3 тоже маска указывается. Но маска указывается в содержимом LSA. А когда мы заказываем show ip ospf database, мы смотрим только оглавление этой таблицы. Это как раз ровно то, что реплицируется на этапе Exchange. Краткое содержание, но без самого мяса. А иногда бывает интересно заглянуть в мясо. Например, посмотреть, какие линки есть внутри LSA первого типа. Он говорит, что здесь есть два линка. Окей, два линка — это хорошо. А что это за линки? Что там за IP-шники? Что там за соседство? Это надо уже заказывать содержимое самой LSA. Для этого у нас есть команда show ip ospf database. Дальше указываете тип LSA, который вас интересует. И ID-шник.

Вот это — тип. И вот это — LSA ID. В случае, если мы заказываем LSA первого типа, то LSA ID будет совпадать с Router ID того, кто придумал эту LSA. Вы можете не писать в явном виде ID-шник той LSA, которая вам интересна. Вы можете сказать: покажи мне ту LSA, которую придумал я сам. И тогда вместо ID-шника вы можете указать self-originate. Здесь вместо этой штуки — self-originate. И тогда вы увидите ту самую LSA, которую придумали именно вы. С неё очень удобно начинать сборку пазла. Как минимум ваша LSA первого типа в LSDB точно есть. Вы заказываете её и дальше смотрите, на кого вы подключены. Видите LSA, подключенные к вам. Заказываете их. Видите, кто к ним подключен. Заказываете их — и так далее, пока пазл у вас не соберётся. В нашем случае мы догадываемся, что LSA будет именно с ID-шником 1.1.1.1.

Мы её заказали. И нам показывают её содержимое. У каждой LSA есть тип. В нашем случае Router Links — это Type 1. Дальше показывается Link State ID. Про кого эта LSA? LS ID. Или про что эта LSA? Это у нас ID-шник роутера. Router ID. Дальше. Advertising Router — кто придумал эту LSA? Здесь роутер сам про себя придумывает, поэтому Advertising Router — это тоже Router ID того, кто её придумал. Sequence Number. LSA постоянно меняется. Как только выпускаются новые версии, мы прибавляем единичку к тому, что в Sequence Number лежало. Либо раз в полчаса мы выпускаем новую версию LSA, чтобы показать, что она не протухла. Поэтому при нормальной работе Sequence Number будет постоянно увеличиваться. У каждой LSA есть чек-сумма. Она передаётся на этапе Exchange, и вы можете посмотреть, что содержимое LSA действительно вам будет интересно.

Например, может быть такое, что у вас есть LSA, у неё ID-шник такой же, Advertising Router такой же, Sequence Number такой же, а чек-сумма другая. Это значит, что у вас разные LSA, которые претендуют на то, чтобы быть одинаковыми. В этом случае это означает, что у вас есть какой-то конфликт. Вы должны будете такие штуки отслеживать. Возможно, даже какой-то алертинг придумать. Но вы должны это опознать и понять, какую LSA использовать для сборки пазла. Нужно, чтобы все роутеры использовали одну и ту же LSA для сборки пазла. Пусть они неправильно будут собирать, но хотя бы одинаково. Главное, чтобы не получилось так, что один роутер использовал одну LSA, а другой — другую, и устроили петлю. Поэтому для сборки будет браться только одна LSA, а вторая будет по факту игнорироваться, как будто роутера просто такого в топологии нет. Если у вас такая штука будет, то, по крайней мере, роутеры не устроят петлю. Поэтому нужно знать, какую LSA брать, и они будут брать ту, у которой чек-сумма больше.

Им просто нужно выбрать одинаковую LSA из двух кандидатов. Одинаково на всех роутерах. Берут ту, у которой чек-сумма больше. Дальше. Длина. Просто длина в байтах. Сколько там мяса содержимого. Ничего интересного. В каждой LSA есть флаги: являемся ли мы ABR, являемся ли мы ASBR. И мы видим, что роутер 1 действительно является ABR. Здесь не показано, но он считает, что он действительно ABR. Видимо, у него где-то ещё один интерфейс есть, какой-нибудь Area 2, например. Это мы сейчас рассматриваем LSA роутера 1. Внутри этой LSA есть два линка. И у нас показывается, что есть транзитная сетка. Это LSA второго типа. Мы подключены к ней. Действительно, вот у нас подключение к ней. И эта LSA второго типа будет иметь ID-шник 10.1.2.2.

Где она у нас? LSA второго типа 10.1.2.2. Дальше показывается, что мы на эту LSA смотрим интерфейсом с IP-шником 10.1.2.1. И внутри самой LSA указывается маска, допустим /24. Внутри LSA второго типа. Поэтому, когда мы найдём такую LSA, мы поймём, что IP-шник, которым мы смотрим на эту LSA, будет 10.1.2.1 с маской /24. Показывается метрика. Мы интерфейсом с метрикой 1 смотрим на LSA второго типа, который отвечает за связь между двумя роутерами. Кроме того, у нас есть Stub Network. 192.168.1.0 — это пользовательская сеть. Просто обычная сетка. Никаких соседств там не обнаружено. И мы рассказываем, что эта сетка 192.168.1.0 по маске /24 с метрикой 1, мы на неё смотрим.

Для сборки пазла этого достаточно. Stub Network, напоминаю, — это пользовательская сетка без каких-либо соседств. Если у нас есть point-to-point соседство без LSA второго типа, одна LSA первого типа смотрит напрямую на другую LSA первого типа, то это было бы Point-to-Point Network. А здесь у нас Transit Network. Мы смотрим с LSA первого типа на LSA второго типа. Поведение по умолчанию в broadcast-средах типа Ethernet. Если мы нашли... Давайте вернусь на предыдущий слайд. Если мы нашли LSA второго типа, к которой мы подключены, ID у неё 10.1.2.2, мы можем её заказать. Говорим show ip ospf database, дальше указываем тип LSA — network — и ID LSA. ID у нас 10.1.2.2. И система показывает содержимое мяса LSA второго типа, Link State ID 10.1.2.2, тот самый, который просили. Оно же по совместительству IP-шник DR. Дальше. Кто придумал эту LSA? Это ID-шник DR.

Потому что LSA второго типа придумывает именно DR. Показывается маска, с которой все роутеры обязательно в этом канале одинаково существуют. Эта маска проверяется при установлении соседства, поэтому действительно ей можно доверять. Когда роутер первый говорит, что он смотрит на LSA второго типа с IP-шником 10.1.2.1, он маску свою не показывает, но эта маска показывает, что все с /24 сеткой здесь будут жить в этой сети. Показываются ID-шники соседей. Это ID-шник роутера 1, это ID-шник роутера 2. В нашем случае всего два соседа. Один из них DR, второй BDR. Так. Дальше. Можно было бы заказать отдельную LSA первого типа для роутера 2 и посмотреть, как они друг с другом сочетаются. Понятно, что команда там будет та же самая.

И там будет написано, что роутер 2 подключен как раз к LSA второго типа, поэтому пазл у нас действительно сойдётся. Одна LSA роутера 1, в которой говорится 192.168.1.0/24, Stub Network. И дальше он говорит: я смотрю на LSA второго типа. Дальше мы находим LSA второго типа, в которой указано, что одним концом мы смотрим на R1, другим концом на R2. И дальше R2 говорит: я смотрю на LSA второго типа, и у меня тоже, возможно, какие-то сетки есть подключенные, только их здесь не видно. Плюс он говорит, что он ABR, и у него есть доступ к каким-то внешним сетям, про которые он расскажет уже в дистанс-векторном стиле. Если у вас все эти LSA есть — раз LSA, два LSA, три LSA, — то вы собираете пазл, и они действительно друг с другом прекрасно состыкуются. В том случае, если R2 является ABR, мы можем заказать отображение LSA третьего типа, указываем show ip ospf database summary.

Опять же, summary — это не про суммирование IP-сетей, это суммирование костов, с которыми известна определённая сеть. Показывается ID-шник LSA третьего типа. Это совпадает с IP-шником той самой сети, про которую идёт рассказ в LSA третьего типа. Advertising Router — это у нас ABR ID. Дальше указывается IP-шник сети, её маска и её метрика. Это всё содержимое LSA. Она очень простая: в ней указывается только, до какой сети ABR может достать и за сколько копеек. Больше в ней ничего нет. Когда LSA третьего типа выпускается, мы строим кратчайший маршрут до ABR, потому что знаем, как до него добраться. У нас он есть в таблице топологии. Дальше мы говорим: мы до него построили кратчайший маршрут, он стоит какое-то количество копеек, плюс прибавим, сколько здесь написано, и получим суммарную стоимость доступа до сети в другом регионе.

Так, дальше. Пятёрки, если вдруг таковые будут, Можно посмотреть SHIP-у из PivDataBase External, и заказать ID-шник LSA-ки, если вы его знаете. ID-шник LSA-ки совпадает с IP-шником анонсируемой сети. В нашем случае 172.16.0.0. Это IP-шник сети, он же LinkStateID. Для пятерок они совпадают так же, как для трешек. Показывается IP-сети. Это ASBRID. Показывается Network Mask, сетка у нас 172.16.0.0 по 16-й маске. Показывается тип метрики, и в скобочках larger than any link state path — это намек на то, что эта цена в долларах, не в копеечках, которыми SPF оперирует. Поэтому она в любом случае важнее, чем любая внутренняя стоимость SPF. Если у вас есть несколько вариантов,

как можно выйти во внешний мир, есть две разные LSA-ки. У нас один ASBR1 и другой ASBR2. Один говорит, я знаю, как добраться до какой-то сети, и он присылает нам E2 метрику 20, а другой говорит, я знаю, как добраться до какой-то внешней сети, я знаю, как добраться за 19. 19 в любом случае метрика E2 будет лучше, чем 20. Неважно, насколько близко вы расположены к тому или иному ASBR. Даже если вы явно к одному ASBR находитесь ближе, вы говорите, нет, я не буду пользоваться его LSA-кой, потому что LSA-ка за 19 долларов получается выгоднее, чем 20. Даже несмотря на то, что к ASBR1 мы намного ближе. Показывается метрика, показывается forwarding address. В большинстве ситуаций мы его не используем. Реально, где он может быть полезен, это только сценарий конвертирования LSA-ки семерки в пятерку.

Бывают еще экзотические сценарии, когда он проставляется в явном виде. И метка в нашем случае не проставлялась. Семерка будет называться NSSA External. NSSA External. Как мог, так и написал. Да. Вам нужно будет примерно представлять название этих LSA-ек: роутерные LSA-ки, network LSA-ки или netlink LSA-ки. Summary, ASBR summary. Давайте прямо напишу. Router. Это тип 1. Дальше network, тип 2. Дальше summary. Дальше ASBR summary. Дальше external. И NSSA external.

Эти типы LSA-ек реально в цифрах поддерживаются. Получаются основные нечетные, а четные вспомогательные. Можно и так сказать, да. Но это скорее совпадение. Я не думаю, что кто-то прямо заморачивался и думал про четность-нечетность. Основные LSA-ки, безусловно, роутерные, потому что в них содержится основное мясо. Network — вспомогательный, для того чтобы пазл легче складывался. Summary — это перекладывание маршрутов между регионами. External — перекладывание маршрутов с другой автономной системы. Да, первое, третье и пятое — действительно основные. ASBR summary — это вспомогательное для того, чтобы найти, как добраться до внешнего ASBR, который находится в другом регионе. И семерка — NSSA External. По сути, та же пятерка, только переименованная. Так. Написано, да, я писал, старался.

NSSA External. Просмотр LSA-ек. Семерки. Содержимое у нее точно такое же. Содержимое у LSA-ек трешки и четверки, и пятерки, и семерки — у пары этих абсолютно одинаковые. Формат у них одинаковый. Summary и ASBR summary. Да, там показывается Network Mask. У ASBR Network Mask отсутствует, поэтому она 0. И в скобочках показывается, что для ASBR Network Mask не сильно полезна. И метрика. В случае с пятеркой и семеркой содержимое у них одинаковое. Единственное, что флаги могут немножко различаться. Так. Про четверку. У нас есть роутер 1.1.1.1, который вбрасывает какие-то внешние маршруты. Например, BGP-шные. Он показывает, что у него 172.16.0.0 по 16-й маске есть. И на роутере R2 мы говорим: у нас есть какой-то ABR. Роутер 1 в этом случае будет ASBR.

ASBR. Роутер 1. А ABR — это роутер 2. В первом регионе роутеры, которые будут находиться в первом регионе, они могут добраться до внешней сети, но только через LSA-ку пятерку плюс помогает четверка. В этом случае мы увидим, что в первом регионе у нас есть summary autonomous system border router link states. Здесь ASBR. Правильно, конечно, было бы ASBR. И показывается содержимое ее. Тип LSA-ки. Про ASBR — вспомогательная LSA-ка. ID-шник. Это ID-шник ASBR. ASBR ID. Если кто-то выпускает LSA-ку пятого типа и подписывается, что он 1.1.1.1, то в этой LSA-ке четверки можно через ABR добраться до ID-шника 1.1.1.1, даже несмотря на то, что в базе его нет. Естественно, в первом регионе в базе никакого 1.1.1.1 не будет присутствовать.

Показывается ID-шник ABR-а. ABR ID. Показывается Network Mask, которая абсолютно лишена какого-либо смысла в случае с ASBR ID. Нужна только, если вы берете тот же самый формат сообщения, но переделываете его в LSA-ку-трешку-summary. И показывается метрика. За сколько копеек знает ASBR ABR? В нашем случае 10 копеек. Так. Что касается флагов. Здесь propagate флаг... А, это четверка, простите. Да, четверка. Propagate семерки. Так. Если вы хотите что-то подебажить, подебажить можно либо Hello пакеты. Мы с вами уже это делали. Я вам показывал. Вы делаете debug IP OSPF Hello,

и система будет показывать каждый раз, когда у вас пробегает Hello пакет, либо вы его отправляете, либо вы его принимаете, что именно там будет присутствовать. Send Hello. В нашем случае мы отправляем мультикастовое Hello в нулевой регион с IP-шника 10.1.2.1. Или получаем Hello от ID-шника 2.2.2.2 в нулевом регионе от IP-шника 10.1.2.2. Это мы IP-шники видим, потому что IP-шники палятся в открытом виде в качестве IP-шника источника в пакете. В нашем случае показывают, что не все хорошо получилось, что MisMatch Hello параметры, чего-то не совпадает. Возможно, таймеры не совпадают. Можно заказать отображение конкретных пакетов, и в этом случае вы увидите пакеты. В нашем случае Receive пакета идет. У OSPF второй версии. Тип четверка. И тут вы сразу вспоминаете. Первый тип — это Hello. Второй тип — это DBD.

Третий тип — это LS Update. Четвертый — LS Request. И пятый — LS Acknowledge. В нашем случае мы видим тип 4. Явно это был LS Request. Показывается ID-шник, который отправил такой пакет. Показывается, на каком интерфейсе мы это получили. Практически всё. Для большинства задач этого на самом деле хватает. LS Acknowledge, которые приходят в этих пакетах. Вы либо принимаете эти пакеты, у вас LS Acknowledge добавляются, либо не принимаете, и они у вас не добавляются. После того как OSPF добавил LS Acknowledge, он делает пересчет топологии и добавляет маршрут в таблицу маршрутизации. И для того чтобы дебажить этот процесс, используется команда debug ip ospf rib. Всё, что связано с таблицей маршрутизации. Это uber-сценарий дебага.

Если у вас уже на уровне построения таблицы маршрутизации требуется дебаг, то значит, что что-то прямо пошло совсем не по плану. Скорее всего, это связано с задублированными LSA ID, с Router ID или чем-то таким, когда у вас пазл собирается неправильно. Если у вас соседи вроде бы все правильные, LS Acknowledge приходят правильно, Hello Packet приходят правильно, а пазл собирается неправильно — в этом случае приходится дебажить уже на таком уровне. Показывается, что у нас добавляется маршрут в таблицу маршрутизации 192.168.2.0 в нулевом регионе, Intra Area маршрут, метрика 11, получен через 10.1.2.2 от гигабита 0.0. ID-шник соседа вот такой. Показывается, что если у нас раньше был какой-то другой маршрут, маршрут заменяет предыдущий,

показывается, что мы заменили NextHop, который там раньше был. И если у нас всё хорошо, у нас, например, обнаружен какой-то новый маршрут, то показывается сообщение, что с маршрутом произошли какие-то изменения. В нашем случае изменился маршрут, добавлен новый способ добраться до сетки. И раньше у него был какой-то другой способ добраться до этой сети. Сейчас он стал получше. И мы заменили NextHop в таблице маршрутизации. Так. По поводу стабов и тотали стабов. Мы с вами смотрели на то, что бывают стабы. Мы смотрели на то, что в стабы вместо пятерок вбрасывается трешка с дефолтным маршрутом. И есть фирменная цисковская штука — это тотали стаб регион, который вы включаете только на ABR. Если у вас есть какие-то роутеры в обычном стаб регионе, вы на всех роутерах должны будете прописать,

что второй регион они должны считать стабом. И здесь тоже второй регион они должны считать стабом. В случае с тотали стабом эта фича только на ABR включается. Вы говорите: здесь тотали стаб. А на всех остальных роутерах вы можете сказать, что это просто стаб. Не надо на них указывать тотали стаб. Это бессмысленно. Это поведение только для ABR. И когда у вас есть ABR, на котором вы указываете, что какой-то регион будет тотали стабом, вы вместо вообще всех маршрутов вбрасываете один дефолтный маршрут. Нет смысла говорить, что есть такая сетка, есть такая сетка, пятая сетка, десятая сетка и все остальные сетки тоже, если можно сказать, что просто есть вообще все сети. Если вы указываете, что регион будет тотали стабом, вы заставляете ABR суммировать в одну дефолтную LSA-ку не только LSA-ки пятерки, но и LSA-ки трешки. Inter-area маршруты. Команда по назначению стаба или тотали стаба будет очень простая. В настройке роутера вы указываете area 2 stub, а для тотали стаба указываете

ключик no summary. Этот ключик no summary как раз указывает на то, что ABR при перекладывании маршрутов между регионами в этот регион не будет отправлять ни пятерки, ни трешки. За исключением одной трешки 0.0.0.0. Если у вас есть NSSA, то вы указываете вместо слова stub слово NSSA. Та же самая история: у нас есть роутер ABR, и вы указываете area 4 NSSA. Это на всех роутерах надо делать. Здесь указываете NSSA, здесь указываете NSSA, какие-то еще роутеры есть — везде указываете NSSA. Фактически вы представляете, что в этом регионе не допускаются пятерки, но допускаются семерки, LSA-ки семерки. Если вы указываете, что у вас есть NSSA регион, есть специфика Cisco: она не генерирует в этот регион LSA-ку пятерку, не пересылает в этот регион LSA-ки пятерки,

не пересылает внешние сети, и при этом не делает дефолтный маршрут, она их просто скрывает. Это специфика Cisco, которую надо просто запомнить, никакой логики в этом нет. У Cisco было какое-то пространное объяснение, зачем они это сделали в свое время, но это невозможно понять, и надо просто запомнить. При включении NSSA региона вы вместо того, чтобы все сетки пятерки в мире схлопнуть до дефолтного маршрута, все сетки пятерки схлопываете, а дефолтный маршрут не вкладываете. Если вы хотите, вы должны будете этот дефолтный маршрут вбросить в ручном режиме. По умолчанию эта трешка с дефолтом не появляется. Вот она, эта штука. Да, крестик тут стоит не случайно. Просто запомните это, запишите себе. Поведение абсолютно неразумное, нелогичное. Но тем не менее оно такое, как есть. Если вы объявляете регион с тотали стабом, то вы указываете area 5 NSSA no summary,

и в этом случае вы блокируете также и трешки. У вас появляется дефолтный маршрут. Здесь уже дефолтный маршрут появляется. С area 4 NSSA, если вы не указываете ключ no summary, дефолтный маршрут автоматом не появляется. Если вы указываете no summary, то есть не передавать дальше summary LSA, не передавать дальше трешки, то дефолтный маршрут у вас при этом есть, так же как вы, наверное, и ожидали бы. Просто надо запомнить, что при обозначении региона обычным NSSA Не генерируется LSA-ка трешка с дефолтным маршрутом. Дальше. Что еще здесь бывает? Вы можете повлиять на трансляцию LSA-ки семерки в LSA-ку пятерку, если у вас есть NSSA-регион. В NSSA-регионе мы можем выбрасывать внешние сетки, они будут появляться в виде LSA-ек семерок. Если у вас есть несколько АБРов в регионе, например, есть один АБР-1 и здесь другой АБР-2, по умолчанию, как вы помните, LSA-ку семерку в пятерку будет транслировать только тот роутер, у которого роутер ID больше.

АБР-2, например, скажет, что у меня роутер ID меньше, я же вижу, кто у меня внутри региона является АБРом. Я увижу, что у меня роутер ID меньше, и я не буду транслировать эту сетку в пятерку. Если вы хотите, чтобы у вас оба АБРа или конкретный АБР всегда транслировал семерки в пятерки, несмотря на то, что у вас, возможно, роутер ID будет меньше, чем у другого АБРа, вы указываете Translate Type-7 Always. Если вы это указываете, то у вас будет пятерку порождать как роутер с максимальным роутер ID, так и рядышком будет идти другая LSA-5, но уже от другого АБРа. Трафик, естественно, все равно будет ходить до одного и того же узла, но из двух этих LSA выберется какая-то одна, и трафик будет направляться в сторону ближайшей LSA-ки, скорее всего, или как вы поставите стоимости, но в любом случае будет доходить до этого АСБРа.

Если вы хотите, вы можете также сделать Translate Type-7 Suppress FA, Forwarding Address. Если вы это сделаете, то у вас вместо Forwarding Address с IP-шником АСБРа АБР будет вкладывать свой собственный IP-шник, он будет говорить, считайте маршрут до меня, и он будет каким-то образом пытаться поиграть с метрикой, которая будет в LSA-ке пятерке указываться. Штука довольно опасная, поэтому рекомендую с ней не играть, но тем не менее, если вдруг захотите, пожалуйста, посмотрите. Можно сочетать одно с другим, указать NSSA, Translate, Type-7, Always. Они сочетаются. Обратите внимание на то, что здесь указан синтаксис региона 0.0.0.5, номер региона. Мы везде указываем Area 0, Area 1, Area 9. На самом деле номер региона — это 32-битное число, и когда вы работаете с 32-битными числами, вы в Cisco можете задать это число в форме IP-адреса.

И формулировка Area 0.0.0.5 — это означает, что вы используете в качестве номера региона число 5, просто записанное в форме IP-шника, так же, как мы записываем IP-адреса. В некоторых случаях вам потребуется вбрасывать маршрут по умолчанию. Если вы хотите вбросить маршрут по умолчанию в NSSA-регион, то используется команда Area, дальше номер региона, NSSA и Default Information Originate. Когда мы просто объявляем Area 2 NSSA, у нас дефолтный маршрут, который вкладывает в себя все пятерки, не появляется. Если мы хотим, чтобы он появлялся, нужно указать Default Information Originate. В Totally Stub это делать не нужно. В Total NSSA регионе у нас появляется маршрут дефолтный из-за того, что мы складываем туда трешки. Но в обычном NSSA регионе требуется волшебный пендель Default Information Originate.

Если у нас не NSSA регион, а просто какой-то обычный регион, то можно в него тоже дефолт вбросить. Он будет появляться в виде LSA-ки пятерки. И соответственно команда будет в настройке роутера Default Information Originate. Вы просто будете говорить, что через вас можно добраться до любых сетей в мире, и трафик будет ходить до вас для того, чтобы дальше уйти во все сети в мире. Можно добавить этот маршрут только если у вас есть этот маршрут в таблице маршрутизации. Просто Default Information Originate берет дефолтный маршрут и вбрасывает его в OSPF. Классическое дистанц-векторное поведение. Если вы хотите вбросить дефолтный маршрут безусловно, независимо от того, есть он в таблице маршрутизации или нет, вы можете добавить ключик Always. Default Information Originate Always. Но есть нюанс. Эта штука не работает в NSSA-регионе. Если вы хотите в NSSA вбрасывать дефолт, то вы обязаны вот этим волшебным пенделем пользоваться.

Дальше. Когда вы порождаете такую пятерку, появляется новая LSA-ка пятерка. ID-шник LSA-ки совпадает с IP-шником сети, там же будет указываться маска слэш 0, Advertising Router — это ваш собственный ID-шник. Там больше уже ничего особо интересного не будет. Если мне память не изменяет, здесь будет метрика по умолчанию второго типа вбрасываться, и стоимость такой LSA-ки будет 2. Она будет, по-моему, заимствоваться из RIB, если мне память опять же не изменяет. Если вы ее вбрасываете, сколько у вас есть в RIB такая метрика, столько она здесь и показывается. Давайте попробуем это пощупать на наших Cisco-ках. Посмотрим, как у нас строится таблица топологии, и посмотрим, какие LSA-ки они будут создавать.

Давайте смотреть, что у нас есть в таблице сейчас. Наши роутеры связаны через центральный. В таблице топологии у нас у всех роутеров все примерно одинаковое. Show IP OSPF Database. Мы сейчас увидим, кто на кого чем смотрит. И мы видим, что есть у нас большое количество LSA-ек первого типа и больше ничего. Действительно, у нас сейчас все связи между роутерами сделаны через Point-to-Point-линк. Смотря на то, что кажется, что у нас Point-to-Multipoint на интерфейсе висит. Как здесь видно, на интерфейсе висит тип среды Network Point-to-Multipoint. Такого типа соседства нет. Есть тип среды Point-to-Multipoint, в которой мы устанавливаем Point-to-Point-соседство со всеми, кто на этом интерфейсе обнаружен. На нашем маленьком роутере обнаружен всего один сосед. И поэтому мы указываем, что на Point-to-Multipoint-интерфейсе у нас обнаружено одно Point-to-Point-соседство. На центральном роутере на Point-to-Multipoint-интерфейсе обнаружено много соседей, поэтому у него будет много Point-to-Point соседств на этом интерфейсе.

У него один интерфейс смотрит на всех сразу. И мы можем начать расковыривать наш пазл с того, что закажем show ip ospf database router self-originate. Мы просим ту самую LSA, которую мы сами придумали. И вот LSA моя, роутерная, показывает, что у нас есть сосед. Link connected to another router в скобочках Point-to-Point соседства. Наша первая LSA смотрит напрямую на первую LSA соседа. И у нас есть Stub Network. Поскольку тип среды Point-to-Multipoint не анонсирует connected сетку, а анонсирует хостовый IP-шник, то здесь показывается, что IP-шник у нас 192.168.0.15 и маска этого IP-шника 255.255.255.255. Используется это для того, чтобы можно было собрать пазл. Когда у нас пазл собирается, дальше нужно по этому пазлу next hop проставить.

И next hop для нашего IP-шника 192.168.0.15, на ваших роутерах должен быть IP-шник 192.168.0.100. Необычная ситуация, потому что мы же все в одной сети, казалось бы. И неестественная ситуация, что мы должны трафик на один IP-шник в сети направлять на другой IP-шник в сети. Но по факту OSPF не знает, что у нас есть unicast-овая полносвязная топология. Он знает, что мультикастовая топология у нас не полносвязная. Он мультикастом может на споуках обнаружить только хаб. И поэтому он говорит, я точно знаю, что Hello-пакеты у нас ходят между нашими споуками и хабами. И делает вывод, что только туда же ходит unicast-овый трафик. Что unicast-овый трафик между споуками не ходит. Он не может ниоткуда узнать, что там на самом деле трафик есть. И поэтому он говорит, окей, я буду строить все маршруты через хаб, через центральный роутер. И по факту, если мы посмотрим таблицу маршрутизации, в таблице маршрутизации у нас на все наши хостовые IP-шники будут добавляться маршруты по 32-й маске.

Show IP Route. Show IP Route OSPF для красоты. И вот они. 192.168.0.1, 3, 5 и так далее. И next hop у них будет центральный роутер. Вообще-то говоря, у нас в DMVPN есть прямая связность между споуками. За это у нас отвечает тот самый протокол NHRP. Поэтому OSPF в этой ситуации ведет себя неэффективно. Мы сказали ему, пожалуйста, построй топологию, кто на кого как смотрит. Он запустил мультикаст, обнаружил соседей. И этот мультикаст обнаружил только одного соседа — центральный роутер. Он сказал, окей, тогда я буду весь трафик посылать через него, потому что через него есть точно связность со всеми остальными. Но если бы он немножечко по-другому себя вел, то мы бы тогда могли получить фазу 2 DMVPN, когда трафик между споуками ходит напрямую. Но для этого нам надо опять же сменить тип среды. Потом это сделаем. Если сейчас наши роутеры каким-то образом будут анонсировать сетки, то сетки, анонсируемые нашими роутерами, будут реплицироваться между роутерами.

И в таблицу маршрутизации каждого роутера NextHop будет добавляться 192.168.0.101. Мы убедимся, что это действительно так, когда сейчас анонсируем что-нибудь дополнительное. Но пока что разбираемся с базой LSDB. Так, возвращаясь к LSA. Есть линк в сторону соседского роутера. Есть линк в сторону IP-шника, который можно добавить в таблицу маршрутизации. Если у нас есть линк в сторону соседнего роутера, можно заказать отображение LSA, соответствующее этому роутеру. Нас интересует роутерная LSA с таким ID-шником. Мы смотрим на соседнюю LSA первого типа, и ID-шник ее нам известен. Прекрасно. Заказываем. Show IP OSPF database router. И вот то, чего нам не хватает. Это LSA центрального роутера. И он сейчас будет нам долго и нудно рассказывать, на кого он какими интерфейсами смотрит.

У него целых 8 соседств, 8 линков указано, поэтому здесь будет много всего. Давайте разбираться. ID-шник LSA, который он придумал, совпадает с его роутер ID. Advertising Router — опять же, он сам про себя придумал, поэтому здесь тоже совпадает. И показывается, что у него есть куча линков в сторону соседей. Они все доступны через один и тот же интерфейс. Поэтому мы на них смотрим по IP-шнику 192.168.0.1. На все соседства у нас этот роутер указывает один и тот же адрес. Потому что это действительно один и тот же туннельный интерфейс. Но мы на этом туннельном интерфейсе указываем кучу Point-to-Point соседств, и у нас действительно пазл будет собираться не так, что все друг на друга смотрят, как через LSA второго типа, а все смотрят на центральный, а он уже смотрит на всех остальных. Если у нас сейчас центральный роутер отваливается, то OSPF здесь, конечно же, поломается.

Показываются ID-шники соседей. В нашем случае ID-шник такой, ID-шник сякой, ID-шник пятый, ID-шник десятый. И они все абсолютно одинаковые. Единственное, что 192.168.0.1 — видимо, OSPF запустился до того, как на лупбеке у нас что-то появилось. И последняя штука. Stub Network про IP-шник, который висит на Point-to-Multipoint интерфейсе. Опять же, анонсируется не connected сетка, анонсируется хостовый IP-шник по 32-й маске. Если мы сейчас добавим, например, loopback интерфейс, он точно так же будет себя вести. Он добавит Stub Network, но обязательно по 32-й маске. Он не будет добавлять connected сетку, потому что на лупбеках анонсируется только хостовый IP-шник. Давайте попробуем с вами сейчас немножко поиграть. Во-первых, давайте добавим loopback.

У нас есть loopback на наших роутерах. Давайте добавим этот loopback в LSA первого типа. Show IP interface brief. Вот у меня loopback 10.15.1.1. Если у вас loopback нет, то сделайте, пожалуйста, на первом роутере. 10, точка номер комплекта, точка дважды номер роутера с 32-й маской. Давайте даже не с 32-й, а с 24-й для красоты сделаем. 10.15.1.1 по 24-й маске у меня. 10.12.1.1 по 24-й маске у 12-го комплекта. 10.1.1.1 у первого комплекта, опять же по 24-й маске. Conf t. Interface loopback 0. Не loopback 9, loopback 0. IP-адрес 10.15.1.1 по маске 255.255.255.0. Я сделал сейчас 24-ю маску, чтобы показать, что на loopback у нас по-прежнему анонсируется не connected сетка, а хостовый IP-шник по умолчанию.

И этот интерфейс добавляем в OSPF. Мне лень писать команду network, поэтому IP OSPF 1 area 0. Я добавил loopback в OSPF, и теперь у меня будет выпущена новая LSA-ка первого типа, которая будет указывать, что у нас появился новый Stub Network. Давайте посмотрим ее. Где у нас self-originate? Раньше был линк на соседний роутер, линк на Stub Network — наш IP-шник на туннельном интерфейсе. И сейчас появился линк на Stub Network на loopback. Обратите, пожалуйста, внимание. Network mask 255.255.255.255. Это показывает нам, что действительно на loopback анонсируется именно connected IP-шник, не connected сетка. Show IP interface loopback 0.

На loopback у нас по 24-й маске. Show IP OSPF route 10.15.1.1. 10.15.1.1. По 32-й маске. Именно потому, что там висит loopback. И у loopback тип среды тоже свой фирменный — loopback. Show IP OSPF interface loopback 0. Тип среды loopback. Анонсируется connected IP-шник, не connected сетка. Если мы хотим заставить Cisco анонсировать именно connected сетку, мы имеем возможность это сделать, прописав волшебный пендель. Но мы должны будем сказать, что network type у нее будет не loopback, а какой-нибудь другой, при котором анонсируется вся сеть целиком. Не connected IP-шник, а connected сетка. Давайте посмотрим, что мы можем прописать.

Не все варианты network type будут доступны на всех типах интерфейсов. На loopback из доступных вариантов будет на самом деле только два. Кажется, что мы можем прописать broadcast, non-broadcast, point-to-point, point-to-multipoint обычный, point-to-multipoint non-broadcast. Loopback, кстати, нет. Loopback прописать нельзя. Если вы попытаетесь network broadcast указать, он скажет, извините, не дам. Если вы попытаетесь point-to-multipoint указать, он скажет, извините, не дам. Единственное, что вам будет доступно, это network point-to-point. Это он принял.

И после того, как мы меняем тип среды на point-to-point, у нас анонсируется connected сетка, а не connected IP-шник. Show IP OSPF interface loopback 0. Тип среды меняется на point-to-point. Анонсируется connected сетка. На этом интерфейсе мы начинаем посылать hello-пакеты. Обычно мы этого не делаем. Но здесь, поскольку тип среды поменяли, он начинает туда посылать hello-пакеты. Никого там не обнаруживает. Таймеры... А что таймеры? Таймер на loopback особо никому не интересует. Да. Никого не обнаруживает. И, как следствие, просто висящий в воздухе интерфейс. Show IP route. Show IP OSPF route. Нам сейчас покажут, что 10.15.1.0 по 24 маске сетка у нас появляется в списке посчитанных маршрутов OSPF. 10.15.1.0 по 24 маске против 10.15.1.1 по 32 маске, который был изначально.

Мы поменяли тип среды на loopback. И у нас начинает анонсироваться сетка по-честному, а не только хостовый IP-шник. IP OSPF database. Router self-originate. Возвращаемся к нашим баранам. Раньше анонсировалось по 255.255.255.255 маске. Сейчас анонсируется по 255.255.255.0 маске. Но топология у нас от этого не меняется. Это всё stub network. Всё про то, что анонсируется соседям. От того, что мы поменяли тип среды, поменялось только указание, какая маска анонсируется в LSA первого типа loopback. В каких случаях вам нужно будет на loopback менять тип среды?

Если вы хотите проэмулировать пользовательскую сетку в лабе и хотите анонсировать именно, допустим, /24 сеть. Не хотите /32, хотите /24, хотите какая connected на интерфейсе висит, такую хотите анонсировать. В этой ситуации вы можете поменять тип среды на point-to-point. Логически, если вы просто возьмёте и несведущему человеку скажете show run interface loopback 0, покажете ему эту вещь — интерфейс туннельный, на нём прописано IP OSPF network point-to-point. Это выглядит бредово. Я согласен с тем, что это выглядит бредово, но поведение по умолчанию на цисках — это то, что тип среды в OSPF на loopback будет loopback. И на loopback анонсируется хостовый IP-шник. Если вы меняете тип среды на point-to-point, от этого ничего не меняется, только анонсируется уже connected-сетка по-честному — какая там на интерфейсе висит, такая анонсируется. Больше никаких изменений нет. Поэтому, если вдруг вы увидите у кого-нибудь в конфиге такую штуку, не пугайтесь. Это не про то, что вы хотите там не выбирать LSA второго типа на loopback.

Нет, это сугубо для того, чтобы управлять тем анонсом, который у вас будет на интерфейсе. Так, это что касалось LSA первого типа. Здесь у нас больше ничего особого нет. Давайте попробуем сделать какие-нибудь ещё LSA, например, LSA второго типа. И для того, чтобы замонстрячить LSA второго типа, я предлагаю сделать отдельно ещё один регион. У нас сейчас все роутеры связаны в нулевом регионе. Я предлагаю сделать LSA второго типа в регионе с каким-нибудь хитрым номером. И каждый из нас выберет сейчас себе номер региона, совпадающий с номером вашего комплекта. У первого комплекта будет номер региона 1, у второго — номер 2, у третьего — номер 3 и так далее. И мы свяжем между собой первый и второй роутеры. И скажем, что первый и второй роутеры будут жить в каком-то ненулевом регионе. Давайте связывать между собой первый и второй роутеры через ненулевой регион.

Номер региона берём с номером комплекта. В моём случае номер комплекта у меня 15-й, и номер региона я тоже сделаю 15-й. Conf t. Интерфейс Ethernet 0/0. Связывает между собой первый и второй роутеры. 12-й субинтерфейс. Там уже есть IP-шники, поэтому мы просто указываем ip ospf 1, номер экземпляра первый, area 15. И на втором роутере делаем аналогичное действие. Заходим на роутер. Enable. Conf t. OSPF. Router OSPF 1. Он у меня там был. И заходим на интерфейс Ethernet 0/0.12. ip ospf 1 area 15. На роутерах в IPv4 OSPF достаточно просто прописать подобную команду. В большинстве ситуаций контекст роутера заводится автоматически.

Контекст router OSPF 1 поднимается сам. Но в моём случае я вижу, что он не поднялся. Поэтому router OSPF 1. Даём волшебный пендель. Так, соседство установилось. И чего-то у нас тут не хватает. Network type mismatch. Надо посмотреть. Do show run interface Ethernet 0/0.12. Здесь у нас просто настройки. Никакие хитрые настройки не даны. А здесь do show run interface 0/0.12. Чего-то не хватает. А, здесь как раз в IPv4 OSPF network point-to-point прописано. Так, я убрал настройку, которая там была, откуда-то она там затесалась.

И сейчас у меня OSPF установился нормально. Показывается, что соседство обнаружено. Никаких предупреждений Cisco не пишет. И у нас установилось соседство через ненулевой регион. Это означает, что наш первый роутер является ABR. И этот ABR перекладывает маршруты, известные в нуле, в ненулевой регион. И поэтому на нашем втором роутере мы сейчас должны видеть пачку LSA-тройек. Кроме того, тип среды по умолчанию на Ethernet-интерфейсах будет broadcast. Поэтому там есть LSA второго типа. И в LSA второго типа мы увидим, что два роутера в ненулевом регионе выпускают LSA первого типа. Связаны между собой они LSA второго типа. И плюс есть куча тройек. Проверяем. Show IP OSPF database. Видим. Две LSA первого типа, как и предсказывалось. Первый и второй роутеры. Связаны между собой LSA второго типа. На Ethernet по умолчанию генерится. И куча тройек.

Всё, что в нулевом регионе было известно, всё перекладывается в LSA-тройки в ненулевой регион. И показывается, кто их придумал. ABR. Если бы у нас было два ABR, по каждой сетке у нас было бы две LSA-тройки. Допустим, сетка 10.1.1.1, выпущенная одним роутером. И каким-нибудь другим ABR. Была бы такая же link ID, но advertising router был бы другой. Мы можем заказать отображение LSA. Show IP OSPF database router self-originate. Смотрим на то, что у нас здесь есть. У нас всего один интерфейс в OSPF, на котором обнаружена LSA второго типа. Как я узнал, что второго типа? Потому что тип соседства — transit network. Значит, есть LSA второго типа. ID LSA второго типа — 10.15.12.1. Он совпадает с IP-шником DR, но это никого не интересует. Show IP OSPF database network 10.15.12.1.

Показывается LSA второго типа. К ней подключен router ID 10.15.1.1. К ней подключен router ID 10.15.2.2. И можем заказать вот это. Router 10.15.1.1. И увидеть второй роутер в топологии, что он действительно связан с той же самой LSA, к которой подключены мы. Он подключен к LSA второго типа с ID 10.15.12.1. Так же, как и мы. Поэтому пазл в регионе у нас собрался. Топологическая информация содержится в LSA первого-второго типа. Все линки, которые мы на соседях обнаруживали, здесь показываются, что они действительно есть. Всё хорошо, всё замечательно. И все сетки, которые будут известны в нулевом регионе, полученные на первом роутере, они были переложены в LSA-тройки. И мы опять же можем заказать их отображение. Show IP OSPF database summary.

Я заказал ID LSA. ID совпадает с IP-шником. 10.1.1.1. Маска. 32-я маска. Метрика. 2001 копейка. Одна копейка на loopback. Тысяча копеек стоит туннельный интерфейс до центрального роутера. Тысяча копеек стоит интерфейс от центрального роутера до меня туннельный. И получается 2001 копейка. Это метрика на роутере R1. Поэтому, когда мы пытаемся добраться до этой сетки, мы сейчас посчитаем кратчайший маршрут до этого ABR. 10.15.1.1. Посчитаем, сколько копеечек стоит добраться до него. И прибавим это к 2001 копейке — просуммированной им стоимости, как он может добраться до удалённой сети. Есть, кстати, команда show ip ospf.

Та же самая команда. Show IP OSPF rib. Здесь показывается, как добраться до каждого роутера. До 10.15.12.2 мы можем добраться сами. Нам ничего не будет стоить, потому что это наш собственный IP-шник. И есть 10.15.12.1. Это сосед, который доступен через интерфейс Ethernet 0/0.12. Мы можем добраться до него за 21 копейку. Почему DR стал 10.15.1.1? Хороший вопрос. Не знаю на самом деле.

Погодите, а где вы это увидели, что DR стал 10.15.1.1? Я нигде этого не видел. ABR стал 10.15.1.1. Или вы имеете в виду, что вот здесь designated router address? Не знаю, честно говоря. В какой-то момент он решил, что должен быть он. После того, как он заявляет, что он будет DR, все с этим соглашаются. Ещё раз подчеркну, это не процедура выборов. Это процедура, где каждый роутер по известным ему данным пытается понять, кто должен стать DR. И если один роутер заявляет, что он уже DR, то второй роутер с этим просто соглашается. В этой ситуации, если бы были полноценные, в кавычках, выборы, то выбраться должен был бы как раз наш второй роутер. Но здесь, видимо, первый заявил, что он будет являться DR, потому что я, например, менял тип среды.

Скорее всего, это связано с тем, что было установлено соседство. Роутер 2 был выбран DR, потом соседство порвалось. DR переехал на другой роутер. И после этого переподнялось соседство. Там уже DR остался первый. Скорее всего, это было так. Я не могу точно утверждать, но скорее всего это было так. Дальше. Наши LSA третьего типа будут обрабатываться в таком дистанс-векторном режиме. Приходят указания, что до сети можно добраться. И все роутеры просто говорят: мы видим, что до сети стоит добраться столько-то копеечек, прибавляем стоимость до ABR и получаем итоговую стоимость. Далее. Давайте свяжем между собой второй и четвёртый роутеры. И сделаем немножечко необычную вещь.

У нас сейчас есть связь между первым и вторым роутером. И эта связь идёт через регион с номером комплекта. В моём случае 15-й. Давайте сделаем связь между вторым и четвёртым роутером в ещё одном регионе. Например, прибавьте 100, и получится в моём случае 115. Указываю conf t. Второй и четвёртый связаны. Интерфейс Ethernet 0/0.24. ip ospf 1 area 115. И на четвёртом роутере аналогичные действия. Enable, conf t. Интерфейс e0/0.24. ip ospf 1 area 115. Я указываю, что эти роутеры должны подружиться.

И они таки подружатся. Router OSPF 1. Запускаю контекст роутера. Почему не дружим? Кто будет дружить? Do show IP OSPF. Они должны будут подружиться. Но они не будут на самом деле дальше перекладывать маршруты. Установлено соседство между вторым и четвёртым. И смотрите, какая у нас сейчас топология. Центральный роутер до первого смотрит нулевым регионом. Между первым и вторым у нас регион 15. Между вторым и четвёртым у нас регион 115. Второй роутер смотрит одним интерфейсом в 15-й регион, а другим интерфейсом в 115-й.

Show IP OSPF interfaces. Есть brief. Это роутер 2. У него есть один интерфейс в 15-м регионе, другой интерфейс в 115-м. Сказал между вторым и третьим, ошибся — между вторым и четвёртым. Второй и третий у нас на диаграмме не соединены. У нас есть связь между вторым и четвёртым. Прошу прощения, если вас запутал. Да, второй и четвёртый. И получается, что этот роутер действительно смотрит в два региона, но он при этом не является ABR. Вот это интересный момент. Он не смотрит в нулевой регион, поэтому он ABR не является. И он поэтому не перекладывает маршруты из 15-го региона в 115-й. Поэтому на четвёртом роутере у нас сейчас маршрутов никаких особо не будет в OSPF. Show IP route. OSPF есть, а маршрутов нет.

На втором роутере маршруты есть, всё хорошо. А на четвёртом нет. И даже если мы сейчас на втором роутере скажем, что у нас есть интерфейс loopback 0. Conf t. Интерфейс loopback 0. ip ospf 1 area 0. Искусственно поднимем нулевой регион. Искусственно заставим этот роутер быть ABR. Он у нас на самом деле всё равно не будет перекладывать маршруты. Он из 15-го региона в 115-й тройки перекладывать не будет. Те маршруты, которые в нулевом регионе будут зарождаться, он, конечно, будет перекладывать, но таких маршрутов не так много. Поэтому после того, как я сделал искусственный интерфейс в нулевом регионе на втором роутере, у нас появится только парочка несчастных маршрутов и больше ничего. Хочется, конечно же, большего. Хочется сделать так, чтобы все маршруты на четвёртый роутер пришли. Но для этого нам надо каким-то образом второй роутер заставить перекладывать маршруты, полученные через тройку в одном ненулевом регионе, в другой.

А как мы это можем сделать? Никак. Но зато можно сделать так, чтобы у нас реплицировалась база нулевого региона. Давайте поднимать Virtual Link. С Virtual Link, правда, надо будет немножко подождать. Нам надо будет еще теорию пройти. Давайте сейчас переключимся на теорию, а потом после нее сделаем Virtual Link. Пока отложим Virtual Link, потом сделаем, и сделаем чего-нибудь еще. У нас, например, на слайдах был NSSA. Мы можем какой-нибудь регион объявить нестандартным регионом и сделать так, чтобы в него не вкладывались некоторые маршруты. И нам нужно будет, чтобы у нас эти маршруты где-то зародились. Поэтому я иду на центральный роутер и вкладываю внешний маршрут. Show IP route. Здесь что-нибудь наверняка будет, да?

Что можно положить. Туннельный интерфейс, loopback. Loopback нам нужен для того, чтобы оно работало. Loopback 0 есть. Замечательный. Нет, нехорошо, нехорошо, нехорошо. Нам сейчас понадобится одна штука, которую мы на слайдах не прошли. Я как-то ускакал быстро в сторону лабы. Нужно было, конечно, этот слайд сначала прочитать, а только потом уже переключаться на лабу. Это будет рассказ про редистрибуцию. Про то, что можно взять какие-то маршруты, которые у вас в таблице маршрутизации есть, и положить их в OSPF. Можно взять connected, статики, динамические какие-то маршруты, BGP, RIP,

то, что мы с вами прошли, и положить их в таблицу топологии OSPF. Причем OSPF поддерживает работу с несколькими VRF в цисках, поэтому вы можете взять и положить маршруты определенного VRF только в таблицу OSPF. По умолчанию маршруты, которые вы выбрасываете в OSPF, получают метрику E2 типа, и значение метрики будет 20. Можно указать и тип, и значение метрики, либо явно, либо через route-map. Вы привычным уже способом указываете команду redistribute, чего редистрибьютим. Например, redistribute connected, redistribute static, redistribute EIGRP, redistribute BGP. И можете указать сразу же метрику. Например, здесь у нас redistribute static, дальше metric 10, metric-type 1. Можно даже и метку задать. Для LSA пятёрок у нас есть действительно поле для метки.

И потом на эти метки можно каким-то образом ориентироваться. Вы эти пятёрки можете еще раскрасить. И потом route-map отбирать маршруты-пятёрки, только покрашенные в определенный цвет. Но очень важный нюанс. Cisco всегда, как обычно, идет своим путем. И если вы не укажете волшебное слово subnets, то у вас будут импортироваться только классовые сети. Если вы думаете, что наступил 2018 год, 21 век, нет, не наступил. Cisco по-прежнему живет в классовом мире. Если вы хотите сказать, что надо импортировать не только классовые сети, но и подсети с масками неклассовыми, то, пожалуйста, не забывайте это слово. Subnets, subnets, subnets, subnets. Фактически это обязательное слово, которое вы обязательно должны будете указывать каждый раз, когда указываете redistribute в OSPF. Вероятность того, что вы захотите классовые сети вбросить, она околонулевая. Я бы сказал нулевая. Поэтому это слово просто в обязательном порядке всегда указывайте.

Redistribute connected subnets. Redistribute static subnets, redistribute EIGRP 1 subnets. Если указываете в явном виде метрику и metric-type, то хорошо. Если не хотите указывать в явном виде, можете воспользоваться тем, что метрика по умолчанию будет второго типа. И в принципе для большинства задач этого достаточно. И можно указать default metric. Так же как в EIGRP, так же как в RIP, default metric указывает для новых маршрутов, какая seed metric, стартовая метрика для свежевброшенных пятёрок у вас будет. А если хотите, можете назначать с помощью route-map метрики для отдельных маршрутов. И route-map может ориентироваться на свойства редистрибьюченного маршрута для того, чтобы проставить метрики или типы метрик в зависимости от содержимого маршрута. Можно на метрики ориентироваться, можно ориентироваться на свойства маршрута, можно ориентироваться на метки, если они есть.

Например, в EIGRP они действительно есть, и вы можете на них ориентироваться. Если вы хотите использовать route-map, route-map умеет permit-ить или не permit-ить маршруты. Поэтому, если вы хотите взять какие-то маршруты, полученные из определенного источника, и вбросить их в OSPF по условию, то OSPF вам это позволяет сделать через route-map. Те маршруты, которые вы хотите пропустить в OSPF, вы permit-ите. Те маршруты, которые вы не хотите пропустить в OSPF, вы не permit-ите. И здесь у нас наш любимый пример с тремя маршрутами с разными тегами. У нас есть маршрут с тегом 1, с тегом 2 и с тегом 3. И первый блок route-map указывает на то, что мы отбираем маршруты с тегом 1, проставляем им метрику 10 первого типа. Дальше второй блок указывает на то, что все остальные маршруты мы пропускаем через второй блок и говорим, матчим тег 2 и просто их пропускаем.

Метрика у нас в явном виде не указывается. Это значит, что метрика будет E2 20. И все остальные маршруты, которые не имеют тега 1 либо тега 2, мы не матчим, мы их не permit-им, и они у нас по факту отбрасываются. Поэтому этот маршрут мы permit-им, этот маршрут мы permit-им, этот маршрут мы не permit-им. И указываем redistribute static, что забираем из таблицы маршрутизации, какие маршруты, и указываем, через какой route-map их пропустить. Route-map static to OSPF. В таблице маршрутизации у нас маршруты эти будут появляться на всех роутерах, и в таблице топологии тоже. Видим, что show ip OSPF database показывает нам две пятёрки. Пятёрка с ID-шником 10.0.1.1, с 10.0.2.2. В оглавлении не видно масок, но тем не менее мы понимаем, что это маски на самом деле /32 в одном и в другом случае. Кто придумал их? ASBR.

ID. И показывается метка. Метка у нас сохраняется. Если вы хотите, вы можете поменять. Вы указываете set, допустим, tag 10. И тогда у вас метка будет действительно 10. Но по умолчанию она сохраняется. В таблице маршрутизации маршруты, которые получают метрику первого типа, будут показываться буковкой E1. И у них, если маршрут метрики E1 типа, то метрика, указанная в LSA пятёрке, и метрика forward metric складываются. Они получены по одной и той же методологии, поэтому их можно складывать. У нас получается 10, которые прописаны в LSA, плюс один forward metric, складываем, получаем 11. Для E2 маршрутов метрика, указанная в LSA, и метрика forward metric, то есть транспортная метрика внутри OSPF до ASBR,

получены по разным методикам, складывать их нельзя, и метрика в LSA указана всегда больше. Поэтому мы здесь будем видеть 20, потому что редистрибьюченная метрика второго типа в таблицу маршрутизации ставится без указания на forward metric. Но если мы закажем отдельно этот маршрут, то там будет видно, что forward metric отдельно есть. Если мы хотим дополнительно как-то зафильтровать маршруты, которые мы получаем или отправляем в процесс OSPF, здесь есть небольшие особенности. Когда мы смотрели на ограничение маршрутов в RIP и в EIGRP, мы нагло пользовались тем, что это протоколы дистанц-векторные, поэтому, когда мы принимаем какие-то маршруты, мы просто пропускаем эти маршруты через фильтр и говорим, эти маршруты прошли, эти маршруты не прошли, всё хорошо, всё замечательно. Когда мы работаем с OSPF, у нас есть проблема. OSPF не оперирует термином маршрут.

Маршрут у него является вторичным свойством по сравнению с первичной штукой, с LSA. Поэтому OSPF будет оперировать LSA, а не отдельными маршрутами. Когда к нам какой-то маршрутизатор-сосед присылает LSA, мы не можем сказать, мы эту LSA не хотим видеть, мы хотим ее игнорировать, мы обязаны ее принять, поэтому фильтровать трафик на входе и на выходе нельзя. Вы не можете фильтровать ничего, что вы получаете от соседей. Вы от соседей получаете LSA, и вы обязаны их принять. Вы не имеете возможности, вы не имеете права фильтровать отдельные LSA. Единственное, что вы можете сделать, это если вы придумываете LSA, в ней чего-нибудь не писать. Например, если вы ABR, вы можете просуммировать мелкие сетки, которые получены в одном регионе, и наружу отправить суммарный маршрут. Вы не отправляете мелкие сетки в регионы, никто в регионе не знает про то, что эти мелкие сетки существуют. Вы про это просто не говорите. Но если вам кто-то отправляет LSA, вы ее обязаны принять. И вы ее обязаны посчитать,

включить в топологию, если это LSA первого, второго типа, либо просчитать кратчайшие маршруты до сеток, полученных через LSA первого, третьего или пятого типов. Но Cisco всё-таки предлагает реализовать механизм, который будет позволять фильтровать кое-что в OSPF. Фактически вам будет доступно два типа фильтрации, которые вы можете назначить. Первый тип фильтрации — это если вы редистрибьютите маршруты в OSPF из таблицы маршрутизации. У вас в таблице маршрутизации есть, например, BGP-шные маршруты. Вы говорите, перекладываем BGP-шные маршруты в OSPF. В этой ситуации вы можете фильтровать эти маршруты, потому что они действительно работают на уровне отдельных маршрутов. Вы пропускаете всё, что идет из таблицы маршрутизации в ваш OSPF через фильтр, и LSA-ки пятёрки вы генерируете не на все маршруты, которые в таблице маршрутизации были, а только на некоторые. Для этого будет использоваться стандартный наш способ — distribute list. Дальше вы указываете направление, откуда фильтруем.

Дальше либо access list, либо prefix list. Out BGP, и дальше там out EIGRP, out RIP. Из таблицы маршрутизации мы указываем, какие маршруты мы забираем в OSPF. Out — значит, из таблицы маршрутизации. Если вы хотите фильтровать какие-то маршруты на вход, то вы, еще раз подчеркну, не можете фильтровать отдельные апдейты, которые к вам приходят, потому что этих апдейтов нет, вам присылают LSA-ки. Маршруты порождаются только после того, как OSPF эти маршруты посчитал. Они не передаются по сети, они передаются в виде LSA-ек. OSPF эти LSA-ки принимает, считает кратчайшие маршруты, после чего маршруты здесь порождаются, и они могут быть вброшены в таблицу маршрутизации. На этапе вброса в таблицу маршрутизации вы можете запретить принимать маршруты в таблицу маршрутизации. И вы указываете distribute list, дальше вешаете access list на вход, in. Это значит, что вы в таблицу маршрутизации маршрут не принимаете. OSPF посчитал,

нашел next hop, нашел кратчайший маршрут, нашел метрику, попытался вставить в таблицу маршрутизации, таблица маршрутизации говорит, не буду вставлять. Как будто там уже что-то есть. Она просто отказывается это принимать. Distribute list работает на самом деле не с OSPF, она настраивается в контексте config router, но на самом деле она работает с таблицей маршрутизации. Мы говорим, мы не будем принимать в таблицу маршрутизации маршруты OSPF-овские, потому что они нам не нравятся, они фильтр не прошли. Это нельзя сделать в OSPF, вы не можете в OSPF сказать, не надо считать маршрут до Васи. Вы можете сказать, посчитай маршрут до Васи, попытайся вбросить его в таблицу маршрутизации И обломайся с инкапсуляцией. После того, как вы зафильтровали какие-то маршруты, полученные из внешнего источника, на входе в OSPF, вы эти маршруты дальше никому не рассказываете. Но есть нюанс. Когда мы, например, в RIP — давайте здесь представим, что у нас здесь RIP — вы принимаете какой-то маршрут в RIP.

Вы дальше говорите, окей, у нас есть RIP-овский маршрут, мы его перекладываем в таблицу маршрутизации, забираем из таблицы маршрутизации и анонсируем другим соседям. Мы не можем анонсировать то, чего нет в таблице маршрутизации, поэтому фактически маршруты приходят в таблицу маршрутизации и уходят из таблицы маршрутизации. Но в OSPF мы работаем не на уровне отдельных маршрутов, поэтому вполне может быть такое, что сосед прислал вам LSA, в этой LSA было написано, у меня есть connected сетка в сторону Васи. OSPF говорит, я вижу, что существует сетка Васи, считает до неё кратчайший маршрут, пытается вбросить этот маршрут в таблицу маршрутизации, таблица маршрутизации говорит, не буду принимать. И дальше вы рассказываете эту LSA своим соседям. В RIP и в EIGRP, в протоколах дистанц-векторных, вы не можете анонсировать то, чего у вас нет в таблице маршрутизации. Если вы на этапе вброса в таблицу маршрутизации что-то зафильтровали, то у вас это анонсироваться не может, потому что этого у вас нет.

В OSPF вы будете продолжать анонсировать LSA с маршрутами, которых у вас нет в таблице маршрутизации. И это очень опасная штука, потому что вы говорите, что через меня можно добраться до какой-то сети, потому что кто-то говорит, у меня есть сетка А. Он присылает LSA, что у меня есть connected сетка А. Вы говорите, я смотрю на того, кто нам прислал такую сетку. Дальше вы говорите, я смотрю на другой роутер, который есть у меня в таблице соседей. Но в таблицу маршрутизации вы сетку А не вносите, потому что вы её зафильтровали. Сосед про то, что вы что-то зафильтровали, не знает. Он говорит, я NextHop до сетки А вижу, что это должен быть ваш роутер. И весь трафик он будет посылать нам. А дальше мы будем его блэкхолить, потому что мы не знаем, куда его девать. Поэтому будьте очень аккуратны, когда вы фильтруете какие-то маршруты в OSPF. Поведение может быть неожиданным, если вы не совсем хорошо понимаете, как эта штука работает.

Поэтому поведение OSPF отличается от поведения EIGRP и RIP. Аккуратнее будьте с фильтрацией маршрутов. Если хотите фильтровать маршруты, можно фильтровать маршруты, которые приходят из другого протокола через таблицу маршрутизации в OSPF. И это считается не приходящими, а исходящими из таблицы маршрутизации маршрутами, поэтому они помечаются словом OUT. OUT можно фильтровать только маршруты, которые вы редистрибьютите в OSPF. В RIP или в EIGRP вы через OUT можете также контролировать апдейты до соседей. Здесь OUT — это только для редистрибуции. И IN — это маршруты, которые вы посчитали в OSPF и пытаетесь вложить в таблицу маршрутизации. Можно просто сказать, не принимаем такие маршруты по определённым IP-адресам или маскам. Или можно сказать, что нас интересует, чтобы маршруты, у которых OSPF посчитал next-hop-ом какого-то конкретного соседа, не вбрасывались в таблицу маршрутизации.

Вы тогда префиксом можете отобрать только тех соседей, которые имеют право присылать определённые маршруты. Но в любом случае будьте предельно осторожны, когда вы это делаете. Что-то пойти не так может здесь очень легко. Вопрос поступил. Фильтровать лучше на всех роутерах, чтобы никто не вбрасывал в RIB. Если вы хотите что-то зафильтровать и хотите сделать это хорошо, лучше всего просто не вбрасывать в сами LSA информацию о какой-то сети, которой у вас в таблице маршрутизации роутеров быть не должно. Лучше всего не допускать появления маршрутов в самом OSPF, в самой LSDB до каких-то сетей. И вам в этом случае не придётся фильтровать какие-то маршруты в таблицу маршрутизации. Но если уж вы это делаете, то делайте по крайней мере это аккуратно, чтобы не получилось так, что маршруты будут построены через вас, потому что маршруты строятся по LSA, а LSA вы в обязательном порядке распространяете все.

А дальше, когда пакеты по этим маршрутам до вас приходят, вы эти пакеты будете обрабатывать уже по таблице маршрутизации, и у вас там может соответствующего маршрута не быть, потому что вы его зафильтровали. Такое поведение вполне возможно. И чаще всего проблемы с OSPF при фильтрации маршрутов возникают именно с этим, что у вас транзитный роутер, соседи не знают, что вы что-то зафильтровали, соседи думают, что у вас всё хорошо, они вам трафик присылают, а вы этот трафик выкидываете, потому что не знаете, куда его девать. Это типичная ошибка при фильтрации маршрутов в OSPF. Дальше. Если вы хотите рассказывать про какие-то конкретные маршруты, полученные из внешних источников, вы лучше будете не порождать соответствующие пятёрки. И тогда вы просто через route-map прогоняете маршруты или через distribute list out прогоняете определённые маршруты и не порождаете пятёрки, которые вам не нравятся.

После того, как пятёрки распространяются по всей сети, все роутеры должны будут иметь в таблице маршрутизации до них маршрут. Если вы хотите, чтобы какие-то отдельные маршрутизаторы не имели маршрутов до пятёрок, единственное, что вы можете с этим сделать, — это сказать, что в определённый регион мы не хотим вбрасывать пятёрки, поэтому объявляем этот регион stub. А если вы хотите ограничить распространение маршрутов до каких-то сетей, которые нативны для OSPF, то в этом случае вы можете воспользоваться суммаризацией или агрегацией маршрутов. При работе OSPF внутри региона мы нигде ничего наврать и ничего зафильтровать не можем. Или только таким варварским способом, когда мы на этапе вброса в таблицу маршрутизации что-то делаем, но так делать не нужно. А ABR при перекладывании маршрутов между регионами имеет возможность немножко поднаврать. И типичный сценарий, где он может поднаврать, — это использовать команду суммаризации, area range. У неё немножко странный синтаксис.

Давайте разберёмся, как она будет работать. Если у нас есть несколько мелких сетей в каком-то регионе, мы видим, что у нас здесь есть сетки 10.0.1.0, 10.0.2.0. В нулевом регионе. Мы хотим сделать так, чтобы в остальные регионы у нас анонсировалась суммарка. В этом случае мы указываем в настройке роутера OSPF, из какого региона мы забираем мелкие сетки. В нашем случае из нулевого региона. И дальше указываем сетку-суммарку, которую мы анонсируем во все остальные регионы. Поэтому во все остальные регионы — в первый, во второй, в десятый, в двадцатый — мы вместо кучи мелочёвки будем анонсировать эту десятку. 10.0.0.0 по /16 маске. Фактически, когда мы указываем команду area чего-то range чего-то, мы говорим: сети этого диапазона range снаружи региона X видны как единая большая сеть. Очень часто люди думают, что здесь надо работать в такой дистанц-векторной логике, как в EIGRP или в RIP мы писали.

Напомню, как в RIP мы суммарки делали. Мы заходили на интерфейс, в котором мы смотрим на соседа, и говорили, в сторону этого соседа надо посылать суммарку. Здесь надо не в сторону соседа посылать суммарку, а из региона забирать сразу уже готовую суммарку. И вы указываете area 0, range чего-то. И во все регионы сразу ваш ABR будет перекладывать сетку именно суммарку. Если вы хотите из первого региона забрать что-то и выложить это наружу, то в этой ситуации вы указываете в обратную сторону: area 1, range чего-то. И тогда в нуле будет порождаться сетка-суммарка. В таблице маршрутизации у вас будет добавляться виртуальный маршрут. Так же, как и всегда, когда у нас есть дистанц-векторное поведение: если мы анонсируем что-то, чего раньше не было, то мы должны хотя бы виртуальный маршрут создать, чтобы, если вдруг трафик придёт до этой сети, было понятно, что с ним делать.

Если вы говорите, что у вас есть сетка 10.0.1.0, 10.0.2.0, при этом все остальные сети 10.0.0.0/16 у вас по факту в таблице маршрутизации отсутствуют, вы добавляете при анонсе 10.0.0.0/16 виртуальный маршрут 10.0.0.0/16 в сторону интерфейса Null0. Если вдруг трафик придёт до сети 10.0.3.0, 10.0.4.0, вы его выбросите. Это происходит потому, что вы заявляете, что вы знаете всю сетку, и если кто-то вам верит, что трафик до определённой сети можно через вас доставить до удалённой сети, вы не должны будете с этим трафиком ничего делать. Вы не должны, в частности, его отправлять, например, по маршруту по умолчанию, потому что может сложиться ситуация, при которой у вас маршрут по умолчанию смотрит через соседа, а дальше вы говорите, я знаю, как добраться до какой-то суммарной сети. И этот роутер говорит, да, все сетки в мире доступны там, но все 10.0.0.0/16 доступны через него.

И он посылает эти пакеты вам, потому что он думает, что маршрут есть. А вы говорите, я его буду обрабатывать по умолчанию и направляете на соседний роутер. У вас получается петля. Чтобы такой петли не было, добавляется виртуальный discard-интерфейс — 10.0.0.0/16 в сторону интерфейса Null0. Эта штука называется discard route. Поведение по умолчанию — RFC 1583 в Cisco IOS. Метрика агрегата — наименьшая метрика компонентов. Можно переключить, можно сказать, что Cisco не должна работать по RFC 1583. Она должна работать по RFC 2328. И вы указываете no RFC 1583 compatibility. И тогда у вас метрика будет считаться наибольшей, как это предписывает делать стандарт актуальной редакции 2328. Ещё раз хочу подчеркнуть важный момент, на котором все делают ошибку.

Это синтаксис команды. Откуда забираем маршруты и во что эти маршруты превращаются снаружи. Area 0 указывает: из нуля забираем отдельные мелкие сетки, изученные по LSA 1-го или 3-го типов. И анонсируем их во все остальные регионы через суммарку, которую мы указываем в явном виде через range. Если вы из нуля забираете, то area 0. Если вы из первого региона забираете, то суммируем всё это дело в нуле в виде LSA 3-го типа, а потом эта LSA 3-го типа анонсируется во все остальные регионы. Если у нас есть маршруты-пятёрки, их тоже можно суммировать, но суммируются они уже немножко другой командой. Если мы тройки суммируем командой area чего-то range, то пятёрки суммируются командой summary-address. Мы указываем в настройке роутера summary-address и дальше указываем диапазон, в котором будем выпускать LSA 5 вместо кучи мелочёвки, которая у нас из внешнего мира приходит при редистрибуции.

Опять же, хотя бы один компонент у вас должен быть для того, чтобы эта пятёрка порождалась. Так же, как и тройки. Вы будете порождать суммарку только если у вас есть хотя бы один IP-адрес, который в таблице маршрутизации есть из этого диапазона. Метрика здесь уже либо задаётся в явном виде, через default metric, либо вы можете командой distribute list route-map out указать, каким образом вы будете отправлять маршруты с какой метрикой. Но точно так же, как и в случае с LSA-тройками, если вы придумываете какой-то маршрут, которого у вас по факту нет, то вы добавляете виртуальный интерфейс для отброса трафика, который приходит на ваш роутер, на IP-адреса, которых у вас на самом деле в таблице маршрутизации нет. Summary-address, IP-адрес и прямая маска. Не wildcard, а прямая, потому что это именно сетка, префикс, который у вас есть в таблице.

Делать это можно только на ASBR, это указывает, какие вы LSA-пятёрки будете порождать. Когда вы указываете summary-address, дальше указываете какую-то большую сетку, это будет означать, что вместо кучи мелочёвки именно вы вбрасываете одну большую LSA-пятёрку. Бесполезно эту команду делать где-либо ещё. После того, как вы выпустили LSA-пятёрку, эта LSA в неизменном виде распространяется на все роутеры. И сказать в какой-то момент, что некоторые LSA-пятёрки надо пропустить, некоторые LSA-пятёрки пропустить не надо, в OSPF нельзя. Давайте попробуем с вами понастраивать редистрибуцию и убедимся, что действительно это работает каким-то образом. У меня есть, например, первый роутер. И на этом роутере у нас есть три интерфейса, смотрящие в OSPF. Один интерфейс туннельный, второй интерфейс — loopback, на котором мы как раз тренировались менять тип среды, это loopback нулевой, и третий интерфейс, которым первый и второй роутеры соединены между собой.

Туннель и Ethernet 0/0/12 мы сейчас трогать не будем, а вот loopback мы сейчас немножко поменяем. Мы уберём с него, с loopback на первом роутере, указание, что он будет работать в OSPF.