По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сетевые устройства 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), прежде чем отобразится командный интерфейс.
Сталкивались ли вы задачей одновременной типовой настройки телефонный аппаратов? Например, настроить 50 штук IP – телефонов Yealink. Эта задача будет достаточно рутинной и затратной по времени. В FreePBX создан модуль End Point Manager, который позволяет создать шаблон настроек для определенных групп устройств и затем перенести его на телефонные аппараты. О нем и поговорим.
/p>
Пару слов про модуль End Point Manager
Как уже сказано выше, модуль EPM позволяет производить автоматическую настройку различных единиц оборудования, от конечных телефонных аппаратов до шлюзов. Условно говоря, настройка модуля делится на следующие сегменты:
Global Settings - глобальные настройки модуля, такие как IP – адрес Asterisk и прочие
Extension Mapping - раздел, в котором сопоставляется шаблон и MAC – адрес устройства
Brands - в разделе можно посмотреть марки оборудования, которые были сконфигурированы с помощью EPM
Модуль является платным и стоит 75$ на 25 лет. В бесплатной версии модуля, доступна только настройка телефонов марки Sangoma. Полный перечень приведен в таблице ниже.
Add Brand - добавьте необходимые брэнды оборудования, для которого вы бы хотели создать шаблон
Image Management - здесь можно загрузить картинку в формате GIF, JPEG, или PNG и размером не более 20 мегабайт, которая будет использоваться на оконечных телефонов, например в роли фонового изображения. Данный функционал работает только на устройствах с поддержкой фонового изображения
Basefile Edit - данный раздел позволяет менять различные значения, которые нельзя изменить через стандартные настройки телефона, например через его GUI. Представляет из себя XML – файл. Рекомендуем настраивать данный раздел только в том случае, если вы точно знаете что делаете.
Custom Extensions - раздел аналогичен настройке в модуле Custom Extension
Firmware Management - раздел служит для обновления прошивки телефонов.
Network Scan - сетевая утилита, которая позволяет сканировать указанную сеть на предмет наличия в ней поддерживаемых устройств и уточнения их MAC - адресов
Без приобретения лицензии на модуль вы сможете работать со следующими устройствами:
Производитель
Модель
Поддержка фонового изображения
Sangoma
s300
Нет
Sangoma
s500
Да
Sangoma
s700
Да
Sangoma
Vega 50-4FXS
-
Sangoma
Vega 50-8FXS
-
Sangoma
Vega 3000-24FXS
-
Sangoma
Vega 5000-24FXS
-
Sangoma
Vega 5000-50FXS
-
Поддерживаемые без лицензии устройства
В случае оплаты модуля, для работы будут доступны Aastra, Algo, Audio Codes, Cisco, Cortelco, CyberData, Digium, Grandstream, Mitel, Mocet, Obihai, Panasonic, Phoenix Audio, Polycom, Snom, Uniden, VTech, Xorcom и всеми любимый Yealink.
Настройка Global Settings
В настройках EPM переходим в раздел Global Settings:
Internal IP Address - укажите IP – адрес вашего Asterisk. В нашем случае это 192.168.0.77
External IP Address - если какие-то из ваших телефонов будут подключаться к АТС из внешней сети, то в данном поле укажите внешний IP – адрес или FQDN (Fully Qualified Domain Name)
Ports - в разделе будут указаны порты для WEB – доступа, порт для HTTP провижининга
(автоматической настройки телефонов) и RESTful приложений
Phone Admin Password - все управляемые телефоны имеют пароль для администратора. В данном поле вы можете указать его для всех устройств
Phone User Password - некоторые модели телефонов, например Cisco, имеют систему авторизации для администратора через обычного пользователя. Здесь нужно указать его пароль
ReSync Time - через указанное время телефоны будут обращаться к серверу на предмет изменения в их конфигурационных файлах. По умолчанию, время равно 86400 секунд, что есть 1440 минут, что в свою очередь ровняется 24 часа :)
XML-API (RestAPI) Default Login - включение/выключение данной опции позволяет телефону обращаться к различным приложениям через RestAPI
Extension Mapping IP Addresses - отображать ли IP – адрес устройства на этапе сопоставления телефона и внутреннего номера
Extension Mapping Phone Status - отображать ли время пинга до устройства. Оба параметра замедляют работу.
По окончанию настроек нажмите Save Global
Настройка шаблона настроек
Переходим к настройкам. Сделаем шаблон на примере производителя Sangoma. Для этого, в настройках модуля, в блоке Brands, выберем Sangoma. Для добавления нового шаблона нажимаем New Template. Производим настройки в первой вкладке, которая называется General:
Template Name - даем имя для нашего шаблона. Например, New_template
Default Template - будет ли данный шаблон шаблоном по умолчанию для телефонов. Выставляем Default
Destination Address - в данном поле необходимо указать IP – адрес или доменное имя для нашей IP – АТС Asterisk. При нажатии на кнопки Internal или External, при сохранении, в поле будет автоматически подставлено значение внутреннего или внешнего IP – адреса АТС соответственно. Это удобно в том случае, если мы делаем разные шаблона для внутренних телефонов и для внешних.
Provision Server Address - сервер, к которому телефон будет обращаться за конфигурацией. По умолчанию это наш Asterisk
Provision Server Protocol - протокол, который будет использовать IP – телефон чтобы получить файл конфигурации. Оставьте в данном поле TFTP
Переходим во вкладку Regional
Time Zone - временная зона. Поле прибавляет, или удаляет определенное количество часов к GMT (среднее время по Гринвичу). Например, в Москве GMT +03:00 и мы выбираем +03.00
Primary Time Server - главный сервер синхронизации времени по протоколу NTP. Вы можете посмотреть список серверов в интернете
Daylight Savings -опция подсказывает телефону, использовать ли настройки DST (Daylight Saving Time) – то есть сезонное время
Country Tones - опция настройки гудка. В разных странах они различаются, выберите подходящий
Web GUI Language - язык графического интерфейса администрирования IP - телефона
LCD Display Language - язык на дисплее телефона
Date Format - формат даты. Нам привычно ДД-ММ-ГГ
Time Format - формат времени. Мы выбрали 24 часовой формат
Двигаемся дальше и переходим во вкладку Options. Разберем здесь самые основные опции:
Background Image - выберите фоновое изображение, которое ранее, было залито с помощью пункта меню Image Management
Line Label - информация, которая будет отображаться о пользователе телефона на главном дисплее. Может быть следующих видов:
Name - имя пользователя. Например, «Иван Петров»
Extension - показывать только номер абонента. Например, «101»
Name-Extension - показывать и имя и номер. Например, «Иван Петров 101»
Multicast Enable - поддержка Multicast пейджинга
Функционал Multicast Paging появился в 13 версии FreePBX. Если коротко, то теперь телефон может отправлять на заранее сконфигурированный широковещательный адрес пейджинг запросы. Более подробно вы можете почитать в статье про новинки FreePBX 13
Multicast Address - мультикаст адрес, о котором мы рассказали выше
Dial Patterns - шаблон набора номеров для IP - телефона
Ring Tone - выбрать номер звукового сопровождения для звонка (рингтон)
Screen Saver - что показывать на дисплее телефона по таймауту бездействия Screen Saver Timeout
Call Waiting Signal - хотите ли вы услышать звуковой сигнал, при условии того, что вы уже разговариваете с одним из абонентов и вам поступает второй звонок
BLF Alert - тип индикатора BLF. Это может быть визуальное мигание, аудио сопровождение или оба сразу
По окончанию настроек не забываем нажимать Save Template
Соответствие телефона и шаблона
После того, как мы произвели настройку шаблона его необходимо проассоциировать с телефонным аппаратом. Мы будем делать это с помощью MAC – адреса устройства. Переходим в раздел Extension Mapping и нажимаем Add Extension
В столбце слева выбираем необходимый номер
По середине, выбираем производителя и вводим MAC – адрес телефона
В левом столбце выбираем шаблон и модель телефона
Теперь, чтобы доставить на телефоны адрес TFTP сервера (адреса нашего Asterisk в данном случае), в настройках DHCP сервера необходимо настроить параметр option 150 с IP – адресом TFTP. Телефон обратиться на сервер с просьбой предоставить файл конфигурации для устройства с его MAC – адресом, которое мы создали на этапе ранее.
Пока не создан единый протокол маршрутизации, управляющий остальными, существует необходимость в том, чтобы несколько протоколов маршрутизации мирно сосуществовали в одной сети. К примеру, одна компания работает с OSPF, а другая компания работает с EIGRP, и эти две компании слились в одно целое предприятие. Пока вновь образованный ИТ-персонал не перейдет для использования на единый протокол маршрутизации (возможно они когда-нибудь это сделают), маршруты, известные протоколу OSPF, необходимо объявить в часть сети, работающей под управлением EIGRP, и наоборот.
Упомянутый выше сценарий возможен благодаря Route redistribution, и именно этому посвящена данная статья. Другие причины, по которым вам потребуется выполнить Route redistribution, это: различные части сети конкретной компании находятся под различным административным контролем; если необходимо объявить маршруты своему поставщику услуг через BGP, или, возможно, необходимо подключиться к сети делового партнера.
Рассмотрим следующую базовую топологию.
В простой топологии, показанной выше, мы хотим, чтобы OSPF и EIGRP объявляли друг другу маршруты, о которых они знают. Эта концепция называется взаимным перераспределением маршрутов. Поскольку роутер CENTR имеет один интерфейс в автономной системе OSPF (AS) и один интерфейс в EIGRP AS, он несет ответственность за выполнение Route redistribution.
Seed Metrics
Основная проблема, с которой мы сталкиваемся при Route redistribution между различными протоколами маршрутизации, заключается в разнообразных подходах, применяемых протоколами маршрутизации для измерения своих метрик. Например, OSPF использует cost-метрику, которая основана на bandwidth, в то время как EIGRP использует метрику, основанную на bandwidth и delay, но также может учитывать надежность или (и) нагрузку (и даже использовать Maximum Transmission Unit (MTU) в качестве прерывания связи). Итак, что же нам делать?
Мы, как администраторы, можем настроить метрику, назначенную маршрутам, поступающим из одной AS, которые перераспределяются в другую AS. Если нам лень вручную настраивать метрику, которая будет использоваться для Route redistribution, то используется seed metric. В следующей таблице показаны seed metrics, используемые различными протоколами маршрутизации.
Основываясь на приведенной выше таблице, мы видим, что, маршрутам, которые перераспределяются в OSPF по дефолту будет назначена метрика 20, если же маршруты, перераспределяются в протокол OSPF от протокола BGP, то им будет присвоено значение метрики 1. Интересно, что и RIP, и EIGRP по умолчанию имеют seed metrics бесконечности. Это означает, что любой маршрут, перераспределенный в эти протоколы маршрутизации, будет считаться недостижимым по умолчанию и поэтому не объявляются никаким другим роутерам. BGP, однако, перераспределяет маршрут, полученный из протокола внутреннего шлюза (IGP), используя исходную метрику этого маршрута.
Пример базовой настройки
Конечно, есть еще много вопросов, связанных с перераспределением маршрутов, таких как циклы маршрутизации, которые могут возникнуть, когда у нас есть несколько роутеров, соединяющих наши автономные системы, или выборочная фильтрация определенных маршрутов от перераспределения. Но мы вернемся ко всему этому в следующих статьях. А пока давайте разберемся, как выполнить базовую настройку Route redistribution (перераспределения маршрутов). Рассмотрим предыдущую топологию, на этот раз с добавлением информации о сети и интерфейсе:
В этой топологии роутер CENTR изучает маршруты от OFF1 через OSPF и от OFF2 через EIGRP. Это видно в выходных данных команды show ip route, отображенной на CENTR:
Однако ни роутер OFF1, ни роутер OFF2 не изучили никаких маршрутов, потому что роутер CENTR еще не выполняет Route redistribution. Об этом свидетельствует вывод команды show ip route, отображенной на OFF1 и OFF2:
Теперь давайте добавим конфигурацию Route redistribution к роутеру CENTR. Чтобы подтвердить предыдущее утверждение о том, что seed metric для маршрутов, перераспределяемых в EIGRP, является бесконечностью, мы изначально не будем настраивать какие-либо метрики и позволим seed metric вступить в силу.
CENTR# conf term
Enter configuration commands, one per line. End with CNTL/ Z
CENTR(config)#router ospf 1
CENTR(config-router)#redistribute eigrp 1
CENTR(config-router)#exit
CENTR(config)#router eigrp 1
CENTR(config-router)# redistribute ospf 1
CENTR(config-router)#end
CENTR#
Команда redistribute применена в режиме конфигурации роутера для каждого протокола маршрутизации, и метрика не была указана. Важно, что, когда мы ввели команду redistribute eigrp 1 выше, мы не включили ключевое слово subnets в команду, которая заставляет как классовые, так и бесклассовые сети перераспределяться в OSPF. Однако, как видно из приведенных ниже выходных данных, ключевое слово subnets было автоматически добавлено для нас:
Данное поведение автоматического добавления ключевого слова subnets наблюдается в последних версиях Cisco IOS. Некоторые, более старые версии Cisco IOS, не включают автоматически ключевое слово subnets, и вам может потребоваться вручную добавить его в команду redistribute. Давайте теперь взглянем на таблицы IP-маршрутизации на роутерах OFF1 и OFF2, чтобы увидеть, какие маршруты они изучили (и не изучили).
Приведенные выше выходные данные показывают нам, что роутер CENTR успешно перераспределил маршруты, известные EIGRP в OSPF, которые затем были изучены роутером OFF1. Обратите внимание, что перераспределенные маршруты, известные роутеру OFF1, имеют метрику 20, которая является seed metrics OSPF. Однако роутер OFF2 не изучал никаких новых маршрутов, потому что, когда роутер CENTR перераспределял маршруты в EIGRP, он использовал seed metrics EIGRP бесконечность (что означает недостижимость). В результате эти маршруты не были объявлены роутеру OFF2.
Чтобы решить эту проблему, нам нужно назначить метрику маршрутам, перераспределяемым в EIGRP. Существует три основных способа присвоения не дефолтных метрик маршрутам, перераспределяемым в протокол маршрутизации..
Установите метрику по умолчанию для всех протоколов маршрутизации, перераспределяемых в определенный протокол маршрутизации.
Установите метрику как часть команды redistribute.
Установите метрику используя route-map
Чтобы проиллюстрировать первый вариант, давайте настроим метрику для назначения всем маршрутам, перераспределяемым в EIGRP.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config)#router eigrp 1
CENTR (config-router)#default-metric ?
1-4294967295 Bandwidth in Kbits per second
CENTR (config-router)#default-metric 1000000 ?
0-4294967295 delay metric in 10 microsecond units
CENTR(config-router)#default-metric 1000000 1 ?
0-255 Reliability metric where 255 is 100% reliable
CENTR (config-router)#default-metric 1000000 1 255 ?
1-255 Effective bandwidth metric (Loading) where 255 is 100% loaded
CENTR (config-router)#default-metric 1000000 1 255 1 ?
1-65535 Maximum Transmission Unit metric of thenpath
CENTR (config-router)#default-metric 1000000 1 255 1 1500
CENTR (config-router)#end
CENTR#
Контекстно-зависимая справка была использована в приведенном выше примере для отображения каждого компонента метрики, назначаемого маршрутам, перераспределяемым в EIGRP. Однако последняя команда была default-metric 1000000 1 255 1 1500. Если бы мы устанавливали default-metric для OSPF, мы могли бы использовать такую команду, как default-metric 30, чтобы назначить стоимость 30 OSPF маршрутам, перераспределяемым в OSPF. Однако в этом примере мы указали только default-metric для EIGRP. Давайте теперь проверим таблицу IP-маршрутизации на роутере OFF2, чтобы увидеть, были ли маршруты OSPF успешно объявлены в EIGRP.
Прекрасно! Роутер OFF2 изучил маршруты, происходящие из OSPF AS. Мы знаем, что маршруты первоначально пришли из-за пределов EIGRP, из-за кода EX, появляющегося в каждом из этих маршрутов.
Второй вариант установки метрики на Route Redistribution состоял в том, чтобы назначить метрику как часть команды redistribute, которая позволяет нам указать различные метрики для различных протоколов маршрутизации, перераспределяемых в процесс маршрутизации. Чтобы проиллюстрировать этот подход, давайте удалим предыдущие команды default-metric и redistribute из роутера CENTR и введем команду redistribute, которая определяет метрику, которая будет назначена.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router eigrp 1
CENTR(config-router)#no default-metric 1000000 1 255 1 1500
CENTR(config-router)#no redistribute ospf 1
CENTR(config-router)#redistribute ospf 1 ?
Match Redistribution of OSPF routes
metric Metric for redistributed routes
route-map Route map reference
cr
CENTR(config-router)#redistribute ospf 1 metric 1000000 1 255 1 1500
CENTR(config-router)#end
CENTR#
Если мы сейчас вернемся к роутеру OFF2, то получим тот же результат, что и раньше:
Третьим вариантом установки метрики для Route Redistribution использовании маршрутной карты (route-map). Маршрутные карты являются супермощными и могут быть использованы для различных конфигураций. По сути, они могут соответствовать определенному трафику и устанавливать один или несколько параметров (например, IP-адрес следующего прыжка) для этого трафика. Однако в нашем контексте мы просто будем использовать route-map для указания значения метрики, а затем применим ее к команде redistribute. В следующем примере показано, как мы можем удалить нашу предыдущую команду redistribute из роутера CENTR, создать route-map, а затем ввести новую команду redistribute, которая ссылается на нашу карту маршрута (route-map):
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router eigrp 1
CENTR(config-router)#no redistribute ospf 1 metric 1000000 1 255 1 1500
CENTR(config-router)#exit
CENTR(config)#route-map SET-МETRIC-DEMO
CENTR(config-route-map)#set metric 1000000 1 255 1 1500
CENTR(config-route-map)#exit
CENTR(config)#router eigrp 1
CENTR(config-router)#redistribute ospf 1 route-map SET-МETRIC-DEMO
CENTR(config-router)#end
CENTR#
В приведенном выше примере, после удаления нашей команды redistribute, мы создали карту маршрута с именем SET-METRIC-DEMO. Это был очень простой route-map, которая не должна была соответствовать никакому траффику. Он был просто использован для установки метрики. Однако в следующей статье мы увидим, что route-map может быть использована, чтобы дать нам больше контроля над нашим перераспределением маршрутов. В нашем текущем примере карта маршрута была затем применена к нашей новой команде redistribute. Опять же, это дает нам тот же результат с точки зрения таблицы IP-маршрутизации роутера OFF2:
OSPF E1 или E2 Routes
Прежде чем мы закончим эту статью в нашей серии Route redistribution, давайте еще раз рассмотрим таблицу IP-маршрутизации на роутере OFF1:
Обратите внимание, что каждый из маршрутов, перераспределенных в OSPF, отображается в таблице IP-маршрутизации роутера OFF1 с кодом E2. Однако наблюдаются также код E1, оба указывающих, что маршрут возник из-за пределов OSPF AS роутера. Итак, в чем же разница между этими двумя кодами?
Код E2 указывает, что маршрут несет метрику, назначенную роутером, выполняющим перераспределение, который известен как автономный системный пограничный роутер (ASBR). Это означает, что независимо от того, сколько дополнительных роутеров в OSPF мы должны пересечь, чтобы вернуться к ASBR, метрика остается такой же, какой она была, когда ASBR перераспределил ее. Когда мы перераспределяем маршруты в OSPF, эти маршруты, по дефолту, являются этими External Type 2 (E2).
Код E1 указывает, что метрика маршрута состоит из первоначальной стоимости, назначенной ASBR, плюс стоимость, необходимая для достижения ASBR. Это говорит о том, что маршрут Е1, как правило, более точен, и на самом деле это так. Хотя наличие кода E1 не дает нам никакого преимущества в простой топологии, как у нас, где роутер OFF1 имеет только один путь для достижения ASBR (т. е. CENTR), и где есть только один способ для маршрутов EIGRP быть введенными в наш OSPF AS (т. е. через роутер CENTR).
Если мы хотим перераспределить маршруты E1 в OSPF вместо маршрутов E2, то это можно сделать с помощью команды redistribute. В следующем примере мы удаляем нашу команду redistribute для процесса маршрутизации OSPF на роутере CENTR, а затем повторно применяем команду redistribute, указывающую, что мы хотим, чтобы External Type 1 (E1) применялись к перераспределенным маршрутам.
CENTR#configuration terminal
Enter configuration commands, one per line. End with CNTL/Z.
CENTR(config)#router ospf 1
CENTR(config-router)#no redistribute eigrp 1 subnets
CENTR(config-router)#redistribute eigrp 1 metric-type ?
1 Set OSPF External Туре 1 metrics
2 Set OSPF External Туре 2 metrics
CENTR(config-router)#redistribute eigrp 1 metric-type 1
CENTR(config-router)#end
CENTR#show
Давайте проверим таблицу IP-маршрутизации на роутере OFF1, чтобы увидеть, изменились ли параметры на основе этой новой команды redistribute, введенной на роутере CENTR.
В приведенных выше выходных данных обратите внимание, что маршруты, перераспределенные в OSPF, имеют код E1, а не дефолтный код E2. Кроме того, обратите внимание, что это приводит к тому, что метрика этих маршрутов будет немного выше. В частности, роутер CENTR перераспределил EIGRP-изученные маршруты в OSPF, используя начальную метрику OSPF 20.
Однако существует стоимость OSPF 1, чтобы добраться от роутера OFF1 до роутера CENTR. Таким образом, поскольку перераспределенные маршруты были сконфигурированы как маршруты E1, стоимость этих маршрутов с точки зрения роутера OFF1 является стоимостью, первоначально назначенной роутером OFF1, которая составляла 20, плюс стоимость для OFF1, чтобы добраться до CENTR, который равен 1, итого общей стоимости 21.
Отлично, теперь вы знаете, как делать перераспределение маршрутов. Теперь почитайте, как сделать Фильтрацию маршрутов с помощью карт маршрутов.