Routing Policy

Routing policies are used to control the flow of data to and from endpoints. They are a core concept in the stacuity platform, and are a very powerful way to tailor the network for the needs of the application. They affect routing, security and edge services.

The configuration of a routing policy is split into three sections:

• Details - basic information such as name, monitor and status
• Policy Rules - the set of rules controlling how data is routed to/from Routing Targets.
• Edge Services - the services within the stacuity platform which can exchange data with the endpoints related the policy.

The logical order used to create Routing Policies is:

1. Create a VSlice (if it doesn't exist already)
2. Create one or more Routing Targets to represent the external networks which you want your endpoints to connect to
3. Create a Routing Policy to define how these Routing Targets are selected and used
4. Create an Endpoint Group which refers to the Routing Policy
5. Put appropriate the Endpoints into the group.

Policy Rules

A Routing Policy typically contains a number of rules. As data passes through the platform, the rules are consulted in order, one-by-one, until a matching rules is found. Once a match is found, the data is routed according to the configuration of the rule.

If no rules are matched, then the data is dropped and not forwarded.

If you are familiar with IP Access Lists on routers and firewalls, the principle is similar - except that as well as configuring whether data is dropped or forwarded, you can also configure where it is forwarded to.

The example policy above contains three rules, plus the default 'drop' rule which cannot be changed. Traffic which matches either of the first two rules ('iPad to Order Server' and 'Photo App') will be forwarded to the 'AzureVPN' Routing Target], anything else will be routed to the Internet.

Changes to these rules will not take effect until they overall policy is saved.

New rules can be added by clicking 'Add Rule', and existing rules can be changed by clicking the edit (pencil) icon alongside each rule.

Rule Matching

Rules contain a number of parameters which are used to specify what data traffic will match the rule, and how matching traffic should be handled.

Direction defines which direction of traffic will be matched. 'Uplink' is traffic from the Endpoint towards the Routing Target; 'Downlink' is traffic in the opposite direction.

Destination IP Pattern is optional, and contains a list of CIDR-formatted subnets.

Examples of valid patterns are as follows:

Destination patterns can only be specified for uplink traffic; the destination for downlink traffic is always the endpoint itself.

Source IP Pattern is the equivalent for downlink traffic - and follows the same rules. The source for uplink traffic is always the endpoint.

The Reflexive toggle is used to control whether returning traffic is also matched. It is usually appropriate for this to be set - otherwise (for example), the responses to outbound requests will be blocked.

Protocol is used to select a transport protocol (such as TCP, UDP or ICMP). If unselected, traffic of any protocol is matched.

If TCP or UDP is selected as a transport protocol, Source or Destination ports can optionally be specified too - which will be used in matching. Valid port patterns are as follows:

Rule Application

Once traffic has been matched against a rule using the above parameters, it is handled according to the following parameters:

The Action controls whether the data is forwarded, dropped or reflected.

Once a Routing Policy has been created and saved, it can be selected on appropriate Endpoint Groups in the VSlice. Routing Policies not applied to any Endpoint Groups have no effect.