N E T V I R T E X P E R T

     As I wrote on some of my previous posts, Lets Encrypt automation of certs renewal inside NSX ALB (Avi) platform is very useful for Customer environments utilising large number of web oriented services, which needs to be on free HTTPS setup. These blogs about integration could be found here LINK-1 or LINK-2 for DNS based configurations.     What I saw from some operational systems is that,  occasionally, there is small piece left under HTTP policies (for HTTP-01 based challenges), in parent-child setups of virtual services, where HTTP policy is not removed properly from parent virtual service and that prohibits further renewal of certificate when it's needed. Typical removal of that piece is making troubles because it's associated to virtual service and system is not allowing that change.     What's needed is to de-associate problematic HTTP policy set from virtual service and then it can be freely removed from system without any issue. This...

     Recently, I had very interesting scenario around NSX ALB (ex Avi Networks) setup with multiple networks, NAT's and no-NAT's, but more important routing requirement inside Customer environment. As you are aware of - NSX ALB Service engines have multiple NICs - to be more accurate there are 1 management + 9 data interfaces, which can be used with different configurations depending on actual needs and infrastructure. In my specific case, there were following assumptions which were successfully deployed across virtual service configuration: - external network (from NSX ALB perspective) - based on Cisco ACI SDN solution, where basically different L3-outs (specific ACI setup) for multiple NSX ALB needs were configured directly on Cisco platform. For this purpose, we will introduce VRF named XYZ, specifically created for connections mentioned above; - there is a need for multiple floating IP + BGP config in place on NSX ALB SE's, which can be found on this link  Defaul...

    NSX ALB (ex Avi Networks) solution supports different methods for scaling inside data plane, providing required resources in throughput, high availability and scalability vertically and horizontally. In typical scale-out mechanism for virtual service, which btw can be manual or automatic setup, service engines (SE) are added to group and existing VIP (Virtual Service IP) is maintained (scale-in process is of course opposite one). Basically different options are available for these scaling methods, known as: L2 scale-out mode - VIP always mapped to "primary" SE, which implies that "organization" of traffic and sending to others SE's in group is also responsibility of primary SE --> heavier operations and dependency on this node are possible. Return traffic  can go directly from the secondary SE's via the Direct Secondary Return mode or via the primary SE (Tunnel mode).  Direct Secondary Return  (DSR) mode gives option to  return traffi...

     In one of my previous posts about NSX ALB (Avi) and Let's Encrypt integration LINK , I explained how useful could be implementing service like this, especially in Customer environment where large number of different DNS records exist, serving different virtual services using legitimately known and signed digital certificate. Based on main part of this functionality, GitHub script used for certificate management service inside NSX ALB ( LINK - v0.9.7 actual at the time of writing), I would like to show you different options available and useful depending on different use cases and scenarios.     Parameters used by script are well defined and usable inside certificate management configuration on NSX ALB: user / password - self explained and needed by certificate management service for successful run of script. Permissions using custom role defined as  read & write access enabled for Virtual Service, Application Profile, SSL/TLS Certificates and Cer...

     I would like to share very useful setup for VMware NSX ALB (ex Avi solution), in terms of usage freely available Let's Encrypt certificate management solution. Basically, provided script gives you automation inside NSX ALB environment, without the need for some external tools or systems. Putting it summary these are the required steps: - create appropriate virtual service (VS) which you will use for SSL setup with Let's Encrypt cert - this can be standalone service or SNI ( Service Name Identifier ) based ( Parent/Child ) if needed. Initially you can select "System-Default" SSL cert during the VS setup; - create appropriate DNS records for new service in place - out of scope of NSX ALB most of the times. NSX ALB Controllers should have access to Let's Encrypt public servers for successful ACME based HTTP-01 certificate generation/renewal; - Download required script from  HERE - Follow rest of required configuration steps on this link  NSX-ALB-Lets-Encrypt-S...