Quelques mots sur FastPath et FastTrack chez MikroTik

Ce n'est un secret pour personne que MikroTik fabrique des routeurs Software-Baser et que le processeur prend en charge la majeure partie du traitement du trafic. Cette approche présente un avantage, car Vous pouvez programmer presque toutes les fonctionnalités et maintenir un système relativement uniforme pour tous les appareils. Mais en vitesse, ils seront toujours à la traîne des routeurs avec des puces spécialisées.

Le traitement des packages logiciels présente plusieurs inconvénients:

1. Manque de vitesse de fil - un processeur (en particulier un seul cœur) ne peut pas fonctionner plus rapidement que les puces spécialisées.
2. Serrures. Avec de très gros volumes de trafic (par exemple, DoS / DDoS), vous ne pourrez peut-être pas vous connecter au routeur même via l'interface de la console, car tout le temps processeur sera occupé par le traitement du trafic.
3. La complexité de la mise à l'échelle. Vous ne pouvez pas ajouter un module qui augmente la vitesse de traitement des paquets dans le matériel.

Les développeurs utilisent différentes solutions matérielles et logicielles pour améliorer la situation:

1. Switch-chip sur les modèles à faible coût, vous permet de traiter le trafic Layer2 en contournant le CPU.
2. SoC avec une bonne puce réseau (ligne CCR).
3. Utilisation du chiffrement matériel
4. Diverses technologies qui réduisent le nombre de traitements logiciels pour les packages (FastPath et FastTrack), et elles seront discutées.

SlowPath vs FastPath

SlowPath est le chemin de trafic de base à travers les sous-systèmes internes MikroTik, il peut être assez varié et plus le chemin est long, plus la charge sur le CPU est élevée et plus la vitesse baisse.

FastPath - algorithmes qui vous permettent de transférer du trafic en contournant des unités de traitement assez grandes.

Environnement de travail et prise en charge des appareils

La plupart des routeurs et cartes modernes de MikroTik prennent en charge FastPath, mais le wiki a une liste détaillée:

Et une liste séparée pour les interfaces non Ethernet:

FastPath nécessite une prise en charge complète des interfaces entrantes et sortantes. Seules les files d'attente matérielles doivent être activées sur les interfaces.

Enfin, FastPath déteste vraiment le trafic fragmenté. Si le paquet est fragmenté, il restera définitivement coincé sur le CPU.

FastPath et Bridge

Bridge est une interface logicielle utilisée pour créer des communications de couche 2 entre plusieurs interfaces matérielles (ou logicielles). Si vous combinez 4 interfaces Ethernet dans le pont sur le routeur (et activez hw=yes ) et une sans fil, le trafic entre les interfaces Ethernet contournera l'interface logicielle et le trafic entre Ethernet et sans fil utilisera le pont logiciel. Sur les routeurs avec plusieurs puces (par exemple RB2011), le trafic entre les interfaces de différentes puces utilisera les capacités du pont logiciel (parfois, pour réduire la charge, les interfaces combinent simplement le cordon de raccordement et en général cela fonctionne).

FatsPath - se réfère uniquement au trafic passant par le CPU (pont logiciel), il s'agit généralement du trafic entre les interfaces de différentes puces, ou l'option hw=yes est désactivée.

Sur Packet Flow, le trafic passant par Bridge est le suivant:

Et plus de détails:

Il est inclus dans les paramètres du pont (le paramètre est le même pour toutes les interfaces de pont) [Pont] -> [Paramètres] -> [Autoriser FastPath], là vous pouvez également voir les compteurs.

Pour que FastPath fonctionne dans Bridge, les conditions suivantes doivent être remplies:

1. Il n'y a pas de configuration vlan sur les interfaces de pont (je pense que cela n'est pas pertinent pour la série CRS, où les vlan sont configurés au niveau matériel, mais je peux me tromper)
2. Il n'y a pas de règles dans le /interface bridge filter /interface bridge nat , ce sont les mêmes blocs du deuxième circuit que la trame traverse.
3. Pare use-ip-firwall=no feu IP non activé ( use-ip-firwall=no ). Une bonne fonctionnalité pour capturer le trafic et déboguer le réseau, mais rarement activée de manière continue.
4. N'utilisez pas de mesh et de metarouter
5. Sur l'interface ne fonctionnent pas: renifleur, torche et générateur de trafic.

FastPath et Tunnel

En bref: l'interface du tunnel est l'encapsulation de certains paquets dans la partie de chargement d'autres paquets. Si vous suivez PacketFlow, le paquet d'origine est marqué de lignes rouges, le paquet d'origine encapsulé dans le paquet de protocole de tunnel (par exemple, ipip ou gre; eoip obtient (et vient) dans la décision de pontage; le paquet de tunnel est encore plus intéressant, mais n'est pas lié à fastpath).

Le trafic du tunnel dans FastPath ne sera pas visible dans: pare-feu, files d'attente, hotspot, vrf, comptabilité ip. Mais certains des paquets continueront à être transmis via SlowPath, cela doit être pris en compte lors de la configuration du pare-feu.

Pour que FastPath fonctionne dans les interfaces de tunnel, les conditions suivantes doivent être remplies:

1. N'utilisez pas le cryptage IPSec
2. Évitez la fragmentation des paquets (configurez mtu correctement)
3. Activer allow-fast-path=yes sur l'interface du tunnel

FastPath et Layer3

La couche 3 est la transmission de paquets entre les sous-réseaux; le routeur construit des tables de routage et les transmet au saut suivant.

Sur Packet Flow, le trafic de transit de la couche réseau ressemble à ceci:

aller en profondeur

et encore plus profond

Pour utiliser FastPath sur Layer3, les conditions suivantes doivent être remplies:

1. N'ajoutez pas de règles au pare-feu (du tout, même nat).
2. N'ajoutez pas d'entrées aux listes d'adresses.
3. Ne configurez pas les files d'attente simples et l'arborescence des files d'attente pour parent=global ou les interfaces sur lesquelles vous prévoyez d'obtenir un FastPath fonctionnel.
4. N'utilisez pas de mesh et de métarouteur.
5. Désactivez le suivi des connexions. L'option auto a été introduite spécifiquement pour que FastPath fonctionne lorsqu'il n'y avait pas de règles dans le pare-feu.
6. N'utilisez pas la /ip accounting .
7. N'utilisez pas /ip route vrf .
8. Ne configurez pas /ip hotspot .
9. N'ajoutez pas de stratégies IPSec.
10. Le cache d'itinéraire doit être activé.
11. N'utilisez pas activement: /tool mac-scan et /tool ip-scan .
12. L'exécution de renifleur, de torche et de générateur de trafic interfère avec FastPath.

Il est inclus dans les paramètres IP: [IP] -> [Paramètres], vous pouvez également voir les compteurs des paquets traités avec succès.

Capture d'écran d'un routeur domestique. J'ai un pare-feu assez chargé, plusieurs connexions et files d'attente L2TP / IPSec activées en permanence. Vous ne pouvez même pas rêver de FastPath.

Fasttrack

Technologie d'étiquetage des paquets IP pour un passage rapide à travers le flux de paquets.

Pour que FastTrack fonctionne, les conditions suivantes doivent être respectées:

1. Le cache d'itinéraire et FastPath doivent être activés et actifs.
2. La configuration correcte pour l'étiquetage du trafic.
3. Fonctionne uniquement pour le trafic UDP et TCP.
4. N'utilisez pas de mesh et de métarouteur.
5. N'utilisez pas activement: /tool mac-scan et /tool ip-scan .
6. L'exécution de renifleur, de torche et de générateur de trafic interfère avec FastTrack.

Le trafic marqué comme fasttrack ne sera pas traité dans:

1. Filtre pare-feu (bien que cela soit discutable, je montrerai pourquoi dans l'exemple);
2. Pare-feu mangle;
3. IPsec
4. Files d'attente avec parrent = global;
5. Hotspot;
6. VRF

Si quelque chose interfère avec le paquet passant par fasttrack, il sera transmis comme tous les paquets restants le long du chemin lent.

Il est activé en ajoutant une règle (voir ci-dessous) dans le pare-feu. FastTrack seuls les paquets de la connexion établie sont marqués (vous pouvez en marquer de nouveaux, mais il y aura ensuite des problèmes avec NAT). La table de filtres est utilisée car lors du marquage de fasttrack dans le pré-routage, il y aura à nouveau des problèmes avec NAT.

Test synthétique

Et (pour le dernier test) ce qui a été configuré et comment cela a fonctionné:
Les règles de filtrage ont continué à traiter le trafic (si vous désactivez l'autorisation du trafic établi et connexe, il est abandonné), les paquets qui ne sont pas entrés dans FastTrack ont ​​été capturés dans postrouting + mangle.

Dans Connection Tracker, vous pouvez suivre les connexions FastTrack par l'indicateur du même nom.

Dans les compteurs [IP] -> [Paramètres], vous pouvez voir que FastTrack est actif et fonctionne, mais pas FastPath.

 /ip firewall filter add action=fasttrack-connection chain=forward connection-state=established,related add action=accept chain=forward connection-state=established,related add action=accept chain=forward connection-state=new add action=drop chain=forward /ip firewall mangle add action=mark-packet chain=postrouting connection-state=established,related new-packet-mark=q1 passthrough=no src-address=20.20.20.0/24 /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1 

Au lieu d'une conclusion

Utiliser ou non?

• FastPath for Bridge - Certainement oui. Réduit au moins la charge sur le CPU.
• FastPath pour les tunnels - Non. Cela fonctionne boueux, il s'éteint s'il y a du cryptage.
• FastPath pour Layer3 - En controverse, la plupart des capacités du routeur sont perdues. Dans un grand réseau fermé à l'Internet sauvage, le réseau peut avoir ses propres (petits) gains.
• FastPath pour MPLS / VLAN / Bonding / VRRP - S'active automatiquement, si possible. Il n'y a pas d'option distincte pour le contrôle.
• FastTrack - Pour les configurations domestiques et SOHO sans files d'attente et un pare-feu paranoïaque convient. Les tests synthétiques avec un seul client semblent bons, dans la pratique, vous devez surveiller attentivement le trafic qui a fui devant FastTrack et rechercher la cause.

Liens en plus

https://wiki.mikrotik.com/wiki/Manual:Fast_Path
https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack
http://mum.mikrotik.com/presentations/UA15/presentation_3077_1449654925.pdf