PPPoE 接続設定の手順｜Cisco / FortiGate / YAMAHA / NEC の違い

はじめに

日本のインターネット接続（特にフレッツ光などの回線）において、長年スタンダードとして使われてきた PPPoE。近年は IPoE（IPv4 over IPv6）が普及していますが、固定 IP の利用や閉域網接続など、PPPoE は今も現場で活用される重要な技術です。

ただし、ルーターのメーカーによって設定コマンドや論理構造の組み立て方は異なります。本記事では、PPPoE の仕組みの基礎から、日本の現場で導入実績の多い 主要 4 メーカー（Cisco / FortiGate / YAMAHA / NEC） のクライアント設定コマンドを整理します。検証は以下のバージョンを前提にしています。

• Cisco: IOS / IOS XE 17.x 系
• FortiGate: FortiOS 7.4 / 7.6 系
• YAMAHA: RTX1300 / RTX1220 / RTX830（Rev.15 系）
• NEC: UNIVERGE IX シリーズ（Ver.10 系）

なお、Cisco ルーターを PPPoE サーバー側 として構築する手順については、関連記事『Cisco ルーターで PPPoE サーバーを構築する手順｜VRF 連携のポイント』で整理しています。クライアント側・サーバー側の両方を組み合わせた検証環境の構築に役立ちます。

なぜ PPPoE が生まれたか

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

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

PPPoE の仕組みと接続フロー

設定に入る前に、PPPoE がどのような仕組みで通信を確立しているのかを整理します。

Ethernet・PPP・PPPoE の関係

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

Ethernet

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

PPP

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

PPPoE

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

IP 通信までの流れ（2 つのステージ）

PPPoE は、通信開始までに ディスカバリステージ と セッションステージ の 2 段階を経由します。

STEP

PPPoE ディスカバリステージ（接続先の特定）

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

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

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

STEP

PPP セッションステージ（認証と IP アドレス取得）

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

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

参考: RFC 2516（A Method for Transmitting PPP Over Ethernet）
“Stage 1, Discovery: When a Host wishes to initiate a PPPoE session, it must first perform Discovery to identify the Ethernet MAC address of the peer and establish a PPPoE SESSION_ID.”
（ステージ 1 のディスカバリでは、ホストが PPPoE セッションを開始する際に、対向の Ethernet MAC アドレスを特定し PPPoE SESSION_ID を確立します）
https://datatracker.ietf.org/doc/html/rfc2516

Cisco ルーター（IOS / IOS XE）の設定例

Cisco ルーターでは、物理インターフェース で PPPoE パケットを送受信できるようにし、Dialer インターフェース という仮想インターフェースで認証や IP アドレスを管理します。

設定コマンド例

hostname Router
!
! --- 1. 物理インターフェースの設定 ---
! WAN 側のケーブルを挿すポート。PPPoE を有効化し、Dialer 1（pool 1）と紐づけ
interface GigabitEthernet0/1
 description WAN-Interface
 no ip address
 pppoe enable
 pppoe-client dial-pool-number 1
 no shutdown
!
! --- 2. LAN 側インターフェースの設定 ---
interface Vlan1
 description LAN-Interface
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!
! --- 3. Dialer インターフェースの設定（PPPoE の主体） ---
interface Dialer1
 description PPPoE-Session
 !
 ! ▼ MTU をフレッツ網の推奨値に合わせる
 mtu 1454
 !
 ip address negotiated
 encapsulation ppp
 !
 ! ▼ MSS を調整（MTU - 40 byte）
 ip tcp adjust-mss 1414
 !
 dialer pool 1
 dialer group 1
 !
 ! ▼ 認証情報（プロバイダから通知された ID / Pass）
 ppp authentication chap callin
 ppp chap hostname user-a-site1@example.com
 ppp chap password cisco
 !
 ! ▼ IPCP で DNS とデフォルトルートを取得
 ppp ipcp dns request
 ppp ipcp route default
 ip nat outside
!
! --- 4. NAT/NAPT の設定 ---
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
!
end

設定上のポイント: MTU / MSS の調整

フレッツ光などの回線では、PPPoE のヘッダが付与される分、通常の Ethernet（1500 byte）よりも一度に運べるデータサイズが小さくなります。ここを適切に設定しないと、Web サイトの一部が表示されない、通信が極端に遅くなる、といったトラブル（Path MTU Discovery ブラックホール問題）が発生する可能性があります。

mtu 1454

Cisco のデフォルト MTU は 1500 ですが、フレッツ網（NTT 東西）の推奨値は 1454 です。インターフェースの MTU を明示的に変更することで、LCP ネゴシエーション時の MRU にも反映されます。

ip tcp adjust-mss 1414

MTU 1454 に対して IP ヘッダ 20 byte と TCP ヘッダ 20 byte を差し引いた値です。クライアント PC が認識する MSS をルーター側で書き換え、フラグメント発生を抑える設定です。

なお、ip mtu コマンドのみを設定する例も見られますが、LCP ネゴシエーション（MRU）に反映するためには インターフェースの mtu コマンドを使う のが推奨です。詳細は後続セクション「MTU / MSS の落とし穴: フレッツ網での設計」で整理します。

参考: Cisco / Application Services Configuration Guide, IOS XE 17.x – PPP over Ethernet Client
“For PPPoE virtual template interfaces, the mtu command must be configured because Ethernet has a maximum payload size of 1500 bytes, the PPPoE header is 6 bytes, and PPP Protocol ID is 2 bytes.”
（PPPoE インターフェースでは mtu の設定が必要です。Ethernet の最大ペイロードサイズ 1500 バイトから PPPoE ヘッダ 6 バイトと PPP Protocol ID 2 バイトを差し引くためです）
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/application-services/b-application-services/m_bba-pppoe-client-xe.html

FortiGate（FortiOS）の設定例

FortiGate では、物理ポート（例: wan1）のモードを static や dhcp から pppoe に変更して設定します。GUI でも CLI でも設定できますが、CLI のほうが設定項目を一覧で確認しやすく、Config バックアップを読む際にも役立ちます。

設定コマンド例（基本構成）

config system interface
    edit "wan1"
        # ▼ PPPoE モードへの変更と認証情報
        set mode pppoe
        set username "user-a-site1@example.com"
        set password "fortinet"

        # ▼ MTU を 1454 に変更
        set mtu-override enable
        set mtu 1454

        # ▼ デフォルトルートと DNS の自動取得
        set defaultgw enable
        set dns-server-override enable
    next
end

config system pppoe-interface（IPv4 / IPv6 両対応構文）

物理ポート自体を PPPoE モードにする上記の構文に加えて、FortiOS には config system pppoe-interface という専用構文 があります。物理ポートとは別に PPPoE インターフェースを論理的に定義でき、特に IPv4 / IPv6 を同時に PPPoE で利用したいケース で扱いやすくなります。FortiOS 6.2 以降で利用可能です。

config system pppoe-interface
    edit "PPPoE-WAN"
        set device "port3"
        set username "user-a-site1@example.com"
        set password "fortinet"
        set ipv6 enable
    next
end

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

GUI からの設定（FortiOS 7.4.7 以降）

FortiOS 7.4.7 以降では、PPPoE オプションが GUI でデフォルト表示 されるようになりました。それ以前のバージョンでは、CLI で一度 set mode pppoe を入れることで GUI 側でも PPPoE 関連項目が表示される動作になっていました。

参考: Fortinet Community / Technical Tip: PPPoE interface option not available from GUI
“Starting FortiOS v7.4.7 and above PPPoE option is available on GUI by default.”
（FortiOS 7.4.7 以降では PPPoE オプションが GUI でデフォルト表示されます）
https://community.fortinet.com/t5/FortiGate/Technical-Tip-PPPoE-interface-option-not-available-from-GUI/ta-p/189804

設定のポイント: ポリシーと MSS 調整

FortiGate でインターネットに接続するには、インターフェース設定に加えて ファイアウォールポリシー の作成が前提になります。MSS の調整はファイアウォールポリシー内で設定するのが一般的です。

config firewall policy
    edit 1
        set name "LAN-to-Internet"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"

        # ▼ NAT を有効化
        set nat enable

        # ▼ MSS クランプ設定（インターフェース MTU に応じて自動調整されるが、明示指定も可能）
        set tcp-mss-sender 1414
        set tcp-mss-receiver 1414
    next
end

FortiGate はファイアウォール製品のため、許可ポリシー（LAN → WAN）が定義されていない通信は遮断されます。 PPPoE が UP しているのに通信できない場合、まずポリシーの定義状況を確認することをおすすめします。

YAMAHA RTX ルーターの設定例

YAMAHA は日本の SOHO・中小企業市場で広く採用されているメーカーです。interface ではなく pp（Point-to-Point） という論理インターフェースを使って設定するのが特徴です。現行の対応機種は RTX1300 / RTX1220 / RTX1210 / RTX840 / RTX830 / NVR700W / NVR510 などです。

設定コマンド例

ここでは、lan2 ポートを WAN 側（ONU 接続）、lan1 ポートを LAN 側とする一般的な構成を示します。

# --- 1. LAN 側インターフェースの設定 ---
ip lan1 address 192.168.1.1/24

# --- 2. PPPoE セッションの設定（pp 1） ---
# YAMAHA では "pp select" で設定対象を選択してから記述
pp select 1
 pp always-on on
 pppoe use lan2

 # ▼ 認証情報の設定
 pp auth accept chap pap
 pp auth myname user-a-site1@example.com password

 # ▼ MTU / MRU の調整（フレッツ推奨値）
 ppp lcp mru on 1454
 ip pp mtu 1454

 # ▼ MSS の調整（MTU から自動計算）
 ip pp tcp mss limit auto

 # ▼ NAT ディスクリプタの紐づけ（後述）
 ip pp nat descriptor 1000

 pp enable 1

# --- 3. NAT ディスクリプタ（NAPT）の定義 ---
nat descriptor type 1000 masquerade
nat descriptor address outer 1000 ipcp

# --- 4. ルーティングと DNS ---
ip route default gateway pp 1
dns server pp 1

設定のポイント: NAT ディスクリプタ

YAMAHA の設定で最初に戸惑いやすいのが NAT ディスクリプタ です。Cisco などではインターフェース内に直接 NAT 設定を書きますが、YAMAHA では NAT の定義（ディスクリプタ）を別に作成し、それをインターフェースに適用（バインド）する という手順を踏みます。

nat descriptor type 1000 masquerade

「ID 1000 番の NAT 定義は IP マスカレード（NAPT）として動作する」という定義

ip pp nat descriptor 1000

（pp select 内）: 「この PP インターフェースでは ID 1000 番の NAT 定義を利用する」という適用

ID が一致していないと、PPPoE セッションは確立しても NAT が動作せず、外部サイトにアクセスできない状態になります。設定時に ID の一致を確認する習慣をつけておくと、トラブルシューティングの起点がわかりやすくなります。

参考: YAMAHA / フレッツ 光ネクスト インターネット（IPv6 PPPoE）接続
「IPv6 PPPoE 機能の対応機種は、RTX5000、RTX3510、RTX3500、RTX1300、RTX1220、RTX1210、RTX1200（Rev.10.01.32 以降）、RTX840、RTX830、RTX810、NVR700W、NVR510、NVR500（Rev.11.00.16 以降）、FWX120、vRX（VMware ESXi 版）です。」
https://network.yamaha.com/setting/router_firewall/flets/flets_other_service/ipv6_pppoe

NEC UNIVERGE IX ルーターの設定例

NEC IX シリーズは通信事業者や企業の拠点ルーターとして広く利用されています。コマンド体系は Cisco IOS に近いものの、「どの物理ポートを使うか」の指定方法 など、細部に独自の設計があります。

設定コマンド例

IX シリーズでは、物理インターフェースで pppoe enable を有効化しつつ、Dialer インターフェース側から dialer bind-interface で物理ポートを指定する 構成が一般的です。

! --- 1. 物理インターフェースの設定 ---
interface GigaEthernet0.0
  no ip address
  pppoe enable
  no shutdown
!
! --- 2. Dialer インターフェースの設定 ---
interface Dialer0
  ! ▼ どの物理ポートで PPPoE するかを指定（Cisco とは紐づけ方向が逆）
  dialer bind-interface GigaEthernet0.0

  ! ▼ IP アドレスと認証
  ip address negotiated
  encapsulation ppp
  ppp authentication chap pap
  ppp chap hostname user-a-site1@example.com
  ppp chap password nec-router

  ! ▼ MTU / MSS の調整
  mtu 1454
  ip tcp adjust-mss 1414

  ! ▼ NAPT（IP マスカレード）の有効化
  ip napt enable

  no shutdown
!
! --- 3. デフォルトルート ---
ip route default Dialer0
!
! --- 4. NAPT エントリ数の拡張（必要に応じて） ---
! 大規模拠点では NAPT の同時セッション数を環境に合わせて拡張
! 例: ip napt translation max-entries 65535

設定のポイント: Cisco との違い

dialer bind-interface の方向

Cisco（IOS）では物理ポート側に pppoe-client dial-pool-number を書いて Dialer と紐づけますが、NEC IX では Dialer 側に dialer bind-interface を書いて物理ポートを指定 します。紐づけの方向が逆になる点が混同しやすいポイントです。

ip napt enable

Cisco のように ACL を定義して ip nat inside source list ... を記述しなくても、インターフェース配下に ip napt enable を記述するだけで NAPT が有効化されます。

NGN 網向けの高速化（Fast Forwarding）

IX シリーズには、パケット転送をハードウェア / ソフトウェアで最適化する Fast Forwarding 機能があり、デフォルトで有効です。大規模拠点では NAPT の同時セッション数上限（ip napt translation max-entries）をチューニングすることで安定性を高められます。

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

主要 4 メーカーの PPPoE 設定要素を、設計上の論点ごとに整理すると次のとおりです。メーカー間のコマンド体系は異なるものの、考慮する設計要素は共通しています。

比較から見える設計のポイント

論理インターフェースの考え方が異なる

Cisco / NEC は Dialer、FortiGate は物理 IF または pppoe-interface、YAMAHA は pp という独立した概念。設定対象の単位を最初に把握しておくことが、ミスの防止につながります。

物理ポートと論理 IF の紐づけ方向が逆になるケース

Cisco（物理 → Dialer）と NEC（Dialer → 物理）は紐づけ方向が逆です。複数メーカーを併用する現場では、構成図に方向を明示しておくことをおすすめします。

NAT 設定の「書き場所」が異なる

Cisco は ACL ＋ グローバル設定、FortiGate はポリシー、YAMAHA は NAT ディスクリプタ ＋ 適用、NEC は IF 内 1 行。NAT が機能しない場合のトラブルシューティング起点が、メーカーごとに異なります。

FortiGate のポリシー前提

他のルーターと最も異なる点で、ポリシー設定がないと PPPoE が UP しても通信が成立しません。

MTU / MSS の落とし穴: フレッツ網での設計

PPPoE 設定で必ず登場する 1454 や 1414 という値には、明確な根拠があります。

なぜ MTU は 1454 byte なのか（フレッツ網の仕様）

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

合計 46 byte 分のオーバーヘッドが発生するため、フレッツ接続時の推奨 MTU は 1454 byte となります。これを考慮せず 1500 byte のまま送出すると、網の入口で強制的にフラグメントされたり破棄されたりして、通信効率が低下します。

MTU と MRU の違い（Cisco の落とし穴）

Cisco ルーターでは、似たコマンドが複数存在するため注意が必要です。

• MTU（Maximum Transmission Unit）: 自分が送信できる最大サイズ
• MRU（Maximum Receive Unit）: 自分が受信できる最大サイズ（PPP の接続開始時に相手に通知する値）

Cisco の仕様では、インターフェースの mtu コマンドの値が、PPP ネゴシエーション（LCP）で相手に通知する MRU の値として使われます。

推奨される設定: mtu 1454

インターフェース自体のサイズを 1454 に設定することで、LCP ネゴシエーション時に「私は 1454 byte まで受信できます（MRU=1454）」と相手に通知します。送受信ともに 1454 byte で整合性が取れる設定です。

注意したい設定: ip mtu 1454 のみ

ip mtu のみを設定した場合、IP パケットのサイズ制限は 1454 になりますが、インターフェースの物理 MTU（デフォルト 1500）は変わりません。LCP ネゴシエーション時に MRU=1500 が通知されてしまうため、対向側は 1500 byte のパケットを送ってくる可能性があり、フレッツ網内での破棄や再送が発生する設計 になります。

Cisco でフレッツ網に接続する際は、interface Dialer 内で mtu 1454 を設定することをおすすめします。

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

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 など）

Cisco

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

FortiGate

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

YAMAHA

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

NEC IX

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

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

PADT と切断時の挙動

PPPoE セッションの切断は PADT（PPPoE Active Discovery Terminate）パケット で通知されます。回線切断時にクライアント側のセッションが残ってしまうと、再接続時に「サーバー側でセッション数の上限に達している」と判定されることがあります。

keepalive の設定

LCP echo を有効化することで対向の死活を検知しやすくなります

再接続タイマー

FortiGate の disc-retry-timeout、YAMAHA の pppoe auto connect on など、再接続動作の設定を環境に合わせて調整することをおすすめします

1 セッション = 1 IP の前提

PPPoE で払い出される IP アドレスは、原則として 1 セッションに 1 IP（端末型払い出し） です。フレッツ光ネクストの一般的な契約では端末型が前提となるため、ルーター側で NAT / NAPT を併用する設計が標準的です。

MSS Clamping のかかる場所

MSS の調整は、送信側・受信側のどちらでも有効化可能 ですが、フラグメント発生を抑制するうえでは「PPPoE インターフェース上で双方向に効かせる」設計が安全です。FortiGate のポリシーでは tcp-mss-sender と tcp-mss-receiver の両方を設定する書き方が広く採用されています。

補足: IPv6 PPPoE という選択肢

本記事では IPv4 PPPoE を中心に整理してきましたが、IPv6 PPPoE という選択肢も現場で利用されています。フレッツ網では IPv6 IPoE（IPv4 over IPv6）が主流になりつつある一方、特定の用途では IPv6 PPPoE が引き続き活用されています。

IPv6 PPPoE が選ばれるケース

固定 IPv6 アドレスが必要な構成

IPoE は ISP 側が割り当てるため固定運用が難しいが、PPPoE は契約形態によって固定 IPv6 アドレスの提供が可能

既存の IPv4 PPPoE と並行運用したい構成

1 台のルーターで IPv4 PPPoE と IPv6 PPPoE を別の pp セッションとして組む設計

特定の閉域網接続

プロバイダが PPPoE 認証を前提として IPv6 を提供する構成

YAMAHA RTX での設定イメージ

YAMAHA は IPv6 PPPoE 対応が比較的早く、RTX1300 / RTX1220 / RTX1210 / RTX840 / RTX830 / NVR700W / NVR510 などの現行機種で利用できます。

pp select 2
 pppoe use lan2
 pp auth accept pap chap
 pp auth myname (ISP 接続 ID) (パスワード)
 ppp ipv6cp use on
 ipv6 pp dhcp service client
 pp enable 2

ipv6 route default gateway pp 2
ipv6 prefix 5 dhcp-prefix@pp2::/64
ipv6 lan1 address dhcp-prefix@pp2::1/64
ipv6 lan1 rtadv send 5 o_flag=on
ipv6 lan1 dhcp service server

IPv4 PPPoE と IPv6 PPPoE を 1 台のルーターで併用する場合、DNS の問い合わせ優先順位によって名前解決に失敗することがあります。YAMAHA の公式ドキュメントでも dns server 設定の調整が必要なケース が紹介されており、両方式を併用する設計では事前に検証することをおすすめします。

接続確認コマンド集

設定後の動作確認に役立つ、各メーカーの主な確認コマンドをまとめます。

Cisco（IOS / IOS XE）

! ▼ PPPoE セッションの状態確認（State が UP なら正常）
Router# show pppoe session

! ▼ IP アドレスの取得確認（Dialer に IP が付与されているか）
Router# show interface dialer 1

! または
Router# show ip interface brief

FortiGate（FortiOS）

# ▼ インターフェースのステータスと IP 確認
FortiGate # get system interface

# ▼ ルーティング確認（デフォルトルート 0.0.0.0/0 があるか）
FortiGate # get router info routing-table all

# ▼ 疎通確認（Ping）
FortiGate # execute ping 8.8.8.8

YAMAHA（RTX）

# ▼ PP インターフェースの状態詳細
# 接続時間、取得 IP、DNS などが一覧で表示される主要な確認コマンド
RTX# show status pp 1

# ▼ ルーティング確認
RTX# show ip route

NEC（UNIVERGE IX）

! ▼ PPPoE セッションの状態確認（State が up なら正常）
Router# show pppoe session

! ▼ IP アドレスとインターフェース詳細
Router# show interface Dialer0

! または
Router# show ip interface

トラブルシューティングの基本コマンド

PPPoE が想定どおりに動作しない場合、以下のデバッグ系コマンドで原因を切り分けます。症状（接続できない / 認証で失敗 / IP が取れない / 通信が遅い）に応じて使い分け ます。

Cisco: PPP / PPPoE デバッグ

! ▼ PPPoE のディスカバリ段階を追跡（PADI / PADO / PADR / PADS）
Router# debug pppoe events
Router# debug pppoe errors

! ▼ PPP の LCP / IPCP ネゴシエーションを追跡
Router# debug ppp negotiation

! ▼ 認証フェーズの追跡
Router# debug ppp authentication

! ▼ デバッグ停止
Router# undebug all

切り分けの目安: PADI 送出後に PADO が返らない → 物理層 / 対向到達性 / VLAN 設定 / LCP は完了するが認証で failure → ID / パスワードまたは認証方式（CHAP / PAP）/ IPCP で IP が取れない → ppp ipcp の指定漏れ

FortiGate: PPPoE デバッグ

# ▼ PPPoE デーモンのデバッグ
FortiGate # diagnose debug application pppoed -1
FortiGate # diagnose debug enable

# ▼ インターフェースの状態詳細
FortiGate # diagnose netlink interface list

# ▼ デバッグ停止
FortiGate # diagnose debug disable
FortiGate # diagnose debug reset

切り分けの目安: pppoed ログでエラーなし ＋ PPPoE が UP しているのに通信不可 → ファイアウォールポリシーまたはルーティングの確認 / pppoed ログで認証失敗 → auth-type の確認

YAMAHA: PP セッションのデバッグ

# ▼ PP の詳細状態（接続時間、取得 IP、エラー数）
RTX# show status pp 1

# ▼ PPPoE のデバッグログを有効化
RTX# pp select 1
RTX# pppoe debug on

# ▼ syslog で PPP 関連のメッセージを確認
RTX# show log | grep -i ppp

切り分けの目安: 「相手の応答がありません」 → 物理層 / 対向到達性 / 「認証エラー」表示 → ID / パスワードや認証方式 / NAT 不動作 → show nat descriptor address で ID マッピングを確認

NEC IX: PPP / Dialer のデバッグ

! ▼ PPP のデバッグ
Router# debug ppp negotiation
Router# debug ppp authentication

! ▼ Dialer インターフェースの状態
Router# show interface Dialer0

! ▼ デバッグ停止
Router# no debug all

切り分けの目安: Dialer インターフェースが down のまま → dialer bind-interface の指定先と物理インターフェースの状態確認 / LCP 完了後に切断 → MTU / MRU の不整合

共通の切り分け観点

メーカーを問わず、PPPoE が確立しない場合は以下の順で切り分けると効率的です。

まとめ

本記事では、インターネット接続の代表的な技術である PPPoE について、仕組みから主要 4 メーカーの設定例までを整理しました。

• PPPoE は Ethernet と PPP を組み合わせたプロトコルで、接続には「ディスカバリ」と「セッション」の 2 段階がある
• 主要 4 メーカー（Cisco / FortiGate / YAMAHA / NEC）でコマンド構文は異なるが、設計要素（インターフェース紐づけ・認証・MTU / MSS・NAT）は共通している
• フレッツ網接続では MTU 1454・MSS 1414 を基準に設計し、Cisco では ip mtu ではなくインターフェースの mtu コマンドで設定することをおすすめする
• FortiGate は許可ポリシーが前提のため、セッション確立後に通信できない場合はポリシーをまず確認する
• YAMAHA は NAT ディスクリプタの ID マッピングが正しいことを確認する設計が重要
• NEC IX は dialer bind-interface の紐づけ方向が Cisco と逆になる点を押さえておく
• IPv6 PPPoE は固定 IPv6 や特定の閉域網など、IPoE 方式では対応が難しい要件で選択肢になる

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