Contenu

Introduction

Comportement CEF sur la plate-forme Cisco IOS XE

Vérifier la contiguïté CEF

Phénomène commun observé

Conclusion

Introduction

Ce document décrit la fonctionnalité CEF (Cisco Express Forwarding) sur les périphériques basés sur Cisco IOS® XE. Contrairement aux autres routeurs Cisco, les routeurs basés sur Cisco IOS XE sont modulaires non seulement en termes de matériel, mais également en termes de logiciels. En raison de cette nature, le comportement de la plupart des fonctionnalités et des protocoles est également un peu différent. Vous verrez également comment les tables CEF sont gérées sur les périphériques basés sur Cisco IOS XE et comment les grandes tables BGP (Border Gateway Protocol) sont gérées en termes de mises à jour CEF sur les plates-formes Cisco IOS XE.

Comportement CEF sur la plate-forme Cisco IOS XE

Mise à jour de table CEF au sein de la plate-forme XE

Sur les périphériques Cisco IOS XE tels que l'ASR1000, le plan de contrôle est séparé du plan de transfert. Chaque fois qu'une mise à jour doit être transmise du plan de contrôle au plan de données, elle doit passer par le flux de données indiqué dans le diagramme de flux. Par exemple, dans le cas du CEF chaque fois qu'un préfixe est appris sur le plan de contrôle, cette mise à jour passe du plan de contrôle (IOSd) au gestionnaire de transfert du plan de contrôle (FMAN-RP). Le gestionnaire de transfert du plan de contrôle utilise des utilitaires du noyau tels que les liaisons lsmpi, Hyper-Transport (HT), etc. afin de transmettre la mise à jour au gestionnaire de transfert du plan de transfert (ESP) (FMAN-FP). Le gestionnaire de transfert envoie la mise à jour au QFP (Quantum Flow Processor) qui programme le microcode QFP afin de programmer enfin le sous-système QFP qui effectue le transfert réel des paquets dans les périphériques Cisco ASR (Aggregation Services Router).

Vous pouvez utiliser différentes commandes pour vérifier la mise à jour CEF sur chacun de ces modules logiciels. C'est le processus étape par étape pour cela.

Afin de vérifier CEF sur le plan de contrôle :

Router#show ip cef

Prefix                     Next Hop             Interface

0.0.0.0/0                  no route

0.0.0.0/8                  drop

0.0.0.0/32                 receive

1.1.1.1/32                 10.10.10.1           GigabitEthernet0/0/0

2.2.2.2/32                 receive              Loopback1

10.10.10.0/24              attached             GigabitEthernet0/0/0

10.10.10.0/32              receive              GigabitEthernet0/0/0

Router#show platform software ip rp active cef summary

Forwarding Table Summary

Name             VRF id  Table id    Protocol         Prefixes    State

------------------------------------------------------------------------------------------------

Default          0       0           IPv4             20          OM handle: 0x404a4df8

Router#show platform software ip rp active cef detail

Forwarding Table

0.0.0.0/0 -> OBJ_ADJ_NOROUTE (0), urpf: 5

Prefix Flags: Default, Default route handler

OM handle: 0x404a91e8

0.0.0.0/8 -> OBJ_ADJ_DROP (0), urpf: 13

Prefix Flags: unknown

OM handle: 0x404bd5e8

0.0.0.0/32 -> OBJ_ADJ_RECEIVE (0), urpf: 12

Prefix Flags: Receive

OM handle: 0x404bd298

1.1.1.1/32 -> OBJ_ADJACENCY (16), urpf: 20

Prefix Flags: unknown

OM handle: 0x404fec70

Afin de vérifier les détails CEF dans le plan de transfert (ESP) :

Router#show platform software ip fp active cef detail

Forwarding Table

0.0.0.0/0 -> OBJ_ADJ_NOROUTE (0), urpf: 5

Prefix Flags: Default, Default route handler

aom id: 73, HW handle: 0x4310df8 (created)

0.0.0.0/8 -> OBJ_ADJ_DROP (0), urpf: 13

Prefix Flags: unknown

aom id: 90, HW handle: 0x4362cd8 (created)

0.0.0.0/32 -> OBJ_ADJ_RECEIVE (0), urpf: 12

Prefix Flags: Receive

aom id: 86, HW handle: 0x4333568 (created)

127.0.0.0/8 -> OBJ_ADJ_DROP (0), urpf: 13

Prefix Flags: unknown

aom id: 91, HW handle: 0x4387048 (created)

224.0.0.0/4 -> OBJ_ADJ_DROP (0), urpf: 13

Prefix Flags: unknown

aom id: 92, HW handle: 0x43870d8 (created)

Router#show platform software ip fp active cef summary

Forwarding Table Summary

Name             VRF id  Table id    Protocol         Prefixes    State

------------------------------------------------------------------------------------------------

Default          0       0           IPv4             20          hw: 0x43010a8 (created)

Ces commandes peuvent également être utilisées lorsque vous rencontrez des problèmes CEF sur le périphérique. Par exemple, bien que les routes soient apprises, les préfixes ne sont pas accessibles. Vous pouvez parcourir tous les modules pour voir si toutes les tables CEF sont mises à jour correctement ou non.

Vérifier la contiguïté CEF

De la même manière, vous pouvez vérifier davantage la table de contiguïté CEF pour toutes les informations de couche 2 sur les préfixes adjacents.

Afin de vérifier la contiguïté CEF sur le plan de contrôle :

Router#show adjacency gigabitEthernet 0/0/0 detail

Protocol Interface                 Address

IP       GigabitEthernet0/0/0      10.10.10.1(11)

72772 packets, 4622727 bytes

epoch 0

sourced in sev-epoch 0

Encap length 14

0062EC6B89000062EC6BEC000800

L2 destination address byte offset 0

L2 destination address byte length 6

Link-type after encap: ip

ARP

Router#show platform software adjacency rp active

Number of adjacency objects: 4

Adjacency id: 0x10 (16)

Interface: GigabitEthernet0/0/0, IF index: 8, Link Type: MCP_LINK_IP

Encap: 0:62:ec:6b:89:0:0:62:ec:6b:ec:0:8:0

Encap Length: 14, Encap Type: MCP_ET_ARPA, MTU: 1500

Flags: no-l3-inject

Incomplete behavior type: None

Fixup: unknown

Fixup_Flags_2: unknown

Nexthop addr: 10.10.10.1

IP FRR MCP_ADJ_IPFRR_NONE 0

OM handle: 0x404ea1d8

Vous devez noter l'ID de contiguïté afin de vérifier les détails de cette contiguïté particulière dans le plan de transfert. Dans ce cas, l'ID de contiguïté est 16.

Afin de vérifier la contiguïté CEF sur le plan de transfert :

Router#show platform software adjacency fp active index 16

Number of adjacency objects: 4

Adjacency id: 0x10 (16)

Interface: GigabitEthernet0/0/0, IF index: 8, Link Type: MCP_LINK_IP

Encap: 0:62:ec:6b:89:0:0:62:ec:6b:ec:0:8:0

Encap Length: 14, Encap Type: MCP_ET_ARPA, MTU: 1500

Flags: no-l3-inject

Incomplete behavior type: None

Fixup: unknown

Fixup_Flags_2: unknown

Nexthop addr: 10.10.10.1

IP FRR MCP_ADJ_IPFRR_NONE 0

aom id: 114, HW handle: 0x43ae148 (created)

Ici, vous voyez que les informations de contiguïté CEF sont renseignées dans le gestionnaire de transfert (FMAN) sur FP. FMAN FP envoie ces informations au pilote client QFP qui programme la table de transfert QFP qui sera utilisée pour le transfert. À partir de la commande précédente, copiez le handle matériel afin de vérifier les informations de transfert sur QFP.

Router#show pla hard qfp act feature cef-mpls adjacency handle 0x43ae148

Adj Type: : IPV4 Adjacency

Encap Len: : 14

L3 MTU: : 1500

Adj Flags: : 0

Fixup Flags: : 0

Output UIDB: :

Interface Name: GigabitEthernet0/0/0

Encap: : 00 62 ec 6b 89 00 00 62 ec 6b ec 00 08 00

Next Hop Address: : 10.10.10.1

Lisp Fixup HW Ptr: : 0x767b28f0

Next HW OCE Ptr: : 00000000

CM   HW    Ptr:: 946947588

Fixup_Falgs_2: : 0

Ici, vous savez que toutes les tables de contiguïté sont mises à jour correctement et que le routeur est prêt à transmettre. Cependant, tout le processus d'isolation prend beaucoup de commandes et nécessite une connaissance de l'architecture modulaire à un certain niveau. Par conséquent, pour simplifier cela, une commande a été introduite récemment qui fournit des informations consolidées de tous les modules.

Note: Pour les périphériques dotés d’une longue table de routage, cette commande peut prendre plusieurs minutes.

La commande est show ip cef platform detail.

Phénomène commun observé

Pour tous les périphériques modulaires Cisco IOX XE dans les situations où un grand nombre de préfixes sont appris sur le routeur, il faut généralement un certain temps pour programmer tous les préfixes dans tous les modules de transfert. Ceci peut être observé très fréquemment sur les routeurs qui sont assis à la périphérie du fournisseur et qui apprennent la table de routage BGP complète à partir du FAI.

Dans le centre d'assistance technique, il y a eu peu de cas où il a été constaté qu'après l'ouverture de la session BGP et même la mise à jour de la route BGP dans la table de routage, les préfixes ne sont pas accessibles pendant un certain temps. Normalement, cela prend entre 20 et 30 secondes et dépend de la plate-forme du routeur pour envoyer des requêtes ping à ces préfixes. Par exemple, voici un scénario de test :

Pagent est un outil de générateur de trafic utilisé pour pousser un million de routes BGP vers le routeur ASR1002HX.

Vous voyez ici que, même si les routes BGP sont apprises sur le périphérique et que la table CEF du plan de contrôle est mise à jour, le réseau interne ne peut pas envoyer de requête ping aux préfixes appris pendant quelques secondes supplémentaires. Sur la base de la discussion CEF, il est clair que vous devez mettre à jour les entrées CEF sur chaque module logiciel. Vous pouvez voir une conséquence de ce comportement dans ce scénario particulier où les préfixes ne sont pas accessibles en raison du fait qu'ils n'ont pas été mis à jour dans la table de transfert ESP. Voici quelques résultats de l'ASR1002HX pour référence.

Les tables BGP sont mises à jour avec un million de routes.

Router#show ip bgp summary

BGP router identifier 1.1.1.1, local AS number 100

BGP table version is 1, main routing table version 1

1000002 network entries using 248000496 bytes of memory

1000002 path entries using 128000256 bytes of memory

100002/0 BGP path/bestpath attribute entries using 26400528 bytes of memory

100000 BGP AS-PATH entries using 5402100 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 407803380 total bytes of memory

BGP activity 8355774/7355772 prefixes, 9438985/8438983 paths, scan interval 60 secs

Neighbor        V           AS  MsgRcvd MsgSent   TblVer  InQ OutQ             Up/Down                                 State/PfxRcd

10.10.10.2      4          100       5       2              1    0             0 00:00:58                                         1

20.20.20.2      4          100  100002       3              1    0             0 00:01:02                                   1000000

Bien que la table BGP ait un million de préfixes, la table CEF du gestionnaire de transfert n'avait que 48613 préfixes acquis.

Si vous attendez 20 à 30 secondes, vous voyez la table CEF FP entièrement mise à jour avec un million de préfixes.

Router#show platform software ip fp active cef summary

Forwarding Table Summary

Name             VRF id  Table id    Protocol         Prefixes    State

------------------------------------------------------------------------------------------------

Default          0       0           IPv4             48613       hw: 0x2edce98 (created)

Conclusion

Lorsque vous traitez des périphériques d'architecture modulaire basés sur Cisco IOS XE pour le transfert de problèmes connexes, vous devez vérifier les informations relatives à la table de transfert à partir de tous les modules logiciels. Le scénario BGP expliqué peut être considéré comme un comportement attendu avec cette plate-forme, car le périphérique met quelques secondes pour mettre à jour les préfixes dans tous les modules logiciels.