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:
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.
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.
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.