Subnet Group Form
The Subnet Group form creates a new group or edits an existing one. Subnet groups bundle subnets into a single named collection so a Scan Template can reference one group instead of every member subnet individually.
Inputs
| Name | Description | Allowed values | Default |
|---|---|---|---|
Name | Human-readable label for this group | Non-empty string, must be unique across subnet groups (e.g., "production-servers") | — |
Description | Optional free-text note | Any text, max 10,000 characters | Empty |
Subnets | Selection of subnets to include in this group. The picker shows each subnet's name, CIDR, and whether it is built-in. | At least one selection (empty groups are rejected) | None |
Gotchas
- **When creating:** Group subnets by operational meaning ("dmz-servers", "office-vlans") rather than by CIDR. The names appear in scan templates and audit logs.
- **When editing:** Removing a subnet from the group affects future scans — historical scan results remain.
- Subnet groups referenced by a Scan Template cannot be deleted until the references are removed.
- A subnet can belong to multiple groups simultaneously. There is no exclusivity constraint — useful when you want overlapping logical views (e.g. "all-dc-1" and "high-sensitivity") that share members.
API calls (4)
| Method | Path | Description |
|---|---|---|
| GET | /api/config/subnet-groups/:id | Load an existing subnet group (Edit mode) |
| GET | /api/config/subnets | List available subnets for selection |
| POST | /api/config/subnet-groups | Create a new subnet group (Create mode) |
| PUT | /api/config/subnet-groups/:id | Update an existing subnet group (Edit mode) |
Related
- Subnet Groups — Parent list page
- Subnets — Members of subnet groups
- Scan Templates — Consumes subnet groups to define what gets scanned