ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    MTU size > 1500

    IT Discussion
    7
    23
    2.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Mike DavisM
      Mike Davis @JaredBusch
      last edited by

      @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?

      1 Reply Last reply Reply Quote 0
      • dbeatoD
        dbeato
        last edited by

        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

        1 Reply Last reply Reply Quote 1
        • dbeatoD
          dbeato
          last edited by

          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

          Mike DavisM 1 Reply Last reply Reply Quote 1
          • Mike DavisM
            Mike Davis @dbeato
            last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • bigbearB
              bigbear
              last edited by

              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.

              1 Reply Last reply Reply Quote 2
              • Mike DavisM
                Mike Davis
                last edited by

                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 = 79ms

                Then 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),
                bigbearB 1 Reply Last reply Reply Quote 0
                • bigbearB
                  bigbear @Mike Davis
                  last edited by

                  @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 = 79ms

                  Then 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?

                  1 Reply Last reply Reply Quote 1
                  • bigbearB
                    bigbear
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 1
                    • bigbearB
                      bigbear
                      last edited by bigbear

                      https://support.polycom.com/content/dam/polycom-support/products/Voice/polycom_uc/other-documents/en/2015/BLF_HuntGroups_EA91820.pdf

                      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.

                      Mike DavisM 1 Reply Last reply Reply Quote 3
                      • Mike DavisM
                        Mike Davis @bigbear
                        last edited by

                        @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.

                        1 Reply Last reply Reply Quote 1
                        • Mike DavisM
                          Mike Davis
                          last edited by

                          The phone is a Polycom UC VVX410 in case anyone else is having this issue.

                          dbeatoD 1 Reply Last reply Reply Quote 0
                          • dbeatoD
                            dbeato @Mike Davis
                            last edited by

                            @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 🙂

                            1 Reply Last reply Reply Quote 0
                            • 1
                            • 2
                            • 2 / 2
                            • First post
                              Last post