Chapter 4: Networking, DNS, and Cluster Connectivity
Learning Objectives
Design Cohesity network topologies including bonded interfaces, VLAN tagging, and 10/25/40/100 GbE selection.
Configure VIPs, cluster partitions, and BGP/static routing for partition-aware client access.
Plan DNS, NTP, certificate, and identity prerequisites that must be in place before the cluster is bootstrapped.
Build a firewall port matrix that covers inter-node, source-to-cluster, replication, Helios, and IPMI traffic.
Troubleshoot common failure modes: LACP half-bonded, MTU mismatch, SmartDNS delegation broken, partition split-brain.
Networking is the discipline that makes or breaks a Cohesity deployment. A perfectly sized cluster with a beautifully tuned protection policy will still miss its backup window if a switch is misconfigured, an MTU mismatch is silently dropping jumbo frames, or DNS is handing clients the IP address of a node that has been down for three hours. Architects sitting the CCAE exam are expected to design the physical, logical, and service-layer network of a Cohesity cluster end-to-end — bonded NICs, VLANs, VIPs, partitions, BGP, SmartDNS, NTP, certificates, and the firewall matrix that ties it all together.
Section 1: Physical and Logical Network Layout
Pre-Section Quiz — Test Your Baseline
1. A customer's network team cannot configure MLAG/vPC across their two ToR switches but still needs dual-switch resiliency for a Cohesity cluster. Which bond mode should you recommend?
Mode 4 (LACP) on a single switch onlyMode 1 (Active-Backup) with one NIC to each switchBalance-tlb (mode 5) with weighted hashingMode 0 (Round-Robin) for active-active without LACP
2. An architect is planning IP allocation for a 6-node cluster. How many primary-network IPs (node IPs + VIPs) plus IPMI IPs must be reserved?
3. Which statement about jumbo frames in a Cohesity deployment is correct?
Only the cluster nodes need MTU 9000; switches can stay at 1500.Jumbo frames are only relevant for SmartFiles, not DataProtect ingest.MTU 9000 must be configured end-to-end (nodes, switches, uplinks, L3 hops); a single MTU 1500 hop silently drops large writes.MTU mismatches always trigger an immediate hard error and never produce intermittent slowness.
Every Cohesity node ships with at least two 10 GbE+ NICs that are intended to be bonded into a single logical interface — bond0 — that becomes the cluster's primary network. The primary network carries node-to-node traffic, VIPs (and therefore client backup/restore traffic), management UI/API, and replication. A separate IPMI interface handles out-of-band hardware management.
Figure 4.1: End-to-end network topology
flowchart LR
Source[Source Clients Backup Agents / NAS / VMware]
ToR[ToR Switch Pair MLAG / vPC]
Bond[bond0 LACP mode 4]
Node1[Node 01]
Node2[Node 02]
Node3[Node 03]
Node4[Node 04]
VIP[VIP Pool 1 VIP per node]
Part[Cluster Partition mgmt / smb / s3]
Source --> ToR
ToR --> Bond
Bond --> Node1
Bond --> Node2
Bond --> Node3
Bond --> Node4
Node1 --> VIP
Node2 --> VIP
Node3 --> VIP
Node4 --> VIP
VIP --> Part
Animation 1 — Backup Packet Flow: Source to VIP
A backup write traverses Source → ToR Switch → bond0 → Cluster Node → VIP. Each hop lights up as the packet arrives.
Bond Modes: Active-Backup vs. LACP
Cohesity supports exactly two Linux bonding modes on the primary interface — there is no balance-tlb, no balance-alb, and no Cisco PAgP. The choice is binary, and architects should be able to defend it on exam day.
Figure 4.2: Bond mode selection decision tree
flowchart TD
Start[Choose Bond Mode for bond0]
Q1{Switches support LACP / 802.3ad?}
Q2{Dual-switch resiliency required?}
Q3{MLAG / vPC configured?}
Mode1[Mode 1: Active-Backup One NIC active Sub-second failover Branch / ROBO / Lab]
Mode4Single[Mode 4: LACP Single switch port-channel Aggregate throughput]
Mode4MLAG[Mode 4: LACP MLAG / vPC pair Production default]
Fallback[Fall back to Mode 1 or fix switch config]
Start --> Q1
Q1 -->|No| Mode1
Q1 -->|Yes| Q2
Q2 -->|No| Mode4Single
Q2 -->|Yes| Q3
Q3 -->|Yes| Mode4MLAG
Q3 -->|No| Fallback
Bond mode
Linux name
Switch requirement
Throughput
Failover
Typical use
Mode 1
Active-Backup
None
One NIC at a time
Sub-second on link loss
Branch / ROBO, lab clusters, switches without LACP/MLAG
Mode 4
802.3ad LACP
Port-channel/LAG; MLAG/vPC for dual-switch
Aggregate (L3+L4 hash)
Sub-second on LACPDU loss
Production default
Animation 2 — LACP vs. Active-Backup: Live Bond Comparison
Toggle bond modes and simulate a NIC failure. Active-Backup uses one NIC; LACP load-balances across both.
Mode 4 is the production-recommended default because it gives both link redundancy and active load distribution across NICs. The trade-off is that the upstream switches must support LACP and be configured as a port-channel, LAG, or — for cross-switch resiliency — an MLAG/vPC pair so the two NICs in the bond can land on two physically separate switches and still appear to LACP as a single peer.
The bond mode is set in two places, and forgetting either is a classic deployment bug:
Per-node, in /etc/sysconfig/network-scripts/ifcfg-bond0, set BONDING_OPTS="mode=4 miimon=100".
Cluster-wide, via the iris CLI: iris_cli cluster -username=<user> -password=<pass> edit-bm bonding-mode=4.
Primary, Secondary, and IPMI Interfaces
Primary network — bond0 carrying node management IPs, all VIPs, and tagged-VLAN protocol traffic. 10 GbE is the floor.
Secondary network — optional. Often a tagged VLAN on bond0 used to segregate replication or NAS protocol traffic.
IPMI — out-of-band, 1 GbE, on a dedicated management VLAN. Uses TCP/UDP 623 plus 80/443 for Redfish/web UI.
IP allocation rule of thumb: 1 node management IP + 1 VIP per node on the primary network, plus 1 IPMI IP per node on the OOB network. A 4-node cluster needs 8 primary-network IPs plus 4 IPMI IPs.
VLAN Tagging and Speed Selection
The recommended pattern is untagged management on the native VLAN of bond0, with tagged VLANs on top for protocol traffic (SMB/NFS, replication, per-tenant access). Each tagged VLAN can carry its own VIP pool and SmartDNS subdomain.
Speed
Use case
1 GbE
IPMI only. Never the primary bond in production.
10 GbE
Hybrid nodes, mid-size clusters, replication-heavy ROBO. Production minimum.
25 GbE
Dense storage and modern hybrid nodes; common production choice in 2024+.
40/100 GbE
All-flash nodes, large SmartFiles workloads, 10+ node clusters.
Whatever speed you pick, all NICs in a single bond must run at the same speed — mixing 10 and 25 GbE in bond0 is unsupported. Enable jumbo frames (MTU 9000) end-to-end: an MTU mismatch on any L3 hop will silently drop large backup writes.
Key Points — Section 1
Bond two same-speed 10/25 GbE NICs into bond0 using LACP mode 4 with MLAG/vPC; fall back to Active-Backup (mode 1) only when LACP is unavailable.
Set the bonding mode in bothifcfg-bond0 and cluster-wide via iris_cli edit-bm — missing one is a classic deploy bug.
Per node: 1 node management IP + 1 VIP on the primary network, 1 IPMI IP on a dedicated OOB VLAN.
Run jumbo frames (MTU 9000) end-to-end — nodes, switches, and every L3 hop — or large writes drop silently.
10 GbE is the production floor; 25/40/100 GbE for dense and all-flash; never mix speeds within a single bond.
Post-Section Quiz — Check Your Understanding
1. A customer's network team cannot configure MLAG/vPC across their two ToR switches but still needs dual-switch resiliency for a Cohesity cluster. Which bond mode should you recommend?
Mode 4 (LACP) on a single switch onlyMode 1 (Active-Backup) with one NIC to each switchBalance-tlb (mode 5) with weighted hashingMode 0 (Round-Robin) for active-active without LACP
2. An architect is planning IP allocation for a 6-node cluster. How many primary-network IPs (node IPs + VIPs) plus IPMI IPs must be reserved?
3. Which statement about jumbo frames in a Cohesity deployment is correct?
Only the cluster nodes need MTU 9000; switches can stay at 1500.Jumbo frames are only relevant for SmartFiles, not DataProtect ingest.MTU 9000 must be configured end-to-end (nodes, switches, uplinks, L3 hops); a single MTU 1500 hop silently drops large writes.MTU mismatches always trigger an immediate hard error and never produce intermittent slowness.
Section 2: Cluster Partitions and VIPs
Pre-Section Quiz — Test Your Baseline
4. What is the key behavioral difference between classic DNS round-robin and Cohesity SmartDNS?
SmartDNS uses TCP only while round-robin uses UDP only.SmartDNS health-checks VIPs and removes failed nodes from rotation automatically; round-robin keeps handing out dead VIPs until a human intervenes.SmartDNS requires DHCP-assigned VIPs while round-robin uses static IPs.Round-robin supports partitions; SmartDNS does not.
5. An architect delegates cohesity.acme.com to a Cohesity cluster. To which IPs should corporate DNS NS records point for highest availability?
A single node management IP — SmartDNS only listens on node IPs.Two or more cluster VIPs — never node IPs — so a node failure does not take the entire delegated zone dark.The cluster's IPMI VLAN gateway, since SmartDNS runs out-of-band.Helios SaaS endpoints; the cluster proxies DNS through Helios.
6. When is BGP route advertisement most useful in a Cohesity design?
Single-rack, single-VLAN deployments where all clients ARP for VIPs in the same broadcast domain.Multi-subnet primary networks or stretch clusters where VIP failover needs to traverse a router boundary.Replacing SmartDNS entirely — BGP is the new load-distribution mechanism.Configuring IPMI failover between OOB management switches.
7. A cluster partition in Cohesity is best described as:
A separate cluster with its own quorum, metadata, and SpanFS instance.A logical grouping of nodes within a single physical cluster used for stretch designs, multi-tenant separation, or per-protocol routing — quorum still spans the whole cluster.A storage tier separating hot and cold data within a View Box.A reserved pool of VIPs that cannot be reassigned across nodes.
Once bond0 is up and IPs are reserved, the next layer is the cluster's VIP pool and how clients reach it. This is where Cohesity's most distinctive networking feature — SmartDNS — and its concept of cluster partitions come into play.
The Cluster Partition Concept
A cluster partition is a logical grouping of nodes within a single physical cluster, used for three scenarios:
Stretch / multi-rack designs — nodes in rack A in one partition, rack B in another, so SmartDNS returns only locally-reachable VIPs.
Multi-tenant traffic separation — tenants pinned to different partitions, each with its own VIPs and FQDN.
Mixed-protocol routing — SmartFiles SMB on one partition, S3 on another, so a hot SMB workload cannot starve S3 throughput.
A partition is not a separate cluster — quorum, metadata, and SpanFS still span the whole cluster. The partition only governs which VIPs a given client sees.
Virtual IPs (VIPs)
The recommended pattern is one VIP per node, all in the same subnet/VLAN as node management IPs and the gateway, statically assigned (no DHCP). VIPs serve every client-facing protocol: SMB (TCP 445), NFS (TCP/UDP 2049 + 111), S3 (TCP 443), management UI/API (TCP 80/443), and physical agent traffic (TCP 50051).
DNS Round-Robin vs. SmartDNS
Aspect
Classic DNS Round-Robin
SmartDNS (preferred)
Where DNS records live
Corporate DNS server
Cohesity cluster (delegated subdomain)
A-record management
Static, manually maintained
Dynamic, cluster-managed
Health awareness
None — failed nodes still get returned
Health-checked — failed VIPs auto-removed
TTL
Often 1 hour (corporate default)
Short (seconds), driving fast failover
Partition awareness
None
Returns only VIPs from healthy nodes in the relevant partition
Failover
Manual
Automatic
Figure 4.3: SmartDNS resolution flow
sequenceDiagram
participant Client as Backup Client
participant SiteDNS as Corporate DNS
participant ClusterDNS as Cohesity SmartDNS
participant Health as Cluster Health Check
participant VIP as Healthy VIP
Client->>SiteDNS: Query cohesity.acme.com
SiteDNS->>SiteDNS: Lookup NS records
SiteDNS->>ClusterDNS: Forward via NS delegation
ClusterDNS->>Health: Get currently healthy nodes
Health-->>ClusterDNS: Healthy VIP set (excludes failed)
ClusterDNS-->>SiteDNS: A records (rotated, short TTL)
SiteDNS-->>Client: Healthy VIP address
Client->>VIP: Connect (SMB / NFS / S3 / API)
VIP-->>Client: Service response
A backup client queries cohesity.acme.com. The query traverses corporate DNS, lands at the Cohesity authoritative DNS, the cluster excludes failed VIPs from the response, and the client connects to a healthy VIP.
Analogy — SmartDNS as Maitre d'. Picture a busy restaurant with eight tables. Classic DNS round-robin is a printed seating chart taped to the door: it cycles through tables 1 through 8 regardless of whether table 5 has a broken leg. SmartDNS is a maitre d' who glances across the room, sees which tables are clean and ready, and seats you there. When table 5's leg breaks, the maitre d' simply stops sending guests to it.
BGP for Multi-Subnet VIP Failover
For multi-subnet primary networks (supported from 6.6+) and stretch-cluster designs that cross a router, BGP route advertisement lets the cluster announce VIP /32 routes from individual nodes upstream. When a node fails, its /32 is withdrawn; when SmartDNS re-homes the VIP, the new node advertises the /32. BGP and SmartDNS are complementary: SmartDNS picks the VIP, BGP makes it routable across L3.
Worked Example — 4-Node Cluster, 3 Partitions
For a 4-node cluster with three partitions (mgmt VLAN 10, smartfiles-smb VLAN 100, smartfiles-s3 VLAN 200):
4 node management IPs (10.10.0.11–14)
4 IPMI IPs on the OOB VLAN (10.99.0.11–14)
4 VIPs per partition × 3 partitions = 12 VIPs total
NS delegation for cohesity.acme.com, smb.cohesity.acme.com, and s3.cohesity.acme.com — each delegated to two or more VIPs, never node IPs.
Key Points — Section 2
One VIP per node, all in the same subnet/VLAN as the gateway, statically assigned — no DHCP.
SmartDNS delegates a subdomain from corporate DNS to the cluster, returns only currently healthy VIPs, and uses short TTLs for fast failover.
Cluster partitions are logical groupings within one physical cluster — quorum still spans all nodes; partitions only steer which VIPs a client sees.
Always delegate NS records to VIPs (two or more), never to node management IPs.
BGP /32 advertisement makes VIP failover work across L3 boundaries; it complements SmartDNS, it does not replace it.
Post-Section Quiz — Check Your Understanding
4. What is the key behavioral difference between classic DNS round-robin and Cohesity SmartDNS?
SmartDNS uses TCP only while round-robin uses UDP only.SmartDNS health-checks VIPs and removes failed nodes from rotation automatically; round-robin keeps handing out dead VIPs until a human intervenes.SmartDNS requires DHCP-assigned VIPs while round-robin uses static IPs.Round-robin supports partitions; SmartDNS does not.
5. An architect delegates cohesity.acme.com to a Cohesity cluster. To which IPs should corporate DNS NS records point for highest availability?
A single node management IP — SmartDNS only listens on node IPs.Two or more cluster VIPs — never node IPs — so a node failure does not take the entire delegated zone dark.The cluster's IPMI VLAN gateway, since SmartDNS runs out-of-band.Helios SaaS endpoints; the cluster proxies DNS through Helios.
6. When is BGP route advertisement most useful in a Cohesity design?
Single-rack, single-VLAN deployments where all clients ARP for VIPs in the same broadcast domain.Multi-subnet primary networks or stretch clusters where VIP failover needs to traverse a router boundary.Replacing SmartDNS entirely — BGP is the new load-distribution mechanism.Configuring IPMI failover between OOB management switches.
7. A cluster partition in Cohesity is best described as:
A separate cluster with its own quorum, metadata, and SpanFS instance.A logical grouping of nodes within a single physical cluster used for stretch designs, multi-tenant separation, or per-protocol routing — quorum still spans the whole cluster.A storage tier separating hot and cold data within a View Box.A reserved pool of VIPs that cannot be reassigned across nodes.
Section 3: External Service Dependencies
Pre-Section Quiz — Test Your Baseline
8. A Cohesity cluster fails to authenticate AD-joined SMB clients with cryptic Kerberos errors. Forward DNS works. What is the most likely missing prerequisite?
SAML federation with Helios.Reverse DNS (PTR records) for the cluster, nodes, and VIPs — Kerberos requires both forward and reverse name resolution.An SNMPv3 trap target for the AD domain controller.Outbound HTTPS to Helios for AD federation.
9. Why is using the same NTP source as the AD domain controllers important?
It is required to register the cluster with Helios.Kerberos has a 5-minute clock skew tolerance and Cohesity's strict-consistency metadata can eject nodes ~30s out of sync from quorum.It avoids licensing audit failures.NTP source mismatch breaks SMB3 multichannel.
10. The cluster cannot reach Helios after a recent security project that introduced an outbound forward proxy with TLS interception. The local UI works fine. What is the most likely fix?
Switch from LACP to Active-Backup bonding.Upload the proxy's root CA to the cluster's trust store so it can validate intercepted TLS to Helios.Disable IPMI on each node.Re-IP all VIPs into the proxy's transit subnet.
A Cohesity cluster does not live in isolation. Before the bootstrap wizard ever runs, the architect must align with the network, identity, security, and operations teams on a shopping list of external services.
DNS, NTP, and Reverse DNS
DNS (TCP/UDP 53) — at least two upstream resolvers. The cluster needs forward and reverse DNS for itself, every node, every VIP, every replication peer, and every Helios endpoint. Reverse DNS (PTR records) is mandatory for AD/Kerberos to work.
NTP (UDP 123) — at least two NTP sources, ideally three for quorum. Cohesity's strict-consistency metadata layer is intolerant of clock skew; nodes more than ~30 seconds out can be ejected from quorum. Use the same NTP source as your AD domain controllers — Kerberos has a 5-minute clock skew tolerance.
AD/LDAP, Kerberos, and SSO Endpoints
LDAP (TCP 389) / LDAPS (TCP 636) — AD bind for user lookup. LDAPS is preferred.
Kerberos (TCP 88, UDP 88) — required for AD-joined SMB shares and the cluster's machine account.
SAML / OIDC (TCP 443 outbound) — for SSO with Okta, Entra ID, Ping, etc.
DNS prerequisite — the AD domain's _ldap._tcp.<domain> SRV records must resolve.
Certificate Authority and TLS Chains
Out of the box the cluster ships with a self-signed cert. For production, replace it with a CA-signed SAN certificate covering the cluster hostname, every SmartDNS-delegated subdomain, and optionally individual node FQDNs. For replication and Helios connectivity:
Trust the peer cluster's CA (cluster-to-cluster replication).
Trust public CAs for outbound HTTPS to Helios.
If a forward proxy intercepts TLS, upload the proxy's root CA — otherwise Helios calls fail with cert validation errors.
SMTP, SNMP, and Syslog Targets
SMTP (TCP 25 / 465 / 587 outbound) — for email alerts. Most enterprises use authenticated relay on 587 with STARTTLS.
SNMP (UDP 161 inbound, UDP 162 outbound traps) — for monitoring system integration.
Syslog (UDP 514 / TCP 6514 outbound) — for SIEM integration. TCP 6514 with TLS is preferred for compliance environments.
Key Points — Section 3
Forward and reverse DNS for cluster, nodes, and VIPs is non-negotiable — missing PTRs break Kerberos.
Use the same NTP source as your AD domain controllers; Cohesity nodes more than ~30s out can be ejected from quorum.
Replace the self-signed TLS cert with a CA-signed SAN certificate covering the cluster FQDN and all SmartDNS subdomains.
If outbound HTTPS to Helios is intercepted by a forward proxy, upload the proxy's root CA to the cluster trust store.
Plan SMTP, SNMP, and Syslog targets as Day-0 deliverables, not Day-2 polish — security review will demand them.
Post-Section Quiz — Check Your Understanding
8. A Cohesity cluster fails to authenticate AD-joined SMB clients with cryptic Kerberos errors. Forward DNS works. What is the most likely missing prerequisite?
SAML federation with Helios.Reverse DNS (PTR records) for the cluster, nodes, and VIPs — Kerberos requires both forward and reverse name resolution.An SNMPv3 trap target for the AD domain controller.Outbound HTTPS to Helios for AD federation.
9. Why is using the same NTP source as the AD domain controllers important?
It is required to register the cluster with Helios.Kerberos has a 5-minute clock skew tolerance and Cohesity's strict-consistency metadata can eject nodes ~30s out of sync from quorum.It avoids licensing audit failures.NTP source mismatch breaks SMB3 multichannel.
10. The cluster cannot reach Helios after a recent security project that introduced an outbound forward proxy with TLS interception. The local UI works fine. What is the most likely fix?
Switch from LACP to Active-Backup bonding.Upload the proxy's root CA to the cluster's trust store so it can validate intercepted TLS to Helios.Disable IPMI on each node.Re-IP all VIPs into the proxy's transit subnet.
Section 4: Firewalls and Port Requirements
Pre-Section Quiz — Test Your Baseline
11. A physical Linux backup agent cannot reach the Cohesity cluster. Network team confirms general L3 reachability. Which TCP port is most important to verify is open from the agent to cluster VIPs?
12. For inter-cluster replication between a primary and DR Cohesity cluster, which TCP ports must be open bidirectionally?
22 and 80 only11111, 11114, 24444, and 44353 and 123 only25, 161, and 514
13. Which configuration is a security finding the architect must avoid?
Placing IPMI on a dedicated OOB management VLAN.Putting IPMI on the same primary VLAN as VIPs and backup traffic.Using TCP 6514 with TLS for syslog to a SIEM.Using LDAPS (TCP 636) instead of plain LDAP (389).
14. Which statement about Helios connectivity is correct?
Helios initiates inbound connections to the cluster on TCP 443.The cluster initiates an outbound HTTPS (TCP 443) connection to Helios; Helios never reaches in.Helios uses TCP 50051 for cluster control.Helios connectivity requires opening UDP 53 inbound on every node.
15. SmartDNS NS delegation in corporate DNS has been pointed at node01's and node02's management IPs. node01 goes down for maintenance. What happens?
Nothing — SmartDNS automatically promotes another node IP.Half the delegated DNS zone goes dark because NS records point at a dead node IP. Always delegate to two or more VIPs, never node IPs.Helios re-delegates the zone to a healthy region.Clients automatically retry against the cluster's IPMI interface on TCP 623.
The CCAE exam loves port-matrix questions. Memorize the table below; an architect who can rattle off "TCP 50051 is the physical-agent channel, TCP 11114 is replication-inbound, UDP 123 is NTP" will save themselves several scenario questions.
Helios is a SaaS control plane. The cluster initiates an outbound HTTPS (TCP 443) tunnel to Helios — Helios never reaches in. The cluster needs outbound TCP 443 to helios.cohesity.com and the regional endpoints. If a forward proxy intercepts TLS, its CA must be trusted by the cluster.
Common Firewall Misconfigurations
TCP 50051 not opened from cluster VIPs — backups fail with "agent unreachable."
Asymmetric replication ports — opening 11111 outbound on the source side but not inbound on the DR side.
MTU 1500 on a transit switch while both endpoints are MTU 9000 — silent drops, intermittent slowness.
Missing reverse DNS — Kerberos breaks, AD-joined SMB protections fail.
Helios proxy CA not trusted — cluster shows "disconnected from Helios" while local UI looks fine.
IPMI on the primary VLAN — security finding waiting to happen.
SmartDNS NS delegation pointed at node IPs instead of VIPs — when the named node fails, the entire delegated zone goes dark.
Inter-cluster replication needs bidirectional TCP 11111, 11114, 24444, and 443.
NAS source ports: SMB 445, NFS 2049 + 111 (rpcbind); VMware uses TCP 443 to vCenter/ESXi.
Helios is outbound-only on TCP 443; intercepting proxies need their root CA uploaded to the cluster.
IPMI must live on a dedicated OOB management VLAN, never on the primary network.
Post-Section Quiz — Check Your Understanding
11. A physical Linux backup agent cannot reach the Cohesity cluster. Network team confirms general L3 reachability. Which TCP port is most important to verify is open from the agent to cluster VIPs?
12. For inter-cluster replication between a primary and DR Cohesity cluster, which TCP ports must be open bidirectionally?
22 and 80 only11111, 11114, 24444, and 44353 and 123 only25, 161, and 514
13. Which configuration is a security finding the architect must avoid?
Placing IPMI on a dedicated OOB management VLAN.Putting IPMI on the same primary VLAN as VIPs and backup traffic.Using TCP 6514 with TLS for syslog to a SIEM.Using LDAPS (TCP 636) instead of plain LDAP (389).
14. Which statement about Helios connectivity is correct?
Helios initiates inbound connections to the cluster on TCP 443.The cluster initiates an outbound HTTPS (TCP 443) connection to Helios; Helios never reaches in.Helios uses TCP 50051 for cluster control.Helios connectivity requires opening UDP 53 inbound on every node.
15. SmartDNS NS delegation in corporate DNS has been pointed at node01's and node02's management IPs. node01 goes down for maintenance. What happens?
Nothing — SmartDNS automatically promotes another node IP.Half the delegated DNS zone goes dark because NS records point at a dead node IP. Always delegate to two or more VIPs, never node IPs.Helios re-delegates the zone to a healthy region.Clients automatically retry against the cluster's IPMI interface on TCP 623.