dhclient флудит

[Schneider]

Проблема следующая, в syslog после нескольких дней работы сервера под ubuntu 10.10 server
подключенного к билайн начинает сыпаться такая фигня:

Код: [Выделить]

Apr  7 18:20:26 localhost dhclient: DHCPREQUEST of 10.143.152.89 on eth0 to 89.179.231.148 port 67
Apr  7 18:20:41 localhost dhclient: last message repeated 3 times
Apr  7 18:........ localhost dhclient: last message repeated 5 times
Apr  7 18:........ localhost dhclient: last message repeated 5 times
и тд и тп. разных вариациях
запрос идет vpn(pptp)серверу от моего компа
при этом по ifconfig у интерфейса ppp0 уже есть ip адрес и почему его еще раз запрашивает dhcpclient не понятно.
раньше я видел такую фигню на предыдущей версии (9) Ubuntu при тех же обстоятельствах. ну подумал что сессии больше суток не приветствуются в билайн и добавил разрыв соединения и повторное включение (pptp сессия) через 2 минуты. вроде проблема исчезла.
Но вот сегодня увидел что локальные ресурсы отвалились, часть доступа к некоторым компам сети блокирована (для тех кто не знаком с билайн) . Звоню в службу поддержки, а мне там намекают на то, что широковещательный флуд мог быть причиной такой блокировки. Я в логи смотрю. А там уже двое суток такая фигня сыпется.

Куда копать, кто подскажет ?
Пользователь решил продолжить мысль 10 Апреля 2011, 05:57:21:up

[Schneider]

есть идеи? 

[podkovyrsty]

есть идеи? 

Включи дебаг в dhcpdc и в впн клиенте и смотри что инициирует запросы.
ppp0 тут непричем, у тебя по поводу eth0 запросы идут.

[Schneider]

ppp0      Link encap:Point-to-Point Protocol
          inet addr:78.107.58.215  P-t-P:89.179.231.148  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1460  Metric:1
          RX packets:1640846 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1349026 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:1585598147 (1.5 GB)  TX bytes:760745311 (760.7 MB)

10.111.111.111  подключен точка точка к 89.179.231.148
с помощью этого тунеля образуется ppp0 с адресом 78.107.58.215

дык запросы то идут к VPN  серверу получается? я правильно понимаю.
я просто не разбираюсь в деталях как работает DHCP и всегда думал что это только широковещательные запросы могут быть. а тут не совсем так вроде.

[podkovyrsty]

Получается так.
Могут, но не обязаны.
А покажи route -n при установленном подключении.

[Schneider]

Код: [Выделить]

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
85.21.72.83     10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
85.21.230.73    10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
85.21.230.73    10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
195.14.50.21    10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
85.21.230.77    10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
85.21.230.77    10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
195.14.50.26    10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
89.179.135.67   10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
195.14.40.141   10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
195.14.50.93    10.143.152.1    255.255.255.255 UGH   0      0        0 eth0
78.107.122.0    10.143.152.1    255.255.255.240 UG    0      0        0 eth0
85.21.72.80     10.143.152.1    255.255.255.240 UG    0      0        0 eth0
217.118.84.0    10.143.152.1    255.255.255.0   UG    0      0        0 eth0
233.33.210.0    10.143.159.76   255.255.255.0   UG    0      0        0 eth0
78.107.52.0     10.143.152.1    255.255.255.0   UG    0      0        0 eth0
10.143.152.0    0.0.0.0         255.255.248.0   U     0      0        0 eth0
10.0.0.0        10.143.152.1    255.0.0.0       UG    0      0        0 eth0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
вот
я до конца не понимаю как работает маршрутизация.
мне к примеру не понятно
78.107.52.0     10.143.152.1    255.255.255.0   UG    0      0        0 eth0
почему запросы к сети внешки 78.107.52.0 надо слать на внутренний шлюз через eth0

че нить видно из этого ?

[censor]

и не поймете пока не почитаете про маршрутизацию хотя бы статическую
на сеть 78.107.52.0 с маской 255.255.255.0 ходить через шлюз 10.143.152.1
ваш провайдер скорей всего предоставляет бесплатный доступ к данным сетям либо это его же сеть

[es1840]

1. Если вы постоянно подключены по одному физическому адресу к Билайн, убрать т.н. флуд DHCP можно, указав адрес dhcp сервера в конфиге dhcpd (/etc/dhcp3/dhclient.conf)./ Читать man./ Тогда он широковещательный пакет посылать не будет, а будет делать запрос к своему серверу.
2. Сходите на форум Билайн, там по своей географии разберитесь с настройками маршрутов. Там у них с маршрутизацией в сети есть нюансы по географии.
3. Проверьте качество физической линии связи, может быть там неисправность... Иначе с чего-бы dhcp дергаться.

P.S. По опыту общения с украинским Билайн скажу - виноватым они все равно будут считать вас, даже если у них сервера мыши съедят...
Это как раз эти спецы предлагали на Линуксе отключить антивирус для восстановления работы канала (dhcp не подхватывал).

Теперь у другого провайдера "инженер по компьютерным сетям" культурно извинился, передал все данные и адреса, после чего молча наблюдал, как настраивается и проверяется сеть в Linux. И почему-то был приятно удивлен.

[Schneider]

конечно качество физической линии можно проверять а можно и не проверять. у меня такая фигня была и раньше когда я жил в другом районе. На счет "украинский билайн", так это может быть совсем другая компания. В казахстане тоже есть билайн. но к российскому он отношения не имеет (в смысле технически, даже деньги на телефон российский нельзя у них положить).
 Если вы прочитали первый пост то обратите внимание что dhclient как раз и посылает запросы серверу vpn (а не широковещательный), не смотря на то, что Ip адрес ни внешнего ppp0 ни внутреннего eth0 интерфейсов никуда не делся.

 PS. Маны читать это конечно само собой, но я ожидал каких то конструктивных советов, от тех, кто уже знаком с dhclient на практике.

[AnrDaemon]

Самый конструктивный ответ тебя даст твой саппорт.
Ибо DHCP клиент просто из вредности спамить не будет. Раз начинается такая фигня, значит, есть немаленькая вероятность, что провайдерская сеть настроена без приложения головы к рукам.

[Schneider]

добавил в кронтаб:

50 5 * * 1-7 poff bee
51 5 * * 1,3,5,7 ifconfig eth0 down
52 5 * * 1,3,5,7 ifconfig eth0 up
53 5 * * 1,3,5,7 dhclient eth0
54 5 * * 1-7 pon bee

чтобы vpn не глючил первая и последняя запись - сессии больше суток по моему у провайдера не особо приветствуются
а по пон.ср.пятн.воскр. перезапуск eth0
потому как

Код: [Выделить]

Listening on LPF/eth0/00:90:27:2d:4e:d5
Sending on   LPF/eth0/00:90:27:2d:4e:d5
Sending on   Socket/fallback
DHCPREQUEST of 10.143.152.89 on eth0 to 255.255.255.255 port 67
DHCPACK of 10.143.152.89 from 10.143.152.1
bound to 10.143.152.89 -- renewal in 297131 seconds.судя по последней строчке аренда выдается на 3 суток где то (каждый раз по разному)
может dhclient повторяет свою работу? при существующем подключении. вот я и решил его сбрасывать каждые двое суток.
должно помоч

Пользователь решил продолжить мысль 18 Апреля 2011, 11:42:32:интересную вещь обнаружил в syslog

старт компа:

Код: [Выделить]

Apr 14 23:59:04 localhost kernel: [   22.520483] type=1400 audit(1302811144.159:11): apparmor="STATUS" operation="profile_load" name="/usr/sbin/tcpdump" pid=458
Apr 14 23:59:04 localhost dhclient: DHCPOFFER of 10.143.159.76 from 10.143.152.1
Apr 14 23:59:04 localhost dhclient: DHCPREQUEST of 10.143.159.76 on eth0 to 255.255.255.255 port 67
Apr 14 23:59:04 localhost dhclient: DHCPACK of 10.143.159.76 from 10.143.152.1
Apr 14 23:59:06 localhost dhclient: bound to 10.143.159.76 -- renewal in 274751 seconds.

а вот начал флудить, при том что pptp (VPN) подключение у меня было в этот момент отключено!!!! :

Код: [Выделить]

Apr 18 04:02:42 localhost kernel: [273841.076688] IPT INPUT packet died: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:26:9e:bc:a7:c6:08:00 SRC=10.143.154.139 DST=10.14
Apr 18 04:18:17 localhost dhclient: DHCPREQUEST of 10.143.159.76 on eth0 to 89.179.231.148 port 67
Apr 18 04:18:52 localhost dhclient: last message repeated 5 times
Apr 18 04:20:02 localhost dhclient: last message repeated 4 times
Apr 18 04:21:02 localhost dhclient: last message repeated 5 times
Apr 18 04:22:02 localhost dhclient: last message repeated 4 times

получается через 274751 секунд (кто не верит может пересчитать) dhclient начинает повторно запрашивать адрес но уже не у 10.143.152.1 (это местный шлюз) как в первый раз, а почему то уже у VPN сервера, который к eth0 интерфейсу отношения не имеет.
сейчас попробую dhcp сервер насильно прописать для eth0.
----------------------
ан нет оказалось 89.179.231.148 это не VPN Сервер!

[AnrDaemon]

Маршруты проверяй...

[Schneider]

че их проверять то, они(маршруты) от того же dhcp сваливаются. а те которые скриптом для VPN (pptp) проверил-
все верно сваливает, часть на шлюз по умолчанию, часть в сеть. даже сетка 233.33.210.0 iptv правильно прикручена.

[AnrDaemon]

...Ты думаешь, мне больше заняться нечем, кроме как спорить с тобой по поводу того, что надо а что не надо проверять?
Да, маршруты сваливаются по DHCP. КРИВЫЕ!
Ищи кривизну, тыкай своего провайдера носом, нехай исправляют.

[podkovyrsty]

cat /etc/dhcp3/dhclient.conf