Configuring OSPF in a Single Area When configuring any device, it is important to establish why you are configuring the system and what you are trying to achieve. This section examines the configuration of a Cisco router for OSPF within a single area. The commands are few and simple; the implications are somewhat more difficult. This section covers the following: -
Configuration of OSPF -
- Required configuration -
- Optional configuration -
Commands -
- What each configuration command achieves -
- How the configuration command achieves its goal Required Commands for Configuring OSPF on an Internal Router In this chapter, you learn to configure an internal router within a single area. An internal router is one that is within an area and whose sole function for OSPF is to route traffic within the area. The router needs to understand how to participate in the OSPF network. Therefore, it requires the following: -
The OSPF process The routing protocol needs to be started on the router. -
Participating router interfaces The router might not want to have all its interfaces send or receive OSPF routing updates. A classic example is a dialup line to a remote office. If there is only one subnet at the remote office, it would be more efficient to use default and static route commands, because any updates would dial the line. -
Identification of the area The router defines which area it is in on a per-interface basis. -
A router ID (RID) This allows the router to be identified by the other routers in the network. The algorithm used to create the routing table builds a graph from a single point. IP addresses are usually assigned to interfaces, so the router needs to assign an IP address to represent the router itself; this is the RID. The ID of the router advertising a link is used to determine the next logical hop, for example, if that link is used in the path selection to a remote network. The following two commands are required for configuring OSPF on a single internal router: Enabling the OSPF Routing Protocol When configuring the router for the first time, there is no IP routing protocol running on the Cisco router (unless the SETUP script is used). This is not true of other protocols, however; for example, if an IPX network address is configured on an interface, the IPX RIP process will be automatically started. To configure OSPF as the routing protocol, use the following command: Router(config)# router ospf process-number Here, process-number is a number local to the router. It is possible to have more than one process running on a router, although this is an unusual and expensive configuration in terms of router resources. Repeating the command with another ID number will create another process. One possible scenario for this configuration is a service provider that wants to separate its OSPF domain from its customer. The process number does not have to be the same on every router in the area or the autonomous system. In the interest of sanity , however, many administrators make it the same number. NOTE A common error in configuration is to confuse the process ID with the RID or the area ID. These are not related in any way. The process ID is simply a mechanism to allow more than one process to be configured on a router. The RID is the mechanism by which a router is identified within the OSPF domain, and the area ID is a mechanism of grouping routers that share full knowledge of OSPF-derived routes within the OSPF domain.
Enabling the OSPF network Command Although you have turned on OSPF, it has no information about how to operate . The networks that are to participate in the OSPF updates, and the area that they reside in, must be defined. If the following information is not specified, the process will have nothing to do: Router(config-router)# network network-number wildcard-mask area area-number This command deserves a moment's explanation because it is the cause of many errors in configuration. The network command in OSPF plays a similar role to that of the network command in RIP or IGRP. The difference is the level of granularity afforded to the administrator. In RIP and IGRP, the network command is defined at the class level. In OSPF, it is possible to identify the specific address of an interface. The additional parameter area states the area that the interface inhabits. This allows a router to have different interfaces in different areas, making it an area border router (ABR). The area-number is a 32-bit field and the format can take one of two forms: The first is a simple decimal, and the second is a dotted decimal format similar to that of an IP address. Some implementations of OSPF might only understand one of the formats, but Cisco will accept either form. However, it is important to remember that decimal and dotted decimal use different numbering systems. For example, while 0.0.0.5 and 5 are the same, the area 0.0.4.6 is equivalent to 1030 in decimal. The dotted decimal notation is a stream, which you should think of as a continuation of the binary numbers ; it does not start again as in an IP address. So the decimal number 1030 is 1024+6 or 00000000.00000000.00000100.00000110 What the network Command Will Do After the network command has been entered, OSPF identifies which interfaces are participating in OSPF by comparing the interface IP address with the address given in the network command, filtered through the wildcard mask. The wildcard mask states how much of the address to pay attention to. The wildcard mask could look at just the class of address, such as everything in network 10.0.0.0, for example. At the other extreme, the mask can be more specific and identify an interface address. All interfaces that match the given network number will reside in the area specified in the network command. CAUTION Take great care in choosing the wildcard mask. Remember that it follows the same format as the wildcard mask in an access list. It is extremely easy to make errors in the configuration, and those errors might be difficult to find.
After identifying the interfaces on the router that are participating in the OSPF domain, the following happens. -
Updates will be received on the interface. -
Updates will be sent out of the interfaces. -
The interface will be placed in the defined area. -
If appropriate, the Hello protocol will be propagated. Depending on the interface type, a default hello and dead interval are defined based on the OSPF network type. This network command has many of the same characteristics as an access list. The wildcard mask has the same format and enables you to group interfaces into an area. It follows the same top-down logic of a link list, as seen in an access list. NOTE If there are stub networks connected to a router, it is useful to issue the command redistribute connected subnets . This command is issued as part of the router process configuration, and it includes the connected subnets in OSPF advertisements without actually running OSPF on them. This is very useful for real OSPF configurations, particularly those that involve WAN pay- per-packet , low-bandwidth links.
Configuration Examples The following examples show how one command can cover all router interfaces, and also how each individual interface can be specified. Given a router with six interfaces, three with addresses in the 10.0.0.0 class and three with addresses in the 172.16.0.0 class, the following would configure all interfaces to participate in OSPF area 0: Router(router-config)# network 0.0.0.0 255.255.255.255 area 0 The following would have only the interfaces addressed from 10.0.0.0 participating in OSPF area 0: Router(config-router)# network 10.0.0.0 0.255.255.255 area 0 The next example shows only two specific interfaces participating in OSPF area 0: Router(config-router)# network 10.12.0.1 0.0.0.0 area 0 Router(config-router)# network 172.16.15.1 0.0.0.0 area 0 Why Is the network Command so Complex? It is reasonable to ask why OSPF is so much more complex than either IGRP or RIP in this instance. The answer is that the level of precision available in the OSPF network command provides the capability to place different interfaces into different areas on the same router. The need for this complexity is not obvious in this example because an internal router is being configured within a single area. The flexibility in defining which interfaces reside in which area is considered in Chapter 9, "Configuring OSPF Across Multiple Areas," in the section "Required Configuration Commands for a Multiarea OSPF Network." Options for Configuring OSPF on an Internal Router The following options are not necessary to make OSPF function properly within an area. However, they might be useful in your network design: -
The loopback interface -
The cost command -
The priority command -
The RID The following sections describe each option in more detail. The Loopback Interface and the Router ID The router needs an ID to participate in the OSPF domain. The RID is used to identify the source of LSA updates as shown in the OSPF database. This ID takes the form of an IP address. The address can be either defined by the administrator or left to the whim of the router. Most people define the ID so that it is easier to track events in the network, for internal documentation, and for other system-administration purposes. The use of loopback interface addresses is often used to define the RID, as described in the following section. A loopback interface is a virtual interface, which has the advantage of never going down because it has no physical characteristics. The Default Router ID Selection The most common method of defining the RID is to use the defaults offered by Cisco. The default RID is taken from the highest IP address assigned to a loopback interface. If no loopback is defined, then OSPF takes the highest IP interface address as the RID. If no ID is stated, the router will take the highest IP address configured on a loopback interface. Although it is unlikely that this address will change, it is possible. From an administrative viewpoint, such a change would introduce an unnecessary level of chaos into the network. Manual Configuration of Router ID The command to define the OSPF RID is within the router configuration. If there is no RID defined, there are other methods . The Cisco rule states that the RID will be taken from the address of the loopback interface. If no loopback interface is defined, it uses the highest IP address of the active interfaces configured on the router. Once the RID of the router has been chosen, the RID is not dependent on whether the interface is active or even functional until the router is rebooted. At that point, a different RID would be chosen from the active IP addresses. This could break some OSPF configurations, such as virtual links. You are therefore advised to configure the loopback interface. Because a virtual interface does not exist physically, it can never go down. Therefore, the OSPF RID is not vulnerable to hardware interface problems if the router reboots. It is possible to have multiple loopback interfaces, in which case the loopback interface with the highest IP address will be selected if no RID has been configured. Many organizations choose a different addressing scheme for the loopbacks to distinguish them easily when troubleshooting. Remember that each interface requires a separate subnet. The use of a private address from RFC 1918 might be wise. Private addresses will not deplete the IANA address that is being used by the organization and have the advantage of being easily distinguished for administrative documentation. The following shows how to configure the RID: Router(config)# router ospf Router(config-router)# router-id ip-address The following shows how to configure a loopback interface: Router(config)# interface loopback interface-number Router(config-if)# ip address ip-address subnet-mask NOTE When designing a network, consider whether to include the loopback interface address in the network commands. There are both advantages and disadvantages to this, and they should be researched in any network design. If the organization is running out of valid addresses, it might be advisable to use the loopback address only as an RID and not to insert it into the routing table. The disadvantage of this configuration is that it cannot be pinged for testing. This is known as a bogus RID. The preferred configuration would be to have an address in the routing table. These addresses are assigned a /32 subnet mask.
Changing the Default Metric Using the cost Command Another command that might be useful is the cost command. This command manually overrides the default cost that the router assigns to the interface. The default cost is calculated based on the bandwidth parameter assigned to the outgoing interface with the bandwidth command. The cost command syntax is as follows: Router(config-if)# ip ospf cost cost A lower cost increases the likelihood that the interface will be selected as the best or shortest path. The range of values configurable for the cost of a link is 1 to 65535. In general, the path cost in Cisco routers is calculated using the formula 10 8 /bandwidth. Table 7-2 shows examples of default costs. Table 7-2. Default Costs in OSPF | Link Type | Default Cost | | 56-kbps serial link | 1785 | | T1 (1.544-Mbps serial link) | 64 | | Ethernet | 10 | | 16-Mbps Token Ring | 6 | | FDDI | 1 | NOTE Serial lines have many different speeds. The default bandwidth is 1.544 Mbps. If the line is a slower speed, use the bandwidth command to specify the real link speed. The cost of the link will then change to correspond to the bandwidth that you configured.
As shown in Table 7-2, the calculation of bandwidth gives FDDI a metric of 1. If you have multiple links with high bandwidth, you might want to have a higher number than the default cost in order to differentiate the cost on those links. It is also possible to control how OSPF calculates default metrics for the interface. Use the ospf auto-cost reference-bandwidth router global configuration command to change the numerator of the previous OSPF cost formula: Router(config-router)# ospf auto-cost reference-bandwidth reference-bandwidth Here, reference-bandwidth is in megabytes per second. The range is 1 to 4,294,967; the default is 100. This means that a cost of 1 = 100 Mbps, and a cost of 10 = 100/10 = 10 Mbps. If you are moving to gigabit, you would want 1000 Mbps = 1 Gbps. Any change using the ospf auto-cost reference-bandwidth command should be done on all routers in the autonomous systems so that they all use the same formula to calculate cost. The value set by the ip ospf cost command overrides the cost resulting from the auto-cost reference-bandwidth command. In some of the Cisco IOS software documentation, the auto-cost command is documented as ospf auto-cost . However, auto-cost is the actual command in the Cisco IOS. Check the command reference set for the command for your IOS version. Considerations in using the cost command include the following: -
Never change defaults unless you can explain why the change is necessary. Reasons for using the cost option in OSPF include the following: -
- You want to maintain interoperability among different vendors running OSPF. -
- There is a design reason to choose a different path than the one selected by the Cisco default metric. -
- You want to allow greater granularity in the application of the cost metric. -
If you override the default by manual configuration, it is important that you consider the physical and logical topology map of the network. Any change to the metric might change the traffic patterns in the network. Determining the Designated Router Using the priority Command The last optional command to consider is the priority command. You use this command to determine the designated router (DR) and backup designated router (BDR) on a multiaccess link. Remember that the Hello protocol carries the priority field and is the mechanism by which the DR and BDR are elected. To be "up for election," the priority must be a positive integer between 1 and 255. If the priority is 0, the router cannot participate in the election. The higher the priority, the greater the likelihood of being elected. If no priority is set, all Cisco routers have a default priority of 1, and the highest RID is always used as a tiebreaker. Reasons for increasing the router priority include the following: -
The router has greater CPU and memory than the others do on the LAN. -
The router is the most reliable router on the segment. -
All the other routers on the LAN connect to stub networks. They all form the access layer of the network. -
There are point-to-multipoint connections in an NBMA cloud, and the hub router needs to be configured as the centralized resource, requiring it to be the DR. -
The router is an ABR, and you do not want it to consume more resources as a DR, so another router on the subnet either has its priority increased or the ABR has its priority decreased. The following section shows these commands in context to make their use and functionality much more apparent. A Working Configuration of OSPF on a Single Router Example 7-1 is a working configuration of OSPF on a single router. Use this example in conjunction with Figure 7-1. Figure 7-1. Diagram for the Configuring OSPF Example  The San Jose router is selected as the DR, after its priority is set to 100, and the cost of the fast Ethernet interface is set to 10, overriding the default cost. Example 7-1. Configuring OSPF SanJose(config)# router ospf 100 SanJose(config-router)# network 140.100.0.0 0.0.255.255 area 3 SanJose(config-router)# interface FastEthernet1/0 SanJose(config-if)# ip address 140.100.17.129 255.255.255.240 SanJose(config-if)# ip ospf priority 100 SanJose(config-if)# no shutdown SanJose(config-if)# interface FastEthernet3/0 SanJose(config-if)# ip address 140.100.17.193 255.255.255.240 SanJose(config-if)# ip ospf cost 10 SanJose(config-if)# no shutdown SanJose(config-if)# interface Fddi2/0 SanJose(config-if)# ip address 140.100.32.10 255.255.255.240 SanJose(config-if)# no ip directed-broadcast SanJose(config-if)# no shutdown Configuring OSPF over an NBMA Topology The design considerations of running OSPF over an NBMA topology require thought and research because the configuration choices that are made will dramatically affect your network. This section covers one of the common choices on a partially meshed network, illustrates the kind of decisions that need to be made, and shows the configuration that would be implemented. If the network is partially meshed, then the choice to use only point-to-point subnets can waste addresses. If you choose a point-to-multipoint configuration, the network uses one subnet, and there is no DR/BDR negotiation. This configuration has the advantage of saving addresses but behaves as if it is a series of point-to-point links. If private addressing is used, this might not be a consideration. When the decision is made as to which technology is to be implemented, whether you are using point-to-point or point-to-multipoint, the configuration is straightforward. The choice is defined on the interface as an ip ospf network command. The network command syntax is as follows: Router(config-if)# ip ospf network { broadcast non-broadcast { point-to-multipoint [ non-broadcast ]}} Table 7-3 explains the command. Table 7-3. The ip ospf network Command | Option | Description | | broadcast | Sets the network mode to broadcast. | | non-broadcast | Sets the network mode to nonbroadcast multiaccess (NBMA mode). This is the default mode for serial interfaces with Frame Relay encapsulation and point-to-multipoint subinterfaces. Router(config-if)# ip ospf network non-broadcast | | point-to-multipoint | Sets the network mode to point-to-multipoint. | | point-to-multipoint non-broadcast | (Optional) Sets the network mode to point-to-multipoint nonbroadcast. | Configuring OSPF in NBMA Mode In NBMA mode, the design considerations are imperative, because the selection of the DR and BDR must ensure physical connectivity to all routers in the NBMA cloud. Remember that this is a nonbroadcast environment, so you must configure the DR and BDR with a static list of the other routers attached to the cloud so that they can become neighbors and create adjacencies. This is achieved with the use of the neighbor command. NOTE New technologies introduced to OSPF have removed the need to configure the neighbors manually. These technologies are explained later in the section "Configuring OSPF in Point-to-Multipoint Mode."
The syntax of the command is as follows: Router(config-if)# neighbor ip-address [ priority number ] [ poll-interval sec ] [ cost number ] You use the neighbor command to configure OSPF routers interconnecting to nonbroadcast networks. The different options used with the neighbor command are explained in Table 7-4. Table 7-4. The OSPF neighbor Command | Syntax | Description | | ip-address | Interface IP address of the neighbor. | | priority number | (Optional) An 8-bit number indicating the likelihood of the neighbor being elected as the BDR or the DR. The default is 0. This keyword does not apply to point-to-multipoint mode interfaces because no BDR or DR is selected. This is another way of setting the ip ospf priority command. The highest priority is used, irrespective of the command used to set it. | | poll-interval sec | (Optional) Unsigned integer value reflecting the poll interval. RFC 1247 recommends that this value be much larger than the hello interval. The default is 120 seconds (2 minutes). This keyword does not apply to point-to-multipoint mode interfaces. If a neighboring router has become inactive (hello packets have not been seen for the router dead interval period), it might still be necessary to send hello packets to the dead neighbor. These hello packets will be sent at a reduced rate, called the poll interval, to ensure connectivity is maintained while preserving bandwidth. | | cost number | (Optional) Value that assigns a cost or metric. It takes the form of an integer from 1 to 65,535. Neighbors with no specific cost configured will assume the cost of the interface, based on the bandwidth or the ip ospf cost command. | Example 7-2 shows how the command is used. Example 7-2. The OSPF neighbor Command Router(config)# interface Serial0 Router(config-if)# ip address 131.144.10.100 255.255.255.0 Router(config-if)# encapsulation frame-relay Router(config-if)# ip ospf network non-broadcast Router(config)# router ospf 1 Router(config-router)# network 131.144.10.100 0.0.0.255 area 0 Router(config-router)# neighbor 131.144.10.2 Router(config-router)# neighbor 131.144.10.3 Router(config-router)# neighbor 131.144.10.5 NOTE NBMA mode is used by default in a nonbroadcast multiaccess environment, so there is no need for the ip ospf network non-broadcast command. However, neighbor statements are necessary.
Configuring OSPF in Point-to-Multipoint Mode An OSPF point-to-multipoint interface is seen as a numbered point-to-point interface with one or more neighbors. The cloud is configured as one subnet with a host route for each router involved in the OSPF cloud. NOTE The ip ospf network point-to-multipoint non-broadcast command option is a feature related to point-to-multipoint networks with Cisco IOS Software Release 11.3a. You can find more information on the subject by searching Cisco.com with the keywords "OSPF point-to-multipoint network with separate costs per neighbor" or click the link to the Technical Support OSPF page.
By default, the network is considered to be a series of point-to-point interfaces. There is no need to specify neighbors, because the neighbors will see each other and simply become adjacent, with no need for the election of a DR or a BDR. Point-to-multipoint does not try to reduce adjacencies using a DR. Instead, it accepts the extra overhead of having a full set of adjacencies for the sake of stability. Point-to-multipoint forms an adjacency automatically along any PVC, which causes more overhead but is more resilient than NBMA. You can specify neighbors with the neighbor command, in which case you should specify a cost to each neighbor. You are not required to have a fully meshed topology, which reduces the number of PVCs needed and the number of neighbor entries in the neighbor table. It is possible to change the default of NBMA to point-to-multipoint with the command ip ospf network point-to-multipoint and to nonbroadcast network with the command ip ospf network point-to-multipoint non-broadcast. The point-to-multipoint network is then considered a nonbroadcast network, and the mode is a Cisco extension. The neighbor command is required to identify neighbors in a nonbroadcast network. Assigning a cost to a neighbor is optional. Example 7-3 shows the necessary configuration for OSPF in point-to-multipoint mode (point-to-multipoint broadcast mode, compliant with the RFC 2328, because the keyword non-broadcast is not specified). There is no need to configure neighbors, although you can do so if desired. Example 7-3. Configuring Point-to-Multipoint Networks Router(config)# interface Serial0 Router(config-if)# ip address 10.1.1.1 255.255.255.0 Router(config-if)# encapsulation frame-relay Router(config-if)# ip ospf network point-to-multipoint Router(config)# router ospf 1 Router(config-router)# network 10.1.1.0 0.0.0.255 area 0 Configuring OSPF in Broadcast Mode You use the broadcast mode to avoid using the neighbor command and all the attendant configurations. This broadcast mode works best with a fully meshed network. Example 7-4 shows a typical configuration of OSPF in broadcast mode. Example 7-4. Configuring a Broadcast Network Router(config)# interface Serial0 Router(config-if)# ip address 10.1.1.1 255.255.255.0 Router(config-if)# encapsulation frame-relay Router(config-if)# ip ospf network broadcast Router(config)# router ospf 1 Router(config-router)# network 10.1.1.0 0.0.0.255 area 0 Configuring OSPF in Point-to-Point Mode on a Frame Relay Subinterface In the point-to-point mode, the adjacency created between the routers is automatic because each subinterface behaves as a physical point-to-point network. Therefore, the communication is direct and automatic. The following steps explain how to configure OSPF point-to-point mode on subinterfaces: - Step 1. Configure Frame Relay encapsulation on the interface.
- Step 2. At the interface level, create a subinterface.
It is recommended that you remove any network layer address assigned to the physical interface using the no ip address command. The Layer 3 address should be assigned to the subinterface.
- Step 3. Configure the Layer 3 and Layer 2 (DLCI) addresses on the subinterface.
- Step 4. Point-to-point mode is the default OSPF mode for point-to-point subinterfaces, so no further configuration is required.
Example 7-5 shows the necessary configuration required for a point-to-point Frame Relay subinterface. Example 7-5. Configuring a Point-to-Point Frame Relay Subinterface Router(config)# interface Serial0 Router(config-if)# no ip address Router(config-if)# encapsulation frame-relay Router(config)# interface Serial0.1 point-to-point Router(config-subif)# ip address 10.1.1.1 255.255.255.0 Router(config-subif)# frame-relay interface-dlci 51 Router(config)# interface Serial0.2 point-to-point Router(config-subif)# ip address 10.1.2.1 255.255.255.0 Router(config-subif)# frame-relay interface-dlci 52 Router(config)# router ospf 1 Router(config-router)# network 10.1.0.0 0.0.255.255 area 0 The shading in the previous example shows the configuration required to create a subinterface running point-to-point Frame Relay with IP. Of course, it is imperative to check any configuration on a network device, because any errors could potentially bring down the entire network. To verify the configuration, there is a wealth of Cisco commands. They are covered in the following section. Checking the Configuration of OSPF on a Single Router The set of commands shown in Table 7-5 is invaluable in both configuration and maintenance of a live network. These commands are particularly useful in troubleshooting the network. As such, these commands are a necessary set of tools for use on a daily basis, for the CCNP/CCDP/CCIP BSCI exam, and for the CCIE lab exam. Table 7-5. The show Command Options for OSPF | Command Option | Description | | show ip ospf | Shows the OSPF process and its details, for example, how many times the router has recalculated its routing table. | | show ip ospf database | Shows the contents of the topological database. | | show ip ospf interface | Gives information about how OSPF has been configured on each interface. Typing errors are easily seen with this command. | | show ip ospf neighbor | Displays all the information about the relationship that the router has with its neighborsfor example, the status of communication. One of the main points of interest is whether all the neighbors are present in the table. | | show ip protocols | Enables you to view the IP routing protocol configuration on the router. | | show ip route | Shows detailed information about the networks that the router is aware of and the preferred paths to those networks. Also gives the next logical hop as the next step in the path. | NOTE An excellent resource is the Cisco web site, which takes you through a series of flowcharts to identify a particular problem and how to solve it. These flowcharts are nested, so expect to work through several levels. This is an excellent resource for understanding troubleshooting techniques that are beyond the scope of this book or the BSCI exam. You can find the flowcharts at this URL: http://www.cisco.com/warp/public/104/trouble_main.html
Understanding the output of these commands is important. This is not just because the output might constitute questions on the exam, but because the capability to analyze what is happening on the network demands a thorough understanding of the concepts explained in this chapter. You need to understand the concepts in this chapter to interpret the output of a show command. The OSPF show commands are highly detailed and give a comprehensive understanding of the state of the network. The show ip ospf Command This section explains the show ip ospf command. This command is extremely useful, because it shows how the OSPF routing protocol is running on a particular router. It includes the number of times that the SPF routing algorithm has been run, which is indicative of the stability of the network. To issue the command, use the following syntax: Router# show ip ospf [ process-id ] Example 7-6 shows the output of this command. Table 7-6 explains how to read this information. Example 7-6. The show ip ospf process-id Command Output SanJose# show ip ospf 100 Routing Process "ospf 100" with ID 140.100.32.10 Supports only single TOS(TOS0) routes It is an internal router SPF schedule delay 5 secs, Hold time between two SPFs 10 secs Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs Number of external LSA 0. Checksum Sum 0x0 Number of DCbitless external LSA 0 Number of DoNotAge external LSA 0 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Area 3 Number of interfaces in this area is 3 Area has no authentication SPF algorithm executed 10 times Area ranges are Link State Update Interval is 00:30:00 and due in 00:18:54 Link State Age Interval is 00:20:00 and due in 00:08:53 Number of DCbitless LSA 2 Number of indication LSA 0 Number of DoNotAge LSA 0 Table 7-6. Explanation of the show ip ospf Command Output | Field | Explanation | | Routing Process "ospf 100" with ID 140.100.32.10 | Shows the local process ID for OSPF and the RID that it will advertise. | | Supports only single ToS (TOS0) routes | OSPF is capable of carrying information about the type of service (ToS) that the IP datagram has requested . This is supported by Cisco in accordance with the RFCs but only implements the value 0. | | It is an internal router | Species the types of router that OSPF defines, including internal, area border, and autonomous system boundary router. | | SPF schedule delay | Specifies how long to wait to start the SPF calculation after receiving an LSA update to prevent running SPF too often. | | Hold time between two SPFs | Specifies the minimum amount of time between SPF calculations. | | Number of DCbitless external LSA | Used with OSPF demand circuits. Refer to the Cisco web site for greater detail on this subject. | | Number of DoNotAge external LSA | Used with OSPF demand circuits, such as ISDN. | | Summary Link update interval is 0:00:00 and the update is due in 0:00:00 | An ABR would transmit this link-state advertisement (LSA) into another area. Summarization occurs at the area border. As an internal router, this router is not capable of issuing this update. | | External Link update interval is 0:00:00 and the update due in 0:00:00 | An autonomous system boundary router would transmit this LSA into another routing protocol using redistribution. The update is external to the domain or autonomous system. As an internal router, this router is not capable of issuing this update. | | Area 3 Number of interfaces in this area is 3 Area has no authentication SPF algorithm executed 10 times Area ranges are | Specifies the number of areas of which this router is a member. As an internal router, it is configured for a single area and is a member of one area. At a glance, it is possible to see how many of the router's interfaces are in an area and whether the router is using MD5 security. It is useful to see the number of times that the SPF algorithm has been executed, because this is an indication of the network stability. The area ranges show any summarization that has been configured. | | Link State Update Interval is 00:30:00 and due in 00:18:54 | The default for the LSA update timer is 30 minutes. This is used to ensure the integrity of the topological databases. This field shows when the next update is and that the default has not been changed. These update timers should be the same throughout the area. | | Link State Age Interval is 00:20:00 and due in 00:08:53 | This specifies the MAX-AGED update deletion interval and shows when the database will next be purged of out-of-date routes. | The show ip ospf database Command The following command displays the contents of the router's topological database and the different LSAs that have populated the database: Router# show ip ospf database In this example, because the router used is an internal router, the LSAs displayed will be the router and network updates. This command has many parameters that enable the user to examine very specific information. This section considers the general command. Example 7-7 shows the output of this command. Table 7-7 explains the meaning of the important fields. Example 7-7. The show ip ospf database Command Output SanJose# show ip ospf database OSPF Router with ID (140.100.32.10) (Process ID 100) Router Link States (Area 3) Link ID ADV Router Age Seq# Checksum Link count 140.100.17.131 140.100.17.131 471 0x80000008 0xA469 1 140.100.17.132 140.100.17.132 215 0x80000007 0xA467 1 140.100.17.194 140.100.17.194 1489 0x8000000B 0xFF16 1 140.100.23.1 140.100.23.1 505 0x80000006 0x56B3 1 140.100.32.10 140.100.32.10 512 0x8000000C 0x46BA 3 140.100.32.11 140.100.32.11 150 0x80000006 0x6A73 1 140.100.32.12 140.100.32.12 1135 0x80000002 0x8E30 1 Net Link States (Area 3) Link ID ADV Router Age Seq# Checksum 140.100.17.130 140.100.23.1 220 0x80000007 0x3B42 140.100.17.194 140.100.17.194 1490 0x80000002 0x15C9 140.100.32.11 140.100.32.11 150 0x80000004 0x379E Table 7-7. Explanation of the show ip ospf database Command | Field | Explanation | | OSPF Router with ID (140.100.32.10) (Process ID 100) | The RID and the process ID of the router being viewed . | | Router Link States (Area 3) | The router LSAs, showing the links connecting the router to neighbors discovered via the Hello protocol. | | Link ID | The link ID, which is the same as the OSPF RID. | | ADV Router | The OSPF RID of the advertising router. Note that the ID is the same as the link ID when describing the router LSAs. This is because the router is advertising these links in its router LSA to the area. | | Age | The age is the length of time since the last update. It is shown in seconds. | | Seq # | The sequence number, used to ensure that the LSA is truly an update that is more recent than anything currently in the topological database. | | Checksum | The checksum on the entire LSA update. Ensures the integrity of the update. | | Link count | The number of links that the router has configured for OSPF. Note that this field is shown only for the router LSA update. | | Net Link States (Area 3) | Information taken from the network LSAs that have been received by the router. | | Summary Net Link States (Area 3) | Information taken from the summary LSAs, which are passed between the ABRs. As an internal router in a single area, this section of the display would be blank. | The show ip ospf interface Command This command shows how OSPF has been configured on an interface level and how it is working at the interface. This level of detail is excellent for troubleshooting configuration errors: Router# show ip ospf interface [ type number ] Important information such as the DR, the BDR, a list of neighbors, and the network type is shown by this command. Example 7-8 shows the output of this command. Table 7-8 explains how to read this information. Example 7-8. The show ip ospf interface [type number] Command Output SanJose# show ip ospf interface fastethernet1/0 FastEthernet1/0 is up, line protocol is up Internet Address 140.100.17.129/28, Area 3 Process ID 100, Router ID 140.100.32.10, Network Type BROADCAST, Cost: 1 Transmit Delay is 1 sec, State DR, Priority 100 Designated Router (ID) 140.100.32.10, Interface address 140.100.17.129 Backup Designated router (ID) 140.100.23.1, Interface address 140.100.17.130 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:06 Neighbor Count is 3, Adjacent neighbor count is 2 Adjacent with neighbor 140.100.17.132 Adjacent with neighbor 140.100.17.131 Adjacent with neighbor 140.100.23.1 (Backup Designated Router) Suppress hello for 0 neighbor(s) Table 7-8. Explanation of the show ip ospf interface Command | Field | Explanation | | FastEthernet1/0 is up, line protocol is up | This should be seen as two statements. The first half of the sentence indicates that the physical line is operational. This meaning differs with the type of interface; for Ethernet, it indicates the presence of the transceiver. The second portion of the sentence indicates that the data link layer is working. | | Internet Address 140.100.17.129/28, | The IP address and mask configured on the interface. | | Area 3 | The OSPF area for which the interface is configured. | | Process ID 100, Router ID 140.100.32.10 | The autonomous system number, which is in fact the OSPF process ID. The RID shown will be advertised in the LSA updates. | | Network Type BROADCAST | The type of network to which the interface is connected, which indicates how neighbors are found and adjacencies are formed . | | Cost: 1 | The metric cost of the link, which, although not stated, was probably dynamically chosen using the Cisco defaults. | | Transmit Delay is 1 sec | The anticipated time taken to send an update to the neighbor. The default is 1 second. | | State DR | The state of the link in reference to establishing adjacencies. This field is extremely useful in troubleshooting. Here are the states in order of progression: DOWN Heard from no one. ATTEMPT Sent a hello on an NBMA, but haven't heard back. INIT Heard a hello, but have not achieved neighbor status. TWO-WAY Established full neighbor relationship; saw itself in the neighbor's hello table. EXSTART Starting up the link for exchanging DDPs. EXCHANGE Sending DDPs to other router. LOADING Building the database and LSAs from the DDPs. FULL Established adjacency. DR Is the designated router for this LAN. | | Priority 100 | The priority is sent in the Hello protocol and is used to determine the election of the DR and the BDR. The value of 1 means that the router is prepared to be elected. If every other router has the priority of 1, the highest RID will select the routers. | | Designated Router (ID) 140.100.32.10, Interface address 140.100.17.129 | The address of the elected DR. Note that the ID and the interface ID differ . This is a useful field for troubleshooting misconfiguration. | | Backup Designated router (ID) 140.100.23.1, Interface address 140.100.17.130 | The address of the BDR. Note that both the ID and the interface are given, and that they differ. | | Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 | It is possible to change these timers, and it is sometimes necessary if connecting to another vendor's equipment that has different defaults. These timers should be consistent throughout the area. The timer intervals shown here are the defaults for broadcast and point-to-point network types. | | Hello due in 00:00:06 | When the next hello packet is due to be sent out of the interface. | | Neighbor Count is 3, Adjacent neighbor count is 2 | The number of routers that have neighbor relationships. Note that the number of routers with which adjacency is established is less than the number of neighbors. This is because there is a DR and a BDR, whose responsibility it is to maintain the adjacencies with all routers on the LAN. | | Adjacent with neighbor 140.100.23.1 (Backup Designated Router) | The RID of the adjacent router, which is the BDR in this case. | The show ip ospf neighbor Command This command shows OSPF neighbors. All the neighbors known to the router can be viewed, or the command can be made more granular and the neighbors can be shown on a per-interface basis. One neighbor also might be picked out for scrutiny. This level of detail is excellent for troubleshooting configuration errors: Router# show ip ospf neighbor [ type number ] [ neighbor-id ] [ detail ] Example 7-9 shows the output of this command. Example 7-9. The show ip ospf neighbor Command Output SanJose# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 140.100.17.132 1 FULL/DROTHER 00:00:36 140.100.17.132 FastEthernet1/0 140.100.17.131 1 FULL/DROTHER 00:00:37 140.100.17.131 FastEthernet1/0 140.100.23.1 1 FULL/BDR 00:00:38 140.100.17.130 FastEthernet1/0 140.100.32.12 1 FULL/DROTHER 00:00:35 140.100.32.12 Fddi2/0 140.100.32.11 1 FULL/DR 00:00:32 140.100.32.11 Fddi2/0 140.100.17.194 1 FULL/DR 00:00:31 140.100.17.194 FastEthernet3/0 To be more specific in what is viewed, it is possible to look at the neighbors that have been discovered on a particular interface, as seen in Example 7-10. Example 7-10. The Neighbors That Have Been Discovered on a Particular Interface SanJose# show ip ospf neighbor fddi 2/0 Neighbor ID Pri State Dead Time Address Interface 140.100.32.12 1 FULL/DROTHER 00:00:36 140.100.32.12 Fddi2/0 140.100.32.11 1 FULL/DR 00:00:32 140.100.32.11 Fddi2/0 To see all the neighbors in as much detail as possible, however, use the command displayed in Example 7-11. Example 7-11. Using the show ip ospf neighbor detail Command SanJose# show ip ospf neighbor detail Neighbor 140.100.17.132, interface address 140.100.17.132 In the area 3 via interface FastEthernet1/0 Neighbor priority is 1, State is FULL, 6 state changes DR is 140.100.17.129 BDR is 140.100.17.130 Options 2 Dead timer due in 00:00:35 Neighbor 140.100.17.131, interface address 140.100.17.131 In the area 3 via interface FastEthernet1/0 Neighbor priority is 1, State is FULL, 6 state changes DR is 140.100.17.129 BDR is 140.100.17.130 Options 2 Dead timer due in 00:00:34 Neighbor 140.100.23.1, interface address 140.100.17.130 In the area 3 via interface FastEthernet1/0 Neighbor priority is 1, State is FULL, 6 state changes DR is 140.100.17.129 BDR is 140.100.17.130 Options 2 Dead timer due in 00:00:36 Neighbor 140.100.32.12, interface address 140.100.32.12 In the area 3 via interface Fddi2/0 Neighbor priority is 1, State is FULL, 6 state changes DR is 140.100.32.11 BDR is 140.100.32.10 Options 2 Dead timer due in 00:00:32 Neighbor 140.100.32.11, interface address 140.100.32.11 In the area 3 via interface Fddi2/0 Neighbor priority is 1, State is FULL, 6 state changes DR is 140.100.32.11 BDR is 140.100.32.10 Options 2 Dead timer due in 00:00:38 Neighbor 140.100.17.194, interface address 140.100.17.194 In the area 3 via interface FastEthernet3/0 Neighbor priority is 1, State is FULL, 9 state changes DR is 140.100.17.194 BDR is 140.100.17.193 Options 2 Dead timer due in 00:00:38 Table 7-9 explains the meanings of the important fields from Examples 7-9 through 7-11. Table 7-9. Explanation of the show ip ospf neighbor Command | Field | Explanation | | Neighbor | This is the RID. | | Neighbor priority | This is the priority sent out with the Hello protocol to elect the DR and the BDR. | | State | This shows the state, not of the link, but whether the interface was elected. DR Designated router. BDR Backup designated router. DROTHER The router was not chosen as the DR or the BDR. If the priority on the interface had been set to zero, the state would always be DROTHER because the router could not be elected as a DR or a BDR. | | Dead Time | The dead time is how long the router will wait without hearing the periodic hello from its neighbor before it is declared dead. This timer should be consistent on the network; otherwise , there will be problems. | | Address | This is the interface address of the neighbor. Note that the RID is not the same as the interface address. If the loopback address or the highest IP address on the router has been used, the address probably will differ. | | Interface | This is the outgoing interface of the router, upon which the neighbor routers were heard. | | Options | The option available is one of design. It identifies whether the area the neighbors inhabit is a stub area. | The show ip protocols Command This command shows the configuration of IP routing protocols on the router. It details how the protocols were configured and how they interact with one another. It also indicates when the next updates will occur. This command is excellent for troubleshooting configuration errors and understanding how the network is communicating about its routes: Router# show ip protocols Example 7-12 shows the output of this command. Table 7-10 explains how to read this information. Example 7-12. The show ip protocols Command Output SanJose# show ip protocols Routing Protocol is "ospf 100" Sending updates every 0 seconds Invalid after 0 seconds, hold down 0, flushed after 0 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: ospf 100 Routing for Networks: 140.100.0.0 Routing Information Sources: Gateway Distance Last Update 140.100.17.131 110 00:50:23 140.100.17.132 110 00:50:23 140.100.17.194 110 00:07:39 140.100.23.1 110 00:50:23 140.100.32.11 110 00:07:39 140.100.32.12 110 00:07:39 Distance: (default is 110) Table 7-10. Explanation of the show ip protocols Command | Field | Explanation | | Routing Protocol is "ospf 100" | This routing protocol is configured on the router. If there is more than one routing protocol configured, the details of each are listed in turn . | | Sending updates every 0 seconds | The frequency of the routing update is shown. It is not relevant for a link-state routing protocol that sends updates of changes as required (incremental updates). | | Invalid after 0 seconds | This field is relevant for distance vector protocols. It indicates the period of time that a route is considered valid, from the time of the last update. If an update on the status of the route has not been received in this defined value, the route is marked unreachable. | | hold down 0 | Holddown timers are used only in distance vector protocols. If a distance vector protocol suspects that a route in its table is bad, it will mark it down but will not accept another path with a less-favorable metric until the holddown timer has expired . This is to avoid loops in the network. If a link-state protocol hears an update, it acts on the information. | | flushed after 0 | The 0 value indicates that this is a field used by distance vector routing protocols. After marking a route as invalid, it will flush it from the routing table after this timer has expired. | | Outgoing update filter list for all interfaces is not set | Access lists can be set on an interface to filter networks from the routing update. This should be used carefully because it affects connectivity. | | Incoming update filter list for all interfaces is not set | The access list can filter either outgoing or incoming updates. | | Redistributing: ospf 100 | If the routing protocol is sharing information with another routing protocol configured on the router, the information is listed here. This is a very important field because redistribution is complex and, therefore, easily misconfigured. If no redistribution is configured, the protocol is seen to be sharing information with itself. | | Routing for Networks: 140.100.0.0 | This reflects the use of the network commands when the protocol was configured. OSPF allows granularity in the use of the command. The entries here could be as specific as the interface addresses. | | Routing Information Sources | This is a major heading for the gateway fields, which are the addresses of the routers sending updates to this router. They will become the next logical hop in the routing table. | | Gateway | This field is a subset of the Routing Information Sources field just discussed. It is the address of the router providing updates. | | Distance | The administrative distance is the preference given to the source of the update. Whereas the metric indicates which path to choose if there is more than one available, the administrative distance indicates which source (routing protocol) to choose if there is more than one providing a path to a remote network. The administrative distance takes precedence over the routing metric. | | Last Update | This is the time since the last update was received from that source. | | Distance: (default is 110) | The administrative distance can be changed for the entire routing protocol (the example here is OSPF), which would be listed here, or it can be changed per source, as seen earlier in the listing of each individual source (gateway). | The show ip route Command This command shows the IP routing table on the router. It details how the network is known to the router and how the router discovered the route. This command is excellent for troubleshooting configuration errors and understanding how the network is communicating about its routes. It is given detailed consideration in Chapter 1, "IP Routing Principles." Router# show ip route The commands covered in this section are useful to verify that the configuration has worked and that the OSPF network is functioning correctly. In a single-area environment, the full complexity of OSPF is not engaged. The full strength and complexity of OSPF come to the forefront in the design and configuration of a multiarea network. Troubleshooting OSPF in a Single Area Troubleshooting an OSPF network requires the same skills of detection and critical thinking as those needed in any problem solving. Whether you are a doctor trying to locate the cause of a patient's pain or a network administrator investigating a corporate network's slow response time, the approach needs to be methodical and well-documented. The better your understanding of the subject, or patient, the easier it is to diagnose the problem. As a network administrator, this understanding will grow if you document not only your network, but also every change that is made to that network. Cisco provides many tools to aid the troubleshooting process. There are courses and many technical documents in addition to a forum for questions and answers. The following web pages provide some excellent troubleshooting tools, which will help in the everyday maintenance of your network and provide a good learning resource. Some of these resources might require you to be a registered user and to log in: -
A page of troubleshooting tools: http://www.cisco.com/public/support/tac/tools.shtml Because Cisco sometimes reorganizes its web pages, this reference might change. Luckily, Cisco maintains an excellent search engine. You should search for tools from the home page. -
A utility that allows the output of listed show commands and interprets the output: https ://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl -
A troubleshooting assistant that leads you through a series of screens to help diagnose a problem: http://www.cisco.com/kobayashi/support/tac/tsa/launch_tsa.html The debug Commands An excellent, though dangerous, troubleshooting tool is the debug command. The debug command has the highest process priority and is therefore capable of consuming all the resources on the router, thus becoming the problem as opposed to helping to solve the problem. It is important simply to turn on debug for the specific task to be monitored and to turn it off as soon as the data is gathered. The no form of this command disables debugging output. You would be wise to direct the output to a log file so that the data can be perused with care. The debug commands are EXEC commands. The options available for monitoring OSPF are listed in Table 7-11. Table 7-11. The debug Command Options for OSPF | Command Option | Description | | debug ip ospf events | Displays information about OSPF-related events, such as adjacencies, flooding information, designated router selection, and shortest path first (SPF) calculation. | | debug ip packet | IP debugging information includes packets received, generated, and forwarded. Fast-switched packets do not generate messages. | | 