Netflow

[rack]

Mam taką konfigurację na MX5-t:

Kod: Zaznacz cały

forwarding-options {
    sampling {
        input {
            rate 1000;
            run-length 10;
            max-packets-per-second 100;
        }
        family inet {
            output {
                file filename flow_test files 2 size 2k;
                flow-server 192.168.13.15 {
                    port 9991;
                    source-address 172.16.20.11;
                    version 5;
               }

ge-1/1/3 {
        description INTERNET;
        unit 0 {
            family inet {
                filter {
                    input FLOW_DATA;
                }
                address x.x.x.x;


firewall {
    family inet {
        filter FLOW_DATA {
            term CALY_RUCH {
                then {
                    sample;
                    accept;
                }
            }
        }
    }

Nie odkładają mi się żadne informacje na serwerze. Lokalnie problemu nie ma. Informacje się odkładają do pliku flow_test, ale ja muszę to obsłużyć na serwerze.Sprawdziłem TCPDUMP'em i serwer otrzymuje pakiet na port 9991 od routera, ale wygląda na to, że nic w nim nie ma, bo nie przyrastają mi liczniki w flowctl. Obecnie serwer ten obsługuje netflow z routerów Cisco i z nich mi się prawidłowo zbierają staty.

Czy widzi ktoś jakiś błąd w konfiguracji?

[michaliwanczuk]

nic nie blokuje Ci ruchu z MX'a do serwera zbierającego flowy ?

[rack]

No właśnie nie. TCPDUMP na serwerze pokazuje pakiety od routera. Co ciekawe każda komenda z serii "show services accounting" zwraca pusty wynik. To jest poprawne zachowanie?

[rack]

Dobra widzę, że problem mam na serwerze. Nie wiem dlaczego, ale flowd, który mi teraz zbiera informacje z Cisco nie rozumie informacji z Junipera. Postawiłem obok serwer z nfcap i nfdump i na nim netflow jest prawidłowo przetwarzany. Nie wiem dlaczego flowd nie rozumie junipera. Z tego co wiem netflow jest standardem i informacje powinny wyglądać tak samo u wszystkich vendorów. Poprawcie mnie jeśli tak nie jest. Ma ktoś jakiś sprawdzony soft na linuxa, którym zbiera netflowa z juniperów? Obecnie jestem na etapie testowania nfcap,nfdump i nfsen. Jakby ktoś miał jakąś ciekawszą sprawdzoną alternatywę opensource to pisać proszę.

UPDATE

FLOWD zrozumiał Junipera. Miałem mały błąd w konfigu, ale okazuje się że Juniper przesyła błędne info do collectora.

[B.]

Z tego co wiem netflow jest standardem i informacje powinny wyglądać tak samo u wszystkich vendorów.

Standard standardem, a implementacje moga byc rozne.

[mdenis]

Swoją drogą ma ktoś doświadczenie ile ruchu można samplować bez dodatkowej karty MS czy AS ?

[rack]

W mojej powyższej konfiguracji sampluje wszystko na in i na out, ale nic to nie daje ponieważ informacje przekazywane do collectora to bzdury. Otworzyłem case w JTAC i otrzymałem odpowiedź, że bez karty na MX5 jest wspierany tylko IPFIX. Po w prowadzeniu komendy na siłę otrzymuje komunikat że jest ona deprecated... walczę póki co z JTACiem, case już był raz eskalowany, bo mi gość internet w firmie odłączył w środku dnia i oprócz tego marnowałem czas na tłumaczenie mu oczywistych rzeczy, które on powinien wiedzieć. Na chwilę obecną z powodu netflow, który jest dla mnie kluczowy jestem bardzo niezadowolony z tego sprzętu i poziomu obsługi JTAC, który woła o pomstę do nieba. MX5 bez dodatkowego modułu Ci wiarygodnego netflowa nie zrzuci niestety.

[mdenis]

W mojej powyższej konfiguracji sampluje wszystko na in i na out, ale nic to nie daje ponieważ informacje przekazywane do collectora to bzdury. Otworzyłem case w JTAC i otrzymałem odpowiedź, że bez karty na MX5 jest wspierany tylko IPFIX. Po w prowadzeniu komendy na siłę otrzymuje komunikat że jest ona deprecated... walczę póki co z JTACiem, case już był raz eskalowany, bo mi gość internet w firmie odłączył w środku dnia i oprócz tego marnowałem czas na tłumaczenie mu oczywistych rzeczy, które on powinien wiedzieć. Na chwilę obecną z powodu netflow, który jest dla mnie kluczowy jestem bardzo niezadowolony z tego sprzętu i poziomu obsługi JTAC, który woła o pomstę do nieba. MX5 bez dodatkowego modułu Ci wiarygodnego netflowa nie zrzuci niestety.

Ja sampluje na M120, i narazie na rate 1000 + 10 następnych pakietów i działa dobrze. W sumie przy ruchu 200 Mb/s nie zauważyłem jakiegokolwiek zwiększenia zużycia zasobów. Gdzieś wyczytałem że na tzw. "RE based sampling" można dojechać do 7000 pkt/s.
Jutro będę to testował na większym ruchu to się okaże ile w tym prawdy.
Zbieram to nfdumpem + nfsen i zadziałało od pierwszego razu.
Trochę to dziwne, że na mx5 nie rusza. Config wygląda praktycznie jak u mnie. Co masz na myśli że collector dostaje bzdury ?

[rack]

Otrzymuje informacje o ruchu znacznie odbiegające od rzeczywistości. Przykładowo ruch sumaryczny z danej podsieci na out wskazuje według netflow na 5Mb podczas gdy SNMP wskazuje na 13 Mb. SNMP mówi prawdę ponieważ klient też sam monitoruje swoją infrastrukturę i rzeczywiście generuje 13Mb. Ja zbieram nfdumpem i flowd i na obu to samo.

[mdenis]

Otrzymuje informacje o ruchu znacznie odbiegające od rzeczywistości. Przykładowo ruch sumaryczny z danej podsieci na out wskazuje według netflow na 5Mb podczas gdy SNMP wskazuje na 13 Mb. SNMP mówi prawdę ponieważ klient też sam monitoruje swoją infrastrukturę i rzeczywiście generuje 13Mb. Ja zbieram nfdumpem i flowd i na obu to samo.

Powiem tak, wygląda mi to na problem tutaj :

forwarding-options {
sampling {
input {
rate 1000;
run-length 10;
max-packets-per-second 100;
}

Wywal run-lenght, wtedy zobaczysz czy wskazuje poprawne wartości. Ogólnie większość programów do analizy danych z którymi się narazie spotkałem ma właśnie problem z odpowiednim zinterpretowaniem wyników jeżeli używasz run-lenght na junie.

[rack]

Run-lenght wyrzuciłem, bo według dokumentacji nie jest on wspierany na MX5. Obecnie mam rate na 1 ustawiony bez żadnych dodatkowych opcji. Nie będę teraz wklejał konfiguracji.Cały czas się ona zmienia, bo ludzie z JTAC podsyłają teraz swoje pomysły. Jak uda się rozwiązać to opisze tu dla potomnych.

[rack]

Tak więc jak obiecałem opiszę dla potomnych:

Po 1. Routery MX-5-t nie obsługują netflowa w klasycznej postaci, a jedynie IPFIX.

Po 2. Konfiguracja, którą zamieściłem na początku, nie nadaje się do niczego. Poniżej jest działająca:

Kod: Zaznacz cały

set chassis tfeb slot 0 sampling-instance sample
set interfaces ge-1/1/3 unit 0 family inet sampling input
set interfaces ge-1/1/3 unit 0 family inet sampling output
set forwarding-options sampling instance sample input rate 1
set forwarding-options sampling instance sample family inet output flow-server <adres_collectora> port 9911
set forwarding-options sampling instance sample family inet output flow-server <adres_collectora> autonomous-system-type peer
set forwarding-options sampling instance sample family inet output flow-server <adres_collectora> no-local-dump
set forwarding-options sampling instance sample family inet output flow-server <adres_collectora> version-ipfix template ipv4
set forwarding-options sampling instance sample family inet output inline-jflow source-address <wiadomo>
set forwarding-options sampling instance sample family inet output inline-jflow flow-export-rate 100
set services flow-monitoring version-ipfix template ipv4 flow-active-timeout 10
set services flow-monitoring version-ipfix template ipv4 flow-inactive-timeout 10
set services flow-monitoring version-ipfix template ipv4 template-refresh-rate packets 1000
set services flow-monitoring version-ipfix template ipv4 template-refresh-rate seconds 10
set services flow-monitoring version-ipfix template ipv4 ipv4-template

Po 3. Nie wypchniemy pakietów z informacjami o ruchu przez interfejsy OOB (fxp), co mi skutecznie utrudniło życie...