По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье рассматривается OSPF и все проблемы, которые могут возникнуть с этим протоколом. OSPF отличается от EIGRP протоколом состояния канала, но общим для них является то, что оба протокола маршрутизации устанавливают соседство до обмена информацией о маршрутизации. В случае OSPF мы обмениваемся LSA (объявление о состоянии канала), чтобы создать LSDB (база данных о состоянии канала). Наилучшая информация из LSDB будет скопирована в таблицу маршрутизации.
В этой части мы начнем с устранения неполадок соседей OSPF. Как только у нас есть рабочее соседство OSPF, мы рассмотрим другие проблемы, такие как отсутствующие маршруты.
Full просмотр соседства OSPF
При просмотре соседства OSPF, мы видим, что оно сообщает нам Full. Необходимо больше информации для понимания состояния Full.
Если смежность соседства OSPF не полная, мы рассматриваем одно из следующих состояний:
Соседей нет вообще
Оно "залипло" в ATTEMPT.
Оно "залипло" в INIT.
Оно "залипло" в 2-WAY.
Оно "залипло" в EXSTART/EXCHANGE.
Оно "залипло" в LOADING.
Давайте начнем и рассмотрим разные ситуации, которые могут возникнуть с соседством OSPF!
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Урок 1
у нас есть 2 маршрутизатора
Мы начнем со сценариев, когда OSPF вообще не имеет соседства. В приведенном выше примере у нас есть 2 маршрутизатора.
нет никакого OSPF соседства
Как вы можете видеть, у нас нет никакого OSPF соседства, что может быть не так?
show ip ospf interface show ip ospf interface
Можно было просто посмотреть на текущую конфигурацию и выяснить, что не так, но мы не ищем простых путей. Мы используем другие полезные команды OSPF. Сначала используем команду show ip ospf interface. Мы видим, что OSPF не включен на интерфейсе FastEthernet 0/0 R1, но он работает на R2.
Кто-то допустил ошибку с командой network и набрал неверный сетевой адрес
Кто-то допустил ошибку с командой network и набрал неверный сетевой адрес ... простая ошибка, но такие вещи случаются.
R1(config)#router ospf 1
R1(config-router)#no network 192.168.21.0 0.0.0.255 area 0
R1(config-router)#network 192.168.12.0 0.0.0.255 area 0
Настройка правильного сетевого адреса и обратной маски устраняет эту ошибку.
Настройка правильного сетевого адреса
Проблема решена. Соседство OSPF установлено. Это было легкое начало... Итог урока: проверьте правильность настройки сетевого адреса, обратной маски и области.
Урок 2
2 маршрутизатора, но проблема другая
Очередная проблема. Схема аналогичная: 2 маршрутизатора, но проблема другая.
нет никакого соседства OSPF
Как вы видите, нет никакого соседства OSPF.
Протокол OSPF был включен на интерфейсе обоих маршрутизаторов
Протокол OSPF был включен на интерфейсе обоих маршрутизаторов, поэтому мы знаем, что был использован правильный тип сети. Однако если вы внимательно посмотрите на R1, то увидите, что на нем написано "No Hellos (Пассивный интерфейс)". Если вы настроите пассивный интерфейс, то сеть на интерфейсе все равно будет объявлена, но она не будет отправлять приветственные пакеты OSPF. Таким образом, невозможно создать соседство OSPF.
невозможно создать соседство OSPF
Вот она проблема.
R1(config)#router ospf 1
R1(config-router) #no passive-interface Fe0/0
Удалим пассивный интерфейс.
Удалим пассивный интерфейс
Соседство OSPF работает. Проблема устранена!
Итог урока: проверьте, что OSPF отправляет приветственные пакеты на интерфейс, поскольку, в противном случае, вы не сможете создать соседство.
Урок 3
те же маршрутизаторы, другая проблема
Следующий сценарий с теми же маршрутизаторами, но другая проблема.
R1 показывает, что наш сосед OSPF находится в состоянии INIT R2 ничего не показывает
Интересно... R1 показывает, что наш сосед OSPF находится в состоянии INIT, а R2 ничего не показывает.
OSPF был правильно настроен на обоих интерфейсах OSPF был правильно настроен на обоих интерфейсах
Как мы видим, в примере выше OSPF был правильно настроен на обоих интерфейсах.
Поскольку R1 показывает состояние INIT, мы можем сделать вывод, что он получает что-то от R2. R2 ничего не показывает, поэтому, вероятно, ничего не получает от R1. OSPF использует пакеты приветствия для установления соседства OSPF, и они отправляются с использованием многоадресного адреса 224.0.0.5.
можем ли мы пропинговать адрес многоадресной рассылки можем ли мы пропинговать адрес многоадресной рассылки
Рекомендуется проверить, можем ли мы пропинговать адрес многоадресной рассылки, который OSPF использует для пакетов приветствия. Мы видим, что R1 и R2 оба не получают ответа.
Отправка эхо-запросов друг другу проходят без проблем Отправка эхо-запросов друг другу проходят без проблем
Отправка эхо-запросов друг другу проходят без проблем. Так что может вызвать проблемы с отправкой и получением многоадресного трафика OSPF? Как насчет списка доступа?
на R2 имеется входящий список доступа на R2 имеется входящий список доступа
Мы что-то нашли. И это то, что на R2 имеется входящий список доступа с именем BLOCKSTUFF.
в нижней части access-list имеется данный запрет
Список доступа разрешает только TCP, UDP и ICMP трафик. OSPF не использует TCP или UDP, и он удаляется этим списком доступа из-за deny any. Мы этого не видим в верхнем листинге, но в нижней части access-list имеется данный запрет.
R2(config)#ip access-list extended BLOCKSTUFF
R2(config-ext-nacl)#5 permit ospf any any
проведем коррекцию
Проведем коррекцию access-list, чтобы был разрешен трафик OSPF.
теперь она отображается как Full
Проблема решена, теперь она отображается как Full.
теперь можно пинговать адрес многоадресной рассылки 224.0.0.5 OSPF теперь можно пинговать адрес многоадресной рассылки 224.0.0.5 OSPF
Ну что, теперь можно пинговать адрес многоадресной рассылки 224.0.0.5 OSPF. Мы видим ответ с другой стороны.
Итог урока: не блокируйте многоадресные адреса OSPF 224.0.0.5 и 224.0.0.6 (DR / BDR).
Урок 4
от же сценарий, другая проблема
Это еще не все! Тот же сценарий, другая проблема:
Соседство OSPF отсутствует, но мы видим, что OSPF был включен на интерфейсе Соседство OSPF отсутствует, но мы видим, что OSPF был включен на интерфейсе Соседство OSPF отсутствует, но мы видим, что OSPF был включен на интерфейсе Соседство OSPF отсутствует, но мы видим, что OSPF был включен на интерфейсе
Соседство OSPF отсутствует, но мы видим, что OSPF был включен на интерфейсе.
Пинг на адреса многоадресной рассылки проходит Пинг на адреса многоадресной рассылки проходит
Пинг на адреса многоадресной рассылки проходит, так что это уже хорошо. Это хороший момент для включения отладки, чтобы узнать, что происходит:
что происходит за кулисами
Это очень полезная отладка, которая позволяет увидеть, что происходит за кулисами.
сбросим процесс OSPF
Мы сбросим процесс OSPF, чтобы ускорить отладку. Имейте в виду, что вы также можете сбросить только одно соседство OSPF. Это лучшая идея, если это применяется в производственной сети (сети предприятия или организации).
R1 говорит, что он получил пакет
Теперь нам есть с чем работать. R1 говорит, что он получил пакет hello, но у нас есть несоответствующие параметры hello. R означает то, что мы получили, а C - что мы настроили.
Как мы видим, существует несоответствие в маске подсети. R1 настроен с маской подсети 255.255.255.0, в то время как R2 имеет маску подсети 255.255.255.128. OSPF будет сравнивать маску подсети только в том случае, если вы используете широковещательный тип сети.
show ip ospf interface show ip ospf interface
Можно использовать команду show ip ospf interface для проверки типа сети, и видно, что она является broadcast.
Здесь мы видим, что R2 имеет другую маску подсети Здесь мы видим, что R2 имеет другую маску подсети
Здесь мы видим, что R2 имеет другую маску подсети. Необходимо это исправить!
R2(config)#interface Fe0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.0
Достаточно просто...
соседство OSPF работает соседство OSPF работает
Теперь мы видим, соседство OSPF работает.
Итог урока: проверьте правильность использования одинаковых масок подсетей на маршрутизаторах, которые напрямую связаны друг с другом.
Урок 5
Та же топология, и у нас очередная проблема с пакетами hello
Давайте продолжим, но уже со следующей ошибкой. Та же топология, и у нас очередная проблема с пакетами hello. Сразу перейдем к отладочной части:
проблема похожа на наш последний сценарий
Эта проблема похожа на наш последний сценарий. Есть часть параметров, которые должны совпадать в hello-пакете, чтобы создать соседство OSPF. dead-interval на R1 сконфигурирован на 24 секунды, а на R2 - на 11 секунд. hello-interval сконфигурирован на 10 секунд на R2 и 6 секунд на R1. Поменяем настройки параметров:
R1(config)#interface Fe0/0
R1(config-if)#ip ospf hello-interval 10
R1(config-if)#ip ospf dead-interval 11
Нам нужно изменить это на уровне интерфейса.
Введенные команды с новыми параметрами
Введенные команды с новыми параметрами решают нашу проблему. Соседство OSPF работает.
Урок 6
Топология
Еще одна проблема, с которой нам, возможно, придется столкнуться, это аутентификация. OSPF предлагает 3 метода аутентификации:
без аутентификации
Plaintext
MD5 аутентификация
нет соседей OSPF нет соседей OSPF
Как мы видим, у нас нет соседей OSPF. Давайте используем debug:
Debug ip ospf adj
Debug ip ospf adj поможет нам решить эти неполадки. Видно, что мы получаем пакет с аутентификацией типа 2, а используется тип 0. Вот что это значит:
Type 0: нет аутентификации.
Type 1: plaintext аутентификация.
Type 2: MD5 аутентификация.
Соответственно - R1 сконфигурирован без аутентификации, а R2 сконфигурирован на использование аутентификации MD5.
R2 сконфигурирован на использование аутентификации MD5
Мы также можем посмотреть информацию OSPF для каждого интерфейса, чтобы увидеть, включена ли аутентификация или нет.
включена ли аутентификация или нет
Это то, что настроено на интерфейсе R2.
R1(config)#interface FastEthernet0/0
R1(config-if)#ip ospf authentication message-digest
R1(config-if)#ip ospf message-digest-key 1 md5 MYKEY
Мы копируем и вставляем его в R1.
копируем и вставляем его в R1
Проблема устранена! Если вам интересно, вот что вы увидите, когда задан неправильный пароль на одном из маршрутизаторов:
R1(config)#interface FastEthernet0/0
R1(config-if)#no ip ospf message-digest-key 1 md5 MYKEY
R1(config-if)#ip ospf message-digest-key 1 md5 WRONGKEY
Сначала мы поменяем ключ:
отладчик говорит нам, что мы используем неправильный ключ
Наш отладчик говорит нам, что мы используем неправильный ключ между нашими маршрутизаторами.
Извлеченный урок: убедитесь, что вы используете один и тот же тип аутентификации OSPF и пароль между маршрутизаторами.
Урок 7
Тот же сценарий
Что еще может пойти не так? Кажется, что нет никаких проблем, связанных с соседством OSPF! Тот же сценарий, теперь другая проблема:
Соседство отсутствует OSPF Соседство отсутствует OSPF
OSPF-соседство отсутствует.
есть несоответствие в номере области
На одном из наших маршрутизаторов появилось сообщение. Оно не требует объяснений, похоже, у нас есть несоответствие в номере области.
R1 настроен для области 1, а R2 настроен для области 0 R1 настроен для области 1, а R2 настроен для области 0
R1 настроен для области 1, а R2 настроен для области 0. Исправляем:
network
R1(config)#router ospf 1
R1(config-router)#no network 192.168.12.0 0.0.0.255 area 1
R1(config-router)#network 192.168.12.0 0.0.0.255 area 0
Мы используем команду network, чтобы задать правильный номер области.
network
Ура, все работает!
Итог урока: убедитесь, что ваши маршрутизаторы OSPF согласовывают один и тот же номер области.
Урок 8
а этот раз R1 и R2 находятся в одной зоне 1
Рисунок выше слегка отличается от предыдущего. На этот раз R1 и R2 находятся в одной зоне 1.
нет соседей нет соседей
Вот так сюрприз... нет соседей! Запускаем отладку:
Запускаем отладку
Очень интересно! Существует несоответствие в опции stub/transit area. OSPF имеет различные типы областей, и оба маршрута должны согласовываться с типом области (stub, nssa, totally stub и totally nssa).
R1, по-видимому, настроен на использование normal area
R1, по-видимому, настроен на использование normal area.
R2, похоже, настроен на использование stub area
R2, похоже, настроен на использование stub area. Несоответствие в типе области означает, что мы не можем установить соседство OSPF.
R2 имеет команду area 1 stub
На листинге выше мы видим, что R2 имеет команду area 1 stub. Удалим ее.
R2(config)#router ospf 1
R2(config-router)#no area 1 stub
Изменим область 1 на normal area для R2.
Изменим область 1 на normal area для R2 Изменим область 1 на normal area для R2
Итог урока: убедитесь, что ваши маршрутизаторы OSPF используют один и тот же тип области.
Урок 9
Очередная ситуация с неполадками с OSPF
Очередная ситуация с неполадками в OSPF, которая на первый взгляд кажется очень запутанной. Давайте посмотрим на конфигурацию OSPF обоих маршрутизаторов:
посмотрим на конфигурацию OSPF обоих маршрутизаторов посмотрим на конфигурацию OSPF обоих маршрутизаторов
Это простая конфигурация.
таблица соседства OSPF не пустая таблица соседства OSPF не пустая
У нас таблица соседства OSPF не пустая, но оба маршрутизатора "застряли" в состоянии 2WAY. Помимо поиска нужного нам слова "FULL", следует обратить внимание на две вещи, отображаемые командой show:
Оба маршрутизатора показывают друг друга как DROTHER.
Приоритет для обоих маршрутизаторов равен 0.
В multi-access сети, такой как Ethernet, OSPF будет выполнять выборы DR/BDR, если тип сети broadcast или non-broadcast.
Проверяем тип сети:
Оба интерфейса настроены для типа сети broadcast Оба интерфейса настроены для типа сети broadcast
Оба интерфейса настроены для типа сети broadcast. Это значение по умолчанию для интерфейсов Ethernet. Это означает, что у нас есть выборы DR/BDR, но оба маршрутизатора настроены на приоритет 0, а это означает, что они не будут участвовать в выборах DR/BDR. По этой причине они застряли в состоянии 2WAY. Необходимо это исправить:
R1(config)#interface fastEthernet 0/0
R1(config-if)#ip ospf priority 1
Мы изменим приоритет на одном из маршрутизаторов.
Мы видим, что R1 был выбран для DR Мы видим, что R1 был выбран для DR
Все работает. Мы видим, что R1 был выбран для DR, потому что он имеет приоритет 1. Итог урока: Типы широковещательной и не вещательной сети требуют выбора DR/BDR. Убедитесь, что один из маршрутизаторов выбран.
В следующей статье мы разберем еще 8 уроков траблшутинга OSPF.
Компьютерные сети это то, что можно встретить сейчас в любом доме, в любой организации. Более того, это одна из основных составляющих успешной деятельности современного предприятия. И чем крупнее организация, тем шире в ней компьютерная сеть. В этом случае для удобства организации работы имеет смысл разделить единую сеть на подсети. В этой статье мы рассмотрим, как правильно и без ошибок наладить работу с подсетями в рамках одной локальной сети.
p>
Прежде всего, стоит понимать, а нужно ли вообще разбивать сеть? Если фирма небольшая, на 3-4 сотрудника в одном офисе, то в такой разбивке нет необходимости. Однако, если сотрудники компаний занимают несколько кабинетов, или же отделы находятся в различных зданиях - в этом случае без сегментации на подсети не обойтись.
Вообще, интернет-провайдер рассматривает любую организацию как одну сеть, в идеале, имеющую один IP-адрес. На деле так получается далеко не всегда. Если организация крупная, то в ней по факту может быть несколько локальных подсетей, объединенных в одну сеть, которую и будет "видеть" провайдер. Эти подсети могут быть территориально удалены друг от друга, поэтому нужно правильно наладить их соединение, чтобы избежать ошибок в обмене данными.
Конечно, самым очевидным решением будет присвоение каждому устройству своего IP-адреса. Но если в сети есть несколько маршрутизаторов, такой вариант будет неприемлемым или исключительно сложным в реализации.
Что же делать в случае, если сеть организована через связанные между собой маршрутизаторы? В этом случае нужно присвоить IP-подсетям разные адреса.
Задачка: из пункта А в пункт Б выехал поезд…Упс, нет, не та задача. Пусть в организации есть несколько отделов. Чтобы понять, какое количество IP-адресов выдать на подсеть, необходимо знать потребности каждого отдела. Иными словами, знать максимальное количество компьютеров и сетевых устройств, которое планируется ставить в каждом отделе. Для каждого компьютера (и любого другого сетевого девайса) в рамках подсети будет установлен свой индивидуальный IP-адрес. Также нужны IP-адреса для виртуальных серверов, если таковые используются в организации. Не лишним будет создать запас IP-адресов на случай расширения отдела и установки новых рабочих станций.
Есть два варианта разделения сети. Это вариант с подсетями равного размера и вариант с подсетями разного размера. Рассмотрим первый случай:
Если вы на хотите заморачиваться с самостоятельным расчетом подсетей, то мы сделали все за вас 😌. Воспользуйтесь нашим готовым калькулятором подсетей
Вариант 1: Разделение сети на подсети одинакового размера:
Вообще, в сети, устроенной по протоколу IPv4 можно, как правило размещают 254 устройства (2^8-2 – два в восьмой степени минус 2. Минус два, так как один адрес широковещательный а другой сетевой, так называемый нулевой). Из адресного пространства узла (последние 8 бит) для адресации подсетей потребуется занять несколько бит. Если занять 1 бит получится 2 подсети, 2 бита 4 подсети, 3 бита 8 подсетей и так далее. Маска подсети будет увеличиваться на +1 за каждый занятый для разбивки бит.
Таким образом, определив нужное количество подсетей, мы можем начинать разбивку. Стоит помнить, что чем больше подсетей, тем меньше в них будет адресов. Например, если подсетей нужно сделать 7, то для адресации в адресном пространстве узла мы возьмем 3 бита, и еще 5 у нас останется для присвоения IP-адресов. Таким образом, в каждой подсети можно будет установить (2^5-2 – два в пятой степени минус два) = 30 устройств. Общая вместимость сети в данном случае составит (30*8) =240 устройств.
Диапазоны устройств в подсетях найти также несложно. Они будут распределены от 0 до 254, при этом адреса подсети уже будут зарезервированы (0, 32, 64, 96, 128, 160, 192, 224)
Пример:
1-я подсеть: 1.2.3.0 /27 диапазон 1.2.3.1 /27 1.2.3.30 /27
2-я подсеть: 1.2.3.32 /27 диапазон 1.2.3.33 /27 1.2.3.62 /27
3-я подсеть: 1.2.3.64 /27 диапазон 1.2.3.65 /27 1.2.3.94 /27
4-я подсеть: 1.2.3.96 /27 диапазон 1.2.3.97 /27 1.2.3.126 /27
5-я подсеть: 1.2.3.128 /27 диапазон 1.2.3.129 /27 1.2.3.158 /27
6-я подсеть: 1.2.3.160 /27 диапазон 1.2.3.161 /27 1.2.3.190 /27
7-я подсеть: 1.2.3.192 /27 диапазон 1.2.3.193 /27 1.2.3.222 /27
8-я подсеть: 1.2.3.224 /27 диапазон 1.2.3.225 /27 1.2.3.254 /27
Таким образом, наши IP - пакетики могут легко пройти через маршрутизаторы и найти нужный путь. Но в данном варианте есть и минус - множество IP-адресов в подсети остаются неиспользуемыми. Теперь рассмотрим второй вариант:
Вариант 2. Разделение сети на подсети различного размера:
В данном случае необходимо будет рекурсивно разделить сеть пополам. Посмотрите наглядную картинку:
И так далее. А затем для каждой подсети подобрать адрес с диапазоном нужного размера. Таким образом если в одной подсети 50 устройств, она будет в диапазоне 3 итерации деления, если же 5, то в 5 итерации.
Используя этот метод, мы экономим IP-адреса и можем разделять сеть на подсети разных размеров.
Подытоживая, можно отметить, что такое деление отлично подойдет в случае IPv6, но с учетом того, что там используется гораздо более объемное адресное пространство, там проблемы с экономией IP-адресов не стоит. Принцип деления сети на подсети будет тем же самым с поправкой на 128-битный адрес нового протокола.
Привет! В этой статье мы рассмотрим Partitions и Calling Search Space (CSS) в Cisco Unified Communications Manager (CUCM) , которые являются частью механизма Class of Control и применяются при разграничении доступов.
/p>
Partitions можно рассматривать как набор маршрутов, паттернов, номеров DN, каждый из которых может принадлежать к определенным разделам. CSS же представляет собой упорядоченный список Partitions. Чтобы совершить вызов Partition вызываемой стороны должен принадлежать CSS вызывающей стороны.
При попытке выполнить вызов CUCM просматривает CSS вызывающей стороны и проверяет, принадлежит ли вызываемая сторона Partition’у в CSS. Если это так, вызов направляется в Translation Pattern. Если нет, то вызов отклоняется или Translation Pattern игнорируется. Подробнее про маршрутизацию и Translation Pattern’ы можно прочить в наших статьях.
Можно назначить разные CSS IP-телефонам, номерам DN, переадресации всех вызовов (Call Forwarding All – CFA), переадресации без ответа (Call Forwarding No Answer - CFNA), переадресации вызовов в случае занятости (Call Forwarding Busy - CFB), шлюзов и паттернам Translation Pattern.
Разделы и CSS облегчают маршрутизацию вызовов, поскольку они делят план маршрутизации на логические подмножества на основе организации, местоположения и/или типа вызова.
Чтобы лучше понять, как все это работает, рассмотрим пример.
Пример использования Partitions и CSS
Этот пример иллюстрирует, как можно разграничить маршрутизацию звонка между пользователями в пределах организации.
Допустим, у нас имеется три группы пользователей:
Стажеры (могут звонить только на внутренние номера)
Работники (могут звонить на внутренние номера и совершать междугородние звонки)
Руководство (могут звонить на внутренние номера, совершать междугородние и международные звонки)
Для каждого направления необходимо иметь Partition:
Внутренние номера –Partition_1
Междугородние звонки – Partition_2
Международные звонки – Partition_3
Эти разделы отражают все возможные направления звонков. Все телефоны (номера DN) мы поместим в раздел Partition_1 (внутренние номера).
На шлюзе сконфигурировано два паттерна Route Patterns:
Все звонки кроме международных (поместим в раздел Partition_2)
Международные звонки (поместим в раздел Partition_3)
На основании этих ограничений создаем три CSS:
CSS1 содержит разделы: Partition_1
CSS2 содержит разделы: Partition_1, Partition_2
CSS3 содержит разделы: Partition_1, Partition_2, Partition_3
Настраиваем телефоны:
На телефонах стажеров указываем CSS1
На телефонах работников указываем CSS2
На телефонах руководства указываем CSS3
Теперь совершим тестовые звонки с заданными настройками.
Тест 1: Звонок с телефона стажера
Набран внутренний номер:
Вызываемый абонент: Partition_1
Разделы CSS вызывающего абонента: Partition_1
Результат: Вызов выполнится (раздел Partition_1 включен в CSS)
Набран междугородний номер:
Вызываемый абонент: Partition_2
Разделы CSS вызывающего абонента: Partition_1
Результат: Вызов не выполнится (раздел Partition_2 не включен в CSS)
Набран международный номер:
Вызываемый абонент: Partition_3
Разделы CSS вызывающего абонента: Partition_1
Результат: Вызов не выполнится (раздел Partition_3 не включен в CSS)
Тест 2: Звонок с телефона работника
Набран внутренний номер:
Вызываемый абонент: Partition_1
Разделы CSS вызывающего абонента: Partition_1, Partition_2
Результат: Вызов выполнится (раздел Partition_1 включен в CSS)
Набран междугородний номер:
Вызываемый абонент: Partition_2
Разделы CSS вызывающего абонента: Partition_1, Partition_2
Результат: Вызов выполнится (раздел Partition_2 включен в CSS)
Набран международный номер:
Вызываемый абонент: Partition_3
Разделы CSS вызывающего абонента: Partition_1, Partition_2
Результат: Вызов не выполнится (раздел Partition_3 не включен в CSS)
Тест 3: Звонок с телефона руководства
Набран внутренний номер:
Вызываемый абонент: Partition_1
Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3
Результат: Вызов выполнится (раздел Partition_1 включен в CSS)
Набран междугородний номер:
Вызываемый абонент: Partition_2
Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3
Результат: Вызов выполнится (раздел Partition_2 включен в CSS)
Набран международный номер:
Вызываемый абонент: Partition_3
Разделы CSS вызывающего абонента: Partition_1, Partition_2, Partition_3
Результат: Вызов выполнится (раздел Partition_3 включен в CSS)
Таким образом, получается, что вызовы совершать можно, только если раздел Partition вызываемого абонента находится в CSS вызывающего.
Настройка
Начнем с настройки Partitions. В Cisco Call Manager Administration переходим во вкладку Call Routing → Class of Control → Partition и нажимаем Add New. Здесь в поле Name указываем название для раздела и нажимаем Save.
Теперь перейдем к созданию CSS. Для этого выберем вкладку Call Routing → Class of Control → Calling Search Space. Тут указываем имя в поле Name, из поля Available Partitions перенесем в поле Selected Partitions разделы, которые должен содержать CSS. Перенос осуществляется при помощи стрелочек. После чего нажимаем кнопку Save для сохранения.
После того как мы создали CSS и Partitions на наших серверах, применим их к устройствам. Рассмотрим это на примере настройки телефона. Для этого выбираем телефон, который мы хотим настроить во вкладке Device → Phone. В его настройках выбираем желаемую линию и нажимаем на нее, например Line [1] . В открывшемся окне в строке Route Partition в выпадающем списке выбираем раздел для этой линии. После этого нажимаем Save и возвращаемся назад.
Теперь нам осталось применить к телефону CSS. Здесь, в настройках телефона в поле Device Information находим строчку Calling Search Space и в выпадающем меню выбираем созданный ранее CSS. Затем сохраняем и применяем настройки.
Аналогично мы можем настраивать Partitions и CSS на других устройствах, паттернах и номерах.