Cisco – How to virtual-link between two different OSPF areas

ciscoospfrouting

Is there a way to connect routers via virtual-link between two different OSPF area?

topology

Best Answer

You need to configure virtual link on both end point routers of the virtual link. Command in router ospf configuration is: area <AREA_ID> virtual-link <ROUTER_ID> where <AREA_ID> is transit OSPF area and <ROUTER_ID> is IP address (Loopback) of the other interconnecting router. Virtual links are considered to be an indicator of bad network design, so if you really need to use them maybe you should consider revising your network structure.

OSPF Backbone

Why is area 0 the backbone area in OSPF? Why must all other areas connect to it?

This is explained very well in RFC 3509, Section 1.2¹:

1.2 Motivation

In OSPF domains the area topology is restricted so that there must be a backbone area (area 0) and all other areas must have either physical or virtual connections to the backbone. The reason for this star-like topology is that OSPF inter-area routing uses the distance-vector approach and a strict area hierarchy permits avoidance of the "counting to infinity" problem. OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, allowing ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes, and limiting ABRs' SPF calculation to consider only Summary-LSAs in the backbone area's link-state database.

OSPF is usually considered a link-state protocol. What some people miss is that OSPF uses both link-state protocol and distance-vector protocol algorithms.

Routes within the backbone, or a non-backbone area are computed as a link-state protocol does (ref Dijkstra's algorithm).
When OSPF must carry non-backbone routes through the backbone, it uses some distance-vector behavior (i.e. parts of the Bellman Ford algorithm) to propagate Type3 LSA metrics into non-backbone areas.

Simple example of OSPF's distance-vector behavior:

<-- Area 5 --><-- Area 0 --><--           Area 4           -->

R5-----------R1-----------R2------------R3---------------------R4
     Cost 3      Cost 5        Cost 7            Cost 12

               LSA-->          LSA-->
               Type3 LSA       Type3 LSA
               {From R1}       {From R2}
               R5 cost is 3    R5 cost is 8

Consider what happens to a /32 Loopback route for R5.

R5 sends a Type1 LSA containing the /32 Loopback
R1 (Area 5 ABR), is connected to Area 0; it translates the Type1 LSA into a Type3 LSA with a cost of 3.
R2 (Area 4 ABR) receives R1's Type3 LSA (metric 3) and changes the metric to R5's Loopback, based on R2's cost to R1. Now R2's Type3 LSA for R5 has a cost of 8. This is the distance-vector behavior I mentioned above.

Requiring all non-backbone routes to go through the backbone is a loop-prevention mechanism.

Connecting non-backbone OSPF areas at an ABR

If 2 areas aren't connected through area 0 (discontiguous), how does OSPF behaving as a link state protocol increase the possibility of routing loops?

As we saw above, OSPF uses distance-vector behavior to send routes through the Area 0 backbone. Distance-vector protocols have well-known limits, such as the count-to-infinity problem. OSPF would be vulnerable to the same issues, if we didn't have boundaries on its behavior.

¹_{RFC 3509 describes Cisco IOS's ABR behavior}

OSPF – How to Set a Zero Cost Link

Can one set a link's cost to zero in OSPF?

Yes and no... you can't manually set a link's cost to 0, but if you have a Designated Router election on the network, the cost from the DR to any attached router on the same Broadcast / NBMA network is considered 0.

As such, be sure that the A-B and C-D links are OSPF broadcast networks; this forces a DR election and will make the cost of A-B and C-D zero. The DR is sometimes referred to as a pseudonode in OSPF.

Once you make the A-B and C-D links zero cost in OSPF (by virtue of a DR election), A-C and B-D links should be set to the same cost if you want equal-cost load-balancing.

This could be desirable to force load-balancing in certain cases.

If you want a generalized solution to this problem (without dependencies the topology or type of OSPF network involved), you are making one of the classic cases for MPLS TE; OSPF supports MPLS TE (see RFC 3630).

Let's assume:

You are running Cisco IOS
You only need load-balancing in a single OSPF area
You are not trying to deal with NIC-level failovers on the hosts (which can still be managed with MPLS TE, but I'm not illustrating here for brevity)
My configuration below has no errors (caveat emptor: I did not lab test my config below, and it's been close to a decade since I seriously needed MPLS TE); however, even if I have to fix an error in the config, the concept of solving your problem with equal-cost load-balancing through MPLS TE tunnels is correct.

Topology

Assume all IP addresses in the diagram are taken from 10.1.x.x...

          1.1/30   1.2/30
          g1/1     g1/1
         A-------------C
     g1/2|             |g1/2
 2.253/24|             |3.253/24
         |             |
         |             |
 2.252/24|             |3.253/24
     g1/2|             |g1/2
         B-------------D
          g1/1     g1/1
          1.5/30   1.6/30

MPLS TE Tunnels

Build the following tunnels so we can use ECMP to meet your requirements. Each tunnel interface will have the same OSPF cost.

Tunnels from head-end Router A
Tunnel0: Path A -> C
Tunnel1: Path A -> B -> D -> C
Tunnels from head-end Router C
Tunnel0: Path C -> A
Tunnel1: Path C -> D -> B -> A

Loopbacks

A:Lo0 10.0.0.1/32
B:Lo0 10.0.0.2/32
C:Lo0 10.0.0.3/32
D:Lo0 10.0.0.4/32

Router A's configuration (you can derive all others from this example)

Reference links:

MPLS TE w/ OSPF Ref
Interface MTUs: CCO MTU Link 1, CCO MTU Link 2
MPLS TE Autoroute info

!
mpls traffic-eng tunnels
!
interface Loopback0
 ip address 10.0.0.1 255.255.255.255
!
interface Tunnel0
 ip unnumbered Loopback0
 tunnel destination 10.0.0.3
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng bandwidth 10000
 tunnel mpls traffic-eng path-option 1 explicit name A_C
 !!! NOTE: Keep the tunnel up if path-option 1 fails
 tunnel mpls traffic-eng path-option 2 dynamic
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel destination 10.0.0.3
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng bandwidth 10000
 tunnel mpls traffic-eng path-option 1 explicit name A_B_D_C
 !!! NOTE: Keep the tunnel up if path-option 1 fails
 tunnel mpls traffic-eng path-option 2 dynamic
!
interface GigabitEthernet1/1
 description [A -> C]
 mtu 1524
 mpls mtu 1524
 ip mtu 1500
 ip address 10.1.1.1 255.255.255.252
 ip rsvp bandwidth 10000 10000
 mpls traffic-eng tunnels
!
interface GigabitEthernet 1/2
 description [A -> B]
 mtu 1524
 switchport
 switchport mode access
 switchport access vlan 10
!
interface Vlan10
 mtu 1524
 mpls mtu 1524
 ip mtu 1500
 ip address 10.1.2.253 255.255.255.0
 standby 10 ip 10.1.2.254
 standby 10 priority 105
 standby 10 timers msec 200 750
 ip rsvp bandwidth 1000000 1000000
 mpls traffic-eng tunnels
!
router ospf 10
 router-id 10.0.0.1
 log-adjacency-changes
 network 10.0.0.0 0.255.255.255 area 0
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
!
ip explicit-path name A_C enable
 next-address 10.1.1.2
! 
ip explicit-path name A_B_D_C enable
 next-address 10.1.2.252
 next-address 10.1.1.6
 next-address 10.1.3.253
!