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.
Dieses Dokument beschreibt, wie der Cisco Catalyst 6500 mit Supervisor Sup2T die (Cisco Express Forwarding) CEF-Einträge programmiert, die in der Cisco IOS-Software in der Linecard-Hardware konfiguriert sind, die für die Paketweiterleitung verwendet wird.
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Cisco Catalyst Switches der Serie 6500
Die Informationen in diesem Dokument basieren auf den folgenden Hardware- und Softwareversionen:
Line Card für Cisco Catalyst 6500 WS-X6848-GE-TX (mit DFC4)
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
CEF wird von den meisten Cisco Multilayer-Switches als Layer-3-Switching-Mechanismus verwendet. Netzwerktechniker müssen die Funktionsweise von CEF kennen, um Netzwerkausfälle, Paketverluste oder Paketverzögerungen täglich zu beheben.
Der Sup2T-Supervisor im Standalone-Modus oder als VSS wird derzeit von vielen Unternehmensnetzwerken als Core-Switch bereitgestellt und fasst praktisch alle anderen Routing- oder Switching-Geräte zusammen. Dies bedeutet auch, dass der Großteil des Intra- und Inter-Domain-Datenverkehrs weitergeleitet wird, um die Pakete erfolgreich an seine Ziele zu senden. Um dies zu erreichen, muss Sup2T über die richtigen Routing-Informationen verfügen, die statisch oder dynamisch über Routing-Protokolle erfasst werden.
In einem modularen Chassis können neben dem Supervisor mehrere Weiterleitungs-Engines vorhanden sein. Bestimmte Linecards (insbesondere die neuen Linecards wie C6800-32P10G) beinhalten bereits eine eigene Weiterleitungs-Engine, um die Paketvermittlungsleistung zu erhöhen. Die Suche von CEF-Einträgen wird lokal ausgeführt und führt dazu, dass die Ressourcen für Datenverkehr, der über verschiedene Linecards eingeht, am besten verteilt werden. Diese Karten werden auch als DFCs bezeichnet.
Diese CEF-Einträge, die von allen Weiterleitungs-Engines gemeinsam verwendet werden, können in der HW aus mehreren Gründen nicht zugewiesen werden, z. B. aufgrund eines Softwarefehlers, einer Ressourcenerschöpfung bis hin zu hohen CPU-Bedingungen. Dadurch wird verhindert, dass der Switch genügend Zeit hat, 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
Im Diagramm enthält ein Standalone-Switch der Serie 6506 eine Supervisor 2T sowie eine Linecard WS-6848-GE-TX mit 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 des 3850.
Hierfür verfügt der 3750X über eine statische Route zur IP-Adresse 1.1.1.1 bis zum nächsten Hop 10.1.1.10. Dies ist die SVI von VLAN 1 im Sup2T-Switch. Der Sup2T-Switch muss diesen Datenverkehr über Next Hop 10.1.2.1 an den 3850-Switch weiterleiten, der in einem statischen Routeneintrag für IP 1.1.1.1/32 basiert. Dabei handelt es sich um die 3850-Schnittstelle, die mit der Sup2T in VLAN 2 verbunden ist.
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
Aus Gründen der Einfachheit sind sowohl 3750X- als auch 3850-Switches über dieselbe Linecard mit dem 6500 verbunden. Das bedeutet, dass der Datenverkehr lokal nachgeschlagen und auch lokal weitergeleitet wird.
Ein Paket empfängt 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 Ziel-IP-Adressfeld in diesem Paket und sucht nach den programmierten CEF-Einträgen für die beste Übereinstimmung (Longest Mask).
Da es sich um eine DFC-Karte handelt, bedeutet dies, dass sie über eigene CEF-Einträge verfügt und diese überprüft werden. Daher müssen wir die Linecard mit dem Befehl Attach [dec] oder Attach Switch [1-2] mod [dec] für VSS anschließen.
Jetzt sollten Sie sich in der DFC-Eingabeaufforderung befinden, den Befehl show platform hardware cef oder den Befehl show platform hardware cef vpn 0 aufrufen, um alle für die allgemeine Routing-Tabelle programmierten CEF-Einträge zurückzugeben (VPN 0/ No VRF).
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. Der Befehl gibt die beste Übereinstimmung für das Präfix 1.1.1.1 zurück, und der Befehl, der zum Weiterleiten von Datenverkehr verwendet wird:
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, er wurde programmiert als Ergebnis unseres statischen Eintrags in IOS-Software programmiert über Befehl ip route 1.1.1.1 255.255.255.255 10.1.2.1.
Sie können auch überprüfen, ob dieser Eintrag Treffer erhält und der Datenverkehr mit diesem Eintrag weitergeleitet wird. Verwenden Sie hierzu Befehle show platform hardware cef 1.1.1.1 detail, 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, wie das Paket neu geschrieben wird und ob der Datenverkehr durch diesen Adjacency-Eintrag umgeschrieben 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 <<<<
Die Werte dest_mac und src_mac sind die Werte von Hauptinteresse, 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, d. h. der 3850 (Next Hop bis 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
Außerdem zeigt das Statistics-Feld, dass der Datenverkehr tatsächlich auf diesen Adjacency-Eintrag trifft, und L2-Header werden entsprechend umgeschrieben.
Durch das Löschen von CEF-Einträgen können wir alle Einträge löschen, die falsch programmiert sind (z. B. zu einem falschen Adjacency-Eintrag) oder sogar zu Schulungszwecken. Sie bietet auch die Möglichkeit, einen Routing-Pfad zu ändern.
Um einen CEF-Eintrag zu löschen, müssen Sie verstehen, dass CEF-Einträge sequenziell programmiert sind und ein Hardware-Index zugewiesen ist, z. B.:
MXC.CALO.Sup2T-dfc3#show plattform hardware cef vpn 0
Codes: decap: Entkapselung, + - Push - Label
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, müssen diese in ein Software-Handle konvertiert werden. Dies können Sie mit dem Befehl test plattform 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
Nachdem Sie das Software-Handle kennen, können Sie mit dem Löschen des CEF-Eintrags fortfahren, indem Sie den Befehl test plattform hardware cef v4-delete [sw handle] mask [mask length] vpn [dec] verwenden.
MXC.CALO.s2TVSS-sw2-dfc3#test platform hardware cef v4-delete 101 mask 32 vpn 0 test_ipv4_delete: done.
Hinweis: 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 für die Testplattform-Hardware cef vpn 0 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. Bei der Weiterleitungs-Engine, aus der die Einträge entfernt werden, müssen Sie wirklich vorsichtig sein.
Bei einer Änderung des Datenverkehrs besteht das Risiko, dass keine Transparenz besteht (bei einem Labortest), dies kann auf den Treffer eines anderen CEF-Eintrags zurückzuführen sein. Achten Sie darauf, immer die exakteste zu finden (längste Maske). In dieser Übung trifft sie 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 Ziel 1.1.1.1, der über Linecard 3 eingeht, mit einem Shim-Header wieder in Umlauf gebracht und an die CPU geleitet. Manchmal wird anstelle dieses CEF-Eintrags eine weitere 0.0.0.0/0 mit Drop Adjaceny angezeigt, die genau dasselbe tut.
Hinweis: Evaluieren Sie, welche CEF-Einträge entfernt werden. Eine hohe CPU-Auslastung kann hierdurch verursacht werden. In der Regel wird eine Standardroute 0.0.0.0/0 konfiguriert, und der Datenverkehr wird entsprechend weitergeleitet (was zu Paketverlusten führt).
Beim Hinzufügen eines CEF-Eintrags werden in den meisten Fällen Probleme bei der Fehlprogrammierung behoben, die Paketverluste, Paketverzögerungen oder eine hohe CPU-Auslastung verursachen. Kenntnisse über die Installation der CEF-Einträge in der Hardware ermöglichen nicht nur das Korrigieren eines falsch programmierten Eintrags, sondern auch die Manipulation der Paketweiterleitung über Umleitung des Pakets, Verweisen auf eine komplett andere Schnittstelle oder den nächsten Hop, Umschreiben eines gerouteten Pakets nach Bedarf und/oder Verwerfen usw. All dies, ohne das Paket neu zu laden, die Konfiguration zu entfernen und festzulegen oder eine offensichtliche Änderung vorzunehmen. Der CEF-Eintrag Das Hinzufügen kann ohne den Konfigurationsmodus erfolgen. (Wie auch beim Verfahren zum Entfernen der CEF-Einreise, das im vorherigen Abschnitt erläutert wurde).
Grundsätzlich gibt es hier zwei Situationen, wenn Sie einen gültigen ARP-Eintrag zum nächsten Hop haben, in diesem Fall 10.1.2.1 und wenn nicht (aus irgendeinem Grund). In der zweiten Situation müssen Sie einen gültigen ARP-Eintrag erstellen (über statische ARP):
Schritt 1: Es gibt einen ARP-Eintrag im Switch 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 in der CEF-Tabelle als Hostroute ( /32 ) 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, die über denselben Next Hop für die Sicherungsverbindung verfügt, muss über dieselbe Schnittstelle weitergeleitet und mit denselben L2-Headern neu geschrieben werden.
Obwohl dies zunächst ziemlich offensichtlich erscheint, ist es eigentlich das wichtigste Element, einen CEF-Eintrag hinzuzufügen, müssen Sie ihm mitteilen, wie ein Paket mit einem bestimmten CEF Adjacency Entry umgeschrieben werden soll.
Schritt 2: Angenommen, es gibt dafür keinen automatisch erstellten ARP-Eintrag, daher müssen Sie 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. Daher wird es an 0c11.678b.f6f7 gesendet. Wenn in der Befehlsausgabe show mac address-table address 0c11.678b.f6f7 bereits ein Eintrag für die MAC-Adresse vorhanden ist, der in Ordnung ist, müssen Sie andernfalls 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 die Funktion dieser Adjacency-Einträge erkannt haben, können Sie endlich einen CEF-Eintrag hinzufügen. Im letzten Abschnitt wurde der CEF-Eintrag für das Präfix 1.1.1.1/32 durch den Befehl Testplattform Hardware cef v4-delete gelöscht. Jetzt fügen Sie es zurück durch den Befehl Test Plattform Hardware cef v4-insert [prefix] [Maskenlänge] vpn [VPN-Nummer] Adjacency [Adjacency-Index]
Verwenden Sie zur Überprüfung dieses Befehls den Befehl test plattform hardware cef v4-insert 1.1.1 32 vpn 0 adjacency 114689. Der Eintrag wurde wieder in die DFC CEF-Tabelle eingefü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
Bei der Konfiguration aus allen vorherigen Schritten wurde die VPN 0-Zeichenfolge in den Befehlen show platform hardware cef durchgesetzt. Auch wenn dies 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 absichtlich vorgenommen, um Beachten Sie immer, dass Einträge aus bestimmten VRF-Instanzen (Routing Table Instanzen) hinzugefügt oder gelöscht werden. Verwenden Sie dazu das Dokument, das Sie dem CEF-Eintrag 1.1.1.1/32 hinzugefügt und gelöscht haben. Bestimmte Präfixe sind jedoch sehr wahrscheinlich in verschiedenen VRFs vorhanden (d. h. e 10.x.x.x) und löschen, hinzufügen oder ändern Sie einen CEF-Eintrag für eine falsche VRF kann negative Auswirkungen verursachen.
Löschen Sie einen CEF-Eintrag mit dem Präfix 1.1.1.1/32 für VRF TEST_VRF. Eine detaillierte Beschreibung der Hinzufügung von CEF-Einträgen finden Sie im Abschnitt CEF-Eintrag hinzufügen in diesem Dokument.
Um die VRF-Instanz hinzuzufügen, ändern Sie die SVIs des 6500-Switches mit dem Befehl ip vrf forwarding [VRF-NAME] und fügen Sie schließlich die gleiche statische Route in unserer TEST_VRF-Tabelle hinzu:
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 auch sequenziell programmiert. Dies war die erste VRF-Instanz im Switch (zuvor wurde kein anderes VRF 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 zutrifft:
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 fortfahren können, ihn zu löschen oder von/zu dieser VRF-Instanz hinzuzufügen:
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
Bedenken Sie, dass in einem Produktionsnetzwerk Paketverluste und abgehackte Audiowiedergabe oder schlechtes Video aufgrund dieser CEF-Einträgen auftreten. Daher wird empfohlen, diese Tests in einem Wartungsfenster durchzuführen.