По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Эта статья завершает нашу серию лекций по пониманию EIGRP рассмотрением двух последних тем:
Идентификатор роутера EIGRP
Требования к соседству EIGRP
Предыдущие статьи цикла:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Часть 2. Про соседство и метрики EIGRP
Часть 2.2. Установка K-значений в EIGRP
Часть 3. Конвергенция EIGRP – настройка таймеров
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Начнем мы наше обсуждение с рассмотрения идентификатора роутера EIGRP.
EIGRP Router ID
Каждый EIGRP-спикер роутер имеет ассоциируемый router ID EIGRP (RID). RID - это 32-битное значение, записанное в десятичном формате с точками, например IPv4-адрес. RID EIGRP определяется, когда процесс EIGRP начинает выполняться. Интересно, что EIGRP использует те же шаги для определения RID, что и OSPF. Ниже показаны последовательные шаги определения RID:
Шаг 1. Применить заданное значение RID.
Шаг 2. Если RID не настроен, используйте самый старший IPv4-адрес на loopback интерфейсе, находящийся в состоянии up/up.
Шаг 3. Если ни один loopback интерфейс не настроен с IPv4-адресом, используйте самый высокий IPv4-адрес на non-loopback интерфейсе.
Интересно, что в то время, как EIGRP требует, чтобы роутер имел RID, значение RID играет очень тривиальную роль в процессе EIGRP. Соседи EIGRP могут дублировать RID и устанавливать соседство EIGRP между ними, хотя лучше всего назначать уникальные RID соседям EIGRP. Однако, прежде чем мы чрезмерно минимизируем RID, есть один очень важный момент, когда роутер нуждается в уникальном RID роутера. В частности, если мы вводим внешние маршруты в процесс маршрутизации EIGRP, роутер, выполняющий это перераспределение, нуждается в уникальном RID.
Настройка и проверка Router ID EIGRP
Чтобы сделать схему сетевой адресации более интуитивно понятной, вы можете выбрать ручную настройку RID EIGRP на определенном роутере. Это можно сделать с помощью команды EIGRP router-id rid, как показано на роутере OFF1 и показано в следующем примере:
OFF1#conf term
Enter configuration commands, one per line. End with CNTL/Z.
OFF1(config)#router eigrp 1
OFF1(config-router)#eigrp router-id 1.1.1.1
OFF1(config-router)#end
OFF1#
Обратите внимание на выходные данные в приведенном выше примере, что мы вручную установили RID роутера OFF1 на 1.1.1.1. Команды проверки, которые позволяют нам просматривать RID роутера, включают: show ip eigrp topology и show ip protocols, как показано в следующих примерах:
Требования к соседству
Одной из основных проблем, возникающих при устранении неполадок в сети EIGRP, является установление соседства. EIGRP имеет несколько требований, как и OSPF. Однако EIGRP и OSPF немного отличаются по своим предпосылкам соседства. В таблице ниже перечислены и противопоставлены правила установления соседства как для EIGRP, так и для OSPF.
Требования
EIGRP
OSPF
иметь возможность отправлять пакеты на другой сервер
Да
Да
Первичный адрес интерфейса (не вторичный адрес) должен быть включен в ту же подсеть, что и сеть, сопоставляемая оператором network.
Да
Да
Интерфейс, соединенный с соседом не должен быть пассивным.
Да
Да
Необходимо использовать ту же автономную систему (для EIGRP) или process-ID (для OSPF) при настройке роутера.
Да
Нет
Таймер Hello и таймер Hold (для EIGRP) или Dead таймер (дляOSPF)максимально совпадать.
Нет
Да
Соседи должны аутентифицироваться друг с другом, если аутентификация настроена.
Да
Да
Должно быть в той же зоне
N/A
Да
IP MTU совпадает.
Нет
Да
К-значения совпадают
Да
N/A
Идентификаторы роутеров (rid) должны быть уникальными
Нет
Да
Мы продолжаем постигать основы важнейшего протокола, использующегося в IP телефонии и в сегодняшней статье рассмотрим основные сценарии установления соединения, а также работу основных компонентов протокола SIP. Протокол SIP имеет 3 стандартных сценария установления соединения, которые отличаются наличием и участием тех или и иных устройств.
Пример №1
Установление соединения между User Agent’ами, когда в сети отсутствуют всякого рода серверы. Простейшим примером является сеанс связи, в котором принимают участие только два пользователя. Терминальное оконечное оборудование называется UA (User Agent), когда одновременно совмещает в себе функции UAС (User Agent Client) - клиента и UAS (User Agent Server) - сервера. В данном случае сценарий установления соединения будет выглядеть так: .
Абонент A снимает телефонную трубку и набирает номер Абонента B, тем самым генерируя запрос INVITE , который содержит описание сеанса связи.
Устройство абонента B отвечает сообщением 100 Trying , которое означает, что запрос находится в обработке.
После обработки запроса устройство абонента B уведомляет его о входящем вызове, а в сторону абонента A отвечает сообщением 180 Ringing, что соответствует контролю посылки вызова.
Абонент B снимает телефонную трубку, отвечая сообщением 200 OK, означающее успешную обработку запроса.
Устройство абонента A прекращает прием контроля посылки вызова и посылает подтверждение ACK, означающее прием ответа на запрос INVITE.
Между абонентами устанавливается разговорная фаза. Происходит передача голосового трафика по протоколу RTP (Real-Time Transfer Protocol).
Важно отметить, что SIP не участвует в непосредственной передаче голоса, а лишь предоставляет условия и способы согласования открытия неких каналов обмена на основе других протоколов, в данном случае - RTP.
Абонент A кладет телефонную трубку, тем самым инициируя завершение передачи голосового потока. Устройство абонента A генерирует запрос Bye, в сторону устройства абонента B.
Устройство абонента B отвечает сообщением 200 OK, означающем успешную обработку запроса Bye.
Терминальное оконечное оборудование абонентов A и B возвращается в исходное состояние.
Однако, данный сценарий установления соединения является самым примитивным, можно даже сказать частным. Обычно в сети присутствует SIP прокси сервер, который принимает и обрабатывает запросы от пользователей и выполняет, соответствующие этим запросам, действия.
Пример №2
Рассмотрим сценарий установления соединения между двумя пользователями.
В данном случае задачу поиска и приглашения абонента выполняет Прокси сервер, вызывающему пользователю необходимо знать только постоянный номер вызываемого абонента. Отметим, что функции прокси сервера выполняет офисная телефонная станция
Как видно из рисунка, процесс установления и разъединения соединения происходит аналогично первому сценарию, только в качестве посредника при передаче сообщений протокола SIP выступает SIP Proxy.
Пример №3
Допустим, что в сети имеется множество пользователей, число которых постоянно пополняется. Они могут менять свое фактическое положение, ставить переадресацию (redirection) на другой номер, проводить конференц – звонки и др. Для предоставления подобных сервисов требуется наличие в сети соответствующих серверов, поддерживающих ту или иную функцию.
Сервер регистрации (Registration Server) для аутентификации и авторизации пользователей.
Сервер определения местоположения (Allocation Server) для определения реального местонахождения пользователей.
Сервер переадресации (Redirect Server) для перенаправления звонков на другие номера, в случае если пользователь настроил данную функцию.
Сервер регистрации это логический элемент и обычно его функции выполняет SIP Proxy, такие совмещенные сервера называют Registar. SIP Proxy может также выполнять функции серверов определения местоположения и переадресации, такое совмещение полезно в плане масштабируемости сети.
Приведем пример, когда сеть содержит некий комбинированный SIP Proxy, который поддерживает все функции, описанные выше. Допустим, что новый, еще не зарегистрированный пользователь A,вызывает пользователя B, который уже прошел процедуру авторизации.
Новый User Agent A посылает серверу сообщение REGISTER , которое инициирует процесс регистрации.
Т.к User Agent A ещё не зарегистрирован, то сервер Registar отвечает сообщением 401 Unauthorized
Тогда User Agent A посылает серверу сообщение REGISTER + login, содержащее логин и пароль.
Сервер Registar отвечает сообщением 200 OK, на этом процесс регистрации закончен. Теперь пользователь А авторизован на сервере и может совершать звонки.
User Agent A инициирует установление связи с пользователем B сообщением INVITE.
На данном этапе включаются функции серверов определения местоположения и переадресации, сервер отвечает сообщением 302 Moved Temporarily, означающее, что вызываемый абонент временно сменил местоположение и содержащее его новые данные для установления соединения.
User Agent A отвечает сообщением ACK, которое означает прием ответа от Redirect сервера на запрос INVITE.
Далее User Agent A инициирует новое установление соединения напрямую к пользователю B, в соответствии с полученными данными.
Как видно из рисунка дальнейший процесс соединения происходит аналогично сценарию 1.
В следующей статье мы подробно рассмотрим основные модификации протокола SIP для взаимодействия с традиционными телефонными сетями, использующими сигнализацию ОКС-7.
Пользователи очень часто встречаются с ошибкой 32788 в среде виртуализации Hyper-V. Если быть точным, то полная формулировка ошибки следующая:
The application encountered an error while attempting to change the state of %имя_виртуальной_машины%.%имя_виртуальной_машины% failed to change state. The operation cannot be performed while the object is in use with error code 32788
Выглядит это «неприятное» popup окно примерно вот так:
Ошибка появляется, когда пользователь пытается запустить виртуальную машину. Итак, погнали разбираться. Данный гайд подойдет для Hyper-V версий 2012 R2 и 2016.
Краткая матчасть
Ошибка возникает, из за того, что виртуализация это несколько более сложная штука, чем просто создание виртуальных вычислительных машин поверх физического устройства. Внутри каждой есть операционные системы, сетевые адаптеры, виртуальные коммутаторы, устройства для хранения, интерфейсы взаимодействия и другие.
Сам интерфейс Hyper-V – это лишь консоль управления. Устаревшая и неактуальная конфигурация виртуальных машин приводит к возникновению ошибок. В том числе, и ошибке 32788.
Основные причины ошибки 32788
Самые главные причины ошибки 32788, которые мы воспроизводили на опыте:
Конфликт (неточность/неактуальность) конфигурации виртуальной машины;
Изменения виртуального коммутатора (VM switch) на машине;
Исправляем ошибку 32788
Итак, чтобы исправить ошибку, нужно:
Открыть Settings (настройки) виртуальной машины. В списке виртуальных машин, нажмите правой кнопкой мыши на нужную виртуальную машину и выберите Settings;
Откройте настройки сетевого адаптера (Network Adapter Settings). А так же пробегитесь по всем пунктам меню слева (Memory, Processor, IDE Controller и так далее), на предмет обнаружения уведомления с надписью Configuration Error. В нашем примере, виртуальная машина столкнулась с проблемой того, что виртуальный коммутатор (Vswitch), к которому она подключена, более не существует (The network adapter is configured to a switch which no longer exists…)
Вот она, причина ошибки 32788 в нашей случае – устаревшие настройки виртуального коммутатора. Возможно, его кто то удалил, или изменил его имя.
В любом случае, нам нужно исправить это. Создаем новый виртуальный коммутатор (Virtual Switch) типа Internal, для внутреннего использования:
После внесение всех изменений перезагрузите (выполните рестарт) виртуальную машину.