NetFlow v1, v5 i trochę o innych wersjach
 

NetFlow składa się z dwóch komponentów. Jeden zajmuje się obsługą przepływów w lokalnej pamięci urządzenia, a drugi ich eksportem do kolektora. Rodzaj i ilość danych eksportowanych do kolektora zależy od wybranej wersji eksportu danych. Należy pamiętać, że niekoniecznie wszystkie informacje, jaki można zobaczyć w lokalnej pamięci urządzenia będą eksportowane i niekoniecznie wszystkie będą wspierane przez kolektor. Dostępnych jest kilka wersji formatu eksportu danych NetFlow. Dużą część z nich omówimy w tym artykule.


Zainteresowanych zbieraniem danych o ruchu oraz jego analizą zachęcamy do zapoznania się z Cisco Stealthwatch.


Eksport danych z użyciem NetFlow v1
 
Oryginalny format, obsługiwany od samego początku protokołu NetFlow. Dostępny jest od wersji 11.0 oprogramowania Cisco IOS. Obecnie nie jest stosowany, za wyjątkiem potrzeby kooperacji z kolektorami nie wspierającymi wyższych wersji. Obsługuje on tylko protokół IPv4 i eksport danych tylko z Main Cache. W każdym pakiecie może przenosić do 24 przepływów. Format ten zakłada, że wszystkie informacje o przepływach są zbierane tylko na wejściu interfejsu (brak pola wskazującego kierunek przepływu).
 
Do kolektora eksportowane są tylko podstawowe informacje na temat każdego z przepływów, którymi są:
  • interfejs wejściowy i wyjściowy (SNMP ifIndex),
  • pola Source i Destination Address w nagłówku protokołu IPv4,
  • pole DSCP (Differentiated Services Code Point), dawniej ToS (Type of Service) w nagłówku IPv4,
  • pole Protocol w nagłówku IPv4,
  • pola Source i Destination Port w nagłówku protokołu TCP/UDP,
  • zbiorcze (OR) flagi dla protokołu TCP,
  • adres IP urządzenia następnego przeskoku,
  • łączna ilość przesłanych pakietów,
  • łączna ilość przesłanych bajtów,
  • czas trwania (rozpoczęcie i zakończenie).

Pola klucze zostały oznaczone kolorem zielonym.

Włączenie usługi NetFlow dokonuje się per interfejs z którego ma być zbierany ruch. W naszym przykładzie ruch będzie przepływał pomiędzy interfejsem GigabitEthernet 0/0, a GigabitEthernet 0/1. W związku z chęcią wykorzystania formatu eksportu danych NetFlow w wersji 1, dane będziemy chcieli zbierać tylko na wejściu tych interfejsów (ang. ingress). Zagwarantuje nam to poprawną interpretację tych informacji po stronie kolektora.

R2# configure terminal
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip flow ingress
R2(config)# interface GigabitEthernet0/1
R2(config-if)# ip flow ingress
R2(config-if)# end
R2# show ip flow interface
GigabitEthernet0/0
  ip flow ingress
GigabitEthernet0/1
  ip flow ingress
R2#

Po wydaniu powyższych poleceń, urządzenie zacznie zapełniać Main Cache informacjami o przepływach. Poniższym poleceniem możemy dokonać weryfikacji konfiguracji sposobu eksportu danych dla Main Cache.

R2# show ip flow export
Flow export v1 is disabled for main cache
  Version 1 flow records
  0 flows exported in 0 udp datagrams
  0 flows failed due to lack of export packet
  0 export packets were sent up to process level
  0 export packets were dropped due to no fib
  0 export packets were dropped due to adjacency issues
  0 export packets were dropped due to fragmentation failures
  0 export packets were dropped due to encapsulation fixup failures
R2#

Domyślną wersją eksportu danych jest wersja 1. Zatem jedynce co musimy zrobić, to zdefiniować kolektor i opcjonalnie wskazać interfejs źródłowy (warto wykorzystać do tego celu interfejs Loopback, co zagwarantuje nam niezmienność adresu IP, który to powinien być taki sam dla wszystkich danych wysyłanych z jednego urządzenia).

Można tego dokonać za pomocą poniższych poleceń. Usługa kolektora NetFlow znajduje się pod adresem IP 10.246.4.91 i nasłuchuje na porcie UDP o numerze 9995.

R2# configure terminal
R2(config)# ip flow-export source Loopback0
R2(config)# ip flow-export destination 10.246.4.91 9995
R2(config)# exit
R2# show ip flow export
Flow export v1 is enabled for main cache
  Export source and destination details : 
  VRF ID : Default
    Source(1)       10.246.255.2 (Loopback0)
    Destination(1)  10.246.4.91 (9995) 
  Version 1 flow records
  93 flows exported in 15 udp datagrams
  0 flows failed due to lack of export packet
  0 export packets were sent up to process level
  0 export packets were dropped due to no fib
  0 export packets were dropped due to adjacency issues
  0 export packets were dropped due to fragmentation failures
  0 export packets were dropped due to encapsulation fixup failures
R2#  

Istnieje możliwość zastosowania alternatywnego polecenia ip route-cache flow do uruchomienia usługi NetFlow. Usługa NetFlow jest uruchamiana wraz ze wskazaniem pierwszego interfejsu z którego mają być zbierane informacje o przepływach. Polecenie to zostało uznane za przestarzałe (ang. legacy command), niemniej warto je znać.

Użycie polecenia ip flow ingress (zbieranie danych na wejściu interfejsu) lub ip flow egress (zbieranie danych na wyjściu interfejsu), włącza zbieranie informacji tylko dla interfejsu/podinterfejsu w konfiguracji którego zostało wydane.

Natomiast polecenie ip route-cache flow włącza zbieranie informacji na wejściu dla interfejsu głównego i jego wszystkich podinterfejsów. Polecenie to dostępne jest tylko w konfiguracji interfejsu głównego (nie jest dostępne w konfiguracji podinterfejsu). Wynik użycia tego polecenia został zademonstrowany poniżej.

R2(config)# do show ip flow interface
R2(config)# interface GigabitEthernet0/1
R2(config-if)# ip route-cache flow
R2(config-if)# end
R2# show ip flow interface 
GigabitEthernet0/1
  ip route-cache flow
  ip flow ingress
GigabitEthernet0/1.104
  ip flow ingress
GigabitEthernet0/1.105
  ip flow ingress
R2#

Na załączonym niżej obrazku możemy zobaczyć jak wygląda pakiet przenoszący informacje o przepływach, który zostaje wysłany do kolektora. Standardowy nagłówek zawiera informacje na temat wersji (1), ilości przenoszonych przepływów i informacje czasowe. Dalej znajdują się już informacje o poszczególnych przepływach.



NetFlow v2 v3 v4
 
Wersje 2, 3 i 4 nie zostały nigdy wydane. Przynajmniej oficjalnie.

Eksport danych z użyciem NetFlow v5
 
Wersja 5 eksportuje dodatkowe informacje na temat BGP ASN, masce prefiksu IP i dodała numer sekwencyjny, który rośnie per każdy przenoszony przepływ. Jest nadal powszechnie stosowana. Dzięki dodaniu numeru sekwencyjnego, kolektor jest w stanie wykryć brakujące przepływy, które mogły do niego nie dotrzeć. Obsługuje tylko protokół IPv4 i eksport danych z Main Cache. W każdym pakiecie może przenosić do 30 przepływów. Format ten zakłada, że wszystkie informacje o przepływach są zbierane tylko na wejściu interfejsu.
 
Poniżej znajduje się lista informacji na temat każdego z przepływów, jaka wysyłana jest do kolektora:
  • interfejs wejściowy i wyjściowy (SNMP ifIndex),
  • pola Source i Destination Address w nagłówku protokołu IPv4,
  • pole DSCP (Differentiated Services Code Point), dawniej ToS (Type of Service) w nagłówku IPv4,
  • pole Protocol w nagłówku IPv4,
  • pola Source i Destination Port w nagłówku protokołu TCP/UDP,
  • zbiorcze (OR) flagi dla protokołu TCP,
  • adres IP urządzenia następnego przeskoku,
  • pola wskazujące Source i Destination BGP ASN ruchu (domyślnie ASN będący właścicielem prefiksu),
  • pola wskazujące Source i Destination Prefix Mask,
  • łączna ilość przesłanych pakietów,
  • łączna ilość przesłanych bajtów,
  • czas trwania (rozpoczęcie i zakończenie).

Pola klucze zostały oznaczone kolorem zielonym

Sposób uruchomienia wygląda jak poprzednio. Włączamy zbieranie informacji na wejściu interfejsów przez które będzie przechodził ruch, a następnie definiujemy adres kolektora, interfejs źródłowy i wersję eksportu danych NetFlow.

R2# configure terminal
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip flow ingress
R2(config)# interface GigabitEthernet0/1
R2(config-if)# ip flow ingress
R2(config-if)# exit
R2(config)# ip flow-export source Loopback0
R2(config)# ip flow-export version 5
R2(config)# ip flow-export destination 10.246.4.91 9995
R2(config)# exit
R2# show ip flow export
Flow export v5 is enabled for main cache
  Export source and destination details : 
  VRF ID : Default
    Source(1)       10.246.255.2 (Loopback0)
    Destination(1)  10.246.4.91 (9995) 
  Version 5 flow records
  270 flows exported in 45 udp datagrams
  0 flows failed due to lack of export packet
  0 export packets were sent up to process level
  0 export packets were dropped due to no fib
  0 export packets were dropped due to adjacency issues
  0 export packets were dropped due to fragmentation failures
  0 export packets were dropped due to encapsulation fixup failures
R2# show ip flow interface
GigabitEthernet0/0
  ip flow ingress
GigabitEthernet0/1
  ip flow ingress
R2#  

Na załączonym niżej obrazku możemy zobaczyć jak wygląda pakiet przenoszący informacje o przepływach, który zostaje wysłany do kolektora. Standardowy nagłówek zawiera informacje na temat wersji (5), ilości przenoszonych przepływów, informacje czasowe i numer sekwencyjny przepływów. Jest to numer początkowy, co oznacza że w kolejnym pakiecie powinien on urosnąć o ilość wysłanych przepływów w bieżącym pakiecie, która wynosi 4 (Count). Zatem kolejny pakiet powinien posiadać FlowSequence równe 824. Dalej widać poszczególne przepływy. 



Należy pamiętać, że wysyłanie danych o przepływach realizowane jest z użyciem protokołu UDP, czyli zawodnie. Wprowadzenie od wersji 5 numerów sekwencyjny, nie gwarantuje nam co prawda retransmisji tych informacji, ale daje możliwość wykrycia potencjalnych problemów. Ich przykładem mogą być problemy z pamięcią lub zbyt duże obciążenie urządzeń (kolektora, urządzeń po drodze lub urządzenia wysyłającego informacje o przepływach).

Domyślnie informacje o źródłowym i docelowym BGP ASN, wskazują ASN do którego należy prefiks (origin-as). Istnieje możliwość wymuszenia, by wskazywane były BGP ASN sąsiadów, od których ruch otrzymaliśmy i do których zostanie on przekazany (peer-as). Niemniej, nie ma możliwości zapisywania obydwóch informacji.

Jeśli będziemy chcieli informacje na temat BGP ASN sąsiadów, to tylko one będą znajdowały się w Main Cache/Aggregation Caches i będą wysyłane do kolektora. Służą do tego celu dwa polecenia ip flow-export version 5 peer-as i ip flow-export version 5 origin-as, które się wzajemnie wykluczają. Jedno, nadpisuje drugie.

Istnieje także możliwość dodania do Main Cache informacji na temat BGP Nexthop. Przy czym należy pamiętać, iż pole to nie jest obsługiwane przez NetFlow v5, stąd informacja ta nie będzie wysyłana do kolektora. Służy do tego celu polecenie ip flow-export version 5 bgp-nexthopip flow-export version 5 peer-as bgp-nexthop lub ip flow-export version 5 origin-as bgp-nexthop. Jeśli użyjemy samego polecenie ip flow-export version 5 bgp-nexthop i nie włączymy żadnego z Aggregation Caches, to informacje o BGP ASN i BGP Nexthop nie bedą zapisywane. 


Aby dane o BGP ASN były przechowywane w Main Cache (widoczne w ‘show ip cache verbose flow') oraz eksportowane do kolektora (od NetFlow v5), należy włączyć którykolwiek z Aggregation Caches (nie musi on gromadzić informacji o BGP ASN) lub użyć poleceń ip flow-export version 5 peer-as/ip flow-export version 5 origin-as z opcjonalnym parametrem bgp-nexthop lub bez niego. Użycie polecenia ip flow-export version 5 bgp-nexthop, bez wskazania origin-as/peer-as lub bez uruchomienia któregoś z Aggregation Caches, nie powoduje zapisywania informacji o BGP ASN. Dane te nie są przechowywane w Main Cache i co za tym idzie eksportowane do kolektora.

Zostało to sprawdzone na: Cisco ISR G2 3945E [15.2(4)M3, 15.4(3)M3] i Cisco ISR G1 3845 [12.4(24)T6]. Wygląda to na błąd w oprogramowaniu, ale może to po prostu ma tak działać. Oprócz tego, BGP ASN nie zostanie pokazany, jeśli ruch pochodzi z lub jest kierowany do lokalnego względem routera zbierającego informację AS.


Poniżej można zobaczyć ruch z AS 65008 do AS 65007. Ruch, wychodząc z AS 65008, przechodzi przez AS 65006, następnie AS 65234, do którego należy R4 i dopiero dociera do AS 65007. Zatem z punktu widzenia routera R4, który należy do AS 65234, origin-as są 65008 i 65007, a peer-as 65006 i 65007. Pierwszy to Src BGP ASN, a drugi Dst BGP ASN. Warto jeszcze raz przyglądnąć się wykorzystywanej przez nas topologii sieci, by lepiej zrozumieć różnicę w wyświetlanych informacjach. 

R4(config)# ip flow-export version 5 origin-as bgp-nexthop
R4(config)# do show ip cache verbose flow | begin SrcIf
SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts
Port Msk AS                    Port Msk AS    NextHop              B/Pk  Active
BGP: BGP NextHop    
Gi0/1          172.16.8.1      Gi0/0          172.16.7.2      06 00  12       1 
0016 /24 65008                 D4CA /24 65007 10.246.34.3            44     0.0
BGP: 10.246.255.2    
 
R4(config)# ip flow-export version 5 peer-as bgp-nexthop
R4(config)# do show ip cache verbose flow | begin SrcIf
SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts
Port Msk AS                    Port Msk AS    NextHop              B/Pk  Active
BGP: BGP NextHop      
Gi0/1          172.16.8.1      Gi0/0          172.16.7.2      06 00  12       1 
0016 /24 65006                 7EBF /24 65007 10.246.34.3            44     0.0
BGP: 10.246.255.2    

R4(config)#

NetFlow v6
 
Z informacji jakie udało mi się znaleźć, wersja 6 została opracowana na potrzeby jednego klienta i nie jest obecnie stosowana i wspierana przez Cisco Systems. Przenosi ona te same informacje na temat przepływów co wersja 5, ale format nagłówka i danych pakietu jest bardziej zbliżony do wersji 7. Różnicą w stosunku do wersji 7, są same 0 w miejscu gdzie powinna znajdować się informacja na temat 'shortcut router ip address', o którym będzie dalej. 

NetFlow v7
 
Wersja 7 obsługiwana jest tylko na już dość starych platformach Cisco Catalyst 5000 z NFFC (NetFlow Feature Card), routerach Cisco 7600 oraz Cisco Catalyst 6500 z supervisor PFC1 (Policy Feature Card) i MSFC (Multilayer Switch Feature Card), której zadaniem jest realizacja routingu.
 
Aby zrozumieć potrzebę zastosowania nowego formatu, przyjrzyjmy się architekturze Cisco Catalyst 6500 z SUP1, gdzie pierwszy pakiet tworzący przepływ jest przełączany przez MSFC, a kolejne by odciążyć MSFC, bezpośrednio przez PFC1. Problemem tej architektury, jest wysyłanie z różnych adresów IP (adres MSFC i PFC1) danych do kolektora związanych z tym samym przepływem.
 
Dzięki dodaniu pola 'shortcut router ip address', wskazującego na adres IP należący do MSFC, kolektor jest w stanie powiązać ze sobą te dane i utworzyć z nich jeden przepływ. Wersja 7 dostarcza podobnych samych informacji na temat przepływu co wersja 5 (podobna budowa i format), za wyjątkiem kilku pól, które mają zawsze wartość 0. Więcej na temat budowy i formatu eksportowanych danych NetFlow 7 można znaleźć tutaj.

Zapraszamy do kontaktu drogą mailową This email address is being protected from spambots. You need JavaScript enabled to view it. lub telefonicznie +48 797 004 932.