Centralized data policy is policy that is configured on a vSmart controller (hence, it is centralized) and that affects data traffic being transmitted between the routers on the Viptela overlay network.
Centralized Data Policy Overview
Data policy operates on the data plane in the Viptela overlay network and affects how data traffic is sent among the vEdge routers in the network. The Viptela architecture defines two types of data policy, centralized data policy, which controls the flow of data traffic based on the IP header fields in the data packets and based on network segmentation, and localized data policy, which controls the flow of data traffic into and out of interfaces and interface queues on a vEdge router.
Centralized data policy is applied to packets that originate from a specific sender, or source address, for instance, from a workstation in a local site that is sending voice, data, or other traffic, and it controls which destinations within a VPN the traffic can reach. Data policy is applied to data traffic based on a 6-tuple of fields in the packet's IP header: source IP address, source port, destination IP address, destination port, DSCP, and protocol.
As with control policy, data policy is provisioned centrally on a vSmart controller and is applied only on the vSmart controller. The data policy itself is never pushed to the vEdge routers in the network. What is pushed to the vEdge devices, via OMP and based on the site ID, are the results of the data policy; hence, the effects of the policy are reflected on the vEdge routers. Normally, the data policy on a vEdge router acts as the data policy for the entire site that sits behind the router. Data policy that comes from the vSmart controller is always implicitly applied in the inbound direction.
Data policy can be applied to data traffic based on the packet header fields, such as the prefix, port, protocol, and DSCP value, and they can also be applied based on the VPN in the overlay network to which the traffic belows.
Data Policy Based on Packet Header Fields
Policy decisions affecting data traffic can be based on the packet header fields, specifically, on the source and destination IP prefixes, the source and destination IP ports, the protocol, and the DSCP.
This type of policy is often used to modify traffic flow in the network. Here are some examples of the types of control that can be effected with centralized data policy:
- Which set of sources are allowed to send traffic to any destination outside the local site. For example, local sources that are rejected by such a data policy can communicate only with hosts on the local network.
- Which set of sources are allowed to send traffic to a specific set of destinations outside the local site. For example, local sources that match this type of data policy can send voice traffic over one path and data traffic over another.
- Which source addresses and source ports are allowed to send traffic to any destination outside the local site or to a specific port at a specific destination.
VPN Membership Policy
A second type of centralized data policy is VPN membership policy. It controls whether a vEdge router can participate in a particular VPN. Stated another way, VPN membership policy defines which VPNs a vEdge router is and is not allowed to receive routes from.
VPN membership policy can be centralized, because it affects only the packet headers and has no impact on the choice of interface that a vEdge router uses to transmit traffic. What happens instead is that if, because of a VPN membership policy, a vEdge router is not allowed to receive routes for a particular VPN, the vSmart controller never forwards those routes to that router.
Deep Packet Inspection
In addition to examining the network- and transport-layer headers in data packets, centralized data policy can be used to examine the application information in the data packets' payload. This deep packet inspection offers control over how data packets from specific applications or application families are forwarded across the network, allowing you to assign the traffic to be carried by specific tunnels. To control the traffic flow of specific application traffic based on the traffic loss or latency properties on a tunnel, use application-aware routing.