topic Re: After standby SIC initialized CLUSTERXL showing down in Firewall and Security Management

After standby SIC initialized CLUSTERXL showing down

praveend — Fri, 29 Oct 2021 12:33:41 GMT

its working setup - using ClusterXL Active/Standby mode .

Standby SIC was down

i reinitialized SIC after that on the SMS i can see both Gateways are up - But ClusterXL is down .

i started HA service - cphastart

Sync interface connection

FW1----eth1-03------eth1-03------FW2

FW1-Eth1-03 - ipaddress 1.1.1.1/30

FW2-Eth1-03 - ipaddress 1.1.1.2/30

After SIC initialized do i require any re-configuration for the ClusterXL .

when i did tcpdump on sync interface i can see that ARP is not resolving

arp who-has 1.1.1.1 tell 1.1.1.2 same for the FW2 also .

am not able to ping both sync ip address from respective Firewalls .

on the working/production Firewall i can see below output

Output of the cphaprob -a if command shows "Inbound: UP , Outbound: DOWN"

as per SK65560 communication issue related to outside , but switch side every think seems to good .

Do i need to do any more configuration or steps .

Thanks ,

Re: After standby SIC initialized CLUSTERXL showing down

funkylicious — Sun, 31 Oct 2021 14:25:48 GMT

Hi,

I recall having a similar issue when I received those routes from a routing protocol (eBGP)

Had to configure a route-map and deny/drop the routes from being installed in the RIB.

Can you check and see if you have any routes for them in the routing table ?

Re: After standby SIC initialized CLUSTERXL showing down

PhoneBoy — Mon, 01 Nov 2021 02:43:21 GMT

If you do a tcpdump on eth1-03, do you see traffic coming to/from the nodes?

Re: After standby SIC initialized CLUSTERXL showing down

praveend — Mon, 01 Nov 2021 04:23:36 GMT

TCP DUMP output it seems ARP not getting , but HA interface is connected properly externally

TCP DUMP

tcpdump -nni eth1-03
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1-03, link-type EN10MB (Ethernet), capture size 96 bytes
11:59:01.319908 IP 0.0.0.0.8116 > 10.X.X.128.8116: UDP, length 34
11:59:01.382188 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.382221 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 34
11:59:01.382233 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 32
11:59:01.382234 arp who-has 1.1.1.4 tell 1.1.1.1
11:59:01.382236 arp who-has 1.1.1.2 tell 1.1.1.1
11:59:01.382237 arp who-has 1.1.1.3 tell 1.1.1.1
11:59:01.382238 arp who-has 1.1.1.4 tell 1.1.1.1
11:59:01.382240 IP 1.1.1.1 > 0.0.0.0: ICMP echo request, id 0, seq 7, length 16
11:59:01.382242 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.382249 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.382257 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.482111 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.482150 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 32
11:59:01.482152 arp who-has 1.1.1.2 tell 1.1.1.1
11:59:01.482155 arp who-has 1.1.1.3 tell 1.1.1.1
11:59:01.482157 arp who-has 1.1.1.4 tell 1.1.1.1
11:59:01.482162 IP 1.1.1.1 > 0.0.0.0: ICMP echo request, id 0, seq 7, length 16
11:59:01.482164 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.482172 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 96
11:59:01.482180 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.519826 IP 0.0.0.0.8116 > 10.X.X.128.8116: UDP, length 34
11:59:01.582148 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.582191 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 34
11:59:01.582204 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 32
11:59:01.582207 arp who-has 1.1.1.2 tell 1.1.1.1
11:59:01.582208 arp who-has 1.1.1.3 tell 1.1.1.1
11:59:01.582211 arp who-has 1.1.1.4 tell 1.1.1.1
11:59:01.582212 arp who-has 1.1.1.2 tell 1.1.1.1
11:59:01.582214 IP 1.1.1.1 > 0.0.0.0: ICMP echo request, id 0, seq 7, length 16
11:59:01.582216 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.582227 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.582235 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.619817 IP 0.0.0.0.8116 > 10.X.X.128.8116: UDP, length 50
11:59:01.682084 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.682143 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 50
11:59:01.682154 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.682162 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.682169 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.719812 IP 0.0.0.0.8116 > 10.X.X.128.8116: UDP, length 34
11:59:01.782122 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.782157 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 34
11:59:01.782168 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.782176 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.782184 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.882130 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 40
11:59:01.882155 IP 0.0.0.0.8116 > 1.1.1.0.8116: UDP, length 32

Re: After standby SIC initialized CLUSTERXL showing down

PhoneBoy — Mon, 01 Nov 2021 04:29:43 GMT

What version/JHF level?
Did you actually push policy to the gateways?

Re: After standby SIC initialized CLUSTERXL showing down

praveend — Mon, 01 Nov 2021 05:12:29 GMT

R77.20

no i didn't push policy - because ClusterXL status was showing Down

Thank you

Re: After standby SIC initialized CLUSTERXL showing down

PhoneBoy — Mon, 01 Nov 2021 06:04:54 GMT

On what appliances?
Because unless you're running Embedded Gaia, R77.20 is End of Support.

Re: After standby SIC initialized CLUSTERXL showing down

_Val_ — Mon, 01 Nov 2021 16:16:37 GMT

Push policy, and check cluster status again.

Re: After standby SIC initialized CLUSTERXL showing down

praveend — Tue, 02 Nov 2021 01:33:01 GMT

yes firewall is end of support and without checkpoint support .

Re: After standby SIC initialized CLUSTERXL showing down

praveend — Tue, 02 Nov 2021 01:41:28 GMT

Cluster Status is showing down that's why i didn't push policy .

my doubt is below

1. Firewall Cluster is working properly

2. Standby Firewall SIC is reset

3.After SIC reset do we require to unload policy ?

Re: After standby SIC initialized CLUSTERXL showing down

network360 — Sun, 14 Nov 2021 04:44:41 GMT

After SIC reset no need to unload policy ,

please check below command and you will come to know the status of critical service

cphaprob list , cphaprob -l list and cpstat ha -f all

Re: After standby SIC initialized CLUSTERXL showing down

praveend — Sun, 28 Nov 2021 02:56:08 GMT

HI ,

Thank you Issue is fixed , cpstat ha -f all is very good command , in this command i got exact interface - which is failed , i can see that 3 interface down .

issue was in the core switch VLAN tagging was wrong .

once VLAN tagging is fixed and Sync Interface connected directly using straight UTP cable .

Thank You