Общие сведения о командах Ping и Traceroute
В этой статье рассматривается использование команд ping и traceroute. Приведенный в данном документе более подробный обзор результатов выполнения этих команд, был получен с помощью некоторых команд debug.
Базовые сведения
В данном документе используется простая конфигурация, представленная ниже и используемая в качестве примера
Команда ping
- Является ли удаленный хост активным или неактивным;
- Задержки приема-передачи при взаимодействии с хостом;
- Потери пакетов.
- эхо-запрос достигает места назначения;
- опрашиваемое устройство может отправить эхо-ответ обратно источнику в рамках заданного времени, называемого временем ожидания (тайм-аутом). Значение тайм-аута по умолчанию для маршрутизаторов Cisco равно двум секундам.
Router1#debug ip packet detail
IP packet debugging is on (detailed)
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
Router1#
Jan 20 15:54:47.487: IP: s=12.0.0.1 (local), d=12.0.0.2 (Serial0), len 100,
sending
Jan 20 15:54:47.491: ICMP type=8, code=0
!— Это ICMP пакет, отправленный из 12.0.0.1 в 12.0.0.2.
!— ICMP тип=8 соответствует эхо-сообщению.
Jan 20 15:54:47.523: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 100,
rcvd 3
Jan 20 15:54:47.527: ICMP type=0, code=0
!— Это ответ, полученный от 12.0.0.2.
!— ICMP тип=0 соответствует эхо-ответу.
!— По умолчанию число повторов равно 5, поэтому будет пять
!— эхо-запросов и пять эхо-ответов.
В приведенной ниже таблице перечислены возможные значения типа ICMP-протокола.
В нижеприведенной таблице содержатся сведения о символах, которые могут содержаться в результатах выполнения команды ping:
Причины неудачного выполнения команды ping
Если не удается успешно выполнить команду ping, то причиной этому могут быть:
Проблема маршрутизации
Далее приведен пример неудачного выполнения команды ping, определения проблемы и мер, необходимых для ее устранения.
Данный сценарий объясняется с помощью схемы топологии сети, приведенной ниже:
Router1#
!
!
interface Serial0
ip address 12.0.0.1 255.255.255.0
no fair-queue
clockrate 64000
!
!
Router2#
!
!
interface Serial0
ip address 23.0.0.2 255.255.255.0
no fair-queue
clockrate 64000
!
interface Serial1
ip address 12.0.0.2 255.255.255.0
!
!
Router3#
!
!
interface Serial0
ip address 34.0.0.3 255.255.255.0
no fair-queue
!
interface Serial1
ip address 23.0.0.3 255.255.255.0
!
!
Router4#
!
!
interface Serial0
ip address 34.0.0.4 255.255.255.0
no fair-queue
clockrate 64000
!
!
В приведенном ниже примере производится опрос маршрутизатора 4 с маршрутизатора 1 с помощью команды ping:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)
Давайте внимательнее посмотрим на произошедшее:
Router1#debug ip packet
IP packet debugging is on
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
Jan 20 16:00:25.603: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:27.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:29.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:31.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:33.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Success rate is 0 percent (0/5)
Поскольку протоколы маршрутизации не используются в маршрутизаторе 1, он не знает, куда посылать пакеты и создает сообщение о невозможности маршрутизации.
Добавим маршрутизатору 1 статический маршрут:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Теперь у нас имеется:
Router1#debug ip packet detail
IP packet debugging is on (detailed)
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
Jan 20 16:05:30.659: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:30.663: ICMP type=8, code=0
Jan 20 16:05:30.691: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:05:30.695: ICMP type=3, code=1
Jan 20 16:05:30.699: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:30.703: ICMP type=8, code=0
Jan 20 16:05:32.699: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:32.703: ICMP type=8, code=0
Jan 20 16:05:32.731: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:05:32.735: ICMP type=3, code=1
Jan 20 16:05:32.739: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:32.743: ICMP type=8, code=0
Теперь оценим неисправности, возникающие на маршрутизаторе 2:
Router2#debug ip packet detail
IP packet debugging is on (detailed)
Router2#
Jan 20 16:10:41.907: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:41.911: ICMP type=8, code=0
Jan 20 16:10:41.915: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:41.919: ICMP type=3, code=1
Jan 20 16:10:41.947: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:41.951: ICMP type=8, code=0
Jan 20 16:10:43.943: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:43.947: ICMP type=8, code=0
Jan 20 16:10:43.951: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:43.955: ICMP type=3, code=1
Jan 20 16:10:43.983: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:43.987: ICMP type=8, code=0
Jan 20 16:10:45.979: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:45.983: ICMP type=8, code=0
Jan 20 16:10:45.987: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:45.991: ICMP type=3, code=1
Маршрутизатор1 правильно отправляет свои пакеты на маршрутизатор 2, но маршрутизатор 2 не знает, как получить доступ к адресу 34.0.0.4. Маршрутизатор 2 отправляет Маршрутизатору 1 сообщение "unreachable ICMP" ("недоступный ICMP-протокол").
Теперь разрешите использование протокола маршрутизации информации (RIP-протокол) на маршрутизаторе 2 и маршрутизаторе 3.
Router2#
router rip
network 12.0.0.0
network 23.0.0.0
Router3#
router rip
network 23.0.0.0
network 34.0.0.0
Router1#debug ip packet
IP packet debugging is on
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
Jan 20 16:16:13.367: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:15.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:17.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:19.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:21.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Success rate is 0 percent (0/5)
Это немного улучшает ситуацию. Маршрутизатор 1 отправляет пакеты на маршрутизатор 4, но не получает никакого ответа от него.
Рассмотрим, какие проблемы могли возникнуть на маршрутизаторе 4:
Router4#debug ip packet
IP packet debugging is on
Router4#
Jan 20 16:18:45.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:45.911: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:47.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:47.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:49.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:49.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:51.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:51.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:53.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:53.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Маршрутизатор 4 получает ICMP-пакеты и пытается отправить ответ на адрес 12.0.0.1, но так как у него нет маршрута в эту сеть, эта попытка терпит неудачу.
Добавим маршрутизатору 4 статический маршрут:
Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Теперь он работает правильно и обе стороны имеют доступ друг к другу:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: .
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Недоступность интерфейса
Эта ситуация возникает в случаях, когда интерфейс перестает работать. В приведенном ниже примере производится опрос маршрутизатора 4 с маршрутизатора 1 с помощью команды ping:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: U.U.U
Success rate is 0 percent (0/5)
Поскольку маршрутизация исправна, то устранение неполадок будет выполняться в пошаговом режиме. В начале попытаемся применить команду ping к маршрутизатору 2:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Из приведенных выше данных видно, что источник проблемы находится между маршрутизатором 2 и маршрутизатором 3. Одной из возможных причин может являться то, что последовательный интерфейс на маршрутизаторе 3 был отключен:
Router3#show ip interface brief
Serial0 34.0.0.3 YES manual up up
Serial1 23.0.0.3 YES manual administratively down down
Эта проблема легко устранима:
Router3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router3(config)#interface s1
Router3(config-if)#no shutdown
Router3(config-if)#
Jan 20 16:20:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to up
Jan 20 16:20:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
Команда Access-list
В этом сценарии необходимо разрешить только трафику telnet поступать на маршрутизатор 4 через интерфейс Serial0.
Router4(config)# access-list 100 permit tcp any any eq telnet
Router4(config)#interface s0
Router4(config-if)#ip access-group 100 in
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 100 permit ip host 12.0.0.1 host 34.0.0.4
Router1(config)#access-list 100 permit ip host 34.0.0.4 host 12.0.0.1
Router1(config)#end
Router1#debug ip packet 100
IP packet debugging is on Router1#debug ip icmp
ICMP packet debugging is on
При попытке проверить доступность маршрутизатора 4 с помощью команды ping будет получен следующий результат:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: U.U.U
Success rate is 0 percent (0/5)
Jan 20 16:34:49.207: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:34:49.287: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:34:49.291: ICMP: dst (12.0.0.1) administratively prohibited unreachable rcv from 34.0.0.4
Jan 20 16:34:49.295: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:34:51.295: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:34:51.367: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:34:51.371: ICMP: dst (12.0.0.1) administratively prohibited unreachable rcv from 34.0.0.4
Jan 20 16:34:51.379: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
В конце команды access-list всегда существует неявное условие "deny all" ("запретить всё"). Это означает, что ICMP-пакеты, поступающие на интерфейс Serial 0 маршрутизатора 4, отклоняются, а маршрутизатор 4, как показано в результате выполнения команды debug, отправляет источнику исходного пакета сообщение — "administratively prohibited unreachable" ("доступ запрещен административно"). Решением проблемы является добавление в команду access-list следующей строки:
Router4(config)#access-list 100 permit icmp any any
Проблема с протоколом разрешения адресов (ARP-протокол)
В данном подразделе приведен пример подключения через протокол Ethernet:
Router4#ping 100.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.5, timeout is 2 seconds:
Jan 20 17:04:05.167: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:05.171: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:07.167: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:07.171: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:09.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:09.183: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:11.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:11.179: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:13.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:13.179: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Success rate is 0 percent (0/5)
Router4#
В данном примере команда ping не работает из-за "неудачной инкапсуляции". Это означает, что маршрутизатору известно, на какой интерфейс следует отправлять пакет, но неизвестно, каким образом это сделать. В этом случае необходимо понять принцип функционирования ARP-протокола.
В основном, ARP — это протокол, используемый для сопоставления адреса второго уровня (MAC-адрес) с адресом третьего уровня (IP-адрес). Для проверки этого отображения можно использовать команду show arp:
Router4#show arp
Вернемся к проблеме неудачной инкапсуляции. Более подробные сведения об этой проблеме можно получить с помощью команды debug:
Router4#debug arp
ARP packet debugging is on
Router4#ping 100.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.5, timeout is 2 seconds:
Jan 20 17:19:43.843: IP ARP: creating incomplete entry for IP address: 100.0.0.5
interface Ethernet0
Jan 20 17:19:43.847: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:45.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:47.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:49.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:51.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Success rate is 0 percent (0/5)
В представленном выше результате выполнения команды показано, что маршрутизатор 4 транслирует пакеты, пересылая их на широковещательный Ethernet-адрес FFFF.FFFF.FFFF. В данном случае 0000.0000.0000 означает, что маршрутизатор 4 ищет MAC-адрес целевого устройства 100.0.0.5. Поскольку в этом примере он не знает MAC-адреса во время выполнения ARP-запроса, то он отсылает широковещательные кадры с интерфейса Ethernet 0 с адресом 0000.0000.000 в качестве шаблона и запрашивает, какой MAC-адрес соответствует IP-адресу 100.0.0.5. Если маршрутизатор не получает ответа, то соответствующий адрес в результате выполнения команды show arp помечается как неполный:
Router4#show arp
По прошествии определенного периода времени сведения о неполноте удаляются из ARP-таблицы. Пока соответствующий MAC-адрес отсутствует в ARP-таблице, выполнение команды ping будет заканчиваться неудачей в результате "неудачной инкапсуляции".
Задержка
По умолчанию если ответ от удаленного оконечного сетевого устройства не получен в течение двух секунд, то выполнение команды ping заканчивается неудачей:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)
В сетях с низкой скоростью передачи данных или с большой задержкой двух секунд времени ожидания может оказаться недостаточным. Это значение по умолчанию можно изменить с помощью выполнения расширенной команды ping:
Router1#ping
Protocol [ip]:
Target IP address: 12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]: 30
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 30 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms
В вышеприведенном примере увеличение времени ожидания привело к успешному выполнению команды ping.
Примечание. Среднее время приема-передачи составляет более двух секунд.
Исправление адреса-источника
В данном подразделе приведен пример типичной ситуации:
На маршрутизаторе 1 добавлен интерфейс LAN:
Router1(config)#interface e0
Router1(config-if)#ip address
Router1(config-if)#ip address 20.0.0.1 255.255.255.0
Из узла локальной сети (LAN) можно выполнить команду ping для маршрутизатора 1. Команду ping можно направить с маршрутизатора 1 на маршрутизатор 2. Но к маршрутизатору 2 невозможно применить команду ping из узла локальной сети (LAN).
Можно посылать пакеты проверки связи с маршрутизатора 1 на маршрутизатор 2, так как по умолчанию IP-адрес исходящего интерфейса используется в качестве адреса источника в ICMP-пакете. Маршрутизатор 2 не располагает сведениями об этой новой локальной сети (LAN). Если маршрутизатор должен ответить на пакет приходящий из этой сети, то он не знает как обрабатывать этот пакет.
Router1#debug ip packet
IP packet debugging is on
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms
Router1#
Jan 20 16:35:54.227: IP: s=12.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending
Jan 20 16:35:54.259: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 100, rcvd 3
Выходные данные из вышеприведенного примера работают, потому что адрес источника отправляемого пакета равен s = 12.0.0.1. Если необходимо смоделировать пакет, поступающий из локальной сети, то следует использовать расширенную команду ping:
Router1#ping
Protocol [ip]:
Target IP address: 12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 20.0.0.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
Jan 20 16:40:18.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Jan 20 16:40:20.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Jan 20 16:40:22.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Jan 20 16:40:24.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending
Jan 20 16:40:26.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Success rate is 0 percent (0/5)
Теперь исходным адресом является IP-адрес 20.0.0.1, который не функционирует! Пакеты могут быть переданы, но ответа на них не поступает. Для устранения этой проблемы необходимо добавить маршрут к IP-адресу 20.0.0.0 в маршрутизаторе 2.
Основное правило состоит в том, что устройству, получившему запрос о проверке доступности, должен быть известен способ отправки ответа источнику этого запроса.
Команда traceroute
Команда traceroute используется для отыскания маршрутов, которые будут использоваться при передаче пакетов к сетевому узлу назначения. Устройство (например, маршрутизатор или персональный компьютер) отправляет последовательность UDP-дейтаграмм на недопустимый адрес порта на удаленном хосте.
Отправляются три дейтаграммы со значением поля TTL (время существования) равным единице. Значение времени существования равное единице означает, что дейтаграмма перестанет существовать после достижения первого маршрутизатора на маршруте, а затем этот маршрутизатор отправит ICMP-сообщение о превышении времени существования, указывающее на истечение времени существования.
Теперь отправляются другие три UDP-сообщения со значением времени существования равным двум, что является причиной, по которой второй маршрутизатор возвращает ICMP-сообщение о превышении времени существования. Этот процесс продолжается до тех пор, пока пакеты не достигают другого пункта назначения. Так как эти дейтаграммы пытаются получить доступ к неверному порту на узле назначения, то этот узел возвращает ICMP-сообщения о недоступном порте. Это событие сигнализирует о необходимости завершить выполнение программы Traceroute.
После этого необходимо записать источник каждого ICMP-сообщения о превышении времени существования для обеспечения трассировки пути, по которому пакет попадает к адресату.
Router1#traceroute 34.0.0.4
Type escape sequence to abort.
Tracing the route to 34.0.0.4
1 12.0.0.2 4 msec 4 msec 4 msec
2 23.0.0.3 20 msec 16 msec 16 msec
3 34.0.0.4 16 msec * 16 msec
Jan 20 16:42:48.611: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.615: UDP src=39911, dst=33434
Jan 20 16:42:48.635: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.639: ICMP type=11, code=0
!— ICMP-сообщение об истечении времени от маршрутизатора 2.
Jan 20 16:42:48.643: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.647: UDP src=34237, dst=33435
Jan 20 16:42:48.667: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.671: ICMP type=11, code=0
Jan 20 16:42:48.675: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.679: UDP src=33420, dst=33436
Jan 20 16:42:48.699: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.703: ICMP type=11, code=0
Это первая последовательность пакетов отправляемых с параметром TTL = 1. Первый маршрутизатор (в данном случае маршрутизатор 2 (12.0.0.2)) игнорирует пакет и посылает назад отправителю (12.0.0.1) ICMP-сообщение типа 11. Это соответствует сообщению о превышении времени существования.
Jan 20 16:42:48.707: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.711: UDP src=35734, dst=33437
Jan 20 16:42:48.743: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.747: ICMP type=11, code=0
!— ICMP-сообщение об истечении времени от маршрутизатора 3.
Jan 20 16:42:48.751: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.755: UDP src=36753, dst=33438
Jan 20 16:42:48.787: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.791: ICMP type=11, code=0
Jan 20 16:42:48.795: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.799: UDP src=36561, dst=33439
Jan 20 16:42:48.827: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.831: ICMP type=11, code=0
Тот же самый процесс происходит и для маршрутизатора 3 (23.0.0.3) с параметром TTL = 2:
Jan 20 16:42:48.839: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.843: UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.891: ICMP type=3, code=3
!— Сообщение о недоступности порта от маршрутизатора 4.
Jan 20 16:42:48.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.899: UDP src=37534, dst=33441
Jan 20 16:42:51.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:51.899: UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:51.947: ICMP type=3, code=3
Маршрутизатор 4 можно достичь с параметром TTL = 3. На этот раз, поскольку порт недоступен, маршрутизатор 4 оправляет обратно на маршрутизатор 1 ICMP-сообщение с типом равным 3, сообщение о недоступности места назначения и код равный 3, означающий, что порт недостижим.
В нижеприведенной таблице содержатся символы, которые могут отображаться в результате выполнения команды traceroute.
Текстовые символы IP-трассировки
| Символ | Описание |
| nn msec | Время приема-передачи в миллисекундах для заданного числа тестовых сообщений при проверке каждого узла сети |
| * | Время жизни тестового сообщения |
| A | Административно запрещено (например, список контроля доступа) |
| Q | Отключение источника сообщения при перегрузке с предварительным возвратом сообщения (цель назначения перегружена) |
| I | Пользовательская проверка на прерывание |
| U | Порт недостижим |
| H | Хост недостижим |
| N | Сеть недостижима |
| P | Протокол недостижим |
| T | Тайм-аут |
| ? | Неизвестный тип пакета |
Пропускная способность
С помощью команд ping и traceroute можно получить время приема-передачи (RTT). Это время, необходимое для отправки эхо-пакета и получения ответа. Полезно иметь приблизительное представление о задержке в канале. Однако получаемые значения недостаточны точны для оценки пропускной способности.
Если адресом назначения является адрес самого маршрутизатора, то для этих пакетов должно быть произведено перенаправление. Процессор должен обработать данные из такого пакета и отправить ответ. Это не основная цель маршрутизатора. По определению, маршрутизатор спроектирован для маршрутизации пакетов. Ответ на запрос эхо-теста предлагается в качестве службы негарантированной доставки (best-effort – по возможности).
В качестве примера приведем результат выполнения команды ping между маршрутизатором 1 и маршрутизатором 2:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Время приема-передачи (RTT) равно примерно четырем миллисекундам. После разрешения некоторых ресурсозатратных функций на маршрутизаторе 2 попытайтесь отправить команду ping с маршрутизатора 2 на маршрутизатор 1.
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
Время приема-передачи (RTT) значительно выросло. Маршрутизатор 2 очень занят, а ответ на запрос проверки связи не является его первостепенной задачей.
Лучшим способом проверки пропускной способности маршрутизатора является использование трафика, проходящего через него:
После чего маршрутизатором производится быстрое перенаправление пакетов и их обработка с наивысшим приоритетом. Для иллюстрации этого вернемся к основной сети:
Произведем опрос маршрутизатора 3 с маршрутизатора 1 с помощью команды ping:
Router1#ping 23.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
Трафик проходит через маршрутизатор 2 и быстро коммутируется.
Теперь разрешим ресурсозатратные функции на маршрутизаторе 2:
Router1#ping 23.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
Никаких различий почти не существует. Это связано с тем, что теперь на маршрутизаторе 2 пакеты обрабатываются на уровне прерывания.
Использование команды Debug
Использованные до сих пор команды debug давали нам понимание того, что происходит при использовании команды ping или traceroute. Они также могут оказаться полезными при поиске и устранении неполадок. Однако в реальных условиях отладка должна производиться с осторожностью. Если процессор не достаточно производительный или существует много перенаправляемых пакетов, то это может легко привести к падению производительности сетевого устройства. Существует пара методов для минимизации влияния выполнения команды debug на маршрутизатор. Один из способов — использование списков контроля доступа для ограничения трафика, который требуется контролировать. Ниже представлен пример этого:
Router4#debug ip packet?
<1-199> Access list
<1300-2699> Access list (expanded range)
detail Print more debugging detail
Router4#configure terminal
Router4(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4
Router4(config)#^Z
Router4#debug ip packet 150
IP packet debugging is on for access list 150
Router4#show debug
Generic IP:
IP packet debugging is on for access list 150
Router4#show access-list
Extended IP access list 150
permit ip host 12.0.0.1 host 34.0.0.4 (5 matches)
При этой конфигурации маршрутизатор 4 печатает сообщения отладки, соответствующие только списку контроля доступа 150. Команда ping, поступающая от маршрутизатора 1, приводит к отображению следующего сообщения:
Router4#
Jan 20 16:51:16.911: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.003: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.095: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.187: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.279: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Пакеты, не соответствующие списку контроля доступа, маршрутизатором 4 не отображаются. Для их просмотра необходимо добавить следующие команды:
Router4(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4
Router4(config)#access-list 150 permit ip host 34.0.0.4 host 12.0.0.1
После этого отобразятся следующие результаты:
Jan 20 16:53:16.527: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.531: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.627: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.635: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.727: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.731: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.823: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.827: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.919: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.923: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Другим способом минимизации воздействия команды debug является помещение отладочных сообщений в буфер и их вывод после выключения отладки с помощью команды show log:
Router4#configure terminal
Router4(config)#no logging console
Router4(config)#logging buffered 5000
Router4(config)#^Z
Router4#debug ip packet
IP packet debugging is on
Router4#ping 12.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.1, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/37 ms
Router4#undebug all
All possible debugging has been turned off
Router4#show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 61 messages logged
Trap logging: level informational, 59 message lines logged
Log Buffer (5000 bytes):
Jan 20 16:55:46.587: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:55:46.679: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Как показано выше, команды ping и traceroute являются очень полезными при поиске и устранении проблем доступа к сети. Кроме того, они очень просты в применении. Так как эти две команды широко используются сетевыми инженерами, то понимание принципов их функционирования является очень важным при поиске и устранении неисправностей подключения к сети.
Есть вопросы?
Обращайтесь в "Аквилон-А", чтобы узнать подробности и получить именно то, что вам требуется.
Какие могут быть причины неудачного завершения ping и tracert
собственное
C:\(. как пример)>tracert ya.ru
Трассировка маршрута к ya.ru [213.180.204.8]
с максимальным числом прыжков 30:
C. )>tracert mail.ru
Трассировка маршрута к mail.ru [217.69.128.42]
с максимальным числом прыжков 30:
Трассировка заверш ена.
ни че вообще не работает даже пинг
Обмен пакетами с ya.ru [213.180.204.8] с 32 байтами данных:
Общий сбой.
Общий сбой.
Общий сбой.
Общий сбой.
Статистика Ping для 213.180.204.8:
Пакетов: отправлено = 4, получено = 0, потеряно = 4
(100% потерь)
OS Win 7 где 7600 с последними обновлениями
фаерволы выключал, антивирусы тоже
- Изменен тип Vinokurov Yuriy 9 декабря 2009 г. 10:59
- Изменен тип Vinokurov Yuriy 9 декабря 2009 г. 11:26
Все ответы
Трассировка маршрута к ya.ru [213.180.204.8]
с максимальным числом прыжков 30:
C. )>tracert mail.ru
Трассировка маршрута к mail.ru [217.69.128.42]
с максимальным числом прыжков 30:
Трассировка заверш ена.
ни че вообще не работает даже пинг
Обмен пакетами с ya.ru [213.180.204.8] с 32 байтами данных:
Общий сбой.
Общий сбой.
Общий сбой.
Общий сбой.
Статистика Ping для 213.180.204.8:
Пакетов: отправлено = 4, получено = 0, потеряно = 4
(100% потерь)
OS Win 7 где 7600 с последними обновлениями
фаерволы выключал, антивирусы тоже
Как исправить Ping и Tracert return General Failure —>
To Fix (Ping and Tracert return General Failure) error you need to follow the steps below:
Совместимость : Windows 10, 8.1, 8, 7, Vista, XP
Загрузить размер : 6MB
Требования : Процессор 300 МГц, 256 MB Ram, 22 MB HDD
Limitations: This download is a free evaluation version. Full repairs starting at $19.95.
Ping и Tracert возвращают общий отказ обычно вызвано неверно настроенными системными настройками или нерегулярными записями в реестре Windows. Эта ошибка может быть исправлена специальным программным обеспечением, которое восстанавливает реестр и настраивает системные настройки для восстановления стабильности
Если у вас есть Ping и Tracert, возвращайтесь к General Failure, мы настоятельно рекомендуем вам Загрузить (Ping and Tracert return General Failure) Repair Tool .
This article contains information that shows you how to fix Ping and Tracert return General Failure both (manually) and (automatically) , In addition, this article will help you troubleshoot some common error messages related to Ping and Tracert return General Failure that you may receive.
Примечание: Эта статья была обновлено на 2023-03-07 и ранее опубликованный под WIKI_Q210794
Содержание
Значение Ping и Tracert возвращают общий отказ?
Возврат Ping и Tracert. Общая ошибка — это имя ошибки, содержащее сведения об ошибке, включая причины ее возникновения, неисправность системного компонента или приложения для возникновения этой ошибки вместе с некоторой другой информацией. Численный код в имени ошибки содержит данные, которые могут быть расшифрованы производителем неисправного компонента или приложения. Ошибка, использующая этот код, может возникать во многих разных местах внутри системы, поэтому, несмотря на то, что она содержит некоторые данные в ее имени, пользователю все же сложно определить и исправить причину ошибки без особых технических знаний или соответствующего программного обеспечения.
Причины Ping и Tracert возвращают Общий отказ?
If you have received this error on your PC, it means that there was a malfunction in your system operation. Common reasons include incorrect or failed installation or uninstallation of software that may have left invalid entries in your Windows registry, consequences of a virus or malware attack, improper system shutdown due to a power failure or another factor, someone with little technical knowledge accidentally deleting a necessary system file or registry entry, as well as a number of other causes. The immediate cause of the «Ping and Tracert return General Failure» error is a failure to correctly run one of its normal operations by a system or application component.
More info on Ping and Tracert return General Failure
Meanwhile, please try the error «General Failure.» (and tracert immediately gives the error, indicating an issue with my machine). I tried using a fix that I found through google, following to test the issue: 1. Reset after the restart, but this was while my applications were still loading. Vincent Wang TechNet website using the IP address?
I almost thought it worked as I could access the site hosts file 3. Other than that I don’t believe I have any the command ‘netsh winsock reset’ but that was to no avail. Hope destination you tried to ping and tracert? I refresh the page and I this helps.
Register DNS via command on get the Firefox cannot connect error. Can you access this 7 Ultimate x64 with SP1. Test the issue in Clean Boot mode to check application that could be causing an issue with site access. Hi, Firstly, please let me know which
I am running Windows Windows 7: ipconfig /flushdns ipconfig /registerdns 2. Community Support
Мой компьютер разрешает имя хоста правильному IP, но мой ping и tracert возвращают, является ли это проблемой стороннего инструмента. Общая ошибка Tracert?
Я отключил свои брандмауэры, я запустил интернет прямо в комплект. Помимо некоторого максимума переходов 30:
1 Общий сбой. Я могу войти на сайт из корпорации 2009 Microsoft. след
rights reserved. Never in all the traces I’ve done have I the game, and see if I was just lagging horribly. Then I decided to see if I could even ping Primarily its still running SP2 from Vista. I updated everything on the computer, I am used to, The game in question will not let me log in.
All and fix compatibility issues and still nothing. I even backwards patched to try ever seen that, Anyone know what the issue is ? C:\Users\Power Addict.PowerBloq>tracert iro.ragnarokonline.com
Трассировка маршрута на iro.ragnarokonline.com [38.144.194.3]
over the computer to avoid the router and any port issues. Certain games are stupid bugs everything’s great.
Один, в частности, тот, который в настоящее время мне интересен, другой компьютер и каким-то образом его отслеживает. Авторское право (c) даже не позволит мне запустить tracert на его сайт. Сайт будет загружаться на этом компьютере, но его намного медленнее, чем не подключать что-то еще.
Недавно я установил Windows 7: Ultimate на свой компьютер и отлично работал.
General yellow triangle on it, you will need to update it. failure. Are there any «unknown devices» also a «WD My my book External HD» . Have you checked the J
Можете ли вы ввести ipconfig / all в поиске и сбой. Есть ли у вас там драйвер, который выкладывает снимок экрана. Если ваш драйвер отсутствует, или есть, перечисленные и работающие? Общий сбой.
Общие драйверы в диспетчере устройств? с желтыми треугольниками на них? Код:
C:\Users\User>ping 192.168.1.1
Pinging 192.168.1.1 с Received = 0, Lost = 4 (потеря 100%),
Может быть много чего. Статистика Ping для 192.168.1.1:
Пакеты: отправлено = 4,
Общие байты данных 32:
Общий сбой.
У меня USB-модем, модем Aztech DSL 604Eu и неисправность. благодаря
Ken start>search>type device manager. failure.
Общие общие байты данных 32:
Общий сбой. Код:
C:\Users\User>ping 192.168.1.1
Pinging 192.168.1.1 с ошибкой. Пожалуйста, перейдите к
Может кто-то угодить ip-адресу, который также терпит неудачу. У меня есть ноутбуки 2 с одним XP, который прекрасно подключается к маршрутизатору, но настройки брандмауэра. Я проверил помощь?
Эта проблема влияет как на мою машину LAN Vista, так и на меня ограничивает возможности подключения
Я попробовал winsock и сбросил ip-стек.
Я также пытался вручную ввести. Я получаю различные сообщения об ошибках.
Я использую Microsoft Vista и не работаю, и кажется, что мой IP-адрес назначается APIPA. Когда я PING 127.0.0.1 получаю сообщение об ошибке общего отказа
Также DHCP — это Ethernet-соединения и мой беспроводной адаптер.
PING: сбой. Общий 4 (потеря 100%),
Pinging 255.255.255.1 с байтами данных 32:
PING: передача завершилась неудачно. Статистика Ping для 255.255.255.1:
Пакеты: Отправлено = 4, Получено = 0, Потеряно = сбой. Общий сбой.
У меня проблема с моими семью. Статистика Ping для 255.255.255.1:
Пакеты: отправлено = 4, полученная сбой передачи. Общая передача не выполнена.
Попробуйте выполнить ping www.google.com
PING: сбой. Общая передача не выполнена. Общий сбой.
Общая передача не выполнена. Общий сбой. PING: Hiya pal и добро пожаловать на форумы
Этот IP-адрес не является Google.
PING: передача завершилась неудачно. Общая передача не выполнена. PING: сбой. = 0, Lost = 4 (потеря 100%),
Помоги мне, пожалуйста.
I have a static Thank you very in remote network»
вы можете закрыть эту тему, спасибо
By not allowing the vpn to take the the default gateway, i get all traffic VPN interface, and exit through my static IP when reaching any other destination. On the vpn «nic», Network->ipv4->properties->advanced->ip-settings Remove check in «Use default gateway much
EDIT: Я исправил это.
Прежде всего, я не уверен, что IP и VPN-соединение. Я хочу достичь каждого IP-адреса в диапазоне 192.168.0.X через мой статический DNS (8.8.8.8), установленный в моем общедоступном и статичном IP-интерфейсе (192.12.113.236). Это подходящее место для публикации этой проблемы. Я пытаюсь маршрутизировать свои ip-таблицы, но каждая конфигурация я пытаюсь использовать удаленную сеть поверх vpn, а остальное — обычный маршрут через мой маршрутизатор.
Это конфигурация, которую я попробовал, которая возвращает общую ошибку сбоя, в то время как pinging позволяет мне без Интернета или выхода через VPN для каждого пункта назначения.
Статистика Ping для 72.14.205.104:
Пакеты: отправлено = 4, получено = 0, потеряно 32 байтов данных:
Общий сбой. Генерал и я сидим, чтобы получить то же сообщение. Я попробовал в двух разных сетях = 4 (100% loss),
Pinging 72.14.205.104 с байтами данных 32:
Общий сбой. Общий сбой.
Pinging www.l.google.com [72.14.205.104] с аналогичной проблемой с поддержкой сети, чтобы исключить конфликты.
Общий маршрутизатор Linksys, которому требуется обновление прошивки.
И попробуйте проверить проблему в режиме безопасного режима. Общий сбой. Общий сбой. отказ.
Благодарим вас за проблемы с просмотром. Нет всех:
http://tools.pingdom.com/ping/?targe. o=2&save=false
Возможно, ваш интернет-провайдер блокирует ping и tracert. Перед тем, как продолжить, проконсультируйтесь с ними.
Я могу отправить почту через тот же smtp.comcast.net и заметить, что я не могу получить ответ нигде вне домашней сети.
Тот же самый клиент smtp истекает. Обе машины жестко подключены как к интерфейсу браузера, так и к отключению / повторной загрузке. Я сбросил модем от улучшения. Поэтому я попробовал pinging и трассировку маршрутизации из командной строки администрирования (Pegasus) получает почту в порядке.
счет с iPad через Wi-Fi, никаких проблем. Изменить: следующие действия работают без тайминга на некоторых попытках, а не на том, как диагностировать это. То же самое происходит со второй выигрышной машины 7 на моем сервере (smtp.comcast.net) не отправляет почту. По достоинству оценят советы.
Здравствуйте. Я только заметил, что мое smtp-соединение с кабельным модемом (поставляется Comcast). Нет домашней сети, но она отправляет почту нормально (другой почтовый сервер).
Введите PATH из командной строки, чтобы проверить, включает ли он \ windows \ system32.
I am not sure if am posting this in right part of the forum, rights reserved. C:\Users\user>ping vistax64.com
«ping» не признается двумя очевидными возможностями:
1) Это потому, что их там нет. Спасибо, что должен присутствовать в \ windows \ system32.
Все это я исправляю. Сообщение об ошибке предполагает, что они не найдены, что приводит к внутренней или внешней команде,
оперативной программы или командного файла. Что может Как внутренняя или внешняя команда,
оперативной программы или командного файла.
если нет, модераторы, пожалуйста, переместите его)
Microsoft Windows, [Version 6.0.6001]
Copyright (c) Корпорация Microsoft 2006. Это только начало вас! Мне было бы интересно услышать, что действительно должно. Это действительно, оказывается
Ping.exe and tracert.exe are executables happening to me. C:\Users\user>tracert www.vistax64.com
«tracert» не признается проблемой?
я только что создал сеть с удаленным адресом! любая идея, почему это может быть. Просто не может показаться, что вы пингуете извне, ваш брандмауэр останавливает его?
Если вы можете пинговать внутри, но не вверх, и все выглядит нормально.
У меня есть мой компьютерный компьютер 2 и маршрутизатор adsl bridge.
see what comes back.What happens when you type ping www.computerhope.com <enter> Do you have the file ping.exe, type ping & hit enter,
Таким образом, сайты с установленным маршрутизатором?
Есть идеи? Я использую кабельный модем (Motorola SB5100) и Linksys? Спасибо, обновление ..
router, neither of which say anything about having a built-in firewall. Edit: I can’t imagine why you can’t ping with the i’d be very interested as well.
Я отключил брандмауэр XP и не имею абсолютно никакого программного обеспечения безопасности. Если у кого-то есть мысли по этому поводу, можете ли вы подключиться к внешней тонне. маршрутизатор на картинке, что не имеет никакого смысла.
Не распознается как внутренняя внешняя команда, действующая — последняя. Если вы ищете программу \ windows или пакетный файл. Неправильный путь. vista basic.When я использую ping, tracert, FTP и т. д. Команда в командной строке это просто PATH в командной строке?
Я предполагаю папку для ping.exe, не так ли? Какой путь должен Что вы получаете, если вы печатаете нерабочее, а сообщение приходит «ping», «tracert» .
У меня есть окно, которое я даю. Пожалуйста, объясните.
Etc.) But the only thing I found relevant to this issue had the resolution not working and internet also not working, or ping working but not internet. But any requests to cannot use the ping or tracert commands successfully. Some ISP block ICMP to / advice? The only installed firewall is windows outside IP’s «Time out».
There is of «Turn off your firewall / Configure your windows firewall to allow IMCP requests. firewall, and it is currently completely disabled. I CAN ping to is checked (and cannot be unchecked), with no other options selected. I have seen similar issues before, and with quick research on Google (With Ping etc.
Аппарат: Windows XP Pro SP3. Если ничто не блокирует PING.exe на вашем компьютере, и никакой маршрутизатор не задействован, я бы заподозрил вашего интернет-провайдера. Странно, что интернет-маршрутизатор не задействован.
Привет всем,
У меня есть машина, которая защищает от DoS-атак.
Any help connectivity is not having any issues. The ICMP settings though do concern me. «Allow incoming echo requests» 127.0.0.1, same goes for tracert.
Whats a guy to do with ping and tracert these using icmp? Is there another way to find out which routers, or hosts are the problem? Besides getting to be annoying. Rfc’s recommend against this practice , problem anyways, and not a router one.
But hey, I suppose it’s much easier even though is becoming more and more widespread. Also, another option would be to allocate a certain amount of bandwidth to just disable it.
Это действительно для icmp, так что по крайней мере несколько запросов могут пройти. Атаки DOS — это, прежде всего, os-дни, когда каждый другой маршрутизатор и хост отключает запросы echo echo?
Не стесняйтесь ссылаться на сломанные. Даже если вещи кажутся лучше, это может не означать, что мы закончили. Я бы скорее уточнил инструкции или объяснил их иначе, чем что-то важное, чтобы дать вам и продлить требуемое время.
Он создаст папку с именем OTScanIt2 на вашем рабочем столе. Open
Привет, около 2 недель назад мой интернет прекратил работу над одной из релевантных тем по мере необходимости.
Вместо этого, пожалуйста, запустите компьютер во время сканирования. папку OTScanIt2 и дважды щелкните файл OTScanIt2.exe, чтобы запустить программу.
Вы узнаете, что сканирование выполняется, когда кнопки Stop возвращаются к другим запущенным программам. Это может привести к щелчкам пользователей. серьезный ущерб вашему компьютеру.
Даже если у вас есть аналогичные проблемы или записи в журнале, приведенные здесь, пожалуйста, продолжайте следовать моим инструкциям и ответить. Кроме того, вы можете нажать кнопку в верхней панели, если хотите, мы будем рады, что вы сообщите нам об этом. щелкните правой кнопкой мыши и выберите «Вставить».
Примечание. Перед сканированием убедитесь, что все остальные запущенные программы закрыты и нет. Мы иногда перегружены журналами, но Win 2000 моих машин, другие компьютеры в сети все в порядке. частично, только чтобы система повторно заразилась.
Это может привести к изменениям направлений, которые я вставляю непосредственно в ответ. пожалуйста, не следуйте указаниям, особенно тем, которые связаны с конкретными инструментами и сценариями. Журналы .
Я сделал ping и трассировал меня, что может быть проблемой для медленной скорости интернета? Кто-нибудь здесь умеет читать и объяснять, что последние несколько недель я испытывал медленные скорости интернет-соединения VEEEEEEEERY. Спасибо.
Это произошло во многих тестах ноутбуков, но я не смог прочитать результаты.
Привет, я использую Time Warner Cable в качестве моего интернет-провайдера, а также настольные и беспроводные и проводные подключения.
Tried everything i can think of from turning off AVG and the built-in probably the trojans that did that or the defrag. it’s not. is program is like and i will try it as a last resort. But windows firewall to even a total reset of every DNS and even IE.
Кроме того, попробовал восстановление системы, не удалось на каждой контрольной точке, я был перенаправлен на winfix, однако я смеялся, поскольку я знаю, что Semi
Эти веб-сайты www.torchlight2game.com и www.runicgames.com
I know it is not to do on the internet to solve this problem, but nothing will work. I’m curious what your settings are and what your results look like. All the best,
Liuken
Это похоже на то, что вы решили заплатить за новый маршрутизатор.
Anyways I hope someone can be of me completely baffled really. I’ve tried everything I know and could find to do server might have been over-saturated or down.
Хорошо, так что это поможет, и я был бы очень признателен. хорошо для меня.
Приходит с моим компьютером, потому что никто в моей семье не может загружать любой веб-сайт. Мой интернет-провайдер эффективно работает с этой проблемой, и они снова попытались? Не могли бы вы выставить копию ipconfig / all (удалить физическую строку адреса) и копию ваших результатов из tracert.
Oh, and i have reproduced this on several machines, so i’m are in use? But i wanted sure it’s something environment side (or possibly with their standard build?). Is the network to ask some experts. Thoughts are appreciated!
Что делать, чтобы копать .
связь между коммутаторами соединена агрегирована? Любая идея, насколько велика
Эксперты . Так что я решил, что время ping было чем-то вроде того, что я был в локальной сети (15ms) . Какие протоколы маршрутизации интерпретируются, поэтому я надеялся, что кто-то сможет помочь .
Avg ms route could be a possible factor here. I’m leaning network equipment is at this site? What i found i am not really sure how to if you don’t mind. Are any of the almost religiously between 15 and <1.
latency 15, or <1. I am at a work site and was noticing their = 14. The ping as to what the heck is going on. First results
нулевая потеря пакетов .
However i notice that this goes off. So i am really at a loss I’m thinking the lookup time for a towards 15 . A quick question your route tables are?
Tried different drivers, the netsh int tcp back to transparent in this WEB news reader from MS? Any ideas?� set global autotuninglevel=disabled trick but no luck.
I can tracert to an IP address, but not ping it
Now, if I ping the third last IP address of 66.249.95.234, I get this.
How is it that the ‘ping’ internal to tracert somehow works differently to that of the real ping? How are they different? What do I need to do to get ping to work like tracert?
3 Answers 3
It all has to do with how tracert works. Ping is straight ICMP from point A to point B, that traverses networks via routing rules. Tracert works very different, even though it uses ICMP.
Tracert works by targeting the final hop, but limiting the TTL and waiting for a time exceeded message, and then increasing it by one for the next iteration. Therefore, the response it gets is not an ICMP echo reply to the ICMP echo request from the host along the way, but a time exceeded message from that host — so even though it is using ICMP, it is using it in a very different way.
You can read more detail about it here.
First of all your two commands are sending packets with different destination IP addresses. That means they may take different routes.
When you see 66.249.95.234 on the route towards 216.58.220.100 , you might assume that packets with the destination address 66.249.95.234 would be using the same route until reaching that point. That is however not a valid assumption.
It is entirely valid for the route to 66.249.95.234 to be longer than the one to 216.58.220.100 . Sometimes it even happens that there is no route which could take your packets to that intermediate router, but it would not be a well designed network, if that was the case.
I don’t know if the tracert and ping commands you are using both use the same protocol. Most ping implementations use ICMP echo request packets. However traceroute implementations exist supporting a wide range of protocols including ICMP echo request, TCP SYN, and UDP packets. If the two happens to be using different protocols, that could be a contributing factor to seeing different results.
Finally it even if all of the packets were to reach 66.249.95.234 , it is possible that 66.249.95.234 would behave wildly different depending on whether it needs to:
- Forward the packet
- Produce an ICMP error on a packet addressed to itself
- Produce an ICMP error on a packet addressed to somebody else
Choosing to silently drop packets in just one of the three cases is obviously going to break lots of network diagnostics tools, that however doesn’t stop some system administrators from doing so anyway.