I have a situation where after applying ip inspect on interfaces with our ISP's and on the internal interface the following symptoms were seen:
1). CPU reached 100%
2). Session count reached 11500 sessions
3). Version IOS 12.3.14T
The configuration was ispect on icmp, tcp, udp and dns. On the interfaces inspect was applied inbound facing the ISP's and the internal network, the ACLs were also applied in the inbound direction. The timers were left at their defaults and dos was disabled. When looking at processes cpu the highest figure was on IP Input.
Any suggestions or recommendations would be appreciated.
sh ip inspect statistics Packet inspection statistics [process switch:fast switch] tcp packets: [696376:22379236] udp packets: [21012:65075] packets: [3255:7963] dns packets: [21011:65160] Interfaces configured for inspection 3 Session creations since subsystem startup or last reset 644405 Current session counts (estab/half-open/terminating) [10785:31:59] Maxever session counts (estab/half-open/terminating) [12125:116:125] Last session created 00:00:00 Last statistic reset 01:16:52 Last session creation rate 7305 Last half-open session total 31
sh ip inspect config Session audit trail is disabled Session alert is enabled one-minute (sampling period) thresholds are [400:100000000] connections max-incomplete sessions thresholds are [400:20000000] max-incomplete tcp connections per host is 100000. Block-time 0 minute. tcp synwait-time is 30 sec -- tcp finwait-time is 15 sec tcp idle-time is 3600 sec -- udp idle-time is 30 sec dns-timeout is 5 sec Inspection Rule Configuration Inspection name xxxxx-In udp alert is on audit-trail is off timeout 30 icmp alert is on audit-trail is off timeout 10 dns alert is on audit-trail is off timeout 30 tcp alert is on audit-trail is off timeout 3600
I don't know exaclty wath the cbac on the dns try to do in the application L7 .
Have you already tried to:
- disable the dns on the cbac ?
- disable the session alert on the inspect ?
Can you configure the netflow to see if there're dos or ddos streams ?
FYI:
*** NetFlow
NetFlow and NDE on the MSFC
The NetFlow cache on the MSFC captures statistics for flows routed in software. The MSFC supports NetFlow aggregation for traffic routed in software.
NetFlow and NDE on the PFC
The NetFlow cache on the PFC captures statistics for flows routed in hardware. The PFC supports sampled NetFlow and NetFlow aggregation for traffic routed in
hardware.
Having said the above, the Sup720 theoritecally should switch all packets in hardware, so having the Netflow in PFC would be the way to go. However, there
might be some packets that gets software switched in which the Netflow and NDE in PFC will not catch. The document does not say about not having support in
configuring Netflow in both PFC and MSFC.
If you want to see all flows, it is necessary to configure netflow export on both (PFC + MSFC). From the MSFC there are exported only first flow packet (MSFC
find destination interface from the routing table) and rest of flow is switched (it is not go through MSFC) and goes through PFC. I'm recommending send both
flow exports in to same collector, so you will see complete traffic.
show ip flow interface
sh ip cache flow
sh ip flow top-talkers
*** IP Source Tracker
The IP Source Tracker feature allows you to gather information about the traffic flowing to a host that is suspected of being under attack. This feature also
allows you to easily trace an attack back to its entry point into the network.
To trace attacks, NetFlow and access control lists (ACLs) are used together to determine the source. To block attacks, committed access rate (CAR) and ACLs
are been used.
Normally, when you identify the host that is subject to a DoS attack, you must determine the network ingress point to effectively block the attack. This
process starts at the router closest to the host.
The IP Source Tracker feature provides an easy, more scalable alternative to output ACLs for tracking DoS attacks.
Step 1. After you identify the destination being attacked, enable tracking for the destination address on the whole router by entering the ip source-track
command.
Step 2. A special CEF entry is created for the destination address being tracked. For line cards or port adapters that use specialized ASICs to do packet
switching, the CEF entry is used to punt packets to the line card's or port adapter's CPU.
Step 3. Each line card CPU collects information about the traffic flow to the tracked destination (via utilization of NetFlow).
Step 4. The data generated is periodically exported to the router. To display a summary of the flow information, enter the show ip source-track summary
command. To display more detailed information for each input interface, enter the show ip source-track command.
Step 5. Statistics provide a breakdown of the traffic to each tracked IP address. This allows you to determine which upstream router to analyze next. You can
shut down the IP source tracker on the current router by entering the no ip source-track command, and re-open it on the upstream router.
Step 6. Repeat Step 1 through Step 5 until you identify the source of the attack.
Step 7. Apply CAR or ACLs to limit or stop the attack.
it-vr-ipnetworks.it-(config)#ip source-track ? A.B.C.D Destination address to track address-limit Limit number of tracked addresses syslog-interval Interval between syslog notification messages
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.