Cisco ルーターで PPPoE サーバを構築する手順｜VRF 連携のポイント

はじめに

ネットワークの接続検証を行う際、Cisco ルーターを PPPoE サーバとして動作させる構成 は、クライアント側の動作確認やトラブルシューティングにおいて役立ちます。現代のネットワークでは IPoE 方式が普及していますが、PPPoE 方式を利用する環境や検証ニーズは依然として残っています。

本記事では、まず 基本構成（端末型払い出し） で PPPoE サーバを構築する手順を整理したうえで、応用構成として VRF を活用したマルチテナント環境 の組み方を解説します。AAA Attribute List を用いた動的な IP アドレス割り当てや、設計時の制約・トラブルシューティングまで、実機ベースで整理します。検証は Cisco IOS XE 17.x 系 を前提にしています。

クライアント側（PPPoE クライアント）の設定については、関連記事『PPPoE 接続設定の手順｜Cisco / FortiGate / YAMAHA / NEC の違い』で各機種の手順をまとめています。あわせて参照すると、サーバ側・クライアント側の動作を一通り確認できます。

PPPoE サーバー機能の概要と検証での活用シーン

Cisco ルーターは、PPPoE クライアントとしてだけでなく、PPPoE サーバー（ブロードバンドアクセスサーバー / BAS）として動作させること も可能です。本来、PPPoE サーバーは ISP（インターネットサービスプロバイダー）の網内に配置される設備ですが、Cisco ルーターでこの機能をエミュレートすることで、閉塞された検証環境でも ISP 接続を模した試験が行えます。

なぜ PPPoE サーバーの設定環境が役立つのか

近年は IPoE 方式への移行が進んでいますが、PPPoE 方式は法人向け回線や既存環境で広く稼働しています。ネットワークエンジニアにとって、PPPoE サーバーの設定環境は以下のシーンで役立ちます。

• クライアントルーターの接続設定の動作検証
• 認証サーバー（RADIUS）との連携試験
• MTU / MSS に起因する通信不具合の再現と対策確認
• マルチテナント環境における L3 分離のプロトタイプ作成

実機検証では、上位側に Cisco ルーターを 1 台用意して PPPoE サーバーとして設定することで、クライアント側の設定が正しいかどうかを即座に確認できます。手軽な検証環境の構築については、当ブログの関連記事『Packet Tracer のインストールから使い方まで』も参考にしてください。

参考: Cisco / Application Services Configuration Guide, IOS XE 17.x – PPP over Ethernet Client
“Before the introduction of this feature, Cisco IOS XE software supported PPPoE only on the access server side.”
（PPPoE クライアント機能が追加される以前は、Cisco IOS XE はアクセスサーバー側（PPPoE サーバー側）の PPPoE のみをサポートしていました）
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

基本構成: シンプルな PPPoE サーバーを組む

まずはマルチテナントを意識せず、シングル VRF（グローバルテーブル）でシンプルに PPPoE サーバーを構成する手順を整理します。VRF を併用する応用構成は、後続のセクションで解説します。

構成例（端末型払い出し）

以下の前提で設定します。

• ユーザー名: user1@example.com / パスワード: cisco
• 払い出し IP アドレスプール: 10.0.0.1 〜 10.0.0.10
• PPPoE 終端側インターフェース: Vlan10
• BBA グループ名: POE-BASIC

! AAA 認証の有効化
aaa new-model
aaa authentication ppp default local
!
! ユーザー認証情報
username user1@example.com password 0 cisco
!
! IP アドレスプール
ip local pool POOL-BASIC 10.0.0.1 10.0.0.10
!
! BBA グループと Virtual-Template の紐づけ
bba-group pppoe POE-BASIC
 virtual-template 1
!
! Loopback（unnumbered の借用元）
interface Loopback1
 ip address 10.0.0.254 255.255.255.0
!
! Virtual-Template
interface Virtual-Template1
 mtu 1492
 ip unnumbered Loopback1
 peer default ip address pool POOL-BASIC
 ppp authentication chap
!
! PPPoE 終端インターフェース
interface Vlan10
 no ip address
 pppoe enable group POE-BASIC

設定上のポイント

mtu 1492 の根拠

イーサネットの最大ペイロード 1500 バイトから、PPPoE ヘッダ 6 バイト ＋ PPP Protocol ID 2 バイト ＝ 計 8 バイト を引いた値です。純粋な PPPoE 環境では 1492 が標準値になります。フレッツ網など、内部で L2TP を利用する回線を模擬する場合は 1454 を使う設計もあります（後述）

ip unnumbered Loopback1

Virtual-Template 自体に IP アドレスを割り当てず、Loopback の IP アドレスを借用する構成です。クライアントが増えるたびに IP アドレスを消費しない設計につながります。

peer default ip address pool

プールから順番に IP アドレスを払い出す端末型方式です。ユーザーごとに固定 IP を払い出したい場合は、後述の AAA Attribute List 方式を併用します。

参考: Cisco / Broadband Access Aggregation and DSL Configuration Guide, IOS XE Release 3S – PPPoE on Ethernet
“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 の Virtual-Template インターフェースでは mtu の設定が必要です。イーサネットの最大ペイロード 1500 バイトから PPPoE ヘッダ 6 バイトと PPP Protocol ID 2 バイトを差し引くためです）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/xe-3s/asr1000/bba-xe-3s-asr1000-book/bba-ppoe-enet-xe.html

bba-group pppoe global と個別名の使い分け

bba-group pppoe の名前には予約語 global も指定できます。

bba-group pppoe global

ルーター全体で 1 つの共通 BBA グループとして動作。pppoe enable のみを指定するインターフェースで自動的に参照される

bba-group pppoe <任意の名前>

特定インターフェースから明示的に pppoe enable group <名前> で紐づけて利用。複数の BBA グループを使い分けたい場合（マルチテナント構成など）に必要

シンプル構成では global、複数のテナントや拠点を分離する構成では個別名と使い分けます。

端末型と LAN 型の払い出し方式の違い

PPPoE サーバがクライアントに IP アドレスを払い出す方式には、端末型 と LAN 型 の 2 種類があります。

端末型払い出し（標準）の特徴

peer default ip address pool POOL-BASIC のように、定義した IP プールから 1 セッションごとに 1 IP を払い出します。show ip route で確認すると、Virtual-Access インターフェースに対して /32 のホストルートが動的に学習されます。検証用途や ISP 接続のシミュレーションで一般的な方式で、本記事の基本構成例もこの方式です。

LAN 型払い出しを構成する場合の考え方

LAN 型は、PPPoE クライアント配下にサブネット（例: 192.0.2.0/29）をまるごと払い出し、サブネット内の複数アドレスをクライアント側で利用できるようにする方式です。Cisco ルーター単体で LAN 型を実装する場合は、サーバー側にサブネット宛のスタティックルートを Virtual-Access 経由で追加するなど、端末型より設定が複雑になります。

検証用途の多くでは端末型で十分要件を満たせる ため、まずは端末型で構築し、必要に応じて LAN 型を検討する流れがおすすめです。テナント数が増える場合は、RADIUS など外部の認証サーバーとの組み合わせが向きます。

応用構成: VRF を活用したマルチテナント PPPoE サーバー

ここからは、1 台の物理ルーターを論理的に分割する VRF（Virtual Routing and Forwarding） を活用したマルチテナント構成を解説します。複数の顧客やプロジェクトの検証を同時に行う環境で役立つ構成です。

VRF を活用するメリット

VRF を使う主なメリットは、ルーティングテーブルを論理的に独立させられる点 にあります。

通信の隔離

USER-A と USER-B の通信が混ざらないため、テナント間での通信分離が可能

IP アドレスの重複が許容される

各テナントが独立したルーティングテーブルを持つため、異なるテナント間で同一のプライベート IP アドレスを使用する構成 が可能。ISP 接続のシミュレーションで、実際の利用環境に近い構成を組む際に役立ちます

AAA Attribute List による柔軟な制御

Cisco の AAA Attribute List 機能を組み合わせると、接続するユーザーごとに動的な制御が可能になります。「ユーザー ID に基づいて、どの VRF のどの IP アドレスを割り当てるか」を定義できるため、物理的なポートに縛られない柔軟なプロビジョニングが実現します。

マルチテナント構成例

USER-A と USER-B の 2 つのテナントを想定し、それぞれに独立した VRF を割り当てる構成を示します。

aaa new-model
!
aaa authentication ppp default local
aaa authorization network default local
!
ip vrf for_user-a
 rd 1:1
!
ip vrf for_user-b
 rd 1:2

aaa attribute list to_user-a-site1
 attribute type addr 10.0.0.1 service ppp protocol ip
!
aaa attribute list to_user-b-site1
 attribute type addr 10.0.0.1 service ppp protocol ip
!
username user-a-site1@example.com password 0 cisco
username user-a-site1@example.com aaa attribute list to_user-a-site1
!
username user-b-site1@example.com password 0 cisco
username user-b-site1@example.com aaa attribute list to_user-b-site1

bba-group pppoe USER-A
 virtual-template 1
!
interface Loopback1
 ip vrf forwarding for_user-a
 ip address 10.0.0.254 255.255.255.0
!
interface Virtual-Template1
 mtu 1454
 ip vrf forwarding for_user-a
 ip unnumbered Loopback1
 no peer default ip address
 ppp authentication chap
!
interface Vlan10
 ip vrf forwarding for_user-a
 no ip address
 pppoe enable group USER-A

IOS XE 17.x 系での新構文への移行（マルチプロトコル VRF）

IOS XE では、IPv4 専用の旧構文（Single-protocol VRF）に加えて、IPv4 / IPv6 の両方を 1 つの VRF で扱える新構文（Multiprotocol VRF） が導入されています。新規構築では新構文の利用が推奨されています。

新構文での設定例（VRF for_user-a を新構文で書く場合）:

vrf definition for_user-a
 rd 1:1
 address-family ipv4
 exit-address-family
!
interface Virtual-Template1
 mtu 1454
 vrf forwarding for_user-a
 ip unnumbered Loopback1
 no peer default ip address
 ppp authentication chap

既存の旧構文 VRF を新構文に移行したい場合は、vrf upgrade-cli multi-af-mode common-policies コマンドで一括変換できます。ただし、一度新構文に移行すると旧構文には戻せない ため、影響範囲を確認したうえで実施することをおすすめします。

参考: Cisco / MPLS: Layer 3 VPNs Configuration Guide, IOS XE Release 3S – MPLS VPN VRF CLI for IPv4 and IPv6 VPNs
“Once you have converted to a multiprotocol virtual routing and forwarding (VRF) instance, you cannot convert the VRF back to an IPv4-only single-protocol VRF.”
（いったんマルチプロトコル VRF に変換すると、IPv4 専用のシングルプロトコル VRF には戻せません）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/xe-3s/mp-l3-vpns-xe-3s-book/mp-vpn-ipv4-ipv6.html

設計上の注意点と MTU / MSS の最適化

PPPoE サーバーを構築する際は、セッションの確立だけでなく、運用環境に近いパフォーマンスを再現する設計も意識します。

MTU / MSS サイズの設計

PPPoE 環境では、8 バイトのオーバーヘッド（PPPoE ヘッダ 6 バイト ＋ PPP Protocol ID 2 バイト） が付与されるため、通常のイーサネット環境より小さな MTU が必要になります。フラグメンテーションを抑制するため、MTU の調整が推奨されます。

接続事業者・回線種別によって最適値は異なるため、構築先の仕様確認をおすすめします。IPoE 方式との違いについては、関連記事『IPoE（IPv4 over IPv6）方式の仕組みとルーターー設定手順』でも整理しています。

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

PPPoE サーバーを構築する前に、機種・OS・トポロジに関する制約を把握しておくと、後からの手戻りを抑えられます。

機種・OS に関する制約

ISR 4000 シリーズでは PPPoE Server 機能が正式サポート外

コマンド自体は残っており動作する場合があるものの、Cisco の公式サポート対象外という扱いです。本番運用で利用する場合は、Cisco Feature Navigator で機種・IOS バージョンの対応状況を事前に確認することをおすすめします。

CEF（Cisco Express Forwarding）が必須

PPPoE サーバー機能は CEF 上で動作します。show ip cef summary で動作状況を確認しておくことをおすすめします。

Virtual-Access インターフェース上では CEF 以外のスイッチング方式は無効化される

flow / optimum switching を併用する設計はできません。

トポロジに関する制約

PPPoE は Frame Relay や FDDI / Token Ring 上では非サポート

イーサネットおよび ATM（PPPoEoA）上での利用が前提です。

PPPoE virtual template の mtu 設定が事実上必須

PPPoE オーバーヘッド 8 バイトを差し引いた値を設定しないと、正常な通信が成立しないケースがあります。

物理 1 インターフェースあたり 1 つの VRF のみ

1 つのサブインターフェースは 1 つの VRF にしか所属できません。1 つの物理ポートで複数 VRF のセッションを終端したい場合、VLAN サブインターフェースを VRF ごとに用意する 設計が必要です。

マルチテナント構成での制約

ユーザーごとに AAA Attribute List を個別に定義する

ユーザーごとの属性割り当ては VRF 単位ではなくユーザー単位で定義します。

Loopback / Virtual-Template / 終端インターフェースすべての VRF 設定を揃える

1 つでも VRF 設定が抜けると、セッションは確立してもルーティングが成立しないケースが発生しやすくなります。

ローカル認証では大規模運用に向かない

本記事の構成例はローカル DB 認証ですが、テナント数が増える場合は RADIUS など外部認証サーバーとの連携をおすすめします。

IOS XE での新構文移行に関する制約

vrf definition 新構文への移行は片方向のみ

いったん新構文に移行すると、旧構文（IPv4 専用 VRF）には戻せません。

既存インターフェースの設定が影響を受ける場合がある

新構文への移行コマンド vrf upgrade-cli 実行時、対象インターフェース上に IPv6 アドレスが設定されている場合は失われます。事前に設定をバックアップしておくことをおすすめします。

参考: Cisco / Application Services Configuration Guide, IOS XE 17.x – PPP over Ethernet
“Although Cisco Express Forwarding switching is supported, flow, and optimum switching are not; these configurations are ignored on the PPPoE virtual access interface.”
（Cisco Express Forwarding スイッチングはサポートされますが、flow / optimum スイッチングはサポートされず、PPPoE の Virtual-Access インターフェース上では無視されます）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/xe-3s/asr1000/bba-xe-3s-asr1000-book/bba-ppoe-enet-xe.html

動作確認とトラブルシューティングの基本コマンド

PPPoE サーバの設定後、想定どおりに動作しない場合の切り分けコマンドを 5 段階で整理します。

STEP

PPPoE セッションの確立確認

最初に、PPPoE セッション自体が確立しているかを確認します。

Router# show pppoe session

確認ポイント

• State が UP または PTA（PPP Termination Aggregation）になっているか
• RemMAC（リモート MAC）がクライアント側のインターフェース MAC アドレスと一致しているか
• VT（Virtual-Template 番号）が想定どおりか

セッション一覧に対象クライアントの行が出ていない場合、PPPoE Discovery 段階（PADI / PADO / PADR / PADS）で失敗している可能性があります。

STEP

認証フェーズの確認

セッションが安定しない、または認証エラーが疑われる場合、PPP のネゴシエーションをデバッグで追跡します。

Router# debug ppp negotiation
Router# debug ppp authentication
Router# debug pppoe events
Router# debug pppoe errors

確認ポイント

• LCP ネゴシエーションが完了しているか
• CHAP または PAP の認証が SUCCESS で終わっているか
• 認証失敗時、username / password の不一致や、aaa attribute list の参照漏れが出ていないか

デバッグ完了後は、undebug all で出力を停止します。

STEP

Virtual-Access インターフェースの状態確認

セッションが確立すると、サーバー側で動的に Virtual-Access インターフェースが生成されます。

Router# show interface virtual-access 1.1

確認ポイント

• protocol is up になっているか
• 所属する VRF（VRF Name）が想定どおりか
• 借用元の Loopback IP アドレスが表示されているか

STEP

ルーティングテーブルの確認

セッション確立後、サーバー側のルーティングテーブルにクライアントの IP アドレスが学習されているかを確認します。

! グローバルテーブル（基本構成の場合）
Router# show ip route | begin Gateway

! VRF を利用するマルチテナント構成の場合
Router# show ip route vrf for_user-a | begin Gateway

正常時は、動的生成された Virtual-Access 経由で /32 のホストルートが直接接続として学習されます。

Routing Table: for_user-a
（中略）
C       10.0.0.1/32 is directly connected, Virtual-Access1.1
C       10.0.0.2/32 is directly connected, Virtual-Access1.2

学習されない場合は、aaa attribute list の適用漏れか、Virtual-Template / Loopback / 終端インターフェースの VRF 紐づけ漏れが疑われます。

STEP

設定全体の整合確認

! BBA グループと Virtual-Template の紐づけ確認
Router# show running-config | section bba-group

! Virtual-Template の設定確認
Router# show running-config interface Virtual-Template1

! ユーザー名と AAA Attribute List の紐づけ確認
Router# show running-config | include username

確認ポイント

• bba-group pppoe <名前> の virtual-template 番号が、実際の Virtual-Template の番号と一致しているか
• pppoe enable group <名前> を設定したインターフェースが、対象 BBA グループ名を正しく参照しているか
• username <user> aaa attribute list <list> の行が、対象ユーザーごとに存在するか
• マルチテナント構成では、Loopback / Virtual-Template / 終端インターフェースの VRF 名が一致しているか

これらの整合確認は、複数テナントを構成する場合に効果的なチェックポイント です。VRF 名の打ち間違いやテンプレート番号の参照ずれは、セッションは確立してもルーティングが成立しない原因として頻出します。

まとめ

本記事では、Cisco ルーターで PPPoE サーバーを構築する手順を、基本構成から VRF を活用したマルチテナント構成まで整理しました。

• Cisco ルーターの PPPoE サーバー機能は、検証環境を閉塞網内で構築する際に役立つ。
• まず端末型払い出しのシンプル構成で組み、要件に応じて VRF を組み合わせる構造で設計するのが扱いやすい。
• VRF と AAA Attribute List を組み合わせると、テナント間での IP アドレス重複を許容した柔軟なマルチテナント構成が可能になる。
• 純粋な PPPoE 環境では MTU 1492、フレッツ網模擬では MTU 1454 を基準に設計する。
• IOS XE 17.x 系では IPv4 / IPv6 両対応の vrf definition 新構文への移行が推奨される。
• ISR 4000 シリーズでは PPPoE Server 機能が正式サポート外のため、機種・バージョンの確認を先に行うことをおすすめする。

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