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
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
関連製品
このドキュメントは、次のバージョンのハードウェアとソフトウェアにも使用できます。
- Cisco IOS XE 16.xを搭載したCatalyst 3650/3850シリーズスイッチ
背景説明
このドキュメントでは、DHCPリレーエージェントであるCatalyst 9000シリーズスイッチでDynamic Host Configuration Protocol(DHCP)アドレスの割り当てが低速であるか、または断続的にDHCPアドレスの割り当てが失敗する問題をトラブルシューティングする方法について説明します。
Control Plane Policing(CoPP)機能は、不要なトラフィックやDenial of Service(DoS)攻撃からCPUを保護することで、デバイスのセキュリティを向上させます。また、大量の他の優先度の低いトラフィックによって引き起こされるトラフィックドロップから、制御トラフィックと管理トラフィックを保護することもできます。
デバイスは通常、3つの運用面に分割され、それぞれに独自の目的があります。
- データパケットを転送するためのデータプレーン。
- コントロールプレーン。データを正しくルーティングします。
- ネットワーク要素を管理するための管理プレーン。
CoPPを使用すると、CPUに送られるほとんどのトラフィックを保護し、ルーティングの安定性、到達可能性、およびパケット配信を確保できます。最も重要なことは、CoPPを使用してCPUをDoS攻撃から保護できることです。
CoPPは、モジュラQoSコマンドラインインターフェイス(MQC)とCPUキューを使用してこれらの目的を達成します。さまざまなタイプのコントロールプレーントラフィックが特定の基準に基づいてグループ化され、CPUキューに割り当てられます。これらのCPUキューは、ハードウェアの専用ポリサーを設定することで管理できます。たとえば、特定のCPUキュー（トラフィックタイプ）のポリサーレートを変更したり、特定のトラフィックタイプのポリサーを無効にしたりできます。
ポリサーはハードウェアで設定されますが、CoPPはCPUパフォーマンスやデータプレーンのパフォーマンスには影響しません。ただし、CPUに向かうパケットの数が制限されるため、CPUの負荷が制御されます。つまり、ハードウェアからのパケットを待機するサービスは、制御されたレートの入力パケットを参照できます（レートはユーザが設定できます）。
問題
Catalyst 9000スイッチは、ルーテッドインターフェイスまたはSVI上でip helper-addressコマンドが設定された場合に、DHCPリレーエージェントとして設定されます。ヘルパーアドレスが設定されているインターフェイスは、通常、ダウンストリームクライアントのデフォルトゲートウェイです。スイッチがクライアントに正常なDHCPリレーサービスを提供するためには、着信DHCP Discoverメッセージを処理できる必要があります。このためには、スイッチがDHCP Discoverを受信し、このパケットをCPUにパントして処理する必要があります。DHCP Discoverを受信して処理すると、リレーエージェントによって、DHCP Discoverを受信したインターフェイスを送信元とし、ip helper-address設定で定義されているIPアドレスを宛先とする、新しいユニキャストパケットが作成されます。パケットが作成されると、ハードウェアによって転送され、DHCPサーバに送信されます。DHCPサーバではパケットを処理でき、最終的にリレーエージェントに送信されて、クライアントに対するDHCPプロセスを続行できます。
一般的な問題として、リレーエージェントのDHCPトランザクションパケットが、ICMPリダイレクトやICMP宛先到達不能メッセージなどの特定のICMPシナリオの対象となるため、CPUに送信されるトラフィックの影響を受けないことが挙げられます。この動作は、クライアントがDHCPからIPアドレスをタイムリーに取得できない、またはDHCP割り当ての失敗の合計として現れる可能性があります。ネットワークの負荷が完全に最大になる業務時間のピークなど、特定の時間帯にのみ動作を確認できるシナリオもあります。
「背景説明」セクションで説明したように、Catalyst 9000シリーズスイッチには、デバイス上で設定されイネーブルにされたデフォルトのCoPPポリシーが付属しています。このCoPPポリシーは、フロントパネルポートで受信され、デバイスのCPUを宛先とするトラフィックのパスに配置されるQuality of Service(QoS)ポリシーとして機能します。トラフィックタイプと、ポリシーで設定された事前定義されたしきい値に基づいて、トラフィックをレート制限します。デフォルトで分類され、レート制限されるトラフィックの例としては、ルーティング制御パケット（通常はDSCP CS6でマーキングされる）、トポロジ制御パケット(STP BPDU)、低遅延パケット(BFD)などがあります。 これらのパケットを確実に処理できれば、安定したネットワーク環境が得られるため、パケットに優先順位を付ける必要があります。
show platform hardware fed switch active qos queue stats internal cpu policerコマンドを使用して、CoPPポリサーの統計情報を表示します。
ICMPリダイレクトキュー（キュー6）とBROADCASTキュー（キュー12）の両方が、同じPlcIdx 0（ポリサーインデックス）を共有します。 つまり、デバイスのCPUで処理する必要があるブロードキャストトラフィック（DHCP Discoverなど）は、ICMPリダイレクトキューでデバイスのCPU宛てのトラフィックと共有されます。その結果、前述した問題が発生し、ICMPリダイレクトキュートラフィックによってブロードキャストキューによる処理が必要なトラフィックが枯渇し、正当なブロードキャストパケットがドロップされるために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と同じであるためです。
問題は、ICMPリダイレクト基準を満たしているため、フロー全体がCPUで処理されることです。他のデバイスがICMPリダイレクトシナリオを満たす送信トラフィックである場合、さらに多くのトラフィックがこのキュー内のCPUにパントされ始めます。これらのデバイスは同じCoPPポリサーを共有しているため、ブロードキャストキューに影響を与える可能性があります。
ICMPをデバッグして、ICMPリダイレクトsyslogを表示します。
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
Catalyst 9300 CPUのEmbedded Packet Capture(EPC)は、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リダイレクトの送信時期の詳細については、次のリンクを参照してください。https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13714-43.html
シナリオ2:ICMP到達不能
10.10.10.100のユーザが10.100.100.100へのTelnet接続を開始する場合と同じトポロジについて考えます。今回は、Telnet接続をブロックするアクセスリストがVLAN 10 SVIのインバウンドに設定されています。
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到達不能が有効になっているため、デバイスがICMP宛先到達不能パケットを生成できるように、パケットはCPUにパントされます。
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
Catalyst 9300 CPUでのEmbedded Packet Captureは、CPUでのTelnet接続の初期TCP SYNと、送信されるICMP Destination Unreachableを示します。
ICMP宛先到達不能パケットの送信元は、クライアントを宛先とするCatalyst 9300 VLAN 10インターフェイスであり、ICMPパケットの送信先である元のパケットヘッダーが含まれています。
解決方法
このシナリオでは、ICMP宛先到達不能メッセージを生成するために、ACLによってブロックされるパントされたパケットの動作を無効にします。
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超過
前の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メッセージを生成します。
コード0のICMPパケットタイプは11です（TTLが送信中に期限切れになりました）。 このパケットタイプは、CLIコマンドでは無効にできません
このシナリオでは、DHCPトラフィックに関する問題が関係します。これは、ループされたパケットは、受信されたインターフェイスと同じインターフェイスを外部に持たないため、ICMPリダイレクションの影響を受けるためです。
ユーザから送信されたパケットもICMPリダイレクションの対象になります。このシナリオでは、DHCPトラフィックはBROADCASTキューから簡単に枯渇します。規模の面では、リダイレクトキューにパントされたパケットの数が多いため、このシナリオはさらに悪くなります。
ここでは、192.168.10.0/24ネットワークに対して1000回のpingを実行し、ping間のタイムアウトを0秒としてCoPPドロップを示します。9300のCoPP統計情報はクリアされ、0バイトでドロップされた後に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>
リダイレクトのためにCPUにパントされたトラフィック量が原因で、CoPPドロップが発生します。これは1つのクライアントに対してのみであることに注意してください。
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リダイレクトを無効にすることです。ルーティングループの問題もありますが、パケットがリダイレクト用にもパントされるため、強度がさらに高まります。
ICMP TTL-Exceededパケットは、TTLが1の場合にもパントされますが、これらのパケットは異なるCoPPポリサーインデックスを使用し、BROADCASTとキューを共有しないため、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
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
20-Oct-2023 |
再認定 |
1.0 |
30-Sep-2021 |
初版 |
フィードバック