1. Home
  2. Cisco Systems
  3. ISR CBAC prolem

ISR CBAC prolem

I have 2811 with IOS 12.4(4)T1 ADVANCED IP SERVICES and after applying CBAC I noticed that router drops some of the returning traffic that belongs to the same TCP session or UDP flow as the packets not dropped. Some packets makes trough to the users and some are simply dropped by inbound ACL... I opened TAC case, but after 2 weeks they are unsuccessful in troubleshooting my issue.

I tried to raise tcp half-opened connection threshold, but there where no any improvements regarding to this problem...

%FW-4-ALERT_ON: getting aggressive, count (213/2000) current 1-min rate: 601

Could a message as above be interpreted as that router has detected a significantly amount of half-opened connections (601 currently), but it would not start to block that traffic until half-opened connection count reaches 2000. Right? If so, misconfigured half-opened connection threshold could not be the cause of this problem?

Is someone else with such problem?

Configuration excerpt:

ip inspect max-incomplete high 2000 ip inspect max-incomplete low 1000 ip inspect one-minute low 500 ip inspect one-minute high 600 ip inspect name DEFAULT100 cuseeme ip inspect name DEFAULT100 ftp ip inspect name DEFAULT100 h323 ip inspect name DEFAULT100 netshow ip inspect name DEFAULT100 rcmd ip inspect name DEFAULT100 realaudio ip inspect name DEFAULT100 rtsp ip inspect name DEFAULT100 smtp ip inspect name DEFAULT100 sqlnet ip inspect name DEFAULT100 streamworks ip inspect name DEFAULT100 tftp ip inspect name DEFAULT100 tcp ip inspect name DEFAULT100 udp ip inspect name DEFAULT100 vdolive ip inspect name DEFAULT100 icmp !

interface fa0/0

! inside interface

ip address 192.168.10.1 255.255.255.0

ip nat inside

ip inspect DEFAULT100 in

!

Interface fa0/1

! outside interface

ip address 195.100.100.1 255.255.255.252

ip nat outside

ip access-group 111 in

!

Interface loopback 0

ip address 200.200.200.1 255.255.255.248

ip nat inside source list 1 pool NAT_POOL overload

!

ip nat pool NAT_POOL 200.200.200.1 200.200.200.1 netmask 255.255.255.248

!

access-list 111 deny any any

B.R.

Igor

Reply to
Igor Mamuzic
Loading thread data ...

It's difficult to diagnose these kinds of issues without having more config information as well as a better description of exactly what you're seeing. It would be helpful to know the answers to these questions:

1) Have you determined if packets are arriving out of order? CBAC doesn't react well when sequence numbers arrive significantly out of order. Just how out of order packets need to be to cause problems depends on your TCP and Inspect timeout configuration but I suspect that this might be a factor in your case because you specifically mention the same problem with UDP traffic. Since UDP is connectionless CBAC's only job when processing generic UDP traffic is to open a "window" to the destination and start monitoring the flow for activity. If no activity is detected within a certain time period, the window will be closed by CBAC. At that point, any return traffic is going to be dropped. If you see this type of thing a lot, you might want to increase the inspection timouts. The easiest way to quickly identify this type of problem is with a packet trace. Ethereals' built in TCP sequence analysis will spot these kinds of problems very quickly....

2) Are you running CEF/Flow switching?

3) Have you determined if it's a specific type of flow that's consistently causing the problem? (FTP, DNS, etc.) Or does it happen with all different types of flows regardless specific or generic inspection?

This is only one of many possible reasons you're seeing traffic dropped. If you provide more information, I'd be glad to help you identify the problem and provide some solutions that have worked for me over the years.

Regards C. Rowland

Reply to
Cisco

Hello,

thanks for helping me to troubleshoot this issue, I have some updates regarding this case:

When I apply CBAC (input direction) onto inside interface without any ACL's applied on any interfaces it still shows dropped packets anyway if you activate 'ip inspect log drop-pkt'. Here is log output:

004681: Jan 23 10:52:32: %FW-6-DROP_PKT: Dropping tcp pkt 82.193.194.241:1404 => 195.95.24.245:80

004682: Jan 23 10:53:21: %FW-6-DROP_PKT: Dropping tcp pkt 67.18.137.218:80 => 192.168.73.68:13769

004703: Jan 23 11:01:59: %FW-6-DROP_PKT: Dropping tcp pkt 82.193.222.178:35608 => 207.65.23.135:443

As you can see from the output above it seems that it drops both outbound (82.193.194.241:1404 => 195.95.24.245:80) and inbound (67.18.137.218:80 =>

192.168.73.68:13769) connections...

Here are answers on your questions:

1) Have you determined if packets are arriving out of order? I have to check once again...I'll let you know what I found out... Now, regarding UDP, I think I saw udp traffic being dropped such as dns queries...

2) I'm running CEF and netflow on both outside and inside interfaces...

3) Packets that being dropped are mostly http/https traffic which should be inspected with generic tcp inspection, but these apps represents the majority of our internet traffic.

4) Yet another thing I forgot to mention in my previous post - traffic drops occurs only at heavier traffic load conditions, that is during a working day, but when traffic amount is low on evening or during weekends CBAC performs ok...

B.R. Igor

Reply to
Igor Mamuzic

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.