API Powershell script fails with specific Invoke-WebRequest call

Reply
L0 Member

API Powershell script fails with specific Invoke-WebRequest call

Hi,

I'm trying to create a restful api call against our firewall to map historical QoS Statistics on a certain interface.

I've seemed to come across an issue that's not working and I was hoping you could help.

First question first: the information that I'm trying to get is the QoS Statistics (Network -> QoS -> Statistics)

Has that been exposed by SNMP in any recent PANos versions?


if not here's my issue:

Here's the command I'm trying to use to retrieve information in the API call: show qos interface ethernet1/2 throughput 0

I've verify the syntax to use running the following commands on the FW console:

debug cli on
show qos interface ethernet1/2 throughput 0

I get:

(container-tag: qos container-tag: interface container-tag: entry key-tag: name value: ethernet1/2 leaf-tag: throughput value: 0 pop-tag: pop-tag:)
((eol-matched: . #t) (context-inserted-at-end-p: . #f))


<request cmd="op" cookie="05...34" uid="502"><operations><show><qos>
<interface><entry name='ethernet1/2'><throughput>0</throughput></entry></interface>
</qos></show></operations></request>


2019-12-10 15:15:27
<response status="success"><result><![CDATA[Class 1 0 kbps
Class 2 16590 kbps
Class 3 35469 kbps
Class 4 309 kbps
Class 5 51859 kbps
Class 6 13692 kbps
Class 7 424 kbps
Class 8 0 kbps
]]></result></response>

Class 1 0 kbps
Class 2 16590 kbps
Class 3 35469 kbps
Class 4 309 kbps
Class 5 51859 kbps
Class 6 13692 kbps
Class 7 424 kbps
Class 8 0 kbps


Using the above results as a template I created the API call as follows (and this does work in a web browser):

https://PAN-FW-url/api/?type=op&cmd=<show><qos><interface><entry name='ethernet1/2'><throughput>0</throughput></entry></interface></qos></show>&key=APIkey

Here's the results I get:

<?xml version="1.0"?>
-<response status="success">
<result>Class 1 0 kbps Class 2 61035 kbps Class 3 15621 kbps Class 4 2435 kbps Class 5 7329 kbps Class 6 1693 kbps Class 7 3592 kbps Class 8 0 kbps </result>
</response>

Here's a snippet from the powershell script (the two Uri's are for comparison):

$Uri1 = "https://PAN-FW-url/api/?type=op&cmd=<show><qos><interface><entry name='ethernet1/2'><throughput>0</throughput></entry></interface></qos></show&key=APIkey"
$Uri2 = "https://PAN-FW-url/api/?type=op&cmd=<show><clock></clock></show>&key=APIkey"

$Results = Invoke-WebRequest -Method Get -Uri $Uri1

this one fails with:

Invoke-WebRequest : Illegal parameter [request]
At C:\Program Files (x86)\PAN QoS download traffic.ps1:57 char:12
+ $Results = Invoke-WebRequest -Method Get -Uri $Uri1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand


I've confirm that my basic script is functional by running the second Uri which runs and returns the system time with no issues:

$Results = Invoke-WebRequest -Method Get -Uri $Uri2

The thing that stands out different between the two Uri's as a possible illegal parameter is the <entry name='ethernet1/2'> section, other than that the two are similar in form and function.

So my thinking is it's somehow a syntax error in powershell or the firewall is somehow handling both differently.

I've exhausted the website information and can't seem to find the correct answer so I'm hoping you can help!

Can you suggest the appropriate syntax for powershell for this call or point me in the right direction?

Thanks!
Stan...

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!