VMware SD WAN (Velocloud) on prem lab guide

    For the purpose of lab playground and explore on different features from VMware SD WAN (ex Velocloud) solution, it's possible to relatively easy deploy required solutions inside demo environments. Full on prem production infrastructure requires use of VMware professional services for proper deployment and installation, with cloud based as most preferred option by vendor itself.
    Setup requires a couple of OVA files for deployment, like in typical VMware environments:
- vCO - orchestrator, for the purpose of configuration and management plane,
- vCG - gateway, for the purpose of control plane function,
- vCE - edge, data plane establishment and possibly the only hardware piece in SD WAN setup (also available as OVA of course).
    Successful setup comprises next steps:
1) classic OVA deployment of vCO and vCG components - vCO/vCG. For vCO and vCG you have option to dedicate 1 or 2 interfaces for the purpose of communication with external/internal (ie second vCO or vCG) world - 1 NIC setup is totally fine and easier for lab environment.
2) Login to the URL: https://${VM-IP}/operator with default username/password combination: super@velocloud.net/vcadm!n - CHANGE ACCORDINGLY!
3) Change, if needed depending on addressing, default blocked subnets inside vCG using SSH - edit the file: /opt/vc/etc/vc_blocked_subnets.json
4) Create new gateway on vCO system - IP is pre-defined vCG, and key will be generated after this step which will be needed in next step:


5) SSH to vCG and activate using command - if network reachability exists activation will be successful:
sudo /opt/vc/bin/activate.py -i -s $<VCO IP> $<KEY>
6) vCG should be added to gateway pool inside vCO configuration
7) vCO - create new Customer for testing purposes:


8) Create new vCE assigning to previously created test Customer - remember activation key:


9) Deploy vCE using OVA file as usual procedure. vCE in virtual format has multiple interfaces, which are later able to be configured as WAN or LAN accordingly. Using activation key from previous step and IP of vCO you can set automatic activation of virtual edge in your lab environment. If needed occasionally - default SSH password for edge devices is in form of "VeloHello***", where *** stands for last 3 digits of equipment number.
10) After this usual environment configuration steps in term of edge firmware upgrade / profile edit / network related configs etc.





Comments

Post a Comment

Popular posts from this blog

NSX ALB LetsEncrypt with DNS-01 challenge - BIND example

    In some of my previous posts, mentioned here LetsEncrypt script integration and Script parameter usage , I explained how useful it can be for NSX advanced load balancing solutions to utilise this kind of approach for free and automatic certificate manipulation, especially in environments with large number of web services inside. This approach utilises HTTP-01 based challenge with LetsEncrypt systems and L7 HTTP/S virtual services on NSX ALB side.     Now, from some time ago there is enhancement in this area, developed by official Avi Networks devops page, in terms of using DNS-01 challenge also. I tried on-prem option using Bind DNS as server which works very well.     Steps are pretty much similar to HTTP-01 option, which can be summarised as following:      - Create L7 virtual service with publicly available FQDN - certificates resolved can be in both options RSA or ECDSA, as configured during creation;        - Do...
Read more

VMware SD WAN - multiple locations - LAN IP address space overlapping with NAT

Image
     Different scenarios are possible in terms of routing, NAT-ing and IP overlapping setups using VMware Velocloud SD WAN technology in Customer environments.      Recently I had an PoC with my Customer for the on-prem option with this VMware solution, where different use cases were interesting to show and demonstrate - one of them is something I would like to share and it relates to possibility of LAN-side NAT on Edge (branch) locations, with purpose to have IP overlapped on these setups. Next picture is showing typical Hub&Spoke setup where it can be possible to make this type of configuration: Picture 1. VMware SD WAN lab on-prem environment     Basically thing which needs to be accomplished is appropriate NAT solution for LANs on every branch Edge which are and needs to be the same (192.168.1.0/24 in this example) - as it is shown on Picture 1.      Honestly speaking, NAT is not one of so powerful things insi...
Read more

NSX-T Layer 2 bridging - scenarios & use cases

Image
     Layer 2 bridging is very useful feature of NSX-T, which provides connection to a VLAN backed port group or a device, such as a gateway, that resides outside of NSX-T DC environment. Useful scenarios, among others, are: Workload migration from VLAN-backed to NSX overlay segment, NSX-V to NSX-T migration in Customer environments, Security features leverage using NSX-T Gateway firewall etc. L2 bridging feature requires usage of Edge clusters and Edge Bridge profiles.      Deployments should consider different options, with most important scenarios, for implementation below (this covers Edge VM deployment option as typical use case): Edge VM on VSS portgroup  --> promiscuous and forged transmit on portgroup REQUIRED / ESXi host (with Edge VM) command " esxcli system settings advanced set -o /Net/ReversePathFwdCheckPromisc -i 1 " REQUIRED / Active and Standby Edge VMs should be on different hosts, Edge VM on VDS 6.6 (or later) portgroup  -->...
Read more