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 jest 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ć.