OSPF Virtual Links

• Virtual Links:
  • Allows discontiguous area 0s to be connected.
  • Allows a disconnected area to connect to a backbone area via a transit area.
    • The transit area (the area through which the virtual link is configured) must have full routing information.
    • The transit area also cannot be a stub area.
  • The Hello protocol works over virtual links just like it does with standard links – in 10 second intervals.
  • LSAs, however, do not refresh every 30 minutes like a standard link.
    • LSAs learned through a virtual link have the DoNotAge (DNA) option set. This prevents the LSA from aging out. This is required to prevent excessive flooding over the virtual link.
• Congfiguration – use the following router configuration command:

area area-id virtual-link router-id [authentication [message-digest | null]] [hello-interval seconds] [retransmit-interval seconds] [transmit-delay seconds] [dead-interval seconds] [[authentication-key key] | [message-digest-key key-id md5 key]]

• The parameters are:

• The area area-id virtual-link command requires ther router ID of the far-end router. Several commands can be used to find the router ID
  • sh ip ospf
  • sh ip ospf interface
  • sh ip protocol

Example

Figure 1: Virtual Link Example Topology

R1 Configuration

R1(config)#int loopback 1
R1(config-if)#ip address 1.1.1.1 255.0.0.0
!
R1(config-if)#int fa0/0
R1(config-if)#ip address 4.0.0.1 255.0.0.0
R1(config-if)#no shut
R1(config-if)#no keepalive*
!
R1(config-if)#int s1/0
R1(config-if)#ip address 10.10.10.1 255.255.255.0
R1(config-if)#no shut
!
R1(config-if)#router ospf 100
R1(config-router)#network 4.0.0.0 0.255.255.255 area 0
R1(config-router)#network 10.10.10.0 0.0.0.255 area 1
R1(config-router)#area 1 virtual-link 3.3.3.3

!

*The no keepalive command seems to fool dynamips into thinking that there is a device on the other end of this router’s fa0/0 interface. The result is an up/up interface instead of up/down that I kept getting before inserting that command.

R2 Configuration

R2(config)#int loopback 1
R2(config-if)#ip address 2.2.2.2 255.0.0.0
!
R2(config-if)#int s1/0
R2(config-if)#ip address 10.10.10.2 255.255.255.0
R2(config-if)#no shut
!
R2(config-if)#int s1/1
R2(config-if)#ip address 192.168.1.2 255.255.255.0
R2(config-if)#no shut
!
R2(config-if)#router ospf 100
R2(config-router)#network 192.168.1.0 0.0.0.255 area 1
R2(config-router)#network 10.10.10.0 0.0.0.255 area 1

R3 Configuration

R3(config)#int loopback 1
R3(config-if)#ip address 3.3.3.3 255.0.0.0
!
R3(config-if)#int fa0/0
R3(config-if)#ip address 5.0.0.1 255.0.0.0
R3(config-if)#no shut
R3(config-if)#no keepalive*
!
R3(config-if)#int s1/0
R3(config-if)#ip address 192.168.1.1 255.255.255.0
R3(config-if)#no shut
!
R3(config-if)#router ospf 100
R3(config-router)#network 5.0.0.0 0.255.255.255 area 2
R3(config-router)#network 192.168.1.0 0.0.0.255 area 1
R3(config-router)#area 1 virtual-link 1.1.1.1

• The OSPF router ID is the highest IP address on the router, and if present, the highest loopback address. Notice that I configured loopback addresses for each of the routers. To make it easy to identify, I chose to use the loopback address based on the router name (ie R1 = 1.1.1.1 and so forth)
• Router IDs are calculated at boot time or when OSPF process is started. Therefore don’t be alarmed if you configure an interface IP address and configure a loopback address later and find that the router ID is doesn’t reflect the loopback address. Usually, a reload of the router will fix this. In this exercise, I tried clear ip ospf process but that didn’t fix it. A reload did.

• For anyone interested, here’s the basic dynamips .net configuration for the lab exercises discussed here:

[localhost]

[[7200]]
image = \Program Files\Dynamips\images\C7200-JK.BIN
# On Linux / Unix use forward slashes:
# image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
npe = npe-400
ram = 96

#

#

[[Router R1]]
model = 7200
console = 2001
S1/0 = R2 s1/0

#

#

[[ROUTER R2]]
model = 7200
console = 2002
s1/1 = R3 s1/0

#

#

[[ROUTER R3]]
model = 7200
console = 2003

Verifying OSPF Virtual-Link Operation

Figure 2: sh ip ospf virtual-links Command

• The parameters show:
  • Virtual Link OSPF_VL0 to router 3.3.3.3 is up specifying that the link to neighbor 3.3.3.3 is up.
  • Transit area 1 – specifies that the virtual link is formed through transit area 1.
  • via interface serial1/0 – the virtual link is formed through this interface.
  • Cost of using 128 – this is the cost associated with reaching the neighbor through the virtual link.
  • Transmit Delay is 1 sec – which shows that the estimated time it takes to transmit a link state update (LSU) packet on the virtual link.
  • State POINT_TO-POINT – OSPF classifies a virtual link as a network type. Within each ABR, the virtual link will transition to the fully functional point-to-point interface state when a route to the neighboring ABR is found in the routing table.
  • Adjacency State FULL (Hello suppressed) – tells us that the state between the two neighbors is full.
    
    • The output shows that OSPF hellos are suppressed. This means that, once the virtual link is up, no hellos are exchanged. OSPF suppresses the hellos because it considers virtual links to be demand circuits. Normally, OSPF sends hellos every 10 seconds and refreshes its LSAs every 30 minutes. However, even this amount of traffic is undesirable on demand circuits. The use of OSPF demand circuit options suppresses hello and LSA-refresh functions. As a result, any changes that you make to the OSPF authentication do not take effect until you clear the OSPF process with the clear ip ospf process command.

Figure 3: sh ip ospf neighbor Command

• Be aware that the sh ip ospf neighbor command does not display adjacencies over virtual links. The one clue about the existence of the virtual link is the presence of the OSPF_VL0 interface.
  • To display adjacency over virtual links, use the sh ip ospf virtual-links command.

Figure 4: sh ip ospf database Command

• Note int the output that any of the LSAs learned from a virtual link have the DoNotAge (DNA) option.
  • *I haven’t quite yet understood why DNA is set. But my theory is, because OSPF considers virtual circuits as demand circuits and Hellos are suppressed, the LSA is told not to age, in other words, the LSA will not reach MaxAge. I’m guessing here.

Figure 5: sh ip ospf database router Command

• Breaking down the ouput under the “Router Link States (Area 0)” heading:
  • In the Options field:
    • No TOS-capability
    • DC means it is capable of supporting OSPF over demand circuits.
  • LS Type: Router Links - it is a Type 1 LSA.
  • Link State ID: 1.1.1.1 - for router links, Link State ID is always the same as the Advertising Router
  • Advertising Router: 1.1.1.1 – this is the router ID of the router that created the LSA
  • Area Border Router – in the router LSA, this is indicated as Bit B.
  • Link connected to: a Stub Network – refers to the network on the LAN interface.
  • Link connected to: a Virtual Link - refers to the connection to the Virtual link.
    • It is followed by the router ID of the neighbor on the other end of the virtual link [(Link ID) Neighboring Router ID: 3.3.3.3]

OSPF Authentication

• When authentication is configured on a router, the router authenticates the source of each routing update packet that it receives.
• There are three different types of OSPF authentication (shown in the following with their type codes):
  • Null (Type 0)
    
    • This is the default setting, which means the routing updates are not authenticated.
  • Simple (Type 1)
    • A password is used but it is sent in clear text over the network.
  • MD5 (Type 2)
    • With MD5 authentication, the password does not pass over the network. MD5 is a message-digest algorithm specified in RFC 1321. MD5 is considered the most secure OSPF authentication mode.
    • OSPF MD5 authentication includes a nondecreasing sequence number in each OSPF packet to protect against replay attacks.
      
• When configuring authentication, the whole area must use the same type of authentication.

Configure Simple Password Authentication

• To configure simple authentication follow a two step process:
  1. Use the following interface configuration command to assign a password:

     ip ospf authentication key password.

     • The password parameter is any string of characters up to 8 bytes in length (= 8 charatcters).
     • This password is used as the “key” which is inserted into an OSPF header when the Cisco IOS software originates the routing protocol packets.
     • A separate password can be assigned to each network on a per-interface basis.Plain text authentication passwords do not have to be the same throughout an area, but they must be the same between neighbors.
  2. Specify authentication type using the following interface configuration command.

     ip ospf authentication [message-digest | null]

  • • For simple password authentication, use the ip ospf authentication command with no parameters.
    • message-digest – Optional parameter that specifies MD5 authentication will be used
    • null – Optional parameter that specifies no authentication is to be used. This is useful for overriding simple password or MD5 authentication if configured for an area.

• For backward compatibility, an authentication type for an area is supported – as opposed to authentication type for an interface, which is described above.
  • In other words, as an alternative to using ip ospf authentication command on a interface, you may use a router command to configure authentication on an OSPF area.
  • The following router configuration command is used for configuring authentication on an area:

area area-id authentication [message-digest]

• The parameters used are:
  • area-id - identifies the area on which authentication is applied. Can be either a decimal or dotted decimal value.
  • message-digest – An optional parameter that enables the MD5 authentication.

Example Simple Password Authentication

Figure 6: Example Simple Password Authentication

R1 Configuration:

Router R1:
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
!
interface Serial1/0
ip address 192.168.1.1 255.255.255.0
ip ospf authentication
ip ospf authentication-key pa$$word
!
!
router ospf 100
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0

R2 Configuration

Router R2:
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
!
!
interface Serial1/1
ip address 192.168.1.2 255.255.255.0
ip ospf authentication
ip ospf authentication-key pa$$word
!
!
router ospf 100
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0

• Here’s a simple .net configuration of the above topology for anyone who wants to lab it up on dynamips:

[localhost]

#
[[7200]]
image = \Program Files\Dynamips\images\C7200-JK.BIN
# On Linux / Unix use forward slashes:
# image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
npe = npe-400
ram = 96

#
[[ROUTER R1]]
s1/0 = R2 s1/1
model = 7200
console = 2001
#

[[ROUTER R2]]
model = 7200
console = 2002

Figure 7: Verifying Simple Password Authentication

• sh ip ospf neighbor command output displays FULL ospf adjacency relationship.
• The routing table shows that the 2.2.2.2 network route has been learned.
• The ping of the 2.2.2.2 network was successful.

Figure 8A & 8B: Troubleshooting Simple Password Authentication

• Use debug ip opsf adj
• This error shows that one router is using type 1 authentication while the other does not have authentication configured

• Use debug ip ospf adj
• This output is a result of Type 1 (simple password) authentication configured on both routers but the passwords do not match.

Configure MD5 Authentication

• Use the following two step configuration to enable Md5 authentication:
  1. Use the following interface configuration command to assign a key and key id:

     ip ospf message-digest-key key-id md5 key.

     • key-id is an identifier in the range of 1 to 255.
     • key is an alphanumeric password of up to 16 bytes (16 characters).
  2. Specify authentication type using the following interface configuration command:

     ip ospf authentication message-digest

     • Just like the simple password authentication, the MD5 authentication for an area is also supported using the area area-id authentication message-digest router configuration command, for backward compatibility.

• The key and key-id parameters used in the MD5 authentication configuration are used to generate a message digest (called a hash) for each OSPF packet. The message digest is appended to the packet – not the password.
• All neighboring routers on the same network must have the same password.
  • In other words: the same key-id on the neighbor router must have the same key value.
• A practical use for having multiply key-id setup is when changing keys (or passwords).
  • For example, consider a router with the following interface configuration:
    • ip ospf message-digest-key 100 md5 OLD
  • You can add the following on the same interface:
    • ip ospf message-digest-key 200 md5 NEW
  • By doing this the router sends multiple copies of the same packet, each one authenticated by the different keys.
    • One packet is sent and authenticated by key 100
    • A second, identical packet is sent and authenticated by key 200
  • This type of rollover process allows neighboring routers to continue communicating while the network administrator updates the routers with a new key.
  • When the new key has been configured for both routers and all neighbors are updated, the old key shold be removed:
    • no ip ospf message-digest-key 100.

Example MD5 Authentication

• The following configuration is based on the topology Figure 6 above:

R1 Configuration

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
!
interface Serial1/0
ip address 192.168.1.1 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 100 md5 pa$$word
!
!
router ospf 100
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0

R2 Configuration

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
!
interface Serial1/1
ip address 192.168.1.2 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 100 md5 pa$$word
!
!
router ospf 100
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0

Figure 9: Verifying MD5 Authentication

• The sh ip ospf neighbor command shows R1 has full adjacency with its neighbor, R2.
• The routing table has learned the network 2.2.2.2.
• Ping of 2.2.2.2, learned via OSPF, is successful.

Figure 10A & 10B: Troubleshooting MD5 Authentication

• On the output above, R1 and R2 are configured with the following configurations, respectively:
  • ip ospf message-digest-key 100 md5 pa$$word
  • ip ospf message-digest-key 200 md5 pa$$word
• Analyzing the output of R1, it is sending out hash calculated with key-id 100, but it is receiving hash from R2 which is calculated using key-id 200. The same happens vice versa, with R2 expecting key-id 200 while R1 is expecting key-id 100.
• Even though the key (ie password) is the same on both neighbors, the authentication fails because the key-ids don’t match.
• The messages will keep appearing every 10 seconds (every hello interval) until the misconfiguration is fixed.

Figure 11: MD5 Authentication – Mismatched Password

• The message above is consistent with mismatch key values (password) on either end of the link.

Resources:

1. Cisco Systems [IP Routing] Configuration Examples & Technotes – OSPF Virtual Link
2. Cisco Systems [IP Routing] – What Are Virtual Links?
3. Sample Configuration for Authentication in OSPF
4. Configuring OSPF Authentication on a Virtual Link

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.