Cisco ルーターの PPPoE 設定手順｜Dialer 構成と ip mtu の違い

はじめに

Cisco ルーターでフレッツ光などの PPPoE 回線に接続する場合、設定の中心になるのが Dialer インターフェースという仮想インターフェースです。物理ポートと Dialer の役割分担や、ip mtu と mtu の使い分けなど、Cisco 特有の考え方を押さえておくと、設定でつまずきにくくなります。本記事は、Cisco ルーターを PPPoE クライアントとして設定する手順を、コマンドの意味とあわせて整理します。

PPPoE そのものの仕組み（ディスカバリ / セッションの 2 段階）や、フレッツ網で MTU 1454 / MSS 1414 となる根拠については、親記事『PPPoE 接続の仕組みと設定の基本｜主要 4 メーカーの設計比較』で解説しています。また、Cisco ルーターを対向の PPPoE サーバー側として構築する手順は、関連記事『Cisco ルーターで PPPoE サーバーを構築する手順｜VRF 連携のポイント』で扱っています。本記事はクライアント側の設定に絞って掘り下げます。検証は IOS / IOS XE 17.x 系を前提にしています。

Cisco の PPPoE クライアント設定で押さえるべき要点は 2 つです。第一に、物理インターフェースで PPPoE を有効化し、認証・IP アドレス・MTU といった論理的な設定は Dialer インターフェースに集約するという役割分担です。第二に、MTU は ip mtu ではなくインターフェースの mtu で設定するのが基本という点で、これは PPP の MRU ネゴシエーションに関わる Cisco 特有の落とし穴です（詳細は MTU / MSS のセクションで扱います）

Cisco の PPPoE 設定の全体像（Dialer インターフェースとは）

具体的なコマンドに入る前に、Cisco の PPPoE 設定がどのような構造になっているのかを整理します。この役割分担を理解しておくと、各コマンドをどのインターフェースに書くのかが明確になります。

物理 IF と Dialer の役割分担

Cisco の PPPoE クライアント設定では、物理インターフェースと Dialer インターフェース（仮想インターフェース）の 2 つを組み合わせて使います。それぞれの役割は次のとおりです。

物理インターフェース（例: GigabitEthernet0/1）

WAN 側のケーブルを接続するポート。ここでは PPPoE を有効化し、Dialer プールへの割り当てを行うだけで、IP アドレスは設定しない（no ip address）

Dialer インターフェース（例: Dialer1）

PPPoE セッションの主体となる仮想インターフェース。認証情報、IP アドレスの取得、MTU、NAT の外側指定など、論理的な設定をここに集約する

物理ポートは「PPPoE のパケットが出入りする口」、Dialer は「PPPoE セッションそのものを管理する論理的な実体」と整理すると理解しやすくなります。実際に PPPoE セッションが確立すると、ルーターは内部的に Virtual-Access インターフェースを動的に生成し、Dialer の設定を引き継いで通信します。

参考: Cisco / Application Services Configuration Guide, IOS XE 17.x – PPP over Ethernet Client
“Create the logical dialer interface and configure the pool used to pick physical interfaces”
（物理インターフェースを選択するためのプールを構成し、論理 Dialer インターフェースを作成します）
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

紐づけの方向（物理 → Dialer）

物理インターフェースと Dialer インターフェースは、dial-pool（ダイヤルプール）番号を介して紐づきます。このとき、紐づけの記述方向が Cisco の特徴です。

• 物理インターフェース側に pppoe-client dial-pool-number 1 を記述し、「この物理ポートは pool 1 に所属する」と宣言する
• Dialer インターフェース側に dialer pool 1 を記述し、「この Dialer は pool 1 の物理ポートを使う」と宣言する

両者を同じプール番号（上記例では 1）で一致させることで、物理ポートと Dialer が結びつきます。物理側からプールに参加し、Dialer 側がそのプールを参照するという流れです。

この紐づけの方向は、メーカーによって異なります。たとえば NEC UNIVERGE IX では、Dialer 側に dialer bind-interface を書いて物理ポートを直接指定する形になり、Cisco とは逆向きになります。複数メーカーを併用する現場では、構成図に紐づけの方向を明示しておくと混乱を避けられます（メーカー間の比較は親記事の早見表を参照してください）

なお、Cisco ルーターは 1 台で PPPoE クライアントとサーバーの両機能を持つことができ、共通の Dialer インターフェースを介して IPsec と組み合わせた構成（DMVPN など）も公式にサポートされています。本記事ではクライアントの基本構成を扱い、IPsec 併用時の MTU / MSS 設計は後半のセクションで補足します。

CLI での基本設定手順

ここでは、GigabitEthernet0/1 を WAN 側（ONU 接続）、Vlan1 を LAN 側とする一般的な構成を例に、CLI での設定手順を整理します。設定は「物理インターフェース → Dialer インターフェース → NAT・ルーティング」の順で進めます。

物理インターフェースの設定（pppoe enable / dial-pool-number）

WAN 側の物理インターフェースでは、IP アドレスを割り当てず、PPPoE を有効化して Dialer プールへ割り当てます。

interface GigabitEthernet0/1
 description WAN-Interface
 no ip address
 pppoe enable group global
 pppoe-client dial-pool-number 1
 ip nat outside
 no shutdown

• no ip address: 物理ポートには IP を付与しない（IP は Dialer 側で管理する）
• pppoe enable group global: このインターフェースで PPPoE セッションを有効化する。
• pppoe-client dial-pool-number 1: この物理ポートを dial-pool 1 に割り当てる。
• ip nat outside: NAT の外側インターフェースとして指定する。

Dialer インターフェースの設定（認証・IP 取得）

PPPoE セッションの主体となる Dialer インターフェースに、認証情報・IP アドレスの取得方法・MTU を設定します。

interface Dialer1
 description PPPoE-Session
 mtu 1454
 ip address negotiated
 encapsulation ppp
 ip tcp adjust-mss 1414
 dialer pool 1
 dialer-group 1
 ppp authentication chap pap callin
 ppp chap hostname user-a-site1@example.com
 ppp chap password 0 cisco-secret
 ppp pap sent-username user-a-site1@example.com password 0 cisco-secret
 ip nat outside

• mtu 1454: インターフェースの MTU をフレッツ網の値に設定する（純粋な PPPoE 環境では 1492。ip mtu との違いは後述）
• ip address negotiated: IPCP のネゴシエーションで対向から払い出された IP を使用する。
• encapsulation ppp: カプセル化方式を PPP に設定する。
• ip tcp adjust-mss 1414: TCP の MSS をルーター側で書き換える。
• dialer pool 1: dial-pool 1 に所属する物理ポートを使用する（物理側の dial-pool-number 1 と一致させる）
• ppp authentication chap pap callin: 認証方式として CHAP / PAP を受け付ける。
• ppp chap hostname / ppp chap password: プロバイダーから通知された接続 ID とパスワード

CHAP と PAP の両方を記載しておくと、対向の要件に応じて自動的にネゴシエーションされます。プロバイダーが PAP のみの場合に備え、ppp pap sent-username も併記する書き方が広く採用されています。

参考: Cisco / Cisco 819 ISR Software Configuration Guide – Configuring PPP over Ethernet with NAT
“interface dialer 0 ip address negotiated ip mtu 1492 encapsulation ppp”
（Dialer インターフェースに ip address negotiated・MTU・PPP カプセル化を設定する）
https://www.cisco.com/c/en/us/td/docs/routers/access/800/819/software/configuration/Guide/819_SCG/9ppp_e_nat.html

NAT（NAPT）とデフォルトルート

LAN 側インターフェースを NAT の内側に指定し、NAPT（オーバーロード）とデフォルトルートを設定します。

interface Vlan1
 description LAN-Interface
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!
access-list 1 permit 192.168.1.0 0.0.0.255
ip nat inside source list 1 interface Dialer1 overload
!
dialer-list 1 protocol ip permit
ip route 0.0.0.0 0.0.0.0 Dialer1

• ip nat inside: LAN 側インターフェースを NAT の内側として指定する。
• access-list 1: NAT 対象とする内部ネットワークを定義する。
• ip nat inside source list 1 interface Dialer1 overload: ACL 1 に該当する通信を Dialer1 のアドレスへ NAPT 変換する。
• dialer-list 1 protocol ip permit: dialer-group 1 に対応する対象トラフィックを定義する。
• ip route 0.0.0.0 0.0.0.0 Dialer1: デフォルトルートを Dialer1 へ向ける。

Cisco の NAT は、ACL で NAT 対象を定義し、グローバル設定の ip nat inside source list で Dialer インターフェースに紐づける、という組み立てです。NAT の「書き場所」はメーカーごとに異なります（比較は親記事のこちらを参照）

主要コマンドの意味

設定で登場するコマンドのうち、意味を取り違えやすいものを補足します。

ip address negotiated

ip address negotiated は、IPCP（IP Control Protocol）のネゴシエーションで対向から払い出された IP アドレスを、そのインターフェースに割り当てるコマンドです。固定の IP アドレスを直接設定する代わりに、PPPoE 接続時にプロバイダーから動的に割り当てられたアドレスを使う、という指定になります。

interface Dialer1
 ip address negotiated

フレッツ光ネクストの一般的な端末型契約では、接続のたびにアドレスが払い出されるため、この ip address negotiated を使うのが基本です。プロバイダーから固定 IP が割り当てられる契約の場合は、ip address で直接アドレスを設定することもできます。

ppp chap hostname / password と chap callin

PPPoE の認証情報は、Dialer インターフェース配下の ppp chap hostname（接続 ID）と ppp chap password（パスワード）で設定します。ppp authentication chap pap callin の callin は、着信側（callin）の方向でのみ認証を要求するという指定です。

PPPoE クライアントの場合、認証するのは対向（サーバー / BAS）側であり、クライアント側が相手を認証する必要はありません。callin を付けることで、クライアントは「自分が相手から認証される」側の動作になり、不要な相互認証によるネゴシエーションの行き違いを避けられます。

dialer pool / dialer-group

似た名前のコマンドですが、役割が異なります。

• dialer pool: Dialer インターフェースが使用する物理ポートのグループ（プール）を指定する。物理側の pppoe-client dial-pool-number と番号を一致させることで紐づく
• dialer-group: この Dialer で「どのトラフィックがダイヤル（接続）の対象になるか」を、dialer-list と組み合わせて定義する

dialer pool は物理ポートとの紐づけ、dialer-group は接続トリガーとなるトラフィックの定義、と整理すると混同しにくくなります。常時接続の PPPoE では、dialer-list 1 protocol ip permit のように IP 全般を対象とする書き方が一般的です。

MTU / MSS 設計（ip mtu の落とし穴）

PPPoE 設定で頻出する MTU まわりのコマンドには、mtu と ip mtu の 2 つがあり、どちらを使うかで PPP のネゴシエーション結果が変わります。ここは Cisco 固有のつまずきどころです。

mtu と ip mtu の違い（MRU への反映）

2 つのコマンドの違いを整理します。

• mtu 1454: インターフェース自体の MTU（物理的に扱える最大フレームサイズ）を設定する。この値が、PPP の LCP ネゴシエーション時に対向へ通知する MRU（受信可能な最大サイズ）に反映される
• ip mtu 1454: IP パケットのサイズ上限のみを設定する。インターフェースの MTU（既定 1500）は変わらないため、LCP では MRU=1500 のまま通知される

問題になるのは後者です。ip mtu だけを設定すると、自分が送信する IP パケットは 1454 に抑えられますが、LCP で「私は 1500 byte まで受信できる（MRU=1500）」と対向に伝えてしまうため、対向が 1500 byte のパケットを送ってくる余地が残ります。結果として、フレッツ網内での破棄や再送が発生する設計になります。実機の LCP ログでも、インターフェース MTU が 1500 のままだと MRU 1500 が通知される挙動が確認できます。

送受信の両方向で整合を取るには、インターフェースの mtu コマンドで MTU 自体を設定するのが基本です。フレッツ網であれば mtu 1454、純粋な PPPoE 環境であれば mtu 1492 を Dialer インターフェースに設定します。

参考: Cisco / Ethernet MTU and TCP MSS Adjustment Concept for PPPoE Connections
“PPPoE needs additional 8 bytes and truncates the Ethernet MTU to 1492”
（PPPoE は追加で 8 byte を必要とし、Ethernet MTU を 1492 に切り詰めます）
https://www.cisco.com/c/en/us/support/docs/ip/transmission-control-protocol-tcp/200932-Ethernet-MTU-and-TCP-MSS-Adjustment-Conc.html

あわせて ip tcp adjust-mss で MSS を調整します。フレッツ網では ip tcp adjust-mss 1414（MTU 1454 − IP / TCP ヘッダ計 40 byte）、純粋な PPPoE 環境では ip tcp adjust-mss 1452（MTU 1492 − 40 byte）が基準値です。MSS 調整は Dialer インターフェースまたは LAN 側インターフェースのいずれにも設定でき、確実に経路上で書き換わるよう配置します（MTU / MSS の値の根拠はこちらを参照）

IPsec / VPN を併用する場合の MSS

PPPoE 回線の上で IPsec VPN（サイト間 VPN や DMVPN）を構成する場合、PPPoE のオーバーヘッドに加えて IPsec の暗号化ヘッダが上乗せされるため、MSS をさらに小さく設計する必要があります。これを考慮しないと、小さいパケットは通るのに大きいパケットだけ通らない、という切り分けの難しい症状につながります。

IPsec のオーバーヘッドは暗号化方式やトンネル方式によって変動するため一概には決まりませんが、実務では、トンネルインターフェースや Dialer インターフェースに対して MSS を 1300〜1400 程度まで下げる設計が広く採用されています。Cisco のサポートコミュニティでも、PPPoE + IPsec の構成で MSS を小さめに設定して大きなパケットを通す事例が共有されています。

interface Dialer1
 mtu 1454
 ip tcp adjust-mss 1414
!
interface Tunnel0
 ! IPsec トンネル側ではさらに小さい MSS を設定
 ip tcp adjust-mss 1360

具体的な値は、暗号化方式（ESP / AH）、トンネルモード、追加ヘッダの有無によって変わります。本番適用前に、実機で大きいサイズの Ping（DF ビット付き）を流して、フラグメントなしで通る最大サイズを確認したうえで MSS を決めることをおすすめします。

応用構成

VLAN タグ付き PPPoE（サブインターフェース）

ISP やキャリアによっては、PPPoE に VLAN タグを付与する仕様があります。Cisco では、物理インターフェースにサブインターフェースを作成し、encapsulation dot1Q で VLAN タグを設定したうえで、そのサブインターフェース配下で PPPoE を有効化します。

interface GigabitEthernet0/1.101
 encapsulation dot1Q 101
 pppoe enable group global
 pppoe-client dial-pool-number 1

encapsulation dot1Q 101 の VLAN ID（上記例では 101）には、ISP が指定する値を設定します。Dialer 側の設定は、タグなしの場合と同じです。ISP が指定する VLAN ID は事前に確認しておく必要があります。

WAN 側 MAC アドレスの変更

PPPoE セッションのローカル MAC アドレスは、既定で PPPoE を送出する物理インターフェースの MAC アドレスが使われます。回線業者やプロバイダー側で特定の MAC アドレスが登録されている環境（機器の交換時など）では、ルーターの物理インターフェースの MAC アドレスを変更して、従来の機器と同じ MAC で接続したいケースがあります。

物理インターフェース配下で mac-address コマンドを使うと、そのインターフェースの MAC アドレスを任意の値に変更できます。

interface GigabitEthernet0/1
 mac-address 0011.2233.4455
 pppoe enable group global
 pppoe-client dial-pool-number 1

設定後、show vpdn session all または show pppoe session の出力に表示されるローカル MAC アドレスが、指定した値に変わっていることを確認します。なお、プラットフォームやインターフェースの種類によっては mac-address コマンドに対応していない場合があるため、対象機種の対応状況を確認したうえで適用することをおすすめします。

確認とトラブルシューティング

設定後の動作確認と、想定どおりに動作しない場合の切り分け手順を整理します。PPPoE は「セッションが確立しているか」「IP が払い出されているか」「通信が成立するか」を段階的に確認すると、原因を絞り込みやすくなります。

確認コマンド

PPPoE セッションと IP 取得の状態は、主に次のコマンドで確認します。

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

! Dialer に IP が払い出されているか
show ip interface brief

! Dialer インターフェースの詳細
show interface dialer 1

! ルーティング確認（デフォルトルートが Dialer を向いているか）
show ip route

show pppoe session の出力で State が UP になっていれば、PPPoE セッション自体は確立しています。あわせて show ip interface brief で Dialer インターフェースにグローバル IP が付与されていれば、IPCP による IP 取得まで完了しています。この状態で通信できない場合は、NAT・ルーティング・ACL を確認する、という切り分けになります。

debug による切り分け

セッションが確立しない、または認証で失敗する場合は、debug コマンドでネゴシエーションの過程を追跡します。実機への負荷がかかるため、稼働中の環境では影響範囲を確認したうえで実行することをおすすめします。

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

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

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

! デバッグ停止
undebug all

出力のどの段階で止まっているかによって、確認すべき箇所が変わります。

• PADI 送出後に PADO が返らない: 物理層・対向到達性・VLAN 設定を確認する（ディスカバリステージで停止）
• LCP は完了するが認証で failure: 接続 ID / パスワード、認証方式（CHAP / PAP）の整合を確認する。
• 認証は通るが IP が取れない: ip address negotiated の設定漏れ、IPCP のネゴシエーション状況を確認する。

PPPoE のステージごとの切り分けの考え方は、親記事の共通切り分けステップでも整理しています。あわせて参照すると、メーカーを問わない切り分けの全体像を把握できます。

よくあるトラブルと確認ポイント

Cisco の PPPoE クライアントで遭遇しやすいトラブルを整理します。

PPPoE は UP だが Web の一部が表示されない / 通信が遅い

MTU / MSS の設定を確認する。ip mtu のみの設定になっていないか、mtu でインターフェース MTU を設定しているかを点検する

IPsec VPN 経由の大きいパケットだけ通らない

トンネル側の MSS をさらに下げる（MTU / MSS 設計のセクションを参照）

セッションは確立するが LAN から通信できない

NAT の内側 / 外側インターフェースの指定（ip nat inside / ip nat outside）と、ACL・ip nat inside source list ... overload の対象範囲を確認する。

認証が通らない

プロバイダーが CHAP / PAP のどちらを要求するかを確認し、ppp chap / ppp pap sent-username の設定を見直す。

まとめ

本記事では、Cisco ルーターを PPPoE クライアントとして設定する手順を、Dialer インターフェースの考え方から MTU / MSS 設計、トラブルシューティングまで整理しました。物理 IF と Dialer の役割分担を押さえ、MTU は ip mtu ではなくインターフェースの mtu で設定することが、安定した接続の前提になります。

• PPPoE の論理設定は Dialer インターフェースに集約し物理 IF は PPPoE 有効化のみ。
• 物理と Dialer は dial-pool 番号で紐づき、方向は物理から Dialer へ参照する。
• ip address negotiated は IPCP で払い出された IP を使う指定
• MTU はインターフェースの mtu で設定し MRU を正しく通知することが重要
• フレッツ網は MTU 1454 / MSS 1414、純粋な PPPoE は MTU 1492 / MSS 1452 が基準
• IPsec 併用時はトンネル側の MSS をさらに下げて大きいパケットの破棄を防ぐ。
• 切り分けはセッション確立・IP 取得・通信成立の順に段階的に確認する。

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