MikroTik - Fluxo de tráfego (Netflow) Octets Counter wrap

Question

Estou usando Traffic Flow com pmacct (nfacct) para fazer a contabilidade IP.

Tenho notado que, se um fluxo exceder ~ 4GBytes em menos de um minuto (que é meu active-flow-timeout ), o fluxo de% exportadoOctets contará a perda de uma quantidade significativa do total de dados medidos.

Acredito que este é um problema com o contador de octetos sendo 32 bits não assinados e se o tráfego estiver acima do limite ( 4294967296 ), o exportador não enviará o fluxo para o coletor (não sei como outros fornecedores lidam com isso).

Isso é muito sério, pois resulta em totais de tráfego muito errados!

Aqui está minha configuração de fluxo de tráfego:

/ip traffic-flow
set active-flow-timeout=1m cache-entries=1k enabled=yes interfaces=sfp1
/ip traffic-flow target
add dst-address=X.X.X.X v9-template-refresh=60 v9-template-timeout=1m

E aqui estão algumas capturas de fluxo do wireshark.

Flow 3
    [Duration: 59.590000000 seconds (switched)]
    Packets: 5700194
    Octets: 4255323704
    InputInt: 16
    OutputInt: 0
    SrcAddr: 31.X.X.254
    DstAddr: 185.X.X.254
    Protocol: UDP (17)
    IP ToS: 0x00
    SrcPort: 2043 (2043)
    DstPort: 2299 (2299)
    NextHop: 185.X.X.X
    DstMask: 0
    SrcMask: 0
    TCP Flags: 0x00
    Destination Mac Address: Routerbo_XX:XX:XX (d4:ca:6d:XX:XX:XX)
    Post Source Mac Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Post NAT Source IPv4 Address: 31.X.X.254
    Post NAT Destination IPv4 Address: 185.X.X.254
    Post NAPT Source Transport Port: 0
    Post NAPT Destination Transport Port: 0

Segunda captura:

Flow 3
    [Duration: 59.590000000 seconds (switched)]
    Packets: 5532208
    Octets: 4003344704
    InputInt: 16
    OutputInt: 0
    SrcAddr: 31.X.X.254
    DstAddr: 185.X.X.254
    Protocol: UDP (17)
    IP ToS: 0x00
    SrcPort: 2043 (2043)
    DstPort: 2299 (2299)
    NextHop: 185.X.X.X
    DstMask: 0
    SrcMask: 0
    TCP Flags: 0x00
    Destination Mac Address: Routerbo_XX:XX:XX (d4:ca:6d:XX:XX:XX)
    Post Source Mac Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Post NAT Source IPv4 Address: 31.X.X.254
    Post NAT Destination IPv4 Address: 185.X.X.254
    Post NAPT Source Transport Port: 0
    Post NAPT Destination Transport Port: 0

Na época dessas capturas, um teste de largura de banda (UDP, 1500bytes, 1Gbit, receive) estava em execução há algum tempo. Então, rodando a 1gbit por 60segundos ( active-flow-timeout ) ele deveria ter medido pelo menos ~ 7864320000 Octets (~ 7.3GB)

Se eu reduzir o teste de largura de banda para 460mbit, os fluxos exportados parecem relatar o tráfego corretamente, já que o contador de Octetos não excede o máximo sem sinal de 32 bits. Embora eu veja bastante sobrecarga e eu me pergunto por que isso acontece. Em 460mbit de tráfego sustentado, em 60 segundos ele deve medir ~ 3617587200 octets (= 3.36GB). Mas, em vez disso, mediu 4269160500 (= 3,9 GB) Eu não tenho certeza de onde o extra ~ 600MB veio.

Flow 6
    [Duration: 59.590000000 seconds (switched)]
    Packets: 2846107
    Octets: 4269160500
    InputInt: 16
    OutputInt: 0
    SrcAddr: 31.X.X.254
    DstAddr: 185.X.X.254
    Protocol: UDP (17)
    IP ToS: 0x00
    SrcPort: 2058 (2058)
    DstPort: 2314 (2314)
    NextHop: 185.X.X.X
    DstMask: 0
    SrcMask: 0
    TCP Flags: 0x00
    Destination Mac Address: Routerbo_0d:95:72 (d4:ca:6d:XX:XX:XX)
    Post Source Mac Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Post NAT Source IPv4 Address: 31.X.X.254
    Post NAT Destination IPv4 Address: 185.X.X.254
    Post NAPT Source Transport Port: 0
    Post NAPT Destination Transport Port: 0

Mas se eu aumentar o teste de largura de banda para 480mbit por exemplo, então o fluxo exportado tem seu contador em volta perdendo uma quantidade significativa de dados (por exemplo: ~ 4GBytes de dados)

Flow 3
    [Duration: 59.590000000 seconds (switched)]
    Packets: 2865308
    Octets: 2994704 <-- Only 2.8MB?! Even with 64byte packets,
                    based on the measured packets above, 
                    it should have measured > 174MBytes of data!
    InputInt: 16
    OutputInt: 0
    SrcAddr: 31.X.X.254
    DstAddr: 185.X.X.254
    Protocol: UDP (17)
    IP ToS: 0x00
    SrcPort: 2055 (2055)
    DstPort: 2311 (2311)
    NextHop: 185.X.X.X
    DstMask: 0
    SrcMask: 0
    TCP Flags: 0x00
    Destination Mac Address: Routerbo_0d:95:72 (d4:ca:6d:XX:XX:XX)
    Post Source Mac Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Post NAT Source IPv4 Address: 31.X.X.254
    Post NAT Destination IPv4 Address: 185.X.X.254
    Post NAPT Source Transport Port: 0
    Post NAPT Destination Transport Port: 0

Os testes acima foram feitos em um CCR1036-8G-2S + executando a versão 6.32.1 (não posso atualizar, já que este é um sistema de produção).

Fazendo os mesmos testes em uma instalação x86 (executando 6.29 - também não pode atualizar porque está em produção) os resultados são ainda piores! Parece que o contador do Octets envolve 2147483647 , o que sugere que nas versões < 6.32.1 ou em construções não Tilera, o contador de octetos é de 32 bits.

A situação toda é praticamente a mesma quando você monitora uma interface Gbit com v1 SNMP (32bit counters). A solução no SNMP é muito simples. Use o SNMP v2 que suporta contadores de 64 bits. Mas não consigo encontrar nenhuma solução para o Netflow.

Alguém pode confirmar esse problema? Alguém sabe uma solução para isso? Esta é uma limitação do protocolo netflow ou um bug no RouterOS? Como outros fornecedores lidam com isso (não tenho outro equipamento no momento para testar isso)?

    

Answer 1

Olhando para a documentação da Cisco no NetFlow v9, ela menciona que os bytes O contador é por padrão 32 bits, mas é configurável e sugere que ele seja aumentado para 64 bits nos roteadores principais, etc.

In some cases the size of a field type is fixed by definition, for example PROTOCOL, or IPV4_SRC_ADDR. However in other cases they are defined as a variant type. This improves the memory efficiency in the collector and reduces the network bandwidth requirement between the Exporter and the Collector. As an example, in the case IN_BYTES, on an access router it might be sufficient to use a 32 bit counter (N = 4), on a core router a 64 bit counter (N = 8) would be required. All counters and counter-like objects are unsigned integers of size N * 8 bits.

Assim, o próprio protocolo pode suportar contadores de 64 bits. Parece que o modelo v9 do mikrotik usa contadores de 32 bits.

Acabei de confirmar isso ao capturar o modelo de dados no wireshark.

FlowSet 1 [id=0] (Data Template): 256,257
    FlowSet Id: Data Template (V9) (0)
    FlowSet Length: 184
    Template (Id = 256, Count = 22)
        Template Id: 256
        Field Count: 22
        Field (1/22): LAST_SWITCHED
        Field (2/22): FIRST_SWITCHED
        Field (3/22): PKTS
        Field (4/22): BYTES
            Type: BYTES (1)
            Length: 4
        Field (5/22): INPUT_SNMP
        Field (6/22): OUTPUT_SNMP
        Field (7/22): IP_SRC_ADDR
        Field (8/22): IP_DST_ADDR
        Field (9/22): PROTOCOL
        Field (10/22): IP_TOS
        Field (11/22): L4_SRC_PORT
        Field (12/22): L4_DST_PORT
        Field (13/22): IP_NEXT_HOP
        Field (14/22): DST_MASK
        Field (15/22): SRC_MASK
        Field (16/22): TCP_FLAGS
        Field (17/22): DESTINATION_MAC
        Field (18/22): SOURCE_MAC
        Field (19/22): postNATSourceIPv4Address
        Field (20/22): postNATDestinationIPv4Address
        Field (21/22): postNAPTSourceTransportPort
        Field (22/22): postNAPTDestinationTransportPort
    Template (Id = 257, Count = 21)
        Template Id: 257
        Field Count: 21
        Field (1/21): IP_PROTOCOL_VERSION
        Field (2/21): IPV6_SRC_ADDR
        Field (3/21): IPV6_SRC_MASK
        Field (4/21): INPUT_SNMP
        Field (5/21): IPV6_DST_ADDR
        Field (6/21): IPV6_DST_MASK
        Field (7/21): OUTPUT_SNMP
        Field (8/21): IPV6_NEXT_HOP
        Field (9/21): PROTOCOL
        Field (10/21): TCP_FLAGS
        Field (11/21): IP_TOS
        Field (12/21): L4_SRC_PORT
        Field (13/21): L4_DST_PORT
        Field (14/21): FLOW_LABEL
        Field (15/21): IPV6_OPTION_HEADERS
        Field (16/21): LAST_SWITCHED
        Field (17/21): FIRST_SWITCHED
        Field (18/21): BYTES
            Type: BYTES (1)
            Length: 4
        Field (19/21): PKTS
        Field (20/21): DESTINATION_MAC
        Field (21/21): SOURCE_MAC

O campo de bytes tem lenth 4.

Então eu acho que isso deve ser corrigido pelo MikroTik.

A menos que alguém esteja ciente de uma solução / solução alternativa.