JP4223643B2 - ルータ - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明はルータに関し、更に詳しくはＬＡＮにおけるルータの信頼性向上に関する。
【０００２】
【従来の技術】
図２９は従来のルータの概念図である。ルータ１０は第１のＬＡＮ回線部１と、ルーチング処理部２と、第２のＬＡＮ回線部３と、経路情報制御部４から構成されている。そして、ルータ１０の両端にはサブネットワーク（以下サブネット）が接続される。第１のＬＡＮ回線部１はその一端がサブネットと接続され、他端はルーチング処理部２に一端に接続されている。ルーチング処理部２の他端には第２のＬＡＮ回線部３と経路情報制御部４が接続されている。
【０００３】
このように構成されたシステムにおいて、サブネットからの転送データは、ＬＡＮ回線部１で受信され、ルーチング処理部２に送られる。ルーチング処理部２は、経路情報制御部４が保持するルーチングテーブルを参照してルーチング先を決定し、ＬＡＮ回線部３に送る。ＬＡＮ回線部３はサブネットと接続され、サブネットに転送データを送出する。以上の動作は、第２のＬＡＮ回線部３にサブネットから転送データが入力されてきた場合についても同様である。経路情報制御部４としては、例えばＲＩＰ／ＯＳＰＦ等が用いられる。ＲＩＰ／ＯＳＰＦは、ルーチング情報をダイナミックにルータ間でやりとりして、ルーチングテーブルを作成するためのプロトコルである。
【０００４】
従来より、ルータの高信頼性確保は、各サブネットに複数台のルータを冗長構成で配置し、片方のルータが障害となった場合に、別のルータがルーチング機能を代行する方法がとられている。
【０００５】
図３０は従来のシステムの構成例を示す図である。図において、Ｓｉはサブネット、Ｒはルータである。各サブネットには、ルータが二重化構成で配置されており、冗長構成となっている。特定のサブネットＳ５とＳ６を結ぶルータ間は、ＷＡＮ回線で接続されている。このような構成にしておけば、例えば一方のルータが故障した時には、他方のルータがルーチング動作を続行し、回線が切断されることを防止することができる。この場合、同一サブネット内で冗長構成されたルータ間のみが代行が可能である。なお、従来のルータでは、装置内のトラヒックに拘らず常時、一定の電力が消費されている。
【０００６】
【発明が解決しようとする課題】
冗長構成をとらない場合には、ルータが障害になると、そのルータの配下のサブネットは、他のサブネットと通信できないという問題がある。この問題を解決するために、各サブネットに複数台のルータを配置する冗長構成をとった場合には、通常、ルーチング処理を行なわないサブネットに対しても、ルータのポートを専有することになり、ルータがサポートしているポート数をフルに活用できないため、２倍以上の台数のルータを用意する必要があった。更に、サブネット間を複数のルータで冗長的に接続するためには、ＷＡＮ回線を複数用意することになり、高信頼性確保のためのコストは非常に大きいものになっている。
【０００７】
電力消費に関しても、近年高速化のために、ルーチング機能をハードウェアで行なうルータが増えてきており、ルータの消費電力は増大する傾向にあり、ネットワークの拡大に伴い、夜間等のトラヒック低下時に無駄に消費される電力も無視できないものになってきている。
【０００８】
本発明はこのような課題に鑑みてなされたものであって、各サブネット毎に複数のルータを冗長的に配置することなく、ルータが障害になった時にルーチング動作を継続することが可能で、低コストのルータを提供することを目的としている。
【０００９】
【課題を解決するための手段】
（１）図１は本発明の原理ブロック図で、ルータの構成を示している。図２９と同一のものは、同一の符号を付して示す。図において、１１はルータ内の特定のイベントをもとに動作モードの切り替え契機を検出するモード切り替え契機検出手段、１２は該モード切り替え契機検出手段１１の出力を受けてポート間の接続をルータ動作からリピータ動作に切り替えるリピータモード切り替え手段、１３はＬＡＮ回線部１，３と接続されルータ内の各ポート間を接続し、あるポートから受信したフレームを他の全ポートに送信するリピータ処理部、１４はルーチング処理部２と接続され他のルータがリピータモードに切り替わったことを検出する他装置モード切り替え検出手段、１５は該他装置モード切り替え検出手段１４の出力を受け他のルータ宛のフレームに関するルーチング機能を代行するルーチング代行手段である。
【００１０】
１６はモード切り替え契機検出手段１１と接続され装置内のトラヒック低下を自動的に検出するトラヒック監視手段、１７はルーチング代行手段１５と接続されネットワーク管理プロトコルを使用して、ネットワーク内の各ルータからルーチング代行機能に必要な情報を取得するポート情報取得手段、１８は他装置モード切り替え検出手段１４と接続されルータ動作中に他装置宛のフレームを監視する他装置宛フレーム監視手段、１９はリピータモード切り替え手段１２と接続されネットワークのループ構成を認識するループ検出手段、２０はリピータモード切り替え手段１２と接続されルータがＷＡＮ又は異速度ＬＡＮインタフェースを搭載している場合に、同一メディアのポート間をそれぞれ接続するメディア内接続手段である。図２９に示す従来構成に構成要素１１〜２０が加わったものである。
【００１１】
図で、実線は通常時の動作の流れを、間隔の狭い破線は障害発生時のデータの流れを、間隔の広い波線は制御の流れを示す（以下、同じ）。
モード切り替え契機検出手段１１が切り替え契機を検出すると、リピータモード切り替え手段１２がルータ内の各ポートを固定的に接続して、ルータ動作からリピータ動作に切り替える。ここで、ルータ動作とは宛先ＩＰアドレスに従い、各ポートにフレームを投げ分ける動作であり、リピータ動作は信号がルータをスルーで抜ける垂れ流し動作である。リピータ処理部１３は、各ポートから受信したフレームを他の全ポートに送信する。
【００１２】
他装置モード切り替え検出手段１４が、他のルータがリピータモードに切り替わったことを検出すると、ルーチング代行手段１５はリピータモードになった装置宛のフレームに関するルーチング処理を代行する。従って、隣接ルータより、ある契機で他のルータのルーチング機能を代行することが可能になる。
【００１３】
（２）請求項２記載の発明は、装置内のトラヒック低下を自動的に認識するトラヒック監視手段を具備することを特徴とする。
トラヒック監視手段１６が、トラヒックの低下を検出した場合に、請求項１と同様の方法で、リピータモード切り替え手段１２が自装置をルータモードからリピータモードに切り替える。従って、ルータ内のトラヒック低下を契機として、隣接ルータにルーチング機能を代行させることが可能になる。
【００１４】
（３）請求項３記載の発明は、ネットワーク管理プロトコルを使用して、ネットワーク内の各ルータからルーチング代行機能に必要な情報を取得するポート情報取得手段を具備することを特徴とする。
【００１５】
ポート情報取得手段１７は、ネットワーク管理プロトコルを使用して、ネットワーク内の各ルータからルーチング代行機能で使用する情報を自動的に取得してルーチング代行手段１５に与える。従って、ルーチング代行機能を自動的に行なうことが可能となる。
【００１６】
（４）請求項４記載の発明は、ルータ動作中に他装置宛のフレームを監視する他装置宛フレーム監視手段を具備することを特徴とする。
他装置宛フレーム監視手段１８は、ネットワークを流れるフレームを監視し、予め取得している他のルータのポート情報も参照することで、自装置が直接接続されていないサブネットにおける他のルータ宛のフレームを受信したことを他装置モード切り替え検出手段１４に通知する。他装置モード切り替え検出手段１４は、これを契機に他装置がモードを切り替えたことを認識する。従って、高速かつ確実なモード切り替えが可能となる。
【００１７】
（５）請求項５記載の発明は、ネットワークのループ構成を認識するループ検出手段を具備することを特徴とする。
ループ検出手段１９は、スパニングツリープロトコル等を用いて、予め自装置のポート間のループを検出しておく。ここで、スパニングツリープロトコルとは、ブリッジがツリー状に構成されている時に有効なプロトコルであって、ブリッジがツリー状からループ状になった時に、データがループを無限に中継する状態（ブロードキャストストーム）からループを切ってループから抜け出すためのプロトコルをいう。モード切り替え契機検出手段１１が切り替え契機を検出した時に、リピータモード切り替え手段１２は、ループになっているポートに関しては、代表の１ポートのみを他ポートと接続する。従って、リピータ動作時のループ回避が可能となる。
【００１８】
（６）請求項６記載の発明は、ルータがＷＡＮ又は異速度ＬＡＮインタフェースを搭載している場合に、同一メディアのポート間を各々接続するメディア内接続手段を具備することを特徴とする。
【００１９】
モード切り替え契機検出手段１１が切り替え契機を検出した時に、メディア内接続手段２０は、ルータ内の各ポートのメディアを識別し、メディア毎に接続すべきポートをリピータモード切り替え手段１２に通知する。リピータモード切り替え手段１２は、同一メディア毎にルータ内の各ポートを固定的に接続して、ルータ動作からリピータ動作に切り替える。他装置モード切り替え検出手段１４が、他のルータがリピータモードに切り替わったことを検出すると、ルーチング代行手段１５は異なるメディアのポートから送られてくるリピータモードになった装置宛のフレームに関するルーチング処理を代行する。従って、リピータモード切り替え時に、メディア変換を不要とすることが可能となる。
【００２０】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
図２は本発明が適用されるネットワークシステムの構成例を示す図である。図中、Ｒ１〜Ｒ６はルータ（以下Ｒｘ）、Ｓ１〜Ｓ１０は各ルータＲｘで構成されるサブネット（以下Ｓｘ）である。図では、ルータＲ１に障害が発生した場合に、ルータＲ２でＲ１の代行をする場合を例示している。ルータＲ１は、サブネットＳ１，Ｓ２と接続され、ルータＲ２はサブネットＳ３，Ｓ４と接続されている。Ｒ１とＲ２はサブネットＳ５に接続され、サブネットＳ５はルータＲ３と接続されている。ルータＲ３とＲ４間はＷＡＮ回線で接続され、ルータＲ４はサブネットＳ６と接続されている。
【００２１】
サブネットＳ６はルータＲ５，Ｒ６と接続されている。ルータＲ５はサブネットＳ７，Ｓ８と接続され、ルータＲ６はサブネットＳ９，Ｓ１０と接続されている。
【００２２】
（実施の形態例１）
ＲＩＰ／ＯＳＰＦ等によるダイナミックルーチングを適用したＴＣＰ／ＩＰネットワークを例に取り上げ、ルータ動作が障害で停止する際に本発明を適用する例を示す。ＲＩＰ／ＯＳＰＦは、ルーチング情報をダイナミックにルータ間でやりとりしてルーチングテーブルを作成するプロトコル、ＴＣＰはトランスポート層の通信プロトコル、ＩＰはインターネット層のプロトコルである。
【００２３】
本発明のルータは、ルータ動作が障害等で停止した時にリピータ動作に切り替わる機能と、他ルータがリピータ動作に切り替わった時にルーチング動作を代行する機能の両方を兼ね備える。それぞれの機能は、それぞれ独立して動作する。即ち、障害発生時はリピータ動作、他ルータ障害検出時はルーチング代行動作を行なう。そして、これらルータは、正常時及び代行時に動作するルーチング処理部２、ルーチング代行手段１５（図１参照。以下同じ）と、障害発生時に動作するリピータ処理部１３を実装している。
【００２４】
図３は実施の形態例１の障害発生ルータの動作説明図であり、障害発生時のリピータ動作に必要な手段のみを示している。図１と同一のものは、同一の符号を付して示す。図５は実施の形態例１の代行ルータの動作説明図であり、他ルータ障害検出時のルーチング代行動作に必要な手段のみを示している。
【００２５】
図２において、各ルータが正常動作中の状態では、Ｓ１内及びＳ２内のノードが他サブネットのノードと通信する場合、Ｒ１がルーチング動作を行っている。この状態で、ルータＲ１で障害が発生し、ルータ動作が停止した場合を考える。ルータ動作の障害は、モード切り替え契機検出手段１１で検出する。具体例として、ルーチング処理部２又は経路情報制御部４において、ハードウェア障害或いはソフトウェア障害をハード的に検出する。
【００２６】
障害を検出したモード切り替え契機検出手段１１は、リピータモード切り替え手段１２に障害を通知する。障害通知を受け取ったリピータモード切り替え手段１２は、ハードレジスタ設定等により、正常時にルーチング処理部２に接続されていたルータ内の各ポートをリピータ処理部１３に接続替えし、リピータ動作に切り替える。これにより、フレームの転送が継続できるようになる。この場合、フレームは当該ルータ内をスルーで抜けることになる。
【００２７】
本実施の形態例におけるリピータ処理部１３は、通常のリピータと同様に、接続されたポートから受信したフレームを、そのまま他の全ポートに中継するだけの、単なるハードウェア的な接続を想定しているが、リピータ処理部１３が、受信したフレームを一旦バッファに取り込み、各ポートの速度に合わせてフレームを中継することにより、速度の異なるポート間を接続することも可能であり、メディアの異なるＷＡＮ回線についても、メディア変換を行ない、受信したフレームを接続された全てのポートに対して、各ポートのメディアに合わせてブロードキャストすることで対応可能である。
【００２８】
更に、リピータ処理部１３が、ＭＡＣアドレスを学習して、学習されているＭＡＣアドレスについては、対応するポートだけにフレームを送信するブリッジ機能を持つことにより、ネットワークの負荷を低減することも可能である。
【００２９】
従来方式のルータでは、Ｒ１のルータ動作に障害が発生した場合、Ｓ１内及びＳ２内のノードが自サブネットを越えて他のサブネットのノードと通信することはできなくなる。一方、本発明では、障害が発生したルーチング処理部２等を切り離し、リピータ動作に切り替えることにより、フレーム転送を継続することが可能となる。以上のルータ動作からリピータ動作に切り替わる際の処理の流れを図４の障害発生の動作フローチャートに示す。
【００３０】
図４は実施の形態例１の障害発生ルータの動作フローチャートである。モード切り替え契機検出手段１１において、ルータ動作の障害を検出する（Ｓ１）。次に、リピータモード切り替え手段１２により、ルータ動作からリピータ動作にハード的に切り替える（Ｓ２）。次に、リピータ処理部１３がＬＡＮ回線部から受信したフレームを他ＬＡＮ回線部に転送する（Ｓ３）。
【００３１】
ここで、一つ問題がある。本発明のようにルータ動作からリピータ動作に切り替えるだけでは、実際の通信は継続できない。それは、異なるサブネットが同一物理セグメント上に共存することになり、従来方式のルータでは、うまくルーチング動作ができないためである。
【００３２】
即ち、本実施の形態例では、ルータＲ１がリピータ動作することにより、サブネットＳ１，Ｓ２，Ｓ５が同一セグメント上に存在することになる。この問題を解決するルーチング機能の代行について、図２のＲ２が代行する場合を例にとって説明する。
【００３３】
図２の構成では、Ｒ１から見てＳ５上に隣接ルータはＲ２，Ｒ３の２台存在するが、本発明では、障害発生ルータの隣接ルータの内、１台のルータがルーチングを代行する。どのルータが代行するかの判断は、予め設定しておく形でも可能であり、ＲＩＰ／ＯＳＰＦによる定期的な経路情報のやりとりから取得可能な隣接ルータのＩＰアドレスの大小比較等により自動化することも可能である。
【００３４】
図６は実施の形態例１のルーチングを代行する前のルータＲ２の内部構成説明図である。サブネットＳ５は物理ポート２１と接続され、論理インタフェース２２を介してルーチング処理部２と接続されている。サブネットＳ３は物理ポート２４と接続され、論理インタフェース２３を介してルーチング処理部２と接続されている。サブネットＳ４は物理ポート２６と接続され、論理インタフェース２５を介してルーチング処理部２と接続されている。ルーチング処理部２は、ルーチング代行手段１５と接続されている。この状態では、まだルーチング処理部２がルーチング動作を行なっている。
【００３５】
図２の構成において、各ルータが正常動作中におけるＲ２のインタフェース（ＩＦ）のアドレステーブル状態を図７に示す。各ルータが正常動作中の時、Ｒ２のアドレステーブルは、自装置が直接接続されているサブネットＳ３，Ｓ４，Ｓ５に関する情報しか持っていない。図７に示すテーブルは、ＩＦ名と、対応するＩＰアドレスとＭＡＣアドレスより構成される。例えば、Ｓ３論理ＩＦに対するＩＰアドレスはＲ２のＳ３の論理ＩＦ−ＩＰ、ＭＡＣアドレスはＲ２のＳ３論理ＩＦ−ＭＡＣより構成されている。Ｓ４論理ＩＦとＳ５論理ＩＦについても同様である。
【００３６】
また、各ルータが正常動作中におけるＲ２のルーチングテーブル状態を図８に示す。Ｒ２のルーチングテーブルは、宛先と、送信論理ＩＦと、送信物理ＩＦと、ゲートウェイより構成されている。Ｓ１からＳ１０宛までの各エントリの内、直接接続されているサブネットＳ３，Ｓ４，Ｓ５以外は、ゲートウェイとしてＲ１，Ｒ３のＳ５論理ＩＦのＩＰアドレスが設定されている。
【００３７】
この時のＲ３のルーチングテーブル状態を図９に示す。これも同様に、直接接続されているサブネットＳ５以外は、ゲートウェイとしてＲ１，Ｒ２のＳ５論理ＩＦのＩＰアドレス、或いはＲ４のＳ６論理ＩＦのＩＰアドレスが設定されている。Ｓ６〜Ｓ１０まではＷＡＮ−ＩＦで接続される。従来方式のルータもこの状態で動作する。即ち、図６に示すように、各ルータが正常動作中は、サブネット、物理ポート、論理ＩＦが全て１対１の関係にある。
【００３８】
図１０に正常動作中にＳ１上のノード（以下Ｎ１）がＳ３上のノード（以下Ｎ３）と通信する際の通信シーケンスを示す。先ずＮ１からＲ１にＡＲＰリクエストが送信され（Ｓ１）、Ｒ１からのＡＲＰレスポンスにより、Ｒ１のＳ１論理ＩＦのＭＡＣアドレスを解決する（Ｓ２）。解決するとは、ＩＰアドレスに対応したＭＡＣアドレスを取得することである。その後、Ｒ１にＮ３宛のＩＰフレームが送信される（Ｓ３）。
【００３９】
Ｒ１は、ルーチングテーブルを検索し、Ｎ３宛のフレームのゲートウェイとして、Ｒ２のＳ５論理ＩＦのＩＰアドレスを抽出する（Ｓ４）。Ｒ１からＲ２にＡＲＰリクエストが送信され（Ｓ５）、Ｒ２からのＡＲＰレスポンスにより、Ｒ２のＳ５論理ＩＦのＭＡＣアドレスを解決する（Ｓ６）。次に、Ｒ１からＲ２にＮ３宛のフレームが中継される（Ｓ７）。
【００４０】
その後、Ｎ３はＲ２の直接接続のサブネットのため、Ｎ３のＩＰアドレスを抽出する（Ｓ８）。次に、Ｒ２からＮ３にＡＲＰリクエストが送信され（Ｓ９）、Ｎ３からのＡＲＰレスポンスにより、Ｎ３のＭＡＣアドレスを解決する（Ｓ１０）。そして、最後にＲ２からＮ３にＮ３宛のＩＰフレームが中継される（Ｓ１１）。以上のようにして、Ｎ３宛のフレームは、Ｎ１→Ｒ１→Ｒ２→Ｎ３のように、Ｒ１，Ｒ２の２台のルータを経由する。
【００４１】
次に、Ｒ１が障害によりリピータ動作に切り替わってから、Ｒ２がＲ１のルーチングを代行するまでの動作を説明する。図５はルーチングを代行するＲ２の動作説明図である。Ｒ１が障害によりリピータ動作に切り替わった場合、他装置モード切り替え検出手段１４において、Ｒ１がリピータ動作に切り替わったことを検出する。検出する方法としては、Ｒ２からＰｉｎｇ等による定期的なヘルスチェック等が考えられる。ここで、Ｐｉｎｇとは、パケットを相手方に投げてその応答が帰ってくるかどうかをチェックするものである。
【００４２】
切り替えを検出した場合、他装置モード切り替え検出手段１４からルーチング代行手段１５に通知され、自分が代行するか否か判断する。この場合、前述の事前設定或いは隣接ルータのＩＰアドレスの大小比較等により、自分が代行すると判断することとする。
【００４３】
図１１は代行ルータの内部構成説明図である。図６と同一のものは、同一の符号を付して示す。図において、３０はＳ１代行ＩＦ、３１はＳ５代行ＩＦ、３２はＳ２代行ＩＦであり、それぞれ物理ポート２１とルーチング処理部２間に設けられている。Ｓ１代行ＩＦ３０は、ルータＲ１のＳ１のＩＰアドレス／ＭＡＣアドレス、Ｓ５代行ＩＦ３１は、ルータＲ１のＳ５のＩＰアドレス／ＭＡＣアドレス、Ｓ２代行ＩＦ３２は、ルータＲ１のＳ２のＩＰアドレス／ＭＡＣアドレスを自ＩＦのアドレスとして使用してフレームの送受信を行う。
【００４４】
自分が代行すると判断したルーチング代行手段１５は、Ｒ１が直接接続されているサブネットＳ１，Ｓ２，Ｓ５の代行ＩＦを生成する。図１２は生成される代行ＩＦのアドレステーブルの状態を示す。この際、使用するＩＰアドレス／ＭＡＣアドレスは、Ｒ１のＳ１，Ｓ２，Ｓ５の各論理ＩＦのＩＰアドレス／ＭＡＣアドレスである。Ｒ１のアドレスを取得する方法としては、Ｒ２に予め設定しておく等が考えられる。
【００４５】
また、Ｓ１，Ｓ２，Ｓ５の代行ＩＦに関しては、代行フラグを立て、代行用のアドレステーブルであるかどうかを識別する。ルーチング代行手段１５は、更に経路情報制御部４に、Ｓ１，Ｓ２宛の代行用ルーチングテーブル生成を要求する。図１３に生成される代行用ルーチングテーブルの状態を示す。図８に示す正常動作中のテーブルと比べて違う部分は、Ｓ１宛／Ｓ２宛のエントリの送信論理ＩＦがＳ１代行ＩＦ／Ｓ２代行ＩＦになっていることと、ゲートウェイがＲ１の論理ＩＦのＩＰアドレスではなく、ゲートウェイ無し（Ｒ２がＳ１，Ｓ２に直接接続されているイメージ）になっていることである。また、代行フラグを立てて保持し、代行用のルーチングテーブルかどうかを識別する。
【００４６】
以上により、Ｒ２はＲ１の代行ルータになる。
次に、代行ルータになったＲ２における経路情報制御の流れを説明する。
Ｒ２のルーチングテーブルにおけるＳ１宛／Ｓ２宛のエントリは、Ｒ１のＳ５論理ＩＦを代行するＳ５代行ＩＦ３１を介してＲＩＰ、ＯＳＰＦ等のルーチングプロトコルを使用してＳ５上の隣接ルータＲ３に通知され、Ｒ３から更にＲ４，Ｒ５，Ｒ６に通知される。Ｓ３宛／Ｓ４宛のエントリは、Ｓ５論理ＩＦ２２を介してＳ５上の隣接ルータＲ３に通知され、Ｒ３から更にＲ４，Ｒ５，Ｒ６に通知される。
【００４７】
逆に、Ｓ１宛／Ｓ２宛以外のエントリは、Ｒ１のＳ１論理ＩＦ／Ｓ２論理ＩＦを代行するＳ１代行ＩＦ３０、Ｓ２代行ＩＦ３２を介してＳ１／Ｓ２方面に通知される。Ｓ６〜Ｓ１０宛のエントリは、Ｒ３からＳ５論理ＩＦ２２を介して受け取る。
【００４８】
以上により、Ｓ１，Ｓ２，Ｓ５上の接続ルータにあたかもＲ１が存在しているかのように見せかける。
図１４に、代行ルータとなったＲ２等とやりとりする経路情報により生成される、Ｒ３におけるルーチングテーブ状態を示す。図９と比較して異なるところは、Ｓ１宛／Ｓ２宛のエントリのゲートウェイが、Ｒ１−Ｓ５論理ＩＦ−ＩＰアドレスか、Ｒ２−Ｓ５代行ＩＦ−ＩＰアドレスかの部分のみである。しかしながら、Ｒ２−Ｓ５代行ＩＦ−ＩＰアドレスは、Ｒ１−Ｓ５論理ＩＦ−ＩＰアドレスを使用しているため、Ｒ３のルーチングテーブルは、Ｒ２がＲ１の代行をする前後で全く同じ状態である。即ち、Ｒ２が代行する場合、Ｒ３は従来のルータとして動作すればよい。
【００４９】
以上、Ｒ１が障害によってリピータ動作に切り替わってから、Ｒ２がＲ１の代行ルータになるまでの処理の流れを図１５の代行ルータの動作フローチャートに示す。先ず、他装置モード切り替え検出手段１４において、他ルータの障害（リピータ処理に切り替え）を検出する（Ｓ１）。次に、ルーチング代行手段１５において、自分が代行ルータになるべきか否かを判断する（Ｓ２）。そして、代行すべきかどうかチェックする（Ｓ３）。
【００５０】
代行すべきである場合には、ルーティング代行手段１５により、代行ＩＦの生成後、経路情報制御部４へ代行が必要な経路情報の制御を要求する（Ｓ４）。次に、ルーチング処理部２がルーチング代行手段１５及び経路情報制御部４により作成されたテーブルに従い、ルーチングを代行する（Ｓ５）。
【００５１】
図１６にＲ２がＲ１の代行動作中にＳ１上のノード（以下Ｎ１）がＳ３上のノード（以下Ｎ３）と通信する際の通信シーケンスを示す。ここで、ルータＲ１はリピータ動作機能のみとなり、信号をスルーで通過させるだけの機能となっている。先ず、Ｎ１からＲ２（Ｓ１代行ＩＦ３０ 図１１参照）にＡＲＰリクエストが送信され（Ｓ１）、Ｒ２からのＡＲＰレスポンスにより、Ｒ２のＳ１代行ＩＦ３０のＭＡＣアドレス（Ｒ１のＳ１論理ＩＦのＭＡＣアドレス）を解決する（Ｓ２）。
【００５２】
その後、Ｒ２（Ｓ１代行ＩＦ３０）にＮ３宛のＩＰフレームが送信される（Ｓ３）。Ｎ３は、Ｒ２の直接接続サブネットのため、Ｎ３のＩＰアドレスを抽出する（Ｓ４）。次に、Ｒ２からＳ３論理ＩＦ２３を介して、Ｎ３にＡＲＰリクエストが送信され（Ｓ５）、Ｎ３からのＡＲＰレスポンスにより、Ｎ３のＭＡＣアドレスを解決する（Ｓ６）。そして、最後に、Ｒ２からＮ３に、Ｎ３宛のＩＰフレームが中継される（Ｓ７）。
【００５３】
以上説明したように、Ｎ１はＲ１がリピータ動作に切り替わっても、デフォルトゲートウェイ等の設定を変更せずに、Ｎ３との通信が可能である。Ｎ３宛のフレームは、Ｎ１→Ｒ１（リピータ動作）→Ｒ２（代行ルータ）→Ｎ３のようにＲ２の１台のルータを経由する。
【００５４】
以上の方法により、障害発生等でルータがリピータ動作に切り替わることが可能となる。また、あるルータがリピータ動作に切り替わった時、その隣接ルータがルーチングを代行することが可能となる。
【００５５】
（実施の形態例２）
図１７は実施の形態例２におけるリピータ動作をするＲ１の動作説明図、図１８は実施の形態例２におけるＲ１の動作フローチャートである。図１７において、図１と同一のものは、同一の符号を付して示す。図１７において、１６はモード切り替え契機検出手段１１と接続され、装置内のトラヒック低下を自動的に認識するトラヒック監視手段である。その他の構成は、図５に示すそれと同じである。ここでは、Ｒ１において装置内のトラヒック低下を検出し、リピータ動作をする場合を考える。
【００５６】
装置内のトラヒック低下は、トラヒック監視手段１６により検出する。トラヒック監視は以下のように実施する。
トラヒック低下を判断する情報は、装置内のＭＩＢ（ＲＦＣ１２１３：ＭＩＢ−II）を利用する。ここで、ＭＩＢとは、ネットワーク管理のために標準化された各種管理情報のことである。
【００５７】
受信オクテット総数（ＩｆＩｎＯｃｔｅｔｓ）→インタフェース毎の情報
送信オクテット総数（ＩｆＯｕｔＯｃｔｅｔｓ）→インタフェース毎の情報
上記情報から、装置内のある時刻Ｘから時刻Ｙにおけるトラヒック（利用率）を算出する。
【００５８】
時刻ＸＹ間総送受信バイト数＝（ＹのＩｆＩｎＯｃｔｅｔｓ−ＸのＩｆＩｎＯｃｔｅｔｓ）＋（ＹのＩｆＯｕｔＯｃｔｅｔｓ−ＸのＩｆＯｕｔＯｃｔｅｔｓ）
毎秒総送受信バイト数＝時刻ＸＹ間総送受信バイト数／（Ｙ−Ｘ）
利用率＝（毎秒総送受信バイト数×８）／Ｉｆｓｐｅｅｄ（インタフェース の速度）
インタフェース毎に上記利用率を算出し、全インタフェースの平均利用率を算出する。平均利用率（ｂｐｓ）と事前に設定したトラヒックしきい値を比較し、
平均利用率＜トラヒックしきい値
となった場合に、トラヒック低下と判断し、モード切り替え契機検出手段１１に通知され、リピータモード切り替え手段１２によりリピータ動作に切り替える。なお、モード切り替え契機検出手段１１以降の動作は、実施の形態例１と同様である。
【００５９】
また、Ｒ１がリピータ動作に切り替わった後のルーチングの代行は、前述したようにＲ２により行なわれる。動作は、実施の形態例１に示すものと同様である。なお、この場合、全ルータがリピータ動作になるのを防ぐため、動作切り替えをしない（代行ルータ）設定を用意している。この場合、Ｒ２に設定しておく。
【００６０】
また、上記平均利用率を算出するパラメータとして、以下の設定が可能とする。
利用率算出間隔（Ｘ−Ｙ間の時間）
トラヒックしきい値（ｂｐｓ）
切り替え許容時間帯（Ａ時Ｂ分〜Ｃ時Ｄ分）
監視対象インタフェース（複数指定可能）
また、トラヒック低下を判断する情報として、装置内でサポートするＲＭＯＮ１−ＭＩＢ（ＲＦＣ１７５７）のｓｔａｔｉｃｓ（セグメント単位の統計量）又はＲＭＯＮ２−ＭＩＢ（ＲＦＣ２０２１）のｐｒｏｔｏｃｏｌＤｉｓｔ（プロトコル毎）／ｎｌＨｏｓｔ（ホスト毎）統計量の利用も可能である。
【００６１】
次に、図１８について説明する。トラヒック監視手段１６において、装置内のトラヒックを周期的に監視する（Ｓ１）。次に、平均使用率＜トラヒックしきい値であるかどうかチェックする（Ｓ２）。そうでない場合には、ステップＳ１に戻る。そうである場合には、トラヒック監視手段１６がモード切り替え契機検出手段１１にトラヒック低下を通知する（Ｓ３）。モード切り替え契機検出手段１１は、リピータモード切り替え手段１２に通知して、動作モードをそれまでのルーチングモードからリピータモードに切り替える（Ｓ４）。
【００６２】
この実施の形態例によれば、ルータ内のトラヒック低下を契機として、隣接ルータにルーチング機能を代行させることが可能になる。
（実施の形態例３）
図１９は実施の形態例３における代行ルータＲ２の動作説明図、図２０は実施の形態例３におけるＲ２の動作フローチャートである。図１９において、図１と同一のものは、同一の符号を付して示す。図において、１７はネットワーク管理プロトコルを使用して、ネットワーク内の各ルータからルーチング代行機能に必要な情報を取得するポート情報取得手段で、ルーチング代行手段１５と接続されている。その他の構成は、図５と同様である。
【００６３】
図２において、各ルータのネットワーク管理（ＳＮＭＰ）エージェント機能が動作している状態で、Ｒ１がリピータ動作に切り替わり、Ｒ２が代行ルータとなる際に必要となるＲ１のＩＰアドレス／ＭＡＣアドレス等のポート情報をＳＮＭＰプロトコルにより取得することにより、設定無しで自動的に代行を可能とする場合を考える。
【００６４】
代行に必要なＲ１のポート情報は、ポート情報取得手段１７により取得する。ルーチング代行動作に必要なポート情報としてインタフェース毎に以下のものがある。
【００６５】
ＩＰアドレス
ＩＰサブネットマスク
ＩＰブロードキャストアドレス
ＭＡＣアドレス
ポート情報取得手段１７は、隣接ルータの上記情報を、ＳＮＭＰプロトコルを使用し、定期的に収集する。ＳＮＭＰ通信用のＩＰアドレスは、ＲＩＰ／ＯＳＰＦ等でやりとりされる経路制御情報の送信元ＩＰアドレス（この場合、Ｒ１のＳ５論理ＩＦのＩＰアドレス）を使用する。定期的に収集するのは、収集後にＩＰアドレス等の設定変更がある場合に対応するためである。
【００６６】
具体的には、ルータＲ１のＩＰアドレスが設定されたインタフェース毎に以下のＭＩＢ（ＲＦＣ１２１３：ＭＩＢ−ＩＩ）を収集する。収集情報は以下の通りである。
【００６７】
ＩｐＡｄＥｎｔＡｄｄｒ（ＩＰアドレス）
ＩｐＡｄＥｎｔＮｅｔＭａｓｋ（ＩＰサブネットマスク）
ＩｐＡｄＥｎｔＢｃａｓｔＡｄｄｒ（ＩＰブロードキャストアドレス）
ＩｆＰｈｙｓＡｄｄｒｅｓｓ（ＭＡＣアドレス）
ポート情報取得手段１７は、収集した情報を保持し、Ｒ１がリピータ動作に切り替わり、自分が代行ルータになる際に備える。
【００６８】
次に、図２０のフローチャートについて説明する。ポート情報取得手段１７は、隣接ルータのポート情報を定期的に収集する（Ｓ１）。それと並行して、隣接ルータのモード切替えを監視し（Ｓ２）、隣接ルータがリピータモードに切り替わった場合には収集したポート情報を使用して代行動作する（Ｓ３）。これにより、実施の形態例１で示したＲ１のポート情報を予め設定することによる方法と比べ、設定無しで自動的に代行に必要な情報を解決し、代行することが可能となる。
【００６９】
（実施の形態例４）
図２１は実施の形態例４における代行ルータＲ２の動作説明図、図２２は実施の形態例４におけるＲ２の動作フローチャートである。図２１において、１７はルータ動作中に他装置宛のフレームを監視する他装置宛フレーム監視手段で、他装置モード切り替え検出手段１４と接続されている。その他の構成は、図５と同様である。
【００７０】
図２において、Ｒ１がリピータ動作に切り替わり、Ｒ２が代行ルータとなる際に他装置宛フレームを監視することにより、高速かつ確実なモード切り替えを可能とする場合を考える。
【００７１】
他装置宛フレーム監視手段１８は、他装置宛フレームを監視し、Ｒ１がリピータ動作に切り替わったことを検出する。Ｒ１がルータ動作中は、図２中のＳ１及びＳ２上のＲ１宛（Ｒ１のＳ１／Ｓ２論理ＩＦのＭＡＣアドレス宛）の以下のようなフレームは、Ｒ２（Ｓ５上）まで流れてこない。
【００７２】
・Ｓ１／Ｓ２上のノードがＲ１のＭＡＣアドレスを求めるために送信するＲ１のＩＰアドレスに対するＡＲＰリクエストフレーム（宛先ＭＡＣアドレスはブロードキャストアドレス）
・Ｓ１／Ｓ２上のノードが他サブネット上のノード宛に送信するＩＰフレーム (宛先ＩＰアドレスは他サブネット上のノード、宛先ＭＡＣアドレスはＲ１)
Ｒ１がリピータ動作に切り替わった後、上記フレームは、Ｒ１からＳ５上まで流れてきてＲ２が受信することになる。Ｒ３にもフレームは届くが、代行ルータでない場合には廃棄する。
【００７３】
従来のルータであれば、上記フレーム（本来Ｒ１宛のフレーム）を受信した場合、フレームが廃棄されるが、Ｒ２では他装置宛フレーム監視手段１８が上記フレームの受信を監視し、上記フレームの場合には、Ｒ１がリピータ動作に切り替わったと判断し、他装置モード切り替え検出手段１４に通知する。それをトリガとして、ルーチング代行手段１５に指示し、Ｒ２が代行ルータとなる。他装置モード切り替え検出後から代行ルータになるまでの動作は、実施の形態例１と同様である。
【００７４】
次に、図２２について説明する。他装置宛フレーム監視手段１８において、隣接ルータ宛のフレームを監視する（Ｓ１）。次に、フレーム受信を監視し（Ｓ２）、フレームを受信した場合には、他装置宛フレーム監視手段１８から他装置モード切り替え手段１４に通知される（Ｓ３）。次に、他装置モード切り替え手段１４からルーチング代行手段１５に通知し、代行動作を開始する（Ｓ４）。
【００７５】
この実施の形態例によれば、実施の形態例１で示したＰｉｎｇ等による定期的なヘルスチェックによる方法に比べ、上記のフレームを受信した時点で即代行ルータに切り替わるため、ユーザーの通信を止めることなく、継続させることが可能となる。従って、高速かつ確実なモード切り替えが可能となる。
【００７６】
（実施の形態例５）
図２３は実施の形態例５のネットワーク構成図、図２４は実施の形態例５におけるリピータ動作をするＲ１の動作説明図、図２５は実施の形態例５におけるＲ１の動作説明図である。
【００７７】
図２３において、ループを構成しているＲ１，Ｒ２にて、Ｒ２がリピータ動作中にＲ１がリピータ動作に切り替わる場合を考える。図２３において、Ｒ１及びＲ２がリピータ動作に切り替わった場合、Ｓ２及びＳ５の接続経路がループになり、無限にデータ転送を繰り返し、或いはシステムがストップするブロードキャストストームが発生するという問題がある。これを回避するのが、図２４のループ検出手段１９である。
【００７８】
全ルータのループ検出手段１９において、リピータ動作への切り替え前（ルータ動作中）に、仮想的にブリッジとして動作しているかのようにＳＴＰ（スパニングツリープロトコル）を動作させておき、ブリッジレベルでのループを事前に把握しておく。
【００７９】
若し、ブリッジレベルでループが検出された場合、ＳＴＰにより優先度の最も低いインタフェースがブロッキング状態（フレームの送受信をカット）で保持される。図２３においては、Ｒ２がリピータ動作中であるため、Ｒ１のＳ２論理ＩＦ、又はＳ５論理ＩＦのどちらかがブロッキング状態となる。この場合、Ｓ２論理ＩＦがブロッキング状態とする。
【００８０】
この状態で、Ｒ１がリピータ動作に切り替わる際、Ｒ１のリピータモード切り替え手段１２は、ループ検出手段１９が保持しているＳＴＰ情報をチェックし、Ｓ２論理ＩＦ非接続を認識する。リピータモード切り替え手段１２は、Ｓ２論理ＩＦ以外のポートをリピータ処理部に接続する。
【００８１】
次に、図２５のフローチャートの説明をする。先ず、ループ検出手段１９がループを検出した場合（Ｓ１）、ループ検出手段１９は、必要なポートをブロッキング状態とし、ループを回避する（Ｓ２）。次に、モード切り替え契機検出手段１１がモード切り替え契機を検出した場合（Ｓ３）、モード切り替え契機検出手段１１は、リピータモード切り替え手段１２に通知する（Ｓ４）。リピータモード切り替え手段１２は、ループ検出手段１９の状態を参照し、ブロッキング状態以外のポートをリピータ処理部１３に接続する。
【００８２】
この実施の形態例によれば、システムがリピータ動作に切り替わっても、ブロードキャストストームが発生することを回避することが可能となる。
（実施の形態例６）
図２６は実施の形態例６におけるネットワーク構成図、図２７は実施の形態例６における同一メディアのポート間を各々接続するＲ３の動作説明図、図２８は実施の形態例６におけるＲ３の動作フローチャートである。
【００８３】
図２７において、２０はルータがＷＡＮ又は異速度ＬＡＮインタフェースを搭載している場合に、同一メディアのポート間をそれぞれ接続するメディア内接続手段である。３１は対向ルータと接続されるＷＡＮ回線部であり、ルーチング処理部２と接続されている。３２は対向ルータと接続されるＷＡＮ回線部であり、ルーチング処理部２と接続される。
【００８４】
図２６において、Ｒ３が障害となった時に、Ｒ２がＲ３の代行を行なう場合を考える。Ｒ３はＲ４とＡＴＭやＩＳＤＮ等のＷＡＮ回線で接続されており、Ｒ３とＲ２の間も同一メディアのＷＡＮ回線で接続することにより、冗長構成をとっている。また、Ｒ３はＳ５及びＳ１１と１００ＢＡＳＥ−ＴＸ等の同一メディアのＬＡＮ回線で接続されている。
【００８５】
Ｒ３が障害となった場合、実施の形態例１では、全てのＬＡＮポート及びＷＡＮポートがリピータ処理部１３と接続され、どのポートから受信したフレームも他の全てのＬＡＮポート及びＷＡＮポートに転送される。この時、ポートのメディアが異なるため、受信したフレームを一旦バッファに蓄積して、送信ポートのメディアに合わせてメディア変換を行ない送信することになる。
【００８６】
本実施の形態例の構成では、Ｒ３のモード切り替え契機検出手段１１が、ルータ動作の障害を検出すると、メディア内接続手段２０が各ポートのメディアを識別し、メディア毎にポートを接続するために、どのポート間を接続すればよいかをリピータモード切り替え手段１２に通知し、リピータモード切り替え手段１２は、同一メディアであるＬＡＮ回線１−ＬＡＮ回線２間及びＷＡＮ回線１−ＷＡＮ回線２間（図２６参照）を各々接続してリピータモードに切り替える。
【００８７】
リピータ処理部１３は、ＬＡＮ回線１から受信したフレームはＬＡＮ回線２に送信し、ＬＡＮ回線２から受信したフレームはＬＡＮ回線１に送信する。また、ＷＡＮ回線に関しても同様にフレームの転送を行なう。代行ルータであるＲ２は、実施の形態例１と同様の方法でＲ３のルーチング処理を代行する。
【００８８】
例えば、Ｓ１からＳ６に対するフレームは、Ｓ１−Ｒ１−Ｓ５−Ｒ２−Ｒ３−Ｒ４−Ｓ６という経路で転送される。Ｓ１からＳ１１に対するフレームは、Ｓ１−Ｒ１−Ｓ５−Ｒ２−Ｓ５−Ｒ３−Ｓ１１という経路で転送される。
【００８９】
次に、図２８について説明する。先ず、モード切り替え契機検出手段１１において、ルータ動作の障害を検出する（Ｓ１）。次に、メディア内接続手段２０は、メディア毎に接続すべきポートをリピータモード切り替え手段１２に通知する（Ｓ２）。次に、リピータモード切り替え手段１２により、ＬＡＮ回線部間、ＷＡＮ回線部間を各々接続して、ルータ動作からリピータ動作にハードウェア的に切り替える（Ｓ３）。リピータ処理部１３がＬＡＮ回線部から受信したフレームを他ＬＡＮ回線部に転送し、ＷＡＮ回線部から受信したフレームを他ＷＡＮ回線部に転送する。
【００９０】
この実施の形態例によれば、障害になったルータがメディア変換機能を持たなくても、メディアの異なる回線間のルーチングを行なうことが可能となる。
【００９１】
【発明の効果】
以上説明したように、本発明によれば、以下の効果が得られる。
（１）請求項１記載の発明によれば、各サブネット毎に複数のルータを冗長的に配置することなく、ルータが障害になった時にルーチング動作を継続することが可能となり、低コストによる信頼性向上が可能となる。
【００９２】
（２）請求項２記載の発明によれば、夜間、休日等の低トラヒック時に代行動作による縮退運用に切り替えることにより、ルータの消費電力を低く抑えることが可能となる。
【００９３】
（３）請求項３記載の発明によれば、各ルータに代行ルーチングに必要なポート情報を予め設定することなく運用することが可能となり、ネットワーク構築及び構成変更時の労力削減や、設定ミスによる誤動作防止に大きく寄与することができる。
【００９４】
（４）請求項４記載の発明によれば、ヘルスチェック等のやり方に比べて、ネットワークのトラヒックを増大させることなく、素早く、かつ確実に切り替えを行なうことが可能となる。
【００９５】
（５）請求項５記載の発明によれば、ループ構成においてもリピータ動作を行なうことが可能となり、複数ルータによる冗長構成との混在や、複雑なネットワークにおいても、信頼性の向上や省電力を実現することが可能となる。
【００９６】
（６）請求項６記載の発明によれば、ＷＡＮや速度の異なるＬＡＮポート間のリピータ動作を、メディア変換無しに単純に接続可能となり、請求項１に示すルータを使用した場合のコストダウン及び信頼性の向上が可能となる。
【００９７】
このように、本発明によれば、各サブネット毎に複数のルータを冗長的に配置することなく、ルータが障害になった時にルーチング動作を継続することが可能で、低コストのルータを提供することができる。
【図面の簡単な説明】
【図１】本発明の原理ブロック図である。
【図２】本発明が適用されるネットワークシステムの構成例を示す図である。
【図３】実施の形態例１の障害発生ルータの動作説明図である。
【図４】実施の形態例１の障害発生ルータの動作フローチャートである。
【図５】実施の形態例１の代行ルータの動作説明図である。
【図６】実施の形態例１の代行ルータの代行前の内部構成説明図である。
【図７】実施の形態例１の正常動作中のＲ２のＩＦのアドレステーブル状態を示す図である。
【図８】実施の形態例１の正常動作中のＲ２のルーチングテーブル状態を示す図である。
【図９】実施の形態例１の正常動作中のＲ３のルーチングテーブル状態を示す図である。
【図１０】実施の形態例１の正常動作中のＳ１←→Ｓ３間の通信シーケンスを示す図である。
【図１１】実施の形態例１の代行ルータの内部構成説明図である。
【図１２】実施の形態例１のＲ１障害発生時のＲ２のＩＦのアドレステーブル状態を示す図である。
【図１３】実施の形態例１のＲ１障害発生時のＲ２（代行ルータ）のルーチングテーブル状態を示す図である。
【図１４】実施の形態例１のＲ１障害発生時のＲ３のルーチングテーブル状態を示す図である。
【図１５】実施の形態例１の代行ルータの動作フローチャートである。
【図１６】実施の形態例１の代行動作におけるＳ１←→Ｓ３間の通信シーケンスを示す図である。
【図１７】実施の形態例２の動作説明図である。
【図１８】実施の形態例２の動作フローチャートである。
【図１９】実施の形態例３の動作説明図である。
【図２０】実施の形態例３の動作フローチャートである。
【図２１】実施の形態例４の動作説明図である。
【図２２】実施の形態例４の動作フローチャートである。
【図２３】実施の形態例５のネットワーク構成を示す図である。
【図２４】実施の形態例５の動作説明図である。
【図２５】実施の形態例５の動作フローチャートである。
【図２６】実施の形態例６のネットワーク構成例を示す図である。
【図２７】実施の形態例６の動作説明図である。
【図２８】実施の形態例６の動作フローチャートである。
【図２９】従来のルータの概念図である。
【図３０】従来のシステム構成例を示す図である。
【符号の説明】
１ ＬＡＮ回線部
２ ルーチング処理部
３ ＬＡＮ回線部
４ 経路情報制御部
１０ ルータ
１１ モード切り替え契機検出手段
１２ リピータモード切り替え手段
１３ リピータ処理部
１４ 他装置モード切り替え検出手段
１５ ルーチング代行手段
１６ トラヒック監視手段
１７ ポート情報取得手段
１８ 他装置宛フレーム監視手段
１９ ループ検出手段
２０ メディア内接続手段

Claims (6)

1. ルータ内の特定のイベントをもとに動作モードの切り替え契機を検出するモード切り替え契機検出手段と、
   ポート間の接続をルータ動作からリピータ動作に切り替えるリピータモード切り替え手段と、
   ルータ内の各ポート間を接続し、あるポートから受信したフレームを他の全ポートに送信するリピータ処理部と、
   他のルータがリピータモードに切り替わったことを検出する他装置モード切り替え検出手段と、
   他のルータ宛のフレームに関するルーチング機能を代行するルーチング代行手段
   とを具備し、ある契機で他のルータのルーチング機能を代行することを特徴とするルータ。
2. 装置内のトラヒック低下を自動的に認識するトラヒック監視手段を具備することを特徴とする請求項１記載のルータ。
3. ネットワーク管理プロトコルを使用して、ネットワーク内の各ルータからルーチング代行機能に必要な情報を取得するポート情報取得手段を具備することを特徴とする請求項１乃至２の何れかに記載のルータ。
4. ルータ動作中に他装置宛のフレームを監視する他装置宛フレーム監視手段を具備することを特徴とする請求項１記載のルータ。
5. ネットワークのループ構成を認識するループ検出手段を具備することを特徴とする請求項１記載のルータ。
6. ルータがＷＡＮ又は異速度ＬＡＮインタフェースを搭載している場合に、同一メディアのポート間を各々接続するメディア内接続手段を具備することを特徴とする請求項１記載のルータ。

Images