GrandPr1de Опубликовано 29 ноября, 2017 · Жалоба Есть проблемка. Сливаю с MX-104 netflow v5, параллельно есть ещё радиус аккаунтинг. Нетфлоу чисто для подсчета трафика. При этом статистика общий трафик по нетфлоу примерно десятая часть, от того, что пришло в радиус аккаунтинге. Sample включается на каждую сессию в динамическом профиле. Подскажите, что может стоит поменять? Junos: 15.1R6.7 Конфиг: dynamic-profiles { service-shape-in { variables { speed-var default-value 1m; shape-name-in uid; ip default-value 127.0.0.1; fw-name-in uid; link-name-in { default-value fw-name-in; uid-reference; } burst equals " ($speed-var * 1.35) "; } interfaces { "$junos-interface-ifd-name" { unit "$junos-interface-unit" { family inet { filter { input "$fw-name-in" precedence 100; } } } } } firewall { family inet { filter "$fw-name-in" { interface-specific; term 0 { from { source-address { $ip; } } then { policer "$shape-name-in"; sample; accept; } } } } policer "$shape-name-in" { filter-specific; if-exceeding { bandwidth-limit "$speed-var"; burst-size-limit "$burst"; } then discard; } } } service-shape-out { variables { speed-var default-value 1m; shape-name-out uid; ip default-value 127.0.0.1; fw-name-out uid; link-name-out { default-value fw-name-out; uid-reference; } } interfaces { "$junos-interface-ifd-name" { unit "$junos-interface-unit" { family inet { filter { output "$link-name-out" precedence 100; } } } } } firewall { family inet { filter "$fw-name-out" { interface-specific; term 0 { from { destination-address { $ip; } } then { policer "$shape-name-out"; sample; accept; } } } } policer "$shape-name-out" { if-exceeding { bandwidth-limit "$speed-var"; burst-size-limit 10m; } then discard; } } } } forwarding-options { sampling { sample-once; input { rate 1; } family inet { output { flow-inactive-timeout 15; flow-active-timeout 60; flow-server xxx.xxx.xxx.1 { port 1000; autonomous-system-type origin; no-local-dump; source-address xxx.xxx.xxx.2; version 5; } } } } } Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
purecopper Опубликовано 29 ноября, 2017 · Жалоба Мы netflow снимаем с зеркала. Очень уж sampling напрягает FPC. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 29 ноября, 2017 · Жалоба inline поддерживается только ipfix/v9 у вас же v5 , соответственно у вас оно обрабатывается на RE , но там есть ограничение на кол-во пакетов (10к по моему) , все что выше соответственно дропается. P.S. и вообще нужно проверить програмируется ли правильно ваш фильтр... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 29 ноября, 2017 · Жалоба Скорее всего какой-то рейт лимит, ибо на тетсах очень четко всё считалось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
purecopper Опубликовано 29 ноября, 2017 · Жалоба orlik inline он же вроде только с MS-MPC. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 29 ноября, 2017 · Жалоба Ipfix инлайн на любой Mac. Карте Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 29 ноября, 2017 · Жалоба Дерьмово, мне нужен именно netflow v5 :( Придется как-то трафик себе зеркалить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 29 ноября, 2017 · Жалоба Необходимо на EX4550 сделать две сессии зеркала с разных src портов в разные dst порты (СОРМ и DPI), судя по https://kb.juniper.net/InfoCenter/index?page=content&id=KB21200 и https://www.juniper.net/documentation/en_US/junos/topics/concept/port-mirroring-ex-series.html#port-mirror-terminology можно сделать 7 сессий, но в пределах своих PFE или же одна глобальная если используется VLAN, LAG, Firewall. Как я понял вот такой конфиг уже попадает под ограничения 1 глобальной сессии и вторая не сработает? Пример: ethernet-switching-options { analyzer COPM { input { ingress { interface ae3; BRAS interface ae4; BRAS interface xe-0/0/12; RADIUS interface xe-0/0/13; RADIUS } } output { interface { xe-0/0/11.0; СОРМ } } } ethernet-switching-options { analyzer COPM { input { ingress { interface ae3; PPPoE interface ae4; PPPoE } } output { interface { xe-0/0/10.0; DPI } } } Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 29 ноября, 2017 · Жалоба 7 часов назад, orlik сказал: inline поддерживается только ipfix/v9 у вас же v5 , соответственно у вас оно обрабатывается на RE , но там есть ограничение на кол-во пакетов (10к по моему) , все что выше соответственно дропается. P.S. и вообще нужно проверить програмируется ли правильно ваш фильтр... купили nprobe, сделали прокси v9 to v5 и всё как надо спасибо за совет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 10 декабря, 2017 · Жалоба Столкнулся с проблемой, на EX4550 где заявлено 32к маков, на очень "волатильной" сети (роутеры юзеров относительно часто появляются и исчезают из маков) в 28к маков - sfid сжирает весь проц на 12-й версии junos , а на 15-й версии он вообще убивает свитч, через время load average улетает в небеса и ssh отсыхает. Начинает более-менее сносно работать на ~7k маков, и то, пакетики на транзитных вланах теряет. Кроме того свитч в таком стрессе начинает терять пакеты, что вообще хреново (пусть он бы лучше не запоминал нестабильный мак с первого раза, чем дропал транзитный траффик со стабильными маками). no-mac-learning в юзерских вланах в случае терминации на одном BRAS конечно прокатывает (все равно один порт на вход и выход), но хочется понять - это лечится? Какие-то более старшие модели ведут себя получше, или же джуны на агрегации не выживают? Увеличивать aging mac-ов пробовал - не помогает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 11 декабря, 2017 · Жалоба Посмотрите на команду set ethernet-switching-options mac-lookup-length и https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR842439 Вот ещё обсуждение тут же forum.nag.ru Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 11 декабря, 2017 · Жалоба Командой пользовался конечно же, проблему решило только частично (слегка уменьшило нагрузку). Вобщем буду советовать клиенту переезжать на железо без проблемы с коллизиями. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 11 декабря, 2017 · Жалоба Кто знает, EX4600 тоже болеет этим? Там 200к+ маков заявлено Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 12 декабря, 2017 · Жалоба 21 час назад, nuclearcat сказал: Кто знает, EX4600 тоже болеет этим? Там 200к+ маков заявлено Нее , там все честно , там проблем с коллизиями нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
smelnik Опубликовано 11 января, 2018 · Жалоба Коллеги, а подскажите пожалуйста по Juniper L3vpn хочу поменять next-hop для экспортированных префиксов делаю show routing-instances VPN-A instance-type vrf; interface lo0.2000; route-distinguisher 65000:2000; vrf-import vpna-import; vrf-export vpna-export; routing-options { static { route 192.168.2.0/24 discard; } } show policy-options policy-statement vpna-export term ONE { from { route-filter 192.168.2.0/24 exact; } then { community add vpna-comm; next-hop 1.1.1.1; accept; } } term TWO { then reject; } Next-hop не меняется run show route 192.168.2.0/24 advertising-protocol bgp 2.2.2.2 extensive VPN-A.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) * 192.168.2.0/24 (1 entry, 1 announced) BGP group IBGP type Internal Route Distinguisher: 65000:2000 VPN Label: 299792 Nexthop: Self Flags: Nexthop Change Localpref: 100 AS path: [65000] I Communities: target:65000:2000 При этом на втором MX с такими же политиками всё ок. При этом не работает на MX, который является route reflector`ом. вот чяднт Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v_r Опубликовано 11 января, 2018 · Жалоба @smelnik Вероятно next-hop меняется экспортной политикой для cсоседа 2.2.2.2 (и вообще я не уверен что в vrf-export можно указать next-hop PE роутера). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
smelnik Опубликовано 11 января, 2018 · Жалоба @v_r В том-то и дело что нет ( vrf-export обрабатывается отдельно от export для соседа. Изменить поведение можно указав vpn-apply-export. Но это не этот случай :) В vrf-export можно менять next-hop. В данной схеме PE1 и PE2 соединены прямым линком. PE1 - RR - на нём set next-hop не работает. PE2 - route-reflector client. На нём set next-hop работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v_r Опубликовано 11 января, 2018 · Жалоба @smelnik Еще один вариант - возможно на PE2 настроен vrf-table-label для VPN-A, хотя опять-таки я не уверен влияет ли он на next-hop в данном случае. И думаю что RR/не-RR не имеет отношения к next-hop. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
smelnik Опубликовано 11 января, 2018 · Жалоба @v_r vrf-table-lable не включен. Я понимаю, что rr влиять не должен, но это единственное отличие :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
smelnik Опубликовано 12 января, 2018 · Жалоба @v_r И всё же это RR :) Позже отпишусь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
smelnik Опубликовано 14 января, 2018 · Жалоба В общем на RR next-hop-self к vrf-export не применяется. Хотим изменить next-hop, как в моём случае, применяем vpn-apply-export и настраиваем политики на export для соседей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sided Опубликовано 8 февраля, 2018 · Жалоба есть MX240 Enhanced MX SCB MPC 3D 16x 10GE PIC 3 BUILTIN BUILTIN 4x 10GE(LAN) SFP+ на нем виртуальный logical-systems поднят туннель между ними, там бгп run show interfaces lt-1/3/0 Physical interface: lt-1/3/0, Enabled, Physical link is Up Interface index: 148, SNMP ifIndex: 1507 Type: Logical-tunnel, Link-level type: Logical-tunnel, MTU: Unlimited, Speed: 100000mbps Device flags : Present Running так вот, у нас вырос чуть трафик, соответственно он вырос и в туннеле. НО! не прокачивается больше 16г сумарно, хотя он и Speed: 100000mbps увеличивается пинг даже между пиринговыми ипами туннеля и проседает скорость конечно у всех кто идет через тунель принудительно скорость не ставили run show configuration chassis fpc 1 pic 3 { tunnel-services; } никаких фильтров на интерфейсе нет просто unit 100 { encapsulation ethernet; peer-unit 200; family inet { address 10.10.10.1/30; } unit 200 { encapsulation ethernet; peer-unit 100; family inet { address 10.10.10.2/30; } в каком направлении копать? подскажите пожалуйста Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 9 февраля, 2018 · Жалоба https://www.safaribooksonline.com/library/view/juniper-mx-series/9781449358143/ch01s04.html судя по схеме PIC имеет полосу 40G до фабрики. И если не ошибаюсь, то на плату полоса не 160Г как на все порты было бы, а 120Г. итого 30Г на 4 порта?.. вполне вероятно это ваше ограничение. конвертируйте еще PIC и ECMP балансировку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sided Опубликовано 11 февраля, 2018 · Жалоба ответ с форума джунипер Please refer this document: https://www.juniper.net/documentation/en_US/junos/topics/concept/chassis-mpc-16-port-10-gigabit-ethe... -> Supports one full-duplex 10-Gigabit Ethernet tunnel interface for each Packet Forwarding Engine https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/chassis-tunnel-interface... So just to add more info, you're limited to 10g per PFE. 1/3/x & 1/2/x LT = 10g 1/0/x & 1/1/x LT = 10g In your case, if you want to continue on FPC1, use pic0 or pic1 for LT bandwithd. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 12 февраля, 2018 · Жалоба я бы обратил на это из документации: Supports an effective line rate of twelve 10-Gigabit Ethernet ports. If all sixteen 10-Gigabit Ethernet ports are used, the line card is oversubscribed in the ratio of 4:3. По графикам явно видно больше 10Г (20Г half) на LT. Но уровень поход на 15Г (30Г half) как на переподписку. Type: Logical-tunnel, Link-level type: Logical-tunnel, MTU: Unlimited, Speed: 100000mbps 100Г - это чисто информационна составляющая. Для SNMP к примеру. поставите 1Мбит - порт все равно будет качать гигабиты Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...