During a Maestro deployment, an Uplink or Management port may remain down even with the cable connected.
Before concluding that the transceiver is faulty, check the interface’s Security Group assignment and provisioning status. In Maestro, the availability of these ports also depends on the environment’s configuration.
Physical connectivity, provisioning, and forwarding
The behavior described in the training material is that Uplink and Management ports must be provisioned in a Security Group to establish a link under normal conditions. A port removed from all Security Groups may also lose its link, even though it remains physically connected.
Downlinks serve a different purpose: they provide connectivity to appliances and enable their discovery. Therefore, an UP Downlink does not prove that the Security Group is ready to process traffic.
When troubleshooting, separate these checks:
| Check |
Question to answer |
| Administrative state |
Is the port enabled? |
| Operational state |
Is the physical link established? |
| Assignment and provisioning |
Does the interface belong to the correct Security Group, and has the configuration been applied? |
| Forwarding |
Are the Security Group and its interfaces ready to carry traffic? |
Start with the MHO
On the Orchestrator, in Gaia Clish or Expert mode:
orch_stat -p
orch_stat -t
orch_stat -L
Use the port view to identify interface state and mapping, the topology view to correlate objects, and LLDP to verify discovered appliances and their connected ports.
LLDP confirms appliance discovery, but it does not prove that production traffic is flowing.
Next, in Gaia Clish on the MHO, inspect the specific port:
show maestro port <Port-ID> type
show maestro port <Port-ID> admin-state
show maestro port <Port-ID> qsfp-mode
show maestro port <Port-ID> auto-negotiation
show maestro port <Port-ID> optic-info
show maestro port <Port-ID> optic-info-details
These queries help correlate the port type, administrative state, configured speed, and transceiver information. Available optical diagnostics depend on the installed module.
The port identifier uses this format:
<Orchestrator-ID>/<Port-Label>/<Split-ID>
Select the actual port using TAB completion. For breakout connections, the subport is part of the identifier.
Check Link State Propagation too
If LSP is configured, a port may go DOWN because another port in the same LSP group has failed. This mechanism allows connected switches to stop forwarding traffic toward a compromised path.
In Gaia Clish on the MHO:
show maestro lsp configuration all
show maestro lsp status
Correlate the group configuration and status before attributing the failure to the port you are investigating.
What about admin-state up?
The following syntax is available:
set maestro port <Port-ID> admin-state up
However, administratively enabling a port does not prove that provisioning is complete or forwarding is functional. This command changes the configuration and should be used with a defined purpose, after checking the port assignment and potential impact on the environment.
My troubleshooting sequence would be: identify the port, check its state and type, validate assignment and provisioning, check LSP, and correlate the physical parameters at both ends.
The goal is to determine why the port is DOWN before trying to bring it UP.
