Почему NTP прослушивает широковещательный IP

Это физическая машина SBC, и заказчик создал множество виртуальных IP-адресов (это связано с концепцией relem и vnet в телекоммуникациях).

Здесь мы создали eth2 и eth3 в качестве сигнального интерфейса. eth2 и eth3 обрабатываются как vlan и связывают реле eth2:6 и eth3.1238:0 с этими vlan.

В нашем случае мы отбрасываем eth2 и eth3 из ntp.conf, потому что к eth2 и eth3 привязано несколько релем, поэтому ntp пытается создать сокет для каждого сеанса, и проблема заключалась в том, что все дескрипторы файлов были исчерпаны. Вот почему мы добавляем только интерфейс eth0 и не хотим, чтобы npt слушал какой-либо интерфейс, кроме eth0, поэтому я использовал опцию игнорирования подстановочных знаков интерфейса.

Однако мы видим, что после внесения изменений в ntp.conf он пытается прослушивать широковещательный адрес и не может выполнить привязку с неожиданной ошибкой.

ntpd[89217]: ./../lib/isc/unix/ifiter_ioctl.c:617: unexpected error:
ntpd[89217]: eth2:6: getting broadcast address: Cannot assign requested address
ntpd[89217]: i/o error on routing socket No buffer space available – disabling
ntpd[5410]: ./../lib/isc/unix/ifiter_ioctl.c:617: unexpected error:
ntpd[5410]: eth3.1238:0: getting broadcast address: Cannot assign requested address
ntpd[5410]: ntpd exiting on signal 15
ntpd[1508]: ntpd exiting on signal 15

ntp.conf

fudge 127.127.1.0 stratum 10
Authentication stuff
keys /etc/ntp.keys
path for keys file
trustedkey 1
define trusted keys
requestkey 1
server 172.23.5.8 iburst
server 172.23.5.9 iburst
restrict 172.23.5.8
restrict 172.23.5.9
key (7) for accessing server variables
controlkey 15 # key (6) for accessing server variables
extra lines to fix issue about NTP Daemon
interface listen eth0
interface ignore wildcard

ip a sh

256: eth3.897@eth3: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:1e:67:53:e0:b2 brd ff:ff:ff:ff:ff:ff
inet 169.254.66.8/18 brd 169.254.127.255 scope global eth3.897:0
inet6 fe80::21e:67ff:fe53:e0b2/64 scope link nodad
valid_lft forever preferred_lft forever
257: eth3.951@eth3: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:1e:67:53:e0:b2 brd ff:ff:ff:ff:ff:ff
inet 169.254.66.118/18 brd 169.254.127.255 scope global eth3.951:0
inet6 fe80::21e:67ff:fe53:e0b2/64 scope link nodad
valid_lft forever preferred_lft forever
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host nodad

Может ли кто-нибудь сказать мне, как исправить эту ошибку?


person Sumit Gemini    schedule 20.10.2016    source источник


Ответы (1)


Мне не удалось воспроизвести вашу проблему, но я подозреваю, что в игре есть несколько вещей;

Где-то у вас может быть проблема с конфигурацией IP-адреса на одном из ваших интерфейсов (именно поэтому вы получаете ошибку привязки). Мне также интересно, есть ли в вашей системе более одного файла конфигурации, поскольку ваш предыдущий текст вопроса показал действительный вывод из ntpq -pcrv что означало, что он работал, когда вы делали этот тест.

В более раннем редактировании вашего вопроса вы показали действительный вывод из ntpq -pcrv, который указывал, что ntp уже запущен. Возможно, у вас установлено более одной версии или вы пытаетесь запустить более одного экземпляра — вам также следует проверить это.

Сигнал 15 - это SIGTERM, что означает, что "что-то" прервало его, а не он умер/разбился и т. д.

Ниже мой файл конфигурации из бокса. (Это сервер S1 с напрямую подключенными эталонными часами, но я удалил лишние биты конфигурации)

#YOU SHOULD ALSO ADD:
interface ignore wildcard
interface listen eth0

driftfile /var/lib/ntp/drift
leapfile "/etc/ntp/leap-seconds.3676752000"

restrict default kod nomodify
restrict -6 default kod nomodify
restrict 127.0.0.1
restrict -6 ::1

server server1
server server2
server server3
server server4
server server5

#REQUIRES MCAST SETUP/CONFIG
broadcast 224.0.1.1 key 6
manycastserver 239.255.254.254

includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
trustedkey 6

Замените serverX своими собственными вышестоящими серверами — вам нужно минимум 3, в идеале 5 серверов для надежной работы ntp.

Перезапустите ntp и подождите некоторое время, затем запустите ntpq -pcrv и проверьте вывод. Ниже мой для справки;

    ntpq -pcrv
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-server1         10.10.10.14      2 u   50   64  377   29.791    0.421   0.147
-server2         .GPS.            1 u   66   64  377    9.694    0.255   0.218
#server3          10.10.10.74     2 u   23   64  377    7.376    0.685   0.057
+server4         .PPS.            1 u    3   64  377   16.979   -0.894   0.185
-server5         .DCFa.           1 u   13   64  377    9.016    0.481   0.251
 ntp.mcast.net   .MCST.          16 u    -   64    0    0.000    0.000   0.002
 LOCAL(0)        .LOCL.          10 l    -   64    0    0.000    0.000   0.000
+SHM(0)          .GPS.            0 l    6   16  377    0.000    6.366   8.976
*SHM(1)          .PPS.            0 l   16   16  377    0.000   -0.046   0.011
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd [email protected] Tue May 31 10:09:21 UTC 2016 (1)",
processor="x86_64", system="Linux/4.7.3-1.el6.elrepo.x86_64", leap=00,
stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.225, refid=PPS,
reftime=dbc612ab.93ca4dbf  Thu, Nov  3 2016 19:46:51.577,
clock=dbc612bc.05f5dedc  Thu, Nov  3 2016 19:47:08.023, peer=52638, tc=4,
mintc=3, offset=-0.129, frequency=-68.142, sys_jitter=0.115, clk_jitter=0.051, clk_wander=0.012, tai=36, leapsec=201507010000,
expire=201612010000

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

person user3788685    schedule 03.11.2016
comment
спасибо, и позвольте мне проверить ваш скрипт, я скоро сообщу вам о своем выводе. - person Sumit Gemini; 04.11.2016
comment
Проблема не воспроизводится. Я жду вопроса. Не могли бы вы сказать мне, какие журналы нам нужны, если мы получим эту проблему в будущем для отладки? - person Sumit Gemini; 19.11.2016
comment
Я бы следил за /var/log/messages и время от времени запускал бы ntpq -pcrv, чтобы проверить, все ли в порядке. Надеюсь, у вас больше не возникнет проблем. - person user3788685; 19.11.2016
comment
спасибо, на самом деле эта служба NTP работает на клиентской машине, так как я могу время от времени получать журналы ntpq -pcrv? У меня нет контроля над этой машиной. - person Sumit Gemini; 19.11.2016
comment
если у вас нет доступа к машине, то это немного сложно. в зависимости от того, насколько хороши ваши сценарии, вы можете сделать что-то, что подтягивает статистику, или вы можете пойти по маршруту RRD/MRTG. Честно говоря, nptd не известен своими журналами. - person user3788685; 19.11.2016