nixx

ну да, ну да. пропишите маску больше, пропишите еще какое-то шаманство. а если для стыков выданы две сети /31 из айпишников, идущих подряд - какую маску каждой прописать-то? давайте без извращений просто скажем, что у микротиков работа с /31 не поддерживается вплоть до какой-то там 7й ROS, как тут упоминали. конкретно мой глюк - два туннеля, внутри каждого поднимается bgp стыковочный диапазон выдан для каждого туннеля в виде /31 сеток. пиры нормально пингуются, bgp-сессия с ними поднимается, и если прописать вручную к какому-нибудь пиру 0.0.0.0/0, то трафик бегает нормально. вот только получаемые по bgp от пира маршруты появляются в виде unreachable с next-hop'ом - айпишником пира. поменяли стыковочные сети на /30 - всё нормально, все принимаемые маршруты в статусе reachable. ps: пробовал делать, как советовали в этом топике на предыдущей странице - прописывать на интерфейсе /32 - у меня почему-то начинал колбаситься интерфейс туннеля. ну вот down-up-down-up каждые две секунды, и так бесконечно. нет чтобы сразу писать при задании маски /31 что-то типа "unsupported", но нет, разработчикам надо было предоставить юзерам самим это познать...

DES-1228/ME стабильны, как дуб ) их дом.ру мега-партиями продавал пару лет назад, может еще где-то остались. если из новых - то, подозреваю, что ничего, т.к. 100мбит свитчи уже становятся редкостью.

самое сложное, имхо, - это вовремя обновлять товарища. потому что чуть прощелкал - и вышло уже новое обновление какой-нибудь софтины, в него входящей, а у него все обновления вручную, и строго следующие друг за другом (причем обновления разнообразные - от apt update или "изменить пятую строчку в конфиге" и до 'update table set ...' через mysql cli). если есть деньги - можно поручить это разработчикам.

разбужу тему, раз уж нагуглилась ) скажите пожалуйста, правильно ли я понимаю, что если мой бгп-пир отдал мне /31, да еще и внутри gre-туннеля, то получать от него маршрут со шлюзом в состоянии unreachable - это нормально? ...и надо просить хотя бы /30? ROS 6.49.10

судя по тому, что человек упорно постит скрины с winbox'а, других графиков у него нет. или?... @rliskov у вас есть нормальный мониторинг хоть какой-то, с хоть какой-то историей? посмотреть бы на графики за сутки/за трое/за неделю. не растут ли дропы строго в ЧНН, либо они постоянно размазаны по времени. связать бы еще по времени графики трафика с занятостью, как выше написали, cpu. а заодно и скажите, что у вас на другом конце оптики/DAC'ов стоит, какие устройства.

это баг. у него, с позволения сказать, control plane о чем-то вечном задумывается периодически. даже на последней 6.11.065. а еще он периодически путает местами по SNMP данные с DDM SFP (ну т.е. вместо 25 порта отвечает данные с 26го). но длинк сказал "мы эту модель больше не поддерживаем вообще и с концами", поэтому смиритесь.

...еще наблюдался заметный рост числа нат-сессий на cisco ASR в это же время с резким обрывом в 13:20-13:30, когда всё заработало. а скажите (сам я в мобилки не лезу от слова "совсем"), если упомянутые адреса недоступны - при вбивании в браузере мобилы того же яндекса - он должен открываться или нет? у наших абонентов не открывалось вообще ничего, что не вбей.

у четырех, как минимум, операторов связи в Курске и Орле со вчерашнего вечера отвалились массово (но не глобально) мобилки, планшеты, работающие по wi-fi. мобилки разнообразные, роутеры разнообразные. тв и всякие кофемолки, подключенные по wi-fi, а также айфоны, сцуко, при этом работают. примерно в 13:20 мск перестали звонить абоненты, а жаловавшиеся ранее подтвердили, что заработало. возможно, наши жалобы в support-asbi дали эффект, возможно сами... ждем некоего таймаута в час-два, чтобы удостовериться окончательно.

у вас при почти одинаковых TX уровнях с обоих сторон - RX сильно разнЯтся. я бы сразу грешил на физику - оптический канал между точками - что-то с ним не очень (в сторону от мелланокса к циске затухания сильно больше).

на текущий момент пришел к результату (по-видимому, неполному, но хоть какому-то): BDCom перестал частично воспринимать строчки, относящиеся к untagged влану при конфигурации ethernet-порта в виде: interface GigaEthernet0/5 switchport trunk vlan-allowed 1002-1513,4000,4040 switchport trunk vlan-untagged 4000 switchport mode trunk switchport pvid 4000 почему частично - потому что если повесить в этом влане ip на сам BDCom - то он пингуется, с него наружу тоже пинги ходят, на него можно залогиниться. но при этом если извне пинговать ONU, висящие на BDCom'е - они ничего не отвечают. с самого BDCom'а эти же ONU нормально пингуются. но если убрать строчки в конфигурации GigaEthernet0/5, задающие vlan-untagged и pvid, и повесить на вышестоящем устройстве vlan 4000 с тэгом, то пингуется в нём и BDCom, и онушки. конфигурация ONU выглядит как: interface EPON0/1 epon bind-onu mac xxxx.xxxx.xxxx 1 switchport trunk vlan-allowed 1,1002-1513,4000,4040 switchport trunk vlan-untagged 1 switchport mode trunk switchport protected 1 interface EPON0/1:1 epon onu port 1 ctc vlan mode tag 1002 priority 0 epon onu ctc ip address static 10.20.30.40 255.255.255.0 gateway 10.20.30.1 cvlan 4000 svlan 0 priority 0 epon onu port 1 ctc loopback detect switchport mode dot1q-tunnel-uplink или же switchport mode trunk на ethernet-порту - без разницы. с переливом старых конфигов пока не игрался. походу, где-то что-то перемудрили с прохождением тэгов. на остальных моделях - ничего подобного не замечено. это просто сброс интерфейса в дефолтную конфигурацию. чем оно может помочь? ну я попробовал на всякий случай (вдруг там какое-то скрытое шаманство) - без изменений.

дык можно же выключить ) и не писать правил, которые используют established и прочие подобные ключи, работающие со стейтами соединений.

тазик - это какой-нибудь некросервер, в данном контексте - в роли маршрутизатора/ната/сенсора нетфлоу, которую у вас выполняет микротик.

версия 1.7.х норм, основные фиксы по IPFIX были в 1.6 ветке. у вас в одном потоке IPFIX льются и flow-данные (от кого-кому, количество), и NAT-инфа (внутренний ип, внешний ип, начало/конец сессии) по-любому при просмотре одного типа данных второй будет выводиться черт-те как. плюс то, что этот поток создает микротик, добавляет сюда некоторой неоднозначности (всё может быть запущенней, чем мне кажется с ваших слов). если вас это не устраивает, вариантов несколько 1) поменять микротик на циску или тазик или еще что-нибудь, что будет нормально (а циска еще и раздельно) отдавать потоки 2) делить поток данных на приеме - NAT отдельно, flow отдельно, и так и складывать в архивы (я так делаю в случае с ipt_netflow на тазике) 3) сделать, как коллега постом выше - собирать два потока разных версий - netflow5 не знает, что такое NEL, и будет отдавать только данные по перекачанному объему, а дамп IPFIX грепать с тем же ключом -o (почитайте ман, там много интересного) на тему "только NAT Events" вместо nfdump - можете посмотреть pmacct, у меня он используется для вспомогательных целей, но какой-то он нестабильный. мне не понравился.

судя по рекомендации, вы с олт бдкомов не работали. там и текстовый, и sqlite база онушек, и бинарный конфиг индексов интерфейсов. каких-либо описаний к прошивкам бдкома вы не найдете никогда. на протяжении 4 лет минимум любое обновление сводилось к перезаливу фирмвари, единожды к изменению номеров интерфейсов на одной из моделей, а зачастую к апдейтам базы sqlite и коррекции/дополнению текстового конфига, всё на лету самой прошивкой делается.

конкретно это процитированное похоже на то, что вы flow-записи пытаетесь прочитать как NAT event'ы (добавьте флажок -o line для вывода в виде flow) а дата кривая может быть по причине старой версии nfdump'а либо кривого коллектора (что-то там разрабочик фиксил в IPFIX, но уже года три назад, если не больше... да и к микротику у него претензии были, что там, как обычно, всё не так, как у людей). а это как раз NAT event'ы. в них всегда будет 0 байт.