askask

Действительно в 36 серии есть такие оиды, спасибо. Видимо не нашел из-за того что индексом является мак интерфейса, а не id.

да да я вот эти 2 поля LastDeregTime, LastDeregReason тоже очень хочу... Нашли oid ? К сожалению, их не существует. Ответ от китайской техподдержки. Таки да OID не нашел взял телнетом.... думаю все найдут то что искали .1.3.6.1.4.1.3320.101.11.1.1, и похоже чутка прибрэхивает китайский саппорт Ничего подобного тут нету. Единственный способ отловить dereg reason - это ловить snmp трапы. Только есть одна загвоздка, в трапах есть только DyingGasp - пропало питание и registered/deregistered onu event. Cледовательно чтобы найти wire down - нужно складывать в базу данных все события питания и проверять не пропало ли питание когда приходит deregistered. В общем эти все скрипты есть и они даже работают, а в кактях рисуется количество wire down на ОЛТ, но не всегда нормально обрабатывают события, особенно когда питание пропадает массово и шлется куча сообщений. Скорее всего не вовремя отрабатывают многоэтажные костыли в виде snmptrapd - snmptt - самодельный php trap handler в кучу потоков. Поэтому не вижу смысла выкладывать это здесь. Для нормального решения задачи гораздо проще и эффективней ломиться телнетом и парсить вывод команды.

Что-то нигде его не видно. Можно ссылку для слепых?

Увеличил- не помагло Я думаю вам нужно переименовать графики по шаблонам <path_cacti>/cli/poller_graphs_reapply_names.php .

Все работает, но в подписи графиков не отображается последние два знака МАК адреса (.... E6:67:B3:0B:2D: ), это можно исправить где-то? (считываются все 12 знаков, а в подпись попадают только 10) Какая модель ону? Мак очень похож на sofetec, только там e0:67:b3 Какие значения отображаются если сделать vebose query для Epon interface statistics P33xx Series в настройках устройства? Onu BDCOM, Sofetec, Eltex значения + Found item [onuMacAddress=E0:67:B3:0B:2d:92] index: 44 [from value] 59 Down EPON0/2:45 1 E0:67:B3:0B:2D:92 69 Up EPON0/3:5 1 FC:FA:F7:16:21:60 а на графике надпись ... Epon signal - EPON0/2:45 - E0:67:B3:0B:2D: Попробуйте увеличить максимальную длину title графика visual->maximum title length.

Все работает, но в подписи графиков не отображается последние два знака МАК адреса (.... E6:67:B3:0B:2D: ), это можно исправить где-то? (считываются все 12 знаков, а в подпись попадают только 10) Какая модель ону? Мак очень похож на sofetec, только там e0:67:b3 Какие значения отображаются если сделать vebose query для Epon interface statistics P33xx Series в настройках устройства?

Оно то да, но возникает вопрос почему при потерях такие жуткие тормоза, а не выпадание кадров например? На старом протоколе все ок. Или может я чего-то не понимаю и причина не в потерях?

Решили ещё три года назад - QUIC. Для индикации использования в Chrome можно попробовать это расширение. Оказывается в хроме можно зайти в chrome://flags/ и отключить QUIC. И пока окончательно не понятно связано это с полками по дороге?

tcpdump -c 3 -nn -S -X -vvvvv host 173.194.21.89 22:49:25.684406 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto UDP (17), length 1378) 173.194.21.89.443 > 192.168.111.100.58312: [udp sum ok] UDP, length 1350 0x0000: 00e0 52f4 806c 000c 4330 5088 0800 4500 ..R..l..C0P...E. 0x0010: 0562 0000 4000 3a11 4863 adc2 1559 c0a8 .b..@.:.Hc...Y.. 0x0020: 6f64 01bb e3c8 054e 43d2 00c1 434e 4e81 od.....NC...CNN. 0x0030: 98f3 4106 065a 8fc1 e111 01ad 04c7 a3af ..A..Z.......... 0x0040: ddcd c39f b3ba f800 f64f d7ab 3bec f627 .........O..;..' 0x0050: fb18 2b84 155f 0301 f526 a74f 7227 3789 ..+.._...&.Or'7. 0x0060: ca6f 4318 89ec 4941 e318 0004 1fcd 12cd .oC...IA........ 0x0070: 5203 c404 b381 a143 9a9a 4784 d789 2e8d R......C..G..... Это в хроме. 22:52:05.516221 IP (tos 0x0, ttl 64, id 13294, offset 0, flags [DF], proto TCP (6), length 1372) 192.168.111.100.55214 > 173.194.21.89.443: Flags [P.], cksum 0x54d9 (correct), seq 3670958691:3670960011, ack 3884018984, win 4096, options [nop,nop,TS val 353437958 ecr 321744465], length 1320 0x0000: 000c 4330 5088 00e0 52f4 806c 0800 4500 ..C0P...R..l..E. 0x0010: 055c 33ee 4000 4006 0e86 c0a8 6f64 adc2 .\3.@.@.....od.. 0x0020: 1559 d7ae 01bb dace 6263 e781 6d28 8018 .Y......bc..m(.. 0x0030: 1000 54d9 0000 0101 080a 1511 0906 132d ..T............- 0x0040: 6e51 1703 0305 2300 0000 0000 0000 094a nQ....#........J 0x0050: d2e6 a05a 0716 e39a 2c5c f70a e86e 13e7 ...Z....,\...n. А это в опере. В сафари все закономерно. Похоже разработчики хрома и хромиум решили для уменьшения задержек (так оно и вышло) использовать udp для доставки потока. Дальше остается только догадываться. Может во время полки серверы ютуба оставляют за собой право не отвечать на запросы или возникают потери? А браузер послушно ждет, пока у него не заканчивается буфер. При этом пакеты с гарантированной доставкой доходят нормально. Впрочем причин может быть много. UPD: не помешало бы исследовать tcp пакеты на предмет tcp retransmittion, но у меня на машине не работает wireshark. Это бы опровергло или подтвердило гипотезу.

Подтверждаю, проблема возникает только в последних версиях Google Chrome и Chromium (мб яндекс тоже, не проверял) под Windows и OS X. Под Linux старенький со старым Chrome - полет нормальный, а также опера, firefox, safari, edge на разных платформах. А такой холивар развели на 3 страницы, я уже думал как бгп перенастроить. Остается 1 вопрос: почему проблема возникает именно вечером?

Если сервер исключительно молотит трафик(никаких бд, веб серверов и т. д.), то si - это для вас основной показатель, а он в свою очередь входит в общую загрузку ядра. Load average = Сумма общей загрузки ядер процессора. Никаких проблем если <70% или 0.7*(количество_ядер), можно и больше, но будьте готовы...

Если нужен только BGP смотрите в сторону Brocade.

RX Boot Code Version 2.9.00d ... Enter 'a' to stop at memory test Enter 'b' to stop at boot monitor А що буде якщо натиснути а або b ?

Не маю можливості проводити експерименти з цими командами, але можливо вони вам допоможуть: boot system slot1|2 hitless-reload mp dual-active-console - зовсім не знаю що означає По дефолту, звісно, з флешки. З цього приводу є мануал ftp://ftp.software.ibm.com/systems/support/system_x_pdf/bigironrx_02702e_releasenotes.pdf, хоч і трохи старий.

Я бачу у вас різні версії прошивок на модулях, що може викликати непередбачувані проблеми. Рекомендую все обновити до однакової версії. Можливо це і вирішить основну проблему. copy tftp flash <TFTP-server-ip-addr> <image-name> primary copy tftp flash <TFTP-server-ip-addr> <image-name> secondary copy tftp flash <TFTP-server-ip-addr> <image-name> monitor copy-boot copy tftp lp <TFTP-server-ip-addr> <imagename> monitor all copy tftp lp <TFTP-server-ip-addr> <imagename> monitor copy-boot all copy tftp lp <TFTP-server-ip-addr> <image-name> primary | secondary all copy tftp mbridge <TFTP-server-ip-addr> <image-name> MBRIDGE Я завжди думав, що неправильний MBRIDGE может зламати шассі. Виходить що ні.