NEC IX の VRRP 設定手順|ネットワークモニタとの連携

  • URLをコピーしました!
目次

はじめに

NEC UNIVERGE IX シリーズは、企業の拠点ルーターとして広く使われています。本社との VPN 接続や、複数回線を束ねた冗長構成を組む場面で、ゲートウェイの冗長化に VRRP を採用するケースがあります。

IX の VRRP 設定には、他社機器と比べて押さえておきたい特性があります。設定コマンドを投入しても、グローバル設定での有効化を忘れると動作しません。また、Cisco や FortiGate が持つトラッキング機能に相当する仕組みを VRRP 側に持たないため、上位回線の監視は別の機能で実現します。

この記事でわかること
  • IX の VRRP が準拠する RFC と、IPv4 と IPv6 での違い
  • vrrp enableを含む基本設定の手順
  • 仮想 IP アドレス宛のパケットを受信するvirtual-hostの使いどころ
  • トラッキング機能を持たない IX で、ネットワークモニタを使った監視設計
  • VRRP と NAT を併用する際に注意したい挙動

結論から述べます。IX で VRRP を動作させるには、グローバル設定モードで vrrp enable を投入することが前提です。インターフェース配下の設定だけでは動作しません。また、上位回線の障害を検知して切り替える仕組みは、VRRP のトラッキングではなくネットワークモニタ機能で構成します。Cisco のtrackコマンドに相当する記述は VRRP 側に存在しないため、設計の考え方から切り替える必要があります。

本記事の設定例は、次の構成を前提にしています。

項目
セグメント192.168.100.0/24
仮想 IP アドレス192.168.100.254
R1(Master 想定)の実 IP アドレス192.168.100.251
R2(Backup 想定)の実 IP アドレス192.168.100.252
VRID1
LAN 側インターフェースGigaEthernet0.0
WAN 側インターフェースGigaEthernet1.0

なお、IX シリーズと IX-R / IX-V シリーズでドキュメントが分かれています。本記事は確認できた範囲での記述となるため、実機への適用前に対象機種のマニュアルで構文を確認することをおすすめします。

NEC IX における VRRP の位置づけ

IX で VRRP を使う前に、準拠する規格を確認しておきます。

IPv4 と IPv6 で準拠 RFC が異なる

IX の VRRP には、他社と大きく異なる特性があります。

参考: NEC UNIVERGE IX シリーズ FAQ / VRRP
「UNIVERGE IXシリーズ」のVRRPは、IPv4はRFC2338(VRRPv2)、IPv6はRFC5798(VRRPv3)に準拠しています。
https://jpn.nec.com/univerge/ix/faq/vrrp.html

IPv4 側は VRRPv2、IPv6 側は VRRPv3 という構成です。Cisco のように IPv4 で v2 と v3 を選択する形ではありません。

この違いが影響するのは、次のような場面です。

要件IX での対応
IPv4 で VRRPv2 の対向対応可
IPv4 で VRRPv3 の対向対応可否の確認が必要
IPv6 で VRRPv3 の対向対応可
IPv4 でサブセカンドの切り替えVRRPv2 のため秒単位が前提

Cisco 機器と対向する構成では、Cisco 側でfhrp version vrrp v3を投入していると VRRPv3 で動作します。IX の IPv4 側は VRRPv2 のため、この組み合わせではネゴシエーションが成立しません。Cisco 側を既定の VRRPv2 のままにする設計が前提になります。

バージョン整合の重要性については、関連記事『VRRP とは|Master 選出と priority 設計の落とし穴』でも扱っています。

VRRP で対応できない範囲

IX の公式 FAQ には、VRRP の適用範囲についての記述もあります。主回線のダウンや、主回線を経由する経路の途中で障害が発生しても、VRRP による切り替えはできないと明記されています。

VRRP が判定するのは、あくまで同一セグメント上での Advertisement の受信可否です。上流の障害を検知するには別の仕組みが必要になり、IX ではネットワークモニタ機能がその役割を担います。後半のセクションで扱います。

もう 1 点、バックアップ回線へ切り替わった際の復路について、主回線でルーティングプロトコルを使用するか、いずれかの VRRP ルーターで NAT が必要になるという記述もあります。往路だけを切り替えても、復路が旧経路を通ると通信が成立しないという点は、設計時に押さえておきたい部分です。

基本設定の手順

IX の VRRP 設定は、グローバル設定とインターフェース設定の 2 段階になります。

vrrp enable の投入

まず、グローバル設定モードで VRRP 機能を有効化します。

Router(config)# vrrp enable

この 1 行がないと、インターフェース配下に設定を投入しても VRRP は動作しません。公式の設定例でも、インターフェース設定の前に記述されています。

設定が動作しない場合の切り分けでは、まずこの行の有無を確認することをおすすめします。

Master 側の設定

LAN 側インターフェースに、VRID と仮想 IP アドレスを設定します。

vrrp enable
!
interface GigaEthernet0.0
 ip address 192.168.100.251/24
 no ip redirects
 vrrp 1 ip 192.168.100.254
 vrrp 1 priority 200
 no shutdown

vrrp 1 ip 192.168.100.2541が VRID、続くアドレスが仮想 IP アドレスです。Cisco の VRRPv2 とよく似た構造になっています。

no ip redirectsは公式の設定例に含まれている記述です。ICMP リダイレクトを抑止する設定で、冗長構成では意図しないリダイレクトを避ける目的があります。

Backup 側の設定

Master より低い priority を設定します。

vrrp enable
!
interface GigaEthernet0.0
 ip address 192.168.100.252/24
 no ip redirects
 vrrp 1 ip 192.168.100.254
 vrrp 1 priority 100
 vrrp 1 preempt
 no shutdown

両機の差分は実 IP アドレスと priority の 2 点のみです。

priority の考え方

IX の公式 FAQ には、priority の値について明確な説明があります。0 と 255 は特別な意味を持ちます

意味
0VRRP グループに参加しないことを意味する。ネットワークモニタの shutdown-trigger 機能で VRRP 動作を停止させる際に使用される
1〜254通常の設定範囲。大きい値が Master に選出される
255自動的に付与される値。VRRP ルーターのインターフェース IP アドレスと仮想ルーターの IP アドレスを同じ値に設定したときに付与され、無条件で Master になる

255 が「設定する値」ではなく「自動的に付与される値」である点が重要です。RFC 5798 では 255 が仮想 IP アドレスを所有する機器に予約された値とされており、IX の実装はこの規定に忠実です。

FortiGate では所有者でない機器にも priority 255 を明示的に設定できます。IX と FortiGate を対向させる構成では、FortiGate 側で 255 を設定すると、IX 側から見て所有者が存在するかのような状態になります。マルチベンダー構成では、双方が扱える 1〜254 の範囲で設計を揃えることをおすすめします。

FortiGate 側の priority 設定については、関連記事『FortiGate VRRP の設定手順』にまとめています。

preempt の設定

IX の既定はプリエンプトモードです。priority の高い機器が復旧すると、自動的に Master へ戻ります。

切り戻しを抑止する場合は、否定形で設定します。

interface GigaEthernet0.0
 no vrrp 1 preempt

公式の設定例には、プリエンプトの設定を Master 側と Backup 側で揃えるよう注記されています。片側だけ無効にすると、意図しない状態になる可能性があります。

タイマーと認証

調整可能なパラメーターもあります。

interface GigaEthernet0.0
 vrrp 1 timers advertisement 1
 vrrp 1 authentication <テキスト文字列>

timers advertisementは Advertisement の送信間隔を秒単位で指定します。IPv4 側は VRRPv2 のため、ミリ秒単位の設定には対応していません。サブセカンドの切り替えが要件となる構成では、この点が制約になります。

認証は VRRPv2 のテキスト認証です。RFC 3768 で規定されている方式であり、Cisco の MD5 認証とは互換性がありません。Cisco と対向する構成で認証を使う場合は、双方でテキスト認証を選択する必要があります

仮想 IP アドレス宛の通信と virtual-host

構築後に「仮想 IP アドレスに ping が返らない」という状況に遭遇することがあります。IX ではこれが既定の動作です。

既定では仮想 IP アドレス宛のパケットを破棄する

NEC の障害切り分けガイドラインに、動作が明記されています。

参考: NEC UNIVERGE IX シリーズ 障害切り分けガイドライン
VRRPv2(IPv4)のデフォルト動作では、VRRPの仮想IPアドレス宛のパケットを廃棄します。
https://jpn.nec.com/univerge/ix/Support/Troubleshooting/netmon-vrrp-3.html

これは障害ではなく、RFC 5798 の Accept_Mode に相当する規定に沿った動作です。Accept_Mode の既定値は False とされており、仮想 IP アドレスを所有しない機器は、Master であっても仮想 IP アドレス宛のパケットを自分宛として受け入れません。

IPv4 と IPv6 で扱いが異なる点が IX の特徴です。

アドレスファミリー既定の動作追加設定
IPv4(VRRPv2)仮想 IP アドレス宛のパケットを破棄virtual-hostが必要
IPv6(VRRPv3)常に受信できる不要

同じガイドラインには、IPv6 の場合は常に仮想 IP アドレス宛のパケットを受信できるため、virtual-host の設定は不要と記載されています。

virtual-host の設定

仮想 IP アドレス宛のパケットを受信させるには、追加の設定を投入します。

interface GigaEthernet0.0
 ip address 192.168.100.251/24
 vrrp 1 ip 192.168.100.254
 vrrp 1 priority 200
 vrrp 1 ip virtual-host

vrrp 1 ip virtual-hostの 1 行を追加する形です。

この設定が必要になる場面は 2 つあります。

  • 仮想 IP アドレスを IPsec トンネルの終端として使う場合
  • 監視システムから仮想 IP アドレス宛の ping で死活監視を行う場合

後者は設計上の判断が分かれます。仮想 IP アドレス宛の ping を共通の監視手段にすると、メーカーごとに設定の要否が変わります。監視対象を各機器の実 IP アドレスにする方法も選択肢になります

IPsec トンネルの終端として使う場合

仮想 IP アドレスをトンネル終端にする構成では、virtual-host に加えてトンネル側の設定も必要です。

interface Tunnel0.0
 ipsec source-address <IPsec ポリシー名> Virtual1

仮想インターフェース名の指定方法が、この構成の要点です。公式ガイドラインでは、VRRP の仮想インターフェースをVirtual[VRID]の形式で指定すると説明されています。VRID が 10 であればVirtual10、本記事の構成のように VRID が 1 であればVirtual1を指定します。

物理インターフェース名ではなく、VRID から導かれる仮想インターフェース名を使う点に注意が必要です。

この構成が持つ意味は明確です。IPsec トンネルの終端が仮想 IP アドレスになるため、VRRP のフェイルオーバー時に対向側から見た終端アドレスが変わりません。拠点間 VPN で機器を冗長化する場合、対向側の設定変更なしに切り替えられます。

ただし、VRRP はセッション情報を同期しないため、フェイルオーバー時に IPsec SA は再確立が必要になります。切り替え後の通信復旧までに、SA の再ネゴシエーションの時間が加わる前提で設計することをおすすめします。

VRRP と NAT を併用する際の注意

拠点ルーターとして IX を使う構成では、NAT との併用が一般的です。ここに、切り分けが難しい挙動があります。

複数の Master が生じた場合の影響

NEC の障害切り分けガイドラインでは、次の事象が説明されています。ネットワークモニタによる経路切り替えで VRRP を停止させたにもかかわらず、VRRP の動作が継続しているという症状です。

原因として挙げられているのが、NAT を設定したインターフェース上で VRRP が複数動作し、複数の装置が Master として動作している状態です。

影響が生じる仕組みは次のとおりです。

  1. VRRP と NAT を併用した場合、NAT アドレスに対する ARP 要求には Master が応答します
  2. 同一インターフェース上に複数の Master が存在すると、複数の装置が同じ NAT アドレスへの ARP 要求に応答します
  3. 結果として、正常な経路で通信が行えなくなります

通常の VRRP の切り分けでは見つけにくい事象です。VRRP 自体は動作しており、show vrrpの出力も個別には正常に見えます。問題は、同一インターフェース上で複数の VRRP グループが動作している構成にあります。

設計上の対処

この事象を避けるには、次の点を確認します。

確認項目内容
同一インターフェースの VRRP グループ数複数構成している場合、Master がどの装置に分散しているか
ネットワークモニタでの停止対象すべての VRRP グループが停止対象に含まれているか
NAT の設定インターフェースVRRP を動作させているインターフェースと一致しているか

ネットワークモニタで VRRP を停止させる設計では、対象とする VRID の指定漏れに注意が必要です。1 つの VRID だけを停止対象にすると、残りのグループで Master が維持され、NAT アドレスへの ARP 応答が続きます。

復路の経路設計

もう 1 点、NAT に関連する記述が公式 FAQ にあります。バックアップ回線に切り替わった際、復路のパケットをバックアップ回線経由にするには、主回線でルーティングプロトコルを使用するか、いずれかの VRRP ルーターで NAT が必要とされています。

VRRP は状態を通知するプロトコルであり、経路情報を交換しません。往路を切り替えても、復路の経路が自動的に追従するわけではありません。

対処方法内容
ルーティングプロトコルの併用主回線で OSPF や BGP を動作させ、経路を動的に切り替える
NAT による送信元の書き換えVRRP ルーター側で NAT を行い、復路を自身へ戻す

拠点ルーターの構成では、NAT による方法が採用されるケースが多くなります。設定量が少なく、対向側の設定に依存しないためです。ただし、NAT を経由することでアプリケーション側に制約が生じる場合があるため、要件に応じた判断が必要になります。

上位回線の監視(ネットワークモニタとの連携)

VRRP が判定するのは、同一セグメント上での Advertisement の受信可否だけです。上位回線の障害を検知して切り替えるには、別の仕組みが必要になります。

IX にはトラッキング機能がない

ここが他社機器との最大の違いです。Cisco のtrackコマンドや FortiGate のvrdstに相当する設定は、IX の VRRP には用意されていません。VRRP の設定行として監視先を指定することはできません。

代わりに使用するのが、独立した機能であるネットワークモニタです。

メーカー監視の実装VRRP との関係
CiscotrackオブジェクトVRRP 設定行から参照
FortiGatevrdstVRRP 設定内に記述
NEC IXネットワークモニタ独立した機能から VRRP を操作

設計の考え方が異なる点に注意が必要です。Cisco では「VRRP が監視結果を参照する」構造ですが、IX では「ネットワークモニタが VRRP を操作する」構造になります。設定を読む際も、VRRP の設定行だけを見ても監視の有無が判断できません。

Cisco 側の実装との対比は、関連記事『Cisco VRRP の設定手順|v2 と v3 で異なる構文の使い分け』で扱っています。

ネットワークモニタの構成要素

ネットワークモニタは 3 つの要素で構成されます。

  1. watch-group: 監視グループの定義
  2. event: 監視条件(何を検知するか)
  3. action: 検知時の動作(何を実行するか)

定義したグループはnetwork-monitorコマンドで有効化します。この有効化を忘れると監視が動作しませんvrrp enableと同様、IX では有効化のコマンドが独立している点が特徴です。

基本的な設定例

上流のホストを監視し、到達不能になったら VRRP を停止させる構成です。

vrrp enable
!
watch-group wan-watch 10
 event 10 ip unreach-host 8.8.8.8 GigaEthernet1.0
 action 10 ip shutdown-vrrp 1
!
network-monitor wan-watch enable
!
interface GigaEthernet0.0
 ip address 192.168.100.251/24
 no ip redirects
 vrrp 1 ip 192.168.100.254
 vrrp 1 priority 200
 no shutdown

各行の意味を整理します。

内容
watch-group wan-watch 10監視グループ名とシーケンス番号
event 10 ip unreach-host 8.8.8.8 GigaEthernet1.0指定インターフェースから対象ホストへの到達性を監視
action 10 ip shutdown-vrrp 1障害検知時に VRID 1 の VRRP を停止
network-monitor wan-watch enable監視の有効化

VRRP を停止させると priority が 0 として扱われます。priority 0 は VRRP グループに参加しないことを意味する特別な値です。Backup 側がこれを検知して Master へ昇格します。

監視の種類

event には複数の種類が用意されています。実務でよく使われるものを整理します。

event監視内容
ip unreach-host <アドレス> <インターフェース>指定ホストへの ICMP 到達性
ip unreach-route <プレフィックス> <インターフェース>自装置のルーティングテーブル上の経路の存在
ip vr-inactive <VRID>指定 VRRP グループが Master 以外へ遷移したこと
ip vr-active <VRID>指定 VRRP グループが Master へ遷移したこと

経路監視(unreach-route)は、上流機器が生きたまま経路を失うケースに対応できます。ホスト監視より検知範囲が広く、動的ルーティングを併用している構成では有用です。

公式の設定事例集には、ホスト監視の動作条件も記載されています。5 秒間隔で ICMP Echo Request を送信し、6 回連続で応答がない場合に障害と判定します。障害中も送信は継続し、1 回でも応答があれば復旧と判定する動作です。

検知までに約 30 秒かかる計算になります。VRRP 自体の切り替わりが約 3.6 秒であることを踏まえると、上流障害の検知は桁違いに遅くなります。要件によっては、監視間隔の調整を検討する必要があります。

アクションの種類

action にも複数の選択肢があります。

action動作
ip shutdown-vrrp <VRID>VRRP 動作を停止(priority 0 相当)
ip resume-vrrp <VRID>VRRP 動作を復旧
ip decrement-vrrp-priorityVRRP 優先度を減算
ip shutdown-route / ip resume-route特定経路の隠蔽と可視化
ipsec clear-sa <インターフェース>関連する IPsec SA と IKE SA を削除
turn-BAK-LED-on装置前面の BAK ランプを点灯

VRRP 停止型(shutdown-vrrp)と priority 減算型(decrement-vrrp-priority)の 2 系統がある点は、Cisco や FortiGate と同じ構図です。

方式特徴向いている構成
shutdown-vrrppriority の計算が不要単純な 2 台構成
decrement-vrrp-priority減算値と priority 差の設計が必要3 台以上、段階的な優先度制御

多くの構成ではshutdown-vrrpが扱いやすい選択になります。減算値と priority 差の関係を計算する必要がなく、確実に切り替わるためです。

ipsec clear-saturn-BAK-LED-onは IX 固有のアクションです。前者は IPsec トンネルを終端する構成で、切り替え時に SA を明示的に削除して再確立を促します。後者は装置前面の LED を点灯させ、現地での目視確認を可能にします。無人拠点の運用では、後者が切り分けの手がかりになります。

実 IP アドレスと仮想 IP アドレスを分ける必要がある

シャットダウントリガを使う構成での重要な制約です。公式マニュアルに明記されています。

参考: NEC IX-R/IX-V 機能説明書 / ネットワークモニタの設定
VRRP シャットダウントリガを使用するときは必ず実 IP アドレスと VRRP 仮想 IP アドレスを別の値にする必要があります。
https://support.necplatforms.co.jp/ix-nrv/manual/fd/02_router/19_netmon.html

理由も同じ箇所で説明されています。仮想アドレスと実アドレスを同一にすると、そのルーターの VRRP 優先度が 255 となり、必ず Master になるためです。

前述のとおり、IX では実 IP アドレスと仮想 IP アドレスを同じ値にすると priority 255 が自動的に付与されます。この状態では VRRP を停止させても Master のままになり、監視によるフェイルオーバーが機能しません。

本記事の構成例では、仮想 IP アドレスを 192.168.100.254、実 IP アドレスを 192.168.100.251 と別の値にしています。ネットワークモニタを併用する設計では、この分離が前提になります。

両系が停止する構成に注意

もう 1 つ、公式の障害切り分けガイドラインに記載されている落とし穴があります。

VRRP の状態監視(vr-inactive)を両機に設定すると、一方の障害検出が連鎖して両側の VRRP が停止するという事象です。この状態になると、障害が復旧してもネットワークモニタで復旧を検出できなくなります。

解決策として、一方の監視設定を VRRP の状態監視から経路監視に変更する方法が案内されています。

! R1 側: 経路監視で VRID 20 を停止
watch-group vrrp10-watch 10
 event 10 ip unreach-route 192.168.0.0/24 GigaEthernet0.0
 action 20 ip shutdown-vrrp 20
!
network-monitor vrrp10-watch enable
! R2 側: VRRP 状態監視で VRID 10 を停止
watch-group vrrp20-watch 10
 event 10 ip vr-inactive 20
 action 20 ip shutdown-vrrp 10
!
network-monitor vrrp20-watch enable

複数の VRID を連動させる構成では、監視方式を片側だけ変えることで循環を断ち切ります。設計時に、イベントとアクションの依存関係が閉ループになっていないかを確認することをおすすめします。

動作確認と切り分け

設定後の確認は、VRRP 側とネットワークモニタ側の両方を見る形になります。

VRRP の状態確認

基本の確認コマンドです。

Router# show vrrp
Router# show vrrp detail

show vrrp detailでは、状態遷移の履歴と Advertisement の送受信カウンター、priority 0 の送受信回数、TTL エラー数まで表示されます。

確認したい箇所を整理します。

項目確認内容
Statemasterbackupか。期待どおりの状態か
priority設定値どおりか。ネットワークモニタ作動時は 0 になる
仮想 IP アドレス両機で同一の値か
状態遷移の履歴遷移の頻度と時刻。フラッピングの判断材料
Advertisement カウンターsentだけが増えてrcvdが 0 なら対向から届いていない
TTL エラー数増加していれば経路を跨いだパケットを受信している

状態遷移の履歴が表示される点が IX の利点です。フラッピングの調査では、遷移の頻度とタイミングから原因を絞り込めます。

ネットワークモニタの状態確認

監視の動作状況は、別のコマンドで確認します。

Router# show watch-group detail

出力には、グループの有効・無効、現在のステータス、変化と復旧のカウント、そしてイベントの発生履歴が時刻付きで表示されます。プローブの成功と失敗の回数、往復時間の履歴も確認できます。

短時間に変化が繰り返し記録されていれば、監視先までの回線品質を疑う流れになります。

状態が期待どおりにならない場合

確認の順序を整理します。

STEP
VRRP がまったく動作しない場合
  • vrrp enableが投入されているかを確認します
  • インターフェースがno shutdownになっているかを確認します
STEP
両機とも Master になる場合

Advertisement が相互に届いていない状態です。

  • 対向機器のバージョンが VRRPv2 で揃っているか(Cisco 側が VRRPv3 になっていないか)
  • 認証設定が一致しているか
  • マルチキャストアドレス 224.0.0.18 が中間機器で遮断されていないか
  • VLAN やポート設定に不整合がないか
STEP
意図しない機器が Master になる場合
  • priority の設定値を確認します
  • 実 IP アドレスと仮想 IP アドレスが同一になっていないかを確認します。同一の場合は priority 255 が自動付与されます
STEP
監視が動作しない場合
  • network-monitor <グループ名> enableが投入されているかを確認します
  • show watch-group detailでプローブが実行されているかを確認します
STEP
仮想 IP アドレスに ping が返らない場合

IPv4 では既定の動作です。応答させる必要がある場合はvrrp <VRID> ip virtual-hostを追加します。

対向機器側からの確認

マルチベンダー構成では、両側から確認すると切り分けが速くなります。FortiGate と対向する構成であれば、FortiGate 側でもdiagnose sniffer packetによるキャプチャが可能です。プロトコル番号 112 のパケットが双方向に届いているかを確認すると、どちら側で失われているかを判断できます

まとめ

NEC UNIVERGE IX の VRRP は、グローバル設定でのvrrp enableが前提となり、上位回線の監視は VRRP のトラッキングではなくネットワークモニタ機能で構成します。Cisco や FortiGate とは設計の考え方が異なるため、他社の構成をそのまま移植することはできません。IPv4 が VRRPv2 準拠である点も、マルチベンダー構成では対向機器のバージョン選定に影響します。

  • IX の VRRP は IPv4 が VRRPv2、IPv6 が VRRPv3 に準拠
  • グローバル設定の vrrp enable がないと VRRP は動作しない
  • priority 255 は設定値ではなく実 IP と仮想 IP の一致で自動付与される
  • IPv4 では既定で仮想 IP 宛パケットを破棄し、virtual-host で受信可能
  • トラッキング機能がなく、監視はネットワークモニタで代替する
  • シャットダウントリガ使用時は実 IP と仮想 IP を別の値にする
  • 状態監視を両機に設定すると両系停止が起きるため経路監視と組み合わせる

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ(ネットワーク・サーバ・クラウド・セキュリティ)の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus(取得から20年以上)/ VCAP-DCA / Azure Solutions Architect Expert

▶ 運営者プロフィール(詳細)

目次