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 can be accomplished in 2 d

     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  Default Gatew