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

Да. Настройка OSPF в Cisco. Многие команды здесь мы уже видели. Вряд ли для вас будут какие-то совсем уникальные новые команды в этом модуле. Большую часть, скорее всего, вы видели на CCNA. Просто там мы говорили, давайте мы включим и увидим, что это просто работает. А здесь мы теперь будем включать и понимать, как это работает и почему это работает именно так. Для начала, как включить OSPF на интерфейсе? Я думаю, вы помните, есть команда Network, и можно включить в явном виде на интерфейсе. Когда у нас есть команда Network, которая на интерфейсе включает OSPF, мы указываем рядом, в каком регионе она должна работать. Если мы в явном виде на интерфейсе OSPF включаем, то там указывается, опять же в явном виде, в каком регионе оно должно быть. У Cisco при включении интерфейса в OSPF есть некоторые особенности, как именно она будет этот интерфейс включать в OSPF.

Во-первых, будет автоматически вычисляться стоимость этого интерфейса, и вычисляться она будет по формуле. Как вы помните, чем больше стоимость, тем меньше должна быть вероятность того, что через этот интерфейс пойдёт трафик. Стандартная формула в Cisco OSPF будет заключаться в следующем. Берём некую референсную полосу пропускания, которая по умолчанию 100 мегабит в секунду, и делим на скорость интерфейса. Если вы хотите, вы можете поменять reference bandwidth, и тогда стоимости на интерфейсах будете изменять. Либо вы можете поменять bandwidth интерфейса, сказать, что у вас интерфейс на самом деле не такой, каким кажется. На интерфейсе может быть написано гигабит, а по факту только 100 мегабит. И в любом случае вы можете повлиять на стоимость интерфейса вручную, конечно же. На стоимость интерфейса можно повлиять тремя способами. Первое — повлиять на reference bandwidth, второе — повлиять на bandwidth самого интерфейса, и третье — стоимость назначить вручную. Референсная полоса 100 мегабит даёт вам при скорости 1,5 мегабита — это T1, если вы вдруг забыли, Serial Link — стоимость 64.

При скорости 10 мегабит она даёт вам стоимость 10, при скорости в 100 мегабит она даёт стоимость 1. И при всех более скоростных интерфейсах стоимость OSPF тоже будет по факту 1. Это означает, что сегодня, если вы берёте Cisco роутер, у него с вероятностью единица все интерфейсы будут больше чем 100 мегабит. Поэтому все интерфейсы получат стоимость 1. При настройках по умолчанию современные роутеры Cisco не различают интерфейсы больше чем 100 мегабит в секунду. У них у всех стоимость будет по умолчанию 1. А это означает, что вы с очень большой вероятностью захотите поменять cost на этих интерфейсах, если они у вас по факту неравноправны. Гигабит и 10 гигабит Cisco роутер отличить не сможет. 100 мегабит и гигабит тоже Cisco роутер по умолчанию отличить не сможет. Поэтому reference bandwidth вы наверняка захотите поменять. Дальше. По умолчанию IOS работает в режиме совместимости со старым RFC 1583.

Это означает, что если вы будете делать суммаризацию, то она будет иметь минимальную стоимость, вопреки тому, что написано в RFC 2328, что надо делать максимальную стоимость из отдельных компонентов. И ещё из особенностей — router ID будет у нас по стандартному алгоритму. Сначала самый большой loopback на этом экземпляре OSPF. Если у нас есть loopback, который мы включили в OSPF, router ID берётся с него. Если у вас есть loopback просто какой-то на железке, но он не включён в OSPF, тогда будет браться самый большой IP-адрес с него. Или если у вас loopback вообще никаких нет, то берётся просто самый большой IP-адрес. Здесь более правильно сказать — на виртуальных интерфейсах. Да, loopback и loopback. Вряд ли вас будут спрашивать на экзамене про разницу между этими двумя пунктами. На самом деле может быть такое, что у вас самый большой IP-адрес на loopback будет,

но Cisco будет выбирать router ID каким-то иным образом. Именно потому, что она сначала выбирает loopback, который входит в экземпляр OSPF. Включается OSPF либо командой Network, либо ip ospf 1 area 0. Это экземпляр OSPF, это регион. Мы в явном виде, когда включаем OSPF на интерфейсе, обязаны сказать, в какой регион он будет смотреть. Если вы используете команду Network, по факту вы задаёте условие access list, и все IP-адреса, которые у вас на интерфейсах попадают под это условие access list, включаются в регион, который опять же в команде Network задан. Неочевидный момент. Вы можете сделать несколько команд Network, которые будут иметь разную wildcard маску, и как следствие у вас IP-адрес на интерфейсе может попасть под несколько разных команд Network. И у них не обязаны быть одинаковые регионы. Это Area 0 может быть такое, что вы скажете рядом Network 192.168.1.1 по маске 0.0.0.0 Area 1.

Если вы такое сделаете, у вас попадёт IP-адрес 192.168.1 и сюда, и сюда. И, соответственно, возникает вопрос, какой Area выбрать? В этом случае Cisco выбирает наиболее специфичную команду Network, ту команду Network, у которой нулевых битов в wildcard маске больше. Отсюда возникает следующее следствие. Вы обязаны здесь указывать wildcard маску, у которой сначала идут все нули, а потом все единицы. Так же, как в прямых масках для IP-адресов, мы говорим, в принципе теоретически RFC 950 позволяет нам для обычных нормальных прямых масок сказать, что у нас маска будет сначала некоторое количество единиц, потом некоторое количество нулей, потом снова некоторое количество единиц, снова некоторое количество нулей. У нас нолики-единички могут быть в IP-адресах перемешаны, которые относятся к host ID и к network ID. Но это не принято делать, и никто так сейчас по факту не делает. И все последующие RFC ориентируются на то, что у вас в network маске обычные — сначала идут все единички, потом нолики.

В wildcard масках для access list мы можем перемешивать нолики и единички, но в условии команды Network для OSPF вы обязаны сделать wildcard маску, в которой сначала идут все нолики, а потом все единички. И поэтому одна из них будет иметь больше нулей, а вторая — меньше нулей, если у вас есть две команды Network. И, соответственно, та, у которой нулей в маске будет больше, она будет более специфичная, и настройки региона для интерфейсов будут браться с неё. Если вы в явном виде на интерфейсе сказали ip ospf и area, то это переопределяет действие команды Network. Даже если у вас есть несколько команд Network, под которые попадает IP-адрес на интерфейсе, но есть эта настройка, то в этом случае она считается самой специфичной — логично — она переопределяет действие команды Network, и, соответственно, регион берётся тот, который в явном виде на интерфейсе прописан. Я вам рекомендую прописывать на интерфейсе OSPF всегда в явном виде. Несмотря на то, что командой Network можно накрыть одновременно много разных интерфейсов,

читается конфигурация намного лучше, когда вы прописываете в настройке интерфейса указание, что он работает в OSPF. И troubleshoot это намного легче. Когда вы включаете OSPF на интерфейсе, у вас начинается отправка Hello пакетов, плюс connected сети попадают в анонс, включаются все connected сети, включая те, которые secondary, и те, которые static attached сети. Если вы пропишете что-то типа ip route 10.1.0.0 маска 255.255.0.0 interface GigabitEthernet 0/1, то это считается attached сеть, она показывается как connected,

и она тоже включается в анонс OSPF нативным естественным образом. Но Hello пакет вы будете отправлять только с primary адреса. Если вдруг у вас есть и primary, и secondary адреса, то Hello пакеты с secondary вы не отправляете, соседство с них не установится. Роутеры будут проверять, что у вас IP-адреса одинаковые и что они находятся в одной сети. Дальше. Как вы помните, даже в Hello пакетах будет передаваться маска сети, которая у вас есть, поэтому не просто IP-адреса должны быть в одной сети с точки зрения соседа, а ещё и маска обязана быть одинаковая. Правда, некоторые устройства, некоторые реализации это не будут проверять. Так. По поводу стоимостей. Можно на интерфейсе стоимость прописать в явном виде. Команда ip ospf cost и дальше число. Число двухбайтовое, как вы помните, метрика OSPF первого типа может быть двухбайтовая. И здесь как раз видно, что она такая и есть.

И вы можете повлиять на стоимость неявно, либо поменяв bandwidth, это очевидно, что это можно сделать, либо поменять reference bandwidth. Команда в настройке роутера: auto-cost reference-bandwidth и дальше число. Задаётся это число в мегабитах, но по факту можно здесь увидеть, что это число 4 миллиарда 294 миллиона 967 тысяч. На самом деле ему здесь не хватает трёх знаков, для того чтобы получить 2 в 32-й степени. Поэтому по факту здесь было бы неплохо понимать, что килобиты больше подходят под это. Но тем не менее по умолчанию мы здесь задаём именно в мегабитах, и по умолчанию здесь значение будет 100. Если вдруг вы захотите поменять автоматическую reference bandwidth, чтобы она, например, различала интерфейсы 10 гигабит и гигабит, вам нужно эту стоимость сделать как минимум 10 тысяч,

чтобы 10 тысяч делилось на скорость интерфейса, и у вас получались бы разные значения для гигабитных и 10-гигабитных линков. Для 10 гигабит у вас будет единичка, для гигабита будет десятка. Имейте, пожалуйста, в виду, что разные роутеры не обязаны стоимости считать по одной и той же логике. И если вы берёте Cisco и не Cisco, совершенно не факт, что стоимость интерфейсов они друг на друга автоматически посчитают одинаково. И вполне может быть такое, что у вас будет один роутер и другой роутер, и они связаны между собой, и один роутер скажет: у нас этот интерфейс гигабит, и, соответственно, стоимость на нём должна быть 1, потому что это Cisco IOS. А другой скажет: у меня Cisco Nexus, например. И, соответственно, здесь стоимость будет считаться по другой референсной полосе, делённой на скорость интерфейса. Там другая референсная полоса.

Допустим, либо Nexus, либо IOS с изменённым reference bandwidth. И он скажет, что у меня 20 гигабит, делённая на скорость интерфейса, получается метрика 20. Ничего страшного, пазл всё равно сойдётся, несмотря на то, что стоимости будут разные. Просто трафик, который будет проходить в одном направлении, будет считать, что метрика здесь единица. Трафик, который будет проходить в другом направлении, будет считать, что метрика 20. Вы можете встретить пример, когда действительно будет нужно на интерфейс повесить стоимости разные в разных направлениях. Например, если у вас интерфейс будет ADSL. ADSL — это асимметричный канал. Буква A означает «асимметричный». Пропускная способность в одном направлении и в другом направлении у него не одинаковые. Именно это означает слово «асимметричный». И, соответственно, в этом случае мы говорим, что у нас в одном направлении производительность 640 килобит в секунду, а в другом направлении у нас 8 мегабит. И, соответственно, стоимость здесь, допустим, одна, а стоимость в другом направлении будет, допустим, 12.

И таким образом мы сможем адаптироваться под то, что у нас действительно интерфейсы имеют неодинаковую производительность в разные стороны. Опять же, никто вас не обязывает выставлять стоимости в логике «чем меньше, тем лучше». Вы вполне можете сказать, что у вас есть интерфейс, у которого стоимость будет — давайте вот два роутера нарисую. Вот у нас два роутера. Они смотрят на одного и того же соседа. И, соответственно, у нас здесь есть какая-то сетка, допустим, сеть A. И между ними есть связь. И мы говорим: у нас на одном роутере запускается Cisco IOS. Она говорит: этот интерфейс стоит 10. 10-мегабитный интерфейс имеет стоимость 10. А другой — это Nexus, он говорит: у меня этот интерфейс будет гигабитный, но, соответственно, метрика, допустим, там 20 гигабит по умолчанию, деленная на 1 гигабит, получается метрика 20. Давайте вот здесь нарисую ее. И, соответственно, вот здесь вот он говорит, интерфейс,

который смотрит на соседа, будет иметь метрику единичка, потому что здесь, например, не знаю, 20 гигабит линк. И в этой ситуации, несмотря на то, что Nexus может пустить трафик по гигабитному линку сразу напрямую до роутера, а он скажет, с точки зрения математики 1 плюс 10 выгоднее, чем 20, потому что, соответственно, у меня здесь 20 гигабитный линк, я 20 гигабит авторинференс, делю на скорость интерфейса 20 гигабит, например, вот так вот Ether Channel здесь есть, он как раз 20 гигабитный, из двух десяток составленный, и стоимость у него будет 1 копеечка. Трафик, который пойдет вот так вот, он будет проходить по маршруту стоимостью 11. Трафик, который пойдет напрямки, он пойдет по маршруту стоимостью 20. И в этом случае Nexus будет считать, что надо пустить трафик в обход. Хотя, да, вот здесь вот 10-мегабитный линк, стоимость ему десятку EOS назначил в соответствии с какой-то своей логикой. У него она была другая. Поэтому, если вы хотите, чтобы у вас трафик ходил логичным образом,

убедитесь, что все роутеры считают стоимости в одинаковой логике. Или хотя бы, что вы ручками проставили стоимость интерфейсов в одинаковой логике. Чем меньше стоимость, тем больше, вероятно, прохождение трафика по нему. Сейчас у нас получается, да, что 10-копеечный линк 10-мегабитный получается более интересный, более приоритетный, чем 20-копеечный линк на другом роутере, который на самом деле гигабитный. Вот, чтобы такого не было, убедитесь, что все роутеры у вас работают в одной логике. По умолчанию это нигде не проверяется. Это ваша ответственность как администратор за то, чтобы проследить, что все интерфейсы имеют правильную логику. Так, если хотите объявить интерфейс пассивным, здесь все просто. Пассив интерфейс. Сетки анонсируются, HelloPacket не посылаются. Ну, HelloPacket не посылаются, как следствие, никто нас не похакает, никто не увидит, как мы настроены. Даже если мы не настроили требование предъявлять пароль, все равно мы просто не установим соседство на этом интерфейсе.

Далее. У Cisco есть одна хорошая, скажем, особенность. Cisco компания, которая делает большое количество всяких инноваций. Если посмотреть на то, кто придумывает RFC, их придумывают не какие-то сферические боги в вакуум, их придумывают инженеры, работающие как раз в крупных сетевых компаниях. Cisco придумывала огромное количество всяких RFC. Но в случае с USPF есть очень интересная особенность. USPF стандартный протокол, в котором есть 5 типов канальных сред. Broadcast-овая, Point-to-Point-V, Point-to-Multipoint-V, Non-Broadcast-V и Virtual Link. У Cisco поддерживается 7 типов канальных сред. К перечисленным 5 есть еще дополнение Point-to-Point, Non-Broadcast и Loopback. С Loopback там все просто, а вот этот Point-to-Multipoint, Non-Broadcast, это новый тип среды, которого в стандарте нет. И, соответственно, ведет он себя немножко необычным образом. Более того, если посмотреть на то, что в стандарте

описано, в RFC 2328, то выяснится, что Cisco понимает свои обозначения, обозначения вот этих вот типов канальных интерфейсов по-своему, у нее поведение этих интерфейсов будет отличаться и работать не по стандарту. Поэтому, если вдруг у вас есть гетерогенная среда, в которой есть Cisco роутеры и есть не Cisco роутеры, убедитесь, пожалуйста, что типы интерфейсов, которыми вы будете назначать железки друг на друга, они себя будут вести в соответствии с какой-то вот общей логикой. Потому что это совершенно не факт, что если вы с одной стороны включаете один тип среды, который там называется, к примеру, Point to Multipoint с одной стороны и Point to Multipoint на Cisco с другой стороны, что это действительно будут одинаковые Point to Multipoint. Cisco понимание Point to Multipoint и стандартное появление, стандартное описание Point to Multipoint различаются, они не совпадают. Поэтому будьте здесь осторожны. На экзамене весьма вероятно вас заставят сказать,

какие типы канальных сред, которые поддерживаются Cisco по факту будут стандартными. И здесь вас ожидает еще один сюрприз. Официальное руководство Cisco говорит, что некоторые вещи из тех, которые Cisco поддерживает, они нестандартны, хотя они таковыми являются. И наоборот. Вот, например, Cisco говорит, что бродкастовая среда это нестандартный тип. И возможно, в каких-то старых ревизиях RFC действительно не было такого типа среды. Но в RFC 23-28 оно есть. А Cisco говорит, что на своем экзамене его нету. Поэтому будьте аккуратны. Пожалуйста, имейте в виду, что на экзамене нужно будет говорить, что бродкастовая среда это нестандартная среда. А на самом деле она стандартная. Point to point тоже самое. Якобы его нету, а на самом деле оно есть. Это стандартный тип взаимодействия с соседями. Non-broadcast и OSPF Virtual Link стандартные вещи. И Cisco их поддерживает. Здесь никаких сюрпризов нет. Point to multipoint это якобы Cisco говорит,

что оно есть. Но здесь есть нюансы. Оно действительно есть. Просто понимание Cisco того, как работает Point to multipoint и понимание стандартного того, как работает Point to multipoint, оно разное. Поэтому, несмотря на то, что как бы да, RFC 23-28 штука с таким названием есть. И Cisco говорит, что это стандартное взаимодействие Point to multipoint. На самом деле нифига подобного. Это поведение нестандартное. И поэтому здесь якобы да, именно в том смысле, что на самом деле оно не стандартное. Point to multipoint non-broadcast обратная ситуация. Cisco говорит, что такого нету. А на самом деле вот то, что Cisco называет Point to multipoint non-broadcast это на самом деле Point to multipoint стандартный, обычный RFC. В RFC такого действительно нету. Описания такого названия нету. Point to multipoint non-broadcast. Но это обычный Point to multipoint, который есть в RFC. Что здесь можно будет про каждый из этих каналов сказать? Broadcast, которого якобы нет в RFC, это самый обычный

Broadcast. Это среда, в которой есть мультикаст, в которой все друг с другом полно связанные топологии имеют. У нас выпускается LSA-ка второго типа, выпускается она DRM, который, естественно, выбирается. За счет мультикаста мы автоматически обнаруживаем соседей, анонсируется вся сетка целиком, то есть в этот вот самый транзитный сетка, который можно с помощью префикса сапрешеном скрыть. И таймер там по умолчанию 10 на 40. Если у вас Point to Point соседство, то же самое. Мультикаст там, ну, в кавычках, есть он, да, просто автоматически отправляем пакет в среду и все узлы в этой среде, весь один узел в этой среде автоматически этим мультикастом, он же Broadcast, он же Unicast накрывается. Соседство автоматическое. Full mesh там, ну, естественно, есть с тем единственным соседом, с которым у нас взаимодействие есть, он, ну, Full mesh. DR, BDR в этой среде не нужен, таймеры такие же 10 на 40. Анонсируется, опять же, вся сетка целиком. Point to MultiPoint это якобы

стандартная штука с точки зрения CISC, на самом деле не стандартная. Она говорит, что если у нас есть OSPF 2 роутера, то есть один роутер и другой роутер, который дружит через канал, в котором вы хотите объявить тип среды Point to MultiPoint. Вот если вы это сделаете с точки зрения CISC, то у вас автоматически должны обнаружиться соседи. И автоматически соседи должны обнаружиться за счет того, что у вас есть эмуляция MultiCast. Вот эта вот эмуляция MultiCast это то, чего в стандарте нигде не прописано. Вот, вы отправляете MultiCast пакет, и он кое-до-кого дойдет. И кое-до-кого автоматически дойдет такой MultiCast пакет, и с тем, до кого такой пакет дошел, будет установлено соседство. Но этот MultiCast дойдет не до всех, потому что FullMesh у вас нету. Вот, и в такой среде соответственно нельзя выбирать DR, BDR, нельзя выбирать LSA-ку второго типа, и поэтому вы каждому отдельному соседу по факту должны будете отправлять

отдельный HelloPacket. Но вы отправляете отдельный HelloPacket в отдельных кадрах, кадры будут Unicast-овые. А по факту внутри будет лежать MultiCast-овое вложение, и MultiCast-овое вложение в несколько Unicast-овых кадров будет превращать как раз эмулятор MultiCast-а. Вот эта вот штука, эмулятор MultiCast-а, мы ее увидим в DMVP-не, я вам обещал сделать на него Labo, и как раз да, вот, она есть во FrameRelay, она есть в DMVP-не, но она никоим образом нестандартная, поэтому PointU-Multipoint это поведение нестандартное. таймер 30 на 120, потому что Cisco понимает, что по факту, когда вы говорите, что у вас эмуляция Broadcast-а будет, на самом деле она отправляет весь трафик Unicast-ом, и сколько у вас соседей есть, столько сообщений за один цикл у вас будет по факту отправляться. Поэтому таймер здесь 30 на 120. Вы генерируете один MultiCast-овый пакет, который превращается в кучу Unicast-ов эмулятором, и дальше отправляется

по отдельности один пакет, другой пакет, третий пакет, и так далее. Поскольку полной связи нету, то анонсировать всю сетку нельзя, анонсируются отдельные хосты. Non-Broadcast- стандартное поведение, то есть это полно связанная топология, в которой нет MultiCast-а. Как следствие, вы должны будете статически прописывать всех соседей, и после того, как вы соседей прописали, вы выпускаете LSO-ку второго типа и говорите, я вот вижу DR-а, и он видит всех остальных. Но при этом HelloPacket-ы вы отправляете на каждого Unicast-ом, поэтому таймер 30 на 120. Анонсируется вся сетка, как и всегда, когда у нас есть LSO-ка второго типа. Ну, с Virtual Link-ом все, да, понятное и предсказуемо. MultiCast-а там как бы нету, это воображаемый псевдопровод. FullMesh тоже как бы псевдопровод, там, про псевдопровод как-то говорить не приходится. Соседство в Virtual Link-е прописывается вручную, ничего автоматически не обнаруживается. DR-бдр там, естественно, не выбирается, таймеров никаких нету. Один раз вы устанавливаете

Hello соседство и после этого вы ожидаете, что если сосед отвалится, вы об этом узнаете не потому, что он вам присылать Hello перестал, а потому, что вы узнаете об этом из лосейки первого типа. Если сосед помрет, вы увидите, что сосед помер через лосейки первого, второго типов внутри ненулевого региона. Поэтому таймеров там никаких нету. Hello пакеты не посылаются, вы не ожидаете, что сосед по Virtual Link-у вам будет что-то присылать периодически. Ну и, соответственно, никакой сети там нету, это воображаемый псевдопровод, там никакого транзита в нем не будет. И в Point-a-Multipoint Non-Broadcast это вот то, что Циско говорит якобы новая штука, которая никогда раньше не была. Это то, что называется обычный Point-a-Multipoint с точки зрения RFC. Среда, в которой никто никого не видит, ну, кое-кто кое-кого видит, мультикаста нету, соседи прописываем ручками, DR-BDR не выбирается, анонсируется хост-нетворк. Loopback это фирма

на Цисковской фиговина. Когда вы создаете Loopback, который включается в в в в в в SPF на Циске, то у вас на этом интерфейсе не обнаруживаются соседи, вы не отправляете HelloPacket, нет смысла отправлять в Loopback HelloPacket, какой смысл в этом? Поэтому Циск автоматически обнаруживает, что вы включили в SPF на Loopback и говорит, я не буду туда отправлять никакие HelloPacket, я не буду там выбирать LSA, я не буду пытаться установить соседство, я просто анонсирую хостовый IPшник slash 32, который висит на этом интерфейсе. Обратите внимание, если у вас есть роутер, и вы на этом роутере делаете Loopback интерфейс, Loopback 0, и вы на этом Loopback интерфейсе вешаете IPшник 10, там 0, 1, 0, slash 24, вот по факту, здесь 0, 1, 1, 24, по факту у вас анонсируется ваш IPшник по 32 маске, у вас slash 24 сетка не анонсируется,

именно потому, что анонсируется хостовый IPшник всегда на Loopback интерфейсе. Если вы хотите на Loopback сказать, что у вас не надо анонсировать 32 сетку, анонсировать надо именно Connected сетку, которая на интерфейсе висит, то вы должны будете поменять тип среды на Loopback с Loopback на какой-то другой, где у вас есть анонс всей сети. То есть, это либо Broadcast, либо Point-to-Point, либо Non-Broadcast. Но забегая вперед, Broadcast и Non-Broadcast вы объявить на Loopback не можете, поэтому вам остается только Point-to-Point. Вот вы можете сказать на Loopback, пожалуйста, Cisco, не трактуй этот интерфейс с точки зрения OSPF, как тип канальной среды Loopback, а трактуй этот тип канальной среды Point-to-Point. Кажется, лишено смысла, на самом деле, это делается именно ради того, чтобы анонсировать сетку, а не отдельный хостовый IP-шник. Опять же, сейчас Labo будем делать и увидим, зачем это будет нужно. Команда будет на интерфейсе IP, OSPF, Network, и дальше вы указываете тип канальной среды, который поддерживается конкретно этим интерфейсом.

Cisco по умолчанию будет назначать типы достаточно точно. Она будет говорить, что если у вас есть Ethernet, или Token Ring, или в DDI интерфейсе, то там назначается тип среды Broadcast. В этих средах есть Multicast, в этих средах есть полносвязная топология, поэтому Broadcast там прекрасно себя будет чувствовать. Если у вас есть тип среды Frame Relay, то есть вы на интерфейсе Frame Relay, на родительском интерфейсе, подчеркну, включаете OSPF, или на ATM интерфейсе, или на X25 интерфейсе, включаете OSPF, вам назначается тип среды Non-Broadcast. Предполагается, что если у вас тип среды Non-Broadcast, то у вас там полно связанная топология. Во Frame Relay это совершенно необязательно. То есть может быть такое, что у вас есть Frame Relay Switch, и соответственно к этому Frame Relay Switch, или к Frame Relay облаку, вы подключаете три роутера, и вы не между всеми тремя покупаете связность. То есть вы говорите, у нас вот эта вот связность есть, и вот эта вот связность есть.

Но соответственно вот этой связности у вас нет. вы не заплатили денег, и провайдер вам не прописал соответствующие PVC-шки. Вот в этом случае вы должны будете поменять этот тип среды Non-Broadcast, потому что Non-Broadcast предполагает, что у вас полно связанная топология. Дальше. Если у вас есть интерфейсы туннельные, то OSPF по умолчанию назначает на них Point-to-Point тип. Для Great Tunnelей, для IP-IP-туннелей, для большинства туннелей на самом деле это вполне осознанное явление. Но есть нюанс. DMVPN, он как бы тоже туннель считается, только там Multipoint, ГРИЕ. И вот если вы указываете, что у вас будет Point-to-Point тип среды, а по факту вы говорите, что у вас на этом интерфейсе есть несколько разных соседей, например, за счет этого самого Multipoint, ГРИЕ, DMVPN-овского, у вас OSPF сломается на этом интерфейсе. На Point-to-Point интерфейсе OSPF не ожидает увидеть больше одного соседа. Если он установил соседство с кем-то на туннельном интерфейсе,

вот этот вот туннель, 0, и у него есть сосед, с которым он дружит, он получил Hello пакет от него, и он говорит, я вижу одного соседа, а потом в этот же интерфейс еще кто-то другой пришел, он тоже посылает нам Hello, и вот если у вас тип среды на туннельном интерфейсе по умолчанию Point-to-Point, то старое соседство развалится, а новое переустановится. На Point-to-Point интерфейсе вы не можете держать больше одного соседства. Point-to-Point будет назначаться автоматически на туннельных интерфейсах, на сериал-линках с инкапсуляцией HDLC или PPP, и на субинтерфейсах Frame Relay Point-to-Point типа. Ну и на ATM интерфейсах тоже Point-to-Point субинтерфейсах. На лупбеке. Ну, очевидно, что лупбек у вас автоматически назначается на лупбеке. Вы не можете объявить тип среды лупбек, ни на чем, вообще нигде. Можно на лупбеке только сказать, что у вас будет Point-to-Point. А вот на не лупбеке поставить лупбек нельзя.

Дальше. Point-to-Multipoint и Point-to-Pultipoint Non-Broadcast надо назначать вручную. Ну, скорее всего, Point-to-Multipoint Non-Broadcast вы захотите сделать на Frame Relay Point-to-Multipoint субинтерфейс. Это такой специальный тип среды для Frame Relay Point-to-Multipoint субов. Но, опять же, по умолчанию на субах у вас ничего специально выбираться не будет. Там будет выбираться Non-Broadcast. Так. Дальше. Что еще здесь можно будет сделать? По-моему, таймеры... Да, про таймеры я забыл сказать. Обратите внимание на то, что таймеры на разных типах интерфейсов будут разные. И если вдруг у вас есть несколько роутеров, которые друг с другом дружат, но один роутер считает, что у него тип среды какой-то один, а другой какой-то другой, то имейте, пожалуйста,

в виду, что Cisco по умолчанию эти таймеры, соответственно, будут назначать на разных интерфейсах, на разных типах интерфейсов по-разному. Если у вас с одной стороны будет тип среды Point-to-Point, а с другой стороны Point-to-Multipoint, то у Point-to-Point таймеры 10 на 40, а у Point-to-Multipoint таймеры 30-120. И соседство в этом случае не получится. Они будут отправлять друг другу HelloPacket и будут заявлять разные таймеры. Для того, чтобы соседство получилось, надо таймеры будет ручками подкрутить. Ну, и еще один момент, да, кроме таймеров, желательно, чтобы совпадали режимы выбора DR и BDR, потому что, если у нас в Point-to-Point и Point-to-Multipoint все хорошо, DR-BDR не выбираются в обоих случаях. То, например, если у нас будет с одной стороны Point-to-Point, а с другой стороны будет, например, Broadcast, то в этой ситуации получится, что Broadcast у нас выбирает DR, а Point-to-Point DR не выбирает. И один из роутеров будет собирать пазл с использованием LSEC второго типа, а другой без. Не сказать,

чтобы это обязательно привело к проблемам. Ну, да, это может привести к проблемам, потому что пазл у вас в итоге будет очень странный. Так. Да. Назначается на интерфейсе IP, OSPF, Network, и дальше указываете тип интерфейса. Еще на интерфейсе можно будет сделать всякие разные другие няшки. Например, можно будет назначить приоритет при выборах DR, BDR. из всех роутеров, которые будут в интерфейсе друг друга находить, DR будет выбираться тот, у которого приоритет максимальный. А если таковых несколько, то будет выбираться тот, у кого будет больше... Сейчас соображу. Вечно забываю, IP-шник или ID-шник. ID-шник, наверное. Или IP-шник. старость, не радость. Да, ID-шник. Специально перепроверил. Да,

посмотрел в RFC. Сначала сравнивается приоритет, потом ID-шник. У кого больше, тот и прав. Соответственно, да, в случае, если у нас кто-то захотел стать DR-ом, он выбирается DR-ом и остается таковым до позеленения до тех пор, пока он не сдохнет. Ну, соответственно, да, и BDR тоже назначается, и после этого BDR ждет, чтобы DR сдох, и тогда он таковым станет. Если вы указываете приоритет 0, то в этом случае вы отказываетесь от участия в выборах и DR-а, и BDR-а. То есть, вы никогда не обещаете не быть ни DR-ом, ни BDR-ом. Еще раз напомню, что в OSPF-е процедуры выборов как таковой нет. Каждый роутер в голове у себя делает свое собственное решение, кто с его точки зрения должен стать DR-ом, кто с его точки зрения должен стать BDR-ом. То есть, там нету процедуры вида два роутера подрались и решили, что один из них более достоин стать DR-ом, чем другой. То есть, каждый роутер, исходя из той информации,

которая у него имеется, принимает решение о том, кто с его точки зрения правильный DR. Ну, и если у вас действительно вся топология сходится, если у вас полно связанная топология, где можно выбирать DR-а, BDR-а, везде мультикаст ходит, то в этой ситуации ваш роутер будет получать hello-сообщение от всех, будет видеть все приоритеты и в этом случае он сможет выбрать DR-а и BDR-а правильно. Если ваш роутер получает hello-сообщение не от всех, потому что у вас, например, мультикаст какой-то странный, смотри, например, с DMVPN, то в этой ситуации роутер может назначить DR-а и BDR-а неверно. И, да, он может, например, назначить DR-ом себя и какой-то другой роутер, возможно, в этом же канале, скажет, что DR- будет own. И у вас получится, что есть как бы два DR-а, они выпускают за одну и ту же среду две LSE-ки и это приведет к неправильной сборке пазла. Поэтому, если в каком-то случае вы знаете, что у вас, например, нету полно связанной топологии со всеми остальными с помощью мультикаста,

вы как раз хотите отказаться от выборов DR-а и BDR-а, чтобы никогда, ни при каких условиях никто даже бы не подумал, что вы можете быть DR-ом. И вы сами в первую очередь. В DMVPN очень полезная вещь. Если у нас есть хаб DMVPN-овский и пачка с полков. Вот у нас связь между DMVPN-овским облаком и всеми с полками есть, но Unicast работает между всеми, а вот Multicast работает только между хабом и с полками. И, соответственно, если с полки друг другу будут посылать Hello-сообщение, они не пройдут. И поэтому с полки приоритеты друг друга не знают. Они видят Hello только от хаба. И в этой ситуации в DMVPN-е правильным будет сказать, что на наших с полках мы выставляем приоритет 0 для того, чтобы с полки никогда даже не пытались возомнить себя DR-ом. И в этом случае DR-ом будет выбран хаб неизбежно. У него есть действительно полная мультикастовая связанность со всеми и с ним все будет хорошо

работать. Дальше. Вы можете указать, как часто вы отправляете Hello-пакеты. Если вы выставляете Hello-interval IPOSPF Hello-interval дальше число, то таймер Dead Interval автоматически выставляется кратный четырем. То есть, если вы говорите IPOSPF Hello-interval 8 Dead Interval 0 Dead Timer Hold Time у вас выставляется в 32 автоматом. Если вы хотите его ручками поменять, можете указать IPOSPF Dead Interval и некое число. Есть возможность сказать вот такую хитрую штуку IPOSPF Dead Interval Minimal. Это значит, что у вас Dead Interval будет 1 секунда. Но это предполагает, что у вас должен в этом случае быть минимальный Hello-таймер. Как часто вы отправляете Hello-пакеты? Нет никакого смысла выставлять Hello-таймер в минимальное значение, чтобы потом сказать IPOSPF

Dead Interval Minimal. Вот если вы указываете IPOSPF Dead Interval Minimal, то это значит, что Hello-таймер у вас должен быть меньше секунды. И вы должны будете продолжить эту команду указанием Hello Multiplayer и дальше сколько сообщений в секунду вы будете посылать. То есть, если вы указываете IPOSPF Dead Interval Minimal, то вы одной командой задаете и Hello-таймер и Dead Interval. Сказать, что это опять же имеет смысл нельзя. Если вы хотите обнаруживать отказавших соседей как можно быстрее, возможно, имеет смысл использовать BFD. Bidirectional Forward Detection. Но, если у вас его нету, если вы, например, с цисками работаете, то вот эта штука в принципе неплохо будет BFD заменять. Она будет отправлять много пакетов в секунду и будет обнаруживать отказ соседа за время чуть больше одной секунды. То есть, сосед отваливается и через секунду вы говорите, что с момента получения последнего Hello-сообщения от него прошло больше одной секунды, Hello не приходит,

следовательно, связи нет. Опять же, будьте осторожны, потому что, если вы связываетесь, например, через какой-то горе, я тут туннель или что-то еще, то есть, через провайдера, и у провайдера где-то что-то происходит, он начинает немножко козлить, например, потеряет трафик за одну секунду, да, у вас ОСПФ соседство развалится, но, но, по факту, очень быстро оно должно при этом восстановиться, и у вас получится, что часть трафика вы направите по альтернативной трассе, но при этом обратно перескочите на основную трассу весьма быстро, и у вас может быть такое, что если будет происходить такая штука часто, приложения от этого будут страдать, то есть, трафик ходит, ходит по нормальной трассе, потом быстро вы перескакиваете на запасную трассу, быстро снова на основную, и у вас приложение от этого, ну, там, либо, если это голос, они могут ходить, пакеты голосовые по разным трассам за разное время, у вас голос будет булькать при переключении, если переключение происходит часто, ну, значит, да, будет булькать часто,

может быть такое, что TCP-шный реордеринг будет вызывать переотправку с Пуриус или трансмишн, ну, то есть, не всегда это желательно, чтобы вы быстро обнаруживали падение соседства, особенно, если у вас какие-то внешние каналы, тем более, что на самом деле с помощью вот этих вот Hello пакетов, которые вы будете отправлять постоянно в секунду, там будет тратиться, ну, пусть не очень большое количество трафика, но все-таки будет, если у вас оплата за трафик, то вы можете за вот эти вот Hello пакеты, которые вы отправляете штуками в секунду, да, немножко заплатить денег. Так, я рекомендую, если у вас поддерживается BFD, использовать именно его. Что делать, когда OSPF хорошо работает? Радоваться жизни. Что делать, когда OSPF плохо работает? Проверять, траблшутить? Show IP Protocols, Show IP OSPF показывает настройки процесса OSPF. Ну, в общем, эти команды мы уже видели. Show IP Protocols для EJRP показывает

всякие разные полезные штуки. Так, а где он есть? Чего нету? Ну, ладно. Show IP Protocols, да, покажет базовые настройки OSPF, плюс их же покажет на самом деле Show IP OSPF. То есть, в Show IP Protocols и Show IP OSPF показывается примерно одна и та же информация. Плюс, можно траблшутить интерфейсы, которые в OSPF включились. Плюс, можно смотреть, какие соседства установлены через эти интерфейсы. Плюс, можно посмотреть, что OSPF посчитал, какие маршруты у него будут кратчайшие. Плюс, можно посмотреть, что в таблице маршрутизации из OSPF взялось. Как водится, это все разные сущности. Как посмотреть, какие интерфейсы включены в OSPF? Show IP OSPF интерфейс по аналогии, в принципе, с EJRP. У нас там было Show IP EJRP интерфейс, здесь Show IP OSPF интерфейс. Но есть нюанс. Если вы просто закажете Show IP OSPF интерфейс, вам покажется простыня интерфейсом. Если вы захотите, вы можете ограничить вывод, сказать, что вас интересует

простыня только за один интерфейс, указав в явном виде, какой интерфейс вас будет интересовать. Show IP OSPF интерфейс, там не знаю, туннель 0. Но если вы хотите просто табличку посмотреть, как EJRP, то для этого надо указать Show IP OSPF интерфейс brief. И вот эта вот команда покажет именно табличку. Покажет по каждому интерфейсу, в каком экземпляре OSPF оно завелось, в каком регионе, какой IPшник на интерфейсе кто мы на этом интерфейсе, если мы выбираем DR, BDR, или мы DR, или мы DR, или мы DR other. И сколько у нас соседей обнаружилось на этом интерфейсе, с кем из них мы установили полные соседские взаимоотношения. И учитывая, что здесь у нас на интерфейсе всего два соседства, всего два роутера, одно соседство, то, соответственно, вот мы обнаружили одного соседа и с ним перешли в полные взаимоотношения в фазу full. Но если у нас, например, соседей будет 5, то один из них может быть будет DR, второй из них будет BDR, а остальные,

сколько получается, 3, да, они у нас будут DR other. У нас будет показываться 2,5. Сколько полностью соседей, сколько полных соседей и сколько всего обнаружено. Feasible account. Дальше. ShowIPoSPF Neighbor покажет соседей. Вот в нашем случае 10,002 сосед. Приоритет у него при выборах DR и BDR единичка. Ну, скорее всего, такой же, как у нас. С ним установлены полные соседские взаимоотношения. И этот сосед BDR. То есть мы на этом интерфейсе DR, а он с нами в одном интерфейсе BDR. Dead timer. Через сколько признаем соседа трупом. Дальше. Вот эта вот штука это ID-шник соседа, вот эта штука это IP-шник соседа. Они могут визуально совпадать, но Neighbor ID это не IP-адрес. А вот эта колонка, она как раз показывает IP-шник, от которого нам приходят Hello-пакеты.

И последний это интерфейс, на котором мы увидели соседа. После того, как сосед установил с нами соседство, прислал нам LSA-ки. LSA-ки мы посчитали кратчайшие маршруты, поставили все маршруты в таблице маршрутизации. ShowIPoSP показывает, что действительно маршруты SPF-овские есть, буквы О показываются. Вот IP-шник сети, маска, административное расстояние 110, метрика 2 и NextHop 10.001. То есть, это все базовая работа SPF-а. Если вдруг нам интересно будет детально посмотреть какой-то конкретный интерфейс, то ShowIPoSPF интерфейс и вот конкретный интерфейс нам здесь покажет кое-какие интересные вещи. Во-первых, покажется, откуда этот интерфейс взялся в SPF-е. Вот именно этот интерфейс взялся не за команды Network, а из-за того, что мы прописали IPoSPF какой-то, Area какая-то. Я думаю, что это был IPoSPF 1, Area 0. Дальше показывается, какой тип среды у нас используется. По умолчанию

на Ethernet интерфейсах используется Broadcast среда. И вот мы здесь видим, что Broadcast, как следствие, у нас есть элассейка 2 типа, как следствие, у нас таймеры 10 на 40, как следствие, у нас выбирается DR-BDR, вот. Как следствие, да, мы имеем полно связанные топологии, поэтому анонсируется та сетка, которая у нас висит на интерфейсе. 10, 1, 2, 0, по 24-й маске. 10, 1, 2, 0, слэш, 24. Анонсируется сетка. Вот. Можно будет на интерфейсе, соответственно, анонсировать какие-то еще сетки, то есть, если у нас здесь вот в секондре сетки были бы какие-то, то они бы тоже анонсировались. Мы на этом интерфейсе BDR, мы BDR, потому что у нас приоритет 1, а у DR-а оказался IP-шник больше, чем у нас, вот, ID-шник больше, чем у нас. ID-шник его 2, 2, 2, 2, а у нас оказался

1, 1, 1, 1. Приоритет у него у DR-а единичка, а у нас тоже единичка, поэтому сравнивались именно ID-шники. У кого больше, тот и прав. И показываются справочные IP-шники. У нас IP-шник 1, 10, 1, 2, 1, у него IP-шник 10, 1, 2, 2. Хорошо видно, что ID-шники и IP-шники это разные вещи, и они не совпадают между собой. Таймеры, как и обещалось, hello timer 10, dead timer 40. Вот эта вот штука, это в течение какого времени после старта интерфейса мы ждем выборов DR-а, BDR-а. То есть, мы ожидаем, что кто-то нам скажет, кого он считает DR-ом, BDR-ом. Это делается на случай, если вдруг мы включились в рабочую сеть и там уже есть DR-BDR. Вот мы не должны начинать с того, что будем кричать DR- это мы, потому что DR- это сущность, которая выбирается один раз и дальше он работает до тех пор, пока не сдохнет. Вот поэтому, если мы включаемся в сети и кто-то нам говорит, что DR уже существует, уже выбран, мы говорим окей, тогда мы используем того, кто уже сейчас является DR-ом. А если мы приходим в новую сеть и включаем

у SPF на интерфейсе и у нас никто не присылает нам указания, кто DR сейчас, то мы говорим окей, в этой ситуации тогда мы будем считать DR-ом самого себя. Так, дальше, hello, следующий отправится через 8 секунд. Neighbor на этом интерфейсе обнаружен целая одна штука, из них один полностью перешел в full. и, соответственно, вот список этих нейборов. ID-шник 22222, который DR. Если бы вдруг у нас были соседства на этом интерфейсе, на которых мы бы по каким-то причинам не хотели отправлять hello сообщения, то есть, например, вот в virtual link те же самые, то здесь бы показывалось suppress hello. Ну, да. В нормальной ситуации мы такого не видим. Если у нас есть какой-то сосед, мы тоже можем попросить отобразить детальное соседство, указываем show ip ospf neighbor, дальше указываем интерфейс, на котором мы нашли соседа и ID-шник этого соседа.

Показывается, перешли мы с ним полные взаимоотношения или нет, сколько раз менялось тип, менялось состояние этого соседа. Очень интересно на самом деле смотреть, если у вас вдруг начинает колбасить соседа, что не падает ли он у вас из full, например, в init, и потом из init обратно в full не переходит. То есть, если вы видите, что счетчик у вас зашкаливающий за какие-то разумные значения, то вы говорите, окей, у нас с этим соседом какая-то беда, что обычно проявляется в том, что у вас трафик начинает ходить как-то странно. Дальше показывается, что его приоритет, мы его знаем, указывается, кого он считает DR, кого он считает BDR. Мы видим его hello сообщение и мы видим, что он пишет про то, кого он считает DR, BDR. Видим, что в hello сообщениях он проставляет некие флаги и мы на самом деле уже знаем какие-то флаги. Вот этот вот

EBIT мы уже видели. EBIT означает, что он не против того, чтобы ему присылали LSA-ки пятерки. То есть, он считает, что это регион нормальный, в котором LSA-ки пятерки допустимы. Ну и судя по тому, что да, он, что мы с ним дружим в регионе нулевом, да, вполне логично, что этот регион транзитный, там LSA-ки пятерки допускать можно. Вот. Дальше. Через 36 признаем соседа трупом, 5 часов мы с ним уже нормально работаем и мы ему ничего особенно не хотим переотправлять сейчас. У нас пока что очередь на отправку нулевая. то есть, все, что мы ему хотели отправить, все отправили. Если бы вдруг мы ему что-то отправили, а acknowledge в том или ином виде мы на это не получили, мы бы это переотправили, но здесь бы указывалось, сколько раз мы переотправляли чего-нибудь. Вот. Нембров это retransmissions, у нас бы счетчик опять же рос. Так.

Итак, давайте с вами настроим наш OSPF. Так, я сильно подозреваю, что у меня на роутерах R1 и R2 есть, кстати, экземпляр OSPF, который я вам поднимал для демонстрашек. Давайте я сейчас сотру его. Роутер OSPF1 и на R2 тоже потом сотру. Вот. И начнем с вами настраивать OSPF так, чтобы у нас конфигурация OSPF была вот как бы с чистого листа. Так, ну-ка, на всякий случай доу-шоу, run, интерфейс, Ethernet 0, 0, студия. Ага, здесь вот еще вот эта штука есть. интерфейс Ethernet 0, 0, 0, 0, 12, no, IP, OSPF, network, point to point. Вот. Теперь, операция чистая-чистая. Аналогичное действие надо будет на R2 сделать. Сейчас на нашем роутере никаких следов OSPF нету, и для того, чтобы включить OSPF на интерфейсах, мы можем использовать

команду network. Ну, для начала надо запустить сам контекст OSPF, роутер, OSPF и дальше некое число. Число двубайтовое, и оно локальное для железки. Не передается по сети никоим образом, за исключением одного нюанса, что если вы перекладываете OSPF-овские маршруты в EJRP, то в этом случае EJRP будет как раз палить, из какого процесса ESPF он эти самые маршруты взял. Но при выборе лучшего маршрута на эту цифру он не ориентируется, это так чисто для трэблшутинга, поэтому, в принципе, вы можете брать любое число, которое вам захочется. Я предлагаю брать единичку, но имейте, пожалуйста, в виду, что на экзамене вас будут ловить на том, что вы можете запустить на одной железке несколько разных процессов OSPF, и у них могут быть разные идентификаторы. И те команды, которые вам будут на экзамене показывать или подсовывать, они вполне возможно будут относиться к каким-то разным контекстам, разным процессам OSPF. Поэтому внимательно

смотрите на те идентификаторы, которые там в экзамене у вас будут использоваться. В реальном мере используйте номер один. На экзамене очень внимательно изучайте, какие номера процессов OSPF вам предлагают использовать. С вероятностью 90% вам попадется вопрос на экзамене, где показывают конфигурацию роутера OSPF1, а дальше показывают настройки интерфейса, и в настройке интерфейса там будет, например, идентификатор 100 стоять, IP, OSPF, там чего-нибудь 100. Поэтому осторожнее, внимательнее и смотрите на то, где какие отсылки будут. Собаки, да, но, естественно, предполагается, что раз вы профессионал, то вы должны будете понимать, что идентификатор процесса здесь, идентификатор процесса там, они должны быть одинаковые. Что если вдруг вы запускаете контекст OSPF с номером идентификатора 1, а на интерфейсе прописываете там, не знаю, 2 или 100, то, да, это приведет потому, что у вас интерфейс по факту окажется не в том процессе.

Но, да, в реальном мире я настоятельно вам рекомендую не выпендриваться и использовать номер процесса 1. Тем не менее, никто вам не запрещает сказать, что да, что у вас есть какой-то другой процесс, который, не знаю, хотите, используйте 100, хотите 65 тысяч, хотя, почему бы и нет? То есть, если у вас есть такая возможность, вы этой возможности можете пользоваться, у вас есть такое право. Ну, траблшутить сами будете. Я запускаю процесс 1. Опять же, если вы хотите, вы можете использовать любые другие идентификаторы. Но, траблшутить будете сами. Дальше. У нас надо запустить наши роутеры, заставить их связаться между собой. И на роутере первом я предлагаю сначала подружиться не по Ethernet. Я предлагаю включить OSPF на интерфейсе DMVPN и посмотреть, к чему это привезет. Дело в том, что у нас туннельный интерфейс, он как раз хитрый. Он туннельный, и на туннельном

интерфейсе у нас тип среды автоматически назначается Point-to-Point. Поэтому я сейчас на интерфейсе туннельном говорю, что у нас Network 192, 168, 0, 15. Это мой IP-шник на туннельном интерфейсе. 0, 0, 0, 0, 0, Wildcard маска, Area 0. Я мог бы включить OSPF на туннельном интерфейсе двумя разными способами. Мог бы с помощью команды Network, или мог бы пойти на этот интерфейс и сказать, что IP OSPF 1, Area 0. Это привело бы к одному и тому же результату. Я предпочел сейчас воспользоваться командой Network. Мне она больше нравится. Естественно, что дружба у нас автоматом не получится, потому что со стороны центрального роутера аналогичной команды нету. На туннельном интерфейсе там никто нас не ждет. Поэтому Hello пакеты я в туннель отправляю и они никуда не уходят. Более того, я подчеркну, они никуда не уходят. Они даже до центрального роутера не доходят,

потому что показываю Show IP OSPF Interfaces Brief Interfaces На интерфейсе у нас туннельном OSPF включился. Кстати, обратите внимание, у него кост максимально большой, потому что bandwidth на туннельном интерфейсе если мне память не изменяет, считается 1 килобит что ли. Show интерфейс туннель 0 bandwidth 100 килобит. Да, 100 мегабит в секунду, деленное на 100 килобит в секунду как разную тысячу. Так, и я на этом туннельном интерфейсе буду иметь тип среды Show IP OSPF Interface туннель 0. Тип среды я буду иметь на этом интерфейсе Point to Point. На Point to Point интерфейсе у нас автоматически должен работать мультикаст. Мы отправляем

пакеты в Point to Point интерфейс и они автоматически должны дойти до получателя. Здесь у нас dmvpn. у нас в dmvpn мультикаста по умолчанию нету. Давайте я покажу как у меня выглядит туннельный интерфейс. Show Run интерфейс туннель 0. У меня есть на этом интерфейсе IPшник. У меня есть на этом интерфейсе указание откуда посылаются пакеты с какого IPшника с IPшника висящего на интерфейсе дали 1. У меня есть указание что на этом интерфейсе получателем может быть кто угодно и IPшник получателя я буду резолвить на NextHop сервере 192-168-01 до которого я могу добраться через публичный IPшник 111-111-111-111. И есть указание что экземпляр NHRP на этом интерфейсе будет первый. То есть здесь нет указания как работает мультикаст и забегая немножко вперед мультикаст здесь не работает никак. Для того чтобы мультикаст на туннельном

dmvpn завелся нужно будет ему помочь и на какие-то спалки то есть если мы будем прописывать мультикастовых получателей спалков нам нужно будет заранее прописать публичные пишнике всех всех всех всех спалков это адское количество работы и на самом деле делать не нужно поэтому мы сейчас пропишем мультикастовым получателям только хаба и вот на на хаби сделаем ответные действия мы скажем что все кто зарегистрировался в н-чарпи будут являться нашими мультикастовыми получателями и соответственно на спалке трафик мультикастовый пойдет только в сторону хаба а на хаби мультикастовый трафик будет эмулироваться сторону всех получателей

интерфейс 10000 айпи и н-чарпи мультикаст а тоже также делается я прописываю получателя мультикастового трафика и указываю что мультикастовый трафик уйдет в сторону того же самого айпишника 101 101 101 101 это айпишник центрального хаба на хаби нужно будет ответные действия прописать у меня есть хаб так это не тот вот этот хаб интерфейс туннель 0 айпи и н-чарпи мап мультикаст дайна миг все кто зарегистрировался по иной черпи на этом интерфейсе будут получателями копия мультика ства трафика для того чтобы сейчас все получилось нужно интерфейс туннеля выключить и включить то есть вот на пардон на моем роутер первым я указываю

shutdown у себя тоже пожалуйста то же самое делаете туннельный интерфейс гасим физически Гасим — он у нас падает down, показывается сообщение «интерфейс туннель» в состоянии administratively down. Потом no shutdown — интерфейс поднимается, в процессе поднятия он отправляет мультикастовый NHRP-запрос на хаб с просьбой зарегистрироваться, и начиная с этого момента у нас мультикастовый трафик между хабом и споками может ходить. Теперь мы можем отправлять мультикастовые hello-пакеты на адрес 224.0.0.5. До того момента мы пытались это делать — в point-to-point интерфейсе мы отправляем мультикастовые пакеты, но они не могут дойти ни до куда. А сейчас они по крайней мере могут дойти. Когда мы point-to-point интерфейс имеем, у нас генерируются мультикастовые пакеты на 224.0.0.5, и они уходят в сторону хаба. Я могу это проверить с использованием команды на хабе — show ip nhrp

multicast. Все получатели мультикастового трафика здесь у меня есть — все, кто выключил-включил интерфейс после того, как я прописал команду ip nhrp map multicast dynamic, — здесь перечислены. Теперь если я захочу отправить какой-то мультикастовый пакет в этот интерфейс, он будет автоматически реплицироваться, и каждая копия мультикаста пойдёт юникастом в сторону каждого конкретного получателя. Из одного мультикастового пакета Cisco эмулирует шесть разных юникастовых пакетов и отправит их юникастом на всех этих получателей. Для того чтобы у нас сейчас OSPF завёлся, я должен буду на туннельном интерфейсе сказать, что этот интерфейс тоже в OSPF будет работать. Есть нюанс — если это сделаю, ip ospf 1 area 0, OSPF заведётся, только

вы видите сами, что будет происходить: у нас постоянно будет какая-то попытка — соседства устанавливаются, после чего всё разваливается, у нас всё переходит в EXSTART/DOWN, то есть видно, что ему очень плохо. Давайте отменю. Я отменил — no ip ospf 1 area 0 — и давайте разбираться, что у нас такое происходит. Почему вроде бы казалось, мы включили OSPF на интерфейсах, а она вот так плохо себя ведёт. Связано это как раз с тем, что у нас интерфейс туннельный. На этом роутере show ip ospf interface tunnel 0 не сможет показать... Он тоже типа point-to-point, и на point-to-point интерфейсе Cisco не ожидает увидеть много разных hello-пакетов от многих разных роутеров. Сколько разных нейборов

к ней прибежало и говорит «я хочу с тобой подружиться» — и что с этими соседями делать, ничего не сделаешь. Cisco говорит: я не знаю, как в такой ситуации быть, когда столько разных соседей приходит и говорит «я хочу с тобой дружить». Поэтому для того чтобы здесь Cisco могла подружиться, я должен сменить тип среды. Здесь возникает вопрос: что я со своей стороны могу предложить? Я могу либо поменять point-to-point, который сейчас есть на интерфейсе, на point-to-multipoint, но тогда у меня таймеры поедут. Либо я могу сказать, что у меня тип среды, например, будет broadcast, но тогда я буду выпускать LSA второго типа, которую вы не ожидаете. Либо я могу что-то ещё придумать. Давайте я сейчас попробую на туннельном интерфейсе включить режим не point-to-point, а point-to-multipoint. Это будет означать, что я на этом интерфейсе буду устанавливать соседские отношения со многими роутерами, и кроме того у меня будут

таймеры 30 на 120, поэтому таймеры мне нужно будет подкрутить вручную. ip ospf network type — и дальше у меня здесь на выбор: broadcast предполагает, что у меня множественный доступ, есть LSA второго типа, таймеры 10 на 40, но broadcast — мультикаста нету, соседей надо прописывать вручную. В остальном — таймеры 30 на 120, но есть LSA второго типа. То есть оба варианта мне не устроят. Point-to-point — понятно, он сейчас по умолчанию, он тоже меня не устроит. Поэтому остаётся у меня вариант только point-to-multipoint. Указываю, что у меня point-to-multipoint, и дальше на выбор есть вариант просто нажать Enter или сказать, что в этом point-to-multipoint у меня нет broadcast-ов, в кавычках нет мультикаста. Здесь то, что он говорит «non-broadcast», на самом деле имеется в виду как раз то, что мультикаста нету. Поскольку у меня это DMVPN, то мультикаст у меня

есть — он нарисованный, но тем не менее он есть. Поэтому я указываю просто ip ospf network point-to-multipoint, поднимаю интерфейс — no shutdown — убеждаюсь, что у меня соседства автоматически не поднимаются, несмотря на то что казалось бы вроде всё хорошо, мультикаст есть, всё замечательно. Но если я сейчас включу дебаг, сразу понятно почему — debug ip ospf packet hello. Пакет — таймеры у меня 30 на 120, а у вас соответственно 10 на 40. Я отправляю пакеты с 30 на 120, вы отправляете с 10 на 40. Ну, no shutdown — ip ospf 1 area 0. Я интерфейс выключал. И у меня начинают приходить пакеты, и в этих пакетах

таймеры не видно. Давайте сделаем дебаг посильнее — debug ip ospf adj. Received hello — и показывается, что у нас не совпадают таймеры. Приходит сообщение hello 10 на 30, а у меня стоит настройка 40 на 120. Поэтому сейчас я поменяю таймеры на такие же, как у него. В приходящих сообщениях: dead 40, а сконфигурировано 120, и hello receive 10, а сконфигурировано 30. Config terminal, interface tunnel 0, прописываю таймеры — ip ospf hello-interval 10. Достаточно прописать

только hello-interval, потому что dead-interval автоматически настраивается в четыре раза больше. 10 на 40 — у меня автоматически подключается, и видно, что соседство у нас устанавливается. Единственный момент заключается в том, что вы со своей стороны будете анонсировать всю сетку /24, как она у вас висит на интерфейсе, а я буду анонсировать сетку /32, потому что на point-to-multipoint у нас нету полной связности, мы не выпускаем LSA 2 типа, как следствие я буду анонсировать /32. Но опять же на сборке пазла это не повлияет. У вас установилось соседство, мы проверяем, что на центральном роутере оно есть — очевидно, что есть. Мы проверяем, что на маленьком роутере оно есть — действительно есть. Show ip ospf interface — интерфейс туннельный включился, на нём

обнаружен один сосед, с этим соседом перешли в полные взаимоотношения. Show ip ospf neighbor — показывается, что с соседом связь есть. Мы со своей стороны трактуем на туннельном интерфейсе на маленьком роутере этот интерфейс как point-to-point, и на point-to-point не выбираются DR/BDR. Поэтому мы с единственным соседом, который на этом point-to-point интерфейсе может быть, устанавливаем full взаимоотношения. А на туннеле центрального роутера — он говорит, что у нас point-to-multipoint, там нету LSA второго типа, там с каждым соседом надо full взаимоотношения устанавливать, несмотря на то что они все на одном и том же интерфейсе. И получается — никто DR/BDR не выбирает, со всеми устанавливаются полные взаимоотношения. И если посмотреть сейчас пазл, то пазл у нас будет складываться именно так, что у нас есть много разных независимых соседств. Дальше — show ip ospf interface tunnel 0.

172.16.0.1 — обратите внимание, это Router ID 172.16.0.1, а вот эта штука — IP-адрес 192.168.0.101 — они не совпадают. Показывается, что у нас DR и BDR не выбраны, никто их не выбирал. Neighbor priority 0 — neighbor не собирается выбирать DR/BDR. И ещё у нас тут есть сообщение, что он считает, что этот area, в котором он с нами дружит — area номер 0, обычный нормальный регион, в котором допустимы LSA пятёрки. Ну и в принципе можно посмотреть на OSPF — show ip ospf route — те маршруты, которые OSPF просчитал. Вот эту сетку анонсирует каждый из нас, а вот эту сетку — 192.168.0.101 с /32 маской —

анонсирует центральный роутер. У каждого роутера есть указание, какую connected-сетку включать в анонс. Если у нас broadcast или point-to-point интерфейс, мы включаем именно connected-сетку. Когда сетка у нас 192.168.0.0/24 — я её сам знаю, её знаете вы, эту сетку мы знаем из многих разных источников. А вот эта штука — 192.168.0.101/32 — её нам центральный роутер анонсировал, потому что он бы рад вот эту анонсировать, но у него настройка на интерфейсе стоит point-to-multipoint, а на point-to-multipoint анонсируется именно IP-адрес, который висит на интерфейсе, с /32 маской. Поэтому он сказал: извините, я не могу вам сказать, что я знаю всю сетку — я могу сказать только то, что я знаю, как до себя самого добраться. Дальше вы посчитаете по этой самой карте сети, которая у вас в голове есть, до чего именно вы можете добраться, и вы поймёте, что вы можете добраться до меня. Дальше — вот это список next-hop-ов, здесь ничего интересного

для нас нет. Действительно, есть мы, и есть next-hop 0.101, и в таблице маршрутизации сейчас у нас появится вот этот /32 маршрут. Show ip route — вот он. Несмотря на то что это как бы connected-нечто на туннельном интерфейсе, на центральном роутере вместо connected-сетки по той маске, которая по факту висит, он анонсирует только хостовый свой собственный IP-адрес с /32 маской. Делается это специально для сред с неполной связностью, потому что point-to-multipoint — это среда, в которой у нас нет full mesh, и тогда роутеры должны говорить, что они знают не всю сетку, а говорят только то, про что они по факту могут точно заявить, что они точно знают — свой IP-адрес они точно знают. И когда роутеры устанавливают соседство, вы через центральный роутер можете добраться до любой другой точки сети, которую знает центральный роутер. Его IP-адрес будет вставляться в качестве

next-hop, а в таблице маршрутизации, если вдруг какие-то другие роутеры будут присылать указания, что они знают, как добраться до самих себя, и центральный роутер вам эти маршруты будет дальше передавать, то вы можете сказать в этой ситуации: например, я могу добраться до 192.168.0.14 через 192.168.0.101. Давайте сейчас в качестве последнего завершающего задания на сегодня поменяем на наших маленьких роутерах тип канальной среды на DMVPN-интерфейсе тоже на point-to-multipoint и поменяем заодно таймеры, для того чтобы у нас соседство могло переустановиться. Config terminal, interface tunnel 0, ip ospf network — и указываем point-to-multipoint. И ip ospf hello-interval 10. Если мы это сделаем, сейчас у нас никто не будет анонсировать connected-сетку

192.168.0.0/24 — вместо этого все будут анонсировать свои собственные IP-адреса, и в таблице маршрутизации OSPF нам скажет: для того чтобы добраться до каждого отдельного IP-адреса в этой сети, надо ходить через центральный роутер. Я думаю, что вы уже наверное сделали, поэтому я могу показать отображение таблицы — show ip ospf route — что мой OSPF посчитал. Вот я вижу 192.168.0.1/32, он прислал, 192.168.0.3, 0.4, 0.11 — и все они идут по /32 маске, и показывается cost 2000. Для того чтобы добраться до сетки 192.168.0.1, мне надо пойти на next-hop 192.168.0.101, а потом оттуда прыгнуть до вашего спока — и у меня получится cost 2000 для того, чтобы добраться до этого узла. Но next-hop всё равно мне один единственный — 192.168.0.101. Show ip route ospf — в таблице маршрутизации

есть отдельные /32 маски до каждого из нас, трафик по факту может пройти по этим маршрутам. Ping 192.168.0.1 — он действительно ходит, и ходит он через центральный роутер. Сейчас мы весь трафик отправляем в туннель на IP-адрес 192.168.0.101, как OSPF нам это и завещал. Здесь правда есть нюанс, заключающийся в том, что DMVPN в принципе юникастовый трафик в полносвязную топологию предоставляет, а для мультикаста там только hub-and-spoke топология. Поэтому здесь нам интересно было бы OSPF как-то адаптировать и заставить его работать не в фазе 1, когда у нас фаза DMVPN первая — это то, где весь трафик ходит через центральный роутер, — а сделать так, чтобы фаза 2 использовалась, чтобы трафик ходил напрямую с одного узла на другой. Но это мы сделаем отдельно на следующем занятии, когда мы будем проходить соответствующие команды. На сегодня предлагаю закругляться. Завтра поднимем здесь OSPF и посмотрим на базу данных LSDB, что там за LSA,

и как у нас будет храниться. Ну и поделаем всякие разные клёвые другие штуки с нашими цисками. На сегодня всё, спасибо за внимание, пока-пока.