April 7th, 2012 § 4 Comments
(This is the second page of an article. Build details below — the, “why?”, is, here.)
We’ll build this on a separate network WITHIN ESXi, without the trunk and external swtich. Your new private network will be completely contained in your ESXi host, available to be added (as a new, “ethX”), to every virtual host.
- In vShere client, click on your host on the left, then the, “Configuration”, tab, and then, “Networking”.
- Click, “Add Networking…”
- Choose, “Virtual Machine”, from the Connection Types (“Next >”)
- Choose, “Create a vSphere standard switch”, radio button (“Next >”)
- Label your new network, “GNS3 Network”, vlan, “None (0)”. (“Next >”)
- and, “Finish”.
- Click the, “Properties”, link on your new switch (ie. “vSwitch1″)
- Click, “vSwitch”, in the configuration list, then, “Edit…”.
- Click on the, “Security”, tab and change, “Promiscious Mode”, to, “Accept”, then OK. (“Yes” to warning)
- Close out and you are set to add new nics to your new virtuals.
Explanation: You now have a virtual network for use between virtual hosts. Your traffic will not leave your virtually host machine. Why promiscious mode for our new switch? Remember you are running virtual routers on a virtual machine. Promiscious mode turns your switch into a… a make shift hub, where arp packets are not stopped at a switch/bridge port or virtual machine. Although the ESXi switch may not think that Cisco device is on top of virtual host (running behind another bridge in your Linux host), it is, we have to let the ARPs back in. Without it, arp responses will not get back to your Cisco, thereby not allowing communication.
Want to use a trunk, like the image above? (not needed) If you want to trunk externally, goto the, “Properties”, link for your standard ESXi switch (ie. “vSwitch0″) and then, Add…”, another port group assigned to a different vlan. Then assign nics to your virtuals. Remember to set the new port group to, “Accept”, Promiscious mode!
- Build a single Linux 6 machine on a ESXi host, or your virtual platform of choice, and add a secondary nic to your virtual to point to your new, “GNS3 Network” , switch. Optionally, clean up unneeded applications by disabling them (chkconfig xyz off), “yum update”, and reboot. I chose, “minimal”, install – so you may have some of the utils below.
- Install utilities for tunnelling, bridging, X forwarding, and GNS3 compatibility.
[root@centos6-1 ~]# yum install tunctl bridge-utils openssh-clients telnet xterm PyQt4 xauth xorg-x11-fonts* sip-devel
- Create the bridge (br0) and tap (tap0).
[root@centos6-1 ~]# brctl addbr br0
[root@centos6-1 ~]# tunctl -t tap0
- Add both GNS3 network ethernet device (eth1) and tap (tap0) to the bridge (br0).
[root@centos6-1 ~]# brctl addif br0 eth1
[root@centos6-1 ~]# brctl addif br0 tap0
- Set GNS3 network ethernet device (eth1) and tap (tap0) in promiscuous mode and turn them up
[root@centos6-1 ~]# ifconfig eth1 promisc up
[root@centos6-1 ~]# ifconfig tap0 promisc up
- IP and turn up your bridge on the GNS3 network.
[root@centos6-1 ~]# ifconfig br0 10.0.0.2/24 up
From this point, if you were to duplicate this machine, you would be able to ping from one 10.0.0.0/24 interface to another over your new GNS3 network.
The GNS3 installation documentation is probably best left to the authors at GNS3.net. But for my lab I will say, all I had to do was download GNS3 and Dynamips to get my lab up and running. I extracted and opened GNS3 (“python gns3″). Opened, “Preferences”, set my path to the downloaded Dynamips binary file (in my case, “/root/dynamips-0.2.8-RC3-community-x86_64.bin”), and then loaded my IOS images with the, “IOS images and hypervisors”, menu option.
Since you installed, “xauth”, and, “xorg-x11-fonts*”, back during your CentOS build, you should be able to, “ssh -X”, to the new virtual machine and forward GNS3 back. (“ssh -l root centos6-1 -X”)
What we’ll do next is setup the dreaded GNS3, “Cloud”, to get any connected router connected to your new, “tap0″, interface on your Linux host. Ok, it’s not really, “dreaded”, it’s actually easy to set up.
- From the GNS3 menu on the left side, drag, “Cloud”, into your network workspace. You will have a new cloud appear, normally labelled, “C1″.
- Right-click on the new C1 cloud and, “Configure”.
- Click, “C1″, from the left pane of new, “Node Configurator”, window.
- On the, “NIO TAP”, tab, type in, “tap0″, and click, “Add”. (“nio_tap:tap0″, will appear in the list below)
- Click, “OK”
Now we get into working with GNS3, likely best suited to the GNS3 documentation authors, but…
We have a cloud sitting on an empty network. That cloud is going to be our conduit to our Linux machine. Now we have to connect a router to it. Drag a router, from the same family you installed an IOS image for (ie. 7200), to your workspace. To, “physically”, connect to your cloud, click the, “Add a link”, button, and drag a new virtual ethernet/fiber/virtual-cups-n-string connection from your router to the new cloud. You will now have a new network that looks a lot like the first image of these articles – A cloud (c1), a router (r1), and a link line between the two.
If you right click on the new router, and click start and then, “console”, you are on your way. Turn up an interface and ping your br0 interface back on your virtual machine.
R1#sh int desc
Interface Status Protocol Description
Fa0/0 admin down down
Gi1/0 admin down down
Enter configuration commands, one per line. End with CNTL/Z.
R1(config-if)#descr “Connection to tap0 cloud”
R1(config-if)#ip address 10.0.0.4 255.255.255.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.6, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms
To reach my initial goal for this project, I duplicated the VMware virtual image for my CentOS6-1 machine (such as explained here by the folks at dedoimedo.com), and I could ping from one Cisco router to another.
Take each step as it comes, one at a time. Signal flow is your friend.
If you have landed on this page, drop me a note! It’s great to hear from people that might read these articles and find some use in them. If not useful, what do you think would be? I’ll try those!
April 7th, 2012 § Leave a Comment
When I learn new things I would prefer to see things in action rather than in a book. So, when I was studying for my CCNA certification last year, I needed to find a way to push some packets around myself without going broke renting or buying network gear. That’s where GNS3, the network simulator, came into play.
GNS3 is a graphical network simulator for Windows, Mac, and Linux that allows you to setup full blown networks on your personal PC. The power of GNS3 lies in its Qt based graphical interface and its use of Dynamips, a emulator thats boots true Cisco IOS images.
Once running, you can setup a graphical layout of a network, such as you may do with a drawing app like Visio or Dia. But, unlike a two dimensional drawing program, you can then start and run your gear right from within the interface (cool!). Click on the console button and you just might think you were sitting in the datacenter with your laptop and a rollover cable. All this without the cold chills from all those overzealous datacenter HVAC units.
I guess for most network troubleshooting problems you could just keep all of your new virtual routers isolated on one PC. But I wanted to leverage the free cpu cycles of some virtual machines here and also have the ability to connect my new virtual network to external FTP and TFTP servers for maintenance. VMware ESXi (or KVM, VirtualBox, etc) and Linux networking to the rescue.
A look at the virtual LAB…
At the core of this installation is GNS3 running on CentOS 6.2 instances on top of a VMware ESXi 5 machine.
Although this is all a little, “screwy”, that’s actually the name of my ESXi host, an ESXi hypervisor running on a HP i5 Intel. “Shorty”, is a Cisco 2924xl, with a trunked interface to, “Screwy”. But before you say, “I don’t have another switch or a trunk…”, this all can be done within the virtual environment of ESXi or Linux KVM or Virtual Box. The trunked interface (or non-trunked for that matter) was just setup so I can add more, and more, and more, virtual hosting machines to the mix. All for the cause of world virtual domination! Virtualize! ah-hem.
Now, as ANOTHER aside. I want to show you why this works, not just how to set it up. I’m not an expert but hopefully this will at least help one person take a different look at things. (wish more people did this – explain how they figured it out) (If you want the, “how”, scroll past this paragraph). I try to think with, “Signal Flow”, in mind. How are my packets getting from one place to another and what layers , of how things communicate (MACs, IPs, protocols (ftp,icmp,etc)), are important.
In my test of final functionality for this build, I wanted to be able to ping router1 on CentOS6-2 with router1 on CentOS6-1. Once the ping utility on the Cisco router sent our icmp packet onto the wire, it only had to deal with up to layer 3 for its journey. The network layer of the TCP/IP model.
I pushed the packets, checking at each step using tools like, “tcpdump”, to investigate if my layer 2 (MAC/ARP) and Layer 3 (IP) packets were flowing. (Try, “tcpdump -i eth1″ (cntrl-C to get out)). Was I getting packets to the first, “tap0″, interface from the source router1? (tcpdump -i tap0) No? ..check my cloud configuration in GNS3. Bascially, check each step, open each door as you come to it if it is not open already.
Some helpful hints/utilities:
- tcpdump (ie. “tcpdump -i eth1 icmp”, “tcpdump -i tap0 arp”, or “tcpdump -i eth1 host 10.0.0.4″)
- iptables -F (Yes, might be best to flush iptables rules and come back later to insert appropriate rules)
- arp -av (do we have mac addresses assigned to IPs or did the ARP for MAC<>IP not get through?)
- brctl showmacs <bridge> (ie. brctl showmacs br0, Does the bridge know the mac<>ip?)
- ifconfig -a (are your interfaces UP!?) & ipconfig eth1 promisc (we’ll get to this)
- brctl show (are both your interfaces, “tap0″, and, “ethX”, attached to the bridge?)
Ok, do you want to build something like this?
Onto the GORY DETAILS…