По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье описывается конфигурация, необходимая на маршрутизаторе Cisco для получения сведений о системе доменных имен (DNS) от поставщика услуг и передачи их внутренним пользователям с помощью DHCP. Протокол DNS используется для разрешения полного доменного имени (FQDN) на его соответствующий IP-адрес.
Получение DNS IP адреса от провайдера с помощью PPP
В большинстве корпоративных сетей, где локальный DNS-сервер недоступен, клиенты должны использовать службу DNS, предоставляемую провайдером, или настроить общедоступный DNS-сервер в свободном доступе.
Рис. 1.1 DNS IP-адрес от провайдера с использованием PPP
Настройка локального DHCP-сервера на маршрутизаторе Cisco
Выполните настройку основных параметров DHCP на маршрутизаторе Cisco и включите его для того, чтобы он действовал как DHCP-сервер для локальной сети.
Во-первых, включите службу DHCP на маршрутизаторе Cisco.
R1(config)#service dhcp
Затем создайте пул DHCP, определяющий сетевую подсеть, которая будет передана в аренду DHCP-клиентам в локальной сети.
ip dhcp pool LAN_MY
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 192.168.1.1
Здесь пул DHCP был назван как LAN_MY.
Оператор network задает подсеть и маску пула адресов DHCP
default-router указывает IP-адрес маршрутизатора по умолчанию для DHCP-клиента. Это должен быть IP-адрес в той же подсети, что и клиент
DNS-сервер задает IP-адрес DNS-сервера, который доступен для DHCP-клиента
Включите DNS-сервер на маршрутизаторе Cisco
В режиме глобальной конфигурации включите службу DNS на маршрутизаторе.
R1(config)#ip dns server
Конфигурация для ретрансляции публичной службы DNS от провайдера через PPP
Для того, чтобы получить Public DNS от провайдера, необходимо настроить ppp ipcp dns request на Dialer интерфейсе.
R1(config)#interface dialer 1
R1(config-if)#ppp ipcp dns request
Когда все вышеперечисленные конфигурации будут выполнены:
Команда ppp ipcp dns request сначала помогает получить информацию о публичном DNS-сервере от провайдера через ipcp-фазу согласования PPP.
Затем команда ip dns server позволяет маршрутизатору начать действовать в качестве самого DNS-сервера. Однако маршрутизатор в конечном итоге использует Public DNS service от провайдера для разрешения доменных имен
Кроме того, когда локальный DHCP-сервер раздаст IP-адреса клиентам, он будет представлять себя как DNS-сервер. Все входящие запросы разрешения DNS от клиентов будут обрабатываться маршрутизатором с использованием Public DNS
Проверка
Шаг 1: Запустите debug ppp negotiation и внимательно прочитайте информацию о IPCP, чтобы проверить, предоставляется ли информация о DNS-сервере провайдером.
Шаг 2: выполните команду show ppp interface virtual-access, чтобы узнать о различных параметрах, успешно согласованных во время настройки PPP.
R1# show ppp interface virtual-access 3
В сегодняшней статье речь пойдет о проприетарном протоколе компании Cisco Systems - SCCP – (Skinny Client Control Protocol), который предназначен для построения корпоративных телефонных сетей на основе продуктов Cisco, таких как:
IP-Телефоны серии 7900
Софт-фоны Cisco IP communicator
Cisco Unified Communications Manager
Cisco Unity
Стоит заметить, что в телефонии существует ещё один протокол с абсолютно идентичной аббревиатурой – SCCP – Signalling Connection and Control Protocol, однако данный протокол относится к сигнализации ОКС-7, тогда как SCCP – (Skinny Client Control Protocol) работает в стеке TCP/IP.
Протокол SCCP занимает то же самое место в VoIP что и SIP, H.323 и MGCP и выполняет те же самые функции. Однако, в отличие от всех перечисленных протоколов, имеет гораздо более простой синтаксис и требует меньше компьютерных ресурсов для обработки своих сообщений.
Как и большинство VoIP протоколов SCCP предназначен для обмена сигнальными сообщениями между клиентом и сервером в процессе установления и завершения звонка.
В процессе передачи речевых данных SCCP не участвует, для этих целей служит протокол RTP - (Real-Time Transport Protocol). Кроме того, стоит отметить, что в SCCP не используется RTСP - (Real-Time Transport Control Protocol), который передает диагностическую информацию о текущем соединении. Для этих целей в SCCP имеются собственные механизмы.
Как уже было замечено, Протокол SCCP имеет очень простой синтаксис. По заголовку того или иного сообщения можно однозначно определить в каком статусе находится текущее соединение, что делает Протокол SCCP крайне удобным при траблшутинге. Для передачи сообщений SCCP используется TCP (Transmission Control Protocol) well-known порт 2000.
Соединение по SCCP невозможно рассматривать без сервера (чаще всего CUCM). SCCP имеет большое множество сообщений и отправляет их на сервер по каждому поводу, ожидая руководства к дальнейшим действиям. Выглядит это примерно так:
IP-Телефон: StationInit: Кто-то снял телефонную трубку
Сервер: StationD: Включи зуммер
Сервер: StationD: Выведи на дисплее сообщение “Введите номер”“
IP-Телефон: StationInit: Начинаю вызывать абонента, первая цифра его номера – “4”
IP-Телефон: StationInit: Вторая цифра – “7”
Каждое событие фиксируется вплоть до получения сервером сообщения о том, что телефонная трубка снова в исходном положении.
Обратите внимание, что сообщения SCCP отправляются как в сторону клиента, так и сторону сервера, поэтому для определения источника сообщения используются идентификаторы. StationInit, если источником является клиент и StationIniD, если источником является сервер телефонии. Таким образом появляется возможность в мельчайших деталях отследить любой звонок, совершенный внутри корпоративной сети.
Приведем пример некоторых сообщений SCCP:
0x0000 - Keep Alive Message – Отправляется от сервера к клиенту сразу после регистрации
0x0001 - Station Register Message – Запрос регистрации на сервере
0x0002 - Station IP Port Message – Отправляет клиент. Номер UDP порта для RTP сессии
0x0006 - Station Off Hook Message – Отправляет клиент. Снятие телефонной трубки
0x0099 - Station Display Text Message – Выводит на дисплей сообщение “Введите номер”
0x0082 - Station Start Tone Message – Включает зумер.
0x27 - Station Soft Key Event Message (new call/end call) – Если это начало вызова, то данное сообщение содержит первую цифру номера вызываемого абонента. Может также содержать промежуточные цифры номера, а также запрос на разрыв соединения (end call)
0x107 - Station Connection Statistics Request Message – Отправляется клиентом. Запрос диагностической информации (информации о задержках и потерях медиа-пакетов, джиттер-буфере, принятых и отправленных пакетах и т.д. ). Это тот самый механизм, который компенсирует отсутствие RTCP.
Как видно из данного примера, MessageID каждого сообщения крайне точно описывает соответствующее ему событие, поэтому чтение трассировок SCCP обычно не составляет труда.
Стоит также добавить, что некоторые компании, занимающиеся разработкой голосовых решений, такие как: Digium, SocketIP и Symbol Technologies, добавили поддержку протокола SCCP в свои продукты.
Как только пакет переносится через шину на исходящую линейную карту или указатель на буфере пакетов перемещается из входной очереди в выходную очередь, сетевому устройству все еще остается работать. Рисунок ниже иллюстрирует это.
Обратите внимание на кольцо, показанное на рисунке, это кольцо передачи, а не кольцо приема. На рисунке есть четыре шага:
Шаг 1. Пакет передается на передающую сторону маршрутизатора для переадресации. Здесь может потребоваться обработка после переключения, в зависимости от платформы и конкретных функций; они не показаны на этом рисунке. Сначала будет предпринята попытка поместить пакет непосредственно на кольцо передачи, где он может быть передан. Если кольцо уже имеет пакет на нем, или если кольцо заполнено (в зависимости от реализации), пакет не будет помещен на кольцо передачи. Если пакет помещен на кольцо передачи, Шаг 2 пропускается (что означает, что пакет не будет обработан с использованием каких-либо правил Quality of Service [QoS]). В противном случае пакет помещается в очередь вывода, где он будет ожидать передачи в кольцо передачи.
Шаг 2. Если пакет не может быть помещен на кольцо передачи, он будет помещен в очередь вывода для хранения в течение некоторого времени.
Шаг 3. Код передачи периодически перемещает пакеты из очереди вывода в кольцо передачи. Порядок, в котором пакеты берутся из очереди вывода, будет зависеть от конфигурации QoS;
Шаг 4. В какой-то момент после того, как пакет был перемещен в кольцо передачи, передающий PHY-чип, который считывает каждый бит из буфера пакетов, кодирует его в надлежащий формат для исходящего физического типа носителя и копирует пакет на провод.