Что может помешать установить связь между компьютерами при эхо запросе
Обновлено: 04.07.2024
Для тех, кто уже с локальными сетями на ты, эта публикация будет простой и очевидной. Итак, команда ping запускает эхо запрос по служебному протоколу ICMP. Как вы уже помните, протокол - это по сути язык общения между устройствами. В данном случае ICMP протокол является служебным, так как используется для диагностики, а не для передачи данных. Одной из самых известных команд, использующих данный протокол является команда ping.
Основная идея в том, что вам надо проверить есть ли сетевое соединение от текущего узла до удаленного. Думаю Вам знакома такая ситуация, когда Вы разговариваете по телефону, а там Вас только внимательно слушают, и возникает ощущение, что говоришь в пустоту. Тогда Вы спрашиваете, Петр (или Алексей, или Иван), ты меня слышишь(это запрос), на что там отвечают, да отлично слышу (это ответ на запрос) и Вы продолжаете разговор.
Как правило, сейчас все компьютеры подключены к интернету через локальную сеть и проблемы могут быть как в ней, так и дальше.
1. Запускаем командное окно, с помощью команды cmd
То есть если доступ в интернет есть, а сайт не открывается, тогда пингуем этот сайт, и если пинги есть - это одна ситуация, если пингов нет - другая ситуация. здесь уже проблемы у сайта возможны, а возможно нестыковка по протоколам верхнего уровня. Но стоит отметить, что не все сайты могут подтверждать эхо запрос - отвечать на команду ping. На некоторых умышленно ICMP протокол отключен.
тогда проверяем адрес ping 8.8.8.8 - это один из DNS серверов и он всегда должен быть на связи. Если ответ есть, значит вероятнее всего проблема в настройках DNS. но это лишь предположение, так как вариантов может быть куда больше. Если ответа нет, то исследуем локальную сеть.
4. В командном окне пишем ipconfig .
Видим, что наш адрес, 192.168.1.9, а адрес маршрутизатора через который мы подключены к интернет - 192.168.1.1. Но это так прописано в настройках. Лучше проверить связь с ним через команду ping .
Как видим, все прошло отлично, то есть проблем в локальной сети нет, значит искать надо дальше. Возможно тут стоит звонить провайдеру и выяснять с ним, если в локальной сети связь есть, а дальше нет.
Немного о самой команде и её возможностях :
Если ввести запрос ping /? , то получим полную расшифровку ключей к этой команде.
Если Вы только начинается осваивать направление интернет и компьютерных сетей, то начните с освоения этой команды.
Качество связи во время разговора играет весомую роль в работе компании. Это сказывается, и на эффективности работы сотрудников, и на имидже компании в целом. Основные жалобы: пропадают слова, прерывается голос, слышно эхо или речь приходит с задержкой.
Некоторые провайдеры подскажут причину проблемы и, что можно предпринять со своей стороны. Снимут дамп, сделают анализ и дадут рекомендации. Но таких крайне мало. Из памяти, пожалуй вспомню оператора Мобилон — Привет техподдержке, если читаете!
А что происходит, если провайдер не указал причину и не дал рекомендаций?
Несомненно, у вас начнет закрадываться мысль о смене провайдера. Но решит ли это проблему? Если причина на вашей стороне, то очевидно, что проблема не решится, и с новым провайдером качество будет также неудовлетворительным. А переход, дело не простое и затратное. За такой исход событий руководство компании спасибо вам не скажет.
Можно еще обратиться в аутсорсинговую фирму, которая имеет кейсы в решении подобных проблем. Но это дополнительные затраты. Да и нет никаких гарантий, что потраченные средства оправдают себя.
Что еще можно предпринять? Казалось бы, вариантов больше не осталось.
Но может быть все-таки разобраться самому?
“Да, дорогие друзья!” — Отвечу я вам. — "Всё гораздо проще, чем кажется!"
Имея позитивный опыт в решении подобных проблем, хочу поделиться с вами способом ее диагностики и решения, не прибегая к кардинальным мерам и помощи сторонних лиц.
Для диагностики нам понадобится научиться снимать дамп сети (sniffer) с роутера и маршрутизатор Mikrotik. А также, настроить очереди (QoS) на роутере.
Для упрощения схемы, я поделил весь процесс на этапы:
1. Настройка и запуск packet sniffer
Для того чтобы определить причину проблемы, необходимо снять dump звонка. В нем будет содержаться вся информация о состоянии сети во время вызова.
Настраиваем на Микротике packet sniffer: Tools → Packet Sniffer
На вкладке General оставляем значения по умолчанию.
Открываем настройку Packet Sniffer
Вкладка Streaming: галочки Streaming Enabled и Filter Stream, в поле Server пишем адрес, куда будем отправлять данные, собираемые сниффером.
Прописываем адрес хоста куда слать сниффер
Я отправляю на свой ПК в той же сети, поэтому прописываю его локальный адрес. Но можно слать и на удаленный сервер, тогда прописываем его внешний ip.
Вкладка Filter: здесь необходимо в поле IP Address прописать ip-адрес провайдера телефонии.
Если не получилось выяснить адреса провайдера, то можно прописать просто 0.0.0.0/0
Но тогда в дампе будет очень много лишней информации, что затруднит анализ.
Я пообщался с техподдержкой своего провайдера, они порекомендовали прописать всю подсеть.
Прописываем адрес провайдера ip-телефонии Packet Sniffer запущен-
Сниффер на роутере запущен, теперь необходимо поймать пакеты.
На том ПК или сервере, адрес которого указали в поле Server, нужно запустить tcpdump.
а) нужно скачать утилиту tcpdump
Скачиваем с официального сайта версию не для коммерческого использования.
tcpdump.exe можно запустить даже с флэшки
Для этого запускаем cmd от имени администратора и проваливаемся в директорию с файлом tcpdump.exe
Запускаем tcpdump на Windows
Вводим команду tcpdump -D
Нам отобразится список доступных интерфейсов.
Выводим список доступных интерфейсов
Запускаем дамп в онлайн режиме, чтобы найти интерфейс, который нам нужно слушать.
Например: tcpdump -i 1 -v -n host 192.168.88.1
где 1 - это номер интерфейса, а host - адрес роутера.
У меня пакеты летят на интерфейсе под №4, его и буду слушать.
Запускаем tcpdump online
Далее запускаем команду для отлова сниффера с Микротика:
tcpdump host 192.168.88.1 -i 4 -C50 -n -v -w name_sniffer.pcap
где i - номер интерфейса, С50 - ограничение размера записываемого файла до 50Мб, n - отображать IP-адреса вместо имени хостов, v - уровень отображения получаемой информации (1-й уровень), w - записывать данные в файл.
Запустили tcpdump для отлова Packet Sniffer
Необходимо установить утилиту tcpdump. Обычно она присутствует в стандартном репозитории.
Более подробно про установку можно посмотреть, например, здесь.
tcpdump host 192.168.88.1 -i any -C50 -n -v -w /var/tmp/name_sniffer.pcap
После запуска tcpdump вы должны увидеть отсчет улавливаемых пакетов (на Linux), в поле Got. Если отсчет не идет, значит что-то сделали неверно, перепроверьте.
Запустили tcpdump для отлова Packet Sniffer
2. Фиксируем проблемный звонок
Теперь, когда у нас tcpdump ловит сниффер с Микротика, нужно зафиксировать проблемный звонок.
Если проблема плавающая, тогда следуют попросить сотрудников, чтобы записали время и номер телефона, когда возникнет деградация голоса.
У меня получилось зафиксировать такой пример самостоятельно с одним из сотрудников:
Как мы слышим на записи, голос идет с прерываниями.
Но может быть и так, что на записи из личного кабинета виртуальной АТС провайдера всё будет отлично, а мы слышали человека на том конце провода плохо. Это значит, что к провайдеру голос приходит хорошего качества, а уже по пути от провайдера до нашего конечного устройства голос доходит с потерей пакетов. Для того, чтобы проверить это, нам поможет сниффер.
3. Останавливаем sniffer и анализируем его в Wireshark
Проблемный вызов необходимо проанализировать. Останавливаем tcpdump (Ctrl+C) и sniffer на Микротике (нажать Stop). Создастся файл name_sniffer.pcap.
Открываем pcap файл в Wireshark и переходим в Телефония → Вызовы VoIP
Открываем pcap файл для анализа
В новом окне отобразятся все вызовы, которые попали в дамп. У меня такой один.
VoIP-вызов в дампе
-Выберите вызов и откройте “Последовательность потоков”, чтобы увидеть движение запросов по вашему звонку.
Дамп движения запросов звонка (последовательность потоков)
В случае, когда не проходит вызов или наблюдается односторонняя слышимость, мы можем с помощью дампа последовательности потоков увидеть, где кроется проблема.
Далее нас интересуют RTCP пакеты.
Из всего перехваченного сниффером трафика нужно отфильтровать только RTCP пакеты.
- отобразить RTCP со значением потерь пакетов больше 10 или RTCP со значением джиттера больше 35.
Анализ RTCP по звонку
Здесь видим, что потеряно 50 пакетов из 256 и уровень джиттера 166 (хотя нормальный уровень это 30-70).
По каким причинам это может происходить?
Забивается линия выделенная вам от интернет провайдера.
Например, у нас 3Mб/с на "внешку". Устройства в локальной сети потребляют все 3Mб/с, но если просто сёрфить в браузере, то мы не заметим нехватку канала. Так как в этом случае, используется транспортный протокол TCP. А телефония использует UDP, которому свойственно теряться в процессе передачи, если весь ваш выделенный канал занят.
Устройства подключены по “воздуху” (Wi-Fi).
В таком случае будет высокий показатель джиттера.
У провайдера на линии есть радиоканал.
Проблема с вашим маршрутизатором.
Проблемы на линии интернет провайдера
В этой статье, более подробно, рассмотрена причина под пунктом № 1.
По остальным скажу кратко.
Пункт № 2 - если на устройствах есть функция джиттер-буфер, то нужно установить режим “Fixed”. Если нет такой опции, то подключить устройство витой парой.
Пункт № 3 и № 5 - обратиться к интернет провайдеру, предоставив наши дампы, подтверждающие проблему.
Пункт № 4 - диагностировать или заменить роутер.
Но в первую очередь, рекомендую всегда сначала проработать пункт № 1.
4. Настраиваем выделенную полосу для ip-телефонии
Необходимо в вашей локальной сети обеспечить для ip-телефонии отдельную полосу пропускания (QoS), чтобы трафик других устройств не мешал.
Для начала, измерьте фактическую скорость интернета на "внешку".
У меня на загрузку скорость 11Мб/с, на отдачу 14Мб/с. Хотя по договору должно быть 15М в обе стороны. Поэтому и рекомендую измерять, какая у вас скорость по факту, а не по бумагам. Это поможет корректно настроить очереди на роутере.
Для настройки очередей открываем на Микротике Queues
Queues
Cоздаем правила в разделе Simple Queues.
На вкладке General задаем ограничение по скорости для всей локальной сети.
Я устанавливаю максимальные значения лимита меньше на 2М, чем полученные при замере.
Почему 2М? Беру с запасом, так как скорость может быть не постоянной и в моменте меняться как в большую, так и в меньшую сторону.
Настройки на вкладке General
В Advanced выставить Queue Type распределение по pcq (это делается для того, чтобы устройства не мешали друг другу и равномерно использовали трафик).
Настройки на вкладке Advanced
Сохраняем это правило и создаем еще одно, для SIP.
Прописываем ip-адрес (можно всю подсеть) провайдера ip-телефонии.
Максимальные лимиты устанавливаем, как заявлено по договору интернет провайдера.
Настройки General для SIP
В Advanced устанавливаем Limit At. Это позволит для телефонии оставлять 1Мб/с в любом случае, даже если идет максимальная нагрузка на канал другими устройствами.
Вкладка Advanced при настройке QoS для SIP
Сохраняем и устанавливаем правило SIP на верхнюю позицию.
Порядок QoS правил
ВНИМАНИЕ!
Учитывайте порядок настроенных правил. Обработка осуществляется сверху вниз. Поэтому обязательно правило SIP поднимаем на самый верх (см на скриншоте).
Чтобы очереди (QoS) начали работать, необходимо деактивировать правило Fasttrack в IP → Firewall → Filter Rules.
Пояснение по настроенным QoS:
весь трафик, который идет на ip-адреса отличные от адреса voip-провайдера, ограничивается 12Мб/с на загрузку и 9Мб/с на отдачу
весь остаток от этого до 15Мб/с оставляем для телефонии
и на тот случай, что если даже трафик проскочит выше лимитов, для телефонии отведен 1Мб/с принудительно
Далее проверяем ходит ли вообще трафик в настроенных QoS.
Нужно открыть настройки очереди и перейти на вкладку Traffic.
График трафика local QoS График трафика sip QoS
На вкладке Statistic можно увидеть, количество “дропнутых” пакетов и распределенных по pcq.
Статистика local QoS
Также можно проверить, как отрабатывают очереди, с помощью утилиты iperf.
5. Тестируем связь
Теперь, когда QoS настроены, нужно протестировать связь.
Ставим дамп и делаем несколько тестовых звонков.
Я сделал несколько вызовов сотрудникам, и мы вместе убедились, что теперь прерываний не наблюдалось.
Вот пример одного из звонков.
В дампе этого вызова потерь пакетов не наблюдается.
Дамп звонка после настройки QoS Дамп звонка после настройки QoS
Единственное, можно заметить, что уровень джиттера выше нормы.
Это обусловлено подключением voip-устройства через Wi-Fi. И, так как устройство позволяет настроить джиттер-буфер, качество голоса не страдает.
Итоги
Когда у вас возникла проблема с качеством голоса цифрового характера, всегда в первую очередь, производите анализ локальной сети и настройте QoS для телефонии. Если даже выяснится, что причина была не на вашей стороне, то у вас уже будут технические данные (дампы), которые сможете предоставить провайдерам для подтверждения.
В некоторых организациях в локальной сети может находиться большое количество устройств с разными категориями. Например, помимо ip-телефонии еще ip-камеры, которые также используют udp протокол для передачи данных. Следовательно для ip-камер тоже необходимо выделять QoS.
Вам не обязательно настраивать очереди точно также, как у меня. Главное, что я хотел, показать логику решения проблемы с качеством голоса.
Проверка сети и интернета с помощью команды ping
Предположим, что вам нужно проверить связь с компьютером в соседнем кабинете, для этого вам нужно знать его IP адрес (сетевой адрес) или имя этого компьютера. Пускай его IP адрес будет 192.168.88.1 и имя в сети SPA. Заходим в Пуск, выбираем пункт Выполнить. Так же можно и с помощью горячих клавиш. Для этого нажимаем Windows + R. В открывшемся окне пишем команду для вызова командной строки cmd.
выполнить и пишем cmd
После нажатия кнопки OK появится окно командной строки, в котором пишем команду ping 192.168.1.100 или ping spa, где после команды ping идет сетевой адрес или сетевое имя компьютера с которым проверяем связь.
пинг адреса в сети
При получение команды ping ваш компьютер начинает посылать пакеты удаленному компьютеру, удаленный компьютер приняв эти пакеты отсылает ответ о принятых пакетах. С скриншотов выше мы видим. Что ваш компьютер отослал четыре пакета по 32 байта и получил ответ с задержкой 1 мс.
Рабочий пример когда пропали пинги:
Внезапно стал тормозить outlook, письма не переключаются и не отправляются. Все висит. Открыл cmd вбил адрес outlook и написал команду
Вот результат что я увидел
Такая картина предстала на моем мониторе. Была потеря пакетов и 250+ мс задержки до сервера. Пришлось писать тикет в майкрософт и провайдеру.
Если вам интересно в чем была проблема, описание проблемы и ее решения в конце статьи.
В продолжении времени ответа хочу сказать, чем меньше время ответа от удаленного ресурса тем стабильнее связь.
нормальный пинг до сервера microsoft outlook
А так же хочу добавить, что количество и размер отправляемых пакетов можно увеличить. Делается это для тестов стабильности канала. Введя в командной строке команду
Где -t означает количество отправляемых пакетов. (Если после -t не указать число то пакеты будут отправляться бесконечно).
И где -l 50 означает, что размер отправляемых пакетов будит 50 байт.
Для теста интернета и его стабильности я использую команду
Можно писать и ip адрес, но на мой взгляд так быстрее. Кстати кто-то пишет ip google 8.8.8.8, на мой взгляд это долго.
Ping через сеть Wi-Fi
Хочу заметить еще вот что, если у вас wi-fi 2,4 Ghz. Тогда могут быть небольшое задержки при пинге. Не пугайтесь это нормально. Например эту задержку видно на скриншоте.
1 Ответ от 87.250.250.242: число байт=32 время=47мс TTL=243
2 Ответ от 87.250.250.242: число байт=32 время=53мс TTL=243
3 Ответ от 87.250.250.242: число байт=32 время=71мс TTL=243
4 Ответ от 87.250.250.242: число байт=32 время=47мс TTL=243
5 Ответ от 87.250.250.242: число байт=32 время=47мс TTL=243
Почему к outlook были большие пинги и обрывы
Как я и обещал пишу о том как я исправил проблему с outlook 365. Написав провайдеру и отправив тикет в microsoft я принялся искать проблему внутри сети. Оказалось что у меня на роутере стояли dns не провайдера, а dns google. Поменяв днс на маршрутизаторе проблема ушла.
Через время мне ответили и провайдер и microsoft что они проблем не видят. Но я их немного опередил.
Как найти кольцо в сети при помощи команды ping
Вот кстати еще один хороший совет. Если у вас в внутри сети скачут пинги. Скорее всего у вас образовалось кольцо в сети. Чтоб его найти требуется
- Отключить все свитчи и хабы от роутера.
- Далее по одному подключать при этом запускать на одном из подключаемых компьютерах команду пинг на роутер.
Если пинги будут:
1 Ответ от 192.168.1.1: число байт=32 время=1мс TTL=64
2 Ответ от 192.168.1.1: число байт=32 время=1мс TTL=64
3 Ответ от 192.168.1.1: число байт=32 время=1мс TTL=64
4 Ответ от 192.168.1.1: число байт=32 время=1мс TTL=64
Все хорошо, но если вы увидите такую картину
1 Ответ от 192.168.1.1: число байт=32 время= 1мс TTL=64
2 Ответ от 192.168.1.1: число байт=32 время= 67мс TTL=64
3 Ответ от 192.168.1.1: число байт=32 время= 158мс TTL=64
4 Ответ от 192.168.1.1: число байт=32 время= 89мс TTL=64
5 Ответ от 192.168.1.1: число байт=32 время= 1мс TTL=64
6 Ответ от 192.168.1.1: число байт=32 время= 14мс TTL=64
Тогда на этом участке который вы только что подключили есть кольцо. Соответственно вам надо пойти и найти тот свитч или хаб. В который неопытный пользователь воткнул патч корд двумя концами.
Иногда невозможность установить связь с удаленным сервером может сводить с ума, так как вы не знаете, чья это проблема - ваша или удаленного сервера. Все перечисленное ниже должно дать вам некоторое представление о различных проблемах удаленного доступа.
Не работает модем
Если модем не работает, возможны следующие варианты.
Связь прерывается
Если соединение постоянно прерывается, проверьте следующие условия.
- Разрыв связи происходит из-за отсутствия действий. Наберите номер еще раз.
- Ожидание вызова прерывает соединение. Отключите ожидание вызова (звонка).
- Кто-то еще воспользовался удлинителем.
- Отсоединился кабель модема.
- Программа модема нуждается в обновлении.
- Настройки модема несовместимы с сервером удаленного доступа.
- Сервер удаленного доступа отключен.
- Модем не может взаимодействовать с модемом удаленного сервера.
- Внешний модем не включен.
- Модем неисправен. Активируйте регистрацию модема для проверки связи.
- Кабель несовместим с модемом.
- Линия занята.
- Качество линии плохое.
- ISDN-коммутатор занят. Попробуйте позже.
- Неправильно сконфигурирован телефонный номер. Для соединения может потребоваться один или два телефонных номера. Свяжитесь с телефонной компанией и уточните.
- Неправильно введен идентификатор профиля SPID (Service Profile Identifier) - это относится к Соединенным Штатам и Канаде.
- Не включен учет времени, проводимого в сети.
- Удаленный сервер не подключен или выключен.
Полезные сетевые инструменты и сценарии
Существует несколько инструментов для отслеживания и решения проблем, связанных с применением протокола TCP/IP . Этими инструментами являются PING , ARP , IPCONFIG, TRACERT, NBTSTAT и PATHPING. Все они запускаются из командной строки и выдают результаты в формате DOS . В таблице 8.1 перечислены эти инструменты и дано их краткие описания.
Подобно гидролокатору на подводной лодке, команда PING позволяет получать информацию о своих соседях. Правда, тут она применяется в сугубо мирных целях. Она может сообщить вам о том, как долго информационные пакеты идут из вашего компьютера на принимающий компьютер. Она делает это посредством отправки ICMP эхо-сигнала указанному устройству - будь то устройство локальной сети или сервер на другой стороне земного шара.
Если вы тестируете пинг-запросом устройство своей локальной сети, то устройство откликнется практически мгновенно. В этом случае вы узнаете, что оба компьютера работают нормально. При возникновении проблем следует выполнить следующие шаги.
1. Протестируйте пингом-запросом адрес локальной перемычки. Если этот адрес ответит, то на локальном компьютере имеется конфигурация протокола TCP/IP.
2. Протестируйте локальный IP-адрес и убедитесь, что нет конкуренции с другим устройством в сети.
3. Протестируйте IP-адрес шлюза по умолчанию. Так вы проверите возможность добраться до ближайшего маршрутизатора, который позволяет общаться с компьютерами в другой подсети.
Ping IP_адрес шлюза
4. Протестируйте пингом-запросом адрес указанного вами устройства в другой подсети. Так вы проверите возможность установки связи с устройством другой подсети.
Ping IP_адрес узла
5. Протестируйте пингом-запросом то же самое устройство, применив полное имя его домена. Если попытка закончится провалом, но шаг 4 работает, то это проблема разрешения имени. На этом этапе следует убедиться, что DNS-серверы доступны, таблицы Hosts и LMHosts точны, а WINS (если используется) правильно сконфигурирован.
Ping IP_имя узла
Инструмент PING используется следующим образом:
Ping [-t] [-a] [-n] [-l] [-f] [-I TTL] [-v TOS ] [-r ] [-s ] [-j список узлов] [-k список узлов] [-w ] список адресатов
Читайте также: