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.
