flexible netflow w służbie statystyk

kwestia dokładnego nadzoru ruchu wymienianego pomiędzy systemami autonomicznymi w dobie peerowania się ze wszystkimi we wszystkich dostępnych IXach stała się kluczowa do możliwości utrzymania realnej przewidywalności prowadzonego biznesu, optymalizacji wykupionych usług oraz oczywiście - optymalnej inżynierii ruchu w sieci.

dosyć popularnym, otwartym oprogramowaniem do prostego zliczania i wizualizacji ruchu wymienianego z poszczególnymi ASami oraz obciążenia połączeń z rozbiciem na poszczególne ASy jest pakiet AS-Stats - bardzo prosty, wydajny i dający szybko wgląd w to co się dzieje na routerze. kluczowym elementem pakietu jest plik knownlinks, który zawiera zestawienie identyfikatorów interfejsów - ponieważ próbki NetFlow eksportowane do kolektora zawierają tylko identyfikator. plik ten wygląda następująco:

# Router IP      SNMP ifindex    tag           description        color
192.168.0.1      1               ATMAN         ATMAN              5EA631
192.168.0.1      2               CROWLEY       Crowley            FFFF00
192.168.0.1      3               TPSA          TP                 E45605

indeks interfejsu do wpisania do tego pliku odczytuje się na eksportującym próbki NetFlow routerze poleceniem

show snmp mib ifmib ifindex

wszystko dzieje się dobrze, dopóki router nie musi zostać przeładowany - tak się na jednym poczciwym 3845 stało i wykresy zaczęły zastanawiać swoją nieprawdziwością :) okazało się oczywiście że problem był banalny - po restarcie interfejsy zostały ponumerowane od nowa i dwa z nich zamieniły się identyfikatorami. można temu zapobieć (i należy) wydając polecenie:

snmp-server ifindex persist

tak czy inaczej, próbując ustalić czemu ruch w statystykach wygląda dosyć nieprawdopodobnie wykorzystałem możliwości Cisco IOSa w zakresie dostępności z linii poleceń gotowych do analizy statystyk NetFlow - tzw. Flexible NetFlow. dotychczasowa konfiguracja NetFlow była globalna (z paroma różnymi wyjątkami), natomiast wraz w wprowadzeniem NetFlow w wersji 9 pojawiła się bardzo elastyczna modularność całej konfiguracji. nas interesowała statystyka zbiorcza ruchu per źródłowy AS na poszczególnych interfejsach, zdefiniowałem zatem rekord NetFlow:

flow record NF-DATA
 match routing source as peer
 match interface input
 collect routing source as
 collect counter bytes
 collect counter packets

a następnie trzy osobne instancje realizujące monitoring - w rzeczywistej konfiguracji moga one dodatkowo zawierać swoją własną definicję celu eksportu próbek, tutaj nigdzie tego nie eksportuje, jedynie zliczam:

flow monitor FM-ATMAN
 record NF-DATA
!
flow monitor FM-Crowley
 record NF-DATA
!
flow monitor FM-TP
 record NF-DATA

następnie tak przygotowaną definicję należy dokonfigurować do odpowiedniego interfejsu - każda zdefiniowana instancja monitora zbierać będzie zadane dane dla konkretnego ruchu wejściowego przez interfejs do konkretnego operatora:

interface GigabitEthernet 0/0.100
  description Uplink-ATMAN
  ip flow monitor FM-ATMAN input
  ip flow ingress
!
interface GigabitEthernet 0/0.101
  description Uplink-Crowley
  ip flow monitor FM-Crowley input
  ip flow ingress
!
interface GigabitEthernet 0/0.102
  description Uplink-TP
  ip flow monitor FM-TP input
  ip flow ingress

w tym momencie pamięć podręczna każdego z monitorów powinna zacząć już zapełniać się zdefiniowanymi w rekordzie NF-DATA danymi. pamięć tą zestawiać można w najróżniejsze sposoby, wykonując sortowanie, zliczanie, agregację, czy nawet eksport do pliku CSV lub na dowolny zewnętrzny nośnik. nas interesowało jednak tylko zweryfikowanie, że na każdym z interfejsów dociera do nas ruch z konkretnych ASów.

c3845#show flow monitor FM-ATMAN cache aggregate routing source as counter bytes sort highest counter bytes
Processed 6 flows
Aggregated to 6 flows
Showing the top 6 flows

IP SRC AS       BYTES       flows
=========  ==========  ==========
24724      1669629642           1
2529        375072464           1
16265       172599860           1
8615             2173           1
2852               64           1

i istotnie - na łączu do ATMANa widać wyraźnie że najwięcej ruchu dociera z samego ASa 24724. z kolei na łączu z TP:

c3845#show flow monitor FM-TP cache aggregate routing source as counter bytes sort highest counter bytes
Processed 8 flows
Aggregated to 8 flows
Showing the top 8 flows

IP SRC AS       BYTES       flows
=========  ==========  ==========
5617        166892112           1
34805         1435138           1
41023            1613           1
48224            1400           1
39006            1063           1
283               437           1
20829             152           1

...też głównym dostawcą zawartości jest AS5617 - oczywiście nie zawsze tak musi być, ale może to posłużyć do szybkiej weryfikacji czy wykresy statystyk ruchowych nie pokazują nieprawdy. czy zdefiniowanie takich monitorów mocno obciąża procesor? dla ruchu zagregowanego ponad 300Mbit/s i platformy 3845 skok w obciążeniu wynosi 2-3%. przy dobrze dobranej platformie nie ma się zatem co przejmować.

Łukasz Bromirski

Read more posts by this author.

Warszawa, Polska http://lukasz.bromirski.net