Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > ISR CBAC prolem

Reply
Thread Tools

ISR CBAC prolem

 
 
Igor Mamuzic
Guest
Posts: n/a
 
      01-22-2006
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 With Quote
 
 
 
 
Cisco
Guest
Posts: n/a
 
      01-23-2006
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 With Quote
 
 
 
 
Igor Mamuzic
Guest
Posts: n/a
 
      01-23-2006
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




"Cisco" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> 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 With Quote
 
lennartvdd lennartvdd is offline
Junior Member
Join Date: Dec 2009
Posts: 1
 
      12-01-2009
Sorry for opening up this old post, but I have exactly the same problem ! Did you solve it?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ISR (interrupt service routine) code in isr.c Eirik Midttun C Programming 2 02-08-2007 03:52 AM
html table prolem roN HTML 2 02-07-2006 06:04 PM
Performance prolem when deploying Mans ASP .Net 3 01-28-2004 07:43 PM
Re: Roadrunner prolem perplexed Computer Support 0 09-02-2003 07:22 PM
Roadrunner prolem perplexed Computer Support 1 09-02-2003 07:17 PM



Advertisments