Настройка OSPFv3 Classic Mode в Cisco IOS

ospfv3 в циско иус причем мы будем говорить сейчас про тот режим который обсуждали мы на си сены так называемый классический режим дело в том что так же как и в случае с egp с ospfv3 вы можете работать на самом деле в двух разных ну назовем то способов управления им можно использовать также как в egp у нас был классический режим и именованный режим здесь вот есть классический режим и режим of mode вот мы сначала разберем тот режим который для нас привычный который айпи в 6 роутер успев чего-то там указываем что у нас есть роутер ospfv дальше назначаем номер экземпляра это не instance это номер экземпляра если нужно указываем роутер айди если нужно указываем пассивные интерфейсы дальше указываем на конкретном интерфейсах которые должны работать в испе и айпи 6 успев номер экземпляра и дальше номер региона команды network нету есть только вручную задание

участие конкретного интерфейса в протоколе успев в конкретном экземпляре в конкретном регионе ничего нового в принципе для вас это все должно быть знакомо естественно что если вы хотите одновременно включить ospfv3 на целой пачке интерфейсов то вам придется на каждой зайти и сказать этот интерфейс работает этот интерфейс работает этот работает если у вас это физические интерфейсы есть замечательная команда интерфейс range а вот если это сабы как вот у нас наслает на стенде то соответственно придется прям действительно ручками заходить и ручками включать также как и в случае с айпи в 4 мой спи фом диагностика его будет происходить через сначала посмотреть запустился ли он либо шоу ipv6 протокол с либо шоу ipv6 успf здесь из того что важно будет смотреть надо будет смотреть роутер айди надо будет смотреть какие регионы у вас есть в каких регионах ваш роутер чувствует что он живой и в частности да если у вас есть больше двух регионов то есть ли хотя бы один интерфейс в

нулевом регионе ну то есть показано да на каких интерфейсах вы успев включили если вдруг вы захотите посмотреть на референсную полосу то в шоу ipv6 протокол с этого не видно это есть шоу ipv6 успf и здесь вот референс bandwidth units 100 мегабит в секунду cisco и us использует старый дурацкий механизм 100 мегабит деленное на скорость интерфейса для определения метрики интерфейса отсюда вывод все современные интерфейсы будут иметь метрика единичка то что автоматически можно посчитать эту самую метрику работает только для очень старых интерфейсов если вы работаете с современными железками это фактически означает что у всех интерфейсов вы стоимости должны быть назначать либо ручками либо менять референс бенда иначе все интерфейсы будут иметь стоимость единичку некоторые любят ругаться на из из говорит что вот в из все интерфейсы имеют стоимость 10 он тоже тоже протокол link state of и там тоже интерфейс этом тоже та же самая концепция стоимости тот же самый алгоритм фактически вычисления кратчайшего пути но вот да в искусе все обязательно ручками надо делать в успев говорят вот циска умеет

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

как раз посмотреть на чек сумму так про интерфейсы те команды которые у нас были в ipv4 они же в принципе есть и в ipv6 шоу ipv6 у spf интерфейс бриф ну то есть то же самое что было шоу айпи интерфейс бриф шоу айпи успев интерфейс бриф показывает на интерфейсы показывают номер экземпляра регион в котором они сидят стоимость интерфейса наше состояние на этом интерфейсе будем ли мы дэром бдэром кем-то там и показывается наибор физе был и аккаунт то есть сколько соседей есть с какими из них мы перешли в полноценные взаимоотношения интерфейс сайди раньше здесь на интерфейсе показывался и пиш ник и это и пиш ник считался в таблице соседей как next hop здесь сейчас вот у вас показывается номер интерфейса когда вы заказываете шоу ipv6 успf интерфейс бриф вот вы смотрите что есть гигабитный интерфейс номер 2 fast ethernet 00 номер 4 fast ethernet 01 номер 5 fast ethernet 02 номер 6 естественно все это для того

чтобы подвязать потом найти интерфейсы либо и лосики девятки если у нас интер интро ири маршруты либо если у нас обнаружено соседство лосейку восьмерку с линк локал адресами дальше шоу и пиви 6 успевный бар у нас как вы помните шоу айпи успевный бар показывала сначала network айди а потом network айпи вот здесь вот вайпи 4 был айпиш ник в айпи 6 у нас соседи известны не через айпиш ники соседи у нас известны через интерфейсы поэтому айпишную колонку отсюда убрали и интерфейс айди по идее вы должны будете здесь видеть каким интерфейсом он на вас смотрит то есть например интерфейса где будет там göra первый интерфейс соседа смотрит на ваш интерфейс номер два вот здесь почему то вот не показано но иногда такое бывает что да cisco не показывает интерфейса адийно это каким интерфейсом он смотрит на вас вот каким интерфейсом вы на него смотрится здесь вот показывается так и соответственно

В таблице маршрутизации SHOIP V6 Rout OSPF показывает маршруты OSPF. Точно так же они будут показываться. Буквка О, намек на OSPF. Точно так же административное расстояние 110 и метрика. Ну, метрика, да. Метрика и метрика. Link local адреса будут браться из LSA 8. Когда мы говорим, что у нас есть какие-то роутеры, которые каким-то образом соединены между собой. На одном из роутеров есть сетка. Вот эта сетка анонсируется в LSA 9. Соответственно, здесь у нас есть LSA 8. LSA 8, LSA 8. Здесь тоже есть LSA 8, LSA 8. Но это уже другие LSA 8. И они не распространяются в другие регионы. Ну, вот, соответственно, здесь 8, здесь 8, здесь 8, здесь 8, здесь 8. Мы на одном роутере считаем, как добраться до LSA 9. Говорим, самый простой способ пойти по вот такому-то маршруту. И next hop в этом маршруте будет LSA 8 соседа. Вот мы адрес, который в LSA 8 соседа указан, как раз указываем в качестве next hop.

Стоимости. Если вдруг захотим поменять, это можно сделать либо на интерфейсе в явном виде, тоже как в IPv4 было IP OSPF cost. Здесь у нас есть IPv6 OSPF cost. Либо можно будет сказать AutoCost Reference Bandwidth настройки роутера. Приглашение к обводу в IPv6 роутере будет config.rtr. На экзамене на это вполне может быть вопрос. И точно так же вы указываете Reference Bandwidth в мегабитах. Хотя на самом деле, да, вот видно, да, что она хоть и в мегабитах и указывается, но максимальное значение, максимальная скорость, которая может быть на интерфейсе, это получается 4 терабита. Так что, да, на самом деле, передается это значение там как раз в килобитах. Так, дальше. Если вдруг какие-то интерфейсы пассивные, опять же, все то же самое, как во всех остальных протоколах, которые мы с вами смотрели. Passive Interface. Есть Passive Interface Default, есть No Passive Interface или Passive Interface на конкретный интерфейс, который вам нравится или не нравится.

Если вы объявляете интерфейс пассивным, точно так же, как в OSPFV4, OSPFV2 для IPv4, HelloPacket не отправляются, не принимаются. На самом деле важнее, что они не отправляются. Поэтому вы не установите соседство, поэтому вы не включите какого-то левого соседа на этом интерфейсе в список соседей, как следствие, да, что если вы ничего не отправляете ему, то соседство у вас не установится. Ну, то, что HelloPacket не принимаются, да, это как бы уже следствие, что если вдруг мы не дружим с соседями на этом интерфейсе, то нам незачем принимать от них HelloPacket. Так. Что еще можно на интерфейсе сделать? Можно приоритет прописать при выборе DR и BDR. Концепция выборов DR и BDR точно та же самая. Можно прописать HelloInterval, DeadInterval. Опять же, можно задать только HelloInterval, DeadInterval вычислится автоматически. Субсекундных таймеров Cisco IOS для OSPF 3-й версии не поддерживает.

То есть, если вы захотите использовать субсекундные таймеры, то вам однозначно нужен будет BFD. И, соответственно, тип среды. Точно так же, как в OSPF V4, ShowIP V6, OSPF Network. Здесь вот у нас будут те же самые нам привычные значения указывать. Это все, напомню, на интерфейсе делается. То есть, приоритеты, таймеры, тип среды. Все это мы с вами уже, по-моему, делали. Так. Что касается статического указания соседей. В IPV4 мы делали это в контексте роутера. И, соответственно, там IP-шник соседа у вас должен был резолваться для того, чтобы вы могли с ним подружиться. И, естественно, да, что вы указываете IP-шник, который у вас есть. И дальше, естественным образом, по таблице маршрутизации, вы указываете тем самым и интерфейс, на котором этот сосед должен существовать. В IPV6 у нас не получится указать IP-шник соседа, который будет маршрутизированным.

Потому что мы дружим по link-local адресам. Соответственно, в контексте роутера link-local адрес указывать как-то грешновато. Поэтому все равно придется указывать интерфейс. И поэтому концепция указания соседей статикой поменялась. Вы теперь это делаете в настройке интерфейса. Статических соседей можно прописать только если у вас есть тип среды non-broadcast или point-to-multipoint non-broadcast, точно так же, как в IPV4. Но, соответственно, да, вот IPV6 и USPF-neighbor вы указываете link-local адрес. Естественно, что этот адрес должен резолваться в канальный адрес. То есть если вы во FrameRail работаете или в DMVPN, то вам потребуется маппинг для этого адреса. showIPv6 и USPF-интерфейс. Точно то же самое, что было в IPV4. Показывается адрес, который есть на интерфейсе, но он уже link-local. Показывается, какой номер интерфейса на вашей железке присвоен этому интерфейсу. Какой номер региона. Какой номер экземпляра USPF. И вот новость.

Instance ID. В каком инстансе этот интерфейс у вас будет присутствовать. Вот в нашем случае он есть в инстансе номер 0. Это значит, что это обычная IPV6 маршрутизация. Роутер ID. Тип среды. Стоимость интерфейса. Кто мы. Какой у нас приоритет. И интересная штука. Transmit delay. Я про нее на самом деле рассказывал, когда говорил про EGRP. Что USPF протокол очень неспешный. Если у нас что-то происходит, то USPF не хочет про это рассказывать своим соседям немедленно. Да, он может, конечно, рассказать немедленно, но он может также и подождать. И вот transmit delay это как раз указание на то, что будет, если у нас с этим интерфейсом что-то случится. Если у нас, например, поднимется этот интерфейс или опухнет, этот интерфейс упадет, то мы не сразу отправляем LSA-ку новую, в которой рассказываем, что у нас такой интерфейс поднялся или такой интерфейс упал. Мы ждем одну секунду, мы даем ему время на то, чтобы прочихаться и переподняться заново.

Если он меньше, чем за секунду поднимется, то мы LSA-ку не выпускаем новую. Мы тем самым экономим ресурсы соседним роутерам и мы даем им возможность сделать вид, что ничего не было. Поэтому там, где EJRP немедленно перескочит на запасной маршрут, если он есть, USPF скажет, подожди секундочку. Подождет секундочку. И если вдруг все вернется на круги своя, он скажет, не было ничего, ничего не было. А если за секунду, соответственно, никакого позитивного изменения не произойдет, то, соответственно, выпускается новая LSA-ка. Она обрабатывается всеми роутерами. Они запускают пересчет кратчайшего пути в графе и перескакивают на запасные маршруты, которые они посчитают на лету. Так, кто DR, кто BDR. Показываются ID-шники соседей и показываются их link-local-адреса. Опять же, нам не сильно важно знать их link-local-адреса, потому что, в принципе, у нас есть возможность посмотреть всегда в табличку, но здесь вот на всякий случай справочно показывают, какие link-local-ы у них есть.

Таймеры. Hello-timer 10 на 40. Ну, действительно, гигабитный интерфейс, стандартные таймеры. Wait-timer. Сколько мы ждем перед тем, как признаем себя DRM? И когда будет следующий hello? Так, так, так, так, так, так. Neighbor count. Один сосед. Из них один сосед полностью с установленным full взаимодействием. И сосед имеет ID-шник 0002. У этого соседа роль BDR. Ну, естественно, что у нас DR. Surprise Hello. На самом деле, я уже показывал, да, что если у вас есть некоторые интерфейсы, которые имеют тип on-demand, например, это Virtual Link, то там Hello не посылаются. Вот здесь как раз suppress Hello тоже есть. Мы на этом интерфейсе Hello не делаем супрессинга. Мы отправляем Hello по-честному. Graceful Restart – это штука следующая. Если у вас есть большой роутер, у которого есть два супервизора

и некоторое количество линейных карт, вот это супервизор 1, это супервизор 2, это своего рода думалки. Есть, соответственно, линейные карты, которые делалки. Line карты. Помните, я начинал рассказ про то, как устроен CEF в самом начале курса. Соответственно, у нас есть таблица маршрутизации на каждом из этих самых роутеров, на каждом из супервизоров. Это фактически просто обычная таблица SHRP Road. Каждый конкретный супервизор в каждый конкретный момент должен принять решение, он работает или нет. Если у вас работает один супервизор, то он будет отвечать за то, что пополняет свою таблицу маршрутизации, а дальше, соответственно, выгружают ее копию в линейные карты, в тот самый Distributed CEF. И здесь у нас идет репликация FIBA – Forwarding Information Base. Соответственно, CEF у нас работает на линейной карте, но кормит его таблицей маршрутизации на супервизоре. Если вдруг один из супервизоров дохнет, то второй супервизор должен сказать,

окей, у нас сейчас есть какая-то проблема. Супервизор первый работал, который кормил линейные карты, но он помер. И сейчас надо завестись. Но вот эта вот процедура перехвата управления у супервизора, она не мгновенная. Она занимает некоторое время. И в зависимости от конкретного супервизора, от конкретных настроек, она может занимать до нескольких минут. У вас там фактически супервизор с нуля будет грузиться. И для того, чтобы переключиться с одного супервизора на другой, посылается соседним специальное сообщение. Ребята, у меня тут какая-то проблема, но не волнуйтесь. Линейная карта накормлена хорошими маршрутами. У нее с ней все в порядке. Если у вас только не произойдет какого-то криминала, и, допустим, не изменится таблица топологии, пожалуйста, не думайте, что то, что я вам не присылаю hello-сообщение, это означает, что я сдох. Я не сдох. У меня фарвардинг идет как шоу. У меня только hello посылаться не могут, потому что я с вами еще соседские отношения не переустановил. Но я сейчас загружу вот этот самый второй супервизор, переустановлю соседские отношения,

загружу полностью себя таблицу LSA, посчитаю все кратчайшие маршруты, и накормлю линейную карту новыми маршрутами. Это все одна и та же железка. Просто у нее в голове вот такой корпускулярно-волновой дуализм. У нее одна голова думает, что вторая сдохла, и, соответственно, думает, что надо сейчас подумать, о чем думала первая голова в момент, когда она дохла. И поэтому требуется некоторое время на переключение. И вот эта вот штука называется как раз graceful restart. На конкретно этом роутере у нас есть graceful restart helper. Это как раз ситуация, когда к нам кто-то говорит, подожди, пожалуйста, у меня сейчас голова будет заниматься тем, что пытаться восстановить, о чем думала вторая голова. И мы говорим, окей, мы тебя подождем. Ты нам не присылаешь hello пакет, и это не страшно. Продолжай, пожалуйста, в том же духе до тех пор, пока ты считаешь, что все хорошо, мы тебя будем держать в таблице соседей, несмотря на hello. Эта же штука может называться NSF, non-stop forwarding.

Можно конкретного соседа посмотреть, show ip ospf neighbors. Соответственно, показывается neighbor, ID-шник neighbor, показывается, в каком регионе мы с ним дружим, через какой интерфейс. Показывается ID-шник интерфейса соседа, которым он смотрит на нас. То есть мы смотрим на него интерфейсом gigabit 00, и этот интерфейс будет иметь, например, ID-шник 2. А вот он, сосед на нас, смотрит ID-шником 3. Мы знаем его link local address, потому что от него приходят hello сообщения. Мы знаем, какой у него приоритет, опять же, с hello сообщений. Мы переходим с ним в какие-то взаимоотношения. То есть мы держим его в состоянии full, значит, мы от него больше ничего не хотим. Показывается, кого он считает DR-ом, кого он считает BDR-ом. Показывается, какие опции он нам заявил. В нашем случае мы видим, что он поддерживает протокол IPv6,

он поддерживает LSA-кипи... Сейчас, пардон. Он... EBIT этот самый... Да, он ASBR. Вот. Показываются таймеры, с которыми у нас есть, что мы признаем его трупом через 40 секунд. Ну, как раз согласуются с таймером 40. Так, мы с ним установили соседские взаимоотношения 21 минут назад. И QLens, это указывает на то, что мы ему не хотим ничего отправить, такого, чтобы он нам не подтвердил до этого. То есть, если бы вдруг мы увидели здесь какое-то число, которое было бы больше нуля, то это значит, что мы ему попытались что-то отправить, а он нам это не подтвердил, и мы хотим это переотправлять. Так. Так же, как и в OSPF второй версии у нас есть LSA, LSA. Соответственно, LSA в случае вот такой вот топологии, когда есть два роутера, 0, 0, 0, 1, 0, 0, 2. Здесь у нас два разных региона.

Есть LSA второго типа, есть две LSA первого типа. Здесь вот у нас будет явно LSA девятка. Здесь у нас явно будут LSA восьмерки. Ну, и здесь у нас явно будет LSA трешка перекладываться. Вот к сборке пазла будут иметь отношения LSA первого и второго типа. И заодно здесь еще будут LSA-ка восьмерка нужна для того, чтобы посмотреть на то, какими IPшниками роутеры друг на друга смотрят. Вот. Соответственно, роутер link state – это LSA-ки первого типа. Показывается, что у нас есть роутер LSA-ка от роутера 0, 0, 0, 1, роутер на LSA-ка от роутера 0, 0, 0, 2. Есть netlink state – это LSA-ка двушка. У LSA-ки двушки есть IDшник. И вот он, IDшник странный, 4. Мы привыкли немножко в ESPF второй версии, что IDшник – это IPшник DR. Здесь IPшников DR уже нет. Здесь есть номер интерфейса на DR. И, соответственно, есть IDшник DR.

Тот, кто придумал эту LSA-ку – это IDшник DR. Вот пара link ID плюс advertising роутер на самом деле полностью характеризуют LSA-ку второго типа. Вот. В этой LSA-ке написано, что есть два соседа. Ну, я так догадываюсь, что 0, 0, 0, 1 и 0, 0, 0, 2. И, соответственно, каждый из роутеров рассказывает, какими link local адресами он на нас смотрит. Вот link LSA – это как LSA-ки-восьмерки. Ну, Type 8 – это даже намекает. Показывает, что у нас есть две LSA-ки в регионе. Я думаю, что здесь 0, 0, 0, 2 должно быть. Что роутер 0, 0, 0, 1 говорит, я четвертым интерфейсом смотрю в среду. И 0, 0, 0, 2. Я четвертым интерфейсом тоже смотрю в среду. Как мы смотрим локальные IDшники интерфейсов? Show IPv6 и SPF интерфейс показывают IDшники наши. Дальше.

Пазл собрали, link local выявили. Дальше смотрим на все остальные LSA-ки с адресной информацией. Inter-area LSA-ка – это, соответственно, бывшая трешка. Ну, и нынешняя трешка тоже. А интро-эре – это LSA-ка девятка. Это LSA-ка про маршруты в своем регионе. И пятерка, ну, она же семерка на самом деле, это Type 5. Очевидно, какая-то Type 5. Забавно, что будет у нас следующее. Для пятерок и для трешек у нас показываются сами префиксы. То есть показывается, про какую сетку идет рассказ в конкретной LSA-ке. Про девятки такого, к сожалению, нет. Но, соответственно, про девятки указывается, к чему эта девятка была приклеена. Вот показывается, что придумал ее роутер первый. Придумал он про LSA-ку свою первого типа. И вот link ID у него нулевой. Reference to LSA-ID тоже 0.

Так, внутри там, естественно, будет про какую-то сетку рассказ. Ну, в нашем случае, скорее всего, про FD01.22.664. Так, вот мясо каждой из этих LSA-ек. Роутер на LSA-ке по-прежнему все то же самое показывает. Показывает, что у нас есть один линк на соседа. Транзитная сетка, значит, в сторону LSA-ки двушки. Показывается, что мы – это 0.0.0.1. И мы видим LSA-ку второго типа, которая выпущена роутером 0.0.0.1. И ID-шник у нее будет четвертый. Вот. Дальше мы заказываем LSA-ку второго типа с ID-шником 4 и с Advertising Router ID 0.0.0.1. Вот у нас она будет. Show IPv6 USPF Database Network Advertising Router 0.0.0.1. На самом деле, можно еще LSA-ид запросить, но он какой-то там кривой будет, поэтому обычно просто Advertising Router заказывают. Вряд ли у вас будет много разных LSA-ек второго типа, выпущенных одних и тем же роутером.

Ну, в нашем случае, да, мы видим, что у нас есть LSA-ка, соответственно, выпущенная 0.0.0.1, интерфейсом номер 4, и к ней подключены два роутера. 0.0.0.0.1, 0.0.0.2. Это вот как раз, вот она, LSA-ка. В одну сторону смотрит первый роутер, в другую смотрит второй. Так, дальше. Можно посмотреть link-local адреса, которые у вас известны. Опять же, это все LSA-ки, которые распространяются в пределах канала, поэтому вы должны будете, когда заказываете LSA-ки восьмого типа, говорить не просто show IPv6 USPF Database, не просто указывать тип LSA-ки, который вас интересует, но вы должны будете сказать, на каком интерфейсе она вас интересует, потому что они будут привязаны уже к разным интерфейсам. Ну и если хотите все LSA-ки восьмого типа посмотреть, то можете просто на этом остановиться. Если хотите сказать, что вас интересует какая-то конкретная LSA-ка,

можете сказать, вот вас интересует та самая LSA-ка, выпущенная роутером 0.0.0.1. И вот здесь вот, вот он, наш link-local адрес. Эту LSA-ку придумал 0.0.0.1 на своем интерфейсе третьем. То есть вот у него третий интерфейс, и вот на нем есть вот такой вот link-local адрес. Когда второй роутер будет подсчитывать кратчайший маршрут, он скажет, что я вот могу, например, добраться до какого-то там вот дальнего роутера в углу сети, ну и, соответственно, next-hop у меня будет IP-шник тот самый, который на третьем интерфейсе висит. В таблицу маршрутизации будет добавляться именно он. Роутер-праорити здесь у нас указывается. Это роутер-праорити при указании next-hop. У нас может быть ситуация, в которой несколько роутеров будут иметь разные приоритеты в исходящих рашках. Соответственно, в таблице маршрутизации нужно будет добавить тот роутер, у которого приоритет будет больше. Если у нас есть несколько роутеров.

Так, что здесь еще у нас? Интра-эреа адреса. Это вот адреса, которые доступны в своем регионе. Допустим, у вас есть роутер-2, и вот он хочет посмотреть LSA, которая выпущена роутером R1. Мы указываем showipv6.uspf-датабейс. Дальше указываем тип LSA, префикс LSA. Это интра-эреа как раз префикса. И говорим, дайте, пожалуйста, ту LSA, которая выпущена роутером 001, вот этого самого типа LSA 9. И здесь будет у нас, кто выпустил LSA, каким интерфейсом он ее выпустил. И показывается, да, какой адрес был и сколько префиксов на этом интерфейсе висит. Вот. Это маска сети и метрика.

Так, так, так, так. Если у нас есть интер-эреа префиксы, то есть маршруты, пришедшие из другого региона, формат там будет примерно похожий. Опять же, показывается, какой роутер придумал такую LSA-эко. Показывается... Так, сейчас. Показывается сетка fd02.2 с 64-й маской. И показывается метрика. В нашем случае метрика 0 означает, что интерфейс вот этот вот самый, на котором висит такая сетка, сам по себе имеет метрику 0. Поэтому, когда АБР перекладывает такую сетку, он говорит, я знаю, как добраться до этой сетки за суммарную стоимость в 0 копеечек. Ну, да. В случае, например, если это был интерфейс лупбека, вот даже у ЦИСКИ будет такое поведение как раз по умолчанию, что лупбеки будут иметь стоимость 0 копеек. Так. Ну и, соответственно, последнее. Это LSA-ки пятерки. Они же семерки. Show IPv6. USPF Database External.

Или NSSI External. То же самое, что было в IPv4. И можно заказать детальную сетку. Прямо в явном виде сетку указать. То есть не надо говорить, покажи мне сетку, которую... Что там? ЛSA-ку пятерку, которую придумал Вася. Можно просто сказать, какую сетку вас интересует показать. И вот все, что здесь есть. Все, на самом деле, нам уже привычно и знакомо. Кто придумал? ASBR ID. Дальше. Какая сетка? FDFF. По 64-й маске. Какая метрика? Метрика второго типа. 20 копеек. Ну, 20 долларов, точнее. То есть это все то же самое, что было в IPv4. Если мы будем заказывать show IPv6.OSP в датабейсе NSSI External, то... Ну, в общем, да. Оно будет показывать все то же самое. Так. Если вдруг мы находимся в регионе, в котором у нас нету ASBR, то рядышком прикладывается LSA-ка четверка. И вот на R2, вот здесь вот, в первом регионе, если мы будем заказывать, у нас действительно LSA-ка четверка будет.

Роутер 1 является ASBR. Мы его роутер ID в первом регионе вот здесь вот не видим. Ну, поэтому мы должны будем получать LSA-ку четверку для того, чтобы узнать, как до него добраться. В LSA-ке пятерке написано, кто придумал эту LSA-ку. 0, 0, 0, 1. И в регионе первом такого роутера нету. Поэтому для того, чтобы пазл все-таки собрался, R2, будучи ABR, перекладывает не просто LSA-ку пятерку, а прикладывает рядом с ней четверку. И говорит, для того, чтобы добраться до 0, 0, 0, 1, ходите, пожалуйста, через меня, через 0, 0, 0, 2, за моей спиной. 20 копеек маршрут стоит до ASBR. Вот так вот это работает. Дебажить IPv6 OSPF, соответственно, дебага IPv6 OSPF Hello. Дебага IPv6 OSPF Packet.

Дебага IPv6 OSPF SPF. Ну, с Hello пакетами все понятно. Дебага IPv6 OSPF SPF – это построение LSDB. То есть, если у нас приходят какие-то новые LSA-ки, оно у вас будет показываться на консоли. Или если у вас пересчиталась топология в результате изменения LSA-к первого-оторватива и маршруты получили какие-то другие NextHop или другие метрики, то, соответственно, тоже здесь это будет показываться. Если вас интересуют какие-то конкретные маршруты, то вы можете заказать InterArea, IntraArea или внешние экстернал маршруты. Так. Стабы – то же самое абсолютно. Все абсолютно один в один. Вообще ничего не поменялось. Настройка стабов идентична по отношению к OSPF второй версии. Команды абсолютно те же самые. Редистрибуция – та же самая будет. Default Information в брос дефолта – та же самая. Default Information originate always или Default Information originate always.

Если у нас в таблице маршрутизации дефолта нет, он все равно будет вбрасываться. Видел эсэки пятерки. Так. Да. Вот она пятерка с дефолтным маршрутом. У IPv4 у нас в таблице маршрутизации маршруты показывались O. O – пробел EA. O – пробел E1. O – пробел E2. Или O – пробел N1. O – пробел N2. В IPv6 решили вот этот пробел сократить. То есть зачем писать пробел, если в принципе и так все понятно. Поэтому OE1 слитно. O – N2 слитно. Это значит вот как раз маршрут из OSPF. И дальше показывается элэсэйка пятерка или семерка. И первый или второй тип – это, соответственно, метрика элэсэйки пятерки или семерки. Если у вас есть интер-эреа маршрут, он показывается EA.

Вот. О – E – E – E – E – E – E – E. Или O – E – E просто O – E. Так. Далее. Далее. Далее. Далее. Далее. С редистрибуцией все абсолютно точно так же, как и в IPv4. То есть можно забирать маршруты из BGP, из EGRP, из OSPFV3. Потому что он, соответственно, с IPv6 работает. Из RIPNG или из ISSA. Все эти протоколы работают с IPv6, из них можно забрать маршруты и включить в анонсы OSPF. Можно вбрасывать маршруты в глобальную таблицу, можно вбрасывать в VRF. И есть нюанс. Если у вас есть роутер, и вот у него есть один интерфейс, на котором вы включили OSPF.

OSPFV3. И у вас есть другой интерфейс, на котором вы включили EGRP. И вы говорите, пожалуйста, перекладываем маршруты EGRP-шные в OSPF. И вот на интерфейсе, на своем собственном интерфейсе роутера у вас висит маршрутизируемый IP-шник FD, например, не знаю, 0022.64. Вот этот вот IP-шник, он как бы connected, но он также как бы и EGRP-шный. И для того, чтобы connected маршруты, принадлежащие другому протоколу, который вы хотите redistributить, они вот redistributились, вам нужно будет указать вот эту вот штуку, include connected. Это именно фича IPv6, что если вы забираете из другого протокола маршруты, то нормально redistributиться по умолчанию будут только маршруты, не connected. Вот чтобы connected тоже redistributились именно те, которые включены в другой протокол, вот надо будет вот эту вот самую штуку заказать. По умолчанию в OSPF второй и третьей версии метрика второго типа, метрика 20.

Можно заказать явно через либо команды redistribute, либо через дефолт метрик, либо через roadmap. Вот пример, как это выглядит для roadmap. У нас есть два маршрута с тегом 1, с тегом 2. Мы говорим, забираем только маршруты, которые матчатся по тегу 1. И назначаем тип метрики 1, метрику 10. Redistribute, static, roadmap, static to OSPF. Маршруты redistributятся. Те маршруты статические, у которых был тег 1, вбрасываются в OSPF. Те маршруты, которые не получили тег 1, они не прошли roadmap, не проматчились, не пропермитились. И, соответственно, в таблицу не попали. Так, здесь вот как раз вот это вот, не обращайте внимания, это косяк. Этого быть не должно. У нас появляется только маршрут OSPF V3 до вот этой вот сетки.

FD11, 2 2.0 по 64 маске. Вот этот вот маршрут не прошел фильтрацию и не попал в таблицу. Так, show IPv6 road покажет вам маршруты, да, что OE1 – это маршрут OSPF-овский, внешний, полученный через LSV-ку пятерку, и метрика в нем первого типа. Вот метка tag1 сохраняется для OSPF-ских маршрутов. Это link local адрес соседа, который такой маршрут прислал, ну, точнее, который мы посчитали должен быть next hop. И поскольку метрика первого типа, то мы можем десятку сложить с forward metric и получить общую метрику в таблице маршрутизации 11. Административное расстояние OSPF 110. Если что, можно поменять, но не нужно. Так, если мы используем OSPF IPv4, OSPF V2, то фильтровать трафик, как вы помните, фильтровать маршруты в OSPF V2

мы можем либо в направлении из таблицы посчитанных маршрутов OSPF в сторону таблицы маршрутизации, либо наоборот, если мы забираем маршруты из таблицы маршрутизации, вбрасываем их в OSPF в виде LSV-к пятерок. То есть сделать так, чтобы не отправлять какие-то LSV-ки мы не можем. Мы можем только не генерировать эти LSV-ки. Или если мы приняли уже какие-то LSV-ки, то мы все равно их отправим своим соседям, и мы посчитанные маршруты из этих LSV-ек можем не вбрасывать в таблицу маршрутизации. Дистрибьют-лист в OSPF V3 будет работать, в принципе, так же, как в OSPF V2, за небольшими исключениями. Во-первых, работает только с префикс-листами. То есть если вы в IPv4, в OSPF V2, могли указать дистрибьют-лист с аксесс-листом или с роутмапом, и таким образом там достаточно гибко могли играть маршрутами, то вот в OSPF V3 в классическом режиме, по крайней мере, актуальные версии iOS, которые мне были доступны, вот они не поддерживали аксесс-листы или роутмапы.

Они могли работать только с префикс-листами. Вот, например, мы могли сделать префикс-лист, который из OSPF в таблицу маршрутизации разрешал только, допустим, 128-маски. Ну и в этой ситуации мы говорим «distрибьют-лист из OSPF в RIB», префикс-лист OSPF в RIB, in gigabit 00. Обратите внимание на следующий синтаксис. На то, что если мы указываем, что мы из OSPF в таблицу маршрутизации выбрасываем маршруты, то, соответственно, направление на вход, потому что «distрибьют-лист» работает именно с таблицей маршрутизации. Он говорит, что маршруты в таблицу маршрутизации из OSPF будут подвергаться фильтрации. Но когда мы говорим, что мы хотим фильтровать маршруты на вход и еще хотим дополнительно вот этот вот самый интерфейс проверить, gigabit 00, то в этом случае мы запросим маршруты из OSPF в таблицу маршрутизации и пропустим их. Если у них префиксы совпадают, в нашем случае OSPF, то RIB попадает под префикс-лист.

И если у них NextHop будет за интерфейсом gigabit 00. Вот только в этом случае мы их проверяем по фильтру. Если у нас есть какие-то маршруты, которые приходят, и у них NextHop будет какой-то другой, они не попадут под этот префикс-лист, и они не будут фильтроваться. То есть если вы заказываете в OSPF фильтрацию на вход в таблицу маршрутизации с указанием интерфейса, то под такой фильтр будут попадать только маршруты, у которых NextHop смотрит в сторону этого интерфейса. В дистанц-векторных протоколах это не так. В дистанц-векторных протоколах вы будете фильтровать эти маршруты прямо на входе. К вам приходит маршрут, и вы его в виде апдейта фильтруете. Он у вас в таблицу топологии даже не попадает. Поэтому там уже не ставится задача впустить его в таблицу маршрутизации с каким-то NextHop или не впустить, потому что вы сами апдейты расстреливаете на подлете. Здесь, соответственно, у нас понятия апдейт нет. Здесь у нас есть только понятие LSA. LSA фильтровать дистрибьюторством нельзя. Поэтому при фильтрации маршрутов в таблицу маршрутизации мы сначала у SPF говорим,

посчитай, куда смотрит у тебя NextHop, а только после этого мы пытаемся вбросить маршруты в таблицу маршрутизации, и там фильтр будет проверять, что именно мы будем разрешать. Если мы забираем маршруты из какого-то другого маршрутного источника, например, из BGP в USPF, соответственно, маршруты, получается, выходят из таблицы маршрутизации и дальше уходят в сторону USPF. Поэтому у нас направление Out, и мы указываем, откуда маршруты взялись с таблицы маршрутизации, что мы их хотим отдать в сторону таблицы маршрутизации. Distribute List, Out, BGP. Значит, при отдаче маршрутов в BGP-шных мы проверяем эти маршруты на соответствие префикс-листу. Так, да, контролировать адрес шлюза нельзя, но можно контролировать интерфейс, за которым будет сидеть шлюз. Если мы хотим, например, выполнять агрегацию,

никакой автоматической агрегации тут, конечно же, нету. У нас только все вручную делается. Агрегация маршрутов, которые в виде LSA-ктрешек приходят, точнее, уходят с АБРа, делается точно так же, как она делалась и в USPF V2. Area, дальше номер региона, из которого мы забираем мелочевку. Range, суммарка, которую мы будем отдавать во все остальные регионы. Если мы хотим LSA-ктрешек суммировать, то, соответственно, тоже это делается все примерно так же. Единственное, что раньше было summary address в USPF V2, здесь у нас summary prefix. Было summary address. Ну, в общем-то, действительно, summary prefix немножко более логичным. Так. USPF V3 уже не работает в цисках в режиме совместимости с RFC 1583, в котором у нас по умолчанию работают циски в USPF V2.

Поэтому метрика в USPF V3 по умолчанию уже нормальная. То есть максимальная метрика из всех компонентов. Если у нас есть маршрут FD002.1 по 128 маске с метрикой 10 и FD002 с метрикой 20, то, соответственно, LSA-ктрешек мы сделаем с метрикой 20 за всю сеть, которая у вас только есть. Вот. Пятерки вы в явном виде указываете метрику или роутмапом, или там что-то еще. Дефолт метрик. Виртуаллинки работают абсолютно точно так же, как и в случае с USPF V2. То есть никаких вообще изменений нет. Указываете, через какой регион у вас прокладывается виртуаллинк, и роутер ID того соседа, с которым вы хотите реплицировать таблицу нулевого региона. При этом, естественно, что роутер ID в этом регионе должен быть. Так. Если вы хотите играть с административным расстоянием,

тоже так же, как и в случае с USPF во второй версии, можно использовать Distance USPF, и тогда вы задаете отдельные значения административного расстояния для разных маршрутов. Вот Distance USPF, Intra Area Takeda, Inter Area Takeda, External Takeda. Либо можно сказать просто Distance и число. Сказать, что все три значения вы задаете одновременно. Например, Distance 110. Это значение по умолчанию. Так. Значения по умолчанию такие же, как в USPF 110. Здесь везде 110. Да, 170 непонятно откуда взялось. Небольшой нюанс, что на уровне отдельного маршрута в USPF V3 в классическом режиме вы переопределить AD не можете. То есть в USPF V2 вы могли сказать Distance, циферка, дальше IP-шник, маска и дальше название аксесс-листа. И, соответственно, вы указывали, что все маршруты, которые у вас в USPF посчитаны,

и у вас шлюзом будет вот этот вот IP-шник и маска, а префикс попадает под аксесс-лист, то, соответственно, вы им назначаете циферку административного расстояния. Здесь такое уже сделать не покатит. Если вы указываете циферку, то циферка указывает просто, что все маршруты, которые у вас есть, вообще все, будут иметь административное расстояние одинаковое. Просто да, немножко не доделали в CISC-е USPF V3. Если вы хотите использовать аутентификацию, то, ну, это делается... Сейчас. Да, на следующем слайде как раз покажу. Если вы хотите использовать аутентификацию с помощью Authentication Trailer, то, на самом деле, синтаксис, который здесь будет использоваться, он будет использовать ключевые цепочки, и команда там будет на интерфейсе заимствоваться от IFMode, который мы с вами не проходили, но который пройдем в ближайшее время. Еще раз подчеркну, что эта штука может не поддерживаться даже CISC-ами всеми. Поддерживается это с 15.4 EOS,

то есть действительно на самых недавних EOS это у вас будет. Для того, чтобы это заработало, вы должны будете создать ключевую цепочку, так же как в USPF V2 задать криптографический алгоритм. Хотите, можете MD5 запросить, хотите, можете SHA-256-512. И дальше вы указываете ключевую строку, и на интерфейсе прописываете вместо IP USPF Authentication, вы указываете USPF V3 Authentication, Keychain, и дальше ключевую цепочку. Специально включать аутентификацию на уровне региона или чего-то еще не нужно, просто указываете, да, вот эту вот команду, она сама все за вас сделает. То есть это уже не две команды разные, как было в USPF V2, а одна. Несмотря на то, что вы используете синтаксис вот этот вот самый USPF V3, который характерен для IFMode, эта команда будет работать и с классическим режимом тоже. Поэтому если вдруг вам говорят, что в классическом режиме не поддерживается SHA-256,

если SHA-512, то есть так называемые мощные крипто-алгоритмы, да, свежее шифрование, то это неправда. Если вы используете authentication trailer, то вы можете использовать в классическом режиме вот эти вот самые SHA-хэши. Если вы хотите использовать USPF V3 классический режим без authentication trailer, то для защиты вам придется использовать IPsec. Вы должны будете придумать security параметры индексы. Это фактически ключ. Номер ключа, простите. Номер, ну да, номер ключа. Вы должны сказать, какой алгоритм, какой процесс вы будете использовать, MD5 или SHA-1. И дальше вы должны будете сам ключ, само мясо ключа придумать. И вот на уровне интерфейса, соответственно, вы задаете команду IPv6 USPF authentication. Дальше вы указываете, какой тип аутентификации вы будете использовать. Никакую уже не ключевую цепочку, а прямо сразу пишите IPsec. Дальше номер ключа SPI500.

Тип шхэша, который вы будете использовать, MD5. И ключ, который у вас здесь будет. Ключ будет зависеть от конкретного механизма, который вы заказываете. Если вы заказываете MD5, то нужно 16-байтовый ключ. 16 байт – это 32 символа. И вот здесь вот у нас 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, ABCDEF – 16 символов. И еще раз 1, 2, 3, 4, 5, 6, 7, 8, еще раз 16 символов. 32 символа – 16 байт. Если вы заказываете SHA-1, то вам нужно 20 байт. Ну, соответственно, вот 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0. 40 символов, 20 байт. Понятное дело, что в реальности это будет очень неудобно прописывать. Тем более, что сгенерировать по-честному 20 байт совершенно произвольных будет нелегко. Но, тем не менее, предполагается, что вы это сделаете. Но если вы сделаете, да, у вас IPsec будет шифровать трафик. Точнее, не шифровать, а подписывать.

MD5 и SHA-1 будут именно цифровую подпись пакетов делать. Если вы хотите именно шифровать, шифровать, то вы должны будете и security параметр индекс задать, сказать, какой протокол вы будете использовать для шифрования ESP-AES-CBC-128. Это значит, что вы используете протокол шифрования ESP, алгоритм шифрования AES-CBC, длина ключа 128 бит, и дальше вы указываете сам ключ. Вот он. И затем вы указываете, что вам нужно хаширование тоже. SHA-1 и вот это вот, соответственно, ключ для хаширования. Вы должны будете придумать сначала 16-байтовый ключ для AES-а, и потом 20-байтовый ключ для SHA-1. Ну и, естественно, что эти ключи должны быть каким-то образом случайные. В реальности, ну, это достаточно тяжело делать. Придумывать ключи, чтобы они были случайные, чтобы они совпадали на соседних роутерах.

Поэтому, конечно, можно было это сделать как-то более удобно, но, увы, никак не сделано. OSPF и протоколы согласования ключей, к сожалению, несовместимы. Если вы хотите, вы можете на уровне всего региона сделать задание, что все интерфейсы, которые у вас будут в OSPF и в третьем, все должны однотипно работать. Можно сказать, Area 1 Authentication или Area 1 Encryption, что вы либо цифровой подписью подписываете пакеты, либо и шифруете пакеты OSPF-ские тоже. Но это чуточку более интересная идея, что вы на уровне всего региона говорите на одном роутере, что все интерфейсы, которые в этом регионе есть, все должны использовать одинаковое шифрование. Понятное дело, что это меньше настроек. Чуточку ухудшается безопасность в том смысле, что у вас не попарно все роутеры будут иметь разные ключи. Ну, то есть, пара роутеров имеет отдельный ключ любая. У вас один ключ на всех. Но все равно это лучше, чем ничего. И все равно это, по крайней мере, чуточку легче поддерживать, чуточку легче обслуживать,

чем когда у вас действительно отдельные ключи на все пары роутеров. Так. Давайте попробуем с вами это поконфигурировать. У нас сейчас с вами есть наши роутеры, и там, если мне память не изменяет, есть следы IPv6. Давайте это проверим, гипотезу. Вот мой роутер R1. Enable show IPv6 interface brief. Да, у нас действительно есть IPv6 на интерфейсе Ethernet 0.12, и у нас есть только он. Давайте с вами на роутере 1 поднимем IPv6 на туннельном интерфейсе. У нас туннельный интерфейс как раз будет грешный, и мы заодно потренируемся работать с IPv6 в DMVPN. Очень интересная штука. Соответственно, сейчас будем работать с ней. Что нам потребуется?

Нам потребуется включить IPv6 на туннельном интерфейсе, и нам потребуется подружить OSPF v3 поверх этого самого туннельного интерфейса. Давайте для начала, просто чтобы вспомнить, как все это дело выглядит, поднимем OSPF v3 на интерфейсе Ethernet 0.12 между первым и вторым роутером. Так, show IPv6 protocols. Я проверю, какие у меня сейчас протоколы маршрутизации IPv6 запущены, чтобы не получилось, чтобы там какой-нибудь IPv6 EGRP внезапно организовался. Но вот его там нет. Убедитесь, пожалуйста, что у вас тоже show IPv6 protocols не показывает ничего лишнего, что никакого там EGRP нет, RIP-NG нет, а если есть, выпиливайте. И, соответственно, conf.t.ipv6.router.ospf1, номер экземпляра 1. И указываем, что у нас есть таки роутер OSPF.

Можем роутер ID задать, если захотим. Можем надеяться, что он автоматически каким-то образом поднимется. Но, опять же, алгоритм будет использоваться тот же, что берем самый большой IP-шник с лупбеков, если есть. Если лупбеков нет, то берем просто самый большой IP-шник. IPv4. У вас нет строки ND. Это значит, что у вас, скорее всего, на интерфейсе ни одном нету IPv6-адресов. Убедитесь, пожалуйста, что вы включили IPv6 Uniconstrating, и что у вас на интерфейсе Ethernet 0.12 есть строчка IPv6 Enable. Вот интерфейс Ethernet 0.12, IPv6 Enable. Ну и заодно я на нем прописываю IPv6, OSPF1, Area 0. Аналогичные команды сделаю на втором роутере. Enable, ConfT, интерфейс... Нет, не интерфейс, а IPv6 Unicast Routing.

Так, IPv6 роутер OSPF1, интерфейс Ethernet 0.12, и IPv6 Enable, IPv6 OSPF1, Area 0. Включаем в нулевой регион наши роутеры. Выясняем, что да, таки действительно у нас сейчас должно установиться соседство. По крайней мере, я на это очень надеюсь. Do show IPv6 OSPF Neighbors. Скорее всего, там они, да, сидят, ждут окончания wait-таймера. Wait-таймер 40 секунд. С момента, когда включили OSPF на интерфейсе, он, соответственно, 40 секунд ждет и пытается выбрать DR-а, BDR-а. Видите, они сидят в состоянии DR-AZER. Они не просто так там сидят. Они ждут окончания wait-таймера, который по умолчанию 40 секунд. И после окончания wait-таймера они говорят,

мы понимаем, кто должен стать DR-ом. Вот они договариваются, действительно. Сейчас у нас DR-ом должен стать, ну, скорее всего, R2, потому что у него ID-шник больше. Do show IPv6 OSPF интерфейс. Да, это наш интерфейс. И мы на этом интерфейсе DR. Да, вот, state DR. Да, мы DR. Действительно, подрались между собой два роутера. У одного ID-шник 101522, у другого ID-шник 101511. Приоритеты одинаковые единички по умолчанию. Поэтому выиграл право стать DR-ом тот, у кого ID-шник больше. Так, дальше. Дальше, дальше, дальше. Таймеры вот как раз. Hello timer 10 на 40. И wait-таймер 40 секунд. Сколько мы ждем перед тем, как объявлять DR-а? У вас DR-10511.

Возможно, у вас на роутере первом wait-таймер закончился до того, как вы включили R2. Да. Если у вас wait-таймер на роутере первом закончился раньше, чем включился в сеть R2, то в этой ситуации, да, R1, оказавшись один одинешенек на интерфейсе, выбрал себя DR-ом, после чего стал рассылать hello-сообщение с криками «Я DR!» и когда R2 включился, R1 уже просто занял право стать DR-ом. Копипаст в консоли работает. Там Ctrl-C, Ctrl-V, по идее. Или, нет, мышкой, мышкой, мышкой, мышкой. Да, мышкой. Ctrl-C — это отправляется комбинация. Так, что ты здесь хотел сказать? Вот, да. Сейчас у нас два роутера подружились между собой. Сообщение про установление соседств у нас действительно образовалось. Show IPv6 USPF Neighbor показывает, что сосед есть.

Сосед имеет роль BDR. Он обнаружен на 13-м интерфейсе. И интерфейс наш Ethernet 0012. Так. Замечательно. Мы видим, что у нас есть интерфейс бродкастовый. Поэтому сейчас в таблице топологии у нас будет две LSE-ки первого типа, одна LSE-ка второго типа, две LSE-ки восьмого типа. Вы это все уже знаете. То есть LSE-ки первого типа за роутеры, LSE-ки второго типа за бродкаст интерфейс, восьмой LSE-ки за link-local ID, link-local адреса, которыми роутеры друг на друга смотрят. И маршрутизированных IP-шников у нас нету, поэтому больше ничего там и не будет. Show IPv6 USPF Database. Вот. Как и прогнозировалось, две LSE-ки первого типа, одна второго, две восьмого. Давайте смотреть, как у нас собирается пазл. Show IPv6 USPF Database,

router self-originate. Наша собственная LSE-ка. У нас есть наш роутер, ID-шник у нас 10.15.2.2. Мы сами про себя рассказываем. Это в версии LSE-ки 0 за, ну, фактически, да, за самая просто нормальная LSE-ка, просто обычная, без ничего. В этой LSE-ке есть один линк, который смотрит на LSE-ку второго типа, метрика интерфейса 10. Мы эту отправили 10-м интерфейсом. И LSE-ка второго типа, на которую смотрит наш линк, будет иметь ID-шник 10 и advertising-роутер ID 10.15.2.2. Заказываем такую LSE-ку. Нас интересует network.lsa. Дальше нас интересует advertising-роутер 10.15.2.2. и LSE-ид. Да, LSE-ид заказать нельзя.

Ну-ка, может быть, там можно как-то постараться. Да, link-state ID, он заказывается вот в таком вот дурацком виде, но мы заказываем ID-шник 10. и, соответственно, advertising-роутер 10.15.2.2. То есть мы заказали LSE-ку второго типа с ID-шником 10, выпущенный роутером 10.15.2.2. И вот это самая LSE-ка. Действительно ID-шник 10. Действительно придумал ее 10.15.2.2. И он говорит, что к этой LSE-ке второго типа подключен и роутер 2, и роутер 1. Запрашиваем LSE-ку за первый роутер. Роутер на LSE-ка 10.15.1. А, сейчас нет. Роутер. Там надо advertising-роутер рассказывать. Advertising-роутер 10.15.1.1. В OSPFV2 мы заказывали LSE-ид в выпущенной LSE-ке.

Здесь надо смотреть пару и ID-шник, и advertising-роутер. ID-шники здесь уже меньше означают существенно. Ну вот в нашем случае, да, мы видим роутерная LSE-ка, выпущенная роутером 10.15.1.1. У нее ID-шник неговорящий 0. Вот. Она говорит, что как раз транзитная сетка на LSE-ку двойку соседства смотрит. И это транзитная LSE-ка, которая нам уже известна. Все, пазл сошелся. Все топологические линки мы собрали. Роутер 2 смотрит на LSE-ку второго типа. LSE-ка второго типа. К ней подключается роутер 1. Больше никаких интерфейсов нет. Дальше, если мы будем строить кратчайшие маршруты, которые на роутере 2 будут смотреть в сторону роутера 1, нам потребуется LSE-ка восьмого типа. То есть мы построили кратчайший маршрут, выяснили, что NextHop будет роутер 1. И возникает вопрос, а вот NextHop это что? В таблицу маршрутизации мы какой адрес должны добавить. И для этого нам будет полезно

link LSE-ка. Указываем интерфейс, на котором эта LSE-ка будет. Так, нас интересует интерфейс Ethernet 0.0.12. И дальше говорим. Эта LSE-ка должна быть выпущена роутером 10.15.1.1. И вот она, LSE-ка, которая выпущена в нашем канале Ethernet 0.0.12 роутером 10.15.1.1. То есть ID-шник интерфейса Cisco посчитала сама из вот этой вот фразы. И здесь вот видно тот link local адрес, который соответствует этому интерфейсу. Вот интерфейс Ethernet 0.0.12. Номер у него будет 13, кстати, к слову. И показывается link local. То есть когда мы будем в таблицу маршрутизации какие-то маршруты добавлять,

мы будем добавлять именно этот IP-шник. Если мы хотим сказать, что у нас есть какие-то сетки, доступные в нашем регионе, давайте вот, не знаю, loopback какой-нибудь добавим, что ли. do show ipv6 interface brief. Так. Вот у меня есть loopback. Loopback 0. Давайте его добавим в таблицу топологии OSPF EV3. У меня на нем IP-шник fd номер комплекта 2.2. По 128 маске. conft, интерфейс loopback 0, ipv6, ospf1, area 0. Добавляю его. И смотрим на то, что в итоге получилось. Сейчас должно получиться то, что у нас в LSA-ке топологической никаких изменений не произойдет. А вот добавится LSA-ка, так называемая

intra-area prefix. OSPF database. Вот она, intra-area prefix LSA-ка. LSA-ка 9. Рассказывает, что у нас есть какая-то сетка, доступная внутри региона. К сожалению, здесь не показывается, как в LSA-ках, трешках или пятерках, что именно за сетка есть, поэтому мы должны заказывать детальный вывод самой LSA-ки для того, чтобы увидеть саму сетку. Prefix Advertising router 10, 15, 2, 2. Вот она, это LSA-ка. Она рассказывает про сетку FD15 2.2 по 128-й маске. В таблице маршрутизации эта сетка будет доступна на всех роутерах, и линкокл адрес соседа будет указан в качестве Next-hop-а. Enable

Show IPv6 Road OSPF Вот он. Буковка О намекает на обычный intra-area маршрут FD15 2.2 по 128-й маске. Все честно, все работает. Так. Мы с вами просто включили OSPF, просто подняли его на интерфейсах, посмотрели на содержимое таблички. Давайте теперь поиграем с интерфейсами. У нас есть наш замечательный туннельный интерфейс. В этом туннельном интерфейсе мы сейчас будем запускать OSPF. И я очень сильно хочу, чтобы у нас этот OSPF дружил по туннельному интерфейсу не в нулевом регионе. Вот. То есть, я хочу сделать так, чтобы у нас действительно связь была через, например, регион номер 101. Это позволит нам сделать задел под Virtual Link. Мы сейчас с вами поднимем связь через

101 регион в туннельном интерфейсе. И дальше будем строить через этот 101 регион в Virtual Link до центрального роутера. И давайте посмотрим, к чему это приведет. Conft. Включаем интерфейс туннель 0, IPv6 enable. Включаем там IPv6 вообще. Включаем этот интерфейс в как называется в OSPF. IPv6, OSPF 1, Area. И дальше я предложил использовать 101 регион. Вы, пожалуйста, тоже у себя включайте туннельные интерфейсы в 101 регион. После чего мы столкнемся с проблемой. Проблема заключается в том, что у нас для работы OSPF на интерфейсе нужен мультикаст. А мультикаст у нас будет резолваться в DMVP немножко криво. И это криво заключается в том,

что, соответственно, мультикаст ходит только между с полком и хабами. Он между с полками напрямую не ходит. Поэтому нам нужно будет сказать, что у нас на этом интерфейсе есть IPv6 экземпляр NHRP, потому что IPv4 отдельно, NHRP, IPv6 отдельно. Нам нужно будет сказать, что этот экземпляр NHRP смотрит на хаб центральный роутер, что мультикаст отправляется хабу, что если вдруг нам захочется услышать с полки какие-то другие, то это опять же надо будет спросить хаб. И что тип среды на этом туннельном интерфейсе у нас будет не тот, который по умолчанию используется. По умолчанию на туннельных интерфейсах используется point-to-point. Объективно говоря, DMVP это не point-to-point интерфейс, это что-то другое. Это либо point-to-multipoint, либо можно сказать, что это интерфейс браткастовый. На браткастовом интерфейсе у нас будет выпускаться LSA второго типа, и, соответственно, трафик между роутерами будет ходить напрямую. А это как раз позволит нам перевести DMVP в фазу 2.

В фазе 1 весь трафик ходит через хаб, в фазе 2 трафик между сполками ходит напрямую. Давайте так и сделаем. В IPv4 мы этого не делали, а в IPv6 мы это сделаем. IPv6 OSPF Network Broadcast. Это предполагает, что у нас есть мультикаст, и это предполагает, что у нас есть полносвязная юникастовая топология, но мультикаст то у нас как раз не полносвязный здесь. Юникаст полносвязный, а мультикаст нет. Поэтому IPv6 OSPF Priority 0 мы отказываемся от выборов DR и BDR. И мы указываем, соответственно, что у хаба приоритет будет как раз не 0, и поэтому он будет DR всегда. Мы будем дружить с хабом, и все LSA будут передаваться через хаб. А дальше, поскольку он DR, он будет их транслировать всем остальным участникам. Ну и напрямую трафик между сполками будет ходить спасибо протоколу NHRP. Этот самый NHRP тоже нужно будет

настроить. Мы пока на туннельном интерфейсе настраивали только IPv4 NHRP. Здесь надо будет отдельно сказать, что у нас есть IPv6 NHRP Network ID ну допустим 1. Это мы запустили экземпляр NHRP на этом интерфейсе. Дальше IPv6 NHRP указываем, что у нас есть NextHop сервер. А для NextHop сервера нам нужно будет IPшник. А IPшник нужно будет указывать linklocal. А linklocal IPшник указывать произвольный неудобно. Поэтому я сейчас пойду на хаб и пропишу там какой-нибудь красивый linklocal адрес, чтобы его можно было удобно прописывать. Но я сделаю это попозже. fe80 2.101 пожалуйста пропишите у себя его тоже. Вот именно такой linklocal адрес просто потому, что прописывать настоящий linklocal который там сейчас возможно будет неудобно. Так прописываем только

не IPv6 а IPv6 NHS fe80 2.101 То есть я прописываю NextHop сервер говорю NextHop сервер будет вот такой вот linklocal адрес. Дальше возникает вопрос а где его собственно говоря брать IPv6 NHRP map fe80 2.101 и мы указываем публичный IPшник через который мы будем отправлять трафик вот этому вот соседу 101 101 101 101 101 Так Что это не пошло А надо вот так указать слэш 128 В IPv6 маппинги указываются обязательно для префиксов то есть в IPv4 мы указывали отдельные IPшники здесь мы указываем префикс fe80 2.101 slash 128 вы у себя пожалуйста вот все то же самое пропишите вот ровно те же самые команды IPv6 enable IPv6 usbf1 nr1 network broadcast проверить 0 network id nhs

map map до link local IPшник fe80 101 рядышком map multicast тоже соответственно 101 101 101 101 101 map mp map на IPv4 IPшник ничего страшного вот этот вот маппинг он указывает когда мы заворачиваем IP пакеты в GRE мы эти GRE пакеты должны куда-то отправлять GRE мы заворачиваем в IPv4 если бы мы хотели указать что IPv6 пакеты или любые другие пакеты мы заворачиваем в GRE IPv6 то тогда надо было бы указать туннель mode GRE multicast IPv6 вот так моде GRE multipoint IPv6 если бы мы такую штуку сделали то тогда у нас трафик заворачивался в IPv6 пакеты а сейчас они у нас заворачиваются в IPv4

что IPv4 вложение что IPv6 отправляется в сторону соседей по IPv4 вот мы указали что у нас есть multicast трафик он отправляется сюда мы указали что unicast трафик до linklocal IPшника FE80101 отправляется тоже туда же по всем остальным IPшникам мы будем спрашивать NextHopServer опять же мы его знаем потому что у нас маппинг прописан и в принципе этого должно быть достаточно для того чтобы у нас OSPF на интерфейсе завелся IPv6 прописали OSPF прописали тип среды прописали priority прописали network ID NHS mapping multicast все хорошо осталось только со стороны центрального роутера прописать я надеюсь что сейчас у нас все будет работать единственное что когда я со стороны центрального роутера это дело пропишу будет маленький нюанс заключаться в том что надо будет перерегистрироваться на NextHopServer потому что

multicast будет работать только для тех кто зарегистрировался так пробуем на R1 так а вот здесь я чувствую что у меня есть EGRP для IPv6 удалю-ка я его conft no IPv6 роутер EGRP 65000 так роутер OSPF а пардон пардон IPv6 роутер OSPF1 дальше интерфейс туннель 0 так интерфейс туннель 0 значит IPv6 enable прописываю ответные действия IPv6 OSPF 1 Area

101 IPv6 priority OSPF priority мне нужно чтобы этот роутер стал DR-ом и он стал с большей вероятностью чем любой другой роутер поэтому на центральном роутере я задираю приоритет относительно всех остальных так приоритет включили network type IPv6 OSPF network broadcast мы выпускаем LSA второго типа так и что-то у нас тут отвалилось да отвалилось потому что мультикаст у нас не работает поэтому down так ну и прописываем все необходимое для NHRP так давайте-ка я сделаю shutdown IPv6 IPv6 NHRP NHS а NHRP Network ID1 IPv6 NHRP

NAP 1 IPv6 IPv6 NHRP NAP Multicast threatening здоровья net ел с dentro share environment avez Так, и все. No shot. Этого должно быть достаточно для того, чтобы у нас IPv6 завелся. Интерфейс включается. Теперь ваши роутеры, которые долго пытаются зарегистрироваться в NHRP, они, соответственно, сейчас будут пытаться это сделать. И у них это через некоторое время будет получаться. И вот я вижу, что у нас начинают устанавливаться первые соседства. Третий комплект установился. Опять же, да, это происходит не потому, что... В смысле, это происходит не одновременно не потому, что там кто-то сначала сделал все остальное... Все необходимые шаги, а все остальные не сделали. Не одновременно это происходит потому, что ваши роутеры периодически пытаются перерегистрироваться, точнее, впервые хотя бы зарегистрироваться на хабе. И там есть определенный тайм-аут.

Они пытаются сделать, у них не получается, они впадают в спячку. Потом снова пытаются, снова... У них не получается, снова впадают в спячку. Если вы хотите, вы можете со своей стороны шатно-ушатно интерфейсом туннельным сделать и тем самым ускорить процесс. Я вот сейчас так собираюсь сделать. Туннельный интерфейс, шат. Сейчас интерфейс упадет. Ноушат. При выключении и по следующему включению интерфейса происходит перерегистрация. И вот на этом интерфейсе у нас обнаружен IPv6 сосед. Попробуйте тоже, пожалуйста, сделать. И вы получите, по идее, получите работающую соседство. При этом сейчас у нас таблица топологии должна будет измениться. У нас сейчас должны все роутеры среплицировать между собой базу 101 региона. Помимо того, что не знали базу нулевого региона, они еще и базу 101 региона должны будут усосать.

show ipv6 ospf database. Так. Вот это вот относится к нулевому региону. Мы его не трогали. Так. Да, вот это все это нулевой регион. А вот это вот это регион уже 101. В 101 регионе у нас есть наша собственная LSA. Есть... Так, что-то я не понял. А где все остальное? А где вот тот роутер, с которым мы установили соседские взаимоотношения? Вот такой вот ID-шник. show ipv6 ospf database. Что-то не хватает. То есть объективно, да, здесь у нас есть соседство. show ipv6 ospf neighbors.

Опа. Соседа на самом деле нету. Да, у нас соседство не установилось. Несмотря на то, что здесь пробежало сообщение о том, что соседство есть, на самом деле его нету. На самом деле что-то с ним случилось. Давайте дебаг смотреть. Что еще делать? дебаг. дебаг. дебаг. ipv6 ospf hello. Ждем дебаг. То есть мы ожидаем, что у нас сообщение будет отсылаться. Туннельные сообщения отправили hello. Получили hello не от того. Получили hello не от того. То есть нам в туннельном интерфейсе не приходят hello пакеты. Так, а что там скажет центральный роутер? show ipv6 ospf neighbors.

Он их видит в ddr.azor. Так, я ничего вообще не забыл там в настройках. Нет, таймеры нормальные. Я везде тип среды бродкаст указал. Поэтому таймеры там 10 на 40 должны совпадать. Ну и даже здесь видно, что у них у всех таймеры в диапазоне от 30 до 40. Так что здесь все хорошо. Если бы таймеры не совпадали, соседа просто бы в принципе не было. Ну давайте дебаг. pv6 ospf hello. Вроде бы, вроде бы. Мультикаст мы посылаем. Мультикастовое hello мы посылаем и видим в ответ кучу hello. Здесь мы снова посылаем и снова эти hello должны быть. Но по факту вот видно, что они не приходят. Что receiving hello на туннельном интерфейсе у нас нет.

Так, смотрим. Дебаг all. show ipv6 nhrp. Так, есть. Мультикаст весь отправляется туда. На роутрецентральном. And debug all. Show ipv6 nhrp. Мультикаст. Мультикаст никуда не посылается. То есть, несмотря на то, что на интерфейсе есть указание, что получатели, которые регистрируются на интерфейсе, должны будут попадать в базу мультикаста, здесь мы видим, что получателей мультикаста у нас на самом деле нет. Do show run interface. Туннель 0. Так.

Так. IPv6 nhrp. Map. Мультикаст. Dynamic. Вот эта вот команда, она должна указывать, что все, кто зарегистрировался в nhrp, они все должны являться получателям мультикаста. Но она почему-то не сработала. Давайте попробуем выключить туннель и включить его снова. Сделать то же самое на маленьком роутере. То есть, искусство, чтобы перерегистрироваться. Interface. 0. Shard. Перед этим включу дебаг в nhrp. Дебаг, IPv6, nhrp. Он так может? Дебаг в nhrp просто.

Так. Пошли регистрации. Пошли регистрации. Пошли регистрации. Receive registration request. Я думаю, что пора отключать дебаг. Здесь видно, что идет большое количество сообщений вот таких вот. Что не удалось замапить. Пошли. Замапить чего-то к NBMA. А! Семен Семенович! Я же забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Забыл. Интерфейс. Туннель 0. Да. У нас регистрация-то идет на IPшник FE82.1. А его кто-нибудь прописал? Его никто не прописал. IPv6 адрес FE82.1.

Слэш 64. Линк локал. Красивый линк локал адрес. Чуть не хватает. А я на коре это и делаю. То есть я прописываю линк локал адрес. И теперь надо перерегистрироваться. Потому что у нас вот этот вот IPшник является NextHub сервером. Shad. Да. IPшник 101. Спасибо, что поправляете. Выключаю туннельный интерфейс. Включаю туннельный интерфейс. И заставляю роутер перерегистрироваться. Соседство установилось. IPv6. Оспф. Neighbor. Во. Во.

Во. Во. Во. Во. Во. Это туннельный интерфейс. Соответственно на нем Оспф только что включился. Сейчас он будет ждать 40 секунд. Дальше он перейдет из дрозера в DR или BDR. И теперь у нас все будет хорошо. Да. Ну как всегда на самом деле вот эти вот все косяки мелкие. Если что-то не работает, то где-то ошиблись. Ну скорее всего ошиблись в чем-то простом. Вряд ли ошиблись в какой-то там штуке прям глобальной, которую надо там было настраивать по справочнику. Скорее всего где-то либо опечатались, либо просто забыли какую-то мелкую херню сделать. Вот. Установили соседство. Сосед перешел в full. DR как и предполагается будет 172.16.0.101. Центральный роутер. Он выпускает LSE ко второго типа и говорит, что к ней подключены все, кто подключен к центральному роутеру с помощью full взаимоотношений. Поэтому, несмотря на то, что у нас сосед всего один, в таблице маршрутизации мы будем видеть все IPшники наших

соседей в качестве next-hopов. Вот. И соответственно в таблице маршрутизации show.itv6.ospf.database у нас сейчас будет много-много-много всякого интересного в 101-м регионе. Вот. 101-й регион. В нем куча LSE первого типа. В нем одна LSE второго типа, придуманная DR. К ней подключены 7 роутеров, в том числе сам DR и 6 других мелких. Вот, скорее всего, вот все вот эти вот шестеро. Дальше. Они анонсировали inter-area префиксы в 101-й регион. Вот у нас они. И у нас есть некоторое количество link local адресов. Все страшные, ужасные. Нам они на самом деле не интересны. Но если мы захотим, мы можем эти link local resolve в таблице маршрутизации с помощью nrp. Теперь. Давайте посмотрим на саму таблицу маршрутизации. show.itv6.road.ospf.

И здесь выясняется, что несмотря на то, что у нас есть какие-то вот LSE, в них рассказывается про какие-то внешние сетки. В таблице маршрутизации этого ничего нет. И ничего этого нету именно потому, что если мы изучаем какую-то сетку в виде LSE 3 типа в ненулевом регионе, и у нас нет этой сетки в базе нулевого региона, не в виде LSE 3, не в виде LSE 1 типа, то эта сетка нам недоступна. И вот эта сетка из другого куска разрывного нуля. У нас сейчас 0 разорван. И нам нужно сделать так, чтобы этот 0 обратно собрался воедино. Я собираюсь сделать следующую штуку. Прописать кучу virtual link'ов. И, соответственно, сделать так, чтобы у нас базы нулевого региона все-таки среплицировались. На центральном роутере я сейчас буду поднимать virtual link'и до каждого из наших роутеров. А на каждом нашем роутере я скажу, что базу нулевого региона надо взять именно из центрального core R1.

Conf. Conf. Не интерфейс. IPv6. Роутер. OSPF1. Прописываем Area 101 через 101 регион. Строим virtual link. И реплицируем базу нулевого региона с ID'шником 172.16.0.1. Это ID'шник центрального роутера. Вы у себя это прописываете. Да. Нам IPv6 ругается, что если мы это будем делать, то мы будем отправлять Unicast-овые Hello-пакеты. А у этого роутера нет ни одного IPv6 адреса, который мы могли бы использовать в этом самом OSPF. Поэтому нам нужно будет сейчас на центральном роутере прописать какой-нибудь маршрутизируемый IP'шник. Интерфейс 100. Так. Интерфейс 100. IPv6 адрес.

FD. Какой бы мне сделать? .101-128. И повторяю попытку установить virtual link. Возможно, этому роутеру тоже нужно иметь IP'шник. Давайте попробуем этому роутеру нашему тоже IP'шник назначить. Да. Для того, чтобы построить virtual link, оба конца туннеля должны быть, конечно же, корректно настроены. И фактически, да, однотипный. Поэтому virtual link у него нету какого-то в кавычках сервера и в кавычках клиента. Это два АБРа между собой протягивают мостик. Соответственно, то, что я сейчас с центральным роутером прописываю, центральный роутер, в принципе, ожидает симметричные настройки иметь. Если я на центральном прописал публичный IP'шник, то, наверное, предполагается, что и во всех остальных роутерах тоже маршрутизируемые IP'шники будут.

Если у вас не ругаются, может быть, у вас этот самый есть loopback, который в USPF включен на роутере первым? Не знаю. Так. Так. Интерфейс P0.0. IPv6. Адрес FD15.1.128. Давайте так попробуем. Да. Если есть маршрутизируемый IP'шник в указанном регионе, то, соответственно, можно подняться VirtualLink. Вот я прописал маршрутизируемый IP'шник на туннельный интерфейс. Этот IP'шник точно будет реплицироваться по таблице маршрутизации, потому что у нас роутеры внутри одного региона будут.

В 101-м регионе мы анонсируемый IP'шник вот такой вот. FD15.2.1 по 128-й маске. В моем случае 15-й. Вы можете сделать FD01, FD02 и так далее. И, соответственно, поверх этих IP'шников мы будем отправлять HelloPacket. HelloPacket. И HelloPacket будут отправляться на IP'шник, который мы посчитаем в топологии до RouterID с вот этой вот самой 172.16.01. Я прописал публичный IP'шник на туннельном интерфейсе на моем роутере. Я прописал публичный IP'шник на центральном. Я прописал VirtualLink. И теперь... Он тут сейчас будет ругаться, что приходят пакеты, которые, в общем, неожидаемые. Вот. Must be VirtualLink. Но мы не прописали VirtualLink на центральном роутере. Сейчас я буду прописывать их. Мне благо как раз они валятся с достаточной регулярностью. Я буду видеть, с кем-то прописать надо VirtualLink. IPv6 роутер USPF1. Area 101. VirtualLink.

Так. Кто первый? Пописать. Походи по одному. 172. 16. Нет. Какие-то медишники-то у нас. 10, 15, 1, 1. Я знаю. Ду, шоу, IPv6, USPF, Neighbor. Так. 10, 3, 1, 1. 10, 4, 1, 1. 10, 5, 1, 1. 10, 5, 1, 1. Я знаю. Ду, шоу, IPv6, USPF, Neighbor. Так. 10, 3, 1, 1. 10, 4, 1, 1. Ду, шоу, IPv6, USPF, Neighbor. Так. 10, 3, 1, 1. 10, 4, 1, 1. 10, 5, 1, 1. 10, 12, 1, 1. так вроде все прописал все кто был прописан в качестве моих соседей все получили virtual

линки ну и соответственно вот да на наших роутерах у нас установлено соседские отношения по этим самым virtual link и мы можем это дело проверить вот действительно у нас тут появляется новая связь через интерфейс вот такой вот красивый и теперь реплицируется база нулевого региона по этой базе можно будет увидеть какие лосейки есть в нулевом регионе как следствие у нас база нулевого региона будучи с реплицированной получат сейчас все вот эти вот сетки которые есть в лосейки в лосейках трешках 101 региона и у нас таблица марштизации это все тоже начнет проявляться show ipv6 road вот все сеточки появились наш роутер является абэром наш роутер является концом virtual link а наш роутер является соответственно чем он является транзитным для трафика 101 регион ну и да

вот лосейки сейчас мы будем видеть датабейс училась и к первого региона часть из них dna значит don't age и 2 нормальные это те которые придумал первый второй роутер куча netlink state опять же большая часть из них дн и это они пришли через virtual link куча лосейк третьего типа они почти все дн и кроме тех которые мы сами придумали лосейки пятерки лосейки восьмерки это link local адреса они нужны у нас в пределах нашего провода и вот дальше пошло просто первый регион куча всякого разного так вот такой вот замечательный протокольчик мы сейчас можем на наших роутерах например вот на втором роутере у нас таблица маршрутизации тоже реплицируется и был шоу это 6 вот здесь маршруты уже будут какие-то полученные через лосейки трешки и вот

например fd0322.1 или fd0422.2 я могу сейчас попернуть пинг лица принципиально процесс сборки пазла в ipv6 не отличается от айпи в 4 но вот маршрутная маршрутная работа с маршрутами в айпи в 6 успехи она соответственно немножко отличается за счет того что у нас маршрутной информации злосаяк первого и второго типа выехала в лосейки восьмерки и девятки а так по большому тот же по большому счету тот же самый протокол ничего нового