From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Thu Dec 29 2005 - 17:43:40 GMT-3
Dennis,
You can do a "show ip ospf virtual-links" on each side to verify
the configuration and adjacency. But as you know the real problem is
that the virtual-link is run as a demand circuit (see below) so any
changes made on one side (authentication type, authentication password,
etc) will not truly take effect until there are updates to send across
the virtual-link or the OSPF process is restarted.
Rack1R1#show ip ospf virtual-links | include (Virtual|demand)
Virtual Link OSPF_VL0 to router 150.1.3.3 is up
Run as demand circuit
Rack1R1#
I recommend to my students in class to always clear the OSPF
process and make sure the virtual-link comes back up after making
changes to the virtual-link's configuration. This way you can be sure
the virtual-link is working as expected and the changes have taken
effect.
You can also use the "debug ip ospf adjacency" command in newer
IOS versions to debug an adjacency issue with the virtual-link. The
debug command has been around for a while but in previous versions the
virtual-link's adjacency would never seem to produce any output.
Here is a demonstration of the problem for the benefit of the
people who aren't familiar with this issue.
R1 and R3 have area 0 configured on their loopback interfaces. Area 1
is configured on the serial link between R1 and R3.
Rack1R1#show run | be router ospf
router ospf 1
router-id 150.1.1.1
log-adjacency-changes
area 1 virtual-link 150.1.3.3
network 155.1.1.1 0.0.0.0 area 0
network 155.1.0.0 0.0.255.255 area 1
Rack1R1#show ip ospf virtual-links | include Adjacency State
Adjacency State FULL (Hello suppressed)
Rack1R1#
Rack1R3#show run | be router ospf
router ospf 1
router-id 150.1.3.3
log-adjacency-changes
area 1 virtual-link 150.1.1.1
network 150.1.3.3 0.0.0.0 area 0
network 155.1.0.0 0.0.255.255 area 1
Rack1R3#show ip ospf virtual-links | include Adjacency State
Adjacency State FULL (Hello suppressed)
Rack1R3#
As we can see the configuration is working and the adjacency
state is full. We'll now change the authentication type for area 0 from
null to type 1 (aka plain text or simple authentication) on R3 only.
R1's authentication type will be left to the default of null. For
routers to become neighbors with OSPF the authentication type must
match.
Rack1R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R3(config)#router ospf 1
Rack1R3(config-router)#area 0 authentication
Rack1R3(config-router)#^Z
Rack1R3#
Rack1R3#sho ip ospf virtual-links
Virtual Link OSPF_VL0 to router 150.1.1.1 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 1, via interface Serial1/2, Cost of using 781
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:03
Adjacency State FULL (Hello suppressed)
Index 1/2, retransmission queue length 0, number of retransmission 1
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 1, maximum is 1
Last retransmission scan time is 0 msec, maximum is 0 msec
Simple password authentication enabled
Rack1R3#
Rack1R3#show ip ospf virtual-links | include Adjacency State
Adjacency State FULL (Hello suppressed)
Rack1R3#
At this point R1 and R3 are not aware of the authentication type
mismatch because of the fact the virtual-link is a demand circuit and no
periodic hellos are exchanged. Because of this demand-circuit, only
when updates are sent, the neighbor relationship is torn down, or the
OSPF process is restarted will the routers discover the authentication
type mismatch. The reason this isn't a problem with routers on say an
Ethernet segment, is because of the periodic hellos that are sent by the
routers. By sending the periodic hellos the routers will discover the
authentication type mismatch and tear down the neighbor relationship
automatically.
Now by shutting down R3's loopback interface, R3 will have to
send an update to R1 about the loopback's state changing to down. At
this point R1 and R3 will discover the problem with the virtual-link as
seen in the last output from the debug below. We could have also just
cleared the OSPF process on one of the routers or did a shut/no shut the
serial link to restart the neighbor relationship.
Rack1R3#debug ip ospf adj
OSPF adjacency events debugging is on
Rack1R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R3(config)#int lo 0
Rack1R3(config-if)#shut
Rack1R3(config-if)#^Z
Rack1R3#
*Apr 24 17:05:44.784: OSPF: Interface Loopback0 going Down
*Apr 24 17:05:44.784: OSPF: 150.1.3.3 address 150.1.3.3 on Loopback0 is
dead, state DOWN
*Apr 24 17:05:45.260: %SYS-5-CONFIG_I: Configured from console by
console
Rack1R3#
*Apr 24 17:05:45.284: OSPF: Build router LSA for area 0, router ID
150.1.3.3, seq 0x80000003
Rack1R3#
*Apr 24 17:05:46.780: %LINK-5-CHANGED: Interface Loopback0, changed
state to administratively down
*Apr 24 17:05:47.780: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Loopback0, changed state to down
Rack1R3#
*Apr 24 17:05:52.360: OSPF: Rcv pkt from 155.1.13.1, OSPF_VL0 : Mismatch
Authentication type. Input packet specified type 0, we use type 1
Rack1R3#
HTH,
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Dennis J. Hartmann
Sent: Thursday, December 29, 2005 11:37 AM
To: ccielab@groupstudy.com
Subject: OSPF Virtual Link & Authentication Verification Command
Does anyone remember the command and verification procedure to
ensure
that a virtual-link is using the authentication password?
I've had scenarios where my virtual-links were up, but improperly
because the authentication was not configured correctly. Please advise.
Thanks.
Sincerely,
Dennis J. Hartmann
White Pine Communications
dh8@pobox.com
CCSI#23402 / CCVP / CCIP / CCNP
Cisco Optical, VPN & IDS Specialist
MCSE
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:52 GMT-3