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

Немножко отвалилась запись, пардон. Мы продолжаем настраивать наш OSPF. Мы сейчас снимаем с loopback наше указание, что loopback работает в OSPF. Сейчас show run interface loopback 0 — сейчас на нём стоит команда ip ospf 1 area 0. Я сейчас её уберу, и у меня этот интерфейс из loopback из OSPF пропадёт. Интерфейс loopback 0 — no ip ospf 1 area 0. Я убрал loopback, и теперь он больше не известен во всей остальной сети. Я хочу, чтобы этот маршрут был известен, но я хочу, чтобы он был известен через внешнюю, через LSA пятого типа. Поэтому я сейчас предлагаю сделать route-map, который будет отбирать только исключительно

IP-шник этого самого loopback, будет его permit'ить и будет выбрасывать с какой-нибудь хитрой метрикой. Route-map будет достаточно простенький, и будет он ссылаться на, например, IP-шник 10.15.1.1, подсеть 10.15.1.0/24. Это именно наша connected-сетка на этом loopback. Создаём какой-то механизм, которым мы можем отобрать такие префиксы. Я предлагаю, например, взять ip prefix-list loopback permit 10.15.1.0/24. Такой prefix-list отберёт один единственный префикс 10.15.1.0/24, ни в коем случае не его компоненты. И этот один единственный префикс нам нужно будет сейчас заматчить в route-map. Route-map —

я вот так назову — указываем match ip address prefix-list loopback. Простенький route-map, который будет матчить IP-шники в проходящих префиксах по prefix- list loopback, будет сравнивать с 10.15.1.0/24, и если такой префикс у нас встретится, мы над ним немножко поиздеваемся. Set metric — не знаю, какую кривую поставим — давайте 30. Metric type 1. Type 1. Мы указали, что у нас маршрут на loopback разрешается, мы указали, что он будет иметь метрику первого типа, и метрика у него будет 30. Ничего остального мы больше матчить не будем и

permit'ить тоже не будем. Из всех connected-сеток через такой route-map пройдёт только один единственный префикс на loopback. И теперь этот route-map можно будет приклеить к redistribution в OSPF. Router OSPF 1. Redistribute connected — не забываем — route-map connected_to_ospf. Redistribute connected route-map connected_to_ospf. Эта команда берёт все connected-маршруты, которые у нас есть в таблице маршрутизации, — их много тут, — дальше она их прогоняет через route-map, и соответственно те маршруты, на которые route-map сказал «да», она пропускает в OSPF в виде LSA пятёрки первого типа с метрикой 30. В

таблицах топологии у нас сейчас должны появиться новые пятёрки. Я думаю, что даже вы, наверное, какие-то пятёрки уже успели породить. Проверим, что действительно они есть. Show ip ospf database external — все пятёрки, которые есть. Первая пятёрка — видимо, третий комплект — 10.3.1.0/24, метрика 20, тип 1, всё хорошо. Четвёртый комплект — метрика 30, первого типа, всё правильно. Двенадцатый комплект — 24 маска, тип 1, метрика 30. И моя тоже метрика 30. Некоторое количество LSA у нас прибежало, и эти LSA будут обрабатываться в таблице маршрутизации. Show ip route — давайте сделаем route ospf. У нас маршруты, полученные по LSA пятёркам, показываются с буковкой E. E1 — это LSA пятёрки первого типа, у нас они

все такие. И соответственно есть ещё E2 — это метрики второго типа. И показывается, что до этих маршрутов метрика складывается: forward-метрика до ASBR — там порядка 2000 — и соответственно то, что написано в LSA, метрика даётся и складывается вместе с этим. Последнюю команду повторить легко. Section — вот она такая. Давайте в чат я кину. И нам ещё понадобится show run section. Вот такой route-map. И нам ещё понадобится вот этот товарищ. Loopback prefix-list. Мы сделали prefix-list, который матчит только одну единственную строчку

в таблице маршрутизации. Мы пропустили все маршруты через route-map, который отсылает к этому самому prefix-list, и всё, на что prefix-list сказал «да», мы проштамповали метрикой 30 первого типа, ну или 20, кому как. И получается, что маршруты, которые в LSA пятёрках приходят, они помечаются буковками E1 и E2. Давайте ещё раз посмотрим — может, уже что-то прибежало новенькое. Вот так. Нет, пока четыре маршрута есть плюс ещё один мой. OSPF database. Type 5. Чтобы здесь LSA соответствующие порождались. Я вижу, кстати, что здесь ещё новенькие прибежали — 10.1.1.0, раньше не было. Ну, только её не было.

Мы видим, что шесть LSA пятёрок у нас есть: одна из них моя, пять ваших. У нас есть пятёрки, эти пятёрки порождаются нашими роутерами — берутся loopback'и из роутеров первых и анонсируются в виде пятёрок при redistribution connected-сетей в OSPF. И мы при этом ещё сделали дополнительно фильтрацию с помощью route-map. А если бы мы не использовали route-map, мы могли бы фильтровать distribute-list'ом. Можно было бы сказать, что в таблице маршрутизации у нас есть connected-сетки, но мы просто говорим redistribute connected, а дальше говорим, что при redistribution прогоняем все потенциальные маршруты через prefix-list и пропускаем только те маршруты, на которые prefix-list скажет «да». Это два разных механизма. Route-map работает скорее со стороны OSPF — OSPF забирает только интересующие маршруты. А distribute-list скорее работает с таблицей маршрутизации —

это то, что таблица маршрутизации способна отдать в OSPF. Эти два механизма могут оба одновременно работать. Route-map говорит, что OSPF забирает. Distribute-list говорит, что таблица маршрутизации отдаёт. Настраиваются они при этом все в контексте OSPF, в одном и том же месте — router OSPF 1, и соответственно здесь distribute-list указывает на то, какие маршруты таблица маршрутизации отдаст нам для работы в OSPF. Давайте попробуем зафильтровать что-нибудь в сторону таблицы. Сейчас у нас есть — show ip route OSPF — сейчас у нас есть маршруты, например, 192.168.0.101,

0.203, 0.204, 0.205 по 32 маске. Давайте сделаем следующую штуку: скажем, что этих маршрутов в таблице маршрутизации у нас быть не должно. Что вместо них нам нужно иметь только маршруты, которые начинаются на десятку. Маршруты, которые начинаются на 192.168, в таблице маршрутизации у нас не должны появляться. Это может привести к очень забавным последствиям, правда, потом, но тем не менее мы сейчас это сделаем и скажем, что из посчитанных OSPF маршрутов в таблицу маршрутизации не имеют шанса пробиться маршруты до IP-шников, начинающихся на 192.168. И мы для этого сделаем новый prefix-list. Ip prefix-list no_192 — скажем — соответственно permit 192.168.0.0/16 le 32. Внимание, я сказал сейчас, что я permit'ю 192.168.0.0/16 le 32,

любой из этих маршрутов под такой list попадёт, и он будет именно что запермичен. Не обязательно, что если мы сделаем что-то, что будет иметь слово permit, то с этим что-то дальше хорошее произойдёт. Мы сейчас скажем... Нам нужен distribute-list, мы хотим distribute-list. Route-map тоже может работать. Ладно, идея была красивая — мне пришла в голову мысль, что если бы мы это в route-map матчили, то могли бы сказать, что в route-map мы не говорим permit на маршруты, которые удовлетворяют этому самому prefix-list. Но я сейчас подумал, что это будет уже слишком чересчур, если мы сейчас сделаем ещё один route-map. Поэтому давайте сделаем точно такой же prefix- list, но не permit, а deny. У него будет le 32, что означает: мы говорим deny только на маршруты, у которых

маска 32 или меньше. В IPv4 больше чем 32 быть не может, поэтому она в точности будет равна 32 — вот они, маршруты по 32 маске. Поэтому сейчас скажу, что у нас этот prefix-list — я неправильно сделал — потом сделаю то же самое, но скажу deny на IP-шники 192.168.0.0/16 ge 32, а потом скажу, что в этом же prefix-list permit'ю вообще все остальные маршруты — 0.0.0.0/0 le 32. Промахнулся. Show ip prefix-list no_192. Обратите внимание на то, как у меня этот prefix-list выглядит. Он сначала говорит «нет» на

сетки 192.168.0.0 по 32 маске, а потом он говорит «да» на все остальные сетки — 0.0.0.0/0 le 32. Это permit на все маршруты. Сейчас я через этот prefix-list прогоню маршруты, которые OSPF посчитал и пытается бросить в таблицу маршрутизации, и мы посмотрим, что OSPF после этого не сможет выбрасывать эти маршруты. И покажет нам только вот это. Distribute-list — дальше указываем, через что пропускать маршруты — prefix no_192. Дальше указываем, в каком направлении мы хотим фильтровать наши маршруты. Здесь либо in, либо out, но это считается по отношению к таблице маршрутизации. Если мы в таблицу маршрутизации не хотим принимать определённые маршруты, то мы говорим: мы фильтруем на вход.

И можно сказать, через какой интерфейс маршруты были получены, но нас сейчас это не сильно интересует. Если вы здесь указываете интерфейс, то вы на самом деле говорите: в таблицу маршрутизации не принимать маршруты, которые OSPF посчитал и у которых next hop — один из этих интерфейсов. Я указываю просто prefix на вход и тем самым говорю, что в таблицу маршрутизации мы не будем добавлять маршруты с IP-шниками 192.168.0.0 по 32 маске. Проверяем, что у нас получается. Show ip route. Вуаля — маршруты пропали. Мы таким образом зафильтровали маршруты и сделали так, что у нас трафик до этих сетей соответственно может ходить. Обратите внимание на забавный момент: 192.168.0.101 — у нас маршрут как бы до него есть, потому что он connected, и

DMVPN ответственен за его резолвинг, мы знаем, как до него добраться. Если мы сейчас захотим попинговать его — ping 168.0.101 — у нас пинг будет именно благодаря DMVPN, в котором есть полная связность. Но если бы вдруг у нас OSPF притащил бы какой-то маршрут и сказал, что next hop будет не 192.168.0.101, а, например, 0.1 — какой-нибудь другой роутер, такой же spoke, — и у нас DMVPN работал бы в фазе 2, ну или даже не DMVPN был бы, а какой-нибудь Frame Relay, условно говоря, то соответственно мы такой маршрут в таблицу маршрутизации уже поставить бы не смогли. Мы бы не знали, как добраться до таких IP-шников, и DMVPN у нас бы сломался. Так. Кстати, я вижу, что пятый роутер пришёл — пятый маршрут у нас 10.5.1.0/24, у него маршрут до loopback есть, этот loopback нативный. Надо сделать так, чтобы с этого интерфейса

OSPF убрался, и тогда он, возможно, будет вбрасываться в таблицу в виде LSA пятёрки. Наша задача сейчас — зафильтровать какие-то маршруты — она решена. Действительно, маршруты у нас убрались из таблицы маршрутизации. В OSPF они всё равно есть. Show ip OSPF route — команда, которая подсчитывает кратчайшие маршруты в OSPF и показывает их перед тем, как сбросить таблице маршрутизации. Она показывает, что эти маршруты есть, вот они, а вот напротив них галочки нету. Это означает, что в таблицу маршрутизации они действительно не были вброшены — что-то помешало. Вот. Галочка — угловая скобка, назовём её — она показывает, что удалось установить в таблицу маршрутизации. Этих маршрутов не удалось поставить в таблицу, оказалось, что их не готовы принять. Distribute-list их зарезал. Так, дальше.

Что бы ещё можно было сделать? Интересно. На R2 у нас маршруты сейчас тоже есть. Show ip OSPF route. Вот. OSPF есть. OSPF притащил маршруты. Здесь, обратите внимание, эти маршруты — их никто не зарезал. Потому что OSPF работает с LSA. То, что на R1 таких маршрутов нет, не означает, что у нас эти маршруты дальше не передаются. Если бы вы аналогичное действие сделали в RIP, в EIGRP, даже в BGP, вы бы маршруты, которые у вас в таблице маршрутизации отсутствуют, не смогли дальше передать. А здесь у вас этих маршрутов в таблице R1 роутера нет. Но R2 сказал: ничего страшного, я направляю на R1 эти пакеты.

И соответственно пусть R1 решает, что с ними дальше делать. То, что R1 эти маршруты зафильтровал — это его половые трудности. Вот такой момент есть. Так, далее. Давайте попытаемся сделать так, чтобы у нас в некоторые регионы не проходили LSA 5. Сейчас у нас есть связь между первым и вторым роутерами. И на втором роутере мы видим, что у нас действительно E2, E1 маршруты есть. Маршруты, внешние для OSPF. Они были переложены в OSPF. И вот они нам теперь здесь известны. Мы хотим, чтобы на R2 такие маршруты не приходили. Потому что он не может с ними справиться. Например, потому что это какой-нибудь маленький роутер. И для него такая большая таблица маршрутизации на весь экран — она ему сложная. Для того чтобы это сделать, нужно, чтобы у нас регион, в который не должны вбрасываться LSA 5, был объявлен stub'ом.

И делается это в настройке роутера. Router OSPF 1. Area — в моём случае 15 — stub. Я объявляю, что у нас регион 15-й будет stub'ом. И он отваливается. Не он отваливается, а сосед отваливается. Соседи не могут установить соседство, потому что они считают, что у нас разные типы регионов. R2 заявляет, что он считает регион 15-й stub'ом. А R1 считает, что это нормальный регион. И соответственно у них не совпадает флаг E. В отправляемых сообщениях R1 он выставляет, что LSA 5 в 15-м регионе доступны. R2 говорит, что нет, недоступны. Сосед отвалился. Conf t. Router. Router. OSPF 1. Area 15. Stub. Возвращаем. Не возвращаем, а делаем так, чтобы роутеры смогли подружиться. И сейчас у нас R2 роутер вместо кучи отдельных пятёрок будет получать одну суммарку.

Причём трёшку. IP route OSPF. Вот. Раньше — показываю, как было раньше — были E1 и E2 маршруты. Вот они. Сейчас вместо этих маршрутов мы видим только вот такую штуку. Необычный дефолтный маршрут, который к тому же не в виде E1 или E2 маршрута, а в виде LSA 3. Inter-area маршрут. Все пятёрки мы зафильтровали, вместо них приходит одна суммарка — трёшка. Show ip OSPF database. Эти LSA пятёрки пока что в базе есть, но они сейчас устареют и протухнут. И соответственно они пропадут из таблицы. Для того чтобы ускорить этот процесс, можно зайти на роутер или даже clear

ip OSPF. Я перезагружаю OSPF. И сейчас там эти LSA должны протухнуть. Не так всё просто. Надо оба роутера перезагрузить. Причём желательно одновременно. Ладно, ничего страшного, подождём. Так. В любом случае, в таблице маршрутизации эти LSA не учитываются. Маршруты из них не забираются. И в таблицу маршрутизации E1 и E2 маршруты больше не попадают. Если мы захотим, мы можем сказать, что нет смысла нам присылать такие маршруты 0.0.0.0. И потом ещё дополнительно... А, я знаю, откуда эти пятёрки берутся. У нас же этот роутер. Conf t.

Interface loopback 0. No ip OSPF 1 area 0. Я же там добавлял, что loopback должен быть в нулевом регионе для того, чтобы просимулировать его ABR-ство. Да. IP OSPF database. Сейчас LSA пятёрки должны протухнуть через некоторое время. Так. Здесь будет видно, что у нас есть маршрут дефолтный через роутер первый. И кроме того, первый роутер говорит, что у него есть куча отдельной мелочи, через него можно до которой тоже добраться. Если мы хотим сказать, что не надо присылать кучу мелочи и суммарку, если всё равно по факту это одно и то же — не надо говорить, что я знаю такую сеть, сякую сеть, пятую сеть, десятую сеть и все остальные сети тоже — это лишено смысла. Можно просто сказать: я знаю все сети. Если мы хотим так оптимизировать поведение роутера первого, то мы должны будем сказать, что у нас area 15 не просто stub, а stub no-summary.

Это ключевое слово no-summary будет означать следующее: не надо посылать LSA третьего типа. No-summary — это не то, что мы в этот регион ничего не суммаризируем, а no-summary — это не посылать LSA трёшки. И соответственно LSA трёшки не посылаются. Вместо них посылается одна единственная LSA трёшка за всю сеть 0.0.0.0. Старые LSA должны будут немножко протухнуть. Мы дадим им немножко времени. А, вот они уже протухли. 0.0.0.0. Одна единственная LSA осталась. Так. Вот. Если вдруг мы хотим показать, что наш роутер будет теоретически желать вбрасывать какие-то маршруты, хотя он считает, что регион, в котором он находится — это stub, и соответственно в этом stub'е пятёрки порождать нельзя,

то в этой ситуации нам нужно будет сделать следующую вещь. Давайте сделаем вот какую штуку. Свяжем первый и третий роутеры между собой. Скажем, что у нас есть регион, с помощью которого первый и третий роутеры связываются. Это будет area ... 250. Нет, 250 плохо. 250 плохо. 200 плюс номер региона. Area 215 NSSA. Я указываю, что мы сделаем Not-So-Stubby Area. И я указываю, что интерфейс Ethernet 0/0.13, который связывает первый и третий роутеры, ip OSPF 1 area 215. Вы тоже у себя сделаете связь между первым и третьим роутерами через интерфейс Ethernet 0/0.13 в регион 200 плюс номер вашего комплекта.

В моём случае это был 215. И здесь мы на R1 прописали всё необходимое, на R3 тоже прописываем всё необходимое. Enable. Conf t. Router OSPF 1. Area 215 NSSA. Interface Ethernet 0/0.13. IP OSPF 1 area 215. Мы связываем их через broadcast-интерфейс. Там будет порождаться по одной LSA первого типа, одна LSA второго типа. Куча суммарок. И поскольку мы объявили регион NSSA, то будет порождаться также LSA семёрка. В NSSA-регионе трёшки переходят нормально, а вот пятёрки не переходят. Более того, если вы указываете просто area 215 NSSA, то в этом случае дефолтный маршрут там автоматом не появляется.

Вот я сейчас покажу, что у нас в итоге получилось. Show ip OSPF database. Смотрите. Есть вот эта штука. Это соответственно две LSA первого типа. Есть вот эта штука. Это одна LSA второго типа. Есть куча трёшек. LSA трёшки есть, всё честно. И, соответственно, есть LSA-7, потому что роутер R1 её redistributed. Он же является ASBR, он же является ABR. Поэтому он говорит, что семёрка у нас есть. И в этой ситуации он должен, по идее, проставить в этой семёрке флаг do not propagate. Давайте посмотрим. Show IP OSPF Database NSSA External. Вот оно. No Translation. Эти LSA-7 уже переложены в нулевой регион. Не надо их на других ABR-ах перекладывать по умолчанию.

И здесь мы видим, что пятёрок у нас действительно нет. И, кроме того, нету нулевого маршрута. Его тут действительно нет. Можете посмотреть. Нигде нет указания про нулевой маршрут. Пятёрки заблокировали, а вместо них нулевой маршрут не предоставили. Если мы хотим сказать, что ABR при объявлении региона должен будет вбрасывать всё-таки нулевой маршрут, это нужно сделать с помощью волшебного пенделя. Заходим на роутер первый и указываем. Area 1 NSSA. Default Information Originated. Мы не просто закрываем все LSA-ки пятёрки, а мы вместо них дефолт вкладываем. По умолчанию, если вы указываете именно тип региона, просто NSSA, обычный NSSA, то дефолт там не вкладывается. Дурацкое поведение, которое надо просто запомнить. И теперь у нас маршрут дефолтный появится. Где он есть?

Не вижу. А у нас, наверное, там... Default Information Originate. А, Area 1, да, простите. Area 1, Area 215. Я постоянно путаюсь, уже спать пора. И здесь порождается дефолт. Забавный нюанс. Да, я ошибся с номером региона. Забавный нюанс, что если мы в обычный стаб вбрасываем дефолт, этот дефолт приходит в виде LSA-ки трёшки. Потому что в обычном стабе нельзя пускать LSA-ки семёрки, нельзя пускать LSA-ки пятёрки. В обычном стабе ничего кроме трёшек не остаётся. Если вы указываете, что у вас есть NSSA, обычный NSSA, в котором вы указываете Default Information Originate,

то у вас роутер ABR вбрасывает не трёшку, а вбрасывает именно семёрку. Видите, что это семёрка. Внутри NSSA у нас появляется дефолтный маршрут. У этой семёрки, кстати, будет стоять как раз флажок тоже. Нельзя будет транслировать её. Тот, кто её придумал, он уже ABR. И не надо порождать на основании этой LSA-ки семёрки пятёрку, если вдруг у нас какой-то другой роутер будет ABR. Метрика двойка. Метрика второго типа, простите. Метрика единичка. Это вместо всей кучи LSA-ек пятёрок в NSSA-регионе ABR положил этот дефолтный маршрут.

Если мы хотим сказать, что нет смысла, помимо этого нулевого маршрута, присылать ещё кучу отдельных суммарок, если они в принципе все тоже доступны через ABR, то на ABR нужно будет дополнительно сказать NSSA Default Information Originate No Summary. Так же, как мы это делали с обычным стабом, добавляем ключевое слово No Summary, и LSA-ки трёшки схлопываются в дефолтный маршрут. Смотрим на то, что получилось. No Summary делает этот регион Total NSSA. В Total NSSA в принципе Default Information Originate не нужно, поэтому у нас появляется вместо LSA-ек пятёрок и трёшек одна трёшка с дефолтом. И к тому же мы сказали Default Information Originate, поэтому порождается ещё дополнительно и семёрка с дефолтом. Но в этой ситуации, если у нас один и тот же маршрут известен и по LSA-кам трёшкам, и по LSA-кам внешним пятёркам-семёркам, то выбирается тот маршрут, который через трёшки.

Таблица маршрутизации, show IP OSPF. У нас будет маршрут, который через трёшку известен. Вот такая загогулина получается. И вот маршрут, известный через LSA-ку-семёрку 10-15-1-0 по 24-й маске, который R1 сам же и редистрибутнул. И здесь показывается, что он действительно есть. Это что касалось нашего NSSA-региона. NSSA обычный, NSSA totally stub, totally NSSA. Вот они так себя ведут. Запомните из того, что здесь нужно будет прям действительно запомнить на экзамене, что area NSSA не порождает дефолтный маршрут, несмотря на то, что это абсолютно нелогично, это поведение такое у Cisco есть. Я думаю, пришла пора поговорить про virtual link. Что касается virtual link, это, как вы помните, виртуальный интерфейс,

который связывает между собой два роутера, которым нужно реплицировать базу нулевого региона. И они связаны между собой не через нулевой регион. В нашем случае на картинке показано, что два роутера хотят реплицировать базу нулевого региона, хотя они связаны через роутер номер один. На самом деле, вы вполне можете себе представить, что у вас есть два, например, разрывных нулевых региона, и вы хотите реплицировать базу их для того, чтобы этот кусочек и этот кусочек были связаны между собой. В этом случае через воображаемый интерфейс, относящийся к нулевому региону, у вас будут передаваться LSA-ки первого типа, и базы нулевого региона в этом случае будут реплицироваться. Что касается ситуации, когда virtual link чаще встречается, это у вас есть роутер один. R1, давайте называть его R1, у него есть доступ к нулевому региону. Вот он. У вас есть регион, через который два других роутера связаны, роутер 2, например,

и у нас здесь Area 1 показывается. Плюс к тому, у вас здесь ещё есть один регион, и этот регион не обязательно должен быть нулевым, например, Area 2. И сразу возникает вопрос, что делать в такой ситуации, когда у нас есть нулевой регион, первый регион и второй регион. Маршруты так ходить не будут, потому что то, что здесь зародилось в виде LSA-ки первого типа, перекладывается в первый регион в виде LSA-ки трёшки, и потом R2 не будет перекладывать ничего во второй регион, потому что он не является ABR-ом, и он не будет ничего перекладывать до тех пор, пока он не станет этим самым ABR-ом. И для того, чтобы стать ABR-ом, мы ему можем сказать, здесь у нас Area 2. Давайте сделаем интерфейс, который будет смотреть в Area 0. И тогда он станет ABR-ом, и тогда он будет перекладывать маршруты между регионами, но у нас сразу возникает вопрос, как эти кусочки нулевого региона связать.

Чтобы этот роутер стал ABR-ом, чтобы этот роутер стал перекладывать маршруты между регионами, у него нулевой регион должен присутствовать. Поэтому даже если это будет воображаемый интерфейс, который смотрит в нулевой регион, в этом воображаемом интерфейсе у нас порождается LSA-ка нулевого региона, и нам нужно эту LSA-ку сделать известной всем остальным в оригинальном нуле. Поэтому если у вас роутер является ABR-ом, то нулевой регион у него обязан быть. Полная база всего, что происходит в нулевом регионе. Поэтому даже если мы говорим, что здесь у нас будет Area 2, казалось бы, где здесь нулевой регион? Где-то этот нулевой регион обязан быть. Иначе этот роутер просто не станет ABR-ом. А если он не станет ABR-ом, он не будет перекладывать маршруты, не будет перекладывать трафик по этим маршрутам, как следствие. Поэтому нам нужно его заставить стать ABR-ом. И нам нужно, чтобы он получил базу нулевого региона. Мы порождаем виртуальный псевдопровод нулевого региона, и у нас на этом роутере ABR-е нулевой регион таким образом самозарождается.

Для того, чтобы в Cisco создать virtual link, мы должны будем сказать, через какой регион мы будем дружить, и до какого идентификатора виртуальный конец псевдопровода будет строиться. Вы указываете: Area 1, Virtual Link 2.2.2.2 на роутере R1. Почему надо указывать регион, через который вы будете дружить? Потому что эта штука — это router ID. Этот router ID есть в базе LSA первого типа, но в каждом регионе эта база своя. Поэтому если у нас есть ABR R1, у него есть регион 1, у него есть регион 2, R3, R4 и так далее. И там может быть много разных регионов, в которых тот же ABR будет присутствовать, тот же router ID. Поэтому мы должны будем сказать, через какой конкретно регион мы будем строить туннель до другого ABR. И здесь мы указываем регион, и мы указываем router ID другого конца туннеля. И, соответственно, на другом конце мы указываем ответное действие, через какой регион строим и до какого другого конца туннеля мы строим Virtual Link.

И в этом случае у вас получается, что как минимум этот интерфейс будет относиться к Area 0. У нас порождается интерфейс, который смотрит в Area 0, у нас реплицируется база нулевого региона, и даже если у вас есть физические интерфейсы, которые смотрят только в первый и во второй регион, у вас всё равно нулевой регион по факту тоже есть. И вы становитесь ABR-ом, и вы начинаете перекладывать трафик между этими двумя регионами, как будто у вас был бы полноценный интерфейс в ноль. Давайте попробуем это соорудить. У нас как раз сейчас есть ситуация, когда роутеры первый и второй связаны по, в моём случае, 15-му региону, а второй и четвёртый связаны в моём случае по 115-му региону. И я специально убрал все следы нулевого региона на нашем втором роутере. Роутер 2, у него сейчас enable, show IP OSPF interface brief,

у него сейчас есть два интерфейса, Ethernet 0012 и Ethernet 0024. Оба в разных регионах, и ни один из них не нулевой. Убедитесь, пожалуйста, что у вас тоже так, то что я в своё время добавлял loopback в нулевой регион, для того чтобы показать, что проблема всё равно будет, если у нас разрывный ноль. Сейчас здесь нуля просто нету, поэтому show IP OSPF просто без параметров не говорит нам, что этот роутер будет ABR-ом. У него есть два разных региона, но ABR-ом он при этом не является. И здесь нигде не написано, что этот роутер будет ABR-ом. На R1, кстати, будет. Enable, show IP OSPF. Здесь показывается, что это ABR. Это ABR. Сейчас найду, где это. Здесь прям показывается, что...

This router is ABR. Вот. It is an area border router. Что это и ABR, и ASBR. После слова event log. На R2 такой штуки нету. На R2 здесь нету слова, что это ABR. У него есть интерфейсы, смотрящие в разные регионы, но у него нету нуля. Поэтому он не считает себя ABR-ом. И LSA-ки трёшки в других регионах он не порождает. Если он из одного ненулевого региона получает какие-то LSA-ки трёшки, он её дальше никуда не перекладывает. Равно как если в другом регионе у нас есть LSA-ки первого типа, он в виде LSA-ек трёшек тоже маршруты никуда не перекладывает. Для того, чтобы он это начал делать, нам нужно соорудить на нём базу нулевого региона.

А базу нулевого региона можно как раз сделать через Virtual Link. Не проблема, делаем conf t. Указываем router OSPF 1. Дальше. Area. Через какую мы строим наш Virtual Link? В моём случае 15-я. Virtual Link. И дальше идентификатор другого роутера. Какой у нас там идентификатор? Router ID 10.15.1.1 у меня. Посмотрите, какой у вас на первом роутере идентификатор. Он ещё и стаб. Area 15 стаб. И здесь тоже. Area 15 стаб. Через нетранзитный регион нельзя построить Virtual Link.

Это вполне логично. Поэтому, если я пытаюсь это сделать, он ругается. В этой ситуации я отключил стабовость на 15-м регионе. Сказал, что другой конец туннеля будет в 15-м регионе. 10.15.1.1. Дальше. На R1 делаю ответные действия. Area 15. Virtual Link. 10.15.2.2. И у нас получается виртуальный интерфейс, который Cisco называет OSPF VL0. Virtual Link 0. Там обнаружен сосед. И на этом соседе у нас передаются LSA базы нулевого региона. На R2

у нас появляется виртуальный интерфейс, смотрящий в нулевой регион. Show IP OSPF interfaces brief. У нас появляется виртуальный интерфейс VL0, который смотрит в 0. Он всегда смотрит в 0. Virtual Link обязан смотреть в 0. Он просто по определению такой. На этом интерфейсе у нас обнаружено соседство. Соседство типа Point to Point. Хотя на самом деле более правильно было бы сказать, что это соседство именно virtual link-овское. Оно особенное. Если мы закажем отображение show IP OSPF interface VL0. Я боюсь, что он там не сможет показать. Да. OSPF VL 0. Давайте попробуем. Нет, не хочет. Ничего страшного. У нас воображаемый интерфейс, который есть только в воображении OSPF. Это не настоящий интерфейс. И здесь показывается, что мы ничего не делали для того, чтобы этот интерфейс включился в OSPF.

Он естественным образом самозародился в этом OSPF. Тип среды Virtual Link — как раз это стандартный способ связи между двумя роутерами. Это не Point-to-Point. Это не транзитная сетка через LSA 2 типа. Это не Stub-сетка. Это что-то совершенно особенное. Эти два слова Configure-to-Sdemand Circuit, Run-Sdemand Circuit означают, что LSA мы туда не посылаем. Один раз установили соседство. Не LSA, простите, а HelloPacket мы не посылаем. Один раз установили соседство и дальше сидим, пить-есть не просим. Ничего по этому интерфейсу по факту не бегает. LSA передали и всё. Дальше. Обнаружен сосед. И напротив соседа показываем HelloSuppressed. Мы в этом интерфейсе не посылаем HelloPacket. Это абсолютно правильно, потому что если у вас сосед отвалится, с которым вы работаете, то вы об этом узнаете через LSA-ки первого типа. А вам отдельный HelloPacket, чтобы проверять другой конец туннеля на жизнеспособность, в этом случае посылать не нужно.

Дальше можем посмотреть show ip ospf neighbors. Что у нас обнаружен neighbor. Вот он, этот neighbor. Показывается, что DR/BDR мы с этим neighbor не выбирали, что с этим соседом мы перешли в полные взаимоотношения. И здесь у нас HelloPacket, которые будут передаваться. Указывают, что на этом интерфейсе мы согласны передавать внешние LSA-ки пятёрки. Здесь не показывается, что с этим соседом HelloSuppressed. Ладно. В общем, подружились. Оно работает. И дальше show ip ospf database. У нас появляется база нулевого региона, несмотря на то, что живых физических интерфейсов в нулевом регионе у нас нет.

Вот оно. Нулевой регион действительно весь целиком показывается. Видно, что действительно в нулевом регионе у нас есть LSA-ки первого типа. Все-все-все LSA-ки первого типа на наш роутер прибежали, несмотря на то, что, ещё раз подчеркну, физически ни одного интерфейса в нулевом регионе у нас нет. У нас только воображаемый интерфейс. Есть куча LSA-ок второго типа. Есть куча summary ASBR. И дальше про 15-й регион нам начинают рассказывать, что там что-то тоже есть. И про 215-й регион там тоже что-то мы должны... Про 115-й регион должны рассказать. Естественно, что через этот Virtual Link там ещё и LSA-ки пятёрки прибегают. Да, вот они. И если посмотреть напротив некоторых LSA-ок, которые к нам прибегают, будет стоять вот эта штучка. Do Not Age. DNA. Это означает, что если LSA-ка к вам такая пришла, её не надо перевыпускать каждые 30 минут. Она не устаревает, и у неё срок может быть какой угодно.

Нормальные LSA-ки вы перевыпускаете раз в 30 минут. А если вы не делаете этого, то через час такая LSA-ка сдохнет. И как только она досчитает до 3600 секунд срока годности, это считается, что LSA-ка должна быть выкинута из базы. В случае с Virtual Link'ами вы передаёте эти самые LSA-ки по Virtual Link'у. И дальше вы понимаете, что с соседом точно есть нормальная связь в любом случае. Если у соседа что-то произойдёт, он вам пришлёт новую версию LSA-ки. А если вдруг он отвалится, то вы все LSA-ки, полученные по Virtual Link'у, должны будете удалить в любом случае. Поэтому вам особенно нет смысла в такой ситуации заставлять соседа перевыпускать эти самые LSA-ки и нагружать Virtual Link лишний раз. Вы можете сказать, окей, мы не будем перевыпускать LSA-ки, если мы получили их по Virtual Link'у. Мы будем напротив них ставить флажок. Эта LSA-ка никогда не протухнет естественным образом. И можем сейчас заказать роутерную LSA-ку.

Например, какую бы роутерную LSA-ку посмотреть? Давайте 10.3.1.1. Такой у нас точно нет. Show IP OSPF Database Router 10.3.1.1. Возраст у этой LSA-ки 1411 секунд. Причём один раз мы её получили, и с тех пор она дальше не устаревает. В остальном LSA-ка нормальная, обычная. И в ней есть указание, кто на кого каким интерфейсом смотрит. Что у нас есть какое-то Point-to-Point соседство. У нас есть какая-то Stub-сетка. И если я закажу LSA-ку, например, свою собственную, 10.15.1.1, то там я ожидаю, что будет ещё вот эта штучка. Вот эта. И будет указываться, что есть, помимо того, что у нас есть Point-to-Point интерфейс через туннель, есть Stub-сетка на туннельном интерфейсе, у нас IP-шник висит.

Есть ещё, помимо этого, связь с нашим роутером. И с нашим роутером она как раз через Virtual Link строится. Это Point-to-Point соседство, но специальное и особенное. Когда мы собираем пазл, мы говорим, покажи нашу LSA-ку. Мы увидим, что есть Virtual Link связь с соседом. Мы говорим, почти настоящий интерфейс. Собираем пазл. И действительно у нас пазл собирается, что наш Virtual Link строится с Virtual Link соседа, тот строится через туннельный интерфейс с центральным, тот через туннельный интерфейс со всеми остальными. И те, возможно, тоже через Virtual Link с какими-то своими соседями будут строиться. И таким образом получается, что действительно пазл сходится. Что-то ещё хотел сказать. Virtual Link имеет метрику, совпадающую с метрикой, как добраться внутри региона, через который Virtual Link строится, до другого конца туннеля. Мы нигде эту десятку не назначали.

Десятку посчитал мой роутер R2 самостоятельно, когда по карте топологии 15 региона посмотрел, как быстрее всего добраться до R1. Он посмотрел, что стоить это будет 10 копеечек, и этому Virtual Link он назначил стоимость именно 10 копеечек. Поэтому фактически Virtual Link идёт той же трассой, что самый лучший способ добраться до другого конца туннеля в 15 регионе. Просто оно не показывается, как именно. Что-нибудь ещё здесь? Наверное, нет. Ещё раз подчеркну, что Virtual Link — это способ быстро починить связь, когда у вас нулевой регион развалился на несколько частей. Это не должно закладываться на уровне дизайна, что у вас внезапно в каком-то месте штатно работает Virtual Link. Virtual Link — это именно быстро организовать связь между двумя роутерами, если нужно среплицировать базу нулевого региона тогда, когда она там должна быть штатной, но её там нету почему-то.

И ещё, когда вы указываете, что у вас есть роутер, который смотрит в какой-то ненулевой регион, через который строится Virtual Link, в LSA первого типа тоже указывается соответствующий флажок. Есть флажок, что это ABR, есть флажок, что это ASBR, есть флажок, что это конец Virtual Link. Поэтому роутеры, которые находятся внутри ненулевого региона, они тоже смогут понять, что между какими-то роутерами Virtual Link будут проходить. Это что касалось Virtual Link. Prefix suppression — очень прикольная вещь, которая скрывает транзитные префиксы. Я уже про неё говорил, что это механизм, с помощью которого можно избавиться от ненужных префиксов, которые между роутерами будут использоваться. Например, у нас есть роутеры R1 и R4.

У них есть пользовательские сетки 192.168.1.0, 192.168.2.0. Фактически только эти сети на самом деле интересуют нас как пользователей OSPF. Сеть с OSPF создаётся для того, чтобы пользователи в ней работали, пользовательские устройства. Эти транзитные сетки мы вынуждены в OSPF включать, когда мы включаем OSPF на интерфейсах. Они сразу в анонс неизбежно попадают. Может быть попадают там только Connected Type-ишники или Connected сетки целиком, но тем не менее всё равно в анонсе появляется лишний мусор. Чтобы от этого мусора избавиться, есть замечательная штука, которая называется Prefix Suppression. Вы указываете это в настройке роутера, и после этого в LSA-ках первого типа у вас Stub-нетворки с этих интерфейсов перестают анонсироваться, и в LSA-ках второго типа у вас указывается маска /32. Такие сети в RIB у вас не попадают. Даже если у вас будет старый роутер, который не знает про RFC, который эту штуку придумал, он просто поймёт, что 32-я маска на транзитной сети быть в принципе не может.

Он скажет, что она неправильная, и в таблицу маршрутизации её добавлять не будет. Давайте попробуем это дело включить. Опять же, команда всего одна, поэтому здесь всё должно пройти достаточно легко и быстро. Так, это не то. У нас есть, например, наши роутеры первые, и они смотрят на туннельный интерфейс. Я предлагаю там сказать conft, router, ospf 1, prefix suppression. Просто одна команда. Вы, пожалуйста, тоже её сделайте. do show ip ospf road. Сейчас тут 192.168, всякие разные IP-шники есть. Они нас сейчас не сильно интересуют. На core-r надо будет ответные действия сделать, сказать prefix suppression. И сейчас я ожидаю, что у нас все эти транзитные сетки из таблицы OSPF уйдут, что нам они не нужны.

show ip ospf, show ip road. Их стало уже заметно меньше, да, 192.168, вот эти остались: первое, пятое, двенадцатое. Было их существенно больше. Было первое, третье, четвёртое, пятое, одиннадцатое, двенадцатое, пятнадцатое. Да. Они действительно убираются. В таблице маршрутизации меньше ненужных префиксов, особенно если у вас сетка большая, заметно сокращает загрузку таблиц маршрутизации, заметно упрощает внешний вид вашей таблицы, и всячески рекомендуется к использованию. На цисках поддерживается, на других роутерах может не поддерживаться. Опять же, вы включаете prefix suppression на уровне отдельного роутера. Этот роутер не будет добавлять в анонсы какие-то вещи. То, что какие-то другие роутеры, возможно, эту штуку будут не поддерживать — значит, они будут добавлять в анонсы транзитные префиксы, и у вас получится, что если вы где-то включили, где-то не включили, то какие-то роутеры не рассказывают про свои префиксы, какие-то рассказывают, но всё равно в таблицу маршрутизации будет добавляться то, кто что-то рассказал.

Но по большому счёту эти отдельные IP-шники 192.168.0105.012 для таблицы не сильно интересны, не сильно нужны, поэтому имеет смысл их убирать. Вот первый пропал. show ip road, в общем, да, 5 и 12 пока остались. Надо прописать prefix suppression на роутере, и тогда всякая ненужная мелкая ерунда будет убираться. Действительно, зачем нам держать в таблице отдельные транспортные IP-шники? Не нужны. Дальше. Если мы захотим, мы можем поиграть с маршрутами, можно задать административное расстояние. Опять же, как и в EIGRP, можно задать отдельное административное расстояние для нативных маршрутов, для intra-area и для external маршрутов.

В EIGRP у нас было два типа маршрутов, здесь у нас три. Изученные по LSA-кам первого типа, изученные по LSA-кам третьего и пятого типов. Соответственно, административное расстояние для всех по умолчанию 110. Здесь вранье написано 110 для всех маршрутов. Да, не знаю, откуда это взялось, 170 для внешних. Видимо, из EJRP я копировал слайд. Так вот, 110 для всех маршрутов по умолчанию. Вы можете поменять это, сказав команду distance OSPF, дальше intra-area какое-то, inter-area какое-то и external какое-то. Опять же, зачем это может понадобиться? В ситуации, когда у нас какие-то маршруты перекладываются в OSPF, и потом из этого OSPF куда-то там дальше перекладывается. Или наоборот, из OSPF забирается куда-то в одно место, а потом из этого одного места куда-то обратно прикладывается в OSPF. Чтобы на уровне административного расстояния отличать маршруты нормальные от маршрутов

внешних. OSPF в принципе не подвержен проблеме обратной регистрибуции, потому что при выборе маршрута маршруты через LSA первого и третьего типов всегда будут превосходить маршруты через LSA пятерки. Поэтому в принципе нет отдельной какой-то острой необходимости для внешних маршрутов ставить административное расстояние больше, чем для нативных. В RIP такая потребность бы была, но в RIP нет концепции внешнего маршрута. В EJRP она есть и EJRP тем самым не подвержен проблеме обратной регистрибуции. Вот OSPF тоже не подвержен, но уже по другой причине. Если вы хотите, вы можете, однако, административное расстояние поменять. Можно поменять на уровне всего протокола. Тогда вы указываете Distance OSPF и даете настройки, что все OSPF-овские маршруты будут иметь административное расстояние, какое вы зададите. Если вы хотите на уровне отдельного маршрута или отдельных конкретных маршрутов поменять административное расстояние, это опять же можно делать и механизм будет

точно тот же самый, что и для всех остальных протоколов, которые мы с вами изучали. Distance циферка вместо OSPF циферка. Дальше задаете аксесс-листом IP-шники шлюза, которые у вас посчитаны в таблице маршрутизации и задаете аксесс-лист, который отбирает нужные маршруты через указанный шлюз. Вот в нашем случае мы сказали, что все маршруты, которые подвержены, которые проходят через ACL Distance 180, должны получить административное расстояние 180. И вот нормальные маршруты, ненормальные маршруты, кривые маршруты, у них у всех административное расстояние 180. Так, ситуации, в которых вам пришлось бы играть административным расстоянием, еще раз подчеркну, крайне мало. Это, как правило, либо миграция с одного протокола динамической маршрутизации на другой, когда у вас одновременно работают два протокола, и вам нужно, чтобы сначала продолжил

работать нормально старый, когда вы добавляете новый протокол динамической маршрутизации. Поэтому вы должны новому протоколу сделать административное расстояние хуже. Ну, например, у вас сейчас есть RIP, а вы хотите внедрить OSPF. Если вы начнете OSPF внедрять до того, как RIP уйдет из таблицы, то это может привести к очень нежелательным последствиям. Для того, чтобы не устроить петлю, вы сначала добавляете OSPF, вы параллельно с RIP его внедряете, но вы ему занижаете административное расстояние, точнее, завышаете, и делаете, чтобы он был хуже, чем RIP. Ну, например, делаете ему 150 административное расстояние. Поднимаете везде OSPF, и дальше начинаете убирать RIP. И вот, когда вы уберете RIP, у вас OSPF будет просчитывать маршруты, которые уже известны в остальной части сети, и, соответственно, там нигде уже петли не случится. Если вы просто начнете добавлять OSPF, где попало, то у вас будет возможность устроить, соответственно, петлю, что OSPF говорит ходи

в одну сторону, RIP говорит ходи в другую сторону, и это будет петля. А вот, если вы сначала добавите OSPF, а потом начнете убирать RIP, и тем самым пускать OSPF в действие, то тогда OSPF у вас никогда не направит трафик туда, где RIP скажет ходи обратно. Вот, и в этой ситуации фактически будет единственный сценарий, легитимный, где вы имеете право административное расстояние менять. Во всех остальных случаях, что CISCO рекомендует, не CISCO-то, скажем, рекомендует, а CISCO рассказывает, как можно поменять административное расстояние, вот, это, ну, скорее, бредовый какой-то сценарий в реальной практике не встречающийся. Так, да, во все сообщения вы можете сделать пароль. Пароль можно прикладывать в открытом виде, либо использовать хэш MD5. Плентекстовый пароль плохая идея во всех случаях. То есть, если вы это хотите сделать, вы должны будете на уровне

интерфейса сказать, какой пароль вы будете прикладывать на пакетах в этом интерфейсе. Команда будет на уровне интерфейса IP, USPF, Authentication Key и дальше пароль. И вы должны будете сказать, что надо отправлять пакеты с паролем. Это отдельная команда. То, что вы говорите командой, что пароль будет вот такой, это не указывает, что надо отправлять пакеты с паролем. Требовать аутентификацию можно либо на уровне интерфейса тоже, то есть, вы указываете IP, USPF, Authentication Key и отдельно рядышком указываете IP, USPF, Authentication. Либо можете сказать, что все интерфейсы у вас требуют аутентификацию. Но тогда на всех интерфейсах вы должны будете заранее прописать Authentication Key. Дурацкий механизм у USPF второй версии никто не спорит, но вот как есть. То есть, отдельно прописываем какой пароль и отдельно прописываем, что пароль нужен. если вы хотите использовать пароль, но все-таки не передавать его в открытом виде, а я думаю, что именно это

хотите вы сделать, то в этом случае нужно будет подписывать пакеты хэшем от содержимого пакета плюс ключа. Ключевые цепочки здесь не поддерживаются. Есть такая вот штука, да, что в EJRP у нас были ключевые цепочки, здесь у нас ключевых цепочек нет. Однако, ключи, которые будут передаваться, они будут, однако, поименованы, пронумерованы, скажем так. И вы должны будете задать эти самые нумерованные ключи на каждом интерфейсе, который у вас будет использоваться. То есть, есть у нас интерфейс, через который мы дружим с соседом, окей, указываем на нем, что у нас нужно использовать ключевую строчку, определенную, ключ, и, соответственно, пакеты подписывать этим ключом. Точно так же, как и в случае с plaintextом, мы должны будем сначала прописать, какой ключ использовать. IPOSPF Message Digest Key, дальше указываем номер ключа, указываем, какой хэш используем, какой ключ используем. И отдельно указываем

на уровне интерфейса или на уровне региона, что аутентикация должна быть и аутентикация должна быть нормальная, а не plaintext. То есть, либо на интерфейсе IPOSPF Authentication Message Digest, либо на уровне региона Area 0 Authentication Message Digest. есть нюанс, который заключается в следующем. Вы можете прописать на уровне одного интерфейса много ключей с разными номерами. И тогда, если вы отправляете пакет, вы будете отправлять пакет с наибольшим номером ключа, то есть, у вас есть роутер, и вот у него есть интерфейс, и на этом интерфейсе прописаны ключи первый, второй, третий. при прочих равных вы говорите, я буду отправлять пакеты с третьим ключом, потому что у него номер больше. Это самый свежий ключ. Но, если вы принимаете пакеты, то вы принимаете пакеты с любым ключом. То есть, к вам приходит HelloPacket, и в нем написано, это ключ номер 2. Вы говорите, окей, проверяем по ключу

номер 2, если все хорошо, то замечательно, соответственно, работаем. И, если у вас есть несколько разных соседей, которые присылают вам HelloPacket, и в этих HelloPacket разные ключи, у вас возникает вопрос. Когда вы отправляете HelloPacket сами, вы должны будете указать, какой у вас номер ключа используется, вы указываете ключ с наибольшим номером. Но, если вам другой сосед присылает ключ с номером 2, а вы отправляете ключ с номером 3, у вас, получается, будут разные пароли. И для этого OSPF V2 в ЦИСКе используют хитрую процедуру, которая называется Keyrollover. Я не думаю, что она у вас будет в CCNPшном экзамене, но я думаю, что это настолько гениальная идея, что я про нее должен рассказать, хотя это, в принципе, CCIшная тема. Если к вам приходят HelloPacket с разными ключами, вот один ключ с номером 2, второй ключ с номером 3, вы начинаете отправлять HelloPacket со всеми ключами. Вы говорите, я отправляю HelloPacket с ключом 2, и я отправляю HelloPacket с ключом 3.

Вот. И плюс, если у вас прописаны несколько ключей, вы отправляете вообще все ключи. То есть, вы еще и первый ключ сюда же тоже добавляете. Вот такая вот штука будет называться Keyrollover. Почему вы должны будете это делать? Потому что у вас HelloPacket, в принципе, адресован вообще всем, но в этом HelloPacket ключ должен быть один и тот же. Если у вас разные соседи используют разные ключи, вы не можете одно сообщение им отправить, чтобы оно накрыло обоих. Поэтому вы отправляете разные копии HelloSообщений с подписанными разными ключами. Вы отправляете HelloPacket с ключом 2, сосед, у которого двойка, такое HelloSообщение примет. Сосед, у которого HelloSообщение в смысле ключ с тройкой прописан, он его не примет. Вот. Дальше вы отправляете HelloS3. Кто-то его тоже в свою очередь отвергнет, кто-то его примет. В итоге получится, что вы будете дублировать эти самые сообщения Hello, подписывать их разными ключами, и у вас получится, что в итоге так или иначе все дойдет до всех абонентов. Если у вас какой-то апдейт будет,

вы тоже апдейт рассылаете сразу пачкой этих самых сообщений, каждый апдейт подписываете разным ключом. В нормальной ситуации вы там апдейт, например, на 224.006 посылаете, вот вы его один посылаете, а здесь, если вы включаете Key Relover, если у вас на интерфейсе обнаружено несколько соседей с разными ключами сконфигурированными в Hello пакетах, вы же видите, какие сконфигурированы, то вы шарашите всеми ключами, которые у вас есть, дублируете сообщения и подписываете их всеми-всеми-всеми-всеми-всеми ключами. Такая вот штука, которая позволяет, опять же, провести смену ключей относительно безболезненно. Делается это, естественно, для того, сменить ключ, чтобы вы прописали новый ключ, у вас не поломалась связь, чтобы если вдруг у вас есть там три роутера в одном канале, вы же не можете на всех трех роутерах одновременно прописать новые ключи. Вы на одном прописываете, а на двух других у вас пока ключ еще старый. С ключевыми цепочками было бы все просто, а вот с прописыванием ключей в явном виде приходится вот такие вот извращения делать.

Так, ключевые цепочки поддерживаются, но у них есть нюанс. Если вы используете ключевые цепочки, то у вас с помощью ограничения срока действия ключа вы можете провести смену ключей сравнительно безболезненно в любом случае. Но для этого надо, чтобы сосед тоже, соответственно, мог провести такую смену. Создаете ключевые цепочки, указываете на каждом ключе, какой хэш вы будете использовать. Вот у вас появляется штука, вот такая, криптографика, алгоритм, и вы указываете, что за алгоритм вы хотите использовать. Можно MD5, можно SEA1, SEA256 и так далее. И дальше на интерфейсе вы прописываете IP, OSPF, Authentication, Keychain и дальше название ключевой цепочки. Два выхода, соответственно, как можно настроить аутентификацию в OSPF либо через ключевые цепочки, либо через вот это вот самое прописывание ключей на интерфейсе с процедурой KeyRollover.

Любой, который вам больше нравится, такой используйте. Мне больше нравится с ключевыми цепочками, но да, это предполагает, что сосед сможет взять и перейти с одного ключа на другой практически одномоментно. Вот. Давайте мы тогда на сегодня закончим. Давайте не будем заканчивать, давайте я расскажу быстренько про OSPF, в DMVPN, если мы хотим включить фазу 2. У нас сейчас уже есть DMVPN фаза 1, когда весь трафик идет через центральный роутер. Если мы хотим фазу 2, то нам нужно будет немножко пошаманить. И пошаманить будем следующим образом. Нам нужно будет, чтобы трафик между споками ходил напрямую. Соответственно, в этой ситуации нам нужно, чтобы у нас все роутеры считали, что они подключены к одной и той же сети. А для этого нам нужна будет LSA ко второго типа. Вот если мы хотим сказать, чтобы у нас LSA ко второго типа выпускалось, нам нужно будет сделать тип среды,

в котором а, есть автоматическое обнаружение соседей, и б, есть LSA ко второго типа. Это тип среды Broadcast. В Broadcast у нас выбирается DR-BDR, у нас обнаруживают соседи автоматически, и Multicast в DMVPN работает таким образом, что автоматически можно нащупать только центральный роутер на споках, а вот центральный роутер может нащупать всех остальных. В этой ситуации получается, что центральный роутер Hub DMVPN будет идеальным кандидатом на роль DR-а. А в то же время ни один спок не будет идеальным кандидатом на роль DR-а. Поэтому для того, чтобы у нас в DMVPN фаза 2 заработала, мы отключаем приоритет на споках в ноль, говорим, споки никогда DR-ами не будут, мы завышаем приоритет DR-у до какого-то значения, которое будет больше, чем у споков. По умолчанию у споков единичка, вот мы на DR-е, на настоящем DR-е поставим приоритет 100. Мы указываем

тип среды Broadcast со всех роутеров, для того, чтобы они понимали, что LSA ко второго типа есть. И что в этой ситуации произойдет? Наши роутеры будут выбирать DR-а, BDR-а. Они будут говорить, DR-ом у нас будет хаб, а BDR-а у нас вовсе не будет, потому что больше никого они и не видят. Этот DR выпускает LSA ко второго типа. Он говорит, что к ней будут подключены все споки, и все споки будут видеть IP-шники друг друга и будут ставить next-hop-ами друг на друга все маршруты, которые будут получены через этих самых споков. То есть, у нас будет соседство, не каждый видит хаба и строит с ним отдельный point-to-point соседства, а все-все-все друг друга видят через LSA ко второго типа. Пусть даже на самом деле на уровне мультикаста они видят только хаб. И вот эта вот штука, она позволит трафику ходить не через хаб. весь трафик по факту будет ходить через интернет между споками напрямую. Это очень полезно, например, в ситуации, когда у вас телефонии есть,

что зачем трафику лишний раз испытывать какую-то дополнительную задержку и ходить через хаб. Это будет намного быстрее, если вы будете ходить напрямую. Можно будет в некоторых ситуациях сказать, что вы хотите прописать статических соседей, это не получится сделать, где попало. Статику можно использовать только в типе среды нон-бродкаст или point-to-multipoint нон-бродкаст. ЦИСК на всех остальных интерфейсах автоматически обнаруживает соседей. Ну и, соответственно, если вы прописываете тип среды нон-бродкаст, вы можете в настройке роутера сказать, что айпишник соседа будет определенный нейбор, дальше указываете айпишник, и дальше штука, которая многих смущает, вы указываете приоритет соседа, и дальше все люди думают, что вот этот вот приоритет это явно что-то про др-бдр. Нифига подобного. Это не про др-бдр. Это про то, в каком порядке вы должны будете с соседями устанавливать соседские взаимоотношения,

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

R1, R2, здесь R3 и соответственно R3. И мы хотим сказать, что у роутера R1 приоритет при выборах др-бдр-а будет 100, у R2 будет приоритет, не знаю, 10, и у R3 будет приоритет 5. Вот очевидно, что др-ом в итоге должен стать R1. Но когда мы на R3 прописываем соседей, мы говорим, что у нас есть сосед R1 статически прописанный и у нас есть сосед R2 статически прописанный. У R1 приоритет при выборах др-бдр-а 100, у R2 приоритет при выборах др-бдр-а 10. Если мы скажем, что у R1 приоритет опроса 100, а у R2 приоритет опроса 10, то мы сначала подружимся с R1. Мы сначала подружимся с R1, мы выберем др-бдр-а в этом канале, R1 скажет, я буду др-ом, и потом, когда мы будем дружить с R2, мы скажем, др-ом будет R1, мы с ним уже подружились. Удобно здесь вот приоритеты назначать такие же, как при выборах др-бдр-а. Но это не то же самое,

это не одно и то же. Это просто пропорядок, в котором мы опрашиваем. Чем больше приоритет вот здесь у нейбора, тем скорее мы с ним начнем дружить. Не более того. Есть замечательная особенность у SPF, вы должны будете прописать нейборов только с одной стороны. То есть, если вы указываете статический нейбора, то достаточно прописать его только с одной стороны, чтобы соседство установилось. Лучше, конечно, логичнее, если вы прописываете с обеих сторон, и на одном роутере прописываете статический соседа, и на другом. Но достаточно для работы только с одной. Так, что еще тут? Про выключение поддержки RFC 1583 до циски и по умолчанию работает в старом RFC. Метрика агрегатного маршрута минимальная метрика компонентов. Если у вас есть ASBR где-то в сети, то вы в RFC 1583

считаете маршрут до него только на основании суммы стоимости. То есть, если у вас есть давайте попробуем как-то нарисовать вот так вот два региона, например, Area 1 и Area 0. вот и соответственно у нас где-то есть где-то есть АБР 2 АБР и вот например, чтобы нам такое сделать, чтобы такого сделать плохого да, у нас вот есть какой-то роутер и вот здесь какой-то роутер и соответственно у нас есть два варианта как добраться от роутера 1 до роутера 2 роутер 2 будет внешним АБР и соответственно у нас есть вариант либо пойти вот так вот в обход это

получается доступно через ЛСВ и Кутрешку либо пойти как-то вот так вот очень сильно очень сильно но напрямки в пределах своего региона то есть вот этот вот маршрут интроэре он сильно длиннее вот РФС 2328 будет предпочитать интроэре маршруты то есть даже если он длиннее независимо от того какая тут метрика то есть вот эта вот метрика может быть там 1000 а вот здесь вот метрика маршрута будет стоимость маршрута 10 РФС 2328 предпочтет длинный маршрут по своему региону РФС 1583 скажет нам не важно какие маршруты через какие регионы пойдем по более короткому маршруту если вы связываете между собой две железки которые будут работать в разных режимах одна по РФС 2328 другая по РФС 1583 это может вызвать проблемы то есть одна будет говорить считаем более короткий маршрут другая будет говорить считаем более длинный маршрут пример смотрите какая штука вот например у нас есть вот эта вот вот такая вот топология но у нас вот

вот этот вот АБР есть АБР и у него есть вариант куда направить трафик если железка с номером 1 работает по РФС 1583 а вот этот вот АБР работает по режиму РФС 2328 РФС 1583 говорит как добраться до СБР вот так АБР говорит как добраться до маршрут до АСБР который находится с нами в одном регионе только по своему региону соответственно если у нас есть какой-то пакет который предназначен для внешней сети эти два роутера будут этот пакет кидать друг другу до позеленения поэтому если у вас в сети есть железки пожалуйста убедитесь что они работают в одной и той же логике что у вас если везде циски и уст то они работают в 1583 как по умолчанию если у вас есть железки работающие в РФС 2328 переключите все железки в 2328 это скорее всего поддерживается в настройке роутера

указывайте No Compatible РФС 1583 да поведение можно управлять то есть можно сказать циски что не надо работать по старой РФС надо работать по новой в общем-то разница между 1583 и 2328 кроме того что вот на слайде написано особо и нету так все мы прошли теорию про манипуляции с маршрутами давайте на сегодня на этом завершаем наши студии завтра встретимся и проговорим про OSPFV3