- CheckMates
- :
- Products
- :
- Quantum
- :
- Maestro Masters
- :
- Maestro basic setup documentation
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maestro basic setup documentation
Hey guys,
I've been playing around with some Maestro units and a number of gateways. I have been running into a number of problems that caused me to document all the actions that I needed to do for a specific type of installation, the document is about 3 different scenario's:
- Single site dual Maestro
- Dual site single Maestro
- Dual Site dual Maestro
Please check out the document and let me know what you think about it, also if you see things that you don't understand or know that should be different, please let me know.
Updated the document to v1.0, 16 dec 2019.
Updated the document to v1.2, 26 Feb. 2020. Added bonding.
Updated the document to v1.3, 03 Mar. 2020. updated some parts and added commands.
Updated the document to v1.5, 17 Mar. 2020. updated some parts and added commands after training.
Updated the document to v1.6, 25 May 2020. Update regarding HA licenses
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Lari,
I'm fully agree with what you said, but unfortunately in my case the management server is located remotely. That means I have to manage SG via it's public IP. Initially I configured LOM interfaces to be part of the same subnet which is part of the management interfaces, but after I learnt they can't be reached via VPN I had to move them behind data interfaces.
I was interested for the cases like mine, where the management server is located remotely, what is the purpose of dedicated management interfaces, but as Anatoly mentioned I just can't move on with FTW without them.
So here is my case with example - I have magg0 interface on MHO and SG, which is part of VLAN100 10.100.1.0/24.
SG1 - 10.100.1.1
MHO - 10.100.1.10 - GW: SG1
LOM1 - 10.100.1.11 - GW: SG1
LOM2 - 10.100.1.12 - GW: SG1
10.100.1.0/24 is part of VPN encryption domain and I wanted MHO, LOM1 and LOM2 to be reachable via VPN, but after this is not possible I had to move them to a separate VLAN which is part of data interfaces.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello all,
we have 1xMHO-140 with 2x6000 appliances connected to it. With this setup we could have only one security group, so I'm wondering what is the best approach for upgrade both appliances with the latest JHF? According link below we should divide them into logical groups, but I think this approach is fine when you have more than one MHO.
As far as I can understand I have to proceed with the following commands:
g_clusterXL_admin –b 1_02 down
and in gclish:
installer import local <full path to jhf.tgz>
installer install 1 member_ids 1_02
After the secondary member is upgraded I have to the same with the primary one (SMO). Is that fine?
Is there a difference if I don't use the global approach with gclish and just go to the secondary member and type:
clusterXL_admin down
and in clish:
installer import local <full path to jhf.tgz>
installer install 1
and then do the same with the primary member.
What about if we need to upgrade to major version - for instance from R80.20SP to R80.30SP? What is the best approach in that case?
Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can still upgrade the gateways one at a time. MHO and SG can run different takes. Since you have only one MHO, upgrading it will cause an outage due to reboot so plan a maintenance window for the MHO upgrade.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did the upgrade with:
g_clusterXL_admin -b 1_02 down
installer install 1 member_ids 1_02
g_clusterXL_admin -b 1_01 down
installer install 1 member_ids 1_01
But I'm still wondering what will happen when I have to upgrade from R80.20SP to R80.30SP.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Upgrade from R80.20SP to R80.30SP is not supported, because there are versions for different appliances. Appliances which works with R80.20SP are not supporting R80.30SP (except 23K), and newer appliance which support R80.30SP does not work with R80.20SP
Thank you,
Anatoly
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Anatoly! This is something new for me and I didn't expect it. So it seems from the whole 6000 series only 6500 and 6800 don't support R80.30SP. This is curious...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's correct. All newer quantum appliances require R80.30SP. The next version R81SP will be supported on all appliances (older and newer ones)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see. I just expected R80.30SP will be released also for 6500 in future, but it seems this is not the case. Thank you for your clarification!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quick question. We have 2 MHO-140s and 2 gateways with a single SG running on R80.20SP Take 279. We are using both eth1/1/1 (eth1- Mgmt1) and eth2/1/1 (eth1-Mgmt2) for management connectivity, however, we don't have a bond setup. Only eth1- Mgmt1 has the IP configured which we establish SIC with. We intend to bond them and from what I understand, LACP is not supported? Do I need to configure MAGG or just a regular bond (Active-Backup or XOR)? All of the data ports are configured with LACP without issues.
eth1/1/1 (eth1- Mgmt1) is used as the internal interface of our FW cluster, I presume it is fine functioning as a data port?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You'll need to configure MAGG in either active/backup or XOR mode. You cannot use management ports for data traffic because there is no distribution or correction on those ports.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Lari, thanks for your reply. I stand corrected, eth1/1/1 (eth1- Mgmt1) is not used as the internal interface of our FW cluster and configured as the default 'management' port type. There is no data traffic, it is purely used for managing the SMO.
We will configure MAGG using both eth1/1/1 (eth1- Mgmt1) and eth2/1/1 (eth1-Mgmt2) interfaces from each MHO. I take it a breakout cable is not required since we have only a single Security Group.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is there any diagrams to support the setup doc? I've started to create my own, which is layered (May be totally wrong but I need a logical starting point)
Diagram for management/Sync/LOM connectivity.
Diagram for Data connectivity.
My objective is to setup dual MHO's in a Dual Site (x2 MHO's per site) scenario where SGMs span both sites. Each SG would run VSX allowing me to have active/active in both sites.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is always nice to see that the work I have put into this document is copied into an SK .
Just a pitty that there are no pointers into additional configuration like adding a management bond and such things.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Happy to send you the Visio I created. It's split into three tabs, MGMT, DATA & SYNC, showing layer 1 connectivity.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Marten,
can you kindly clarify in One Site-Dual MHO setup if it requires following points:
- Start to work with only ONE MHO and ONE GW plugged
- Set orchestrator amount to 1
is this strictly suggested/needed?
I performed two MHO-Single site setup recently; first one ok without changing site amount and both MHOs and both GW in SG. Anyway, one MHO is not anymore reacheable by https (connection refused) but only with ssh/ping.
Second one a disaster: configuration from Orchestrator not pushed (gw it doesn't reboot); try to change amount to 1 and then revert back to 2 but one MHO (with SG configured) pulled configuration from other MHO added secondly after a factory reset (so, without any SG configuration). This remembered me Fortigate cluster and its override functionality
So my other question, how to avoid member-id-1 overwriting? i wanna be sure that i configure one MHO and it remains the main MHO for SG changes/adding.
thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey there,
Orchestrator-amount is 2 by default. If you have only one MHO, change it to 1. Otherwise don't need to touch it. This is per site setting so if you have a dual site with two MHOs on both sites, then keep the amount as 2.

- « Previous
- Next »