> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/switch-infrastructure/config-manager/llms.txt.
> For full documentation content, see https://docs.nvidia.com/switch-infrastructure/config-manager/llms-full.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/switch-infrastructure/config-manager/_mcp/server.

# VPC Creation

The VPC Creation workflow provisions the VRF metadata for a new VPC at a site. A VPC in this context is a tenant-scoped routing domain modeled as a VRF on the managed switches; creation is the metadata step that allocates the route distinguisher (RD) and registers the VRF objects in Nautobot. No switches are touched by this workflow — applying the new VPC to a device happens through [VPC Assignment](/switch-infrastructure/config-manager/user-guides/vpc-lifecycle/vpc-assignment), and re-rendering and redeploying tenant configuration happens through [VPC Tenant Change](/switch-infrastructure/config-manager/user-guides/vpc-lifecycle/vpc-tenant-change).

Creation is idempotent on `vpc_id` — re-running with an existing ID returns the already-existing VRFs rather than creating new ones.

This workflow is experimental and not intended for general use. Use it only in test or pilot environments.

## Prerequisites

Before running, confirm:

* **Site exists in Nautobot** and is correctly tagged so RD allocation can find an available range.
* **vpc\_id chosen.** Pick a unique identifier; if the same ID is reused, the workflow short-circuits and returns the existing VRFs without creating new ones.
* **Route-distinguisher range has free entries** within the site's allocated `rd_min`..`rd_max` window. The workflow's RD allocator pulls the first available RD in that window.

## Running the workflow

1. Navigate to the Config Manager URL for your environment.
2. Click the **+** in the top right and select **VpcCreationWorkflow**.
3. Fill in the form using the field reference below and submit.

| Field           | Description                                                                                         | Required            |
| :-------------- | :-------------------------------------------------------------------------------------------------- | :------------------ |
| **Site**        | The site the VPC belongs to.                                                                        | Yes                 |
| **VPC**         | Unique identifier for the VPC. Idempotency key — re-running with the same ID returns existing VRFs. | Yes                 |
| **Description** | Free-form description for the VPC.                                                                  | Yes                 |
| **Namespace**   | Tag used to identify the VPC namespace in Nautobot.                                                 | Yes                 |
| **RD Min**      | Lower bound of the route-distinguisher allocation range (0-65535).                                  | No (default: 60000) |
| **RD Max**      | Upper bound of the route-distinguisher allocation range (0-65535).                                  | No (default: 65000) |

After submission, a status page shows the single `create_vpc` stage. The workflow returns a result with two lists: `created_vrfs` (newly provisioned in this run) and `existing_vrfs` (already present at start time).

## Execution stages

The workflow runs one stage. No human approval is required.

1. **`create_vpc` — Allocate the RD and provision VRF objects.**

   Queries Nautobot for any existing VRFs matching the `vpc_id` + `namespace_tag`. If they exist, the stage short-circuits with the existing-VRFs list and the result is treated as a successful no-op. Otherwise, the activity allocates the first available RD in `[rd_min, rd_max]` and calls `provision_vrf` to register the VRF in Nautobot. The stage display reports the created VRFs.

## Verifying outcomes

After the workflow reports success, confirm:

* **`create_vpc` shows green** and the result's `created_vrfs` or `existing_vrfs` list contains the expected VRF objects.
* **Nautobot shows the VRFs** under the site with the allocated RD.
* **Re-running the workflow** with the same `vpc_id` returns immediately with `existing_vrfs` populated — confirming idempotency.

## Common issues

**`create_vpc` fails with "no available route distinguishers".**

The `[rd_min, rd_max]` window is exhausted. Either widen the window via the optional inputs, or audit the site's existing VRFs and reclaim RDs no longer in use before retrying.

**`create_vpc` fails with "Failed to create VRFs".**

The Nautobot write to register the VRF failed. Check Nautobot's logs and confirm the site, tenant, and namespace tag are correctly modeled before re-running.

**The result has empty `created_vrfs` and a populated `existing_vrfs`.**

The VPC already existed — the workflow short-circuited. This is the expected idempotent behavior.

## Related guides

* [VPC Deletion](/switch-infrastructure/config-manager/user-guides/vpc-lifecycle/vpc-deletion) — tear down a VPC (only when it is not in use on any device).
* [VPC Assignment](/switch-infrastructure/config-manager/user-guides/vpc-lifecycle/vpc-assignment) — bind the new VRF to a device and specific ports.
* [VPC Tenant Change](/switch-infrastructure/config-manager/user-guides/vpc-lifecycle/vpc-tenant-change) — assign + render + deploy a VPC change against a device end-to-end.
* [Render Service](/switch-infrastructure/config-manager/services/render/overview) — produces the tenant-scoped configurations that get deployed onto devices once a VPC is assigned.