Пингование неизвестного ip: PING — сетевая диагностика на IP-уровне

Содержание

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 число — Запись маршрута для указанного числа переходов.

-s число — Штамп времени для указанного числа переходов.
-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 5000 -l 1000 ab57.ru — опрос узла ab57.ru 5000 раз, пакетами с данными длиной в 1000байт. Допустимая максимальная длина данных — 65500.

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) при передаче пакета.”

  • Применение PING для пошаговой диагностики проблем доступа в Интернет:
  • Обобщенная схема соединения компьютера (планшета, ноутбука домашней сети) с удаленным конечным узлом можно представить следующим образом:

    В качестве домашней сети используется наиболее распространенная сеть с 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-адресов, принадлежащих локальной сети. Устройства с такими адресами достижимы локально, без использования
    маршрутизации
    . Маршрутизация — это способ обмена данными с сетевыми устройствами не принадлежащими к данной локальной сети через специальное устройство — маршрутизатор ( router, роутер ). Маршрутизаторы представляют собой специализированные компьютеры с несколькими сетевыми интерфейсами и специализированным программным обеспечением обеспечивающим пересылку 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 ->

    195.34.52.213 ->
    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-адрес. Примером скрытого адаптера является виртуальный адаптер кластера неудачной работы Майкрософт.

    Изменение порядка привязки

    Чтобы изменить порядок привязки, выполните следующие действия:

    1. Нажмите кнопку Начните, а затем нажмите панель управления.

    2. Щелкните Сеть и Интернет, а затем нажмите кнопку Network and Sharing Center.

    3. Изменение параметров сетевого адаптера в зависимости от операционной системы:

      • Для Windows Server 2008 нажмите кнопку Управление настройками адаптеров.

      • Для Windows Server 2008 R2 нажмите параметры адаптер изменить.

    4. Нажмите кнопку Упорядока, указать макет, а затем нажмите кнопку Меню.

    5. В меню Advanced нажмите кнопку Advanced Параметры.

    6. В окне Подключения выберите сетевой адаптер, который вам нужен.

    7. Переместите этот сетевой адаптер в верхнюю часть списка или в нижнюю часть списка. Это можно сделать с помощью кнопок UP ARROW и DOWN ARROW.

    8. Нажмите кнопку ОК.

    Изменение файла «Хостс»

    Для скрытого адаптера невозможно изменить порядок привязки с помощью действий в разделе «Как изменить порядок привязки». Для скрытых адаптеров необходимо добавить запись в файл Hosts, использующий предназначенное имя хоста и IP-адрес.

    Чтобы изменить файл Hosts, выполните следующие действия:

    1. Нажмите кнопку кнопку Все программы.

    2. Щелкните аксессуары, щелкните правой кнопкой мыши Блокнот, а затем нажмите кнопку Выполнить в качестве администратора.

    3. или предодокайте подтверждение.

    4. В командную строку введите следующую команду и нажмите ВВОД:

      cd %windir%\System32\Drivers\Etc  
      
    5. В командной подсказке введите хосты блокнота и нажмите кнопку ENTER.

    6. В нижней части файла, открываемого на шаге 5, добавьте новую запись для предназначенного IP-адреса с помощью следующего формата: IP_Address Hostname
      Например, для IP-адреса 10.0.0.1 для Server01 введите:
      10.0.0.1Server01

    7. В меню File нажмите кнопку Сохранить, а затем Блокнот.

    8. В командной подсказке введите 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 утилитами. Пользователи могут полностью пропустить шаг пинг сканирования с помощью опции сканирования с целью составления списка (-sL) или просто отключив его (-PN), или сканировать сеть с помощью произвольных комбинаций мультипортовых TCP SYN/ACK, UDP и ICMP запросов. Целью всех этих запросов является получение ответов, указывающих, что IP адрес в настоящее время активен (используется хостом или сетевым устройством). В большинстве сетей лишь небольшой процент IP адресов активен постоянно. Это особенно характерно для адресных пространств вида 10.0.0.0/8. Такие сети имеют 16 млн. IP адресов, но я видел, как они используются компаниями, в которых не более тысячи машин. Функция обнаружения хостов может найти эти машины в этом необъятном море IP адресов.

    Если не задано никаких опций обнаружения хостов, то Nmap посылает TCP ACK пакет на порт 80 и запрос на ICMP эхо ответ кажодй целевой машине. Исключение составляет ARP сканировании всех целей в сети. Для непривилегированных пользователей Unix оболочки, вместо ACK пакета посылается SYN используя системный вызов connect Эти умолчания равнозначны опциям -PA -PE. Такое сканирование достаточно для локальных сетей, но для исследования безопасности необходимо использовать более сложные наборы запросов.

    Опции -P* (определяющие тип пинг сканирования) могут комбинироваться. Вы можете увеличить шансы обхода строго брандмауэра посылая множество запросов различных типов, используя различные TCP порты/флаги и ICMP коды. Также имейте в виду, что даже если вы определите различные -P* опции, по умолчанию применительно к целям локальной сети будет производиться и ARP сканирование (-PR), т.к. оно почти всегда быстрее и более эффективно.

    По умолчанию после обнаружения хостов Nmap начинает сканирование портов каждой активной машины. Так будет, даже если вы укажите на использование нестандартных методов обнаружения хостов, например, с использованием UDP запросов (-PU). Прочтите об опции -sP, чтобы узнать, как выполнить только обнаружение хостов, или используйте опцию -PN, чтобы пропустить обнаружение хостов и осуществить сканирование портов всех целевых машин. С помощью следующих опций можно настраивать функцию обнаружения хостов:

    -sL (Сканирование с целью составления списка)

    Это тип сканирования является «упрощенной» версией функции обнаружения хостов, при помощи которого просто будет создан список хостов заданной сети без посылки каких-либо пакетов целевым машинам. По умолчанию Nmap все же будет осуществлять обратное разрешение DNS с целью узнавания имен хостов. Часто бывает удивительно, как много полезной информации могут содержать обычные имена хостов. Например, fw.chi это имя брандмауэра одной Чикагской компании. В конце Nmap также сообщает общее количество IP адресов. Этот тип сканирования также является хорошим способом проверить, что вы действительно знаете IP адреса необходимых вам целей. Если имена хостов содержат неизвестные вам доменные имена, то стоит провести дальнейшее исследование, чтобы избежать сканирования сети не той компании, которая вам нужна.

    Т.к. целью является просто составление списка целевых хостов, то опции с большим уровнем функциональности, такие как сканирование портов, определение ОС или пинг сканирование не могут сочетаться с рассматриваемой опцией. Если вы хотите отключить пинг сканирование, но хотите использовать опции с таким высоким уровнем функциональности, то почитайте об опции -PN.

    -sP (Пинг сканирование)

    Эта опция указывает Nmap произвести пинг сканирование (определение хостов), а затем вывести список доступных хостов, т.е. тех, которые ответили на запросы. Определение маршрутов и NSE скрипты также используются, если необходимо, однако дальнейшее тестирование (как сканирование портов или определение ОС) не производится. По умолчанию эта опция считается как бы на один шаг более тщательной, чем сканирование с целью составления простого списка хостов, и может быть использована в этих же целях. Она позволяет произвести исследование целевой сети без привлечения внимания. Знание, какие хосты в сети в данный момент работают, для атакующих ценне, чем просто список IP адресов и сетевых имен, предоставляемых опцией -sL.

    Эта опция также полезна системным администраторам. Она может быть использована для подсчета количества работающих в сети машин или мониторинга доступности сервера. Это часто называют «пинг чисткой» (ping sweep) и результаты, предоставляемые этой опцией, заслуживают больше доверия, чем обычное пингование широковещательных адресов, т.к. большинство хостов не отвечают на подобные запросы.

    По умолчанию опцией -sP посылаются запрос на ICMP это ответ и TCP ACK пакет на порт 80. Когда используется непривилегированным пользователем, посылается только SYN пакет (используя системные вызов connect) на порт 80 целевой машины. Когда привилегированный пользователь производит сканирование целей локальной сети, то используются ARP запросы до тех пор, пока не будет задано --send-ip. Для большей гибкости опция -sP может быть скомбинирована с любой из опций -P* (за исключением -PN). Если используется какой-либо из этих типов запросов и опции для задания номеров портов, то запросы по умолчанию (ACK и это ответы) опускаются. Когда между машиной с Nmap и целевой сетью расположен строгий брандмауэр, то рекомедуется использование таких расширенных методов сканирования. Иначе некоторые из хостов могут быть не определены, т.к. брандмауэр заблокировал запрос или ответ.

    -PN (Не использовать пинг сканирование)

    Указывает Nmap полностью пропустить этап обнаружения хостов. Обычно, Nmap использует этот этап для обнаружения активных машин, к которым можно применить более углубленное сканирование. По умолчанию Nmap производит углубленное сканирование, такое как сканирование портов, определение версии или определение ОС только обнаруженных работающих хостов. После отключения этапа обнаружения хостов опцией -PN, Nmap будет производить сканирование каждого заданого целевого IP адреса. Так что, если для сканирования будет определена сеть с адресным пространством класса B (/16), то будет произведено сканирование всех 65,536 IP адресов. Т.к. этап обнаружения хостов и составления списка целей сканирования пропущен, то Nmap будет исполнять запрошенные функции, как если бы каждый IP адрес был активен. Для машин локальной сети будет произведено ARP сканирование (пока не зададите --send-ip), т.к. Nmap необходимы MAC адреса для дальнейшего сканирования целевых хостов. Раньше эта опция задавалась флагом P0 (используется нуль), но была переименова, чтобы избежать путаницы с пингованием с использованием IP протокола PO (используется буква O).

    -PS <список_портов> (TCP SYN пингование)

    Эта опция посылает пустой TCP пакет с установленным SYN флагом. Порт по умолчанию — 80 (можно задать во время компилирования изменяя DEFAULT_TCP_PROBE_PORT_SPEC в nmap.h). Альтернативные порты задаются в качестве параметров. Синтаксис такой же как и для опции -p за исключением того, что спецификаторы типа T: недопустимы. Примеры: -PS22 и -PS22-25,80,113,1050,35000. Имейте в виду, что между списком портов и -PS не должно быть пробела. Если заданы несколько запросов, то они будут посланы параллельно.

    Установленные флаг SYN указывает удаленной системе, что вы пытаетесь установить соединение. Если порт назначения закрыт, то в ответ посылается RST (сброс) пакет. Если порт открыт, то удаленная система предпримет второй шаг в 3-ех этапной последовательности установки TCP соединения путем ответа SYN/ACK TCP пакетом. Система, на которой работает Nmap, сбрасывает почти установленное соединение отвечая RST пакетом вместо ACK, что привело бы к установке полного соединения. RST пакет посылается ядром системы, на которой работает Nmap, в ответ на непредвиденный SYN/ACK пакет, а не самой Nmap.

    Nmap не важно открыт порт или закрыт. Ответы пакетами RST или SYN/ACK описанными выше, указывают Nmap на то, что хост доступен и может отвечать на запросы.

    На Unix машинах, только пользователь с правами root, как правило, может посылать и принимать сырые TCP пакеты. Для непривилегированного пользователя для каждого целевого порта инициируется системный вызов connect. Поэтому при попытке установить соединение на целевой хост посылается SYN пакет. Если на вызов connect приходит быстрый ответ или отказ типа ECONNREFUSED, значит TCP стек получил SYN/ACK или RST пакет, и хост помечается как доступный. Если соединение не устанавливается по причине истечения времени (timeout), то хост помечается как не работающий. Этот механизм также используется для соединений с использованием протокола IPv6, т.к. построение сырых пакетов IPv6 еще не реализовано в Nmap.

    -PA <список_портов> (TCP ACK пингование)

    Этот тип пингования очень похож на описанный выше. Разница состоит в том, как вы могли догадаться, что вместо установки SYN флага устанавливается TCP ACK флаг. Такой ACK пакет имеет своей целью распознавание данных во время установленного TCP соединения, но такого соединения не существует, поэтому удаленные хосты всегда будут отвечат на такой запрос RST пакетом, тем самым выдавая свое существование.

    Опция -PA использует тот же порт по умолчанию, что и SYN запросы (80), и так же может принимать в качестве параметра список портов в том же формате. Если эту опцию пытается использовать непривилегированный пользователь или задана цель в формате IPv6, то используется механизм с использованием вызова connect описанный выше. Этот механизм несовершенен, т.к. при использовании вызова connect вместо ACK пакета посылается SYN.

    Причина, по которой Nmap предоставляет оба типа пингования (SYN и ACK), состоит в повышении шансов обхода брандмауэров. Многие администраторы конфигурируют роутеры или другие простые брандмауэры на блокировку входящих SYN пакетов за исключением тех, что предназначены для публичных служб, таких как веб сайт или почтовый сервер. Тем самым предотвращаются все остальные соединения, и в то же время пользователи могут беспрепятственно выходить в Интернет. Такой подход не требует много ресурсов от брандмауэров/роутеров и широко поддерживается различными аппаратными и программными фильтрами. для реализации такого подхода имеет опцию --syn. Когда брандмауэр использует такие правила, то запросы с установленным флагом SYN (-PS), посланные на закрытые порты, с большой вероятностью будут заблокированы. В таких случаях более выгодно использовать запросы с флагом ACK, т.к. они не попадают под эти правила.

    Другим популярным типом сетевого экрана является брандмауэр блокирующий все непредвиденные пакеты. Изначально эта функция поддерживалась только в наиболее продвинутых брандмауэрах, хотя с годами она становится все популярнее. Использующийся в Linux сетевой экран Netfilter/iptables реализует этот механизм с помощью опции --state, которая категоризирует пакеты в зависимости от состояния соединения. Против таких систем лучше использовать пакеты SYN, т.к. непредвиденные пакеты ACK с большой вероятностью будут распознаны как фиктивные и заблокированы. Решение такого затруднительного положение состоит в том, чтобы посылать и SYN и ACK запросы путем задания опций -PS и -PA.

    -PU <список_портов> (UDP пингование)

    Еще одной функцией используемой для обнаружения хостов является UDP пингование, которая посылает пустой (пока не задана опция --data-length) UDP пакет на данные порты. Список портов задается в том же формает, что и для описанных выше опций -PS и -PA. Если порты не заданы, то по умолчанию используется 31338. Порт по умолчанию может быть задан во время компиляции путем изменения DEFAULT_UDP_PROBE_PORT_SPEC в nmap.h. По умолчанию выбран не распростаненный порт, т.к. отправка запросов на открытые порты нежелательна для этого типа сканирования.

    Целью запроса UDP является получение в ответ ICMP пакета с ошибкой «порт недостижим». Это указывает Nmap на то, что машина работает и доступна. Другие типы ICMP ошибок, такие как хост/сеть недоступна или превышение TTL указывают на то, что машина выключена или недоступна. Отсутствие ответа интерпретируется этим же путем. Если такой запрос посылается на открытый порт, то большинство служб просто игнорируют пустой пакет и не посылают никакого ответа. Поэтому портом по умолчанию является 31338, т.к. он вряд ли будет использоваться какой-либо службой. Лишь некоторые службы, такие как Character Generator (chargen) protocol, ответят на пустой UDP пакет, и это также укажет Nmap на то, что машина доступна.

    Основным преимуществом такого типа сканирования является то, что он позволяет обходить брандмауэры, фильтрующие только TCP запросы. Например, однажды у меня был беспроводной широкополосный роутер Linksys BEFW11S4. Внутренний интерфейс этого устройства фильтровал по умолчанию все TCP порты, в то время как в ответ на UDP запросы посылалось сообщение об ошибке «порт недостижим», что делало его работу бесполезной.

    -PE; -PP; -PM (Типы пинг пакетов ICMP)

    В дополнении к нестандратным методам обнаружения хостов с помощью TCP и UDP запросов, Nmap может посылать и стандартные пакеты, используемые вездесущей программой ping. Nmap посылает ICMP пакет типа 8 (эхо запрос) на целевой IP адрес, ожидая в ответ от доступного хоста пакет типа 0 (эхо ответ). К сожалению для сетевых исследователей, многие хосты и брандмауэры теперь блокируют такие пакеты вместо того, чтобы ответить на них, как это требуется в RFC 1122. По этой причине сканеры использующе только ICMP запросы редко бывают полезны при сканировании неизвестных целей в Интернете. Но они могут быть полезны системным администраторам, занимающимся мониторингом внутренней сети. Используйте опцию -PE, чтобы активировать такой тип сканирования.

    Но Nmap использует не только стандратный эхо запрос. В стандарте ICMP (RFC 792) также определены запросы временной метки, информационные запросы и запросы адресной маски с кодами 13, 15 и 17 соответственно. Хотя они служат для того, чтобы узнать какую-либо информацию, такую как адресную маску или текущее время, они могут быть легко применены для обнаружения целей. Система, которая отвечает на них, работает и доступна. В настоящее время Nmap не использует информационные запросы, т.к. они не получиил широкого распространения. Стандарт RFC 1122 наставивает на том, что «хост НЕ ДОЛЖЕН посылать такие сообщения». Запросы временной метки или адресной маски могут быть посланы путем задания опций -PP и -PM соответственно. Ответ на запрос временной метки (ICMP код 14) или на запрос адресной маски (код 18) указывают на то, что хост доступен. Эти запросы могут быть полезны, когда администраторы блокируют пакеты эхо запросов, но забывают о том, что другие типы ICMP запросов могут быть использованы в тех же целях.

    -PO <список_протоколов> (пингование с использованием IP протокола)

    Новейшей опцией для обнаружения хостов является пингование с использованием IP протокола, которая посылает IP пакеты с номером протокола, указанным в заголовке пакета. Список протоколов задается в том же формате, что и список портов в описанных выше опциях обнаружения хостов с помощью протоколов TCP и UDP. Если не указан ни один протокол, то по умолчанию будут использованы IP пакеты ICMP (протокол 1), IGMP (протокол 2) и IP-in-IP (протокол 4). Протоколы по умолчанию могут быть заданы во время компиляции путем изменения DEFAULT_PROTO_PROBE_PORT_SPEC в nmap.h. Имейте в виду, что для ICMP, IGMP, TCP (протокол 6) и UDP (протокол 17), пакеты посылаются с «правильными» заголовками протокола, в то время как для остальных протоколов пакеты посылаются без дополнительной информации после IP заголовка (пока не задана опция --data-length).

    При использовании этого метода ожидаются ответы по протоколу исходного запроса, либо ICMP сообщение о недостижимости, что свидетельствует о том, что данный протокол не поддерживается удаленным хостом. Оба варианта ответа означают, что целевой хост доступен.

    -PR (ARP пингование)

    Одной из наиболее популярных сфер применения Nmap является сканирование локальных сетей (LAN). В большинстве локальных сетей, особенно тех, которые используют диапазоны частных адресов определенные в RFC 1918, большое количество IP адересов не используется в любой момент времени. Когда Nmap пытается послать сырой IP пакет, такой как ICMP эхо запрос, операционная система должна определить MAC-адрес (ARP) соответствующий целевому IP, чтобы правильно адресовать фрейм. Это часто бывает медленно и проблематично, т.к. операционные системы не были написаны с учетом того, что им придется посылать миллионы ARP запросов недоступным хостам в короткий промежуток времени.

    ARP сканирование позволяет Nmap вместо ARP запросов использовать свои собственные оптимизированные алгоритмы. И если Nmap получает ответ, то ей даже нет необходимости беспокоиться о других типах обнаружения хостов, основанных на IP пакетах. Этот делает ARP сканирование более быстрым и надежным. Поэтому оно применяется по умолчанию для сканирования локальных сетей. Даже если указаны другие типы сканирования (как -PE или -PS), Nmap все равно использует ARP сканирование для машин локальной сети. Если вы абсолютно не хотите использовать такой тип сканирования, то задайте опцию --send-ip.

    --traceroute (Отслеживать путь к хосту)

    Отслеживание осуществляется после сканирования, используя результаты этого сканирования для определения порта и протокола, с помощью которых можно будет достичь цели. Процедура работает со всеми типами сканирования кроме сканирования с использованием системного вызова connect (-sT) и «ленивого» (idle) сканирования (-sI). Все отслеживания используют динамическую модель таймингов Nmap и осуществляются параллельно.

    Процедура отслеживания маршрута работает путем посылки пакетов с низким TTL (time-to-live (временем-жизни) в попытке получить в ответ ICMP сообщение Time Exceeded (Превышение Времени Жизни) от промежуточных узлов между сканером и целевым хостом. Стандартные реализации процедуры отслеживания маршрута начинают с TTL равным 1, а затем увеличивают его до тех пор, пока не будет достигнут целевой хост. В реализации же этой процедуры в Nmap сначала устанавливается высокий TTL, а затем TTL уменьшается, пока не станет равным 0. Это позволяет Nmap использовать «умные» алгоритмы кэширования с целью увеличения скорости отслеживания маршрута. В среднем Nmap посылает 5-10 пакетов на хост, в зависимости от условий в сети. В случае сканирования единственной подсети (напр. 192.168.0.0/24), возможно будет необходимо послать только один пакет на каждый хост.

    --reason (Показать причины состояний портов и хостов)

    Показывает информацию о причинах, по которым каждый порт установлен в какое-либо состояние, и по которым каждый хост работает или нет. Эта опция выводит тип пакета, по которому было определено состояние порта или хоста. Например, RST пакет от закрытого порта или эхо ответ от работающего хоста. Информация, которую может предоставить Nmap, определяется типом сканирования или пингования. SYN сканирование и SYN пингование (-sS и -PS) описываются очень детально, а информация о сканировании с использованием TCP соединений (-sT) ограничена реализацией системного вызова connect. Эта функция автоматически активируется при использовании опции отладки (-d), и результаты ее работы хранятся в XML файлах, даже если эта опция не была задана.

    -n (Не производить разрешение DNS имен)

    Указывает Nmap никогда не производить обратное разрешение DNS имен каждого обнаруженного активного IP адереса. Преобразование DNS может быть медленным даже со встроенным в Nmap параллельным преобразователем IP адресов, поэтому данная опция может сократить время сканирования.

    -R (Производить разрешение DNS имен для всех целей)

    Указыват Nmap всегда производить обратное разрешение DNS имен для каждого целевого IP адреса. Обычно DNS преобразование применяется только к доступным хостам.

    --system-dns (Использовать системный DNS преобразователь)

    По умолчанию Nmap преобразует IP адреса путем посылки запросов непосредственно серверам имен, указанным в вашей системе, и последующим анализом ответов. Многие запросы (часто десятки) исполняются параллельно для увеличения производительности. Задайте эту опцию, чтобы использовать ваш системный преобразователь IP адресов (один IP адрес за один системный вызов getnameinfo). Это медленно и редко бывает полезно, до тех пор, пока вы не найдете ошибку в параллельном преобразователе Nmap (если найдете, известите нас, пожалуйста). Системный преобразователь всегда используется для сканирования с использованием протокола IPv6.

    --dns-servers <server1>[,<server2>[,...]] (Сервера для обратного разрешения DNS)

    По умолчанию Nmap определяет DNS сервера (для разрашения rDNS) из вашего resolv.conf файла (Unix) или из реестра (Win32). Вы можете использовать эту опцию для задания альтернативных серверов. Эта опция игнорируется, если вы используете --system-dns или сканирование по протоколу IPv6. Использование нескольких DNS серверов частно увеличивает скорость сканирования, особенно если вы выбираете официальные сервера для IP пространства вашей цели. Эта опция также может увеличить незаметность, т.к. ваши запросы могут быть перенаправлены любым рекурсивным DNS сервером в Интернете.

    Эта опция также бывает полезна при сканировании частных сетей. Иногда лишь некоторые сервера имен предоставляют правильную rDNS информацию, и вы можете даже не знать, где они. Вы можете просканировать сеть на наличие открытого порта 53 (возможно с помощью фукнкции определения версии), затем попробовать составить список (-sL) указывая по очереди все сервера имен в опции --dns-servers до тех пор, пока не найдете тот, который работает.

    Тестирование соединений с помощью Ping-запросов | Answer

    Команда «Ping» является одним из первых средств, которые нужно использовать для проверки подключения к компьютеру, маршрутизатору и Интернету. Она выполняется в командной строке, однако получить основные сведения о подключении достаточно просто. Вся процедура не займет больше 30 секунд.

    1. Чтобы выполнить команду ping, последовательно выберите пункты Пуск > Выполнить.
    2. В окне запуска программы введите cmd и нажмите кнопку ОК. Появится окно с черным фоном и белой командной строкой.
    3. Введите ping и через пробел IP-адрес или DNS-адрес.
    4. Нажмите клавишу Enter, чтобы выполнить команду. Три полезных примера:
      1. ping 127.0.0.1 («замыкание на себя» — компьютер пытается обратиться к самому себе. Эта проверка позволяет определить, может ли компьютер передавать трафик Ethernet. Отсутствие ответа после выполнения этой команды указывает на проблему с операционной системой.)
      2. ping 192.168.1.1 (Если после выполнения этой команды получен ответ «Превышен интервал ожидания для запроса.», введите команду ping 192.168.0.1. Если и в этом случае интервал ожидания превышен, это означает, что компьютер не подключается к маршрутизатору.)
      3. 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-адрес).

    • Если в результате поиска было обнаружено более одного подходящего маршрута, тогда будет использован маршрут, имеющий наименьшее административное расстояние.

    • При одинаковых значениях административных расстояний действует следующая приоритетность:

      1. Статические многоадресные маршруты

      2. Маршруты DVMRP

      3. Маршруты MBGP

      4. Одноадресные маршруты

    • Если в одной и той же таблице маршрутов для одного пути будут найдено несколько записей, тогда будет использован маршрут с самым длинным совпадением.

    Из листинга команды 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
    1. 0
    2. +0
    3. Авторизоваться Зарегистрироваться

    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 июн.

    пользователь118687

    1111 золотой знак11 серебряный знак22 бронзовых знака

    1

    — это server1, заполнитель для Интернет-сайта, например, www.google.com? Или это машина, которой вы управляете в своей локальной сети?

    Если это ваша собственная машина, ваш DNS, вероятно, не знает об этом. Вы можете решить эту проблему, добавив строку в файл hosts.

    Если это локальный компьютер, ваши варианты:

    1. добавьте его в файл hosts каждой машины (они также доступны на хостах Windows и OSX) — самый простой, но трудоемкий

    2. имеют IP-адреса компьютеров, переданные (возможно, по MAC-идентификатору) через DHCP-сервер, который также обрабатывает DNS и будет обслуживать эти имена — это маловероятно.Это зависит от вашего DHCP-сервера, но, например, прошивка DD-WRT может это сделать.

    3. запустите свой собственный DNS-сервер (возможно, используя DNS-кеш) и определите IP-адреса ваших серверов в конфигурации

    Пример настройки DNS кеша на сервере Ubuntu здесь, не уверен для Red Hat EL.

    https://help.ubuntu.com/lts/serverguide/dns-configuration.html

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *