my topology along with IP and config:
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:
And here's what it normally looks like on router1:
But when you shut the gig 0/0 interface on router0, the ospf database reduces to this:
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:
On router0, his route table has been reduced, also, which is why the pings and traceroutes fail:
So, on router0, we do a
clear ip ospf process
and typeyes
. What we then see in the ospf database is: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:
However, the route table on router1 is still messed up:
So we do a
clear ip ospf process
and typeyes
on router1. And then the PC is able to traceroute over the serial links: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.