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

    MTU size > 1500

    Scheduled Pinned Locked Moved IT Discussion
    23 Posts 7 Posters 2.7k Views
    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.
    • JaredBuschJ
      JaredBusch
      last edited by

      That is totally different than what you posted the first time

      Mike DavisM 1 Reply Last reply Reply Quote 1
      • 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
                              • 1 / 2
                              • First post
                                Last post