CCNA 200-125 Tutorial: OSPF Passive Interfaces

You can also see this OSPF feature in action in one of my CCNA 5:00 Video Boot Camps:

CCNA Video:  OSPF Passive Interfaces

The term “passive interface” is an odd one; why would we ever want to run OSPF on an interface and then make that interface passive?   On top of that, what exactly happens to an interface when we make it passive?   Let’s answer that first question first, using this network:

OSPF Passive Interface Lab Setup

Both R2 and R3 have the 10.1.1.0 /24 network in their OSPF routing tables. (At this point, that’s the only route in those tables!)

R2#show ip route ospf
 10.0.0.0/24 is subnetted, 1 subnets
 O 10.1.1.0 [110/65] via 172.12.123.1, 00:00:13, Serial0/1/0
R3#show ip route ospf
 10.0.0.0/24 is subnetted, 1 subnets
 O 10.1.1.0 [110/65] via 172.12.123.1, 00:00:19, Serial0/1/0

It’s always wise to ping new destinations, and we have no trouble with that from R2 or R3.

R2#ping 10.1.1.1

Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 64/64/68 ms

R3#ping 10.1.1.1

Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms

The act of enabling OSPF on an interface via the network command allows that interface to begin multicasting Hello packets to 224.0.0.5 out that same interface.   In this lab, the 10.1.1.0 /24 network is a broadcast segment, which in turn means a hello will be sent out the interface on that network every 10 seconds.   We can and will verify that theory with show ip ospf interface.

R1#show ip ospf interface fast 0/0
 FastEthernet0/0 is up, line protocol is up
 Internet Address 10.1.1.1/24, Area 0
 Process ID 1, Router ID 172.12.123.1, Network Type BROADCAST, Cost: 1
 Transmit Delay is 1 sec, State DR, Priority 1
 Designated Router (ID) 172.12.123.1, Interface address 10.1.1.1
 No backup designated router on this network
 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
 oob-resync timeout 40
 Hello due in 00:00:09
 Supports Link-local Signaling (LLS)
 Index 2/2, flood queue length 0
 Next 0x0(0)/0x0(0)
 Last flood scan length is 0, maximum is 0
 Last flood scan time is 0 msec, maximum is 0 msec
 Neighbor Count is 0, Adjacent neighbor count is 0
 Suppress hello for 0 neighbor(s)

Thing is,  there’s no router or L3 switch on that segment that could possibly use the hellos.

Sending OSPF Hello To No One

We can see the hellos leaving every 10 seconds with debug ip ospf hello.

R1#debug ip ospf hello
OSPF hello events debugging is on
00:37:06: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 10.1.1.1
00:37:12: OSPF: Send hello to 172.12.123.2 area 0 on Serial1/0 from 172.12.123.1
00:37:12: OSPF: Send hello to 172.12.123.3 area 0 on Serial1/0 from 172.12.123.1
00:37:12: OSPF: Rcv hello from 172.12.123.3 area 0 from Serial1/0 172.12.123.3
00:37:12: OSPF: End of hello processing
00:37:16: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 10.1.1.1
00:37:17: OSPF: Rcv hello from 172.12.123.2 area 0 from Serial1/0 172.12.123.2
00:37:17: OSPF: End of hello processing
00:37:26: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 10.1.1.1

That might not seem like a big deal, but that’s 6 unnecessary Hello packets leaving that router every minute — 360 unnecessary packets every hour — 8,640 unnecessary Hellos leaving that router every single day.   There’s no reason to have the router do that when there’s no possible OSPF neighbor to be found off that interface, right?   Right!

We could stop the hellos by removing network 10.1.1.0 0.0.0.255 area 0 …

R1(config)#router ospf 1
R1(config-router)#no network 10.1.1.0 0.0.0.255 area 0

R1#debug ip ospf hello
OSPF hello events debugging is on
00:41:12: OSPF: Send hello to 172.12.123.2 area 0 on Serial1/0 from 172.12.123.1
00:41:12: OSPF: Send hello to 172.12.123.3 area 0 on Serial1/0 from 172.12.123.1
00:41:25: OSPF: Rcv hello from 172.12.123.3 area 0 from Serial1/0 172.12.123.3
00:41:25: OSPF: End of hello processing
00:41:31: OSPF: Rcv hello from 172.12.123.2 area 0 from Serial1/0 172.12.123.2
(Note from Chris: Hellos are no longer leaving Fast0/0)

… but of course, that’s also going to remove the 10.1.1.0 /24 route from R2 and R3, which really isn’t what we’re after.

R2#show ip route ospf
 (Note from Chris: Nothing to show.)

R3#show ip route ospf
 (Ditto)

Before we proceed, I’ll put the 10.1.1.0 /24 network back in on R1.

R1(config)#router ospf 1
R1(config-router)#network 10.1.1.0 0.0.0.255 area 0

Passive interfaces to the rescue!   By making Fast 0/0 passive, we’ll keep OSPF enabled on that particular interface while preventing that interface from sending Hello packets.   The only tricky part of this config is remembering that passive-interface is not an interface-level command.

R1(config)#router ospf 1
 R1(config-router)#passive-interface ?

 Async Async interface
 BVI Bridge-Group Virtual Interface
 CTunnel CTunnel interface
 Dialer Dialer interface
 FastEthernet FastEthernet IEEE 802.3
 Group-Async Async Group interface
 Lex Lex interface
 Loopback Loopback interface
 MFR Multilink Frame Relay bundle interface
 Multilink Multilink-group interface
 Null Null interface
 Port-channel Ethernet Channel of interfaces
 Serial Serial
 Tunnel Tunnel interface
 Vif PGM Multicast Host interface
 Virtual-PPP Virtual PPP interface
 Virtual-Template Virtual Template interface
 Virtual-TokenRing Virtual TokenRing
 default Suppress routing updates on all interfaces

R1(config-router)#passive-interface fast 0/0

Our new pal debug ip ospf hello verifies Hello packets are no longer being multicast via Fast 0/0 while both R2 and R3 still see 10.1.1.0 /24 in their respective routing tables.

R1#debug ip ospf hello
OSPF hello events debugging is on

00:50:01: OSPF: Rcv hello from 172.12.123.3 area 0 from Serial1/0 172.12.123.3
00:50:01: OSPF: End of hello processing
00:50:07: OSPF: Rcv hello from 172.12.123.2 area 0 from Serial1/0 172.12.123.2
00:50:07: OSPF: End of hello processing
00:50:12: OSPF: Send hello to 172.12.123.2 area 0 on Serial1/0 from 172.12.123.1
00:50:12: OSPF: Send hello to 172.12.123.3 area 0 on Serial1/0 from 172.12.123.1
(Note from Chris:  No hellos leaving Fast 0/0.)
R2#show ip route ospf
 10.0.0.0/24 is subnetted, 1 subnets
 O 10.1.1.0 [110/65] via 172.12.123.1, 00:00:00, Serial0/1/0

R3#show ip route ospf
 10.0.0.0/24 is subnetted, 1 subnets
 O 10.1.1.0 [110/65] via 172.12.123.1, 00:01:36, Serial0/1/0

With great passive interfaces comes great responsibility, and that responsibility includes making the right interfaces passive. If I make the wrong interface on R1 passive, well, bad things happen.

Wrong Passive Interface

R1(config)#router ospf 1
R1(config-router)#passive-interface Serial 1/0

%OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.2, Neighbor Down: Interface down or detached
%OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.3, Neighbor Down: Interface down or detached

If you see adjacencies drop right after you use passive-interface, you made the wrong interface passive!   No worries, just put no in front of the command you just entered and your adjacencies will come back up. (This may take a minute or two on an NBMA network.)

R1(config)#router ospf 1
R1(config-router)#no passive-int serial 1/0

%OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.2 on Serial1/0 from LOADING to FULL, Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 172.12.123.3 on Serial1/0 from LOADING to FULL, Loading Done

You can also use passive interfaces with RIPv2 and EIGRP, and it’s a very good idea to know exactly what happens (and doesn’t happen) when you use this feature with those two protocols. We’ll have a look at EIGRP passive interfaces in our next CCNA 200-125 tutorial!

Chris B.