orca

Тоже пришлось с quagga на frr переходить. Когда quagga на 13.0 добавляет в систему маршруты в dmesg вот такое сыпется: mask sin_len too small frr вроде работает нормально

Это все пробовал. Оно меняет количество очередей сетевой карты, но эти очереди потом распределяются по if_io_tqg_ количество которых равно количеству ядер в системе. При двух процессорах работают только if_io_tqg_ которые привязаны к первому процессору. В рассылку не писал. Честно говоря никогда туда не писал только читал иногда.

Здравствуйте, пишу сюда чтоб не плодить темы. Недавно обновился до FreeBSD 13, но началось все еще с 12 как появился iflib. Поведение на разных серверах, аналогичное. CPU 2 x CPU E5-2670 Сетевая карта ix, драйвер стандартный который идет с системой Как я понял при загрузке создаются потоки для каждого ядра процессора. procstat -at | grep if_io 0 100019 kernel if_io_tqg_0 -1 24 sleep - 0 100020 kernel if_io_tqg_1 -1 24 sleep - 0 100021 kernel if_io_tqg_2 -1 24 sleep - 0 100022 kernel if_io_tqg_3 -1 24 sleep - 0 100023 kernel if_io_tqg_4 -1 24 sleep - 0 100024 kernel if_io_tqg_5 -1 24 sleep - 0 100025 kernel if_io_tqg_6 -1 24 sleep - 0 100026 kernel if_io_tqg_7 -1 24 sleep - 0 100027 kernel if_io_tqg_8 -1 24 sleep - 0 100028 kernel if_io_tqg_9 -1 24 sleep - 0 100029 kernel if_io_tqg_10 -1 24 sleep - 0 100030 kernel if_io_tqg_11 -1 24 sleep - 0 100031 kernel if_io_tqg_12 -1 24 sleep - 0 100032 kernel if_io_tqg_13 -1 24 sleep - 0 100033 kernel if_io_tqg_14 -1 24 sleep - 0 100034 kernel if_io_tqg_15 -1 24 sleep - Когда даю нагрузку на сеть, судя по top работают только первые 8 потоков, которые работают с первым процессором. Получается второй процессор вообще не используется. Пробовал разные комбинации тюнинга sysctl не получается с iflib задействовать второй процессор. Помогает только поставить драйвер ix из портов. Тогда появляется по 8 потоков на каждый порт сетевой карты, которые можно распределить по ядрам всех процессоров. Но так не всегда удобно, если в сервере более 16 ядер то лишние не используются, а если менее 16 то попадает по несколько потоков на одно ядро. Думал может в FreeBSD 13 что то изменилось, но нет.

Спасибо помогло. Еще добавил это: https://reviews.freebsd.org/D22848

Да snooping умеет, если в ipfw на сервере режу igmp, мультикаст пропадает. В tcpdump вижу igmp reportы. Утилита ifmcstat показывает кучу групп. В описании утилиты написано: "The ifmcstat command dumps multicast group information from the kernel." Как убрать эти группы из ядра и почему они сами не убираются, неясно.

Это не мультикаст влан, это обычный влан с мультикастом. С дропами я разобрался. Вопрос не в этом. Я разбирался почему на сервер приходит мультикаста в два раза больше чем уходит юникаста на клиентов. Непонятно почему фря продолжает слать igmp reportы после того как канал смотреть перестали. msd_lite попробую, может действительно поможет.

Есть сервер FreeBSD 12.1-RELEASE-p1 GENERIC amd64, один физический интерфейс, в нем два vlan. Один влан смотрит в Интернет, другой принимает мультикаст. Запущен udpxy. Клиент из интернет подключается к udpxy, сервер шлет igmp запрос в vlan с мультиксат, в ответ получает мультикаст поток и передает его по http клиенту, сервер периодически шлет igmp report. Все хорошо, все работает. Начались жалобы на пропадания кадров. Заметил очень большую разницу в объемах трафика между вланами. Стал разбираться. Оказалось после того как клиент от канала отключился, либо переключил на другой канал, сервер все равно продолжает слать igmp reportы, и получает мультикаст. На сервер идут все потоки которые когда либо смотрели, не зависимо от того смотрят их сейчас или нет. Даже если полностью убить udpxy, мультикаст продолжает идти на сервер. Если запретить в фаерволе igmp, через пару минут мультикаст останавливается (на свиче igmp snooping работает правильно), после удаления правил все возвращается. Утилита ifmcstat показывает все группы на которые подписан сервер. Как их оттуда убрать я не нашел. Пробовал на стороне источника мультикаст переключать igmp v2 и v3, на сервере igmp тоже переключается вслед за источником, но группы он не покидает. ОС обновил с 11.2, там она вела себя аналогично.

Здравствуйте. Никто не смог подружить pppoe mpd5 с FreeBSD 10x ? Сейчас у меня FreeBSD 9.3 + MPD 5.7_3, в пике 800-850 pppoe сессий. Работает относительно стабильно. Где то год назад, когда обновлял железо пытался запустить на десятке. Тогда сервер, после непродолжительной работы уходил в ступор и реагировал только на ресет, что конкретно писал в лог уже не вспомню.

Я откатился на 9,2 проблема решилась. Видимо не все гладко у десятки с нетграфом.

А кто нибудь решил первоначальную проблему с FreeBSD 10 и mpd 5.7 ? Или только откатывать на 9.2? У меня после обновления до 10.0 тоже стали появляться такие зависания с umtxn. Никак не могу вычислить зависимость. Может зависнуть в час пик когда много сессий и наоборот рано утром когда нагрузка минимальна.

Удивительно, вчера поставил ваши значения sysctl уже сутки прошли, полет нормлаьный. Буду наблюдать дальше.

Вот vmstat -z сейчас, как только проявится проблема выложу vmstat в момент проблемы. vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 208, 0, 91, 11, 91, 0 UMA Zones: 320, 0, 91, 5, 91, 0 UMA Slabs: 568, 0, 2884, 7, 68964, 0 UMA RCntSlabs: 568, 0, 13113, 5, 75138, 0 UMA Hash: 256, 0, 0, 0, 3, 0 16 Bucket: 152, 0, 15, 110, 157, 0 32 Bucket: 280, 0, 72, 110, 352, 2 64 Bucket: 536, 0, 113, 27, 640, 12 128 Bucket: 1048, 0, 3274, 8, 56099548, 84810 VM OBJECT: 216, 0, 60394, 23576, 324540970, 0 MAP: 232, 0, 7, 25, 7, 0 KMAP ENTRY: 120, 150660, 52, 320, 124643, 0 MAP ENTRY: 120, 0, 1963, 185773, 3364430189, 0 DP fakepg: 120, 0, 0, 0, 0, 0 SG fakepg: 120, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 273, 6, 273, 0 16: 16, 0, 2942, 922, 1615660809, 0 32: 32, 0, 4034, 2228, 311547309, 0 64: 64, 0, 7830, 12498, 284182348, 0 128: 128, 0, 7719, 7448, 20336634, 0 256: 256, 0, 12708, 25347, 299483174170, 0 512: 512, 0, 1976, 9119, 1138660582, 0 1024: 1024, 0, 96, 472, 4627799, 0 2048: 2048, 0, 97, 733, 8038099, 0 4096: 4096, 0, 410, 802, 13880322, 0 Files: 80, 0, 155, 2095, 436712459, 0 TURNSTILE: 136, 0, 970, 70, 970, 0 umtx pi: 96, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0 PROC: 1120, 0, 59, 730, 13553375, 0 THREAD: 1112, 0, 865, 104, 1116, 0 SLEEPQUEUE: 80, 0, 970, 74, 970, 0 VMSPACE: 392, 0, 37, 733, 13553349, 0 cpuset: 72, 0, 11, 139, 11, 0 audit_record: 952, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 8286, 576, 584479950323, 335140 mbuf: 256, 0, 2, 2086, 27383308637, 0 mbuf_cluster: 2048, 25600, 8862, 16738, 7031947819, 658150 mbuf_jumbo_page: 4096, 12800, 0, 313, 120836, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 NetGraph items: 72, 4118, 0, 0, 0, 0 NetGraph data items: 72, 522, 0, 0, 0, 0 g_bio: 232, 0, 0, 12640, 31502129, 0 ttyinq: 160, 0, 150, 186, 1215, 0 ttyoutq: 256, 0, 80, 100, 648, 0 ata_request: 320, 0, 0, 36, 20, 0 ata_composite: 336, 0, 0, 0, 0, 0 VNODE: 472, 0, 93692, 14156, 28310950, 0 VNODEPOLL: 112, 0, 0, 66, 1, 0 S VFS Cache: 108, 0, 104006, 14662, 26684396, 0 L VFS Cache: 328, 0, 379, 25505, 2097288, 0 NAMEI: 1024, 0, 0, 796, 362732275, 0 DIRHASH: 1024, 0, 1609, 287, 23231, 0 NFSMOUNT: 624, 0, 0, 0, 0, 0 NFSNODE: 688, 0, 0, 0, 0, 0 pipe: 728, 0, 2, 368, 12559613, 0 ksiginfo: 112, 0, 774, 777, 231712, 0 itimer: 344, 0, 0, 99, 5355, 0 KNOTE: 128, 0, 21, 2183, 1522203985, 0 socket: 680, 25602, 65, 2005, 314696049, 0 unpcb: 240, 25600, 34, 350, 551700, 0 ipq: 56, 819, 0, 378, 203694, 0 udp_inpcb: 336, 25608, 12, 2012, 305972843, 0 udpcb: 16, 25704, 12, 2172, 305972843, 0 tcp_inpcb: 336, 25608, 16, 699, 1861363, 0 tcpcb: 880, 25600, 15, 181, 1861363, 0 tcptw: 72, 5150, 1, 999, 1745493, 0 syncache: 144, 15366, 0, 286, 1698491, 0 hostcache: 136, 15372, 2, 138, 664, 0 tcpreass: 40, 1680, 0, 420, 7047, 0 sackhole: 32, 0, 0, 505, 408, 0 sctp_ep: 1272, 25602, 0, 0, 0, 0 sctp_asoc: 2240, 40000, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 144, 5, 0 sctp_raddr: 616, 80004, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0 sctp_stream_msg_out: 96, 400026, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0 ripcb: 336, 25608, 3, 393, 6310120, 0 rtentry: 200, 0, 56, 191, 874, 0 IPFW dynamic rule: 120, 0, 0, 0, 0, 0 selfd: 56, 0, 964, 1052, 385319447, 0 SWAPMETA: 288, 116519, 162, 5207, 698275, 0 ip4flow: 56, 99351, 877, 18338, 229198098, 0 ip6flow: 80, 99360, 0, 0, 0, 0 Mountpoints: 752, 0, 5, 10, 5, 0 FFS inode: 168, 0, 93654, 18766, 28310328, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 93654, 18201, 28310327, 0

Здравствуйте, есть такая проблема: Система FreeBSD 8.2-RELEASE-p3, ядро GENERIC amd64. Иногда, не зависимо от нагрузки на роутер, перестаёт идти трафик через один VLAN. В этом влане у меня абоненты. В логах пусто. Кроме перезагрузки помогает только выключение и включение самого интерфейса ifconfig igb1 down, ifconfig igb1 up. Никакой зависимости от времени суток, количества пакетов, количества абонентов в сети, нагрузки на процессор я не нашел. Что это может быть и как с этим бороться?

Да процессор не справляется, не расчитывали на такой скаче нагрузки. Сейчас другое железо подбираем.

У меня такая же беда. С начала ДНСы стали спотыкаться, поменял bind на unbound, теперь бордер мрет. Что с этой заразой делать, неясно.