Active/Active traffic log.

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Active/Active traffic log.

L4 Transporter


I knew session owner generate traffic log.

Does session setup device generated traffic log  If a session is denied L4 processing before L7 processing???

Network Diagram

Router#1(Power-OFF) ------ Router#2(Power ON)

            |                                       |

          FW#1                               FW#2

           |                                       |

         BB#1                                BB#2

*Router#1 has problem. So It is power-off status.

FW configuration

Session owner : first-packet

Session setup : ip-modulo

rule01 on security rule : source zone = untrust , source IP = any , destination zone = trust , destination IP = , service = any , application = any , action = deny.

If rule01 actions is allow, there are rule01 traffic logs in only FW#2 because is session owner. Of course, session setup is load-sharing between FW#1 and FW#2.

But rule01 action is deny and I have seen there are denied traffic logs in all FWs. So I think session setup device can generate traffic logs.

Is it TRUE?? Please anybody know me!


Some traffics go to FW#1 through FW#2 and across HA3 Link for session setup.

Another traffics stay FW#2 for session setup.

But these traffics are denied by rule01 during L4 processing before L7 processing.

So There are denied traffic logs in all FWs.



L3 Networker


Logging on both devices in A/A when traffic is denied due to L4 to L7 processing is expected behavior.

Here's a simple flow of events to help you understand the logic behind this behavior:

1. First packet comes in on Primary device for instance. Primary is session owner (First packet) and Secondary is chosen for setup (IP modulo)

2. Secondary sets up the session (L1-L3) while Primary does the L4-L7 processing

3. At this point, this same session is represented by unique session IDs, one on the Primary and another on the Secondary

4. If the Primary device decides to discard the session based on its L4-L7 processing, then both session IDs on both devices need to be in the DISCARD state

5. After these discard sessions time out, each device needs to log the action of its respective session in its traffic logs

Note that the logic is a little different if the security policy permits the traffic.

In this case, only session owner logs the traffic because it's the device that is "responsible" for the session and its traffic.

When the policy is deny, no traffic really goes through the pair and so both devices have to log why neither of them allowed the session to live.



Thanks, taonibare.

I have more questions.

1. When primary device receives first packet, primary device copy first packet then send it to secondary device on HA3 link. Right?

2. I know until now that session owner is only L7 processing and session setup is L1 ~ L4 processing. Do I know incorrect it?

3. There are denied traffic log in both devices. It is same session ID. Right?


KC Lee


1. That is correct, provided packet forwarding is enabled.

2. This is correct as well.

3. Unfortunately, the actual session ID will be different for each firewall.


Thanks cstancill,

Each device(primary and secondary) has different denied log not same log.

For example, Primary device has 'A' session denied log but secondary device doesn't have it.

Secondary device has 'B' session denied log but primary device doesn't.

I think that only session setup device has denied log.

What do you think it?




    Sorry for the delayed response. For denied logs, you are correct.


Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!