Screen OS

Hello.
 
I'm using ISG-1000
 
Firmware: 6.2.0r1.0 (Firewall+VPN)
 
When I’m running TCP traffic (HTTP or SMTP) on 4 x 1Gige interfaces I’m getting many drops with msg 'AGE OUT'
 
The CPU utilization is at 30% usage, and memory usage is really low and still I see many drops
 
I tried to change the HTTP service timeout to something higher and still having these drops,
 
But when I’m working with only 2 x 1Gige interfaces I don't see any drops (it doesn’t matter which interfaces)
 
 
Hope someone can help me since I don’t know what else to do
 
Thank you

What's the session duration for this timed out sessions? If it's about 20 seconds you're running into inital set-up time-out. 99% of cases caused by asymetric routing.

Hi,

 

Session "Age OUT"  messages you are seeing is probably because  of logging on the policy. When you have a logging on the policy and getting this kind of message , it is refering to multiple issues like FIN or Reset coming from either client or Server Or may be Firewall is sending this kind of messages.

 

Please collect the following data which would be helpful to find the clue of the issue:

1) Sniffer capture for traffic coming and outgoing to the firewall

2) Debug flow basic with specifc filters

 

Thanks

Atif

Just so it's clear on what "age-out" means.. This is not a dropped packet in the typical sense (i.e denied by policy, screen, etc..)

 

Age-Out means the session timer expired. Typically you'll see this with TCP connections if you have (as screenie mentioned) an asymetric routing issue. 

 

This could also mean you have traffic black holed, or a service down. For example.. if a user is configured to connect to a website everytime they open up their web browser but that internal server does not respond (assuming it's permitted by policy) the firewall will see a Syn request.. build a partial/embryonic session with a time out of 30 seconds (3 ticks). 

 

A large amount of TCP age-outs is an indicator of a problem. Most likely with your network or maybe the firewall routing table.

 

Good luck,

-Tim Eberhard

 

 

Thank you all for replying.

 

I don't know what's an 'Asymetric routing' but I will tell you what i'm trying to do.

 

the machine has 5 interfaces, 1 for managment and the other for the traffic

 

IP's

 

interface1 - 1.1.1.1

interface2 - 2.2.2.1

interface3 - 3.3.3.1

interface4 - 4.4.4.1

 

interface1 is the client and interface2 is the server

 

same for interface3 and interface4

 

int1 send data (UDP\TCP) to int2 and int3 send same data to int4

 

 

 

this is my routing table:

IPv4 Dest-Routes for <trust-vr> (11 entries)
--------------------------------------------------------------------------------------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*        12          0.0.0.0/0            mgt    192.168.64.1   S   20      1     Root
*         5         1.1.1.1/32         eth1/1         0.0.0.0   H    0      0     Root
*         9         3.3.3.1/32         eth1/3         0.0.0.0   H    0      0     Root
*         7         2.2.2.1/32         eth1/2         0.0.0.0   H    0      0     Root
*        11         4.4.4.1/32         eth1/4         0.0.0.0   H    0      0     Root
*         3  192.168.64.111/32            mgt         0.0.0.0   H    0      0     Root
*         2    192.168.64.0/24            mgt         0.0.0.0   C    0      0     Root
*        10         4.4.4.0/24         eth1/4         0.0.0.0   C    0      0     Root
*         8         3.3.3.0/24         eth1/3         0.0.0.0   C    0      0     Root
*         6         2.2.2.0/24         eth1/2         0.0.0.0   C    0      0     Root
*         4         1.1.1.0/24         eth1/1         0.0.0.0   C    0      0     Root

 

 

i'm using any-any-permit as my rulebase

 

 

hope it's helps

 

if anyone knows how can i use sniffers and debug my flows in ISG-1000 I would like to hear

 

 

thank you !!

Asymetric means your flow to a destination is different from the flow back. This oft happens when there is a router to some remote location on the network, which isn't the default gateway. To reach a destination a packet is send to the firewall (being the default gateway in the network) the firewall "knows" about the router on the same network the packet is arriving from. So it send the packet to the router. The return pack however arrives on the router, and this router has a directly connected network for this addres, So it does its job this best its knows how and directly dilivers this packet, bypassing the firewall. This results in a early time-out on the firewall because it sees the syn (first packet) but it misses the syn-ack (first reply), reulting in an age-out over 20 seconds. (TCP here).

 

So far the theory on asym routing....

 

To bebug your session:

 

first set a debug flow filter:

 

set ff src-ip <IP> dst-ip <IP>

 

Start the debug

 

debug flow basic

 

clear the debug out buffer

 

clear db

 

generate your traffic

 

Stop the debugging

 

undebug all (or just press the escape key !)

 

look at the result

 

get db stream

 

So this is how you can look in detail how a session is build up or what goes wrong.

 

There one thing bothering me on your routing table. The default route is on the managment network, Isn't there a connection to the internet or other default gateway?

 

Thanks Screenie

 

 

Can I debug entire range? I can't debug just 1 IP address since i'm using a load generator that sends from entire range (client) to 1 IP address (Server)

 

this machine is not going to the internet it's internal machine in a QA lab

 

 

But I ran a debug on 1 IP just to see what's going on, and I saw many things there but can see any error or something else

 

 

What else can be done?

 

thanks

 

You can also run a snoop, but that's heavy on the cpu. If you run a snoop detail you can upload the output of get dbstream in a packet analyzer. Debuging on a range is not supported. You can however set a destination port with set ff and limit that way what you debug.