но вообще я пришел не за этим

кто сталкивался с тем, что JunOS игнорирует flow timeout active / inactive для inline IPFIX на MX?

в конфиге стоит 15, а флоу летят по 180++ секунд

кто сталкивался с тем, что JunOS игнорирует flow timeout active / inactive для inline IPFIX на MX?

мне кажется ты уже задавал этот вопрос один раз

и я так и не нашел ответа на этот вопрос

это происходит с завидной регулярностью на однаковов железе

иногда - пашет как часы

иногда - нихера

а софт какой?

последнее рекомендованное джунипером

я лично не сталкивался, но я и не мониторю это специально конечно же

а кейсы заводить пробовал ?)

там индусы

"а вы пробовали перезагружать"

они нихера не понимают что такое flow duration

надо резидент-инженеров ловить

ссылаются на документацию раз за разом и несут бред

локальных

они есть

ну и проблема в том, что это все разные железки

а, еще

около я заметил что число флоу потоков мотается 512-1024 каждый раз когда баг происходит

ну в MX супервизоры одинаковые, кроме ppc-версий поэтому и бага может быть одна

и я подозреваю, где-то есть рейт лимит на число потоков флоу в секунду либо на число aged потоков в секунду

я такое отловил на ASR 9k

cache timeout rate-limit 4096

около я заметил что число флоу потоков мотается 512-1024 каждый раз когда баг происходит

jflow inline?

на ASR 9k был вот этот конфиг

ага, инлайн

такое ощущение, что у него зашито число потоков, которые он сбрасывает за секунду

и если их больше - он тупо их игнорит

и они удлиняяются, потому что их никто не обреза и не сбросил на коллектор 😕

такое ощущение, что у него зашито число потоков, которые он сбрасывает за секунду

flow-export-rate какой выставлен? максимум может быть 100 (Kpps) на pfe то есть если карта с двумя пфе то 200

я вот тоже сейчас смотрю на этот параметр.... почему он pps?

странно мерить число флоу в секунду в pps 😕

я так понимаю, это число пакетов от сэмплера в сторону нетфлоу агента

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

они нихера не понимают что такое flow duration

Ну ты поднимай кейс сразу

Пару раз свопнешь инженера и менеджер придёт

не помогало 🙁 попробеум в следующий раз

@pavel_odintsov

NPC1(mx480-under vty)# show jnh 0 inline-services flow-table-info Configured IPv4 Flow Table in Unit: 0 Configured IPv6 Flow Table in Unit: 0 Configured VPLS Flow Table in Unit: 0 Programmed IPv4 Flow Table Size : 3932160 Programmed IPv6 Flow Table Size : 1024 Programmed VPLS Flow Table Size : 1024 IPv6 Extended Attribute : 0 IPv4 Ring Buffer Size : 262144 IPv6 Ring Buffer Size : 262144 VPLS Ring Buffer Size : 262144

Посмотри сюда

на какой именно флажок?

units—Number of 256K flow entries available for the IPv4 flow table. Range: 1 through 245 Default: 1024 (1K)—Starting with Junos OS Release 16.1R1 and 15.1F2 Default: 3,932,160 (3840K)—Prior to Junos OS Release 16.1R1 and 15.1F2

Ща, доберусь с компа найду

пасиб!

пасиб!

1) show services accounting flow inline-jflow fpc-slot X

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

start shell pfe network fpcX show jnh 0 inline-services flow-table-info

если все плохо - https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/ipv4-flow-table-size.html

ставим

делаем лучше в MW

@blademd я сталкивался с таким же поведением на а9к, если что

Давно хотел подробнее написать про механизм virtual ethernet segment, о котором упоминал ранее. Во-первых, механизм vES позволяет не только распределять функции DF между AC, это далеко не первопричина его появления, а скорее приятный побочный эффект. Классический способ использования ES для физического интерфейса не всегда работает в случае, если между CE и PE есть какая-либо агрегационная сеть (L2 или MPLS), так как связь между AC и физическими интерфейсами со стороны различных PE, подключенных к агрегационной сети, может быть произвольной. Представьте три PE, подключенные к общему L2 сегменту, на одном PE в сторону этого сегмента настроены два сервиса EVPN (A, B), но на каждом из оставшихся только по одному сервису (либо A, либо B). Очевидно, что три физических интерфейса этих PE невозможно объединить в общий ES по старинке, так как механизм выбора DF может выбрать маршрутизатор, на котором заданного сервиса нет. Дополнительно отмечу, что на физическом интерфейсе можно смешивать различные типы vES: single-homed, single-active multi-homed, active-active multi-homed, конечно же, в зависимости от конкретной реализации. Несмотря на возросшую гибкость, разработчики черновика указывают на необходимость введения механизма mass withdraw уже для группы маршрутов type 1 per ES, так как время сходимости сети при некоторых типах отказа будет увеличиваться в зависимости от количества таких маршрутов (читай – используемых vES). Второй момент, который стоит прояснить — это автоматически сгенерированные значения ESI (точнее даже vESI). Например, для ES type 1 JunOS в поле CE LACP Port Key устанавливает значение с номером unit, что позволяет получить отличные друг от друга vESI. Если изучить другие типы ES в RFC 7432 (Sec. 5) очевидно, что данный подход возможно транслировать и на них. И всё-таки некий простор для проблем тем не менее просматривается, ведь различные реализации протокола должны независимо друг от друга выбирать одинаковый идентификатор vESI. А теперь небольшая история. Если в JunOS на физическом интерфейсе, который является частью ES, отключить (disable) любой unit, то PE автоматически откажется от роли DF для всех instance этого интерфейса, все single-active AC перейдут в состояние Blocked, для all-active они останутся Forwarding. Если смотреть глубже, то при отключении любого unit автоматически отзываются маршруты type 1 per ES и type 4, для all-active маршруты type 1 per EVI продолжают анонсироваться. В точности причины такого поведения мне неизвестны, но предлагаю порассуждать. Отключив unit, можно легко столкнуться с ситуацией, когда instance, частью которого он является, выступает в роли DF на текущем PE. Тогда мы рискуем изолировать сегмент от BUM трафика, так как другие его PE не выберут новый DF между собой до тех пор, пока анонсируется type 4 с текущего. Однако отозвать type 4 только для одного instance невозможно, он генерируется на физический интерфейс. С другой стороны, отключаемый unit может быть частью instance, где PE не является DF на общем сегменте. Зачем отзывать type 4 тогда? Скорее всего это происходит из-за того, что в случае отказа DF новым может быть выбран тот PE, на котором unit в этом instance нами отключен и мы снова приходим к ситуации с изоляцией сегмента от BUM трафика. Интересно, что в случае с active-active невозможно заблокировать все unit, так как скорее всего в сторону CE собран LAG, по которому может приходить трафик, но так как отзывается type 1 per ES (даже несмотря на оставшийся type 1 per EVI) трафик будет передаваться только в одну сторону (от CE к удалённым PE), но не обратно. Вообще всё это о том, что парой неловких движений можно не только лишить сегмент BUM трафика, а вообще изолировать его полностью от сети. Никогда не слышал о подобном механизме в других реализациях EVPN, как мне кажется, здесь больше вреда, чем пользы. Забавно и то, что vES прекрасно подходит здесь как workaround.

делаем лучше в MW

смотреть конкретно нужо на : Programmed IPv4 Flow Table Size Programmed IPv6 Flow Table Size

принято!

@blademd я сталкивался с таким же поведением на а9к, если что

Было не плохо, если бы это как-то документально где-то было описано, а то вангование какое-то сплошное

Было не плохо, если бы это как-то документально где-то было описано, а то вангование какое-то сплошное

ну это реализация EVPN :) Видимо думают, что раз прочитал RFC, то должен понимать боль

Надо просто пообщаться с кем-нибудь, кто близок к телу

https://www.noction.com/clients/dqe

Дооптимизировались

https://twitter.com/atoonk/status/1143153922594373638

That combined with verizon not filtering its customers

не зря их хуавей щимит

аж обидно, да? :)

аж обидно, да? :)

Да это все армяне. Мисак меня хейтил, что я принимал строго по ripedb, а не все до /24 маски бай дефолт

Да это все армяне. Мисак меня хейтил, что я принимал строго по ripedb, а не все до /24 маски бай дефолт

лул

Да это все армяне. Мисак меня хейтил, что я принимал строго по ripedb, а не все до /24 маски бай дефолт

Наши большие строго по ripedb автоматом фильтры генерят

при этом он жёстко топит не вливать специфики ворлд вайд, потому что фиб распухает

два стула этому сударю

Наши большие строго по ripedb автоматом фильтры генерят

+

В том регионе поди плохо все с irr

в том? Это ж Омерико?

Наши большие строго по ripedb автоматом фильтры генерят

И это правильно, но все равно, никто не мешает в свой as-set добавить asn/as-set cloudflare)

Ну

радоначальники инета не умеют в инет?

И это правильно, но все равно, никто не мешает в свой as-set добавить asn/as-set cloudflare)

ну да, но все равно это менее вероятно чем вот это

радоначальники инета не умеют в инет?

Говорят, что райпдб образец всего, по сравнению с другими