Juniper MX Chassis
Juniper MX機材にまつわるメモ。構造や機材交換で確認する点、注意事項等々。
MX モジュール概要
いろいろモジュール名がでてくるが何をしているかはこれ読むとよい。
MPC,FPC,MIC,PIC
MPC≒FPC, MIC≒PIC。
MPC,MICというのが昔のFPC,PICという呼び名から変わったという雑な理解でもよさそう。
コマンドでみると内部的にはPICとか表示されたりもする。ただ利用者的にはあまりその差はないとは思う。
従来のFPCと違い、Trio-Chipというチップセットが搭載されたのがMPCっぽい。そのMPCに対応したのインターフェースカードがMIC。
CB
ContorlBaordのこと。正式にはSwitchContoroleBoard(SCB)。
いわゆるコントロールプレーンに該当する機能を提供するためのモジュール。
(正確にはREがコントロールプレーンの機能を提供している)
SCBを指すスロットはFPCとは別の専用のスロットなので注意。
SCBの役割としては次の3つ。
Routing Engineのモジュールの格納
LineCard間の通信の中継
シャーシ全体のコントロール
REを格納しているのは物理的にそうなっているのが確認できる。
大事な点としてLineCard間の通信はCBを経由している。
当然REもSCBにそれぞれ挿さる。これでCB,REはactive-backupで冗長化される。
CBの冗長化設定
CBはactive-backupの構成で二枚で冗長化されているが、機種によってはactive-activeでも運用できる。
この場合後述のFabricの利用可能なpathが増えることになるのでシャーシ全体でさばけるトラフィック帯域が増える。
ただしCBを両方使うことになるので片方のCBが壊れた場合に何かしらの影響がでる。
GRES(Graceful Routing Engine Switchover)
REが死んださいにForwardingを止めずにスイッチオーバーする機能。
データプレーンに影響は与えないが、コントロールプレーンの機能の保護はできない。
master側は次のイベントを検出した際にはmaster REが自発的にスイッチオーバーする。
master REカーネルが停止
master REでハードウェアエラー発生
管理者による手動切り替え
backup REはmasterからのkeepaliveパケットを2秒、または4秒受け取らなかった場合にはmasterが死んだものとみなしスイッチオーバーする。
NSR(Nonstop Active Routing)
一般的にはNSR(Non stop Routing)である。JUNOS用語としてはなぜかActiveが入っているが意味は一緒。 GRESでは失われるコントロールプレーンのルーティング情報を冗長化してコントロールプレーンのActiveBackupを高速に行う。routing protocol deamonであるrpdの情報をbackup REに保存する仕組み。
GRESが有効になっていないと使えない。
PFE(Packet Forwarding Engine)
いわゆるデータプレーン。一般的にはNPUと呼ばれる。 実体としては各ラインカードに複数存在する。
REと通信してPFEのforwarding tableを構築している。
下図はMPC3E Cassis PFE
https://gyazo.com/7703b484fe583fda53f50bc2671b17f7
XM: QoS分類やパケットバッファ
XF: ファブリックインターコネクト
LU: ルックアップメモリ及びパケット転送処理
DPC(Dense Port Concentrator)
集積コネクタ。ユーザー目線でいうと結局FPC/MPCとDPCは同じなのでFPC≒MPC≒DPCになる。
これよむと要はMPCのご先祖という感じっぽい。
DPCは後述のFabric Planeとそれぞれ接続されていて、FPCのトラフィックは最終的にFabricを経由してSCBにいく。
MX Fabric
MXシリーズではPFEが複数あり、それぞれで分散処理をする構成である。PFEはDPC/MPCごとに複数ある。
もしパケットフォワーディング先が一つのPFE内で完結しない場合は別のPFEにパケットを転送しないとならない。このときの転送で使われるのがFabric Planeと呼ばれる内部バス。たぶんバックプレーンみたいなもの。
MX480/240の場合はPlaneはSCBごとに4つあり、複数あることで帯域幅を稼いでいる。SCBが冗長化されている場合にはactive側落ちた時には当然backup側のSCBがactiveになり、同時にactive Fabric Planeも変わる。
https://gyazo.com/aa83aa5101987a99c84fb04d14f12998
機材交換オペレーション
何をするにもalarm、logはつねに確認。logについてはjunosはinfoレベルのログが大すぎるので怪しいログが交換後に定常的にでなさそうかを見る。
FPC間の通信はCBを経由するのでFPC交換時にはFPCの状態ももちろんだが、CBのfabric planeのリンクがきちんとあがるかも確認すること。
確認コマンド
code:=commands
show chassis fpc detail
show chassis fabric fpcs
show chassis fabric plane