motorhunter Опубликовано 14 мая, 2012 (изменено) · Жалоба Добрый день. С некоторых пор абоненты одного сегмента пожаловались на нестабильную работу сети. Посмотрел дамп и увидел на DHCP-сервере следующую картину: tcpdump -i eth0 -pn port 68 or icmp 08:05:51.831806 IP 10.10.2.237.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 1c:6f:65:c9:bc:e9, length 300 08:05:51.832523 IP 10.10.0.4.67 > 10.10.2.237.68: BOOTP/DHCP, Reply, length 376 08:05:51.855210 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.857002 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.861995 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.864299 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.867440 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.869478 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.871493 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.873508 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.879102 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.885177 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.892241 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.898664 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.905865 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.912868 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.918817 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.924717 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.948941 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.951055 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.952958 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.955009 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.958537 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.959908 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.961812 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.963601 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.965921 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.968418 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.970025 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.972094 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.974577 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.976624 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 08:05:51.978651 IP 10.10.2.237 > 10.10.0.4: ICMP 10.10.2.237 udp port 68 unreachable, length 412 10.10.0.4 - DHCP-сервер, 10.10.2.237 - абонент. Лог сервера выглядит нормальным: May 14 08:05:51 debian-nas-10 dhcpd: DHCPINFORM from 10.10.2.237 via eth0 May 14 08:05:51 debian-nas-10 dhcpd: DHCPACK to 10.10.2.237 (1c:6f:65:c9:bc:e9) via eth0 Данный абонент находится в одном широковещательном домене с сервером. Такая картина наблюдается у части абонентов, находящихся в разных районах города. В сети на доступе в основном мыльницы, в ядре и на агрегации проблем не видно. Что может быть? Пока подозреваю, что где-то есть сгоревшая мыльница (или несколько), либо медиаконвертер. Изменено 14 мая, 2012 пользователем motorhunter Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 14 мая, 2012 · Жалоба Обойдётся без ответа на инфрм, в информе запрашиваются доп параметры, типа прокси (обычно для службы автоматических обновлений). Можно вообще не отвечать а информ - ничего не изменится для клиентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 15 мая, 2012 · Жалоба Похоже на то, что где-то в сети многократно дублируется пакет 08:05:51.832523 IP 10.10.0.4.67 > 10.10.2.237.68: BOOTP/DHCP, Reply, length 376 а при пинге абонента с сервера нет дубликатов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
motorhunter Опубликовано 15 мая, 2012 (изменено) · Жалоба Обойдётся без ответа на информ Обойдётся, но вопрос в другом - почему такой ответ (и в таком количестве)? agr, нет, пинг нормальный, запрос-ответ в единственном экземпляре. Изменено 15 мая, 2012 пользователем motorhunter Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 15 мая, 2012 · Жалоба Мыльницу значит занятно поплющило либо порт подбило... Скорее всего - ту, в которую воткнут абон или по дороге от абона до умного свича. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
agr Опубликовано 16 мая, 2012 · Жалоба Обойдётся без ответа на информ Обойдётся, но вопрос в другом - почему такой ответ (и в таком количестве)? agr, нет, пинг нормальный, запрос-ответ в единственном экземпляре. Странно. Могу посоветовать тогда только попробовать отследить не флапает ли mac- клиента между портами и долго ли он держится в mac-таблице. Мыльницы скорее всего неуправляемые, но хотя бы проверить на аггрегации можно. У нас как-то был случай с множественным дублированием. Причина была такая: один свич(фирмы Cisco) слегка сошел с ума и начал непрерывно генерить STP Topology Change, отчего на сопредельных свичах в сегменте постоянно обнулялась mac- таблица. В результате весь трафик отправлялся на все порты, а некоторые клиентские роутеры его маршрутизировали обратно в сеть, вот из-за этого получалось много дубликатов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...