Route Policies Template

NOTE: If you have deployed an SD-WAN network by using Business Intent Overlays (BIO), Orchestrator uses BIOs to automatically create the necessary Route Policies.

If you are creating a conventional WAN optimization network, there might be occasions when you need to directly configure Route Policies. Then, the following applies.

Only use the Route Policy template to create (and apply) rules for flows that are to be:

• Sent pass-through (shaped or unshaped)

• Dropped

• Configured for a specific high-availability deployment

• Routed based on application, ports, VLAN, DSCP, or ACL (Access Control List)

You might also want to create a Route Policy entry when multiple tunnels exist to the remote peer, and you want the appliance to dynamically select the best path based on one of these criteria:

• Load balancing

• Lowest loss

• Lowest latency

• A preferred interface

• A specific tunnel

Why?

Each appliance’s default routing behavior is to auto-optimize all IP traffic, automatically directing flows to the appropriate tunnel. Auto-optimization strategies reduce the need to create explicit route map entries for optimization. The three strategies provided are TCP-based auto-opt, IP-based auto-opt, and subnet sharing. By default, all three are enabled on the System template.

Priority

• With this template, you can create rules with a priority from 1000 – 9999. When the template is applied to an appliance, Orchestrator will delete all rules having a priority in that range before applying its policies.

• If you access an appliance directly, you can create rules with higher priority than Orchestrator rules (1 – 999) and rules with lower priority (10000 – 19999 and 25000 – 65534).

  NOTE: The priority range from 20000 to 24999 is reserved for Orchestrator.

• When adding a rule, the priority is incremented by ten from the previous rule. The priority can be changed, but this default behavior helps to ensure you can insert new rules without having to change subsequent priorities.

Match Criteria

• These are universal across all policy maps—Route, QoS, Optimization, NAT (Network Address Translation), and Security.

• If you expect to use the same match criteria in different maps, you can create an ACL (Access Control List), which is a named, reusable set of rules. For efficiency, create them in Configuration > Templates & Policies > ACLs > Access Lists, and apply them across appliances.

• The available parameters are Application, Address Map (for sorting by country, IP address owner, or SaaS application), Domain, Geo Location, Interface, Protocol, DSCP, IP/Subnet, Port, Traffic Behavior Overlay, Fabric or Internet, and User Role (the User Role as specified in the authentication exchange with the ClearPass RADIUS server).

  NOTE: User Role options include the RADIUS User Role, User Name, User Group, User Device, or User MAC. Configuring User Role match criteria enables an EdgeConnect to automatically assign traffic steering and firewall zone policies.

• To specify different criteria for inbound versus outbound traffic, select the Source:Dest check box.

  NOTE: Source and destination role-based policies can be configured when both source and destination users are in the same network.

Source or Destination

• An IP address can specify a subnet; for example, 10.10.10.0/24 (IPv4) or fe80::204:23ff:fed8:4ba2/64 (IPv6).

• To allow any IP address, use 0.0.0.0/0 (IPv4) or ::/0 (IPv6).

• Ports are available only for the protocols tcp, udp, and tcp/udp.

• To allow any port, use 0.

Wildcard-based Prefix Matching Rules

• Even when using a range or a wildcard, the IPv4 address must be specified in the 4-octet format, separated by the dot notation. For example, A.B.C.D.

• Range is specified using a single dash. For example, 128-129.

• Wildcard is specified as an asterisk (*).

• Range and Wildcard can both be used in the same address, but an octet can only contain one or the other. For example, 10.136-137.*.64-95.

• A wildcard can only be used to define an entire octet. For example, 10.13*.*.64-95 is not supported. Use 10.130-139.*.64-95 to specify this range.

• The same rules apply to IPv6 addressing.

• CIDR notation and (Range or Wildcard) are mutually exclusive in the same address. For example, 192.168.0.1-127/24 is not supported. Use either 192.168.0.0/24 or 192.168.0.1-127.

• These prefix-matching rules apply to the following policies only: Route, QoS, Optimization, NAT, Security, and ACLs.

Set Actions Fields

The Route Policy template’s SET actions determine where to direct traffic and what the fallback is when a tunnel is down.

Where the Appliance Directs Traffic

• In the Destination field, you specify how to characterize the flow. The options are a specific overlay, auto-optimized, pass-through [shaped], pass-through-unshaped, or dropped.

• When auto-optimized, a flow is directed to the appropriate tunnel. If you choose, you can specify that the appliance use metrics to dynamically select the best path based on one of these criteria:

  • Load balancing

  • Lowest loss

  • Lowest latency

• When configuring the Route Policy for an individual appliance when multiple tunnels exist to the remote peer, you can also select the path based on a preferred interface or a specific tunnel.

How Traffic Is Managed If a Tunnel Is Down

• The Fallback can be pass-through [shaped], pass-through-unshaped, or dropped.

• When configuring the Route Policy for an individual appliance, the continue option is available if a specific tunnel is named in the Destination column. That option enables the appliance to read subsequent entries in the individual Route Policy in the event that the tunnel used in a previous entry goes down.

---