Bonding on Maestro - dual orchestrators - single site

[Gary_Atchley]

Installed release r81.10, with JHF 55, R&D private fix for GRE on Maestro environment

Trying to follow Maestro basic setup v1.6, CP_Quantum Maestro Getting Started Guide, sk170294,etc,etc

From what I have found it is recommended that you should configure bonding for uplinks. We have regular interfaces, interface with VLANs and GRE interfaces. This is a migration from an R81 Cluster environment to the Maestro environment. We understand that we will be using the old VIP IP addresses for all but the GRE interfaces. I believe the switches will need to bond these interfaces as well on the network side.

Question 1: Is it best practice to bond all the uplink interfaces? If not, what is and where is it explained?

Question 2: On the VLAN interfaces would we create the bond on the VLAN interfaces (MHO-1 - eth1-8.1620 and eth1-8.1632; MHO-2 - eth2-8.1620 and eth2-8.1632), I see these VLAN's on the Maestro WebUI by hovering mouse over the gateway

Question 3: We have GRE interfaces configured on these, but not sure how to do the bonding for these.

Question 4: Are the bonding groups unique to the SG where they are configured? I.E., Could we have the mgmt bonding group be 0 on multiple SGs where we would end up with magg0 on any SG and it would not be associated with any of the other SGs? Or would it be recommended for them to be different? We originally were going to use the SG#, so we would end up with magg1 and magg2.

[Wolfgang]

@Gary_Atchley I'll try to answer your questions.

Question 1: Is it best practice to bond all the uplink interfaces? If not, what is and where is it explained?

>> Yes. For redundancy and bandwidth you should use BOND interface. You can group your physical interfaces to BONDs like one BOND for external, one for internal and another for DMZ.

Question 2: On the VLAN interfaces would we create the bond on the VLAN interfaces (MHO-1 - eth1-8.1620 and eth1-8.1632; MHO-2 - eth2-8.1620 and eth2-8.1632), I see these VLAN's on the Maestro WebUI by hovering mouse over the gateway.

>> The bonds are created in the SG, on top of them you can configure your VLAN interfaces. No BOND or VLAN configuration on the MHO will be needed for your uplinks.

Question 3: We have GRE interfaces configured on these, but not sure how to do the bonding for these.

>> Same like Question 2. GRE on top of your BOND.

Question 4: Are the bonding groups unique to the SG where they are configured? I.E., Could we have the mgmt bonding group be 0 on multiple SGs where we would end up with magg0 on any SG and it would not be associated with any of the other SGs? Or would it be recommended for them to be different? We originally were going to use the SG#, so we would end up with magg1 and magg2

>> The behaviour of a BOND for magg and uplinks will be different. For magg bond you can share them between different SG but some limitations exist. See Configuring Bond Interface on the Management Ports and Mastro Mgmt Bond (magg) - dual Orchestrator and multiple Security Groups For uplink BONDs you can share them between different SGs see Shared Uplink Ports 

[Peter_Bors1]

Q1: Bonding is definitely recommended, otherwise you'll most probably need some dynamic routing to provide redundancy.

Be aware that you have to major types of bonds:

- active-active: you'll need multi-chassis ether-channel support on the switches (VPC, VSS, MLAG, etc)

- active-backup: functions very similarly to cluster interfaces, less configuration is needed on the switches. Very important to define the primary interface of the bond, so all the SGMs are on the same page

Q2: Basically you create the bonds, and from there on you'll use the bond as a normal interface (e.g. assign IP, add VLAN, etc)

Q3: Unsure about GRE, but I'd try the same way as with a normal interface, but with the bondx.y

Q4: Yes, the bonding happens on the SGMs, so you should configure it for the SG. I believe the magg must be magg99. If you have the necessary connectivity, I'd dedicate physical mgmt ports to given SG (ethx-Mgmt1 to SG1, ethx-Mgmt2 to SG2, etc), just for the sake of future-proofness and flexibility. (Of course it won't work if you have more than 4 SGs on MHO140, in that case you'll need to share the physical interfaces between the SGs)