Citrix SD-WAN WANOP

Router Configuration

March 12, 2021

Contributed by:

S C

The router has three tasks when supporting virtual inline mode:

It must forward both incoming and outgoing WAN traffic to the SD-WAN appliance.
It must forward SD-WAN traffic to its destination (WAN or LAN).
It must monitor the health of the appliance so that the appliance can be bypassed if it fails.

Policy-Based Rules

In virtual inline mode, the packet forwarding methods can create routing loops if the routing rules do not distinguish between a packet that has been forwarded by the appliance and one that has not. You can use any method that makes that distinction.

A typical method involves dedicating one of the router’s Ethernet ports to the appliance and creating routing rules that are based on the Ethernet port on which packets arrive. Packets that arrive on the interface dedicated to the appliance are never forwarded back to the appliance, but packets arriving on any other interface can be.

The basic routing algorithm is:

Do not forward packets from the appliance back to the appliance.
If the packet arrives from the WAN, forward it to the appliance.
If packet is destined for the WAN, forward to the appliance.
Do not forward LAN-to-LAN traffic to the appliance.
Traffic shaping is not effective unless all WAN traffic passes through the appliance.

Note: When considering routing options, keep in mind that returning data, not just outgoing data, must flow through the appliance. For example, placing the appliance on the local subnet and designating it as the default router for local systems does not work in a virtual inline deployment. Outgoing data would flow through the appliance, but incoming data would bypass it. To force data through the appliance without router reconfiguration, use inline mode.

Health Monitoring

If the appliance fails, data should not be routed to it. By default, Cisco policy based routing does no health monitoring. To enable health monitoring, define a rule to monitor the appliance’s availability, and specify the “verify-availability” option for the “set ip next-hop” command. With this configuration, if the appliance is not available, the route is not applied, and the appliance is bypassed.

Important: Citrix recommends virtual inline mode only when used with health monitoring. Many routers that support policy-based routing do not support health-checking. The health-monitoring feature is relatively new. It became available in Cisco IOS release 12.3(4)T.

Following is an example of a rule for monitoring the availability of the appliance:

``` 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

This rule pings the appliance at 192.168.1.200 periodically. You can test against 123 to see if the unit is up.

## Routing Examples

The following examples illustrate configuring Cisco routers for the local and remote sites shown in [Virtual inline example](/en-us/citrix-sd-wan-wanop/11/cb-deployment-modes-con/br-adv-virt-inline-mode-con.html). To illustrate health monitoring, the configuration for the local site includes health monitoring, but the configuration for the remote site does not.

Note: The configuration for the local site assumes that a ping monitor has already been configured.

The examples conform to the Cisco IOS CLI. They might not be applicable to routers from other vendors.

Local Site, Health-Checking Enabled:

``` 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-->

Remote Site (No Health Checking):

``` 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 !_

Each of the above examples applies an access list to a route map and attaches the route map to an interface. The access lists identify all traffic originating at one accelerated site and terminating at the other (A source IP of 10.10.10.0/24 and destination of 20.20.20.0/24 or vice versa). See your router's documentation for the details of access lists and route-maps.

This configuration redirects all matching IP traffic to the appliances. If you want to redirect only TCP traffic, you can change the access-list configuration as follows (only the remote side's configuration is shown here):

``` 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-->

Note that, for access lists, ordinary masks are not used. Wildcard masks are used instead. Note that when reading a wildcard mask in binary, “1” is considered a “don’t care” bit.

The official version of this content is in English. Some of the Cloud Software Group documentation content is machine translated for your convenience only. Cloud Software Group has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Cloud Software Group product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Cloud Software Group, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Cloud Software Group will not be held responsible for any damage or issues that may arise from using machine-translated content.

Router Configuration

March 12, 2021

Contributed by:

S C

March 12, 2021

Contributed by:

S C

Router Configuration

Policy-Based Rules

Health Monitoring

In this article