l1ght

Ну это разве что ставить свич и зеркалить на порт, а на втором порте сидеть с ваершарком. Да и мне ipfw по вкус, удобно просто, нет километровых конфигов.

Да я как раз это и прочитал. Ну я так линукс не очень люблю.... Но когда такой выбор стоит - тут уж придётся

Тут нас + биллинг в одной коробке Насколько я помню линуха поддержка была и гарантированя работа исключительно как биллинга. Качаю убунту.. буду тестить.

Ты хоть сам понимаешь, какая пропасть поколений между Pentium 4 и Pentium G sandy bridge? Значит не железо виновато, рекомендация стандартна - сносите BSD, ставьте linux. Да я вот думаю в сторону accel-ppp с ipoe, только вот у меня стоит Ubilling, такой он теплый и родной Не хочется никуда переходит, да и с фрей мне как-то проще, если не считать этого момента с падением в кору. По поводу проца - ну я просто перепутал, поэтому и вылажил строчку hw.model, дабы вопросы о железе отпали.

А я думал я один такой дурак ) Меня кстати net.isr спасал в такие моменты. Когда он был выключен - его включение спасло сервер от падения в кору, он конечно был нагружен очень, но нормально себя чувствовал. Кстати кто ещё подскажет - не хотят грузится параметры из loader.conf после недавнего мажорного обновления с 9.0 до 9.2. Лично у меня спам на определенный порт отменяется, т.к. 6881 порт у меня ничем не слушается и включен blackhole. Да и вообще, сокстат никакого криминала не показывает Я правило с каунтом добавил - но думаю счётчик вообще дергатся не будет. И почему сразу выкинуть железо? Ну живёт оно себе нормально, не перенагружается hw.model: Intel® Pentium® CPU G860 @ 3.00GHz Завернуть траф на соседний порт свича просто не могу, т.к. аплинк зашёл прямо в машину.

А кхм, если вы про это http://habrahabr.ru/post/168607/ - сначала внешняя сетевая была 82574L, а потом, всё переехало на двух портовую серверную. И была ровно та же жопа...

Вот как.... Чтож тогда всё стало понятно, значит будем думать про замену! Очень благодарен. Но если сменим карточки и будет та же фигня, с меня начальство шкуру-то снимет ) Так что жду ещё идей не так давно разработчики интела заметили уязвимость, при которой наступал п@зд#ц при конкретном SIP пакете. Не твой случай? Да у меня вообще sip трафик незамечен, и ничего у меня вроде его не использует. Если не ошибаюсь SIP - для айпи телефонии?

выкидывате эти, ставьте с чипом не менее 82576. На моей практике все сетевухи подобные вашей начинали дохнуть при 12к ппс и окончательно дохли при 18к. Никакими тьюнингами и "яндексовскими" драйверами проблема не устранялась. Яндексовские дрова максимум что могли - это облегчить жизни на исходящем трафике PS: в моём случае ОС - FreeBSD. На линуксе с 82579 чипом 480к ппс шуршит с 17% нагрузки на проц. ну и посмотрите что именно проц нагружает pmcstat -S instructions -O /tmp/sample.out & sleep 30 && killall pmcstat pmcstat -R /tmp/sample.out -g && gprof -l -K INSTR_RETIRED_ANY/kernel |head -n 60 | tail -n 25 Спасибо за подсказку, буду смотреть. Не знаю, как у вас при 18кппс загибалось, у меня всё шуршит аж бегом Только вот у моей проблемы нет никакой систематики, по крайней мере не было. Может профайлинг чего покажет... Совершенно от нагрузки не зависит, только чаще вечером вылетает, но бывает и днем при мизерной нагрузке

Сетевухи аж 3, одна двух портовая inter pro/1000 pt dual port server adapter а ещё 2 на чипе device = '82574L Gigabit Network Connection', если верить pciconv -lv. Нагрузки не очень большие порядка 70-80кппс и 150 мегабит. В час пик загрузка проца - максимум 35%, при нормальных условиях.

День добрый, имеется: 9.2-RELEASE #0: Sun May 18 03:42:49 EEST 2014 /usr/obj/usr/src/sys/ROUTER i386 Суть проблемы: иногда, загрузка проца подымается до возможных 100% (проц кстати двухядерка пень 4). Так вот если верить показанию топа - нагрузка растёт именно из-за прерываний на внешней сетевой карте (менять пробовал, эфект тот-же). Но vmstat -i в норме. Вот примерно следующее видно: last pid: 22409; load averages: 0.52, 0.50, 0.30 128 processes: 3 running, 109 sleeping, 16 waiting CPU: 0.0% user, 0.0% nice, 5.5% system, 27.2% interrupt, 67.3% idle Mem: 108M Active, 80M Inact, 129M Wired, 132K Cache, 73M Buf, 1543M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME CPU COMMAND 11 root 155 ki31 0K 16K RUN 0 7:38 88.28% idle{idle: cpu0} 12 root -72 - 0K 128K CPU1 1 2:46 50.05% intr{swi1: netisr 1} 11 root 155 ki31 0K 16K RUN 1 5:21 47.36% idle{idle: cpu1} 12 root -72 - 0K 128K WAIT 0 0:24 6.01% intr{swi1: netisr 0} 0 root -92 0 0K 96K - 0 0:11 2.54% kernel{em1 taskq} 0 root -92 0 0K 96K - 1 0:15 0.63% kernel{em0 taskq} interrupt total rate irq16: xhci0 ehci0 891 1 irq19: atapci0+ 4995 8 irq23: ehci1 893 1 cpu0:timer 1216146 2122 irq256: em0 2221212 3876 irq257: em1 1758013 3068 irq258: hdac0 41 0 cpu1:timer 1187698 2072 Total 6389889 11151 Ну это моменты когда нагрузка растёт и машина с ней справляется. А бывают моменты когда машина просто в кору падает и всё. Поэтому данных что происходит тогда привести не могу. Но то что я на скорую руку смотрел в принципе vmstat -i ничего криминального не показывает. Какие будут идеи? Может чего сильно в sysctl перекрутил? kern.ipc.nmbclusters=60000 kern.ipc.somaxconn=8192 kern.ipc.maxsockets=204800 net.inet.udp.maxdgram=57344 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.randomized=0 net.inet.tcp.nolocaltimewait=1 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.icmp.bmcastecho=0 net.inet.ip.ttl=64 net.inet.tcp.drop_synfin=1 net.inet.tcp.syncookies=1 net.inet.ip.dummynet.expire=1 net.inet.ip.fw.dyn_buckets=2048 net.inet.tcp.maxtcptw=40960 kern.ipc.maxsockbuf=16777216 net.inet.tcp.recvspace=262144 net.inet.ip.intr_queue_maxlen=8192 net.inet.ip.dummynet.io_fast=1 net.inet.ip.dummynet.hash_size=1024 net.inet.ip.dummynet.pipe_slot_limit=1000 kern.maxfilesperproc=200000 kern.ipc.shmmax=67108864 net.inet.tcp.rfc3390=0 net.inet.ip.fw.autoinc_step=1 net.inet.tcp.blackhole=2 net.inet.icmp.maskrepl=1 net.inet.udp.blackhole=1 net.link.ether.inet.max_age=30 net.inet.tcp.sendspace=262144 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendbuf_inc=524288 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.ip.random_id=1 net.inet.ip.rtexpire=60 net.inet.ip.rtminexpire=2 net.inet.ip.rtmaxcache=1024 net.inet.icmp.drop_redirect=1 net.inet.ip.redirect=0 kern.maxfiles=204800 net.inet.tcp.delayed_ack=0 dev.em.0.rx_int_delay=200 dev.em.0.tx_int_delay=200 dev.em.1.rx_int_delay=200 dev.em.1.tx_int_delay=200 dev.em.2.rx_int_delay=200 dev.em.2.tx_int_delay=200 dev.em.3.rx_int_delay=200 dev.em.3.tx_int_delay=200 net.graph.recvspace=8388608 net.graph.maxdgram=8388608 net.inet.icmp.icmplim=200 net.inet.udp.recvspace=262144 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 kern.random.sys.harvest.point_to_point=0 net.inet.ip.fw.dyn_buckets=16384 net.inet.ip.fw.dyn_max=65535 kern.ipc.shmall=128000000 net.inet.tcp.msl=15000 dev.em.0.rx_abs_int_delay=4000 dev.em.0.tx_abs_int_delay=4000 dev.em.1.rx_abs_int_delay=4000 dev.em.1.tx_abs_int_delay=4000 dev.em.2.rx_abs_int_delay=4000 dev.em.2.tx_abs_int_delay=4000 dev.em.3.rx_abs_int_delay=4000 dev.em.3.tx_abs_int_delay=4000 dev.em.0.rx_processing_limit=4096 dev.em.1.rx_processing_limit=4096 dev.em.2.rx_processing_limit=4096 dev.em.3.rx_processing_limit=4096 net.route.netisr_maxqlen=4096 net.inet.ip.intr_queue_maxlen=10240 net.isr.dispatch=deferred net.link.bridge.pfil_onlyip=0 net.link.bridge.pfil_member=1 net.link.bridge.pfil_bridge=0 net.link.bridge.pfil_local_phys=0 net.link.bridge.ipfw=0 net.link.bridge.ipfw_arp=0 net.inet.tcp.mssdflt=1460 net.inet.tcp.syncache.rexmtlimit=0 net.inet.tcp.icmp_may_rst=0 vfs.read_max=128 security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 vfs.ufs.dirhash_maxmem=16777216 net.raw.recvspace=65534 net.raw.sendspace=65534 net.inet.raw.maxdgram=65534 net.inet.raw.recvspace=65534 kern.ipc.shm_use_phys=1 Да и в sockstat никакого криминала нет... Уже извёлся незнаю чего и думать

Еще раз. Никто ничего против елтекса не имеет, это раз. Во вторых вы про мерседес могли бы рассказать год или два назад. А сейчас, когда у меня все отлично работает на бдкоме, какой нах@р мерседес и жигули? Может быть Мерседес и БМВ? Тогда, кто тут кто? И вообще дело не в этом =) Лично я не буду покупать у россиян, это мое лично мнение и я никого не переубеждаю. Куплю бдком, хуавей, суньхуйвчай, эриксон, еще что то. Такие дела. Порадовал ваш ответ Да надо прекращать флудить в теме где предоставляют оборудование на тесты!

Нет, не предлогайте бюджетные решения! А то и дальше будут набегать и кричать, что построена говносеть на тупых мыльницах Ну а по поводу микрота - 950 микрот держит порядка 80 машин (нат, шейп, дхцп, фильтрация в фаерволе). Пиковую нагрузку, что он видел - 40 мегабит и загрузка проца примерно 60%. Запаса ещё с головой, но микроты они такие, лучше их не перенагружать, а то у них bad block-и вылетают. Ну а лично мне больше нравится решение на тазике, там много не надо, сойдет любая машина с линем или бздей. Манов в интернете полно, так что при желании всё настраивается, а и в последствии работает замечательно.

Не будем обсуждать определенных вендоров, просто сравним Gepon и Turbo Gepon. Gepon VS Turbo Gepon Downlink: 1.25G 2.5G Uplink: 1.25G 1.25G Дело не конкретно в мультикасте, а в том что нисходящая скорость в 2 раза выше. Так как аплоад задействуется в 99% не больше чем на половину от даунлоада - это позволить не уперется в пропускную способность в ЧНН. У меня вообще статистика что аплоада задействуется в 5-10 раз меньше от даунлоада. А если посчитать что, если 1 дерево состоит из 128 абонентов: и существует тариф 100 мегабит - то 10 качальщиков не положат всю пропускную способность на 2-5 минут. Или я в чём-то не прав?

+++++ Ну что могу сказать, если сугубо из таких убеждений... Только вот тот же BDCOM -> GEPON, a Eltex -> Turbo GEPON. Разницу думаю объяснять не надо.

Да 750-ки там с головой хватит И натить, шейпить, ещё и проксик держать запаса хватить должно

750-го и на больше хватить может, если не требовать от него чего-то сверх))

Политика - политикой, а работа - работой! Мне вот скоро в руки тоже елтекс попадет. Жду не дождусь, поработать с хваленым елтексом. И блин при чём тут политика когда человек оборудование на тесты предлагает?

Спасибо - то что нужно. Свич заработал

Спасибо, буду пытатся

О как, тогда всё понятно Спасибо за инфу!

Ну насколько я понимаю 82 опция это собственно agent circuit id и agent remote id. Agent circuit id - с какого порта. Agent remote id - айди самого свича. Если я правильно понял вы намекаете что каким-то волшебным образом номер влана может выступать как circuit id? Если нет - поправте как правильнее будет, или расскажите, что имели в виду. Потому что я всё таки думаю что именно на доступе нужна 82 опция.

Всем доброго времени суток. Значит столкнулся я лицом к лицу с выше упомянутым коммутатором - D'Link DES 3200-26/1A. Знакомый притащил и попросил "глянуть что с ним". Ну у свича немного невменяемое поведение как-то. Он сброшен на дефолт как я понял. Проблема в следующем к консоли я подключаюсь нормально и всё ок. А вот порты (все 24 100 мегабитных) не фурычат. А 2 из них и вовсе горят всё время, хотя к ним ничего не подключено. Втыкаю свой ноут в любой из 24 портов - 0. Никакой реакции. В 2 гигабтных втыкаюсь - реакция идет, а толку немного. А точнее сказать и вовсе нету. Даже через них на коммутатор зайти я не могу через его стандартный айпи.

Если для абонентского влана указывать хулпер адрес - то тогда л3 интерфейс должен находится на свиче доступа или агрегации, правильно? И тогда возвращаемся к тому, что уже говорил

Хм, сказано было что только выше серии 3560 умеют private vlan. Согласен, без 82 опции тяжко. Но вот надо что-то придумать.

у меня много cisco 2960 8 портовых, а они private vlan не умеют допустим.