R2#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 3.3.3.3 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 23, via interface Serial0/0/0, Cost of using 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:06
Message digest authentication enabled
Youngest key id is 1
But is it up? The answer is yes, but nothing is working right now :)
So it would seem that this little command is slightly misleading. Let's look a little deeper shall we?
R2#sh ip ospf int brie | i Nbrs|VL
Interface PID Area IP Address/Mask Cost State Nbrs F/C
VL0 1 0 10.0.23.2/24 64 P2P 0/0
The part that we're really interested is right on the end there. Zero neighbours. None.
Here's the relevant configs on both routers to show what I have going on.
R2#sh run | s router ospf
router ospf 1
log-adjacency-changes
area 0 authentication message-digest
area 23 virtual-link 3.3.3.3 message-digest-key 1 md5 blah
network 10.0.12.2 0.0.0.0 area 0
network 10.0.23.2 0.0.0.0 area 23
R3#sh run | s router ospf
router ospf 1
log-adjacency-changes
area 23 virtual-link 2.2.2.2
network 10.0.23.3 0.0.0.0 area 23
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 vir
Virtual 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.
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.
ReplyDeleteI'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.
DeleteYeah, 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.
ReplyDeleteHmm, why aren't my changes propagating? But the virtual link is still up - what's happening? Argh.
That's the other one Narbik told me - if you're making those changes, but the link is up, try forcing a topology change (e.g. shut/no shut an interface), and see if the neighbor relationship stays up.