MTU size > 1500
-
You mean broadsoft not Broadcom. I know they have told other customers the same but it is not possible to do that with MTU. See example below:
https://community.ubnt.com/t5/EdgeMAX/VOIP-and-Routing-Question/td-p/1365480
-
In other words they want you to reduce the MTU to 1480 instead of 1500.
https://support.olafe.com/hc/en-us/articles/217846408-Limitations-on-Monitored-Lines
-
@dbeato said in MTU size > 1500:
In other words they want you to reduce the MTU to 1480 instead of 1500.
https://support.olafe.com/hc/en-us/articles/217846408-Limitations-on-Monitored-Lines
I think you hit a bingo with that one. That make sense.
-
Right, good ol... ping -f -l xxxx to the sip server up address, xxxx being the mtu size. Lower and raise til you find the correct size that replies below the integer that doesn’t.
Pretty common wherever early adsl existing behind a firewall that added header for SPI.
-
So I did this test:
C:\>ping -f -l 1473 208.73.144.1 Pinging 208.73.144.1 with 1473 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 208.73.144.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), C:\>ping -f -l 1472 208.73.144.1 Pinging 208.73.144.1 with 1472 bytes of data: Reply from 208.73.144.1: bytes=1472 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1472 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1472 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1472 time=79ms TTL=244 Ping statistics for 208.73.144.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 79ms, Maximum = 79ms, Average = 79msThen I set the MTU on the SonicWall down to 1472 since that was the largest that worked. When I test now, it's 28 bits lower. Is that to be expected, or is something wrong? Should the BLF thing be resolved?
C:\>ping -f 208.73.144.1 -l 1444 Pinging 208.73.144.1 with 1444 bytes of data: Reply from 208.73.144.1: bytes=1444 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1444 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1444 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1444 time=79ms TTL=244 Ping statistics for 208.73.144.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 79ms, Maximum = 79ms, Average = 79ms C:\>ping -f 208.73.144.1 -l 1445 Pinging 208.73.144.1 with 1445 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 208.73.144.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), -
@mike-davis said in MTU size > 1500:
So I did this test:
C:\>ping -f -l 1473 208.73.144.1 Pinging 208.73.144.1 with 1473 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 208.73.144.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), C:\>ping -f -l 1472 208.73.144.1 Pinging 208.73.144.1 with 1472 bytes of data: Reply from 208.73.144.1: bytes=1472 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1472 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1472 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1472 time=79ms TTL=244 Ping statistics for 208.73.144.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 79ms, Maximum = 79ms, Average = 79msThen I set the MTU on the SonicWall down to 1472 since that was the largest that worked. When I test now, it's 28 bits lower. Is that to be expected, or is something wrong? Should the BLF thing be resolved?
C:\>ping -f 208.73.144.1 -l 1444 Pinging 208.73.144.1 with 1444 bytes of data: Reply from 208.73.144.1: bytes=1444 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1444 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1444 time=79ms TTL=244 Reply from 208.73.144.1: bytes=1444 time=79ms TTL=244 Ping statistics for 208.73.144.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 79ms, Maximum = 79ms, Average = 79ms C:\>ping -f 208.73.144.1 -l 1445 Pinging 208.73.144.1 with 1445 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 208.73.144.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),What you are doing thus far is common with adsl and firewalls.
What is the BLF issue? What phone and platform?
-
Okay I read the whole thread.
You should know Polycom has a hard limit of 50 BLF keys on most models. I know you said 48 but you probably aren’t counting line buttons.
-
Page 3 half way down
Can all VVX Business Media Phones handle 50 BLF lines out of the box?
Due to screen limitations of the phone hardware, there are limits on the number of BLF lines that can be monitored, depending on the phone model. These limits are purely a factor of the number of physical line keys available on each phone.
If more than the maximum number of lines is configured, the phone will not monitor those additional lines.
To reach the maximum of 50 BLF lines, expansion modules must be attached to the phone.
-
@bigbear yes, the Polycom has a side car and has a 50 BLF limit. It was the issue of going from 48 to 50. Changing the MTU down to 1472 seemed to fix it. Thanks for the commands so I could find out what that limit was.
-
The phone is a Polycom UC VVX410 in case anyone else is having this issue.
-
@mike-davis said in MTU size > 1500:
The phone is a Polycom UC VVX410 in case anyone else is having this issue.
I have them and people with those limits have a side card too
