Настройка IP-MPLS (1)

Продолжаем с вами курс по провайдерским сетям. И мы с вами достаточно много смотрели теории по тому, как устроены IP-сети с современными ускорениями в виде MPLS. Давайте попробуем немножечко это все дело поконфигурировать. Первое, что нам нужно будет узнать, это, соответственно, первые команды, с которыми сталкивается абсолютно любой сетевик. Я думаю, что, в принципе, вы догадываетесь, как назначается IP-адрес. Мы с вами это уже даже делали, но на всякий случай я вам показываю, чтобы вы команду видели, что если вдруг мы работаем на роутере EOS, мы используем на интерфейсе команду IP-адрес и дальше IP-шника маска. Если мы используем в EOS XR, то мы используем, в принципе, такой же синтаксис, интерфейс чего-то там, и в субконтексте настройки этого интерфейса IP-адрес, но уже без десятичной маски. Используем именно маску в префиксной записи. Еще раз подчеркну, что настраивается IP-адрес на том интерфейсе,

который смотрит в нужную вам среду. Может быть, эта среда будет физическая, может быть, эта среда будет виртуальная. То есть, если вы хотите работать с субинтерфейсами, то IP-шник вы должны, естественно, назначать на субинтерфейсе. Равным образом на субинтерфейсе, ну, там, где у вас IP-шник висит, вы будете назначать всякие правила типа там аксесс-листы, какие-то там, не знаю, шейпинги, все остальное, это все делается именно на логическом интерфейсе, на субинтерфейсе. Если у вас это все дело совпадает, то есть вы в среду нужную смотрите прямым проводом, интерфейсом, и у вас там нет никаких разделений на субинтерфейсе, на что-то еще, ну, прекрасно. Если есть, то не забывайте, что на физическом интерфейсе мы никакие настройки не делаем. Для любого взаимодействия делаем отдельный субинтерфейс. После того, как мы дали настройки на интерфейсе, у нас есть диагностика, которая позволяет нам посмотреть, что-то такое в итоге получилось. Она имеет вид show IP-интерфейс на цисках, на обычных, либо есть...

Так, кстати, да, не ошибся ли я там? Да, не IP-адрес здесь, простите, IPv4-адрес опечатался. Ну, в принципе, команда вот такую настройку тоже сожрет. То есть если вы скажете просто IP-адрес, она поймет, что вы имеете в виду. Равно на самом деле многие команды обычного Иоса, Иос XR тоже жрет. Они прописаны там как алиасы. Но в справке вот IP-адрес она вам не покажет, она вам потребует IPv4-адрес. Соответственно, в диагностике тоже в Иос XR заменяется все с IP на IPv4. Если мы работаем с IPv4, на IPv6, если мы работаем с IPv6. То есть синтаксис у XR при работе что с IPv4, что с IPv6 одинаковый. То есть show IPv6 interface. На интерфейсе назначается адрес команды, ну, предсказуемый IPv6-адрес. То есть, в принципе, Иос XR уже настроен на работу с IPv6 намного лучше, чем это делает Иос обычный.

Если Иос обычный изначально создавался в логике, что существует только протокол IPv4, а IPv6 никакого не бывает, и потом к нему уже IPv6 сбоку приклеивали, как попало, то вот в Иос XR, который появился, напомню, в 2004 году, уже было понятно, что IPv6 есть, поэтому весь синтаксис заточен под то, что нету какого-то превосходства IPv4 над IPv6. Если мы настраиваем один протокол, если настраиваем другой протокол, то количество буквок, которые надо вводить, оно примерно одинаковое. Равным образом, если мы захотим посмотреть список всех интерфейсов, на которых у нас есть, допустим, IP-адреса, в CISC, в обычный showIP-интерфейс или showIP-интерфейс-бриф, команду в табличном виде запрашивают. Ну, соответственно, на Иос XR это showIPv4-интерфейс-бриф. Эта команда покажет на роутере все интерфейсы, на которых у вас можно отправлять трафик, покажет на каждом из них, есть ли IP-адрес или нет IP-адреса, если есть, покажет, в каком VRF этот адрес будет,

про VRF сейчас будет отдельно, и показывает физику и канальный уровень, в API они или не в API. Что касается таблицы маршрутизации, showIP-роут в обычной CISC, showROAD IPv4 в Иос XR. Это надо запомнить, и showIP-роут в ней нету, равное нету showIPv4-роут. То есть мы смотрим таблицу маршрутов, и конкретно мы из нее заказываем маршрут IPv4. Логика здесь немножко изменилась по сравнению с обычным EOS. Также, как если вы в Иосе обычном вешаете IP-адрес на устройство, у вас порождается присоединенный маршрут, также и в Иос XR. То есть мы повесили IP-шник 10.0.0.2 на интерфейс, у нас породился конект от маршрута 10.0.0 по 24 маске. Вся логика, в принципе, плюс-минус километр одинаковая. Ну вот небольшое различие в синтезе. Если мы хотим добавить статический маршрут в обычном EOS, мы используем команду IPv4, дальше указываем IP-шник, маску,

и дальше два параметра. Ну, на самом деле параметров больше, но основные два. Это интерфейс, через который маршрут будет доступен, и IP-адрес, через который он, опять же, будет доступен. IP-адрес шлюза. Если вы не указываете IP-адрес шлюза, то маршрут все равно в таблицу принимается, но добавляется так называемый присоединенный маршрут. То есть если вы указываете только интерфейс, на котором этот маршрут будет доступен, то Cisco будет предполагать, что все узлы в этой сети доступны напрямую через интерфейс. Если мы говорим, например, про Ethernet, все узлы будут пытаться нащупаться протоколом ARP. Если вы указываете, что там это будет не broadcast, а point-to-point интерфейс, то просто весь трафик будет отправляться в этот интерфейс. Довольно опасная штука, потому что очень часто люди забывают написать IP-адрес шлюза и пишут, например, дефолтный маршрут, IP-road 0000, слоишь 0000, дальше указывают просто интерфейс, там, гигабит 00. И все, и больше ничего не делают. Это означает, что все IP-адреса в мире у вас как бы Cisco воспринимаются

как узлы в одном канале с вами. Соответственно, до них и до всех можно достать с помощью протокола ARP. Само по себе эта проблема как бы является очень сомнительной, ну, просто вы будете неоптимально себя вести. Но настоящая проблема будет формироваться тогда, когда у вас следующий NextHop, ну, или кто-то вообще в этой сети будет включать ProxyArp, потому что он тогда будет своим MAC-адресом отвечать на вообще все запросы, которые у него есть. Если у него есть дефолтный маршрут, он вам будет говорить 8-8-8-8, это я присылаю трафик мне. 9-9-9-9, прекрасно, это тоже я присылаю трафик мне. Вот до каждого IP-шника он будет вам присылать трафик. Присоединенный маршрут добавить можно практически в любом случае, там особых проверок нету, а вот если вы добавляете IP-шник NextHop, то используются дополнительные проверки. Этот IP-шник должен резолвиться в таблице маршрутизации. Ну, и если вы указываете присоединенный маршрут, не присоединенный маршрут, а и IP-шник, и интерфейс, через который будет доступен некоторый маршрут,

то тем самым вы часть проверок отключаете. Поэтому будьте осторожны, если вы указываете, где будет доступен шлюз, либо указываете интерфейс, если вы точно знаете, что действительно оттачат маршрут, то есть напрямую подключен, либо указываете IP-адрес шлюза. И то, и другое надо делать с осторожностью. То есть если вы указываете и интерфейс, и IP-шник, могут быть проблемы, если вы где-то ошибетесь. В некоторых случаях это будет полезно, в некоторых это будет скорее вредно. Вы можете добавить несколько маршрутов до одной и той же сети. Cisco позволяет это делать. В Cisco во всех роутерах есть механизм, который называется Cisco Express Forwarding. Это механизм аппаратного ускорения маршрутизации. То есть мы говорили, что классическая маршрутизация, она очень медленная, потому что там рекурсивные запросы, бла-бла-бла. В Cephe у вас все маршруты, когда в таблицу маршрутизации добавляются, они могут смотреть куда угодно. Но Cephe все эти маршруты резолвит и складывает себе в отдельную табличку. Поэтому у вас в таблице маршрутизации, условно, 100 тысяч маршрутов. И в табличке Cephe 100 тысяч пережеванных маршрутов.

Каждый пережеванный маршрут заключается в готовом интерфейсе, через который должен выходить трафик. То есть он уже все прорезолвил до присоединенного интерфейса. И он нашел канальный адрес соседа, куда надо отправлять трафик. То есть он взял, дошел до конкретного IP-шника NextHop, который действительно уже присоединенный, который хочет роутер использовать в качестве доставки трафика в удаленную сеть, и получил его канальный адрес. Так вот, если вы добавляете 2, 3, 10 маршрутов, они все могут добавиться в Cephe. И у вас до одной и той же сети Cephe будет трафик балансировать. Он это делать будет с использованием механизма, схожего с тем, который используется в Azure Channel. То есть если у нас трафик идет в сторону сети, до которой есть 2, 3, 4, 10 разных маршрутов с разными NextHop'ами, Cephe действительно будет направлять трафик до всех 10 NextHop'ов. Но при этом в сторону каждого конкретного NextHop'а трафик всегда будет укладываться так, что одно и то же приложение всегда пользуется

одним и тем же NextHop'ом. Не может быть такое, что вот мы берем и там пинкаем соседа, и трафик начинает ходить. Половина пингов в одну сторону, половина в другую. Так быть не должно. Но там есть, ну, с пингом, ладно, не очень хороший пример. Телнет. Взяли, открыли Телнет-сессию, вот ни в коем случае не будет такое, что Телнет половина пакетов отправляется в одну сторону, половина в другую. Если только вы не включаете первую пакет балансировки. Тогда вы механизм отключаете, и у вас циск превращается в глупый балансировщик, типа четный пакет налево, нечетный направо. Как правило, вызывает это проблема, поэтому это не рассказывается на CCNA, рассказывается только на CCI, даже не рассказывается, а как бы предполагается, что вы знаете это. И даже на лабах, вот когда вы сдаете лабу цисковскую, CCI-шную, там есть на это задание, типа включите балансировку, поломайте все, это самый пир-пакет балансировки, а потом почините. Ну, то есть то еще удовольствие. Поэтому пир-пакет балансировки не включаем, как вводные. Дальше. Если вы добавляете несколько маршрутов

до одной и той же сети, они все добавляются в CEF, то есть у вас CEF начинает балансировать потоки трафика на два разных NextHop, при этом старается, более-менее равномерно их загружается, насколько это возможно. Если вы добавили какой-то маршрут, а потом хотите исправить его, потому что поняли, что добавили его с ошибкой, добавляем новый правильный, старый при этом удаляем. То есть если вы просто добавите новый до такой же сети, старый при этом сам не удаляется, естественно. Если вы в EOS XR работаете, логика вся та же самая, но на CISC на обычный у нас новый маршрут создается одной строчкой в глобальном конфиге. Просто указываем там в EOS IP, роут, чего-то там. В EOS XR мы должны запустить контекст роутер статик. Это означает, что у нас появляется новый источник маршрутной информации, который будет вбрасывать маршруты в таблицу маршрутизации. То есть если вы не запускаете роутер статик, у вас как бы статических маршрутов в таблице маршрутизации

быть не может. CISC живет спокойно и у нее на один процесс как бы меньше. Если вы хотите добавлять статические маршруты, вы запускаете роутер статик, указываете, какие маршруты вы хотите добавлять, адрес family IPv4 Unicast. Мы увидим дальше, что практически все протоколы маршрутизации, которые мы будем в курсе изучать, они все будут так или иначе работать с разными адресными семействами, могут выбрасывать маршруты в таблицу маршрутизации опять же разных адресных семейств. Ну вот мы здесь делаем адрес family IPv4 Unicast, а дальше все то же самое, как в обычном EOS. Можно добавить несколько маршрутов до одной и той же сети в сторону разных NextHop. Если добавили два, один нормальный и один неправильный, то вот неправильный надо ручками удалить. Также, как и в случае с обычным EOS, чаще всего мы хотим добавлять маршруты до какого-то конкретного NextHop, и чаще всего мы не хотим указывать адрес интерфейса, через который это все будет доступно. И тогда синтаксис команды, которая будет это делать, будет иметь вид router static,

адрес family чего-то там Unicast, и IPшник, маска сети, и IPшник шлюза. Так. Если мы хотим работать с VRF'ами. VRF — это на самом деле концепция для вас, наверное, уже немножко новая по сравнению с тем, что мы проходили на CCNA, поэтому я должен буду про нее, соответственно, немножко рассказать. VRF — это отдельная таблица маршрутизации. У нас есть так называемая глобальная таблица маршрутизации, с которой мы работали на CCNA, и есть отдельные таблицы маршрутизации, которые никак не связаны с самой глобальной. То есть мы берем, можем разделить физический роутер на несколько логических маленьких виртуальных роутеров. И вот эти вот логические таблицы маршрутизации мы должны будем сначала создать перед тем, как их использовать, а потом отнести к ним какие-то интерфейсы для того, чтобы трафик, приходящий на этих интерфейсах, маршрутизировался именно по определенным таблицам маршрутизации. Создается VRF командой IPVRF и дальше название его. То есть каждому VRF'у мы можем дать название,

иногда дают название по цветам. Если мы говорим про все эти предприятия, там они обычно там Green, Yellow, в общем-то такое. Если вы работаете в какой-нибудь компании, которая может быть связана с какими-то проверками аудиторов или чего-то еще, то, может быть, вы захотите разнести разные, допустим, отделы по VRF'ам, и у вас будет отдельный отдел, там, не знаю, условно финансисты, отдельный отдел R&D, отдельно что-то еще, и вот каждый отдельный свой отдел крутится в своем отдельном VRF'е. То есть трафик разных отделов между собой в принципе теоретически ходить не может, потому что между ними как бы даже просто гипотетически нет маршрута. Так же, как в случае с Виланами. Между разными Виланами мы трафик не коммутируем. Вот то же самое с VRF'ами. У нас отдельно таблицы маршрутизации живут для каждой отдельной сущности. Нет, интерфейс не может при этом быть в двух разных VRF'ах. Если вдруг вы хотите принимать трафик,

который относится к двум разным VRF'ам, вам, так же, как и в случае с Виланами, надо будет его как-то промаркировать. В случае с Виланами мы маркируем трафик 802.1Q чаще всего. Но в принципе вы можете 802.1Q образом же маркировать трафик и в VRF. Если говорить про классический, скажем, вендор и независимый пример, когда у вас есть роутер. Давайте попробую прессовать роутер. У него есть физический интерфейс. И по этому интерфейсу приходят пакеты, соответственно, с VRF'ом, допустим, 1 и пакеты с VRF'ом 2, которые надо будет обрабатывать по разным таблицам маршрутизации. Вот и мы говорим, у нас 802.1Q заголовок здесь, допустим, первый, здесь второй Вилан мы используем. Ну, в этом случае мы можем поднять два субинтерфейса. Один смотрит в первый Вилан, и мы говорим на нем 802.1Q, соответственно, первый Вилан. На другом говорим 802.1Q, второй Вилан. И трафик мы просто обрабатываем, каждый субинтерфейс запихиваем в разные VRF'.

Если же мы используем именно цисковское железо, есть такая штука, которая называется EVN, Easy Virtual Network. Смысл тот же самый, что пакет у вас приходит с метками 802.1Q, но вы не плодите хреновую тучу субинтерфейсов, а вы говорите, что у вас номер 802.1Q заголовка, ну вот метка 802.1Q заголовка однозначно совпадает с номером VRF'. Вы VRF все промаркируете, указываете, что у вас в VRF и менеджмент, например, используется номер, там, не знаю, 10 или номер 1. В нашем случае вот один используется, значит, VRF номер 1. Рядом делаете IP VRF, не знаю, клиент, клиент, и указываете, что у него номер 2. И трафик, который приходит с меткой первого Вилана, он обрабатывается сразу по VRF менеджменту. Тот, который приходит с меткой второго Вилана, он обрабатывается по VRF другому. При этом у вас всего один интерфейс, на нем всего один айтишник.

Вы не плодите хреновую тучу субинтерфейсов. Эта штука чуть менее, скажем, хорошо читается по сравнению с тучей субинтерфейсов. И в некоторых случаях она при этом имеет право на существование, но я бы вам, наверное, пользоваться ей не рекомендовал. Вообще классический пример, когда у нас каждый интерфейс смотрит все-таки в отдельно свой отдельный VRF. В нашем случае мы видим, что мы создали VRF менеджмент, дальше включили интерфейс gigabit.00 и выполнили команду IP VRF forwarding management. Как только мы это сделали, у нас все IP пакеты, которые начинают приходить на MAC адрес этого интерфейса, они начинают обрабатываться по VRF менеджменту, по таблице менеджмента. Очень удобная штука, когда у вас используют так называемые out-of-band менеджмент сети. То есть у вас есть, не знаю, коммутатор, например, да, и у него есть какие-то интерфейсы, которые на морде висят, и эти интерфейсы на морде смотрят на пользователя. Это на одного пользователя, это на другого, на третьего, на четвертого, на пятого, на шестого, на седьмого.

И у вас эти интерфейсы, они объединяются в какие-то там VLAN, и мы говорим, вот это вот интерфейсы, которые смотрят на там, не знаю, как это, домашняя сеть, да, на один дом, на один подъезд это интерфейс, на другой подъезд это на третий. И еще есть один интерфейс, который вы выделяете под цели менеджмента. Просто он физически обособлен. Этот трафик не ходит через те же самые VLAN, через те же самые таблицы, по которым ходят обычные клиенты. Мы его выносим в менеджмент, и, соответственно, у него там все свое отдельное обособленное. В сетях предприятия эта штука просто даже физически часто смотрит прямо в отдельную сеть. То есть у вас есть отдельно свечи, через которые уходит трафик, допустим, серверов клиентов, и у них на морде есть одни порты, а рядышком есть еще отдельный менеджмент порт, и от него провод идет в прям совсем отдельную сеть. То есть это не в сторону оплинков идет, а в сторону какого-то отдельного менеджмент свеча, на котором сидят только там безопасники, например, или только айтишники. Ну вот такие вот штуки, они как бы бывают, часто используются, если мы говорим именно про такие вот

несложные примеры с VRF-ами. Очень такой характерный показательный пример — это менеджмент VRF. Вот. Мы указываем, что у нас интерфейс Gigabit 0 будет жить в VRF-е-менеджмент. Если вы используете эту команду, у вас автоматически с этого интерфейса счищаются все IP-адреса. То есть если у вас там был настроен IP-адрес какой-то, вот после выполнения команды IP-VRF-Farwarding Management, у вас айтишник с него стирается. Это мера безопасности для того, чтобы вы случайно не включили интерфейс с IP-адресом, который, вообще-то говоря, для этого VRF-а не предназначен. Поэтому отдельно после назначения VRF-а вы все равно должны переназначить IP-адреса. И вы, естественно, должны будете назначить их правильным образом. Если вы хотите добавить какой-то маршрут, например, маршрут по умолчанию в VRF-менеджменте очень часто бывает. Вот мы добавили IP-шник 10.0.0.2 по 24-й маске. Мы говорим, все остальные менеджмент-сети будут доступны через IP-шник 10.0.0.1.

Ну, например, вот такой, через отдельный выделенный коммутат, через, да, маршрутизатор, который подключается просто в отдельный выделенный out-of-band-менеджмент-пор. В этом случае мы добавляем IP-road, нашу привычную команду, VRF-менеджмент, новая концепция, которой у нас раньше не было. Раньше мы здесь ничего не писали. Сейчас добавляем VRF-менеджмент и добавляем IP-шник маску и шлюз. То же самое, в принципе, что и было. После чего, если мы хотим посмотреть содержимое таблицы маршрутизации менеджмент, мы указываем show.ip-road и дальше VRF-менеджмент. Видно, что здесь вот у нас есть маршрут по умолчанию, который мы добавили. При этом этот маршрут по умолчанию никоим образом не пересекается с таблицей глобальной. То есть в таблице глобальной у вас могут быть маршруты, в которых у вас там, например, пользователи сидят, и там трафик во всей сети в мире ходит через какие-то там системы безопасности, через что-нибудь еще. Ну, а вот менеджмент трафик, он ходит исключительно только через вашу внутреннюю специальную сеточку. То есть это прямой доступ в сеть управления.

Вот. Так вот как-то так. Ну, обычно, да, менеджмент VRF, он вот такой вот компактный есть. То есть там есть connect-types-ник и один дефолтный маршрут. А больше там ничего не нужно. Если хотите, можете что-нибудь еще подобавлять, но по большому счету незачем. В EOS XR концепция такая же. Вы должны создать VRF, вы должны отнести к этому VRF интерфейс, и вы, если захотите, должны будете создать статический маршрут, который смотрят во всей сети в мире. Немножечко по-другому создается VRF. То есть вы не просто указываете, что у вас будет VRF-менеджмент. Причем обратите внимание, в EOS обычно мы указываем IP VRF, а в EOS XR мы просто говорим VRF, и дальше внутри этого менеджмент VRF мы указываем, что есть адресное семейство, такие-сякие. И в настройке адресного семейства в VRF обязательно нужно указывать две сущности. Это экспорт road target и импорт road target. Мы сейчас с вами пока не трогаем, зачем они нужны, но просто их надо указать. Если вы не используете BGP с L3 VPN,

можете указать здесь любую совершенно фигню, которая вам понравится. Но никоим образом не будет влиять на вашу работу. Если же вы будете использовать L3 VPN, то здесь надо будет указывать правильную штуку. Ну да, там для управления маршрутами, когда у вас прибегают маршруты по BGP с указанием разных road target, вы можете в разные VRF и разные маршруты указывать, как они будут утекать. Для простого сценария, когда у вас просто роутер с EOS XR почему-то есть, а BGP с L3 VPN вы при этом почему-то не используете, вы должны здесь написать все равно, что хотите, то и пишетесь. Пример, то, что можно написать, вот такой вот. В принципе, можете взять образцовый показатель, это использовать, оно сойдет. Дальше, интерфейсы к VRF относятся, в общем, почти так же. Тоже указываем VRF Management, уже не IP VRF Forwarding, а просто VRF Management, и он относится к указанному VRF. Ну и здесь тоже IP V4 адрес, да, опечатался.

Привычка, знаете ли, страшная сила. Ну и если мы хотим добавить какие-то статические маршруты, в EOS обычно мы указываем IP Road VRF чего-то, здесь мы указываем роутер статик, VRF чего-то, и внутри VRF делаем адресное семейство. Ну, в общем, концепция примерно та же. Если мы хотим посмотреть таблицу маршрутизации, ну, я думаю, что вы уже догадываетесь, не ShowRoad IP V4, а ShowRoad VRF Management IP V4. В общем, все то же самое, как в обычном EOS, по большому счету, с некоторыми поправками. Если мы добавляем какие-то маршруты в таблицу маршрутизации, мы должны будем знать, что маршруты могут быть разные. То есть, во-первых, они могут быть до разных сетей, а во-вторых, они могут иметь разные происхождения. Очевидный способ произойти для маршрута – это быть присоединенным маршрутом, который вы добавляете по факту наличия IP-шника на интерфейсе. То есть, мы повесили IP-шник на интерфейс, такой маршрут называется connected,

и у него есть так называемое административное расстояние. Это административное расстояние 0. Если мы добавляем статический маршрут, неважно, удаленный какой-то, или connected, или присоединенный, у него по умолчанию административное расстояние будет 1. Вы можете переопределить это административное расстояние, вы можете сделать его больше, если хотите. То есть, никто вам не мешает добавить статический маршрут с административным расстоянием 20 или 50 или 100, но вы не можете его сделать меньше. То есть он единичка или больше. Если вы используете маршруты BGP-шные, то у BGP на самом деле несколько административных расстояний по умолчанию. Маршруты, которые вы получаете по EBGP, имеют административное расстояние 20. Маршруты, которые вы получаете по IBGP, будут иметь административное расстояние 200. EBGP будет иметь три разных административных расстояния. Маршруты, которые нативно взялись в EBGP, будут иметь административное расстояние 90. То есть если вы просто там командный network на интерфейсах включили EBGP,

вот он там порождает эти маршруты, и у них административное расстояние будет как раз такое 90. Можно переопределить, но по умолчанию вот так. Если вы используете редистрибуцию в EBGP, то внешние маршруты в EBGP будут иметь административное расстояние 170. То есть это то, что зародилось изначально не в самом EBGP, а прибежало откуда-то еще. И, наконец, RIP используется в административное расстояние 120 для всех маршрутов. RIP уже не различает там внутренне и внешне, для него просто кидаю кусок таблицы маршрутизации и все. OSPF 110, где он есть, да, 110. Можно гипотетически назначить разные административные расстояния по умолчанию для маршрутов LSEC первых, третьих или пятых. Но по умолчанию они все три одинаковые. Если вы будете использовать ASAS, у него административное расстояние 115, то есть лучше, чем RIP, но хуже, чем OSPF. И дальше из того, что еще надо будет знать...

Да, да, при HRP забыл. Если вы делаете суммарный маршрут, у HRP бывает административное расстояние 5. 254 – хорошо известное административное расстояние для DHCP маршрутов. То есть если вам по DHCP пришел какой-то маршрут, вы его вбрасываете в таблицу маршрутизации, например, дефолтный. В этом случае у вас они показываются как то, что этот маршрут статический, но административное расстояние у него будет совсем маленькое – 254. И если вдруг у вас есть несколько маршрутов, которые приходят до одной и той же сети, но из разных источников, то сравнивается как раз их административное расстояние. Какой маршрут стоит предпочесть? Вот чем меньше административное расстояние, тем лучше. То есть если к вам приходит маршрут из BGP с одной стороны по EBGP, подчеркну EBGP, и с другой стороны по OSPF, то в этом случае вы не думайте. У нас одна и та же сетка 10.000 по 24 маске, но вы смотрите, у SPF административное расстояние 110,

у EBGP административное расстояние 20, следовательно маршрут до сетки 10.000 мы будем указывать всегда в сторону BGP. То есть мы смотрим, что маршруты прибегают до одной и той же сети, и из всех маршрутов, прибежавших до одной и той же сети, мы выбираем те, у которых административное расстояние меньше. При этом в таблицу маршрутизации будут попытаться попасть только те маршруты, которые конкретный протокол посчитал лучшими. То есть то, что у BGP при этом может быть несколько разных вариантов, как добраться до этой же самой сети, то есть может быть гипотетически, что у нас еще есть какой-то третий роутер, который по BGP говорит, я тоже знаю, как добраться. Ну, например, он говорит, этот маршрут у нас тоже будет EBGP, но у него, не знаю, айспаз длиннее. Вот айспаз, у него какой-нибудь длинный-длинный. Вот такой вот длинный айспаз. В этом случае мы говорим, что у нас EBGP сначала выбирает самый выгодный маршрут. У него есть вариант отсюда или отсюда посмотреть,

куда трафик должен уходить по BGP. Он говорит, в этом случае я сначала из двух BGP маршрутов выбираю один лучший, который приходит от вот этого вот соседа. Дальше я пытаюсь его вбросить в таблицу маршрутизации, только в этот момент он будет драться с OSPF. То есть отдельно Best Path Selection в самом BGP, отдельно какой маршрут вставить в таблицу маршрутизации. Это два разных процесса, многих почему-то пытаются смешивать. Если у вас есть два маршрута, полученных из одного и того же источника, то вы должны будете все равно пытаться сравнить их, какой из них следует предпочесть. В принципе, вы можете в CEF поставить оба. То есть никто вам не запрещает это делать. Но все-таки Cisco по умолчанию старается выбрать, если есть два маршрута, которые получены из одного и того же источника, она старается выбрать один, который ей будет больше нравиться. Ну и, соответственно, в таблицу маршрутизации чаще всего, что BGP, что OSPF, что EGRP, ставят все-таки один маршрут.

Ну или, по крайней мере, там OSPF и EGRP могут сознательно вставить несколько с одинаковой метрикой. В принципе, они могут поставить маршруты и с разными метриками. И могут при этом дополнительно, кроме самой метрики, которая просто число безразмерное, указать также и параметр TrafficShare. TrafficShare — это у нас доля трафика, который должен получить конкретный NextHop при отправке по нему данных. Смысл заключается в том, что если у нас есть один роутер, и у него есть два NextHop1 и NextHop2. И, соответственно, у нас есть два маршрута, которые можно использовать для того, чтобы доставить трафик в сеть 10.000. Вот мы, соответственно, говорим, у нас вариант есть «пойти сюда» и «пойти сюда». Но мы почему-то знаем, что вот этот вот NextHop, он жирный, на него можно поставить трафика больше, чем на нижний, которые маленькие и сладенькие. В этом случае мы говорим, сюда TrafficShare будет 2, сюда TrafficShare будет 1. Выглядеть это будет, скорее всего, как то, что у вас не просто 2 к 1 будет распределение трафика,

у вас еще это будет параллельно сопровождаться различием в метриках. Соответственно, у вас отдельно здесь будет метрика, метрик, ну, например, 1, а здесь у вас будет метрика 2. Метрик 2. Это не обязательно связанное между собой понятие. То есть вы можете добавить 2 маршрута с одинаковыми метриками, но TrafficShare поставить им, соответственно, разный. Вы можете поставить 2 маршрута с разными метриками, TrafficShare поставить одинаковый. Оба параметра в таблицу маршрутизации добавляются на этапе вброса маршрута в таблицу. Но чаще всего они добавляются таким образом, что производение вот этих параметров равно произведению вот этих вот параметров. То есть что метрики относятся друг к другу обратно пропорционально тому, как относится друг к другу трафик-шер до одной и той же сети. Дальше происходит следующее. Сам цеф, он на роутере имеет некоторое количество так называемых бакетов.

То есть у вас есть такие ведерки, которые вы можете использовать для того, чтобы отправлять трафик до одного и того же префикса. То есть у вас фактически идет указатель, что в таблице цефа есть префикс, который указывает на то, что есть некие бакеты, которые можно использовать, трафик через них. Каждый бакет будет указывать на какой-то конкретный next hop. Но, соответственно, может быть такое, что у нас есть бакеты 1, 2, 3. Давайте три бакета сделаю, вот этого нет бакета. И, соответственно, next hop 1 и next hop 2. И мы эти три бакета распределяем по next hop следующим образом, что первый и второй бакеты указывают на next hop 1, а третий бакет указывают на next hop 2. Балансировка на самом деле идет между бакетами. И каждый бакет получает равное количество трафика. Если мы хотим сказать, что у нас трафик next hop 1 и 2 должен относиться в пропорции 2 к 1, в этом случае мы как раз указываем, что у нас два бакета смотрят на next hop 1, третий бакет смотрит на next hop 2.

Балансировка будет как раз 2 к 1. Этих бакетов на каждый префикс может быть ограниченное количество. То есть их в зависимости от конкретной железки может быть либо 16, либо 32, ну, либо, если мы говорим про IPv6, их может быть 64. 64 ведерка на каждый префикс вы можете создать. Вы не можете разбалансировать трафик таким образом, чтобы у вас общее количество бакетов, требуемых для балансировки, превышало бы вот такое вот число. Если говорить про экзамены, то вам рассказывают про то, что вот этих бакетов там 16. В реальности все современные CSs'ки используют 32 бакета. И поэтому, ну, если, допустим, предположить, что вы имеете делать какую-то старую платформу, где бакетов 16, вы разбалансировать трафик можете в пропорции, например, 9 к 7. Вы можете разбалансировать трафик как 15 к 1. Вы можете разбалансировать трафик как 13 к 1. То есть вы задействуете 14 бакетов и 16 возможных. Вы можете разбалансировать трафик как 8 к 7, 15 бакетов задействуете, 1 свободный. Но вот вы не можете сделать, допустим, балансировку 17 к 1. Это потребует 18 бакетов, у вас столько просто нет.

Поэтому часто можно будет указать, что вы видите, что, например, EJRP у вас сбрасывает два маршрута с разными метриками, и он пытается разбалансировать трафик в обратной пропорции к этим меткам, и он как раз указывает какой-то трафик-шер, который он хочет получить. Трафик-шер, который он хочет получить, может быть какой-нибудь очень кривой. 213 к 975. Но по факту в бакетах у вас никогда не получится такой балансировки. Если вы запросите, не знаю, 911 к 301, вот такую балансировку, он скажет, ну это примерно то же самое, что 3 к 1. То есть вот здесь и вот здесь, если взять, поделить одно на другое, это все равно то же самое, что 3 к 1. Почему? Вот такую балансировку я сделать не могу, тем более все равно там по факту трафик балансируется не по пакетно, а по потокам. И все равно на самом деле балансировка там будет как получится. Может быть такое, что один поток возьмет и весь интерфейс в 100% нагрузку уложит, а все остальные будут сидеть и ничего не делать.

Поэтому по факту он скажет, я буду на самом деле использовать 3 бакета для одного NextHop и один бакет для другого NextHop. NextHop у вас в случае с CEF будут уже готовы и пережеваны, то есть они будут на самом деле фактически выглядеть как указание, на какой интерфейс трафик посылаем и с каким канальным заголовком мы посылаем трафик. Если мы используем IPv4, то мы чаще всего в таблице маршрутизации указываем какой-то IPшник NextHop, который реализовывается протоколом ARP в канальный адрес и который прекрасно влезает в канальный заголовок, который CEF уже на готове держит. Если говорить про IPv6, то мы в таблице маршрутизации чаще всего либо указываем маршрутизируемый адрес, либо указываем link-local адрес. В любом случае с помощью Neighbor Discovery из всего этого дела получается канальный заголовок, ну, например, MAC-адрес, да, у нас резолвится, что из маршрутизируемого, что из не маршрутизируемого адреса. И в таблице CEF, который будет по факту использоваться для маршрутизации, используется только MAC-адрес. Поэтому не надо удивляться тому, что в IPv6 у нас NextHop и link-local адреса. Это никаким образом ни на что не влияет.

Все равно для маршрутизации они не используются. Для маршрутизации используются MAC. Если говорить про то, чтобы хранить маршруты до всех сетей в мире, то это было бы, прямо, откровенно говоря, неудобно. Сетей слишком много, поэтому чаще всего все маршруты, которые у нас смотрят на весь остальной мир, мы их складываем в один большой мегамаршрут, как восьминулевка. 0,0,0,0 по нулевой маске. Ну, или два двойточия, если лишь 0 по нулевой маске. В классовой маршрутизации эта штука не существовала, потому что нельзя было указать маску, и такого явления, как сеть 0,0,0,0 просто не было. Но в бесклассовом мире у нас это вполне все работает. Если говорить про CF, команды для работы с CF плюс-минус километр одинаковые. То есть, show ip-road у нас в IPv4, show ipv6-road в IPv6 на CISC-ах обычных. Если мы говорим про роутеры EOS XR, show ipv4, show road ipv4.

Если говорить про CF, на самом деле вот такую команду роутер XR тоже сожрет. То есть, я говорил, да, что у нас есть макросы, которые на самом деле в XR-ах присутствуют. Если вы по привычке набираете EOS-овскую команду, вот он подобную вот попытается сожрать. Ну, если что, show cf там чаще всего. Show cf, адрес family IPv4, show cf, адрес family IPv6 покажет вам по каждому маршру, префиксу, который вас интересует, какие next hop, какие bucket и так далее там присутствуют. В любом случае, сами префиксы будут указывать на так называемые adjacency, на next hop. И если вы хотите посмотреть детали конкретно в adjacency, то show adjacency та же самая команда по большому счету в XR-ах и будет. На экзамене этого ни в коем случае не будет. Это я вам рассказываю просто для того, чтобы вы понимали, как устроен аппаратный ускоритель в EOS-ах и в EOS XR. То есть показано вот здесь у нас, что у нас таблица маршрутизации.

Есть некая сетка 192.168.4.0, которая статическим маршрутом указана, что доступна через 192.168.3.0. А эту сетку притащил BGP, и BGP сказал, что next hop для нее будет 192.168.2.1. А этот IPшник доступен по OSPF и через соседа 192.168.1.1. А этот IPшник доступен через интерфейс, в который мы смотрим напрямую 192.168.1.2 адресом. То есть вот эта вот рекурсия, если бы мы по-честному все делали, она бы занимала довольно много времени для резолвинга. Ну ладно, четыре маршрута несложно перебрать, но представьте себе, что у нас роутер со всей картины интернета, в которой там 800 тысяч маршрутов, плюс еще на нем какие-то клиентские маршруты, которые, может, перебирать не надо, но все равно они место жрут. Вот перебирать все это дело, это было бы просто тупо дорого. Дорого по времени для каждого пакета. Цепт говорит, у нас вот этот вот адрес 192.168.4.0 соответствует сети 192.168.4.0 по 24 маске. Мы о ее существовании знаем, потому что ее кто-то добавил в таблицу маршрутизации.

Но когда он ее добавил, роутер автоматически пробежал по всем вот этим вот рекурсиям и сказал, у нас connected адрес уже найден. То есть мы уже указываем, что трафик должен идти через 192.168.1.1.1. Вот этот вот. И, соответственно, next hop у нас 192.168.1.1. Он по факту в тот момент, когда маршрут добавляется, не сразу резолвится. Резолвится в MAC адрес, он тогда, когда нужно будет отправить трафик первый раз по этому маршруту. В нашем случае, учитывая, что там OSPF, скорее всего, у нас уже все зарезолвлено, потому что если OSPF работает, то взаимодействие с этим соседом, 112.168.1.1, уже идет. И в CRP там уже давно отправлено. Ну вот у нас можно посмотреть, что showadjacency, 112.168.1.1, покажет нам уже готовый канальный заголовок, который используется для отправки данных этому соседу. 0000C 026BC6 – это MAC адрес получателя. 0000C 0357 4D – это MAC адрес источника.

0800 – это EtherType, который мы используем для отправки IP-пакетов. У нас уже готовый канальный заголовок, который можно использовать при отправке данных в сторону IP-шника 112.168.4.1. Если мы хотим на вот такой вот адрес отправлять данные, оборачиваем его вот таким вот байтами, заголовка канального, и отправляем на интерфейс Gigabit 0.0. Просто в среду. Все готово. Все очень быстро. Эту штуку придумала Cisco. Называла ее Cisco Express Forwarding. На самом деле у многих эндеров есть что-то очень похожее. Так. Если мы говорим про динамическую маршрутизацию, давайте рамочно пробежимся по RIP и EGRP, и потом их попробуем включить. Ну, давайте начнем с RIP. Мы включаем динамическую маршрутизацию, мы включаем роутер RIP, и дальше заставляем RIP подружиться по каким-то конкретным интерфейсам, обменяться таблицами, своими таблицами топологии. RIP имеет административное расстояние 120,

работает крайне тупо, по умолчанию рассылает сообщение по таймеру раз в 30 секунд. Таймер можно настроить, но, в принципе, незачем. Лучше от RIP полностью отказаться. И по умолчанию в EOS работает режим совместимости с RIP первой версии. RIP первой версии классовый. Поэтому, если мы работаем с EOS, то надо его обязательно переводить в режим полноценной второй версии и выключать включенную по умолчанию автоматическую агрегацию на границе классовых сетей, которые у него там есть, опять же, для совместимости с роутерами, которые, возможно, работают в RIP первой версии. Включение RIP на EOS обычно происходит крайне тупо. Вы используете команду Network, которая никакого отношения к нетворкам, собственно говоря, не имеет. Эта команда имела когда-то в очень далеких временах смысл. Она обозначала действительно Network, то есть вы указывали классовую сеть, в которую у вас смотрел ровно один классовый интерфейс, на котором надо было включить RIP. Вы на этом интерфейсе начинали отправлять анонсы RIP и Connected сетку, на нем ту самую классовую сеть,

которую вы указывали, добавляли в таблицу топологии RIP. В бесклассовом мире эта команда потеряла свой смысл, который крылся за ее названием. То есть когда мы указываем в RIP команду Network, эта команда не обозначает ничего, связанного с нетворками. Она ничего про префиксы нам не рассказывает. Если мы указываем Network чего-нибудь, мы указываем IP-шник классовой сети. То есть если вы даже попытаетесь указать бесклассовый IP-шник, она вам все равно по факту изменит его на классовый. Все IP-адреса на интерфейсах у вас начинают перебираться, и система находит те интерфейсы, на которых IP-шники попадают в указанную классовую сеть. То есть вот, например, у нас есть роутер, на нем есть гигабитный интерфейс, с SOS 2.16.1.1 по 24-й маске интерфейсом, и три интерфейса виланных, ну, не знаю, здесь, это Switch, и у него три интерфейса с IP-шниками 10.0.1.1, 2.1.3.1.

Мы используем команду 10.0.0.0 в Network 10.0.0.0. Это классовая сеть десятка. Система перебирает все IP-шники, говорит, этот не в десятке, этот в десятке, этот в десятке, этот в десятке. Следовательно, на этих трех интерфейсах RIP включается. На этом интерфейсе RIP эта команда не включает. Когда мы используем Network, и система обнаруживает, что на каком-то физическом интерфейсе IP-шник попадает в указанную классовую сеть, система на этом интерфейсе, во-первых, начинает отсылать анонс RIP, во-вторых, начинает принимать анонс RIP, и в-третьих, она добавляет connected сетки с этих интерфейсов в таблице топологии. То есть в таблице топологии окажутся вот эти вот сети 10.1.0, 10.0.1.0, 10.0.2.0, 10.0.3.0 по 24-м маскам. Мы использовали одну команду Network, и у нас добавилось 3 сети с совершенно другими префиксами, не теми, которые мы указали. То есть обратите внимание, вот это вот слово Network, оно ничего уже давным-давно не обозначает.

Это просто слово. На его месте могло быть слово Aqualang. Мы бы указывали Aqualang 10.0.0.0. Это обозначало ровно то же самое. То есть ничего в смысле эта штука не потеряла бы. Это просто надо запомнить, что когда-то давным-давно эта штука имела смысл, как именно Network, а сегодня это уже не имеет смысла. Это очень давний рудимент в Cisco IOS. Нам будет нужно не просто включить на вот этих вот интерфейсах RIP, но и на интерфейсе, в котором мы дружим с соседом, чтобы у нас вот здесь прореплицировались таблицы. Наполнение этой таблицы мы уже сделали. То есть ту сетку, про которую мы хотим рассказать соседям, мы уже создали. Ну, дальше осталось подружиться с соседями. Опять же, смотрим, какой у нас IP-шник. 172.16.1.1.1. по 24-й маске. Это IP-шник из классовой сети 172.16.0.0. Поэтому мы указываем Network 172.16.0.0. Еще раз подчеркну. Вот это классовая сеть. Вот этот IP-шник без классовой. Маршруты, которыми мы будем обмениваться, без классовой. Но указываем мы классовую сеть.

Если вы скажете, давайте я укажу здесь 172.16.1.1, система это примет. Но знаете, что она сделает? Она скажет, ты тут самый хитрый, да? Я тебе выполню командой 172.16.0.0. И вы не можете сказать, что не надо мне включать RIP на другом интерфейсе, на котором у вас IP-шник там 172.16.2.2. Вот она принудительно вам все равно там RIP включит. Вы не можете от этого отказаться. Если вы хотите сказать, что на некоторых интерфейсах, вот, например, как на клиентских вот этих вот VLAN-ах, которые у нас на предыдущем слайде были, мы, конечно, хотели включить Connected Setky в анонс, но мы не хотели туда отправлять анонсы, вы можете включить команду Passive Interface, которая перестанет отправлять анонсы в эти сети. Но она при этом в случае с RIP-ом по-прежнему не запретит принимать анонсы. То есть, если вам соседи захотят прислать какие-то анонсы, она никаким образом этому не препятствует. Опять же, надо просто запомнить, что в циске вот такое вот поведение есть. Если вы хотите блокировать прием RIP-овских анонсов

на интерфейсе, который у вас смотрит на клиентов, блокируйте на этом интерфейсе RIP с помощью аксесс-листа. То есть, указывайте, что 520-й порт UDP-шный блокируется на адреса самого роутера. Дальше. Если у вас много интерфейсов, которые на клиентов смотрят, и вы указываете в этом случае Passive Interface Default и No Passive Interface, которые действительно должны позволять устанавливать соседство. Если говорить про EOS, у него по умолчанию работает режим совместимости первой версии, и он отправляет анонсы в пакетах первой версии, которые классовые. То есть, это не то, что вы хотите. Поэтому для работы с EOS вы должны будете переключить его в режим второй версии, то есть, не отправлять анонсы первой. И вы должны будете выключить штуку, которая, опять же, на роутерах с EOS работает по умолчанию, команда AutoSummary. То есть, вы должны будете вручную выполнить ее, выполнить новый AutoSummary.

Команда мерзкая и гадкая, потому что она используется для совместимости с старыми роутерами. Если у вас используется так называемый Discontingent Classful Network, когда у вас есть вот здесь кусочек классовой сети и вот здесь кусочек классовой сети 172.16, а вот здесь какая-то другая сеть классовая. То есть, здесь 172.16.00, здесь 172.16.00, а здесь вот 10.000. То есть, действительно, у нас 172.16 сетка разорвана. В классовом мире такого быть не могло, но мы-то работаем и без классовом мире, поэтому, как бы, в нашем мире это может случиться. Вот если CIS-овский роутер включить в конфигурации по умолчанию в такой сети, произойдет следующее. Этот роутер скажет, у меня слева одна классовая сеть, справа другая классовая сеть. Я беру 172.16.1.0 по 2.4 маски сетку и перекладываю в анонсах в другую классовую сеть, но я при этом говорю, что у меня вся целиком 172.16.00 сетка присутствует. Поскольку это анонсы RIP по второй версии, он рассказывает

про маску, которая там используется, но он рассказывает про классовую маску. То же самое делает второй роутер. Он говорит, у меня вот здесь одна классовая сеть, здесь другая классовая сеть. Я перекладываю сеть 172.16.0.0 по 16 маске, как бы, автоматически суммирую вот эту вот классовую сеть, это без классовую сеть, доклассовую. И получается, какой-то роутер, который может принимать такие анонсы, он принимает 172.16.00 с одной стороны, 172.16.00 с другой стороны. Что он сделает? Правильно скажет, окей, я буду балансировать трафик. Часть трафика пойдет налево, часть направо. Выключается эта команда noAutoSummary. В этом случае при даже нахождении на границе классовых сетей роутер будет без каких-либо проблем отправлять анонсы по-честному. То есть просто надо запомнить, что если вдруг зачем-то вы там, не знаю, ударились головой и включаете RIP на IOS, переводим его в режим второй версии и отключаем AutoSummary. На оборудовании других вендоров такого может не быть.

Как проверить, что RIP у вас завелся? ShowIP Protocols покажет нам все источники маршрутной информации, которые зарегистрированы в системе, откуда они могут вбрасывать маршруты в RIP. Вам покажется, как часто отправляются апдейты на интерфейсах, покажется, что вы отправляете пакеты второй версии, принимаете пакеты второй версии, но если вы указываете версию 2, это так и есть. Покажутся интерфейсы, на которых у вас RIP включился, покажутся команды Network, которые вы вбили, то есть вот это вот Routing for Networks никакого отношения к Routing for Networks не имеет. Это не про Routing и не про Networks. Это про то, какие вы команды с названием Network вбили в конфиге. Здесь могло бы быть написано вместо Routing for Networks Diving with Aqualang. Никаких проблем. То есть это все равно никакого отношения ни к маршрутизации, ни к Networks не имеет. Погружение с Aqualang для 10.0.0.0, то есть это 192.168.1.0. Вот это вот, это какие команды Networks мы вбили. Вот это вот,

это кто у нас NextHop. Вот NextHop. То есть у нас 192.168.1.2 присылает нам какие-то маршруты, мы их добавляем в таблицу маршрутизации. Административное состояние для таких маршрутов по умолчанию 120. Те маршруты, которые от RIP к нам прибежали в таблицу маршрутизации, имеют административное расстояние 120. Здесь на слайде очевидная ошибка. И у них буковка R показывает, что это маршруты RIP-овские. В квадратных скобках первое число будет обозначать административное расстояние, второе число метрику RIP-а. Если мы работаем с IPv6, в общем, все то же самое, только команды Network нету, так что все надо включать вручную на интерфейсах. Интерфейс будет включаться в RIP с помощью команды IPv6, RIP, дальше название экземпляра RIP-а, enable. Название экземпляра RIP-а это то, чего мы не делаем в RIP-е для IPv4, но мы делаем это в RIP-е для IPv6. То есть у нас контекст роутера запускается

IPv6, роутер, RIP, и дальше название экземпляра. Все настройки, остальные остаются такие же. Если мы запустили RIP IPv6, то указываем, опять же, те же самые команды для диагностики. showIPv6 protocols покажет, какие у нас экземпляры RIP-а созданы. Вот здесь у нас есть RIP-сиси, и есть команда showIPv6 RIP, которая покажет чуть больше диагностики про сам процесс RIP-а, и покажет маршруты showIPv6 roadrip, маршруты RIP-овские, указывается административное расстояние 120, метрика, ну, в нашем случае двойка, и маршруты ставятся на link-local адрес соседа, на тот адрес, из-под которого приходят аннонсы. Если мы хотим перекладывать в RIP какие-то внешние маршруты, например, статические, у нас роутер есть, у него есть часть маршрутов статических, они не обязательно смотрят в сторону этого интерфейса, они просто взялись из статики, мы указываем, что у нас есть какой-то статический маршрут.

И у нас есть несколько роутеров, которые связаны по RIP между собой. И мы хотим, чтобы маршруты RIP оказались во внешнем маршрутном источнике, например, не знаю, у нас вместо статика может быть BGP, к примеру, да? Вот, мы хотим сказать, что маршруты, которые по RIP нам известны на этом роутере, мы перекладываем в BGP. У нас порождается BGP-шный маршрут, а те маршруты, которые мы по BGP хотим показать в RIP, мы перекладываем из BGP в RIP. В этом случае роутер, который будет заниматься такой редистрибуцией, роутер на границе автономной системы RIP, он будет вбрасывать маршруты, как будто бы он получил этот маршрут из таблицы маршрутизации, он по факту получил это. То есть, мы действительно взяли маршрут из таблицы маршрутизации и переложили его в RIP. Ну и при этом мы должны будем какую-то стартовую метрику задать. Если вы не зададите стартовую метрику, маршруты будут иметь административное расстояние, метрику 16, то есть бесконечность. Ну, вы указываете, допустим, команда redistribute, какие маршруты вы указываете, и redistribute дальше можете указать дополнительно.

Не просто, что вы их вкладываете, а вы указываете их с некой метрика. Вот, например, redistribute static, метрик 1. Так, если вы работаете с IPv4 маршрутами, то для вас будут доступны connected маршруты, BGP, EGRP, OSPF, второй, третьей версии, потому что третья версия гипотетически может работать с IPv4 маршрутами или ISIS. Все эти протоколы таскают маршруты IPv4, и их можно положить в RIP. Из одного RIPа вы в другой RIP положить маршруты не можете, потому что RIP на устройстве Cisco может быть только один. Если работаем с EOS XR, то ситуация будет похожа, то есть, если мы запускаем роутер RIP, мы просто указываем роутер RIP и указываем, что нас интересуют какие-то интерфейсы в этом RIP. Команды Network больше нету, поэтому мы должны будем все интерфейсы просто перечислить в явном виде. Указываем интерфейс такой, интерфейс

SQL, пятый, десятый. Если хотим пассивный интерфейс создать, ну тоже passive interface, либо default, либо указываем в явном виде. если хотим редистрибуцию делать, редистрибьют и дальше вот показано, откуда может XR взять маршруты для RIP. Может взять connected маршруты, статики, BGP-шные, OSPF, ASIS, EGRP. Обратите внимание на то, что OSPF V3 RIP не может взять в качестве источника, потому что EOS XR не поддерживает адресное семейство IPV4 для OSPF V3. Если хотим продиагностировать наш RIP, то showRip и дальше showRip database покажут маршруты RIP-овские, showRip interface, showRip statistics, ну в общем там есть какие-то команды, которые можно все это дело продиагностировать. Давайте подключаться к нашим устройствам и пытаться настроить RIP таким образом, чтобы у нас отложились команды по настройке RIP на наших

так скажем пальчиках. Так, вот я подключился к своим железкам. Начнем мы с роутера Cisco EOS XR. Я сильно подозреваю, что у меня на нем конфигурация сброшена вся, да, судя по названию EOS, поэтому я сейчас буду настраивать его практически с нуля. В принципе, вы тоже можете это сделать, то есть если у вас сейчас конфигурация почему-то не такая, как, как сказать, не пустая, вы можете ее сбросить и перенастроить все заново для того, чтобы у вас команда по настройке роутера EOS XR отложилась. На экзамене будет много вопросов по настройку XR. Я верю, что IP-шники на EOS обычно вы настраивать умеете, но вот на XR, если вдруг вы не работаете с этим каждый день, то лучше просто, чтобы эта команда у вас отложилась. ConvT, вот, например, я по привычке работаю с EOS-овской терминологией обычного. ConvT, конфигура терминал. Здесь терминал не нужен, здесь просто конфигура обычный. Хост

name роутер. Мне больше нравится, когда у меня железка называется роутер. Затем интерфейс gigabit 0000. Я его включаю на шатдаун. И затем вешаю на него IP-шник. IP-адрес, ну, допустим, 10.002 слэш 24. Я сейчас ввожу эту команду, видите, она сожралась. Но на самом деле надо правильно вводить IPv4-адрес. То есть show configuration. Мне покажут сейчас, что я сделал. Вот IPv4-адрес надо вводить по-хорошему. Просто, опять же, мой опыт работы с циской, с обычной, уже превосходит мои возможности по введению команд правильным образом. По-хорошему я должен был бы, конечно, сейчас сказать IPv4-адрес вот такой вот. Commit. Проверяем,

что система это сожрала. Интерфейс включается, пробегают сообщения о том, что все хорошо. И, соответственно, мы можем приступать к настройке другого интерфейса, который нам сейчас понадобится. Это интерфейс loopback. Мы указываем интерфейс loopback 0 и на нем вешаем IPшник какой-нибудь, не знаю, IPv4, я на этот раз смог, адрес 10, не знаю, пусть это будет второй роутер 10.222. 222. 32. Интерфейс как интерфейс просто совершенно произвольный. Какие хотите IPшники навешивайте, такие навешивайте, то есть вы, если делаете это самостоятельно, лабу, можете использовать такие же адреса, как я использую, можете свои собственные придумывать на лету. Наша задача сейчас сделать так, чтобы роутеры между собой взаимодействовали, лабораторные комплекты сейчас у всех обособлены, то есть вы по адресам между комплектами не пересекаетесь, поэтому какие хотите, такие делайте. На более старших курсах мы будем устраивать

взаимодействие между разными комплектами и там, конечно же, нужно будет корректно настраивать IP-адресацию, чтобы вы своими адресами не налезли на другие комплекты. А сейчас мы никоим образом не завязаны друг на друга, можете использовать какие угодно IP-адреса, прям реально какие угодно. Хотите использовать 1.1.1.1.2.2.2.2.3.3.3.3.3. Ну, главное, что я верю в вас, что вы знаете, как работает IP-адресация вообще в принципе, ни о сомнении, в этом нет. Просто сделаем так, чтобы сейчас наши два роутера подружились между собой по рипу и отдали друг другу IP-шники вот этих самых лумбэков. Ну, не самая, казалось бы, задача, что если вдруг вы там курс по роутингу прослушивали, то вы это делать умеете на iOS с завязанными глазами одной левой пяткой. Ну, на iOS XR все-таки мы этого пока не делали, поэтому сейчас будем делать. IP-шник повесили на интерфейс, можем закоммититься на всякий пожарный случай. И дальше приступаем к настройке роутера IP.

Роутер, рип, никакие специальные названия экземпляров не нужны, то есть просто говорим, что роутер, рип и все. Если вдруг что, здесь есть справка, которая покажет вам, что можно будет сделать, обратите внимание на то, что нету такого контекста, как адресное семейство. Рип второй версии работает, соответственно, только с IPv4. Вы можете включить режим совместимости с первой версией, но в iOS XR по умолчанию этого не нужно. То есть в XR по умолчанию у вас все работает в второй версии. Если вдруг вы захотите использовать рип.ng, то здесь есть нюанс, что так, exit, заключается в очевиднейшем моменте, то есть здесь просто нету контекста рип.ng. Рип.ng не поддерживает сейс.xr. Ну, да, роутер рип, и дальше здесь

мы можем сделать какие-то вещи. Мы можем включить или не включать автосуммирование. По умолчанию оно выключено, то есть это на iOS обычном оно включено, по умолчанию на iOS XR оно выключено. Его можно включить, если нам зачем-то это нужно. Но это нужно, если у нас роутер смотрит на какую-то железку, которая работает в классовом режиме. Я сомневаюсь, что вы сегодня будете включать рип для того, что если вы вдруг будете включать рип, что вы делаете для того, чтобы поддерживать классовую железку. Скорее всего, типичный use case для операторов, вы включаете рип для контроля какого-то другого устройства, которое ничего кроме рипа не умеет. Оно будет бесклассовое, но оно будет соответственно просто поддерживать только рип. Очень типичная ситуация для каких-то кастомных устройств, которые под нужды провайдеров делаются, и просто производителю лень делать там какой-то полноценный процесс динамической маршрутизации, он говорит, я тебе включу рип, вот дальше с этой железкой делаю, что хочешь. Обратите внимание на то, что команды network здесь нету,

то есть если мы хотим включить рип на каком-то интерфейсе, мы используем здесь в настройке router rip команду interface и указываем gigabit 0000 наш интерфейс, на котором мы должны будем работать. В настройке интерфейса можно будет какие-то свои отдельные указания дать, например, там включить split horizon, выключить split horizon, включить poison reverse, здесь же можно сказать, что интерфейс будет пассивный, то есть если вдруг нам это зачем-то нужно, вот мы можем сказать passive interface. Но я предпочитаю это сделать на интерфейсе loopback. Сейчас приглашение ковода не изменилось, но я нахожусь уже в другом контексте. Кстати, забавная штука, я про нее вам не рассказывал, но вы в EOS обычном не можете посмотреть, как расшифровывается вот этот конфиг rip if, в каком субконтексте настройки роутера rip и вы находитесь. В EOS XR есть полезная штука в PVD, которая покажет, что вы сейчас находитесь в настройке именно роутер rip интерфейса loopback 0. Полезно, опять же, в какой-то степени слизано с

Juniper, но да, в нашем случае мы наглядно видим, где мы находимся. И вот здесь вот я хочу сказать, что этот интерфейс по себе интерфейс указываю, что он пассивный и в принципе я заодно включил его в сам контекст rip. Выхожу, commit, очень хочется по-джоновски набрать commit and quit, но не получается. Так, и соответственно end. Вот сейчас у меня роутер rip завелся, сейчас я, если захочу, могу посмотреть show rip, он мне покажет, что rip у меня есть, rip работает, rip работает в режиме второй версии, дефолтная метрика не настроена, в том смысле, что если я захочу вбросить в rip какие-то маршруты, мне нужно будет в явном виде seed метрик ему задать стартовую метрику, потому что иначе он будет анонсировать метрику 16.

Автоматическое суммирование выключено, использование бродкаста для ripа второй версии выключено, по умолчанию вторая версия использует мультикаст, максимум пасс это сколько rip будет добавлять маршрутов в таблицу маршрутизации, но в CEF сколько бакетов, не сколько бакетов, а сколько маршрутов именно будет использовать, ну и таймеры, в общем, стандартные таймеры риповские, 30 секунд hello time, как часто отправляем апдейты, 180 секунд, через сколько секунд после получения апдейта rip заподозрит, что кажется с маршрутом что-то не то, и через сколько секунд после получения апдейта маршрут будет сфлажен, то есть, если вдруг у нас пришел какой-то апдейт, и потом сосед молчит, не посылает нам новые апдейты, то мы 3 минуты ждем, что сосед что-нибудь еще пришлет, потом помечаем маршрут как кривой инвалидный, и через еще минуту маршрут выбрасываем из таблицы, тогда же заодно запускаем hold down timer,

так, ну в смысле hold down запускаем тогда же, когда инвалид, так, если мы хотим настроить соседнюю железку, давайте все-таки попробую роутер XR настроить, есть надежда, что с ним что-то будет работать, я смотрю, он, кстати, как-то там полуживой, полудохлый, show run, enable show run, у него там какие-то дебаги бегают, IP, RP, ну, у него даже IP-шник настроен, то есть вот на интерфейсе Gigabit 1, который смотрит на наши остальные роутеры, у него есть IP-адрес 10.001, я, конечно, могу это все дело сбросить, давайте, раз уж договорились, что роутер XR сбросили, то этот тоже сбросим, inter, так, простите, default interface range Gigabit 1-4, сбрасываем в состояние по умолчанию все интерфейсы, которые у нас есть,

ну, заодно надо do and debug all сделать, а то вот эти вот арпы меня как-то раздражают, выключили дебаги, сбросили все интерфейсы в состояние по умолчанию и настраиваем интерфейс Gigabit 1, указываем no shutdown на всякий пожарный случай, а то вдруг он выключен, IP-адрес, ну, не знаю, 10.001, привычка, 255, 255, 255, 0. Гипотетически у нас сейчас должны пингаться IP-шники роутеры XR, ну, проверим, do ping 10.002, о, даже пингаются, я не знаю, что такое было с нашим XE до сегодняшнего дня, потому что, вот я говорю, что на предыдущих занятиях он себя вел как-то коварно, он на арпы не отвечал, точнее, видел, что арпы приходят ответные, но не добавлял их в таблицу, и, как следует, трафик между двумя IP-шниками не ходил. Сейчас все нормально входит, я ничего с этим комплектом не делал, честное слово.

И после того, как мы включили интерфейс, который смотрит на XR напрямую, создаем точно такой же лутбэк, интерфейс лутбэк 0. IP, адрес 10 11 1 255 255 так еще мне немножко раздражает вот то что на все вот эти дебаги у меня прерывается вот видите я сделаю line 0 логинг синхронус так у меня есть соответственно два интерфейса с айпишниками вроде все хорошо хочу обменяться маршрутами запускаю роутер rip и соответственно первые два действия которые я делаю в операционных системах иус иус xe версия 2 но автосамбри делаю это просто чтобы не попасть на неприятные последствия если говорить про egrp у egrp такая же проблема есть

egrp по умолчанию работает в таком полуклассовом режиме на 12 иусе и он по умолчанию выполняет суммирование сетей до классовых на границах между классовыми сетями это была абсолютно такая стандартная проблема когда люди включали 6 тоник каталист запускали на нем и ggrp а 6 тоники у них как правило иусы старые 12 и они ловили автосамбри и из-за этого трафик между разными кусками классовой сети перестал ходить это очень типичная история когда у вас например пользовательские айпишники в одной классовой частной сети служебные айпишники транзитные они в другой классовой сети у вас соответственно все это дело по факту разваливалось поэтому но автосамбри на старых иусах это было просто обязательное требование если вы настраивали рип или egrp ну сейчас с новыми иусами с новыми иусы xe в egrp это не требуется но в рипе по прежде бы нужно включили на автосамбри и теперь указываем

что нам нужно включить рип на интерфейсах нашем лоббеке и нашем гигабит 1 эти интерфейсы имеют айпишники 10.0.0.1 и 10.1.1.1 они оба принадлежат классовой сети 10.0.0.0 поэтому я указываю команду network и дальше я должен указать классовую сеть десятку я если здесь наберу что-нибудь другое оно все равно мне схлопнет это все до классовой сети десятки сейчас указываю 10.234.32.17 я указываю айпишник из классовой сети десятки он мне его принимает но на самом деле он выполняет команду 10.0.0.0 классовую сеть из этого айпишника вычленяет и добавляет в конфиг do show run include ну эти секшен роутер рип видите сожрал десятку я указал вообще ни разу не классовую сеть я указал айпишник но у меня из этого айпишника извлекся адрес классовой сети добавился в конфиг все интерфейсы на которых

есть айпишники из этой классовой сети то есть наши два лоббек и физический интерфейс они добавились в базу рипа нельзя сказать что какой-то интерфейс у вас в рипе присутствовать не будет просто нет такой возможности вот такие вот особенности скажем реализации рипа в циске ну и смотрим на то что у нас получилось show ip protocols покажут зарегистрированные протоколы как можно пополнить таблицу покажется что у нас действительно есть рип вот он покажется что у нас включился рип на аж на трех интерфейс аж на трех интерфейсах у меня откуда тут взялся дефолтный интерфейс не дефолтный как субинтерфейс я не удалил почему то ну вот у меня гигабит ethernet и loopback 0 интерфейсы по факту добавились в рип на каждом из них отправляется рип второй версии анонс и принимается рип второй версии анонсы автентикации не используются и соответственно все это получилось благодаря одной команде network 10.000 при этом у нас даже какие-то анонсы

рипа к нам приходят 10.002 показывает что next hop есть то есть чего-то он нам такое наприсылал show ip road покажет что маршруты есть и действительно здесь вот он рип маршрут прибежал можно заказать только риповский маршрут show ip road trip можно заказать show ip road 10.222 и он нам покажет маршрут что действительно прибежал из рипа покажется административное расстояние 120 покажется метрика риповская вот она один прыжок между роутерами и и и и вот метрика маршрута единичка traffic share count рип зарегистрировал единичку но рип он тупой протокол он всегда делает traffic share такой же как как самая выгодная метрика маршрута с разными метриками он добавить в таблицу не может поэтому он всегда выбирает до четырех одинаково хороших лучших маршрутов добавляет их и в каждый добавляет одинаковый traffic share count

так если мы смотрим на ios xr то там диагностика тоже у нас есть show rip покажет нам запущенный процесс ну а я уже его делал show rip интерфейс покажет список интерфейсов интерфейс вот они что на каждом из них у нас рип работает на лупбеке я даже сделал пассив интерфейс действительно показан как пассивный на вот этом интерфейсе не показано что он пассивный здесь показано что он нормальный покажет на и пишник на этом интерфейсе показано что у нас используется мультикаст мы присоединились к мультикастовой группе 224 009 серии проутеры и аутентикацию не заказывали обнаружена сущность которая в принципе не существующая rip пиры у рипа нету процедуры установления соседства у рипа есть просто соседей роутер который присылают анонсы по рипу и вот здесь наш роутер xr зафиксировал что из под адреса 10.01 приходят

апдейты и эти апдейты имеют вторую версию мы добавляем базу show ip show раут айпи 4 покажет что маршруты риповские действительно есть вот рип вот этот вот маршрут 10.1.1.1 по 32 маски ко мне прибежал а еще прибежал вот этот вот который с субинтерфейса потому что тоже на нем включился и сказать что я не хочу использовать этот интерфейс в рипе я не могу я могу только его удалить как такой мусорный интерфейс но зато поскольку рип дистанции векторный протокол я могу в любом месте наврать все что угодно я могу на роутере который порождает такой маршрут сказать да в базе он есть show ip рип датабейс давайте покажу show ip рип датабейс у меня показывается что действительно в базе такой маршрут присутствует но я из этой базы могу этот маршрут никому не показывать то есть я просто не анонсирую этот айпешник этот маршрут никому в рипе такая возможность без каких-либо проблем имеется мы здесь можем контролировать в рипе анонсы на уровне от отдельных префиксов можем указывать что на отдельных интерфейсах не показываем анонсы либо вообще никому не показываем анонсы

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

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

у нас показывает что можно указать какой режим мы хотим использовать либо md5 либо plaintext и рядышком еще указываем ключевую цепочку айпи рип аутентикейшн и указываем ключевую цепочку которую надо создать в этом случае все пакеты которые мы будем отправлять они будут подписаны с использованием пароля который будет изъят из этой ключевой цепочки ну давайте скажем кейчейн у нас есть какая-то цепочка и надо ее создать эту самую ключевую цепочку выходим из контекста интерфейса и указываем кейчейн кейчейн кей один кейстринг ну не знаю циска и сейчас все пакеты которые ли будут отправлять они должны будут подписаны быть паролем циска давайте я попробую сейчас включить в air shark и посмотрим действительно ли пакеты риповские будут идти с указанием такого пароля

нам нужно будет возможно немножко подождать учитывая тот факт что риповские апдейты они идут с небольшими с большими таймерами то есть таймер там раз 30 секунд апдейты посылает вот надо будет дождаться очередного апдейта подождать вот и второй версии 10 002 это центральный роутер посылает 10 001 посылает вот сообщение рип аутентикашн симпл пасворд циска все как заказывали соответственно сейчас у нас сосед по факту не работает потому что центральный не центральный а рип на и у сексе я использует пароль рип на и у секса р пароль не использует поэтому у нас через некоторое время после того как в базе таймер риповский протухнет 3-х минутный маршрут из таблицы маршрутизации будет изъят show rip database так показывается вот аптайм 92 секунды это примерно полторы минуты

надо дождаться и дождемся мы его дождемся 180 секунд маршрут будет помечен как инвалид и после инвалида он из таблицы маршрутизации уйдет то есть нету сообщения вида я перестал знать какой-то маршрут там нету сообщения от сосед отвалился если только сосед не заявил что я тебе я хочу отправить метрику 16 то мы ждем ждем ждем терпеливо пока с маршрутом что-то случится вот 10 111 у него аптайм 125 секунд я хочу дождаться аптайма 180 секунд после того наступит таймер инвалид и маршрут должен прекратить свое существование он по-прежнему будет присутствовать в таблице рипа в базе данных но он будет помечен уже как такой кривой косой маршрут которым пользоваться нельзя 147 но немножко осталось так что у нас там еще в рипе есть пока мы смотрим швай пирип статистик давать посмотрим

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

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

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

рассылка hello пакетов подчеркну что команда нетворк здесь никакого отношения к префиксам к тому что будет анонсироваться не имеет опять же здесь тем же успехом можно было написать слово акваланг то есть это не нетворк это просто некоторая команда которая задает условия аксесс листа который мы отбираем айпишники висящий интерфейсах и после этого то что попадает в анонс то что попадает в анонс никакого отношения к тому что в команде нет так указывалось не имеет в анонс попадают все подключенные сети в том числе те которые секондаре если вы сдаете секондаре айпишник он создает какой-то оттачат маршрут присоединенный маршрут он все равно попадет в анонс то есть если у вас например вот здесь вот есть команда команда 192 168 00 по маске 00855 255 network вот у нас есть айпишник 192 168 1 192 168 2131 они могут быть по 24 маскам они попадут в анонс эти сетки по 24 маскам здесь как вы видите маска вообще ни разу не 24 причем она перевернута как как это принято в аксесс листах если вы скажете команду

айпи раут не знаю 8.8.8.8.8.8 слэш 32 не слышу 32 мне просто не писать 255 255 255 255 0 фа 0 0 у вас на этом интерфейсе фа 0 0 появится оттачат маршрут статический он точно также попадет в анонс в анонс egp то есть эта сетка вообще никак в нетворках не фигурирует но поскольку это оттачат маршрут на интерфейсе он в анонс попадет ну и равным образом да вот мы указываем 192 168 00 здесь здесь и здесь в анонсы попадают коннект от сетки и на этом интерфейсе указываем 10 0 0 1 0 0 0 0 команд network то есть на ровно на одном интерфейсе на котором первичный айпишник 10 0 0 1 и ровно такой не более какой-либо еще мы включаем все коннект от сетки в анонс мы начинаем рассылать эти сетки над своим соседям на всех интерфейсах где у нас egp включился мы начинаем рассылать

hello пакеты там где у нас обнаружены соседи которые присылают hello пакеты нам мы с ними дружим и обмениваемся с ними таблицы топологии если у нас все хорошо то все работает замечательно если у нас все нехорошо то у нас есть алгоритм диагностики сначала смотрим шоуи протокол с потом интерфейс на которых egp включился потом список соседей потом таблица топологии потом из нее смотрим что в таблице маршрутизации попала шоуи протокол покажет вам ключевые параметры как запущен egp какой номер автономной системы какие k-values здесь показано что этих коэффициентов компонентов метрики коэффициентов метрики пять штук к 1 к 2 к 3 к 4 к 5 на самом деле в реальности их будет 6 система вам не показывает но еще на самом деле есть к 6 равный нулю который передается потому что все современные egp рпшные роутеры работают с широкими метриками а для них нужно 6 компонентов и система просто скрывает от вас это честное слово то есть даже если вы используете классический режим egp вот тот который

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

варенз это насколько не очень хорошие маршруты могут отличаться друг от друга для того чтобы и gp тоже добавил их таблицы маршрутизации уникальные фичи и gp по умолчанию выключена включать ее на самом деле не стоит то есть несмотря на то что она кажется такая клевая что если у нас есть типа два маршрута один сильно хорош и другой чуть похуже типа между ними трафик можно балансировать по факту она приносит больше проблем чем пользы поэтому за редкими исключениями она не нужна ну и автоматическое суммирование классовых сетей на границе между классовыми сетями у нас выключена хотя до старых и уск по умолчанию работе команда к команда network который мы включили здесь опять же написано routing for networks ничего подобного это никакой не рутинг не for networks какие команды network мы задали и ручки информационные сорсис покажет список next hope также как для рипа шлп и gp интерфейс из покажет список интерфейсов где и gp у вас работает покажет на каждом интерфейсе сколько соседей обнаружено ну и если вы видите что интерфейса в списке нету то подружиться с ним по

нему с соседями не получится если интерфейса нету то интерфейс может быть выключен интерфейс может быть помечен как пассивный или на нем айпишник не попадает под действие команды network мне иногда такое встречалось что люди пытались команды network secondary айпишники отобрать вот должен первый айпишник primary попадать под действие команды network иначе не заведется еще на самом деле отдельно расскажу потом соседство если вдруг у вас устанавливается то сосед будет виден в команде в команде show ip и gp neighbors по каждому соседу показывается его айпишник интерфейс через который он завелся hold time через сколько признаем его трупом если он нам не пришлет новых ало сообщения в течение того времени smooth round trip time среднее время прохождения туда-обратно rt or transmission time out через сколько мы будем пили секунд пересылать ему сообщение повторно если он нам не подтвердит получение сообщения которые доставляются надежно кьюкаунт размер очереди то есть вот здесь вот

всегда должен быть ноль то есть если вдруг вы видите там не ноль в течение длительного времени это не порядок ну и почему сосед может не работать если у нас интерфейсы два друг друг на друга роутер смотрят а вот соседства нету либо несовпадение номеров автономок соседи не будут дружить если они в разных автономных системах либо не совпадают адреса сетей для всех primary и secondary ip адресов то есть смысл заключается в том что если у вас есть два роутера вы указываете что на одном из них есть primary айпишник 10 0 1 1 1 слэш 24 и secondary айпишник 10 0 2 1 слэш 24 а на другом вы говорите что primary айпишник 10 0 2 2 слэш 24 и 10 0 1 2 слэш 24 это secondary у вас дружба здесь не получится то есть он проверяет именно кто primary кто secondary может быть такое что у вас не совпадают коэффициенты вот эти вот к 1 к 2 к 3 к 4 к 5 мы с вами не

видели команду как именно можно их испортить но если они не совпадают между собой метрики будут считаться неодинаково во всей топологии поэтому дружба в таком случае не будет возможно соседи все в автономной системе вообще все роутер в автономной системе должны иметь знаковые коэффициенты к 1 к 2 к 3 к 4 к 5 к 6 может быть такое что у вас не совпадает мту то есть если мту различается и jrp не подружится вот в spf мы с вами говорили что и в спф там в dbd сообщениях проверяют ду там должен соподать перед тем как перейти в фазу exchange фазик старт это делает и jrp тоже это делает на самом деле если у вас jrp не дружат между собой то может быть проблема с мту может быть такое что у вас есть таксес лист который фильтрует протокол 88 то есть jrp не используйте cp и jrp не использует юзи пи если вы делаете аксесс лист который на интерфейсе висит на соседа и говорит permit tcp не не permit юдп не не permit айси пи не не это не значит что он разрешил ежерпи ежерпи использует свое отдельное вложение ну и понятное дело что если интерфейс с одной

стороны с другой стороны работают и jrp то все хорошо если один из них забыть включить то будет плохо после того как дружба установлена дальше смотрим на то что прибежало от соседей и джерпи хранит все маршруты которые приходят от соседей складывать складывать их в специальную базу база называется топология вы можете выполнить просмотр этой таблицы команды show ipjrp топологи и тогда вот у вас покажется все маршруты которые удовлетворяют условиям физибилити комиссион если вы захотите вообще все маршруты посмотреть есть ключик all links или detail то есть она покажет вообще все но обычно нам вот эти вот где ты ил до ты обычно нам все всем все маршруты не нужны нам нужны только фейсбол сексессора и 10 показываются маршруты которые самые выгодные которыми можно пользоваться и ставить их в таблицу мар ж Re� зация по каждому маршруту показывается его состояние буквка п

означает что с маршрутам все хорошо то есть пассивный это не значит что какой-то недостаточно активно это значит что с маршрутом все хорошо можно не кому-видеться если маршрут перешел в состояние active значит с маршрутами есть какая-то беда им пользоваться по факту нельзя показывается сеть которая вас известно показывается сколько сексессоров есть и показывается список списки этих за всех их successor. То есть вот здесь вот список из одного successor, здесь список из одного successor… Здесь список из одного successor и здесь тоже список из одного successor. В нашем случае successor – это мы сами. Показывается для каждого successor, его Reported Distance и наша Computer Distance через него. Самая маленькая метрика самая маленькая Computer Distance наша за всю историю наблюдений, пока маршрут был в пассивном состоянии показывается Здесь вот как feasible distance. Мы будем проверять feasibility condition именно таким образом, что если сосед заявляет, что знает сетку за расстояние меньше, чем вот это вот,

то, соответственно, у нас все хорошо, мы такому маршруту можем верить, он заведомо не проходит через нас. Если сосед заявляет, что знает сетку дороже, чем feasible distance, то, значит, такому маршруту верить нельзя. Далее. Маршруты из таблицы топологии попадают в таблицу маршрутизации. Show IP Route EJRP. 112.168, да. Маршруты показываются, что буква D присылает их по EJRP. Если маршруты, дистрибученные в EJRP, показываются D, EX, внешние маршруты. Административное расстояние EJRP-90, и EJRP такие конские метрики, которые даже на быстрых интерфейсах, они там меньше, чем 512 не бывают. А на всех остальных роутерах, на всех остальных процессах, у нас обычно метрики какие-то не очень большие, десятки, ну, единицы иногда бывают. В том же рипе там единичка была метрика, а здесь 28 тысяч. Если взять более медленные интерфейсы, то метрики будут существенно, существенно больше, миллионами исчисляться.

Это не страшно. Показано, что Show IP Route в таблице маршрутизации на самом деле хранит кучу служебной информации. Показано по каждому маршруту, что он прибежал из EJRP. Показано из автономной системы 65000.01. Мы его взяли. Административное расстояние RIP метрика. Вот эта вот метрика не EJRP, это метрика в таблице маршрутизации этого маршрута. Отдельно есть Compute Distance, но Compute Distance здесь не показывается. Вот эта вот метрика, она же вот эта, это одна и та же метрика, Traffic Share Count, как мы пропорционально делим трафик. И показываются вот эти вот штуки. Вот этот вот вектор метрик EJRP, он переезжает в таблицу маршрутизации. Таблица маршрутизации в роутере хранит кусок информации из таблицы топологии. Показано, что суммарная задержка по этому маршруту 110 микросекунд или 11 десятков микросекунд. Минимальная полоса пропускания 100 тысяч килобит. Reliability полноценная. MTU по осчитанным по трассе минимальная 1500 байт.

И загрузка с самым загруженным месте практически нулевая. Hop Count единичка. Если мы хотим балансировать трафик EJRP, то мы можем это дело включить. Команда используется Variants. Это мультипликатор. Во сколько раз не самые выгодные маршруты могут отличаться от самого выгодного маршрута, при этом считаться достаточно выгодными для того, чтобы их все равно можно было вбросить в таблицу маршрутизации. Эта штука позволяет включить так называемый UCLB, Unequal Cost Load Balancing, уникальная фича для EJRP, так чтобы трафик отбразовался на 2 или 3 или 4 разных NextHop, или насколько хотите разных NextHop, причем что маршруты, посчитанные через этих NextHop, они имеют неодинаковую метрику. Другие протоколы защищаются с помощью разных метрик от петли. То есть они говорят, что если у нас есть маршрут выгодный, есть маршрут невыгодный,

то вот невыгодный маршрут гипотетически может содержать петлю. А самый выгодный маршрут петлю не содержит. EJRP же использует тот факт, что он точно знает, что у соседа петли нет, с помощью механизма, который называется Feasibility Condition. Поэтому он может добавить несколько маршрутов в таблицу маршрутизации, даже несмотря на то, что метрика у них разная. В таблицу маршрутизации в любом случае могут попасть только Feasible Successors, только те маршруты, которые проверены на метрике. То есть если у нас есть маршрут, который отличается в N раз от Суксессора, и он прошел Feasibility Condition, мы его добавить можем. Если у нас есть маршрут, который на копеечку отличается от Суксессора, от самого выгодного маршрута, то есть он чуть-чуть меньше по стоимости, и у нас Variance даже задран в какое-то большое значение, но при этом маршрут не проходит Feasibility Condition, мы его в таблицу маршрутизации не добавляем. Иногда даже бывает такое, что у нас есть два маршрута. У одного маршрута через соседа А reported distance,

ну не знаю, допустим, может быть 100, а computed distance будет, ну например, там, не знаю, 200. И у другого маршрута до той же самой сети, через другой роутер B, будет reported distance, ну не знаю, 100... 150, и соответственно, computed distance будет 160. Вот, в этом случае может такое быть, что вот этот вот маршрут будет выбран Суксессором, а вот этот маршрут не будет выбран вовсе. Несмотря на то, что computed distance у него меньше, но у нас есть еще такая штука, как feasible distance, самая маленькая метрика за всю историю наблюдений. То есть, если она будет, например, 100... Ну, 150 даже, да, 150 вполне сойдет. В этом случае сосед знает, что... Сосед сказал, что знает этот маршрут за 150 копеек. Мы говорим, мы когда-то сами знали маршрут за 150 копеек, и мы не доверяем тем маршрутам, которые присылают нам соседи

с указанием reported distance, не строго меньше, чем наша feasible distance. Поэтому, несмотря на то, что у нас есть маршрут как бы формально выгодный за 160 копеек, мы говорим, мы ему не верим. Мы доверяем более дорогому маршруту, который, однако, гарантированно не содержит петлю через нас. Настройка, соответственно, происходит с помощью команды variants. Мы указываем, во сколько раз невыгодный маршрут может отличаться по цене от выгодного, для того, чтобы мы его все равно могли добавить в таблицу маршрутизации. По умолчанию, variants 1. То есть, маршруты добавляются только, если они абсолютно одинаковые. Вы можете задать там целое число, сказать, variants 2, variants 3, и маршруты будут в этом случае в таблице маршрутизации добавляться, если их метрика различается не более, чем в указанное количество раз с метрикой самого выгодного маршрута. Можно указать команду также traffic share и сказать, как вы хотите балансировать трафик. Traffic share balanced использует балансировку пропорциональной метрики.

То есть, при вбросе в таблицу маршрутизации, роутер EGRP будет добавлять traffic share параметр, чтобы добиться балансировки обратно пропорциональной метрики. Либо вы можете использовать traffic share min, и тогда у вас весь трафик будет балансироваться одинаково. Так. Что касается пассивных интерфейсов, ну, в общем, да, passive interface, default, no passive interface. Все то же самое, как в RIP, ничего не изменилось. Если вдруг вы хотите работать с EGRP, базовая работа с EGRP для IPv6 выглядит точно так же, как для IPv4, ничего нового. Опять же, учитывая, что фактически там работает алгоритм dual, которому фиолетово на то, что передается, он просто передает как бы маршрут одну штуку. А какой маршрут там будет, IPv4, IPv6 ему по барабану. Процедура выбора маршрута, лучшего или худшего, процедура назначения метрики, она не зависит от того, что мы передаем. Поэтому EGRP для IPv4 и IPv6, в общем-то,

не сильно отличаются между собой. Команды network нету, соответственно, есть вместо нее команда IPv6, EGRP, и дальше номер автономной системы на интерфейсе. То есть, если мы хотим включить EGRP для IPv6 на интерфейсе, допустим, вот в гигабите 0.0, FastEthernet 0.0, 0.1, 0.2, мы используем интерфейс range, и с помощью этой команды указываем на всех четырех, в нашем случае, интерфейсах, команду IPv6 и EGRP 65.0.1. Поэтому включаем EGRP тут, тут, тут и тут. Точно так же команда делает... Тут какая-то странность у меня. FD 0.0. Точно так же команда делает абсолютно идентичную вещь с EGRP для IPv4, то есть начинает отправлять Hello-пакеты на интерфейсе, и все коннект-отсетки включают в анонс. Есть нюанс, что EGRP не может запуститься, если вы не назначите router ID. И router ID задается в формате IPv4 адреса. Это не IPv4 адрес, это число в формате IPv4 адреса. То есть EGRP, router ID, дальше некое число.

Вот 0.0.0.1 как IPшник, это не очень здорово использовать. А вот как router ID, пожалуйста, никаких проблем. Правила те же самые, что и с OSPF. То есть если вы используете router ID, лучше всего будет взять отдельный лупбек, который у вас наверняка будет использоваться для административных целей, и router ID назначить равным IPшнику на этом лупбеке. Show IPv6 protocols. Опять же здесь ошибка. Show IPv6 protocols. Покажет нам, что у нас есть protocol. Опечатка. Да. С указанными параметрами. Опять же здесь он скрывает от нас, но на самом деле K6 равен 0. Точно так же показывается, на каких интерфейсах у нас включился EGRP. Здесь раньше показывалась команда network, сейчас показывается, на каких интерфейсах EGRP включился. Небольшие различия косметические заключаются в том, что максимум пасс в IPv6 EGRP будет 16. Связано это с тем, что у старых даже платформ для IPv4

на каждый маршрут использовалось 16 бакетов, и для того, чтобы балансировать трафик в разных пропорциях между четырьмя разными маршрутами, нам нужно было бакетов, как раз все 16 штук использовать. В случае же с IPv6, у нас Cf для IPv6 используют до 64 бакетов на один префикс, поэтому балансировать трафик в разной пропорции можно с большим количеством next-hopов. По умолчанию EGRP до 16 next-hopов вбрасывает в таблицу маршрутизации. Опять же, это можно переопределить. Show IPv6 EGRP interfaces, show IPv6 EGRP neighbor, show IPv6 EGRP topology, все те же самые команды у нас будут. Ну и show IPv6 road. По show IPv6 EGRP neighbors следует заметить, что link-local адреса будут указываться в качестве соседских, то есть нам не обязательно иметь маршрутизируемые адреса на интерфейсах транзитных, которые будут между роутами. В основном все то же самое. Ну и в таблице маршрутизации маршруты EGRP показываются буквкой D.

В нашем случае мы видим, что у нас маршруты есть. Show IPv6 road по маршруту показывает всякую разную интересную информацию. Вот тип маршрута EGRP-шного, что это нативный EGRP-шный маршрут. И показывает next hop. В нашем случае next hop всего один. Если мы хотим использовать аутентификацию, точно так же мы должны будем использовать ключевые цепочки, как и в случае с RIP. Указываем, что у нас есть ключевая цепочка. Если мы хотим организовать переход ключей, то мы можем сделать несколько ключей на одной ключевой цепочке и указать время, когда мы отправляем и принимаем каждый из комплектных ключей. Обычно в этом случае мы говорим, что вот если у нас есть какая-то временная ось, мы говорим, что у нас вот в норме до определенного часа X должен использоваться некий ключ номер 1. Вот мы говорим, у нас есть ключ номер 1, у него там пароль CISCO 1, 2, 3. И у нас есть некий час X, когда должен отправляться этот ключ. Криво нарисовал. Не здесь, он вот так вот.

Час X, когда мы отправляем один ключ, вот до часа X мы отправляем один ключ, а после часа X мы говорим, должен отправляться другой ключ. Но есть нюансы, что если мы используем на разных роутерах указание, что вот до определенного часа мы используем ключи, после определенного часа мы используем другие ключи, время может немножко не сойтись. Поэтому обычно, когда мы говорим, что у нас есть ключи, которые мы отправляем, мы указываем вот ровно, что до определенного часа мы что-то отправляем, после определенного часа мы отправляем что другое. Но соседний роутер, который будет отправлять эти самые ключи нам, он должен отправлять эти ключи нам в соответствии со своими часами, установленными. И эти часы могут немножко расходиться. Поэтому может быть такое, что у нас час икс уже наступил, и мы уже отправляем соседу второй ключ, А у соседа этот час X еще не наступил, поэтому мы говорим, что у нас send lifetime будет происходить вот ровно с часа X или от часа X до часа X.

В общем, мы точное время указываем. А accept lifetime мы обычно указываем с небольшим перехлестом. То есть мы говорим, что вот есть некое время, в течение которого мы согласны принимать еще первый ключ, потому что у соседа, возможно, небольшое расхождение во время с нами есть. И равным образом, что принимать другой ключ мы тоже начинаем немножко раньше по сравнению с тем, как мы сами этот ключ начнем отправлять. Ну и эти ключи можно на лету редактировать, на лету менять. И когда мы хотим указать, что у нас на каком-то интерфейсе EJRP должен использовать аутентификацию, мы должны задать две команды. Authentication Mode EJRP, IP Authentication Mode EJRP на интерфейсе. Указываем номер автономной системы и указываем, какой тип аутентификации мы используем. EJRP поддерживает только MD5 аутентификацию. Вот фактически вот эта монолитная запись EJRP 650001. Очень часто люди не понимают, что говорят. А типа там может быть какая-то другая автономная система в этом интерфейсе.

Вот EJRP 650001 — это просто мы указываем экземпляр EJRP, с которым мы работаем на этом интерфейсе. И IP Authentication Keychain привязываем к ключевую цепочку. Указываем Authentication Keychain, опять же, комплект EJRP 650001 и название ключевой цепочки. Так, далее, далее, далее, далее. Если вы имеете несколько ключей, которые валидны, то есть у вас есть и ключ номер один, и ключ номер два, которые почему-то оказались валидны оба, в норме, как я уже сказал, эта штука используется для перехода ключей. Мы до определенного момента начинаем отправлять один ключ, после определенного момента начинаем отправлять только второй ключ. У нас не должно быть никогда такого, что в какой-то момент времени валидны для отправки оба ключа. Но если вдруг такое получается, что валидны для отправки оба ключа, подписывается ключ с минимальным номером. Если мы работаем в EJRP для EOS XR, то настройка выполняется в контексте роутера EJRP.

Опять же, то же самое, что в контексте роутера RIP. У нас вся настройка выполняется в одном и том же месте. Мы уже не лазим отдельно на интерфейсы, мы не лазим куда попало. Мы все делаем в одном и том же контексте. Команды network больше нет, поэтому настройка идет через субконтекст интерфейс. Мы указываем, у нас есть роутер EJRP. Дальше здесь задается либо число номера автономной системы, либо задается имя. Вы по-хорошему можете назначить имя комплекта. В принципе, если здесь используется число, то дальше при включении EJRP для IPv4 и EJRP для IPv6 у вас число номера автономной системы будет просто наследоваться. Вот здесь я на всякий случай сделал и номер автономной системы в названии роутера. И после того, как мы указываем адрес Family IPv4, отдельно указывается автономная система 650001. Как понятно, вы можете рядышком с адрес Family IPv4 запустить адрес Family IPv6, и, в общем, ничего от этого не изменится. Здесь нигде в содержимом никаких отсылок к IPv4 или к IPv6 нет.

Все настройки относятся к EJRP и не относятся к конкретному протоколу. Здесь задается в настройке адресного семейства номер автономки, Variants, если нужно, Maximum Path, если нужно, указываем Passive Interface. И если хотим включить EJRP на интерфейсе, то в явном виде указываем интерфейс такой интерфейс, такой интерфейс, такой интерфейс пятый, интерфейс десятый. Если хотим аутентификацию включить, просто указываем не то, что там пытаемся догадаться, какие команды в CISC соответствуют EJRP, какому номеру автономки. Ну, то есть очевидно, да, что вот процедура аутентификации, что в RIP, что в EJRP, она кривая, косая и сделана сумасшедшими людьми для сумасшедших людей. Если вы знаете, как она делается, окей, это несложно. Но если вы не знаете, вы никогда не догадаетесь, что вам надо создать именно ключевую цепочку и не прописать пароль в открытом виде. Здесь в настройке интерфейса просто указывается Authentication, Keychain.

То есть вы просто не можете здесь ничего больше сделать, у вас только один вариант, что сделать. Одна команда, один вариант того, что можно либо включить аутентикацию, либо не включить. Ну и ключевые цепочки создаются точно так же. То есть вы указываете, что у вас в глобальном контексте есть ключевая цепочка, на ней вешается ключ с номером некоторым, и на этом ключе ключевая строка, время, когда принимаем, время, когда отправляем. Диагностика вся та же самая. Show EJRP IPv4, Interfaces, Neighbors, Topology. То есть все то же самое. То есть поменяли местами IP и EJRP, и у нас, в общем, получилось все так вот. Давайте попробуем это дело опять же настроить. Далее. EJRP мы посмотрели с вами. Давайте посмотрим на... Нет, мы не делали EJRP, давайте настраивать EJRP. У нас есть наш роутер Cisco.

И мы сейчас поднимем быстренько EJRP, убив предварительно RIP. На EOS XR убивается RIP очень легко. Указываем, что нас интересует конфигура терминал. Пытался сказать, что я сделал... Не набрал конфигура терминал, пытался удалить быстренько T, пока вы не заметили, но удалил пробел. Ну, роутер RIP. Все. Commit. RIP убит. На EOS обычно мы должны будем отдельно убить сам процесс RIP, отдельно пойти по конфигам. То есть вот я сейчас возьму и на EOS XE, который фактически обычный EOS. Я вот покажу. Show running config section RIP. То есть показать все строчки, имеющие отношение к RIP. И у нас есть сам контекст RIP. И плюс у нас есть еще вот эта вот строчка, которая висит в настройке интерфейса. То есть конфиг RIP разделен на несколько частей. Если мы хотим удалить RIP, то мы должны будем отдельно сказать no router RIP.

И это удалит контекст RIP. Но вот при этом вот эта вот хреновина все равно в конфиге останется. Show. Так, do show. Do show. Do. Show run section RIP. Ух ты. Надо же. Фокус не удался, факел был пьян. Раньше старые версии RIP, они оставляли следы на интерфейсах. Я вот не знал, что они исправили это поведение. То есть если вы удаляете контекст router RIP, хвосты остаются в любом случае. Ну вот, новая версия винти не оставляет. Ну ладно, прекрасно. Не уставляет, не оставляет. Роутер EGRP. И дальше запускаем номер основной системы. Опять же, неважно какой, главное, чтобы одинаковый. 65.001 с одной стороны. Ну, значит, с другой стороны тоже будет он. Опять же, нужно включить EGRP на интерфейсе, на котором мы хотим подружиться. И мы указываем, что у нас IP-шник, на котором мы хотим подружиться. Здесь, по-моему, 10.001. Network.

Никакого отношения к сетям не имеет. Задает условия access-листа. Я говорю, я хочу access-листом отобрать ровный интерфейс, на котором IP-шник ровно 10.001. Я указываю 10.001. И в outcard-маску 0.001. И тем самым я включаю EGRP ровно на одном интерфейсе, на котором IP-шник ровно 10.001. Равным образом я указываю Network. 10.1.1.1. По маске 0.001. Условие access-листа отбирает только один IP-шник. 10.1.1.1. Только интерфейс, обладающий таким IP-шником Primary, попадает в анонс EGRP. Ну и с другой стороны, на XR-е делаю ответные действия. Роутер, EGRP, 65.001. Адрес Family, Family, IP-4. Не помню, Unicast надо? Не надо. Не надо Unicast. Unicast. Unicast просто. Autonomous System можно не набирать, учитывая, что номер автономки у нас уже указан.

65.001. Можно указать Autonomous System. Autonomous System. Вот здесь можно номер автономки указать. Можно не указывать, и так сработает. И указываем Interface. Egabit 0.00. На нем включаем EGRP. И Interface. Lookback 0. На нем включаем EGRP тоже. Не мешало бы нам сейчас сделать так, чтобы у нас роутер показал бы нам какое-то сообщение, если у нас сработает соседство. Я, честно говоря, не помню в EOS XR это работает по умолчанию или нет, но я на всякий случай сейчас проверю. Выхожу из контекст-интерфейс и... И... Да. LogNamewareChanges. Вот эта вот штука. Это LogAdjustances. Нет такого, да? LogNamewareChanges. Ну, пусть будет. Так. LogNamewareChanges. И Commit.

Коммитимся, запускаем EGRP. У нас через некоторое время должно установиться соседство, и роутеры должны будут обменяться маршрутами лоббаков. Ждем Commit. Так. Do. Давайте не Do. Давайте с другой стороны зайдем. Вот. Соседство у нас установилось. А вот, да, XR ничего не показал. Собака страшная. Do. Show. Log. Да, вот. Соседство у нас установилось. В логе оно есть. На консоль оно не пробежало. Ну, ладно. Смотрим на то, что получилось. Выходим из контекст-роут. Из контекста настройки. Смотрим. Давайте на XE сначала. Те команды, которые у нас были на слайдах. Show IP EGRP interfaces.

Покажем, что у нас есть два интерфейса в EGRP. Один из них гигабитный. Другой лупбэк. По-хорошему лупбэк надо было бы сделать пассивным. Тогда бы он из этого списка пропал. На интерфейсе обнаружен сосед. Среднее время туда-обратно 41 миллисекунда. Кстати, чуть дофига. И можно посмотреть, что именно это за сосед. Show IP EGRP neighbors. Показано в сосед 1002. На интерфейсе гигабита первым он был обнаружен. И, соответственно, у него сейчас идет нормальная цивилизованная работа. Show IP EGRP topology покажет нам список всех маршрутов, которые в EGRP нам известны. У нас есть два коннекта маршрута, которые у нас в таблице EGRP есть. И один маршрут, который нам рассказали. То есть сосед заявил, что он знает за 281 копейку некий маршрут. Прислал его нам. Мы посчитали computed distance для этого маршрута 2841 копейку. Это запомнили в качестве самой маленькой метрики за всю историю наблюдений.

Проверили, что вот это число меньше, чем вот это число. Все честно. И добавили этот маршрут в таблицу маршрутизации. Show IP Rout EGRP. Вот он наш маршрут. Вот она метрика, которая текущая есть. Через NextHop 10.002. На XR-е... Давайте... Show run partition, по-моему, да? Show run... А, сразу router EGRP. Роутер EGRP. Вот как выглядит конфигурация роутера на EOS XR. То есть я просто сказал, что у нас адресное семейство IPv4. На нем есть интерфейс лупбека и интерфейс не лупбека. Все, больше ничего нет. Никаких команд neighbor, ничего. Просто вот такая вот компактная запись. Опять же, если я скажу, ну, router EGRP 65.001, я убью весь контекст. У меня все упоминания про router EGRP на этой железке уйдут в небытие.

Show EGRP IPv4 interfaces. Покажут список интерфейсов. Та же самая картинка, что была на EOS обычном. Только синтаксис. Сначала EGRP, потом IPv4. В принципе, на EOS обычном вот эта вот команда тоже сработает. Вот сейчас показываю. Фокус. Show EGRP. Адрес family надо написать. Адрес family. То есть вот она показывает тот же самый вывод. Ну, на XR адрес family писать не надо. Show EGRP IPv4 interfaces. На двух интерфейсах EGRP завелся. На одном из них обнаружил соседа. Среднее время прохождения туда-обратно 26 миллисекунд. Ну, то есть раскачивается потихоньку. Show EGRP IPv4 neighbors. Neighbor, по-моему. Покажет соседа. 10.001 на интерфейсе гигабите 0.001. Topology. Покажет топологию.

Все те же самые маршруты, что у нас есть. Они никуда не делись. И в таблице маршрутизации. Show IPv4. Road. EGRP. Простите. Show Road IPv4. EGRP. IPv4. EGRP. Вот он наш EGRP-шный маршрут. То есть все вроде бы работает. Если захотим, можем, по-моему, здесь сказать. Show Road IPv4. 10.1.1.1. Слэш 32. И нам вернут более расширенно какую-то информацию. Detail. Вот. То есть EOS XR. Помнит, что это маршрут был EGRP-шный. Рассказывает про него все, что знает. Показывает. Показывает, показывает, показывает. Метрику его.

Вот эта вот метрика, видите, 2 миллиона 570 тысяч 240. Это на самом деле широкая метрика. То есть wide-метрики. Когда мы пользуемся EGRP, мы не замечаем этого. На самом деле он использует широкие метрики. Я вам сейчас докажу это. Я сейчас опять же запущу в AirShark. Так. Меня интересует не RIP. Меня интересует EGRP. E-E-V-G-R-P. E-E-G-R-P. Вот он у нас работает. Сейчас бы мне надо отобрать какие-нибудь апдейты. Не hello пакеты, а апдейты. Вот он, апдейт. И, и, и, и, и. Вот. Видите? Широкие метрики. И показываются, какие параметры он передает. Вот он передает Reliability, Load, MTU, HopCount, Delay, Bandwidth. Две дополнительные метрики Jitter, Energy он не передает. Они опционально идут в TLV. И здесь еще есть коэффициенты.

K1, K2, K3, K4, K5. Так. А они в hello идут. Вот они. K1, K2, K3, K4, K5 и предательский K6. Вот. То есть на самом деле, когда два роутера дружат между собой, вот этот вот IOS XE, он говорит, я дружу по классическим метрикам, show IP protocols. Бьет себя пяткой в грудь, говорит, у меня все хорошо, у меня только пять коэффициентов. K1, K2, K3, K4, K5, ни про каких-то K6 он не говорит. Когда он метрику показывает, show IP, EGRP, Topology, Topology, нигде не показывает он, что там какие-то страшные миллионы. Он говорит, у меня все в килобитах считается, у меня все в десятках микросекундах, и стандартную формулу показывает. В реальности на XR используется все уже по-честному, и метрика, мы видим, здесь она уже конская. Конская метрика, потому что именно такая метрика должна быть при работе с широкими метриками. Это 64-битная метрика.

Если у нас будет не такой быстрый маршрут, она вырастет сильно больше, чем 32 бита, и если надо будет ее добавить в таблицу маршрутизации, то, соответственно, будет использоваться уплотнение. То есть будет использоваться мультипликатор, обычно там на 128 делят, и оно неплохо типа влезает. Но если нужно, можно будет изменить этот процесс, можно будет сказать, что при вбросе широкой метрики в таблицу маршрутизации, если у нас уже iOS обычно не будет прикидываться, тут дурачком будет прикидываться именно уже по-честному, все будет широкую метрику пытаться добавить. Можно будет сказать, что в таблицу маршрутизации метрика EGRP-шная добавляется с какими-то другими значениями. Так. EGRP показал. Давайте двигаться дальше. Дальше у нас по плану OSPF. OSPF в нацистках есть. Мы его даже включали на CCNA. Rooter ID использует алгоритм выбора либо прибитой гвоздями в ручную настройку, либо самый большой адрес на лупбеках в этом экземпляре OSPF,

либо самый большой адрес на лупбеках просто, либо просто самый большой адрес на всех интерфейсах. Вам на стандартных курсах, скажем, цисковских или в книжках CCNP-шных про вот этот вот шаг не скажут. На самом деле он есть. Что если у вас есть лупбек, который заведен в OSPF, то циска предпочитает его, даже если он меньше. То есть если у вас, например, есть адрес 10.0.0.1 на интерфейсе Gigabit 0.0, адрес 10.0.0.2 на интерфейсе лупбек 0, который входит в OSPF, который вас интересует, например, в OSPF 1, и 10.0.0.3, который на другом лупбеке у нас не входит в наш OSPF, OSPF V2. Ну, там OSPF другой процесс, другой экземпляр. Так вот, если мы запустим два разных процесса OSPF, они выберут два разных лупбека. Один выберет в качестве роутер-аде лупбек 10.0.0.2,

другой выберет 10.0.0.3. Дальше. Стоимость интерфейсов вычисляется циской по хитрой формуле. Референсная полоса разделенная на скорость интерфейса. То есть у нас интерфейс 100 Мбитный, скорость его будет 100 Мбит, деленная на 100 Мбит, получается единичка. Учитывая, что iOS XR создан для работы с интерфейсами существенно более быстрыми, и, в принципе, у него 100 Мбитных интерфейсов отразясь не бывало, то эта формула для iOS обычного еще худо-бедно подходила, начиная с 92-го года, а сегодня она уже даже для обычных iOS немножко устарела. Для iOS XR она тем более устарела. Поэтому можно будет сказать, что просто iOS всегда назначает всем интерфейсом единичку и все. iOS обычно работает в режиме совместимости со старым RFC 1583, что в некоторых случаях может вызывать любопытные глюки, потому что это RFC устаревший, на его место сейчас пришел 2328, и, соответственно, если у вас часть железа работает в одном режиме, часть в другом, ну, да, возможны костыли разные забавные.

OSPF второй версии, которая для IPv4 на iOS обычно включается двогоразными способами. То есть вы можете воспользоваться либо старой командой Network, которая, можно заменить словом Aqualang, ничего не изменится, которая задает условия аксесс-листа, и вы указываете, что те интерфейсы, которые попадают под условия аксесс-листа, которые вы вводите командой Network, включаются в OSPF. Но интерфейс у нас не просто включается в OSPF, а в указанном регионе. На интерфейсе, на котором мы включили OSPF, начинается отправка хлоу-пакетов, начинается дружба с соседями, и начинаются все анонсы включаться в... все коннект-отсетки включаться в LSA-ки первого типа. Включаются все подключенные сети, все сети включают те, которые появляются в результате секондри-айпишников и в результате static-оттач-троутов. Если вы хотите воспользоваться новым способом, то вы должны будете зайти на интерфейс, указать IP, OSPF, номер процесса, area, ну, какой регион вы хотите такое делать.

На экзамене, возможно, вас будут ловить на то, что номера процессов постараются подсунут нестандартные. Если хотите задать стоимость интерфейсов, можно либо в явном виде сказать, что интерфейс стоит столько копеечек, стоимость 2-байт-тв, либо использовать автокост-референс-бендис. Она указывает, что, соответственно, сколько мегабит мы будем делить на скорость интерфейса. По умолчанию – 100. Ну, да. Если хотите объявить интерфейс пассивным, заходим в контекст роутер, указываем, что либо один пассивный интерфейс будет, два, три, четыре, сколько надо, либо все пассивные, а один не пассивный. Если что-то не работает, тот же самый алгоритм. Проверяем живость самого OSPF, проверяем интерфейсы, соседство и чего в итоге посчиталось. У OSPF есть отдельная таблица базы данных самого OSPF, которую можно тоже потраблшить, showIP OSPF database. Но на нашем уровне детализации, скажем, это не сильно интересно. А вот, допустим, на курсе по роутингу,

мы там уже, конечно, в базе будем ковыряться, дай Боже. Результатом будет то, что OSPF посчитает кратчайшие маршруты, сложит их в свою промежуточную табличку, а дальше оттуда постарается переложить их в таблицу маршрутизации. Вот эти две команды, showIP OSPF road, showIP road OSPF, это две разные команды. Одна из них до попытки вброса маршрутов, то есть то, что OSPF посчитал нативно. Вторая после, когда мы уже в таблицу маршрутизации что-то добавили. Как проверяем список интерфейсов? ShowIP OSPF интерфейс, если вы просто закажете без бриф, то система выдаст простыню по всем интерфейсам, которые у вас есть. ShowIP OSPF интерфейс бриф покажет табличный вывод, с которым удобно работать. ShowIP OSPF neighbor покажет список соседей, по каждому соседу показывается его ID-шник, это ID, это роутер ID соседа, он на всех соседствах будет одинаковый. Показывается его IP-шник, вот это вот, это у нас IP-шник, не путайте, то, что здесь они два указанных значения

похожи друг на друга, эта случайность, так в норме не всегда бывает. Показывается приоритет и показывается, соответственно, приоритет при выборах DR-BDR. Поскольку DR-BDR выбирается для того, чтобы оптимизировать поведение в мультиаксесс-средах, то, соответственно, не все со всеми в мультиаксесс-среде будут дружить. Если DR-BDR выбирается, DR и BDR дружат все со всеми, а все остальные DR-азеры не дружат между собой. Вот в этом случае у вас показывается, конкретно с этим соседом, есть полное соседство или нет. Если нет, то будет здесь 2-way. И, соответственно, здесь после DR-BDR показывается, кто сосед. Если мы захотим посмотреть, кто мы, то мы это видим вот здесь вот. showIP SPF, интерфейс brief. Ну и результатом работы то, что в SPF чего-то там посчитал, будет showIP route SPF, маршрут SPF показывается буквкой O, административное расстояние 110, метрика по умолчанию, как мы помним, для каждого интерфейса единичка.

То есть если у нас есть два роутера, которые друг на друга смотрят напрямую, и один говорит, я знаю за одну копеечку некую сетку, мы соседа знаем за одну копеечку, мы посчитаем и говорим, вот мы посчитали, получилось, что для того, чтобы дойти до некой сетки, у нас нужно две копеечки заплатить. Если вдруг вы захотите потраблшутить таблицу LSDB, то делается это команда showIP SPF database, то есть здесь вот показано, что вот эти вот LSDB, это LSDB первого типа, вот эти LSDB второго типа, вот эти LSDB третьего типа, вот эти LSDB пятерки. Если вы все в один регион запихиваете, то четверка у вас там не будет, ну и трешка на самом деле не будет. Если вы разбиваете сеть на регионы, то у вас будут трешки-четверки. Если вы захотите в OSPF вбросить какие-то внешние маршруты, то, соответственно, тоже как же можно будет это сделать с процессом, который называется редистрибуция. То есть мы берем какие-то внешние маршруты и вбрасываем их в OSPF.

У OSPF не требуется назначать базовую стартовую метрику, seed metric, то есть по умолчанию маршруты, которые будут вбрасываться в OSPF, будут генерировать LSDB пятерки второго типа метрика, то есть метрика, выраженная в баксах, если вы помните, про что я. И, соответственно, значение метрики будет 20. Вы можете в явном виде указать, что маршруты, которые вы будете вбрасывать, будут иметь либо другой тип метрики, либо другую саму метрику. И можно, в принципе, будет там достаточно гибко назначать эти самые метрики с помощью так называемых road map. Ну, если мы в OSXR работаем с этим, то с помощью road policy. Road policy и road map сильно за рамками нашего курса будут, поэтому, если вдруг интересно, то на провайдерском CINP это мы разбирать будем обязательно. Сейчас пока нет. Есть особенность в iOS обычном, если вы не укажете ключ вот такой вот, subnet, то будут вбрасываться в OSPF только сетки классовые. Зачем это сделано, я не знаю. То есть кому-то, когда-то пришла в голову гениальная идея,

почему он перед этим не пошел, не самоубил стабстинку, потому что это, на мой взгляд, тоже была бы гениальная идея, я не знаю. Ну, вот с тех пор все, кто чего-то вбрасывает в OSPF, указывают команду redistribute чего-то там, subnet. Вот это вот слово. Его просто всегда надо указывать в современном мире абсолютно всех случаев. Вот. Хотим бросить connected сетки, указываем subnet. Хотим бросить static сетки, указываем subnet. Хотим бросить EGRP, указываем subnet. То есть в обязательном порядке указываем subnet. Зачем вбрасывать connected сетки? На самом деле, это очень интересный вопрос. Если у вас есть роутер, OSPF-овский, мы можем, казалось бы, если у нас есть какой-то интерфейс, который смотрит в сеть, взять и включить OSPF на этом интерфейсе. Казалось бы, да? Хорошая идея. Но в этом случае маршрут, который у нас будет известен через LSA-ку первого типа, он будет распространяться на все остальные роутеры. И если у нас в LSA-ке произойдут какие-то изменения, у нас, соответственно,

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

это в принципе очень плохая практика. Но если у вас очень мало этих пользовательских сетей, вы можете в принципе попытаться по этому пути пойти. В этом случае вы говорите, давайте мы коннектат сетку, вот эту вот редистрибутим. У нас получится вместо кусочка LSA-ки первого типа LSA-ка пятерка. И вот такой вот механизм позволит вам эти самые пятерки порождать или убивать. И это не будет вызывать смену топологии. Не будет вызывать пересчет SPF. И как следствие у вас вашу сетку колбасить не будет. Да, LSA-ек пятерок при этом будет много, но у вас топология при этом будет монолитная, она будет надежная. А то, что все вот эти вот пользовательские маршруты будут порождать LSA-ки пятерки, но будут порождать, да. Но у нас фактически в этом случае SPF будет работать как Distance Elector Protocol для пользовательских маршрутов. Он будет просчитывать кратчайший путь до удаленного ASBR по LSA-кам четверкам или напрямую по LSA-кам первого типа, если в одном регионе все происходит. А дальше будет говорить. Вот мы видим, что он, этот самый ASBR,

анонсировал 100-500 LSA-ек пятерок. Вот мы до всех этих LSA-ек пятерок ставим себе NextHop тот самый, который идет по кратчайшей трассе к тому ASBR. Если вы хотите использовать аутентификацию, в принципе, это неплохая идея будет всегда. Это можно сделать двумя способами, но, соответственно, один из этих способов, он откровенно плохой. Вы можете использовать аутентификацию по паролю, то есть подписывать все сообщения просто плентекстовым паролем, либо подписывать все сообщения хэшем MD5 от содержимого пакета и пароля, что, конечно, существенно более разумная идея. Если вдруг вы захотите использовать пароль плентекстовый, я не знаю, зачем вам это может пригодиться, то есть разве только в лабе протестировать, что это вообще возможно, мы будем указывать IP, OSPF, аутентикейшн кей на каждом интерфейсе, где мы хотим использовать аутентификацию. То есть вот эту вот штуку надо на каждом, каждом интерфейсе на соседа будет прописать. У нас есть 10 разных роутеров

соседей в OSPF, значит, на 10 разных интерфейсах на соседский роутер мы должны будем указать IP, OSPF, аутентикейшн кей, и дальше тот ключ, который для этого соседа подходит. А дальше будет параллельно с этой командой, какой ключ мы хотим использовать, указание, что ключ использовать вообще надо. Можно это сделать либо на уровне интерфейса, рядышком написать IP, OSPF, аутентикейшн, у нас будет две команды, вот эта вот и вот эта вот. Либо на уровне региона просто сказать, что все интерфейсы в регионе должны использовать аутентификацию, area 0 authentication. Если вы хотите использовать хэш MD5, то на каждом интерфейсе надо будет задать не plaintextный пароль, а вот такую вот колбасу. IP, OSPF, месседж дайджест кей, дальше номер ключа, указать, что ключи будут не plaintextом отправляться, а с помощью хэша MD5, и некий пароль, secret key. И тоже, так же, как и в предыдущем случае, либо на уровне интерфейса рядышком указать команду IP, OSPF, аутентикейшн, аутентикейшн, аутентикейшн, аутентикейшн, аутентикейшн, либо указать на уровне

всего региона не area 0 authentication, а area 0 authentication месседж дайджест. Если у вас есть несколько ключей, то работать будет это все интересно довольно. То есть, когда ключ вы отправляете, когда вы отправляете сообщение, подписанное ключом, вы указываете и хэш, и номер этого ключа. И, соответственно, если сосед принимает hello packet или какой-то ls update или что-то еще и видит, какой ключ в нем использован, и если он видит, что у него есть ключ с таким же номером, он его использует. Если у него такого ключа нет, то он просто игнорирует сообщение. Но у вас возникает вопрос. Ладно, когда вы отправляете какое-то сообщение с ключом, сосед поймет, какой ключ ему использовать, если у него этих ключей несколько. Но какой ключ использовать вам? Вы же можете использовать только один ключ, а у вас их там, например, два или три. Вот один ключ с номером 1, второй рядышком лежит ключ с номером 2, третий ключ с номером 3, и все ключи разные, пароли разные. И вы не можете отправить сообщение с указанием двух-трех разных ключей, двух-трех разных хэшей.

То есть нельзя так сделать. Вы отправляете сообщение в этом случае с одним ключом, который у вас самый маленький. Но если к вам придет входящее сообщение с каким-то другим ключом, вы включаете процедуру KeyRollover. Вы начинаете все сообщения дублировать. Вы хотели отправить одно hello-сообщение с ключом номер один, а к вам приходит hello-сообщение с ключом номер два. Вы говорите, о-о-о, а у нас-то есть соседи, которые не используют ключ номер один. Вы в этом случае включаете KeyRollover, начинаете отсылать и первый ключ, и второй ключ, и третий ключ в разных сообщениях. Вместо одного hello-сообщения начинаете отправлять три. То есть вот этот KeyRollover это такая костыльная процедура, которая позволяет дружить с соседями, которые на интерфейсе используют не такой же ключ, как вы. Вот. Если вы хотите, вы можете использовать использовать аутентикацию по ключевой цепочке, так же, как мы

это делали в EJRP и в RIP. В этом случае указываем, что у нас есть такая ключевая цепочка и добавляем к ключу, помимо ключевой фразы, вот такую вот хреновину. Криптографик, алгоритм. Здесь показано, какие механизмы можно будет использовать в ЦИСКе. Ну вот можно сказать, например, что вас интересует либо просто MD5 хэш от пакета плюс пароля, либо использовать более серьезные вещи с краптографическим шифрованием SH1. Вот. Ну, в любом случае вы указываете, что у вас есть такая ключевая цепочка, и затем вы указываете на интерфейсе IP, USPF, Authentication, Keychain, и дальше указываете ключевую цепочку. Все равно вы будете использовать номерованные ключи, то есть у вас на ключевой цепочке одновешенные ключи с номерами. Из ключевой цепочки выбираются ключи с наибольшим номером, а если вдруг ключи приходят к вам в сообщениях, и эти ключи не с наибольшим номером, то ничего страшного, вы можете проверять со всеми

действительными ключами, у которых у вас указан Accept Lifetime действительный. В этой ситуации KeyRulever не нужен, потому что вы можете в этой ситуации рулить ключами, ограничивая срок их действия. То есть вы можете в этом случае переходить с одного ключа на другой без каких-либо особенных проблем. Если вдруг вы хотите работать с USPF третьей версией для IPv6, должны будет уже никакую команду Network не использовать. USPF включается на интерфейсе только в явном виде. Заходим на интерфейс, указываем IPv6, USPF, номер процесса, area, номер региона. Точно так же назначается RouterID, причем RouterID для USPF витрии назначать приходится часто, потому что если у вас не будет ни одного IPv4 адреса, автоматически роутер не сможет RouterID себе выбрать. Точно так же, как и в случае с EGRP, Show IPv6 Protocols, мы смотрим для того, чтобы посмотреть, USPF вообще завелся, не завелся. Здесь показано RouterID. Почему я вам рассказываю про эту команду, хотя вообще она не про не USPF, не про EGRP,

потому что если вдруг у вас RouterID не будет назначен, здесь будет RouterID 0.0.0.0 и всего вот этого у вас не будет. То есть вы сразу с помощью команды Show IPv6 Protocols поймете, что SPF у вас не запустился из-за отсутствия RouterID. Show IPv6 и SPF покажут, как именно настроен SPF, с какими параметрами, какой RouterID, какой у него референс бенвиз, какое у него количество интерфейсов в разных регионах, какое у него количество регионов, ну в общем, всякая разная полезная штука. Здесь будет иметь смысл обратить внимание на вот это вот число, как часто у вас выполняется SPF, когда он в последний раз выполнялся. Дело в том, что слишком часто оно, естественно, происходить не должно. То есть для диагностики каких-то проблем с USPF, вот эти две команды, в принципе, подходят вполне неплохо. Базовая диагностика в любом случае у нас вся та же самая. Проверяем интерфейс и соседство, и что прибежало. Вот в нашем случае Show IPv6 USPF интерфейс brief. Опять же, так же, в случае с IPv4 USPF, та же самая команда используется, показывает список соседей,

показывает, кто мы на каждом интерфейсе, показано, сколько обнаружено соседей, со сколькими из них установлены полные соседские взаимоотношения. Show IPv6 USPF neighbor показывает ID-шник соседа и не показывает IP-шник соседа. Дело в том, что нам уже не нужен IP-шник соседа, по большому счету. Нам здесь показывается интерфейс ID, и это интерфейс ID, это номер интерфейса, который у соседа будет виден вот в этой вот колонке. То есть, фактически, это используется только при сборке пазла. Мы говорим, что у нас есть два роутера, один на другой смотрит интерфейсом с номером, там, допустим, 3, другой на первый смотрит интерфейсом с номером 4. И Show IPv6 роут USPF покажут маршрут USPF с кипомичем с буковкой O, административное расстояние 110, метр К2. В общем, все то же самое, что и есть. Если хотите использовать аутентификацию в USPF V3, то нужно будет использовать либо Authentication Trailer, это дополнительная фича, которая поддерживается

только в очень новых ИОСах, и она не совсем стандартная. То есть, фактически, этот механизм будет добавлять к USPF V3 пакетам, которые, в принципе, можно подписать с помощью IPsec дополнительную TLV-шку. И эта TLV-шка, она будет как раз использоваться для того, чтобы в ней прописать, какой ключ вы используете и какой хэш вы используете. Та же самая история. Создаете ключевую цепочку, указываете криптографический алгоритм, и на интерфейсе указываем вместо IP OSPF Authentication OSPF V3 Authentication K-Chain, OSPF K-Chain. Эта штука вообще-то используется для так называемого OSPF V3 AF-мод, который мы с вами не разбираем. То есть, вот эта синтаксис OSPF V3 на интерфейсе, он специальный, особенный и используется в особенных случаях. Но, в принципе, она же работает. Эта же штука работает и с классическим режимом. Эта штука не поддерживается всеми операционными системами, поэтому с осторожностью ее используйте. Но вот если у вас новые IOS везде, новый XE, то она вполне возможно

у вас будет работать и позволит вам рулить аутентификации с помощью ключевых цепочек. Это удобно, потому что легко проводить смену ключей, легко рулить самими паролями. То есть, пароли задаются обычным плейтекстом в конфиге, и это, конечно, просто банально приятно читать. Если вы хотите использовать нативный механизм, который есть в IPv6, то аутентификация в OSPF V3 в классическом виде, она будет выглядеть, конечно, страшновато. Вы должны будете вручками сказать, какие механизмы вы хотите использовать для защиты ваших OSPF пакетов. То есть, надо будет ручками создать САшку, вы указываете номер SPI, это просто число, которое ни на что особо не влияет, но оно должно совпадать с обеих сторон. И вы указываете хэш, ну да, хэш, который вы будете использовать. Размер ключа, точнее, да. Размер ключа для выборного вам механизма хэширования.

Если вы используете MD5, то вы должны будете задать 16-байтовый ключ. Он задается в 16-ричном виде, и вот такой 1, 2, 3, 4, 5, 6, 7, 8 и так далее, это вот 16 байт. Если вы используете SECH1, то 20-байтовая строчка у вас должна в итоге получиться. Это 40 символов 16-ричных. Если вы хотите, вы можете также заказать и шифрование OSPF пакетов. Для этого вам нужно будет отдельно сказать, какой механизм хэширования вы будете использовать для цифровой подписи и какой механизм шифрования ESP вы тоже будете использовать. Опять же, вам нужно будет задать ключ. Для AESA нужно будет задать ключ 128-бит. Ну, понятно, что используется крайне редко. Можно использовать на уровне региона, то есть та же самая команда, только не IPv6, OSPF authentication, а area чего-то там authentication. На стройке роутера вы указываете, что все интерфейсы в определенном регионе должны использовать определенную SECH.

Настраивается неудобно, выглядит неудобно, нечитаемо. Если вы где-то ошибетесь в этой самой SACH-ке, ну, будет не очень здорово. Назначить SACH-ке случайным образом, прям по-честному, случайным, ну, сложно. Потому что если вы, если CISCO заставляет вас вводить вот это вот значение, она заставляет вас значение вводить ручками. И, ну, так или иначе, я думаю, что если кто-то это и использует, то у всех будет либо там 20 нулей вот здесь, вот либо 20 единиц, либо 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, либо 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, повторенные 4 раза подряд. Ну, то есть это элемент случайности здесь, конечно, такой себе очень сомнительный. Если мы хотим работать с OSPF, MVUS XR, то, в общем-то, предсказуемо все будет выглядеть. Единственное, что здесь вот написано прям, что совы не то, чем кажется. То есть команда Network, она здесь есть, но она обозначает не то, что вы можете подумать. Она обозначает тип канальной среды, тип, простите, OSPF среды по умолчанию.

То есть будет ли OSPF по умолчанию, например, воспринимать Ethernet интерфейсы как бродкастовые и, как следствие, выбирать в них LSA-юку второго типа. То есть вы можете это поведение переопределить, и команда Network отвечает именно за это. Запускаем процесс OSPF, роутер-OSPF, чего-то там. Указываем, что у нас используется роутер ID какой-то конкретный, который нам будет нравиться. Так, здесь неправильно написано, OSPF-3. Дальше. Все настройки, которые мы хотим делать, на самом деле делаются в настройке региона. То есть если у нас есть АБР, значит, у него будет два региона. Ну, конкретно на этом роутере всего один регион, Area 0. Дальше. Внутри региона мы захотим, даем настройки, что мы хотим использовать. Message Digest или мы хотим использовать вот такой вот ключик для хэш-мдпятых. И если мы захотим, мы можем включить вот такие вот интерфейсы в наш нулевой регион.

Ну, в нашем случае мы включаем интерфейс Gigabit 0.0. И используем Gigabit Ethernet 0.0.0.1. Но этот Gigabit Ethernet 0.0.1 будет пассивный. Вот эти вот настройки будут применяться на уровне региона. То есть все интерфейсы в регионе будут использовать хэш-мдпятые с ключом CISCO. А вот на этом вот Gigabit 0.0.0.1 у нас будет использоваться Authentication Message Digest с ключевой цепочкой Keychain. И, соответственно, все ключи, которые мы будем использовать, мы будем брать из этой ключевой цепочки. То есть все интерфейсы будут использовать вот эти вот настройки. А именно в настройке интерфейса Gigabit 0.0.0.0 есть какая-то настройка, которая переопределяет действие в вышестоящем контексте. Опять же, в принципе, в некоторых случаях это может быть удобно. Если вы хотите использовать OSPF V3, то выглядит все это дело абсолютно точно так же. То есть ничего не изменяется. Запускаем роутер OSPF V3. Дальше указываем номер экземпляра или имя экземпляра. Точно так же создаем настройки, точно так же указываем номера регионов.

И в OSPF V3 у нас указываются, опять же, точно так же интерфейсы. Здесь OSPF V3, OSPF V3 и так далее. То есть вот здесь вот V3 везде. И указываем, если вдруг захотим аутентификацию, authentication чего-то там и дальше. Вот параметры, которые мы используем, абсолютно точно такие же, как в случае с обычным iOS. Ну, да, бывает такое. Если захотим на интерфейсы стоимость поставить, опять же, мы указываем стоимость в субконтексте настройки интерфейса, в субконтексте настройки регионов, в субконтексте настройки роутера, в глобальном конфиге. Диагностика, вы не поверите, все те же самые команды были, которые у нас раньше, они очень похожи в iOS XR. Show OSPF интерфейс, show OSPF neighbor, show OSPF rows, show OSPF summary, все это нам, show OSPF database, lsdb показать, это все оно здесь есть. Это речь идет именно про OSPF второй версии.

Если мы хотим OSPF третьей версии, show OSPF V3. В CISках, в CISке iOS можно использовать в OSPF V3 два разных адресных семейства, адрес FamilyIPv4, адрес FamilyIPv6. В OSXR OSPF V3 работает только с адресным семейством IPv6, поэтому там не надо указывать, что вы хотите IPv4 или IPv6. Давайте попробуем это дело понастраивать. Поскольку здесь у нас все будет довольно быстро, я думаю, что задача здесь несложная. CISCO, CISCO, CONVT, NO ROUTER EGRP, 65.001. Убили EGRP, прибили и добавили роутер OSPF. Я люблю роутер OSPF1. По большому счету здесь можно его именованный контекст сделать, и он будет абсолютно любым. AREA 0. theaters еж deniedha. Interface has 0.0.0.0.0.0.0.1.

In terrace lookback 0.0.0.0.0.0.0.1.0.0.3. Все, OSPF завелся. Аналогичное действие с другой стороны. так и был он т но и g rp 65 0 1 роутер роутер успf 1 так здесь большому счету ничего не надо делать интерфейс гигабит 0 гигабит 1 айпи usbf 1 0 интерфейс лутбак 0 айпи usbf 1 соседство установилось так соседство установилась даже с кем-то еще через 10 200 203 интересно ну ладно установился ладно и проверяем что в итоге получилось айпи usbf интерфейс из простыня шайки успех интерфейсов бриф красивая

табличка у нас включился успех на двух интерфейсах люббек 0 и гигабит 1 на гигабите 1 мы помимо всего прочего еще и дрозер то есть ну окей хорошо с двумя соседями установлены полные соседские взаимоотношения видим это вчера позавчера мы поднимали на и у ся обычном или на свече успех для того чтобы показать 30 3 будет ну вот судя по всему это она шоу айпи usbf neighbors вот они два соседа один дэр другой бдр шоу айпи usbf датабейс покажет нам лосейки которые есть все у нас в одном регионе регион номер 0 показывается 3 лосейки первого типа и 1 лосейка второго типа и шоу айпи usbf раут это показывает какие маршруты usbf просчитал вот он нашел что у нас в сети есть три роутера и

3-е роутера они соответственно знают про какие-то маршруты вот каждый из них знает про один хороший маршрут через который мы хотим работать сетка 10 0 0 0 по 24 маски это сетка connected она лучше всего доступна будет через нас самих сетка 10 1 1 1 тоже connected она доступна будет через айпишник 10 1 1 1 тоже через нас самих и 10 2 2 2 по 32 маски эта сетка интро и то есть она в нашем регионе будет доступна за две копеечки через соседа 10 0 2 доступного по интерфейсу гигабит первому шоу айпи раут успев покажет что у нас есть один вот этот вот маршрут который смог добавиться в таблицу маршрутизации из трех маршрутов категоs теперь нам посчитал два connected до то есть они уже в таблице маршрутизации есть и добавить их таблицу маршрутизации еще раз не получается успев при своем мистративном расстоянии 110 резко проигрывают конima от маршрутом у которых административное расстояние 0 поэтому

он посчитал зря но тем не менее они есть его то бы посчитал а вот этот маршрут он смог добавить цапли часов и зации и тот факт что он смог добавить естаблицы маршрутизации отображается Вот это вот птичкой. На XR у нас тоже что-то сейчас произошло. Давайте посмотрим на это. Show OSPF interfaces. Интерфейс brief. Вот они, два наших интерфейса. На лутбеке все включилось, на гигабите все включилось. На гигабите у нас мы BDR и у нас два полноценных соседства. Так, дальше. Show OSPF neighbors. Вот они, два наших соседа. 10.1.1.1, который D-Rather и 10.1.1.1, который D-Rather.

С каждым соседом мы нормально дружим. IPшники у них вот такие вот. Обратите внимание, вот здесь вот показывается IDшник, здесь показывается IPшник. Это две разные сущности. И далее посмотрим, что у нас там нам присылали. Они show IP OSPF database. IP OSPF, господи. Три LSA. Три LSA первого типа, одна LSA второго типа, которая соединяет всех троих в единую сеть. В принципе, можно даже посмотреть, что там внутри у нее написано. Па-па-па-па-пам. Network. Detail. Он так сожрет? Не сожрет. Надо IDшник указать. Вот наша любимая LSA. То есть, это LSA, отвечающая за связь между тремя роутерами. И она говорит, ко мне подключены три роутера с IDшником таким, с IDшником сяким, с IDшником вот этим вот.

Придумал ее роутер с IP-адресом DR-а 10.0.0.3. То есть, DR у нас 10.0.0.3. В принципе, согласуется с тем, что мы видели. И show ospf rib, кажется. Нет, show ospf. Па-па-па-па-па-пам. Как-то здесь роутс. Показывает, какие маршруты ospf просчитал. То есть, это до того, как он вбросил их в таблицу маршрутизации. Он показывает то же самое, что show ip ospf road. Что у нас есть три маршрута, которые известны по ospf. Вот этот вот маршрут connected, вот этот маршрут connected, и этот маршрут, прибежавший издалека от соседа 10.1.1.1. Все три пытаются вброситься в таблицу маршрутизации, но двум из них не повезет. Show road ipv4 ospf. Вот он наш ospf маршрут. До сети 10.1.1.1 по 32 маске через соседа 10.0.1.

Если вдруг мы захотим сделать абэра, никаких проблем. То есть, вместо show run router ospf, вместо того, чтобы интерфейс loopback'а заносить в нулевой регион, мы можем его перенести в первый регион. У нас роутер превратится в абэра, будет генерировать лосейки третьего типа, четвертого типа, если будут пятерки, и так далее. Так, ну и, наконец, что у нас там следующее? ISIS по плану. Если говорить про настройку ISIS, то ситуация будет с ним следующая. Мы можем, по большому счету, настраивать его очень и очень экзотическими способами. Можем указывать, что там есть несколько регионов. Между ними надо перекладывать LSP-шки делать, которые будут указывать там на этот самый флаг оттачит и прочее, прочее. Но, если использовать ISIS в том виде, в котором он используется реально,

то в подавляющем большинстве случаев, если кто-то ISIS запускает, то запускают его все в одном регионе. Дело в том, что, если говорить про то, зачем ISIS нужен провайдерам, он нужен как просто абстрактный некоторый протокол link-state типа. У нас таких протоколов link-states есть два. OSPF и ISIS, соответственно. Они используются провайдерами чаще, чем какие-либо другие протоколы IGP, потому что, если у вас есть несколько роутеров, работающих в одном регионе, то роутеры, которые будут по-честному строить топологию между собой, они могут дополнительно к этой топологии добавить чего-нибудь еще. Вы можете в OSPF, например, положить APAC-U-LSA и в этих APAC-U-LSA закодировать то, например, сколько у вас проектируемая полоса пропускания есть в интерфейсах и сколько от нее уже зарезервировано. В случае с ISIS вы можете это сделать не с помощью APAC-U-LSA, а с помощью TLV. То есть вы выпускаете LSP, говорите, я смотрю вот таким интерфейсом

на такого-то соседа, и я на интерфейсе в этом соседа резервирую определенную полосу пропускания. Это все происходит в одной и той же LSP. Как следствие, получается, что если у вас все работает в одном регионе, то вы можете использовать всякие разные няшки, в том числе и очень-очень нужные для, например, того же самого MPLS traffic engineering. Ему не нужно будет, чтобы вы делали какую-то сложную топологию OSPF или сложную топологию ISS. Для него все нужно будет максимально просто сделать. Ему нужно будет все задать в один регион, сделать, чтобы лукбеки ходили по OSPF, и все, больше нам ничего не надо. Та же самая история с ISS. Если вы поднимаете для провайдерских задач, он в подавляющем большинстве случаев работает в одном регионе. И если это говорить про один регион, вы можете сделать ISS, который работает только в регионе Level 1, либо в одном регионе Level 2. Level 2 намного проще, потому что у него нету требования к одинаковым номерам или ID. То есть мы загоняем все роутеры

в один регион L2, и этого более чем достаточно для корректной работы. Чтобы заставить роутер работать через ISS, реплицировать таблицы маршрутизации IPv4, IPv6, и не суть важная, у него все равно какая-то полезная нагрузка, так или иначе, с помощью ISS мы будем использовать следующие команды. Сначала запускаем на iOS обычный процесс роутер ISS, и дальше даем ему некий номер. Можно не давать номер, просто сказать роутер ISS, он его запустит, ну, если хотите, без номера. Я не помню, это вообще работает? Нет. По-моему, должно работать. Просто роутер ISS без ничего. Ну, по-моему, должно. Сейчас проверим. Дальше. Нужно будет сказать, что ваш роутер – это роутер только второго уровня, то есть это не Level 1, Level 2 роутер, как по умолчанию все происходит. Вы указываете IS-Type, Level 2 Only. Вы тем самым говорите, что ваше Intermediate System –

это Intermediate System, который не АБР, не обычный роутер, который находится внутри первого региона, это только роутер второго региона. У него не может быть соседств Level 1, Level 2. Не может быть соседств Level 1, у него все соседства будут Level 2. Дальше. Вы указываете, с какими адресными семействами ваш роутер готов работать. Это, в принципе, не обязательно, но можно указать адрес Family IPv4, Unicast, адрес Family IPv6 Unicast, и вы указываете тип метрик, который вы хотите использовать. Метрик Style Wide чаще всего бывает нужен, то есть, если вы забыли, IS-S использует метрики до 63 на интерфейс и до 1023 на весь маршрут, на весь путь. Ну, соответственно, этого не очень много, и в некоторых случаях нам необходимо будет, вам в обязательном порядке будет нужно переключать стиль метрик на широкий, в том числе, например, как раз при использовании IS-S с MPLS. Там метрику Style Wide надо ставить обязательно.

И вот это вот все, что вы хотите сделать с точки зрения, скажем, настройки вашего роутера. Кроме настройки, вам нужно будет сказать, что некоторые интерфейсы у вас будут регулироваться с MPLS, ASS. То есть, если мы говорим, что у нас есть, например, гигабитный интерфейс, гигабит 0.0, мы говорим на нем IP-роутер SS1, значит, IP-шные маршруты с этого интерфейса попадают в таблицу LSDB. Более того, по этому интерфейсу возможно установление соседства с соседним роутером, который тоже на нас смотрит, интерфейсом, на котором тоже включен IP-роутер SS. Ну, аналогично можно сделать с IPv6-роутер SS. И мы указываем, какая стоимость будет у этого интерфейса, ASS, метрик, ну, какая-то там метрика. ASS метрик 100 намекает на то, что мы как раз использовали широкий стиль метрик, потому что на нормальных метриках мы такую метрику назначить не можем. И все, что я вам рассказал до сих пор, наверное, у вас

не вызвало никаких странных реакций, никакого отторжения. Но вы могли заметить, что я умолчал про вот эту страшную штуку. И вот эта страшная штука, она как раз определяет то, как будет работать ваш роутер. Это адрес. Команда нет, не путать с командой нетворк. В ASS ее нету, но начинается она с тех же самых нет, которые есть в RIP, в EGRP, в SPF и даже в BGP есть, но хотя она там совсем другое делает. Здесь нет, это не нетворк, это просто нет, Network Entity Title. вы указываете адрес вашего роутера ASS, ваша Intermediate System. Он состоит, если вы помните, из сначала типа региона, 49, всегда 49, никакие другие варианты мы туда не хотим ставить. Дальше, двухбайтовый код региона, это любое число, которое вы захотите, в принципе, можно сделать все, что угодно, ну вот, например, 0 туда поставить. Дальше, шестибайтовый System ID, можно сюда записать

MAC-адрес, можно сюда записать IP-шник в той форме, которую я вам рассказывал, что если у вас IP-шник 192.168.1.1, то вы говорите, каждый вот этот октет, это три цифры, 192.168.00.1, 0.01, то есть 192 уехал сюда, 168 уехал сюда, 1 уехал сюда, 1 уехал сюда. И у нас получается таким образом шестибайтовое число. Можно воспользоваться таким механизмом. Вот он, System ID. Если предположить, что он был сгенерирован по такому принципу, то здесь был IP-шник 10, 2, 1, 1. Может быть такой, может быть какой-то еще. Единственное, что требуется от System ID, быть уникальным в пределах всей основной системы. То есть это будет только важно, все остальное не важно. И в конце то, что делает указанный NSAP именно Net. То есть

это всегда 0. Вот такую вот хреновину вам нужно будет составить. Вам нужно будет убедиться, что она уникальная в пределах всей автономной системы. И запускаем. если у нас есть два роутера, вот мы берем, говорим, у нас есть раз роутер, два роутера. На один назначаем какой-то адрес с уникальным системой ID, на другой назначаем уникальный адрес с уникальным системой ID. Включаем ASIS тут, включаем ASIS здесь. Все. Оно работает. После того, как оно заработает, можно будет посмотреть соседство. Соседство смотрится немножко дурацкая команда, я здесь ее забыл указать. Show CLNS Neighbors. То есть у вас соседство будет не с точки зрения ASIS, а с точки зрения CLNS. И в результате установления соседства у вас роутеры обменяются LSP-шками, эти LSP-шки попадут в базу. Вот нам покажут, какие LSP-шки есть, LSP-ID. Если есть LSP-шка, придуманная самим

роутером в одном регионе с нами, то показывается вот ее ID-шник. Свежая версия IOS автоматически заменяют начало LSP-шки, LSP-ID именем того роутера, который они ее придумали. То есть там в начале идет вот этот вот самый net, вот эта вот штука системы ID, того, кто придумал эту LSP-шку. И IOS, чтобы не городить огород с длинными-длинными-длинными именами, автоматически вместо системы ID ставит хост-нэйм этого соседа. Дальше. Если вы хотите посмотреть на то, что содержимое там есть, там, конечно, есть ShowISIS Database Detail и так далее, но нас сейчас это не сильно интересует. Наша задача убедиться, что в базе данных чего-то от соседа прибежало. Дальше ShowIP Road ISIS показывает, что у нас какие-то маршруты из ISIS-овской базы попали в таблицу маршрутизации. ISIS-овские маршруты показываются маленькой буковкой I.

Дальше L1 или L2 это какого уровня эти маршруты, как мы их узнали, в каком регионе, в какого типа. Ну и какая сетка, какое административное расстояние 115, сколько стоит такой маршрут, ну там 20 копеек, окей. Кто прибежал, точнее, кто NextHop и через какой интерфейс оно будет доступно. Если мы работаем с EOS XR, то настройка прям похожая, то есть мы запускаем контекст router ISIS чего-то там, указываем там какой-то network identity title, указываем, что наша Infirmidia System будет только второго уровня, и если мы запускаем адрес family IPv6 и не каст, то внутри в нее мы можем сказать адрес metric style wide. Можем одновременно несколько адресных семей запустить. Ну вот здесь показан только IPv6, если запускаем IPv4, как вы понимаете, все то же самое. И дальше из контекста роутера,

простите, config.ss указываем, что у нас интерфейс gigabit 0000 работает в этом самом SIS. Давайте попробуем это дело настроить. То есть у нас опять же наши роутеры есть сейчас, на которых уже настроены все IPшники, осталось там только включить соответствующие процессы динамической маршрутизации. Cisco, Cisco, ConfT, NoRouter, OSPF1. С одной стороны убили, с другой стороны сейчас тоже убьем. ConfT, NoRouter, OSPF1. Убили OSPF и настраиваем ASIS. Роутер ASIS. Вот, я сказал, что можно без номера и да, я не ошибся, действительно можно без номера.

Так, в принципе, по большому счету достаточно здесь будет указать только Net, Network Entity Title. и этот Net должен быть таким, чтобы System ID в нем был уникальным. Окей, Net 49, тип региона всегда 49, дальше, номер региона, неважно какой, мы делаем L2 регион, на номер региона можно не обращать внимания. Дальше, указываем System ID, это у меня роутер с IP-шником 1001, я указываю 010, дальше 0.01, дальше 00.1, так, не угадал, 0,0,0, вот так вот, то есть это у меня IP-шник 10, 0, 0,1, и дальше в конце должен быть всегда 2,0, то есть вот такой вот Network Entity Title

будет обозначать, что я работаю с типом региона 49, вот он, с кодом региона 0,0,0,0, с System ID 6-байтовым, в котором с использованием очень хитрая схема закодирована IP-шник 10,0,0,1, и NSubSelector 0,0, который всегда 0,0, заодно metric style wide и заодно ES type level2 only указываю, что я всегда буду только работать с регионом 2-го уровня. Затем на интерфейсе нужно будет сказать, что IPv4 адресация этого интерфейса нам нужно будет включить в LSP-шку. Интерфейс loopback 0 IP router ESS и на интерфейсе, на котором мы хотим подружиться с соседом gigabit 1 IP

router ESS. Если мы не укажем level2 only, у нас роутер будет работать в режиме L1-L2, то есть он будет и level1 базу реплицировать, и level2 базу реплицировать. По большому счету ничего страшного не будет, но просто у нас одна и та же LSP-шка будет известна и в первом, и в втором регионе. Он использует первый регион. Ну, то есть вы для... Все равно при этом должны будете следить за тем, чтобы у вас коды регионов совпадали. Для первого уровня регионов важно будет контролировать вот этот вот самый код региона, который будет после 49 идти, чтобы роутеры, которые находятся в единой непрерывной части с одной стороны, роутеры, которые находятся в единой непрерывной части с другой стороны, получали бы свои собственные уникальные коды регионов, которые бы правильно соответствовали положению в системе. Чтобы не париться с раздачей вот этих вот кодов региона, потому что там есть сложности с этим, мы указываем level 2 only и не паримся с номерами.

То есть какие есть, какие такие есть. Они там любые могут быть. Мы просто говорим. В любом случае она будет работать. Так.