NEC UNIVERGE IX の PPPoE 設定手順|Cisco との違いと NAPT

  • URLをコピーしました!
目次

はじめに

NEC UNIVERGE IX シリーズは、通信事業者や企業の拠点ルーターとして広く利用されているメーカーです。コマンド体系は Cisco IOS に似た雰囲気を持ちますが、PPPoE の設定構造には明確な違いがあり、Cisco と同じ感覚で設定しようとすると戸惑う場面があります。本記事は、NEC UNIVERGE IX シリーズを PPPoE クライアントとして設定する手順を、Cisco との違いとあわせて整理します。

PPPoE そのものの仕組み(ディスカバリ / セッションの 2 段階)や、フレッツ網で MTU 1454 / MSS 1414 となる根拠については、親記事『PPPoE 接続の仕組みと設定の基本|主要 4 メーカーの設計比較』で解説しています。本記事は NEC 固有の設定と運用に絞って掘り下げます。検証は UNIVERGE IX シリーズ(Ver.10 系)を想定しています。

この記事でわかること
  • NEC IX の PPPoE 設定構造と、Cisco との違い(Dialer を使わない点)
  • PPP プロファイルとサブインターフェースを組み合わせた基本設定の手順
  • ip napt enable による NAPT 有効化と、MTU / MSS の調整
  • VLAN・NAPT チューニング・高速転送などの応用構成と切り分け

NEC IX の PPPoE 設定で押さえるべき要点は 2 つです。第一に、PPPoE はサブインターフェース(例: GigaEthernet0.1)に対して encapsulation pppoe で設定し、認証情報は PPP プロファイルとして定義して ppp binding で結びつけるという構造です。Cisco のような Dialer インターフェースは使いません。第二に、NAPT はインターフェース配下の ip napt enable 1 行で有効化できるという手軽さです(詳細は各セクションで扱います)

NEC IX の PPPoE 設定の全体像(Cisco との違い)

具体的なコマンドに入る前に、NEC IX の PPPoE 設定がどのような構造になっているのか、Cisco との対比で整理します。

コマンド体系は Cisco IOS に近い

NEC IX のコマンドは、interface でインターフェースを選択し、no shutdown で有効化し、show 系コマンドで状態を確認するなど、Cisco IOS に似た操作感を持ちます。ip route default でデフォルトルートを設定する書き方も近く、Cisco に慣れたエンジニアであれば全体の流れは把握しやすいメーカーです。

一方で、PPPoE まわりの設定構造は Cisco と異なります。似ているがゆえに「Cisco と同じだろう」と進めると差異につまずくため、違いを意識しておくことが重要です。

Dialer ではなくサブインターフェースに直接設定する

最大の違いは、PPPoE セッションを終端する論理インターフェースの考え方です。

Cisco

Dialer インターフェース(仮想インターフェース)を作成し、物理ポートと dial-pool 番号で紐づける。認証・IP・MTU は Dialer 配下に集約する。

NEC IX

物理ポートのサブインターフェース(例: GigaEthernet0.1)に encapsulation pppoe を設定し、そのサブインターフェース自体を PPPoE インターフェースとして扱う。Dialer は使わない。

NEC IX では、Dialer のような独立した仮想インターフェースを作らず、サブインターフェースに直接 PPPoE をカプセル化します。認証情報については、PPP プロファイルという単位で接続 ID とパスワードを定義し、それをサブインターフェースから ppp binding <プロファイル名> で参照する構造です。Cisco の「物理 → Dialer の紐づけ」に対し、NEC IX は「サブインターフェース+ PPP プロファイルの参照」という構造になります(メーカー間の比較は親記事の早見表を参照してください。なお、Cisco 側の Dialer 構成の詳細は関連記事『Cisco ルーターの PPPoE 設定手順|Dialer 構成と ip mtu の違い』で扱っています)。

参考: NEC / UNIVERGE IX シリーズ IX-R/IX-V 機能説明書 PPPoE の設定
“interface GigaEthernet1.1 encapsulation pppoe ppp binding profile-1 ip address ipcp ip napt enable”
(サブインターフェースに PPPoE をカプセル化し、PPP プロファイルを結びつけ、IPCP で IP を取得し、NAPT を有効化する)
https://support.necplatforms.co.jp/ix-nrv/manual/fd/02_router/10_pppoe.html

CLI での基本設定手順

ここでは、GigaEthernet0.0 を LAN 側、GigaEthernet0.1 を WAN 側(PPPoE サブインターフェース)とする一般的な構成を例に、CLI での設定手順を整理します。設定は「PPP プロファイル → LAN 側 → WAN 側(PPPoE)→ デフォルトルート」の順で進めます。

PPP プロファイルの定義(認証情報)

まず、プロバイダーへの接続情報を PPP プロファイルとして定義します。

ppp profile flets-v4
 authentication myname user-a-site1@example.com
 authentication password user-a-site1@example.com pppoe-secret
  • ppp profile flets-v4: 「flets-v4」という名前の PPP プロファイルを作成する。
  • authentication myname: 対向(プロバイダー)に名乗る接続 ID を設定する。
  • authentication password <ID> <パスワード>: 接続 ID に対応するパスワードを設定する。

認証方式は、PPP プロファイルに対する authentication accept で指定します。既定値は authentication accept chap-pap で、CHAP を試みた後に PAP を試みる動作になるため、一般的なフレッツ接続では明示設定なしでも CHAP / PAP の両方に対応します。PPPoE クライアントとして接続する場合、対向を認証する authentication request の設定は不要です。

LAN 側と WAN 側(PPPoE)の設定

LAN 側インターフェースに IP アドレスを設定し、WAN 側のサブインターフェースに PPPoE を設定します。

# --- LAN 側インターフェース ---
interface GigaEthernet0.0
 ip address 192.168.1.254/24
 no shutdown
!
# --- WAN 側インターフェース(PPPoE サブインターフェース) ---
interface GigaEthernet0.1
 encapsulation pppoe
 auto-connect
 ppp binding flets-v4
 ip address ipcp
 ip mtu 1454
 ip tcp adjust-mss auto
 ip napt enable
 no shutdown

WAN 側の各コマンドの役割は次のとおりです。

  • encapsulation pppoe: このサブインターフェースを PPPoE でカプセル化する。
  • auto-connect: PPPoE セッションを自動接続に設定する。
  • ppp binding flets-v4: 先に定義した PPP プロファイル「flets-v4」を結びつける。
  • ip address ipcp: IPCP のネゴシエーションで払い出された IP アドレスを使用する。
  • ip mtu 1454: MTU をフレッツ網の値に設定する。
  • ip tcp adjust-mss auto: MSS を MTU に応じて自動調整する。
  • ip napt enable: このインターフェースで NAPT(IP マスカレード)を有効化する。

NAPT とデフォルトルート

NEC IX の NAPT は、インターフェース配下の ip napt enable 1 行で有効化できます。Cisco のように ACL を定義してグローバル設定で紐づける必要がなく、設定が簡潔です。最後に、デフォルトルートを PPPoE サブインターフェースへ向けます。

ip route default GigaEthernet0.1
  • ip route default GigaEthernet0.1: デフォルトルートの出力先を PPPoE サブインターフェースに指定する

NAPT の対象は、NAPT を有効化したインターフェースを通過する内→外方向の通信が基本です。外→内方向の通信を一部許可したい場合は、静的 NAPT(ip napt static)を併用します。

主要コマンドの意味

設定で登場するコマンドのうち、NEC IX 特有で意味を押さえておきたいものを補足します。

ppp profile と ppp binding

NEC IX の認証情報は、PPP プロファイルという設定単位で管理します。これは、接続 ID とパスワードなどの PPP 認証情報を名前付きの定義としてまとめ、インターフェースから参照する仕組みです。

# プロファイルの定義
ppp profile flets-v4
 authentication myname user-a-site1@example.com
 authentication password user-a-site1@example.com pppoe-secret
!
# インターフェースからの参照
interface GigaEthernet0.1
 ppp binding flets-v4
  • ppp profile flets-v4: 認証情報をまとめた「flets-v4」というプロファイルを定義する。
  • ppp binding flets-v4: サブインターフェースに、定義済みのプロファイルを結びつける。

認証情報を直接インターフェースに書くのではなく、プロファイルとして分離して参照する点が特徴です。複数のサブインターフェースで同じ認証情報を使い回したり、設定の見通しをよくしたりする際に役立ちます。

ip address ipcp

ip address ipcp は、IPCP(IP Control Protocol)のネゴシエーションで対向から払い出された IP アドレスを、そのインターフェースに割り当てる指定です。Cisco の ip address negotiated に相当します。

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

ip napt enable

ip napt enable は、そのインターフェースで NAPT(IP マスカレード)を有効化する 1 行のコマンドです。NEC IX の NAPT 設定は簡潔で、WAN 側インターフェースにこの 1 行を記述するだけで、内→外方向の通信に対して NAPT が動作します。

NEC IX の NAPT は、内→外方向のアドレス変換履歴(NAPT キャッシュ)がない限り、外→内方向の通信を遮断する簡易的なファイアウォールとしても動作します。外部から内部への通信を一部許可したい場合は、静的 NAPT(ip napt static)を設定します。

参考: NEC / UNIVERGE IX シリーズ FAQ(IPv4、NAT、DHCP)
“通常NAPT機能は内→外方向へのアドレス変換履歴(NAPTキャッシュ)がない限り外→内方向への通信は全てNAPTによりブロックする”
https://jpn.nec.com/univerge/ix/faq/ip.html

MTU / MSS の調整

NEC IX の PPPoE インターフェースでは、MTU と MSS をそれぞれ設定します。

interface GigaEthernet0.1
 ip mtu 1454
 ip tcp adjust-mss auto
  • ip mtu 1454: インターフェースの MTU を設定する。NEC IX の PPPoE インターフェースの MTU は基本的に 1492 byte ですが、フレッツサービス(フレッツ光ネクスト等)では 1454 byte、NTT 西日本のフレッツ・光プレミアムでは 1438 byte が目安になります。
  • ip tcp adjust-mss auto: MSS を自動調整する。auto を指定すると、そのインターフェースの MTU 長から 40 byte(IP ヘッダ 20 byte + TCP ヘッダ 20 byte)を引いた値が MSS に設定されます。

ip tcp adjust-mss auto を使うと、MTU 1454 のインターフェースでは MSS が自動的に 1414 に調整されます。手動で値を計算する必要がないため、設定ミスを抑えられます。実際に、show ip interface の出力で MTU 1454 に対して MSS(TCP MSS adjustment size)が 1414 と表示されることが確認できます。

参考: NEC / UNIVERGE IX シリーズ FAQ(PPPoE)
“基本的には「1492byte」になりますが、フレッツサービス(フレッツ光ネクスト、Bフレッツ、フレッツADSL)の場合は「1454byte」”
https://jpn.nec.com/univerge/ix/faq/pppoe.html

MTU / MSS の値の根拠(フレッツ網のオーバーヘッド)については、『PPoE 接続の仕組みと設定の基本|主要 4 メーカーの設計比較』で詳しく解説しています。

応用構成

VLAN タグ付き PPPoE(サブインターフェース)

NEC IX では、もともと PPPoE をサブインターフェースに設定するため、VLAN タグ付きの構成にも対応しやすい設計です。ISP が VLAN タグを指定する場合は、サブインターフェースに VLAN ID を設定したうえで、encapsulation pppoe を構成します。

NEC IX では、1 つのイーサネットポート当たり最大 8 セッションの PPPoE を扱えます(IX シリーズ共通)。また、1 つの LAN ポート当たり 32 個のサブインターフェースを実装しています(全機種共通)。複数のプロバイダーや IPv4 / IPv6 を別セッションで構成する場合も、サブインターフェースを分けて設定します。具体的な VLAN 設定コマンドは、対象機種のコマンドリファレンスで確認することをおすすめします。

NAPT エントリ数のチューニング

大規模拠点や、多数の端末が同時に通信する環境では、NAPT キャッシュ(変換テーブル)のエントリ数が上限に達し、新たな通信が行えなくなることがあります。この場合、インターフェース単位での NAPT エントリ数の上限を調整します。

interface GigaEthernet0.1
 ip napt enable
 ip napt translation max-entries 16384
  • ip napt translation max-entries: そのインターフェースの NAPT キャッシュのエントリ数上限を設定する

NEC 公式の機能説明書でも、NAPT キャッシュのオーバーフローが頻繁に発生する場合は、仕様範囲内でエントリ数の上限を増やすか、タイムアウトを調整する方法が案内されています。また、特定のホストが大量にキャッシュを消費して他のホストの通信に影響する場合は、ホスト単位での制限も検討します。

参考: NEC / UNIVERGE IX シリーズ IX-R/IX-V 機能説明書 NAT/NAPT の設定
“頻繁にNAPTキャッシュのオーバーフローが発生している場合は仕様範囲内で「インタフェース単位での制限」の値を増やすか、タイムアウトを調整してください”
https://support.necplatforms.co.jp/ix-nrv/manual/fd/02_router/13-2_nat.html

高速転送に関する補足

NEC IX シリーズには、パケット転送を最適化する高速転送機能が備わっています。ただし、機能の名称・既定の有効/無効・対象機種は世代やファームウェアによって異なります。大規模拠点でパフォーマンスを最適化する場合は、対象機種の機能説明書やコマンドリファレンスで、高速転送機能の仕様と NAPT 併用時の挙動を確認することをおすすめします。

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

設定後の動作確認と、想定どおりに動作しない場合の切り分け手順を整理します。NEC IX では、show pppoe status でセッションの状態を、show ip interface で IP 取得の状況を確認できます。

確認コマンド

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

# PPPoE セッションの状態確認
show pppoe status

# サブインターフェースの IP 取得状況(IPCP で IP が付与されているか)
show ip interface GigaEthernet0.1

# PPPoE セッションの統計情報(PADI / PADO / PADR / PADS / PADT)
show interfaces GigaEthernet0.1 detail

# PPP の状態(CHAP / PAP の認証統計)
show ppp GigaEthernet0.1

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

show ip interface GigaEthernet0.1 で「Address determined by IPCP」とともにグローバル IP が表示されていれば、PPPoE セッションが確立し IP 取得まで完了しています。このとき、MTU 1454 に対して MSS(TCP MSS adjustment size)が 1414 と表示されることもあわせて確認できます。

切り分けの進め方

NEC 公式の障害切り分けガイドラインでは、症状に応じて確認するコマンドが整理されています。

STEP
PADI を繰り返し送出しているが PADO が返らない

show pppoe status の統計で「PADI: outputs / retries」が増え続け、「PADO: inputs」が 0 のままの場合、対向(BAS)まで到達できていない可能性があります。ONU や回線側ポートのリンク状態、配線を確認します

STEP
認証で失敗している

show ppp GigaEthernet0.1 で CHAP または PAP の「failures」の値が増え続けている場合、接続 ID / パスワードの設定に誤りがある可能性があります

STEP
IP アドレスが取得できない

show interfaces GigaEthernet0.1 で「PPP state is ppp opened (address negotiation failed)」と表示される場合、固定 IP 契約でのアドレス不一致などが疑われます。設定したアドレスとプロバイダー通知値を確認します

STEP
PADI / PADT の送受信が異常に多い

PPP セッションの接続・切断を繰り返している状態です。回線状態を確認します

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

NEC IX の PPPoE で遭遇しやすいトラブルを整理します。

プロファイル名の不一致

ppp profile で定義した名前と、サブインターフェースの ppp binding で指定した名前が一致しているかを確認する。NEC IX 特有のつまずきどころ。

NAPT の設定漏れ

セッションは確立し IP も取れているのに LAN から通信できない場合、WAN 側サブインターフェースに ip napt enable が設定されているかを確認する。

デフォルトルートの向き先

ip route default の出力先が PPPoE サブインターフェース(例: GigaEthernet0.1)になっているかを確認する。

Web の一部が表示されない / 通信が遅い

MTU / MSS の設定を確認する。NEC 公式でも、この症状は Path-MTU-Black-Hole 問題の影響が考えられると案内されている

なお、NEC IX を対向の PPPoE サーバー(BAS)側として構成する手順は、UNIVERGE IX シリーズ機能説明書の「PPPoE サーバーの設定」で扱われています。検証環境を 1 台で完結させたい場合に役立ちます。

まとめ

本記事では、NEC UNIVERGE IX シリーズを PPPoE クライアントとして設定する手順を、Cisco との違いから NAPT・MTU / MSS の設計、トラブルシューティングまで整理しました。Dialer を使わずサブインターフェースに直接 PPPoE を設定する構造と、PPP プロファイルを ppp binding で結びつける考え方を押さえることが、設定の前提になります。

  • PPPoE はサブインターフェースに encapsulation pppoe で設定し Dialer は使わない。
  • 認証情報は ppp profile で定義しインターフェースから ppp binding で参照する。
  • ip address ipcp は IPCP で払い出された IP を使う指定で Cisco の negotiated に相当
  • NAPT はインターフェース配下の ip napt enable 1 行で有効化できる。
  • MSS は ip tcp adjust-mss auto により MTU から 40 byte を引いた値が自動設定される。
  • 大規模拠点では ip napt translation max-entries でエントリ数上限を調整する。
  • 切り分けは show pppoe status と show ppp を起点に到達性・認証・IP 取得を確認する。

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

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ(ネットワーク・サーバ・クラウド・セキュリティ)の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus(取得から20年以上)/ VCAP-DCA / Azure Solutions Architect Expert

▶ 運営者プロフィール(詳細)

目次