[GrandPr1de]

Есть проблемка.

Сливаю с 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;
                }
            }
        }
    }
}

 

[purecopper]

Мы netflow снимаем с зеркала.

Очень уж sampling напрягает FPC.

[orlik]

inline поддерживается только ipfix/v9 у вас же v5 , соответственно у вас оно обрабатывается на RE , но там есть ограничение на кол-во пакетов (10к по моему) , все что выше соответственно дропается. 

 

P.S. и вообще нужно проверить програмируется ли правильно ваш фильтр...

[GrandPr1de]

Скорее всего какой-то рейт лимит, ибо на тетсах очень четко всё считалось.

[purecopper]

orlik inline он же вроде только с MS-MPC.

[orlik]

Ipfix инлайн на любой Mac. Карте

[GrandPr1de]

Дерьмово, мне нужен именно netflow v5 :(

Придется как-то трафик себе зеркалить.

[hsvt]

Необходимо на 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
            }
        }
    }

 

[GrandPr1de]

7 часов назад, orlik сказал:

inline поддерживается только ipfix/v9 у вас же v5 , соответственно у вас оно обрабатывается на RE , но там есть ограничение на кол-во пакетов (10к по моему) , все что выше соответственно дропается. 

 

P.S. и вообще нужно проверить програмируется ли правильно ваш фильтр...

купили nprobe, сделали прокси v9 to v5 и всё как надо

спасибо за совет

[nuclearcat]

Столкнулся с проблемой, на EX4550 где заявлено 32к маков, на очень "волатильной" сети (роутеры юзеров относительно часто появляются и исчезают из маков) в 28к маков - sfid сжирает весь проц на 12-й версии junos , а на 15-й версии он вообще убивает свитч, через время load average улетает в небеса и ssh отсыхает. Начинает более-менее сносно работать на ~7k маков, и то, пакетики на транзитных вланах теряет.

Кроме того свитч в таком стрессе начинает терять пакеты, что вообще хреново (пусть он бы лучше не запоминал нестабильный мак с первого раза, чем дропал транзитный траффик со стабильными маками).

no-mac-learning в юзерских вланах в случае терминации на одном BRAS конечно прокатывает (все равно один порт на вход и выход), но хочется понять - это лечится? Какие-то более старшие модели ведут себя получше, или же джуны на агрегации не выживают?

Увеличивать aging mac-ов пробовал - не помогает.

[orlik]

Посмотрите на команду 

set ethernet-switching-options mac-lookup-length и https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR842439

 

 

Вот ещё обсуждение тут же forum.nag.ru

[nuclearcat]

Командой пользовался конечно же, проблему решило только частично (слегка уменьшило нагрузку).

Вобщем буду советовать клиенту переезжать на железо без проблемы с коллизиями.

[nuclearcat]

Кто знает, EX4600 тоже болеет этим? Там 200к+ маков заявлено

[orlik]

21 час назад, nuclearcat сказал:

Кто знает, EX4600 тоже болеет этим? Там 200к+ маков заявлено

Нее , там все честно , там проблем с коллизиями нет

[smelnik]

Коллеги, а подскажите пожалуйста по 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`ом.

вот чяднт

[v_r]

@smelnik Вероятно next-hop меняется экспортной политикой для cсоседа 2.2.2.2 (и вообще я не уверен что в vrf-export можно указать next-hop PE роутера).

[smelnik]

@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 работает.

[v_r]

@smelnik Еще один вариант - возможно на PE2 настроен vrf-table-label для VPN-A, хотя опять-таки я не уверен влияет ли он на next-hop в данном случае.

И думаю что RR/не-RR не имеет отношения к next-hop.

[smelnik]

@v_r vrf-table-lable не включен. Я понимаю, что rr влиять не должен, но это единственное отличие :)

[smelnik]

@v_r И всё же это RR :) Позже отпишусь.

[smelnik]

В общем на RR next-hop-self к vrf-export не применяется.

Хотим изменить next-hop, как в моём случае, применяем vpn-apply-export и настраиваем политики на export для соседей.

[Sided]

есть 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;
    }
 

в каком направлении копать? подскажите пожалуйста

[dmvy]

https://www.safaribooksonline.com/library/view/juniper-mx-series/9781449358143/ch01s04.html

судя по схеме PIC имеет полосу 40G до фабрики. И если не ошибаюсь, то на плату полоса не 160Г как на все порты было бы, а 120Г. итого 30Г на 4 порта?.. вполне вероятно это ваше ограничение. конвертируйте еще PIC и ECMP балансировку.

[Sided]

ответ с форума джунипер

 

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.

[dmvy]

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

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Мбит - порт все равно будет качать гигабиты