What is a Localized Policy?

The main difference between centralized and localized policies is the area of effect. A centralized policy is applied on vSmart and has a network-wide impact (hence centralized). In contrast, a localized policy is configured directly on a vEdge router via CLI or through a vManage device template and has a single-device scope (hence localized). As the control and data plane of the SD-WAN solution is separated, localized policies are also divided into control and data ones, as illustrated in the diagram below.

Localized Control Policies

A WAN edge router participates in the SD-WAN overlay fabric on the transport side and exchanges routing information with the vSmart controllers via OMP. On the service side, the vEdge router engages in the site-local routing domain. It appears to other network nodes in the site-local network as a regular Cisco router capable of running traditional routing protocols such as BGP or OSPF and exchanging routing information with the site-local routers.

A localized control policy is a mechanism to control the vEdge’s routing behavior on the site-local network that the device is part of. Unlike a centralized control policy that affects the routing behavior across the entire SD-WAN overlay fabric, a localized control policy applies only to a traditional routing protocol at a local branch. This type of policy is called a route policy and is configured, as shown in the diagram below.

An SD-WAN route policy is similar in structure and usage to a route-map on a regular Cisco router. It allows us to modify the local routing behavior on the site-local network.

Localized Data Policies

A localized data policy is applied on a specific vEdge interface and affects how the router handles data traffic received or transmitted through that particular interface. This policy type is also referred to as access-list (ACL). The following diagram illustrates an example of an access list attached to ge0/2 of a vEdge router.

The ACL denies any TELNET traffic that comes on ge0/2. However, it does not affect the data traffic that comes to interfaces ge0/1 and ge0/3. We can also deny TELNET traffic with a centralized data policy, but it has a VPN-wide effect. In this example, applying a centralized data policy to VPN 5 will deny TELNET traffic on all three interfaces (ge0/1, ge0/2, ge0/3), while the localized data policy denies the telnet traffic only on ge0/2. As you can see, localized data policies have a single interface scope.

With an access list, we can also filter, rewrite, or apply a class of service (CoS) to data packets as they traverse a specific interface.

Comments

bssohail

Fri, 11/18/2022 - 17:03

Hi, I need your assistance. I have 10 spokes sides. And each spokes sides I have created 4 vLan. In these 4 LAN i want to allow some IPS to communicate between the VLAN's and rest will be restricted. How can I achieve these. Further If I use variable in ACL list for example Manage IP as variable and it repeated 10 times in an ACL so for all 10 lines I have to tell the value of that variable while deployment. Please assist the easiest way to deply

Ivan.Ivanov

Sat, 11/19/2022 - 11:24

Hello bssohail,
It really depends on the exact use case you have. I am unsure what you mean by VLANs - do you mean VPNs or just four SVIs within a single VPN? If you want to restrict communication between sites in a scalable way - look at centralized data policies. If you want to restrict communication within a VPN at each site, the most scalable approach would be an intra-vpn Firewall Policy.
HTH, Ivan