JP4454516B2 - 障害検出装置 - Google Patents

障害検出装置 Download PDF

Info

Publication number
JP4454516B2
JP4454516B2 JP2005039528A JP2005039528A JP4454516B2 JP 4454516 B2 JP4454516 B2 JP 4454516B2 JP 2005039528 A JP2005039528 A JP 2005039528A JP 2005039528 A JP2005039528 A JP 2005039528A JP 4454516 B2 JP4454516 B2 JP 4454516B2
Authority
JP
Japan
Prior art keywords
failure
packet
packets
link
control packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2005039528A
Other languages
English (en)
Other versions
JP2006229477A (ja
Inventor
靖 笹川
健一 瓦井
正実 百海
孝 鷹取
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2005039528A priority Critical patent/JP4454516B2/ja
Priority to US11/155,658 priority patent/US7957267B2/en
Publication of JP2006229477A publication Critical patent/JP2006229477A/ja
Application granted granted Critical
Publication of JP4454516B2 publication Critical patent/JP4454516B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/24—Testing correct operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、障害検出装置に関し、特にネットワーク上の障害検出を行う障害検出装置に関する。
近年、通信事業者が提供する、ＬＡＮ（Local Area Network）を利用してのキャリアサービスとして、広域イーサネット（イーサネットは登録商標）があり、現在広がりを見せている。広域イーサネットは、イーサネットのＬＡＮ環境を、レイヤ２スイッチを使ってネットワークを接続し、複数のＬＡＮ環境を１つに統合するサービスである。
広域イーサネットは、高価なルータ（レイヤ３スイッチ）を用いずに、安価なスイッチングハブ（レイヤ２スイッチ）を使うので、ネットワークの構築や運用管理に関わるコストが削減でき、例えば、企業の構内ＬＡＮをつなげて、都市全体のエリアにまで拡張することが可能である。
また、このようなキャリアネットワークにおいて、ネットワーク障害が発生し、復旧が遅れると、被害も重篤なものになるため、装置内の各種パッケージの二重化、装置自身の二重化、リンクの二重化、エンド−エンド間のパスの二重化等の様々なレベルでの冗長構成が採用されており、障害検出時には冗長系側にすみやかに切り替えを行うことで耐障害性の向上を図っている。
ただし、冗長構成をいくら設けていても、装置自身が障害をすばやく的確に検出できなければ意味がなく、サイレント障害（冗長側への自動的な切り替えが行われず、またオペレータへのアラーム通知もなく、異常動作が生じていることが認識しにくい障害）が発生すると、障害期間が長時間続き、またイーサネット網においては、ループ（loop）が生じて、フレーム輻輳が発生してしまうおそれがある。
図１１、図１２はループによるネットワーク障害を説明するための図である。ネットワーク５０は、ノード５１〜５４で構成され、ノード５１〜ノード５４はリング状に互いに接続し、ノード５１とノード５４が接続している（図中、細実線が物理的な回線）。
ここで、イーサネット網を構築する場合には、ループ状の経路が生じないように、ツリー（tree）構造の経路となるように構築する。なぜなら、もし、ネットワーク上にループ状の経路が存在すると、フレームのブロードキャスト時に、ブロードキャスト・ストーム（broadcast storm）と呼ばれるフレーム輻輳が発生するからである。
すなわち、あるノードからブロードキャスト・フレームを送出したとき、ブロードキャスト・フレームは、各ノードにおいて、受信ポート以外のすべてのポートからフラッディング（flooding）されるので、ネットワーク内にループがあると、ブロードキャスト・フレームは、ループ内を無限に流れることになり、同じ経路を延々とブロードキャスト・フレームが巡ってしまう。
すると、帯域が瞬時にブロードキャスト・フレームで埋まってしまい、通常の通信ができなくなってしまう。例えば、図１１のように、ネットワーク５０にはループＲがあるので、ブロードキャスト・フレームがノード５１→ノード５２→ノード５３→ノード５４→ノード５１→・・・とうように、ループＲ上を無限に流れて輻輳が発生してしまう。
したがって、イーサネット網を構築する場合には、レイヤ２ネットワークでのループを論理的に遮断する必要がある。例えば、図１２のように、回線Ｌ１、Ｌ２を論理的に遮断すれば、すべてのループがなくなって、ツリーＴの構造が形成される（図中、太実線）。
このようなツリー（スパニングツリー（Spanning Tree）と呼ばれる）を形成するためには、例えば、ＳＴＰ（Spanning Tree Protocol）の制御により、各ノード間でＢＰＤＵ（Bridge Protocol Data Unit）と呼ばれる制御情報をやりとりし、トラヒック経路をダイナミックに変更する運用を行う（スタティックに運用する場合には、各ノードに対してあらかじめツリー経路となるように設定しておく）。これにより、物理的にループを形成しているネットワークであっても、フレームがループの中を巡り続ける事態を防ぐことができる。
ところが、図１２のようなスパニングツリーが形成されていても、ネットワーク５０にサイレント障害が発生して障害検出機能が効果的に働かないと、そのために各ノードでの経路認識が食い違ってきて、ツリー構造が崩れ、ループが生じてしまうおそれがある。したがって、サイレント障害の対策には、冗長構成を設けることの他にさらに、いかに高精度に障害を検出できるかということが重要な事項となる。
従来のイーサネットの障害検出として、ＬＡＮ内の装置でループバックテストを実行する技術が提案されている（例えば、特許文献１）。
特開２００３−３０４２６４号公報（段落番号〔００２０〕〜〔００２７〕，第１図）
上記のような、サイレント障害が発生すると、運用系から冗長系への切替え契機は、顧客からの苦情によるしかなく、サービスの長時間の断となるため、各ベンダでは独自のプロトコルによって、ネットワーク障害を検出する取り組みがなされている。
図１３はネットワーク障害検出の流れを示す図である。ベンダ独自プロトコルによる一般的なネットワーク障害を検出する一動作例を示している。ノードＡ、ＢがリンクＬ３、Ｌ４で接続している。
〔Ｓ２１〕ノードＡは、リンクＬ３を通じて、フレームＦａをノードＢへ送信する。フレームＦａには、自ノード識別欄と他ノード識別欄があり、ノードＡでは、フレームＦａの自ノード識別欄に、自分がノードＡである旨の“Ａ”を挿入し、他ノード識別欄には、リンクＬ４から受信したフレームＦｂの自ノード識別欄に記されている“Ｂ”を折り返す形で挿入して送信する。
〔Ｓ２２〕ノードＢは、リンクＬ４を通じて、フレームＦｂをノードＡへ送信する。フレームＦｂは、自ノード識別欄と他ノード識別欄があり、ノードＢでは、フレームＦｂの自ノード識別欄に、自分がノードＢである旨の“Ｂ”を挿入し、他ノード識別欄には、リンクＬ３から受信したフレームＦａの自ノード識別欄に記されている“Ａ”を折り返す形で挿入して送信する。
〔Ｓ２３〕ノードＡは、フレームＦｂを受信すると、フレームＦｂの自ノード識別欄に記されている“Ｂ”という情報をメモリに記憶させる（すなわち、相手ノードがＢであることを記憶する）。なお、メモリのエージング時間（メモリをクリアする更新時間）を１分とし、フレームＦｂの送信間隔は２０秒とする。
〔Ｓ２４〕ノードＢは、フレームＦａを受信すると、フレームＦａの自ノード識別欄に記されている“Ａ”という情報をメモリに記憶させる（すなわち、相手ノードがＡであることを記憶する）。なお、メモリのエージング時間を１分とし、フレームＦａの送信間隔は２０秒とする。
〔Ｓ２５〕ノードＡは、フレームＦｂが３回来ないとメモリをクリアすることになり、このとき他ノード識別欄に“０”を挿入したフレームＦａ−１を生成してノードＢへ送信する。また、ノードＡは、フレームＦｂが３回来ないことで、リンクＬ４（または対向のノードＢ）に障害が発生していることを検出する。
〔Ｓ２６〕ノードＢは、フレームＦａ−１を受信すると、他ノード識別欄に“０”が挿入されていることを認識する。すなわち、自分のノード識別名（Ｂ）がノードＡに伝わっておらず、自分が送信しているフレームＦｂがノードＡに正常受信されていないことを認識し、リンクＬ４（または対向のノードＡ）に障害が発生していることを検出する。
このように、「対向装置から制御フレームを一定期間受信しないこと」及び「対向装置から受信する制御フレーム中の折り返し情報が、自装置が送信した情報と異なること」によって、送受信ノード間で障害検出を行うことができる。
しかし、このような現状のベンダ独自プロトコルによるネットワーク障害検出では、上記の例のような、対向装置側の監視内容を意識した上での制御を行うことを前提としているため、ネットワーク内の自社装置間で接続されたリンクしか対応できないといった問題があった。
このため、マルチベンダ化が進んでいる現在のキャリアネットワークに対して、利便性が乏しいといった問題があり、さらにネットワーク検出障害のプロトコルの標準化も進展していないのが現状である。
このため、マルチベンダ環境において、自装置と対向装置間で同一プロトコルによる相互動作をすることなく、対向装置側が障害の監視を何ら意識せずに、ネットワーク障害を検出できれば、非常に耐障害性の向上という意味での効果が期待され、このような技術の実現が強く要望されている。
本発明はこのような点に鑑みてなされたものであり、対向装置間で同一プロトコルによる相互動作をすることなく、自装置のみでネットワーク障害を高精度に検出する障害検出装置を提供することを目的とする。
本発明では上記課題を解決するために、図１に示すような、ネットワーク上の障害検出を行う障害検出装置１０において、障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置２０に対して、障害監視制御パケットを送信する障害監視制御パケット送信部１１と、障害監視制御パケットの送信パケット数をカウントする送信パケットカウンタ１２と、対向装置２０から送信される制御パケットを受信して、受信パケット数をカウントする受信パケットカウンタ１３と、送信パケット数と受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する障害検出部１４と、を有することを特徴とする障害検出装置１０が提供される。
ここで、障害監視制御パケット送信部１１は、障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置２０に対して、障害監視制御パケットを送信する。送信パケットカウンタ１２は、障害監視制御パケットの送信パケット数をカウントする。受信パケットカウンタ１３は、対向装置２０から送信される制御パケットを受信して、受信パケット数をカウントする。障害検出部１４は、送信パケット数と受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する。
本発明の障害検出装置は、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置に対して、障害監視制御パケットを送信して障害監視制御パケットの送信パケット数をカウントし、対向装置から送信される制御パケットを受信して、受信パケット数をカウントし、送信パケット数と受信パケット数に対して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識する構成とした。これにより、マルチベンダ環境において、自装置と対向装置間で同一プロトコルによる相互動作をすることなく、自装置のみでネットワーク障害を高精度に検出することが可能になる。
以下、本発明の実施の形態を図面を参照して説明する。図１は障害検出装置の原理図である。障害検出装置１０は、障害監視制御パケット送信部１１、送信パケットカウンタ１２、受信パケットカウンタ１３、障害検出部１４から構成され、ネットワーク上の障害検出を行う装置である。障害検出装置１０の機能は、例えば、広域イーサネット内のレイヤ２スイッチなどに適用可能である。
障害監視制御パケット送信部１１は、障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置２０に対して（すなわち、自社製品とは異なる他社の製品に対して）、障害監視制御パケットを送信する。送信パケットカウンタ１２は、障害監視制御パケットの送信パケット数をカウントする。
受信パケットカウンタ１３は、対向装置２０から送信される制御パケットを受信して、受信パケット数をカウントする。障害検出部１４は、送信パケット数と受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する。
次に障害監視制御パケット送信部１１、送信パケットカウンタ１２及び受信パケットカウンタ１３の障害検出装置１０内の配置位置について説明する。図２は障害検出装置１０のブロック構成を示す図である。障害検出装置１０は、スイッチング処理部１０１、出力パケット処理部（Egress Process）１０２ａ、入力パケット処理部（Ingress Process）１０２ｂ、ＭＡＣ（Media Access Control）処理部１０３ａ、１０３ｂ、リンクインタフェース部１０４ａ、１０４ｂ、ＣＰＵ１０５から構成される。
出力パケット処理部１０２ａは、スイッチング処理部１０１でスイッチングされたパケットの入力処理を行い、ＭＡＣ処理部１０３ａは、ＭＡＣレイヤの終端処理を行う。リンクインタフェース部１０４ａは、物理レイヤでの送信インタフェース処理を行って、パケットを対向装置２０へリンクＬを介して送信する。
また、リンクインタフェース部１０４ｂは、リンクＬを介して送信された対向装置２０からのパケットに、物理レイヤでの受信インタフェース処理を行い、ＭＡＣ処理部１０３ａは、ＭＡＣレイヤの終端処理を行う。入力パケット処理部１０２ｂは、パケットの出力処理を行ってスイッチング処理部１０１へ送信する。ＣＰＵ１０５は、各構成ブロックの全体制御を行う。
ここで、障害監視制御パケット送信部１１の機能は、出力パケット処理部１０２ａに配置し、送信パケットカウンタ１２は、リンクインタフェース部１０４ａに配置する。そして、出力パケット処理部１０２ａから障害監視制御パケットを一定間隔で流して、リンクインタフェース部１０４ａでその障害監視制御パケットをカウントする。
障害検出部１４の機能を有するＣＰＵ１０５は、送信パケットカウンタ１２でカウントされる送信パケット数を監視して、一定時間内にパケット数に変化がなければ障害発生とみなす（障害監視制御パケット送信部１１から一定間隔で障害監視制御パケットが送信されるので、一定時間カウントアップされていなければ障害が発生していることになる）。
この場合、出力パケット処理部１０２ａ→ＭＡＣ処理部１０３ａ→リンクインタフェース部１０４ａの経路が、障害検出の保証範囲となる（ただし、この送信側の障害検出では、対向装置２０に確実にパケットが送信されていることは確認できないが、リンクＬが確立した状態で、少なくてもリンクインタフェース部１０４ａまでが正常であれば、トラフィックが対向装置２０に届かない確率は非常に低いので、障害検出のカバー範囲は広くなる）。
一方、受信パケットカウンタ１３は、入力パケット処理部１０２ｂに配置し、入力パケット処理部１０２ｂにおいて、対向装置２０から送信されたパケットをカウントする。
障害検出部１４の機能を有するＣＰＵ１０５は、受信パケットカウンタ１３でカウントされる受信パケット数を監視して、一定時間内にパケット数に変化がなければ障害発生とみなす（対向装置２０から一定間隔で制御パケットが送信されるので、一定時間カウントアップされていなければ障害が発生していることになる）。この場合、対向装置２０→リンクインタフェース部１０４ｂ→ＭＡＣ処理部１０３ｂ→入力パケット処理部１０２ｂの経路が、障害検出の保証範囲となる。
このように、障害監視制御パケットを送信して障害検出を行う場合は、障害監視制御パケット送信部１１を装置の上位レイヤ処理側（装置の内側）に配置し、送信パケットカウンタ１２を物理レイヤ処理（装置の外側）に配置する。また、対向装置２０から送信される制御パケットによる障害検出を行う場合は、受信パケットカウンタ１３を装置の上位レイヤ処理側に配置する。このような配置にすることで、上記のように障害検出の保証範囲を最も広くとることが可能になる。
次に１本のリンクにおける障害検出動作について説明する。図３は装置間が１本のリンクで接続された際の障害検出動作を示すシーケンス図である。障害検出装置１０の機能を有する装置を自社装置１０ａ、対向装置２０を他社装置２０ａとし、互いに１本のリンクＬで接続している。
〔Ｓ１〕自社装置１０ａ内の障害監視制御パケット送信部１１は、障害監視用の独自のパケットである障害監視制御パケットを一定間隔で他社装置２０ａへ送信する。なお、この障害監視制御パケットは、他社装置２０ａで受信されたときに廃棄されるものであり、ペイロードには何の制御内容をも含まないパケットである。
〔Ｓ２〕自社装置１０ａ内の送信パケットカウンタ１２は、障害監視制御パケットをカウントする。
〔Ｓ３〕自社装置１０ａ内の障害検出部１４は、カウントされる送信パケット数を監視する。カウント値に変化がなければ（カウントアップされてなければ）ステップＳ４へいき、変化があれば監視を続ける。
〔Ｓ４〕障害検出部１４は、自社装置１０ａに障害が発生しているものとみなし外部へアラーム通知する。
〔Ｓ５〕他社装置２０ａは、制御パケットを送信する。この制御パケットは、他社装置２０ａから送信される何らかの制御パケットであり（カウント動作のみに用いるためどのような制御パケットでもよい）、一定間隔で送信されるものである。
〔Ｓ６〕自社装置１０ａ内の受信パケットカウンタ１３は、制御パケットを受信してカウントする。
〔Ｓ７〕自社装置１０ａ内の障害検出部１４は、カウントされる受信パケット数を監視する。カウント値に変化がなければステップＳ８へいき、変化があれば監視を続ける。
〔Ｓ８〕障害検出部１４は、他社装置２０ａから自社装置１０ａ間の経路に障害が発生しているものとみなし外部へアラーム通知する。
ここで、ステップＳ１、Ｓ５において、障害監視制御パケットと制御パケットは、常時一定間隔でリンクＬ上に送出されるユーザトラフィックとは独立したパケットとする。
なぜなら、もしユーザトラフィックに関連するパケットを使用して、パケット数のカウント値による障害検出を行うと、夜間などではユーザトラフィックが減少しカウント値の変化が起こらず、通信状態が正常であっても障害が発生していると誤って検出するおそれがあるからである。
このため、自社装置１０ａからはユーザトラフィックとは無関係な独自の障害監視制御パケットを送信し、また他社装置２０ａから送信されるユーザトラフィックとは無関係な何らかの制御パケットを受信することで、ユーザトラフィックが流れていないときであっても、誤検出のない障害検出を可能にしている。
また、ステップＳ４、Ｓ８ではアラーム通知を行ってオペレータに保守動作を促しているが、その後の障害検出装置１０の動作として、該当ポートを無効化する処理が行われる（対向装置２０はリンク断を検出することになる）。無効化されたポートの復旧は、手動または定期的に自動復旧が行われる。さらに、障害検出をリンク冗長／装置冗長への切り替え契機として、冗長系へ切り替えることも可能である。
以上説明したように、障害検出装置１０では、自装置側で統計情報として送信パケット数及び受信パケット数を計測して、これらの統計情報を収集し、障害検出を行う構成とした。このような構成により、対向装置２０側の監視内容を意識せずに障害検出を行うことができる。すなわち、マルチベンダ環境において、自装置と対向装置間で同一プロトコルによる相互動作をすることなく、対向装置２０側が障害の監視を何ら意識せずに、また冗長ポートを追加するなどといった作業も不要であり、効率よくネットワーク障害を検出できる。このため、従来のように、自社装置間でのみ接続されたリンクしか障害検出ができないといった不便さがなくなり、他ベンダ装置に接続しても、高精度にネットワーク障害が検出できるので、マルチベンダ環境において対耐障害性の向上を図ることが可能になる。
次に自社装置１０ａと他社装置２０ａがリンク・アグリゲーション（Link Aggregation（以降ＬＡと呼ぶ））で接続している際の障害検出動作について説明する。なお、ＬＡは、複数リンクを仮想的な１つのリンクとみなす接続方式であり、IEEE.802.3adで規定されている。
図４は装置間がＬＡで接続された際の障害検出動作を示すシーケンス図である。自社装置１０ａと他社装置２０ａが３本のリンクＬ１〜Ｌ３で接続し、このリンクＬ１〜Ｌ３を仮想的な１本のリンクとして使用するものとする。
〔Ｓ１１〕自社装置１０ａ内の障害監視制御パケット送信部１１は、障害監視用の独自のパケットである障害監視制御パケットをリンクＬ１〜Ｌ３を介して、一定間隔で他社装置２０ａへ送信する。
〔Ｓ１２〕自社装置１０ａ内の送信パケットカウンタ１２は、リンクＬ１〜Ｌ３毎に流れる障害監視制御パケットをカウントする。
〔Ｓ１３〕自社装置１０ａ内の障害検出部１４は、リンクＬ１〜Ｌ３毎にカウントされる送信パケット数を監視する。カウント値に変化がなければステップＳ１４へいき、変化があれば監視を続ける。
〔Ｓ１４〕障害検出部１４は、自社装置１０ａに障害が発生しているものとみなし外部へアラーム通知する。
〔Ｓ１５〕他社装置２０ａは、リンクＬ１〜Ｌ３を介して、制御パケットを送信する。
〔Ｓ１６〕自社装置１０ａ内の受信パケットカウンタ１３は、リンクＬ１〜Ｌ３毎に制御パケットを受信してカウントする。
〔Ｓ１７〕自社装置１０ａ内の障害検出部１４は、リンクＬ１〜Ｌ３毎にカウントされる受信パケット数を監視する。カウント値に変化がなければステップＳ１８へいき、変化があれば監視を続ける。
〔Ｓ１８〕障害検出部１４は、他社装置２０ａから自社装置１０ａ間の経路に障害が発生しているものとみなし外部へアラーム通知する。
次に障害検出装置１０を具体的に実現した際の構成及び動作について説明する。図５は障害検出装置１０の機能を有する通信装置の構成を示す図である。通信装置３０は、装置管理部３１、ＣＬ（command line）／ＮＭＳ（network management system）インタフェース部３２、ＬＣＣ（Link Connectivity Check）プロトコル処理部３４、フィルタリングデータベース処理部３５、回線／スイッチ制御部３６、スイッチング処理部３７、回線インタフェース処理部３８−１〜３８−ｎから構成される。
なお、障害監視制御パケット送信部１１、送信パケットカウンタ１２及び受信パケットカウンタ１３の機能は、回線インタフェース処理部３８−１〜３８−ｎに含まれ、障害検出部１４の機能は、ＬＣＣプロトコル処理部３４に含まれる。
装置管理部３１は、装置全体の管理を行う。具体的にはプロビジョニング情報管理部３３と連携し、装置のプロビジョニング情報にもとづき、スイッチング処理部３７、回線インタフェース処理部３８−１〜３８−ｎ、ＬＣＣプロトコル処理部３４に動作条件を指示する。
また、スイッチング処理部３７／回線インタフェース処理部３８−１〜３８−ｎ／ＬＣＣプロトコル処理部３４から、動作状態／障害発生／障害復旧等に関する情報を入手し、必要なアクションを取る。障害検出制御を行う装置管理部３１に対する機能拡張例を以下の（Ａ１）〜（Ａ４）に示す。
（Ａ１）プロビジョニング情報管理部３３との連携によりポート毎にadminstatusパラメータの設定情報を読み出し、これにもとづき、ＬＣＣプロトコル処理部３４に動作条件の指示を行う。
（Ａ２）ＬＣＣプロトコル処理部３４からの通知により、障害検出をオペレータへ通知する。
（Ａ３）ＬＣＣプロトコル処理部３４からの通知により、障害検出を知り、必要によりフィルタリングデータベース処理部３５に対して、フィルタリングデータベースのフラッシュを指示する。
（Ａ４）ＬＣＣプロトコル処理部３４からの通知により、障害検出を知り、必要により回線／スイッチ制御部３６を経由し、回線インタフェース処理部３８−１〜３８−ｎに対して、Disableステートへの遷移を指示する。
ＣＬ／ＮＭＳインタフェース部３２は、CL（コマンドライン）／NMS（ネットワーク管理システム）とのインタフェースを司り、ここでは、プロビジョニング情報管理部３３と連携し、管理情報の設定及び表示を行う。
プロビジョニング情報管理部３３は、ＣＬ／ＮＭＳインタフェース部３２からの指示に従い、プロビジョニング情報を設定／表示すると共に、該当プロビジョニング情報を各機能ブロックに対して参照可能とする。
ＬＣＣプロトコル処理部３４は、ＬＣＣの動作主体であり、装置管理部３１から指示された動作条件に従い、障害を検出した場合は、その旨を装置管理部３１に通知する。障害検出制御を行うＬＣＣプロトコル処理部３４に対する機能拡張例を以下の（Ｂ１）〜（Ｂ５）に示す。
（Ｂ１）装置管理部３１からの指示により、ポート毎に障害監視機能／制御パケット送信機能の有効化／無効化を行い、ポート状態ステートマシン＃１〜＃ｎに動作指示を出すとともに、必要に応じて、回線インタフェース処理部３８−１〜３８−ｎに障害監視の開始／停止を指示する。
（Ｂ２）制御パケット送信機能が有効の場合、必要に応じて、回線インタフェース処理部３８−１〜３８−ｎに障害監視用制御パケットを装置管理部３１から指示された間隔で送信する事を指示する。
（Ｂ３）障害監視機能が有効の場合、回線インタフェース処理部３８−１〜３８−ｎからの障害検出通知／復旧通知を受信し、ポート状態ステートマシン＃１〜＃ｎに該当イベントの発生を通知する。
（Ｂ４）ポート状態ステートマシン＃１〜＃ｎの動作により、障害を認識し、該当ポートが障害である旨を、装置管理部３１に通知する。
（Ｂ５）装置管理部３１からの指示により、回線／スイッチ制御部３６を経由し、回線インタフェース処理部３８−１〜３８−ｎに対して、Disableステートへの遷移を指示する。
フィルタリングデータベース処理部３５は、プロビジョニング情報管理部３３、装置管理部３１、回線インタフェース処理部３８−１〜３８−ｎと連携し、ＭＡＣフィルタリングデータベースの原本を管理し、各回線インタフェース処理部に対して、必要なＭＡＣフィルタリングデータベースを提供するとともに、スイッチング制御部３７に対して、必要なスイッチングを指示する。
回線／スイッチ制御部３６は、装置管理部３１からの指示に従い、スイッチング処理部３７／回線インタフェース処理部３８−１〜３８−ｎに対して、動作条件を通知するとともに、スイッチング処理部３７／回線インタフェース処理部３８−１〜３８−ｎからの動作状態／障害発生／障害復旧等に関する情報を装置管理部３１に通知する。
スイッチング処理部３７は、回線／スイッチ制御部３６からの指示に従い、各回線インタフェース処理部及び自装置内の必要な機能ブロックとのスイッチングを行う。
回線インタフェース処理部３８−１〜３８−ｎは、回線／スイッチ制御部３６からの指示に従い、ＭＡＣフィルタリングデータベースを参照することによるパケットの送受信を行う。障害検出制御を行う回線インタフェース処理部３８−１〜３８−ｎに対する機能拡張例を以下の（Ｃ１）、（Ｃ２）に示す。
（Ｃ１）ＬＣＣプロトコル処理部３４からの指示により、障害監視ステートマシン＃１〜＃ｎに対して、障害監視の開始／停止を指示する。
（Ｃ２）障害監視ステートマシン＃１〜＃ｎは、統計情報（カウント値）の受信パケット数と送信パケット数の変化を周期的に監視し、障害検出／復旧検出をＬＣＣプロトコル処理部３４に通知する。
次に通信装置３０における障害検出の動作設定について説明する。
（１）障害検出用監視統計情報
（１ａ）受信パケット数：ＭＡＣチップの受信ユニキャストパケット数と受信非ユニキャストパケット数との和の変化を監視する。ただし、ＣＬＩによりクリアされないカウンタを監視する。
（１ｂ）送信パケット数：ＭＡＣチップの送信ユニキャストパケット数と送信非ユニキャストパケット数との和の変化を監視する。ただし、ＣＬＩによりクリアされないカウンタを監視する。
（２）単一物理ポートに対して、以下の動作指定を行う。
（２ａ）特定のMAC DA（マルチキャストアドレス／対向装置のユニキャストアドレス）、Ethertypeを付与した制御パケットを特定の送信間隔で送信する事を指定する。
（２ｂ）障害検出時の動作モードを指定する。
（TRAP通知のみ（障害検出時にアラーム通知をして保守動作を促すこと）／TRAP通知＋shutsown（障害検出時にアラーム通知をして保守動作を促し、該当ポートを無効化すること）／TRAP通知＋shutsown＋自動復旧（障害検出時にアラーム通知をして保守動作を促し、該当ポートを無効化し、定期的に自動復旧を試みること）。
（２ｃ）障害検出保護回数を指定する。
障害検出タイマ値×障害検出保護回数→この期間障害が継続した場合障害とする。障害検出タイマは８秒固定とする（受信パケット数または／送信パケット数がこのタイマの期間変化しなかった場合障害とする）。
（３）障害監視制御パケットの送信開始契機は以下とする。
「該当ポートがＬＣＣ機能を指定されている状態」かつ「該当ポートの物理ポートがUP状態」へ遷移時で該当ポートがパケットの送受信が可能となった時。
（４）送信パケット数／受信パケット数の変化の監視開始契機は以下とする（物理ポートのLINK UP／DOWNを考慮する）。
（４ａ）「該当ポートがＬＣＣ機能を指定されている状態」かつ「該当ポートがリンクアップ中」へ遷移時。
（４ｂ）「監視正常状態」で該当ポートのリンクダウンを検出後、リンクアップを検出時。
（４ｃ）TRAP通知モードで障害検出後、自動復旧した場合。
（４ｄ）TRAP通知モードで障害検出後、復旧待ち状態で、該当ポートのリンクダウンを検出後、リンクアップを検出時。
（４ｅ）TRAP通知＋shutdownモードで、障害検出によるshutdownを実施後、オペレータからの復旧指示によりリンクアップを試み、リンクアップした時。
なお、上記リンクアップ検出時は常に、該当ポートがパケットの送受信が可能となったことが条件として加わる。
（５）送信パケット数／受信パケット数の変化の監視停止契機は以下とする（物理ポートのLINK UP／DOWNを考慮する）。
（５ａ）該当ポートがＬＣＣ機能の指定を解除された時。
（５ｂ）該当ポートがリンクダウンした時。
（５ｃ）該当ポートがTRAP通知＋shutdown及びTRAP通知＋shutsown＋自動復旧モードで運用中に、障害検出によるshutdownを実施した場合。
（６）shutdownと通常のshutdownの識別と復旧方法
（６ａ）新たに本機能で認識するポート状態（LccOperStatus）を設け、ifOperStatusがdown状態で、LccOperStatusがfailureの時に、本機能によりshutdownを実施したものと判断する。
（６ｂ）上記状態からの復旧は、noshutdownコマンドにより行う。
（６ｃ）障害の検出そのものは、システムとしての警報の扱いの対象外とする。つまり、本機能による障害の検出そのものでは、TRAP通知のみとする。
（７）障害監視方式を以下に示す。
（７ａ）（４）に示す条件を障害監視のトリガとする。
（７ｂ）（２）で規定した障害検出タイマを周期として、（１）で規定した「受信パケット数」と「送信パケット数」の変化を監視する。
（７ｃ）前の周期で収集した「受信パケット数」／「送信パケット数」と現周期で収集した「受信パケット数」／「送信パケット数」を比較し、どちらかが一致した場合、障害と判断し、この障害検出が指定された保護回数連続した時、一致したカウンタ名及びポートIDを付加情報として障害検出を通知する。
（７ｄ）障害検出中は、上記と同様の方式で復旧を監視する。復旧の判定は前の周期で収集した「受信パケット数」／「送信パケット数」と現周期で収集した「受信パケット数」／「送信パケット数」を比較し、双方が不一致の場合とし、ポートIDを付加情報として障害検出を通知する。
（７ｅ）（５）で規定した条件をトリガとして、障害監視を停止する。
次に障害監視制御パケットのフォーマットについて説明する。図６は障害監視制御パケットのフォーマットを示す図である。図中の数値はbyteを表す。各フィールドの説明を以下に示す。
MAC DA[６]は、宛先MACアドレスであり、コマンドにて指定されたアドレスを設定する。デフォルトで01-00-0E-00-00-01。MAC SA[６]は、送出元MACアドレスであり、自装置のMACアドレスを設定する。
L／T[２]は、障害監視制御パケットのEther-Typeであり、 コマンドにて指定された値を設定する。Sub Type[１]は、0x20固定とする（0x20が障害監視制御パケットであることを示す識別番号となる）。
Flags[１]は、０固定とする。Code[２]は、＜02-00＞とし、ＬＣＣ機能の制御パケットを示す。TTL（Time to Live）[１]はリザーブとする（２５５固定）。TTL base[１]は、リザーブ（２５５固定）とする。
Sequence number[２]は、０固定とする。Slot-ID[１]は、パケットを送信するポートのスロット識別子である。Port-ID[１]は、パケットを送信するポートのポート識別子である。Padding[３６]は、ALL“０”を設定する。
次に通信装置３０のポート状態ステートマシン及び障害監視ステートマシンについて説明する。図７、図８はポート状態ステートマシン＃１〜＃ｎの状態遷移を示す図である。変数の定義を以下に示す。
LccAdminStatus：ＬＣＣ機能の該当ポートへの設定状態。disable,enableの状態を持つ。
ifOperStatus：該当ポートのオペレーショナルリンク状態。up,down,dormant（新規追加）の３つの状態を持つ。dormant状態へは、本機能によりshutdownされた場合に遷移し、他状態への遷移は通常のshutdownコマンドが投入された場合のみ遷移する。
LccOperStatus：本機能における該当ポートの状態であり、監視機能無効、監視正常、障害中、監視休止中の状態を持つ。監視機能無効（disable）は、本機能が指定されていない状態または指定されたがリンクがアップしていない状態である。監視正常（normal）は、本機能による監視状態にあり、正常な状態である。障害中（failure）は、本機能による障害を検出した状態で、動作モードにより、該当ポートのifOperStatusはdormant状態の場合とup状態の場合がある。監視休止中（unknown）は、本機能による監視正常時にリンクダウンを検出（ifOperStatusがdown）し、監視を休止している状態である。
LccMonStartInd：障害監視ステートマシンへの動作指示。動作指示内容として、trueは、この値に変化したことにより、障害監視ステートマシンは監視を開始する。falseは、この値に変化したことにより、障害監視ステートマシンは監視を停止する。
LccMode： 本機能による障害検出時の動作モードを意味する（コマンドにより指定）。動作モードには、shutdown（障害検出時、shutdownするモード）とnoShutdown（障害検出時、shutdownしないモード）がある。
次にポート状態ステートマシン＃１〜＃ｎの関数の定義を示す。
noticeNormalTrap（）： 障害監視を開始した事を示すTRAPを送信する。付加情報として、検出portidを付与する。
noticeFailTrap（）：本機能による障害を検出した事を示すTRAPを送信する。付加情報として、検出portid,障害種別（Rx／Tx／RxTx）を付与する。
LccShutdown（）：ＬＣＣ機能によるshutdownを実行する。
図９、図１０は障害監視ステートマシン＃１〜＃ｎの状態遷移を示す図である。変数の定義を以下に示す。
prevRxCount：直前の周期で収集した受信パケットカウンタの内容を示す。
prevTxCount：直前の周期で収集した送信パケットカウンタの内容を示す。
currRxCount：現周期で収集した受信パケットカウンタの内容を示す。
currTxCount：現周期で収集した送信パケットカウンタの内容を示す。
rxCount：getStatistics関数で収集した受信パケットカウンタの内容を示す。
txCount：getStatistics関数で収集した送信パケットカウンタの内容を示す。
rxFail：受信パケットカウンタの監視が正常か否かを示す変数（障害監視で使用）。
txFail：送信パケットカウンタの監視が正常か否かを示す変数（障害監視で使用）。
rxFail2：受信パケットカウンタの監視が正常か否かを示す変数（復旧監視で使用）。
txFail2：送信パケットカウンタの監視が正常か否かを示す変数（復旧監視で使用）。
timerExp：タイマステートマシンにより、登録されたタイマが満了時、trueに設定される変数。
monTimer：タイマステートマシンに登録されるタイマ変数。タイマステートマシンは、本変数が０以外の時に１秒周期で１減算し、０になるとtimerExpをtrueに設定する。
adminMonTimer：監視タイマとして設定された変数（R2.3では８固定）。
rxCompRslt：compStatistics関数の実行結果が格納される変数（受信パケットカウンタ）。
txCompRslt：compStatistics関数の実行結果が格納される変数（送信パケットカウンタ）。
detectGuardTimes：保護回数連続障害検出判定用変数。
adminGuardTimes：CLIにより指定された保護回数。
次に障害監視ステートマシン＃１〜＃ｎにおける関数の定義を示す。
getStatistics（）：統計情報の受信パケットカウンタと送信パケットカウンタを参照し、その結果を、それぞれrxCount,txCountに格納する。
compStatistics（）：prevRxCountとcurrRxCount／prevTxCountとcurrTxCountを比較し、その結果をそれぞれ、rxCompRslt／txCompRsltに格納する（一致したらtrueを一致しなかったらfalseを設定する）。
failNotics（）：LccOperStatusにfailureを設定する事によりポート状態ステートマシンに障害検出を通知する（rxFail／txFailは付加情報としてポート状態ステートマシンにより参照される）。
recovNotics（）：LccOperStatusにnormalを設定する事によりポート状態ステートマシンに障害復旧の検出を通知する。
制御パラメータ（送信）は、宛先MACアドレス、Ether Type、制御パケット送信間隔（固定：３秒）からなる。制御パラメータ（監視）は、監視タイマ（固定：８秒とし、この時間送受信パケット数のどちらかが変化しない場合、障害と判定する）。動作モード、保護回数からなる。
保守者への通知（TRAP）は、障害を検出したことを通知する。このとき、付加情報として、障害検出ポートや障害種別（Rx／Tx／RxTx）を通知する。また、TRAPにより、障害が復旧したことを通知し、このとき付加情報として、復旧検出ポートを通知する。
保守者への通知（CLI）は、Link Connectivity Check（ＬＣＣ）機能に関する設定状態をコマンドにより、参照可能とする。または監視ポートの状態をコマンドにより、参照可能とする（ポート状態：正常（normal）、障害中（failure）、未知（unknown）、監視無効（disable）。
フィルタリング条件は、受信制御パケットは障害監視用統計情報収集後、廃棄することする。
以上説明したように、障害検出装置１０は、マルチベンダ環境のキャリアネットワークにおけるリンクのサイレント障害の検出に有効であり、ネットワークの耐障害性の向上を図ることが可能になる。特に、障害検出装置１０は、独自機能でありながら、他社装置に何ら変更を必要としないためキャリアにとって、マルチベンダ環境における導入を容易にする。
（付記１） ネットワーク上の障害検出を行う障害検出装置において、
障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置に対して、前記障害監視制御パケットを送信する障害監視制御パケット送信部と、
前記障害監視制御パケットの送信パケット数をカウントする送信パケットカウンタと、
前記対向装置から送信される制御パケットを受信して、受信パケット数をカウントする受信パケットカウンタと、
前記送信パケット数と前記受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する障害検出部と、
を有することを特徴とする障害検出装置。
（付記２） 前記障害監視制御パケット送信部は、装置内の上位レイヤの処理部に配置し、前記送信パケットカウンタは、装置内の前記対向装置と自装置が接続する物理レイヤまたはリンクレイヤの処理部に配置することで、前記障害検出部は、前記送信パケット数の監視を行って、前記上位レイヤと前記物理レイヤの処理部間の経路に発生する障害検出を保証することを特徴とする付記１記載の障害検出装置。
（付記３） 前記受信パケットカウンタは、装置内の上位レイヤの処理部に配置することで、前記障害検出部は、前記受信パケット数の監視を行って、前記対向装置から前記上位レイヤの処理部までの経路に発生する障害検出を保証することを特徴とする付記１記載の障害検出装置。
（付記４） 前記障害監視制御パケット送信部は、ユーザトラフィックが流れていないときであっても、誤った障害検出がされないように、ユーザトラフィックとは独立な前記障害監視制御パケットを常時一定間隔で送信することを特徴とする付記１記載の障害検出装置。
（付記５） 前記障害監視制御パケット送信部は、前記対向装置で受信されたときに廃棄され、ペイロードに制御内容を含まない前記障害監視制御パケットを生成し送信することを特徴とする付記４記載の障害検出装置。
（付記６） 自装置と前記対向装置とが、複数リンクを仮想的な１つのリンクとみなすリンク・アグリゲーションで接続している場合には、前記障害監視制御パケット送信部は、前記複数リンクの各リンクから前記障害監視制御パケットを送信し、前記送信パケットカウンタは、前記複数リンクのリンク毎に送信パケット数をカウントし、前記受信パケットカウンタは、前記複数リンクの各リンクから前記対向装置から送信された制御パケットを受信して、リンク毎に受信パケット数をカウントし、前記障害検出部は、リンク毎に障害検出を行うことを特徴とする付記１記載の障害検出装置。
（付記７） ネットワーク上の障害検出を行う障害検出方法において、
障害監視制御パケットを生成して、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置に対して、前記障害監視制御パケットを送信し、
前記障害監視制御パケットの送信パケット数を、送信パケットカウンタでカウントし、
前記対向装置から送信される制御パケットを、受信パケットカウンタで受信して、受信パケット数をカウントし、
前記送信パケット数と前記受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識して外部へ通知することで、前記対向装置の側で障害の監視を認識することなく、自装置側のみで障害検出を行うことを特徴とする障害検出方法。
（付記８） 装置内の上位レイヤの処理部で障害監視制御パケットの生成、送信を行い、前記送信パケットカウンタは、装置内の前記対向装置と自装置が接続する物理レイヤまたはリンクレイヤの処理部に配置することで、前記送信パケット数の監視により、前記上位レイヤと前記物理レイヤの処理部間の経路に発生する障害検出を保証することを特徴とする付記７記載の障害検出方法。
（付記９） 前記受信パケットカウンタは、装置内の上位レイヤの処理部に配置することで、前記受信パケット数の監視により、前記対向装置から前記上位レイヤの処理部までの経路に発生する障害検出を保証することを特徴とする付記７記載の障害検出方法。
（付記１０） ユーザトラフィックが流れていないときであっても、誤った障害検出がされないように、ユーザトラフィックとは独立な前記障害監視制御パケットを常時一定間隔で送信することを特徴とする付記７記載の障害検出方法。
（付記１１） 前記対向装置で受信されたときに廃棄され、ペイロードに制御内容を含まない前記障害監視制御パケットを生成し送信することを特徴とする付記１０記載の障害検出方法。
（付記１２） 自装置と前記対向装置とが、複数リンクを仮想的な１つのリンクとみなすリンク・アグリゲーションで接続している場合には、前記複数リンクの各リンクから前記障害監視制御パケットを送信し、前記送信パケットカウンタは、前記複数リンクのリンク毎に送信パケット数をカウントし、前記受信パケットカウンタは、前記複数リンクの各リンクから前記対向装置から送信された制御パケットを受信して、リンク毎に受信パケット数をカウントすることで、リンク毎に障害検出を行うことを特徴とする付記７記載の障害検出方法。
障害検出装置の原理図である。 障害検出装置のブロック構成を示す図である。 装置間が１本のリンクで接続された際の障害検出動作を示すシーケンス図である。 装置間がＬＡで接続された際の障害検出動作を示すシーケンス図である。 障害検出装置の機能を有する通信装置の構成を示す図である。 障害監視制御パケットのフォーマットを示す図である。 ポート状態ステートマシンの状態遷移を示す図である。 ポート状態ステートマシンの状態遷移を示す図である。 障害監視ステートマシンの状態遷移を示す図である。 障害監視ステートマシンの状態遷移を示す図である。 ループによるネットワーク障害を説明するための図である。 ループによるネットワーク障害を説明するための図である。 ネットワーク障害検出の流れを示す図である。
符号の説明
１０ 障害検出装置
１１ 障害監視制御パケット送信部
１２ 送信パケットカウンタ
１３ 受信パケットカウンタ
１４ 障害検出部
２０ 対向装置

Claims (5)

  1. ネットワーク上の障害検出を行う障害検出装置において、
    障害監視制御パケットを生成し、自装置と同一プロトコルで障害検出のための相互動作が不要な対向装置に対して、前記障害監視制御パケットを送信する障害監視制御パケット送信部と、
    前記障害監視制御パケットの送信パケット数をカウントする送信パケットカウンタと、
    前記対向装置から送信される、前記送信パケットと同一プロトコルのパケット以外の制御パケットを受信して、受信パケット数をカウントする受信パケットカウンタと、
    前記送信パケット数と前記受信パケット数を監視して、一定時間内に少なくともいずれか一方のパケット数に変化がなければ、障害発生と認識し、外部へ通知する障害検出部と、
    を有することを特徴とする障害検出装置。
  2. 前記障害監視制御パケット送信部は、装置内の上位レイヤの処理部に配置し、前記送信パケットカウンタは、装置内の前記対向装置と自装置が接続する物理レイヤまたはリンクレイヤの処理部に配置することで、前記障害検出部は、前記送信パケット数の監視を行って、前記上位レイヤと前記物理レイヤの処理部間の経路に発生する障害検出を保証することを特徴とする請求項１記載の障害検出装置。
  3. 前記受信パケットカウンタは、装置内の上位レイヤの処理部に配置することで、前記障害検出部は、前記受信パケット数の監視を行って、前記対向装置から前記上位レイヤの処理部までの経路に発生する障害検出を保証することを特徴とする請求項１記載の障害検出装置。
  4. 前記障害監視制御パケット送信部は、ユーザトラフィックが流れていないときであっても、誤った障害検出がされないように、ユーザトラフィックとは独立な前記障害監視制御パケットを常時一定間隔で送信することを特徴とする請求項１記載の障害検出装置。
  5. 自装置と前記対向装置とが、複数リンクを仮想的な１つのリンクとみなすリンク・アグリゲーションで接続している場合には、前記障害監視制御パケット送信部は、前記複数リンクの各リンクから前記障害監視制御パケットを送信し、前記送信パケットカウンタは、前記複数リンクのリンク毎に送信パケット数をカウントし、前記受信パケットカウンタは、前記複数リンクの各リンクから前記対向装置から送信された制御パケットを受信して、リンク毎に受信パケット数をカウントし、前記障害検出部は、リンク毎に障害検出を行うことを特徴とする請求項１記載の障害検出装置。
JP2005039528A 2005-02-16 2005-02-16 障害検出装置 Expired - Fee Related JP4454516B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2005039528A JP4454516B2 (ja) 2005-02-16 2005-02-16 障害検出装置
US11/155,658 US7957267B2 (en) 2005-02-16 2005-06-20 Fault detection device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005039528A JP4454516B2 (ja) 2005-02-16 2005-02-16 障害検出装置

Publications (2)

Publication Number Publication Date
JP2006229477A JP2006229477A (ja) 2006-08-31
JP4454516B2 true JP4454516B2 (ja) 2010-04-21

Family

ID=36815493

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005039528A Expired - Fee Related JP4454516B2 (ja) 2005-02-16 2005-02-16 障害検出装置

Country Status (2)

Country Link
US (1) US7957267B2 (ja)
JP (1) JP4454516B2 (ja)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7925728B2 (en) * 2005-09-08 2011-04-12 International Business Machines Corporation Facilitating detection of hardware service actions
DE102005055148B4 (de) * 2005-11-18 2008-04-10 Siemens Ag Verfahren, Detektionseinrichtung und Servereinrichtung zur Auswertung einer eingehenden Kommunikation an einer Kommunikationseinrichtung
US7711800B2 (en) * 2006-01-31 2010-05-04 Microsoft Corporation Network connectivity determination
US8160062B2 (en) * 2006-01-31 2012-04-17 Microsoft Corporation Network connectivity determination based on passive analysis of connection-oriented path information
US8040895B2 (en) * 2006-03-22 2011-10-18 Cisco Technology, Inc. Method and system for removing dead access control entries (ACEs)
EP1906602B1 (en) * 2006-09-28 2010-03-24 Nokia Siemens Networks Gmbh & Co. Kg Controlling congestion detection in HSDPA systems
US8363555B2 (en) * 2006-10-25 2013-01-29 Cisco Technology, Inc. Monitoring internet protocol (IP) telephony signaling links
CN101018228B (zh) * 2006-12-22 2011-11-23 华为技术有限公司 一种端口聚合方法及装置
JP4762161B2 (ja) * 2007-01-19 2011-08-31 富士通株式会社 ネットワーク装置、ネットワーク冗長接続方法およびネットワーク冗長接続プログラム
JP2008227782A (ja) * 2007-03-12 2008-09-25 Fujitsu Telecom Networks Ltd 回線二重化ｇｅ−ｐｏｎシステム
US8677479B2 (en) * 2007-04-16 2014-03-18 Microsoft Corporation Detection of adversaries through collection and correlation of assessments
JP4852486B2 (ja) * 2007-07-06 2012-01-11 株式会社エヌ・ティ・ティ・ドコモ トラフィック監視システム
US8266489B2 (en) * 2007-10-19 2012-09-11 Ati Technologies Ulc Recovering from a link down event of a two-way serial connection
CN100534024C (zh) * 2007-11-26 2009-08-26 中控科技集团有限公司 基于工业以太网的故障处理方法、系统及一种交换设备
JP5065941B2 (ja) * 2008-02-29 2012-11-07 アラクサラネットワークス株式会社 スイッチ装置およびネットワークシステム
US7860982B2 (en) * 2008-03-14 2010-12-28 Microsoft Corporation Internet connectivity verification
JP5281360B2 (ja) * 2008-10-30 2013-09-04 アズビル株式会社 リング型スイッチングハブ、リング型イーサネットシステム、およびリング接続制御方法
JP2010161494A (ja) * 2009-01-06 2010-07-22 Howa Mach Ltd データ受信システム
JP5029763B2 (ja) 2009-02-03 2012-09-19 富士通株式会社 ネットワーク障害時情報収集装置、方法、及びプログラム
JP5032533B2 (ja) * 2009-06-09 2012-09-26 富士通テレコムネットワークス株式会社 フレーム伝送装置及びフレーム廃棄数測定方法
JP4977190B2 (ja) 2009-11-12 2012-07-18 富士通テレコムネットワークス株式会社 通信装置、インターフェースカードおよび障害対処方法
US8195989B1 (en) * 2010-08-20 2012-06-05 Juniper Networks, Inc. Detection of ethernet link failure
US20120087232A1 (en) * 2010-10-12 2012-04-12 Brocade Communications Systems, Inc. Link state relay for physical layer emulation
JP2012129868A (ja) 2010-12-16 2012-07-05 Nec Corp 通信システム
US9025490B2 (en) * 2011-01-17 2015-05-05 Shahram Davari Network device
JP5665723B2 (ja) 2011-11-29 2015-02-04 アラクサラネットワークス株式会社 パケット中継装置およびシステム、障害検出方法
BR112015007958A2 (pt) * 2012-10-09 2017-07-04 Adaptive Spectrum & Signal Alignment Inc método e sistema para diagnosticar conectividade em sistemas de comunicação
US10212062B2 (en) * 2012-10-09 2019-02-19 Assia Spe, Llc Method and system for latency measurement in communication systems
US9825857B2 (en) 2013-11-05 2017-11-21 Cisco Technology, Inc. Method for increasing Layer-3 longest prefix match scale
US9674086B2 (en) 2013-11-05 2017-06-06 Cisco Technology, Inc. Work conserving schedular based on ranking
US10778584B2 (en) 2013-11-05 2020-09-15 Cisco Technology, Inc. System and method for multi-path load balancing in network fabrics
WO2015069576A1 (en) 2013-11-05 2015-05-14 Cisco Technology, Inc. Network fabric overlay
US9769078B2 (en) 2013-11-05 2017-09-19 Cisco Technology, Inc. Dynamic flowlet prioritization
US9397946B1 (en) 2013-11-05 2016-07-19 Cisco Technology, Inc. Forwarding to clusters of service nodes
US9655232B2 (en) 2013-11-05 2017-05-16 Cisco Technology, Inc. Spanning tree protocol (STP) optimization techniques
US10951522B2 (en) 2013-11-05 2021-03-16 Cisco Technology, Inc. IP-based forwarding of bridged and routed IP packets and unicast ARP
US9686180B2 (en) 2013-11-05 2017-06-20 Cisco Technology, Inc. Managing routing information for tunnel endpoints in overlay networks
US9888405B2 (en) 2013-11-05 2018-02-06 Cisco Technology, Inc. Networking apparatuses and packet statistic determination methods employing atomic counters
US9374294B1 (en) 2013-11-05 2016-06-21 Cisco Technology, Inc. On-demand learning in overlay networks
US9502111B2 (en) 2013-11-05 2016-11-22 Cisco Technology, Inc. Weighted equal cost multipath routing
CN106470128A (zh) * 2015-08-18 2017-03-01 富士通株式会社 故障检测装置和系统
JP6558167B2 (ja) * 2015-09-14 2019-08-14 株式会社Ｊｖｃケンウッド 通信装置、制御方法
CN110943964B (zh) * 2018-09-21 2022-07-22 华为技术有限公司 数据校验方法、装置及存储介质
US11503665B2 (en) 2020-06-02 2022-11-15 Apple Inc. Apparatus and methods for efficient link disconnection determination
CN114501684A (zh) * 2020-11-13 2022-05-13 艾锐势企业有限责任公司 用于自动恢复连接的方法、装置、扩展器和计算机介质

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4567595A (en) * 1983-03-31 1986-01-28 At&T Bell Laboratories Multiline error detection circuit
US5812951A (en) * 1994-11-23 1998-09-22 Hughes Electronics Corporation Wireless personal communication system
JPH09130358A (ja) 1995-10-26 1997-05-16 Nec Eng Ltd 伝送システムにおける故障箇所特定システム
GB2337903B (en) * 1998-05-28 2000-06-07 3Com Corp Methods and apparatus for collecting storing processing and using network traffic data
US6327476B1 (en) * 1998-06-30 2001-12-04 Conexant Systems, Inc. System and method for wireless voice and computer communications using a wireless link to a public telephone network
US6549882B1 (en) * 1998-12-21 2003-04-15 Cisco Technology, Inc. Mechanisms for providing and using a scripting language for flexibly simulationg a plurality of different network protocols
US6327249B1 (en) * 1999-08-04 2001-12-04 Ess Technology, Inc Data communication device
JP3994614B2 (ja) * 2000-03-13 2007-10-24 株式会社日立製作所 パケット交換機、ネットワーク監視システム及びネットワーク監視方法
US6850495B1 (en) * 2000-08-31 2005-02-01 Verizon Communications Inc. Methods, apparatus and data structures for segmenting customers using at least a portion of a layer 2 address header or bits in the place of a layer 2 address header
US7142563B1 (en) * 2001-02-20 2006-11-28 At&T Corp. Service interface for QoS-driven HPNA networks
US6888816B2 (en) * 2001-04-02 2005-05-03 Asustek Computer Inc. Window-based polling scheme for a wireless communications protocol
US7184408B2 (en) * 2001-07-31 2007-02-27 Denton I Claude Method and apparatus for programmable generation of traffic streams
US6996063B2 (en) * 2001-11-16 2006-02-07 Asustek Computer Inc. Applicable PDU range test and calculation for window-based polling
JP2003304264A (ja) 2002-04-08 2003-10-24 Nec Access Technica Ltd Ｌａｎにおけるループバックテスト方法及びループバックテストシステム
WO2003098874A1 (fr) * 2002-05-17 2003-11-27 Allied Telesis Kabushiki Kaisha Concentrateur et procede de gestion de reenclenchement de l'alimentation electrique approprie
US7310356B2 (en) * 2002-06-24 2007-12-18 Paradyne Corporation Automatic discovery of network core type
US7149917B2 (en) * 2002-07-30 2006-12-12 Cisco Technology, Inc. Method and apparatus for outage measurement
US7260066B2 (en) * 2002-10-31 2007-08-21 Conexant Systems, Inc. Apparatus for link failure detection on high availability Ethernet backplane
US7224668B1 (en) * 2002-11-27 2007-05-29 Cisco Technology, Inc. Control plane security and traffic flow management
US7254373B2 (en) * 2003-01-28 2007-08-07 Conexant, Inc. Antenna diversity based on packet errors
US7539489B1 (en) * 2003-04-04 2009-05-26 Veriwave, Incorporated Location-based testing for wireless data communication networks
JP3794580B2 (ja) 2003-07-11 2006-07-05 古河電気工業株式会社 データ中継方法、データ中継装置およびその装置を用いたデータ中継システム
KR100552509B1 (ko) * 2003-10-13 2006-02-14 삼성전자주식회사 이동 애드 혹 네트워크에서의 브로드캐스트 데이터 처리방법
US7424652B2 (en) * 2003-11-19 2008-09-09 Alcatel Lucent Method and apparatus for detection of transmission unit loss and/or replication
US7376404B2 (en) * 2004-04-28 2008-05-20 Lucent Technologies Inc. System and method for detecting a fault in a multiple receiver system
EP1628429A3 (en) * 2004-08-19 2011-06-01 Infineon Technologies AG Method for transmitting information with an acknowledgement scheme and respective communication system
US8060650B2 (en) * 2004-10-27 2011-11-15 Hewlett-Packard Development Company, L.P. Diagnosing a path in a storage network
KR100701105B1 (ko) * 2004-12-22 2007-03-28 한국전자통신연구원 Ｉｐ 기반 네트워크에서 제어채널 구성 및 보호 방법과상태 천이 방법

Also Published As

Publication number Publication date
US20060182036A1 (en) 2006-08-17
JP2006229477A (ja) 2006-08-31
US7957267B2 (en) 2011-06-07

Similar Documents

Publication Publication Date Title
JP4454516B2 (ja) 障害検出装置
JP4128974B2 (ja) レイヤ２ループ検知システム
US20060198315A1 (en) Communication apparatus
EP2082508B1 (en) Monitoring link aggregation links
JP4764420B2 (ja) イーサネット（登録商標）ｏａｍネットワークにおけるアラーム指示および抑制（ａｉｓ）機構
JP4212476B2 (ja) イーサネット上でｓｄｈ／ｓｏｎｅｔ自動保護スイッチングをサポートするための方法
JP4257509B2 (ja) ネットワークシステム、ノード装置、冗長構築方法、および冗長構築プログラム
US8483050B2 (en) Method and apparatus for ethernet ring protection
US6857027B1 (en) Intelligent network topology and configuration verification using a method of loop detection
EP2194676B1 (en) Ethernet ring system, its main node and intialization method
US9270485B2 (en) Method for ethernet ring protection
US9237092B2 (en) Method, apparatus, and system for updating ring network topology information
JP5471240B2 (ja) スイッチ装置、リングネットワークシステム、通信制御方法、および装置のプログラム
US20020159398A1 (en) Spanning tree control unit in the case of trouble or increase and method thereof
JP5862445B2 (ja) 通信装置
CN102238067B (zh) 一种快速环网保护协议环上的切换方法和装置
CN106685783A (zh) 一种环网保护方法和系统
JP4532253B2 (ja) フレーム転送装置及びフレームのループ抑止方法
CN101641915B (zh) 重构通信网络的方法
WO2018171745A1 (zh) 一种用于环网的保护倒换方法及装置
US20080219174A1 (en) Detecting Inactive Links in a Communication Network
JP4659611B2 (ja) パスプロテクション方法及びレイヤ２スイッチ
JP2011223172A (ja) リング型ネットワークシステム、通信装置および障害検出方法
JP5328502B2 (ja) Ｌ２冗長通信装置
JP4137728B2 (ja) ブリッジ装置、及び該装置のブリッジ処理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080111

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090929

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091126

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100202

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100202

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130212

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4454516

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140212

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees