Последовательность Тестирования Сети

Рубрика: Конфигурация и тестирование сети

В качестве резюме, давайте пройдем через последовательность тестирования сети (см. предыдущие посты о тестировании сети) в другом сценарии.

Последовательность Тестирования - Соединяем все это вместе

Тест 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-адреса

Смотрите также
Комментарии
Написать

(обязательно)

(обязательно)

Это не спам (обязательно)