MX が IPsec を終端する前に揃えておくべき条件
設定をコミットできても、証明できるのはパーサーだけであり、経路ではありません。サービスが実際に動くかどうかは、プラットフォームのタプルの五つの要素が決めます。
設定はきれいにコミットでき、インターフェースも起きているのに、トンネルは確立を拒否したままです。ログのどこにも、このプラットフォームではできないとは書かれていません。単に、やっていないだけです。Junos では IPsec はサービスであり、シャーシ、サービスハードウェアまたはソフトウェア経路、リリースという特定の組み合わせがあって初めて実行でき、機能ページが説明しているのはソフトウェアの能力であって、あなたの装置のことではありません。タプルは要素ごとに確認する必要があります。コミット結果が証明するのはパーサーだけだからです。
パケットが実際に通る場所
IPsec 用に選択されたトラフィックは、それを暗号化するコンポーネントに到達しなければなりません。サービスモジュールを備えたプラットフォームでは、選択されたフローはそのモジュールへ誘導され、その後で転送経路に戻ります。モジュールが存在しない、容量が不足している、あるいはインターフェースにバインドされていない場合、設定は存在するのにパケットは一つも処理されません。コミットの出力からは、その状態を健全な状態と区別できません。
ソフトウェアで実装する方式では、処理はルーティングエンジン上またはインラインハードウェア内に置かれ、リソースの上限は大きく異なります。設定に見えているトンネルが、実際にどちらの経路で運ばれているのかは分かりません。
タプルの五つの要素
どの推奨事項を読む前でも、まず組み合わせを書き留めてください。一つの要素が他の要素を無効にすることがあるからです。三年前にサービスを支えていた部品番号は、このシャーシに入っているカードとリリースについて何も語りません。以下の行をチェックリストとして読み、設定からは分からない値を埋めてください。
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
アドレスファミリーとワークロードは、人が飛ばしがちな二つの行であり、どちらも確認は安く、後から気づくと高くつきます。タプルは表計算ソフトからではなく装置から読んでください。設定が報告するのは、あなたが要求した内容であり、実際に搭載されている内容ではないからです。大部分は二つのコマンドで足ります。show chassis hardware は実際に装着されているカードを示し、show version は正確なリリースを示します。どちらも設定が正しいかどうかに依存しない、という点が要点です。
show chassis hardware
show versionリリースの関門は本物の関門
リリースの細部は形式の問題ではありません。Juniper の IPsec の概要 では、マルチサービスカードの AES-GCM 対応は Junos 17.3R1、FIPS モードは 17.4R1 からとされています。したがって同じ機能でも、プラットフォームの運用方式によって二つのしきい値があり、どのモードで動かすかが、どちらが当てはまるかを決めます。機能一覧を確認する前に、モードを確認してください。
読むべきは、実際に導入されている正確なバージョンのリリースノートであり、文書化されている最新版ではありません。後から登場したビルドの機能は、それ以前のビルドに存在すると見なせませんし、あるカード向けに書かれた記述が別のカードに移せるものでもありません。リリースノートの該当行を設計記録に写し、その主張に根拠を添えてください。プラットフォームファミリー向けに書かれたサポート記述は、あなたが動かすモードや手持ちのカードについての記述ではないからです。
容量はワークロードで決まり、見出しの数字では決まらない
測定条件を伴わない見出しのスループット値は、マーケティングの数字です。小さいパケットは大きいものよりビット当たりのコストがはるかに高く、同時接続のアソシエーションはメモリを消費し、カードを共有する他のあらゆるサービスが残りを減らします。
想定されるトラフィックから見積もってください。典型的なパケットサイズと最悪時のサイズ、ピアの数、そのカードが NAT や他のサービスも終端するかどうかです。そのうえで、ある日ある経路が設計の想定以上の負荷を運ぶ日のために余裕を残します。ハードウェアが遊んでいる前提の容量計画は、計画ではなく願望です。その数字がビジネスケースに関わるなら、代表的な負荷の下で装置上で一度測定し、その測定値を設計と一緒に保管してください。
設計より先に記録を書く
設計が必要とする能力ごとに、プラットフォームの参照情報、リリースに合った文書、未解決の制約を一か所にまとめます。タプルのある行が満たせない場合は、古くなった購入リストに合わせて設計を作り直すのではなく、別の承認済みゲートウェイと比較してください。記録には、どのシステムがその作業を行うのか、どのような制限の下で行うのかを書くべきです。
ピアの確認はその後です。遠端とのプロトコル互換性は次の問いであり、ローカル側のサポートの代わりには決してなりません。提案で合意していても、パケットを一度も暗号化しないシャーシを助けることはできないのです。