Multiple OSPF processes with mixed network statements can really mess things up! Fortunately, there is a better way to assign an interface into an OSPF area.

I’ve discussed overlapping OSPF network statements in one of my earlier posts. In the a “pre-IPv6-era” we were taught to use network statements in the OSPF stanza to assign the interfaces to a certain OSPF area. This configuration

interface Vlan100
  ip address 10.0.100.1 255.255.255.0
!
router ospf 1
  passive-interface default
  no passive-interface Vlan100
  network 10.0.100.0 0.0.0.255 area 1

…enables OSPF process on the interface Vlan100 and assigns that interface to OSPF area 1.
What happens if one uses multiple and overlapping networks statements in order to assign interfaces into different areas? Here is an example:

interface FastEthernet0/0
  ip address 10.99.99.1 255.255.255.0
!
interface Vlan100
  ip address 10.0.100.1 255.255.255.0
!
router ospf 1
  passive-interface default
  no passive-interface Vlan100
  no passive-interface FastEthernet0/0
  no passive-interface ...
  network 10.0.100.0 0.0.0.255 area 100
  network 10.0.0.0 0.255.255.255 area 0

This works as expected – more specific network statement for 10.0.100.0/24 is processed first, putting the interface Vlan100 to area 100. Next, a less specific network statement assigns all other interfaces from 10.0.0.0/8 to the backbone area. Cisco box neatly sorts the networks statements under the OSPF stanza, from most to least specific.

Overlapping networks can also be used with multiple OSPF processes. But, there is a hidden trap – the order of OSPF processes in the configuration is important! Check this:

interface FastEthernet0/0
  ip address 10.99.99.1 255.255.255.0
!
interface Vlan200
  ip address 10.0.200.1 255.255.255.0
!
router ospf 2
  passive-interface default
  no passive-interface Vlan200
  network 10.0.200.0 0.0.0.255 area 0
!
router ospf 1
  passive-interface default
  no passive-interface FastEthernet0/0
  no passive-interface ...
  network 10.0.0.0 0.255.255.255 area 0

In the example above interface Vlan200 is put into backbone area 0 under OSPF process 2, then others follow by OSPF process 1. But what if the order of the processes is reversed and OSPF 1 comes first?

interface FastEthernet0/0
  ip address 10.99.99.1 255.255.255.0
!
interface Vlan200
  ip address 10.0.200.1 255.255.255.0
!
router ospf 1
  passive-interface default
  no passive-interface FastEthernet0/0
  no passive-interface ...
  network 10.0.0.0 0.255.255.255 area 0
!
router ospf 2
  passive-interface default
  no passive-interface Vlan200
  network 10.0.200.0 0.0.0.255 area 0

In the situation like this Vlan200 stays “passive” and it is not part of any OSPF process. It matches network 10.0.0.0/8 which comes first in OSPF 1, but it is declared passive there with the “passive-interface default”. Being matched already by OSPF 1, Vlan200 is ignored in OSPF 2.
The situation could be even worse as the order of OSPF processes in the configuration changes after a router reloads – processes are being reordered in ascending order of process ID.


IPv6 to the rescue :-). Not the protocol itself – just the way OSPF is configured for IPv6.

Namely, IPv6 introduced another “juniperised” approach to the Cisco OSPF configuration. In OSPFv3 (for IPv6), network statements are not used. They are being replaced by direct assignments to areas inside the interface configuration. The broken configuration above can be replaced by:

interface FastEthernet0/0
  ip address 10.99.99.1 255.255.255.0
  ip ospf 1 area 0
!
interface Vlan200
  ip address 10.0.200.1 255.255.255.0
  ip ospf 2 area 0
!
router ospf 1
  passive-interface default
  no passive-interface FastEthernet0/0
  no passive-interface ...
!
router ospf 2
  passive-interface default
  no passive-interface Vlan200

Nice and clean and with no dilemma what comes first :-).
This technique is well-known in OSPFv3 for IPv6 but it is implemented for IPv4 as well in Cisco IOS 15.something.

Advertisements