ADAM PULSE Knowledge Base
Diagnostics & troubleshooting · PoE · LLDP-MED · FortiSwitch · Grandstream

Grandstream phones on FortiSwitch: why PoE, LLDP-MED and firmware can drop phones offline

By Michael Obraitis, Managing Partner, and Michael Dale, CEO · Published August 18, 2026 · Last reviewed August 2026 · ADAM Pulse Knowledge Base · Voice Diagnostics Series

Short answer

When a Grandstream IP phone intermittently unregisters, fails to power up, or shows no link or PoE indication on a FortiSwitch, do not assume the problem is the cable, SIP provider, or phone registration.

The failure can occur before SIP registration ever becomes relevant.

A useful troubleshooting model is:

Power → Ethernet link → VLAN → IP connectivity → provisioning → SIP registration

If the phone cannot reliably negotiate power or establish Ethernet link, troubleshooting SIP credentials or the hosted phone platform is premature.

This is particularly important with older Grandstream GXP21xx phones and certain FortiSwitch platforms. Fortinet has published a troubleshooting case for the Grandstream GXP2160 in which a FortiSwitch PoE controller firmware issue prevented reliable power delivery. Fortinet's documented remediation included updating RT PoE firmware, updating FortiSwitchOS, and configuring poe-disconnection-type DC-delay on the affected port.

Grandstream firmware also matters. Historical Grandstream GXP21xx release notes document fixes involving LLDP environments, LLDP MED behavior, DNS related registration loss, and other networking issues.

The safest troubleshooting principle is:

Stabilize power and Layer 1 first. Upgrade deliberately second. Troubleshoot registration third.

Start below SIP: power and link come first

Why Can a VoIP Phone Fail Before SIP Is Even Involved?

An IP phone depends on several layers working in sequence.

Layer 1: Power

The phone must receive stable power through PoE or an external power adapter.

Layer 2: Ethernet

The phone and switch must establish a physical Ethernet link.

Layer 3: Network

The phone must obtain the correct VLAN, DHCP lease, gateway, DNS, and network access.

Provisioning

The phone must retrieve and apply the correct configuration.

SIP

Only then can the phone reliably register with the voice service.

This sequence matters.

If the switch does not establish PoE or Ethernet link, the problem is not yet a SIP problem.

This is a very important symptom.

If a known good phone is connected directly to a switch and there is:

investigate the physical and power negotiation layers first.

Possible causes include:

Do not start by troubleshooting SIP.

The external power supply test

Why Is Testing With an External Power Supply So Valuable?

An external power adapter is an excellent isolation tool.

It separates:

Is the phone failing because it cannot receive stable PoE?

from:

Is the phone failing even when power is independent of the switch?

A useful test is:

Test A

Phone powered only through switch PoE.

Observe stability.

Test B

Disable PoE on that switch port and power the phone with the correct external adapter.

Observe stability again.

If the phone becomes substantially more stable under external power, the PoE path becomes a strong suspect.

This does not automatically prove the switch is defective. It tells you which layer deserves investigation.

Can External Power Be Used as a Temporary Workaround?

Yes, in an appropriate environment.

If the phones support an approved external power supply, temporarily disabling PoE on the affected switch ports and powering the phones externally can isolate or bypass an unstable PoE negotiation problem.

This can be especially valuable when:

This should be documented as a temporary stabilization measure, not automatically treated as the permanent root cause fix.

Why Should PoE Be Disabled if an External Power Adapter Is Being Used?

If the purpose of the test is to eliminate PoE as a variable, disabling PoE on the respective switch port creates a cleaner test.

Otherwise, the phone may still interact with the switch's PoE detection and negotiation process even though external power is connected.

The desired isolation state is:

External power supplies the phone

and

The switch port provides Ethernet only

That gives the technician a clearer comparison.

Firmware: when it helps, and when it hurts

Can a Firmware Upgrade Make the Situation Worse?

Yes.

Firmware changes should not be treated as harmless.

They can change:

A large version jump can also introduce migration behavior that does not appear during a smaller incremental update.

If an organization previously attempted a major firmware upgrade and had to revert because of severe disruption, that history should become part of the change plan.

Should We Upgrade Firmware Just Because a Newer Version Exists?

No.

The right question is:

What version is supported, what problem are we trying to solve, and what is the safest supported upgrade path?

Before upgrading, identify:

Firmware should solve a known problem or move the environment to a supported state.

It should not be used as a blind troubleshooting button.

Why Is a Large Firmware Jump Risky?

A phone running very old firmware may have passed through years of:

The safest path may require intermediate releases.

Always review the manufacturer and provisioning provider guidance for the exact device before jumping several firmware branches.

Which Grandstream firmware versions actually fixed this

Which Grandstream Firmware Versions Actually Fixed This?

This is the part most write-ups skip, and skipping it makes the whole article look unverifiable.

The GXP21xx release notes record a build — 1.0.7.81 — that fixed three defects which together describe exactly the failure pattern in this article:

Fixed phone stucked at base download when using LLDP-MED.

Fixed Device TFTP upgraded abnormally in LLDP network environment

Fixed phone loss of register every 32 minutes due to failing to resolve DNS

A phone hanging during boot under LLDP-MED, and a phone that registers and then silently drops on a repeating interval, are two of the three symptoms people arrive here with. If the fleet is on anything older than 1.0.7.81, firmware is a live hypothesis and not a guess.

Now the trap. Grandstream's current GXP21xx release note only retains history back to 1.0.11.35. A reader who checks the current document for 1.0.7.81 finds nothing, and reasonably concludes the claim was invented. The older history lives in the archived release notes — for example the 1.0.8.50 note — which are still downloadable from Grandstream's firmware server and previous-firmware page. Cite the archived note, not the current one, or the citation fails the first time anyone checks it.

Practically, when you inventory the fleet, the versions worth knowing are the ones bracketing that fix: 1.0.5.33, 1.0.7.15 and 1.0.7.81. Anything below 1.0.7.81 is old enough that the documented LLDP-MED and DNS defects apply.

Why Is Grandstream Firmware Relevant to LLDP MED?

LLDP MED is commonly used in voice networks to communicate information such as network policy and voice VLAN behavior.

Historical Grandstream GXP21xx release notes include fixes related to LLDP environments and LLDP MED behavior.

For example, Grandstream documented a fix for a phone becoming stuck during boot in an LLDP MED environment in older GXP21xx firmware.

That history matters when troubleshooting an older GXP phone running legacy firmware.

It does not mean every LLDP problem is caused by the phone.

It means firmware must be considered as part of the evidence.

LLDP, LLDP-MED and what they do not do

What Is LLDP?

LLDP stands for Link Layer Discovery Protocol.

It allows directly connected network devices to advertise information to one another.

In a VoIP environment, a switch and phone may use LLDP information to assist with:

What Is LLDP MED?

LLDP MED extends LLDP for endpoint environments such as IP telephony.

MED stands for Media Endpoint Discovery.

It can help communicate information relevant to voice endpoints, including network policy and power related information.

When LLDP MED behavior is unreliable, a phone can experience unexpected VLAN or network behavior.

Does LLDP MED Actually Supply PoE?

No.

Do not confuse LLDP MED with the underlying IEEE PoE detection and classification process.

PoE power delivery and LLDP based power information can interact in modern environments, but they are not the same mechanism.

A phone can have an LLDP problem without having a PoE problem, and it can have a PoE detection problem before LLDP communication becomes relevant.

That distinction is important when writing a root cause analysis.

How Much Power Does a GXP21xx Actually Draw?

Very little, and that fact is a triage shortcut worth having early.

The GXP21xx desk phones are 802.3af Class 1 to Class 2 devices — roughly 4 W to 6.5 W at the port. They are among the lightest powered devices on a typical access switch; a Wi-Fi 6 access point or a PTZ camera on the same switch will draw several times more.

The useful consequence: PoE budget exhaustion is an unlikely explanation for these particular phones. If a 24-port switch is failing to power a handful of 5 W desk phones, the budget is almost certainly not the constraint, and time spent totting up wattage is time not spent on detection and negotiation — which is where the documented defects actually live.

Budget still deserves a glance if the same switch is carrying access points, cameras or PoE++ devices. But do not let it become the first hypothesis for a phone in this class.

What Is a Powered Device?

In PoE terminology, the phone is the Powered Device, or PD.

The switch is the Power Sourcing Equipment, or PSE.

The PSE determines whether an appropriate powered device is connected and then supplies power according to the supported PoE process.

If detection or disconnect behavior is problematic, the phone can lose power even though the Ethernet configuration itself appears correct.

PoE detection, disconnect and DC-delay

What Is PoE Disconnect Detection?

A PoE switch must determine whether the powered device is still connected.

FortiSwitch supports configurable disconnect behavior on applicable platforms.

Current Fortinet documentation describes:

For DC-delay, Fortinet documents DC disconnect with an additional 500 millisecond delay.

This can matter with endpoints whose electrical load behavior creates problematic disconnect detection.

What Is poe-disconnection-type DC-delay?

It is a FortiSwitch PoE configuration option on supported models and FortiSwitchOS versions.

Fortinet documents DC-delay as DC disconnect with an additional 500 millisecond delay.

Fortinet also specifically documents using DC-delay in its Grandstream GXP2160 troubleshooting procedure after the prescribed PoE firmware and FortiSwitchOS updates.

Do not apply this command blindly across every switch.

Confirm:

Will I Actually Find These Settings on My Switch?

Possibly not, and this is where most people conclude the article is wrong.

Most FortiSwitches are FortiLink-managed by a FortiGate rather than administered standalone. Fortinet documents that under FortiLink, poe-disconnection-type may not be exposed as a normal managed-switch setting and has to be pushed as a custom command from the FortiGate. A reader who opens the switch UI, cannot find the setting, and gives up has hit a management-mode difference, not a documentation error.

The keyword also differs by mode. Standalone uses poe-pre-standard-detect; under FortiLink the equivalent appears as poe-pre-standard-detection. Searching for the wrong one returns nothing.

Before you spend an hour on this: establish whether the switch is FortiLink-managed or standalone. Everything below depends on the answer.

The documented Fortinet case, and its real scope

Has Fortinet Documented a Grandstream PoE Problem?

Yes.

Fortinet published a troubleshooting article specifically titled:

Troubleshooting Tip: FortiSwitch not providing power to GRANDSTREAM GXP2160 VoIP Phone

In the documented case, the switch reported RT PoE firmware 1.0.1.7.

Fortinet's remediation procedure included:

poe-disconnection-type DC-delay

This is strong evidence that PoE controller firmware should be checked when a GXP2160 does not receive power from an affected FortiSwitch platform.

Does That Fortinet KB Apply to Every Grandstream and Every FortiSwitch?

No.

This distinction is essential.

The published Fortinet article addresses a specific Grandstream GXP2160 and particular FortiSwitch conditions.

Do not generalize one vendor case into:

All Grandstream phones have broken PoE

or:

All FortiSwitches require RT PoE 1.0.1.9

Two scope points worth stating plainly. Fortinet's documented case covers the 124F and 148F at RT PoE 1.0.1.6 and 1.0.1.7 — the 124F belongs in that list as much as the 148F. And because the 1.0.1.9 image is only available from Fortinet TAC, opening a TAC case is step zero of this remediation, not a footnote at the end of it. You cannot execute the documented fix without it, so open the case before you plan the change window rather than after.

Instead use it as a troubleshooting lead.

Match:

Then involve Fortinet TAC when the environment aligns with the documented issue or when the exact platform requires vendor specific guidance.

The commands, and collecting evidence first

How Do I Check the FortiSwitch PoE Firmware?

A useful FortiSwitch diagnostic command is:

get hardware statusReview the output for the PoE Firmware Version or equivalent platform information.

Record:

Do this for every affected switch rather than assuming identical switches have identical firmware.

How Do I Check PoE State Per Port?

On supported FortiSwitch platforms, use the relevant PoE diagnostic command for the installed FortiSwitchOS release.

A commonly useful command is:

get switch poe inlineCapture the complete output.

You are looking for evidence such as:

Command availability and output can vary by platform and FortiSwitchOS release, so verify against current Fortinet documentation or TAC guidance.

Why Should We Collect Command Output Before Changing Anything?

Because troubleshooting without a baseline destroys evidence.

Before making a change, record:

Then make one controlled change and retest.

This lets you answer:

What actually fixed it?

What Is PoE Pre Standard Detection?

FortiSwitch includes a poe-pre-standard-detect setting for supporting certain legacy PoE devices.

Modern standards compliant phones generally should not require legacy pre standard detection.

Fortinet's current documentation notes that this setting is global on certain models, including 148F PoE variants, while it is per port on other PoE models.

Fortinet also documents that the default changed to disabled starting with FortiSwitchOS 7.0.0.

Should PoE Pre Standard Detection Be Enabled for a Grandstream IP Phone?

Do not enable it simply because a phone is having trouble.

For a standards based endpoint, start with the normal supported IEEE PoE configuration and verify the manufacturer's requirements.

Use pre standard detection only when it is actually required and supported for the device.

Adding legacy detection mechanisms during troubleshooting can introduce another variable.

Model and profile differences

Why Does the FortiSwitch Model Matter?

PoE implementation is not identical across every switch.

Differences can include:

A solution validated on a 148F should not automatically be copied to a 248 model without checking the exact platform documentation.

What About FortiSwitch 148 and 248 Models?

Treat them separately.

If both families show similar symptoms, collect the same evidence from each, but do not assume they use identical PoE controller firmware or identical remediation.

For each switch:

get hardware statusand the applicable per port PoE diagnostic output.

Then compare the results by model.

If the 148 aligns with a documented Fortinet TAC issue but the 248 does not, open the appropriate vendor case rather than forcing the 148 remediation onto the 248.

Should We Change the LLDP Profile?

Not without understanding the current configuration.

First document which LLDP profile is applied to the affected phone ports.

Then determine:

The objective is to simplify the test, not create more moving parts.

Is the Default LLDP Profile Always the Answer?

No.

A default profile can be a useful baseline, but the correct profile depends on the network design.

If the production voice VLAN relies on specific LLDP MED network policy, replacing a custom profile without understanding it can break phone connectivity.

Always capture the existing configuration before changing it.

Isolating the actual fault

How Do I Tell Whether LLDP Is the Problem?

Use isolation testing.

For example:

If power is stable but the phone lands on the wrong VLAN, LLDP or VLAN policy becomes more relevant.

If there is no Ethernet link at all, stay lower in the stack.

What If External Power Helps but the Phone Still Unregisters?

That is valuable evidence.

It suggests PoE may be one problem but not the only problem.

Once power is stable, continue upward:

Ethernet

→ Voice VLAN

→ DHCP

→ DNS

→ Internet / WAN

→ Provisioning

→ SIP registration

Do not declare the issue solved simply because unregistering becomes less frequent.

Can Old Firmware Cause SIP Unregistering?

Potentially.

Historical Grandstream GXP21xx release notes document fixes for registration loss, including a case involving DNS resolution.

Firmware can also affect the networking behavior that registration depends on.

However, an unregistering phone can also be caused by:

Firmware is one branch of the troubleshooting tree, not the automatic answer.

Upgrading a fleet safely

What Is the Safest Way to Upgrade a Fleet of Old Phones?

Never start with the whole fleet.

Use a staged deployment.

Stage 1: Inventory

Record:

Stage 2: Validate

Confirm with the phone manufacturer and provisioning provider:

Stage 3: Pilot

Select one non critical phone.

Stage 4: Baseline

Test before upgrade:

Stage 5: Upgrade

Upgrade only the pilot.

Stage 6: Burn In

Observe it for an appropriate period.

Stage 7: Expand

Upgrade a small group.

Stage 8: Production

Only after successful validation should the broader fleet be scheduled.

Why Is a Pilot So Important?

A firmware upgrade can be technically successful while operationally failing.

For example:

The phone boots.

But:

A pilot catches these issues before dozens or hundreds of phones are affected.

What Should Be in the Rollback Plan?

Before the upgrade, know:

A rollback plan that begins after the outage is not a rollback plan.

Can Downgrading Grandstream Firmware Be Dangerous?

Yes.

Grandstream publishes model specific downgrade warnings.

For example, current Grandstream firmware documentation warns that certain GXP213x hardware revisions should not be downgraded below specified versions after reaching newer firmware because doing so may brick the device.

Always read the exact release notes for the exact model and hardware revision before upgrading or downgrading.

Escalation: who to involve, and with what evidence

Should the Hosted VoIP Provider Be Involved?

Yes, especially when the provider controls provisioning.

The provider may control:

A locally upgraded phone can simply be overwritten or reprovisioned if the provider's platform expects another firmware branch.

Coordinate rather than creating competing management planes.

Should Fortinet TAC Be Involved?

Yes when:

Provide TAC with evidence rather than a generic report.

What Evidence Should We Give Fortinet TAC?

Include:

This makes the case much easier to reproduce and escalate.

What Evidence Should We Give the Phone Provider?

Include:

Stabilising, and what the evidence does not prove

What Is the Best Temporary Stabilization Plan?

When production stability is more important than immediately completing root cause remediation:

This isolates power while preserving network service.

Does External Power Prove the Switch Is Bad?

No.

It proves that changing the power path changed the behavior.

Possible underlying causes can still include:

Root cause requires evidence from both sides.

Does a Firmware Upgrade Prove the Phone Was the Problem?

No.

If upgrading the phone resolves the problem, it is strong evidence that firmware behavior was involved.

But an upgrade can also change timing or negotiation in a way that merely avoids a switch side defect.

In interoperability problems, the root cause may involve the interaction between two devices rather than a single guilty component.

How Should We Describe the Root Cause?

Avoid unsupported absolute statements such as:

"Grandstream PoE is broken."

A more defensible technical statement is:

"The incident is consistent with a PoE interoperability problem between the affected Grandstream phone firmware and the FortiSwitch power delivery environment. External power testing, switch PoE diagnostics, firmware comparison, and vendor documentation should be used to isolate the contributing components."

That language reflects the evidence without overstating it.

Troubleshooting decision tree

Troubleshooting Decision Tree

Does the phone power on through PoE?

No

→ Test known good cable and port.

Still no?

→ Check switch port status and PoE state.

Still no?

→ Test approved external power.

External power works?

→ Investigate PoE negotiation, switch PoE firmware, switch OS, and phone firmware.

Does the phone power on but no Ethernet link appears?

→ Test known good cable.

→ Test known good port.

→ Verify port is enabled.

→ Check speed and negotiation configuration.

→ Compare known good phone.

→ Check LLDP.

→ Check LLDP MED.

→ Check voice VLAN configuration.

→ Check port profile.

→ Check phone VLAN settings.

Does the phone receive correct VLAN and IP but unregister?

→ Check DNS.

→ Check WAN stability.

→ Check firewall and NAT.

→ Check SIP ALG.

→ Check provider reachability.

→ Check provisioning.

→ Check phone firmware.

Does external power reduce or eliminate failures?

→ Keep external power as a temporary isolation measure if operationally appropriate.

→ Disable PoE on that specific port.

→ Collect switch PoE firmware and port diagnostics.

→ Review Fortinet known issues.

→ Review phone firmware.

→ Coordinate vendor remediation.

Checklists and change plan

Tier 1 Technician Checklist

Physical

FortiSwitch

Network

Phone

Escalation

Change Plan for a High Risk Firmware Upgrade

Before

During

After

Frequently asked questions

Why does my Grandstream phone not receive PoE from a FortiSwitch?

Possible causes include switch port configuration, PoE budget, detection problems, PoE controller firmware, FortiSwitchOS, phone firmware, cabling, or a device interoperability problem. Fortinet has published a specific troubleshooting case involving GXP2160 phones and certain FortiSwitch PoE firmware.

Why does my Grandstream phone keep unregistering?

Unregistering can result from power instability, Ethernet instability, VLAN changes, DNS problems, WAN issues, firewall behavior, SIP ALG, provisioning, provider issues, or phone firmware. Troubleshoot from the physical layer upward.

Can old Grandstream firmware cause LLDP problems?

Historical Grandstream GXP21xx release notes contain fixes involving LLDP environments and LLDP MED, so firmware should be included in the troubleshooting process for older phones.

Can a FortiSwitch PoE firmware problem stop a Grandstream from powering up?

Yes. Fortinet has documented a GXP2160 case involving RT PoE firmware where the prescribed remediation included RT PoE firmware 1.0.1.9, FortiSwitchOS 7.6.2 GA, and `DC-delay`.

What does DC-delay do on a FortiSwitch?

Fortinet documents it as DC disconnect detection with an additional 500 millisecond delay.

Should I enable PoE pre standard detection?

Not automatically. It is intended for legacy PoE detection use cases. Start with the supported standards based configuration for a modern phone.

Can I power a Grandstream phone with an external adapter?

If the exact phone model supports an approved external adapter, it can be a useful troubleshooting and temporary stabilization method.

Should I disable PoE when using external power?

If you are deliberately trying to eliminate PoE as a troubleshooting variable, disabling PoE on that specific port creates a cleaner isolation test.

Should I upgrade all Grandstream phones at once?

No. Pilot one non critical device, validate it, observe it, then expand gradually.

Can a firmware downgrade brick a Grandstream phone?

Grandstream publishes downgrade warnings for certain models and hardware revisions. Always read the exact release notes before upgrading or downgrading.

Is LLDP MED the same as PoE?

No. They can interact in endpoint environments, but IEEE PoE detection and LLDP MED are distinct mechanisms.

What should I check first if there is no link light and no PoE light?

Start with power, cable, port state, PoE diagnostics, and a known good comparison. SIP registration is not yet the relevant layer.

What should I send Fortinet TAC?

Send the switch model, OS, PoE firmware, hardware status, per port PoE diagnostics, port configuration, phone model and firmware, external power test results, timestamps, and known good comparisons.

References

Vendor documentation only. Where a firmware fix is cited, the archived release note is linked rather than the current one, because the current note does not go back far enough to contain it.

  1. Grandstream — GXP21xx release note archive (1.0.8.50)— the archived note containing the 1.0.7.81 fixes: "Fixed phone stucked at base download when using LLDP-MED", "Fixed Device TFTP upgraded abnormally in LLDP network environment", and "Fixed phone loss of register every 32 minutes due to failing to resolve DNS." The current release note only retains history back to 1.0.11.35.
  2. Grandstream — Previous firmware— where the archived images and release notes for older builds are still available.
  3. Grandstream — Firmware— current firmware and the current release note, whose history begins at 1.0.11.35.
  4. Grandstream — GXP21xx Series documentation— user guides and administration documentation for the GXP2130/2135/2140/2160/2170.
  5. Fortinet Document Library — FortiSwitch PoE— PoE detection, disconnect behaviour, pre-standard detection and the differences between standalone and FortiLink-managed administration.
  6. Fortinet Document Library — FortiSwitch managed by FortiGate (FortiLink)— the management mode that determines whether a PoE setting is exposed directly or has to be pushed as a custom command.
  7. IEEE 802.3af — Power over Ethernet classes— the class structure behind the 4 W to 6.5 W draw of a Class 1–2 desk phone.
Ask ADAM Pulse about desk-phone dropouts

ADAM Pulse diagnoses Zoom Phone desk-phone faults at the switch: PoE, LLDP-MED, firmware and the evidence Fortinet and Grandstream both need before anyone guesses.

Prepared by ADAM Pulse (USA Telecom Consulting LLC)

Managed voice and network services, SDVOSB. We run the unglamorous part of this: switch and phone firmware inventory, PoE and LLDP evidence capture before anything is changed, staged firmware upgrades with a pilot group and a rollback plan, and holding both the Fortinet and the phone vendor cases so nobody is waiting on the other. Support: (888) 989-4872 · support@adampulse.us