Going through the support files and if you find such kind of log messages
2010-07-11 11:55:47 | INFO | CPU #000 | Started filtering packets of type 'TCP Non-SYN' received on interface # 0. Reason: Started filtering due to attack detection
2010-07-11 12:00:35 | INFO | CPU #000 | Started filtering packets of type 'TCP No-SYN + RST' received on interface # 0. Reason: Started filtering due to attack detection
2010-07-11 13:07:25 | INFO | CPU #000 | Stopped filtering packets of type 'TCP No-SYN + RST' received on interface # 0. Reason: Stopped filtering for an administrative pause
Basically those logs mean that SCE detect attacks and then in order to protect itself, it put those attack traffic in filter, one hour later, SCE remove the flows from filter and check again, if attack persist, SCE put attack traffic in filter again.
The time (1 hour) to continue filtering traffic is default that can be changed.
Configuration:
configure
interface LineCard 0
sanity-checks attack-filter times filtering-cycle <seconds> max-attack-time <Seconds>
To verify:
sh interface LineCard 0 attack-filter current-attacks
Example:
SCE#>show interface LineCard 0 sanity-checks attack-filter times
Filtering cycle: 3600 seconds.
Max attack time: 86400 seconds.
what is Filtering Cycle and max-attack-time?
When such attack is detected and the system is in some kind of shortage it will start filtering that specific type for the "Filtering cycle" value seconds after this time it will stop for certain amount of time in order to test whether the attack is still on and whether we are still in shortage, if both conditions are still stand it will start filter again for another "Filtering cycle" seconds period of time.
Assuming the attack and the shortage condition will still stand cycle after cycle after cycle we will stop filtering upon "Max Attack Time" seconds even if the attack and the shortage are still there.
Regards
Shelley
