nixx

в свете появления далеко не единичного количества абонентов, которые в сетях разбираются немножко слегка (хотя по вус проходят, полагаю, связистами), и прям норовят пхнуть вместо онушки обычный медюк, озадачился отслеживанием сработок по AlwaysLaserOn, ну и до кучи разными прочими трапами... ну так вот... оказалось, что втыкании медюка напрямую в SFP (в смысле, вообще без висящих на дереве ONU), в логе сообщение про AlwaysLaser генерится, но вот трапа (любого, пусть даже не nmsOnuLaoNotification, а хоть что угодно) - тю-тю. аналогично и с подключенной онушкой - вешаю на соседний отвод медюк, на голове линк падает совсем, в логе ругань, трапов нет. с трапом авторизации примерно так же (ну просто до кучи пошел пробовать) - пытаюсь залогиниться с заведомо неправильным паролем, авторизация на OLT через радиус, в логе три сообщения "User nixx Authorization failed", трапов - ноль. при этом на успешную авторизацию трап летит... но нафига-то он нужен по большом счету... хост для трапов настроен так: snmp-server host 192.168.10.10 description Zabbix version v2c myCommunity authentication configure snmp я в печальке. посоветуйте парсер логов, чтобы с него по нахождению ключевых слов можно было сгенерить че-нить для zabbix_sender'а логи принимаются сислогом со всего железа одним хостом и раскладываются по каталогам ip-address/year/month/dayfile про zabbix_agent в плане чтения логов у меня какие-то не очень добрые мысли ("Регулярные выражения для logrt поддерживаются только в имени файла, сопоставление регулярного выражения для каталога не поддерживается" (c) )

а там уже не российские сертификаты. в китай сбербанк уехал, если верить моему FF:

сам спросил, сам отвечаю - да, возрастает. Просто потому, что распределением flows по физ портам в агрегации занимается QFP, что нарисовано на любой диаграмме в pdf'ах об архитектуре asr. К сожалению, на 1001X циске в силу медленности тамошнего qfp - это сильно заметно. Процентов 5+ и более съедается в чнн (вплоть до 10) на трафике в 11 гбит in/out. На 1002X - почти не видно разницы. ну и разница в ios'ах тоже влияет, как оказалось. у меня получился разброс от 45% на иосе 16.9.8 с раздельным трафиком по портам до 65% на 17.9.8 с порт-ченнелом на одинаковом (плюс-минус 200мбит) трафике в 11 гбит. можно попробовать vlan-based manual balancing, но... тогда теряются все плюсы порт-ченнела, кроме возможности безболезненно дернуть один из линков не в чнн.

40г (а точнее 38г) роутится без проблем с загрузкой процов процентов на 50 (2673v4). три фулл-вью, два недофулл (мск-их). натится тоже без проблем, но процы уже уползают за 60%. тюнинга никакого, кроме стандартного кручения сетевух через ethtool (set-channels, set-rings)

микротик в РФ не работает. mlx5_core 0000:05:00.0: 126.016 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x16 link) итого. два фуджитсу-мелланокса CX455A - ConnectX-4 соединены прямым QSFP28 AOC'ом процы E5-2680v4/2686v4, платформы - одна супермикра X10DRI, другая интел S2600WT2R вешаю шесть iperf'ов-серверов на шесть портов на процах 2686, запускаю шесть клиентов на процах 2680 к каждому iperf-серверу при трех iperf'ах-клиентах в одну сторону и трех - в обратную (ключик -R) получаем in 65 гбит, out 50 гбит при всех шести клиентах с флагом -R - in 71 гбит, out 150 мбит при всех шести в обычном режиме - in 35 мбит, out 65 гбит по 30-60% на разных ядрах процов. спецом прерывания и iperf'ы на ядра одного проца не прибивал, лениво возиться. ps: один iperf выше 37-39 гбит упорно не прокачивает, поэтому по советам ведущих стоматологов с реддита - пробовал четыре и шесть.

как обычно, мимо кассы. алиэкспресс, 7 тыр полгода назад однопортовый мелланокс 100г с 16х pcie шиной. ну для примера вот первое, на что наткнулся адаптеры, как раз, можно вообще не считать. проц и материнка серверные основную цену составят. имхо, 3gen scalable может и потянуть. ну а 4gen наверняка.

тыканье закончилось на стадии регистрации. зачем вам мой инн и адрес прямсразу? логин чтобы чисто по объявам потыкать вообще исключен?

как раз сейчас занимаюсь тем, что аннулирую функционал многочисленных микротиков 1009 на периферии (узлах агрегации), ставя вторую ASR в ядре. функционал - нат, шейпинг, авторизация абонентов, редирект по неоплате, пропуск к социально значимым, нетфлоу в сорм. а для чего ставить 1009 "рядом с абонентами" - даже не знаю. как L2 свитчи они бесполезны, длинки 3028 за 500р умеют больше. EoIP'ы поднимать, разве что. но для этих целей hap/hex'ов за глаза хватит. а про сохранение инвестиций как-то вообще мимо кассы. что микротики дешевеют, что циски, ушедшие в EoL, что джуники. любое железо - это не про сохранение инвестиций, а про предоставление сервиса, на котором (в зависимости от его качества) зарабатывают. и вот с микротиками это качество - гм, ну... вы сами охарактеризовали: это пример роутера на упомянутые вами 40гбит практически за копейки в настоящее время. надо лопатить 100 одной железкой, а не тремя - без вопросов, asr1002-hx, catalyst 8500, но платить придется чуть больше )

попробуйте два варианта: 1) т.к. по умолчанию snmp читает и без всяких snmp.conf мибы из каталога /usr/share/snmp/mibs (в нём это hardcoded, как говорит man), то задайте так: mibdirs +/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/var/lib/mibs/external mibs +ALL 2) рабочий вариант у меня под заббиксом (упорно читал одну переменную из микротика, будь он неладен, то в hex, то в string, пока не подсунул ему индивидуальный mibdir с mib'ом от микротика): mibdirs /usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf mibdirs +/home/scripts/mibs и никакого "mibs" вообще. ps: ну и когда вы вызываете snmpwalk, он там в первой строчке (ну, по крайней мере, в моей консоли )) пишет такое: # snmpwalk -v2c -c comm 10.20.30.40 .1 > oids.txt MIB search path: /root/.snmp/mibs:/usr/local/share/snmp/mibs:/home/nixx/snmp/mibs/BDCom сориентируйтесь, чего не хватает, или наоборот - что лишнее.

36гбит поддерживает железка за ~80 тыр по безналу (ASR1002-X). ну откройте уже для себя на каком-то там году общения с микротиками, что такое PLD, ASIC и прочие FPGA. в любом "железном" маршрутизаторе, к которым не относятся ни роутеры Mikrotik, ни роутеры Eltex (извините, наболело тоже), маршрутизацией трафика (и натом заодно) занимаются специализированные микросхемы, которым вообще плевать на объем нагрузки в пределах их мощности. они с одинаковой задержкой работают как на 5% занятости, так и на 90%. и лимит их производительности заранее известен. а обычный процессор, такой, как в микротиках - он там вообще сбоку слева, иногда чем-то поуправлять ходит, когда скучно.

давайте начнем с вопроса, КАК вы прописали "этот каталог" через mibdirs? а также гуглу вы 100% доверяете, или есть вариант того, что он гонит пургу? мне, в противовес гуглу, кажется, что вы наоборот - прописыванием "этого каталога" удалили из обработки каталог с основными мибами, идущий в пакете net-snmp. приведите snmp.conf целиком.

не только. возьмите mib-файлы посвежее, сами почитайте. fileTransferProtocolType OBJECT-TYPE SYNTAX INTEGER { ftp(1), tftp(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of file transfer protocol used by the process" ::= { fileTransferEntry 2 }

да, у них днем упало число маршрутов значительно. но такое бывает чуть ли не каждый месяц эпизодически, поэтому особого значения не придал. а про ТСПУ - на что еще думать, если присел не один аплинк, а несколько? ) только на то, что по России полетело очередное обновление. два оператора, в которых стоят ТСПУ - получили гору ругани от абонентов. третий, где ТСПУ нет (но тоже есть msk-ix) - ничего не заметил, и даже трафик почти не спадАл. поэтому первой мыслью было позвонить в ТП ДЦОА. но у них таких звонящих, походу, было уже много, и ответа я не дождался. а потом пошли стыки с msk-ix отваливаться сами. upd: собсно, я таки был прав в своей догадке. от msk-ix пришло письмо, в котором подтверждается проблема с ТСПУ.

что-то в очередной раз сломалось на msk-ix? или ТСПУшники привычно криворучат? 16:30 большое проседание трафика как по msk-ix (вплоть до отвала пиров), так и по мегафону. абоненты матерятся. по графику самого msk-ix уже минус почти терабит из шести нарисовалось.

аппаратная? производитель, вообще говоря, пишет обратное - "Split horizon is a software feature that disables hardware offloading" )) с горизонтом, в принципе, рабочее решение. еще можно включить "use ip firewall" в settings окошка бриджей, и файерволлом разграничивать трафик между вланами. но такая жуть потом получается... )