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
      last edited by

      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/170504812146650

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

      1 Reply Last reply Reply Quote 0
      • 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