How to Create a Broadcast Domain, VLAN, and NAS LIFs on NetApp ONTAP

Figure 01 / Tagged NAS network on a NetApp ONTAP cluster

What you will build

• SVM: nas_svm01
• Broadcast domain: bd-vlan100-nas · IPspace Default · MTU 1500
• VLAN ID: 100, on interface groups a0a and a0b across all nodes
• Subnet: 10.10.20.64/27 · four NAS LIFs at 10.10.20.66–.69, one per node (cluster1-01 … cluster1-04)

Prerequisites

• VLAN 100 is configured and allowed on every connected switch trunk.
• The SVM nas_svm01 already exists.
• The interface groups a0a and a0b already exist on each node.
• You have a Cluster Admin account and the cluster management IP.

Part 1 — Method A: System Manager (GUI)

Step 1: Create the broadcast domain

Go to Network > Overview > Broadcast Domains and click Add. Name it bd-vlan100-nas, set IPspace to Default and MTU to 1500, and save it without selecting ports — the VLAN ports get added after they exist.

Step 2: Create the VLAN

Go to Network > Ethernet Ports and click + VLAN. Enter VLAN ID 100 and create it on a0a and a0b on every node (cluster1-01 through cluster1-04). Confirm each new VLAN port lands in the bd-vlan100-nas broadcast domain.

Step 3: Create the NAS LIFs

Go to Network > Overview > Network Interfaces and click Add. Create four data LIFs for nas_svm01 using 10.10.20.66, .67, .68, and .69 — assign each LIF to its node and a VLAN-100 port.

Step 4: Verify

Back in Network > Network Interfaces, confirm all four LIFs show Up/Up and Home = True.

Part 2 — Method B: CLI

This is the command-line equivalent of Part 1 — the identical broadcast domain, VLAN, and NAS LIFs, built from the cluster shell instead of System Manager. Run this instead of Part 1, not after it.

1. Create the broadcast domain

network port broadcast-domain create -broadcast-domain bd-vlan100-nas -ipspace Default -mtu 1500

# verify
network port broadcast-domain show -broadcast-domain bd-vlan100-nas

2. Create VLAN 100 on each node and interface group

network port vlan create -node cluster1-01 -port a0a -vlan-id 100
network port vlan create -node cluster1-01 -port a0b -vlan-id 100
network port vlan create -node cluster1-02 -port a0a -vlan-id 100
network port vlan create -node cluster1-02 -port a0b -vlan-id 100
network port vlan create -node cluster1-03 -port a0a -vlan-id 100
network port vlan create -node cluster1-03 -port a0b -vlan-id 100
network port vlan create -node cluster1-04 -port a0a -vlan-id 100
network port vlan create -node cluster1-04 -port a0b -vlan-id 100

# verify
network port vlan show -vlan-id 100

3. Add the VLAN ports to the broadcast domain

network port broadcast-domain add-ports -broadcast-domain bd-vlan100-nas -ports cluster1-01:a0a-100,cluster1-01:a0b-100,cluster1-02:a0a-100,cluster1-02:a0b-100,cluster1-03:a0a-100,cluster1-03:a0b-100,cluster1-04:a0a-100,cluster1-04:a0b-100

# verify
network port broadcast-domain show-ports -broadcast-domain bd-vlan100-nas

4. Create the NAS data LIFs

network interface create -vserver nas_svm01 -lif lif_nas_svm01_100_01 -service-policy default-data-files -home-node cluster1-01 -home-port a0b-100 -address 10.10.20.66 -netmask-length 27
network interface create -vserver nas_svm01 -lif lif_nas_svm01_100_02 -service-policy default-data-files -home-node cluster1-02 -home-port a0b-100 -address 10.10.20.67 -netmask-length 27
network interface create -vserver nas_svm01 -lif lif_nas_svm01_100_03 -service-policy default-data-files -home-node cluster1-03 -home-port a0b-100 -address 10.10.20.68 -netmask-length 27
network interface create -vserver nas_svm01 -lif lif_nas_svm01_100_04 -service-policy default-data-files -home-node cluster1-04 -home-port a0a-100 -address 10.10.20.69 -netmask-length 27

5. Verify LIF status

network interface show -vserver nas_svm01 -fields address,home-node,home-port,status-admin,status-oper,is-home

Validation checklist

• Broadcast domain bd-vlan100-nas created (MTU 1500, IPspace Default).
• VLAN 100 created on a0a and a0b on all four nodes.
• All eight VLAN ports added to the broadcast domain.
• Four NAS LIFs created for nas_svm01.
• All LIFs report Up/Up and Home = True.
• Connectivity validated from a NAS client on VLAN 100.

ONTAP network architecture: ports, VLANs, broadcast domains, and LIFs

Before the commands, hold the mental model. In ONTAP networking, a physical port carries one or more tagged VLANs; each VLAN port joins exactly one broadcast domain; that broadcast domain seeds a failover group; and a data LIF rides on a port inside the domain, failing over only to ports the failover group says are reachable. Get the layering right and LIF failover behaves predictably; get it wrong and a LIF comes up offline or a broadcast domain partitions. The three diagrams below are the reference picture for the rest of this guide.

Figure 02 / Switch trunk to data LIFs — two VLANs on one physical uplink

What the administrator is seeing: a single trunk feeding two logically isolated networks. Because each VLAN port belongs to its own broadcast domain, a reachability problem on the NFS network never drags CIFS LIFs down with it. That isolation is the practical payoff of broadcast domains, and it is why ONTAP networking best practices favor one broadcast domain per Layer 2 network rather than one giant shared domain.

Figure 03 / The ONTAP networking object chain

Figure 04 / One broadcast domain spanning an HA pair

Complete ONTAP broadcast domain deployment example

This is the full end-to-end ONTAP VLAN configuration for a new NFS network on VLAN 120, from VLAN creation through a verified data LIF. Run it from the cluster shell as a Cluster Admin. Sample output is shown so you know what a healthy result looks like at each step; substitute your own node names, ports, and addresses (the values below use documentation-range IPs).

1. Create the VLAN ports

Tag VLAN 120 onto each node’s physical data ports. The VLAN port name is <port>-<vlan-id>.

network port vlan create -node cluster1-01 -port e0c -vlan-id 120
network port vlan create -node cluster1-01 -port e0d -vlan-id 120
network port vlan create -node cluster1-02 -port e0c -vlan-id 120
network port vlan create -node cluster1-02 -port e0d -vlan-id 120

2. Verify the VLAN ports

network port vlan show -vlan-id 120

         Network       Network
Node     VLAN Name     Port    VLAN ID  MAC Address
-------- ------------- ------- -------- -----------------
cluster1-01
         e0c-120       e0c     120      90:e2:ba:11:22:01
         e0d-120       e0d     120      90:e2:ba:11:22:02
cluster1-02
         e0c-120       e0c     120      90:e2:ba:33:44:01
         e0d-120       e0d     120      90:e2:ba:33:44:02
4 entries were displayed.

3. Create the broadcast domain

Create bd-nfs-120 in the Default IPspace with the MTU your switch trunk is configured for. Use 9000 only if jumbo frames are enabled end to end; otherwise 1500.

network port broadcast-domain create -broadcast-domain bd-nfs-120 -mtu 9000 -ipspace Default

4. Add the VLAN ports to the broadcast domain

network port broadcast-domain add-ports -broadcast-domain bd-nfs-120 -ports cluster1-01:e0c-120,cluster1-01:e0d-120,cluster1-02:e0c-120,cluster1-02:e0d-120

5. Verify reachability

On ONTAP 9.8 and later, network port reachability show tells you whether each port actually reaches the broadcast domain ONTAP expects. ok is the only state you want; anything else is covered in the troubleshooting section below.

network port reachability show -detail -node cluster1-01 -port e0c-120

                      Reachable
Node    Port      Status        Broadcast Domains
------- --------- ------------- -----------------
cluster1-01
        e0c-120   ok            bd-nfs-120
  Expected Broadcast Domain: bd-nfs-120
  Reachable Broadcast Domains: bd-nfs-120

6. (Optional) Create a dedicated IPspace for multi-tenant isolation

If this network belongs to an isolated tenant rather than the shared Default IPspace, create the IPspace first and build the broadcast domain inside it. Most single-tenant clusters skip this and stay in Default.

network ipspace create -ipspace ips-tenant-a
network port broadcast-domain create -broadcast-domain bd-nfs-120 -mtu 9000 -ipspace ips-tenant-a

7. Create the NFS data LIF

Create the LIF on a VLAN 120 port inside the broadcast domain. ONTAP assigns its failover group from the broadcast domain automatically.

network interface create -vserver nas_svm01 -lif nfs_lif01 -service-policy default-data-files -home-node cluster1-01 -home-port e0c-120 -address 10.10.20.130 -netmask-length 24

8. Verify the configuration

network interface show -vserver nas_svm01 -lif nfs_lif01

            Logical    Status     Network          Current   Current Is
Vserver     Interface  Admin/Oper Address/Mask     Node      Port    Home
----------- ---------- ---------- ---------------- --------- ------- ----
nas_svm01
            nfs_lif01  up/up      10.10.20.130/24   cluster1-01 e0c-120 true

up/up with Is Home = true is the finish line: the LIF is administratively up, operationally up, and sitting on its home port. If you see up/down, jump to the troubleshooting section — it is almost always a broadcast domain or reachability problem, not the LIF itself.

Broadcast domain vs VLAN vs IPspace

These three constructs get conflated constantly, and the confusion is the root of most ONTAP networking design mistakes. They operate at different layers and solve different problems. A VLAN is Layer 2 segmentation on the wire. A broadcast domain is ONTAP’s reachability-and-failover grouping of ports. An IPspace is a multi-tenant isolation boundary that lets the same IP subnet exist twice in one cluster without collision.

Real-world example. A service provider hosts two customers who both use 10.0.0.0/24 for NAS. In a single IPspace that is an immediate address collision. The fix: one IPspace per customer (ips-tenant-a, ips-tenant-b), each containing its own broadcast domain built on its own VLAN. The VLAN keeps the traffic apart on the wire, the broadcast domain governs failover within each tenant, and the IPspace lets the identical subnet exist twice without conflict. On the SAN side the equivalent isolation discipline is single-initiator zoning — see our Cisco MDS zoning field guide for the Fibre Channel counterpart.

ONTAP version considerations

Broadcast domain and VLAN behavior changed materially across recent ONTAP releases. If you administer a fleet at mixed versions — or you are planning a cluster upgrade — the differences below determine whether ONTAP creates broadcast domains for you, whether it will second-guess a manual choice, and how it surfaces unhealthy ports.

Why upgraders should care: a cluster moving from 9.7 to 9.8+ shifts from “ONTAP does exactly what you typed” to “ONTAP actively reconciles ports against detected reachability.” Administrators who do not expect that can be surprised when the reachability scan reassigns a port. The behavior is correct and desirable — but it rewards understanding the model rather than fighting it.

Troubleshooting ONTAP broadcast domains and VLANs

Five failure modes account for the overwhelming majority of broadcast domain and LIF failover tickets. Each one below has a concrete diagnosis path and fix. The quick-reference table follows.

Problem 1: LIF remains offline (up/down) after creation

A freshly created LIF that reports up/down is almost never a LIF fault. The usual causes are a VLAN port that was never added to the broadcast domain, an address in the wrong subnet, or a failover target that does not exist. Confirm the home port is actually in the domain, then verify the subnet matches the VLAN gateway.

network port broadcast-domain show -broadcast-domain bd-nfs-120
network interface show -lif nfs_lif01 -fields home-port,failover-group,subnet-name

Problem 2: Broadcast domain partitioned

A partitioned broadcast domain means its ports no longer all share Layer 2 reachability — some ports can reach each other and some cannot, so failover across the partition silently breaks. The reachability scan is the authoritative diagnosis.

network port reachability show -detail

# a partition shows as "misconfigured-reachability" or split reachable domains
# repair the affected port back to its correct domain:
network port reachability repair -node cluster1-02 -port e0d-120

A misconfigured-reachability status means the port has reachability to a broadcast domain other than the one it is configured for — usually a switch-side VLAN or trunk change. repair reassigns the port to the domain ONTAP actually detects.

Problem 3: Port not reachable

A port reporting no-reachability is a wire-or-switch problem, not an ONTAP one. Work outward: confirm the switch trunk allows the VLAN, confirm tagging matches (a port expecting tagged frames on an access port sees nothing), and confirm MTU agreement — a jumbo-frame broadcast domain on a 1500-MTU switch path produces exactly this symptom.

network port show -node cluster1-01 -port e0c-120 -fields mtu,link-status
network port reachability show -node cluster1-01 -port e0c-120

Problem 4: Node ports missing from the broadcast domain

If only one node’s ports are in the domain, LIFs on the other node cannot fail over to it — the classic “works until takeover” outage. List the domain’s ports and add any node that is missing.

network port broadcast-domain show -broadcast-domain bd-nfs-120 -instance
network port broadcast-domain add-ports -broadcast-domain bd-nfs-120 -ports cluster1-02:e0c-120,cluster1-02:e0d-120

Problem 5: Failover group not populated correctly

ONTAP builds the failover group from the broadcast domain’s ports. If a LIF’s failover targets look wrong, the fault is upstream in the broadcast domain membership. Verify the group, then confirm the LIF references it.

network interface failover-groups show -failover-group bd-nfs-120
network interface show -lif nfs_lif01 -fields failover-group,failover-policy

For production clusters carrying live NAS workloads, these changes belong under change control with a reviewed rollback. That is the work WUC’s managed storage and data-center networking services handle day to day.

Creating broadcast domains in ONTAP System Manager

The CLI walkthrough above is the fastest path for engineers who live in the cluster shell. For teams who standardize on the GUI, here is the same NFS-on-VLAN-120 deployment in ONTAP System Manager, with the result you should expect to see after each step. The navigation path is the same on every modern ONTAP release; the one screen newer administrators miss is the reachability check between creating the VLAN and creating the LIF.

Figure 05 / System Manager navigation flow

Step-by-step, with expected results

1. Network > Overview. Confirm the physical ports (e0c, e0d) show up. Expected: both ports green, no existing VLAN 120.
2. Ethernet Ports > + VLAN. Create VLAN ID 120 on e0c and e0d for each node. Expected: new ports e0c-120 and e0d-120 appear.
3. Verify port reachability. On ONTAP 9.8+, the port detail shows its reachable broadcast domain. Expected: reachability ok; if it reads no-reachability, fix the switch trunk before continuing.
4. Broadcast Domains > Add. Create bd-nfs-120 with the correct MTU and IPspace. Expected: the VLAN 120 ports are listed as members.
5. Network Interfaces > Add. Create nfs_lif01 for nas_svm01 on a VLAN 120 port. From ONTAP 9.12, System Manager shows the auto-selected broadcast domain — override only with cause. Expected: LIF status up/up.
6. Test connectivity. Mount the export from a client on VLAN 120. Expected: successful mount and read/write; the LIF stays on its home port.

IPspace isolation for multi-tenant clusters

When a single cluster serves tenants who must never see one another’s traffic — or who use overlapping IP ranges — the broadcast domain alone is not enough. IPspaces give each tenant a private network namespace: its own broadcast domains, VLANs, and LIFs, with full address-space isolation. The same subnet can exist in two IPspaces without collision.

Figure 06 / Two IPspaces, the same subnet, zero collision

Real-world ONTAP networking deployment examples

Patterns beat theory. Four deployments below show how broadcast domain, VLAN, and IPspace design changes with the workload and the resilience requirement.

Example 1: healthcare — CIFS for clinical systems, NFS for VMware

A hospital runs clinical applications over CIFS and a VMware estate over NFS, on one ONTAP cluster, with strict separation and high availability. Design: two VLANs (CIFS on VLAN 20, NFS on VLAN 120), two broadcast domains spanning the HA pair, and one data LIF per node per network. The CIFS and NFS domains stay independent so a reachability problem on the clinical network cannot affect the VMware datastores, and every LIF has a same-domain partner port to survive a controller takeover. Both networks live in the Default IPspace because there is a single tenant. The decision that matters: separate broadcast domains per Layer 2 network, not a shared domain, so failure domains stay small.

Example 2: VMware NFS datastore network

For NFS datastores, redundancy and frame sizing dominate. Design: a dedicated NFS VLAN, a broadcast domain at MTU 9000 (jumbo frames end to end — verified on the switch), and at least one NAS LIF per node so vSphere always has a local path. Best practice is to keep the datastore network on its own broadcast domain so its MTU and failover behavior are independent of every other workload, and to confirm reachability at MTU 9000 before mounting — a silent 9000-on-a-1500-path mismatch is the classic cause of datastores that mount but stall under load.

Example 3: multi-tenant service provider

A provider hosts many customers on shared hardware, several of whom use overlapping IP ranges. Design: one SVM and one IPspace per tenant, each IPspace containing its own broadcast domain and VLAN (see Figure 06). The IPspace boundary delivers full address-space isolation, so two tenants can both use 10.0.0.0/24 without conflict; the per-tenant VLAN keeps traffic separated on the wire; the per-tenant broadcast domain governs failover inside each tenant. This is the only design that safely supports overlapping subnets on one cluster.

Example 4: MetroCluster across two sites

In a MetroCluster, networking must survive a whole-site loss. Design considerations: broadcast domains and their VLANs must exist identically at both sites, with the same names and MTU, so a LIF can come up at the surviving site after a switchover. Layer 2 reachability for each VLAN has to be present at both locations — the most common MetroCluster networking defect is a VLAN that is trunked at site A but missing at site B, which works perfectly until the day you actually fail over. Validate reachability at both sites, and rehearse a switchover in a maintenance window rather than discovering the gap during a real event.

Automating broadcast domain and LIF deployment

At fleet scale you do not click through System Manager forty times — you codify the build. All three approaches below create the same VLAN 120 / bd-nfs-120 / nfs_lif01 stack. Keep credentials out of source: use environment variables or a vault, never hard-coded secrets, and validate TLS against the cluster certificate in production.

ONTAP REST API

The ONTAP REST API is the modern programmatic interface. Authenticate with HTTP Basic over HTTPS against the cluster management LIF, then POST each object.

# 1. Create the VLAN port (e0c-120 on cluster1-01)
curl -sk -u "$ONTAP_USER:$ONTAP_PASS" -X POST \
  https://10.10.20.10/api/network/ethernet/ports \
  -H "Content-Type: application/json" \
  -d '{"type":"vlan","node":{"name":"cluster1-01"},"vlan":{"base_port":{"name":"e0c","node":{"name":"cluster1-01"}},"tag":120}}'

# 2. Create the broadcast domain
curl -sk -u "$ONTAP_USER:$ONTAP_PASS" -X POST \
  https://10.10.20.10/api/network/ethernet/broadcast-domains \
  -H "Content-Type: application/json" \
  -d '{"name":"bd-nfs-120","mtu":9000,"ipspace":{"name":"Default"}}'

# 3. Create the NAS data LIF
curl -sk -u "$ONTAP_USER:$ONTAP_PASS" -X POST \
  https://10.10.20.10/api/network/ip/interfaces \
  -H "Content-Type: application/json" \
  -d '{"name":"nfs_lif01","svm":{"name":"nas_svm01"},"ip":{"address":"10.10.20.130","netmask":"24"},"location":{"home_node":{"name":"cluster1-01"},"home_port":{"name":"e0c-120","node":{"name":"cluster1-01"}}},"service_policy":{"name":"default-data-files"}}'

# Typical response: HTTP 201 Created with a job reference, e.g.
# {"job":{"uuid":"f1a2...","_links":{"self":{"href":"/api/cluster/jobs/f1a2..."}}}}

The -k flag skips certificate validation for lab use only; in production drop -k and trust the cluster CA.

Python (requests)

import os
import requests

CLUSTER = "10.10.20.10"
AUTH = (os.environ["ONTAP_USER"], os.environ["ONTAP_PASS"])
BASE = f"https://{CLUSTER}/api"

session = requests.Session()
session.auth = AUTH
session.verify = "/etc/ssl/ontap-ca.pem"   # trust the cluster CA in prod

def post(path, payload):
    r = session.post(f"{BASE}{path}", json=payload, timeout=30)
    r.raise_for_status()
    return r.json()

post("/network/ethernet/ports", {
    "type": "vlan",
    "node": {"name": "cluster1-01"},
    "vlan": {"base_port": {"name": "e0c", "node": {"name": "cluster1-01"}}, "tag": 120},
})

post("/network/ethernet/broadcast-domains", {
    "name": "bd-nfs-120", "mtu": 9000, "ipspace": {"name": "Default"},
})

post("/network/ip/interfaces", {
    "name": "nfs_lif01",
    "svm": {"name": "nas_svm01"},
    "ip": {"address": "10.10.20.130", "netmask": "24"},
    "location": {
        "home_node": {"name": "cluster1-01"},
        "home_port": {"name": "e0c-120", "node": {"name": "cluster1-01"}},
    },
    "service_policy": {"name": "default-data-files"},
})

print("VLAN, broadcast domain, and NAS LIF created.")

Ansible (netapp.ontap collection)

Ansible is the cleanest choice for repeatable, idempotent fleet deployments. Store credentials in Ansible Vault, never in plain inventory.

# inventory.yml
all:
  hosts:
    cluster1:
      ansible_host: 10.10.20.10
      netapp_username: "{{ vault_ontap_user }}"
      netapp_password: "{{ vault_ontap_pass }}"

# deploy-nfs-net.yml
- name: Deploy VLAN 120 NFS networking
  hosts: cluster1
  gather_facts: false
  collections: [netapp.ontap]
  vars:
    login: &login
      hostname: "{{ ansible_host }}"
      username: "{{ netapp_username }}"
      password: "{{ netapp_password }}"
      https: true
      validate_certs: true
  tasks:
    - name: Create VLAN 120 on e0c
      na_ontap_net_vlan:
        state: present
        node: cluster1-01
        parent_interface: e0c
        vlanid: 120
        <<: *login

    - name: Create broadcast domain bd-nfs-120
      na_ontap_broadcast_domain:
        state: present
        name: bd-nfs-120
        mtu: 9000
        ipspace: Default
        ports: ["cluster1-01:e0c-120","cluster1-01:e0d-120"]
        <<: *login

    - name: Create NAS data LIF
      na_ontap_interface:
        state: present
        interface_name: nfs_lif01
        vserver: nas_svm01
        home_node: cluster1-01
        home_port: e0c-120
        address: 10.10.20.130
        netmask_length: 24
        service_policy: default-data-files
        <<: *login

# execute
ansible-playbook -i inventory.yml deploy-nfs-net.yml --ask-vault-pass

Because each module is declarative, re-running the playbook is safe: ports and domains that already exist are left untouched. That idempotence is the whole point of automating ONTAP networking — the same playbook builds a new cluster and audits an existing one.

ONTAP networking object quick-reference matrix

One table to keep the five objects straight — what each one is for, where it sits, and whether a NAS LIF depends on it.

Field notes from production ONTAP deployments

WUC’s storage engineering practice designs, deploys, and operates NetApp ONTAP networking for enterprise and regulated environments — healthcare, financial services, and multi-site infrastructure — across single clusters and MetroCluster. The guidance in this article is what the practice applies on production clusters carrying live NAS workloads, distilled into the lessons that repeat across engagements:

• MTU mismatches fail silently. A jumbo-frame broadcast domain on a 1500-MTU switch path mounts fine and then stalls under load. Verify MTU end to end before you trust the network, not after a user complains.
• Add the partner node’s ports before you test failover. The “works until takeover” outage is almost always a broadcast domain missing one node’s VLAN ports. Confirm both controllers are in the domain, then rehearse a takeover in a window.
• Trust the reachability engine on 9.8+. When a port reads misconfigured-reachability, the switch changed — let network port reachability repair reconcile it rather than hand-editing membership.
• Document the VLAN-to-broadcast-domain map. The single most useful artifact in an incident is a current table of which VLAN maps to which broadcast domain on which ports. Keep it with the runbook.
• MetroCluster gaps hide until switchover. A VLAN trunked at one site but not the other is invisible in steady state. Validate Layer 2 reachability at both sites, every time.

ONTAP NAS networking deployment checklist

A printable field checklist for a broadcast domain, VLAN, and NAS LIF build. Run it top to bottom; do not create the LIF until reachability is confirmed.

Frequently asked questions

What is a broadcast domain in ONTAP?

A broadcast domain is a group of network ports across the cluster that share the same Layer 2 reachability and MTU. It defines where a LIF is allowed to live and where it may fail over, and it is the object from which ONTAP derives failover groups.

Can multiple VLANs exist in the same broadcast domain?

No. A broadcast domain represents one Layer 2 network, so its ports should all carry the same VLAN. Mixing VLANs in one broadcast domain breaks the reachability model and is a misconfiguration ONTAP will flag.

What happens if a port is not reachable?

A port with no reachability cannot carry LIF traffic and is excluded from effective failover. On ONTAP 9.8 and later, network port reachability show reports the status; the cause is almost always a switch trunk, VLAN tagging, or MTU mismatch rather than ONTAP itself.

Does ONTAP automatically create broadcast domains?

On ONTAP 9.8 and later, yes — ONTAP auto-creates broadcast domains based on detected Layer 2 reachability. On 9.7 and earlier you create them manually. From 9.12, System Manager also lets you add or select one by hand, with a connectivity-loss warning if you override the automatic choice.

What is the difference between a failover group and a broadcast domain?

A broadcast domain is the set of reachable ports; a failover group is the list of those ports a specific LIF may move to. ONTAP generates the failover group from the broadcast domain automatically, so the broadcast domain is the cause and the failover group is the effect.

Can a broadcast domain span nodes?

Yes, and for failover it must. A LIF can only fail over to a port in its broadcast domain, so a domain used for HA must contain ports from every node the LIF should survive onto — typically both controllers in an HA pair.

How do I verify VLAN connectivity?

Use network port vlan show to confirm the VLAN port exists, then network port reachability show to confirm it reaches the expected broadcast domain. A LIF reading up/up with Is Home = true is the final confirmation that the data path works.

What is an IPspace?

An IPspace is an isolated network namespace within a cluster. It lets the same IP subnet exist more than once without collision, which is what makes secure multi-tenancy possible. Broadcast domains live inside an IPspace; most single-tenant clusters use only the Default IPspace.

When should I create separate broadcast domains?

Create a separate broadcast domain per Layer 2 network and per MTU. NFS on VLAN 120 at MTU 9000 and CIFS on VLAN 20 at MTU 1500 belong in different domains so their failover and frame sizing stay independent.

How does System Manager handle broadcast domains?

From ONTAP 9.12, System Manager presents the automatically detected broadcast domain when you create a LIF and lets you override it manually. Choosing a domain by hand raises a warning about possible connectivity loss, because the automatic choice reflects actual reachability.

References

• Create a broadcast domain — NetApp ONTAP networking management. NetApp.
• Configure VLANs over physical ports — NetApp ONTAP networking management. NetApp.
• Create LIFs (network interfaces) — NetApp ONTAP networking management. NetApp.
• network interface create — ONTAP command reference. NetApp.
• Repair port reachability — NetApp ONTAP networking. NetApp.
• Create broadcast domains (ONTAP 9.8 and later) — NetApp ONTAP networking. NetApp.