The topology is very simple, we have a vpls tunnel faicing to core device and a VRF for the phones only
Issus: Phones (yealink) are not auto provisioning ,by using option66 after factory reset.
So the intersting part is here: they are working well until someone factory resets them.
Once they are reset they are not able to do auto provisioning. - The tunnel which is running for them is VPLS-tunnel
For testing purposes we swiched over to EoIP - everything works well now
All the phones can do auto provisioning after factory reset.
Can you see in the debug log of the DHCP server that the DHCPDISCOVER and the DHCPREQUEST from the factory-reset phone arrives and Option 66 is on the list of requested ones?
Can you see Option 66 in the DHCPOFFER and DHCPACK sniffed at the phone-facing end of the tunnel?
Was the EoIP tunnel interface at the DHCP-server-facing end in the same VRF like the VPLS tunnel interface?
To me it sounds more like a problem with broadcast handling in the VPLS case than like a problem of Option 66 as such. The phone may skip the DHCPDISCOVER (broadcast) phase when not factory-reset but just rebooted, and attempt to renew the previous lease with the previously used server by sending a DHCPREQUEST (unicast). But if it does get the correct IP address via DHCP after factory-reset, it’s even more weird.
we have pluget computer and run Wireshark ,and we wasn’t able to detect option66. im doubt that we did properly
VRF is same, im not playing with that one, just i have swopend to EoIP.
/ip route vrf
add interfaces=vpls1,vpls2,vpls3,eoip1-mark=phones, as you can see i have changed only the tunnel interface.
more details on this i’ll provide you once available.
I’m not happy to use EoIP, because already we have cloud