PING — сетевая диагностика на IP-уровне
Команда PING это, пожалуй, самая используемая сетевая утилита командной строки. PING присутствует во всех версиях всех операционных систем с поддержкой сети и является простым и удобным средством опроса узла по имени или его IP-адресу.Для обмена служебной и диагностической информацией в сети используется специальный протокол управляющих сообщений ICMP (Internet Control Message Protocol). Команда ping позволяет выполнить отправку управляющего сообщения типа Echo Request (тип равен 8 и указывается в заголовке ICMP-сообщения) адресуемому узлу и интерпретировать полученный от него ответ в удобном для анализа виде. В поле данных отправляемого icmp-пакета обычно содержатся символы английского алфавита. В ответ на такой запрос, опрашиваемый узел дожжен отправить icmp-пакет с теми же данными, которые были приняты, и типом сообщения Echo Reply (код типа в ICMP-заголовке равен 0) . Если при обмене icmp-сообщениями возникает какая-либо проблема, то утилита ping выведет информацию для ее диагностики.
Формат командной строки:
ping [-t] [-a] [-n число] [-l размер] [-f] [-i TTL] [-v TOS] [-r число] [-s число] [[-j списокУзлов] | [-k списокУзлов]] [-w таймаут] конечноеИмя
Параметры:
-t — Непрерывная отправка пакетов.
Для завершения и вывода статистики используются комбинации клавиш
Ctrl + Break (вывод статистики и продолжение), и Ctrl + C (вывод статистики и завершение).
-a — Определение адресов по именам узлов.
-n число — Число отправляемых эхо-запросов.
-l размер — Размер поля данных в байтах отправляемого запроса.
-f — Установка флага, запрещающего фрагментацию пакета.
-i TTL — Задание срока жизни пакета (поле «Time To Live»).
-v TOS — Задание типа службы (поле «Type Of Service»).
-r число — Запись маршрута для указанного числа переходов.
-j списокУзлов — Свободный выбор маршрута по списку узлов.
-k списокУзлов — Жесткий выбор маршрута по списку узлов.
-w таймаут — Максимальное время ожидания каждого ответа в миллисекундах.
Примеры использования:
ping google.com — эхо-запрос к узлу с именем google.com с параметрами по умолчанию — количество пакетов равно 4, длина массива данных = 32 байта.
ping -6 ya.ru — пинг узла ya.ru с использованием протокола Ipv6
ping -a 192.168.1.50 — выполнить пинг с определением имени конесного узла по его адресу.
ping -s 192.168.0.1 computer — пинг узла computer от источника 192.168.0.1. Используется когда на компьютере имеется несколько сетевых интерфейсов.
ping w 5000 ya.ru — пинг с таймаутом ожидания равным 5 секунд ( по умолчанию — 4 сек).
ping -n 1 -l 3000 -f ya.ru — пинг с запретом фрагментации пакета.
ping -n 1-r 3 ya.ru — отправить 1 эхо-запрос на узел ya.ru с отображением первых 3-х переходов по маршруту.
ping -i 5 ya.ru — пинг с указанием времени жизни TTL=5. Если для достижения конечного узла потребуется большее количество переходов по маршруту, то маршрутизатор, прервавший доставку ответит сообщением ”Превышен срок жизни (TTL) при передаче пакета.”
Обобщенная схема соединения компьютера (планшета, ноутбука домашней сети) с удаленным конечным узлом можно представить следующим образом:
В качестве домашней сети используется наиболее распространенная сеть с IP-адресами 192.168.1.0 /255.255.255.0 . Речь идет об IPv4 – IP протоколе версии 4, где для адресации используется 4 байта. IP- адреса принято представлять в виде десятичных значений байтов, разделяемых точками. Каждое устройство в сети должно иметь свой уникальный адрес. Кроме адреса, в сетевых настройках используется маска сети ( маска подсети). Маска имеет такой же формат представления, как и адрес. Комбинация адреса и маски определяет диапазон адресов, которые принадлежат локальной сети — 192.168.1.0-192.168.1.255. Первый и последний адреса диапазона не назначаются отдельным сетевым устройствам, поскольку используются в качестве адреса сети и широковещательного адреса. Обычно адрес роутера делают равным 192.168.1.1 или 192.168.1.254. Это не является обязательным стандартом, но на практике используется довольно часто. Единичные биты маски определяют постоянную часть IP-адреса сети, а нулевые — выделяемые отдельным узлам. Значение 255 — это байт с установленными в единицу битами. Маска сети служит средством определения диапазона IP-адресов, принадлежащих локальной сети. Устройства с такими адресами достижимы локально, без использования
Команда PING можно использовать для диагностики отдельных узлов:
ping 127.0.0.1 — это пинг петлевого интерфейса. Должен выполняться без ошибок, если установлены и находятся в работоспособном состоянии сетевые программные компоненты.
ping свой IP или имя — пинг на собственный адрес или имя. Должен завершаться без ошибок, если установлены все программные средства протокола IP и исправен сетевой адаптер.
ping IP-адрес роутера — должен выполняться, если исправна сетевая карта компьютера, исправен кабель или беспроводное соединение, используемые для подключения к роутеру и исправен сам роутер. Кроме того, настройки IP должны быть такими, чтобы адрес компьютера и роутера принадлежали одной подсети. Обычно это так, когда сетевые настройки выполняются автоматически средствами DHCP-сервера маршрутизатора.
ping yandex.ru — выполнить опрос узла с именем yandex.ru. Если опрос завершается с ошибкой, то причиной может быть не только отсутствие связи с маршрутизатором провайдера, но и невозможность определения адреса узла yandex.ru из-за проблем с программными средствами разрешения имен.
ping 8.8.8.8 — выполнить опрос узла с IP-адресом 8.8.8.8 . Если опрос по адресу выполняется без ошибок, а опрос по имени завершается сообщением о неизвестном узле, то проблема в разрешении имен. Причиной может быть неработоспособность DNS-сервера провайдера. В этом случае, можно попробовать сменить его в настройках сетевого соединения на публичные DNS сервера Google с адресами 8.8.4.4 и 8.8.8.8. Также, проблема может быть вызвана плохим качеством связи с провайдером, что сопровождается слишком большим временем отклика и пропаданием пакетов.
ping -t yandex.ru — выполнять ping до нажатия комбинации CTRL+C, При нажатии CTRL+Break — выдается статистика и опрос узла продолжается.
ping -n 1000 -l 500 192.168.1.1 — выполнить ping 1000 раз с использованием сообщений, длиной 500 байт. Пинг пакетами стандартной длины в 32 байта может выполняться без ошибок, а на длинных — с ошибками, что характерно для беспроводных соединения при низком уровне сигнала в условиях интенсивных помех.
ping -n 1 -r 9 -w 1000 yandex.ru — выполнить ping 1 раз (ключ -n 1), выдавать маршрут для первых 9 переходов (-r 9), ожидать ответ 1 секунду (1000мсек)
В результате выполнения данной команды отображается и трассировка маршрута:
Обмен пакетами с yandex.ru [87.250.251.11] с 32 байтами данных:
Ответ от 87.250.251.11: число байт=32 время=36мс TTL=54
Маршрут: 81.56.118.62 ->
81.56.112.1 ->
10.109.11.9 ->
10.109.11.10 ->
195.34.59.105 ->
195.34.52.213 ->
195.34.49.121 ->
87.250.239.23
Статистика Ping для 87.250.251.11:
Пакетов: отправлено = 1, получено = 1, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 36мсек, Максимальное = 36 мсек, Среднее = 36 мсек
В данном примере, между отправителе и получателем пакетов выстраивается цепочка из 9 маршрутизаторов. Нужно учитывать тот факт, что в версии утилиты ping.exe для Windows, число переходов может принимать значение от 1 до 9. В случаях, когда этого значения недостаточно, используется команда tracert
Отсутствие эхо-ответа не всегда является признаком неисправности, поскольку иногда по соображениям безопасности, некоторые узлы настраиваются на игнорирование эхо-запросов, посылаемых PING. Примером может служить узел microsoft.com и некоторые маршрутизаторы в сетях небольших провайдеров.
Использование PING в командных файлах.
Нередко, команда PING используется для организации задержек в командных файлах. Выполняется пингование петлевого интерфейса с указанием нужного значения счетчика пакетов, задаваемого параметром -n. Посылка эхо-запросов выполняется с интервалом в 1 секунду, а ответ на петлевом интерфейсе приходит практически мгновенно, поэтому задержка будет приблизительно равна счетчику минус единица:ping -n 11 127.0.0.1 — задержка в 10 секунд.
Команда PING используется в командных файлах для определения доступности IP-адресов. Поскольку, результат опроса никак не отражается в переменной ERRORLEVEL , то вместо ее анализа используется поиск определенных признаков в данных стандартного вывода PING. Если внимательно посмотреть на сообщения программы ping.exe при опросе доступного и недоступного узла, то можно заметить, что они значительно отличаются
ping 456.0.0.1 — ping на несуществующий адрес
Ответ на такую команду может отличаться от конкретной версии утилиты, и может быть приблизительно таким
При проверке связи не удалось обнаружить узел 456.0.0.1. Проверьте имя узла и повторите попытку.
ping yandex.ru — ping на адрес узла yandex.ru
Ответ на ping доступного узла:
Обмен пакетами с yandex.ru [87.250.250.11] по 32 байт:
Ответ от 87.250.250.11: число байт=32 время=10мс TTL=55
Таким образом, для решения задачи определения доступности узла в командном файле, достаточно проанализировать характерные слова в выводе ping.exe при успешном ответе. Наиболее характерно в данном случае наличие слова TTL. Оно никогда не встречается при возникновении ошибки и состоит всего лишь из символов английского алфавита. Для поиска «TTL» в результатах ping.exe удобнее всего объединить ее выполнение в цепочку с командой поиска строки символов FIND.EXE (конвейер ping и find). Если текст найден командой FIND, то значение переменной ERRORLEVEL будет равно 0
ping -n 1 COMPUTER | find /I «TTL» > nul
if %ERRORLEVEL%==0 goto LIVE
ECHO computer недоступен
подпрограмма обработки недоступного состояния
…
Exit
:LIVE — начало подпрограмм
ы обработки состояния доступности узла
…
…
В более простом варианте можно использовать команды:
PING yandex.ru |find «TTL=» && ECHO Yandex pingable — команда ECHO выполняется, если значение ERRORLEVEL, установленное FIND равно 0, т.е узел yandex.ru отвечает на ping.
PING Server64 |find «TTL=» || ECHO Server64 not pingable — команда ECHO выполняется, если значение ERRORLEVEL, установленное FIND не равно 0, т.е. узел Server64 не ответил на ping.
Весь список команд CMD Windows | На главную страницу.
Возвращается неправильный IP-адрес — Windows Server
- Чтение занимает 2 мин
В этой статье
В этой статье содержится решение проблемы, возвращаемой неправильным IP-адресом при ping сервере с помощью его имени NetBIOS.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 981953
Симптомы
У вас есть компьютер, на Windows Server 2008 или Windows Server 2008 R2. Когда сервер с несколькими IP-адресами пытается самостоятельно деспинговать с помощью своего имени NetBIOS, возвращается неправильный IP-адрес.
Причина
При выполнении ping с именем, а не IP-адресом, имя должно быть разрешено к IP-адресу. Если имя сервера, IP-адрес возвращается в качестве адреса сетевого адаптер, который находится в верхней или нижней части порядка привязки сети. Обычно это будет последний установленный сетевой адаптер, который может не быть интерфейсом, который вы ожидаете использовать. Поэтому команда ping возвращает неправильный IP-адрес.
Примечание
Если в сетевом адаптере имеется несколько адресов, предпочтительнее использовать адреса IPv6.
Решение
Чтобы решить эту проблему, можно изменить адаптер, на который выбран IP-адрес, перемещая предпочтительный адаптер в верхнюю или нижнюю часть привязки. Для скрытого адаптера, который не фигурировал в списке, можно создать файл Hosts, использующий имя сервера и предполагаемый IP-адрес. Примером скрытого адаптера является виртуальный адаптер кластера неудачной работы Майкрософт.
Изменение порядка привязки
Чтобы изменить порядок привязки, выполните следующие действия:
Нажмите кнопку Начните, а затем нажмите панель управления.
Щелкните Сеть и Интернет, а затем нажмите кнопку Network and Sharing Center.
Изменение параметров сетевого адаптера в зависимости от операционной системы:
Для Windows Server 2008 нажмите кнопку Управление настройками адаптеров.
Для Windows Server 2008 R2 нажмите параметры адаптер изменить.
Нажмите кнопку Упорядока, указать макет, а затем нажмите кнопку Меню.
В меню Advanced нажмите кнопку Advanced Параметры.
В окне Подключения выберите сетевой адаптер, который вам нужен.
Переместите этот сетевой адаптер в верхнюю часть списка или в нижнюю часть списка. Это можно сделать с помощью кнопок UP ARROW и DOWN ARROW.
Нажмите кнопку ОК.
Изменение файла «Хостс»
Для скрытого адаптера невозможно изменить порядок привязки с помощью действий в разделе «Как изменить порядок привязки». Для скрытых адаптеров необходимо добавить запись в файл Hosts, использующий предназначенное имя хоста и IP-адрес.
Чтобы изменить файл Hosts, выполните следующие действия:
Нажмите кнопку кнопку Все программы.
Щелкните аксессуары, щелкните правой кнопкой мыши Блокнот, а затем нажмите кнопку Выполнить в качестве администратора.
или предодокайте подтверждение.
В командную строку введите следующую команду и нажмите ВВОД:
cd %windir%\System32\Drivers\Etc
В командной подсказке введите хосты блокнота и нажмите кнопку ENTER.
В нижней части файла, открываемого на шаге 5, добавьте новую запись для предназначенного IP-адреса с помощью следующего формата: IP_Address Hostname
Например, для IP-адреса 10.0.0.1 для Server01 введите:
10.0.0.1Server01В меню File нажмите кнопку Сохранить, а затем Блокнот.
В командной подсказке введите ipconfig/flushdns и нажмите кнопку ENTER. Он будет перезагружать файл Hosts без перезапуска компьютера или сервера.
Примечание
Если вы хотите получить определенный адрес IPv4 для сетевого адаптер, можно использовать параметр -4. Например, можно использовать следующую команду:
ping -4 <host name>
Если вы хотите использовать адреса IPv4 в сети, вы можете Windows использовать адреса IPv4 вместо адресов IPv6. Однако мы не рекомендуем вам это делать. Настоятельно рекомендуется обновить сеть для использования адресов IPv6. Дополнительные сведения о том, как отключить IPv6, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
929852 Отключение некоторых компонентов протокола Интернета версии 6 (IPv6) в Windows Vista, Windows 7 и Windows Server 2008
Дополнительные сведения
Дополнительные сведения о функции getaddrinfo можно получить на следующем веб-сайте MSDN:
Функция getaddrinfo
Обнаружение хостовОдна из первейших задач при исследовании любой сети это сократить (иногда довольно большой) набор IP диапазонов до списка активных или интересных хостов. Сканирование каждого порта каждого IP адреса медленно и необязательно. Конечно же то, что делает хост интересным для исселедования во многом определяется целями сканирования. Сетевые администраторы возможно будут заинтересованы только в хостах, на которых запущена определенная служба, в то время как тем, кого интересует безопасность, будут интересны все устройства с IP адресами. Задачи администраторов по обнаружению работающих хостов в сети могут быть удовлетворены обычным ICMP пингом, людям же, которые тестируют способность сети противостоять атакам из вне, необходимо использовать разнообразные наборы запросов с целью обхода брандмауэра. Посколько задачи, требующие обнаружения хостов столь различны, Nmap предоставляет большое разнообразие опций
для различных методов. Задачу обнаружения хостов иногда называют пинг сканированием (ping scan), однако она намного
превосходит использование обычных ICMP запросов ассоциирующихся с вездесущими
ping утилитами. Пользователи могут полностью пропустить шаг пинг
сканирования с помощью опции сканирования с целью составления списка ( Если не задано никаких опций обнаружения хостов, то Nmap посылает TCP ACK пакет на порт 80 и запрос на ICMP
эхо ответ кажодй целевой машине. Исключение составляет ARP сканировании всех целей в сети. Для непривилегированных
пользователей Unix оболочки, вместо ACK пакета посылается SYN используя системный вызов Опции По умолчанию после обнаружения хостов Nmap начинает сканирование портов каждой активной машины. Так будет,
даже если вы укажите на использование нестандартных методов обнаружения хостов, например, с использованием
UDP запросов (
|
Тестирование соединений с помощью Ping-запросов | Answer
Команда «Ping» является одним из первых средств, которые нужно использовать для проверки подключения к компьютеру, маршрутизатору и Интернету. Она выполняется в командной строке, однако получить основные сведения о подключении достаточно просто. Вся процедура не займет больше 30 секунд.
- Чтобы выполнить команду ping, последовательно выберите пункты Пуск > Выполнить.
- В окне запуска программы введите cmd и нажмите кнопку ОК. Появится окно с черным фоном и белой командной строкой.
- Введите ping и через пробел IP-адрес или DNS-адрес.
- Нажмите клавишу Enter, чтобы выполнить команду. Три полезных примера:
- ping 127.0.0.1 («замыкание на себя» — компьютер пытается обратиться к самому себе. Эта проверка позволяет определить, может ли компьютер передавать трафик Ethernet. Отсутствие ответа после выполнения этой команды указывает на проблему с операционной системой.)
- ping 192.168.1.1 (Если после выполнения этой команды получен ответ «Превышен интервал ожидания для запроса.», введите команду ping 192.168.0.1. Если и в этом случае интервал ожидания превышен, это означает, что компьютер не подключается к маршрутизатору.)
- ping www.netgear.com. (Эта команда позволяет определить возможность подключения к компьютерам в Интернете.)
Если проблемы с подключением отсутствуют, результат выполнения команды ping должен быть аналогичен тому, который указан на снимке экрана ниже. Три интересующих нас результата отмечены красными стрелками.
Первый результат означает, что компьютер, с которым мы связываемся, отвечает. (DNS-адрес» www.netgear.com» преобразуется командой ping в эквивалентный IP-адрес 10.1.1.86.) Это демонстрирует наличие подключения к Интернету и работоспособность соответствующего удаленного компьютера. Веб-сайт www.netgear.com работает постоянно, поэтому этот адрес можно использовать для проверки связи.
Второй результат показывает, что потери переданных пакетов Ethernet составляют «0%». Это наилучший возможный результат выполнения команды. Он указывает на небольшую загруженность сети и отсутствие необходимости отправлять одну и ту же информацию повторно.
Третий результат представляет собой среднее время ответа. «Среднее = 0 мс» — это наилучший возможный результат. Возможно, такие быстрые ответы могут быть получены только от компьютеров, находящихся в вашей сети.
Интерпретация результатов выполнения команды при наличии проблем
В отношении оборудования NETGEAR наиболее вероятной проблемой может быть превышение интервала ожидания запроса. Это указывает на отсутствие подключения. Обратитесь к разделу Не удается войти в систему маршрутизатора или Отсутствие доступа к Интернету через маршрутизатор.
Другой наиболее вероятной проблемой может быть сообщение об ошибке «Неизвестный хост», которая указывает лишь на то, что указанный DNS- или IP-адрес не существует. Возможно, при его вводе была допущена ошибка.
Другие проблемы обычно не входят в сферу компетентности службы поддержки NETGEAR. Зачастую они возникают на стороне интернет-провайдера. В таком случае рекомендуется обратиться к своему интернет-провайдеру. Неоднозначная ситуация возникает тогда, когда процент потери переданных пакетов отличается от значения 0 %. Иногда это указывает на наличие серьезной проблемы, а иногда это не является признаком какой-либо неполадки. Однако если потери выше 5 %, это однозначно указывает на проблему.
Если среднее время ответа превышает 500 мс, возможно, существует проблема с задержкой в сети. В этом случае так же рекомендуется обратиться к своему интернет-провайдеру.
Ограничения, связанные с выполнением команды ping
- Это средство не подходит для диагностики кратковременных проблем.
- Хорошие результаты выполнения команды достаточно объективны, тогда как неудовлетворительные результаты могу быть вызваны различным набором любых проблем, поэтому им не всегда стоит полностью доверять.
- Для выполнения команды ping используются ICMP-пакеты, приоритет которых достаточно низкий. Они передаются с меньшей скоростью, чем обычный сетевой трафик. Некоторые компьютеры не принимают ICMP-пакеты, а, значит, полностью блокируют команду проверки связи.
- Если IP-адрес имеется в результатах выполнения команды трассировки маршрута, это НЕ означает, что такой IP-адрес должен обязательно отвечать на запросы команды проверки связи.
Обновлено:11/28/2016 | Article ID: 22332
Руководство по устранению проблем многоадресной IP-рассылки
Содержание
Введение
Предварительные условия
Требования
Используемые компоненты
Условные обозначения
Общие сведения
Маршрутизатор не пересылает на хост многоадресные пакеты по причине ошибки RPF
Выявление ошибок
Возможные способы решения проблемы
Маршрутизатор не пересылает на хост многоадресные пакеты из-за значения TTL, установленного у источника
Выявление ошибок
Возможные способы решения проблемы
Маршрутизатор не пересылает на хост многоадресные пакеты из-за порогового значения времени TTL, установленного на маршрутизаторе
Выявление ошибок
Возможные способы решения проблемы
Множественные равноценные пути приводят к нежелательному поведению обратного пути при продвижении данных
Выявление ошибок
Возможные способы решения проблемы
Почему при многоадресной IP-рассылке не выполняется балансировка нагрузки по всем имеющимся равноценным путям?
Возможные способы решения проблемы
Почему маршрутизатор выдает сообщения об ошибках многоадресной рассылки «INVALID_RP_JOIN»?
Выявление ошибок (часть 1)
Выявление ошибок (часть 2)
Протокол CGMP не предотвращает возникновение потока многоадресных пакетов
Выявление ошибок
Проверки
Возможные способы решения проблемы
Протокол CGMP не предотвращает затопление многоадресными пакетами из-за размещения источника/получателя.
Выявление ошибок
Возможные способы решения проблемы
Протокол CGMP не предотвращает возникновение потока многоадресных пакетов для некоторых групповых адресов
Возможные способы решения проблемы
Дополнительная информация
В настоящем документе обсуждаются наиболее распространенные проблемы, связанные с многоадресной IP-рассылкой, а также устранение этих проблем.
Требования
Настоящий документ не содержит каких-либо специфических требований.
Используемые компоненты
Область применения настоящего документа не ограничивается какими-либо конкретными версиями аппаратного и программного обеспечения.
Условные обозначения
Дополнительные сведения об условных обозначениях в документах см. в «Технические советы Cisco. Условные обозначения».
При устранении неполадок, связанных с многоадресной маршрутизацией, особую важность представляет исходный адрес. Групповая, или многоадресная рассылка использует проверку, которая называется «проверка наличия обратного маршрута». Когда многоадресный пакет поступает на интерфейс, процесс RPF проверяет, является ли этот входящий интерфейс исходящим интерфейсом, используемым одноадресной маршрутизацией для доступа к источнику многоадресного пакета. Использование данного процесса проверки RPF позволяет предотвратить появление петель. Многоадресная маршрутизация не будет перенаправлять пакет, пока источник, отправивший этот пакет, не прошел проверку RPF. Как только пакет проходит эту проверку, многоадресная маршрутизация перенаправляет пакет, используя для этого только адрес назначения.
Также как и в случае одноадресной маршрутизации, многоадресная маршрутизация может использоваться в нескольких протоколах. Например: режим уплотнения в протоколе многоадресной рассылки независимой от протокола, разреженный режим PIM, протокол дистанционно-векторной многоадресной маршрутизации, протокол пограничной многоадресной маршрутизации и протокол обнаружения источников многоадресных сообщений. Случаи, рассматриваемые в настоящем документе, поэтапно описывают процесс устранения различных неполадок. Вы узнаете, какие команды необходимо использовать, чтобы быстро локализовать проблему, а также узнаете, как устранить ее. Предлагаемые случаи являются типичными для всех протоколов, за исключением особо оговоренных примеров.
В этом разделе предлагается решение общераспространенной проблемы многоадресной IP-рассылки, связанной со сбоем RPF. В качестве примера используется следующая диаграмма сети:
На рисунке выше показано, что многоадресные пакеты поступают на интерфейс E0/0 маршрутизатора 75a. Пакеты поступают с сервера, имеющего IP-адрес 1.1.1.1 и выполняющего рассылку для группы 224.1.1.1. Это называется (S,G) или (1.1.1.1, 224.1.1.1).
Выявление ошибок
Хосты, подключенные непосредственно к маршрутизатору 75a, получают многоадресные пакеты, в то время как хосты, непосредственно подключенные к маршрутизатору 72a таких пакетов не получают. Сначала выполните команду show ip mroute 224.1.1.1 для того, чтобы посмотреть, что происходит на маршрутизаторе 75a. Эта команда произведет осмотр многоадресного маршрута для группового адреса 224.1.1.1:
75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
Поскольку маршрутизатор работает в режиме уплотнения PIM (на это указывает флаг «D»), то мы не обращаем внимания на запись «*,G», а сосредотачиваемся на записи «S,G». Эта запись указывает на то, что источником многоадресных пакетов является сервер, который имеет адрес 1.1.1.1 и который выполняет рассылку на многоадресную группу 224.1.1.1. Пакеты рассылки поступают на интерфейс Ethernet0/0 и затем уходят с интерфейса Ethernet0/1. Это идеальный сценарий.
Выполните команду show ip pim neighbor, чтобы посмотреть, отображается ли восходящий маршрутизатор (75a) маршрутизатором 72a в качестве соседа PIM:
ip22-72a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 2.1.1.1 Ethernet3/1 2d00h 00:01:15 v2
Из листинга команды show ip pim neighbor видно, что с окружением PIM все в порядке.
Выполните команду show ip mroute, чтобы посмотреть, имеется ли у маршрутизатора 72a хороший многоадресный маршрут:
ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Dense, 00:10:42/00:00:00 Ethernet3/2, Forward/Dense, 00:10:42/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags: Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Dense, 00:01:10/00:00:00 Ethernet3/2, Forward/Dense, 00:00:16/00:00:00 ip22-72a#
Из листинга команды show ip mroute 224.1.1.1 мы видим, что входящим интерфейсом является интерфейс Ethernet2/0, в то время как это должен был бы быть интерфейс Etheret3/1.
Выполните команду show ip mroute 224.1.1.1 count, чтобы посмотреть, поступает ли на маршрутизатор 72а какой-нибудь многоадресный трафик для этой группы, а также узнать, что потом происходит с этим трафиком:
ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2032 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471 Source: 1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0 ip22-72a#
В строке Other counts мы видим, что трафик сбрасывается по причине сбоя RPF: total 471 drops, due to RPF failure – 471…
Выполните команду show ip rpf <source>, чтобы проверить, нет ли какой-нибудь ошибки RPF:
ip22-72a#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 1.1.1.1/32 RPF type: unicast (static) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-72a#
Программное обеспечение Cisco IOS® рассчитывает интерфейс RPF следующим образом. Возможные источники информации RPF: одноадресная таблица маршрутизации, таблица маршрутизации MBGP, таблица маршрутизации DVMRP и таблица статических многоадресных маршрутов. При расчете RPF интерфейса, для того чтобы определить, на каком источнике информации будет основываться расчет RPF, в основном используется административное расстояние. Конкретные правила таковы:
По всем предшествующим источникам данных RPF выполняется поиск на предмет совпадения с исходным IP-адресом. При использовании Разделяемых деревьев вместо исходного адреса используется адрес точки встречи (RP-адрес).
Если в результате поиска было обнаружено более одного подходящего маршрута, тогда будет использован маршрут, имеющий наименьшее административное расстояние.
При одинаковых значениях административных расстояний действует следующая приоритетность:
Статические многоадресные маршруты
Маршруты DVMRP
Маршруты MBGP
Одноадресные маршруты
Если в одной и той же таблице маршрутов для одного пути будут найдено несколько записей, тогда будет использован маршрут с самым длинным совпадением.
Из листинга команды show ip rpf 1.1.1.1 видно, что интерфейсом RPF является интерфейс E2/0, однако входящим интерфейсом должен быть интерфейс E3/1.
Выполните команду show ip route 1.1.1.1, чтобы узнать, почему номер интерфейса RPF отличается от ожидаемого.
ip22-72a#show ip route 1.1.1.1 Routing entry for 1.1.1.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Ethernet2/0 Route metric is 0, traffic share count is 1
Из листинга команды show ip route 1.1.1.1 можно видеть, что существует статический маршрут /32, из-за которого был выбран ошибочный интерфейс RPF.
Выполните следующие отладочные команды:ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface
Теперь пакеты приходят на интерфейс E3/1, что и требовалось. Однако эти пакеты по-прежнему сбрасываются, поскольку данный интерфейс не является интерфейсом, который используется таблицей одноадресной маршрутизации для проверки RPF.
Примечание: процедура отладки пакетов представляет опасность. Данная процедура запускает коммутацию процессов для многоадресных пакетов, что приводит к увеличению загрузки ЦП. Кроме того, отладка пакетов может привести к возникновению больших объемов выходных данных, что в свою очередь может привести к полному зависанию маршрутизатора из-за медленного вывода данных на консольный порт. Перед отладкой пакетов обязательно надо отключить протоколирование в консоль и включить протоколирование в буферную память. Чтобы сделать это, выполните команды no logging console и logging buffered debugging. Результаты отладки можно посмотреть воспользовавшись командой show logging.
Возможные способы решения проблемы
Вы можете либо внести изменения в таблицу одноадресной маршрутизации либо добавить статический многоадресный маршрут, чтобы принудительно запустить многоадресную рассылку на RPF через требуемый интерфейс, независимо от того, что указано в таблице одноадресной маршрутизации. Добавление статического многоадресного маршрута:
ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1
Этот статический mroute формулирует, что для достижения адреса 1.1.1.1 для RPF в качестве адреса следующей ретрансляции необходимо использовать 2.1.1.1, являющийся внешним интерфейсом E3/1.
ip22-72a#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet3/1 RPF neighbor: ? (2.1.1.1) RPF route/mask: 1.1.1.1/32 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables
Листинг команд show ip mroute и debug ip mpacket выглядит удовлетворительно. Количество отправленных пакетов, отображаемых счетчиком show ip mroute count, увеличивается. Хост А получает пакеты.
ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 (1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 2.1.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019 Source: 1.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026 Source: 1.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0 ip22-72a# ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 10:18:29.951: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward
В этом разделе описывается решение распространенной проблемы, связанной с многоадресными пакетами IP, которые не были переданы из-за нулевого значения времени жизни (time to live – TTL). Это довольно распространенная проблема, поскольку существуют большое количество различных приложений, выполняющих многоадресную рассылку. Эти приложения в основном предназначены для использования в локальных сетях и в силу этого для них устанавливается низкое значение времени TTL, иногда это значение может быть равно 1. В качестве примера рассмотрим диаграмму сети, приведенную ниже:
Выявление ошибок
На рисунке выше маршрутизатор A не пересылает пакеты, поступившие от источника S, на маршрутизатор В, к которому напрямую подключен Получатель (Receiver). Чтобы узнать состояние многоадресной маршрутизации, воспользуемся листингом команды show ip mroute, выполненной на маршрутизаторе A:
ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 (*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00
Запись 224.0.1.40 можно оставить без внимания, поскольку все маршрутизаторы входят в состав этой группы Auto-RP Discovery. Однако для 224.1.1.1. в листинге не указано никакого источника. Помимо «*, 224.1.1.1», необходимо посмотреть «1.1.1.1, 224.1.1.1».
Выполните команду show ip rpf, чтобы узнать, не связано ли это со сбоем RPF:
ROUTERA#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 1.1.1.0/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables
Из приведенного выше листинга видно, что с RPF все в порядке. Проверка RPF корректно указывает на интерфейс E0/0, ведущий к IP-адресу источника.
Проверьте, настроен ли протокол PIM на интерфейсах. Для этого используйте команду show ip pim interface:
ROUTERA#show ip pim interface Address Interface Version/Mode Nbr Query DR Count Intvl 1.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 1.1.1.2 2.1.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 2.1.1.2
Листинг показывает, что с протоколом все в порядке. Проверьте, распознается ли активный трафик маршрутизатором. Для этого используйте команду show ip mroute active:
ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps
Из приведенного выше листинга видно, что маршрутизатор не распознает активный трафик.
ROUTERA#debug ip mpacket IP multicast packets debugging is on
Вероятно, получатель не отправляет никаких IGMP-отчетов (вступлений) [Internet Group Management Protocol – протокол управления группами Интернета для группы 224.1.1.1. Это можно проверить выполнив команду show ip igmp group:
ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 2.1.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 3.1.1.2
Для группы 224.1.1.1 имеется присоедиение (join) на интерфейсе E1/2. Это очень хорошо.
Насыщенный режим PIM – это протокол переполнения и отсечения, поэтому здесь присоединения отсутствуют, но имеются наращивания (grafts). Поскольку маршрутизатор В не получил потока от маршрутизатора А, он не знает, куда следует отправлять наращивание.
Можно проверить, не является ли это проблемой времени TTL. Для этого можно воспользоваться анализатором пакетов или выполнить команду show ip traffic:
ROUTERA#show ip traffic IP statistics: Rcvd: 248756 total, 1185 local destination 0 format errors, 0 checksum errors, 63744 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options
В приведенном выше листинге указано – «63744 bad hop counts». При каждом запуске этой команды это число увеличивается. Это серьезное указание на то, что отправитель отправляет пакеты, время TTL которых равно 1. Маршрутизатор А уменьшает это значение до 0. Это ведет к увеличению числа, указанного в поле «bad hop count».
Возможные способы решения проблемы
Чтобы устранить эту проблему, необходимо увеличить время TTL. Это можно сделать на уровне приложений отправителя. Более подробно см. в инструкции к вашему приложению многоадресной рассылки.
После этой операции состояние маршрутизатора А выглядит следующим образом:
ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 (*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 (1.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00
Именно это нам и нужно.
На маршрутизаторе В можно видеть следующее:
ROUTERB#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 (*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 (1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1 Outgoing interface list: Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00
В этом разделе предлагается решение широко распространенной проблемы, связанной с тем, что при низком значении порога TTL многоадресный трафик IP перестает поступать к получателю. В качестве примера используется следующая диаграмма сети:
Выявление ошибок
На рисунке выше получатель (Receiver) не получает многоадресные пакеты, поступающие от источника (Source). Между источником и маршрутизатором 75а могут находиться несколько маршрутизаторов. Сначала проверим маршрутизатор 75a, поскольку он подключен непосредственно к получателю.
ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00
Из приведенного выше листинга видно, что маршрутизатор 75a перенаправляет пакеты через исходящий интерфейс Ethernet0/1. Чтобы быть полностью уверенным в том, что маршрутизатор 75a перенаправляет пакеты, включите отладку (debug) для этого источника и для группы многоадресной рассылки:
ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 1.1.1.1 host 224.1.1.1 ip22-75a(config)#end ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied
Показанные выше отладочные сообщения указывают на то, что маршрутизатор 75a не перенаправляет многоадресные пакеты, потому что было достигнуто пороговое значение времени TTL. Можно проверить настройки маршрутизатора, чтобы найти причину этой неполадки. Итак, «виновник» найден:
interface Ethernet0/1 ip address 2.1.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15
Пороговое значение TTL, установленное на маршрутизаторе, равняется 15. Однако это не означает, что пакеты, имеющие пороговое значение TTL выше 15, не могут отправляться. В действительности верно обратное. Приложение отправляется с пороговым значением TTL равным 15. К тому моменту, когда приложение достигает маршрутизатора 75a, значение TTL у многоадресных пакетов становится меньше 15.
Команда ip multicast ttl-threshold <value> означает, что любые пакеты, значение TTL у которых ниже указанного порога (в нашем случае это значение равно 15) перенаправляться не будут. Эта команда обычно используется, чтобы организовать «заграждение», которое не позволит внутреннему многоадресному трафику выйти за пределы внутренней сети.
Возможные способы решения проблемы
Можно «отключить» команду ip multicast ttl-threshold <value> указав аргумент no. В результате этого будет установлено значение TTL, используемое по умолчанию, – 0. Можно также уменьшить пороговое значение TTL таким образом, чтобы трафик начал проходить через маршрутизатор.
В данном разделе описывается ситуация, при которой наличие множественных равноценных путей до источника может стать причиной нежелательного поведения функции переадресации в обратном направлении (Return Path Forwarding – RPF). Здесь также описано, как настроить многоадресную IP-рассылку таким образом, чтобы избежать такого режима работы. В качестве примера используется следующая диаграмма сети:
Выявление ошибок
На рисунке выше показано, что у маршрутизатора 75b есть три равноценных обратных пути к источнику (1.1.1.1), и при этом маршрутизатор выбирает канал, который вы не предпочли бы выбрать первым в качестве канала RPF.
При наличии нескольких равноценных путей до источника многоадресная IP-рассылка в качестве исходящего интерфейса выбирает интерфейс, у которого имеется сосед PIM с наиболее высоким значением IP-адреса, а затем по остальным каналам отправляет другим соседям PIM сообщения об отсечении (prunes).
Возможные способы решения проблемы
Чтобы сменить интерфейс, который многоадресная IP-рассылка выбирает в качестве своего входящего интерфейса, можно выполнить одно из следующих действий:
Настройте PIM только на интерфейсах, через которые должна проходить многоадресная рассылка (это означает, что будет утрачена избыточность многоадресной рассылки).
Измените подсети таким образом, чтобы IP-адрес с наибольшим значением приходился на канал, который вы хотите использовать для многоадресной рассылки в первую очередь.
Создайте статический многоадресный маршрут (mroute), который будет указывать на предпочтительный многоадресный интерфейс (это означает, что будет утрачена избыточность многоадресной рассылки).
В качестве примера создадим статический многоадресный маршрут.
Прежде чем устанавливать статический многоадресный маршрут, необходимо убедиться, что в приведенном ниже листинге таблица маршрутизации содержит три равноценных пути к исходному адресу 1.1.1.1. Информация RPF указывает, что RPF-интерфейсом является интерфейс E1/3:
ip22-75b#show ip route 1.1.1.1 Routing entry for 1.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 3.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet1/3 RPF neighbor: ? (4.1.1.1) RPF route/mask: 1.1.1.0/24 RPF type: unicast (ospf 1) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00 (1.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT Incoming interface: Ethernet1/3, RPF nbr 4.1.1.1 Outgoing interface list: Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42
После настройки статического многоадресного маршрута в листинге можно видеть, что RPF-интерфейс поменялся на интерфейс E1/1:
ip22-75b#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 2.1.1.1 ip22-75b(config)#end ip22-75b#show ip rpf 1.1.1.1 RPF information for ? (1.1.1.1) RPF interface: Ethernet1/1 RPF neighbor: ? (2.1.1.1) RPF route/mask: 1.1.1.1/0 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip route 1.1.1.1 Routing entry for 1.1.1.0/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 3.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00 (1.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47 Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28
В этом разделе предлагается решение распространенной проблемы по настройке многоадресной IP-рассылки, которая связана с неравномерным распределением нагрузки по всем доступным путям с одинаковой стоимостью. В качестве примера используется следующая диаграмма сети:
На приведенном выше рисунке видно, что у маршрутизатора 75b имеются три равноценных обратных пути к источнику (1.1.1.1). Нам необходимо выполнить балансировку многоадресного трафика по всем трем каналам.
Возможные способы решения проблемы
В разделе Множественные равноценные пути приводят к нежелательному поведению обратного пути при продвижении данных мы узнали, что для проведения проверки RPF протокол PIM выбирает только один интерфейс, отсекая при этом все остальные интерфейсы. Это означает, что у нас не происходит балансировка нагрузки. Для балансировки нагрузки необходимо удалить PIM из избыточных каналов и создать туннель между маршрутизаторами 75a и 75b. Затем можно распределить нагрузку на уровне канала, а IP будет выполняться по туннелю.
Ниже приведены настройки туннеля:
Маршрутизатор 75a |
---|
интерфейс Tunnel0 ip address 6.1.1.1 255.255.255.0 ip pim tunnel source Ethernet0/0 tunnel destination 5.1.1.1 ! interface Ethernet0/0 ip address 1.1.1.2 255.255.255.0 ip pim sparse-dense-mode ! interface Ethernet0/1 ip address 2.1.1.1 255.255.255.0 ! interface Ethernet0/2 ip address 3.1.1.1 255.255.255.0 ! interface Ethernet0/3 ip address 4.1.1.1 255.255.255.0 |
Маршрутизатор 75b |
---|
интерфейс Tunnel0 ip address 6.1.1.1 255.255.255.0 ip pim sparse-dense-mode tunnel source Ethernet1/4 tunnel destination 1.1.1.2 ! interface Ethernet1/1 ip address 2.1.1.2 255.255.255.0 ! interface Ethernet1/2 ip address 3.1.1.2 255.255.255.0 ! interface Ethernet1/3 ip address 4.1.1.2 255.255.255.0 ! interface Ethernet1/4 ip address 5.1.1.1 255.255.255.0 ip pim sparse-dense-mode ! ip mroute 0.0.0.0 0.0.0.0 Tunnel0 |
После настройки туннеля выполните команду show ip mroute, чтобы посмотреть многоадресный маршрут (mroute) для данной группы:
ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 (1.1.1.1, 224.1.1.1), 02:40:32/00:03:29, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00 Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00 (1.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT Incoming interface: Tunnel0, RPF nbr 6.1.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00
Чтобы убедиться в том, что многоадресные данные равномерно распределяются по всем трем каналам, проверьте интерфейсные данные маршрутизатора 75a.
Входящий интерфейс имеет пропускную способность 9000 бит/с:
ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec
Каждый из трех выходных интерфейсов показывает 3000 бит/с:
ip22-75a#show interface e0/1 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/2 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/3 . . 5 minute output rate 3000 bits/sec, 7 packets/sec
В этом разделе предлагается решение широко распространенной проблемы, связанной с сообщением об ошибке – «INVALID_RP_JOIN».
Выявление ошибок (часть 1)
Сообщение об этой ошибке поступает на точку встречи (Rendezvous Point – RP):
00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 1.1.6.2 for invalid RP 1.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 1.1.6.2 for invalid RP 1.1.5.4
Причины этой ошибки описаны в справочнике Сообщения о системных ошибках программного обеспечения Cisco IOS Software: нисходящий PIM-маршрутизатор отправил для общего дерева сообщение о присоединении (join message), которое этот маршрутизатор отказывается принимать. Такое поведение говорит о том, что этот маршрутизатор разрешает присоединяться к конкретной точке встречи только нисходящим маршрутизаторам.
Возможно, включен какой-нибудь механизм фильтрации. Следует проверить конфигурацию этого маршрутизатора:
interface Ethernet0/0 ip address 1.1.5.4 255.255.255.0 ip pim sparse-dense-mode ! ip pim accept-rp 10.2.2.2 8 ip pim send-rp-announce Ethernet0/0 scope 15 ip pim send-rp-discovery scope 15 ! access-list 8 permit 224.0.0.0 0.255.255.255
Какую роль в приведенной выше конфигурации выполняет оператор accept-rp? В Документации CCO говорится, что «для настройки маршрутизатора на принятие запросов Join или Prune, предназначенных для указанной точки RP или конкретного списка групп, необходимо использовать команду глобальной настройки ip pim accept-rp«. Чтобы снять этот флажок, используйте эту команду с аргументом no.
Когда команда ip pim accept-rp будет отключена, эти сообщения прекратятся. Итак, источник проблемы был найден. А как быть в том случае, если эта команда должна присутствовать в настройках? В этом случае вы можете разрешить использование ошибочного RP-адреса. Чтобы посмотреть правильный RP-адрес, выполните команду show ip pim rp mapping:
ip22-75a#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP (Auto-RP) This system is an RP-mapping agent Group(s) 224.0.0.0/4 RP 1.1.5.4 (?), v2v1 Info source: 1.1.5.4 (?), via Auto-RP Uptime: 01:00:48, expires: 00:02:07
Согласно вышеприведенному листингу, адрес 1.1.5.4 — единственный RP-адрес, который был получен через Auto-RP или иным способом. Однако, данный маршрутизатор является единственной точкой встречи для групп 224.0.0.0/4. Таким образом, оператор pim accept-rp, указанный в конфигурации выше, является ошибочным.
Возможные способы решения проблемы
Необходимо исправить IP-адрес в операторе ip pim accept-rp следующим образом:
Измените данный оператор:
ip pim accept-rp 10.2.2.2 8
На следующее:
ip pim accept-rp 1.1.5.4 8
Оператор также можно изменить таким образом, чтобы он принимал то, что хранится в кэше auto-rp. При этом убедитесь, что в списке доступа (8 в этом примере) разрешен необходимый диапазон группы многоадресной рассылки. Приведем пример:
ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255
Выявление ошибок (часть 2)
Данное сообщение об ошибке выводится на маршрутизаторе 2.
router2# *Aug 12 15:18:17.891: %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40) Join from 0.0.0.0 for invalid RP 2.1.1.1
Проверьте, является ли маршрутизатор 2 точкой встречи для группы 224.1.1.1:
router2#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 1.1.1.1 (?), v2v1 Info source: 1.1.1.1 (?), elected via Auto-RP Uptime: 00:21:26, expires: 00:02:24 router2#
1.1.1.1 – точка встречи для 224.1.1.1.
Проверьте, является этот интерфейс одним из интерфейсов маршрутизатора 2:
router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 1.1.1.2 YES NVRAM up up Ethernet1/0 2.1.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#
Поскольку маршрутизатор 2 не является точкой встречи, он не должен был получать пакет RP-Join. Проверьте, почему нисходящий маршрутизатор отправил этот пакет маршрутизатору 2, в то время как он не должен был делать этого:
router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 1.1.1.1 (?), v2v1 Info source: 1.1.1.1 (?), elected via Auto-RP Uptime: 00:24:30, expires: 00:02:16 Group(s): 224.0.0.0/4, Static-Override RP: 2.1.1.1 (?) router3#
Как видно, маршрутизатор 3 имеет статически настроенную информацию RP, указывающую на маршрутизатор 2, что неправильно. Теперь понятно, почему маршрутизатор 3 отправляет пакет RP-Join маршрутизатору 2.
Возможные способы решения проблемы
Можно настроить маршрутизатор 2 в качестве точки встречи для группы 224.1.1.1, а можно изменить настройки на маршрутизаторе 3 таким образом, чтобы он ссылался на корректный PR-адрес.
router3#show run | i rp ip pim rp-address 2.1.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 2.1.1.1 override router3(config)#exit router3#
После соответствующего изменения настроек маршрутизатор 3 ссылается на корректный RP-адрес, а сообщение об ошибке больше не выводится.
router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 1.1.1.1 (?), v2v1 Info source: 1.1.1.1 (?), elected via Auto-RP Uptime: 00:30:45, expires: 00:02:02 router3#
В данном разделе рассказывается о том, каким образом может возникнуть нежелательный поток многоадресных пакетов в том случае, когда протокол управления группами Cisco (CGMP) включен лишь на некоторых маршрутизаторах конкретной подсети, а также рассказывается о том, как можно избежать возникновения этой проблемы. В качестве примера используется следующая диаграмма сети:
Выявление ошибок
На рисунке выше в статической таблице CAM на маршрутизаторе Catalyst 5000 (Switch A) не указано ни одного правильного порта, которые были бы заняты. Маршрутизатор, выполняющий протокол CGMP, не отправляет пакетов CGMP.
Протокол CGMP был корректно настроен при помощи команды set cgmp enable на коммутаторе А и при помощи команды ip cgmp на интерфейсе E0/2 маршрутизатора 75a. Однако при выполнении команды show multicast group на коммутаторе А не отображается ни одной группы многоадресной рассылки:
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- Total Number of Entries = 0
В листинге этой команды должны быть указаны все порты, к которым подключен CGMP-маршрутизатор (port 2/3), а также все порты, к которым подключен заинтересованный получатель (port 2/6). Поскольку в последней строке листинга указан 0, мы можем предположить, что все порты необоснованно «затопляются» многоадресным трафиком, хотим мы этого или нет.
Проверки
Проверьте, имеются ли какие-нибудь PIM-соседи у маршрутизатора 75а:
ip22-75a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 2.1.1.1 Ethernet0/2 00:07:41 00:01:34 v2
Из приведенного выше листинга видно, что маршрутизатор 75a видит маршрутизатор 75b (через коммутатор A) как действующего PIM-соседа.
Теперь проверим, получают ли эти маршрутизаторы корректную информацию о многоадресном маршруте (mroute):
ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00 (1.1.1.1, 224.1.1.1), 00:14:56/00:02:59, flags: CTA Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00
Из приведенного выше листинга видно, что маршрутизатор 75a перенаправляет пакеты через исходящий интерфейс Ethernet0/2 в сторону коммутатора А. В листинге, представленном ниже, мы видим, что маршрутизатор 75b получает многоадресные пакеты и корректно переадресует их:
ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00 Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00 (1.1.1.1, 224.1.1.1), 00:00:35/00:02:59, flags: CTA Incoming interface: Ethernet1/3, RPF nbr 2.1.1.2 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
Если посмотреть со стороны коммутатора А, то видно, что коммутатор видит маршрутизатор 75 со стороны порта 2/3.
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 Total Number of Entries = 1
Итак, до сих пор все было прекрасно. Выполним несколько отладочных команд на маршрутизаторе 75а. Может быть нам удастся что-нибудь выяснить:
ip22-75a#debug ip cgmp CGMP debugging is on *Feb 8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:45:22.206: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:46:22.234: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:47:22.262: GDA 0000.0000.0000, USA 00d0.ff2f.a002
В приведенном выше листинге адрес 0000.0000.0000 является общегрупповым адресом, который используется в том случае, когда маршрутизаторы отправляют CGMP-сообщения Join/Leave с тем, чтобы коммутаторы могли занять их порты. В формате уровня МАС аббревиатура GDА означает Group Destination Address (адрес групп назначения), а аббревиатура USA означает Unicast Source Address (адрес источника одноадресной рассылки). Это адрес хоста, создавшего отчет IGMP, для которого генерируется это сообщение CGMP. В этом случае это – MAC-адрес для интерфейса E0/2 маршрутизатора 75a. MAC-адрес для интерфейса E0/2 на маршрутизаторе 75a можно посмотреть при помощи команды show interface:
ip22-75a#show interface e0/2 Ethernet0/2 is up, line protocol is up Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)
Кроме того, при включении команды debug ip igmp можно иногда видеть следующее:
*Feb 8 12:51:41.854: IGMP: Received v2 Report from 2.1.1.3 (Ethernet0/2) for 224.1.1.1
Однако затем мы не видим соответствующий CGMP-пакет, поступивший с маршрутизатора 75а. Это означает, что маршрутизатор 75a получает отчеты IGMP, но не генерирует необходимые пакеты CGMP, содержащие информацию для коммутатора A о том, какие порты следует блокировать. А это именно то, что ожидается от маршрутизатора 75а как запросчика IGMP. Из листинга, полученного с маршрутизатора 75а, видно, почему этого не происходит:
ip22-75a#show ip igmp interface e0/2 Ethernet0/2 is up, line protocol is up Internet address is 2.1.1.2/24 IGMP is enabled on interface Current IGMP version is 2 CGMP is enabled IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 3 joins, 1 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 2.1.1.2 (this system) IGMP querying router is 2.1.1.1 No multicast groups joined
Если к одной подсети подключены два маршрутизатора и если они оба настроены на работу с протоколом CGMP, то только один из этих маршрутизаторов будет отправлять CGMP-пакеты. Маршрутизатор, отправляющий CGMP-пакеты, является запрашивающим IGMP-маршрутизатором. Такой маршрутизатор представляет собой маршрутизатор с наименьшим значением IP-адреса из всех маршрутизаторов, на которых включен протокол IGMP.
В нашем случае IGMP включен как на маршрутизаторе 75а, так и на маршрутизаторе 75b (последний становится опрашивающим IGMP-маршрутизатором). Однако протокол CGMP включен только на маршрутизаторе 75a. Поскольку маршрутизатор 75а не является опрашивающим IGMP-маршрутизатором, никакие CGMP-пакеты не отправляются.
Возможные способы решения проблемы
Чтобы устранить эту проблему, на запрашивающем IGMP-маршрутизаторе необходимо настроить протокол CGMP. В нашем случае это маршрутизатор 75b. Сначала на маршрутизаторе 75b необходимо выполнить отладочные команды:
ip22-75b#conf t Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#int e 1/3 ip22-75b(config-if)#ip cgmp ip22-75b(config-if)#end ip22-75b#debug ip cgmp ip22-75b#debug ip igmp *Feb 8 12:58:42.422: IGMP: Received v2 Report from 2.1.1.3 (Ethernet1/3) for 224.1.1.1 *Feb 8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 *Feb 8 12:58:42.422: from 2.1.1.3 for 224.1.1.1 *Feb 8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 *Feb 8 12:58:42.422: GDA 0100.5e01.0101, USA 0030.b655.a859
Маршрутизатор 75b получает от 2.1.1.3 отчет IGMP для группы 224.1.1.1. Затем он отправляет CGMP-сообщение Join на коммутатор A для MAC-эквивалента 224.1.1.1 с MAC-адресом (USA) заинтересованного хоста 2.1.1.3. Коммутатор A определяет, какой порт включен на хосте, поэтому помечает его как открытый и блокирует другие порты.
Теперь на коммутаторе А все должно работать нормально:
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4,2/6 Total Number of Entries = 2
Так значительно лучше. На коммутаторе А пакеты 224.1.1.1 (01-00-5e-01-01-01) отправляются только с портов 2/3, 2/4 и 2/6, как это и должно быть. Затопление остальных портов прекратилось. Теперь общее количество записей указано правильно – 2 записи. МАС-адрес 01-00-5e-00-01-28 отображен из адреса многоадресной рассылки 224.0.1.40, который используется для CGMP-сообщений о рефлексивном присоединении (self joins).
В этом разделе описывается решение распространенной проблемы, связанной с коммутатором Catalyst, который затопляет трафиком все имеющиеся порты, вместо того, чтобы отправлять этот трафик на требуемый хост. В качестве примера используется следующая диаграмма сети:
Выявление ошибок
На рисунке сверху маршрутизаторы Router 75a и Router 75b, а также коммутатор Catalyst 5000 (Switch A) правильно настроены для многоадресной передачи данных и использования протокола CGMP. На хост поступает многоадресный трафик. Однако, этот трафик получают и все другие хосты, находящиеся со стороны коммутатора А. Коммутатор А выполняет лавинную маршрутизацию трафика через все порты. Это указывает на то, что протокол CGMP не работает.
Листинг команды show multicast group, выполненной на коммутаторе A, выглядит следующим образом:
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 Total Number of Entries = 1
Из приведенного выше листинга видно, что единственной группой является группа 224.0.1.40, которая используется маршрутизатором в момент, когда он отправляет CGMP-сообщения о рефлексивном присоединении для группы auto-RP. Почему случилось так, что нет никаких других групп?
Возможные способы решения проблемы
Чтобы найти решение, необходимо понимать, каким образом протокол CGMP ведет себя при определенных обстоятельствах. Маршрутизатор с включенным CGMP отправляет на коммутатор CGMP-сообщения о присоединении, информируя этот коммутатор о хостах, заинтересованных в конкретной группе многоадресной рассылки. Для этих хостов коммутатор осуществляет поиск MAC-адресов в таблице CAM, а затем пересылает многоадресные пакеты через порты соответствующих хостов и блокирует переадресацию многоадресных пакетов через остальные порты.
Если маршрутизатор получает многоадресные пакеты из источника, который находится на том же самом интерфейсе, на котором у маршрутизатора включен протокол CGMP, то тогда маршрутизатор отправляет CGMP-сообщения о рефлексивном присоединении через интерфейс, на котором включен CGMP.
Например, если бы источник находился на той же подсети (VLAN), 2.1.1.0/24, как и маршрутизаторы 75a и 75b, то CGMP работал бы так как надо. Маршрутизатор, получив сведения о пакетах из источника, отправит коммутатору CGMP-сообщение о рефлексивном присоединении, который динамически определит, на каких портах находится маршрутизатор, а затем заблокирует пересылку многоадресных пакетов через все другие порты.
Если маршрутизатор получает IGMP-отчеты от хоста, находящегося на том же интерфейсе, на котором у маршрутизатора включен протокол CGMP, то тогда маршрутизатор отправляет CGMP-сообщения о присоединении через интерфейс, на котором включен CGMP.
Другой пример: у нас имеется заинтересованный хост в той же самой VLAN. В этом случае при получении CGMP-маршрутизатором IGMP-отчета от хоста, который заинтересован в конкретной группе многоадресной рассылки, этот маршрутизатор отправил бы CGMP-сообщение о присоединении. В этом сообщении был бы указан МАС-адрес хоста, который хочет присоединиться, и группа, к которой он хочет присоединиться. Затем Catalyst 5000 осуществит проверку таблицы CAM для MAC-адресов хостов, поместит ассоциированный порт в список многоадресной группы и заблокирует все остальные незаинтересованные порты.
То же самое не справедливо для случаев, когда источник и заинтересованный хост или хосты находятся в подсети, отличной от подсети с включенным CGMP (VLAN). Многоадресные пакеты, поступающие от источника, не переключают маршрутизатор на отправку коммутатору CGMP-сообщений о рефлексивном присоединении. Таким образом, эти пакеты достигают коммутатора и передаются по всей VLAN. Данный сценарий продолжается до отправки хостом в VLAN от порта коммутатора IGMP-сообщения о присоединении. Только при получении отчета IGMP маршрутизатор отправляет пакет CGMP, который заставляет коммутатор добавлять порт соответствующего хоста в качестве переадресующего и блокировать все остальные порты (кроме портов маршрутизатора).
Чтобы протокол CGMP работал в транзитной сети, можно добавить хост к той же VLAN, к которой добавлены маршрутизаторы 75a и 75b, как показано на следующей схеме.
Или переместите источник на ту же подсеть, на которой находятся маршрутизаторы 75a и 75b, как в этом примере.
Переместите источник в ту же самую подсеть и затем проверьте листинг с коммутатора А:
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 2/4 6 Total Number of Entries = 2 '*' - Configured Console> (enable) Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4 Total Number of Entries = 2
Теперь на коммутаторе А адрес 224.1.1.1 (01-00-5e-01-01-01) отправляется только на порты маршрутизаторов 2/3 и 2/4 (а не на все порты, находящиеся от коммутатора А).
В данном разделе рассматриваются причины, по которым некоторые групповые IP-адреса заставляют протокол группового управления Cisco (CGMP) высылать многоадресный трафик на все порты в локальной сети. При использовании группового адреса 225.0.0.1 протокол CGMP не работает. Он пересылает многоадресный поток через всех порты коммутатора и бесполезно расходует пропускную способность. Однако если изменить адрес на 225.1.1.1, то CGMP будет работать так как надо. Что же не так с адресом 225.0.0.1, ведь он не является зарегистрированным адресом для протокола маршрутизации?
Возможные способы решения проблемы
Во-первых, важно представлять себе, каким образом адреса многоадресной рассылки 3-го уровня отображаются на адреса многоадресной рассылки 2-го уровня. Все кадры многоадресной IP-рассылки используют адреса уровня IEEE Media Access Control (MAC), начинающиеся с 24-битного префикса 0x0100.5e. При отображении адресов 3-го уровня на адреса 2-го уровня, 23 бита низкого порядка адреса многоадресной рассылки 3-го уровня отображаются на 23 бита низкого порядка MAC-адреса IEEE.
Необходимо также знать, что для IP-адреса многоадресной рассылки имеются 28 бит уникального адресного пространства (32 бита минус 4 бита, относящихся к префиксу класса D – 1110). Поскольку имеется только 23 бита, отображенных в адресе IEEE MAC, то остается 5 бит перекрытия. Это означает, что несколько адресов многоадресной рассылки 3-го уровня могут быть сопоставлены с одним адресом многоадресной рассылки 2-го уровня.
Например:
224.0.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001 224.128.0.1 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001
Обратите внимание, что в приведенном выше примере и адрес 224.0.0.1, и адрес 224.128.0.1 отображаются на один и тот же адрес многоадресной рассылки 2-го уровня.
Теперь когда нам известно, каким образом сопоставляются адреса многоадресной рассылки уровня 2 и уровня 3, мы попробуем найти решение указанной проблемы.
Коммутатор А направляет поток многоадресных пакетов на 224.0.0.x, потому что эти адреса являются локальными адресами канала, и нам необходимо убедиться, что локальные адреса канала попадают ко всем устройствам, находящимся в LAN. Коммутаторы Catalyst также направляют многоадресные пакеты на другие адреса многоадресной рассылки, которые на MAC-уровне сопоставлены неоднозначно с адресом 224.0.0.x (например, адрес 224.0.0.1 и адрес 225.0.0.1 оба сопоставляются с адресом 0100.5e00.0001). Коммутатор передает многоадресные пакеты, предназначенные для этих локальных адресов канала, независимо от того, включен CGMP или нет.
Следовательно, приложение многоадресной рассылки должно избегать использования адресов класса D, которые сопоставляются с адресом многоадресной рассылки 2-го уровня – 0100.5e00.00xx, где xx – шестнадцатеричное число от 00 до FF. Сюда входят следующие адреса класса D:
224.0.0.x (x = 0 to 255) 225.0.0.x . 239.0.0.x 224.128.0.x (x = 0 to 255) 225.128.0.x . 239.128.0.x
Использование команды TRACERT для устранения неполадок TCP/IP в Windows
Аннотация
В данной статье описывается TRACERT (Trace Route), служебная программа командной строки, который можно использовать для трассировки путь, который принимает пакет Internet Protocol (IP) до места назначения. В данной статье рассматриваются следующие вопросы:
-
Использование служебной программы TRACERT
-
Использование команды TRACERT для устранения неполадок
-
Сведения о параметрах команды TRACERT
Дополнительная информация
Использование служебной программы TRACERT
Диагностические программы TRACERT определяет маршрут к месту назначения, посылая эхо-сообщений протокола ICMP (Internet Control) пакетов в место назначения. В этих пакетов TRACERT использует разные значения IP Time To Live (TTL). Поскольку каждый маршрутизатор на пути обязан уменьшить значение поля TTL пакета, по крайней мере на 1 перед дальнейшей пересылкой пакета, значение TTL по сути является эффективным счетчиком переходов. Когда срок ЖИЗНИ пакетов достигает нуля (0), маршрутизатор посылает ICMP «Time Exceeded» сообщений на исходном компьютере. TRACERT отправляет первого эхо-пакета с TTL равным 1 и увеличивает значение TTL на 1 для каждого последующего отправляемого пока назначение не ответит или пока не будет достигнуто максимальное значение поля TTL. Сообщений ICMP «Time Exceeded», который промежуточные маршрутизаторы отправить назад отображается маршрут. Однако обратите внимание, что некоторые маршрутизаторы просто отбрасывать пакеты с истекшим сроком TTLs, и эти пакеты не видны для команды TRACERT. Команда TRACERT выводит упорядоченный список промежуточных маршрутизаторов, которые возвращают ICMP «Time Exceeded» сообщения. Параметр -d с помощью команды tracert программа TRACERT не требуется выполнять поиск в DNS для каждого IP-адреса, так, что команда TRACERT отображает IP-адрес ближних интерфейсов маршрутизаторов. В следующем примере команда tracert и ее результаты пакет проходит через два маршрутизатора (157.54.48.1 и 11.1.0.67), чтобы достигнуть узла 11.1.0.1. В этом примере основной шлюз — 157.54.48.1 и IP-адрес маршрутизатора в 11.1.0.0 сети находится в 11.1.0.67.The команды:
C:\>tracert 11.1.0.1В результате выполнения команды: Tracing route to 11.1.0.1 over a maximum of 30 hops ————————————————— 1 2 ms 3 ms 2 ms 157.54.48.1 2 75 ms 83 ms 88 ms 11.1.0.67 3 73 ms 79 ms 93 ms 11.1.0.1 Trace complete.
Использование команды TRACERT для устранения неполадок
TRACERT можно использовать, чтобы узнать в каком месте сети останавливаются пакеты. В следующем примере основной шлюз обнаружил, что существует не правильный путь для размещения на 22.110.0.1. Вероятно, либо маршрутизатор имеет проблемы конфигурации или 22.110.0.0 сети не существует, отражая неправильный IP-адрес. Команда:
C:\ > tracert 22.110.0.1В результате выполнения команды: Tracing route to 22.110.0.1 over a maximum of 30 hops —————————————————— 1 157.54.48.1 reports: Destination net unreachable. Trace complete. TRACERT полезна для устранения неполадок в больших сетях, где несколько путей может привести к той же точке или где задействовано множество промежуточных компонентов (мосты или маршрутизаторы).
Сведения о параметрах команды TRACERT
Существует несколько параметров командной строки, которые можно использовать с помощью команды TRACERT, несмотря на то, что параметры не являются обычно требуются для стандартных неполадок. В следующем примере синтаксис команды показывает все возможные варианты:
Tracert -d -h максЧисло -j списокУзлов — w Таймаут target_hostЧто делают параметры: -d Specifies to not resolve addresses to host names -h maximum_hops Specifies the maximum number of hops to search for the target -j host-list Specifies loose source route along the host-list -w timeout Waits the number of milliseconds specified by timeout for each reply target_host Specifies the name or IP address of the target host
Что такое ICMP — ping-test.ru
ICMP (ang. Internet Control Message Protocol) — это один из протоколов сетевого уровня в модели ISO/OSI. Его задачей является обслуживание функции контроля правильности работы сети. С его помощью передаются всякого рода, низкоуровневые сводки, с раскроенными неправильностями во время сетевых связей. Практически целая коммуникация между данными компьютерами или другими устройствами при употреблении протокола ICMP происходит незаметным для конечнего пользователя образом. Единичными исключениями являются здесь инструменты ping и traceroute.
Коммуникация, ицпользующая протокол ICMP, состоит в пересылке подходящих информаций об ошибках, раскроенных во время связи между двумя устройствами. Одиночная информация существует в виде пакета, сформированного надлежащим образом (ang. Datagram), который следовательно будет подвергнутый инкапсуляции в рамке протокола IP. Протокол ICMP, вопреки всеобщему мнению, не использует в своей работе протоколы TCP, ни UDP. Итак, не пользуется никакими сетевыми портами.
Устройство пакета ICMP следующее:
• Заголовок в 4 байтов — первый байт определяет тип пакета, второй — код операции, третий и четвёртый представляют собой контрольную сумму.
• Поле данных с долготой зависимой от типа пакета и его функции. В некоторых случаях может быть установленным с уровня инструмента, напр. догадливая команда ping в Виндоуз устанавливает размер данных пакета ECHO_REQUEST на 32 байта, а версия, встречающаяся в системах Юникс на 56 байтов.
Список некоторых типов сводок протокола ICMP:
Тип Значение
0 Echo Reply (поворот эха — «ответ на ping»)
1 — 2 Забронированные
3 Destination Unreachable (недостожимость места предназначения)
4 Source Quench (сдержание отправителя)
5 Redirect Message (измени трассирование)
6 Alternate Host Address (альтернативный адрес хоста)
7 Забронированные
8 Echo Request (требование эха)
9 Router Advertisement (объявление маршрутизатора (рутера))
10 Router Solicitation (выбор рутера)
11 Time Exceeded (превышение лимита времени)
12 Parameter Problem (проблема с параметром)
13 Timestamp (требование временного шифра)
14 Timestamp Reply (поворот временного шифра)
15 Information Request (требование информации)
16 Information Reply (поворот информации)
17 Address Mask Request (требование адресной маски)
18 Address Mask Reply (поворот адресной маски)
19 Забронированные для безопасности
20 — 29 Забронированные
30 Traceroute (слежка трассы)
31 Datagram Conversion Error (ошибка конверсии дейтаграммы)
32 Mobile Host Redirect (изменение адреса мобильного узла)
33 IPv6 Where-Are-You (вопрос IPv6 «где ты»)
34 IPv6 Here-I-Am (ответ IPv6 «я здесь»)
35 Mobile Registration Request (просьба регистрировать мобильный узел)
36 Mobile Registration Reply (ответ на проьбу регистрировать мобильный узел)
37 Domain Name Request (требование названия домена)
38 Domain Name Reply (поворот названия домена)
39 SKIP Algorithm Discovery Protocol
40 Photuris, Security failures
41-255 Забронированные
Поле кода операции в заголовке пакета ICMP определяет вид содержания в сообщении, зависимого от его типа. Например, пакет типа 3, то есть Destination Unreachable может заключать следующие коды операции во втором байте заголовка:
0 Целевая сеть недостижимая
1 Целевое устройство (хост) недостижимое
2 Целевой протокол недостижимый (или необслуживаемый)
3 Целевой порт недостижимый
4 Пакет должен быть подвергнутый фрагментации, а установили флаг DF (не фрагментируй)
5 Traceroute неправильная
6 Неизвестная целевая сеть
7 Целевое устройство (хост) неизвестное
8 Хост отправителя недоступный
9 Доступ в сеть воспрещённый
10 Доступ в устройство воспрещённый
11 Установка поля Type of Service (в заголовке IP) делает невозможным доступ в целевую сеть
12 Установка поля Type of Service (в заголовке IP) делает невозможным доступ в целевую сеть
13 Коммуникация воспрещённая
Примеры работы протокола ICMP:
• Ping — один из инструментов, выступающих практически в каждой операционной системе, обслуживающей протокол TCP/IP. С его помощью пакеты ICMP ECHO_REQUEST отправляются в целевой компьютер. Дистанционная машина, после получения такого сообщения должна ответить при помощи ECHO_REPLY. Поэтому можно определить следующее: Конфигурация сети делает возможной связь с дистанционной машиной, и оценку её нагрузки на основании информаций, касающихся количества потерянных пакетов и времени ответа.
• Traceroute – инструмент, делающий возможным определение, через какие маршрутизаторы проходит пакет по дороге к дистанционному компьютеру. Сначала, локальный компьютер посылает пакет ECHO_REQUEST в дистанционное устройство, с параметром ТТЛ (TTL -Time to Live), установленным на 1. Первый рутер уменьшает ТТЛ на один, значит до нуля, удаляет пакет и отсылает адресату сообщение ICMP TIME_EXCEEDED. Целевой компьютер, после получения такой информации, возобновляет высылку ECHO_REQUEST, но ц ТТЛ установленным на стоимость 2. Первый рутер уменьшает ТТЛ на 1, второй сделает то же самое, устанавливая 0, и вновь удалит пакет, и отошлёт сообщение TIME_EXCEEDED. Такая ситуация повтаряется так долго, что даже пакет доберётся до дистанционного комньютера, который тогда отошлёт отправителю сообщение ECHO_REPLY.
windows 7 — Определить неизвестный IP в нашей сети
Я не могу предоставить глобальное решение для вашей проблемы, только частичное. Вы можете добавить это к технике switch , чтобы расширить диапазон ваших возможностей.
Если пользователь, запускающий виртуальную машину, подключен к вашей локальной сети через Wi-Fi, вы можете идентифицировать его / ее с помощью трассировки. Причина в том, что вы показали нам, что виртуальная машина имеет IP-адрес в вашей локальной сети, следовательно, она находится в конфигурации с мостом .По техническим причинам соединения Wi-Fi не могут быть соединены мостом, поэтому все гипервизоры используют изящный трюк вместо реальной конфигурации моста: они используют proxy_arp , см., Например, эту запись в блоге Bodhi Zazen для объяснения того, как это работает для KVM, и эта страница для VMWare.
Поскольку вместо виртуальной машины на ARP-запросы есть компьютер, traceroute будет идентифицировать узел раньше виртуальной машины. Например, это результат моей трассировки с другого компьютера в моей локальной сети:
Мой traceroute [v0.85]
asusdb (0.0.0.0) Пн 1 июн 11:45:03 2015
Клавиши: Справка Режим отображения Перезапустить статистику Порядок выхода полей
Пакеты Пинги
Host Loss% Snt Last Avg Best Wrst StDev
1. расал.z.lan 0,0% 1 6,0 6,0 6,0 6,0 0,0
2. FB.z.lan
rasal — это хост-машина, FB — гость, я выдаю это с третьего компьютера (asusdb).
В Windows правильная команда —
tracert 10.0.0.131
В Linux можно сделать то же самое с очень удобной утилитой mtr :
мтр 10.0.0.131
Это дополняет, а не заменяет технику переключения. Если ваш traceroute показывает, что между вашим компьютером и виртуальной машиной нет промежуточных переходов, то, по крайней мере, вы будете знать, что можете исключить все компьютеры LAN, подключенные через Wi-Fi, ограничив диапазон ваших возможностей и сделав метод коммутатора эффективным. вероятность, , если у вас есть управляемый коммутатор или вы хотите отключать кабели в коммутаторе один за другим.
В качестве альтернативы вы можете подделать как техническую проблему и отключить все Ethernet-соединения, вынуждая ваших пользователей использовать Wi-Fi, пока ваш виновник не заглотит наживку.
Ping [компьютер] получить странный IP-адрес
Я почти уверен, что @hyperslug ударил его по голове. При использовании OpenDNS в качестве вашего DNS-провайдера, если вы попытаетесь разрешить неизвестное имя, они вернут IP-адрес, который «перенаправит» ваш браузер на свою страницу «результатов» под брендом . Вы никогда не увидите страницу «404» при использовании OpenDNS.
Если бы вы использовали DNS-серверы вашего интернет-провайдера и попытались выполнить запрос PING sam
, вы бы получили:
C: \> ping sam
Запрос Ping не может найти хост Sam.Пожалуйста, проверьте имя и попробуйте снова.
Чтобы исправить это (при условии, что вы хотите разрешить sam
по имени и не должны вводить IP-адрес), вам необходимо поместить запись в файл HOSTS
для «sam».
Из вашей таблицы маршрутизации я вижу, что вы находитесь в сети 192.168.52.x, а ваш компьютер — 192.168.52.152. Я также вижу, что ваш шлюз по умолчанию — 192.168.52.1. Вы не упомянули IP-адрес sam
.Для целей этого упражнения предположим, что sam
— 192.168.52.201.
Я предполагаю, что ваша среда — это Windows. Вам нужно отредактировать файл % windir% \ system32 \ drivers \ etc \ hosts.
Если вы никогда не использовали файл hosts и
, вам, вероятно, сначала придется переименовать % windir% \ system32 \ drivers \ etc \ hosts.sam
в % windir% \ system32 \ drivers \ etc \ hosts.
Откройте файл в своем любимом текстовом редакторе (например, в Блокноте), и вы увидите нечто очень похожее на:
# Copyright (c) 1993–1999 Microsoft Corp.#
# Это пример файла HOSTS, используемого Microsoft TCP / IP для Windows.
#
# Этот файл содержит сопоставления IP-адресов с именами хостов. Каждый
# запись должна храниться в отдельной строке. IP-адрес должен
# следует поместить в первый столбец, за которым следует соответствующее имя хоста.
# IP-адрес и имя хоста должны быть разделены хотя бы одним
# космос.
#
# Кроме того, комментарии (например, эти) могут быть добавлены к отдельным
# строк или после имени машины, обозначенного символом '#'.
#
# Например:
#
№ 102.54.94.97 rhino.acme.com # исходный сервер
# 38.25.63.10 x.acme.com # x клиентский хост
127.0.0.1 локальный
В конце файла hosts добавьте строку:
192.168.52.201 сам
Сохраните файл, и все готово.
[решено] Ping Показывает IP-адрес, отличный от того, что я пингую! — Сеть
Я пингую имя компьютера, он возвращается с ПРАВИЛЬНЫМ IP-адресом. 192.168.36.6
но если я пингую этот ip, он говорит, что целевой хост недоступен 192.168.36.16 ????
он говорит то же самое под именем компьютера, когда я пингую его в CMD …. почему он показывает неправильный IP ?? Серверы DNS верны в ipconfig / all ?? это проблема на моих DNS-серверах?
C: \ Users \ jseiler> пинг 532neffm
Пинг 532neffm.buffseminary.com [192.168.36.6] с 32 байтами данных:
Ответ от 192.168.36.16: Целевой хост недоступен.
C: \ Users \ jseiler> пинг 192.168.36.6
Пинг
C: \ Users \ jseiler> пинг 532neffm
Пинг 532neffm.buffseminary.com [192.168.36.6] с 32 байтами данных:
Ответ от 192.168.36.16: Целевой хост недоступен. 192.168.36.6 с 32 байтами данных:
Ответ от 192.168.36.16: Целевой хост недоступен.
Ответ от 192.168.36.16: Целевой хост недоступен.
C: \ Users \ jseiler> пинг 192.168.36.6
Пинг 192.168.36.6 с 32 байтами данных:
Ответ от 192.168.36.16: Целевой хост недоступен.
Ответ от 192.168.36.16: Целевой хост недоступен.
Сонора
OP
JJBorton 3 января 2011 г., 11:51 UTCЯ предполагаю, что машина, с которой вы запускаете ping, является машиной Vista или Windows 7, и что IP-адрес этой машины 192.168.36.16.
Ping под Windows 7 или Vista сообщит о недоступности IP-адреса таким образом, а не «нет ответа от», который вы, возможно, привыкли видеть.
rhel — ping: unknown host
rhel — ping: unknown host — Unix и Linux Stack ExchangeСеть обмена стеков
Сеть Stack Exchange состоит из 177 сообществ вопросов и ответов, включая Stack Overflow, крупнейшее и пользующееся наибольшим доверием онлайн-сообщество, где разработчики могут учиться, делиться своими знаниями и строить свою карьеру.
Посетить Stack Exchange- 0
- +0
- Авторизоваться Зарегистрироваться
Unix & Linux Stack Exchange — это сайт вопросов и ответов для пользователей Linux, FreeBSD и других Un * x-подобных операционных систем.Регистрация займет всего минуту.
Зарегистрируйтесь, чтобы присоединиться к этому сообществуКто угодно может задать вопрос
Кто угодно может ответить
Лучшие ответы голосуются и поднимаются наверх
Спросил
Просмотрено 14к раз
Я настраиваю рабочую станцию с RHEL 6.6. Когда я сделаю
ping server1
он сказал ping: unknown host server1
. Однако я могу пинговать
server1 с IP-адресом xx.xx.xx.xxx.
Мне кажется, /etc/resolv.conf
будет переписан NetworkManager.
Я добавляю их в свой / etc / sysconfig / network-scripts / ifcfg-eth0
:
DNS1 = xx.xx.xx.xxx
DNS2 = xx.xx.xx.xxx
ДОМЕН = xxx.xxx.xx
Есть предложения, что могло пойти не так?
роаима75.2k1111 золотых знаков9797 серебряных знаков189189 бронзовых знаков
Создан 09 июн.
пользователь1186871111 золотой знак11 серебряный знак22 бронзовых знака
1— это server1, заполнитель для Интернет-сайта, например, www.google.com? Или это машина, которой вы управляете в своей локальной сети?
Если это ваша собственная машина, ваш DNS, вероятно, не знает об этом. Вы можете решить эту проблему, добавив строку в файл hosts.
Если это локальный компьютер, ваши варианты:
добавьте его в файл hosts каждой машины (они также доступны на хостах Windows и OSX) — самый простой, но трудоемкий
имеют IP-адреса компьютеров, переданные (возможно, по MAC-идентификатору) через DHCP-сервер, который также обрабатывает DNS и будет обслуживать эти имена — это маловероятно.Это зависит от вашего DHCP-сервера, но, например, прошивка DD-WRT может это сделать.
запустите свой собственный DNS-сервер (возможно, используя DNS-кеш) и определите IP-адреса ваших серверов в конфигурации
Пример настройки DNS кеша на сервере Ubuntu здесь, не уверен для Red Hat EL.
https://help.ubuntu.com/lts/serverguide/dns-configuration.html
Антон72.3k4141 золотой знак141141 серебряный знак208208 бронзовых знаков
Создан 09 июн.
Оливер Оливер14122 бронзовых знака
Создайте эту запись в файле / etc / hosts:
ххх.xxx.xxx.xxx server1
, где xxx.xxx.xxx.xxx — это IP-адрес server1.
Также, если server1 имеет общедоступный DNS, убедитесь, что ваш /etc/resolv.conf указывает на 8.8.8.8 и 4.2.2.2:
кот /etc/resolv.conf:
сервер имен 8.8.8.8
сервер имен 4.2.2.2
Если вы не знаете публичное разрешение server1, найдите частное разрешение server1 в своей сети. Если нет частного или общедоступного разрешения, server1 существует только в вашем воображении, но вы все равно можете использовать файл / etc / hosts, чтобы сделать его реальным для вашей локальной машины.
Создан 09 июн.
Баазигар66233 серебряных знака99 бронзовых знаков
Не тот ответ, который вы ищете? Посмотрите другие вопросы с метками rhel или задайте свой вопрос.
Unix и Linux Stack Exchange лучше всего работает с включенным JavaScriptВаша конфиденциальность
Нажимая «Принять все файлы cookie», вы соглашаетесь с тем, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Принимать все файлы cookie Настроить параметры
Сеть— «ping: unknown host google.com», но IP-адреса работают нормально
На этот вопрос уже есть ответы :
Закрыт 3 года назад.
Недавно я обновился с Ubuntu 12.04 до Ubuntu 14.04. После перезапуска у меня подключен Wi-Fi и / или подключение к локальной сети без доступа в Интернет. Я использую Toshiba Satellite C855D.
$ sudo lshw -C сеть
*-сеть
описание: Беспроводной интерфейс
продукт: Wi-Fi адаптер RTL8188CE 802.11b / g / n
поставщик: Realtek Semiconductor Co., Ltd.
физический идентификатор: 0
информация об автобусе: pci @ 0000: 02: 00.0
логическое имя: wlan0
версия: 01
серийный: c0: d9: 62: 8d: 39: 85
ширина: 64 бита
часы: 33 МГц
возможности: pm msi pciexpress bus_master cap_list ethernet физический беспроводной
конфигурация: broadcast = yes driver = rtl8192ce driverversion = 3.13.0-24-generic firmware = N / A ip = 192.168.0.109 latency = 0 link = yes multicast = yes wireless = IEEE 802.11bgn
ресурсы: irq: 16 ioport: 3000 (размер = 256) память: f0200000-f0203fff
*-сеть
описание: интерфейс Ethernet
продукт: RTL8101E / RTL8102E PCI Express Fast Ethernet контроллер
поставщик: Realtek Semiconductor Co., Ltd.
физический идентификатор: 0
информация об автобусе: pci @ 0000: 06: 00.0
логическое имя: eth0
версия: 05
серийный: 00: 8c: fa: 49: e0: 4d
размер: 10 Мбит / с
емкость: 100 Мбит / с
ширина: 64 бита
часы: 33 МГц
возможности: pm msi pciexpress msix vpd bus_master cap_list физический ethernet tp mii 10bt 10bt-fd 100bt 100bt-fd автосогласование
конфигурация: автосогласование = при трансляции = да драйвер = r8169 версия драйвера = 2.3LK-NAPI duplex = половина прошивки = rtl_nic / rtl8105e-1.fw latency = 0 link = no multicast = yes port = MII speed = 10Mbit / s
ресурсы: irq: 41 ioport: 2000 (размер = 256) память: f0104000-f0104fff память: f0100000-f0103fff
$ ifconfig -a
eth0 Link encap: Ethernet HWaddr 00: 8c: fa: 49: e0: 4d
ВВЕРХ ТРАНСЛЯЦИИ МУЛЬТИКАСТ MTU: 1500 Метрическая система: 1
Пакеты RX: 0 ошибок: 0 отброшено: 0 переполнений: 0 кадров: 0
Пакеты TX: 0 ошибок: 0 отброшено: 0 переполнений: 0 носитель: 0
коллизии: 0 txqueuelen: 1000
Байт RX: 0 (0.0 B) Байты TX: 0 (0,0 B)
lo Link encap: Локальный шлейф
inet адрес: 127.0.0.1 Маска: 255.0.0.0
inet6 адрес: :: 1/128 Область: Хост
ВЫПОЛНЕНИЕ ЗАПИСИ ВВЕРХ MTU: 65536 Метрическая система: 1
Пакеты RX: 727 ошибок: 0 отброшено: 0 переполнений: 0 кадров: 0
Пакеты TX: 727 ошибок: 0 сброшено: 0 переполнений: 0 несущая: 0
коллизии: 0 txqueuelen: 0
Байт приема: 56993 (56,9 КБ) байтов передачи: 56993 (56,9 КБ)
wlan0 Link encap: Ethernet HWaddr c0: d9: 62: 8d: 39: 85
inet адрес: 192.168.0.109 Bcast: 192.168.0.255 Маска: 255.255.255.0
inet6 адрес: fe80 :: c2d9: 62ff: fe8d: 3985/64 Объем: Ссылка
ВВЕРХ ТРАНСЛЯЦИИ МУЛЬТИКАЛТА MTU: 1500 Метрическая система: 1
RX пакетов: 1934 ошибок: 0 отброшено: 0 переполнений: 0 кадров: 0
Пакеты TX: 61 ошибка: 0 сброшено: 0 переполнено: 0 несущая: 0
коллизии: 0 txqueuelen: 1000
$ пинг 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56 (84) байтов данных.
64 байта из 8.8.8.8: icmp_seq = 1 ttl = 47 time = 47,2 мс
64 байта из 8.8.8.8: icmp_seq = 2 ttl = 47 время = 44,8 мс
64 байта из 8.8.8.8: icmp_seq = 3 ttl = 47 time = 43,6 мс
64 байта из 8.8.8.8: icmp_seq = 4 ttl = 47 time = 156 мс
$ пинг google.com
ping: неизвестный хост google.com
$ nslookup google.com 8.8.8.8
Сервер: 8.8.8.8
Адрес: 8.8.8.8 # 53
Неавторитетный ответ:
Имя: google.com
Адрес: 190.167.241.187
Имя: google.com
Адрес: 190.167.241.178
Имя: google.com
Адрес: 190.167.241,163
Имя: google.com
Адрес: 190.167.241.183
Имя: google.com
Адрес: 190.167.241.177
Имя: google.com
Адрес: 190.167.241.172
Имя: google.com
Адрес: 190.167.241.153
Имя: google.com
Адрес: 190.167.241.162
Имя: google.com
Адрес: 190.167.241.167
Имя: google.com
Адрес: 190.167.241.152
Имя: google.com
Адрес: 190.167.241.168
Имя: google.com
Адрес: 190.167.241.182
Имя: google.com
Адрес: 190.167.241.157
Имя: google.com
Адрес: 190.167.241.173
Имя: google.com
Адрес: 190.167.241.148
Имя: google.com
Адрес: 190.167.241.158
$ cat /etc/resolvconf/resolv.conf.d/head
# Динамический файл resolv.conf (5) для преобразователя glibc (3), созданный resolvconf (8)
# НЕ РЕДАКТИРУЙТЕ ЭТОТ ФАЙЛ ВРУЧНУЮ - ВАШИ ИЗМЕНЕНИЯ БУДУТ ПЕРЕЗАПИСАНЫ
сервер имен 8.8.8.8
$ перезапуск сети службы sudo
стоп: задание не выполнено при остановке
начало: задание уже выполняется: сеть
$ нм-инструмент
Инструмент NetworkManager
Состояние: подключено (глобальное)
- Устройство: eth0 ---------------------------------------------- -------------------
Тип: проводной
Драйвер: r8169
Состояние: недоступен
По умолчанию: нет
Аппаратный адрес: 00: 8C: FA: 49: E0: 4D
Возможности:
Обнаружение несущей: да
Скорость: 100 Мб / с
Проводные свойства
Перевозчик: выключен
- Устройство: wlan0 [Honey Nut Cheerios] ----------------------------------------- -
Тип: 802.11 Wi-Fi
Драйвер: rtl8192ce
Состояние: подключено
По умолчанию: да
Аппаратный адрес: C0: D9: 62: 8D: 39: 85
Возможности:
Скорость: 18 Мб / с
Беспроводные свойства
Шифрование WEP: да
Шифрование WPA: да
Шифрование WPA2: да
Точки беспроводного доступа (* = текущая точка доступа)
* Honey Nut Cheerios: Infra, 00: 21: 29: EF: 11: 2D, частота 2437 МГц, скорость 54 Мбит / с, мощность 78 WPA2
Claro8AD: Infra, 00: 1A: 2B: B0: 69: CD, частота 2462 МГц, скорость 54 Мбит / с, мощность 27 WPA2
CLAROB5F570: Инфра, 88: 25: 2C: B5: F5: 70, частота 2412 МГц, скорость 54 Мбит / с, мощность 20 WEP
WIND30: Инфра, 00: 1F: FB: 68: E3: 6C, частота 2427 МГц, скорость 54 Мбит / с, мощность 37 WPA
dd-wrt_vap: Infra, 02: 1C: 10: 34: 41: 15, частота 2437 МГц, скорость 54 Мбит / с, мощность 24 WPA
Настройки IPv4:
Адрес: 192.168.0.109
Префикс: 24 (255.255.255.0)
Шлюз: 192.168.0.1
DNS: 8.8.8.8
DNS: 8.8.4.4
Как устранить сбой эхо-запроса или потерю пакетов с помощью теста связи? _Эластический облачный сервер_Устранение неполадок_Общие проблемы_HUAWEI CLOUD
Признак
При доступе к другим ресурсам из ECS произошло зависание сети. Выходные данные команды ping показали, что произошла потеря пакета или сетевая задержка была большой.
В этом разделе в качестве примера используются Tracert и MTR, чтобы описать, как устранить потерю пакетов или длительную задержку.
Возможные причины
Потеря пакета или длительная задержка могут быть вызваны перегрузкой канала, сбоями узла канала, высокой нагрузкой на сервер или неправильными настройками системы.
Убедившись, что проблема не вызвана ECS, используйте Tracert или MTR для дальнейшего поиска неисправности.
MTR используется для обнаружения сетевых неисправностей.
Вы можете выбрать использование Tracert или MTR в зависимости от ОС ECS:Использование Tracert в Windows
Tracert показывает путь, по которому пакеты достигают целевого сервера, и время, когда пакеты достигают каждого узла.Tracert предлагает те же функции, что и команда ping, но предоставляет более подробную информацию, включая полный путь, по которому проходят пакеты, IP-адрес каждого сквозного узла и время прибытия пакетов на каждый узел.
- Войдите в Windows ECS.
- Откройте окно cmd и выполните следующую команду для отслеживания IP-адреса:
tracert IP-адрес или веб-сайт
Например, tracert www.example.com
Выходные данные команды показывают, что:
- Максимальное количество прыжков по умолчанию — 30. Первый столбец показывает порядковый номер каждого перехода.
- Tracert каждый раз отправляет три пакета. Второй, третий и четвертый столбцы показывают время, за которое три пакета достигают места назначения. В последнем столбце показаны IP-адреса узлов, на которые были перенаправлены пакеты.
- Если сообщение * * * истекло время ожидания запроса , устраните неполадки в затронутом канале и узле.
Использование WinMTR в Windows
- Войдите в Windows ECS.
- Загрузите установочный пакет WinMTR с официального сайта.
- Распакуйте установочный пакет WinMTR.
- Дважды щелкните WinMTR.exe , чтобы запустить инструмент.
- В окне WinMTR введите IP-адрес или доменное имя целевого сервера в Host и щелкните Start .
- Подождите, пока WinMTR запустится в течение определенного периода времени, и щелкните Stop , чтобы остановить тест.
Результаты испытаний следующие:
- Имя хоста : IP-адрес или доменное имя каждого узла, через который пакеты проходят к серверу назначения
- Nr : количество узлов, через которые проходят пакеты
- Потеря% : коэффициент потери пакетов узла
- Отправлено : количество отправленных пакетов
- Recv : количество полученных ответов
- Лучшее : самое короткое время отклика
- Avrg : среднее время отклика
- Наихудшее
010: максимальное время отклика 9
901 Последний : время последнего ответа
Использование MTR в Linux
Установка MTR
MTR установлен во всех дистрибутивах Linux.Если MTR не установлен на вашей Linux ECS, выполните следующую команду, чтобы установить его:
- Ubuntu
sudo apt-get install mtr
Параметры MTR
- -h / — help : меню справки
- -v / — version : MTR version
- -r / — report : результаты всех трассировок
- -p / — split : результаты каждой трассировки
- -c / — report-cycle : количество пакетов ( 10 по умолчанию), отправляемых в секунду
- -s / — psize : размер пакета
- -n / — no-dns : разрешение доменного имени не выполняется для IP-адресов
- -a / — address : IP-адрес для отправки пакетов, который устанавливается, если один хост имеет несколько IP-адресов
- — 4 : IPv4
- -6 : IPv6
Далее используется связь между локальным сервером и целевым сервером с IP-адресом 119.xx.xx.xx в качестве примера.
Выполните следующую команду, чтобы получить результаты диагностики MTR в виде отчета:
mtr 119.xx.xx.xx — отчет
Отображается информация, подобная следующей:
[root @ ecs-0609 ~] # mtr 119.xx.xx.xx --report Старт: 22 авг, чт, 15:41:22 2019 ВЕДУЩИЙ: ecs-652 Loss% Snt Last Avg Best Wrst StDev 1. | - 100.70.0.1 0,0% 10 3,0 3,4 2,8 7,5 1,3 2. | - 10.242.7.174 0.0% 10 52,4 51,5 34,2 58,9 6,3 3. | - 10.242.7.237 0,0% 10 3,2 5,0 2,7 20,8 5,5 4. | - 10.230.2.146 0,0% 10 1,0 1,0 1,0 1,1 0,0 5. | - 192.168.21.1 0,0% 10 3,5 4,2 2,8 11,6 2,5 6. | - 10.242.7.238 0,0% 10 35,3 34,5 6,0 56,4 22,6 7. | - 10.242.7.173 0,0% 10 3,3 4,7 3,1 14,7 3,6 8. | - ??? 100,0 10 0,0 0,0 0,0 0,0 0,0
Параметры в выходных данных предыдущей команды описаны следующим образом:
- HOST : IP-адрес или доменное имя узла
- Loss% : коэффициент потери пакетов
- Snt : количество пакетов, отправленных в секунду
- Last : время последнего ответа
- Avg : среднее время отклика
- Лучшее : самое короткое время отклика
- Wrst : максимальное время отклика
- StDev : стандартное отклонение, большее значение указывает на большую разницу между временем отклика для каждого пакета данных на узле
Обработка отчетов WinMTR и MTR
На следующем рисунке показан пример анализа отчетов WinMTR и MTR.
- Локальная сеть сервера (область A): локальная сеть и локальная сеть провайдера
- Если какой-либо узел в локальной сети неисправен, проверьте локальную сеть.
- Если локальный интернет-провайдер неисправен, сообщите о проблеме местному оператору связи.
- Магистральная сеть оператора связи (область B): если в этой области возникает ошибка, определите оператора связи, которому принадлежит неисправный узел, на основе IP-адреса узла и сообщите о проблеме оператору связи.
- Локальная сеть на стороне назначения (область C): сеть провайдера, которому принадлежит сервер назначения.
- Если на сервере назначения происходит потеря пакетов, конфигурация сети сервера назначения может быть неправильной. Проверьте конфигурацию брандмауэра на конечном сервере.
- Если потеря пакета происходит на определенных узлах с несколькими переходами рядом с целевым сервером, сеть провайдера, которому принадлежит целевой сервер, может быть неисправной.
Общие сбои канала
- Неправильная конфигурация целевого сервера Как показано в следующем примере, если уровень потери пакетов составляет 100%, пакеты не принимаются целевым сервером. Неисправность может быть вызвана неправильной конфигурацией сети на конечном сервере. В таком случае проверьте конфигурацию брандмауэра на конечном сервере.
Host Loss% Snt Last Avg Best Wrst StDev 1.??? 2. ??? 3. 1XX.X.X.X 0,0% 10 521,3 90,1 2,7 521,3 211,3 4. 11X.X.X.X 0,0% 10 2,9 4,7 1,6 10,6 3,9 5. 2X.X.X.X 80,0% 10 3,0 3,0 3,0 3,0 0,0 6. 2X.XX.XX.XX 0,0% 10 1,7 7,2 1,6 34,9 13,6 7. 1XX.1XX.XX.X 0,0% 10 5,2 5,2 5,1 5,2 0,0 8. 2XX.XX.XX.XX 0,0% 10 5.3 5,2 5,1 5,3 0,1 9. 1XX.1XX.XX.X 100,0% 10 0,0 0,0 0,0 0,0 0,0
- Ограничение скорости ICMP Как показано в следующем примере, потеря пакетов происходит на пятом переходе, но проблема не сохраняется на последующих узлах. Следовательно, определяется, что неисправность вызвана ограничением скорости ICMP на пятом узле. Эта проблема не влияет на передачу данных на целевой сервер. Поэтому игнорируйте эту проблему.
Host Loss% Snt Last Avg Best Wrst StDev 1.1XX.XX.XX.XX 0,0% 10 0,3 0,6 0,3 1,2 0,3 2. 1XX.XX.XX.XX 0,0% 10 0,4 1,0 0,4 6,1 1,8 3. 1XX.XX.XX.XX 0,0% 10 0,8 2,7 0,8 19,0 5,7 4. 1XX.XX.XX.XX 0,0% 10 6,7 6,8 6,7 6,9 0,1 5. 1XX.XX.XX.XX 0,0% 10 27,2 25,3 23,1 26,4 2,9 6. 1XX.XX.XX.XX 0,0% 10 39,1 39,4 39.1 39,7 0,2 7. 1XX.XX.XX.XX 0,0% 10 39,6 40,4 39,4 46,9 2,3 8. 1XX.XX.XX.XX 0,0% 10 39,6 40,5 39,5 46,7 2,2
- Цикл Как показано в следующем примере, пакеты данных циклически передаются после пятого перехода, и они не могут достичь сервера назначения. Эта ошибка вызвана неправильной конфигурацией маршрутизации на узлах оператора связи. Обратитесь к перевозчику для устранения неисправности.
Host Loss% Snt Last Avg Best Wrst StDev 1.1XX.XX.XX.XX 0,0% 10 0,3 0,6 0,3 1,2 0,3 2. 1XX.XX.XX.XX 0,0% 10 0,4 1,0 0,4 6,1 1,8 3. 1XX.XX.XX.XX 0,0% 10 0,8 2,7 0,8 19,0 5,7 4. 1XX.XX.XX.XX 0,0% 10 6,7 6,8 6,7 6,9 0,1 5. 1XX.XX.XX.65 0,0% 10 0,0 0,0 0,0 0,0 0,0 6. 1XX.XX.XX.65 0,0% 10 0,0 0.0 0,0 0,0 0,0 7. 1XX.XX.XX.65 0,0% 10 0,0 0,0 0,0 0,0 0,0 8. 1XX.XX.XX.65 0,0% 10 0,0 0,0 0,0 0,0 0,0 9. ??? 0,0% 10 0,0 0,0 0,0 0,0 0,0
- Прерывание связи Как показано в следующем примере, после передачи пакетов данных на четвертый переход не может быть получен ответ. Обычно это вызвано прерыванием связи между затронутыми узлами.Рекомендуется выполнить дополнительную проверку с помощью теста обратной связи. В таком случае обратитесь к оператору связи, которому принадлежат затронутые узлы.
Host Loss% Snt Last Avg Best Wrst StDev 1. 1XX.XX.XX.XX 0,0% 10 0,3 0,6 0,3 1,2 0,3 2. 1XX.XX.XX.XX 0,0% 10 0,4 1,0 0,4 6,1 1,8 3. 1XX.XX.XX.XX 0,0% 10 0,8 2,7 0,8 19,0 5,7 4. 1XX.XX.XX.XX 0.0% 10 6,7 6,8 6,7 6,9 0,1 5. 1XX.XX.XX.XX 0,0% 10 0,0 0,0 0,0 0,0 0,0 6. 1XX.XX.XX.XX 0,0% 10 0,0 0,0 0,0 0,0 0,0 7. 1XX.XX.XX.XX 0,0% 10 0,0 0,0 0,0 0,0 0,0 8. 1XX.XX.XX.XX 0,0% 10 0,0 0,0 0,0 0,0 0,0 9 1XX.XX.XX.XX 0,0% 10 0,0 0.0 0,0 0,0 0,0
Устранение неполадок сетевого подключения
Для тестирования и устранения неполадок в сети вы можете использовать инструменты, доступные на вашем клиентском компьютере и в Firebox. Для тестов, которые включают команды, выдаваемые с клиентского компьютера Windows, используйте компьютер в доверенной, дополнительной или настраиваемой сети, подключенной к Firebox.
Средства устранения неполадок сети
Используйте эти инструменты и методы для проверки возможности подключения к сети и разрешения имени хоста в вашей сети.Эти методы тестирования упоминаются в шагах по устранению неполадок в следующих разделах.
Проверьте связь с хостом с вашего компьютера с Windows- Найдите текстовое поле поиска на панели задач Windows или в меню «Пуск».
- В текстовом поле поиска введите cmd и нажмите Введите .
Откроется окно командной строки. - В командной строке введите ping [ IP-адрес назначения или имя хоста ] и нажмите Введите .
Вы можете использовать диагностическую задачу Ping для отправки пакетов ping из Firebox на IP-адрес или имя хоста.
Чтобы отправить эхо-запрос из Firebox в веб-интерфейсе Fireware:- Выберите Состояние системы> Диагностика .
Откроется страница «Диагностика» с выбранной вкладкой «Файл диагностики». - Выберите вкладку Сеть .
Откроется страница сети. - В раскрывающемся списке Task выберите команду Ping .
Появится текстовое поле «Адрес». - В текстовом поле Адрес введите IP-адрес или имя хоста.
- Щелкните Выполнить задачу .
Выходные данные команды появятся на панели результатов. - Чтобы остановить команду Ping, нажмите Остановить задачу .
Для получения дополнительной информации о задачах диагностики в веб-интерфейсе Fireware см. Запуск задач диагностики на Firebox.
Просматривайте сообщения журнала для разрешенных подключенийПо умолчанию Firebox не создает сообщения журнала для подключений, которые разрешены политиками фильтрации пакетов, такими как политика Ping.Во время устранения проблем с сетевым подключением может быть полезно включить регистрацию разрешенных пакетов для такой политики, как Ping.
Используйте эти шаги для редактирования параметров ведения журнала в политике, чтобы Firebox создавал сообщения журнала для подключений, разрешенных политикой.
Чтобы включить регистрацию в политике, в веб-интерфейсе Fireware:- Выберите Брандмауэр> Политики брандмауэра .
Откроется страница Политики. - Щелкните имя политики, которую нужно изменить.
Откроется страница Политики брандмауэра> Изменить. - В разделе Ведение журнала установите флажок Отправить сообщение журнала .
- Нажмите Сохранить , чтобы сохранить изменение конфигурации.
- Дважды щелкните политику, чтобы изменить ее.
Откроется диалоговое окно «Изменить свойства политики». - Выберите вкладку Свойства .
- Нажмите Ведение журнала .
- Установите флажок Отправить сообщение журнала .
- Сохраните конфигурацию в Firebox.
После того, как вы сделаете это изменение, Firebox создает сообщения журнала для подключений, разрешенных политикой.В Traffic Monitor вы можете фильтровать сообщения журнала, чтобы просмотреть сообщения журнала, созданные для подключений, разрешенных определенной политикой, или для подключений к определенному IP-адресу или с него.
Чтобы просмотреть и отфильтровать сообщения журнала в веб-интерфейсе Fireware:- Выберите Панель мониторинга> Монитор трафика .
- В текстовом поле фильтра вверху страницы введите термин для поиска только тех сообщений журнала, которые содержат этот термин.Например, это может быть IP-адрес компьютера в вашей сети, имя пользователя или имя политики, для которой вы включили ведение журнала.
- Чтобы удалить фильтр, щелкните.
Чтобы узнать больше о панели мониторинга Traffic Monitor, см. Traffic Monitor.
Чтобы просмотреть и отфильтровать сообщения журнала в Firebox System Manager:- Выберите вкладку Traffic Monitor .
- В текстовом поле фильтра вверху страницы введите термин для поиска только тех сообщений журнала, которые содержат этот термин. Например, это может быть IP-адрес компьютера в вашей сети, имя пользователя или имя политики, для которой вы включили ведение журнала.
- Чтобы удалить фильтр, щелкните.
Чтобы узнать больше о Traffic Monitor в Firebox System Manager, см. Сообщения журнала устройства (Traffic Monitor).
Чтобы узнать больше о том, как читать сообщение журнала, см. Чтение сообщения журнала.
Используйте команду ipconfig, чтобы увидеть конфигурацию сети на компьютере с Windows.- Найдите текстовое поле поиска на панели задач Windows или в меню «Пуск».
- В текстовом поле поиска введите cmd и нажмите Введите .
Откроется окно командной строки. - Чтобы увидеть назначенный IP-адрес, маску подсети и шлюз по умолчанию, в командной строке введите ipconfig и нажмите Введите .
- Чтобы просмотреть дополнительную информацию, включая IP-адреса DNS-сервера, введите ipconfig / all и нажмите Введите .
Устранение неполадок исходящих подключений
Чтобы определить причину проблем с подключением к Интернету с компьютеров в вашей локальной сети, начните с проверки связи с локального компьютера в вашей сети до Firebox или локального сервера в вашей сети. В случае успеха следующим шагом будет проверка маршрутизации и разрешения DNS для хостов за пределами вашей локальной сети.Используйте инструкции в предыдущем разделе, чтобы запустить диагностические команды, используемые в этих тестах, и просмотреть сообщения журнала.
Тест 1 — эхо-запрос внутреннего IP-адреса
С локального компьютера попробуйте выполнить эхо-запрос других внутренних IP-адресов в той же локальной сети. Например, попробуйте проверить связь с локальным сетевым сервером или IP-адресом внутреннего интерфейса Firebox. Чтобы запустить эхо-запрос с компьютера Windows, следуйте инструкциям в предыдущем разделе.
Если вы не можете пропинговать внутренний IP-адрес Firebox, это может указывать на проблему с конфигурацией Firebox или на проблему с конфигурацией вашей локальной сети или кабелями. Чтобы увидеть IP-адрес и шлюз по умолчанию в конфигурации локальной сети на клиентском компьютере, из командной строки Windows используйте команду ipconfig.
Посмотрите на выходные данные команды ipconfig и рассмотрите следующие возможные причины сбоя проверки связи:
Проблема с конфигурацией сети на вашем локальном компьютереВ выходных данных команды ipconfig на клиентском компьютере найдите IPv4-адрес, назначенный локальному компьютеру, и IP-адрес шлюза по умолчанию.Клиентский компьютер должен иметь адрес IPv4. В большинстве случаев шлюз по умолчанию должен быть IP-адресом внутреннего интерфейса Firebox, к которому подключается локальная сеть.
DHCP не включен или неправильно настроен на FireboxЕсли клиентский компьютер использует DHCP для получения IP-адреса, а вывод ipconfig показывает, что IP-адрес не назначен, проверьте конфигурацию интерфейса Firebox, к которому подключается локальная сеть.Убедитесь, что DHCP-сервер включен и что пул адресов DHCP, настроенный для интерфейса Firebox, содержит достаточно IP-адресов для назначения адресов всем подключающимся клиентам.
В сети есть мошеннический DHCP-серверЕсли клиентский компьютер использует DHCP для получения IP-адреса, а IP-адрес и шлюз, назначенные на клиенте, не соответствуют настройкам DHCP-сервера, настроенным на интерфейсе Firebox, к которому эта сеть подключается, возможно, что включен мошеннический DHCP-сервер. вашей сети и назначил неожиданный IP-адрес.
Проблема с внутренней маршрутизацией вашей сети.Если между клиентским компьютером и внутренним интерфейсом Firebox есть коммутатор или маршрутизатор, проблема может быть в конфигурации коммутатора или маршрутизатора. Чтобы проверить, является ли проблема коммутатором или маршрутизатором, подключите клиентский компьютер напрямую к внутреннему интерфейсу Firebox, а затем попробуйте снова пропинговать Firebox.
Сбой физического интерфейса или кабеляПроблемы с сетевым подключением могут быть вызваны повреждением или отсоединением кабеля либо отказом сетевого интерфейса на компьютере, Firebox или любом подключенном коммутаторе или маршрутизаторе. Чтобы обнаружить этот тип проблемы, посмотрите на индикаторы соединения и активности на сетевом интерфейсе на каждом конце каждого кабеля, попробуйте другой сетевой кабель или попробуйте a, чтобы проверить соединение с Firebox с другого компьютера в том же сегменте сети. .
Для получения информации об индикаторах на интерфейсах Firebox см. Руководство по оборудованию для вашей модели Firebox.
Внутренний IP-адрес Firebox перекрывается с другим хостом в вашей сети.Если проблема затрагивает всех или многих пользователей в вашей сети, возможно, существует конфликт IP-адресов между внутренним IP-адресом Firebox и другим устройством в вашей сети.Чтобы проверить это, отсоедините кабель от интерфейса Firebox, а затем попробуйте пропинговать внутренний интерфейс Firebox с клиентского компьютера. Если ping получает ответ, когда сеть не подключена к интерфейсу Firebox, какой-то другой хост в сети использует IP-адрес, который конфликтует с IP-адресом интерфейса Firebox.
Тест 2 — эхо-запрос шлюза по умолчанию для Firebox
Если вы можете успешно пропинговать IP-адрес интерфейса Firebox, проверьте, может ли трафик с клиентского компьютера маршрутизироваться на адреса за пределами Firebox.Чтобы проверить это, с вашего компьютера с Windows попытайтесь проверить связь со шлюзом по умолчанию для внешнего интерфейса Firebox. Это подтвердит, что ваш компьютер может выполнять маршрутизацию к хосту за пределами Firebox, и что ваш Firebox настроен на разрешение этих запросов ping.
Вы можете увидеть IP-адрес внешнего шлюза Firebox по умолчанию в WatchGuard System Manager или на панели управления интерфейсом в веб-интерфейсе Fireware.
Если в вашей сети есть Интернет-шлюз, отличный от Firebox, интернет-трафик от клиентов в вашей сети может не проходить через Firebox. Чтобы убедиться, что исходящий трафик в Интернет проходит через Firebox, включите регистрацию разрешенных пакетов в политике проверки связи и убедитесь, что сообщения журнала создаются для запросов проверки связи из вашей сети. Дополнительные сведения о том, как это сделать, см. В предыдущем разделе Средства устранения неполадок сети .
Если ваш эхо-запрос к шлюзу по умолчанию внешнего интерфейса Firebox не работает, проверьте одну из следующих причин:
Неправильная конфигурация динамического NAT на FireboxЕсли ваша локальная сеть не использует одну из частных подсетей RFC 1918, правила динамического NAT по умолчанию не маскируют трафик из вашей частной сети в Интернет.Чтобы узнать, может ли это быть проблемой, просмотрите сообщения журнала для ваших запросов ping. Убедитесь, что атрибут src_ip_nat отображается и указанный IP-адрес совпадает с внешним IP-адресом Firebox.
Если ваш Firebox настроен для режима Drop-in или Bridge, атрибут src_ip_nat не появляется в сообщениях журнала для исходящего трафика.
Дополнительные сведения о динамическом NAT и правилах динамического NAT по умолчанию см. В разделе «О динамическом NAT».
Ваш компьютер не может маршрутизировать внешние хосты через Firebox.Чтобы проверить, так ли это, подключите компьютер напрямую к Firebox, чтобы обойти внутреннюю сеть. Убедитесь, что ваш клиентский компьютер имеет IP-адрес в правильной подсети для подключения к Firebox, и что шлюз по умолчанию установлен на IP-адрес интерфейса Firebox, к которому подключается локальная сеть.
Тест 3 — Проверка разрешения DNS
Если вы можете успешно пропинговать шлюз по умолчанию вашего Firebox, следующим шагом будет проверка разрешения DNS. Чтобы проверить разрешение DNS, попробуйте проверить связь с удаленным веб-хостом, например www.watchguard.com. Если это не удается, попробуйте проверить связь с удаленным IP-адресом, например DNS-сервером вашего интернет-провайдера, или общедоступным DNS-сервером, например 8.8.8.8 или 4.2.2.2. Если вы можете успешно проверить связь с удаленным IP-адресом, но не можете проверить связь с именем хоста, это указывает на проблему с разрешением DNS.
Если разрешение DNS не удается, изучите следующие возможные причины:
IP-адрес DNS-сервера по умолчанию, используемый клиентом, недействителен или не отвечает.Используйте командную строку Windows на своем клиентском компьютере для проверки разрешения DNS.Если вы не укажете IP-адрес DNS-сервера, команда nslookup использует DNS-сервер по умолчанию.
Сначала проверьте DNS с DNS-сервером по умолчанию:
nslookup www.watchguard.com
Затем добавьте IP-адрес к общедоступному DNS-серверу:
nslookup www.watchguard.com 8.8.8.8
Если разрешение DNS не работает с DNS-сервером по умолчанию, но работает с общедоступным DNS-сервером, проверьте DNS-серверы, используемые клиентским компьютером и Firebox.
- Чтобы увидеть DNS-сервер по умолчанию, используемый на клиентском компьютере, используйте команду ipconfig / all в командной строке Windows. DNS-сервер на клиенте обычно должен быть таким же, как DNS-сервер, используемый Firebox.
- Чтобы увидеть текущие IP-адреса DNS-сервера для Firebox в веб-интерфейсе Fireware, выберите Dashboard> Interfaces> Detail . Чтобы увидеть DNS-серверы в Firebox System Manager, разверните Interfaces status для Firebox на вкладке Front Panel .
Чтобы проверить, может ли трафик перенаправляться на DNS-сервер и отвечает ли DNS-сервер, вы можете попытаться пропинговать IP-адрес DNS-сервера с клиентского компьютера и из Firebox.
Ваш Firebox не разрешает исходящие DNS-запросы.Если вы можете успешно пропинговать DNS-сервер с клиентского компьютера в вашей сети, разрешение DNS не удастся, если в конфигурации Firebox нет политики, разрешающей исходящие DNS-запросы.
Для дальнейшего устранения этой проблемы вы можете протестировать разрешение DNS из Firebox, как описано выше, чтобы увидеть, работает ли разрешение DNS из Firebox.Если разрешение DNS работает из Firebox, но не работает от клиентов во внутренней сети, вполне вероятно, что в Firebox нет политики, разрешающей исходящие запросы DNS. Чтобы узнать, так ли это, изучите сообщения журнала в Traffic Monitor, пока вы тестируете DNS или пытаетесь разрешить имена внешних хостов. Ищите сообщения журнала для запрещенных подключений с портом назначения 53.
Если вы отключите или удалите политику Outgoing по умолчанию, Firebox не разрешит исходящие DNS-запросы, если вы не добавите другую политику, разрешающую эти подключения.Если вы удаляете исходящую политику, убедитесь, что другие ваши политики разрешают узлам в вашей сети или, по крайней мере, ключевым серверам подключаться к исходящим сообщениям для DNS, NTP и других необходимых функций.
Для получения дополнительных сведений о политике исходящих сообщений см. Раздел «О политике исходящих сообщений».
См. Также
Маршруты и маршрутизация
О Multi-WAN
.