По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сетевые устройства Huawei обычно поставляются неконфигурированными по умолчанию, поэтому, для использования устройства необходимо сначала настроить некоторые из его основных функций.
1. Настройка имени хоста
В интерфейсе командной строки имя хоста (имя устройства) заключено в угловые скобки (...) или квадратные скобки ([...]). Имя хоста по умолчанию - Huawei, но это имя следует изменить, чтобы лучше различать несколько устройств. Чтобы изменить имя хоста, используйте команду sysname host-name. В следующем примере показано, как изменить имя хоста на Huawei-AR-01.
system-view
Enter system view, return user view with Ctrl+Z.
[Huawei] sysname Huawei-AR-01
[Huawei-AR-01]
2. Настройка системного времени
По умолчанию устройства Huawei используют Coordinated Universal Time (UTC). Чтобы указать другой часовой пояс для устройства, выполните команду сlock timezone time-zone-name {add | minus} offset. Вы можете назвать часовой пояс в параметре time-zone-name и указать, является ли смещение часового пояса к UTC положительным (add offset) или отрицательным (minus offset). Обратите внимание, что {...} указывает на то, что один из вложенных параметров должен быть выбран. Например, если вы хотите установить часовой пояс устройства как Пекинское время, выполните следующую команду:
[Huawei-AR-01] clock timezone BJ add 08:00
После установки часового пояса выполните команду clock datetime HH:MM: SS YYYY-MM-DD для установки времени и даты. Параметр HH:MM:SS задает время в 24-часовом формате, а YYYY-MM-DD-дату. (Устройства Huawei поддерживают только 24-часовой формат.) Например, чтобы установить время и дату 18: 30 10 марта 2019 года, выполните следующую команду:
[Huawei-AR-01] clock datetime 18:30:00 2019-03-10
3. Задание IP-адреса на устройстве
Для входа в систему, вы можете использовать Telnet . Однако Telnet требует, чтобы на интерфейсе устройства был установлен IP-адрес. Для присвоения IP-адреса, выполните команду ip-address {mask | mask-length} в интерфейсном виде. Параметры ip-address и mask задают IP-адрес и маску подсети соответственно в десятичной системе счисления, а mask-length задает число последовательных "1"в двоичной системе счисления маски подсети. В следующем примере показано, как установить IP-адрес 10.1.1.100 и маску подсети 255.255.255.0 для интерфейса управления Ethernet 1/0/0:
<Huawei-AR-01> system-view
[Huawei-AR-01] interface ethernet 1/0/0
[Huawei-AR-01-Ethernet1/0/0] ip address 10.1.1.100 255.255.255.0
Длина двоичной записи маски подсети равна 24 (255.255.255.0 эквивалентна двоичному значению 11111111.11111111.11111111.00000000), поэтому в этом примере вы можете заменить 255.255.255.0 на 24.
4. Конфигурации интерфейса пользователя
Если вы входите в устройство через консольный порт, отображается консольный пользовательский интерфейс. При входе в систему через Telnet отображается пользовательский интерфейс терминала виртуального типа (VTY). Чтобы реализовать управление пользователем через консольный порт, например, установить User Layer равным 2, можно выполнить следующие команды:
system-view
[Huawei] user-interface console 0
[Huawei-ui-console0] user privilege level 2
Другие пользователи также могут войти в устройство, даже тогда когда вы находитесь в нем. Каждый пользователь имеет отдельный пользовательский интерфейс (количество поддерживаемых интерфейсов VTY варьируется в зависимости от устройства), поэтому для дифференциации нескольких пользовательских интерфейсов устройство реализует нумерацию пользовательских интерфейсов.
Нумерация интерфейса пользователя.
Когда пользователь входит в устройство, устройство выделяет пользователю самый низкий пронумерованный простой пользовательский интерфейс в соответствии с используемым методом входа в систему. Пользовательские интерфейсы нумеруются либо относительно, либо абсолютно.
НОтносительная нумерация
Формат нумерации - тип пользовательского интерфейса + номер. Как правило, устройство имеет один консольный порт (некоторые устройства могут иметь больше) и 15 пользовательских интерфейсов VTY (5 пользовательских интерфейсов VTY включены по умолчанию). При использовании относительной нумерации порты отображаются следующим образом:Консольный пользовательский интерфейс: CON 0Пользовательские интерфейсы VTY: первый пользовательский интерфейс VTY - это VTY 0, второй VTY 1 и т. д.
Абсолютная нумерация
Абсолютное число однозначно идентифицирует пользовательский интерфейс. Абсолютные и относительные числа находятся в взаимно однозначном отображении. Пользовательский интерфейс консоли имеет относительное число CON 0 и абсолютное число 0. Пользовательский интерфейс VTY имеет относительное число в диапазоне от VTY 0 до VTY 14 и абсолютное число в диапазоне от 129 до 143.Чтобы проверить пользовательские интерфейсы, поддерживаемые устройством, выполните команду display user-interface. Например:
В выходных данных команды столбец Idx показывает абсолютные числа, а столбец Type-относительные числа.
Проверка подлинности пользователя.
Для гарантированного входа авторизованным пользователям, устройство поддерживает проверку подлинности паролем и проверку подлинности AAA. Так же можно входить и без проверки подлинности.
Проверка подлинности паролем
Этот режим используется по дефолту и требует от пользователей ввода правильного пароля для входа в систему. Если пароль не настроен, вход в систему будет запрещен.
Проверка подлинности ААА
Этот режим требует правильного сочетания имени пользователя и пароля. Использование комбинации имени пользователя и пароля повышает безопасность по сравнению с проверкой подлинности паролем. Кроме того, пользователи дифференцированы и не влияют друг на друга во время проверки подлинности. Проверка подлинности AAA обычно используется для входа по Telnet из-за ее повышенной безопасности.
Отсутствие проверки подлинности
Этот режим не выполняет проверки подлинности пользователей и не рекомендуется. Отсутствие проверки подлинности позволяет пользователям входить в систему напрямую без каких-либо учетных данных.Механизм проверки подлинности пользователя проверяет логин пользователя. По дефолту после входа пользователя на устройство с помощью Telnet ему присваивается Layer0.
Пример: настройка пользовательских интерфейсов VTY
Во время ввода устройства в эксплуатацию многие пользователи могут войти на устройство для настройки сервисов. Чтобы ограничить число пользователей, которые могут войти в систему через Telnet, до 15, настройте 15 пользовательских интерфейсов VTY. Затем, чтобы разрешить пользователям настраивать службы, установите User Layer равным 2.
Установите максимальное число пользовательских интерфейсов VTY равным 15.
Выполните команду пользовательского интерфейса user-interface maximum-vty number . Укажите number равным 15.
system-view
[Huawei] user-interface maximum-vty 15
Войдите в режим интерфейса пользователя VTY
Запустите команду пользовательского интерфейса vty first-ui-number [last-ui-number]. Укажите first-ui-number как 0 и last-ui-number как 14 (относительные номера пользовательских интерфейсов VTY). Обратите внимание, что [...] указывает, что вложенный параметр является необязательным; однако в этом примере этот параметр необходим для ограничения числа разрешенных пользователей.
[Huawei] user-interface vty 0 14
[Huawei-ui-vty0-14]
Установите уровень пользователя 2 для пользовательского интерфейса VTY.
Запустите команду user privilege level level. Укажите level равным 2.
[Huawei-ui-vty0-14] user privilege level 2
Установите режим проверки подлинности пользователя на AAA для пользовательского интерфейса VTY.
Запустите команду authentication-mode {aaa | none | password}
[Huawei-ui-vty0-14] authentication-mode aaa
Настройте user name и password, используемые при аутентификации AAA. Выйдите из пользовательского интерфейса VTY и выполните команду aaa, для перехода в режим AAA. Запустите local-user user-name password cipher password для настройки user name и password (cipher указывает, что указанный password зашифрован). После выполните telnet local-user-name-service-type для настройки типа службы Telnet.
После завершения настройки необходимо ввести имя пользователя (admin) и пароль (admin@123), прежде чем отобразится командный интерфейс.
Учишься азам VoIP? Cisco Packet Tracer это отличное решение, в рамках которого ты сможешь попрактиковать свои навыки перед продакшном, подготовиться к экзаменам или просто поймать фан, делая то, чего не можешь сделать на работе (STP петли, широковещательные штормы и прочие радости).
Итак, спешим показать способ, как собрать базовую лабу для тренировки своих VoIP (Voice over IP) навыков. Погнали.
Наполняем лабу железом
В явном виде тебе понадобится L3 девайс (у нас будет маршрутизатор 2811), L2 (коммутатор 2950) и телефончики, которых мы добавим 3 штуки (модели 7960). Перетаскивай все это дело в рабочее поле и соединяй патч – кордом, как показано на скриншоте:
Отлично. Нажми 2 раза на IP – телефон и перейди во вкладку GUI, как показано на скриншоте ниже:
Наш телефон ругается на то, что у него нет питания. Не проблема, подключим к нему блок питания. Переходим в раздел Physical и обращаем внимание на адаптер питания, который выделен красным на скриншоте ниже:
Перетаскиваем его прямо к разъему под питание. Должно получиться примерно вот так:
Как только мы включили питание на телефонах, у нас поднялись линки – обратите внимание на зеленые точки от телефонов до свича:
На этапе подготовки нашей среды работы все. Переходим к конфигурации.
Настройка оборудования
Начинаем с маршрутизатора. Открываем его консоль, поднимаем интерфейс и присвоим IP – адрес:
en
conf t
interface FastEthernet 0/0
ip address 192.168.0.1 255.255.255.0
no shutdown
Поднимаем DHCP сервер на маршрутизаторе для IP – телефонов:
en
conf t
ip dhcp pool voice
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
exit
Теперь нужно дать дополнительную команду для опции 150. Она позволяет подтягивать и автоматически подтягивать прошивки для телефонов с TFTP сервера. Выполняем:
en
conf t
ip dhcp pool voice
option 150 ip 192.168.0.1
Время поднастроить классические VoIP параметры, такие как:
max-dn - максимально – возможное количество поддерживаемых DN (Directory Numbers). Номеров, другими словами;
max-ephones - максимальное количество телефонных аппаратов. Сделаем по количеству DN’ов;
ip source-address - откуда наш роутер будет принимать звонки (запросы) от SCCP девайсов;
auto assign - присвоение линий в автоматическом режиме;
en
conf t
telephony-service
max-dn 15
max-ephones 15
ip source-address 192.168.0.1 port 3100
auto assign 1 to 19
Балдеж. Двигаемся к настройке свича (коммутатор). Нам нужно только включить поддержку VoIP на интерфейсах (голосовой VLAN):
en
conf t
interface range FastEthernet 0/1 - FastEthernet 0/3
switchport mode access
switchport voice vlan 1
exit
Дело за малым. Присвоим телефонные номера нашим аппаратам:
en
conf t
ephone-dn 1
number 11111
exit
ephone-dn 2
number 2222
exit
ephone-dn 3
number 3333
exit
Готово. Можно звонить. Попробуем позвонить с 1111 на 2222:
Продолжайте практиковать свои навыки в VoIP в сетях Cisco :)
Четвертая часть тут
Описанные до сих пор технологии—коммутация каналов и пакетов, плоскости управления и 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). Это не компоненты сложности, а то, что можно назвать следствиями сложности.
Администраторы должны быть искусны в выявлении такого рода компромиссных треугольников, точно понимать «углы» треугольника, определять, где в плоскости возможного лежит наиболее оптимальное решение, и быть в состоянии сформулировать, почему некоторые решения просто невозможны или нежелательны.
Если вы не нашли компромиссов, вы недостаточно усердно искали — это хорошее эмпирическое правило, которому следует следовать во всех инженерных работах.