ネットワーク の記事一覧

こんにちは。GMOインターネットグループ株式会社の松下です。近年、ネットワークの複雑化やデバイスの増加に伴い、手動でのネットワーク管理は限界に近づいています。この課題に対処するため、AI（人工知能）を活用したネットワーク自動化が注目されています。この記事では、AI技術の具体的な活用方法とその構成についてわかりやすく解説します。 伝統的なネットワーク運用の課題 従来のネットワーク運用には、以下のような課題が存在します。 手動設定の煩雑さ：デバイスごとに個別の設定が必要で、時間がかかる。リアルタイム対応の困難さ：トラブル発生時の迅速な対応が難しい。ヒューマンエラー：手作業による設定ミスが障害の原因となる。 これらの課題を解決するために、AI技術が効果的なソリューションとなっています。 AIによるネットワーク自動化のメリット 1. 自動化された設定と管理 ネットワークデバイスの設定を自動化し、統一されたポリシーを適用します。これにより、設定ミスを減らし、一貫性を保つことができます。 また、設定自体をAIに作成させることも可能です。 具体例：ChatGPTを活用したCisco機器の設定 プロンプト： 新しいVLAN 30を作成し、ポート1から5に割り当てる設定コマンドを教えてください。 AIからの応答： configure terminal vlan 30 name New_VLAN exit interface range GigabitEthernet0/1 - 5 switchport mode access switchport access vlan 30 exit end 2. 異常検知と予測 機械学習を用いてトラフィックパターンを分析し、異常な活動を早期に検知します。将来的な問題を予測し、事前に対策を講じることも可能です。 3. 効率的なリソース配分 ネットワークの使用状況をリアルタイムで監視し、リソースを最適に配分します。これにより、帯域幅の無駄遣いを防ぎ、パフォーマンスを向上させます。 導入時のポイント AIによるネットワーク自動化を成功させるためには、以下の点に注意が必要です。 データの品質確保：AIは大量のデータを基に学習するため、正確で高品質なデータが重要です。人材の育成：AI技術を理解し運用できる専門人材の確保や育成が必要です。段階的な導入：一度に全てを自動化するのではなく、重要な部分から段階的に導入することがリスクを最小限に抑えます。 まとめ AIを活用したネットワーク自動化は、運用効率の向上だけでなく、信頼性やセキュリティの強化にも大きく貢献します。データ収集から自動化までの一連のプロセスを理解し、具体的なAI技術の活用方法を身につけることで、技術者としての市場価値も高まります。

GMOインターネットグループの梅崎です。今回はネットワーク通信に必要なケーブル部材の話を、独断と偏見によるピックアップでご紹介できればと思います。 メタルケーブル いわゆるLANケーブルについてです。(人によっては「RJ45」「STP/UTPケーブル」「ツイストペアケーブル」「メタルケーブル」などと呼ぶこともあります) コネクタ形状 「RJ45」というものだけ覚えておけば大丈夫です。配線はほとんど「ストレート」なので、「クロス」はそんなのもあったな程度に覚えておけば十分です。 ケーブルの種類 「Cat5e」と「Cat6/Cat6A」だけで十分かと思います。注意点としては「Cat5相当品」を名乗る、中の線が足りないものがあるので記憶の片隅に入れておいてください。それぞれの用途としては「Cat5eが1Gbps以下」、「Cat6Aが10Gbps以下」での接続で使います。(余談ですが10Gbps以上は基本的に光ファイバーを使うほうが面倒が少なくていいと思います。メタルケーブルはノイズを拾って通信品質が劣悪になった経験が……) その他にもケーブルの直径でAWGxxという番号もあったりします。(PoEでの電力や接続距離に制限がかかることがあるので、細さはほどほどにしたほうが吉です) 光ファイバー コネクタ形状 「LC」「MPO」をよく使い、「SC」はたまに使うので、この3つを覚えておけば大丈夫です。「LC」「SC」は一つのコネクタに1つの心線が入っており、「LC」が小さめ、「SC」がちょっと大きめな形をしています。「MPO」は一つのコネクタに複数の心線が入っており、MPO8かMPO12をよく使います。(MPO24とかもあるらしいですが、今のところこれを利用する光トランシーバーを使ったことはないです) 「MPO8」は「MPO12」の使わない心線がないもののようです。現状は「MPO8」のみで十分かと思いますが、念のためMPO12を購入してもいいかなと考えています。 両端のコネクタ形状が異なるケーブルもあります。例えば・「MPO8」を8本の「LC」にバラしたもの・片側は「LC」、もう片側は「SC」になっているものがあり、用途(光トランシーバーの形状など)によって使い分けるのに便利です。 「MPO」の配線はいくつかの種類があるので、使う光トランシーバーに合わせて使い分けてください。 その他にもファイバーの端面の形で角度がついていないものと角度がついているものがあります。互換性がないのでご注意を。 ケーブルの種類 「シングルモードファイバー(SMF)」、「マルチモードファイバー(MMF)」がありますが、光トランシーバーのレーザーの種類で使い分けると覚えておけば大丈夫です。 ざっくりと短距離であればMMF、長距離であればSMFが使われることが多いです。 また、「SMF」「MMF」それぞれに「OS1」「OS2」、「OM3」「OM4」といった種類があり、同じ光トランシーバーでも、ケーブルによって接続可能な距離が違うと思っておいてください。 その他 「DAC」や「AOC」と呼ばれる光トランシーバー部分とケーブルが一体化されているものも存在します。「DAC」が光トランシーバーの形状で金属のケーブルがつながったもので、「AOC」が光トランシーバーに光ファイバーがつながったものです。 「DAC」は超短距離用で10m以下、「AOC」はそれよりは長く100m以下で使うことが多いです。 最後に 以上、私がよく使うケーブル部材について話してきました。 ケーブルの端面形状についてや「LC」よりも小さなコネクタ形状など、今回割愛した内容については、ケーブルやNW機器のメーカーさんのサイトも見ると面白いですよ、と丸投げしつつ筆を擱こうと思います。

GMOインターネットグルーブの梅崎です今回はスイッチングハブ（以下、スイッチ）などの設定において「VLAN」「VLANを切る/分ける」とはどんなものなのかを簡単に説明しますOSI参照モデルはある程度知っている、「アプセトネデブ」でピンと来る程度のネットワークの基本的な知識があることを前提としています はじめに ズバリ「VLANを切る/分ける」とは平たく言うと、新しいスイッチを作るイメージです 少し細かく言うと、1つの物理的なスイッチを複数の仮想的なスイッチに分割することを指しています 1本の接続で複数の仮想的なスイッチ同士を接続する場合にもVLANを使うので、こちらを指していることもあります なぜVLANを使うのか VLANを使わずにIPセグメントごとに物理的なスイッチを並べることもできますが、以下のような問題があります 端末数の少ない場合、スイッチのポートが余り無駄になる端末数に合わせて機種の違うスイッチを使う場合、管理が煩雑になる端末の急増した際に、スイッチの交換が必要になる そこでVLANを利用すれば同じ種類のスイッチを並べつつ、利用用途に合わせた仮想的なスイッチが作成できるためこれらの問題を回避しながら費用の圧縮や効率的な運用管理が可能になります （サーバーの仮想化などと同様の動機だと考えてください） 具体的にVLANを使うには もちろん「VLANを切る」だけでは端末を接続することはできないので物理的なポートをVLANに所属させる必要があります(ちなみに、VLANはそれぞれに番号を付けて管理しています) VLANに対応していない端末や1つのVLANしか利用しない端末用にはタグ無し（untag/access）などと呼ばれる、普通のイーサネットフレームが流れる設定にします VLANに対応しており、複数のVLANを利用するスイッチ同士/端末用にはタグ有り（trunk）と呼ばれる、イーサネットフレームにVLAN番号を差し込む設定にすることが多いです そうすることで、一本の接続で複数のVLANのイーサネットフレームを同時に流し、受け取ったイーサネットフレームがどのVLANに所属しているかを分類できるようになっています VLANとルーティング VLANは仮想的なスイッチに分割すると言いましたが、この分割によりVLANを跨いだ相互通信はできなくなります 相互通信をしたい場合はルーターを用意する必要があります 例えば、ルーター機能とスイッチ機能を兼ね備えたスイッチを使用しVLAN(≒仮想的なスイッチ)に対して仮想的なポートを作り、そのポートを使ってルーティングを行うことで、VLANを跨いだ相互通信が可能となります(このポートはSVI、irb、vlanifなど、各社でさまざまな名前があります) 最後に 今回は割愛してしまったのですがそもそもなぜIPセグメントを複数使いたいのかすべての端末を1つのIPセグメントにまとめると駄目なのかといった点についても、機会がありましたら説明したいと思います

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューションチームの梅崎です今回は主にサーバー管理者/アプリ開発者向けに「ネットワークが繋がらない、通信ができない」となったときの・ クライアント/サーバー側で可能なトラブルシュート方法・ ネットワーク管理者へ調査依頼を出す際に我々が欲しい情報をまとめてみました今回はそのアクセス拒否されている場合の被疑箇所の特定編です 過去記事はこちら https://developers.gmo.jp/38113/ https://developers.gmo.jp/41457/ アクセス拒否されている場合の被疑箇所の特定 クライアント側でパケットキャプチャを取りつつアクセスしたいポートに対してtelnetで通信を試す telnet 192.0.2.1 80 その際にパケットキャプチャでICMPのunreachableが来ているとそのICMPの送り元のホストで通信が遮断されています In IP 192.0.2.1 > 192.0.2.2: ICMP 192.0.2.1 tcp port http unreachable, length 68 # (In側≒受信側) IP (送信元のIP) > (おそらく自分のIP): ICMP (説明) unreachable, (説明) なのでそのICMPの送信元で通信許可を実施してください ICMPが来ていない場合はサーバー側でもパケットキャプチャしクライアント側のIPアドレスからのパケットが届いているかを確認してください クライアント側のIPアドレスからのパケットが届いている場合 それに対応する応答パケットがあるかを確認してください応答パケットがない場合はサーバー側の問題なので調査してみてください 応答パケットがある場合は応答パケットが通信経路中で遮断されている可能性があるためクライアント側のIPアドレスからのパケットが届いていない場合を確認してください クライアント側のIPアドレスからのパケットが届いていない場合 下記の情報とともにネットワーク管理者へ「クライアント側とサーバー側の間でパケットが届いていない」という旨の情報とともに調査依頼をしてください 必須 ・問題となっているクライアントとサーバーのIPアドレス 　「192.0.2.123/24」や「192.0.2.123 255.255.255.0」等 ・ここまでで調査したコマンドと結果すべて(パケットキャプチャの結果を含む) あれば ・画面のスクショやログのコピー ※秘匿情報以外は加工せず生情報の方がベスト ・事象を確認した時間帯 　最低限、一時間単位で正確なものがありがたいです

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューションチームの梅崎です今回は主にサーバー管理者/アプリ開発者向けに「ネットワークが繋がらない、通信ができない」となったときの・ クライアント/サーバー側で可能なトラブルシュート方法・ ネットワーク管理者へ調査依頼を出す際に我々が欲しい情報をまとめてみました今回はその通信に問題がある場合の被疑箇所の特定編です 通信に問題がある場合の被疑箇所の特定 前提として、クライアントとサーバーとの通信の場合通信経路上におおよそ下記の機器があることが多いです クライアント <==> クライアント側GW/FW <==> 経由するGW/FW <==> サーバー側GW/FW <==> サーバー この章ではそれぞれどこのポイントで通信ができていないかの調査方法について記載しています※ICMPが全区間にて許可されている前提の調査方法です　特別セキュリティ要件が厳しくICMPもできない場合は、ネットワーク管理者へ直接調査依頼をした方が早いかもしれないです 全体的なL3(ルーティング)の調査 クライアントからサーバー、もしくはサーバーからクライアントへpingを打ってください # pingコマンドで確認、「192.0.2.123」を実際のIPアドレスへ置き換えてください ping 192.0.2.123 # 出力例 # # 通信は問題ない場合 # PING 192.0.2.123 (192.0.2.123) 56(84) bytes of data. # 64 bytes from 192.0.2.123: icmp_seq=1 ttl=64 time=0.340 ms # 64 bytes from 192.0.2.123: icmp_seq=2 ttl=64 time=0.422 ms # 64 bytes from 192.0.2.123: icmp_seq=3 ttl=64 time=0.418 ms # 64 bytes from 192.0.2.123: icmp_seq=4 ttl=64 time=0.450 ms # 64 bytes from 192.0.2.123: icmp_seq=5 ttl=64 time=0.382 ms # ^C # --- 192.0.2.123 ping statistics --- # 5 packets transmitted, 5 received, 0% packet loss, time 3999ms # rtt min/avg/max/mdev = 0.340/0.402/0.450/0.041 ms # # # 通信が許可されていない場合 # PING 192.0.2.123 (192.0.2.123) 56(84) bytes of data. # From 192.0.2.123 icmp_seq=1 Destination Port Unreachable # From 192.0.2.123 icmp_seq=2 Destination Port Unreachable # From 192.0.2.123 icmp_seq=3 Destination Port Unreachable # ^C # --- 192.0.2.123 ping statistics --- # 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms # # # 応答がない場合(タイムアウトする場合) # PING 192.0.2.123 (192.0.2.123) 56(84) bytes of data. # ^C # --- 192.0.2.123 ping statistics --- # 9 packets transmitted, 0 received, 100% packet loss, time 8000ms 通信は問題ない場合、ルーティングは問題がなく、アクセス許可がされていない可能性が高いです 「アクセス拒否されている場合の被疑箇所の特定(作成中)」を参照してください 通信が許可されていない場合、ルーティングは問題がなく、アクセス許可がされていないです 「アクセス拒否されている場合の被疑箇所の特定(作成中)」を参照してください 応答がない場合(タイムアウトする場合)は次項に記載の内容を実施してください クライアントとサーバーのL3(ルーティング)の調査 クライアントもしくはサーバーでルーティングの確認をしてください # ルーティングテーブルの確認 ip route show # 出力例 # default via 192.0.2.1 dev ens192 proto static metric 100 # 192.0.2.0/24 dev ens192 proto kernel scope link src 192.0.2.123 metric 100 出力の見方 「宛先のIPセグメント(defaultはすべての宛先)」 via 「中継ネットワーク機器のIPアドレス, 所謂デフォルトゲートウェイ/デフォゲ」 dev 「サーバーのインターフェース名」 proto static metric 100 クライアントからサーバー(逆向きも同様) * 通信用の行は存在するか、登録されているか* デフォゲのIPアドレスは正しいか* インターフェース名は正しいか を確認してください これがおかしい場合はサーバー/クライアントの設定を修正してください これが問題ない場合は次項に記載の内容を実施してください クライアントとサーバーのL2の調査 デフォゲとの疎通が可能かを確認してください # pingコマンドで確認、「192.0.2.1」を実際のIPアドレスへ置き換えてください ping 192.0.2.1 まず、デフォゲのIPアドレスが正しいことを再確認してください デフォゲとの疎通が問題ない場合は、「クライアントとサーバーの間のルーティング確認」を参照してください デフォゲとの疎通に問題がある場合は次のコマンドで調査をしてください # L2(VLAN等)が繋がっているかの確認 # ARPテーブルの確認 ip neigh show # 出力例 # 192.0.2.200 dev ens192 FAILED # 192.0.2.10 dev ens192 lladdr 00:53:00:00:00:00 STALE # 192.0.2.15 dev ens192 lladdr 00:53:00:aa:aa:aa STALE # 192.0.2.16 dev ens192 lladdr 00:53:00:12:34:56 STALE FAILED以外の行として同一IPセグメントのサーバーのIP/MAC Addressが一つも表示されない場合はサーバーとネットワーク機器でIP帯 or VLAN番号が一致していない可能性が高いです 次のコマンドでサーバー側のインターフェースを情報を取得してください # インターフェースのIPアドレスとMACアドレスなどを表示 ip address show # 出力例 #(略) #2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 # link/ether 00:53:00:00:00:00 brd ff:ff:ff:ff:ff:ff # inet 192.0.2.10/24 brd 192.0.2.255 scope global noprefixroute dynamic eth0 #(略) 出力の見方 例の1行目が 2: 「インターフェース名」: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 「MTUサイズ」 qdisc mq state 「UP/DOWN、インターフェース上がっているか落ちているか」 group 「この辺は気にしなくてOK」 例の2行目が link/ether 「MACアドレス」 brd ff:ff:ff:ff:ff:ff 例の3行目が inet 「IPアドレス」 brd 「ブロードキャストアドレス」 scope 「この辺は気にしなくてOK」 下記の情報とともにネットワーク管理者へ「ip neigh showで同一IPセグメントのサーバー(ARPエントリー)が見えず、デフォゲとのping疎通もできない」という旨の調査依頼をしてください 必須 ・問題となっているクライアントとサーバー名、位置情報等 ・問題となっているクライアントとサーバーを接続しているスイッチ名とスイッチのインターフェース番号 ・問題となっているクライアントとサーバーのIPアドレス 　「192.0.2.123/24」や「192.0.2.123 255.255.255.0」等 ・デフォゲとして指定しているIPアドレス 　「192.0.2.1」等 ・デフォゲの設定をしているサーバーのインターフェースのIPアドレスとMACアドレス ・ここまでで調査したコマンドと結果すべて 利用していれば必須 ・問題となっているクライアントとサーバーのVLAN番号 あれば ・画面のスクショやログのコピー ※秘匿情報以外は加工せず生情報の方がベスト ・事象を確認した時間帯 　最低限、一時間単位で正確なものがありがたいです 既存のサーバーのIP/MAC Addressが表示されてる場合は上記の情報とともにネットワーク管理者へ「ip neigh showで同一IPセグメントのサーバー(ARPエントリー)が見えるがデフォゲとのping疎通ができない」という旨の調査依頼をしてください クライアントとサーバーの間のルーティング確認 宛先からのping応答がないがデフォゲからのping応答はある場合は どの経路を通って通信しているかの情報を取得してください # tracerouteコマンドで確認、「192.0.2.1」を実際のIPアドレスへ置き換えてください # (少し時間がかかります) traceroute -n 192.0.2.1 下記の情報とともにネットワーク管理者へ「サーバーからのping応答がないがデフォゲからのping応答はある」という旨の情報とともに調査依頼をしてください 必須 ・問題となっているクライアントとサーバーのIPアドレス 　「192.0.2.123/24」や「192.0.2.123 255.255.255.0」等 ・クライアントとサーバーがお互いにどの経路を通って通信しているかの情報 ・ここまでで調査したコマンドと結果すべて あれば ・画面のスクショやログのコピー ※秘匿情報以外は加工せず生情報の方がベスト ・事象を確認した時間帯 　最低限、一時間単位で正確なものがありがたいです

初めまして！GMOインターネットグループ株式会社、新卒2年目の江﨑です。今回は初心者が一から負荷テストについて学び、実施した経験についてお話しします。 はじめに 今回、オンプレミスのサービスのクラウドリフトに伴って負荷テストを行う必要がありました。私は普段、フロントエンドエンジニアとしてサービスのUI改善を行っており、負荷テストは未開の領域でした。そのため、一から負荷テストについて学び、多くの知見を得ることができたのでこれから学ぶ方の参考になればと思い、執筆させていただきました。 使用ツール Distributed Load Testing on AWSApache JMeter 今回はAWSが提供する Distributed Load Testing on AWS を用いて実行環境を簡単に構築し、細かいシナリオは Apache JMeter で作成しました。 ■Distributed Load Testing on AWSDistributed Load Testing on AWS ソリューションは、大規模および負荷時のソフトウェアアプリケーションテストを自動化して、リリース前に性能上の潜在的なパフォーマンスの問題を特定するのに役立ちます。このソリューションは、一定のペースでトランザクションレコードを生成する数多くの接続ユーザーを作成およびシミュレートします。サーバーをプロビジョニングする必要はありません。また、このソリューションでは、複数の AWS リージョンにまたがってテストを実行することができます。詳細：https://aws.amazon.com/jp/solutions/implementations/distributed-load-testing-on-aws/ 公式では上記のように紹介されています。 Distributed Load Testing on AWS 構成図 サーバーレスな負荷生成コントローラー・エンジン & Web UI を提供しています。（コントローラーは Taurus を使用）既存サービス（負荷テスト先）のクラウドリフトで忙しい中、負荷テスト元の実行環境を一から構築するとなると途方に暮れてしまいます。そんな手間を省いてくれる便利なツールとなっています。下記公式ガイドから簡単に環境構築できる AWS Cloud Formation を立ち上げることができます。実装方法の詳細については公式ガイドをご覧ください。https://d1.awsstatic.com/Solutions/ja_JP/distributed-load-testing-on-aws.pdf ■Apache JMeterApache JMeter™ アプリケーションはオープンソースソフトウェアであり、機能動作の負荷テストとパフォーマンスの測定を行うために設計された100%純粋なJavaアプリケーションです。元々はWebアプリケーションのテスト用に設計されましたが、その後他のテスト機能にも拡張されました。詳細：https://jmeter.apache.org/ 公式では上記のように紹介されています。GUIで直感的に操作ができ、プラグインを用いて様々なシナリオを作成できます。メジャーなツールであるため、ネット上に多くの記事が公開されています。また、日本語にも対応しているため英語が苦手な私でも難なく利用することができました。 シナリオ作成 シナリオは負荷テスト先のアプリケーションによって異なるので、今回は使われる機会が多いと思われる機能を抜粋して紹介します。 Thread Group Thread Group ・スレッド数や Ramp-up 期間、ループ回数を設定する機能・今回は Distributed Load Testing on AWS で設定するため全て 1 に設定 HTTP Cookie Manager HTTP Cookie Manager ・Cookie を使用する場合に必要となる機能・自動取得された Cookie はスレッドごとに管理される HTTP Request HTTP Request ・GET や POST などアプリケーション内で想定するユーザーのリクエスト内容を設定・ユーザーが行う一連の流れを作成することで解像度の高いシナリオを作成できる Regular Expression Extractor Regular Expression Extractor ・HTTP Request で取得した Body や Response Header から値を正規表現抽出する・上の画像では input 要素から value 属性の値を抽出して TOKEN 変数に代入している 他にも様々な機能があるので負荷テスト先のアプリケーションに合ったシナリオを作成してみてください。 負荷テスト実施 Distributed Load Testing on AWS に作成したシナリオをアップロードして負荷テストを行っていきます。 Create Load Test Task Count・負荷エンジンとなる Fargate タスク数Concurrency・タスク毎に生成される仮想ユーザー数・Task Count × Concurrency = 同時接続数Ramp Up・Concurrency に達するまでの時間（0 以上, 単位：秒 or 分）・Ramp Up 時間を増やすと徐々に負荷がかかるHold For・Concurrency を維持し続ける時間（1 以上, 単位：秒 or 分）・Ramp Up 10分 + Hold For 50分 = 負荷テスト 1時間 上記項目入力後、Apache JMeter で作成したシナリオをアップロードして実行するだけで負荷テストが行われます。 負荷テスト結果 Test Results Avg Responce Time・すべてのリクエストの平均応答時間（秒）Avg Latency・すべてのリクエストの平均レイテンシ（秒）Avg Connection Time・すべてのリクエストについて、ホストへの接続にかかった平均時間 （秒）Avg Bandwidth・すべてのリクエストの平均帯域幅Total Count・リクエスト総数Success Count・成功したリクエスト総数Error Count・エラー総数Requests Per Second・すべてのリクエストの 1 秒あたりの平均リクエスト数Percentile Responce Time・テストの応答時間のパーセンタイル値（最大応答時間は 100%、最小応答時間は 0%） Error が発生していたり、Responce Time が異常に遅い場合は負荷テスト先のアプリケーションでボトルネックが発生しているため解消する必要があります。今回は Amazon CloudWatch や AWS X-Ray でボトルネックを確認し、クラウド環境の構成を見直し、修正しました。その後再負荷テストを行い、問題が無いことを確認してからアプリケーションのリリースを行いました。 おわりに 今回の経験を通して、負荷テストはお客様に安定したサービスを提供するための指標となることを学びました。正常に稼働しているシステムでも、負荷の大きいリクエストを送られたり、長時間稼働し続けるとエラーを出してしまいます。そういった不測の事態を避けたり、システムの限界を把握しておくためにも、リリース前の負荷テストは重要です。今回ご紹介したように、面倒な環境構築を行わずとも負荷テストを実施できる便利なツールが世の中には存在しますので、皆さまも是非、自身のサービスに対して負荷テストを行ってみてはいかがでしょうか。

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューションチームの梅崎です今回は主にサーバー管理者/アプリ開発者向けに「ネットワークが繋がらない、通信ができない」となったときの・ クライアント/サーバー側で可能なトラブルシュート方法・ ネットワーク管理者へ調査依頼を出す際に我々が欲しい情報をまとめてみました今回はそのエラー内容特定編です 注意事項 基本的には上からなぞっていけば大丈夫な形にはしていますがWindows機などはコマンドが違うことが多くコメントでやりたいことを記載しているので同様の情報を取得できるものを探していただければと思います あと、IPv6の調査はあまりやったことは無いですが基本的にはトラブルシュート方法は変わらずコマンドにIPv6用のオプションをつければ大丈夫だと思います どんなエラーなのかを特定 この章では最低限、通信の問題なのかクライアント/サーバーのアプリケーション的なエラー、設定の不備なのかを切り分けする方法を記載しています ブラウザ等で404や403といった4xxエラーが表示される クライアントとサーバーとの通信は問題ないです「URLが誤っている」かサーバーで「ファイルが存在しない」、「アクセスを許可していない」等が原因のため URLの再確認とWebサーバー側の設定の確認が必要です ブラウザ等で500や504といった5xxエラーが表示される クライアントとサーバーとの通信は問題ないですサーバー側のエラーやバックエンドが落ちているなどが原因の可能性が高いです サーバー、バックエンド側のログの確認が必要です ※サーバーとバックエンドの「通信に問題がある場合(作成中)」を参照してください 名前解決に失敗する 「URLが誤っている」か「DNSサーバーの設定が無い」「リゾルバの設定がされていない/間違えている」かなと思いますURLの再確認とDNSサーバー側の設定の確認、クライアント側のリゾルバの設定の確認が必要です タイムアウトエラーが表示される(Webに限らず) クライアントとサーバーとの通信に問題があるかサーバー側が落ちている、アクセスするIPアドレスに誤りがある可能性があります IPアドレスの再確認とサーバー側が落ちていないかを下記コマンド等で確認する必要があります ※コマンドの結果が問題ない場合は、「通信に問題がある場合(作成中)」を参照してください # プロセスが待ち受ける、バインドするIPアドレス/port等を確認 # 「*」は全IPアドレスで待ち受けている状態です、特定のIPアドレスが表示されることがあります # HTTP ならば TCP *:80, HTTPSならば TCP *:443などのことが多いです sudo lsof -i -P -nn # 出力例 # COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME # snmpd 1364 Debian-snmp 6u IPv4 43174 0t0 UDP *:161 # sshd 1387 root 3u IPv4 68716 0t0 TCP *:22 (LISTEN) # docker-pr 67965 root 4u IPv4 50378714 0t0 TCP *:443 (LISTEN) # docker-pr 67978 root 4u IPv4 49454775 0t0 TCP *:80 (LISTEN) 最後のLISTENの箇所のIPアドレスとポート番号が意図したものであることそもそも意図した行が存在することを確認してください IPアドレスやポート番号が意図と異なる場合はサーバー側の設定に不備があります 行自体が存在しない場合は大抵プロセスが落ちています サーバーの設定等の調査をしてください tcp/udpのポート番号がそれぞれ何用途かはWikipediaや IANAのページ などに書かれているので詳細はそれらを参照ください 「アクセスが拒否されました」等が表示される(Webに限らず) クライアントとサーバーを含む通信経路上でアクセス拒否する設定(ファイアウォール, ACL, iptables等)がされている可能性が高いですまた、サーバー上のプロセスが落ちている場合もこの表示になる場合があります 前項「タイムアウトエラーが表示される」と同様に下記コマンドで調査してください ※コマンドの結果が問題ない場合は、「アクセス拒否されている場合(作成中)」を参照してください # プロセスが待ち受けるport等が問題ないかを確認 sudo lsof -i -P -nn なんとなく重い、特定時間だけ不調になる 原因として思いつくだけでもDDoS, プログラムのバグ, クライアント/サーバーの過負荷, 通信の輻輳, 通信経路上での物理故障, etc... 本腰を入れた調査が必要なので サーバー管理者、ネットワーク管理者を巻き込んで調査してください 調査に当たっては下記の情報が欲しいです 必須 ・具体的な事象の説明 　☓「通信エラーがでている」 　○「画面に□□というメッセージが表示されている」 　○「△回に▲度□□というメッセージが表示される」 　○「動作に■秒かかるようになった」 ・クライアントのIPアドレス 　「192.0.2.123/24」や「192.0.2.123 255.255.255.0」等 ・サーバーのIPアドレス ・サーバーのプロトコル 　TCP/UDP/ICMP等とport番号 ・事象を確認した時間帯 　最低限、一時間単位で正確なものがありがたいです 利用していれば必須 ・クライアントのVLAN番号 ・クライアント名、位置情報等 ・クライアントを接続しているスイッチ名とスイッチのインターフェース番号 ・サーバーのVLAN番号 ・サーバー名、位置情報等 ・サーバーを接続しているスイッチ名とスイッチのインターフェース番号 あれば ・画面のスクショやログのコピー ※秘匿情報以外は加工せず生情報の方がベスト

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューションチームの梅崎です今回は弊社にある実際のローカル5G環境のアンテナをFree5GCにつなげてみました 構成 主に使ったもの 5Gコアhttps://github.com/free5gc/free5gc02638669e8daaa301775749a3a56cb66a143857bhttps://github.com/free5gc/gtp5g652e8e512aa2371d0304253301ccf252cb41b357OSUbuntu 22.04.2 LTS5.15.0-67-genericサーバーCPU : Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz× 2ソケット（計24コア/48スレッド）メモリー : 128GB 構築 NFのコンフィグはhttps://github.com/free5gc/free5gc-compose/blob/master/config/の内容をベースにしておりcomposeファイルはコンテナイメージを自分でビルドするものに変更しています composeファイルで気をつけたこと AMFへ外部からアクセスできるようにする services: amf: ports: - "0.0.0.0:38412:38412/sctp" UPFのネットワークをホストのものに&networkのRoot権限を与える これについてはアンテナに通知するUPFのIPアドレスがUPF自身がbindするものになってしまうようでして これを別のIPアドレスにする設定が分からずとりあえずはホストのNICを直接使うようにしました services: amf: upf: cap_add: - NET_ADMIN network_mode: "host" AMF, UPFだけ外部からアクセスできるようにしておけば大丈夫なようなのでこれ以外は内部ネットワークでそれぞれのコンテナ(NF)同士が通信できるようにしています 設定ファイルの変更点 各NFの設定の内、plmnを実際に利用するものへ変更snssaiはsst 1のsd 000001のみにし他は削除しています registerIPv4, bindingIPv4, nrfUriなどのコンテナが利用するIPアドレスをサービス名に変更しています(UPFについてはサーバー自体のIPアドレスを直接記載しました) UPFとSMFの設定の内、端末用のIPアドレス帯を実際に利用するIPアドレス帯へ変更 AMFのNAS security parametersをとりあえず全部有効にしています(おそらくアンテナとが利用するものの指定が足りなかったのか、これをしないとアンテナと接続できなかったです) security: # NAS security parameters integrityOrder: # the priority of integrity algorithms - NIA1 - NIA2 - NIA0 cipheringOrder: # the priority of ciphering algorithms - NEA1 - NEA0 - NEA2 あとはDebugレベルを変えたりFree5GC自体のサンプルコンフィグと見比べて必要なさそうなコンフィグを消したりしてます 実機のアンテナと接続 ※注※　免許申請の際の構成図と変わるので、定期報告の際に構成を更新した旨を国へ連絡する必要があります アンテナ側のコアのIPアドレスを今回構築したものへ変更したのですが、すぐには端末と接続できず とはいえ繋がらない原因も３つぐらいで・上記にも書いたUPFコンテナのアドレスがアンテナから見えない件・security parametersが一致しない(?)件・リリースタグがついているバージョンではうまく行かず、その時の最新版を利用する必要があった件これを解決すれば普通に端末との通信ができるようになり正直、事前に思っていたよりはかなりあっさりと接続できたなという印象です (ただ、現状も設定が足りないのか、Free5GCとアンテナとの間の接続が切れ、アンテナ側が再起動を何度か繰り返してはいますが……) 最後に エイヤッと試した割にあっさりとFree5GCと実機の接続ができ良い意味で拍子抜けしたなと思ってしまっています やっぱり標準化されたプロトコルっていいなと思います 一点気になるのはWebコンソールがブラウザで開くと認証っぽいのはあるのですがAPIを直接Curlで叩くと管理者名だけで認証(?)が通るのでここは自前で作るかしないとならないなと思います また、今後はFree5GCのパフォーマンス試験や他の実装のコアも試してみようと考えています特にパフォーマンスについては、アンテナ1つ程度であればもっともっとCPUが弱い安価なPCでも十分動作しそうなのでそれも試して見ようと思います NFはgoでの実装なのでいっそラズパイでも動くのではと少し思っています(ラズパイの場合、UPFが使っているカーネルモジュールがうまく動くのか知見が無いので確信は無いですが……) ということで次回はFree5GCのパフォーマンス試験かラズパイへコアを乗っける構成を実施しようと思います

NWエンジニアが日々書いているネットワーク構成図。Visioやdraw.ioなど色々なツールがありますが、表計算ツールのエクセルで作ってみたら意外といい感じでした。そんなわけで一週まわって「エクセルで書けば良いのでは？」という提案をさせて下さい。 ネットワーク構成図って？ この記事をクリックいただいた皆さんは存じているかと思いますが、一応「ネットワーク構成図とはなんぞや？」という話をしておきます。（以下、NW構成図と略します！） NW構成図とは通信インフラの設計図。 例えば、通信インフラが道路みたいなものだと仮定すると、構成図はいわば通信インフラの地図。 典型的な構成図（内容は全て架空の値です） 最悪、なくてもシステムは動くし、道は辿ればわかるんですが… 複雑な構成でいちいち辿っていると迷子になることうけあい。 皆さんがG〇〇gleMAPにナビしてもらうように、NWエンジニアはネットワーク構成図にナビしてもらうわけですね。説明おしまい。 構成図を作るツールはいろいろある さて、そんな大事なNW構成図。 これを作る作業はインフラエンジニアがずっと取り組んできた課題、なので手段もたくさんあります。 身近な構成図に特化したツールというと、 VISIOパワーポイントdraw.ioLLDP自動絵画ツール などなど、簡単にメリデメをまとめてみました。 VISIO 図面絵画に強いオフィスツール。ステンシルというオブジェクトアイコンが多様にあり、かつ、アイコンからアイコンへ線を引く事に長けています。 ユーザに提出する見栄えのいい資料も、複雑な社内のシステム資料もこれ一本。欠点は標準オフィスではないため、入れてる人しか見れないし編集できないこと。 パワポ ご存じプレゼン資料作りのツール。 図形を書く事にもそこそこ長けており、ユーザに提出するシンプルな資料であればこれが簡単。また複数スライドでパラパラ漫画を作り、構成の遷移を表す事にかけては他より優秀です。 欠点は図面の最大サイズが決まっていること、世界地図は書けません。 draw.io 図面作成ができる無料のWEBツール。VISIOに似た操作感で使え、フリーソフトであることが最大のメリット。こちらもシンプルなNW構成を書くのに適しています。 デメリットはWEBツールゆえ機能が少なく操作性ががやや悪いこと、また線が増えると見づらくなりがち。 NW構成図の自動絵画ツール さいきんはNW構成図を自動で図を書いてくれるツール（LLDPなどの機器の生データを元に書くやつ）がでてきました。起動すると自動でアイコンをおいて線をひいてくれます。 メリットは人の手が加わっていないため図に間違いが無い事、それと自動配置なので人的コストの削減ができます。 良いことづくめに聞こえるんですが、自動配置の置きっぷりがいまいちで人間がやりなおさないといけません。図が大きくなるとそもそも配置することさえ困難になってくることもしばしば…。 10台以下の小規模NWをであれば、そこそこ使えるのではないでしょうか。 余談 ちなみに、カッコイイことで有名なインタロップのShowNet構成図は"イラストレーター"で書かれてるらしいですよ。そう言うのもあるのかー！ エクセルはどうか？ んで、本題のエクセルです。 エクセルはもともと表計算をするツールなんですが、図形絵画もそこそこ充実しています。 これをNW構成図として特化させて図を書いてみたものがコチラ！ よくある三段構成（内容は全て架空の値です） 意外といい感じの図が書けるのではないでしょうか。シカクを並べて線をつなげるのは得意っぽい。 続いて抽象的な図の作成を作成してみました。 たまにありそうな社内ネットワーク（内容は全て架空の値です） ぱっとしないのですが一応書けてはいます。アイコンが足りないので、フリー素材を多用するともっときれいになりそう。 続いてデカめの構成図を書いてみましょう。 ハコがいっぱいつながった構成図（内容は全て架空の値です） ん。良いのではないでしょうか。 わりとスムーズに書けました。必要十分な表現ができていますし、図形を美しく配置する機能もばっちり。 PCの動作が重くなったりもしません。 シートとして複数の資料を1つのブックにまとめられるのも便利ですね。構成図と結線表とIP表が同じ資料にまとまってコンパクト化に成功。 これもう、一週回って 『　構成図はエクセルで書いたら良い。　』 のではなかろうか？ エクセルで構成図を書くコツ3つ そんなわけで昨今の私はエクセルで構成図を書いているのですが、書く中で"コツ"がわかってきたので、マネしてみたい方向けに共有しておきましょう。 １．グリッドの代わりにセルを使う まず第一にセルの縦横サイズを揃え、セルをグリッドとして使用します。 これが意外と便利で、以下のようなことができるようになります。 "Alt＋ドラッグ＆ドロップ"でグリッド吸着図形をセルに沿ってピタリと配置できます。美しいは正義。 セル単位でカット＆ペーストの処理ができる図形をセル単位でまとめてコピー＆ペーストができます。しかもペースト先でピタリと揃う！（下図参照） 行列操作で図と図の間に隙間を作る行/列の挿入を行うことで線や図形がセル単位で広がります。これを利用すると図形と図形の間に隙間を容易に作ることができます（下図参照）。図は作るだけでなく更新していくもの、更新のしやすさは大事なポイント。 ２．線にはベジエ曲線を使う エクセルには線がいくつかあり、自動で曲がってくれるコネクタというタイプも便利なのですが、おすすめは"ベジエ曲線"。 ベジエ曲線という機能はイラストレーターなど絵画ツールでよく使われる機能。引いた後"頂点の編集"で調整できます。調整時に"Alt＋ドラッグ＆ドロップ"でセルに吸着させることで、きれいな線を引く事ができるのが最高。 ３．重なり対策には光彩機能 線と線の重なりはなるべく避けるべきなのですが、増えてくるとどうやっても避けられない状況になりがち。VISIOとかだと、トンネルのようになって線の重なりをよけてくれるものですが、エクセルにはそれがありません。 そこで光彩機能。線の周囲にぼやーっと別の色を付ける機能なんですが、これをやっておくと重なりが明確になります。 サクサク構成図を作るポイントのABC もう3つ。サクサク作るうえで押さえておきたいポイントを紹介させて下さい。 A．書式コピーを使う でかい図を書いていると、色やフォントなどをいじらないと見づらくなることがあります。それをひとつづつ変えるのは本当にツライ。 そんな時は書式コピー、ある図形からある図形へ書式情報を移すもの、これが使えるのはWindowsアプリの強みです。 B．"オブジェクトの選択"を使う エクセルには"オブジェクトの選択"というセル操作から図形操作に移動するモードがあります。ホーム→検索と選択→オブジェクトの選択 と選ぶとでてきます。 このモードに入ると、クリックでセルを選択することがなくなり、複数の図形を範囲指定で囲って操作できるようになります。便利。ちなみに抜けるときは"Escキー"です。 "クイック アクセス ツール バー"も使おう 先の書式コピーを含め、よく使うツールは左上の"クイック アクセス ツール バー"に入れておくとより便利になりますよ。 C．オフィス標準の便利機能を使おう F4キーで繰り返し、Clt＋Aで全選択、Home＋Ctrlで図形の左上に移動…などなど、ショートカット機能を使うことで快適に利用できます。 以下によく使うものを紹介しておきます。 代表的なキー操作Home＋Ctrl図形の左上に移動Ctrl＋A全選択Ctrl+Z / Ctrl+Yリドゥ / アンドゥCtrl+X / Ctrl+C / Ctrl+Vカット / コピー / ペーストF4直前の操作を繰り返す（書式の連続適用など）Ctrl+S保存Ctrl+C+クリック図形の複数選択 エクセル構成図に欠点はあるのか？ いくつかあるのですが、最大の欠点は"図形内の文字を検索できない"こと。VISIOとかはできて、でかい構成図でIPやホストなんかを探すときに有用なのですが、エクセルではできません。 エクセルでもいちおう、アドイン（RelaxToolsなど）を入れることで図形内の検索ができるようになります。困った方は入れましょう。でもそれはそれとして、 「マイクロソフトさんなんとかしてください。」 まとめ そんな感じで「NW構成図を作る選択肢にエクセルがあるよ。」という提案の話でした。 表計算ツールで邪道ともいえる絵画機能をフル活用した構成図作成。これがけっこーいけます。VISIOが無いかた、他のツールに不満のあるかた、一度試してみていただければと思います。 余談。 ちなみに、エクセルにしかできないことを最後にひとつ！謎のやる気の無い線を引く機能があって これ！ うんうん。かわいいですね。エイプリルフールのジョークにかがでしょうか。 ご拝読ありがとうございました。それではよい構成図ライフを。

こんにちは、GMOインターネットグループ株式会社の長谷川です。今回はWindowsに対してUbuntuサーバーからWake-on-LANを遠隔で行えるAPIサーバー構築に関してお話して行こうと思います。 作成動機 電気代が上がっているので自宅の VPN サーバーを使用時以外は出来るだけ休止させておきたいという熱い思いからです。 WOLとは Wake-on-LANと呼ばれる技術の略称で、主にLAN内のNWに繋がっているPC等にマジックパケットというパケットを送り電源投入を行う技術です。 システム構成 簡単にまとめてしまうと、自宅外から自宅内の Ubuntu の API サーバーに向け API を叩きます。target の PC に向け Ubuntu の API サーバーから WOL コマンドを実行しマジックパケットを発行します。 Windows の ACPI ステートに関して WOLを利用する場合にはWindowsのバージョンやハードウェア構成により、起動できるACPIのステートが異なる場合があります。 ACPIステートは以下の状態があります。 ACPI ステート状態S0 （動作中）システムが完全に使用出来る状態、稼働中S1 （スリープモダンスタンバイ）低電力アイドル状態、CPUクロック停止、HDDの回転停止、メモリ保持S2 （スリープモダンスタンバイ） 低電力アイドル状態、CPUクロック停止、HDDの回転停止、メモリ保持 S3 （スリープモダンスタンバイ） 低電力アイドル状態、CPUクロック停止、HDDの回転停止、メモリ保持 S4 （休止状態） 低電力アイドル状態、CPUクロック停止、HDDの回転停止、ファイル保持S5 （シャットダウン） 完全なシャットダウン引用元 : https://learn.microsoft.com/ja-jp/windows/win32/power/system-power-states 今回は S4 休止状態からの起動を想定して API サーバーを作成します。ここでは Windows 側の設定の例は様々なパターンがあるため、それぞれの環境に合わせ設定されている想定として以後進めていきます。 Ubuntuサーバーの環境構築 Go言語はクロスコンパイルが可能でシングルバイナリとしても配置できる為、Ubuntuサーバーに合わせてビルドが出来るようであればUbuntuサーバーに必要なものは、WOLコマンドの実行出来れば問題ありません。 sudo apt install wakeonlan 実際のAPIサーバーのコード package mainimport (    "encoding/json"    "fmt"    "log"    "net/http"    "os/exec"    "regexp" // 今回は軽量Web toolキットの gorilla mux を使います。 // ビルド環境にない場合には "go get -u github.com/gorilla/mux" でインストールしてください    "github.com/gorilla/mux")type Device struct {    MacAddr string `json:"macaddr"`}// 入力された MAC アドレスを元に WOL コマンドを実行する関数func InputWOLCommand(macaddr string) string {    out, _ := exec.Command("wakeonlan", macaddr).Output()    return string(out)}// API の Postを受け取る関数func postWOL(w http.ResponseWriter, r *http.Request) {    w.Header().Set("Content-Type", "application/json")    var wol Device    _ = json.NewDecoder(r.Body).Decode(&wol) // 送られてきた MAC アドレスが本当に MACアドレスの形式になっているか正規表現でチェックする。    regTrueFalse, _ := regexp.MatchString("(?:[0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}", wol.MacAddr)    if regTrueFalse { // MACアドレスが正しい形式であればWOLコマンドを実行する関数にMACアドレスを引き渡します。        out := InputWOLCommand(wol.MacAddr)        json.NewEncoder(w).Encode(wol)        fmt.Println("wol wake up server -> " + out)    } else {        fmt.Println("Not match MAC type")    }}func main() { // ルーターのイニシャライズ    r := mux.NewRouter()    fmt.Println("Port UP : 3000") // ルーティングと起動ポートの指定    r.HandleFunc("/api/wol/", postWOL).Methods("POST")    log.Fatal(http.ListenAndServe(":3000", r))} 上記をビルドして Ubuntu サーバーに配置します。systemd にサービス登録などの手順は省きますが、配置が完了したら起動して自宅のルーターにポート転送やファイヤーウォールの設定を行い、グローバルIPからAPIサーバーのポートにアクセスできるようにします。（ルーターの説明書やウェブページを検索すると手順が書かれた記事が数多くあります。。） 実行 APIを叩くことが出来れば何でもよいですが今回は curl で投げます。 curl -X POST -H "Content-Type: application/json" -d "{\"macaddr\":\"[起動設定させたPCのMACアドレス]\"}" "http://[自宅グローバルIP]:3000/api/wol/" target PC が熱い思いにより起動されると成功です。 まとめ APIがないものにAPIを生やしたいという熱い思いや、遠隔で操作を行いたい、自動化が好きだという方は是非 GMOインターネットグループの採用ページ をご覧ください。きっとあなたのやりたいことが見つかると思います。