メイン | 2006年03月 »

2006年02月28日

MAC アドレスは5分で消えるか?

多くのLayer2 スイッチでは、MAC アドレステーブルのエージングタイムは300秒に設定されています。

IEEE 802.1D が推奨するデフォルト値だからです。
IEEE 802.1D では、10〜1,000,000 秒の間で設定可能とされています(実際に設定可能かどうかは、機器の実装に依存します)。

※ IEEE 802.1D - Table 7.4 Ageing time parameter value 参照

あるMAC アドレスがスイッチのポートで学習された後、そのMAC アドレスを送信元とするフレームを300秒間受信しないと、そのMAC アドレスはテーブルから削除されます。
というのが通説となっています。

これは、多くの場合正しくありません
MAC アドレステーブルのエージングタイムは、テーブル上のMAC アドレスが最後に参照されてから、エイジアウトするまでの時間を定めた物、という誤解に基づいているからです。


MAC アドレステーブルのエージングタイムは、エイジアウトするまでの時間ではなく、エントリをエイジアウトさせるべきかどうかの判定を行う間隔を定めた値です。

MAC アドレスがスイッチのポートで学習されると、そのMAC アドレスには、スイッチによって参照された事を意味するフラグがセットされます。

学習された直後のエイジアウト判定処理で、スイッチはMAC アドレスのフラグを確認します。

ここでフラグがセットされている場合、フラグはリセットされます。

その次の判定処理までの間に、そのMAC アドレスを送信元とするフレームを同じポートで受信すると、フラグは改めてセットされます。

判定処理までの間に、そのようなフレームを受信しなかった場合(つまり、フラグはリセットされている状態)、そのMAC アドレスはテーブルから削除されることになります。

以下の例は、エージングタイムがデフォルトの300秒の場合のエイジアウトについて説明するものです。


  1. Aのタイミングでフレームを受信します。送信元アドレスをMAC アドレステーブルに登録し、判定フラグをセットします。
  2. Bのタイミングで判定処理が発生し、セットされていたフラグをリセットします。
  3. Bから300秒経過し、Cのタイミングで二度目の判定処理が発生します。
    A で登録されたMAC アドレスにはフラグがセットされていないので、エイジアウトします。

BCの間に、フレームを再度受信した場合は、フラグがセットしなおされるため、C のタイミングではフラグがリセットされるだけで、エイジアウトはしません。

以上の事から、学習されたMAC アドレスが、その後一度も再学習されなかった場合、エイジアウトするまでに要する時間は、300秒以上(ただし、600秒未満)となることがわかります。

    最短時間 = 300 秒 ------>> 判定処理のタイミングに学習した場合
    最長時間 = 600-1 秒 ------>> 判定処理の直後に学習した場合


Catalyst6500 のDFC (Distributed Feature Card) など一部のスイッチでは、上記の動作とは異なる実装がされているものもあります。
DFC は、Catalyst6500 のラインカード毎に搭載されるForwarding Engine です。

本来SVE (Supervisor Engine Module) 上のPFC (Policy Feature Card) で行う転送処理を、各ラインカードで行わせることで、SVE の負荷を下げると同時に、高速転送処理を実現しています。

エージングの方式が通常のスイッチと異なるのは、筐体内に分散されたDFC 間で情報の同期を取るためのメカニズムが加わっているためです。

STP を究める 基礎編 (5)Bridge ID とRoot Bridge (ルートブリッジ)

これまでの例で見たように、Bridged-LAN 上には一台以上のブリッジが存在し得ます。

二台以上存在する場合、個々のブリッジを識別するためには、一意(ユニーク)な名前が必要です。
どのブリッジの名前も"Bridge" だと、どの機器を指しているのかわからないからです。

MAC 副層の上で動作するブリッジは、いわゆるLayer2 機器です。
Layer2 (Ethernet)には、MAC アドレスという、一意な名前(※)があります。
ブリッジの持つMAC アドレスを名前として利用すれば、ブリッジが何台あっても重複することなく一意に表現できます。



    IP アドレスと違い、MAC アドレスには位置情報が含まれていません。
    位置情報が含まれない識別子は、アドレスではなく名前です。
    つまり、MAC アドレスは厳密にはアドレスではないことになります。
    (IP アドレスには、ホストが所属するネットワーク(位置)を意味するネットワーク部があります)


STP (Spanning Tree Protocol) は、物理的にループ構成となっているBridged-LAN 上に、論理的なツリートポロジを構築するためのプロトコルです。

ツリートポロジとは、トポロジ上の任意の二点間を結ぶ経路が一つしか存在しないトポロジです。
具体的には、基点となるブリッジから枝葉を伸ばすようにノード(ブリッジ)を接続していきます。

基点となるブリッジを、Root Bridge (ルートブリッジ)と呼びます。
root は、根を意味する英単語です。
つまり、ツリートポロジの根となるブリッジです。



ルートブリッジはどのように選出されるのでしょうか。

一番簡単なのは、静的に設定してやる方法です。管理者により直接、Root Bridge であると設定してやれば、間違いはありません。

しかし、この方法には問題があります。
静的な設定は、ブリッジの故障や新しいブリッジの追加というイベントに、自動的に対応できません。
つまり、STP を究める 基礎編 (4)スパニングツリーの役割でお話した、b項に違反してしまいます。

ブリッジ同士で情報を交換し合って、Root Bridge を選出することが出来れば、イベントの発生を受けて、その時々に適切なブリッジがRoot Bridge になることが出来ます。

ブリッジ同士で交換する情報には、ブリッジの名前が格納されています。
この名前は、16進数で構成されるMAC アドレスです。

幸いMAC アドレスは16進数の数値です。数値であれば、ブリッジ同士で大小を比較し、最も小さいMAC アドレスを持つブリッジを、Root Bridge に選出することが可能です。


しかし、MAC アドレスを比較することにも問題があります。

MAC アドレスは機器固有のアドレスであり、通常は変更することが出来ません。
つまり、Bridged-LAN の構築に同じブリッジを使う限り、必ず決まったブリッジがRoot Bridge となってしまいます。

これは、「任意のトポロジを構成できること」を求めるd項に違反しています。

Root Bridge はツリートポロジの根となるブリッジです。
トラフィックのパターンにもよりますが、枝葉となるブリッジ間の通信の多くは、Root Bridge を通過します。

Bridged-LAN の外縁部 (端末が収容されている、ブロードキャストドメインの末端)のブリッジがRoot Bridge となると、トラフィックがそこに集中してしまいます。

MAC アドレスだけでRoot Bridge を選出するのは無理がありそうです。


STP を実装しているブリッジはそれぞれ、変更可能なBridge Priority (ブリッジプライオリティ)という値を持っています。

このBridge Priority にMAC アドレスを合わせた値を、Bridge ID (ブリッジID) と呼びます。
Root Bridge を選出するために比較されるのは、このBridge ID です。








Bridge Priority は、0 〜 65535 (10進数) の間で設定可能です。
IEEE 802.1D で推奨するデフォルト値は32768(16進数の0x8000) で、Cisco のCatalyst を含め多くの機器はこの値をデフォルト値にしています。

「Bridge Priority + MAC アドレス」という形をとるため、通常は、MAC アドレスの値に左右されることなく、設定されたBridge Proirty が最も小さいブリッジが、Root Bridge に選出されます。

初期値のまま使用するなど、Bridge Priority が同じブリッジが二台以上存在する場合、MAC アドレスが最も小さいブリッジがRoot Bridge となります。


















    STP を究める 基礎編 の内容は、特に明記しない限り、1998年版のIEEE 802.1D に基づいています。
    Bridge ID、Port ID、Path Cost 値など、IEEE 802.1T で行われた仕様の拡張は、2004年版のIEEE 802.1D に盛り込まれています。
    これらの拡張仕様については、応用編にて説明する予定です。

2006年02月26日

STP を究める 基礎編 (4)スパニングツリーの役割

STP を究める 基礎編 (1)スパニングツリーとルーティングプロトコル」でも書いたように、STP は、各ブリッジからルートブリッジへの最短パスを探し出すことを目的としたプロトコルです。

ルートブリッジへのパスが複数ある場合は、最短パス以外を待機系とします。
最短パスが使用不可能となると、待機系となっているパスの中で最も最短のパスが改めて選出されます。

そうすることで、ブリッジ間だけではなく、任意の二点間のパスがひとつだけとなり、ループを防ぐことができます。

トポロジの変化を察知して最新の状況に対応するためには、ブリッジ同士が情報を交換するための規則と、交換した情報を元に正しく判断するための規則が必要なります。
これらの規則を総称して、STA (Spanning Tree Algorithm) と呼びます。

STA は、IEEE 802.1D の第八章で定義されています。
IEEE 802.1D は、MAC フレームの宛先アドレスを読んで転送先ポートを決定する、いわゆるTransparent MAC Bridge (透過MAC ブリッジ) の仕様を定めた規格です。

IEEE 802.1D の第八章第一節では、STA に必要とされる項目が挙げられています。

8.1 Requirements to be met by the algorithm

a) It will configure the active topology of a Bridged LAN of arbitrary topology into a single spannning tree, such that there is at most one data route between any two end stations, eliminating data loops.

任意のトポロジを単一のツリートポロジーに収束させることで、任意の二点間のパスをひとつにし、ループを防ぐことが求められています。

b) It will provide for fault tolerance by automatic reconfiguration of the spanning tree topology as a result of Bridge failure or a breakdown in a data path, within the confines of the available Bridged LAN components, and for the automatic accomodation of any Bridge or Bridge Port added to the Bridged LAN without the formation of transient data loops.

ブリッジやポートの追加や、故障に対応して、自動的にトポロジを変化させることが求められています。
また、新しいトポロジに対応するまでの間、一時的なループが発生しないことも要求されます。

c) The entire active topology will stabilize in any sized Bridged LAN. It will, with a high probability, stabilize within a short, known bounded interval in order to minimize the time for which the service is unavailable for communication between any pair of end stations.

Bridged LAN の大きさにかかわらず、安定動作することが求められています(これには、例外があります)。
また、状況の変化を受けてトポロジを変更する際、収束するまでの時間が短いことが、また、計測可能な範囲であることが求められています。
つまり、「いつかは収束する」というのは許されません。

d) The active topology will be predictable and reproducible, and may be selected by management of the parameters of the algorithm, thus allowing the application of Configuration Management, following traffic analysis, to meet the goals of Performance Management.

同じパラメータを設定している限り、必ず同じトポロジに収束することが求められています。
また、パラメータを操作することで、任意のトポロジを構成できることが求められています。
つまり、「構築するたびに、異なるトポロジ」は許されません。

e) It will operate transparently to the end statins. such that they are unaware of their attachment to a single LAN or a Bridged LAN when using the MAC Services.

端末から見て、透過的に動作することが求められています。
これは、STP への要求というよりは、ブリッジに求められている要件です。
IP で使われるデフォルトゲートウェイのような要素が必要ないことを意味します。

f) The communications bandwidth consumed by the Bridges in establishing and maintining the spanning tree on any particular LAN will be a small percentage of the total available bandwidth and independent of the total traffic supported by the Bridged LAN regardless of the total number of Bridges or LANs.

ブリッジ間でやり取りする情報が、帯域を浪費しないことが求められています。

g) The memory requirements associated with each Bridge Port are independent of the number of Bridges and LANs in the Bridged LAN.

LAN 上にブリッジが何台存在していても、LAN 上に情報を発信するのは通常一台だけです。

h) Bridges do not have to be individually configured before being added to the Bridged LAN, other than having their MAC Addresses assigned through normal procedures.

ブリッジをLAN に接続する際、事前の設定は必要ありません。
IP ルータのような、アドレスの設定が必要がないことを意味します。
ただし、任意のトポロジを構成するためには、設定を操作する必要があります。



これらSTA に求められる要件をブリッジに実装したのが、STP (Spanning Tree Protocol) です。
以後のページでは、これらの要件がどのように実現されているのか、詳細を追っていきます。


    STP を究める 基礎編 の内容は、特に明記しない限り、1998年版のIEEE 802.1D に基づいています。
    Bridge ID、Port ID、Path Cost 値など、IEEE 802.1T で行われた仕様の拡張は、2004年版のIEEE 802.1D に盛り込まれています。
    これらの拡張仕様については、応用編にて説明する予定です。

2006年02月22日

STP を究める 基礎編 (3)Bridged LAN の冗長化

ブリッジが一台しかないと、そのブリッジが壊れてしまうとLAN 間の通信手段は無くなってしまいます。











上図では、LAN-1 とLAN-2 がBridge によって相互接続されています。
Brige のMAC アドレステーブルには、次のようなエントリが作成されており、PC-2 宛のフレームはPort-2 へ、PC-1 宛のフレームはPort-1 へ転送します。
仮に、PC-1 宛のフレームをPort-1 で受け取ると、受信ポートと転送先が同じなので、破棄されます。

Bridge に不具合が発生すると、PC-1 とPC-2 の間でフレームを送りあう手段は無くなってしまいます。








このような状態になってしまうのは、LAN-1 とLAN-2 の間のBridge が一台しかないからです。
Bridge も機械ですから、絶対に壊れないということはありえません。

1台しかないからだめなのであれば、2台にしてみましょう。









LAN-1 とLAN-2 の間に、2台のBridge を置いてみました(Bridge-A、B)。
これなら、Bridge が一台壊れても、もう一台のBridge を経由して通信を継続することができます。

2台のBridge では、MAC アドレステーブルは次のようになっています。
















PC-1 からPC-2 へ送られるフレームは、Bridge-B によりLAN-1 へ転送された後、Bridge-A のPort-1 でも受信されます。
Bridge-A のMAC アドレステーブルでは、PC-1 のMAC アドレスはPort-1 で学習されているので、Port-2 へ転送されることは無く、破棄されます。

フレームがブロードキャストの場合はどうでしょうか?












ff-ff-ff-ff-ff-ff は、全てのノードを意味するMAC アドレスです。
ff-ff-ff-ff-ff-ff を送信元とするノードは存在しないので、このアドレスがブリッジに学習されることはありえません(※文末)

学習されることがないため、宛先MAC アドレスがff-ff-ff-ff-ff-ff となっているフレーム(ブロードキャスト)を受け取ったブリッジは、無条件に他のポートへ転送します。
結果、二台のブリッジによってフレームは永遠に転送され続けることになります。

Ethernet フレームには、IP ヘッダのTTL のような、転送された回数を記録する仕組みがないからです。
当然、ブリッジはそのフレームが何回転送されたかを知ることができず、永遠に転送され続けることになります。

PC-1 だけではなく、フレームを送信したPC-2 にも、大量のブロードキャストフレームが届きます。
PC は受信したブロードキャストフレームを処理するのに手一杯となります。
ブリッジにもCPU が搭載されており、受信したブロードキャストフレームを処理する必要があります。
PC と同じように手一杯になり、ブリッジ本来のフレーム転送処理にも影響が出てきます。
いわゆる、ブロードキャストストームです。


たいていの技術書で説明していあるのは、ここまでです。
しかし、複数のLAN の間に二台以上のブリッジがある場合に発生する問題は、これだけではありません。
これまでの説明では、ユニキャストフレームなら問題がないようにも読めます。












PC-2 から送信されたフレームは、Bridge-A とB の両方で受信され、それぞれLAN-1 へ転送されます。
結果、PC-1 はPC-2 が送信した数の二倍のフレームを受信することになります。
また、二台のブリッジが完全に同期を取ってフレームを転送するわけではありません。
つまり、PC-2 が送信した順番通りに、PC-1 に届くとは限らないわけです。

前者をFrame Duplication (複製)、後者をMiss Ordering (順番間違い)と呼びます。
上位層のプロトコルにも依存しますが、PC-1 は、受信したフレームから上位層のデータを正しく再生できない場合もあります。

Ethernet では、フレームは、必ず送信された順番で受信される必要があります。


単純にブリッジの台数を増やしただけでは、冗長化は実現できないことが分かりました。一方のブリッジが待機系となり、他方のブリッジが正常に動作している間はフレーム転送処理を行わないような仕組みがあれば、なんとかなりそうです。

本特集で取り上げるSTP (Spanning Tree Protocol) を使うと、そのような問題を解決することができます。

※ 送信元にff-ff-ff-ff-ff-ff を入れる端末と、そんなフレームを受信するとMAC アドレステーブルに登録してしまうLAN スイッチ・・・・関連性のない二つのバグのコラボレーションで、特定ポートにしかブロードキャストを転送できなくなるというトラブルを経験したことがあります・・・


    STP を究める 基礎編 の内容は、特に明記しない限り、1998年版のIEEE 802.1D に基づいています。
    Bridge ID、Port ID、Path Cost 値など、IEEE 802.1T で行われた仕様の拡張は、2004年版のIEEE 802.1D に盛り込まれています。
    これらの拡張仕様については、応用編にて説明する予定です。

2006年02月20日

STP を究める 基礎編 (2)LAN とBridged LAN

STP (Spanning Tree Protocol) の話をする際、「LAN の中でもっともプライオリティが高い」という表現が頻繁に出てきます。

ここで言うLAN は、普通LAN と聞いて思い浮かべるLAN とは少しちがいます。

下図では、三つのEthernet セグメントが、2台のブリッジ(Bridge-A、B)によって接続されています。













各セグメントには、LAN-1、LAN-2、LAN-3 と名前がついています。
STP のトポロジーを考える場合、このように、Ethernet セグメント = LAN となります。
つまり、このネットワークには、LAN が三つあることになります。

このように、複数のLAN がブリッジで相互接続された状態を、Bridged-LAN(ブリッジドLAN:ブリッジされたLAN) と呼びます。

この定義は、IEEE 802 (LMSC: LAN and MAN Standard Committee) により定められたものです。
LAN とは、IEEE802.3 や802.5 といった規格で定められている範囲のもの、ということができます。
それらを相互接続するための規格が、IEEE802.1d です。

※ IEEE 802.1d = Local Area Network - Media Access Control (MAC) Bridges

STP の話をしているときにLAN と言う場合、Ethernet であればCollision Domain (コリジョンドメイン)と同じ意味になります。

UTP や光ケーブルでブリッジ同士がPoint-to-Point 接続されている場合は、その部分がLAN です。











Layer2で動作する機器には、ブリッジとスイッチがあります。
どちらも、受け取ったフレームから送信元MAC アドレスを学習するラーニングブリッジです。
受け取ったフレームの宛先MAC アドレスをキーに、MAC アドレステーブルを参照して転送先ポートを決定するという動作に変わりはありません。

フレームの転送処理をCPU (ソフトウェア)で行うのがブリッジ、ASIC (ハードウェア)で行うのがスイッチ、という認識が一般的です。
処理を行うコンポーネントが違うだけで、本質的に同じものと言えます。

STP の観点からは、ブリッジとスイッチに違いはありません。
本特集では、文脈に不都合が生じない限り、ブリッジに統一します。


    STP を究める 基礎編 の内容は、特に明記しない限り、1998年版のIEEE 802.1D に基づいています。
    Bridge ID、Port ID、Path Cost 値など、IEEE 802.1T で行われた仕様の拡張は、2004年版のIEEE 802.1D に盛り込まれています。
    これらの拡張仕様については、応用編にて説明する予定です。

2006年02月19日

TCAM (Ternary CAM) とBCAM (Binary CAM)

さまざまなメーカから発売されるLAN スイッチのデータシートを見ると、ほとんどの製品がTCAM を実装しているのが分かります。

TCAM (Ternary CAM、ターナリCAM) とは何でしょうか? 従来のCAM と何が違うのでしょうか?

まずは、Ternary の意味を調べて見ましょう。
goo 英和辞書を見ると、

    三つ組の; 三元の; 第三位の; 【コンピュータ】3値の, 3進法の

とあります。
どうやら、キーワードは「三つ」にあるようです。

ディジタルコンピュータが扱うデータを細かくしていくと、最後は0 か1 の二種類の値を表すビットになります。つまりBinary(バイナリ)です。

CAM に格納されるデータはディジタル情報なので、0か1 のどちらかです(バイナリ)。

※ 通常CAM と呼ぶときは、BCAM (Binary CAM) を指します。

TCAM もディジタル情報を扱うので、当然0 と1 です。
では、三つ目は何でしょうか?

答えは、Don't Care (ドントケア)です。
論理回路の勉強をしたことがある人は、聞いたことがあるのではないでしょうか?(ブール代数とかカルノー図とか)
0 と1 の、どちらでも良いことを表す言葉です。言い換えれば、0 or 1です。

つまりTCAM は、検索対象に0、1、Don't Care の3種類の状態が存在するわけです。


Don't Care があると、どんな良いことがあるのでしょうか?

0と1 の2種類しかないと、検索で引っ掛けるためには、検索対象の要素が検索キーと完全に一致する必要があります。
Don't Care は0と1のどちらでも良い値です。つまり、検索する際に無視できるということです。

具体的には、検索対象の要素のうち、無視できる領域を表すマスクで表現します。
マスクと聞いてピンときた人もいますよね?
そうです。サブネットマスクです。

サブネットマスクは、IP アドレスのうち、ネットワーク部を意味する領域の大きさを表現するのに使われます。
マスクされなかった部分はホスト部で、ネットワーク(サブネット)を表現する際には無視される部分です。

TCAM は、Longest Prefix matching (ロンゲストマッチと呼ばれるのが一般的)が必要なテーブル検索に利用されます。
ルーティングテーブルの検索がもっとも多い使用例です。
レイヤ3スイッチの多くがTCAM を採用しているのは、このためです。

これに対してレイヤ2スイッチのMAC アドレステーブルは、TCAM である必要はありません。
MAC アドレスの検索にPrefix を指定する必要は無く、検索対象がキーと完全に一致していることが要求されるためです。

※ 仮に、MAC アドレスの先頭3バイトが00-11-22 というエントリだけを探し出す、というような検索がMAC アドレステーブルに求められるのであれば、TCAM を使うメリットが出てきます。
しかし、MAC アドレステーブルをそのような目的で利用する機能は、現在はありません(今後もないでしょう)。


なぜCisco は、MAC アドレステーブルをCAM と呼ぶのか? も併せてお読みください。

Cisco はなぜ、MAC アドレステーブルをCAM と呼ぶのか?

CatOS で動作しているCatalyst シリーズスイッチでは、MAC アドレステーブルのことをCAM (Content Addressable Memory) と呼んでいます。

CatOS のコマンドプロンプトで、show cam dynamic と実行すると、以下のような結果が得られます。



Catalyst> show cam dynamic

* = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry.
X = Port Security Entry

VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]
---- ------------------ ----- --------------------------------------
1 00-60-5c-86-5b-81 * 4/1 [ALL]
1 00-60-2f-35-48-17 * 4/1 [ALL]
1 00-80-24-f3-47-20 * 1/2 [ALL]
1 00-60-09-78-96-fb * 4/1 [ALL]
1 00-80-24-1d-d9-ed * 1/2 [ALL]
1 00-80-24-1d-da-01 * 1/2 [ALL]
1 08-00-20-7a-63-01 * 4/1 [ALL]

なぜ、MAC アドレスと宛先ポートを格納しているテーブルをCAM と呼ぶのでしょうか?
CAM とは何でしょうか?


端的に言うとCAM は、SRAM などのメモリー上に展開されたテーブルから、目的のエントリーを高速に見つけ出すための手段です。

CAM の効用を理解するためには、まず、CAM ではないテーブル検索手段を見てみる必要があります。

どのような種類のテーブルでも良いのですが、ここはMAC アドレステーブルを例に考えてみましょう。

VLAN をサポートした最近のスイッチでは、さまざまな要素をMAC アドレステーブルに格納しています。
しかし今回は、もっともシンプルに、MAC アドレスとそれに対応するポート番号だけを格納したテーブルを、想定します。

MAC アドレステーブルから引き出したい情報は、そのアドレスが学習されたポートの番号です。
スイッチは、ポート番号を知ることで、そのアドレス宛のフレームを、正しいポートに転送できます。

テーブルから目的のエントリを探し出す一番シンプルな方法は、1行目から順番に見ていくことです。
間違いのない方法ですが、テーブルが大きくなると、どうしても時間がかかります。

実際には、ハッシュを使うなど、さまざまな工夫が施されています。
しかし、CPU により処理されるこれらの検索手段で、検索に要する時間を短縮するのは限界があります。


1980年代の後半、CAM が登場します。

CAM は、先にも述べたとおり、メモリー上のテーブルから目的のエントリーを高速に見つけ出すための手段です。

技術の進歩により製造コストが下がった半導体素子上に、メモリー上のテーブルを検索するための、専用のハードウェアを実装したものがCAM です。
検索エンジンであって、検索対象のテーブルでは無いことに注意してください。

CAM に、キーとなる要素を入力すると、その要素が格納されている、テーブルのアドレスが得られます(今回の例では、要素とはMAC アドレスです)。
アドレスが分かれば、テーブルのその箇所を直接読むことができます。

CAM を利用すると、検索に要する時間は、テーブルの大きさに左右されません。
通常、1クロックで検索が完了します。

CAM の動作を知るには、次のサイトがお勧めです。
英文ですが、それほど難しい表現もありませんし、量も多くありません。
前半だけでもCAM の概要を理解することができます。
後半はトランジスタの動作を理解していないと難しいですが、単純なフリップフロップ回路が理解できる程度の知識があれば、難しくありません。

Content-Addressable Memory Introduction


繰り返しますが、CAM はテーブルではありあません。
それでは、なぜCisco は、MAC アドレステーブルのことをCAM と呼ぶのでしょうか。

これは私見ですが、この命名には、マーケティング目的のバイアスがかかっているのでしょう。

LAN スイッチが登場した1990年代初頭は、半導体製造技術の進歩により製造コストが顕著に低下し始めた時期と一致します。
いえ、安価な半導体素子の存在こそが、LAN スイッチの実現に大きく貢献しているとも言えます。

CAM という新しい技術を採用していることを、アピールする目的があったことが伺えます。

※ もちろん、当時からCAM を採用していたのはCisco(旧Crescendo) だけではありません。

CAM とTCAM (Ternary CAM) も併せてお読みください。

2006年02月18日

STP を究める 基礎編

特集 - STP を究める 基礎編のインデックスページです。


STP を究める 基礎編


STP を究める 基礎編 (1)スパニングツリーとルーティングプロトコル

STP を究める 基礎編 (2)LAN とBridged LAN

STP を究める 基礎編 (3)Bridged LAN の冗長化

STP を究める 基礎編 (4)スパニングツリーの役割

STP を究める 基礎編 (5)Bridge ID とRoot Bridge (ルートブリッジ)

STP を究める 基礎編 (6)Root Path Cost (ルートパスコスト)

STP を究める 基礎編 (1)スパニングツリーとルーティングプロトコル

STP (Spanning Tree Protocol) は、レイヤ2で動作するプロトコルです。

ルーティングプロトコルは、RIP、OSPF などさまざまですが、どれもレイヤ3で動作するプロトコルです。

異なるレイヤで動作する2種類のプロトコル。
何の関連性もないように思えますが、両者をよく観察すると、同じ種類のものであることがわかります。

    「STP とRIP(OSPF)は同じ」

何を馬鹿なことを、と思いますか?


両者はどちらも、機器同士で情報を送り合い、ある物への最短パスを探し出すことを目的としてます。
「ある物」とは、STP ではRoot Bridge(ルートブリッジ)であり、RIP(OSPF) では個々の宛先ネットワーク(サブネット)です。

何を以って「最短」と判断するか。
STP ではRoot Path Cost(ルートパスコスト)であり、RIP やOSPF ではメトリックです。

つまり、対象物(Root Bridge かネットワーク)と判断基準(Root Path Cost かメトリック)が異なるだけで、目的は同じというわけです。

私は、これらのプロトコルを総称して、分散システムの収束アルゴリズムと呼んでいます。


この特集では、STP を究めます。

それでは、STP が動作している機器がどのようにしてRoot Bridge への最短パスを探し出すのか、見ていきましょう。


    STP を究める 基礎編 の内容は、特に明記しない限り、1998年版のIEEE 802.1D に基づいています。
    Bridge ID、Port ID、Path Cost 値など、IEEE 802.1T で行われた仕様の拡張は、2004年版のIEEE 802.1D に盛り込まれています。
    これらの拡張仕様については、応用編にて説明する予定です。

スニってみると

自宅のブロードバンドルータが壊れてしまいました。

どこのルータとは言いませんが、某国産メーカです。
いろいろ切り分けしてみた結果、WAN 側ポートが壊れてしまったようだと、ひとまずの結論です。

この手の小型機器には、Web ベースの管理画面しかないので、どうにも痒いところに手が届きません。
調べれば裏口が見つかるのかもしれませんが、面倒なのでパス。
一万円も出せば新品が買えますからね(ヨドバシカメラのポイントも貯まってるし)。


自宅は、各部屋にRJ45 のアウトレットが取り付けられている、いわゆるインターネットマンションです(死語?)。
建物までは光ケーブルがきており、100Mbps を約50世帯で共有しています。

※ マンション購入時の担当営業君、100メガバイトパーセックと言っていましたが・・・
新しいルータを買うまでの間、どうしてもネットにつなげる必要が生じたので、パソコンを直結しました。
無防備なパソコンを外部ネットに接続すると、20分でウィルスに感染するという報告もありますが、背に腹は替えられません。

用事も済み、これ以上パソコンをネットに晒す必要もなかったのですが、ふと思いつき、Ethereal を立ち上げて、パケットをキャプチャしてみました。


MAC アドレスからは、ルータなのかレイヤ3スイッチなのかはうかがい知れませんが、メジャーな某国産メーカです。

他の世帯とはVLAN で分けてるんでしょう。
数分間、キャプチャできたフレームのMAC アドレスは、ルータと私のパソコンだけでした。

宅配便が届いたのでしばらくそのままにし、10分後に戻ってくると、MAC アドレスの数が増えています。

IEEE Registration Authority で検索してみても、ほとんどは聞いたこともないような台湾メーカです。

パケットの中身を見てみると、見覚えのないMAC アドレスは、全部TCP のSYN です。
宛先ポート番号は、全部80(HTTP)です。

まさかとは思いましたが、他の住戸からのパケットが漏れてきているようです(しかも、SYN だけが)。

ためしに、宛先IP アドレスを直接指定してウェブアクセスしてみると・・・
みなさん、いろんなサイトを見てるんですねぇ・・・お隣の国のカーディーラーのサイト、ネットゲーム。お約束ですが、もちろんアダルトサイトも。

インターネット接続業者のサポートセンターに苦情を言うべきかどうか、迷ってます。
面倒だから。
新しいブロードバンドルータを間に挟めば、見なかったことにできますしね。

これで終わると、単なる日記になってしまうので、ちょっと昔話をしましょう。

今でこそVLAN といえば、ブロードキャストドメインであり、IP を使ってる環境であれば、
VLAN といえばサブネットとほとんど同義に扱われています。

でも、VLAN の概念が出始めのころは、さまざまなコンセプトがありました。
ブロードキャストはVLAN 内に閉じ込められても、ユニキャストはVLAN 越えできるものもありました。
VLAN イコール サブネットと思っているお客が、そんなスイッチを買ってしまって、バグだーっと大騒ぎになることも結構ありました。


新しいブロードバンドルータは、シスコの子会社のリンクシスにしました。
WRT54GS/P-JP

このルータ、家庭向けのくせに、BPDU をしゃべってます。
そのうち、STP (Spanning Tree Protocol) のテストでもしてみましょう。

2006年02月17日

HSRP を究める 基礎編

特集 - HSRP を究める 基礎編のインデックスページです。

HSRP を究める 実践編はこちら
HSRP を究める 応用編はこちら


HSRP を究める 基礎編


HSRP を究める 実践編はこちら
HSRP を究める 応用編はこちら

HSRP を究める 実践編

特集 - HSRP を究める 実践編のインデックスページです。


HSRP を究める 基礎編はこちら
HSRP を究める 応用編はこちら


HSRP を究める 実践編


HSRP を究める 基礎編はこちら
HSRP を究める 応用編はこちら

HSRP を究める 応用編

特集 - HSRP を究める 応用編のインデックスページです。

HSRP を究める 基礎編はこちら
HSRP を究める 実践編はこちら


HSRP を究める 応用編


HSRP を究める 基礎編はこちら
HSRP を究める 実践編はこちら

2006年02月13日

UDLD を究める

特集 - UDLD を究める のインデックスページです。

UDLD を究める


UDLD を究める (1) はじめに

UDLD を究める (2)Bidirectional とUnidirectional

UDLD を究める (3)UDLD とAuto Negotiation

UDLD を究める (4)UDLD の基本動作

UDLD を究める (5)UDLD のパケットフォーマット

UDLD を究める (6)UDLD のタイマー

UDLD を究める (7)Bidirectional State

UDLD を究める (8)Operartional State

UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立

UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する

UDLD を究める(11)UDLD アグレッシブモード

UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性

UDLD を究める(13)設定用コマンド

UDLD を究める(14)show コマンド

UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立

UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する

UDLD を究める(17)UDLD のテスト環境を構築する

UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(1) はじめに

Ethernet などネットワーク機器のポートは、通常、送信と受信の両方が行えることが期待されています。
(例外として、Catalyst6500 や4500でサポートされている、Unidirectional Ethernet という機能があります)

本来送受信ができるはずのポートで、受信または送信しかできなくなると、さまざまなトラブルが発生します。

代表的なものとしては、Spanning Tree Protocol の誤動作によるループがあります。

OSPF など、ルータ間でネイバー関係を構築してからデータをやり取りするルーティングプロトコルであれば、ネイバーがダウンすることで障害を早期に検知することができます。
しかしRIPv1 のように、一方的に経路情報を送るプロトコルの場合、「特定のネットワークとの通信ができない」以外に明示的に障害の発生を示す情報が無く、切り分けが困難です。

Cisco のCatalyst シリーズでサポートされているUDLD (Uni-Directional Link Detection) を使うと、そのような状況を検出し、ポートを閉塞させることで障害の局所化が行えます。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD の状態遷移を時系列でまとめました。

UDLD ノーマルモード

UDLD ノーマルモードの弱点

UDLD アグレッシブモード



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(17)UDLD のテスト環境を構築する

UDLD の試験環境を構築するには、メディアコンバータを使ったり、Cisco 社員しか知りえない方法で行うなど、比較的敷居が高いのが実情です。

Catalyst6500 やCatalyst 4500 でサポートされているUnidirectional Ethernet 機能を利用すると、Catalyst をメディアコンバータの代用とする事が可能になります。
Unidirectional Ethernet 機能は、以下のIOS version からサポートされています。

    Catalyst6500 --- IOS version 12.2(18)SXE
    Catalyst4500 --- IOS version 12.1(13)EW

Unidirectional Ethernet は、IOS version だけではなく、使用するラインカードの種類にも依存します。
詳細はCisco のウェブサイトで確認してください(Command Reference のunidirectioanl コマンドのページに書かれています)。

Catalyst をメディアコンバータの代用とすることには、以下のメリットが考えられます。

    Cisco 製品のみで検証を行う事が出来る
    一度環境を構築してしまえば、遠隔操作で検証を行う事が出来る
    CCO で公開されているIOS コマンドのみを用いて環境を構築できる


Unidirectional Ethernet


Unidirectional Ethernet は、Ethernet Switch を用いて放送型のアプリケーション専用のインフラを実現するための機能です。

通常のEthernet ではFrame は双方向に流れますが、接続される端末の実装が、フレームを受信するのみで送信する事が無い場合、スイッチと端末の間の光ケーブルのペアのうち、使われるのは一本のみとなります(例:スイッチ(TX) --> 端末(RX)) 。

音声データを受信・出力するスピーカ 、監視カメラからの画像を受信・表示し続けるモニター、制御機器からのデータを受信しつづける機器のように、データを送信し続ける、または受信し続けるだけの機器が想定されます。
(例:温度計、モータの回転速度計、地震計、電圧計)




Unidirectional Ethernet の設定は、1000BASE-X ポートでのみ設定可能で、「受信のみを行う(Receive-Only)」若しくは「送信のみを行う(Send-Only)」を選択します。

    interface GigabitEthernet3/1
    switchport access vlan 10
    switchport mode access
    logging event link-status
    speed nonegotiate
    unidirectional receive-only
    no cdp enable

    interface GigabitEthernet3/4
    switchport access vlan 10
    switchport mode access
    logging event link-status
    speed nonegotiate
    unidirectional send-only
    no cdp enable

以下の例では、Catalyst-A のGigabitEthernet0/11(GBIC) とCatalyst-B のGigabitEthernet0/12(GBIC) の間でUDLD を使用する事を想定します。
メディアコンバータの代用には、Catalyst4503 を使っています。
(未確認ですが、おそらくCatalyst4900 でも可能でしょう)

@ 光ケーブルを次のように接続します。

    Catalyst-A (Gi0/11) のTX と、Catalyst4503(Gi3/3)のRX
    Catalyst-A (Gi0/11) のRX と、Catalyst4503(Gi3/4)のTX
    Catalyst-B (Gi0/11) のTX と、Catalyst4503(Gi3/1)のRX
    Catalyst-B (Gi0/11) のRX と、Catalyst4503(Gi3/2)のTX

Catalyst4503 側はGigabit Ethernet が4ポート必要です。
各ポートのTX 若しくはRX のどちらかしか使用しないことに注意して下さい。

A Catalyst4503 でVLAN を次のように設定します。

    Gi3/1、Gi3/4 ----- VLAN 10
    Gi3/2、Gi3/3 ----- VLAN 20

VLAN10、20 のSpanning Tree Protocol を無効にします。
CDP をDisable にします。

B Catalyst4503 の各ポートで、Unidirectional Ethernet を設定します。

    VLAN 10
      Gi3/1 Receive Only
      Gi3/4 Send Only

    VLAN 20
      Gi3/2 Send Only
      Gi3/3 Receive Only

Catalyst-A からCatalyst-B へ向けたフレームは、Catalyst4503 のVLAN20 (Gi3/3 --> Gi3/2) を通過します。

Catalyst-B からCatalyst-A へ向けたフレームは、Catalyst4503 のVLAN10 (Gi3/1 --> Gi3/4) を通過します。

※ Send-only に設定したポーtは、ケーブルを接続しなくてもリンクアップします(LED 緑点灯)。

ここまで完了すると、Catalyst-AとB の間でPing が可能になります。又、Spanning TreeProtocol のBPDU はCatalyst4503 を通過するようになります。

C Catalyst4503 で、次のようなMonitor Session (SPAN) を設定します。

Catalyst4503 では、CDP/UDLD/PAgP 等のプロトコルを無効にしても、受信したフレームを、CPU へ転送してしまいます。
このままでは、Catalyst-A、B の間のUDLD PDU は、Catalyst4503 に吸い上げられてしまい、Bidirectional になりません。

そこで、Catalyst4503 の各VLAN(10、20) で、Receive-only ポート で受信したフレームをSend-Only ポートへコピーするように、MonitorCatalyst4500 では、CDP/UDLD/PAgP 等のプロトコルをDisable にしても、それらのFrame を受信するとCPU へForward |
してしまいます。
このままでは、Catalyst-A/B 間のUDLD Frame はCatalyst4503 に吸い上げられてしまい、Bi-directional になりません。
そこで、Catalyst4503 の各VLAN (10、20) で、Receive-only ポート で受信したFrame をSend-Only ポートへコピーするように、Monitor Session (SPAN) を設定します。

    Monitor Session 1 (VLAN 10)
      Source Gi3/1 (Receive Only)
      Destination Gi3/4 (Send Only)

    Monitor Session 2 (VLAN 20)
      Source Gi3/3 (Receive Only)
      Destination Gi3/2 (Send Only)

このステップを完了すると、Catalyst-A とB の間で、UDLD のState がBidirectional になります。

これでCatalyst4503 の設定は完了です。

C Catalyst-A とB でUDLD の検証を行います。

Catalyst-A とB の間をUni-directional するには、Catalyst4503 のポートのうち、Receive-Only となっている物のどちらか一方をshutdown します。

Send-Only のポートをshutdown してはいけません。
Catalyst-A とB のポートががリンクダウンしてしまうので、UDLD の検証が出来ません。
※ UDLD の試験対象(この例では、Catalyst-A とB) のポートでは"speed nonegotiate" を設定し、Auto-Negotiation をDisable にして下さい。


UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する

debug コマンドを使って、Unidirectional を検知してから、ErrDisable されるまでの流れを見ていきます。

本ページでは、Debug コマンドを使用します。
本ページの内容を実際に試される場合は、事前に「Debug コマンドについて」をお読みください。



Catalyst#debug udld events
UDLD events debugging is on
Catalyst#debug udld packets
UDLD packets debugging is on
Catalyst#

ログ中の色づけされた16進数は、以下のとおりです。



    Device ID
    Port ID
    Echo
    Message Interval
    Flags

Catalyst-A

Bidirectional になっています。



*Mar 17 03:56:00: allNeighborsAgedOutEvent during link up. (Gi0/11) @
*Mar 17 03:56:00: Phase set from ADV to LUP because all neighbors aged out (Gi0/11) A
*Mar 17 03:56:00: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11) B
*Mar 17 03:56:00: Pr (Gi0/11)
*Mar 17 03:56:00: prev = 0 entry = 1141168 next = 0 exp_time = 0 (Gi0/11)
*Mar 17 03:56:00: udsb->cache = 0xDCA128 (Gi0/11)
*Mar 17 03:56:00: timeout timer = 7 (Gi0/11)
*Mar 17 03:56:00: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 17 03:56:00: Pr (Gi0/11)
*Mar 17 03:56:01: timeout timer = 6 (Gi0/11)
*Mar 17 03:56:01: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 17 03:56:01: Pr (Gi0/11)
*Mar 17 03:56:02: timeout timer = 5 (Gi0/11)
*Mar 17 03:56:02: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 17 03:56:02: Pr (Gi0/11)

@ 対向機器からUDLD PDU を受信しなくなり、エントリーをテーブルから消去しました。
A Link Up フェイズへ移行しました。
B 空のEcho TLV を持ったProbe を送信し始めます。 Recommended Timeout フラグとReSynch フラグが立っています。

Catalyst-B



*Mar 17 03:56:00: udld process packet received, length 99 (Gi0/12) @
*Mar 17 03:56:00: 21 03 6E 0A 00 01 00 0F 46 41 41 30 35 34 39 53 30 41 54 00
*Mar 17 03:56:00: 02 00 0A 47 69 30 2F 31 31 00 03 00 08 00 00 00 00 00 04 00
*Mar 17 03:56:00: 05 07 00 05 00 05 05 00 06 00 16 43 61 74 61 6C 79 73 74 33
*Mar 17 03:56:00: 35 35 30 2D 31 32 54 3A 41 00 07 00 08 00 00 00 54
*Mar 17 03:56:00: TLV = 1 TLV length = 15 (Gi0/12)
*Mar 17 03:56:00: item_len[1] = 12 (Gi0/12)
*Mar 17 03:56:00: Bytes left = 58 (Gi0/12)
*Mar 17 03:56:00: TLV = 2 TLV length = 10 (Gi0/12)
*Mar 17 03:56:00: item_len[2] = 7 (Gi0/12)
*Mar 17 03:56:00: Bytes left = 48 (Gi0/12)
*Mar 17 03:56:00: TLV = 3 TLV length = 8 (Gi0/12)
*Mar 17 03:56:00: Bytes left = 40 (Gi0/12)
*Mar 17 03:56:00: TLV = 4 TLV length = 5 (Gi0/12)
*Mar 17 03:56:00: item_len[4] = 1 (Gi0/12)
*Mar 17 03:56:00: Bytes left = 35 (Gi0/12)
*Mar 17 03:56:00: TLV = 5 TLV length = 5 (Gi0/12)
*Mar 17 03:56:00: item_len[5] = 1 (Gi0/12)
*Mar 17 03:56:00: Bytes left = 30 (Gi0/12)
*Mar 17 03:56:00: TLV = 6 TLV length = 22 (Gi0/12)
*Mar 17 03:56:00: item_len[6] = 19 (Gi0/12)
*Mar 17 03:56:00: Bytes left = 8 (Gi0/12)
*Mar 17 03:56:00: TLV = 7 TLV length = 8 (Gi0/12)
*Mar 17 03:56:00: item_len[7] = 4 (Gi0/12)
*Mar 17 03:56:00: Bytes left = 0 (Gi0/12)
*Mar 17 03:56:00: Parse packet info and insert entry (0xDB6840) into cache. (Gi0/12)
*Mar 17 03:56:00: Cached TLV #1 = FAA0549S0AT, length = 11 (Gi0/12)
*Mar 17 03:56:00: Cached TLV #2 = Gi0/11, length = 6 (Gi0/12)
*Mar 17 03:56:00: udld_handle_bidirdetect_info (Gi0/12)
*Mar 17 03:56:00: udld_handle_bidirdetect_info pairs = 0 (Gi0/12)
*Mar 17 03:56:00: Cached TLV #4 = 7, length = 0 (Gi0/12)
*Mar 17 03:56:00: Cached TLV #5 = 5, length = 0 (Gi0/12)
*Mar 17 03:56:00: Cached TLV #6 = Catalyst3550-12T:A, length = 18 (Gi0/12)
*Mar 17 03:56:00: Cached TLV #7, val = 3 length = 84 (Gi0/12)
*Mar 17 03:56:00: New_entry = DB6840 (Gi0/12)
*Mar 17 03:56:00: Found an entry from same device (Gi0/12)
*Mar 17 03:56:00: Cached entries = 2 (Gi0/12)
*Mar 17 03:56:00: Entry (0xDA873C) deleted: 1 entries cached
*Mar 17 03:56:00: Cached entries = 1 (Gi0/12)
*Mar 17 03:56:00: Probe packet(resynch) (Gi0/12)
*Mar 17 03:56:00: Zero IDs in 2way conn list (Gi0/12)
*Mar 17 03:56:00: Doing neighbor scanning after bidir->non-bidir transition. (Gi0/12)
*Mar 17 03:56:00: Bidir->all unidir => DET. (Gi0/12)
*Mar 17 03:56:00: RSY neighbor (Gi0/12)
*Mar 17 03:56:00: Udld entering detection phase. (Gi0/12)
*Mar 17 03:56:00: UDLD send echo message, flags = 0 (Gi0/12)
*Mar 17 03:56:00: E (Gi0/12)
*Mar 17 03:56:00: Zero IDs in 2way conn list (Gi0/12)
*Mar 17 03:56:00: Zero IDs in 2way conn list (Gi0/12)
*Mar 17 03:56:00: UDLD FSM updated port, bi-flag udld_empty_echo, phase udld_detection (Gi0/12)B
*Mar 17 03:56:00: Udld receive packet *END*. (Gi0/12)A
(中略)
*Mar 17 03:56:05: confirmation recv'd in EXT (Gi0/12) C
*Mar 17 03:56:05: UDLD disabled port, packet received in extended detection (Gi0/12)
*Mar 17 03:56:05: UDLD send flush message, flags = 0 (Gi0/12) D
*Mar 17 03:56:05: F (Gi0/12)
*Mar 17 03:56:05: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi0/12, unidirectional link detected E
*Mar 17 03:56:05: %PM-4-ERR_DISABLE: udld error detected on Gi0/12, putting Gi0/12 in err-disable state
*Mar 17 03:56:05: Port UDLD set error disabled (Gi0/12)
*Mar 17 03:56:05: Entry (0xDB6840) deleted: 0 entries cached
*Mar 17 03:56:05: Hash entry deleted = DB6840 (Gi0/12)
*Mar 17 03:56:05: current phase = udld_disable_port (Gi0/12)
*Mar 17 03:56:05: Restart counter = 0 (Gi0/12)
*Mar 17 03:56:05: Neighbors counter = 0 (Gi0/12)
*Mar 17 03:56:05: Udld receive packet *END*. (Gi0/12)
*Mar 17 03:56:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/12, changed state to down
*Mar 17 03:56:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar 17 03:56:20: %LINK-3-UPDOWN: Interface GigabitEthernet0/12, changed state to down

@ Catalyst-A から、Echo TLV が空のUDLD PDU を、GigabitEthernet0/12 で受信しました(Catalyst-A ログのBのフレームです)。
Recommended Timeout フラグとReSynch フラグが立っています。
A ここまでが一つのUDLD PDU です。
B Detection フェイズへ移行しました。
C 拡張ディテクションウィンドウが始まった直後に、空のEcho TLV を持ったProbe を受信しました。
D Flush を送信しました。 F はFlush を意味します。
E GigabitEthernet0/12 をErrDisable にしました。


アグレッシブモードの場合はどうでしょうか。

Catalyst-A

Bidirectional になっています。



*Mar 19 19:16:12: allNeighborsAgedOutEvent during link up. (Gi0/11) @
*Mar 19 19:16:12: Phase set from ADV to LUP because all neighbors aged out (Gi0/11) A
*Mar 19 19:16:12: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11) B
*Mar 19 19:16:12: Pr (Gi0/11)
*Mar 19 19:16:12: prev = 0 entry = 11E588C next = 0 exp_time = 0 (Gi0/11)
*Mar 19 19:16:12: udsb->cache = 0xDCA128 (Gi0/11)
*Mar 19 19:16:12: timeout timer = 7 (Gi0/11)
*Mar 19 19:16:12: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 19 19:16:12: Pr (Gi0/11)
*Mar 19 19:16:13: timeout timer = 6 (Gi0/11)
*Mar 19 19:16:13: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 19 19:16:13: Pr (Gi0/11)
*Mar 19 19:16:14: timeout timer = 5 (Gi0/11)
*Mar 19 19:16:14: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 19 19:16:14: Pr (Gi0/11)
*Mar 19 19:16:15: timeout timer = 4 (Gi0/11)
*Mar 19 19:16:15: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 19 19:16:15: Pr (Gi0/11)
*Mar 19 19:16:16: timeout timer = 3 (Gi0/11)
*Mar 19 19:16:16: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 19 19:16:16: Pr (Gi0/11)
*Mar 19 19:16:17: timeout timer = 2 (Gi0/11)
*Mar 19 19:16:17: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 19 19:16:17: Pr (Gi0/11)
*Mar 19 19:16:18: timeout timer = 1 (Gi0/11)
*Mar 19 19:16:18: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 19 19:16:18: Pr (Gi0/11)
*Mar 19 19:16:19: timeout timer = 0 (Gi0/11) C
*Mar 19 19:16:19: Phase set to udld_advertisement from phase udld_link_up in aggresive mode after all neighbors aged out. (Gi0/11)
*Mar 19 19:16:19: UDLD send flush message, flags = 0 (Gi0/11) D
*Mar 19 19:16:19: F (Gi0/11)
*Mar 19 19:16:19: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi0/11, aggressive mode failure detected E
*Mar 19 19:16:19: %PM-4-ERR_DISABLE: udld error detected on Gi0/11, putting Gi0/11 in err-disable state
*Mar 19 19:16:19: Port UDLD set error disabled (Gi0/11)
*Mar 19 19:16:19: Phase set to udld_advertisement after timer_expired. (Gi0/11)
*Mar 19 19:16:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/11, changed state to down
*Mar 19 19:16:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar 19 19:16:21: %LINK-3-UPDOWN: Interface GigabitEthernet0/11, changed state to down

@ 対向機器からUDLD PDU を受信しなくなり、エントリーをテーブルから消去しました。
A Link Up フェイズへ移行しました。
B 空のEcho TLV を持ったProbe を送信し始めます。 Recommended Timeout フラグとReSynch フラグが立っています。
C 空のEcho TLV を持ったProbe を8回送信し終わりました。
D Flush を送信しました。
E GigabitEthernet0/11 をErrDisable にしました。


UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立

debug コマンドを使って、ポートがリンクアップしてから、Bidirectional となるまでの流れを見ていきます。

本ページでは、Debug コマンドを使用します。
本ページの内容を実際に試される場合は、事前に「Debug コマンドについて」をお読みください。



Catalyst#debug udld events
UDLD events debugging is on
Catalyst#debug udld packets
UDLD packets debugging is on
Catalyst#

ログ中の色づけされた16進数は、以下のとおりです。


    Device ID
    Port ID
    Echo
    Message Interval

Catalyst-A

リンクアップしました。



*Mar 5 22:04:53: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)@
*Mar 5 22:04:53: Pr (Gi0/11)
*Mar 5 22:04:54: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 5 22:04:54: Pr (Gi0/11)
*Mar 5 22:04:55: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 5 22:04:55: Pr (Gi0/11)
*Mar 5 22:04:56: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 5 22:04:56: Pr (Gi0/11)
*Mar 5 22:04:57: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 5 22:04:57: Pr (Gi0/11)
*Mar 5 22:04:58: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 5 22:04:58: Pr (Gi0/11)
*Mar 5 22:04:59: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 5 22:04:59: Pr (Gi0/11)
*Mar 5 22:05:00: UDLD send probe message, flags = rec_timeout | resynch (Gi0/11)
*Mar 5 22:05:00: Pr (Gi0/11)
*Mar 5 22:05:01: UDLD send probe message, flags = rec_timeout (Gi0/11)A
*Mar 5 22:05:01: P (Gi0/11)
*Mar 5 22:05:08: UDLD send probe message, flags = rec_timeout (Gi0/11)
*Mar 5 22:05:08: P (Gi0/11)
*Mar 5 22:05:15: UDLD send probe message, flags = rec_timeout (Gi0/11)
*Mar 5 22:05:15: P (Gi0/11)
*Mar 5 22:05:22: UDLD send probe message, flags = rec_timeout (Gi0/11)
*Mar 5 22:05:22: P (Gi0/11)
*Mar 5 22:05:29: UDLD send probe message, flags = rec_timeout (Gi0/11)
*Mar 5 22:05:29: P (Gi0/11)
*Mar 5 22:05:36: UDLD send probe message, flags = rec_timeout (Gi0/11)
*Mar 5 22:05:36: P (Gi0/11)
*Mar 5 22:05:43: UDLD send probe message, flags = rec_timeout (Gi0/11)
(中略)
*Mar 5 22:06:49: udld process packet received, length 99 (Gi0/11)B
*Mar 5 22:06:49: 21 01 62 47 00 01 00 0F 43 48 4B 30 36 31 39 57 30 4D 55 00
*Mar 5 22:06:49: 02 00 0A 47 69 30 2F 31 32 00 03 00 08 00 00 00 00 00 04 00 C
*Mar 5 22:06:49: 05 07 00 05 00 05 05 00 06 00 16 43 61 74 61 6C 79 73 74 33
*Mar 5 22:06:49: 35 35 30 2D 31 32 54 3A 43 00 07 00 08 00 00 00 05
*Mar 5 22:06:49: TLV = 1 TLV length = 15 (Gi0/11)
*Mar 5 22:06:49: item_len[1] = 12 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 58 (Gi0/11)
*Mar 5 22:06:49: TLV = 2 TLV length = 10 (Gi0/11)
*Mar 5 22:06:49: item_len[2] = 7 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 48 (Gi0/11)
*Mar 5 22:06:49: TLV = 3 TLV length = 8 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 40 (Gi0/11)
*Mar 5 22:06:49: TLV = 4 TLV length = 5 (Gi0/11)
*Mar 5 22:06:49: item_len[4] = 1 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 35 (Gi0/11)
*Mar 5 22:06:49: TLV = 5 TLV length = 5 (Gi0/11)
*Mar 5 22:06:49: item_len[5] = 1 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 30 (Gi0/11)
*Mar 5 22:06:49: TLV = 6 TLV length = 22 (Gi0/11)
*Mar 5 22:06:49: item_len[6] = 19 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 8 (Gi0/11)
*Mar 5 22:06:49: TLV = 7 TLV length = 8 (Gi0/11)
*Mar 5 22:06:49: item_len[7] = 4 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 0 (Gi0/11)
*Mar 5 22:06:49: Parse packet info and insert entry (0xD8BA50) into cache. (Gi0/11)
*Mar 5 22:06:49: Cached TLV #1 = CHK0619W0MU, length = 11 (Gi0/11)
*Mar 5 22:06:49: Cached TLV #2 = Gi0/12, length = 6 (Gi0/11)
*Mar 5 22:06:49: udld_handle_bidirdetect_info (Gi0/11)
*Mar 5 22:06:49: udld_handle_bidirdetect_info pairs = 0 (Gi0/11)
*Mar 5 22:06:49: Cached TLV #4 = 7, length = 0 (Gi0/11)
*Mar 5 22:06:49: Cached TLV #5 = 5, length = 0 (Gi0/11)
*Mar 5 22:06:49: Cached TLV #6 = Catalyst3550-12T:C, length = 18 (Gi0/11)
*Mar 5 22:06:49: Cached TLV #7, val = 3 length = 5 (Gi0/11)
*Mar 5 22:06:49: New_entry = D8BA50 (Gi0/11)
*Mar 5 22:06:49: Device Index = 1 (Gi0/11)
*Mar 5 22:06:49: First entry (Gi0/11)
*Mar 5 22:06:49: Probe packet (Gi0/11)
*Mar 5 22:06:49: Zero IDs in 2way conn list (Gi0/11)
*Mar 5 22:06:49: Non-RSY new neighbor (Gi0/11)
*Mar 5 22:06:49: Udld entering detection phase. (Gi0/11)
*Mar 5 22:06:49: UDLD send echo message, flags = 0 (Gi0/11)
*Mar 5 22:06:49: E (Gi0/11) D
*Mar 5 22:06:49: Zero IDs in 2way conn list (Gi0/11)
*Mar 5 22:06:49: Zero IDs in 2way conn list (Gi0/11)
*Mar 5 22:06:49: UDLD FSM updated port, bi-flag udld_empty_echo, phase udld_detection (Gi0/11) E
*Mar 5 22:06:49: Udld receive packet *END*. (Gi0/11)
*Mar 5 22:06:49: udld process packet received, length 120 (Gi0/11) F
*Mar 5 22:06:49: 22 00 C9 95 00 01 00 0F 43 48 4B 30 36 31 39 57 30 4D 55 00
*Mar 5 22:06:49: 02 00 0A 47 69 30 2F 31 32 00 03 00 1D 00 00 00 01 00 0B 46
*Mar 5 22:06:49: 41 41 30 35 34 39 53 30 41 54 00 06 47 69 30 2F 31 31 00 04
*Mar 5 22:06:49: 00 05 07 00 05 00 05 05 00 06 00 16 43 61 74 61 6C 79 73 74
*Mar 5 22:06:49: 33 35 35 30 2D 31 32 54 3A 43 00 07 00 08 00 00 00 01
*Mar 5 22:06:49: TLV = 1 TLV length = 15 (Gi0/11)
*Mar 5 22:06:49: item_len[1] = 12 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 79 (Gi0/11)
*Mar 5 22:06:49: TLV = 2 TLV length = 10 (Gi0/11)
*Mar 5 22:06:49: item_len[2] = 7 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 69 (Gi0/11)
*Mar 5 22:06:49: TLV = 3 TLV length = 29 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 40 (Gi0/11)
*Mar 5 22:06:49: TLV = 4 TLV length = 5 (Gi0/11)
*Mar 5 22:06:49: item_len[4] = 1 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 35 (Gi0/11)
*Mar 5 22:06:49: TLV = 5 TLV length = 5 (Gi0/11)
*Mar 5 22:06:49: item_len[5] = 1 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 30 (Gi0/11)
*Mar 5 22:06:49: TLV = 6 TLV length = 22 (Gi0/11)
*Mar 5 22:06:49: item_len[6] = 19 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 8 (Gi0/11)
*Mar 5 22:06:49: TLV = 7 TLV length = 8 (Gi0/11)
*Mar 5 22:06:49: item_len[7] = 4 (Gi0/11)
*Mar 5 22:06:49: Bytes left = 0 (Gi0/11)
*Mar 5 22:06:49: Parse packet info and insert entry (0x1141168) into cache. (Gi0/11)
*Mar 5 22:06:49: Cached TLV #1 = CHK0619W0MU, length = 11 (Gi0/11)
*Mar 5 22:06:49: Cached TLV #2 = Gi0/12, length = 6 (Gi0/11)
*Mar 5 22:06:49: udld_handle_bidirdetect_info (Gi0/11)
*Mar 5 22:06:49: udld_handle_bidirdetect_info pair left = 1 (Gi0/11)
*Mar 5 22:06:49: FAA0549S0AT device (Gi0/11)
*Mar 5 22:06:49: udld_handle_bidirdetect_info: good packet (Gi0/11)
*Mar 5 22:06:49: Cached TLV #4 = 7, length = 0 (Gi0/11)
*Mar 5 22:06:49: Cached TLV #5 = 5, length = 0 (Gi0/11)
*Mar 5 22:06:49: Cached TLV #6 = Catalyst3550-12T:C, length = 18 (Gi0/11)
*Mar 5 22:06:49: Cached TLV #7, val = 3 length = 1 (Gi0/11)
*Mar 5 22:06:49: New_entry = 1141168 (Gi0/11)
*Mar 5 22:06:49: Found an entry from same device (Gi0/11)
*Mar 5 22:06:49: Cached entries = 2 (Gi0/11)
*Mar 5 22:06:49: Entry (0xD8BA50) deleted: 1 entries cached
*Mar 5 22:06:49: Cached entries = 1 (Gi0/11)
*Mar 5 22:06:49: Echo packet (Gi0/11)
*Mar 5 22:06:49: Checking if multiple neighbors (Gi0/11)
*Mar 5 22:06:49: Single neighbor detected (Gi0/11)
*Mar 5 22:06:49: Checking if link is bidirectional (Gi0/11)
*Mar 5 22:06:49: Found my own ID pair in 2way conn list (Gi0/11)
*Mar 5 22:06:49: Checking if multiple neighbors (Gi0/11)
*Mar 5 22:06:49: Single neighbor detected (Gi0/11)
*Mar 5 22:06:49: Checking if link is bidirectional (Gi0/11)
*Mar 5 22:06:49: Found my own ID pair in 2way conn list (Gi0/11)
*Mar 5 22:06:49: UDLD FSM updated port, bi-flag udld_bidir_detected, phase udld_detection (Gi0/11)H
*Mar 5 22:06:49: Udld receive packet *END*. (Gi0/11)
*Mar 5 22:06:50: timeout timer = 4 (Gi0/11)
*Mar 5 22:06:50: UDLD send echo message, flags = 0 (Gi0/11)
*Mar 5 22:06:50: E (Gi0/11)G
(中略)
*Mar 5 22:06:54: Phase set to udld_advertisement from phase udld_detection. (Gi0/11)I
*Mar 5 22:06:54: Phase set to udld_advertisement after timer_expired. (Gi0/11)


@ 1秒間隔で、Probe を送信しています。 Recommended Timeout とReSynch フラグがセットされています。Pr はProbe を意味します。
A 8秒経過すると、以後のProbe はRe-Synch フラグをリセットし、7秒間隔で送信されます。
B 対向機器からのUDLD PDU をGigabitEthernet0/11 で受信しました。
C Echo TLV は空
D ここまでが一つのUDLD PDU です。E はEcho を意味します。
E Detection フェイズへ移行します。
F 次のUDLD PDU を受信しました。Echo TLV から、対向機器が自分のUDLD PDU を受信できていることがわかります(対向機器もDetection フェイズへ移行しているはずです)。
Message Interval は7になっています。
G ここまでが一つのUDLD PDU です。E はEcho を意味します。
H Bidirectional になりました。
I Advertisement フェイズへ移行します。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(14)show コマンド

UDLD 関連のshow コマンド一覧です。

Catalyst の機能は、機種やIOS のトレインによって、サポート状況やコマンドのフォーマットが微妙に異なる場合があります。
サポート状況は、Cisco Systems のウェブサイトで確認してください。


show udld [Interface Name | neighbors]

UDLD の状態、各種パラメータやタイマーを表示します。

    Interface Name
    特定のインターフェイス上のUDLD 情報のみ表示する場合に指定します。
    省略した場合は、全てのインターフェイス上のUDLD 情報が表示されます。

    neighbors
    出力を簡略化します。

show udld の出力例



Catalyst-A#show udld gigabitethernet0/11

Interface Gi0/11
---
Port enable administrative configuration setting: Enabled @
Port enable operational state: Enabled A
Current bidirectional state: Bidirectional B
Current operational state: Advertisement - Single neighbor detected C
Message interval: 15 D
Time out interval: 5 E

Entry 1 F
---
Expiration time: 21
Device ID: 1
Current neighbor state: Bidirectional G
Device name: CHK0619W0MU H
Port ID: Gi0/12 I
Neighbor echo 1 device: FAA0549S0AT J
Neighbor echo 1 port: Gi0/11 K

Message interval: 10 L
Time out interval: 5 M
CDP Device name: Catalyst-B N
Catalyst-A#

    @ Catalyst 全体のUDLD の設定状況(Enabled/Disabled)
    A ポートのUDLD の設定状況(Enabled/Disabled)
    B UDLD State (Bidirectional/Unidirectiona/Undetermined)
    C Operational State(Inactive/Link Up/Detection/Advertisement)
    D 自分に設定されているMessage Interval
    E Timout Interval (5秒固定)
    F 対向機器の情報
    G UDLD State (Bidirectional/Unidirectiona/Undetermined)
    H 対向機器のDevice ID
    I 対向機器のPort ID
    J 対向機器のUDLD PDU から抽出した、自分のDevice ID
    K 対向機器のUDLD PDU から抽出した、自分のPort ID
    L 対向機器に設定されているMessage Interval
    M 対向機器のTimeout Interval (5秒固定)
    N 対向機器のDevice Name (hostname)

show udld neighbors の出力例



Catalyst-A# show udld neighbors

Port Device Name Device ID Port-ID OperState
-------- ------------------------------ ------------ ------- --------------
Gi3/1 SAL0734K5R2 1 Gi4/1 Bidirectional
Gi4/1 SAL0734K5R2 1 Gi3/1 Bidirectional
Catalyst#



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(13)設定用コマンド

UDLD 関連のコマンド一覧です。


    udld enable
    udld aggressive
    udld message time
    udld reset


Catalyst の機能は、機種やIOS のトレインによって、サポート状況やコマンドのフォーマットが微妙に異なる場合があります。
サポート状況は、Cisco Systems のウェブサイトで確認してください。


[no] udld [enable | aggressive]

UDLD 有効、または無効にします。

    enable
    UDLD を有効にします。

    aggressive
    アグレッシブモードを有効にします。指定しない場合は、ノーマルモードで動作します

コマンドの先頭にno を付けると、設定を削除できます。



[no] udld message time [Value]

Message Interval を設定します。

    Value
    UDLD PDU を送信する間隔を秒で指定します。デフォルトは15です(7から90の間で設定可能)。

コマンドの先頭にno を付けると、設定を削除できます。



udld reset

ErrDisable となったポートを復旧させます。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性

UDLD ノーマルモードとアグレッシブモードの間に、大きな実装の違いはありません。
異なるのは、Unidirectional と判断するための条件だけです

このページでお話する内容は、Cisco により正式サポートされているか不明です。

繰り返しますが、両モードの違いは、Unidirectional と判断するための条件だけです。
送信するUDLD PDU のフォーマットも同じであり、パラメータの解釈の仕方も同じです。

つまり、ノーマルモードのCatalyst と、アグレッシブモードのCatalyst の間で、UDLD は正常に動作します。

実際に、ノーマルモードしかサポートしていないCatalyst3500XL と、アグレッシブモードのCatalyst3550 とで、UDLD が正常に動作することが確認できました。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(11)UDLD アグレッシブモード

これまで見てきたUDLD は、ノーマルモードと呼びます。

UDLD ノーマルモードでは、ポートが受信も送信もできなくなった場合はUniDirectional を検知できないという欠点がありました。

UDLD アグレッシブモードでは、Link Up フェイズに移行したCatalyst-A が、1秒間隔でProbe を8秒間送信する間に、Catalyst-B からのUDLD PDU を受信しないと、即座にFlush を送信し、ポートをErrDisable にします。

アグレッシブモードの場合、Unidrectional と判断するための条件がLink Up フェイズに移行後、8回のProbe 送信が完了後も、対向機器からUDLD PDU を受信できないことなので、送信・受信の両方ができない状態にも対処可能です。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する

一旦Bidirectional になった後、Unidirectional を検知するまでを見ていきます。

Advertisement フェイズ

受信するUDPD PDU に、自分の情報が無くなってから45秒(対向機器から通知されるMessage Interval の3倍)経過すると、学習していた対向機器の情報を削除し(Age Out)、Link Up フェイズへ移行します。

上図では、Catalyst-A は、Catalyst-B からのProbe を受信できなくなりました。

Link Up フェイズ(Catalyst-A)

Catalyst-A がLink Up フェイズへ移行すると、空のEcho TLV を持ったProbe を、1秒間隔で送信し始めます。

Catalyst-B は、まだAdvertisement フェイズです。

このときのUDLD PDU に含まれる内容は以下のとおりです。

Catalyst-A

    Opcode = 00001 (Probe)
    RT bit = 1
    RSY bit = 1
    Device ID TLV = 自分のDevice ID
    Port ID TLV = このUDLD PDU を送信しているポートの番号
    Echo TLV = 空
    Message Interval = 7
    Timeout Interval = 5
    Device Name TLV = 自分に設定されたhostname

Catalyst-B

    Opcode = 00001 (Probe)
    RT bit = 1
    RSY bit = 0
    Device ID TLV = 自分のDevice ID
    Port ID TLV = このUDLD PDU を送信しているポートの番号
    Echo TLV = 受信したUDLD PDU から抽出したDevice ID/Port ID (Catalyst-A)
    Message Interval = 15
    Timeout Interval = 5
    Device Name TLV = 自分に設定されたhostname

Catalyst-A から、空のEcho TLV を持ったProbe を受信し始めると、Catalyst-B はDetection フェイズへ移行します。


Detection フェイズ(Catalyst-B)

Catalyst-B がDetection フェイズへ移行すると、Catalyst-A との間のフレーム到達性確認をはじめます(ディテクションウィンドウ)。

Catalyst-A がUDLD PDU を受信できない今の状態で、Catalyst-A から送られてくるUDLD PDU のEcho TLV に、自分の情報が格納されることはありえませんので、5秒後、ディテクションウィンドウが終了し、拡張ディテクションウィンドウが開始されます。

Catalyst-A からは、空のEcho TLV を持ったUDLD PDU を受信し続けているので、拡張ディテクションウィンドウが始まるとUnidirectional と判断され、Catalyst-B はFlush を送信し、ポートをErrDisableにします。

Catalyst-B の側でErrDisable となると、Catalyst-A のポートはリンクダウンします。


Catalyst-A が積極的にポートをErrDisable としないのは、UDLD PDU の未達が一時的な物である可能性を考慮し、復旧可能な場合を想定しているからです。

UniDirectional と判断するための条件が、拡張ディテクションウィンドウ中に、空のEcho TLV を持ったUDLD PDU を対向機器から受信することである点に注意してください。
Catalyst-Bのポートが受信も送信もできなくなった場合は、両方のCatalyst がLink Up フェイズにとどまり続けることとなり、UniDirectional を検知する事はできません。

この欠点を解消したのが、UDLD アグレッシブモード です。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立

ポートがリンクアップしてから、Bidirectional となるまでの流れを見ていきます。

UDLD ネイバー関係の確立

Link Up フェイズ


ポートがリンクアップすると、1秒間隔でProbe(Hello、Advertisement) を送信し始めます。

このときのUDLD PDU に含まれる内容は以下のとおりです。

Catalyst-A、B ともに

    Opcode = 00001 (Probe)
    RT bit = 1
    RSY bit = 1
    Device ID TLV = 自分のDevice ID
    Port ID TLV = このUDLD PDU を送信しているポートの番号
    Echo TLV = 空
    Message Interval = 7
    Timeout Interval = 5
    Device Name TLV = 自分に設定されたhostname

8回Probe を送信するまでの間に(8秒間)、対向機器からのUDLD PDU を受信できない場合、以後は7秒間隔でProbe の送信を続けます。
(Probe のフォーマットは、RSY ビットが0となる以外は、1秒間隔の時と同じです)

対向機器からUDLD PDU を受信すると、Detection フェイズへ移行します。


Detection フェイズ


Detection フェイズに移行すると、5秒間(Timeout Interval)、Echo を1秒間隔で送信します。

この5秒間をディテクションウィンドウと呼び、この間に、自分の情報が格納されているEcho を対向機器から受信することが期待されます。

このときのUDLD PDU に含まれる内容は以下のとおりです。

Catalyst-A、B ともに

    Opcode = 00010 (Echo)
    RT bit = 1
    RSY bit = 0
    Device ID TLV = 自分のDevice ID
    Port ID TLV = このUDLD PDU を送信しているポートの番号
    Echo TLV = 受信したUDLD PDU から抽出したDevice ID/Port ID
    Message Interval = 7
    Timeout Interval = 5
    Device Name TLV = 自分に設定されたhostname

ディテクションウィンドウの間に、自分の情報がEcho TLV に格納されているUDLD PDU を受信すると、UDLD State をBiDirectional とし、Advertisement フェイズへ移行します。

受信したEcho TLV に自分の情報が格納されているということは、送信したUDLD PDU が対向機器に到達できている事を意味し、フレームが送受信ともに正常であるとみなされます。

ディテクションウィンドウの間に、自分の情報がEcho TLV に格納されているUDLD PDU を対向機器から受信できない場合、拡張ディテクションウィンドウ(Extended Detection Window)が開始され、以後はProbe をMessage Interval (= 7秒)の間隔で送信します。

拡張ディテクションウィンドウの間に空のEcho TLV を持つUDLD PDU を対向機器から受信すると、UniDirectionalであると判断し、Flush を送信の後そのポートをErrDisable とします

通常は、リンクアップ直後に拡張ディテクションウィンドウが始まることはなく、Advertisement フェイズへ移行します。
拡張ディテクションウィンドウが必要になるのは、一旦Bidirectional となってから、不具合を検知するときです。


Advertisement フェイズ


UDLD State がBidirectional になると、Advertisement フェイズへ移行します。
以後は、自分に設定されたMessage Interval(デフォルトは15秒)の間隔で、Probe を送信し続けます。

このときのUDLD PDU に含まれる内容は以下のとおりです。

Catalyst-A、B ともに

    Opcode = 00001 (Probe)
    RT bit = 1
    RSY bit = 0
    Device ID TLV = 自分のDevice ID
    Port ID TLV = このUDLD PDU を送信しているポートの番号
    Echo TLV = 受信したUDLD PDU から抽出したDevice ID/Port ID
    Message Interval = 15
    Timeout Interval = 5
    Device Name TLV = 自分に設定されたhostname



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める (8)Operartional State

UDLD のステートマシン内のフェイズをOperational State と呼びます。

Operational State(フェイズ) には、以下の4種類があります。


  1. Inactive

  2. Link Up

  3. Detection

  4. Advertisement


Inactive

UDLD が無効となっているか、ポートがダウンしている状態です。

Link Up

ポートがアップして、まだ一つもUDLD PDU を受信していない状態です。

Detection

対向機器からUDLD PDU を受信して、Bidirectional となるまでの状態です。

Advertisement

対向機器との間で、Bidirectional が確立した状態です。
安定動作中はこのフェイズに留まります。

本サイトでは、UDLD Phase と言った場合、Operational State を指すものとします。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める (7)Bidirectional State

UDLD の稼動状況を意味するState を、Bidirectional State と呼びます。

Bidirectional State は、3種類あります。

Bidirectional

対向機器との間でBidirectional となっている状態です。

Unidirectional

対向機器との間でUnidirectional が検出された状態です。

Undetermined

対向機器からUDPD PDU を受け取っていないか、受け取った後Bidirectional となるまでの一時的な状態です。


本サイトでは、UDLD State と言った場合、Bidirectional State を指すものとします。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める (6)UDLD のタイマー

UDLD が正常に動作するため、二つのタイマーが定義されています。

Message Interval

UDLD PDU を送信する間隔です。
デフォルトは60秒です。1から90秒の間で設定可能です。

Timeout Interval

ディテクションウィンドウの長さです。
5秒固定で、変更はできません。

ディテクションウィンドウは、対向機器から初めてUDLD PDU を受信してから、Bidirectional となるまでに許容される間隔(秒)です。

詳細は、アルゴリズムのページで説明します。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める (5)UDLD のフレームフォーマット

UDLD のフレームフォーマットです。


_______________________________


IEEE 802.3


宛先MAC アドレスは、CDP (Cisco Discovery Protocol) と同じ01-00-0c-cc-cc-cc です。
送信元MAC アドレスは、ポートのMAC アドレスを使います。



LLC


DSAP、SSAP ともに、上位にSNAP ヘッダーが存在することを意味する0xaa が入ります。
Control フィールドには、Unnumbered Information を意味する0x03が入ります。

※ DSAP (Destination Service Access Point)
※ SSAP (Source Service Access Point)



SNAP


OUI には、Cisco Systems を意味する0x00000c が入ります。
Type には、UDLD を意味する0x0111 が入ります。

※ OUI (Organizationally Unique Identifier)



UDLD


Version

Version 1 を意味する001(2進数)が入ります。

Opcode

UDLD PDU の種類を意味します。
UDLD のOpcode (オプコード)は、Probe、Echo、Flush の3種類があります。

※ Probe は、Hello、Advertisement とも呼ばれます。

各Opcode の詳細については、後述します。

Flags

状況に応じて立てるフラグです。
UDLD のフラグには、RT(Recomended Timeout)とRe-Synch の2種類があります。

各Opcode の詳細については、後述します。

TLVs

UDLD では、各種パラメータの表記にTLV 方式を採用しています。

※ TLV(Type Length and Value Encoding)

UDLD で使うTLV は以下の7種類です。

    Device ID TLV
    Port ID TLV
    Echo TLV
    Message Interval TLV
    Timeout Interval TLV
    Device Name TLV
    Sequence Number TLV


Device ID TLV


_______________________________

UDLD PDU を送信する機器のDevice ID が格納されます。
Catalyst2950、3550 の場合、Serial Number が入ります。

Port ID TLV


_______________________________

UDLD PDU を送信するポートの名前が格納されます。
GigabitEthernet0/1 の場合、Ge0/1 となります。

Echo TLV


_______________________________

UDLD Neighbor Database の内容、つまり、このUDLD PDU を送信する機器が、それまでに受信したUDLD PDU から抽出した情報が格納されます。

UDLD を有効にしているポートでは、通常、対向機器は1台だけです。
しかし、HUB を経由して複数台の対向機器が存在するような場合、対向機器が2台以上になることもあります(もちろん、誤った構成ですが)。

対向機器が複数台ある場合、全ての対向機器の情報が、Echo TLVに格納されます。

Number of Port ID
UDLD PDU を受信した対向機器の台数

Device/Port IDs
対向機器からのUDLD PDU から抽出した、対向機器のDevice ID とPort ID が格納されます。
このフィールドの内容は、次のようなフォーマットとなっています。


_______________________________

Message Interval TLV


_______________________________

UDLD PDU を送信する間隔です。

Timeout Interval TLV


_______________________________

ディテクションウィンドウ(Detection Window)の長さです。

※ ディテクションウィンドウについては後述します。

Device Name TLV


_______________________________

hostname コマンドで設定した、機器の名前が格納されます。

Sequence Number TLV


_______________________________

UDLD PDU が送信された順番を意味するシーケンス番号が格納されます。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める (4)UDLD の基本動作

UDLD は、対向機器との間でフレームを送信しあって、到達性を確認します。

UDLD が有効となっているCatalyst のポートがリンクアップすると、UDLD フレーム(UDLD PDU)を送信し始めます。

※ PDU (Protocol Data Unit)

UDLD が有効となっているCatalyst のポートで、対向機器からのUDLD フレームを受信すると、受信したUDLD フレームから抽出した情報を埋め込んで、対向機器にUDLD フレームを送信します。

自分の情報が埋め込まれたUDLD フレームを受信すると、Catalyst は、自分の送信したフレームが対向機器に正しく受信されていることがわかります。














対向機器が正しく受信していると、両方の機器が認識することで、リンクがBidirectional であると判断されます。

対向機器から定期的に送られてくるUDLD フレームに、自分の情報が含まれなくなると、自分のUDLD フレームが対向機器に届かなくなったと認識されます。
そのような状態は、Unidirectional だと判断され、一定回数の再送を試みたのち、ポートを閉塞します。













UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める (3)UDLD とAuto Negotiation

Auto Negotiation があればUDLD は必要ない、という意見があります。

確かに、Auto Negotiation のRemote Fault 機能を利用すれば、TX から送信した(はず)の信号が、相手に届いていないことを検出できます。

しかし、Auto Negotiation で検出できるのは、PHY レベル(物理層)の信号までです。
PHY レベルでは問題がなくても、スイッチのポート不具合で、フレームを送信・受信できない状況が発生することもあります。

UDLD を物理層のプロトコルであるという誤解があります。
Cisco の社員でさえ、そのような誤解をしている人をたまに見かけますが、正しくありません。

名称にリンクとありますが、物理層の信号を監視しているわけではありません。
フレームを送信しあって到達性を確認することで、物理層の状態変化を間接的に検出するプロトコルです。

フレームの到達性は、データリンクの健全性と言い換えることができます。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

UDLD を究める (2)Bidirectional とUnidirectional

Cisco は、イーサネットのポートで、TX からフレームを送信し、RX でフレームを受信できる状態をBidirectional(双方向) であると定義しています。

反対に、TX からフレームが送信できないか、もしくは、RX でフレームを受信できない状態を、Unidirectional(片方向) であると定義してます。









上図では、Catalyst-A のTX から送信されたフレームはCatalyst-B のRX で、Catalyst-B のTX から送信されたフレームはCatalyst-A のRX で、正常に受信できています。
こういう状態がBidirectional (バイダイレクショナル)です。

これに対して下図では、Catalyst-A はCatalyst-B からのフレームを受信できていますが、Catalyst-B はCatalyst-A からのフレームを受信できていません。
フレームを受信できていない理由は二つ考えられます。

    Catalyst-A が、正しく送信できていない
    Catalyst-B が、正しく受信できていない









どちらの理由であれ、このような状態がUnidirectional (ユニダイレクショナル) です。

※ Unidirectional のことを、IEEE 802.3 では、Asymetric Link Failure (非対称リンク障害) と呼んでいます。



UDLD を究める (1) はじめに
UDLD を究める (2)Bidirectional とUnidirectional
UDLD を究める (3)UDLD とAuto Negotiation
UDLD を究める (4)UDLD の基本動作
UDLD を究める (5)UDLD のパケットフォーマット
UDLD を究める (6)UDLD のタイマー
UDLD を究める (7)Bidirectional State
UDLD を究める (8)Operartional State
UDLD を究める (9)UDLD のアルゴリズム(1)ネイバー関係の確立
UDLD を究める(10)UDLD のアルゴリズム(2)Unidirectional を検知する
UDLD を究める(11)UDLD アグレッシブモード
UDLD を究める(12)UDLD ノーマルモードとアグレッシブモードの互換性
UDLD を究める(13)設定用コマンド
UDLD を究める(14)show コマンド
UDLD を究める(15)UDLD のデバッグ(1)ネイバー関係の確立
UDLD を究める(16)UDLD のデバッグ(2)Unidirectional を検知する
UDLD を究める(17)UDLD のテスト環境を構築する
UDLD を究める(付録) UDLD の状態遷移を時系列で観察する

HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP version 2 の設定です。

HSRP version 2 を設定します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/0
Router-A(config-if)#standby version 2@
Router-A(config-if)#standby ?
<0-4095> group numberA
authentication Authentication
delay HSRP initialisation delay
ip Enable HSRP and set the virtual IP address
mac-address Virtual MAC address
name Redundancy name string
preempt Overthrow lower priority Active routers
priority Priority level
redirect Configure sending of ICMP Redirect messages with an HSRP
virtual IP address as the gateway IP address
timers Hello and hold timers
track Priority tracking
use-bia HSRP uses interface's burned in address
version HSRP version

Router-A(config-if)#standby 1000 ip 192.168.1.1
Router-A(config-if)#standby 1000 preempt
Router-A(config-if)#standby 1000 priority 105
Router-A(config-if)#^Z
Router-A#

@ HSRP version 2 を使用することを宣言します。

A standby version 2 を実行すると、256から4095のStandby Group 番号も指定できるようになります。

そのほかの設定は、HSRP version 1 と同じです。

show standby の実行結果です。



Router-A#show standby
Ethernet0/0 - Group 1000 (version 2)
State is Active
2 state changes, last state change 00:00:08
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c9f.f3e8
Local virtual MAC address is 0000.0c9f.f3e8 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.000 secs
Preemption enabled
Active router is local
Standby router is unknown
Priority 105 (configured 105)
IP redundancy name is "hsrp-Et0/0-1000" (default)
Router-A#

Standby Group 番号に続けて、HSRP version 2 を使用中と表示されます。

HSRP version を1 に戻すには、standby version 1 か、no standby version を実行します。
しかし、Standby Group 番号に256以上を指定していると、以下のメッセージが表示されて、Version の変更ができません。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/0
Router-A(config-if)#standby version 1
% Warning: Current config does not permit HSRP version 1.
Router-A(config-if)#no standby version
% Warning: Current config does not permit HSRP version 1.
Router-A(config-if)#



HSRP のversion は、インターフェイス毎に異なるものを使用できます。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット

HSRP version 2 のパケットフォーマットです。





000

この例では、IPv4 を使っています。

Ethernet


宛先IP アドレスが224.0.0.102 に変わったのに伴い、宛先MAC アドレスは、01-00-5E-00-00-66 に変わりました。
送信元MAC アドレスは、Active Router の場合はVirtual MAC アドレスです。
Active 以外のルータは、Real MAC アドレスを使います。



IP


HSRP は、サブネット内でのみ有効なプロトコルです。
HSRP のパケットはルーティングされる必要がないので、IP ヘッダのTTL(Time To Live) は必ず1になります。

HSRP はUDP を使用するので、Protocol フィールドには17(10進数)が入ります。

宛先IP アドレスは、サブネット内のすべてのHSRP ルータを意味する224.0.0.102 になります。
送信元IP アドレスは、HSRP パケットを送信するインターフェイスのReal IP アドレスです。



UDP


UDP のポート番号は、宛先/送信元のどちらも、HSRP を意味する1985(10進数)が入ります。



HSRP


TLVs


HSRP version 2 では、パケットフォーマットにTLV 方式を採用しています。

※ TLV(Type Length and Value Encoding)

HSRP version 2 で使うTLV は以下の4種類です。


  1. Group State TLV

  2. Interface State TLV

  3. Text Authentication TLV

  4. MD5 Authentication TLV



Group State TLV


Version

HSRP version 2 を意味する2が入ります。

Opcode


HSRP メッセージの種類を意味します。
HSRP のOpcode (オプコード)は、Hello、Coup、Resign の3種類があります。

HSRP version 1 にあったAdvertisement メッセージは、後述するInterface State TLV により実現されるため、Opcode からはなくなりました。

State


Standby Group に所属しているルータのState (ステート:状態)を意味します。
HSRP のState は、Disabled、Init、Learn、Listen、Speak、Standby、Active の7種類があります。

※ Disabled は、ルータ内部でのみ使用されるState なので、HSRP パケットのState が0 になることはありません。

IP version


使用するIPのバージョンが入ります。

Group Number


Standby Group 番号が入ります。設定可能な番号が4096個に拡張されたのに伴い、フィールド長が2オクテットに拡張されています。

Identifier


送信元インターフェイスのMAC アドレスが入ります。

Priority


ルータに設定されたプライオリティが入ります。
プライオリティが一番高いルータがActive Router に、二番目に高いルータがStandby Router になります。
プライオリティが同じ場合は、Real IP アドレスが比較の対象となります。
プライオリティのデフォルトは100です(0〜255の間で設定可能です)。

Hello Time


ルータがHello メッセージを送信する間隔を意味します。
デフォルトは3秒です(1〜254秒までの間で設定可能です)。

Hold Time


他のルータから受信したHello メッセージの内容を保持する時間を意味します。
デフォルトは10秒です("Hello Time + 1秒" 〜 255秒までの間で設定可能)。

Active Router からの最後のHello メッセージ受信後、Hold Time の秒数が経過すると、Standby Router は、Active Router が存在しなくなったと判断して、自分がActive Router になろうとします。

Hello Time とHold Time は、Active Router に設定された値が、Standby Group 内で共有されます。
Active Router が切り替わると、新しいActive Router に設定されている値に変わります。

※ 値が変わるのは、新しいActive Router に、明示的に値が設定されている場合だけです。明示的に設定されていない場合(デフォルト値)は、以前のActive Router の値が使われ続けます。

同様に、Standby Router からの最後のHello メッセージ受信後、Hold Time が経過すると、Listen State にあったルータは、Stnadby Router が存在しなくなったと判断して、自分がStandby Router になろうとします。

Virtual IP Address


設定された(もしくは、他ルータから学習した) Virtual IP アドレスが格納されます。




Interface State TLV


Acctive Groups


自分がActive Router となっている、Standby Group の数が入ります。

Passive Groups


自分がActive Router となっていない、Standby Group の数が入ります。




Text Authentication TLV


Authentication Data


認証用の文字列(平文)が入ります。
文字列を設定することで、Standby Group に参加するルータの簡易認証を行うことができます。




MD5 Authentication TLV


Algorithm


使用するアルゴリズムが入ります。現在サポートしているのはMD5 のみなので、必ずMD5を意味する1が入ります。

Padding


未使用フィールドです。必ず0が入ります。

Flags


未定義フィールドです。現在は使用されていません。

IP Address


送信元インターフェイスのIP アドレスです。
4オクテットしか幅がないので、IPv6 では使用できないと思われます(未確認)。

Key ID


キーチェインのID が入ります。
キー文字列を直接設定した場合は、0が入ります。

Authentication Data


MD5 のダイジェスト文字列が入ります。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

2006年02月12日

HSRP を究める - 応用編(7) HSRP version 2(1)

これまで見てきたHSRP は、version 1 でした。

このページでは、IOS version 12.3(4)T からサポートされるようになった、HSRP version 2 を見ていきます。

HSRP version 1 と2 の間に、プロトコルのステートマシン(状態遷移)に関する大きな違いはありません。

HSRP version 1 でサポートされていたHSRP の各種機能は、HSRP version 2 でも同様に利用できます。

HSRPP version 2 の大きな変更点は、以下の4点です。


  1. Standby Group 番号の拡張

  2. バーチャルMAC アドレスの変更

  3. メッセージの宛先アドレスの変更

  4. IPv6 のサポート


1. Standby Group 番号の拡張


HSRP version 1では、設定可能なStandby Group 番号は、1から255までの256個でした。
HSRP version 2では、0から4095までの4096個に拡張されています。

この拡張は、Encapsulation をDot1Q やISL に設定したサブインターフェイス上にStandby Group を設定しる場合に、VLAN ID とStandby Group 番号を一致させることで、管理を用意にすることをもく低としています。

2. バーチャルMAC アドレスの変更


HSRP version 1では、デフォルトのバーチャルMAC アドレスに、00-00-0c-07-ac-xx が使われていました。
HSRP version 2では、00-00-0C-9F-Fx-xx に変更されています。

3. メッセージの宛先アドレスの変更


HSRP version 1では、Hello などのHSRP メッセージの宛先IP アドレスに、"All Routers on this Subnet" を意味する224.0.0.2 が使われていました。
HSRP version 2では、HSRP 用に別途IANA から割り当てられた、224.0.0.102 に変更されています。

この変更は、CGMP(Cisco Group Management Protocol) など、他のプロトコルとの競合を回避するための措置です。

※ IANA (Internet Assigned Number Authority)

4. IPv6 のサポート


HSRP version 1 では、IPv4 しかサポートしていませんでした。
HSRP version 2 では、IPv6 をサポートするため、パケットフォーマットが変わりました。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする

EtherChannel を組んでいるインターフェイスをトラッキングしたいこともあります。

Channel 内の物理インターフェイスの一つが使用不可となっても、Channel 自体はアップしています。

Channel 内の物理インターフェイスが減っていき、Standby Router 側のリンクの方が太くなった時点で、Active Router の切り替えが発生するのが理想です。

Channel 内の複数の物理インターフェイスを、それぞれトラッキングすることは可能です。
しかし、これまで見てきたboolean and やboolean or では、そこまで柔軟な対応はできません。
「全部のインターフェイスがダウンしたら」とか「一つでもアップしたら」と、両極端です。

上図では、Router-A とC の間は、3本のEthernet でEtherChannel を構成しています。
Router-B とD の間も、3本のEthernet でEtherChannel を構成していますが、1本はダウンしています。

この状態で、Router-A とC の間のリンクが一本ダウンしても、Standby Router 側(Router-B) のリンクと同じ帯域幅なので、Active Router が切替わる必要性は見られません。

Router-A とC の間のリンクがもう一本ダウンして、Channel 内のリンクが一本だけになると、Standby Router 側(Router-B) のリンクの方が太くなります。

今回は、Router-A とC の間のリンクが1本以下になったら、Standby Group のプライオリティを下げ、2本以上になったら、プライオリティを元に戻すように設定します。

本ページでは、Debug コマンドを使用します。
本ページの内容を実際に試される場合は、事前に「Debug コマンドについて」をお読みください。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#track 1 interface ethernet 0/1 line-protocol@
Router-A(config-track)#delay down 1 up 15
Router-A(config-track)#exit
Router-A(config)#track 2 interface ethernet 0/2 line-protocol
Router-A(config-track)#delay down 1 up 15
Router-A(config-track)#exit
Router-A(config)#track 3 interface ethernet 0/3 line-protocol
Router-A(config-track)#delay down 1 up 15
Router-A(config-track)#exit
Router-A(config)#track 10 list threshold weightA
Router-A(config-track)#object 1 weight 20B
Router-A(config-track)#object 2 weight 20
Router-A(config-track)#object 3 weight 20
Router-A(config-track)#threshold weight up 40 down 20C
Router-A(config-track)#exit
Router-A(config)#interface ethernet0/0
Router-A(config-if)#standby 10 track 10 decrement 10D
Router-A(config-if)#^Z
Router-A#

@ Track 1、2、3 にそれぞれ、Ethernet0/1、0/2、0/3 のLine Protocol をトラッキング対象として指定します。

A Track 10 を作成し、Object をList 指定します。

B 先に作成したTrack 1、2、3 をそれぞれObject 1、2、3 として指定し、20の重みを設定します。

C トラッキングの閾値(Threshold) を設定します。この例は、重みが20以下になったらダウン、40以上になったらアップと判断することを意味します。

D Standby Group 10 に、Track 100を対象とするObject Tracking を設定します。プライオリティの下げ幅は10です。

以上で設定は完了です。

Router-A で、show track を確認します。

Router-A#show track
Track 1
Interface Ethernet0/1 line-protocol
Line protocol is Up
2 changes, last change 00:00:16
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 2
Interface Ethernet0/2 line-protocol
Line protocol is Up
1 change, last change 00:02:18
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 3
Interface Ethernet0/3 line-protocol
Line protocol is Up
1 change, last change 00:02:00
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 10
List threshold weight
Threshold Weight is Up (60/60)
2 changes, last change 00:01:36
object 1 weight 20 Up (20/60)
object 2 weight 20 Up (20/60)
object 3 weight 20 Up (20/60)
Threshold weight down 20 up 40

Tracked by:
HSRP Ethernet0/0 10
Router-A#


すべてが正常に動作しているとき、Track 100 の重みは60あります。
Track 100の監視対象であるTrack 1、2、3のどれかがダウンすると、重みは20減ります。二つ目のTrack がダウンすると、さらに重みは20減り、20になります。
Track 100 の重みが20以下になると、Track 100はダウンしたと判断し、アラームがあがります。
Standby Group 10 は、アラームを受けて、プライオリティを10減らします。

Track 1、2、3のダウンしていた二つのうちのどちらかがアップすると、重みは40に増えます。
Track 100 はアップしたと判断され、アラームがあがり、それを受けてStandby Group 10のプライオリティが10増えます。

つまり、EtherChannel 内のリンクが一つ以下になればダウン、二つ以上になればアップ、と判断され、Standby Group のプライオリティを操作することができます。

では、実際に障害を発生させて、状況を観察しましょう。

Router-A で、debug track を実行しておきます。

Debug コマンドについて」をお読みください。



Router-A#
Router-A#debug track
Router-A#


Router-A のインターフェイスEthernet0/1 をshutdown します。

Router-A(config)#interface ethernet 0/1
Router-A(config-if)#shutdown
Router-A(config-if)#
*Feb 11 23:36:10.272: Track: 1 Down change delayed for 1 secs
*Feb 11 23:36:11.272: Track: 1 Down change delay expired
*Feb 11 23:36:11.272: Track: 1 Change #2 interface Et0/1, line-protocol Up->Down
*Feb 11 23:36:11.276: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
Router-A(config-if)#
*Feb 11 23:36:12.268: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
*Feb 11 23:36:13.268: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
Router-A(config-if)#^Z
Router-A#

Router-A で、show track を確認します。



Router-A#show track
Track 1
Interface Ethernet0/1 line-protocol
Line protocol is Down (hw admin-down)
2 changes, last change 00:00:16
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 2
Interface Ethernet0/2 line-protocol
Line protocol is Up
1 change, last change 00:02:18
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 3
Interface Ethernet0/3 line-protocol
Line protocol is Up
1 change, last change 00:02:00
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 10
List threshold weight
Threshold Weight is Up (40/60)
2 changes, last change 00:01:36
object 1 weight 20 Down (0/60)
object 2 weight 20 Up (20/60)
object 3 weight 20 Up (20/60)
Threshold weight down 20 up 40
Tracked by:
HSRP Ethernet0/0 10
Router-A#

Ethernet0/1 がダウンして、Track 1 の重み20が減り、重みは40になりました。
しかし、まだTrack 10 はアップしています。

show standby を確認します。



Router-A#show standby
Ethernet0/0 - Group 10
State is Active
2 state changes, last state change 00:04:02
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.876 secs
Preemption enabled
Active router is local
Standby router is 192.168.1.101, priority 95 (expires in 8.756 sec)
Priority 100 (default 100)
Track object 10 state Up decrement 10
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

続いて、Ethernet0/2 をshutdown します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/2
Router-A(config-if)#shutdown
Router-A(config-if)#
*Feb 11 23:36:51.480: Track: 2 Down change delayed for 1 secs
*Feb 11 23:36:52.484: Track: 2 Down change delay expired
*Feb 11 23:36:52.484: Track: 2 Change #2 unterface Et0/2, line-protocol Up->Down*Feb 11 23:36:52.948: Track: 10 Change #3 list, threshold weight Up->Down(->20)
Router-A(config-if)#
*Feb 11 23:36:52.952: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/2 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
*Feb 11 23:36:53.364: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> Speak
Router-A(config-if)#
*Feb 11 23:36:53.480: %LINK-5-CHANGED: Interface Ethernet0/2, changed state
to administratively down
*Feb 11 23:36:54.480: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/2, changed state to down
Router-A(config-if)#
*Feb 11 23:37:01.880: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> Standby
Router-A(config-if)#Router-A(config-if)#^Z
Router-A#


Router-A で、show track を確認します。



Router-A#show track
Track 1
Interface Ethernet0/1 line-protocol
Line protocol is Down (hw admin-down)
2 changes, last change 00:01:06
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 2
Interface Ethernet0/2 line-protocol
Line protocol is Down (hw admin-down)
2 changes, last change 00:00:25
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 3
Interface Ethernet0/3 line-protocol
Line protocol is Up
1 change, last change 00:02:49
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 10
List threshold weight
Threshold Weight is Down (20/60)
3 changes, last change 00:00:25
object 1 weight 20 Down (0/60)
object 2 weight 20 Down (0/60)
object 3 weight 20 Up (20/60)

Threshold weight down 20 up 40
Tracked by:
HSRP Ethernet0/0 10
Router-A#


Ethernet0/1 に続いてEthernet0/2がダウンして、Track 2 の重み20が減り、重みは20になりました。
Track 10 はダウンします。

Standby Group 10 のプライオリティが10下げられ、State はActive からSpeak へ、そしてStandby へ移行します。

show standby を確認します。



Router-A#show standby
Ethernet0/0 - Group 10
State is Standby
2 state changes, last state change 00:04:56
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.404 secs
Preemption enabled
Active router is 192.168.1.101, priority 95 (expires in 9.328 sec)
Standby router is local
Priority 90 (default 100)
Track object 10 state Down decrement 10
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

先ほどshutdown したEthernet0/1 をno shutdown します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet 0/1
Router-A(config-if)#no shutdown
*Feb 11 23:38:25.356: Track: 1 Up change delayed for 15 secs
Router-A(config-if)#
*Feb 11 23:38:27.352: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state t
o up
*Feb 11 23:38:28.352: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
Router-A(config-if)#^Z
*Feb 11 23:38:28.820: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/1 from LOADING to FULL, Loading Done
Router-A(config-if)#
*Feb 11 23:38:40.356: Track: 1 Up change delay expired
*Feb 11 23:38:40.356: Track: 1 Change #3 interface Et0/1, line-protocol Down->Up
*Feb 11 23:38:40.948: Track: 10 Change #4 list, threshold weight Down->Up(->40)
Router-A(config-if)#
*Feb 11 23:38:41.628: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Standby -> Active
Router-A(config-if)#

Router-A で、show track を確認します。



Router-A#show track
Track 1
Interface Ethernet0/1 line-protocol
Line protocol is Up
3 changes, last change 00:00:08
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 2
Interface Ethernet0/2 line-protocol
Line protocol is Down (hw admin-down)
2 changes, last change 00:01:56
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 3
Interface Ethernet0/3 line-protocol
Line protocol is Up
1 change, last change 00:04:21
Delay up 15 secs, down 1 sec
Tracked by:
Track-list 10
Track 10
List threshold weight
Threshold Weight is Up (40/60)
4 changes, last change 00:00:10
object 1 weight 20 Up (20/60)
object 2 weight 20 Down (0/60)
object 3 weight 20 Up (20/60)

Threshold weight down 20 up 40
Tracked by:
HSRP Ethernet0/0 10
Router-A#

Ethernet0/1 がアップし、Track 2 の重み20が増え、重みは40になりました。
Track 10 はアップします。

Standby Group 10 のプライオリティが10上がり、State はStandby からActive へ移行します。

show standby を確認します。



Router-A#show standby
Ethernet0/0 - Group 10
State is Active
2 state changes, last state change 00:06:24
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.544 secs
Preemption enabled
Active router is local
Standby router is 192.168.1.101, priority 95 (expires in 4.253 sec)
Priority 100 (default 100)
Track object 10 state Up decrement 10
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

Standby Group 10 は元に戻りました。



今回は、EtherChannel 内の物理リンクを対象としましたが、Channel ではなく、別々なリンクを対象として重み付けをすることも可能です。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする

これまでは、インターフェイスや特定のIP 経路情報をトラッキングして、Active Router の切り替えを行ってきました。

経路情報を使って、特定のIP アドレスをトラッキングするには、そのIP アドレスのホストルートを受け取って、ルーティングテーブルへ載せる必要があります。

ルータのLoopback インターフェイスであれば、ホストルートでも問題ありません。
しかし、他のルータのインターフェイスに設定されている、全てのIP アドレスをホストルートで受け取るのは現実的ではありません。

ルータ全体が使用不可となる状況は、Loopback インターフェイスを監視することでトラッキング可能ですが、ルータの特定のインターフェイスに発生する障害を検出することはできません。

下図を見てください。
Router-C のインターフェイスEthernet0/1 は、インターネットへの出口となっています。

Router-C 自体は稼動していても、このインターフェイスが使用不可となると、Router-C を経由してインターネットへ接続することはできなくなります。

IOS version 12.3(14)T からサポートされている、IP SLA (Service Level Agreement) 機能を使うと、特定IP アドレスへのReachability をトラッキングできます。


本ページでは、Debug コマンドを使用します。
本ページの内容を実際に試される場合は、事前に「Debug コマンドについて」をお読みください。

まずは、Router-A でIP SLA を設定します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#ip sla monitor 1@
Router-A(config-sla-monitor)#type echo protocol ipIcmpEcho 192.168.4.102A
Router-A(config-sla-monitor-echo)#frequency 10B
Router-A(config-sla-monitor-echo)#timeout 1000C
Router-A(config-sla-monitor-echo)#exit
Router-A(config)#ip sla monitor schedule 1 life forever start-time nowD
Router-A(config)#

@ IP SLA 番号を指定します(1から2147483647の間で指定できます)。

A IP SLA の計測には、応答時間を見るEcho、ホップ毎の遅延のゆらぎを見るJitter など、数種類がありますが、今回は、Echo を利用します。
計測方法は、type に続けてecho と指定します。

IP SLA の計測には、HTTP、FTP、DNS、ICMP などさまざまプロトコルが使用できますが、、計測方法にEcho を使う場合はICMP のみ利用可能です。
プロトコルは、protocol に続けて、ipIcmpEcho と指定します。
ICMP の宛先に、Router-C のEthernet0/1(192.168.4.102) を指定します。

B ICMP Echo Request を送信する間隔を秒数で指定します。今回は、10秒にしました。

C Router-C からICMP Echo Reply が返ってこない場合のタイムアウト値を秒数で指定します。今回は、1秒にしました。

D IP SLA による計測を実施するスケジュールを、設定します。

先に作成したIP SLA 番号1 を、schedule に続けて指定します。

life で、計測開始から何秒間継続するかを指定します。今回は、管理者が停止させるまで継続しつづけるよう、forever を使います。

start-time で、計測を開始する時刻を指定します。今回は、即座に始めるよう、now を使います。

ここまで終わると、Router-A は、Router-C へ10秒間隔でPing を送信し始めます。

続けて、Router-A にObject Tracking を設定します。



Router-A(config)#track 1 rtr 1@
Router-A(config-track)#delay down 1 up 15A
Router-A(config-track)#exit
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#standby 10 track 1B
Router-A(config-if)#

@ rtr で、先ほど設定したIP SLA 番号1 を割り当てます(Track 1)。
RTR はResponse Time Reporter の略です。

A Down Delay タイマー、Up Delay タイマーを設定します。

B Standby Group 10 のトラッキング対象を、Track 1 に設定します。


設定は以上です。

Router-A で、debug track を実行しておきます。

Debug コマンドについて」をお読みください。



Router-A#
Router-A#debug track
Router-A#


Router-C のインターフェイスEthernet0/1 をshutdown します。



Router-C(config)#interface e0/1
Router-C(config-if)#shutdown
Router-C(config-if)#
*Feb 11 17:55:37.467: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.5 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-C(config-if)#
*Feb 11 17:55:39.467: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
*Feb 11 17:55:40.467: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
Router-C(config-if)#

Router-C のEthernet0/1 がダウンしました。

Router-A のコンソールです。



Router-A#
*Feb 11 18:04:38.391: Track: 1 Down change delayed for 1 secs@
*Feb 11 18:04:39.391: Track: 1 Down change delay expiredA
*Feb 11 18:04:39.391: Track: 1 Change #4 rtr 1, state Up->DownB
Router-A#
*Feb 11 18:04:41.091: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> SpeakC
Router-A#
*Feb 11 18:04:51.091: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> StandbyD
Router-A#

@ Router-C のEthernet0/1(192.168.4.102) からICMP Echo Reply が返ってこなくなったのを受けて、Down Delay タイマーを稼動させました。

A Down Delay タイマーが満了しました。

B Down Delay タイマーの満了を受けて、アラームを上げました。

C Track 1 からのアラームを受けて、Standby Group 10 のプライオリティを10下げ、State がActive からSpeak へ移行しました。

D State が、Speak からStandby へ移行しました。


対象はルータのインターフェイスだけに限りません。
特定のサーバを対象にトラッキングすることも可能です。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

2006年02月11日

HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする

先の例では、複数のインターフェイスをboolean and でトラッキングしました。
実用性に乏しいことをお話しましたが、ネットワークの構成しだいでは、boolean and が有効に働くこともあります。

このページでは次のようなネットワークを使います。

※ この例で使うネットワークは、機能を理解するために簡略化しています。
必ずしも最適な構成ではないことをご了承下さい。


本ページでは、Debug コマンドを使用します。
本ページの内容を実際に試される場合は、事前に「Debug コマンドについて」をお読みください。

※ これまでに設定したObject Tracking の設定は削除しておいてください。

Router-A とB の間でStandby Group 10 を作成して、PC-1 にデフォルトゲートウェイを提供しています。

全てが正常に動作しているとき、Router-A がActive Router、Router-B がStandby Router になっています。

Router-C とD は、インターネットへの出口になっており、それぞれ別なISP に接続しています。
すべてが正常に動作しているとき、Router-A が中継するデータはRouter-C を経由して、Router-B が中継するデータはRouter-D を経由してインターネットへ向け送信されます。
Router-C が使用不可となると、Router-A のルーティングテーブル上で、インターネット宛のNext Hop は、Router-B のEthernet0/0(192.168.1.101) に切替わります。

それまでのPC1 --> Router-A --> Router-C --> Internet という流れが、PC-1 --> Router-A --> Router-B --> Router-D --> Internet となります。

通信は継続できますが、Standby Group 10のActive Router はRouter-A のままです。

Active Router がRouter-B に切替われば、余計なHop(Router-A) が介在することなくInternet への接続性を確保できます。


Router-A から、最短でインターネットへ出るには、Router-C を経由する必要があります。
また、Router-A からRouter-C へ到達するには、(インターネットを経由しない限り)Ethernet0/1 しか道はありません。

Router-C が使用不可となるか、Router-A のEthernet0/1 がダウンすると、PC-1 の送信するパケットがインターネットへ出るためには、Router-B を経由することになります。

つまり、この二つの状況のどちらか一方が発生すると、Active Router がRouter-B へ切替わることが期待されます。

boolean and を使用すると、二つの条件のどちらか一方の発生を受けて、Standby Group のプライオリティを下げることができます。


Router-A でトラッキングの設定を行います。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#
Router-A(config)#track 1 interface ethernet 0/1 line-protocol@
Router-A(config-track)#delay down 1 up 10
Router-A(config-track)#exit
Router-A(config)#track 2 ip route 1.1.1.5/32 reachabilityA
Router-A(config-track)#delay down 1 up 10
Router-A(config-track)#exit
Router-A(config)#track 3 list boolean andB
Router-A(config-track)#object 1C
Router-A(config-track)#object 2
Router-A(config-track)#delay down 1 up 10
Router-A(config-track)#exit
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#standby 10 track 3 decrement 10D
Router-A(config-if)#^Z
Router-A#

@ Ethernet0/1 のLine Protocol をトラッキングするTrack 1 を作成します。

A Router-C のLoopback 0(1.1.1.5/32) をトラッキングするTrack 2を作成します。

B リストをboolean and するTrack 3 を作成します。

C 先に作成したTrack 1 と2 を、Track 3のObject に指定します。

D Track 3 を、Ethernet0/0 のStandby Gropup 10 でトラッキングします。


Router-A で、debug track を実行しておきます。

Debug コマンドについて」をお読みください。



Router-A#
Router-A#debug track
Router-A#


では、まずはRouter-A のEthernet0/1 をshutdown してみましょう。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/1
Router-A(config-if)#shutdown@
Router-A(config-if)#
*Feb 11 14:16:13.564: Track: 1 Down change delayed for 1 secsA
Router-A(config-if)#
*Feb 11 14:16:13.572: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Feb 11 14:16:14.580: Track: 1 Down change delay expiredB
*Feb 11 14:16:14.580: Track: 1 Change #4 interface Et0/1, line-protocol Up->DownC
Router-A(config-if)#
*Feb 11 14:16:15.240: Track: 3 Down change delayed for 1 secsD
Router-A(config-if)#
*Feb 11 14:16:15.572: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
*Feb 11 14:16:16.252: Track: 3 Down change delay expiredE
*Feb 11 14:16:16.252: Track: 3 Change #7 list, boolean and Up->Down(->10)F
Router-A(config-if)#
*Feb 11 14:16:16.572: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
Router-A(config-if)#
*Feb 11 14:16:19.232: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> SpeakG
Router-A(config-if)#
*Feb 11 14:16:29.232: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> StandbyH

@ Ethernet0/1 をshutdown しました。

A Ethernet0/1 のダウンを検出して、Down Delay タイマーが稼動を始めます。

B 1秒に設定してあった、Down Delay タイマーが満了しました。

C Track 1 が、Ethernet0/1 のLine Protocol がダウンしたと、アラームを発します。

D Track 1 のアラームを受けて、Track 3 のDown Delay タイマーが稼動を始めます。

E Track 3 のDown Delay タイマーが満了しました。

F Track 3 が、アラームを発します。

G Track 3 のアラームを受けて、Standby Group 10 のプライオリティが10 下げられ、State がActive からSpeak に移行します。

H Standby Group 10 のState が、Speak からStandby に移行しました。


次は、Router-E のLoopback0/1(1.1.1.5/32) へのReachability 検出を、試してみます。
※ Router-A のEthernet0/1 をno shutdown して、元に戻して置いてください。

Router-E でno ip routing します。



Router-E#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-E(config)#no ip routing
Router-E(config)#


Router-A のコンソールです。



Router-A#
*Feb 11 14:51:56.120: Track: 2 Down change delayed for 1 secs@
*Feb 11 14:51:57.120: Track: 2 Down change delay expiredA
*Feb 11 14:51:57.120: Track: 2 Change #4 IP route 1.1.1.5/32, OSPF->no route, reachability Up->Down
B
Router-A#
*Feb 11 14:51:57.840: Track: 3 Down change delayed for 1 secsC
*Feb 11 14:51:58.840: Track: 3 Down change delay expiredD
*Feb 11 14:51:58.840: Track: 3 Change #9 list, boolean and Up->Down(->10)
E
Router-A#
*Feb 11 14:52:01.396: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> SpeakF
Router-A#
*Feb 11 14:52:11.404: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> StandbyG
Router-A#

@ ルーティングテーブルから1.1.1.1/32 が無くなったことを検出して、Down Delay タイマーが稼動を始めます。

A 1秒に設定してあった、Down Delay タイマーが満了しました。

B Track 2 が、Ethernet0/1 のLine Protocol がダウンしたと、アラームを発します。

C Track 2 のアラームを受けて、Track 3 のDown Delay タイマーが稼動を始めます。

D Track 3 のDown Delay タイマーが満了しました。

E Track 3 が、アラームを発します。

F Track 3 のアラームを受けて、Standby Group 10 のプライオリティが10 下げられ、State がActive からSpeak に移行します。

G Standby Group 10 のState が、Speak からStandby に移行しました。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)

これまで見てきたトラッキングはすべて、インターフェイスのアップ・ダウンを対象としたものでした。
ルータ単体(自分自身)の状況を監視していたわけです。

他のルータの状況をトラッキングして、HSRP のState に反映させられれば、より柔軟な運用ができます。

Object Tracking では、特定の経路情報への到達性(Reachability) を対象にトラッキングを行うこともできます。

この機能を利用し、特定のルータのLoopback Interface をトラッキングします。

このページでは次のようなネットワークを使います。

※ この例で使うネットワークは、機能を理解するために簡略化しています。
必ずしも最適な構成ではないことをご了承下さい。


本ページでは、Debug コマンドを使用します。
本ページの内容を実際に試される場合は、事前に「Debug コマンドについて」をお読みください。

※ これまでに設定したObject Tracking の設定は削除しておいてください。

Router-A とB の間でStandby Group 10 を作成して、PC-1 にデフォルトゲートウェイを提供しています。

全てが正常に動作しているとき、Router-A がActive Router、Router-B がStandby Router になっています。

Router-C とD は、インターネットへの出口になっており、それぞれ別なISP に接続しています。
すべてが正常に動作しているとき、Router-A が中継するデータはRouter-C を経由して、Router-B が中継するデータはRouter-D を経由してインターネットへ向け送信されます。
Router-C が使用不可となると、Router-A のルーティングテーブル上で、インターネット宛のNext Hop は、Router-B のEthernet0/0(192.168.1.101) に切替わります。

それまでのPC1 --> Router-A --> Router-C --> Internet という流れが、PC-1 --> Router-A --> Router-B --> Router-D --> Internet となります。

通信は継続できますが、Standby Group 10のActive Router はRouter-A のままです。

Active Router がRouter-B に切替われば、余計なHop(Router-A) が介在することなくInternet への接続性を確保できます。




Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#track 1 ip route 1.1.1.3/32 reachability@
Router-A(config-track)#exit
Router-A(config)#track timer ip route 1A
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#standby 10 track 1 decrement 10B
Router-A(config-if)#

@ トラッキング対象として、Router-E のLoopback 0(1.1.1.3/32) への到達性を指定しています。
到達性の有無は、Ping などによる診断ではなく、ルーティングテーブル上のエントリの有無で確認します。

A ルーティングテーブルを確認する間隔を1秒に指定します。デフォルトは15秒です。

B Object 1 がダウンしたら(1.1.1.3/32 がルーティングテーブルから消えたら)、Standby Group 10 のプライオリティを10下げるよう、指定します。

では、実験を始めましょう。

その前に一つ。
今回は、他のルータの状況変化に連動して、HSRP のプライオリティを変化させます。
Router-A のコンソールでは状況を把握しにくいので、debug track を実行しておきましょう。

Debug コマンドについて」をお読みください。



Router-A#
Router-A#debug track
Router-A#


Router-A のルーティングテーブルを確認します。



Router-A#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 7 subnets
C 1.1.1.1 is directly connected, Loopback0
O 1.1.1.3 [110/11] via 192.168.2.102, 00:00:07, Ethernet0/1
O 1.1.1.2 [110/11] via 192.168.1.101, 00:00:07, Ethernet0/0
O 1.1.1.5 [110/51] via 192.168.1.101, 00:00:07, Ethernet0/0
O 1.1.1.4 [110/21] via 192.168.1.101, 00:00:07, Ethernet0/0
O 192.168.4.0/24 [110/20] via 192.168.2.102, 00:00:07, Ethernet0/1
O 192.168.5.0/24 [110/30] via 192.168.1.101, 00:00:07, Ethernet0/0
C 192.168.1.0/24 is directly connected, Ethernet0/0
C 192.168.2.0/24 is directly connected, Ethernet0/1
O 192.168.3.0/24 [110/20] via 192.168.1.101, 00:00:08, Ethernet0/0
Router-A#

Router-C のLoopback0(1.1.1.5/32) は、ルーティングテーブルへ載っています。


では、Router-C で障害を発生させてみましょう。

今回は、Router-C でIP ルーティングを無効にしてみます。
(電源オフでも、Loopback0 のIP アドレスを削除するのでも良いです)



Router-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-C(config)#no ip routing
Router-C(config)#

※ OSPF のネイバーがダウンしたりと、メッセージが表示されますが、とりあえず流してください。

Router-A のコンソールです。



Router-A#
*Feb 11 12:44:32.361: Track: 1 Change #14 IP route 1.1.1.5/32, OSPF->no route, reachability Up->Down@
Router-A#
*Feb 11 12:44:33.593: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> SpeakA
Router-A#
*Feb 11 12:44:43.593: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> StandbyB
Router-A#
Router-A#show ip routeC
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 6 subnets
C 1.1.1.1 is directly connected, Loopback0
O 1.1.1.3 [110/11] via 192.168.2.102, 00:02:20, Ethernet0/1
O 1.1.1.2 [110/11] via 192.168.1.101, 00:02:20, Ethernet0/0
O 1.1.1.4 [110/21] via 192.168.1.101, 00:02:20, Ethernet0/0
O 192.168.4.0/24 [110/20] via 192.168.2.102, 00:02:20, Ethernet0/1
O 192.168.5.0/24 [110/30] via 192.168.1.101, 00:02:20, Ethernet0/0
C 192.168.1.0/24 is directly connected, Ethernet0/0
C 192.168.2.0/24 is directly connected, Ethernet0/1
O 192.168.3.0/24 [110/20] via 192.168.1.101, 00:02:22, Ethernet0/0
Router-A#

@ 1.1.1.5/32 へのReachability が失われたことを受けて、Track 1 をダウンさせました。

A Track 1 がダウンしたことを受けて、Standby Group のプライオリティが10 下げられ、90になります。Router-B からプライオリティが95 のHello メッセージを受け取り、Active Router を辞めます。

B Standby Router になりました。

C Router-A のルーティングテーブルを確認すると、1.1.1.5/32 が無くなっているのがわかります。


対象はLoopback インターフェイスだけに限りません。
上の例で、ISP-1 からしか受け取らない経路情報があるのであれば、それをTrack することでもActive Router の切り替えを行うこともできます。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)

実用性に多少疑問はありますが、先ほどの例で、boolean and を使ったトラッキングを見てみましょう。

このページでは次のようなネットワークを使います。

※ この例で使うネットワークは、機能を理解するために簡略化しています。
必ずしも最適な構成ではないことをご了承下さい。


※ これまでに設定したObject Tracking の設定は削除しておいてください。

Router-A に、Object Tracking の設定をします。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#track 1 interface ethernet0/1 line-protocol@
Router-A(config-track)#delay down 1 up 15
Router-A(config-track)#exit
Router-A(config)#
Router-A(config)#track 2 interface ethernet 0/2 line-protocolA
Router-A(config-track)#delay down 1 up 15
Router-A(config-track)#exit
Router-A(config)#track 3 list boolean andB
Router-A(config-track)#
Router-A(config-track)#object 1C
Router-A(config-track)#object 2
Router-A(config-track)#exit
Router-A(config)#
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#standby track 3 decrement 10D
Router-A(config-if)#delay down 1 up 15
Router-A(config-if)#^Z
Router-A#


@ Ethernet0/1 を対象とするトラッキングを設定します(Object 1)。

A 続けて、Ethernet0/2 を対象とするトラッキングを設定します(Objcet 2)。

B Objcet 3を作成し、複数の対象をトラッキングすることを意味するlist を指定し、ダウンと判断するための条件をboolean and で指定します。
boolean and にすると、全てのobject がアップしていない限りダウン、全てがアップしたらアップ、という意味になります。

C Object 番号1と2 を、オブジェクト番号3 のトラッキング対象に指定します。
D Object 3をStandby Group 10のトラッキング対象に設定します。


Router-A のEthernet0/1 をshutdown してみます。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/1
Router-A(config-if)#shutdown@
Router-A(config-if)#
*Feb 10 23:24:44.139: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
*Feb 10 23:24:46.139: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
*Feb 10 23:24:47.147: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
Router-A(config-if)#
*Feb 10 23:24:47.899: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> Speak
Router-A(config-if)#
*Feb 10 23:24:57.899: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> StandbyA
Router-A(config-if)#

@ Ethernet0/1 をshutdown しました。
A Ethernet0/1 がダウンしただけで、Standby Group 10 のState がStandby に移行しました。

続けて、Ethernet0/2 をshutdown します。



Router-A(config)#interface ethernet0/2
Router-A(config-if)#shutdown
Router-A(config-if)#
*Feb 10 23:27:24.459: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.4 on Ethernet0/2 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
*Feb 10 23:27:26.459: %LINK-5-CHANGED: Interface Ethernet0/2, changed state to administratively down
*Feb 10 23:27:27.467: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/2, changed state to down
Router-A(config-if)#


これで、Ethernet0/1 と0/2 の両方がダウンしました。

Ethernet0/1 でno shutdown します(Ethernet0/2 でも良いです)。



Router-A(config)#interface ethernet0/1
Router-A(config-if)#no shutdown
Router-A(config-if)#
*Feb 10 23:29:30.119: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Feb 10 23:29:31.119: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
Router-A(config-if)#
*Feb 10 23:29:35.667: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/1 from LOADING to FULL, Loading Done
Router-A(config-if)#

Ethernet0/1 はアップしましたが、HSRP に変化は見られません。

続けて、Ethernet0/2 をno shutdown します。



Router-A(config)#interface ethernet0/2
Router-A(config-if)#no shutdown@
Router-A(config-if)#
*Feb 10 23:33:18.683: %LINK-3-UPDOWN: Interface Ethernet0/2, changed state to up
*Feb 10 23:33:19.683: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/2, changed state to upA
Router-A(config-if)#
*Feb 10 23:33:25.695: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.4 on Ethernet0/2 from LOADING to FULL, Loading Done
Router-A(config-if)#
*Feb 10 23:33:48.107: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Standby -> ActiveB
Router-A(config-if)#

@ Ethernet0/2 をno shutdown しました。
A Ethernet0/2 がアップしました(これで、Ethernet0/1 と0/2 の両方がアップしました)。
B Standby Group 10 のState がStandby からActive に変わりました。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)

このページでは次のようなネットワークを使います。

※ この例で使うネットワークは、機能を理解するために簡略化しています。
必ずしも最適な構成ではないことをご了承下さい。

Router-A とB の間でStandby Group 10 を作成して、PC-1 にデフォルトゲートウェイを提供しています。

全てが正常に動作しているとき、Router-A がActive Router、Router-B がStandby Router になっています。

Router-A では、インターフェイスEthernet0/1 をトラッキングしており、Ethernet0/1 がダウンすると、プライオリティを10下げるようになっています。

Router-A でプライオリティが10下がって90になると、プライオリティが95のRouter-B がActive Router になります。

しかし、Router-B とE の間のリンクは、64kbps の低速シリアル回線です。
Router-A とC の間のリンクが失われても、まだ、Router-D との間には、10Mbps のイーサネットが残っています。
このリンクを使って通信を継続したいところです。


IOS version 12.2(15)T からサポートされている、Object Tracking という機能を使えば実現できます。

従来のHSRP では、トラッキングの対象は、自分の持つ一つのインターフェイスだけでした。
Object Tracking は、さまざまな対象(Object)をトラッキングすることができます。
また、同時に複数のObject をトラッキングすることもできます。

今回は、二つのインターフェイスを対象にして、両方のインターフェイスがダウンしたらHSRP のプライオリティを下げ、片方でもアップしたらプライオリティを元に戻すように設定します。


Tracking の仕組みを理解するため、まずは一つのインターフェイスだけを対象にトラッキングしてみます。
(得られる結果は、従来のInterface Tracking と同じです)

Router-A でObject Tracking の設定をします。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#
Router-A(config)#track 1 interface ethernet 0/1 line-protocol@
Router-A(config-track)#
Router-A(config-track)#delay down 1 up 15A
Router-A(config-track)#exit
Router-A(config)#
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#standby 10 track 1 decrement 10B
Router-A(config-if)#^Z
Router-A#

@ Object を設定します。
Object 番号を1にします(1から500の間で選択できます)。
トラッキング対象を、インターフェイスEthernet0/1 のLine Protocol に指定します。

A トラッキング対象がダウンしてからプライオリティを下げるまでの遅延時間を秒数で設定します(0から180の間で選択できます)。
同時に、トラッキング対象がアップしてからプライオリティを戻すまでの遅延時間を秒数で設定します(0から180の間で選択できます)。
今回は、ダウン時の遅延を1秒に、アップ時の遅延を15秒に設定しました。
この設定を省略すると、デフォルト値の0秒が選択されます。

B トラッキング対象をTrack 1 に指定し、ダウン時の下げ幅をdecrement で設定します

では、Ethernet0/1 をダウンさせてみましょう。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet 0/1
Router-A(config-if)#shutdown@
Router-A(config-if)#
*Feb 10 22:09:14.723: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
*Feb 10 22:09:16.719: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively downA
Router-A(config-if)#
*Feb 10 22:09:16.931: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> SpeakB
Router-A(config-if)#
*Feb 10 22:09:17.719: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
Router-A(config-if)#
*Feb 10 22:09:26.939: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> StandbyC
Router-A(config-if)#


@ Ethernet0/1 でshutdown しました。
A Ethernet0/1 がダウンしました。
B Standby Group 10のState がActive からSpeak へ移行しました。
C Standby Group 10のState がSpeak からStandby へ移行しました。

Router-B のコンソールです。



Router-B#
*Feb 10 22:09:17.547: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Standby -> Active
Router-B#

Standby Group 10のActive Router になりました。

では、Router-A のEthernet0/1 をno shutdown しましょう。



Router-A(config)#interface ethernet0/1
Router-A(config-if)#no shutdown@
Router-A(config-if)#
*Feb 10 22:16:28.871: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Feb 10 22:16:29.871: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to upA
Router-A(config-if)#
*Feb 10 22:16:35.639: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/1 from LOADING to FULL, Loading Done
Router-A(config-if)#
*Feb 10 22:16:44.011: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Standby -> ActiveB
Router-A(config-if)

@ Ethernet0/1 でno shutdown しました。
A Ethernet0/1 がアップしました。
B Standby Group 10のState がStandby からActive へ移行しました。



では、トラッキングの対象を二つに増やしましょう。

まず、先に設定したObject Tracking の設定を削除しておいてください。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#no track 1
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#no standby 10 track 1
Router-A(config-if)#^Z
Router-A#

Router-A に、改めてObject Tracking の設定をします。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#track 1 interface ethernet0/1 line-protocol@
Router-A(config-track)#delay down 1 up 15
Router-A(config-track)#exit
Router-A(config)#
Router-A(config)#track 2 interface ethernet 0/2 line-protocolA
Router-A(config-track)#delay down 1 up 15
Router-A(config-track)#exit
Router-A(config)#track 3 list boolean orB
Router-A(config-track)#
Router-A(config-track)#object 1C
Router-A(config-track)#object 2
Router-A(config-track)#exit
Router-A(config)#
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#standby track 3 decrement 10D
Router-A(config-if)#delay down 1 up 15
Router-A(config-if)#^Z
Router-A#


@ 先ほどと同様に、Ethernet0/1 を対象とするトラッキングを設定します(Track 1)。

A 続けて、Ethernet0/2 を対象とするトラッキングを設定します。Track 番号が2になっている点に注意してください。

B Track 3を作成します。複数の対象をトラッキングすることを意味するlist を指定し、ダウンと判断するための条件をboolean で指定します。

boolean or は、list の中のobject が一つでもアップしていればアップ、全てダウンしたらダウンさせる、という意味です。
boolean and にすると、全てのobject がアップしていない限りダウン、全てがアップしたらアップ、という意味になります。

C Track 1と2 を、Track 3 のトラッキング対象に指定します。
D Track 3をStandby Group 10のトラッキング対象に設定します。








Router-A のEthernet0/1 をshutdown してみます。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/1
Router-A(config-if)#shutdown@
Router-A(config-if)#
*Feb 10 22:35:51.263: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
*Feb 10 22:35:53.259: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
*Feb 10 22:35:54.259: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to downA
Router-A(config-if)#

@ Ethernet0/1 をshutdown しました。
A Ethernet0/1 はダウンしますが、HSRP に変化は見られません。

続けて、Router-A のEthernet0/2 をshutdown します。



Router-A(config)#interface ethernet0/2
Router-A(config-if)#shutdown@
Router-A(config-if)#
*Feb 10 22:42:06.187: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.4 on Ethernet0/2 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
*Feb 10 22:42:08.179: %LINK-5-CHANGED: Interface Ethernet0/2, changed state to administratively downA
Router-A(config-if)#
*Feb 10 22:42:08.299: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> SpeakB
Router-A(config-if)#
*Feb 10 22:42:09.179: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/2, changed state to down
Router-A(config-if)#
*Feb 10 22:42:18.299: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> StandbyC
Router-A(config-if)#

@ Ethernet0/2 をshutdown しました。
A Ethernet0/2 がダウンしました。
B Standby Group 10 のState がActive からSpeak に移行しました。
C Standby Group 10 のState がSpeak からStandby に移行しました。

では、Router-A のEthernet0/1 をno shutdown しましょう(Ethernet0/2 でも良いです)。



Router-A(config)#interface ethernet0/1
Router-A(config-if)#no shutdown@
Router-A(config-if)#
*Feb 10 22:47:06.631: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Feb 10 22:47:07.639: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to upA
Router-A(config-if)#
*Feb 10 22:47:14.687: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.3 on Ethernet0/1 from LOADING to FULL, Loading Done
Router-A(config-if)#
*Feb 10 22:47:20.679: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Standby -> ActiveB
Router-A(config-if)#

@ Ethernet0/1 でno shutdown しました。
A Ethernet0/1 がアップしました。
B Standby Group 10 のState が、Standby からActive に変わりました。

このように、Object Tracking を使うことで、複数のインターフェイスを同時にトラッキングすることができ、より柔軟な運用が行えます。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

2006年02月10日

HSRP を究める - 実践編(20) show コマンド

HSRP 関連のshow コマンド一覧です。

    show standby
    show standby delay
    show standby
    show standby redirects
    show standby capability
    show standby internal



show standby [Interface Name] [Group Number] [all] [brief]

Standby Group の状態、各種パラメータやタイマーを表示します。

IOS version 10.0 から使用可能です。


    Interface Name
    特定のインターフェイス上のStandby Group のみ表示する場合に指定します。
    省略した場合は、全てのインターフェイス上のStandby Group が表示されます。

    Group Number
    インターフェイスを指定したときのみ、Standby Group 番号を指定できます。
    インターフェイスを指定しない場合は、ルータ上の全てのStandby Group が対象となります。

    all
    全てのStandby Group を対象とする場合に、指定します。
    all を省略した場合も、全てのStandby Group が対象となるので、必要ありません。

show interface の出力例 (IOS version 12.2(8)T 以降)



Router-A#show standby ethernet 0/0 10
Ethernet0/0 - Group 10 @
State is Active A
2 state changes, last state change 00:21:41 B
Virtual IP address is 192.168.1.1 C
Active virtual MAC address is 0000.0c07.ac0a D
Local virtual MAC address is 0000.0c07.ac0a (v1 default) E
Hello time 15 msec, hold time 3 sec F
Next hello sent in 0.015 secs
Authentication text "smartnet" G
Preemption enabled H
Active router is local I
Standby router is 192.168.1.103, priority 100 (expires in 1.656 sec) J
Priority 105 (configured 105) K
Track interface Serial2/0 state Up decrement 15 L
IP redundancy name is "Engineering_Division" (cfgd) M
Router-A#

    @ 対象とするインターフェイスとStandby Group 番号
    A Standby Group のState
      Active、Standby、Listen、Init、Learn、Speak)

    B State が変化した回数
      初めて作成されたGruop でActive になると、Listen → Standby → Active となるので、変化した回数は2回です。その後Standby へ移行すると、Active → Speak → Standby と変化するので、回数は4回となります。

    C Standby Group のバーチャルIP アドレス
      他のルータから学習した場合は、(learnt) と表示される

    D Standby Group のバーチャルMAC アドレス
    E ルータに設定された、バーチャルMAC アドレス
      Active Router となっているときは、Cと一致します。
      standby mac-address コマンドで変更している時は、(confgd) と表示されます。
      Virtual MAC アドレスを変更していないときは、0000.0c07.acxx (v1 default) と表示されます。
      standby use-bia が設定されているときは、(bia) と表示されます

    F 使用中のHello Time とHold Time
      Active Router では無いときは、Active Router から学習して使用中の値が表示されます。
      ルータに設定した値ではない点に注意してください。

    G 認証関係の情報
      認証の設定をしていない場合は表示されません。
      平文の場合は文字列、MD5 を使用している場合はキーまたはキーチェインが表示されます

    H Preempt の状態
      有効な場合はenabled、無効な場合はdisabled と表示されます

    I Active Router のIP アドレスとプライオリティ、Active Timer が満了するまでの時間
      自分がActive Router の場合は、local と表示されます

    J Standby Router のIP アドレスとプライオリティ、Standby Timer が満了するまでの時間
      自分がActive Router の場合は、local と表示されます

    K プライオリティ
      括弧でくくられていない値は現在のプライオリティ、くくられているものは、設定された値です

    L Interface Tracking の設定
      Tracking の対象インターフェイス、現在の状態(Up/Down)、Down した場合のプライオリティの下げ幅の順に表示されます。
      Interface Tracking を設定していない場合は、表示されません。

    MStandby Group 名
      Group 名を設定していない場合、デフォルト値(インターフェイス名、Group 番号を組み合わせた名前。例:hsrp-Et0/0-10)が表示されいます。
      Group 名を設定すると、cfgd と表示されます。
      no standby 10 name とすると、以後、デフォルト値も表示されなくなります


show interface の出力例 (IOS version 12.2(8)T 以前)



Router-C#show standby ethernet0/0 30
Ethernet0/0 - Group 30
Local state is Active, priority 105, may preempt, use bia @
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.822
Virtual IP address is 192.168.1.3 configured A
Active router is local
Standby router is 192.168.1.102 expires in 9.568
Virtual mac address is aabb.cc00.6700
Authentication text "smartnet"
5 state changes, last state change 00:00:19
Priority tracking 1 interface, 1 up: B
Interface Decrement State
Serial2/0 15 Up
Router-C#

    @ IOS version 12.2(8)T 以前は、State とプライオリティ、Preempt の状態が一行に表示されます。
    standby preempt を設定していないときは、may preempt が表示されません。
    standby use-bia が設定されているときは、use bia が表示されます

    A Standby Group のバーチャルIP アドレス。
    IOS version 12.2(8)T 以前は、他のルータから学習することができないので、バーチャルIP アドレスは必ず、ルータ自身に設定したものとなり、configured が表示されます。

    B IOS version 12.2(8)T 以前は、Interface Tracking の表示方法が異なります


    brief
    コマンドの出力を簡略化します。



Router-A#show standby brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Et0/0 10 105 P Active local 192.168.1.102 192.168.1.1
Et0/0 20 100 P Standby 192.168.1.102 local 192.168.1.2
Et0/0 30 95 P Standby 192.168.1.102 local 192.168.1.3
Et0/1 100 100 Init unknown unknown 1.1.1.1
Router-A#

    Interface:
      インターフェイス名

    Grp:
      Standby Group 番号

    P:
      Preempt が設定されていることを意味します

    State:
      このルータのHSRP State

    Active:
      Active Rotuer のIP アドレス。自分がActive Router の場合は、local と表示されます

    Standby:
      Standby Rotuer のIP アドレス。自分がStandby Router の場合は、local と表示されます

    Virtual IP:
      Standby Group のバーチャルIP アドレス



show standby delay [Interface Name]

Preempt が働くまでに経過する秒数を表示します。

IOS version 12.2 から使用可能です。

    Interface Name
    特定のインターフェイス上の情報のみ表示する場合に指定します。
    省略した場合は、全てのインターフェイス上の情報が表示されます。



Router-A#show standby delay
Interface Minimum Reload
Ethernet0/0 1 5
Ethernet0/1 1 5
Router-A#


    Minimum:
    インターフェイスがアップしてから、Preempt が稼動するまでの秒数

    Reroad:
    ルータが起動してから、Preempt が稼動するまでの秒数



show standby redirect [Interface Name] [active | passive | timers]

HSRP とICMP Redirect の協調動作に関する情報を表示します。
上から順番に、タイマー情報、Active Router の情報、Passive Router の情報が表示されます。

IOS version 12.2 から使用可能です。

    Interface Name
    特定のインターフェイス上の情報のみ表示する場合に指定します。
    省略した場合は、全てのインターフェイス上の情報が表示されます。

    active
    Actvie Router の情報のみ表示します。

    passive
    Passive Router の情報のみ表示します

    timers
    タイマー情報のみ表示します




Router-A#show standby redirect
Interface Redirects Unknown Adv Holddown
Ethernet0/0 enabled enabled 30 180

Active Hits Interface Group Virtual IP Virtual MAC
local 0 Ethernet0/0 10 192.168.1.1 0000.0c07.ac0a
local 0 Ethernet0/0 20 192.168.1.2 0000.0c07.ac14
192.168.1.103 1 Ethernet0/0 30 192.168.1.3 aabb.cc00.6700
192.168.1.103 0 Ethernet0/0 40 192.168.1.4 aabb.cc00.6700

Passive Hits Interface Expires in
192.168.1.102 0 Ethernet0/0 167.504
Router-A#


    Redirects:
    ICMP Redirect との協調動作の状態を、その下に表示します。
    有効な場合enabled (デフォルト)、no standby redirects もしくはstandby redirects disable を設定した場合は、disabled となります。
    協調動作を無効にした場合でも、Real IP アドレスをRedirect 先とした、通常のICMP Redirect は行われる点に注意してください。

    Unkwon:
    Unkown Router(HSRP を設定していないルータ)へのRedirect の状態を、その下に表示します。
    有効な場合enabled (デフォルト)、no standby redirect unknown を設定した場合は、disabled となります。

    Holddown:
    Passive Router Hold Down Interval の値が表示されます。
    Passive Router Hold Down Interval は、他のルータから受信したAdvertisement メッセージを保持する時間です。

    Active:
    サブネット上に存在する全てのStandby Group の、Active Router のReal IP アドレス。
    自分がActive Router の場合は、local と表示されます。
    自分が参加していないStandby Group も表示されます。

    Hits:
    このルータに、Redirect 先に選ばれた回数
    他のルータからRedirect 先に選ばれた回数は含まれない点に注意してください。

    Passive:
    サブネット上に存在する全てのStandby Group の、Active Router のReal IP アドレス。
    Passive Router は、どのStandby Group でもActive Router となっていないルータを指します。

    Expires in:
    Passive Router リストから、このルータを削除するまでの秒数です。
    Advertisement を受信すると、Passive Router Hold Down Interval の値に戻ります。



show standby capability [Interface Name]


インターフェイスに設定可能なStandby Group の数を表示します。

IOS version 12.2 から使用可能です。

    Interface Name
    特定のインターフェイス上の情報のみ表示する場合に指定します。
    省略した場合は、全てのインターフェイス上の情報が表示されます。



Router#show standby capability
RSP2 * indicates hardware may support HSRP
|
Interface Type H Potential Max Groups
FastEthernet6/0/0 18 cyBus FastEthernet Int * 28 VIP has limited AF entries
FastEthernet6/1/0 18 cyBus FastEthernet Int * 28 VIP has limited AF entries
Virtual-Access1 21 Virtual Access interfa -
Loopback0 83 Loopback -
Router#

    Type:
    Ethernet コントローラの種類。
    Ethernet ではないインターフェイスは、インターフェイスの種類が表示されます。

    H:
    HSRP が設定可能なインターフェイスには、*(アスタリスク) が表示されます。

    Potential Max Groups:
    設定可能なStandby Group の数。
    本来設定可能なStandby Group の数は、0から255の256個です。
    ハードウェアの制限で設定可能な数が限られている場合、その理由が表示されます。



show standby internal [Interface Name]

HSRP の設定内容が、ルータの中でどのように反映されているのかを確認できます。

IOS version 12.2 から使用可能です。

    Interface Name
    特定のインターフェイス上の情報のみ表示する場合に指定します。
    省略した場合は、全てのインターフェイス上の情報が表示されます。



Router-A#show standby internal
Global Confg: 0000, HSRP process running
Et0/0 If hw AmdP2, State 0x210040 (4 cfgd groups on hw)
Et0/0 If hw Confg: 0000
Et0/0 If hw Flags: 0000
Et0/0 If sw Confg: 0000
Et0/0 If sw Flags: 0000
Et0/0 Grp 0 Confg: 0200, TRACK
Et0/0 Grp 0 Flags: 0100, PREEMPT_RELOAD
Et0/0 Grp 10 Confg: 027A, IP_PRI, PRIORITY, PREEMPT, TIMERS, TRACK, AUTH
Et0/0 Grp 10 Flags: 0000
Et0/0 Grp 20 Confg: 023A, IP_PRI, PRIORITY, PREEMPT, TRACK, AUTH
Et0/0 Grp 20 Flags: 0040, ACTIVE_TIMERS
Et0/0 Grp 30 Confg: 023A, IP_PRI, PRIORITY, PREEMPT, TRACK, AUTH
Et0/0 Grp 30 Flags: 0040, ACTIVE_TIMERS
Et0/0 Grp 40 Confg: 0000
Et0/0 Grp 40 Flags: 0041, LEARNT, ACTIVE_TIMERS
Router-A#



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

2006年02月09日

HSRP を究める - 実践編(19) 設定用コマンド(5)

HSRP 関連のコマンド一覧です。


    standby redirects timers
    standby redirects unknown
    standby redirects advertisement authentication md5 key-chain
    standby redirects advertisement authentication md5 key-string


[no] standby redirects timers [Value1] [Value2]

Passive Router が送信するAdvertisement メッセージ関連のタイマー値を設定します。

IOS version 12.2 から使用可能です。

    Value1
    HSRP Router advertisement interval を秒数で設定します。
    10から180の間から選択可能です。
    このコマンドを設定しない場合は、デフォルト値の60が選択されます。

    Value2
    HSRP router holddown interval を秒数で設定します。
    61から3600の間から選択可能です。
    このコマンドを設定しない場合は、デフォルト値の180が選択されます。

コマンドの先頭にno を付けると、デフォルト値に戻すことができます。



[no] standby redirects unknown

Unknown Router をRedirect 先に指定することを有効にします。

Unknown Router へのRedirect は、デフォルトで有効になっており、running-config やstartup-config には表示されません。
コマンドの先頭にno を付けると、この機能を無効にすることができます。

IOS version 12.2 から使用可能です。



[no] standby redirects advertisement authentication md5 key-chain [Word]

Passive Router が送信するAdvertisement メッセージの認証を行うことを指定します。
認証に失敗すると、Advertiseent メッセージは無視され、holddown interval を過ぎると、Passive Router リストから削除されます。
Passive Router リストから削除されると、Unkown Router として、Redirect 先の対象となります。

key-chain の設定については、standby authentication md5 key-chain コマンドを参照して下さい。

このコマンドは、IOS version 12.4 のCommand Reference に載っていませんが、CLI のHelp には表示されています。



Router-A(config-if)#standby redirect ?
advertisement Redirect advertisement messages
timers Adjust redirect timers
unknown Redirect to non-HSRP routers

Router-A(config-if)#standby redirect

設定自体は有効に動作することは確認しましたが、正式サポートされていない機能ということで、Cisco からのサポートが受けられない可能性があります。
このコマンドの使用を検討される際は、購入元経由でCisco に確認を取ることをお奨めします。



[no] standby redirects advertisement authentication md5 key-string [0 | 7] [Word] [Timeout] [Value]

Passive Router が送信するAdvertisement メッセージの認証を行うことを指定します。
認証に失敗すると、Advertiseent メッセージは無視され、holddown interval を過ぎると、Passive Router リストから削除されます。
Passive Router リストから削除されると、Unkown Router として、Redirect 先の対象となります。

key-chain の設定については、standby authentication md5 key-string コマンドを参照して下さい。

このコマンドは、IOS version 12.4 のCommand Reference に載っていませんが、CLI のHelp には表示されています。



Router-A(config-if)#standby redirect ?
advertisement Redirect advertisement messages
timers Adjust redirect timers
unknown Redirect to non-HSRP routers

Router-A(config-if)#standby redirect

設定自体は有効に動作することは確認しましたが、正式サポートされていない機能ということで、Cisco からのサポートが受けられない可能性があります。
このコマンドの使用を検討される際は、購入元経由でCisco に確認を取ることをお奨めします。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(18) 設定用コマンド(4)

HSRP 関連のコマンド一覧です。


standby mac-address
standby use-bia
standby version
standby sso
standby redirects
standby redirects [disable | enable]


[no] standby [Group Number] mac-address [MAC Address]

Standby Group のVirtual MAC アドレスを指定します。
BIA を使わない限り、通常は00-00-0c-07-ac-xx がVirtual MAC アドレスとして使われます。
APPN(Advanced Peer to Peer Network) を使用している環境では、端末は、DLUR(Dependent Logical-Unit Requester) Router に設定されたVirtual MAC アドレスへ、接続要求を送信します。
Active Router の使用するVirtual MAC アドレスを、APPN と一致させるための手段として、このコマンドが使われます。

IOS version 11.2 から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    MAC Address
    MAC アドレスを指定します。

コマンドの先頭にno を付けると、設定を削除できます。

standby use-bia を使用しているときは、設定できません。

MAC アドレスの重複によるトラブルを防ぐため、特に必要がない場合は、Virtual MAC アドレスの変更は行わない方が良いでしょう。


[no] standby use-bia

Active Router となっているときに使うMAC アドレスを、バーチャルMAC アドレスから、BIA(Burnt In Address) に変更します。

IOS version 11.2 から使用可能です。

コマンドの先頭にno を付けると、設定を削除できます。



[no] standby version [1 | 2]

HSRP のバージョンを指定します。
指定しない場合は、バージョン1が選択されます。

HSRP バージョン2 では、Standby Group 番号を0から4095の間で設定できます。

コマンドの先頭にno を付けると、設定を削除できます。
ただし、256 以上のStandby Group 番号を設定している場合は、削除できません。

HSRP バージョン2で使われるバーチャルMAC アドレス は、00-00-0C-9F-Fx-xx となります。

    x-xx に、Standby Group 番号を16進数にした値が入ります

IOS version 12.3(4)T から使用可能です。

    1
    HSRP バージョン1を指定します。

    2
    HSRP バージョン2を指定します。



[no] standby sso

SSO(Statefull Switch Over) によるRoute Processor の二重化を行っているルータで使用します。

Route Processor の切り替わり発生時、切替わりが完了するまでの間に他のルータがActive Router になることを防ぎます。
Standby RP がActive になる前に、HSRP の機能を先に肩代わりすることで、切替わり中にもActive Router として動作することができます。

SSO を設定してあるルータでは、自動的にこの機能が有効になります。
コマンドの先頭にno を付けると、この機能を無効にすることができます。

IOS version 12.2(25)S から使用可能です。



[no] standby redirects

HSRP とICMP Redirect の協調動作を有効にします。

HSRP とICMP Redirect の協調動作は、デフォルトで有効になっており、running-config やstartup-config には表示されません。
コマンドの先頭にno を付けると、この機能を無効にすることができます。

IOS version 12.1(3)T から使用可能です。

ICMP Redirect 自体が有効な場合(ip redirects コマンド)、この機能を無効にすると、以下の警告メッセージが表示されますが、協調動作は無効になります。



Router-A(config-if)#no standby redirect
% ICMP redirects are enabled on the interface.
Router-A(config-if)#

HSRP とICMP Redirect の協調動作を無効にすると、Redirect 先のIP アドレスは、Virtual IP アドレスではなく、Real IP アドレスが指定されます。

このコマンドは、インターフェイス単位で設定できますが、グローバルコンフィグレーションモードで設定することで、すべてのインターフェイスで有効、または無効にすることもできます。



Router-A(config)#no standby redirects
Router-A(config)#



standby redirects [disable | enable]

HSRP とICMP Redirect の協調動作を有効、または無効にします。
グローバルコンフィグレーションモードで使用します。

[no] standby redirect を、グローバルコンフィグレーションモードで使用するのと同じです。

IOS version 12.1(3)T から使用可能です。

    disable
    HSRP とICMP Reriect の協調動作を無効にします。

    enable
    HSRP とICMP Reriect の協調動作を有効にします。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(17) 設定用コマンド(3)

HSRP 関連のコマンド一覧です。


    standby authentication
    standby authentication md5 key-string
    standby authentication md5 key-chain


[no] standby [Group Number] authentication [text] [Word]

認証用の文字列を設定します。

IOS version 10.0 から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 10.3 から、Group 番号を指定できるようになりました。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    text
    認証文字列が平文(プレインテキスト)であることを指定します。
    IOS version 12.1 から使用可能になりました。
    IOS version 12.1 以降でも、省略して、直接文字列を入力することもできます。

    Word
    認証文字列を設定します。
    半角で101文字までです。
    英数字と、? 以外の記号 -=\`!@#$%^&*()_+|~[]{};':",./<> が、使用できます。

コマンドの先頭にno を付けると、設定を削除できます。



[no] standby [Group Number] authentication md5 key-string [0 | 7] [Word] [Timeout] [Value]

ハッシュアルゴリズムにMD5 を使って、認証文字列の暗号化を行います。
IOS version 12.3(2)T から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    0
    キーを暗号化しないことを指定します。
    省略した場合は、暗号化しないことを意味します。

    7
    キーを暗号化することを指定します。
    省略した場合は、暗号化しないことを意味します。

    Word
    キー文字列を入力します。
    半角で64文字までです。
    英数字と、? 以外の記号 -=\`!@#$%^&*()_+|~[]{};':",./<> が、使用できます。

    Timeout
    キーを変更する際は、Active Router 以外のルータを先に変更し、Active Router は最後に変更する必要があります。

    Timeout は、キーの設定変更をしている間、Active Router から受け取る古いキーを、何秒間許容するかを指定します。

    許容している秒数が経過すると、認証に失敗したことを意味するメッセージを出力し、Active Router になろうとします。

    つまり、Standby Group に所属するすべてのルータで、キーを変更し終えるのに必要な時間を設定する必要があります。

    許容されるのは、Active Router からの古いキーだけです。
    Active Router からの新しいキーは許容されないため、Active Router からキーの変更を始めると、他のルータは即座に認証失敗のメッセージを表示し、Active Router になろうとします。

    他のルータからの新しいキーは、即座に認証失敗と判断され、メッセージが表示されますが、Active Router との間で同じキーを使っている限りActive Router になろうとはしないので、問題ありません。

    Cisco は、Active Router でキーの変更をした場合、古いキーを保持するのは(Timeout で設定した値ではなく) Hold Time の間だけと述べていますが、実際にはTimeout 値の方が有効なようです。
    しかし、結局のところ、Active Router のキーを変更すると、即座に他のルータがActive Router になろうとしてしまうので、やはりActive Router のキーは最後に設定しなければなりません。



The active router should have its key string changed no later than one holdtime period, specified by the standby timers interface configuration command, after the non-active routers.

    IOS version 12.4 で確認したところ、記号の! で始まるkey-string を指定すると、Timeout オプションが表示されません(そのほかの記号は大丈夫です)。
    ! で始まるKey-string が使えないわけではありません。



Router-A(config-if)#standby 10 authentication md5 key-string !test-key ?
0 Specifies an UNENCRYPTED key string will follow
7 Specifies a HIDDEN key string will follow
WORD Key string (64 chars max)

Router-A(config-if)#standby 10 authentication md5 key-string !test-key

    Timeout は表示されませんが、直接入力することは可能です。



Router-A(config-if)#standby 10 authentication md5 key-string !key ?
0 Specifies an UNENCRYPTED key string will follow
7 Specifies a HIDDEN key string will follow
WORD Key string (64 chars max)

Router-A(config-if)#standby 10 authentication md5 key-string !key timeout 10
Router-A(config-if)#

    Value
    0から32767の間で指定可能です。

コマンドの先頭にno を付けると、設定を削除できます。

Cisco は、Key の長さを16文字以上にすることを推奨しています。


The key can contain up to 64 characters. We recommend using at least 16 characters.



[no] standby [Group Number] authentication md5 key-chain [Word]

ハッシュアルゴリズムにMD5 を使って、認証文字列の暗号化を行います。
key chain コマンドで事前に作成した、キーチェインを用いる場合に使用します。
IOS version 12.3(2)T から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    Word
    key chain コマンドで作成したキーチェインの名前を指定します。

コマンドの先頭にno を付けると、設定を削除できます。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(16) 設定用コマンド(2)

HSRP 関連のコマンド一覧です。


    standby preempt dealy sync
    standby priority
    standby track
    standby timers



[no] standby [Group Number] preempt dealy sync [value]

Stateful NAT など、複数のルータ間で機能を冗長化している場合に使用します。
ルータの切り替わりに際して、アドレス変換テーブルなどの情報の同期が完了するまで、HSRP のActive Router 切り替わりを遅らせる秒数を指定します。

IOS version 12.0(2)T から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    Value
    Preempt が働くまでの間隔を秒数で指定します。
    0から3600で指定可能です。

コマンドの先頭にno を付けると、設定を削除できます。

※ preempt delay minumum / reload / sync コマンドも一括で実行可能です。

    例:standby 30 preempt delay minimum 10 reload 30 sync 30


[no] standby [Group Number] priority [Value]

HSRP のプライオリティを指定します。
値が大きいほど、プライオリティが高くなります。

IOS version 11.3 から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    Value
    プライオリティを0から255の間で指定します。

コマンドの先頭にno を付けると、設定を削除できます。

以前は、Preempt の設定も同時に行うこともできましたが、IOS version 12.2 からは、別なコマンドになりました。



[no] standby [Group Number] track [Interface Name] [Value]

Interface tracking の監視対象インターフェイスと、プライオリティの下げ幅を指定します。
トラックしているインターフェイスがダウンすると、プライオリティを下げることで、他のルータがActive Router になることを促します。
下げ幅は、他のルータがActive Router になれるように考慮する必要があります。

IOS version 10.3 から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    Interface Name
    監視対象のインターフェイスを指定します。

    Value
    プライオリティの下げ幅を指定します。
    指定しない場合は、10が選択されます。

コマンドの先頭にno を付けると、設定を削除できます。



[no] standby [Group Number] timers [msec1] [Hello] [msec2] [Hold]

HSRP で使用するタイマー値を設定します。
IOS version 10.0 から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 10.3 から、Group 番号を指定できるようになりました。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    msec1
    Hello Time をミリ秒単位で設定することを指定します。
    省略した場合は、秒単位になります。
    IOS version 11.2 から指定可能になりました。

    Hello
    Hello Time を設定します。
    秒単位の場合は、1から254の間で指定可能です。
    ミリ秒単位の場合は、15から999の間で指定可能です。

    msec2
    Hold Time をミリ秒単位で設定することを指定します。
    省略した場合は、秒単位になります。
    Hello Time を秒単位で設定した場合、msec2は指定できません。
    IOS version 11.2 から指定可能になりました。

    Hold
    Hold Time を設定します。
    秒単位の場合は、Hello Time の値 + 1から255の間で指定可能です。
    ミリ秒単位の場合、

      Hello Time の3倍が50未満の場合(15、16)、50から3000の間
      Hello Time の3倍が50以上の場合、Hello Time の3倍から3000の間

    で指定可能です。

コマンドの先頭にno を付けると、設定を削除できます。

Cisco は、Hold Time を250ミリ秒未満にした場合、HSRP State のフラッピングが起こる可能性を指摘しています。
また、Cisco7200 より小型のルータ、100Mbps 未満の低速インターフェイスで、Hold Time を250ミリ秒未満にしないことを推奨しています。

フラッピングが発生すると、CPU の使用率が高騰し、他の機能へ影響することがあります。
process-max-time を使用することで、単一のプロセスがCPU を占有することを防ぐ方法が提示されています。
確かにCPU の占有は防げますが、フラッピングは防げませんので本末転倒です。

Cisco IOS IP Application Services Commands, Release 12.2
"standby timers" から抜粋

Some HSRP state flapping can occasionally occur if the holdtime is set to less than 250 milliseconds, and the processor is busy. It is recommended that holdtime values less than 250 milliseconds be used on Cisco 7200 platforms or better, and on Fast-Ethernet or FDDI interfaces or better. Setting the process-max-time command to a suitable value may also help with flapping.

通常Hello Time やHold Time は、他のルータのHello メッセージから学習できますが、ミリ秒単位で設定された値は学習されません。
同じ値を、全てのルータに設定する必要があります。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(15) 設定用コマンド(1)

HSRP 関連のコマンド一覧です。


    standby ip
    standby name
    standby preemp
    standby preempt delay minimum
    standby preempt dealy reload



[no] standby [Group Number] ip [IP Address] [Secondary]

Standby Group のバーチャルIP アドレスを設定します。
IOS version 10.0 から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 10.3 から、Group 番号を指定できるようになりました。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    IP Address
    Standby Group のバーチャルIP アドレス

    Sencondary
    [IP Address] で設定したバーチャルIP アドレスが、Secondary アドレスであること意味します。
    IOS version 11.1 から指定可能になりました。

コマンドの先頭にno を付けると、設定を削除できます。


[no] standby [Group Number] name [Group Name]

Standby Group に設定する名前を指定します。
IOS version 12.0(2)T から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 10.3 から、Group 番号を指定できるようになりました。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    Group Name
    Standby Group の名前。
    半角で101文字までです。
    英数字と、? 以外の記号 -=\`!@#$%^&*()_+|~[]{};':",./<> が、使用できます。

コマンドの先頭にno を付けると、設定を削除できます。


[no] standby [Group Number] preempt

Preempt を有効にします。
IOS version 11.3 から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 10.3 から、Group 番号を指定できるようになりました。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

コマンドの先頭にno を付けると、設定を削除できます。

以前は、Preempt の設定も同時に行うこともできましたが、IOS version 12.2 からは、別なコマンドになりました。

    例:standby 10 priority 105 preempt

※ preempt delay minumum / reload/ sync コマンドも一括で実行可能です。

    例:standby 30 preempt delay minimum 10 reload 30 sync 30


[no] standby [Group Number] preempt delay minimum [Value]

インターフェイスがアップしてから、Preempt によりActive Router に切り替わるまでの時間を調整できます。

IOS version 12.0(2)T から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    Value
    Preempt が働くまでの間隔を秒数で指定します。
    0から3600で指定可能です。

コマンドの先頭にno を付けると、設定を削除できます。

Cisco のConfiguration Guide には、「ルータが起動してからの秒数」と、間違いではありませんが、すべてを説明しきれていません。
起動直後にインターフェイスがアップした時にも、この値は有効ですが、実際にはshutdown していたインターフェイスをno shutdown してアップしたときにも有効です。

Preempt を遅らせることで、ルーティングプロトコルのコンバージェンスが完了するまでに、Active Router となってしまうことを回避できます。


※ preempt delay minumum / reload/ sync コマンドも一括で実行可能です。

    例:standby 30 preempt delay minimum 10 reload 30 sync 30


[no] standby [Group Number] preempt dealy reload [value]

インターフェイスがアップしてから、Preempt によりActive Router に切り替わるまでの時間を調整できます。
ルータが起動後、最初にインターフェイスがアップしたときのみ有効です。

IOS version 12.2 から使用可能です。

    Group Number
    Standby Group 番号。0から255まで指定できます。
    指定しない場合、0が選択されます。
    IOS version 12.3(4)T からサポートされるHSRP version 2 を使用する場合は、0から4095まで指定できます。

    Value
    Preempt が働くまでの間隔を秒数で指定します。
    0から3600で指定可能です。

コマンドの先頭にno を付けると、設定を削除できます。

Preempt を遅らせることで、ルーティングプロトコルのコンバージェンスが完了するまでに、Active Router となってしまうことを回避できます。

※ preempt delay minumum / reload/ sync コマンドも一括で実行可能です。

    例:standby 30 preempt delay minimum 10 reload 30 sync 30



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編 (14) ICMP Redirect (3) Unknown Router

Redirect 先が、HSRP のStandby Group に参加してなかったらどうでしょうか?

本ページでは、Debug コマンドを使用します。
本ページの内容を実際に試される場合は、事前に「Debug コマンドについて」をお読みください。

Router-A のルーティングテーブルを確認します。



Router-A#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 4 subnets
C 1.1.1.101 is directly connected, Loopback0
O 1.1.1.103 [110/11] via 192.168.1.103, 00:01:37, Ethernet0/0
O 1.1.1.102 [110/11] via 192.168.1.102, 00:01:37, Ethernet0/0
O 1.1.1.104 [110/75] via 192.168.1.103, 00:01:37, Ethernet0/0
[110/75] via 192.168.1.102, 00:01:37, Ethernet0/0
O 192.168.4.0/24 [110/74] via 192.168.1.103, 00:01:37, Ethernet0/0
O 192.168.5.0/24 [110/84] via 192.168.1.103, 00:01:37, Ethernet0/0
[110/84] via 192.168.1.102, 00:01:37, Ethernet0/0
C 192.168.1.0/24 is directly connected, Ethernet0/0
C 192.168.2.0/24 is directly connected, Serial2/0
O 192.168.3.0/24 [110/74] via 192.168.1.102, 00:01:37, Ethernet0/0
Router-A#

192.168.5.0/24 へ到達するためのNext Hop は、先のページから引き続き、Router-B、C のReal IP アドレス(Ethernet0/0) を指しています。


上図では、Router-C からHSRP の設定を全て削除してあります。



Router-C#show running-config interface ethernet0/0
Building configuration...

Current configuration : 69 bytes
!
interface Ethernet0/0
ip address 192.168.1.103 255.255.255.0
end

Router-C#

Router-A でshow standby redirect を確認します。



Router-A#show standby redirect
Interface Redirects Unknown Adv Holddown
Ethernet0/0 enabled enabled 10 180

Active Hits Interface Group Virtual IP Virtual MAC
unknown 0 Ethernet0/0 0 unknown unknown
local 0 Ethernet0/0 10 192.168.1.1 0000.0c07.ac0a
local 0 Ethernet0/0 20 192.168.1.2 0000.0c07.ac14
local 0 Ethernet0/0 30 192.168.1.3 0000.0c07.ac1e

Passive Hits Interface Expires in
192.168.1.103 25 Ethernet0/0 81.236
192.168.1.102 0 Ethernet0/0 178.336
Router-A#

まだRouter-C(192.168.1.103) がPassive Router として残っています。
HSRP を無効にしたRouter-C からのAdvertisement メッセージを受信しなくなって、180秒経過するまでは、Passive Router として認識されています。
(Passive Router Hold Down Interval のデフォルト値は180秒)

約3分待って、もう一度show standby redirect を確認します。



Router-A#show standby redirect
Interface Redirects Unknown Adv Holddown
Ethernet0/0 enabled enabled 10 180

Active Hits Interface Group Virtual IP Virtual MAC
unknown 0 Ethernet0/0 0 unknown unknown
local 0 Ethernet0/0 10 192.168.1.1 0000.0c07.ac0a
local 0 Ethernet0/0 20 192.168.1.2 0000.0c07.ac14
local 0 Ethernet0/0 30 192.168.1.3 0000.0c07.ac1e

Passive Hits Interface Expires in
192.168.1.102 0 Ethernet0/0 176.688

Router-A#

Passive Router のリストから、Router-B(192.168.1.103) が消えました。


では、PC1 からPC4(192.168.5.105) へPing を打ってみます。

Router-A のコンソールです。



Router-A#
Router-A#
Feb 8 10:05:43.667: ICMP: Use HSRP virtual address 192.168.1.1 as ICMP src
Feb 8 10:05:43.667: ICMP: redirect sent to 192.168.1.201 for dest 192.168.5.105, use gw 192.168.1.103
Router-A#

1行目で、ICMP Redirect の送信元IP アドレスを、自分がActive Router となっている、Standby Group 10 のバーチャルルータ(192.168.1.1) へ変更しています。

※ PC1 の実装によっては、デフォルトゲートウェイ(192.168.1.1) ではないルータから送られてきたICMP Redirect を無視するものもあります。
無視されてRedirect に失敗するのを回避するため、送信元IP アドレスをVirtual IP アドレスに変更しています。

2行目で、ICMP Redirect をPC1 へ送信しています。

192.168.5.105 へ到達するためのゲートウェイが、192.168.1.103 になりました。


今回のRouter-C のようにHSRP が設定されていないルータを、HSRP では、Unknown Router と呼びます。




HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router

今度は、Router-A を、全てのStandby Group のActive Router にした状態で、ICMP Redirect の動作を見ていきます。

本ページでは、Debug コマンドを使用します。
本ページの内容を実際に試される場合は、事前に「Debug コマンドについて」をお読みください。


Router-A のルーティングテーブルを確認します。



Router-A#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 4 subnets
C 1.1.1.101 is directly connected, Loopback0
O 1.1.1.103 [110/11] via 192.168.1.103, 00:01:37, Ethernet0/0
O 1.1.1.102 [110/11] via 192.168.1.102, 00:01:37, Ethernet0/0
O 1.1.1.104 [110/75] via 192.168.1.103, 00:01:37, Ethernet0/0
[110/75] via 192.168.1.102, 00:01:37, Ethernet0/0
O 192.168.4.0/24 [110/74] via 192.168.1.103, 00:01:37, Ethernet0/0
O 192.168.5.0/24 [110/84] via 192.168.1.103, 00:01:37, Ethernet0/0
[110/84] via 192.168.1.102, 00:01:37, Ethernet0/0
C 192.168.1.0/24 is directly connected, Ethernet0/0
C 192.168.2.0/24 is directly connected, Serial2/0
O 192.168.3.0/24 [110/74] via 192.168.1.102, 00:01:37, Ethernet0/0
Router-A#

192.168.5.0/24 へ到達するためのNext Hop は、先のページから引き続き、Router-B、C のReal IP アドレス(Ethernet0/0) を指しています。


Router-A で、Standby Group 20、30 のプライオリティを110 に上げます。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/0
Router-A(config-if)#standby 10 priority 110
Router-A(config-if)#standby 20 priority 110
Router-A(config-if)#standby 30 priority 110

Router-A(config-if)#^Z
Router-A#

Router-A で、show standby brief を確認します。



Router-A#show standby brief P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Et0/0 10 110 P Active local 192.168.1.103 192.168.1.1
Et0/0 20 110 P Active local 192.168.1.102 192.168.1.2
Et0/0 30 110 P Active local 192.168.1.103 192.168.1.3
Router-A#

全てのStandby Group で、Router-A がActive Router になっています。

Router-A で、show standby redirect を確認します。



Router-A#show standby redirect
Interface Redirects Unknown Adv Holddown
Ethernet0/0 enabled enabled 30 180

Active Hits Interface Group Virtual IP Virtual MAC
local 0 Ethernet0/0 10 192.168.1.1 0000.0c07.ac0a
local 0 Ethernet0/0 20 192.168.1.2 0000.0c07.ac14
local 0 Ethernet0/0 30 192.168.1.3 0000.0c07.ac1e

Passive Hits Interface Expires in
192.168.1.103 2 Ethernet0/0 154.812
192.168.1.102 1 Ethernet0/0 158.604

Router-A#

Router-B とC がPassive Router になっています。


PC1 からPC2(192.168.5.105) へPing を打ちます。

Router-A のコンソールです。



Router-A#
Feb 8 09:34:43.426: ICMP: redirect not sent to 192.168.1.201 for dest 192.168.5.105
Feb 8 09:34:43.426: ICMP: 192.168.1.103 does not contain an active HSRP group

Router-A#

リダイレクト先のRouter-3(192.168.1.103) がPassive Router なので、Redirect してはいけないと判断され、ICMP Redirect は行われません。

PC1 からPC5 宛のパケットは、Router-A によってルーティングされ続けます。




HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router

このページでは、全てのルータをIOS version 12.4 で動作させます。
HSRP のICMP Redirect との協調機能は、IOS version 12.0 ではサポートされていないからです。

本ページでは、Debug コマンドを使用します。
本ページの内容を実際に試される場合は、事前に「Debug コマンドについて」をお読みください。


この機能がサポートされていないルータは、Advertisement メッセージを送信することができません。
Advertisement を送信できないと、他のルータ(Active、Standby) に存在を知らせることができないため、Passive Router であるにもかかわらず、Redirect 先に選ばれてしまう可能性があります。

Passive Router とは、Standby Group に参加しており、且つ、どのGroup のActive Router にもなっていない物を指します。

Cisco は、(正常動作時に)Passive Router が存在するようなネットワークは、ミスコンフィグレーションだと言っています。

Cisco IOS IP Configuration Guide, Release 12.2
"Redirects to Passive HSRP Routers" から抜粋

A network configuration with passive HSRP routers is considered a misconfiguration. For HSRP ICMP redirection to operate optimally, every router on the network that is running HSRP should contain at least one active HSRP group.

ミスコンフィグは少し言い過ぎのような気もします。
Passive Router は、Active Router になっているStandby Group がひとつもないルータであり、リソースが有効に使われないのは事実です。
「好ましくない構成」が妥当でしょう。


※ 先のページでshutdown した、Router-A のSerial 2/0 をno shutdown しておいてください。

Router-A で、debug ip icmp を実行しておきます。



Router-A#debug ip icmp
ICMP packet debugging is on
Router-A#

PC1 のデフォルトゲートウェイは、Standby Group 10 のバーチャルルータ(Router-A) になっています。

ここで、Router-A のSerial 2/0 で、OSPF のCost を10000 に変更します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface serial 2/0
Router-A(config-if)#ip ospf cost 10000
Router-A(config-if)#^Z
Router-A#

Router-A のルーティングテーブルを確認します。



Router-A#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 4 subnets
C 1.1.1.101 is directly connected, Loopback0
O 1.1.1.103 [110/11] via 192.168.1.103, 00:01:37, Ethernet0/0
O 1.1.1.102 [110/11] via 192.168.1.102, 00:01:37, Ethernet0/0
O 1.1.1.104 [110/75] via 192.168.1.103, 00:01:37, Ethernet0/0
[110/75] via 192.168.1.102, 00:01:37, Ethernet0/0
O 192.168.4.0/24 [110/74] via 192.168.1.103, 00:01:37, Ethernet0/0
O 192.168.5.0/24 [110/84] via 192.168.1.103, 00:01:37, Ethernet0/0
[110/84] via 192.168.1.102, 00:01:37, Ethernet0/0
C 192.168.1.0/24 is directly connected, Ethernet0/0
C 192.168.2.0/24 is directly connected, Serial2/0
O 192.168.3.0/24 [110/74] via 192.168.1.102, 00:01:37, Ethernet0/0
Router-A#

192.168.5.0/24 へ到達するためのNext Hop が、Router-B、C のReal IP アドレス(Ethernet0/0) に変わりました。

PC1 からPC2(192.168.5.105) へPing を打ちます。


Router-A のコンソールです。



Feb 8 08:48:18.935: ICMP: HSRP changing redirect sent to 192.168.1.201 for dest 192.168.5.105
Feb 8 08:48:18.935: ICMP: gw 192.168.1.103 -> 192.168.1.3, src 192.168.1.1
Feb 8 08:48:18.935: ICMP: Use HSRP virtual address 192.168.1.1 as ICMP src
Feb 8 08:48:18.935: ICMP: redirect sent to 192.168.1.201 for dest 192.168.5.105, use gw 192.168.1.3
Router-A#
Router-A#

1行目のメッセージで、Router-A は、PC1 へICMP Redirect を送信しようとします。
2行目で、Next Hop のゲートウェイをRouter-B のReal IP(192.168.1.103)から、Router-B がActive Router となっている、Standby Group 30のバーチャルルータ(192.168.1.3) へ変更しています。
Redirect の送信元IP アドレスも、本来はRouter-A のReal IP アドレスですが、自分がActive Router となっている、Standby Group 10 のバーチャルルータ(192.168.1.1) へ変更しています。

※ PC1 の実装によっては、デフォルトゲートウェイ(192.168.1.1) ではないルータから送られてきたICMP Redirect を無視するものもあります。
無視されてRedirect に失敗するのを回避するため、送信元IP アドレスをVirtual IP アドレスに変更しています。

4行目で、ICMP Redirect をPC1 へ送信しています。

192.168.5.105 へ到達するためのゲートウェイが、192.168.1.3 になりました。

Router-B に不具合が発生しても、他のルータがActive Router となることで、通信を継続することができます。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(11) Standby Group に名前を付ける

これまで番号で呼んできたStandby Group ですが、名前を付けることもできます。

名前は付けられるのですが、Hello メッセージで伝播できるわけではなく、一台ずつ手で設定しなければならないこともあり、あまり実用的ではありません。

ここでは、簡単に紹介するにとどめます。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/0
Router-A(config-if)#standby 10 name Engineering_Division
Router-A(config-if)#^Z
Router-A#

Router-A のStandby Group 10 に、"Engineering_Division" という名前を付けました。

show standby で確認できます。



Router-A#show standby
Ethernet0/0 - Group 10
State is Listen
41 state changes, last state change 00:22:30
Virtual IP address is 192.168.1.1
Active virtual MAC address is aabb.cc00.6700
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Authentication text "smartnet"
Preemption enabled
Active router is 192.168.1.103, priority 100 (expires in 7.512 sec)
Standby router is 192.168.1.102, priority 95 (expires in 8.364 sec)
Priority 90 (configured 105)
Track interface Serial2/0 state Down decrement 15
IP redundancy name is "Engineering_Division" (cfgd)
Ethernet0/0 - Group 20
State is Listen
5 state changes, last state change 00:22:31
Virtual IP address is 192.168.1.2
<省略>
Track interface Serial2/0 state Down decrement 15
IP redundancy name is "hsrp-Et0/0-30" (default)
Router-A#

standby name コマンドは、IOS version 12.0(2)T からサポートされています。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)

三つのStandby Group へ、バランスよく負荷分散ができたところで、障害を発生させて、状況の変化を観察してみましょう。

Router-A のSerial 2/0 をshutdown してみます。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface serial 2/0
Router-A(config-if)#shutdown
Router-A(config-if)#^Z
Router-A#
Feb 7 04:06:32.231: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.104 on Serial2/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Feb 7 04:06:32.735: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 20 state Standby -> Listen
Router-A#
Feb 7 04:06:33.071: %SYS-5-CONFIG_I: Configured from console by console
Feb 7 04:06:33.583: %IP-4-DUPADDR: Duplicate address 192.168.1.1 on Ethernet0/0, sourced by aabb.cc00.6700
Feb 7 04:06:33.583: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> Speak
Router-A#
Feb 7 04:06:34.231: %LINK-5-CHANGED: Interface Serial2/0, changed state to administratively down
Feb 7 04:06:35.235: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, changed state to down
Router-A#

Tracking しているSerial 2/0 に障害が発生すると、Router-A は、各Standby Group のプライオリティを15 下げます。

プライオリティが90 になったGroup 10 は、Router-C がActive Router になり、Router-A は、Active からListen に変わります。
Router-B は、Listen からStandby Router に昇格します。

プライオリティが85 になったGroup 20 は、Router-C がStandby Router になり、Router-A は、Standby Router からListen に変わります。

プライオリティが80 になったGroup 30 は、元々Listen なので、変化はありません。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編 (9) Standby Group を追加する

これまで、三台のルータにStandby Group を設定して、バーチャルルータによるゲートウェイの冗長化をPC に対して提供してきました。

今は下図のようになっています。

どのルータにも不具合がない場合、Active Router は、Router-A の一台だけです。
PC1〜3から、PC4 へのパケットはすべてRouter-A によって処理され、Router-B、C は待機しているだけです。

このままでは、待機しているだけのルータとシリアル回線が使われないままになります。
三台のルータがそれぞれActive Router となれるように、三つのStandby Group を作成して、三台のPC が別々のバーチャルルータをデフォルトゲートウェイとすれば、負荷も分散できますし、リソースの有効利用にもなります。

まずは、Router-A に、Standby Group 20、30 を追加します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/0
Router-A(config-if)#standby 20 ip 192.168.1.2
Router-A(config-if)#standby 20 preempt
Router-A(config-if)#standby 20 track serial 2/0 10
Router-A(config-if)#standby 20 authentication smartnetworks
Router-A(config-if)#
Router-A(config-if)#standby 30 ip 192.168.1.3
Router-A(config-if)#standby 30 preempt
Router-A(config-if)#standby 30 track serial 2/0
Router-A(config-if)#standby 30 authentication smartnetworks
Router-A(config-if)#^Z
Router-A#

同じ設定を、Router-B、C にもします。

Router-B は問題なく設定できますが、Router-C に設定しようとすると、できません。



Router-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-C(config)#interface ethernet0/0
Router-C(config-if)#standby 20 ip 192.168.1.2
% Interface hardware cannot support multiple groups.
Router-C(config-if)#

複数のStandby Group はサポートされていない、というメッセージです。
show interface を確認してみます。



Router-C#show interface ethernet0/0
Ethernet0/0 is up, line protocol is up
Hardware is Lance, address is aabb.cc00.6700 (bia aabb.cc00.6700)
Internet address is 192.168.1.103/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 19 drops; input queue 0/75, 0 drops, 0 flushes
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
201691 packets input, 22145528 bytes, 0 no buffer
Received 23124 broadcasts, 0 runts, 0 giants, 0 throttles
70 input errors, 0 CRC, 0 frame, 0 overrun, 70 ignored
0 input packets with dribble condition detected
187226 packets output, 20958872 bytes, 0 underruns
0 output errors, 0 collisions, 12 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Router-C#

Ethernet コントローラがLance なのが原因です。
Ethernet コントローラにLance またはPQUICC を採用しているルータは、複数のMAC アドレスを同時に使用することはできません。

※ Lance、PQUICC については、こちらを参照してください。

Router-C で複数のStandby Group をつくるために、Virtual MAC アドレスではなく、BIA(Burnt In Address) を使うことにします。



Router-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-C(config)#interface ethernet0/0
Router-C(config-if)#standby use-bia
Router-C(config-if)# standby 20 ip 192.168.1.2
Router-C(config-if)# standby 20 preempt
Router-C(config-if)# standby 20 authentication smartnet
Router-C(config-if)# standby 20 track Serial2/0
Router-C(config-if)# standby 30 ip 192.168.1.3
Router-C(config-if)# standby 30 preempt
Router-C(config-if)# standby 30 authentication smartnet
Router-C(config-if)# standby 30 track Serial2/0
Router-C(config-if)#^Z
Router-C#

これで三台全部に三つのStandby Group を作成できました。
PC のデフォルトゲートウェイを、次のように変更します。

PC1 --> 192.168.1.1 (Standby Group 10)
PC2 --> 192.168.1.2 (Standby Group 20)
PC3 --> 192.168.1.3 (Standby Group 30)

追加で作成したStandby Group 20 と30 のActive Router が、Router-C に偏っています。
これは、Group 20、30 にプライオリティが設定されていないからです。
ルータのReal IP アドレスが比較され、一番大きいRouter-C がActive Router となっています。(Group 10 は、プライオリティが105 のRouter-A がActive)

三台のルータが、下記のように、それぞれ別なGroup のActive Router となるよう、プライオリティを操作する必要があります。


Router-A -- Group 10 Active, Group 20 Standby
Router-B -- Group 20 Active, Group 30 Standby
Router-C -- Group 30 Active, Group 10 Standby

Active Router となるGroup にはプライオリティを105に、Standby Router となるGroup には100、Listen となるGroup には95 と設定します。
Interface Tracking によるプライオリティの下げ幅を15にします。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/0
Router-A(config-if)#standby 10 priority 105
Router-A(config-if)#standby 20 priority 100
Router-A(config-if)#standby 30 priority 95
Router-A(config-if)#standby 10 track serial 2/0 15
Router-A(config-if)#standby 20 track serial 2/0 15
Router-A(config-if)#standby 30 track serial 2/0 15
Router-A(config-if)#^Z
Router-A#



Router-B#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-B(config)#interface ethernet0/0
Router-B(config-if)#standby 10 priority 95
Router-B(config-if)#standby 20 priority 105
Router-B(config-if)#standby 30 priority 100
Router-B(config-if)#standby 10 track serial 2/0 15
Router-B(config-if)#standby 20 track serial 2/0 15
Router-B(config-if)#standby 30 track serial 2/0 15
Router-B(config-if)#^Z
Router-B#



Router-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-C(config)#interface ethernet 0/0
Router-C(config-if)#standby 10 priority 100
Router-C(config-if)#standby 20 priority 95
Router-C(config-if)#standby 30 priority 105
Router-C(config-if)#standby 10 track serial 2/0 15
Router-C(config-if)#standby 20 track serial 2/0 15
Router-C(config-if)#standby 30 track serial 2/0 15
Router-C(config-if)#^Z
Router-C#

下図のように、構成が変わりました。
これで、三台のルータが無駄なく利用されるようになります。

各ルータで、show standby brief を確認します。



Router-A#show standby brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Et0/0 10 105 P Active local 192.168.1.103 192.168.1.1
Et0/0 20 100 P Standby 192.168.1.102 local 192.168.1.2
Et0/0 30 95 P Listen 192.168.1.103 192.168.1.102 192.168.1.3
Router-A#



Router-B#show standby brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Et0/0 10 95 P Listen 192.168.1.101 192.168.1.103 192.168.1.1
Et0/0 20 105 P Active local 192.168.1.101 192.168.1.2
Et0/0 30 100 P Standby 192.168.1.103 local 192.168.1.3
Router-B#



Router-C#show standby brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Et0/0 10 100 P Standby 192.168.1.101 local 192.168.1.1
Et0/0 20 95 P Listen 192.168.1.102 192.168.1.101 192.168.1.2
Et0/0 30 105 P Active local 192.168.1.102 192.168.1.3
Router-C#



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証

Standby Group に参加するルータに、共通の合言葉を設定します。

※ 先のページで設定したHello Time とHold Time は、デフォルトに戻しておいてください。

デフォルトの合言葉は、"cisco" に設定されています(running-config には表示されません)。

三台のルータすべてに、standby 10 authentication smartnetworks を設定します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#standby 10 authentication smartnetworks
Router-A(config-if)#^Z
Router-A#

設定変更中は、次のようなメッセージが表示されます。



Router-C(config-if)#
Feb 7 02:12:31.013: %STANDBY-3-BADAUTH: Bad authentication from 192.168.1.101, group 10, remote state Active
Feb 7 02:12:38.021: %STANDBY-6-STATECHANGE: Ethernet0/0 Group 10 state Standby -> Active

それまで同じ合言葉だったルータが、突然別な合言葉を使い始めたので、警告されます。
合言葉が違うルータ同士は、Standby Group 番号が同じであっても、別なグループになってしまいます。
同じStandby Group の中に、同じVirtual IP アドレスを持った、複数のActive Router が出現します。

全てのルータで設定が終わると、下図のようになります。


ここに、Authentication がデフォルトのままのRouter-X を接続すると、以下のメッセージが各ルータに表示されます。



Router-A#
Feb 7 02:18:09.846: %IP-4-DUPADDR: Duplicate address 192.168.1.1 on Ethernet0/0, sourced by 0000.0c07.ac00
Router-A#

新たに接続されたルータなので、Bad Auth とはならず、最初から別物扱いされます。
別なGroup 扱いなのは同じで、同じVirtual IP アドレスを持った、複数のActive Router が出現します。
Virtual IP アドレスが重複していることを警告するメッセージです。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編 (7) Timer を変更する

これまで、Hello Time やHold Time はデフォルト値のままでした。
デフォルト値はそれぞれ、3秒と10秒なので、Active Router が切り替わるまでに最低10秒、通信断が発生します。

通信断をもっと短くするため、Hello Time とHold Time を小さくしてみます。

※ 前のページでshutdown したRouter-A のSerial 2/0 を元に戻しておいてください。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#standby 10 timers 1 5
Router-A(config-if)#^Z
Router-A#

Hello Time を1秒に、Hold Time を5秒に設定しました。

show standby で確認します。



Router-A#show standby
Ethernet0/0 - Group 10
State is Active
12 state changes, last state change 00:02:10
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 1 sec, hold time 5 sec
Next hello sent in 0.204 secs
Preemption enabled
Active router is local
Standby router is 192.168.1.103, priority 100 (expires in 4.948 sec)
Priority 105 (configured 105)
Track interface Serial2/0 state Up decrement 10
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

Router-B とC のHold Time とHello Time も、自動的に、1秒と5秒に変わっています。
Router-A からのHello メッセージを受信して、学習したからです。



Router-B#show stand
Ethernet0/0 - Group 10
State is Listen
21 state changes, last state change 00:00:58
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 1 sec, hold time 5 sec
Preemption enabled
Active router is 192.168.1.101, priority 105 (expires in 4.092 sec)
Standby router is 192.168.1.103, priority 100 (expires in 4.312 sec)
Priority 100 (default 100)
Track interface Serial2/0 state Up decrement 10
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-B#



Router-C#show stand
Ethernet0/0 - Group 10
Local state is Standby, priority 100, may preempt
Hellotime 1 sec, holdtime 5 sec
Next hello sent in 0.456
Virtual IP address is 192.168.1.1 configured
Active router is 192.168.1.101, priority 105 expires in 4.380
Standby router is local
33 state changes, last state change 00:00:51
Priority tracking 1 interface, 1 up:
Interface Decrement State
Serial2/0 10 Up
Router-C#

今、ネットワークは下図のようになっています。

Router-A のEthernet0/0 をshutdown します。



outer-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#shutdown
Router-A(config-if)#
Feb 7 00:40:53.391: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> Init
Router-A(config-if)#
Feb 7 00:40:53.403: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.102 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Feb 7 00:40:53.403: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.103 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
Feb 7 00:40:55.403: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down
Feb 7 00:40:56.411: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down
Router-A(config-if)#

Router-C のコンソールです。



Router-C#
Feb 7 00:40:57.820: %STANDBY-6-STATECHANGE: Ethernet0/0 Group 10 state Standby -> Active
Feb 7 00:41:30.960: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.101 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
Router-C#

Router-A がInit になった00:40:53 から、約5秒後の00:40:57 には、Router-C がActive になっています。

Ping の不通も、Hello Time/Hold Time を変更するまえより短時間で済んでいるのが分かります。



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

これまでは、Active Router からHello メッセージが届かなくなって10秒待ってから、Router-C はActive になっていました。
Hold Time を短くすることで、Active Router(Router-A) の異変を察知するのに要する時間を短縮できました。


Hello Time を1秒、Hold Time を5秒にするということは、Hello メッセージを5回紛失したらActive Router の切り替わりが発生することを意味します。
Hello メッセージを毎秒送信するのは、帯域の浪費であり、現実的ではありません。

デフォルト値の場合、Hello メッセージの紛失は3回まで許されることになります。
(Hello Time = 3 、Hold Time = 10)
デフォルト値のように、Hold Time は、Hello Time の約3倍に設定するのが一般的です。


一度Hello Time やHold Time を小さくして、それが他のルータに学習されると、学習したルータでは、設定をデフォルトに戻しても反映されません(running-config には入りますが、学習した値のまま動作します)。

値が元に戻らないのは、より小さい値を他から学習した場合です。
小さい値に設定変更したルータ自身は、設定を削除することでデフォルト値に戻ります。
※ 他から学習したルータも、より値を小さくする設定変更は有効になります。

学習した小さい値は戻せなくても、自分で変更した値は戻せます。
より小さく変更はできるので、一旦値をより小さくした上で、設定を削除すればデフォルトに戻せます。

この制限は、より小さい値を他のルータから学習した場合です。
学習したのがデフォルトより大きい場合は、より大きくも、より小さくも変更できます。
IOS version が12.4 の場合、学習した値の変更は、デフォルト値以外なら大小どちらでも可能です。
(standby 10 timers 3 10 は無効だが、standby 10 timers 5 15 は有効になる)

これら一連の、学習した値を変更する際の制限は、意図して実装したものではなく、実装の甘さが露呈したもののように見えます。
実際のところはどうなんでしょうか?

ご存知の方はこちらまでお知らせください。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編 (6) Interface Tracking

Serial2/0 をshutdown しても通信は継続できましたが、余計なルータ(Router-A) が介在し続けるのは、効率がよくありません。

vSerial2/0 のリンクダウンをトリガーに、Active Router を他のルータに切り替えることができれば、そのような状況を回避できます。

Router-A に、Interface Tracking を設定することで実現できます。

※ 一旦、Serial 2/0 をno shutdown しておきます。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/0
Router-A(config-if)#standby 10 track serial 2/0 10
Router-A(config-if)#^Z
Router-A#

Serial 2/0 で不具合を検知すると、Router-A は、Standby Group 10 のプライオリティを10下げます(105 - 10 = 95)。

show standby で確認します。



Router-A#show standby
Ethernet0/0 - Group 10
State is Active
1 state change, last state change 01:03:55
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.796 secs
Preemption enabled
Active router is local
Standby router is 192.168.1.103, priority 100 (expires in 7.268 sec)
Priority 105 (configured 105)
Track interface Serial2/0 state Up decrement 10
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

改めて、Router-A のSerial2/0 をshutdown します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface serial2/0
Router-A(config-if)#shut
Router-A(config-if)#
Feb 7 00:02:12.957: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.104 on Serial2/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
Feb 7 00:02:14.969: %LINK-5-CHANGED: Interface Serial2/0, changed state to administratively down
Feb 7 00:02:15.969: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, changed state to down
Feb 7 00:02:15.969: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> Speak
Router-A(config-if)#

Serial2/0 をshutdown すると、Router-A はプライオリティを10下げた95のHello メッセージを送信し始めます。

それを受けて、Router-C がCoup メッセージを送信して、Active Router に切り替わります。
よりプライオリティの高いRouter-C からのCoup メッセージを受け取ると、Router-A はActive Router を辞め、Standby Router の選出プロセスに入るため、Speak State に移行します。

Router-C のコンソールメッセージです。



Router-C#
Feb 7 00:02:15.951: %STANDBY-6-STATECHANGE: Ethernet0/0 Group 10 state Standby -> Active
Router-C#

Router-B のコンソールメッセージです。



Router-B#
Feb 7 00:02:25.945: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> Standby
Router-B#

Router-A とRouter-B の間で行われるStandby Router 選出プロセスで、プライオリティの高いRouter-B (100) が選ばれます。


PC1 からPC4 のPing には、ほとんど影響が見られません。



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.U.U!!!!!!!!!!!!!!!!U!!!!!!!!!!
!!!!!U!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

ここで、残りのルータ(B、C)にもInterface Tracking を設定しておきましょう。



Router-B#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-B(config)#interface ethernet 0/0
Router-B(config-if)#standby 10 track serial 2/0 10
Router-B(config-if)#^Z
Router-B#



Router-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-C(config)#interface ethernet0/0
Router-C(config-if)#standby 10 track serial 2/0 10
Router-C(config-if)#^Z
Router-C#


今、各ルータの設定は以下のようになっています。
Interface Tracking で、プライオリティの下げ幅を10に設定したのに、running-config にはstandby 10 track Serial2/0 としかありません。
これは、下げ幅のデフォルトが10なので、省略されているのです。



Router-A#show running-config interface ethernet0/0
Building configuration...

Current configuration : 186 bytes
!
interface Ethernet0/0
ip address 192.168.1.101 255.255.255.0
no ip redirects
standby 10 ip 192.168.1.1
standby 10 priority 105
standby 10 preempt
standby 10 track Serial2/0
end

Router-A#



Router-B#show running-config interface ethernet0/0
Building configuration...

Current configuration : 161 bytes
!
interface Ethernet0/0
ip address 192.168.1.102 255.255.255.0
no ip redirects
standby 10 ip 192.168.1.1
standby 10 preempt
standby 10 track Serial2/0
end

Router-B#



Router-C#show running-config interface ethernet0/0
Building configuration...

Current configuration : 190 bytes
!
interface Ethernet0/0
ip address 192.168.1.103 255.255.255.0
no ip redirects
no ip directed-broadcast
standby 10 ip 192.168.1.1
standby 10 preempt
standby 10 track Serial2/0 10
end

Router-C#



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)

Active Router になっているRouter-A で、別な障害を発生させてみます。

インターフェイスSerial2/0 をshutdown します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface serial2/0
Router-A(config-if)#shutdown
Router-A(config-if)#^Z
Router-A#
Feb 6 22:39:33.594: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.104 on Serial2/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Feb 6 22:39:34.206: %SYS-5-CONFIG_I: Configured from console by console
Feb 6 22:39:35.586: %LINK-5-CHANGED: Interface Serial2/0, changed state to administratively down
Feb 6 22:39:36.594: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, changed state to down

Serial2/0 がダウンした以外、何も変化が見られません。



Router-A#show standby
Ethernet0/0 - Group 10
State is Active
1 state change, last state change 00:26:54
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.488 secs
Preemption enabled
Active router is local
Standby router is 192.168.1.103, priority 100 (expires in 7.488 sec)
Priority 105 (configured 105)
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

Active Router のままです。



!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.U.U.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

PC1 からPC4 へのPing も、一時的に不通となっただけです。


Router-A のルーティングテーブルを見てみます。



Router-A#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 4 subnets
C 1.1.1.101 is directly connected, Loopback0
O 1.1.1.103 [110/11] via 192.168.1.103, 00:02:57, Ethernet0/0
O 1.1.1.102 [110/11] via 192.168.1.102, 00:02:57, Ethernet0/0
O 1.1.1.104 [110/75] via 192.168.1.103, 00:02:57, Ethernet0/0
[110/75] via 192.168.1.102, 00:02:57, Ethernet0/0
O 192.168.4.0/24 [110/74] via 192.168.1.103, 00:02:57, Ethernet0/0
O 192.168.5.0/24 [110/84] via 192.168.1.103, 00:02:57, Ethernet0/0
[110/84] via 192.168.1.102, 00:02:57, Ethernet0/0

C 192.168.1.0/24 is directly connected, Ethernet0/0
O 192.168.3.0/24 [110/74] via 192.168.1.102, 00:02:57, Ethernet0/0
Router-A#

192.168.5.0/24 宛のNext Hop が、Router-B とC のEthernet0/0 に変わっています。

Ping が一時的に不通となったのは、Router-A のルーティングテーブルから、192.168.5.0/24 宛のNext Hop が存在しなくなったからです。
Next Hop がRouter-B、C のEthernet0/0 へ変わることにより、通信は復旧します。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する

Active Router が無事切り替わることが確認できたので、shutdown したRouter-A のEthernet0/0 を元に戻しましょう。



Router-A(config-if)#no shutdown
Router-A(config-if)#
Feb 6 21:22:28.059: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
Feb 6 21:22:29.059: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
Router-A(config-if)#
Feb 6 21:22:36.099: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.102 on Ethernet0/0 from LOADING to FULL, Loading Done
Feb 6 21:22:36.139: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.103 on Ethernet0/0 from LOADING to FULL, Loading Done
Router-A(config-if)#
Router-A#
Feb 6 21:23:38.011: %SYS-5-CONFIG_I: Configured from console by console
Router-A#show standby
Ethernet0/0 - Group 10
State is Listen
3 state changes, last state change 00:27:02
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Preemption disabled
Active router is 192.168.1.103, priority 100 (expires in 7.212 sec)
Standby router is 192.168.1.102, priority 100 (expires in 9.572 sec)

Priority 100 (default 100)
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

Router-A のIP アドレスは192.168.1.101 です。
三台のルータ中一番小さいので、復帰しても、Standby Router にはならず、Listen State となります。


自分から辞めない限りActive Router はそのままです。
仮に、Router-A が三台中もっとも処理能力が高いルータであるとすると、復帰したRouter-A がActive Router に戻ることが期待されます。

そこで、preempt を設定します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface e0/0
Router-A(config-if)#standby 10 preempt
Router-A(config-if)#^Z
Router-A#

何も変化はおきません。
show standby を確認します。



Router-A#show standby
Ethernet0/0 - Group 10
State is Listen
3 state changes, last state change 00:34:50
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Preemption enabled
Active router is 192.168.1.103, priority 100 (expires in 7.156 sec)
Standby router is 192.168.1.102, priority 100 (expires in 8.268 sec)

Priority 100 (default 100)
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

Router-C(192.168.1.103) がActive Router のままです。

これは、プライオリティが設定されていないからです。
三台ともデフォルト値のプライオリティ(100) を使用しているので、もっともIP アドレスが大きいRouter-C(192.168.1.103) がActive Router のままとなります。

Router-A でプライオリティを105に設定します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface e0/0
Router-A(config-if)#standby 10 priority 105
Router-A(config-if)#^Z
Router-A#
Feb 6 21:45:46.735: %SYS-5-CONFIG_I: Configured from console by console
Router-A#
Feb 6 21:45:50.151: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> Active
Router-A#

Router-A(Priority 105) がActive Router に変わりました。

Active Router を辞めたRouter-C は、Standby Router の選出プロセスに入るため、一旦Speak State に移行し、その後、Standby Router になります(Router-B よりもIP アドレスが大きいため)。

Router-C#
Feb 6 21:45:50.153: %STANDBY-6-STATECHANGE: Ethernet0/0 Group 10 state Active -> Speak
Router-C#
Router-C#show standby
Ethernet0/0 - Group 10
Local state is Standby, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.504
Virtual IP address is 192.168.1.1 configured
Active router is 192.168.1.101, priority 105 expires in 8.440
Standby router is local

4 state changes, last state change 00:01:42
Router-C#

Router-B はStandby Router を辞め、Listen State へ移行します。



Router-B#
Feb 6 21:45:47.261: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Standby -> Listen
Router-B#

ここで、残りのルータ(B、C)にもPreempt を設定しておきましょう。



Router-B#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-B(config)#interface ethernet0/0
Router-B(config-if)#standby 10 preempt
Router-B(config-if)#^Z
Router-B#



Router-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-C(config)#interface ethernet0/0
Router-C(config-if)#standby 10 preempt
Router-C(config-if)#^Z
Router-C#



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)

では、Router-A に障害を発生させて、動作を確認してみましょう。

Router-A のEthernet0/0 をshutdown してみます。

PC-1 からPC-4 へPing を打ちっぱなしにします。

※ この検証では、PC はCisco ルータで代用しています。
PC 役のルータでは、IP ルーティングを無効にして、デフォルトゲートウェイを設定しています。



PC-1#ping
Protocol [ip]:
Target IP address: 192.168.5.105
Repeat count [5]: 0
% A decimal number between 1 and 2147483647.
Repeat count [5]: 2147483647
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 2147483647, 100-byte ICMP Echos to 192.168.5.105, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Router-A のEthernet0/0 をshutdown します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/0
Router-A(config-if)#shutdown
Router-A(config-if)#
Feb 6 20:56:39.679: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Active -> Init
Router-A(config-if)#
Feb 6 20:56:39.691: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.102 on Ethernet0/0 from 2WAY to DOWN, Neighbor Down: Interface down or detached
Feb 6 20:56:39.691: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.103 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Router-A(config-if)#
Feb 6 20:56:41.687: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down
Feb 6 20:56:42.699: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down

Standby Group 10 のHSRP State がActive からInit に遷移した後、Ethernet0/0 がダウンしました。

Router-C のコンソールにメッセージが表示されます。



Router-C#
Feb 6 20:56:47.280: %STANDBY-6-STATECHANGE: Ethernet0/0 Group 10 state Standby -> Active
Feb 6 20:57:15.732: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.101 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
Router-C#

それまでStandby Router だったRouter-C は、Router-A からのHello メッセージが10秒間受信できなかったので、Active Router に移行します。

※ Router-A のState がInit になった20:56:39 から、Router-C がActive となった20:56:47 の時間差が10秒ではないのは、Router-A が最後にHello メッセージを送信したのがInit になる2秒前だからです。

Router-C でshow standby を確認します。



Router-C#show standby
Ethernet0/0 - Group 10
Local state is Active, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 1.502
Virtual IP address is 192.168.1.1 configured
Active router is local
Standby router is 192.168.1.102 expires in 7.012
Virtual mac address is 0000.0c07.ac0a
2 state changes, last state change 00:23:39
Router-C#

Router-C がActive Router、Router-B(192.168.1.102) がStandby Router になっているのが確認できます。

Router-B のコンソールにもメッセージが表示されます。



Router-B#
Feb 6 20:56:57.252: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> Standby
Router-B#
Feb 6 20:57:15.732: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.101 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
Router-B#

Router-C がActive Router になり、Standby Router からのHello メッセージが届かなくなって10秒経過後、Router-B はStandby Router になりました。


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!.....................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Router-A のEthernet0/0 がshutdown されてから、Ping は不通となりましたが、Router-C がActive Router になることで、復旧しました。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(2) Standby Group をつくる

サブネット192.168.1.0/24 にバーチャルルータをつくります。

Router-A、B、C にStandby Group 10を作成します。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet0/0
Router-A(config-if)#standby 10 ip 192.168.1.1
Router-A(config-if)#^Z
Router-A#
Feb 6 20:48:00.585: %SYS-5-CONFIG_I: Configured from console by console
Router-A#
Feb 6 20:48:30.848: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> Standby
Feb 6 20:48:30.848: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Standby -> Active

まずRouter-A のEthernet0/0 にstandby 10 ip 192.168.1.1 を設定します。
しばらくすると、Standby Group 10のActive Router になったことを意味するメッセージが表示されます。

ここでshow standby を実行すると、Standby Group 10の状況を確認できます。



Router-A#show standby
Ethernet0/0 - Group 10
State is Active
2 state changes, last state change 00:04:41
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.132 secs
Preemption disabled
Active router is local
Standby router is unknown
Priority 100 (default 100)
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

HSRP State はActive になっています。
Virtual IP アドレスは、192.168.1.1 です。
Virtual MAC アドレスは、Standby Group 10 を意味する00-00-0c-07-ac-0a です。
Hello Time とHold Time は、それぞれ3秒と10秒です(デフォルト値)。
プライオリティはデフォルト値の100 になっています。

引き続きRouter-B に同じ設定をします。



Router-B#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-B(config)#interface ethernet0/0
Router-B(config-if)#standby 10 ip 192.168.1.1
Router-B(config-if)#^Z
Router-B#
Feb 6 20:51:18.300: %SYS-5-CONFIG_I: Configured from console by console
Router-B#
Feb 6 20:51:48.400: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Speak -> Standby

Standby Group 10 のStandby Router になったことを意味するメッセージが表示されます。

show standby を見てみます。



Router-B#show standby
Ethernet0/0 - Group 10
State is Standby
1 state change, last state change 00:02:37
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.920 secs
Preemption disabled
Active router is 192.168.1.101, priority 100 (expires in 8.044 sec)
Standby router is local
Priority 100 (default 100)
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-B#

HSRP State はStandby になっています。
Active Router は、先ほど設定したRouter-A(192.168.1.101) になっています。
Standby Router は、自分自身を意味するLocal になっています。

ここでもう一度Router-A でshow standby を見てみます。



Router-A#show standby
Ethernet0/0 - Group 10
State is Active
2 state changes, last state change 00:16:44
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.992 secs
Preemption disabled
Active router is local
Standby router is 192.168.1.102, priority 100 (expires in 9.756 sec)
Priority 100 (default 100)
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-A#

先ほどはUnknown となっていたStandby Router が、Router-B(192.168.1.102) に変わりました。Router-B からのHello メッセージを受け取ったからです。

IP アドレスが大きいRouter-B(192.168.1.102) が出現しても、Router-A(192.168.1.101) はActive Router であり続けます。
Active Router は、自分から辞めない限り、Active Router のままです。

続けてRouter-C を設定します。



Router-C#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-C(config)#interface ethernet0/0
Router-C(config-if)#standby 10 ip 192.168.1.1
Router-C(config-if)#^Z
Router-C#

Router-C にStandby Group 10を設定すると、Router-B のコンソールにメッセージが表示されました。



Router-B#
Feb 6 20:53:18.684: %HSRP-6-STATECHANGE: Ethernet0/0 Grp 10 state Standby -> Listen
Router-B#

Router-B がStandby Router では無くなったようです。
Router-C でshow standby を見てみます。



Router-C#show standby
Ethernet0/0 - Group 10
Local state is Standby, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 1.292
Virtual IP address is 192.168.1.1 configured
Active router is 192.168.1.101, priority 100 expires in 7.060
Standby router is local
1 state changes, last state change 00:08:31
Router-C#

Router-C がStandby Group 10のStandby Router となったことが確認できます。

※ Router-B はIOS version 12.0 で動作しているので、show コマンドの表示が異なります。

今度はRouter-B のshow standby です。



Router-B#show standby
Ethernet0/0 - Group 10
State is Listen
6 state changes, last state change 00:10:35
Virtual IP address is 192.168.1.1
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Preemption disabled
Active router is 192.168.1.101, priority 100 (expires in 7.528 sec)
Standby router is 192.168.1.103, priority 100 (expires in 8.988 sec)

Priority 100 (default 100)
IP redundancy name is "hsrp-Et0/0-10" (default)
Router-B#

HSRP State がListen になっています。
Active Router はRouter-A(192.168.1.101)、Standby Router はRouter-C(192.168.1.103) になっているのが確認できます。

Router-B ではなくRouter-C がStandby Router になったのは、Router-C のIP Address(192.168.1.103) の方が、Router-B(192.168.1.102) よりも大きいからです。


ひとまず設定が完了したので、PC-1、2、3 のデフォルトゲートウェイを192.168.1.1 に変更します。

PC1、2、3 からPC4 宛のパケットは、Standby Group 10 のバーチャルルータ(192.168.1.1) 宛に送られます。
今は、Router-A がStandby Group 10のActive Router になっているので、パケットはすべて、Router-A によりルーティングされます。


Router-A とB はIOS version 12.4 で動作しているので、HSRP を設定してもICMP Redirect は有効になっています。
しかし、Standby Group 内に12.0 で動作しているRouter-C が存在するので、Router-A とB でもICMP Redirect を無効にします。



Router-A#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)#interface ethernet 0/0
Router-A(config-if)#no ip redirects
Router-A(config-if)#^Z
Router-A#

IOS version 12.0 で動作しているルータでは、ICMP Redirect との協調機能が実装されていません。
そのため、Listen State になっている間はAdvertisement メッセージを送信せず、Router-A やB からはPassive Router であることが分かりません。
そのため、Passive Router であるにもかかわらず、Router-A やB から、Redirect の対象とされてしまいます。

ICMP Redirect を有効にするのは、Standby Group 内のルータがすべて、強調機能をサポートしているときだけにしましょう。

※ Router-C(IOS version 12.0) では、HSRP を設定すると、自動的にICMP Redirect が無効になります。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する

ここからは、実際にHSRP をルータに設定してきます。

まずは、HSRP を設定する前のネットワークの状況を確認しましょう。

Router-A からRouter-D の、4台のCisco ルータがあります。

※ Router-A、B、D はIOS version 12.4、Router-C は12.0 で動作しています。
バージョンによって設定可能な項目と、show コマンドの出力が異なるのを確認するためです。

Router-A、B、C は、192.168.1.0/24 というサブネットに、インターフェイスEthernet0/0 を介して接続しています。
Router-D は、他の三台のルータと、シリアル回線で接続されており、それぞれ別なサブネットです。シリアル回線の速度は、すべて64kbps です。

各ルータではルーティングプロトコルにOSPF が採用されており、すべてArea 0に参加しています。
特に明記しない限り、どのルータも、必要な経路をすべて持っているものとします。

PC1 からPC3 の3台の端末は、192.168.1.0/24 に所属しており、それぞれ、Router-A、B、C をデフォルトゲートウェイとしています。
特に問題が無い場合、PC1、2、3からPC4 へのパケットは、それぞれのデフォルトゲートウェイによってルーティングされます。

Router-A に不具合が発生すると、PC1 のパケットはPC4 へ到達する手段を失ってしまいます。

デフォルトゲートウェイは、PC 上に静的に設定されているので、このような状況に自律的に対応することができません。

ここから、HSRP の設定を開始します。



HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

Debug コマンドについて

Cisco ルータのDebug コマンドは、トラブルシューティングや動作の確認に有効です。

ルータが送受信したパケットの内容を見たり、さまざまな機能が、ルータ内部でどのような処理をしているのかを確認することができます。

本サイトでも、Debug コマンドを使ったトラブルシューティング事例や、機能の紹介を行うことがあります。


便利なDebug コマンドですが、危険な面もあります。

大量のメッセージ出力でコンソールが埋め尽くされたり、CPU 使用率の高騰を招いて、キー入力を受け付けなくなることもあります。
他の機能にまで影響を及ぼし、最悪の場合、ルータを再起動するしか回復の手段がなくなることもあります。

Debug コマンドを試される場合は、危険性をよく理解したうえで行ってください。
Live Network(実際に運用されているネットワーク)から切り離された、検証環境でのみDebug コマンドを使用されることをお勧めします。

HSRP を究める(15) ICMP Redirect との協調動作

IOS version 12.1(3)T から、HSRP とICMP Redirect を協調動作させるための仕組みが加わりました。

上図では、二台のルータのインターフェイスEthernet0/0 で、それぞれ二つのStandby Group が設定されています(Group 10 と20)。
Router-A は、Standby Group 10 のStandby Router、Group20 のActive Router になっています。
Router-B は、Standby Group 10 のActive Router、Group20 のStandby Router になっています。

先ほどと同様に、Router-B のEthernet1/0 でコストが増加されています。

左側のPC からの150.1.1.1 宛のパケットに対して、ICMP Redirect を返すのは先ほどと同様ですが、Redirect 先が、Router-A のReal IP アドレスではなく、Standby Group 20のVirtual IP アドレスになっています。

以後、左側のPC は、150.1.1.1 宛のパケットを、Standby Group 20 のActive Router に送ります。
なんらかの理由でRouter-A が使用不可となっても、Router-B がStandby Group 20のActive Router に切り替わることで、通信を継続できます。


この機能は、ルータに複数のStandby Group が設定されているときのみ、有効に働きます。

HSRP が設定されているルータは、自分に設定されているGroup だけでなく、サブネット上を流れるHello メッセージをすべて監視しています。
ICMP Redirect を送信する前に、Redirect 先がStandby Group に参加しているかどうか確認し、いずれかのGroup のActive Router となっていれば、Redirect 先をReal IP アドレスではなくVirtual IP に書き換えます。


Redirect 先のルータに、Active Router となっているGroup が無い場合(参加しているGroup がすべてStandby かListen)、Redirect は行われません。
Standby Group に参加していてActive Router になっていないルータを、Passive Router と呼びます。
Passive Router のReal IP アドレスへのRedirect は、冗長化されたルータを有効に活用できていないことになるので、禁止されています。




















上図では、Redirect 先のRouter-D がListen State なので、ICMP Redirect は送信せず、中継を続けています。

show standby redirect コマンドで、Redirect 先がPassive Router かどうかを確認できます。



Router#show standby redirect
Interface Redirects Unknown Adv Holddown
Ethernet0/0 enabled enabled 30 180

Active Hits Interface Group Virtual IP Virtual MAC
local 0 Ethernet0/0 10 192.168.1.1 0000.0c07.ac0a
local 0 Ethernet0/0 20 192.168.1.2 0000.0c07.ac14

Passive Hits Interface Expires in
192.168.1.102 0 Ethernet0/0 159.512

Router#


Redirect 先のルータにHSRP の設定が一切されていない場合、通常のICMP Redirect と同様に、Real IP をゲートウェイとするICMP Redirect を返信します。

no standby redirect unknown を設定すると、Redirect 先のルータにHSRP が設定されていない場合は、ICMP Redirect を送信せず、パケットの中継を続けさせることができます。





















State がListen となっているルータはHello メッセージを送信しないので、Active かStandby にならないかぎり、存在をほかのルータに知られることはありません。
他のルータに知られないままだと、Passive Router であるにもかかわらず、Redirect 先に指定されてしまいます。

Passive Router が、存在を他のルータへ通知するための手段として、IOS version 12.1(3)T から、Advertisement メッセージが導入されました。

Passive Router は、30秒に一回、自分が参加しているStandby Group の数と、State を含んだメッセージを送信します。
Advertisement メッセージを送信する間隔は、10〜180秒の間で変更できます。

Advertisement メッセージを180秒間受信しないと、そのルータは、HSRP が設定されていないルータになったと判断され、以後はRedirect の対象となります(Passive Router Hold Down Interval)。
Hold Down Interval は、30〜3600秒の間で変更できます。



Router(config-if)
Router(config-if)#standby redirect timers 30 180
Router(config-if)#






















HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める(14) ICMP Redirect

HSRP を使っているインターフェイスで、ICMP Redirect を有効にすると、Virtual Router による冗長構成が活かされない状況が発生することがあります。

上図では、Router-B がActive Router になっており、インターフェイスEthernet0/0 でICMP Redirect が有効になっています。
Ethernet1/0 では、ルーティングプロトコルのコストを増加させています。
そのため、Router-B のルーティングテーブル上で、150.0.0.0 へ到達するためのNext Hop は192.168.1.100(Router-B のEthernet0/0) となっています。

左側のPC が、150.1.1.1 宛のパケットを、Active Router (Router-B) へ送ると、Router-B は、192.168.1.100(Router-A) へ中継します。
このように、Router-B がActive Router であっても、150.0.0.0 宛のパケットはすべて、Router-A を介して転送されます。

ここで、Router-B のEthernet0/0 で、ICMP Redirect を有効にします。

150.1.1.1 宛のパケットを受け取ると、Router-B は、192.168.1.100(Router-A) をゲートウェイとするICMP Redirect を、送信元に送ります。

ICMP Redirect を受け取ると、PC はルーティングテーブルに、150.1.1.1 宛のゲートウェイを192.168.1.100とするエントリを作成します。
以後の150.1.1.1 宛のパケットはすべて、Router-A に直接送られます。

ここまではすべて上手くいっているように見えますが、この後Router-A がなんらかの理由で使用不可となると、PC が150.1.1.1 宛にパケットを送る手段はなくなります。

HSRP を使ってゲートウェイを冗長化しているにもかかわらず、一台のルータが使用不可となったために、通信ができない状況が発生するわけです。

そのような状況を回避するため、Cisco のIOS では、HSRP の設定をしたインターフェイスではICMP Redirect が自動的に無効となります。

もちろん、意図的にICMP Redirect を有効にすることはできますが、警告メッセージが表示されます。



Router(config-if)#ip redirects
% Warning: the combination of ICMP redirects and HSRP on the same
% interface may result in lost packets.
Router(config-if)#

警告は出ますが、設定は有効になります。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める(13) Authentication

HSRP では、共通の文字列をルータに設定することで、Standby Group に参加するルータの簡易認証を行うことができます。

Authentication を明示的に設定しないと、デフォルトの文字列"cisco"が使われます。

Authentication は、standby authentication コマンドで設定できます。

Authentication 文字列が異なるHello メッセージを受信すると、ルータは、警告メッセージを表示します。
警告はされますが、防ぐ手段は無く、Standby Group に複数のActive Router が存在することになってしまいます。
同じIP アドレスを持つ複数のルータが存在することになります。

※ そのような状態で、Virtual IP宛にPing を実行すると、両方のルータからReply が返ってきます。
端末とルータの間にLayer2 スイッチなどのラーニングブリッジが存在すると、Virtual MAC アドレスが二つのポートの間を、短時間に往復しているように見えます。
スイッチの実装によっては、ループが存在すると判断して、ポートを無効化することもあります。





HSRP における認証は、許可されないルータが存在することを防ぐというよりは、管理者の知らないルータが接続されたことを検出するための手段、と言うことができます。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める(12) BIA (Burnt In Address)

HSRP のStandby Group は、ひとつのインターフェイス上に複数作成することもできます。

複数のStandby Group で同時にActive Router となると、そのインターフェイスは、複数のVirtual MAC アドレス宛パケットを、同時に処理しなければいけません。

ルータに限らず、ネットワークに接続された機器のEthernet インターフェイスは、自分が受信しなければならないMAC アドレスの一覧を、MAC Address Filter に設定します。

比較的旧式なCisco ルータのEthernet インターフェイスには、MAC Address Filter にひとつしか登録できないものがあります。

※ Cisco800、1000、1600、2500、3000、4000、4500 などの、Ethernet コントローラにLance またはPQUICC を使用している機器が該当します。

Ethernet コントローラは、show interface で確認できます。



Router#show interfaces e0/0
Ethernet0/0 is administratively down, line protocol is down
Hardware is Lance, address is 0000.0cxx.xxxx (bia 0000.0cxx.xxxx)
Internet address is 192.168.1.101/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:11:48, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 16913 drops; input queue 0/75, 1920 drops, 0 flushes
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
37690 packets input, 2339316 bytes, 0 no buffer
Received 37663 broadcasts, 0 runts, 0 giants, 1920 throttles
3825 input errors, 0 CRC, 0 frame, 0 overrun, 3825 ignored
0 input packets with dribble condition detected
30532 packets output, 1876942 bytes, 0 underruns
0 output errors, 0 collisions, 3852 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Router#



そのようなルータで複数のStandby Group を設定しようとすると、不可能であることを意味するメッセージが表示されます。



Router#standby 20 ip 192.168.1.2
% Interface hardware cannot support multiple groups.
Router#


そのようなインターフェイスに複数のStandby Group を作成するための回避策として、BIA (Burnt In Address) を使う方法があります。

BIA は、インターフェイスが本来持っているMAC アドレスです。Virtual MAC アドレスの代わりに、このアドレスをVirtual IP アドレスに関連付けます。






Virtual MAC アドレスを用いる場合は、Standby Group 毎に異なるMAC アドレスが生成されましたが、BIA を使うと、すべてのGroup で同じMAC アドレスが使われます。

BIA は、standby use-bia コマンドで設定します。
インターフェイスを一度shutdown し、改めてno shutdown すると、有効になります。



Router#show standby
Ethernet0/0 - Group 10
Local state is Active, priority 100, may preempt, use bia
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.226
Virtual IP address is 192.168.1.1 configured
Active router is local
Standby router is unknown
Virtual mac address is 0000.0cxx.xxxx <<----------------------
12 state changes, last state change 00:04:30
Router#


BIA を使うと、Standby Group のMAC アドレスに、ルータ固有のMAC アドレスを使うことができます。
しかし、端末の視点から見ると、Active Router が切り替わるたびにデフォルトゲートウェイのMAC アドレスが変わる事になり、「透過的」という利点が失われてしまいます。

ゲートウェイのMAC アドレスが変わったことを端末に知らせる手段がないと、端末は古いMAC アドレスを宛先としたままパケットを送信し続けるので、新しいActive Router に破棄されてしまいます。

そのような状況を回避するため、Gratuitous ARP が使われます。
新しくActive Router となったルータは、Gratuitous ARP をブロードキャストし、デフォルトゲートウェイのMAC アドレスが変わったことを、端末に通知します。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める(11) Interface Tracking

HSRP は、サブネット内で動作するプロトコルなので、同じルータであっても、他のサブネットの状況は関知しません。
















上図では、Router-A のインターフェイスEthernet1/0 のリンクが、ダウンしています。
しかし、Ethernet0/0 でのHSRP Hello メッセージには支障がないので、Router-A はActive Router であり続けます。
端末からのパケットはRouter-A に送られ続けます。

ルーティングプロトコルにより、Router-A のルーティングテーブル上のNextHop がRouter-B のEthernet0/0 に変わると、Router-A はパケットを中継するようになりますが、PC 間の通信に一台余計なルータ(Router-A) が介することになるので、効率がよくありません。


Interface Tracking 機能を使うと、そのような状況を回避できます。




















上図では、Router-A に、standby 10 track Ethernet1/0 10 が設定してります。
このコマンドは、「Ethernet1/0 がダウンしたら、Standby Group 10のプライオリティを10下げる」という意味です。

プライオリティが10下がって90になったHello メッセージを、プライオリティが95のRouter-B が受け取ると、Coup メッセージを送信して、自分がActive Router になります。

※ Interface Tracking を利用するには、Router-B で、Preempt が設定されていなければいけません。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める(10) Preempt

Active Router がいなくなったり、プライオリティが下がると、それまでStandby Routerだったルータが、Active Router に変わります。

しかし、逆に、従来のActive Router が復活したり、プライオリティが高いルータが新たに接続されても、Active Router の切り替わりは発生しません。
つまり、Active Router の切り替わりは、Active Router が使用不可となるか、自分からActive Router であることを辞めない限り発生しません。

※ この動作は、Active Router の選定についてのみです。
Standby Router は、プライオリティの高いルータが出現すると、即座に切り替わります。
これまでの例では、説明を簡略化するために、Active Router も切り替わりが発生するものとして説明をしていました。
実際には、以下に説明する設定をしない限り、切り替わりません。

(復活したルータも含め)新たに出現したルータは、たとえプライオリティが高くても、Active Router にはなりません。
Active Router 以外のルータとの間でプライオリティを比較し、もっともプライオリティの高いルータが、Standby Router となります。


上図では、Router-A とRouter-C の間はGigabit Ethernet(1000Mbps)、Router-B との間はFast Ethernet(100Mbps) です。
Router-A がActive Router に戻らないと、左側PC から右側PC へのパケットは、Gigabit Ethernet のリンクを利用することができません。


そのような状況を回避し、プライオリティが高いルータが出現したら、Active Router の切り替わりを速やかに行う方法を、Preempt(プリエンプト)と呼びます。

※ Preempt の名詞形"Preemption" は、「先買い権」を意味する英単語です。

Preempt が設定してあると、新しく出現したルータが、自分のプライオリティがもっとも高いことを確認すると、Coup メッセージを送信して、Active Router になります。






















Standby Delay コマンド


Preempt を使用していないにもかかわらず、復帰したルータがActive Router になってしまう場合があります。
Layer3 スイッチ(Catalyst) のVLAN Interface で、HSRP とSpanning Tree Protocol を併用した場合に、そのような状況が発生しえます。

















上図では、Catalyst(Layer3 Switch)でHSRP を使用しています。
HSRP を使用するポートは、Routed Port ではなく、VLAN Interface(SVI:Switched Virtual Interface) です。

Catalyst-A が再起動したり、ポートのリンクがアップすると、Spanning Tree のPort State はBLOCKING → LISTENING → LEARNING と移行し、FORWARDING となるまで、最短で30秒を要します(デフォルト値を使用した場合)。

この間も、HSRP は動作しています。
ポートがFORWARDING となっていないので、Catalyst-A は、Catalyst-B からのHello メッセージを受け取れません。

Catalyst-A は、Active Router がいないと判断して、自分がActive Router になります。

standby delay minimum reload コマンドを使用すると、インターフェイスがアップしてから、HSRP が稼動を始めるまでの時間を調整することができます。



Catalyst-A(config-if)#
Catalyst-A(config-if)#standby delay ?
minimum Minimum delay
reload Delay after reload

Catalyst-A(config-if)#
Catalyst-A(config-if)#standby delay minimum 30 reload 120
Catalyst-A(config-if)#

minimum は、インターフェイスがアップしてから、HSRP が稼動し始めるまでに要する時間です。
reload は、Catalyst が再起動してから、HSRP が稼動し始めるまでに要する時間です。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める (9) Gratuitous ARP

Active Router は、Virtual IP アドレス宛のパケットと、自分のインターフェイスに設定されたReal IP アドレス宛のパケットの両方を処理する必要があります。

Active Router は、Real IP アドレスを送信元とするパケットにも、Virtual MAC アドレスを送信元MAC アドレスとして使用します。

ルータが新たにActive Router になると、Real IP アドレスに関連付けられるMAC アドレスは、Real MAC アドレスからVirtual MAC アドレスに変わります。

反対に、これまでActive Router であったルータがActive を辞めると、Real IP に関連付けられるMAC アドレスはVirtual からReal MAC アドレスに変わります。

IP アドレスとMAC アドレスの関連付けが変わった事を、サブネット内の機器へ通知するために、ルータは、Gratuitous ARP(グラテュイタスARP)と呼ばれる特別なARP Reply パケットを送信します。

※ Gratuitous とは、「不必要な」「無意味な」といった意味の英単語です。

Active Router の切り替わり時に送信されるGratuitous ARP は、Sender IP とTarget IP がともにルータのReal IP アドレスとなっているARP Reply です。
自分宛のReply という、ARP 本来の目的からは外れた方法であることから、Gratuitous と呼ばれています。

※ Gratuitous ARP は、VRRP など、ほかのプロトコルでも利用されています。
文字通り「意味のない」ARP なので、共通の規則があるわけではなく、プロトコル毎に異なります。

下記の例は、Real IP が192.168.1.200 のルータが、Active Router になった時に送信するGratuitous ARP です。
Real IP アドレスとVirtual MAC アドレスの組み合わせで一回、ブロードキャストしています。
続けて、Virtual IP アドレスとVirtual MAC アドレスの組み合わせで二回、ブロードキャストとマルチキャストでARP Reply を送信しています。



*Feb 4 19:32:44.324: IP ARP: sent rep src 192.168.1.200 0000.0c07.ac0a,
dst 192.168.1.200 ffff.ffff.ffff Ethernet0/0
*Feb 4 19:32:44.324: IP ARP: sent rep src 192.168.1.1 0000.0c07.ac0a,
dst 192.168.1.1 ffff.ffff.ffff Ethernet0/0
*Feb 4 19:32:44.324: IP ARP: sent rep src 192.168.1.1 0000.0c07.ac0a,
dst 192.168.1.1 0100.0ccd.cdcd Ethernet0/0

※ 01-00-0c-cd-cd-cd は、Cisco でDummy Multicast と呼ばれているマルチキャストアドレスです。
Spanning Tree Protocol のUplinkFast でも、Uplink の切り替わり時に送信するマルチキャストパケットに用いられています。

上図では、Router-A がActive Router、Router-B がStandby Router となっています。

ここでRouter-A のPriority を85に下げます。

Router-A がStandby Router に変わり、Router-B がActive Router になります。
Router-A とB は、それぞれGratuitous ARP を送信します。
PC のARP キャッシュ上のエントリは、Router-B のReal IP(192.168.1.200) に関連付けるMAC アドレスをVirtual MAC アドレスへ、Router-A のReal IP(192.168.1.100) に関連付けるMAC アドレスをReal MAC アドレスへ変更します。


ルータの切り替わり時にGratuitous ARP が送信されないと、PC は、ARP キャッシュのエントリを適切に書き換えることができません。

上図では、Router-A がStandby Router になったにもかかわらず、PC からRouter-B のReal IP アドレス宛パケットの宛先MAC アドレスが、Virtual MAC アドレスになっています。
そのようなパケットは、Router-A に無視され、破棄されます。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める (8) HSRP ステート(State)

HSRP が動作しているルータは、Standby Group が安定しているときは、Init、Listen、Standby、Active State のどれかになります。

Speak、Learn は、Standby Group が安定するまでの一過性の状態です。ルータが正常に動作しているかぎり、これら二つのState にとどまり続ける事はありません。


Initial


インターフェイスがダウンしているとき、また、アップした直後の状態です。

Learn


ルータにVirtual IP アドレスが設定されておらず、他のルータのメッセージからVirtual IP アドレスを学習しようとしている状態です。

通常Vritual IP アドレスは、Standby Group に所属するすべてのルータに設定されます。
しかし、最低限一台のルータにVirtual IP アドレスを設定してやれば、受信したHello メッセージから、Virtual IP アドレスを学習することができます。
一度学習したVirtual IP アドレスは、インターフェイスがダウンしても保持しつづけます。

学習したVirtual IP アドレスはNVRAM に書き込まれないため、ルータが再起動すると、Hello メッセージから学習したVirtual IP アドレスは失われます。

Hello メッセージからVirtual IP アドレスを学習すると、HSRP State は、Learn からListen へ移行します。

Listen


ルータが、Active でもStandby State でもない状態です。
ルータが3台以上ある場合、Active にもStandby State にもならない三台目以降のルータは、Listen にとどまります。
新たにインターフェイスがアップすると、Standby Timer、Active Timer が満了するか、他のルータからのHello メッセージを受信するまで、Listen State にとどまります。

Speak


ルータが、Active またはStandby Router の選出プロセスに入っている状態です。
Standby Timer が満了すると、Standby State へ移行します。

Standby


ルータがStandby Router となっていることを表します。
Active Router から最後にHello メッセージを受信してから、Hold Time の秒数が経過すると(Active Timer の満了)、Active State へ移行します。

Active


ルータがActive Router となっていることを表します。
Active Router は、Virtual MAC アドレス宛のパケットをルーティングするとともに、Virtual IP アドレス宛のパケットも処理します。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める (7) HSRP のTimer

Standby Group 内の複数のルータが正しく動作するため、以下の三種類のタイマーが稼動しています。

※ パケットフォーマットのページで説明したHello Time とHold Time は、タイマーではなくパラメータです。
Hello メッセージで運ばれるこれらのパラメータを使用して、ルータはタイマーを稼動させます。



Active Timer


Active Router の存在を監視するためのタイマーです。
Hold Time から生成されます。

Standby Timer


Standby Router の存在を監視するためのタイマーです。
Hold Time から生成されます。

Hello Timer


定期的にHello メッセージを送信するためのタイマーです。
タイマーが満了するたびに、Hello メッセージが送信されます。
Hello Time から生成されます。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める (6) HSRP メッセージの種類

Standby Group に参加しているルータは、お互いにメッセージを交換することで、Active/Standby ルータを選定し、その状態を維持します。


HSRP のメッセージは、以下の四種類です。

Hello


ルータが、Active (またはStandby Router) となっている間、Hello Time に設定された間隔で、送信されます。

Coup (クー)
Active ではなかったルータが、Active Router になろうとするときに送信するメッセージです。
それまでActive Router であったルータから、自分よりも低いプライオリティのHello を受け取ると、Standby Router は、Coup メッセージを送信して、Active Router になろうとします。

Coup は、「打撃」を意味する英単語ですが、このメッセージ名の語源はフランス語の"coup d'etat(クーデター) です。

Resign (リザイン)
それまでActive Router であったルータが、Active Router を辞めるときに送信するメッセージです。
Active Router でHSRP の設定を削除すると、Resign メッセージを送信して、Standby Router が即座にActive Router になることを促します。

※ インターフェイスをshutdown した場合は、Resign メッセージは送信されません。Standby Router がActive Router に切り替わるのは、Hold Time の秒数が経過してからになります。

Advertisement (アドバタイズメント)
Standby Group 内の三台目以降のルータは、Listen State になり、Hello メッセージを送信しません。
Hello メッセージを送信しないため、Active かStandby Router になるまで、他のルータに存在を知られることがありません。これを、Passive Router と呼びます。

IOS version 12.1(3)T からサポートされた、ICMP Redirect との協調動作を利用する場合、Passive Router が、自分の存在をActive Router に知らせる(Advertise する) 必要があります。

※ ICMP Redirect との協調動作については、こちらを参照して下さい。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める (5) HSRP のパケットフォーマット

HSRP のパケットフォーマットです。

Ethernet


宛先MAC アドレスは、01-00-5E-00-00-02 です。
送信元MAC アドレスは、Active Router の場合はVirtual MAC アドレスです。
Active 以外のルータは、Real MAC アドレスを使います。



IP


HSRP は、サブネット内でのみ有効なプロトコルです。
HSRP のパケットはルーティングされる必要がないので、IP ヘッダのTTL(Time To Live) は必ず1になります。

HSRP はUDP を使用するので、Protocol フィールドには17(10進数)が入ります。

宛先IP アドレスは、サブネット内のすべてのルータを意味する224.0.0.2 になります。
送信元IP アドレスは、HSRP パケットを送信するインターフェイスのReal IP アドレスです。



UDP


UDP のポート番号は、宛先/送信元のどちらも、HSRP を意味する1985(10進数)が入ります。



HSRP


Version

HSRP のVersion は0です。

Opcode


HSRP メッセージの種類を意味します。
HSRP のOpcode (オプコード)は、Hello、Coup、Resign、Advertisement の四種類があります。

※ Advertisement は、IOS version 12.1(3)T からサポート

各Opcode の詳細については、後述します。

State


Standby Group に所属しているルータのState (ステート:状態)を意味します。
HSRP のState は、Init、Learn、Listen、Speak、Standby、Active の六種類があります。
各State の詳細については、後述します。

Hello Time


ルータがHello メッセージを送信する間隔を意味します。
デフォルトは3秒です(1〜254秒までの間で設定可能です)。

Hold Time


他のルータから受信したHello メッセージの内容を保持する時間を意味します。
デフォルトは10秒です("Hello Time + 1秒" 〜 255秒までの間で設定可能)。

Active Router からの最後のHello メッセージ受信後、Hold Time の秒数が経過すると、Standby Router は、Active Router が存在しなくなったと判断して、自分がActive Router になろうとします。

Hello Time とHold Time は、Active Router に設定された値が、Standby Group 内で共有されます。
Active Router が切り替わると、新しいActive Router に設定されている値に変わります。

※ 値が変わるのは、新しいActive Router に、明示的に値が設定されている場合だけです。明示的に設定されていない場合(デフォルト値)は、以前のActive Router の値が使われ続けます。

同様に、Standby Router からの最後のHello メッセージ受信後、Hold Time が経過すると、Listen State にあったルータは、Stnadby Router が存在しなくなったと判断して、自分がStandby Router になろうとします。

Priority


ルータに設定されたプライオリティが入ります。
プライオリティが一番高いルータがActive Router に、二番目に高いルータがStandby Router になります。
プライオリティが同じ場合は、Real IP アドレスが比較の対象となります。
プライオリティのデフォルトは100です(0〜255の間で設定可能です)。

Standby Group


ルータに設定されたStandby Group 番号が入ります。
Standby Group 番号のデフォルトは0です。
(Standby Group 番号を設定しない場合は、0が自動的に設定されます。show running-config には反映されませんが、show standby を実行すると、Group 番号が0になっているのが確認できます)

Reserved


未使用フィールドです。このフィールドには0が格納されています。

Authentication Data


認証用の文字列(平文)が入ります。
文字列を設定することで、Standby Group に参加するルータの簡易認証を行うことができます。

Virtual IP Address


設定された(もしくは、他ルータから学習した) Virtual IP アドレスが格納されます。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める (4) Hello の交換

HSRP のState がActive もしくはStandby のルータは、Hello メッセージを交換しあうことで、お互いの状態を知ることができます。

Hello メッセージは3秒毎に送信されます。
この間隔は、Hello Time というパラメータを変更することで調整ができます(1〜254秒)。

Active Router からのHello メッセージを、最後に受信してから10秒経過すると、Active Router がいなくなったと判断し、Standby Router はActive Router に切り替わります。
この秒数は、Hold Time というパラメータで調整できます(Hello Time + 1秒〜255秒)。

Hello メッセージは、Standby Group 番号やVirtual IP アドレスなどの情報も運びます。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める (3) バーチャルルターのアドレス

端末が、ルータを越えた先のネットワークへパケットを送るには、デフォルトゲートウェイのIP アドレスとMAC アドレスを知る必要があります。

バーチャルルータのIP アドレスとMAC アドレスは、それぞれVirtual IP アドレス、Virtual MAC アドレスと呼ばれます。

Virtual IP アドレスは、Standby Group に設定されたIP アドレスです。
Virtual MAC アドレスは、Standby Group 番号を用いて生成されます。

00-00-0c-07-ac-xx の最後の1バイトに、Standby Group 番号を16進数にしたものが入ります。
Standby Group 番号が10の場合は、

00-00-0c-07-ac-0a

となります。

Virtual IP ---- Standby Group により共有されるIP アドレス
Virtual MAC --- Standby Group により共有されるMAC アドレス
Real IP ------- 各ルータのインターフェイスに設定されたIP アドレス
Real MAC ------ 各ルータのインターフェイス固有のMAC アドレス


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める (2) バーチャルルータ

HSRP の主な目的は、ゲートウェイの切り替わりに自律的な対応ができない端末へ、冗長化されたゲートウェイを提供することです。
ゲートウェイの切り替わりは、可能な限り、端末に意識させることなく行われる必要があります。
このことを、端末から見て透過的(Transparent)であると呼びます。

ゲートウェイが切り替わっても同じアドレスが使えれば、端末は、ゲートウェイの切り替わりを意識することなく通信を継続できます。

HSRP では、仮想ルータを用意し、端末のデフォルトゲートウェイにこの仮想ルータを指定します(図中のRouter-X)。

Router-A が正常に動作している間は、Router-X 宛のパケットはRouter-A により処理されます。

Router-A に異常が発生すると、Router-B がRouter-X の役割を肩代わりすることで、Router-X 宛のパケット処理を継続することができます。
端末から見ると、切り替わりが発生してもゲートウェイはRouter-X なので、切り替わりを意識することなく通信を継続することができます。

バーチャルルータ(図中のRouter-X) の役割を担うルータの集まりを、Standby Group と呼びます。

バーチャルルータの役をしている状態(State) をActive と呼びます。
Active となっているルータをActive Router と呼びます。

ルータにはプライオリティが設定可能で、もっともプライオリティが高いルータが、Active Router となります。
プライオリティのデフォルト値は100です。
プライオリティが同じ場合は、IP アドレスが大きい方がActive Routerとなります。

プライオリティの低いルータは待機系となります。
待機系となった状態(State) をStandby と呼び、Standby となっているルータをStandby Router と呼びます。


HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

HSRP を究める(1) はじめに

通常、端末に設定されるデフォルトゲートウェイは、ひとつだけです。

デフォルトゲートウェイに不具合が発生して使用不可能になると、通信を継続するためには、ゲートウェイを切り替える必要があります。

端末自身がゲートウェイの不具合を検知して、自律的にゲートウェイを切り替えるには、RIP やOSPF といったルーティングプロトコルを実装する必要があり、現実的ではありません。
ICMP Router Discovery Protocol(IRDP) やProxy ARP を利用することも無理ではありませんが、切り替えに要する時間に難があり、実用的ではありません。

端末の側で特別な手段を実装することなく、デフォルトゲートウェイの冗長化をルータ側で実現する方法に、VRRP(Virtual Router Redundancy Protocol) とHSRP(Hot Standby Router Protocol) があります。

VRRP はIETF によって標準化されたプロトコルですが、HSRP はCisco Systems が開発した独自プロトコルです。
今回は、HSRP について説明します。







デフォルトゲートウェイに不具合が発生して使用不可能になると、通信を継続するためには、ゲートウェイを切り替える必要があります。

端末自身がゲートウェイの不具合を検知して、自律的にゲートウェイを切り替えるには、RIP やOSPF といったルーティングプロトコルを実装する必要があり、現実的ではありません。
ICMP Router Discovery Protocol(IRDP) やProxy ARP を利用することも無理ではありませんが、切り替えに要する時間に難があり、実用的ではありません。

端末の側で特別な手段を実装することなく、デフォルトゲートウェイの冗長化をルータ側で実現する方法に、VRRP(Virtual Router Redundancy Protocol) とHSRP(Hot Standby Router Protocol) があります。

VRRP はIETF によって標準化されたプロトコルですが、HSRP はCisco Systems が開発した独自プロトコルです。
今回は、HSRP について説明します。








HSRP を究める (1) はじめに
HSRP を究める (2) バーチャルルータ
HSRP を究める (3) バーチャルルターのアドレス
HSRP を究める (4) Hello の交換
HSRP を究める (5) HSRP のパケットフォーマット
HSRP を究める (6) HSRP メッセージの種類
HSRP を究める (7) HSRP のTimer
HSRP を究める (8) HSRP ステート(State)
HSRP を究める (9) Gratuitous ARP
HSRP を究める(10) Preempt
HSRP を究める(11) Interface Tracking
HSRP を究める(12) BIA (Burnt In Address)
HSRP を究める(13) Authentication
HSRP を究める(14) ICMP Redirect
HSRP を究める(15) ICMP Redirect との協調動作

HSRP を究める - 実践編(1) HSRP を設定する前の状況を確認する
HSRP を究める - 実践編(2) Standby Group をつくる
HSRP を究める - 実践編(3) Active Router に障害を発生させてみる(1)
HSRP を究める - 実践編 (4) Preempt とプライオリティを設定する
HSRP を究める - 実践編 (5) Active Router に障害を発生させてみる(2)
HSRP を究める - 実践編 (6) Interface Tracking
HSRP を究める - 実践編 (7) Timer を変更する
HSRP を究める - 実践編 (8) Standby Group に参加するルータの認証
HSRP を究める - 実践編 (9) Standby Group を追加する
HSRP を究める - 実践編(10) Active Router に障害を発生させてみる(3)
HSRP を究める - 実践編(11) Standby Group に名前を付ける
HSRP を究める - 実践編(12) ICMP Redirect(1)Active Router
HSRP を究める - 実践編(13) ICMP Redirect(2)Passive Router
HSRP を究める - 実践編(14) ICMP Redirect(1)Unknown Router
HSRP を究める - 実践編(15) 設定用コマンド(1)
HSRP を究める - 実践編(16) 設定用コマンド(2)
HSRP を究める - 実践編(17) 設定用コマンド(3)
HSRP を究める - 実践編(18) 設定用コマンド(4)
HSRP を究める - 実践編(19) 設定用コマンド(5)
HSRP を究める - 実践編(20) show コマンド

HSRP を究める - 応用編(1) 複数のインターフェイスをトラッキングする(1)
HSRP を究める - 応用編(2) 複数のインターフェイスをトラッキングする(2)
HSRP を究める - 応用編(3) IP の経路情報 をトラッキングする(1)
HSRP を究める - 応用編(4) 異なる種類のObject をトラッキングする
HSRP を究める - 応用編(5) 特定のIP アドレスへの到達性をトラッキングする
HSRP を究める - 応用編(6) トラッキング対象のObject に重み付けをする
HSRP を究める - 応用編(7) HSRP version 2
HSRP を究める - 応用編(8) HSRP version 2 のパケットフォーマット
HSRP を究める - 応用編(9) HSRP version 2 (2)

Remark - Access-list にコメントを付ける

何十行にも渡るアクセスリストを読むのは、結構面倒です。
自分の書いたアクセスリストならまだしも、他人の書いたものなら、なおさらです。

どういう目的のアクセスリストなのか、コメントが付いていると理解もしやすいし、書き間違いを指摘するのも容易になります。

access-list remark コマンドを使うと、アクセスリストにコメントを付けることができます。




!
access-list 100 deny icmp host 192.168.1.2 any
access-list 100 permit ip any any
access-list 100 remark Reject ICMP from 192.168.1.1
!

上記の例では、192.168.1.2 からのICMP を拒否していることを示すコメント「Reject ICMP from 192.168.1.1」が付けられています。

access-list remark は、IOS Version 12.0(2)T から使用可能です。

motd - ログイン時にバナーを出力する

Telnet を使ってルータ間を行ったり来たりしながら、ログを集めることがあります。
対象ルータが変わるたびにログの保存ファイルを変更するのも面倒だし、ルータ間で比較をする場合は、同じファイルにしたほうが良いこともあります。

しかし、後から他の人がログを見ようとすると、これがネックになります。
あるルータのログだと思って読み続けていたら、いつの間にか他のルータに変わったのに気づかず、誤った解釈をしてしまうことがあります。

motd (Message Of The Day) を使うと、そのようなミスを減らすことができます。

motd は、機器にログインした時に出力されるバナーメッセージです。
Cisco のIOS では、banner motd コマンドで設定します。



Router2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#banner motd #
Enter TEXT message. End with the character '#'.
Hostname - Router2
Location - Tokyo Bldg. Floor 3
Contact - net_admin@abc_corp.com
#
Router2(config)#^Z
Router2#

このルータのコンソールへアクセスすると、motd が表示されます。



Press RETURN to get started.

<中略>

Hostname - Router2
Location - Tokyo Bldg. Floor 3
Contact - net_admin@abc_corp.com

Router2>

このままでは、Telnet でこのルータにアクセスした場合には、motd は表示されません。
VTY にexec-banner コマンドを設定してやります。



Router2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#line vty 0 4
Router2(config-line)#exec-banner
Router2(config-line)#^Z
Router2#

Telnet でRouter2 にログインします。



Router1#
Router1#Router2
Trying Router2 (1.1.1.2)... Open

Hostname - Router2
Location - Tokyo Bldg. Floor 3
Contact - net_admin@abc_corp.com


User Access Verification

Password:
Router2>en
Password:
Router2#

descriptions - インターフェイスにメモを付ける

このポートには何がつながってるの?


BGP のルートリフレクタ専用に使うといった特殊な事例を除き、大抵のルータやスイッチには複数のポートが存在します。

トラブル対応をする際、機器のコンソールとネットワーク図などの資料の間を行ったり来たりしながら、ポートの設定を確認していきます。

機器の設定の中に、そのポートが何に繋がっているのかメモを残せれば、この作業が省けます。

Cisco のIOS では、description コマンドを使って、インターフェイスにメモを書き込むことができます。



Router#sh running-config interface ethernet 0/0
Building configuration...

Current configuration : 121 bytes
!
interface Ethernet0/0
description To_Router2_Ethernet0/0
ip address 1.1.1.1 255.0.0.0
no ip directed-broadcast
end

Router#

Hostname - 名前をください

お客「えーっと、RT03S001 にRT03N003 が繋がっていてですね、、、その先にはRT02W001 とRT01E011 が・・・・」

サポート「RT02W001 に繋がっているのはどれですか?」

お客「RT02W003・・・違った、004 です」


トラブルの渦中にいる人から、状況を訊き出して把握するのは、骨が折れることです。
さっき聞いたことと矛盾していたり、やっと把握できたと思ったら、「間違ってました、本当は・・・」
送ってきた情報は見当違いなものだったり・・・

現場にいない人に、トラブルの状況を正確に伝えるのは、骨が折れることです。
何度も同じことを訊いてきたり、要求された情報を送ったら、今度はアレを採れ、コレを採れ・・・いつまでたっても問題は解決しません。


サーバやネットワーク機器に名前をつける際、多くの場合、組織内で定められた命名規則に従います。
ファイルサーバはFS、ルータはRT、スイッチはSW、ファイアウォールはFW・・・多くの場合、これに連番が続きます。

確かに、シンプルな命名規則があれば、管理が容易になりますし、正規表現を使うこともできます。
が、そのhostname が通用するのは、命名規則に慣れ親しんだ組織内だけです。

トラブルコールを受けたサポート要員にとって、英数字の文字列でしかないhostname はやっかいな代物です。
お客の口から次々に出てくる機器の名前が、ネットワークのどの位置に存在するのか、なかなかイメージすることができません。
トラブルの解決が遅れる要因にもなり得ます。

地名などの設置場所や、ネットワーク内の位置づけを連想しやすい単語をhostname に 含めることで、そのようなストレスを多少なりとも緩和することができます。
単語を付ける場所をhostname の末尾にすれば、正規表現を使う妨げにもなりません。

Collision - Link Segment におけるコリジョンの取り扱い

10BASE5、10BASE2 といったバスメディアでは、一度にフレームを送信する事が出来る機器は、一台のみです。
複数の機器が同時にフレームを送信すると、フレーム同士の衝突(Collision) と判断され、送信は中断されます。
物理メディア(ケーブル)が複数機器によって共有されているためです。

バスのように、1本のケーブル上に3台以上の機器が存在可能なセグメントを、IEEE802.3 では、Mixing Segment と呼びます。
これに対してUTP ケーブルや光ケーブルのように、ケーブル上に2台までしか存在できない、Point-to-Point なセグメントを、Link Segment と呼びます。

Link Segment では、送信(TX) と受信(RX) が物理的に別なワイヤを用いているため、フレームが衝突することは本来ありません。

しかし、10BASE5 などのバスメディアとの互換性を保つため、10BASE-T や100BASE-TX でも、Half Duplex の場合は、同時に送信できる機器を一台に制限しています。

UTP ケーブルや光ケーブルを使ったEthernet/802.3 PHYでは、対向機器からフレームを受信している間は、送信を行いません。
自分がフレームを送信している最中に対向機器からフレームを受信すると、コリジョンが発生したと判断して送信を中断します。

Full Duplex の場合は、そのような状態が発生しても送信を続けます。これによって全二重通信が可能になります。

Duplex Mismatch - Ethernet におけるDuplex 設定不一致の確認方法

Link Segment の両端でDuplex の設定に不一致(Duplex Mismatch)があると、一方はフレームを送信し続け、他方はほとんど送信できない状態が発生します。

※ Link Segment については、Collision - Link Segment におけるコリジョンの取り扱いを参照して下さい。



上の図では、PC はFull Duplex、Switch はHalf Duplex となっています。

Full Duplex の場合、フレームを送信中に対向機器からのフレームを受信しても、かまわず送信を続けます。

Half Duplex の場合、フレームを送信する前に、対向機器からのフレームの有無を確認します(CSMA/CD のCS:Carrier Sense)。
対向機器がフレームを送信中であれば(自分が受信中)、送信を見合わせます。
このため、 フレームを受信し続けている限り、Half Duplex 側は送信が出来ません。

Full Duplex 側も途切れなく送信し続けているわけではありませので、間隙を突いてフレーム送信を開始することもできないわけではありません。
仮に送信を開始できたとしても、Full Duplex 側がフレームを送信し始めると、コリジョンとなるので、送信を完了できる可能性は低くなります。
(Full Duplex 側は、コリジョンが発生してもかまわず送信を続けます)


Duplex Mismatch な状態は、スイッチやルータのポートで、以下のカウンタを確認することで把握できます。

Half Duplex 側:


送信している最中に対向機器からのフレームを受信すると、Half Duplex 側では、コリジョンが発生したと判断します。
また、Carrier Sense が16回発生すると(16回目の再送処理が発生すると)、フレーム送信をあきらめます(Excessive collision)。

Cisco のIOS では、show interface で確認できます。



Router#show interface ethernet0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 00xx.xxxx.xxxx (bia 00xx.xxxx.xxxx)
Internet address is 192.168.23.101/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 2630 drops
5 minute input rate 2000 bits/sec, 3 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
7751694 packets input, 732225537 bytes, 19 no buffer
Received 7751694 broadcasts, 0 runts, 0 giants, 2630 throttles
513 input errors, 0 CRC, 0 frame, 0 overrun, 513 ignored
0 input packets with dribble condition detected
276177 packets output, 28200213 bytes, 0 underruns
1 output errors, 36 collisions, 2 interface resets
0 babbles, 0 late collision, 132 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Router#

コリジョンは、Half Duplex な環境であれば普通に発生し得るので、コリジョンだけを見ても正常か異常かの判断ができないこともあります。
その場合は、Late Collision を確認してください。
正常に動作しているEthernet では、Late Collision は発生しません。
フレームを送信し始めて512 Bit Time が経過してから発生したコリジョンは、Late Collision としてカウントされます。

Late Collision については、 Late Collision - Ethernet におけるコリジョン検出のメカニズム を参照してください。

Full Duplex 側:


コリジョンに遭遇すると、Half Duplex 側は送信を中断します。
そうすると、中断するまで送信中だったフレームの断片が、Full Duplex 側で受信されます。

不完全なフレームを受信したFull Duplex 側では、フレームの長さが64バイト未満であればRunts をカウントします。
フレームの長さが8ビットの倍数でない場合は、Alignment Errorとしてカウントされます。
そのようなフレームからは正しいCRC 値が生成できないので、CRC Error もカウントされます。

※ 機器の実装によっては一部のカウンターしかカウントしない場合もあります

Catalyst シリーズでも、Alignment Error カウンタの表示方法は機種により異なります。
下記の例は、Catalyst3750 のものです。



Cat3750#show controllers ethernet-controller fastEthernet 1/0/1

Transmit FastEthernet1/0/1 Receive
0 Bytes 0 Bytes
0 Unicast frames 0 Unicast frames
0 Multicast frames 0 Multicast frames
0 Broadcast frames 0 Broadcast frames
0 Too old frames 0 Unicast bytes
0 Deferred frames 0 Multicast bytes
0 MTU exceeded frames 0 Broadcast bytes
0 1 collision frames 0 Alignment errors
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 0 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 0 Minimum size frames
0 8 collision frames 0 65 to 127 byte frames
0 9 collision frames 0 128 to 255 byte frames
0 10 collision frames 0 256 to 511 byte frames
0 11 collision frames 0 512 to 1023 byte frames
0 12 collision frames 0 1024 to 1518 byte frames
0 13 collision frames 0 Overrun frames
0 14 collision frames 0 Pause frames
0 15 collision frames
0 Excessive collisions 0 Symbol error frames
0 Late collisions 0 Invalid frames, too large
0 VLAN discard frames 0 Valid frames, too large
0 Excess defer frames 0 Invalid frames, too small
0 64 byte frames 0 Valid frames, too small
0 127 byte frames
0 255 byte frames 0 Too old frames
0 511 byte frames 0 Valid oversize frames
0 1023 byte frames 0 System FCS error frames
0 1518 byte frames 0 RxPortFifoFull drop frame
0 Too large frames
0 Good (1 coll) frames
0 Good (>1 coll) frames

Cat3750#


Ethernet の再送処理 - バックオフアルゴリズム

Ethernet では、自分が送信したフレームがコリジョンに遭遇すると、ランダムに生成した待ち時間が経過した後、フレームの再送信を試みます。
待ち時間を生成するための計算式を、Truncated Exponential Backoff Algorithm と呼びます。
このアルゴリズムで算出される待ち時間は、必ず、スロットタイム(512BT) のn倍となります。
0 <= n < 2^k (2のk乗)

n --- 0 以上 2^k 未満
k --- Frame 再送信回数(1 〜 10)


k に再送信回数が代入されるのは1 〜10 までで、11回目以降16回目までは10 が代入されます。
つまり、再送待ち時間は最長52.4 ミリ秒( = 2^10 * 512BT)となります。

送信中のフレームがコリジョンに遭遇すると(1回目)、0 〜 2^1 -1 の中からランダムにバックオフタイムが選択されます(0 もしくは 1)。

0 --- 512BT * 0 = 0BT = 0 second
1 --- 512BT * 1 = 512BT = 51.2 usec


10Mbps の場合、1が選択されると、51.2マイクロ秒の待ち時間が経過した後、フレームの再送信を試みます。
0が選択された場合は、待ち時間無しで再送を試みます。

2回目の送信がコリジョンに遭遇すると、0 〜2^2 -1 の中からランダムに、バックオフタイムが選択されます(0/1/2/3)。

0 --- 512BT * 0 = 0BT = 0 second
1 --- 512BT * 1 = 512BT = 51.2 usec
2 --- 512BT * 2 = 1024BT = 102.4 usec
3 --- 512BT * 3 = 1536BT = 153.6 usec



再送回数(k)
n=0〜2^k-1
最大待ち時間 (n * 512BT)
1 1 512
2 3 1536
3 7 3584
4 15 7680
5 31 15872
6 63 32256
7 127 65024
8 255 130560
9 511 261632
10 1023 523766
11 1023 523766
12 1023 523766
13 1023 523766
14 1023 523766
15 1023 523766
16 N/A フレーム破棄


再送は15回まで可能です。
16回目の再送が発生すると、端末はフレームを破棄し、再送回数カウンタを初期化した後、以後の処理を上位層に委ねます。



n は、コリジョンに遭遇した端末が想定する、コリジョンドメイン内の端末数を意味します。

初めてコリジョンに遭遇すると、端末はコリジョンドメインに、自分以外に1台端末が存在すると想定します。
2回目は3台、3回目は7台、とExponential(指数関数的)に想定端末数を増加させて行きます。
想定端末数が1023 に達すると(再送回数が10回に達すると)、以後は想定端末数は増加しません。 この1023 に、自分自身を足した1024が、コリジョンドメインに存在可能な最大端末数です。

Late Collision - Ethernet におけるコリジョン検出のメカニズム

端末が、自分の送信したフレームがコリジョンに遭遇したことを認識するためには、そのフレームを送信している最中にコリジョンの発生を検出する必要があります。
フレームを構成する最後のビットを送信し終えた後にコリジョンが発生しても、送信した端末はそのコリジョンが自分のフレームにより発生した物かどうかを判断できないからです。

※ この記事の内容は、10Mbps のEthernet を前提にしています。Fast Ethernet(100Mbps) に適用するには、時間を10分の1にして下さい。

コリジョンドメインの一番端に存在する端末が送信したフレームが、最遠端まで届いた所でコリジョンに遭遇し、その事実が送信端末に認識されるまで、フレームは送信され続けていなければならないわけです。
これを満たすため、Ethernet の最小フレームサイズは64バイト(512ビット)に定められています。

フレームがコリジョンドメインの一番端から送信されて、最遠端から戻ってくるまでのビット時間(BT)を、最大伝播遅延(Maximum Propagation Delay)と呼び、Ethernet では、464 BT と定められています。
(464 BT = 46.4 ナノ秒は、1ビットが同軸ケーブルを約5キロメートル伝播されるのに要する時間です)

※ BT(Bit Time) は、1ビットの送信に要する時間です。

100ns = Ethernet
010ns = FastEthernet

自分が送信したフレームがコリジョンに遭遇したと認識すると、その事実をコリジョンドメイン内の全ての端末へ通知するため、Jam と呼ばれる信号(32ビット)を送信します。

最大伝播遅延と最大ジャム送信時間合計に16 BT を足した512 BT (= 51.2 マイクロ
秒)をラウンドトリップ時間と呼び、コリジョンドメインサイズの上限を規定しています。

464BT = Maximum Propagation Delay (最大伝播遅延)
032BT = Maximum Jam Time(最大ジャム送信時間)
016BT
------------------------------------------------------
512BT = ラウンドトリップ時間


最小フレームサイズ = 64バイト(512ビット) は、このラウンドトリップ時間から導き出された物です。
これにより、送信するフレームがコリジョンに遭遇した場合、そのフレームを送信し終わるまでに必ず検出できる事が保証されています。


チャネル獲得


端末がフレームを送信し始めて512 BT が経過するまでは、フレームがコリジョンドメイン内の隅々まで到達していない可能性があります。
フレームがまだ到達していない個所の端末は、LAN が空いているものと判断して、フレーム送信を開始できます。
そして、コリジョンが発生します。

フレームを送信し始めて512 BT が経過すると、LAN上にフレームが存在する事を全ての端末が認識しているので、他の端末によりフレーム送信が妨害されることはありません。
この512 BT をスロットタイムと呼びます。

スロットタイムの間コリジョンに遭遇せずにフレームを送信できた状態を、「チャネルを獲得した(Aquired)」と呼び、チャネル獲得の後は、コリジョンに遭遇せずに送信を完了できる事が保証されます。

ここまでの話は、LAN 上のすべての機器が、CSMA/CD の規則を遵守している場合です。

チャネルを獲得したにも関わらず(512 BT 経過後)、コリジョンが発生すると、Late Collision(レイトコリジョン)としてカウントされます。
その名の通り、「(スロットタイムが過ぎた後)遅れてやってきた」コリジョンというわけです。

Late Collision は、ラウンドトリップ時間が512 BT に収まっていない事を意味します。
ケーブル長が規定値に収まっていなかったり、途中のリピータやトランシーバの不具合で発生する事が多いです。


100メートルというUTP ケーブルの最大長は、ラウンドトリップ時間を元に割り出された物ではなく、電気信号の減衰率を元に定められたものです。
そのため、ケーブル長に起因するLate Collision は、UTP ケーブルの環境で発生することは稀です。
UTP ケーブルの環境でLate Collision が観測される場合、Duplex Mismatch が原因となることが多いです。

Duplex Mismatch については、Duplex Mismatch - Ethernet におけるDuplex 設定不一致の確認方法を参照して下さい。

NTP - 時刻の同期をとる

ルータやスイッチに限らず、ネットワーク上の機器はみな時計を持っています。

ルータやスイッチの時計にずれがあると、運用上様々な問題が生じます。
機器から出力されるメッセージのタイムスタンプにずれがあると、トラブルシューティングを行うのが困難になります。

NTP (Network Time Protocol) は、そのような悩みを解決してくれます。
ネットワーク上にマスターとなるTime Server を配置し、すべての機器がTime Server と同期することで、ずれの発生する可能性を最小限にとどめることができます。

Time Server には、ルータやスイッチといったネットワーク機器がなることもできます。


Cisco.com (CCO) レビューについて

高アベイラビリティ Catalyst 6000 スイッチの NTP 設定 (ライター翻訳)

Example NTP Configuration for High Availability Catalyst 6000 Switch (英文)


Catalyst6500 上のMSFC(Multilayer Switch Feature Card) を、NTP Server にする方法を説明する技術資料です。

Catalyst6500 は、Slot1 とSlot2 にSupervisor Engine を実装して、冗長化することができます(※)

※ Supervisor1a かSupervisor2 の場合。Supervisor720 やSupervisor32 は、Slot5 もしくはSlot6 に入ります。

Supervisor には、MSFC と呼ばれるドーターカードが実装されています。
Supervisor Engine でCatOS を用いた場合、MSFC はIOS が動作するルータの役割をします(※)

※ Supervisor Engine でIOS を用いることもできます。その場合、Supervisor Engine とMSFC は単一のシステムとして動作します。

つまり、Supervisor Engine が2枚実装されているCatalyst6500 の中では、2台のルータが動作していることになります。

シャーシ内にMSFC が二つ存在する場合の動作方式は、以下の二種類があります。

DRM (Dual Router Mode) ----- 二つのMSFC がそれぞれ独立したルータとなります
SRM (Single Router Mode) --- 片側のMSFC はバックアップとなります

この資料では、DRM を例として挙げています。
DRM の場合、config-sync を設定すると、設定を必要とするのは片側のMSFC のみとなります。
一方のMSFC に設定すると、他方にも自動的に反映してくれます。



!config-sync is enabled
redundancy
high-availability
config-sync
!


スイッチの二重 MSFC が他のルータについては NTP サーバとして機能して、ネットワーク内ではスイッチとして機能します(このスイッチ自体にあるスーパーバイザ エンジンをむ)。

訳がおかしいですね。
正確には
「二つのMSFC は、ネットワーク上のほかのルータやスイッチに対して、NTP Server として機能します(スイッチは、MSFC が実装されているCatalyst も含みます)」
となります。

Host Name やインターフェイスに設定するIP アドレスなど、重複が許されない設定については、alt に続けて個別の設定を指定します。

!

!
interface Loopback0
ip address 10.10.10.1 255.255.255.252 alt ip address 10.10.10.5 255.255.255.252
!


コマンドの中には alt キーワードをサポートせず、したがって config-sync と共に使用できないものがあります。 たとえば ntp peer コマンドです。このコマンドで config-sync がサポートされれば、MSFC15 と MSFC16 は NTP 同位関係を確立できます。 これがネットワークの要件である場合は、config-sync をディセーブルにして、手動で確実に、2 つの MSFC の設定を二重 MSFC システムの要件に合わせます。詳細については 関連情報を参照してください。

不可能なことを「(仮に)サポートされていればできます」と言っても意味がありません。
上記の文では、可能にする手段があるかのような誤解を招きかねませんが、実際にはありません。

スーパーバイザ エンジンでは、sc0 管理インターフェース(172.16.100.100)は VLAN 1 に属します。 スイッチのデフォルト ゲートウェイは、VLAN 1 インターフェース(172.16.100.1)上のホットスタンバイ ルータ プロトコル(HSRP)IP アドレスです。

Supervisor Engine のsc0 インターフェイスは、Catalyst を管理するためのものです。
デフォルトではVLAN 1 に属していますが、所属VLAN は必要に応じて変更可能です。
スイッチの管理インターフェイスは、ルータの視点から見ると、スイッチに接続されている端末と同じ扱いになります。

このように実装した場合の問題の 1 つは、スイッチ全体に障害が起きた場合ネット ワーク内の他のデバイスが同期しないということです。

この資料でも言及されているように、一つのシャーシ内の二つのルータをNTP Server としても、冗長化という点ではそれほど意味はありません。
MSFC に加えて、他のルータをバックアップのTime Server として利用するのが現実的でしょう。

HSRP - 負荷を分散する

HSRP (Hot Standby Router Protocol) は、Cisco により開発された、デフォルトゲートウェイを冗長化するプロトコルです。
同様の機能を実現するプロトコルに、VRRP (Virtual Router Redundancy Protocol) があります。

実際の適用箇所はデフォルトゲートウェイに限定されませんが、本来の目的は、ルーティングプロトコルを実装していない端末に対して、Next Hop の冗長性を提供することにあります。

HSRP では、複数台のルータでStandby Group と呼ばれるグループを構成します。
Standby Group には、Virtual IP アドレスと、それに対応するVirtual MAC アドレスが一つずつ存在します。

サブネット内の端末は、Virtual IP アドレスをデフォルトゲートウェイとして設定します。
Standby Group の中から、一台のルータがActive Router となり、Virtual IP/MAC アドレス宛のパケットを処理します。
(Standby Group の二台目のルータはStandby Router と呼ばれます)

Active Router とStandby Router は、Hello パケットを交換しあうことで、お互いの存在を確認します。
Active Router が存在しなくなると(Hello パケットが届かなくなると)、Standby Router はActive Router に代わり、Virtual IP/MAC 宛のパケット処理を肩代わりします。

こうして、端末は、ルータの切り替わりを認識することなく、通信を継続することができます。


Cisco.com (CCO) レビューについて

HSRP(Hot Stanby Router Protocol)を使用したロード シェアリング (ライター翻訳)

Load Sharing with HSRP (英文)


複数のStandby Group を作成することで、ルータの負荷を分散するとともに、冗長化された回線を有効利用する方法を説明した技術資料です。

Standby Group が一つしかない場合、同時に利用可能なルータは一台だけです。
Standby Router や三台目以降のルータ、それらのルータが接続している回線は待機状態となります。

Standby Group を複数作成すると、そのサブネット内の端末が利用可能なデフォルトゲートウェイは、Standby Group の数だけ存在することになります。

端末毎にデフォルトゲートウェイを変えてやることで、ルータの負荷を分散するとともに、回線を有効利用することができます。
















<R1 の設定



interface Ethernet0
ip address 171.16.6.5 255.255.255.0
standby 1 preempt
standby 1 ip 171.16.6.100
standby 1 track Serial0
standby 2 preempt
standby 2 ip 171.16.6.200
standby 2 track serial 0
standby 2 priority 95

R2 の設定



interface Ethernet0
ip address 171.16.6.6 255.255.255.0
standby 1 preempt
standby 1 ip 171.16.6.100
standby 1 track Serial0
standby 1 priority 95
standby 2 preempt
standby 2 ip 171.16.6.200
standby 2 track serial 0

171.16.6.0/24 というサブネットには、171.16.6.100 と171.16.6.200 の二つのデフォルトゲートウェイが存在することになります。

■ priority
Priority 値の比較で、どのルータがActive Router となるかが決まります。
Priority が最も大きいルータがActive Router となります。デフォルト値は100 です。

Priority が同じ場合、IP アドレスが比較され、もっとも大きいものが選択されます。

■ preempt(プリエンプト)
それまでStandby Router だったルータがActive Router となったあと、従来のActive Router が復旧したとします。

本来であれば、復旧したルータがまたActive Router の役をやってくれれば良いのですが、HSRP ではそうはなりません。
肩代わりしたルータがなんらかの理由でActive Router の役を辞めない限り、そのままです。

Preempt を設定すると、従来のActive Router が復旧すると(=より大きいPriority のルータが出現すると)、復旧したルータがActive Router になります。

■ track
HSRP は、サブネットの中でのみ有効な仕組みです。
あるインターフェイスで発生した障害は、他のサブネットのStandby Group には影響を与えません。

先の図で言うと、Router-A とRouter-C の間のリンクがダウンしても、Router-A はStandby Group 1 のActive Router であり続けてしまいます。

このような状態に対応するため、track を設定します。
この設定例では、standby * track Serial0 が設定してあります。

これは、Serial0 インターフェイスを監視することを意味します。
このインターフェイスのリンクがダウンすると、HSRP で設定されたPriority を下げます。
Priority の下がったHello を受け取ると、Standby Router はActive Router の役を肩代わりします。

通常は、standby * track Serial0 20 というふうに、どの程度Priority を下げるかを指定します。指定がない場合は、10 下げられます。

重要な注意事項

ローエンド製品に搭載されているイーサネット(Lance および QUICC)コントローラによっては、アドレス フィルタ内にユニキャスト Media Access Control(MAC; メディア アクセス制御)アドレスを 1 つしか設定できません。

複数のStandby Group を作成する場合、ルータは、Standby Group の数だけVirtual MAC アドレスを認識する必要があります。

しかし、ルータに実装されているイーサネットコントローラの種類によっては、同時に認識できるMAC アドレスが一つだけの場合もあります(Lance やQUICC)。

そのようなルータでHSRP を使用する場合、standby * use-bia を設定します。
standby * use-bia を設定すると、ルータはHSRP の処理に、Virtual MAC アドレスではなく、ルータ本来のMAC アドレスを使用します。
BIA はBurnt In Address の略で、イーサネットコントローラに本来プログラムされているアドレスを意味します。

イーサネットコントローラの種類は、show interface コマンドで確認できます。



Router#show interface ethernet0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 00e0.1eb9.9ec2 (bia 00e0.1eb9.9ec2)
Internet address is 192.168.23.101/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 2630 drops
5 minute input rate 2000 bits/sec, 3 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
7751694 packets input, 732225537 bytes, 19 no buffer
Received 7751694 broadcasts, 0 runts, 0 giants, 2630 throttles
513 input errors, 0 CRC, 0 frame, 0 overrun, 513 ignored
0 input packets with dribble condition detected
276177 packets output, 28200213 bytes, 0 underruns
1 output errors, 36 collisions, 2 interface resets
0 babbles, 0 late collision, 132 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Router#

Link Aggregation - リンク/ポートを束ねるということ

Link Aggregation - リンク/ポートを束ねる

Cisco のCatalyst シリーズでは、Ethernet ポートを束ねる機能(Link Aggregation) をEtherChannel (イーサーチャネル) と呼んでいます。

この名称は、Kalpana (現在はCisco)により1996年に商標登録されたものです。
Kalpana は、LAN スイッチの黎明期に誕生したメーカで、Ethernet ポートに初めてFull Duplex 機能を実装した会社でもあります。

通信機器市場に占めるCisco のシェアから、Ethernet ポートを束ねる事をChanneling(チャネリング)と呼ぶのが一般的です。
しかし、ポート(リンク)を束ねる事をチャネルと呼ぶのは、実際にはCisco くらいで、メーカ毎に様々な呼び方があります。

Foundry Networks ----- Trunk Link、Link Aggregation
Extreme Networks ----- Load-Sharing、Link Aggregation
Cisco Systems -------- EtherChannel、Link-Bunlding(CRS-1)
Enterasys Networks --- Trunk、Link Aggregation
アライドテレシス ----- ポートトランキング
アラクサラ ----------- リンクアグリゲーション
日立電線 ------------- Link Aggregation


一昔前は、ポート(リンク)を束ねることを、Trunking(トランキング)と呼ぶのが一般的でした。
Trunk は、「幹」という意味の英単語で、複数のポートを束ねて太いリンクを提供する機能の名称としては妥当です。

しかし、IEEE 802.1Q で、複数VLAN を束ねるポートのことをTrunk Port と呼ぶようになると、面倒な事になりました。
単にTrunk といっても、ポートを束ねる機能のことなのか、VLAN を束ねたポートのことなのか分かりません。

2000年にIEEE 802.3ad が公開され、Link Aggregation (リンク集約) という言葉が徐々に広まりつつあります。


IEEE 802.3ad では、ルータ・スイッチ同士で情報を交換することで、自動的にLink Aggregation を実現するためのプロトコルも定義されています。
LACP (Link Aggregation Control Protocol) です。

以前は、メーカ毎に独自のプロトコルが存在し、メーカ間の互換性はありませんでしたが、
最近はLACP を実装している機器も増え、異なるメーカ同士でLink Aggregation が実現可能になりました。

これまでCisco では、PAgP (Port Aggregation Protocol) という独自プロトコルを用いていましたが、最上位機種であるCRS-1 では、PAgP を実装しておらず、LACP のみをサポートしています。

世の中の流れは、着実にLACP に向いて流れているようです。

ip subnet-zero - 何のために存在するのか?

ip subnet-zero …… ほとんどすべてのCisco ルータ、Catalyst に設定されています。
ルータを初期化しても必ず入っているこの設定。
気にはなっても、あえて触れなかった人も多いのではないでしょうか。

Router#sh run
Building configuration...

Current configuration : 497 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router
!
!
clock timezone PST -8
ip subnet-zero
no ip domain lookup
!


クラスという枠の存在により、IP のアドレッシングが今よりもっと自由度が低かったころに話はさかのぼります。

インターネットに接続するためには、IP アドレスが必要になります。
割り当てられたアドレスブロックをそのまま使うのではなく、大抵の場合、複数のサブネットに分割して、ルータによりそれらのサブネットを束ねます。


ここに、220.220.220.0 というクラスC のネットワークアドレスを取得した企業があると仮定します。

8ビットあるホスト部から3ビット借りてくると、次の八つのサブネットができます。

220.220.220.000(000-00000)※
220.220.220.032(001-00000)
220.220.220.064(010-00000)
220.220.220.096(011-00000)
220.220.220.128(100-00000)
220.220.220.160(101-00000)
220.220.220.192(110-00000)
220.220.220.224(111-00000)

※ 括弧の中は2進数

1行目のサブネット番号は0 なので、このネットワークは220.220.220.0 になります。

サブネット分割するまえのクラスC ネットワークと同じですよね。
220.220.220.0 と書いても、本来のクラスC なのか、サブネットなのか区別ができません。

ルータの実装によっては、この「区別できない」ことが致命的になる場合もあります。
そのため、サブネット番号がゼロとなるようなサブネットは使わないことが推奨されていました(RFC 950)。

Cisco のIOS でも、従来は、サブネット番号がゼロとなるようなIP アドレスは設定ができませんでした。

Router(config)#interface ethernet 0/0
Router(config-if)#
Router(config-if)#ip address 220.220.220.1 255.255.255.224
Bad mask /27 for address 220.220.220.1
Router(config-if)#

しかし、この制限はあくまで推奨に基づくもので、禁止事項ではありません。

そのような状況を踏まえてCisco は、ip subnet-zeroというコマンドを導入しました。
ip subnet-zero" を設定すると、サブネット番号がゼロとなるアドレスも設定可能となります。

Router(config)#ip subnet-zero
Router(config)#
Router(config)#interface ethernet 0/0
Router(config-if)#ip address 220.220.220.1 255.255.255.224
Router(config-if)#

IOS Version 12.0 からは、ip subnet-zero がデフォルトで有効になっています。

もちろん、no ip subnet-zero を設定することで、無効にすることもできます。

CDP - 存在を主張する

CDP (Cisco Discovery Protocol) は、その名の通り、Cisco により開発された独自プロトコルです。
ルータやスイッチでCDP を有効にすると、各インターフェイスから60秒に一回、CDP フレームが送信して、自分の存在を対向機器に通知します。

対向機器からのCDP フレームを受信すると、フレームから得た情報は、CDP Neighbor Table と呼ばれるデータベースに格納されます。

CDP は、ポートのDuplex 設定や、VLAN の設定情報を運ぶことができます(後述)。
ルータやスイッチは、受信したCDP フレームの内容を確認することで対向機器との設定の食い違いを知り、エラーメッセージを出力して管理者へ通知することもできます。

CDP は、機器全体でEnable/Disable を選択できるほか、インターフェイス単位でもEnable/Disable することができます。

Catalyst へのCisco 製IP Phone 接続や、Layer2 Traceroute の利用など、CDP の使用が必須とされる場合もあります。

先述の通りCDP はCisco 独自のプロトコルであり、他社の類似プロトコルとの互換性はありません。
しかし、鳥取三洋電機のIP Phone など、Cisco からライセンス供与されているメーカも一部存在します。


Cisco.com (CCO) レビューについて

Cisco IOS を稼働している Cisco ルータとスイッチでの Cisco Discovery Protocol の設定 (ライター翻訳)

Configuring Cisco Discovery Protocol on Cisco Routers and Switches Running Cisco IOS (英文)


Router#show cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
Sending CDPv2 advertisements is enabled
Router#

holdtime は、Neighbor Table の情報を保持する時間です。
CDP フレームを受信すると、HoldTime タイマーがカウントダウンを始めます。180 秒が経過すると、その情報はNeighbor Table から削除されます。
同じ機器からCDP フレームを受信するとタイマーは初期化されるので、CDP フレームを受信し続けている間は、情報は保持され続けることになります。

従来のCDP(Version 1)では、IOS のVersion やインターフェイス、IP アドレスなどの基本情報しか通知することができませんでした。
CDP Version 2 では、インターフェイスに設定されたNative VLAN や、IP Phone の情報を扱えるような拡張がなされています。

Router#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater

Device ID Local Intrfce Holdtme Capability Platform Port ID
R2-AGS Ser 1 129 R 2500 Ser 0
R6-2500 Eth 0 144 R 4000 Eth 0
Router#

Device ID -------- 対向機器のHostname
Local Intrfce ---- 対向機器と接続している、自分のインターフェイス
Holdtme ---------- Hold Time タイマー
Capability ------- 対向機器の種別(Capability Codes を参照)
Platform --------- 対向機器の機種
Port ID ---------- 対向機器のインターフェイス

NAT - IP アドレスを変換する

インターネットの利用が、商用が主目的となっていく過渡期に大きな問題となったのは、「急速に拡大するネットワークでいかに効率よくデータを送り届けるか」と「限られたIP アドレス空間をいかにやりくりするか」の二点でした。

前者は、クラス分割という、必ずしも効率的とはいえない方式を利用していたIPv4 に、クラスの枠を取り払ったCIDR (サイダー: Classless Inter Domain Routing) を導入することで乗り越えました。

後者を解決したのが、NAT(ナット: Network Address Translation ※)です。

※ NAT について説明された最も初期の資料の一つであるRFC1631 では、Network Address Translator とありますが、一般的にNetwork Address Translation と呼ばれることが多いです。

NAT は、ルータやファイアウォール機器に実装され、ネットワークを内部と外部に分割します。
内部ネットワークから外部ネットワークへ向けて送信されるデータは、NAT ルータにより中継されます。












内部ネットワークから外部ネットワークへ送信されるパケットは、NAT ルータによって中継される際に、送信元IP アドレスや送信元TCP/UDP ポート番号が変換されて宛先へ送られます。

外部ネットワークから戻ってきたパケットは、NAT ルータにより宛先IP アドレスや宛先TCP/UDP ポート番号が確認され、対応する内部ネットワークの宛先に変換されます。

IP アドレスは、ネットワーク上の位置情報であると同時に、ID(識別子)でもあります。
ID である以上、インターネット上に存在するIP アドレスは、すべてが一意である必要があります。重複は許されません。
しかし、インターネット上のすべてのノードに一意のIP アドレスを割り当てるには、数が足りません(※)

※ 1990年代初頭、私が所属していた会社では、クラスB のグローバルアドレスが、すべてのPC に割り当てられていました。

NAT により外部と内部に分割することで、内部ネットワークを、外部(インターネット)のアドレッシングから独立させることを可能にします。
独立させることで、外部ネットワークへ影響を与えることなく、内部ネットワークを自由に拡張することが可能となります。



Cisco.com (CCO) レビューについて

NAT の動作の仕組み(ライター翻訳)

How NAT Works (英文)



NAT の基本的な動作について説明した技術資料です。
ルータの具体的な設定方法については触れられておらず、メーカに依存しない、NAT の仕組みを勉強するには良い資料ですね。

ただ、「内部」「外部」「グローバル」「プライベート」といった用語が、正確に定義されることなく乱用されており(※)、非常に読みづらくなっているのが難点です。

※ 一応「NAT:ローカルおよびグローバルの定義」という別な資料へのリンクが提示されていますが、こちらも非常に読みづらく、一読しただけでは理解できそうもありません。

■ 用語の定義

「外部」「グローバル」は、NAT ルータを境にして、インターネットに向け公開されている側を指します。
「内部」「プライベート」は、インターネット側から直接アクセスできない側を指します。

背景知識

NAT の役割を、企業の受付にたとえて説明しています。
これは、Cisco の技術資料にしては珍しく、秀逸な説明ですね。
企業の受付にたとえることで、NAT の役割を、容易に理解することができます。

続いて、NAT の実現方法を図付きで説明していますが、NAT の動作と利用方法が同列に説明されており、少し混乱します。

最初の三つ、「スタティック NAT」「ダイナミック NAT」「オーバーロード」は、NAT の動作を説明するものですが、最後の「オーバーラップ」は、NAT の利用方法について述べています(※)。

※ インターネット上に存在するIP アドレスを、内部ネットワークでも用いる場合の実現方法の例として、スタティックNAT を挙げています。

内部ネットワークは通常は Local Area Network(LAN; ローカルエリア ネットワーク)であり、これは普通スタブ ドメインと呼ばれます。スタブ ドメインは IP アドレスを内部的に使用する LAN です。

突然スタブという言葉が出てきました。一応説明はしてありますが、イメージしづらいですね。
スタブ(Stub) とは、本来「切り株」「切れ端」という意味の英単語です。
ネットワークでは、中継点ではない物に使われる言葉です(※)。
つまり、スタブドメインは、ISP のように様々なユーザのデータを中継するのではなく、ISP から受け取ったデータを他のISP やユーザに中継する必要が無い、企業や自宅のネットワークを指します。

※ OSPF のスタブエリアなど

次の例では、NAT ルータは、プライベート(内部)ネットワークに存在する未登録 IP アドレス(内部ローカル アドレス)を登録済み IP アドレスに変換するよう設定されています。

「未登録IP アドレス」とは、内部ネットワークで使われているIP アドレスを指します。それに対して「登録済みIP アドレス」とは、このスタブドメインが、インターネットに対して公開しているIP アドレスです。







スタブ ドメイン上にあるほとんどのコンピュータは、内部ローカル アドレスを使用して互いに通信します。

インターネットの普及、B2B、B2C の一般化により、この前提条件は過去のものとなりました。

スタブ ドメイン上のコンピュータの中には、主にネットワークの外部と通信するものがあります。このコンピュータには、変換が不要であることを意味する内部グローバル アドレスがあります。

この例は、DMZ(ディミリタライズドゾーン: DeMilitarized Zone) に設置されたWWW サーバなどを指しているのでしょうか?
DMZ にグローバルアドレスを用いるのは間違いではありませんが、あまりお勧めできる構成ではありません。

NAT ルータはルーティング テーブルをチェックして、宛先アドレスのエントリがあるかどうかを確認します。宛先アドレスがルーティング テーブルに登録されていない場合、パケットは廃棄(ドロップ)されます。

アドレスの変換処理を行う前に、ルーティングテーブルが参照されることを説明しています。

ルーティングテーブルに、宛先へ到達するための経路が存在しなければ、そもそもアドレス変換を行う理由がありませんので、破棄されます。
ルーティングを主目的として設計されたコンピュータであるルータにとって、アドレス変換よりも、ルーティングテーブルを参照する処理の方が、負荷が低くなります。
この順番は妥当でしょう。

ルータは内部グローバル アドレスを使用して、パケットを宛先に送信します。

NAT ルータは、パケットの送信元IP アドレスを、内部グローバルアドレスに変換して、外部へ中継します。

パブリック ネットワーク上のコンピュータはプライベート ネットワークにパケットを送信します。 パケットの送信元アドレスは、外部グローバル アドレスです。 宛先アドレスは、内部グローバル アドレスです。

返信されてきたパケットの宛先IP アドレスは、先ほどNAT ルータが変換した、内部グローバルアドレスになります。

パケットが外部ネットワークに着信する場合、NAT ルータはアドレス変換テーブルを検索して、テーブルに宛先アドレスがあるかどうかを特定し、そのアドレスをスタブ ドメイン上のコンピュータにマッピングします。

返信されてきたパケットが、NAT ルータの外部インターフェイスで受信された時の動作を説明しています。

NAT ルータは、パケットの内部グローバル アドレスを内部ローカル アドレスに変換し、ルーティング テーブルをチェックした後、パケットを送信先コンピュータに送信します。

パケットを外部へ中継した時とは逆の動作になります。
宛先IP アドレスを内部向けに変換した後でないと、ルーティングテーブルを参照できないからです。

NAT オーバーロードでは、TCP/IP プロトコル スタックの一機能である多重化を利用します。

ここで言う多重化とは、TCP/UDP のポート番号を使うことで、一つのIP アドレスの上で、複数のセッションを識別できることを意味します。

ダイナミック NAT とオーバーロードの例

残念ながら、Flash アニメへのリンクが切れているようです。
Flash アニメを見る場合は、原文を参照しましょう。

内部ネットワーク(スタブ ドメイン)に設定されている IP アドレスは、Internet Assigned Numbers Authority(IANA)(IP アドレスを分配する世界的な機関)によってその会社専用に割り当てられたアドレスではありません。これらのアドレスは一意でないため、ルーティング不能と見なされます。

ルーティング不能なのは、一意ではないからではなく、外部ネットワークに存在しない経路だからです。
内部ネットワークの中では、ルーティングテーブルに経路が登録されていれば、そのようなアドレスでもルーティング可能です。

ダイナミックNAT とスタティックNAT の間に、基本的な動作の違いはありません。
内部ローカル/内部グローバルアドレスの関連付け(マッピング)が、ダイナミックの場合は、そのときにあいているアドレスとの間で行われるのに対して、スタティックの場合は事前の設定が必要となるくらいです。


オーバーロードは、内部から外部へのアクセス要求に対して、割り当て可能な内部グローバルアドレスの数が不足している場合に有効です。
内部グローバルアドレスがひとつしかない場合、この方法を使います。
この場合、内部グローバルアドレスは、NAT ルータのインターネット側インターフェイスに設定されたIP アドレスになります。

ルータは送信元コンピュータの送信元ポートを、アドレス変換テーブル内の、送信元コンピュータのアドレス情報を保存した場所と一致するポート番号に置き換えます。

ひとつしかない送信元IP アドレスでは、内部ネットワークの複数の端末を識別することができませんので、TCP/UDP のポート番号を使用します。
NAT ルータは、外部へ中継するパケットの送信元ポート番号を変換し、ポート番号を、その端末に割り当てます。
外部から戻ってきたパケットの宛先ポート番号は、このポート番号になりますので、NAT ルータは、どの端末宛のパケットなのかを識別することができます。

アドレス変換テーブルの標準的なエントリのサイズはおよそ 160 バイトであるため、4 MB の DRAM を搭載したルータであれば、理論的には 26,214 の同時変換が可能です。これはほとんどのアプリケーションにとって十分な数です。

DRAM が、すべてNAT 用に使われるわけではない点に注意してください。


マルチホーミング

ルータは Border Gateway Protocol(BGP; ボーダーゲートウェイ プロトコル)(TCP/IP プロトコル群の一部)を使用して、異なるプロトコルを使用するネットワーク間のルーティングを行います。マルチホーム ネットワークでは、ルータはスタブ ドメイン側で Internal Border Gateway Protocol(IBGP)を使用し、他のルータとの通信には External Border Gateway Protocol(EBGP)を使用します。

これは訳もおかしいですが、原文も正しく説明できていません。

マルチホーミングとは、スタブドメインから外部へ接続するための出口(NAT ルータ)が複数存在する環境を指します。

NAT ルータが外部から経路情報を受け取るための手段としてEBGP を使います。
これに対してIBGP は、スタブドメイン内で、複数のNAT ルータが、経路情報の同期を取るための手段として用いられます。



ACL - 指定したパケットの送受信を許可・拒否する

ACL(Access Control List) は、主に、ルータやスイッチを通過するトラフィックを制御するために用いられます。
アドレスなどのヘッダー情報に基づいて、通過を許可、又は禁止します。

Cisco のIOS では、IP だけではなく、IPX、DECnet、XNS・・・といった様々なプロトコルのパケットをACL で制御することができます。



Cisco.com (CCO) レビューについて

■ レビュー対象

一般的に使用される IP ACL の設定(ライター翻訳)

Configuring Commonly Used IP ACLs (英文)


ACL (Access Control List) の設定方法を説明する技術資料です。
Cisco のIOS では、IPX、DECnet、XNS など、様々なプロトコルのパケットを制御することができますが、この資料ではIP を対象にしています。

IP 用のACL には、Standard IP ACL とExtended IP ACL の二種類があります。

※この資料では、画像(ネットワーク図)の表示がおかしくなっています。図は、自動翻訳か原文を参照しましょう。

選択したホストによるネットワーク アクセスの許可

この例では、IP Standard ACL を使って、もっとも基本的なトラフィック制御を行っています。
Ethernet0 で受信されるIP パケットの内、送信元アドレスが192.168.10.1 の場合のみ受信可能で、それ以外はすべて破棄されます。

ACL は、その名の通り、一つ以上の制御文で構成されるリストです。
受信したパケットは、ACL に合致するかどうか、上から順番に確認されます。
合致する行が見つかると、確認作業はそこで終了し、ACL の設定にしたがって、パケットはpermit 又はdeny されます。

表示はされていませんが、リストの最後には「暗黙のdeny all (implicit deny all) と呼ばれる、すべてのパケットを破棄するACL が存在します。
設定したACL にヒットしない場合、この「暗黙のdeny all」が適用され、パケットは破棄されます。

この例で、送信元アドレスが192.168.10.1 ではないパケットがすべて破棄されるのは、この「暗黙のdeny all」が適用されるためです。

選択したホストによるネットワーク アクセスの拒否

先の例とは逆に、この例では、送信元アドレスが192.168.10.1 の場合は破棄、それ以外のパケットはすべて受信を許可しています。

「暗黙のdeny all」による破棄を防ぐため、access-list 1 deny host 192.168.10.1 の次に、すべてのパケットを受信可能にするaccess-list 1 permit any を設定しています。

連続した IP アドレスの範囲へのアクセスの許可

先の二つの例では、IP Standard ACL を使っていましたが、この例では、IP Extended ACL を用いています。
ACL の設定で、access-list の次にある番号は、ACL に割り当てるID(アクセスリスト番号)です。
アクセスリスト番号が1〜99、1300〜1999 の場合はStandard、100〜199、2000〜2699 の場合はExtended ACL です。

Telnet トラフィックの拒否(TCP、ポート 23)

これまでの例は、送信元/宛先アドレスを条件にACL を設定していましたが、この例では、TCP のポート番号を条件しています。

Ethernet0 で受信するIP パケットの内、TCP 宛先ポート番号が23 (Telnet) の場合は破棄され、それ以外はすべて受信されます。

今回の例では宛先ポート番号を条件としましたが、送信元ポート番号を用いる場合は、access-list 102 deny tcp any eq 23 any とします。

内部ネットワークだけによる TCP セッション開始の許可

この例では、TCP の宛先ポート番号が1023 以上、且つ、すでにTCP コネクションが確立されている場合のみ受信可能となっています。

established が設定されていると、TCP ヘッダーのACK もしくはRSTフラグが立っている場合(すでにコネクションが確立していることを意味する)のみ合致します。

FTP トラフィックの拒否(TCP、ポート 21)

ACL でTCP やUDL の送信元/宛先ポートを指定する際、ほとんどのWell-Known ポートは、番号ではなく名前で指定することができます。
この例では、FTP (Control = 21、Data = 20) を名前で指定しています。

※ この翻訳文では、二行のACL がつながって表示されてしまっています。正しいACL 表記は原文を参照しましょう。

ルーティング更新の許可

ACL をインターフェイスに適用すると、「暗黙のdeny all」によって、RIP やOSPF などのルーティングプロトコルのアップデートも受け取れなくなってしまうので、注意してください。

ACL に基づくトラフィックのデバッグ

ACL は、パケットの送受信をpermit/deny するだけではなく、特定のパケットを捕らえるための手段としても用いられます。

この例では、以下の条件に合致するIP パケットを受信すると、debug ip packet 199 detail で、パケットの内容をコンソールに表示させています。

10.1.1.1 から172.16.1.1 宛のTCP パケット
もしくは
172.16.1.1 から10.1.1.1 宛のTCP パケット


このほかにも、特定のパケットを、QoS 機能によりCOS/TOS の値を書き換えることなどにも、ACL は利用されます。

ErrDisable - 不具合を検知したポートを閉塞する

Cisco のCatalyst は、不具合を検知したポートを、ErrDisable(エラーディセイブル) という状態にすることで、不具合箇所を局所化する機能を持っています。

ErrDisable となったポートは、shutdown (CatOS の場合はdisable) と同様の扱いとなります。

ポートをErrDisable にする条件(不具合の種類)は、機種やOS の種類(IOS/CatOS)、Version によって異なります。
以下に、代表的な条件をリストします。

UDLD (Unidirectional Link Detection)
BPDU-Guard (STP)
RootーGuard (STP)
Channel Config Mismatch
Link Flap
Loopback Detection
Broadcast Supression

どの条件がサポートされているか確認するには、次のshow コマンドを使います。

IOS
show errdisable detact cause

CatOS
show errdisable-timeout

ErrDisable は、不具合を回避するための措置であって、それ自体は不具合ではありません。
問題を解決するには、ポートをno shutdown (CatOS の場合はset port enable) とする前に、ErrDisable となった原因を追及する必要があります。

※IOS において、ErrDisable となったインターフェイスを復旧させるには、一度手動でshutdown をした上で、no shutdown する必要があります。

「shutdown と同等」と書きましたが、ErrDisable がshutdown と異なる点は、自動的に復旧させる手段があることです。

次のコマンドで秒数を設定すると、ErrDisable となったポートは、一定秒数が経過すると自動的に復旧します。

IOS
errdisable recovery interval

CatOS
set errdisable-timeout interval

IOS の場合、errdisable detect cause コマンドで、ErrDisable とする条件を、個別にenable/disable することができます。


Cisco.com (CCO) レビューについて

■ レビュー対象

CatOS プラットフォームでの errDisable ポート状態からの復旧 (ライター翻訳)


Recovering From errDisable Port State on the CatOS Platforms (英文)



ErrDisable となったポートを復旧せさせる方法を説明した技術資料です。
CatOS で動作しているCatalyst が対象となっています。

エラー ディセーブル状態になっているポートは、根本原因が検出されて解決される限り、それ自体がアラームの原因にはならないことを覚えておいてください。 エラー ディセーブル状態のポートは、解決する必要があるもっと深刻な問題があることを示しています。

ErrDisable 自体が不具合では無いことを説明しています。
ポートをErrDisable から復旧できたとしても、根本原因を取り除かない限り、問題は解決されません。

set option errport という新しいコマンドが CatOS に追加されました。このコマンドを使うと、このような特殊なコリジョン エラーが起きているポートの検出でスイッチが実行するアクションを管理者が決定できます。

CatOS version 6.x で確認したところ、set option errport コマンドはすでになくなっているようですので、本レビューでは触れません。

上記メッセージでは、errDisable またはエラー ディセーブル状態であることが明確には示されていません。しかし、これらのメッセージでは、スイッチによってポートがディセーブルにされたことが確かに示されています。

ErrDisable となった時に表示されるメッセージは、ErrDisable と明記してない場合があります。show interface status (IOS)、show port (CatOS) などのコマンドを使って確認する必要があります。

これらの状況を修正するには、根本にある問題に対処してからポートを再度イネーブルにする必要があります。 これは接続が正しくないポートであるため(PortFast がイネーブルで別のスイッチに接続されている)、PortFast 機能をオフにします。 繰り返しますが、PortFast は端末に接続されたポートでだけ使用することを想定しています。

この対策は根本的に間違っています。
BPDU-Guard は、Spanning Tree を理解する機器(= BPDU をしゃべる機器・・・スイッチやブリッジ)がそのポートの配下に存在することを禁止する機能で、PortFast を設定したポートでのみ使用可能です。

このポートがErrDisable となったのは、BPDU を受信したからです。
そもそも禁止していたことを行ったためにErrDisable となったわけですから(管理ポリシー違反)、ここですべき対策は、「ポリシーを変えること = PortFast を辞める」ではなく、BPDU を送信する機器を特定して取り除くことです。


あるスイッチを EtherChannel に設定して別のスイッチを EtherChannel に設定しないと、スパニング ツリー プロセスを引き起こして EtherChannel に設定した側のチャネル ポートをシャットダウンします。

Channel Config Mismatch 発生時の状況を説明しています。
Channel Config Mismatch については、以下のリンクで詳しく説明しています。

EtherChannel - 複数のリンクを束ねる


EtherChannel を ON モードにしても、チャネリングの前にもう一方のサイドとネゴシエートするための PAgP パケットは送信されません。

「ON モードにしても」ではなく「ON モードにすると」です。

Channel Config Mismatch の検出は、BPDU を利用して行います。
Spanning Tree をDisable にしているCatalyst では、Channel Config Mismatch が発生しても検出されず、ポートもErrDisable にはならない点に注意してください。

EtherChannel - 複数のリンクを束ねる

Cisco のCatalyst シリーズでは、Ethernet ポートを束ねる機能(Link Aggregation) をEtherChannel (イーサーチャネル) と呼んでいます。

この名称は、Kalpana (現在はCisco)により1996年に商標登録されたものです。
Kalpana は、LAN スイッチの黎明期に誕生したメーカで、Ethernet ポートに初めてFull Duplex 機能を実装した会社でもあります。

通信機器市場に占めるCisco のシェアから、Ethernet ポートを束ねる事をChanneling(チャネリング)と呼ぶのが一般的です。
しかし、ポート(リンク)を束ねる事をチャネルと呼ぶのは、実際にはCisco くらいで、メーカ毎に様々な呼び方があります。

Foundry Networks ----- Trunk Link、Link Aggregation
Extreme Networks ----- Load-Sharing、Link Aggregation
Cisco Systems -------- EtherChannel、Link-Bunlding(CRS-1)
Enterasys Networks --- Trunk、Link Aggregation
アライドテレシス ----- ポートトランキング
アラクサラ ----------- リンクアグリゲーション
日立電線 ------------- Link Aggregation


一昔前は、ポート(リンク)を束ねることを、Trunking(トランキング)と呼ぶのが一般的でした。
Trunk は、「幹」という意味の英単語で、複数のポートを束ねて太いリンクを提供する機能の名称としては妥当です。

しかし、IEEE 802.1Q で、複数VLAN を束ねるポートのことをTrunk Port と呼ぶようになると、面倒な事になりました。
単にTrunk といっても、ポートを束ねる機能のことなのか、VLAN を束ねたポートのことなのか分かりません。

2000年にIEEE 802.3ad が公開され、Link Aggregation (リンク集約) という言葉が徐々に広まりつつあります。


IEEE 802.3ad では、ルータ・スイッチ同士で情報を交換することで、自動的にLink Aggregation を実現するためのプロトコルも定義されています。
LACP (Link Aggregation Control Protocol) です。

以前は、メーカ毎に独自のプロトコルが存在し、メーカ間の互換性はありませんでしたが、
最近はLACP を実装している機器も増え、異なるメーカ同士でLink Aggregation が実現可能になりました。

これまでCisco では、PAgP (Port Aggregation Protocol) という独自プロトコルを用いていましたが、最上位機種であるCRS-1 では、PAgP を実装しておらず、LACP のみをサポートしています。

世の中の流れは、着実にLACP に向いて流れているようです。

Cisco.com (CCO) レビューについて

Cisco.com (CCO) では、多くの技術資料が公開されており、日本語に翻訳されたものも多くあります。
しかし、翻訳の質は高いとは言えず、意味の通らない表現が多々見られるのも事実です。

本サイトのCisco.com (CCO) レビューは、日本語化されたCisco.com ドキュメントを補足することを目的とします。

Cisco.com の日本語翻訳は以下の2種類に分けられます。

ライター翻訳 人の手により翻訳されたもの
自動翻訳 コンピュータによる機械翻訳

本サイトでは、主に、ライター翻訳の技術文書を対象にレビューを行います。
ライター翻訳が存在しない技術文書については、自動翻訳を対象とすることもあります。その場合は、いつの時点での自動翻訳なのかを明記します。
(自動翻訳は、システムの更新により精度が変わる可能性があるため)

本文中、バックグラウンドがグレーとなっている文は、Cisco.com 技術資料からの引用であることを意味します。

Cisco.com (CCO) ユーザ登録ナビ

ウェブ上の登録画面では、ちょっとした入力ミスで最初からやり直しをさせられるなど、イライラさせられることが多いものです。
特に英語を機械翻訳したような登録画面では、意味不明な説明文や、肝心な部分が英語のままで、日本の実情に合っていない場合もあります。

Cisco.com (CCO) も例外ではなく、登録を完了するだけで、気が付いたら数十分経っていたということもあります。

迷わず最短時間で登録できるよう、ナビを作成してみました。

Cisco Systems, Inc (日本語)

1) 画面上の「ユーザ登録」をクリックします。

お客様の情報

項目
言語の選択 ここで選択する言語は、ユーザ登録画面の表示言語です
姓、名 半角英数のみ有効です
メールアドレス Cisco からの通知を受信するアドレスを入力してください
希望する言語 今後Cisco から受け取るメール等に使われる言語です

ログイン名

項目
ユーザーID 登録したいユーザーID を半角英数字で入力します
パスワード パスワードを入力します
パスワードの指針を、「アカウント保護の手引き(英文)」から抜粋しました

1) 大文字、小文字の両方を含むこと
2) 数字、句点等の記号を含むこと
3) 5文字以上にすること
4) 一般的な単語、方言、専門用語は避けること
5) 個人情報を含まないこと

その他のアカウントへのご登録

以下の条件に該当する人はチェックを入れてください。

シスコ代理店の社員、サポート契約がある人
シスコ代理店の社員だが、契約番号が分からない人
シスコから直接製品を購入した人(日本では適用外)
シスコ代理店から紹介され、PICA プログラムに加盟している人
CCIE ホルダー

Cisco からの、各種案内送付の可否を指定します。

電子メール
郵送
電話
ファックス

電子メールの形式を指定します。

テキスト 又はHTML

シスコ代理店からの各種案内送付の可否を指定します。

シスコのPrivacy Statement を承諾して、「送信」ボタンをクリックします。



登録者の情報を入力します

ご勤務先 / ご住所


個人登録の場合は「ご自宅の住所」を選択して下さい

項目
会社・団体名 「ご自宅の住所」を選択した場合は空欄
住所1 2-14-27
住所2 Akasaka
区・市 Minato-ku
都道府県 Tokyo
郵便番号 107-0052
(ハイフン有り無しどちらでも可)
Japan

上記例はシスコシステムズ株式会社の住所を使用しています。
郵便番号は、入力した住所に対応する番号を正しく指定しないと先に進めません。
事業所個別番号(事業所に割り当てられた郵便番号)は受け付けられない場合があります。その場合は、所在地の郵便番号を使って登録してください。
指定した郵便番号が正しくない場合に表示される「ヘルプドキュメント」(英文)は、日本については触れられていません。


追加情報(必須)

項目
国別コード 81(日本)
電話番号 内線は空欄でも問題ありません
職種 重複や、職種ではなく業種と思われるような選択肢もありますが、適当に選んでも問題ありません。

「送信」ボタンをクリックします



勤務先に関する情報を入力します。
画面下の「このステップを省略する」をクリックすると、このページをスキップすることができます。

「このステップを省略する」か、勤務先情報を入力して「送信」をクリックすると、Cisco からメールが送られてきます



Cisco から送られてきたメールの本文内のURL をクリックして、「登録完了」画面が出ると、登録作業が完了です。



Cisco.com (CCO) へのログイン


画面上の「ログイン」をクリックします。
登録したユーザー名、パスワードを入力してログインします。
先ほどクリックした「ログイン」が「ログイン済」となればログイン成功です。
登録した内容は、Cisco.com Profile Manager で変更可能です。

モジュールが抜けない!!(2)

オフィスが移転することになりました。

情報システム部門の仕事は山のようにあります。

ケーブルの配線
PC・電話機の設置
マシンルームの確保
業者の手配

ユーザ部門の要求が固まって、移転計画を確定させないと取り掛かれません。
システム部門の要求はいつも後回しにされがちです。

移転日までの多忙な日々を過ごす中で、おざなりにされがちなのが、ルータやスイッチといったネットワーク機器の移設です。
PC や電話機のように台数も多くないので、つい後回しにしてしまい、結局、当日になって適当な箱と梱包剤を見つけてきました。

新しい設置場所へ到着し、スイッチをラックに収め、電源を入れます。

立ち上がりません。

何が悪いのでしょう?
トラブルシューティングを始めます。

ラインカードを全部抜き、スーパーバイザーエンジンだけにして起動してみましょう。

!!ラインカードが抜けない!!

立て付けが悪くなってしまっています。シャーシが歪んでしまったようです。

こうなってしまっては、丸ごと交換するしかなさそうです。
でも、このような場合、サポート契約を結んでいても、メーカはなかなか無償交換には応じてくれません。


ネットワーク機器の箱や梱包剤を保管しておくのは、場所の無駄ですし、現実的ではありません。
移転が決まったら、まずはメーカか、購入元に相談してみることをお勧めします。
有償の場合もあるかもしれませんが、正規の箱を手配してもらえるかもしれません。

あと一点。

移動する際は、モジュール類は全部抜いた状態で行いましょう。
立て付けが悪くなって抜けなくなると、シャーシだけでなく丸ごと交換するしかなくなってしまいます。

期待される動作です

最近サーバに繋がらない事が多いんだよね。

ユーザ部門からのクレームを受けて調査した所、ルータがおかしなパケットを送信しているのを発見しました。

メーカーに問い合わせると、

「現在のバージョンでは期待される動作です。次のバージョンでは変更される予定です」
という回答でした。

期待される動作??

仕様通りというのは分かったけど、誰も期待なんかしてねーよ!

PC のメールソフトに向かって、一人突っ込みました。


明らかにおかしい動作をしていても、そのバージョンにおける(イケテない)仕様、という事はあります。
そもそも、そのバージョンが作成された時点では、そのような状況は想定されていなかったのでしょう。

そういう場合、メーカはなかなか不具合とは認めません。
そして、「期待される動作」という回答となります。

しかし、誰もそんな動作など期待していません。もちろんメーカも。

語源は、英語のexpected behavior のようです。
直訳すると、「予期される振る舞い」でしょうか。

「想定される動作」「ありえる事象」程度の表現が妥当ではないでしょうか。


みなさんはどう思われますか?

モジュールが抜けない!!

故障したモジュールの代替品が到着しました。
交換作業は週末の予定です。

問題のスイッチに収容されているユーザへ、ネットワークが一時的に使えなくなる事を通知します。

週末を迎え、作業のために出社しました。
モジュールの箱を抱えて、スイッチの設置場所へ向かいます。
スイッチの前まで来て、さあ作業を始めようという時です。

モジュールが抜けない!!

膨大な本数のケーブルが邪魔をして、モジュールが抜けないのです。

モジュールを交換するだけのはずだったので、ユーザに通知した作業時間はたったの1時間です。
ケーブルにはラベルが付いておらず、このまま抜くと元に戻せなくなります。
休日とは言えネットワークは動いており、勝手に止める事は許されません。

すべてのケーブルに仮のラベルを付けて、なんとか予定時間内に作業を終えましたが、疲れ果ててしまいました。

でも、これで終わりではありません。
月曜日の朝、みんなが出社してくると、

サーバーにつながらない!

メールが読めないよ!

ユーザ部門からのクレームの嵐です。
どうやら、焦ってつなぎ間違いをしてしまったようです。

今晩、緊急メンテナンスをする事になりました・・・


ネットワーク機器にケーブルを接続する際の鉄則は、

モジュールに平行

です。
どんなに短距離であっても、たとえ仮配線であっても。

モジュールに対して垂直に配線してしまうと、モジュールが抜けなくなってしまいます。
モジュールに対して平行に配線されていれば、ケーブルをスロットの両脇に逃がしながら、余計なケーブルを抜く事なく作業ができま

1000BASE-TX か、1000BASE-T か

光ケーブルによる通信技術が規格化され、実装技術が確立すると、次はより安価なメタルケーブルで。
10BASE-F と10BASE-T、FDDI とCDDI、100BASE-FX と100BASE-TX・・・LAN 技術の普及は
いつもこのような流れを辿っています。

すでに普及期に入ったGigabit Ethernet も、例外ではありません。
1000BASE-T のLAN カードは二、三千円で買うことができます。
デスクトップまでギガビットという流れを受けて、小型のワークグループスイッチでも10/100/1000Mbps をサポートするのが当たり前になってきました。

メーカのサイトを見ると、1000BASE-T をTX と間違っているケースが散見されますが、
1000BASE-TX という規格は、1000BASE-T とは別に存在します(互換性もありません)。

1000BASE-TX は、IEEE802.3ab が策定される前、Lucent Technlogies が提案した技術が元になっています。
残念ながらIEEE802.3ab では採用されませんでしたが、改めてEIA/TIA に提案され、EIA/TIA-854-A として規格化されました。

IEEE802.3ab(1000BASE-T) では、UTP ケーブルの4ペアすべてで送受信処理を行います(1ペア = 250Mbps)。
各ペアの両端にはハイブリッド回路が置かれ、送受信信号の分離を行う必要があります。4ペア間の同期を取るための処理も要求され、実装コストを押し上げる要因になっています。

          +--- TX/RX ---- <-- 250Mbps --> ---- TX/RX ---+
+--- TX/RX ---- <-- 250Mbps --> ---- TX/RX ---+
<<---+ +--->>
+--- TX/RX ---- <-- 250Mbps --> ---- TX/RX ---+
+--- TX/RX ---- <-- 250Mbps --> ---- TX/RX ---+

これに対してEIA/TIA-854-A(1000BASE-TX) では、2ペア毎に送受信を独立して行わせる事で、信号分離やペア間の同期に要する負荷を軽減しています。
1000BASE-T と比較して、1000BASE-TX は安価に実現できることから、Cheaper Gigabit Ethernet と呼ばれることもあります。


          +--- TX --------> 500Mbps --> --------- RX ---+
+--- TX --------> 500Mbps --> --------- RX ---+
<<---+ +--->>
+--- RX ----- <-- 500Mbps <------------ TX ---+
+--- RX ----- <-- 500Mbps <------------ TX ---+

1000BASE-T はCategory5e で実現できますが、1000BASE-TX はCategory6 以上のケーブルが必要となります。
これが1000BASE-TX の普及を妨げている要因でしょうか。
普及期に入った1000BASE-T の、量産効果によるコストダウンも大きな要因となっているようです。

no ip domain-lookup - いちいち確認するのはやめてくれ

ああっ、やってもーた!

タイプミスをした事はない、そんな人はおそらく居ないと思います。

通常のOS では、コマンドを打ち間違えても、警告メッセージが出力されるだけですぐにプロンプトが戻ってきます。

これがCisco のIOS の場合、打ち間違ったコマンドをネームサーバへ問い合わせます。
当然そんな名前はありませんから、いつまで待っても名前は解決されません。
何度も繰り返し、一分以上経った頃、ようやくUnkown Command というメッセージと一緒にプロンプトが戻ってきます。

Router#shwo
Translating "shwo"...domain server (255.255.255.255)

Translating "shwo"...domain server (255.255.255.255)
(255.255.255.255)% Unknown command or computer name, or unable to find computer address
Router#

no ip domain-lookup を設定してやると、無駄なDNS Lookup を止める事ができます。

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#
Router(config)#no ip domain?
domain domain-list domain-lookup domain-name
Router(config)#no ip domain-lookup ?
nsap Enable IP DNS queries for CLNS NSAP addresses
source-interface Specify source interface for DNS resolver

Router(config)#no ip domain-lookup
Router(config)#^Z
Router#
Router#shwo
Translating "shwo"

Translating "shwo"
% Unknown command or computer name, or unable to find computer address
Router#

do show - 設定中にshow コマンドを実行する

「このインターフェイス、今Up してる?」

ルータを設定している最中に、show コマンドを確認したくなることだってあります。
ちょっと気になって確認したいんだけど、いちいちconfiguration mode を抜けるのも面倒です。

そんな時は、do コマンドを使いましょう。
実行したいshow コマンドの前にdo をつけてやると、Configuration Mode の中からshow コマンドを実行することができます。

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#
R3(config)#interface ethernet 0/0
R3(config-if)#
R3(config-if)#ip address 192.168.1.1 255.255.255.0
R3(config-if)#
R3(config-if)#do show interface ethernet 0/0
Ethernet0/0 is up, line protocol is up
Hardware is Lance, address is 0000.0c11.1111 (bia 0000.0c11.1111)
Internet address is 192.168.1.1/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2168 packets input, 318383 bytes, 0 no buffer
Received 1169 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
4432 packets output, 484826 bytes, 0 underruns
0 output errors, 0 collisions, 14 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Router(config-if)#



注:show interface ethernet 0/0 出力中のMAC アドレスは架空のものです。

IOS Ping を止める

先輩、Ping が止まりませんっ(涙

時にはPing を打ちっぱなしにして様子を見たいこともあります。
Windows のPing なら、-t オプションを使えば簡単に実現できる事が、なぜかIOS ではできません。
仕方ないので、回数を指定する時に、最大数の2147483647 を入力します。
(0を入力すると、指定可能な数字を教えてくれます)

Router#ping
Protocol [ip]:
Target IP address: 10.33.5.1
Repeat count [5]: 0
% A decimal number between 1 and 2147483647.
Repeat count [5]: 2147483647
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 2147483647, 100-byte ICMP Echos to 10.33.5.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

画面が! で埋め尽くされていきます。
さて、次の作業もあるのでそろそろPing を止めましょう・・・Control-C を何度押しても止まりません。

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Windows とは違うようです。

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

新人君が泣きそうな顔をしていたら、教えてあげましょう。

IOS では、Control + Shift を押しながら数字の6を押すことでPing を止めることができます。

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (268/268), round-trip min/avg/max = 8/22/60 ms
Router#

Control とShift は左右どちらも有効です。

IOS Ping 使いこなし(3) ソフトウェアかハードウェアか

Ping は通るんだけどね。

オプションフィールドがあるIP パケットはハードウェア処理されません。
このことは、「IOS Ping 使いこなし(2)」でお話ししました。

これはデメリットではありますが、視点を変えればメリットにもなり得ます。

「サーバが見えない!Ping も通らないよ」

お客様からのコールです。
切り分けの結果、パケットが途中のレイヤ3スイッチを通過できていないようだということが分かりました。

レイヤ3スイッチのルーティングテーブルを調べても異常はありません。試しにスイッチからサーバへPing を打ってみても、問題なく通ります。

そこで、件の端末から拡張Ping を打ってみると・・・通りました!

普通のPing は通らなかったのに、拡張Ping だと通ります。
なぜでしょう?何が違うのでしょう?

そうです。IP オプションです。

通常のPing ではオプションは付かず、ハードウェア処理
拡張Ping ではオプションが付き、ソフトウェア処理

どうやら問題は、レイヤ3スイッチのハードウェア処理部分にありそうです。

IOS Ping 使いこなし(2) レイヤ3スイッチにおける注意点

最近は、LAN スイッチにルーティング機能が実装されていることが当たり前になってきました。いわゆるレイヤ3スイッチです。

従来のルータがソフトウェア(CPU) で処理していたのに対し、レイヤ3スイッチは、ルーティングをハードウェア(ASIC - Application Specific Integrated Circuit) で行う事で高速な処理を可能にしています。

ASIC やFPGA(Field Programmable Gate Array) などの半導体素子製造技術の進歩によりレイヤ3スイッチは発展してきましたが、その普及は、IP の普及に拠る所が大きいと言えます。

ハードウェアにより処理をするということは、柔軟性を犠牲にするということでもあります。
従来型ルータの利点である柔軟性の高いCPU 処理から、決まった処理を高速に行うASIC へのシフト。

決められたとおりの処理を高速に行うには、処理の対象であるパケットが決まったフォーマットに則っている必要があります。
IPX、DECnet、Appletalk・・・数年前まで、LAN では様々なプロトコルが混在していました。
その中の一つでしかないIP だけを対象に高速処理を実現しても、それほどのメリットにはなりません。
受信するほとんどのパケットはIP、そんな状況が現出して初めて、レイヤ3スイッチが普及できるようになったのです。

そんなレイヤ3スイッチにも苦手なIP パケットがあります。

IPヘッダーにオプションが指定されているIP パケットです。
TTL、アドレス、TOS・・・ヘッダーには様々なフィールドがありますが、全て固定長です。
これに対してオプションフィールドは、中に入る情報次第で小さくもなれば大きくもなります。機能が拡張されれば、それまで想定していなかった情報が格納されます。

どのようなパケットがハードウェア処理可能かは、メーカにより異なります。
Cisco のCatalyst シリーズでは、以下の三つの条件に合致するIP パケットがハードウェア処理の対象となります。

レイヤ2のフォーマットがEthernet II
フラグメンテーションの必要が無いパケット
IP オプションの無いパケット

この条件に合致しない場合、IP パケットであっても全てソフトウェア処理されます。

Ping の拡張機能を使った場合も、中継ルータがCatalyst だとソフトウェア処理されてしまうので要注意です。

IOS Ping 使いこなし

Ping が通らないよ〜

ネットワークエンジニアでPing を知らない人は恐らくいないでしょう。
Ping は最も基本的なネットワーク診断ツールです。
Windows、UNIX、Mac OS・・・Ping を実装していないOS は見当たりません。ほとんどのネットワーク機器にもPing は実装されており、Cisco のIOS も例外ではありません。

Router#ping 192.168.83.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.83.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/32 ms
Router#

宛先を指定してPing を実行すると、IP の到達性(Reachability)を確認することが出来ます。

上記の例のように宛先IP アドレスだけを指定することも出来ますが、いつもはEnter を連打するだけで通過しているオプションを使うことで、よりキメの細かいテストが出来ます。

Router#ping
Protocol [ip]:
Target IP address: 10.33.5.1
Repeat count [5]: 10
Datagram size [100]: 500
Timeout in seconds [2]: 1
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]: 2
Set DF bit in IP header? [no]: yes
Validate reply data? [no]: no
Data pattern [0xABCD]:

オプションを入力していくと、次の選択肢が現れます。

Loose, Strict, Record, Timestamp, Verbose[none]:

ここでは、IP ヘッダーのオプションフィールドを使った拡張機能を指定します。

Loose オプションを使うと、宛先へ到達するまでの経路を指定することが出来ます。
指定された経路が不通の場合、代替経路を探してくれます。
Windows のPing で指定する-j オプションと同等です。

Loose, Strict, Record, Timestamp, Verbose[none]: Loose
Source route: 192.168.12.67 192.168.83.1
Loose, Strict, Record, Timestamp, Verbose[LV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.5.1, timeout is 2 seconds:
Packet has IP options: Total option bytes= 11, padded length=12
Loose source route: <*>
(192.168.12.67)
(192.168.83.1)

Reply to request 0 (88 ms). Received packet has options
Total option bytes= 12, padded length=12
Loose source route:
(192.168.83.1)
(192.168.12.67)
<*>
End of list

<省略>

Reply to request 4 (60 ms). Received packet has options
Total option bytes= 12, padded length=12
Loose source route:
(192.168.83.1)
(192.168.12.67)
<*>
End of list

Success rate is 100 percent (5/5), round-trip min/avg/max = 60/67/88 ms
Router#

Strict オプションの使い方はLoose オプションと同じですが、指定した経路を経由して宛先に到達できない場合にはUnreachable となります。
Windows のPing で指定する-k オプションと同等です。

Loose, Strict, Record, Timestamp, Verbose[none]: Strict
Source route: 192.168.12.67 192.168.83.1
Loose, Strict, Record, Timestamp, Verbose[SV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.5.1, timeout is 2 seconds:
Packet has IP options: Total option bytes= 11, padded length=12
Strict source route: <*>
(192.168.12.67)
(192.168.83.1)

Unreachable from 192.168.12.67. Received packet has options
Total option bytes= 11, padded length=12
Strict source route: <*>
(192.168.12.67)
(192.168.83.1)

<省略>

Success rate is 0 percent (0/5)
Router#


Record オプションを指定すると、ICMP Echo Request が宛先に到達し、Echo Reply が戻ってくるまでに通過したルータのアドレスを取得する事が出来ます。
Windows のPing で指定する-r オプションと同等です。

Loose, Strict, Record, Timestamp, Verbose[none]: Record
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.5.1, timeout is 2 seconds:
Packet has IP options: Total option bytes= 39, padded length=40
Record route: <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)

Reply to request 0 (40 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(192.168.12.66)
(192.168.83.3)
(10.33.5.1)
(192.168.83.1)
(192.168.12.65)
(192.168.12.66) <*>
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list

<省略>

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/40/40 ms
Router#

Timestamp オプションを指定すると、途中のルータを通過した時刻を知ることが出来ます。
Windows のPing で指定する-s オプションと同等です。

Loose, Strict, Record, Timestamp, Verbose[none]: Timestamp
Number of timestamps [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[TV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.5.1, timeout is 2 seconds:
Packet has IP options: Total option bytes= 40, padded length=40
Timestamp: Type 0. Overflows: 0 length 40, ptr 5
>>Current pointer<<
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)

Reply to request 0 (52 ms). Received packet has options
Total option bytes= 40, padded length=40
Timestamp: Type 0. Overflows: 0 length 40, ptr 29
Time=*20:54:03.903 PST (810D397F)
Time=*20:54:03.915 PST (810D398B)
Time=*20:54:03.627 PST (810D386B)
Time=*20:54:03.627 PST (810D386B)
Time=*20:54:03.935 PST (810D399F)
Time=*20:54:03.955 PST (810D39B3)
>>Current pointer<<
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)
Time= 16:00:00.000 PST (00000000)

<省略>

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/52 ms
Router#

Verbose とは何でしょうか?これまで見てきたLooseStric オプションを実行した時にも勝手に入っていました。

Loose, Strict, Record, Timestamp, Verbose[LV]:

Loose, Strict, Record, Timestamp, Verbose[SV]:

Verbose とは、「多弁な」とか「くどい」という意味の英単語です。
単に宛先を指定してPing を実行すると、!!!!! としか出てきませんでしたが、Verbose を指定するとPing 毎のRTT (Round Trip time = 往復遅延時間)を知ることが出来ます。

Loose, Strict, Record, Timestamp, Verbose[none]: verbose
Loose, Strict, Record, Timestamp, Verbose[V]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.5.1, timeout is 2 seconds:
Reply to request 0 (20 ms)
Reply to request 1 (20 ms)
Reply to request 2 (20 ms)
Reply to request 3 (20 ms)
Reply to request 4 (20 ms)
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 ms
Router#

Verbose モードは、LooseStric といった拡張機能を指定すると、自動的に有効となります。


IP ヘッダーオプションを使う際に注意すること

“標準”の哲学―スタンダード・テクノロジーの三〇〇年

同じEthernet なのに、なんでつながらないの?


最近のパソコンには、Ethernet インターフェイスが標準装備されています。
ご存知の通りEthernet は、Xerox により開発され、DEC (Digital Equipment Corporation)、Intel、Xerox により規格が定められた後、IEEE の802 委員会(LMSC - LAN and MAN Standard Committee) によってIEEE 802.3 として標準化されました。

買ってきたパソコンを、LAN につなげようとした時に事件は起こります。

A社のパソコンはスイッチにつながるのに、B社のパソコンだとリンクアップしない!
同じEthernet なのに・・・

標準化され、広く普及しているEthernet ですらこういうことは起こります。

IEEE、IETF、ISO・・・ネットワーク業界も標準だらけです。
そもそも標準って、誰が考えたんでしょう?

この本では、18世紀後半に産声を上げた「標準化」の思想が、どのように発展してきたかを丁寧に説明しています。

「そもそも、標準ってのはね・・・」


書名:“標準”の哲学―スタンダード・テクノロジーの三〇〇年
著者:橋本 毅彦
出版社:講談社

ログがないので分かりません

ログがないので分かりません

一過性のトラブルについてメーカーに問い合わせると、大抵の場合このような回答を貰います。
ちょっと待ってください。

本当にそれで良いんですか?
また発生したらどうするの?

最近は、わざわざ聞き返さなくても「また発生したら○○のログを採ってください」と教えてくれることが多くなりました。

でもやっぱり、煙に巻かれてるような感じです。
本当にそのログでトラブルの原因が分かるのでしょうか?

様子を見て、と言われたら次の事を確認しましょう。

どういう情報がないから分からなかったのか
その情報で何が分かるのか
そのコマンド出力のどの部分に注目すべきなのか

これを繰り返す事で、ノウハウが蓄積されてきます。しかも、このノウハウは単なるマニュアルではなく応用の利くノウハウです。
次に発生するトラブルがまったく同じ内容でなくても、前回より短時間で対応できることでしょう。

exec prompt timestamp - show コマンドを実行した時刻を知る

このログ、何時に採ったの?

お客様から送られてきたログを見ていると、怪しい箇所を発見しました。

「このカウンターの上がり方は異常だよね」

そのshow コマンドは複数回連続して採ってあり、カウンター値が異常に増えている事が見て取れます。
でも、このshow コマンドはどれくらいの間隔で実行したのでしょうか?
コマンドの出力にタイムスタンプが付いていないので分かりません。

多くの人は、show clock コマンドを使ってコマンド実行時の時刻を表示させているようです。

Router#
Router#show clock
03:24:18.664 UTC Thu Dec 29 2005

Router#
Router#show interfaces ethernet 0/0
Ethernet0/0 is up, line protocol is up
Hardware is AmdP2, address is 0050.500b.9100 (bia 0050.500b.9100)
Internet address is 1.60.50.54/8
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 1/75/139095/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 2000 bits/sec, 3 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
5164144 packets input, 513614455 bytes, 0 no buffer
Received 5163863 broadcasts, 0 runts, 0 giants, 0 throttles
1797 input errors, 0 CRC, 0 frame, 0 overrun, 1797 ignored
0 input packets with dribble condition detected
133101 packets output, 12732441 bytes, 0 underruns
0 output errors, 84 collisions, 1 interface resets
0 babbles, 0 late collision, 108 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Router#


でも、トラブルの真っ最中に、コマンドを実行するたびにshow clockしていては時間の無駄ですし、忘れてしまうことだって考えられます。

そこで、exec prompt timestamp を使う事を提案します。

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#
Router(config)#line console 0
Router(config-line)#
Router(config-line)#exec prompt ?
timestamp Print timestamps for show commands

Router(config-line)#
Router(config-line)#exec prompt timestamp
Router(config)#^Z
Router#

exec prompt timestamp を設定しておくと、show コマンドの出力にタイムスタンプをつけてくれるようになります。

Router#
Router#show interfaces gigabitEthernet 0/1
Load for five secs: 5%/0%; one minute: 6%; five minutes: 3%
Time source is user configuration, 03:25:53.011 UTC Thu Dec 29 2005

GigabitEthernet5/0/1 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 0012.7ff7.7e81 (bia 0012.7ff7.7e81)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:06, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 7000 bits/sec, 10 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1887 packets input, 176680 bytes, 0 no buffer
Received 1327 broadcasts (0 multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 318 multicast, 0 pause input
0 input packets with dribble condition detected
44 packets output, 4844 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
Router#



このexec prompt timestamp はIOS version 12.2 からはサポートされているようですが、12.1 や12.0 でも一部のメンテナンスリリースで利用可能です。
みなさんがお使いのルータでも利用可能か、一度確認されることをお勧めします。

信頼性工学のはなし―信頼度99.9999…%をめざして

最近よく壊れるよね。


隣の席のAさんがメーカーの人と電話で話しています。
数十箇所の地方拠点に展開したルータとスイッチが、導入から数年経ち、ぼちぼち壊れ始めたら危険信号です。

メーカーに故障解析を依頼すると

「○○が壊れてたのが原因でした。でもMTBF 範囲内です。傾向性も見られません」

サポート契約を結んでいるので交換してくれたから良いような物ですが、腑に落ちません。
交換するまでネットワークは使えませんし、交換するために人も動きますからそのコストも無視できません。

そもそもMTBF はどうやって算出してるんでしょうか?
ルータなどの機械単体だけではなく、ネットワーク全体の信頼性はどうやって測ったら良いのでしょうか?

そんな事を考え始めたら、この本を手にとって見てください。
著者は航空自衛隊で長年飛行機の開発プロジェクトにかかわってきた、信頼性工学のベテランです。
豊富な経験と知識に基づいて、平易な言葉で説明されている信頼性工学入門の良書です



書名:信頼性工学のはなし―信頼度99.9999…%をめざして
著者:大村 平
出版社:日科技連出版社

Cisco.com (CCO) に登録しよう

Cisco Systems を知っていますか?

愚問でしたね。ネットワークエンジニアの皆さんには、何を今更・・でしょう。
ご存知の通りCisco Systems (以下、Cisco) は、通信機器業界の顔、市場シェア7割を超える巨人です。

Cisco.com (シスコ・ドット・コム)は、Cisco が運営するウェブ・サイトの正式名称です。数年前まではCCO (Cisco Connection Online) と呼ばれていました。
Cisco の社員や代理店の人は今でもCCO と呼ぶことが多いので、耳にされた事があるかもしれません。

他のメーカのウェブサイト同様、Cisco.com でも技術資料やツールが公開されていますが、Cisco.com のコンテンツ数は他を大きく引き離しています。
内容も、Cisco 製品に限定せず、CCNA などネットワークの勉強に有効な資料が多くあります。

一部のツールはユーザ登録が必要ですが、無料です。
「俺は紫色しか使わない!」というアンチCisco な人も居るでしょうが、これを利用しない手はありません。

http://www.cisco.com/jp/

Cisco.com (CCO) ユーザ登録ナビへ進む

「分かりやすい表現」の技術―意図を正しく伝えるための16のルール

「ルータが動かないんです」


トラブルの対応をしていると、毎日のように聞く言葉です。

ルータの電源が入らないの?
コンソールにアクセスできないの?
そもそもケーブルはささってる?
ひょっとして、重くて運べないって意味ですか?

「動かない」だけだと、いろいろな状況が考えられます。

やっと状況を聞きだして、「じゃあ、○○のログを送ってください」

半日待って受け取ったのは数十メガのテキストファイル・・・読むだけで一仕事です。手当たり次第に思いつくshow コマンドを打ちまくっている上に、数台のルータの間を行ったりきたり・・・
ASCII ART のネットワーク図は崩れてしまって読めません。

今日も終電を逃してしまいました。

トラブルレポートを書く時、集めたログを整理する時、数分でも良いので手を休めて考えてみてください。そのレポートを読んで、トラブルの現場にいなかった人が理解できますか?



書名:「分かりやすい表現」の技術―意図を正しく伝えるための16のルール
著者:藤沢 晃治
出版社:講談社(ブルーバックス)

腕木通信 ナポレオンが見たインターネットの夜明け

電気通信の登場以前に、これ程洗練された通信システムが存在したとは驚きです。


18世紀末、革命時代のフランスでクロード・シャップ(Claude Chappe) により発明された光通信システムのお話です。

腕木通信とは・・・?

約10キロ間隔で塔を立て、頂上に設置した3本の腕木を操作します。
腕木の角度によって数字を表現し、数字の組み合わせに単語を割り当てます(符号化)。
隣の塔の腕木を望遠鏡で確認し、自分の腕木を同じ状態にセットして次の塔へ伝える・・・塔がルータの役割をするわけです。

パリ〜ブレスト間(550q)の情報伝達に要した時間はたったの8分でした。
それまで、人の移動によってしか実現できなかった情報通信システムの、まさにブレークスルーと言えます。



書名:腕木通信 ナポレオンが見たインターネットの夜明け
著者:中野 明
出版社:朝日新聞社

service timestamps - タイムスタンプの表示方法

Cisco ルータで発生したトラブルを調査する時、皆さんはどのshow コマンドを一番に確認しますか?
状況により答えは様々だと思いますが、私はshow logging を実行して、障害発生中の状況がお客様の証言と食い違いがないかを確認します。

show logging を実行すると、そのルータで過去に発生したイベントが時系列で表示されます。

00:01:47: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
00:01:47: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to up
00:01:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
00:01:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to up

2行目の「GigabitEthernet0/1 のリンクアップ」は、0時1分47秒に発生したかのように見えますが、そうではありません。
数日が経過するとタイムスタンプの表示は次のように変わります。

6d06h: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to down
6d06h: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to down

もうお分かりですね。show logging で表示されるタイムスタンプは、イベントの発生時刻ではなく、ルータが起動してから、そのイベントが発生するまでに経過した時間なのです(この例では、Ge0/2 のリンクダウンは6日と6時間経過時に発生している)。
これでは、正確なイベント発生時刻が分からず、複数台のルータ間でログを見比べることなどできません。

show running-config を実行してみます。

Router#show running-config
Building configuration...

Current configuration : 1404 bytes
!
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime

最後の行に注目してください。
service timestamp は、ルータが出力するメッセージにつけられるタイムスタンプの表記法を設定するコマンドです。
log uptime を指定すると、以後のログのタイムスタンプは起動後の経過時間(Uptime)になります。
IOS では、このUptime がデフォルトになっているのです。

ここで設定をuptime からdatetime へ変更します。

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#
Router(config)#service timestamps log datetime
Router(config)#^Z
Router#

datetime に変更すると、タイムスタンプの表記が、イベントの発生した時刻になります。

*Mar 1 00:01:28: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
*Mar 1 00:01:28: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to up
*Mar 1 00:01:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
*Mar 1 00:01:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to up

datetime msec とすると、ミリ秒単位のタイムスタンプを表示させることができます。

*Mar 1 00:01:28.675: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
*Mar 1 00:01:28.701: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to up
*Mar 1 00:01:29.682: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
*Mar 1 00:01:29.707: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to up

同様に、service timestamps debug datetime msec を設定すると、Debug コマンドの出力にも同様のタイムスタンプを表示させることができます。


さすがにネットワークの中心に設置されているコアルータでは、service timestamps がデフォルトのままで運用されている例はほとんど見たことがありませんが、地方オフィスに設置されているような小型ルータではたまに見かけます。

イベントが発生した時刻を正確に表示させることで、トラブル発生時のネットワークの状況を正確に把握することが可能となります。

無料メールマガジン「英語でネットワークエンジニア」

アライドテレシス、アラクサラ、日立電線・・・確かに国産メーカーもがんばっていますが、今でも通信機器市場はCisco Systems に代表される米系メーカーの独擅場です。
ルータやスイッチを設定するために、英語のマニュアルやメーカーのホームページ上の資料を読むことはネットワークエンジニアの業務と言っても過言ではありません。

え?Cisco のマニュアルは日本語化されているから、英語なんて必要ないですか?

確かにCisco はマニュアルを日本語化していますし、TAC の技術資料の翻訳にも力を入れているようです。

しかし、です。

本屋に並んでいるような翻訳本とは違い、ウェブサイト上の技術情報は、次々に本社から送られてくる資料を早く訳して公開するのに手一杯で、訳文の質は決して高くありません。
訳しているのはエンジニアではありません。訳している間に、原文にあった文字になっていない(行間の)文脈が抜け落ちてしまい、役に立たない技術資料も多く見られます。

そうです。マニュアルやRFC を原文で読めれば、日本語だけでは得られなかった多くの情報があなたの物になるのです。

「でも、辞書と画面を行ったりきたりしてると疲れるんだよね。。。」

ごもっともです。しかし、マニュアルやRFC は中学英語レベルでも十分読み解くことができます。
必要なのは語彙力(単語)です。
メールマガジン「英語でネットワークエンジニア」では、毎回ひとつの英単語を取り上げ、技術資料の中での使われ方を見ていき、例文にちなんだ技術解説をします。


□■―――――――――――――――――――――――□■

【英語でネットワークエンジニア #1】
2006/1/9

□■―――――――――――――――――――――――□■

expire (いくすぱいあ)

〔動〕終わる、満了する

■ 発音
http://dictionary.goo.ne.jp/voice/e/01011290.wav


スイッチやルータなどのネットワーク機器では、様々な
タイマーが動作しています。
ある状態から他の状態へ遷移するためのトリガーとして、
タイマーが利用されています。タイマーは刻一刻とカウ
ントし続け、規定値に達するとexpire し、それをトリ
ガーに次の状態へ遷移します。

■ 例文
The switch port waits for the Forward Delay timer to
expire, moves the port to the LEARNING state, and
resets the Forward Delay timer.

■ 訳文
Switch port は、Forward Delay タイマーが満了するのを
待ち、LEARNING ステートへ移行し、Forward Delay タイ
マーをリセットする。

■ 解説
STP(Spanning Tree Protocol)のポート・ステート遷移
に関する説明文です。

スイッチのポートがリンク・アップすると、BLOCKING ->
LISTENING -> LEARNING と状態遷移し、そのポートの先に
ループが存在しないと判断されるとFORWARDING となります。

この例文では、LISTENING -> LEARNING の状態遷移を取り
上げています。

LEARNING へ状態が遷移すると、Forward Delay タイマーは
リセットされ、最初からカウントが始まります。

Forward Delay のデフォルトは15秒ですが、4〜30秒の間で
設定可能です。

■ 意訳
Forward Delay タイマーが満了すると、Switch port は
(LISTENING から) LEARNING ステートへ移行し、Forward
Delay タイマーをリセットする。

■ 補足
expire の名詞形 expiration を使って、次のように言い
換える事も出来ます。

The switch port waits for expiration of the Forward
Delay timer, moves the port to the LEARNING state,
and resets the Forward Delay timer.


□■―――――――――――――――――――――――□■

発行:MK Consulting

□■―――――――――――――――――――――――□■