- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: VLAN HA Cluster error
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
VLAN HA Cluster error
We currently have a Check Point Cluster HA mode.
We made test Vlan in GAIA on both nodes (see pics) and assign virt IP in SmartConsole – after it one Cluster node change state to down. What do we wrong?Network
Error
Node 1
Node 2
Error
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Jerry
cphaprob -a if
equired interfaces: 5
Required secured interfaces: 1
eth1 UP non sync(non secured), multicast
eth2 UP non sync(non secured), multicast
eth4 UP non sync(non secured), multicast
eth5 UP sync(secured), multicast
Mgmt Disconnected non sync(non secured), multicast
eth3 DOWN (86.3 secs) non sync(non secured), multicast (eth3.2 )
Virtual cluster interfaces: 5
eth1 87.
eth2 192.
eth3 192.
eth4 198.
eth3.2 10.10.2.254
cphaprob stat
Number Unique Address Assigned Load State
1 (local) 3.3.3.1 0% Down
2 3.3.3.2 100% Active Attention
Local member is in current state since Tue Mar 26 15:10:17 2019
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does basic connectivity actually work on interface eth3.2? Is there at least one other pingable IP address on that network other than the cluster members themselves?
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Problem Notification table
------------------------------------------------
|Name |Status|Priority|Verified|Descr|
------------------------------------------------
|Synchronization|OK | 0| 7394| |
|Filter |OK | 0| 7393| |
|routed |OK | 0| 7392| |
|cphad |OK | 0| 352513| |
|fwd |OK | 0| 352507| |
------------------------------------------------
as well as that one:
Product name: High Availability
Major version: 6
Minor version: 0
Service pack: 4
Version string: N/A
Status code: 0
Status short: OK
Status long: Refer to the Notification and Interfaces tables for information about the problem
HA installed: 1
Working mode: High Availability (Active Up)
HA protocol version: 2
HA started: yes
HA state: active
HA identifier: 1
---
compare to yours after doing
cpstat ha -f all | grep -v eth
and see you match the issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
if PRI is 3.3.31 and SEC is 3.3.3.2 I presume tere isn't any VIP on that INT done by the object Network Management section?
ps. you need more than 1 Sync interface for the ClusterXL to work and I guess when eth3 DOWN and NON-SYNC is that one part of the Cluster is only DOWN another is UP am I correct?
I guess the whole ClusterXL setup seem little bit twisted here to be honest.
what happends when you do cphaprob syncstat / ldstat? paste it here pls.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Jerry wrote:
your SYNC int's are 3.3.3.1 and 2 - are they really eth5 ? have you checked the subnet mask of eth5?
if PRI is 3.3.31 and SEC is 3.3.3.2 I presume tere isn't any VIP on that INT done by the object Network Management section?
ps. you need more than 1 Sync interface for the ClusterXL to work and I guess when eth3 DOWN and NON-SYNC is that one part of the Cluster is only DOWN another is UP am I correct?
I guess the whole ClusterXL setup seem little bit twisted here to be honest.
what happends when you do cphaprob syncstat / ldstat? paste it here pls.
Jerry, yes 3.3.3.1 and 3.3.3.2 realy eth5.
Our Cluster HA is work well untill we not make a VLAN.
After VLAN was created - one node is down and another is UP - you are right.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
cphaprob -l list
cpstat ha -f all | grep -v eth ----> (mask IP's first) the important part is:
"Problem Notification table"
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have assigned an IP address for physical interface eth3. You are trying to add new VLAN on eth3? What is the point here? Such a configuration is not allowed.
Jozko Mrkvicka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Jozko
Today I'll try your solution to do.
I'll back after trying.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So I'm back.
We've resolved our VLAN issue.
The problem was in Cisco port configuration. In our case – ports were configured as NATIVE VLAN mode. After we changed port mode to Hybrid – all works fine.
According sk88700 – no matter have you assigned an IP address for physical interface or not – it works fine if VLAN port on network equipment configured properly .
Thanks everyone for help
