Opérations CEF sur le commutateur L3 vs le routeur

Je comprends que les commutateurs L3 utilisent CEF pour un transfert de paquets plus rapide. Cependant, CEF ne fonctionnera pas pour les paquets qui doivent subir NAT. Est-ce à dire que CEF n'est pas utilisé par les routeurs de périphérie et les commutateurs de périphérie L3? L'utilité du CEF est-elle limitée au LAN?

— Michael May
source

Réponses:

NAT peut bien sûr utiliser CEF. C'est du propre guide de Cisco ici: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml

Q. What kind of routing performance can be expected when using Cisco IOS NAT?

    A. Cisco IOS NAT supports Cisco Express Forwarding switching, fast switching, and process switching. For 12.4T release and later, fast-switching path is no longer supported. For Cat6k platform, the switching order is Netflow (HW switching path), CEF, process path.

    Performance depends on several factors:

        The type of application and its type of traffic

        Whether IP addresses are embedded

        Exchange and inspection of multiple messages

        Source port required

        The number of translations

        Other applications running at the time

        The type of hardware and processor

Les plates-formes plus grandes exécutant IOS-XR, où la FIB est distribuée aux cartes de ligne, prennent également en charge le NAT de classe opérateur, de sorte que son utilité ne se limite pas au LAN seul.

De plus, de nombreux commutateurs L3 de Cisco ne font tout simplement pas du tout NAT

— mellowd
source

Techniquement, sur le chemin CEF, de l'entrée à la sortie, vous avez des points d'insertion pour les fonctionnalités (comme NAT). Si ce point d'insertion existe, la fonctionnalité fonctionne avec CEF activé. Mais contrairement à la recherche L3, il pourrait ne pas y avoir de gains de performances observables pour cette fonctionnalité, car CEF fournit simplement des données pour la fonctionnalité, sans changer la fonctionnalité elle-même. Mais surtout, ce sont des détails sans importance, des détails importants sont, gardez CEF activé.

— ytti

CEF est le mot de Cisco pour leur FIB. Lorsque commutateur L3 vous « sh ip cef », aucune de ces informations est en fait utilisé pour pousser les paquets du tout, ce n'est que le logiciel Trie qui est utilisé pour alimenter le matériel ASIC.

CEF n'est que le terme utilisé par Cisco pour décrire leur code de stockage / récupération de données optimisé, ce n'est pas une technologie spécifique avec une fonction spécifique.

Dans la plupart des plates-formes matérielles, vous ne pouvez pas simplement exécuter la boîte sans CEF, car la structure de données CEF est nécessaire pour compiler les informations spécifiques au matériel.
Certaines fonctionnalités comme MPLS dépendent également de la structure de données CEF et ne fonctionneront donc pas sans.

La commutation LAN (L2) n'est pas abstraite via CEF, elle ne dépend donc pas du tout de CEF.

Je recommande ce livre pour des informations assez à jour sur CEF (il est écrit après une réécriture majeure du CEF vers 12.2S)

Si vous contraignez la définition CEF de IP Trie FIB, cela ne peut évidemment pas être utilisé pour NAPT, car vous ne pouvez pas prédéterminer ce qui est natté et où. Mais comme expliqué, CEF n'est pas une technologie spécifique, c'est un concept plus large, et donc c'est discutable si CEF est une fonctionnalité NAT ou non, je me tromperais du côté de la fonctionnalité CEF:

bu.ip.fi#sh cef features global  | b Local
  Global Local features not attached to a specific interface:
     NAT
bu.ip.fi#

Je ne ferais jamais rien sans CEF et c'est probablement uniquement pour des raisons héritées que le choix de le désactiver existe même. Considérez Juniper, ils n'ont pas de terme spécifique qu'ils utilisent pour décrire le même concept, car ils n'ont pas besoin de le différencier d'une autre méthode, car une telle alternative inférieure n'existe pas.

— ytti
source

Juste pour ajouter à cela - CEF est un chemin de commutation, une arborescence d'informations pour la transmission des informations et ainsi de suite, de sorte que le nom «CEF» peut être utilisé de nombreuses façons et cela ajoute à la confusion. En fait, NAT est pris en charge dans le chemin CEF (tout comme des milliers d'autres fonctions), mais les tables construites par CEF ne contiennent pas certaines des informations nécessaires pour changer de paquet uniquement en les utilisant comme ytti l'a souligné, des entrées supplémentaires doivent être consultées (ils sont construits et maintenus par le code NAT). Quoi qu'il en soit, si le paquet peut être commuté dans le chemin CEF sans retomber dans la commutation de processus, c'est toujours une fonctionnalité prise en charge par CEF.

— Łukasz Bromirski

Est-ce à dire que CEF n'est pas utilisé par les routeurs de périphérie et les commutateurs de périphérie L3? L'utilité du CEF est-elle limitée au LAN?

CEF est utile car il permet à un routeur de réécrire rapidement les informations de la couche 2 pendant les opérations de transfert de la couche 3. Les routeurs WAN doivent réécrire les informations d'en-tête Layer2 tout comme les commutateurs LAN ... CEF est extrêmement utile pour les deux types de routeur.

À un niveau élevé, le CEF remplit deux fonctions:

Contient un cliché instantané de la table de routage, qui mappe le préfixe routé à un saut suivant
Contient une référence à une table de contiguïté Layer2, qui fournit des informations mises en cache sur les en-têtes Layer2 nécessaires pour réécrire le paquet IP via le prochain bond de sortie mentionné dans la première puce.

Exemple:

Considérez ce routeur qui a une liaison WAN HDLC sur Serial1 / 0, et une connexion LAN via FastEthernet0 / 0 ...

R1#show adjacency internal
Protocol Interface                 Address
IP       Serial1/0                 point2point(5)
                                   0 packets, 0 bytes
                                   0F000800             <--------- HDLC Header rewrite info
                                   CEF   expires: 00:02:17
                                         refresh: 00:00:17
                                   Epoch: 0
                                   Fast adjacency disabled
                                   IP redirect enabled
                                   IP mtu 1500 (0x0)
                                   Fixup disabled
                                   Adjacency pointer 0x6663D3E0, refCount 5
                                   Connection Id 0x000000
                                   Bucket 6

Supposons qu'un paquet IPv4 allant à 192.0.2.1 entre dans le routeur à partir de FastEthernet0 / 0 sur le LAN, et doit quitter Serial1 / 0 sur le WAN (le fait qu'il quitte Serial1 / 0 se trouve dans le tableau CEF ... et le CEF table fait référence à la table d'adjacence).

Lorsque le routeur reçoit le paquet IPv4 de FastEthernet0 / 0, le routeur doit supprimer l'en-tête Ethernet et ajouter l'a- tête HDLC , 0F000800car il s'agit d'une destination IPv4 ( 0x0800existe-t-il en tant que valeur de "type" HDLC pour dire que l'en-tête suivant est IPv4).

Si CEF n'a pas mis en cache les informations de réécriture d'en-tête (triviales) pour Serial1 / 0, il doit rechercher les informations manuellement au niveau du commutateur de processus (ce qui est très lent). Ces valeurs de table d'adjacence ne changeront pas tant que l'encapsulation sur Serial1 / 0 ne changera pas; par conséquent, Cisco IOS met en cache les informations de réécriture de contiguïté dans la table de contiguïté.

Les informations de réécriture s'impliquent davantage lorsque vous regardez les relais de trame ou les PVC ATM.

Ce document sur CCO (Document ID: 17812) peut expliquer les choses mieux que moi en ressassant beaucoup de contenu CCO

— Mike Pennington
source

Les opérations de couche 2 ne seront-elles pas consultées uniquement par le CAM? Les opérations de couche 3 consulteront la FIB qui est l'endroit où CEF opère et s'il doit y avoir une inspection plus approfondie des paquets à la couche 3 (dans le cas d'un paquet devant subir NAT), cela ne rendra-t-il pas CEF inutile pour les routeurs WAN?

— Michael May

CEF en particulier n'est pas utilisé pour / cache / contiguïté ou les recherches l3, il s'agit d'une «commutation rapide» (qui n'est plus du tout prise en charge). CEF est pré-construit, donc toutes les données dont vous pourriez avoir besoin pour la recherche d'adjacence ou l3, sont déjà dans la structure qui est optimale pour rechercher avec des contraintes définies par la plate-forme donnée.

— ytti

@ytti, je suis désolé, mais CEF cache les informations de contiguïté, je pense que vous vous trompez sur la façon dont le cache est rempli (à mon humble avis, vous supposez que le paquet doit être lancé pour être mis en cache, mais ce n'est pas vrai) ... One des différences substantielles entre CEF et les autres méthodes de commutation (comme fast-switching) est que CEF est pré-calculé. Cependant, CEF doit toujours mettre en cache les informations, sinon il faut le rechercher au niveau du commutateur de processus ... très lent, et la raison pour laquelle nous avons besoin de CEF pour les interfaces LAN et WAN.

— Mike Pennington

Je pense que nous ne sommes pas d'accord sur ce que signifie la `` mise en cache '', mais oui, le point clé est, il est pré-construit et pour de nombreuses fonctionnalités (telles que MPLS), ce n'est que la structure des données, il n'y a pas de stockage de `` commutation de processus '' pour se replier. à.

— ytti

@ChristianDelapena, vous confondez les implémentations matérielles d'une table de recherche matérielle (mémoire CAM) avec le processus logiciel IOS qui remplit les tables de recherche matérielle (c'est-à-dire CEF). CEF existe afin que vous puissiez mapper une entrée de préfixe de couche 3 sur les informations de réécriture de protocole requises au niveau de la couche 2 ... cependant, la couche 2 peut être constituée de nombreux protocoles différents, tels que frame-relay, atm, packet-over-sonet, hdlc, ppp ou ethernet. .. tous ces protocoles peuvent transporter IPv4, mais ils ont besoin de champs spécifiques remplis dans leurs en-têtes avant de pouvoir prendre ce paquet IP et l'encapsuler pour le prochain routeur WAN à traiter

— Mike Pennington