Вы находитесь на странице: 1из 10

A Brief Note Regarding These Exercises: Most of these exercises can be solved quite easily

with the Windows calculator (when operating in "scientific" mode), but you might want to have a
feel for doing this stuff the "hard way" as well, because you won't have access to a calculator
during Cisco exams (including those for CCNA, CCNP, CCDA, and CCDP).
EXERCISES (numbered in binary, of course!):
00000001. Count from 0 to 255 in binary (use only two fingers!).
00000010. Convert the following binary numbers to decimal:
a.
b.
c.
d.
e.
f.
g.
h.

1101
1
101
110
10110
0010110
1101111
11101110111

00000011. Convert the following decimal numbers to binary:


a.
b.
c.
d.
e.
f.
g.
h.

123
242
17
247
10001
99
214
78

00000100. Is the binary number


010101010100101010101010101010101111101010000101011101011

even or odd?
00000101. If it takes Al five (decimal) hours to run a marathon, how many minutes does it take
him? Give your answer in binary.
00000110. Why can a computer with a 32-bit address bus access a maximum of 4 GB of
memory? Some CPUs provide a 64-bit address space. How many memory locations will they be
able to address individually? IP version 6 uses a 128-bit address space. How many addresses can
it provide?
00000111. Convert the following IP addresses in "dotted-decimal" notation to their 32-bit binary
equivalents:
a.
b.
c.
d.
e.
f.
g.

203.184.17.253
255.255.0.0
10.253.135.99
124.36.0.226
255.255.248.0
80.90.100.110
224.0.0.6

h. 255.255.255.252

00001000. Convert the following binary IP addresses to dotted-decimal:


a.
b.
c.
d.
e.
f.
g.
h.

01101010 11010010 10101010 01011010


00011110 10101010 01101001 01010101
11111111 00000000 00000000 00000000
11111001 00000000 00000000 11011101
10000000000000010110011011111110
11111111111111111111111000000000
01001100011100001111000001111101
10110011100011110000111110000010

00001001. Convert the following decimal numbers to eight-bit binary numbers:


a.
b.
c.
d.
e.
f.
g.
h.

34
62
206
19
250
72
183
66

00001010. Convert the following binary numbers to hexadecimal (base-16):


a.
b.
c.
d.
e.
f.
g.
h.

0111
1101
1011011
11101100
100101101
0101101011110000
00000000000000000001
11001010111001101011010011

00001011. Convert the following hexadecimal numbers to binary:


a.
b.
c.
d.
e.
f.
g.
h.

DEAD
AF-05-12-57
00-00-0C-9F-F2-A9
00-00-5E-00-00-00
123456789ABCDEF
F0E1D2C3B4A59687
B0C
1000

00001100. Is the hexadecimal number:


AC93D9E02817C635A78B92C9F4837D2A

even or odd?
00001101. Hex seems to be a hassle. Why do we use it?
00001110. A subnet mask is given as FF-FF-FC-00. What is its representation in dotted-decimal
notation?
00001111. What are the hex and dotted-decimal representations for a "/29" subnet mask?

EXTRA CREDIT (Not on the Cisco tests - for math geeks only!):
00010000. Convert the following hexadecimal numbers to decimal:
a.
b.
c.
d.
e.
f.
g.
h.

AA
123F
FEDCBA
D0-BE-D0
B8C
FF-FF-FF-FA
10
BABE

00010001. Convert the following decimal numbers to hexadecimal:


a.
b.
c.
d.
e.
f.
g.
h.

9
32
73
255
1,025
4,099
65536
1,048,575

00010010. Convert the following binary numbers to decimal (these are pretty tricky!):
a.
b.
c.
d.
e.

0.1
1.11
101.01101
100101.11101
11101111.10000001

00010011. Convert the following decimal numbers to binary (these are really tricky!):
a.
b.
c.
d.
e.

0.5
1.0625
7.7500
163.2
3.141592654

ANSWERS:
00000001. Count from 0 to 255 in binary (you can't do it with only two fingers, but it's good
practice!).
Remember that in binary (base-two), just like in decimal (base-ten), each position you move to
the left increases in value by the amount of the base. In decimal, for example, the positions are
valued "ones", "tens", "hundreds", "thousands" and so on, and as we move left, each position
increases by the value of the base, which in this case is ten. In binary, the positions are valued
"ones", "twos", "fours", "eights" and so on, each time increasing by the amount of the base,
which in this case is two. Those of us who are familiar with a scheme called "scientific notation"
may recall that the right-most position represents the base to the zero power, and then, as we
move left, each position increments the exponent (power) by one, such as "two-to-the-zero"
(which is one), "two-to-the-first" (two), "two-to-the-second" (four), etc. It works that way for all
bases, not just ten and two. Here are the binary representations of the numbers from zero to 255:

0-31
00000000
00000001
00000010
00000011
00000100
00000101
00000110
00000111
00001000
00001001
00001010
00001011
00001100
00001101
00001110
00001111
00010000
00010001
00010010
00010011
00010100
00010101
00010110
00010111
00011000
00011001
00011010
00011011
00011100
00011101
00011110
00011111

32-63
00100000
00100001
00100010
00100011
00100100
00100101
00100110
00100111
00101000
00101001
00101010
00101011
00101100
00101101
00101110
00101111
00110000
00110001
00110010
00110011
00110100
00110101
00110110
00110111
00111000
00111001
00111010
00111011
00111100
00111101
00111110
00111111

64-95
01000000
01000001
01000010
01000011
01000100
01000101
01000110
01000111
01001000
01001001
01001010
01001011
01001100
01001101
01001110
01001111
01010000
01010001
01010010
01010011
01010100
01010101
01010110
01010111
01011000
01011001
01011010
01011011
01011100
01011101
01011110
01011111

96-127
01100000
01100001
01100010
01100011
01100100
01100101
01100110
01100111
01101000
01101001
01101010
01101011
01101100
01101101
01101110
01101111
01110000
01110001
01110010
01110011
01110100
01110101
01110110
01110111
01111000
01111001
01111010
01111011
01111100
01111101
01111110
01111111

128-159
10000000
10000001
10000010
10000011
10000100
10000101
10000110
10000111
10001000
10001001
10001010
10001011
10001100
10001101
10001110
10001111
10010000
10010001
10010010
10010011
10010100
10010101
10010110
10010111
10011000
10011001
10011010
10011011
10011100
10011101
10011110
10011111

160-191
10100000
10100001
10100010
10100011
10100100
10100101
10100110
10100111
10101000
10101001
10101010
10101011
10101100
10101101
10101110
10101111
10110000
10110001
10110010
10110011
10110100
10110101
10110110
10110111
10111000
10111001
10111010
10111011
10111100
10111101
10111110
10111111

192-223
11000000
11000001
11000010
11000011
11000100
11000101
11000110
11000111
11001000
11001001
11001010
11001011
11001100
11001101
11001110
11001111
11010000
11010001
11010010
11010010
11010011
11010100
11010101
11010110
11010111
11011000
11011001
11011010
11011011
11011100
11011101
11011111

224-255
11100000
11100001
11100010
11100011
11100100
11100101
11100110
11100111
11101000
11101001
11101010
11101011
11101100
11101101
11101110
11101111
11110000
11110001
11110010
11110011
11110100
11110101
11110110
11110111
11111000
11111001
11111010
11111011
11111100
11111101
11111110
11111111

00000010. To convert from binary to decimal, just multiply each bit by the value of its position,
and add the results for all positions. The right-most position is worth one. When dealing with
binary numbers, the value of each position increases by a factor of two as we move left, so the
next position to the left is worth two, the next position is worth four, the next is worth eight, etc.
Again, for fans of scientific notation, the base is two, and the exponents start at zero for the rightmost position, and increment by one for each position as we move left. That is, in an eight-bit
binary number, the columns (bits) are worth:
1
2 6 3 1
8 4 2 6 8 4 2 1
---------------------1 1 1 1 1 1 1 1 = 255 (128 + 64 + 32 + 16 + 8 + 4 + 2 + 1)

Therefore, converting the binary number 01101 to decimal (starting from the left and moving to
the right) gives [0 x 16] + [1 x 8] + [1 x 4] + [0 x 2] + [1 x 1], or 13. You can start at the right and
move left if you find that more convenient, just make sure you do the math correctly.
a.
b.
c.
d.
e.

13
1
5
6
22

f. 22
g. 111
h. 1,911

00000011. Going from decimal to binary is easy. Just use this algorithm:
Divide the decimal number (which mathematicians would call the "dividend") by 2 (the
"divisor"). Write down the result (the "quotient") and what is left over (the "remainder"). Using
the quotient as the new dividend, repeat until the dividend is zero. Now, read the remainders in
reverse order, and you have the binary equivalent of the original decimal number.
For example, suppose we want to convert the decimal number 123 to binary. First, do the
divisions (stop when the quotient reaches zero):
123
61
30
15
7
3
1

/
/
/
/
/
/
/

2
2
2
2
2
2
2

->
->
->
->
->
->
->

Q
Q
Q
Q
Q
Q
Q

=
=
=
=
=
=
=

61,
30,
15,
7,
3,
1,
0,

R
R
R
R
R
R
R

=
=
=
=
=
=
=

1
1
0
1
1
1
1

Now read the remainders from bottom to top:


123
61
30
15
7
3
1

/
/
/
/
/
/
/

2
2
2
2
2
2
2

->
->
->
->
->
->
->

Q
Q
Q
Q
Q
Q
Q

=
=
=
=
=
=
=

61,
30,
15,
7,
3,
1,
0,

R
R
R
R
R
R
R

=
=
=
=
=
=
=

1
1
0
1
1
1
1

^
|
|
|
|
|
|

top!
to
bottom
from
bits
the
Read

The binary equivalent of decimal 123 is 1111011. We can (and should!) check our work by using
the method from the previous problem, which (working from left to right) gives [1 x 64] + [1 x
32] + [1 x 16] + [1 x 8] + [0 x 4] + [1 x 2] + [1 x 1], or 123. If we want to represent the answer as
an eight-bit binary number, just add a zero on the left (referred to as "zero-padding") for
01111011.
a.
b.
c.
d.
e.
f.
g.
h.

1111011
11110010
10001
11110111
10011100010001
1100011
11010110
1001110

Note that there are sometimes ways to "cheat". For example in "a" above (Convert 123 to
binary"), since 1111111 in binary is 127 in decimal, if we turn off the 4's bit (0000100) in 127
(1111111), we get 123 (1111011). Likewise, in "d", since 255 is 11111111, 247 is 11110111 (eight
less). With a little practice, you can exploit this to good effect in more complicated problems.
00000100. Odd, because it ends in a "1".
00000101. First convert five (decimal) hours into 300 (decimal) minutes. Then convert 300
(decimal) minutes into binary. The answer is 100101100 (binary) minutes.

00000110. A computer with a 32-bit address bus is said to have a "32-bit address space". Since
with 32 bits you can have 4,294,967,296 unique combinations:
00000000000000000000000000000000
00000000000000000000000000000001
00000000000000000000000000000010
... and so on, and so forth ...
11111111111111111111111111111101
11111111111111111111111111111110
11111111111111111111111111111111

(0)
(1)
(4,294,967,293)
(4,294,967,294)
(4,294,967,295)

such a machine could store and retrieve information from 4,294,967,296 memory locations (if
you don't believe there are 4,294,967,296 unique combinations, you are welcome to list and
count them!). The bottom line is that the number of possible combinations of bits on the address
bus is the number of memory addresses that the computer can address individually. Machines
with a 64-bit address space can individually address 18,446,744,073,709,551,616 memory
locations (nobody can afford that many!). Likewise, the 128-bit address space of IPv6 will allow
for 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses. That should last a while!
Note that in order to find the answers for the 64-bit and 128-bit address spaces, I wrote a special
program that will handle precise calculations involving huge integers (whole numbers). No
"normal" calculator (not even a fancy scientific) will handle numbers that large with the number
of significant digits I quoted.
00000111.
a.
b.
c.
d.
e.
f.
g.
h.

If we convert each decimal value to a binary octet, we have:


203
184
17
253
11001011 10111000 00010001 11111101
11111111 11111111 00000000 00000000
00001010 11111101 10000111 01100011
01111100 00100100 00000000 11100010
11111111 11111111 11111000 00000000
01010000 01011010 01100100 01101110
11100000 00000000 00000000 00000110
11111111 11111111 11111111 11111100

00001000.
a.
b.
c.
d.
e.
f.
g.
h.

106.210.170.90
30.170.105.85
255.0.0.0
249.0.0.221
128.1.102.254
255.255.254.0
76.112.240.125
179.143.15.130

00001001.
a.
b.
c.
d.
e.
f.
g.

00100010
00111110
11001110
00010011
11111010
01001000
10110111

h. 01000010

00001010. To convert a binary number to its hex representation, first group the bits into
"nibbles" (a "nibble" is four bits, or half a byte), starting from the right. For example, given the
binary number 10110110011, the right-most nibble is 0011. The next nibble to the left is 1011.
The left-most nibble is 0101 (note the addition of a leading zero to get four bits). Now, convert
each nibble to its hex equivalent, using the following table:
Binary Hex
0000
0
0001
1
0010
2
0011
3
0100
4
0101
5
0110
6
0111
7
1000
8
1001
9
1010
A
1011
B
1100
C
1101
D
1110
E
1111
F

Using the nibbles 0101 1011 0011, we obtain the values 5 B 3. Finally, concatenate (smash
together) the hex digits in a suitable manner, such as 0x5B3, or whatever representation is handy.
Long hex numbers are typically represented as pairs of hex digits separated by dashes (e.g., 05B3). This is done because a pair of hex digits represents two four-bit nibbles, which is one eightbit byte.
a.
b.
c.
d.
e.
f.
g.
h.

0x7
0xD
0x5B
0xEC
0x012D
0x5AF0
0x1
0x032B9AD3 (or 03-2B-9A-D3)

00001011. To go from hex to binary, just reverse the process from above. Using the table,
convert each hex digit into its binary (nibble) equivalent, and then concatenate the nibbles. For
example, to convert the hex value A2F to binary, convert the hex digits A, 2 and F to binary,
which gives 1010 0010 1111, and smack them together (in order) to get 101000101111.
a.
b.
c.
d.
e.
f.
g.
h.

1101111010101101
10101111000001010001001001010111
000000000000000000001100100111111111001010101001
000000000000000001011110000000000000000000000000
000100100011010001010110011110001001101010111100110111101111
1111000011100001110100101100001110110100101001011001011010000111
101100001100
1000000000000

00001100. Recall that in hexadecimal (base-sixteen), there are sixteen digits: 0, 1, 2, 3, 4, 5, 6, 7,


8, 9, A, B, C, D, E and F (where A, B, C, D, E and F represent 10, 11, 12, 13, 14 and 15 in

decimal, respectively). Therefore, the answer is "even", because it ends in an "A", which is ten in
decimal (an even number).
00001101. Because each hex digit is worth four binary bits, we can use hex as shorthand for
binary numbers. For example, an IP version 6 address is represented as a 32-digit hex number.
Assuming that we still have to manipulate IP addresses in the future, would you rather type or
write 32 hex digits, or its equivalent as 128 binary digits?
00001110. First, expand each hex digit into its binary nibble equivalent:
F
F
F
F
F
C
0
0
1111 1111 1111 1111 1111 1100 0000 0000

Now, make an octet out of each nibble pair:


11111111 11111111 11111100 00000000

Convert each octet to its decimal equivalent:

11111111 11111111 11111100 00000000


255
255
252
0

Separate the values by periods to get 255.255.252.0


00001111. A "/29" subnet mask means 29 ones, followed by 3 zeroes (subnet masks are always
32 bits in length). Thus, its binary representation is:
11111111111111111111111111111000

To convert to hex, group the bits by nibbles:


1111 1111 1111 1111 1111 1111 1111 1000

And convert each nibble to a hex digit:

1111 1111 1111 1111 1111 1111 1111 1000


F
F
F
F
F
F
F
8

To get the hex representation, group the hex digits in "paired-dashed" format:
FF-FF-FF-F8

To convert the mask to dotted-decimal format, divide the binary format into octets:
11111111 11111111 11111111 11111000

Convert each octet to its decimal equivalent:

11111111 11111111 11111111 11111000


255
255
255
248

Separate the values with periods to get 255.255.255.248


EXTRA CREDIT ANSWERS:
00010000. Going from hex to decimal is similar to going from binary to decimal. Just convert
each hex digit to its decimal equivalent, multiply by the value of its position, and add the results
for all positions. As with binary and decimal, the right-most position is worth one. When dealing
with hex numbers, the value of each position increases by a factor of sixteen as we move left, so
the next position to the left is worth sixteen, the next position is worth 256 (decimal), the next is
worth 4,096, etc. Again, for fans of scientific notation, the base is sixteen, and the exponents start
at zero for the right-most position, and increment by one for each position as we move left.
Therefore, converting the hex number 2AB to decimal (starting from the right and moving
leftwards) gives [11 x 1] + [10 x 16] + [2 x 256], or 683. As with binary, you can start at the left
and move to the right, just make sure that you don't scramble the values while multiplying and
adding positions.

a.
b.
c.
d.
e.
f.
g.
h.

170
4,671
16,702,650
13,680,336
2,956
4,294,967,290
16
47,806

00010001. As with decimal to binary, going from decimal to hex is a little tricky. You have to
figure out how many hex digits you need, and the value of each. Let's do an example ...
Suppose we want to convert the decimal number 11,267 to hex. How many hex digits are
necessary? Well, since the hex positions start at the right with a value of one, and the value
increases by a factor of sixteen each time we move one position to the left, they follow the rightto-left progression of 1-16-256-4,096-65,536-etc. Since our value 11,267 is smaller than 65,536,
we don't need to go that far. We only need the 1-through-4096 positions, or four hex digits, and
we can therefore represent our decimal number of 11,267 with a four digit hex number. To find
the hex number, we start with our decimal number of 11,267, and with our highest-valued hex
position of 4,096. How many times does 4,096 go into 11,267? Twice, with 3075 left over.
Therefore, our first hex digit is "2", and the hex result so far looks like "2". Now we repeat the
process. How many times does 256 go into 3,075? Twelve (which is "C" in hex), with 3 left over,
so "C" is our next hex digit, and the hex result so far is "2C". How many times does 16 go into
3? Zero, so that's our next hex digit, and that gives us "2C0". How many times does one (the last
position) go into 3? Three, so that's our next (and final) hex digit, and the hex result is "2C03".
Again, while this looks long and involved, it is really quite quick once you get the hang of it.
Another way to do it is to first convert the decimal number to binary (using whatever method
you prefer), and then convert the resulting binary to hex (which is easy, just do one nibble at a
time). Either way, we can check our work by using the method from the previous problem, which
(working from right to left) gives [3 x 1] + [0 x 16] + [12 x 256] + [2 x 4096], or 11,267.
a.
b.
c.
d.
e.
f.
g.
h.

0x9
0x20
0x49
0xFF
0x401
0x1003
0x10000
0xFFFFF

00010010. A new twist: the "binary point"! It's like a decimal point, but it is used with binary
numbers. It works just like the decimal point, except that the values to the right of the binarypoint are divided by two as you move farther right, instead of by ten as with a decimal point.
That is, the position immediately to the right of the binary point is worth one-half, the next
position further to the right is worth one-fourth, then one-eighth, one-sixteenth, etc (whereas with
a decimal point it goes one-tenth, one-hundreth, one-thousandth, etc). As usual, when converting
from binary to decimal, just determine the values of the columns with ones, and add them up to
get the decimal result, and ignore the zero bits.
a. 0.5
b. 1.75

c. 5.40625
d. 37.90625
e. 239.50390625

00010011. Decimal to binary can be tricky when fractions are involved. As with decimal
numbers, there are some fractions (such as one-third, which is 0.3333333...continuing forever)
that cannot be represented with a finite number of binary digits. In other words, the part to the
right of the binary-point goes on forever. Also, just because you can represent a number "nicely"
as a decimal doesn't mean you can represent it nicely as a binary, and vice versa.
a.
b.
c.
d.
e.

0.1
1.0001
111.11
10100011.00110011 etc ... goes on for many (maybe infinitely many) digits
11.00100100 etc ... goes on for infinitely many digits

Вам также может понравиться