Последовательность Тестирования Сети
В качестве резюме, давайте пройдем через последовательность тестирования сети (см. предыдущие посты о тестировании сети) в другом сценарии.
Тест 1: Локальная Обратная петля - Успех
C:\>ping 127.0.0.1
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
На узле 1 стек IP сконфигурирован должным образом.
Тест 2: Локальный NIC - Успех
C:\>ping 192.168.23.3
Pinging 192.168.23.3 with 32 bytes of data:
Reply from 192.168.23.3: bytes=32 time<1ms TTL=128
Reply from 192.168.23.3: bytes=32 time<1ms TTL=128
Reply from 192.168.23.3: bytes=32 time<1ms TTL=128
Reply from 192.168.23.3: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.23.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
IP-адрес должным образом присвоен NIC, и электроника в NIC отвечает на IP-адрес.
Тест 3: Пинг Локального Шлюза - Успех
C:\>ping 192.168.23.254
Pinging 192.168.23.254 with 32 bytes of data:
Reply from 192.168.23.254: bytes=32 time<1ms TTL=128
Reply from 192.168.23.254: bytes=32 time<1ms TTL=128
Reply from 192.168.23.254: bytes=32 time<1ms TTL=128
Reply from 192.168.23.254: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.23.254:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Шлюз по умолчанию работает. Это также проверяет работу локальной сети.
Тест 4: Ping Удаленного Узла - Отказ
C:\>ping 192.168.11.1
Pinging 192.168.11.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.11.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
Это - тест передачи вне локальной сети. Поскольку шлюз ответил, но узел за его пределами - нет, проблема, по-видимому, где-нибудь вне локальной сети.
Тест 5: Трассировка маршрута к Удаленному Узлу - Отказ на первом Транзитном участке
C:\>tracert 192.168.11.1
Tracing route to 192.168.11.1 over a maximum of 30 hops
1 * * * Request timed out.
2 * * * Request timed out.
3 ^C
Кажется, будто результаты противоречивы. Шлюз по умолчанию отвечает, указывая, что есть передача между узлом Host1 и шлюзом. С другой стороны шлюз, кажется, не отвечает на traceroute.
Одно из объяснений может быть такое: локальный узел не сконфигурирован должным образом, чтобы использовать 192.168.23.254 в качестве шлюза по умолчанию. Чтобы проверить это, мы исследуем конфигурацию Host1.
Тест 6: Исследование Конфигурации Узла на использование Надлежащего Локального Шлюза - Неверная конфигурация
C:\>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
IP Address. . . . . . . . . . . . : 192.168.23. 3
Subnet Mask . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . : 192.168.23.253
Из вывода команды ipconfig можно заключить, что шлюз не сконфигурирован должным образом на узле. Это объясняет ложное предположение, что проблема была в объединенной сети вне локальной сети. Даже при том, что адрес 192.168.23.254 отвечает, он не является адресом, сконфигурированным на узле Host1 в качестве шлюза.
Будучи не в состоянии создать кадр, Host1 отбрасывает пакет. В этом случае не может быть никакого ответа, обозначенного в трассировке до удаленного узла.
Далее: Процесс ARP - Отображение IP адресов на MAC-адреса