Hands-On Lab: Configuring the OSPF Passive Interface Manually

This hands-on lab configures a passive interface in OSPF so a LAN-facing interface still advertises its network while no longer sending or accepting OSPF hello packets on it, preventing unnecessary neighbor formation and unauthorized adjacencies on access-layer ports.

OSPF Passive InterfaceSuppress Hello PacketsAccess Port Security

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

Lab Objective

Configure a router's LAN-facing interface as passive within OSPF, verify its network is still advertised into the routing domain, and confirm no OSPF hello packets are sent or accepted on that interface afterward.

Lab Purpose

An interface facing an end-user LAN segment has no legitimate OSPF neighbor to form an adjacency with, yet by default OSPF sends hello packets out every network-enabled interface. This wastes bandwidth and, more importantly, creates a security exposure: anyone who plugs a rogue router into that LAN segment could potentially form an unauthorized OSPF adjacency.

Lab Topology

R1
  GigabitEthernet0/0: 192.168.7.1/24 (LAN, end
                       users only, no other routers)
  Serial0/0/0: 10.7.7.1/30 (WAN link to R2,
               legitimate OSPF neighbor)

OSPF process 1 already advertising both networks

Task 1: Verify Both Interfaces Currently Send Hellos

Confirm OSPF hello packets are being sent on both the LAN and WAN interfaces.

Task 2: Configure the LAN Interface as Passive

Set GigabitEthernet0/0 as a passive interface within the OSPF process.

Task 3: Verify the LAN Network Is Still Advertised

Confirm 192.168.7.0/24 still appears in other routers' routing tables despite the interface being passive.

Task 4: Verify Hellos Are Suppressed on the LAN Interface

Confirm no OSPF hello packets are sent or received on the now-passive interface, while the WAN interface continues normally.

Solution and Verification

R1# show ip ospf interface brief

Interface    PID   Area    IP Address/Mask    Cost   State
Gi0/0        1     0       192.168.7.1/24     1      DR
Se0/0/0      1     0       10.7.7.1/30        64     P2P
-- Both interfaces are actively participating,
-- including the LAN interface with no
-- legitimate neighbor to talk to

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

R2# show ip route ospf

O    192.168.7.0/24 [110/2] via 10.7.7.1, Serial0/0/0
-- R2 still learns this network correctly --
-- passive interface only suppresses hello
-- packets, it does NOT stop the network from
-- being advertised via the network command,
-- discussed earlier in this series

R1# show ip ospf interface gigabitethernet0/0

GigabitEthernet0/0 is up, line protocol is up
  No Hellos (Passive interface)

R1# show ip ospf interface serial0/0/0

Serial0/0/0 is up, line protocol is up
  Timer intervals configured, Hello 10, Dead 40
-- Confirms the LAN interface has genuinely
-- stopped sending hellos, while the WAN
-- interface continues normal OSPF operation

Key Takeaway

Passive interface is a critical distinction from simply not including a network in OSPF at all: the network is still advertised and reachable, but the interface stops actively participating in neighbor discovery — this combination of "advertise the route, but don't accept neighbors here" is exactly what a LAN-facing access interface needs, and it should be applied as standard practice on every interface with no legitimate OSPF neighbor.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه