Перейти к содержимому
Калькуляторы

ХЕЛП!! Отваливается сетевуха на Linux router.

Меняю сервера на сети.

 

Конфигурация BGP роутеров, которые которые хочу заменить  – два древних сервера (xeon E5345). 
Дополнительно в каждый сервер установлена  двухпортовая карточка intel  (82576). Дистр leaf (ядро 2.6.35.14-i686) bird 1.3.6  + модуль ipt_netflow.
Тюнинг sysctl
#spoofprotect
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

 

в чнн нагрузка порядка 200000pps


Сервера одним интерфейсом смотрят  соотв, в провайдеров (eBGP, принимаю fv  +  default)  другим интерфейсом внутрь AS, по OSPF отдают дефолт соседям и между серваками iBGP разумеется. Как бы ничего сложного.  Работают серваки очень давно, практически беспроблемно.


Логика сети с точки зрения конфигурации BGP/OSPF при переносе на новые сервера сохраняется один в один.

 

Новые серваки - 1U,2хXeon E5620,2х4GB RAM, дополнительно установлены  карточки intel X520-DA2(82599ES), прерывания интерфейсов (eth3,eth2) прибиты к разным сокетам.  В sysctl перенес две строчки (см. в ыше).

 

Резервный сервер. 

 

ОДНА сетевуха (2 SFP+) один интерфес смотрит в аплинк, другой внутрь AS. Интерфейсы карточек включены DAC кабелями через промежуточный коммутатор.
Centos c ядром  kernel-ml-4.12.0-1.el6.elrepo.x86_64, bird 1.6.3, последний модуль ipt_netflow, дрова ixgbe version 5.1.3 ( последние).
Перевел на новый сервер трафик с аплинка - все взлетело с первой попытки, работает почти месяц.

 

Основной сервер.

 

ДВЕ 10г сетевухи (4 ре SFP+) (в сервере рейзер на две карты).
Centos kernel-ml-4.13.7-1.el6.elrepo.x86_64, bird 1.6.3,последняя версия модуля ядра ixgbe и ipt_NETFLOW.
Первая 10Г карточка подключена одним интерфейсом  DAC кабелем к коммутатору, вторым интерфейсом через SFP модуль в железку аплинка.
Вторая 10Г карточка пока никак физически не включена – просто установлена в сервер и ждет своего часа. 

 

И далее самое интересное.

 

Начинаю переводить на основной сервер трафик с резервного. Перевел частично входящий с аплинка –  5 минут полет нормальный. 
Перевожу исход в аплинк, исход отруливается и  через 5 минут теряю сервак – сервак не пускает даже через консоль ipmi. 
НО!!!  linux в нем работал, т.к. настроен ipmi watchdog  и сервер не перегрузился автоматически.

 

После ребута по питалову через  ipmi, в логах ничего не хорошего не обнаруживаю ВООБЩЕ. Это понятно – ребут по питалову.

 

Меняю на сервере ядро – возвращаю, которое шло при установке kernel-2.6.32-696.13.2.el6.x86_64, ixgbe  (который шел с  ядром ver 4.2.1-k), модуль ipt_netflow последний, bird 1.6.3. 
Снова перевожу трафик и снова после отруливания исхода в аплинк проходит несколько минут (минуты три-пять) и сервак снова отваливается. 
Загрузка перед отвалом 85000 pps (нагрузка никакая).
Однако  сервак успевает выплюнуть на ipmi консоль сообщение  - см картинку. eth3 - Интерфейс который смотрит внутрь AS.

Через ipmi консоль сервер пустил, bird работал. Перегрузил сервер с командной строки.

 

При проверке на перегрев "сбойнувшей" сетевухи на этом сервере сделал петлю между 10Г интерфейсами DAC кабелем и сбриджевал интерфейсы в linux   – погонял трафик – 200000 pps через оба интерфейса, при этом карточка не отваливается!!!  Прерываний в системе было не много, два ядра процессоров разных сокетово в 100%загрузились, видимо так работает модуль бриджа в linux.


Вот такой случился случай…   

 

Какие будут мысли? Куда глянуть? В sysctl может что то не хватает? Ядро с какими параметрами лучше грузить? Две карточки в одном рейзере друг над другом – нормально?
Какие дебаги собрать для следующей попытки перевода трафика?   
Какие команды выполнить с консоли если карточка снова отвалится?

 

PS

Пока думаю поставить kernel-lt-3.10.108-1.el6.elrepo.x86_64.rpm  или поменять дистрибутив на debian. 
Попробую вынуть из сервера вторую не используемую 10Г карточку.
 

ОШибка_10г_сетевуха.png

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да тут однозначно надо ядро апдейтить. с вероятностью 99.9% проблема решится

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

10 минут назад, s.lobanov сказал:

да тут однозначно надо ядро апдейтить. с вероятностью 99.9% проблема решится

на какое лучше?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На  4.14. А какой софт используется для BGP?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в сервере процы/память тестили под нагрузкой (БЕЗ сетевух)? после описанных ребутов объем памяти не уменьшался (типа как один модуль памяти пропал)?

конфигами берда поделитесь? )) интересует та часть, которая за ibgp+ospf вовнутрь отвечает.

 

ps: и я б поставил не 2х4гб, а 6х2. там же трехканальный контроллер.

Изменено пользователем nixx

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Недавно столкнулся с похожим поведением на свежеустановленной Ubuntu 17.10 Server.

 

При включении BGP FV от пары провов - через некоторое время отваливалась сеть. То ли ядро, то ли еще что, поставил 16.04 - все хорошо, не отваливается...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

6 часов назад, nixx сказал:

в сервере процы/память тестили под нагрузкой (БЕЗ сетевух)? после описанных ребутов объем памяти не уменьшался (типа как один модуль памяти пропал)?

конфигами берда поделитесь? )) интересует та часть, которая за ibgp+ospf вовнутрь отвечает.

 

ps: и я б поставил не 2х4гб, а 6х2. там же трехканальный контроллер.

Здесь на форуме говорили что третий канал памяти значительно увеличивает latency или что типа того. Имеет смысл использовать два канала памяти для каждого проца. Можно доустановить еще 2х4ГБ. После ребутов - на память не смотрел, сейчас в сервере 2х4GB (по top в 2.6.32 8049620k) По iBGP+OSPF в личку написал, дабы тему не засорять.

 

6 часов назад, ne-vlezay80 сказал:

На  4.14. А какой софт используется для BGP?

bird 1.6.3.   

да, есть такое ядро

# yum list | grep kernel | grep 4.14.0
kernel-ml.x86_64                            4.14.0-1.el6.elrepo          elrepo-kernel
 

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Управление питанием в BIOS включено? ASPM на PCI? Глубокие CPU C-States? Попробуйте это все отключить.

Изменено пользователем Умник

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

13 часов назад, Hawk128 сказал:

Недавно столкнулся с похожим поведением на свежеустановленной Ubuntu 17.10 Server.

 

При включении BGP FV от пары провов - через некоторое время отваливалась сеть. То ли ядро, то ли еще что, поставил 16.04 - все хорошо, не отваливается...

У меня давно уже на арче сеть отвалилась потому что арпкеш забился или что то ещё с ним не то было, решилось в 3 строчки сисцтл крутилок.

# ARP tunings
net.ipv4.neigh.default.gc_thresh1=2048
net.ipv4.neigh.default.gc_thresh2=4096
net.ipv4.neigh.default.gc_thresh3=8192

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Было такое один в один.

Все перепробовал - версии драйверов, разные ядра, настройки рингов и тд.

В конечном итоге снял сетевуху и рэйзер, протер контакты спиртом. На ватке остались желтые пятна после рэйзера.

Продул разъем, все установил. При этом старался поставить карточку, максимально утопив в разъем. Там есть небольшой разбег у самореза крепления планки.

После этого полет норм уже 1 год.

 

Это хардварные проблемы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, Умник сказал:

Управление питанием в BIOS включено? ASPM на PCI? Глубокие CPU C-States? Попробуйте это все отключить.

это все настройки в BIOS нужно делать или ядро linux  грузить с параметрами?

С какими параметрами грузить ядро?

 

2 часа назад, sekuzz сказал:

Было такое один в один.

Все перепробовал - версии драйверов, разные ядра, настройки рингов и тд.

В конечном итоге снял сетевуху и рэйзер, протер контакты спиртом. На ватке остались желтые пятна после рэйзера.

Продул разъем, все установил. При этом старался поставить карточку, максимально утопив в разъем. Там есть небольшой разбег у самореза крепления планки.

После этого полет норм уже 1 год.

 

Это хардварные проблемы.

я конечно протру спиртом и перевоткну все дивайсы в слотах. НО как вяжется с тестами по 200000 тысяч пакетов через каждый интерфейс?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, Ivan_83 сказал:

У меня давно уже на арче сеть отвалилась потому что арпкеш забился или что то ещё с ним не то было, решилось в 3 строчки сисцтл крутилок.


# ARP tunings
net.ipv4.neigh.default.gc_thresh1=2048
net.ipv4.neigh.default.gc_thresh2=4096
net.ipv4.neigh.default.gc_thresh3=8192

сервер стоит как бордер. у него 10 соседей внутри AS и один eBGP нейбор. Старый сервер работает с настройками

net.ipv4.neigh.default.gc_thresh1 = 128

net.ipv4.neigh.default.gc_thresh2 = 512

net.ipv4.neigh.default.gc_thresh3 = 1024

 

Можно конечно воткнуть

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

14 часов назад, QWE сказал:

я конечно протру спиртом и перевоткну все дивайсы в слотах. НО как вяжется с тестами по 200000 тысяч пакетов через каждый интерфейс?

У меня тоже без нагрузки ошибок не было.

Давал нагрузку (было порядка 50kpps) и через 5-10 мин начинало сыпать в консоль ошибки с отвалом доступа по ip.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 17.11.2017 в 14:23, sekuzz сказал:

У меня тоже без нагрузки ошибок не было.

Давал нагрузку (было порядка 50kpps) и через 5-10 мин начинало сыпать в консоль ошибки с отвалом доступа по ip.

 

Вынул сетевку из бордера и протестил trex ом (с другого компа) через петлю, тест проходит без к.л. ошибок и отвалов. 

 

Однако  поведение бордера с сетеухой сейчас такое. Сколько бы пакетов  не летело с trex (хоть 1000 в секунду, хоть миллион) все равно  через 5-6 секунд на бордере перестают форвардится пакеты (/usr/bin/sar -n DEV 1)   на вход  интерфейса видно что летят а исход прекращается. что на 3.10 ядре, что на 4.12, что на 4.14 ядре.

 

Поставил на бордер trex (на другой ЖД) сделал петлю, прогнал trex все тесты чистые.

 

Тупик.

 

dmesg на этом сервере пишет ошибку

 

tsc: Fast TSC calibration failed

 

 

PS.

Текст сообщения исправлен.

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 16.11.2017 в 01:55, ne-vlezay80 сказал:

На  4.14. А какой софт используется для BGP?

на 4.14 дрова ixgbe с сайта intel не компилятся

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 17.11.2017 в 20:03, QWE сказал:

на 4.14 дрова ixgbe с сайта intel не компилятся

kmod-ixgbe.x86_64 : ixgbe kernel module(s)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 16.11.2017 в 23:51, QWE сказал:

это все настройки в BIOS нужно делать

Именно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Очень похоже на проблему с железом.

Как вариант - попробуйте проапгрейдить биос, поиграть там с настройками.

Следующее на очереди только смена карты и сервера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 15.11.2017 в 23:35, s.lobanov сказал:

да тут однозначно надо ядро апдейтить. с вероятностью 99.9% проблема решится

Сделал даунгрейд ядра на основном сервере.

Для основного сервера сделал копию диска резервного сервака (Centos c ядром  kernel-ml-4.12.0-1.el6.elrepo.x86_64, bird 1.6.3, последний модуль ipt_netflow, дрова ixgbe version 5.1.3).  Работает 5 день (тьфу,тьфу,тьфу).

 

сервер и сетевухи - гонял trex ом. ничего не отваливалось.

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.