Central Management practice questions

System Settings > SD-WAN

Why it fails: System Settings manages FortiManager itself.

Policy & Objects > Firewall Policy

Why it fails: That is for standard firewall policies.

Log View > SD-WAN

Why it fails: Log View is for troubleshooting.

Device Manager

Why it fails: Device Manager is for configuration, not monitoring.

Log View

Why it fails: Log View shows raw logs, not aggregated performance metrics.

Policy & Objects

Why it fails: Policy & Objects is for configuration.

They allow for multiple internet service providers

Why it fails: Multiple ISPs are supported with or without zones.

They automatically configure static routes

Why it fails: Routes must be configured separately.

They increase the speed of the internet connection

Why it fails: SD-WAN does not inherently increase hardware speed.

Global Objects

Why it fails: Global objects define the policy, not the mapping.

Device Groups

Why it fails: Groups are for organization, not mapping.

SD-WAN Rules

Why it fails: Rules define traffic selection, not interface mapping.

SSH

Why it fails: SSH is for secure access, not health probes.

FTP

Why it fails: FTP is not used for health probes.

SNMP

Why it fails: SNMP is for management, not SD-WAN health checks.

Loopback interfaces

Why it fails: Loopbacks don't have egress paths.

Aggregate interfaces

Why it fails: Aggregate is not a direct member type.

The SD-WAN template was not installed on the FortiGates; templates are only applied when a policy package is installed.

Why it fails: SD-WAN templates are applied during the installation of the policy package or when explicitly installed. However, the scenario states the template was applied, and some devices show health check down, implying installation occurred. The issue is not installation but likely routing or connectivity.

The health check is using the wrong source interface; it must be explicitly set to 'auto' to use the SD-WAN member.

Why it fails: In SD-WAN performance SLA, the source interface is typically specified as the SD-WAN member interface or left as 'auto' to use the outgoing interface. Setting it to 'auto' is not mandatory; you can specify the interface. The problem is more likely missing routes or firewall policies blocking the health check traffic.

The SD-WAN template does not support ICMP health checks; only HTTP and DNS are supported.

Why it fails: FortiGate SD-WAN performance SLA health checks support multiple protocols including ICMP, HTTP, DNS, and TCP echo. ICMP is a valid and commonly used protocol. The issue is not protocol support, but likely a configuration or connectivity problem. This option is incorrect because ICMP is fully supported for health checks.

Policy Packages with installation targets filtered by metadata.

Why it fails: Policy packages can be assigned to device groups or individual devices, and installation targets can be filtered by metadata. However, this controls policy installation, not SD-WAN template assignment. SD-WAN templates are managed separately, and dynamic mapping is the correct feature for template assignment.

Scripts that run on FortiManager to modify device settings based on metadata.

Why it fails: Scripts can automate configuration changes, but they are not the native mechanism for dynamic SD-WAN template assignment. Using scripts would require custom logic and is not as streamlined as the built-in dynamic mapping feature in SD-WAN Manager. The scenario calls for a feature, not a custom script.

Provisioning Templates with device groups based on metadata.

Why it fails: Provisioning templates are used for system-level settings like DNS, NTP, and administrators. They do not directly assign SD-WAN templates based on metadata. Device groups can be used for organization, but dynamic assignment of SD-WAN templates is not achieved through provisioning templates.

The SD-WAN template was not locked before installation, so FortiManager skipped its deployment.

Why it fails: Locking a template in FortiManager is not required for deployment; locking only prevents other administrators from editing the template. SD-WAN templates are provisioned through policy packages and do not need to be locked to install. The missing rule is more likely due to the template not being properly linked to the policy package or the FortiGate not being in the correct provisioning scope.

The Performance SLA 'MPLS' was configured with a manual update interval, so the rule could not evaluate the SLA status.

Why it fails: Performance SLA update intervals affect how often the FortiGate checks link health, not whether the SD-WAN rule is deployed. Even with a manual or long interval, the rule would still be present on the FortiGate. The absence of the rule indicates a deployment issue, not an SLA evaluation problem. The rule should exist regardless of the SLA update method.

The FortiGates are running FortiOS 6.4, which does not support SD-WAN rules with Performance SLA-based selection.

Why it fails: FortiOS 6.4 does support SD-WAN rules with Performance SLA-based selection; this feature was introduced earlier and is available in 6.4. While FortiManager 7.2 can manage FortiOS 6.4 devices, the SD-WAN rule functionality is supported. The issue is not a version limitation but a deployment configuration problem. The rule would still be installed if the template were properly applied.

If a device is offline during installation, the SD-WAN template is queued and applied when the device reconnects.

Why it fails: FortiManager does not automatically queue and apply installations to offline devices. If a device is offline, the installation will fail, and the administrator must retry after the device comes online. There is no automatic queuing mechanism for SD-WAN templates specifically.

Modifying an SD-WAN template automatically pushes the changes to all assigned devices.

Why it fails: Modifying an SD-WAN template does not automatically push changes to devices. The administrator must reinstall the policy package or perform an installation to apply the updated template. FortiManager requires an explicit installation step to propagate changes.

You can install an SD-WAN template independently without installing a policy package.

Why it fails: While you can install individual configuration objects, SD-WAN templates are designed to be installed with a policy package. Installing them independently is not a standard workflow and may lead to inconsistencies. The typical method is to install the policy package that includes the SD-WAN template.

Provisioning template with dynamic interface mapping

Why it fails: Provisioning templates are used for system-level settings and interface configurations, not specifically for SD-WAN template customization. While dynamic interface mapping can map physical interfaces to logical roles, it does not provide the granular per-device variable substitution needed for unique WAN IPs within an SD-WAN template.

Centralized policy package with installation targets

Why it fails: Policy packages are used for firewall policies and objects, not for SD-WAN template configuration. While you can assign installation targets to policy packages, this does not address the need for per-device WAN IP customization within an SD-WAN template.

SD-WAN template with per-device override

Why it fails: Per-device override in FortiManager allows you to modify the template on a specific device, but it breaks the standardization and creates a separate configuration that is no longer linked to the template. This does not allow local customization while keeping the template applied; it effectively detaches the device from the template.

Assign the Performance SLAs to the SD-WAN interfaces.

Why it fails: Performance SLAs are not directly assigned to interfaces; instead, they are referenced in SD-WAN rules. The health checks within the SLA monitor the interfaces, but the SLA itself is associated with the rule. Assigning SLAs to interfaces is not a standard configuration step in FortiManager SD-WAN templates.

Set the SD-WAN rule strategy to 'Manual'.

Why it fails: Setting the SD-WAN rule strategy to 'Manual' would disable automatic path selection based on SLA. Manual strategy requires administrator intervention to choose paths, which contradicts the goal of dynamic selection. The correct strategy for SLA-based selection is typically 'Best Quality' or 'Lowest Cost', not Manual.

Enable 'SLA Target' in the SD-WAN rule configuration.

Why it fails: While SD-WAN rules can specify SLA targets, enabling 'SLA Target' is not a separate action; it is part of defining the rule. The rule must reference the SLA, but there is no distinct 'SLA Target' setting to enable. The key is to configure the rule to use the SLA, which is covered by defining the rule with the appropriate SLA reference.

The Install Wizard can only install complete policy packages; there is no option to push individual template changes.

Why it fails: This is incorrect because FortiManager's Install Wizard does support installing individual templates or objects. It offers granular installation options, such as 'Install Policy Package' or 'Install Template'. Administrators can select specific templates to push, which is useful for making targeted updates. The ability to install templates separately is a key feature for efficient management of large deployments.

The Install Wizard can push SD-WAN template changes only if the FortiGates are in the same ADOM as the template and the template is locked.

Why it fails: The FortiGates must be in the same ADOM as the template for it to be applicable, but locking the template is not a requirement for installation. Locking prevents edits, not deployment. The Install Wizard does not require the template to be locked; it only requires that the template is properly assigned and the devices are in scope. Locking is an administrative control, not a deployment prerequisite.

The Install Wizard requires a full policy package reinstall whenever an SD-WAN template is modified, because templates are embedded in the package.

Why it fails: While SD-WAN templates are associated with policy packages, FortiManager allows updating templates independently. The Install Wizard can push template changes without reinstalling the entire policy package. This is designed to minimize configuration changes and avoid unnecessary disruption. A full reinstall is not mandatory; the wizard provides the flexibility to install only the necessary components.

Run a 'diagnose debug application sdwan' on the FortiGate.

Why it fails: While 'diagnose debug application sdwan' can provide debugging information about SD-WAN operations, it is not the primary method to verify template application. It is more useful for troubleshooting live traffic issues. Template application is better verified through configuration review or installation logs.

Check the FortiGate's system event logs for template installation messages.

Why it fails: System event logs on the FortiGate may contain messages about configuration changes, but they do not specifically confirm that an SD-WAN template was applied. FortiManager's task monitor is the authoritative source for template installation status. Event logs are more for system events like reboots or interface up/down.

Use FortiManager's 'Policy & Objects' to view the SD-WAN rules.

Why it fails: FortiManager's 'Policy & Objects' section is used for managing firewall policies and objects, not for verifying SD-WAN template application. While SD-WAN rules may be part of policies, this section does not provide a direct way to confirm template deployment status on a FortiGate.

AP Manager > SD-WAN Templates

Why it fails: AP Manager is used for managing wireless access points, not SD-WAN templates. SD-WAN templates are configured under Device Manager. This option is clearly incorrect because it refers to a different management area entirely. The scenario involves branch FortiGates, not wireless APs, so this path would not provide the required functionality.

Policy & Objects > SD-WAN Templates

Why it fails: Policy & Objects > SD-WAN Templates is where you create and manage SD-WAN templates, but it does not directly assign them to multiple FortiGates. Assignment is done through a separate mechanism, often via the 'Install Wizard' or by using a template group. This option is about template definition, not bulk assignment.

Device Manager > Provisioning Templates

Why it fails: Provisioning Templates in Device Manager are used for initial device configuration, such as interface settings and static routes, not for SD-WAN template assignment. Assigning an SD-WAN template to multiple devices requires a different workflow, typically through Policy & Objects or a dedicated SD-WAN template section. This option does not provide the centralized assignment capability needed for SD-WAN.

Device Manager

Why it fails: Device Manager in FortiManager is used to add, manage, and monitor individual devices. While it shows device status and allows per-device configuration, it does not provide a bulk method to apply SD-WAN templates to multiple devices simultaneously. Applying templates one by one would be inefficient for large deployments.

Policy & Objects

Why it fails: Policy & Objects is where firewall policies and objects are defined, including SD-WAN rules. However, it does not handle the application of SD-WAN templates to devices. Templates are applied through the Provisioning or SD-WAN template sections, not directly from Policy & Objects.

Provisioning Templates

Why it fails: Provisioning Templates are used for system-level settings and can include SD-WAN templates, but they are not the primary feature for applying SD-WAN templates. The dedicated SD-WAN template feature is more direct for this purpose. Provisioning Templates might be used in conjunction but are not the main answer.

Set the Performance SLA 'Internet_SLA' to use 'OR' logic, so that the link is within SLA if either member meets the threshold.

Why it fails: Using 'OR' logic would mean the link is considered within SLA if at least one member meets the threshold, which is the opposite of the requirement. The engineer wants both members to meet the threshold. FortiManager does not provide an 'OR' logic setting within a single Performance SLA. The correct approach is to use multiple SLAs and an SD-WAN rule that requires both.

Configure the Performance SLA 'Internet_SLA' with a 'Combined' metric that averages the latency of both members.

Why it fails: FortiManager Performance SLA objects do not support a 'Combined' metric that averages latency across multiple interfaces. Each SLA monitors a single interface. Averaging would not enforce that both members meet the threshold individually. To achieve the requirement, separate SLAs are needed. The 'Combined' option is not available in the SD-WAN template configuration.

Set the Performance SLA 'Internet_SLA' to 'All' mode, so that all members must meet the SLA for the link to be considered up.

Why it fails: In FortiManager SD-WAN templates, Performance SLA objects do not have an 'All' mode that aggregates multiple members. Each Performance SLA is typically associated with a single member interface. To evaluate multiple members together, you would need separate SLA objects or use SD-WAN rules with multiple SLA references. The 'All' mode is not a valid setting for Performance SLA in this context.

Meta Fields

Why it fails: Meta Fields are custom variables used in FortiManager to assign values to objects across multiple devices, such as IP addresses or hostnames. They are not designed to map SD-WAN member interfaces to physical ports. While Meta Fields can be used for dynamic configuration, they require manual assignment and do not automatically handle interface mapping for SD-WAN templates.

Provisioning Templates

Why it fails: Provisioning Templates in FortiManager are used to configure system-level settings like DNS, NTP, and administrative access. They do not manage SD-WAN interface mappings. Although they are part of FortiManager's central management, they operate at a different layer and cannot resolve the specific issue of mapping SD-WAN member interfaces to the correct physical ports on a different FortiGate model.

Interface Groups

Why it fails: Interface Groups are used to logically group physical interfaces for administrative purposes, such as applying policies or configuring aggregate links. They do not automatically resolve mismatches between template interface references and the target device's physical interfaces. While they can simplify management, they do not provide the dynamic mapping needed when deploying a template to a different FortiGate model.

SD-WAN template with static interface assignments and hardcoded IP addresses

Why it fails: Static interface assignments and hardcoded IPs require manual editing for each device, defeating the purpose of centralized management. This approach does not leverage FortiManager's automation capabilities and would result in IP conflicts or misconfigurations across the 40 devices. It is the opposite of what the administrator needs for scalable deployment.

SD-WAN template with manual per-device overrides after provisioning

Why it fails: Manual per-device overrides are time-consuming and error-prone, especially across 40 devices. This approach contradicts the goal of automated deployment and increases administrative overhead. FortiManager provides dynamic mapping precisely to avoid such manual intervention, so this option is not the correct solution.

SD-WAN template with a global health check profile only

Why it fails: A global health check profile defines performance monitoring parameters but does not handle interface name or IP address substitution. While health checks are part of SD-WAN, they do not address the requirement of automatic per-device interface and IP mapping. This option fails to solve the core problem of device-specific configuration.

Interface Mapping

Why it fails: Interface Mapping is used in provisioning templates to map physical interfaces to roles like 'wan1' or 'internal'. However, for SD-WAN templates, the specific feature that handles variable interface names is Dynamic Mapping. Interface Mapping does not automatically resolve interface names for SD-WAN members across different models. Hence, it is not the correct answer.

Meta Fields

Why it fails: Meta Fields are used to store custom variables for use in scripts, CLI templates, or provisioning templates. They are not designed to dynamically map SD-WAN member interfaces. While they can hold interface names, they do not provide automatic resolution based on device model. Therefore, they are not the correct feature for this scenario.

Normalized Interfaces

Why it fails: Normalized Interfaces is not a FortiManager feature. FortiManager uses interface mapping in provisioning templates, but that is different from SD-WAN template dynamic mapping. The term 'Normalized Interfaces' does not exist in FortiManager documentation. Thus, this option is incorrect.