MTU size > 1500
-
Yeah, this is an ISP issue more than anything. What size does your ISP handle?
-
@mike-davis said in MTU size > 1500:
I have a VoIP provider that wants me to set the MTU size on the outbound interface of my firewall to 65507. What are the ramifications if I go beyond 1500? I understand their VoIP system may be able to handle fragmented UDP packets, but does that create the potential to mess anything else up?
I feel like this is a miscommunication. For Level 2 switching you cant exceed 1500, 1518 actually and 18 bytes for overhead.
If there is additional overhead then you would need to set a smaller MTU size to ensure you aren't exceeding the threshold. Not the other way around. Is the VOIP service delivered over VPN, the only cause I can think of here.
-
@mike-davis said in MTU size > 1500:
I have a VoIP provider that wants me to set the MTU size on the outbound interface of my firewall to 65507. What are the ramifications if I go beyond 1500? I understand their VoIP system may be able to handle fragmented UDP packets, but does that create the potential to mess anything else up?
That sounds more like a UDP port TCP port opening not MTU....
-
@mike-davis said in MTU size > 1500:
I have a VoIP provider that wants me to set the MTU size on the outbound interface of my firewall to 65507. What are the ramifications if I go beyond 1500? I understand their VoIP system may be able to handle fragmented UDP packets, but does that create the potential to mess anything else up?
Belongs in the I can't even discussions because jsut WTF...
-
This should cause some major concerns with the VoIP host.
-
@mike-davis said in MTU size > 1500:
I have a VoIP provider that wants me to set the MTU size on the outbound interface of my firewall to 65507. What are the ramifications if I go beyond 1500? I understand their VoIP system may be able to handle fragmented UDP packets, but does that create the potential to mess anything else up?
So many issues with this. Is the VoIP provider also providing a physical connection instead of your ISP? Because that's the only way setting a custom MTU size would make a difference. Even if your ISP supports larger MTU sizes, I highly doubt they support up to 65507!
I'm with JB, FFS, this should be in the "I can't even" thread.
-
@travisdh1 said in MTU size > 1500:
@mike-davis said in MTU size > 1500:
I have a VoIP provider that wants me to set the MTU size on the outbound interface of my firewall to 65507. What are the ramifications if I go beyond 1500? I understand their VoIP system may be able to handle fragmented UDP packets, but does that create the potential to mess anything else up?
So many issues with this. Is the VoIP provider also providing a physical connection instead of your ISP? Because that's the only way setting a custom MTU size would make a difference. Even if your ISP supports larger MTU sizes, I highly doubt they support up to 65507!
I'm with JB, FFS, this should be in the "I can't even" thread.
Yeah, Jumbo is only 9,000!!
-
Sorry I was out on a job that took all day.
The issue is that the customer has a Polycom phone that has a side car. They once they go beyond 48 BLFs, all the BLFs stop working.
Broadcom says:
The recommended solution is to configure the firewalls and/or NAT routers at customer
premises to handle fragmented UDP packets correctly. These firewall and NAT routers
must be configured to support the maximum UDP payload size of 65507 bytes and to
allow at least 45 fragmented packets per packet.
As an example, the Cisco firewalls need to be configured to increase the allowed
fragments per packet to 45 from the default 24 (The maximum supported fragments is
8500 in the case of Cisco firewalls).They then sent me a link to this article that tells how to make the change on a SonicWall:
https://www.sonicwall.com/en-us/support/knowledge-base/170504812146650It didn't make sense to me so I didn't make the change they suggested and posted it here in case I was wrong about the whole thing.
-
That is totally different than what you posted the first time
-
@jaredbusch I'm confused about it. The one snippet from Broadcom is talking about UDP and then Nextiva sent me a link on how to change the MTU. So to be clear MTU has nothing to do with UDP payload size? Does it make sense to have to change UDP payload size?
-
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.
