Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
abihsot__
Advisor
Jump to solution

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?

 

 

 

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

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.

View solution in original post

0 Kudos
1 Reply
PhoneBoy
Admin
Admin

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events