Знакомство с Cisco IOS XR

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

В отличие от EOS, который единый, монолитный, и вот если вы купили какой-то EOS, в нем есть сразу все, что только может заблагорассудиться. С 15 EOS обычного там появился механизм лицензии, то есть у вас как бы EOS идет с какими-то функциями, но не часть из функций заблокирована. И вы можете взять, вставить лицензию, и у вас разблокируется определенная функциональность. Но при этом как бы сами функции в операционке при этом присутствовали. В EOS вы можете натурально поставить операционную систему, а потом до нее доставлять пакеты с нужной вам функциональностью. То есть это не то, что раньше это нельзя было делать, потому что вы денег не занесли. А сейчас вы денег занесли, и стало можно. Нет, в EOS XR это именно вы можете установить пакет, и дальше этот пакет у вас позволит вам выполнять какие-то новые действия, которые раньше были недоступны. Есть модули, которые идут в обязательном порядке и обеспечивают этим модулем базовую работу операционной системы. И есть модули, которые вы можете доставить, если они вам нужны, а можете и не ставить, если они вам не нужны.

Все, в любом случае, процессы, все вот эти модули, они абсолютно обособлены. Сбой в одном из этих модулей на другие модули никоим образом не повлияет. Более того, многие вещи, которые в операционной системе есть, они зарезервированы. То есть, если у вас какой-то процесс выходит из-под контроля, то он убивается, и на его месте запускается его брат-близнец, но только подконтрольный. В отличие от EOS обычного и EOS XE, есть вещи, которые у вас в операционной системе может быть и присутствуют, но вы их не используете. И поэтому эти вещи не занимают память, не занимают ресурсопроцессора, потому что в концепции EOS XR то, что вы сейчас не используете, не подгружается. То есть, концепция динамически подгружаемых библиотек в этой операционной системе реализована сполна. Это камень в огород тылуса обычного, в котором, если у вас есть условный OSPF, вот он в полудохлом состоянии, но у вас постоянно запущен, даже если вы его не используете. Вы можете не использовать условный ASIS,

но он у вас все равно в полудохлом состоянии есть. EOS XR говорит, что если вы не используете что-то, то это вам не нужно, и у вас он вообще никоим образом не задействован, не использует никакие ресурсы. Поскольку все процессы изолированы между собой, сбой в одном процессе не может повлиять на все остальные процессы. Опять же, это камень в огород EOS, где процесс, который неаккуратно записал чего-нибудь в область памяти другого процесса, мог катастрофический сбой на самом деле вызвать. В XR это невозможно. Любое взаимодействие между процессами допустимо только через вызовы своего рода API. То есть у вас есть межпроцессное взаимодействие, и один процесс может вежливо попросить в рамках некоторого протокола, другой процесс выполнить определенные действия. Вам нужно, чтобы OSPF отдавал по SNMP указание, что он запущен. Окей, OSPF процесс дергает SNMP процесс, говорит, я запущен. SNMP говорит, я понял. Кладет в свою память какое-то значение.

Только так. Никаких уже прямых вызовов к памяти чужого процесса недопустимо. Более того, помимо всего этого, вы можете в рамках операционной системы iOS XR запустить на самом деле несколько комплектов, несколько виртуальных экземпляров роутера, каждый из которых получит свою какую-то обособленную функциональность. И эта штука будет называться Secure Domain Router. Вы можете изолировать экземпляры операционной системы, которые у вас запущены в рамках одной железки. То есть железка одна, а XR на ней запущено две. Но один из этих XR настоящий, а второй он такой виртуальный. И вы можете выдать кому-то из... какому-то, допустим, сотруднику доступ к своему экземпляру роутера, но этот роутер будет виртуальный. И он все равно сможет рулить этим роутером абсолютно так же, как если бы он рулился настоящим боевым роутером. Но при этом он будет ограничен теми ресурсами, которые вы ему дадите. Представьте себе ту самую огромную железную дуру на 1152 линейные карты.

То есть если бы это была одна большая дура на 1152 линейные карты, по 50 портов каждой, это было бы 50 тысяч портов, в ней невозможно было бы разобраться. А главное, вы бы никогда, на самом деле, столько портов на одном роутере не собрали бы, чтобы им действительно пришлось рулить бы в пределах одного устройства. Но вы можете, в принципе, встретить ситуацию, при которой вам нужно взять и большое количество портов разделить на несколько своего рода групп. И каждой группой портов управляют свои администраторы, свои инженеры, своя группа инженеров. И в этом случае вы можете сегментировать ваш физический роутер на несколько не пересекающихся логических роутеров, ну, примерно как VRF. Вот у нас есть VRF, виртуальная таблица маршрутизации, отдельная, обособленная всего. И в этой таблице маршрутизации крутятся там свои маршруты. То же самое, только на более высоком уровне. У вас изолированы не таблицы маршрутизации, получается, а изолированный роутер целиком, прям отдельный комплект роутера. У него свои интерфейсы, никоим образом не пересекающиеся, свои все.

И ваш администратор может изойти на свой экземпляр роутера, но не может повлиять на другие экземпляры, которые запущены на той же железке. Штука эта называется Secure Domain Router. И вот если вы хотите дать одной группе администраторов доступ к каким-то возможностям вашего роутера, но не хотите давать доступ целиком ко всему роутеру, потому что другие клиенты, другие сервисы, сервисы, возможно, будут влиять на работу этого инженера или напротив этого инженера, может повлиять на какие-то другие сервисы. Вот вы боитесь. Вот вы в этом случае нарезаете ваш большой роутер на несколько маленьких кусочков и администратор даете полный доступ, но к своему отдельному маленькому кусочку. Еще раз подчеркну, это не та же самая штука, которая, например, в обычном ИОСе мы можем сказать, я тебе даю право рулить интерфейсом номер один, я тебе даю право рулить интерфейсом номер два, но я тебе не даю право рулить интерфейсом номер три. То есть в этом случае мы его ограничиваем по правам, но он все равно может видеть, что такой интерфейс есть,

там интерфейс номер три, да, он к нему не может получить доступ, но он не может его проадминить, возможно, он не может выполнить команду там show interface, но при этом он все равно знает, что этот интерфейс существует. В случае, если вы делите большой роутер на отдельные вот такие вот секвердомайн роутеры, то вы в экземпляр виртуального роутера демонстрируете вообще теоретически только те ресурсы, которыми инженер-администратор может распоряжаться. В принципе, в других цисковских операционных системах тоже такая же штука есть. В Nexus это называется VDC, Virtual Device Context, а здесь вот Secure Domain Router. Так. Как уже было сказано, все, что только можно зарезервировать в этой операционной системе, все зарезервировано. На роут-процессоре все процессы, которые запускаются, они запускаются на самом деле дважды. То есть, если у нас есть желание запустить там условный процесс BGP, то мы запускаем два экземпляра BGP, один настоящий, второй на всякий случай. Если вдруг у нас обнаруживается сбой

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

с, ну не знаю, с тем же самым SNMP. То есть он сообщает, я зажегся. И если у нас этот самый OSPF дохнет, идет переключение на запасной процесс, который становится активным и запускается параллельно запасной, то вот этот вот самый процесс SNMP, с которым шло взаимодействие, он не должен каким-то образом узнать про то, что у нас случилось, случился перескок на другой запасной процесс. Поэтому у нас на самом деле запускается прокладка. SNMP взаимодействует с прокладкой, а прокладка уже взаимодействует с активным процессом. Если активный процесс дохнет, то прокладка переключается на запасный процесс. Вот эта вот прокладка будет называться QNET Simlink Manager. Вряд ли вам это понадобится когда-то в реальной жизни, я думаю, но тем не менее в экзаменах на это могут быть вопросы. Вторая штука, которая здесь будет нужна, это штука, которая будет мониторить состояние процессов, и в случае, если она будет обнаруживать падение, катастрофическое падение процесса или что-то, что может повлиять на его работоспособность, это вот именно она будет перестреливать один процесс

и переключать фокус на другой. Она будет называться Event Connection Manager. Так. Дальше. Если у нас есть операционная система EOS XR, вы можете встретить разные версии этой операционной системы, равно как и EOS, допустим, он тоже бывает разных версий. Есть там 15.0.1, 15.1.20, не знаю. Короче, разные версии операционной системы. Естественно, что в тех версиях, которые CISC выпускает, рано или поздно обнаруживаются ошибки, рано или поздно есть у CISC желание какие-то новые фичи внедрить, поэтому выходят все новые и новые операционные системы. Но это как бы все равно операционная система CISC EOS, просто есть более старая, более новая. CISC EOS XR та же самая штука. И на экзамене будут вопросы про нумерацию этих версий и про управление жизненным циклом EOS XR. Следовательно, вот то, что на слайде есть, вам придется на экзамен донести, не расплескав. Первое.

Понятное дело, что вот этот вот самый номер версии, ну, к примеру, да, 330. На самом деле сейчас актуальная версия, там, шестая, но, тем не менее, да, 330, достаточно старый EOS, но, тем не менее, он когда-то был. Вот он состоит из трех цифр, разделенных точками. Первая цифра — это мажорный релиз, основной, как бы, трейн, как мы считаем, что этот EOS будет называться. Ну, вот если у нас версия 3.3.0, мы понимаем, это EOS XR версии 3. Если у нас там 6.0.1, это EOS версии 6. Дальше вторая циферка — это минорный релиз, и третья — это maintenance релиз. Если вы выпускаете, ну, вы получаете от циски новую версию операционной системы, вы можете взять и примерно прикинуть, как именно ваша текущая операционная система отличается от операционной системы, которую вам предлагают. Если у них там мажорный релиз одинаковый, то, значит, изменения там, ну, сравнительно небольшие, как правило, косметические,

или, возможно, какие-то новые мелкие фичи добавили, но ничего принципиально нового не произошло. То есть, допустим, если у нас есть неисправление, а более новая версия операционной системы, там, 3.3.0, 3.4.0, ну, мы понимаем, мажорный релиз одинаковый, минорный релиз немножко отличается. Ну, вот в 3.4.0 по сравнению с 3.3.0 добавили там чего-то там вот, добавили L2 VPN и улучшили L3 VPN за счет механизмов Inter-AS и Carrier Support and Carrier функций. Ну, соответственно, если мы видим, что у нас операционная система какой-то одной версии, а нам Cisco предлагает другую версию, и отличается первая циферка, то, значит, изменения мажорные, изменения существенные, возможно, какие-то новые платформы добавились, возможно, какие-то новые принципиальные фичи добавились, то есть что-то сильно изменилось. Как правило, для установки мажорного, нового мажорного релиза требуется рестарт. То есть очень маловероятно,

что вы накатите там на пятую версию L6R шестую и сможете обновиться без ребута. Скорее всего, ребут потребуется. Для обновления минорного релиза обычно ребут не нужен. Есть еще такая штука, как Maintenance Release. Это вот последняя циферка. Это исправление ошибок и какие-то очень мелкие фичи, то есть чисто косметические, никак не влияющие на работу системы. Эта штука называется Maintenance Release. Они, как правило, никогда не требуют рестарта. То есть если вы понимаете, что у вас как-то циска работает не очень хорошо после апдейта, вы можете взять, посмотреть, и, возможно, на ту операционную систему, которую вы поставили, уже есть новый Maintenance Release, который исправляет те ошибки, которые были внесены на предыдущем этапе. Maintenance Release выходит раз в 4 месяца или по случаю, если будут обнаружены какие-то прям колоссальные ошибки, которые надо исправлять срочно. То есть если что-то прям катастрофичное нашли в новой версии минорного релиза, то, значит, выходит Maintenance Release сразу. По плану Maintenance Release выходит пачкой,

выходит раз в 4 месяца, и на Maintenance Release выпускаются пачки обновлений, которые закрывают косяки, обнаруженные на предыдущем этапе. То есть, условно говоря, у нас есть там релиз 3.4.0, вот через 4 месяца мы можем ожидать, что будет Maintenance Release 3.4.1. Там еще через 4 месяца. Можем, в принципе, ожидать там 3.4.2, например. А может быть, не будет. Каждые 8 месяцев выходит новый большой релиз, то есть либо мажорный, либо минорный. То есть, там, если у нас есть версия 2.0.0, то вот через 8 месяцев можно ожидать 2.1.0. Там еще через 8 месяцев 2.2.0. Может быть такое, что 2.2.0 уже не придет. Может, придет уже сразу 3.0. Так. Будут вопросы на экзамене определенно про время, которое проходит с момента выпуска операционной системы до момента выхода из какого-либо обращения этой самой операционной системы.

Время, когда начинается жизненный цикл релиза, будет называться CCO. То есть, это тот момент, когда новый релиз, новая операционная система, новая версия загружается на сайт CISCO. Вот, начиная с этого момента, проходит некоторое время, и через 6 месяцев после того, как объявлен новый релиз, как его начинают пользователи иметь возможность загрузить, объявляется время, когда этот самый релиз выйдет из продажи. Announce EOS — это как раз время, как правило, CISCO говорит, что через год мы этот релиз перестанем продавать. End of Sale обычно случается через полтора года после выкладывания EOS на CISCO портал. Дальше. То, что EOS больше не продается, не означает, что на самом деле с ним уже все закончено. То есть, если вы его успели купить, дальше вы можете с ним работать. Через 6 месяцев после объявления End of Sale

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

она может все равно выпускать какие-то, допускать какие-то изменения в этот самый EOS, какую-то поддержку по нему оказывать, если захочет. Но если не захочет, она, соответственно, это делать не обязана. И спустя 6,5 лет после объявления начала продаж, то есть спустя 78 месяцев объявляется фаза End of Life, начиная с этого момента, на любые попытки обратиться в CISCO с предложением каким-то образом вам помочь с вашей CISCO очень-очень древней, CISCO скажет, нет, идите нафиг совершенно точно. То есть End of Life – это вообще, такой штуки больше не существует, все сдохло, стюардессу надо закопать. Так, скорее всего, если будут вопросы, то вопросы будут на тему того, вот когда объявляется End of Sale, когда объявляется End of Maintenance, то есть это вот все происходит там с определенными промежутками. Так, если у нас есть операционная система CISCO EOS XR,

то мы можем этой операционной системой управлять. На самом деле, вот когда мы покупаем железку, мы покупаем не для того, чтобы сказать, «У, какая клевая железка», а для того, чтобы на нее посмотреть и сказать, «Да, это железка, которую мы можем настроить, так, чтобы она выполняла наши задачи». Управление EOS возможно с помощью консольки, как ни странно, то есть командная линия, командная строка, command line interface. Вы можете получить к ней доступ несколькими разными способами. Первый способ получения доступа к командной строке – это подключиться через консоль. Обычный банальный RS-232. То есть вот у нас консольный порт на супервизоре, на роут-процессоре. Вы в него втыкаетесь обычным классическим голубеньким SmartCon и получаете обычную нормальную консоль. Вот у нас сейчас доступ к нашим устройствам как раз через консоль и организован. В принципе, есть два порта, которые RS-232 на роут-процессоре. Один консольный порт, второй, который будет называться AUX.

Это точно такой же RS-232, но в нем закручены гайки в части безопасности. На железках обычно роут-процессоров два. И вы можете подключиться только к тому, который активный. Если вы пытаетесь подключиться к консольке к неактивному роут-процессору, который запасной сидит на подхвате системы, ну, будет ругаться и говорить, что этот роут-процессор не согласен вас обслуживать. Ну, в этом случае вы берете, вытыкаете консольный провод из одного, роут-процессор втыкаете в другой, там все будет хорошо. Альтернативный вариант получения доступа к командной строке — это подключиться по VTI, то есть по TELNET, SSH или любому другому протоколу удаленного управления, который вас устроит, на айпишнике вашего роут-процессора. Айпишники на самом деле бывают разные. Во-первых, начнем с очевидного. У нас роут-процессоры подключаются двумя разными портами часто. То есть у нас есть LAN-1 и LAN-2, менеджмент LAN-1, менеджмент LAN-2. Это оба порта управления, вы можете подключиться в любой из них,

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

вы получаете доступ к пользовательскому режиму. У вас приглашение к поводу заканчивается на птичку. Дальше вы пишете enable, вводите пароль на enable, попадаете в привилегированный режим. И получается, как бы, что вы два раза сделали работу по вводу пароля. Вы сначала показали, какой пароль у вашей учетной записи, а потом вы показали, что вы знаете пароль на enable, который позволяет вам перейти в привилегированный режим. И это, ну, в общем, достаточно глупая какая-то концепция, она нелогичная. И в любом случае, если вы пользуетесь какой-то системой централизованного управления, то вы, как правило, прописываете права на пользователя все равно отдельно. То есть, если вы там пользуетесь локальной базой пользователя, вы все равно на юзера прописываете там username Cisco, privilege 15, паспорт Cisco. Это условно. Если вы на радиусе храните, то вы атрибут выдаете, какой уровень привилегий отдавать для пользователя, чтобы пользователь сразу в решеточку входил, чтобы он показывал только свой логин и пароль и больше никогда не вводил никакие другие пароли. Ну, и получается, что вот эта вот концепция пользовательского привилегированного режима в обычном iOS,

она какая-то скверная. В iOS XR от нее избавились, то есть вы вводите логин и пароль, вы получаете доступ сразу в режим, ну, в кавычках, привилегированный. Понятное дело, что этот привилегированный режим, он будет ограничен по возможностям тем, что вам разрешено делать с операционкой. Но, тем не менее, вот там нет специального отдельного процесса, покажи еще один секретный пароль. Приглашение к каводу будет сразу с решеточкой, и оно будет немножко непривычное после Cisco iOS. Оно будет указывать, куда вы подключились. То есть вот это вот приглашение к каводу, оно указывает, что вы подключились к роуд-процессору, здесь всегда RP. Дальше показывается номер шасси. Если у вас, опять же, система многошассишная, то показывается там, какая стойка у вас, условно говоря. Дальше показывается, к какому роуд-процессору вы подключились. RP0, это, ну, здесь RP0 называется, может быть, RSP0, может быть, RSP1, то есть это просто название роуд-процессора, к которому вы подключились.

Учитывая, что в системе, как правило, этих роуд-процессоров два. Есть железки, у которых один роуд-процессор, там будет просто стоять RP0. И если у вас есть несколько процессоров, несколько систем на роуд-процессоре, которые можно будет управлять, то есть это либо сам вот роуд-процессор, либо ESP, то здесь показывается то, чем вы управляете прямо сейчас в рамках роуд-процессора. CPU0 показывается, что вы работаете с обычным IOS, с обычным экземпляром операционной системы. То есть это не какой-то специализированный процессор, которым можно будет рулить. Дальше через двоеточие показывается имя железки, то есть здесь уже что-то напоминающее обычный IOS, хостнейм устройства, решеточка и дальше обычная командная строка. Вы можете выполнить привычные вам команды, там, show version, и посмотреть на то, что система вам выдает. В принципе, в некотором смысле, команды, которые в XR существуют, они каким-то образом похожи на IOS. То есть если вы привыкли работать с командами в Cisco IOS,

вы в XR, ну не то, что будете себя чувствовать вольготно, но вы примерно поймете логику, наверное, того, как команды могут выглядеть. Потому что в большинстве случаев команды, которые настраивают IOS XR, похожи на команды, которым настраивается IOS. Но логика этих команд будет, однако, другой. Мы про логику и настройку поговорим сейчас на следующем слайде. Если вы просто входите в систему, то есть, например, подключаетесь консолькой RS-2032, входите в систему, система говорит, скажи пароль и проходи, вы вводите логин и пароль. На наших железках, например, используется штатная комбинация Cisco-Cisco. Если вы указали правильный логин и пароль, то система пускает вас в решеточку. То есть, обычный режим, решеточка, exec. То есть, уже никакого пользовательского режима User Mode нет. Дальше вы можете выполнить команду Configure. Это бывшая команда Configure Terminal. Ну, то есть, если вы хотите, вы можете набрать Configure Terminal, система это сожрет. Но вообще просто конфигуре достаточно. И вы попадете в Config.

Config. Дальше в этом конфиге вы можете переходить в настройки каких-то подмодулей. То есть, допустим, вы можете взять и перейти в настройку интерфейса. Скажете там интерфейс, гигабит, чего-нибудь. И вам система перейдет в субконтекст Config. Ну, привычная нам по IOS-у концепция. И бывают контексты, которые вложены друг в друга. То есть, сначала зашли, как в IOS-е было, классический такой слайд, как настройка ключевой цепочки. Зашли в ключевую цепочку, зашли в конкретный ключ, настроили ключевую строку для конкретного ключа в конкретной ключевой цепочке. У нас вот здесь приглашение к ководу будет. Там конфиг чего-то там, чего-то там, чего-то там. Ну, с этим все понятно. Здесь вся логика такая же, как в обычном IOS-е, но есть нюанс. Есть такая штука, как Secure Domain Router. Те самые контексты, комплекты, виртуальные экземпляры IOS XR, которые запущены в рамках одного устройства. Если вы позволите управлять своим маленьким комплектом

какому-то человеку, какой-то группе администраторов, то есть они в пределах своего комплекта могут делать все, что угодно. Но возникает вопрос, а как нарезать операционную систему на разные комплекты, на разные экземпляры? И вот эта вот нарезка системы на разные экземпляры равно обеспечению обновления операционной системы в целом, потому что операционная система на самом деле одна, сколько бы там этих виртуальных контекстов ни было, оно выполняется из-за специального режима, который называется Admin Config. Административный режим позволяет нам управлять операционной системой в целом, то есть обновлять ее, нарезать роутер на контексты, и привычная концепция, опять же, с обычного IOS — это Config Register, то есть управлять поведением при загрузке роутера. Это все можно сделать только из специального административного режима. Мы в обычном экзеке можем сказать Admin и попадем в специальный Admin Exec режим. А отсюда можно перейти в Admin Config, то есть у нас приглашение к ководу здесь будет Admin, решетка.

Если мы здесь ConfT наберем, то у нас приглашение к ководу будет ConfigAdmin. ConfigAdmin. Это не какая-то отдельная сущность, не какая-то под сущность обычного конфига, это прям отдельный конфиг. И мы с помощью этого Admin Config можем рулить именно с железкой целиком. В этом Admin Config есть свои субконтексты и так далее. То есть логику я думаю, что вы поняли. Есть нормальный конфиг, в рамках которого можно рулить интерфейсами, юзерами, всем чем угодно. А есть специальный отдельный Admin Config, в рамках которого можно рулить очень важными вещами. Как работаем с консолькой? Ну вот примерно так и работаем. У нас есть приглашение к ководу, заканчивающиеся на решетку, значит мы в экзак-режиме. То есть просто хостнейм и решетка, без ничего. Вводим конфигурию, попадаем в конфиг. Ну то же самое, что в iOS обычно было, только там еще конфигура терминал была. Если хотим выйти из конфига, то мы в Exit на один уровень вверх или End целиком вываливать нас из конфига. То есть здесь ничего нового.

Если хотим по субконтекстам пробежаться, ну вот там в роутер заходим, роутер BGP запускаем, дальше переходим в контекст адресного семейства, у нас получается, мы находимся в конфиге, в контексте BGP, в субконтексте настройки адресного семейства BGP. Если мы хотим зайти в административный режим, то мы заходим в ключевое слово admin, и здесь можно управлять, например, операционной системой, можем заливать новые файлы с iOS, можно делать всякие разные другие штуки. Если мы хотим проадминить железку, то мы в админе пишем конфигурию, у нас приглашение меняется в admin config. Если мы вносим какие-то изменения в конфигурию, то на самом деле система себя ведет не так, как мы привыкли в iOS обычном. То есть в обычном iOS мы вносим какие-то изменения, они сразу применяются. Там набрали IP-адрес чего-нибудь у нас сразу, IP-адрес чего-нибудь на интерфейсе появляется. Запустили роутер там, не знаю, новую команду Network сразу, команда Network отработала.

Запустили. Все, что мы делаем в настройках, все, оно применяется немедленно. Исключение, как вы помните, на свечах это запуск процесса MST, настройки MST применяются только пачкой, и настройки VLAN. Когда вы вводите указание, что у вас есть новый VLAN, он не сразу применяется, только тогда, когда вы выходите из контекста настройки VLAN. В то же время iOS XR никогда не применяет изменения сразу. Изменения проходят двухэтапные, соответственно, две стадии. Первая стадия, вы при внесении изменений, когда вы просто пишете конфигурию, а потом начинаете вешать там IP-шники на интерфейс и все остальное, вы проводите синтаксическую проверку того, что вы ввели. То есть система сначала проверяет, что то, что вы ввели, имеет вообще какой-то смысл, проверяет синтаксис, проверяет какую-то базовую логику того, что вы вводите, но не применяет это все немедленно. То есть изменения не вносятся в текущую конфигурацию. И фактически вы правите

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

То есть если где-то вы там ошиблись из 10 команд в самый последний, который вы набрали, сделали ошибку логическую, набрали commit, система проверила 9 команд, десятую попыталась выполнить, и не смогла, она никакую из этих 10 команд по умолчанию не применяет. Если вы хотите, вы можете управлять этим поведением немножечко более интересно. Если вы хотите, вы можете просто нажать commit. То есть в конфиге чего-то поправили, нажали commit, изменения применились. Но если вы хотите, вы можете сделать и более, скажем, какие-то изощренные вещи. Самое, наверное, правильное, самое правильное с точки зрения логики штука — это commit confirmed. Если вы указываете commit, у вас изменения применяются, и они сразу начинают работать, и они сразу сохраняются в энергонезависимую память. То есть если вы потом перезагрузите железку, она потом не вспомнит, что у нее на самом деле была другая конфигурация. И здесь возникает проблема следующего характера, что если вы внесли изменения, сразу железка не сдохла от этого,

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

рекомендуется использовать commit confirmed. И есть штука, которая позволяет использовать не атомарную операцию commit, а попытаться применить так много команд из commit, как только возможно. То есть, если вы набрали 10 команд и в десятый ошибка, а 9 остальных нормальные, то если вы наберете commit best effort, то у вас применятся только те команды, которые действительно по факту рабочие. А те, которые не сработали, они не применятся. То есть, вместо того, чтобы единый атомарный commit делать, у вас применяется вот то, что получилось применить. Можно будет отключить проверки на вшивость, проверки на доступное место в памяти. В некоторых случаях, например, редактирование, например, аксесс-листов может быть интересно. Вы можете сказать commit false, и система, если ей покажется, что вы делаете что-то небезопасное,

не будет при этом возникать. То есть, у нее есть такое подозрение иногда, что вам может не хватить места, не хватить тех или иных ресурсов. Ну вот, commit false — это заставить железку применить изменения все равно. Может быть, конечно, это вылетит с ошибкой, то есть, если действительно памяти не хватает. Но часто система перестраховывается, и на самом деле, можно попытаться уговорить ее выполнить те действия, которые вы хотите. Из того, что интересно, есть, соответственно, commit safe running — это вы текущую конфигурацию, которая у вас есть, записываете в некоторых файлях для того, чтобы потом на него внимательно посмотреть. Есть, соответственно, commit safe, простите, просто save. текущая конфигурация загружается в нужный вам файлик. Load и commit replace. Load — это загружается конфигурацией целиком, а commit replace вы в текущую конфигурацию заменяете неким содержимым.

То есть вы указываете commit replace, и дальше все, что вы ввели вот в эту самую кандидатскую конфигурацию, только то, что вы ввели, становится конфигом. Если просто вы заходите в конфиг и потом нажимаете config replace, просто enter нажимаете, у вас конфигурация целиком очищается. Роутер становится голый, как будто он только что пришел с завода. Если вы захотите, вы можете зайти в конфигурацию, дальше понабивать всю конфигурацию, которую вы прочитаете, например, с файлика, просто copy-paste сделаете, нажимаете commit replace, у вас конфигурация заменяется на то, что вы набиваете. Ну, то есть это такой способ сделать commit replace. Commit, простите, configure replace из обычного iOS. Так. Как посмотреть, что у вас работает? Есть команда show running config, она показывает текущую конфигурацию.

Очевидно. Есть команда show config, когда вы заходите в конфиг и дальше начинаете вводить какие-то настройки, которые вы хотите, чтобы применились одновременно с commit. Вот вы можете посмотреть, что именно у вас изменится после того, как вы сделаете commit. Show config покажет то, что вы собираетесь внести. Show config merge покажет, что в итоге получится. То есть есть отдельно show running, как сейчас работает, есть show config merge, что получится в итоге. И show config changes — это если вы сделаете не обычный commit, а commit replace, стерев все, что у вас было в конфигурации, заменив тем, что вы ввели в рамках текущего конфига. Вот show config changes показывает вам то, что получится после config replace. Так. Да, ну, commit confirmed я уже сказал. Да, commit confirmed обычно через минуту срабатывает, но вот вы можете указать таймер, в течение которого вы должны будете отреагировать на попытку применения конфигурации. Если вдруг вы не потеряли управление,

то вы просто еще раз делаете commit, и у вас все срабатывает. Если вы ввели commit confirmed, там, допустим, не указали таймер или указали таймер 1, 1 минута, нажали, потеряли управление железкой, железка через минуту сама откатит конфигурацию назад. Так. Можно будет добавить label, так называемую метку, для того, чтобы потом в истории кандидатских, истории активных конфигураций вы могли найти ту, которая вас интересует. То есть, каждая конфигурация, которую вы применяете, вот когда вы commit пишете, у вас она сохраняется в специальной базе. И вы потом по этой базе можете смотреть, чего вы там такое конфигурили. И если вы на каждую commit делаете метку, то вы потом можете понять, что вот, ага, здесь commit мы исправили, допустим, содержимое, ну не содержимое, а настройки интерфейса, которые смотрят на одного пользователя. Здесь мы отредактировали настройки в SPF, здесь мы там и что-то еще сделали. И потом, если вы смотрите историю изменений, то вы будете понимать,

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

но она там существенно более кривая. Она требует использования функции архивации, то есть что у вас файлики, фактически прям файлики-файлики сохранялись бы в EOS, и вы могли бы посмотреть, какие у вас предыдущие конфигурации были, могли бы там откатиться, но в обычном EOS там только 10 этих конфигов есть, и, в общем, функция достаточно такая, кривая. А здесь это сравнительно штатная вещь, то есть что-то наконфигурили, закоммитили, не понравилось, откатились. Так, да. Как посмотреть историю изменений? Show configuration history. И вам показывается по каждому изменению конфигурации, что это было примерно. То есть если вы сделали коммит, то показывается просто какая-то информация. Вот эту вот информацию можно заменить на текстовый комментарий. Если вы захотите, вы можете добавить текстовый комментарий, что вы делали. Вот те самые лейблы и дескрипшены. Если вы с конфигурацией делали что-то еще, вот, например, бэкапили или перезагружали железку, и там, возможно, вследствие перезагрузки что-то изменилось,

в этом случае, опять же, система сама автоматически изменяет конфигурацию, и предыдущие варианты бэкапят. Если вы хотите откатиться на какой-то конкретный номер конфигуры, который у вас здесь есть, то есть вы посмотрели, вот, последние два изменения, это вот как раз коммиты. Один раз сделали коммит, стало хорошо, второй раз сделали коммит, стало плохо, вы хотите откатиться вот сюда вот. Соответственно, вот вы можете сказать, rollback, configuration, to, и дальше указать номер, который вас интересует. Там, to4, to2. Это на... откатиться на элемент с указанным вами номером. Если вы хотите откатиться на какой-то элемент, и вы не знаете, какой у него был номер, а чаще всего вы как бы догадываетесь, что вас интересует ровно предыдущая конфигурация, потому что это чаще всего так и есть. Вы хотите откатиться на одну конфигуру назад. Применили изменения, поняли, что все плохо, хотите вернуться на одну конфигуру назад, rollback, configuration, last1. Можно на 2, на 3, ну, то есть сколько элементов захотите, столько и сделайте. Как правило, вы хорошо помните, сколько коммитов вы сделали. Ну, чаще всего один.

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

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

И система скажет, извините, там уже занято. Вы можете посмотреть, кто именно захватил управление. Show configuration log. Система покажет, есть ли эксклюзивные попытки захвата сессии. И, соответственно, вы можете посмотреть show configuration sessions, кто именно этот лог схватил. То есть вот нам показано вот это вот configuration log, и этому логу соответствует линия управления VTI 0, ну, видимо, telnet, user admin, и схватил управление он вот в это вот время. В iOS XE эта ситуация никак не обрабатывается. То есть вы можете легко отредактировать все, что угодно. Изменения применяются в iOS XE немедленно. Вероятность того, что два администратора прямо действительно одновременно применят какие-то изменения, она нулевая. Она ровно нулевая. Она не близка к нулевая, но ровно нулевая, потому что все равно сначала обработается исправление от одного пользователя, а потом, соответственно, контекст перескочат на другого пользователя и применится изменение другого пользователя. Изменения первого потеряются. Вот в более продвинутых операционных системах,

но в первую очередь в Joanness, во вторую очередь в iOS XR, такие штуки просто не разрешено делать. Вы можете не допускать того, чтобы кто-то с вами в принципе одновременно чего-то редактировал. Так. Если вы хотите обновить iOS XR, то вам нужно будет сделать несколько действий. Вам нужно будет, во-первых, где-то надыбать пакет обновления, который вас будет интересовать. Пакет обновления будет работать только для конкретного модуля. То есть в отличие от обычного iOS, где у нас просто достаточно было просто файлик подтащить, и там весь этот файлик целиком начинает обновлять вообще все. То есть вы не можете сказать, давайте обновим только, не знаю, TELNET, только OSPF. В XR можно обновить модуль один. Не обновлять всю систему целиком, сказать, вот нам не нравится поведение конкретного модуля, но мы хотим обновить только конкретный модуль. Вам для этого будет нужно добыть где-то файлик, который называется PE.

Packet чего-то там, Installation, не помню. У меня есть какая-то расшифровка, я ее не помню. И, соответственно, вы должны этот файлик скормить в вашей CISC. Ну, самый простой способ – это там CFTP, TFTP или чего-то еще скопировать его, положить на флешечку или на диск, а затем нужно будет его распаковать. Этот файлик, он по факту является архивом. И вы, когда скачиваете этот файлик, говорите, давайте мы его распакуем, вы указываете команду InstallAd. Дальше вы указываете название файлика, и система при выполнении команды InstallAd, она берет этот файлик и распаковывает его в папку с операционной системой. Прямо натурально распаковывает. Но от того, что она его распаковала, не следует, что она полученные эти файлы каким-то образом начинает обрабатывать. То есть вам надо в какой-то момент сказать, вот мы там файлики положили новые, на них надо поставить ссылку. И эта команда будет InstallActivate. То есть вы указываете название пакета. Сначала InstallAd, потом InstallActivate. И, как водится, InstallCommit.

То есть все изменения надо будет коммитить. Если даже это обновление операционной системы, все равно коммит нужен. Это не конфигуры коммит, это другой коммит. Но, тем не менее, все равно надо. Вот в этот момент операционная система понимает, что ей подоткнули какие-то новые файлики. Она понимает, что эти файлики надо обработать, и она начинает их прожевывать. И рано или поздно прожевывает. Поскольку обновление операционной системы или даже отдельных модулей – эта штука все-таки достаточно инвазивная, для того, чтобы войти в режим, в котором вам позволят системы это сделать, нужно выполнить команду Admin. То есть сначала пишем Admin, приглашение к ководу изменяется, и после этого только мы можем редактировать модуль операционной системы. Если вы хотите посмотреть, что происходило в части обновлений с вашей операционкой, потому что может быть такое, что вы один администратор, а есть какой-то другой администратор. Вот другой администратор внезапно что-то там обновил. Вот как узнать, чего происходило, кто чего обновлял? Есть команда showinstallrollback.

Она покажет точно так же, как и с configuration, show configurations, покажет, что происходило с устройством, какие обновления происходили, и можно, если вдруг вы захотите, откатиться по состоянию на некоторое количество обновлений назад. То есть это происходит само. Если вы поставили пакет, он у вас начинает глючить, вы говорите, ну-ка нафиг, нафиг, нафиг. Можно указать showinstallrollback и дальше указать номер конкретного роллбека, который вас потенциально интересует, и система покажет, что происходило. В нашем случае вот происходило, что базовый образ операционной системы был установлен, и если мы хотим откатиться, то вот, соответственно, у нас вернется ситуация вот на такие вот пакеты. Указываем installrollback, дальше to, номер 2. То есть откатываем конфигурацию на те пакеты, которые были два апдейта назад. Система начинает апдейт,

начинает переколбашивать пакеты, и, соответственно, рано или поздно ей это либо удается, либо она говорит, извините, не могу, чего-то там ей не хватает. В какой ситуации может чего-то не хватать? Например, если вы удалили те пакеты, которые у вас были, с которых вы уходили наверх. То есть здесь вот, к примеру, мы обновляем пакет manageability и обновляем мы его на версию 4.1.0. Но у него какая-то версия уже была. То есть там, не знаю, 3.8.84, к примеру. Если мы обновляем пакет с 3.8.84 на 4.1.0, то старый пакет должен остаться для того, чтобы можно было на него вернуться. Если вы почему-то решите удалить старый пакет, то вернуться на него будет нельзя. Как можно будет удалить пакеты? Есть команда showinstallactive, которая покажет, какие у вас пакеты прямо сейчас есть. И, соответственно, если вы поймете, что у вас есть какой-то пакет, который прямо сейчас работает, и он вам проблем не приносит, вы можете сказать, окей, прекрасно,

с этим пакетом все хорошо, мы его берем в качестве как бы эталонного пакета и дальше откатиться в рамках этого пакета на какие-то более старые версии мы уже не хотим и не захотим никогда. Вы можете в этом случае выполнить команду install remove и дальше указать название пакета, который вам не нужен. Если вдруг вы понимаете, что есть какой-то пакет, который вы поставили, а он вам не нужен, но он все равно пока активный, его можно деактивировать. То есть так же, как вы когда устанавливаете новый пакет, вы указываете install add, добавляете новый файлик, потом install activate, это вы добавляете этот файлик и даете ему управление. Вот есть и обратная операция, install deactivate, install remove. Команды activate и deactivate требуют коммита, install commit, то есть они изменяют поведение операционной системы. Install add и install remove это просто работа с файликами. То есть вы добавляете новый файлик, вы убираете новый файлик. Есть макрос install remove inactive. Он делает очень простую вещь.

Если вы много-много-много всего обновляли, то вы можете очень долго по show install смотреть, какие пакеты у вас неактивные. То есть вот эти вот пакеты, которые здесь показывают, они активные, с ними все хорошо. На обоих роут-процессорах у нас есть там чего-то, какие-то вот, какие-то пакеты. Но если вы много раз обновлялись, у вас будет большое количество неактивных пакетов. Install remove inactive удалит все, что вам не нравится. То есть это такой механизм быстрой и простой очистки всего, всех следов, которые были поставлены при апдейтах, при всех апдейтах. Так, есть еще одна штука, которую вам нужно будет знать. Это механизм turbo boot. То есть по сути, свое-то ROM-ON. То есть в CISC обычном это называется ROM-ON, в EOS XR это называется turbo boot. В чем заключается смысл этой штуки? Вы можете, если захотите, восстановить поведение

роут-процессора, если вдруг у вас с ним произошел какой-то катастрофический сбой. То есть, например, вы взяли и случайно удалили что-то, что нужно для работы операционной системы. Или вы, там, не знаю, ну просто флешка повредилась, вы там хотите на эту флешку перезаписать заново новый файлик. То есть, если у вас система не грузится, то вы должны будете грузить систему через вот этот вот самый ROM-ON в EOS обычном или через turbo boot в EOS XR. Как эта штука выглядит? Первое самое. Если вы загружаетесь и система вообще не грузится, то есть, она выпадает в ROM-ON, то в этом случае вы переходите вот сюда вот. Если у вас система пока еще грузится, но вы не хотите, чтобы она грузилась так, как она грузится сейчас, потому что вы предполагаете, что у вас, например, диск может посыпался или что-то еще, то есть, флешка гвитая, в этом случае вы можете при живом EOS выполнить определенные действия. Есть команда CFS-Check, она выполняет проверку файловой структуры, файлового пространства. Если она проверяет и находит какие-то ошибки,

она их пытается исправить. Ну и бывает такое, что у вас действительно обнаружены ошибки, но эти ошибки не удается исправить, и как следствие у вас операционная система оказывается повреждена. И это, как правило, как правило, это проявляется в том, что у вас система не может работать корректно. Может быть, она может загрузиться, может быть, она позволит вам войти в командную строку, но при этом она не позволит, не знаю, какие-то процессы запустить. Система будет говорить, извините, файл поврежден. В этой ситуации нужно будет перезалить EOS. Если у вас есть такая возможность, это хорошо, на лету, но иногда такой возможности просто нет. В этом случае нужно будет исправлять конфиг-регистр. То есть, у нас есть команда конфиг-регистр, такая же, как в обычном EOS, она влияет на поведение железки целиком. И мы указываем конфиг-регистр, дальше указываем 0,0, location all, значит, мы прописываем этот конфиг-регистр одновременно на обоих роут-процессорах. Дальше перезагружаем оба роут-процессора команды reload location all. Это делается из админ-режима.

Понятное дело, что перезагрузить оба роут-процессора это в целом идея не очень интересная, если у вас роутер действительно фарвардит боевой трафик. Но если он уже сломался, если с ним уже произошел какой-то катастрофический сбой, то здесь делать нечего. Дальше. Вы после того, как вы выставляете вот эту вот штуку, конфиг-регистр, 0,0, вы заставляете вашу циску упасть в ROM1. И если у вас она грузилась до того хоть как-то, она перестает это делать, она вываливается в ROM1, и вы получаете сразу доступ от судового. Что вам нужно здесь будет сделать? Вам нужно будет сказать, что если ваша система не... Продон. Если ваша система сейчас не может загрузиться, это происходит, видимо, потому что у вас нет базового образа операционной системы, которая мог бы загрузиться. Следовательно, вам нужно будет его где-то дать. Вы убираете переменные, которые называются boot и tfp-файл. То есть это указание, откуда следует

грузить операционную систему, если она у вас не лежит на флешке. Дальше. Вы набираете команду sync. Эта команда реплицирует состояние на второй role-процессор. Дальше. Вы указываете вот такие вот штуки. IP-адрес свой, IP-садмет-маск свою, то есть вы тем самым даете настройки IP-адреса этому самому ROM1. Шлюз по умолчанию, если нужно. И дальше волшебное слово turbo-boot. это как раз указание на то, что надо делать при загрузке. Если вы хотите, чтобы ваша система загрузилась с tfp, то вы указываете, откуда грузимся, что делаем с текущей конфигурацией и что действительно нужно будет делать с turbo-boot. Если вы знаете, что ваша флешка уже точно повреждена, что там есть какой-то iOS, который на ней лежит, но он уже точно не живой,

вот, в этом случае вы можете добавить здесь формат. Это, ну, вполне говорящая настройка, она сотрет все, что у вас на флешке, ну, на диске есть. И дальше выполняем команду boot и указываем файлик, который называется vm. То есть вот эта вот штука, это фактически базовый образ операционной системы, из которого следует загрузиться. Указываем, ну, проще всего с tfp его указать, натравляем на tfp сервер, говорим загрузись отсюда, и система начинает грузиться. после того, как мы все сделали, на резервном процессоре указываем команду configuration register 0102. Ну, то есть это выставление в обычный нормальный режим и перезагружаемся. Почему надо будет сделать на резервном процессоре это? Потому что у нас висит в ромоне, и он автоматически не загружается после того, как вы на него прописали вот эту вот команду config register 0102. То есть его нужно будет config register вернуть в оригинальные значения. На основном процессоре

мы все настройки сделали, основной процессор смог получить нормальный use, а вот запасной процессор, который резервный, ему, соответственно, надо будет дать волшебный пиндель. Поэтому мы указываем, восстанавливаем оригинальное значение config register, не пытаемся на него переключаться, пока он выключен. Но вот после того, как он получает нормальный config register, он сможет все настройки схватить с основного road processor и ресет, понятное предсказуемое поведение. Так, с какого интерфейса будут лететь настройки? С менеджмент интерфейсов. У road processor два менеджмент интерфейса, менеджмент LAN 1, менеджмент LAN 2. То есть они переключаются в бриджовый режим, и с любого из них он сможет достучаться. Так, давайте сейчас попробуем с вами это дело посмотреть. Мы сейчас видим процесс загрузки роутера на основе операционной системы EOS XR, и когда вы видите вот подобную вот штуку, что система говорит, что консоль сейчас доступна, на самом деле она не совсем доступна.

Если я сейчас попытаюсь нажать enter, система будет ругаться, говорить, что в общем, все плохо, и вот она говорит, пожалуйста, не пытайтесь переконфигурировать это устройство до тех пор, пока процесс загрузки не завершится. Это означает, что у вас сейчас пока еще железо не до конца загрузилось, то есть оно, да, загрузило операционную систему, оно загрузило процесс RP-Access, которое позволяет мне зайти по телнету, например, или по консоли на железку, но оно не загрузило саму вот базу операционной системы EOS, и, соответственно, вот то, что то, что я сейчас получу доступ, оно на самом деле будет такой декоративный доступ, потому что сейчас параллельно с тем, что я могу зайти в эту систему, еще другие процессы настраивают железку прямо вот сейчас на лету. Я воспользуюсь заранее запрограммированной парой логин-пароль, которыми здесь система любезно подсказывает, что система говорит, что зайди с паролем Cisco-Cisco, ну вот я воспользуюсь этой рекомендацией, Cisco-Cisco,

и система меня пускает в консольку, при этом я говорю еще раз, что система параллельно с этим вот фактом, что я зашел в консольку, делает какие-то другие дела. Как только она закончит конфигурацию устройства, на консоль вылетит отдельное сообщение, что система полностью завершила все настройки, с этого момента в конфигурацию можно будет переходить без каких-либо проблем. Я, честно говоря, не помню. А, вот, как раз она пробежала, система configuration complete, то есть я сейчас могу в конфигуре без каких-либо ограничений заходить. Система меня пускает, и в этом конфигуре я могу делать все, что угодно. То есть здесь по большому счету логика примерно та же самая, что в обычной вылесе, то есть работает вопросик, точно так же все разбивается на отдельные экраны, точно так же там в терминале помещается по 25 строчек, поэтому раз 25 строчек делает отбивку. Ну, то есть это поведение вам должно быть после обычного EOS знакомо. Так, если мы хотим что-то сделать

с нашей системой, ну, то есть, допустим, на обычном EOS, что первое самое дело? Переименовывая его. Вот у нас сейчас железка называется EOS. Мы подключились к устройству на роуд-процессор в нулевой стойке, нулевой роуд-процессор и управляем обычным процессором, обычным CPU. Но мы хотим переименовать наше устройство, сказать, чтобы оно называлось не просто EOS, а как-то иначе. Переименование предсказуемым образом работает. Hostname, там, не знаю, Hostname, не знаю, Network Education. Система при этом не применила эту настройку сразу. В отличие от обычного EOS, который сразу бы переименовал устройство, здесь нужно делать commit. Я сделал commit, система изменила настройки. То есть, это важный момент, что как только вы вводите настройку, она немедленно не применяется. Когда вы делаете commit, она применяется. Если я захочу изменить какие-то настройки еще раз, и вот, допустим,

я вижу, что Network Education 1 вроде бы ничего, вроде бы мне все нравится. Commit Confirmant. Указываю Commit Confirmant. Система применяет настройку. Приглашение к вводу изменяется, становится Network Education 1 имя узла, но в течение минуты я должен буду еще раз применить commit для того, чтобы система сохранила все это дело. Если я в течение минуты не применю новый commit, то система будет ругаться и говорить что, судя по всему, администратор потерял управление железкой. Ну, в принципе, можем подождать, можем параллельно позаниматься какими-то другими делами. Что еще можно будет сделать? Можно будет здесь посмотреть на... Так, на что бы здесь посмотреть-то? Не знаю, на настройку интерфейсов, что ли? То есть, если мы хотим редактировать интерфейсы,

в обычном EOS мы пишем интерфейс, и дальше у нас есть название интерфейса. Сначала тип интерфейса, потом номер модуля, и потом там иногда через дробь, иногда через две дроби, иногда через три дроби указывается интерфейс. Здесь система будет немножко по-другому устроена. Здесь у нас интерфейсы, как правило, имеют страшные ужасные номера. то есть, давайте покажу. Show интерфейс summary. Я не знаю, есть такая команда? Нет, вот такой. Так, давайте выйдем из конфига. Система предупреждает меня, что у нас есть какие-то изменения, которые я ввел. Я, кстати, не помню, что у нас было. А, вот, система говорит, что я ввел commit confirm. Вот, да, что у меня сейчас еще пока не применился commit confirm, и если я выйду из конфигурации, то система немедленно откатится назад. Типа я вот после commit confirm

должен ввести в явном виде еще раз commit, чтобы точно уж стало хорошо. И вот если я все-таки настаиваю на том, что я должен буду выйти, система откатывается назад. И, и, и, и, чего? Я не откатилась. А, пардон, откатилась, все честно, да. Было network education 1, и стал network education просто невнимательный. То есть я не ввел commit в течение commit confirm, система откатила назад на предыдущую стабильную конфигурацию. Так, show interface status summary. Здесь показываются типы интерфейсов, которые у нас есть, и показывается, что у нас есть гигабитные интерфейсы, есть какие-то еще интерфейсы, и есть вот нуль интерфейс, который обычно используется для того, чтобы за нуль роутить трафик. Ну, вот в нашем случае есть гигабитные интерфейсы. Это три интерфейса, они все находятся

в состоянии down. Если мы захотим посмотреть, что именно за интерфейсы есть и почему они находятся в состоянии down, работает предсказуемая команда showrun. Ну, showrun config. и мы видим, что конфигурация действительно у нас есть. У нас есть один менеджмент интерфейс, просто абстрактный интерфейс Ethernet, и есть вот три интерфейса, которые нужны для маршрутизации пользовательского трафика. Вот этот вот интерфейс находится на роут-процессоре, вот эти вот три интерфейса находятся на линейной карте. И видно, что названия этих интерфейсов, они немножко специфические, то есть показываются номер стойки, номер линейной карты, номер... так, номер стойки, номер линейной карты, наверное, номер модуля на линейной карте и номер конкретного порта. Ну, вот такие вот страшные, ужасные номера. В принципе, ничего такого необычного в них нет, надо просто запомнить, что они вот так вот пишутся. И фактически, да, вы указываете, какой номер порта вас интересует Gigabit Ethernet 0.002.

Понятное дело, так же, как в обычном илусе работают сокращения типа G0.002. Хорошо видно строчку shutdown в каждом интерфейсе. Если мы захотим, чтобы интерфейс работал, можно вот новый shutdown сделать. Ну, то есть это все предсказуемо работает так же, как в обычном илусе. ConfT привычка. В принципе, можно было просто Conf набрать. Interface там Gigabit 0. drop 0, drop 0, drop 0, no shutdown. Система не применяет изменения немедленно. Commit теперь применяет. Интерфейс переходит в состояние up, то есть вот здесь как-то по-дурацки это отрисовалось, вот эта вот штука, это у нас сообщение дебага. Ну, на самом деле, да, система применила изменения после Commit и теперь у нас интерфейс находится в состоянии up. Так,

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

будет имя Network Education. Естественно, что если я откачусь на него то я вынужден буду откатиться и на все предыдущие Commit тоже. То есть, если я скажу, что меня интересует вот, допустим, перескок вот сюда вот в конфигурации, то по факту будет правильно, если у меня применится изменение из вот этого Commit, из вот этого Commit, из вот этого Commit. давайте попробуем. Так, где у меня есть rollback configuration to вот этот вот. Система пытается откатиться, ей удалось это сделать, и у нас конфигурация вернулась на два Commita назад. showrun вот показывает, что все интерфейсы выключены, название железки Network Education. Вот примерно так

можно работать с конфигурацией. IUS XR за вас ведет историю ваших Commit, и в случае, если вы сделали что-то неправильно, всегда можно откатиться на некоторое количество Commit назад. В IUS обычном есть аналогичная штука, то есть ввести историю изменений текущей конфигурации, ну, не текущей конфигурации, там, чуть более сложно, ввести историю изменений конфигурации можно с помощью команды архив, и если вы хотите откатиться на состояние некоторое количество изменений конфигурации назад, вы можете использовать команду configure replace. Но здесь это сделано существенно более элегантно и удобно. В принципе, в Juniper абсолютно так же, как здесь все это устроено. Так, что еще здесь нас будет интересовать? В IUS XR все конфигурации, все модули конфигурации, которые есть, они достаточно удобные, они разбиты по модулям. Хорошо видно,

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

Более того, все штуки, которые будут относиться к контексту роутер OSPF, они все будут находиться вот в этом вот контексте. То есть, в ИУСе обычном, если вы знаете, там тоже OSPF, только OSPF V3, можно заставить хранить все конфиги в одном и том же месте, в контексте роутера OSPF V3, но только это требует именно использования OSPF V3. С обычным OSPF, который OSPF V2, в обычном ИУСе вы не можете заставить хранить все настройки OSPF в одном месте. У вас часть конфига будет лежать в роутер OSPF в контексте, часть конфига будет лежать, которая относится к интерфейсам в настройках OSPF и будут храниться в роутеру OSPF V1 без исключения. То есть, ничего в настройке самого интерфейса Gigabit 0.0 относящегося к OSPF не будет. Равным образом включаем какой-нибудь там, не знаю, HSRP. В ИУСе обычном все настройки HSRP-шные хранятся в настройке интерфейса. Здесь мы запускаем отдельный кусок, отдельный процесс HSRP. У него появляется отдельный блок

в текущей конфигурации. Все настройки, относящиеся ко всем интерфейсам, имеющие отношение к HSRP, хранятся в отдельном блоке. Это намного удобнее читается. Если вас интересует только блок, относящийся к роутеру OSPF, прекрасно. Заказывайте конфигурацию, указывайте, что вас интересует блок роутеру OSPF, и вы не читаете конфигурацию, которая вам не нужна. Так, ну, я предлагаю на этом приблизительно знакомство с операционной системой EOS XR завершить. Давайте следующий модуль, который у нас будет, он будет посвящен работе с Ethernet и сервисами на основе Ethernet. И там, естественно, мы будем проверять работоспособность наших устройств и будем, естественно, оперировать и операционной системой EOS, и операционной системой EOS XR. На сегодня все. Спасибо за внимание. Пока-пока. Спасибо.