PPPoE 接続の仕組みと設定の基本｜主要 4 メーカーの設計比較

はじめに

日本のインターネット接続（特にフレッツ光などの回線）において、長年スタンダードとして使われてきた PPPoE。近年は IPoE（IPv4 over IPv6）への移行が進んでいますが、固定 IP の利用や閉域網接続、既存環境の維持運用など、PPPoE は今も現場で扱う機会の多い技術です。IPoE 方式との違いや使い分けについては、関連記事『IPoE（IPv4 over IPv6）方式の仕組みとルーター設定手順』で整理しています。

本記事では、PPPoE の仕組みと接続フローを整理したうえで、フレッツ網での MTU / MSS 設計の根拠、主要 4 メーカー（Cisco / FortiGate / YAMAHA / NEC）の設定要素の横断比較、設計時に共通して押さえたい制約事項までをまとめます。各メーカーの具体的な設定コマンドと機種別のトラブルシューティングは、それぞれの詳細記事（機種別ガイド）で解説しています。

PPPoE は Ethernet 上に仮想的な 1 対 1 セッションを確立し、その中で PPP の認証・IP 払い出しを行うプロトコルです。メーカーごとにコマンド体系は異なりますが、設計要素（論理インターフェースの紐づけ・認証・MTU / MSS・NAT）は 4 メーカーで共通しており、フレッツ網では MTU 1454 / MSS 1414 を基準に設計します。

なぜ PPPoE が生まれたか

電話回線時代の主流は、ID とパスワードで認証するダイヤルアップ接続（PPP）でした。その後、ADSL や光ファイバーといった常時接続（Ethernet）が普及しましたが、ISP（プロバイダー）側にはユーザーごとに ID / パスワードで認証して接続を管理する仕組みを引き続き利用したいというニーズがありました。

そこで、Ethernet 上で従来の PPP を動作させるために考案されたのが PPPoE（PPP over Ethernet）です。Ethernet の物理的な接続性と、PPP の認証・管理機能を組み合わせたプロトコルとして、ISP の運用要件に応える形で広く採用されました。

Ethernet・PPP・PPPoE の関係

PPPoE は、その名のとおり Ethernet（LAN の技術）の上で PPP（電話回線時代の技術）を利用するプロトコルです。

Ethernet

マルチアクセスネットワーク。手軽で高速だが、ユーザー認証や課金管理（AAA 機能）の仕組みを持たない

PPP

1 対 1 で接続するプロトコル。ID / パスワードによるユーザー認証や、IP アドレス割り当ての機能を持つ

PPPoE

Ethernet 上に仮想的な 1 対 1 のセッションを確立し、その中で PPP 通信を行う技術。Ethernet 環境でも ISP 側で認証・管理が可能になる

PPPoE の接続フロー（2 つのステージ）

PPPoE は、通信開始までにディスカバリステージとセッションステージの 2 段階を経由します。各メーカーのデバッグコマンドで切り分けを行う際も、「どちらのステージで止まっているか」を最初に特定するのが基本です。

ディスカバリステージ（EtherType 0x8863）

クライアント（ルーター）が接続先のサーバー（BAS: Broadband Access Server）を探索し、セッション ID を取得する段階です。以下のパケットを順にやりとりします。

1. PADI（PPPoE Active Discovery Initiation）: クライアントからのブロードキャスト
2. PADO（PPPoE Active Discovery Offer）: サーバーからの応答
3. PADR（PPPoE Active Discovery Request）: クライアントからのセッション要求
4. PADS（PPPoE Active Discovery Session-confirmation）: サーバーからのセッション ID 通知

ディスカバリステージで使用される EtherType は 0x8863 です。

参考: RFC 2516（A Method for Transmitting PPP Over Ethernet）
“it must first perform Discovery to identify the Ethernet MAC address of the peer”
（ホストはまずディスカバリを実行し、対向の Ethernet MAC アドレスを特定する必要があります）
https://datatracker.ietf.org/doc/html/rfc2516

セッションステージ（EtherType 0x8864）

セッションが確立した後、その仮想セッションの中で PPP のネゴシエーションが行われます。LCP（Link Control Protocol）でリンクパラメータを交渉し、CHAP / PAP で認証を行い、IPCP（IP Control Protocol）で IP アドレスを取得します。完了するとインターネット通信が可能になります。

セッションステージで使用される EtherType は 0x8864 です。

フレッツ網での MTU / MSS 設計

PPPoE 設定で必ず登場する 1454 や 1414 という値には、明確な根拠があります。この設計を誤ると、Web サイトの一部が表示されない、通信が極端に遅くなるといったトラブル（Path MTU Discovery ブラックホール問題）が発生する可能性があります。

なぜ MTU は 1454 byte なのか

通常の Ethernet では、一度に運べるデータの最大サイズ（MTU）は 1500 byte です。一方、NTT 東西のフレッツ網（地域 IP 網 / NGN）を通る際は、複数のヘッダがデータの先頭に付与されます。

内訳	サイズ
Ethernet MTU	1500 byte
PPPoE ヘッダ	-6 byte
PPP ヘッダ	-2 byte
NTT 網内の転送用ヘッダ（トンネリングや VLAN タグ等）	-38 byte
ユーザーが利用できる実効サイズ	1454 byte

合計 46 byte 分のオーバーヘッドが発生するため、フレッツ接続時の MTU は 1454 byte となります。この値は NTT 東日本の技術参考資料でも規定されている公式仕様です。

参考: NTT 東日本 / 技術参考資料 IP 通信網サービスのインタフェース ―フレッツシリーズ― 第三分冊
「フレッツ 光ネクストでは IP 通信網における IPv4 通信の MTU 値は 1454byte です。IP 通信網が MTU 値を超えるパケットを受信した場合、IP 通信網はパケットを分割転送、または破棄する場合があります」
https://www.ntt-east.co.jp/info-st/katsuyou/h23/temp24-1.pdf

これを考慮せず 1500 byte のまま送出すると、網の入口でフラグメントされたり破棄されたりして、通信効率の低下や通信断につながります。なお、フレッツ網を経由しない純粋な PPPoE 環境では、Ethernet 1500 byte から PPPoE ヘッダ 6 byte ＋ PPP Protocol ID 2 byte を差し引いた 1492 byte が標準値になります。検証環境などでサーバー側から構築する場合の考え方は、関連記事『Cisco ルーターで PPPoE サーバーを構築する手順｜VRF 連携のポイント』で整理しています。

MTU と MRU の違い

PPPoE の設計では、似た用語である MTU と MRU を区別して理解しておく必要があります。

MTU（Maximum Transmission Unit）

自分が送信できる最大サイズ

MRU（Maximum Receive Unit）

自分が受信できる最大サイズ。PPP の接続開始時（LCP ネゴシエーション）に相手へ通知する値

PPPoE では、RFC 2516 の制約により LCP でネゴシエーションできる MRU の上限は 1492 byte と定められており、Cisco をはじめ各メーカーの実装もこの値を既定としています。

参考: Cisco / Broadband Access Aggregation and DSL Configuration Guide – PPP over Ethernet Client
“mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492”
（RFC 2516 では、ネゴシエーション可能な MRU の最大値を 1492 と定めています）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/15-mt/bba-15-mt-book/bba-ppoe-client.html

ここで注意したいのが、「IP パケットのサイズ制限」と「インターフェースの MTU」を別のコマンドで設定するメーカーがある点です。たとえば Cisco では、ip mtu のみを設定すると IP パケットの制限は 1454 になるものの、LCP で対向に通知される MRU は 1500 のままとなり、対向側が 1500 byte のパケットを送ってくる余地が残ります。結果として、フレッツ網内での破棄や再送が発生する設計になります。インターフェース自体の MTU を 1454 に設定し、送受信の両方向で整合を取るのが基本です。各メーカーでの具体的な設定コマンドは、機種別ガイドで解説しています。

MSS Clamping の考え方

MTU が IP パケット全体の上限であるのに対し、MSS（Maximum Segment Size）は TCP のデータ部分の上限です。MTU 1454 から IP ヘッダ 20 byte と TCP ヘッダ 20 byte を差し引いた 1414 byte が、フレッツ網での MSS の基準値になります。

ルーターが TCP の 3 ウェイハンドシェイク時に MSS 値を書き換えることで、エンド端末側の設定変更なしにフラグメントの発生を抑えられます（MSS Clamping）。調整は送信側・受信側のどちらでも有効化できますが、フラグメント抑制の観点では PPPoE インターフェース上で双方向に効かせる設計が安全です。設定の書き場所はメーカーによって異なり、Cisco / NEC はインターフェース配下、FortiGate はファイアウォールポリシー内、YAMAHA は ip pp tcp mss limit auto による自動調整が基本になります。詳細は各機種別ガイドを参照してください。

主要 4 メーカーの設定要素比較

主要 4 メーカーの PPPoE 設定要素を、設計上の論点ごとに整理すると次のとおりです。メーカー間のコマンド体系は異なるものの、考慮する設計要素（論理インターフェース・認証・MTU / MSS・NAT）は共通しています。比較表で全体像を把握したうえで、構築する機種の詳細手順は各機種別ガイドを参照してください。

比較早見表（論理 IF・認証・NAT・確認コマンド）

設計要素	Cisco	FortiGate	YAMAHA	NEC IX
論理 IF の単位	Dialer インターフェース	物理 IF / pppoe-interface	pp（Point-to-Point）	Dialer インターフェース
物理 IF への紐づけ	pppoe-client dial-pool-number	set mode pppoe（物理 IF 内）	pppoe use lan2	dialer bind-interface
紐づけの方向	物理 → Dialer	物理 IF 自体に PPPoE 設定	pp 内から物理を指定	Dialer → 物理
認証情報	ppp chap hostname ＋ ppp chap password	set username ＋ set password	pp auth myname	ppp chap hostname ＋ ppp chap password
MTU 設定	mtu 1454（Dialer）	set mtu-override enable ＋ set mtu 1454	ppp lcp mru on 1454 ＋ ip pp mtu 1454	mtu 1454（Dialer）
MSS 調整	ip tcp adjust-mss 1414	ポリシーで tcp-mss-sender / receiver 指定	ip pp tcp mss limit auto	ip tcp adjust-mss 1414
NAT 有効化	ip nat inside source list ... overload	ポリシーで set nat enable	NAT ディスクリプタを定義し pp に適用	ip napt enable（IF 内 1 行）
デフォルトルート	ppp ipcp route default	set defaultgw enable	ip route default gateway pp 1	ip route default Dialer0
接続確認	show pppoe session	get system interface	show status pp 1	show pppoe session
通信ポリシー要否	不要（ACL でフィルタは可能）	必須（ファイアウォール製品のため）	不要（フィルタは別途設定）	不要（フィルタは別途設定）

この表から読み取れる設計上のポイントは 3 つあります。第一に、論理インターフェースの概念がメーカーごとに独立していること（Cisco / NEC は Dialer、FortiGate は物理 IF または pppoe-interface、YAMAHA は pp）。第二に、物理ポートと論理 IF の紐づけ方向が Cisco と NEC で逆になること。第三に、NAT 設定の「書き場所」が 4 社 4 様であり、NAT が機能しない場合のトラブルシューティング起点がメーカーごとに異なることです。

Cisco（IOS / IOS XE）の要点

Dialer インターフェースという仮想インターフェースが PPPoE の主体となり、認証・IP アドレス・MTU / MSS を Dialer 配下で管理します。物理インターフェース側には pppoe enable と pppoe-client dial-pool-number を設定し、物理 → Dialer の方向で紐づけます。NAT は ACL とグローバル設定（ip nat inside source list ... overload）の組み合わせで構成します。

具体的なコンフィグ例、ip address negotiated や dialer pool といった各コマンドの意味、debug pppoe / debug ppp negotiation を使った切り分け手順は、関連記事『Cisco ルーターの PPPoE 設定手順｜Dialer 構成と ip mtu の違い』で解説しています。なお、Cisco ルーターを対向のサーバー側として構築する手順は、関連記事『Cisco ルーターで PPPoE サーバーを構築する手順｜VRF 連携のポイント』を参照してください。

FortiGate（FortiOS）の要点

物理ポートのモードを set mode pppoe に変更する方式と、config system pppoe-interface で論理的な PPPoE インターフェースを定義する方式（IPv4 / IPv6 併用時に有効、FortiOS 6.2 以降）の 2 通りがあります。

参考: Fortinet Document Library / config system pppoe-interface（FortiOS 7.4 CLI Reference）
“Configure the PPPoE interfaces.”
（PPPoE インターフェースを設定します）
https://docs.fortinet.com/document/fortigate/7.4.4/cli-reference/268798926/config-system-pppoe-interface

他の 3 メーカーと最も異なるのは、ファイアウォールポリシーの定義が通信の前提となる点です。PPPoE セッションが UP しているのに通信できない場合、まずポリシーの定義状況を確認します。MSS 調整もポリシー内（tcp-mss-sender / receiver）で行います。2 方式の使い分け、GUI での設定可否（FortiOS バージョンによる差異）、固定 IP・VLAN 構成、再接続まわりのチューニングと diagnose debug application pppoed による切り分けは、関連記事『FortiGate の PPPoE 設定手順｜ポリシー前提と確認コマンド』で解説しています。

YAMAHA RTX の要点

pp select で pp（Point-to-Point）という論理インターフェースを選択してから設定を記述する、独自のコマンド体系を持ちます。NAT は NAT ディスクリプタを定義し、それを pp に適用（バインド）する 2 段構成で、定義側と適用側の ID が一致していないと「セッションは確立するのに通信できない」状態になります。トラブルシューティングの典型的な起点です。

pp auth myname をはじめとする各コマンドの意味、NAT ディスクリプタの設計、IPv6 PPPoE との併用構成、GUI（Web 設定画面）からの設定手順は、関連記事『YAMAHA RTX の PPPoE 設定手順｜pp と NAT ディスクリプタの勘所』で解説しています。

NEC UNIVERGE IX の要点

コマンド体系は Cisco IOS に近いものの、紐づけの方向が逆で、Dialer インターフェース側から dialer bind-interface で物理ポートを指定します。複数メーカーを併用する現場で混同しやすいポイントです。NAT は ACL を定義する必要がなく、インターフェース配下の ip napt enable 1 行で NAPT が有効化されます。

コンフィグ例、NAPT エントリ数のチューニング、切り分けコマンドは、関連記事『NEC UNIVERGE IX の PPPoE 設定手順｜Cisco との違いと NAPT』で解説しています。

設計時に押さえたい共通の制約事項

メーカーごとの構文の違いとは別に、PPPoE の設計時に共通して押さえておきたいポイントを整理します。

認証プロトコル（CHAP / PAP）の選定

PPP の認証プロトコルには CHAP と PAP があります。

CHAP（Challenge Handshake Authentication Protocol）

チャレンジ＆レスポンス方式で、パスワードが平文で流れない

PAP（Password Authentication Protocol）

認証時にパスワードが平文で送信される

セキュリティ上は CHAP の利用が推奨されますが、ISP やプロバイダーによっては PAP のみ受け付けるケースもあります。設定では chap pap のように両方を許可する書き方が広く採用されており、対向の要件に応じて自動的にネゴシエーションされます。

VLAN タグ付き PPPoE への対応

ISP やキャリアによっては、PPPoE に VLAN タグを付与する仕様があります（フレッツ クロスの一部の構成、海外 ISP の DSL など）。いずれのメーカーも「タグ付きの論理インターフェースを作成し、そこで PPPoE を有効化する」という考え方は共通です。

Cisco

物理 IF にサブインターフェース（encapsulation dot1Q <vlan-id>）を作成し、その配下で PPPoE を有効化

FortiGate

VLAN インターフェースを作成し、そのインターフェースに対して set mode pppoe を設定

YAMAHA

vlan コマンドでタグ付きインターフェースを作成し、pppoe use で参照

NEC IX

物理 IF にサブインターフェース（vlan-id）を作成し、そこで PPPoE を有効化

ISP が指定する VLAN ID は事前に確認しておく必要があります。

PADT と切断時の挙動、1 セッション = 1 IP の前提

PPPoE セッションの切断は PADT（PPPoE Active Discovery Terminate）パケットで通知されます。

参考: RFC 2516（A Method for Transmitting PPP Over Ethernet）
“may be sent anytime after a session is established”
（PADT はセッション確立後の任意のタイミングで送信される可能性があります）
https://datatracker.ietf.org/doc/html/rfc2516

回線切断時にクライアント側のセッションが残ってしまうと、再接続時に「サーバー側でセッション数の上限に達している」と判定されることがあります。LCP echo（keepalive）を有効化して対向の死活を検知しやすくするとともに、再接続タイマーの調整を環境に合わせて検討することをおすすめします（具体的なコマンドは各機種別ガイドで解説しています）。

トラブルシューティングの共通切り分けステップ

メーカーを問わず、PPPoE が想定どおりに動作しない場合は以下の 5 段階で切り分けると効率的です。機種別のデバッグコマンドは各機種別ガイドにまとめています。

ステップ 1〜2 で止まる場合は配線・VLAN 設定・対向設備、ステップ 3 はプロバイダーから通知された認証情報、ステップ 4 は本記事「フレッツ網での MTU / MSS 設計」の設計値、ステップ 5 はメーカーごとの NAT の「書き場所」（比較早見表を参照）が、それぞれ確認の起点になります。

まとめ

本記事では、PPPoE の仕組みと接続フロー、フレッツ網での MTU / MSS 設計の根拠、主要 4 メーカーの設計比較までを整理しました。メーカーごとにコマンド体系は異なりますが、考慮すべき設計要素は共通しており、比較表で全体像を押さえたうえで機種別ガイドへ進む流れが効率的です。

• PPPoE は Ethernet 上に仮想セッションを確立し PPP の認証機能を利用する技術
• 接続はディスカバリとセッションの 2 段階で確立し、切り分けもこの単位で行う。
• フレッツ網では NTT 公式仕様に基づき MTU 1454 / MSS 1414 を基準に設計
• MRU は LCP で対向に通知される値のため、インターフェース MTU との整合が重要
• 設計要素（論理 IF・認証・MTU / MSS・NAT）は 4 メーカー共通で、書き場所のみ異なる。
• FortiGate はポリシー前提、YAMAHA は NAT ディスクリプタの ID 一致が確認の起点
• 機種別の設定コマンドと詳細な切り分け手順は各機種別ガイドを参照

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