Jump to content
Калькуляторы

Странности с DHCP

Добрый день. С некоторых пор абоненты одного сегмента пожаловались на нестабильную работу сети. Посмотрел дамп и увидел на 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

Данный абонент находится в одном широковещательном домене с сервером. Такая картина наблюдается у части абонентов, находящихся в разных районах города. В сети на доступе в основном мыльницы, в ядре и на агрегации проблем не видно. Что может быть? Пока подозреваю, что где-то есть сгоревшая мыльница (или несколько), либо медиаконвертер.

Edited by motorhunter

Share this post


Link to post
Share on other sites

Обойдётся без ответа на инфрм, в информе запрашиваются доп параметры, типа прокси (обычно для службы автоматических обновлений). Можно вообще не отвечать а информ - ничего не изменится для клиентов.

Share this post


Link to post
Share on other sites

Похоже на то, что где-то в сети многократно дублируется пакет

08:05:51.832523 IP 10.10.0.4.67 > 10.10.2.237.68: BOOTP/DHCP, Reply, length 376

 

а при пинге абонента с сервера нет дубликатов?

Share this post


Link to post
Share on other sites

Обойдётся без ответа на информ

Обойдётся, но вопрос в другом - почему такой ответ (и в таком количестве)?

 

agr, нет, пинг нормальный, запрос-ответ в единственном экземпляре.

Edited by motorhunter

Share this post


Link to post
Share on other sites

Мыльницу значит занятно поплющило либо порт подбило... Скорее всего - ту, в которую воткнут абон или по дороге от абона до умного свича.

Share this post


Link to post
Share on other sites

Обойдётся без ответа на информ

Обойдётся, но вопрос в другом - почему такой ответ (и в таком количестве)?

 

agr, нет, пинг нормальный, запрос-ответ в единственном экземпляре.

 

 

Странно. Могу посоветовать тогда только попробовать отследить не флапает ли mac- клиента между портами и долго ли он держится в mac-таблице. Мыльницы скорее всего неуправляемые, но хотя бы проверить на аггрегации можно.

У нас как-то был случай с множественным дублированием. Причина была такая: один свич(фирмы Cisco) слегка сошел с ума и начал непрерывно генерить STP Topology Change, отчего на сопредельных свичах в сегменте постоянно обнулялась mac- таблица. В результате весь трафик отправлялся на все порты, а некоторые клиентские роутеры его маршрутизировали обратно в сеть, вот из-за этого получалось много дубликатов.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this