Apply Template Groups
Configuration > Templates & Policies > Apply Template Groups
Use this tab to add or remove template groups from appliances.
-
To add or remove template groups from appliances, select the appliances, select the Add check box for each template to add or clear the Remove check box for each template to remove, and then click Apply to save and apply the changes.
-
Drag template groups up or down to reorder the list. Orchestrator automatically applies any changes to template groups to their associated appliances.
NOTE: If multiple template groups are applied to an appliance, the order in which they are applied determines which template is used. Template groups applied later (lower on the apply order list) overwrite any conflicting templates applied earlier.
-
Template groups that are already associated with appliances will be updated on those appliances when:
-
Any template in the template group is added, edited or removed.
-
Orchestrator restarts.
-
An appliance reboots.
-
The following table describes the information displayed on this tab for each appliance.
| Field | Description |
|---|---|
| Appliance | The name of the appliance. |
| Present | The template groups applied to the appliance. |
| Changes | Any recent changes made to the template groups that are applied to the appliance. |
Best Practices When Applying Template Groups
Do: Use templates for all fabric configurations
Avoid unique configurations in your network by using template groups and templates to apply configurations consistently to every appliance in your SD-WAN fabric.
Do: Use Default Template Group for global configuration settings
The Default Template Group cannot be removed. It is a recommended best practice to put all global appliance configuration items into the Default Template Group, including Security Policies, Access Lists, Shaper, and QoS Policies, as these are typically standard across the network.
Do: Use additional template groups for different configurations across appliance groups
Multiple template groups can be created, each containing different templates and different attributes of those templates. Additionally, each appliance or group of appliances can have multiple template groups applied to them. For more information, see Multiple Template Groups Example.
Do: Pay attention to the Template Apply Order
Template groups are applied to the appliances based on the Template Apply Order.
NOTE: The last template group in the list will be the final configuration applied to the appliance.
This order can be changed by simply dragging and dropping the template groups into the desired order. It is recommended to use the Default Template Group and keep it at the top of the list.
For more information, see Apply Template Groups Behavior and Multiple Template Groups Example.
Do: Make template changes in a limited scope for testing/validation of changes
Global changes applied via templates can be service impacting. It is recommended to make changes that are globally significant to a small portion of the network to ensure there is no service disruption related to the changes.
Do: Use the System template in template groups
The System template should be included inside any template group because it contains the MSS (Maximum Segment Size) value.
Do: Use Replace if Merge/Replace are available
Some templates have Merge and Replace options, which appear as Merge and Replace buttons on the template, as shown in the following figure. If a template does not have Merge and Replace options, the template is always replaced. In most cases, Replace should be used instead of Merge.
The Replace option replaces the configuration contained in the template on the appliance when any changes are made to the template. This ensures that the configuration is always consistent with the template.
Do Not: Use Merge
The Merge option allows changes in the template to be merged with what is currently in place on the appliance, which can lead to configuration inconsistencies. Merge should be avoided in most cases. One exception where Merge should always be used is the Network Access Control (NAC) template.
The following table is an example of Merge behavior. The newly applied template settings override all old settings (aclMap 1, 2 and 4). Where the new template does not have specific settings, the previous settings remain (aclMap3).
| Template Settings Applied via Merge | Current Appliance Settings | Appliance Settings After Merge |
|---|---|---|
| aclMap1 | aclMap1 | aclMap1 |
| 100 abc | 100 currabc | 100 abc |
| 200 def | 100 currdef | 200 def |
| aclMap2 | aclMap2 | aclMap2 |
| 100 mng | 100 currmng | 100 mng |
| 200 twn | 300 ttp | 200 twn |
| ——- | aclMap3 | aclMap3 |
| ——- | 200 efg | 200 efg |
| ——- | 300 dng | 300 dng |
| aclMap4 | ——- | aclMap4 |
| 300 hello | ——- | 300 hello |
| 301 world | ——- | 301 world |
Do Not: Make changes locally on an appliance
Templates ensure consistency of configurations across your entire fabric. Local changes to an appliance are unnecessary, except for the following:
-
Deployment: Each appliance has a unique deployment configuration that consists of IP addressing, Labels, Bandwidth, and WAN Optimization.
-
Routing and VRRP: BGP, OSPF, VRRP, and Multicast configurations are typically unique to each appliance.
-
VTI and Passthrough Tunnels: Third Party IPSec tunnels and VTIs are unique to each appliance.
All items noted above can be configured manually or through Preconfiguration, which can be used to model each of these unique configurations inside a YAML file stored on the Orchestrator. These configurations can be used to model everything on the appliance, or to add/update parts of the configuration.
For more information on preconfiguration, see Preconfigure Appliances.
Apply Template Groups Behavior
Using templates in Orchestrator helps maintain consistency across the network footprint. It is important to understand the behavior of how templates are applied and what actions trigger an update or synchronization of configuration in a template.
Templates are always pushed in a top-down manner from the Orchestrator to the appliances, and in the order of priority based on the Template Apply Order.
The following table details the actions that trigger an application or re-application of the template configuration.
| Event | Action | Result |
|---|---|---|
| Appliance Reboot | All associated template groups are re-applied to appliance, based on the Template Apply Order. | Any local changes to the appliance that are part of a template group are corrected by the Orchestrator. |
| Orchestrator Reboot | All template groups are re-applied to all associated appliances. | Any local changes to the appliance that are part of a template group are corrected by the Orchestrator. |
| Add, change, or delete new template group that is not yet associated with any appliance(s). | All template groups are re-applied to associated appliances, based on the Template Apply Order. | None. |
| Add, change, or delete template group that is associated with appliance(s). | All template groups are re-applied to associated appliances, based on the Template Apply Order. | Any local changes to the appliance that are part of a template group are corrected by the Orchestrator. |
| Apply template group to a previously non-associated appliance. | All associated template groups are re-applied to newly associated appliance(s), based on the Template Apply Order. | Any local changes to the appliance that are part of a template group are corrected by the Orchestrator. |
| Remove template group from associated appliance. | Template association is removed within Orchestrator. | Any configuration that was part of the template remains in place on the appliance, but any future updates to the template will not be applied. |
Multiple Template Groups Example
This section describes an example network that consists of appliances deployed in North America, Europe, and Asia.
-
Appliances in North America should point to a regional syslog collector (IP = 1.2.3.4).
-
Appliances in Europe should point to a different collector (IP = 4.5.6.7).
-
Appliances in Asia should point to the global collector (IP = 8.9.10.11), which is configured in the Default Template Group.
To accomplish this, you would add two new template groups.
After configuration, apply the EUR_Logging template group to the Europe appliances and the NA_Logging template to the North America appliances.
This points the North America appliances to the logging server at 1.2.3.4 and the Europe appliances to 4.5.6.7. Any other appliances continue to use the logging server configured in the Default Template group, which is 8.9.10.11.
The following image shows the Apply Template Groups tab from an example Orchestrator that has a configuration with seven template groups. Each template group contains templates that are configured based on the appliance role, administrative requirements, geographic location, and other factors.
The following table outlines how the seven template groups are applied to the appliances.
| Template Group Name | Appliances the Template Group is Applied To |
|---|---|
| Default Template Group | Applied to ALL appliances in the SD-WAN fabric. |
| Hub_Defaults | Applied to All Hub appliances in the SD-WAN fabric, and NOT applied to Spoke appliances. |
| Spoke_Defaults | Applied to All Spoke appliances in the SD-WAN fabric, and NOT applied to Hub appliances. |
| PST_PDT | Applied to all appliances in the Pacific Time Zone. |
| MST_MDT | Applied to all appliances in the Mountain Time Zone. |
| CST_CDT | Applied to all appliances in the Central Time Zone. |
| EST_EDT | Applied to all appliances in the Eastern Time Zone. |
The following image shows a breakdown of the final appliance configuration for this example, when the same templates are part of multiple template groups. In this example the following is true:
-
The Default Template Group contains DNS and Date/Time.
-
Spoke_Defaults contains DNS with different values than the Default Template Group.
-
MST_DST contains Date/Time with different values than the Default Template Group.
All the unique templates from each template group are consolidated and applied to the appliance for common template configuration between template groups. The last template group in the Apply Order is the final configuration on the appliance.
Template Options
The following table has general guidelines about whether templates are recommended in the default group or in a new or separate group. Consult with Technical Support for specific details on template configuration.
| Template Name | Default Template Group | Separate Template Group | Notes |
|---|---|---|---|
| System | Yes | Case-by-case | Should be included in the Default Template Group because it contains the MSS (Maximum Segment Size) value. |
| Auth/Radius/TACACS+ | Yes | For local appliance authentication via HTTPS/SSH. | |
| SNMP | Yes | Case-by-case | For appliance SNMP, which is disabled by default. |
| Network Access Control (NAC) | No | Case-by-case | Used to configure MAC Auth and 802.1x. |
| Appliance IP Allow List | Yes | Used to configure access to SNMP, HTTP/HTTPS, and SSH on the local appliance. | |
| Flow Export | Yes | Typically global, but this could be configured in a region-specific template. | |
| DNS | Yes | Typically global, but this could be configured in a region-specific template. | |
| Logging | Yes | Typically global, but this could be configured in a region-specific template. | |
| Banner Messages | Yes | Typically global, but this could be configured in a region-specific template. | |
| HTTPS Certificate | No | Case-by-case | For the local appliance WebUI certificate. |
| User Management | Yes | Global configuration of local accounts for “password of last resort” access is recommended. This allows for easy lifecycle management of local passwords. | |
| Date/Time | Case-by-case | Some deployments use a global time standard; others require appliance time to be based on physical location. | |
| Password Settings | Yes | Used to configure password complexity requirements and expiration for local accounts. | |
| SSL Certificates | Case-by-case | Needed for SSL Decryption/WAN Op only. | |
| SSL CA Certificates | Case-by-case | Needed for SSL Decryption/WAN Op only. | |
| SSL for SaaS | Case-by-case | Needed for SSL Decryption/WAN Op only. | |
| VRRP | No | Case-by-case | Typically configured per site, but you could use this to set a global standard for “VRRP_Primary” and “VRRP_Secondary.” |
| Peer Priority | No | Yes | Typically set on branches for selecting a preferred peer when multiple duplicate routes are present. |
| Route Redistribution Maps | Yes | Typically global, but this could be configured in a region-specific template. | |
| BGP | Yes | Typically global, but this could be configured in a region-specific template. | |
| OSPF | Yes | Typically global, but this could be configured in a region-specific template. | |
| BFD | Yes | Typically global, but this could be configured in a region-specific template. | |
| VXLAN | Yes | Typically global, but this could be configured in a region-specific template. | |
| Admin Distance | No | Yes | Admin distance is often configured differently for hub versus spoke appliances, and this varies based on environment. |
| Routes | No | Yes | Desired routes are often configured differently for hub versus spoke appliances, and this varies based on environment. |
| Shaper | Yes | Typically global, should remain global. | |
| User Defined Apps | No | No | Deprecated. Use Application Definitions in Orchestrator. |
| Access Lists | Yes | Typically global, should remain global. | |
| Route Policies | No | Case-by-case | Templatized or manual route policies should be avoided as the overlay should take care of this. Route policies are typically used only for troubleshooting purposes. |
| QoS Policies | Yes | Typically global, should remain global. | |
| Optimization Policies | Yes | Typically global, should remain global. | |
| SaaS NAT Policies | No | Case-by-case | If SaaS Optimization is used, hubs may have a different configuration than spokes. |
| Threshold Crossing Alerts | No | Yes | TCAs can be customized by region; including these in a region-specific template may be desired. |
| SaaS Optimization | No | Case-by-case | If SaaS Optimization is used, hubs may have a different configuration than spokes. |
| Security Policies | Yes | Typically global, should remain global. | |
| DNS Proxy Policies | Yes | Typically global, should remain global. | |
| Management Services | Yes | Typically global, should remain global. | |
| Firewall Protection Profiles | Yes | Typically global, but this could be configured in a region-specific template. | |
| CLI | Yes | Typically global, should remain global. | |
| Session Management | Yes | Typically global, should remain global. | |
| Secure Web Services | Yes | Typically global, should remain global. |