Configuring OSPF
The many options and
configuration variables available to OSPF frequently make it the IGP of choice in large IP internetworks. However, the opinion is occasionally expressed that OSPF configuration is "too complex" to be a good choice for small internets. This is nonsense. As the first case study shows, getting a basic OSPF configuration up and running involves only a few extra keystrokes in the network command; if the operation of OSPF is reasonably well understood, these extra keystrokes will be intuitive.
Case Study: A Basic OSPF Configuration
The three steps necessary to
begin a basic OSPF process are:
Determine the area to which each router interface will be attached. Enable OSPF with the
command router ospf
process-id. Specify the interfaces on which to run OSPF, and their areas, with the
network area command.
Unlike the process ID associated with IGRP and EIGRP, the OSPF
process ID is not an autonomous system number. The process ID can be any positive integer and has no significance outside the router on which it is configured. Cisco IOS allows multiple OSPF processes to run on the same router; the process ID merely distinguishes one process from another within the device.
The
network command used with the previously discussed protocols allows only the specification of a major network address. If some interfaces within the network should not run the routing protocol, the
pas
sive-interface command has to be used with those protocols. The
network area command is much more flexible, reflecting the fully classless nature of OSPF. Any address range can be specified with an (address, inverse mask) pair. The
inverse mask is the same as the inverse mask used with access lists. The area can be specified in either decimal or dotted decimal.
Figure 9.61 shows an OSPF internetwork. Note that each area has an assigned IP address from which its subnets are derived. Limiting an area to a single address or subnet is not necessary, but doing so has significant advantages, as will be seen in a later case study on address summarization. Note also that this example is designed to demonstrate the configuration of multiple areas.
In "real life," it would be much wiser to put such a small internetwork within a single area. Further, that single area does not have to be area 0. The rule is that all areas must connect to the backbone; therefore, a backbone area is needed only if there is more than one area.
Each of the four routers in Figure 9.61 is configured differently to demonstrate the flexibility
of the
network area command. The configurations are:
Rubens
router ospf 10
network 0.0.0.0 255.255.255.255 area 1
Chardin
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
Goya
router ospf 30
network 192.168.20.0 0.0.0.3 area 0.0.0.0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
Matisse
router ospf 40
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
The first thing to note is that the
process IDs are different for each router. Usually these numbers are the same across an internet for consistency of configuration. Here the process IDs are configured differently merely to demonstrate that they have no meaning outside of the router. These four differently numbered processes are able to communicate.
The next thing to notice is the format of the
network area command. Following the network portion is an IP address and an inverse mask. When the OSPF process first becomes active, it will "run" the IP addresses of all active interfaces against the (address, inverse mask) pair of the first network statement. All interfaces that match will be assigned to the area specified by the area portion of the command. The process will then run the addresses of any interfaces that did not match the first network statement against the second network statement. The process of running IP addresses against network statements continues until all interfaces have been matched or until all network statements have been used. It is important to note that this process is consecutive, beginning with the first
network statement. As a result, the order of the statements can be important, as is shown in the troubleshooting section.
Note
The process of matching IP addresses to areas is consecutive, beginning with the first network statement.
Rubens' network statement will match all
interfaces on the router. The address 0.0.0.0 is really just a placeholder; the inverse mask of 255.255.255.255 is the element that does all of the work here. With "
don't care" bits placed across the entire four octets, the mask will find a match with any address and place the corresponding interface into area 1. This method provides the least precision in controlling which interfaces will run OSPF.
Chardin is an ABR between area
1 and area 0. This fact is reflected in its network statements. Here the (address, inverse mask) pairs will place any interface that is connected to any subnet of major network 192.168.30.0 in area 1 and any
interface that is connected to any subnet of major network 192.168.20.0 in the backbone area.
Goya is also an ABR. Here the (address, inverse mask) pairs will match only the specific subnets configured on the two interfaces. Notice also that the backbone area is specified in dotted decimal. Both this format and the decimal format used at Chardin will cause the associated area fields of the OSPF packets to be 0x00000000, so they are compatible.
Matisse has one interface, 192.168.10.65/26, which is not running OSPF. The network statements for this router are configured to the individual interface addresses, and the inverse mask indicates that all 32 bits must match exactly. This method provides the most precise control over which interfaces will run OSPF.
Finally, note that although Matisse's interface 192.168.10.65/26 is not running OSPF, that address is numerically the highest on the router. As a result, Matisse's
Router ID is 192.168.10.65 (Figure 9.62).
Case Study: Setting Router IDs with Loopback Interfaces
Suppose router Matisse from
Figure 9.61 has been configured in a staging center and then sent to the field to be installed. During the bootup, the router reports that it cannot allocate a Router ID, and it seems to report the
network area commands as configuration errors (Figure 9.63). Worse, the OSPF commands are no longer in the running configuration.
The problem here is that during bootup all the interfaces on the router were administratively shut down. If OSPF cannot find an active IP address for its Router ID, it cannot
start. And if the OSPF process isn't active, the subsequent network area commands will be invalid.
The solution to this problem (assuming you have a valid reason for having all physical interfaces in shutdown) is to use a loopback interface. The loopback interface, which is a virtual, software-only interface, is always up. Therefore, its IP address is always available.
The more common reason for using loopback interfaces on OSPF routers is that the interfaces allow the network administrator to control the Router IDs. When the OSPF process looks for a Router ID, OSPF will prefer the address of a loopback interface over the addresses of all physical interfaces, regardless of the numerical order. If there are multiple loopback interfaces with IP addresses, OSPF will choose the numerically highest loopback address.
Controlling the Router IDs so that
individual OSPF routers are more easily identified facilitates management and troubleshooting. The Router IDs are usually managed by one of two methods:
The first method has the disadvantage of using up the assigned network address space. The second method will preserve the legitimate addresses, but one must remember that what is bogus in one internet is legitimate in another. Using easily recognized addresses such as 1.1.1.1, 2.2.1.1, and so on is fine as long
as you remember that these are not public addresses. Care must
be taken that the bogus addresses do not leak out to the public Internet.
The configurations of the last section are modified to use loopback addresses as follows:
Rubens
interface Loopback0
ip address 192.168.50.1 255.255.255.255
!
router ospf 10
network 192.168.30.0 0.0.0.255 area 1
Chardin
interface Loopback0
ip address 192.168.50.2 255.255.255.255
!
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
Goya
interface Loopback0
ip address 192.168.50.3 255.255.255.255
!
router ospf 30
network 192.168.20.0 0.0.0.3 area 0.0.0.0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
Matisse
interface Loopback0
ip address 192.168.50.4 255.255.255.255
!
router ospf 40
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
For this example, the network address 192.168.50.0 has been set aside for exclusive use as Router IDs. Router IDs are thus easily distinguished from other IP addresses in this internet.
The first thing to note about this configuration is the address masks used with the loopback addresses: Each mask is configured as a host address. This step is not really necessary, because OSPF treats a loopback interface as a stub host; whatever (address, mask) pair is configured, the address of the loopback interface will be
advertised as a host route. The host mask is used merely
to keep things neat, and to reflect the way in which the address is advertised.
Note
OSPF advertises loopback interface addresses as host routes
However, the second point of interest makes the first somewhat irrelevant. Remember that OSPF does not have to be running on an interface for its IP address to be used as the Router ID. In fact, having OSPF advertise the loopback addresses just creates unnecessary LSAs. In the example shown, notice that the network area statements do not refer to the loopback addresses. In fact, the configuration at Rubens had to be changed. Rubens' previous command, network 0.0.0.0
255.255.255.255 area 1, would have picked up the loopback address.
Note
Benefits of loopback addresses
In addition to aiding management and troubleshooting, using loopback interfaces will also make an OSPF internet more stable. If a physical interface from which the Router ID was taken experiences a hardware failure, if the interface is administratively shut down, or if the IP address is inadvertently deleted, the OSPF process must acquire a new Router ID. Therefore, the router must prematurely age and flood its old LSAs and then flood LSAs containing the new ID. A loopback interface has no hardware components to fail. The Router ID will still have to be recalculated if the loopback interface or its IP address is inadvertently deleted, but the likelihood of a change in the loopback interface is reduced because routine
configuration
activity should not concern this interface.
Case Study: Domain Name Service Lookups
Loopback interfaces simplify the
management and troubleshooting of OSPF internets by providing predictable Router IDs. This simplification can be taken even further by recording the Router IDs in a Domain Name Service (DNS) database. The router can then be configured to consult the server address-to-name mappings, or Reverse DNS lookups, and then display the routers by name instead of by Router ID (Figure 9.64).
Goya was configured to perform
DNS lookups as follows:
ip name-server 172.19.35.2
!
ip ospf name-lookup
The first command specifies the address of the DNS server, and the second enables the OSPF process to perform DNS lookups. In some cases, a router is identified by an interface address instead of a Router ID. Adding entries to the DNS database for the router interfaces, such as rubens-e0, allows the interfaces to also be identified by name while differentiating them from the Router IDs.
The address of the name server used in this example does not belong to one of the subnets shown in Figure 9.61. The method by which this network is reached is the subject of
the next case study.
Case Study: OSPF and Secondary Addresses
Two rules are related to the use of
secondary addresses in an OSPF environment:
OSPF will advertise a secondary network or subnet only if it is also running on the primary network or subnet. OSPF sees secondary networks as
stub networks (networks on which there are no OSPF neighbors) and therefore will not send Hellos on them. Consequently, no adjacencies can be established on secondary networks.
Figure 9.65 shows the DNS server and an additional router attached to the E0 interface of Matisse. The server and the new router have addresses in subnet 172.19.35.0/25, so Matisse's E0 has been given a secondary address of 172.19.35.15/25:
interface Ethernet0
ip address 172.19.35.15 255.255.255.128 secondary
ip address 192.168.10.33 255.255.255.240
!
router ospf 40
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
network 172.19.35.15 0.0.0.0 area 192.168.10.0
With this configuration, Matisse will advertise subnet 172.19.35.0/25 to its neighbors. However, if the network area statement for 192.168.10.33 should be deleted, subnet 172.19.35.0/25 will no longer be advertised.
Because Matisse is attached to subnet 172.19.35.0/25 via a secondary address, it cannot establish an adjacency with any routers on that subnet (Figure 9.66). However, the DNS server uses
Dali as its default gateway. Therefore Matisse and Dali must be able to
route packets to each other.
An assessment of the internet as it has been described so far shows that:
Subnet 172.19.35.0/25 is being advertised into the OSPF domain; a packet with a destination address of 172.19.35.2 will be routed to Matisse's E0 interface and from there directly to the DNS server (Figure 9.67). Because the DNS server must send replies to network addresses different than its own, it will send the replies to Dali for routing. Dali is not exchanging routing information with Matisse, so it does not know how to reach the networks within the
OSPF autonomous system.
So the one step needed to "close the circuit" is
to tell Dali how to reach the OSPF networks. This is easily done with a static route:
Dali(config)#ip route 192.168.0.0 255.255.0.0 172.19.35.15
Note that static routes are classless, so the one supernet entry can be used to match all addresses within the
OSPF autonomous system.
In this example, Matisse is not an
ASBR. Although it sends packets to destinations outside of the autonomous system, it is not accepting any information about exterior destinations and therefore is not originating any type 5 LSAs.
Figure 9.68 shows a new set of destinations reachable via Dali. Matisse must now become an ASBR and advertise the routes into the OSPF domain. However, it must first learn the routes. This task can be done by configuring static routes or by running a routing protocol that will communicate over the secondary network. In either case, the routes must then be redistributed into OSPF.
RIP, which has no difficulties with secondary addresses, is chosen to communicate with Dali. Matisse's
configuration is as follows:
interface Ethernet0
ip address 172.19.35.15 255.255.255.128 secondary
ip address 192.168.10.33 255.255.255.240
!
router ospf 40
redistribute rip metric 10
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
!
router rip
network 172.19.0.0
This configuration enables RIP
on the secondary network of E0, allowing Matisse to learn routes from Dali (Figure 9.69). The routes are redistributed into OSPF, (which is no longer running on the secondary address) and assigned an OSPF cost of 10, with the
command redis
tribute rip metric 10. See Chapter 11 for more details on redistribution. Figure 9.70 shows that the routes are advertised into the OSPF domain with default
external type 2 (E2) metrics; notice that at Rubens the cost of these routes is still 10. Matisse advertises these external destinations with type 5 LSAs, making
it an ASBR (Figure 9.71).
Case Study: Stub Areas
Because no type 5 LSAs are being
originated within area 1, it can be configured as a stub area. Note that when an attached area is configured as a stub area, the Hellos originated by the router into that area will have E = 0 in the Options field. Any router receiving these Hellos, which is not similarly configured, will drop the packets, and an adjacency will not be established. If there is an existing adjacency, it will be broken. Consequently, if an operational area is going to be reconfigured as a stub area, downtime should be scheduled; routing will be disrupted until all routers are reconfigured.
A stub area is configured by
adding the
area stub command to the OSPF process:
Rubens
router ospf 10
network 0.0.0.0 255.255.255.255 area 1
area 1 stub
Chardin
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
area 1 stub
Comparing the link state database of Rubens before (Figure 9.72) and after (Figure 9.73) the configured stub area shows that all autonomous system external LSAs and ASBR summary LSAs have been eliminated from the database. In this case, the size of the database has been reduced by 50%.
When a stub area is attached to an ABR, the router will automatically advertise a default route (destination 0.0.0.0) into the area via a Network Summary LSA. The database summary in Figure 9.73 indicates this additional type 3 LSA. The last
entry in Rubens's route table (Figure 9.74) shows the default route advertised by Chardin.
The ABR will advertise a default route with a cost of 1. The cost of the serial link between Rubens and Chardin is 64; Figure 9.74 shows the total cost of the default route to be 64 + 1 = 65. This default cost can be changed with
the
area default-cost command. For example, Chardin can be configured to advertise the default route with a cost of 20 as follows:
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
area 1 stub
area 1 default-cost 20
The resulting cost increase, 64 + 20 = 84, can be seen in Figure 9.75. Changing the cost of the default route has no real benefit here but may be useful in stub areas with more than one ABR. Normally, each Internal Router would merely choose the default route with the lowest cost. By manipulating the advertised cost, the network administrator could cause all Internal Routers to use the same ABR. The second ABR, advertising a higher cost, would be used
only if the first were to fail.
Case Study: Totally Stubby Areas
Totally stubby areas are configured by placing the keyword no-sum
mary at the end of the
area stub command. This step is necessary only at the ABR; the Internal Routers use the standard stub area configuration. To make area 1 of the sample internet a totally stubby area, Chardin's configuration would be:
router ospf 20
network 192.168.30.0 0.0.0.255 area 1
network 192.168.20.0 0.0.0.255 area 0
area 1 stub no-summary
Figure 9.76 shows that the LSAs in Rubens' database have been reduced to three; Figure 9.77 shows the
route table.
Case Study: Not-So-Stubby Areas
The earlier case study, "OSPF and Secondary Interfaces," left off with Matisse accepting routes
from Dali via RIP and redistributing them into the OSPF domain (see Figure 9.68). This step makes Matisse an ASBR and by extension makes area 192.168.10.0 ineligible to become a stub or totally stubby area. However, there is no need for AS External LSAs to enter the area from the backbone area; therefore area 192.168.10.0 can be configured as an
NSSA. The configuration at Matisse is:
router ospf 40
redistribute rip metric 10
network 192.168.10.2 0.0.0.0 area 192.168.10.0
network 192.168.10.33 0.0.0.0 area 192.168.10.0
area 192.168.10.0 nssa
!
router rip
network 172.19.0.0
The same
area nssa statement shown here
is configured at Goya. Since Goya is an ABR, it will translate type 7 LSAs received on the NSSA-attached interface into type 5 LSAs. FThese translated LSAs will be flooded into the backbone and hence to the other areas. Comparing the route tables of Goya and Chardin shows that Goya has tagged the external routes as NSSA (Figure 9.78). Chardin has tagged the routes as E2 (Figure 9.79), indicating that they have been learned from type 5 LSAs.
This translation can also be observed by examining Goya's database. Figure 9.80 shows that the database contains both type 7 and type 5 LSAs to the same external routes. The originating router for the type 7 LSAs is Matisse, whereas the originating router for the type 5 LSAs is Goya.
Several configuration options are available for the ABR. First, the no-summary option can be used with the area nssa command to block the flooding of type 3 and type 4 LSAs into the NSSA. To turn area 192.168.10.0 into a somewhat schizophrenically named "totally stubby not-so-stubby" area, Goya's configuration would be:
router ospf 30
network 192.168.20.0 0.0.0.3 area 0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
area 192.168.10.0 nssa no-summary
Matisse's route table (Figure 9.81) shows the elimination of all inter-area routes and the addition of a default route
advertised by Goya.
In Figure 9.82, the link to Dali ha
s been moved from Matisse to Goya; the IP address has also moved. Goya is now an ASBR redistributing RIP-learned routes into OSPF.
When an ABR is also an ASBR and is connected to a not-so-stubby area, the default behavior is to advertise the redistributed routes into the NSSA as shown in Figure 9.83.
The default redistribution may be turned off on an ABR/ASBR by adding the
statement no-redistribution to the
area nssa command. In the sample internet, no types 3, 4, 5, or 7 LSAs
should be sent into area 192.168.10.0 from the ABR. The
desired redistribition is accomplished by the following configuration at Goya:
interface Ethernet0
ip address 172.19.35.15 255.255.255.128
!
router ospf 30
redistribute rip metric 10 metric-type 1
network 192.168.20.0 0.0.0.3 area 0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
area 192.168.10.0 nssa no-redistribution no-summary
!
router rip
network 172.19.0.0
Here the
area nssa command blocks type 5 LSAs from entering the area through Goya;
no-redistribution blocks type 7 LSAs, and no-summary blocks types 3 and 4. As before, the no-summary command also causes Goya to send a single type 3 LSA into the area to advertise a default route. Figure 9.84 shows Matisse's route table after type 7 redistribution is disabled at Goya. Note that the external networks are still reachable, even though they are not in the table, because of the default route.
In the final example, Goya is to allow types 3 and 4 LSAs into the NSSA, but not types 5 and 7. The problem is that when the no-sum
mary statement is removed, the ABR will no longer originate a type 3 LSA advertising a default route.
Without a default route, the exterior destinations will not be reachable from within the NSSA. The statement
default-information-originate, added to the area nssa command, will cause the ABR to advertise a default route into the NSSA—this time, with a type 7 LSA. Using this
statement, Goya's OSPF configuration is:
router ospf 30
redistribute rip metric 10 metric-type 1
network 192.168.20.0 0.0.0.3 area 0
network 192.168.10.0 0.0.0.31 area 192.168.10.0
area 192.168.10.0 nssa no-redistribution no-summary
Figure 9.85 shows Matisse's route table after the reconfiguration. The table contains inter-area routes and a default route with an N2 tag indicating that the route was learned
from a type 7 LSA.
Case Study: Address Summarization
Although stub areas conserve
resources within non-backbone areas by preventing certain LSAs from entering, these areas do nothing to conserve resources on the backbone. All addresses within an area are still advertised out to the backbone. This situation is where address summarization can help. Like stub areas, address summarization conserves resources by reducing the number of LSAs flooded. It also conserves resources by hiding instabilities. For example, a "flapping" subnet will cause LSAs to be flooded throughout the
internetwork at each state transition. However, if that subnet
address is subsumed by a summary address, the individual subnet and its instabilities are no longer advertised.
Note
Inter-area and external router summarization
Cisco's OSPF can perform two types of address summarization:
inter-area summarization and external route summarization. Inter-area summarization is, as the name implies, the summarization of addresses between areas; this type of summarization is always configured on ABRs. External route summarization allows a set of external addresses to be redistributed into an OSPF domain
as a summary address and is configured on ASBRs.
Inter-area summarization is covered in this section, and external route summarization
is covered in Chapter 11.
In Figure 9.86, area 15 contains eight subnets: 10.0.0.0/16 through 10.7.0.0/16. Figure 9.87 shows that these addresses can be represented with the single summary address 10.0.0.0/13.
An ABR can be configured to advertise a summary address either into the backbone area or into a non-backbone area. Best practice dictates that a non-backbone area's addresses should be summarized into the backbone by its own ABR, as opposed to having all other ABRs summarize the area into their areas. Then, from the backbone area, the summary will be advertised across the backbone and into the other areas. This both simplifies the router configurations and reduces the size of the LS database in the backbone.
The
area range command specifies the area to which the summary address belongs, the summary
address, and the address mask. Recall from Chapter 8, "Enhanced Interior Gateway Routing Protocol (EIGRP),"
that when a summary route is configured for EIGRP, a route to the null interface is automatically entered into the route table to prevent black holes and route loops. Unlike EIGRP, OSPF does not enter this route automatically. Therefore, whenever you are configuring summary routes within an OSPF domain, be sure to add a static route for the summary address, pointing to the null interface.
Pena's OSPF configuration is:
router ospf 1
network 10.0.0.0 0.7.255.255 area 15
network 10.8.0.0 0.7.255.255 area 0
area 15 range 10.0.0.0 255.248.0.0
!
ip route 10.0.0.0 255.248.0.0 Null0
Figure 9.87 shows that the range of addresses represented by 10.0.0.0/13 is contiguous—that is, the three bits that are summarized constitute every combination from 000 to 111. The addresses in area 25 are different. These do not form a contiguous range. They may, however, still be summarized with the
following configuration at Hurd:
router ospf 1
network 10.8.0.0 0.0.255.255 area 0
network 172.20.0.0 0.0.255.255 area 25
area 25 range 172.16.0.0 255.240.0.0
!
ip route 172.16.0.0 255.240.0.0 Null0
This summary will work, even if some of the addresses in the range appear elsewhere in the internetwork. In Figure 9.88, network 172.17.0.0/16 is in area 15, although it belongs to the set of addresses being summarized from area 25. Pena advertises this address into the backbone area, where Hurd learns it and advertises it into area 25. The accompanying mask is more specific (that is, longer) than the mask of the summary address 172.16.0.0/12; because OSPF is classless, it will route destination addresses belonging to 172.17.0.0 to the correct destination.
Although the address configuration of Figure 9.88 will work, it is an undesirable design practice. The point of summarization is to conserve resources; network 172.17.0.0/16 must be advertised across the backbone independently of 172.16.0.0/12. Such a design also creates the potential for route loops if default addresses are used. This problem is discussed in Chapter 12, "Default Routes and On-Demand Routing."
Notice also in Figure 9.88 that subnets 172.16.27.0/25 (at Gorman) and 172.16.27.192/29 (at Okeeffe) are
discontiguous. Again
because OSPF is a classless routing protocol, Gorman and Okeeffe do not act as network border routers. The subnets and their masks are advertised into network 172.20.0.0, and no routing
ambiguities will occur.
Case Study: Authentication
OSPF packets can be
authenticated to prevent inadvertent or intentional introduction of bad routing information. Table 9.8 lists the types of authentication available. Null authentication (type 0), which means no authentication information is included in the packet header, is the default. Authentication using simple clear-text passwords (type 1) or
MD5 cryptographic checksums (type 2) can be configured. When authentication is configured, it must be configured for an entire area.
If increased network security is the objective, type 1 authentication should be used only when devices within an area cannot support the more secure type 2 authentication. Clear-text authentication leaves the internetwork vulnerable to a "sniffer attack," in which packets are captured by a protocol analyzer and the passwords are read (see Chapter 7 and especially Figure 7.8). However, type 1 authentication can be useful when performing OSPF reconfigurations. For example, separate passwords can be used on "old" OSPF routers and "new" OSPF routers sharing a common broadcast network to prevent them from talking to each other.
To configure type 1 authentication for an area, the command
ip ospf authentication-keyis used to assign a password of up to eight octets to each interface attached to the area. The passwords do not have to be the same throughout the area, but must be the same between neighbors. Type 1 authentication is then enabled by entering the
area authentication command to the OSPF configuration.
Referring to Figure 9.88, type 1 authentication is enabled for areas 0 and 25. Hurd's configuration is:
interface Ethernet0
ip address 10.8.1.1 255.255.255.0
ip ospf authentication santafe
!
interface Serial0
ip address 172.20.1.1 255.255.255.252
ip ospf authentication taos
!
interface Serial1
ip address 172.20.1.5 255.255.255.252
ip ospf authentication abiquiu
!
router ospf 1
network 10.8.0.0 0.0.255.255 area 0
network 172.20.0.0 0.0.255.255 area 25
area 25 range 172.16.0.0 255.240.0.0
area 0 authentication
area 25 authentication
The password "santafe" is used between Hurd and Pena; "taos" is used between Hurd and Gorman, and "abiquiu" is used between Hurd and Okeeffe.
The
MD5 algorithm, used by type 2 authentication, computes a hash value from the OSPF packet contents and a password (or key). This hash value is transmitted in the packet, along with a key ID and a non-decreasing sequence number. The receiver, knowing the same password, will calculate its own hash value. If nothing in the message has changed, the receiver's hash value should match the sender's value transmitted with the message. The
key ID allows routers to reference multiple passwords, making password changes easier and more secure. An example of password migration is included in this case study. The sequence number prevents "replay attacks," in which OSPF packets are captured, modified, and retransmitted to a router.
To configure type 2 authentication for an area, the
command ip ospf message-digest-key md5 assigns a password of up to 16 bytes and key ID between 1 and 255 to each interface attached to the area. Like type 1, the passwords do not have to be the same throughout the area, but both the key ID and the password must be the same between neighbors. Type 2 authentication is then enabled by entering the
area authentication message-digest command to the OSPF configuration.
Hurd is configured to use type 2 authentication as follows:
interface Ethernet0
ip address 10.8.1.1 255.255.255.0
ip ospf message-digest-key 5 md5 santafe
!
interface Serial0
| 
