Checkpoint : Finding memory Leak

A memory leak, technically, is an ever-increasing usage of memory by an application.

With common desktop applications, this may go unnoticed, because a process typically frees any memory it has used when you close the application.

However, In the client/server model, memory leakage is a serious issue, because applications are expected to be available 24×7. Applications must not continue to increase their memory usage indefinitely, because this can cause serious issues. To monitor such memory leaks, we can use the following commands.
[Expert@splat]# ps -aux | sort -k5 -n | tail -5
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
root 30912 0.0 2.6 213348 55644 ? Sl 2011 0:07 in.aclientd 259
root 3783 0.0 2.6 213352 55544 ? Sl 2011 0:08 in.asessiond 0
root 30659 0.0 2.6 213436 55768 ? Sl 2011 0:08 in.ahclientd 900
root 3784 0.0 2.7 214356 56572 ? Sl 2011 0:09 in.aufpd 0
root 3504 0.0 3.1 414212 65168 ? Ssl 2011 24:32 fwd

In the above ps command, –sort option outputs the highest %MEM at bottom. Just note down the PID for the highest %MEM usage. Then use ps command to view all the details about this process id, and monitor the change over time. You had to manually repeat ir or put it as a cron to a file.

[Expert@splat1]# ps -ev 3504
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
3504 ? Ssl 24:32 22 78 414133 65168 3.1 fwd PPKDIR=/opt/CPppak-R70 CPMDIR=/opt/CPsuite-R70/fw1 CONSOLE=/dev/console TERM=linux SUDIR=/opt/C

[Expert@splat1]# ps -ev 3504
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
3504 ? Ssl 24:32 22 78 414133 65168 3.1 fwd PPKDIR=/opt/CPppak-R70 CPMDIR=/opt/CPsuite-R70/fw1 CONSOLE=/dev/console TERM=linux SUDIR=/opt/C

Note: In the above output, if RSS (resident set size, in KB) increases over time (so would %MEM), it may indicate a memory leak in the application.

Checkpoint : State Syncronization Guide

To reduce or eliminate these error messages verify that you followed the below recomendations:

• Sync network needs to be dedicated to synchronization only. It is not recommended to run VRRP or IPSO Cluster on sync interfaces (refer to sk39179).
• Sync interfaces should be configured as a non-ADP interfaces.
• Synchronization interfaces should be the same speed or faster than the fastest interface on the VRRP or IPSO Cluster. However, this recommendation is impractical when 10 gigabit interfaces are employed. In practice, no more than 2 gigabits of throughput is needed for sync traffic on IPSO Appliances. This means a pair of non-ADP gigabit Ethernet interfaces will be sufficient, though in many cases a single gigabit Ethernet interface will suffice.
• It is recommended to use a dedicated VLAN on a switch, for Check Point sync traffic from a single cluster only i.e. you should not mix CP sync traffic from other cluster members across this dedicated VLAN. Use of cross-over cable is also supported in a 2-node cluster. Choosing to use a switch or a cross-over cable for CP Sync traffic is a environment preference.
• For VRRP only - disable synchronization for certain services. This will help stabilize the systems because:
1. Less memory will be demanded by the sync process. You already saw some related messages in the fwd.elg about sync buffers being full.
2. This will release the CPU time.

The HTTP, HTTPS and DNS services are good candidates to be taken out of synchronization. Because of their nature, they are not affected on a fail over scenario without synchronization.

• The following limitations are applicable for state synchronization over wide area network:
1. The synchronization network must guarantee no more than 100ms latency and no more than 5% packet loss.
2. The synchronization network may only include switches and hubs. No routers are allowed on the synchronization network, because routers will drop Cluster Control Protocol (CCP) packets . CCP is either Multicast or Broadcast and thus non-routable.
• If IP cluster is configured between two IPSO Appliances located in two different cities, CCP and VRRP advertisements need to be update quite frequently. Any latency can cause both cluster members to behave abnormally. Also, if there is a break in the WAN link, both will become master, which can also cause problems.
  The solution is to ensure minimal latency between the cluster members and a highly reliable link.

Checkpoint - IPSO - Memory Usage

In Voyager Monitor option select CPU and Memory Utilization . This gives you the Total Real Memory, Active Real Memory and the Free Memory available on the appliance.

For console access use clish to display the Real Memory Used. This value is displayed in terms of percentage value.

ipso[admin]# clish

clish:1> show useful-stats



Components Total

Active Routes 4

Packets Forwarded 0

VRRP Masters 0

Real Memory Used 22%

Disk Capacity 11%

Note: The real physical memory output gathered from Voyager is taken from the kernel directly.

F5 : Bigip Platform Naming Conversion

Supported platforms

This installation method is supported only on the following platforms:

• BIG-IP 520 and 540 (D35)
• BIG-IP 1000 (C36)
• BIG-IP 1500 (C36)
• BIG-IP 1600 (C102)
• BIG-IP 2400 (D44)
• BIG-IP 3400 (C62)
• BIG-IP 3410 (C100)
• BIG-IP 3600 (C103)
• BIG-IP 3900 (C106)
• BIG-IP 4100 (D46) (for standalone Application Security Manager installations)
• BIG-IP 5100 and 5110 (D51)
• BIG-IP 6400 (D63)
• BIG-IP 6800 (D68)
• BIG-IP 6900 (D68)
• BIG-IP 8400 (D84)
• BIG-IP 8800 (D88)
• BIG-IP 8900 (D106)

If you are unsure which platform you have, look at the sticker on the back of the chassis to find the platform number

CIsco ASA - FW priority and state

It has been sometime since I posted something related to ASA :),

How to see the FW status in a cluster?

Defenitely you can see this by running "show failover" but what if you dont have enable access.. Infact no way (Both Name in ASA will be same by default)

But following command can help you,

conf t#

prompt hostname context priority state

Now you will see the priority and state of FW along with the name., no need to be in enable mode :)

Checkpoint : Connection / NAT Tables

NAT Cache Table
-------------------

[Expert@GEHfiSJPhino11]# fw tab -t fwx_cache -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost fwx_cache 8116 7965 13295 0

NAT Table
-----------

[Expert@GEHfiSJPhino11]# fw tab -t fwx_alloc -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost fwx_alloc 8187 72 3460 0



Connection Table
-------------------
[Expert@GEHfiSJPhino11]# fw tab -t connections -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost connections 8158 14144 26665 56550

Checkpoint : SecureXL

When SecureXL is enabled, all traffic should be accelerated, except traffic that matches the following conditions:

• The first packets of any new TCP session, unless a "template" exists.
• The first packet of any new UDP session.
• All traffic that matches a service that uses a Resource.
• Certain traffic that matches a service that is inspected by a SmartDefence or Web Intelligence feature. For example, traffic on which SSH protections are activated is not accelerated. For more details, refer to sk42401: Factors that adversely affect performance in SecureXL.
• All traffic that is supposed to be dropped or rejected, according to the rule base.
• All traffic that matches a rule, whose source or destination is the Gateway itself.
• All traffic that matches a rule with a Security Server.
• All traffic that matches a rule with User Authentication or Session Authentication.
• Non-TCP/UDP/GRE/ESP traffic.
• All multicast traffic.
• All fragmented traffic.
• All traffic with IP options.
• RST packets, when the "Spoofed Reset Protection" feature is activated.
• When using ClusterXL in Load Sharing mode with 'Sticky Decision Function'.
• Traffic that violates stateful inspection paradigm, or that is suspected to be spoofed.
• IPv6 traffic

Connection establishment acceleration ("templates" mechanism)

In order to enhance connection establishment acceleration, a mechanism attempts to "group together" all connections that match a particular service and whose sole discriminating element is the Source Port. This type of "grouping" enables even the very first packets of a TCP handshake to be accelerated. This is very useful on short connections, in which the percentage of TCP handshake traffic is very high.

The very first packets of the first connection on the same service will be forwarded to the Security Gateway's kernel, which will then create a "template" of the connection and notify the SecureXL device. Any subsequent TCP establishments on the same service (where only the source port is different) will already be accelerated (as well as any other traffic, of course).

There are several conditions that will prevent a template from being created:

• Connections that cannot be discriminated ONLY by the source port cannot be templated.
• NATed traffic cannot be templated.
• VPN traffic cannot be templated.
• Complex connections (FTP, H323, etc.) cannot be templated.
• Non-TCP/Non-UDP traffic cannot be templated.
• The following rules will prevent a Connection Template from being created. All subsequent rules below such rules will not be templated as well, regardless of the rule. It is advised that all rules that can be templated, be placed at the top of the rule base (unless of course, this will violate other optimization considerations):
  
  • Rule with service 'Any'
  • Rule with a service that has a 'handler' (where a specific protocol is chosen in 'Protocol Type' field - instead of 'None' ; go to service object - right-click - Edit... - Advanced... - Protocol Type:).
  • Rules with the following objects:
    
    • Time object
    • Port range object
    • Dynamic object
  • Rules with "complex" services (i.e., services that have anything specified in the "Match" field, or "Enable reply from any port" of their "Advanced" section or Source Port is defined).
  • Rules with RPC/DCOM/DCE-RPC services.
  • Rules with Client Authentication or Session Authentication.
  • When SYN Defender or Small PMTU features are activated in SmartDefense/IPS