Closed dumlutimuralp closed 6 years ago
I have tested this with "-service (Get-NsxService ICMP Echo)" or "-service (Get-NsxSerice Http)" as well... Still the same behaviour
Thanks @hakkurt for finding the resolution to this. I should have used FirewallSectionName parameter. However since I did not receive any kind of error it was really challenging to identify the missing part.
$FirewallSection = new-NsxFirewallSection $FirewallSectionName $Ruleinbound = get-nsxfirewallsection $FirewallSectionName........
Run the LHS of the pipeline in your original comment. (Get-NsxFirewallSection $FirewallSection) and I bet it produces no output because you are passing xml rather than a name to the first positional argument (bound to the name parameter). This is by design.
Both patterns for dealing with a lack of content (to either a) produce a non terminating error (eg: Get-VM), or b) produce no output (eg: Get-ChildItem) ) are common in PowerShell.)
PowerNSX was deliberately designed to follow the latter pattern (both approaches have pro's and cons). We can debate the appropriateness of that choice later, but know that it is deliberate.
Now consider your whole pipeline Get-Section | New-FirewallRule... If Get-Section produces no output the RHS of the pipeline is not executed. This is standard PoSH behaviour. No error.
Hope this helps. It does place the emphasis on you catching empty returns if its important to you.
Also (somewhat pedantically I admit :) ) - technically, it is the behaviour of Get-NsxFirewallSection that you have issue with, not New-NsxFirewallRule.
@nmbradford Thanks for your response. I agree that it is fully about "GetNsxFirewallSection" . Still progressing on learning PowerNSX. (without a solid foundation on PowerCLI to be honest) I tried to look for examples in PowerNSX and also on the internet and yes, apparently I overlooked. When I issued "(Get-NsxFirewallSection $FirewallSection)" it provided the below output :
id : 1027 name : Day 3 Ops generationNumber : 1518619711370 timestamp : 1518619711370 type : LAYER3
No problem, although a correction, when you issued $FirewallSection
(Note the absence of the Get-NsxFirewallSection cmdlet) you got that output. Should you have actually issued Get-NsxFirewallSection $FirewallSection
you would have got no output. Give it a try... ;)
More generally, when in doubt - dont build long pipeline, or nest operations like -service (Get-NSxService http)... break the operations down into the simplest components, and test them individually.
So - something like this would have shown your issue very early :
PS C:\> Get-NsxFirewallSection BookStore
id : 1004
name : Bookstore
generationNumber : 1517203120671
timestamp : 1517203120671
type : LAYER3
PS C:\> $FirewallSection = Get-NsxFirewallSection BookStore
PS C:\> $FirewallSection
id : 1004
name : Bookstore
generationNumber : 1517203120671
timestamp : 1517203120671
type : LAYER3
PS C:\> Get-NsxFirewallSection $FirewallSection <-------------- Here is your problem. No output
PS C:\> $test = New-NsxService -Name testing -Protocol TCP -port 8123
PS C:\> New-NsxFirewallRule -Section $FirewallSection -Service $test <------------- you dont have to use the pipeline, its a convenience, you can specify the section as an arg
The correct way to use the pipeline in your original attempt would be as follows :
$FirewallSection | New-NsxFirewallRule ... <------- Note the lack of Get-NsxFirewallSection. We already have the object representing the section stored in $FirewallSection
When trying to add a rule to an existing session (I am using the syntax below) it does not generate any error but it also does NOT create the firewall rule. This is NSX 6.3.5.
get-nsxfirewallsection $FirewallSection | New-NSXFirewallRule -Name "TestICMPRule" -Source $Sg -Service "ICMP" -Action allow -ApplyToDfw:$false -AppliedTo $Sg -position bottom
_PS C:\Scripts> $FirewallSection
id : 1023 name : DumluOps generationNumber : 1518541138761 timestamp : 1518541138761 type : LAYER3
PS C:\Scripts> $Sg
objectId : securitygroup-33 objectTypeName : SecurityGroup vsmUuid : 42109E01-B2C3-073F-963D-9308000FAF56 nodeId : 8b5795bf-3e0c-44ba-a91b-6790ffd6c4de revision : 1 type : type name : Dumlu description : scope : scope clientHandle : extendedAttributes : isUniversal : false universalRevision : 0 inheritanceAllowed : false_