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)機能は、不要なトラフィックやサービス拒否(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割り当ての失敗の合計として現れる可能性があります。状況によっては、1日の特定の時間（ネットワークの負荷が完全に最大になる業務時間のピークなど）にのみ動作を確認できます。
「背景説明」セクションで説明したように、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（ポリサーインデックス）を共有します。つまり、DHCP Discoverなど、デバイスのCPUで処理する必要のあるすべてのブロードキャストトラフィックは、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のルータに直接送信する方が、ノートPCにとってより効率的であるためです。これは、いずれにしても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は、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リダイレクトおよびリダイレクトがいつ送信されるかについては、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 unreachablesが有効になっているため、パケットは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
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トラフィックがブロードキャストキューから枯渇する可能性があります。規模の面では、リダイレクトキューにパントされたパケットの数が原因で、このシナリオはさらに悪くなります。
ここでは、192.168.10.0/24ネットワークに対する1000回のpingを介して、各ping間に0秒のタイムアウトでCoPPドロップを示します。9300のCoPP統計情報はクリアされ、pingが送信される前に0バイトが廃棄されます。
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ドロップが発生します。これは、単一のクライアントに対してのみであることに注意してください。
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 |
初版 |
フィードバック