CRS-1 と IOS XR の動作に関するベスト プラクティス

ダウンロード オプション

  • PDF     (526.9 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (238.0 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (467.9 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2006 年 11 月 1 日
Document ID:71770

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

概要

このドキュメントでは、次について説明します。

  • プロセスとスレッド

  • CRS-1 ファブリック

  • コントロール プレーン

  • Rommon と Monlib

  • Physical Layer Interface Module（PLIM; 物理レイヤ インターフェイス モジュール）と Modular Service Card（MSC; モジュラ サービス カード）

  • 構成管理

  • セキュリティ

  • アウトオブバンド

  • Simple Network Management Protocol（SNMP）

前提条件

要件

Cisco IOS® XRに関する知識があることが推奨されます。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

  • Cisco IOS XR ソフトウェア

  • CRS-1

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

Cisco IOS XR の概要

Cisco IOS XR は、規模の拡大縮小が可能な設計になっています。カーネルはマイクロカーネル アーキテクチャであり、プロセス管理、スケジューリング、信号、タイマーなど、不可欠なサービスだけが提供されます。ファイル システム、ドライバ、プロトコル スタック、アプリケーションなど、他のすべてのサービスはリソース マネージャとしてみなされ、メモリ保護されたユーザ領域で実行されます。プログラムの設計によっては、これらの他のサービスを実行時に追加したり削除したりできます。マイクロカーネルのフットプリントは 12 KB に過ぎません。マイクロカーネルと基本オペレーティング システムは QNX Software Systems によって提供され、Neutrino と呼ばれています。QNX は、リアルタイム オペレーティング システム設計を専門としています。マイクロカーネルはプリエンプティブであり、スケジューラは優先順位ベースです。このため、プロセス間でのコンテキスト スイッチングが非常に高速になり、必要な場合には常に最高の優先順位のスレッドが CPU にアクセスできます。これらは Cisco IOS XR で活用される利点の一部です。ただし、最大の利点としては、オペレーティング システム コア内部の Inter Process Communication（IPC; プロセス間通信）の継承設計が挙げられます。

Neutrino はメッセージ パッシング型のオペレーティング システムであり、すべてのスレッド間におけるプロセス間通信の基本的な手段はメッセージです。特定のサーバがサービスを提供する場合、メッセージの交換用にチャネルが作成されます。クライアントは、関連ファイルの記述子に直接マッピングすることでサーバ チャネルに接続して、サービスを使用します。クライアントとサーバの間のすべての通信は、同じメカニズムによって実行されます。CRS-1 などのスーパー コンピュータにとっては、このことが非常に大きな利点となります。標準の UNIX カーネルでローカルの読み取り動作が実行される場合は、次を検討してください。

  • カーネルへのソフトウェア割り込み。

  • カーネルによりファイル システムに手配される。

  • データが受信される。

リモートの場合は次を検討します。

  • カーネルへのソフトウェア割り込み。

  • カーネルにより NFS が手配する。

  • NFS によりネットワーキングの構成要素が呼び出される。

  • リモートでネットワーキングの構成要素が手配される。

  • NFS が呼び出される。

  • カーネルによりファイル システムが手配される。

ローカル読み取りのセマンティックスとリモート読み取りのセマンティックスは同一ではありません。ファイル ロッキングと設定権限の引数とパラメータは異なります。

次のように QNX のローカルの場合を検討します。

  • カーネルへのソフトウェア割り込み。

  • カーネルによってファイル システムへのメッセージ パッシングが実行される。

次のように非ローカルの場合を検討します。

  • カーネルへのソフトウェア割り込み。

  • カーネルが IPC 転送メカニズムである QNET に移る。

  • QNET がカーネルに移る。

  • カーネルによりファイル システムが手配される。

引数引き渡しとファイル システム パラメータに関するすべてのセマンティックスは同一です。すべては IPC インターフェイスでデカップリングされているため、クライアントとサーバを完全に分離することが可能です。これは、時間や場所を選ばずに任意のプロセスが実行可能であることを意味します。要求を処理している特定のルート プロセッサの負荷が高すぎる場合は、DRP で稼働している別の CPU にこの処理を簡単に移行できます。異なる CPU 上でさまざまな処理を実行するスーパー コンピュータは、他のノードと簡単に通信できる複数のノードに分散しています。このインフラストラクチャは規模の拡大縮小を行う機会を提供するために配置されています。Cisco ではこの利点を活用して、メッセージ パッシング カーネルの基本的な動作に関連する付加的なソフトウェアを作成し、CRS ルータによる何千ものノードへの規模の拡大を可能にしました。ノード（この場合は CPU）では、Route Process（RP; ルート プロセス）、Distributed Route Processor（DRP; 分散ルート プロセッサ）、Modular Services Card（MSC; ジュラ サービス カード）、または Switch Processor（SP; スイッチ プロセッサ）のいずれであっても、OS のインスタンスが稼働します。

プロセスとスレッド

Cisco IOS XR 内では、プロセスとは 1 つ以上のスレッドが含まれる、メモリ上の保護領域を指します。プログラマの観点からは、スレッドで作業が実行され、各スレッドでは特定のタスクを実行するための論理的な実行パスが遂行されます。実行のフローでスレッドに必要なメモリはスレッドが動作するプロセスに属するもので、他のプロセス スレッドからは保護されています。スレッドは実行の単位であり、スタックおよびレジスタなどの実行コンテキストが含まれています。プロセスは仮想アドレス空間を共有するスレッドのグループであり、プロセスに単一のスレッドだけを含ませることも可能ですが、多くの場合は複数のスレッドが含まれています。あるプロセス内のメモリに別のプロセス内の他のスレッドが書き込もうとすると、この違反プロセスは削除されます。プロセス内で複数のスレッドが動作している場合、そのスレッドはプロセス内の同じメモリにアクセスできるので、結果としてそのスレッドは別のスレッドのデータに上書きできることになります。同じプロセス内でのこのようなスレッドを回避するためには、リソースへの同期を維持する手順を実行します。

サービスに対する相互排他性を保証するために、スレッドでは Mutual Exclusion（MUTEX）と呼ばれるオブジェクトが使用されます。MUTEX を備えたスレッドとは、例のようにメモリの特定領域への書き込みが可能なスレッドです。MUTEX を備えていない他のスレッドは書き込みができません。Semaphore、Conditional Variable 別名 Condvar、Barrier、および Sleepon など、リソースへの同期を実現する他のメカニズムも存在します。これらについてはこのドキュメントでは説明していませんが、これらの役割の一部として同期サービスの提供があります。ここで説明した原理を Cisco IOS に当てはめてみると、Cisco IOS は多くのスレッドを動作させている単一のプロセスであり、これらのすべてのスレッドは同じメモリ領域にアクセスできます。ただし、Cisco IOS ではこれらのスレッドはプロセスと呼ばれます。

プロセスとスレッドの状態

Cisco IOS XR には、サービスを提供するサーバと、サービスを利用するクライアントが存在します。1 つのプロセスに、同じサービスを提供する多くのスレッドを含めることができます。別のプロセスには、任意の時点で特定のサービスを要求する可能性のある多くのクライアントを含めることができます。サーバへは常にアクセスできるわけではなく、クライアントがサービスへのアクセスを要求する場合、サーバが解放されるのを待つことになります。このような状態では、クライアントはブロックされていると呼ばれます。これをブロッキング クライアント サーバ モデルと呼びます。クライアントがブロックされる原因には、クライアントが MUTEX などのリソースを待っていたり、サーバがまだ応答していなかったりすることがあります。

ospf プロセス内のスレッド ステータスを確認するには、show process ospf コマンドを発行します。

RP/0/RP1/CPU0:CWDCRS#show process ospf
                  Job Id: 250
                     PID: 110795
         Executable path: /disk0/hfr-rout-3.2.3/bin/ospf
              Instance #: 1
              Version ID: 00.00.0000
                 Respawn: ON
           Respawn count: 1
  Max. spawns per minute: 12
            Last started: Tue Jul 18 13:10:06 2006
           Process state: Run
           Package state: Normal
       Started on config: cfg/gl/ipv4-ospf/proc/101/ord_a/routerid
                    core: TEXT SHAREDMEM MAINMEM
               Max. core: 0
               Placement: ON
            startup_path: /pkg/startup/ospf.startup
                   Ready: 1.591s
               Available: 5.595s
        Process cpu time: 89.051 user, 0.254 kernel, 89.305 total
JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
250    1      40K  10 Receive       0:00:11:0509 ospf
250    2      40K  10 Receive       0:01:08:0937 ospf
250    3      40K  10 Receive       0:00:03:0380 ospf
250    4      40K  10 Condvar       0:00:00:0003 ospf
250    5      40K  10 Receive       0:00:05:0222 ospf

OSPFプロセスにはジョブID(JID)が付与され、これは250です。これは、実行中のルータや通常は特定のバージョンのCisco IOS XRでは変更されません。ospf プロセス内には 5 つのスレッドが存在し、それぞれに独自の Thread ID（TID）が付与されています。 リストには、各スレッドのスタック容量、各スレッドの優先順位、および各スレッドの状態が示されています。

同期メッセージ パッシング

QNX がメッセージ パッシング型のオペレーティング システムであることはすでに述べてあります。実際には、QNX は同期メッセージ パッシング型のオペレーティング システムです。オペレーティング システムの問題の多くは、同期メッセージングに反映されます。これは、同期メッセージ パッシングにより問題が引き起こされているという意味ではなく、問題の症状が同期メッセージ パッシングで発現するという意味です。同期動作なので、CRS-1 オペレータはライフサイクルや状態情報へ簡単にアクセスでき、トラブルシューティング プロセスに役立てることができます。メッセージ パッシングのライフ サイクルは次のようなものです。

  • サーバによってメッセージ チャネルが作成される。

  • クライアントがサーバのチャネルに接続する（posix open に類似）。

  • クライアントによってサーバにメッセージが送信され（MsgSend）、応答を待ちながらブロックされる。

  • サーバではクライアントからのメッセージが受信され（MsgReceive）、メッセージが処理され、クライントへ応答が行われる。

  • クライアントではブロックが解除され、サーバからの応答が処理される。

このブロッキング クライアント/サーバ モデルは同期メッセージ パッシングです。つまり、クライアントではメッセージが送信されると、ブロックされます。サーバでメッセージが受信され、処理されてからクライアントに応答が返されると、クライアントではブロックが解除されます。詳細情報は次のとおりです。

  • サーバは「RECEIVE」状態で待機する。

  • クライアントでサーバにメッセージが送信され、「BLOCKED」状態になる。

  • サーバではメッセージが受信され、ブロックが解除される（「RECEIVE」状態で待機している場合）。

  • クライアントは「REPLY」状態に移行する。

  • サーバは「RUNNING」状態に移行する。

  • サーバでメッセージが処理される。

  • サーバからクライアントに応答される。

  • クライアントでブロックが解除される。

クライアントやサーバの状態を表示するには、show process コマンドを発行します。

RP/0/RP1/CPU0:CWDCRS#show processes
JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
1      1       0K  0  Ready       320:04:04:0649 procnto-600-smp-cisco-instr
1      3       0K  10 Nanosleep     0:00:00:0043 procnto-600-smp-cisco-instr
1      5       0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      7       0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      8       0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      11      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      12      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      13      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      14      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      15      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      16      0K  10 Receive       0:02:01:0207 procnto-600-smp-cisco-instr
1      17      0K  10 Receive       0:00:00:0015 procnto-600-smp-cisco-instr
1      21      0K  10 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      23      0K  10 Running       0:07:34:0799 procnto-600-smp-cisco-instr
1      26      0K  10 Receive       0:00:00:0001 procnto-600-smp-cisco-instr
1      31      0K  10 Receive       0:00:00:0001 procnto-600-smp-cisco-instr
1      33      0K  10 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      39      0K  10 Receive       0:13:36:0166 procnto-600-smp-cisco-instr
1      46      0K  10 Receive       0:06:32:0015 procnto-600-smp-cisco-instr
1      47      0K  56 Receive       0:00:00:0029 procnto-600-smp-cisco-instr
1      48      0K  10 Receive       0:00:00:0001 procnto-600-smp-cisco-instr
1      72      0K  10 Receive       0:00:00:0691 procnto-600-smp-cisco-instr
1      73      0K  10 Receive       0:00:00:0016 procnto-600-smp-cisco-instr
1      78      0K  10 Receive       0:09:18:0334 procnto-600-smp-cisco-instr
1      91      0K  10 Receive       0:09:42:0972 procnto-600-smp-cisco-instr
1      95      0K  10 Receive       0:00:00:0011 procnto-600-smp-cisco-instr
1      103     0K  10 Receive       0:00:00:0008 procnto-600-smp-cisco-instr
74     1       8K  63 Nanosleep     0:00:00:0001 wd-mbi
53     1      28K  10 Receive       0:00:08:0904 dllmgr
53     2      28K  10 Nanosleep     0:00:00:0155 dllmgr
53     3      28K  10 Receive       0:00:03:0026 dllmgr
53     4      28K  10 Receive       0:00:09:0066 dllmgr
53     5      28K  10 Receive       0:00:01:0199 dllmgr
270    1      36K  10 Receive       0:00:36:0091 qsm
270    2      36K  10 Receive       0:00:13:0533 qsm
270    5      36K  10 Receive       0:01:01:0619 qsm
270    7      36K  10 Nanosleep     0:00:22:0439 qsm
270    8      36K  10 Receive       0:00:32:0577 qsm
67     1      52K  19 Receive       0:00:35:0047 pkgfs
67     2      52K  10 Sigwaitinfo   0:00:00:0000 pkgfs
67     3      52K  19 Receive       0:00:30:0526 pkgfs
67     4      52K  10 Receive       0:00:30:0161 pkgfs
67     5      52K  10 Receive       0:00:25:0976 pkgfs
68     1       8K  10 Receive       0:00:00:0003 devc-pty
52     1      40K  16 Receive       0:00:00:0844 devc-conaux
52     2      40K  16 Sigwaitinfo   0:00:00:0000 devc-conaux
52     3      40K  16 Receive       0:00:02:0981 devc-conaux
52     4      40K  16 Sigwaitinfo   0:00:00:0000 devc-conaux
52     5      40K  21 Receive       0:00:03:0159 devc-conaux
65545  2      24K  10 Receive       0:00:00:0487 pkgfs
65546  1      12K  16 Reply         0:00:00:0008 ksh
66     1       8K  10 Sigwaitinfo   0:00:00:0005 pipe
66     3       8K  10 Receive       0:00:00:0000 pipe
66     4       8K  16 Receive       0:00:00:0059 pipe
66     5       8K  10 Receive       0:00:00:0149 pipe
66     6       8K  10 Receive       0:00:00:0136 pipe
71     1      16K  10 Receive       0:00:09:0250 shmwin_svr
71     2      16K  10 Receive       0:00:09:0940 shmwin_svr
61     1       8K  10 Receive       0:00:00:0006 mqueue

ブロックされたプロセスとプロセスの状態

ブロックされた状態にあるプロセスを表示するには、show process blocked コマンドを発行します。

RP/0/RP1/CPU0:CWDCRS#show processes blocked
  Jid       Pid Tid                 Name State  Blocked-on
65546      4106   1                  ksh Reply    4104  devc-conaux
  105     61495   2              attachd Reply   24597  eth_server
  105     61495   3              attachd Reply    8205  mqueue
  316     65606   1          tftp_server Reply    8205  mqueue
  233     90269   2              lpts_fm Reply   90223  lpts_pa
  325    110790   1            udp_snmpd Reply   90257  udp
  253    110797   4               ospfv3 Reply   90254  raw_ip
  337    245977   2               fdiagd Reply   24597  eth_server
  337    245977   3               fdiagd Reply    8205  mqueue
65762   5996770   1                 exec Reply       1  kernel
65774   6029550   1                 more Reply    8203  pipe
65778   6029554   1       show_processes Reply       1  kernel
RP/0/RP1/CPU0:CWDCRS#

同期メッセージ パッシングでは、異なるスレッド間でのプロセス間通信のライフ サイクルが簡単に追跡できます。スレッドは、いつの時点においても何らかの状態にあります。ブロックされた状態は、問題の症状を示している可能性があります。スレッドがブロックされた状態であっても必ずしも問題が発生しているわけではないので、show process blocked コマンドを発行する必要も、Cisco テクニカルサポートでサービスリクエストをオープンする必要もありません。ブロックされたスレッドはきわめて正常な状態です。

前述の出力に注目してください。リストの最初のスレッドに注目して、そのスレッドが ksh であり、応答が devc-conaux でブロックされていることに注意してください。クライアント（この場合は ksh）では devc-conaux プロセスにメッセージが送信され、サーバ（この場合は devc-conaux）では応答が行われるまで、ksh 応答がブロックされます。ksh はコンソールや AUX ポートで使用される UNIX シェルです。ksh ではコンソールからの入力が待機されますが、オペレータが入力を行わないためにコンソールからの入力が発生しない場合、ksh では何らかの入力が処理される時点までブロックされた状態が続きます。処理が行われたら、ksh は devc-conaux でブロックされた応答に戻ります。

これは正常な状態であり、問題を示しているわけではありません。ポイントは、ブロックされたスレッドは正常であり、その判断は XR のバージョン、使用するシステムの種類、設定した内容と show process blocked コマンドの出力をだれがどのように変更しているのかによって異なる点にあります。show process blocked コマンドの使用は、OS に関連した問題に対するトラブルシューティングを開始するためには優れた方法です。たとえば CPU の使用率が高いなどの問題が発生する場合は、正常値から外れている項目を表示するためにこのコマンドを使用します。

機能しているルータにとってはどのような状態が正常なのかを理解してください。これにより、プロセスのライフサイクルにトラブルシューティングを行う場合に、比較を行うためのベースラインが提供されます。

スレッドは、いつの時点においても何らかの状態にあります。次の表に、状態の一覧を示します。

状態 意味
DEAD ダウン状態です。カーネルではスレッドのリソースの解放を待機中です。
実行中 CPU 上でアクティブに実行中です。
READY CPU 上で実行中ではありませんが、実行の用意が整っています。
STOPPED 一時停止中（SIGSTOP シグナル）です。
SEND サーバでメッセージが受信されるのを待機中です。
受信 クライアントでメッセージが送信されるのを待機中です。
REPLY サーバからメッセージが応答されるのを待機中です。
STACK スタックがさらに割り当てられるのを待機中です。
WAITPAGE プロセス マネージャによってページ フォールトが解決されるのを待機中です。
SIGSUSPEND シグナルを待機中です。
SIGWAITINFO シグナルを待機中です。
NANOSLEEP 一定時間スリープ状態です。
MUTEX MUTEX の取得を待機中です。
CONDVAR 条件変数にシグナルが送られるのを待機中です。
加入 別のスレッドの終了を待機中です。
INTR 割り込みを待機中です。
SEM セマフォの取得を待機中です。

重要なプロセスとその機能

Cisco IOS XR には多くのプロセスがあります。次に、重要なプロセスの一部とその機能を説明します。

ウォッチドッグ システム モニタ（WDSysmon）

これは、プロセスのハングと使用可能メモリ低下の状況を検出するために提供されるサービスです。使用可能メモリの低下は、メモリ リークやその他の外来的な状況の結果として発生する可能性があります。ハングは、プロセス デッドロック、無限ループ、カーネル ロックアップ、スケジューリング エラーなど、さまざまな状況の結果として発生する可能性があります。マルチ スレッドの環境では、システムがデッドロック状態または単にデッドロックと呼ばれる状態になる可能性があります。デッドロックが発生する可能性があるのは、リソース コンテンションのために 1 つ以上のスレッドが処理を継続できない場合です。たとえば、スレッドAはスレッドBにメッセージを送信し、同時にスレッドBはスレッドAにメッセージを送信できます。両方のスレッドは互いに待機し、ブロック状態になり、両方のスレッドは永続的に待機します。これは 2 つのスレッドが関与する単純な状況ですが、多くのスレッドが使用するリソースをサーバが処理していて、別のスレッドでそのリソースがブロックされている場合、そのリソースへのアクセスを要求する多くのスレッドはサーバ上で送信がブロックされた待機状態となる可能性があります。

デッドロックは少数のスレッド間で発生する可能性があるものですが、結果として他のスレッドに影響を与える可能性があります。デッドロックは優れたプログラム設計により回避されるものですが、プログラムの設計と記述の適切さの程度には関係しません。場合によっては、特定のタイミングでのデータに依存するイベントの特定のシーケンスによりデッドロックが引き起こされる可能性があります。デッドロックは常に確定的に発生するわけではないので、通常、再現することが非常に困難です。WDSysmonには、Neutrinoがサポートする最高の優先順位で実行されるスレッドが多数あります。優先順位63で実行すると、優先順位ベースのプリエンプティブスケジューリング環境でスレッドがCPU時間を取得できます。WDSysmon はハードウェア ウオッチドッグ機能を使用して動作し、ハング状況を検出するソフトウェア プロセスを監視します。このような状況が検出されると、WDSysmon では状況に関する詳細情報が収集され、プロセスやカーネルのコアダンプ生成、syslog への書き込み、スクリプトの実行、デッドロックされたプロセスの削除が実行されます。問題の程度によっては、システムの動作を維持するためにルート プロセッサのスイッチオーバーを開始することができます。

RP/0/RP1/CPU0:CWDCRS#show processes wdsysmon
                  Job Id: 331
                     PID: 36908
         Executable path: /disk0/hfr-base-3.2.3/sbin/wdsysmon
              Instance #: 1
              Version ID: 00.00.0000
                 Respawn: ON
           Respawn count: 1
  Max. spawns per minute: 12
            Last started: Tue Jul 18 13:07:36 2006
           Process state: Run
           Package state: Normal
                    core: SPARSE
               Max. core: 0
                   Level: 40
               Mandatory: ON
            startup_path: /pkg/startup/wdsysmon.startup
            memory limit: 10240
                   Ready: 0.705s
        Process cpu time: 4988.295 user, 991.503 kernel, 5979.798 total

JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
331    1      84K  19 Receive       0:00:00:0029 wdsysmon
331    2      84K  10 Receive       0:17:34:0212 wdsysmon
331    3      84K  10 Receive       0:00:00:0110 wdsysmon
331    4      84K  10 Receive       1:05:26:0803 wdsysmon
331    5      84K  19 Receive       0:00:06:0722 wdsysmon
331    6      84K  10 Receive       0:00:00:0110 wdsysmon
331    7      84K  63 Receive       0:00:00:0002 wdsysmon
331    8      84K  11 Receive       0:00:00:0305 wdsysmon
331    9      84K  20 Sem           0:00:00:0000 wdsysmon

プロセス WDSysmon には 9 つのスレッドがあります。優先度10で4回、他の4回は11、19、20、および63です。プロセスが設計されると、プログラマはプロセス内の各スレッドに与える優先度を慎重に考慮します。すでに説明したとおり、スケジューラは優先順位に基づいているので、より高い優先順位のスレッドが低い優先順位のスレッドよりも常に優先されます。優先順位 63 はスレッドが実行可能な最高の優先順位であり、この場合ではスレッド 7 が該当します。スレッド 7 は CPU ホグを追跡する監視スレッドです。このスレッドはその監視対象である他のスレッドよりも高い優先順位で実行される必要がありますが、そうでない場合には実行の機会がまったく失われ、実行が意図された手順に従うことができなくなります。

Netio

Cisco IOS には、ファースト スイッチングとプロセス スイッチングのコンセプトが存在します。ファースト スイッチングは CEF コードを使用し、割り込み時に発生します。プロセス スイッチングは IP スイッチング コードである ip_input を使用する、スケジュールされたプロセスです。より高性能なプラットフォームでは、CEF スイッチングがハードウェアで実行され、ip_input は CPU でスケジュールされます。Cisco IOS XR では、Netio が ip_input に相当します。 

P/0/RP1/CPU0:CWDCRS#show processes netio
                  Job Id: 241
                     PID: 65602
         Executable path: /disk0/hfr-base-3.2.3/sbin/netio
              Instance #: 1
                    Args: d
              Version ID: 00.00.0000
                 Respawn: ON
           Respawn count: 1
  Max. spawns per minute: 12
            Last started: Tue Jul 18 13:07:53 2006
           Process state: Run
           Package state: Normal
                    core: DUMPFALLBACK COPY SPARSE
               Max. core: 0
                   Level: 56
               Mandatory: ON
            startup_path: /pkg/startup/netio.startup
                   Ready: 17.094s
        Process cpu time: 188.659 user, 5.436 kernel, 194.095 total
JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
241    1     152K  10 Receive       0:00:13:0757 netio
241    2     152K  10 Receive       0:00:10:0756 netio
241    3     152K  10 Condvar       0:00:08:0094 netio
241    4     152K  10 Receive       0:00:22:0016 netio
241    5     152K  10 Receive       0:00:00:0001 netio
241    6     152K  10 Receive       0:00:04:0920 netio
241    7     152K  10 Receive       0:00:03:0507 netio
241    8     152K  10 Receive       0:00:02:0139 netio
241    9     152K  10 Receive       0:01:44:0654 netio
241    10    152K  10 Receive       0:00:00:0310 netio
241    11    152K  10 Receive       0:00:13:0241 netio
241    12    152K  10 Receive       0:00:05:0258 netio

Group Services Process（GSP）

それぞれ独自のカーネル インスタンスが実行される数千のノードを持つどのスーパーコンピュータでも、通信に対するニーズが存在します。インターネットでは、1 対多の通信がマルチキャスト プロトコルを介して効率的に実行されます。GSPは、CRS-1内のIPCに使用される内部マルチキャストプロトコルです。GSPは、1対多の信頼性の高いグループ通信を提供し、非同期セマンティクスでコネクションレス化します。これによって、GSP は何千ものノードへと規模を拡大できます。

RP/0/RP1/CPU0:CWDCRS#show processes gsp
                  Job Id: 171
                     PID: 65604
         Executable path: /disk0/hfr-base-3.2.3/bin/gsp
              Instance #: 1
              Version ID: 00.00.0000
                 Respawn: ON
           Respawn count: 1
  Max. spawns per minute: 12
            Last started: Tue Jul 18 13:07:53 2006
           Process state: Run
           Package state: Normal
                    core: TEXT SHAREDMEM MAINMEM
               Max. core: 0
                   Level: 80
               Mandatory: ON
            startup_path: /pkg/startup/gsp-rp.startup
                   Ready: 5.259s
               Available: 16.613s
        Process cpu time: 988.265 user, 0.792 kernel, 989.057 total
JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
171    1     152K  30 Receive       0:00:51:0815 gsp
171    3     152K  10 Condvar       0:00:00:0025 gsp
171    4     152K  10 Receive       0:00:08:0594 gsp
171    5     152K  10 Condvar       0:01:33:0274 gsp
171    6     152K  10 Condvar       0:00:55:0051 gsp
171    7     152K  10 Receive       0:02:24:0894 gsp
171    8     152K  10 Receive       0:00:09:0561 gsp
171    9     152K  10 Condvar       0:02:33:0815 gsp
171    10    152K  10 Condvar       0:02:20:0794 gsp
171    11    152K  10 Condvar       0:02:27:0880 gsp
171    12    152K  30 Receive       0:00:46:0276 gsp
171    13    152K  30 Receive       0:00:45:0727 gsp
171    14    152K  30 Receive       0:00:49:0596 gsp
171    15    152K  30 Receive       0:00:38:0276 gsp
171    16    152K  10 Receive       0:00:02:0774 gsp

BCDL バルク コンテンツ ダウンローダ

RP や MSC など、さまざまなノードへ確実にデータをマルチキャストするには、BCDL が使用されます。BCDL では、基本の転送として GSP が使用されます。BCDL によってメッセージの順序を追った配信が保証されます。BCDL 内部には、エージェント、プロデュサ、およびコンシューマが存在します。エージェントは、コンシューマへマルチキャストする前にデータを取得してバッファするために、プロデューサと通信するプロセスです。プロデューサは全員が必要とするデータを制作するプロセスで、コンシューマはプロデューサによって提供されるデータを受け取ることに関与するプロセスです。BCDL は Cisco IOS XR ソフトウェアのアップグレード中に使用されます。

Lightweight Messaging（LWM）

LWM は Cisco が作成したメッセージングの形式で、オペレーティング システムやトランスポート層との非依存性を目的として、Neutrino との間および相互間でのプロセス間通信を行うアプリケーション間に抽象化層を作成する設計になっています。Cisco が OS ベンダーを QNX から他社へ変更する場合、基礎となるオペレーティング システムの基本機能間の抽象化層がオペレーティング システムへの依存を解消するのに役立ち、他のオペレーティング システムへのポーティングの手助けとなります。LWM では同期が保証されたメッセージ配信が提供されますが、これはネイティブの Neutrino メッセージ パッシングと同様、受信者が応答するまで送信者がブロックする原因となります。

また、LWM では 40 ビット パルスでの非同期のメッセージ配信も提供されます。非同期メッセージは非同期で送信されますが、これはメッセージがキューイングされて送信者でのブロックが発生しないことを意味します。ただし、サーバから次に使用できるメッセージのポーリングが行われる場合には、サーバではメッセージが非同期には受信されないことになります。LWM はクライアント/サーバとして構造化されています。サーバは、メッセージを傍受する耳を提供するチャネルを作成し、この作成したばかりのチャンネルでループによるメッセージ受信のリスニングが実行されている間は待機します。メッセージが受信されると、ブロックが解除されてクライアント識別子が取得されますが、これは事実上、受信されたメッセージからの受信 ID と同じものです。次に、サーバによって一部の処理が実行され、後でクライアント識別子へのメッセージ応答が行われます。

クライアント側では、メッセージ接続が行われます。接続先へ識別子を通過させてからメッセージ送信が行われて、ブロックされます。サーバでの処理が終了すると、応答が行われ、クライアントのブロックが解除されます。事実上、これは Neutrino のネイティブ メッセージ パッシングと同じなので、抽象化層は非常に薄いものになります。

LWM は高度なパフォーマンスを目的とした最小限のシステム コールとコンテキスト スイッチを使用した設計であり、Cisco IOS XR 環境では IPC の優先方式です。

envmon

最も基礎的なレベルでは、環境モニタリング システムは物理的なパラメータ（温度、電圧、ファン速度など）が動作範囲から外れる場合に警告を行い、ハードウェアが破損する可能性がある臨界値に近づいているハードウェアをシャットダウンする役割を担っています。環境モニタリング システムは、このタスクを実行するために、使用できる各ハードウェア センサーを定期的に監視し、測定された値をカード固有のしきい値と比較して、必要に応じて警告を行います。システムの初期化において開始された、定期的にシャーシ内のすべてのハードウェア センサー（電圧、温度、ファン速度など）にポーリングを行う永続的なプロセスによって、このデータは外部の管理クライアントに提供されます。また、この定期的なプロセスではセンサーの値を警告のしきい値と比較し、フォールト マネージャによる後続の処理のために、環境に関する警告をシステム データベースへ発行します。センサーの値が危険なほど範囲から外れている場合は、環境モニタリング プロセスによってカードがシャット ダウンされることがあります。

CRS-1 ファブリックの概要

  • マルチステージファブリック：3ステージベントポロジ

  • 輻輳を最小化するファブリック内部でのダイナミック ルーティング

  • セルベース：136バイトセル、120バイトデータペイロード

  • トラフィックの分離を改善し、ファブリック内のバッファリング要件を最小化するフロー制御

  • ステージからステージへのスピードアップ配信

  • 2つのトラフィックキャストをサポート（ユニキャストおよびマルチキャスト）

  • キャストあたり 2 つのトラフィック優先順位のサポート（高い優先順位と低い優先順位）

  • 1M ファブリック マルチキャスト グループのサポート（FGID）

  • コスト効率の高い耐障害性：1+1ではなくファブリックプレーンを使用したN+1またはN+kの冗長性を大幅にコストを増加

単一シャーシ モードで稼働している場合は、S1、S2、および S3 の各 ASIC は同じファブリック カードに配置されます。また、一般的に、このカードは S123 カードとも呼ばれます。マルチシャーシ構成の場合は、S2 が分離され、Fabric Card Chassis（FCC; ファブリック カード シャーシ）に配置されます。 この設定では、プレーンを構成するために 2 枚のファブリック カード（S2 カードおよび S13 カード）が必要です。各 MSC は、冗長性を提供するために 8 つのファブリック プレーンに接続されるので、1 つ以上のプレーンが失われた場合でもトラフィックはファブリックを通過しますが、ファブリックを通過できる集約トラフィックは少なくなります。CRS は、7 つのプレーンだけを使用しても、大部分のパケット サイズに対して回線レートで動作を続けることができます。バックプレッシャは奇数と偶数のプレーンを介してファブリックに送信されます。奇数および偶数のプレーンの 2 つのプレーンよりも少ない装備しかないシステムを稼働することは推奨されません。2 つ未満のプレーンの設定はサポートされない設定です。

ファブリック プレーン

crs-ios-xr-bp1.gif

上のダイアグラムは、1 つのプレーンを表しています。このダイアグラムを 8 倍する必要があります。これは、LC のスプレイヤ（ingressq）ASIC が 8 つの S1（プレーンあたり 1 つの S1）に接続されることを意味します。 各ファブリック プレーンの S1 は、8 つのスプレイヤに接続されます。

  • シャーシの上位 8 つの LC

  • 下位 8 つの LC

16スロットのLCシャーシごとに16のS1があります。上のLCの場合は8（プレーンごとに1つ）、下のLCの場合は8です。

単一の 16 スロット シャーシでは、S123 ファブリック カードが 2 つの S1、2 つの S2、および 4 つの S3 が備わっています。これはファブリックのスピードアップ計算の一部です。トラフィックが入る際にファブリックを終了させる可能性がある、2 倍のトラフィックが存在します。1 スプレイヤと比較すると、現在、LC あたり 2 つのスポンジ（fabricq）も存在します。これにより、複数の入力 LC によって出力 LC が過負荷になる場合に、出力 LC でのバッファリングが可能になります。出力 LC では、ファブリックからのこの追加帯域幅を吸収できます。

ファブリック モニタリング

プレーンの可用性と接続性：

admin show controller fabric plane all
admin show controller fabric connectivity all detail

プレーンがセルを送受信しているかどうか、また、一部のエラーが増加しているかどうかを確認します。

admin show controllers fabric plane all statistics

前述のコマンドの略語を次に示します。

  • CE：修正可能なエラー

  • UCE:Uncorrectableエラー

  • PE：パリティエラー

ブートアップ時にはいくつかエラーが発生する可能性があるため、それらが検出されても気にする必要はありません。これらのフィールドは実行時には増加しないはずです。これらのフィールドが増加している場合、ファブリック内の問題を示している可能性があります。ファブリック プレーンごとのエラー詳細を取得するには、次のコマンドを発行します。 

admin show controllers fabric plane <0-7> statistics detail

コントロール プレーンの概要

現在、ラインカード シャーシおよびファブリック シャーシの間のコントロール プレーンの接続は、RP（LCC）および SCGE（FCC）上のギガビット イーサネット ポートを経由しています。 ポート間の相互接続は、2 つ以上のギガビット イーサネット ポートを介して接続が可能な Catalyst 6500 スイッチのペアを経由して提供されます。

crs-ios-xr-bp2.gif

Catalyst 6500 の設定

マルチシャーシ コントロール プレーンに使用される Catalyst スイッチに推奨される設定を次に示します。

  • すべてのポートで単一の VLAN が使用される。

  • すべてのポートがアクセス モードで実行される（トランキングなし）。

  • ループ防止用にスパニング ツリー 802.1w/s が使用される。

  • 2 つのスイッチを相互接続するために 2 つ以上のリンクが使用され、ループ防止用に STP が使用される。チャネリングは推奨されません。

  • IOS-XR では標準ベースの 802.1s がサポートされないので、CRS-1 RP および SCGE に接続するポートでは先行標準モードが使用される。

  • スイッチ間およびスイッチと RP/SCGE の間で接続するポート上では、UDLD を有効にする必要がある。

  • CRS-1 ではデフォルトで UDLD が有効である。

マルチシェルフ システムで Catalyst 6500 を設定する方法については、『マルチシェルフ システムでの Cisco IOS XR ソフトウェアの始動』を参照してください。

マルチシャーシ コントロール プレーンの管理

マルチシャーシ システムのコントロール プレーン接続を提供する Catalyst 6504-E シャーシは、下記の管理サービス用に設定されます。

  • 各 PoP で LAN スイッチに接続する、ポート ギガビット 1/2 を介したインバンド管理。狭い範囲のサブネットとプロトコルにだけアクセスが許可されます。

  • システムの時刻を設定するために NTP が使用される。

  • 標準ホストへの syslog が実行される。

  • 不可欠な機能用に SNMP ポーリングとトラップを有効にできる。

注：動作中のCatalystに変更を加える必要はありません。計画済みの変更には事前テストを行う必要がありますが、このテストはメンテナンスの時間帯に行うことを強く推奨いたします。

次に管理設定の例を示します。

#In-band management connectivity
interface GigabitEthernet2/1
 description *CRS Multi-chassis Management Ethernet - DO NOT TOUCH*
 ip address [ip address] [netmask]
 ip access-group control_only in
!
!
ip access-list extended control_only
 permit udp [ip address] [netmask] any eq snmp
 permit udp [ip address] [netmask] eq ntp any
 permit tcp [ip address] [netmask] any eq telnet

#NTP 

ntp update-calendar
ntp server [ip address]

#Syslog
logging source-interface Loopback0
logging [ip address]
logging buffered 4096000 debugging
no logging console

#RADIUS
aaa new-model
aaa authentication login default radius enable
enable password {password}
radius-server host [ip address] auth-port 1645 acct-port 1646
radius-server key {key}

#Telnet and console access
!
access-list 3 permit [ip address]
!
line con 0
 exec-timeout 30 0
 password {password}
line vty 0 4
 access-class 3 in
 exec-timeout 0 0
password {password}

ROMMON および Monlib

Cisco monlib は実行可能プログラムであり、デバイスに格納されていて、実行には ROMMON により RAM にロードされます。ROMMON では、デバイス上のファイルへのアクセスに monlib が使用されます。ROMMON のバージョンはアップグレード可能ですが、アップグレードは Cisco テクニカルサポートの推奨に基づいて行う必要があります。最新の ROMMON バージョンは 1.40 です。

アップグレードの手順

次のステップを実行します。

  1. ROMMON バイナリを Cisco CRS-1 ROMMON（登録ユーザ専用）からダウンロードします。

  2. TAR ファイルを展開し、6 つの BIN ファイルを Disk0 の CRS ルート ディレクトリにコピーします。

    RP/0/RP0/Router#dir disk0:/*.bin

Directory of disk0:

65920       -rwx  360464      Fri Oct 28 12:58:02 2005  rommon-hfr-ppc7450-sc-dsmp-A.bin
66112       -rwx  360464      Fri Oct 28 12:58:03 2005  rommon-hfr-ppc7450-sc-dsmp-B.bin
66240       -rwx  376848      Fri Oct 28 12:58:05 2005  rommon-hfr-ppc7455-asmp-A.bin
66368       -rwx  376848      Fri Oct 28 12:58:06 2005  rommon-hfr-ppc7455-asmp-B.bin
66976       -rwx  253904      Fri Oct 28 12:58:08 2005  rommon-hfr-ppc8255-sp-A.bin
67104       -rwx  253492      Fri Oct 28 12:58:08 2005  rommon-hfr-ppc8255-sp-B.bin

  3. show diagコマンドを使用します | inc ROM|NODE|PLIMコマンドを発行して、現在のrommonバージョンを表示します。

    RP/0/RP0/CPU0:ROUTER(admin)#show diag | inc ROM|NODE|PLIM
NODE 0/0/SP : MSC(SP)
  ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
PLIM 0/0/CPU0 : 4OC192-POS/DPT
  ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
NODE 0/2/SP : MSC(SP)
  ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
PLIM 0/2/CPU0 : 8-10GbE
  ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
NODE 0/4/SP : Unknown Card Type
NODE 0/6/SP : MSC(SP)
  ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
PLIM 0/6/CPU0 : 16OC48-POS/DPT
  ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
NODE 0/RP0/CPU0 : RP
  ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
NODE 0/RP1/CPU0 : RP
  ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
NODE 0/SM0/SP : FC/S
  ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
NODE 0/SM1/SP : FC/S
  ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
NODE 0/SM2/SP : FC/S
  ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
NODE 0/SM3/SP : FC/S
ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]

  4. ROMMON をアップグレードするには、ADMIN モードに切り替えて upgrade rommon a all disk0 コマンドを使用します。

    RP/0/RP0/CPU0:ROUTER#admin
RP/0/RP0/CPU0:ROUTER(admin)#upgrade rommon a all disk0 
Please do not power cycle, reload the router or reset any nodes until
 all upgrades are completed.
Please check the syslog to make sure that all nodes are upgraded successfully.
If you need to perform multiple upgrades, please wait for current upgrade
 to be completed before proceeding to another upgrade.
Failure to do so may render the cards under upgrade to be unusable.

  5. ADMINモードを終了し、show logを入力します。 | inc 「OK, ROMMON A」と入力し、すべてのノードが正常にアップグレードされたことを確認します。正常にアップグレードされていないノードがある場合は、手順 4 に戻って再プログラムします。

    RP/0/RP0/CPU0:ROUTER#show logging | inc "OK, ROMMON A"
RP/0/RP0/CPU0:Oct 28 14:40:57.223 PST8: upgrade_daemon[380][360]: OK,  ROMMON A is programmed successfully. 
SP/0/0/SP:Oct 28 14:40:58.249 PST8: upgrade_daemon[125][121]: OK,  ROMMON A is programmed successfully. 
SP/0/2/SP:Oct 28 14:40:58.251 PST8: upgrade_daemon[125][121]: OK,  ROMMON A is programmed successfully. 
LC/0/6/CPU0:Oct 28 14:40:58.336 PST8: upgrade_daemon[244][233]: OK,  ROMMON A is programmed successfully. 
LC/0/2/CPU0:Oct 28 14:40:58.365 PST8: upgrade_daemon[244][233]: OK,  ROMMON A is programmed successfully. 
SP/0/SM0/SP:Oct 28 14:40:58.439 PST8: upgrade_daemon[125][121]: OK,  ROMMON A is programmed successfully. 
SP/0/SM1/SP:Oct 28 14:40:58.524 PST8: upgrade_daemon[125][121]: OK,  ROMMON A is programmed successfully. 
LC/0/0/CPU0:Oct 28 14:40:58.530 PST8: upgrade_daemon[244][233]: OK,  ROMMON A is programmed successfully. 
RP/0/RP1/CPU0:Oct 28 14:40:58.593 PST8: upgrade_daemon[380][360]: OK,  ROMMON A is programmed successfully. 
SP/0/6/SP:Oct 28 14:40:58.822 PST8: upgrade_daemon[125][121]: OK,  ROMMON A is programmed successfully. 
SP/0/SM2/SP:Oct 28 14:40:58.890 PST8: upgrade_daemon[125][121]: OK,  ROMMON A is programmed successfully. 
SP/0/SM3/SP:Oct 28 14:40:59.519 PST8: upgrade_daemon[125][121]: OK,  ROMMON A is programmed successfully.

  6. ROMMON をアップグレードするには、ADMIN モードに切り替えて upgrade rommon b all disk0 コマンドを使用します。

    RP/0/RP0/CPU0:ROUTER#admin
RP/0/RP0/CPU0:ROUTER(admin)#upgrade rommon b all disk0 
Please do not power cycle, reload the router or reset any nodes until
 all upgrades are completed.
Please check the syslog to make sure that all nodes are upgraded successfully.
If you need to perform multiple upgrades, please wait for current upgrade
 to be completed before proceeding to another upgrade.
Failure to do so may render the cards under upgrade to be unusable.

  7. ADMINモードを終了し、show logを入力します。 | inc 「OK, ROMMON B」をクリックし、すべてのノードが正常にアップグレードされたことを確認します。正常にアップグレードされていないノードがある場合は、手順 4 に戻って再プログラムします。

    RP/0/RP0/CPU0:Router#show logging | inc "OK, ROMMON B"  
RP/0/RP0/CPU0:Oct 28 13:27:00.783 PST8: upgrade_daemon[380][360]: OK, 
ROMMON B is programmed successfully. 
LC/0/6/CPU0:Oct 28 13:27:01.720 PST8: upgrade_daemon[244][233]: OK, 
ROMMON B is programmed successfully. 
SP/0/2/SP:Oct 28 13:27:01.755 PST8: upgrade_daemon[125][121]: OK, 
ROMMON B is programmed successfully. 
LC/0/2/CPU0:Oct 28 13:27:01.775 PST8: upgrade_daemon[244][233]: OK, 
ROMMON B is programmed successfully. 
SP/0/0/SP:Oct 28 13:27:01.792 PST8: upgrade_daemon[125][121]: OK, 
ROMMON B is programmed successfully. 
SP/0/SM0/SP:Oct 28 13:27:01.955 PST8: upgrade_daemon[125][121]: OK, 
ROMMON B is programmed successfully. 
LC/0/0/CPU0:Oct 28 13:27:01.975 PST8: upgrade_daemon[244][233]: OK, 
ROMMON B is programmed successfully. 
SP/0/6/SP:Oct 28 13:27:01.989 PST8: upgrade_daemon[125][121]: OK, 
ROMMON B is programmed successfully. 
SP/0/SM1/SP:Oct 28 13:27:02.087 PST8: upgrade_daemon[125][121]: OK, 
ROMMON B is programmed successfully. 
RP/0/RP1/CPU0:Oct 28 13:27:02.106 PST8: upgrade_daemon[380][360]: OK, 
ROMMON B is programmed successfully. 
SP/0/SM3/SP:Oct 28 13:27:02.695 PST8: upgrade_daemon[125][121]: OK, 
ROMMON B is programmed successfully. 
SP/0/SM2/SP:Oct 28 13:27:02.821 PST8: upgrade_daemon[125][121]: OK, 
ROMMON B is programmed successfully.

  8. upgrade コマンドでは、ブートフラッシュの特殊な予約済みセクションに新しい ROMMON が焼き付けられるだけです。、新しい ROMMON は、カードがリロードされるまで非アクティブのままです。したがって、ユーザがカードをリロードすると、新しい ROMMON がアクティブになります。一度に 1 つずつ各ノードをリセットするか、ルータ全体をリセットするだけで、これが実行されます。

    Reload Router:
RP/0/RP0/CPU0:ROUTER#hw-module node 0/RP0/CPU0 or 0/RP1/CPU0 reload (depends on which on is in Standby Mode.
RP/0/RP0/CPU0:ROUTER#reload  

!--- Issue right after the first command.

Updating Commit Database.  Please wait...[OK]
Proceed with reload? [confirm]


!--- Reload each Node. For Fan Controllers (FCx), !--- Alarm Modules (AMx), Fabric Cards (SMx), and RPs (RPx), !--- you must wait until the reloaded node is fully reloaded !--- before you reset the next node of the pair. But non-pairs !--- can be reloaded without waiting.

RP/0/RP0/CPU0:ROUTER#hw-module node 0/RP0/CPU0 or 0/RP1/CPU0 reload 

!--- This depends on which on is in Standby Mode.

RP/0/RP0/CPU0:ROUTER#hw-module node 0/FC0/SP
RP/0/RP0/CPU0:ROUTER#hw-module node 0/AM0/SP
RP/0/RP0/CPU0:ROUTER#hw-module node 0/SM0/SP

!--- Do not reset the MSC and Fabric Cards at the same time.

RP/0/RP0/CPU0:ROUTER#hw-module node 0/0/CPU

  9. show diagコマンドを使用します | inc ROM|NODE|PLIMコマンドを発行し、現在のROMMONバージョンを確認します。

    RP/0/RP1/CPU0:CRS-B(admin)#show diag | inc ROM|NODE|PLIM
NODE 0/0/SP : MSC(SP)
  ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
PLIM 0/0/CPU0 : 4OC192-POS/DPT
  ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]
NODE 0/2/SP : MSC(SP)
  ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
PLIM 0/2/CPU0 : 8-10GbE
  ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]
NODE 0/6/SP : MSC(SP)
  ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
PLIM 0/6/CPU0 : 16OC48-POS/DPT
  ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]
NODE 0/RP0/CPU0 : RP
  ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]
NODE 0/RP1/CPU0 : RP
  ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]]
NODE 0/SM0/SP : FC/S
  ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
NODE 0/SM1/SP : FC/S
  ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
NODE 0/SM2/SP : FC/S
  ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
NODE 0/SM3/SP : FC/S
  ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]

    注：CRS-8およびファブリックシャーシでは、ROMMONによってファン速度もデフォルトの4000 RPMに設定されます。

PLIM および MSC の概要

次に CRS-1 ルータでのパケット フローを紹介しますが、下記の用語は特に区別なく使用されています。

IngressQ ASIC は、Sprayer ASIC とも呼ばれます。

FabricQ ASIC は、Sponge ASIC とも呼ばれます。

EgressQ ASIC は、Sharq ASIC とも呼ばれます。

SPP は Packet Switch Engine（PSE; パケット交換エンジン）ASIC とも呼ばれます。

Rx PLIM > Rx SPP > Ingress Q > Fabric > Fabric Q > Tx SPP > Egress Q > Tx PLIM (Spplyer) (Sharq)

crs-ios-xr-bp3.gif

パケットは Physical Layer Interface Module（PLIM; 物理レイヤ インターフェイス モジュール）で受信されます。

PLIM には、PLIM が接続する MSC の物理インターフェイスがあります。PLIM と MSC は、シャーシ バックプレーンを介して接続された別々のカードです。結果として、特定の MSC のインターフェイスの種類は、その MSC が接続する PLIM の種類によって定義されます。PLIM の種類に従って、カードにはインターフェイスの物理メディアとフレーム同期を提供するさまざまな ASIC がたくさん含まれます。PLIM ASIC の目的は、MSC と物理接続の間にインターフェイスを提供することです。PLIM では、光ファイバの終端処理、光電気変換の実行、SDH/Sonet/イーサネット/HDLC/PPP などでのメディア フレーム同期の終端、CRC のチェック、バッファ ヘッダーと呼ばれる制御情報の追加、および残りのビットの MSC への転送が実行されます。PLIM では、HDLC または PPP のキープアライブのソースとシンクは実行されません。これらは MSC の CPU で処理されます。

PLIM では、次の機能も提供されます。

  • 1/10 ギガビット イーサネットの MAC フィルタリング

  • 1/10 ギガビット イーサネットの入力/出力 MAC アカウンティング

  • 1/10 ギガビット イーサネットの VLAN フィルタリング

  • 1/10 ギガビット イーサネットの VLAN アカウンティング

  • 入力バッファリングと輻輳通知

crs-ios-xr-bp4.gif

PLIM の加入過多

10GE PLIM

8 X 10G の PLIM では、約 80 Gbps のトラフィックを終端処理する機能が提供される一方、MSC の転送機能は最大 40 Gbps です。PLIM で使用できるすべてのポートにデータが入力される場合は加入過多が発生し、プレミアム トラフィックが誤って廃棄されないことを保証する QoS モデリングがきわめて重要になります。状況によっては、加入過多の選択の余地はなく、回避が必要です。これを実行するには、8 つのポートのうち 4 つのポートだけを使用する必要があります。また、MSC および PLIM 内部で最適な帯域幅がこの 4 つのポートで使用できるように注意する必要もあります。

注：ポートマッピングはリリース3.2.2以降で変更されています。下記のダイアグラムを参照してください。

リリース 3.2.1 以前でのポート マッピング

crs-ios-xr-bp5.gif

リリース 3.2.2 以降でのポート マッピング

crs-ios-xr-bp6.gif

前述のように、物理ポートに対するサービスの提供は 2 つの FabricQ ASIC のどちらかが行います。ASIC へのポートの割り当ては静的に定義され、変更できません。また、8 X 10G の PLIM には PLA ASIC が 2 つあります。1つ目のPLAサービスポート0 ～ 3、2つ目のサービス4 ～ 7。8 X 10G PLIMでの1つのPLAの帯域幅容量は約24 Gbpsです。単一の FabricQ ASIC のスイッチング キャパシティは、約 62 Mpps です。

ポート 0 〜 3 またはポート 4 〜 7 を使用する場合、PLA（24 Gbps）の帯域幅容量は 4 つのポートすべてで共有され、これにより全体的なスループットが制限されます。ポート0、2、4、6(3.2.1まで)または0、1、4、5(3.2.2以降)を入力すると、これらのポートすべてが1つのFabricQ ASICによって処理されます。スイッチング容量は62 Mppsですが、これもスループット容量を制限します。

最適なパフォーマンスを達成するには、PLA と FabricQ ASIC の両方で最高の効率性を実現するようにポートを使用することが最適です。

SIP-800/SPA

SIP-800 PLIM では、Service Port Adapter（SPA）と呼ばれるモジュラ インターフェイス カードを使用して動作する機能が提供されています。 SIP-800 では、理論上 60 Gbps インターフェイス キャパシティを備えた 6 つの SPA ベイが提供されます。MSC の転送キャパシティは、最大 40 Gbps です。SIP-800 のすべてのベイが使用されると、SPA の種類によっては加入過多が発生し、プレミアム トラフィックが誤って廃棄されないようにするには QoS モデリングがきわめて重要になる可能性があります。

注：オーバーサブスクリプションは、POSインターフェイスではサポートされていません。ただし、適切なスループット キャパシティが確実に提供されるようにするには、10 Gb POS SPA の配置が適切です。10 GbイーサネットSPAはIOS-XRリリース3.4でのみサポートされています。このSPAはオーバーサブスクリプション機能を提供します。

状況によっては、加入過多の選択の余地はなく、回避が必要です。これを実行するには、6 つのベイのうち 4 つのベイだけを使用する必要があります。また、MSC および PLIM 内部で最適な帯域幅がこの 4 つのポートのいずれでも使用できるように注意する必要があります。

SPA ベイ マッピング

crs-ios-xr-bp7.gif

前述のように、物理ポートに対するサービスの提供は 2 つの FabricQ ASIC のどちらかが行います。ASIC へのポートの割り当ては静的に定義され、変更できません。また、SIP-800 PLIM には PLA ASIC が 2 つあります。最初のPLAサービスポート0、1および3、2番目のサービス2、4および5。

SIP-800 PLIM での単一 PLA の帯域幅容量は、約 24 Gbps です。単一の FabricQ ASIC のスイッチング キャパシティは、約 62 Mpps です。

ポート0、1、3またはポート2、4、5を入力すると、PLA(24 Gbps)の帯域幅容量が、全体のスループットを制限する3つのポートすべてで共有されます。これらのポート グループには、それぞれの単一の FabricQ によりサービスが提供されるため、ポート グループの最大のパケット レートは 62 Mpps になります。最適な帯域幅を達成するには、PLA で最高の効率性を実現するようにポートを使用することが最適です。

推奨される配置：

  SPA ベイ番号 SPA ベイ番号 SPA ベイ番号 SPA ベイ番号
オプション 1 0 1 4 5
オプション 2 1 0 3 4

カードに4つ以上のSPAを装着する場合は、上記のオプションのいずれかを実行して、2つのポートグループ(0、1、3、2、4、5)間のインターフェイスを分散することをお勧めします。 次に、次のSPAモジュールを、0、1、3、2、4、5ポートグループのいずれかのオープンポートに配置する必要があります。

DWDM XENPACK

リリース 3.2.2 以降では、DWDM XENPACK のインストールが可能となり、これにより、調整可能な光モジュールが提供されます。このような XENPACK モジュールの冷却要件として、インストールされたモジュール間に空きスロットを置く必要があります。また、単一の DWDM XENPACK モジュールがインストールされると、XENPACK モジュールが DWDM デバイスではない場合でも最大で 4 つのポートが使用できます。したがって、これは FabricQ での PLA からポートへのマッピングに直接に影響します。この要件には注意する必要があり、次の表で検討されています。

推奨される配置：

光ファイバ ポート番号 光ファイバ ポート番号 光ファイバ ポート番号 光ファイバ ポート番号
オプション 1 または DWDM XENPACK 0 0 5 7
オプション 2 1 3 4 6

3.2.2 以降または 3.3 がインストールされている場合、FabricQ マッピングの変更は避けてください。このため、通常のモジュールと DWDM XENPACK のモジュールのどちらにも、さらに簡単な配置パターンを使用できます。

光ファイバ ポート番号 光ファイバ ポート番号 光ファイバ ポート番号 光ファイバ ポート番号
オプション 1 0 0 4 6
オプション 2 1 3 5 7

カードに4つ以上の非DWDM XENPACKポートを装着する場合は、リストされているオプションのいずれかを実行して、2つのポートグループ(0 ～ 3、4 ～ 7)間で光インターフェイスモジュールを展開することをお勧めします。 0 〜 3 または 4 〜 7 のポート グループの空ポートのいずれかに、次の光インターフェイス モジュールを配置する必要があります。光インターフェイス モジュールの 5 番に 0 〜 3 のポート グループを使用する場合、光インターフェイス モジュールの 6 番を 4 〜 7 のポート グループに配置する必要があります。

詳細については、『DWDM XENPAK モジュール』を参照してください。

構成管理

IOS-XR のコンフィギュレーションは 2 段階の設定によって実行されますが、第 1 段階ではユーザがコンフィギュレーションを入力します。この段階では、CLI でコンフィギュレーション構文の確認だけが行われます。この段階で入力されるコンフィギュレーションが認識されるのは、CLI/XML などのコンフィギュレーション エージェント プロセスだけです。このコンフィギュレーションは sysdb サーバには書き込まれないので、確認は行われません。バックエンド アプリケーションには通知されず、この段階ではコンフィギュレーションにアクセスしたり、コンフィギュレーションを認識したりすることはできません。

第 2 段階では、ユーザがコンフィギュレーションを明示的にコミットします。この段階では、コンフィギュレーションが sysdb サーバに書き込まれ、バックエンド アプリケーションによってコンフィギュレーションが確認され、sysdb によって通知が生成されます。第 1 段階で入力されたコンフィギュレーションをコミットする前に、コンフィギュレーション セッションを中止することができます。したがって、第 1 段階で入力されたすべてのコンフィギュレーションが常に第 2 段階で常にコミットされると仮定することは危険です。

また、第 1 段階や第 2 段階では、ルータの動作や実行コンフィギュレーションを複数のユーザが修正できます。したがって、第 1 段階でのコンフィギュレーションや動作状態が実行されるルータのテストは、実際にコンフィギュレーションがコミットされる第 2 段階では有効ではない場合があります。

コンフィギュレーション ファイル システム

Configuration File System（CFS; コンフィギュレーション ファイル システム）は、ルータのコンフィギュレーションを格納するために使用される一連のファイルとディレクトリです。CFS はディレクトリ disk0:/config/ の下に格納されますが、これは RP で使用されるデフォルトのメディアです。CFS 内のファイルとディレクトリはルータには内部的なものでなので、ユーザによる修正や削除は避ける必要があります。これにより、コンフィギュレーションが失われたり破損したりして、サービスに影響が及ぶ可能性があります。

各コミット後、CFS にスタンバイ RP へのチェックポイントが行われます。このことは、フェールオーバー後にルータのコンフィギュレーション ファイルを保存するのに役立ちます。

ルータのブートアップ中、最後にアクティブであったコンフィギュレーションが CFS に格納されたコンフィギュレーション コミット データベースから適用されます。ルータによって自動的に実行されるため、各設定のコミット後にアクティブなコンフィギュレーションをユーザが手動で保存する必要はありません。

ブートアップ時でのコンフィギュレーションの適用中に、コンフィギュレーションを変更することは推奨できません。コンフィギュレーションの適用が完了していない場合は、ルータにログオンすると次のメッセージが表示されます。

System Configuration Process

このデバイスのスタートアップ コンフィギュレーションは、現在ロード中です。これには数分かかる場合があります。完了時には通知されます。このプロセスが完了するまでは、デバイスのコンフィギュレーション変更は行わないでください。場合によっては、最後にアクティブであったコンフィギュレーションを CFS から復元するのではなく、ユーザ提供の ASCII コンフィギュレーション ファイルからルータのコンフィギュレーションを復元することが望ましい場合があります。

次の手順で、強制的にコンフィギュレーション ファイルを適用できます。

using the “-a” option with the boot command. This option forces
    the use of the specified file only for this boot.
    
    rommon>boot <image> –a <config-file-path>

    setting the value of “IOX_CONFIG_FILE” boot variable to the
    path of configuration file. This forces the use of the specified file
    for all boots while this variable is set.
    
    rommon>IOX_CONFIG_FILE=
      
      
    rommon>boot <image>

ルータ設定を復元する際に、1つ以上の設定項目が有効にならない可能性があります。失敗したすべてのコンフィギュレーションは CFS に保存され、次のリロードまで維持されます。

失敗したコンフィギュレーションを確認して、エラーを修正し、コンフィギュレーションを再度適用することができます。

これらは、ルータの起動時に失敗したコンフィギュレーションに対処するためのヒントの一部です。

IOX では、コンフィギュレーションを失敗したコンフィギュレーションとして次の 3 つの原因に分類できます。

  1. 構文エラー：パーサーは構文エラーを生成します。これは通常、CLIコマンドに互換性がないことを示します。構文エラーを修正して、コンフィギュレーションを再度適用する必要があります。

  2. セマンティックエラー：セマンティックエラーは、ルータの起動中にコンフィギュレーションマネージャが設定を復元したときに、バックエンドコンポーネントによって生成されます。コンフィギュレーションが実行コンフィギュレーションの一部として受け入れられることを保証する役割は、cfgmgr にはないことに注意することが重要です。cfgmgr は単なる中継者で、バックエンド コンポーネントによって生成されるセマンティックスの失敗を報告するだけです。失敗の理由を分析して失敗の原因を判断するのは、それぞれのバックエンド コンポーネントのオーナーの責任です。ユーザは設定モードからdescribe <CLI commands>を実行し、バックエンドコンポーネントの検証者の所有者を簡単に見つけることができます。たとえば、失敗したコンフィギュレーションとして router bgp 217 が表示される場合、describe コマンドによってコンポーネント ベリファイアが ipv4-bgp コンポーネントであることが表示されます。 

    RP/0/0/CPU0:router#configure terminal
RP/0/0/CPU0:router(config)#describe router bgp 217
The command is defined in bgpv4_cmds.parser

Node 0/0/CPU0 has file bgpv4_cmds.parser for boot package /gsr-os-mbi-3.3.87/mbi12000-rp.vm from gsr-rout
Package:
    gsr-rout
        gsr-rout V3.3.87[Default]  Routing Package
        Vendor : Cisco Systems
        Desc   : Routing Package
        Build  : Built on Mon Apr  3 16:17:28 UTC 2006
        Source : By ena-view3 in /vws/vpr/mletchwo/cfgmgr_33_bugfix for c2.95.3-p8
        Card(s): RP, DRP, DRPSC
        Restart information:
          Default:
            parallel impacted processes restart
Component:
    ipv4-bgp V[fwd-33/66]  IPv4 Border Gateway Protocol (BGP)

File: bgpv4_cmds.parser


User needs ALL of the following taskids:

        bgp (READ WRITE) 

It will take the following actions:
  Create/Set the configuration item:
         Path: gl/ip-bgp/0xd9/gbl/edm/ord_a/running
        Value: 0x1
Enter the submode:
        bgp
RP/0/0/CPU0:router(config)#

  3. 適用エラー：設定は正常に確認され、実行コンフィギュレーションの一部として受け入れられましたが、バックエンドコンポーネントが何らかの理由で動作状態を更新できません。コンフィギュレーションは正しく確認されたので実行コンフィギュレーションに表示されますが、バックエンド動作エラーのために失敗した設定としても表示されます。describe コマンドを、コンポーネント適用のオーナーを検索するために、適用が失敗した CLI で再度実行できます。

    • 起動時に失敗したコンフィギュレーションを確認して再度適用するには、下記手順を実行します。

      リリース 3.2 の場合、失敗したコンフィギュレーションを再度適用するために、オペレータは次の手順を使用できます。

      • オペレータは、ルータの起動時に保存された、失敗したコンフィギュレーションを確認するために show configuration failed startup コマンドを使用できます。

      • オペレータはshow configuration failed startup noerror | file myfailed.cfgコマンドを発行します。

      • オペレータは、この失敗したコンフィギュレーションを再度適用するために、コンフィギュレーション モードに切り替えて、load/commit コマンドを使用する必要があります。

           RP/0/0/CPU0:router(config)#load myfailed.cfg
   Loading.
   197 bytes parsed in 1 sec (191)bytes/sec
   RP/0/0/CPU0:router(config)#commit

    • リリース 3.3 イメージの場合、オペレータは次のアップデートされた手順を使用できます。

      オペレータは、失敗したコンフィギュレーションを確認して再度適用するために、show configuration failed startup コマンドと load configuration failed startup コマンドを使用する必要があります。 

      RP/0/0/CPU0:router#show configuration failed startup 
!! CONFIGURATION FAILED DUE TO SYNTAX/AUTHORIZATION ERRORS 
telnet vrf default ipv4
server max-servers 5 interface POS0/7/0/3 router static 
address-family ipv4 unicast
 0.0.0.0/0 172.18.189.1

!! CONFIGURATION FAILED DUE TO SEMANTIC ERRORS 
router bgp 217 !!%
Process did not respond to sysmgr !
RP/0/0/CPU0:router#

RP/0/0/CPU0:router(config)#load configuration failed startup noerror
Loading.
263 bytes parsed in 1 sec (259)bytes/sec
RP/0/0/CPU0:mike3(config-bgp)#show configuration
Building configuration...
telnet vrf default ipv4 server max-servers 5 router static 
address-family ipv4 unicast
  0.0.0.0/0 172.18.189.1
 !
!
router bgp 217
!
end

RP/0/0/CPU0:router(config-bgp)#commit

カーネル ダンプ機能

デフォルトでは、プロセスがクラッシュすると IOS-XR によってコア ダンプがハードディスクに書き込まれますが、カーネル自体がクラッシュした場合にはこれは書き込まれません。マルチシャーシシステムの場合、この機能は現在ラインカードシャーシ0でのみサポートされています。他のシャーシは将来のソフトウェアリリースのソフトウェアでサポートされる予定です。

標準コンフィギュレーションと admin モード コンフィギュレーションの両方で次の設定を使用して、RP と MSC のどちらのカーネル ダンプも有効にすることが推奨されます。 

exception kernel memory kernel filepath harddisk:   
exception dump-tftp-route port 0 host-address 10.0.2.1/16 destination 10.0.2.1 next-hop 10.0.2.1 tftp-srvr-addr 10.0.2.1

カーネル ダンプ設定

カーネル ダンプ設定により、カーネル クラッシュに対して次が発生します。

  1. RP がクラッシュし、RP のハードディスクではディスクのルート ディレクトリ内にダンプが書き込まれる。

  2. MSC がクラッシュすると、RP0 のハードディスクではディスクのルート ディレクトリ内にダンプが書き込まれる。

これは、non-stop forwarding（NSF）がルーティング プロトコルに設定されているため、RP フェールオーバーの回数には影響しません。コアの書き込み中のクラッシュの後、クラッシュした RP やラインカードが再び使用できるにようなるには、さらに数分の時間が必要になる場合があります。

標準モードと admin モードの両方のコンフィギュレーションに対するこの設定の追加の例を次に示します。admin モードのコンフィギュレーションでは、DRP の使用が必要になることに注意してください。

次の出力に、カーネル ダンプ設定の例を示します。

RP/0/RP0/CPU0:crs1#configure
RP/0/RP0/CPU0:crs1(config)#exception kernel memory kernel filepat$
RP/0/RP0/CPU0:crs1(config)#exception dump-tftp-route port 0 host-$
RP/0/RP0/CPU0:crs1(config)#commit
RP/0/RP0/CPU0:crs1(config)#
RP/0/RP0/CPU0:crs1#admin
RP/0/RP0/CPU0:crs1(admin)#configure
Session                     Line        User      Date                      Lock
00000201-000bb0db-00000000  snmp        hfr-owne  Wed Apr  5 10:14:44 2006 
RP/0/RP0/CPU0:crs1(admin-config)#exception kernel memory kernel f$
RP/0/RP0/CPU0:crs1(admin-config)#exception dump-tftp-route port 0$
RP/0/RP0/CPU0:crs1(admin-config)#commit
RP/0/RP0/CPU0:crs1(admin-config)#
RP/0/RP0/CPU0:crs1(admin)#

セキュリティ

LPTS

Local Packet Transport Services（LPTS）では、ローカルの宛先のパケットが処理されます。LPTS はさまざまなコンポーネントで構成されています。

  1. 主なコンポーネントは、ポート調停プロセスと呼ばれています。たとえば、BGP や IS-IS など、異なるプロトコル プロセスからのソケット要求を受信し、これらのプロセスのすべてのバインディング情報を追跡します。たとえば、BGP プロセスがソケット ナンバー 179 を受信する場合、PA ではその情報を BGP プロセスから取得し、IFIB 内のそのプロセスにバインディングを割り当てます。

  2. IFIB は、LPTS プロセスの別のコンポーネントです。どのプロセスが、どの特定のポートを受信しているかのバインディング情報を維持します。IFIB はポート調停プロセスによって生成され、ポート調停によって保持されます。IFIB によってこの情報の複数のサブセットが生成されます。

    1 番目のサブセットは IFIB のスライスです。このスライスは IPv4 プロトコルなどに関連付けることができます。次に、スライスは該当するフロー マネージャに送信され、パケットを適切なプロセスに転送するために IFIB スライスが使用されます。

    2 番目のサブセットは事前 IFIB であり、これにより、適切なプロセス（プロセスが 1 つだけ存在する場合）や適切なフロー マネージャへの LC によるパケットの転送が可能になります。

  3. たとえば、BGP の複数のプロセスなど、ルックアップが簡単ではない場合、パケットをさらに配布するのにフロー マネージャが役立ちます。各フロー マネージャは、IFIB の単一または複数のスライスを持ち、IFIB のスライスに関連付けられた該当するプロセスにパケットを適切に転送します。

  4. 宛先ポートにエントリが定義されていない場合、そのパケットは廃棄されるか、フロー マネージャに転送されます。ポートに関連付けられたポリシーが存在する場合、パケットは関連付けられたポートなしで転送されます。フロー マネージャは新しいセッション エントリの生成を支援します。

内部パケット転送の方法

レイヤ 2（HDLC、PPP）フローとレイヤ 4（ICMP/PING）フローの 2 種類のフロー、およびルーティング フローが存在します。

  1. レイヤ2 HDLC/PPP：これらのパケットはプロトコルIDによって識別され、スプレイヤのCPUキューに直接送信されます。レイヤ 2 プロトコル パケットには高い優先順位が付与され、CPU によって取得されて（Squid 経由）処理されます。したがって、レイヤ 2 のキープアライブは CPU 経由の LC を介して直接応答されます。これによって、応答のために RP を経由する必要がなくなり、配布されたインターフェイス管理のテーマに沿って実行されます。

  2. ICMP（レイヤ 4）パケットは LC 内で受信され、ルックアップを介して IFBI を通過し、スプレイヤ上の CPU キューに送信されます。これらのパケットは CPU に送信されて（Squid 経由）処理されます。次に、応答はファブリックを経由して転送されるために、スプレイヤ出力キューを介して送信されます。これは別のアプリケーションにも情報が必要な場合です（ファブリックを介した複製）。 ファブリックを介した後、パケットは適切なスポンジとコントロール キューを経由して適切な出力 LC に宛てられます。

  3. ルーティング フローは IFIB 内でルックアップされ、いずれかが制御パケット用に予約された出力シェーピング キュー（8000 のキュー）へ送信されます。これは非シェーピング キューであり、単にフルになるたびに処理が行われるだけです。 – 優先度が高い。次に、パケットは高い優先順位のキュー上のファブリックを介して、スポンジ上の一連の CPU に送信され（スプレイヤ上の Squid キューに類似）、適切なプロセス、フロー マネージャ、または実際のプロセスによって処理されます。応用は、出力ラインカード スポンジを経て、さらにライン カード経て戻されます。出力 LC スポンジには、制御パケットを処理するために特殊なキューが用意されています。スポンジ内のキューは、出力ポートごとに、高い優先順位、制御パケット、および低い優先順位のパケットに分けられます。

  4. PSE には、レイヤ 4、レイヤ 2、およびルーティング パケットのレート制限用に設定された一連のポリシャが用意されています。これらは事前設定されていますが、将来的にはユーザによる設定が可能になります。

LPTS の最も一般的な問題の 1 つは、ルータに ping を実行する際に廃棄されるパケットです。通常、LPTS ポリシャでは、これらのパケットにレート制限が行われます。次は確認する場合です。

RP/0/RP0/CPU0:ss01-crs-1_P1#ping 192.168.3.14 size 8000 count 100                                  
Type escape sequence to abort.
Sending 100, 8000-byte ICMP Echos to 192.168.3.14, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!
!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!
Success rate is 97 percent (97/100), round-trip min/avg/max = 1/2/5 ms
RP/0/RP0/CPU0:ss01-crs-1_P1#show lpts pifib hardware entry statistics location 0/5/CPU0 | excl 0/0
 
* - Vital; L4 - Layer4 Protocol; Intf - Interface;
DestAddr - Destination Fabric Address;
na - Not Applicable or Not Available
 
Local, Remote Address.Port          L4    Intf         DestAddr     Pkts/Drops
----------------------------------- ----- ------------ ------------ --- any                                 any   any          Punt       100/3
224.0.0.5 any                       any   PO0/5/1/0    0x3e         4/0
224.0.0.5 any                       any   PO0/5/1/1    0x3e         4/0
<further output elided>

IPSec

IP パケットは、本来はセキュリティで保護されていません。IP セキュリティは IP パケットを保護するために使用される方式です。CRS-1 の IP セキュリティはソフトウェア転送パスに実装されているため、IP セキュリティ セッションは RP/DRP で終端されます。CRS-1 につき合計 500 の IPsec セッションがサポートされます。この数は CPU の処理速度と割り当てられたリソースによって異なります。これにはソフトウェア制限がなく、ローカルに発信され、RP でローカルに終端したトラフィックだけが IP セキュリティ処理の対象となります。この種類のトラフィックには IP セキュリティ トランスポート モードまたはトンネル モードのどちらも使用できますが、IP セキュリティ処理ではオーバーヘッドが小さいため、IP セキュリティ トランスポート モードが優先されます。

リリース 3.3.0 では、BGP over IPsec および OSPFv3 over IPsec の暗号化がサポートされています。

IP セキュリティの実装の詳細については、『Cisco IOS XR システム セキュリティ設定ガイド』を参照してください。

注：IPsecには暗号パイが必要です(たとえば、hfr-k9sec-p.pie-3.3.1)。

アウトオブバンド

コンソールと AUX アクセス

CRS-1 RP/SC では、アウトオブバンド管理の目的にコンソールと AUX ポートが使用でき、さらに IP 経由のアウトオブバンドには管理イーサネット ポートも使用できます。

各 RP/SCGE のコンソールと AUX ポート（シャーシにつき 2 つ）は、コンソール サーバに接続可能です。これは、単一のシャーシ システムに 4 つのコンソール ポートが必要であり、マルチシャーシ システムに 12 のポートと 2 つの追加ポート（Catalyst 6504-E のスーパーバイザ エンジンの場合）が必要であることを意味します。

AUX ポート接続は、IOS-XR カーネルへのアクセスを提供し、コンソール ポート経由ではシステム回復が不可能な場合にそれを実現するため、重要です。AUX ポートを介したアクセスは、システム上でローカルに定義されたユーザだけが使用でき、さらにユーザにルートシステムや Cisco サポート レベルのアクセス権が備わっている場合にのみ使用可能です。また、ユーザにはシークレット パスワードを定義しておく必要もあります。

仮想端末アクセス

Telnetおよびセキュアシェル(SSH)を使用して、vtyポート経由でCRS-1に到達できます。デフォルトではどちらも無効になっているので、ユーザが明示的にこれらを有効にする必要があります。

注：IPsecには暗号パイが必要です(たとえば、hfr-k9sec-p.pie-3.3.1)。

SSH を有効にするには、まず、この例で示すように RSA キーおよび DSA キーを生成します。 

RP/0/RP1/CPU0:Crs-1#crypto key zeroize dsa
% Found no keys in configuration.
RP/0/RP1/CPU0:Crs-1#crypto key zeroize rsa
% Found no keys in configuration.

RP/0/RP1/CPU0:Crs-1#crypto key generate rsa general-keys
The name for the keys will be: the_default
  Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keypair. 
  Choosing a key modulus greater than 512 may take a few minutes.

How many bits in the modulus [1024]: 
Generating RSA keys ...
Done w/ crypto generate keypair
[OK]

RP/0/RP1/CPU0:Crs-1#crypto key generate dsa            
The name for the keys will be: the_default
  Choose the size of your DSA key modulus. Modulus size can be 512, 768, or 1024 bits. Choosing a key modulus
How many bits in the modulus [1024]: 
Generating DSA keys ...
Done w/ crypto generate keypair
[OK] 


!--- VTY access via SSH & telnet can be configured as shown here.

vty-pool default 0 4
ssh server
!
line default
 secret cisco
 users group root-system
 users group cisco-support
 exec-timeout 30 0
transport input telnet ssh
!
!
telnet ipv4 server

関連情報

更新履歴

改定 発行日 コメント
1.0
01-Nov-2006
初版

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ

このドキュメントは次の製品に対応しています