Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Baby jumbo frames (MTU 1508) for PPPoe connections?

    2.1 Snapshot Feedback and Problems - RETIRED
    5
    6
    5461
    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.
    • D
      dadiy last edited by

      Hi,  Has any progress been made adding support for baby jumbo frames (MTU 1508) for PPPoe connections soon?

      1 Reply Last reply Reply Quote 0
      • O
        Olman last edited by

        I think,  it never happens look non standard …

        1 Reply Last reply Reply Quote 0
        • D
          David_W last edited by

          I've done some preliminary scoping work on adding RFC 4638 support to pfSense, allowing the use of PPPoE MTU > 1492 (i.e. interface MTU > 1500).

          The pfSense specific code will need, at most, a trivial patch - I haven't investigated this aspect yet, as the main problem is that there's no support for RFC 4638 in any of the lower layers.

          On FreeBSD, the low-level handling of PPPoE is in the kernel's netgraph PPPoE code. The last time I checked, even the version in HEAD has no support for the RFC 4638 PPP-Max-Payload tag. The first step is therefore adding this support to sys/netgraph/ng_pppoe.[ch] with a suitable interface for userland code.

          The next step is to patching mpd5 to make use of the kernel interface to the PPP-Max-Payload tag.

          Both these patches would have to be suitable for upstream adoption - though I have got patches into the FreeBSD kernel before and at least one pfSense committer is a FreeBSD src committer.

          The work is on my "to do" list, and I now have an appropriate setup to work on this (an RFC 4638 aware PPPoE Internet connection supplied over a BT Openreach VDSL2 circuit, a BT Openreach / Huawei modem, a jumbo capable Intel server NIC in my pfSense box and jumbo capable switches). Unfortunately, it may well be six months before I have the time to work on this.

          The patches that are around to add RFC 4638 support to NetBSD and OpenBSD offer no help in adding support to FreeBSD. NetBSD and OpenBSD implement PPPoE very differently to FreeBSD.

          1 Reply Last reply Reply Quote 0
          • E
            eri-- last edited by

            Normally it should be easier for FreeBSD(netgraph/mpd5) to include this.
            Since from my understanding this is just patching the ng_ppp and mpd5 to provide an option for this.

            Have not read teh RFC yet if it requires the interface to bump to 1508 mtu or not since that is a more severe impact in general.

            1 Reply Last reply Reply Quote 0
            • jimp
              jimp Rebel Alliance Developer Netgate last edited by

              Not that it directly helps, but baby jumbo frame support was also just added in the last OpenBSD release, I remember seeing it in their announcement.

              1 Reply Last reply Reply Quote 0
              • D
                David_W last edited by

                @ermal:

                Normally it should be easier for FreeBSD(netgraph/mpd5) to include this.
                Since from my understanding this is just patching the ng_ppp and mpd5 to provide an option for this.

                Have not read teh RFC yet if it requires the interface to bump to 1508 mtu or not since that is a more severe impact in general.

                Interface MTU of 8 bytes higher than the PPP MTU is a must to allow for the PPPoE header. This means that for PPP MTUs higher than 1492 negotiated using RFC 4638, a jumbo capable network interface in jumbo mode is required. The PPP-Max-Payload MTU will have to be clamped at the lower of the value signalled from mpd5 and the interface MTU (less 8 bytes in the latter case).

                All the RFC does is give the method to negotiate an maximum MTU in place of the usual PPPoE maximum of 1492. It's up to the PPP layer to make use of this negotiated maximum MTU to negotiate a PPP MTU above 1492, and the transport layer and network must be capable of operating at that MTU.

                @jimp:

                Not that it directly helps, but baby jumbo frame support was also just added in the last OpenBSD release, I remember seeing it in their announcement.

                Both OpenBSD and NetBSD now have RFC 4638 support. As they don't use netgraph for PPPoE, the implementation cannot be directly ported to FreeBSD, though, as ermal says, adding support to FreeBSD shouldn't be too hard.

                Connections supporting RFC 4638 are common in the UK. All BT Openreach provided VDSL2 and FTTP circuits support a 1500 byte PPP MTU. Almost every ISP using these circuits uses PPPoE - the notable exception is Sky, which uses DHCP (I forget which DHCP option is used for authentication).

                All the VDSL2 modems and FTTP ONTs supplied by BT Openreach with these connections can support a 1500 byte PPP MTU. If BT Openreach decided to offer 'wires only' VDSL2, it will be up to the customer / ISP to select hardware with baby jumbo support.

                There's a lot of pfSense users in the UK who could make use of this if it was available, assuming their pfSense box has a jumbo capable NIC.

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

                Products

                • Platform Overview
                • TNSR
                • pfSense
                • Appliances

                Services

                • Training
                • Professional Services

                Support

                • Subscription Plans
                • Contact Support
                • Product Lifecycle
                • Documentation

                News

                • Media Coverage
                • Press
                • Events

                Resources

                • Blog
                • FAQ
                • Find a Partner
                • Resource Library
                • Security Information

                Company

                • About Us
                • Careers
                • Partners
                • Contact Us
                • Legal
                Our Mission

                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                Subscribe to our Newsletter

                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                © 2021 Rubicon Communications, LLC | Privacy Policy