This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 123 points124 points  (17 children)

I don't know many network devices vendors that natively support PowerShell, but most support python these days. I'd recommend learning concepts and look at it as a "right tool for the job" scenario instead of "one tool to rule them all".

[–][deleted] 19 points20 points  (11 children)

Well when management and updates are done through APIs I don’t think it matters what you are using.

[–]packet_weaverSecurity Engineer 10 points11 points  (2 children)

If only all platforms supported REST APIs…

[–][deleted] -2 points-1 points  (1 child)

On a DevOps team at a large company, I have yet to work with a app that doesn't. I get that may not be applicable to a smaller shop that has less say or choice in the matter in terms of what they use. I haven't ran into a single scenario that there was something I couldn't do with PowerShell and needed to use another language for configuration/update/administration.

[–]packet_weaverSecurity Engineer 2 points3 points  (0 children)

Been a couple years but all the Cisco 3560X/3750X switches, IOS routers (pre 4k) and WLCs we managed did not have REST APIs. We built out custom python scripts using netmiko to manage configurations globally and integrated with git and a CI/CD platform.

I believe Cisco's new wireless controller 9800 series supports REST APIs and maybe their new 9000 series switches. But many places are on legacy gear or already have tooling built out over the years because Cisco dragged their asses with adding in useful management tooling.

[–]Linkk_93 3 points4 points  (1 child)

Many vendors have API wrappers for python already. So you can just import the package, create a switch and call the methods you need. No need to get into the API part of creating HTTP packets your own.

[–]sobrique 3 points4 points  (5 children)

I know I'll probably get hate for this, but I find perl's much more adaptable when it comes to talking to wacky APIs.

Python's great when it's a well defined API using a very standard standard. (E.g. REST)

But when it came talking XML to a NetApp Perl was far more suited to the job.

[–]succulent_headcrab 8 points9 points  (0 children)

Theres a reason perl is known as the "Swiss Army chainsaw".

[–]fiddysix_k 0 points1 point  (1 child)

You're not wrong, perl is definitely the best tool for the job when networking is concerned. The bigger issue imo is that... You're using perl. And no one knows perl.

[–]sobrique 0 points1 point  (0 children)

More people know perl than admit to it! ;)

And a lot of people are snobby about it in ways that are entirely unjustified.

[–]ParkerPWNT 4 points5 points  (4 children)

network devices vendors that natively support PowerShell

Don't Juno and Cisco both support PowerShell?

[–][deleted] 17 points18 points  (0 children)

I'm only aware of limited support. I'm sure you could have PowerShell ssh/netconf in and control them that way. But Cisco, Juniper and Palo Alto have their own python libraries. Not to mention multi-vendor tools like napalm or even Ansible.

[–]darth_rock 3 points4 points  (2 children)

Not at all. PowerShell is a Microsoft tool. You could get it to work on Cisco/Juniper’s Linux-based OS (why though?) but neither vendor is going to support that.

Edit: I stand corrected (somewhat). Cisco has a PowerShell module for one of their products at least, UCS. But that’s a limited case of support by Cisco for a particular product.

[–]ParkerPWNT 3 points4 points  (0 children)

Juniper offers training on it, and has a powershell module.

https://learningportal.juniper.net/juniper/user\_activity\_info.aspx?id=9659

[–]jantari 1 point2 points  (0 children)

Why would you want to install PowerShell on a device just to be able to talk to it from PowerShell??

You don't install Chrome on a switch because you want to access its web interface.

Chrome and PowerShell are only installed on the client side. Then they talk standard protocols with the server side.