DVS NIC teaming load balancing options and NSX interoperability and PowerNSX: NSX Security Tags, Security Groups, Distributed Firewall Sections and Distributed Firewall Rules with external CSV files: Difference between pages

From Iwan
(Difference between pages)
Jump to: navigation, search
(Import pages from iwan.wiki)
 
(Import pages from iwan.wiki)
 
Line 1: Line 1:
== Introduction ==
Last week I blogged about how to get started with PowerNSX.


When we set up NSX one of the components that need to be installed at some point is a VTEP network adapter.
Reason for me to dive into the wonderful world of PowerNSX was because I needed to implement Application Fencing.
This VTEP network adapter is nothing more than a virtual (vmk) network adapter on the host that is responsible to encapsulate "normal" network packets into VXLAN network packets (or the other way around).
More about Application Fencing wan be found [https://www.youtube.com/watch?v=CEIc8GCnD6g here] and [http://networkinferno.net/achieving-micro-segmentation-with-log-insight here].
These VTEP's will use the existing vNIC uplinks that are currently configured and leveraged by the vSphere Distributed Switch (vDS).
In this article I am going to explain what the available options are and how this is used by NSX.


== dVS teaming and NSX VMKNic teaming policy mapping ==
The whole purpose of implementing Application Fencing is to get visibility what VM / Application is talking to what VM / Application with what protocol and port.


There are various different sources of documentation available form VMware and I noticed that the terminology is not always in sync.
This information can be used to implement an [https://networkinferno.net/implementing-a-zero-trust-security-architecture Zero Trust Security Architecture]
To understand this fully I have tried to map everything together to see what statements and settings belong to each other.
This is shown in the table below:


{{TableStart}}
I will write a separate blog about Application Fencing in the future but in order to get there there are some steps that needs to be done.
<tr class="info"><th>NSX Design Guide Terminology</th><th>NSX Install Guide Terminology</th><th>NSX Supported</th><th>Multiple VTEPs supported</th><th>Traffic Flow / Link Usage</th><th>Corresponding VMKNic teaming policy</th></tr>
<tr><td>Route Based on Originating Port</td><td>Route based on the originating virtual port</td><td>Yes</td><td>Yes</td><td>Both links active</td><td>LOAD BALANCE - SRCID</td></tr>
<tr><td>Route Based on Source MAC Hash</td><td>Route based on source MAC hash</td><td>Yes</td><td>Yes</td><td>Both links active</td><td>LOAD BALANCE - SRCMAC</td></tr>
<tr><td>Route Based on IP Hash (Static EtherChannel)</td><td>Route based on IP hash</td><td>Yes</td><td>No</td><td>Flow based</td><td>STATIC ETHERCHANNEL</td></tr>
<tr><td>Explicit Failover Order</td><td>Use explicit failover order</td><td>Yes</td><td>No</td><td>One link active</td><td>FAILOVER</td></tr>
<tr><td>LACP</td><td>Not mentioned here</td><td>Yes</td><td>No</td><td>Flow based</td><td>ENHANCED LACP</td></tr>
<tr><td>Route Based on Physical NIC Load (LBT)</td><td>Route based on physical NIC load</td><td>No</td><td>N/A</td><td>N/A</td><td>N/A</td></tr>
{{TableEnd}}


{{note|ENHANCED LACP is also called LACPv2}}
In my example I will use the traditional 3-tier Bookstore App.
This vApp has the following VM's:
# Web01
# Web02
# App01
# App02
# DB01


{{note|On a individual port group level you can override the dVS teaming option, but the recommendation is not to mix these too much}}
Right now we only have 5 VM's so creating the Security Tags, Security Groups, Assigning the tags to specific VM's and Creating the Distributed Firewall Rules is done pretty fast.


== Configure VXLAN Transport Parameters (taken from the "NSX Installation Guide") ==
BUT WHAT IF ... you need to implement Application Fencing in an infrastructure with more than 1000 VM's with 500 security tags and 500 security groups and the corresponding firewall rules?


<blockquote>
This could take a while right?
Plan your NIC teaming policy.
Your NIC teaming policy determines the load balancing and failover settings of the vSphere Distributed Switch.


Do not mix different teaming policies for different port groups on a vSphere Distributed Switch where some use Etherchannel or LACPv1 or LACPv2 and others use a different teaming policy.
You can speed this up with the use of PowerNSX!
If uplinks are shared in these different teaming policies, traffic will be interrupted.
Below you will find a method to run PowerNSX in combination with external Comma Separated Value (CSV) files.
If logical routers are present, there will be routing problems.
This will save you a lot of time!
Such a configuration is not supported and should be avoided.


The best practice for IP hash-based teaming (EtherChannel, LACPv1 or LACPv2) is to use all uplinks on the vSphere Distributed Switch in the team, and do not have port groups on that vSphere Distributed Switch with different teaming policies.
The steps to implement Application Fencing are:


For more information and further guidance, see the VMware® NSX for vSphere Network Virtualization Design Guide at https://communities.vmware.com/docs/DOC-27683.
# Add Security Tags and Tier based Security Groups (and statically make the security tag an member of the tier security group)
</blockquote>
# Assign the Security Tags to the correct VM's (so that the VM's are placed in the correct tier group)
# Add separate Application based Security Groups (so that the Tier based Security Groups can be nested inside an Application Security Group)
# Nest the Tier based Security Groups into the Application Security Group
# Add Distributed Firewall Sections to add in the Distributed Firewall Rules
# Add in the Tier based Distributed Firewall Rules
# Add in the Application based Distributed Firewall Rules


[https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.3/com.vmware.nsx.install.doc/GUID-2FA9D4DE-56C0-40A4-A085-2FCE502A87B9.html Source]
{{note|This example will only have 5 VM's spread across 3 tiers all forming 1 application so this approach looks like its a bit overkill, but when you need to implement this in an organisation with a lot of VM's and a lot of applications that are segmented into different tenants then you will love it!}}


== VDS Uplinks Connectivity NSX Design Considerations (taken from the "From the VMware® NSX for vSphere Network Virtualization Design Guide") ==
The scripts and CSV files that I used for this exercise are found below.


<blockquote>
== Add Security Tags and Tier based Security Groups (and statically make the security tag an member of the tier security group) ==
The teaming option associated to a given port-group must be the same for all the ESXi hosts connected to that specific VDS, even if they belong to separate clusters.
For the case of the VXLAN transport port-group, if the LACP teaming option is chosen for the ESXi hosts part of compute cluster, this same option must be applied to all the other compute clusters
connected to the same VDS.
Selecting a different teaming option for a different cluster would not be accepted and will trigger an error message at the time of VXLAN provisioning.


If LACP or static EtherChannel is selected as the teaming option for VXLAN traffic for clusters belonging to a given VDS, then the same option should be used for all the other port-groups/traffic types defined on the VDS.
The script {{f|/script.ps1}}:
The EtherChannel teaming choice implies a requirement of additionally configuring a port-channel on the physical network.
Once the physical ESXi uplinks are bundled in a port-channel on the physical switch or switches, using a different teaming method on the host side may result in unpredictable results or loss of communication. This is one of the primary reasons that use of LACP is highly discouraged, along with restriction it imposes on Edge VM routing connectivity with proprietary technology such as vPC from Cisco.


The VTEP design impacts the uplink selection choice since NSX supports single or multiple VTEPs configurations.
{{file|name=/script.ps1|desc=The script.ps1 file|body=
The single VTEP option offers operational simplicity.
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
If traffic requirements are less than 10G of VXLAN traffic per host, then the Explicit Failover Order option is valid.
## version 1.0
It allows physical separation of the overlay traffic from all the other types of communication; one uplink used for VXLAN, the other uplink for the other traffic types.
## August 2016
The use of Explicit Failover Order can also provide applications a consistent quality and experience, independent from any failure.
#--------------------------------------------------
Dedicating a pair of physical uplinks to VXLAN traffic and configuring them as active/standby will guarantee that in the event of physical link or switch failure, applications would still have access to the
# ____  __  _  _  ____  ____  __ _  ____  _  _
same 10G pipe of bandwidth.
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
This comes at the price of deploying more physical uplinks and actively using only half of the available bandwidth.
#  ) __/(  O )\ /\ / ) _)  )  //    /\___ \ )  (
# (__)  \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#    PowerShell extensions for NSX for vSphere
#--------------------------------------------------


A single VTEP is provisioned in the port-channel scenarios, despite the fact there are two active VDS uplinks.
#This will create the security tags and the groups based on a CSV.
This is because the port-channel is considered a single logical uplink since traffic sourced from the VTEP can be hashed on a per-flow basis across both physical paths.
#Note that the tags and groups will need to be UNIQUE as this script does not do error handling.


Since the single VTEP is only associated in one uplink in a non port-channel teaming mode, the bandwidth for VXLAN is constrained by the physical NIC speed.
#import the CSV file content and place the content in a loop
If more than 10G of bandwidth is required for workload, multiple VTEPs are required to increase the bandwidth available for VXLAN traffic when the use of port-channels is not possible (e.g., blade servers). Alternately, the VDS uplink configuration can be decoupled from the physical switch configuration.
import-csv .\CSV.csv <nowiki>|</nowiki> % {
Going beyond two VTEPs (e.g., four uplinks) will results into four VTEP configurations for the host, may be challenging while troubleshooting, and will require a larger IP addressing scope for large-scale L2 design.
The number of provisioned VTEPs always matches the number of physical VDS uplinks.
This is done automatically once the SRC-ID or SRC-MAC option is selected in the “VMKNic Teaming Policy” section of the UI interface.


The recommended teaming mode for the ESXi hosts in edge clusters is “route based on originating port” while avoiding the LACP or static EtherChannel options.
#Create security tag based on field in CSV
Selecting LACP for VXLAN traffic implies that the same teaming option must be used for all the other port-groups/traffic types which are part of the same VDS.
$st = New-NsxSecurityTag -name $_.SECTAG
One of the main functions of the edge racks is providing connectivity to the physical network infrastructure.
This is typically done using a dedicated VLAN-backed port-group where the NSX Edge handling the north-south routed communication establishes routing adjacencies with the next-hop L3 devices.
Selecting LACP or static EtherChannel for this VLAN-backed port-group when the ToR switches perform the roles of L3 devices complicates the interaction between the NSX Edge and the ToR devices.


The ToR switches not only need to support multi-chassis EtherChannel functionality (e.g., vPC or MLAG) but must also be capable of establishing routing adjacencies with the NSX Edge on this logical connection.
#Create security group based on field in CSV and makes the security tag a member of the new security group
This creates an even stronger dependency from the underlying physical network device; this may an unsupported configuration in specific cases.
$sg = New-NsxSecurityGroup -name $_.SECGROUP -includemember ($st)
As a consequence, the recommendation for edge clusters is to select the SRCID/SRC-MAC hash as teaming options for VXLAN traffic.
}
An architect can also extend this recommended approach for the compute cluster to maintain the configuration consistency, automation ease, and operational troubleshooting experience for all hosts’ uplink connectivity.
}}
In summary, the “route based on originating port” is the recommended teaming mode for VXLAN traffic for both compute and edge cluster.
</blockquote>


[https://communities.vmware.com/docs/DOC-27683 Source]
The CSV:


== Edge Service Gateway peering across vPC rules ==  
{{file|name=/CSV.csv|desc=The CSV.csv file|body=
SECTAG,SECGROUP
ST-WEB,SG-TIER-WEB
ST-APP,SG-TIER-APP
ST-DB,SG-TIER-DB
}}


One of the statements above in the NSX Design guide was "Selecting LACP or static EtherChannel for this VLAN-backed port-group when the ToR switches perform the roles of L3 devices complicates the interaction between the NSX Edge and the ToR devices"
Executing the Script:


The general rules are
{{console|body=
#you CANNOT set up a route peering with devices that have an vPC peer link across a vPC Port Channel.
PowerCLI C:\new> ##b####y##.\script.ps1
##In order to work around this you can set up separate L2 links (disjoint Layer 2 Links) to allow the peering across these links.
}}
#you CAN set up a route peering with devices ACROSS a vPC Port Channel


Below I have illustrated this:
Result:


[[File:nsx-vtep-nic-teaming-0.png|1200px]]
[[File:sddfnmxc-01.png|800px]]


== VMKNic teaming policy ==
[[File:sddfnmxc-02.png|800px]]


Below you can find the different VMKNic teaming policy options that you are able to select.
== Assign the Security Tags to the correct VM's (so that the VM's are placed in the correct tier group) ==
I have also put together a small summery of the characteristics to get a good feel how this is working and I will back this with some diagrams later in this article.


=== Load Balance - SRCID ===
The script {{f|/script.ps1}}:


[[File:nsx-vtep-nic-teaming-1.png|300px]]
{{file|name=/script.ps1|desc=The script.ps1 file|body=
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#--------------------------------------------------
# ____  __  _  _  ____  ____  __ _  ____  _  _
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )  //    /\___ \ )  (
# (__)  \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#    PowerShell extensions for NSX for vSphere
#--------------------------------------------------


* Multiple VTEP supported
#This will go trough the list of VM's and apply the tag that is on the same line of the VM
* VTEP to vNIC mapping is1:1
import-csv .\CSV.csv<nowiki>|</nowiki>% {
* VM1 with portID=1 will take vNIC0
* VM1 with portID=4 will take vNIC1
* VM2 with portID=2 will take vNIC1
* VM3 with portID=3 will take vNIC0
* The first path chosen will always be valid and does not expire
* The algorithm is round-robin
* This does not take interface load into account


=== Load Balance - SRCMAC ===
#Read security tag from a field in the CSV
$st = Get-NsxSecurityTag -name $_.SECTAG


[[File:nsx-vtep-nic-teaming-2.png|300px]]
#Read VM Name from a field in the CSV
$vm = Get-Vm -name $_.VMNAME


* Multiple VTEP supported
#Assign security tag to the VM Name
* VTEP to vNIC mapping is1:1
$vm = Get-Vm -name $_.VMNAME<nowiki>|</nowiki>New-NsxSecurityTagAssignment -ApplyTag $st
* VM1 with MAC#1 (eth0.1) will take vNIC0
}
* VM1 with MAC#2 (eth0.2) will take vNIC1
}}
* VM2 with MAC#2 will take vNIC1
* VM3 with MAC#3 will take vNIC0
* The first path chosen will always be valid and does not expire
* The algorithm is round-robin
* This does not take interface load into account
* This option takes a bit more overhead then SRCID


=== Static Etherchannel ===
The CSV:


[[File:nsx-vtep-nic-teaming-3.png|300px]]
{{file|name=/CSV.csv|desc=The CSV.csv file|body=
VMNAME,SECTAG
Web01,ST-WEB
Web02,ST-WEB
App01,ST-APP
App02,ST-APP
DB01,ST-DB
}}


* One VTEP supported
Executing the Script:
* One interface is only visible (LAG interface)
* The load balancing is taken care of the LACP protocol
* Old version of LACP in dVS version 5.0


=== Enhanced LACP (LACPv2) ===
{{console|body=
PowerCLI C:\new> ##b####y##.\script.ps1
}}


[[File:nsx-vtep-nic-teaming-4.png|300px]]
Result:


* One VTEP supported
[[File:sddfnmxc-06.png|800px]]
* One interface is only visible (LAG interface)
* The load balancing is taken care of the LACP protocol


* LACPv1 is not supported
[[File:sddfnmxc-07.png|800px]]
** Old version with less supported load balancing algorithms
** One LAG interface per dVS supported
** One LAG interface per host supported
* LACPv2 = Enhanced LACP
** New version with more supported load balancing algorithms
** 64 LAG interfaces per dVS supported


This is the screen to show how the LAG is configured:
[[File:sddfnmxc-03.png|800px]]


[[File:nsx-vtep-nic-teaming-5.png|300px]]
[[File:sddfnmxc-04.png|800px]]


=== Failover ===
[[File:sddfnmxc-05.png|800px]]


[[File:nsx-vtep-nic-teaming-6.png|300px]]
== Add separate Application based Security Groups (so that the Tier based Security Groups can be nested inside an Application Security Group) ==


* One VTEP supported
The script {{f|/script.ps1}}:
* One interface will always be active and the other always standby


== Explicit Failover Order (one VTEP) ==
{{file|name=/script.ps1|desc=The script.ps1 file|body=
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#--------------------------------------------------
# ____  __  _  _  ____  ____  __ _  ____  _  _
# ( _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )  //    /\___ \ )  (
# (__)  \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#    PowerShell extensions for NSX for vSphere
#--------------------------------------------------


* VM1 (with PortID 1) will use the only VTEP interface available and will use the active Physical NIC of the ESXi Host
#This will create the security groups.
* VM2 (with PortID 2) will use the only VTEP interface available and will use the active Physical NIC of the ESXi Host
#Note that the tags and groups will need to be UNIQUE as this script does not do error handling.
* VM3 (with PortID 3) will use the only VTEP interface available and will use the active Physical NIC of the ESXi Host
* Only one Physical NIC is always active and the other one is standby
* When the active goes down then the standby becomes active and the traffic is forwarded trough that new active interface
* Port ID is not taken into consideration for load sharing / load balancing


[[File:nsx-vtep-nic-teaming-7.png|1000px]]
#Create security groups
New-NsxSecurityGroup -name SG-APP-BOOKSTORE
}}


== Route Based on Originating Port ID (two VTEPs) ==
Executing the Script:


* VM1 (with PortID 1) will use the VTEP1 interface available and will use the Physical NIC 0 of the ESXi Host
{{console|body=
* VM2 (with PortID 2) will use the VTEP2 interface available and will use the Physical NIC 1 of the ESXi Host
PowerCLI C:\new> ##b####y##.\script.ps1
* VM3 (with PortID 3) will use the VTEP1 interface available and will use the Physical NIC 0 of the ESXi Host
** This goes on-and-on in a Round Robin fashion
* Both physical NICs are active
* When the one physical NIC goes down then the other will be used and the traffic is forwarded trough that available interface
* Port ID is taken into consideration for load sharing / load balancing
* The algorithm does not take interface load into account
** SO if physical NIC0 is overutilized due to al ot of traffic traversing this interface the "Route Based on Originating Port ID" algorithm will still try to use this interface


[[File:nsx-vtep-nic-teaming-8.png|1000px]]
objectId          : securitygroup-31
objectTypeName    : SecurityGroup
vsmUuid            : 4223B69E-2DE2-804A-0BE0-FA7307BB2D02
nodeId            : c1afd25d-49fe-4259-bd07-f4508a80d472
revision          : 1
type              : type
##b####bl##name              : SG-APP-BOOKSTORE
description        :
scope              : scope
clientHandle      :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false
}}


== Route Based on Source MAC Hash (two VTEPs) ==
Result:


* VM1 (with MAC A) will use the VTEP1 interface available and will use the Physical NIC 0 of the ESXi Host
[[File:sddfnmxc-08.png|800px]]
* VM2 (with MAC B) will use the VTEP2 interface available and will use the Physical NIC 1 of the ESXi Host
* VM3 (with MAC C) will use the VTEP1 interface available and will use the Physical NIC 0 of the ESXi Host
* VM2 (with MAC D) will use the VTEP1 interface available and will use the Physical NIC 0 of the ESXi Host
** This goes on-and-on in a Round Robin fashion
** VM2 has one virtual NIC with two sub-interfaces and each sub-interface has it's own MAC address
* Both physical NICs are active
* When the one physical NIC goes down then the other will be used and the traffic is forwarded trough that available interface
* MAC Addresses are taken into consideration for load sharing / load balancing
* The algorithm does not take interface load into account
** SO if physical NIC0 is overutilized due to al ot of traffic traversing this interface the "Route Based on Originating Port ID" algorithm will still try to use this interface


[[File:nsx-vtep-nic-teaming-9.png|1000px]]
== Nest the Tier based Security Groups into the Application Security Group ==


== vSphere Networking and NSX - Static EtherChannel and LACP - 1 x VTEP ==
The script {{f|/script.ps1}}:


* With the use of Etherchannel or LACP regardless what version the loadbalancing protocol selected between the vDS and the physical switch will dictate the load balancing way
{{file|name=/script.ps1|desc=The script.ps1 file|body=
* Both physical NICs are active
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
* When the one physical NIC goes down then the other will be used and the traffic is forwarded trough that available interface
## version 1.0
## August 2016
#--------------------------------------------------
# ____  __  _  _  ____  ____  __ _  ____  _  _
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )  //    /\___ \ )  (
# (__)  \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#    PowerShell extensions for NSX for vSphere
#--------------------------------------------------


[[File:nsx-vtep-nic-teaming-10.png|1000px]]
#This will read the security groups from the CSV and will nest the groups into other groups in the CSV.


=== vSphere load balancing type support===
import-csv .\CSV.csv<nowiki>|</nowiki>% {


vSphere supports these load balancing types:
#Read the TIER Security Group
$app = Get-NsxSecurityGroup -name $_.SECTIERGROUP


# Destination IP address
#Read the APP Security Group
# Destination IP address and TCP/UDP port
$ags = Get-NsxSecurityGroup -name $_.SECAPPGROUP
# Destination IP address and VLAN
# Destination IP address, TCP/UDP port and VLAN
# Destination MAC address
# Destination TCP/UDP port
# Source IP address
# Source IP address and TCP/UDP port
# Source IP address and VLAN
# Source IP address, TCP/UDP port and VLAN
# Source MAC address
# Source TCP/UDP port
# Source and destination IP address
# Source and destination IP address and TCP/UDP port
# Source and destination IP address and VLAN
# Source and destination IP address, TCP/UDP port and VLAN
# Source and destination MAC address
# Source and destination TCP/UDP port
# Source port ID
# VLAN


When LACP is configured the switch that the ESXi host is connected to must match the same load balancing type that is available and selected on the ESXi / dVS side.
#Nest one group into another
A mismatch between these two can and will result in the loss of network traffic.
$ags<nowiki>|</nowiki>Add-NsxSecurityGroupMember -member $app
}
}}


[https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2051826 Source]
The CSV:


=== Route Based on IP Hash (Static EtherChannel) or LACP with the load balancing types: Destination IP address and Source IP address ===
{{file|name=/CSV.csv|desc=The CSV.csv file|body=
APPNAME,SECTIERGROUP,SECAPPGROUP
BOOKSTORE,SG-TIER-WEB,SG-APP-BOOKSTORE
BOOKSTORE,SG-TIER-APP,SG-APP-BOOKSTORE
BOOKSTORE,SG-TIER-DB,SG-APP-BOOKSTORE
}}


When we select this option the load sharing of the traffic is determined by the load balancing algorithm that you select on the dVS side and on the physical network side.
Executing the Script:
When we select the load balancing type to be "Destination IP address" or "Source IP address" with VTEP traffic are some drawbacks.


This is how the VXLAN frame format looks like:
{{console|body=
PowerCLI C:\new> ##b####y##.\script.ps1


[[File:nsx-vtep-nic-teaming-11.png|600px]]
objectId          : securitygroup-31
objectTypeName    : SecurityGroup
vsmUuid            : 4223B69E-2DE2-804A-0BE0-FA7307BB2D02
nodeId            : c1afd25d-49fe-4259-bd07-f4508a80d472
revision          : 2
type              : type
name              : SG-APP-BOOKSTORE
description        :
scope              : scope
clientHandle      :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false
##b####bl##member            : member


When the LACP load balancing is done based on either the Destination IP address or the Source IP address it will use the “Outer IP Header” into consideration to make the load balancing decisions.
objectId          : securitygroup-31
Specifically for NSX it will use the IP addresses of the VTEP interfaces as te source or destination.
objectTypeName    : SecurityGroup
These IP addresses typically never change.
vsmUuid            : 4223B69E-2DE2-804A-0BE0-FA7307BB2D02
This means that the traffic path chosen will ALWAYS use the same links and no load balancing will take place for VXLAN based traffic (traffic that is originated from and to a NSX Logical Switch).
nodeId            : c1afd25d-49fe-4259-bd07-f4508a80d472
revision          : 3
type              : type
name              : SG-APP-BOOKSTORE
description        :
scope              : scope
clientHandle      :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false
##b####bl##member            : {SG-TIER-APP, SG-TIER-WEB}


[[File:nsx-vtep-nic-teaming-12.png|1000px]]
objectId          : securitygroup-31
objectTypeName    : SecurityGroup
vsmUuid            : 4223B69E-2DE2-804A-0BE0-FA7307BB2D02
nodeId            : c1afd25d-49fe-4259-bd07-f4508a80d472
revision          : 4
type              : type
name              : SG-APP-BOOKSTORE
description        :
scope              : scope
clientHandle      :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false
##b####bl##member            : {SG-TIER-DB, SG-TIER-APP, SG-TIER-WEB}


[[File:nsx-vtep-nic-teaming-13.png|600px]]
PowerCLI C:\new>
}}


So this combination is not usable and will not give you what you want.
Result:


[[File:nsx-vtep-nic-teaming-14.png|1000px]]
[[File:sddfnmxc-09.png|800px]]


In order to “solve” this it is better good to use a load balancing type that takes Layer 4 (protocol information UDP/TCP port information) into consideration.
== Add Distributed Firewall Sections to add in the Distributed Firewall Rules ==
This way load balancing will be based on more dynamic elements.


[[File:nsx-vtep-nic-teaming-15.png|1000px]]
The script {{f|/script.ps1}}:


[[File:nsx-vtep-nic-teaming-16.png|600px]]
{{file|name=/script.ps1|desc=The script.ps1 file|body=
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#--------------------------------------------------
# ____  __  _  _  ____  ____  __ _  ____  _  _
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )  //    /\___ \ )  (
# (__)  \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#    PowerShell extensions for NSX for vSphere
#--------------------------------------------------


== Other Documentation Sources ==
#This will only add 1 new Distributed Firewall Section.
New-NsxFirewallSection FWS-APP-BOOKSTORE
}}


*[http://www.routetocloud.com/2014/05/nsx-and-teaming-policy/ NSX and teaming policy]
Executing the Script:
*[https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.networking.doc/GUID-4D97C749-1FFD-403D-B2AE-0CD0F1C70E2B.html vSphere (6) vDS Teaming and Failover Policies]
 
*[http://cloudmaniac.net/vsphere-enhanced-lacp-support/ vDS LACPv1 and LACPv2 differences explanation]
{{console|body=
*[https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004088 NIC teaming in ESXi and ESX (1004088)]
PowerCLI C:\new> ##b####y##.\script.ps1
*[http://runnsx.com/index.php/2015/10/10/configuring-lacp-on-vsphere-6-0/ LACP ON VSPHERE 6.0 AND CISCO]
 
*[https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2120663 Link Aggregation Control Protocol (LACP) with VMware vSphere 5.1.x, 5.5.x and 6.x (2120663)]  
id              : 1012
*[https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2051826 Enhanced LACP Support on a vSphere 5.5 Distributed Switch (2051826)]  
##b####bl##name            : FWS-APP-BOOKSTORE
*[https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2006129 Understanding IP Hash load balancing (2006129)]  
generationNumber : 1470349159308
timestamp        : 1470349159308
type            : LAYER3
}}
 
Result:
 
[[File:sddfnmxc-10.png|800px]]
 
== Add in the Tier based Distributed Firewall Rules ==
 
The script {{f|/script.ps1}:
 
{{file|name=/script.ps1|desc=The script.ps1 file|body=
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#--------------------------------------------------
# ____  __  _  _  ____  ____  __ _  ____  _  _
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )  //   /\___ \ )  (
# (__)  \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#    PowerShell extensions for NSX for vSphere
#--------------------------------------------------
 
#This will go trough the list of Firewall Rules
import-csv .\CSV.csv<nowiki>|</nowiki>% {
 
#Collect the varables from the CSV file
$tn = $_.TIERNAME
$sg = get-nsxsecuritygroup $_.SECGROUP
$sec = get-nsxfirewallsection $_.FWSECTION
$fwt = $_.FWT
 
#Add rule to Firewall section
$sec<nowiki>|</nowiki>new-nsxfirewallrule -name $tn -Action allow -position bottom -appliedto $sg -Tag $fwt -EnableLogging
}
}}
 
The CSV:
 
{{file|name=/CSV.csv|desc=The CSV.csv file|body=
TIERNAME,SECGROUP,FWSECTION,FWT
WEB,SG-TIER-WEB,FWS-APP-BOOKSTORE,FWT-TIER-WEB
APP,SG-TIER-APP,FWS-APP-BOOKSTORE,FWT-TIER-APP
DB,SG-TIER-DB,FWS-APP-BOOKSTORE,FWT-TIER-DB
}}
 
Executing the Script:
 
{{console|body=
PowerCLI C:\new> ##b####y##.\script.ps1
 
id              : 1012
name            : FWS-APP-BOOKSTORE
generationNumber : 1470349548233
timestamp        : 1470349548233
type            : LAYER3
##b####bl##rule            : rule
 
id              : 1012
name            : FWS-APP-BOOKSTORE
generationNumber : 1470349548784
timestamp        : 1470349548784
type            : LAYER3
##b####bl##rule            : {WEB, APP}
 
id              : 1012
name            : FWS-APP-BOOKSTORE
generationNumber : 1470349549337
timestamp        : 1470349549337
type            : LAYER3
##b####bl##rule            : {WEB, APP, DB}
}}
 
Result:
 
[[File:sddfnmxc-11.png|800px]]
 
== Add in the Application based Distributed Firewall Rules ==
 
The script {{f|/script.ps1}}:
 
{{file|name=/script.ps1|desc=The script.ps1 file|body=
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#--------------------------------------------------
# ____  __  _  _  ____  ____  __ _  ____  _  _
# (  _ \ / \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )  //   /\___ \ )  (
# (__)  \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#    PowerShell extensions for NSX for vSphere
#--------------------------------------------------
 
 
 
#This will set the variables
$sec = $_.FWSECTION
$arn = $_.APPNAME
$sg = "$_.SECGROUP
$fwt = $_.FWT
 
#Here we create a new Distributed Firewall Rule with the variables set above
$sec<nowiki>|</nowiki>new-nsxfirewallrule -name $arn -Action allow -position bottom -appliedto $sg -Tag $fwt -EnableLogging
}}
 
The CSV:
 
{{file|name=/CSV.csv|desc=The CSV.csv file|body=
APPNAME,SECGROUP,FWSECTION,FWT
BOOKSTORE,SG-APP-BOOKSTORE,FWS-APP-BOOKSTORE,FWT-APP-BOOKSTORE
}}
 
Executing the Script:
 
{{console|body=
PowerCLI C:\new> ##b####y##.\script.ps1
 
id              : 1012
name            : FWS-APP-BOOKSTORE
generationNumber : 1470353361332
timestamp        : 1470353361332
type            : LAYER3
##b####bl##rule            : {WEB, APP, DB, BOOKSTORE}
}}
 
If you want to run the script without an CSV file your can use this:
 
{{file|name=/script.ps1|desc=The script.ps1 file|body=
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#--------------------------------------------------
# ____  __  _  _  ____  ____  __ _  ____  _  _
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )  //    /\___ \ )  (
# (__)  \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#    PowerShell extensions for NSX for vSphere
#--------------------------------------------------
 
$an = "BOOKSTORE"
$sg = get-nsxsecuritygroup "SG-APP-BOOKSTORE"
$sec = get-nsxfirewallsection "FWS-APP-BOOKSTORE"
$fwt = "FWT-APP-BOOKSTORE"
 
#Add rule to Firewall section
$sec<nowiki>|</nowiki>new-nsxfirewallrule -name $an -Action allow -position bottom -appliedto $sg -Tag $fwt -EnableLogging
}}
 
Result:
 
[[File:sddfnmxc-12.png|800px]]
 
Thanks [https://www.linkedin.com/in/kmruddy Kyle] for pointing out how to work with PowerShell and external CSV's and [https://www.linkedin.com/in/anthony-burke-b989b713 Anthony] for finetuning this.
And thanks [https://www.linkedin.com/in/nick-bradford-6349ba1 Nick] for this awesome PowerNSX!


<br />
<br />
[[Category:Articles]]
[[Category:Articles]]
[[Category:VMware]]
[[Category:VMware]]

Revision as of 10:35, 12 January 2024

Last week I blogged about how to get started with PowerNSX.

Reason for me to dive into the wonderful world of PowerNSX was because I needed to implement Application Fencing. More about Application Fencing wan be found here and here.

The whole purpose of implementing Application Fencing is to get visibility what VM / Application is talking to what VM / Application with what protocol and port.

This information can be used to implement an Zero Trust Security Architecture

I will write a separate blog about Application Fencing in the future but in order to get there there are some steps that needs to be done.

In my example I will use the traditional 3-tier Bookstore App. This vApp has the following VM's:

  1. Web01
  2. Web02
  3. App01
  4. App02
  5. DB01

Right now we only have 5 VM's so creating the Security Tags, Security Groups, Assigning the tags to specific VM's and Creating the Distributed Firewall Rules is done pretty fast.

BUT WHAT IF ... you need to implement Application Fencing in an infrastructure with more than 1000 VM's with 500 security tags and 500 security groups and the corresponding firewall rules?

This could take a while right?

You can speed this up with the use of PowerNSX! Below you will find a method to run PowerNSX in combination with external Comma Separated Value (CSV) files. This will save you a lot of time!

The steps to implement Application Fencing are:

  1. Add Security Tags and Tier based Security Groups (and statically make the security tag an member of the tier security group)
  2. Assign the Security Tags to the correct VM's (so that the VM's are placed in the correct tier group)
  3. Add separate Application based Security Groups (so that the Tier based Security Groups can be nested inside an Application Security Group)
  4. Nest the Tier based Security Groups into the Application Security Group
  5. Add Distributed Firewall Sections to add in the Distributed Firewall Rules
  6. Add in the Tier based Distributed Firewall Rules
  7. Add in the Application based Distributed Firewall Rules
Note

This example will only have 5 VM's spread across 3 tiers all forming 1 application so this approach looks like its a bit overkill, but when you need to implement this in an organisation with a lot of VM's and a lot of applications that are segmented into different tenants then you will love it!

The scripts and CSV files that I used for this exercise are found below.

Add Security Tags and Tier based Security Groups (and statically make the security tag an member of the tier security group)

The script /script.ps1:

/script.ps1 - The script.ps1 file
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#-------------------------------------------------- 
# ____   __   _  _  ____  ____  __ _  ____  _  _ 
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )   //    /\___ \ )  ( 
# (__)   \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#     PowerShell extensions for NSX for vSphere
#--------------------------------------------------

#This will create the security tags and the groups based on a CSV.
#Note that the tags and groups will need to be UNIQUE as this script does not do error handling.

#import the CSV file content and place the content in a loop
import-csv .\CSV.csv | % {

#Create security tag based on field in CSV
$st = New-NsxSecurityTag -name $_.SECTAG

#Create security group based on field in CSV and makes the security tag a member of the new security group
$sg = New-NsxSecurityGroup -name $_.SECGROUP -includemember ($st)
}

The CSV:

/CSV.csv - The CSV.csv file
SECTAG,SECGROUP
ST-WEB,SG-TIER-WEB
ST-APP,SG-TIER-APP
ST-DB,SG-TIER-DB

Executing the Script: 

PowerCLI C:\new> .\script.ps1

Result:

Sddfnmxc-01.png

Sddfnmxc-02.png

Assign the Security Tags to the correct VM's (so that the VM's are placed in the correct tier group)

The script /script.ps1:

/script.ps1 - The script.ps1 file
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#-------------------------------------------------- 
# ____   __   _  _  ____  ____  __ _  ____  _  _ 
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )   //    /\___ \ )  ( 
# (__)   \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#     PowerShell extensions for NSX for vSphere
#--------------------------------------------------

#This will go trough the list of VM's and apply the tag that is on the same line of the VM
import-csv .\CSV.csv|% {

#Read security tag from a field in the CSV
$st = Get-NsxSecurityTag -name $_.SECTAG

#Read VM Name from a field in the CSV
$vm = Get-Vm -name $_.VMNAME

#Assign security tag to the VM Name
$vm = Get-Vm -name $_.VMNAME|New-NsxSecurityTagAssignment -ApplyTag $st
}

The CSV:

/CSV.csv - The CSV.csv file
VMNAME,SECTAG
Web01,ST-WEB
Web02,ST-WEB
App01,ST-APP
App02,ST-APP
DB01,ST-DB

Executing the Script: 

PowerCLI C:\new> .\script.ps1

Result:

Sddfnmxc-06.png

Sddfnmxc-07.png

Sddfnmxc-03.png

Sddfnmxc-04.png

Sddfnmxc-05.png

Add separate Application based Security Groups (so that the Tier based Security Groups can be nested inside an Application Security Group)

The script /script.ps1:

/script.ps1 - The script.ps1 file
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#-------------------------------------------------- 
# ____   __   _  _  ____  ____  __ _  ____  _  _ 
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )   //    /\___ \ )  ( 
# (__)   \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#     PowerShell extensions for NSX for vSphere
#--------------------------------------------------

#This will create the security groups.
#Note that the tags and groups will need to be UNIQUE as this script does not do error handling.

#Create security groups
New-NsxSecurityGroup -name SG-APP-BOOKSTORE

Executing the Script: 

PowerCLI C:\new> .\script.ps1

objectId           : securitygroup-31
objectTypeName     : SecurityGroup
vsmUuid            : 4223B69E-2DE2-804A-0BE0-FA7307BB2D02
nodeId             : c1afd25d-49fe-4259-bd07-f4508a80d472
revision           : 1
type               : type
root ##b##name               : SG-APP-BOOKSTORE
description        :
scope              : scope
clientHandle       :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false

Result:

Sddfnmxc-08.png

Nest the Tier based Security Groups into the Application Security Group

The script /script.ps1:

/script.ps1 - The script.ps1 file
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#-------------------------------------------------- 
# ____   __   _  _  ____  ____  __ _  ____  _  _ 
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )   //    /\___ \ )  ( 
# (__)   \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#     PowerShell extensions for NSX for vSphere
#--------------------------------------------------

#This will read the security groups from the CSV and will nest the groups into other groups in the CSV.

import-csv .\CSV.csv|% {

#Read the TIER Security Group
$app = Get-NsxSecurityGroup -name $_.SECTIERGROUP

#Read the APP Security Group
$ags = Get-NsxSecurityGroup -name $_.SECAPPGROUP

#Nest one group into another
$ags|Add-NsxSecurityGroupMember -member $app
}

The CSV:

/CSV.csv - The CSV.csv file
APPNAME,SECTIERGROUP,SECAPPGROUP
BOOKSTORE,SG-TIER-WEB,SG-APP-BOOKSTORE
BOOKSTORE,SG-TIER-APP,SG-APP-BOOKSTORE
BOOKSTORE,SG-TIER-DB,SG-APP-BOOKSTORE

Executing the Script: 

PowerCLI C:\new> .\script.ps1

objectId           : securitygroup-31
objectTypeName     : SecurityGroup
vsmUuid            : 4223B69E-2DE2-804A-0BE0-FA7307BB2D02
nodeId             : c1afd25d-49fe-4259-bd07-f4508a80d472
revision           : 2
type               : type
name               : SG-APP-BOOKSTORE
description        :
scope              : scope
clientHandle       :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false
root ##b##member             : member

objectId           : securitygroup-31
objectTypeName     : SecurityGroup
vsmUuid            : 4223B69E-2DE2-804A-0BE0-FA7307BB2D02
nodeId             : c1afd25d-49fe-4259-bd07-f4508a80d472
revision           : 3
type               : type
name               : SG-APP-BOOKSTORE
description        :
scope              : scope
clientHandle       :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false
root ##b##member             : {SG-TIER-APP, SG-TIER-WEB}

objectId           : securitygroup-31
objectTypeName     : SecurityGroup
vsmUuid            : 4223B69E-2DE2-804A-0BE0-FA7307BB2D02
nodeId             : c1afd25d-49fe-4259-bd07-f4508a80d472
revision           : 4
type               : type
name               : SG-APP-BOOKSTORE
description        :
scope              : scope
clientHandle       :
extendedAttributes :
isUniversal        : false
universalRevision  : 0
inheritanceAllowed : false
root ##b##member             : {SG-TIER-DB, SG-TIER-APP, SG-TIER-WEB}

PowerCLI C:\new>

Result:

Sddfnmxc-09.png

Add Distributed Firewall Sections to add in the Distributed Firewall Rules

The script /script.ps1:

/script.ps1 - The script.ps1 file
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#-------------------------------------------------- 
# ____   __   _  _  ____  ____  __ _  ____  _  _ 
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )   //    /\___ \ )  ( 
# (__)   \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#     PowerShell extensions for NSX for vSphere
#--------------------------------------------------

#This will only add 1 new Distributed Firewall Section.
New-NsxFirewallSection FWS-APP-BOOKSTORE

Executing the Script: 

PowerCLI C:\new> .\script.ps1

id               : 1012
root ##b##name             : FWS-APP-BOOKSTORE
generationNumber : 1470349159308
timestamp        : 1470349159308
type             : LAYER3

Result:

Sddfnmxc-10.png

Add in the Tier based Distributed Firewall Rules

The script {{f|/script.ps1}:

/script.ps1 - The script.ps1 file
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#-------------------------------------------------- 
# ____   __   _  _  ____  ____  __ _  ____  _  _ 
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )   //    /\___ \ )  ( 
# (__)   \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#     PowerShell extensions for NSX for vSphere
#--------------------------------------------------

#This will go trough the list of Firewall Rules
import-csv .\CSV.csv|% {

#Collect the varables from the CSV file
$tn = $_.TIERNAME
$sg = get-nsxsecuritygroup $_.SECGROUP
$sec = get-nsxfirewallsection $_.FWSECTION
$fwt = $_.FWT

#Add rule to Firewall section
$sec|new-nsxfirewallrule -name $tn -Action allow -position bottom -appliedto $sg -Tag $fwt -EnableLogging
}

The CSV:

/CSV.csv - The CSV.csv file
TIERNAME,SECGROUP,FWSECTION,FWT
WEB,SG-TIER-WEB,FWS-APP-BOOKSTORE,FWT-TIER-WEB
APP,SG-TIER-APP,FWS-APP-BOOKSTORE,FWT-TIER-APP
DB,SG-TIER-DB,FWS-APP-BOOKSTORE,FWT-TIER-DB

Executing the Script: 

PowerCLI C:\new> .\script.ps1

id               : 1012
name             : FWS-APP-BOOKSTORE
generationNumber : 1470349548233
timestamp        : 1470349548233
type             : LAYER3
root ##b##rule             : rule

id               : 1012
name             : FWS-APP-BOOKSTORE
generationNumber : 1470349548784
timestamp        : 1470349548784
type             : LAYER3
root ##b##rule             : {WEB, APP}

id               : 1012
name             : FWS-APP-BOOKSTORE
generationNumber : 1470349549337
timestamp        : 1470349549337
type             : LAYER3
root ##b##rule             : {WEB, APP, DB}

Result:

Sddfnmxc-11.png

Add in the Application based Distributed Firewall Rules

The script /script.ps1:

/script.ps1 - The script.ps1 file
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#-------------------------------------------------- 
# ____   __   _  _  ____  ____  __ _  ____  _  _ 
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )   //    /\___ \ )  ( 
# (__)   \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#     PowerShell extensions for NSX for vSphere
#--------------------------------------------------



#This will set the variables
$sec = $_.FWSECTION
$arn = $_.APPNAME
$sg = "$_.SECGROUP
$fwt = $_.FWT

#Here we create a new Distributed Firewall Rule with the variables set above
$sec|new-nsxfirewallrule -name $arn -Action allow -position bottom -appliedto $sg -Tag $fwt -EnableLogging

The CSV:

/CSV.csv - The CSV.csv file
APPNAME,SECGROUP,FWSECTION,FWT
BOOKSTORE,SG-APP-BOOKSTORE,FWS-APP-BOOKSTORE,FWT-APP-BOOKSTORE

Executing the Script: 

PowerCLI C:\new> .\script.ps1

id               : 1012
name             : FWS-APP-BOOKSTORE
generationNumber : 1470353361332
timestamp        : 1470353361332
type             : LAYER3
root ##b##rule             : {WEB, APP, DB, BOOKSTORE}

If you want to run the script without an CSV file your can use this:

/script.ps1 - The script.ps1 file
## Author: Iwan Hoogendoorn t:@i1wan m:iwan@i-1.nl
## version 1.0
## August 2016
#-------------------------------------------------- 
# ____   __   _  _  ____  ____  __ _  ____  _  _ 
# (  _ \ /  \ / )( \(  __)(  _ \(  ( \/ ___)( \/ )
#  ) __/(  O )\ /\ / ) _)  )   //    /\___ \ )  ( 
# (__)   \__/ (_/\_)(____)(__\_)\_)__)(____/(_/\_)
#     PowerShell extensions for NSX for vSphere
#--------------------------------------------------

$an = "BOOKSTORE"
$sg = get-nsxsecuritygroup "SG-APP-BOOKSTORE"
$sec = get-nsxfirewallsection "FWS-APP-BOOKSTORE"
$fwt = "FWT-APP-BOOKSTORE"

#Add rule to Firewall section
$sec|new-nsxfirewallrule -name $an -Action allow -position bottom -appliedto $sg -Tag $fwt -EnableLogging

Result:

Sddfnmxc-12.png

Thanks Kyle for pointing out how to work with PowerShell and external CSV's and Anthony for finetuning this. And thanks Nick for this awesome PowerNSX!


Retrieved from "http://www.iwanhoogendoorn.nl/index.php?title=DVS_NIC_teaming_load_balancing_options_and_NSX_interoperability&oldid=80"