NetFlow v9, ingress/egress i UDP/SCTP
 

Do eksportu informacji NetFlow w wersji 9 wykorzystywane są szablony. Dzięki ich zastosowaniu, możliwe jest przesyłanie dowolnej grupy informacji z danych, jakie wspierane są przez urządzenie wysyłające i kolektor. Stąd, warto upewnić się czy kolektor nie tylko wspiera format eksportu danych NetFlow v9, ale także czy obsługuje wymagane przez nas dodatkowe pola i rozszerzenia.

O ile nie powinno być problemu z tradycyjnymi polami, jakie były obsługiwane w wersji 5, to warto sprawdzić każde inne. Wraz z wersją 9, pojawiła się możliwość definiowana dodatkowych pól, specyficznych dla producenta danego rozwiązania, które wysyła informacje o przepływach. W wyniku tego możemy natrafić na sytuację, że pomimo wsparcia naszego kolektora dla wersji 9, niektóre informacje nie będą gromadzone i prezentowane.


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


Dane, które dało się eksportować w wersji 5 i 8 można eksportować za pomocą wersji 9. Niemniej, ze względu na wykorzystanie szablonów, które umożliwiają dość elastyczne definiowanie rodzajów informacji zawartych w każdym z rekordów, wersja 9 posiada nieco większy narzut. Nieduży.


Biorąc pod uwagę chęć eksportu dokładnie tych samych informacji, które umożliwiała nam wersja 5, pojedynczy pakiet będzie mógł przenosić informacje na temat 24 przepływów. Dla przypomnienia, w wersji 5 mogło być ich być aż 30. Za to, dzięki możliwości okrojenia informacji jakie są nam potrzebne, ilość przepływów w pakiecie może przekraczać 30. Wrócimy do tego tematu przy omawianiu Flexible NetFlow. 


Wraz z wersją 9 zostało wprowadzone wsparcie dla zbierania informacji na wyjściu interfejsu. Co prawda, da się tak zebrane informacje eksportować z użyciem niższych wersji formatu eksportu danych. Niemniej, należy być wtedy szczególnie ostrożnym, gdyż eksportowane dane nie zawierają informacji na temat kierunku w jakim zostały zebrane.


Jeśli na niektórych interfejsach zbierać będziemy dane na wejściu, a na niektórych na wyjściu, to może poskutkować to duplikacja danych i niestety kolektor nie będzie w stanie tego wykryć. Stąd przyjmuje się, że zbieranie informacji na wyjściu interfejsu obsługiwane jest od wersji 9, a dla niższych wersji konfiguruje się zbieranie informacji na wejściu (zbieranie danych tylko na wyjściu wszystkich interfejsów, nie powinna sprawiać problemów w niższych wersjach).


W przypadku wersji 9 nie ma z tym problemu, gdyż istnieje tam możliwość eksportu informacji na temat kierunku w jakim zostały zebrane dane (domyślnie, konfiguracja przygotowana z użyciem TNF eksportuje taką informację). Oznacza to, że wraz z wersją 9, możemy zbierać dane na wejściu i wyjściu każdego z interfejsów jednocześnie lub to mieszając i kolektor będzie mógł sobie z tym poradzić.

Zbieranie informacji na wyjściu interfejsu najczęściej wykorzystywane jest przy:
  • kompresji ruchu, gdzie ilość danych na wyjściu interfejsu będzie mniejsza niż na interfejsie wejściowym,
  • ruchu multicast, gdyż zbierając dane na wejściu, nie ma informacji gdzie zostanie on zreplikowany,
  • chęci zachowania w rekordach odpowiednich adresów na urządzeniu realizującym NAT.
W rekordzie, który został zebrany na wyjściu interfejsu, polem kluczowym jest domyślnie interfejs wyjściowy. Jeśli chcemy to zmienić, należy posłużyć się poniższym poleceniem.
 
R4(config)# ip flow-egress input-interface

Użycie szablonów przyczyniło się do łatwego rozszerzenia zbieranych informacji o dane IPv6 i MPLS (Multiprotocol Laber Switching) oraz informacje z L2, jak numer VLAN i adres MAC. Stała się również możliwa analiza ruchu multicast względem jego replikacji oraz możliwość zbierania takich danych, jak różnica w opóźnieniu pomiędzy pakietami (ang. jitter), ilość zgubionych pakietów (ang. packet loss) czy czas podróży pakietu (ang. round trip time). Dane te mogą być kluczowe dla ruchu VoIP i wideo. W przypadku, kiedy urządzenie zbierające dane obsługuje DPI (Deep Packet Inspection), możliwe jest nawet zbieranie informacji na temat wykorzystywanych w sieci aplikacji/protokołów (np. NBAR firmy Cisco Systems).

Do dalszej analizy uruchomimy zbieranie informacji na wejściu i na wyjściu, każdego z interfejsów.

R4(config)# interface GigabitEthernet 0/0
R4(config-if)# ip flow ingress 
R4(config-if)# ip flow egress 
R4(config-if)# interface GigabitEthernet 0/1
R4(config-if)# ip flow ingress 
R4(config-if)# ip flow egress 
R4(config-if)# interface GigabitEthernet 0/2   
R4(config-if)# ip flow ingress 
R4(config-if)# ip flow egress 
R4(config-if)#

Następnie włączymy eksport NetFlow w wersji 9. Dopóki nie wskażemy miejsca docelowego, nie będzie on aktywny.

R4(config)# ip flow-export version 9
R4(config)# ip flow-export source Loopback0
R4(config)# do show ip flow export template
   Template Options Flag = 0
   Total number of Templates added = 0
   Total active Templates = 0
   Flow Templates active = 0
   Flow Templates added = 0
   Option Templates active = 0
   Option  Templates added = 0
   Template ager polls = 0
   Option Template ager polls = 0
Main cache version 9 export is disabled
 Template export information
   Template timeout = 30
   Template refresh rate = 20
 Option export information
   Option timeout = 30
   Option refresh rate = 20
R4(config)# ip flow-export destination 172.16.1.123 9995
R4(config)# do show ip flow export template                  
   Template Options Flag = 0
   Total number of Templates added = 0
   Total active Templates = 0
   Flow Templates active = 0
   Flow Templates added = 0
   Option Templates active = 0
   Option  Templates added = 0
   Template ager polls = 0
   Option Template ager polls = 0
Main cache version 9 export is enabled
 Template export information
   Template timeout = 30
   Template refresh rate = 20
 Option export information
   Option timeout = 30
   Option refresh rate = 20
R4(config)#

W NetFlow v9 mamy szablony opisujące opcje i szablony opisujące dane. W związku z możliwością zagubienia datagramu UDP, są one domyślnie wysyłane co 20 pakietów lub co 30 minut. Wartości te można modyfikować dla każdego z rodzaju szablonów niezależnie. W naszym przykładzie, skrócimy je o połowę.

R4(config)# ip flow-export template timeout-rate 15
R4(config)# ip flow-export template refresh-rate 10
R4(config)# ip flow-export template options timeout-rate 15
R4(config)# ip flow-export template options refresh-rate 10
R4(config)# do show ip flow export template                     
   Template Options Flag = 0
   Total number of Templates added = 1
   Total active Templates = 1
   Flow Templates active = 1
   Flow Templates added = 1
   Option Templates active = 0
   Option  Templates added = 0
   Template ager polls = 63
   Option Template ager polls = 0
Main cache version 9 export is enabled
 Template export information
   Template timeout = 15
   Template refresh rate = 10
 Option export information
   Option timeout = 15
   Option refresh rate = 10
R4(config)#

Dodatkowo można włączyć eksportu informacji na temat dodatkowych opcji. Opcja szablonu 'export-stats' sprawi, że do kolektora będą wysyłane informacje na temat wysłanej do niego ilości pakietów i przepływów. Włączymy też zbierania informacji na temat bgp-nexthop i BGP ASN. Poniżej widać, iż z każdą zmianą informacji jakie mają być eksportowane, ulegają zmianie informacje na temat eksportowanych szablonów.

R4(config)# ip flow-export template options export-stats 
R4(config)# do show ip flow export template              
   Template Options Flag = 1
   Total number of Templates added = 2
   Total active Templates = 2
   Flow Templates active = 1
   Flow Templates added = 1
   Option Templates active = 1
   Option  Templates added = 1
   Template ager polls = 88
   Option Template ager polls = 2
Main cache version 9 export is enabled
 Template export information
   Template timeout = 15
   Template refresh rate = 10
 Option export information
   Option timeout = 15
   Option refresh rate = 10
R4(config)# ip flow-export version 9 origin-as bgp-nexthop 
R4(config)# do show ip flow export template                
   Template Options Flag = 1
   Total number of Templates added = 3
   Total active Templates = 3
   Flow Templates active = 2
   Flow Templates added = 2
   Option Templates active = 1
   Option  Templates added = 1
   Template ager polls = 120
   Option Template ager polls = 33
Main cache version 9 export is enabled
 Template export information
   Template timeout = 15
   Template refresh rate = 10
 Option export information
   Option timeout = 15
   Option refresh rate = 10
R4(config)#

Informacje zbierane na urządzeniu wyglądają tak samo, jak poprzednio. Wynika to z tego, że zbierane informacje, a wersja eksportowanych danych, to dwie różne rzeczy.

W pierwszej części możemy zobaczyć statystykę wielkości pakietów. Zawiera ona w sobie wielkość całego pakietu IP. Wynika z niej, że 55,1% pakietów miało wielkość od 33 do 64 bajtów, a 38,2% wielkość od 65 do 96. Trochę niżej, można zobaczyć informacje statystyczne o wykrytych w sieci protokołach.

R4# show ip cache verbose flow 
IP packet size distribution (2546 total packets):
   1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480
   .000 .551 .382 .047 .004 .001 .000 .000 .001 .000 .000 .000 .002 .000 .000
 
    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .001 .000 .005 .000 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes

  8 active, 4088 inactive, 354 added
  7224 ager polls, 0 flow alloc failures
  Active flows timeout in 30 minutes
  Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 34056 bytes
  6 active, 1018 inactive, 12 added, 12 added to flow
  0 alloc failures, 0 force free
  1 chunk, 1 chunk added
  last clearing of statistics never
Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
--------         Flows     /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow
TCP-BGP             82      0.0         1    63      0.1       2.9      15.5
TCP-other          134      0.1         7    72      0.8       1.5      11.1
UDP-NTP             75      0.0         1    76      0.0       0.0      15.6
ICMP                13      0.0        46    85      0.5      41.5      15.5
Total:             304      0.2         5    76      1.5       3.2      13.6

SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts

Port Msk AS                    Port Msk AS    NextHop              B/Pk  Active
BGP: BGP NextHop
Gi0/0          10.246.34.3     Null           224.0.0.2       11 C0  10     262 
0286 /0  0                     0286 /0  0     0.0.0.0                62  1126.4

Gi0/0          172.16.1.123    Local          10.246.255.4    06 10  18     417 
FA60 /0  0                     0016 /0  0     0.0.0.0                45    49.9

Gi0/0          172.16.7.2      Gi0/2*         172.16.6.0      01 00  10       5 
0000 /24 65007                 0800 /32 65006 172.16.46.6           100     0.0
BGP: 172.16.46.6     
FFlags: 01  

Gi0/0          172.16.7.2      Gi0/2          172.16.6.0      01 00  10       5 
0000 /24 65007                 0800 /32 65006 172.16.46.6           100     0.0
BGP: 172.16.46.6     

Gi0/2          172.16.46.6     Local          172.16.46.4     06 C0  18       2 
00B3 /24 0                     FC1D /0  0     0.0.0.0                49    13.7
BGP: 0.0.0.0         

Gi0/0          172.16.1.123    Local          172.16.4.0      01 00  10       1 
0000 /24 0                     0303 /32 0     0.0.0.0                56     0.0
BGP: 0.0.0.0         

Gi0/0          10.246.255.2    Local          10.246.255.4    06 C0  18       2 
00B3 /32 0                     68F0 /32 0     0.0.0.0                49    10.2
BGP: 0.0.0.0         

Gi0/2          172.16.6.0      Gi0/0          172.16.7.2      01 00  10       5 
0000 /32 65006                 0000 /24 65007 10.246.34.3           100     0.0
BGP: 10.246.255.2    

R4#

Zanim zaczniemy interpretować informacje o przepływie, warto zwrócić uwagę na "*", jaka pojawia się przy niektórych rekordach w polu interfejsu docelowego (DstIf). Wskazuje ona, że informacje te zostały zebrane na wyjściu (ang. egress) oznaczonego gwiazdką interfejsu.

Widać też pole FFlags (Flow Flags), którego wartość tworzy sumę OR jednej lub większej ilości flag przepływu. 01 oznacza przepływ wyjściowy, 02 przepływ, który został odrzucony (na przykład, na skutek działania listy ACL), 04 ruch MPLS, a 08 ruch IPv6. Zatem, dla przykładu wartość 05 (01 OR 04) będzie oznaczała ruch wyjściowy MPLS. 

Pomimo tego, że uruchomiliśmy zbieranie informacji o przepływach na wejściu i wyjściu interfejsu Gi0/0, to widać, że informacje zbierane są tylko na jego wejściu. Wynika to z tego, że na interfejsie tym został skonfigurowany MPLS. Zatem z punktu widzenia interfejsu, nie ma na nim wyjściowego ruchu IP. Aby ruch ten dało się zbierać, wymagana jest dodatkowa konfiguracja MPLS-aware NetFlow, o czym będzie więcej w kolejnym artykule.


Do tej pory, nie interpretowaliśmy wszystkich informacji, jakie można odczytać z rekordu przepływu. Są one zestawione w legendzie, która wyświetlana jest na samym początku.

SrcIf          SrcIPaddress    DstIf          DstIPaddress    Pr TOS Flgs  Pkts
Port Msk AS                    Port Msk AS    NextHop              B/Pk  Active
BGP: BGP NextHop

SrcIf i DstIf, są skrótami od odpowiednio Source Interface i Destination Interface. Poniżej nich są informacje, odnoszą się do odpowiednio części źródłowej i docelowej wartości pól:

  • Port - zwykle numer portu TCP/UDP (wartość hexadecymalna),
  • Msk - wielkość prefiksu/długość maski (wartość dziesiętna)
  • AS - BGP ASN (wartość dziesiętna).

Kolumny SrcIPaddress i DstIPaddress oznaczają odpowiednio źródłowy i docelowy adres IP. Dalej znajduje się kolumna Pr, która oznacza numer protokołu z nagłówka IP (wartość hexadecymalna). Dla przykładu, Pr równe 0x01 oznacza ICMP, 0x06 TCP, a 0x11 - dziesiętnie 17 - oznacza UDP. Dalej, kolejno mamy wartość bajtów TOS (wartość hexadecymalna) i zbiorcze (OR) flag TCP - Flgs (wartość hexadecymalna). Poniżej flag znajduje się średnia ilość bajtów na pakiet - B/Pk. Ostatnia kolumna zawiera informacje na temat ilości pakietów (Pkts) składających się na aktualny wpis. Zaraz poniżej, w miejscu Active znajduje się czasu aktywności przepływu w sekundach, w momencie wylistowania go. Należy pamiętać, że kiedy informacja zostanie wyeksportowana, na skutek minięcia licznika active, to czas dla nowych pakietów składających się na nowy rekord przepływu liczony jest od zera. Na końcu, u samego dołu znajduje się informacja na temat adresu IP następnego przeskoku według BGP (BGP: BGP NextHop) - 0.0.0.0, jeśli w tablicy routingu nie ma wpisu BGP dla docelowego adresu IP. Została jeszcze wartość NextHop, która wskazuje adres IP urządzenia następnego przeskoku, na drodze do docelowego adresu IP.


Przeanalizujemy poniższe informacje na temat przepływu z adresu 172.16.1.123 do adresu 10.246.255.4. 

Gi0/0          172.16.1.123    Local          10.246.255.4    06 10  18     227 
EB46 /24 0                     0016 /32 0     0.0.0.0                64    35.1
BGP: 0.0.0.0      

Interfejsem wejściowym jest Gi0/0, a wyjściowy interfejs Local. Oznacza to, że ruch kierowany jest do urządzenia, które zbiera informacje o przepływach (stąd też pola NextHop i BGP NextHop mają wartość 0.0.0.0). Adres 10.246.255.4, jest adresem Loopback interfejsu routera R4, z którego pochodzi informacja o tym przepływie. Pr wartości 0x06 w miejscu Pr (TCP) i 0x0016 w miejscu Dst Port, możemy zorientować się, że jest to sesja SSH (0x16 to 22 dziesiętnie), nawiązana z portu źródłowego 59872 (0xE9E0). W tablicy routing R4, dla adresów IP 172.16.1.123 i 10.246.255.4 znajduje się długość prefiksu odpowiednio /24 i /32.

R4# show ip route 172.16.1.123
Routing entry for 172.16.1.0/24
  Known via "bgp 65234", distance 200, metric 5176320, type internal
  Last update from 10.246.255.2 00:48:03 ago
  Routing Descriptor Blocks:
  * 10.246.255.2, from 10.246.255.2, 00:48:03 ago
      Route metric is 5176320, traffic share count is 1
      AS Hops 0
      MPLS label: none
R4# show ip route 10.246.255.4
Routing entry for 10.246.255.4/32
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via bgp 65234
  Routing Descriptor Blocks:
  * directly connected, via Loopback255
      Route metric is 0, traffic share count is 1
R4#

Wartość TOS wynosi 0x10, co bitowo daje wartość 0001 0000. Wartość ta, nie pasuje do żadnej z klas DSCP (CS, AF, EF), ale oznacza Low Delay w przypadku interpretacji TOS (D = 1). Poniżej budowa tego pola w interpretacji TOS. 

         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |   PRECEDENCE    |  D  |  T  |  R  |  0  |  0  |
      +-----+-----+-----+-----+-----+-----+-----+-----+ 

Zbiorcze flagi TCP (OR), czyli wszystkie widziane w tym przepływie, mają wartość 0x18 (0001 1000), co wskazuje na obecność flag PSH i ACK. Za pewne, flaga SYN pojawiała się w tym połączeniu jeszcze przed skonfigurowanie usługi NetFlow (w trakcie nawiązywania połączenia SSH do R4). Poniżej widać fragment nagłówka TCP z flagami. 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data | | | |N|C|E|U|A|P|R|S|F|                               |
   | Offset| | | |S|W|C|R|C|S|S|Y|I|            Window             |
   |       | | | | |R|E|G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Na przepływ ten składa się 227 pakietów, gdzie średnia ilość bajtów na pakiet to 64. Jest on aktywny od 35.1 sekundy.

Tak wyglądają informacje na temat skonfigurowanego kolektora i wysyłanych do niego informacji:

R4# show ip flow export 
Flow export v9 is enabled for main cache
  Export source and destination details : 
  VRF ID : Default
    Source(1)       172.16.4.0 (Loopback0)
    Destination(1)  172.16.1.123 (9995) 
  Version 9 flow records, origin-as bgp-nexthop
  327 flows exported in 51 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
R4#

Pomimo tego, że uruchomiliśmy zbieranie informacji o przepływach na wejściu i wyjściu interfejsu Gi0/0, to widać, że informacje zbierane są tylko na jego wejściu. Wynika to z tego, że na interfejsie tym został skonfigurowany MPLS. Zatem z punktu widzenia interfejsu, nie ma na nim wyjściowego ruchu IP. Aby ruch ten dało się zbierać, wymagana jest dodatkowa konfiguracja MPLS-aware NetFlow, o czym będzie więcej w kolejnym artykule.


BGP Nexthop ToS Aggregation Cache

 
Istnieje 12 predefiniowanych Aggregation Caches, ale tylko 11 z nich obsługuje eksport danych w wersji 8. Natomiast wszystkie 12 obsługuje export danych w wersji 9. Przyjrzyjmy się niżej nieomówionemu do tej pory Aggregation Cache w oparciu o pole BGP NextHop i bajt ToS. Jako jedyny z Aggregation Caches, obsługuje on eksport tylko w wersji 9. Powodem tego jest pole BGP Next-Hop, które nie było zdefiniowane w wersji 5 i 8.
 
R4# show ip cache flow aggregation ?
as AS aggregation cache
as-tos AS TOS aggregation cache
bgp-nexthop-tos BGP nexthop TOS aggregation cache
destination-prefix Destination Prefix aggregation cache
destination-prefix-tos Destination Prefix TOS aggregation cache
prefix Source/Destination Prefix aggregation cache
prefix-port Source/Destination Prefix port aggregation cache
prefix-tos Source/Destination Prefix TOS aggregation cache
protocol-port Protocol and port aggregation cache
protocol-port-tos Protocol, port, TOS aggregation cache
source-prefix Source Prefix aggregation cache
source-prefix-tos Source Prefix TOS aggregation cache

R4#

Sposób konfiguracji agregacji z wykorzystaniem BGP Nexthop oraz pola ToS (wartość DSCP):

R4(config)# ip flow-aggregation cache bgp-nexthop-tos 
R4(config-flow-cache)# ?
Flow Aggregation Cache configuration commands:
  cache    Configure netflow cache parameters
  default  Set a command to its defaults
  enabled  Enable the aggreation cache
  exit     Exit from flow aggregation cache configuration mode
  export   Specify host/port to send flow statistics
  help     Description of the interactive help system
  no       Negate a command or set its defaults
R4(config-flow-cache)# export version ?
  9  Version 9 export format
R4(config-flow-cache)# export template options export-stats 
R4(config-flow-cache)# export template options refresh-rate 10
R4(config-flow-cache)# export template options timeout-rate 15
R4(config-flow-cache)# export template refresh-rate 10        
R4(config-flow-cache)# export template timeout-rate 15 
R4(config-flow-cache)# enabled
R4(config-flow-cache)# exit
R4(config)#
R4# show ip cache verbose flow aggregation bgp-nexthop-tos 
IP Flow Switching Cache, 278544 bytes
  7 active, 4089 inactive, 362 added
  6649 ager polls, 0 flow alloc failures
  Active flows timeout in 30 minutes
  Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 34056 bytes
  7 active, 1017 inactive, 362 added, 362 added to flow
  0 alloc failures, 0 force free
  1 chunk, 1 chunk added
Src If         Src AS  Dst If         Dst AS  TOS Flows   Pkts  B/Pk  Active
BGP NextHop     
Gi0/0           0      Null            0      C0     3      5     54    12.3
BGP: 0.0.0.0           
Gi0/2           65006  Gi0/0           0      00     1      1     44     0.0
BGP: 10.246.255.2      
Gi0/2           65006  Gi0/0           0      C0     1     27    131     5.6
BGP: 10.246.255.2      
Gi0/0           0      Gi0/2           65006  10     1      4    155     0.0
BGP: 172.16.46.6       
Gi0/0           0      Gi0/2           65006  10     1      4    155     0.0
BGP: 172.16.46.6       FFlags: 01
Gi0/0           0      Gi0/2           65006  00     1     27    163     5.6
BGP: 172.16.46.6       
Gi0/0           0      Gi0/2           65006  00     1     27    163     5.6
BGP: 172.16.46.6       FFlags: 01
R4#

Widać, że sposób konfiguracji jest analogiczny jak dla wszystkich Aggregation Caches, za wyjątkiem dodatkowej możliwości konfigurowania parametrów szablonów, opcji szablonów i opcji.

Różnica jest w tym, że domyślną i jedyną wersją eksportu danych, jest wersja 9. Poniżej widać też konfigurację kolejnego Aggregation Caches, który obsługuje eksport w wersji 8 i 9. 

R4(config)# ip flow-aggregation cache destination-prefix
R4(config-flow-cache)# export version ?
  8  Version 8 export format
  9  Version 9 export format
R4(config-flow-cache)# export version 9
R4(config-flow-cache)# enabled
R4(config-flow-cache)# exit
R4(config)#

Domyślnie eksport danych w wersji 9 odbywa się przy użyciu protokołu UDP. Był to jedyny dostępny sposób transportu we wcześniejszych wersjach eksportu danych NetFlow. Od wersji 9, możliwe jest wykorzystanie do tego celu protokołu SCTP (Stream Control Transmission Protocol).


SCTP (Stream Control Transmission Protocol)

 
Eksport danych z wykorzystaniem UDP nie zapewnia niezawodności transmisji i adaptacji do przeciążeń w sieci i komunikujących się urządzeń. Od wersji 5 został wprowadzony numer sekwencyjny. Dzięki niemu, kolektor jest świadomy faktu, iż nie wszystkie informacje do nie dotarły. Niemniej, ze względu na prosty i jednostronny model wysyłania informacji ("push"  - są one wypychane w stronę kolektora, bez względu na to czy w ogóle jest on dostępny), nie ma on żadnej możliwości powiadomienia o swoim przeciążeniu lub zagubieniu jakiś danych.
 
SCTP rozwiązuje wyżej wspomniane problemy. Zawiera w sobie mechanizm kontroli przeciążenia, dzięki czemu urządzenie wysyłające może być pewne, że nie robi tego szybciej, niż kolektor jest w stanie odebrać lub przesyłać sieć. Stosowane są do tego celu specjalne okna przeciążenia/odbiorcze i algorytm powolnego startu oraz reakcji na zagupienie pakietu. Wysyłane dane mogą być buforowane do czasu potwierdzenia ich odebrania przez kolektor. W przypadku braku otrzymania potwierdzenia, mogą one zostać wysłane ponownie. Obsługiwane są również selektywne potwierdzenia, które dokładnie wskazują porcje danych, jakich nie otrzymaliśmy.
 
W zależności od naszych potrzeb, SCTP umożliwia trzy tryby pracy: niezawodny, częściowo niezawodny i zawodny. Tryb zawodny podobny jest do transmisji UDP. Stosowany jest zwykle wtedy, gdy nie chcemy zużywać zasobów urządzenia wysyłającego do buforowania niepotwierdzonych pakietów. Tryb niezawodny przypomina transmisję TCP, gdzie wszystkie dane są buforowane i wymagają potwierdzenie przed zwolnieniem miejsca w buforze. Tryb cześciowo niezawodny umożliwia zdefiniowanie limitu bufora, w którym są przechowywane niepotwierdzone dane. Zabezpiecza to urządzenie wysyłające przed wyczerpaniem pamięci. Kiedy w takim buforze skończy się miejsce, to przed umieszczeniem kolejnego pakietu, usuwany jest z niego najstarszy niepotwierdzony, a do kolektora wysyłana jest informacja o numerze sekwencyjnym pakietu, który nie został dostarczony.
 
W jednym połączeniu SCTP może być przetwarzanych wiele niezależnych strumieni (TCP obsługuje jeden strumień ruchu na połączenie). W jednym połączeniu SCTP utrzymywany jest jeden strumień na potrzeby transmisji informacji o szablonach, szablonach opcji i danych opcji (nr 0) oraz jeden lub więcej na potrzeby transmisji danych o przepływach (np. jeden dla Main Cache i po jednym dla każdego skonfigurowanego Aggregation Caches). Co więcej, każdy ze strumieni w jednym połączeniu do tego samego kolektora, na ten sam numer portu może obsługiwać inny tryb pracy (zawodny, niezawodny, częściowo niezawodny).

Polecenia związane z konfiguracją parametrów odświeżania informacji o szablonach i szablonach opcji, nie mają odniesienia do STCP. Dotyczą one tylko protokołu UDP, gdzie była potrzeba ich okresowego wysyłania ze względu na niepewność transmisji. Poniżej zamieściłem te polecenia jeszcze raz (dla Main Cache i Aggregation Caches).
 
R4(config)# ip flow-export template timeout-rate 30
R4(config)# ip flow-export template refresh-rate 20
R4(config)# ip flow-export template options timeout-rate 30
R4(config)# ip flow-export template options refresh-rate 20
R4(config-flow-cache)# export template options refresh-rate 20
R4(config-flow-cache)# export template options timeout-rate 30
R4(config-flow-cache)# export template refresh-rate 20
R4(config-flow-cache)# export template timeout-rate 30 

Oprócz tego, SCTP posiada mechanizm wiadomości hearbeat, dzięki któremu może monitorować dostępność drugiej strony i w razie potrzeby przełączyć transmisję na inny adres IP. O samym protokole SCTP można by napisać więcej niż jeden artykuł. To tylko ogólny zarys, jako że nie każdy mógł o nim słyszeć. Ma on wiele plusów w odniesieniu do TCP oraz UDP, nie pomijając bezpieczeństwa/multihomingu. Zapewne nie używamy go powszechnie ze względu na to, że TCP/UDP przyszło na świat wcześniej. Podobny problem jak z IPv6 i IPv4. Może kiedyś doczekamy się Internet2 opartego w pełni o IPv6 i SCTP.


Protokół SCTP nie jest obsługiwany przez darmowe kolektory NetFlow, ale obsługuje go Cisco Stealthwatch.


Poniżej pokazany został sposób konfiguracji SCTP dla Main Cache i jednego wybranego Aggregation Cache.

Eksport z Main Cache ustawiony został w trybie 'redundant', co oznacza, że od razu zostanie aktywowane połączenie z zapasowym kolektorem i wysłane zostaną do niego informacje na temat szablonów i szablonów opcji. Przy czym, dane o przepływach będą wysyłane tylko do kolektora podstawowego. Dopiero, kiedy kolektor podstawowy nie potwierdzi otrzymania wiadomości heartbeat w czasie określony przez 'backup fail-over', który poniżej ustawiliśmy na 50 msec, nastąpi przełączenie przesyłania danych do kolektora zapasowego.

Eksport z wybranego Aggregation Cache został uruchomiony w trybie fail-over, co oznacza, że połączenie do zapasowego kolektora zostanie aktywowane dopiero, kiedy nie otrzymamy potwierdzenia wiadomości hearbeat od kolektora podstawowego w czasie określony poleceniem 'backup fail-over' (domyślnie 25 msec). Przełączenie na zapasowy kolektor następuje również w przypadku, kiedy podstawowy nie potwierdzi odebrania wiadomości, która została wysłana trzykrotnie.

W trakcie korzystania z kolektora zapasowego, SCTP cały czas będzie próbował ustanowić ponownie połączenie z kolektorem podstawowym. Kiedy już się on pojawi, to przełączenie nastąpi po czasie skonfigurowanym poleceniem 'backup restore-time', którego domyślna wartość wynosi 25 sekund. W przypadku wykorzystania trybu fail-over, należy liczyć się z możliwością utraty informacji na temat przepływów, jakie zostały zakolejkowane do wysłania w trakcie przełączenia na kolektor zapasowy. By uniknąć tzw. flapowania (ang. flapping) - pojawiania się i znikania podstawowego kolektora, należy pamiętać, by czas określony poleceniem 'backup restore-time' był większy od typowego czasu konwergencji sieci po zmianie/awarii.

R4(config)# ip flow-export destination 172.16.1.123 9000 sctp 
R4(config-flow-export-sctp)# ?
SCTP export configuration commands:
  backup       Specify the SCTP backup parameters
  default      Set a command to its defaults
  exit         Exit from SCTP configuration mode
  no           Negate a command or set its defaults
  reliability  Specify the SCTP reliability
R4(config-flow-export-sctp)# reliability ?
  full     Export data with full reliability
  none     Export data unreliably
  partial  Export data with partial reliability
R4(config-flow-export-sctp)# reliability partial buffer-limit ?
  <1-65535>  Buffer limit in number of flow records
R4(config-flow-export-sctp)# reliability partial buffer-limit 128 
R4(config-flow-export-sctp)# backup ?
  destination   Specify the SCTP backup destination
  fail-over     Specify the fail-over time
  mode          Specify the backup mode
  restore-time  Specify the restore time
R4(config-flow-export-sctp)# backup destination 172.16.7.91 9000 
R4(config-flow-export-sctp)# backup mode redundant 
R4(config-flow-export-sctp)# backup restore-time ?
  <0-3600>  restore time in seconds
R4(config-flow-export-sctp)# backup restore-time 5
R4(config-flow-export-sctp)# backup fail-over ?
  <0-3600>  Fail-over time (mS)
R4(config-flow-export-sctp)# backup fail-over 50
R4(config-flow-export-sctp)# exit
R4(config)# ip flow-aggregation cache bgp-nexthop-tos 
R4(config-flow-cache)# export destination 172.16.1.123 9000 sctp
R4(config-flow-export-sctp)# backup destination 172.16.7.91 9000
R4(config-flow-export-sctp)# backup mode fail-over 
R4(config-flow-export-sctp)# exit
R4(config-flow-cache)# enabled 

Poniższym poleceniem możemy sprawdzić sposób konfiguracji i stan ustawionych kolektorów, razem ze statystykami eksportowanych informacji. Wszędzie widać stan 'initialising', 're-establishing' lub 'fail-over', jako że w naszej sieci nie ma działającego kolektora. Gdyby kolektory były aktywny, to powinniśmy widzieć dwa razy stan 'connected' przy trybie 'redundant' i 'connected' oraz 'not connected' przy trybie 'fail-over'.

R4# show ip flow export sctp verbose
IPv4 main cache exporting to 172.16.1.123, port 9000, partial
status: re-establishing
backup mode: redundant
0 flows exported in 0 sctp messages.
0 packets dropped due to lack of SCTP resources
fail-over time: 50 milli-seconds
restore time:   5 seconds
backup: 172.16.7.91, port 9000
   status: initialising
   fail-overs: 0
   0 flows exported in 0 sctp messages.
   0 packets dropped due to lack of SCTP resources 
43 packets dropped due to primary & backup failure.
bgp-nexthop-tos cache exporting to 172.16.1.123, port 9000, full
status: fail-over
backup mode: fail-over
0 flows exported in 0 sctp messages.
0 packets dropped due to lack of SCTP resources
fail-over time: 25 milli-seconds
restore time:   25 seconds
backup: 172.16.7.91, port 9000
   status: initialising
   fail-overs: 59
   0 flows exported in 0 sctp messages.
   0 packets dropped due to lack of SCTP resources 
15 packets dropped due to primary & backup failure.
R4#

Przedstawiony tu zarys eksportu danych NetFlow w wersji 9. Widać wiele plusów w odniesieniu do poprzednich wersji. Niemniej, nie da się wszystkiego na temat NetFlow v9 zmieścić w jednym artykule, stąd zapraszam do kolejnych. 


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.