I'll leave it to you to spot the problem with the VL, and why it's not reaching Full :)

Incidentally, if configure a virtual link on one side, but not the other, then the side you do have it configured on will show the VL status as "down" in "show ip ospf interface ospf brief".R2#sh ip ospf virVirtual Link OSPF_VL1 to router 3.3.3.3 is down Run as demand circuit DoNotAge LSA allowed. Transit area 23, Cost of using 65535 Transmit Delay is 1 sec, State DOWN, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

So if you follow the logic here I think we can draw a couple conclusions.

The neighbourship status is completely independent of the VL virtual interface.

The virtual link is considered "Up" as soon as the two sides are both sending Hellos to each other over the virtual link. Or put another way, the VL interface is considered "Up" when the neighbourship reaches 2-Way.

The command to verify the state of the VL virtual interface is different than the command to verify that you actually have a functional, Full state neighbourship over a virtual link established.

3 comments:

This is something I ran into a while back. It's a perfect scenario to trip people up on :) I like to use show ip ospf traffic to look at what kind of errors I'm seeing like mismatch in authentication etc.

I've not really used 'sh ip ospf vir' very much in the past. I've tended to rely on 'sh ip ospf nei' instead, and then debugging events when it's not coming up. I guess this shows my method has some advantages... Though there is still some good info to be found here.

Yeah, I got caught out on this with a Cisco 360 lab once. Classic thing is to get students to configure a VL, then later add a requirement to configure authentication on area 0, using a router command.