I wanted to implement a mechanism that would automatically (using EEM) block unstable OSPF neighbors. Once you identify the neighbors to block (this should be the hard part), blocking them is easy if you're running point-to-point interfaces (you just make the interface passive), but blocking a single neighbor on a multi-access interface is a royal pain. I didn't want to use the access lists, as it would be very hard to integrate OSPF-specific filters with existing incoming access-lists configured on the interfaces. Control Plane Protection looked like the ideal tool to use; if I could drop certain inbound IP packets (OSPF hello packets) based on their source IP address (= unstable neighbor) and IP protocol (= OSPF), they would never get to the OSPF process and the adjacency would not form, resulting in a more stable network.
Update: After the comment from William Chu, I've tested 12.4 mainstream release. OSPF is blocked as configured. Next I've re-read the documentation … and found that one of the documented restrictions is that the host subinterface only filters UDP and TCP traffic. Configuring the service policy on the aggregate path (the control-plane keyword with no options) worked.
Before trying to figure out the integration between the SYSLOG messages and router configuration changes, I performed an easy test: I tried blocking all OSPF traffic in the host control-plane (the one controlling packets received by the IOS processes) with the following configuration:
class-map match-all BlockOSPF
match access-group name BlockOSPF
!
!
policy-map ControlPlane
class BlockOSPF
drop
!
ip access-list extended BlockOSPF
permit ospf any any
!
control-plane host
service-policy input ControlPlane
However, according to the
show commands, the service policy did not identify any packets as belonging to the BlockOSPF class and the OSPF adjacencies were not affected:
C1#show policy-map control-plane host
Control Plane Host
Service-policy input: ControlPlane
Class-map: BlockOSPF (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name BlockOSPF
drop
Class-map: class-default (match-any)
5 packets, 400 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
C1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.12 1 FULL/DR 00:00:30 10.0.1.2 FastEthernet0/0
10.0.0.2 0 FULL/ - 00:00:33 10.0.0.2 Serial1/0.101
10.0.2.2 0 FULL/ - 00:00:33 10.0.0.1 Serial1/0.100
After a few more tests, I had to conclude that the Control Plane Protection using host subinterface
does not work on OSPF packets (and it
might does not work on other non-TCP/UDP traffic either).
Consequently you cannot protect your router from a DoS attack coming through an interface on which you have to run OSPFTo filter non-TCP/UDP traffic, use the aggregate path control plane protection.