In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie der Cisco Catalyst 6500 mit Supervisor Sup2T die in der Cisco IOS-Software konfigurierten (Cisco Express Forwarding) CEF-Einträge in der Linecard-Hardware programmiert, die für die Paketweiterleitung verwendet wird.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Cisco Catalyst Switches der Serie 6500
Die Informationen in diesem Dokument basieren auf folgenden Hardware- und Software-Versionen:
Cisco Catalyst 6500 WS-X6848-GE-TX (mit DFC4) Line Card
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
CEF als Layer-3-Switching-Mechanismus wird von den meisten Multilayer-Switches von Cisco verwendet. Für Netzwerktechniker ist es wichtig zu verstehen, wie CEF funktioniert, um Netzwerkausfälle, Paketverluste oder Paketverzögerungsszenarien täglich zu beheben.
Der Sup2T-Supervisor im Standalone-Modus oder, da VSS derzeit von vielen Unternehmensnetzwerken als Core-Switch bereitgestellt wird, aggregiert praktisch alle anderen Routing- oder Switching-Geräte. Dies bedeutet auch, dass der Großteil des Intra- und Inter-Domain-Verkehrs weitergeleitet wird, um die Pakete erfolgreich an die Ziele zu senden. Um dies zu erreichen, muss Sup2T über geeignete Routing-Informationen verfügen, die statisch oder dynamisch über Routing-Protokolle gelernt werden.
In einem modularen Chassis können neben den Supervisors mehrere Forwarding-Engines vorhanden sein. Bestimmte Linecards (insbesondere die der neuen Generation wie C6800-32P10G) verfügen bereits über eine eigene Weiterleitungs-Engine, um die Paketvermittlungsleistung zu verbessern. Die Suche nach CEF-Einträgen wird lokal ausgeführt und bewirkt, dass Ressourcen für Datenverkehr, der über verschiedene Linecards eingeht, optimal verteilt werden. Diese werden als verteilte Weiterleitungskarten (DFCs) bezeichnet.
Diese CEF-Einträge, die von allen Weiterleitungs-Engines gemeinsam genutzt werden, können aus mehreren Gründen nicht in der HW zugewiesen werden, von einem Softwaredefekt über eine erschöpfte Ressourcennutzung bis hin zu hohen CPU-Bedingungen. Dadurch wird verhindert, dass der Switch genügend Zeit hat, um alle Einträge zu aktualisieren. Dies kann zu einer Reihe unerwünschter Ereignisse führen.
Netzwerk:
Switch#show module 3
---------------------- ----------------------------- Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 3 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6848-GE-TX SAL2003X5AH ---- --------------------------- ------------------ ----------- ------- ------- 3 Distributed Forwarding Card WS-F6K-DFC4-A SAL2003X5AH 1.4 Ok
In dem Diagramm hat ein eigenständiger 6506-Switch einen installierten Supervisor 2T sowie eine Linecard WS-6848-GE-TX mit einem DFC in Steckplatz 3. Host 3750X, der über Port G3/1 mit der Linecard verbunden ist, sendet Datenverkehr an die Loopback 0-Adresse 1.1.1.1 von 3850.
Dazu weist der 3750X eine statische Route zur IP-Adresse 1.1.1.1 bis zum nächsten Hop 10.1.1.10 auf, der die SVI von VLAN 1 im Sup2T-Switch darstellt. Der Sup2T-Switch muss diesen Datenverkehr basierend auf einem statischen Routeneintrag für IP 1.1.1.1/32 über den nächsten Hop 10.1.2.1, der mit dem Sup2T in VLAN 2 verbundenen 3850-Schnittstelle, an den 3850-Switch weiterleiten.
MXC.CALO.3750X#show ip route | inc 1.1.1.1 S 1.1.1.1 [1/0] via 10.1.1.10 MXC.CALO.Sup2T#show ip route | inc 1.1.1.1 S 1.1.1.1 [1/0] via 10.1.2.1 CALO.MXC.3850#show ip route | inc 1.1.1.1 C 1.1.1.1 is directly connected, Loopback1
Beachten Sie, dass der Einfachheit halber sowohl der 3750X als auch der 3850 Switch über dieselbe Linecard mit dem 6500 verbunden sind. Das bedeutet, dass der Datenverkehr lokal gesucht und lokal weitergeleitet wird.
Ein Paket erreicht den Sup2T-Switch über Gi3/1 und erreicht schließlich die Weiterleitungs-Engine (da es sich um eine DFC handelt). Die Weiterleitungs-Engine analysiert das Feld für die Ziel-IP-Adresse in diesem Paket und führt eine Suche nach den programmierten CEF-Einträgen durch, um die beste Übereinstimmung zu erhalten (längste Maske).
Da es sich um eine DFC-Karte handelt, bedeutet dies, dass sie über eigene CEF-Einträge verfügt, und um diese zu überprüfen, müssen Sie die Linecard mit dem Befehl "hängen" [dec] oder dem Befehl "switch" [1-2] mod [dec] für VSS anschließen.
Jetzt sollten Sie in der DFC-Eingabeaufforderung, Befehl show platform hardware cef oder show platform hardware cef vpn 0 alle CEF-Einträge zurückgeben, die für eine allgemeine Routing-Tabelle (VPN 0/Keine VRF) programmiert wurden.
Da das Ziel das Präfix 1.1.1.1/32 ist, verwenden Sie den Befehl show platform hardware cef vpn 0 lookup 1.1.1.1.1. Der Befehl gibt die beste Übereinstimmung für das Präfix 1.1.1.1 und die für die tatsächliche Weiterleitung des Datenverkehrs verwendete zurück:
MXC.CALO.Sup2T#attach 3 Trying Switch ... Entering CONSOLE for Switch Type "^C^C^C" to end this session MXC.CALO.Sup2T-dfc3#show platform hardware cef vpn 0 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 32 0.0.0.0/32 receive 33 255.255.255.255/32 receive 34 10.1.85.254/32 glean 35 10.1.85.5/32 receive 36 10.1.86.5/32 receive [snip...] MXC.CALO.Sup2T-dfc3#show platform hardware cef vpn 0 lookup 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 262 1.1.1.1/32 Vl2 ,0c11.678b.f6f7
Der CEF-Eintrag ist vorhanden und wurde als Ergebnis unseres statischen Eintrags in der IOS-Software über den Befehl ip route 1.1.1.255.255.255.255 10.1.2.1 programmiert.
Sie können auch überprüfen, ob dieser Eintrag Treffer erhält und Datenverkehr mit diesem Eintrag über Befehle show platform hardware cef 1.1.1.1 detail weitergeleitet wird, die einen Adjacency-Eintrag zurückgibt:
MXC.CALO.Sup2T-dfc3#show platform hardware cef 1.1.1.1 detail Codes: M - mask entry, V - value entry, A - adjacency index, NR- no_route bit LS - load sharing count, RI - router_ip bit, DF: default bit CP - copy_to_cpu bit, AS: dest_AS_number, DGTv - dgt_valid bit DGT: dgt/others value Format:IPV4 (valid class vpn prefix) M(262 ): 1 F 2FFF 255.255.255.255 V(262 ): 1 0 0 1.1.1.1 (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0)
Schließlich zeigt der Adjacency-Eintrag an, wie das Paket neu geschrieben wird und ob der Datenverkehr durch diesen Adjacency-Eintrag neu geschrieben wird:
MXC.CALO.Sup2T-dfc3#show platform hardware cef adjacencies entry 114689 detail RIT fields: The entry has a Layer2 Format _________________________________________________________ |decr_ttl = YES | pipe_ttl = 0 | utos = 0 |_________________|__________________|____________________ |l2_fwd = 0 | rmac = 0 | ccc = L3_REWRITE |_________________|__________________|____________________ |rm_null_lbl = YES| rm_last_lbl = YES| pv = 0 |_________________|__________________|____________________ |add_shim_hdr= NO | rec_findex = N/A | rec_shim_op = N/A |_________________|__________________|____________________ |rec_dti_type = N/A | rec_data = N/A |____________________________________|____________________ |modify_smac = YES| modify_dmac = YES| egress_mcast = NO |____________________________________|____________________ |ip_to_mac = NO |_________________________________________________________ |dest_mac = 0c11.678b.f6f7 | src_mac = d8b1.902c.9680 |___________________________|_____________________________ | Statistics: Packets = 642 Bytes = 75756 <<<<
dest_mac und src_mac sind die Werte von main interest, die die neuen L2-Header angeben, die für dieses Paket geschrieben werden. Die Ziel-MAC-Adresse 0c11.678b.f6f7 ist 10.1.2.1. Dies ist die 3850 (Next Hop to reach 1.1.1.1):
MXC.CALO.Sup2T#show ip arp 10.1.2.1 Protocol Address Age (min) Hardware Addr Type Interface Internet 10.1.2.1 30 0c11.678b.f6f7 ARPA Vlan2
Das Statistikfeld zeigt außerdem an, dass der Datenverkehr tatsächlich auf diesen Adjacency-Eintrag trifft, und L2-Header werden entsprechend umgeschrieben.
Löschen Sie CEF-Einträge können uns helfen, alle Einträge zu löschen, die falsch programmiert sein könnten (zu einem falschen Adjacency-Eintrag zum Beispiel) oder sogar für Schulungszwecke. Es bietet auch die Möglichkeit, einen Routing-Pfad zu ändern.
Um einen CEF-Eintrag zu löschen, müssen Sie wissen, dass CEF-Einträge sequenziell programmiert sind und dass ihnen ein Hardware-Index zugewiesen wurde. Beispiel:
MXC.CALO.Sup2T-dfc3#show platform hardware cef vpn 0
Codes: decap - Entkapselung, + - Aufkleber
MXC.CALO.Sup2T-dfc3#show platform hardware cef vpn 0
...
Index Prefix Adjacency 259 10.1.2.255/32 receive 260 10.1.1.1/32 Vl1 ,a0ec.f930.3f40 261 10.1.2.1/32 Vl2 ,0c11.678b.f6f7 262 1.1.1.1/32 Vl2 ,0c11.678b.f6f7 <<<< Our CEF entry of interest has a HW index of 262.
...
Dieser Hardware-Index ist das wichtigste Element zum Löschen eines CEF-Eintrags, da er als Referenz verwendet wird. Um jedoch Änderungen daran vorzunehmen, muss es in ein Software-Handle konvertiert werden. Dies können Sie mit dem Befehl test platform hardware cef index-conv hw_to_sw [hw index] erreichen
MXC.CALO.Sup2T-dfc3#test platform hardware cef index-conv hw_to_sw 262 hw index: 262 ----> sw handle: 101
Nun, da Sie wissen, die Software-Handle, können Sie mit der CEF-Eintrag Löschung mit Befehl Testplattform Hardware cef v4-delete [sw Handle] mask [Maskenlänge] vpn [dec]
MXC.CALO.s2TVSS-sw2-dfc3#test platform hardware cef v4-delete 101 mask 32 vpn 0 test_ipv4_delete: done.
Anmerkung: Der Wert für die Maskenlänge ist 32, da es sich um eine hostspezifische Route handelt (1.1.1.1/32).
Jetzt wird unser CEF-Eintrag gelöscht:
MXC.CALO.Sup2T-dfc3#show platform hard cef vpn 0 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency MXC.CALO.Sup2T-dfc3#show platform hard cef vpn 0 [snip...] 259 10.1.2.255/32 receive 260 10.1.1.1/32 Vl1 ,a0ec.f930.3f40 261 10.1.2.1/32 Vl2 ,0c11.678b.f6f7 288 224.0.0.0/24 receive <<<<<<< Index 262 no longer exists in the CEF entries. 289 10.1.85.0/24 glean
Beachten Sie, dass der Befehl cef vpn 0 der Testplattform-Hardware unter der DFC-Eingabeaufforderung ausgeführt wurde. Auf diese Weise wurde der CEF-Eintrag aus der CEF-Tabelle der DFC und NICHT aus dem Supervisor entfernt. Sie müssen sehr vorsichtig sein, von welcher Weiterleitungs-Engine die Einträge entfernt werden.
Bei einer Änderung des Datenverkehrs besteht das Risiko, dass keine Transparenz erkennbar ist (im Falle eines Labortests). Dies kann auf einen anderen CEF-Eintrag zurückzuführen sein. Achten Sie darauf, immer die exakteste (längste Maske). In dieser Übung trifft er auf:
MXC.CALO.Sup2T-dfc3#show plat hard cef vpn 0 lookup 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 262048 0.0.0.0/0 glean
Was macht dieser Eintrag eigentlich mit dem Paket?:
MXC.CALO.Sup2T-dfc3#show platform hardware cef adjacencies entry 262048
RIT fields: The entry has a Recirc. Format _________________________________________________________ |decr_ttl=NO | l2_fwd=NO | ccc = 6 | add_shim_hdr = YES |_____________|____________|_________|____________________ |rc_fidx=0 | rc_shimop=1 | rc_dti_type=4 | rc_data = 0x10B |____________|_____________|_______________|______________ Statistics: Packets = 2163 Bytes = 255234
Taken from a CPU packet capture using Catlayst 6500 NETDR tool. For NETDR capture tool details refer to: Catalyst 6500 Series Switches Netdr Tool for CPU-Bound Packet Captures ------- dump of incoming inband packet ------- l2idb Po1, l3idb Vl1, routine inband_process_rx_packet, timestamp 01:00:17.841 dbus info: src_vlan 0x1(1), src_indx 0xB40(2880), len 0x82(130) bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x5FA4(24484), CoS 0 cap1 0, cap2 0 78020800 00018400 0B400100 82000000 1E000464 2E000004 00000010 5FA45BDD destmac D8.B1.90.2C.96.80, srcmac A0.EC.F9.30.3F.40, shim ethertype CCF0 earl 8 shim header IS present: version 0, control 64(0x40), lif 1(0x1), mark_enable 1, feature_index 0, group_id 0(0x0), acos 0(0x0), ttl 14, dti 4, dti_value 267(0x10B) 10000028 00038080 010B ethertype 0800 protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 100, identifier 51573 df 0, mf 0, fo 0, ttl 255, src 10.1.1.1, dst 1.1.1.1 icmp type 8, code 0 ------- dump of outgoing inband packet ------- l2idb NULL, l3idb Vl2, routine etsec_tx_pak, timestamp 01:03:56.989 dbus info: src_vlan 0x2(2), src_indx 0x380(896), len 0x82(130) bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x0(0), CoS 0 cap1 0, cap2 0 00020000 0002A800 03800000 82000000 00000000 00000000 00000000 00000000 destmac 0C.11.67.8B.F6.F7, srcmac D8.B1.90.2C.96.80, shim ethertype CCF0 earl 8 shim header IS present: version 0, control 0(0x0), lif 16391(0x4007), mark_enable 0, feature_index 0, group_id 0(0x0), acos 0(0x0), ttl 15, dti 0, dti_value 540674(0x84002) 000800E0 0003C008 4002 ethertype 0800 protocol ip: version 0x04, hlen 0x05, tos 0x00, totlen 100, identifier 50407 df 0, mf 0, fo 0, ttl 254, src 10.1.1.1, dst 1.1.1.1 icmp type 8, code 0
Nun wird der gesamte Datenverkehr mit dem Ziel 1.1.1.1, der über Linecard 3 eingeht, mit dem Shim-Header rezirkuliert und zur CPU gelocht. Manchmal wird anstelle dieses CEF-Eintrags eine weitere 0.0.0.0/0 mit Drop-Adjaceny angezeigt, die genau dasselbe tut.
Anmerkung: Werten Sie aus, welche CEF-Einträge entfernt wurden. Dadurch kann eine hohe CPU-Auslastung verursacht werden. In der Regel wird die Standardroute 0.0.0.0/0 konfiguriert, und der Datenverkehr wird auf dieser Grundlage weitergeleitet (und verursacht einen Paketverlust).
Wenn ein CEF-Eintrag hinzugefügt wird, werden in den meisten Fällen Probleme bei der Fehlprogrammierung behoben, die zu Paketverlusten, Paketverzögerungen oder einer hohen CPU-Auslastung führen. Kenntnisse, wie die CEF-Einträge in der Hardware installiert werden, bieten nicht nur die Möglichkeit, einen falsch programmierten Eintrag zu korrigieren, sondern auch die Paketweiterleitung durch Rezirkulation des Pakets zu manipulieren, es auf eine völlig andere Schnittstelle oder einen nächsten Hop zu verweisen, ein geroutetes Paket nach Bedarf umzuschreiben und/oder zu verwerfen usw. All dies, ohne ein Neuladen der Box, entfernen und Konfiguration oder eine offensichtliche Änderung. Der CEF-Eintrag kann hinzugefügt werden, ohne dass der Konfigurationsmodus aktiviert wird. (Wie Sie es auch mit dem CEF-Eintrags-Entfernungsverfahren im vorherigen Abschnitt beschrieben haben).
Grundsätzlich gibt es hier zwei Situationen, in denen Sie einen gültigen ARP-Eintrag für den nächsten Hop haben, in diesem Fall 10.1.2.1 und in denen Sie es nicht tun (aus irgendeinem Grund). In der zweiten Situation müssen Sie einen gültigen ARP-Eintrag erstellen (über statisches ARP):
Schritt 1: Im Switch befindet sich ein ARP-Eintrag für 10.1.2.1, der den nächsten Hop für 1.1.1.1 darstellt.
MXC.CALO.Sup2T#show ip arp 10.1.2.1 Protocol Address Age (min) Hardware Addr Type Interface Internet 10.1.2.1 2 0c11.678b.f6f7 ARPA Vlan2 MXC.CALO.Sup2T#show ip route | inc 1.1.1.1 S 1.1.1.1 [1/0] via 10.1.2.1
Ein ARP-Eintrag wird als Host-Route ( /32 ) in der CEF-Tabelle programmiert:
MXC.CALO.Sup2T-dfc3#show plat hard cef vpn 0 look 10.1.2.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 53 10.1.2.1/32 Vl2 ,0c11.678b.f6f7 And of course, there is an index for this which again will tell us how a packet should be rewritten to reach 10.1.2.1: MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef vpn 0 10.1.2.1 detail [snip...] Format:IPV4 (valid class vpn prefix) M(53 ): 1 F 2FFF 255.255.255.255 V(53 ): 1 0 0 10.1.2.1 (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0) Wait, wasn't 114689 adj entry the same used for 1.1.1.1?: MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef 1.1.1.1 de [snip...] Format:IPV4 (valid class vpn prefix) M(54 ): 1 F 2FFF 255.255.255.255 V(54 ): 1 0 0 1.1.1.1 (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0)
Jedes Paket mit einer Ziel-IP-Adresse, das über denselben Next Hop für die Datenverbindung verfügt, muss über dieselbe Schnittstelle weitergeleitet und mit denselben L2-Headern neu geschrieben werden.
Auch wenn dies zunächst ziemlich offensichtlich erscheint, ist es tatsächlich das wichtigste Element, einen CEF-Eintrag hinzuzufügen, Sie müssen ihm sagen, wie ein Paket mit einem bestimmten CEF-Adjacency-Eintrag umgeschrieben werden sollte.
Schritt 2: Angenommen, es wird kein ARP-Eintrag automatisch erstellt. Sie müssen also einen statischen ARP-Eintrag erstellen.
Dazu müssen Sie die MAC-Adresse des Geräts kennen, das als Next-Hop für das Präfix 10.1.2.1 verwendet wird, damit sie an 0c11.678b.f6f7 gesendet wird. Wenn in der Anzeige der MAC-Adresstabelle bereits ein Eintrag für die MAC-Adresse vorhanden ist 0c11.678b.f6f7-Befehlsausgabe, die in Ordnung ist, wenn nicht, dann müssen Sie einen statischen MAC-Eintrag erstellen:
MXC.CALO.Sup2T(config)#mac address-table static 0c11.678b.f6f7 vlan 2 int Gi3/21 Displaying entries from DFC switch [2] linecard [3]: vlan mac address type learn age ports ----+----+---------------+-------+-----+----------+----------------------------- 2 0c11.678b.f6f7 static No - Gi3/21
Schritt 3. Schließlich muss ein statischer ARP-Eintrag erstellt werden, damit ein CEF-Eintrag programmiert werden kann:
MXC.CALO.Sup2T(config)#arp 10.1.2.1 0c11.678b.f6f7 arpa <<< Static ARP configuration MXC.CALO.Sup2T#show ip arp 10.1.2.1 Protocol Address Age (min) Hardware Addr Type Interface Internet 10.1.2.1 - 0c11.678b.f6f7 ARPA <<< Now the static ARP entry is complete
// Attaching to DFC3...
MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef 10.1.2.1 detail [snip...] Format:IPV4 (valid class vpn prefix) M(53 ): 1 F 2FFF 255.255.255.255 V(53 ): 1 0 0 10.1.2.1 (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0)
The ARP entry exist in CEF table for DFC3. Same Adjacency Index result as before...
Nachdem Sie verstanden haben, was diese Adjacency-Einträge bewirken, können Sie endlich mit dem Hinzufügen eines CEF-Eintrags fortfahren. Im letzten Abschnitt wurde der CEF-Eintrag für das Präfix 1.1.1.1/32 mit dem Befehl test platform hardware cef v4-delete gelöscht. Fügen Sie ihn jetzt über den Befehl test platform hardware cef v4-insert [Präfix] [Maskenlänge] vpn [VPN-Nummer] adjacency [Adjacency-Index] zurück.
Um dies zu überprüfen, verwenden Sie den Befehl test platform hardware cef v4-insert 1.1.1.1 32 vpn 0 adjacency 14689. Der Eintrag wurde in der DFC-CEF-Tabelle wieder hinzugefügt:
MXC.CALO.Sup2T-sw2-dfc3#test platform hardware cef v4-insert 1.1.1.1 32 vpn 0 adjacency 114689 test_ipv4_insert: done: sw_index = 42 MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef vpn 0 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 54 1.1.1.1/32 Vl2 ,0c11.678b.f6f7 Ping from the 3750X to Loopback 0 is successful and HW forwarded by 6500 DFC. MXC.CALO.Sup2T-sw2-dfc3#show platform hard cef adj entry 114689 Index: 114689 -- Valid entry (valid = 1) -- RIT fields: The entry has a Layer2 Format _________________________________________________________ |decr_ttl=YES | l2_fwd=NO | ccc = 4 | add_shim_hdr = NO |_____________|____________|_________|____________________ Statistics: Packets = 684 Bytes = 80712
// Logs in 3850
CALO.MXC.385024XU#show logging [snip...] *Jan 23 05:59:56.911: ICMP: echo reply sent, src 1.1.1.1, dst 10.1.1.1, topology BASE, dscp 0 topoid 0 *Jan 23 05:59:57.378: ICMP: echo reply sent, src 1.1.1.1, dst 10.1.1.1, topology BASE, dscp 0 topoid 0 *Jan 23 05:59:57.390: ICMP: echo reply sent, src 1.1.1.1, dst 10.1.1.1, topology BASE, dscp 0 topoid 0
Während der Konfiguration aus allen vorherigen Schritten wurde die Zeichenfolge vpn 0 in den show platform hardware cef-Befehlen durchgesetzt. Auch wenn es völlig unnötig erscheint, da der Befehl standardmäßig die Einträge für die allgemeine Routing-Tabelle oder vpn 0 zurückgibt, wurde dies mit Absicht getan, um immer im Auge zu haben, dass Einträge von bestimmten Routing-Tabellen-Instanzen (VRFs) hinzugefügt oder gelöscht werden, durch das Dokument, das Sie hinzugefügt und gelöscht haben CEF-Eintrag 1.1.1.1/32. e. 10.x.x.x) ein, und löschen, hinzufügen oder ändern Sie einen CEF-Eintrag für eine falsche VRF kann negative Auswirkungen haben.
Löschen Sie einen CEF-Eintrag mit dem Präfix 1.1.1.1/32 für VRF TEST_VRF. Eine detaillierte Beschreibung der CEF-Einträge finden Sie im Abschnitt Add a CEF Entry (CEF-Eintrag hinzufügen) dieses Dokuments.
Um die VRF-Instanz hinzuzufügen, ändern Sie die SVIs in 6500 in die vorgeschlagene VRF-Instanz mit dem Befehl ip vrf forwarding [VRF-NAME], und fügen Sie schließlich die gleiche statische Route in die TEST_VRF-Tabelle ein:
MXC.CALO.Sup2T(config)#ip vrf TEST_VRF MXC.CALO.Sup2T(config-vrf)#int vlan 1 MXC.CALO.Sup2T(config-if)#ip vrf forwarding TEST_VRF % Interface Vlan1 IPv4 disabled and address(es) removed due to enabling VRF TEST_VRF MXC.CALO.Sup2T(config-if)#ip add 10.1.1.10 255.255.255.0 MXC.CALO.Sup2T(config-if)#int vlan 2 MXC.CALO.Sup2T(config-if)#ip vrf forwarding TEST_VRF % Interface Vlan2 IPv4 disabled and address(es) removed due to enabling VRF TEST_VRF MXC.CALO.Sup2T(config-if)#ip add 10.1.2.10 255.255.255.0 MXC.CALO.Sup2T(config)#ip route vrf TEST_VRF 1.1.1.1 255.255.255.255 10.1.2.1
MXC.CALO.Sup2T#show ip vrf
Name Default RD Interfaces
TEST_VRF <not set> Vl1
Vl2
Die VRFs werden ebenfalls sequenziell programmiert. Dies war die erste VRF-Instanz im Switch (zuvor wurde keine andere VRF-Instanz konfiguriert), daher sollte die VPN-Nummer für diese VRF-Instanz 1 lauten. Führen Sie den Befehl show platform hardware cef vpn 1 aus, um sicherzustellen, dass dies der Fall ist:
MXC.CALO.Sup2T-sw2-dfc3#show plat hard cef vpn 1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 34 10.1.1.10/32 receive 35 10.1.1.0/32 receive 36 10.1.1.255/32 receive 38 10.1.2.10/32 receive 43 10.1.2.0/32 receive 44 10.1.2.255/32 receive 53 10.1.2.1/32 Vl2 ,0c11.678b.f6f7 54 1.1.1.1/32 Vl2 ,0c11.678b.f6f7 [snip...] However, usually, switches have hundred or thousands of VRFs and just count them in the 'show ip vrf' command output would be quite difficult. In order to know which VPN number is assigned to a VRF we will run the command "show platform hardware cef vrf [VRF name] [prefix] detail", it will return the actual vpn number for that VRF: Format:IPV4 (valid class vpn prefix) M(54 ): 1 F 2FFF 255.255.255.255 V(54 ): 1 0 1 1.1.1.1 <<<<<<<<<<< The number in red determines the VPN this prefix belongs to. (A:114689, LS:0, NR:0, RI:0, DF:0 CP:0 DGTv:1, DGT:0)
Es ist wichtig, die tatsächliche VPN-Nummer und den Softwareindex für diesen Eintrag zu kennen, damit Sie mit dem Löschen oder Hinzufügen der Nummer zu dieser VRF-Instanz fortfahren können:
MXC.CALO.Sup2T-sw2-dfc3#test platform hardware cef index-conv hw_to_sw 54 hw index: 54 ----> sw handle: 42 MXC.CALO.Sup2T-sw2-dfc3#test platform hardware cef v4-delete 42 mask 32 vpn 1 test_ipv4_delete: done. Result: MXC.CALO.Sup2T-sw2-dfc3#show platform hardware cef vpn 1 lookup 1.1.1.1 Codes: decap - Decapsulation, + - Push Label Index Prefix Adjacency 262049 0.0.0.0/0 drop Traffic is now getting punted, and the effects are seen in the 3750X pings to 1.1.1.1: MXC.CALO.3750X#ping 1.1.1.1 repe 5000000 Sending 5000000, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!! [snip...]
// Packet loss
Beachten Sie, dass in einem Produktionsnetzwerk Paketverluste und abgehackte Audiodaten oder fehlerhafte Videos aufgrund dieser CEF-Eintragsbedingung auftreten. Daher wird empfohlen, diese Tests in einem Wartungsfenster durchzuführen.
Feedback