From 37f3b408d3d3e316b0625c61cac0693776909af2 Mon Sep 17 00:00:00 2001 From: Chris Date: Mon, 10 Aug 2026 17:29:45 -0400 Subject: [PATCH 1/2] creating Azure conductor deployment guide --- .../_deploy_azure_conductor_network_design.md | 29 ++ docs/deploy_appendix_azure_conductor.mdx | 220 ++++++++++ docs/deploy_azure_conductor.mdx | 85 ++++ docs/deploy_azure_conductor_config.mdx | 87 ++++ docs/deploy_azure_conductor_install.mdx | 92 ++++ docs/deploy_azure_conductor_router.mdx | 401 ++++++++++++++++++ docs/deploy_azure_conductor_vm.mdx | 209 +++++++++ sidebars.js | 12 + 8 files changed, 1135 insertions(+) create mode 100644 docs/_deploy_azure_conductor_network_design.md create mode 100644 docs/deploy_appendix_azure_conductor.mdx create mode 100644 docs/deploy_azure_conductor.mdx create mode 100644 docs/deploy_azure_conductor_config.mdx create mode 100644 docs/deploy_azure_conductor_install.mdx create mode 100644 docs/deploy_azure_conductor_router.mdx create mode 100644 docs/deploy_azure_conductor_vm.mdx diff --git a/docs/_deploy_azure_conductor_network_design.md b/docs/_deploy_azure_conductor_network_design.md new file mode 100644 index 00000000000..382f68e536d --- /dev/null +++ b/docs/_deploy_azure_conductor_network_design.md @@ -0,0 +1,29 @@ + + +The following IP addressing and naming scheme is used consistently throughout this guide. Substitute your own values when configuring your network. + +| Parameter | Example Value | Description | +|-----------|--------------|-------------| +| Azure Region | `eastus` | Azure region for all deployed resources | +| Resource Group | `SSR-RG` | Azure resource group containing all resources | +| VNet Name | `SSR-VNet` | Virtual network address space `10.0.0.0/16` | +| Conductor Subnet | `ssr-conductor-subnet` | Conductor management subnet (`10.0.0.0/24`) | +| Conductor Private IP | `10.0.0.10` | Static private IP assigned within the conductor subnet | +| Conductor Gateway | `10.0.0.1` | Conductor subnet gateway | +| Conductor Public IP | `` | Azure-assigned public IP — used for SSH, GUI, and as the conductor address | +| Authority Name | `Authority128` | SSR organizational authority name | +| Conductor Name | `Conductor` | Conductor system name | +| Conductor Node Name | `node0` | Conductor node name | +| Router WAN Subnet | `ssr-router-wan` | Router public (WAN) subnet (`10.0.1.0/24`) | +| Router LAN Subnet | `ssr-router-lan` | Router private (LAN) subnet (`10.0.2.0/24`) | +| Router Name | `azure-router-1` | Router system name | +| Router Node Name | `node0` | Router node name | +| WAN Device Interface | `wan-dev` | WAN device interface name | +| WAN Network Interface | `wan1` | WAN network interface name | +| LAN Device Interface | `lan-dev` | LAN device interface name | +| LAN Network Interface | `lan1` | LAN network interface name | +| Router LAN IP | `10.0.2.1/24` | LAN gateway address assigned to the router LAN interface | +| Tenant Name | `corp` | LAN-side user tenant | +| Service Name | `Internet-Traffic` | Internet breakout service | +| Service Address | `0.0.0.0/0` | All internet-bound traffic | +| Neighborhood | `internet` | SVR peering neighborhood name | diff --git a/docs/deploy_appendix_azure_conductor.mdx b/docs/deploy_appendix_azure_conductor.mdx new file mode 100644 index 00000000000..2be391a2645 --- /dev/null +++ b/docs/deploy_appendix_azure_conductor.mdx @@ -0,0 +1,220 @@ +--- +title: Appendix - Azure Conductor Configuration +sidebar_label: Appendix - Azure Conductor Configuration +--- +import NetworkDesign from './_deploy_azure_conductor_network_design.md'; + +This appendix contains the complete SSR PCLI configuration for the `Conductor` and `azure-router-1` deployments described in this guide. Apply this configuration after completing [Step 3 — Configure the Conductor](deploy_azure_conductor_config.mdx) and [Step 4 — Deploy and Configure a Router](deploy_azure_conductor_router.mdx). + +## Network Design Reference + + + +## Applying This Configuration + +This configuration can be applied to a freshly initialized conductor using the PCLI import function. + +1. Save the configuration below to a file — for example, `azure-conductor.cfg`. + +2. Copy the file to the conductor: + + ```bash + scp azure-conductor.cfg t128@:/tmp/ + ``` + +3. Log in to the conductor PCLI: + + ```bash + ssh t128@ + su admin + ``` + +4. Enter configuration mode and import: + + ```text + admin@node0.Conductor# import config /tmp/azure-conductor.cfg + ``` + +5. Review any validation warnings, then commit: + + ```text + admin@node0.Conductor (config)# commit + Are you sure you want to commit the candidate config? [y/N]: y + ``` + +Alternatively, you may copy and paste each block into the PCLI while in `configure` → `edit` mode. + +## Complete Configuration + +Replace all placeholder values (shown in angle brackets) with values from your environment before applying. + +```text +config + authority + name Authority128 + + conductor-address + + tenant corp + name corp + exit + + service Internet-Traffic + name Internet-Traffic + scope public + security internal + + access-policy + source corp + exit + + address 0.0.0.0/0 + exit + + router Conductor + name Conductor + inter-node-security internal + + node node0 + name node0 + role conductor + + device-interface mgmt-dev + name mgmt-dev + type ethernet + forwarding false + vmbus-uuid + + network-interface mgmt-intf + name mgmt-intf + type management + + address 10.0.0.10 + ip-address 10.0.0.10 + prefix-length 24 + gateway 10.0.0.1 + exit + exit + exit + exit + exit + + router azure-router-1 + name azure-router-1 + inter-node-security internal + + node node0 + name node0 + role combo + + device-interface wan-dev + name wan-dev + type ethernet + forwarding true + vmbus-uuid + + network-interface wan1 + name wan1 + global-id 1 + conductor true + default-route true + source-nat true + management true + + management-vector + name mgmt-vec-wan + priority 100 + exit + + neighborhood internet + name internet + exit + + inter-router-security internal + dhcp v4 + exit + exit + + device-interface lan-dev + name lan-dev + type ethernet + forwarding true + vmbus-uuid + + network-interface lan1 + name lan1 + global-id 2 + tenant corp + source-nat true + + address 10.0.2.1 + ip-address 10.0.2.1 + prefix-length 24 + exit + + dhcp disabled + exit + exit + exit + + dns-config manual + mode manual + address 1.1.1.1 + address 8.8.8.8 + exit + + service-route internet-route + name internet-route + service-name Internet-Traffic + + next-hop node0 wan1 + node-name node0 + interface wan1 + exit + exit + exit + exit +exit +``` + +## Configuration Notes + +:::important +All VMBus UUID values in this configuration are placeholders. You must discover the actual values from the deployed VM before applying this configuration. See [Discover VMBus UUIDs](deploy_azure_conductor_router.mdx#discover-vmbus-uuids) for the discovery procedure. +::: + +| Item | Note | +|------|------| +| `conductor-public-ip` | Replace with the public IP address shown in the Azure Portal Outputs tab after the conductor VM is deployed. | +| `conductor-vmbus-uuid` | Replace with the VMBus UUID of the conductor's management NIC, discovered by running `sudo dpdk-devbind.py --status` on the conductor VM. | +| `wan-vmbus-uuid` | Replace with the VMBus UUID for `eth1` (the public/WAN NIC) on the router VM. | +| `lan-vmbus-uuid` | Replace with the VMBus UUID for `eth2` (the private/LAN NIC) on the router VM. | +| `10.0.0.10` (conductor private IP) | Replace with the actual private IP assigned to the conductor VM if different from this guide's example. | +| `10.0.2.1/24` (router LAN IP) | Replace with the actual LAN gateway address for your private subnet. | +| `gateway 10.0.0.1` | Replace with the actual gateway IP for the conductor subnet. | +| `forwarding false` on conductor NIC | The conductor management NIC is not a forwarding interface. Do not change this value. | +| `dhcp v4` on `wan1` | The router WAN interface obtains its IP via DHCP from the Azure `ssr-router-wan` subnet. This is the expected behavior for Azure-hosted routers. | + +## Interface Summary + +| Router | Interface | Device Interface | VMBus UUID | Type | Configuration | +|--------|-----------|-----------------|-----------|------|---------------| +| `Conductor` | `mgmt-intf` | `mgmt-dev` | `` | Management | Static `10.0.0.10/24`, forwarding `false` | +| `azure-router-1` | `wan1` | `wan-dev` | `` | External | DHCP v4, conductor, management, source-nat, default-route, neighborhood `internet` | +| `azure-router-1` | `lan1` | `lan-dev` | `` | External | Tenant `corp`, static `10.0.2.1/24`, source-nat | + +## Service Route Summary + +| Router | Service Route | Service | Type | Next Hop | +|--------|--------------|---------|------|---------| +| `azure-router-1` | `internet-route` | `Internet-Traffic` | `service-agent` | `node0 / wan1` | + +## Design Notes + +**Management over Forwarding** — The `wan1` interface on `azure-router-1` carries both internet forwarding traffic and conductor management sessions simultaneously. Management traffic originates from the `169.254.x.x` range and is source-NAT'd to the DHCP WAN address before leaving the interface. This eliminates the need for a separate management subnet or out-of-band management path. + +**Internet Breakout** — The `internet-route` service route directs all `corp`-tenant traffic matching the `Internet-Traffic` service (destination `0.0.0.0/0`) out through `wan1` as a service-agent. Source NAT on `wan1` translates LAN client addresses to the WAN IP before traffic reaches the Azure internet gateway. + +**VMBus UUID Binding** — Azure assigns VMBus UUIDs to NICs at VM creation time. Unlike VMware PCI addresses, VMBus UUIDs are stable across reboots but are unique to each VM instance. Always discover the actual values from the deployed VM rather than using the placeholders in this appendix. + +**Conductor Address** — The `conductor-address` is set to the conductor's Azure public IP so that routers outside the Azure VNet can also reach the conductor. If all managed routers reside in the same VNet, the private IP (`10.0.0.10`) may be used instead. diff --git a/docs/deploy_azure_conductor.mdx b/docs/deploy_azure_conductor.mdx new file mode 100644 index 00000000000..21b58361ff9 --- /dev/null +++ b/docs/deploy_azure_conductor.mdx @@ -0,0 +1,85 @@ +--- +title: Azure Conductor Deployment Guide +sidebar_label: Overview +--- +import NetworkDesign from './_deploy_azure_conductor_network_design.md'; + +This guide walks you through deploying a **Juniper Session Smart Conductor on Azure** using the Bring Your Own License (BYOL) plan, and then using that conductor to provision and manage a Session Smart Router (SSR) running in the same Azure VNet. When you complete this guide, the conductor VM will be running SSR 7.1.4, configured with an authority name, conductor address, and shared services that allow branch routers to onboard and begin forwarding traffic. + +## Guide Topics + +| Step | Topic | Description | +|------|-------|-------------| +| 1 | [Create the Azure Conductor VM](deploy_azure_conductor_vm.mdx) | Deploy the BYOL Conductor VM from the Azure Marketplace | +| 2 | [Initialize and Access the Conductor](deploy_azure_conductor_install.mdx) | Verify the BYOL installation and log in to the Conductor GUI | +| 3 | [Configure the Conductor](deploy_azure_conductor_config.mdx) | Set the authority name, conductor address, tenant, and internet service | +| 4 | [Deploy and Configure a Router](deploy_azure_conductor_router.mdx) | Deploy a BYOL conductor-managed router and configure WAN, LAN, and internet breakout | +| — | [Appendix — Conductor Configuration](deploy_appendix_azure_conductor.mdx) | Complete Azure conductor and router PCLI configuration reference | + +## Network Topology + +The diagram below shows the logical network this guide builds. + +```mermaid +graph TD + Internet((Internet)) + subgraph Azure["Azure — eastus"] + subgraph VNet["SSR-VNet 10.0.0.0/16"] + ConductorVM["SSR Conductor VM\n(Conductor / node0)\nPublic IP: auto-assigned\nPrivate: 10.0.0.10/24\nSubnet: ssr-conductor-subnet"] + RouterVM["SSR Router VM\n(azure-router-1 / node0)\nWAN: DHCP (10.0.1.x/24)\nLAN: 10.0.2.1/24"] + LAN["LAN Devices\nTenant: corp\n10.0.2.0/24"] + end + end + ISP(["Azure Internet Gateway"]) + + Internet <-->|"Internet"| ISP + ISP <-->|"WAN — DHCP"| RouterVM + RouterVM <-->|"Internet Breakout\nservice: Internet-Traffic"| Internet + LAN <-->|"LAN"| RouterVM + RouterVM <-->|"Management over Forwarding\nWAN — Port 930 / 4505 / 4506"| ConductorVM +``` + +## Roles + +| Device | Type | Role | +|--------|------|------| +| `Conductor` | Azure VM (BYOL) | Standalone SSR Conductor — centralized management and provisioning | +| `azure-router-1` | Azure VM (BYOL) | Conductor-managed SSR — internet breakout, LAN forwarding | + +## Network Design Reference + + + +## Prerequisites + +Before beginning, ensure the following are available: + +- **Azure subscription** — with permission to create VMs, VNets, network security groups, and managed identities. +- **Azure VNet** — with at least the following subnets already created: + - `ssr-conductor-subnet` — reachable via SSH and HTTPS for administration. + - `ssr-router-wan` — the router's public (WAN) subnet; must have internet egress. + - `ssr-router-lan` — the router's private (LAN) subnet. +- **Azure Managed Identity** — with the minimum read permissions listed in [Step 1](deploy_azure_conductor_vm.mdx#requirements). +- **Juniper software access credentials** — Artifactory username and password for SSR software downloads. +- **SSH key pair** — RSA 2048-bit or stronger; the public key is supplied to the Azure deployment templates. + +## Software Version Requirements + +This guide installs **SSR 7.1.4** on both the conductor and the router. + +:::note +The router software version must be lower than or equal to the conductor software version. +::: + +:::note +BYOL instances require the conductor to run SSR 6.3.0-R1 or newer. SSR 7.1.4 satisfies this requirement. +::: + +## Related Documentation + +- [System Requirements](intro_system_reqs) +- [Conductor Deployment Best Practices](bcp_conductor_deployment) +- [Management Traffic over Forwarding Interfaces](config_management_over_forwarding) +- [Onboard an SSR Device to a Conductor](onboard_ssr_to_conductor) +- [Installing a BYOL Conductor-managed Router in Azure](intro_installation_byol_azure_conductor) +- [Installing a PAYG Conductor-managed Router in Azure](intro_installation_azure) diff --git a/docs/deploy_azure_conductor_config.mdx b/docs/deploy_azure_conductor_config.mdx new file mode 100644 index 00000000000..bdfbc3ab149 --- /dev/null +++ b/docs/deploy_azure_conductor_config.mdx @@ -0,0 +1,87 @@ +--- +title: "Step 3: Configure the Conductor" +sidebar_label: "Configure the Conductor" +--- +import NetworkDesign from './_deploy_azure_conductor_network_design.md'; +import AuthorityName from './_set_authority_name.md'; +import SetConductorIP from './_set_conductor_ip.md'; +import ConductorAuthority from './_conductor_to_authority.md'; + +This step configures the authority-level settings on the conductor: the authority name, conductor address, corporate tenant, and internet service. These objects are shared across all routers managed by this conductor. + +All steps are performed from the **Conductor GUI** at `https://` unless otherwise noted. + +## Network Design Reference + + + +## 1. Assign the Conductor's Asset ID + + + +## 2. Set the Authority Name + + + +:::note +Use your organization's name as the authority name (for example, `Authority128`). The authority name cannot be changed after routers have been provisioned without re-onboarding them. +::: + +## 3. Set the Conductor Address + +The conductor address is the IP that managed routers use to reach this conductor. For Azure deployments, use the **public IP address** assigned to the conductor VM so that routers outside the Azure VNet can also reach it. + +:::note +If all managed routers reside in the same Azure VNet and communicate over private addressing, you may use the conductor's **private IP** (`10.0.0.10` in this guide) instead. +::: + + + +When prompted for the conductor address, enter the public IP address displayed in the Azure Portal Outputs tab (for example, `203.0.113.10`). Validate and commit the change. + +## 4. Create the Corporate Tenant + +Tenants logically partition the network. The `corp` tenant represents corporate LAN users and is referenced by the LAN interface configuration on each managed router. + +1. In the Conductor GUI, select **Configuration**. +2. Select **Authority**. +3. Scroll to **Tenants** and select **ADD**. +4. Enter the name `corp` and select **SAVE**. +5. Select **VALIDATE** then **COMMIT**. + +:::info +Tenants are authority-wide. A single `corp` tenant definition applies to all routers that assign it to a LAN interface. +::: + +## 5. Create the `Internet-Traffic` Service + +The *service* configuration element defines the IP destinations that the SSR routes. This step creates a single service representing all internet-bound traffic from corporate LAN users. + +1. In the Conductor GUI, select **Configuration**. +2. Select **Authority** from the left panel. +3. Scroll down to **Services** and select **ADD**. +4. Enter the name `Internet-Traffic` and select **SAVE**. +5. On the Service screen, verify **Enabled** is set to `true`. +6. Scroll down to **Service Addresses** and select **ADD**. +7. Enter `0.0.0.0/0` and select **SAVE**. +8. Scroll down to **Access Policy** and select **ADD**. + - Set **Source** to `corp`. + - Select **SAVE**. +9. Select **VALIDATE** then **COMMIT**. + +## What Was Configured + +At the end of this step your authority contains: + +| Object | Name | Value | +|--------|------|-------| +| Authority | `Authority128` | | +| Conductor Address | | Public IP of the conductor VM | +| Tenant | `corp` | LAN-side user population | +| Service | `Internet-Traffic` | `0.0.0.0/0`, access from `corp` | + +The conductor is now ready to accept router onboarding. + +## Next Step + +Proceed to [Step 4 — Deploy and Configure a Router](deploy_azure_conductor_router.mdx). diff --git a/docs/deploy_azure_conductor_install.mdx b/docs/deploy_azure_conductor_install.mdx new file mode 100644 index 00000000000..1f3e01a9b78 --- /dev/null +++ b/docs/deploy_azure_conductor_install.mdx @@ -0,0 +1,92 @@ +--- +title: "Step 2: Initialize and Access the Conductor" +sidebar_label: "Initialize and Access" +--- +import NetworkDesign from './_deploy_azure_conductor_network_design.md'; + +This step verifies that the BYOL installation has completed successfully, confirms the conductor is running, and walks you through logging in to the conductor GUI for the first time. + +## Network Design Reference + + + +## Wait for Installation to Complete + +The BYOL bootstrapper installs SSR 7.1.4 automatically after the VM is deployed. This process takes approximately **10–15 minutes** after the VM first starts. + +You can monitor installation progress by connecting to the VM via SSH: + +```bash +ssh t128@ +``` + +Once logged in, check the bootstrapper journal for progress: + +```bash +journalctl -u 128T-hardware-bootstrapper -f +``` + +The installation is complete when you see output similar to: + +``` +Device successfully initialized +``` + +## Verify the Conductor Is Running + +1. From an SSH session on the conductor VM, enter the SSR PCLI: + + ```bash + su admin + ``` + +2. Run `show system` and wait until the status returns as `running`: + + ```text + admin@node0.Conductor# show system + ``` + + The system may take a few minutes to fully start after installation. Run the command again if the status is not yet `running`. + +## Log In to the Conductor GUI + +1. Open a browser and navigate to `https://`. + + :::note + The conductor uses a self-signed certificate. If your browser presents an "unsafe connection" warning, click through to continue. You can replace the certificate later. + ::: + +2. Log in with the following default credentials: + + | Field | Value | + |-------|-------| + | Username | `admin` | + | Password | `128Tadmin` | + + :::important + Change the default password immediately after first login. The new password requires a minimum of 9 characters containing at least 1 uppercase letter, 1 lowercase letter, and 1 number. + ::: + +3. A successful login confirms the conductor is running and reachable on the public IP. + +## Manual Onboarding + +If you did not supply cloud-init onboarding configuration during deployment, you can complete onboarding manually: + +1. Log in to the conductor VM via SSH: + + ```bash + ssh t128@ + ``` + +2. Run the configuration generator: + + ```bash + /usr/libexec/hardwareBootstrapper128t config-generator + ``` + +3. Follow the prompts to supply the conductor name, SSR version, artifactory credentials, and node name. The bootstrapper installs the software and initializes the conductor. + +## Next Step + +Proceed to [Step 3 — Configure the Conductor](deploy_azure_conductor_config.mdx). diff --git a/docs/deploy_azure_conductor_router.mdx b/docs/deploy_azure_conductor_router.mdx new file mode 100644 index 00000000000..629ab6ac546 --- /dev/null +++ b/docs/deploy_azure_conductor_router.mdx @@ -0,0 +1,401 @@ +--- +title: "Step 4: Deploy and Configure a Router" +sidebar_label: "Deploy and Configure a Router" +--- +import NetworkDesign from './_deploy_azure_conductor_network_design.md'; + +This step deploys a BYOL conductor-managed SSR in Azure and configures it on the conductor with WAN and LAN interfaces, management over forwarding, and an internet breakout service route. + +## Network Design Reference + + + +## Requirements + +The following infrastructure must exist in your Azure subscription before deploying the router: + +- A VNet where the router will be deployed. This guide uses the same `SSR-VNet` as the conductor. +- An Availability Set for the router VM. +- The VNet is segmented with at least the following two subnets: + - **Public subnet** (`ssr-router-wan`): provides internet connectivity and carries WAN traffic. The conductor's management interface must be reachable from this subnet. + - **Private subnet** (`ssr-router-lan`): provides connectivity to internal workloads. +- A **Managed Identity** with the following minimum read permissions: + + ``` + Microsoft.Compute/virtualMachines/read + Microsoft.Network/virtualNetworks/read + Microsoft.Network/networkInterfaces/read + ``` + +:::note +A dedicated management subnet is optional for conductor-managed routers in this guide. Management traffic travels over the WAN forwarding interface instead. See [Management Traffic over Forwarding Interfaces](config_management_over_forwarding.md) for background. +::: + +## Deploy the Router VM + +### Azure Portal + +1. Return to the **Session Smart Networking Platform BYOL** offering in the Azure Marketplace. +2. Click **Get it now** and agree to the terms. +3. Click the **Plans + Pricing** tab. + + ![Plans](/img/platforms_azure_plans.png) + +4. Click the **Launch** link on the **Juniper Session Smart Conductor-managed Router** template. + + ![Router ARM Template](/img/azure-byol-conductor-managed-template.png) + +5. Fill in the template parameters: + + | Parameter | Example Value | Notes | + |-----------|--------------|-------| + | Subscription | _(your subscription)_ | | + | Resource Group | `SSR-RG` | | + | Location | `eastus` | One word, all lowercase | + | Availability Set Name | `SSR-RouterSet` | Must exist in the same resource group | + | Instance Size | `Standard_F8s_v2` | | + | Instance Name | `azure-router-1` | | + | SSR Version | `7.1.4` | | + | Artifactory Username | _(your username)_ | | + | Artifactory Token | _(your token)_ | | + | Managed Identity | _(your managed identity)_ | | + | Virtual Network Name | `SSR-VNet` | | + | Public Subnet Name | `ssr-router-wan` | WAN subnet | + | Private Subnet Name | `ssr-router-lan` | LAN subnet | + | Public Subnet Allowed CIDR | `0.0.0.0/0` | Restrict after deployment | + | Private Subnet Allowed CIDR | `0.0.0.0/0` | | + | Admin Allowed CIDR | `0.0.0.0/0` | Restrict after deployment | + | Primary Control IP | `` | Public IP of the conductor from Step 1 | + | Secondary Control IP | _(leave blank)_ | Only required for HA conductor deployments | + | Admin Public Key Data | _(contents of your SSH public key)_ | | + +6. Agree to the terms and conditions. +7. Click **Purchase** to launch the deployment. + + ![Deployment complete](/img/platforms_azure_deployment_complete.png) + +8. When the deployment completes, the BYOL bootstrapper begins installing SSR 7.1.4. Allow **10–15 minutes** for installation to finish before proceeding. + +### Azure CLI or PowerShell + +Create the parameters file `router_byol.parameters.json`: + +```json +{ + "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#", + "contentVersion": "1.0.0.0", + "parameters": { + "location": { "value": "eastus" }, + "availabilitySetName": { "value": "SSR-RouterSet" }, + "instanceSize": { "value": "Standard_F8s_v2" }, + "instanceName": { "value": "azure-router-1" }, + "SSR Version": { "value": "7.1.4" }, + "artifactoryUsername": { "value": "" }, + "artifactoryToken": { "value": "" }, + "managedIdentity": { "value": "" }, + "virtualNetworkName": { "value": "SSR-VNet" }, + "publicSubnetName": { "value": "ssr-router-wan" }, + "privateSubnetName": { "value": "ssr-router-lan" }, + "publicSubnetAllowedCidr": { "value": "0.0.0.0/0" }, + "privateSubnetAllowedCidr": { "value": "0.0.0.0/0" }, + "adminAllowedCidr": { "value": "0.0.0.0/0" }, + "conductorPrimaryControlIP": { "value": "" }, + "adminPublicKeyData": { "value": "" } + } +} +``` + +Launch the deployment: + +```bash +New-AzResourceGroupDeployment -ResourceGroupName SSR-RG ` + -TemplateUri ` + -TemplateParameterFile ./router_byol.parameters.json +``` + +### Cloud-init Onboarding + +When launching via CLI or automation, supply the following `user-data` block to configure the router onboarding: + +```yaml +#cloud-config +write_files: + - path: /etc/128T-hardware-bootstrapper/onboarding-config.json + content: | + { + "name": "azure-router-1", + "ssr-version": "7.1.4", + "mode": "conductor-managed", + "conductor-hosts": [""], + "artifactory-user": "", + "artifactory-password": "", + "cloud-provider": "azure" + } +``` + +| Option | Meaning | +|--------|---------| +| `name` | The name of the router as it will appear in the conductor. | +| `ssr-version` | The SSR software version to install. | +| `mode` | Set to `conductor-managed`. | +| `conductor-hosts` | List of conductor control IP addresses. | +| `artifactory-user` | Artifactory credentials username. | +| `artifactory-password` | Artifactory credentials password or token. | +| `cloud-provider` | Set to `azure`. | + +## Verify the Router Is Onboarded + +After installation completes, the router contacts the conductor and appears as a pending asset. + +1. In the Conductor GUI, select **Configuration**. +2. Select **Authority** and look for a new router entry under **Routers**. +3. The router appears with a pending association. Proceed to [Assign the Router's Asset ID](#assign-the-routers-asset-id) to associate it with the router configuration. + +## Network Interface Layout + +The BYOL conductor-managed router template deploys a VM with three network interfaces attached in the following order: + +| Linux Interface | Azure NIC Name | Subnet | +|-----------------|---------------|--------| +| `eth0` | Router-mgmt | _(not used in this guide — no dedicated management subnet)_ | +| `eth1` | Router-public | `ssr-router-wan` | +| `eth2` | Router-private | `ssr-router-lan` | + +In Azure, device interfaces are identified by **VMBus UUID** rather than PCI address. You must discover the VMBus UUID for each interface before configuring the router on the conductor. + +## Discover VMBus UUIDs + +The SSR uses VMBus UUIDs to bind device interfaces to the underlying Azure virtual hardware. You must map each Azure NIC to its VMBus UUID before configuring the router. + +### Step 1: Identify VMBus UUIDs From the Router VM + +1. SSH into the router VM: + + ```bash + ssh t128@ + ``` + +2. Run the following command: + + ```bash + sudo dpdk-devbind.py --status + ``` + + In the **VMBus devices** section, the first column contains the VMBus UUID. The `if` parameter shows the associated Linux interface name. + +### Step 2: Map Azure NICs to VMBus UUIDs + +1. Log in to the [Azure Portal](https://portal.azure.com). +2. Navigate to the router VM and select **Networking** under **Settings**. + + ![Azure Networking Settings](/img/VMBusAzureUI1.png) + +3. The attached network interfaces are listed from left to right: **Router-mgmt**, **Router-public**, **Router-private**. + + ![Azure Port UI](/img/VMBusAzureUI2.png) + +4. Cross-reference the Linux interface names from `dpdk-devbind.py` with the Azure portal to build the following mapping: + + | Azure NIC Name | Linux Interface | Subnet | VMBus UUID | + |----------------|----------------|--------|-----------| + | Router-public | `eth1` | `ssr-router-wan` | _(discovered from dpdk-devbind.py)_ | + | Router-private | `eth2` | `ssr-router-lan` | _(discovered from dpdk-devbind.py)_ | + + Record the WAN VMBus UUID as `` and the LAN VMBus UUID as `` for use in the following configuration steps. + +## Configure the Router on the Conductor + +All configuration steps below are performed in the **Conductor GUI** at `https://`. + +:::note +Your conductor must already have the following objects configured before proceeding: + +- **Authority name** — set to your organization's name. +- **Conductor address** — set to the conductor's public IP. +- **`corp` tenant** — the LAN-side user tenant. +- **`Internet-Traffic` service** — with address `0.0.0.0/0` and access policy permitting `corp`. + +If any of these are missing, complete [Step 3 — Configure the Conductor](deploy_azure_conductor_config.mdx) first. +::: + +:::note +If you prefer to apply configuration using the PCLI, the complete example configuration is available in the [Appendix](deploy_appendix_azure_conductor.mdx). +::: + +### Assign the Router's Asset ID + +1. In the Conductor GUI, select **Configuration**. +2. Under **Routers**, select `azure-router-1`. +3. Select the **Configure** icon. +4. Select node `node0`. +5. Under **Associated Asset ID**, select the asset ID reported by the router VM. +6. Select **VALIDATE** then **COMMIT**. + +### 1. Configure the WAN Interface + +The WAN interface (`eth1` / `ssr-router-wan`) connects to the internet, obtains a DHCP address, and carries both internet forwarding and conductor management traffic via [Management over Forwarding](config_management_over_forwarding.md). + +#### 1a. Create the WAN Device Interface + +1. In the Conductor GUI, navigate to the `azure-router-1` router, then to node `node0`. +2. Scroll to **Device Interfaces** and select **ADD**. +3. Enter the name `wan-dev` and select **SAVE**. +4. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `ethernet` | | + | VMBus UUID | `` | Discovered in [Discover VMBus UUIDs](#discover-vmbus-uuids) | + | Forwarding | `true` | | + +5. Select **SAVE**. + +#### 1b. Create the WAN Network Interface + +1. Under the WAN Device Interface, scroll to **Network Interfaces** and select **ADD**. +2. Enter the name `wan1` and select **SAVE**. +3. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `external` | | + | DHCP | `v4` | The Azure subnet assigns an IP via DHCP | + | Global-ID | `1` | | + | Conductor | `true` | Marks this interface for conductor connectivity | + | Management | `true` | Enables management over forwarding on this interface | + | Default Route | `true` | Linux uses this interface as its default route | + | Source NAT | `true` | Required for management over forwarding | + +4. Scroll to **Management Vector** and select **ADD**. + - Enter name `mgmt-vec-wan` and priority `100`. + - Select **SAVE**. + +5. Scroll to **Neighborhoods** and select **ADD**. + - Enter neighborhood name `internet`. + - Verify **Topology** is set to `spoke`. + - Select **SAVE**. + +:::important +`Conductor` must be set to `true` or management traffic will not reach the conductor. + +`Source NAT` and `Default Route` must both be `true` on the WAN management interface. Management traffic originates from the `169.254.x.x` range and must be source-NAT'd to a routable address before leaving the interface. The default route ensures Linux routes non-SVR traffic through the SSR forwarding engine. +::: + +### 2. Configure the LAN Interface + +The LAN interface (`eth2` / `ssr-router-lan`) connects to the private subnet and assigns the `corp` tenant to inbound traffic. + +#### 2a. Create the LAN Device Interface + +1. In the Conductor GUI, navigate to node `node0` of `azure-router-1`. +2. Scroll to **Device Interfaces** and select **ADD**. +3. Enter the name `lan-dev` and select **SAVE**. +4. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `ethernet` | | + | VMBus UUID | `` | Discovered in [Discover VMBus UUIDs](#discover-vmbus-uuids) | + | Forwarding | `true` | | + +5. Select **SAVE**. + +#### 2b. Create the LAN Network Interface + +1. Under the LAN Device Interface, scroll to **Network Interfaces** and select **ADD**. +2. Enter the name `lan1` and select **SAVE**. +3. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `external` | | + | Global-ID | `2` | | + | DHCP | `disabled` | | + | Tenant | `corp` | Assigns all inbound LAN traffic to the corp tenant | + | Source NAT | `true` | | + +4. Scroll to **Interface Addresses** and select **ADD**. + - IP Address: `10.0.2.1` + - Prefix Length: `24` +5. Select **SAVE**. + +### 3. Configure DNS + +Configure DNS so the router can resolve FQDNs for conductor connectivity and software downloads. + +1. Return to the **Router** level for `azure-router-1`. +2. Scroll to **DNS Config** and select **ADD**. +3. Set **Mode** to `manual` and enter DNS server addresses — for example, `1.1.1.1` and `8.8.8.8`. +4. Select **SAVE**. + +### 4. Create the Internet Breakout Service Route + +The service route directs traffic matched by the `Internet-Traffic` service out through the WAN interface as a direct internet breakout. + +1. Return to the **Router** level for `azure-router-1`. +2. Scroll to **Service Routes** and select **ADD**. +3. Enter the name `internet-route` and select **SAVE**. +4. Set the following fields: + + | Field | Value | + |-------|-------| + | Service Name | `Internet-Traffic` | + | Service Route Type | `service-agent` | + +5. Scroll to **Next Hops** and select **ADD**. + - Node Name: `node0` + - Interface: `wan1` +6. Select **SAVE**. +7. Select **VALIDATE** then **COMMIT**. + +## Verify Connectivity + +After committing the configuration, verify the router is online and forwarding traffic. + +### Verify the Router Is Connected to the Conductor + +From the Conductor GUI, select **Routers**. The `azure-router-1` router should show a **Connected** status. + +From the conductor PCLI: + +```text +admin@node0.Conductor# show peers +``` + +The peer entry for `azure-router-1` should show status `Up`. + +### Verify ARP on the WAN Interface + +Azure gateways do not respond to ICMP ping. Use the ARP table to verify WAN connectivity: + +```text +admin@node0.azure-router-1# show arp +``` + +Look for **valid** ARP entries on the `wan1` interface. + +### Verify Internet Reachability + +From the router PCLI, ping an internet host to confirm internet breakout is working: + +```text +admin@node0.azure-router-1# ping 8.8.8.8 +``` + +## What Was Configured + +| Object | Name | Value | +|--------|------|-------| +| Router | `azure-router-1` | Conductor-managed, combo role | +| WAN Device Interface | `wan-dev` | VMBus UUID — WAN, forwarding `true` | +| WAN Network Interface | `wan1` | DHCP v4, conductor, management, source-nat, default-route | +| WAN Neighborhood | `internet` | Spoke topology | +| LAN Device Interface | `lan-dev` | VMBus UUID — LAN, forwarding `true` | +| LAN Network Interface | `lan1` | Tenant `corp`, static `10.0.2.1/24`, source-nat | +| Service Route | `internet-route` | `Internet-Traffic` → `node0/wan1` | + +## Related Documentation + +- [Appendix — Complete Configuration](deploy_appendix_azure_conductor.mdx) +- [Management Traffic over Forwarding Interfaces](config_management_over_forwarding) +- [Configuring a Device Interface with VMBus UUID](intro_installation_azure#configuring-a-device-interface-with-vmbus-uuid) diff --git a/docs/deploy_azure_conductor_vm.mdx b/docs/deploy_azure_conductor_vm.mdx new file mode 100644 index 00000000000..51fd96b086d --- /dev/null +++ b/docs/deploy_azure_conductor_vm.mdx @@ -0,0 +1,209 @@ +--- +title: "Step 1: Create the Azure Conductor VM" +sidebar_label: "Create the Conductor VM" +--- +import NetworkDesign from './_deploy_azure_conductor_network_design.md'; + +This step deploys the BYOL Session Smart Conductor VM from the Azure Marketplace. The deployment template creates the VM, assigns a static public IP to the management interface, and configures a network security group. A cloud-init script installs SSR 7.1.4 and initializes the node as a conductor automatically. + +## Network Design Reference + + + +## Requirements + +The following infrastructure must exist in your Azure subscription before deploying the conductor: + +- A VNet where the Conductor will be deployed (`SSR-VNet` in this guide). +- A subnet within that VNet reachable via SSH and HTTPS for administration (`ssr-conductor-subnet`). +- The subnet must be reachable from the WAN interface of every SSR router this conductor will manage. +- A **Managed Identity** assigned the following minimum read permissions: + + ``` + Microsoft.Compute/virtualMachines/read + Microsoft.Network/virtualNetworks/read + Microsoft.Network/networkInterfaces/read + ``` + +## Recommended VM Sizes + +Select the instance size that best meets the scale of your deployment. + +| Recommended Azure VM Size | Max vNICs | vCPU Cores | Memory | +|---------------------------|-----------|-----------|--------| +| Standard_F8s_v2 | 4 | 8 | 16 GB | +| Standard_F16s_v2 | 4 | 16 | 32 GB | +| Standard_F32s_v2 | 8 | 32 | 64 GB | +| Standard_D8s_v5 | 4 | 8 | 32 GB | + +For guidance on scaling the conductor for larger deployments, see [System Requirements](intro_system_reqs.md#conductor-scaling-recommendations). + +## What the Template Creates + +When you deploy the conductor using the BYOL template, Azure automatically creates: + +- A VM using the BYOL Session Smart image from the Marketplace. +- A single network interface (`control`) connected to the management subnet. +- A network security group (NSG) associated with the control interface. +- A unique static public IP address assigned to the control interface. + +The following image shows the resulting infrastructure: + +![Conductor deployment](/img/platforms_azure_conductor_deployment.png) + +## Select the BYOL Plan + +1. Go to [Azure Marketplace](https://portal.azure.com) and search for **Session Smart Networking Platform**. +2. Select the **BYOL** plan. +3. Click **Get it now**. +4. Agree to the terms of use and privacy policy. +5. Click the **Plans + Pricing** tab. + +![Plans](/img/platforms_azure_plans.png) + +## Deploy via Azure Portal + +1. On the **Plans + Pricing** tab, click the **Launch** link on the **Juniper Session Smart Conductor** template. + + ![ARM Template](/img/azure-byol-conductor-template.png) + +2. Fill in the template parameters using the following table. For full parameter descriptions, see [Template Parameter Reference](#template-parameter-reference). + + | Parameter | Example Value | Notes | + |-----------|--------------|-------| + | Subscription | _(your subscription)_ | | + | Resource Group | `SSR-RG` | Select existing or create new | + | Location | `eastus` | One word, all lowercase | + | Availability Set Name | `SSR-AvailabilitySet` | Must exist in the same resource group | + | Instance Size | `Standard_F8s_v2` | | + | Instance Name | `Conductor` | VM display name | + | SSR Version | `7.1.4` | The BYOL version to install | + | Artifactory Username | _(your username)_ | Juniper software access | + | Artifactory Token | _(your token)_ | Juniper software access token | + | Managed Identity | _(your managed identity)_ | Must have the permissions listed in [Requirements](#requirements) | + | Virtual Network Name | `SSR-VNet` | Must already exist | + | Control Subnet Name | `ssr-conductor-subnet` | The conductor management subnet | + | Control Allowed CIDR | `0.0.0.0/0` | Restrict to known source IPs after deployment | + | Admin Allowed CIDR | `0.0.0.0/0` | Restrict to known admin IPs after deployment | + | Admin Public Key Data | _(contents of your SSH public key)_ | At least 2048-bit RSA | + + :::caution + `Control Allowed CIDR` and `Admin Allowed CIDR` default to `0.0.0.0/0` for initial deployment. After the deployment completes and your environment is stable, update the associated NSG rules to restrict access to known source addresses. + ::: + +3. Agree to the terms and conditions. +4. Click **Purchase** to launch the deployment. + + ![Deployment complete](/img/platforms_azure_deployment_complete.png) + +5. When the deployment completes, open the **Outputs** tab. Note the following values — you will need them in later steps: + + - **Public IP address** assigned to the conductor management interface. + - **SSH login command** for the Linux VM. + + :::important + Log in to the Linux instance via SSH using the default username `t128` and the private key that corresponds to the public key supplied in **Admin Public Key Data**. + ::: + +## Deploy via Azure CLI or PowerShell + +To deploy programmatically, first enable programmatic deployment: + +1. On the **Plans + Pricing** tab, click **Get started** under the template. +2. Select your subscription and click **Save**. + +![Programmatic deployment](/img/platforms_azure_programmatically.png) + +3. Copy the **URL** for the **Juniper Session Smart Conductor** template from the **Plans + Pricing** tab. +4. Create the parameters file `conductor_byol.parameters.json`: + + ```json + { + "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#", + "contentVersion": "1.0.0.0", + "parameters": { + "location": { "value": "eastus" }, + "availabilitySetName": { "value": "SSR-AvailabilitySet" }, + "instanceSize": { "value": "Standard_F8s_v2" }, + "instanceName": { "value": "Conductor" }, + "SSR Version": { "value": "7.1.4" }, + "artifactoryUsername": { "value": "" }, + "artifactoryToken": { "value": "" }, + "managedIdentity": { "value": "" }, + "virtualNetworkName": { "value": "SSR-VNet" }, + "controlSubnetName": { "value": "ssr-conductor-subnet" }, + "controlAllowedCidr": { "value": "0.0.0.0/0" }, + "adminAllowedCidr": { "value": "0.0.0.0/0" }, + "adminPublicKeyData": { "value": "" } + } + } + ``` + +5. Launch the deployment: + + ```bash + New-AzResourceGroupDeployment -ResourceGroupName SSR-RG ` + -TemplateUri ` + -TemplateParameterFile ./conductor_byol.parameters.json + ``` + + :::important + Log in to the Linux instance via SSH using `t128` as the username and the private key corresponding to the public key in the parameters file. + ::: + +## Deploy with Cloud-init Custom Data + +When launching via the CLI, PowerShell, or automation, you can supply a cloud-init `user-data` block to control the onboarding configuration: + +```yaml +#cloud-config +write_files: + - path: /etc/128T-hardware-bootstrapper/onboarding-config.json + content: | + { + "name": "Conductor", + "ssr-version": "7.1.4", + "mode": "conductor", + "artifactory-user": "", + "artifactory-password": "", + "node-name": "node0", + "cloud-provider": "azure" + } +``` + +| Option | Meaning | +|--------|---------| +| `name` | The name of the conductor. | +| `ssr-version` | The SSR software version to install (BYOL only). | +| `mode` | Set to `conductor` for a conductor deployment. | +| `artifactory-user` | Username portion of the Juniper Artifactory credentials. | +| `artifactory-password` | Password or token portion of the Juniper Artifactory credentials. | +| `node-name` | Name of the conductor node. Use `node0` for a standalone conductor. | +| `cloud-provider` | Set to `azure` for Azure deployments. | +| `download-timeout` | Timeout duration for the BYOL installation (default: `6h`). | +| `download-retries` | Number of installation retry attempts (default: unlimited). | + +## Template Parameter Reference + +| Parameter | Description | +|-----------|-------------| +| Subscription | Subscription for the deployment. | +| Resource Group | Select an existing resource group or create a new one. | +| Region | Auto-populated from the resource group. | +| Location | The Azure location where the VNet exists. One word, all lowercase (for example, `eastus`, `westus`, `westeurope`). See [Azure locations](https://azure.microsoft.com/en-us/global-infrastructure/locations). | +| Availability Set Name | Name of the existing availability set within the same resource group and region. | +| Instance Size | The Azure VM size to use for the conductor. | +| Instance Name | Display name for the conductor VM. | +| SSR Version | SSR software version to install. Set to `7.1.4` for this guide. | +| Artifactory Username | User portion of the Juniper Artifactory credentials. | +| Artifactory Token | Token portion of the Juniper Artifactory credentials. | +| Managed Identity | Azure Managed Identity name. Must have the read permissions listed in [Requirements](#requirements). | +| Virtual Network Name | Name of the existing VNet where the conductor will be deployed. | +| Control Subnet Name | Name of the management subnet within the VNet. | +| Control Allowed CIDR | Source IP CIDR range allowed to reach the conductor control interface. | +| Admin Allowed CIDR | Source IP CIDR range allowed to reach the conductor for administration. Restrict this after deployment. | +| Admin Public Key Data | RSA public key (at least 2048-bit) used to authenticate SSH access to the VM. | + +## Next Step + +Proceed to [Step 2 — Initialize and Access the Conductor](deploy_azure_conductor_install.mdx). diff --git a/sidebars.js b/sidebars.js index c6654447b2c..8153cf44ab9 100644 --- a/sidebars.js +++ b/sidebars.js @@ -25,6 +25,18 @@ module.exports = { "deploy_appendix_vmware_conductor", ], }, + { + "type": "category", + "label": "Azure Conductor", + "items": [ + "deploy_azure_conductor", + "deploy_azure_conductor_vm", + "deploy_azure_conductor_install", + "deploy_azure_conductor_config", + "deploy_azure_conductor_router", + "deploy_appendix_azure_conductor", + ], + }, ], }, { From 0a0dc78c520c63d9f7759b6a5b5082ef958ecc2b Mon Sep 17 00:00:00 2001 From: Chris Date: Wed, 19 Aug 2026 15:16:44 -0400 Subject: [PATCH 2/2] generating Azure hub and spoke deployment guide --- .../_deploy_azure_hub_spoke_network_design.md | 37 ++ docs/deploy_appendix_azure_hub_spoke.mdx | 301 +++++++++++++ docs/deploy_azure_hub_spoke_config.mdx | 426 ++++++++++++++++++ docs/deploy_azure_hub_spoke_hub_vm.mdx | 186 ++++++++ docs/deploy_azure_hub_spoke_overview.mdx | 99 ++++ docs/deploy_azure_hub_spoke_spoke_vm.mdx | 133 ++++++ docs/deploy_azure_hub_spoke_vmbus.mdx | 129 ++++++ docs/deploy_guides_overview.md | 4 +- sidebars.js | 12 + 9 files changed, 1325 insertions(+), 2 deletions(-) create mode 100644 docs/_deploy_azure_hub_spoke_network_design.md create mode 100644 docs/deploy_appendix_azure_hub_spoke.mdx create mode 100644 docs/deploy_azure_hub_spoke_config.mdx create mode 100644 docs/deploy_azure_hub_spoke_hub_vm.mdx create mode 100644 docs/deploy_azure_hub_spoke_overview.mdx create mode 100644 docs/deploy_azure_hub_spoke_spoke_vm.mdx create mode 100644 docs/deploy_azure_hub_spoke_vmbus.mdx diff --git a/docs/_deploy_azure_hub_spoke_network_design.md b/docs/_deploy_azure_hub_spoke_network_design.md new file mode 100644 index 00000000000..cb61c13c19e --- /dev/null +++ b/docs/_deploy_azure_hub_spoke_network_design.md @@ -0,0 +1,37 @@ + + +The following IP addressing and naming scheme is used consistently throughout this guide. Substitute your own values when configuring your network. + +| Parameter | Example Value | Description | +|-----------|--------------|-------------| +| Azure Region | `eastus` | Azure region for all deployed resources | +| Resource Group | `SSR-RG` | Azure resource group containing all resources | +| VNet Name | `SSR-VNet` | Virtual network address space `10.0.0.0/16` | +| Conductor Subnet | `ssr-conductor-subnet` | Conductor management subnet (`10.0.0.0/24`) | +| Conductor Private IP | `10.0.0.10` | Static private IP assigned within the conductor subnet | +| Conductor Public IP | `` | Azure-assigned public IP — used for SSH, GUI, and as the conductor address | +| Authority Name | `Authority128` | SSR organizational authority name | +| Conductor Name | `Conductor` | Conductor system name | +| Hub WAN Subnet | `ssr-hub-wan` | Hub router public (WAN) subnet (`10.0.1.0/24`) | +| Hub LAN Subnet | `ssr-hub-lan` | Hub router private (LAN) subnet (`10.0.2.0/24`) | +| Hub Router Name | `azure-hub-router` | Hub router system name | +| Hub Node Name | `node0` | Hub router node name | +| Hub WAN Device Interface | `wan-dev` | Hub WAN device interface name | +| Hub WAN Network Interface | `wan1` | Hub WAN network interface name | +| Hub LAN Device Interface | `lan-dev` | Hub LAN device interface name | +| Hub LAN Network Interface | `lan1` | Hub LAN network interface name | +| Hub LAN IP | `10.0.2.1/24` | LAN gateway address assigned to the hub LAN interface | +| Hub Tenant | `hub-corp` | Hub LAN-side user tenant | +| Spoke WAN Subnet | `ssr-spoke-wan` | Spoke router public (WAN) subnet (`10.0.3.0/24`) | +| Spoke LAN Subnet | `ssr-spoke-lan` | Spoke router private (LAN) subnet (`10.0.4.0/24`) | +| Spoke Router Name | `azure-spoke-router` | Spoke router system name | +| Spoke Node Name | `node0` | Spoke router node name | +| Spoke WAN Device Interface | `wan-dev` | Spoke WAN device interface name | +| Spoke WAN Network Interface | `wan1` | Spoke WAN network interface name | +| Spoke LAN Device Interface | `lan-dev` | Spoke LAN device interface name | +| Spoke LAN Network Interface | `lan1` | Spoke LAN network interface name | +| Spoke LAN IP | `10.0.4.1/24` | LAN gateway address assigned to the spoke LAN interface | +| Spoke Tenant | `spoke-corp` | Spoke LAN-side user tenant | +| Service Name | `Internet-Traffic` | Internet breakout service | +| Service Address | `0.0.0.0/0` | All internet-bound traffic | +| Neighborhood | `internet` | SVR peering neighborhood name | diff --git a/docs/deploy_appendix_azure_hub_spoke.mdx b/docs/deploy_appendix_azure_hub_spoke.mdx new file mode 100644 index 00000000000..bf283079ade --- /dev/null +++ b/docs/deploy_appendix_azure_hub_spoke.mdx @@ -0,0 +1,301 @@ +--- +title: "Appendix: Azure Hub and Spoke Configuration" +sidebar_label: "Appendix: Hub and Spoke Config" +--- +import NetworkDesign from './_deploy_azure_hub_spoke_network_design.md'; + +This appendix contains the complete SSR PCLI configuration for the `azure-hub-router` and `azure-spoke-router` deployments described in this guide. This configuration reflects the final state after completing all steps through [Step 4 — Configure Hub and Spoke Routers](deploy_azure_hub_spoke_config.mdx). + +:::important +Replace all placeholder values (shown in angle brackets) with values from your environment before applying: + +- `` — public IP of the conductor VM. +- `` — VMBus UUID of the conductor management interface (found using `sudo dpdk-devbind.py --status` on the conductor VM). +- `` — VMBus UUID of the hub router WAN NIC (`eth1`). +- `` — VMBus UUID of the hub router LAN NIC (`eth2`). +- `` — VMBus UUID of the spoke router WAN NIC (`eth1`). +- `` — VMBus UUID of the spoke router LAN NIC (`eth2`). +::: + +## Network Design Reference + + + +## Applying This Configuration + +This configuration can be applied to the conductor using the PCLI import function. + +1. Save the configuration below to a file — for example, `azure-hub-spoke.cfg`. + +2. Copy the file to the conductor: + + ```bash + scp azure-hub-spoke.cfg t128@:/tmp/ + ``` + +3. Log in to the conductor PCLI: + + ```bash + ssh t128@ + su admin + ``` + +4. Enter configuration mode and import: + + ```text + admin@node0.Conductor# import config /tmp/azure-hub-spoke.cfg + ``` + +5. Review any validation warnings, then commit: + + ```text + admin@node0.Conductor (config)# commit + Are you sure you want to commit the candidate config? [y/N]: y + ``` + +Alternatively, you may copy and paste each block into the PCLI while in `configure` → `edit` mode. + +:::note +The authority-level objects the routers depend on (`hub-corp` tenant, `spoke-corp` tenant, `Internet-Traffic` service, authority name, and conductor address) are included in the configuration block below. If your conductor already has an `Internet-Traffic` service or other conflicting objects, reconcile those before importing. +::: + +## Complete Configuration + +```text +config + authority + name Authority128 + + conductor-address + + tenant hub-corp + name hub-corp + exit + + tenant spoke-corp + name spoke-corp + exit + + service Internet-Traffic + name Internet-Traffic + scope public + security internal + + access-policy hub-corp + source hub-corp + exit + + access-policy spoke-corp + source spoke-corp + exit + + address 0.0.0.0/0 + exit + + router Conductor + name Conductor + inter-node-security internal + + node node0 + name node0 + role conductor + + device-interface mgmt-dev + name mgmt-dev + type ethernet + forwarding false + vmbus-uuid + + network-interface mgmt-intf + name mgmt-intf + type management + + address 10.0.0.10 + ip-address 10.0.0.10 + prefix-length 24 + gateway 10.0.0.1 + exit + exit + exit + exit + exit + + router azure-hub-router + name azure-hub-router + inter-node-security internal + + node node0 + name node0 + role combo + + device-interface wan-dev + name wan-dev + type ethernet + forwarding true + vmbus-uuid + + network-interface wan1 + name wan1 + global-id 1 + conductor true + default-route true + source-nat true + management true + + management-vector + name mgmt-vec-wan + priority 100 + exit + + neighborhood internet + name internet + topology hub + exit + + inter-router-security internal + dhcp v4 + exit + exit + + device-interface lan-dev + name lan-dev + type ethernet + forwarding true + vmbus-uuid + + network-interface lan1 + name lan1 + global-id 2 + tenant hub-corp + source-nat true + dhcp disabled + + address 10.0.2.1 + ip-address 10.0.2.1 + prefix-length 24 + exit + exit + exit + exit + + dns-config + mode manual + servers [ 1.1.1.1 8.8.8.8 ] + exit + + service-route internet-breakout + name internet-breakout + service-name Internet-Traffic + + next-hop node0 wan1 + node-name node0 + interface wan1 + exit + exit + exit + + router azure-spoke-router + name azure-spoke-router + inter-node-security internal + + node node0 + name node0 + role combo + + device-interface wan-dev + name wan-dev + type ethernet + forwarding true + vmbus-uuid + + network-interface wan1 + name wan1 + global-id 1 + conductor true + default-route true + source-nat true + management true + + management-vector + name mgmt-vec-wan + priority 100 + exit + + neighborhood internet + name internet + topology spoke + exit + + inter-router-security internal + dhcp v4 + exit + exit + + device-interface lan-dev + name lan-dev + type ethernet + forwarding true + vmbus-uuid + + network-interface lan1 + name lan1 + global-id 2 + tenant spoke-corp + source-nat true + dhcp disabled + + address 10.0.4.1 + ip-address 10.0.4.1 + prefix-length 24 + exit + exit + exit + exit + + dns-config + mode manual + servers [ 1.1.1.1 8.8.8.8 ] + exit + + service-route internet-via-hub + name internet-via-hub + service-name Internet-Traffic + peer azure-hub-router + exit + exit + exit +exit +``` + +## Interface Summary + +### Hub Router (`azure-hub-router`) + +| Interface | Device Interface | VMBus UUID | Type | Configuration | +|-----------|-----------------|-----------|------|---------------| +| `wan1` | `wan-dev` | `` | External | DHCP v4, conductor, default-route, source-nat, management, neighborhood `internet` topology `hub` | +| `lan1` | `lan-dev` | `` | External | Tenant `hub-corp`, static `10.0.2.1/24`, source-nat | + +### Spoke Router (`azure-spoke-router`) + +| Interface | Device Interface | VMBus UUID | Type | Configuration | +|-----------|-----------------|-----------|------|---------------| +| `wan1` | `wan-dev` | `` | External | DHCP v4, conductor, default-route, source-nat, management, neighborhood `internet` topology `spoke` | +| `lan1` | `lan-dev` | `` | External | Tenant `spoke-corp`, static `10.0.4.1/24`, source-nat | + +## Service Route Summary + +| Router | Service Route | Service | Type | Next Hop | Effect | +|--------|--------------|---------|------|---------|--------| +| `azure-hub-router` | `internet-breakout` | `Internet-Traffic` | `service-agent` | `node0/wan1` | Hub LAN and spoke SVR traffic breaks out directly to the internet. | +| `azure-spoke-router` | `internet-via-hub` | `Internet-Traffic` | `peer` | `azure-hub-router` | Spoke internet traffic is forwarded over the SVR peer path to the hub for breakout. | + +## Traffic Flow Reference + +The following table describes how internet traffic flows in the completed hub-and-spoke network. + +| Source | Destination | Path | +|--------|------------|------| +| Hub LAN device (10.0.2.x) | Internet | Hub LAN → `hub-corp` tenant → `Internet-Traffic` service → `internet-breakout` route → hub `wan1` → internet. | +| Spoke LAN device (10.0.4.x) | Internet | Spoke LAN → `spoke-corp` tenant → `Internet-Traffic` service → `internet-via-hub` peer route → SVR path → hub `wan1` → internet. | +| Hub or spoke router | Conductor | Management over forwarding on `wan1` using port 930/4505/4506; management-vector priority 100 on each router's WAN interface. | diff --git a/docs/deploy_azure_hub_spoke_config.mdx b/docs/deploy_azure_hub_spoke_config.mdx new file mode 100644 index 00000000000..4ebdeb44840 --- /dev/null +++ b/docs/deploy_azure_hub_spoke_config.mdx @@ -0,0 +1,426 @@ +--- +title: "Step 4: Configure Hub and Spoke Routers" +sidebar_label: "Configure Hub and Spoke Routers" +--- +import NetworkDesign from './_deploy_azure_hub_spoke_network_design.md'; + +This step configures both routers on the conductor. You will first update the authority-level objects to support hub and spoke tenants, then configure each router's WAN interface, LAN interface, and service routes. The hub router provides direct internet breakout; the spoke router routes internet traffic to the hub over an SVR peer path. + +All steps are performed from the **Conductor GUI** at `https://` unless otherwise noted. + +:::note +If you prefer to apply configuration using the PCLI, the complete example configuration is available in the [Appendix](deploy_appendix_azure_hub_spoke.mdx). +::: + +## Network Design Reference + + + +## Part 1: Update Authority-Level Configuration + +The conductor must have the correct tenants and services configured before either router is activated. If you already completed the [Azure Conductor Deployment Guide](deploy_azure_conductor.mdx) and created a `corp` tenant and `Internet-Traffic` service, you can either rename those objects or create new ones as described below. This guide uses separate tenants for hub and spoke users. + +:::note +Your conductor must already have an authority name and conductor address set. If these are not yet configured, complete steps 1–3 of [Configure the Conductor](deploy_azure_conductor_config.mdx) before continuing. +::: + +### 1. Create the Hub Tenant + +The `hub-corp` tenant represents users on the hub router's LAN. + +1. In the Conductor GUI, select **Configuration**. +2. Select **Authority**. +3. Scroll to **Tenants** and select **ADD**. +4. Enter the name `hub-corp` and select **SAVE**. +5. Select **VALIDATE** then **COMMIT**. + +### 2. Create the Spoke Tenant + +The `spoke-corp` tenant represents users on the spoke router's LAN. + +1. Scroll to **Tenants** and select **ADD**. +2. Enter the name `spoke-corp` and select **SAVE**. +3. Select **VALIDATE** then **COMMIT**. + +### 3. Create or Update the `Internet-Traffic` Service + +The `Internet-Traffic` service matches all internet-bound traffic. Both tenants must be granted access so the hub can forward internet traffic for both hub LAN users and spoke LAN users arriving over SVR. + +1. In the Conductor GUI, select **Configuration**. +2. Select **Authority** from the left panel. +3. Scroll to **Services** and select **ADD** (or select the existing `Internet-Traffic` service if it already exists). +4. Enter the name `Internet-Traffic` and select **SAVE**. +5. Verify **Enabled** is set to `true`. +6. Scroll to **Service Addresses** and select **ADD**. Enter `0.0.0.0/0` and select **SAVE**. +7. Scroll to **Access Policy** and add two entries: + - **Source:** `hub-corp` — select **SAVE**. + - **Source:** `spoke-corp` — select **SAVE**. +8. Select **VALIDATE** then **COMMIT**. + +:::info +The `spoke-corp` access policy on the `Internet-Traffic` service allows traffic from spoke LAN users to be forwarded by the hub router when it arrives over the SVR peer path. Without this policy, the hub drops spoke-originated internet traffic. +::: + +## Part 2: Configure the Hub Router + +### Assign the Hub Router's Asset ID + +1. In the Conductor GUI, select **Configuration**. +2. Under **Routers**, select `azure-hub-router`. +3. Select the **Configure** icon. +4. Select node `node0`. +5. Under **Associated Asset ID**, select the asset ID reported by the hub router VM. +6. Select **VALIDATE** then **COMMIT**. + +### 1. Configure the Hub WAN Interface + +The WAN interface (`eth1` / `ssr-hub-wan`) connects to the internet, obtains a DHCP address, and carries both internet forwarding and conductor management traffic. The neighborhood topology is set to `hub`, which makes this router the internet gateway for spoke routers in the same neighborhood. + +#### 1a. Create the Hub WAN Device Interface + +1. In the Conductor GUI, navigate to the `azure-hub-router` router, then to node `node0`. +2. Scroll to **Device Interfaces** and select **ADD**. +3. Enter the name `wan-dev` and select **SAVE**. +4. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `ethernet` | | + | VMBus UUID | `` | Discovered in [Step 3](deploy_azure_hub_spoke_vmbus.mdx) | + | Forwarding | `true` | | + +5. Select **SAVE**. + +#### 1b. Create the Hub WAN Network Interface + +1. Under the WAN Device Interface, scroll to **Network Interfaces** and select **ADD**. +2. Enter the name `wan1` and select **SAVE**. +3. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `external` | | + | DHCP | `v4` | Azure assigns an IP via DHCP | + | Global-ID | `1` | | + | Conductor | `true` | Marks this interface for conductor connectivity | + | Management | `true` | Enables management over forwarding | + | Default Route | `true` | Linux uses this interface as its default route | + | Source NAT | `true` | Required for management over forwarding | + +4. Scroll to **Management Vector** and select **ADD**. + - Name: `mgmt-vec-wan` + - Priority: `100` + - Select **SAVE**. + +5. Scroll to **Neighborhoods** and select **ADD**. + - Name: `internet` + - Topology: `hub` + - Select **SAVE**. + +6. Select **SAVE**. + +:::important +Setting **Topology** to `hub` on the hub router's neighborhood is what distinguishes it from a spoke. The conductor uses this topology to auto-generate adjacencies between the hub and any spoke routers that share the same neighborhood name with topology `spoke`. + +`Conductor`, `Source NAT`, and `Default Route` must all be `true` on the WAN management interface. Management traffic originates from the `169.254.x.x` range and must be source-NAT'd to a routable address before leaving the interface. +::: + +### 2. Configure the Hub LAN Interface + +The LAN interface (`eth2` / `ssr-hub-lan`) connects to the hub private subnet and assigns the `hub-corp` tenant to inbound traffic. + +#### 2a. Create the Hub LAN Device Interface + +1. Navigate to node `node0` of `azure-hub-router`. +2. Scroll to **Device Interfaces** and select **ADD**. +3. Enter the name `lan-dev` and select **SAVE**. +4. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `ethernet` | | + | VMBus UUID | `` | Discovered in [Step 3](deploy_azure_hub_spoke_vmbus.mdx) | + | Forwarding | `true` | | + +5. Select **SAVE**. + +#### 2b. Create the Hub LAN Network Interface + +1. Under the LAN Device Interface, scroll to **Network Interfaces** and select **ADD**. +2. Enter the name `lan1` and select **SAVE**. +3. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `external` | | + | Global-ID | `2` | | + | DHCP | `disabled` | | + | Tenant | `hub-corp` | Assigns all inbound LAN traffic to the hub-corp tenant | + | Source NAT | `true` | | + +4. Scroll to **Interface Addresses** and select **ADD**. + - IP Address: `10.0.2.1` + - Prefix Length: `24` +5. Select **SAVE**. + +### 3. Configure Hub DNS + +Configure DNS so the hub router can resolve FQDNs for conductor connectivity and software downloads. + +1. Return to the **Router** level for `azure-hub-router`. +2. Scroll to **DNS Config** and select **ADD**. +3. Set **Mode** to `manual` and enter DNS server addresses — for example, `1.1.1.1` and `8.8.8.8`. +4. Select **SAVE**. + +### 4. Create the Hub Internet Breakout Service Route + +The hub routes internet-bound traffic (from both its own LAN users and spoke users arriving over SVR) directly out through its WAN interface. + +1. Return to the **Router** level for `azure-hub-router`. +2. Scroll to **Service Routes** and select **ADD**. +3. Enter the name `internet-breakout` and select **SAVE**. +4. Set the following fields: + + | Field | Value | + |-------|-------| + | Service Name | `Internet-Traffic` | + | Service Route Type | `service-agent` | + +5. Scroll to **Next Hops** and select **ADD**. + - Node Name: `node0` + - Interface: `wan1` +6. Select **SAVE**. +7. Select **VALIDATE** then **COMMIT**. + +## Part 3: Configure the Spoke Router + +### Assign the Spoke Router's Asset ID + +1. In the Conductor GUI, select **Configuration**. +2. Under **Routers**, select `azure-spoke-router`. +3. Select the **Configure** icon. +4. Select node `node0`. +5. Under **Associated Asset ID**, select the asset ID reported by the spoke router VM. +6. Select **VALIDATE** then **COMMIT**. + +### 1. Configure the Spoke WAN Interface + +The spoke WAN interface (`eth1` / `ssr-spoke-wan`) connects to the internet and carries both conductor management traffic and the SVR underlay path to the hub router. The neighborhood topology is set to `spoke`. + +#### 1a. Create the Spoke WAN Device Interface + +1. Navigate to the `azure-spoke-router` router, then to node `node0`. +2. Scroll to **Device Interfaces** and select **ADD**. +3. Enter the name `wan-dev` and select **SAVE**. +4. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `ethernet` | | + | VMBus UUID | `` | Discovered in [Step 3](deploy_azure_hub_spoke_vmbus.mdx) | + | Forwarding | `true` | | + +5. Select **SAVE**. + +#### 1b. Create the Spoke WAN Network Interface + +1. Under the WAN Device Interface, scroll to **Network Interfaces** and select **ADD**. +2. Enter the name `wan1` and select **SAVE**. +3. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `external` | | + | DHCP | `v4` | Azure assigns an IP via DHCP | + | Global-ID | `1` | | + | Conductor | `true` | Marks this interface for conductor connectivity | + | Management | `true` | Enables management over forwarding | + | Default Route | `true` | Linux uses this interface as its default route | + | Source NAT | `true` | Required for management over forwarding | + +4. Scroll to **Management Vector** and select **ADD**. + - Name: `mgmt-vec-wan` + - Priority: `100` + - Select **SAVE**. + +5. Scroll to **Neighborhoods** and select **ADD**. + - Name: `internet` + - Topology: `spoke` + - Select **SAVE**. + +6. Select **SAVE**. + +:::important +Setting **Topology** to `spoke` pairs this router with the hub router in the `internet` neighborhood. The conductor auto-generates adjacencies between the two routers when both are committed, enabling the SVR peer path used by the spoke's internet service route. +::: + +### 2. Configure the Spoke LAN Interface + +The LAN interface (`eth2` / `ssr-spoke-lan`) connects to the spoke private subnet and assigns the `spoke-corp` tenant to inbound traffic. + +#### 2a. Create the Spoke LAN Device Interface + +1. Navigate to node `node0` of `azure-spoke-router`. +2. Scroll to **Device Interfaces** and select **ADD**. +3. Enter the name `lan-dev` and select **SAVE**. +4. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `ethernet` | | + | VMBus UUID | `` | Discovered in [Step 3](deploy_azure_hub_spoke_vmbus.mdx) | + | Forwarding | `true` | | + +5. Select **SAVE**. + +#### 2b. Create the Spoke LAN Network Interface + +1. Under the LAN Device Interface, scroll to **Network Interfaces** and select **ADD**. +2. Enter the name `lan1` and select **SAVE**. +3. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Type | `external` | | + | Global-ID | `2` | | + | DHCP | `disabled` | | + | Tenant | `spoke-corp` | Assigns all inbound LAN traffic to the spoke-corp tenant | + | Source NAT | `true` | | + +4. Scroll to **Interface Addresses** and select **ADD**. + - IP Address: `10.0.4.1` + - Prefix Length: `24` +5. Select **SAVE**. + +### 3. Configure Spoke DNS + +1. Return to the **Router** level for `azure-spoke-router`. +2. Scroll to **DNS Config** and select **ADD**. +3. Set **Mode** to `manual` and enter DNS server addresses — for example, `1.1.1.1` and `8.8.8.8`. +4. Select **SAVE**. + +### 4. Create the Spoke Internet Service Route + +The spoke router does not break out internet traffic directly. Instead, it forwards internet-bound traffic to the hub router over the SVR peer path established by the shared `internet` neighborhood. + +1. Return to the **Router** level for `azure-spoke-router`. +2. Scroll to **Service Routes** and select **ADD**. +3. Enter the name `internet-via-hub` and select **SAVE**. +4. Set the following fields: + + | Field | Value | Notes | + |-------|-------|-------| + | Service Name | `Internet-Traffic` | | + | Service Route Type | `peer` | Routes internet traffic to a peer router via SVR | + | Peer | `azure-hub-router` | The hub router provides internet breakout for the spoke | + +5. Select **SAVE**. +6. Select **VALIDATE** then **COMMIT**. + +:::info +The `peer` service route type directs matched traffic over the SVR path to the named peer router. The hub's `internet-breakout` service route then forwards that traffic to the internet. This is the SSR hub-and-spoke internet breakout pattern. +::: + +## Verify Connectivity + +After committing all configuration, verify both routers are online and forwarding traffic correctly. + +### Verify Both Routers Are Connected to the Conductor + +From the Conductor GUI, select **Routers**. Both `azure-hub-router` and `azure-spoke-router` should show a **Connected** status within 2–5 minutes of the commit. + +From the conductor PCLI: + +```text +admin@node0.Conductor# show peers +``` + +Both routers should appear with status `Up`. After SVR adjacencies form, a third entry for the hub-to-spoke peer should also appear. + +### Verify SVR Peering Between Hub and Spoke + +From the hub router PCLI: + +```text +admin@node0.azure-hub-router# show peers +``` + +The spoke router should appear as an SVR peer with status `Up`. + +From the spoke router PCLI: + +```text +admin@node0.azure-spoke-router# show peers +``` + +The hub router should appear with status `Up`. + +### Verify ARP on the WAN Interfaces + +Azure gateways do not respond to ICMP ping. Use the ARP table to verify WAN connectivity on each router: + +```text +admin@node0.azure-hub-router# show arp +admin@node0.azure-spoke-router# show arp +``` + +Look for **valid** ARP entries on the `wan1` interface of each router. + +### Verify Internet Reachability + +From the hub router: + +```text +admin@node0.azure-hub-router# ping 8.8.8.8 +``` + +From the spoke router: + +```text +admin@node0.azure-spoke-router# ping 8.8.8.8 +``` + +Both routers should reach the internet. Spoke internet traffic traverses the SVR peer path to the hub before being forwarded to the internet. + +### Verify Service Paths + +From the spoke router, confirm that internet traffic resolves through the hub: + +```text +admin@node0.azure-spoke-router# show service-path +``` + +The `Internet-Traffic` service should show a path type of `peer` with `azure-hub-router` as the next-hop peer. + +## Configuration Summary + +### Hub Router + +| Object | Name | Key Settings | +|--------|------|-------------| +| Router | `azure-hub-router` | combo node | +| WAN Device Interface | `wan-dev` | VMBus UUID, forwarding `true` | +| WAN Network Interface | `wan1` | DHCP v4, conductor, management, source-nat, default-route, neighborhood `internet` topology `hub` | +| LAN Device Interface | `lan-dev` | VMBus UUID, forwarding `true` | +| LAN Network Interface | `lan1` | Tenant `hub-corp`, static `10.0.2.1/24`, source-nat | +| DNS | manual | `1.1.1.1`, `8.8.8.8` | +| Service Route | `internet-breakout` | `Internet-Traffic` → `node0/wan1` (direct breakout) | + +### Spoke Router + +| Object | Name | Key Settings | +|--------|------|-------------| +| Router | `azure-spoke-router` | combo node | +| WAN Device Interface | `wan-dev` | VMBus UUID, forwarding `true` | +| WAN Network Interface | `wan1` | DHCP v4, conductor, management, source-nat, default-route, neighborhood `internet` topology `spoke` | +| LAN Device Interface | `lan-dev` | VMBus UUID, forwarding `true` | +| LAN Network Interface | `lan1` | Tenant `spoke-corp`, static `10.0.4.1/24`, source-nat | +| DNS | manual | `1.1.1.1`, `8.8.8.8` | +| Service Route | `internet-via-hub` | `Internet-Traffic` → peer `azure-hub-router` (via SVR) | + +## Related Documentation + +- [Appendix — Complete Configuration](deploy_appendix_azure_hub_spoke.mdx) +- [Management Traffic over Forwarding Interfaces](config_management_over_forwarding.md) +- [Configuring a Device Interface with VMBus UUID](intro_installation_azure.md#configuring-a-device-interface-with-vmbus-uuid) +- [Conductor Deployment Best Practices](bcp_conductor_deployment.md) diff --git a/docs/deploy_azure_hub_spoke_hub_vm.mdx b/docs/deploy_azure_hub_spoke_hub_vm.mdx new file mode 100644 index 00000000000..06594f0def7 --- /dev/null +++ b/docs/deploy_azure_hub_spoke_hub_vm.mdx @@ -0,0 +1,186 @@ +--- +title: "Step 1: Create the Hub Router VM" +sidebar_label: "Create the Hub Router VM" +--- +import NetworkDesign from './_deploy_azure_hub_spoke_network_design.md'; + +This step deploys the BYOL Hub Router VM from the Azure Marketplace. The deployment template creates the VM, attaches it to the hub WAN and LAN subnets, and runs a cloud-init bootstrapper that installs SSR 7.1.4 and configures the node as a conductor-managed router automatically. + +## Network Design Reference + + + +## Requirements + +The following infrastructure must exist in your Azure subscription before deploying the hub router: + +- The `SSR-VNet` VNet with the `ssr-hub-wan` and `ssr-hub-lan` subnets already created. +- An Availability Set named `SSR-HubSet` in the same resource group and region. +- A **Managed Identity** assigned the following minimum read permissions: + + ``` + Microsoft.Compute/virtualMachines/read + Microsoft.Network/virtualNetworks/read + Microsoft.Network/networkInterfaces/read + ``` + +- The conductor's public IP address from the [Azure Conductor Deployment Guide](deploy_azure_conductor.mdx). + +:::note +A dedicated management subnet is not required. Management traffic travels over the WAN forwarding interface using [Management Traffic over Forwarding Interfaces](config_management_over_forwarding.md). +::: + +## Recommended VM Sizes + +| Azure VM Size | Max vNICs | vCPU Cores | Memory | +|---------------|-----------|-----------|--------| +| Standard_F8s_v2 | 4 | 8 | 16 GB | +| Standard_F16s_v2 | 4 | 16 | 32 GB | +| Standard_F32s_v2 | 8 | 32 | 64 GB | +| Standard_D8s_v5 | 4 | 8 | 32 GB | + +For guidance on sizing for larger deployments, see [System Requirements](intro_system_reqs.md). + +## What the Template Creates + +When you deploy the hub router using the BYOL conductor-managed router template, Azure automatically creates: + +- A VM using the BYOL Session Smart image from the Marketplace. +- Three network interfaces: management (`eth0`), WAN/public (`eth1`), and LAN/private (`eth2`). +- A network security group associated with each interface. +- A unique public IP address assigned to the WAN interface. + +The management interface (`eth0`) is not used in this guide. Management traffic travels over the WAN forwarding interface instead. + +## Deploy via Azure Portal + +1. Go to [Azure Marketplace](https://portal.azure.com) and search for **Session Smart Networking Platform**. +2. Select the **BYOL** plan. +3. Click **Get it now** and agree to the terms of use and privacy policy. +4. Click the **Plans + Pricing** tab. + + ![Plans](/img/platforms_azure_plans.png) + +5. Click the **Launch** link on the **Juniper Session Smart Conductor-managed Router** template. + + ![Router ARM Template](/img/azure-byol-conductor-managed-template.png) + +6. Fill in the template parameters using the following table: + + | Parameter | Example Value | Notes | + |-----------|--------------|-------| + | Subscription | _(your subscription)_ | | + | Resource Group | `SSR-RG` | | + | Location | `eastus` | One word, all lowercase | + | Availability Set Name | `SSR-HubSet` | Must exist in the same resource group | + | Instance Size | `Standard_F8s_v2` | | + | Instance Name | `azure-hub-router` | | + | SSR Version | `7.1.4` | | + | Artifactory Username | _(your username)_ | | + | Artifactory Token | _(your token)_ | | + | Managed Identity | _(your managed identity)_ | | + | Virtual Network Name | `SSR-VNet` | | + | Public Subnet Name | `ssr-hub-wan` | Hub WAN subnet | + | Private Subnet Name | `ssr-hub-lan` | Hub LAN subnet | + | Public Subnet Allowed CIDR | `0.0.0.0/0` | Restrict after deployment | + | Private Subnet Allowed CIDR | `0.0.0.0/0` | | + | Admin Allowed CIDR | `0.0.0.0/0` | Restrict after deployment | + | Primary Control IP | `` | Public IP of the conductor | + | Secondary Control IP | _(leave blank)_ | Only required for HA conductor deployments | + | Admin Public Key Data | _(contents of your SSH public key)_ | | + + :::caution + `Public Subnet Allowed CIDR` and `Admin Allowed CIDR` default to `0.0.0.0/0` for initial deployment. After the environment is stable, update the associated NSG rules to restrict access to known source addresses. + ::: + +7. Agree to the terms and conditions. +8. Click **Purchase** to launch the deployment. + + ![Deployment complete](/img/platforms_azure_deployment_complete.png) + +9. When the deployment completes, open the **Outputs** tab and note the **public IP address** assigned to the hub WAN interface. You will need this value in later steps. + +## Deploy via Azure CLI or PowerShell + +To deploy programmatically, first enable programmatic deployment for the BYOL plan, then create the parameters file `hub_router_byol.parameters.json`: + +```json +{ + "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#", + "contentVersion": "1.0.0.0", + "parameters": { + "location": { "value": "eastus" }, + "availabilitySetName": { "value": "SSR-HubSet" }, + "instanceSize": { "value": "Standard_F8s_v2" }, + "instanceName": { "value": "azure-hub-router" }, + "SSR Version": { "value": "7.1.4" }, + "artifactoryUsername": { "value": "" }, + "artifactoryToken": { "value": "" }, + "managedIdentity": { "value": "" }, + "virtualNetworkName": { "value": "SSR-VNet" }, + "publicSubnetName": { "value": "ssr-hub-wan" }, + "privateSubnetName": { "value": "ssr-hub-lan" }, + "publicSubnetAllowedCidr": { "value": "0.0.0.0/0" }, + "privateSubnetAllowedCidr": { "value": "0.0.0.0/0" }, + "adminAllowedCidr": { "value": "0.0.0.0/0" }, + "conductorPrimaryControlIP": { "value": "" }, + "adminPublicKeyData": { "value": "" } + } +} +``` + +Launch the deployment: + +```bash +New-AzResourceGroupDeployment -ResourceGroupName SSR-RG ` + -TemplateUri ` + -TemplateParameterFile ./hub_router_byol.parameters.json +``` + +## Cloud-init Onboarding + +When launching via CLI or automation, you can supply the following `user-data` block to configure onboarding: + +```yaml +#cloud-config +write_files: + - path: /etc/128T-hardware-bootstrapper/onboarding-config.json + content: | + { + "name": "azure-hub-router", + "ssr-version": "7.1.4", + "mode": "conductor-managed", + "conductor-hosts": [""], + "artifactory-user": "", + "artifactory-password": "", + "cloud-provider": "azure" + } +``` + +| Option | Meaning | +|--------|---------| +| `name` | The name of the router as it will appear on the conductor. | +| `ssr-version` | The SSR software version to install. | +| `mode` | Set to `conductor-managed`. | +| `conductor-hosts` | List of conductor control IP addresses. | +| `artifactory-user` | Artifactory credentials username. | +| `artifactory-password` | Artifactory credentials password or token. | +| `cloud-provider` | Set to `azure`. | + +## Network Interface Layout + +The BYOL conductor-managed router template deploys a VM with three network interfaces attached in the following order: + +| Linux Interface | Azure NIC Name | Subnet | +|-----------------|---------------|--------| +| `eth0` | Router-mgmt | _(not used in this guide)_ | +| `eth1` | Router-public | `ssr-hub-wan` | +| `eth2` | Router-private | `ssr-hub-lan` | + +:::note +Record the hub router's public WAN IP from the Azure Portal Outputs tab. You will need it when deploying the spoke router and when configuring the conductor to reach this router for management purposes. +::: + +## Next Step + +Proceed to [Step 2 — Create the Spoke Router VM](deploy_azure_hub_spoke_spoke_vm.mdx). diff --git a/docs/deploy_azure_hub_spoke_overview.mdx b/docs/deploy_azure_hub_spoke_overview.mdx new file mode 100644 index 00000000000..e98e272cc73 --- /dev/null +++ b/docs/deploy_azure_hub_spoke_overview.mdx @@ -0,0 +1,99 @@ +--- +title: "Deploying Azure Hub and Spoke Routers" +sidebar_label: Overview +--- +import NetworkDesign from './_deploy_azure_hub_spoke_network_design.md'; + +This guide walks you through deploying a **hub router and a spoke router on Azure** as conductor-managed SSR instances using the Bring Your Own License (BYOL) plan. When you complete this guide, both routers will be running SSR 7.1.4, connected to a pre-existing SSR conductor, and forwarding traffic with the following behavior: + +- **Hub router** — provides direct internet breakout for hub LAN users and acts as the internet gateway for the spoke router over an SVR peer path. +- **Spoke router** — provides LAN services for spoke users and routes internet-bound traffic through the hub router via SVR. +- **Both routers** — reach the conductor using management over forwarding on their WAN interfaces. + +:::note +This guide assumes a conductor is already installed and running SSR 7.1.4. If you have not yet deployed a conductor, complete the [Azure Conductor Deployment Guide](deploy_azure_conductor.mdx) first. +::: + +## Guide Topics + +| Step | Topic | Description | +|------|-------|-------------| +| 1 | [Create the Hub Router VM](deploy_azure_hub_spoke_hub_vm.mdx) | Deploy the BYOL Hub Router VM from the Azure Marketplace | +| 2 | [Create the Spoke Router VM](deploy_azure_hub_spoke_spoke_vm.mdx) | Deploy the BYOL Spoke Router VM from the Azure Marketplace | +| 3 | [Verify Installation and Discover VMBus UUIDs](deploy_azure_hub_spoke_vmbus.mdx) | Wait for SSR 7.1.4 installation to complete and identify NIC VMBus UUIDs for both routers | +| 4 | [Configure Hub and Spoke Routers](deploy_azure_hub_spoke_config.mdx) | Configure both routers on the conductor with WAN, LAN, and internet routing | +| — | [Appendix — Hub and Spoke Configuration](deploy_appendix_azure_hub_spoke.mdx) | Complete PCLI configuration reference for both routers | + +## Network Topology + +The diagram below shows the logical network this guide builds. + +```mermaid +graph TD + Internet((Internet)) + subgraph Azure["Azure — eastus"] + subgraph VNet["SSR-VNet 10.0.0.0/16"] + Conductor["SSR Conductor\nPrivate: 10.0.0.10/24\nSubnet: ssr-conductor-subnet"] + HubRouter["Hub Router\n(azure-hub-router)\nWAN: 10.0.1.x/24 — DHCP\nLAN: 10.0.2.1/24"] + SpokeRouter["Spoke Router\n(azure-spoke-router)\nWAN: 10.0.3.x/24 — DHCP\nLAN: 10.0.4.1/24"] + HubLAN["Hub LAN Devices\nhub-corp\n10.0.2.0/24"] + SpokeLAN["Spoke LAN Devices\nspoke-corp\n10.0.4.0/24"] + end + end + ISP(["Azure Internet Gateway"]) + + Internet <-->|"Internet"| ISP + ISP <-->|"WAN — DHCP"| HubRouter + ISP <-->|"WAN — DHCP\n(management + SVR underlay)"| SpokeRouter + HubRouter <-->|"Internet Breakout\nInternet-Traffic"| Internet + HubLAN <-->|"LAN"| HubRouter + SpokeLAN <-->|"LAN"| SpokeRouter + SpokeRouter <-->|"SVR — Internet-Traffic\ntopology: spoke → hub"| HubRouter + HubRouter <-->|"Management Port 930/4505/4506"| Conductor + SpokeRouter <-->|"Management Port 930/4505/4506"| Conductor +``` + +## Roles + +| Device | Type | Role | +|--------|------|------| +| `Conductor` | Azure VM (BYOL) | Pre-existing conductor — centralized management and provisioning | +| `azure-hub-router` | Azure VM (BYOL) | Hub router — internet breakout for hub LAN and spoke SVR traffic | +| `azure-spoke-router` | Azure VM (BYOL) | Spoke router — LAN services, routes internet via hub SVR peer | + +## Network Design Reference + + + +## Prerequisites + +Before beginning, ensure the following are available: + +- **Pre-existing SSR conductor** — running SSR 7.1.4 with a static public IP reachable from the hub and spoke WAN interfaces. This guide uses the conductor from the [Azure Conductor Deployment Guide](deploy_azure_conductor.mdx). +- **Azure subscription** — with permission to create VMs, VNets, network security groups, and managed identities. +- **Azure VNet** — `SSR-VNet` with at least the following subnets already created: + - `ssr-hub-wan` — hub router WAN subnet; must have internet egress. + - `ssr-hub-lan` — hub router LAN subnet. + - `ssr-spoke-wan` — spoke router WAN subnet; must have internet egress. + - `ssr-spoke-lan` — spoke router LAN subnet. +- **Two Azure Availability Sets** — one for the hub VM (`SSR-HubSet`) and one for the spoke VM (`SSR-SpokeSet`), in the same resource group. +- **Azure Managed Identity** — with the minimum read permissions listed in [Step 1](deploy_azure_hub_spoke_hub_vm.mdx#requirements). +- **Juniper software access credentials** — Artifactory username and token for SSR software downloads. +- **SSH key pair** — RSA 2048-bit or stronger; the public key is supplied to both deployment templates. + +## Software Version Requirements + +This guide installs **SSR 7.1.4** on both routers. The conductor must be running SSR 7.1.4 or newer before deploying the routers. + +:::note +The router software version must be lower than or equal to the conductor software version. +::: + +## Related Documentation + +- [Azure Conductor Deployment Guide](deploy_azure_conductor.mdx) +- [Management Traffic over Forwarding Interfaces](config_management_over_forwarding.md) +- [Conductor Deployment Best Practices](bcp_conductor_deployment.md) +- [Onboard an SSR Device to a Conductor](onboard_ssr_to_conductor.md) +- [Installing a BYOL Conductor-managed Router in Azure](intro_installation_byol_azure_conductor.md) +- [System Requirements](intro_system_reqs.md) diff --git a/docs/deploy_azure_hub_spoke_spoke_vm.mdx b/docs/deploy_azure_hub_spoke_spoke_vm.mdx new file mode 100644 index 00000000000..0e175cbacbd --- /dev/null +++ b/docs/deploy_azure_hub_spoke_spoke_vm.mdx @@ -0,0 +1,133 @@ +--- +title: "Step 2: Create the Spoke Router VM" +sidebar_label: "Create the Spoke Router VM" +--- +import NetworkDesign from './_deploy_azure_hub_spoke_network_design.md'; + +This step deploys the BYOL Spoke Router VM from the Azure Marketplace using the same conductor-managed router template used for the hub router. The bootstrapper installs SSR 7.1.4 and connects the spoke to the conductor automatically. + +## Network Design Reference + + + +## Requirements + +The following infrastructure must exist in your Azure subscription before deploying the spoke router: + +- The `SSR-VNet` VNet with the `ssr-spoke-wan` and `ssr-spoke-lan` subnets already created. +- An Availability Set named `SSR-SpokeSet` in the same resource group and region. +- The same **Managed Identity** used for the hub router, or a separate identity with the same minimum read permissions. + +:::note +You can deploy the spoke VM while the hub VM bootstrapper is still running. Both installations proceed in parallel; you verify both in [Step 3](deploy_azure_hub_spoke_vmbus.mdx). +::: + +## Deploy via Azure Portal + +1. Return to the **Session Smart Networking Platform BYOL** offering in the Azure Marketplace. +2. Click **Get it now** and agree to the terms. +3. Click the **Plans + Pricing** tab. + + ![Plans](/img/platforms_azure_plans.png) + +4. Click the **Launch** link on the **Juniper Session Smart Conductor-managed Router** template. + + ![Router ARM Template](/img/azure-byol-conductor-managed-template.png) + +5. Fill in the template parameters using the following table: + + | Parameter | Example Value | Notes | + |-----------|--------------|-------| + | Subscription | _(your subscription)_ | | + | Resource Group | `SSR-RG` | | + | Location | `eastus` | One word, all lowercase | + | Availability Set Name | `SSR-SpokeSet` | Must exist in the same resource group | + | Instance Size | `Standard_F8s_v2` | | + | Instance Name | `azure-spoke-router` | | + | SSR Version | `7.1.4` | | + | Artifactory Username | _(your username)_ | | + | Artifactory Token | _(your token)_ | | + | Managed Identity | _(your managed identity)_ | | + | Virtual Network Name | `SSR-VNet` | | + | Public Subnet Name | `ssr-spoke-wan` | Spoke WAN subnet | + | Private Subnet Name | `ssr-spoke-lan` | Spoke LAN subnet | + | Public Subnet Allowed CIDR | `0.0.0.0/0` | Restrict after deployment | + | Private Subnet Allowed CIDR | `0.0.0.0/0` | | + | Admin Allowed CIDR | `0.0.0.0/0` | Restrict after deployment | + | Primary Control IP | `` | Public IP of the conductor | + | Secondary Control IP | _(leave blank)_ | Only required for HA conductor deployments | + | Admin Public Key Data | _(contents of your SSH public key)_ | | + +6. Agree to the terms and conditions. +7. Click **Purchase** to launch the deployment. + + ![Deployment complete](/img/platforms_azure_deployment_complete.png) + +8. When the deployment completes, open the **Outputs** tab and note the **public IP address** assigned to the spoke WAN interface. + +## Deploy via Azure CLI or PowerShell + +Create the parameters file `spoke_router_byol.parameters.json`: + +```json +{ + "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#", + "contentVersion": "1.0.0.0", + "parameters": { + "location": { "value": "eastus" }, + "availabilitySetName": { "value": "SSR-SpokeSet" }, + "instanceSize": { "value": "Standard_F8s_v2" }, + "instanceName": { "value": "azure-spoke-router" }, + "SSR Version": { "value": "7.1.4" }, + "artifactoryUsername": { "value": "" }, + "artifactoryToken": { "value": "" }, + "managedIdentity": { "value": "" }, + "virtualNetworkName": { "value": "SSR-VNet" }, + "publicSubnetName": { "value": "ssr-spoke-wan" }, + "privateSubnetName": { "value": "ssr-spoke-lan" }, + "publicSubnetAllowedCidr": { "value": "0.0.0.0/0" }, + "privateSubnetAllowedCidr": { "value": "0.0.0.0/0" }, + "adminAllowedCidr": { "value": "0.0.0.0/0" }, + "conductorPrimaryControlIP": { "value": "" }, + "adminPublicKeyData": { "value": "" } + } +} +``` + +Launch the deployment: + +```bash +New-AzResourceGroupDeployment -ResourceGroupName SSR-RG ` + -TemplateUri ` + -TemplateParameterFile ./spoke_router_byol.parameters.json +``` + +## Cloud-init Onboarding + +```yaml +#cloud-config +write_files: + - path: /etc/128T-hardware-bootstrapper/onboarding-config.json + content: | + { + "name": "azure-spoke-router", + "ssr-version": "7.1.4", + "mode": "conductor-managed", + "conductor-hosts": [""], + "artifactory-user": "", + "artifactory-password": "", + "cloud-provider": "azure" + } +``` + +## Network Interface Layout + +| Linux Interface | Azure NIC Name | Subnet | +|-----------------|---------------|--------| +| `eth0` | Router-mgmt | _(not used in this guide)_ | +| `eth1` | Router-public | `ssr-spoke-wan` | +| `eth2` | Router-private | `ssr-spoke-lan` | + +## Next Step + +After both VMs are deployed, proceed to [Step 3 — Verify Installation and Discover VMBus UUIDs](deploy_azure_hub_spoke_vmbus.mdx). diff --git a/docs/deploy_azure_hub_spoke_vmbus.mdx b/docs/deploy_azure_hub_spoke_vmbus.mdx new file mode 100644 index 00000000000..48f907f59ff --- /dev/null +++ b/docs/deploy_azure_hub_spoke_vmbus.mdx @@ -0,0 +1,129 @@ +--- +title: "Step 3: Verify Installation and Discover VMBus UUIDs" +sidebar_label: "Verify and Discover VMBus UUIDs" +--- +import NetworkDesign from './_deploy_azure_hub_spoke_network_design.md'; + +This step waits for SSR 7.1.4 to finish installing on both VMs, confirms both routers appear on the conductor, and discovers the VMBus UUIDs for the WAN and LAN interfaces on each router. You must record these UUIDs before configuring the routers on the conductor. + +## Network Design Reference + + + +## Wait for Installation to Complete + +The BYOL bootstrapper installs SSR 7.1.4 automatically after each VM is deployed. This process takes approximately **10–15 minutes** per VM after it first starts. Both VMs install in parallel, so you do not need to wait for one to finish before checking the other. + +Monitor installation progress by connecting to each VM via SSH: + +```bash +# Hub router +ssh t128@ + +# Spoke router (separate terminal) +ssh t128@ +``` + +Once logged in, check the bootstrapper journal for progress: + +```bash +journalctl -u 128T-hardware-bootstrapper -f +``` + +Installation is complete on each VM when you see output similar to: + +``` +Device successfully initialized +``` + +## Verify the Routers Are Running + +On each router, enter the SSR PCLI and confirm the system is running: + +```bash +su admin +``` + +```text +admin@node0.azure-hub-router# show system +``` + +The status should return `running`. Repeat for the spoke router: + +```text +admin@node0.azure-spoke-router# show system +``` + +## Verify the Routers Appear on the Conductor + +After installation, each router contacts the conductor and appears as a pending asset. + +1. In the Conductor GUI, select **Configuration**. +2. Select **Authority** and look under **Routers**. +3. Both `azure-hub-router` and `azure-spoke-router` should appear with pending associations. + +If a router does not appear within 15 minutes of installation completing, verify that: +- The conductor's public IP is reachable from the router WAN subnet over ports 930, 4505, and 4506. +- The correct conductor IP was supplied in the deployment template or cloud-init block. + +## Discover VMBus UUIDs + +In Azure, device interfaces are identified by **VMBus UUID** rather than PCI address. You must discover the VMBus UUID for each WAN and LAN interface before configuring the routers on the conductor. + +Perform the following steps on **each router** separately. Record the UUIDs — you will need them in [Step 4](deploy_azure_hub_spoke_config.mdx). + +### Step 1: Run dpdk-devbind on the Router VM + +SSH into the router VM and run: + +```bash +sudo dpdk-devbind.py --status +``` + +In the **VMBus devices** section, the first column contains the VMBus UUID. The `if` parameter shows the associated Linux interface name. + +Example output: + +``` +VMBus devices using DPDK-compatible driver +========================================== +... + +Other VMBus devices +=================== + 'Hyper-V NIC VF [140...] if=eth1 drv=hv_netvsc ... + 'Hyper-V NIC VF [140...] if=eth2 drv=hv_netvsc ... +``` + +### Step 2: Map Azure NICs to VMBus UUIDs + +1. Log in to the [Azure Portal](https://portal.azure.com). +2. Navigate to the router VM and select **Networking** under **Settings**. + + ![Azure Networking Settings](/img/VMBusAzureUI1.png) + +3. The attached network interfaces are listed from left to right: **Router-mgmt**, **Router-public**, **Router-private**. + + ![Azure Port UI](/img/VMBusAzureUI2.png) + +4. Cross-reference the Linux interface names from `dpdk-devbind.py` with the Azure portal to build the following mapping for each router: + + | Azure NIC Name | Linux Interface | Subnet | VMBus UUID | + |----------------|----------------|--------|-----------| + | Router-public | `eth1` | WAN subnet | _(from dpdk-devbind.py)_ | + | Router-private | `eth2` | LAN subnet | _(from dpdk-devbind.py)_ | + +### VMBus UUID Reference Table + +Record your discovered UUIDs using the following table. You will substitute these values throughout [Step 4](deploy_azure_hub_spoke_config.mdx). + +| Router | Interface | Role | VMBus UUID | +|--------|-----------|------|-----------| +| `azure-hub-router` | `eth1` | WAN (`ssr-hub-wan`) | `` | +| `azure-hub-router` | `eth2` | LAN (`ssr-hub-lan`) | `` | +| `azure-spoke-router` | `eth1` | WAN (`ssr-spoke-wan`) | `` | +| `azure-spoke-router` | `eth2` | LAN (`ssr-spoke-lan`) | `` | + +## Next Step + +Proceed to [Step 4 — Configure Hub and Spoke Routers](deploy_azure_hub_spoke_config.mdx). diff --git a/docs/deploy_guides_overview.md b/docs/deploy_guides_overview.md index 3c94da380d6..64d8a1fd239 100644 --- a/docs/deploy_guides_overview.md +++ b/docs/deploy_guides_overview.md @@ -5,8 +5,8 @@ sidebar_label: Overview Conductor and Router Deployment Guides are provided to help walk a network engineer through the steps required to stand up a conductor-managed SSR network. -Conductor deployments currently include VMware ESXi. In this guide the conductor will have a configuration ready for a branch router to onboard and come online, managed by the conductor, forwarding internet traffic for LAN users, and reachable by the conductor over the same WAN interface used for internet breakout. +Conductor deployments are available for VMware ESXi and Azure. Each conductor guide walks you through deploying the conductor VM, initializing SSR software, configuring the authority, and preparing the conductor to manage routers. -Router deployments are currently under development. +Router deployment guides are available for VMware ESXi and Azure. The Azure guide covers a hub-and-spoke topology where both routers are deployed as BYOL Azure VMs, managed by a pre-existing conductor, and connected via SVR peering with the hub providing internet breakout for both local LAN users and spoke LAN users. The deployment guides are intended to be used independently of one another, allowing you to mix and match conductor and router platforms. \ No newline at end of file diff --git a/sidebars.js b/sidebars.js index 8153cf44ab9..5b540a2fbc4 100644 --- a/sidebars.js +++ b/sidebars.js @@ -55,6 +55,18 @@ module.exports = { "deploy_appendix_vmware_router", ], }, + { + "type": "category", + "label": "Azure Hub and Spoke Routers", + "items": [ + "deploy_azure_hub_spoke_overview", + "deploy_azure_hub_spoke_hub_vm", + "deploy_azure_hub_spoke_spoke_vm", + "deploy_azure_hub_spoke_vmbus", + "deploy_azure_hub_spoke_config", + "deploy_appendix_azure_hub_spoke", + ], + }, ], }, ],