ServiceNow FortiGate HA Cluster and VDOM Relationship Modeling

[Henrik Jutterst]

Posting a question from a college who works within network department. The customer want to use relations as close to OOB and Discovery as possible. 

---------

While reviewing how FortiGate HA clusters and VDOMs should be modelled in CMDB, I noticed that the ServiceNow/Fortinet discovery documentation appears to model both the Cluster CI and the VDOM CIs as running directly on the physical firewall nodes.

I understand the rationale when looking at the cluster or the VDOM in isolation, since both ultimately depend on the underlying firewall appliances. However, the model becomes less intuitive when all three layers exist simultaneously (node, cluster, and VDOM).

From an operational perspective:

Monitoring targets the cluster management IP.

Services are mapped to VDOMs.

Configuration changes are performed against the cluster.

Individual firewall nodes are typically only relevant during HA or hardware-related events.

Another reason for the question is that, once a cluster object exists, most operationally relevant constructs are associated with the cluster rather than the individual members. Examples include VDOMs, VIPs, NAT policies, routing, and management access. This makes the cluster the natural point of interaction for operations, monitoring, and service mapping, even though those functions are ultimately implemented by the underlying HA nodes.

Because of this, the operational view of the platform feels more like:

Firewall Nodes -> Cluster -> VDOM

Where I struggle is that the current relationship model appears to flatten the hierarchy by relating both the Cluster and the VDOM directly to the firewall nodes. While technically correct, it seems to diverge from how the platform is operated and consumed.

Can ServiceNow confirm whether this is an intentional design decision? If so, what is the rationale for modeling the relationships this way when a cluster object is also present?

If there is no specific rationale behind the current relationship model, could it be reviewed to determine whether a hierarchical relationship closer to Firewall Nodes -> Cluster -> VDOM would better represent the operational dependency chain? 

-----------

Kind regards

/Henrik

[VJ_Srivastava]

Hello @Henrik Jutterst,

From an enterprise architecture perspective, your network colleague has identified a fundamental tension within the CMDB: the conflict between Infrastructure topology and Service topology.

ServiceNow’s default flattened model is technically accurate from a bottom-up hardware discovery standpoint, but it is architecturally flawed for modern ITOM Event Management and Service Mapping. In a mature Common Service Data Model (CSDM) deployment, logical routing constructs (Clusters and VDOMs) must be decoupled from the physical nodes to accurately represent High Availability (HA). If a secondary firewall node drops, the overarching business service shouldn't immediately flag as degraded if the cluster successfully failed over and handled the traffic.

To build a resilient, scalable architecture that supports AIOps and automated root-cause analysis, your CMDB must reflect operational reality, not just physical wiring. I strongly advise extending the OOB pattern to build out this hierarchical model (Nodes -> Cluster -> VDOM). Abstracting the logical service layer away from the physical hardware layer is a critical architectural step for organizations looking to mature their ITOM visibility.

[NehaG8791370651]

Hi @Henrik Jutterst,

This is a very common observation when dealing with complex network discovery! The reason ServiceNow’s out-of-the-box (OOB) patterns flatten this hierarchy—binding both the Cluster and VDOM directly to the physical nodes—is deeply rooted in how the platform handles hardware asset management and software licensing. Horizontal Discovery is fundamentally designed to anchor logical components back to the physical hardware executing them.

However, as your network colleague rightly pointed out, this creates a headache for Service Mapping and dependency views. If your organization wants to enforce the Firewall Nodes -> Cluster -> VDOM relationship without entirely rewriting the OOB patterns, the cleanest technical approach is to utilize a post-processing script within the Fortinet Discovery pattern.

You can use a quick script to intercept the payload right before it hits the Identification and Reconciliation Engine (IRE). The script can drop the direct VDOM -> Node relationships and replace them with VDOM -> Cluster relationships. Just keep in mind that whenever you customize OOB pattern logic, you must add a mandatory regression test for this specific pattern during your next ServiceNow family release upgrade to ensure your custom relationships aren't overwritten!