ネットワーク の記事一覧

初めまして！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インターネットグループの採用ページ をご覧ください。きっとあなたのやりたいことが見つかると思います。

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューション部の梅崎です今回はローカル5G案件でfree5GCを物理サーバー上で動かしどれだけのトラフィックをさばけるのか試しました free5GCを試してみた -Vol.01 https://developers.gmo.jp/23934/#%E6%AC%A1%E5%9B%9E 構成 free5GC の全コンポーネントを入れた物理サーバー(10Gbps接続✕2)を一台UERANSIM の UE & gNB 相乗りの VM を5台ずつ、3台の物理サーバー(10Gbps接続)へMEC見立ての物理サーバー(iperfの対向役)を一台 主に使ったもの 5Gコア free5GC この時点のものリンク１リンク２5Gアンテナ/端末シミュレーター UERANSIM v3.2.6リンク OS Ubuntu 22.04.1 LTSトラフィック生成ツール iperf version 2.1.5free5GC 側のサーバーCPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GBUERANSIM 側の物理サーバーCPU: Intel(R) Xeon(R) CPU E5-2670 v3 × 2ソケット（計24コア/48スレッド） メモリー: 128GBorCPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GBUERANSIM の VMCPU: 8個メモリー: 1GBMEC見立ての物理サーバー CPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GB トラフィック印加試験 1台のVMのみ # MECへUEごとにのトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 100M -c ${受け側のIP} -P 1 -u #受け側 iperf -s -i 1 -u 100Mbpsのときは問題ないですが 600Mbpsのときはそもそも、UERANSIMのVMからパケットが500Mbps前後しか出ない状態でした色々試したところ400Mbpsのトラフィック一本ならパケロス等も無いようで今回の構成のUE一台ごとの上限は400Mbpsのようです 15台のVM(UDP) # MECへUEごとにトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 100M -c ${受け側のIP} -P 1 -u #受け側 iperf -s -i 1 -u 100Mbpsを15台分は特に問題なく 100Mbps * 2本が15台分は一瞬3Gbpsになるもののすぐにセッションが切断されてしまいました 15台のVM(TCP) 次にTCPでも同様なことを試してみました # MECへUEごとにトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 300M -c ${受け側のIP} -P 2 #受け側 iperf -s -i 1 UDPをTCPにするとアップロード側が合計で最大7Gbps程度になり正直TCPよりUDPの方がスピードが出そうだと思っていたのですがTCPの方が圧倒的に多くのトラフィックを捌けていて驚いています…… 15台のVM(UDP、チューニングをしてみる) ちょっとTCP側と違いあまりチューニング方法が出てこなかったのですが一つそれらしいコマンドを見つけたので試そうと思います # UDPはソケットバッファを増やすとパフォーマンスが良くなるとのこと sysctl -w net.core.rmem_max=4194304 sysctl -w net.core.wmem_max=4194304 # MECへUEごとにトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 100M -c ${受け側のIP} -P 1 -u #受け側 iperf -s -i 1 -u 100Mbps*2を15台の動作はあまり変わらないという結果でした ここで気がついたのですが合計トラフィックが3Gbpsを超えたところでパケットがMEC役のサーバーへ届かなくなり その後、しばらくしfree5GCのサーバーへ来るトラフィックが3Gbpsを割り始めるとパケットがMEC役のサーバーへ到達するようになりました 15台のVM(TCP、 UL/DL双方向) ちょっとUDPは挙動が怪しいですが、これ以上はチューニングを頑張らないとならなさそうなので一旦TCPの方を試していきます ここまではUEからみてUL方向のトラフィックのみだったので今度はTCPUL/DL双方向にしたところ # MECへUEごと、UL/DL双方向にトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 500M -c ${受け側のIP} -d #受け側 iperf -s -i 1 ULが4.5Gbpsほど、DLが3.5Gbpsほどになりましたただ、ULのみのときと同じく数分放置しているとセッションが切れてしまうUEが数台出てくる状態です 15台のVM(TCP、DL方向) 次にUEからみてDL方向のトラフィックをテストしてみます # MECへUEごと、UL/DL双方向にトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 500M -c ${受け側のIP} -r #受け側 iperf -s -i 1 DL方向のトラフィックも7Gbps程度はでるようでしたこちらも数分放置しているとセッションが切れてしまうUEが数台出ていました 15台のVM(TCP、UL方向、7Gbps以下) 最後に今までの上限トラフィックより少ないトラフィックだとUEのセッションが切れないようになってくれるか試してみます # MECへUEごと、UL/DL双方向にトラフィックを流す #出す側 iperf -i 1 -t 3600 -b 400M -c ${受け側のIP} #受け側 iperf -s -i 1 最初は問題なく400Mbps*15台の6Gbpsほどを処理できています ただ、こちらも一時間放置したところいくつかのUEのセッションが切れてping届かなくなっていました まとめ free5GCを物理サーバー上に構築したところ今回のサーバースペックだとTCPがUL/DL合計7～8Gbps程度、UDPがULで3Gbps程度出るようですがトラフィックを流し続けているとUEのセッションが不安定になってしまうという結果でした ただし、この不安定さの原因がUERANSIM側なのかfree5GC側なのか、はたまた相性の問題なのかが不明なので今後はUE/coreの別実装でもテストする必要があるかなと思います 最後に 安定性はさておくと現状のローカル5G環境として利用する分には捌けるトラフィックは十分かなと感じています 次回は実際のRANをfree5GCにつなげてみて安定性等々を試していこうかと思います

こんにちは。GMOインターネットグループ株式会社の新里です。セキュリティ的な側面でなくても、通信経路上でパケットをキャプチャーして動作確認・データの有無について確認したくなる事は多々あると思います。たまに、どうやれば？という事を聞かれたりするので、少しパケットキャプチャーについて書いてみます。 対象ごとに分かれるキャプチャ OSIレイヤーのEthernetの部分から見たいのか？アプリケーションレイヤーだけで良いのか？というので方法は全然変わってきますね。あと、OSがある端末でキャプチャーを行うのか？IoT端末のように、OSが無いような端末のキャプチャーはどうするのか？といった感じで方法が分かれますね。僕の場合は、主に以下のような用途で分けて使っています。 Wireshark、tcpdumpWindows・Linux・Mac上でパケットキャプチャを行い、L2～L4(主にTCP/UDP/TLS...など)を確認するとき。他にもiPhoneのパケットをMacでパケットキャプチャする際にも利用する。BurpsuiteブラウザやモバイルアプリのL7（アプリケーションのデータ通信）の確認するときに利用。モバイルホットスポット(Windows)IoT端末などOSを持たないアプリのキャプチャを行う際に、WiFiの接続先として利用する（L3として利用してキャプチャする）。ここで更にWiresharkでパケットキャプチャを行うことで、端末の通信を確認する。ミラーリング（L2 HUB）WiFiを持たない端末で、Ethernetが使えるときに利用する。ミラー先のWindows/MacなどのPCでWiresharkでパケットキャプチャを行うことで、端末の通信を確認する。BLE SnifferBLEの通信をキャプチャするときに利用する。キャプチャしたパケットはWiresharkで確認を行う。これは僕の手持ちのBluefruit LE Sniffer。 WiFiのキャプチャ2.4GHz/5GHz WiFiのキャプチャをするときに利用する。MacのWireless Diagnostics（ワイヤレス診断）の機能で、WiFiのキャプチャを行って、Wiresharkでキャプチャしたパケットの確認を行う。この辺とかの通り。 どの方法を使っても、Wiresharkを主にメインのツールとして利用しています。意外なところで、BLEのキャプチャを行った内容もWiresharkで見ることができますね。Wiresharkを統合的なツールとして利用するため、Windows/Macを利用するときはデフォでインストールして利用しています。 RPi4でお手軽キャプチャ Raspberry Pi4（以下、RPi4）はお手軽にLinuxルータに出来るので、RPi4をルータ化して接続する端末のパケットキャプチャを行うといった方法もあります。簡単に出来るので、以下に手順を示します。 環境 Raspberry Pi 4 model B 4Gbyte memOS : Ubuntu Server 22.04.1 LTSUSB to Ether : BUFFALO LUA4-U3-AGTE-WH上流：eth0（RPi4の物理NIC）下流：eth1（USB to EtherのNIC） RPi4をルーター化させるので、上流はRPi4のNIC、下流にはUSB to Etherで接続します。下流側は適当にL2を指して有線端末のパケットをキャプチャーするというわけです。 設定 設定の流れとしては... インターフェイス(IP)の設定DHCPの設定DNSの設定ルーティング設定IPマスカレード といった流れです。最初のIPの設定を行います。上流はDHCPでIPが配布される前提で、下流は192.168.80.0/24のレンジを使います。 # デフォルトで設定されている /etc/netplan/50-cloud-init.yaml を修正 network: ethernets: eth0: dhcp4: true optional: true eth1: dhcp4: false addresses: [192.168.80.1/24] nameservers: addresses: [8.8.8.8] optional: true version: 2 次はDHCPの設定です。下流側から見たらルーターとして動作するので、DHCPでのIP配布からDNSの設定を行います。まずはDHCP側からです。ここで下流側のドメインはcapture.devということにしておきます。 # パッケージを以下でインストール # sudo apt install -y isc-dhcp-server # # /etc/dhcp/dhcpd.conf を修正 option routers 192.168.80.1; option domain-name-servers 192.168.80.1; option domain-name "capture.dev"; subnet 192.168.80.0 netmask 255.255.255.0 { range 192.168.80.2 192.168.80.252; option routers 192.168.80.1; } # 設定が終わったら以下で再起動 # systemctl restart isc-dhcp-server.service 次はDNSサーバーとしての設定です。転送先は8.8.8.8(google)を利用することにします。 # パッケージを以下でインストール # sudo apt install -y bind9 # # /etc/bind/named.conf.options を修正 options { directory "/var/cache/bind"; listen-on port 53 { localhost; 192.168.80.0/24; }; allow-query { localhost; 192.168.80.0/24; }; forwarders { 8.8.8.8; }; recursion yes; dnssec-validation auto; listen-on-v6 { any; }; }; # named.conf.local を修正 zone "capture.dev" IN { type master; file "capture.dev.zone"; }; # 設定が終わったら以下で再起動 # sudo systemctl restart named 最後にルーティングさせる設定を行います。 # /etc/sysctl.conf を以下に修正 # net.ipv4.ip_forward=1 # # 設定を有効化 sudo sysctl -p 最後にIPマスカーレドの設定です。RPi4でNATの設定を行い ConeNAT、Symmetric NATのような設定を変えることで、下流側NW端末の挙動を簡単に確認できるようになるというわけです。 # iptableの設定保持用のパッケージをインストールしておく # sudo apt install -y iptables-persistent # # ここでは単にルーターとして動作させるようにするため、設定を全部除去してから行う。 iptables -F iptables -t nat -F iptables -t nat -A POSTROUTING -s 192.168.80.0/24 -o eth0 -j MASQUERADE # symmetric nat用の設定の場合は以下 # iptables -t nat -A POSTROUTING -s 192.168.80.0/24 -o eth0 -j MASQUERADE --random iptables-save > /etc/iptables/rules.v4 それでは実際にtcpdumpで下流側の通信を見てみます。sshでRPi4の上流(eth1)側から接続して "sudo tcpdump -i eth1" としてキャプチャーします。eth1側(下流)から接続すると、接続している自身のssh接続も余分にキャプチャーされるので、上流側から接続した方がよいでしょう。以下のような感じでキャプチャーされている様子が分かると思います。 その他 最後にこんな物も入れて使っていたりするよ、ということで。Mac AppStoreからゲットできるWiFi Explorerという物を使って電波の強度・周辺のWiFiの状況をスキャンしたりもしています。電波強度、チャネルなど様々な情報を一覧・時系列で見ることが出来て電波状況をスキャンするとき、お手軽にPCで出来るので重宝しています。 ケーブルや電波を伝ってくるパケットは様々な形でキャプチャー、問題点の把握などで利用することが出来るので、対象によって使えるようにしておくと便利だと思います。

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューション部の梅崎です今回はローカル5Gについて簡単にご説明させていただきます 簡単に 簡単にローカル5Gとは何かというとこれまで携帯キャリアが行っていた 「特定の周波数の電波を使い排他的に無線通信を行う」 ということを一般事業者も参入できるようになったものです ざっくり言うとマイ5G（マイホーム的な）だと思ってもらって大丈夫です どんなメリットがあるのか？ ローカル5G環境を構築するためには国へ申請を出す必要がありますそうやって国から免許をもらうことで電波のうち一定の範囲の周波数を排他的に利用できます 排他的に利用できるということは既存のWi-Fi等で起こる電波干渉がなくなり、他者の通信に起因する悪影響がなくなるので安定した通信が可能となるということが大きなメリットです もちろん携帯キャリアの5Gと同様の技術を使うため大容量、他接続、低遅延といった5G自体のメリットも享受できます 携帯キャリアの5G、ローカル5G、Wi-Fiの違いは？ 携帯キャリアの5Gはキャリアさんが設備を全て用意/管理してくれ特定多数のユーザーがそれをシェアする形のため程々の費用で快適さは他のユーザー次第の通信になります ローカル5Gは自分で設備を用意するため費用はかかるもののユーザーは免許を受けた電波を独占することができ安定した快適さが保証された通信となります Wi-Fiは個々人が思い思いに設備を用意するため近隣のWi-Fi設備の影響を受け、さらには無線キーボードやマウスといった同じ周波数帯の電波を利用する機器からも影響を受けることがあり設備自体の費用はかなり抑えめですが、通信の快適さは周囲の環境次第という博打的なものとなっています 住居にたとえるならば 「携帯キャリアの5G」は管理会社が面倒を見てくれる「寮」「ローカル5G」は自分で住環境を整え、管理しなければならない「分譲マンション」「Wi-Fi」は快適なときは快適だが酷いときは酷い「キャンプ」 といったところでしょうか ですので正直なところ、このうちのどれを選ぶかはコストと求める品質で要相談だと思います まとめ まとめると ローカル5Gとは自分・自社用のマイ5Gであり多少のコストはかかるが高品質で安定した通信が必要な方向けのもの となります 以上、簡単ではありますがローカル5Gとは？でしたお読みいただきありがとうございました 関連記事 https://developers.gmo.jp/23934/ https://developers.gmo.jp/3938/

初めまして。GMOインターネットグループ株式会社の清水です。みなさんは電気通信主任技術者という国家資格をご存じでしょうか。みなさんがインターネットを使っている裏側ではこの資格を持った人が必要不可欠なのですが、何をしているのかはおろか資格自体初耳という人も多いと思います。この記事では電気通信主任技術者とは何か、そしてインターネットの裏側で電気通信主任技術者はどのようなことをしているのか解説したいと思います。 電気通信主任技術者とは？ インターネットプロバイダサービスを提供している会社では、各家庭からインターネットに接続するための回線設備の維持・運用・管理を行っています。一定以上の規模の回線設備に対してアップグレードなどの理由で工事をするときや、運用管理をする場合にはこれらを監督する責任者が必要になります。その監督するうえで必要な資格が電気通信主任技術者になります。現実の世界でも道路工事や建設工事などには責任者が必ずいると思いますが、電気通信主任技術者はそれのインターネット版だと思っていただけたらイメージしやすいかと思います。 なぜ監督責任者に資格が必要なのかというと、インターネット回線設備を扱うためには専門知識を持った人が必要であり、ひとたび誤った扱いをすると非常に広範囲に影響が出てしまうからです。言うまでもないことですが皆さんが毎日のように利用しているインターネットは生活になくてはならないものであり、電気・ガス・水道といったインフラのように一度止まってしまうと社会に与える影響が非常に大きなものになっています。しかしながら上述した誤った扱いにより非常に多くの人が長時間インターネットを使用できない障害がたびたび発生しています。そのためインターネット回線設備を正しく扱える専門知識を持っていることの証明として電気通信主任技術者があり、それを監督責任者とすることで社会がいつでもどこでもインターネットを使うことができるようにしているのです。 資格を取得するには 電気通信主任技術者の資格を取得するためには、一般財団法人日本データ通信協会が運営する電気通信主任技術者試験に合格する必要があります。試験内容は選択問題のペーパーテストで、3科目すべてで60%以上の点数を取る必要があります（学歴・実務経験により科目免除あり）。 勉強方法としては電気通信主任技術者試験のホームページに過去問が提供されていますので、そちらを確認して試験傾向をつかんでおくのがいいかと思います。また過去問の解説や過去問に出題されている技術内容の解説をしている試験対策本やWebサイトがありますので、過去問を解いて出題内容がわからない場合はそちらを参照するといいと思います。筆者は過去問のほかに下記のような試験対策本をGMOインターネットグループの福利厚生の一つである「学ぼうぜ！」で購入して勉強しました。 https://www.amazon.co.jp/dp/4274217922 資格取得のきっかけ GMOインターネットグループではインターネットプロバイダサービスとしてGMOとくとくBBを10年以上にわたって運営しており、大変多くのお客様がご利用されています。ご利用されているお客様が大変多いため、ひとたび通信障害が発生するとそれが与える社会的影響が甚大なものになります。総務省ではそのようなサービスを提供している会社を法律に基づき、プロバイダサービスを提供するうえでの管理規定の策定と、その管理規定の遵守およびインターネット回線の維持運用管理の監督責任者として電気通信主任技術者の選任を義務付けています。弊社も総務省から指定をいただきましたので、管理規定の策定と電気通信主任技術者の選任を進めていました。 その中でGMOインターネットグループの商材を支えるデータセンターネットワークを担当していた私に資格取得の話が舞い込んできました。 話を聞くうちに自分のスキルアップにつながると考え、数か月間にわたり勉強した結果、無事試験に合格し資格を取得しました。 さいごに 電気通信主任技術者は知名度こそ低いものの、インターネットを安定して使えるようにするためには欠かせない資格です。普段インターネットを使っているときに「インターネットが使えているのは電気通信主任技術者が裏で頑張っている」ということを思い出していただければ幸いです。 ※本記事の情報は記事執筆時点（2022年9月）の情報を基に記載しています。　最新の情報は電気通信主任技術者試験のホームページをご確認ください。

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューション部の梅崎です今回はローカル5G案件でfree5GCをVMで動かしどれだけのトラフィックをさばけるのか試しました 構成 free5GCの全コンポーネント入のVMを一台UERANSIMのUE&gNB相乗りを偶数台 一台のサーバーの中に↑をVMとして作成してそれぞれは同じブリッジに接続しています 端末の接続を行うとデータ通信はUE（端末）<==>UPF（コア）間でカプセリングされやりとりされます 主に使ったもの 5Gコアfree5GCリンク１リンク２5Gアンテナ/端末シミュレーターUERANSIMリンクOSUbuntu 22.04.1 LTSトラフィック生成ツールiperf version 2.1.51台目のサーバー(他にもいろいろ相乗り)CPU: Intel(R) Xeon(R) CPU E5-2630 v2 × 2ソケット（計12コア/24スレッド）メモリー: 128GB* qemu-kvm* libvirt-daemon-system* virtinst* ovmfこの辺をインストールしています2台目のサーバー(次回記載予定) CPU: Intel(R) Xeon(R) CPU E5-2660 v3 × 2ソケット（計20コア/40スレッド）メモリー: 128GB トラフィック印加試験 1台目のサーバーのみ #双方向にトラフィックを200M上限で流す(以下同様のコマンド、上限だけ変更している) #出す側 iperf -i 1 -t 600 -b 200M -l 1400 -c ${受け側の端末へ払い出されたIP} -d #受け側 iperf -s -i 1 この構成だと1ペアだけの通信でも上下合わせて260Mbps弱しかでずさらには10～90秒ほどでUEがシグナルロストしてしまう事象が発生しました 次に4ペアでそれぞれ100Mbps上限でトラフィック印加したところ1ペアのときとは異なり、上下すべて合計で400Mbps程度は出たものの1ペアのときと同じく10～90秒ほどでUEがシグナルロストしてしまう事象が発生しました なお、躓いたポイントとしてを後ほど書くのですがもともとはすべての通信が一つのコアで捌いていたようで上下200Mbpsほどで頭打ちだったのでこの400Mbpsでも良くなった方ではあります ただし、最後のペアは100Mbpsは切断されることはなく7分間は通信し続けることができましたが、やはりしばらく時間が経つと途中で切断されてしまいました…… （この構成ですと400Mbpsの通信の時点でホストマシンのCPU使用率がえらいことになっていました全コアが60数%を超えてくれないのでハイパースレッディングがうまくいってないんですかね？） はまりポイント セキュアブート 今回のfree5GCではUPFのパケットの処理にカーネルモジュールの読み込みが必要なのですがそのままmake installでインストールエラーが出ていました 調べていくとどうも署名が無い（？）ようでセキュアブートが有効になっていると失敗しているようでした なのでセキュアブートを無効化するためvirsh-editでVMの設定の該当の箇所へ↓を追記しました <domain type='kvm'> <os firmware='efi'> <loader secure='no'/> <bootmenu enable='yes'/> ブートメニューの選択肢が出ないようになっていたのでVM側でも↓の設定をしています /etc/default/grubへ↓ ------------------------------ GRUB_TIMEOUT_STYLE=menu GRUB_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=false GRUB_HIDDEN_TIMEOUT=10 ------------------------------ ↑を追記/書き換え sudo update-grub で反映 その後VMを起動するとブートメニューが表示されその中に「UEFIの設定」の項目があるはずなのでそれを選択して設定を開き、セキュアブートを無効化しました net.ipv4.ip_forward free5GCのUPFを動かすサーバーで /etc/sysctl.conf の↓ --------------------- net.ipv4.ip_forward=1 --------------------- ↑のコメントアウトを外すか末尾に追記 を実施することでパケットフォワードしてくれるようになります（iptablesなども適宜許可が必要です） virtio-netのチューニング デフォルトだと一つのコアでしかパケット処理をしてくれないらしく一つのコアだけが使用率100%になっていることがあったのでこちらを参考にキューの数を増やすことでトラフィックフローごとに複数のコアにバランシングされるようにしました また、こちらも行っています（ただ、こちらで性能向上したかはあまり体感はできなかったです……） 所感 色々全部のせでVMを作ったところハイパーバイザ側のブリッジングの処理などですかね？結構CPU負荷が高いようでしてトラフィックを捌くどころかCプレーン的な通信も落としちゃっているような気がしています 一応トラフィック制限をかけ50Mbps程度の通信なら落ちないようなのですがこのままでは実機アンテナとの接続試験どころではないなと感じました 次回 Linux側のチューニングを行うことで多くのトラフィックをさばけるのかもしれないのですが正直今の性能を見るに、チューニングでの性能向上は疑っております…… なので次回は「小技ではなく力技で」ということで5Gコアを別筐体で構築し改めて試験しようと思います