Problem: OSPF Not Installing Any Routes in the Routing Table

This is also a common problem in OSPF to find routes in the database but not in the routing table. When OSPF finds any kind of discrepancy in the database, it does not install any routes in the routing table. This section assumes that the sender is advertising the routes in the database. If the sender is not advertising the routes, or if the route is not even present in the database, troubleshoot that problem first. This was discussed in the previous section, for troubleshooting when OSPF is not advertising routes.

The most common possible causes of this problem are as follows :

• The network type is mismatched.

• IP addresses are flipped in dual serial-connected routers or a subnet/mask mismatch has occurred.

• One side is a numbered and the other side is an unnumbered point-to-point link.

• A distribute list is blocking the routes' installation.

• There is a broken PVC in a fully meshed Frame Relay network with the broadcast network type.

Figure 9-66 shows a network setup that produces the OSPF route installation problem. The cloud in the middle is irrelevant. It could be Frame relay, PPP HDLC, or something else, but it must be a point-to-point WAN link in this scenario.

Figure 9-66. OSPF Network Setup Used to Produce Route Installation Problems

Example 9-183 shows that R2 is not installing any routes in the routing table.

Example 9-183 R2 Has No Routes in Its Routing Table

 R2#  show ip route ospf  R2# 

OSPF Not Installing Any Routes in the Routing Table ‚ Cause: Network Type Mismatch

A mismatched network type produces a discrepancy in the database, and OSPF will not install those routes in the routing table. This situation is common in NBMA networks in which one side has a point-to-point network type and the other side has a broadcast network type. This problem also occurs if one side is defined as a point-to-multipoint network and the other side is left as nonbroadcast.

In this example, one side is defined as broadcast and the other side is defined as point-to-point. When an interface network type is defined as broadcast, OSPF considers that link to be a transit link and puts that link in its router LSA as a transit link.

Figure 9-67 shows the flowchart to follow to solve this problem.

Figure 9-67. Problem-Resolution Flowchart

Debugs and Verification

Example 9-184 shows the interface configuration on both R1 and R2. The R1 serial interface network type is broadcast, while R2 uses the default network type, which is nonbroadcast.

Example 9-184 Network Types for R1 and R2

 R1#  interface Serial0   ip address 131.108.1.1 255.255.255.0    ip ospf network broadcast    !  _____________________________________________________________________________________ R2#  interface Serial0  ip address 131.108.1.2 255.255.255.0 

Example 9-185 shows the output of show ip ospf interface for the Serial 0 interface of both routers, which shows that there is a network type mismatch on both ends.

Example 9-185 Determining Whether R1 and R2 Have a Network Type Mismatch on the Serial 0 Interfaces

 R1#  show ip ospf interface serial 0  Serial0 is up, line protocol is up   Internet Address 131.108.1.1/24, Area 0   Process ID 20, Router ID 131.108.2.1,  Network Type BROADCAST  , Cost: 64   Transmit Delay is 1 sec, State DR, Priority 1   Designated Router (ID) 131.108.2.1, Interface address 131.108.1.1   Backup Designated router (ID) 131.108.2.2, Interface address 131.108.2.2   Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5     Hello due in 00:00:08   Neighbor Count is 1, Adjacent neighbor count is 1     Adjacent with neighbor 131.108.2.2  (Backup Designated Router)   Suppress hello for 0 neighbor(s) _____________________________________________________________________________________  R2#  show ip ospf interface serial 0  Serial0 is up, line protocol is up  Internet Address 131.108.1.2/24, Area 0   Process ID 20, Router ID 131.108.1.2,  Network Type POINT_TO_POINT  , Cost: 64  Transmit Delay is 1 sec, State POINT_TO_POINT,  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5    Hello due in 00:00:02  Neighbor Count is 1, Adjacent neighbor count is 1    Adjacent with neighbor 131.108.2.1  Suppress hello for 0 neighbor(s) 

Example 9-186 shows the output of router LSAs on each router. The router LSA is complaining that the advertising router is unreachable. This is why the routers are not installing routes in the routing table.

Example 9-186 LSAs for R1 and R2 Indicate That the Advertising Router Is Unreachable

 R1#  show ip ospf database router 131.108.1.2   Adv Router is not-reachable  LS age: 418    Options: (No TOS-capability, DC)    LS Type: Router Links    Link State ID: 131.108.1.2    Advertising Router: 131.108.1.2    LS Seq Number: 80000002    Checksum: 0xFA63    Length: 60     Number of Links: 3      Link connected to: another Router (point-to-point)      (Link ID) Neighboring Router ID: 131.108.2.1      (Link Data) Router Interface address: 131.108.1.2      Number of TOS metrics: 0      TOS 0 Metrics: 64      Link connected to: a Stub Network      (Link ID) Network/subnet number: 131.108.1.0      (Link Data) Network Mask: 255.255.255.0      Number of TOS metrics: 0      TOS 0 Metrics: 64      Link connected to: a Stub Network      (Link ID) Network/subnet number: 131.108.0.0      (Link Data) Network Mask: 255.255.255.0      Number of TOS metrics: 0      TOS 0 Metrics: 10 _____________________________________________________________________________________ R2#  show ip ospf database router 131.108.2.1   Adv Router is not-reachable  LS age: 357    Options: (No TOS-capability, DC)    LS Type: Router Links    Link State ID: 131.108.2.1    Advertising Router: 131.108.2.1    LS Seq Number: 8000000A    Checksum: 0xD4AA    Length: 48     Number of Links: 2       Link connected to: a Transit Network       (Link ID) Designated Router address: 131.108.1.1       (Link Data) Router Interface address: 131.108.1.1       Number of TOS metrics: 0       TOS 0 Metrics: 64      Link connected to: a Stub Network      (Link ID) Network/subnet number: 131.108.2.0      (Link Data) Network Mask: 255.255.255.0      Number of TOS metrics: 0      TOS 0 Metrics: 10 

Solution

In this example, one side of a link is shown as a point-to-point link in the database, and the other side of the same link is shown as a transit link. This creates a discrepancy in the database and the router will not install anything in the routing table.

To fix this problem, change the network type of R1 back to its default, which is point-to-point. Example 9-187 shows how to change the network type back to point-to-point on R1.

Example 9-187 Changing Network Type Back to Point-to-Point

 R1#  interface Serial0   ip address 131.108.1.1 255.255.255.0   no ip ospf network broadcast  

Example 9-188 shows the output of show ip ospf interface for the serial interface. It shows that the network type is point-to-point.

Example 9-188 Verifying That R1's Serial 0 Interface Is of Network Type Point-to-Point

 R1#  show ip ospf interface serial 0  Serial0 is up, line protocol is up  Internet Address 131.108.1.1/24, Area 0  Process ID 20, Router ID 131.108.2.1,  Network Type POINT_TO_POINT  , Cost: 64  Transmit Delay is 1 sec, State POINT_TO_POINT,  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5    Hello due in 00:00:02  Neighbor Count is 1, Adjacent neighbor count is 1    Adjacent with neighbor 131.108.1.2  Suppress hello for 0 neighbor(s) 

Example 9-189 shows that R2 starts installing OSPF routes in its routing table.

Example 9-189 Confirming That OSPF Routes Now Are Being Installed

 R2#  show ip route 131.108.3.0   Routing entry for 131.108.3.0/24   Known via "ospf 1", distance 130, metric 74, type intra area  Redistributing via ospf 1   Last update from 131.108.1.1 on Serial0, 01:39:09 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.2.1, 14:39:09 ago, via Serial0       Route metric is 64, traffic share count is 1 

OSPF Not Installing Any Routes in the Routing Table ‚ Cause: IP Addresses Are Flipped in Dual Serial-Connected Routers

The IP addressing on dual serial interfaces can cause this problem. OSPF forms a FULL adjacency because the neighbor is still reachable, but this creates a discrepancy in the OSPF database.

This also can happen when the wrong IP subnet or mask is assigned on one side. This creates a discrepancy in the OSPF database.

Figure 9-68 shows a network setup in which the addresses on the serial interfaces are flipped; for example, R1's Serial 0 address is 131.108.1.1/24. The other end of this interface goes into Serial 0 of R2, which has the 131.108.2.1/24 address defined under Serial 0. A similar thing can be observed with the Serial 1 interface. This obviously looks like the addresses are flipped.

Figure 9-68. OSPF Network in Which Router Serial Interface IP Addresses Are Flipped

Example 9-190 shows that R2 is not installing any routes in the routing table because of the discrepancy in the database.

Example 9-190 R2 Is Not Installing Any OSPF Routes in Its Routing Table

 R2#  show ip route ospf  R2# 

Figure 9-69 shows the flowchart to follow to solve this problem.

Figure 9-69. Problem-Resolution Flowchart

Debugs and Verification

Example 9-191 shows the output of show ip ospf neighbor, which shows that OSPF is forming FULL adjacency on both serial links. The address column shows that the neighbor address and interface do not match. For example, in Example 9-191, R2 has two neighbors. Because R2's Serial 0 address is in the range 131.108.2.0/24, as shown in Figure 9-68, the neighbor address on Serial 0 also should be in the same range, but it shows 131.108.1.1 as a neighbor on Serial 0.

Example 9-191 show ip ospf neighbor Command Output Indicates OSPF Adjacency Formation on R1's Serial Links

 R2#  show ip ospf neighbor  Neighbor ID    Pri   State        Dead Time   Address         Interface 131.108.2.1      1   FULL/  -     00:00:37  131.108.1.1     Serial0  131.108.2.1      1   FULL/  -     00:00:31  131.108.2.1     Serial1  

Solution

To fix this problem, assign the IP address on the correct corresponding interface. Either change R1's IP addresses on its serial links or change R2's IP addresses on its serial links. In this example, R2's serial links have been changed to match R1's. Serial 0 IP addresses and Serial 1 IP addresses have been swapped, as shown in Example 9-192.

Example 9-192 Changing IP Addresses on R2's Serial Links

 R2#  interface serial 0   no ip address    ip address 131.108.1.2 255.255.255.0    !   interface serial 1   no ip address   ip address 131.108.2.1 255.255.255.0  

Example 9-193 shows that after fixing this problem, R2 installs OSPF routes in its routing table.

Example 9-193 R2's Routing Table Indicates That the Problem Has Been Resolved

 R2#  show ip route 131.108.3.0   Routing entry for 131.108.3.0/24   Known via "ospf 1", distance 130, metric 74, type intra area  Redistributing via ospf 1   Last update from 131.108.1.1 on Serial0, 01:39:09 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.2.1, 14:39:09 ago, via Serial0       Route metric is 64, traffic share count is 1 R2# 

OSPF Not Installing Any Routes in the Routing Table ‚ Cause: One Side Is a Numbered and the Other Side Is an Unnumbered Point-to-Point Link

When OSPF creates a router LSA for point-to-point links, it adheres to the following rule to fill the Link ID and Link Data fields within the router LSA (see Table 9-1).

Table 9-1. Link ID and Link Data Values for OSPF Point-to-Point Numbered and Unnumbered Links

Type	Description	Link ID	Link Data
1	Point-to-point Numbered	Neighbor's router ID	Interface IP address
1	Point-to-point Unnumbered	Neighbor's router ID	MIB-II ifIndex value

Table 9-1 shows that the Link Data field for unnumbered point-to-point links should have an MIB-II ifIndex value. Because the link data value of the numbered interface does not match that of the unnumbered interface, this creates the discrepancy in the OSPF database.

Figure 9-70 shows a network setup in which the R1 serial link is unnumbered to a loopback interface, while the R2 serial link is numbered.

Figure 9-70. OSPF Network with a Serial Link Unnumbered to a Loopback Interface

Figure 9-71 shows the flowchart to follow to solve this problem.

Figure 9-71. Problem-Resolution Flowchart

Debugs and Verification

Example 9-194 shows the discrepancy in the OSPF database. R1's router LSA shows the MIB-II IfIndex value in the Link Data field for Serial 0, while R2's router LSA shows the router's serial interface address in the Link Data field.

Example 9-194 Checking the OSPF Database for a Discrepancy

 R2#  show ip ospf database router  OSPF Router with ID (131.108.1.2) (Process ID 1)                 Router Link States (Area 0)   Adv Router is not-reachable   LS age: 855   Options: (No TOS-capability, DC)   LS Type: Router Links   Link State ID: 131.108.1.1   Advertising Router: 131.108.1.1   LS Seq Number: 8000000D   Checksum: 0x55AD   Length: 60   Number of Links: 1     Link connected to: another Router (point-to-point)      (Link ID) Neighboring Router ID: 131.108.1.2  (Link Data) Router Interface address: 0.0.0.4  Number of TOS metrics: 0        TOS 0 Metrics: 64 _____________________________________________________________________________________ R1#  show ip ospf database router  OSPF Router with ID (131.108.1.1) (Process ID 1)                 Router Link States (Area 0)   Adv Router is not-reachable   LS age: 855   Options: (No TOS-capability, DC)   LS Type: Router Links   Link State ID: 131.108.1.2   Advertising Router: 131.108.1.2   LS Seq Number: 8000000D   Checksum: 0x55AD   Length: 60   Number of Links: 1     Link connected to: another Router (point-to-point)      (Link ID) Neighboring Router ID: 131.108.1.1  (Link Data) Router Interface address: 131.108.1.2  Number of TOS metrics: 0        TOS 0 Metrics: 64 

Example 9-195 shows the configuration on both R1 and R2, which shows that R1's serial interface is unnumbered to a loopback address, while R2's serial interface is numbered.

Example 9-195 Serial Interface Configurations for R1 and R2

 R1#  interface Loopback0   ip address 131.108.1.1 255.255.255.0   !   interface Serial0    ip unnumbered Loopback0    !   router ospf 1   network 131.108.0.0 0.0.255.255 area 0  _____________________________________________________________________________________ R2#  interface Serial0    ip address 131.108.1.2 255.255.255.0    !   router ospf 1  network 131.108.0.0 0.0.255.255 area 0 

Solution

To fix this problem, make sure that both sides are either a numbered point-to-point link or an unnumbered point-to-point link. Example 9-196 shows the new configuration that fixes this problem. In this example, R1's serial interface is assigned an IP address.

Example 9-196 Assigning an IP Address on R1's Serial 0 Interface, Which Was Unnumbered Before

 R1#  interface Serial0    ip address 131.108.1.1 255.255.255.0    !   router ospf 1   network 131.108.0.0 0.0.255.255 area 0  _____________________________________________________________________________________ R2#  interface Serial0    ip address 131.108.1.2 255.255.255.0    !   router ospf 1  network 131.108.0.0 0.0.255.255 area 0 

Example 9-197 shows that R2 installs routes in the routing table after this problem is fixed.

Example 9-197 Confirming OSPF Route Installation

 R2#  show ip route 131.108.3.0   Routing entry for 131.108.3.0/24   Known via "ospf 1", distance 130, metric 74, type intra area  Redistributing via ospf 1   Last update from 131.108.1.1 on Serial0, 01:39:09 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.2.1, 14:39:09 ago, via Serial0       Route metric is 64, traffic share count is 1 R2# 

OSPF Not Installing Any Routes in the Routing Table ‚ Cause: Distribute List Is Blocking the Route Installation

OSPF is a link-state protocol. When it forms an adjacency with any neighbor, it synchronizes its database with that neighbor. Because of its link-state nature, filtering in OSPF is not possible.

Configuring distribute-list in prevents OSPF routes from being installed in the routing table. This doesn't mean that the routes disappear from the OSPF database. It simply means that before OSPF installs the route into the routing table, it checks for the distribute list and installs only those networks that are permitted in the distribute list. However, it keeps the routes in the database.

Figure 9-72 shows a network setup in which OSPF is not installing any routes in the routing table. Specifically, Router 2 is not seeing any OSPF routes in its routing table.

Figure 9-72. OSPF Network That Produces Route Installation Problems

Figure 9-73 shows the flowchart to follow to solve this problem.

Figure 9-73. Problem-Resolution Flowchart

Debugs and Verification

Example 9-198 shows the configuration on R2, which shows that R2 has distribute-list in configured and is not installing any OSPF routes in the routing table. Access list 1, which is used in the distribute list, allows only the 10/8 and 20/8 networks to be installed in the routing table. The remaining networks are implicitly denied. Example 9-198 also shows that the 131.108.3.0 network is not in the routing table because it is denied by the distribute list.

Example 9-198 R2 Configuration with a Distribute List

 R2#  !   router ospf 1   network 131.108.0.0 0.0.255.255 area 0    distribute-list 1 in    !    access-list 1 permit 10.0.0.0     access-list 1 permit 20.0.0.0   R2#  show ip route 131.108.3.0  %Network not in table R2# 

Solution

If a network is in the database but not in the routing table, make sure that the network is permitted in the distribute list.

Example 9-199 shows the new configuration that fixes this problem. In this configuration, network 131.108.3.0 is permitted.

Example 9-199 Configuring R2's Distribute List to Permit the 131.108.3.0/24 Network

 R2#  !   router ospf 1   network 131.108.0.0 0.0.255.255 area 0    distribute-list 1 in    !    access-list 1 permit 10.0.0.0     access-list 1 permit 20.0.0.0    access-list 1 permit 131.108.3.0 0.0.0.255  

Example 9-200 shows that network 131.108.3.0/24 appears in the routing table after fixing the configuration on R2.

Example 9-200 Confirming That the 131.108.3.0 Route Is Installed

 R2#  show ip route 131.108.3.0   Routing entry for 131.108.3.0/24   Known via "ospf 1", distance 130, metric 74, type intra area  Redistributing via ospf 1   Last update from 131.108.1.1 on Serial0, 01:09:19 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.2.1, 14:39:09 ago, via Serial0       Route metric is 64, traffic share count is 1 R2# 

OSPF Not Installing Any Routes in the Routing Table ‚ Cause: Broken PVC in a Fully Meshed Frame Relay Network with Broadcast Network Type

The OSPF network type broadcast should never be defined on a medium that is not fully meshed. Sometimes, the medium is fully meshed but the Layer 2 connectivity is not stable. In that case, when Layer 2 is broken, it creates an inconsistency and the medium becomes non ‚ fully meshed again.

Figure 9-74 shows a network experiencing this problem. Before the PVC between R1 and R2 was broken, R2 was a DR and R3 was a BDR.

Figure 9-74. OSPF Network in Which a Broken PVC in a Fully Meshed Frame Relay Network with Broadcast Network Type Causes Problems

Example 9-201 shows that R1 is not installing any routes in the routing table.

Example 9-201 R1 Is Not Installing Any Routes

 R1#  show ip route ospf  R1# 

Figure 9-75 shows the flowchart to follow to solve this problem.

Figure 9-75. Problem-Resolution Flowchart

Debugs and Verification

Example 9-202 shows the configuration on R1, R2, and R3. The configuration shows that the network type is broadcast on all routers for the Frame Relay cloud.

Example 9-202 Confirming the Network Type on R1, R2, and R3

 R1#  !   interface Serial0.1 multipoint   ip address 131.108.0.1 255.255.255.0    ip ospf network broadcast   _____________________________________________________________________________________ R2#  !   interface Serial0.1 multipoint   ip address 131.108.0.2 255.255.255.0    ip ospf network broadcast   _____________________________________________________________________________________ R3#  !   interface Serial0.1 multipoint   ip address 131.108.0.3 255.255.255.0   ip ospf network broadcast  

Example 9-203 shows the output of show ip ospf neighbor on all three routers. The output on R1 shows that it considers R2 to be the DR. However, the actual DR is R3, as shown in Figure 9-74, because it has the highest router ID. Because the link between R1 and R3 is broken, R1 declares R2 to be the DR.

Example 9-203 Determining the Designated Router

 R1#  show ip ospf neighbor  Neighbor ID Pri State        Dead Time Address      Interface 131.108.2.1 1  FULL/DR  00:00:31  131.108.0.2  Serial0.1 _____________________________________________________________________________________ R2#show ip ospf neighbor Neighbor ID Pri State           Dead Time Address      Interface 131.108.1.1 1  FULL/DROTHER  00:00:34  131.108.0.1  Serial0.1 131.108.3.1 1  FULL/DR  00:00:33  131.108.0.3  Serial0.1 _____________________________________________________________________________________ R3#  show ip ospf neighbor  Neighbor ID Pri State        Dead Time Address      Interface 131.108.2.1 1  FULL/BDR  00:00:31  131.108.0.2  Serial0.1 

Example 9-204 shows the router LSA output on R1 displaying the router LSA for R1, R2, and R3. R1 still considers R2 the DR instead of R3. R1 shows that the Frame Relay link is a stub link because it couldn't find any network LSA generated by R2 in the database. This Frame Relay link is defined as a transit link in both R2 and R3's database. This creates a discrepancy in the OSPF database.

Example 9-204 OSPF Database on R1, R2, and R3 Shows Discrepancy

 R1#  show ip ospf database router  OSPF Router with ID (131.108.1.1) (Process ID 1)                  Router Link States (Area 0)    LS age: 148    Options: (No TOS-capability, DC)    LS Type: Router Links    Link State ID: 131.108.1.1  Advertising Router: 131.108.1.1  LS Seq Number: 8000000B    Checksum: 0x55A    Length: 48     Number of Links: 2  Link connected to: a Stub Network   (Link ID) Network/subnet number: 131.108.0.0   (Link Data) Network Mask: 255.255.255.0  Number of TOS metrics: 0      TOS 0 Metrics: 64      Link connected to: a Stub Network      (Link ID) Network/subnet number: 131.108.1.1      (Link Data) Network Mask: 255.255.255.255      Number of TOS metrics: 0      TOS 0 Metrics: 1    Adv Router is not-reachable    LS age: 1081    Options: (No TOS-capability, DC)    LS Type: Router Links    Link State ID: 131.108.2.1  Advertising Router: 131.108.2.1  LS Seq Number: 80000006    Checksum: 0x4F72    Length: 48     Number of Links: 2      Link connected to: a Stub Network      (Link ID) Network/subnet number: 131.108.2.1      (Link Data) Network Mask: 255.255.255.255      Number of TOS metrics: 0      TOS 0 Metrics: 1  Link connected to: a Transit Network   (Link ID) Designated Router address: 131.108.0.3   (Link Data) Router Interface address: 131.108.0.2  Number of TOS metrics: 0      TOS 0 Metrics: 64    Adv Router is not-reachable    LS age: 306    Options: (No TOS-capability, DC)    LS Type: Router Links    Link State ID: 131.108.3.1  Advertising Router: 131.108.3.1  LS Seq Number: 80000007    Checksum: 0xC185    Length: 48     Number of Links: 2      Link connected to: a Stub Network      (Link ID) Network/subnet number: 131.108.3.1      (Link Data) Network Mask: 255.255.255.255      Number of TOS metrics: 0      TOS 0 Metrics: 1  Link connected to: a Transit Network   (Link ID) Designated Router address: 131.108.0.3   (Link Data) Router Interface address: 131.108.0.3  Number of TOS metrics: 0      TOS 0 Metrics: 64 

Solution

The solution in this case is to run a point-to-multipoint network type. With a point-to-multipoint network type, the flooding increases because no DR/BDR elected. If there is any connectivity problem, however, it will not create any black holes.

So, a trade-off exists between reliability and increased flooding. Selecting a point-to-multipoint network type over unstable Frame Relay links provides reliability, while selecting a broadcast net-work type creates inconsistencies whenever any Layer 2 instability occurs.

Example 9-205 shows the new configuration changes on R1, R2, and R3. The network type is now point-to-multipoint.

Example 9-205 Configuring R1, R2, and R3 with Point-to-Multipoint Interfaces

 R1#  !   interface Serial0.1 multipoint   ip address 131.108.0.1 255.255.255.0    ip ospf network point-to-multipoint   _____________________________________________________________________________________ R2#  !   interface Serial0.1 multipoint   ip address 131.108.0.2 255.255.255.0    ip ospf network point-to-multipoint   _____________________________________________________________________________________ R3#  !   interface Serial0.1 multipoint   ip address 131.108.0.3 255.255.255.0   ip ospf network point-to-multipoint  

Example 9-206 shows that R1 starts learning OSPF routes from R2 after the configuration changes.

Example 9-206 Confirming That R1 Is Learning OSPF Routes from R2

 R1#  show ip route 131.108.3.0   Routing entry for 131.108.3.0/24   Known via "ospf 1", distance 130, metric 129, type intra area  Redistributing via ospf 1   Last update from 131.108.0.2 on Serial0.1, 00:00:19 ago   Routing Descriptor Blocks:   * 131.108.0.2, from 131.108.3.1, 14:39:09 ago, via Serial0.1       Route metric is 64, traffic share count is 1 R1#