Cisco – OSPF doesn’t work when one interface is shutdown

ciscoospfpacket-tracerrouter

my topology along with IP and config:
SS topology

What I do:

A. Normal tracert.

With everything on/no shutdown, I do tracert from PC0|192.168.1.2 to PC1|172.16.1.2:

C:\>tracert 172.16.1.2

Tracing route to 172.16.1.2 over a maximum of 30 hops: 

  1   0 ms      0 ms      0 ms      192.168.1.1
  2   0 ms      0 ms      0 ms      10.10.10.2
  3   1 ms      1 ms      0 ms      172.16.1.2

Trace complete.

It's okay.

B. Shutdown g0/0 in router0, and do tracert.

Shutdown interface g0/0:

router0>en
router0#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
router0(config)#int g0/0
router0(config-if)#shut

router0(config-if)#
%LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down

%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down

02:40:32: %OSPF-5-ADJCHG: Process 10, Nbr 172.16.1.1 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

router0(config-if)#

tracert from PC0|192.168.1.2 to PC1|172.16.1.2:

C:\>tracert 172.16.1.2

Tracing route to 172.16.1.2 over a maximum of 30 hops: 

  1   0 ms      0 ms      0 ms      192.168.1.1
  2   0 ms      *         0 ms      192.168.1.1
  3   *         0 ms      *         Request timed out.
  4   0 ms      *         0 ms      192.168.1.1
  5   *         3 ms      *         Request timed out.
  6   0 ms      *         0 ms      192.168.1.1
  7   *         0 ms      *         Request timed out.
  8   0 ms      *         0 ms      192.168.1.1
  9   *         0 ms      *         Request timed out.
  10   0 ms      *         0 ms      192.168.1.1
Control-C
^C

It fails no matter how long I wait.

C. Turn on g0/0 in router0 again, and do tracert.

Turn on g0/0:

router0(config-if)#no shut

router0(config-if)#
%LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to up

%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up

router0(config-if)#

tracert from PC0|192.168.1.2 to PC1|172.16.1.2:

C:\>tracert 172.16.1.2

Tracing route to 172.16.1.2 over a maximum of 30 hops: 

  1   1 ms      0 ms      0 ms      192.168.1.1
  2   1 ms      0 ms      32 ms     10.10.11.2
  3   1 ms      1 ms      3 ms      10.10.12.1
  4   2 ms      1 ms      1 ms      172.16.1.2

Trace complete.

It finally changes the route to 10.10.11.2 and 10.10.12.1

after a while in router0 appear text:

02:53:30: %OSPF-5-ADJCHG: Process 10, Nbr 172.16.1.1 on GigabitEthernet0/0 from LOADING to FULL, Loading Done

So when I do tracert again, it backs to the original route:

C:\>tracert 172.16.1.2

Tracing route to 172.16.1.2 over a maximum of 30 hops: 

  1   8 ms      0 ms      0 ms      192.168.1.1
  2   1 ms      0 ms      1 ms      10.10.10.2
  3   0 ms      0 ms      13 ms     172.16.1.2

Trace complete.

Is it supposed to be normal?

How can I make PC0 can ping/tracert to PC1 when the g0/0 in router0 state is shutdown?

Edit:

in case you need to see the config & pkt files

router0 config:

!
version 15.1
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname router0
!
!
!
!
!
!
!
!
no ip cef
no ipv6 cef
!
!
!
!
license udi pid CISCO1941/K9 sn FTX15244356
!
!
!
!
!
!
!
!
!
!
!
spanning-tree mode pvst
!
!
!
!
!
!
interface GigabitEthernet0/0
 ip address 10.10.10.1 255.255.255.0
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0/0
 ip address 10.10.11.1 255.255.255.0
!
interface Serial0/0/1
 no ip address
 clock rate 2000000
 shutdown
!
interface Vlan1
 no ip address
 shutdown
!
router ospf 10
 log-adjacency-changes
 network 10.10.10.0 0.0.0.255 area 0
 network 10.10.11.0 0.0.0.255 area 0
 network 192.168.1.0 0.0.0.255 area 0
!
router ospf 1
 log-adjacency-changes
!
ip classless
!
ip flow-export version 9
!
!
!
!
!
!
!
line con 0
!
line aux 0
!
line vty 0 4
 login
!
!
!
end

router1 config:

!
version 15.1
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname router1
!
!
!
!
!
!
!
!
no ip cef
no ipv6 cef
!
!
!
!
license udi pid CISCO1941/K9 sn FTX15243RGR
!
!
!
!
!
!
!
!
!
!
!
spanning-tree mode pvst
!
!
!
!
!
!
interface GigabitEthernet0/0
 ip address 10.10.10.2 255.255.255.0
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 ip address 172.16.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0/0
 no ip address
 clock rate 2000000
 shutdown
!
interface Serial0/0/1
 ip address 10.10.12.1 255.255.255.0
 clock rate 64000
!
interface Vlan1
 no ip address
 shutdown
!
router ospf 10
 log-adjacency-changes
 network 10.10.12.0 0.0.0.255 area 0
 network 10.10.10.0 0.0.0.255 area 0
 network 172.16.1.0 0.0.0.255 area 0
!
ip classless
!
ip flow-export version 9
!
!
!
!
!
!
!
line con 0
!
line aux 0
!
line vty 0 4
 login
!
!
!
end

router2 config:

!
version 15.1
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname router2
!
!
!
!
!
!
!
!
no ip cef
no ipv6 cef
!
!
!
!
license udi pid CISCO1941/K9 sn FTX15249JA2
!
!
!
!
!
!
!
!
!
!
!
spanning-tree mode pvst
!
!
!
!
!
!
interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
 shutdown
!
interface GigabitEthernet0/1
 no ip address
 duplex auto
 speed auto
 shutdown
!
interface Serial0/0/0
 ip address 10.10.11.2 255.255.255.0
 clock rate 64000
!
interface Serial0/0/1
 ip address 10.10.12.2 255.255.255.0
!
interface Vlan1
 no ip address
 shutdown
!
router ospf 10
 log-adjacency-changes
 network 10.10.12.0 0.0.0.255 area 0
 network 10.10.11.0 0.0.0.255 area 0
!
ip classless
!
ip flow-export version 9
!
!
!
!
!
!
!
line con 0
!
line aux 0
!
line vty 0 4
 login
!
!
!
end

Best Answer

TLDR: I think this is a PacketTracer bug. It works on real routers.

I loaded this into PacketTracer and played around with it. Here's what the ospf database normally looks like on router0:

router0#sho ip ospf database
            OSPF Router with ID (192.168.1.1) (Process ID 10)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.10.12.2      10.10.12.2      568         0x80000005 0x00dc56 4
192.168.1.1     192.168.1.1     34          0x8000000d 0x00feb9 4
172.16.1.1      172.16.1.1      34          0x8000000e 0x00bdfc 4

                Net Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      192.168.1.1     34          0x80000003 0x0007d0
router0#

And here's what it normally looks like on router1:

router1#sho ip ospf database
            OSPF Router with ID (172.16.1.1) (Process ID 10)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.10.12.2      10.10.12.2      564         0x80000005 0x00dc56 4
172.16.1.1      172.16.1.1      30          0x8000000e 0x00bdfc 4
192.168.1.1     192.168.1.1     30          0x8000000d 0x00feb9 4

                Net Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum
10.10.10.1      192.168.1.1     30          0x80000003 0x0007d0
router1#

But when you shut the gig 0/0 interface on router0, the ospf database reduces to this:

router0#sho ip ospf database
            OSPF Router with ID (192.168.1.1) (Process ID 10)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.10.12.2      10.10.12.2      622         0x80000005 0x00dc56 4
172.16.1.1      172.16.1.1      6           0x8000000f 0x009b6d 3
router0#

Notice that there are only two router LSAs, that is LSAs of type 1. And the one that is missing is router0 himself!

The same is true on router1:

router1#sho ip ospf database
            OSPF Router with ID (172.16.1.1) (Process ID 10)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.10.12.2      10.10.12.2      643         0x80000005 0x00dc56 4
192.168.1.1     192.168.1.1     26          0x8000000e 0x000ff6 3
router1#

On router0, his route table has been reduced, also, which is why the pings and traceroutes fail:

router0#sho ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.10.11.0/24 is directly connected, Serial0/0/0
L       10.10.11.1/32 is directly connected, Serial0/0/0
     192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.1.0/24 is directly connected, GigabitEthernet0/1
L       192.168.1.1/32 is directly connected, GigabitEthernet0/1

router0#

So, on router0, we do a clear ip ospf process and type yes. What we then see in the ospf database is:

router0#sho ip ospf database
            OSPF Router with ID (192.168.1.1) (Process ID 10)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.10.12.2      10.10.12.2      689         0x80000005 0x00dc56 4
172.16.1.1      172.16.1.1      73          0x8000000f 0x009b6d 3
192.168.1.1     192.168.1.1     15          0x80000010 0x000bf8 3
router0#

That looks much better (himself shows up now), and we didn't change anything besides clearing the ospf database! And now the route table looks better, as well:

router0#sho ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C       10.10.11.0/24 is directly connected, Serial0/0/0
L       10.10.11.1/32 is directly connected, Serial0/0/0
O       10.10.12.0/24 [110/128] via 10.10.11.2, 00:00:34, Serial0/0/0
     172.16.0.0/24 is subnetted, 1 subnets
O       172.16.1.0/24 [110/129] via 10.10.11.2, 00:00:34, Serial0/0/0
     192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.1.0/24 is directly connected, GigabitEthernet0/1
L       192.168.1.1/32 is directly connected, GigabitEthernet0/1

router0#

However, the route table on router1 is still messed up:

router1#sho ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.10.12.0/24 is directly connected, Serial0/0/1
L       10.10.12.1/32 is directly connected, Serial0/0/1
     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.16.1.0/24 is directly connected, GigabitEthernet0/1
L       172.16.1.1/32 is directly connected, GigabitEthernet0/1

router1#

So we do a clear ip ospf process and type yes on router1. And then the PC is able to traceroute over the serial links:

C:\>tracert 172.16.1.2

Tracing route to 172.16.1.2 over a maximum of 30 hops:

  1   1 ms      0 ms      0 ms      192.168.1.1
  2   3 ms      3 ms      10 ms     10.10.11.2
  3   0 ms      1 ms      1 ms      10.10.12.1
  4   1 ms      0 ms      1 ms      172.16.1.2

Trace complete.

C:\>

I noticed that if you no shut the gig 0/0 link on router0 and repeat this whole thing, it reproduces exactly over and over. Crazy.

As a final note, I tested this on real Cisco routers with the same types of connections (ethernet and serial links), and this problem did NOT happen; everything worked as you would expect it to.

Related Topic