今回は、

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中 part.2

こんばんは、執事です。今回は、この記事の続き。前回、en光クロスに変更してから続いている謎のIPv4瞬断について色々切り分けをしていたところ、XG-100NEのLAN4（10Gbpsポート）が完全に通信できなくなるという、なんとも分かりやす...

butler885.com

2026.10.04

この記事の続き。

前回まで、

enひかりクロス10G＋Xpass環境で、IPv4通信だけが突然遅くなる、というかほぼ繋がらなくなる。

という謎の障害を追い続けていました。

Wi-Fi？

ASUS RT-BE18000？

DNS？

LANケーブル？

MTU？

XG-100NE？

DS-Lite？

Xpass側？

と、まぁ色々疑ってきたわけですが。

ちなみに今回使用している無線LAN環境はASUS RT-BE18000。

現在はXG-100NEをルーター、RT-BE18000をAPモードで使用しています。

今回のIPv4瞬断の原因そのものではありませんでしたが、我が家のWi-Fi環境についてはこの機種を使用しています。

【Amazon.co.jp限定】ASUS WiFi RT-BE18000 無線 ルーター 最新規格WiFi7 11529+5764+688Mbps v6プラス/OCNバーチャルコネクト/クロスパス/transix/IPv6オプション対応 トライバンド デュアル10Gポート 10G光クロス ペアレンタルコントロール&ネットワークセキュリティ機能 家中をカバー エコパッケージモデル

ASUS

【Amazon限定】環境に配慮した包装でお届けします。保証期間は+1年の3年保証

Amazonの商品レビュー・口コミを見る

Amazon

楽天

Yahoo!ショッピング

メルカリ

前回の記事の最後では、

XG-100NEのLAN4（10GbE）まで完全に通信できなくなる。

という別のトラブルまで発生。

「これもうXG-100NE本体が壊れてるんじゃね？」

って事でNTTに来てもらって、XG-100NEそのものを交換してもらいました。

これで流石に直るだろ。

と思ってたんですよ。

XG-100NEを新品交換！LAN4も復活！これで終わり！！

……と思うじゃん？

またIPv4が落ちた(´；ω；`)

しかも交換したその日の夜。

2026年9月16日23時32分頃。

新品になったXG-100NEでも、今までと全く同じような症状が発生しました。

今度はちょうど障害が発生している真っ最中にPCを触っていたので、すぐに確認。

まず、

 ping -4 8.8.8.8

を実行。

すると、

連続でタイムアウト。

しばらくすると、こっちでは何もしてないのに突然19ms前後で応答が復帰。

次に、

 nslookup www.yahoo.co.jp 8.8.8.8

これも、

DNS request timed out。

更に、

 curl -4 -I https://www.yahoo.co.jp/

を実行すると、

約21秒待った後、

Failed to connect。

つまり今回は、

• IPv4 ICMP
• IPv4 DNS
• IPv4 HTTPS

がまとめて通信できなくなっている瞬間を捕まえる事ができました。

それでいて、機器の再起動なんかはしていないのに、その後勝手に復旧する。

やっぱり今までと同じじゃないか。

XG-100NEを新品にしても直らないなら、旧XG-100NEだけの故障ではない

ここは結構大きな切り分けになりました。

旧XG-100NEでは実際にLAN4が通信不能になっていたので、

旧XG-100NEに何らかの故障があった

というのはほぼ間違いないと思います。

実際、新品へ交換したらLAN4は普通に使えるようになりました。

なお、宅内側の切り分けではXG-100NE～ASUS間のLANケーブルも交換して確認しています。

10GbE接続なので、切り分けにはCat6A対応ケーブルを使用しました。

今回のIPv4瞬断そのものはケーブル交換では改善しませんでしたが、10GbE環境で物理層を切り分けるなら、まずここはCat6Aになっているか、Cat7とかCat8になっていないかは確認しておいた方がいいです。

バッファロー ツメの折れないLANケーブル モデム用 カテゴリ6a ストレート フラットタイプ ブラック BSLS6AFU10BK

バッファロー

絶対にツメの折れないLANケーブル!!持ちやすく挿抜しやすいケーブル。

Amazonの商品レビュー・口コミを見る

Amazon

楽天

Yahoo!ショッピング

メルカリ

ただ、

IPv4の瞬断は新品交換後も再発。

となると、

「IPv4瞬断も全部旧XG-100NEの故障でした」

では説明できない。

XG-100NEという機種共通のDS-Lite処理やファームウェアの問題、という可能性はまだ残るものの、

少なくとも、

旧XG-100NEという個体だけが悪かった線はかなり薄くなった。

という事。

そこで、再びenひかりへ障害発生時刻と各種ログを送って再調査をお願いしました。

そしてenひかりから返ってきた回答

で、返ってきた回答の要点だけ抜き出すと、

お客様の通信状況を確認した結果、調査時点で可変IPサービスにおける払い出しポート数の上限に達していることを確認いたしました。

ご申告の通信不安定事象については、上記ポート数制限の影響を受けている可能性が考えられます。

……。

ん？

ポート数の上限？

最初読んだ時、

「Xpass設備全体のポートが足りてないって事？」

と思ったんですが、そうではありませんでした。

更に聞いてみたところ、

ウチの1契約に対して割り当てられているTCP/UDPポート数の上限。

とのこと。

そんな上限に引っ掛かってたんかい！

Xpassの可変IPではIPv4アドレスを複数ユーザーで共有している

ちょっとここは仕組みの話。

Xpassの可変IPv4では、一人一人に専用のグローバルIPv4アドレスが与えられているわけではありません。

ざっくり書くと、

 執事885宅 192.168.1.x → XG-100NE → IPv4をIPv6にカプセル化 → Xpass / DS-Lite → AFTR / CGN → 共有グローバルIPv4 → Internet

という感じ。

グローバルIPv4アドレスを複数ユーザーで共有するので、

各契約者には、IPv4通信で利用できるTCP/UDPポート数に上限が設けられている。

で、その割り当てられたポートを全部使い切った。

これが今回enひかり側で確認された事。

あれ？これって今までの症状にめちゃくちゃ当てはまらない？

ここで過去の症状を思い返してみる。

以前は、

 ping -4 8.8.8.8 →17msで正常 nslookup www.yahoo.co.jp 8.8.8.8 →失敗 curl -4 Yahoo →失敗

という状態がありました。

ICMPのpingは通ってる。

でもTCP/UDP通信が新しく確立できない。

そして時間が経つと自然に戻る。

これ、

ポート枯渇と考えると結構きれいに説明できる。

TCPやUDPの通信に使っていた変換情報が時間経過で解放されれば、また空きポートができる。

空きが出来れば新しい通信が始められる。

だから、

 Yahoo開かない → 何度かリロード → 突然開く

みたいな事も起こり得る。

しかもIPv6はこのIPv4用ポートを使わないので、

IPv4は死んでいるのにIPv6サイトは普通に開く。

これも今までの症状と合う。

もちろん、障害中にIPv4 pingまで落ちたケースもあるので、全ての挙動が単純に「ポート枯渇」の一言だけで説明できるかまでは分かりません。

なお、ICMPのpingにはTCP/UDPのようなポート番号自体がありません。

そのため、IPv4 pingまでタイムアウトしたケースについては、TCP/UDPのポート数上限だけでは説明し切れません。

ポート上限とは別の要因が同時に発生していたのか、Xpass側でIPv4通信全体に影響する状態になっていたのか、その点については現時点では不明です。

ただ少なくとも、

実際に我が家の契約でポート上限に達していた。

これはenひかり側で確認されています。

しかも1回じゃなかった

前回の調査時点で、

お世話になっております。
ご調査ありがとうございます。

その後、NTTにてXG-100NE本体を新品交換していただきましたが、交換後も同一のIPv4通信障害が再発しました。

今回は障害発生を確認した直後に下記試験を実施しております。

・ping -4 8.8.8.8
複数回連続してタイムアウト。その後、機器再起動等を行わず自然に19ms程度へ復旧。

・nslookup www.yahoo.co.jp 8.8.8.8
8.8.8.8をDNSサーバーとして直接指定しましたが、DNS request timed out。

・curl -4 -I https://www.yahoo.co.jp/
約21秒後に接続失敗。

XG-100NE交換後も同一現象が発生していること、またDNSだけではなくIPv4のICMP・DNS・HTTPSが同時に通信不能となることから、宅内DNS設定のみの問題ではないと考えております。

今回事象の最初の発生時刻は 2026年9月16日 23:32～23:34頃（JST） です。

その後も同様の状況が散発的に発生しています。

お手数ですが、「調査時点で正常であるか」だけでなく、上記障害発生時刻について、クロスパス側の収容設備、AFTR、CGN/NATセッション、IPv4側出口設備等にパケットロス、セッション異常、設備負荷、収容逼迫等の記録がないかご確認いただけますでしょうか。

また、ご依頼いただきました「通信先から通信元へのトレースルート」について確認させてください。

DS-Liteでは当方のIPv4通信はAFTR/CGNを経由し、グローバルIPv4アドレスを共有する構成と認識しております。そのため、一般利用者側からYahooやGoogle等の通信先を起点として自宅側への逆方向tracerouteを実施することは困難です。

御社で想定されている具体的な測定方法、利用する測定サイト、または通信先をご指定いただけますでしょうか。

必要であれば、次回事象発生時にもIPv4/IPv6双方のping、traceroute、DNS問い合わせ、HTTPS接続結果を取得いたします。

よろしくお願いいたします。

という内容でenひかりへメールを送り、2026年9月16日23:32～23:34頃に実際に発生した障害について確認をお願いしていました。

その後、enひかり側で更に調査したところ、この時間帯とは別に、以下の日時にも我が家の契約でポート数上限への到達を確認していたとのこと。

• 2026年9月16日 11:35頃
• 2026年9月18日 15:03頃

つまり、単に「ポート上限に達している可能性があります」という推測ではなく、実際に複数回、我が家の契約でポート数上限に到達していた記録が残っているという事です。

ちなみにログそのものや具体的な使用ポート数については開示できない、との回答でした。

そしてもっと気になったのが「これは正常な仕様です」という回答

そこで、

「ポート数上限まで達して、普通のWebサイトやDNS通信まで失敗する状態って、設備異常なんですか？それとも仕様なんですか？」

と聞いてみました。

回答は、

可変IPサービスの仕様上、想定される動作となります。

とのこと。

つまり、

ポート上限に達するとIPv4通信に制限が生じること自体は、**「仕様上想定される動作」**。

という回答。

なるほど。

いや、仕組みとしては分かる。

IPv4アドレスが枯渇してるから共有して使ってる。

だから使えるポート数にも限界がある。

そこまでは分かる。

でもさ。

じゃあ、その上限って何ポートなの？

ここですよ。

今回、

実際にウチが上限まで到達した。

と言われてるわけです。

じゃあ、

「一体何ポート使ったら上限なの？」

と思うじゃないですか。

でも、

具体的な割り当てポート数は非公開。

なんです。

しかも、利用者側からは、

• 自分に何ポート割り当てられているのか分からない
• 今何ポート使っているのか分からない
• 上限の何％まで来ているのか分からない
• どの端末がどの程度ポートを使っているのか分からない
• あと何台繋いだら危ないのかも分からない

という状態。

それなのに上限に達すると、

普通のIPv4 Web通信まで断続的に失敗する可能性がある。

そして障害が出た後に問い合わせをして初めて、

「ポート数上限まで到達してますね」

と分かる。

……。

利用者側では対策のしようがなくない？(´・ω・`)

「一般的な利用を想定して必要十分なポート数」とのこと

この辺も気になったので、

「一般家庭でPC、スマホ、Webカメラ等を複数使っていたら上限に達する事も想定しているの？」

と聞いてみました。

回答は、

一般的な利用方法を想定して、必要十分なポート数の割り当てを行っております。

なお、ポートの利用状況は、同時に利用される端末・アプリケーション数や通信状況によって異なります。

そのため、ご利用状況によってはポート数の上限に達する場合がございます。

とのこと。

うん。

言ってる事は分かる。

でも、

「一般的な利用方法」って何台なの？

ってなる。

我が家には、

PC、

スマホ、

タブレット、

Fire TV、

ゲーム機、

ATOM Cam、

その他IoT機器、

なんかが繋がっています。

確かに昔ながらの、

 PC 1台 スマホ 2台

みたいな家よりは多いと思う。

でも今どき、

スマート家電やネットワークカメラ、TV、ゲーム機、タブレットなんかを全部合わせたら、

20台、30台ネットワークにぶら下がっている家庭ってそこまで珍しくないと思うんですよね。

少なくとも、

特殊なサーバーを何十台も公開してる、とか、

大量のP2P通信を意図的に走らせてる、

とかではない。

そこで更に、

「一般的利用を想定して必要十分」と言うなら、何台・何通信程度を想定しているの？

と問い合わせています。

ちなみに、アイキャッチ画像に置いていますが、記事執筆時点で、XG-100NEのDHCPv4払い出し状況は18件でした。

少なくとも数百台を接続しているような特殊な環境ではありません。

固定IPへ変更してください、と言われても…

enひかりからは、

ポート上限へ達するような利用環境なら、

クロスパス固定IPサービスを検討してください。

とも案内されました。

固定IPならIPv4アドレスを共有しないので、今回のような共有ポート数制限の問題からは解放される。

理屈は分かります。

ただし、

XG-100NEはクロスパス固定IPに対応していない。

とのこと。

……。

10Gbps回線にする。

↓

ひかり電話を使うためXG-100NEを使う。

↓

Xpass可変IPを使う。

↓

ポート上限に達する。

↓

固定IPを使ってください。

↓

XG-100NEは固定IP非対応です。

いや、どないせぇっちゅうねんｗ

そもそも契約時にそんな違いを説明されたっけ？

で、ここからは技術的な話というより、

利用者への説明としてどうなの？

という話になってきます。

自分がenひかりクロスを契約した時、

接続方式として、

• v6プラス
• transix
• Xpass

等が選べるので、

電話口で、

「これって何が違うんですか？」

と聞いています。

その時の説明として自分が受け取った内容は、

大きな違いはなく、どれも10Gbps回線で使える。

という程度のもの。

なので、

「じゃあXpassでいいかな」

くらいの感覚で選びました。

少なくとも、

「Xpass可変IPには契約単位のポート上限があり、その上限に達すると通常のWeb閲覧やDNS通信まで断続的に失敗する可能性があります」

なんて説明は受けた記憶がありません。

もちろん後から調べれば、

Webサイトや重要事項説明には、

IPv4アドレスを共有するのでポート数に制限があります。

という内容自体は記載されています。

なので、

「一切書いてないじゃないか！」

という話ではありません。

そこはちゃんと書いてある。

ただね。

「HPに書いてあります」「規約に書いてあります」で済ませて良い話なのか？

今回、自分自身がここまで調査してみて思うのはここ。

ポート制限があります。

という一文を見て、

普通の利用者が、

 ポート上限に到達 → CGN/NATで新規TCP/UDPセッションが作れなくなる → DNS問い合わせ失敗 → HTTPS接続失敗 → Yahooすら断続的に開かなくなる

まで想像できるのか？

って話。

しかも上限値は非公開。

今何ポート使っているかも見えない。

上限までどれくらい余裕があるのかも見えない。

事業者側では、

「9月16日11:35頃に上限に達してましたよ」

と確認できる。

でも利用者側では分からない。

今回なんて自分は、

Wi-Fiを疑い、

ASUSを疑い、

DNSを疑い、

LANケーブルを交換し、

MTUを調べ、

pingを取り、

tracerouteを取り、

curlを打ち、

nslookupを打ち、

XG-100NEのログを何日も調べ、

最終的にXG-100NEまで新品に交換してるんですよ。

で、原因候補が「実は契約ごとのポート上限まで使ってました」って。

いや、

それそっちでは最初から確認できる情報なんかいｗ

って思いますよね。

9月19日23:40、再びIPv4瞬断が発生

この記事を書いている途中、9月18日頃から、それまで一日に何度も発生していたIPv4瞬断をしばらく確認していませんでした。

enひかり側では9月18日15:03頃にも、我が家の契約でポート数上限への到達を確認しているとのことでしたが、自分自身はその時間帯に従来のような瞬断を認識していませんでした。

なので、

「もしかして今回の調査に伴って、何か設定や収容先が変更された？」

なんて事も考えていたんですが……。

2026年9月19日23:40頃、再び同様のIPv4瞬断が発生しました。

やっぱり直ってなかった(´；ω；`)

少なくとも、9月18日以降しばらく症状が出ていなかったのは、恒久的に改善していたわけではなさそうです。

一方で、今回の23:40頃の瞬断について、enひかり側で同時刻にポート数上限へ到達していたかどうかまでは現時点では確認できていません。

そのため、

「今回の23:40の瞬断もポート上限到達が直接の原因だった」

とまでは断定しません。

ただ、これまでに我が家の契約で実際に複数回ポート上限へ到達していることはenひかり側で確認されており、今回も過去と同様のIPv4瞬断が再発したことになります。

つまり、ポート上限問題については引き続き解決しておらず、症状も継続している状態です。

なお、ポート上限到達＝必ず即座に体感できる通信断、というわけではない可能性もあります。

9月18日15:03にはenひかり側で上限到達を確認している一方、自分自身はその時刻に瞬断を認識していなかったためです。

ポート上限に達した時に、どの通信がどの程度影響を受けるのかについても、もう少し情報が欲しいところです。

enひかりへ更に確認している内容

現在、以下について回答待ち。

1. ウチ1契約に割り当てられている具体的なポート数、または概算
2. 具体的なポート上限を非公開にしている理由
3. 利用者側で現在のポート使用数を確認する方法があるのか
4. 「一般的な利用」とは何台・どの程度の通信を想定しているのか
5. 一般的なWeb閲覧やDNS通信まで失敗する可能性について、契約前に具体的に案内している場所
6. 今回の調査に伴って、ウチの割当ポート・収容先・AFTR/CGN設定等を変更したのか

この回答は結構重要だと思っています。

特に、

何ポートなのか。

ここ。

例えば、

「一般家庭には○万ポート程度割り当ててあります」

と分かれば、

まだ利用者側でも考えようがある。

でも、

 上限値 → 秘密, 現在値 → 見えない, 残り → 見えない, 目安 → 不明, 超えた時 → Internetが不安定になる

では、

利用者はどうやって自分の使い方が適正なのか判断すればいいの？

と思うわけです。

総務省にも相談してみようと思う

なので今回、

enひかり側にも、

総務省の電気通信サービスに関する消費者相談窓口へ相談し、見解を確認する予定

と伝えています。

別に、

「enひかりは違法だ！」

とか、

「訴えてやる！」

なんて話ではありません。

そもそも自分は、enひかりを3年以上使っていて、料金面やこれまでの1Gbps回線にはかなり満足していました。

今回もサポート自体はちゃんと調査して回答してくれている。

だから、

enひかりを攻撃したいわけでは全然ない。

問題に感じているのは、

サービスの仕様として存在する大きな制限を、利用者が事前にも利用中にも実質的に把握できない状態で良いのか？

という部分。

規約に書いてある。

HPに書いてある。

というのは分かります。

でも実際に何ポート使えるのかは分からない。

使用量も見えない。

上限が近いかも分からない。

そして上限を超えた結果として、

普通のWeb閲覧まで使えなくなる。

今回みたいなケースを、

「利用者が事前に十分理解した上で契約を選べる状態だった」

と言えるのか？

これはちょっと、

第三者である総務省側の見解も聞いてみたいと思っています。

ここまでの時系列を一回整理

長くなってきたので一度まとめます。

9月14日16:55

enひかりへIPv4瞬断の詳細を報告。

↓

9月14日17:33

更にXG-100NEのLAN4（10GbE）が完全通信不能になった事を追加報告。

ただしLAN1～3でもIPv4瞬断は発生。

↓

9月16日11:35頃

後の回答で、この時刻にウチの契約がポート上限へ到達していた事が判明。

↓

9月16日11:39

enひかりから、

「可変IPサービスにおける払い出しポート数の上限に達している」

との初回回答。

↓

NTTがXG-100NEを新品交換。

LAN4は復旧。

↓

9月16日23:32頃

新品XG-100NEでもIPv4瞬断再発。

ping、nslookup、curlでIPv4通信失敗を確認。

↓

9月17日13:42

XG交換後も障害が再発した事と詳細ログをenひかりへ追加報告。

↓

9月17日21:06

ポート上限とは具体的に何なのか、設備全体なのか契約単位なのか等を質問。

↓

9月18日15:03頃

enひかり側で再びウチの契約がポート上限へ到達していた事を確認。

↓

9月19日10:02

enひかりから、

「1契約ごとのTCP/UDPポート上限で間違いない」

「上限到達によるIPv4通信制限は仕様上想定された動作」

「一般利用を想定して必要十分なポート数を割り当てている」

との正式回答。

↓

9月19日17:39

執事885から、

具体的上限値、利用状況を確認する方法、一般利用の想定、契約前説明、設定変更の有無等を更に質問。

総務省への相談も予定している旨を通知。

↓

9月19日23:40頃

再び従来と同様のIPv4瞬断が発生。

9月18日以降しばらく症状を確認していなかったものの、恒久的に改善していたわけではないことが判明。

なお、この瞬断発生時刻にポート数上限へ到達していたかについては現時点では未確認。

↓

現在回答待ち。

まとめ

というわけで、

長いこと追いかけてきた、

enひかりクロス＋XpassのIPv4瞬断問題。

ようやく、

「可変IPv4で1契約に割り当てられているTCP/UDPポート数の上限へ、実際に到達していた」

という具体的な事実まで辿り着きました。

正直、

最初からこれが分かってれば、

XG-100NEのSPIタイムアウトがどうとか、

DNSがどうとか、

MTUがどうとか、

2時間おきのDHCP更新がどうとか、

あんなに追い回してないｗ

ただ、そこまで色々切り分けたからこそ、

今回の回答を見て、

「あー、それなら確かに今までの挙動と合うわ」

とも思える。

でも同時に、

その上限が利用者から全く見えないのはどうなの？

という新しい疑問も出てきました。

そしてこれ、

自分だけの特殊事例ならまだいい。

でも今後、

スマート家電、

防犯カメラ、

ゲーム機、

PC、

スマホ、

タブレット、

テレビ、

その他IoT機器、

なんかが家庭内にどんどん増えていけば、

同じところに引っ掛かる家庭が出てきても全然おかしくないと思うんですよね。

しかもその時、

利用者側から見えるのは、

「なんかInternetが時々繋がらない」

だけ。

これ、原因分からんて。

10Gbps回線にしたら、通信速度よりIPv4のポート管理に詳しくなるとは思わんかったわｗ

enひかりから次の回答が来たら、

具体的なポート上限や、

今回何か設定変更が行われたのか、

そして契約時の説明についてどういう回答になるのか、

また続きを記事にしたいと思います。

それと総務省にも一度相談してみる予定。

さて、

このシリーズ、

一体どこまで続くんでしょうかね(´・ω・`)

関連記事

光クロス(10Gbps回線）のXpassとXG-100NE運用でipv4が瞬断する問題についてあれこれ検証　part.1

こんばんは、執事です。今回は、これらの記事の続きです。ファンを取り付けて落ち着いたと思ったんだけど、やっぱり瞬断が発生する。しかも、主にipv4接続でのみ発生。Xpass(DS-Lite)ではIPv6はIPoEでそのまま通信し、IPv4はD...

butler885.com

2026.10.04

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中 part.2

こんばんは、執事です。今回は、この記事の続き。前回、en光クロスに変更してから続いている謎のIPv4瞬断について色々切り分けをしていたところ、XG-100NEのLAN4（10Gbpsポート）が完全に通信できなくなるという、なんとも分かりやす...

butler885.com

2026.10.04

enひかりクロス XpassのIPv4瞬断とポート上限問題。10Gbps化後に通信品質が低下した件を総務省にも相談予定 part.4

こんにちは、執事です。今回は、この記事の続き。前回の記事では、enひかりクロス10G＋Xpass環境で長いこと悩まされていたIPv4瞬断について、我が家の1契約に割り当てられているTCP/UDPポート数が、実際に上限へ到達していたことがen...

butler885.com

2026.10.04

enひかりクロス XpassのIPv4瞬断・ポート上限問題を総務省へ情報提供。現在はenひかりの回答待ち part.5

こんにちは、執事です。今回は、この記事の続き。前回の記事では、enひかりクロス10G＋Xpassで発生しているIPv4瞬断と、契約単位のTCP/UDPポート数上限問題について、総務省にも相談してみる予定。というところまで書きました。で、連休...

butler885.com

2026.10.04

enひかりクロス XpassのIPv4瞬断問題その後。9日待って進捗確認、ポート割当やAFTR/CGNの設定変更は「なし」との回答 part.6

こんにちは、執事です。今回は、この記事の続き。前回の記事では、enひかりクロス10G＋Xpassで発生しているIPv4瞬断・ポート上限問題について、総務省へ情報提供。そして、enひかり側にも追加質問を投げて、回答待ち。というところまで書きま...

butler885.com

2026.10.05