Repository navigation
Docs 550 azure hub and spoke deployment guide - #1158
Conversation
| - `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. |
There was a problem hiding this comment.
Not necessarily needed. iirc, the conductor guide didnt use them, probably best to omit here
| sidebar_label: "Create the Hub Router VM" | ||
| --- | ||
|
|
||
| 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. |
There was a problem hiding this comment.
This step deploys the BYOL SSR VM from the Azure Marketplace as a Hub Router. The deployment template creates an instance, attaches it to the hub WAN and LAN subnet, installs SSR 7.1.4, ...
| Microsoft.Network/virtualNetworks/read | ||
| Microsoft.Network/networkInterfaces/read | ||
| ``` | ||
| **^ We don't need this ^ do we?** |
| 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 (`ge-0-0`), WAN/public (`ge-0-1`), and LAN/private (`ge-0-2`). |
There was a problem hiding this comment.
For the sake of the guide, don't use a management interface. There are already a few spots that say we're using mgmt over forwarding (WAN). This line would then say
Two network interfaces: WAN/public (ge-0-0) and LAN/private (ge-0-1)
| - 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. |
There was a problem hiding this comment.
Can probably omit this line. referencing eth0 will add confusion
There was a problem hiding this comment.
If you want to keep something along these lines
The router template supports an additional management interface. This is not used for this guide. Management traffic travels over the WAN forwarding interface intstead.
| From the conductor PCLI: | ||
|
|
||
| ``` | ||
| [email protected]# show peers |
There was a problem hiding this comment.
remove? Nothing else uses pcli commands
| Replace all placeholder values (shown in angle brackets) with values from your environment before applying: | ||
|
|
||
| - `<conductor-public-ip>` — public IP of the conductor VM. | ||
| - `<conductor-vmbus-uuid>` — VMBus UUID of the conductor management interface (found using `sudo dpdk-devbind.py --status` on the conductor VM). |
There was a problem hiding this comment.
Found from viewing devicemap.json
|
|
||
| - `<conductor-public-ip>` — public IP of the conductor VM. | ||
| - `<conductor-vmbus-uuid>` — VMBus UUID of the conductor management interface (found using `sudo dpdk-devbind.py --status` on the conductor VM). | ||
| - `<hub-wan-vmbus-uuid>` — VMBus UUID of the hub router WAN NIC (`eth1`). |
There was a problem hiding this comment.
ge-0-0, ge-0-1 instead of eth1,2
| 2. Copy the file to the conductor: | ||
|
|
||
| ```bash | ||
| scp azure-hub-spoke.cfg t128@<conductor-public-ip>:/tmp/ |
| 3. Log in to the conductor PCLI: | ||
|
|
||
| ```bash | ||
| ssh t128@<conductor-public-ip> |
| - `ssr-spoke-lan` — spoke router LAN subnet. | ||
| - **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. |
There was a problem hiding this comment.
Not actually a prerequisite. It can be created in the template
| 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. |
There was a problem hiding this comment.
Remove as the parameter isn't set in the below examples (and not necessary)
| - 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). |
There was a problem hiding this comment.
add "If an OOBM interface is not used, management traffic travels over the WAN forwarding interface using"
| 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. | ||
| - Two network interfaces: WAN/public (ge-0-0) and LAN/private (ge-0-1). |
There was a problem hiding this comment.
nit format the ge-0-0 with `
|
|
||
| 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. |
There was a problem hiding this comment.
A VM using the BYOL Session Smart image from the Marketplace. Running SSR software and a basic configuration.
Or something like that. i.e. just add that SSR is installed and configured and running
|
|
||
| ## 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** after the VM first starts. Both VMs install in parallel, so you do not need to wait for one to finish before checking the other. |
There was a problem hiding this comment.
The BYOL software installs SSR 7.1.4 automatically...
|
|
||
| ``` | ||
| journalctl -u 128T-hardware-bootstrapper -f | ||
| ``` |
There was a problem hiding this comment.
I don't like this method as it can be very misleading and adds a lot of confusion. Especially for an easy-to-follow deployment guide. Can we just say this an not include looking at hwb journal?
The installation is complete when the SSR PCLI launches.
Or better yet, simplify this entire section to "The installation is complete when both routers appear in show assets on the conductor
There was a problem hiding this comment.
Reading further... Just remove this section and rely on Verify the Routers are Running and Verify the Routers Appear on the Conductor
|
|
||
| ``` | ||
| # Hub router | ||
| ssh -i t128@<hub-router-public-ip> |
There was a problem hiding this comment.
ssh -i t128@<...>
same below
| 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 | Subnet | VMBus UUID | | ||
| |--------|-----------|------|-----------| |
There was a problem hiding this comment.
Missing a block of dashes which is causing formatting to be screwed up
| 2. Copy the file to the conductor: | ||
|
|
||
| ``` | ||
| scp -i azure-hub-spoke.cfg t128@<conductor-public-ip>:/tmp/ |
There was a problem hiding this comment.
scp -i azure-hub-spoke.cfg t128@:/tmp/
…correct, and other interim edits. More to come.
No description provided.