Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Сеть. проблемы, диагностика / FreeBSD)
Изначальное сообщение		[ Отслеживать ]

"Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"	+/–
Сообщение от Oleg Ivanov 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 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 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 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ообщить модератору

	9. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"	+/–
	Сообщение от Karboras on 01-Мрт-18, 18:16
	> Кстати, обновил ОС до 11.1, проблема осталась. А у вас как дела? > Есть ли новости? Проблема решается сама собой после обновления до 11.1 (в моем случае - р6) Драйвера em и igb - штатные (ядро компилировалось из исходных текстов)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Проблема с сетью во FreeBSD 10.3 (routing/MAC-address table)"	+/–
	Сообщение от skeletor (ok) on 02-Мрт-18, 11:20
	>> Кстати, обновил ОС до 11.1, проблема осталась. А у вас как дела? >> Есть ли новости? > Проблема решается сама собой после обновления до 11.1 (в моем случае - > р6) > Драйвера em и igb - штатные (ядро компилировалось из исходных текстов) У меня как-то странно себя вело: после обновления были проблемы, спустя месяц - проблема исчезла. У меня 11.1-p1. Если будут, тогда буду обновляться до p6. Спасибо.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

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

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