What better way to start the Zero to Hero Guide than learning how to build your own ONTAP lab for free? Thanks to Neil Anderson over at FlackBox, we can do just that!
Neil has written a book which covers the entire end to end process. The book contains easy to follow step by step instructions, screenshots and diagrams to ensure that nothing gets missed. Heck, he even provides the IP addresses! The beauty of this is that even if you have zero NetApp experience, you’ll still be able to get a fully operational lab up and running in no time at all.
Anyway, without further ado, here’s where you can find Neil’s guide.
If you run into any issues with your build, be sure to reach out to Neil and he will be more than happy to help you out.
Note: As you will soon see I use tables (some might say excessively :P) in this post. I did this is because it closely resembles what a lot of network engineers do when they’re performing subnet calculations with a pen and paper. This is a very important skill to learn as you won’t always have access to a subnet calculator when you need one.
I recently received an e-mail from a reader asking for subnetting assistance. An extract of the e-mail is below.
I looked at your subnetting archive but I am still confused on how to subnet! *sobs*
So could you help me subnet a IP address of 192.168.25.0/24 with 2 and 27 hosts.
It’s been a while since I’ve done this and your blog is the closest guide that’s helped somewhat.
Could you explain to me step by step how to find the:
- Number of bits in the subnet
- The subnet mask in binary
- The subnet mask in decimal
- The maximum number of usable subnets including the 0 subnet
- The number of usable hosts per subnet
- The first and last host address for each subnet
Just under a year ago I wrote a blog series called NetApp From The Ground Up – A Beginner’s Gude. Since the publication of the series I have been getting e-mails, Tweets and LinkedIn messages from people asking for more. So here it is – The NetApp Zero to Hero Guide.
This series of posts is aimed at people who have zero storage knowledge. Each post will build on from the last and together they will assist the reader in becoming a storage hero :)
In this post I will demonstrate how we can find out which of SW3’s switchports PC1 is connected to in the topology diagram below. To make things more fun though I’ll begin my search from R1.
Note that apart from R1 and PC1’s IP addresses, we do not have nor need any other information such as intermediate device IPs or port numbers in order to get started. Also note that the diagram is only used to show you, the reader what the topology looks like. As explained below, when doing this in a real topology you do not need a topology diagram to be able to successfully locate the host’s corresponding switchport.
To properly administer an EIGRP network an admin really should know how EIGRP calculates and chooses best paths. If you’ve read any CCNA or CCNP resource you’re probably thinking “that’s easy, EIGRP uses Bandwidth and Delay by default”. And you’re completely right. However, how do these two pieces of information actually influence the resulting metric?
Let’s take a look at what EIGRP devices (routers and switches) do with the bandwidth and delay values:
If you haven’t seen it before, it is the formula EIGRP devices use to calculate the metric of a route. If you’re not sure how to read this formula, don’t worry, I’ve got a shortcut :) But I’ll get to that in a moment.
Throughout this post I will be referring to the path which traffic takes when going from R2 to the 192.168.34.0/24 network which resides on R3 and R4 as per this topology diagram:
I thought I’d write up a quick blog post to celebrate the fact that NetApp Insight is around the corner!
If you haven’t seen them already you can find my NetApp posts here. To jump directly to my “NetApp From the Ground Up – A Beginner’s Guide” series of posts click here.
Finally, keep an eye on my Twitter account (@OzNetNerd) and the #NetAppATeam hashtag to see what the other A Team members and I get up to while we’re over there. Oh and of course there’s always the #NetAppInsight hashtag too!
… as you can probably tell, I’m a little excited :)
After publishing my previous post, I received another e-mail from the author of the original e-mail:
… So basically, I would like to find out how to find the first usable IP address. As I say, using your process, I can figure out the Network IP address, and the Broadcast IP address, but I don’t know how to figure out the first usable IP.
I was asking someone in a class this morning, and he was saying something, that I didn’t understand, about adding a “1” to the network address, which would make sense. If the Network IP address is 192.168.0.0 then the first usable address would be 192.168.0.1.
The bit I don’t get is, when you have the IP address and the Subnet Mask in binary, and the Subnet Mask is, say, 21 bits then that would leave 3 bits in the third octet belonging to the host part of the address. Therefore, in total there would be 11 bits belonging to the host address, but how is the calculation made to find the first host address? What happens to the three host bits in the third octet?
My reply to this e-mail went as follows:
Recently I received the following e-mail from a reader:
I have read, and followed your method of finding subnet mask addresses, and calculating the first and last and broadcast addresses, but there is something that I would like to ask.
I can follow the “normal” /30 method, using borrowed bits from the fourth octet, but I find it difficult to figure out what happens when you are using the third, or possibly the second, octet.
If I may pose an example with a classless address:
IP address = 22.214.171.124 /22
Therefore S/M = 255.255.252.0
I believe that this would be demonstrated as : N.N.nnnnnnhh.H
Using the borrowing principal, what is the Network address, and then doing an “Anding” calculation I come up with the following:
11000000—10100010—00101101—11010100 = IP address
11111111—11111111—11111100—00000000 = S/M
11000000—10100010—00101100—00000000 = Network address
Network address = 126.96.36.199
1st Host = 188.8.131.52
What I am puzzled about is how do you calculate the last host, and the broadcast? Although based on your explanation, the last host will be one address lower than the broadcast. My problem is that I can figure out what you do with the two “hh” bits that are in octet 3.
So far in this series I’ve covered Type 1, 2 and 3 LSAs. Next I’m going to cover Type 4 and Type 5 LSAs with the help of this topology.
Before we get started though, let’s have a quick refresher on what these LSAs are used for:
- Type 4 – ASBR-Summary LSA – this is needed because Type 5 External LSAs are flooded to all areas and the detailed next-hop information may not be available in those other areas. This is solved by an Area Border Router flooding the information for the router (i.e. the Autonomous System Boundary Router) where the type 5 originated. The link-state ID is the router ID of the described ASBR for type 4 LSAs.
- Type 5 – External LSA – these LSAs contain information imported into OSPF from other routing processes. They are flooded to all areas unchanged (except stub and NSSA areas). For “External Metric Type 1″ LSAs routing decisions are made using the Type 1 metric cost sent, as the total cost to get to the external destination and includes the cost to the ASBR; while for “External Type 2″ LSAs the metric sent is the cost from the ASBR to the External destination network and must be added to the OSPF cost to the ASBR advertising the Type 5. The link-state ID of the type 5 LSA is the external network number.
Up until this point I have only covered Type 1 and Type 2 LSAs in this series. I’m guessing by now you must be quite familiar with them and are interested to hear about the other LSAs, so let’s move onto Type 3’s.
This is what Wikipeda has to say about Type 3 LSAs:
- Type 3 – Summary LSA – an Area Border Router (ABR) takes information it has learned on one of its attached areas and summarizes it before sending it out on other areas it is connected to. This summarization helps provide scalability by removing detailed topology information for other areas, because their routing information is summarized into just an address prefix and metric. The summarization process can also be configured to remove a lot of detailed address prefixes and replace them with a single summary prefix, helping scalability. The link-state ID is the destination network number for type 3 LSAs.
While the above is true, the summarisation must be configured manually on the ABR, so I’ll delve deeper into it later on in this post. For now let’s just focus on the fact that an ABR is used to share routes between the areas which it is connected. Let’s use the topology below to demonstrate this: