Commander provides the ability to deploy vCenter services to isolated networks where IP and MAC address conflicts are not possible, called fenced networks. To do so, a virtual router is deployed with the VMs or virtual services when you define a service as fenced. The deployment of the vRouter is handled entirely by Commander, so you don't have to import the template or take any other action outside Commander to make it available for use.
The cost of the vRouter isn't presented to users requesting a service which requires one, as the vRouter is an operational cost associated with offering the service. If you need to apply a cost for fencing that users can see, or a cost that will be applied to their quota, use a custom attribute assigned an appropriate cost on the fenced service.
The vRouter is named automatically by Commander using the following convention:
vRouter_R[Request Number]_[Switch Type: (D|S)]_V[vLAN Number]
so that you can tell from its name that a vRouter called vRouter_R18_D_V205 was created with service request 18 and uses a distributed switch with vLAN 205. Summary details for each fenced VM optionally display the name of the vRouter isolating it from the rest of your network.
When viewing fenced services in Commander, the terms external and internal are used to refer to the IP addresses of fenced VMs. The external address is the IP address used to contact the VM from outside the fence, and is known to the router and not the VM itself. The internal address is the IP address actually assigned to the VM's interface, accessible by other VMs inside the fence. When viewing fenced services in the Service Portal, the term Public is used instead of external IP address and Private is used instead of internal.
The external address of the router is assigned by an IP Pool you have created for use with fencing or by a DHCP server available on the external network. This isn't user-configurable, so Service Portal users are not required to have any knowledge of the networking involved in order to request and have functional fenced networks provisioned transparently.
The private IP addresses for VMs inside the fence can be assigned statically, dynamically, or both. Each network interface for each component of the service is independently configurable.
The public addresses for the components inside a fence all come from IP pools, even if the router gets its address from DHCP.
To assign the IPs statically, you provide the IP address the service will use. When dynamic addressing can be used, the VMs will receive their addresses from a DHCP server on the router, which means the service's templates must be DHCP ready.
Each service that employs network fencing requires a dedicated vLAN. Both standard and distributed switches are compatible with network fencing.
You can further configure the fence to allow communications in multiple supported configurations. Each network interface for each component of the service is independently configurable with an access mode that defines the default firewall rules that apply. The access modes are:
- Out only: No inbound connections are permitted on any port, but outbound connections are allowed on all ports.
- In and Out: All inbound and outbound connections are permitted on all ports.
- In only: All inbound connections are permitted on all ports, but no outbound connections are allowed on any port.
- None: No inbound or outbound connections are permitted on any port.
When you choose an access mode of None or Out Only:
- You can open specific ports for inbound connections as exceptions to the default rule applied by the selected access mode. By default, traffic for a fenced VM with In or In/Out Access is redirected to all of its private ports.
- All access to the VMs must be handled via console connections, unless you have opened specific ports for inbound connections. When inbound communications are required, the network must be configured for promiscuous mode.
Here are the major steps you carry out to set up network fencing:
- Prepare vCenter back-end networking. This involves setting up non-routable VLANs for the fenced networks.
- Create an IP pool dedicated to fencing.
- Create a deployment destination for fenced networks.
- Create a service using a fenced network.
Add and remove DNS records for fenced VMs
When you deploy a fenced service, the VMs behind the fence are segregated from the rest of your network. This means that DNS records are not automatically created for fenced VMs. Users outside the fence are still able to connect, providing you've allowed IN access, but only by IP address.
Decommission fenced networks
No special consideration is required to decommission the vRouters handling a fenced network. When all VMs inside the fence have been removed, Commander automatically decommissions the vRouter.
Deleting the fenced service at the virtual service level is recommended.
Connect to the vRouter
If you need to connect to the deployed vRouter in a fenced network, use console access. SSH access has been disabled for security reasons.