Between the holidays and throwing my back out worse than I think I ever have had kept me from moving forward with subjects, but I am determined to get back to where I left off months before the summer by the New Year if life doesn’t happen again by then.
That being said, I am going to work on the U.U.U response from R4 to R5’s loopback of 5.5.5.5, which seemed to break once I made area 15 an NSSA Total Stub. U.U.U means an upstream router does not have a path back to the source of the ping, so I am going to look at route tables on R1 and R3, as these are the ABR’s to both R4 and R5 (Remember there is no longer a virtual-link now that they are stubs).
Here are the results from pinging from R5 to R4’s loopback of 4.4.4.4:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R5#ping 172.12.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R5#ping 172.12.123.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.123.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/64/68 ms
R5#ping 172.12.34.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.34.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/66/68 ms
R5#ping 172.12.34.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.12.34.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/64/68 ms
R5#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R5#
So what it is showing above is that it can ping everything over the WAN up to and including R4’s FastEthernet interface, but not it’s loopback. I’ve already checked R1’s OSPF route table, so now I am curious if R3 can ping 4.4.4.4, which I imagine it can because it is the default gateway that R4 will throw any traffic (including our ping traffic) back to:
R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA 1.1.1.1 [110/65] via 172.12.123.1, 00:23:01, Serial0/2
2.0.0.0/32 is subnetted, 1 subnets
O IA 2.2.2.2 [110/65] via 172.12.123.2, 00:23:01, Serial0/2
100.0.0.0/13 is subnetted, 1 subnets
O E1 100.0.0.0 [110/84] via 172.12.123.1, 00:23:01, Serial0/2
172.12.0.0/24 is subnetted, 3 subnets
O IA 172.12.15.0 [110/65] via 172.12.123.1, 00:23:01, Serial0/2
172.16.0.0/22 is subnetted, 1 subnets
O IA 172.16.8.0 [110/65] via 172.12.123.1, 00:23:01, Serial0/2
R3#
Not looking good, we no longer have a learned route to R5’s 5.5.5.5, so I tried to ping 4.4.4.4 from R3 to prove the idea it has to return traffic being the default gateway:
R3#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R3#
These two routers are directly connected via FastEthernet, but I cannot ping a logical interface on it, I don’t recall running into this before (so I must not have been checking my work). So it occurred to me that the issue may be lying in the fact that Areas configured on a non-Backbone router require a virtual-link for those area’s to be advertised to other neighbors. I removed the Total Stub configs on Area 34 and put back in place the Virtual-Link to see if I regain L3 connectivity or if both area’s need the virtual-link configured for their loopbacks to be advertised across the network.
One thing I bumped into that I found interesting was this:
R3(config-router)#no area 34 stub no-summary
R3(config-router)#area 34 virtual-link 4.4.4.4
% OSPF: Area 34 is a stub or nssa so virtual links are not allowed
R3(config-router)#
I even did “clear ip ospf proc” to make sure it wasn’t clinging to cached memory, but it just wasn’t happening. I then realized when I really looked at the syntax of the error message, it is saying that the area is configured as a stub, so I issued “no area 34 stub” on R3 and immediately the bells and whistles started going off:
R3(config-router)#no area 34 stub
R3(config-router)#area 34 virtual-link 4.4.4.4
R3(config-router)#
*Mar 1 13:54:43.500: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on FastEthernet0/1 from LOADING to FULL, Loading Done
R3(config-router)#
*Mar 1 13:55:05.384: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on OSPF_VL0 from LOADING to FULL, Loading Done
R3(config-router)#do ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R3(config-router)#
MUCH better, however the test will be pinging R5’s loopback of 5.5.5.5 from R4:
R4#ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R4#
Notta. So I will remove stub configs from Area 15 and give it a virtual-link to see if everything goes, along the way got some output I found interesting:
R1(config-router)#no area 15 stub
OSPF: Area is configured as NSSA already
R1(config-router)#
So the router won’t accept no area 15 stub, it wants the syntax and even tells you it wants that syntax correct.Once I removed the NSSA configurations from Area 15, a neighbor adjacency formed, however it is still not able to ping 5.5.5.5 and they are also two routers connected via FastEthernet.
So I wrestled with this for quite some time, as I took stub configs off and added virtual-links how I originally did, but since that original config I’ve added loopbacks that are numerically higher than 1.1.1.1. It took me seeing connections to drop and reform back to R1 several times and a few “sh ip ospf nei” to realize I had to make 172.16.11.1 the virtual-link’s remote RID as it will look for the highest loopback address in OSPF to form neighbor adjacencies (including virtual-links):
R5(config-router)#no area 15 virtual-link 1.1.1.1
R5(config-router)#area 15 virtual-link 172.16.11.1
R5(config-router)#
*Dec 28 00:58:43.767: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.11.1 on OSPF_VL1 from LOADING to FULL, Loading Done
R5(config-router)#
One thing this troubleshooting has taught is the commands “sh ip proto” and “sh ip ospf nei” will give you just about all the info you need when troubleshooting a router, however “sh ip ospf” will give you the whole ball of wax.
I am curious to see if static routes could be added to overcome this issue, but I am too mentally exhausted to push further and retain anything meaningful, so my next sit down I’d like to give some stub / static routing a try because no communication with a virtual-link just doesn’t seem right (but I am too drained to open that can of worms tonight). So next I’ll try making a single stub network, and see if I can statically route it, along with covering Authentication.
I am finding more and more unexpected behaviors each time I sit down to study, so it’s almost difficult to stay on track moving forward before I find the reason for these unexpected behaviors.
The DEVNET GRIND! 