Caveats

Any configurations errors will temporarily pause the CloudBlade, and an error message displayed. Once the error is corrected, the CloudBlade operations will resume. This applies to all scenarios of the CloudBlade functionality.
The CloudBlade may deploy a pair of vIONs in a given location utilizing Azure’s High Availability/Resiliency Schemes with Availability Zones and Availability Sets. However, if the location does not support multiple zones, the CloudBlade will deploy the vION pair only using Availability Set.
Transit VNET CIDR(s) Hub CIDR(s) configurations only support private address prefixes. Also, the CloudBlade reports an error if any of these prefixes overlap with each other or when the CloudBlade can detect an overlap with any application VNET(s) associated with the hub(s) configured for Brownfield deployments.
In Greenfield deployments (where the vWAN resource is not mentioned in the CloudBlade configuration), the CloudBlade creates a new Resource Group apart from the Resource Group created for the Transit VNET. The CloudBlade selects the first region mentioned in Transit Virtual Network CIDR configuration to create the other Resource Group for the vWAN resource.
To change the vWAN instance after the CloudBlade creates it in a Greenfield deployment scenario, the CloudBlade needs to be disabled. This deletes all resources created by the CloudBlade (as applicable). Then, the CloudBlade must be enabled again with the vWAN resource mentioned in the CloudBlade configuration.
For existing vHUB(s), the CloudBlade automatically determines its provisioning status, routing status, and location before deploying the Transit VNET connectivity to these vHUB(s).
If a vHUB's location cannot be determined, the CloudBlade creates a new vHUB resource in the specified region and establishes Transit VNET connectivity to the newly deployed vHUB.
If a vHUB's location is determined, but the vHUB is not fully provisioned (provisioning status or routing status has not succeeded), the CloudBlade waits until the vHUB is fully provisioned before deploying the Transit VNET and associated resources. The CloudBlade then proceeds with deployments in other specified regions.
If more than one vHUB(s) is associated with the same region, the CloudBlade considers the first vHUB resource that matches the location where the Transit VNET resources are deployed.
The CloudBlade deletes all resources created or owned when the CloudBlade is disabled or the configurations are changed.
For vWAN/vHUB instances, the CloudBlade deletes these resources only if the resources are created/owned by the CloudBlade AND there is no application/workload Hub Virtual Network Connections associated with the vHUB.
The Resource Group created for the vWAN resource is deleted if it meets the above conditions, and there are no other resources created in this Resource Group outside of what the CloudBlade has created.
Deleting vWAN/vHUB is a best-effort approach. However, there may be instances where Azure still reports unexpected errors (available in the logs and the status monitor), despite meeting all the above conditions. In such cases, these resources must be deleted manually from the Azure portal if they are no longer required.
If the vION(s) interface configurations are reset, the CloudBlade attempts to correct the same. However, if the internet interface on a vION is reset, the connectivity between vION and controller is disconnected. In such scenarios, you can recover access to the vION devices from the Azure portal through the serial console interface and reconfigure the interfaces correctly to establish controller connectivity. However, this scenario may also result in BGP peer(s) configured on the vION(s) to show as disconnected. To resolve this issue, you must reset the peer from the controller UI whenever necessary.