Jump to content
Калькуляторы

orca

Активный участник
  • Content Count

    197
  • Joined

  • Last visited

About orca

  • Rank
    Студент

Контакты

  • ICQ
    112838284

Информация

  • Пол
    Мужчина

Город

  • Город
    Украина Белгород-Днестровский
  1. Спасибо помогло. Еще добавил это: https://reviews.freebsd.org/D22848
  2. Да snooping умеет, если в ipfw на сервере режу igmp, мультикаст пропадает. В tcpdump вижу igmp reportы. Утилита ifmcstat показывает кучу групп. В описании утилиты написано: "The ifmcstat command dumps multicast group information from the kernel." Как убрать эти группы из ядра и почему они сами не убираются, неясно.
  3. Это не мультикаст влан, это обычный влан с мультикастом. С дропами я разобрался. Вопрос не в этом. Я разбирался почему на сервер приходит мультикаста в два раза больше чем уходит юникаста на клиентов. Непонятно почему фря продолжает слать igmp reportы после того как канал смотреть перестали. msd_lite попробую, может действительно поможет.
  4. Есть сервер 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, там она вела себя аналогично.
  5. Здравствуйте. Никто не смог подружить pppoe mpd5 с FreeBSD 10x ? Сейчас у меня FreeBSD 9.3 + MPD 5.7_3, в пике 800-850 pppoe сессий. Работает относительно стабильно. Где то год назад, когда обновлял железо пытался запустить на десятке. Тогда сервер, после непродолжительной работы уходил в ступор и реагировал только на ресет, что конкретно писал в лог уже не вспомню.
  6. Я откатился на 9,2 проблема решилась. Видимо не все гладко у десятки с нетграфом.
  7. А кто нибудь решил первоначальную проблему с FreeBSD 10 и mpd 5.7 ? Или только откатывать на 9.2? У меня после обновления до 10.0 тоже стали появляться такие зависания с umtxn. Никак не могу вычислить зависимость. Может зависнуть в час пик когда много сессий и наоборот рано утром когда нагрузка минимальна.
  8. Удивительно, вчера поставил ваши значения sysctl уже сутки прошли, полет нормлаьный. Буду наблюдать дальше.
  9. Вот 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
  10. Здравствуйте, есть такая проблема: Система FreeBSD 8.2-RELEASE-p3, ядро GENERIC amd64. Иногда, не зависимо от нагрузки на роутер, перестаёт идти трафик через один VLAN. В этом влане у меня абоненты. В логах пусто. Кроме перезагрузки помогает только выключение и включение самого интерфейса ifconfig igb1 down, ifconfig igb1 up. Никакой зависимости от времени суток, количества пакетов, количества абонентов в сети, нагрузки на процессор я не нашел. Что это может быть и как с этим бороться?
  11. Да процессор не справляется, не расчитывали на такой скаче нагрузки. Сейчас другое железо подбираем.
  12. У меня такая же беда. С начала ДНСы стали спотыкаться, поменял bind на unbound, теперь бордер мрет. Что с этой заразой делать, неясно.
  13. Подойдет ли Extreme BD 12802, на бордер для небольшой сети на 2К-3К пользователей.
  14. Кстати подобная проблема стала появляться и у меня на hp proliant dl360 g7 Система FreeBSD 8.1 AMD64 Сетевая внешняя двухпортовая intel (igb) С прошлой ночи начались проблемы с vlan. Без каких либо видимых причин некоторые вланы перестают работать. В таблице arp этих вланов все хосты incomplete кроме самого себя. Помогает удалить и потом создать влан, либо перезагрузить весь сервер. За последние сутки проблема появлялась 3 раза, в логах всё девственно чисто. З.Ы. Вряд ли проблема в железе так как сервера 2 одинаковых. 2 раза глюкнуло на одном и 1 раз на другом.
  15. Присоединюсь к вопросу. Сейчас стоит: core2duo E8400 2Gb DDR2 сетевая Intel PRO/1000 двухголовая система FreeBSD 7.3 AMD64, nat ng_nat, шейпер IPFW + DUMMYNET, netflow ng_netflow отправляет на другую машину Выше 140 килопакетов, начинаются потери пакетов, процессор загружен под завязку. Что посоветуете? Апгрейд на core2quad Апгрейд на corei5 DDR3 Апгрейд на FreeBSD 8.0 Тюнинг sysctl Поставить рядом ещё одну такую же машину и распределить нагрузку Ещё хотелось бы узнать какой максимум можно из данной конфигурации выжать.