In these parts, I will show and explain how to configure and use the AVI integration with NSX-T Data Center Distributed Firewall (DFW).
- Prelude : AVI SE in NSX-T Exclusion List
- Part 1 : NSX-T Security Group used as a back-end server pool
- Part 2 : Deploying SEs using NSX-T DHCP & NSX-T DFW
- Part 3 : From Virtual Service into NSX-T DFW
The version of NSX-T I used was 3.1.1 (due to old configurations, I use the Manager Policy for the DFW) and AVI 20.1.5.
When we say AVI Integration with NSX-T, it means that we create an “NSX-T Cloud” from AVI.
Official AVI Documentation related to this topic: https://avinetworks.com/docs/20.1/nsx-t-no-se-in-exclude-list/#creating-dfw-rules
Part 1 – NSX-T Security Group used as a back-end server pool
A great point with AVI and the integration with NSX-T is that we are now able to create NSX-T Security Groups and apply them as the pool for our Virtual Services (VS).
The idea here is to work with the Security Tag (matching criteria of the Security Group).
We apply the tags to the VMs we want to have as back-end servers.
This solution give us a great flexibility! For instance if we want to add or remove a backend server we just have to add or remove the Security Tag from the VM.
In addition, in the other upcoming parts we are going to reuse this Security Group in our DFW.
The first manipulation is to create a new NSX-T Security Group (sg.avi-pool-itstxaasvip0001) from NSX-T and add some matching criteria in my case based on VM Tag (st.pool-itstxaasvip0001).
We can then add this newly created Security Tag to all our concerned VMs.
Here I did it manually but the idea is that these Tags are applied and removed dynamically through any automation tool of course.
We can then check that the VMs are now included in our Security Group.
We’re now good from an NSX-T perspective and we can jump to our AVI Controller.
When creating the server pool we can now find and select our NSX Security Group.
It will from now apply automatically and maintain the IPs of our VMs.
