IP Phone No IP Address After Voice VLAN: Find the Lost Reply
The "ip phone no ip address" symptom after a voice VLAN change means the tagged DHCP reply is dropped between the server and the phone port, usually because the voice VLAN is missing from a trunk, the bridge CPU port, the VLAN table or the phone port's tagged list.
- The first untagged lease proves the cable, port and server work, but says nothing about VLAN tagging, so the second DHCP exchange must be debugged as a new path.
- Capture at the phone port, the uplink and the DHCP server at the same time to see which hop last carried the OFFER or ACK.
- On RouterOS, the voice VLAN must be tagged on the bridge itself, on every trunk, and on the phone port, which should have a PVID for the data VLAN.
- Check /interface bridge host for the phone MAC and its vid, because a stale or wrong-VLAN entry makes a unicast reply go nowhere.
- Set a static IP and VLAN on the phone, or use a tagged laptop on the same port, to decide quickly whether the switch or the DHCP server is at fault.
Why does an IP phone get no IP address on the voice VLAN?
The classic ip phone no ip address case starts with how phones boot. Most phones work in two stages. Stage one is DHCP with no VLAN tag on the port's native (PVID) VLAN. The OFFER or ACK carries option 132 (VLAN ID), or the switch advertises a voice VLAN via LLDP-MED or CDP.
Stage two starts when the phone reads that VLAN ID. It drops the first lease, reconfigures its network stack to send tagged frames, and runs DHCP again from DISCOVER. That is why the first lease works and the second fails: the second exchange uses a path (tag 20, for example) that nothing has proven yet.
The phone usually gets an address, then shows 'Network unavailable' or 169.254.x.x. A failure at this point is nearly always a missing VLAN membership somewhere, or a reply that cannot find the phone's MAC.
| Where it breaks | Symptom in a capture | Typical cause |
|---|---|---|
| Phone to switch | DISCOVER tagged never seen on the uplink | Voice VLAN not allowed on the phone port, or ingress filtering drops tagged frames |
| Switch to server | DISCOVER seen on the uplink, none at the server | VLAN missing on the trunk or on the bridge CPU port |
| Server | DISCOVER arrives, no OFFER | No DHCP server or network on the VLAN interface, pool exhausted, conflicting lease |
| Server to switch | OFFER leaves server, not seen at phone port | VLAN not tagged toward the phone port, MAC not learned in that VLAN |
| Switch to phone | OFFER leaves port untagged | Voice VLAN listed untagged on the port, or PVID wrong |
How do I find where the DHCP reply is lost?
Follow the packet hop by hop and stop at the first hop where it disappears. Run captures at the same time and note timestamps, so one DISCOVER can be tracked across all three points.
Sniff on the server or router with tcpdump or sngrep style tooling for DHCP, and on RouterOS use the sniffer. Offloaded bridge ports forward in hardware, so the CPU only sees flooded or CPU-bound traffic. A capture on the router can look empty even when the switch chip is forwarding fine.
- Reboot the phone with captures running at the DHCP server, the uplink, and the phone port (use a mirror port on the switch, or a laptop in line).
- At the server: do you see a tagged DISCOVER on the voice VLAN? If not, the request never arrived, so look at the phone port and trunk.
- If the DISCOVER arrived, do you see an OFFER leaving? If not, the problem is the DHCP server (interface, network, pool, lease).
- If the OFFER left, is it on the uplink? If not, the router's VLAN interface is not on the trunk, or the trunk port lacks the VLAN.
- If the OFFER reached the switch but not the phone port, or left untagged, the problem is the bridge VLAN table, host table or port egress tagging.
# On the DHCP server / Linux side
tcpdump -i eth0 -e -n -vv 'vlan and (port 67 or port 68)'
# RouterOS: capture DHCP on the VLAN interface
/tool sniffer quick interface=vlan20 port=67,68 ip-protocol=udp
# CRS3xx: mirror the phone port to a spare port for a laptop capture
/interface ethernet switch set switch1 mirror-source=ether5 mirror-target=ether8
# Laptop on the mirror port: -e shows the 802.1Q tag
tcpdump -i eth0 -e -n 'ether host aa:bb:cc:dd:ee:ff'What should the phone port and trunk look like?
A phone port is a hybrid port: untagged for the data VLAN (PVID) and tagged for the voice VLAN. The voice VLAN must be in the tagged list of the phone port, of every trunk between the phone and the DHCP server, and of the bridge itself if the router or switch terminates the VLAN.
A common mistake is a VLAN that appears in the bridge VLAN table with the port entries correct but the bridge interface missing from tagged. The VLAN interface sits on the bridge (the CPU port), so without the bridge tagged, DHCP relay, a DHCP server on that VLAN and switch management all see nothing.
Known-good example for a CRS3xx: data VLAN 10, voice VLAN 20, phone on ether5, trunk on sfp-sfpplus1.
/interface bridge add name=bridge vlan-filtering=no
/interface bridge port
add bridge=bridge interface=ether5 pvid=10 frame-types=admit-all ingress-filtering=yes
add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged ingress-filtering=yes
/interface bridge vlan
add bridge=bridge vlan-ids=10 tagged=bridge,sfp-sfpplus1 untagged=ether5
add bridge=bridge vlan-ids=20 tagged=bridge,sfp-sfpplus1,ether5
/interface vlan add name=vlan20 vlan-id=20 interface=bridge
/interface bridge set bridge vlan-filtering=yes
# Verify
/interface bridge vlan print
/interface bridge port printHow do MAC learning and the bridge host table break the reply?
Before the phone has an IP, the server often replies by unicast to the phone's MAC (or to broadcast, depending on the broadcast flag). A unicast reply is only forwarded out the right port if the switch has learned that MAC in that VLAN. If the MAC is unknown it is flooded within the VLAN, which should still work, but a stale entry pointing to the wrong port or VLAN makes it vanish.
The same phone MAC is seen first untagged in VLAN 10 and then tagged in VLAN 20. With vlan-filtering on, the RouterOS host table is keyed by MAC and vid. Look at it directly.
- Print entries for the phone: /interface bridge host print where mac-address=AA:BB:CC:DD:EE:FF.
- Confirm the entry for vid=20 shows on-interface=ether5 and the server or router MAC shows on the trunk.
- If you see the phone MAC on the wrong port, or only in vid=10, disable and re-enable the bridge port to clear its dynamic entries, or temporarily set learn=no on the phone port and retest.
- If the phone MAC never appears with vid=20, the tagged DISCOVER is being dropped on ingress: check ingress-filtering, frame-types and the bridge VLAN entry for ether5.
/interface bridge host print where mac-address=AA:BB:CC:DD:EE:FF
/interface bridge host print where on-interface=ether5
/interface bridge port set [find interface=ether5] learn=no ;# test only
/interface bridge port print ;# H flag = hardware offloadedWhat DHCP server settings can hide the tagged reply?
The voice VLAN needs its own interface, address, pool and network. A server bound to the data VLAN will never answer a tagged request on VLAN 20, and a missing network entry makes the server ignore the request silently.
If DHCP is relayed or served by a router across the trunk, confirm that the router's VLAN 20 interface exists and the trunk carries VLAN 20 in both directions. Then check the lease table: a binding for the same MAC and client-id in the data network can conflict with the second request, especially if the phone changes its client-id between stages.
/ip address add address=10.20.0.1/24 interface=vlan20
/ip pool add name=voice-pool ranges=10.20.0.100-10.20.0.200
/ip dhcp-server add name=dhcp-voice interface=vlan20 address-pool=voice-pool \
lease-time=1h always-broadcast=yes use-framing=no
/ip dhcp-server network add address=10.20.0.0/24 gateway=10.20.0.1
/ip dhcp-server lease print where mac-address=AA:BB:CC:DD:EE:FF
/system logging add topics=dhcp action=memory
/log print where topics~"dhcp"How do I isolate the switch from the phone and the server?
Take the phone out of the problem. Plug a laptop into the phone port, create a VLAN 20 interface on it, and run DHCP. If it gets an address, the switch and server path is good and the phone is the issue. If not, the problem is in the network.
Next, set the phone to a static IP and manual VLAN. A phone that can ping the gateway on VLAN 20 proves tagging works end to end and that only DHCP is broken. Finally swap the phone to a different port or switch to rule out a port-specific config.
Hardware offload on CRS3xx varies by RouterOS version, and VLAN and DHCP behavior has changed across releases. Read the changelog for bridge, VLAN and switch-chip entries, and test on the latest stable or long-term release. If a bug is suspected, compare bridge VLAN filtering with the older /interface ethernet switch VLAN config on a spare port, not on a production one.
# Yealink: set the VLAN manually (web UI or auto-provisioning)
static.network.vlan.internet_port_enable = 1
static.network.vlan.internet_port_vid = 20
# Linux laptop test on the phone port
ip link add link eth0 name eth0.20 type vlan id 20
ip link set eth0.20 up
dhclient -v eth0.20Verification checklist and what to post when asking for help
Before asking for help with an ip phone no ip address problem, confirm each of these items and capture the evidence. A precise report lets others find the failing hop in minutes.
Checklist: the voice VLAN is tagged on the bridge, every trunk and the phone port; the phone port has a PVID for the data VLAN; the VLAN interface and DHCP server exist for VLAN 20; the host table has the phone MAC with vid=20 on the right port; the server logs an OFFER; the capture at the phone port shows the OFFER tagged.
Post the output of /export for bridge, bridge port, bridge vlan, interface vlan and ip dhcp-server (hide secrets), the RouterOS version and board model, the phone model and firmware, and simultaneous captures with timestamps from the phone port, uplink and server.
Common questions
Does DHCP option 132 work on every phone?
No. Yealink and several other vendors read option 132 for the VLAN ID, but the option must be enabled on the phone and the encoding on the server must match. Some phones use LLDP-MED or CDP instead, so check which method the phone prefers in its network settings.
Why does the phone work when I set the VLAN by hand but not through DHCP?
A manual VLAN skips the untagged first stage and the release between stages, so the failure is probably in the first lease, the option 132 value, or a conflicting lease between the two networks. Compare the first OFFER's option 132 in a capture with the VLAN you set by hand.
Can the phone's own PC port cause this problem?
Yes. Most phones forward the PC port untagged and tag only their own traffic, so the switch port must still be hybrid with the data VLAN untagged. If the port is access-only, the tagged voice frames are dropped.
Should I use LLDP-MED instead of option 132?
LLDP-MED is generally cleaner because the switch tells the phone its VLAN before DHCP, so the phone starts tagged. It requires switch support and the phone must have LLDP enabled, and RouterOS bridge ports need LLDP configured separately.