The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Сеть. проблемы, диагностика / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"  +/
Сообщение от Oleg Ivanov email on 27-Июл-17, 18:00 
Наблюдается странная проблема с работой сетевых плат от Intel (em и igb) во FreeBSD 10.3 (FreeBSD 10.3 RELEASE p18 и p20):
сервера, которые работают шлюзами, иногда где-то через неделю, но м.б. и через пару дней стабильной работы перестают видеть некоторые компы в ЛВС. Что-то сбивается то ли в таблице МАС-адресов, то ли в маршрутизации:
на запросы локальных компов (повторю: не всех в ЛВС, а лишь некоторых) с IP-адресами в сети, непосредственно подключенной к внутреннему интерфейсу сервера, сервер отвечает _НЕ_ через внутренний сетевой интерфейс, а через один из внешних интерфейсов (обычно через тот, на котором default gateway - определяю по tcpdump/trafshow).
Проблема решается путем /etc/rc.d/routing restart
ifconfig down/up на внутреннем интерфейсе не помогает.
Причем тут роутинг - понять не могу (странный какой-то глюк)
Т.е. по идее, сервер ДОЛЖЕН видеть _ВСЕ_ локальные IP-адреса непосредственно на своем сетевом интерфейсе - без всяких таблиц маршрутизации. Но по факту _НЕКОТОРЫЕ_ компы перестает видеть, при том, что  остальные продолжает видеть.
IP-адресация в ЛВС - стандартная (типа 192.168.xx.0/24)
Вообще, конфиги на всех серверах однотипные, и на 6/7/8/9 никогда с подобным не сталкивался.
Но вот с переходом на 10-ку получил такую проблему
Кто-нибудь еще сталкивался?
Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"  +/
Сообщение от universite (ok) on 28-Июл-17, 09:28 
Смотрите свои коммутаторы, ибо там вымывается таблица MAC адресов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"  +/
Сообщение от butcher (ok) on 30-Июл-17, 11:55 
>[оверквотинг удален]
> сервера, которые работают шлюзами, иногда где-то через неделю, но м.б. и через
> пару дней стабильной работы перестают видеть некоторые компы в ЛВС. Что-то
> сбивается то ли в таблице МАС-адресов, то ли в маршрутизации:
> на запросы локальных компов (повторю: не всех в ЛВС, а лишь некоторых)
> с IP-адресами в сети, непосредственно подключенной к внутреннему интерфейсу сервера, сервер
> отвечает _НЕ_ через внутренний сетевой интерфейс, а через один из внешних
> интерфейсов (обычно через тот, на котором default gateway - определяю по
> tcpdump/trafshow).
> Проблема решается путем /etc/rc.d/routing restart
> ifconfig down/up на внутреннем интерфейсе не помогает.

Перед тем как отправить пакет IP стек выполняет поиск маршрута до адреса конечного получателя. В результате этого поиска определяется исходящий интерфейс для пакета и адрес назначения. Адрес назначения может отличаться от адреса конечного получателя. Затем в ARP таблице этого интерфейса находится L2 адрес, соответствующий адресу назначения. Если соответствеие найдено - пакет отправляется.

При возникновении проблемы постарайтейсь сохранить вывод команд `netstat -rn`, `arp -an`. Понаблюдайте какие счётчики ошибок изменяются в выводе `netstat -sp ip` и `netstat -sp arp`. Далее можно попробовать routing restart, и теперь сравнить различия в таблице маршрутизации.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"  +/
Сообщение от Oleg Ivanov email on 01-Авг-17, 15:14 
> При возникновении проблемы постарайтесь сохранить вывод команд `netstat -rn`, `arp -an`.
> Понаблюдайте какие счётчики ошибок изменяются в выводе `netstat -sp ip` и
> `netstat -sp arp`. Далее можно попробовать routing restart, и теперь сравнить
> различия в таблице маршрутизации.

Я, собственно, высказал суть проблемы, не вдаваясь в подробности диагностики.
И привел единственный найденный мною вариант решения.
Разумеется, и таблицу ARP, и таблицу маршрутов я смотрел внимательно.
Т.е. МАС-адреса с "потерянными" IP в ARP-таблице присутствуют; но пакеты на связанные IP-адреса все-равно идут через другой интерфейс - на шлюз во внешние сети (не обязательно на default gw: у меня как правило не одна внешняя сеть, а минимум 2, а то и 3-4)

Пока представляется, что проблема - в драйверах em и igb в 10-ке (начиная с 10.1 и до 10.3 включительно). Завтра на одном из проблемных серверов заменю em из ядра на драйвера из
/usr/ports/net/intel-em-kmod

К сожалению, драйвера для igb:
https://downloadcenter.intel.com/download/15815/Intel-Networ...-
на тестовом сервере не прокатили :(

Надеялся, что кто-нибудь еще сталкивался с подобным - ответили бы по-быстрому...

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"  +/
Сообщение от skeletor (ok) on 21-Авг-17, 13:22 
> Кто-нибудь еще сталкивался?

Я столкнулся. Удалось решить проблему? Пробовали обновляться до 11/11.1? У меня сейчас 10.1

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"  +/
Сообщение от Oleg Ivanov email on 22-Авг-17, 14:40 
>> Кто-нибудь еще сталкивался?
> Я столкнулся. Удалось решить проблему? Пробовали обновляться до 11/11.1? У меня сейчас
> 10.1

Я на боевых серверах ставлю только версии extended, а на экспериментальных серверах нет серьезной нагрузки и длительных uptime, поэтому про 11 ничего сказать не могу.
Возможно, что в 10.1 еще старая проблема:
https://habrahabr.ru/post/212813/
https://svnweb.freebsd.org/base/head/sys/netinet/ip_output.c...
В 10.3 данный патч уже есть (но от описанной проблемы не спасает)

Краткий сводный отчет:
1. Проблема - на всех моих серверах с 10.3, кроме одного; в чем его отличие - не пойму: конфиги ядра везде однотипные.
2. Замена ядерных драйверов em на ports/net/intel-em-kmod проблему не решает (а драйвера для igb на сайте Интел - только под Linux - заморачиваться с линукслятором я не стал)
3. Эксперименты с конфигом ядра кардинально проблему не решили: только увеличили длительность между routing restart
4. Пока работаю с костылем: в /etc/crontab поставил регулярные /etc/rc.d/routing restart

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"  +/
Сообщение от skeletor (ok) on 22-Авг-17, 14:51 
>[оверквотинг удален]
> В 10.3 данный патч уже есть (но от описанной проблемы не спасает)
> Краткий сводный отчет:
> 1. Проблема - на всех моих серверах с 10.3, кроме одного; в
> чем его отличие - не пойму: конфиги ядра везде однотипные.
> 2. Замена ядерных драйверов em на ports/net/intel-em-kmod проблему не решает (а драйвера
> для igb на сайте Интел - только под Linux - заморачиваться
> с линукслятором я не стал)
> 3. Эксперименты с конфигом ядра кардинально проблему не решили: только увеличили длительность
> между routing restart
> 4. Пока работаю с костылем: в /etc/crontab поставил регулярные /etc/rc.d/routing restart

Пока не тестировал, но есть костыльная идея: принудительно заворачивать трафик на нужный интерфейс через файервол (у меня pf, а там это делается через route-to).

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"  +/
Сообщение от Oleg Ivanov email on 29-Авг-17, 10:19 
> Пока не тестировал, но есть костыльная идея: принудительно заворачивать трафик на нужный
> интерфейс через файервол (у меня pf, а там это делается через
> route-to).

Ну криво же....

Еще одно наблюдение:
на том сервере, где проблемы нет, используется NATd вместо ipfw kernel-NAT
Тоже непонятно, как оно м.б. взаимосвязано
Попробую там перевести на ipfw NAT - отчитаюсь через неделю

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"  +/
Сообщение от skeletor (ok) on 19-Сен-17, 10:29 
>> Пока не тестировал, но есть костыльная идея: принудительно заворачивать трафик на нужный
>> интерфейс через файервол (у меня pf, а там это делается через
>> route-to).
> Ну криво же....
> Еще одно наблюдение:
> на том сервере, где проблемы нет, используется NATd вместо ipfw kernel-NAT
> Тоже непонятно, как оно м.б. взаимосвязано
> Попробую там перевести на ipfw NAT - отчитаюсь через неделю

Криво, но а какие есть варианты решения? Есть поставленная задача, её нужно решить. Если нет возможности правильно решить во вменяемые сроки - приходится делать костыли.

Кстати, обновил ОС до 11.1, проблема осталась. А у вас как дела? Есть ли новости?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема


  Закладки на сайте
  Проследить за страницей
Created 1996-2017 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor