Saturday, December 1, 2012

Virtual Equipment + Physical Equipment = Big Lab

I have posted a few entries covering GNS3 and how you can use it to help you with your studies. And, in the "Connecting Your PC to Your Virtual GNS3 Routers" I showed you how it was possible to break your GNS3 routers out of the Virtual world and bring them in to the Physical world. In this post, I am to show you how I used this technique in my lab to give me a rather nice setup.

Figure 1 shows the equipment I own at the time of writing. I don't really use the 2610 as GNS3 fulfills all of my router needs. I do use the 2509 though as a console router for the rest of my equipment.

Figure 1


You may be wondering why I need four physical machines... well, at least the wife does ;) My explanation can be found in Figure 2.

Each physical machine has a Virtual Machine (VM) installed. These VMs are bound to their own physical NICs. This is why each machine has a minimum of three NICs. The reason why one machine has five NICs is because it also hosts GNS3. Two of its NICs are assigned to the job of connecting virtual routers to the physical network.


Figure 2


Figure 3 shows how each of the physical NICs are mapped.


Figure 3


Figure 4 tries to explain (or should I say justify?) why I have five monitors.


Figure 4


Finally, Figure 5 shows a basic topology which can be created with the above equipment.

Figure 5

Update

For a more detailed, step by step guide on how to achieve the above, please see my new website.

Update: Where to from here?

My lab has increased in size quite a lot since this post was first written (see the photos below). Even more exciting though is the purchase of my new PC purchase. With this PC I will be able to set up a few ESXi hosts, Nexus 1000V VSMs and VEMs. This will enable me to play around with vCenter, vMotion, VSM High Availability, etc. This, in conjunction with the additional VMs I will be able to create inside the ESXi hosts, will allow me to create even larger topologies than before. I can't wait to get started! :)

The lab as it stands now:





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.

New PC - Nexus 1000V here I come!

As per my previous post, I have been in the market for a new PC for a little while now and have finally made a purchase. The specs can be found below.


CPU: Intel Core i7 3770
GPU: Sapphire Radeon HD7850 2GB OC V2
Mobo: ASRock Z77 Extreme6 Motherboard
RAM: G.Skill Ares F3-1600C10D-16GAO 16GB (2x8GB) DDR3
Case: CoolerMaster HAF 912 Advanced
PSU: Antec High Current Gamer 520W Power Supply HCG-520
HDD1: Samsung 830 Series 128GB SSD
HDD2: Samsung 830 Series 128GB SSD
HDD3: Seagate Barracuda 2TB ST2000DM001
DVD: Samsung SH-224BB/BEBS SATA DVDRW Drive OEM
Screen: 27" Acer V273HL Acer V273HL FHD LED Backlight Monitor

Total Price: About $1,750

The reason for I opted for the Intel Core i7 3770 instead of the 3770K (as was originally planned) is due to the 3770's VT-d support. It was a difficult giving up the overclocking capabilities provided by the 3770K, however, as virtualisation is one of my primary goals I knew which way I had to go.

In regards to the GPU, I like to game from time to time so thought I'd treat myself with a half decent graphics card.

In regards to the two SSDs - as I plan to use several VMs concurrently, I didn't want my HDD to become a bottleneck. By having two SSDs I will be able to spread my VMs across both of them.

In regards to the 16gb of RAM, I thought I'd give it a try to see how well it performs but will most end up purchasing another 16gb as virtual machines tend to consume a heck of a lot of RAM.

Anyway, now that I have my new machine, it is time to get started adding a Nexus my lab!

Before I end this post I just want to throw out a huge thank you to the guys over at PCCG. They provided me with excellent customer service, were very friendly, and had the machine ready to go within 24 hours. Their prices were also one of the best I could find. I can't recommend them enough.


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.

Thursday, November 8, 2012

Download & Install Nexus 1000v For Free!

Cisco has recently announced that the Nexus 1000v can be downloaded and installed free of charge. This is great news for those of us who use VMware products, and especially great news for those of us who have home labs and can't afford to spend large sums of money on licences.

Using this excellent guide, you will be able to build an entire virtualised setup from the ground up in no time at all.

However, if your like me and your PCs are 7+ years old, it is time to upgrade. I've been doing a bit of research, and this is what I have come up with so far:

CPU: i7 3770k
Mobo: Asrock Z77 Pro4
GPU: Gigabyte AMD Radeon HD7850 OC 2GB GV-R785OC-2GD
RAM: G.Skill Ares 16GB (2x8GB) DDR3-1600
SSD: Plextor M5S 256GB
HDD1: Seagate Barracuda 2TB (ST2000DM001)
PSU: Antec High Current Gamer 520W
ODD: DVD burner

All that's really left is to choose a case and buy the above mentioned bits and pieces. As per the photos of my lab (which can be seen at the bottom of the "About Me" page), I don't need any additional keyboards, mice or monitors, which is why they these components are missing from my shopping list above.

Once I have purchased the PC and have got it all up and running, I will post another blog entry describing the process and any gotchas I may have hit along the way.

Update

I have purchased my new PC. The specs have changed quite a lot since this post. To see them, please see this blog entry.

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.

Saturday, September 1, 2012

Saving GNS3 Topologies

A lot of people (myself included) have had trouble saving their GNS3 topologies properly. You think you've done it properly, only to find the next time you open the topology, some or all of the devices have lost their configurations. This can be very frustrating, especially if it was a large and complex network.

The solution I found, which is most probably overkill (but it works every time so I'm happy), is to do the following:

  1. When you open GNS3, a popup window will appear saying "New Project". Make sure the "Save IOS startup configuration" box is ticked, then, choose a location where you'd like to store the project files.
  2. Once you have done that, you are free to create and configure your GNS3 topology. Once your done, issue the "copy run start" command on every router.
  3. While the the topology is still running, click "File", then click "Save".
  4. Again, while the topology is still running, close GNS3 (either by clicking the "X" at the top right hand corner of the screen, or by going to "File", then "Quit". GNS3 will then say "Would you like to save the current topology?" - Click "Yes".
And that's it! If you follow this procedure you will find that your topology, and your configurations, are successfully saved every time.

When you use GNS3 to open a previously saved topology, follow steps 2 through 4 above to ensure any changes you make to the topology and/or router configurations are saved properly.

Changing Names

After performing the above steps, you will find that GNS3 will create ".cfg" files in your project's directory. Each ".cfg" file will map to each device in your topology. For example, if you have R1, R2 and R3, in your topology, the ".cfg" files will be R1.cfg, R2.cfg and R3.cfg.


Because of this, a problem will occur if you decide to change the routers' names in the GNS3 topology window. For example, if you change the above mentioned routers to Spoke, Internet and Core, these routers will now look for Spoke.cfg, Internet.cfg and Core.cfg. if they're not found, GNS3 will create blank copies. So, instead of keeping their original configuration, each device will have no configuration at all.

A simple fix would be to go in to your project directory and rename each of the old ".cfg" files to their new device names.

For example:
  • Delete the blank Spoke.cfg, Internet.cfg and Core.cfg files.
  • Rename R1.cfg to Spoke.cfg
  • Rename R2.cfg to Internet.cfg
  • Rename R3.cfg to Core.cfg
Once you have done that, restart your topology and all will be well again :)

Note: Just to reiterate, the name changes above refer to GNS3's topology window, not the Cisco "hostname" command. If you change the router's name by using the "hostname" command, you do not need to make any of the above mentioned changes.

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.

Friday, February 17, 2012

MTU Vs MSS - Part One

 Have you ever seen the below configuration and wondered what these commands do? And why the MSS value always seems to be 40 bytes lower than the MTU?

interface Dialer1
 ip mtu 1440
 ip tcp adjust-mss 1400


 Well, over the course of my next couple of blog entries, I plan to tell you all about them.

From my countless number of Google searches, the best information I could find was:
  • TCP MSS operates at Layer 4. It is 40 bytes lower than the IP MTU as it does not take headers in to consideration (20 byte IP and 20 byte TCP).
  • IP MTU operates at Layer 3. It is the maximum size a packet can be before it needs to be fragmented (or dropped if the df-bit is set).
  • Ethernet MTU (Layer 2) - 1500 bytes, excluding the header and trailer.
This is good information, but it doesn't tell you why you need to set both the MSS and the MTU.

Using Wireshark, and speaking with the helpful people over at Whirlpool, I was able to get a deeper understanding of how these two come together.

As the syntax of the command suggests, the "ip tcp adjust-mss" command only works for TCP connections. When applied to a router's interface, the router will monitor this interface's incoming and outgoing traffic, looking for SYN packets (which is where hosts define their MSS). When it sees a SYN packet, it will automatically change the MSS field to the size that you specified using the command above. When the receiving host receives the SYN packet, it will see the new MSS that was set by the router, and will reply with an MSS equal to or less than the one specified by the initiating host.

(Just to reiterate, as the router inspects both incoming and outgoing traffic, it doesn't matter whether the connection is initiated by a local host or a remote one, the SYN packet will still be altered).

Note: If the  "ip tcp adjust-mss" command is also set on the remote end of the connection, the lower MSS will be used.

To put it simply, the "ip tcp adjust-mss" command is used to prevent "blackhole routing".

By using this command, you can ensure that your packets are not being fragmented in transit. Fragmentation is far from ideal as it can lead to things like delayed packet delivery and packet drops.

Speaking of fragmentation, this is where the IP MTU comes in to play. When applied to an interface, the IP MTU basically states that packets leaving this interface need to be equal to, or less than the specified size. If they are larger, they will be fragmented. This is why the "ip tcp adjust-mss" command is necessary. By setting the MSS to 40 bytes below the MTU, you ensure that all of the packets sent from your network will not be fragmented by your routers.

Unfortunately though, setting the IP MTU and the MSS does not guarantee your packets won't be fragmented or dropped on their way to their destination. This is because each router your data passes on its way to the destination will be configured differently, and may have different MTU sizes on their interfaces.

If you find your having connectivity issues, there are tools you can use like mturoute.exe that will tell you the MTU of each hop between you and the destination network.

Finally, the Ethernet MTU. This is the MTU that your Layer 2 traffic uses. Setting this to a higher value (e.g 9000 bytes for Jumbo Frames) allows you to send more data per frame, meaning that you've got less overhead per packet. This enables you to deliver much larger amounts of data in shorter periods of time.

And that's it for this entry :) In my next blog post I'll delve deeper in to MSS and include some packet captures to demonstrate how it works.

Update: MTU Vs MSS - Part Two has now been published.

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.

Friday, February 10, 2012

GNS3 IOS Memory Errors - Solution


In a previous post I talked about GNS3 memory errors that produced the below log messages when certain IOS images were used and NATing was enabled:

R1(config)#int fa0/0
R1(config-if)#ip nat inside
% NBAR ERROR: parsing stopped
% NBAR Error : Activation failed due to insufficient dynamic memory
% NBAR Error: Stile could not add protocol node
%NAT: Error activating CNBAR on the interface FastEthernet0/0
*Mar  1 00:00:27.307: %SYS-2-MALLOCFAIL: Memory allocation of 10260 bytes failed from 0x62912920, alignment 0
Pool: Processor  Free: 13696  Cause: Memory fragmentation
Alternate Pool: None  Free: 0  Cause: No Alternate pool
 -Process= "Exec", ipl= 0, pid= 94,  -Traceback= 0x61488C44 0x60015E58 0x6001BDB8 0x6001C410 0x636726CC 0x62912928 0x628F12D8 0x628F6E7C 0x628F25B4 0x628F7104 0x628F25B4 0x628F257C 0x628F4F90 0x628F25B4 0x628F2778 0x62925C0
*Mar  1 00:00:27.311: %NBAR-2-NOMEMORY: No memory available for StILE lmalloc,  -Traceback= 0x61488C44 0x62912944 0x628F12D8 0x628F6E7C 0x628F25B4 0x628F7104 0x628F25B4 0x628F257C 0x628F4F90 0x628F25B4 0x628F2778 0x62925C08 0x6293066C 0x6291D81C 0x6293ABBC 0x6293AF3C
R1(config-if)#
*Mar  1 00:00:27.863: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up
*Mar  1 00:00:30.263: %AAA-3-ACCT_LOW_MEM_UID_FAIL: AAA unable to create UID for incoming calls due to insufficient processor memory


% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR ERROR: symbol addition
% NBAR Error : Activation failed due to insufficient dynamic memory
% NBAR Error: Stile could not add protocol node
%NAT: Error activating CNBAR on the interface FastEthernet0/1



Then, the following message would be displayed in the GNS3 Console:



=> *** Warning: ghostsize is to small for device R1. Increase it with the ghostsize option.


Well, thanks to an anonymous commenter, we now have a fix to the issue. Here is what they wrote:


I had this same thing. Here's how I fixed it quickly. Instead of upping RAM manually on all device, edit the .net file for your project and set the 'ram' parameter on the model as follows:

-------------------
[127.0.0.1:7200]
workingdir = /tmp
udp = 10000
[[3745]]
image = /downloads/c3745-advipservicesk9-mz.124-15.T14.bin
ram = 256
idlepc = 0x60bc1748
ghostios = True
-------------------

now all devices you create from that model will have the same ram setting. seems to have cleared it up the issue for me anyway...



Looking at the other comments that were posted after the above one, it seems to be resolving the issues for others too.

Thanks to the anonymous commenter and to the others for letting us all know that it worked for you too! :)


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.