diff --git a/docs/_byol_aws_instance_types.md b/docs/_byol_aws_instance_types.md new file mode 100644 index 00000000000..5031b2e4e11 --- /dev/null +++ b/docs/_byol_aws_instance_types.md @@ -0,0 +1,18 @@ + + +The following instance sizes are supported for virtual SSR in AWS. Choose the size that best meets your requirements. More information can be found in the [AWS Documentation](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-types.html) + +| AWS Instance Type | Comperable SSR Model | Max vNICs Supported | vCPU Cores | Memory (GiB) | +| ----------------- | -------------------- | ------------------- | ------ | -- | +| c5n.xlarge | SSR120, SSR400, SSR440 | 4 | 4 | 10.5 | +| c5n.2xlarge | SSR130 | 4 | 8 | 21 | +| r8in.2xlarge | SSR1200 | 4 | 8 | 64 | +| r8in.4xlarge | SSR1300 | 8 | 16 | 128 | +| r8in.8xlarge | SSR1400 | 8 | 32 | 256 | +| r8in.16xlarge | SSR1500 | 8 | 64 | 512 | + +Session Smart Router Size recommendatations can be found in [System Requirements](intro_system_reqs.md). + +:::note +Recommendations are based strictly on hardware equivalency, matching vCPU and memory specifications of physical SSR appliance models models +::: \ No newline at end of file diff --git a/docs/_byol_azure_instance_types.md b/docs/_byol_azure_instance_types.md new file mode 100644 index 00000000000..538dff6ee49 --- /dev/null +++ b/docs/_byol_azure_instance_types.md @@ -0,0 +1,12 @@ + + +The following instance types are supported for virtual SSR in Azure. Choose the size that best meets your requirements. More information can be found in the [Azure Documentation](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes). + +| Recommended Azure VM Size | Max vNICs Supported | 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 | + +Session Smart Router Size recommendatations can be found in [System Requirements](intro_system_reqs.md). diff --git a/docs/_byol_gcp_instance_types.md b/docs/_byol_gcp_instance_types.md new file mode 100644 index 00000000000..2466669446f --- /dev/null +++ b/docs/_byol_gcp_instance_types.md @@ -0,0 +1,17 @@ + +The following instance types are supported for virtual SSR in GCP. Choose the size that best meets your requirements. More information on GCP instance types can be found in the [GCP Documentation](https://docs.cloud.google.com/compute/docs/compute-optimized-machines#c2_machine_types). + +| GCP Instance Type | Comperable SSR Model | Max vNICs Supported | vCPU Cores | Memory (GiB) | +| --- | --- | --- | --- | --- | +| c2-standard-4 | SSR120, SSR400, SSR440 | 4 | 4 | 16 | +| c2-standard-8 | SSR130 | 8 | 8 | 32 | +| n2-highmem-8 | SSR1200 | 8 | 8 | 64 | +| n2-highmem-16 | SSR1300 | 10 | 16 | 128 | +| n2-highmem-32 | SSR1400 | 10 | 32 | 256 | +| n2-highmem-64 | SSR1500 | 10 | 64 | 512 | + +Session Smart Router Size recommendatations can be found in [System Requirements](intro_system_reqs.md). + +:::note +Recommendations are based strictly on hardware equivalency, matching vCPU and memory specifications of physical SSR appliance models models +::: \ No newline at end of file diff --git a/docs/deploy_azure_conductor_vm.mdx b/docs/deploy_azure_conductor_vm.mdx index 8a20d77ff3d..3fd132eace6 100644 --- a/docs/deploy_azure_conductor_vm.mdx +++ b/docs/deploy_azure_conductor_vm.mdx @@ -3,6 +3,7 @@ title: "Step 1: Create the Azure Conductor VM" sidebar_label: "Create the Conductor VM" --- import NetworkDesign from './_deploy_azure_conductor_network_design.md'; +import InstanceSizing from './_byol_azure_instance_types.md' This step deploys the BYOL Session Smart Conductor VM from the Azure Marketplace, using the Azure Marketplace Web Interface. 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 automatically initializes the node as a conductor. @@ -23,16 +24,7 @@ The following infrastructure must exist in your Azure subscription before deploy ## 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 diff --git a/docs/deploy_azure_hub_spoke_overview.mdx b/docs/deploy_azure_hub_spoke_overview.mdx index 1ed950714fb..8bd51f8bca3 100644 --- a/docs/deploy_azure_hub_spoke_overview.mdx +++ b/docs/deploy_azure_hub_spoke_overview.mdx @@ -97,5 +97,5 @@ The router software version must be lower than or equal to the conductor softwar - [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) +- [Installing a BYOL Conductor-managed Router in Azure](intro_installation_byol_azure_conductor.mdx) - [System Requirements](intro_system_reqs.md) diff --git a/docs/intro_installation_aws.md b/docs/intro_installation_aws.md index cc554841927..ed334a3076d 100644 --- a/docs/intro_installation_aws.md +++ b/docs/intro_installation_aws.md @@ -8,7 +8,7 @@ Juniper recommends **BYOL (Bring Your Own License)** for both new installations Existing PAYG deployments remain fully supported — no immediate action required. -To review the BYOL deployment procedure, see [Installing a BYOL Conductor-managed Router in AWS](intro_installation_byol_aws_conductor.md). +To review the BYOL deployment procedure, see [Installing a BYOL Conductor-managed Router in AWS](intro_installation_byol_aws_conductor.mdx). ::: Partnering with Amazon, you can install an SSR Conductor and a Session Smart Router (SSR) using Amazon Web Services (AWS). AWS is a secure cloud platform that offers computing power, data storage, content delivery, flexibility, scalability, and reliability for software products. diff --git a/docs/intro_installation_azure.md b/docs/intro_installation_azure.md index b48b81c7349..9d5e679ccd1 100644 --- a/docs/intro_installation_azure.md +++ b/docs/intro_installation_azure.md @@ -10,7 +10,7 @@ Juniper recommends **BYOL (Bring Your Own License)** for both new installations Existing PAYG deployments remain fully supported — no immediate action required. -To review the BYOL deployment procedure, see [Installing a BYOL Conductor-managed Router in Azure](intro_installation_byol_azure_conductor.md). +To review the BYOL deployment procedure, see [Installing a BYOL Conductor-managed Router in Azure](intro_installation_byol_azure_conductor.mdx). ::: diff --git a/docs/intro_installation_azure_mist.md b/docs/intro_installation_azure_mist.md index b525500fe8a..91695d4365b 100644 --- a/docs/intro_installation_azure_mist.md +++ b/docs/intro_installation_azure_mist.md @@ -10,7 +10,7 @@ Juniper recommends **BYOL (Bring Your Own License)** for both new installations Existing PAYG deployments remain fully supported — no immediate action required. -To review the BYOL deployment procedure, see [Installing a BYOL Mist-managed Router in Azure](intro_installation_byol_azure_mist.md). +To review the BYOL deployment procedure, see [Installing a BYOL Mist-managed Router in Azure](intro_installation_byol_azure_mist.mdx). ::: This guide describes the process for deploying a PAYG (Pay As You Go) Mist-managed Session Smart Router (SSR) in Azure. When installed as an Azure image, SSR Version 6.x supports Mist-managed routers. The process consists of the following steps: diff --git a/docs/intro_installation_byol_aws_conductor.md b/docs/intro_installation_byol_aws_conductor.mdx similarity index 93% rename from docs/intro_installation_byol_aws_conductor.md rename to docs/intro_installation_byol_aws_conductor.mdx index 4de6d669f2d..45c1c664b88 100644 --- a/docs/intro_installation_byol_aws_conductor.md +++ b/docs/intro_installation_byol_aws_conductor.mdx @@ -2,6 +2,9 @@ title: Installing a BYOL Conductor-managed Router in AWS sidebar_label: Installing a BYOL Conductor-managed Router in AWS --- + +import InstanceSizing from './_byol_aws_instance_types.md' + This guide describes the process for deploying a BYOL Session Smart Conductor and a BYOL Session Smart Router (SSR) in AWS. The installation and deployment process consists of the following steps: @@ -18,24 +21,13 @@ BYOL instances only support image-based installations, and require the conductor ### Selecting the AMI -The **Bring Your Own License (BYOL)** AMI allows you to install your own licensed copy of the SSR software on an AWS VM. Artifactory credentials are required to authenticate access to the installation repositories. Refer to the [Session Smart Networking Platform (BYOL)](https://aws.amazon.com/marketplace/pp/prodview-lz6cjd43qgw3c?sr=0-2&ref_=beagle&applicationId=AWSMPContessa) offering. +The **Bring Your Own License (BYOL)** AMI allows you to install your own licensed copy of the SSR software on an AWS VM. SSR software access credentials are required to authenticate access to the installation repositories. Refer to the [Session Smart Networking Platform (BYOL)](https://aws.amazon.com/marketplace/pp/prodview-lz6cjd43qgw3c?sr=0-2&ref_=beagle&applicationId=AWSMPContessa) offering. Once you have selected the AMI for your deployment, proceed to the section [Session Smart Conductor Deployment](#session-smart-conductor-deployment) to deploy a Session Smart Conductor, or proceed to the section [Session Smart Conductor Managed Router Deployment](#session-smart-conductor-managed-router-deployment) to deploy a Session Smart Conductor Managed Router. ## Selecting the Instance Size -The following instance sizes are supported for virtual SSR in AWS. Choose the size that best meets your requirements. More information can be found in the [AWS Documentation](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-types.html) - -| Recommended AWS VM Size | Max vNICs Supported | vCPU Cores | Memory | -| ----------------------- | ------------------- | ---------- | ------ | -| c5.xlarge | 4 | 4 | 8 | -| c5.2xlarge | 4 | 8 | 16 | -| c5.4xlarge | 8 | 16 | 32 | -| c5.9xlarge | 8 | 36 | 72 | -| c5n.xlarge | 4 | 4 | 10.5 | -| c5n.2xlarge | 4 | 8 | 21 | -| c5n.4xlarge | 8 | 16 | 42 | -| c5n.9xlarge | 8 | 36 | 96 | + ## Session Smart Conductor Deployment @@ -81,7 +73,7 @@ To deploy the Session Smart Networking software via the AWS Console: - What name do you want to give the instance? - Provide it in the **Conductor Name** field (for example: conductor). - What version of SSR software do you want to install? -- What are the artifactory credentials used to install the software? +- What are the SSR software access credentials used to install the software? - Where do you want to deploy it? - Select the VPC in the region. - Select the subnet within the VPC. @@ -123,8 +115,8 @@ write_files: "name": "", "ssr-version": "", "mode": "conductor", - "artifactory-user": "", - "artifactory-password": "", + "software-access-username": "", + "software-access-token": "", "node-name": "node0", "cloud-provider": "aws" } @@ -134,8 +126,8 @@ write_files: | ------ | ------- | | name | The name of the router. By default, the instance name is used. | | ssr-version | The SSR software version to be installed on the instance. (BYOL only) | -| artifactory-user | User portion of the artifactory credentials. | -| artifactory-password | Password portion of the artifactory credentials. | +| software-access-username | User portion of the SSR software access credentials. | +| software-access-token | Password portion of the SSR software access credentials. | | node-name | The name of the node being provisioned. For a standalone conductor, this is `node0`. | | download-timeout | The timeout duration for installing BYOL (default: 6h) | | download-retries | The number of times to retry SSR installation (default: unlimited) | @@ -164,8 +156,8 @@ A description of the parameters of the template are listed in the following tabl | Name | The Instance Name field provides a name to the VM for the device.| | Instance Type | Size of the EC2 instance.| | SSR Version | SSR software version installed on the instance. | -| Artifactory Username | User portion of the artifactory credentials used to install the SSR software. | -| Artifactory Token | Token for the artifactory credentials used to install the SSR software. | +| SSR Software Access Username | User portion of the SSR software access credentials used to install the SSR software. | +| SSR Software Access Username | Token for the SSR software access credentials used to install the SSR software. | | VPC ID | ID of the existing VPC where the device is going to be deployed. | | Control Subnet ID | ID of the control subnet within the VPC. | | Control Subnet Allowed CIDR | The IP CIDR range of the endpoints allowed to originate traffic to the Conductor's management interface in the management subnet. | @@ -210,8 +202,8 @@ Paste the following JSON content. Please adjust the values to your specific envi "Name": "", "Version": "", "InstanceType": "c5n.xlarge", - "ArtifactoryUsername": "", - "ArtifactoryUsername": "", + "SSRSoftwareAccessUsername": "", + "SSRSoftwareAccessToken": "", "VpcId": "", "ControlSubnet": "", "ControlAllowedCidr": "0.0.0.0/0", @@ -333,7 +325,7 @@ To deploy the Session Smart Networking software via the AWS Console: - Where do you want to deploy it? - Select the VPC in the region. - Select the public, private, and optional management subnets within the VPC. -- What are the artifactory credentials used to install the software? +- What are the SSR software access credentials used to install the software? - What is the control IP address of the Conductor used to manage it? - **Optional** What is the secondary control IP address of the Conductor used to manage it? - Who is going to be the administrator? @@ -382,8 +374,8 @@ write_files: | ------ | ------- | | name | The name of the Router. | | ssr-version | The SSR software version to be installed on the instance. | -| artifactory-user | User portion of the artifactory credentials. | -| artifactory-password | Password portion of the artifactory credentials. | +| software-access-username | Username portion of the SSR software access credentials. | +| software-access-token | Token portion of the SSR software access credentials. | | conductor-hosts | The list of Conductor control IPs used to manage the router. | | download-timeout | The timeout duration for installing BYOL (default: 6h) | | download-retries | The number of times to retry SSR installation (default: unlimited) | @@ -428,8 +420,8 @@ A description of the parameters of the template are listed in the following tabl | -------------------- | ----------- | | Name | Fill out the Instance Name field to provide a name to the VM for the conductor-managed router.| | Version | SSR software version installed on the instance. | -| Artifactory Username | User portion of the artifactory credentials used to install the SSR software. | -| Artifactory Token | Token for the artifactory credentials used to install the SSR software. | +| SSR Software Access Username | Username portion of the SSR software access credentials used to install the SSR software. | +| SSR Software Access Token | Token for the SSR software access credentials used to install the SSR software. | | Primary Control IP | The primary IP address of the Conductor | | Secondary Control IP | The secondary IP address of the Conductor | | Key Name | IAM user key (SSH public key) to login to the EC2 instance (Linux) via SSH.| @@ -479,8 +471,8 @@ Paste the following JSON content. Please adjust the values to your specific envi { "Name": "", "Version": "", - "ArtifactoryUsername": "", - "ArtifactoryToken": "", + "SSRSoftwareAccessUsername": "", + "SSRSoftwareAccessToken": "", "conductorPrimaryControlIP": "", "conductorSecondaryControlIP": "", "InstanceType": "c5n.xlarge", @@ -573,8 +565,8 @@ A description of the parameters of the template are listed in the following tabl | -------------------- | ----------- | | Name | Fill out the Instance Name field to provide a name to the VM for the conductor-managed router.| | Version | SSR software version installed on the instance. | -| Artifactory Username | User portion of the artifactory credentials used to install the SSR software. | -| Artifactory Token | Token for the artifactory credentials used to install the SSR software. | +| SSR Software Access Username | Username portion of the SSR software access credentials used to install the SSR software. | +| SSR Software Access Token | Token for the SSR software access credentials used to install the SSR software. | | Primary Control IP | The primary IP address of the Conductor | | Secondary Control IP | The secondary IP address of the Conductor | | Key Name | IAM user key (SSH public key) to login to the EC2 instance (Linux) via SSH.| diff --git a/docs/intro_installation_byol_aws_mist.md b/docs/intro_installation_byol_aws_mist.mdx similarity index 97% rename from docs/intro_installation_byol_aws_mist.md rename to docs/intro_installation_byol_aws_mist.mdx index cb0897d4768..87d736e549e 100644 --- a/docs/intro_installation_byol_aws_mist.md +++ b/docs/intro_installation_byol_aws_mist.mdx @@ -2,6 +2,10 @@ title: Installing a BYOL Mist-managed Router in AWS sidebar_label: Installing a BYOL Mist-managed Router in AWS --- + +import InstanceSizing from './_byol_aws_instance_types.md' + + This guide describes the process for deploying a Mist-managed instance through AWS. When installed as an AWS image, SSR Version 6.x supports Mist-managed routers. The installation and deployment process consists of the following steps: * [Selecting the AMI](#selecting-the-ami). @@ -18,19 +22,8 @@ For the latest information about SSR BYOL offerings, please refer to the [Cloud Once you have selected the AMI that suits the needs of your deployment, proceed to the [Session Smart Router Deployment](#session-smart-router-deployment) to deploy a Session Smart Router. ## Selecting the Instance Size -The following instance sizes are supported for virtual SSR in AWS. Choose the size that best meets your requirements. More information can be found in the [AWS Documentation](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-types.html) - -| Recommended AWS VM Size | Max vNICs Supported | vCPU Cores | Memory | -| ----------------------- | ------------------- | ---------- | ------ | -| c5.xlarge | 4 | 4 | 8 | -| c5.2xlarge | 4 | 8 | 16 | -| c5.4xlarge | 8 | 16 | 32 | -| c5.9xlarge | 8 | 36 | 72 | -| c5n.xlarge | 4 | 4 | 10.5 | -| c5n.2xlarge | 4 | 8 | 21 | -| c5n.4xlarge | 8 | 16 | 42 | -| c5n.9xlarge | 8 | 36 | 96 | + ## Session Smart Router Deployment diff --git a/docs/intro_installation_byol_azure_conductor.md b/docs/intro_installation_byol_azure_conductor.mdx similarity index 93% rename from docs/intro_installation_byol_azure_conductor.md rename to docs/intro_installation_byol_azure_conductor.mdx index eb27ce4327e..ed7dc2ef81b 100644 --- a/docs/intro_installation_byol_azure_conductor.md +++ b/docs/intro_installation_byol_azure_conductor.mdx @@ -3,6 +3,7 @@ title: Installing a BYOL Conductor-managed Router in Azure sidebar_label: Installing a BYOL Conductor-managed Router in Azure --- import useBaseUrl from '@docusaurus/useBaseUrl'; +import InstanceSizing from './_byol_azure_instance_types.md' This guide describes the process for deploying a Conductor-managed Session Smart Router (SSR) in Azure using your own license. The process consists of the following steps: @@ -16,21 +17,14 @@ BYOL instances only support image-based installations, and require the conductor ## Selecting the Azure Plan -The **Bring Your Own License (BYOL)** plan allows you to install your own licensed copy of the SSR software on an Azure VM. Artifactory credentials are required to authenticate access to the installation repositories. Select the BYOL plan of the [Session Smart Networking Platform](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/juniper-networks.session-smart-networking-payg?tab=Overview) offering. +The **Bring Your Own License (BYOL)** plan allows you to install your own licensed copy of the SSR software on an Azure VM. SSR software access credentials are required to authenticate access to the installation repositories. Select the BYOL plan of the [Session Smart Networking Platform](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/juniper-networks.session-smart-networking-payg?tab=Overview) offering. Once you have selected the BYOL plan for your deployment, proceed to [Session Smart Conductor Deployment](#session-smart-conductor-deployment) to deploy a Session Smart Conductor, or proceed to the section [Session Smart Conductor-managed Router Deployment](#session-smart-conductor-managed-router-deployment) to deploy a Session Smart Router. ## Selecting the Instance Size -The following instance types are supported for virtual SSR in Azure. Choose the size that best meets your requirements. More information can be found in the [Azure Documentation](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes). - -| Recommended Azure VM Size | Max vNICs Supported | 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 | + ## Session Smart Conductor Deployment @@ -89,7 +83,7 @@ To deploy the Session Smart Networking software via the Azure Portal: - Provide the name of the VNet in the **Virtual Network Name** field (for example: `128T-VNet`). - Provide the name of the availability set in the **Availability Set Name** field (for example: `128TSet`). - Provide the name of the **Management Subnet** -- What are the artifactory credentials used to install the software? +- What are the SSR software access credentials used to install the software? - Who is going to be the administrator? - Provide the content of your public SSH key in the `Admin Public Key Data` field. @@ -139,8 +133,8 @@ write_files: "name": "", "ssr-version": "", "mode": "conductor", - "artifactory-user": "", - "artifactory-password": "", + "software-access-username": "", + "software-access-token": "", "node-name": "node0", "cloud-provider": "azure" } @@ -150,8 +144,8 @@ write_files: | ------ | ------- | | name | The name of the router. | | ssr-version | The SSR software version to be installed on the instance. (BYOL only) | -| artifactory-user | User portion of the artifactory credentials. | -| artifactory-password | Password portion of the artifactory credentials. | +| software-access-username | User portion of the SSR software access credentials. | +| software-access-token | Password portion of the SSR software access credentials. | | node-name | The name of the node being provisioned. For a standalone conductor, this is `node0`. | | download-timeout | The timeout duration for installing BYOL (default: 6h) | | download-retries | The number of times to retry SSR installation (default: unlimited) | @@ -184,8 +178,8 @@ A description of the parameters of the template are listed in the following tabl | Instance Size | Select the size of the VM in the field Instance Size. | | Instance Name | Provide a name to the VM for the Session Smart Conductor. | | SSR Version | SSR software version installed on the instance. | -| Artifactory Username | User portion of the artifactory credentials used to install the SSR software. | -| Artifactory Token | Token for the artifactory credentials used to install the SSR software. | +| SSR Software Access Username | Username portion of the SSR software access credentials used to install the SSR software. | +| SSR Software Access Token | Token for the SSR software access credentials used to install the SSR software. | | Managed Identity | The Azure Managed identity used to manage permissions for the router instance. | | Virtual Network Name | Name of the existing VNet where the Session Smart Router is going to be deployed. | | Control Subnet Name | The name of the management subnet within the VNet. | @@ -252,11 +246,11 @@ Paste the following JSON content. Please adjust the values to your specific envi "SSR Version": { "value": "" }, - "artifactoryUsername": { - "value": "The username portion of the artifactory credentials" + "SSR Software Access Username": { + "value": "The username portion of the SSR software access credentials" }, - "artifactoryToken": { - "value": "The password portion of the artifactory credentials" + "SSR Software Access Token": { + "value": "The token portion of the SSR software access credentials" }, "managedIdentity": { "value": "" @@ -368,7 +362,7 @@ To deploy the Session Smart Networking software via the Azure Portal: - What name do you want to give it? - Provide it in the **Instance Name** field (for example: Router). - What version of SSR software do you want to install? -- What are the artifactory credentials used to install the software? +- What are the SSR software access credentials used to install the software? - Provide the name of the VNet in the **Virtual Network Name** field (for example: `128T-VNet`). - Provide the name of the **Public Subnet Name** - Provide the name of the **Private Subnet Name** @@ -428,8 +422,8 @@ write_files: "ssr-version": "", “mode”: "conductor-managed", “conductor-hosts”: [""], - "artifactory-user": "", - "artifactory-password": "", + "software-access-username": "", + "software-access-token": "", "cloud-provider": "azure" } ``` @@ -437,8 +431,8 @@ write_files: | ------ | ------- | | name | The name of the Router. | | ssr-version | The SSR software version to be installed on the instance. (BYOL only) | -| artifactory-user | User portion of the artifactory credentials. | -| artifactory-password | Password portion of the artifactory credentials. | +| software-access-username | Username portion of the SSR software access credentials. | +| software-access-token | Token portion of the SSR software access credentials. | | conductor-hosts | The list of Conductor control IPs used to manage the router. | | download-timeout | The timeout duration for installing BYOL (default: 6h) | | download-retries | The number of times to retry SSR installation (default: unlimited) | @@ -471,8 +465,8 @@ A description of the parameters of the template are listed in the following tabl | SSR Version | SSR software version installed on the instance. | | Primary Control IP | The primary IP address of the Conductor | | Secondary Control IP | The secondary IP address of the Conductor | -| Artifactory Username | User portion of the artifactory credentials used to install the SSR software. | -| Artifactory Token | Token for the artifactory credentials used to install the SSR software. | +| SSR Software Access Username | User portion of the SSR software access credentials used to install the SSR software. | +| SSR Software Access Token | Token for the SSR software access credentials used to install the SSR software. | | Virtual Network Name | Name of the existing VNet where the Session Smart Router is going to be deployed. | | Public Subnet Name | The name of the public subnet within the VNet. | | Public Subnet Allowed CIDR | Corresponds to the source IP CIDR range of the SSR/s at the data center/branch (outside the cloud) allowed to originate traffic to the public interface of the router. This field allows for defining a well defined and trusted IP address range. It is common to set this field to 0.0.0.0/0 for now, as the source IP addresses of the routers at the data center or branch (outside the cloud) are not known at this time. However, after the deployment and once these external IP addresses are known it is recommended to provision them in the corresponding security groups to increase the degree of security. | @@ -546,11 +540,11 @@ Paste the following JSON content. Please adjust the values to your specific envi "conductorSecondaryControlIP": { "value" "The Secondary Control IP of the Conductor", }, - "artifactoryUsername": { - "value": "The username portion of the artifactory credentials" + "SSR Software Access Username": { + "value": "The username portion of the SSR software access credentials" }, - "artifactoryToken": { - "value": "The password portion of the artifactory credentials" + "SSR Software Access Token": { + "value": "The password portion of the SSR software access credentials" }, "managedIdentity": { "value": "Name of the user managed identity resource to be assigned to the Router." diff --git a/docs/intro_installation_byol_azure_mist.md b/docs/intro_installation_byol_azure_mist.mdx similarity index 97% rename from docs/intro_installation_byol_azure_mist.md rename to docs/intro_installation_byol_azure_mist.mdx index 3c3f534cb67..6d1740b1b6b 100644 --- a/docs/intro_installation_byol_azure_mist.md +++ b/docs/intro_installation_byol_azure_mist.mdx @@ -3,6 +3,7 @@ title: Installing a BYOL Mist-managed Router in Azure sidebar_label: Installing a BYOL Mist-managed Router in Azure --- import useBaseUrl from '@docusaurus/useBaseUrl'; +import InstanceSizing from './_byol_azure_instance_types.md' This guide describes the process for deploying a Mist-managed Session Smart Router (SSR) in Azure using your own license. When installed as an Azure image, SSR Version 6.x supports Mist-managed routers. The process consists of the following steps: @@ -19,14 +20,7 @@ Once you have selected the plan that best suits the needs of your deployment, pr ## Selecting the Instance Size -The following instance types are supported for virtual SSR in Azure. Choose the size that best meets your requirements. More information can be found in the [Azure Documentation](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes). - -| Recommended Azure VM Size | Max vNICs Supported | 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 | + ## Session Smart Router diff --git a/docs/intro_installation_byol_gcp_conductor.md b/docs/intro_installation_byol_gcp_conductor.mdx similarity index 90% rename from docs/intro_installation_byol_gcp_conductor.md rename to docs/intro_installation_byol_gcp_conductor.mdx index 35d4abadbdd..e9e426a4f64 100644 --- a/docs/intro_installation_byol_gcp_conductor.md +++ b/docs/intro_installation_byol_gcp_conductor.mdx @@ -2,6 +2,7 @@ title: Installing a BYOL Conductor-managed Router in GCP sidebar_label: Installing a BYOL Conductor-managed Router in GCP --- +import InstanceSizing from './_byol_gcp_instance_types.md' This guide describes the process for deploying a BYOL Session Smart Conductor and a BYOL Session Smart Router (SSR) in Google Cloud Platform (GCP). @@ -17,7 +18,7 @@ BYOL instances only support image-based installations, and require the conductor ## Selecting the GCP Plan -The **Bring Your Own License (BYOL)** plan allows you to install your own licensed copy of SSR software on a GCP virtual machine. Artifactory credentials are required to authenticate access to the BYOL installation repositories. +The **Bring Your Own License (BYOL)** plan allows you to install your own licensed copy of SSR software on a GCP virtual machine. SSR software access credentials are required to authenticate access to the BYOL installation repositories. For the latest information about SSR BYOL offerings, refer to the [Cloud Images BYOL Release Notes](release_notes_byol.md). @@ -25,16 +26,7 @@ After selecting the BYOL plan, continue to [Session Smart Conductor Deployment]( ## Selecting the Instance Size -The following instance types are supported for virtual SSR in GCP. Choose the size that best meets your requirements. More information on GCP instance types can be found in the [GCP machine type documentation](https://docs.cloud.google.com/compute/docs/compute-optimized-machines#c2_machine_types). - -| Recommended VM Size | Max vNICs Supported | vCPU Cores | Memory | -| --- | --- | --- | --- | -| c2-standard-4 | 4 | 4 | 16 GB | -| c2-standard-8 | 8 | 8 | 32 GB | -| c2-standard-16 | 10 | 16 | 64 GB | -| c2-standard-30 | 10 | 30 | 120 GB | - -Session Smart Router Size recommendatations can be found in [System Requirements](intro_system_reqs.md). + ## Session Smart Conductor Deployment @@ -72,8 +64,8 @@ To deploy the Session Smart Networking software through Google Cloud Marketplace 4. In SSR mode, select **Conductor**. 5. Provide the BYOL software inputs: * SSR software version - * Artifactory username - * Artifactory token/password + * SSR software access username + * SSR software access token/password 6. Provide administrative access settings: * Allowed CIDR(s) for SSH/HTTPS access * SSH public key @@ -108,8 +100,8 @@ In the downloaded package, create a Terraform variables file named `ssr-variable ssr_mode = "conductor" ssr_version = "7.0.1" -artifactory_username = "username" -artifactory_token = "password" +ssr_software_access_username = "username" +ssr_software_access_token = "password" ssh_public_key = "ssh key" admin_allowed_cidr = "cidr" @@ -140,8 +132,8 @@ write_files: "name": "", "ssr-version": "", "mode": "conductor", - "artifactory-user": "", - "artifactory-password": "", + "software-access-username": "", + "software-access-token": "", "node-name": "node0", "cloud-provider": "gcp" } @@ -151,8 +143,8 @@ write_files: | --- | --- | | name | The name of the conductor/router. | | ssr-version | The SSR software version to be installed on the instance (BYOL only). | -| artifactory-user | Username portion of the artifactory credentials. | -| artifactory-password | Password/token portion of the artifactory credentials. | +| software-access-username | Username portion of the SSR software access credentials. | +| software-access-token | Password/token portion of the SSR software access credentials. | | node-name | The node name being provisioned. For a standalone conductor, use `node0`. | | download-timeout | The timeout duration for installing BYOL (default: 6h) | | download-retries | The number of times to retry SSR installation (default: unlimited) | @@ -181,8 +173,8 @@ The following are the common deployment parameters for a BYOL Conductor in GCP. | Boot Disk Size | boot_disk_size | Boot disk size in GB. Minimum 60 GB is recommended. | | SSR Mode | ssr_mode | Set to `conductor` for a Conductor deployment. | | SSR Version | ssr_version | SSR software version installed. | -| Artifactory Username | artifactory_username | Username for BYOL repository access. | -| Artifactory Token | artifactory_token | Token/password for BYOL repository access. | +| SSR Software Access Username | ssr_software_access_username | Username for BYOL repository access. | +| SSR Software Access Token | ssr_software_access_token | Token/password for BYOL repository access. | | Admin Allowed CIDR | admin_allowed_cidr | Source CIDR allowed for SSH and HTTPS administration. | | SSH Public Key | ssh_public_key | Public SSH key added for administrator access. | | Control Allowed CIDR | control_nic_allowed_cidr | Source CIDR allowed to reach the Conductor control interface. | @@ -228,8 +220,8 @@ At deployment time: 4. In SSR mode, select **Conductor-managed**. 5. Provide the BYOL software inputs: * SSR software version - * Artifactory username - * Artifactory token/password + * SSR software access username + * SSR software access token/password 6. Specify whether the router is High Availability (HA). 7. Provide administrative access settings: * Allowed CIDR(s) for SSH/HTTPS access @@ -271,8 +263,8 @@ In the downloaded package, create a Terraform variables file named `ssr-variable ssr_mode = "conductor-managed" ssr_version = "7.0.1" -artifactory_username = "username" -artifactory_token = "password" +ssr_software_access_username = "username" +ssr_software_access_token = "password" conductor_hosts = [""] ssh_public_key = "ssh key" admin_allowed_cidr = "cidr" @@ -315,8 +307,8 @@ write_files: "name": "", "ssr-version": "", "mode": "conductor-managed", - "artifactory-user": "", - "artifactory-password": "", + "software-access-username": "", + "software-access-token": "", "conductor-hosts": [""], "cloud-provider": "gcp" } @@ -327,8 +319,8 @@ write_files: | name | The name of the router instance. | | ssr-version | The SSR software version to be installed on the instance (BYOL only). | | mode | Set to `conductor-managed` for a Conductor-managed router. | -| artifactory-user | Username portion of the artifactory credentials. | -| artifactory-password | Password/token portion of the artifactory credentials. | +| software-access-username | Username portion of the SSR software access credentials. | +| software-access-token | Password/token portion of the SSR software access credentials. | | conductor-hosts | One or more IP addresses (or FQDNs) of reachable Conductor control interfaces. | | download-timeout | The timeout duration for installing BYOL (default: 6h) | | download-retries | The number of times to retry SSR installation (default: unlimited) | @@ -356,8 +348,8 @@ The following are the common deployment parameters for a BYOL Conductor-managed | SSR Mode | ssr_mode | Set to conductor-managed for this workflow. | | SSR Version | ssr_version | SSR software version installed. | | HA Router | ha_router | Enables HA-specific interfaces and HA onboarding behavior. | -| Artifactory Username | artifactory_username | Username for SSR repository access. | -| Artifactory Token | artifactory_token | Token/password for SSR repository access. | +| SSR Software Access Username | ssr_software_access_username | Username for SSR repository access. | +| SSR Software Access Token | ssr_software_access_token | Token/password for SSR repository access. | | Admin Allowed CIDR | admin_allowed_cidr | Source CIDR allowed for SSH and HTTPS administration. | | SSH Public Key | ssh_public_key | Public SSH key added for administrator access. | | Conductor Hosts | conductor_hosts | One or more reachable Conductor control IP addresses for onboarding. | diff --git a/docs/intro_installation_byol_gcp_mist.md b/docs/intro_installation_byol_gcp_mist.mdx similarity index 95% rename from docs/intro_installation_byol_gcp_mist.md rename to docs/intro_installation_byol_gcp_mist.mdx index 348ed55e90b..d8cdcda7b1d 100644 --- a/docs/intro_installation_byol_gcp_mist.md +++ b/docs/intro_installation_byol_gcp_mist.mdx @@ -2,6 +2,7 @@ title: Installing a BYOL Mist-managed Router in GCP sidebar_label: Installing a BYOL Mist-managed Router in GCP --- +import InstanceSizing from './_byol_gcp_instance_types.md' This guide describes the process for deploying a Mist-managed Session Smart Router (SSR) in GCP using your own license. The process consists of the following steps: @@ -16,16 +17,7 @@ For the latest information about SSR BYOL offerings, refer to the [Cloud Images ## Selecting the Instance Size -The following instance types are supported for virtual SSR in GCP. Choose the size that best meets your requirements. More information on GCP instance types can be found in the [GCP Documentation](https://docs.cloud.google.com/compute/docs/compute-optimized-machines#c2_machine_types). - -| Recommended VM Size | Max vNICs Supported | vCPU Cores | Memory | -| --- | --- | --- | --- | -| c2-standard-4 | 4 | 4 | 16 GB | -| c2-standard-8 | 8 | 8 | 32 GB | -| c2-standard-16 | 10 | 16 | 64 GB | -| c2-standard-30 | 10 | 30 | 120 GB | - -Session Smart Router Size recommendatations can be found in [System Requirements](intro_system_reqs.md). + ## Session Smart Router diff --git a/docs/intro_installation_quickstart_aws.md b/docs/intro_installation_quickstart_aws.md index 3a38d0a59f5..167fb81460a 100644 --- a/docs/intro_installation_quickstart_aws.md +++ b/docs/intro_installation_quickstart_aws.md @@ -8,7 +8,7 @@ Juniper recommends **BYOL (Bring Your Own License)** for both new installations Existing PAYG deployments remain fully supported — no immediate action required. -To review the BYOL deployment procedure, see [Installing a BYOL Conductor-managed Router in AWS](intro_installation_byol_aws_conductor.md). +To review the BYOL deployment procedure, see [Installing a BYOL Conductor-managed Router in AWS](intro_installation_byol_aws_conductor.mdx). ::: ## Introduction diff --git a/docs/intro_installation_quickstart_mist_aws.md b/docs/intro_installation_quickstart_mist_aws.md index 8181575828f..8dde776d818 100644 --- a/docs/intro_installation_quickstart_mist_aws.md +++ b/docs/intro_installation_quickstart_mist_aws.md @@ -8,7 +8,7 @@ Juniper recommends **BYOL (Bring Your Own License)** for both new installations Existing PAYG deployments remain fully supported — no immediate action required. -To review the BYOL deployment procedure, see [Installing a BYOL Mist-managed Router in AWS](intro_installation_byol_aws_mist.md). +To review the BYOL deployment procedure, see [Installing a BYOL Mist-managed Router in AWS](intro_installation_byol_aws_mist.mdx). ::: This guide describes the process for deploying a PAYG (Pay As You Go) Mist-managed instance through AWS. When installed as an AWS image, SSR Version 6.x supports Mist-managed routers. The installation and deployment process consists of the following steps: diff --git a/docs/release_notes_128t_6.3.md b/docs/release_notes_128t_6.3.md index b1ec99f85df..1be1dc2b339 100644 --- a/docs/release_notes_128t_6.3.md +++ b/docs/release_notes_128t_6.3.md @@ -28,7 +28,7 @@ Before upgrading please review the [**Upgrade Considerations**](intro_upgrade_co As mentioned above, during the upgrade to 6.3, existing systems will go through a conversion process to support image-based delivery. This process involves resizing the existing disk partition to support writing a new disk image to the remaining disk space. As such, the usable disk space seen after this conversion will be approximately halved. The system will automatically detect if there is not enough usable disk space on the existing drive to support this partition resizing and, if so, will trigger an upgrade failure. Even if the conversion is successful and the upgrade succeeds, users may note that the system is experiencing disk space alarms after the upgrade due to the reduction in overall capacity. It is suggested to remove unnecessary large files from systems before upgrading. Old saved tech-support-info archives (check for tar.gz or zip files in `/var/log/128technology`) and uploaded ISO images are frequent contributors to used disk space and should be manually deleted. -In certain scenarios, existing cloud routers may have been installed from images that did not use LVM for partitions. For these systems, the automatic resizing of disk partitions will fail and they cannot be upgraded. It is suggested to rebuild these instances from the official [SSR BYOL](intro_installation_byol_aws_conductor.md) image. +In certain scenarios, existing cloud routers may have been installed from images that did not use LVM for partitions. For these systems, the automatic resizing of disk partitions will fail and they cannot be upgraded. It is suggested to rebuild these instances from the official [SSR BYOL](intro_installation_byol_aws_conductor.mdx) image. When the conductor is initially upgraded to 6.3, it will be upgraded as a package-based system. This is because the system does not understand how to handle image-based delivery until it is running 6.3 software. Once the conductor is running 6.3 all router upgrades will be treated as image-based upgrades and any subsequent conductor upgrade will be treated as image-based. Therefore, it is possible that issues related to disk usage on conductor may not arise until a subsequent upgrade of the conductor beyond the initial step to 6.3. @@ -423,7 +423,7 @@ IDP is not available on the following SSR devices: SSR120, SSR400 and SSR440. ------ - **I95-47154 Conductor-management of image-based SSR devices:** Upgrading to or installing SSR 6.3.0 now supports conductor managed deployments. See [SSR Universal ISO Installation](intro_installation_univ-iso.md) for installation information, and refer to [Upgrading the Conductor](upgrade_ibu_conductor.mdx) for upgrade information. ------ -- **I95-48255 BYOL SSR images for AWS and Azure marketplaces:** New streamlined instances for AWS and Azure have been introduced. For installation and deployment information, refer to [Installing a BYOL Mist-managed Router in AWS](intro_installation_byol_aws_mist.md) and [Installing a BYOL Mist-managed Router in Azure](intro_installation_byol_azure_mist.md). +- **I95-48255 BYOL SSR images for AWS and Azure marketplaces:** New streamlined instances for AWS and Azure have been introduced. For installation and deployment information, refer to [Installing a BYOL Mist-managed Router in AWS](intro_installation_byol_aws_mist.mdx) and [Installing a BYOL Mist-managed Router in Azure](intro_installation_byol_azure_mist.mdx). ------ - **I95-50572 Unified ISO for Mist and Conductor Onboarding:** A single, image-based ISO is the preferred method of installation for all SSR deployments. This new ISO greatly simplifies the software installation process and onboarding of routers to both the Mist-managed and Conductor-managed environments. For information about the install and onboarding process, refer to [SSR Universal ISO Installation](intro_installation_univ-iso.md). ------ diff --git a/docs/release_notes_128t_7.0.md b/docs/release_notes_128t_7.0.md index 8b7179c3abe..c0e1254c285 100644 --- a/docs/release_notes_128t_7.0.md +++ b/docs/release_notes_128t_7.0.md @@ -42,7 +42,7 @@ This issue is currently being addressed by engineering. However, if your deploym As mentioned above, during the upgrade to an image-based installation, existing systems will go through a conversion process to support image-based delivery. This process involves resizing the existing disk partition to support writing a new disk image to the remaining disk space. As such, the usable disk space seen after this conversion will be approximately halved. The system will automatically detect if there is not enough usable disk space on the existing drive to support this partition resizing and, if so, will trigger an upgrade failure. Even if the conversion is successful and the upgrade succeeds, users may note that the system is experiencing disk space alarms after the upgrade due to the reduction in overall capacity. It is suggested to remove unnecessary large files from systems before upgrading. Old saved tech-support-info archives (check for tar.gz or zip files in `/var/log/128technology`) and uploaded ISO images are frequent contributors to used disk space and should be manually deleted. -In certain scenarios, existing cloud routers may have been installed from images that did not use LVM for partitions. For these systems, the automatic resizing of disk partitions will fail and they cannot be upgraded. It is suggested to rebuild these instances from the official SSR BYOL image for either [AWS](intro_installation_byol_aws_conductor.md) or [Azure](intro_installation_byol_azure_conductor.md). +In certain scenarios, existing cloud routers may have been installed from images that did not use LVM for partitions. For these systems, the automatic resizing of disk partitions will fail and they cannot be upgraded. It is suggested to rebuild these instances from the official SSR BYOL image for either [AWS](intro_installation_byol_aws_conductor.mdx) or [Azure](intro_installation_byol_azure_conductor.mdx). When the conductor is initially upgraded to an image-based installation, it will be upgraded as a package-based system. This is because the system does not understand how to handle image-based delivery until it is running 6.3 software. Once the conductor is running 6.3 all router upgrades will be treated as image-based upgrades and any subsequent conductor upgrade will be treated as image-based. Therefore, it is possible that issues related to disk usage on conductor may not arise until a subsequent upgrade of the conductor beyond the initial step to 6.3. diff --git a/docs/release_notes_128t_7.1.md b/docs/release_notes_128t_7.1.md index 3eb99372648..dc6a12691eb 100644 --- a/docs/release_notes_128t_7.1.md +++ b/docs/release_notes_128t_7.1.md @@ -44,7 +44,7 @@ This issue is currently being addressed by engineering. However, if your deploym As mentioned above, during the upgrade to an image-based installation, existing systems will go through a conversion process to support image-based delivery. This process involves resizing the existing disk partition to support writing a new disk image to the remaining disk space. As such, the usable disk space seen after this conversion will be approximately halved. The system will automatically detect if there is not enough usable disk space on the existing drive to support this partition resizing and, if so, will trigger an upgrade failure. Even if the conversion is successful and the upgrade succeeds, users may note that the system is experiencing disk space alarms after the upgrade due to the reduction in overall capacity. It is suggested to remove unnecessary large files from systems before upgrading. Old saved tech-support-info archives (check for tar.gz or zip files in `/var/log/128technology`) and uploaded ISO images are frequent contributors to used disk space and should be manually deleted. -In certain scenarios, existing cloud routers may have been installed from images that did not use LVM for partitions. For these systems, the automatic resizing of disk partitions will fail and they cannot be upgraded. It is suggested to rebuild these instances from the official SSR BYOL image for either [AWS](intro_installation_byol_aws_conductor.md) or [Azure](intro_installation_byol_azure_conductor.md). +In certain scenarios, existing cloud routers may have been installed from images that did not use LVM for partitions. For these systems, the automatic resizing of disk partitions will fail and they cannot be upgraded. It is suggested to rebuild these instances from the official SSR BYOL image for either [AWS](intro_installation_byol_aws_conductor.mdx) or [Azure](intro_installation_byol_azure_conductor.mdx). When the conductor is initially upgraded to an image-based installation, it will be upgraded as a package-based system. This is because the system does not understand how to handle image-based delivery until it is running 6.3 software. Once the conductor is running 6.3 all router upgrades will be treated as image-based upgrades and any subsequent conductor upgrade will be treated as image-based. Therefore, it is possible that issues related to disk usage on conductor may not arise until a subsequent upgrade of the conductor beyond the initial step to 6.3. diff --git a/docs/release_notes_128t_7.2.md b/docs/release_notes_128t_7.2.md index 0071730d929..f578790a90a 100644 --- a/docs/release_notes_128t_7.2.md +++ b/docs/release_notes_128t_7.2.md @@ -43,7 +43,7 @@ This issue is currently being addressed by engineering. However, if your deploym As mentioned above, during the upgrade to an image-based installation, existing systems will go through a conversion process to support image-based delivery. This process involves resizing the existing disk partition to support writing a new disk image to the remaining disk space. As such, the usable disk space seen after this conversion will be approximately halved. The system will automatically detect if there is not enough usable disk space on the existing drive to support this partition resizing and, if so, will trigger an upgrade failure. Even if the conversion is successful and the upgrade succeeds, users may note that the system is experiencing disk space alarms after the upgrade due to the reduction in overall capacity. It is suggested to remove unnecessary large files from systems before upgrading. Old saved tech-support-info archives (check for tar.gz or zip files in `/var/log/128technology`) and uploaded ISO images are frequent contributors to used disk space and should be manually deleted. -In certain scenarios, existing cloud routers may have been installed from images that did not use LVM for partitions. For these systems, the automatic resizing of disk partitions will fail and they cannot be upgraded. It is suggested to rebuild these instances from the official SSR BYOL image for either [AWS](intro_installation_byol_aws_conductor.md) or [Azure](intro_installation_byol_azure_conductor.md). +In certain scenarios, existing cloud routers may have been installed from images that did not use LVM for partitions. For these systems, the automatic resizing of disk partitions will fail and they cannot be upgraded. It is suggested to rebuild these instances from the official SSR BYOL image for either [AWS](intro_installation_byol_aws_conductor.mdx) or [Azure](intro_installation_byol_azure_conductor.mdx). When the conductor is initially upgraded to an image-based installation, it will be upgraded as a package-based system. This is because the system does not understand how to handle image-based delivery until it is running 6.3 software. Once the conductor is running 6.3 all router upgrades will be treated as image-based upgrades and any subsequent conductor upgrade will be treated as image-based. Therefore, it is possible that issues related to disk usage on conductor may not arise until a subsequent upgrade of the conductor beyond the initial step to 6.3. diff --git a/docs/release_notes_byol_5.2.md b/docs/release_notes_byol_5.2.md new file mode 100644 index 00000000000..a1b4d038c3a --- /dev/null +++ b/docs/release_notes_byol_5.2.md @@ -0,0 +1,52 @@ +--- +title: Bring Your Own License (BYOL) +sidebar_label: '5.2' +--- +## Release 5.2.0 + +**Release Date:** Oct 23, 2026 + +### New Features and Improvements +- **I95-66382 Replace artifactory keyword in AWS, Azure, GCP** +Updated the cloud templates use `SSR Software Access Username` and `SSR Software Access Token` instead of `Artifactory Username` and `Artifactory Token`. Added a similar `software-access-username` and `software-access-token` to the onboarding configuration. +Example: +``` + { + "name": "", + "ssr-version": "", + "mode": "conductor", + "software-access-username": "", + "software-access-token": "", + "node-name": "node0", + "cloud-provider": "aws" + } +``` + +- **I95-66517 Updated sizing guidelines for AWS, GCP** +Updated sizing guidelines to be in-line with SSR Hardware Platforms. Legacy sizes are still available, but new reccomended sizes are added. + +#### AWS +``` +c5n.xlarge +c5n.2xlarge +r8in.2xlarge +r8in.4xlarge +r8in.8xlarge +r8in.16xlarge +``` +#### GCP +``` +c2-standard-4 +c2-standard-8 +n2-highmem-8 +n2-highmem-16 +n2-highmem-32 +n2-highmem-64 +``` + +### Resolved Issues + + - **I95-66255 Disabling console does not work on cloud instances** + + _**Resolution:**_ Updated the console grub arguments to be supported by SSR + diff --git a/sidebars.js b/sidebars.js index b5a59d073a4..56928fbb561 100644 --- a/sidebars.js +++ b/sidebars.js @@ -75,6 +75,7 @@ module.exports = { "type": "category", "label": "BYOL Cloud Images", "items": [ + "release_notes_byol_5.2", "release_notes_byol_5.1", "release_notes_byol_5.0", "release_notes_byol_4.0", @@ -102,20 +103,20 @@ module.exports = { "type": "category", "label": "Installing In AWS", "items": [ - "intro_installation_quickstart_aws", - "intro_installation_quickstart_mist_aws", "intro_installation_byol_aws_conductor", "intro_installation_byol_aws_mist", + "intro_installation_quickstart_aws", + "intro_installation_quickstart_mist_aws", ], }, { "type": "category", "label": "Installing In Azure", "items": [ - "intro_installation_azure", - "intro_installation_azure_mist", "intro_installation_byol_azure_conductor", "intro_installation_byol_azure_mist", + "intro_installation_azure", + "intro_installation_azure_mist", ], }, { diff --git a/static/img/aws-byol-conductor-managed-template.png b/static/img/aws-byol-conductor-managed-template.png index 942d526128c..58f2d54c240 100644 Binary files a/static/img/aws-byol-conductor-managed-template.png and b/static/img/aws-byol-conductor-managed-template.png differ diff --git a/static/img/aws-byol-conductor-template.png b/static/img/aws-byol-conductor-template.png index 1047db3b6b1..17ea3093b33 100644 Binary files a/static/img/aws-byol-conductor-template.png and b/static/img/aws-byol-conductor-template.png differ diff --git a/static/img/azure-byol-conductor-managed-template.png b/static/img/azure-byol-conductor-managed-template.png index d37ea2e654f..be5aceb9359 100644 Binary files a/static/img/azure-byol-conductor-managed-template.png and b/static/img/azure-byol-conductor-managed-template.png differ diff --git a/static/img/azure-byol-conductor-template.png b/static/img/azure-byol-conductor-template.png index b55bc138bb2..4f27f1a7637 100644 Binary files a/static/img/azure-byol-conductor-template.png and b/static/img/azure-byol-conductor-template.png differ diff --git a/static/img/gcp-conductor-managed-rtr-template.png b/static/img/gcp-conductor-managed-rtr-template.png index 59686f6a8d4..9599c477789 100644 Binary files a/static/img/gcp-conductor-managed-rtr-template.png and b/static/img/gcp-conductor-managed-rtr-template.png differ diff --git a/static/img/gcp-conductor-template.png b/static/img/gcp-conductor-template.png index aad9d3d288b..5d1bcc5cc04 100644 Binary files a/static/img/gcp-conductor-template.png and b/static/img/gcp-conductor-template.png differ