A downstream FortiGate has been cabled to a root FortiGate and configured with the fabric settings to join the existing Security Fabric. Telemetry discovery is working and the downstream unit is visible to the root, but it remains in a pending state and its data is not trusted into the fabric. The administrator wants the downstream unit to become a full member. Which action on the root FortiGate completes the join?
- AEnable the FortiTelemetry discovery protocol on the root's downstream-facing interface, because authorisation happens automatically once telemetry packets are received.
- BAuthorise the pending downstream device from the Security Fabric settings or topology on the root FortiGate so the root explicitly trusts that serial number as a member. Correct
- CAdd the downstream device as a managed device in FortiManager, which then authorises it back into the Security Fabric on the root's behalf.
- DReconfigure the downstream unit's fabric role from downstream to root so both devices share root authority and the pending state clears.
Why A is wrong: Tempting because telemetry must be enabled on the connecting interface, but the scenario already has discovery working; reception of telemetry does not auto-authorise a member, an explicit authorisation step is still required.
Why B is correct: Correct: discovery makes a candidate visible, but the root administrator must explicitly authorise the device by its serial number before it is admitted as a trusted fabric member.
Why C is wrong: Tempting because FortiManager manages devices, but fabric membership authorisation is performed on the root FortiGate itself, and the Fabric does not depend on FortiManager to admit members.
Why D is wrong: Tempting because role is part of fabric setup, but a fabric has exactly one root; promoting the downstream unit to root would break the tree rather than authorise it as a member.