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 ConfigurationThe three steps necessary to begin a basic OSPF process are:
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; [23] 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. [24] 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. Figure 9.61. Chardin and Goya are ABRs; Rubens and Matisse are Internal Routers. 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
Chardin
Goya
Matisse
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). Figure 9.62. The command show ip ospf process-id displays process-specific information. The first line here shows that the Router ID is 192.168.10.65. Case Study: Setting Router IDs with Loopback InterfacesSuppose 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. Figure 9.63. OSPF will not boot if it cannot find an active IP address for its Router ID. 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
Chardin
Goya
Matisse
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, [25] 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 LookupsLoopback 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). Figure 9.64. OSPF can be configured to use DNS to map Router IDs to names for use in some show commands. Goya was configured to perform DNS lookups as follows:
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 AddressesTwo rules are related to the use of secondary addresses in an OSPF environment:
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:
Figure 9.65. Router Dali and the DNS server are not part of the OSPF domain and are attached to Matisse via a secondary network address. 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. Figure 9.66. This analyzer capture is from the network to which Matisse, Dali, and the DNS server are attached. The smaller window shows that Hellos are only being sourced from Matisse's primary address of 192.168.10.33. The larger window shows a decode of one of the Hellos. An assessment of the internet as it has been described so far shows that:
Figure 9.67. The MAC identifier of the DNS server is recorded in Matisse's ARP cache, indicating that the server can be reached directly. If packets destined for the server had to be routed through Dali, the MAC identifier for both the server and for Dali would be 0000.0c0a.2aa9 in this cache. 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:
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. Figure 9.68. The OSPF autonomous system must learn about the destinations reachable via Dali, but Matisse's secondary address to Dali prevents the two routers from sharing information via OSPF. RIP, which has no difficulties with secondary addresses, is chosen to communicate with Dali. Matisse's configuration is as follows:
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). Figure 9.69. Dali has passed its routing information to Matisse via RIP. Figure 9.70. The RIP-learned routes are redistributed into the OSPF autonomous system as path type E2. Figure 9.71. Matisse (RID = 192.168.50.4) is now an ASBR because it is originating autonomous system external LSAs to advertise the external routes. Case Study: Stub AreasBecause 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
Chardin
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%. Figure 9.72. Reubens's database has a total of 14 LSAs before area 1 is configured as a stub area. Figure 9.73. The stub area configuration eliminates the seven type 5 LSAs and the single type 4 LSA from Rubens's database. One type 3 LSA, which advertises the default route, has been added. 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. Figure 9.74. Rubens's route table shows that all external routes have been eliminated (compare this to Figure 9.70) and that a default route has been added. 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:
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. Figure 9.75. Rubens's route table reflects the results of changing the cost of the default route. Case Study: Totally Stubby AreasTotally 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:
Figure 9.76 shows that the LSAs in Rubens' database have been reduced to three; Figure 9.77 shows the route table. Figure 9.76. Changing area 1 to a totally stubby area eliminates all but one of the type 3 LSAs (the default route). Figure 9.77. A route table in a totally stubby area will contain only intra-area routes and the default route. Case Study: Not-So-Stubby AreasThe 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:
Figure 9.78. The external routes learned from Matisse are tagged as NSSA routes at Goya. 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 [26] (Figure 9.78). Chardin has tagged the routes as E2 (Figure 9.79), indicating that they have been learned from type 5 LSAs.
Figure 9.79. Chardin has tagged the same routes as E2, indicating they have been learned from autonomous system external 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. Figure 9.80. Goya's link state database indicates that the type 7 LSAs from Matisse (192.168.50.4) have been translated into type 5 LSAs by Goya (192.168.50.3). 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:
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. Figure 9.81. All inter-area routes have been replaced with a default route to the ABR. 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. Figure 9.82. The link to Dali has moved to Goya, which now speaks RIP to Dali and redistributes the 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. Figure 9.83. An ABR that is also an ASBR will advertise the external routes into an NSSA with type 7LSAs. In this example, Goya is advertising the external routes with an N1 mettric type. 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: [27]
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. Figure 9.84. After no-redistribution is added to Goya's area nssa command, the route table of Figure 9.83 no longer contains routes learned from type 7LSAs. 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:
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. Figure 9.85. Adding the default-information-orgininate statement to the area nssa command causes the ABR to advertise a default route into an NSSA. Case Study: Address SummarizationAlthough 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. Figure 9.86. The addresses in areas 15 and 25 can summarized into the backbone area. Figure 9.87. The summary address 10.0.0.0/13 represents the range of addresses from 10.0.0.0/16 to 10.7.0.0/16. 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 . [28] 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:
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:
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." Figure 9.88. Network 172.17.0.0 is in area 15, although it is within the range of addresses summarized by 172.16.0.0/12. 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: AuthenticationOSPF 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-key is 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:
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:
Note Changing passwords without disabling authentication The key allows the password to be changed without having to disable authentication. For example, to change the password between Hurd and Okeeffe, the new password would be configured with a different key. Hurd's configuration would be:
Hurd will now send duplicate copies of each OSPF packet out S1; one will be authenticated with key 15, the other with key 20. When Hurd begins receiving OSPF packets from Okeeffe authenticated with key 20, it will stop sending packets with key 15. Once the new key is in use, the old key can be removed from both routers with the command no ip ospf message-digest-key 15 md5 abiquiu . The passwords in an operational internetwork should never be as predictable as the ones used in these examples. Adding the command service password-encryption to the configuration file of all routers using authentication is also wise. This change will cause the router to encrypt the passwords in any display of the configuration file, thereby guarding against the password being learned by simply observing a text copy of the router's configuration. With encryption, a display of Hurd's configuration would include:
Case Study: Virtual LinksFigure 9.89 shows an internetwork with a poorly designed backbone area. If the link between routers Hokusai and Hiroshige fails, the backbone will be partitioned. As a result, routers Sesshiu and Okyo will be unable to communicate with each other. If these two routers are ABRs to separate areas, inter-area traffic between those areas will also be blocked. Figure 9.89. A failure of the link between Hokusai and Hiroshige will partition the backbone area. The best solution to this vulnerability is to add another link to the backbone area ”between Sesshiu and Okyo, for instance. An interim solution, until the backbone can be improved, is to create a virtual link between Hokusai and Hiroshige through area 100. Virtual links are always created between ABRs, at least one of which must be connected to area 0. [29] At each ABR, the area virtual-link command, added to the OSPF configuration, specifies the area through which the virtual link will transit and the Router ID of the ABR at the far end of the link. A virtual link is configured between Hokusai and Hiroshige as follows:
Hokusai
Hiroshige
Packets will normally travel between Sesshiu and Okyo on the backbone link between Hokusai and Hiroshige. If that link fails, the virtual link will be used. Although each router sees the link as an unnumbered point-to-point network (Figure 9.90), in reality the packets are being routed via Kujomoto. Figure 9.90. The state of a virtual link can be observed with the command show ip ospf virtual-link. Case Study: OSPF on NBMA NetworksNon-broadcast multi-access networks such as X.25, frame relay, and ATM present a problem for OSPF. Multi-access means that the NBMA "cloud" is a single network to which multiple devices are attached, the same as Ethernet or Token Ring networks (Figure 9.91). But unlike Ethernet and Token Ring, which are broadcast networks, non-broadcast means a packet sent into the network might not be seen by all other routers attached to the network. Because an NBMA network is multi-access, OSPF will want to elect a DR and BDR. But since an NBMA network is non-broadcast, there is no guarantee that all attached routers will receive the Hellos of all other routers. Therefore, all routers may not automatically learn about all its neighbors, and DR election would not function correctly. Figure 9.91. Routing protocols view NBMA networks as a single subnet to which multiple devices are connected. But when an NBMA network is partially meshed, as it is here, not all attached routers have direct connectivity with all other attached routers. This section examines several solutions to the NBMA problem. The selection of a particular solution depends on the characteristics of the internetwork upon which the solution is to be implemented. The oldest solution, pertinent to pre-10.0 versions of the Cisco IOS, is to manually identify each router's neighbors and establish the DR, using the neighbor command. Figure 9.92 shows a frame relay network with four attached routers. Figure 9.92. Several options exist for configuring OSPF on this NBMA network. Because of the partially-meshed hub-and-spoke configuration of the PVCs in Figure 9.92, Rembrandt must become the DR. As the hub, it is the only router directly connected to all the other routers. The configurations of the four routers are: Rembrandt
Hals
Vandyck
Brueghel
The neighbor command configures Rembrandt with the IP addresses of the interfaces of its three neighbors. The default priority is zero; by not changing the default at Rembrandt, none of its neighbors is eligible to become the DR or BDR. The other three routers are configured with only Rembrandt as a neighbor; the priority is set to 10, which means Rembrandt will become the DR. By making Rembrandt the DR, the PVCs exactly emulate the adjacencies that would have formed if the four routers had been connected to a broadcast multi-access network. OSPF packets will now be unicast to the configured neighbor addresses. To repeat, the neighbor command is necessary only with old (pre-10.0) versions of IOS. A newer solution is to use the ip ospf network command to change the default OSPF network type. One option with this command is to change the network type to broadcast, with ip ospf network broadcast entered at every frame relay interface. This change will cause the NBMA cloud to be viewed as a broadcast network; the configuration of the four routers is: Rembrandt
Hals
Vandyck
Brueghel
Note in this example that the priority of Rembrandt's interface is set to 10, and the priority of the other interfaces is set to 0. This will, again, ensure that Rembrandt is the DR. Note also that the static frame relay mapping commands are set to forward broadcast and multicast addresses. An alternative to influencing the DR election is to implement a fully meshed topology in which every router has a PVC to every other router. From the standpoint of the router, this solution is actually the most efficient of all the NBMA implementation alternatives. The obvious drawback of this approach is monetary cost. If there are n routers, n ( n - 1)/2 PVCs will be necessary to create a fully meshed topology. For example, the 4 routers of Figure 9.92 would need 6 PVCs for a full mesh; 16 routers would require 120 PVCs. Another option is to avoid the DR/BDR election process altogether, by changing the network type to point-to-multipoint. Point-to-multipoint networks treat the PVCs as a collection of point-to-point links; therefore, no DR/BDR election takes place. In multivendor environments, point-to-multipoint may be the only alternative to broadcast networks. In the following configurations, the OSPF network type associated with each interface is changed to point-to-multipoint: Rembrandt
Hals
Vandyck
Brueghel
These configurations take advantage of the frame relay inverse ARP function to dynamically map network-level addresses to the DLCIs, instead of using the static map commands shown in the previous examples. Static maps can still be used if desired. The OSPF point-to-multipoint network type treats the underlying network as a collection of point-to-point links rather than a multi-access network, and OSPF packets are multicast to the neighbors. This situation can be problematic for networks whose connections are dynamic, such as frame relay SVCs or ATM SVCs. Beginning with IOS 11.3AA, this problem can be solved by declaring a network to be both point-to-multipoint and non-broadcast: Rembrandt
Hals
Vandyck
Brueghel
Because the network is non-broadcast, neighbors are not discovered automatically and must be manually configured. Another feature introduced in IOS 11.3AA can be seen in Rembrandt's configuration: Cost can be assigned on a per VC basis with the neighbor command. The last solution is to establish each PVC as an individual point-to-point network with its own subnet (Figure 9.93). This solution is accomplished with subinterfaces: Rembrandt
Hals
Vandyck
Brueghel
Figure 9.93. Point-to-point sub-interfaces allow each PVC to be configured as an individual subnet and eliminate the problem of DR/BDR election on NBMA networks. Note Benefits of establishing each PVC as a point-to-point network for OSPF over NBMA This configuration is the most easily managed of all the configurations of OSPF over NBMA networks. Some of the advantages are evident in the configuration code, such as the ability to use an interface number that corresponds to the DLCI and the inclusion of a description line. The major advantage, however, is the simple one-to-one relationship between routers. An occasional objection to the use of subinterfaces is that each PVC must have its own subnet address. In most cases, this requirement should not be a problem, because OSPF supports VLSM. As the example shows, creating sub-subnets from the subnet address that was assigned to the cloud is an easy matter. And because the PVCs are now point-to-point links, IP unnumbered may be used as an alternative to subnet addresses. A more serious concern with subinterfaces is that they require more memory. The burden can be significant on small routers with limited memory. Case Study: OSPF over Demand CircuitsOSPF over demand circuits is easily configured by adding the command ip ospf demand-circuit to the interface connected to the demand circuit. Only one end of a point-to-point circuit, or the multipoint side of a point-to-multipoint circuit, needs to be declared a demand circuit. In most cases, OSPF over demand circuits should not be implemented across a broadcast medium. On such a network, the Hello packets cannot be suppressed, and the link will stay up. If the virtual circuits in Figure 9.92 are frame relay SVCs, Rembrandt's configuration might be as follows:
Keep the following points in mind when implementing OSPF over demand circuits:
|
![Routing TCP[s]IP (Vol. 11998)](/icons/blank_book.jpg "Routing TCP[s]IP (Vol. 11998)"){kind=icon}