Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

FIGURE 5.3

The VLSM table

FIGURE 5.4

VLSM network example 1

FIGURE 5.5

VLSM table example 1

There are two important things to note here. The first is that we still have

plenty of room for growth with this VLSM network design. The second

point is that we could never achieve this goal with one subnet mask using

classful routing.

Let’s do another one.

Figure 5.6

shows a network with 11 networks, two

block sizes of 64, one of 32, five of 16, and three of 4.

FIGURE 5.6

VLSM network example 2

First, create your VLSM table and use your block size chart to fill in the

table with the subnets you need.

Figure 5.7

shows a possible solution.

Notice that I filled in this entire chart and only have room for one more

block size of 4. You can only gain that amount of address space savings

with a VLSM network!

Keep in mind that it doesn’t matter where you start your block sizes as

long as you always begin counting from zero. For example, if you had a

block size of 16, you must start at 0 and incrementally progress from

there—0, 16, 32, 48, and so on. You can’t start with a block size of 16 or

some value like 40, and you can’t progress using anything but increments

of 16.

Here’s another example. If you had block sizes of 32, start at zero like

this: 0, 32, 64, 96, etc. Again, you don’t get to start wherever you want;

you must always start counting from zero. In the example in

Figure 5.7

, I

started at 64 and 128, with my two block sizes of 64. I didn’t have much

choice because my options are 0, 64, 128, and 192. However, I added the

block size of 32, 16, 8, and 4 elsewhere, but they were always in the

correct increments required of the specific block size. Remember that if

you always start with the largest blocks first, then make your way to the

smaller blocks sizes, you will automatically fall on an increment

boundary. It also guarantees that you are using your address space in the

most effective way.

Okay—you have three locations you need to address, and the IP network

you have received is 192.168.55.0 to use as the addressing for the entire

network. You’ll use

ip subnet-zero

and RIPv2 as the routing protocol

because RIPv2 supports VLSM networks but RIPv1 does not.

Figure 5.8

shows the network diagram and the IP address of the RouterA S0/0

interface.

FIGURE 5.7

VLSM table example 2

FIGURE 5.8

VLSM design example 1

From the list of IP addresses on the right of the figure, which IP address

do you think will be placed in each router’s FastEthernet 0/0 interface

and serial 0/0 of RouterB?

To answer this, look for clues in

Figure 5.8

. The first is that interface

S0/0 on RouterA has IP address 192.168.55.2/30 assigned, which makes

for an easy answer because A /30 is 255.255.255.252, which gives you a

block size of 4. Your subnets are 0, 4, 8, etc. Since the known host has an

IP address of 2, the only other valid host in the zero subnet is 1, so the

third answer down is the right one for the S0/0 interface of RouterB.

The next clues are the listed number of hosts for each of the LANs.

RouterA needs 7 hosts—a block size of 16 (/28). RouterB needs 90 hosts

—a block size of 128 (/25). And RouterC needs 23 hosts—a block size of

32 (/27).

Figure 5.9

illustrates this solution.

FIGURE 5.9

Solution to VLSM design example 1

This is actually pretty simple because once you’ve figured out the block

size needed for each LAN, all you need to get to the right solution is to

identify proper clues and, of course, know your block sizes well!

One last example of VLSM design before we move on to summarization.

Figure 5.10

shows three routers, all running RIPv2. Which Class C

addressing scheme would you use to maintain the needs of this network

while saving as much address space as possible?

FIGURE 5.10

VLSM design example 2

This is actually a pretty clean network design that’s just waiting for you to

fill out the chart. There are block sizes of 64, 32, and 16 and two block

sizes of 4. Coming up with the right solution should be a slam dunk! Take

a look at my answer in

Figure 5.11

.

FIGURE 5.11

Solution to VLSM design example 2

My solution began at subnet 0, and I used the block size of 64. Clearly, I

didn’t have to go with a block size of 64 because I could’ve chosen a block

size of 4 instead. But I didn’t because I usually like to start with the

largest block size and move to the smallest. With that done, I added the

block sizes of 32 and 16 as well as the two block sizes of 4. This solution is

optimal because it still leaves lots of room to add subnets to this network!

Why Bother with VLSM Design?

You have just been hired by a new company and need to add on to

their existing network. There are no restrictions to prevent you from

starting over with a completely new IP address scheme. Should you

use a VLSM classless network or opt for a classful network?

Let’s say you happen to have plenty of address space because you’re

using the Class A 10.0.0.0 private network address, so you really can’t

imagine that you’d ever run out of IP addresses. So why would you

want to bother with the VLSM design process in this environment?

Good question! Here’s your answer…

By creating contiguous blocks of addresses to specific areas of your

network, you can then easily summarize the network and keep route

updates with a routing protocol to a minimum. Why would anyone

want to advertise hundreds of networks between buildings when you

can just send one summary route between buildings and achieve the

same result? This approach will optimize the network’s performance

dramatically!

To make sure this is clear, let me take a second to explain summary

routes. Summarization, also called supernetting, provides route

updates in the most efficient way possible by advertising many routes

in one advertisement instead of individually. This saves a ton of

bandwidth and minimizes router processing. As always, you need to

use blocks of addresses to configure your summary routes and watch

your network’s performance hum along efficiently! And remember,

block sizes are used in all sorts of networks anyway.

Still, it’s important to understand that summarization works only if

you design your network properly. If you carelessly hand out IP

subnets to any location on the network, you’ll quickly notice that you

no longer have any summary boundaries. And you won’t get very far

creating summary routes without those, so watch your step!

Summarization

Summarization, also called route aggregation, allows routing protocols to

advertise many networks as one address. The purpose of this is to reduce

the size of routing tables on routers to save memory, which also shortens

the amount of time IP requires to parse the routing table when

determining the best path to a remote network.

Figure 5.12

shows how a summary address would be used in an

internetwork.

FIGURE 5.12

Summary address used in an internetwork

Summarization is pretty straightforward because all you really need to

have down is a solid understanding of the block sizes we’ve been using for

subnetting and VLSM design. For example, if you wanted to summarize

the following networks into one network advertisement, you just have to

find the block size first, which will make it easy to find your answer:

192.168.16.0 through network 192.168.31.0

Okay—so what’s the block size? Well, there are exactly 16 Class C

networks, which fit neatly into a block size of 16.

Now that we’ve determined the block size, we just need to find the

network address and mask used to summarize these networks into one

advertisement. The network address used to advertise the summary

address is always the first network address in the block—in this example,

192.168.16.0. To figure out a summary mask, we just need to figure out

which mask will get us a block size of 16. If you came up with 240, you got

it right! 240 would be placed in the third octet, which is exactly the octet

where we’re summarizing, so the mask would be 255.255.240.0.

Here’s another example:

Networks 172.16.32.0 through 172.16.50.0

This isn’t as clean as the previous example because there are two possible

answers. Here’s why: Since you’re starting at network 32, your options for

block sizes are 4, 8, 16, 32, 64, etc., and block sizes of 16 and 32 could

work as this summary address. Let’s explore your two options:

If you went with a block size of 16, then the network address would be

172.16.32.0 with a mask of 255.255.240.0 (240 provides a block of

16). The problem is that this only summarizes from 32 to 47, which

means that networks 48 through 50 would be advertised as single

networks. Even so, this could still be a good solution depending on

your network design.

If you decided to go with a block size of 32 instead, then your

summary address would still be 172.16.32.0, but the mask would be

255.255.224.0 (224 provides a block of 32). The possible problem

with this answer is that it will summarize networks 32 through 63 and

we only have networks 32 to 50. No worries if you’re planning on

adding networks 51 to 63 later into the same network, but you could

have serious problems in your internetwork if somehow networks 51

to 63 were to show up and be advertised from somewhere else in your

network! So even though this option does allow for growth, it’s a lot

safer to go with option #1.

Let’s take a look at another example: Your summary address is

192.168.144.0/20, so what’s the range of host addresses that would be

forwarded according to this summary? The /20 provides a summary

address of 192.168.144.0 and mask of 255.255.240.0.

The third octet has a block size of 16, and starting at summary address

144, the next block of 16 is 160, so your network summary range is 144 to

159 in the third octet. This is why it comes in handy to be able to count in

16s!

A router with this summary address in the routing table will forward any

packet having destination IP addresses of 192.168.144.1 through

192.168.159.254.

Only two more summarization examples, then we’ll move on to

troubleshooting.

In summarization example 4,

Figure 5.13

, the Ethernet networks

connected to router R1 are being summarized to R2 as 192.168.144.0/20.

Which range of IP addresses will R2 forward to R1 according to this

summary?

FIGURE 5.13

Summarization example 4

No worries—solving this is easier than it looks initially. The question

actually has the summary address listed in it: 192.168.144.0/20. You

already know that /20 is 255.255.240.0, which means you’ve got a block

size of 16 in the third octet. Starting at 144, which is also right there in the

question, makes the next block size of 16 equal 160. You can’t go above

159 in the third octet, so the IP addresses that will be forwarded are

192.168.144.1 through 192.168.159.254.

Okay, last one. In

Figure 5.14

, there are five networks connected to router

R1. What’s the best summary address to R2?

FIGURE 5.14

Summarization example 5

I’ll be honest with you—this is a much harder question than the one in

Figure 5.13

, so you’re going to have to look carefully to see the answer. A

good approach here would be to write down all the networks and see if

you can find anything in common with all of them:

172.1.4.128/25

172.1.7.0/24

172.1.6.0/24

172.1.5.0/24

172.1.4.0/25

Do you see an octet that looks interesting to you? I do. It’s the third octet.

4, 5, 6, 7, and yes, it’s a block size of 4. So you can summarize 172.1.4.0

using a mask of 255.255.252.0, meaning you would use a block size of 4

in the third octet. The IP addresses forwarded with this summary would

be 172.1.4.1 through 172.1.7.254.

To summarize the summarization section, if you’ve nailed down your

block sizes, then finding and applying summary addresses and masks is a

relatively straightforward task. But you’re going to get bogged down

pretty quickly if you don’t know what a /20 is or if you can’t count by 16s!

Troubleshooting IP Addressing

Because running into trouble now and then in networking is a given,

being able to troubleshoot IP addressing is clearly a vital skill. I’m not

being negative here—just realistic. The positive side to this is that if

you’re the one equipped with the tools to diagnose and clear up the

inevitable trouble, you get to be the hero when you save the day! Even

better? You can usually fix an IP network regardless of whether you’re on

site or at home!

So this is where I’m going to show you the “Cisco way” of troubleshooting

IP addressing. Let’s use

Figure 5.15

as an example of your basic IP trouble

—poor Sally can’t log in to the Windows server. Do you deal with this by

calling the Microsoft team to tell them their server is a pile of junk and

causing all your problems? Though tempting, a better approach is to first

double-check and verify your network instead.

FIGURE 5.15

Basic IP troubleshooting

Okay, let’s get started by going through the troubleshooting steps that

Cisco recommends. They’re pretty simple, but important nonetheless.

Pretend you’re at a customer host and they’re complaining that they can’t

communicate to a server that just happens to be on a remote network.

Here are the four troubleshooting steps Cisco recommends:

1.  Open a Command window and ping 127.0.0.1. This is the diagnostic,

or loopback, address, and if you get a successful ping, your IP stack is

considered initialized. If it fails, then you have an IP stack failure and

need to reinstall TCP/IP on the host.

C:\>

ping 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 127.0.0.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

2.  From the Command window, ping the IP address of the local host

(we’ll assume correct configuration here, but always check the IP

configuration too!). If that’s successful, your network interface card

(NIC) is functioning. If it fails, there is a problem with the NIC.

Success here doesn’t just mean that a cable is plugged into the NIC,

only that the IP protocol stack on the host can communicate to the

NIC via the LAN driver.

C:\>

ping 172.16.10.2

Pinging 172.16.10.2 with 32 bytes of data:

Reply from 172.16.10.2: bytes=32 time<1ms TTL=128

Reply from 172.16.10.2: bytes=32 time<1ms TTL=128

Reply from 172.16.10.2: bytes=32 time<1ms TTL=128

Reply from 172.16.10.2: bytes=32 time<1ms TTL=128

Ping statistics for 172.16.10.2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

3.  From the Command window, ping the default gateway (router). If the

ping works, it means that the NIC is plugged into the network and can

communicate on the local network. If it fails, you have a local physical

network problem that could be anywhere from the NIC to the router.

C:\>

ping 172.16.10.1

Pinging 172.16.10.1 with 32 bytes of data:

Reply from 172.16.10.1: bytes=32 time<1ms TTL=128

Reply from 172.16.10.1: bytes=32 time<1ms TTL=128

Reply from 172.16.10.1: bytes=32 time<1ms TTL=128

Reply from 172.16.10.1: bytes=32 time<1ms TTL=128

Ping statistics for 172.16.10.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

4.  If steps 1 through 3 were successful, try to ping the remote server. If

that works, then you know that you have IP communication between

the local host and the remote server. You also know that the remote

physical network is working.

C:\>

ping 172.16.20.2

Pinging 172.16.20.2 with 32 bytes of data:

Reply from 172.16.20.2: bytes=32 time<1ms TTL=128

Reply from 172.16.20.2: bytes=32 time<1ms TTL=128

Reply from 172.16.20.2: bytes=32 time<1ms TTL=128

Reply from 172.16.20.2: bytes=32 time<1ms TTL=128

Ping statistics for 172.16.20.2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

If the user still can’t communicate with the server after steps 1 through 4

have been completed successfully, you probably have some type of name

resolution problem and need to check your Domain Name System (DNS)

settings. But if the ping to the remote server fails, then you know you

have some type of remote physical network problem and need to go to the

server and work through steps 1 through 3 until you find the snag.

Before we move on to determining IP address problems and how to fix

them, I just want to mention some basic commands that you can use to

help troubleshoot your network from both a PC and a Cisco router. Keep

in mind that though these commands may do the same thing, they’re

implemented differently.

ping

Uses ICMP echo request and replies to test if a node IP stack is

initialized and alive on the network.

traceroute

Displays the list of routers on a path to a network destination

by using TTL time-outs and ICMP error messages. This command will

not work from a command prompt.

tracert

Same function as

traceroute

, but it’s a Microsoft Windows

command and will not work on a Cisco router.

arp -a

Displays IP-to-MAC-address mappings on a Windows PC.

show ip arp

Same function as

arp -a

, but displays the ARP table on a

Cisco router. Like the commands

traceroute

and

tracert

,

arp -a

and

show ip arp

are not interchangeable through DOS and Cisco.

ipconfig /all

Used only from a Windows command prompt; shows you

the PC network configuration.

Once you’ve gone through all these steps and, if necessary, used the

appropriate commands, what do you do when you find a problem? How

do you go about fixing an IP address configuration error? Time to cover

the next step—determining and fixing the issue at hand!

Determining IP Address Problems

It’s common for a host, router, or other network device to be configured

with the wrong IP address, subnet mask, or default gateway. Because this

happens way too often, you must know how to find and fix IP address

configuration errors.

A good way to start is to draw out the network and IP addressing scheme.

If that’s already been done, consider yourself lucky because though

sensible, it’s rarely done. Even if it is, it’s usually outdated or inaccurate

anyway. So either way, it’s a good idea to bite the bullet and start from

scratch.

I’ll show you how a great way to draw out your network using

the Cisco Discovery Protocol (CDP) soon, in Chapter 7, “Managing a

Cisco Internetwork.”

Once you have your network accurately drawn out, including the IP

addressing scheme, you need to verify each host’s IP address, mask, and

default gateway address to establish the problem. Of course, this is

assuming that you don’t have a physical layer problem, or if you did, that

you’ve already fixed it.

Let’s check out the example illustrated in

Figure 5.16

.

FIGURE 5.16

IP address problem 1

A user in the sales department calls and tells you that she can’t get to

ServerA in the marketing department. You ask her if she can get to

ServerB in the marketing department, but she doesn’t know because she

doesn’t have rights to log on to that server. What do you do?

First, guide your user through the four troubleshooting steps you learned

in the preceding section. Okay—let’s say steps 1 through 3 work but step 4

fails. By looking at the figure, can you determine the problem? Look for

clues in the network drawing. First, the WAN link between the Lab A

router and the Lab B router shows the mask as a /27. You should already

know that this mask is 255.255.255.224 and determine that all networks

are using this mask. The network address is 192.168.1.0. What are our

valid subnets and hosts? 256 – 224 = 32, so this makes our subnets 0, 32,

64, 96, 128, etc. So, by looking at the figure, you can see that subnet 32 is

being used by the sales department. The WAN link is using subnet 96,

and the marketing department is using subnet 64.

Now you’ve got to establish what the valid host ranges are for each

subnet. From what you learned at the beginning of this chapter, you

should now be able to easily determine the subnet address, broadcast

addresses, and valid host ranges. The valid hosts for the Sales LAN are 33

through 62, and the broadcast address is 63 because the next subnet is

64, right? For the Marketing LAN, the valid hosts are 65 through 94

(broadcast 95), and for the WAN link, 97 through 126 (broadcast 127). By

closely examining the figure, you can determine that the default gateway

on the Lab B router is incorrect. That address is the broadcast address for

subnet 64, so there’s no way it could be a valid host!

If you tried to configure that address on the Lab B router

interface, you’d receive a

bad mask

error. Cisco routers don’t let you

type in subnet and broadcast addresses as valid hosts!

Did you get all that? Let’s try another one to make sure.

Figure 5.17

shows

a network problem.