NeXuSs Опубликовано 19 февраля, 2013 (изменено) · Жалоба Здравствуйте! Прошу помощи у знающих людей. Опишу проблему. Имею сервер следующей конфигурации: uname -a FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Fri Feb 1 08:29:03 MSK 2013 root@...:/usr/obj/usr/src/sys/ROUTER amd64 /var/run/dmesg.boot CPU: Intel(R) Xeon(R) CPU E5430 @ 2.66GHz (2660.06-MHz K8-class CPU) <--- 2 таких процессора по 4 ядра real memory = 4294967296 (4096 MB) em0: <Intel(R) PRO/1000 Network Connection 7.3.2> port 0x3020-0x303f mem 0xb8820000-0xb883ffff,0xb8400000-0xb87fffff irq 18 at device 0.0 on pci5 em0: Ethernet address: 00:15:17:4f:cb:e4 em0: Using an MSI interrupt em1: <Intel(R) PRO/1000 Network Connection 7.3.2> port 0x3000-0x301f mem 0xb8800000-0xb881ffff,0xb8000000-0xb83fffff irq 19 at device 0.1 on pci5 em1: Ethernet address: 00:15:17:4f:cb:e5 em1: Using an MSI interrupt igb0: <Intel(R) PRO/1000 Network Connection version - 2.3.7> port 0x2020-0x203f mem 0xb9420000-0xb943ffff,0xb9000000-0xb93fffff,0xb9444000-0xb9447fff irq 34 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 90:e2:ba:31:6e:92 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: Bound queue 4 to cpu 4 igb0: Bound queue 5 to cpu 5 igb0: Bound queue 6 to cpu 6 igb0: Bound queue 7 to cpu 7 igb1: <Intel(R) PRO/1000 Network Connection version - 2.3.7> port 0x2000-0x201f mem 0xb9400000-0xb941ffff,0xb8c00000-0xb8ffffff,0xb9440000-0xb9443fff irq 35 igb1: Using MSIX interrupts with 9 vectors igb1: Ethernet address: 90:e2:ba:31:6e:93 igb1: Bound queue 0 to cpu 0 igb1: Bound queue 1 to cpu 1 igb1: Bound queue 2 to cpu 2 igb1: Bound queue 3 to cpu 3 igb1: Bound queue 4 to cpu 4 igb1: Bound queue 5 to cpu 5 igb1: Bound queue 6 to cpu 6 igb1: Bound queue 7 to cpu 7 Логическая схема подключения следующая: <локальная_сеть> --- <em0 сервер em1> --- <Интернет>. На сервере крутится шейпер ng_car, форвардятся белые IP адреса от абонента наружу, ната нет. Трафик бегает, абонент доволен :) (Единственное что вызывает вопросы - это подкрутка сервера под высокие скорости, идущие через него и тема а-ля "раскидать по ядрам isr, и надо ли это вобще, и т.д.", но это немного другая тема) Решили уйти от использования встроенных сетевых карточек em в пользу igb. В качестве igb - Intel Gigabit ET Dual Port Server Adapter на чипе 82576. Установил карточку в сервер, переткнул кабели из em0 и em1 в igb0 и igb1 соответственно. При загрузке FreeBSD карточки определились нормально. После загрузки наблюдаю такую картину - связи с миром в целом нет вообще, пинги до соседних хостов не ходят совсем, никуда. То есть с наскока переехать на них не удалось. Справедливости ради следует отметить, что кроме этого сервера имеется еще 2 (правда с установленной на них FreeBSD 8.2 STABLE), где установка таких же карточек не вызвала абсолютно никаких проблем, все завелось сразу же. Ладно. Отключил фаервол, убрал из автозапуска рабочие скрипты, проверил маршруты, убрал все подкрутки из loader.conf и sysctl.conf, обновил драйверы с версии 2.3.4 до 2.3.7, результат тот же - связи ни с чем нет. Пингуется только локалхост и свои адреса, выставленные в процессе загрузки из rc.conf, в логах тишина. Искал в Интернете похожую проблему и ее решение, ничего подобного не нашел. Наверное следует отметить, что до 9.1 фря обновлялась с 8.2, то есть 9.1 ставилась не с нуля. Подскажите пожалуйста, где и что можно посмотреть по этому поводу? Были ли у кого-нибудь подобные проблемы? Если нужна дополнительная информация - скажите только какая. Изменено 19 февраля, 2013 пользователем NeXuSs Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 февраля, 2013 · Жалоба мбуфов мало, карточке нужно больше. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Diman Опубликовано 19 февраля, 2013 · Жалоба мне хватило в /etc/sysctl.conf: kern.ipc.nmbclusters=204800 правда остался вопрос - может надо побольше ? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NeXuSs Опубликовано 19 февраля, 2013 · Жалоба Пробовал и с sysctl.conf загружаться: cat /etc/sysctl.conf net.inet.ip.fw.one_pass=1 #net.isr.dispatch=direct kern.ipc.maxsockets=204800 kern.ipc.somaxconn=65535 kern.ipc.maxsockbuf=83886080 kern.maxfiles=204800 kern.maxfilesperproc=200000 kern.ipc.nmbclusters=524288 kern.ipc.shmmax=67108864 net.inet.ip.intr_queue_maxlen=10240 net.inet.tcp.maxtcptw=40960 net.inet.tcp.nolocaltimewait=1 net.inet.ip.portrange.randomized=0 net.route.netisr_maxqlen=4096 net.graph.recvspace=8388608 net.graph.maxdgram=8388608 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=0 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=0 net.inet.ip.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.icmp.bmcastecho=0 net.inet.icmp.maskrepl=0 net.link.ether.inet.max_age=30 net.inet.ip.ttl=128 net.inet.tcp.drop_synfin=1 net.inet.tcp.syncookies=1 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 kern.random.sys.harvest.point_to_point=0 # Inerfaces em0 & em1 dev.em.0.rx_int_delay=200 dev.em.0.tx_int_delay=200 dev.em.0.rx_abs_int_delay=4000 dev.em.0.tx_abs_int_delay=4000 dev.em.1.rx_int_delay=200 dev.em.1.tx_int_delay=200 dev.em.1.rx_abs_int_delay=4000 dev.em.1.tx_abs_int_delay=4000 dev.em.0.rx_processing_limit=4096 dev.em.1.rx_processing_limit=4096 # Interfaces igb0 & igb1 dev.igb.0.rx_processing_limit=2048 dev.igb.1.rx_processing_limit=2048 cat /boot/loader.conf geom_mirror_load="YES" net.graph.maxdata=65536 net.graph.maxalloc=65536 # Isr #net.isr.numthreads=8 #net.isr.maxthreads=8 #net.isr.dispatch=direct #net.isr.defaultqlimit=4096 #net.isr.bindthreads=1 # Em hw.em.rxd=4096 hw.em.txd=4096 hw.em.max_interrupt_rate=32000 # Igb if_igb_load="YES" hw.igb.lro=0 hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.max_unterrupt_rate=32000 net.link.ifqmaxlen=10240 net.inet.tcp.syncache.hashsize=1024 net.inet.tcp.syncache.bucketlimit=100 net.inet.tcp.tcbhashsize=4096 То есть, загружаюсь с такими параметрами с шнурками в igb - не работает, выключаю сервер, возвращаю шнурки в em'ы, включаю - работает. Вобще сложилось такое ощущение, что системе по-барабану все эти подкрутки в данный конкретный момент, что дело в чем-то другом, но у меня ума не хватает понять в чем именно. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 февраля, 2013 · Жалоба Зачем выгрузите igb через лоадер, до тюнига буфов? в 9х модули можно грузить из rc.conf, они там грузятся после сисцтл, и грузятся быстрее чем в лоадере. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 19 февраля, 2013 (изменено) · Жалоба ifconfig хотябы частично покажите, если используются vlan, возможно забыли поменять vlandev. Или забыли поменять имена интерфейсов в нетграфе, соответственно будучи подключенными хуками не к тем сетевухам, ноды заворачивают трафик не туда. В общем скорее всего где-то не поменяли имена интерфейсов. Попробовать сделать down/up сетевухе, попробовать ifconfig igbN -rxcsum -txcsum -tco -lro и прочие флаги.... tcpdump -ni igbN в зубы и смотреть по трафику что именно происходит Изменено 19 февраля, 2013 пользователем umike Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NeXuSs Опубликовано 20 февраля, 2013 · Жалоба Для чистоты эксперимента решил взять другой винт и сделать чистую установку FreeBSD 9.1 - RELEASE amd64 на этом же сервере. Установка прошла штатно, опять-таки для чистоты, назначил IP адрес только одному интерфейсу igb1, который подключен напрямую к defaultrouter'у сервера. Пробую ping 127.0.0.1 - Ок До IP igb1 - Ок До defaultrouter - нет пинга. Поднял буфер nmbclusters до 524288, результат тот же. Пробую команду arp -a; сервер на минуту задумывается, затем выдает следующее: # arp -a ?(defaultrouter IP) at (incomplite) on igb1 expired [ethernet] ?(igb1 IP) at (igb1 MAC) on igb1 permanent [ethernet] И это на чистой фре без всего лишнего. Может ли быть такое, что сам слот PCIexpress, куда вставлена сетевуха, глючит таким образом или это вряд ли отразилось бы таким образом? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NeXuSs Опубликовано 20 февраля, 2013 · Жалоба Взял резервную железку (более слабую), вставил сетевушку, установил FreeBSD 9.1 - RELEASE amd64. Всё работает! Получается, что дело в железе. Но дело в том, что где-то около года назад в том же "проблемном" сервере стояла такая же сетевая карта и корректно работала (под FreeBSD 8.2 - STABLE). Сейчас она трудится в другом сервере под FreeBSD 8.2 - STABLE. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 февраля, 2013 · Жалоба cat /vat/log/messages Для чистоты эксперимента решил взять другой винт и сделать чистую установку FreeBSD 9.1 - RELEASE amd64 на этом же сервере. Это не винда, здесь и так всё диагностируется и чинится. Нормальная практика - обновление работающей системы пересборкой или бинарное. Всё что при этом вылазит, обычно описано заранее в соотвествующих файлах, и там же рекомендации по обновлению и правке конфигов. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NeXuSs Опубликовано 20 февраля, 2013 · Жалоба Понятно, буду знать ) Вобщем решилась проблема! Все дело оказалось в том, что почему-то в BIOS'е сервера был включен параметр 'Simulated MSI Support'! Так вот em'ы работали не обращая внимание на этот параметр, а igb отказались. После того, как сервер загрузился, все заработало в штатном режиме! Всем спасибо за внимание! Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...