Section 4.1. Router and Area IDs
4.1. Router and Area IDsAn essential requirement for the proper functioning of a link state protocol, as you saw in Chapter 2, is that each router must be able to uniquely identify itself within the routing domain. This is the purpose of the OSPF router ID (RID) and the IS-IS system ID (SysID). In addition, the router must be able to identify its general position within the routing domain. This is the purpose of the area ID (AID). 4.1.1. OSPF Router IDsOSPF uses a 32-bit number for its RID, represented in the same dotted-decimal format as an IP address. A router can find its RID in one of two ways: The RID can be administratively specified in the OSPF configuration, or an IP address configured on one of the router's interfaces can be used as the RID. The second option is made possible because the RID format is the same as the IP address format, and because there is an assumption that an interface address is unique within the routing domain. Which option is used to acquire a RID depends on the particular OSPF implementation. And in some cases, both options are available. For example, both Juniper Networks' and Cisco Systems' OSPF implementations have a prioritized RID selection process:
The original logic behind Step 2, taking an address from a loopback interface, was that because a loopback interface is a logical interfaceit exists only in software and has no physical presence on the routerit is not susceptible to physical failures. So, there is no risk that an interface failure or shutdown on a router could force OSPF to find a new RID and re-advertise its LSAs using the new RID, which in turn causes SPF runs on routers throughout the area and contributes to network instability. There are two approaches by which a particular OSPF implementation could handle the loss of a RID. One approach is that the failure of an interface will have no effect on the RID. After all, the OSPF process just needs to know some 32-bit value, with some confidence that the value is unique within the OSPF routing domain, to use as its RID at start-up. Once the value is known, it can be remembered, and the subsequent failure of the interface from which the RID was derived is irrelevant. The problem with this approach is that the loss of an IP address on an interface might not have been accidental. What if the IP address is intentionally removed from an interface and is reused on another router, and that router selects that IP address as its own RID? If the first router retains the same address as its RID, you now have duplicate RIDs in your network. The second approach avoids the problem just described and is therefore the lesser of two evils. This approach to the loss of an IP address from which the RID is derived is to force the router to acquire a new RID from its remaining IP addresses. 4.1.2. Troubleshooting: Duplicate Router IDsAllowing more than one router in a network to use the same RID results in serious network outages, and the symptoms can be misleading. For example, in Figure 4.1, two routersR4 and R7have both been configured with the RID 192.168.254.7. The physical interfaces for R6 are shown, as are the interface addresses for R6 and its neighbors. We will observe the results of the duplicate RIDs from that router. Figure 4.1. R4 and R7 are using the same RID. Figures 4.2 through 4.6 show the OSPF entries in the routing table of R6, observed within a time span of just a few minutes. The differences are obvious. The OSPF entries in Figure 4.2 look normal. The network diagram in Figure 4.1 does not show the larger network, so we do not know where most of the destination networks are actually located; we can only assume the entries in Figure 4.2 are correct. (In fact, some of the entries have the correct next hop and some do not.)
Figure 4.3 shows our first indication of trouble (aside from the complaints of network users). This display of the OSPF entries in the routing table was taken just moments after the display in Figure 4.2, but most of the route entries have disappeared. After a few more moments, some but not all of the route entries have returned, as Figure 4.4 shows. But then, in Figure 4.5, most of the entries have again disappeared. This fluctuation continues, with the routing table changing almost as fast as it can be repeatedly displayed.
Such fluctuations in the routing table might be interpreted by a troubleshooter as a symptom of a flapping link somewhere in the network. But among the many changes observed in the routing table is the one shown in Figure 4.6. Here, some of the entries have again reappeared in the table, but this time the next-hop addresses have changed. The next hop of all the prefixes in Figure 4.6 is 192.168.3.2, or router R5 in Figure 4.1. In the routing tables of Figures 4.2 and 4.4, several of the prefixes indicated 192.168.5.2, router R7, as the next hop. This behavior might lead you to suspect a routing loop.
As this example demonstrates, the impact of duplicate RIDs on a network is severe, and the symptoms can be misleading. Quickly finding the true cause of the problem depends on how well you know your network and usually involves careful analysis of the OSPF link state database. Therefore, exercise extreme care to ensure that such a problem never arises through misconfiguration or use of unreliable OSPF code.
4.1.3. OSPF Area IDsThe OSPF area ID (AID) is also a 32-bit number. It can be expressed in dotted-decimal format or, with most implementations, as a simple decimal number such as 1, 55, 218, and so on. If the OSPF implementation supports the latter case, the router just fills in the leading bits with 0s. Some implementations will fill in the leading 0s in configuration displays, whereas others display the configuration exactly as typed. In Figure 4.7, for example, the entry of the same OSPF area configuration is shown for Juniper Networks' JUNOS and for Cisco Systems' IOS. Notice that the resulting JUNOS configuration has filled in the leading 0s, but the IOS configuration shows the area IDs as typed. Do not let this fool you, however. The OSPF messages created by both the Juniper and Cisco routers contain the exact same area ID.
If the decimal number entered for the AID is greater than 255, JUNOS expresses the binary equivalent of the number in dotted-decimal format. The third entry in Figure 4.7, for instance, specifies an AID of 1547. 1547 in binary is 11000001011, which converts to the dotted-decimal number 0.0.6.11. The OSPF backbone area is always represented with an ID of all 0s (0.0.0.0). No other configuration is necessary to designate the backbone area, because this ID is reserved and recognized by OSPF. As with other AIDs, and as shown in Figure 4.7, the backbone AID can also be expressed simply as 0.
4.1.4. IS-IS System and Area IDsIn contrast to the OSPF AID and RID, which are expressed separately, the IS-IS AID and SysID are specified together in the Network Entity Title (NET). The NET is a special version of an ISO network service access point (NSAP) address, familiar to anyone who has worked with ISO protocols or with ATM. Figure 4.8 shows the basic format of a NET. Figure 4.8. The format of a Network Entity Title. As Figure 4.8 indicates, there are a few rules for configuring a NET:
The NET is always specified in hexadecimal. The Authority and Format Identifier (AFI) is actually a part of the Area ID, but is identified separately because of its special configuration rule. In ISO addresses, the AFI identifies the assigning authority of the address and the format of most of the rest of the address. But when the NET is assigned to a router in an IP-only network, the AFI has no real meaning separate from the rest of the AID. The last byte, the NSAP Selector (SEL), is used in ISO protocols to identify an upper-layer function to which the address pointssomething like a port number in IP protocols. The SEL value 0x00 specifies the router itself. In an IP-only network, where there are no upper ISO protocol layers, a router never examines the SEL, which therefore can be set to any 1-byte value. Nonetheless, common practice is to always set the SEL to 0x00.
|
holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.0/24 *[OSPF/10] 00:00:00, metric 3 > to 192.168.5.2 via fe-0/0/3.0 192.168.2.0/24 *[OSPF/10] 00:00:00, metric 2 > to 192.168.3.2 via fe-0/0/1.0 192.168.4.0/24 *[OSPF/10] 00:00:00, metric 2 > to 192.168.5.2 via fe-0/0/3.0 192.168.6.0/24 *[OSPF/10] 00:00:00, metric 2 > to 192.168.5.2 via fe-0/0/3.0 192.168.100.0/24 *[OSPF/150] 00:00:00, metric 0, 
EAN: 2147483647
Pages: 111