CBAC 7200


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.



Reply to
Loading thread data ...

can you paste the output of

sh ip inspect config

sh ip inspect statistics

The netflow feature is available on the IOS ?

Reply to

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

Netflow is available but not configured.

formatting link

Reply to

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 ?


*** 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


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.

The IP Source Tracker works as follows:


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


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. source-track ? A.B.C.D Destination address to track address-limit Limit number of tracked addresses syslog-interval Interval between syslog notification messages source-track ip source-track

Reply to 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.