- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Migrating interface behind bond
- 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
Migrating interface behind bond
Hi there,
Although I found lots of posts around same or similar task, but I seem to struggle. I want to migrate one vlan (eth1) behind already existing bond.
R80.40 ClusterXL active/standby.
Interfaces:
eth1
bond0.10
bond0.20
- Standby - clusterXL_admin down
- Standby - remove IP from eth1
- Standby - add new vlan with IP behind bond (bond0.5)
- Smartconsole - update cluster object so that new interface is reflected in configuration
- Smartconsole - Push policy
- Standby - clusterXL_admin up <<------ keeps down with following error:
Setting member to normal operation ...
Member current state is DOWN
Operation failed: member is still down, please run 'show cluster members pnotes problem' in clish or 'cphaprob list' in expert mode for further details
Now the problem seems to be the difference between the number of monitored interfaces.
Standby tells "Required interfaces 3" and I have following in the list: bond0.10; bond0.20; sync
Active tells "Required interfaces 4" and I have following in the list: eth1; bond0.10; bond0.20; sync
I know about sk92826, but this would only affect the number of vlans monitored behind bond.
How do I failover when standby doesn't join the cluster? Is there a way to temporarily disable monitoring for eth1?
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ClusterXL requires ALL members to be configured identically to work (including interface configuration).
This activity inherently breaks that assumption and clustering won't work until the differences are corrected.
Which means failover won't be possible in the current state.
Further, I don't see how disabling monitoring on eth1 will help since you'll have the same issue when bond0.xx comes online.
Bottom line: this activity must be done in a maintenance window.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ClusterXL requires ALL members to be configured identically to work (including interface configuration).
This activity inherently breaks that assumption and clustering won't work until the differences are corrected.
Which means failover won't be possible in the current state.
Further, I don't see how disabling monitoring on eth1 will help since you'll have the same issue when bond0.xx comes online.
Bottom line: this activity must be done in a maintenance window.
