When we advertise networks in OSPF using the process command network {ip-address} {wildcard-mask} area {area-id} or using the interface command ip ospf {process-id} area {area-id}, the selected network is not just advertised in OSPF, the corresponding interface will also try to form adjacencies in its network segment.  This is a normal behavior; however enabling routing everywhere may increase the chances of the insertion of unauthorized devices.    Another consideration is the possibility of an attack where an attacker could advertise fake routes to the OSPF domain and black hole traffic or even worst like crashing the router.

The following example may illustrate the problem:

First, let’s take a look at the segment 172.16.20.0/24 which corresponds to a group of users. The interface ethernet0/1 of R2 connects to a Layer-2 switch to provide connectivity to the users. No other router is connected to the segment.

R2 Configuration:

!
interface ethernet0/0
ip address 192.168.124.2 255.255.255.0
!
interface ethernet0/1
ip address 172.16.20.2 255.255.255.0
!
interface loopback0
ip address 2.2.2.2 255.255.255.255
!
router ospf 1
router-id 0.0.0.2
network 2.2.2.2 0.0.0.0 area 0
network 172.16.20.0 0.0.0.255 area 0
network 192.168.0.0 0.0.255.255 area 0
!

The above configuration enables OSPF in all 3 interfaces. The interface ethernet0/0 and 0/1 are by default OSPF network type BROADCAST. Therefore, by default both interfaces will try to form adjacencies.   Let’s take a look at the interfaces and neighbor status.

For the interface ethernet0/0 it is ok because it belongs to a transit network which connects to other routers in the same segment (R1 and R4).

However, the interface ethernet0/1 connects to a stub network.   This network is intended for user computers only and does not require adjacency forming capabilities.   In other words, it is not required sending hello packets over this interface.

The above output shows the details of the OSPF process for the interface Ethernet0/1, as you can see the output is similar to the one for interface Ethernet0/0.   This interface is also sending Hello packets with its default settings.      With the configuration like this, an attacker connected to the switch could use software such as Loki to insert routes to OSPF domain.  (You can watch an example here.)

To prevent this from happening, we can use the passive-interface {interface-id} process command.

!
router ospf 1
passive-interface Ethernet0/1
!

In the above example, setting the interface Ethernet0/1 as passive disables the sending of hello packets on that interface; hence, adjacencies will not be formed. However, the subnet 172.16.20.0/24 will continue to be advertised to other interfaces.

Let’s take a look at the result:

Now the output of show ip ospf interface E0/1 states that No Hellos are being sent on this interface and is a Passive interface.

You may be wondering what happens with the interface command ip ospf {process-id} area {area-id}?

Well, it is the same principle.   Let’s take a look to R3 which was configured this way.

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
interface Ethernet0/0
ip address 192.168.13.3 255.255.255.0
ip ospf 1 area 0
!
interface Ethernet0/1
ip address 172.16.30.3 255.255.255.0
ip ospf 1 area 0
!
router ospf 1
router-id 0.0.0.3
passive-interface Ethernet0/1
!

As you can see the output of show ip ospf interface E0/1 display the same results as shown for R2.  It states that No Hellos are being sent on this interface and is a Passive interface.

The Passive-Interface inverse logic:

You may well have a multi-layer switch with multiple VLAN-interfaces where you want to configure most or all of them as passive.  In this case, would be more effective if all of the interfaces are set as passive and just enable the hello packets to the ones where is required instead go on setting the interfaces as passive one by one.  (The inverse logic)

In this case, we can use the passive-interface default process command to disable Hello packets from all interfaces and then enable Hellos with the no passive-interface {interface-id} only on the desired interfaces.

Let’s take a look at the relevant Multi-Layer Switch configuration:

!
ip routing
!
interface Ethernet0/1
description UPLINK-to->R2
no switchport
ip address 192.168.50.2 255.255.255.252
!
interface vlan 10
ip address 10.0.10.254 255.255.255.0
!
interface vlan 20
ip address 10.0.20.254 255.255.255.0
!
interface vlan 30
ip address 10.0.30.254 255.255.255.0
!
interface vlan 40
ip address 10.0.40.254 255.255.255.0
!
interface vlan 50
ip address 10.0.50.254 255.255.255.0
!
interface loopback 0
ip address 50.50.50.50 255.255.255.255
!
router ospf 1
router-id 0.0.0.50
 passive-interface default
 no passive-interface Ethernet0/1
network 50.50.50.50 0.0.0.0 area 0
network 192.168.50.2 0.0.0.0 area 0
network 10.0.0.0 0.0.255.255 area 0
!

With the above configuration, we have enabled OSPF for the loopback interface, for the uplink interface between the switch and R2 and finally all of the SVI interfaces. The passive-interface default command has disabled sending hello packets in all of the OSPF-enabled interfaces. Finally, the no passive-interface Ethernet0/1 enables sending hello packets through that interface.

 WARNING.!

The passive-interface default command will tear down all adjacencies almost immediately.  So, consider how are you connected to the device.

It is time to close this long post. Thank you for visiting.