![]() ![]() As per the screenshot below, we can confirm that “Network Adapter” maps to e0a: Now look at the “MAC Address” field and then marry up the MAC there to the output from the command used above. Then in Workstation, select a Network Adapter and click “Advanced…”. Issue the following command:Ĭdot-clust::> network port show -fields mac However, you don’t have to take my word for it. Well, from my testing it appears as though they’re bound alphabetically: Instead each subnet has its own discreet port.īut 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? 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.īelow is the way in which I’ll set up the mappings:īy using this mapping we avoid having all three subnets sharing a single VMnet interface. 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. Doing so enables us to segment off the ports into their functional groups. 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. Mgmt1 up/up 10.0.0.9/24 cdot-clust-02 e0c trueĪs per the above outputs, we need a minimum of three subnets:įor 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). Logical Status Network Current Current Is The above information can be found in the output of the following commands: LIF Types: Node Management & Cluster Management.NetApp Network PortsĪt the time of writing the simulator (CDoT 8.2) has four network ports: 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. This object can then be connected to your GNS3 equipment and/or other clouds, enabling the devices to communicate with one another.Īs 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. 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. OverviewĪs 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. 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. Today I’m going to cover how you can add another piece of virtual equipment to your lab - the NetApp Simulator. Guide: Building a Self-Contained Virtual Steelhead Lab.Virtual Equipment + Physical Equipment = Big Lab.Connecting Your PC to Your Virtual GNS3 Routers.I have written a few pieces on making the most out of your virtual and physical labs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |