Netflow Aggregation cache
L’aggregation cache de Netflow est une fonctionnalité qui à fait son apparition depuis la version 8. Je vais tenter de synthétiser cette fonction dans cet article.
L’agrégation de l’export des données Netflow est en général effectué par les outils de collection de données sur les stations de management. Ici on fait de l’agrégation directement sur le routeur. On peut créer un summary des données collectées avant de les envoyer vers le data collector.
Les bénéfices d’effectuer cette opération directement sur le routeur sont :
– Réduction de la bande passante entre routeur et station de management
– Réduction du nombre de stations de management
– Augmentation des performances et évolutivité sur les routeurs ayant un grand nombre de flux et faisant tourner Netflow.
Netflow peut donc maintenir, en plus de son cache principal (#sh ip cache flow), plusieurs caches secondaires, ce sont les caches d’agrégation (#sh ip cache flow aggregation
Un petit schéma de chez Cisco pour mieux comprendre que nous avons un cache principal, qui exporte les données aux collecteurs dans un paquet de type Netflow Version 5, et des caches secondaires d’agrégations qui stockent et agrègent d’autres données puis les exportent vers les collecteurs dans un paquet Netflow version 8.
L’aggregation cache est donc basé sur le flow cache principal, et le flow aggregation est basé sur le contenu de la table de routage. Par exemple, si un flux est exporté depuis le cache principal vers le cache d’agrégation, les adresses IP source/destination du flux sont additionnées (ET logique) au masque de sa route correspondante dans la table de routage.
Le flux résultant (moins spécifique) est entré dans le cache d’agrégation.
Exemple de configuration pour mieux comprendre l’histoire du ET logique qui est basé sur la commande ‘mask source/destination minimum X’:
R1(config-if)#ip flow-aggregation cache destination-prefix R1(config-flow-cache)# cache entries 1024 R1(config-flow-cache)# export destination 172.16.0.100 2055 R1(config-flow-cache)# mask destination minimum 16 ! Jamais plus gros que /16 R1(config-flow-cache)# enabled R1(config-flow-cache)#int fa1/0 R1(config-if)#ip flow ingress R1(config-if)#int fa0/1 R1(config-if)#ip flow ingress |
Cette configuration se base sur les destinations, si vous voulez vous baser sur les sources des flux:
R1(config-if)#ip flow-aggregation cache source-prefix R1(config-flow-cache)# mask source minimum 16 |
Cette configuration va nous permettre de grouper les IP en /16 dans le cache d’agrégation plutôt que d’avoir des flux individuels pour chaque source/destination.
Vous pouvez alors vérifier les flux enregistrés avec les commandes suivantes:
#show ip cache flow #show ip cache flow aggregation destination-prefix #show ip cache flow aggregation source-prefix |
Dans mon lab INE, j’ai configuré ceci sur R6:
interface Loopback1 ip address 30.0.0.1 255.255.0.0 interface Loopback2 ip address 30.1.0.1 255.255.0.0 interface Loopback3 ip address 30.2.0.1 255.255.0.0 interface Loopback4 ip address 30.3.0.1 255.255.0.0 interface Loopback5 ip address 30.4.0.1 255.255.0.0 ! router eigrp SECURITY ! address-family ipv4 unicast autonomous-system 100 ! network 30.0.0.0 |
R4 (destination based aggregation cache)
ip flow-aggregation cache destination-prefix export destination 155.1.146.100 9998 mask destination minimum 8 enabled ! int e0/1.146 ip flow egress R4#sh ip route 30.0.0.0 Routing entry for 30.0.0.0/16, 5 known subnets Redistributing via eigrp 100 D 30.0.0.0 [90/1024640] via 155.1.146.6, 00:17:59, Ethernet0/1.146 D 30.1.0.0 [90/1024640] via 155.1.146.6, 00:17:59, Ethernet0/1.146 D 30.2.0.0 [90/1024640] via 155.1.146.6, 00:17:59, Ethernet0/1.146 D 30.3.0.0 [90/1024640] via 155.1.146.6, 00:17:59, Ethernet0/1.146 D 30.4.0.0 [90/1024640] via 155.1.146.6, 00:17:59, Ethernet0/1.146 |
On peut vérifier le fonctionnement en lançant un ping sur les adresses en 30.0.0.0/16 depuis R5. Le flux va traverser R4 qui analyse les flux ressortant pour aller vers R6 (où sont configurés les adresses 30.0.0.0/16).
R5#ping 30.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.0.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R5#ping 30.1.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.1.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R5#ping 30.2.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.2.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R5#ping 30.3.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.3.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R5#ping 30.3.0.254 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.3.0.254, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) |
Et on voit bien les flux >/8 qui arrivent dans la table d’agrégation de R4.
R4#sh ip cache flow aggregation destination-prefix IP Flow Switching Cache, 278544 bytes 7 active, 4089 inactive, 22 added 335 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, 22 added, 22 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added Minimum destination mask is configured to /8 Dst If Dst Prefix Msk AS Flows Pkts B/Pk Active Et0/1.45 155.1.45.0 /24 0 4 20 100 7.5 Et0/1.146 30.3.0.0 /16 0 1 5 100 0.0 Et0/1.146 30.2.0.0 /16 0 1 5 100 0.0 Et0/1.146 30.1.0.0 /16 0 1 5 100 0.0 Et0/1.146 30.0.0.0 /16 0 1 5 100 0.0 |
Le flux est donc placé dans le cache d’agrégation, mais il est intéressant de noter que le flux tombe également dans le cache principal, de façon non agrégée.
Je relance un ping depuis R5:
R5#ping 30.1.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 30.1.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms |
Je vois bien le résultat dans la table d’agrégation:
R4#sh ip cache flo agg dest IP Flow Switching Cache, 278544 bytes 4 active, 4092 inactive, 51 added 819 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds IP Sub Flow Cache, 34056 bytes 4 active, 1020 inactive, 51 added, 51 added to flow 0 alloc failures, 0 force free 1 chunk, 1 chunk added Minimum destination mask is configured to /8 Dst If Dst Prefix Msk AS Flows Pkts B/Pk Active Et0/1.146 30.1.0.0 /16 0 1 5 100 0.0 |
Mais je vois aussi le flux complet dans le cache principal:
R4#sh ip cache flow
IP packet size distribution (33789455 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .000 .000 .999 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 278544 bytes
8 active, 4088 inactive, 191 added
95614 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 34056 bytes
16 active, 1008 inactive, 382 added, 191 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
UDP-other 11 0.0 1 102 0.0 1.2 15.5
ICMP 127 0.0 265925 99 1712.6 129.0 14.7
IP-other 45 0.0 353 61 0.8 1610.5 4.6
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Total: 183 0.0 184636 99 1713.4 485.6 12.3
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Et0/1.146 155.1.146.1 Null 224.0.0.10 58 0000 0000 266
Et0/1.146 155.1.146.6 Null 224.0.0.10 58 0000 0000 268
Et0/1.100 169.254.100.5 Local 169.254.100.4 32 834D FED6 157
Et0/1.146 30.1.0.1 Et0/1.45 155.1.45.5 01 0000 0000 5
Et0/1.45 155.1.45.5 Null 224.0.0.10 58 0000 0000 266 |
Je pense donc que l’on peut exporter les deux tables vers l’agrégateur, mais suivant le niveau de détail que l’on souhaite avoir, on exportera au choix, le cache principal en v5, ou le cache agrégé en mode v8.
Benoit
Network engineer at CNS Communications. CCIE #47705, focused on R&S, Data Center, SD-WAN & Automation.
Follow Me:
Comments are Disabled