Monday, January 26, 2015

Connecting the NetApp Simulator to your Virtual and Physical Labs

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. 

Overview

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. 

As demonstrated in this guide, by binding the NetApp simulator's ports to a cloud we're able to get the simulator to communicate with a Cisco router. The router could easily be replaced with or used in conjunction with any other piece of equipment, whether it be a Virtual Steelhead, Palo Alto firewall, F5 load balancer, ASA firewall, PC, etc. The possibilities are endless.

NetApp Network Ports

At the time of writing the simulator (CDoT 8.2) has four network ports:
  • e0a:
    • Port Type: Cluster
    • LIF Type: Cluster
  • e0b:
    • Port Type: Cluster
    • LIF Type: Cluster
  • e0c:
    • Port Type: Data
    • LIF Types: Node Management & Cluster Management
  • e0d:
    • Port Type: Data
    • LIF Type: None
The above information can be found in the output of the following commands:

cdot-clust::> network port show
                                      Auto-Negot  Duplex     Speed (Mbps)
Node   Port   Role         Link   MTU Admin/Oper  Admin/Oper Admin/Oper  
------ ------ ------------ ---- ----- ----------- ---------- ------------
cdot-clust-01
       e0a    cluster      up    1500  true/true  full/full   auto/1000
       e0b    cluster      up    1500  true/true  full/full   auto/1000
       e0c    data         up    1500  true/true  full/full   auto/1000
       e0d    data         up    1500  true/true  full/full   auto/1000
cdot-clust-02
       e0a    cluster      up    1500  true/true  full/full   auto/1000
       e0b    cluster      up    1500  true/true  full/full   auto/1000
       e0c    data         up    1500  true/true  full/full   auto/1000
       e0d    data         up    1500  true/true  full/full   auto/1000

8 entries were displayed.


cdot-clust::> network interface show
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cdot-clust
            cluster_mgmt up/up    10.0.0.7/24        cdot-clust-01 e0c     true
cdot-clust-01
            clus1        up/up    169.254.237.84/16  cdot-clust-01 e0a     true
            clus2        up/up    169.254.116.159/16 cdot-clust-01 e0b     true
            mgmt1        up/up    10.0.0.8/24        cdot-clust-01 e0c     true
cdot-clust-02
            clus1        up/up    169.254.246.226/16 cdot-clust-02 e0a     true
            clus2        up/up    169.254.77.253/16  cdot-clust-02 e0b     true
            mgmt1        up/up    10.0.0.9/24        cdot-clust-02 e0c     true
7 entries were displayed.


As per the above outputs, we need a minimum of three subnets:
  1. Cluster
  2. Management
  3. Storage
For this example I chose to use 169.254.0.0/16 for cluster traffic, 10.0.0.0/24 for management traffic and 10.0.1.0/24 for storage traffic (which has not been configured at this stage).

Port Mappings

Now that we've got an understanding of the simulator's ports as well as the subnets we'll be using, it's time to map these ports to our VMWare Workstation adapters. Doing so enables us to segment off the ports into their functional groups. For example, e0a and e0b should have an adapter which is dedicated to cluster traffic, e0c should have an adapter which is dedicated to management traffic and e0d should have an adapter which is dedicated to storage traffic.

Note: While this setup would work even if we bound all of the simulator's ports to a single Workstation VMnet interface, it is better practice to segment them off into their functional groups as it replicates what is seen in production environments.

Below is the way in which I'll set up the mappings:
  • e0a & e0b - VMnet1 (169.254.0.0/16)
  • e0c - VMnet0 (10.0.0/24)
  • e0d - VMnet2 (10.0.1.0/24)
By using this mapping we avoid having all three subnets sharing a single VMnet interface. Instead each subnet has its own discreet port.

But wait, given that the Workstation network interfaces all have generic "Network Adapter" names (as per the screenshot below), how do we know which simulator port each of them are bound to?


Well, from my testing it appears as though they're bound alphabetically:
  • Network Adapter - e0a
  • Network Adapter 2 - e0b
  • Network Adapter 3 - e0c
  • Network Adapter 4 - e0d
However, you don't have to take my word for it. Let's confirm it, just to be sure. Issue the following command:

cdot-clust::> network port show -fields mac    
node          port mac              
------------- ---- -----------------
cdot-clust-01 e0a  00:0c:29:63:39:0a
cdot-clust-01 e0b  00:0c:29:63:39:14
cdot-clust-01 e0c  00:0c:29:63:39:1e
cdot-clust-01 e0d  00:0c:29:63:39:28
cdot-clust-02 e0a  00:0c:29:33:2b:84
cdot-clust-02 e0b  00:0c:29:33:2b:8e
cdot-clust-02 e0c  00:0c:29:33:2b:98
cdot-clust-02 e0d  00:0c:29:33:2b:a2
8 entries were displayed.


Then in Workstation, select a Network Adapter and click "Advanced...". Now look at the "MAC Address" field and then marry up the MAC there to the output from the command used above. As per the screenshot below, we can confirm that "Network Adapter" maps to e0a:


VMnet Configuration

In order to connect your VMnet interfaces to GNS3, you must use Workstation's "Connect a host virtual adapter to this network":


Doing this results in a new network adapter appearing in your network adapter list, as per the image below. It is this adapter which you will bind to the cloud object in GNS3 which will enable your GNS3 devices to communicate with your simulator.

As I'm using VMnet0 for this example, my GNS3 topology will have access to my management (10.0.0.0/24) subnet. Further to this, as I've enabled the "Use local DHCP service to distribute IP address to VMs" option, the newly created adapter will receive an IP address on the management subnet. This will allow me to use SecureCRT to SSH into the cluster, so I no longer have to use Workstation's console.


GNS3 Connectivity

We're almost there! Only a couple of steps to go. Hang in there :)

Drag a router and a cloud into the topology pane, and then bind the "VMware Network Adapter VMnet0" adapter to the cloud:


Next, connect the router and cloud together, and then fire up the topology:


Finally, configure the router with an IP address on the management subnet and you're done:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int f0/0
R1(config-if)#no shut
R1(config-if)#ip add 10.0.0.1
*Mar  1 00:02:03.659: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:02:04.659: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R1(config-if)#ip add 10.0.0.1 255.255.255.0
 

To confirm that the setup is working correctly, let's run a ping test:

R1(config-if)#do ping 10.0.0.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/211/1016 ms
 

Finally, to test all seven layers of the OSI model, let's SSH to the simulator from the router:

R1(config-if)#do ssh -l admin 10.0.0.7

Password:
cdot-clust::>


And there you have it! Full connectivity between the simulator and GNS3. As mentioned above, you can easily replace the router with any other device, whether it be physical or virtual.

Update: See my Trunking VLANs between the NetApp Simulator and GNS3 post for more information on integrating the NetApp simulator with GNS3.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

No comments:

Post a Comment