Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Danny
Champion Champion
Champion

SSH to Maestro SMO Master

I have two Maestro dual-site setups that are configured very similarly. When I connect to the security group on the first Maestro setup, I always end up on the SMO Master (sg-ch01-01: 192.0.2.1), but on the other Maestro setup I always end up on sg-ch01-02: 192.0.2.2. What could be the reason for this?

@Lari_Luoma @Anatoly @Tom_Kendrick @Laszlo_Csosza @Jochen_Hoechner 

0 Kudos
12 Replies
Dario_Perez
Employee Employee
Employee

run lldpctl and make sure the port for MHO should be Bpeth1-01/1-03, if is pair 02 or 03 is an issue. 

0 Kudos
emmap
Employee
Employee

Which interface are you SSH'ing into? 

0 Kudos
Martin_Raska
Advisor
Advisor

or member 192.0.2.1 is down and is not SMO, or 192.0.2.1 is not provisioned and your SMO is 192.0.2.2

or HW chaned, we have ti like this

1 - old 6500 decomisioned, IP free

2 - old 6500 decomisioned but replaced with 9100

3 - was free, provisioned second 9100

4

0 Kudos
Danny
Champion Champion
Champion

Hi @Dario_Perez , @emmap , @Martin_Raska ,

I'm connecting to the magg0 interface and IP of both SG's. No hardware was changed.
Orchestrators are MHO-175. 
image.png
maestro2:

SSH > You have logged into the system.

[Expert@sg-ch01-02:0]# asg_blade_config get_smo_ip | tr -d '\n';echo -n ' ('; egrep $(gexec -t -a|tr ',' '|')[[:space:]] /etc/hosts|grep $(asg_blade_config get_smo_ip|awk '{print $NF}')|awk '{print $NF}'|tr -d '\n';echo ')'
[Fri Sep 26 14:41:13 CEST 2025 | 192.0.2.2] SMO ip is: 192.0.2.1 (1_012_01)

[Expert@sg-ch01-02:0]# asg monitor
-------------------------------------------------------------------------------- | System Status - Maestro | -------------------------------------------------------------------------------- | Chassis Mode | Primary Up (1 2) | | SGMs | 4 / 4 | | Version | R81.20 | -------------------------------------------------------------------------------- | SGM ID Chassis 1 Chassis 2 | | ACTIVE STANDBY | -------------------------------------------------------------------------------- | 1 ACTIVE ACTIVE | | 2 ACTIVE ACTIVE | -------------------------------------------------------------------------------- | Chassis HA mode: Primary Up | --------------------------------------------------------------------------------

maestro1:

SSH > You have logged into the system.
[Expert@sg-ch01-01:0]# asg_blade_config get_smo_ip | tr -d '\n';echo -n ' ('; egrep $(gexec -t -a|tr ',' '|')[[:space:]] /etc/hosts|grep $(asg_blade_config get_smo_ip|awk '{print $NF}')|awk '{print $NF}'|tr -d '\n';echo ')' [Fri Sep 26 14:57:31 CEST 2025 | 192.0.2.1] SMO ip is: 192.0.2.1 (1_012_022_01) [Expert@sg-ch01-01:0]# asg monitor -------------------------------------------------------------------------------- | System Status - Maestro | -------------------------------------------------------------------------------- | Chassis Mode | Primary Up (1 2) | | SGMs | 6 / 6 | | Version | R81.20 | -------------------------------------------------------------------------------- | SGM ID Chassis 1 Chassis 2 | | ACTIVE STANDBY | -------------------------------------------------------------------------------- | 1 ACTIVE ACTIVE | | 2 ACTIVE ACTIVE | | 3 ACTIVE ACTIVE | -------------------------------------------------------------------------------- | Chassis HA mode: Primary Up | --------------------------------------------------------------------------------

 

0 Kudos
Anatoly
Employee
Employee

Hi,

You can run asg stat -i tasks from each security group and you will see the real SMO

0 Kudos
Danny
Champion Champion
Champion

Hi @Anatoly,

asg stat -i tasks looks almost identical on maestro2 and maestro1, but I'm still getting logged in to SGM2 when I connect to the sg of maestro2.

maestro2:

SSH > You have logged into the system.

[Expert@sg-ch01-02:0]# asg stat -i tasks
--------------------------------------------------------------------------------
| Task (Task ID)     |        Chassis 1           |        Chassis 2           |
--------------------------------------------------------------------------------
| SMO (0)            |         1                  |                            |
| General (1)        |         1                  |         1                  |
| LACP (2)           |         1                  |         1                  |
| CH Monitor (3)     |         1                  |         1                  |
| DR Manager (4)     |         1                  |                            |
| UIPC (5)           |         1                  |         1                  |
| Alert (6)          |         1                  |                            |
--------------------------------------------------------------------------------

[Expert@sg-ch01-02:0]# echo $CPHA_SMO
1

maestro1:

SSH > You have logged into the system.

[Expert@sg-ch01-01:0]# asg stat -i tasks
--------------------------------------------------------------------------------
| Task (Task ID)     |        Chassis 1           |        Chassis 2           |
--------------------------------------------------------------------------------
| SMO (0)            |         1(local)           |                            |
| General (1)        |         1(local)           |         1                  |
| LACP (2)           |         1(local)           |         1                  |
| CH Monitor (3)     |         1(local)           |         1                  |
| DR Manager (4)     |         1(local)           |                            |
| UIPC (5)           |         1(local)           |         1                  |
| Alert (6)          |         1(local)           |                            |
--------------------------------------------------------------------------------

[Expert@sg-ch01-01:0]# echo $CPHA_SMO
1

 

0 Kudos
Anatoly
Employee
Employee

It mean that everything is OK with SMO and this is SGM #1. You get into another SGM, because your connection pass distribution. And it might happen for one of 2 reasons: 

1. You access to management IP not from management network

2. You applied sk179005 and then traffic on management network will be distributed regardless the SMO

Danny
Champion Champion
Champion

Hi @Anatoly, thanks for your reply.

  1. Both Maestro environments were configured with a Magg interface, and I access it via a data interface.
  2. Regarding sk179005, the feature should be on by default, as my two Maestro environments run on R81.20.

    maestro2:
[Expert@sg-ch01-02:0]# g_fw -a ctl get int fwha_data_mgmt_connection
-*- 4 blades: 1_01 1_02 2_01 2_02 -*-
fwha_data_mgmt_connection = 1

maestro1:

[Expert@sg-ch01-01:0]# g_fw -a ctl get int fwha_data_mgmt_connection
-*- 6 blades: 1_01 1_02 1_03 2_01 2_02 2_03 -*-
fwha_data_mgmt_connection = 1


Looks like sk179005 needs a fix, as it says:
"In a 
 Dual-Site environment with three Security Group Members on each Site. the active Security Group Members are:

  • 1_1 (SMO), 1_3, 1_4 (Active Site)"

It should correctly say:

  • 1_1 (SMO), 1_2, 1_3 (Active Site)
0 Kudos
Anatoly
Employee
Employee

this is just an example. If you had security group of 4 members, and you excluded 1_2, the rest won't be renumbered: 1_1,1_3 and 1_4

0 Kudos
Danny
Champion Champion
Champion

@Anatoly, thanks for explaining.

Is it important that the Main IP, as shown at the security group object in SmartConsole, matches the management IP address of Gaia management interface > magg0 ?

image.png

image.png

0 Kudos
Anatoly
Employee
Employee

Like regular GW, I think it will work even if it doesn't match

0 Kudos
Danny
Champion Champion
Champion

@Anatoly. I understand. It is a best practice, not a requirement.

FYI: If the Main IP doesn't match the Gaia management interface IP, tools like this will fail, because $FWDIR/state/local/FW1/local.set and /etc/hosts don't have a match for the gateway object.

Key Considerations


Main IP in SmartConsole:

  • This is the IP used for Secure Internal Communication (SIC) between the Security Management Server and the gateway.
  • It should be reachable from the management server and typically corresponds to the interface used for management traffic.

Gaia Management Interface IP:

  • This is the IP address used to access the Gaia Portal or CLI for system-level configuration.
  • It may be on a different interface than the one used for SIC or policy installation.

Best Practice

Ideally, the Main IP in SmartConsole should match the IP of the interface used for management access, which is often the same as the Gaia management interface.

However, if your gateway has multiple interfaces and you manage it through a different one (e.g., internal vs external), the Main IP can be set to whichever interface is used for SIC and policy pushes.

Important Notes

If you change the Main IP in SmartConsole, you’ll need to:

  • Reset and re-establish SIC
  • Possibly renew VPN certificates
  • Reinstall policies to ensure proper communication
0 Kudos