Centralized policies

2.2.e Centralized policies overview (not on blueprint)

General information on “SDW Centralized policies overview”:

• Defined on vManage => NETCONF transaction to the vSmart => Pushed via OMP to the vEdge routers
• Policies can be created using the wizard or by entering a CLI text-style configuration
• vManage wizard and the CLI text-style configuration have feature parity
• vSmart must be in “vManage mode” (configuration done via vManage) to be able to accept control policies
• Centralized policies are not added to the configuration of the WAN Edge device but rather sit in the volatile storage
• On a device reboot, the policy will be re-added to the vEdge device along with the other routing updates via the vSmart
• For centralized data policies/AAR this means that vSmarts send the policy as an OMP update to the WAN Edge devices and NOT as a configuration update
• Therefore centralized data policies/AAR must be seen as update for the WAN Edge FIB and firewall rules
• Three different central policy types:
  • App-Route Policy: Applied at vEdge. Applications can be mapped to SLAs.
  • Control Policy: Applied at the vSmart. Comparable to policies configured on a BGP route reflector. Used when manipulation within the SD-WAN fabric is needed.
  • Data Policy: Applied at the vEdge. Commonly referred to as “PBR on steroids”. Used when manipulation on the WAN Edge router is needed.
• Centralized Data Policy directions:
  • from-service: Affects traffic coming from the service side VPNs.
  • from-tunnel: Affects traffic coming from the transport side VPNs.
• Configuration process (high level overview):
  1. Create groups of interest (eg. define Applications, Colors, Prefixes, Sites, TLOCs, …)
  2. Configure a topology (optional - mandatory if no traffic rules are configured)
  3. Configure traffic rules (optional - mandatory if no topologies are configured)
  4. Apply Policies to Sites and VPNs
• After the policy is created it gets pushed to the vSmart (process explained in first line)
• Policies can be modified after they’ve been created
• Sequence lists (eg. traffic rules) have an explicit deny at the end, just like ACLs on IOS
• Only one centralized policy can be active at a time, even if multiple policies are created
• Policies order of operation (from Service VPN to Transport VPN):
  1. Local Ingress Policy
  2. Centralized App-Route Policy (AAR)
  3. Centralized Data Policy
  4. Routing and Forwarding
  5. Queueing and Scheduling
  6. Local Egress Policy

2.2.e i Application Aware Routing

General information on “SDW Application Aware Routing”:

• AAR provides the possibility to control the outgoing traffic flow based on Matching Conditions and SLAs (= Service Level Agreements)
• Matching conditions define the interesting traffic, where the SLA should be applied on
• A SLA is a set of parameters (jitter, latency, loss) which measures the link quality of a data plane tunnel
• Only one of the three parameters must be used, but all of the can be combined together
• If one of the parameters of a data plane tunnel rises above the defined threshold, it can no longer be used for sending traffic
• If there are multiple TLOCs which fit the SLA, a preferred TLOC color can be set which will be used as long as it is SLA compliant
• Validation of AAR can be done via the vEdge Troubleshooting Tools
• Matching Conditions can be:
  • Application Type
  • Protocol
  • Source/Destination Prefix
  • Source/Destination Port
  • […] tbc […]
• AAR default path selection:
  • If a single tunnel matches the SLA, send data traffic through that tunnel
  • If two or more tunnels match the SLA, distribute the traffic among these tunnels
  • If no tunnel matches the SLA, send data traffic through any available tunnel
• AAR path selection parameters:
  • Preferred Color: One/several preferred TLOC colors can be selected which will be exclusively used to send traffic (as long as they are SLA compliant). If they’re not SLA compliant, all other available tunnel colors will be used.
  • Strict: When activated, traffic will be drop if none of the available tunnels are SLA compliant.
• AAR SLA calculation:
  • App-Route Poll Interval: Timespan which is used for SLA statistics calculation based on the BFD packets.
  • App-Route Multiplier: Number of previous poll intervals to take into account for calculating the SLA compliance
• Example: AAR is applied to Site A with target = Google Cloud, SLA = max. 50ms latency, preferred color = mpls + strict, backup preferred color = public-internet. As long as the latency of the MPLS data plane tunnel stays below 50ms, it will be used for traffic destined to the Google Cloud. When the latency rises above 50ms, the Public-Internet data plane tunnel will be used. When the MPLS data plane tunnel latency falls again below 50ms, it will be switched back to MPLS.

2.2.e ii Topologies

General information on “SDW Topologies”:

• By default, all vEdges will create a full-mesh network after they’re up
• With the centralized policies “Topologies” feature, the topology of the overlay network can be easily changed
• This results in highly scalable and flexible topologies to be created and deployed
• It’s possible to mix/combine several topologies, eg. a vEdge is a member of a mesh topology within region A but also attached to a hub-and-spoke network within region B
• Possible topology types:
  • Mesh: Classical partial-/full-mesh topology which can be divided into different regions.
  • Hub-and-Spoke: Classical hub-and-spoke (single-/dual-hub) topology like in DMVPN or FlexVPN.
  • Custom Control: Possible to create “weird” topologies, such as MPLS-only between Site A-B, WAN-only between Site B-C and no connections between Site A-C at all.
• Topologies are always built on VPN0 (“Transport VPN”)
• When configuring custom routing topologies, everything must be seen from the vSmarts perspective, therefor:
  • Outbound direction: vSmart will update the incoming routes AFTER they are installed in the local routing database of the vSmart but BEFORE they are sent out to the other branches (vEdges).
  • Inbound direction: vSmart will update the incoming routes BEFORE they are installed in the local routing database of the vSmart.

2.2.e VPN Membership Policy (not on blueprint)

General information on “SDW VPN Membership Policy”:

• By default, any configured VPN is advertised to any WAN Edge node
• Sometimes it’s required to limit a specific VPN to a few or only on device at all
• This behavior can be controlled using a VPN Membership Policy where it can be designed which site takes part in which VPN and therefor received which vRoutes
• Problem: VPN 123 is used for the guest network. By default, vSmarts would advertise all vRoutes to each site where the VPN 123 is defined.
• Solution: A centralized VPN Membership Policy is enforced excluding all sites from taking part in the VPN 123. This results in that the VPN 123 is only locally used and no vRoutes will ever get advertised over the vSmarts.

2.2.e DIA (not on blueprint)

Direct Internet Access

General information on “SDW DIA”:

• By default, each VPN is “closed” and no traffic to the outside world or other VPNs is allowed unless explicitly configured (eg. route leaking, etc.)
• Problem: VPN 123 is used for the guest network and needs internet access without going through a data center.
• Solution: A centralized data policy is configured on the vSmarts allowing for local internet breakout at the WAN Edge devices.

Configuration steps for centralized DIA:

1. Enable NAT on the internet-facing transport interface
2. Create a centralized policy
3. Define groups of interest (eg. source prefix, …)
4. Configure a traffic data rule:
   • Select “Custom” and add a sequence
   • Match criteria: Source Data Prefix
   • Action criteria: Accept + NAT VPN
5. Apply data rule to sites:
   • “From Service”
   • Site List: The to be applied sites
   • VPN List: The to be applied VPNs
6. Deploy configuration