製品ドキュメント
Citrix SD-WAN WANOP
11.3 11.2 11.1 11.0 10.2
PDFを表示

ルーター構成

April 19, 2021
寄稿者: 
C

仮想インラインモードをサポートする場合、ルータには3つのタスクがあります。

  1. 着信WANトラフィックと発信WANトラフィックの両方をSD-WANアプライアンスに転送する必要があります。
  2. SD-WANトラフィックを宛先（WANまたはLAN）に転送する必要があります。
  3. アプライアンスに障害が発生した場合にアプライアンスをバイパスできるように、アプライアンスの状態を監視する必要があります。

ポリシーベースのルール

仮想インラインモードでは、ルーティングルールがアプライアンスによって転送されたパケットと転送されていないパケットを区別しない場合、パケット転送メソッドはルーティングループを作成できます。その区別をする任意の方法を使用できます。

一般的な方法では、ルーターのイーサネットポートの1つをアプライアンス専用にし、パケットが到着するイーサネットポートに基づいたルーティングルールを作成します。アプライアンス専用のインターフェイスに到着したパケットがアプライアンスに転送されることはありませんが、他のインターフェイスに到着したパケットは転送される可能性があります。

基本的なルーティングアルゴリズムは次のとおりです。

  • アプライアンスからアプライアンスにパケットを転送しないでください。
  • パケットがWANから到着した場合は、アプライアンスに転送します。
  • パケットがWAN宛ての場合は、アプライアンスに転送します。
  • LAN-to-LANトラフィックをアプライアンスに転送しないでください。
  • すべてのWANトラフィックがアプライアンスを通過しない限り、トラフィックシェーピングは効果的ではありません。

注意: ルーティングオプションを検討するときは、送信データだけでなく、返されるデータもアプライアンスを通過する必要があることに注意してください。たとえば、アプライアンスをローカルサブネットに配置し、それをローカルシステムのデフォルトルーターとして指定することは、仮想インライン展開では機能しません。送信データはアプライアンスを通過しますが、受信データはそれをバイパスします。ルーターを再構成せずにアプライアンスを介してデータを強制するには、インラインモードを使用します。

動作状態監視

アプライアンスに障害が発生した場合、データをアプライアンスにルーティングしないでください。デフォルトでは、Ciscoポリシーベースルーティングはヘルスモニタリングを行いません。ヘルスモニタリングを有効にするには、アプライアンスの可用性をモニタリングするルールを定義し、「setipnext-hop」コマンドに「verify-availability」オプションを指定します。この構成では、アプライアンスが使用できない場合、ルートは適用されず、アプライアンスはバイパスされます。

重要：仮想インラインモードは、正常性監視とともに使用する場合のみお勧めします。ポリシーベースのルーティングをサポートする多くのルーターは、ヘルスチェックをサポートしていません。ヘルスモニタリング機能は比較的新しいものです。Cisco IOSリリース12.3（4）Tで利用可能になりました。

以下は、アプライアンスの可用性を監視するためのルールの例です。

``` pre codeblock !- Use a ping (ICMP echo) to see if appliance is connected track 123 rtr 1 reachabilit y ! rtr 1 type echo protocol IpIcmpecho 192.168.1.200 schedule 1 life forever start-time now 


このルールは、192.168.1.200でアプライアンスに定期的にpingを実行します。123に対してテストして、ユニットが稼働しているかどうかを確認できます。

## ルーティングの例

次に、[仮想インラインの例](/ja-jp/citrix-sd-wan-wanop/11/cb-deployment-modes-con/br-adv-virt-inline-mode-con.html)に示すローカルサイトおよびリモートサイトの Cisco ルータの設定例を示します。ヘルスモニタリングを説明するために、ローカルサイトの構成にはヘルスモニタリングが含まれていますが、リモートサイトの構成には含まれていません。

注：ローカルサイトの構成では、pingモニターが既に構成されていることを前提としています。

例は、Cisco IOS CLIに準拠しています。他のベンダーのルーターには適用できない場合があります。

ローカルサイト、ヘルスチェックが有効：

``` pre codeblock
!
! For health-checking to work, do not forget to start
! the monitoring process.
!
! Original configuration is in normal type.
! appliance-specific configuration is in bold.
!
ip cef
!
interface FastEthernet0/0
ip address 10.10.10.5 255.255.255.0
ip policy route-map client_side_map
!
interface FastEthernet0/1
ip address 172.68.1.5 255.255.255.0
ip policy route-map wan_side_map
!
interface FastEthernet1/0
ip address 192.168.1.5 255.255.255.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 171.68.1.1
!
ip access-list extended client_side
permit ip 10.10.10.0 0.0.0.255 10.16.20.0 0.0.0.255
ip access-list extended wan_side
permit ip 10.16.20.0 0.0.0.255 10.10.10.0 0.0.0.255
!
route-map wan_side_map permit 20
match ip address wan_side
!- Now set the appliance as the next hop, if it’s up.
set ip next-hop verify-availability 192.168.1.200 20 track 123
!
route-map client_side_map permit 10
match ip address client_side
set ip next-hop verify-availability 192.168.1.200 10 track 123
<!--NeedCopy-->

リモートサイト（ヘルスチェックなし）：

``` pre codeblock ! This example does not use health-checking. ! Remember, health-checking is always recommended, ! so this is a configuration of last resort. ! ! ip cef ! interface FastEthernet0/0 ip address 20.20.20.5 255.255.255.0 ip policy route-map client_side_map ! interface FastEthernet0/1 ip address 171.68.2.5 255.255.255.0 ip policy route-map wan_side_map ! interface FastEthernet1/0 ip address 192.168.2.5 255.255.255.0 ! ip classless ip route 0.0.0.0 0.0.0.0 171.68.2.1 ! ip access-list extended client_side permit ip 10.16.20.0 0.0.0.255 10.10.10.0 0.0.0.255 ip access-list extended wan_side permit ip 10.10.10.0 0.0.0.255 10.16.20.0 0.0.0.255 ! route-map wan_side_map permit 20 match ip address wan_side set ip next-hop 192.168.2.200 ! route-map client_side_map permit 10 match ip address client_side set ip next-hop 192.168.2.200 !_ 


上記の各例では、アクセスリストをルートマップに適用し、ルートマップをインターフェイスにアタッチします。アクセスリストは、一方の高速化されたサイトで発信され、もう一方のサイトで終了するすべてのトラフィックを識別します（ 10.10.10.0/24 と目的地 20.20.20.0/24 またはその逆）。アクセスリストとルートマップの詳細については、ルーターのドキュメントを参照してください。

この構成は、一致するすべてのIPトラフィックをアプライアンスにリダイレクトします。TCPトラフィックのみをリダイレクトする場合は、アクセスリストの設定を次のように変更できます（リモート側の設定のみがここに表示されます）。

``` pre codeblock
!
 ip access-list extended client_side
 permit tcp 10.16.20.0 0.0.0.255 10.10.10.0 0.0.0.255
 ip access-list extended wan_side
 permit tcp 10.10.10.0 0.0.0.255 10.16.20.0 0.0.0.255
!
<!--NeedCopy-->

アクセスリストの場合、通常のマスクは使用されないことに注意してください。代わりにワイルドカードマスクが使用されます。ワイルドカードマスクをバイナリで読み込む場合、「1」は「気にしない」ビットと見なされます。

ルーター構成
April 19, 2021
寄稿者: 
C
April 19, 2021
寄稿者: 
C

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.