IPV6: OSPF Konfigurasi
Case Study: A Basic OSPF Configuration
The three steps necessary to begin a basic OSPF process are
Step 1. Determine the area to which each router interface will be attached. Step 2. Enable OSPF with the command router ospf process-id. Step 3. 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; [25] the process ID merely distinguishes one process from another within the device. [25]
Although the use of multiple processes on one router is possible, it is highly discouraged because of the demands that the multiple databases will place on router resources.The network command used with RIP allows only the specification of a major network address. If some interfaces within the network should not run the routing protocol, the passive-interface command has to be used with those protocols. As is the network command used with the wildcard mask for EIGRP, the network area command is much more flexible then the network command used for RIP and EIGRP before the wildcard option was introduced, 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. [26] The area can be specified in either decimal or dotted decimal. [26]
See Appendix B, "Tutorial: Access Lists," for a tutorial on the use of inverse masks.
Figure 8-43 shows an OSPF network. 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 network 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 8-43. Chardin and Goya are ABRs; Rubens and Matisse are Internal Routers.Each of the four routers in Figure 8-43 is configured differently to demonstrate the flexibility of the network area command. The configurations are displayed in Example 8-19 through Example 8-22:
Example 8-19. Rubens's OSPF network area configuration.
router ospf 10 network 0.0.0.0 255.255.255.255 area 1
Example 8-20. Chardin's OSPF network area configuration.
router ospf 20 network 192.168.30.0 0.0.0.255 area 1 network 192.168.20.0 0.0.0.255 area 0Example 8-21. Goya's OSPF network area configuration. 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
Example 8-22. Matisse's OSPF network area configuration.
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 statementshave 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. Rubens's 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 (Example 8-23). Example 8-23. The command show ip ospf process-id displays process-specific information.
Matisse#show ip ospf 40 Routing Process "ospf 40" with ID 192.168.10.65 Supports only single TOS(TOS0) routes Supports opaque LSA Supports Link-local Signaling (LLS) Initial SPF schedule delay 5000 msecs Minimum hold time between two consecutive SPFs 10000 msecs Maximum wait time between two consecutive SPFs 10000 msecs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs LSA group pacing timer 240 secs Interface flood pacing timer 33 msecs Retransmission pacing timer 66 msecs Number of external LSA 0. Checksum Sum 0x000000 Number of opaque AS LSA 0. Checksum Sum 0x000000 Number of DCbitless external and opaque AS LSA 0 Number of DoNotAge external and opaque AS LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa External flood list length 0 Area 192.168.10.0 Number of interfaces in this area is 2 Area has no authentication SPF algorithm last executed 00:47:42.792 ago SPF algorithm executed 4 times Area ranges are Number of LSA 5. Checksum Sum 0x02A444 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0
Case Study: Setting Router IDs with Loopback
InterfacesSuppose router Matisse from Figure 8-43 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 (Example 8-24). Worse, the OSPF commands are no longer in the running configuration.
Example 8-24. OSPF will not boot if it cannot find an active IP address for its Router ID.
Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-J1S3-M), Version 12.3(6), RELEAS Copyright (c) 1986-2004 by Cisco Systems, Inc. Compiled Wed 11-Feb-04 19:24 by kellythw Image text-base: 0x80008098, data-base: 0x8199F778 cisco 2621 (MPC860) processor (revision 0x200) with 61440K/4096 Processor board ID JAD05090PW2 (1141326406) M860 processor: part number 0, mask 49 Bridging software. X.25 software, Version 3.0.0. TN3270 Emulation software. 2 FastEthernet/IEEE 802.3 interface(s) 1 Serial network interface(s) 32K bytes of non-volatile configuration memory. 16384K bytes of processor board System flash (Read/Write) network 192.168.10.2 0.0.0.0 area 192.168.10.0 ^ % Invalid input detected at '^' marker. network 192.168.10.33 0.0.0.0 area 192.168.10.0 ^ % Invalid input detected at '^' marker.Press RETURN to get started!
%OSPF-4-NORTRID: OSPF process 40 cannot start. There must be at least one "up" IP interface, for OSPF to use as 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: Set aside a legitimate network or subnet address to be used strictly for Router IDs.
Use a "bogus" IP address range.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 displayed in Example 8-25 through Example 8-28.
Example 8-25. A Loopback interface is added to Rubens's configuration.
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 Example 8-26. A Loopback interface is added to Chardin's configuration. 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
Example 8-27. A Loopback interface is added to Goya's configuration.
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 Example 8-28. A Loopback interface is added to Matisse's configuration. 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.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's previous command, network 0.0.0.0 255.255.255.255 area 1, would have picked up the loopback address. In addition to aiding management and troubleshooting, using loopback interfaces will also make an OSPF internet more stable. In some early versions of IOS, if a physical interface from which the Router ID was taken experiences a hardware failure, [27] 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 current IOS behavior is to obtain the Router ID; if the interface associated with the Router ID fails or the IP address is deleted, the router retains the Router ID until the router is reloaded or the OSPF process is reset. [27]
Merely disconnecting the interface will not cause the Router ID to change.
Another option is to manually assign a Router ID to the router with the
OSPF command router-id. As with the Router ID address assignment
using loopback interfaces, you can arbitrarily choose an IP address to
use as the value of the router-id command. If a Router ID is configured
using this command, this command's value will become the router ID
when the OSPF process is reset or the router is reloaded. When the
router is reloaded, however, there still has to be an interface with an IP
address that comes up before the OSPF process can start. After the
OSPF process starts, the address assigned with the router-id command
will become the Router ID.
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 (Example 8-29). Example 8-29. OSPF can be configured to use DNS to map Router IDs to names for use in some show commands.
Goya#show ip ospf neighbor Neighbor ID Pri State chardin 0 FULL/ matisse 0 FULL/
Goya#show ip ospf database - - Dead Time 00:00:36 00:00:34 Address 192.168.20.1 192.168.10.2 Int Ser Ser OSPF Router with ID (192.168.50.3) (Process ID 30) Router Link States (Area 0.0.0.0) Link ID 192.168.50.2 192.168.50.3 ADV Router chardin goya Age 78 78 Seq# Checksum 0x80000007 0x005A70 0x80000008 0x004C7B Summary Net Link States (Area 0.0.0.0) Link ID 192.168.10.0 192.168.10.32 192.168.30.0 192.168.30.8 ADV Router goya goya chardin chardin Age 74 54 85 100 Seq# 0x80000001 0x80000001 0x80000001 0x80000001 Router Link States (Area 192.168.10.0) Checksum 0x00B356 0x00DCFB 0x007766 0x001DB9Link ID 192.168.50.3 192.168.50.4 --More- ADV Router goya matisse Age 68 67 Seq# Checksum 0x80000007 0x0024D3 0x80000007 0x00E080
Goya was configured to perform DNS lookups as shown in Example 8-30.
Example 8-30. Goya is configured to perform DNS lookups.
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 8-43. 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 8-44 shows the DNS server and an additional router attached to the FA0/0 interface of Matisse. The server and the new router have addresses in subnet 172.19.35.0/25, so Matisse's FA0/0 has been given a secondary address of 172.19.35.15/25 (see Example 8-31). Figure 8-44. Router Dali and the DNS server are not part of the OSPF domain and are attached to Matisse via a secondary network address.Example 8-31. Matisse is configured with a secondary address.
interface FastEthernet0/0 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 8-45). However, the DNS server uses Dali as its default gateway. Therefore Matisse and Dali must be able to route packets to each other. Figure 8-45. 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.
[View full size image]
An assessment of the internet as 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 FA0/0 interface and from there directly to the DNS server (Example 8-32).
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.
Example 8-32. 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 servercan 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.
Matisse#show arp Protocol Address Age (min) Internet 192.168.10.65 - Internet 192.168.10.33 - Internet 172.19.35.15 - Internet 172.19.35.1 1 Internet 172.19.35.2 22 Hardware Addr 0005.5e6b.50a1 0005.5e6b.50a0 0005.5e6b.50a0 0010.7b3c.6bd3 0002.6779.0f4c Type ARPA ARPA ARPA ARPA ARPA Interfa FastEth FastEth FastEth FastEth FastEth
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 8-46 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 8-46. The OSPF autonomous system must learnFigure 8-46. 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.
[View full size image]
RIP, which has no difficulties with secondary addresses, is chosen to communicate with Dali. Matisse's configuration is as shown in Example 8-33.
Example 8-33. RIP is added to Matisse's configuration.
interface FastEthernet0/0 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 subnets 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 FA0/0, allowing Matisse to learn routes from Dali (Example 8-34). 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 redistribute rip metric 10 subnets. See Chapter 11, "Route Redistribution," for more details on redistribution. Example 8-35 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 (Example 8-36).
Example 8-34. Dali has passed its routing information to Matisse via RIP.
Matisse#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is not set R R 192.168.90.0/24 [120/1] via 172.19.35.1, 00:00:09, FastEth 192.168.105.0/24 [120/1] via 172.19.35.1, 00:00:09, FastEt 192.168.30.0/29 is subnetted, 2 subnets O IA 192.168.30.0 [110/193] via 192.168.10.1, 02:12:53, Seri O IA 192.168.30.8 [110/192] via 192.168.10.1, 02:12:53, SeriR C C C C R 192.168.60.0/24 [120/1] via 172.19.35.1, 00:00:09, FastEth 192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks 192.168.10.64/26 is directly connected, FastEthernet0/1 192.168.10.32/28 is directly connected, FastEthernet0/0 192.168.10.0/27 is directly connected, Serial0/0.1 172.19.0.0/25 is subnetted, 1 subnets 172.19.35.0 is directly connected, FastEthernet0/0 192.168.80.0/24 [120/1] via 172.19.35.1, 00:00:10, FastEth 192.168.20.0/30 is subnetted, 1 subnets O IA 192.168.20.0 [110/128] via 192.168.10.1, 02:13:06, Seri 192.168.50.0/32 is subnetted, 1 subnets C 192.168.50.4 is directly connected, Loopback0 R 192.168.70.0/24 [120/1] via 172.19.35.1, 00:00:13, FastEth R 192.168.100.0/24 [120/1] via 172.19.35.1, 00:00:13, FastEt R 192.168.101.0/24 [120/1] via 172.19.35.1, 00:00:13, FastEt
Example 8-35. The RIP-learned routes are redistributed into the OSPF autonomous system as path type E2.
Rubens#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is not set O E2 192.168.90.0/24 [110/10] via 192.168.30.10, 02:25:59, Seri O E2 192.168.105.0/24 [110/10] via 192.168.30.10, 02:25:59, SerC C O E2 O IA O IA O E2 192.168.30.0/29 is subnetted, 2 subnets 192.168.30.0 is directly connected, FastEthernet0/0 192.168.30.8 is directly connected, Serial0/0.1 192.168.60.0/24 [110/10] via 192.168.30.10, 02:25:59, Seri 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks 192.168.10.32/28 [110/193] via 192.168.30.10, 02:26:04, 192.168.10.0/27 [110/192] via 192.168.30.10, 02:26:11, 172.19.0.0/25 is subnetted, 1 subnets 172.19.35.0 [110/10] via 192.168.30.10, 00:00:27, Seria O E2 192.168.80.0/24 [110/10] via 192.168.30.10, 02:26:00, Seri 192.168.20.0/30 is subnetted, 1 subnets O IA 192.168.20.0 [110/128] via 192.168.30.10, 02:26:17, Ser 192.168.50.0/32 is subnetted, 1 subnets C 192.168.50.1 is directly connected, Loopback0O E2 192.1 via 192.168.30.10, 02:26:03, Serial0/0.1 O E2 192.168.100.0/24 [110/10] via 192.168.30.10, 02:26:03, Ser O E2 192.168.101.0/24 [110/10] via 192.168.30.10, 02:26:03, Ser
Example 8-36. Matisse (RID = 192.168.50.4) is now an ASBR because it is originating autonomous system external LSAs to advertise the external routes.
Rubens#show ip ospf border-routers OSPF Process 10 internal Routing Table Codes: i - Intra-area route, I - Inter-area route i 192.168.50.2 [64] via 192.168.30.10, Serial0/0.1, ABR, Area 1 I 192.168.50.4 [192] via 192.168.30.10, Serial0/0.1, ASBR, Area
Case Study: Stub Areas
Because no type 5 LSAs are being originated within area 1 of Figure 8-46, 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 as displayed in Example 8-37 and Example 8-38.
Example 8-37. Rubens is configured to make area 1 a stub area.
router ospf 10 network 0.0.0.0 255.255.255.255 area 1 area 1 stub
Example 8-38. Chardin is configured to make area 1 a stub area.
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 (Example 8-39) and after (Example 8-40) 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 more than 50 percent.
Example 8-39. Rubens's database has a total of 14 LSAs before area 1 is configured as a stub area.
Rubens#show ip ospf database database-summary OSPF Router with ID (192.168.50.1) (Process ID 10) Area 1 database LSA Type Router Network Summary Net Summary ASBR Type-7 Ext Opaque Link Opaque Area Subtotal summary Count 2 0 3 1 0 0 0 6 Delete 0 0 0 0 0 0 0 0 Maxage 0 0 0 0 0 0 0 0 Process 10 database summary LSA Type Count Delete Router 2 0 Network 0 0 Summary Net 3 0 Summary ASBR 1 0 Type-7 Ext 0 0 Opaque Link 0 0 Opaque Area 0 0 Type-5 Ext 8 0 Maxage 0 0 0 0 0 0 0 0 Opaque AS 0 0 0Total 14 0 0
Example 8-40. The stub area configuration eliminates the eight 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.
Rubens#show ip ospf database database-summary OSPF Router with ID (192.168.50.1) (Process ID 10) Area 1 database LSA Type Router Network Summary Net Summary ASBR Type-7 Ext Opaque Link Opaque Area Subtotal summary Count 2 0 4 0 0 0 0 6 Delete 0 0 0 0 0 0 0 0 Maxage 0 0 0 0 0 0 0 0 Process 10 database summary LSA Type Count Delete Router 2 0 Network 0 0 Summary Net 4 0 Summary ASBR 0 0 Type-7 Ext 0 0 Opaque Link 0 0 Opaque Area 0 0 Maxage 0 0 0 0 0 0 0 Type-5 Ext 0 0 0Opaque AS Total 0 6 0 0 0 0
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 Example 8-40 indicates this additional type 3 LSA. The last entry in Rubens's route table (Example 8- 41) shows the default route advertised by Chardin.
Example 8-41. Rubens's route table shows that all external routes have been eliminated (compare this to Example 8- 35) and that a default route has been added.
Rubens#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is 192.168.30.10 to network 0.0.0.0 192.168.30.0/29 is subnetted, 2 subnets C 192.168.30.0 is directly connected, FastEthernet0/0 C 192.168.30.8 is directly connected, Serial0/0.1 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks O IA 192.168.10.32/28 [110/193] via 192.168.30.10, 00:05:24, O IA 192.168.10.0/27 [110/192] via 192.168.30.10, 00:05:24, 192.168.20.0/30 is subnetted, 1 subnets O IA 192.168.20.0 [110/128] via 192.168.30.10, 00:05:24, SeC 192.168.50.1 is directly connected, Loopback0 O*IA 0.0.0.0/0 [110/65] via 192.168.30.10, 00:05:25, Serial0/0.
The ABR will advertise a default route with a cost of 1. The cost of the serial link between Rubens and Chardin is 64; Example 8-41 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 shown in Example 8-42.
Example 8-42. Chardin's configuration sets the cost of the advertised default route.
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 Example 8-43. Changing the cost of the default route has no real benefit here, but might 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.
Example 8-43. Rubens's route table reflects the results of changing the cost of the default route.
Rubens#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is 192.168.30.10 to network 0.0.0.0 C C O IA O IA O IA C O*IA 192.168.30.0/29 is subnetted, 2 subnets 192.168.30.0 is directly connected, FastEthernet0/0 192.168.30.8 is directly connected, Serial0/0.1 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks 192.168.10.32/28 [110/193] via 192.168.30.10, 00:18:49, 192.168.10.0/27 [110/192] via 192.168.30.10, 00:18:49, 192.168.20.0/30 is subnetted, 1 subnets 192.168.20.0 [110/128] via 192.168.30.10, 00:18:49, Ser 192.168.50.0/32 is subnetted, 1 subnets 192.168.50.1 is directly connected, Loopback0 0.0.0.0/0 [110/84] via 192.168.30.10, 00:10:36, Serial0/0.
Case Study: Totally Stubby Areas
Totally stubby areas are configured by placing the keyword no-summary 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 in Figure 8-46 a totally stubby area, Chardin's configuration would be as shown in Example 8-44.
Example 8-44. Chardin is configured to make area 1 a totally stubby area.
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
Example 8-45 shows that the LSAs in Rubens's database have been reduced to three; Example 8-46 shows the route table. Example 8-45. Changing area 1 to a totally stubby area eliminates all but one of the type 3 LSAs (the default route).
Rubens#show ip ospf database database-summary OSPF Router with ID (192.168.50.1) (Process ID 10) Area 1 database LSA Type Router Network Summary Net Summary ASBR Type-7 Ext Opaque Link Opaque Area Subtotal summary Count 2 0 1 0 0 0 0 3 Delete 0 0 0 0 0 0 0 0 Maxage 0 0 0 0 0 0 0 0 Process 10 database summary LSA Type Count Delete Router 2 0 Network 0 0 Summary Net 1 0 Summary ASBR 0 0 Maxage 0 0 0 0Type-7 Ext Opaque Link Opaque Area 0 0 0 0 0 0 0 0 0 Type-5 Ext Opaque AS Total 0 0 3 0 0 0 0 0 0
Example 8-46. A route table in a totally stubby area will contain only intra-area routes and the default route.
Rubens#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is 192.168.30.10 to network 0.0.0.0 192.168.30.0/29 is C 192.168.30.0 is C 192.168.30.8 is 192.168.50.0/32 is C 192.168.50.1 is O*IA 0.0.0.0/0 [110/84] subnetted, 2 subnets directly connected, FastEthernet0/0 directly connected, Serial0/0.1 subnetted, 1 subnets directly connected, Loopback0 via 192.168.30.10, 00:15:52, Serial0/0.
Case Study: Not-So-Stubby Areas
The earlier case study, "OSPF and Secondary Addresses," left off with Matisse accepting routes from Dali via RIP and redistributing them into the OSPF domain (see Figure 8-46). 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. Example 8-47 shows the configuration at Matisse.
Example 8-47. Matisse is configured to make area 192.168.10.0 a not-so-stubby area.
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. Because Goya is an ABR, it will translate type 7 LSAs received on the NSSA-attached interface into type 5 LSAs. These 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 [28] (Example 8-48). Chardin has tagged the routes as E2 (Example 8-49), indicating that they have been learned from type 5 LSAs. [28]
N2 indicates the same metric calculation as E2that is, only the external cost is used. A subsequent example will demonstrate E1 and N1 metric types. Example 8-48. The external routes learned from Matisse areExample 8-48. The external routes learned from Matisse are tagged as NSSA routes at Goya.
Goya#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is not set O N2 192.168.90.0/24 [110/10] via 192.168.10.2, 00:00:41, Seria O N2 192.168.105.0/24 [110/10] via 192.168.10.2, 00:00:41, Seri 192.168.30.0/29 is subnetted, 2 subnets O IA 192.168.30.0 [110/129] via 192.168.20.1, 00:00:41, Seri O IA 192.168.30.8 [110/128] via 192.168.20.1, 00:00:41, Seri O N2 192.168.60.0/24 [110/10] via 192.168.10.2, 00:00:41, Seria 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks O 192.168.10.32/28 [110/65] via 192.168.10.2, 00:00:43, S C 192.168.10.0/27 is directly connected, Serial0/0.1 172.19.0.0/25 is subnetted, 1 subnets O N2 172.19.35.0 [110/10] via 192.168.10.2, 00:00:43, Serial O N2 192.168.80.0/24 [110/10] via 192.168.10.2, 00:00:43, Seria 192.168.20.0/30 is subnetted, 1 subnets C 192.168.20.0 is directly connected, Serial0/0.2 192.168.50.0/32 is subnetted, 1 subnets C 192.168.50.3 is directly connected, Loopback0 O N2 192.168.70.0/24 [110/10] via 192.168.10.2, 00:00:55, Seria O N2 192.168.100.0/24 [110/10] via 192.168.10.2, 00:00:56, Seri O N2 192.168.101.0/24 [110/10] via 192.168.10.2, 00:00:56, Seri
Example 8-49. Chardin has tagged the same routes as E2,Example 8-49. Chardin has tagged the same routes as E2, indicating they have been learned from autonomous system external LSAs.
Chardin#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is not set O E2 192.168.90.0/24 [110/10] via 192.168.20.2, 00:02:49, Seria O E2 192.168.105.0/24 [110/10] via 192.168.20.2, 00:02:49, Seri 192.168.30.0/29 is subnetted, 2 subnets O 192.168.30.0 [110/65] via 192.168.30.9, 00:08:41, Seria C 192.168.30.8 is directly connected, Serial0/0.1 O E2 192.168.60.0/24 [110/10] via 192.168.20.2, 00:02:49, Seria 192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks O IA 192.168.10.32/28 [110/129] via 192.168.20.2, 00:02:55, O IA 192.168.10.0/27 [110/128] via 192.168.20.2, 00:03:16, S 172.19.0.0/25 is subnetted, 1 subnets O E2 172.19.35.0 [110/10] via 192.168.20.2, 00:02:50, Serial O E2 192.168.80.0/24 [110/10] via 192.168.20.2, 00:02:50, Seria 192.168.20.0/30 is subnetted, 1 subnets C 192.168.20.0 is directly connected, Serial0/0.2 192.168.50.0/32 is subnetted, 1 subnets C 192.168.50.2 is directly connected, Loopback0 O E2 192.168.70.0/24 [110/10] via 192.168.20.2, 00:02:52, Seria O E2 192.168.100.0/24 [110/10] via 192.168.20.2, 00:02:52, Seri O E2 192.168.101.0/24 [110/10] via 192.168.20.2, 00:02:52, Ser
This translation can also be observed by examining Goya's database. Example 8-50 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.
Example 8-50. 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). Type-7 AS External Link States (Area 192.168.10
Link ID 172.19.35.0 192.168.60.0 192.168.70.0 192.168.80.0 192.168.90.0 192.168.100.0 192.168.101.0 192.168.105.0 ADV Router 192.168.50.4 192.168.50.4 192.168.50.4 192.168.50.4 192.168.50.4 192.168.50.4 192.168.50.4 192.168.50.4 Age 371 371 371 371 371 371 371 371 Seq# 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 Checksum 0x00C444 0x00A521 0x003785 0x00C8E9 0x005A4E 0x00EBB2 0x00E0BC 0x00B4E4
Type-5 AS External Link States
Link ID 172.19.35.0 192.168.60.0 192.168.70.0 192.168.80.0 192.168.90.0 192.168.100.0 192.168.101.0 192.168.105.0 ADV Router 192.168.50.3 192.168.50.3 192.168.50.3 192.168.50.3 192.168.50.3 192.168.50.3 192.168.50.3 192.168.50.3 Age 305 306 306 306 390 390 390 390 Seq# 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 Checksum 0x005FB4 0x004091 0x00D1F5 0x00635A 0x00F4BE 0x008623 0x007B2D 0x004F5
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 as shown in Example 8-51.
Example 8-51. Goya is configured to make area 192.168.10.0 a totally stubby not-so-stubby area.
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 (Example 8-52) shows the elimination of all inter- area routes and the addition of a default route advertised by Goya. Example 8-52. All inter-area routes have been replaced with a default route to the ABR.
Matisse#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is 192.168.10.1 to network 0.0.0.0R R R C C C C R C R 192.168.90.0/24 [120/1] via 172.19.35.1, 00:00:20, FastEth 192.168.105.0/24 [120/1] via 172.19.35.1, 00:00:20, FastEt 192.168.60.0/24 [120/1] via 172.19.35.1, 00:00:20, FastEth 192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks 192.168.10.64/26 is directly connected, FastEthernet0/1 192.168.10.32/28 is directly connected, FastEthernet0/0 192.168.10.0/27 is directly connected, Serial0/0.1 172.19.0.0/25 is subnetted, 1 subnets 172.19.35.0 is directly connected, FastEthernet0/0 192.168.80.0/24 [120/1] via 172.19.35.1, 00:00:21, FastEth 192.168.50.0/32 is subnetted, 1 subnets 192.168.50.4 is directly connected, Loopback0 192.168.70.0/24 [120/1] via 172.19.35.1, 00:00:21, FastEth R 192.168.100.0/24 [120/1] via 172.19.35.1, 00:00:22, FastEt R 192.168.101.0/24 [120/1] via 172.19.35.1, 00:00:22, FastEt O*IA 0.0.0.0/0 [110/65] via 192.168.10.1, 00:11:40, Serial0/0.1
In Figure 8-47, the link to Dali has been moved from Matisse to Goya; the IP address has also moved. Goya is now an ASBR redistributing RIP- learned routes into OSPF.
Figure 8-47. The link to Dali has moved to Goya, which now speaks RIP to Dali and redistributes the learned routes into OSPF.
[View full size image]
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 Example 8-53.
Example 8-53. An ABR that is also an ASBR will advertise the external routes into an NSSA with type 7 LSAs. In this example, Goya is advertising the external routes with an N1 metric type.
Matisse#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is not setO N1 192.168.90.0/24 [110/74] via 192.168.10.1, 00:00:07, Seria O N1 192.168.105.0/24 [110/74] via 192.168.10.1, 00:00:07, Seri 192.168.30.0/29 is subnetted, 2 subnets O IA 192.168.30.0 [110/193] via 192.168.10.1, 00:03:11, Seri O IA 192.168.30.8 [110/192] via 192.168.10.1, 00:03:11, Seri O N1 192.168.60.0/24 [110/74] via 192.168.10.1, 00:00:07, Seria 192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks C 192.168.10.64/26 is directly connected, FastEthernet0/1 C 192.168.10.32/28 is directly connected, FastEthernet0/0 C 192.168.10.0/27 is directly connected, Serial0/0.1 172.19.0.0/25 is subnetted, 1 subnets O N1 172.19.35.0 [110/74] via 192.168.10.1, 00:03:07, Serial O N1 192.168.80.0/24 [110/74] via 192.168.10.1, 00:00:08, Seria 192.168.20.0/30 is subnetted, 1 subnets O IA 192.168.20.0 [110/128] via 192.168.10.1, 00:03:14, Seri 192.168.50.0/32 is subnetted, 1 subnets C 192.168.50.4 is directly connected, Loopback0 O N1 192.168.70.0/24 [110/74] via 192.168.10.1, 00:00:10, Seria O N1 192.168.100.0/24 [110/74] via 192.168.10.1, 00:00:10, Seri O N1 192.168.101.0/24 [110/74] via 192.168.10.1, 00:00:10, Seri
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 redistribution is accomplished by the Example 8-54 configuration at Goya: [29] [29]
Note the metric-type 1 statement in the redistribution command. This statement causes the external destinations to be advertised with an E1 metric; within the NSSA, the metric type becomes N1, as shown in Example 8.53. Example 8-54. Goya is configured to not redistribute RIP routes into the NSSA 192.168.10.0.interface Ethernet0/0
ip address 172.19.35.15 255.255.255.128 ! router ospf 30 redistribute rip metric 10 metric-type 1 subnets 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. Example 8-55 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.
Example 8-55. After no-redistribution is added to Goya's area nssa command, the route table of Example 8-53 no longer contains routes learned from type 7 LSAs.
Matisse#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-usGateway of last resort is 192.168.10.1 to network 0.0.0.0 192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks C 192.168.10.64/26 is directly connected, FastEthernet0/1 C 192.168.10.32/28 is directly connected, FastEthernet0/0 C 192.168.10.0/27 is directly connected, Serial0/0.1 192.168.50.0/32 is subnetted, 1 subnets C 192.168.50.4 is directly connected, Loopback0 O*IA 0.0.0.0/0 [110/65] via 192.168.10.1, 00:00:51, Serial0/0.1
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-summary 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 NSSAthis time, with a type 7 LSA. Using this statement, Goya's OSPF configuration is displayed in Example 8-56.
Example 8-56. Default route is originated at Goya with the default-information-originate command.
router ospf 30 redistribute rip metric 10 metric-type 1 subnets 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 default-information-o
Example 8-57 shows Matisse's route table after the reconfiguration. The table contains inter-area routes and a default route with an N2 tagindicating that the route was learned from a type 7 LSA.
Example 8-57. Adding the default-information-originate statement to the area nssa command causes the ABR to advertise a default route into an NSSA.
Matisse#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is 192.168.10.1 to network 0.0.0.0 O IA O IA C C C O IA C O*N2 192.168.30.0/29 is subnetted, 2 subnets 192.168.30.0 [110/193] via 192.168.10.1, 00:00:26, Seri 192.168.30.8 [110/192] via 192.168.10.1, 00:00:26, Seri 192.168.10.0/24 is variably subnetted, 3 subnets, 3 masks 192.168.10.64/26 is directly connected, FastEthernet0/1 192.168.10.32/28 is directly connected, FastEthernet0/0 192.168.10.0/27 is directly connected, Serial0/0.1 192.168.20.0/30 is subnetted, 1 subnets 192.168.20.0 [110/128] via 192.168.10.1, 00:00:27, Seri 192.168.50.0/32 is subnetted, 1 subnets 192.168.50.4 is directly connected, Loopback0 0.0.0.0/0 [110/1] via 192.168.10.1, 00:00:22, Serial0/0.1
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 network 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.
The Cisco 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 8-48, area 15 contains eight subnets: 10.0.0.0/16 through 10.7.0.0/16. Figure 8-49 shows that these addresses can be represented with the single summary address 10.0.0.0/13.
Figure 8-48. The addresses in areas 15 and 25 can be summarized into the backbone area.
[View full size image]
Figure 8-49. 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.
11111111111111110000000000000000 = 16-bit mask 00001010000000000000000000000000 = 10.0.0.0/16 00001010000000010000000000000000 = 10.1.0.0/16 00001010000000100000000000000000 = 10.2.0.0/16 00001010000000110000000000000000 = 10.3.0.0/16 00001010000001000000000000000000 = 10.4.0.0/16 00001010000001010000000000000000 = 10.5.0.0/16 00001010000001100000000000000000 = 10.6.0.0/16 00001010000001110000000000000000 = 10.7.0.0/16 00001010000000000000000000000000 = 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 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 7, "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. [30] OSPF also enters this route automatically. In the IOS mainline versions earlier then 12.1, however, the route to the null interface will not be entered automatically. In addition, in IOS releases that have the capability of creating this route, the router can be configured to not install it in the route table using the command no discard-route. Therefore, whenever you are configuring summary routes within an OSPF domain, be sure to verify that the route for the summary address, pointing to the null interface, is created. If it is not automatically created, be sure to add it or to issue the discard-route command. [30]
The reasons for this route are discussed in more detail, with examples, in Chapters 11, "Route Redistribution," and 12, "Default Routes and On-Demand Routing."
Example 8-58 shows Pena's OSPF configuration. Example 8-58. Pena's OSPF configuration.
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 8-49 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 Example 8-59 configuration at Hurd.
Example 8-59. Hurd's OSPF configuration.
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 network. In Figure 8-48, 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 8-48 will work, it is an undesirable design practice. The point of summarization is to conserve resources; network 172.17.1.0/24 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.
Notice also in Figure 8-48 that subnets 172.16.27.0/25 (at Gorman) and 172.16.27.192/29 (at Okeeffe) are discontiguous. Again because OSPFis 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. The default behavior of the area range command is to advertise the range specified. It might be desirable to suppress the advertisement of a range of addresses. The area range command with the keyword not- advertise causes prefixes in the specified range to be suppressed. They are not advertised in LSAs.
Pena is configured to suppress the range 172.17.0.0/16. Pena's configuration becomes as displayed in Example 8-60. Example 8-60. Pena is configured to suppress the advertisement of a range of addresses.
router ospf 1 area 15 range 10.0.0.0 255.248.0.0 area 15 range 172.17.0.0 255.255.0.0 not-advertise network 10.0.0.0 0.7.255.255 area 15 network 10.8.0.0 0.7.255.255 area 0 network 172.17.0.0 0.0.255.255 area 15
This command has the desired affect of suppressing the 172.17.0.0/16 range, but it has an undesirable consequence. Look at the route table on Hurd before (Example 8-61) and after (Example 8-62) entering the command.
Example 8-61. Hurd's route table before Pena suppressed an address range shows two external routes.
Hurd#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is not set O IA O IA O O C C C O IA O E2 O E2 S 172.17.0.0/16 is variably subnetted, 2 subnets, 2 masks 172.17.1.0/24 [110/11] via 10.8.1.2, 00:03:29, Ethernet 172.17.0.1/32 [110/12] via 10.8.1.2, 00:03:29, Ethernet 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks 172.16.27.192/29 [110/65] via 172.20.1.6, 00:03:29, Ser 172.16.27.0/25 [110/65] via 172.20.1.2, 00:03:29, Seria 172.20.0.0/30 is subnetted, 2 subnets 172.20.1.0 is directly connected, Serial0/0.1 172.20.1.4 is directly connected, Serial0/0.2 10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks 10.8.1.0/24 is directly connected, Ethernet0/0 10.0.0.0/13 [110/11] via 10.8.1.2, 00:03:30, Ethernet0/ 10.100.0.0/16 [110/10] via 10.8.1.2, 00:03:30, Ethernet 10.101.0.0/16 [110/10] via 10.8.1.2, 00:03:32, Ethernet 172.16.0.0/12 is directly connected, Null0
Example 8-62. Hurd's route table after Pena suppresses a
range shows the external routes are no longer in the route
table.
Hurd#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA externalE1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks O 172.16.27.192/29 [110/65] via 172.20.1.6, 00:06:11, Ser O 172.16.27.0/25 [110/65] via 172.20.1.2, 00:06:11, Seria 172.20.0.0/30 is subnetted, 2 subnets C 172.20.1.0 is directly connected, Serial0/0.1 C 172.20.1.4 is directly connected, Serial0/0.2 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.8.1.0/24 is directly connected, Ethernet0/0 O IA 10.0.0.0/13 [110/11] via 10.8.1.2, 00:06:12, Ethernet0/ S 172.16.0.0/12 is directly connected, Null0
The external routes learned via RIP on Wyeth, 10.100.0.0 and 10.101.0.0, are no longer in Hurd's route table. Example 8-63 displays the OSPF database for 10.100.0.0 on Hurd. Notice the specified forwarding address.
Example 8-63. The type 5 external link state shows the forwarding address to be the address of the router that originated the external route.
Hurd#show ip ospf data external OSPF Router with ID (172.20.1.5) (Process ID 1) Type-5 AS External Link StatesRouting Bit Set on this LSA LS age: 421 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.100.0.0 (External Network Number ) Advertising Router: 172.17.0.1 LS Seq Number: 80000001 Checksum: 0xF1CC Length: 36 Network Mask: /16 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 10 Forward Address: 172.17.0.1 External Route Tag: 0
The forwarding address is the loopback interface of Wyeth. If the forwarding address in an external LSA is specified, and this address is not reachable, the address contained in the LSA is not inserted into the route table. When Pena translates type 7 NSSA LSAs into type 5 LSAs, by default the forwarding address is transferred from the type 7 to the type 5. The ABR can be configured to suppress the forwarding address during the translation, replacing the specified address with the address 0.0.0.0. When another router receives the type 5 external LSA with the forwarding address suppressed, instead of trying to direct traffic for the external address to the forwarding address, the receiving router will attempt to direct the traffic to the type 7 to type 5 translating ABR router.
Example 8-64 has Pena's new configuration. Example 8-64. Pena's configuration suppresses the inclusion of a forwarding address in translated type 5 LSAs.
router ospf 1 area 15 range 10.0.0.0 255.248.0.0 area 15 range 172.17.0.0 255.255.0.0 not-advertise network 10.0.0.0 0.7.255.255 area 15 network 10.8.0.0 0.7.255.255 area 0 network 172.17.0.0 0.0.255.255 area 15 area 15 nssa translate type7 suppress-fa
Example 8-65 shows Hurd's external database entry for 10.100.0.0, and Example 8-66 shows Hurd's new route table. Example 8-65. The external OSPF database entry shows a suppressed forwarding address.
Hurd#show ip ospf data external OSPF Router with ID (172.20.1.5) (Process ID 1) Type-5 AS External Link States Routing Bit Set on this LSA LS age: 13 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.100.0.0 (External Network Number ) Advertising Router: 172.17.0.1 LS Seq Number: 80000002 Checksum: 0xA9D2 Length: 36 Network Mask: /16 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 10 Forward Address: 0.0.0.0External Route Tag: 0
Example 8-66. The external routes for 10.100.0.0 and 10.101.0.0 are inserted into the route table after suppressing the forwarding address.
Hurd#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inte N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - ia - IS-IS inter area, * - candidate default, U - per-us o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks O 172.16.27.192/29 [110/65] via 172.20.1.6, 00:09:32, Ser O 172.16.27.0/25 [110/65] via 172.20.1.2, 00:09:32, Seria 172.20.0.0/30 is subnetted, 2 subnets C 172.20.1.0 is directly connected, Serial0/0.1 C 172.20.1.4 is directly connected, Serial0/0.2 10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks C 10.8.1.0/24 is directly connected, Ethernet0/0 O IA 10.0.0.0/13 [110/11] via 10.8.1.2, 00:09:33, Ethernet0/ O E2 10.100.0.0/16 [110/10] via 10.8.1.2, 00:00:46, Ethernet O E2 10.101.0.0/16 [110/10] via 10.8.1.2, 00:00:46, Ethernet S 172.16.0.0/12 is directly connected, Null0
The forwarding address displayed in Hurd's database is now 0.0.0.0 and the two external routes are back in the route table.the two external routes are back in the route table.
Case Study: Filtering Between Areas
Another LAN is added to Okeeffe. Devices on the LAN are to be accessed by other devices within area 25, but not from the rest of the network. Another way to limit and control the addresses that are exchanged between areas is to configure LSA type 3 filtering on ABRs. The ABRs can filter network addresses being advertised by type 3 LSAs either into or out of an area.
A LAN with address 192.168.1.0/24 is added to Okeeffe in area 25. This address is advertised in LSAs throughout the network even though it is only to be accessed by other devices in area 25. To prevent the address from being advertised outside area 25, type 3 LSA filtering is configured on Hurd as shown in Example 8-67.
Example 8-67. Hurd uses type 3 LSA filtering.
router ospf 1 area 25 filter-list prefix area25outbound out ! ip prefix-list area25outbound seq 10 deny 192.168.1.0/24 ip prefix-list area25outbound seq 20 permit 0.0.0.0/0 le 32
The OSPF command area PID filter-list prefix specifies the name of a filter list to apply to outbound or inbound LSAs. Outbound lists filter LSAs sent into areas other then the one specified by the command. In our example, the list filters LSAs with addresses originating in area 25 and being sent into non-area 25 areas, such as area 0. Inbound lists filter LSAs as they are sent into area 25.
The first line of the prefix list is clear. The statement denies address 192.168.1.0/24 from being advertised in a type 3 LSA. The second line192.168.1.0/24 from being advertised in a type 3 LSA. The second line permits everything else: every address with a mask from length 0 to length 32 bits. This second line is required because there is a implicit "deny all" statement at the end of the prefix list. 192.168.1.0/24 is prevented from being sent in type 3 LSAs outside of area 25. Every other address is permitted.
Case Study: Authentication
OSPF packets can be authenticated to prevent inadvertent or intentional introduction of bad routing information. Table 8-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 network vulnerable to a "sniffer attack," in which packets are captured by a protocol analyzer and the passwords are read (see Chapter 6 and especially Figure 6.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 8-48, type 1 authentication is enabled for areas 0 and 25. Example 8-68 displays Hurd's configuration.Example 8-68. Hurd is configured to use clear text authentication.
interface Ethernet 0/0 ip address 10.8.1.1 255.255.255.0 ip ospf authentication-key santafe interface Serial 0/0.1 ip address 172.20.1.1 255.255.255.252 ip ospf authentication-key taos interface Serial 0/0.2 ip address 172.20.1.5 255.255.255.252 ip ospf authentication-key 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 ip route 172.16.0.0 255.240.0.0 null0
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 referencetransmitted 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 shown in Example 8- 69. Example 8-69. Hurd is configured to use MD5 authentication.
interface Ethernet 0/0 ip address 10.8.1.1 255.255.255.0 ip ospf message-digest-key 5 md5 santafe interface Serial 0/0.1 ip address 172.20.1.1 255.255.255.252 ip ospf message-digest-key 10 md5 taos interface Serial 0/0.2 ip address 172.20.1.5 255.255.255.252 ip ospf message-digest-key 15 md5 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 message-digestarea 25 authentication message-digest ip route 172.16.0.0 255.240.0.0 null0
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. Example 8-70 shows Hurd's configuration.
Example 8-70. Hurd is configured with a new MD5 key.
interface Serial0/0.2 ip address 172.20.1.5 255.255.255.252 ip ospf message-digest-key 15 md5 abiquiu ip ospf message-digest-key 20 md5 steiglitz
Hurd will now send duplicate copies of each OSPF packet out S0/0.2; 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 network 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, Example 8-71 is a display of what Hurd's configuration would include.Example 8-71. Password encryption is configured on Hurd to encrypt the password in the display of the configuration file.
service password-encryption ! interface Ethernet0/0 ip address 10.8.1.1 255.255.255.0 ip ospf message-digest-key 5 md5 7 001712008105A0D03 ! interface Serial0/0.1 ip address 172.20.1.1 255.255.255.252 ip ospf message-digest-key 10 md5 7 03105A0415 ! interface Serial0/0.2 ip address 172.20.1.5 255.255.255.252 ip ospf message-digest-key 20 md5 7 070E23455F1C1010
In the authentication configuration of the other protocols discussed in this book, key-chains were used to configure the passwords, or key-strings as they are called. OSPF does not support key-chain configuration at the time of this writing.
Case Study: Virtual Links
Figure 8-50 shows an network 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 8-50. A failure of the link between Hokusai and Hiroshige will partition the backbone area.Hiroshige will partition the backbone area. The best solution to this vulnerability is to add another link to the backbone areabetween 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. [31] 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 shown in Example 8-72 and Example 8-73. [31]
When a virtual link is used to connect an area to the backbone through a non- backbone area, one of the ABRs will be between the two non-backbone areas. Example 8-72. Hokusai's virtual link configuration.
router ospf 10 network 192.168.100.1 0.0.0.0 area 0network 192.168.100.29 0.0.0.0 area 0 network 192.168.100.21 0.0.0.0 area 100 area 100 virtual-link 192.168.100.33
Example 8-73. Hiroshige's virtual link configuration.
router ospf 10 network 192.168.100.2 0.0.0.0 area 0 network 192.168.100.33 0.0.0.0 area 0 network 192.168.100.25 0.0.0.0 area 100 area 100 virtual-link 192.168.100.29
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 (Example 8-74), in reality the packets are being routed via Kujomoto. [32] [32]
The output of the show ip ospf virtual-link command might be slightly different, depending upon which IOS version you are using. Example 8-74. The state of a virtual link can be observed with the command show ip ospf virtual-link.
Hokusai#show ip ospf virtual-link Virtual Link OSPF_VL1 to router 192.168.100.33 is up Run as demand circuit DoNotAge LSA not allowed (Number of DCbitless LSA is 2). Transit area 100, via interface Serial0, Cost of using 128 Transmit Delay is 1 sec, State POINT_TO_POINT,Timer intervals configured, Hello 10, Dead 40, Wait 40, Retr Hello due in 00:00:00 Adjacency State FULL (Hello suppressed) Hokusai#
Case Study: OSPF on NBMA Networks
Nonbroadcast multiaccess networks such as X.25, Frame Relay, and ATM present a problem for OSPF. Multiaccess means that the NBMA "cloud" is a single network to which multiple devices are attached, the same as Ethernet or Token Ring networks (Figure 8-51). 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 because 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 might not automatically learn about all its neighbors, and DR election would not function correctly.
Figure 8-51. 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 network 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 8-52 shows a Frame Relay network with four attached routers.
Figure 8-52. Several options exist for configuring OSPF on this NBMA network.Because of the partially meshed hub-and-spoke configuration of the PVCs in Figure 8-52, 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 shown in Example 8-75 through Example 8-78.
Example 8-75. Rembrandt's configuration.
interface Serial0 encapsulation frame-relay ip address 172.16.2.1 255.255.255.0 frame-relay map ip 172.16.2.2 100 frame-realy map ip 172.16.2.3 300 frame-relay map ip 172.16.2.4 500 ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0 neighbor 172.16.2.2 neighbor 172.16.2.3 neighbor 172.16.2.4
Example 8-76. Hals's configuration specifying a neighbor priority.
interface Serial0 encapsulation frame-relay ip address 172.16.2.2 255.255.255.0 frame-relay map ip 172.16.2.1 600 frame-relay map ip 172.16.2.3 600 frame-relay map ip 172.16.2.4 600 ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0 neighbor 172.16.2.1 priority 10 Example 8-77. Vandyck's configuration specifying a neighbor priority. interface Serial0 encapsulation frame-relay ip address 172.16.2.3 255.255.255.0 frame-relay map ip 172.16.2.1 400 frame-relay map ip 172.16.2.2 400 frame-relay map ip 172.16.2.4 400 ! router ospf 1 network 172.16.0.0 0.0.255.255 are a 0 neighbor 172.16.2.1 priority 10Example 8-78. Brueghel's configuration specifying a neighbor priority. interface Serial0 encapsulation frame-relay ip address 172.16.2.4 255.255.255.0 frame-relay map ip 172.16.2.1 200 frame-relay map ip 172.16.2.2 200 frame-relay map ip 172.16.2.3 200 ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0 neighbor 172.16.2.1 priority 10
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 configurations of the four routers are shown in
Example 8-79 through Example 8-82.Example 8-79. Rembrandt's Frame Relay interface is configured as an OSPF broadcast network.
interface Serial0 encapsulation frame-relay ip address 172.16.2.1 255.255.255.0 ip ospf network broadcast ip ospf priority 10 frame-relay map ip 172.16.2.2 100 broadcast frame-realy map ip 172.16.2.3 300 broadcast frame-relay map ip 172.16.2.4 500 broadcast ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
Example 8-80. Hals's Frame Relay interface is configured as an OSPF broadcast network.
interface Serial0 encapsulation frame-relay ip address 172.16.2.2 255.255.255.0 ip ospf network broadcast ip ospf priority 0 frame-relay map ip 172.16.2.1 600 broadcast frame-relay map ip 172.16.2.3 600 broadcast frame-relay map ip 172.16.2.4 600 broadcast ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
Example 8-81. Vandyck's Frame Relay interface isExample 8-81. Vandyck's Frame Relay interface is configured as an OSPF broadcast network.
interface Serial0 encapsulation frame-relay ip address 172.16.2.3 255.255.255.0 ip ospf network broadcast ip ospf priority 0 frame-relay map ip 172.16.2.1 400 broadcast frame-relay map ip 172.16.2.2 400 broadcast frame-relay map ip 172.16.2.4 400 broadcast ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
Example 8-82. Brueghel's Frame Relay interface is configured as an OSPF broadcast network.
interface Serial0 encapsulation frame-relay ip address 172.16.2.4 255.255.255.0 ip ospf network broadcast ip ospf priority 0 frame-relay map ip 172.16.2.1 200 broadcast frame-relay map ip 172.16.2.2 200 broadcast frame-relay map ip 172.16.2.3 200 broadcast ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
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, ensureand 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 8-52 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 might be the only alternative to broadcast networks. In the configurations in Example 8-83 through Example 8-86, the OSPF network type associated with each interface is changed to point-to- multipoint.
Example 8-83. Rembrandt's Frame Relay interface is configured as an OSPF point-to-multipoint network.
interface Serial0 encapsulation frame-relay ip address 172.16.2.1 255.255.255.0 ip ospf network point-to-multipoint ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
Example 8-84. Hals's Frame Relay interface is configuredExample 8-84. Hals's Frame Relay interface is configured as an OSPF point-to-multipoint network.
interface Serial0 encapsulation frame-relay ip address 172.16.2.2 255.255.255.0 ip ospf network point-to-multipoint ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
Example 8-85. Vandyck's Frame Relay interface is configured as an OSPF point-to-multipoint network.
interface Serial0 encapsulation frame-relay ip address 172.16.2.3 255.255.255.0 ip ospf network point-to-multipoint ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
Example 8-86. Brueghel's Frame Relay interface is configured as an OSPF point-to-multipoint network.
interface Serial0 encapsulation frame-relay ip address 172.16.2.4 255.255.255.0 ip ospf network point-to-multipoint! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
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, as in the configurations in Example 8-87 through Example 8-90.
Example 8-87. Rembrandt's Frame Relay interface is configured as an OSPF point-to-multipoint, non-broadcast network.
interface Serial0 ip address 172.16.2.1 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast map-group Leiden frame-relay lmi-type q933a frame-relay svc ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0 neighbor 172.16.2.2 cost 30 neighbor 172.16.2.3 cost 20neighbor 172.16.2.4 cost 50
Example 8-88. Hals's Frame Relay interface is configured as an OSPF point-to-multipoint, non-broadcast network.
interface Serial0 ip address 172.16.2.2 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast map-group Haarlem frame-relay lmi-type q933a frame-relay svc ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0 neighbor 172.16.2.1 priority 10
Example 8-89. Vandyck's Frame Relay interface is configured as an OSPF point-to-multipoint, non-broadcast network.
interface Serial0 ip address 172.16.2.3 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast map-group Antwerp frame-relay lmi-type q933a frame-relay svc ! router ospf 1network 172.16.0.0 0.0.255.255 area 0 neighbor 172.16.2.1 priority 10
Example 8-90. Brueghel's Frame Relay interface is configured as an OSPF point-to-multipoint, non-broadcast network.
interface Serial0 ip address 172.16.2.4 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast map-group Brussels frame-relay lmi-type q933a frame-relay svc ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0 neighbor 172.16.2.1 priority 10
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 8-53). This solution is accomplished with subinterfaces as shown in Example 8-91 though Example 8-94. Figure 8-53. Point-to-point subinterfaces allow each PVC to be configured as an individual subnet and eliminate the problem of DR/BDR election on NBMA networks.Example 8-91. Rembrandt is configured with point-to-point subinterfaces.
interface Serial0 no ip address encapsulation frame-relay interface Serial0.100 point-to-point description -------------------------- to Hals ip address 172.16.2.1 255.255.255.252 frame-relay interface-dlci 100 interface Serial0.300 point-to-point description -------------------------- to Vandyck ip address 172.16.2.5 255.255.255.252 frame-relay interface-dlci 300 interface Serial0.500 point-to-point description -------------------------- to Brueghels ip address 172.16.2.9 255.255.255.252 frame-relay interface-dlci 500! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
Example 8-92. Hals is configured with point-to-point subinterfaces.
interface Serial0 no ip address encapsulation frame-relay interface Serial0.600 description --------------------------- to Rembrandt ip address 172.16.2.2 255.255.255.252 frame-relay interface-dlci 600 ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
Example 8-93. Vandyck is configured with point-to-point subinterfaces.
interface Serial0 no ip address encapsulation frame-relay interface Serial0.400 description ---------------------------- to Rembrandt ip address 172.16.2.6 255.255.255.252 frame-relay interface-dlci 400 ! router ospf 1network 172.16.0.0 0.0.255.255 area 0
Example 8-94. Brueghel is configured with point-to-point subinterfaces.
interface Serial0 no ip address encapsulation frame-relay interface Serial0.200 description ---------------------------- to Rembrandt ip address 172.16.2.10 255.255.255.252 frame-relay interface-dlci 200 ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0
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. Another significant advantage is in the router's failure detection. On point-to-point subinterfaces, the routers on both ends of the point-to-point network can detect a failed virtual circuit (if the FrameRelay cloud provides sufficient signaling), and the routing protocol can converge to an alternate route, if one exists.
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 Circuits
OSPF 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 8-52 are Frame Relay SVCs, Rembrandt's configuration might be as shown in Example 8-95.
Example 8-95. Rembrandt's OSPF demand-circuit configuration.
interface Serial0/0 ip address 172.16.2.1 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint non-broadcast ip ospf demand-circuit map-group Leiden frame-relay lmi-type q933a frame-relay svc ! router ospf 1 network 172.16.0.0 0.0.255.255 area 0neighbor 172.16.2.2 cost 30 neighbor 172.16.2.3 cost 20 neighbor 172.16.2.4 cost 50
Keep the following points in mind when implementing OSPF over demand circuits:
- LSAs with the DoNotAge bit set will be allowed into an area only if all
- LSAs in the area's link-state database have the DC-bit set. This setting ensures that all routers in the area are capable of understanding the DoNotAge bit.
- All routers of an area in which OSPF over demand circuits is implemented must be capable of supporting it.
If OSPF over demand circuits is implemented in a non-stub area, the routers in all non-stub areas must support it. The reason is that the DC-bit in type 5 LSAs will be set, and these LSAs are flooded into all non-stub areas.
An effort should be made to implement demand circuits only within stub, totally stubby, or NSSA areas. Such an implementation negates the need for all routers within the OSPF domain to support OSPF over demand circuits. It also minimizes the number of changed LSAs received as the result of topology changes in other areas, and hence prevents excess uptime of the demand circuit. If OSPF over demand circuits is configured and a virtual link is configured to cross the demand circuit, the virtual link will also be treated as a demand circuit. Otherwise, the virtual link traffic would keep the circuit up.
OSPF refreshes its LSAs every 30 minutes to guard against an LSA becoming corrupted while it resides in the link-state database. Because DoNotAge LSAs are not refreshed across a demand circuit, this robustness feature is lost. The refresh process occurs on each side of a demand circuit out all other interfaces, but LSAs are not refreshed across the link. As a result, the sequence numbers of otherwise identical LSAs on each side of the link might be different. Network management stations may use certain MIB variables [33] to verify database synchronization; if the sequence numbers do not match across the databases, an error might be falsely reported. [33]
Specifically, ospfExternLSACksumSum and ospfAreaLSACksumSum. These are sums of the individual LSA checksum fields. Because the checksum calculation includes the sequence number, and because the sequence numbers might be differe