In Part 2 of this series we made our first API call and received over 200 lines of XML as a result. The reason why we received so much output is because we didn’t remove any
desired-attributes and therefore the call retrieved about 90 pieces of information. When you multiply that by the number of queries we ran (2), you get 180 pieces of information being requested.
This post will discuss why you should limit your queries to only the pieces of information you’re interested in. It will also cover how you can use ZExplore to convert its XML configuration to languages such as Python, Perl and Ruby.
Picking up where I left off in Part 1 of this series, let’s continue our exploration of ZExplore :)
In part 1 I touched on the fact that the API documentation can be a little confusing when it comes to mandatory fields. Unfortunately the same is true for ZExplore. However, NetApp’s documentation explains it well:
Red colored arrows indicate mandatory parameters whereas Blue colored arrows indicate optional parameters.
Note: In some APIs when either one of the two input parameters is required, both these input parameters are marked by “Blue” color arrow and not “Red”.
As I mentioned in my previous post, by doing this NetApp avoids confusing users who might otherwise try to set both parameters if they were both marked as required.
If you’re a regular reader of this blog, you’ll see that I’ve been posting about automation and Python quite a lot recently. The reason being that it’s not only fun, but I feel it’s the way of the future. But I digress…
The reason for this post is to discuss my recent experience with NetApp’s APIs. As I got off to a pretty slow start (which I feel was due to lack of documentation), I’ll also provide setup and usage guidance in the hopes that you can get up and running sooner than I did.
In my previous post Connecting the NetApp Simulator to your Virtual and Physical Labs, I explained the steps you need to follow in order to connect the NetApp simulator to GNS3. By doing this you’re able to connect the simulator to Cisco routers, Virtual Steelheads, ASA firewalls, F5 load balancers… to put it simply, just about any physical or virtual piece of equipment you can think of! This entry builds on that post and demonstrates how, with just a few extra steps, you’re able trunk VLANs between the simulator and GNS3.
To demonstrate its capabilities, I’ll explain three different methods GNS3 is able to handle the VLANs which are passed to it by the simulator. (Note that additional methods become available when you integrating other appliances into GNS3. For example, you could have the simulator hand off the VLANs to a Palo Alto firewall).
Creating VLANs & LIFs on the Simulator
Let’s begin by configuring the simulator side. We’ll need to create the VLANs and LIFs which we plan to make accessible to the device(s) in GNS3. For this example I’ll configure them in the following way:
- e0d-20 = 10.0.20.9 /24
- e0d-30 = 10.0.30.9 /24
- e0d-40 = 10.0.40.9 /24
I have written a few pieces on making the most out of your virtual and physical labs. These include:
Today I’m going to cover how you can add another piece of virtual equipment to your lab – the NetApp Simulator.
Note: As there are plenty of NetApp Simulator documents, blog posts and forum discussions, I won’t be covering things like licence keys, initial configuration, etc.
As with my previous guides, GNS3’s “cloud” object is used to enable the simulator to connect to the rest of the lab virtual and physical lab. For those who are unfamiliar with the cloud object, it allows you to bind your network adapters (both physical and virtual) to an object inside of your GNS3 topology. This object can then be connected to your GNS3 equipment and/or other clouds, enabling the devices to communicate with one another.