CCIECCIPCCNACCNPCertificationNetworkingOSPF

OSPF Router IDs

OSPF Router IDs:

 

OSPF 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:

  1. If a RID is administratively configured, that value is used.

  2. If no RID is administratively configured, an IP address configured on a loopback interface is used.

  3. If no IP address is configured on a loopback interface, an address is taken from a physical interface.

  4. If no IP address is configured on any interface and no RID is administratively configured, OSPF cannot start.

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.

Troubleshooting: Duplicate Router IDs:

Allowing 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.

Figure 4.1

Figure 4.2. The first display of the OSPF route entries appears normal.
Diab@R6> show route protocol ospf

 

inet.0: 19 destinations, 19 routes (18 active, 0
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,tag 0
                                                          > to 192.168.5.2 via fe-0/0/3.0
192.168.200.0/24                         *[OSPF/150] 00:00:00, metric 0,tag 0
                                                          > to 192.168.5.2 via fe-0/0/3.0
192.168.254.2/32                          *[OSPF/10] 00:00:00, metric 2
                                                          > to 192.168.5.2 via fe-0/0/3.0
192.168.254.5/32                         *[OSPF/10] 00:16:27, metric 1
                                                         > to 192.168.3.2 via fe-0/0/1.0
192.168.254.7/32                        *[OSPF/10] 00:00:00, metric 1
                                                        > to 192.168.5.2 via fe-0/0/3.0
224.0.0.5/32                                 *[OSPF/10] 2w3d 06:59:07, metric 1

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.

Figure 4.3. Here, most of the OSPF entries have disappeared from the route table.

Diab@R6> show route protocol ospf

inet.0: 11 destinations, 11 routes (10 active, 0  holddown, 1 hidden) + = Active Route, – = Last Active, * = Both

192.168.254.5/32            *[OSPF/10] 00:16:36, metric 1             
                                            > to 192.168.3.2 via fe-0/0/1.0
224.0.0.5/32                    *[OSPF/10] 2w3d 06:59:16, metric 1
 
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.
 
Figure 4.6. Some of the entries have returned again, but with a different next-hop address.
Diab@R6> show route protocol ospf
 inet.0: 17 destinations, 17 routes (16 active, 0 holddown, 1 hidden) + = Active Route, – = Last Active, * = Both 
192.168.1.0/24                   *[OSPF/10] 00:00:00, metric 4
                                                > to 192.168.3.2 via fe-0/0/1.0
192.168.2.0/24                   *[OSPF/10] 00:00:15, metric 2
                                               > to 192.168.3.2 via fe-0/0/1.0
192.168.6.0/24                   *[OSPF/10] 00:00:00, metric 3
                                                > to 192.168.3.2 via fe-0/0/1.0
192.168.254.2/32                 *[OSPF/10] 00:00:00, metric 3
                                                > to 192.168.3.2 via fe-0/0/1.0
192.168.254.4/32                 *[OSPF/10] 00:00:00, metric 2
                                                 > to 192.168.3.2 via fe-0/0/1.0
192.168.254.5/32                  *[OSPF/10] 00:22:08, metric 1
                                                 > to 192.168.3.2 via fe-0/0/1.00
192.168.254.7/32                  *[OSPF/10] 00:00:00, metric 2
                                                 > to 192.168.3.2 via fe-0/0/1.0
224.0.0.5/32                         *[OSPF/10] 2w3d 07:04:48, metric 1

 

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.

 

RID Configuration Tips

Although it is common practice to configure the RID on a loopback interface, my own preference is to administratively configure the RIDeven if it is the same number as the loopback interface address. This ensures beyond a doubt that the RID is exactly what you intend it to be, and anyone else reading the router’s configuration file can quickly determine the RID. Other network architects can and do disagree. What is important is not so much how you do it, but that you do it consistently. That is, you must have an established and well-documented network standard for setting the RID. The standard should be part of your addressing plan, and ensures that the same RID is not assigned to more than one router.

Another practice I like to stress is making certain that the RID is visibly different from any IP address used in the domain. For example, some octet of the RID might be 255, such as 192.168.255.X or 10.255.X.Y. Setting leading octets to 0, such as 0.0.0.X, is also useful. All that is important is that it is consistent and that it is understood by your operations personnel. With such a standard, a RID is readily recognized and easily distinguished from IP addresses during troubleshooting. Obviously, such an approach eliminates the use of IP addresses as RIDs that are otherwise legitimate within the domain.

 

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

8CRPV f1G4 2

Please type the text above:

Check Also

Close
Close
Close