クラシックなADCルーティングモデルはマルチテナントネットワークには不十分です。
クラシックなADC製品では、ルート管理は通常単一のグローバルテーブルに依存します。小規模のデプロイメントでは十分ですが、マルチテナント、マルチ部門、MSP、政府ネットワーク、DMZ/内部分離、またはデータセンター移行シナリオではすぐに限界に達します。
最初の問題はIPの重複です。異なる顧客、部門、環境が同じプライベートIPブロックを使用する場合があります。2つの別々のテナントが両方とも10.0.0.0/8を使用することは現実世界では非常に一般的です。単一のグローバルルートテーブルでは同じアプライアンス上でその2つのネットワークをクリーンに分離できません。
2つ目の問題は静的と動的ルーティングが別々のデバイスに分散していることです。ルーターがBGP/OSPFでルートを学習しながらADCが独自の静的テーブルを参照している場合、トラフィック決定の半分が一方のデバイスにあり、もう半分が別のデバイスにあります。これによりデバッグが大幅に長くなります — ADCが正しく転送しているか、ルーターが正しいルートを学習したか、リターンパスはどこから来るかをすべて個別に調査する必要があります。
3つ目の問題はデフォルトゲートウェイへの依存です。ゲートウェイは物理的にアップして見えながらアップストリームに到達できない場合があります。クラシックなセットアップではこれを検出しません。トラフィックは健全に見えるが実際には到達不能なゲートウェイに送り続けられます。
4つ目の問題はソースベースまたはポリシーベースルーティングの必要性です。一部のトラフィックはWAN1経由、一部はVPNトンネル経由、一部のテナントトラフィックは専用MPLSリンク経由、一部のサービスはインターネット出口経由でなければなりません。ADCがグローバルルートテーブルのみでこれを管理している場合、オペレーターはCLI、スクリプト、または外部ルーターに依存せざるを得ません。
TR7 ADCはルートテーブルモデルをADCの中心に置きます：すべてのテナントとネットワークゾーンが独自のルーティング決定を行い、静的ルート、動的ルート、ゲートウェイ監視、サービスフローがすべて単一のコンソールから管理されます。
アプローチ
TR7はルーティングをグローバルテーブルから取り出します — 各ネットワークゾーンが独自の独立したルートテーブルに存在します。
TR7ルートテーブル分離
TR7では、ルートテーブルは単なるルートのリストではありません。どのインターフェースからトラフィックが来るか、どのゲートウェイに転送されるか、どのセキュリティルールを通過するか、どのバックエンドに到達するかを決定する別々のネットワークコンテキストです。このモデルにより複数の独立したネットワークゾーンが同じアプライアンス上で実行でき、それぞれが独自のIPプラン、ゲートウェイ、静的ルート、動的ルーティング動作を持ちます。
静的と動的ルーティングが一緒に
TR7 UIを通じて宛先ネットワーク、ゲートウェイ、インターフェース、メトリックを選択して静的ルートを定義できます。より高度なデプロイメントでは、BGP、OSPF、RIP、IS-ISなどの動的ルーティングプロトコルも同じルートテーブルコンテキストで実行できます。管理トラフィックを静的ルートで固定し、本番トラフィックを動的に学習されたパスに従わせることができます — 両方とも同じアプライアンス上の同じガバナンスモデルと同じ運用ビューで。
ポリシーベースルーティング
TR7は宛先IPだけでなくポリシーシグナルによってもトラフィックをステアリングすることをサポートします。特定のvServiceフローを冗長WANに、特定のテナントのトラフィックを専用リンクに、マークされたフローを別のルートテーブルに送ることができます。これは冗長WAN、アクティブ/アクティブインターネット出口、テナントごとのリンク分離、サービスごとのルート選択、インライントランジットシナリオに特に価値があります。
ゲートウェイ監視と自動フェイルオーバー
TR7はデフォルトゲートウェイが実際に到達可能かどうかを追跡できます。設定された回数の失敗チェックの後、ゲートウェイはアンヘルシーとマークされ、代替ルートまたは代替ゲートウェイを有効化できます。これはゲートウェイはアップだがアップストリームはダウンのシナリオをキャッチするために重要です。トラフィックが暗闇に送られることはありません — TR7は実際の到達可能性に基づいて決定します。
機能
TR7ルートテーブルモデルは、マルチテナントデプロイメントと複雑なネットワークトポロジーに必要なすべてのルーティング機能を一つにまとめます。
ルートテーブルごとの独立したルーティング
すべてのTR7ルートテーブルは独自のルーティング決定を行います。同じIPブロックを異なるルートテーブルで競合なく使用できます。これはMSP、SaaS、政府、金融、マルチ顧客環境に必要な基本的な分離を提供します。
Route Health Injection — サービスが健全な間だけアドレスを広告
サービスアドレスは、背後のサービスがヘルスチェックを通っている間だけBGPまたはOSPFに広告され、通らなくなると数秒で取り下げられます。上流ルーターは、提供できないサイトへトラフィックを送るのをやめます — 誰もチケットを起票しないままに。実際にアドレスを保持しているノードだけが広告するため、クラスタのフェイルオーバーがルーティングのブラックホールになりません。BFDにより障害検知は1秒未満になります。
静的ルート管理
オペレーターはUIから直接宛先ネットワーク、ゲートウェイ、メトリック、インターフェースを定義します。静的ルートは主に管理ネットワーク、専用リンク、冗長パス、DMZ/内部分離、特定のバックエンドセグメントに使用されます。
ゲートウェイオンリンクサポート
一部のWANまたはポイントツーポイントの設定では、ゲートウェイIPが同じサブネット内に表示されない場合があります。TR7はそのような接続に対してゲートウェイオンリンク動作をサポートし、専用WAN、トンネル、またはサービスプロバイダーのリンクでの追加の手動ステップの必要性を削減します。
動的ルーティングプロトコルインフラストラクチャ
TR7は高度なネットワーキングチームのために動的ルーティングプロトコルを実行できるインフラストラクチャを提供します。BGP、OSPF、RIP、IS-ISなどのプロトコルをルートテーブルコンテキストで使用できます。これによりADCは静的ルートのみを理解するパッシブなデバイスではなく、データセンターまたはテナントネットワークのアクティブなルーティング参加者になります。 動的ルーティングはアドレスファミリーごとに明示します。これは一つのプロトコルではなく二つだからです。IPv4はOSPFv2が、IPv6はOSPFv3が運びます。デュアルスタックのネットワークが、IPv6移行の途中でルーティングを失うことはありません。
ネイバーはフォームで、生の設定とコンソールも手元に
BGPのピアとOSPFのエリアは、画面上のフォームで定義します — ルーターのアドレス、AS番号、認証、障害検知を1秒未満にするBFDのチェックボックス、そしてRoute Health Injectionを有効にする「このアドレスを広告する」スイッチ。ルーティング設定はTR7がそこから生成します。踏み込んだプロトコル作業も閉ざされていません。生の設定フィールドはTR7が生成した内容の後ろに追加され、上書きされることはありません。プロトコルコンソールも、状態を読み、プロトコルの言葉でデバッグするために残ります。
ポリシーベースルーティング
TR7は特定のトラフィックを異なるルーティング動作に置くことを可能にします。これはサービスごと、テナントごと、またはマークされたフローごとのルート選択に使用されます。管理トラフィックは静的ゲートウェイ経由で出る一方、本番トラフィックは動的ルートに従います。特定のテナントトラフィックをVPNリンクに置き、特定のVIPトラフィックを冗長WANにステアリングできます。
ゲートウェイ監視
デフォルトゲートウェイは定期的な間隔でチェックされます。失敗が設定されたしきい値を超えると、ルートはアンヘルシーとマークされます。代替ゲートウェイまたは代替ルートを有効化できます。この機能はリンク状態だけでなく実際のゲートウェイの到達可能性を確認します。
デフォルトゲートウェイフェイルオーバー
プライマリゲートウェイが失敗した場合、セカンダリゲートウェイへの移行が行われます。これはインターネット出口の冗長性、WANフェイルオーバー、MPLSバックアップ、VPNバックアップ、データセンター内の冗長ゲートウェイシナリオに使用されます。
ネクストホップ負荷分散 (NHLD)
アウトバウンドトラフィックを複数の上位ゲートウェイへ分散し、リンクごとに死活を監視します。障害が起きたリンクは数秒で切り離され、コネクションマーキングにより確立済みフローは開始したリンクに固定されます。そのため戻りトラフィックは対称のまま保たれ、上位のステートフル機器が通信の片側だけを見ることはありません。インターネット回線を2本以上持つ拠点に対するマルチWANの答えがこれです。
デルタルート同期
TR7は変更ごとにルーティング構造全体を再生しません。追加、編集、削除されたルートが区別され、変更されたルートのみが適用されます。このアプローチはライブシステムでのリスクを削減し、変更をより迅速に有効化します。
IPv4とIPv6のルートサポート
TR7はIPv4とIPv6のルート構造を個別に管理できます。デュアルスタック環境では両方のIPファミリーが同じルートテーブルモデルの下で一緒に動作します。
ルートテーブルごとのDNSとhosts管理
各ルートテーブルは独自の名前解決設定を持つことができます。これはテナントごとのDNS、プライベート内部リゾルバー、分離されたテスト環境、異なる内部ドメインシナリオに役立ちます。
クラスター対応のルート動作
HAクラスターシナリオでは、どのデバイスがアクティブなVIPを保持しているかがルート適用に重要です。TR7は使用中のVIP移行方法 — Only VRRP、TR7リンクチェック、TR7ゲートウェイチェック、TR7リンクアンドゲートウェイチェック — に合わせてアクティブデバイスのロジックに従ってルート適用を管理します。
vService経由のクロスルートテーブルサービスフロー
vServiceは1つのルートテーブルでリッスンし、別のルートテーブルに存在するバックエンドにトラフィックを転送できます。例：DMZルートテーブルでインバウンドのインターネットトラフィックを受け取り、内部ルートテーブルのバックエンドに制御された方法で転送します。同じアプライアンスがネットワークゾーン間の制御されたトランジットポイントになります。
静的 + 動的ハイブリッドルーティング
管理ルートを固定に保ちながら、本番トラフィックが動的に学習されたルートに従って流れることができます。メトリック値が優先順位を設定します。オペレーターは重要なパスを静的として固定し、可変ネットワークセグメントを動的プロトコルに委任します。
運用の深み
ルートテーブルモデルはルール作成にとどまりません — 適用順序、ゲートウェイ監視のしきい値、動的ルーティングのライフサイクル、フォールト処理もカバーします。
ルートエントリモデル
すべてのルートは次のコアフィールドで定義されます：宛先ネットワーク、ゲートウェイ、インターフェース、メトリック、ゲートウェイオンリンク動作、および関連するルートテーブル。この構造は単純な静的ルートと複雑なマルチゲートウェイシナリオの両方に十分です。
適用順序
ルート適用はインターフェースとIPの状態に依存します。TR7はまずインターフェースとIP側の変更を適用し、次にルートの変更を有効化します。この順序により、ルートが存在するがインターフェースがまだ準備できていないというクラスのエラーが排除されます。
ゲートウェイ監視のしきい値
ゲートウェイ監視は定義された間隔でチェックします。連続した失敗の後、ゲートウェイはアンヘルシーと見なされ、連続した成功の後に再びヘルシーと見なされます。このライズ/フォールアプローチにより、一時的な変動がルートフラップをトリガーすることを防ぎます。
動的ルーティングのライフサイクル
動的ルーティングインフラストラクチャはルートテーブルコンテキスト内で実行されます。関連するプロトコルサービスが起動され、設定ファイルが生成され、プロトコルコンソールが準備され、ルート学習プロセスが関連するルートテーブルにバインドされます。
ルート失敗時のロールバックロジック
ルートを適用できない場合、TR7はその失敗を分離して評価します。正常に適用されたルートは保持され、問題のあるルートのエラーが表面化されます。これにより単一の不良ルートがルーティング構造全体を破損することを防ぎます。
ルートテーブルとファイアウォールの関係
ルートテーブルの分離はファイアウォールの分離と組み合わせることで完全な意味を持ちます。一方のテナントのルートがもう一方のテナントのファイアウォールルールと混在することはありません。トラフィックは正しいルートテーブルを通過するだけでなく、正しいセキュリティポリシーも通過します。
ルートテーブルとvServiceの関係
vServiceのフロントエンドIPは特定のルートテーブル内でリッスンできます。バックエンド側は異なるルートテーブルを通じてアクセスできます。これによりADCは単に受信トラフィックを近くのバックエンドに転送するデバイスから、ネットワークゾーン間の制御されたサービスゲートウェイに変わります。
ネイバーとエリアの定義も、同じ変更管理の下に
ネイバーとエリアの定義は、設定の他の部分と同じ「検証してから適用」の流れを通り、変更はすべて実施者とともに監査ログに残ります。フォームで表現しきれないもの — 細かなフィルタリング、ルートマップ、プロトコルのチューニング — は生の設定フィールドに書きます。この内容はオブジェクトとともに保存され、設定が再生成されるたびに保持されます。プロトコルコンソールを好むチームは、これまでどおりに作業を続けられます。
vDevice — 1 台の筐体内にあるハードウェア相当の仮想アプライアンス
Route Table はルーティングを分離します。vDevice はさらに進んでアプライアンス全体を分離します。各 vDevice は自身のインターフェース、ファイアウォール、ルートテーブル、独自の L4 DDoS 防御セット、独自の DNS を持ち、ユーザー単位で割り当てられます。ある vDevice への DDoS 嵐はチューニングではなく設計によって封じ込められます。1 台の筐体を複数の独立した装置として使えるのはこのためです。
利用シナリオ
MSPマルチテナントルーティング
MSPは同じTR7アプライアンス上で多くの顧客を実行します。顧客Aと顧客Bが同じIPブロックを使用します。各顧客は独自のTR7ルートテーブルに分離されており、ルート、DNS、ファイアウォールルール、サービスフローが競合しません。
DMZから内部バックエンドへのトランジット
インターネットトラフィックはDMZルートテーブルで受け取られます。TR7がWAAPとアクセスポリシーを適用した後、トラフィックは内部ルートテーブルのバックエンドに転送されます。バックエンドのIPプランは外部に公開されません。
冗長WANとソースベースルーティング
一部のサービスはプライマリWAN経由、一部のテナントは冗長WAN経由、一部の管理サービスは専用リンク経由で出ます。TR7のポリシーベースルーティングは各トラフィッククラスに対して異なるパスを選択します。
データセンターとのBGP統合
TR7はエッジルーターからルートを動的に学習できます。新しいネットワークセグメントが追加された場合、静的ルートを手動で書く必要はありません。ネットワーキングチームはルートをアナウンスし、TR7は関連するルートテーブルで最新のパスを使用します。
ADCをOSPFエリアに追加
既存の内部ネットワークがOSPFで動作している場合、TR7は関連するルートテーブル内でそのトポロジーに参加できます。内部サービスネットワークが自動的に学習され、ルート管理が一元化されます。
デフォルトゲートウェイフェイルオーバー
プライマリゲートウェイが到達不能になります。ゲートウェイ監視が失敗を検出し、トラフィックが代替ゲートウェイに移動されます。オペレーターは手動でルート変更を行う必要はありません。
よくある質問
同じIPブロックを使用する2つのテナントが同じTR7アプライアンス上で実行できますか？
静的と動的ルートが同じルートテーブルで共存できますか？
BGPとOSPFの設定はUIから直接行いますか？
ゲートウェイ監視はどのように機能し、フェイルオーバーはいつトリガーされますか？
vServiceはリッスンしているルートテーブルとは異なるルートテーブルにあるバックエンドにトラフィックを転送できますか？
ルートテーブルの分離には追加ライセンスが必要ですか？
アウトバウンドトラフィックを2本のインターネット回線へ同時に分散できますか？
テナントごとの独立したルーティング — 単一コンソールから管理
重複するIPブロック、静的 + BGP/OSPF動的ルーティング、ゲートウェイ監視。お客様自身のネットワークトポロジーでライブセットアップをご案内します。