Powershell for Network Engineers

The ever wonderful Ivan Pepelnjak over at ipspace.net asked me back in December to join him for a Webinar on PowerNSX. Given that he was hosting a two part series on ‘Powershell for Network Engineers’ this was pretty great.

As a part of this I am presenting to the audience on PowerNSX! I will also have the wizard Nick Bradford, author of PowerNSX, joining for expert commentary.

So what do you have to lose? It is FREE and you get access to materials afterwards. Be sure to come and see how to use PowerNSX to automate administrative tasks such as

  • Getting comfortable with PowerCLI/PowerNSX
  • Deploying new logical elements
  • Documentation via Visio
  • and other cool examples

I would love to see you there. To find out more Here is the extract from his site.

PowerShell is a very popular scripting and automation language, particularly in environments heavily using Windows Server products. Years ago, virtualization vendors like VMware introduced PowerShell extensions (cmdlets) to give Windows administrators easy access to vSphere API/automation functionality.

Similar extensions are available for Cisco UCS products and VMware NSX; you can also use PowerShell to configure, manage, operate, or automate any device with REST API interface, for example Cisco Nexus switches, Arista data center switches, or Juniper devices.

The PowerShell for Networking Engineers webinar describes the basics of PowerShell (to help you understand the rest of the webinar if you have no prior PowerShell experience) and then focuses on a number of use cases:

Configuring Cisco UCS with UCS PowerTool Suite
Configuring Cisco Nexus and MDS switches, Cisco IOS XE devices and Cisco ASA with REST API
Configuring VMware NSX with PowerNSX.

The webinar will be delivered in two live sessions:

First session on February 13th 2017 will focus on Cisco devices. This session will also include the basics of PowerShell; Second session on February 23rd will describe PowerNSX.

See you then!

Sign up here PowerShell for Networking Engineers – ipSpace.net by @ioshints

Where are my Ports?

When searching for a service that includes a port the UI is not overally helpful. It is currently constrained by scope. Searching port by range is something that is easily done with PowerNSX. This includes values that contain the desired port AND those that are included within a range.

When defining a new service within NSX for vSphere it is possible to define a range such as 1024-40000. This means all ports specified by protocol, TCP or UDP, would be subject to the rule the service is used.

A quick look at HTTPS reveals the following services that have an absolute value of 443.

PS /> get-nsxservice -port 443 | select name

VMware Consolidated Backup
Horizon 6 Default HTTPS Client connection to Connection and Security Servers
Horizon 6 Secure Connection Server to View Composer Service communication
Horizon 6 Connection Server to vCenter server communication

Here we can see our venerable HTTPS servers along with others that use HTTPS. Time to look at the first service in detail. Storing the output in a variable we can dig deeper into VMware Consolidated Backup.

PS /> $https[0]

objectId : application-101
objectTypeName : Application
vsmUuid : 564D7CD5-361E-D806-04FD-953DAFAE7E86
nodeId : 13591f6c-5500-45b9-b160-fc0197059ea5
revision : 1
type : type
name : VMware Consolidated Backup
scope : scope
clientHandle :
extendedAttributes :
isUniversal : false
universalRevision : 0
inheritanceAllowed : true
element : element

PS /> $https[0].element

applicationProtocol value
------------------- -----
TCP 443

[0] allows us to select the first object stored within a variable. We can see the applicationProtocol value is TCP and the value is 443. I’d argue this is a duplicated service and superfluous. If I get my way I hope that one day they are tcp-53 and udp-53 named services along with useful service groups! Back on track.

Using a default install the first search will search services using port 16440. This could be within a range or explicitly defined.

PS /> get-nsxservice -port 16440


Time to store the output within the variable $rpc and look at the first object. We want to explore the element property.

PS /> $rpc[0].element

applicationProtocol value
------------------- -----
UDP 1025-65535

Note that the element value is 1025-65535. The port we searched here is 16440. Using some create regex it is possible to take the existing ranges and determine if the value is greater than 1025 and less that 65535.

Very quick way to determine the ports used within a service or service group.