With this experiment we move from RIP to OSPF.
Here the
documentation
from Cisco is not quite as clear as might be hoped. Books on
the subject also leave something to be desired. After puzzling
over the documentation and a book on the subject and making one
totally unfruitful attempt to enable OSPF, we decided
to consult one of Calvin's resident network gurus,
Brian Baas for some help on reading between the lines.
The frustrating thing about trying to do this is that the
documentation seems so simple. As in Experiment 17.3 you just
- telnet to the router.
- type "enable".
- type "show running" just to see what is already going on.
Other useful commands at this point are "show ip route" and
"show ip interface".
- type "router ospf process-id".
(To disable OSPF type "no router ospf process-id".)
- type "config t".
- repeatedly type "network address wildcrd-mask area
area-id".
What could be simpler? Well, first let's talk about that
process-id. At first blush it seems rather arbitrary,
and you wonder why they are asking us for such a number. It is
significant for three reasons:
- You will need the number to disable OSPF.
- You want to make sure no other OSPF processes are running.
The reason why our first attempt to configure OSPF
failed miserably was that one of the
routers had an OSPF process running with id 25000. Where that
came from I have no idea. (This is why you type "show run"
in global configuration mode.)
- You can add information later to a running OSPF process,
but in order to do so, you need its process id.
Now let's move on to the network command and the wildcard-mask.
First, the latter is
nothing like a subnet mask which looks something like
255.255.255.0. The wildcard mask tells you what counts and
what does not. Is the four-bit pattern 1011 the same as 1101?
Obviously not, but suppose the mask is 0110. That means the
first and last bits count, and the others do not. So under
that mask they match. Change the mask to 1011, and they do not
match.
The wildcard-mask will end up being
0.0.3.255 in our intranet. What that means can best be
explained by describing that intranet. We had five
networks connected by four routers. The arrangement is
topologically equivalent to the diagram under Procedure And
Details but
we changed some of the numbers. Ethernet 0 on router n has the
ip address 10.2.n.30 and is connected to the switch for
network n. Ethernet 1 has the ip address 10.2.n.5 and is
connected to the switch for network n+1. We decided that
networks 1 through 3 would be area 0 while 4 and 5 would
constitute area 1. For routers 1 and 2 the network command
looked like
network 0.0.0.0 255.255.255.255 area 0
This says that for routers 1 and 2 anything you are connected
to is in area 0. The wildcard-mask functions as
described above:
where there is a 1, anything matches. Since
that
mask is all 1's in this example, everything matches.
For router 4 we do the same thing except that "area 0" becomes
"area 1".
It is router 3 that is tricky for this topology. Router 3
needs to know that 10.2.4.0 255.255.255.0 and
10.2.5.0 255.255.255.0 are in area 1 and that everything else
is in area 0. You accomplish this with two network commands.
- network 10.2.4.0 0.0.3.255 area 1
- network 0.0.0.0 255.255.255.255 area 0
This means that if the network ip address matches 10.2.4.0
with respect to all 16 bits in bytes 0 and 1, and all but the
least significant 2 bits in byte 2, then it's area 1.
Otherwise, it is area 0. This means that in our intranet,
10.2.4.0 255.255.255.0 and
10.2.5.0 255.255.255.0 will match. Were we to add 10.2.6.0
or 10.2.7.0 with the same subnet mask, networks 6 and 7 could
be placed in area 1 with no problems.
Having worked out this configuration we issued the commands
and watched it work. We also watched the routing tables on
10.2.1.1 while we turned router 3 off and then back on. We
also tried to ping 10.2.5.1 from 10.2.1.1 with OSPF disabled
on router 3. In a second window we enabled OSPF on that router
and watched the packets start to flow. Just
as advertised! Great experiment!!! Fun, fun, fun.
This site is maintained by W. David Laverell
of the Computer Science Department
at Calvin College. For assistance or corrections,
please contact him at .
