Перейти к содержимому
Калькуляторы

napTu

Пользователи
  • Публикации

    27
  • Зарегистрирован

  • Посещение

О napTu

  • Звание
    Абитуриент
  1. Нужно выключить на P1702-4G изолирование медных портов. Делаю switch_config_epon0/1:1#no epon onu port-protect Ничего не меняется, одно устройство даже не видит мак другого, а другое иногда видит мак, но ничего кроме этого больше не ходит. По трейсу только loop protect пакеты от onu и то что приходит с аплинка. Подскажите, куда копать?
  2. netflow sensor linux/freebsd

    нужна freebsd+netflow v9 с расширением NEL (NAT events extension ) нашел только упоминание https://lists.freebsd.org/pipermail/freebsd-net/2013-October/036993.html
  3. удалось снизить нагрузку dummynet на 20% за счет установки параметра pipe burst на 20 мегабайт
  4. Была подобная проблема, но правда помогало передергивание сфп или port state disable/enable. В первый раз переставили на другие порты и работали дальше без проблем, пометив предыдущие "плохими", потом, со временем пришлось занять и "плохие" и они работают до сих пор нормально. Во второй раз на любых портах гас 20км модуль, в другом свиче нормально работает, а в этом гаснет. Замена модуля на того же производителя и той-же дистанции помогла. Ревизия A2.
  5. я смутно представляю обработку пакета, но из того что вычитал про HK_QUEUE, это что дальнейшая обработка пакета производится на базе подсистемы netisr. И тут теряется смысл уходить из ISR в netgraph чтобы затем вернуться в ISR. Пока что вроде собрались yandex драйвера под 9.1release с небольшой правкой мелкой наждачкой: в /usr/src/sys/dev/e1000/e1000_osdep.h закоментил строки 76,78,99 (на которые была ругань) и в /usr/src/sys/modules/em/Makefile убрал e1000_i210.c ... собирал только em драйвер, да и тот похоже не заработал, нет опций rx_queue в sysctl... Полная сборка ядра не идет, ругается на igb ... сетевушки PCI на новособранной тестовой машинке оказались, а на них только legacy em драйвер, который яндексами не поддерживается...
  6. FreeBSD 9.0 + em

    похожую ситуацию давно наблюдаю на 8.1 с яндекс дровами, когда перезагрузка раза в два снижает пиковую нагрузку CPU. Были идеи что замусориваются таблицы в ipfw или еще какие буфера. А то что перекос входа-выхода разных интерфейсов роутера, так это действительно быстрее всего разный путь обработки пакета в ipfw
  7. а есть смысл ? если да , то немножко ближе к реализации кто то может натолкнуть? Например если принимаемый трафик направить в ng_onw2many, а затем с каждого many вернуть в ядро, этого будет достаточно, или необходимы еще какие либо ноды для организации очереди?
  8. 3526

    естественно речь о 100мбит портах. я не понимаю, des-3028 и cisco2950 дают в полке 12800кбайт/с, почему 3526 не дает?
  9. 3526

    раз уж 3536, то спрошу здесь Заметил что на моем 3526 максимальная скорость по show packet ports составляет 9523840 байт в сек, упирается в это значение и растут пинги, делю на 1024, получается 9300,625 кбайт/сек, или 74405кбит/с, или 72.66 мбит/с Возникает вопрос - куда же деваются оставшиеся 27.33 мбит полосы порта? Перекопал все настройки, никаких ограничений нет, ни в hardware , ни в cpu, практически все фичи выключены, свич сброшен был перед продажей. Работают только два access_profile на tcp445 deny и udp68 deny. Если, например, ставить config bandwidth_control 1-24 rx_rate 99 tx_rate 99 то всё равно маскимум 9523840 байт в сек. А как у вас?
  10. управляемый - циска2950. раздача через основной шлюз. пакеты в ответе не дробленные, так и идут по 1300-1500 байт. в запросах все пакеты короткие, но и аплинка особого нет. мультикаст шторм? и куда он девается при закрытии доступа в инет?
  11. У нас тепло, +5 - +15, иногда сыро, но зависимости нет. есть, смотрел, udp,tcp обмен торрента, ничего лишнего или необычного, искал какие либо маркеры пакетов, но возможно они в центре уже отфильтрованы. input flow-control is unsupported output flow-control is unsupported
  12. Может кто то посоветует по сабжу? Ситуация периодически наблюдается на нескольких сегментах сети. Сеть построена на управляемом свиче в середине и оптическими 100мбит выносами на конверторах, затем идут по частному сектору 100м отрезки на неуправляемых свичах. При включении одним из клиентов какого то хитрого торрента возрастают пинги в пределах всего сегмента после оптики, даже в другую ветку от оптики. При запрещении на роутере ip трафика от этого клиента пинги становятся 1-2мс, если же блокировать трафик tcp или udp по раздельности, то пинги кратковременно уменьшаются до 10-20мс, а затем снова возрастают до 30-60мс. От клиента поступает при этом примерно 50 очередей и низкий upload, при этом download к нему около 10мбит. Общий download на сегмент 20-30мбит Как вариант, пакеты маркируются высоким приоритетом QoS? Не нашел никакой информации по этому поводу, неизвестно, понимают ли неуправляемые свичи (или конверторы) маркеры qos и может ли торрент маркировать так пакеты.
  13. Винт SATA 300Гиг, swap раздел отдельный, остальные разделы совмещены на руте. Nov 21 00:23:21 icenet savecore: reboot after panic: page fault Nov 21 00:23:21 icenet savecore: writing core to vmcore.1 Nov 21 01:57:22 icenet kernel: em1: link state changed to DOWN Nov 21 01:57:22 icenet kernel: em1: permanently promiscuous mode enabled Кто может подсказать?
  14. ух как всё запущено... после замены машины на двуядерную нагрузка по taskq процессам выравнялась странно то что драйвер кушал на прием в два раза больше CPU, чем на передачу