Он знал что делал.

что именно знал?

Что с его ноды скорее всего будут писать дерьмо и что это запрещено в России.

Что с его ноды скорее всего будут писать дерьмо и что это запрещено в России.

эм... а он тут сам причём? )

яж говорю. он знал что к нему будут вопросы. вот и отвечает на них

с кем договор - к тому и вопросы

именно

яж говорю. он знал что к нему будут вопросы. вот и отвечает на них

он в СИЗО сидит, а не на вопросы отвечает

Ну как бы соучастие

чтобы было соучастие, надо было чтобы они были связаны

там скорее всего нет никакой его вины, кроме безответственности. И мера пресечения явно выбрана чрезмерная.

Палку рубят.

Он создал ситуацию, которая способствовала нарушению закона.

каким образом?

вы все понимаете. зачем спрашиваете

не понимаю

тор релей поднимают не для нарушения закона

Он создал ситуацию, которая способствовала нарушению закона.

это безответственность. Халатность. Но не экстремизм, или что там ему шьют

читайте мою формулировку внимательно

да. согласен

его к тому же судят не за тор релей

и не за соучастие

и с этим тоже

А что у вас там произошло то, от чего они страдали? )

Коллеги, всем привет. При настройке на Juniper MX80 сбора трафика с помощью jflow без сервисной платы процессом sampled начинает активно сжираться оперативная память. На целевом серваке пакеты от роутера видно, то есть собранные данные он туда сбрасывает. При этом количество потребляемой процессом sampled памяти только растет, но не сокращается. Попытки поиграть с параметром rate в forwarding-options -> sampling -> instance -> sample-instance -> input никакого результата не дали. Добавленные параметры flow-active-timeout и flow-inactive-timeout картину также не меняют. Кто-нибудь сталкивался с таким поведением? Может быть есть гипотезы, почему так может происходить?

ему инкриминируют то, что это он лично все постил, потому что даже 15-летний школьник может написать скриптик, который отложенно отправит посты, а Дмитрий был увлечен ИТ технологиям и там был его IP и ID адрес

вот так примерно выглядит обоснование его ареста

да. согласен

Тебе надо судьёй работать )

не спрашивайте меня только что такое ID адрес

Насколько я помню, у этой истории есть предыстория

Коллеги, всем привет. При настройке на Juniper MX80 сбора трафика с помощью jflow без сервисной платы процессом sampled начинает активно сжираться оперативная память. На целевом серваке пакеты от роутера видно, то есть собранные данные он туда сбрасывает. При этом количество потребляемой процессом sampled памяти только растет, но не сокращается. Попытки поиграть с параметром rate в forwarding-options -> sampling -> instance -> sample-instance -> input никакого результата не дали. Добавленные параметры flow-active-timeout и flow-inactive-timeout картину также не меняют. Кто-нибудь сталкивался с таким поведением? Может быть есть гипотезы, почему так может происходить?

Делай нетфлоу с зеркала

Насколько я помню, у этой истории есть предыстория

какая?

Делай нетфлоу с зеркала

О как. Мирроринг проц routing engine нагружать не будет?

ну миррорить то не на джуне наверно ...

слишком дорого это

сплиттер дешевле )))

Да. Конечно сплиттером

А я вообще правильно понимаю, что без сервисной карты ресурсы так и будут сжираться и сделать с этим особо ничего нельзя?

какая?

Насколько я помню, его ранее принимали за что-то подобное, было в новостях.

Там вообще с jflow проблем дохрена

Насколько я помню, его ранее принимали за что-то подобное, было в новостях.

нет, не принимали никогда его

он вообще политикой не занимался

Не буду спорить

не его

был другой чувак

Не стал бы делать выводов По новостям

Но я бы тащил его как соучастника

ну так можно и гендиректора оператора подтащить :))

как соучастника :))

и всех девелоперов тора

Но я бы тащил его как соучастника

злой ты))

и девелоперов браузеров

Во первых МХ заливает в routing record демона данные о маршрутах. чтобы у тебя в нетфлоу были данные о автономках. И делает он это одновременно с заливом фуллвью например, ухудшая время схождения раза в два :-) Во вторых да, потребление памяти, которой на МХ80 и так не сильно много. В третьих шикарный баг, при большом количестве новых потоков в секунду (например ддос) могут начать флапать бфд сессии с микрохи на асике. Не надо на МХ80 гонять Jflow, лучше миррорь :-)

и вообще всех

я бы всех посадил, а может бы даже и расстрелял

ну так можно и гендиректора оператора подтащить :))

Ну вот совсем не факт

злой ты))

Ну я совсем не добрый

Во первых МХ заливает в routing record демона данные о маршрутах. чтобы у тебя в нетфлоу были данные о автономках. И делает он это одновременно с заливом фуллвью например, ухудшая время схождения раза в два :-) Во вторых да, потребление памяти, которой на МХ80 и так не сильно много. В третьих шикарный баг, при большом количестве новых потоков в секунду (например ддос) могут начать флапать бфд сессии с микрохи на асике. Не надо на МХ80 гонять Jflow, лучше миррорь :-)

Жесть какая! Спасибо. Я как-то наивно полагал, что после циски 76xx все не так и страшно, а оказалось - с точностью наоборот)

Ну оно лучше чем на 76

Но все равно

Да и мх80 уже не сильно актуален

Ну оно лучше чем на 76

Подписываюсь)

Да и мх80 уже не сильно актуален

Да, скорее всего дело в этом. Правда выбора в данный момент особо нет

А, да, еще смешной баг. Даже если это более мощный МХ, и с более мощным процом и большим обьемом памяти часть проблем не так заметна, и ддосов нет (хихи), то все равно остается проблема, что в асик можно залить только 64к aspath, и с какого-то момента ты будешь получать нетфлоу с MAXINT в качестве автономки по этому префиксу. :-) Ну и вдогонку, чтобы два раза не ходить, у них еще по моему опыту похоже рассинхронизация происходит (происходила ? хз), т.е. инфе о автономках вообще верить нельзя, а она-то как раз там и наиболее полезна

МХ80 да, очень проблемный из-за слабого RE. Но часть проблем с inline jflow остается и на старших моделях

Забавно. На циске это отлично работает

Но тоже производительность страдает

....а еще я могу рассказать про мирроринг на МХ-ах, это тоже будет смешно :-)))

А, да, еще смешной баг. Даже если это более мощный МХ, и с более мощным процом и большим обьемом памяти часть проблем не так заметна, и ддосов нет (хихи), то все равно остается проблема, что в асик можно залить только 64к aspath, и с какого-то момента ты будешь получать нетфлоу с MAXINT в качестве автономки по этому префиксу. :-) Ну и вдогонку, чтобы два раза не ходить, у них еще по моему опыту похоже рассинхронизация происходит (происходила ? хз), т.е. инфе о автономках вообще верить нельзя, а она-то как раз там и наиболее полезна

Самое обидное, что мне глобальная инфа была не особо нужна. Нужно тупо считать трафик по одному префиксу поайпишно. И все)

ERROR: S client not available

....а еще я могу рассказать про мирроринг на МХ-ах, это тоже будет смешно :-)))

Не, спасибо. Кажися я всё)

Да, скорее всего дело в этом. Правда выбора в данный момент особо нет

у меня 104й. тоже лью jflow. Правда с модулем

Коллеги подсказывали, на взрослых MXах с модулем проблему не фиксировали

Не, спасибо. Кажися я всё)

Быстро сдался :-)) Я ж еще только начал :-))

В это я готов поверить)

Быстро сдался :-)) Я ж еще только начал :-))

Попробую альтернативный КОСТЫЛЬ)

С модулем - это MS-MPC ? А они рассказывали, на каких скоростях это гоняли ? И с каким pps ? Потому что MS-MIC это по факту броадкомовый XLP (или даже пара), просто многокорковый мипс проц с оффлоадами. И они после перехода с MS-DPC на MS-MPC чутка версию поменяли и очень долго вылавливали косяки, и до сих пор ловят

И я вот более чем уверен, что туда те же routing record тоже будут заливаться довольно неспешно

@orlik скажи уже им

ms-mic-16g

Чо они тут хейтят juniper)

Если бы у меня были в продакшне кошки, я бы хэйтил их :-) К сожалению они все говно. Но это говно у нас уже стоит :-)

И очень хорошо, что не стоит еще большее говно, иначе бы я пошел в корпоративку винды ставить и мышки чистить от отчаяния :-)

Аср1к норм

Че ты

Ага, расскажи мне про нат с оверлоадом на нем :-)

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

остается выяснить, что же не говно ?

Работает

К сожалению джуниковая реализация нетфлоу - одна из таких ловушек

Хз че там с натом

Это слухи

Окей. :-)

У меня их не стоит, поэтому не буду хейтить... :-))

Я на самом деле к джуникам отношусь хорошо, просто надо аккуратно

Вообще нат дело писюка

Тем более уже производительность у них огого

А то привыкли isp in box

Коробка бордер нетфлоу нат и bng

Ну кстати коллеги рассказывали о довольно успешном опыте замены тонны писюков на пару МХ480 с MS-MPC, были в целом довольны

В первую очередь тем, что количество головняка снизилось

Тонна это пережитки