Много провала пинга - ручной ARP, кажется, исправит это

Question

У меня странная проблема.

У меня система мониторинга (похожая на nagios) работает на centos 6

Я наблюдаю за многими узлами, большинство переключателей, которые мы наблюдаем, имеют другую подсеть для освобождения некоторых адресов для хостов DHCP.

Коммутаторы находятся на 172.16.200.0/24. Сервер мониторинга - 172.16.200.30/24. Мой IP-адрес - 172.16.1.250/16 (Ubuntu).

Узлы в подсети 172.16.200.0/24 постоянно работают вверх и вниз. Тем не менее, когда я SSH к системе мониторинга, я могу временно решить эту проблему следующим образом:

ping 172.16.200.35
PING FAIL
arping 172.16.200.35
OK
ping 172.16.200.35
PING SUCCESS

Эти коммутаторы были в порядке, когда они были в подсети 172.16.1.0/24, но теперь они не работают хорошо ... есть идеи, с чего начать?

Кроме того, другая машина в моем собственном офисе под управлением Windows 10 может получить доступ ко всему без нареканий, это 172.16.1.91/16

Извините, что не публикуете таблицы маршрутизации.

Мой ПК:

$ ip -4 a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 172.16.1.250/16 brd 172.16.255.255 scope global eth0
       valid_lft forever preferred_lft forever

$ ip r
default via 172.16.1.254 dev eth0 onlink 
169.254.0.0/16 dev eth0  scope link  metric 1000 
172.16.0.0/16 dev eth0  proto kernel  scope link  src 172.16.1.250 

Система наблюдения:

# ip -4 a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 172.16.1.30/24 brd 172.16.1.255 scope global eth0
    inet 172.16.3.30/24 brd 172.16.3.255 scope global eth0:0
    inet 172.16.200.30/24 brd 172.16.200.255 scope global eth0

# ip r
172.16.3.0/24 dev eth0  proto kernel  scope link  src 172.16.3.30 
172.16.1.0/24 dev eth0  proto kernel  scope link  src 172.16.1.30 
172.16.200.0/24 dev eth0  scope link 
172.16.200.0/24 dev eth0  proto kernel  scope link  src 172.16.200.30 
169.254.0.0/16 dev eth0  scope link  metric 1002 
default via 172.16.1.254 dev eth0

Answer 1

Уровень 2 или Уровень 3 проблема

Я немного ошибаюсь в своем комментарии - я имею в виду запрос содержимого таблицы arp на хосте, у которого возникла проблема с пингом коммутаторов / сервера ДО и ПОСЛЕ arpping. Отчасти мне было любопытно, была ли запись arp «before» без ответа (FAILED) или MAC-адрес изменился из-за arping.

Чтобы получить эту информацию, вы можете использовать команду:

 ip neigh show

или устаревший arp -a

Вы можете передать команде ip определенный интерфейс (phy), чтобы ограничить вывод этой сетевой картой.

Для этого типа проблемы, скорее всего, у вас есть проблема уровня 2 или 3. Это чрезмерное упрощение, но очень условно вы можете представить эти два слоя следующим образом:

• На уровне 2 (канальный уровень) протокол разрешения адресов облегчает сопоставление IP-адресов с физическими MAC-адресами.
• На уровне 3 (он же сетевой уровень) происходит маршрутизация на основе IP.

Проблема физического уровня; слой 1; будет включать в себя кабели, NIC HW и т. д. и, как правило, не будет исправлять себя так многократно с помощью arping, и нет никаких доказательств того, что это проблема более высокого уровня (TCP/UDP или уровень приложения).

Поскольку вы сейчас говорите, что MAC-адрес для неудавшегося эхо-запроса изменяется с одного «реального» MAC-адреса на другой, очень возможно, что у вас есть дублированные IP-адреса (или крайне маловероятные для «приобретенного» оборудования) дублированные MAC-адреса.

Я думаю, что лучший следующий шаг - провести инвентаризацию IP и MAC-адресов, используемых в локальной сети.

Создать карту сети

Используя nmap (zenmap, интерфейс GUI добавляет к нему также некоторые визуальные эффекты - я рекомендую его для этого), выполните следующую команду, чтобы получить топологию подсети «проблема»:

 sudo nmap -sn -PR 172.16.200.0/24

Если вы используете zenmap, просто вставьте эту команду в окно «command» в графическом интерфейсе и нажмите «scan».

Если вы совершенно не знакомы с nmap, вот как выглядит результат этого сканирования (в моей скучной домашней сети), 192.168.1.1/24

Starting Nmap 7.12 ( https://nmap.org ) at 2016-12-27 22:25 EST
Nmap scan report for 192.168.1.1
Host is up (0.00021s latency).
MAC Address: C4:04:XX:XX:XX:XX (Netgear)
Nmap scan report for 192.168.1.40
Host is up (0.0014s latency).
MAC Address: 28:92:XX:XX:XX:XX (Hewlett Packard)
...
(...skipping to bottom...)  
...
Nmap done: 256 IP addresses (19 hosts up) scanned in 3.72 seconds

Это говорит само за себя - выходные данные будут содержать только отвечающие хосты и их MAC и IP-адреса. Возможно, вы получите только один или другой от хоста.

В zenmap вы можете получить визуальную топологию, перейдя на вкладку «топология». По умолчанию все обычно объединяются вместе, поэтому вам, вероятно, придется нажать кнопку «элементы управления» и настроить макет, прежде чем его можно будет использовать. Независимо от источника данных (визуальный или текстовый), соберите все вместе и просмотрите:

1. Любые дублирующиеся IP-адреса или MAC-адреса
2. Любые пропавшие или неожиданные хосты
3. Любые ошибки, отмеченные nmap

Если при сканировании /24 ничего не выскакивает, увеличьте его, чтобы охватить дополнительные сети (/16 займет значительно больше времени).

Если вам нужно создать огромную подсеть (/8), тогда пинг становится запретительным по времени (ожидание истечения времени ожидания ~ 16M), и вы можете удалить аргумент -sn из nmap и просто использовать -PR (который является arping).

Если вы не можете найти ничего полезного в данных, обновите свой вопрос так, как вам удобно, если вы хотите разместить его (возможно, на стороннем сайте, таком как pastebin, чтобы ваш вопрос читался).