JP6162658B2 - 通信機器、及び回線障害の検出方法 - Google Patents

通信機器、及び回線障害の検出方法 Download PDF

Info

Publication number
JP6162658B2
JP6162658B2 JP2014142471A JP2014142471A JP6162658B2 JP 6162658 B2 JP6162658 B2 JP 6162658B2 JP 2014142471 A JP2014142471 A JP 2014142471A JP 2014142471 A JP2014142471 A JP 2014142471A JP 6162658 B2 JP6162658 B2 JP 6162658B2
Authority
JP
Japan
Prior art keywords
server
communication
packet
processing unit
dhcp
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.)
Active
Application number
JP2014142471A
Other languages
English (en)
Other versions
JP2016019230A (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.)
NEC Platforms Ltd
Original Assignee
NEC Platforms 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 NEC Platforms Ltd filed Critical NEC Platforms Ltd
Priority to JP2014142471A priority Critical patent/JP6162658B2/ja
Publication of JP2016019230A publication Critical patent/JP2016019230A/ja
Application granted granted Critical
Publication of JP6162658B2 publication Critical patent/JP6162658B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、通信機器、及び回線障害の検出方法に関し、特にDHCPを用いた動的IPアドレス環境における回線障害の検出及び復旧に関する。
DHCP(Dynamic Host Configuration Protocol、RFC2131)というIPアドレス(Internet Protocol Address)の配布方式が知られている。このDHCP方式は、主にLAN(Local Area Network)での利用が進んでいる。
特許文献1には、IPアドレスの割り当てをまだ受けていないときに、DHCPサーバに対して割り当て要求を行って、IPアドレスを取得することが記載されている。例えば、ファクシミリ複合装置がネットワークを介してDHCPサーバ等に接続されており、ファクシミリ複合装置の再起動時等に、既に割り当てられているIPアドレスと同一のIPアドレスの割り当てをDHCPサーバに要求することなどが記載されている。
特開2008−124542号公報
DHCPを用いた動的IPアドレス環境において、回線障害を検出する方法としては、DHCPにて定期的に実行されるアドレス更新の結果にて判断するものがある。しかしながら、DHCPのリース時間は一般的に数時間と長く、通信障害が発生したタイミングで即時に異常を検出するには不向きである。
また、DHCPを利用せずに、ICMP(Internet Control Message Protocol)等の監視パケットを送信することで回線の正常性を確認する手段も存在する。しかしながら、正常性の保証されたICMPの送信先を指定するのは困難であり、且つインターネット上では、ICMPがブロックされるケースもあり、ICMPを利用できないケースが存在する。
したがって本発明の目的は、DHCPを用いた動的IPアドレス環境において、速やかに回線の障害を検出し復旧させることのできる、通信機器、及び回線障害の検出方法を提供することにある。
前記目的を達成するため、本発明に係る通信機器は、アクセス回線を経由して通信ネットワーク上のサーバと通信を行う通信機器であって、
接続されるクライアントから上記サーバへの通信に利用されるデータパケットと、上記サーバから上記クライアントへの通信に利用されるデータパケットとを計測するパケット計測部と、上記サーバへ、DHCP(Dynamic Host Configuration Protocol)のIPアドレス(Internet Protocol Address)更新を要請するDHCP処理部と、上記データパケットの計測結果から、上記クライアントから上記サーバへの片方向通信を検出すると、上記DHCP処理部へDHCPのIPアドレス更新処理を行うよう指示するリカバリ処理部と、を有する。
本発明に係る回線障害の検出方法は、アクセス回線を経由して通信ネットワーク上のサーバと通信を行う通信機器の回線障害の検出方法であって、
接続されるクライアントから上記サーバへの通信に利用されるデータパケットと、上記サーバから上記クライアントへの通信に利用されるデータパケットとを計測し、
上記データパケットの計測結果から、上記クライアントから上記サーバへの片方向通信を検出すると、上記サーバへ、DHCP(Dynamic Host Configuration Protocol)のIPアドレス(Internet Protocol Address)更新を要請する。
本発明は、データパケットの計測によるパケット通信量の監視と、DHCPのIPアドレス更新機能とを組み合わせて用いることにより、DHCPを用いた動的IPアドレス環境において、速やかに回線の障害を検出し復旧させることができる。
(a)は本発明が適用される代表的な通信システムの構成を示すブロック図であり、(b)はそのルータ101の構成の一例を示すブロックである。 本発明が適用される代表的な通信システムの構成を示すブロック図である。 本発明の第1実施形態によるルータの構成を示すブロック図である。 図2の通信システムにおける回線障害の発生場所を示すブロック図である。 本発明の第1実施形態による異常検出から復旧までの動作を示すフロー図である。 本発明の第2実施形態による通信システムの構成と回線障害の発生場所を示すブロック図である。 本発明の第2実施形態によるIPsecを利用するルータの構成を示すブロック図である。
本発明の好ましい実施形態について、図面を参照しながら詳細に説明する。本発明は、通信回線の異常や動的なIPアドレス環境におけるIPアドレスの変更を、トラフィック計測結果より、IPアドレスを付与する方法として用いられるDHCPを用いて検出し、正常な通信を復旧させるまでの時間を短縮することを特徴とする。
図1(a)は、本発明が適用される代表的な通信システムの構成を示すブロック図である。本発明の通信機器の一例として、図1(a)においてはルータ101を示す。ルータ101はFTTH(Fiber To The Home)やモバイル回線等のアクセス回線を経由して、通信ネットワークの一例としてのインターネット上のDHCPサーバ(サーバ301)から、IPアドレスの付与を受ける。そして、クライアント201はインターネット上のWEBサーバ(サーバ302)と通信を行う。図1(a)の通信システムでは、ルータ101が直接アクセス回線を収容しており、インターネット上のDHCPサーバ(サーバ301)からIPアドレスを取得する。
その場合は、ルータ101にてOSI参照モデルのレイヤ3ネットワーク(IP層)のIPアドレスの変更や、レイヤ2ネットワーク(データリンク層)のプロトコルや接続状態などを把握することができる。
図1(b)は、図1(a)のルータ101の構成の一例を示すブロックである。図1(b)に示すように、ルータ101は、双方向のパケット通信量を計測するパケット計測手段121と、サーバ301からDHCPアドレスを取得するためのDHCP処理手段122と、これらを制御するリカバリ処理手段123と、を有する。
アクセス回線やサーバ301等に障害が発生した場合、クライアント201からの通信は片方向通信となる。ルータ101は一定時間の片方向通信を検出した場合に、DHCPのIPアドレス更新(RENEW)パケットを送信し、サーバ301からの応答の有無を確認することで、アクセス回線やサーバ301の障害を検出することが特徴である。
また、サーバ301からのDHCP応答の内容によって、正常な通信を復旧させるための修復手段を選択する仕組みを有することも特徴である。
本実施形態のルータ101の動作として、回線障害の検出方法及び復旧方法について説明する。パケット計測手段121は、クライアント201からサーバ302方向のパケット転送処理及びサーバ302からクライアント201方向のパケット転送処理の双方向のパケット送受信量を測定する。このパケットの計測結果からリカバリ処理手段123が、クライアント201からサーバ301への片方向通信を検出すると、DHCP処理手段122がサーバ301へDHCPのIPアドレス更新を要請するように、リカバリ処理手段123が指示を出す。IPアドレス更新の要請として、DHCP処理手段122がサーバ301へ、DHCPのIPアドレス更新(RENEW)パケットを送信する。そして、IPアドレス更新パケットの送信に対する、サーバ301からの応答の有無を確認することで、アクセス回線やサーバ301の障害を検出できる。
一方、図1(a)の通信システムとは異なる通信システムも用いられている。図2は、本発明が適用される代表的な通信システムの他の構成を示すブロック図である。図2では、ルータ101は直接アクセス回線を収容しない。近年は図2のように、ルータ101が直接アクセス回線を収容せず、通信端末401のような機器が介在して異なる通信方式でルータ101とサーバ301を接続するような方式が増えている。この場合、インターネットへの接続性をルータ101が直接把握できないという課題がある。
図1(a)のアクセス回線がモバイル回線でない場合、一般的に、アクセス回線の課金がパケット通信量に依存せずに一定額である。これに対し、図2のような通信端末401が収容するアクセス回線がモバイル回線の場合は、パケット通信量が増えることによって、回線費用が増加したり、利用できる通信速度に制限がかかったりする制約がついてしまう。よって、パケットの送信量を減少させたいニーズがある。
本発明は、トラフィック流量の監視により監視パケットを不要とする方法と、アクセス回線上で常時利用可能なDHCPを組み合わせることにより、機能面とコスト面で最適な障害検出方法を取ることが可能となる。以下、より具体的に説明する。
〔第1実施形態〕
次に、本発明の第1実施形態による通信機器、回線障害の検出方法及び復旧方法について、説明する。本実施形態では通信機器の一例として、図2のルータ101を示す。本発明の具体的な実施形態については、図2のようなルータ101が直接アクセス回線を収容せず、通信端末401のような機器が介在して異なる通信方式でルータ101とサーバ301を接続する通信システムの場合を例に、説明する。
図2を参照すると、ルータ101がデータ通信カード(通信端末401)を介してアクセス回線(モバイル回線)を経由し、ゲートウェイ装置(サーバ301)を介して、通信ネットワークの一例としてのインターネットに接続している例が示されている。このような構成により、クライアント201がインターネット上のサーバ302と通信を行う。
ルータ101は、通信端末401を介してアクセス回線に接続し、サーバ301からインターネットへ接続するためのIPアドレスをDHCPにて付与されている。
ルータ101とサーバ301間において、回線や機器の異常が発生して通信できなくなるとクライアント201からサーバ302への通信ができなくなる。クライアント201からはサーバ302への通信を試みるため、ルータ101上では、クライアント201からサーバ302方向には通信が発生するが、異常発生中は通信できない。このため、サーバ302へ通信は届かず、応答も返ってこないため、ルータ101上ではサーバ302からクライアント201方向の通信は発生しないため、片方向通信の状態が発生する。
ルータ101は、定期的に双方向のパケット通信量を計測しており、片方向通信が発生している状態を検出すると、サーバ301に対してDHCPの更新パケットを送信する。更新パケットの応答が無い場合は、回線に異常が発生しているとルータ101は判断し、通信端末401に対して、アクセス回線に対する再接続を行うように動作し、復旧を試みる。
図3は、本発明の第1実施形態による通信機器の構成を示すブロック図である。図3では、ルータ101にて異常検出及びリカバリ動作を行うための構成が示されている。ルータ101は、ルータ101が通信端末401を介してモバイル回線へアクセスするためのモバイル通信処理部114と、モバイル回線へのアクセスが完了した後に、サーバ301からDHCPアドレスを取得するためのDHCP処理部113と、を有する。さらに、ルータ101は、通信端末401に接続されるポート131と、クライアント201に接続されるポート132と、パケット計測部112と、リカバリ処理部115と、ルーティング処理部111と、を有する。
クライアント201からサーバ302方向のパケット転送処理については、次のとおりである。ポート132は、クライアント201から送信されたパケットを受信する。ルーティング処理部111は、クライアント201からのサーバ302への通信に利用されるデータパケットを、ポート131に転送する。ポート131は、このデータパケットを通信端末401に出力する。
パケット計測部112は、クライアント201からサーバ302方向のパケット転送処理及びサーバ302からクライアント201方向のパケット転送処理の双方向のパケット送受信量を測定する。リカバリ処理部115は、ルーティング処理部111、パケット計測部112、DHCP処理部113、及びモバイル通信処理部114からの情報を保持し制御を行う。
また、クライアント201からのサーバ302への通信に利用されるデータパケットは、クライアント201から送信されたパケットをルータ101のポート132にて受信する。受信したデータパケットは、ルーティング処理部111にてポート131に転送され、通信端末401に出力される。サーバ302からクライアント201方向のパケット転送処理はその逆となる。パケット計測部112は、これら双方向のパケット送受信量を測定する。さらに、各処理部(111〜114)からの情報を保持し制御を行う、リカバリ処理部115を有する。
次に、本実施形態の動作として、回線障害の検出方法及び復旧方法を、図面を参照して説明する。図4のような、通信端末401とアクセス回線(モバイル回線)との間での障害が発生した場合について説明する。この場合、ルータ101の内部動作は次のようになる。図5は、本発明の第1実施形態による異常検出から復旧までの動作を示すフロー図である。正常通信が行える状態までの動作と異常発生から復旧までの動作を示す。また、各処理部(112、113、114)がリカバリ処理部115に通知する状態情報については、(表1)にて内容を示す。
(表1)

Figure 0006162658
(表1)の状態情報について、ひととおり説明する。パケット計測値の状態20Nは、パケット計測部112が測定したパケットカウンタのN回目の情報である。パケット計測値の状態20Nは、最新の、ポート131の送信パケットカウンタと、最新の、ポート131の受信パケットカウンタである。パケット計測値の状態20Nは、パケット計測間隔(状態210)毎にN回目としてカウンタ情報を更新する。
パケット計測値の状態20N−1は、パケット計測部112が測定したパケットカウンタのN−1回目の情報である。パケット計測値の状態20N−1は、前回の、ポート131の送信パケットカウンタと、前回の、ポート131の受信パケットカウンタである。パケット計測値の状態20N−1は、パケット計測間隔(状態210)毎にN回目としてカウンタ情報を更新する。
DHCP状態の状態30Nは、DHCP処理部113にて取得したIPアドレス情報である。DHCP処理部113にてDHCP処理が実施された結果を、実施回数N回毎に更新する。取得不可の場合は(0.0.0.0)として記録する。DHCP状態の状態30N−1は、DHCP処理部113にて取得したIPアドレス情報のN−1回目の結果である。
モバイル回線状態の状態40Nは、モバイル回線の状態である。モバイル回線状態の状態40Nは、モバイル通信処理部114が接続処理を実施した毎に更新する。状態としては、UP/DOWNの2種類が存在する。
パケット計測間隔の状態210は、パケット計測部112が計測する間隔(秒)である。
パケット通信量の状態221は、パケット計測間隔の時間あたりの送信パケット数である。パケット通信量の状態221は、状態20Nと状態20N−1の差分より算出される。
パケット通信量の状態222は、パケット計測間隔の時間あたりの受信パケット数である。パケット通信量の状態222は、状態20Nと状態20N−1の差分より算出される。
以下、具体的な動作について説明する。最初に、ルータ101のモバイル通信処理部114が通信端末401に対して、モバイル回線の接続処理を実施し、接続可否の結果を状態401としてルータ101のリカバリ処理部115に通知する。
モバイル回線の接続が完了した場合、次にDHCP処理部113がサーバ301に対して、DHCPによるIPアドレス取得を行い、サーバ301から取得したIPアドレスを状態301として、リカバリ処理部115に通知する。IPアドレスが取得できた場合、通信可能状態となり、パケット計測部112によるポート131のパケット計測が開始される。パケット計測部112が計測を実行する間隔(時間)は、リカバリ処理部115に記録された状態201の間隔にて実行される。
リカバリ処理部115は、パケット計測部112からN回目に通知される状態20Nと、N−1回目に通知される状態20N−1を保持し、その差分からパケット計測間隔(状態201)の間のパケット送受信量を算出する。ここで、Nは2以上の自然数である。
回線状態が異常状態となった場合には、リカバリ処理部115にてパケット送受信量の差分として保持される送信パケット数(状態221)と受信パケット数(状態222)の値が、状態221はゼロでない値となり、状態222がゼロとなる。この状態を片方向通信として検出する。
リカバリ処理部115が片方向通信を検出すると、DHCP処理部113に対して、DHCP更新処理を行うよう指示を出し、DHCP処理部113はサーバ301に対してDHCPのアドレス更新を行う。
回線障害が発生している場合は、これに対しサーバ301から応答が届かない。このため、DHCPのアドレス更新ができずIPアドレスが取得不可となり、DHCP処理部113はリカバリ処理部115に対して状態302としてIPアドレス取得不可の状態(0.0.0.0)を通知する。
リカバリ処理部115は状態301と状態302の結果を比較し不一致の結果が出た場合には、異常状態と判断してリカバリ処理を実行する。状態302の結果がIPアドレス取得不可の場合は、ルータ101とサーバ301の隣接区間にて障害が発生したと判断する。回線の再接続を行うため、モバイル通信処理部114に対して再接続を実行するよう、リカバリ処理部115は指示を出す。
リカバリ処理部115は状態301と状態302の結果を比較し、状態302と状態301の値が同じ場合は正常状態として、その後の処理は行わない。
モバイル通信処理部114は、リカバリ処理部115からの再接続指示を受け、通信端末401に対して、回線の切断、再接続の処理を実行する。次にDHCP処理部113がサーバ301に対して、DHCPによるIPアドレス取得を行い、サーバ301から取得したIPアドレスを状態303として、リカバリ処理部115に通知する。
リカバリ処理部115は、状態302と状態303の結果を比較し、不一致の結果が出るが、前回状態302がIPアドレス取得不可(0.0.0.0)であるため、正常状態への復帰として正常性確認ができたと判断する。
正常性確認ができた後は、パケット計測部112の処理が再開し、監視を継続する。すなわち、パケット計測部112によるポート131のパケット計測が再開される。リカバリ処理部115は、パケット計測部112からN+1回目に通知される状態20N+1と、N回目に通知される状態20Nを保持し、その差分からパケット計測間隔の間のパケット送受信量を算出する。
本発明の本実施形態では、異常発生を検出するための判断材料として、パケット通信量の監視による片方向通信の検出機能と、隣接区間において常時利用が可能なDHCPのアドレス更新機能とを組み合わせて用いることにより、以下の効果が期待できる。
1.DHCPの更新時間(リースタイム)に関わらず、異常発生から短時間で回線障害の検出が可能である。これにより、回線障害の検出から短時間で復旧処理が可能である。
2.DHCPの更新機能を用いることで、パケットフィルタリング等のネットワーク側の制限に関わらず、回線の正常性が確認できる。
3.パケット量の監視により、回線の正常性を確認するための余分なパケットを送信する必要がなくなり、特にパケット量に応じた従量課金回線における、コスト削減が可能である。回線の正常性を確認するための余分なパケットとは、例えばICMP監視によるパケットである。
〔第2実施形態〕
次に、本発明の第2実施形態による通信機器、回線障害の検出方法及び復旧方法について、説明する。本実施形態では通信機器の一例として、図6のルータ101を示す。本実施形態は、ルータ101とルータ102の間で、IPsec等を用いた暗号化通信を行う構成のものである。
図6は、本発明の第2実施形態による通信システムの構成と回線障害の発生場所を示すブロック図である。図7は、本実施形態によるIPsecを利用するルータの構成を示すブロック図である。図7のルータ101について、図3に示される第1実施形態のルータ101と同様な構成については同じ参照番号を付して、詳細な説明は省略することとする。
図7のルータ101は、図3のルータ101と同様に、アクセス回線の異常検出及びリカバリ動作を行う。図7のルータ101は、ルータ101が通信端末401を介してモバイル回線へアクセスするためのモバイル通信処理部114と、モバイル回線へのアクセスが完了した後に、サーバ301からDHCPアドレスを取得するためのDHCP処理部113と、を有する。さらにルータ101は、ポート131、132と、パケット計測部112と、リカバリ処理部115と、ルーティング処理部111と、を有する。さらに、図7のルータ101は、暗号化通信処理部の一例としてのIPsec処理部116を有する。
一般的に、ルータ101配下のクライアント201がインターネット上のサーバ302と通信を行う場合は、図7のルータ101のポート131から送信される場合にIPアドレスの変換が行われる。ルータ101に付与されるIPアドレス状態303の値が変化しても、サーバ302は不特定のIPアドレスからの接続を前提としている場合が多く、クライアント201とサーバ302間の通信は正常に行うことが可能である。
一方、図6に示される、クライアント201とサーバ303とで通信を行う場合を考える。サーバ303は、ルータ102を介してインターネットに接続される。ルータ101とルータ102間で暗号化通信を行う場合、ルータ101とルータ102間では、暗号化通信のためのIPsecトンネル501のセッションを確立し、トンネル501の状態を維持する必要がある。この場合、ルータ101側のIPアドレスが変更されると、暗号化通信を行うことができなくなる。
一般的に、ルータ101のポート131の接続状態が、一旦切断状態となった後に再度接続状態になる場合は、IPアドレスが変更された場合はIPsecのトンネル501を切断し、新たなIPsecトンネルを構築することが可能となる。
しかし、通信端末401の動作によっては、ルータ101のポート131の接続状態が一旦切断状態にならない場合でも、IPアドレスが変更されてしまう可能性が否定できない。その場合は、対向のルータ102とIPsecによる通信ができなくなる。
よって、リカバリ処理部115がDHCP処理部113より通知されたIPアドレス(状態30N)が(0.0.0.0)でなく、状態30N−1と差分があった場合、リカバリ処理部はIPsec処理部116に対してIPsecの切断及び再接続を行うように指示を出す。
本実施形態によれば、第1実施形態と同様に、異常発生を検出するための判断材料として、パケット通信量の監視による片方向通信と、隣接区間において常時利用が可能なDHCPのアドレス更新機能を組み合わせて用いることにより、以下の効果が期待できる。
1.DHCPの更新時間(リースタイム)に関わらず、異常発生から短時間で回線障害の検出が可能である。これにより、回線障害の検出から短時間で復旧処理が可能である。
2.DHCPの更新機能を用いることで、パケットフィルタリング等のネットワーク側の制限に関わらず、回線の正常性が確認できる。
3.パケット量の監視により、回線の正常性を確認するための余分なパケットを送信する必要がなくなり、特にパケット量に応じた従量課金回線における、コスト削減が可能である。回線の正常性を確認するための余分なパケットとは、例えばICMP監視によるパケットである。
一般的なIPsec通信においては正常性を確認するために、状態を確認する機能(dpd-keepaliveやICMPを利用)が存在するが、定常的にパケット通信を行う必要があり、従量課金のモバイル回線を利用する場合においては、費用増を伴ってしまう。
これに対し本発明の本実施形態を利用することにより、一般的なIPsec通信と比較して、正常性確認のためのパケット送信量を減少させつつ、異常発生から短時間で回線障害の検出することが可能になる。その結果、コスト低減を図る効果を得ることができる。
以上、本発明の好ましい実施形態を説明したが、本発明はこれに限定されるものではない。上述した本発明の第1実施形態及び第2実施形態では、図2のようなルータ101が直接アクセス回線を収容せず、通信端末401のような機器が介在して異なる通信方式でルータ101とサーバ301を接続する通信システムの場合を例に、説明した。本発明はこのような通信システムへの適用に限定されるものではなく、図1に示される、ルータ101が直接アクセス回線を収容して、インターネット上のDHCPサーバ(サーバ301)からIPアドレスを取得するものにも適用できる。特許請求の範囲に記載した発明の範囲内で、種々の変形が可能であり、それらも本発明の範囲に含まれることはいうまでもない。
101、102 ルータ
111 ルーティング処理部
112 パケット計測部
113 DHCP処理部
114 モバイル通信処理部
115 リカバリ処理部
116 IPsec処理部
201 クライアント
301、302、303 サーバ
401 通信端末
501 トンネル

Claims (8)

  1. アクセス回線を経由して通信ネットワーク上のサーバと通信を行う通信機器であって、
    接続されるクライアントから前記サーバへの通信に利用されるデータパケットと、前記サーバから前記クライアントへの通信に利用されるデータパケットとを計測するパケット計測部と、
    前記サーバへ、DHCP(Dynamic Host Configuration Protocol)のIPアドレス(Internet Protocol Address)更新を要請するDHCP処理部と、
    前記データパケットの計測結果から、前記クライアントから前記サーバへの片方向通信を検出すると、前記DHCP処理部へDHCPのIPアドレス更新処理を行うよう指示するリカバリ処理部と、を有する通信機器。
  2. 前記パケット計測部は、前記サーバへのパケット送信量がゼロでない値となり前記サーバからのパケット受信量がゼロとなる状態をもって、前記片方向通信を検出する、請求項1に記載の通信機器。
  3. 前記通信ネットワーク上の前記サーバと暗号化通信を行う暗号化通信処理部をさらに有する、請求項1又は請求項2に記載の通信機器。
  4. 前記データパケットの計測結果から、前記クライアントから前記サーバへの片方向通信を検出すると、前記リカバリ処理部は、暗号化通信処理部へ暗号化通信の切断及び再接続を行うように指示する、請求項3に記載の通信機器。
  5. アクセス回線を経由して通信ネットワーク上のサーバと通信を行う通信機器の回線障害の検出方法であって、
    接続されるクライアントから前記サーバへの通信に利用されるデータパケットと、前記サーバから前記クライアントへの通信に利用されるデータパケットとを計測し、
    前記データパケットの計測結果から、前記クライアントから前記サーバへの片方向通信を検出すると、前記サーバへ、DHCP(Dynamic Host Configuration Protocol)のIPアドレス(Internet Protocol Address)更新を要請する、回線障害の検出方法。
  6. 前記サーバへのパケット送信量がゼロでない値となり前記サーバからのパケット受信量がゼロとなる状態をもって、前記片方向通信を検出する、請求項5に記載の回線障害の検出方法。
  7. 前記通信ネットワーク上の前記サーバと暗号化通信を行う、請求項5又は請求項6に記載の回線障害の検出方法。
  8. 前記データパケットの計測結果から、前記クライアントから前記サーバへの片方向通信を検出すると、暗号化通信の切断及び再接続を行う、請求項7に記載の回線障害の検出方法。
JP2014142471A 2014-07-10 2014-07-10 通信機器、及び回線障害の検出方法 Active JP6162658B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014142471A JP6162658B2 (ja) 2014-07-10 2014-07-10 通信機器、及び回線障害の検出方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014142471A JP6162658B2 (ja) 2014-07-10 2014-07-10 通信機器、及び回線障害の検出方法

Publications (2)

Publication Number Publication Date
JP2016019230A JP2016019230A (ja) 2016-02-01
JP6162658B2 true JP6162658B2 (ja) 2017-07-12

Family

ID=55234128

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014142471A Active JP6162658B2 (ja) 2014-07-10 2014-07-10 通信機器、及び回線障害の検出方法

Country Status (1)

Country Link
JP (1) JP6162658B2 (ja)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4137371B2 (ja) * 2000-12-28 2008-08-20 富士通株式会社 アドレス管理装置及びアドレス管理方法
JP4869057B2 (ja) * 2006-12-27 2012-02-01 富士通株式会社 ネットワーク接続復旧方法及びaaaサーバ及び無線アクセス網ゲートウェイ装置
JP5362026B2 (ja) * 2009-10-27 2013-12-11 株式会社東芝 通信障害要因推定方法、その推定方法を備えた通信装置およびプログラム
JP2014007609A (ja) * 2012-06-25 2014-01-16 Hitachi Ltd 仮想化システム、通信装置及びネットワーク障害監視方法

Also Published As

Publication number Publication date
JP2016019230A (ja) 2016-02-01

Similar Documents

Publication Publication Date Title
TWI642282B (zh) 錯誤恢復方法及應用其之物聯網系統與充電系統
KR102156687B1 (ko) 다중 경로 연결을 확립하기 위한 방법 및 멀티 홈 장비
US10187284B2 (en) Communication device, server device, communication method, and non-transitory computer readable medium
JP2006013827A (ja) パケット転送装置
WO2009089713A1 (fr) Procédé de transmission d'un message bfd, procédé et dispositif de détection d'une défaillance de liaison
JP5419907B2 (ja) ネットワークシステム、及び通信復旧方法
JP2015534150A5 (ja)
JP2015170286A (ja) 接続管理装置、通信システム、接続管理方法およびプログラム
JP2010283427A (ja) Lac装置及びフェイルオーバ方法
US20190342200A1 (en) Methods, systems, and computer readable media for multiple bidirectional forwarding detection (bfd) session optimization
US20100332631A1 (en) Communication apparatus, address setting method, and address setting program
US9419876B2 (en) Methods and apparatus to determine network delay with location independence from retransmission delay and application response time
JP6222367B2 (ja) 通信装置、通信システムおよび通信方法
JP4344336B2 (ja) マルチホーミング認証通信システム、マルチホーミング認証通信方法、および管理サーバ
JP6162658B2 (ja) 通信機器、及び回線障害の検出方法
TWI586125B (zh) Field machine
CN108270593A (zh) 一种双机热备份方法和系统
JP4413897B2 (ja) 監視方法、監視装置、監視プログラム及び監視システム
JP6303302B2 (ja) 通信制御システム、中継装置及び通信制御プログラム
JP7158826B2 (ja) 通信制御装置、通信制御システム及び通信制御方法
JP6798349B2 (ja) 通信システム及び中継装置
JP6750950B2 (ja) 通信装置および通信方法
JP6728981B2 (ja) ノード装置、および通信システム
JP6248018B2 (ja) Lac装置及びフェイルオーバ方法
CN104753699A (zh) 一种链路故障处理方法和装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20151117

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160912

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161011

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161208

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: 20170523

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170615

R150 Certificate of patent or registration of utility model

Ref document number: 6162658

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150