По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Четвертая часть тут
Описанные до сих пор технологии—коммутация каналов и пакетов, плоскости управления и QoS—очень сложны. На самом деле, по-видимому, нет конца растущей сложности сетей, особенно по мере того, как приложения и предприятия становятся все более требовательными. В этой лекции будут рассмотрены два конкретных вопроса, связанных со сложностью и сетями:
Что такое сложность сети?
Можно ли «решить» сложность сети?
Почему сети должны быть сложными?
Хотя наиболее очевидным началом понимания темы может быть определение сложности, но на самом деле более полезно рассмотреть вопрос, почему сложность требуется рассмотреть в более общем смысле. Проще говоря, возможно ли «решить» сложность? Почему бы просто не проектировать более простые сети и протоколы? Почему каждая попытка сделать что-то более простое в сетевом мире в конечном итоге явно усложняет ситуацию в долгосрочной перспективе?
Например, благодаря туннелированию поверх (или через) IP сложность плоскости управления снижается, а сеть в целом упрощается. Почему тогда туннельные оверлеи сложны?
Есть два ответа на этот вопрос. Во-первых, поскольку человеческая природа является тем, чем она является, инженеры всегда будут изобретать десять различных способов решения одной и той же проблемы. Это особенно верно в виртуальном мире, где новые решения (относительно) просты в развертывании, (относительно) легко найти проблему с последним набором предлагаемых решений, и (относительно) легко создать новое решение, которое «лучше старого». Это особенно верно с точки зрения поставщика, когда создание чего-то нового часто означает возможность продавать совершенно новую линейку продуктов и технологий, даже если эти технологии очень похожи на старые. Другими словами, виртуальное пространство настолько хаотично, что там легко создать что-то новое.
Второй ответ, однако, заключается в более фундаментальной проблеме: сложность необходима, чтобы справиться с неопределенностью, связанной с трудноразрешимыми проблемами.
Добавление сложности, по-видимому, позволяет сети легче справляться с будущими требованиями и неожиданными событиями, а также предоставлять больше услуг по меньшему набору базовых функций. Если это так, то почему бы просто не построить единый протокол, работающий в одной сети, способный обрабатывать все требования, потенциально предъявляемые к нему, и может обрабатывать любую последовательность событий, которую вы можете себе представить? Одна сеть, работающая по одному протоколу, безусловно, уменьшит количество «движущихся частей», с которыми приходится работать сетевым администраторам, и сделает нашу жизнь проще, верно? На самом деле существует целый ряд различных способов управления сложностью, например:
Абстрагируйтесь от сложности, чтобы построить black box вокруг каждой части системы, чтобы каждая часть и взаимодействие между этими частями были более понятны сразу.
Переместите сложность в другую область — чтобы переместить проблему из области сетей в область приложений, кодирования или протокола. Как говорится в RFC1925 «Проще переместить проблему (например, переместив ее в другую часть общей сетевой архитектуры), чем решить ее»
Добавьте еще один слой сверху, чтобы рассматривать всю сложность как black box, поместив другой протокол или туннель поверх того, что уже есть. Возвращаясь к RFC1925 «Всегда можно добавить еще один уровень indirection»
Проникнитесь сложностью, обозначьте то, что существует как «наследие», и гонитесь за какой-то новой блестящей вещью, которая, как считается, способна решить все проблемы гораздо менее сложным способом.
Игнорируя проблему и надеясь, что она уйдет. Аргументация в пользу исключения «только на этот раз», так что конкретная бизнес-цель может быть достигнута или какая-то проблема устранена в очень сжатые сроки, с обещанием, что проблема сложности будет решена «позже», является хорошим примером.
Каждое из этих решений, однако, имеет ряд компромиссов для рассмотрения и управления. Кроме того, в какой-то момент любая сложная система становится хрупкой - прочной, но хрупкой. Система является надежной, но хрупкой, когда она способна устойчиво реагировать на ожидаемый набор обстоятельств, но неожиданный набор обстоятельств приведет к ее отказу.
Определение Сложности
Учитывая, что сложность необходима, инженеры должны научиться управлять ею каким-то образом, находя или создавая модель, или структуру. Лучше всего начать построение такой модели с самого фундаментального вопроса: что означает сложность в терминах сетей? Можно ли поставить сеть на весы и сделать так, чтобы стрелка указывала на «комплекс»? Существует ли математическая модель, в которую можно включить конфигурации и топологию набора сетевых устройств для получения «индекса сложности»? Как понятия масштаба, устойчивости, хрупкости и элегантности соотносятся со сложностью? Лучшее место для начала построения модели — это пример.
Состояние Control Plane в зависимости от протяженности.
Что такое протяженность сети? Проще говоря, это разница между кратчайшим путем в сети и путем, который фактически принимает трафик между двумя точками. Рисунок 1 иллюстрирует эту концепцию.
Если предположить, что стоимость каждого канала в этой сети равна 1, то кратчайший физический путь между маршрутизаторами A и C также будет кратчайшим логическим путем: [A,B, C]. Однако что произойдет, если метрика на ссылке [A,B] изменится на 3? Самый короткий физический путь по-прежнему [A,B,C], но самый короткий логический путь теперь [A,D,E,C]. Разница между кратчайшим физическим путем и кратчайшим логическим путем-это расстояние, которое должен пройти пакет, пересылаемый между маршрутизаторами A и C—в этом случае протяженность может быть вычислена как (4 [A,D,E,C])?(3 [A,B, C]), для протяженности 1.
Как измеряется протяженность?
Способ измерения протяженности зависит от того, что является наиболее важным в любой конкретной ситуации, но наиболее распространенным способом является сравнение количества прыжков в сети, как это используется в приведенных здесь примерах. В некоторых случаях может оказаться более важным рассмотреть метрику по двум путям, задержку по двум путям или какую-то другую метрику, но важно последовательно измерять ее по всем возможным путям, чтобы обеспечить точное сравнение между путями.
Иногда бывает трудно отличить физическую топологию от логической. В этом случае была ли метрика канала [A,B] увеличена, потому что канал связи на самом деле является более медленной линией связи? Если да, то является ли это примером протяженности или примером простого приведения логической топологии в соответствие с физической топологией, спорно.
В соответствии с этим наблюдением, гораздо проще определить политику с точки зрения протяженности, чем почти любым другим способом. Политика — это любая конфигурация, которая увеличивает протяженность сети. Использование Policy-Based Routing или Traffic Engineering для перенаправления трафика с кратчайшего физического пути на более длинный логический путь, например, для уменьшения перегрузки в определенных каналах, является политикой - она увеличивает протяженность.
Увеличение протяженности — это не всегда плохо. Понимание концепции протяженности просто помогает нам понять различные другие концепции и поставить рамки вокруг компромиссов сложности и оптимизации. Самый короткий путь, с физической точки зрения, не всегда лучший путь.
Протяженность, на этом рисунке, очень простая—она влияет на каждый пункт назначения и каждый пакет, проходящий через сеть. В реальном мире все гораздо сложнее. Протяженность фактически приходится на пару источник / приемник, что делает ее очень трудной для измерения в масштабах всей сети.
Определение сложности: модель А
Три компонента - state, optimization, и surface, являются общими практически в каждом решении по проектированию сети или протокола. Их можно рассматривать как набор компромиссов, как показано на рисунке 2 и описано в следующем списке.
Увеличивающаяся оптимизация всегда движется в направлении большего количества состояний или большего количества поверхность взаимодействия.
Уменьшающееся состояние всегда движется в сторону меньшей оптимизации или большего количества поверхности взаимодействия.
Уменьшение поверхности взаимодействия всегда приводит к меньшей оптимизации или большему состоянию.
Конечно, это не железные правила; они зависят от конкретной сети, протоколов и требований, но они, как правило, достаточно верны, чтобы сделать эту модель полезной для понимания компромиссов в сложности.
Поверхность взаимодействия.
Хотя понимание определения состояние и оптимизация интуитивно понятны, стоит потратить еще немного времени на понимание понятия поверхности взаимодействия. Концепция поверхностей взаимодействия трудна для понимания прежде всего потому, что она охватывает широкий спектр идей. Возможно, был бы полезен данный пример. Предположим, что функция, которая:
Принимает два числа в качестве входных данных
Добавляет их
Умножает полученную сумму на 100
Возвращает результат
Эту единственную функцию можно рассматривать как подсистему в некоторой более крупной системе. Теперь предположим, что вы разбили эту единственную функцию на две функции, одна из которых выполняет сложение, а другая-умножение. Вы создали две более простые функции (каждая из которых выполняет только одну функцию), но вы также создали поверхность взаимодействия между двумя функциями—вы создали две взаимодействующие подсистемы внутри системы, где раньше была только одна.
В качестве другого примера предположим, что у вас есть две плоскости управления, работающие в одной сети. Одна из этих двух плоскостей управления несет информацию о пунктах назначения, доступных вне сети (внешние маршруты), в то время как другая несет пункты назначения, доступные внутри сети (внутренние маршруты). Хотя эти две плоскости управления являются различными системами, они все равно будут взаимодействовать многими интересными и сложными способами. Например, доступность к внешнему назначению будет обязательно зависеть от доступности к внутренним назначениям между краями сети. Эти две плоскости управления теперь должны работать вместе, чтобы построить полную таблицу информации, которая может быть использована для пересылки пакетов через сеть.
Даже два маршрутизатора, взаимодействующие в пределах одной плоскости управления, могут рассматриваться как поверхность взаимодействия. Именно эта широта определения делает очень трудным определение того, что такое поверхность взаимодействия.
Поверхности взаимодействия не плохая вещь. Они помогают инженерам и дизайнерам разделить и победить в любой конкретной области проблемы, от моделирования до реализации.
Управление сложностью через Wasp Waist.
Wasp waist, или модель песочных часов, используется во всем мире и широко имитируется в инженерном мире. Хотя инженеры не часто сознательно применяют эту модель, на самом деле она используется постоянно. На рис. 3 показана модель песочных часов в контексте четырехуровневой модели Department of Defense (DoD), которая привела к созданию пакета интернет-протоколов (IP).
На нижнем уровне, физической транспортной системе, имеется широкий спектр протоколов, от Ethernet до Satellite. На верхнем уровне, где информация распределяется и представляется приложениям, существует широкий спектр протоколов, от протокола передачи гипертекста (HTTP) до TELNET. Однако, когда вы перемещаетесь к середине стека, происходит забавная вещь: количество протоколов уменьшается, создавая песочные часы. Почему это работает, чтобы контролировать сложность? Если мы вернемся к трем компонентам сложности-состоянию, поверхности и сложности, - то обнаружим связь между песочными часами и сложностью.
Состояние делится песочными часами на два разных типа состояния: информация о сети и информация о данных, передаваемых по сети. В то время как верхние уровни занимаются маршалингом и представлением информации в удобной для использования форме, нижние уровни занимаются обнаружением того, какая связь существует и каковы ее свойства на самом деле. Нижним уровням не нужно знать, как форматировать кадр FTP, а верхним уровням не нужно знать, как переносить пакет по Ethernet - состояние уменьшается на обоих концах модели.
Поверхности управляются путем уменьшения количества точек взаимодействия между различными компонентами до одного - Интернет-протокола (IP). Эту единственную точку взаимодействия можно четко определить с помощью процесса стандартизации, при этом изменения в одной точке взаимодействия тщательно регулируются.
Оптимизация осуществляется путем разрешения одному слою проникать в другой слой, а также путем сокрытия состояния сети от приложений. Например, TCP на самом деле не знает состояния сети, кроме того, что он может собрать из локальной информации. TCP потенциально может быть гораздо более эффективным в использовании сетевых ресурсов, но только за счет нарушения уровня, которое открывает трудноуправляемые поверхности взаимодействия.
Таким образом, наслоение многоуровневой сетевой модели — это прямая попытка контролировать сложность различных взаимодействующих компонентов сети.
Очень простой закон сложности можно сформулировать так: в любой сложной системе будут существовать наборы трехсторонних компромиссов. Описанная здесь модель State/Optimization/Surface (SOS) является одним из таких компромиссов. Еще один, более знакомый администраторам, работающим в основном с базами данных, - это Consistency/Accessibility/Partitioning (теорема CAP). Еще один, часто встречающийся в более широком диапазоне контекстов, — это Quick /Cost/Quality (QSQ). Это не компоненты сложности, а то, что можно назвать следствиями сложности.
Администраторы должны быть искусны в выявлении такого рода компромиссных треугольников, точно понимать «углы» треугольника, определять, где в плоскости возможного лежит наиболее оптимальное решение, и быть в состоянии сформулировать, почему некоторые решения просто невозможны или нежелательны.
Если вы не нашли компромиссов, вы недостаточно усердно искали — это хорошее эмпирическое правило, которому следует следовать во всех инженерных работах.
Всем привет! Недавно одну из наших статей мы посвятили рассказу о Route Patterns. Сегодня мы продолжим рассматривать механизм маршрутизации звонка в Cisco Unified Communications Manager (CUCM), и рассмотрим, что происходит с вызовом после того как он попал под определенный паттерн – а именно про Route List и Route Group.
Рассмотрим, как происходит процесс маршрутизации.
После набора номера в Route Patterns происходит сверка с заданными паттернами и выбирается подходящий, который указывает на Route List, который указывает на группы Route Group, которые в свою очередь указывают на устройства, шлюзы и транки.
Настройка Route Group
Для создания группы нужно перейти во вкладку Call Routing → Route/Hunt → Route Group и нажимаем Add New. Тут указываем название группы и в поле Distribution Algorithm выбираем, по какому алгоритму будут распределяться устройства – Top Down или Circular. Сами устройства, транки или шлюзы выбираем в поле Available Devices и для добавления в группу нажимаем кнопку Add to Route Group. После этого добавленное устройство появляется в поле Selected Devices. Для сохранения настроек нажимаем Save.
Настройка Route List.
Чтобы создать список нужно вкладку Call Routing → Route/Hunt → Route List и нажать Add New. Здесь указываем название, описание и группу (по умолчанию – Default). После нажатия Save внизу появляется поле Route List Member Information, в котором нужно нажать кнопку Add Route Group.
В открывшемся окне в строке Route Group выбираем необходимую группу и нажимаем Save. Также в этом окне содержатся настройки трансформации номеров. После этого добавленная группа появится в поле Selected Groups. Затем добавляем остальные группы и сохраняем настройки.
Проверить получившийся маршрут можно перейдя во вкладку Call Routing → Route Plan Report. Здесь можно увидеть список паттернов Route Patterns, список Route List на который они указывают, группы Route Groups, которые содержит список и устройства, шлюзы и транки, указанные в группе. Это наглядно показывает в иерархическом порядке структуру маршрутизации.
Привет! Мы уже рассказывали про операционные системы для устройств Cisco – IOS, IOS-XE, CatOS. В этой статье мы рассмотрим NX-OS и IOS-XR, а также сравним их с традиционной IOS.
На верхнем уровне их можно соотнести так:
Cisco IOS: используется в borderless сетях (то есть это сети, которые позволяют кому угодно, где угодно и с любого устройства подключаться к корпоративной сети). Например, маршрутизатор ISR2 Cisco 3900 Series использует Cisco IOS;
Cisco NX-OS: используется в коммутаторах Cisco Nexus, расположенных в центрах обработки данных. Например, коммутатор Cisco Nexus 7000 работает под управлением Cisco NX-OS;
Cisco IOS-XR: используется на маршрутизаторах провайдеров связи. Например, маршрутизатор Cisco XR 12000 Series использует Cisco IOS-XR.
Cisco IOS
Хотя имя «IOS» появилось позже, операционная система относится к середине 1980-х годов. Cisco IOS была разработана с использованием языка программирования C и имела несколько ограничений, указывающих на то, когда она была разработана. Например, он не поддерживал симметричную многопроцессорную обработку. В результате одна инструкция должна была быть завершена до того, как начнется выполнение другой. Еще одним огромным архитектурным ограничением было использование общего пространства памяти, в результате которого один неправильный процесс мог нанести ущерб другим процессам маршрутизатора.
У некоторых платформ марщрутизаторов были обходные пути. Например модульный маршрутизатор Cisco 7513 – он может быть оснащен модулем универсального интерфейса (VIP), который позволяет отдельным линейным картам запускать собственные экземпляры Cisco IOS. Это обеспечило некоторый уровень балансировки нагрузки и избыточности.
Еще одна версия Cisco IOS - это IOS-XE, которая запускает Cisco IOS в Linux. В качестве примера можно найти Cisco IOS-XE, работающую на маршрутизаторе Cisco ASR 1000 Series. Благодаря набору функций Linux, Cisco IOS-XE добавляет поддержку симметричной многопроцессорности и отдельных пространств памяти. Однако, помимо своих Linux-подходов, Cisco IOS-XE в основном похожа на традиционную Cisco IOS.
Cisco NX-OS
Первоначально имевшая название SAN-OS (где акроним SAN обозначался как Storage Area Network), NX-OS предлагает некоторые обширные архитектурные улучшения по сравнению с традиционными Cisco IOS. Хотя первоначально это была 32-разрядная операционная система, с тех пор она превратилась в 64-разрядную ОС. В отличие от Cisco IOS, NX-OS не использует одно пространство памяти и поддерживает симметричную многопроцессорность. Она также имеет превентивную многозадачность, что позволяет высокоприоритетному процессу получить время процессора перед процессом с более низким приоритетом.
NX-OS построена на ядре Linux, и поддерживает язык Python для создания сценариев на коммутаторах Cisco Nexus. Кроме того, она имеет несколько функций высокой доступности (high availability), и не загружает сразу все ее функции. Вместо этого можно указать, какие функции вы хотите активировать. Устранение ненужных функций освобождает память и процессор для тех функций, которые вам нужны. Однако когда дело доходит до конфигурации, существует много сходства между NX-OS и Cisco IOS.
Cisco IOS-XR
Первоначально разработанная для 64-разрядной работы, IOS-XR предлагает множество улучшений, обнаруженных в NX-OS (например, симметричная многопроцессорность, отдельные пространства памяти и активация только тех сервисов, которые необходимы). Однако, хотя NX-OS построена на ядре Linux, IOS-XR построен на микроядре QNX Neutrino Microkernel.
Функция IOS-XR, которой нет в NX-OS, - это возможность иметь один экземпляр операционной системы, управляющей несколькими шасси. Кроме того, поскольку IOS-XR ориентирована на среды провайдеров, она предлагает поддержку таких интерфейсов, как DWDM и Packet over SONET.
В то время как конфигурация IOS-XR имеет некоторое сходство с традиционной IOS, различия намного заметнее, чем различия в NX-OS. Например, когда вы закончили вводить команды конфигурации, вам необходимо зафиксировать свои изменения, чтобы они вступили в силу и до выхода из режима конфигурации.
Примеры конфигурации
Чтобы проиллюстрировать некоторые основные конфигурации этих трех операционных систем, рассмотрим следующие примеры.
Эти команды были предоставлены маршрутизатору Cisco IOS, коммутатору NX-OS и экземплярам маршрутизатора IOS-XR, работающим в Cisco VIRL. В каждом из следующих примеров показана текущая версия маршрутизатора или коммутатора. Затем мы входим в глобальный режим конфигурации и изменяем имя хоста маршрутизатора или коммутатора, а затем создаем интерфейс Loopback 0, назначая IP-адрес этому интерфейсу, выходя из режима привилегий и выдавая команду show ip interface brief.
При назначении IP-адресов интерфейсам Loopback на устройствах следует заметить, что Cisco IOS требует, чтобы маска подсети была введена в десятичной системе с точками, в то время как NX-OS и IOS-XR поддерживают ввод маски подсети с использованием слеша.
Также нужно обратить внимание, что перед выходом из режима конфигурации необходимо выполнить команду commit на IOS-XR. Кроме того, только когда мы применяем эту команду, применяется наша обновленная конфигурация имени хоста.
IOS:
Router>show version
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Thurs 5-Jan-12 15:41 by pt_team
ROM: System Bootstrap, Version 15.1(4)M4, RELEASE SOFTWARE (fc1)
cisco2911 uptime is 40 seconds
System returned to ROM by power-on
System image file is "flash0:c2900-universalk9-mz.SPA.151-1.M4.bin"
Last reload type: Normal Reload
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to
export@cisco.com.
Cisco CISCO2911/K9 (revision 1.0) with 491520K/32768K bytes of memory.
Processor board ID FTX152400KS
3 Gigabit Ethernet interfaces
DRAM configuration is 64 bits wide with parity disabled.
255K bytes of non-volatile configuration memory.
249856K bytes of ATA System CompactFlash 0 (Read/Write)
License Info:
License UDI:
-------------------------------------------------
Device# PID SN
-------------------------------------------------
*0 CISCO2911/K9 FTX15246R1P
Technology Package License Information for Module:'c2900'
----------------------------------------------------------------
Technology Technology-package Technology-package
Current Type Next reboot
-----------------------------------------------------------------
ipbase ipbasek9 Permanent ipbasek9
security None None None
uc None None None
data None None None
Configuration register is 0x2102
Router>en
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#hostname IOS-ROUTER
IOS-ROUTER(config)#interface loopback0
IOS-ROUTER(config-if)#
%LINK-5-CHANGED: Interface Loopback0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
IOS-ROUTER(config-if)#ip address 10.1.1.1 255.255.255.255
IOS-ROUTER(config-if)#end
IOS-ROUTER#
%SYS-5-CONFIG_I: Configured from console by console
IOS-ROUTER#show ip int brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/1 unassigned YES unset administratively down down
GigabitEthernet0/2 unassigned YES unset administratively down down
Loopback0 10.1.1.1 YES manual up up
Vlan1 unassigned YES unset administratively down down
IOS-ROUTER#
NX-OS:
switch#show version
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2010, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained herein are owned by
other third parties and are used and distributed under license.
Some parts of this software are covered under the GNU Public
License. A copy of the license is available at
http://www.gnu.org/licenses/gpl.html.
Software
BIOS: version 1.3.0
loader: version N/A
kickstart: version 5.0(2)N2(1) [build 5.0(2)N2(1)]
system: version 5.0(2)N2(1) [build 5.0(2)N2(1)]
power-seq: version v1.2
BIOS compile time: 09/08/09
kickstart image file is: bootflash:/sanity-kickstart
kickstart compile time: 12/6/2010 7:00:00 [12/06/2010 07:35:14]
system image file is: bootflash:/sanity-system
system compile time: 12/6/2010 7:00:00 [12/06/2010 08:56:45]
Hardware
cisco Nexus5010 Chassis ("20x10GE/Supervisor")
Intel(R) Celeron(R) M CPU with 2073416 kB of memory.
Processor Board ID JAF1228BTAS
Device name: BEND-2
bootflash: 1003520 kB
Kernel uptime is 0 day(s), 3 hour(s), 30 minute(s), 45 second(s)
Last reset
Reason: Unknown
System version:
Service:
plugin
Core Plugin, Ethernet Plugin, Fc Plugin
switch# conf t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# hostname NEXUS-SWITCH
NEXUS-SWITCH(config)#interface loopback0
NEXUS-SWITCH(config-if)# ip address 10.2.2.2/32
NEXUS-SWITCH(config-if)#end
NEXUS-SWITCH# show ip int brief
IP Interface Status for VRF “default” (1)
Interface IP Address Interface Status
Lo0 10.2.2.2 protocol-up/link-ip/admin-up
NEXUS-SWITCH#
IOS-XR:
RP/0/RP/CPU0:router# show version
Mon May 31 02:14:12.722 DST
Cisco IOS XR Software, Version 4.1.0[Default]
Copyright (c) 2010 by Cisco Systems, Inc.
ROM: System Bootstrap, Version 2.100(20100129:213223) [CRS-1 ROMMON],
router uptime is 1 week, 6 days, 4 hours, 22 minutes
System image file is "bootflash:disk0/hfr-os-mbi-4.1.0/mbihfr-rp.vm"
cisco CRS-8/S (7457) processor with 4194304K bytes of memory.
7457 processor at 1197Mhz, Revision 1.2
2 Management Ethernet
8 GigabitEthernet
12 SONET/SDH
12 Packet over SONET/SDH
1 WANPHY controller(s)
1 TenGigE
1019k bytes of non-volatile configuration memory.
38079M bytes of hard disk.
3607592k bytes of disk0: (Sector size 512 bytes).
3607592k bytes of disk1: (Sector size 512 bytes).
RP/0/RP/CPU0:router#conf t
RP/0/RP/CPU0: router(config)#hostname IOS-XR-ROUTER
RP/0/RP/CPU0: router(config)#interface loopback0
RP/0/RP/CPU0: router(config-if)#ip address 10.3.3.3/32
RP/0/RP/CPU0: router(config-if)#commit
RP/0/RP/CPU0: IOS-XR-ROUTER (config-if)#end
RP/0/RP/CPU0: IOS-XR-ROUTER (config)#show ip int brirf
Interface IP-Address Status Protocol Vrf-Name
Loopback0 10.3.3.3 Up Up default
MgmtEth0/0/CPU0/0 unassigned Shutdown Down default
GigabitEthernet0/0/0/0 unassigned Shutdown Down default
RP/0/RP/CPU0: IOS-XR-ROUTER#