Use the Debug Command
Before you use debug commands, refer to Important Information on Debug Commands .
The different debug commands used in this article shows what happens when a ping or traceroute command is used. These commands can help you troubleshoot issues. However, in a production environment, debugs must be used with caution. If your CPU is not powerful, or if you have a lot of process-switched packets, they can easily stall your device. There are a couple of ways to minimize the impact of the debug command on the router. One way is to use access lists to narrow down the specific traffic that you want to monitor.
Here is an example:
With this configuration, Router4 only prints the debug message that matches the access-list 150. A ping from Router1 causes this message to display:
Router4#
Jan 20 16:51:16.911: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Jan 20 16:51:17.003: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Jan 20 16:51:17.095: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Jan 20 16:51:17.187: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Jan 20 16:51:17.279: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
The answer to the problem does not come from Router4 because these packets do not match the access-list. To see them, add:
Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34
Router4(config)#access-list 150 permit ip host 172.16.4.34 host 172.16.12.1
Jan 20 16:53:16.527: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.531: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
sending
Jan 20 16:53:16.627: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.635: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
sending
Jan 20 16:53:16.727: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.731: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
sending
Jan 20 16:53:16.823: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.827: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
sending
Jan 20 16:53:16.919: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
rcvd 3
Jan 20 16:53:16.923: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
sending
Another way to lower the impact of the debug command is to buffer the debug messages and display them with the show log command once the debug has been turned off:
The ping and traceroute commands are helpful utilities that you can use to troubleshoot network access problems. They are also very easy to use. These two commands are the widely used by network engineers.
Как сделать трассировку маршрута до сервера, сайта в OC Windows
Запускаем командную строку через меню «Пуск – Все программы – Стандартные». Или нажимаем сочетание клавиш «Win + R», появляется окно системной утилиты «Запуск программы», вводим: «cmd» и нажимаем «ок».
В командной строке вводим: «tracert» и адрес ресурса, который нужно проверить. Нажимаем «ввод». В результате трассировки мы узнаем, какие промежуточные узлы проходит пакет и время отклика. На основе этой информации можно понять, где проблема: у Вас, у интернет-провайдера, на одном из промежуточных узлов или на сервере сайта. Звездочки означают, что один из маршрутизаторов не хочет отвечать.
Звездочки не всегда означают проблему — на сервере может стоять файрволл, который блокирует «лишние» пакеты, а «реальные» пропускает и в браузере страница корректно открывается.
The Traceroute Command
Three datagrams are sent, each with a Time-To-Live (TTL) field value set to one. The TTL value of 1 causes the datagram to “timeout” as soon as it hits the first router in the path; this router then responds with an ICMP Time Exceeded Message (TEM) that indicates that the datagram has expired.
Another three UDP messages are now sent, each with the TTL value set to 2, which causes the second router to return ICMP TEMs. This process continues until the packets actually reach the other destination. Since these datagrams try to access an invalid port at the destination host, ICMP Port Unreachable Messages are returned, and indicates an unreachable port; this event signals the Traceroute program that it is finished.
The purpose behind this is to record the source of each ICMP Time Exceeded Message to provide a trace of the path the packet took to reach the destination.
Router1#traceroute 172.16.4.34
Введите escape-последовательность, чтобы прервать.
Отслеживание маршрута до 172.16.4.34
1 172.16.0.12 4 мс 4 мс 4 мс
2 10.0.3.23 20 мс 16 мс 16 мс
3 172.16.4.34 16 мс * 16 мс
20 января 16:42:48.611: IP: s=172.16.12.1 (локальный), d=172.16.4.34 (Serial0), длина 28,
отправка
20 января 16:42:48.615: UDP src=39911, dst=33434
20 января 16:42:48.635: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), длина 56,
RCVD 3
20 января 16:42:48.639: тип ICMP = 11, код = 0
!— Сообщение об истечении времени ICMP от Router2.
20 января 16:42:48.643: IP: s=172.16.12.1 (локальный), d=172.16.4.34 (Serial0), длина 28,
отправка
20 января 16:42:48.647: UDP src=34237, dst=33435
20 января 16:42:48.667: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), длина 56,
RCVD 3
20 января 16:42:48.671: тип ICMP = 11, код = 0
20 января 16:42:48.675: IP: s=172.16.12.1 (локальный), d=172.16.4.34 (Serial0), длина 28,
отправка
20 января 16:42:48.679: UDP src=33420, dst=33436
20 января 16:42:48.699: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), длина 56,
RCVD 3
20 января 16:42:48.703: тип ICMP=11, код=0
Это первая последовательность пакетов, отправленная с TTL=1. Первый маршрутизатор, в данном случае Router2 (172.16.0.12), отбрасывает пакет и отправляет обратно источнику (172.16.12.1) ICMP-сообщение type=11. Это соответствует сообщению об истечении времени.
20 января 16:42:48.707: IP: s=172.16.12.1 (локальный), d=172.16.4.34 (Serial0), длина 28,
отправка
20 января 16:42:48.711: UDP src=35734, dst=33437
20 января 16:42:48.743: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), длина 56,
RCVD 3
20 января 16:42:48.747: тип ICMP = 11, код = 0
!— Сообщение об истечении времени ICMP от Router3.
20 января 16:42:48.751: IP: s=172.16.12.1 (локальный), d=172.16.4.34 (Serial0), длина 28,
отправка
20 января 16:42:48.755: UDP src=36753, dst=33438
20 января 16:42:48.787: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), длина 56,
RCVD 3
20 января 16:42:48.791: тип ICMP = 11, код = 0
20 января 16:42:48.795: IP: s=172.16.12.1 (локальный), d=172.16.4.34 (Serial0), длина 28,
отправка
20 января 16:42:48.799: UDP src=36561, dst=33439
20 января 16:42:48.827: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), длина 56,
RCVD 3
20 января 16:42:48.831: тип ICMP=11, код=0
Тот же процесс происходит для Router3 (10.0.3.23) с TTL=2:
20 января 16:42:48.839: IP: s=172.16.12.1 (локальный), d=172.16.4.34 (Serial0), длина 28,
отправка
20 января 16:42:48.843: UDP src=34327, dst=33440
20 января 16:42:48.887: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), длина 56,
RCVD 3
20 января 16:42:48.891: тип ICMP = 3, код = 3
!— Сообщение Port Unreachable от Router4.
20 января 16:42:48.895: IP: s=172.16.12.1 (локальный), d=172.16.4.34 (Serial0), длина 28,
отправка
20 января 16:42:48.899: UDP src=37534, dst=33441
20 января 16:42:51.895: IP: s=172.16.12.1 (локальный), d=172.16.4.34 (Serial0), длина 28,
отправка
20 января 16:42:51.899: UDP src=37181, dst=33442
20 января 16:42:51.943: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), длина 56,
RCVD 3
20 января 16:42:51.947: тип ICMP=3, код=3
При TTL=3, наконец, достигнут Router4. На этот раз, поскольку порт недействителен, Router4 отправляет обратно Router1 сообщение ICMP с типом = 3, сообщением о недоступности места назначения и кодом = 3, означающим, что порт недоступен.
В следующей таблице перечислены символы, которые могут появляться в выводе команды traceroute.
Символы текста трассировки IP
Резюме
В этом документе показано, как команда traceroute определяет путь, который проходит пакет от заданного источника к заданному месту назначения с использованием пакетов UDP и ICMP. Возможные типы сообщений ICMP на выходе:
Примеры
Эта топология сети используется для примеров:
В каждом из трех примеров используется разное Устройство А. С устройства A команда traceroute 150.1.4.2 выполняется на устройстве 7C.
В каждом из примеров команда детали отладки ip-пакета выполняется на Устройстве 11A.
Маршрутизатор Cisco с ПО Cisco IOS
В этом примере расширенной команды traceroute показаны параметры, которые можно изменить при выполнении команды traceroute с маршрутизатора Cisco. В этом примере все оставлено по умолчанию:
В этом выводе отладки Устройство 11A отправляет ICMP-сообщения «время превышено» источнику зондов (150.1.1.1). Эти сообщения ICMP являются ответом на первоначальные запросы с TTL=1. Устройство 11А уменьшает значение TTL до нуля и отвечает сообщениями «время истекло».
Примечание. Вы не видите зонды UDP в этих выходных данных отладки по двум причинам:
Этот вывод отладки показывает зонд UDP из источника 150.1.1.1, предназначенный для 150.1.4.2.
Примечание. В этих зондах TTL=2 (это невозможно увидеть при отладке). Устройство 11А уменьшает TTL до 1 и пересылает пакеты UDP на Устройство 7А. Устройство 7A уменьшает значение TTL до нуля и отвечает сообщениями ICMP о превышении времени.
* 29 декабря 13:13:57.080: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 28, вперед
* 29 декабря 13:13:57.080: UDP-источник = 37479, dst = 33440
* 29 декабря 13:13:57.080: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 56, вперед
* 29 декабря 13:13:57.080: тип ICMP = 11, код = 0
* 29 декабря 13:13:57.084: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 28, вперед
* 29 декабря 13:13:57.084: UDP-источник = 40631, dst = 33441
* 29 декабря 13:13:57.084: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 56, вперед
* 29 декабря 13:13:57.084: тип ICMP = 11, код = 0
* 29 декабря 13:13:57.084: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 28, вперед
* 29 декабря 13:13:57.088: UDP src=39881, dst=33442
* 29 декабря 13:13:57.088: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 56, вперед
*29 декабря 13:13:57.088: тип ICMP=11, код=0
В этом выводе отладки вы видите следующие три зонда UDP. TTL для этих зондов равен 3. Устройство 11A уменьшает TTL до 2 и перенаправляет их на Устройство 7A. Устройство 7A уменьшает значение TTL до 1 и пересылает пакеты устройству 7B, которое уменьшает значение TTL до нуля и отвечает ICMP-сообщениями о “превышении времени”.
* 29 декабря 13:13:57.088: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 28, вперед
* 29 декабря 13:13:57.088: UDP src=39217, dst=33443
* 29 декабря 13:13:57.092: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 56, вперед
* 29 декабря 13:13:57.092: тип ICMP = 3, код = 3
* 29 декабря 13:13:57.092: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 28, вперед
* 29 декабря 13:13:57.096: UDP-источник = 34357, dst = 33444
* 29 декабря 13:14:00.092: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 28, вперед
* 29 декабря 13:14:00.092: UDP-источник = 39587, dst = 33445
* 29 декабря 13:14:00.092: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 56, вперед
*29 декабря 13:14:00.092: тип ICMP=3, код=3
Вы можете увидеть последние три зонда UDP в этом выводе отладки. Первоначальный TTL этих зондов был равен 4. TTL был уменьшен до 3 устройством 11A, затем уменьшен до 2 устройством 7A, а затем уменьшен до 1 устройством 7B. Устройство 7C отвечает ICMP-сообщениями «порт недоступен», так как оно было адресатом зондов.
Примечание. Устройство 7C отправляет только два сообщения ICMP «порт недоступен» из-за ограничения скорости.
ПК с Linux
Примечание. Вы не видите зонды UDP в этих выходных данных отладки по двум причинам:
Примечание. В этом выводе отладки вы теперь видите UDP-зонд из источника 150.1.1.1, предназначенный для 150.1.4.2.
Примечание. В этих зондах TTL=2 (это невозможно увидеть при отладке). Устройство 11А уменьшает TTL до 1 и пересылает пакеты UDP на Устройство 7А. Устройство 7A уменьшает значение TTL до нуля и отвечает сообщениями ICMP о превышении времени.
* 2 января 07:17:27.902: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
g=150.1.2.2, длина 40, вперед
* 2 января 07:17:27.902: UDP src=33302, dst=33441
* 2 января 07:17:27.906: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
g=150.1.1.1, длина 56, вперед
* 2 января 07:17:27.906: тип ICMP = 11, код = 0
* 2 января 07:17:27.906: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
g=150.1.2.2, длина 40, вперед
* 2 января 07:17:27.906: UDP src=33302, dst=33442
* 2 января 07:17:27.910: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
g=150.1.1.1, длина 56, вперед
* 2 января 07:17:27.910: тип ICMP = 11, код = 0
* 2 января 07:17:27.910: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
g=150.1.2.2, длина 40, вперед
* 2 января 07:17:27.910: UDP src=33302, dst=33443
* 2 января 07:17:27.910: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
g=150.1.1.1, длина 56, вперед
*2 января 07:17:27.910: Тип ICMP=11, код=0
Следующие три зонда UDP теперь видны в этом выводе отладки. TTL для этих зондов равен 3. Устройство 11A уменьшает TTL до 2 и перенаправляет их на Устройство 7A. Устройство 7A уменьшает значение TTL до 1 и пересылает пакеты устройству 7B, которое уменьшает значение TTL до нуля и отвечает ICMP-сообщениями о “превышении времени”.
* 2 января 07:17:27.910: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
g=150.1.2.2, длина 40, вперед
* 2 января 07:17:27.910: UDP src=33302, dst=33444
* 2 января 07:17:27.914: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
g=150.1.1.1, длина 56, вперед
* 2 января 07:17:27.914: тип ICMP = 3, код = 3
* 2 января 07:17:27.914: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
g=150.1.2.2, длина 40, вперед
* 2 января 07:17:27.914: UDP src=33302, dst=33445
* 2 января 07:17:32.910: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
g=150.1.2.2, длина 40, вперед
* 2 января 07:17:32.910: UDP src=33302, dst=33446
* 2 января 07:17:32.914: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
g=150.1.1.1, длина 56, вперед
* 2 января 07:17:32.914: тип ICMP=3, код=3
Этот вывод отладки показывает три последних зонда UDP. Первоначальный TTL этих зондов был равен 4. TTL был уменьшен до 3 устройством 11A, затем уменьшен до 2 устройством 7A, а затем уменьшен до 1 устройством 7B. Затем устройство 7C отвечает ICMP-сообщениями «порт недоступен», поскольку оно было адресатом зондов.
Примечание. Устройство 7C отправляет только два сообщения ICMP «порт недоступен» из-за ограничения скорости.
ПК с MS Windows
Примечание. Вверху вы видите запросы имени NETBIOS. Эти запросы рассматриваются как UDP-пакеты с исходным и конечным портами 137. Для ясности пакеты NETBIOS удалены из остальных выходных данных отладки. Вы можете использовать параметр -d в команде tracert, чтобы отключить поведение NETBIOS.
Примечание. Вы не видите зонды ICMP в этих выходных данных отладки по двум причинам:
В этом выводе отладки теперь вы видите зонд ICMP из источника 150.1.1.1, предназначенный для 150.1.4.2.
Примечание. В этих зондах TTL=2 (это невозможно увидеть при отладке). Устройство 11А уменьшает TTL до 1 и пересылает пакеты UDP на Устройство 7А. Устройство 7A уменьшает значение TTL до нуля и отвечает сообщениями ICMP о превышении времени.
*29 декабря 14:02:37.776: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 92, вперед
* 29 декабря 14:02:37.776: тип ICMP = 8, код = 0
* 29 декабря 14:02:37.776: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 56, вперед
* 29 декабря 14:02:37.776: тип ICMP = 11, код = 0
* 29 декабря 14:02:37.780: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 92, вперед
* 29 декабря 14:02:37.780: тип ICMP = 8, код = 0
* 29 декабря 14:02:37.780: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 56, вперед
* 29 декабря 14:02:37.780: тип ICMP = 11, код = 0
* 29 декабря 14:02:37.780: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 92, вперед
* 29 декабря 14:02:37.780: тип ICMP = 8, код = 0
* 29 декабря 14:02:37.784: IP: s=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 56, вперед
*29 декабря 14:02:37.784: тип ICMP=11, код=0
В этом выводе отладки вы видите следующие три запроса ICMP. TTL для этих зондов равен 3. Устройство 11A уменьшает TTL до 2 и перенаправляет их на Устройство 7A. Устройство 7A уменьшает значение TTL до 1 и пересылает пакеты устройству 7B, которое уменьшает значение TTL до нуля и отвечает ICMP-сообщениями о “превышении времени”.
*29 декабря 14:02:43.292: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 92, вперед
* 29 декабря 14:02:43.292: тип ICMP = 8, код = 0
* 29 декабря 14:02:43.296: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 92, вперед
* 29 декабря 14:02:43.296: тип ICMP = 0, код = 0
* 29 декабря 14:02:43.296: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 92, вперед
* 29 декабря 14:02:43.296: тип ICMP = 8, код = 0
* 29 декабря 14:02:43.300: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 92, вперед
* 29 декабря 14:02:43.300: тип ICMP=0, код=0
* 29 декабря 14:02:43.300: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
g=150.1.2.2, длина 92, вперед
* 29 декабря 14:02:43.300: тип ICMP = 8, код = 0
* 29 декабря 14:02:43.304: IP: s=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
g=150.1.1.1, длина 92, вперед
* 29 декабря 14:02:43.304: тип ICMP=0, код=0
Ограничение скорости недостижимых сообщений ICMP
Недоступность ICMP ограничена одним пакетом за 500 мс (в качестве защиты от атак типа «отказ в обслуживании» (DoS)) в маршрутизаторе Cisco. Начиная с программного обеспечения Cisco IOS версии 12.1 и выше, это значение скорости можно настраивать. Введена команда:
Дополнительные сведения см. в идентификаторе ошибки Cisco CSCdp28161 (только для зарегистрированных клиентов).
тип = 3, код
0 = сеть недоступна;
1 = хост недоступен;
2 = протокол недоступен;
3 = порт недоступен;
4 = требуется фрагментация и установлен DF;
5 = исходный маршрут не выполнен.
Не удается проверить связь
Если вы не можете успешно пропинговать IP-адрес, рассмотрите причины, перечисленные в этом разделе.
Проблема с роутером
Вот примеры неудачных попыток проверки связи, которые могут определить проблему и действия для ее устранения. Этот пример показан на этой диаграмме топологии сети:
Роутер1#
!
интерфейс Serial0
IP-адрес 172.16.12.1 255.255.255.0
нет честной очереди
тактовая частота 64000
!
Маршрутизатор2#
!
интерфейс Serial0
IP-адрес 10.0.2.23 255.255.255.0
нет честной очереди
тактовая частота 64000
!
интерфейс Serial1
IP-адрес 172.16.0.12 255.255.255.0
!
Маршрутизатор3#
!
интерфейс Serial0
IP-адрес 172.16.3.34 255.255.255.0
нет честной очереди
!
интерфейс Serial1
IP-адрес 10.0.3.23 255.255.255.0
!
Роутер4#
!
интерфейс Serial0
IP-адрес 172.16.4.34 255.255.255.0
нет честной очереди
тактовая частота 64000
!
Попробуйте пропинговать Route4 с Router1:
Router1#отладка IP-пакета
Отладка IP-пакетов включена
Предупреждение: Когда команда debug ip packet используется на рабочем маршрутизаторе, это может вызвать высокую загрузку ЦП. Это может привести к серьезному снижению производительности или выходу из строя сети.
Поскольку на маршрутизаторе Router1 не выполняются никакие протоколы маршрутизации, он не знает, куда отправить свой пакет, и выдает сообщение о невозможности маршрутизации.
Добавьте статический маршрут к Router1:
Router1#настроить терминал
Введите команды конфигурации, по одной в строке. Конец с CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Проверьте, что не так на Router2:
Детали IP-пакета Router2#debug
Отладка IP-пакетов включена (подробно)
Маршрутизатор2#
20 января 16:10:41.907: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, длина 100, немаршрутизируемый
20 января 16:10:41.911: тип ICMP = 8, код = 0
20 января 16:10:41.915: IP: s=172.16.0.12 (локальный), d=172.16.12.1 (Serial1), длина 56, отправка
20 января 16:10:41.919: тип ICMP = 3, код = 1
20 января 16:10:41.947: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, длина 100, немаршрутизируемый
20 января 16:10:41.951: тип ICMP = 8, код = 0
20 января 16:10:43.943: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, длина 100, немаршрутизируемый
20 января 16:10:43.947: тип ICMP = 8, код = 0
20 января 16:10:43.951: IP: s=172.16.0.12 (локальный), d=172.16.12.1 (Serial1), длина 56, отправка
20 января 16:10:43.955: тип ICMP = 3, код = 1
20 января 16:10:43.983: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, длина 100, немаршрутизируемый
20 января 16:10:43.987: тип ICMP = 8, код = 0
20 января 16:10:45.979: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, длина 100, немаршрутизируемый
20 января 16:10:45.983: тип ICMP = 8, код = 0
20 января 16:10:45.987: IP: s=172.16.0.12 (локальный), d=172.16.12.1 (Serial1), длина 56, отправка
20 января 16:10:45.991: тип ICMP=3, код=1
Маршрутизатор 1 правильно отправил свои пакеты маршрутизатору 2, но маршрутизатор 2 не знает, как получить доступ к адресу 172.16.4.34. Маршрутизатор 2 отправляет сообщение «ICMP о недоступности» маршрутизатору 1.
Включить протокол маршрутной информации (RIP) на Router2 и Router3:
Роутер2#
маршрутизатор рип
сеть 172.16.0.7
сеть 10.0.7.23
Маршрутизатор3#
маршрутизатор рип
сеть 10.0.7.23
сеть 172.16.0.34
Маршрутизатор 1 отправляет пакеты маршрутизатору 4, но маршрутизатор 4 не возвращает ответ.
Возможная проблема на Router4:
Router4#debug IP-пакет
Отладка IP-пакетов включена
Роутер4#
20 января 16:18:45.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), длина 100,
RCVD 3
20 января 16:18:45.911: IP: s=172.16.4.34 (локальный), d=172.16.12.1, длина 100, немаршрутизируемый
20 января 16:18:47.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), длина 100,
RCVD 3
20 января 16:18:47.907: IP: s=172.16.4.34 (локальный), d=172.16.12.1, длина 100, немаршрутизируемый
20 января 16:18:49.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), длина 100,
RCVD 3
20 января 16:18:49.907: IP: s=172.16.4.34 (локальный), d=172.16.12.1, длина 100, немаршрутизируемый
20 января 16:18:51.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), длина 100,
RCVD 3
20 января 16:18:51.907: IP: s=172.16.4.34 (локальный), d=172.16.12.1, длина 100, немаршрутизируемый
20 января 16:18:53.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), длина 100,
RCVD 3
20 января 16:18:53.907: IP: s=172.16.4.34 (локальный), d=172.16.12.1, длина 100, немаршрутизируемый
Маршрутизатор 4 получает пакеты ICMP и пытается ответить на адрес 172.16.12.1, но, поскольку у него нет маршрута к этой сети, он терпит неудачу.
Добавьте статический маршрут к Router4:
Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Теперь обе стороны могут получить доступ друг к другу:
Интерфейс отключен
Это ситуация, когда интерфейс перестал работать. В следующем примере попытка отправить эхо-запрос Router4 с Router1:
Поскольку маршрутизация верна, выполните пошаговое устранение проблемы. Попробуйте пропинговать Router2:
Из предыдущего примера видно, что проблема возникает между Router2 и Router3. Одна из возможностей состоит в том, что последовательный интерфейс на Router3 был отключен:
Это легко исправить:
Router3#настроить терминал
Введите команды конфигурации, по одной в строке. Конец с CNTL/Z.
Router3(config)#interface serial1
Router3(config-if)#нет выключения
Router3(config-if)#
20 января, 16:20:53.900: %LINK-3-UPDOWN: Интерфейс Serial1, изменено состояние на up
20 января 16:20:53.910: %LINEPROTO-5-UPDOWN: линейный протокол на интерфейсе Serial1,
изменено состояние на вверх
В этом сценарии только трафик telnet может поступать на Route4 через интерфейс Serial0.
Router4(config)# список доступа 100 разрешить tcp любой любой eq telnet
Router4(config)#interface serial0
Router4(config-if)#ip-группа доступа 100 в
Router1#настроить терминал
Введите команды конфигурации, по одной в строке. Конец с CNTL/Z.
Router1(config)#access-list 100 разрешить IP хост 172.16.12.1 хост 172.16.4.34
Router1(config)#access-list 100 разрешить хост ip 172.16.4.34 хост 172.16.12.1
Router1(config)#end
Router1 # отладка IP-пакета 100
Отладка IP-пакетов включена
Router1#отладка ip icmp
Отладка пакетов ICMP включена
Попробуйте пропинговать Router4:
Router4(config)#access-list 100 разрешить icmp любой любой
Проблема протокола разрешения адресов (ARP)
В этом сценарии это соединение Ethernet:
Проблема протокола разрешения адресов
В этом примере ping не работает из-за сообщения “ошибка инкапсуляции”. Это означает, что маршрутизатор знает, через какой интерфейс он должен отправить пакет, но не знает, как это сделать. В этом случае вам необходимо понять, как работает протокол разрешения адресов (ARP).
ARP — это протокол, используемый для преобразования адреса уровня 2 (MAC-адреса) в адрес уровня 3 (IP-адрес). Вы можете проверить это с помощью команды show arp:
Router4#show arp
Протокол Адрес Возраст (мин.) Тип аппаратного адреса Интерфейс
Интернет 172.16.100.4 – 0000.0c5d.7a0d ARPA Ethernet0
Интернет 172.16.100.7 10 0060.5cf4.a955 ARPA Ethernet0
Вернитесь к проблеме “сбой инкапсуляции”, но на этот раз включите команду отладки arp:
В предыдущем выводе показано, что Router4 широковещательно передает пакеты и отправляет их на широковещательный адрес Ethernet FFFF. ФФФФ. ФФФФ. Здесь 0000.0000.0000 означает, что Router4 ищет MAC-адрес пункта назначения 172.16.100.5. Поскольку во время запроса ARP в этом примере MAC-адрес неизвестен, он использует 0000.0000.000 в качестве заполнителя в широковещательных кадрах, отправляемых из интерфейса Ethernet 0, и спрашивает, какой MAC-адрес соответствует 172.16.100.5. Если ответа нет, MAC-адрес, соответствующий IP-адресу в выводе show arp, помечается как неполный:
Router4#show arp
Протокол Адрес Возраст (мин.) Тип аппаратного адреса Интерфейс
Интернет 172.16.100.4 – 0000.0c5d.7a0d ARPA Ethernet0
Интернет 172.16.100.5 0 Неполный ARPA
Интернет 172.16.100.7 2 0060.5cf4.a955 ARPA Ethernet0
По истечении заданного периода эта неполная запись удаляется из таблицы ARP. Пока MAC-адрес отсутствует в таблице ARP, проверка связи завершается ошибкой из-за ошибки инкапсуляции.
Задержка
По умолчанию, если вы не получили ответ от удаленного конца в течение двух секунд, проверка связи не удалась:
В сетях с медленным соединением или большой задержкой двух секунд недостаточно. Вы можете изменить это значение по умолчанию с помощью расширенного пинга:
В предыдущем примере, когда тайм-аут был увеличен, проверка связи прошла успешно.
Примечание: Среднее время прохождения туда и обратно составляет более двух секунд.
Правильный исходный адрес
Этот пример является распространенным сценарием:
Правильный исходный адрес
Добавьте интерфейс LAN на Router1:
Router1(config)#interface ethernet0
Маршрутизатор1(config-if)#ip-адрес 10.0.0.1 255.255.255.0
Со станции в локальной сети можно пропинговать Router1. С Router1 вы можете пинговать Router2. Но со станции в локальной сети вы не можете пропинговать Router2.
От Router1 вы можете пропинговать Router2, потому что по умолчанию вы используете IP-адрес исходящего интерфейса в качестве исходного адреса в вашем ICMP-пакете. Router2 не имеет информации об этой новой локальной сети. Если ему нужно ответить на пакет из этой сети, он не знает, как с ним обращаться.
Предупреждение: Когда команда debug ip packet используется на рабочем маршрутизаторе, это может вызвать высокую загрузку ЦП. Это может привести к серьезному снижению производительности или выходу из строя сети.
Предыдущий пример вывода работает, потому что исходный адрес отправленного пакета — 172.16.12.1. Для имитации пакета из локалки нужно использовать расширенный пинг:
На этот раз исходный адрес 10.0.0.1, и он не работает. Пакеты отправляются, но ответа нет. Чтобы устранить эту проблему, добавьте маршрут к 10.0.0.0 в Router2. Основное правило заключается в том, что пингуемое устройство также должно знать, как отправить ответ источнику пинга.
Высокие потери в очереди ввода
Когда пакет поступает на маршрутизатор, маршрутизатор пытается переслать его на уровне прерывания. Если совпадение не может быть найдено в соответствующей кэш-таблице, пакет ставится в очередь во входной очереди входящего интерфейса для обработки. Некоторые пакеты обрабатываются всегда, но при соответствующей конфигурации и в стабильных сетях скорость обработки пакетов никогда не должна перегружать входную очередь. Если входная очередь заполнена, пакет отбрасывается.
Хотя интерфейс работает, и вы не можете пропинговать устройство из-за большого количества входных очередей. Вы можете проверить входные данные с помощью команды show interface.
Router1#show interface Serial0/0/0
Serial0/0/0 работает, линейный протокол работает
MTU 1500 байт, BW 1984 Кбит, DLY 20000 мкс,
надежность 255/255, txload 69/255, rxload 43/255
Инкапсуляция HDLC, петля не установлена
Набор проверки активности (10 сек.)
Последний ввод 00:00:02, вывод 00:00:00, вывод никогда не зависает
Последняя очистка счетчиков “показать интерфейс” 01:28:49
Входная очередь: 76/75/5553/0 (размер/макс/дроп/флеш);
Всего выпадает выход: 1760
Стратегия организации очереди: организация очереди на основе классов
Очередь вывода: 29/1000/64/1760 (размер/максимальное количество/порог/дропы)
Беседы 7 / 129 / 256 (активных/максимальных активных/максимальных общих)
Зарезервированные разговоры 4/4 (выделено/максимально выделено)
Доступная пропускная способность 1289 кбит/с
!— Вывод подавлен
Как видно из выходных данных, падение входной очереди высокое. См. Устранение неполадок с отбрасыванием входной очереди и выходной очереди для устранения неполадок с отбрасыванием входной/выходной очереди.
Предпосылки
Читатели этого документа должны иметь базовые знания об одной из этих операционных систем:
Используемые компоненты
Информация в этом документе относится к этим версиям программного и аппаратного обеспечения:
- Маршрутизатор Cisco с ПО Cisco IOS версии 12.2
- ПК с Red Hat Linux версии 9
- ПК с MS Windows 2000
Информация в этом документе была создана с помощью устройств в специальной лабораторной среде. Все устройства, используемые в этом документе, запускались с очищенной (по умолчанию) конфигурацией. Если ваша сеть работает, убедитесь, что вы понимаете потенциальное влияние любой команды.
