この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、スーパーバイザSup2Tを搭載したCisco Catalyst 6500が、パケット転送を実現するために使用されるラインカードハードウェアで、Cisco IOSソフトウェアに設定された(Cisco Express Forwarding)CEFエントリをプログラムする方法について説明します。
次の項目に関する知識があることが推奨されます。
Cisco Catalyst 6500 シリーズ スイッチ
このドキュメントの情報は、次のハードウェアとソフトウェアのバージョンに基づいています。
Cisco Catalyst 6500 WS-X6848-GE-TX(DFC4付き)ラインカード。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
レイヤ3スイッチングメカニズムとしてのCEFは、ほとんどのCiscoマルチレイヤスイッチで使用されています。ネットワークエンジニアにとっては、ネットワークの停止、パケット損失、またはパケット遅延が日常的に発生するシナリオをトラブルシューティングするために、CEFがどのように機能するかを理解する必要があります。
スタンドアロンモードまたはVSSのSup2Tスーパーバイザは現在、コアスイッチとして多くの企業ネットワークに導入されており、他のルーティングまたはスイッチングデバイスを実質的にすべて集約します。これはまた、パケットを宛先に正常に配信するために、ほとんどのドメイン内およびドメイン間トラフィックを転送することを意味します。これを実現するには、Sup2Tはルーティングプロトコルを介して静的または動的に学習された適切なルーティング情報を持っている必要があります。
モジュラシャーシでは、スーパーバイザの他に複数のフォワーディングエンジンが存在する場合があります。特定のラインカード(特にC6800-32P10Gなどの新世代のラインカード)には、パケット交換のパフォーマンスを向上させるために、独自のフォワーディングエンジンがすでに組み込まれています。CEFエントリのルックアップはローカルで実行され、異なるラインカードを介して入力されるトラフィックに対してリソースを最適に分散させます。
ソフトウェアの不具合状態、リソースの枯渇、CPU高使用状態など、すべてのフォワーディングエンジンで共有されるこれらのCEFエントリがHWでの割り当てに失敗する場合があり、すべてのエントリをアップデートするための十分な時間がスイッチにないと、一連の望ましくないイベントが発生する可能性があります。
ネットワーク:
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
この図では、スタンドアロンの6506スイッチに、スロット3にDFCを搭載したラインカードWS-6848-GE-TXと、Supervisor 2Tが取り付けられています。ポートG3/1を介してラインカードに接続されているホスト3750Xは、3850のLoopback 0アドレス1.1.1.1にトラフィックを送信します。
このため、3750Xには、Sup2TスイッチのVLAN 1のSVIであるネクストホップ10.1.1.10を経由するIPアドレス1.1.1.1へのスタティックルートがあります。Sup2Tスイッチは、VLAN 2のSup2Tに接続された3850インターフェイスであるネクストホップ10.1.2.1経由で、IP 1.1.1.1/32のスタティックルートエントリに基づいてこのトラフィックを3850スイッチにルーティングする必要があります。
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
簡単にするために、3750Xと3850の両方のスイッチが同じラインカードを介して6500に接続されていることに注意してください。これは、トラフィックがローカルで検索され、ローカルで転送されることを意味します。
パケットはGi3/1経由でSup2Tスイッチに入り、最終的にフォワーディングエンジンに到達します(これはDFCであるため)。 フォワーディングエンジンは、このパケットの宛先IPアドレスフィールドを解析し、最適な一致(最長マスク)を得るためにプログラムされたCEFエントリをルックアップします。
これはDFCカードであるため、独自のCEFエントリがあり、それを確認するためには、ラインカードにVSS用のコマンドattach [dec]またはattach switch [1-2] mod [dec]を使用して接続する必要があります。
これで、DFCプロンプトでshow platform hardware cef コマンドまたはshow platform hardware cef vpn 0コマンドを実行すると、一般的なルーティングテーブル(VPN 0/No VRF)用にプログラムされたCEFエントリがすべて返されます。
目的はプレフィクス1.1.1.1/32であるため、show platform hardware cef vpn 0 lookup 1.1.1.1コマンドを使用します。このコマンドは、プレフィクス1.1.1.1に最も一致するプレフィクスと、実際にトラフィックを転送するために使用するプレフィクスを返します。
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
CEFエントリがそこに存在し、コマンドip route 1.1.1.1 255.255.255.255 10.1.2.1を介してIOSソフトウェアにプログラムされたスタティックエントリの結果としてプログラムされました。
また、隣接関係エントリを返すshow platform hardware cef 1.1.1.1 detailコマンドを使用すると、このエントリがヒットを取得し、トラフィックが転送されることも確認できます。
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)
最後に、隣接関係エントリは、パケットの書き換え方法と、トラフィックがこの隣接関係エントリによって書き換えられるかどうかを示します。
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とsrc_macは主要な関心値で、このパケットに書き込まれる新しいL2ヘッダーを示しています。宛先MACアドレス0c11.678b.f6f7は10.1.2.1で、これは3850(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
また、Statisticsフィールドには、トラフィックが実際にこの隣接関係エントリにヒットしていて、それに従ってL2ヘッダーが書き換えられていることが示されています。
CEFエントリの削除は、誤って(たとえば、誤った隣接関係エントリに)プログラムされたエントリや、トレーニング目的のエントリの削除に役立ちます。また、ルーティングパスを変更する方法も提供します。
CEFエントリを削除するには、CEFエントリが順番にプログラムされ、ハードウェアインデックスが割り当てられていることを理解する必要があります。次に例を示します。
MXC.CALO.Sup2T-dfc3#show platform hardware cef vpn 0
コード: decap – カプセル化解除、+ – プッシュラベル
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.
...
CEFエントリは参照として使用されるため、このハードウェアインデックスはエントリを削除する上で最も重要な要素です。ただし、変更するには、ソフトウェアハンドルに変換する必要があります。これを行うには、test platform hardware cef index-conv hw_to_sw [hw index]コマンドを使用します。
MXC.CALO.Sup2T-dfc3#test platform hardware cef index-conv hw_to_sw 262 hw index: 262 ----> sw handle: 101
ソフトウェアハンドルが判明したので、コマンドtest platform hardware cef v4-delete [sw handle] mask [mask length] vpn [dec]を使用して、CEFエントリの削除を続行できます
MXC.CALO.s2TVSS-sw2-dfc3#test platform hardware cef v4-delete 101 mask 32 vpn 0 test_ipv4_delete: done.
注:マスク長の値は、ホスト固有のルート(1.1.1.1/32)であるため32です
これで、CEFエントリが削除されます。
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
DFCプロンプトでtest platform hardware cef vpn 0コマンドが実行されたことに注目してください。このように、CEFエントリはスーパーバイザからではなく、DFCのCEFテーブルから削除されています。エントリが削除されるフォワーディングエンジンに注意する必要があります。
トラフィックの変更は(ラボテストの場合は)可視化されないリスクがあり、これは別のCEFエントリのヒットが原因である可能性があります。常に最も正確なマスク(最長マスク)に一致することを考慮してください。 このラボでは、次のようにヒットします。
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
では、このエントリは実際にパケットをどのように処理するのでしょうか。
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
これで、ラインカード3を介して入力される宛先1.1.1.1のトラフィックはすべて、SHIMヘッダーで再循環され、CPUにパントされます。場合によっては、このCEFエントリの代わりに、drop隣接関係を持つ0.0.0.0/0が表示されて、まったく同じことを行います。
注:削除されるCEFエントリを評価します。これにより、CPU使用率が高くなる可能性があります。通常は、デフォルトルート0.0.0.0/0が設定され、それに基づいてトラフィックが転送されます(さらにパケット損失を引き起こします)。
CEFエントリが追加されると、ほとんどの場合、パケット損失、パケット遅延、または高CPU使用率を引き起こす誤プログラミングの問題が解決されます。ハードウェアにCEFエントリをインストールする方法の知識は、誤ってプログラムされたエントリを修正する機能を提供するだけでなく、パケットの再循環を介してパケット転送を操作する、まったく異なるインターフェイスまたはネクストホップを指し示す、必要に応じてルーテッドパケットを書き換える、ドロップする機能も提供します。これらはすべて、ボックスをリロードせずに、設定の削除と設定を行うか、明らかな変更を行います。CEFエントリの追加は、コンフィギュレーションモードに入らずに行うこともできます。(前のセクションで説明したCEFエントリの削除手順でも行ったように)。
基本的に、ネクストホップへの有効なARPエントリがある場合(この例では10.1.2.1)、ない場合(何らかの理由による)の2つの状況があります。 2番目の状況では、有効なARPエントリを実際に作成する必要があります(スタティックARPを使用)。
ステップ 1:10.1.2.1のスイッチには、1.1.1.1のネクストホップであるARPエントリがあります。
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
ARPエントリは、CEFテーブルでホストルート( /32 )としてプログラムされます。
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)
宛先IPアドレスが同じデータリンクのネクストホップを持つパケットはすべて、同じインターフェイス経由で転送され、同じL2ヘッダーで書き換えられる必要があります。
これは最初は明らかに見えるかもしれませんが、実際にはCEFエントリを追加する最も重要な要素です。特定のCEF隣接関係エントリを使用してパケットを書き換える方法を指示する必要があります。
ステップ 2ここで、これに対して自動的に作成されるARPエントリがないと仮定して、スタティックARPエントリを作成する必要があります。
これを行うには、プレフィックス10.1.2.1のネクストホップとして使用されているデバイスのMACアドレスを知る必要があるため、このアドレスが0c11.678b.f6f7に送信されます。show mac address-table address 0c11.678b.f6f7コマンド出力にMACアドレスエントリがすでに存在し、それが正常である場合は、スタティックMACエントリを作成する必要があります。
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
ステップ 3最後に、CEFエントリをプログラムするために、スタティックARPエントリを作成する必要があります。
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...
これらの隣接関係エントリの機能を理解したので、最後にCEFエントリの追加に進みます。最後のセクションでは、プレフィクス1.1.1.1/32のCEFエントリが、test platform hardware cef v4-deleteコマンドで削除されています。次に、コマンドtest platform hardware cef v4-insert [prefix] [mask length] vpn [vpn number] adjacency [adjacency index]を使用して、このアドレスを追加し直します
これを確認するには、test platform hardware cef v4-insert 1.1.1.1 32 vpn 0 adjacency 114689コマンドを使用します。エントリがDFC CEFテーブルに再び追加されました。
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
前のすべてのステップで行った設定により、show platform hardware cefコマンド内のvpn 0ストリングが適用されています。このコマンドはデフォルトで汎用ルーティングテーブルまたはvpn 0のエントリを返すため、まったく不要のように思われる場合でも、特定のルーティングテーブルインスタンス(VRF)に対して、CEFエントリ1.1.1.1/32を追加および削除したドキュメントを通じてエントリが常に追加または削除されることを念頭に置いて、意図的に行われました。ただし、特定のプレフィックスは異なるVRF(10.x.x.x)に存在する可能性が高く、誤ったVRFのCEFエントリを削除、追加、または変更すると、悪影響を及ぼす可能性があります。
VRF TEST_VRFに対するプレフィクス1.1.1.1/32のCEFエントリを削除します。CEFエントリの追加の詳細については、このドキュメントの「CEFエントリの追加」セクションを参照してください。
VRFを追加するには、ip vrf forwarding [VRF-NAME]コマンドを使用して、6500スイッチのSVIを提示されたVRFに変更し、最後にTEST_VRFテーブルに同じスタティックルートを追加します。
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
VRFも順番にプログラムされます。これはスイッチ内の最初のVRFであるため(他のVRFは以前に設定されていません)、このVRFインスタンスのVPN番号は1である必要があります。show platform hardware cef vpn 1コマンドを実行して、これが正しいことを確認します。
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)
このエントリの実際のVPN番号とソフトウェアインデックスを知っておくことが重要です。そうすれば、このエントリを削除したり、このVRFインスタンスでエントリを追加したりすることができます。
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
実稼働ネットワークでは、これらのCEFエントリ状態が原因で、パケット損失や音声の途切れ、あるいはビデオの品質低下が発生していると考えてください。したがって、これらのテストはメンテナンス時間帯に実行することを推奨します。
フィードバック