After standby SIC initialized CLUSTERXL showing down

[praveend]

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 ,

[funkylicious]

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 ?

[PhoneBoy]

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

[praveend]

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

[PhoneBoy]

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

[praveend]

R77.20

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

Thank you

[PhoneBoy]

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

[praveend]

yes firewall is end of support and without checkpoint support .

[_Val_]

Push policy, and check cluster status again.

[praveend]

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 ?

[network360 · Accepted solution]

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

[praveend]

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