По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Допустим, Вы решили обзавестись IP телефонией для своего офиса. Вы закупили необходимое количество телефонов, настроили voice VLAN, DHCP, TFTP серверы и определились с номерным планом. Однако, прежде чем Ваш IP Phone зазвонит, ему еще предстоит пройти процедуру загрузки, так называемый Bootup или Startup process, которому и будет посвящена данная статья.
В качестве примера будет рассмотрен процесс загрузки Cisco IP Phone под управлением Cisco CallManager. Понимание данного процесса даст более полное представление о работе телефонов Cisco и IP телефонии в целом, а также поможет в оперативном траблшутинге неисправностей.
Итак, пусть имеется некая сеть, содержащая: сервер с Cisco CallManager, сервер DHCP, сервер TFTP, коммутатор с поддержкой PoE (Power over Ethernet) и Cisco IP Phone, как показано на рисунке ниже.
Допустим, что наш коммутатор и телефон поддерживают протокол PoE. Тогда, сразу после того, как телефон будет подключен к одному из Ethernet портов, коммутатор отреагирует специальным сигналом FLP (Fast Link Pulse), который определяет, имеет ли подключенное устройство питание.
Возвращение FLP в форме петли (loopback) на порт коммутатора, к которому недавно было подключено новое устройство, сигнализирует о том, что на данный порт необходимо незамедлительно подать питание. Таким образом, IP Phone по протоколу PoE 802.3af получает питание в 48 Вольт.
Cisco IP Phone имеет встроенную, энергонезависимую Flash-память, в которой хранится образ прошивки и начальные пользовательские настройки. В процессе начальной загрузки телефон, загружая из Flash-памяти образ прошивки, инициализирует своё программное обеспечение и аппаратные средства.
Как только телефон получил питание и прошел POST (Power-on self-test) для проверки базовой функциональности, коммутатор, по проприетарному протоколу CDP (Cisco Discovery Protocol), отправляет на телефон информацию о том, какой voice VLAN необходимо использовать.
Затем, IP Phone отправляет на широковещательный адрес 255.255.255.255 запрос DHCPDISCOVER, в свою очередь DHCP сервер возвращает ответ DHCPOFFER, который содержит следующую информацию:
Свободный IP адрес
Маска подсети
Адрес шлюза по умолчанию (Default Gateway)
Адрес DNS (Domain Name System) сервера. (опционально)
Адрес TFTP (Trivial File Transfer Protocol) сервера, на котором хранится файл конфигурации для телефонов.
Адрес TFTP сервера задается при конфигурировании DHCP по средствам, так называемой опции 150 (option 150). Синтаксис команды приведен ниже:
option 150 ip 'TFTP server IP address'
После того как телефон с помощью option 150 получил адрес TFTP сервера, он скачивает конфигурационный файл, содержащий параметры для подключения к CallManager.
Если телефон был зарегистрирован на CallManager’е вручную, то он начинает проверять файл .cnf.xml, который определяет какую версию программного обеспечения должны использовать все телефоны, зарегистрированные в данном CallManager’е. Если обнаруживается, что загруженный образ не соответствует общепринятому, то телефон вновь обращается на TFTP сервер для получения корректного образа, хранящегося там в формате .bin.
После обращения к TFTP, загрузив новый образ, телефон инициирует установление TCP соединения с CallManager’ом. Данное соединение открывает возможность использования функционала Cisco IP Phone в полной степени.
Как видите, с того момента как наш IP Phone был подключен в один из портов коммутатора и до того момента, когда мы можем совершать звонки, он проходит еще множество всевозможных этапов загрузки, большинство из которых, конечный пользователь даже не заметит.
Привет! В этой статье мы расскажем про настройку переадресации вызовов (Call Forwarding) в Cisco CME (CUCME) . Есть два метода, которыми можно настроить перенаправление вызова: прямо с IP-телефона (пользовательский метод) и через командную строку IOS CLI (метод для администратора).
Настройка переадресации через IP-телефон
Чтобы включить переадресацию на телефоне нужно нажать клавишу CFwdAll (softkey). Телефон издаст два гудка, после чего нужно будет ввести номер телефона, на который будут направляться вызовы и затем нажать на “решетку” (#), что означает, что ввод номера закончен. На экране появится надпись, что все звонки переадресуются на указанный номер. Чтобы все звонки направлялись на голосовую почту нужно после нажатия клавиши CFwdAll нажать кнопку Messages на телефоне.
Настройка переадресации через CLI
Для настройки переадресации необходимо войти в режим конфигурирования ephone-dn и ввести команду call-forward [тип_переадресации][номер_назначения].
Здесь у аргумента “тип переадресации” может быть несколько значений, которые устанавливают тип переадресации:
All – переадресация всех звонков;
Busy – переадресация, в случае если телефон занят;
Max-length – максимальная длина телефонного номера, который может быть установлен для CFwdAll (значение 0 запрещает использовать переадресацию на телефоне);
Night-service – переадресация вызовов во время ночного режима;
Noan – переадресация при неответе. Дополнительно используется параметр timeout, где указывается через сколько секунд после начала звонка он будет переадресован;
CME(config)# ephone-dn 1000
CME(config-ephone-dn)# call-forward busy 1001
CME(config-ephone-dn)# call-forward noan 1002 timeout 25
Также, эти настройки можно выполнить, используя Cisco Configuration Professional (CCP) . Для этого в настройках переходим во вкладку Unified Communication → Users, Phones, and Extensions → Extensions, там выбрать желаемый номер, перейти во вкладку Advanced и выбрать пункт Call Forwarding.
Здесь аналогично заполняем следующие поля:
Forward all call to – указываем на какой номер делать переадресацию;
When busy divert calls to – указываем, куда переадресовывать звонок, если номер вызываемый номер занят;
Divert unattended calls to – куда направлять вызов при неответе;
No answer timeout – через сколько секунд звонящий будет переадресован;
Call forward max length – максимальная длина номера для CFwdAll;
Также тут есть чекбокс Deny forwarding of calls from an internal extension to outside number, который запрещает делать переадресацию на внешние номера.
Одним из преимуществ и популярности EIGRP является его быстрая конвергенция в случае сбоя связи. Однако одно, что может замедлить эту конвергенцию, - это конфигурация таймера. Именно этому посвящена эта статья, которая является третьей в серии статей о понимании EIGRP.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Часть 2. Про соседство и метрики EIGRP
Часть 2.2. Установка K-значений в EIGRP
Следующие статьи из цикла:
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Начнем наше обсуждение таймеров EIGRP с рассмотрения ситуации, когда два соседа EIGRP непосредственно связаны друг с другом. Если физическая связь между ними не работает, подключенный интерфейс каждого роутера отключается, и EIGRP может перейти на резервный путь (то есть возможный маршрут преемника). Такая ситуация показана на следующем рисунке:
Роутеры OFF1 и OFF2, показанные на приведенном выше рисунке, соединены друг с другом. Поэтому, если кабель между ними обрывается, каждый из интерфейсов роутера, соединяющихся с этим звеном, отключаются, и EIGRP понимает, что он просто потерял соседа и начинает перестраиваться. Однако нарушение связи между несколькими соседями EIGRP не всегда так очевидно. Например, рассмотрим вариант предыдущей топологии, как показано ниже:
Обратите внимание, что между роутерами OFF1 и OFF2 был подключен коммутатор (SW4) на рисунке выше. Если происходит сбой соединения между коммутатором SW4 и роутером OFF1, роутер OFF2 не сразу осознает это, потому что его порт Gig0/1 все еще находится в состоянии up/up. В результате роутер OFF2 может продолжать считать, что роутер OFF1 - это наилучший путь для доступа к сети, такой как 192.0.2.0 /24. К счастью, EIGRP использует таймеры, чтобы помочь EIGRP-спикер роутерам определить, когда они потеряли связь с соседом по определенному интерфейсу.
Таймеры, используемые EIGRP, - это таймеры Hello и Hold. Давайте задержимся на мгновение, чтобы изучить их работу, потому что таймер Hold не ведет себя интуитивно. Во-первых, рассмотрим таймер Hello. Как вы можете догадаться, это определяет, как часто интерфейс роутера отправляет приветственные сообщения своему соседу. Однако таймер Hold интерфейса - это не то, как долго этот интерфейс ожидает получения приветственного сообщения от своего соседа, прежде чем считать этого соседа недоступным. Таймер Hold - это значение, которое мы посылаем соседнему роутеру, сообщая этому соседнему роутеру, как долго нас ждать, прежде чем считать нас недоступными. Эта концепция проиллюстрирована на рисунке ниже, где роутер OFF2 настроен с таймером Hello 5 секунд и таймером Hold 15 секунд.
Два больших вывода из этого рисунка таковы:
Таймер Hello роутера OFF2 влияет на то, как часто он посылает приветствия, в то время как таймер Hold роутера OFF2 влияет на то, как долго роутер OFF1 будет ждать приветствий роутера OFF2.
Указанное время Hello и Hold является специфичным для интерфейса Gig 0/1 роутера OFF2. Другие интерфейсы могут быть сконфигурированы с различными таймерами.
Поскольку таймер Hold, который мы отправляем, на самом деле является инструкцией, сообщающей соседнему роутеру, как долго нас ждать, а не как долго мы ждем Hello-сообщения соседа, причем у каждого соседа может быть свой набор таймеров. Однако наличие совпадающих таймеров между соседями считается лучшей практикой для EIGRP (и является требованием для OSPF).
Чтобы проиллюстрировать конфигурацию и проверку таймеров EIGPR, допустим, что роутер OFF1 имел таймер Hello 1 секунду и таймер Hold 3 секунды на своем интерфейсе Gig 0/1 (подключение к OFF2). Затем мы захотели, чтобы роутер OFF2 имел таймер Hello 5 секунд и таймер Hold 15 секунд на своем интерфейсе Gig 0/1 (подключение к роутеру OFF1). Такая конфигурация укрепляет понятие того, что соседи EIGRP не требуют совпадающих таймеров (хотя лучше всего иметь совпадающие таймеры). В следующем примере показана эта конфигурация таймера для роутеров OFF1 и OFF2.
OFF1#conf term
Enter configuration commands, one per line. End with CNTL/Z.
OFF1(config)#int gig 0/1
OFF1(config-if) #ip hello-interval eigrp 1 1
OFF1(config-if) #ip hold-time eigrp 1 3
OFF1(config-if) #end
OFF1#
OFF2#conf term
Enter configuration commands, one per line. End with CNTL/Z.
OFF2(config)#int gig 0/1
OFF2 (config-if) #ip hello-interval eigrp 1 5
OFF2 (config-if) #ip hold-time eigrp 1 15
OFF2(config-if) #end
OFF2#
Команда ip hello-interval eigrp asn h_intls вводится на каждом роутере для установки таймеров Hello. Параметр asn определяет настроенную автономную систему EIGRP равным 1, и таймер Hello для роутера OFF1 настроен равным 1 секунде, в то время как таймер Hello для роутера OFF2 настроен равным 5 секундам. Аналогично, команда ip hold-time eigrp asn ho_t вводится на каждом роутере для установки таймеров Hold. Опять же, обе команды задают автономную систему 1. Таймер Hold роутера OFF1 настроен на 3 секунды, в то время как таймер Hold роутера OFF2 настроен на 15 секунд. В обоих случаях таймер Hold EIGRP был настроен таким образом, чтобы быть в три раза больше таймера Hello. Хотя такой подход является обычной практикой, он не является обязательным требованием. Кроме того, вы должны быть осторожны, чтобы не установить таймер Hold на роутере со значением меньше, чем таймер Hello. Такая неверная конфигурация может привести к тому, что соседство будет постоянно "падать" и восстанавливаться. Интересно, что Cisco IOS действительно принимает такую неправильную конфигурацию, не сообщая ошибки или предупреждения.
EIGRP использует таймер Hello по умолчанию 5 секунд и таймер Hold по умолчанию 15 секунд на LAN интерфейсах. Однако в некоторых ситуациях на интерфейсах, настроенных для Frame Relay, таймеры по умолчанию будут больше.
Далее, посмотрим, как мы можем проверить настройки таймера EIGRP. Команда show ip eigrp neighbors, как показано в примере ниже, показывает оставшееся время удержания для каждого соседа EIGRP.
Обратите внимание в приведенном выше примере, что значение в столбце Hold равно 2 секундам для роутера OFF1 (то есть 10.1.1.1) и 13 секундам для роутера OFF3 (то есть 10.1.1.10). Эти цифры говорят нам о не настроенных таймерах Hold. Они говорят нам, сколько времени остается до того, как роутер OFF2 отключит этих соседей, в отсутствие приветственного сообщения от этих соседей. Роутер OFF2 перезапускает свой обратный отсчет времени Hold для роутера OFF3 до 15 секунд (таймер Hold роутера OFF3) каждый раз, когда он получает Hello сообщение от OFF3 (которое OFF3 отправляет каждые 5 секунд на основе своего таймера Hello). Поэтому, если вы повторно выполните команду show ip eigrp neighbors на роутере OFF2, вы, вероятно, увидите оставшееся время Hold для роутера OFF3 где - то в диапазоне 10-14 секунд. Однако, поскольку роутер OFF1 настроен с таймером Hold 3 секунды и таймером Hello 1 секунды, оставшееся время Hold, зафиксированно на роутере OFF2 для его соседства с роутером OFF1, обычно должно составлять 2 секунды.
Мы можем видеть настроенные значения таймера Hello и Hold для интерфейса роутера, выполнив команду show ip eigrp interfaces detail interface_id, как показано в примере ниже. Вы можете видеть в выходных данных, что интерфейс Gig 0/1 на роутере OFF2 имеет таймер Hello 5 секунд и таймер Hold 15 секунд.
Отлично, это закрепили. Теперь почитайте про пассивные интерфейсы в EIGRP.