2 Replies Latest reply on Dec 16, 2016 5:30 PM by Bayu Wibowo

    NSX Design Considerations for Automation

    JoJoGabor Expert

      I'm working on an environment which is integrated with vRealize Automation. The design put in place was to implement 3-tiers (web, app, db) of logical switches for each application (or service) with a ESG for each application. I am not familiar with the reasons behind this but I'm failing to see why this would be useful. Would a better solution be to simply have a logical switch for each of the three tiers, or even condense this to two logical switches, DMZ and Internal then simply use micro-segmented firewall rules to keep services from talking to each other. These could be split into subnets for consumption by each service.

       

      This approach seems a lot simpler to build on demand from vRA as it simply consumes a new subnet and doesn't require creating new logical switches or ESGs each time.

       

      Another question. We are using a universal transport zone so we can failover services between DCs, so will all firewall rules lose the ability to use dynamic security groups, and I will have to automate adding into IP sets from vRA. This could get messy

       

      interested in your thoughts as I've never been involved in NSX Design before

        • 1. Re: NSX Design Considerations for Automation
          Sreec Master
          vExpertCommunity Warriors

          The design put in place was to implement 3-tiers (web, app, db) of logical switches for each application (or service) with a ESG for each application. I am not familiar with the reasons behind this but I'm failing to see why this would be useful. Would a better solution be to simply have a logical switch for each of the three tiers, or even condense this to two logical switches, DMZ and Internal then simply use micro-segmented firewall rules to keep services from talking to each other.


          You could do it in any fashion(3 Logical Switches or 1 Logical Switches ,1 ESG ,3 ESG  8ESG etc..) . Choice of design should be purely based on business requirement. I wouldn't put Web,app&db(Three LS) to Three ESG and establish a routing between them. That is unnecessary routing configuration neither i will not recommend deploying three DLR also for each Logical Switch(web,app&db) connected to one Edge . Why don't you connect all three LS to one DLR and connect DLR to ESG ?


          Another question. We are using a universal transport zone so we can failover services between DCs, so will all firewall rules lose the ability to use dynamic security groups, and I will have to automate adding into IP sets from vRA.


          Not 100% sure with VRA if there is any complexity with this ask. As per my knowledge as long as we are leveraging Universal MAC/IP,SG or Lswicth we are good to go.

          • 2. Re: NSX Design Considerations for Automation
            Bayu Wibowo Master
            Community WarriorsUser Moderators

            I hope you have found solution for your scenario.

             

            I agree with you, I would prefer to have 3 or 2 logical switches connected to a same DLR through either:

            1. on demand routed network profile when multiple subnets are required for policy reasons, or

            2. external network profile and use existing logical switches if all workloads tier share same subnet

             

            For production/non-dev workloads I don't normally connect to ESG which means I won't use on demand NAT network profile

            I use on demand NAT network profile or connect logical switches to ESG when overlapping IP address is required or IP is limited

             

            For multi-site deployments

            My understanding is that universal logical switches can be used both using existing logical switches via external network profile or

            on demand universal logical switches via on demand NAT/Routed network profile

            But universal security objects is not supported

            We can still use the non-universal security groups, policies, tags, but policies are enforced only on vCenter where VMs are deployed

             

            Hopefully future vRA/NSX releases provide ability to create universal security objects

            Bayu Wibowo | vExpert NSX, VCIX6-DCV/NV, Cisco Champion, AWS-SAA
            Author of VMware NSX Cookbook http://bit.ly/NSXCookbook
            https://nz.linkedin.com/in/bayupw | twitter @bayupw