Спонтанное отключение всех IPoE интерфейсов

IPoE related questions
KovAl
Posts: 91
Joined: 26 Dec 2017, 15:35

Re: Спонтанное отключение всех IPoE интерфейсов

Post by KovAl »

dimka88 wrote: 01 Jun 2018, 18:02 Сможете показать логи accel level=5 (-5 минут...падение интерфейса+5 минут)?
Не хотелось бы выкладывать в паблик конфиденциальные данные (логины/МАС) абонентов.. Да и объём будет приличный.
Плюс ко всему, лог у меня только level=4. Уровень логирования пришлось снизить из-за очень большого объёма лога. Он у меня парсится админкой.
Может на мыло выслать? Сбросьте в личку.
Axiator wrote: 01 Jun 2018, 18:11 В центосе любят над ядром колдовать. Не пробовали менять версию?
А Вы разве не заметили, что ядро и так НЕ родное? У CentOS 6.9 родное 2.6.32.хх
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: Спонтанное отключение всех IPoE интерфейсов

Post by dimka88 »

Судя по логу, падение происходит в 18:28:03

Code: Select all

[2018-05-31 18:28:03]:  info: eth0.3898.901: recv [RADIUS(1) Accounting-Response id=1]
[2018-05-31 18:28:03]:  info: eth0.3906.705: send ....
[2018-05-31 18:28:03]:  info: eth0.3906.705: recv [RADIUS(1) Accounting-Response id=4f]

//И тут отваливается интерфейс

[2018-05-31 18:28:03]:  warn: eth0.3708.113: radius: server(1) not responding
[2018-05-31 18:28:03]:  warn: radius: server(1) not responding
[2018-05-31 18:28:03]:  warn: eth0.3708.113: radius: no available servers
[2018-05-31 18:28:03]:  warn: eth0.3708.113: radius:acct: no servers available, terminating session...
[2018-05-31 18:28:03]: error: eth0.3708.113: radius:bind: Cannot assign requested address

// И далее accel начинает удалять vlan 
[2018-05-31 18:28:06]:  info: ipoe: remove vlan eth0.XXXX.XXX

// Далее сеть поднимается и все начинает функционировать
[2018-05-31 18:28:59]:  info: ipoe: create vlan eth0.3717.707 parent eth0.3717
[2018-05-31 18:28:59]:  info: ipoe: start interface eth0.3717.707 (mtu=1500)
С логами accel все нормально. Скиньте туда же на почту файлик /var/log/messages и вывод dmesg -T
ps:// Заметил интересный факт, не могу понять почему radius: server(1) not responding если он биндится на другом интерфейс, т.е. eth1
KovAl
Posts: 91
Joined: 26 Dec 2017, 15:35

Re: Спонтанное отключение всех IPoE интерфейсов

Post by KovAl »

dimka88 wrote: 05 Jun 2018, 20:40 Судя по логу, падение происходит в 18:28:03
Скорее всего, это всё-таки результат shutdown -r.
Обратите внимание на лог коммутатора, к которому подключен accel

Code: Select all

414   2018-05-31 18:29:04 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
413   2018-05-31 18:29:00 INFO(6) Port 1:6 link down
412   2018-05-31 18:28:58 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
411   2018-05-31 18:28:52 INFO(6) Port 1:6 link down
410   2018-05-31 18:28:28 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
409   2018-05-31 18:28:25 INFO(6) Port 1:6 link down
408   2018-05-31 18:28:13 INFO(6) Port 1:6 link up, 10Mbps FULL duplex
407   2018-05-31 18:28:10 INFO(6) Port 1:6 link down
406   2018-05-31 18:27:13 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
405   2018-05-31 18:27:09 INFO(6) Port 1:6 link down
Поэтому получается, что интерфейс упал в 18:27:09, поднялся (походу, только "физически") в 18:27, а в 18:28 сработал "сторож" и отправил машину в ребут.
Отсюда и это -
dimka88 wrote: 05 Jun 2018, 20:40 ps:// Заметил интересный факт, не могу понять почему radius: server(1) not responding если он биндится на другом интерфейс, т.е. eth1
Т.е. радиус перестаёт отвечать когда уже начался ребут.
dimka88 wrote: 05 Jun 2018, 20:40 Скиньте туда же на почту файлик /var/log/messages и вывод dmesg -T
dmesg -T - нет такой опции. Оба файла отправил.
Но скорее всего, они также не прольют свет на причину проблемы. Там на мой взгляд, совсем ничего про это..
KovAl
Posts: 91
Joined: 26 Dec 2017, 15:35

Re: Спонтанное отключение всех IPoE интерфейсов

Post by KovAl »

KovAl wrote: 06 Jun 2018, 08:49
dimka88 wrote: 05 Jun 2018, 20:40 Судя по логу, падение происходит в 18:28:03
Скорее всего, это всё-таки результат shutdown -r.
Обратите внимание на лог коммутатора, к которому подключен accel

Code: Select all

414   2018-05-31 18:29:04 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
413   2018-05-31 18:29:00 INFO(6) Port 1:6 link down
412   2018-05-31 18:28:58 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
411   2018-05-31 18:28:52 INFO(6) Port 1:6 link down
410   2018-05-31 18:28:28 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
409   2018-05-31 18:28:25 INFO(6) Port 1:6 link down
408   2018-05-31 18:28:13 INFO(6) Port 1:6 link up, 10Mbps FULL duplex
407   2018-05-31 18:28:10 INFO(6) Port 1:6 link down
406   2018-05-31 18:27:13 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
405   2018-05-31 18:27:09 INFO(6) Port 1:6 link down
Поэтому получается, что интерфейс упал в 18:27:09, поднялся (походу, только "физически") в 18:27,
а в 18:28 сработал "сторож" и отправил машину в ребут.
Отсюда и это -
dimka88 wrote: 05 Jun 2018, 20:40 ps:// Заметил интересный факт, не могу понять почему radius: server(1) not responding если он биндится на другом интерфейс, т.е. eth1
Т.е. радиус перестаёт отвечать когда уже начался ребут.
dimka88 wrote: 05 Jun 2018, 20:40 Скиньте туда же на почту файлик /var/log/messages и вывод dmesg -T
dmesg -T - нет такой опции. Оба файла отправил.
Но скорее всего, они также не прольют свет на причину проблемы. Там на мой взгляд, совсем ничего про это..
KovAl
Posts: 91
Joined: 26 Dec 2017, 15:35

Re: Спонтанное отключение всех IPoE интерфейсов

Post by KovAl »

dimka88 wrote: 05 Jun 2018, 20:40 Судя по логу, падение происходит в 18:28:03
Скорее всего, это всё-таки результат shutdown -r.
Обратите внимание на лог коммутатора, к которому подключен accel

Code: Select all

414   2018-05-31 18:29:04 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
413   2018-05-31 18:29:00 INFO(6) Port 1:6 link down
412   2018-05-31 18:28:58 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
411   2018-05-31 18:28:52 INFO(6) Port 1:6 link down
410   2018-05-31 18:28:28 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
409   2018-05-31 18:28:25 INFO(6) Port 1:6 link down
408   2018-05-31 18:28:13 INFO(6) Port 1:6 link up, 10Mbps FULL duplex
407   2018-05-31 18:28:10 INFO(6) Port 1:6 link down
406   2018-05-31 18:27:13 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
405   2018-05-31 18:27:09 INFO(6) Port 1:6 link down
Поэтому получается, что интерфейс упал в 18:27:09, поднялся (походу, только "физически") в 18:27,
а в 18:28 сработал "сторож" и отправил машину в ребут.
Отсюда и это -
dimka88 wrote: 05 Jun 2018, 20:40 ps:// Заметил интересный факт, не могу понять почему radius: server(1) not responding если он биндится на другом интерфейс, т.е. eth1
Т.е. радиус перестал отвечать, когда уже начался ребут.
dimka88 wrote: 05 Jun 2018, 20:40 Скиньте туда же на почту файлик /var/log/messages и вывод dmesg -T
dmesg -T - нет такой опции. Оба файла отправил.
Но скорее всего, они также не прольют свет на причину проблемы. Там на мой взгляд, совсем ничего про это..
Last edited by KovAl on 06 Jun 2018, 15:36, edited 1 time in total.
KovAl
Posts: 91
Joined: 26 Dec 2017, 15:35

Re: Спонтанное отключение всех IPoE интерфейсов

Post by KovAl »

Ну вот и прибежал очередной пушной зверёк.. :(
И снова в системных логах НИЧЕГО.. В kern.log только начало ребута (17:17:03)
Есть "новости" в логах коммутатора

Code: Select all

437   2018-06-06 17:18:03 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
436   2018-06-06 17:17:59 INFO(6) Port 1:6 link down
435   2018-06-06 17:17:58 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
434   2018-06-06 17:17:52 INFO(6) Port 1:6 link down
433   2018-06-06 17:17:27 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
432   2018-06-06 17:17:24 INFO(6) Port 1:6 link down
431   2018-06-06 17:17:12 INFO(6) Port 1:6 link up, 10Mbps FULL duplex
430   2018-06-06 17:17:09 INFO(6) Port 1:6 link down
429   2018-06-06 17:16:59 INFO(6) Port 1:6 link up, 1000Mbps FULL duplex
428   2018-06-06 17:16:55 INFO(6) Port 1:6 link down
Похоже на то, что eth0 сначала два (или три) раза прыгнул туда-сюда, потом его словил сторож и отправил машину в ребут.
Хотя.. Судя по kern.log - два up/down - это скорее всего уже в процессе ребута.

Code: Select all

Jun  6 17:17:03 ipoe-nas1 kernel: type=1305 audit(1528294623.655:72076): audit_pid=0 old=2294 auid=4294967295 ses=4294967295
Jun  6 17:17:03 ipoe-nas1 kernel: res=1
Jun  6 17:17:03 ipoe-nas1 kernel: type=1305 audit(1528294623.758:72077): audit_enabled=0 old=1 auid=4294967295 ses=4294967295
Jun  6 17:17:03 ipoe-nas1 kernel: res=1
Jun  6 17:17:03 ipoe-nas1 kernel: Kernel logging (proc) stopped.
Jun  6 17:17:58 ipoe-nas1 kernel: imklog 5.8.10, log source = /proc/kmsg started.
Jun  6 17:17:58 ipoe-nas1 kernel: Initializing cgroup subsys cpuset
Jun  6 17:17:58 ipoe-nas1 kernel: Initializing cgroup subsys cpu
Jun  6 17:17:58 ipoe-nas1 kernel: Initializing cgroup subsys cpuacct
Jun  6 17:17:58 ipoe-nas1 kernel: Linux version 3.10.108-1.el6.elrepo.x86_64 (mockbuild@Build64R6) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC) ) #1
SMP Sun Nov 5 10:54:49 EST 2017
......
Чертовщина какая-то..
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: Спонтанное отключение всех IPoE интерфейсов

Post by dimka88 »

1. Можно попробовать подгрузить модуль igb/ixgbe с уровнен логирования debug.
2. Попробуйте поднять debian на флэшке, зараннее поставив туда accel и прочие инструменты, и внедрить в ночное время. Поймем в чем проблема: в centos/kernel или в сетевой карте.
KovAl
Posts: 91
Joined: 26 Dec 2017, 15:35

Re: Спонтанное отключение всех IPoE интерфейсов

Post by KovAl »

dimka88 wrote: 06 Jun 2018, 18:02 1. Можно попробовать подгрузить модуль igb/ixgbe с уровнен логирования debug.
2. Попробуйте поднять debian на флэшке, зараннее поставив туда accel и прочие инструменты, и внедрить в ночное время. Поймем в чем проблема: в centos/kernel или в сетевой карте.
ИМХО, всё это будет пустая трата времени..
1. давайте исходить из реалий - если бы проблема была в драйвере, то падали бы ОБА интерфейса.
Плюс отсутствие error/warning во ВСЕХ системных сообщениях, наводит на мысль, что eth0 отправляется в down ШТАТНО,
т.е. типа ifconfig eth0 down. eth1 при этом не затрагивается совсем.
Отсюда предположение, что отключает eth0 либо accel, либо модуль ipoe. И ОС/ядро здесь не при делах..
Может проблема "несогласованности" находится не конкретно в ОС, или драйвере сетевух, а в их настройке?
Вот то, что у меня изменено по сетевым настройкам

Code: Select all

В rc.local:
/sbin/ethtool -K eth0 tso off tx off sg off
/sbin/ethtool -G eth0 rx 2048
/sbin/ethtool -G eth0 tx 2048
#
/sbin/ethtool -K eth1 tso off tx off sg off
/sbin/ethtool -G eth1 rx 2048
/sbin/ethtool -G eth1 tx 2048
#
#
/sbin/ifconfig eth0 txqueuelen 10000
/sbin/ifconfig eth1 txqueuelen 10000
#
В modprobe:

options igb IntMode=2,2 RSS=4,4 InterruptThrottleRate=100000,100000,100000,100000 QueuePairs=0,0,0,0
alias scsi_hostadapter ata_piix
options nf_conntrack hashsize=2097152
alias netdev-eth0 igb
alias netdev-eth1 igb

В sysctl.conf:

net.core.somaxconn=1024
net.ipv4.ip_local_port_range="15000 61000"
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_tw_reuse=1
net.core.netdev_max_backlog=2000
net.ipv4.tcp_max_syn_backlog=2048
#
net.netfilter.nf_conntrack_acct = 1

net.ipv4.neigh.default.gc_thresh1=2048
net.ipv4.neigh.default.gc_thresh2=4096
net.ipv4.neigh.default.gc_thresh3=16384
#

net.nf_conntrack_max = 16777216
#
#
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_loose = 3
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_established = 7200
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_checksum = 1
#
#
# ARP tunings
net.ipv4.neigh.default.gc_thresh1=2048
net.ipv4.neigh.default.gc_thresh2=4096
net.ipv4.neigh.default.gc_thresh3=8192
#
Может тут что-то не так "накручено"?

2. К сожалению, с debian-like ОС у меня очень поверхностное знакомство. Все 16 лет практики с *nix прошли на RedHat-like ОС.
Поэтому, накосячить ещё больше в debian мне не составит труда..


P.S. На сейчас хочу попробовать включить в accel log level=5 и заменить ребут в "стороже" на ifconfig eth0 up.. ifconfig eth0.3612.2502 up и т.д. по всем интерфейсам.

P.P.S. А вот это (выделил "красным") не может быть причиной -
ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: off
tx-checksum-ipv4: off
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off
scatter-gather: off
tx-scatter-gather: off
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
Может лучше отключить?
KovAl
Posts: 91
Joined: 26 Dec 2017, 15:35

Re: Спонтанное отключение всех IPoE интерфейсов

Post by KovAl »

И снова "здравствуйте"! :)
Вот она - толстая полярная лисичка - снова к нам пришла..
Новый "костыль" (без ребута, но с "апаньем" всех ифейсов) помог, всё взлетело без ребута.
В логах (системных) снова ничего, в accel.log с level=5 "до того как" (порт упал в 16:36:01) из подозрительного обнаружилось только это -

Code: Select all

[2018-06-07 16:35:52]: debug: connlimit: check entry 622
[2018-06-07 16:35:52]: debug: connlimit: remove 621
[2018-06-07 16:35:52]: debug: connlimit: remove 322
[2018-06-07 16:35:52]: debug: connlimit: add entry 622
[2018-06-07 16:35:52]: debug: connlimit: accept 622
В "самый-самый" момент (16:36:01) практически ничего интересного, кроме остановки/старта интерфейсов, что вроде бы логично

Code: Select all

[2018-06-07 16:36:01]:  info: ipoe: stop interface eth0.3898.1305
[2018-06-07 16:36:01]:  info: ipoe: remove vlan eth0.3898.1305
[2018-06-07 16:36:01]: debug: vlan-mon: notify 19 1305 0800 0
[2018-06-07 16:36:01]:  info: ipoe: create vlan eth0.3898.1305 parent eth0.3898
[2018-06-07 16:36:01]:  info: ipoe: start interface eth0.3898.1305 (mtu=1500)
Вывод ethtool eth0 перед "костылём" такой -
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: Unknown!
Duplex: Unknown! (255)
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: no
Что тоже логично.
Вообщем, пока буду жить с костылём, т.к. с ним абонентам не так грустно.
Жду предложений/решений..
dimka88
Posts: 866
Joined: 13 Oct 2014, 05:51
Contact:

Re: Спонтанное отключение всех IPoE интерфейсов

Post by dimka88 »

Accel не отключает!
По конструктиву, есть возможность поставить карту типа intel 82576 и изменить порт коммутатора?
KovAl wrote: 07 Jun 2018, 14:21 из подозрительного обнаружилось только это -

Code: Select all

[2018-06-07 16:35:52]: debug: connlimit: check entry 622
[2018-06-07 16:35:52]: debug: connlimit: remove 621
[2018-06-07 16:35:52]: debug: connlimit: remove 322
[2018-06-07 16:35:52]: debug: connlimit: add entry 622
[2018-06-07 16:35:52]: debug: connlimit: accept 622
Можете отключить модуль connlimit из секции [modules] и данные сообщения пропадут.
Post Reply