Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Netzwerkdiagramm

Identifizieren von CEF-Einträgen über verteilte Weiterleitungs-Engines

Löschen von CEF-Einträgen

CEF-Eintrag hinzufügen

Hinzufügen und Löschen von Einträgen für VRF-Routing-Tabellen

Einführung

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.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

- Cisco Express Forwarding (CEF)

- Cisco Catalyst Switches der Serie 6500

- Cisco Distributed Forwarding Card (DFC)

Verwendete Komponenten

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)

- Cisco Catalyst 6500 mit Supervisor 2T auf IOS Version 15.2.1SY5

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.

Hintergrundinformationen

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.

Netzwerkdiagramm

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

Identifizieren von CEF-Einträgen über verteilte Weiterleitungs-Engines

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.

Löschen von CEF-Einträgen

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).

CEF-Eintrag hinzufügen

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

Hinzufügen und Löschen von Einträgen für VRF-Routing-Tabellen

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.