PPPoE dead-criteriaについて


Cisco機器(ASR1000シリーズ)をBASとし、Radiusサーバーを認証構成を組んだ際、PPPoE dead-criteriaの動作が不明だったため、忘れないうちにまとめておきます。

これ、絶対記録しておかないと後々絶対に忘れちゃう。。。
また、こんなことがあったり、誰かがこの問題にぶち当たった時に参考にしてください。


BAS ~ Radiusへの再送を整理する

PPPoE設定時にすごく悩んだところ。
retransmit、timeout とdead-criteriaの違いがごちゃごちゃになったので
違いを以下にメモっとく。

メモはdead-criteriaで設定時の動作

radius-server dead-criteria time 90 tries 10
  1. 正常にセッションが張れた直後90秒以内に、サーバに障害が発生し、リトランスミット10回が失敗した際、正常にセッションが張れた直後から90秒後からの認証要求で対象のサーバをDEAD判定とする。
  2. また、セッションが張れ、90秒以内にサーバーの障害が発生し、リトランスミット10回が失敗した際、その90秒以内に正常にセッションが張れると、deadのカウントはクリアされる。
  3. ユーザー単位ではなく、総タイムアウト回数(リトランスミット10回)で判断する。


timeがtriesより短いときは再送回数だけ頭に入れておけばよし

※以下の設定場合。

radius-server dead-criteria time 1 tries 3

上記での設定ではセッションが確立後、1秒経過かつ連続3回応答がない場合DEAD判定とみなす。
なお、セッション確立後、1秒以内にセッションが成立するとクリア(0カウント)となる。

設定しても動作確認をしないとわからない。
デバックコマンドで、PPPoEと認証サーバ(radius)の動きを確認しながら見てくこと。

まとめ

PPPoEを設定するにあたり、dead-criteriaは頭がこんがらがっちゃいますよね。
BASでデバックを走らせながら見ていくことでしか、わからないです。

ようは実際に動かして確認しろってことっすね。

以下の記事はRadiusで認証するための構築手順を記載しています。
ご参考にどうぞ。

それでは!


関連記事


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

ABOUTこの記事をかいた人

blank

インターネット関連のSEをやっています。 ネットワーク、サーバー、ストレージ、仮想基盤まで幅広く手を出しており、MVNOの構築経験もあります。 現在は、Pythonを使ったプログラミングの開発をしネットワークの自動化ツールを作成しています! Pythonの入門書も作成しているので、ぜひ参考にしてください!