Catalyst 9000 DHCP リレーエージェントでの DHCP の問題のトラブルシューティング
はじめに
このドキュメントでは、DHCP リレーエージェントとしての Catalyst 9000 スイッチでの低速または断続的な DHCP アドレス割り当て障害をトラブルシューティングする方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Dynamic Host Configuration Protocol（DHCP）および DHCP リレーエージェント
- インターネット制御メッセージ プロトコル（ICMP）
- コントロール プレーン ポリシング（CoPP）
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Catalyst 9000 シリーズ スイッチ
- Cisco IOS® XE バージョン 16.x および 17.x
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
関連製品
このドキュメントは、次のバージョンのハードウェアとソフトウェアにも使用できます。
- Catalyst 3650/3850 シリーズ スイッチと Cisco IOS XE 16.x
バックグラウンド情報
このドキュメントでは、DHCP リレーエージェントとして、Catalyst 9000 シリーズ スイッチで低速の Dynamic Host Configuration Protocol（DHCP）アドレス割り当て障害または断続的な DHCP アドレス割り当て障害をトラブルシューティングする方法について説明します。
コントロール プレーン ポリシング（CoPP）機能は、不要なトラフィックおよび Denial of Service（DoS）攻撃から CPU を保護することでデバイスのセキュリティを向上させます。また、他の優先順位の低い大量のトラフィックによって発生するトラフィックのドロップから、制御トラフィックおよび管理トラフィックを保護することもできます。
デバイスは通常、3 つの操作プレーンにセグメント化され、それぞれに独自の目的があります。
- データ パケットを転送するための、データ プレーン。
- データを適切にルーティングするための、コントロール プレーン。
- ネットワーク要素を管理するための、管理プレーン。
CoPP を使用することで、大半の CPU 行きトラフィックを保護し、ルーティングの安定性と信頼性を確保し、パケットを確実に配信することができます。特に重要なのは、DoS 攻撃から CPU を保護するために CoPP を使用できることです。
CoPP は、モジュラ QoS コマンドライン インターフェイス（MQC）および CPU キューを使用して、これらの目的を達成します。さまざまなタイプのコントロール プレーン トラフィックが特定の条件に基づいてグループ化され、CPU キューに割り当てられます。ハードウェアに専用のポリサーを設定することで、これらの CPU キューを管理できます。たとえば、特定の CPU キュー（トラフィック タイプ）のポリサー レートを変更したり、特定のタイプのトラフィックに対するポリサーを無効にしたりできます。
ポリサーはハードウェアに設定されていますが、CoPP は CPU のパフォーマンスやデータ プレーンのパフォーマンスには影響しません。CPUに向かうパケットの数が制限されるため、CPUの負荷が制御されます。つまり、ハードウェアからのパケットを待機するサービスは、制御されたレートの入力パケットを参照できます（レートはユーザが設定できます）。
問題
ip helper-address コマンドがルーテッドインターフェイスまたは SVI で設定されている場合、Catalyst 9000 スイッチは DHCP リレーエージェントとして設定されます。ヘルパーアドレスが設定されているインターフェイスは、通常、ダウンストリーム クライアントのデフォルトゲートウェイです。スイッチがクライアントに正常なDHCPリレーサービスを提供するには、着信DHCP Discoverメッセージを処理する必要があります。これには、スイッチが DHCP Discover メッセージを受信し、このパケットを CPU にパントして処理する必要があります。DHCP Discover を受信および処理すると、リレーエージェントは、DHCP Discover を受信したインターフェイスを送信元とし、ip helper-address 設定で定義されている IP アドレスを宛先とする、新しいユニキャストパケットを作成します。パケットが作成されると、ハードウェアによって転送され、DHCPサーバに送信されます。DHCPサーバでは、パケットを処理してリレーエージェントに返送できるため、DHCPプロセスをクライアントに対して続行できます。
よくある問題として、リレーエージェントの DHCP トランザクションパケットが、CPU に送信されるトラフィックによって意図せずに影響を受けることがあります。これは、ICMP リダイレクトまたは ICMP 宛先到達不能メッセージなどの特定の ICMP シナリオの対象であるためです。この動作は、クライアントがDHCPからIPアドレスをタイムリーに受信できない、またはDHCP割り当ての失敗の合計が発生する、という形で現れる可能性があります。シナリオによっては、ネットワークの負荷が完全に最大になる業務時間のピークなど、特定の時間帯にのみ動作を確認できます。
「背景説明」のセクションで説明したように、Catalyst 9000 シリーズ スイッチにはデフォルトの CoPP ポリシーが設定され、デバイス上で有効になっています。この CoPP ポリシーは Quality of Service（QoS）ポリシーとして機能し、前面パネルのポートで受信してデバイスの CPU に送られるトラフィックのパスに配置されます。ポリシーで設定されているトラフィックタイプと事前定義されたしきい値に基づいて、トラフィックをレート制限します。デフォルトで分類されレート制限されるトラフィックの例としては、ルーティング制御パケット（通常は DSCP CS6 とマークされます）、トポロジ制御パケット（STP BPDU）、低遅延パケット（BFD）などがあります。 これらのパケットは、確実に処理できるため、安定したネットワーク環境が得られるため、優先順位を付ける必要があります。
show platform hardware fed switch active qos queue stats internal cpu policer コマンドを使用して、CoPP ポリサー統計を確認します。
ICMP リダイレクトキュー（キュー 6）とブロードキャストキュー（キュー 12）は、同じ PlcIdx 0（ポリサーインデックス）を共有します。 つまり、DHCP Discoverなど、デバイスのCPUで処理する必要があるブロードキャストトラフィックは、ICMPリダイレクトキュー内のデバイスのCPU宛てのトラフィックと共有されます。その結果、前述した問題が発生し、ICMPリダイレクトキューによってBROADCASTキューで処理する必要のあるトラフィックが枯渇し、正当なブロードキャストパケットがドロップされるためにDHCPトランザクションが失敗することがあります。
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
--------------------------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0 0
1 1 L2 Control Yes 2000 2000 0 0
2 14 Forus traffic Yes 4000 4000 0 0
3 0 ICMP GEN Yes 600 600 0 0
4 2 Routing Control Yes 5400 5400 0 0
5 14 Forus Address resolution Yes 4000 4000 0 0
6 0 ICMP Redirect Yes 600 600 0 0 <-- Policer Index 0
7 16 Inter FED Traffic Yes 2000 2000 0 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0 0
9 19 EWLC Control Yes 13000 13000 0 0
10 16 EWLC Data Yes 2000 2000 0 0
11 13 L2 LVX Data Pack Yes 1000 1000 0 0
12 0 BROADCAST Yes 600 600 0 0 <-- Policer Index 0
13 10 Openflow Yes 200 200 0 0
14 13 Sw forwarding Yes 1000 1000 0 0
15 8 Topology Control Yes 13000 16000 0 0
16 12 Proto Snooping Yes 2000 2000 0 0
17 6 DHCP Snooping Yes 500 500 0 0
18 13 Transit Traffic Yes 1000 1000 0 0
19 10 RPF Failed Yes 250 250 0 0
20 15 MCAST END STATION Yes 2000 2000 0 0
<snip>
CoPPポリシーでデフォルトの600パケット/秒レートを超えるトラフィックは、CPUに到達する前にドロップされます。
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
--------------------------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0 0
1 1 L2 Control Yes 2000 2000 0 0
2 14 Forus traffic Yes 4000 4000 0 0
3 0 ICMP GEN Yes 600 600 0 0
4 2 Routing Control Yes 5400 5400 0 0
5 14 Forus Address resolution Yes 4000 4000 0 0
6 0 ICMP Redirect Yes 600 600 3063106173577 3925209161 <-- Dropped packets in queue
7 16 Inter FED Traffic Yes 2000 2000 0 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0 0
9 19 EWLC Control Yes 13000 13000 0 0
10 16 EWLC Data Yes 2000 2000 0 0
11 13 L2 LVX Data Pack Yes 1000 1000 0 0
12 0 BROADCAST Yes 600 600 1082560387 3133323 <-- Dropped packets in queue
13 10 Openflow Yes 200 200 0 0
14 13 Sw forwarding Yes 1000 1000 0 0
15 8 Topology Control Yes 13000 16000 0 0
16 12 Proto Snooping Yes 2000 2000 0 0
17 6 DHCP Snooping Yes 500 500 0 0
18 13 Transit Traffic Yes 1000 1000 0 0
19 10 RPF Failed Yes 250 250 0 0
20 15 MCAST END STATION Yes 2000 2000 0 0
<snip>
シナリオ 1：ICMP リダイレクト
最初のシナリオでは次のトポロジについて考えます。
イベントのシーケンスは次のとおりです。
1. 10.10.10.100 のユーザーが、リモートネットワークである 10.100.100.100 のデバイスに Telnet 接続を開始します。
2. 宛先IPは異なるサブネットにあるため、パケットはユーザのデフォルトゲートウェイ10.10.10.15に送信されます。
3. Catalyst 9300 は、ルーティング対象のこのパケットを受信すると、パケットを CPU にパントして ICMP リダイレクトを生成します。
ICMPリダイレクトが生成される理由は、9300スイッチから見ると、ラップトップがこのパケットを10.10.10.1のルータに直接送信する方が効率的であるためです。このルータはCatalyst 9300のネクストホップであり、ユーザが所属するVLANと同じVLANにあるためです。
問題は、ICMPリダイレクト基準を満たしているため、フロー全体がCPUで処理されることです。ICMPリダイレクトシナリオに一致する他のデバイスからトラフィックが送信されると、このキュー内のCPUにさらに多くのトラフィックがパントされ始めます。これらのデバイスは同じCoPPポリサーを共有するため、ブロードキャストキューに影響を与える可能性があります。
ICMPリダイレクトsyslogを表示するには、ICMPをデバッグします。
9300-Switch#debug ip icmp <-- enables ICMP debugs
ICMP packet debugging is on
9300-Switch#show logging | inc ICMP
*Sep 29 12:41:33.217: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:41:33.218: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:41:33.219: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:41:33.219: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:43:08.127: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:09.517: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:10.017: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1 <-- ICMP Redirect to use 10.10.10.1 as Gateway
*Sep 29 12:50:14.293: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:19.053: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:23.797: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:28.537: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:33.284: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
注意：規模の大小に関係なく、ICMPデバッグを有効にする前に、コンソールロギングとターミナルモニタリングを無効にすることをお勧めします。
Catalyst 9300 CPU の組み込みパケットキャプチャは、CPU での Telnet 接続の初期 TCP SYN と、生成された ICMP リダイレクトを表示します。
ICMPリダイレクトパケットの送信元は、クライアントを宛先とするCatalyst 9300 VLAN 10インターフェイスであり、ICMPリダイレクトパケットが送信される元のパケットヘッダーが含まれています。
ソリューション
このシナリオでは、CPU にパントされるパケットを防止でき、これにより ICMP リダイレクトパケットの生成も停止されます。最近のオペレーティングシステムでは、ICMPリダイレクトメッセージを使用しないため、これらのパケットの生成、送信、および処理に必要なリソースは、ネットワークデバイス上のCPUリソースを効率的に使用するものではありません。
または、デフォルトゲートウェイ10.10.10.1を使用するようにユーザに指示しますが、このような設定は何らかの理由で使用される可能性があるため、このドキュメントでは説明しません。
no ip redirects CLIを使用してICMPリダイレクトを無効にするだけです。
9300-Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
9300-Switch(config)#interface vlan 10
9300-Switch(config-if)#no ip redirects <-- disable IP redirects
9300-Switch(config-if)#end
ICMPリダイレクトがインターフェイスで無効になっていることを確認します。
9300-Switch#show ip interface vlan 10
Vlan10 is up, line protocol is up
Internet address is 10.10.10.15/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.102
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is BLOCK-TELNET
Proxy ARP is disabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are never sent <-- redirects disabled
ICMP unreachables are never sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
<snip>
ICMPリダイレクトおよびICMPリダイレクトが送信されるタイミングについての詳細は、「ICMPリダイレクトが送信される条件」を参照してください。
シナリオ 2：ICMP 到達不能
同じトポロジで、10.10.10.100 のユーザーが 10.100.100.100 に Telnet 接続を開始する場合について考えます。今回は、VLAN 10 SVI 上でアクセスリストがインバウンドに設定されており、これが Telnet 接続をブロックします。
9300-Switch#show running-config interface vlan 10
Building Configuration..
Current Configuration : 491 bytes
!
interface Vlan10
ip address 10.10.10.15 255.255.255.0
no ip proxy-arp
ip access-group BLOCK-TELNET in <-- inbound ACL
end
9300-Switch#
9300-Switch#show ip access-list BLOCK-TELNET
Extended IP access list BLOCK-TELNET
10 deny tcp any any eq telnet <-- block telnet
20 permit ip any any
9300-Switch#
イベントのシーケンスは次のとおりです。
1. 10.10.10.100 のユーザーが 10.100.100.100 のデバイスに Telnet 接続を開始します。
2. 宛先IPは異なるサブネットにあるため、パケットはユーザのデフォルトゲートウェイに送信されます。
3. Catalyst 9300がこのパケットを受信すると、インバウンドACLに照らして評価され、ブロックされます。
4. パケットがブロックされ、インターフェイスでIP到達不能が有効になっているため、パケットはCPUにパントされ、デバイスはICMPの「destination unreachable」パケットを生成できます。
ICMP destination unreachable syslogを表示するには、ICMPをデバッグします。
9300-Switch#debug ip icmp <-- enables ICMP debugs
ICMP packet debugging is on
9300-Switch#show logging | include ICMP
<snip>
*Sep 29 14:01:29.041: ICMP: dst (10.100.100.100) administratively prohibited unreachable sent to 10.10.10.100 <-- packet blocked and ICMP message sent to client
注意：規模の大小に関係なく、ICMPデバッグを有効にする前に、コンソールロギングとターミナルモニタリングを無効にすることをお勧めします。
Catalyst 9300 CPU の組み込みパケットキャプチャは、CPU での Telnet 接続の初期 TCP SYN と、送信された ICMP 宛先到達不能を表示します。
ICMP宛先到達不能パケットの送信元は、クライアントを宛先とするCatalyst 9300 VLAN 10インターフェイスで、ICMPパケットが送信される元のパケットヘッダーが含まれています。
ソリューション
このシナリオでは、ACLによってブロックされているパントされたパケットがICMP宛先到達不能メッセージを生成する動作を無効にします。
IP 到達不能機能は、Catalyst 9000 シリーズ スイッチのルーテッドインターフェイスでデフォルトで有効になっています。
9300-Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
9300-Switch(config)#interface vlan 10
9300-Switch(config-if)#no ip unreachables <-- disable IP unreachables
インターフェイスで無効になっていることを確認します。
9300-Switch#show ip interface vlan 10
Vlan10 is up, line protocol is up
Internet address is 10.10.10.15/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.102
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is BLOCK-TELNET
Proxy ARP is disabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are never sent
ICMP unreachables are never sent <-- IP unreachables disabled
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
<snip>
シナリオ 3：ICMP TTL-Exceeded
前の2つのシナリオで使用した以前のトポロジを検討します。今回は、10.10.10.100のユーザが、その後使用停止になったネットワーク内のリソースに到達しようとします。このため、このネットワークをホストするために使用されていた SVI と VLAN は Catalyst 9300 で指定されていません。ただし、ルータには、このネットワークのネクストホップとして Catalyst 9300 VLAN 10 インターフェイスを指すスタティックルートがまだあります。
Catalyst 9300にはこのネットワークが設定されていないため、直接接続として表示されず、9300は10.10.10.1のルータを指すスタティックデフォルトルートへの特定のルートを持たないパケットをルーティングします。
この動作により、ユーザーが 192.168.10.0/24 アドレス空間のリソースに接続しようとすると、ネットワークにルーティングループが発生します。パケットは、TTL が期限切れになるまで 9300 とルータの間でループします。
1. ユーザーが192.168.10/24ネットワーク上のリソースに接続を試みる
2. Catalyst 9300で受信されたパケットは、ネクストホップが10.10.10.1のデフォルトルートにルーティングされ、TTLを1だけデクリメントします。
3. ルータはこのパケットを受信し、ルーティングテーブルをチェックして、ネクストホップが10.10.10.15であるこのネットワークへのルートを見つけます。TTL が 1 だけ減り、パケットが 9300 にルーティングされます。
4. Catalyst 9300 はパケットを受信すると、パケットを 10.10.10.1 に再度ルーティングして、TTL を 1 減らします。
このプロセスは、IP TTL がゼロに達するまで繰り返されます。
Catalystは、IP TTL = 1のパケットを受信すると、そのパケットをCPUにパントし、ICMP TTL-Exceededメッセージを生成します。
ICMP パケットタイプは 11、コードは 0 です（TTL は送信中に期限切れとなります）。 このパケットタイプは、CLIコマンドでは無効にできません
このシナリオでは、DHCP トラフィックの問題が発生します。その理由は、ループされたパケットは、受信されたインターフェイスと同じインターフェイスから送信されるため、ICMP リダイレクトの対象となるからです。ユーザーから送信されたパケットも、ICMP リダイレクトの対象になります。このシナリオでは、DHCP トラフィックをブロードキャストキューから簡単に消費することができます。大規模環境では、リダイレクトキューにパントされるパケットの数が多いため、このシナリオはさらに悪化します。
ここで、CoPP ドロップは、各 ping 間のタイムアウトを 0 秒として、192.168.10.0/24 ネットワークへの 1000 回の ping を介して示されています。9300 の CoPP 統計情報は、ping が送信される前にクリアされ、ゼロバイトでドロップされます。
9300-Switch#clear platform hardware fed switch active qos statistics internal cpu policer <-- clear CoPP stats
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer | i Redirect|Drop <-- verify 0 drops
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
6 0 ICMP Redirect Yes 600 600 0 0 <-- bytes dropped 0
<snip>
ユーザがリモートネットワークにトラフィックを送信します。
User#ping 192.168.10.10 timeout 0 rep 1000 <-- User sends 1000 pings
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 192.168.10.10, timeout is 0 seconds:
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
....................
Success rate is 0 percent (0/1000)
ICMPデバッグは、ルーティングループが原因で発生したリダイレクトおよびTTL超過syslogを示します。
9300-Switch#debug ip icmp
ICMP packet deubgging is on
*Sep 29 16:33:22.676: ICMP: redirect sent to 10.10.10.100 for dest 192.168.10.10, use gw 10.10.10.1 <-- redirect sent
*Sep 29 16:33:22.678: ICMP: time exceeded (time to live) sent to 10.10.10.100 (dest was 192.168.10.10), topology BASE, dscp 0 topoid 0 <-- TTL exceeded observed
*Sep 29 16:33:22.678: ICMP: time exceeded (time to live) sent to 10.10.10.100 (dest was 192.168.10.10), topology BASE, dscp 0 topoid 0
*Sep 29 16:33:22.678: ICMP: time exceeded (time to live) sent to 10.10.10.100 (dest was 192.168.10.10), topology BASE, dscp 0 topoid 0
<snip>
注意：規模の大小に関係なく、ICMPデバッグを有効にする前に、コンソールロギングとターミナルモニタリングを無効にすることをお勧めします。
CoPPドロップは、リダイレクトのためにCPUにパントされたトラフィック量が原因で発生します（これは単一のクライアントに対してのみです）。
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
--------------------------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0 0
1 1 L2 Control Yes 2000 2000 0 0
2 14 Forus traffic Yes 4000 4000 0 0
3 0 ICMP GEN Yes 600 600 0 0
4 2 Routing Control Yes 5400 5400 0 0
5 14 Forus Address resolution Yes 4000 4000 0 0
6 0 ICMP Redirect Yes 600 600 15407990 126295 <-- drops in redirect queue
7 16 Inter FED Traffic Yes 2000 2000 0 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0 0
<snip>
ソリューション
このシナリオの解決策は、シナリオ 1 と同様に ICMP リダイレクトを無効にすることです。ルーティングループの問題もありますが、パケットがリダイレクト用にもパントされるため、強度がさらに高まります。
TTL が 1 のときに ICMP TTL-Exceeded パケットもパントされますが、これらのパケットは異なる CoPP ポリサーインデックスを使用し、ブロードキャストとキューを共有しないため、DHCP トラフィックは影響を受けません。
no ip redirects CLIを使用してICMPリダイレクトを無効にします。
9300-Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
9300-Switch(config)#interface vlan 10
9300-Switch(config-if)#no ip redirects <-- disable IP redirects
9300-Switch(config-if)#end
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
3.0 |
17-Jun-2026
|
スペルチェック、文章校正、パンチダウン、代替テキスト、スペースの更新 |
2.0 |
20-Oct-2023
|
再認定 |
1.0 |
30-Sep-2021
|
初版 |
フィードバック