Security Gateway dropped some packets

[tepeeeeei]

Dear Team,

Hello,

We are implementing ClusterXL and Management High Availability.
We have also activated Anti-Spoofing.
A diagram of the network infrastructure is displayed below.

Under these conditions, the Security Gateway is dropping the following packets:

i1&i2 -> Management NW network address (4th octet 0), UDP/8116
i1&i2 -> 239.255.255.250, UDP/1900
m3&m4 -> m1&m2, TCP/45112 TCP/53393

The cluster configuration appears to be functioning correctly, as indicated by SmartConsole or the output of the "show cluster state" command.
It is effectively executing failover procedures even after simulating failures, such as shutting down the active SG.

(Question 1) Is there an issue with this current setup?
(Question 2) If there is an issue, what steps should be taken to resolve it (e.g. implementing additional firewall policies)?

[_Val_]

What do the drop log entries say?

[tepeeeeei]

Thank you for reply, he said

- i1&i2 -> Management NW network address (4th octet 0), UDP/8116
  -  by rule (All DENY)

- i1&i2 -> 239.255.255.250, UDP/1900
  - IP multicast routing failed (missing OS route)

- m3&m4 -> m1&m2, TCP/45112 TCP/53393
  - TCP packet out of state: TCP packet out of state
  - TCP Flags: PUSH-ACK

[_Val_]

So, some answers:

1. UDP 8116 is CCP traffic. CCP is used to monitor cluster functionality. It is not okay that CCP from NW network is leaking to i1/2/3 network. Check your router does not forward broadcast between network. If it does, see how to remove that. The issue 1 is only cosmetic, not a matter of concern though.

2. Not clear if this is indeed a multicast, and where it comes from. Not related to setup, I believe. 

3. Those are high ports, some reply to TCP traffic. Show more details, especially the source ports for each, to determine the application sending this traffic.

[tepeeeeei]

1. understood that it is a network problem, not Quantum.
2. I don't particularly care about it.
3．The source port was 257.
  It seems to be a return communication of log transmission.
  Since I am receiving logs correctly under normal circumstances, this did not seem to be a problem either.

Thank you very much for your answer!