Hello
There seems to be issue vvx500 not being rfc compliant upon undergoing soft reload.
please refer to attached capture file. the MAC of phone is 00:04:f2:74:19:77, It is connected to DELL switch on a hybrid port where tag vlan is 610. Untag is 110.
Upon soft reset, 1st frame phone sends is a LLDP packet with TTL 0 re frame 1. I noted there is a "proprietry" feature on some switches where as upon receiving such a frame, the switch will immediately send LLDP frame to phone so phone knows which vlan to send DHCP request on. DELL switches don't support this proprietry feature. As such, the phone is sending DHCP packets onto wrong vlan ie frame 31
It is noted in capture the DELL switches do eventually send LLDp frame to phone based on default 30 second interval. It is noted that the phone does not revert to resending DHCP to the correct vlan upon receiving LLDP frame from switch. The phone continues to only send DHCP on the untag vlan and as such, is unable to obtain an IP address on vlan 610. This appears to be non RFC compliant.
Appreciate if you can comment on the behavior of the phone
rgds
George
Solved! Go to Solution.
Hello George,
without spending to much time on this could you kindly post a link to the RFC and Section in the RFC?
In addition we do have a lldpFastStartCount parameter which usually is set to 5.
From the Admin Guide:
You can set this to a maximum of 10 giving you and additional 5 seconds for your switch to respond.
On top of this we also have the net.lldp.extendedDiscovery which is usually set to 0.
From the Admin Guide:
Again this can be changed to a maximum of 3600 seconds which should cover any time period required by your switch to be ready for the LLDP packets.
The VVX500 Phone was sold recently at the 10/06/2016 via Transition Systems Australia Pty Ltd and I suggest you open a support ticket in the APAC region for this if you still believe we are violating an RFC and you require a fix.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Best Regards
Steffen Baier
Polycom Global Services
Hello George,
welcome to the Polycom Community.
This is a day one behaviour and I have not had any tickets raised on this in my area and we are selling quite a few phones every year.
Could you kindly state what RFC and what part of it you believe we violate?
In order to raise a support ticket you need to work with your Polycom reseller as they need to do this for you. In case this is some sort of an Internet discounter please post your phone's MAC address so I can look up who would be able to support you.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Best Regards
Steffen Baier
Polycom Global Services
Hello
This is a day one behaviour and I have not had any tickets raised on this in my area and we
are selling quite a few phones every year.
>>the reason no one may have raised a cased is because some vendors support a enhancement known as "lldp fast start". This enhacement would workaround the problem. Unfortunately the DELL switch doesn't support this at this time so we rely on the fact that the phone should still honor the LLDP packet it receives so as to send DHCP request onto the correct vlan.
In regards to RFC. Its actually IEEE 802.1AB spec. Specifically
MAC address of phone was provided in 1st post. This is what we are seeing:
1. phone soft reset
2. Phone starts to send LLDP frames 1 per second. Lets say t=0
3. t=7. phone transition to sending 1st DHCP request.
It appears the phone is expecting LLDP frame between t=0 to 7. If LLDP fast start is supported on switch, switch will send a LLDP frame to switch within this interval and phone sends DHCP onto correct vlan. If switch does not support fast start, the LLDP packet will arrive at what ever the refresh interval it is sending which by default, is every 30 seconds. When the LLDP packet arrives outside of t=7, the phone never changes sending DHCP request onto the correct vlan. It continues to only send on the untag.
George
Hello George,
without spending to much time on this could you kindly post a link to the RFC and Section in the RFC?
In addition we do have a lldpFastStartCount parameter which usually is set to 5.
From the Admin Guide:
You can set this to a maximum of 10 giving you and additional 5 seconds for your switch to respond.
On top of this we also have the net.lldp.extendedDiscovery which is usually set to 0.
From the Admin Guide:
Again this can be changed to a maximum of 3600 seconds which should cover any time period required by your switch to be ready for the LLDP packets.
The VVX500 Phone was sold recently at the 10/06/2016 via Transition Systems Australia Pty Ltd and I suggest you open a support ticket in the APAC region for this if you still believe we are violating an RFC and you require a fix.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Best Regards
Steffen Baier
Polycom Global Services